linux-kernel - Re: [PATCH RFC 0/3] clk: CCF clock primitives + custom IO accessors

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: <20140302202940.GQ3327@book.gsilab.sittig.org>
Date:	Sun, 2 Mar 2014 21:29:40 +0100
From:	Gerhard Sittig <gsi@...x.de>
To:	Soren Brinkmann <soren.brinkmann@...inx.com>
Cc:	Mike Turquette <mturquette@...aro.org>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Michal Simek <michal.simek@...inx.com>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 0/3] clk: CCF clock primitives + custom IO accessors

On Fri, Feb 28, 2014 at 15:34 -0800, Soren Brinkmann wrote:
> 
> [ MMIO registers assumed for clock control modules, but I2C
> communication may be involved in other hardware, individual for
> a (set of) clock(s) and not for an architecture or platform ]
> 
> Does anybody have a good idea how we could avoid all this code
> duplication while enabling usage of the clock primitives with different
> IO accessors?
> Especially the divider and mux primitive have a lot of code that would
> be painful to maintain twice.

Hasn't past discussion already reached the point where code
duplication of the clock control logic was considered
undesirable, and "low level ops" were outlined?  I.e. extending
the compile time decision for a specific clk_{read,write}l()
implementation by another potential redirection that is specific
to a clock item?

Re-submitting a series which duplicates complete clock types,
while the difference is only in how registers get accessed, is
quite saddening.

> In the next step, I encountered a divider clock whose divider is stored
> in 2 I2C registers. So now, the simple IO access replacement doesn't
> work anymore either since this clock needs 2 registers to be read and
> then shifting around the bitfields accordingly.

Are the registers adjacent and contain only bit fields for one
clock?  Or do registers share parameters for several clocks, or
are not adjacent?

In the former case you may use a table from "divider value" to
"bit pattern to read/write".  In the latter case, the clock
control module is rather special, and may not be easily get
mapped to the common primitives.  Unless the ll_ops can implement
the required special handling.

virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office@...x.de
--
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/