linux-kernel - Re: [PATCH v3 1/2] dt-bindings: serial: samsung: fix maxItems for gs101 & document earlycon requirements

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: <e2f4a37e7c31d26449125a6265239c88162a1085.camel@linaro.org>
Date: Thu, 11 Jul 2024 17:09:50 +0100
From: André Draszik <andre.draszik@...aro.org>
To: Rob Herring <robh@...nel.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Jiri Slaby
 <jirislaby@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor
 Dooley <conor+dt@...nel.org>, Peter Griffin <peter.griffin@...aro.org>,
 Sylwester Nawrocki <s.nawrocki@...sung.com>, Chanwoo Choi
 <cw00.choi@...sung.com>, Alim Akhtar <alim.akhtar@...sung.com>, Michael
 Turquette <mturquette@...libre.com>,  Stephen Boyd <sboyd@...nel.org>, Sam
 Protsenko <semen.protsenko@...aro.org>, Tudor Ambarus
 <tudor.ambarus@...aro.org>, Will McVicker <willmcvicker@...gle.com>, 
 kernel-team@...roid.com, linux-kernel@...r.kernel.org, 
 linux-serial@...r.kernel.org, devicetree@...r.kernel.org, 
 linux-arm-kernel@...ts.infradead.org, linux-samsung-soc@...r.kernel.org, 
 linux-clk@...r.kernel.org
Subject: Re: [PATCH v3 1/2] dt-bindings: serial: samsung: fix maxItems for
 gs101 & document earlycon requirements

Hi Rob,

On Thu, 2024-07-11 at 09:51 -0600, Rob Herring wrote:
> On Wed, Jul 10, 2024 at 7:29 AM André Draszik <andre.draszik@...aro.org> wrote:
> > --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> > +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> > @@ -145,6 +145,20 @@ allOf:
> >          - samsung,uart-fifosize
> >        properties:
> >          reg-io-width: false
> 
> blank line between properties

Do mean before clocks: below and before clock-names: below? We don't do that normally,
at least none of the bindings I looked at do that. Or did I misunderstand?

> > +        clocks:
> > +          description: |
> > +            Note that for earlycon to work, the respective ipclk and pclk need
> > +            to be running! The bootloader normally leaves them enabled, but the
> > +            serial driver will start handling those clocks before the console
> > +            driver takes over from earlycon, breaking earlycon. If earlycon is
> > +            required, please revert the patch "clk: samsung: gs101: don't mark
> > +            non-essential (UART) clocks critical" locally first to mark them
> > +            CLK_IS_CRITICAL and avoid this problem.
> 
> That's a whole bunch of details that are Linux specific which have
> little to do with the binding.

You're right - I had been asked to add this to the binding and didn't consider
that. I think I found a much better alternative in the meantime and this
description can go away.

> > +          maxItems: 2
> > +        clock-names:
> > +          items:
> > +            - const: uart
> > +            - const: clk_uart_baud0
> 
> Which clock is pclk and ipclk?

uart is pclk, clk_uart_baud0 is ipclk.

> 'baud' would be sufficient for the
> name. 'clk_' and 'uart' are redundant because it's all clocks and they
> are all for the uart.

TBH, this patch is just following the existing style & names as already exist for
various other SoCs in this same file. Furthermore, up until this patch the default
from this file applies, which is:

  clock-names:
    description: N = 0 is allowed for SoCs without internal baud clock mux.
    minItems: 2
    items:
      - const: uart
      - pattern: '^clk_uart_baud[0-3]$'
      - pattern: '^clk_uart_baud[0-3]$'
      - pattern: '^clk_uart_baud[0-3]$'
      - pattern: '^clk_uart_baud[0-3]$'

so of course the existing gs101 DTs had followed this scheme. Other SoCs that are
described in this same binding also keep the name as per the default in case
they limit the maximum number like this patch does.

Changing the name now would be a bit disruptive and make gs101 differ from other
Exynos SoCs in this respect, I'd rather not :-)


Cheers,
Andre'