linux-kernel - Re: [PATCH v3] dt-bindings: fpga: Convert fpga-region binding to yaml

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: <20240119233231.GA1290941-robh@kernel.org>
Date: Fri, 19 Jan 2024 17:32:31 -0600
From: Rob Herring <robh@...nel.org>
To: Michal Simek <michal.simek@....com>
Cc: linux-kernel@...r.kernel.org, monstr@...str.eu, michal.simek@...inx.com,
	git@...inx.com, Conor Dooley <conor+dt@...nel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	Moritz Fischer <mdf@...nel.org>, Tom Rix <trix@...hat.com>,
	Wu Hao <hao.wu@...el.com>, Xu Yilun <yilun.xu@...el.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@...r.kernel.org>,
	"open list:FPGA MANAGER FRAMEWORK" <linux-fpga@...r.kernel.org>
Subject: Re: [PATCH v3] dt-bindings: fpga: Convert fpga-region binding to yaml

On Thu, Jan 18, 2024 at 01:34:16PM +0100, Michal Simek wrote:
> 
> 
> On 1/17/24 22:47, Rob Herring wrote:
> > On Wed, Jan 17, 2024 at 12:30:58PM +0100, Michal Simek wrote:
> > > Convert the generic fpga region DT binding to json-schema.
> > > There are some differences compare to txt version.
> > > 1. DT overlay can't be described in example that's why directly include
> > > information from overlay to node which was referenced. It is visible in
> > > example with /* DT Overlay contains: &... */
> > > 
> > > 2. All example have been rewritten to be simpler and describe only full
> > > reconfiguration and partial reconfiguration with one bridge.
> > > Completely drop the case where fpga region can inside partial
> > > reconfiguration region which is already described in description
> > > 
> > > 3. Fixed some typos in descriptions compare to txt version but most of it
> > > is just c&p from txt file.
> > > 
> > > Signed-off-by: Michal Simek <michal.simek@....com>

[...]

> > > +additionalProperties: true
> > 
> > Why? This should only be used if another schema is going to include this
> > one. That's not the case here.
> 
> In v2 we discussed this with Krzysztof. I used pattern properties from
> simple-bus.yaml in v2.
> 
> https://lore.kernel.org/all/b2dd8bcd-1e23-4b68-b7b7-c01b034fc1fe@linaro.org/

You didn't answer his question. You just picked up 
'additionalProperties: true' which is easy because it avoids 'problems'.

His question was is this a common schema referenced by other schemas? If 
so, then use 'additionalProperties: true'. But it is not. You've 
defined exactly what 'compatible' must be and that means it can't be a 
common schema.

> 
> > 
> > 'type: object' would be acceptable here as that says only nodes can be
> > added.
> 
> What do you think should be patternProperties in this case?

You are the one with FPGAs, what do you need?


> I played with it a little bit but all nodes with @ are likely object type.

'@' is only allowed in node names, so it's more than just likely.

> But what to do with others?
> There are nodes as you see in examples like fixed-factor-clock nodes which
> are also object type.

Then the node names can be anything and you should use what I suggested.

> Standard property like firmware-name or encrypted-fpga-config are coming via
> overlay for sure. Others are not permitted. That's why others then listed
> properties likely must be type object. Is there an elegant way to encode it?

Sorry, I don't follow. You should list every possible property, then the 
only thing left are nodes and my suggestion covers them. If there's a 
pattern to the node names, then you can use patternProperties.

> > > +
> > > +examples:
> > > +  - |
> > > +    /*
> > > +     * Full Reconfiguration without Bridges with DT overlay
> > > +     */
> > > +    fpga_region0: fpga-region {
> > 
> > Drop unused labels.
> 
> Actually it is kind of used. I kept it to be able to reference something in
> comment below.

Okay. Kind of outside the scope of examples and schema as I mentioned.


> > > +      compatible = "fpga-region";
> > > +      #address-cells = <1>;
> > > +      #size-cells = <1>;
> > > +      fpga-mgr = <&fpga_mgr0>;
> > > +
> > > +      /* DT Overlay contains: &fpga_region0 */
> > > +      firmware-name = "zynq-gpio.bin";
> > > +      gpio@...00000 {
> > > +        compatible = "xlnx,xps-gpio-1.00.a";
> > > +        reg = <0x40000000 0x10000>;
> > 
> > This example implies this is a translatable address, but the lack of
> > 'ranges' in the parent prevents that. In turn, that means unit-addresses
> > should be accepted in the parent node name as well.
> 
> v1 contains ranges property and it was removed based on Krzysztof comment
> that fpga-region has no unit address that's why ranges shouldn't be used.
> 
> https://lore.kernel.org/all/c3c92468-a1db-498b-b4a2-7926b84cb5ea@linaro.org/

Plain "ranges;" does not have a unit-address. But really, you should 
allow a non-empty ranges too and therefore allow for a unit-address.

Rob