All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yao Zi <ziyao@disroot.org>
To: Conor Dooley <conor@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jirislaby@kernel.org>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Lubomir Rintel <lkundrak@v3.sk>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-serial@vger.kernel.org
Subject: Re: [PATCH] dt-bindings: serial: 8250: Make clocks and clock-frequency exclusive
Date: Wed, 28 May 2025 02:25:56 +0000	[thread overview]
Message-ID: <aDZ0NPg2UCVZisk2@pie.lan> (raw)
In-Reply-To: <20250527-polio-snooze-c05aafc1e270@spud>

On Tue, May 27, 2025 at 04:24:11PM +0100, Conor Dooley wrote:
> On Sat, May 24, 2025 at 10:56:02AM +0000, Yao Zi wrote:
> > The 8250 binding before converting to json-schema states,
> > 
> >   - clock-frequency : the input clock frequency for the UART
> >   	or
> >   - clocks phandle to refer to the clk used as per Documentation/devicetree
> > 
> > for clock-related properties, where "or" indicates these properties
> > shouldn't exist at the same time.
> > 
> > Additionally, the behavior of Linux's driver is strange when both clocks
> > and clock-frequency are specified: it ignores clocks and obtains the
> > frequency from clock-frequency, left the specified clocks unclaimed. It
> > may even be disabled, which is undesired most of the time.
> 
> That sounds like an issue in the driver itself, no? If the clock phandle
> is present it sounds like the driver should be claiming the clock
> whether a frequency is specified or not. If so, that should be fixed
> whether this patch gets applied or not.

Agree.

> > 
> > But "anyOf" doesn't prevent these two properties from coexisting, as it
> > considers the object valid as long as there's at LEAST one match.
> > 
> > Let's switch to "oneOf" and disallows the other property if one exists,
> > exclusively matching the original binding and avoid future confusion on
> > the driver's behavior.
> 
> Have you checked whether or not there are devices that have both
> in-tree? If there are, can you fix them up as part of the change, rather
> than adding new warnings.

Had taken a brief search, seems all UARTs ship both clock-frqeuency and
clocks properties are snps,dw-apb-uart variants, which are not related
to the generic 8250 binding. So I think it shouldn't cause new warnings.

> > 
> > Fixes: e69f5dc623f9 ("dt-bindings: serial: Convert 8250 to json-schema")
> > Signed-off-by: Yao Zi <ziyao@disroot.org>
> > ---
> >  Documentation/devicetree/bindings/serial/8250.yaml | 10 +++++++---
> >  1 file changed, 7 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
> > index dc0d52920575..4322394f5b8f 100644
> > --- a/Documentation/devicetree/bindings/serial/8250.yaml
> > +++ b/Documentation/devicetree/bindings/serial/8250.yaml
> > @@ -45,9 +45,13 @@ allOf:
> >                    - ns16550
> >                    - ns16550a
> >      then:
> > -      anyOf:
> > -        - required: [ clock-frequency ]
> > -        - required: [ clocks ]
> > +      oneOf:
> > +        - allOf:
> 
> Why is the allOf needed here? Does
> oneOf:
>   - required: foo
>   - required: bar
> not work? There's a bunch of bindings doing that, so not sure why it
> doesn't work in your case.

Oops, you're right, it does work here and emits an "... is valid under
each of ..." error. Will change to this form in v2.

> Cheers,
> Conor.
> 
> > +            - required: [ clock-frequency ]
> > +            - properties: { clocks: false }
> > +        - allOf:
> > +            - required: [ clocks ]
> > +            - properties: { clock-frequency: false }
> >  
> >  properties:
> >    compatible:
> > -- 
> > 2.49.0
> > 

Best regards,
Yao Zi

  reply	other threads:[~2025-05-28  2:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-24 10:56 [PATCH] dt-bindings: serial: 8250: Make clocks and clock-frequency exclusive Yao Zi
2025-05-27 15:24 ` Conor Dooley
2025-05-28  2:25   ` Yao Zi [this message]
2025-05-28 13:34     ` Conor Dooley

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=aDZ0NPg2UCVZisk2@pie.lan \
    --to=ziyao@disroot.org \
    --cc=conor+dt@kernel.org \
    --cc=conor@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=lkundrak@v3.sk \
    --cc=robh@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.