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
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
On Tue, Aug 20, 2013 at 09:19:07PM +0800, Ming Lei wrote:
> On Tue, Aug 20, 2013 at 12:01 AM, Mark Brown 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 provides one
On Tue, Aug 20, 2013 at 12:01 AM, Mark Brown 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
>> wrote:
>
>> > Aong those lines, I would like to point out that the device concept
>> > embodied in the kernel's data structures can
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:
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 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 Mon, Aug 19, 2013 at 08:17:53PM +0800, Ming Lei wrote:
> On Sat, Aug 17, 2013 at 9:29 AM, Alan Stern 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 little more than a
On Sat, Aug 17, 2013 at 9:29 AM, Alan Stern 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 deciding which
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 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
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,
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
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
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
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, 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
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
> > >
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
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
>
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
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
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 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
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
> 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
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
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
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
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
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
On 08/14/2013 10:14 AM, Alan Stern wrote:
> 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 -
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
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
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
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
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 08/14/2013 10:14 AM, Alan Stern wrote:
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
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 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
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
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
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 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
On Sun, Aug 11, 2013 at 11:08:37PM +0100, Grant Likely wrote:
> full enumerating like that with either ACPI or FDT, but we could allow
> for sparse population of devices when something is fixed like a
> soldered down USB hub or USB Ethernet MAC.
I agree, there's no point in listing things that
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]).
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
[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
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
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 Sun, Aug 11, 2013 at 11:08:37PM +0100, Grant Likely wrote:
full enumerating like that with either ACPI or FDT, but we could allow
for sparse population of devices when something is fixed like a
soldered down USB hub or USB Ethernet MAC.
I agree, there's no point in listing things that can
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
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
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 8:08 PM, 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 and from a DT/ACPI point of view?
There is precedence for describing
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
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
88 matches
Mail list logo
