linux-kernel - Re: [PATCH] clk: add specified-rate clock

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]

Date:	Wed, 13 Nov 2013 14:31:25 +0000
From:	James Hogan <james.hogan@...tec.com>
To:	Tomasz Figa <tomasz.figa@...il.com>
CC:	<linux-arm-kernel@...ts.infradead.org>,
	Mike Turquette <mturquette@...aro.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Lars-Peter Clausen <lars@...afoo.de>,
	"Arnd Bergmann" <arnd@...db.de>, <linux-doc@...r.kernel.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	<linux-kernel@...r.kernel.org>,
	Rob Herring <rob.herring@...xeda.com>,
	"Grant Likely" <grant.likely@...retlab.ca>,
	Rob Landley <rob@...dley.net>,
	linux-metag <linux-metag@...r.kernel.org>
Subject: Re: [PATCH] clk: add specified-rate clock

On 13/11/13 14:18, Tomasz Figa wrote:
> Hi James, Mike,
> 
> On Wednesday 13 of November 2013 14:09:56 James Hogan wrote:
>> On 29/05/13 18:39, Mike Turquette wrote:
>>> Quoting James Hogan (2013-05-10 05:44:22)
>>>> The frequency of some SoC's external oscillators (for example TZ1090's
>>>> XTAL1) are configured by the board using pull-ups/pull-downs of
>>>> configuration pins, the logic values of which are automatically latched
>>>> on reset and available in an SoC register. Add a generic clock component
>>>> and DT bindings to handle this.
>>>>
>>>> It behaves similar to a fixed rate clock (read-only), except it needs
>>>> information about a register field (reg, shift, width), and the
>>>> clock-frequency is a mapping from register field values to clock
>>>> frequencies.
>>>>
>>>
>>> James,
>>>
>>> Thanks for sending this!  It looks mostly good and is a useful clock
>>> type to support.  Comments below.
>>
>> Hi Mike,
>>
>> Sorry for slight delay getting back to you. I had another think about
>> this stuff yesterday...
>>
> 
> Just a random idea that came to my mind while reading this thread:
> 
> What about modelling this as a set of fixed rate clocks fed into
> a read-only mux?

Yes, that had occurred to me too. I suppose the arguments against would be:
* it doesn't describe the hardware, there is no mux, just a fixed rate
clock with a discoverable frequency.
* it would sort of work for my small case of only having 9 possible
frequencies (although it would be a bit verbose), but wouldn't scale
nicely or be extendible to if the frequency was encoded more
continuously in the register value. E.g. if the frequency was 1MHz *
(the register value - 1) or something crazy like that. Of course that's
conjecture and SoC designers probably aren't going to want to use more
pins for bootstrap config than necessary.

Cheers
James

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/