eeprom: at24: device tree support fixes

Current description of the compatible property for at24 is quite vague.

Specify an exact list of accepted compatibles and document the - now deprecated - strings which were previously used in device tree files.

+ will still work, but are now deprecated.

Current description of the compatible property for at24 is quite vague.

Specify an exact list of accepted compatibles and document the - now deprecated - strings which were previously used in device tree files.

Quoted 4 lines · Bartosz Golaszewski

Current description of the compatible property for at24 is quite vague.

Specify an exact list of accepted compatibles and document the - now deprecated - strings which were previously used in device tree files.

Why is it suddenly deprecated to correctly specify what hardware you have, e.g. "nxp,24c32". In this case the manufacturer is nxp, damnit. Sure, it happens to be compatible with "atmel,24c32", but that is supposed to be written with a fallback as

	"nxp,24c32", "atmel,24c32"

if I understand correctly. So, why is that deprecated in this case?

What if (a few years down the line) it is discovered that some weird quirk is needed that is only appropriate for nxp chips?

nxp is of course just an example, pick any manufacturer of eeproms (supposedly) compatible with the atmel interface.

Also, at,24c08 is listed in Documentation/devicetree/bindings/trivial-devices.txt. It should probably be removed.

Quoted 4 lines · Bartosz Golaszewski

Current description of the compatible property for at24 is quite vague.

Specify an exact list of accepted compatibles and document the - now deprecated - strings which were previously used in device tree files.

Why is it suddenly deprecated to correctly specify what hardware you have, e.g. "nxp,24c32". In this case the manufacturer is nxp, damnit.

Sure, it happens to be compatible with "atmel,24c32", but that is supposed to be written with a fallback as

        "nxp,24c32", "atmel,24c32"

if I understand correctly. So, why is that deprecated in this case?

What if (a few years down the line) it is discovered that some weird quirk is needed that is only appropriate for nxp chips?

nxp is of course just an example, pick any manufacturer of eeproms (supposedly) compatible with the atmel interface.

Cheers,
Peter

Hello Peter,

Quoted 6 lines · Peter Rosin

Quoted 4 lines · Bartosz Golaszewski

Current description of the compatible property for at24 is quite vague.

Specify an exact list of accepted compatibles and document the - now deprecated - strings which were previously used in device tree files.

Quoted 2 lines

Why is it suddenly deprecated to correctly specify what hardware you have, e.g. "nxp,24c32". In this case the manufacturer is nxp, damnit.

Sorry but I disagree.

When you specify a compatible string, you are not specifying a particular hardware but a device programming model.

It's very common to use a compatible string that doesn't match exactly the specific hardware used. That's why it's called _compatible_ BTW.

For example when a DTS define a UART node with an ns16550 compatible, they don't really mean that have a UART IC manufactured by National Semiconductor.

Quoted 4 lines

Sure, it happens to be compatible with "atmel,24c32", but that is supposed to be written with a fallback as

        "nxp,24c32", "atmel,24c32"

This isn't a requirement really, systems integrators are free to use more than one <manufacturer,model> tuple in the compatible string if they want the DTB to be future proof, just in case there's a need for a more specific driver or if the programming model happened to not be the same at the end. This is usually done for the boards compatible string as an example, even when there isn't a struct machine_desc for the specific board compatible and only for the SoC family.

So it's OK if you want to define the compatible as "nxp,24c32", "atmel,24c32", but that's a general OF concept and not something related to the at24 eeprom driver so I'm not sure if it should be mentioned in the at24 DT binding doc.

Quoted 8 lines

if I understand correctly. So, why is that deprecated in this case?

What if (a few years down the line) it is discovered that some weird quirk is needed that is only appropriate for nxp chips?

nxp is of course just an example, pick any manufacturer of eeproms (supposedly) compatible with the atmel interface.

That's indeed a possibility and the reason why most DT nodes have a more specific <manufacturer,model> before the generic one matched by drivers. I really doubt that in the future it will be found that a more specific compatible string is needed for one manufacturer in this case, specially since the driver didn't even care about the manufacturers until recently.

So I think that makes no sense for a driver to support all possible manufacturers as possible compatible strings if all the devices have the same exact programming model.

Quoted 12 lines · Javier Martinez Canillas

Hello Peter,

Quoted 8 lines · Peter Rosin

Quoted 4 lines · Bartosz Golaszewski

Current description of the compatible property for at24 is quite vague.

Specify an exact list of accepted compatibles and document the - now deprecated - strings which were previously used in device tree files.

Why is it suddenly deprecated to correctly specify what hardware you have, e.g. "nxp,24c32". In this case the manufacturer is nxp, damnit.

Quoted 4 lines

Sorry but I disagree.

When you specify a compatible string, you are not specifying a particular hardware but a device programming model.

That's not what it says in https://elinux.org/Device_Tree_Usage

in the "Understanding the compatible Property" section. I quote:

compatible is a list of strings. The first string in the list specifies the exact device that the node represents in the form "<manufacturer>,<model>". The following strings represent other devices that the device is compatible with.

Pretty clearly talks about devices and not programming models. But maybe I shouldn't trust that reference? What should I be reading instead?

Quoted 2 lines

It's very common to use a compatible string that doesn't match exactly the specific hardware used. That's why it's called _compatible_ BTW.

That's not how I read the above.

Quoted 3 lines

For example when a DTS define a UART node with an ns16550 compatible, they don't really mean that have a UART IC manufactured by National Semiconductor.

That just tells me that most people are a little bit lazy and ready to cut a corner or two when they can get away with it. Or that there is some form of misunderstanding at work...

Quoted 13 lines

Quoted 4 lines

Sure, it happens to be compatible with "atmel,24c32", but that is supposed to be written with a fallback as

        "nxp,24c32", "atmel,24c32"

This isn't a requirement really, systems integrators are free to use more than one <manufacturer,model> tuple in the compatible string if they want the DTB to be future proof, just in case there's a need for a more specific driver or if the programming model happened to not be the same at the end. This is usually done for the boards compatible string as an example, even when there isn't a struct machine_desc for the specific board compatible and only for the SoC family.

Quoted 4 lines

So it's OK if you want to define the compatible as "nxp,24c32", "atmel,24c32", but that's a general OF concept and not something related to the at24 eeprom driver so I'm not sure if it should be mentioned in the at24 DT binding doc.

One problem is that if "nxp,24c32" (or "nxp,24c02" as in the example below) is not a valid compatible, the tooling will be correct to complain about it. Currently, it is just a checkpatch deficiency that it complains like this:

$ scripts/checkpatch.pl -f arch/arm/boot/dts/at91-tse850-3.dts
WARNING: DT compatible string "nxp,24c02" appears un-documented -- check ./Documentation/devicetree/bindings/
#249: FILE: arch/arm/boot/dts/at91-tse850-3.dts:249:
+               compatible = "nxp,24c02", "atmel,24c02";

Quoted 9 lines

Quoted 8 lines

if I understand correctly. So, why is that deprecated in this case?

What if (a few years down the line) it is discovered that some weird quirk is needed that is only appropriate for nxp chips?

nxp is of course just an example, pick any manufacturer of eeproms (supposedly) compatible with the atmel interface.

Quoted 6 lines

That's indeed a possibility and the reason why most DT nodes have a more specific <manufacturer,model> before the generic one matched by drivers. I really doubt that in the future it will be found that a more specific compatible string is needed for one manufacturer in this case, specially since the driver didn't even care about the manufacturers until recently.

I'm not talking about the driver. But if what you say is true, that change would have broken a number of existing DTBs. Is that really the case?

Quoted 3 lines

So I think that makes no sense for a driver to support all possible manufacturers as possible compatible strings if all the devices have the same exact programming model.

That's what the fallback is for. With that in place the driver can start to care when there is a need but until then it can work just as it always has. Without knowing the specific device, the driver has less chance to adapt when the unexpected is discovered. But again, I'm not really discussing driver details, I'm complaining about the proposed changes to the bindings. I simply don't see how they make sense.

Cheers,
Peter

Hello Peter,

Quoted 13 lines · Peter Rosin

Quoted 12 lines · Javier Martinez Canillas

Hello Peter,

Quoted 8 lines · Peter Rosin

Quoted 4 lines · Bartosz Golaszewski

Current description of the compatible property for at24 is quite vague.

Specify an exact list of accepted compatibles and document the - now deprecated - strings which were previously used in device tree files.

Why is it suddenly deprecated to correctly specify what hardware you have, e.g. "nxp,24c32". In this case the manufacturer is nxp, damnit.

Quoted 6 lines

Quoted 4 lines

Sorry but I disagree.

When you specify a compatible string, you are not specifying a particular hardware but a device programming model.

That's not what it says in https://elinux.org/Device_Tree_Usage

I think the most up-to-date DT reference is at:

https://www.devicetree.org/

Quoted 11 lines

in the "Understanding the compatible Property" section. I quote:

compatible is a list of strings. The first string in the list specifies the exact device that the node represents in the form "<manufacturer>,<model>". The following strings represent other devices that the device is compatible with.

Pretty clearly talks about devices and not programming models. But maybe I shouldn't trust that reference? What should I be reading instead?

For example the latest spec draft
(https://github.com/devicetree-org/devicetree-specification/releases/download/v0.2-rc1/devicetree-specification-v0.2-rc1.pdf)
says:

"The compatible property value consists of one or more strings that define the specific programming model for the device. This list of strings should be used by a client program for device driver selection. The property value consists of a concatenated list of null terminated strings, from most specific to most general. They allow a device to express its compatibility with a family of similar devices, potentially allowing a single device driver to match against several devices."

The recommended format is "manufacturer,model", where manufacturer is a string describing the name of the manufacturer (such as a stock ticker symbol), and model specifies the model number."

Example:

compatible = "fsl,mpc8641", "ns16550";

In this example, an operating system would first try to locate a device driver that supported fsl,mpc8641. If a driver was not found, it would then try to locate a driver that supported the more general ns16550 device type."

Quoted 5 lines

Quoted 2 lines

It's very common to use a compatible string that doesn't match exactly the specific hardware used. That's why it's called _compatible_ BTW.

That's not how I read the above.

That's not how I read it nor my experience with DT, but of course I may be wrong on this.

Quoted 8 lines

Quoted 3 lines

For example when a DTS define a UART node with an ns16550 compatible, they don't really mean that have a UART IC manufactured by National Semiconductor.

That just tells me that most people are a little bit lazy and ready to cut a corner or two when they can get away with it. Or that there is some form of misunderstanding at work...

For example, I usually see that different SoC families from the same vendor use the same compatible string for integrated peripherals just because are the same from a programming model point of view.

TI am33xx SoCs use a lot of omap3 compatible strings on their nodes and its similar on Exynos SoCs which are the two ARM SoCs I'm most familiar with. Following your logic that's wrong and instead a new compatible string should be added for the GPIO or pinctrl drivers even when are the same because refer to different devices.

Quoted 23 lines

Quoted 13 lines

Quoted 4 lines

Sure, it happens to be compatible with "atmel,24c32", but that is supposed to be written with a fallback as

        "nxp,24c32", "atmel,24c32"

This isn't a requirement really, systems integrators are free to use more than one <manufacturer,model> tuple in the compatible string if they want the DTB to be future proof, just in case there's a need for a more specific driver or if the programming model happened to not be the same at the end. This is usually done for the boards compatible string as an example, even when there isn't a struct machine_desc for the specific board compatible and only for the SoC family.

Quoted 4 lines

So it's OK if you want to define the compatible as "nxp,24c32", "atmel,24c32", but that's a general OF concept and not something related to the at24 eeprom driver so I'm not sure if it should be mentioned in the at24 DT binding doc.

One problem is that if "nxp,24c32" (or "nxp,24c02" as in the example below) is not a valid compatible, the tooling will be correct to complain about it. Currently, it is just a checkpatch deficiency that it complains like this:

Quoted 5 lines

$ scripts/checkpatch.pl -f arch/arm/boot/dts/at91-tse850-3.dts
WARNING: DT compatible string "nxp,24c02" appears un-documented -- check ./Documentation/devicetree/bindings/
#249: FILE: arch/arm/boot/dts/at91-tse850-3.dts:249:
+               compatible = "nxp,24c02", "atmel,24c02";

But isn't that a bug in checkpatch? as long as there's a valid <manufacturer,model> tuple in the compatible string, it shouldn't complain.

Quoted 16 lines

Quoted 15 lines

Quoted 8 lines

if I understand correctly. So, why is that deprecated in this case?

What if (a few years down the line) it is discovered that some weird quirk is needed that is only appropriate for nxp chips?

nxp is of course just an example, pick any manufacturer of eeproms (supposedly) compatible with the atmel interface.

That's indeed a possibility and the reason why most DT nodes have a more specific <manufacturer,model> before the generic one matched by drivers. I really doubt that in the future it will be found that a more specific compatible string is needed for one manufacturer in this case, specially since the driver didn't even care about the manufacturers until recently.

Quoted 4 lines

I'm not talking about the driver. But if what you say is true, that change would have broken a number of existing DTBs. Is that really the case?

Sorry, I didn't get which change you meant.

Quoted 4 lines

Quoted 3 lines

So I think that makes no sense for a driver to support all possible manufacturers as possible compatible strings if all the devices have the same exact programming model.

Quoted 8 lines

That's what the fallback is for. With that in place the driver can start to care when there is a need but until then it can work just as it always has. Without knowing the specific device, the driver has less chance to adapt when the unexpected is discovered. But again, I'm not really discussing driver details, I'm complaining about the proposed changes to the bindings. I simply don't see how they make sense.

My point is that saying in a DT binding that you could have a more specific <manufacturer,model> followed by a generic one is redundant. That's already something one can do to make the DT future proof and latter if is found that the more specific pair is needed, then compatible can be added to the OF device ID table making the driver to match that an the <manufacturer,model> added to the DT binding making it formal.

That's my understanding at least, but I could be completely wrong too since I'm not a DT expert.

Quoted 56 lines · Javier Martinez Canillas

Hello Peter,

Quoted 13 lines · Peter Rosin

Quoted 12 lines · Javier Martinez Canillas

Hello Peter,

Quoted 8 lines · Peter Rosin

Quoted 4 lines · Bartosz Golaszewski

Current description of the compatible property for at24 is quite vague.

Specify an exact list of accepted compatibles and document the - now deprecated - strings which were previously used in device tree files.

Why is it suddenly deprecated to correctly specify what hardware you have, e.g. "nxp,24c32". In this case the manufacturer is nxp, damnit.

Quoted 6 lines

Quoted 4 lines

Sorry but I disagree.

When you specify a compatible string, you are not specifying a particular hardware but a device programming model.

That's not what it says in https://elinux.org/Device_Tree_Usage

I think the most up-to-date DT reference is at:

https://www.devicetree.org/

Quoted 11 lines

in the "Understanding the compatible Property" section. I quote:

compatible is a list of strings. The first string in the list specifies the exact device that the node represents in the form "<manufacturer>,<model>". The following strings represent other devices that the device is compatible with.

Pretty clearly talks about devices and not programming models. But maybe I shouldn't trust that reference? What should I be reading instead?

For example the latest spec draft
(https://github.com/devicetree-org/devicetree-specification/releases/download/v0.2-rc1/devicetree-specification-v0.2-rc1.pdf)
says:

"The compatible property value consists of one or more strings that define the specific programming model for the device. This list of strings should be used by a client program for device driver selection. The property value consists of a concatenated list of null terminated strings, from most specific to most general. They allow a device to express its compatibility with a family of similar devices, potentially allowing a single device driver to match against several devices."

The recommended format is "manufacturer,model", where manufacturer is a string describing the name of the manufacturer (such as a stock ticker symbol), and model specifies the model number."

Quoted 8 lines

Example:

compatible = "fsl,mpc8641", "ns16550";

In this example, an operating system would first try to locate a device driver that supported fsl,mpc8641. If a driver was not found, it would then try to locate a driver that supported the more general ns16550 device type."

Yes, that's a bit different from the wording on the elinux site. Thanks for the pointer! Google was not my friend on this occasion, since I managed to miss that site in my searches. Maybe it has gotten a higher rank now that 0.2 is out, because now I find it easily?

Quoted 6 lines

Quoted 5 lines

Quoted 2 lines

It's very common to use a compatible string that doesn't match exactly the specific hardware used. That's why it's called _compatible_ BTW.

That's not how I read the above.

Quoted 2 lines

That's not how I read it nor my experience with DT, but of course I may be wrong on this.

Either way, it should not be wrong to specify the more specific binding before the generic fallback, as is done in the at91-tse850-3.dts example I gave below.

Quoted 13 lines

Quoted 8 lines

Quoted 3 lines

For example when a DTS define a UART node with an ns16550 compatible, they don't really mean that have a UART IC manufactured by National Semiconductor.

That just tells me that most people are a little bit lazy and ready to cut a corner or two when they can get away with it. Or that there is some form of misunderstanding at work...

For example, I usually see that different SoC families from the same vendor use the same compatible string for integrated peripherals just because are the same from a programming model point of view.

Quoted 5 lines

TI am33xx SoCs use a lot of omap3 compatible strings on their nodes and its similar on Exynos SoCs which are the two ARM SoCs I'm most familiar with. Following your logic that's wrong and instead a new compatible string should be added for the GPIO or pinctrl drivers even when are the same because refer to different devices.

Considering the above quote from the actual DT spec, I wouldn't say wrong. But I'd still say that it should be preferred to list the actual device before the fallback to some generic programming model compatible or some previous version of the hardware/IP-block. Just in case an unintended difference is discovered late in the game...

Quoted 30 lines

Quoted 29 lines

Quoted 14 lines

Quoted 5 lines

Sure, it happens to be compatible with "atmel,24c32", but that is supposed to be written with a fallback as

        "nxp,24c32", "atmel,24c32"

This isn't a requirement really, systems integrators are free to use more than one <manufacturer,model> tuple in the compatible string if they want the DTB to be future proof, just in case there's a need for a more specific driver or if the programming model happened to not be the same at the end. This is usually done for the boards compatible string as an example, even when there isn't a struct machine_desc for the specific board compatible and only for the SoC family.

Quoted 4 lines

So it's OK if you want to define the compatible as "nxp,24c32", "atmel,24c32", but that's a general OF concept and not something related to the at24 eeprom driver so I'm not sure if it should be mentioned in the at24 DT binding doc.

One problem is that if "nxp,24c32" (or "nxp,24c02" as in the example below) is not a valid compatible, the tooling will be correct to complain about it. Currently, it is just a checkpatch deficiency that it complains like this:

$ scripts/checkpatch.pl -f arch/arm/boot/dts/at91-tse850-3.dts
WARNING: DT compatible string "nxp,24c02" appears un-documented -- check ./Documentation/devicetree/bindings/
#249: FILE: arch/arm/boot/dts/at91-tse850-3.dts:249:
+               compatible = "nxp,24c02", "atmel,24c02";

Quoted 3 lines

But isn't that a bug in checkpatch? as long as there's a valid <manufacturer,model> tuple in the compatible string, it shouldn't complain.

Then there is a significant risk that speeling mistakes are not caught. So, I don't think it will be considered a bug unless a DT guru says so of course. I think the checkpatch intention is to catch all undocumented compatibles. But I don't know of course...

Quoted 66 lines · Javier Martinez Canillas

Quoted 56 lines

Hello Peter,

Quoted 13 lines · Peter Rosin

Quoted 12 lines · Javier Martinez Canillas

Hello Peter,

Quoted 8 lines · Peter Rosin

Quoted 4 lines · Bartosz Golaszewski

Current description of the compatible property for at24 is quite vague.

Specify an exact list of accepted compatibles and document the - now deprecated - strings which were previously used in device tree files.

Why is it suddenly deprecated to correctly specify what hardware you have, e.g. "nxp,24c32". In this case the manufacturer is nxp, damnit.

Quoted 6 lines

Quoted 4 lines

Sorry but I disagree.

When you specify a compatible string, you are not specifying a particular hardware but a device programming model.

That's not what it says in https://elinux.org/Device_Tree_Usage

I think the most up-to-date DT reference is at:

https://www.devicetree.org/

Quoted 11 lines

in the "Understanding the compatible Property" section. I quote:

compatible is a list of strings. The first string in the list specifies the exact device that the node represents in the form "<manufacturer>,<model>". The following strings represent other devices that the device is compatible with.

Pretty clearly talks about devices and not programming models. But maybe I shouldn't trust that reference? What should I be reading instead?

For example the latest spec draft
(https://github.com/devicetree-org/devicetree-specification/releases/download/v0.2-rc1/devicetree-specification-v0.2-rc1.pdf)
says:

"The compatible property value consists of one or more strings that define the specific programming model for the device. This list of strings should be used by a client program for device driver selection. The property value consists of a concatenated list of null terminated strings, from most specific to most general. They allow a device to express its compatibility with a family of similar devices, potentially allowing a single device driver to match against several devices."

The recommended format is "manufacturer,model", where manufacturer is a string describing the name of the manufacturer (such as a stock ticker symbol), and model specifies the model number."

Quoted 8 lines

Example:

compatible = "fsl,mpc8641", "ns16550";

In this example, an operating system would first try to locate a device driver that supported fsl,mpc8641. If a driver was not found, it would then try to locate a driver that supported the more general ns16550 device type."

Quoted 4 lines

Yes, that's a bit different from the wording on the elinux site. Thanks for the pointer! Google was not my friend on this occasion, since I managed to miss that site in my searches. Maybe it has gotten a higher rank now that 0.2 is out, because now I find it easily?

The wording may be different, but both (and Peter) are correct.

And ns16550 is a perfect example of why that string alone is not sufficient. Just go count the number of variants and quirks in the kernel 8250 driver.

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

Quoted 2 lines

It's very common to use a compatible string that doesn't match exactly the specific hardware used. That's why it's called _compatible_ BTW.

That's not how I read the above.

Quoted 6 lines

Quoted 2 lines

That's not how I read it nor my experience with DT, but of course I may be wrong on this.

Either way, it should not be wrong to specify the more specific binding before the generic fallback, as is done in the at91-tse850-3.dts example I gave below.

Indeed. I don't think I've ever said anyone is being too specific.

Quoted 19 lines

Quoted 13 lines

Quoted 8 lines

Quoted 3 lines

For example when a DTS define a UART node with an ns16550 compatible, they don't really mean that have a UART IC manufactured by National Semiconductor.

That just tells me that most people are a little bit lazy and ready to cut a corner or two when they can get away with it. Or that there is some form of misunderstanding at work...

For example, I usually see that different SoC families from the same vendor use the same compatible string for integrated peripherals just because are the same from a programming model point of view.

Quoted 5 lines

TI am33xx SoCs use a lot of omap3 compatible strings on their nodes and its similar on Exynos SoCs which are the two ARM SoCs I'm most familiar with. Following your logic that's wrong and instead a new compatible string should be added for the GPIO or pinctrl drivers even when are the same because refer to different devices.

Quoted 5 lines

Considering the above quote from the actual DT spec, I wouldn't say wrong. But I'd still say that it should be preferred to list the actual device before the fallback to some generic programming model compatible or some previous version of the hardware/IP-block. Just in case an unintended difference is discovered late in the game...

Let me clear, "generic" compatibles alone are wrong.

Quoted 30 lines

Quoted 30 lines

Quoted 29 lines

Quoted 14 lines

Quoted 5 lines

Sure, it happens to be compatible with "atmel,24c32", but that is supposed to be written with a fallback as

        "nxp,24c32", "atmel,24c32"

This isn't a requirement really, systems integrators are free to use more than one <manufacturer,model> tuple in the compatible string if they want the DTB to be future proof, just in case there's a need for a more specific driver or if the programming model happened to not be the same at the end. This is usually done for the boards compatible string as an example, even when there isn't a struct machine_desc for the specific board compatible and only for the SoC family.

Quoted 4 lines

So it's OK if you want to define the compatible as "nxp,24c32", "atmel,24c32", but that's a general OF concept and not something related to the at24 eeprom driver so I'm not sure if it should be mentioned in the at24 DT binding doc.

One problem is that if "nxp,24c32" (or "nxp,24c02" as in the example below) is not a valid compatible, the tooling will be correct to complain about it. Currently, it is just a checkpatch deficiency that it complains like this:

$ scripts/checkpatch.pl -f arch/arm/boot/dts/at91-tse850-3.dts
WARNING: DT compatible string "nxp,24c02" appears un-documented -- check ./Documentation/devicetree/bindings/
#249: FILE: arch/arm/boot/dts/at91-tse850-3.dts:249:
+               compatible = "nxp,24c02", "atmel,24c02";

Quoted 8 lines

Quoted 3 lines

But isn't that a bug in checkpatch? as long as there's a valid <manufacturer,model> tuple in the compatible string, it shouldn't complain.

Then there is a significant risk that speeling mistakes are not caught. So, I don't think it will be considered a bug unless a DT guru says so of course. I think the checkpatch intention is to catch all undocumented compatibles. But I don't know of course...

checkpatch.pl is just plain stupid. Who wrote that check anyway? Because bindings are not machine parseable, compatible string checks are pretty much just a grep for the string in all binding docs. So "The" or "compatible" would be valid compatible strings for checkpatch.pl.

If you want to quiet checkpatch.pl, I'd suggest documenting compatible strings as "<vendor>,foo" and having checkpatch match any string for <vendor>. We already handle vendor,<soc>-block type compatible descriptions.

Rob

"atmel,spd" is reported by checkpatch as undocumented in the device tree bindings. Add it to the list of supported compatible strings.

         "atmel,24c00",
         "atmel,24c01",
         "atmel,24c02",
+        "atmel,spd",
         "atmel,24c04",
         "atmel,24c08",
         "atmel,24c16",

Quoted 10 lines

"atmel,spd" is reported by checkpatch as undocumented in the device tree bindings. Add it to the list of supported compatible strings.

         "atmel,24c00",
         "atmel,24c01",
         "atmel,24c02",
+        "atmel,spd",
         "atmel,24c04",
         "atmel,24c08",
         "atmel,24c16",

Sounds alogical to me to make a split by this new record. Can you find better line to inject?

--
With Best Regards,
Andy Shevchenko

2017-12-21 15:08 GMT+01:00 Andy Shevchenko <[email protected]>:

Quoted 12 lines · Bartosz Golaszewski

Quoted 10 lines

"atmel,spd" is reported by checkpatch as undocumented in the device tree bindings. Add it to the list of supported compatible strings.

         "atmel,24c00",
         "atmel,24c01",
         "atmel,24c02",
+        "atmel,spd",
         "atmel,24c04",
         "atmel,24c08",
         "atmel,24c16",

Quoted 2 lines

Sounds alogical to me to make a split by this new record. Can you find better line to inject?

They are actually ordered by memory size. I want to keep it like this in the driver and I prefer that the DT reflect it.

Quoted 13 lines

2017-12-21 15:08 GMT+01:00 Andy Shevchenko <[email protected]>:

Quoted 12 lines · Bartosz Golaszewski

Quoted 10 lines

"atmel,spd" is reported by checkpatch as undocumented in the device tree bindings. Add it to the list of supported compatible strings.

         "atmel,24c00",
         "atmel,24c01",
         "atmel,24c02",
+        "atmel,spd",
         "atmel,24c04",
         "atmel,24c08",
         "atmel,24c16",

Quoted 5 lines

Quoted 2 lines

Sounds alogical to me to make a split by this new record. Can you find better line to inject?

They are actually ordered by memory size. I want to keep it like this in the driver and I prefer that the DT reflect it.

So, I just disagree on the above. Rationale I described at one of the comment.

At the end it's your call, but from my p.o.v. it makes life harder to read and catch the chips which are (un)supported.

--
With Best Regards,
Andy Shevchenko

Add other variants of at24 EEPROMs we support in the driver to the list of allowed compatible strings.

         "atmel,24c00",
         "atmel,24c01",

Documentation/devicetree/bindings/eeprom/at24.txt +2 -0

+        "atmel,24cs01",
         "atmel,24c02",
+        "atmel,24cs02",

Add all supported at24 variants to the of_match table.

Signed-off-by Bartosz Golaszewski <brgl-ARrdPY/[email protected]>

Reviewed-by Javier Martinez Canillas <[email protected]>