mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
To: Rob Herring <robh@kernel.org>
Cc: Vinod Koul <vkoul@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	dmaengine@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dt-bindings: dma: uniphier: Use unevaluatedProperties
Date: Sat, 9 Apr 2022 01:13:35 +0900	[thread overview]
Message-ID: <f350b1d8-23d5-e13b-d908-0fa02f8fcea5@socionext.com> (raw)
In-Reply-To: <Yk80eFKwDVnU67p/@robh.at.kernel.org>

Hi Rob,

On 2022/04/08 3:59, Rob Herring wrote:
> On Thu, Apr 07, 2022 at 04:44:07PM +0900, Kunihiko Hayashi wrote:
>> This refers common bindings, so this is preferred for
>> unevaluatedProperties instead of additionalProperties.
> 
> Yes and no. If you want to define specific common properties are used
> (and not used), then listing them in the specific schema with
> 'additionalProperties' is the right way to do that. If all properties in
> the referenced schema are valid, then unevaluatedProperties is correct.

I understand that having a reference to a common schema isn't a direct reason
to replace with unevaluatedProperties because it depends on how each property
of the common schema is handled in this schema.

Since there is no property to evaluate with "if" etc., I think that it can
be left as "additionalProperties" in this schema.
I withdraw this patch.

> If we wanted using unevaluatedProperties to be a hard rule, we could
> make the meta-schema enforce that.

At the moment it is difficult to decide it to be a hard rule.

Thank you,

---
Best Regards
Kunihiko Hayashi

      reply	other threads:[~2022-04-08 16:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-07  7:44 Kunihiko Hayashi
2022-04-07 18:59 ` Rob Herring
2022-04-08 16:13   ` Kunihiko Hayashi [this message]

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=f350b1d8-23d5-e13b-d908-0fa02f8fcea5@socionext.com \
    --to=hayashi.kunihiko@socionext.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=robh@kernel.org \
    --cc=vkoul@kernel.org \
    /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

all inboxes | Powered by JetHome®