On Tue, Aug 20, 2013 at 12:01 AM, Mark Brown broo...@kernel.org wrote:
On Mon, Aug 19, 2013 at 08:17:53PM +0800, Ming Lei wrote:
On Sat, Aug 17, 2013 at 9:29 AM, Alan Stern st...@rowland.harvard.edu
wrote:
Aong those lines, I would like to point out that the device concept
embodied in the
On Tue, Aug 20, 2013 at 09:19:07PM +0800, Ming Lei wrote:
On Tue, Aug 20, 2013 at 12:01 AM, Mark Brown broo...@kernel.org wrote:
I can't parse this at all well - why would DT want to refer to ACPI, do
you mean people may wish to look at the code as an example? As Grant
I mean usb-acpi
On Fri, 16 Aug 2013, Mark Brown wrote:
On Fri, Aug 16, 2013 at 03:27:58PM -0400, Alan Stern wrote:
On Fri, 16 Aug 2013, Mark Brown wrote:
or those for getting platform data to a device when it
does enumerate.
? I can't make any sense out of that comment. For one thing, why do
On Fri, 16 Aug 2013, Mark Brown wrote:
The difficulty with the first proposal is that subsystems aren't
designed to allow that sort of thing. They expect to be able to
communicate with the devices they manage, during enumeration and
probing at least. The difficulty with the second
On Sat, Aug 17, 2013 at 9:29 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Fri, 16 Aug 2013, Mark Brown wrote:
Besides, you need to get the platform information to the driver in any
case, no matter how you decide to solve the chicken-and-egg problem.
It shouldn't be a factor in
On Mon, Aug 19, 2013 at 08:17:53PM +0800, Ming Lei wrote:
On Sat, Aug 17, 2013 at 9:29 AM, Alan Stern st...@rowland.harvard.edu wrote:
Aong those lines, I would like to point out that the device concept
embodied in the kernel's data structures can be pretty thin. For
example, it might be
On Thu, 15 Aug 2013, Mark Brown wrote:
No, this really is something that's very much generic to the device and
will apply to anywhere the silicon is used. The power on process for a
device isn't something that changes, the mapping of resources that might
be used in that sequence is but we've
On Fri, Aug 16, 2013 at 10:42:10AM -0400, Alan Stern wrote:
Okay, let's see if I understand your problem. You've got a driver that
...
Is that it?
Yes, I think that's it.
The difficulty with the first proposal is that subsystems aren't
designed to allow that sort of thing. They expect to
On Fri, Aug 16, 2013 at 03:27:58PM -0400, Alan Stern wrote:
On Fri, 16 Aug 2013, Mark Brown wrote:
or those for getting platform data to a device when it
does enumerate.
? I can't make any sense out of that comment. For one thing, why do
you need to send platform data to a device?
On Fri, Aug 16, 2013 at 04:39:47PM -0400, Alan Stern wrote:
On Fri, 16 Aug 2013, Mark Brown wrote:
The device in this context is a running instance of the driver.
It's kind of difficult to understand what you're saying. Obviously the
literal meaning is not what you had in mind, because a
On Fri, 16 Aug 2013, Mark Brown wrote:
Besides, you need to get the platform information to the driver in any
case, no matter how you decide to solve the chicken-and-egg problem.
It shouldn't be a factor in deciding which solution to use.
It's not that this is hard, it's that I don't
On Thu, 15 Aug 2013, Mark Brown wrote:
On Wed, Aug 14, 2013 at 03:39:20PM -0400, Alan Stern wrote:
I don't see the point of all this. Obviously the device can't be used
until it physically appears on the bus. What benefit do you get from
registering it and making it available to
On Thu, Aug 15, 2013 at 10:42:00AM -0400, Alan Stern wrote:
On Thu, 15 Aug 2013, Mark Brown wrote:
So why not bring the device to full power as soon as possible during
boot, and have it registered on the bus in the usual way? Once that's
done, the ordinary runtime PM mechanism will allow the
On Thu, 15 Aug 2013, Mark Brown wrote:
On Thu, Aug 15, 2013 at 10:42:00AM -0400, Alan Stern wrote:
On Thu, 15 Aug 2013, Mark Brown wrote:
So why not bring the device to full power as soon as possible during
boot, and have it registered on the bus in the usual way? Once that's
done,
On Thu, Aug 15, 2013 at 01:55:18PM -0400, Alan Stern wrote:
On Thu, 15 Aug 2013, Mark Brown wrote:
On Thu, Aug 15, 2013 at 10:42:00AM -0400, Alan Stern wrote:
To be honest I don't see how that helps much if you're going to handle
the case where platform data is required to enumerate the
On Thu, 15 Aug 2013, Mark Brown wrote:
On Thu, Aug 15, 2013 at 01:55:18PM -0400, Alan Stern wrote:
On Thu, 15 Aug 2013, Mark Brown wrote:
On Thu, Aug 15, 2013 at 10:42:00AM -0400, Alan Stern wrote:
To be honest I don't see how that helps much if you're going to handle
the case where
On Thu, Aug 15, 2013 at 04:42:01PM -0400, Alan Stern wrote:
Okay. Here's a restatement of what you wrote above:
In the case where platform data is required to enumerate the
device, you need to know about the device prior to enumeration.
Obviously true.
You need to get
On Mon, Aug 12, 2013 at 09:04:00PM -0400, Alan Stern wrote:
The bus code would need hooks installed wherever the platform wants to
do something extra. This could end up growing to a lot of hooks. How
can the whole thing be done in a reasonable fashion?
I'd expect that we're just looking
On Wed, 14 Aug 2013, Mark Brown wrote:
On Mon, Aug 12, 2013 at 09:04:00PM -0400, Alan Stern wrote:
The bus code would need hooks installed wherever the platform wants to
do something extra. This could end up growing to a lot of hooks. How
can the whole thing be done in a reasonable
On Wed, Aug 14, 2013 at 10:27:26AM -0400, Alan Stern wrote:
On Wed, 14 Aug 2013, Mark Brown wrote:
I'd expect that we're just looking at hooks around connection and
disconnection here here - if we're looking at much more it seems like we
must be doing something wrong.
Connection and
On Wed, 14 Aug 2013, Mark Brown wrote:
On Wed, Aug 14, 2013 at 10:27:26AM -0400, Alan Stern wrote:
On Wed, 14 Aug 2013, Mark Brown wrote:
I'd expect that we're just looking at hooks around connection and
disconnection here here - if we're looking at much more it seems like we
must
On Wed, Aug 14, 2013 at 12:14:06PM -0400, Alan Stern wrote:
On Wed, 14 Aug 2013, Mark Brown wrote:
Yes, so you'd want callbacks when the device actually appears and
disappears.
No, no -- this is exactly the point I was trying to make. The on-board
hub _won't_ appear on the USB bus until
On Wed, 14 Aug 2013, Mark Brown wrote:
On Wed, Aug 14, 2013 at 12:14:06PM -0400, Alan Stern wrote:
On Wed, 14 Aug 2013, Mark Brown wrote:
Yes, so you'd want callbacks when the device actually appears and
disappears.
No, no -- this is exactly the point I was trying to make. The
On Wed, Aug 14, 2013 at 02:35:07PM -0400, Alan Stern wrote:
On Wed, 14 Aug 2013, Mark Brown wrote:
What I'm proposing is that we have a way of telling buses that devices
exist via a mechanism other than their actually being visible on the bus
at the current time. If you're doing that the
On Wed, Aug 14, 2013 at 10:30:44AM -0600, Stephen Warren wrote:
On 08/14/2013 10:14 AM, Alan Stern wrote:
No, no -- this is exactly the point I was trying to make. The on-board
hub _won't_ appear on the USB bus until the GPIOs are set. Therefore
the callback to set the GPIOs needs to be
On Wed, 14 Aug 2013, Mark Brown wrote:
On Wed, Aug 14, 2013 at 02:35:07PM -0400, Alan Stern wrote:
On Wed, 14 Aug 2013, Mark Brown wrote:
What I'm proposing is that we have a way of telling buses that devices
exist via a mechanism other than their actually being visible on the bus
From: Alan Stern
Sent: Wednesday, August 14, 2013 12:39 PM
Now I'm getting confused. It seems we're talking about at least three
very different things here:
A: Devising a mechanism for platform code to do things involving
devices that are dynamically registered on discoverable
On Wed, Aug 14, 2013 at 03:39:20PM -0400, Alan Stern wrote:
I don't see the point of all this. Obviously the device can't be used
until it physically appears on the bus. What benefit do you get from
registering it and making it available to userspace before that?
Two things. One is that
On Wed, Aug 14, 2013 at 08:16:56PM +, Paul Zimmerman wrote:
Mark's original complaint about USB was this:
the device). The hub needs to be plugged into the SoC after the SoC
USB controller has started with some GPIOs so we need to tell the system
that the hub exists and needs to be
On Sun, Aug 11, 2013 at 09:53:01PM -0400, Alan Stern wrote:
On Sun, 11 Aug 2013, Mark Brown wrote:
One example that's bugging me right now is that on the Insignal Arndale
platform there's a USB hub connected to one of the USB ports on the SoC
(not as a PHY, it seems we also need the
[Adding Olof]
On Mon, Aug 12, 2013 at 10:51:36AM +0100, Mark Brown wrote:
On Sun, Aug 11, 2013 at 09:53:01PM -0400, Alan Stern wrote:
On Sun, 11 Aug 2013, Mark Brown wrote:
One example that's bugging me right now is that on the Insignal Arndale
platform there's a USB hub connected to
On Sun, Aug 11, 2013 at 07:02:57PM -0700, Greg Kroah-Hartman wrote:
On Sun, Aug 11, 2013 at 08:08:26PM +0100, Mark Brown wrote:
I know there's been some discussion of this topic but do we have any
general consensus on how to handle such things both from a Linux driver
model point of view
On Mon, Aug 12, 2013 at 12:07:14PM +0100, Mark Rutland wrote:
As I understand it, the wifi chip on the Snow Chromebook has a similar
issue -- it hangs off of a probeable SDIO bus, but needs a regulator
poked for it to turn on and become probeable (see
exynos_wifi_bt_set_power in [1]).
Yes,
On 08/12/2013 05:07 AM, Mark Rutland wrote:
[Adding Olof]
On Mon, Aug 12, 2013 at 10:51:36AM +0100, Mark Brown wrote:
On Sun, Aug 11, 2013 at 09:53:01PM -0400, Alan Stern wrote:
On Sun, 11 Aug 2013, Mark Brown wrote:
One example that's bugging me right now is that on the Insignal Arndale
On Mon, Aug 12, 2013 at 12:08:17PM -0600, Stephen Warren wrote:
In a similar way, I wonder if the USB case can be considered the same
way? This seems less like a good fit since I don't expect the resources
are always so similar there, and also there's the case of the bus being
potentially
On Mon, Aug 12, 2013 at 12:23:44PM +0100, Mark Brown wrote:
On Sun, Aug 11, 2013 at 07:02:57PM -0700, Greg Kroah-Hartman wrote:
On Sun, Aug 11, 2013 at 08:08:26PM +0100, Mark Brown wrote:
I know there's been some discussion of this topic but do we have any
general consensus on how to
On Mon, Aug 12, 2013 at 01:50:07PM -0700, Greg Kroah-Hartman wrote:
On Mon, Aug 12, 2013 at 12:23:44PM +0100, Mark Brown wrote:
I don't think they're bus specific - the main issue with a lot of this
is that they're outside the infrastructure that the bus standardises so
we should have a
On Mon, 12 Aug 2013, Mark Brown wrote:
On Mon, Aug 12, 2013 at 01:50:07PM -0700, Greg Kroah-Hartman wrote:
On Mon, Aug 12, 2013 at 12:23:44PM +0100, Mark Brown wrote:
I don't think they're bus specific - the main issue with a lot of this
is that they're outside the infrastructure that
Looking at the enumerable buses in the kernel I don't see any which have
real support for any kind of registration of devices prior to their
enumeration. Similarly currently all the DT bindings in the kernel I've
been able to notice cover only non-enumerable buses. This generally
makes sense
On Sun, Aug 11, 2013 at 8:08 PM, Mark Brown broo...@kernel.org wrote:
I know there's been some discussion of this topic but do we have any
general consensus on how to handle such things both from a Linux driver
model point of view and from a DT/ACPI point of view?
There is precedence for
On Sun, 11 Aug 2013, Mark Brown wrote:
Looking at the enumerable buses in the kernel I don't see any which have
real support for any kind of registration of devices prior to their
enumeration. Similarly currently all the DT bindings in the kernel I've
been able to notice cover only
On Sun, Aug 11, 2013 at 08:08:26PM +0100, Mark Brown wrote:
Looking at the enumerable buses in the kernel I don't see any which have
real support for any kind of registration of devices prior to their
enumeration. Similarly currently all the DT bindings in the kernel I've
been able to notice
42 matches
Mail list logo