Thread (29 messages) 29 messages, 7 authors, 2017-01-24

[PATCH v1 2/2] arm: dts: mt2701: add nor flash node

From: robh@kernel.org (Rob Herring)
Date: 2017-01-19 02:51:38
Also in: linux-devicetree, linux-mediatek, lkml

On Wed, Jan 18, 2017 at 5:38 PM, Thomas Petazzoni
[off-list ref] wrote:
Hello,

On Wed, 18 Jan 2017 16:20:10 -0600, Rob Herring wrote:
quoted
quoted
quoted
Rob, Mark, any opinion?
Sigh, is how to do compatibles really not yet understood?
Well, it seems like not everyone necessarily understands what is the
best strategy to adopt (me included).
quoted
quoted
I agree that a clarification would be good. There are really two
options:

 1. Have two compatible strings in the DT, the one that matches the
    exact SoC where the IP is found (first compatible string) and the
    one that matches some other SoC where the same IP is found (second
    compatible string). Originally, Linux only supports the second
    compatible string in its device driver, but if it happens that a
    difference is found between two IPs that we thought were the same,
    we can add support for the first compatible string in the driver,
    with a slightly different behavior.
This. And no wildcards in the compatible string.
OK. So it means that today we do something like:

        compatible = "baz,foo-12", "baz,foo-00";

and support only baz,foo-00 in the driver. If tomorrow we discover
that there is in fact a difference between the two IP blocks, we can
add support for baz,foo-12 in the driver, and handle the differences.

But then, the DT still contains:

        compatible = "baz,foo-12", "baz,foo-00";

and therefore pretends that the IP block is compatible with
"baz,foo-00" which is in fact *not* the case. It was a mistake to
consider it as compatible. So we keep living with a DT that has
incorrect information.
I wouldn't say it's a mistake necessarily. The old compatible would
probably work to some extent. I'd assume it was tested to some level.
Or it could be other changes exposing a difference.
quoted
quoted
 2. Have a single compatible string in the DT, matching the exact SoC
    where the IP is found. This involves adding immediately this
    compatible string in the corresponding driver.
I wouldn't object to this from a DT perspective as I have no clue
generally if IP blocks are "the same" or not. Subsystem maintainers will
object though.
Knowing if IP blocks are "the same" is in fact not necessarily trivial.
What appears to be identical IP blocks today might be discovered later
as actually having subtle differences (sometimes not even visible in
the datasheet).
Yes, I know. That's exactly when you should have multiple compatibles.
Trying to guarantee things are the same is just going to get you in
trouble. You only need to figure out if blocks are obviously different
and only drop the old compatible in that case.
quoted
quoted
I've not really been able to figure out which of the two options is the
most future-proof/appropriate.
They are both future-proof. #2 has the disadvantage of requiring a
kernel update for a new SoC.
Which is generally anyway needed because a new SoC will almost always
require some new drivers, adjusting pin-muxing or clock drivers, etc.
Yes, but you don't want to have to update every single driver.

Rob
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help