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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 25 Aug 2011 09:10:41 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Arnd Bergmann <arnd@...db.de>,
	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 24, 2011 at 11:21 AM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:
> On Wed, Aug 24, 2011 at 11:15:56AM +0200, Linus Walleij wrote:
>
>> That means that the regulators handling the slimbus devices
>> will need to be enabled before the drivers issue regulator_get()
>> and regulator_enable() on them.
>
> What makes you say that?  We've been discussing how we register Slimbus
> devices other than via hotplug.

OK it's founded in Arnd's remarks that the "Linux model" is to
use auto-detection as much as possible, which means hotplug
*and* coldplug, i.e. auto-discovery at boot, by probing the bus
for devices.

If the device is not powered on boot I understand that it
cannot be auto-discovered.

So then you need platform data or device tree or similar to
register the device. Which is frowned upon, if there exist
other ways to detect the hardware.

>> Does the regulator constraint .always_on have this semantic
>> effect, so the regulator framework can power up the devices
>> without their drivers claiming the regulators first?
>
> It does have that effect but it would (as one might expect) force the
> regulators to always be on which is unacceptable for actual systems.

Aha, no good. :-(

>> Or would we need a new .boot_enable flag to handle that?
>
> There is such a flag already.

I really mean .boot_enable, not .boot_on.

.boot_enable would turn on the regulator at boot no matter
whether it was on or not at boot, and make it possible for
devcie drivers to turn it off later by regulator disable.
Probably by turning it on but leaving the use_count at zero
so that it'd be disabled after the initlevels if no device claimed
it and explictly enabled it before that.

This would power the device during init so the bus could
be probed for devices (coldplugged).

But maybe this is a misunderstanding on my side: maybe
slimbus devices can be hotplugged and discovered, so the
bus driver will tell you that a new device arrived, whereas
it cannot be coldplugged, i.e. you cannot ask the bus to
enumerate and say deliver the addresses to the devices
on it?

>> OK so if we can just power the device the bus can probably
>> autodetect all devices on it, it seems.
>
> Should be able to, yes, though we'll still need to bind
> platform/OF data to them.

OK so what you're saying is that it can never be made to
have self-contained drivers without any accompanying platform
data or device tree info?

Thanks,
Linus Walleij
--
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/