On Fri, 26 Oct 2012, Sebastian Andrzej Siewior wrote:
> On Thu, Oct 25, 2012 at 10:36:14AM -0400, Alan Stern wrote:
> > What happens if the drivers get probed in the wrong order? That is, if
> > ehci-platform gets probed before ehci-spear (or whatever)?
>
> The "wrong" driver may get loaded.
T
On Thu, Oct 25, 2012 at 10:36:14AM -0400, Alan Stern wrote:
> What happens if the drivers get probed in the wrong order? That is, if
> ehci-platform gets probed before ehci-spear (or whatever)?
The "wrong" driver may get loaded. Right now, you should have them all in
one driver. For instance the
On 10/25/2012 04:23 AM, Sebastian Andrzej Siewior wrote:
> On Wed, Oct 24, 2012 at 08:55:27AM -1000, Mitch Bradley wrote:
So by listing "usb-ehci" in its device ID table, a driver would
essentially be saying that it can handle _all_ USB EHCI controllers.
>>
>>
>> Actually, it means that
On Thu, 25 Oct 2012, Sebastian Andrzej Siewior wrote:
> On Wed, Oct 24, 2012 at 08:55:27AM -1000, Mitch Bradley wrote:
> > >> So by listing "usb-ehci" in its device ID table, a driver would
> > >> essentially be saying that it can handle _all_ USB EHCI controllers.
> >
> >
> > Actually, it mea
On Wed, Oct 24, 2012 at 08:55:27AM -1000, Mitch Bradley wrote:
> >> So by listing "usb-ehci" in its device ID table, a driver would
> >> essentially be saying that it can handle _all_ USB EHCI controllers.
>
>
> Actually, it means that the driver can handle at least USB EHCI
> controllers that
On Wed, 24 Oct 2012, Stephen Warren wrote:
> > What's the reason for listing the generic value if drivers can't key
> > off it? Does it contain any information that's not already present in
> > the specific values?
>
> This may or may not be a mistake.
>
> The idea is that usb-ehci is included
On Wed, 24 Oct 2012, Mitch Bradley wrote:
> >> Ah, now I'm starting to get the picture.
> >>
> >> So by listing "usb-ehci" in its device ID table, a driver would
> >> essentially be saying that it can handle _all_ USB EHCI controllers.
>
>
> Actually, it means that the driver can handle at lea
On 10/24/2012 8:09 AM, Stephen Warren wrote:
> On 10/24/2012 11:46 AM, Alan Stern wrote:
>> On Wed, 24 Oct 2012, Stephen Warren wrote:
>>
How do we determine which existing drivers claim to support usb-ehci?
A quick search under arch/ and drivers/ turns up nothing but
drivers/usb/h
On Wednesday 24 October 2012 14:04:12 Alan Stern wrote:
> On Wed, 24 Oct 2012, Florian Fainelli wrote:
>
> > As long as no one enables both ehci-platform and ehci-ppc-of at the same
> > time
> > there is no problem. ehci-ppc-of should be removed in favor of ehci-platform
> > and make sure that th
On 10/24/2012 11:46 AM, Alan Stern wrote:
> On Wed, 24 Oct 2012, Stephen Warren wrote:
>
>>> How do we determine which existing drivers claim to support usb-ehci?
>>> A quick search under arch/ and drivers/ turns up nothing but
>>> drivers/usb/host/ehci-ppc-of.c. Changing it to a more HW-specif
On Wed, 24 Oct 2012, Florian Fainelli wrote:
> As long as no one enables both ehci-platform and ehci-ppc-of at the same time
> there is no problem. ehci-ppc-of should be removed in favor of ehci-platform
> and make sure that the specific quirk in ehci-ppc-of also gets ported, other
> that I see n
On Wed, 24 Oct 2012, Rob Herring wrote:
> On 10/24/2012 11:44 AM, Alan Stern wrote:
> > On Wed, 24 Oct 2012, Stephen Warren wrote:
> >
> >> We should absolutely avoid Linux-specific properties where possible.
> >>
> >> That said, what Linux-specific properties are you talking about? The
> >> prop
On Wed, 24 Oct 2012, Stephen Warren wrote:
> > How do we determine which existing drivers claim to support usb-ehci?
> > A quick search under arch/ and drivers/ turns up nothing but
> > drivers/usb/host/ehci-ppc-of.c. Changing it to a more HW-specific
> > match should be easy enough, and then "
On 10/24/2012 11:44 AM, Alan Stern wrote:
> On Wed, 24 Oct 2012, Stephen Warren wrote:
>
>> We should absolutely avoid Linux-specific properties where possible.
>>
>> That said, what Linux-specific properties are you talking about? The
>> properties discussed here (has-synopsys-hc-bug, no-io-watch
On Wednesday 24 October 2012 12:54:05 Alan Stern wrote:
> On Wed, 24 Oct 2012, Stephen Warren wrote:
>
> > Device tree files always need a completely specific value in the
> > compatible property, even when less-specific/more-generic values are
> > also present. So for example, the Linux driver mi
On Wed, 24 Oct 2012, Stephen Warren wrote:
> Device tree files always need a completely specific value in the
> compatible property, even when less-specific/more-generic values are
> also present. So for example, the Linux driver might only care about the
> following existing:
>
> compatible = "u
On 10/24/2012 10:44 AM, Alan Stern wrote:
> On Wed, 24 Oct 2012, Stephen Warren wrote:
>
>> We should absolutely avoid Linux-specific properties where possible.
>>
>> That said, what Linux-specific properties are you talking about? The
>> properties discussed here (has-synopsys-hc-bug, no-io-watch
On Wednesday 24 October 2012 12:38:42 Alan Stern wrote:
> On Wed, 24 Oct 2012, Stephen Warren wrote:
>
> > On 10/24/2012 09:26 AM, Sebastian Andrzej Siewior wrote:
> > > On Wed, Oct 24, 2012 at 10:57:00AM -0400, Alan Stern wrote:
> > >> Under the circumstances, do we really need a new binding docu
On 10/24/2012 10:38 AM, Alan Stern wrote:
> On Wed, 24 Oct 2012, Stephen Warren wrote:
>
>> On 10/24/2012 09:26 AM, Sebastian Andrzej Siewior wrote:
>>> On Wed, Oct 24, 2012 at 10:57:00AM -0400, Alan Stern wrote:
Under the circumstances, do we really need a new binding document for
the
On Wed, 24 Oct 2012, Stephen Warren wrote:
> We should absolutely avoid Linux-specific properties where possible.
>
> That said, what Linux-specific properties are you talking about? The
> properties discussed here (has-synopsys-hc-bug, no-io-watchdog, has-tt)
> are all purely a description of HW
On Wed, 24 Oct 2012, Stephen Warren wrote:
> On 10/24/2012 09:26 AM, Sebastian Andrzej Siewior wrote:
> > On Wed, Oct 24, 2012 at 10:57:00AM -0400, Alan Stern wrote:
> >> Under the circumstances, do we really need a new binding document for
> >> the ehci-platform driver?
>
> It seems reasonable
On Wednesday 24 October 2012 10:16:31 Stephen Warren wrote:
> On 10/24/2012 09:26 AM, Sebastian Andrzej Siewior wrote:
> > On Wed, Oct 24, 2012 at 10:57:00AM -0400, Alan Stern wrote:
> >> Under the circumstances, do we really need a new binding document for
> >> the ehci-platform driver?
>
> It s
On 10/24/2012 08:57 AM, Alan Stern wrote:
> On Tue, 23 Oct 2012, Rob Herring wrote:
>
>> On 10/23/2012 02:33 PM, Alan Stern wrote:
>>> On Tue, 23 Oct 2012, Stephen Warren wrote:
>>>
> Nothing intrinsically distinguishes this class of hardware. The only
> thing these devices have in common
On 10/24/2012 09:26 AM, Sebastian Andrzej Siewior wrote:
> On Wed, Oct 24, 2012 at 10:57:00AM -0400, Alan Stern wrote:
>> Under the circumstances, do we really need a new binding document for
>> the ehci-platform driver?
It seems reasonable to add the new properties to usb-ehci.txt, since
they do
On Wed, Oct 24, 2012 at 10:57:00AM -0400, Alan Stern wrote:
> Under the circumstances, do we really need a new binding document for
> the ehci-platform driver? We should be able to use the existing
> usb-ehci binding, perhaps with some new properties added:
>
> has-synopsys-hc-bug
>
On Tue, 23 Oct 2012, Rob Herring wrote:
> On 10/23/2012 02:33 PM, Alan Stern wrote:
> > On Tue, 23 Oct 2012, Stephen Warren wrote:
> >
> >>> Nothing intrinsically distinguishes this class of hardware. The only
> >>> thing these devices have in common is that they can be managed by
> >>> Linux's
On 10/23/2012 02:33 PM, Alan Stern wrote:
> On Tue, 23 Oct 2012, Stephen Warren wrote:
>
>>> Nothing intrinsically distinguishes this class of hardware. The only
>>> thing these devices have in common is that they can be managed by
>>> Linux's ehci-platform driver.
>>
>> I don't agree. They're al
On Tue, 23 Oct 2012, Stephen Warren wrote:
> > Nothing intrinsically distinguishes this class of hardware. The only
> > thing these devices have in common is that they can be managed by
> > Linux's ehci-platform driver.
>
> I don't agree. They're all EHCI USB controllers (or all EHCI USB
> contr
On 10/23/2012 11:59 AM, Alan Stern wrote:
> On Tue, 23 Oct 2012, Stephen Warren wrote:
>
So, rather than:
compatible = "usb-ehci";
You should always have e.g.:
compatible = "nvidia,tegra20-ehci", "usb-ehci";
Given that, there is then always enough infor
On Tue, 23 Oct 2012, Stephen Warren wrote:
> >> So, rather than:
> >>
> >> compatible = "usb-ehci";
> >>
> >> You should always have e.g.:
> >>
> >> compatible = "nvidia,tegra20-ehci", "usb-ehci";
> >>
> >> Given that, there is then always enough information in the device tree
> >> for the driver
On 10/23/2012 08:10 AM, Alan Stern wrote:
> On Mon, 22 Oct 2012, Stephen Warren wrote:
>
>>> I see. But why would it be done this way instead having a separate
>>> property?
>>
>> Well, I did say normally:-)
>>
>> I can certainly see an argument for representing these differences using
>> custom
On Mon, 22 Oct 2012, Stephen Warren wrote:
> > I see. But why would it be done this way instead having a separate
> > property?
>
> Well, I did say normally:-)
>
> I can certainly see an argument for representing these differences using
> custom properties, rather than deriving the information
On 10/22/2012 01:00 PM, Alan Stern wrote:
> On Mon, 22 Oct 2012, Stephen Warren wrote:
>
> +- has-tt : controller has transaction translator(s).
> +- has-synopsys-hc-bug : controller has the synopsys hc bug
That would normally be determined by the driver based on the particular
>
On Mon, 22 Oct 2012, Stephen Warren wrote:
> >>> +- has-tt : controller has transaction translator(s).
> >>> +- has-synopsys-hc-bug : controller has the synopsys hc bug
> >>
> >> That would normally be determined by the driver based on the particular
> >> compatible value that is in device tree.
>
On 10/22/2012 11:34 AM, Alan Stern wrote:
> On Mon, 22 Oct 2012, Stephen Warren wrote:
>
>> On 10/20/2012 04:10 PM, Tony Prisk wrote:
>>> Add a binding document for ehci-platform driver.
>
>>> +Optional properties:
>>> +- caps-offset : offset to the capabilities register (default = 0)
>>> +- has-
On Mon, 22 Oct 2012, Stephen Warren wrote:
> On 10/20/2012 04:10 PM, Tony Prisk wrote:
> > Add a binding document for ehci-platform driver.
> > +Optional properties:
> > +- caps-offset : offset to the capabilities register (default = 0)
> > +- has-tt : controller has transaction translator(s).
>
On 10/20/2012 04:10 PM, Tony Prisk wrote:
> Add a binding document for ehci-platform driver.
>
> Signed-off-by: Tony Prisk
> ---
> .../devicetree/bindings/usb/ehci-platform.txt | 27
>
> 1 file changed, 27 insertions(+)
> create mode 100644 Documentation/devicetree/
Le dimanche 21 octobre 2012 00:10:32, Tony Prisk a écrit :
> Add a binding document for ehci-platform driver.
>
> Signed-off-by: Tony Prisk
> ---
> .../devicetree/bindings/usb/ehci-platform.txt | 27
> 1 file changed, 27 insertions(+)
> create mode 100644 Documentatio
Add a binding document for ehci-platform driver.
Signed-off-by: Tony Prisk
---
.../devicetree/bindings/usb/ehci-platform.txt | 27
1 file changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/ehci-platform.txt
diff --git a/Documentation/
39 matches
Mail list logo
