Quoting Mark Brown (2018-09-21 11:51:06) > On Fri, Sep 21, 2018 at 11:40:24AM -0700, Stephen Boyd wrote: > > > 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. > > Right, the policy is generally not to have these strings at all. IIRC > the argument is that they tend to either become unclear as the marketing > and technology changes. Where is this policy documented? Is it on the list somewhere or written in Documentation/devicetree/? From my read of Rob's comment in the previous version of this patch, all that was asked was to add another compatible string for the specific SoC. I find the approach of picking the first SoC that the driver works on to be obtuse. I don't want to be reading some SoC DTS and see another SoC marketing number in the compatible string because it makes it confusing to explain to someone that yes these different SoCs are related to each other, but no, that SoC isn't this SoC. Sure it all works and everything is technically fine, but my aesthetically pleasing alarms go off and I don't see any particular downside to having two compatibles. The upside is that things aren't confusing and drivers don't get continual SoC churn updates because the compatible describes the SoC (qcom,sdm845-qspi) and the programming model (qcom,qspi-v1).
