[typo-resend] mtd: omap: fix mtd devices not showing up

Since commit 6d178ef2fd5e ("mtd: nand: Move ELM driver and rename as
omap_elm"), I don't have any mtd devices present on my am335x. This
appears to be related to the link order of the omap_elm and omap2
objects. Fix it by swapping the two in the Makefile.

Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
---
I hoped this wouldn't make a difference, but it very much did. I don't
have a proper explanation for why this actually fixes it for me though.

Resend due to misspelling in ...infradead.org

 drivers/mtd/nand/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Hi Frans,

On 10/27/2014 03:32 PM, Frans Klaver wrote:
> Since commit 6d178ef2fd5e ("mtd: nand: Move ELM driver and rename as
> omap_elm"), I don't have any mtd devices present on my am335x. This
> appears to be related to the link order of the omap_elm and omap2
> objects. Fix it by swapping the two in the Makefile.

Alternatively we could fix either elm_config() or omap_nand_probe() to
return -EPROBE_DEFER in case the device is present but driver not yet probed.

cheers,
-roger

> 
> Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
> ---
> I hoped this wouldn't make a difference, but it very much did. I don't
> have a proper explanation for why this actually fixes it for me though.
> 
> Resend due to misspelling in ...infradead.org
> 
>  drivers/mtd/nand/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
> index 9c847e4..24b81ec 100644
> --- a/drivers/mtd/nand/Makefile
> +++ b/drivers/mtd/nand/Makefile
> @@ -26,8 +26,8 @@ obj-$(CONFIG_MTD_NAND_CS553X)		+= cs553x_nand.o
>  obj-$(CONFIG_MTD_NAND_NDFC)		+= ndfc.o
>  obj-$(CONFIG_MTD_NAND_ATMEL)		+= atmel_nand.o
>  obj-$(CONFIG_MTD_NAND_GPIO)		+= gpio.o
> -obj-$(CONFIG_MTD_NAND_OMAP2) 		+= omap2.o
>  obj-$(CONFIG_MTD_NAND_OMAP_BCH_BUILD)	+= omap_elm.o
> +obj-$(CONFIG_MTD_NAND_OMAP2) 		+= omap2.o
>  obj-$(CONFIG_MTD_NAND_CM_X270)		+= cmx270_nand.o
>  obj-$(CONFIG_MTD_NAND_PXA3xx)		+= pxa3xx_nand.o
>  obj-$(CONFIG_MTD_NAND_TMIO)		+= tmio_nand.o
>

On Mon, Oct 27, 2014 at 03:56:41PM +0200, Roger Quadros wrote:
> Hi Frans,

Hi,

> On 10/27/2014 03:32 PM, Frans Klaver wrote:
> > Since commit 6d178ef2fd5e ("mtd: nand: Move ELM driver and rename as
> > omap_elm"), I don't have any mtd devices present on my am335x. This
> > appears to be related to the link order of the omap_elm and omap2
> > objects. Fix it by swapping the two in the Makefile.
> 
> Alternatively we could fix either elm_config() or omap_nand_probe() to
> return -EPROBE_DEFER in case the device is present but driver not yet probed.

I'd say that that would actually be nicer than having to depend on the
link order. I'll have a go at that.

Thanks,
Frans

On 10/27/2014 10:56 AM, Roger Quadros wrote:
> Hi Frans,
> 
> On 10/27/2014 03:32 PM, Frans Klaver wrote:
>> Since commit 6d178ef2fd5e ("mtd: nand: Move ELM driver and rename as
>> omap_elm"), I don't have any mtd devices present on my am335x. This
>> appears to be related to the link order of the omap_elm and omap2
>> objects. Fix it by swapping the two in the Makefile.
> 

I wonder how is it possible that I didn't got this on my tests.

> Alternatively we could fix either elm_config() or omap_nand_probe() to
> return -EPROBE_DEFER in case the device is present but driver not yet probed.
> 

Yes, that's a good idea. Can't we do both? Getting a systematic deferred
probe sounds like a bit silly to me.

On Mon, Oct 27, 2014 at 04:27:45PM -0300, Ezequiel Garcia wrote:
> 
> On 10/27/2014 10:56 AM, Roger Quadros wrote:
> 
> > Alternatively we could fix either elm_config() or omap_nand_probe() to
> > return -EPROBE_DEFER in case the device is present but driver not yet probed.
> > 
> 
> Yes, that's a good idea. Can't we do both? Getting a systematic deferred
> probe sounds like a bit silly to me.

It may be. If we do both and something moves again, or something is
added that depends on omap_elm but is probed earlier, you won't be
noticing the new systematic probe deferral until you really start
looking at it.

There isn't a real dependency system in the drivers, is there?

Thanks,
Frans

On 10/28/2014 05:57 AM, Frans Klaver wrote:
> On Mon, Oct 27, 2014 at 04:27:45PM -0300, Ezequiel Garcia wrote:
>>
>> On 10/27/2014 10:56 AM, Roger Quadros wrote:
>>
>>> Alternatively we could fix either elm_config() or omap_nand_probe() to
>>> return -EPROBE_DEFER in case the device is present but driver not yet probed.
>>>
>>
>> Yes, that's a good idea. Can't we do both? Getting a systematic deferred
>> probe sounds like a bit silly to me.
> 
> It may be. If we do both and something moves again, or something is
> added that depends on omap_elm but is probed earlier, you won't be
> noticing the new systematic probe deferral until you really start
> looking at it.
> 

That's correct. Relying on the link order is very fragile.

> There isn't a real dependency system in the drivers, is there?
> 

Nope.