linux-kernel - Re: [PATCH v2 tty-next 1/2] dt-bindings: serial: ni,ni16650: add bindings

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 13 Apr 2023 15:44:13 -0500
From:   Brenda Streiff <brenda.streiff@...com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     ilpo.jarvinen@...ux.intel.com,
        Gratian Crisan <gratian.crisan@...com>,
        Jason Smith <jason.smith@...com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        linux-serial@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 tty-next 1/2] dt-bindings: serial: ni,ni16650: add
 bindings

On 4/13/23 02:39, Krzysztof Kozlowski wrote:
> On 13/04/2023 00:24, Brenda Streiff wrote:
>> On 4/11/23 00:44, Krzysztof Kozlowski wrote:
>>> On 10/04/2023 23:11, Brenda Streiff wrote:
>>>> +
>>>> +  interrupts:
>>>> +    maxItems: 1
>>>> +
>>>> +  clock-frequency: true
>>>
>>> I missed it last time - why do you need this property? You do not have
>>> any clock input, so which clock's frequency is it?
>>>
>>
>> This is the clock frequency of the UART; on our x86-based platforms this
>> comes from the LPC clock, on Zynq-7000 it's derived from a clock in the
>> FPGA. This is used to set struct uart_port::uartclk in the serial core,
>> as it is for other UARTs.
>>
>> This clock frequency can vary based on board design (especially on the
>> x86 side, due to different LPC clocks) but for a given design is fixed-
>> frequency.
> 
> So you must have clock input - clocks property. Once you add this, use
> assigned-clocks to get the rate you want.
> 
>>
>> Would you prefer this be documented further? I was following 8250.yaml's
>> lead here with the simple `true`.
> 
> I prefer to drop it. It is not correct and a legacy property. Without
> clock inputs how can you even configure some clock?

Configure in what respect? Software can't change this clock; it's
effectively a fixed oscillator.

In practice, this would always be pointing at a compatible="fixed-clock"
which declares a clock-frequency; this seems like "clock-frequency but
more steps". I can add that, but I'm not clear on what value that adds.

We also have shipping devices with ACPI tables using "clock-frequency",
so independent of support for "clocks" and "assigned-clocks" for
devicetree-using systems, I would still have to keep support in the
driver for a "clock-frequency" device property for ACPI-using systems.

(Is there documentation on a standalone clock-property being a legacy
property that I've missed? I don't see anything of the sort in
writing-bindings.rst or in dt-schema and I want to make sure that I
haven't missed the proper guidance here.)