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]
Message-ID: <2e2a0c70-86d2-7ba1-c87c-aaaa9dd460b5@linaro.org>
Date:   Mon, 16 Jan 2023 09:06:23 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Yong Wu (吴勇) <Yong.Wu@...iatek.com>,
        "joro@...tes.org" <joro@...tes.org>,
        "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
        "mchehab@...nel.org" <mchehab@...nel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>
Cc:     Andrew-CT Chen (陳智迪) 
        <Andrew-CT.Chen@...iatek.com>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Youlin Pei (裴友林) 
        <youlin.pei@...iatek.com>,
        Tiffany Lin (林慧珊) 
        <tiffany.lin@...iatek.com>,
        "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Anan Sun (孙安安) <Anan.Sun@...iatek.com>,
        Libo Kang (康利波) <Libo.Kang@...iatek.com>,
        "kyrie.wu@...iatek.corp-partner.google.com" 
        <kyrie.wu@...iatek.corp-partner.google.com>,
        "robin.murphy@....com" <robin.murphy@....com>,
        "hverkuil@...all.nl" <hverkuil@...all.nl>,
        Chengci Xu (许承赐) 
        <Chengci.Xu@...iatek.com>,
        Yunfei Dong (董云飞) 
        <Yunfei.Dong@...iatek.com>,
        YF Wang (王云飞) <YF.Wang@...iatek.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
        Mingyuan Ma (马鸣远) 
        <Mingyuan.Ma@...iatek.com>,
        "angelogioacchino.delregno@...labora.com" 
        <angelogioacchino.delregno@...labora.com>,
        "will@...nel.org" <will@...nel.org>,
        "nfraprado@...labora.com" <nfraprado@...labora.com>
Subject: Re: [PATCH 01/10] dt-bindings: media: mediatek,vcodec: Remove
 dma-ranges property

On 16/01/2023 09:01, Yong Wu (吴勇) wrote:
> On Fri, 2023-01-13 at 09:25 +0100, Krzysztof Kozlowski wrote:
>> On 13/01/2023 07:01, Yong Wu wrote:
>>> MediaTek iommu has already controlled the masters' iova ranges by
>>> the
>>> master's larb/port id. then the dma-ranges property is unnecessary
>>> for
> 
>> Sentences in English always start with a capital letter, however also
>> they do not start with "Then". Make it a proper a proper sentence.
> 
> Sorry for the syntax issues. I think it is "," before "then".
> 
>>> the master's node. the master is vcodec here.
>>
>> Unnecessary or invalid? 
> 
> For mt8195, It is unnecessary. For the other SoC which doesn't use
> parent/child node, the property is invalid, however, there is no vcodec
> node have this property in this case in the current upstream dts nodes.
> 
>> Don't you depend now on some feature of driver
>> added for example recently?
> 
> No. It doesn't depend on any the other patches. Just depend
> on the code changing in this patchset. I just put the dt-binding
> at the beginning of this series.

So this is an ABI change where you expect no upstream users to be
affected? Why you do not clarify it in commit msg?

> 
>>>
>>> Cc: Tiffany Lin <tiffany.lin@...iatek.com>
>>> Cc: Andrew-CT Chen <andrew-ct.chen@...iatek.com>
>>> Cc: Yunfei Dong <yunfei.dong@...iatek.com>
>>> Cc: Mauro Carvalho Chehab <mchehab@...nel.org>
>>> Cc: Rob Herring <robh+dt@...nel.org>
>>> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>
>>
>> There is little point in storing output of get_maintainers.pl forever
>> in
>> the git log. If you need it for some reason, please keep it after -
>> --.
> 
> I did get the list from get_maintainers.pl. Sorry that I didn't
> differentiate.

Getting the list from get_maintainers.pl is correct but storing it
forever in git log is really unnecessary. It's not useful. It's just
automated output, reproducible at any given time.

> 


Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ