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

[Marek Vasut <marex@denx.de>]

On Friday, August 14, 2015 at 12:46:02 AM, Brian Norris wrote:
> We don't really need the flash information from the device tree here.
> Let's stick with autodetection here instead.

Thanks for keeping me in the loop.

> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
> ---
>  drivers/mtd/spi-nor/fsl-quadspi.c | 8 +-------
>  1 file changed, 1 insertion(+), 7 deletions(-)
> 
> diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c
> b/drivers/mtd/spi-nor/fsl-quadspi.c index d32b7e04ccca..2a17ec6269ff
> 100644
> --- a/drivers/mtd/spi-nor/fsl-quadspi.c
> +++ b/drivers/mtd/spi-nor/fsl-quadspi.c
> @@ -1006,8 +1006,6 @@ static int fsl_qspi_probe(struct platform_device
> *pdev)
> 
>  	/* iterate the subnodes. */
>  	for_each_available_child_of_node(dev->of_node, np) {
> -		char modalias[40];
> -
>  		/* skip the holes */
>  		if (!q->has_second_chip)
>  			i *= 2;
> @@ -1030,10 +1028,6 @@ static int fsl_qspi_probe(struct platform_device
> *pdev) nor->prepare = fsl_qspi_prep;
>  		nor->unprepare = fsl_qspi_unprep;
> 
> -		ret = of_modalias_node(np, modalias, sizeof(modalias));
> -		if (ret < 0)
> -			goto mutex_failed;
> -
>  		ret = of_property_read_u32(np, "spi-max-frequency",
>  				&q->clk_rate);
>  		if (ret < 0)
> @@ -1042,7 +1036,7 @@ static int fsl_qspi_probe(struct platform_device
> *pdev) /* set the chip address for READID */
>  		fsl_qspi_set_base_addr(q, nor);
> 
> -		ret = spi_nor_scan(nor, modalias, SPI_NOR_QUAD);
> +		ret = spi_nor_scan(nor, NULL, SPI_NOR_QUAD);

This is something I don't quite understand. So we have a SPI NOR controller,
which as it's own struct device instance.

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?

But, all of the SPI NORs share the same struct device as the controller. Do
I understand that correctly ? Does that make sense to NOT allocate a new
struct device for each of the SPI NORs ?

Best regards,
Marek Vasut