linux-kernel - Re: [PATCH 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register

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, 14 Nov 2014 10:01:04 -0800
From:	Tony Lindgren <tony@...mide.com>
To:	Tero Kristo <t-kristo@...com>
Cc:	Paul Walmsley <paul@...an.com>,
	Tomi Valkeinen <tomi.valkeinen@...com>,
	Marek Belisko <marek@...delico.com>, robh+dt@...nel.org,
	pawel.moll@....com, mark.rutland@....com,
	ijc+devicetree@...lion.org.uk, galak@...eaurora.org,
	bcousson@...libre.com, linux@....linux.org.uk,
	plagnioj@...osoft.com, grant.likely@...aro.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-fbdev@...r.kernel.org, hns@...delico.com
Subject: Re: [PATCH 4/4] arm: dts: omap3-gta04: Add static configuration for
 devconf1 register

* Tero Kristo <t-kristo@...com> [141113 23:33]:
> On 11/14/2014 01:58 AM, Tony Lindgren wrote:
> 
> The PRCM/clock cleanups that I have under work basically splits the clock
> inits under their respective IP blocks; currently everything is registered
> under generic PRCM. System control module will be one of the clock providers
> (and is going to look like a driver), which will be registering its own
> clocks.

Yes that's nice. The clock modules in the SCM should probably use the
syscon mapping unless there's a clear separate IO area for them. And
then use pinctrl for registers that are muxes for external pins unless
they are in some dedicated clock register area.

> This doesn't change the fact that pinctrl is directly mapping its
> own register space atm though, it might be possible to re-route this to use
> the generic system control module if need be though.

Mapping dedicated IO areas to individual drivers is not a problem. These
drivers can eventually be children of a core SCM driver if needed.

> I guess its just a political decision which way we want to go, currently we
> have lots of system control clocks under the clock data (for
> AM33xx,AM43xx,OMAP3), but we can remove these easily if need be. In some
> cases it is nicer to have the data in the clock tree though, the drivers
> don't need to care if they are touching a clock or a pinctrl entity. Some
> people have been converting additional stuff to CCF outside of PRCM, like
> Archit did some work to try and get control module clock support for DRA7,
> and Tomi has been talking to convert some of the DSS internal clocks to CCF
> also.

Setting up CCF drivers for SCM makes sense to me. I suggest the
following guidelines:

1. If there's a clear separate dedicated IO area in SCM, it can be
   a driver implementing a Linux generic framework for CCF, regulators,
   pinctrl, or PHY.

2. For the random control registers, we should use syscon or
   pinctrl-single to implement Linux generic framwork functions for
   CCF, regulators, pinctrl or PHY.

3. For resource management, we can have a core SCM driver that takes
   care of the save and restore of registers and clocking if needed.
   I believe currently SCM clocks are always enabled though. We can
   set the drivers in #1 and #2 abobe to be childer of the core SCM
   driver if we ever need to manage clocks during runtime.

Regards,

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