CVS log for src/sys/dev/usb/ehcivar.h

Up to [cvs.NetBSD.org] / src / sys / dev / usb

Request diff between arbitrary revisions

Default branch: MAIN
Current tag: isaki-audio2-base

Revision 1.46 / (download) - annotate - [select for diffs], Tue Sep 18 02:00:06 2018 UTC (5 years, 7 months ago) by mrg
Branch: MAIN
CVS Tags: phil-wifi-20191119, phil-wifi-20190609, pgoyette-compat-20190127, pgoyette-compat-20190118, pgoyette-compat-1226, pgoyette-compat-1126, pgoyette-compat-1020, pgoyette-compat-0930, netbsd-9-base, netbsd-9-3-RELEASE, netbsd-9-2-RELEASE, netbsd-9-1-RELEASE, netbsd-9-0-RELEASE, netbsd-9-0-RC2, netbsd-9-0-RC1, netbsd-9, isaki-audio2-base, isaki-audio2, is-mlppp-base, is-mlppp, ad-namecache-base3, ad-namecache-base2, ad-namecache-base1, ad-namecache-base, ad-namecache
Changes since 1.45: +11 -1 lines
Diff to previous 1.45 (colored)

implement a gross hack to fix "boot -a" on systems with usb keyboards on
systems with ehci handover to uhci (and maybe ohci), and fix a similar
problem for "boot -s".

there is effort to ensure that all devices attached via USB are probed
before RB_ASKNAME or RB_SINGLE attempts to ask any questions on the console,
and largely this works, often by chance, today, for USB disks and root.
i've recently pushed this more into uhub and general USB device attachment
as well, and kept a config_pending reference across the first explore of
a bus.  these fix many issues with directly attached hubs.

however, on systems where devices connected to ehci ports are handed over
to a companion uhci or ohci port, it may not be the first, or even second,
bus explore that finds the device finally before attachment, and at this
point all config_pending references are dropped.

there is no direct communication between drivers, the potentials are
looked up but their device_t is only used for generic things like the name,
so informing the correct companion to expect a device and deal with the
config_pending references is not possible without some fairly ugly layer
violations or multi-level callbacks (eg, we have "ehci0", and usually an
the relevant companion, eg, "uhci2", but it is the uhub that uhci2 has
attached that will deal with the device attachment.)

with the above fixes to generic USB code, the disown happens during the
first explore.  the hack works by, at this point, checking if (a) root
is not mounted, (b) single user or ask name are set, and (c) if the hack
as not been triggered already.  if all 3 conditions are true, then a
config_pending_incr() is called and a callback is triggered for (default)
5 seconds to call config_pending_decr().  ehci detach pauses waiting for
this callback if scheduled.

this allows enough time for the uhub and the ukbd/wskbd to attach before
the RK_ASKROOT prompts appear.  testing shows it takes between 1.5 and
2 seconds for the keyboard to appear after the disown occurs.


Index: dev/usb/ehcivar.c
- new sc_compcallout, sc_compcallout, sc_complock, and a state for th
  handover hack.

Index: dev/usb/ehci.c
ehci_init():
- use aprint_normal_dev() instead of manual device_xname().
- initialise sc_compcallout, sc_compcallout, sc_complock, and sc_comp_state.
ehci_detach():
- if there are companion controllers, tear own the above, including waiting
  if there is a callback scheduled.
ehci_disown_callback():
- new callout to call config_pending_decr() in the the future.
  schedule this ca
ehci_disown_sched_callback():
- if booting to single user or asking names, call config_pending_incr() and
  schedule the callout above, default 5 second delay.
ehci_disown():
- if disowning a port call ehci_disown_sched_callback().

This form allows you to request diff's between any two revisions of a file. You may select a symbolic revision name using the selection box or you may type in a numeric name using the type-in text box.