linux-kernel - Re: [PATCH] i2c-ocores: add common clock support

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] [day] [month] [year] [list]

Date:	Fri, 23 Jan 2015 00:21:48 +0100
From:	Wolfram Sang <wsa@...-dreams.de>
To:	Max Filippov <jcmvbkbc@...il.com>
Cc:	Peter Korsgaard <peter@...sgaard.com>,
	Peter Korsgaard <jacmet@...site.dk>, linux-i2c@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] i2c-ocores: add common clock support

On Thu, Jan 22, 2015 at 11:53:51PM +0300, Max Filippov wrote:
> On Thu, Jan 22, 2015 at 10:26 PM, Wolfram Sang <wsa@...-dreams.de> wrote:
> > On Thu, Jan 22, 2015 at 10:15:40PM +0300, Max Filippov wrote:
> >> On Thu, Jan 22, 2015 at 9:57 PM, Wolfram Sang <wsa@...-dreams.de> wrote:
> >> > My suggestion is:
> >> >
> >> > 1) if there is a clk node:
> >> >         - we get the clock rate via clock framework
> >> >         - "clock-frequency" is describing the bus speed as usual (Note
> >> >           that parsing here can be as simple as checking for 100kHz only.
> >> >           Although a seperate patch could probably easily add support for
> >> >           other bus speeds to)
> >> >
> >> > 2?) a new binding is present to specify the IP clock speed:
> >> >         - is this needed? is somebody using the driver without CCF?
> >> >         - if so, the new binding is parsed and evaluated
> >> >         - I couldn't find an existing binding to specify a clock speed.
> >> >           Please have a look, too. Otherwise we need to introduce sth
> >> >           like "opencores,ip-clock-khz" probably.
> >> >         - "clock-frequency" is describing the bus speed as usual
> >> >
> >> > 3) only "clock-frequency" is present:
> >> >         - we keep the current behaviour to be backwards compatible.
> >> >         - driver should emit a warning to convert to new style
> >> >         - must be marked deprecated everywhere
> >> >
> >> > The documentation should be updated accordingly.
> >> >
> >> > Thoughts?
> >>
> >> I can update my patch to do (1) and (3), leaving (2) to whoever may
> >> need that.
> >
> > Please implement (2) as well. Otherwise we would have documented
> > ambiguity of "clock-frequency" which is bad. It shouldn't be much code.
> 
> There will be ambiguity if we want to maintain backwards compatibility,
> so we're documenting it anyway. And since we're going to maintain it,
> those who don't use CCF will still have option (3). Is there a point in
> introducing (2) which currently does not exist and thus has no users?

Yes, because 3) is marked as deprecated "DON'T USE". If you don't
implement 2), then we force people to actually use the ambiguity!


Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)