linux-kernel - Re: CLK_OF_DECLARE advice required

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: <6765be64-9cf6-4663-4182-5b63f27bfb93@raspberrypi.org>
Date:   Wed, 31 May 2017 17:28:58 +0100
From:   Phil Elwell <phil@...pberrypi.org>
To:     Stefan Wahren <stefan.wahren@...e.com>,
        Stephen Warren <swarren@...dotorg.org>
Cc:     Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...eaurora.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-rpi-kernel <linux-rpi-kernel@...ts.infradead.org>,
        linux-clk@...r.kernel.org
Subject: Re: CLK_OF_DECLARE advice required

On 31/05/2017 16:58, Stefan Wahren wrote:
> Am 31.05.2017 um 17:27 schrieb Stephen Warren:
>> On 05/30/2017 06:23 AM, Phil Elwell wrote:
>>> Hi,
>>>
>>> I've run into a problem using the fixed-factor clock on Raspberry Pi
>>> and I'd
>>> like some advice before I submit a patch.
>>>
>>> Some context: the aim is to use a standard UART and some external
>>> circuitry
>>> as a MIDI interface. This would be straightforward except that Linux
>>> doesn't
>>> recognise the required 31.25KHz as a valid UART baud rate. Rhe
>>> workaround is
>>> to declare the UART clock such that the reported rate differs from
>>> the actual
>>> rate. If one sets the reported rate to be (actual*38400)/31250 then
>>> requesting a 38400 baud rate will result in an actual 31250 baud signal.
>>
>> This sounds like the wrong approach. Forcing the port to use a
>> different clock rate than the user requests would prevent anyone from
>> using that port for its standard purpose; it'd turn what should be a
>> runtime decision into a compile-time decision.
>>
>> Are you sure there's no way to simply select the correct baud rate on
>> the port? I see plenty of references to configuring custom baud rates
>> under Linux when I search Google, e.g.:
>>
>>> https://stackoverflow.com/questions/12646324/how-to-set-a-custom-baud-rate-on-linux
>>>
>> "How to set a custom baud rate on Linux?"
>>
>>> https://sourceware.org/ml/libc-help/2009-06/msg00016.html
>> "Re: Terminal interface and non-standard baudrates"
>>
> 
> I remember this gist from Peter Hurley:
> 
> https://gist.github.com/peterhurley/fbace59b55d87306a5b8

Thank you, Stephen and Stephan. Stephen - the clock scaling is applied by a DT overlay so
it effectively a runtime setting, but I take your point about the elegance of the solution.
Stefan - anybaud looks promising, although I would have preferred for users to continue to
use the existing user-space tools - kernel changes can be deployed more easily.

For my edification, can you pretend for a moment that the application was a valid one and
answer any of my original questions?:

1. Should all system clock drivers use OF_CLK_DECLARE? Doing so would probably
avoid this problem, but further initialisation order dependencies may
require more drivers to be initialised early.

2. Why does the clock initialisation hook registered by OF_CLK_DECLARE not
return any indication of success? If it did, and if the OF_POPULATED flag
was only set after successful initialisation then the normal retrying of
a deferred probe would also avoid this problem.

3. Would adding the OF_CLK_DECLARE hook prevent the use of the devm_ managed
functions like devm_kzalloc? If not, why doesn't fixed-factor-clock use it?

Thanks,

Phil