[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20110825094434.GB31154@opensource.wolfsonmicro.com>
Date: Thu, 25 Aug 2011 10:44:34 +0100
From: Mark Brown <broonie@...nsource.wolfsonmicro.com>
To: Linus Walleij <linus.walleij@...aro.org>
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 Thu, Aug 25, 2011 at 09:10:41AM +0200, Linus Walleij wrote:
> 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.
Two problems with that. One is that that'll only work for regulators,
not for GPIOs (eg, reset signals). The other is that if we're going to
be pulling power from devices at runtime we're going to have to cope
with live devices hotplugging underneath an already registered device at
runtime so we've already got all the software cost of being able to
preregister everything anyway so we may as well use it.
> 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?
Coldplugging should work.
> > 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?
Well, some devices might be able to work with no platform data but
that's not going to be true in the general case.
--
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/
Powered by blists - more mailing lists