linux-kernel - Re: [PATCH] ARM: shmobile: compile drivers/sh for CONFIG_ARCH_SHMOBILE

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, 17 Jan 2014 00:49:35 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Ben Dooks <ben.dooks@...ethink.co.uk>
Cc:	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	linux-kernel@...ts.codethink.co.uk,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Linus SH list <linux-sh@...r.kernel.org>,
	Simon Horman <horms@...ge.net.au>,
	Magnus Damm <magnus.damm@...il.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH] ARM: shmobile: compile drivers/sh for
 CONFIG_ARCH_SHMOBILE_MULTI

On Mon, Jan 13, 2014 at 06:45:36AM +0000, Ben Dooks wrote:

> - If pm-runtime is not enabled then we need something to manage the
>   clocks for the driver. If we put that code in the driver then there
>   is not a lot of point in having the pm-runtime clock code here as
>   the driver really only needs a helper to turn them on and off at
>   the right place.

Last time I looked at the code the runtime PM stuff was also being used
to manage actual power domains in at least some of those SoCs (which is
the more common use for power domains).  This was a while ago while I
was doing power domain support for s3c64xx though.

> When discussing this on freenode's #armkernel channel, several people
> including Mark Brown wanted to keep this as it made driver's handling
> of clocks much easier (there was no longer any need to deal with the
> clk code when writing a simple driver). My view is it is a pain as we
> now have a mix of drivers which expect to do their own clock work and
> some that do not. (It is possible there are even some shmobile drivers
> that still do their own clock management).

I don't massively care one way or another but it is a totally reasonable
decision for a platform to do this especially if the clocks are tied to
the power domains in some way, for example a single functional clock
shared over the domain.

The arguments people have for doing this have been more about removing
knowledge of the SoC integration from the driver - having the functional
clocks for the IP visible in the kernel can make IPs harder to share
with platforms that lack meaningful clock management - and factoring out
boilerplate code that just acquires, enables and disables clocks.

> Personally I do not like hiding the implementation of this, as it ends
> up confusing people when they first come to it.

It wouldn't do that if we did it all the time of course; there is an
argument for consistency.

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