[PATCH] ARM: tegra: add "nor-jedec" flash compatible binding

[PATCH] ARM: tegra: add "nor-jedec" flash compatible binding

[Rafał Miłecki]

Starting with commits
8ff16cf ("Documentation: devicetree: m25p80: add "nor-jedec" binding")
1103b85 ("mtd: m25p80: bind to "nor-jedec" ID, for auto-detection")
we have "nor-jedec" binding indicating support for JEDEC identification.

Signed-off-by: Rafa? Mi?ecki <zajec5@gmail.com>
---
 arch/arm/boot/dts/tegra114-dalmore.dts    | 2 +-
 arch/arm/boot/dts/tegra124-jetson-tk1.dts | 2 +-
 arch/arm/boot/dts/tegra124-nyan.dtsi      | 2 +-
 arch/arm/boot/dts/tegra124-venice2.dts    | 2 +-
 arch/arm/boot/dts/tegra20-trimslice.dts   | 2 +-
 arch/arm/boot/dts/tegra30-beaver.dts      | 2 +-
 arch/arm/boot/dts/tegra30-cardhu.dtsi     | 2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
index 8b7aa0d..e30985b 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -1082,7 +1082,7 @@
 		status = "okay";
 		spi-max-frequency = <25000000>;
 		spi-flash at 0 {
-			compatible = "winbond,w25q32dw";
+			compatible = "winbond,w25q32dw", "nor-jedec";
 			reg = <0>;
 			spi-max-frequency = <20000000>;
 		};
diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
index ed8a8ac..b2da4f0 100644
--- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
+++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
@@ -1611,7 +1611,7 @@
 		status = "okay";
 		spi-max-frequency = <25000000>;
 		spi-flash at 0 {
-			compatible = "winbond,w25q32dw";
+			compatible = "winbond,w25q32dw", "nor-jedec";
 			reg = <0>;
 			spi-max-frequency = <20000000>;
 		};
diff --git a/arch/arm/boot/dts/tegra124-nyan.dtsi b/arch/arm/boot/dts/tegra124-nyan.dtsi
index a9aec23..2dc3377 100644
--- a/arch/arm/boot/dts/tegra124-nyan.dtsi
+++ b/arch/arm/boot/dts/tegra124-nyan.dtsi
@@ -343,7 +343,7 @@
 		spi-max-frequency = <25000000>;
 
 		flash at 0 {
-			compatible = "winbond,w25q32dw";
+			compatible = "winbond,w25q32dw", "nor-jedec";
 			spi-max-frequency = <25000000>;
 			reg = <0>;
 		};
diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts
index 5c3f781..73a30cd 100644
--- a/arch/arm/boot/dts/tegra124-venice2.dts
+++ b/arch/arm/boot/dts/tegra124-venice2.dts
@@ -866,7 +866,7 @@
 		status = "okay";
 		spi-max-frequency = <25000000>;
 		spi-flash at 0 {
-			compatible = "winbond,w25q32dw";
+			compatible = "winbond,w25q32dw", "nor-jedec";
 			reg = <0>;
 			spi-max-frequency = <20000000>;
 		};
diff --git a/arch/arm/boot/dts/tegra20-trimslice.dts b/arch/arm/boot/dts/tegra20-trimslice.dts
index d99af4e..ace7028 100644
--- a/arch/arm/boot/dts/tegra20-trimslice.dts
+++ b/arch/arm/boot/dts/tegra20-trimslice.dts
@@ -282,7 +282,7 @@
 		status = "okay";
 		spi-max-frequency = <48000000>;
 		spi-flash at 0 {
-			compatible = "winbond,w25q80bl";
+			compatible = "winbond,w25q80bl", "nor-jedec";
 			reg = <0>;
 			spi-max-frequency = <48000000>;
 		};
diff --git a/arch/arm/boot/dts/tegra30-beaver.dts b/arch/arm/boot/dts/tegra30-beaver.dts
index 3dede39..43ae39a 100644
--- a/arch/arm/boot/dts/tegra30-beaver.dts
+++ b/arch/arm/boot/dts/tegra30-beaver.dts
@@ -1884,7 +1884,7 @@
 		status = "okay";
 		spi-max-frequency = <25000000>;
 		spi-flash at 1 {
-			compatible = "winbond,w25q32";
+			compatible = "winbond,w25q32", "nor-jedec";
 			reg = <1>;
 			spi-max-frequency = <20000000>;
 		};
diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index a1b682e..665a941 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -353,7 +353,7 @@
 		status = "okay";
 		spi-max-frequency = <25000000>;
 		spi-flash at 1 {
-			compatible = "winbond,w25q32";
+			compatible = "winbond,w25q32", "nor-jedec";
 			reg = <1>;
 			spi-max-frequency = <20000000>;
 		};
-- 
1.8.4.5

[PATCH] ARM: tegra: add "nor-jedec" flash compatible binding

[Stephen Warren]

On 05/08/2015 12:21 AM, Rafa? Mi?ecki wrote:
> Starting with commits
> 8ff16cf ("Documentation: devicetree: m25p80: add "nor-jedec" binding")
> 1103b85 ("mtd: m25p80: bind to "nor-jedec" ID, for auto-detection")
> we have "nor-jedec" binding indicating support for JEDEC identification.

The documentation looks quite incomplete. "nor-jedec" sounds like it's 
intended to be something generic. As such, it should be documented in 
e.g. Documentation/devicetree/bindings/mtd/nor-jedec.txt, not buried in 
one particular flash device's binding. If it's not intended to be 
generic, why isn't the existing "winbond,w25q32dw" enough?

Equally, "nor-jedec" doesn't sound like the right name. It doesn't 
differentiate between SPI and parallel NOR flash, which presumably need 
different compatible values, since the programming model is quite 
different, and the compatible value is supposed to define/imply the 
SW-visible programming model.

[PATCH] ARM: tegra: add "nor-jedec" flash compatible binding

[Brian Norris]

On Fri, May 08, 2015 at 10:00:12AM -0600, Stephen Warren wrote:
> On 05/08/2015 12:21 AM, Rafa? Mi?ecki wrote:
> >Starting with commits
> >8ff16cf ("Documentation: devicetree: m25p80: add "nor-jedec" binding")
> >1103b85 ("mtd: m25p80: bind to "nor-jedec" ID, for auto-detection")
> >we have "nor-jedec" binding indicating support for JEDEC identification.
> 
> The documentation looks quite incomplete. "nor-jedec" sounds like
> it's intended to be something generic. As such, it should be
> documented in e.g.
> Documentation/devicetree/bindings/mtd/nor-jedec.txt, not buried in
> one particular flash device's binding. If it's not intended to be
> generic, why isn't the existing "winbond,w25q32dw" enough?

It is generic, though there are plenty of additional manufacturer/device
pairs that could go on top of it. m25p80 was (one of?) the first
supported, so the naming has been based on legacy, and we're in the
process of unwinding a bit of that. If it helps, we could move the doc
to .../mtd/spi-nor,nor-jedec.txt or something like that.

> Equally, "nor-jedec" doesn't sound like the right name. It doesn't
> differentiate between SPI and parallel NOR flash, which presumably
> need different compatible values, since the programming model is
> quite different, and the compatible value is supposed to
> define/imply the SW-visible programming model.

It's definitely for SPI only. There was much discussion about this a
few months back. Somewhere along the way, it was mentioned that the
context (SPI slave is a child of SPI master) would make this clear. I'm
still not sure why we didn't end up with something more descriptive,
though, like "spi-nor,nor-jedec".

I'm open to change, as this binding is new in 4.1-rc1.

Brian

[PATCH] ARM: tegra: add "nor-jedec" flash compatible binding

[Brian Norris]

On Fri, May 08, 2015 at 11:43:17AM -0700, Brian Norris wrote:
> I'm open to change, as this binding is new in 4.1-rc1.

Though we'd need to make sure any change to "nor-jedec" gets applied to
the shmobile platforms that have started using this string in
linux-next.

Brian

[PATCH] ARM: tegra: add "nor-jedec" flash compatible binding

[Stephen Warren]

On 05/08/2015 12:43 PM, Brian Norris wrote:
> On Fri, May 08, 2015 at 10:00:12AM -0600, Stephen Warren wrote:
>> On 05/08/2015 12:21 AM, Rafa? Mi?ecki wrote:
>>> Starting with commits
>>> 8ff16cf ("Documentation: devicetree: m25p80: add "nor-jedec" binding")
>>> 1103b85 ("mtd: m25p80: bind to "nor-jedec" ID, for auto-detection")
>>> we have "nor-jedec" binding indicating support for JEDEC identification.
>>
>> The documentation looks quite incomplete. "nor-jedec" sounds like
>> it's intended to be something generic. As such, it should be
>> documented in e.g.
>> Documentation/devicetree/bindings/mtd/nor-jedec.txt, not buried in
>> one particular flash device's binding. If it's not intended to be
>> generic, why isn't the existing "winbond,w25q32dw" enough?
>
> It is generic, though there are plenty of additional manufacturer/device
> pairs that could go on top of it. m25p80 was (one of?) the first
> supported, so the naming has been based on legacy, and we're in the
> process of unwinding a bit of that. If it helps, we could move the doc
> to .../mtd/spi-nor,nor-jedec.txt or something like that.

Yes, moving the documentation to a generic location would be appropriate 
in my opinion.

>> Equally, "nor-jedec" doesn't sound like the right name. It doesn't
>> differentiate between SPI and parallel NOR flash, which presumably
>> need different compatible values, since the programming model is
>> quite different, and the compatible value is supposed to
>> define/imply the SW-visible programming model.
>
> It's definitely for SPI only. There was much discussion about this a
> few months back. Somewhere along the way, it was mentioned that the
> context (SPI slave is a child of SPI master) would make this clear. I'm
> still not sure why we didn't end up with something more descriptive,
> though, like "spi-nor,nor-jedec".
>
> I'm open to change, as this binding is new in 4.1-rc1.

I don't believe compatible values should be interpreted according to 
context; compatible value matching isn't implemented that way AFAIK, and 
I'm not aware of any precedent for it to work that way.

Did the discussion involve the core DT maintainers? If so, whatever they 
decided can stick. Otherwise, the discussion should be rubn by them.

[PATCH] ARM: tegra: add "nor-jedec" flash compatible binding

[Brian Norris]

On Fri, May 08, 2015 at 02:01:40PM -0600, Stephen Warren wrote:
> On 05/08/2015 12:43 PM, Brian Norris wrote:
> >On Fri, May 08, 2015 at 10:00:12AM -0600, Stephen Warren wrote:
> >>Equally, "nor-jedec" doesn't sound like the right name. It doesn't
> >>differentiate between SPI and parallel NOR flash, which presumably
> >>need different compatible values, since the programming model is
> >>quite different, and the compatible value is supposed to
> >>define/imply the SW-visible programming model.
> >
> >It's definitely for SPI only. There was much discussion about this a
> >few months back. Somewhere along the way, it was mentioned that the
> >context (SPI slave is a child of SPI master) would make this clear. I'm
> >still not sure why we didn't end up with something more descriptive,
> >though, like "spi-nor,nor-jedec".
> >
> >I'm open to change, as this binding is new in 4.1-rc1.
> 
> I don't believe compatible values should be interpreted according to
> context; compatible value matching isn't implemented that way AFAIK,
> and I'm not aware of any precedent for it to work that way.

For SPI slaves, they are always nested within their SPI master/bus node.
The master driver chooses how to probe its children. So there is some
context-sensitivity.

> Did the discussion involve the core DT maintainers? If so, whatever
> they decided can stick. Otherwise, the discussion should be rubn by
> them.

Yes. I never got an "ack", but Mark Rutland commented a few times and
didn't seem to object to the name. e.g.:

http://lists.infradead.org/pipermail/linux-mtd/2015-March/058275.html

Brian

[PATCH] ARM: tegra: add "nor-jedec" flash compatible binding

[Stephen Warren]

On 05/08/2015 02:15 PM, Brian Norris wrote:
> On Fri, May 08, 2015 at 02:01:40PM -0600, Stephen Warren wrote:
>> On 05/08/2015 12:43 PM, Brian Norris wrote:
>>> On Fri, May 08, 2015 at 10:00:12AM -0600, Stephen Warren wrote:
>>>> Equally, "nor-jedec" doesn't sound like the right name. It doesn't
>>>> differentiate between SPI and parallel NOR flash, which presumably
>>>> need different compatible values, since the programming model is
>>>> quite different, and the compatible value is supposed to
>>>> define/imply the SW-visible programming model.
>>>
>>> It's definitely for SPI only. There was much discussion about this a
>>> few months back. Somewhere along the way, it was mentioned that the
>>> context (SPI slave is a child of SPI master) would make this clear. I'm
>>> still not sure why we didn't end up with something more descriptive,
>>> though, like "spi-nor,nor-jedec".
>>>
>>> I'm open to change, as this binding is new in 4.1-rc1.
>>
>> I don't believe compatible values should be interpreted according to
>> context; compatible value matching isn't implemented that way AFAIK,
>> and I'm not aware of any precedent for it to work that way.
>
> For SPI slaves, they are always nested within their SPI master/bus node.
> The master driver chooses how to probe its children. So there is some
> context-sensitivity.

That means it might be possible to implement context-sensitivity. 
However, it does not mean context-sensitivity is or should be implemented.

>> Did the discussion involve the core DT maintainers? If so, whatever
>> they decided can stick. Otherwise, the discussion should be rubn by
>> them.
>
> Yes. I never got an "ack", but Mark Rutland commented a few times and
> didn't seem to object to the name. e.g.:
>
> http://lists.infradead.org/pipermail/linux-mtd/2015-March/058275.html

Nobody pointed out in that thread the "jedec-nor" isn't remotely 
SPI-specific.

[PATCH] ARM: tegra: add "nor-jedec" flash compatible binding

[Geert Uytterhoeven]

On Fri, May 8, 2015 at 8:43 PM, Brian Norris
<computersforpeace@gmail.com> wrote:
> On Fri, May 08, 2015 at 10:00:12AM -0600, Stephen Warren wrote:
>> On 05/08/2015 12:21 AM, Rafa? Mi?ecki wrote:
>> >Starting with commits
>> >8ff16cf ("Documentation: devicetree: m25p80: add "nor-jedec" binding")
>> >1103b85 ("mtd: m25p80: bind to "nor-jedec" ID, for auto-detection")
>> >we have "nor-jedec" binding indicating support for JEDEC identification.
>>
>> The documentation looks quite incomplete. "nor-jedec" sounds like
>> it's intended to be something generic. As such, it should be
>> documented in e.g.
>> Documentation/devicetree/bindings/mtd/nor-jedec.txt, not buried in
>> one particular flash device's binding. If it's not intended to be
>> generic, why isn't the existing "winbond,w25q32dw" enough?
>
> It is generic, though there are plenty of additional manufacturer/device
> pairs that could go on top of it. m25p80 was (one of?) the first
> supported, so the naming has been based on legacy, and we're in the
> process of unwinding a bit of that. If it helps, we could move the doc
> to .../mtd/spi-nor,nor-jedec.txt or something like that.
>
>> Equally, "nor-jedec" doesn't sound like the right name. It doesn't
>> differentiate between SPI and parallel NOR flash, which presumably
>> need different compatible values, since the programming model is
>> quite different, and the compatible value is supposed to
>> define/imply the SW-visible programming model.
>
> It's definitely for SPI only. There was much discussion about this a
> few months back. Somewhere along the way, it was mentioned that the
> context (SPI slave is a child of SPI master) would make this clear. I'm
> still not sure why we didn't end up with something more descriptive,
> though, like "spi-nor,nor-jedec".

What about "jedec,spi-nor"?

Is this "SERIAL FLASH DISCOVERABLE PARAMETERS (SFDP)"?
https://www.jedec.org/standards-documents/docs/jesd216b
(Don't have time to register with jedec now...)

If yes, "jedec,sfdp"? "jedec,jesd216b"?

> I'm open to change, as this binding is new in 4.1-rc1.

Indeed, as long as all users are fixed before 4.1 is released.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

[PATCH] ARM: tegra: add "nor-jedec" flash compatible binding

[Stephen Warren]

On 05/08/2015 02:57 PM, Geert Uytterhoeven wrote:
> On Fri, May 8, 2015 at 8:43 PM, Brian Norris
> <computersforpeace@gmail.com> wrote:
>> On Fri, May 08, 2015 at 10:00:12AM -0600, Stephen Warren wrote:
>>> On 05/08/2015 12:21 AM, Rafa? Mi?ecki wrote:
>>>> Starting with commits
>>>> 8ff16cf ("Documentation: devicetree: m25p80: add "nor-jedec" binding")
>>>> 1103b85 ("mtd: m25p80: bind to "nor-jedec" ID, for auto-detection")
>>>> we have "nor-jedec" binding indicating support for JEDEC identification.
>>>
>>> The documentation looks quite incomplete. "nor-jedec" sounds like
>>> it's intended to be something generic. As such, it should be
>>> documented in e.g.
>>> Documentation/devicetree/bindings/mtd/nor-jedec.txt, not buried in
>>> one particular flash device's binding. If it's not intended to be
>>> generic, why isn't the existing "winbond,w25q32dw" enough?
>>
>> It is generic, though there are plenty of additional manufacturer/device
>> pairs that could go on top of it. m25p80 was (one of?) the first
>> supported, so the naming has been based on legacy, and we're in the
>> process of unwinding a bit of that. If it helps, we could move the doc
>> to .../mtd/spi-nor,nor-jedec.txt or something like that.
>>
>>> Equally, "nor-jedec" doesn't sound like the right name. It doesn't
>>> differentiate between SPI and parallel NOR flash, which presumably
>>> need different compatible values, since the programming model is
>>> quite different, and the compatible value is supposed to
>>> define/imply the SW-visible programming model.
>>
>> It's definitely for SPI only. There was much discussion about this a
>> few months back. Somewhere along the way, it was mentioned that the
>> context (SPI slave is a child of SPI master) would make this clear. I'm
>> still not sure why we didn't end up with something more descriptive,
>> though, like "spi-nor,nor-jedec".
>
> What about "jedec,spi-nor"?

That seems unique enough to me, or the options below if they're actually 
applicable.

> Is this "SERIAL FLASH DISCOVERABLE PARAMETERS (SFDP)"?
> https://www.jedec.org/standards-documents/docs/jesd216b
> (Don't have time to register with jedec now...)
>
> If yes, "jedec,sfdp"? "jedec,jesd216b"?

[PATCH] ARM: tegra: add "nor-jedec" flash compatible binding

[Brian Norris]

On Fri, May 08, 2015 at 03:04:26PM -0600, Stephen Warren wrote:
> On 05/08/2015 02:57 PM, Geert Uytterhoeven wrote:
> >On Fri, May 8, 2015 at 8:43 PM, Brian Norris
> ><computersforpeace@gmail.com> wrote:
> >>On Fri, May 08, 2015 at 10:00:12AM -0600, Stephen Warren wrote:
> >>>On 05/08/2015 12:21 AM, Rafa? Mi?ecki wrote:
> >>>>Starting with commits
> >>>>8ff16cf ("Documentation: devicetree: m25p80: add "nor-jedec" binding")
> >>>>1103b85 ("mtd: m25p80: bind to "nor-jedec" ID, for auto-detection")
> >>>>we have "nor-jedec" binding indicating support for JEDEC identification.
> >>>
> >>>The documentation looks quite incomplete. "nor-jedec" sounds like
> >>>it's intended to be something generic. As such, it should be
> >>>documented in e.g.
> >>>Documentation/devicetree/bindings/mtd/nor-jedec.txt, not buried in
> >>>one particular flash device's binding. If it's not intended to be
> >>>generic, why isn't the existing "winbond,w25q32dw" enough?
> >>
> >>It is generic, though there are plenty of additional manufacturer/device
> >>pairs that could go on top of it. m25p80 was (one of?) the first
> >>supported, so the naming has been based on legacy, and we're in the
> >>process of unwinding a bit of that. If it helps, we could move the doc
> >>to .../mtd/spi-nor,nor-jedec.txt or something like that.
> >>
> >>>Equally, "nor-jedec" doesn't sound like the right name. It doesn't
> >>>differentiate between SPI and parallel NOR flash, which presumably
> >>>need different compatible values, since the programming model is
> >>>quite different, and the compatible value is supposed to
> >>>define/imply the SW-visible programming model.
> >>
> >>It's definitely for SPI only. There was much discussion about this a
> >>few months back. Somewhere along the way, it was mentioned that the
> >>context (SPI slave is a child of SPI master) would make this clear. I'm
> >>still not sure why we didn't end up with something more descriptive,
> >>though, like "spi-nor,nor-jedec".
> >
> >What about "jedec,spi-nor"?
> 
> That seems unique enough to me, or the options below if they're
> actually applicable.

That could be OK with me. If I can get the magic blessing from the DT
folks, then I'll send patches to update everything.

> >Is this "SERIAL FLASH DISCOVERABLE PARAMETERS (SFDP)"?
> >https://www.jedec.org/standards-documents/docs/jesd216b
> >(Don't have time to register with jedec now...)
> >
> >If yes, "jedec,sfdp"? "jedec,jesd216b"?

It's not SFDP. We're looking at SPI flash that are detected simply by
the READ ID (9Fh) opcode. SFDP is on newer SPI flash which support the
5Ah opcode, for reading a parameter table. (I'd like to support this
soon, actually, and one of those sorts of strings might work.)

Brian

[PATCH] ARM: tegra: add "nor-jedec" flash compatible binding

[Brian Norris]

Hi DT maintainers,

On Fri, May 08, 2015 at 02:34:14PM -0700, Brian Norris wrote:
> On Fri, May 08, 2015 at 03:04:26PM -0600, Stephen Warren wrote:
> > On 05/08/2015 02:57 PM, Geert Uytterhoeven wrote:
> > >On Fri, May 8, 2015 at 8:43 PM, Brian Norris <computersforpeace@gmail.com> wrote:
> > >>On Fri, May 08, 2015 at 10:00:12AM -0600, Stephen Warren wrote:
> > >>>Equally, "nor-jedec" doesn't sound like the right name. It doesn't
> > >>>differentiate between SPI and parallel NOR flash, which presumably
> > >>>need different compatible values, since the programming model is
> > >>>quite different, and the compatible value is supposed to
> > >>>define/imply the SW-visible programming model.
> > >>
> > >>It's definitely for SPI only. There was much discussion about this a
> > >>few months back. Somewhere along the way, it was mentioned that the
> > >>context (SPI slave is a child of SPI master) would make this clear. I'm
> > >>still not sure why we didn't end up with something more descriptive,
> > >>though, like "spi-nor,nor-jedec".
> > >
> > >What about "jedec,spi-nor"?
> > 
> > That seems unique enough to me, or the options below if they're
> > actually applicable.
> 
> That could be OK with me. If I can get the magic blessing from the DT
> folks, then I'll send patches to update everything.

Can I get an 'ack' for this change? We merged a binding for "nor-jedec"
in 4.1-rc1, with review (but no explicit 'ack') from Mark, and a few
DTS's are starting to use it. But we're now seeing objections, with a
request to change this to "jedec,spi-nor". I don't care too much, but I
can understand Stephen's point.

Anyway, I don't want to go through too many more patch cycles without an
explicit ack here on the "jedec,spi-nor" binding (i.e.,
s/nor-jedec/jedec,spi-nor/g). With an ack, then I can make sure the
binding and current users get changed before 4.1 is minted, and prevent
other ARM subarchitectures from pulling in the "wrong" binding for 4.2.

Brian