netdev - Re: Regulator support for smsc911x

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20120208113524.GE3120@opensource.wolfsonmicro.com>
Date:	Wed, 8 Feb 2012 11:35:25 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Sascha Hauer <s.hauer@...gutronix.de>
Cc:	Fabio Estevam <festevam@...il.com>, robert.marklund@...ricsson.com,
	netdev@...r.kernel.org, Sascha Hauer <kernel@...gutronix.de>
Subject: Re: Regulator support for smsc911x

On Wed, Feb 08, 2012 at 09:31:41AM +0100, Sascha Hauer wrote:

> There is also option e), something I've been thinking about for a while.
> Implement a list of resources which can be attached to a device. By
> resources I mean regulators, clocks and pinmux for example. A device
> would then just call a make_me_work(state) function which iterates over
> this list and enables/disables all resources as necessary. This way we
> could attach everything we need to a device without cluttering the
> driver code like we do today.

That gets tricky where you have resources that are only needed some of
the time (for example, many of the CODECs I work with can happily have
some of the supplies disabled while they are operational - some systems
may never enable certain supplies) and there are fun interactions with
things like runtime PM and system suspend to consider (wake on LAN would
be one for an ethernet driver).  Once you start hitting low power states
and pursuing optimisations there you start to find that the driver needs
to make decisions about what's going on that can't easily be completely
removed from it.

I have been meaning to do something like that which devices can
request if they happen to have trivial or common usage patterns (of
which there's a few) so all they need to do is set flags but I'm really
not sure it's a good idea by default.  Gets fiddly with the device core
though.

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