Fixed comments and indent
Add commit log to OCTOSPI HW PR
Summary
hardware/stm32_qspi.h - Defines for the STM32H5 QSPI driver. The peripheral on the STM32H5 is actually an OCTOSPI peripheral, however it was decided to use it as a QSPI peripheral for the following reasons:
There is currently support for QSPI within Nuttx.
The STM32H7 QSPI register set is very similar to the STM32H5 OCTOSPI register set and the STM32H7 series has an existing QSPI driver.
OCTOSPI devices are rare as of now and are not part of our use case.
hardware/stm32h56xxx_pinmap.h - Added pin mappings for OCTOSPI GPIOs.
Impact
This change will not impact any architectures outside of the STM32H5 series. Even for the STM32H5 series, these changes will only have an impact if they are utilized.
Testing
No testing yet for these files other than ensuring that we can still build Nuttx. Further testing will be documented in a future pull request when the STM32H5 QSPI driver is added.
This driver add uORB sensor support to Renesas FS3000 sensor.
Thanks Xiang Xiao for review and suggestions.
Signed-off-by: Alan C. Assis <acassis@gmail.com>
The fake audio driver aims to easily simulate the functions of audio driver through reading and writing files.
With it, you can conveniently customize and define various capture or playback audio drivers for debugging or automated testing.
Signed-off-by: yaojingwei <yaojingwei@xiaomi.com>
according to linux kernel doc, "the SA_NOMASK is an obsolete,
nonstandard synonym for this SA_NODEFER" flag, and some ltp linux kernel
testcases need this flag, so we add this flag to make the testcases pass
Signed-off-by: guoshichao <guoshichao@xiaomi.com>
The `struct sensor_gnss_satellite.cf` may be parsed from `GSV.signal_id`(e.g. NMEA 0183 v4.11) and `struct sensor_gnss_satellite.constellation`
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
This patch adds support for velocity measurement sensors.
I plan to use it as a generic velocity type to be used for
Renesas FS3000 (Air Velocity Flow).
Signed-off-by: Alan C. Assis <acassis@gmail.com>
Fixes an issue in kernel build where the user addresses passed
to accept() would be accessed when the wrong MMU mappings were
active. A crash would manifest when attempting to accept() on a
TCP server socket for instance under significant load. The accept
event handler would be called by the HP worker upon client
connection. At this point, accept_tcpsender() would attempt to
write to `addr` resulting in a page fault. Reproducibility would
depend on the current system load (num tasks or CPU stress) but
in loaded environments, it would crash almost 100% of the times.
It should be noted that Linux does this the other way around: it
operates on kernel stack allocated data and once done, it copies
them to user. This can also be a viable alternative, albeit with
one extra copy and a little extra memory.
Signed-off-by: George Poulios <gpoulios@census-labs.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
NOTE
The code was reported as GPL by FOSS ID
and Xiaomi scanned the file xform.c with Black Duck Security and it showed
that the license was BSD-3-Clause and no risk was reported.
Since there is no clause on the license it was concluded as 0BSD
Refference
https://github.com/apache/nuttx/pull/15252
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
This breaks the libuv build without CONFIG_PIPES
as expected:
```
LD: nuttx
/usr/bin/ld: nuttx.rel: in function `uv_pipe':
/src/apps/system/libuv/libuv/src/unix/pipe.c:516: undefined reference to `NXpipe2'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:427: nuttx] Error 1
make: *** [tools/Unix.mk:551: nuttx] Error 2
```
That is, this correctly exposes https://github.com/apache/nuttx/issues/14773
on linux.
When enable CONFIG_STACK_CANARIES, in general, the stack check in the __gcov_fork function is:
" return fork();
18: e59f3020 ldr r3, [pc, #32] @ 40 <__gcov_fork+0x40>
1c: e5932000 ldr r2, [r3]
20: e59d3004 ldr r3, [sp, #4]
24: e0332002 eors r2, r3, r2
28: e3a03000 mov r3, #0
2c: 1a000002 bne 3c <__gcov_fork+0x3c>"
r3 is obtained by taking the value of sp offset. But after opening thumb, the second comparison value in
"8c6: 4a06 ldr r2, [pc, #24] @ (8e0 <__gcov_fork+0x30>)
8c8: 6811 ldr r1, [r2, #0]
8ca: 687a ldr r2, [r7, #4]
8cc: 4051 eors r1, r2"
is obtained through r7. Since r7 stores the stack address at this time, which stores the address of the parent process, the stack out of bounds will occur in the child process
Signed-off-by: wangmingrong1 <wangmingrong1@xiaomi.com>
