[PATCH 1/2] powerpc/85xx: Add a property bus-num for espi controller

[PATCH 1/2] powerpc/85xx: Add a property bus-num for espi controller

[Hou Zhiqiang]

To use "mtdparts=..." in cmdline, the spi_master bus_num must be static.
This property is use to asign a static bus number for spi_master other than
allocate dynamically.

Signed-off-by: Hou Zhiqiang <B48286-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 arch/powerpc/boot/dts/fsl/pq3-espi-0.dtsi   | 1 +
 arch/powerpc/boot/dts/fsl/qoriq-espi-0.dtsi | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/powerpc/boot/dts/fsl/pq3-espi-0.dtsi b/arch/powerpc/boot/dts/fsl/pq3-espi-0.dtsi
index 75854b2..cb4d488 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-espi-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-espi-0.dtsi
@@ -38,4 +38,5 @@ spi@7000 {
 	compatible = "fsl,mpc8536-espi";
 	reg = <0x7000 0x1000>;
 	interrupts = <59 0x2 0 0>;
+	bus-num = <0>;
 };
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-espi-0.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-espi-0.dtsi
index 6db0697..54358f3 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-espi-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-espi-0.dtsi
@@ -38,4 +38,5 @@ spi@110000 {
 	compatible = "fsl,mpc8536-espi";
 	reg = <0x110000 0x1000>;
 	interrupts = <53 0x2 0 0>;
+	bus-num = <0>;
 };
-- 
1.8.5


--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] spi/fsl-lib: Get the SPI controller bus number from DTS

[Hou Zhiqiang]

Get the spi_master's bus_num from DTS to make the spi_master's name
static. So "mtdparts=spi.bus_num.chip_select:..." in cmdline can be
used to asign mtd partions of spi flash.

Signed-off-by: Hou Zhiqiang <B48286-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 drivers/spi/spi-fsl-lib.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/spi-fsl-lib.c b/drivers/spi/spi-fsl-lib.c
index 0b75f26..f5f0307b 100644
--- a/drivers/spi/spi-fsl-lib.c
+++ b/drivers/spi/spi-fsl-lib.c
@@ -198,7 +198,7 @@ int of_mpc8xxx_spi_probe(struct platform_device *ofdev)
 	struct mpc8xxx_spi_probe_info *pinfo;
 	struct fsl_spi_platform_data *pdata;
 	const void *prop;
-	int ret = -ENOMEM;
+	int ret = -ENOMEM, bus_num;
 
 	pinfo = kzalloc(sizeof(*pinfo), GFP_KERNEL);
 	if (!pinfo)
@@ -207,8 +207,12 @@ int of_mpc8xxx_spi_probe(struct platform_device *ofdev)
 	pdata = &pinfo->pdata;
 	dev->platform_data = pdata;
 
-	/* Allocate bus num dynamically. */
-	pdata->bus_num = -1;
+	ret = of_property_read_u32(np, "bus-num", &bus_num);
+	if (ret < 0) {
+		/* Allocate bus num dynamically. */
+		bus_num = -1;
+	}
+	pdata->bus_num = bus_num;
 
 #ifdef CONFIG_FSL_SOC
 	/* SPI controller is either clocked from QE or SoC clock. */
-- 
1.8.5


--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] spi/fsl-lib: Get the SPI controller bus number from DTS

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 720 bytes --]

On Fri, Mar 14, 2014 at 05:35:57PM +0800, Hou Zhiqiang wrote:
> Get the spi_master's bus_num from DTS to make the spi_master's name
> static. So "mtdparts=spi.bus_num.chip_select:..." in cmdline can be
> used to asign mtd partions of spi flash.

If we are going to do this it shouldn't be device specific (it should be
done in the framework since nothing is specific to the controller there)
but I'm not convinced that we should be doing it - this is all very
Linux specific.

The DT already has support for specifying flash layouts, can't those be
used (for example via chosen if they're not fixed for the board)?  Or if
it's just picking the correct filesystem then UUIDs and labels are the
standard way to do things.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

RE: [PATCH 2/2] spi/fsl-lib: Get the SPI controller bus number from DTS

[B48286-KZfg59tc24xl57MIdRCFDg]

> -----Original Message-----
> From: Mark Brown [mailto:broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org]
> Sent: Saturday, March 15, 2014 3:19 AM
> To: Hou Zhiqiang-B48286
> Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org; pawel.moll-5wv7dgnIgG8@public.gmane.org; mark.rutland-5wv7dgnIgG8@public.gmane.org;
> ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org; galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org;
> grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org; Wood Scott-B07421; Hu Mingkai-B21284
> Subject: Re: [PATCH 2/2] spi/fsl-lib: Get the SPI controller bus number
> from DTS
> 
> On Fri, Mar 14, 2014 at 05:35:57PM +0800, Hou Zhiqiang wrote:
> > Get the spi_master's bus_num from DTS to make the spi_master's name
> > static. So "mtdparts=spi.bus_num.chip_select:..." in cmdline can be
> > used to asign mtd partions of spi flash.
> 
> If we are going to do this it shouldn't be device specific (it should be
> done in the framework since nothing is specific to the controller there)
> but I'm not convinced that we should be doing it - this is all very Linux
> specific.

This patch just assign a bus number to the controller. It is driver's 
responsibility to distribute a bus number to spi_master and the definition
of bus_num is used to distinguish controllers. So, it is specific for the
controller and doesn't affect the framework. 

> 
> The DT already has support for specifying flash layouts, can't those be
> used (for example via chosen if they're not fixed for the board)?  Or if
> it's just picking the correct filesystem then UUIDs and labels are the
> standard way to do things.

The DT specifying flash layouts is ok. There is another way to make the
flash layouts using command line, but it is not safe because of the dynamic
bus_num. It is not the reason that the way of DT is supported flash layouts,
to live the other way unsafe, right?

Thanks,
Zhiqiang
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] spi/fsl-lib: Get the SPI controller bus number from DTS

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2218 bytes --]

On Mon, Mar 17, 2014 at 05:11:11AM +0000, B48286-KZfg59tc24xl57MIdRCFDg@public.gmane.org wrote:
> > On Fri, Mar 14, 2014 at 05:35:57PM +0800, Hou Zhiqiang wrote:
> > > Get the spi_master's bus_num from DTS to make the spi_master's name
> > > static. So "mtdparts=spi.bus_num.chip_select:..." in cmdline can be
> > > used to asign mtd partions of spi flash.

> > If we are going to do this it shouldn't be device specific (it should be
> > done in the framework since nothing is specific to the controller there)
> > but I'm not convinced that we should be doing it - this is all very Linux
> > specific.

> This patch just assign a bus number to the controller. It is driver's 
> responsibility to distribute a bus number to spi_master and the definition
> of bus_num is used to distinguish controllers. So, it is specific for the
> controller and doesn't affect the framework. 

You are adding a property to specify a bus number.  There is no reason
why such a property should be specific to a single controller, every
controller in every system has a bus number assigned to it so if we have
a way to specify one controller via the device tree we should have a way
to specify it for all.

> > The DT already has support for specifying flash layouts, can't those be
> > used (for example via chosen if they're not fixed for the board)?  Or if
> > it's just picking the correct filesystem then UUIDs and labels are the
> > standard way to do things.

> The DT specifying flash layouts is ok. There is another way to make the
> flash layouts using command line, but it is not safe because of the dynamic
> bus_num. It is not the reason that the way of DT is supported flash layouts,
> to live the other way unsafe, right?

This sounds to me like we need a better way of talking about flash
device names on the Linux command line rather than a way to fix the bus
number - for example, being able to refer to them using a fixed property
like the physical address.  Being able to refer to devices via an alias
assigned in the DT would also be useful (and more readable), I think
there may already be a mechanism for doing that which would need to be
plumbed in but I'm not 100% sure.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

RE: [PATCH 2/2] spi/fsl-lib: Get the SPI controller bus number from DTS

[B48286-KZfg59tc24xl57MIdRCFDg]

> -----Original Message-----
> From: Mark Brown [mailto:broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org]
> Sent: Monday, March 17, 2014 9:01 PM
> To: Hou Zhiqiang-B48286
> Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org; pawel.moll-5wv7dgnIgG8@public.gmane.org; mark.rutland-5wv7dgnIgG8@public.gmane.org;
> ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org; galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org;
> grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org; Wood Scott-B07421; Hu Mingkai-B21284
> Subject: Re: [PATCH 2/2] spi/fsl-lib: Get the SPI controller bus number
> from DTS
> 
> On Mon, Mar 17, 2014 at 05:11:11AM +0000, B48286-KZfg59tc24xl57MIdRCFDg@public.gmane.org wrote:
> > > On Fri, Mar 14, 2014 at 05:35:57PM +0800, Hou Zhiqiang wrote:
> > > > Get the spi_master's bus_num from DTS to make the spi_master's
> > > > name static. So "mtdparts=spi.bus_num.chip_select:..." in cmdline
> > > > can be used to asign mtd partions of spi flash.
> 
> > > If we are going to do this it shouldn't be device specific (it
> > > should be done in the framework since nothing is specific to the
> > > controller there) but I'm not convinced that we should be doing it -
> > > this is all very Linux specific.
> 
> > This patch just assign a bus number to the controller. It is driver's
> > responsibility to distribute a bus number to spi_master and the
> > definition of bus_num is used to distinguish controllers. So, it is
> > specific for the controller and doesn't affect the framework.
> 
> You are adding a property to specify a bus number.  There is no reason
> why such a property should be specific to a single controller, every
> controller in every system has a bus number assigned to it so if we have
> a way to specify one controller via the device tree we should have a way
> to specify it for all.
> 

The reason to specify a bus number to a single controller is to avoid 
allocating one dynamically, so we know the bus number before booting up the
kernel. If there are several controllers, you should add this property to all
of them. But it is unnecessary to add this property, if you do not care about
the bus number, and it will be allocated dynamically. 

> > > The DT already has support for specifying flash layouts, can't those
> > > be used (for example via chosen if they're not fixed for the board)?
> > > Or if it's just picking the correct filesystem then UUIDs and labels
> > > are the standard way to do things.
> 
> > The DT specifying flash layouts is ok. There is another way to make
> > the flash layouts using command line, but it is not safe because of
> > the dynamic bus_num. It is not the reason that the way of DT is
> > supported flash layouts, to live the other way unsafe, right?
> 
> This sounds to me like we need a better way of talking about flash device
> names on the Linux command line rather than a way to fix the bus number -
> for example, being able to refer to them using a fixed property like the
> physical address.  Being able to refer to devices via an alias assigned
> in the DT would also be useful (and more readable), I think there may
> already be a mechanism for doing that which would need to be plumbed in
> but I'm not 100% sure.

The bus number is the variable designed to distinguish one spi controller
from others. Why spi controller's physical address must be use instead of
bus number?
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] spi/fsl-lib: Get the SPI controller bus number from DTS

[Geert Uytterhoeven]

On Tue, Mar 18, 2014 at 8:40 AM, B48286-KZfg59tc24xl57MIdRCFDg@public.gmane.org
<B48286-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
>> > > The DT already has support for specifying flash layouts, can't those
>> > > be used (for example via chosen if they're not fixed for the board)?
>> > > Or if it's just picking the correct filesystem then UUIDs and labels
>> > > are the standard way to do things.
>>
>> > The DT specifying flash layouts is ok. There is another way to make
>> > the flash layouts using command line, but it is not safe because of
>> > the dynamic bus_num. It is not the reason that the way of DT is
>> > supported flash layouts, to live the other way unsafe, right?
>>
>> This sounds to me like we need a better way of talking about flash device
>> names on the Linux command line rather than a way to fix the bus number -
>> for example, being able to refer to them using a fixed property like the
>> physical address.  Being able to refer to devices via an alias assigned
>> in the DT would also be useful (and more readable), I think there may
>> already be a mechanism for doing that which would need to be plumbed in
>> but I'm not 100% sure.
>
> The bus number is the variable designed to distinguish one spi controller
> from others. Why spi controller's physical address must be use instead of
> bus number?

Because the bus number is dynamic, while the physical address doesn't
change, so it can be used to uniqely identify the device before booting the
kernel.
Cfr. "spi1" vs. "e6e20000.spi".

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 2/2] spi/fsl-lib: Get the SPI controller bus number from DTS

[B48286-KZfg59tc24xl57MIdRCFDg]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2927 bytes --]



> -----Original Message-----
> From: geert.uytterhoeven@gmail.com [mailto:geert.uytterhoeven@gmail.com]
> On Behalf Of Geert Uytterhoeven
> Sent: Tuesday, March 18, 2014 4:56 PM
> To: Hou Zhiqiang-B48286
> Cc: Mark Brown; linux-spi@vger.kernel.org; devicetree@vger.kernel.org;
> rob.herring@calxeda.com; pawel.moll@arm.com; mark.rutland@arm.com;
> ijc+devicetree@hellion.org.uk; galak@codeaurora.org;
> grant.likely@secretlab.ca; Wood Scott-B07421; Hu Mingkai-B21284
> Subject: Re: [PATCH 2/2] spi/fsl-lib: Get the SPI controller bus number
> from DTS
> 
> On Tue, Mar 18, 2014 at 8:40 AM, B48286@freescale.com
> <B48286@freescale.com> wrote:
> >> > > The DT already has support for specifying flash layouts, can't
> >> > > those be used (for example via chosen if they're not fixed for the
> board)?
> >> > > Or if it's just picking the correct filesystem then UUIDs and
> >> > > labels are the standard way to do things.
> >>
> >> > The DT specifying flash layouts is ok. There is another way to make
> >> > the flash layouts using command line, but it is not safe because of
> >> > the dynamic bus_num. It is not the reason that the way of DT is
> >> > supported flash layouts, to live the other way unsafe, right?
> >>
> >> This sounds to me like we need a better way of talking about flash
> >> device names on the Linux command line rather than a way to fix the
> >> bus number - for example, being able to refer to them using a fixed
> >> property like the physical address.  Being able to refer to devices
> >> via an alias assigned in the DT would also be useful (and more
> >> readable), I think there may already be a mechanism for doing that
> >> which would need to be plumbed in but I'm not 100% sure.
> >
> > The bus number is the variable designed to distinguish one spi
> > controller from others. Why spi controller's physical address must be
> > use instead of bus number?
> 
> Because the bus number is dynamic, while the physical address doesn't
> change, so it can be used to uniqely identify the device before booting
> the kernel.
> Cfr. "spi1" vs. "e6e20000.spi".
> 

The precondition of dynamic bus number is initial it with -1 in the controller
driver. But now I need a reasonable bus number, I don't want a dynamic one.
Why does use the controller's physical address to take the role of bus number
to distinguish controllers. 

> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-
> m68k.org
> 
> In personal conversations with technical people, I call myself a hacker.
> But when I'm talking to journalists I just say "programmer" or something
> like that.
>                                 -- Linus Torvalds
> 

N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·zøœzÚÞz)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢j.ïÛ°\½½MŽúgjÌæa×\x02››–' ™©Þ¢¸\f¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾\a«‘êçzZ+ƒùšŽŠÝ¢j"ú!¶i

Re: [PATCH 2/2] spi/fsl-lib: Get the SPI controller bus number from DTS

[Scott Wood]

On Tue, 2014-03-18 at 04:34 -0500, Hou Zhiqiang-B48286 wrote:
> 
> > -----Original Message-----
> > From: geert.uytterhoeven-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org [mailto:geert.uytterhoeven-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
> > On Behalf Of Geert Uytterhoeven
> > Sent: Tuesday, March 18, 2014 4:56 PM
> > To: Hou Zhiqiang-B48286
> > Cc: Mark Brown; linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org; pawel.moll-5wv7dgnIgG8@public.gmane.org; mark.rutland-5wv7dgnIgG8@public.gmane.org;
> > ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org; galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org;
> > grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org; Wood Scott-B07421; Hu Mingkai-B21284
> > Subject: Re: [PATCH 2/2] spi/fsl-lib: Get the SPI controller bus number
> > from DTS
> > 
> > On Tue, Mar 18, 2014 at 8:40 AM, B48286-KZfg59tc24xl57MIdRCFDg@public.gmane.org
> > <B48286-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > >> > > The DT already has support for specifying flash layouts, can't
> > >> > > those be used (for example via chosen if they're not fixed for the
> > board)?
> > >> > > Or if it's just picking the correct filesystem then UUIDs and
> > >> > > labels are the standard way to do things.
> > >>
> > >> > The DT specifying flash layouts is ok. There is another way to make
> > >> > the flash layouts using command line, but it is not safe because of
> > >> > the dynamic bus_num. It is not the reason that the way of DT is
> > >> > supported flash layouts, to live the other way unsafe, right?
> > >>
> > >> This sounds to me like we need a better way of talking about flash
> > >> device names on the Linux command line rather than a way to fix the
> > >> bus number - for example, being able to refer to them using a fixed
> > >> property like the physical address.  Being able to refer to devices
> > >> via an alias assigned in the DT would also be useful (and more
> > >> readable), I think there may already be a mechanism for doing that
> > >> which would need to be plumbed in but I'm not 100% sure.
> > >
> > > The bus number is the variable designed to distinguish one spi
> > > controller from others. Why spi controller's physical address must be
> > > use instead of bus number?
> > 
> > Because the bus number is dynamic, while the physical address doesn't
> > change, so it can be used to uniqely identify the device before booting
> > the kernel.
> > Cfr. "spi1" vs. "e6e20000.spi".
> > 
> 
> The precondition of dynamic bus number is initial it with -1 in the controller
> driver. But now I need a reasonable bus number, I don't want a dynamic one.
> Why does use the controller's physical address to take the role of bus number
> to distinguish controllers. 

Where are you going to get this "reasonable" non-dynamic number from?
How are you going to ensure there are no conflicts with other SPI
controllers (e.g. on a dynamic add-on card)?

Physical addresses work well because they are tied to something real,
rather than an arbitrary enumeration.  Our NAND controllers use the
physical address for the MTD name.  Device tree NOR flash allows the
device tree to set the mtd name[1], and otherwise falls back on the
platform device name, which contains the physical address.

-Scott

[1] This violates the "device tree describes hardware rather than
configures Linux" rule...


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 2/2] spi/fsl-lib: Get the SPI controller bus number from DTS

[B48286-KZfg59tc24xl57MIdRCFDg]

> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, March 19, 2014 6:09 AM
> To: Hou Zhiqiang-B48286
> Cc: 'Geert Uytterhoeven'; Mark Brown; linux-spi@vger.kernel.org;
> devicetree@vger.kernel.org; rob.herring@calxeda.com; pawel.moll@arm.com;
> mark.rutland@arm.com; ijc+devicetree@hellion.org.uk; galak@codeaurora.org;
> grant.likely@secretlab.ca; Hu Mingkai-B21284
> Subject: Re: [PATCH 2/2] spi/fsl-lib: Get the SPI controller bus number
> from DTS
> 
> On Tue, 2014-03-18 at 04:34 -0500, Hou Zhiqiang-B48286 wrote:
> >
> > > -----Original Message-----
> > > From: geert.uytterhoeven@gmail.com
> > > [mailto:geert.uytterhoeven@gmail.com]
> > > On Behalf Of Geert Uytterhoeven
> > > Sent: Tuesday, March 18, 2014 4:56 PM
> > > To: Hou Zhiqiang-B48286
> > > Cc: Mark Brown; linux-spi@vger.kernel.org;
> > > devicetree@vger.kernel.org; rob.herring@calxeda.com;
> > > pawel.moll@arm.com; mark.rutland@arm.com;
> > > ijc+devicetree@hellion.org.uk; galak@codeaurora.org;
> > > grant.likely@secretlab.ca; Wood Scott-B07421; Hu Mingkai-B21284
> > > Subject: Re: [PATCH 2/2] spi/fsl-lib: Get the SPI controller bus
> > > number from DTS
> > >
> > > On Tue, Mar 18, 2014 at 8:40 AM, B48286@freescale.com
> > > <B48286@freescale.com> wrote:
> > > >> > > The DT already has support for specifying flash layouts,
> > > >> > > can't those be used (for example via chosen if they're not
> > > >> > > fixed for the
> > > board)?
> > > >> > > Or if it's just picking the correct filesystem then UUIDs and
> > > >> > > labels are the standard way to do things.
> > > >>
> > > >> > The DT specifying flash layouts is ok. There is another way to
> > > >> > make the flash layouts using command line, but it is not safe
> > > >> > because of the dynamic bus_num. It is not the reason that the
> > > >> > way of DT is supported flash layouts, to live the other way
> unsafe, right?
> > > >>
> > > >> This sounds to me like we need a better way of talking about
> > > >> flash device names on the Linux command line rather than a way to
> > > >> fix the bus number - for example, being able to refer to them
> > > >> using a fixed property like the physical address.  Being able to
> > > >> refer to devices via an alias assigned in the DT would also be
> > > >> useful (and more readable), I think there may already be a
> > > >> mechanism for doing that which would need to be plumbed in but I'm
> not 100% sure.
> > > >
> > > > The bus number is the variable designed to distinguish one spi
> > > > controller from others. Why spi controller's physical address must
> > > > be use instead of bus number?
> > >
> > > Because the bus number is dynamic, while the physical address
> > > doesn't change, so it can be used to uniqely identify the device
> > > before booting the kernel.
> > > Cfr. "spi1" vs. "e6e20000.spi".
> > >
> >
> > The precondition of dynamic bus number is initial it with -1 in the
> > controller driver. But now I need a reasonable bus number, I don't want
> a dynamic one.
> > Why does use the controller's physical address to take the role of bus
> > number to distinguish controllers.
> 
> Where are you going to get this "reasonable" non-dynamic number from?
> How are you going to ensure there are no conflicts with other SPI
> controllers (e.g. on a dynamic add-on card)?
> 
"other than negative (== assign one dynamically), bus_num is fully
board-specific.  usually that simplifies to being SOC-specific.
example:  one SOC has three SPI controllers, numbered 0..2,
and one board's schematics might show it using SPI-2.  software
would normally use bus_num=2 for that controller."
The above paragraph is description of bus_num in spi.h. The "reasonable"
is from it.
Other controllers should also include this property, otherwise it will be
dynamic. So there is not conflict.

> Physical addresses work well because they are tied to something real,
> rather than an arbitrary enumeration.  Our NAND controllers use the
> physical address for the MTD name.  Device tree NOR flash allows the
> device tree to set the mtd name[1], and otherwise falls back on the
> platform device name, which contains the physical address.
>
I know the physical work well, but there is a mechanism of bus number.
As the description say above, isn't it reasonable?
 
> -Scott
> 
> [1] This violates the "device tree describes hardware rather than
> configures Linux" rule...
> 

Re: [PATCH 2/2] spi/fsl-lib: Get the SPI controller bus number from DTS

[Scott Wood]

On Tue, 2014-03-18 at 21:49 -0500, Hou Zhiqiang-B48286 wrote:
> 
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, March 19, 2014 6:09 AM
> > To: Hou Zhiqiang-B48286
> > Cc: 'Geert Uytterhoeven'; Mark Brown; linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org; pawel.moll-5wv7dgnIgG8@public.gmane.org;
> > mark.rutland-5wv7dgnIgG8@public.gmane.org; ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org; galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org;
> > grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org; Hu Mingkai-B21284
> > Subject: Re: [PATCH 2/2] spi/fsl-lib: Get the SPI controller bus number
> > from DTS
> > 
> > On Tue, 2014-03-18 at 04:34 -0500, Hou Zhiqiang-B48286 wrote:
> > >
> > > > -----Original Message-----
> > > > From: geert.uytterhoeven-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> > > > [mailto:geert.uytterhoeven-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
> > > > On Behalf Of Geert Uytterhoeven
> > > > Sent: Tuesday, March 18, 2014 4:56 PM
> > > > To: Hou Zhiqiang-B48286
> > > > Cc: Mark Brown; linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > > > devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org;
> > > > pawel.moll-5wv7dgnIgG8@public.gmane.org; mark.rutland-5wv7dgnIgG8@public.gmane.org;
> > > > ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org; galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org;
> > > > grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org; Wood Scott-B07421; Hu Mingkai-B21284
> > > > Subject: Re: [PATCH 2/2] spi/fsl-lib: Get the SPI controller bus
> > > > number from DTS
> > > >
> > > > On Tue, Mar 18, 2014 at 8:40 AM, B48286-KZfg59tc24xl57MIdRCFDg@public.gmane.org
> > > > <B48286-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > > >> > > The DT already has support for specifying flash layouts,
> > > > >> > > can't those be used (for example via chosen if they're not
> > > > >> > > fixed for the
> > > > board)?
> > > > >> > > Or if it's just picking the correct filesystem then UUIDs and
> > > > >> > > labels are the standard way to do things.
> > > > >>
> > > > >> > The DT specifying flash layouts is ok. There is another way to
> > > > >> > make the flash layouts using command line, but it is not safe
> > > > >> > because of the dynamic bus_num. It is not the reason that the
> > > > >> > way of DT is supported flash layouts, to live the other way
> > unsafe, right?
> > > > >>
> > > > >> This sounds to me like we need a better way of talking about
> > > > >> flash device names on the Linux command line rather than a way to
> > > > >> fix the bus number - for example, being able to refer to them
> > > > >> using a fixed property like the physical address.  Being able to
> > > > >> refer to devices via an alias assigned in the DT would also be
> > > > >> useful (and more readable), I think there may already be a
> > > > >> mechanism for doing that which would need to be plumbed in but I'm
> > not 100% sure.
> > > > >
> > > > > The bus number is the variable designed to distinguish one spi
> > > > > controller from others. Why spi controller's physical address must
> > > > > be use instead of bus number?
> > > >
> > > > Because the bus number is dynamic, while the physical address
> > > > doesn't change, so it can be used to uniqely identify the device
> > > > before booting the kernel.
> > > > Cfr. "spi1" vs. "e6e20000.spi".
> > > >
> > >
> > > The precondition of dynamic bus number is initial it with -1 in the
> > > controller driver. But now I need a reasonable bus number, I don't want
> > a dynamic one.
> > > Why does use the controller's physical address to take the role of bus
> > > number to distinguish controllers.
> > 
> > Where are you going to get this "reasonable" non-dynamic number from?
> > How are you going to ensure there are no conflicts with other SPI
> > controllers (e.g. on a dynamic add-on card)?
> > 
> "other than negative (== assign one dynamically), bus_num is fully
> board-specific.  usually that simplifies to being SOC-specific.
> example:  one SOC has three SPI controllers, numbered 0..2,
> and one board's schematics might show it using SPI-2.  software
> would normally use bus_num=2 for that controller."
> The above paragraph is description of bus_num in spi.h. The "reasonable"
> is from it.
> Other controllers should also include this property, otherwise it will be
> dynamic. So there is not conflict.

So instead of using something concrete like a physical address, you want
to use a number from a manual.  Again, what happens in a system where
SPI controllers can be added dynamically (forget about whether this is
possible on the systems you care about), or even statically from a
different source (e.g. board logic)?  How does the driver know what
number the manual assigns to a given controller?  Why would you even
want to deal with this when using the physical address is so easy?

> > Physical addresses work well because they are tied to something real,
> > rather than an arbitrary enumeration.  Our NAND controllers use the
> > physical address for the MTD name.  Device tree NOR flash allows the
> > device tree to set the mtd name[1], and otherwise falls back on the
> > platform device name, which contains the physical address.
> >
> I know the physical work well, but there is a mechanism of bus number.
> As the description say above, isn't it reasonable?

No.

-Scott


--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] spi/fsl-lib: Get the SPI controller bus number from DTS

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1075 bytes --]

On Tue, Mar 18, 2014 at 07:40:28AM +0000, B48286-KZfg59tc24xl57MIdRCFDg@public.gmane.org wrote:

> > You are adding a property to specify a bus number.  There is no reason
> > why such a property should be specific to a single controller, every
> > controller in every system has a bus number assigned to it so if we have
> > a way to specify one controller via the device tree we should have a way
> > to specify it for all.

> The reason to specify a bus number to a single controller is to avoid 
> allocating one dynamically, so we know the bus number before booting up the
> kernel. If there are several controllers, you should add this property to all
> of them. But it is unnecessary to add this property, if you do not care about
> the bus number, and it will be allocated dynamically. 

Please re-read what I wrote above, you're completely missing the point.
The problem above is that you are adding this in driver specific code,
even if this is a good idea there's nothing specific to this device
about it so we shouldn't be doing it in a driver.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]