Skip to content

Conversation

@rodrigopex
Copy link

@fabiobaltieri that is a PR adding zbus support for the input subsys.

Add the zbus support to input subsystem.

Signed-off-by: Rodrigo Peixoto <[email protected]>
Remove the sync parameter from the callback function.

Signed-off-by: Rodrigo Peixoto <[email protected]>
Add an input subsys sample using zbus.

Signed-off-by: Rodrigo Peixoto <[email protected]>
@fabiobaltieri
Copy link
Owner

fabiobaltieri pushed a commit that referenced this pull request Jan 18, 2024
Previously the sample was using some headers that aren't
available to the host, now we can add a `Makefile.host` to
compile the example on a POSIX OS like Linux:

```
# Go to the sample dir
cd ${ZEPHYR_BASE}/samples/posix/uname

# Compile the sample
make -f Makefile.host

# Run the binary
./build/uname

sysname[65]: Linux
nodename[65]: LAPTOP-YC
release[65]: 5.10.16.3-microsoft-standard-WSL2
version[65]: #1 SMP Fri Apr 2 22:23:49 UTC 2021
machine[65]: x86_64
```

Signed-off-by: Yong Cong Sin <[email protected]>
fabiobaltieri pushed a commit that referenced this pull request Oct 30, 2024
hci_packet_complete(buf, buf_size) should check whether buf_size is
enough.
For instance, hci_packet_complete can receive buf with buf_size 1,
leading to the buffer overflow in cmd->param_len, which is buf[3].
This can happen when rx_thread() receives two frames in 512 bytes
and the first frame size is 511. Then, rx_thread() will call
hci_packet_complete() with 1.

==5==ERROR: AddressSanitizer: global-buffer-overflow on address
0x000000ad81c2 at pc 0x0000005279b3 bp 0x7fffe74f5b70 sp 0x7fffe74f5b68

READ of size 2 at 0x000000ad81c2 thread T6
    #0 0x5279b2  (/root/zephyr.exe+0x5279b2)
    #1 0x4d697d  (/root/zephyr.exe+0x4d697d)
    #2 0x7ffff60e5daa  (/lib/x86_64-linux-gnu/libc.so.6+0x89daa)
(BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c)

0x000000ad81c2 is located 2 bytes to the right of global variable
'rx_thread.frame' defined in 'zephyr/drivers/bluetooth/hci/userchan.c'
(0xad7fc0) of size 512
SUMMARY: AddressSanitizer: global-buffer-overflow
(/root/zephyr.exe+0x5279b2)
Thread T6 created by T2 here:
    #0 0x48c17c  (/root/zephyr.exe+0x48c17c)
    #1 0x530192  (/root/zephyr.exe+0x530192)
    #2 0x4dcc22  (/root/zephyr.exe+0x4dcc22)

Thread T2 created by T1 here:
    #0 0x48c17c  (/root/zephyr.exe+0x48c17c)
    #1 0x530192  (/root/zephyr.exe+0x530192)
    #2 0x4dcc22  (/root/zephyr.exe+0x4dcc22)

Thread T1 created by T0 here:
    #0 0x48c17c  (/root/zephyr.exe+0x48c17c)
    #1 0x52f36c  (/root/zephyr.exe+0x52f36c)
    #2 0x5371dc  (/root/zephyr.exe+0x5371dc)
    zephyrproject-rtos#3 0x5312a6  (/root/zephyr.exe+0x5312a6)
    zephyrproject-rtos#4 0x52ed7b  (/root/zephyr.exe+0x52ed7b)
    zephyrproject-rtos#5 0x52eddd  (/root/zephyr.exe+0x52eddd)
    zephyrproject-rtos#6 0x7ffff6083c89  (/lib/x86_64-linux-gnu/libc.so.6+0x27c89)
(BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c)

==5==ABORTING

Signed-off-by: Sungwoo Kim <[email protected]>
fabiobaltieri pushed a commit that referenced this pull request Nov 6, 2024
With introduction of Raw modes, nRF70 driver now advertises get_c
onfig OP, but doesn't implement all types.

This causes problems two-fold with checksum calculations:
  1. The "config" isn't uninitialized, so, every call returns differnet
     values. So, for UDP header checksum would be done and
     pkt->chksumdone would be set. But for IPv4 header checksum might be
     skipped.
  2. Even if we initialize to zero, then network stack gets all zeros
     and calculates checksum by itself rendering offload moot.

There is another problem in #1, as there is only single flag for pkt for
all checksum, nRF70 driver sees this and tells UMAC to skip checksum for
the entire packet. The design isn't coherent, and should be converted to
communicate per-type checksum status (some are filled by network stack
and some HW).

But as nRF70 support all checksum offloads, advertise all types for both
RX and TX.

Upstream PR #: 80882

Signed-off-by: Chaitanya Tata <[email protected]>
fabiobaltieri added a commit that referenced this pull request May 9, 2025
Current code does not build on Cortex-M0, seems like it does not like
subs:

Error: instruction not supported in Thumb16 mode -- `subs r3,#1'

Replace the instruction with a sub and cmp, add an M0+ board so this is
tested in CI.

Signed-off-by: Fabio Baltieri <[email protected]>
fabiobaltieri added a commit that referenced this pull request May 11, 2025
Current code does not build on Cortex-M0, seems like it does not like
subs:

Error: instruction not supported in Thumb16 mode -- `subs r3,#1'

Adding a unified assembler language declaration in the snippet seems to
fix the problem, also add an M0+ board so this is tested in CI.

Signed-off-by: Fabio Baltieri <[email protected]>
fabiobaltieri added a commit that referenced this pull request May 19, 2025
Current code does not build on Cortex-M0, seems like it does not like
subs:

Error: instruction not supported in Thumb16 mode -- `subs r3,#1'

Adding a unified assembler language declaration in the snippet seems to
fix the problem, also add an M0+ board so this is tested in CI.

Signed-off-by: Fabio Baltieri <[email protected]>
fabiobaltieri pushed a commit that referenced this pull request Jun 30, 2025
Add possibility to perform crop on all pipes and compose (downscale) on
pixel pipes (endpoint #1 and endpoint #2).
Rework the code in order to move the downscale control from
the set_fmt into the set_selection (compose).

Signed-off-by: Alain Volmat <[email protected]>
fabiobaltieri pushed a commit that referenced this pull request Sep 11, 2025
Add support for NV12/NV21, NV16/NV61 and YUV420/YVU420
(semi)planar formats which can be output by the main #1 pipe.

Signed-off-by: Alain Volmat <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants