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: <3da13600844b8a6c3b788bdb26faa537d0287173.camel@mediatek.com>
Date:   Mon, 16 Jan 2023 09:16:48 +0000
From:   Yong Wu (吴勇) <Yong.Wu@...iatek.com>
To:     "krzysztof.kozlowski@...aro.org" <krzysztof.kozlowski@...aro.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        Youlin Pei (裴友林) 
        <youlin.pei@...iatek.com>,
        Tiffany Lin (林慧珊) 
        <tiffany.lin@...iatek.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "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>,
        "mchehab@...nel.org" <mchehab@...nel.org>,
        "joro@...tes.org" <joro@...tes.org>,
        Yunfei Dong (董云飞) 
        <Yunfei.Dong@...iatek.com>,
        YF Wang (王云飞) <YF.Wang@...iatek.com>,
        "nfraprado@...labora.com" <nfraprado@...labora.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>,
        "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
        Mingyuan Ma (马鸣远) 
        <Mingyuan.Ma@...iatek.com>,
        Andrew-CT Chen (陳智迪) 
        <Andrew-CT.Chen@...iatek.com>,
        "angelogioacchino.delregno@...labora.com" 
        <angelogioacchino.delregno@...labora.com>,
        "will@...nel.org" <will@...nel.org>
Subject: Re: [PATCH 01/10] dt-bindings: media: mediatek,vcodec: Remove
 dma-ranges property

On Mon, 2023-01-16 at 09:06 +0100, Krzysztof Kozlowski wrote:
> 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?

Sorry I missed a venc node. In [9/10] of this series, I deleted this
property for mt8195 venc node, this has a little affect. 

VENC would like to locate the IOVA range of 4G-8G. Without this
patchset, It will fallback to 0-4GB. But this is not a fatal issue. It 
also work fine with 0-4GB iova. I will comment this in the commit
message in the next version.

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

This patchset crosses several domains. This patch is about vcodec, the
next one is about jpeg and the later ones are about iommu.
The reviewers may be different, thus I use "Cc:" here. is this OK in
this case? or I should remove this, and put all of them in the cc list
of the mail.

Thanks.

> > 
> 
> Best regards,
> Krzysztof
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ