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: <418418af-64db-445e-8f73-3085b1846722@amd.com>
Date: Wed, 17 Jan 2024 09:27:20 +0100
From: Michal Simek <michal.simek@....com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
 linux-kernel@...r.kernel.org, monstr@...str.eu, michal.simek@...inx.com,
 git@...inx.com
Cc: Conor Dooley <conor+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Moritz Fischer <mdf@...nel.org>, Rob Herring <robh+dt@...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 v2] dt-bindings: fpga: Convert fpga-region binding to yaml



On 1/17/24 09:14, Krzysztof Kozlowski wrote:
> On 17/01/2024 09:07, Michal Simek wrote:
>>>> +patternProperties:
>>>> +  "@(0|[1-9a-f][0-9a-f]*)$":
>>>> +    type: object
>>>
>>> You put (0|[...) to disallow @0001? I personally would not care, dtc
>>> handles this, and the pattern is confusing. Just @[0-9a-z]+$
>>
>> This is actually taken from dtschema/schemas/simple-bus.yaml to allow all nodes
>> with regs.
>>
>>>
>>>> +
>>>> +  "^[^@]+$": true
>>>
>>> I dislike it. How is this binding supposed to be used? If in standalone
>>> way, then you allow any property so what's the point of this schema? If
>>> fpga-bridge.yaml is referenced by other device-specific binding, then
>>> all properties will be evaluated here, so the same: you allow any property.
>>>
>>> Depending on the usage, this might be just like other generic, common
>>> schemas, so end with "additionalPropeties: true".
>>
>> ok. I am fine with it.
> 
> But please verify my idea. If it is used standalone, then you should
> drop both above patterns + additionalProps:false. If it is used as
> generic schema referenced by something, then you could keep one pattern
> for object, but actually it is redundant, so I propose to drop them and
> additionalProps:true.

additionalProperties: true works for me.

I was looking at how to describe cases where you have normal MMIO IP or also 
things like fixed-factor-clock without reg property. That's why I looked at 
simple-bus schema and took patterns from it.
Not sure if there can be something else out of that patterns but if you fine 
with just permitting everything that's perfectly fine for me.

Thanks,
Michal

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ