[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e9ef5936-63dc-f959-13f3-6ab3e9bf140b@kernel.org>
Date: Tue, 22 Feb 2022 10:27:10 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Oleksii Moisieiev <Oleksii_Moisieiev@...m.com>
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
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
>
>>
>>>
>>>> 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.
Best regards,
Krzysztof
Powered by blists - more mailing lists