Re: [coreboot] USB HUB depth

[Joshua Pincus]

Hi Patrick and Nico,

Everything works now as expected.  I wasn't calling usb_poll() properly.

Thanks, again, for the quick responses to my exceedingly naive queries.

JP

On Thu, Mar 9, 2017 at 10:40 AM, Joshua Pincus 
wrote:

> Hi,
>
> Cool.  I'm looking at that code now.  Thanks for your help.
> JP
>
> On Thu, Mar 9, 2017 at 10:29 AM, Patrick Georgi 
> wrote:
>
>> 2017-03-09 18:53 GMT+01:00 Joshua Pincus :
>> > Enable_port() merely provides power to those ports.  It doesn't scan
>> them and then attach them in any way.
>> That happens on the next usb_poll(), which calls ->poll() for every
>> device.
>> In case of hubs, that's generic_hub_poll(), which covers everything else.
>>
>>
>> Patrick
>>
>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] USB HUB depth

[Joshua Pincus]

Hi,

Cool.  I'm looking at that code now.  Thanks for your help.
JP

On Thu, Mar 9, 2017 at 10:29 AM, Patrick Georgi  wrote:

> 2017-03-09 18:53 GMT+01:00 Joshua Pincus :
> > Enable_port() merely provides power to those ports.  It doesn't scan
> them and then attach them in any way.
> That happens on the next usb_poll(), which calls ->poll() for every device.
> In case of hubs, that's generic_hub_poll(), which covers everything else.
>
>
> Patrick
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] USB HUB depth

[Patrick Georgi via coreboot]

2017-03-09 18:53 GMT+01:00 Joshua Pincus :
> Enable_port() merely provides power to those ports.  It doesn't scan them and 
> then attach them in any way.
That happens on the next usb_poll(), which calls ->poll() for every device.
In case of hubs, that's generic_hub_poll(), which covers everything else.


Patrick

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] USB HUB depth

[Joshua Pincus]

Hi Nico,

Thanks for your email.

Indeed, I'm talking about libpayload's USB stack.  There does seem to be a
limit as I don't see usbhub.c or generic_hub.c calling any routines beyond
enable_port() for the ports beyond the HUB.  Enable_port() merely provides
power to those ports.  It doesn't scan them and then attach them in any way.

JP

On Thu, Mar 9, 2017 at 5:16 AM, Nico Huber  wrote:

> On 09.03.2017 11:18, Joshua Pincus wrote:
> > Hi,
> >
> > I'm new to coreboot and to this group.  As this is my first post, let me
> > thank you folks for developing an impressive and incredibly useful
> product!
>
> Hi Joshua,
>
> > I recently fired up the coreboot USB stack on an x86 development board.
> > The USB stack reported back that I have 2 EHCI host controllers on the
> > board.  Each controller, in turn, has a number of ports.  Attached to at
> > most 1 of the ports beyond each controller is a USB 2.0 hub.  Each hub,
> in
> > turn, has a number of ports which the coreboot USB stack enables.
>
> are you talking about libpayload's USB stack? coreboot itself doesn't
> have one.
>
> >
> > My issue is this: I see the host controllers get initialized.  I see the
> > aforementioned hubs get initialized.  I see the ports underneath those
> hubs
> > get enabled.  I do not see nor can I find any existing code that scans
> and
> > attaches the ports associated with those hubs.  Consequently, none of the
> > devices (aka keyboard, USB stick, etc.) plugged into the ports beyond
> those
> > hubs are scanned and attached.  Put another way, it looks like the USB
> > stack, as currently written, only scans and attaches devices at tier 0
> and
> > tier 1.  Anything beyond the hub is merely enabled.
> >
> > Am I wrong or missing something?  How difficult would it be to continue
> the
> > process of recursion to subsequent tiers?
>
> If you are talking about libpayload, there shouldn't be an artificial
> limit. Responsible for hub class USB devices is the code in drivers/usb/
> generic_hub.c + drivers/usb/usbhub.c.
>
> Hope that helps,
> Nico
>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] USB HUB depth

[Nico Huber]

On 09.03.2017 11:18, Joshua Pincus wrote:
> Hi,
> 
> I'm new to coreboot and to this group.  As this is my first post, let me
> thank you folks for developing an impressive and incredibly useful product!

Hi Joshua,

> I recently fired up the coreboot USB stack on an x86 development board.
> The USB stack reported back that I have 2 EHCI host controllers on the
> board.  Each controller, in turn, has a number of ports.  Attached to at
> most 1 of the ports beyond each controller is a USB 2.0 hub.  Each hub, in
> turn, has a number of ports which the coreboot USB stack enables.

are you talking about libpayload's USB stack? coreboot itself doesn't
have one.

> 
> My issue is this: I see the host controllers get initialized.  I see the
> aforementioned hubs get initialized.  I see the ports underneath those hubs
> get enabled.  I do not see nor can I find any existing code that scans and
> attaches the ports associated with those hubs.  Consequently, none of the
> devices (aka keyboard, USB stick, etc.) plugged into the ports beyond those
> hubs are scanned and attached.  Put another way, it looks like the USB
> stack, as currently written, only scans and attaches devices at tier 0 and
> tier 1.  Anything beyond the hub is merely enabled.
> 
> Am I wrong or missing something?  How difficult would it be to continue the
> process of recursion to subsequent tiers?

If you are talking about libpayload, there shouldn't be an artificial
limit. Responsible for hub class USB devices is the code in drivers/usb/
generic_hub.c + drivers/usb/usbhub.c.

Hope that helps,
Nico


-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot