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 nico.huber@secunet.com 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