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

[Marek Vasut <marex@denx.de>]

On Friday, August 14, 2015 at 01:24:47 AM, Brian Norris 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.

I think maybe, just maybe, I should've asked this in an entirely separate
thread, sorry.

> 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.)

Right.

> 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.

Right.

> > 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.

Sorry, I should've asked about this in a separate thread.

Best regards,
Marek Vasut