On Tue, Sep 15, 2015 at 01:40:30PM +0800, Barry Song wrote:
> 2015-09-14 15:17 GMT+08:00 Peter Chen :
> > On Tue, Aug 11, 2015 at 09:43:13AM +, Barry Song wrote:
> >> From: Rong Wang
> >>
> >> Chipidea puts ci information to drvdata, but this
2015-09-14 15:17 GMT+08:00 Peter Chen :
> On Tue, Aug 11, 2015 at 09:43:13AM +, Barry Song wrote:
>> From: Rong Wang
>>
>> Chipidea puts ci information to drvdata, but this overwrites the drvdata
>> placed by EHCI core. EHCI core thinks drvdata is
On Tue, Aug 11, 2015 at 09:43:13AM +, Barry Song wrote:
> From: Rong Wang
>
> Chipidea puts ci information to drvdata, but this overwrites the drvdata
> placed by EHCI core. EHCI core thinks drvdata is ehci_hcd. We can find this
> from codes like ehci-sysfs.c:
> static
On Mon, 17 Aug 2015, Peter Chen wrote:
That's not quite what I had in mind. I was thinking of something more
like this:
Platform device drvdata struct usb_pointers
|
|
|---|---|
|
On Fri, Aug 14, 2015 at 10:26:35AM -0400, Alan Stern wrote:
On Fri, 14 Aug 2015, Peter Chen wrote:
In the old days, a single device could be a USB host controller and
nothing else. Then later, a single device could be either a host
controller or a device controller. Now a single
On Thu, Aug 13, 2015 at 11:01:18AM -0400, Alan Stern wrote:
On Thu, 13 Aug 2015, Peter Chen wrote:
Alan, do you have any suggestions? Currently, IP core driver and ehci
core both takes its internal structure as driver data. Thanks.
It's not just ehci-hcd: The USB core stores the
On Fri, Aug 14, 2015 at 10:26:35AM -0400, Alan Stern wrote:
On Fri, 14 Aug 2015, Peter Chen wrote:
In the old days, a single device could be a USB host controller and
nothing else. Then later, a single device could be either a host
controller or a device controller. Now a single
On Fri, 14 Aug 2015, Peter Chen wrote:
In the old days, a single device could be a USB host controller and
nothing else. Then later, a single device could be either a host
controller or a device controller. Now a single device can be both.
Obviously this causes problems for our
On Fri, 14 Aug 2015, Felipe Balbi wrote:
That's not quite what I had in mind. I was thinking of something more
like this:
Platform device drvdata struct usb_pointers
|
|
|---|---|
|
On Thu, 13 Aug 2015, Peter Chen wrote:
Alan, do you have any suggestions? Currently, IP core driver and ehci
core both takes its internal structure as driver data. Thanks.
It's not just ehci-hcd: The USB core stores the hcd address as driver
data. usb_create_shared_hcd() does:
On Wed, 12 Aug 2015, Peter Chen wrote:
On Tue, Aug 11, 2015 at 09:43:13AM +, Barry Song wrote:
From: Rong Wang rong.w...@csr.com
Chipidea puts ci information to drvdata, but this overwrites the drvdata
placed by EHCI core. EHCI core thinks drvdata is ehci_hcd. We can find this
On Wed, Aug 12, 2015 at 10:45:37AM -0400, Alan Stern wrote:
On Wed, 12 Aug 2015, Peter Chen wrote:
On Tue, Aug 11, 2015 at 09:43:13AM +, Barry Song wrote:
From: Rong Wang rong.w...@csr.com
Chipidea puts ci information to drvdata, but this overwrites the drvdata
placed by EHCI
On Tue, Aug 11, 2015 at 09:43:13AM +, Barry Song wrote:
From: Rong Wang rong.w...@csr.com
Chipidea puts ci information to drvdata, but this overwrites the drvdata
placed by EHCI core. EHCI core thinks drvdata is ehci_hcd. We can find this
from codes like ehci-sysfs.c:
static ssize_t
From: Rong Wang rong.w...@csr.com
Chipidea puts ci information to drvdata, but this overwrites the drvdata
placed by EHCI core. EHCI core thinks drvdata is ehci_hcd. We can find this
from codes like ehci-sysfs.c:
static ssize_t show_companion(struct device *dev,
14 matches
Mail list logo