[RFT PATCH 1/4] mtd: fsl-quadspi: use automatic spi-nor detection

[Michal Suchanek]

On 14 August 2015 at 01:24, Brian Norris <computersforpeace at gmail.com> wrote:
> On Fri, Aug 14, 2015 at 01:09:14AM +0200, Marek Vasut wrote:
>> This is something I don't quite understand. So we have a SPI NOR controller,
>> which as it's own struct device instance.
>
> Right.
>
>> This controller can have multiple SPI NORs on it. Each SPI NOR has it's own
>> struct spi_nor instance and struct mtd_info instance, right?
>
> Right.
>
>> But, all of the SPI NORs share the same struct device as the controller. Do
>> I understand that correctly ?
>
> Mostly yes. But your next statement doesn't quite follow in my mind, so
> maybe you've missed something.
>
> There is typically a single platform device (and associated struct
> device) that represents the fsl-quadspi controller.
>
> (Pedantic side point: each MTD actually creates one or more struct
> device objects; one for the master MTD, and one for each partition that
> might be created. But I don't think you're asking about these struct
> device's.)
>
> But none of this is super-relevant to this patch; I'm not talking about
> struct devices (think kobjects, Linux driver model), I'm dealing with
> struct device_node (think device tree, of_*() APIs, etc.).
>
> Now, each flash connected to the controller has its own device_node. All
> this patch is saying is that we don't need to know much about that node;
> as long as it responds to the READ ID command properly, spi_nor_scan()
> can autodetect it.
>

And if there was suppor for a flash chip that does not respond to READ
ID (or uses a different opcode for it) this patch would break it,
right?

Thanks

Michal