Stephen On Fri, Sep 21, 2018 at 11:40 AM Stephen Boyd <swboyd@xxxxxxxxxxxx> wrote: > > Quoting Doug Anderson (2018-09-21 10:40:14) > > Hi, > > > > On Fri, Sep 21, 2018 at 10:31 AM Stephen Boyd <swboyd@xxxxxxxxxxxx> wrote: > > > > > > Quoting Ryan Case (2018-09-20 15:40:54) > > > > diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.txt b/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.txt > > > > new file mode 100644 > > > > index 000000000000..ecfb1e2bd520 > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.txt > > > > @@ -0,0 +1,36 @@ > > > > +Qualcomm Quad Serial Peripheral Interface (QSPI) > > > > + > > > > +The QSPI controller allows SPI protocol communication in single, dual, or quad > > > > +wire transmission modes for read/write access to slaves such as NOR flash. > > > > + > > > > +Required properties: > > > > +- compatible: Should contain: > > > > + "qcom,sdm845-qspi" > > > > > > Does someone have a more generic compatible string that can be added > > > here to indicate the type of quad SPI controller this is? I really doubt > > > this is a one-off hardware block for the specific SDM845 SoC. > > > > The compatible string used to be "qcom,qspi-v1". ...but Rob Herring > > requested [1] "an SoC specific compatible string". While we could do > > a compatible string like: > > > > "qcom,sdm845-qspi", "qcom,qspi-v1". > > > > I'm curious if that buys us anything. From all my previous experience > > with device tree it is fine to name a compatible string for a > > component based on the first SoC that used it. If we later find that > > this is also used in an "msm1234" we could always later do the > > compatible string for that device as: > > > > "qcom, msm1234-qspi", "qcom,sdm845-qspi" > > > > ...and we don't need to try to come up with a generic name. > > Obviously, though, I'll cede to whatever Rob says here though. > > > > It seems that everybody has misunderstood my email. Let me try to > clarify. > > I'm not saying to replace the sdm845 qspi compatible with a generic one. > I'm recommending that a generic one is added in addition to the SoC > specific one. That way, we get to put the generic compatible string in > the driver and not need to update the driver compatible string array > each time a new SoC comes out with a new compatible string. > > If it turns out later that we need to handle some bug in that specific > SoC compatible string then we're good to go and we can handle it by > matching the more specific SoC version compatible. I don't think I misunderstood. I was suggesting that I believe that the device tree way is to use the first SoC as the generic one. In other words to support sdm845 and msm1234, we do: A) on sdm845: "qcom,sdm845-qspi" on msm1234 (later): "qcom, msm1234-qspi", "qcom,sdm845-qspi" What you are suggesting (I think) is: B) on sdm845: "qcom,sdm845-qspi", "qcom,qspi-v1" on msm1234 (later): "qcom, msm1234-qspi", "qcom,qspi-v1" If Rob likes B) better then it's fine with me, it was just my understanding that A) was the suggested way to do things (even if it is decidedly non-symmetric). NOTE: Even with A) there's no need to update the driver for msm1234 since it has the fallback to sdm845. -Doug
