linux-kernel - Re: RFC: what do we do with system controllers?

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]

Message-Id: <201202291245.54038.arnd@arndb.de>
Date:	Wed, 29 Feb 2012 12:45:53 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	Greg KH <gregkh@...uxfoundation.org>, linux-kernel@...r.kernel.org,
	Paul Walmsley <paul@...an.com>,
	linux-arm-kernel@...ts.infradead.org,
	"Russell King - ARM Linux" <linux@....linux.org.uk>,
	Olof Johansson <olof@...om.net>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Mattias NILSSON <mattias.i.nilsson@...ricsson.com>,
	Rickard ANDERSSON <rickard.andersson@...ricsson.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Nicolas Pitre <nicolas.pitre@...aro.org>
Subject: Re: RFC: what do we do with system controllers?

On Tuesday 28 February 2012, Linus Walleij wrote:

> 
> * Reset or shut down the system
> * Reset individual ASIC blocks
> * Control some core voltage domains
> * Control system frequency
> * Select clocking of indvidual ASIC IP blocks:
> * Provide some versioning numbers for the entire system
> * Enable and reset external buses such as PCI
> * (De)protect flash memory
> * Provide a communication channel to another control unit
> * Set some clock divisors for misc units
> * LEDs, GPIO etc communication channel
> * USB transciever control:
> * Get OTP (one-time-programmable) bits:
> * Set up DDR control registers:
> * Pin control:

Nice list, thanks for putting that together.

> The current way to split this problem is to:
> 
> - Push each subfunctionality into a specialized subsystem
>   PLL and clocks to drivers/clk using the new framework
>   RealSoonNow for example, pin control we have in place
>   regulators can handle domain switches...
> 
> - Put in place an arbitration hub-like mechanism using MFD

Right.

> This can be done in two ways:
> 
> - Permanently map the register range and let subdrivers
>   poke directly into the registers they're interested in.
> 
> - Map the register range in a hub driver (often MFD) and
>   write accessor functions for all subfunctionality.

Generally, I would always prefer the second of these ways,
because it allows one to keep the necessary locking local to
the implementation of the system controller driver.

> As far as the drivers are small and nice the heterogeneous
> character of these device register ranges are not much
> of a problem. Some will argue to not fix what ain't broken
> and not move these out of arch/arm/* at all.

That argument certainly has its merits, after all the way that
the system controller works is one of the central aspects
of a platform/subarchitecture.

> What we need to discuss is if this is how we go about
> taking care of these devices going forward - what shall be
> the preferred design pattern?
> 
> My current assumption is that we need to get these things
> out of arch/arm/* and into proper subsystems, using
> drivers/mfd/* as an arbitration point. However I am not
> sure that everyone really agrees on this. Right now it's
> more a modus operandi and following what someone else
> does than a conscious decision to do this.
> 
> We have discussed creating drivers/scm/* (system controller
> modules) but I'm pretty unsure of what the definition of
> such creatures would be, and the border toward MFD
> would be pretty blurred.

Agreed.

> x86 have conveniently put some of their equivalents under
> drivers/platform/x86 but if I understood Arnd correctly
> creating drivers/platform/arm would break the intentions
> of that directory.

The problem I have with using drivers/platform for this is that
it encourages grouping of drivers by their host-side connection
rather than by their functionality. We're moving away from
that model in most other places in the kernel, and we should
try to discourage it for new code. The drivers/platform/x86
directory contains stuff like rfkill, input, backlight, etc
drivers, all of which have (or should have) other places for
them to live in already.

I don't mind having a new location for system controllers
outside of (or below) drivers/mfd, but I would try to avoid
naming it "platform" because I fear that leads people to stuff
all sorts of drivers in there because they happen to be
implemented as 'platform_driver'.

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