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]

Message-ID: <1874762.a1UESS7e53@flatron>
Date:	Wed, 13 Nov 2013 15:38:26 +0100
From:	Tomasz Figa <tomasz.figa@...il.com>
To:	James Hogan <james.hogan@...tec.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 Wednesday 13 of November 2013 14:31:25 James Hogan wrote:
> 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.

For me, a set of configuration pins that select clock frequency sounds
like a mux. I'd rather say that there are no physical clocks that would
be its inputs, but that's probably just an implementation detail.

> * 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.

I guess you would need an implementation specific code to calculate the
frequency in such cases, which is not what you suggested above (but
rather "a mapping from register field values to clock frequencies"
inside a property).

Best regards,
Tomasz

--
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/