Date:   Fri, 29 Jan 2021 09:55:11 +0800
From:   Wei Xu <xuwei5@...ilicon.com>
To:     Arnd Bergmann <arnd@...nel.org>
CC:     Zhen Lei <thunder.leizhen@...wei.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Rob Herring <robh+dt@...nel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        devicetree <devicetree@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Zhangfei Gao <zhangfei.gao@...aro.org>,
        Chen Feng <puck.chen@...ilicon.com>,
        Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
        "Mauro Carvalho Chehab" <mchehab+huawei@...nel.org>
Subject: Re: [PATCH v3 2/4] arm64: dts: correct vendor prefix hisi to hisilicon

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@...ilicon.com> wrote:
>>> On 2021/1/27 6:23, Arnd Bergmann wrote:
>>>> On Tue, Dec 8, 2020 at 1:46 PM Zhen Lei <thunder.leizhen@...wei.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@...wei.com>
>>>>> Cc: Chen Feng <puck.chen@...ilicon.com>
>>>>> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.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
>> .
>>

Powered by blists - more mailing lists