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

[Brian Norris <computersforpeace@gmail.com>]

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.

> Does that make sense to NOT allocate a new
> struct device for each of the SPI NORs ?

I don't quite see how this question relates. Are you suggesting that we
should be using fewer *device_node* structs? That would involve
rewriting the device tree, I believe.

Or perhaps I've misunderstood your train of thought.

Brian