| Message ID | 20201208124641.1787-3-thunder.leizhen@huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | dt-bindings: reset: convert Hisilicon reset controller bindings to json-schema | expand |
Hi Zhen Lei, On 2020/12/8 20:46, Zhen Lei 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@huawei.com> > Cc: Chen Feng <puck.chen@hisilicon.com> > Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Thanks! Applied to the hisilicon arm64 dt tree. Best Regards, Wei > --- > arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 4 ++-- > arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi > index 49c19c6879f95ce..bfb1375426d2b58 100644 > --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi > +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi > @@ -345,7 +345,7 @@ > crg_rst: crg_rst_controller { > compatible = "hisilicon,hi3660-reset"; > #reset-cells = <2>; > - hisi,rst-syscon = <&crg_ctrl>; > + hisilicon,rst-syscon = <&crg_ctrl>; > }; > > > @@ -376,7 +376,7 @@ > > iomcu_rst: reset { > compatible = "hisilicon,hi3660-reset"; > - hisi,rst-syscon = <&iomcu>; > + hisilicon,rst-syscon = <&iomcu>; > #reset-cells = <2>; > }; > > diff --git a/arch/arm64/boot/dts/hisilicon/hi3670.dtsi b/arch/arm64/boot/dts/hisilicon/hi3670.dtsi > index 85b0dfb35d6d396..5c5a5dc964ea848 100644 > --- a/arch/arm64/boot/dts/hisilicon/hi3670.dtsi > +++ b/arch/arm64/boot/dts/hisilicon/hi3670.dtsi > @@ -155,7 +155,7 @@ > compatible = "hisilicon,hi3670-reset", > "hisilicon,hi3660-reset"; > #reset-cells = <2>; > - hisi,rst-syscon = <&crg_ctrl>; > + hisilicon,rst-syscon = <&crg_ctrl>; > }; > > pctrl: pctrl@e8a09000 { >
On Tue, Dec 8, 2020 at 1:46 PM Zhen Lei <thunder.leizhen@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@huawei.com> > Cc: Chen Feng <puck.chen@hisilicon.com> > Cc: Manivannan Sadhasivam <manivannan.sadhasivam@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? The binding file in this case would need to list the old name as deprecated, though I'm not sure how that would work without causing a warning about the unknown vendor prefix. Arnd
Hi Arnd, On 2021/1/27 6:23, Arnd Bergmann wrote: > On Tue, Dec 8, 2020 at 1:46 PM Zhen Lei <thunder.leizhen@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@huawei.com> >> Cc: Chen Feng <puck.chen@hisilicon.com> >> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@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! Best Regards, Wei > > The binding file in this case would need to list the old name as deprecated, > though I'm not sure how that would work without causing a warning about > the unknown vendor prefix. > > Arnd > . >
On 2021/1/27 6:23, Arnd Bergmann wrote: > On Tue, Dec 8, 2020 at 1:46 PM Zhen Lei <thunder.leizhen@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@huawei.com> >> Cc: Chen Feng <puck.chen@hisilicon.com> >> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@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? Hi, Arnd: This is one of the patch series. The other three patches have been applied by Philipp Zabel and are currently in linux-next. https://lkml.org/lkml/2020/12/10/697 > > The binding file in this case would need to list the old name as deprecated, > though I'm not sure how that would work without causing a warning about > the unknown vendor prefix. > > Arnd > > . >
On Wed, Jan 27, 2021 at 1:42 AM Wei Xu <xuwei5@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@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@huawei.com> > >> Cc: Chen Feng <puck.chen@hisilicon.com> > >> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@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
Hi Arnd, On 2021/1/28 22:08, Arnd Bergmann wrote: > On Wed, Jan 27, 2021 at 1:42 AM Wei Xu <xuwei5@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@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@huawei.com> >>>> Cc: Chen Feng <puck.chen@hisilicon.com> >>>> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@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: Thanks for the detailed explanation! > > 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. Agreed and the driver has been merged into the v5.11-rc1. > > 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. Yes, it is. But if leaving both in place, the dtbs_check will report following warning again: 'hisi,rst-syscon' does not match any of the regexes That is why leizhen changed the dtb. Do you think it is OK to assume no one will use the new dtb with an older kernel? > > 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. Yes, agreed. And The DT change pull request is sent after the driver has been merged into v5.11-rc1. Really appreciate the detail you went to! Best Regards, Wei > > Arnd > . >
Hi Arnd, On 2021/1/29 9:02, Wei Xu wrote: > Hi Arnd, > > On 2021/1/28 22:08, Arnd Bergmann wrote: >> On Wed, Jan 27, 2021 at 1:42 AM Wei Xu <xuwei5@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@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@huawei.com> >>>>> Cc: Chen Feng <puck.chen@hisilicon.com> >>>>> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@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: > > Thanks for the detailed explanation! > >> >> 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. > > Agreed and the driver has been merged into the v5.11-rc1. Sorry, I made a mistake. It has been merged into linux-next *not* the v5.11-rc1. > >> >> 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. > > Yes, it is. > But if leaving both in place, the dtbs_check will report following warning again: > 'hisi,rst-syscon' does not match any of the regexes > > That is why leizhen changed the dtb. > Do you think it is OK to assume no one will use the new dtb with an older kernel? > >> >> 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. > > Yes, agreed. > And The DT change pull request is sent after the driver has been merged into v5.11-rc1. I can drop this patch and revert what I have changed in Mauro's following patch: "arm64: dts: hisilicon: hi3670.dtsi: add iomcu_rst" Then resend the pull request. And pick up this patch after the next merge window. Do you think is it OK? Thanks! Best Regards, Wei > > Really appreciate the detail you went to! > > Best Regards, > Wei > >> >> Arnd >> . >>
On Fri, Jan 29, 2021 at 2:57 AM Wei Xu <xuwei5@hisilicon.com> wrote: > On 2021/1/29 9:02, Wei Xu wrote: > > On 2021/1/28 22:08, Arnd Bergmann wrote: > >> 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. > > > > Yes, it is. > > But if leaving both in place, the dtbs_check will report following warning again: > > 'hisi,rst-syscon' does not match any of the regexes > > > > That is why leizhen changed the dtb. > > Do you think it is OK to assume no one will use the new dtb with an older kernel? > > > >> > >> 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. > > > > Yes, agreed. > > And The DT change pull request is sent after the driver has been merged into v5.11-rc1. > > I can drop this patch and revert what I have changed in Mauro's following patch: > "arm64: dts: hisilicon: hi3670.dtsi: add iomcu_rst" > > Then resend the pull request. And pick up this patch after the next merge window. > Do you think is it OK? Let's start with the updated pull request without this patch so I can merge the other changes you sent. I'm still not convinced it helps to drop the property rather than having both. I think it should be possible to list the old property name in the binding as 'deprecated' and keep it in the .dts for backwards compatibility but leave it out in future dts files. Maybe move it into the board .dts file(s) and make the .dtsi file have only the new property. Arnd
Hi Arnd, On 2021/1/29 16:21, Arnd Bergmann wrote: > On Fri, Jan 29, 2021 at 2:57 AM Wei Xu <xuwei5@hisilicon.com> wrote: >> On 2021/1/29 9:02, Wei Xu wrote: >>> On 2021/1/28 22:08, Arnd Bergmann wrote: >>>> 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. >>> >>> Yes, it is. >>> But if leaving both in place, the dtbs_check will report following warning again: >>> 'hisi,rst-syscon' does not match any of the regexes >>> >>> That is why leizhen changed the dtb. >>> Do you think it is OK to assume no one will use the new dtb with an older kernel? >>> >>>> >>>> 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. >>> >>> Yes, agreed. >>> And The DT change pull request is sent after the driver has been merged into v5.11-rc1. >> >> I can drop this patch and revert what I have changed in Mauro's following patch: >> "arm64: dts: hisilicon: hi3670.dtsi: add iomcu_rst" >> >> Then resend the pull request. And pick up this patch after the next merge window. >> Do you think is it OK? > > Let's start with the updated pull request without this patch so I can merge > the other changes you sent. Got it. Thanks! > > I'm still not convinced it helps to drop the property rather than having > both. I think it should be possible to list the old property name in the > binding as 'deprecated' and keep it in the .dts for backwards compatibility > but leave it out in future dts files. Maybe move it into the board .dts file(s) > and make the .dtsi file have only the new property. Thanks! I will check with Lei Zhen to see which is possible. Best Regards, Wei > > Arnd > . >
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi index 49c19c6879f95ce..bfb1375426d2b58 100644 --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi @@ -345,7 +345,7 @@ crg_rst: crg_rst_controller { compatible = "hisilicon,hi3660-reset"; #reset-cells = <2>; - hisi,rst-syscon = <&crg_ctrl>; + hisilicon,rst-syscon = <&crg_ctrl>; }; @@ -376,7 +376,7 @@ iomcu_rst: reset { compatible = "hisilicon,hi3660-reset"; - hisi,rst-syscon = <&iomcu>; + hisilicon,rst-syscon = <&iomcu>; #reset-cells = <2>; }; diff --git a/arch/arm64/boot/dts/hisilicon/hi3670.dtsi b/arch/arm64/boot/dts/hisilicon/hi3670.dtsi index 85b0dfb35d6d396..5c5a5dc964ea848 100644 --- a/arch/arm64/boot/dts/hisilicon/hi3670.dtsi +++ b/arch/arm64/boot/dts/hisilicon/hi3670.dtsi @@ -155,7 +155,7 @@ compatible = "hisilicon,hi3670-reset", "hisilicon,hi3660-reset"; #reset-cells = <2>; - hisi,rst-syscon = <&crg_ctrl>; + hisilicon,rst-syscon = <&crg_ctrl>; }; pctrl: pctrl@e8a09000 {
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@huawei.com> Cc: Chen Feng <puck.chen@hisilicon.com> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> --- arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 4 ++-- arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)