linux-kernel - Re: [RFC PATCH 0/1] dt-bindings: arm: Add scmi

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: <20220222103022.GA496631@EPUAKYIW015D>
Date:   Tue, 22 Feb 2022 10:30:23 +0000
From:   Oleksii Moisieiev <Oleksii_Moisieiev@...m.com>
To:     Krzysztof Kozlowski <krzk@...nel.org>
CC:     "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Sudeep Holla <sudeep.holla@....com>,
        Cristian Marussi <cristian.marussi@....com>,
        Stefano Stabellini <sstabellini@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 0/1] dt-bindings: arm: Add scmi_devid paramter for

Hi Krzysztof,

On Tue, Feb 22, 2022 at 10:27:10AM +0100, Krzysztof Kozlowski wrote:
> On 22/02/2022 09:55, Oleksii Moisieiev wrote:
> > 
> >>
> >> 2. Does your example work properly? Passes dt_binding_check? Reg looks
> >> different than unit-address.
> >>
> > dt_bindings_check passes without errors. Also I've checked this file
> > explicitly by using command:
> > yamllint -c Documentation/devicetree/bindings/.yamllint Documentation/devicetree/bindings/firmware/arm,scmi-devid.yaml
> > 
> > Reg value, if you mean reg parameter from an Example, was taken from
> > r8a77961.dtsi file.
> The check does not pass. You have an error there:
> 
> Documentation/devicetree/bindings/firmware/arm,scmi-devid.example.dt.yaml:
> example-0: usb@...a0000:reg:0: [0, 3993632768, 0, 256] is too long
> 
> 
Probably I've missed that. I'll doublecheck.
> 
> > 
> >>
> >>>
> >>>> 2. Your schema does is not selected by anything. How is it intended to
> >>>> be used? Nothing is including it, either...
> >>>>
> >>>
> >>> The idea is to use this parameter to set the device_id for the device in
> >>> the device-tree, which matches to the device mapping in the Firmware, so
> >>> Trusted Agent can use it to the device permissions.
> >>> Please see Sections 4.2.2.10 and 4.2.1 [0] (Link was provided in the
> >>> cover letter).
> >>>
> >>> I'm currently propose the new feature, called SCI mediator to Xen-devel
> >>> community. Please see link [1] from cover letter for the details.
> >>> In this feature - Xen is the Trusted Agent, which uses scmi_devid
> >>> parameter to set the device permissions.
> >>> We think that this parameter will be useful for other possible SCMI
> >>> implementations, such as other hypervisor or SCMI backend server etc.
> >>
> >> We talk about different things, I think. I was asking how is this schema
> >> selected?
> >>
> >> I gave it a fast try (dtbs_check) and it confirmed - schema does not
> >> have an effect. It's a noop. You need something like "select: true", see:
> >> Documentation/devicetree/bindings/nvmem/nvmem-consumer.yaml
> >> or this schema should be included by other schemas... but then I would
> >> be happy to see actual usage in this patchset (more commits...).
> >>
> > 
> > I think select: true will work for me. I'll do dtbs_check and
> > dt_bindings_check after making all changes and prepare v2 if there will
> > be no further comments.
> > 
> > Also what do you think about maintainers: field? Is it correct? I'm not
> > sure if I used it correctly.
> 
> 
> I think you should add arm,scmi maintainer next to you.
> 

Should I update MAINTAINERS file as well?

Best regards,
Oleksii.