Supermicro LCD screen modules seem to not support accessing reports through
the control pipes, but working fine with the interrupt pipes.
Sponsored by: iXsystems, Inc.
MFC after: 1 week
deterministically handled after the corresponding PHY drivers when
loaded as modules. Otherwise, when these MAC/PHY driver pairs are
compiled into a single module probing the PHY driver may fail. This
makes r151438 and r226154 actually work. [1]
Reported and tested by: yongari (fxp(4))
- Use DEVMETHOD_END.
- Use NULL instead of 0 for pointers.
Submitted by: jhb [1]
MFC after: 3 days
This will give you more bandwidth for isochronous
FULL speed applications connected through a
High Speed HUB.
This patch has been tested with XHCI and EHCI.
MFC after: 1 week
and not asynchronously. This fixes problems related to USB system
suspend and resume. It is assumed that we are always allowed to sleep
from the device_suspend() method.
MFC after: 1 week
Submitted by: jkim
Code should just use the devtoname() function to obtain the name of a
character device. Also add const keywords to pieces of code that need it
to build properly.
MFC after: 2 weeks
primitives by breaking stop_scheduler into a per-thread variable.
Also, store the new td_stopsched very close to td_*locks members as
they will be accessed mostly in the same codepaths as td_stopsched and
this results in avoiding a further cache-line pollution, possibly.
STOP_SCHEDULER() was pondered to use a new 'thread' argument, in order to
take advantage of already cached curthread, but in the end there should
not really be a performance benefit, while introducing a KPI breakage.
In collabouration with: flo
Reviewed by: avg
MFC after: 3 months (or never)
X-MFC: r228424
Currently the code is not built by any modules. That will
be fixed later. The Atmel ARM bus interface file part of this
commit is just for sake of example. All registers and bits are
declared like macros and not C-structures like in official
Synopsis header files. This driver mostly origins from the
musb_otg.c driver in FreeBSD except that the chip specific
programming has been replaced by the one for DWC 2.0 USB OTG.
Some parts related to system suspend and resume have been left
like empty functions for the future. USB suspend and resume is
fully supported.
This change is designed to let USB keyboard work in the panic context
with stop_scheduler_on_panic=1. Most of change consists of removing
mtx_owned() checks where they can be easily avoided. Some additional
lock cleanup is performed along the way.
A list of the smaller changes:
- newbus methods should be executed with Giant already held, just assert
this
- kbd methods called in the non-polling context should be executed with
Giant already held, just assert this
- Giant is recursive, so we should just take it where we must have it,
without redundant checks if we already have it
- thanks to recent syscons changes we don't need to go through the hoops
to detect if kernel is going to poll us; polling mode is now clearly
separated from non-polling mode
- at present the polling mode can be entered by only one thread
- document special cases in greater detail
Please note that the ukbd code and underlying USB code still lve
dangerously in the kdb context by trying to obtain various locks
including the Giant. If any of those locks are already held by the
stopped threads, then the things would blow up.
Another limitation of the ukbd driver is that it is detached before a
system enters the halt state.
With this commit we can enable kern.stop_scheduler_on_panic by default,
that should not introduce any regressions.
Reviewed by: hselasky
MFC after: 3 months
X-MFC after: r228424, r228760
When SCHEDULER_STOPPED() is true the mtx_owned() call may return
an unexpected and thus meaningless result.
So, in the code paths that can be reached when SCHEDULER_STOPPED() is true
we need to protect the mtx_owned() calls with the SCHEDULER_STOPPED()
checks and ensure that an appropriate branch is taken in each case.
Reviewed by: hselasky
MFC after: 3 months
X-MFC after: r228424
At the moment grab and ungrab methods of all console drivers are no-ops.
Current intended meaning of the calls is that the kernel takes control of
console input. In the future the semantics may be extended to mean that
the calling thread takes full ownership of the console (e.g. console
output from other threads could be suspended).
Inspired by: bde
MFC after: 2 months
