Re: [PATCH v3] nand: Add NAND driver for Mikrotik RB4xx series boards

[Bert Vermeulen <bert@xxxxxxxx>]

On 07/21/2015 10:29 PM, Brian Norris wrote:

>> +static struct spi_driver rb4xx_cpld_driver = {
>> +	.probe = rb4xx_cpld_probe,
>> +	.remove = rb4xx_cpld_remove,
>> +	.driver = {
>> +		.name = "rb4xx-cpld",
>> +		.owner = THIS_MODULE,
>> +	},
>> +};
> 
> I feel some deja vu here (did I make this comment before?); why do you
> need to embed both a SPI and a platform driver here? It appears that the
> NAND controller actually sits on the SPI bus, so this really is not a
> platform driver; it's a SPI driver. Can you just kill off all the
> platform_driver stuff and merge the probe functions?
> 
> Or if I'm missing something big, please do enlighten.

This driver was specifically refused by the SPI subsystem maintainer:

  http://www.linux-mips.org/archives/linux-mips/2015-03/msg00422.html

He suggested the MFD subsystem, where it was also refused:

  http://lkml.iu.edu/hypermail/linux/kernel/1504.0/03162.html

Andy Shevchenko suggested drivers/misc, so I mailed Arnd Bergmann and asked
if he would accept it there.

Arnd took a good look at the driver and suggested the MTD/NAND subsystem.
This is after all a driver for a NAND chip controller. The controller just
happens to reside in a CPLD with custom firmware, which is controlled via
SPI and has some GPIO controller functionality thrown in.

I realize it's an odd hardware setup, and I can't fix that, but this really
does seem to be the best place for it.

I can deal with your other comments on the patch, but I'd really like some
agreement on where this driver will be accepted first. I've come full circle
with getting referred back to the SPI subsystem.


-- 
Bert Vermeulen        bert@xxxxxxxx          email/xmpp
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html