lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 29 Jan 2021 09:02:50 +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>
Subject: Re: [PATCH v3 2/4] arm64: dts: correct vendor prefix hisi to hisilicon

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.

> 
> 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
> .
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ