With the latest change, there are two structures that actually contain
class instance related data. Merge them into usbd_class_dnode, because
there is already a handy macro that can be used in class instances.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Some places have been overlooked, finally get rid of it. Use helpers to
get instance priv and device context.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
USB High-Speed devices must be able to operate at both High-Speed and
Full-Speed. The USB specification allows the device to have different
configurations depending on connection speed. Modify the API to reflect
USB Specification requirements on what can (e.g. configurations) and
what cannot (e.g. VID, PID) be speed dependent.
While the class configurations for different speeds are completely
independent, the actual class instances are shared between operating
speeds (because only one speed can be active at a time). Classes are
free to provide different number of interfaces and/or endpoints for
different speeds. The endpoints are assigned for all operating speeds
during initialization.
Signed-off-by: Tomasz Moń <tomasz.mon@nordicsemi.no>
Introduce usbd_class_iter for keeping endpoint assignment variables
and the single-linked list node. No functional changes right now, but
this paves the way for independent speed specific configurations.
Signed-off-by: Tomasz Moń <tomasz.mon@nordicsemi.no>
When device is not configured, any class or endpoint request must result
in request error. Do not try to find transfer owner because there cannot
be one.
Make sure that the actual handling code path does not depend on the
configured log level because it is absolutely not desired for log level
to affect actual handling.
Signed-off-by: Tomasz Moń <tomasz.mon@nordicsemi.no>
Do not require nil descriptor at the end of descriptor set because it
serves no other purpose than a sentinel. Just end processing on first
NULL pointer within descriptor set.
Signed-off-by: Tomasz Moń <tomasz.mon@nordicsemi.no>
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Add necessary macros and convert UAC2 descriptor test from descriptor
blob to descriptor set. Currently there is only Full-Speed descriptor
set.
Signed-off-by: Tomasz Moń <tomasz.mon@nordicsemi.no>
For specification-compliant high-speed support, we need to support
device quilifiers and other-speed-configuration descriptor requests. We
also need to store different configurations of the class/function
descriptors, which typically only affect the endpoint descriptors. With
this change, the stack expects class/function descriptors to be passed
as an array of struct usb_desc_header pointers to e.g. interface,
interface-specific, and endpoint descriptors, with the last element of
the array pointing to a nil descriptor. And also passed for a specific
speed, for now we support full and high speed configurations.
During instantiation, the class/function implementation must choose the
correct configuration in the full-speed and high-speed descriptor sets
for values such as maximum packet size and bInterval values of interrupt
and isochronous endpoints.
During initialization, the stack reads the highest speed supported by
the controller and uses it to get the appropriate descriptors set
from the instance. If the controller supports only full speed, the stack
configures the class/function descriptor for full speed only, if the
controller supports high speed, the stack configures the descriptors for
high speed only, and a class/function must update the full speed
descriptor during the init callback processing.
During device operation, the class/function implementation must check
the actual speed of the device and use the correct configuration, such
as the endpoint address or maximum packet size.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Save actual device speed in the device context and add helpers to get
highest supported and actual speed.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
The class implementations should not access the members of the struct
usbd_class_node directly.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
This implementation is WIP and has mostly been used to test interface
and endpoint configuration by the stack. For future changes, make the
interfaces more compliant with the USB specification.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Make sure filters set by property-allowlist and property-blocklist
in an including binding are recursively applied to included bindings.
Signed-off-by: Christophe Dufaza <chris@openmarl.org>
Although the PropertySpec.path attribute is documented as
"the file where the property was last modified",
all property specs in Binding.prop2specs will claim
they were last modified by the top-level binding itself.
Consider:
- I1 is a base binding that specifies properties x and y
- I2 is an "intermediate" binding that includes I1,
modifying the specification for property x
- B is a top-level bindings that includes I2,
and specifies an additional property p
When enumerating the properties of B,
we expect the values of PropertySpec.path to tell us:
- y was last modified by I1
- x was last modified by I2
- p was last modified by B
However, the Binding constructor:
- first merges all included bindings into the top-level one
- eventually initializes specifications for all the defined properties
As a consequence, all defined properties claim they were last modified
by the top-level binding file.
We should instead:
- first, take into account their own specifications for the
included properties
- eventually update these specifications with the properties
the top-level binding adds or modifies
Signed-off-by: Christophe Dufaza <chris@openmarl.org>
Make sure the property specs answered by the Binding.prop2specs API
do not all claim (PropertySpec.path) they were last modified
by the top-level binding.
Signed-off-by: Christophe Dufaza <chris@openmarl.org>
add gpio_intel driver with acpi based resource enumeration support.
Also updated test cases overlay with new dts entires.
Signed-off-by: Najumon B.A <najumon.ba@intel.com>
The commit "drivers: ethernet: dsa_ksz8xxx: use
NET_DEVICE_DT_DEFINE_INSTANCE"
(SHA1: f78a081066) replaced
NET_DEVICE_INIT_INSTANCE() with NET_DEVICE_DT_DEFINE_INSTANCE() to
facilitate the removal of deprecated (from Zephyr's 3.2 release)
DT_LABEL() macro.
Unfortunately, the per LAN port initialization is necessary for correct
operation of the DSA driver - otherwise following errors were visible
when LLDP DSA sample (samples/net/dsa/src) was run on ip_k66f board:
<wrn> net_if: iface 0x20001440 is down
<inf> net_dsa_lldp_sample: LLDP pkt recv -> lan1
<inf> net_dsa_lldp_sample: CHASSIS ID: 38:05:43:69:XX:ZZ
<inf> net_dsa_lldp_sample: PORT ID: 38:05:43:69:XX:ZZ
<inf> net_dsa_lldp_sample: TTL: 120s
<inf> net_dsa_lldp_sample: SYSTEM NAME: mtt
<err> net_dsa_lldp_sample: Failed to send, errno 115
The fix is to use again NET_DEVICE_INIT_INSTANCE() with "lan"X name
assigned (to avoid too long names when recommended DT_PROP() is
used instead of DT_LABEL()).
Fixes: f78a081066
Signed-off-by: Lukasz Majewski <lukma@denx.de>
The STM32L152C-DISCOVERY is a development board based on the STM32L152RC
MCU. It is very similar to the stm32l1_disco, which was used as a
reference for the pinmux and defconfig.
stm32l152c_disco board has 256 Kbytes of flash memory, 32 Kbytes of RAM
and 8 Kbytes of data EEPROM.
Signed-off-by: Maxin John <maxin.john@gmail.com>
RISCV_PRIVILEGED implicitly depends on INCLUDE_RESET_VECTOR.
Remove that dependency by adding support for SoCs that
do not need the `__reset` stub.
Signed-off-by: Marcin Szymczyk <marcin.szymczyk@nordicsemi.no>
43de309b3e made a buffer leak.
It was not detected by this test.
Add another configuration, where the final buffer is sent without
fragments in order to exercise the leaky code path.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
This is useful if we want to paste a list of multiple command or add
long advertising data for example.
Signed-off-by: Théo Battrel <theo.battrel@nordicsemi.no>
For more effective code execution on STM32 devices is convenient
to enable flash prefetch buffer.
To be enabled by default, possible to disable using kconfig.
Signed-off-by: Lubos Koudelka <lubos.koudelka@st.com>
If compiling with optimizations (-O2/-Ofast) gcc emits a
maybe-uninitialized warning for `size`.
As far as I can tell, `size` will always be initialized in the cases
where it is used and only left uninitialized in error cases.
Reproduced on main with the multi_endpoint sample on
nrf5340dk/nrf5340/cpuapp.
Signed-off-by: Herman Berget <herman.berget@nordicsemi.no>
When initially reading some of the host code it was unclear
to me why they were needed an how they are used.
By adding some documentation, this can hopefully make it
easier for others to understand these.
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
Add POSIX FD_MGMT option and mark ftruncate as supported
in POSIX Option group Documentation
Signed-off-by: Karthikeyan Krishnasamy <karthikeyan@linumiz.com>
ftruncate should return -1 on errors and it needs to
set appropriate error values in errno
Signed-off-by: Karthikeyan Krishnasamy <karthikeyan@linumiz.com>
Fixes warnings when building documentation due to additional SoC
names being part of the Kconfig symbols which they should not be
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
By default, the generated disassembly file (i.e: the .lst
file) also contains inline source code. This has the
potential to become problematic when attempting to compare
the generated .lst files accross platforms since they may
differ for various reasons. As such, add the option to
control whether the disassembly file should contain inline
source code or not.
The need for this patch was sparked by the differences
observed in the generated .lst file for Linux and Windows
in one of SOF's CI jobs (details in thesofproject/sof/issues/9034),
which were caused by the addition of the inline source code.
With this, we can keep testing for reproducible builds while
not having to deal with differences in the .lst files caused
by things such as having ".." include paths.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Johann Fischer