On Fri, 30 Nov 2012, Andy Green (林安廸) wrote:
I have everything discussed above ready for a try#2, including the
descendant matching stuff in separate patches. The code got a lot
smaller and better with the _ops struct.
The new code can attach the assets to the targeted hub port as
On Thu, 29 Nov 2012, Andy Green wrote:
However I think what you're saying about binding to hub power is good.
The hub ports are not devices, but it would be possible to bind an asset
array to them and make the pre- and post- code functions.
In the 3.6 kernel, hub ports are not devices. In
On 11/30/2012 01:57 AM, the mail apparently from Alan Stern included:
On Thu, 29 Nov 2012, Andy Green wrote:
However I think what you're saying about binding to hub power is good.
The hub ports are not devices, but it would be possible to bind an asset
array to them and make the pre- and post-
On 11/30/2012 04:58 AM, the mail apparently from Andy Green included:
On 11/30/2012 01:57 AM, the mail apparently from Alan Stern included:
On Thu, 29 Nov 2012, Andy Green wrote:
However I think what you're saying about binding to hub power is good.
The hub ports are not devices, but it would
This adds regulators which are controlled by the OMAP4 PandaBoard (ES)'s
EHCI logical root hub existing.
The regulators are made a device_asset of the EHCI logical root hub by
passing them through the hsusb - mfd path. Although the ehci-related
platform_device is created at boot time, it is not
On 11/28/2012 02:59 PM, Andy Green wrote:
This adds regulators which are controlled by the OMAP4 PandaBoard (ES)'s
EHCI logical root hub existing.
The regulators are made a device_asset of the EHCI logical root hub by
passing them through the hsusb - mfd path. Although the ehci-related
On 11/28/2012 11:06 PM, the mail apparently from Roger Quadros included:
Hi Roger -
On 11/28/2012 02:59 PM, Andy Green wrote:
This adds regulators which are controlled by the OMAP4 PandaBoard (ES)'s
EHCI logical root hub existing.
The regulators are made a device_asset of the EHCI logical
