- inline functions within mpu.h converted to macros or moved to up_mpu.c
- mpu.h and up_mpu.c are now conditionally included in build via CONFIG_ARM_MPU
Chips affected by these changes
- imxrt
- kinetis
- lpc17xx
- lpc43xx
- lpc54xx
- sam34
- stm32
- stm32f7
- stm32h7
- stm32l4
- tiva
- xmc4
The same functionality could be implemented in the common place(netlink_recvfrom)
Change-Id: I8aedb29c4f0572f020ca5c0775f06c5e1e17ae4a
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
* boards/arm/stm32/nucleo-f429zi: Initial port to nucleo-f429zi board.
* boards/arm/stm32/nucleo-f429zi: Add two demo configs.
* Add the nucleo-f429zi to boards/Kconfig
boards/Kcondig: Fixed line alignment issue.
* boards/arm/stm32/nucleo-f429zi: Change the license header of all new files to an Apache 2.0 license.
* boards/arm/stm32/nucleo-f429zi: nxstyle fixed
and for future Apache releases.
- Rename the final tarball to add incubating and apache to their names
- Make the tool usuable from a development repo.
- Add a list of patterns(files and folders) to exclude and
a command line argument to pass aditional patterns.
- Add a command to run silently.
- If the build number was not provided let version.sh figure it out.
This commit fixes some long single line comments. This effort was primarily intended to verify the change to tools/nxstyle of PR #743 further. This took the files changed with 1501d284c3 and ran them through nxstyle again. The files in the commit previously passed the old nxstyle test with no complaints. The current nxstyle, on the other hand, reported 49 long single line comments. Each of those were verified and the file was updated. The nxstyle change appears completely reliable.
This resolves issue 718: nxstyle line width check was ignoring the line width check for single line comments.
This turned out to be an artifact in parsing. Usually when parsing character by character, the file character to be parsed was '/n'. Howefver, in the case of parsing single line comments, the final character was the NUL terminator. This means that the lenth check was not being performed in the case of single line comments.
NOTE: Currently, I have suppressed error reports for single line right-hand comments. My fear is that this will unmask more standard violations than we can cope with. It is easy to re-enable and perhaps we should do that in the future:
/* Check for long lines
*
* REVISIT: Long line checks suppressed on right hand comments
* for now. This just prevents a large number of difficult-to-
* fix complaints that we would have otherwise.
*/
if (m > g_maxline && !rhcomment) <-- remote the second condition
A mutex may be configured with rather exotic options such as recursive, unsafe, etc. The availability of these mutex options is controlled by configuation settings. When each option is enabled, additional fields are managed inside of the mutex structure.
pthread_cond_wait() and pthread_timed_wait() do the following atomically: (1) unlock the mutex, (2) wait for the condition, and (3) restore the mutex lock. When that lock is restored, pthread_cond_[timed]wait() must also restore the exact configuration of the mutex data structure if these "exotic" features are enabled.
Now that nxsem_wait_uninterruptible() returns an error when the thread is canceled, new logic is being executed. This revealed an existing error in pthread_cond_wait(). The nature of the error is as follows:
* pthread_cond_wait() must atomically (1) release the mutex, (2) wait on the condition, and (3) re-establish the mutex. Errors can occur on any of these steps. In this case the ECANCELED error was (very correctly) reported by nxsem_wait_uninterruptible().
* However, logic in step (3) had a bug; it re-acquired the mutex, but then a bug in existing logic cause the mutex to be improperly initialized. Essentially, the wrong error status value was being testing. This resulted in a nonsequitar and errors reported by the OS test.
This problem was found by apps/testing/ostest/pthread_cleanup.c
Resolution of Issue 619 will require multiple steps, this part of the first step in that resolution: Every call to nxsem_wait_uninterruptible() must handle the return value from nxsem_wait_uninterruptible properly. This commit is for all remaining drivers in the LC823450 architectures.
Resolution of Issue 619 will require multiple steps, this part of the first step in that resolution: Every call to nxsem_wait_uninterruptible() must handle the return value from nxsem_wait_uninterruptible properly. This commit is for all remaining drivers in the Atmel SAM architectures.
NOTES:
- arch/arm/src/sama5/sam_can.c: Generates several "Mixed case identifier" complaints because definitions provided by header files that are not part of the change.
- arch/arm/src/sama5/sam_pmecc.c: Has two cases of "Mixed case identifies" result within commented out code. There are references to undefined types that might be provided by Atmel logic (Pmecc and Pmerrloc) if it were ever integrated.
Resolution of Issue 619 will require multiple steps, this part of the first step in that resolution: Every call to nxsem_wait_uninterruptible() must handle the return value from nxsem_wait_uninterruptible properly. This commit is for all HCI UART drivers under arch/.
