linux-kernel - Re: [RFC PATCH] slimbus: Linux driver framework for SLIMbus.

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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 17 Aug 2011 17:03:27 +0900
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Kenneth Heitke <kheitke@...eaurora.org>, sdharia@...eaurora.org,
	David Brown <davidb@...eaurora.org>, bryanh@...eaurora.org,
	linux-arm-msm@...r.kernel.org, rdunlap@...otime.net,
	rmk+kernel@....linux.org.uk, john.stultz@...aro.org,
	akpm@...ux-foundation.org, ohad@...ery.com, gregkh@...e.de,
	stefanr@...6.in-berlin.de, lethal@...ux-sh.org,
	linville@...driver.com, zajec5@...il.com,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] slimbus: Linux driver framework for SLIMbus.

On Wed, Aug 17, 2011 at 09:09:44AM +0200, Arnd Bergmann wrote:

> * Move the logic for enabling and disabling devices into a host specific
>   driver that takes care of powering the devices up initially, identifying
>   them and putting them into run-time PM disabled state when no driver was
>   found or the device is unused.

> This will make it possible to reuse the same driver for multiple machines
> that have the same endpoint devices, while moving all the board specific
> clock and reset logic into a separate driver, which can be very small in
> many cases.

There should be no more need for this with slimbus than there is with
any of our other buses - this sort of dynamic enable and disable is
already standard practice for devices in embedded systems.  There's some
stuff it'd be good to do here but it shouldn't be driver specific, it
should be a generic device model thing.  The main problem cases right
now are things like USB which currently assume there's no magic going on
outside of the bus.

One thing I've wanted to do for a while but never quite got the time to
look at yet is to add support for automatically enabling and disabling
regulators along with the probe, remove, suspend and runtime suspend
paths.  If there's sufficient hooks for that they should also be usable
for anything that is suitably board specific.

> I would guess that in many cases, the logic for enabling the devices
> fits into the slimbus host driver. If that is not the case, e.g. when
> a lot of machines have the same host controller but each of them uses
> a different way to get the devices out of reset, you can turn the host

I'd expect that bringing the device out of reset is going to be largely
unrelated to the host controller, it's going to be GPIOs, clocks and
regulators.  The individual drivers are going to want to manage this
stuff dynamically at runtime too.
--
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/