On Thu 02 Apr 15:56 PDT 2020, Doug Anderson wrote:
> Hi,
>
> On Thu, Apr 2, 2020 at 3:37 PM John Stultz <john.stultz@xxxxxxxxxx> wrote:
> >
> > In commit 8fe75cd4cddf ("phy: qcom-qusb2: Add generic QUSB2 V2
> > PHY support"), the change was made to add "qcom,qusb2-v2-phy"
> > as a generic compat string. However the change also removed
> > the "qcom,sdm845-qusb2-phy" compat string, which is documented
> > in the binding and already in use.
> >
> > This patch re-adds the "qcom,sdm845-qusb2-phy" compat string
> > which allows the driver to continue to work with existing dts
> > entries such as found on the db845c.
> >
> > Cc: Andy Gross <agross@xxxxxxxxxx>
> > Cc: Bjorn Andersson <bjorn.andersson@xxxxxxxxxx>
> > Cc: Rob Herring <robh+dt@xxxxxxxxxx>
> > Cc: Mark Rutland <mark.rutland@xxxxxxx>
> > Cc: Doug Anderson <dianders@xxxxxxxxxxxx>
> > Cc: Manu Gautam <mgautam@xxxxxxxxxxxxxx>
> > Cc: Sandeep Maheswaram <sanm@xxxxxxxxxxxxxx>
> > Cc: Matthias Kaehlcke <mka@xxxxxxxxxxxx>
> > Cc: Stephen Boyd <swboyd@xxxxxxxxxxxx>
> > Cc: Kishon Vijay Abraham I <kishon@xxxxxx>
> > Cc: linux-arm-msm@xxxxxxxxxxxxxxx
> > Cc: devicetree@xxxxxxxxxxxxxxx
> > Fixes: 8fe75cd4cddf ("phy: qcom-qusb2: Add generic QUSB2 V2 PHY support")
> > Reported-by: YongQin Liu <yongqin.liu@xxxxxxxxxx>
> > Signed-off-by: John Stultz <john.stultz@xxxxxxxxxx>
> > ---
> > drivers/phy/qualcomm/phy-qcom-qusb2.c | 3 +++
> > 1 file changed, 3 insertions(+)
>
> Do you have an out-of-tree dts file? If not, I'd prefer that the fix
> was for this patch to land instead:
>
> https://lore.kernel.org/r/1583747589-17267-9-git-send-email-sanm@xxxxxxxxxxxxxx
>
> While we can land your patch if someone needs it for supporting an
> out-of-tree dts, it gives people supporting future SoCs the idea that
> they need to add themselves to this table too. That's now discouraged
> unless there's a specific quirk that needs to be handled just for this
> SoC.
>
Afaict the compatible has been in use in the upstream sdm845.dtsi since
v4.20 and we do have an outspoken rule that we don't break backwards
compatibility with existing DTBs.
There are cases where it makes sense to break this rule, e.g. to fix
something that's clearly broken, but I don't see that this is such a
case.
Regards,
Bjorn
