linux-edac.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Serge Semin <fancer.lancer@gmail.com>
To: Rob Herring <robh@kernel.org>
Cc: Serge Semin <Sergey.Semin@baikalelectronics.ru>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Michal Simek <michal.simek@xilinx.com>,
	Borislav Petkov <bp@alien8.de>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Tony Luck <tony.luck@intel.com>,
	Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	Manish Narani <manish.narani@xilinx.com>,
	Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>,
	Michail Ivanov <Michail.Ivanov@baikalelectronics.ru>,
	Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru>,
	Punnaiah Choudary Kalluri  <punnaiah.choudary.kalluri@xilinx.com>,
	Dinh Nguyen <dinguyen@kernel.org>,
	James Morse <james.morse@arm.com>,
	Robert Richter <rric@kernel.org>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org,
	Krzysztof Kozlowski <krzk@kernel.org>
Subject: Re: [PATCH v2 03/15] dt-bindings: memory: snps: Convert the schema to being generic
Date: Mon, 26 Sep 2022 13:56:11 +0300	[thread overview]
Message-ID: <20220926105611.32od2rjlvybmzmut@mobilestation> (raw)
In-Reply-To: <20220912143219.GC1170702-robh@kernel.org>

On Mon, Sep 12, 2022 at 09:32:19AM -0500, Rob Herring wrote:
> On Sat, Sep 10, 2022 at 10:56:47PM +0300, Serge Semin wrote:
> > At the current state the DW uMCTL2 DDRC DT-schema can't be used as the
> > common one for all the IP-core-based devices due to the compatible string
> > property constraining the list of the supported device names. In order to
> > fix that we suggest to update the compatible property constraints so one
> > would permit having any value aside with the generic device names. At the
> > same time the generic DT-schema selection must be restricted to the
> > denoted generic devices only so not to permit the generic fallback
> > compatibles. Finally since the generic schema will be referenced from the
> > vendor-specific DT-bindings with possibly non-standard properties defined
> > it must permit having additional properties specified.
> > 
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > 
> > ---
> > 
> > Note alternatively we could drop the "additionalProperties" keyword
> > modification since currently there is no actual device available with the
> > properties not listed in the generic DT-schema.
> 

> Normally, this has required 2 schema files. However, I think you can 
> do something like this:
> 
> if:
>   compatible:
>     enum:
>       - snps,ddrc-3.80a
>       - snps,dw-umctl2-ddrc
>       - xlnx,zynqmp-ddrc-2.40a
> then:
>   unevaluatedProperties: false
> 
> 
> But please make sure that actually catches undocumented properties 
> because unevaluateProperties under 'then' is not something I've tried.

Oh, I wish this would work! Alas it doesn't. AFAIU the schemas under
the "then" and "else" keywords are considered as separate schemas
and are independently applied to the DT node. As soon as I added the
construction suggested by you the schema evaluation started failing
with error as none of the DT-node properties in the examples are valid:

< ... /snps,dw-umctl2-ddrc.example.dtb: memory-controller@fd070000:
<     Unevaluated properties are not allowed ('compatible', 'reg', interrupts', 'interrupt-names', '$nodename' were unexpected)

< ... /snps,dw-umctl2-ddrc.example.dtb: memory-controller@3d400000:
<     Unevaluated properties are not allowed ('compatible', 'reg', 'interrupts', 'interrupt-names', 'clocks', 'clock-names', '$nodename' were unexpected)

Any suggestion of how this could be fixed? Perhaps updating the
dtschema tool anyhow? (I failed to find a quick-fix for it) Creating
an additional separate schema with the common properties seems a bit
overkill in this case. On the other hand is there a decent
alternative?

What about accepting what I suggested in this patch? It does permit
additional properties, but we won't need to have a separate schema
with just several common properties.

-Sergey

> 
> Rob

  reply	other threads:[~2022-09-26 12:37 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-10 19:56 [PATCH v2 00/15] EDAC/synopsys: Add generic resources and Baikal-T1 support Serge Semin
2022-09-10 19:56 ` [PATCH v2 01/15] dt-bindings: memory: snps: Replace opencoded numbers with macros Serge Semin
2022-09-12 14:18   ` Rob Herring
2022-09-21 18:35   ` (subset) " Krzysztof Kozlowski
2022-09-10 19:56 ` [PATCH v2 02/15] dt-bindings: memory: snps: Extend schema with IRQs/resets/clocks props Serge Semin
2022-09-12 14:20   ` Rob Herring
2022-09-21 18:35   ` (subset) " Krzysztof Kozlowski
2022-09-10 19:56 ` [PATCH v2 03/15] dt-bindings: memory: snps: Convert the schema to being generic Serge Semin
2022-09-12 14:32   ` Rob Herring
2022-09-26 10:56     ` Serge Semin [this message]
2022-09-27 22:02       ` Rob Herring
2022-09-28 10:39         ` Serge Semin
2022-09-10 19:56 ` [PATCH v2 04/15] dt-bindings: memory: Add Baikal-T1 DDRC DT-schema Serge Semin
2022-09-12  0:44   ` Rob Herring
2022-09-12 15:01   ` Rob Herring
2022-09-10 19:56 ` [PATCH v2 05/15] EDAC/synopsys: Add multi-ranked memory support Serge Semin
2022-09-10 19:56 ` [PATCH v2 06/15] EDAC/synopsys: Add optional ECC Scrub support Serge Semin
2022-09-10 19:56 ` [PATCH v2 07/15] EDAC/synopsys: Drop ECC poison address from private data Serge Semin
2022-09-10 19:56 ` [PATCH v2 08/15] EDAC/synopsys: Add data poisoning disable support Serge Semin
2022-09-10 19:56 ` [PATCH v2 09/15] EDAC/synopsys: Split up ECC UE/CE IRQs handler Serge Semin
2022-09-10 19:56 ` [PATCH v2 10/15] EDAC/synopsys: Add individual named ECC IRQs support Serge Semin
2022-09-10 19:56 ` [PATCH v2 11/15] EDAC/synopsys: Add DFI alert_n IRQ support Serge Semin
2022-09-10 19:56 ` [PATCH v2 12/15] EDAC/synopsys: Add reference clocks support Serge Semin
2022-09-10 19:56 ` [PATCH v2 13/15] EDAC/synopsys: Add ECC Scrubber support Serge Semin
2022-09-10 19:56 ` [PATCH v2 14/15] EDAC/synopsys: Drop vendor-specific arch dependency Serge Semin
2022-09-10 19:56 ` [PATCH v2 15/15] EDAC/synopsys: Add Baikal-T1 DDRC support Serge Semin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220926105611.32od2rjlvybmzmut@mobilestation \
    --to=fancer.lancer@gmail.com \
    --cc=Alexey.Malahov@baikalelectronics.ru \
    --cc=Michail.Ivanov@baikalelectronics.ru \
    --cc=Pavel.Parkhomenko@baikalelectronics.ru \
    --cc=Sergey.Semin@baikalelectronics.ru \
    --cc=bp@alien8.de \
    --cc=devicetree@vger.kernel.org \
    --cc=dinguyen@kernel.org \
    --cc=james.morse@arm.com \
    --cc=krzk@kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manish.narani@xilinx.com \
    --cc=mchehab@kernel.org \
    --cc=michal.simek@xilinx.com \
    --cc=punnaiah.choudary.kalluri@xilinx.com \
    --cc=robh@kernel.org \
    --cc=rric@kernel.org \
    --cc=tony.luck@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).