[PATCH v3 2/4] arm64: dts: correct vendor prefix hisi to hisilicon

[Arnd Bergmann]

On Wed, Jan 27, 2021 at 1:42 AM Wei Xu <xuwei5 at hisilicon.com> wrote:
> On 2021/1/27 6:23, Arnd Bergmann wrote:
> > On Tue, Dec 8, 2020 at 1:46 PM Zhen Lei <thunder.leizhen at huawei.com> wrote:
> >>
> >> The vendor prefix of "Hisilicon Limited" is "hisilicon", it is clearly
> >> stated in "vendor-prefixes.yaml".
> >>
> >> Fixes: 35ca8168133c ("arm64: dts: Add dts files for Hisilicon Hi3660 SoC")
> >> Fixes: dd8c7b78c11b ("arm64: dts: Add devicetree for Hisilicon Hi3670 SoC")
> >> Signed-off-by: Zhen Lei <thunder.leizhen at huawei.com>
> >> Cc: Chen Feng <puck.chen at hisilicon.com>
> >> Cc: Manivannan Sadhasivam <manivannan.sadhasivam at linaro.org>
> >
> > I see this change in the pull request I got, but I'm a bit worried about the
> > incompatible binding change. Wouldn't the correct path forward be to
> > list both the correct and the incorrect properties, both in the dts file
> > and in the driver that interprets the properties?
>
> Thanks for the comment!
> The reset driver will look for "hisilicon" firstly and fall back to "hisi".
> And the DTS is shipped with the driver together.
> So I think there is no compatible issue here.
> Please let me know if missed anything. Thanks!

There are three things that can go wrong here, and this is only addressing
one of them:

1. Updating the kernel on a machine with a dtb provided by the firmware
  is a problem if the new driver can not handle the old properties. This
  is correctly handled by the driver's fallback as soon as both trees
  are merged.

2. Updating the dtb while running an older kernel is now broken since
  the driver can no longer read the property. This is less critical, but
  it does seem easy enough to work around here by leaving both
  properties in place.

3. Bisecting through the git history across an incompatible change
  means you can run into broken commits. We try hard to avoid that
  if we are aware of a problem in advance. In this case it could be
  avoided by only merging the incompatible DT change in a following
  merge window after the driver change, or (better) by making it
  a backward-compatible change the same way as addressing 2.

         Arnd