Several DMA pools of the EHCI/UHCI USB host controller driver declare
that buffers should not cross 4K boundaries. If this property is not met
fatal errors like NMIs may happen during USB operation.
Discussed in issue #5000
Certain USB devices do not react anymore after an endpoint reset
in the use case of USB devices passed through to a virtual machine.
When investigating the only USB session client that needs the
flush transfers request - namely the Qemu xhci model used in
VirtualBox - there seems to be no need to reset the endpoint in fact.
Fixgenodelabs/genode#5050
This commit adds support to initialize the timekeeping for
the Linux subsystem with the value from the RTC.
Only the seconds part of timespec64 is supported.
Issue genodelabs/genode#4957
On x86, DMA buffers are actually always mapped as cached. We should
therefore actually ask for a cached buffer in order to avoid confusion.
genodelabs/genode#5000
The driver is superseded by the USB network driver (usb_net) which also
contains MBIM support for LTE modems previously provided by this
driver.
issue #4958
The drivers uses the 'virt_linux' api and the current lx_kit
implementation. It is a drop-in replacement for the Linux 4.16.3 based
version.
issue #4958
* During a session-close, the device-specific usb task and driver data
gets freed. Part of it was the RPC data. To prevent use-after-free
turn it into a pointer and leave it on the stack of the caller thread
* During a device release, URBs discards, and reset operation the Linux task
might get blocked, and then a RPC caller task might return if the RPC
operation was marked as finished already, although it hasn't succeeded yet
* USB devio RESET has to be done before a device release to be effective
Fixgenodelabs/genode#4969
* Within flush_transfer of the USB session a given entrypoint gets
resetted, to be effective al related URBs need to be discarded first
* Discarding URBs shall be done in reverse order, like libusb is doing it,
where it warns about potential races otherwise
Ref genodelabs/genode#4969
* Allow support for kernel configurations without CONFIG_IRQ_DOMAIN_HIERARCHY
* Export `irq_domain` instantiated for driver-specific extensions of the irqchip
Fixgenodelabs/genode#4964
This commit extends the Lx_kit initialization function by passing in
a signal handler that is used to perform the normally occurring
scheduler execution and is a follow-up change for the decoupling
scheduler execution commit.
Instead of burying the signal handler in the 'Lx_kit::Scheduler'
object it is provided by the main object where the driver is free
to perform any additional step before or after executing the scheduler.
Issue #4927Fixes#4952
Since the wireless LAN driver is actually a 'Libc::Component' due to
its incorporation of the 'wpa_spplicant' application, we have to
intercept its construction because we have to initialize the Lx_kit
environment before any static ctors are executed. Most Linux initcalls
are implemented as ctors that will be otherwise implicitly executed
before the controll is given to us in 'Libc::Component::construct'.
Issue #4927.
Prevent missing new RPC calls handed over to a Linux task
of a corresponding usb-device, while that task blocked
during enqueuing of asynchronous URBs.
Fixedgenodelabs/genode#4955
Decoupling the scheduler execution can lead to missed interrupts
because the current implementation only handles one pending
interrupt and requires immediate processing.
This commit introduces a helper object that is used to capture
any occuring interrupts that are then handled consecutively.
Issue #4927.
Prior to this commit, whenever an external event occurred, for example
timer or interrupt, the corresponding I/O signal handler was triggered.
This handler unblocked the task waiting for the event and initiated the
immediate execution of all unblocked tasks. Since these tasks may hit
serialization points, e.g. synchronously waiting for packet stream
operations, that require handling of other I/O signals this leads to
nested execution. This, however, is not supported and mixes application
and I/O level signal handling.
The flagging of the scheduling intent is now decoupled from its
execution by using an application level signal handler that is run in
the context of the components main entrypoint. The I/O signal handler
now triggers the scheduling execution by sending a local signal to
the EP.
Since it might be necessary to execute a pending schedule from the EP
directly the scheduler is extended with the 'execute' member function
that performs the check that the scheduler is called from within the
EP and triggers the execution afterwards.
Issue #4927.
