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 <xuw...@hisilicon.com> wrote:
>>> On 2021/1/27 6:23, Arnd Bergmann wrote:
>>>> On Tue, Dec 8, 2020 at 1:46 PM Zhen Lei <thunder.leiz...@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.leiz...@huawei.com>
>>>>> Cc: Chen Feng <puck.c...@hisilicon.com>
>>>>> Cc: Manivannan Sadhasivam <manivannan.sadhasi...@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
>> .
>>
