Currently when allocating buffers for USB transfers, it is done
once for every transfer rather than once upon creation of the
USB device. This commit changes that by moving allocation of buffers
to the USB Pipe class where they can be reused.
This change unifies the naming convention for kernel tasks.
The goal of this change is to:
- Make the task names more descriptive, so users can more
easily understand their purpose in System Monitor.
- Unify the naming convention so they are consistent.
This name was misleading, as it wasn't really "getting" anything. It has
hence been renamed to `enumerate_interfaces` to reflect what it's
actually doing.
This creates all interfaces when the device is enumerated, with a link
to the configuration that it is a part of. As such, a new class,
`USBInterface` has been introduced to express this state.
Some other parts of the USB stack may require us to perform a control
transfer. Instead of abusing `friend` to expose the default pipe, let's
just expose it via a function.
This also introduces a new class, `USBConfiguration` that stores a
configuration. The device, when instructed, sets this configuration and
holds a pointer to it so we have a record of what configuration is
currently active.
In most cases it's safe to abort the requested operation and go forward,
however, in some places it's not clear yet how to handle these failures,
therefore, we use the MUST() wrapper to force a kernel panic for now.
This is mainly useful when adding an HostController but due to OOM
condition, we abort temporary Vector insertion of a DeviceIdentifier
and then exit the iteration loop to report back the error if occured.
Instead, hold the lock while we copy the contents to a stack-based
Vector then iterate on it without any locking.
Because we rely on heap allocations, we need to propagate errors back
in case of OOM condition, therefore, both PCI::enumerate API function
and PCI::Access::add_host_controller_and_enumerate_attached_devices use
now a ErrorOr<void> return value to propagate errors. OOM Error can only
occur when enumerating the m_device_identifiers vector under a spinlock
and trying to expand the temporary Vector which will be used locklessly
to actually iterate over the PCI::DeviceIdentifiers objects.
Reading from /proc/pci assumes we have PCI enabled and also enumerated.
However, if PCI is disabled for some reason, we can't allow the user to
read from it as there's no valuable data we can supply.
To declare that we don't have a PCI bus in the system we do two things:
1. Probe IO ports before enabling access -
In case we are using the QEMU ISA-PC machine type, IO probing results in
floating bus condition (returning 0xFF values), thus, we know we don't
have PCI bus on the system.
2. Allow the user to specify to not use the PCI bus at all in the kernel
commandline.
This change allow the user to request the kernel to not use any PCI
resources/devices at all.
Also, don't try to initialize devices that rely on PCI if disabled.
We already init receive buffer if we have singleport console, but if
we have multiport console that dynamically allocates ports we never
initted their receive buffers.
There can only be a limited number of functions (only 8).
Also, consider the start bus of the PCI domain when trying to enumerate
other host bridges on bus 0, device 0, functions 1-7 (function 0 is the
main host bridge).
