Date   

Re: Error compiling sample Hello World

Carles Cufi
 

Hey there,

 

I am about to submit an update to the chocolatey package to fix the issue you had with DTC and a 32-bit host.

 

Regarding the error you are getting now, this looks like you’re missing the Python yaml module. To install it, refer to:

http://docs.zephyrproject.org/getting_started/installation_win.html#option-1-windows-command-prompt

 

In particular:

cd %userprofile%\zephyr

pip3 install -r scripts/requirements.txt

 

Make sure you don’t have multiple Python3 versions installed on your machine, this could confuse things a bit.

 

To make sure you have the module installed, you can do:

 

pip3 list

 

Carles

 

From: (ELT) Benjamín Alcalde <balcalde@...>
Sent: 29 August 2018 11:41
To: Cufi, Carles <Carles.Cufi@...>; devel@...
Subject: RE: [Zephyr-devel] Error compiling sample Hello World

 

Hi everyone again:

I get another PC with Windows 8.1 Enterprise 64bits. I started again with the steps show in Getting Started Guide and I get another error. This what I get from the console:

 

C:\Users\alfredo\zephyr\samples\hello_world\build>cmake -GNinja -DBOARD=nrf52_pca10040 ..

-- Found PythonInterp: C:/Python37/python.exe (found suitable version "3.7", minimum required is "3.4")

-- Selected BOARD nrf52_pca10040

Zephyr version: 1.13.0

Parsing Kconfig tree in c:/Users/alfredo/zephyr/Kconfig

Using C:/Users/alfredo/zephyr/boards/arm/nrf52_pca10040/nrf52_pca10040_defconfig as base

Merging C:/Users/alfredo/zephyr/samples/hello_world/prj.conf

-- Generating zephyr/include/generated/generated_dts_board.h

Traceback (most recent call last):

File "c:/Users/alfredo/zephyr/scripts/dts/extract_dts_includes.py", line 15, in <module> import yaml

ModuleNotFoundError: No module named 'yaml'

CMake Error at C:/Users/alfredo/zephyr/cmake/dts.cmake:126 (message):command failed with return code: 1

Call Stack (most recent call first):

C:/Users/alfredo/zephyr/cmake/app/boilerplate.cmake:278 (include)

CMakeLists.txt:3 (include)

 

-- Configuring incomplete, errors occurred!

 

Then I tried to check de DTC version as Carles Cufi told me and this is what I get:

 

C:\Users\alfredo>dtc --version

Version: DTC 1.4.4-ga81d4ca0-dirty

 

 

Thanks in advance.

Best regards

 

 

 

 

De: devel@... [mailto:devel@...] En nombre de Cufi, Carles
Enviado el: martes, 28 de agosto de 2018 14:35
Para: IosuGorostiza; devel@...
Asunto: Re: [Zephyr-devel] Error compiling sample Hello World

 

Hi there,

 

Sounds like there’s an issue with DTC and a 32-bit host. While we do support a 32-bit version of it, I’ve never tested it myself since I don’t have access to a 32-bit Windows installation.

Did you install dtc using Chocolatey?

Could you try perhaps running dtc manually? Open a command prompt and then:

 

C:\Users\Carles>dtc --version

Version: DTC 1.4.4-ga81d4ca0-dirty

 

Thanks,

 

Carles

 

From: devel@... <devel@...> On Behalf Of IosuGorostiza
Sent: 28 August 2018 14:30
To: devel@...
Subject: [Zephyr-devel] Error compiling sample Hello World

 

Hi everybody:
I´m trying to compile the example hello_world as described in the Getting Started Guide. I follow every step of the guide but I´m not able to compile. I deleted everything and start again from the beggining several times and always get the same error. The steps I followed was for ARM.
I´m using the board nrf52_pca10040 in a PC with Windows 8.1 Enterprise 32bits.
Next, I paste what I obtained after executing the compiling instruction:

C:\Users\balcalde\zephyr\samples\hello_world\build>cmake -GNinja -DBOARD=nrf52_pca10040 ..

-- Found PythonInterp: C:/Python37/python.exe (found suitable version "3.7", minimum required is "3.4")

-- Selected BOARD nrf52_pca10040

Zephyr version: 1.13.0

Parsing Kconfig tree in C:/Users/balcalde/zephyr//Kconfig

Using C:/Users/balcalde/zephyr/boards/arm/nrf52_pca10040/nrf52_pca10040_defconfig as base

Merging C:/Users/balcalde/zephyr/samples/hello_world/prj.conf

-- Generating zephyr/include/generated/generated_dts_board.h

CMake Error at C:/Users/balcalde/zephyr/cmake/dts.cmake:84 (message):command failed with return code: Exit code 0xc0000135

 

Call Stack (most recent call first):

  C:/Users/balcalde/zephyr/cmake/app/boilerplate.cmake:278 (include)

  CMakeLists.txt:3 (include)

-- Configuring incomplete, errors occurred!

I spent many hours searching trough the web and reading zephyr documentation but I didn´t found anything that help me to solve that error.

I apprecite any help.
Thanks, best regards

 

 

 

 

 


Re: Error compiling sample Hello World

IosuGorostiza <balcalde@...>
 

Hi everyone again:

I get another PC with Windows 8.1 Enterprise 64bits. I started again with the steps show in Getting Started Guide and I get another error. This what I get from the console:

 

C:\Users\alfredo\zephyr\samples\hello_world\build>cmake -GNinja -DBOARD=nrf52_pca10040 ..

-- Found PythonInterp: C:/Python37/python.exe (found suitable version "3.7", minimum required is "3.4")

-- Selected BOARD nrf52_pca10040

Zephyr version: 1.13.0

Parsing Kconfig tree in c:/Users/alfredo/zephyr/Kconfig

Using C:/Users/alfredo/zephyr/boards/arm/nrf52_pca10040/nrf52_pca10040_defconfig as base

Merging C:/Users/alfredo/zephyr/samples/hello_world/prj.conf

-- Generating zephyr/include/generated/generated_dts_board.h

Traceback (most recent call last):

File "c:/Users/alfredo/zephyr/scripts/dts/extract_dts_includes.py", line 15, in <module> import yaml

ModuleNotFoundError: No module named 'yaml'

CMake Error at C:/Users/alfredo/zephyr/cmake/dts.cmake:126 (message):command failed with return code: 1

Call Stack (most recent call first):

C:/Users/alfredo/zephyr/cmake/app/boilerplate.cmake:278 (include)

CMakeLists.txt:3 (include)

 

-- Configuring incomplete, errors occurred!

 

Then I tried to check de DTC version as Carles Cufi told me and this is what I get:

 

C:\Users\alfredo>dtc --version

Version: DTC 1.4.4-ga81d4ca0-dirty

 

 

Thanks in advance.

Best regards

 

 

 

 

De: devel@... [mailto:devel@...] En nombre de Cufi, Carles
Enviado el: martes, 28 de agosto de 2018 14:35
Para: IosuGorostiza; devel@...
Asunto: Re: [Zephyr-devel] Error compiling sample Hello World

 

Hi there,

 

Sounds like there’s an issue with DTC and a 32-bit host. While we do support a 32-bit version of it, I’ve never tested it myself since I don’t have access to a 32-bit Windows installation.

Did you install dtc using Chocolatey?

Could you try perhaps running dtc manually? Open a command prompt and then:

 

C:\Users\Carles>dtc --version

Version: DTC 1.4.4-ga81d4ca0-dirty

 

Thanks,

 

Carles

 

From: devel@... <devel@...> On Behalf Of IosuGorostiza
Sent: 28 August 2018 14:30
To: devel@...
Subject: [Zephyr-devel] Error compiling sample Hello World

 

Hi everybody:
I´m trying to compile the example hello_world as described in the Getting Started Guide. I follow every step of the guide but I´m not able to compile. I deleted everything and start again from the beggining several times and always get the same error. The steps I followed was for ARM.
I´m using the board nrf52_pca10040 in a PC with Windows 8.1 Enterprise 32bits.
Next, I paste what I obtained after executing the compiling instruction:

C:\Users\balcalde\zephyr\samples\hello_world\build>cmake -GNinja -DBOARD=nrf52_pca10040 ..

-- Found PythonInterp: C:/Python37/python.exe (found suitable version "3.7", minimum required is "3.4")

-- Selected BOARD nrf52_pca10040

Zephyr version: 1.13.0

Parsing Kconfig tree in C:/Users/balcalde/zephyr//Kconfig

Using C:/Users/balcalde/zephyr/boards/arm/nrf52_pca10040/nrf52_pca10040_defconfig as base

Merging C:/Users/balcalde/zephyr/samples/hello_world/prj.conf

-- Generating zephyr/include/generated/generated_dts_board.h

CMake Error at C:/Users/balcalde/zephyr/cmake/dts.cmake:84 (message):command failed with return code: Exit code 0xc0000135

 

Call Stack (most recent call first):

  C:/Users/balcalde/zephyr/cmake/app/boilerplate.cmake:278 (include)

  CMakeLists.txt:3 (include)

-- Configuring incomplete, errors occurred!

I spent many hours searching trough the web and reading zephyr documentation but I didn´t found anything that help me to solve that error.

I apprecite any help.
Thanks, best regards

 

 

 

 

 


BLE start scan callback

robert.konc@...
 

I would like to know when BLE device is scaned.
How to implement callback function that signalize when peripherial device is scaned.

Thanks in advance!

Robert Konc


Re: nrf52840_pca10059 startup

Chettimada, Vinayak Kariappa
 

This all sounds very close to what is described in :
http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52840.ps%2Fpower.html&;cp=2_0_0_4_2_1&anchor=power_usb_supply

"both VBUS and either VDDH or VDD supplies are required"


and "External supply from VDD is only available when power is supplied to VDDH."  Mentioned here: http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52840.ps/ref_circuitry.html#concept_aqp_fd1_fq


You may check if solder bridge SB2 is intact, and VDDH is connected to VBUS_nRF.

- Vinayak



From: Henrik Brix Andersen <henrik@brixandersen.dk>
Sent: Tuesday, August 28, 2018 10:57 PM
To: Chettimada, Vinayak Kariappa
Cc: Cufi, Carles; Zephyr Devel List; Di Santo, Emanuele
Subject: Re: [Zephyr-devel] nrf52840_pca10059 startup
 
Hi,

Neither. I am applying the 3V briefly to the SWDCLK input to generate a low-to-high transition on that pin.
I have just retested. Applying 3V briefly to VDD_nRF has the same effect; the board starts up and the application springs to life.

VBUS_nRF is 5.19V when plugged into USB and VDD_nRF is 0.47V (when the application isn’t running for whatever reason).
After applying ~3V briefly to SWDCLK or VDD_nRF, the application springs to life. VBUS_nRF is the same as before (5.19V) but VDD_nRF is now ~3V (as expected from the initialisation code in boards/arm/nrf52840_pca10059/board.c).

After this, the board continues to function as expected (even after resets, reflashing, etc.) until the next cold-boot (removing VBUS and restoring it).

All help is much appreciated.

Regards,
Brix
-- 
Henrik Brix Andersen

On 28 Aug 2018, at 22.02, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Where are you applying the 3V? to VDD_nRF  or VBUS_nRF? VBUS_nRF has a min, typ. and max of 4.35, 5, and 5.5 Volts. Can you measure the VDD_nRF, when you have the dongle plugged to USB port?

I dont have a dongle presently, reviewing the schematics, I see no reason why the chip should not be running the code in it.


From: Henrik Brix Andersen <henrik@brixandersen.dk>
Sent: Tuesday, August 28, 2018 9:08 PM
To: Chettimada, Vinayak Kariappa
Cc: Cufi, Carles; Zephyr Devel List; Di Santo, Emanuele
Subject: Re: [Zephyr-devel] nrf52840_pca10059 startup
 
Hi all,

I have found that a single low-to-high transition on the SWDCLK pin of the PCA10059 makes the application spring to life.
No debugger attached, no external circuitry at all. Just an external power source of 3V and a switch for applying a low-to-high transition of the SWDCLK line.

Could this have something to do with the internal DC-DC converter of the NRF52840?

Regards,
Brix
-- 
Henrik Brix Andersen

On 27 Aug 2018, at 22.20, Henrik Brix Andersen <henrik@brixandersen.dk> wrote:

Hi,

I am not using the NRF52832 configuration on the NRF52840 SoC; I merely noted that I have successfully used the same programmer (Atmel-ICE) for interacting with NRF52832 SoCs.

Yes, my application is samples/basic/blinky (and all other samples). I have tried the samples/bluetooth/peripheral sample; same issue.
When I initially flash the sample it starts up and everything works as intended. If I then disconnect USB power and reconnect it, nothing starts up (BLE scanner does not show the peripheral anymore).
A simple no-op SWD connection then does the trick; the application springs to life (without flashing a new binary).

I have tried a few of the USB samples as well; none of them shows up as a device on the USB bus.

Do you know if the original firmware binary (the one present on the device when shipping) for the PCA10059 is available anywhere? It could be interesting to see if that behaves correctly.
Are you able to share your locally built zephyr.bin file for the blinky sample with me?

Best regards,
Brix
--
Henrik Brix Andersen

On 27 Aug 2018, at 22.06, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Something you mention about using NRF52832 configuration, why would you want to use that on nRF52840 SoC?

You mention blinky as the example, is that the application you have trouble with? We tried that on our dongle, and see no issues.

I have tried BLE peripheral sample and hci_usb sample on nRF52840 merely powered from nRF USB interface, and see no issues.

Please confirm, that your application is samples/basic/blinky… also please try the samples/bluetooth/peripheral and let me know if you don’t see BLE advertising.

Regards,
Vinayak

On 27 Aug 2018, at 18:42, Henrik Brix Andersen <henrik@brixandersen.dk> wrote:

Hi Vinayak,

Thank you for getting back to me. I just tried reverting commit 26d22b0075cf5a71f13958ec1f2727ac7167eca4, but it does not fix the application behaviour.

Any other ideas are most welcome.

Best regards,
Brix

--
Henrik Brix Andersen

On 27 Aug 2018, at 12.52, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Hi,

I may have introduced a regression (bisected to) in 26d22b0075cf5a71f13958ec1f2727ac7167eca4

I notice that hci_usb sample fails to enumerate the bluetooth class device.

Will get back when I have something. Meanwhile, revert the above mentioned commit and do let me know if your application functions as expected.

Regards,
Vinayak


On 26 Aug 2018, at 19:18, Henrik Brix Andersen <henrik@brixandersen.dk> wrote:

Hi,

I am flashing the board using an Atmel-ICE debugger (using pyOCD 0.11.2) connected to a 10-pin debug connector soldered to the P1 footprint on the bottom of the board.

I am using the same configuration for several NRF52832 boards without issues.

Best regards,
Brix

--
Henrik Brix Andersen

On 26 Aug 2018, at 19.01, Cufi, Carles <Carles.Cufi@nordicsemi.no> wrote:

Hi there,

Can you tell us how you're flashing the board? Another Nordic Devkit, or a separate debug IC?

Also copying Emanuele who's doing most of the work on this board.

Regards,

Carles

On 26/08/2018, 18:07, "devel@lists.zephyrproject.org on behalf of Henrik Brix Andersen" <devel@lists.zephyrproject.org on behalf of henrik@brixandersen.dk> wrote:

Hi,

I have just acquired an NRF52840 Dongle (nrf52840_pca10059) and I am facing some difficulties with board startup.

When I flash a zephyr binary to the board (e.g. samples/basic/blinky) the board starts up fine and starts the application.
But when I disconnect the board from USB power and reconnect it, the application no longer starts (and the internal DC-DC converter does not seem to start-up either).

If I run no-op pyOCD command (e.g. pyocd-flashtool -t nrf52840) the application springs to life (e.g. for blinky, the LED starts to blink).
I am not using mcuboot or any other bootloader; just the bare-bone sample application.

What am I missing here?

Best regards,
Brix
--
Henrik Brix Andersen












Zephyr Development News, 28 August 2018

Marti Bolivar <marti@...>
 

Hello,

This is the 28 August 2018 newsletter tracking the latest Zephyr
development merged into the mainline tree on GitHub.

HTML is available here:

https://foundries.io/insights/2018/08/28/zephyr-news-20180828/

We're experimenting with using Pandoc to help generate the plain text
email version that follows; please bear with us in case of formatting issues.


As usual, contents are broken down as follows:

- Highlights
- Important changes
- New features
- Bug fixes
- Individual changes: a complete list of patches, sorted chronologically
and categorized into areas, like:
- Architectures
- Kernel
- Drivers
- etc.

Highlights
==========

This newsletter covers the following inclusive commit range:

- f5026a11 ("samples/mesh: Fix dev_uuid initialization from identity
address"), merged 16 August 2018
- 00bb7136 ("release: bump version to 1.13-rc1"), merged 22 August 2018

Important Changes
-----------------

v1.13 Release Candidate 1:

With v1.13.0-rc1 tagged and bagged, the merge window is closed. Only
pull requests which fix bugs or add documentation will be merged until
the next window opens (with the usual exceptions for pull requests
deemed special enough to bend the rules).


Tracing Framework:

Zephyr has long supported tool-specific means for tracing execution,
particularly support for Segger's (proprietary, and popular) tools. It
now includes an initial tool-agnostic trace framework.

Official documentation is a bit thin, but the relevant header
(<include/tracing.h>) is essentially a shim layer which allows
implementing additional tracing mechanisms. These will receive the same
trace notifications that Zephyr's Segger SystemView integration
supports. This replaces the old "event logger" mechanism as well as
other SoC-specific tracing code (so long, CONFIG_SOC_WATCH) in a unified
framework.

Support can be enabled via CONFIG_TRACING and enabling a backend (or,
cutting to the chase, by setting CONFIG_SEGGER_SYSTEMVIEW=y, which is
the only backend and selects CONFIG_TRACING). Here is an example of the
dining philosophers sample run under SystemView, showing the types of
events that are generated and associated metadata:

https://foundries.io/uploads/2018/08/28/segger_systemview_zephyr.png

Some of the edges are still a bit rough (the tracing API is not set in
stone, and details like thread IDs shown in the timeline view are not
especially human-readable), but it seems that with the addition of this
framework, generic and improving support for tracing is arriving in
Zephyr.


(Semi-)Automated Benchmarking:

Zephyr now supports gathering data for a variety of benchmarking
results, including for userspace operations. Support for benchmarking
implies a footprint and execution time penalty, so it must be enabled
with CONFIG_EXECUTION_BENCHMARKING. Test suites exercising this are part
of Zephyr's CI, and can also be run locally using sanitycheck.

Here are results and steps to reproduce a userspace-enabled benchmark
test suite on the frdm_k64f board:

https://gist.github.com/mbolivar/ff6db89181bde285f52ab32d5393f4e0

(Note that some userspace-specific issues are still being ironed out
on nRF devices; see issue 9676.) Unfortunately, the generated result
files are in (various different) custom text file formats, rather than
something like CSV or JSON. Thus, some extra parsing has to be done to
process the results.

To run benchmarks on a QEMU x86 Zephyr target (Linux hosts only), use
these instead:

# Run timing benchmarks:
$ sanitycheck -N -p qemu_x86 --test
tests/benchmarks/timing_info/benchmark.timing.userspace

# Run all tests with the "benchmark" tag:
$ sanitycheck -N -p qemu_x86 -t benchmark

As in the "real hardware" case, QEMU results are printed out in various
handler.log files in per-test sanity-out subdirectories.


Nordic GPIO/GPIOTE Changes:

The GPIO driver (drivers/gpio/gpio_nrfx.c) for Nordic nRF SoCs was
reimplemented as a shim over the nrfx vendor HAL, replacing the old
driver (drivers/gpio/gpio_nrf5.c).

Device tree GPIO nodes for nRF51 devices were added, affecting board
device trees.

These changes implied renaming of various GPIO-related Kconfig options.

Out of tree boards will need updates.


Power Management Improvements:

Zephyr has had power management support for quite some time
(http://docs.zephyrproject.org/subsystems/power_management.html), but
up until now, it has essentially been entirely up to the application
to manage power states in response to events. This is in contrast to
other operating systems, where the kernel can automatically initiate
device and SoC power state changes, often as a result of updating data
it's already using to track system state.

Needless to say, "do it yourself, have fun" tends to be less turnkey
than "the OS handles it for you", so it's a welcome sight to see the
initial merge of an "OS-managed" extension to Zephyr's power management
subsystem, which can be enabled by setting CONFIG_PM_CONTROL_OS=y.

Like much else in Zephyr, support is currently limited to nRF devices.
There also appear to be a few hard-coded data structures in the initial
commit limiting the available peripherals and supported functionality.
However, we're excited to see this new addition.

Features
--------

Arches:

The intel_s1000 target now initializes resource ownership for DMA and
I2S, as well as power gating and clock configuration, at SoC init time.

The Arm MPU driver framework was refactored and extended to add support
for v8-M SoCs.

Various internals were refactored for generic tracing support across
architectures.


Bluetooth:

The controller implementation (CONFIG_BT_CTLR) is now included by
default when CONFIG_BT is selected.

Zephyr's PHY update handler more gracefully manages protocol violations
observed with some cell phones available on the market.


Boards:

Support for the nRF-based board to be used at an upcoming Zephyr
hackathon was added as the reel_board configuration.

Support was added for the i.MX7 Solo WaRP7 board (as warp7_m4), with the
initial commit including GPIO, UART, and I2C support.

The intel_s1000_crb board now supports the TLV320DAC audio codec in its
device tree.

STM32L4 boards now support the RTC peripheral in their DTs.

nRF51 boards were refactored for DT-based GPIO support.


Device Tree:

Bindings were added for STM32 real time clocks (RTCs) in
dts/bindings/rtc/st,stm32-rtc.yaml.

The first audio codec binding (for the TI TLV320DAC) was added in
dts/bindings/audio/ti,tlv320dac.yaml.


Documentation:

The Kconfig documentation now makes it clearer which symbols are
selected by an option, and under what conditions. Here is an example for
CONFIG_SEGGER_SYSTEMVIEW:

http://docs.zephyrproject.org/reference/kconfig/CONFIG_SEGGER_SYSTEMVIEW.html#symbols-selected-by-this-symbol


Drivers:

New external device drivers/APIs:

- Analog devices ADXL372 3-axis accelerometer
- Avago APDS9960 digital proximity, ambient light, RGB and gesture
sensor
- TI TLV320DAC310x audio DAC (this is the first audio driver, which
has spawned a drivers/audio directory)
- TI HDC1008 temperature and humidity sensor
- A new driver API for digital microphone controllers was added as
include/audio/dmic.h.

STM32 devices now include support for the RTC peripheral; it was tested
on STM32L4.

The SiFive GPIO driver's IRQ bindings now respect the configured number
of pins.

i.MX devices can now retrieve frequency information for all UARTs.


Kernel:

Various internals were refactored for generic tracing support described
above.


Networking:

Various areas within the networking stack were refactored to avoid
allocating unnecessary struct k_delayed_work instances, resulting in
memory savings mostly affecting IPv6.


Samples:

- samples/sensor/adxl372, for the new ADXL372 accelerometer driver
- samples/subsys/power, for the new power management framework


Testing:

Additional test description and requirements traceability matrix
metadata were merged, along with improved test coverage in various
cases.


Bug Fixes
---------

Arches:

Some undefined signed integer shift operation behavior was corrected in
Arm's MPU framework.

On ARC, CONFIG_STACK_CHECK now works in secure mode as well, along with
other fixes related to thread initialization.

The SiLabs efr32fg1p SoC clock initialization code no longer attempts to
enable external oscillators which are already on.

The native_posix pseudo-architecture saw some segfault fixes in shell
argument handling, and a trace log message fix related to process
killing.


Bluetooth:

Mesh PB-GATT advertising data is initialized on demand, rather than at
initialization time, as the data it depends on may have changed since
initialization. Some PTS-related fixes were also merged.


Build:

A limitation on the number of kernel-space libraries to link into the
final binary has been removed.


Continuous Integration:

The check-compliance.py script no longer crashes when checking Kconfig
symbols for external projects.

sanitycheck internals related to job management were fixed and cleaned
up.

The Shippable configuration now fails when sanitycheck exits with an
error code, which it now does when Python exceptions are raised.


Drivers:

i.MX7 platforms now support GPIO7 and UART6.

Pinmux completions and bug fixes were merged affecting a variety of
STM32 families.

The i.MX I2C driver waits for the bus to be released before starting a
transaction.


External:

Kconfiglib was updated to a new version, fixing an issue related to
parsing the top-level Kconfig file.


Kernel:

The implementations of the k_{enable,disable}_sys_clock_always_on()
macros were fixed.

Various bitwise operations now correctly use unsigned integers. This is
an example of an emerging pattern of using the Coccinelle tool used in
the Linux kernel to perform automatic refactoring of Zephyr code; the
relevant script is scripts/coccinelle/unsigned_shift.cocci.

Thread-specific data is reserved at the top of the stack when
CONFIG_THREAD_USERSPACE_LOCAL_DATA is enabled. The first use case is
errno storage; use of errno from userspace now relies on this option.
This can be extended using the new struct _thread_userspace_local_data.


Libraries:

A couple of bug fixes for the recently merged CMSIS RTOS v1 support were
merged, affecting message and mail queues.


Miscellaneous:

Incorrect combinations of signed integers with irq_lock() were fixed,
also using a Cocinelle script, scripts/coccinelle/irq_lock.cocci.


Networking:

Renewed IPv6 addresses are now available for reuse. IPv6 addresses
related to a removed network prefix are now also removed.

The newly-merged LLDP support saw a timeout-related fix.

A bug causing spurious transmission of TCP retries was fixed.


Samples:

The samples/drivers/watchdog application was updated to use the new
watchdog API.


Testing:

Various issues identified by Coverity were fixed.

Individual Changes
==================

Patches by area (149 patches total):

- Arches: 23
- Bluetooth: 5
- Boards: 6
- Build: 4
- Continuous Integration: 8
- Device Tree: 6
- Documentation: 1
- Drivers: 25
- External: 1
- Kernel: 9
- Libraries: 2
- Miscellaneous: 5
- Networking: 16
- Power Management: 1
- Samples: 10
- Scripts: 1
- Testing: 26

Arches (23):

- 21e63ed2 arch: arm: kconfig: Remove redundant FLOAT dependencies
- 824bcaca xtensa: intel_s1000: Add SoC level SYS_INIT
- c8ea3653 arch: arm: type definition for arm mpu attribute container
- ff919d5f arch: arm: adapt region_init(.) to use arm_mpu_region_attr structure
- 829781d5 arch: arm: refactor _get_region_attr_by_type() function
- 5a696480 arch: arm: refactor _get_region_attr_by_conf(.) function
- 2f0e7221 arch: arm: mpu: move ARMv7m-specific functions in internal header
- 2a1fe6e2 arch: arm: implement ARMv8-M MPU driver
- b9566905 arch: arm: mpu: explicitly add UL in numerical shift operations
- 6ee0ad29 arch: arm: add ASSERT in _get_region_attr_by_type
- db0c5ca0 arch: arc: Added benchmark related hooks.
- e861661c native_posix: argparsing: Fix possible segfault
- 3ac2dc92 native_posix: Minor fix in message printed on kill
- 671cb652 arch/mcimx7_m4: Add pad, clock and gate config for GPIO7 and UART6
- d1219f4e arch/mcimx7_m4: Add i.MX7 Solo Kconfig SoC partnumber define
- f3d28933 arch: arc: stack check will be disabled in exception
- d68c0167 arch: arc: enable stack check when arc is in secure mode
- a1504c3c arch: arc: set the right init status for user space
- fa9fb831 arch: arc: re-orgnize the code in _new_thread
- eab5ff72 arch: arc: put the init context into privileged stack
- 506f21b6 arch: arc: small optimization in mpu driver
- 1301cc63 arch: arm: nordic_nrf: Add an API to check for valid PM state
- f6919977 soc: efr32fg1p: correct clock initialization sequence

Bluetooth (5):

- bb576f61 Bluetooth: Mesh: Move Device UUID log to bt_mesh_prov_enable()
- c0371277 Bluetooth: Mesh: Initialize PB-GATT advertising data at the
right time
- bf023d62 Bluetooth: Mesh: Fix heartbeat subscription state handling
- 8b3fd696 Bluetooth: controller: Fix assert on different transaction collision
- 871859a0 Bluetooth: GATT: Make CCC cfg_changed optional

Boards (6):

- 78a9daaa boards/arm: Enable RTC on STM32L4 boards
- 15813d34 boards: nrf: Changed GPIO default driver to NRFX shim
- bff5f470 boards: add basis support for the reel board
- 950c3466 boards: reel_board: Remove old reference to GPIO_NRF5
- 3c2a56bd boards: intel_s1000: audio codec in device tree
- c17fcf53 boards: Add support for WaRP7 board

Build (4):

- 964f6dc6 linker: Minor refactor of the APP_SMEM_SECTION macro
- cbe7b4fb linker: Re-implement {APP,KERNEL}_INPUT_SECTION
- 9e18b4f0 kconfig: BT: Default to using BT_CTLR when BT
- f2acdffe genrest: List symbols selected by each symbol

Continuous Integration (8):

- b4bdd669 sanitycheck: exit on exceptions
- 27b9e2ef ci: Handle errors and exit on them
- 94acc18b coverage: tests: poll: Add test to validate multiple polling threads
- 4fe581cc check-compliance: Fix undef. Kconfig symbol check for
external projects
- 42822083 sanitycheck: Get ZEPHYR_BASE only once
- c97054c1 sanitycheck: Fix the logic for jobs
- 99aacd98 sanitycheck: Rename CPU_COUNTS to JOBS
- f3bc967e sanitycheck: Overcommit the default number of jobs

Device Tree (6):

- 945ef745 dts/rtc: Introduce binding for STM32 RTC
- e99e363c dts: nrf: Added DTS support for nRF51
- 4f6aac1a dts: nrf5: Changed GPIO and GPIOTE define names
- 03da2f5c dts: audio: device tree support for audio devices
- 41d5a942 include: dt-bindings: pinctrl: stm32-pinctrlf1.h complete
stm32f1 header
- a25c273f dts: Fix cmake warning about missing id field for fsl,imx7d-i2c

Documentation (1):

- 469bd39b doc: add tracing section

Drivers (25):

- 0d47ae4f drivers: rtc: add support for STM32 RTC
- 6d8220d2 drivers: gpio: Add shim for nrfx GPIO and GPIOTE drivers
- d25c887f drivers: nrf: Remove redundant gpio_nrf5 shim
- acc5312b drivers: hdc1008: do not use hardcoded I2C address
- 6c9eb734 drivers: hdc1008: add dt bindings
- 7a507d3e drivers: apds9960: add dt bindings
- ca12b3f7 drivers: gpio: SiFive GPIO allows <32 pins
- 73c10932 drivers: audio: Add audio support in Kconfig
- d9a283d9 drivers: audio: TLV320DAC310x audio DAC driver
- 1864ba55 drivers: audio: add audio to cmake system
- bc332d76 drivers: dmic: APIs for digital microphones
- dc88fa6a drivers: i2s_cavs: Remove resource owner config
- e9c0f7e4 drivers: dma_cavs: Remove resource owner config
- 502d9189 drivers: pinmux: stm32: complete stm32f2 header
- 0ad9b3f8 drivers: pinmux: stm32: complete stm32f0 header
- 30045e4f drivers: pinmux: stm32: complete stm32f3 header
- 3fdf984a drivers: pinmux: stm32: complete stm32f4 header
- 4b9388f4 drivers: pinmux: stm32: complete stm32f7 header
- cc4f992b drivers: pinmux: stm32: complete stm32l0 header
- 425aca24 drivers: pinmux: stm32: complete stm32l4x header
- 96784dff include: console: Include kernel.h for struct k_fifo
- 2d269bb1 drivers: pwm_nrf5_sw: Perform static initialization only once
- 4eee8a67 drivers/i2c/i2c_imx: Check for I2C bus busy before starting
transaction
- 22b61c7f sensors: add WaRP7 board listing for fxos8700 and fxas21002
- a3e7cea1 drivers: sensors: adxl372: Add driver for ADXL372 high-g
accelerometer

External (1):

- 636d5451 ext/hal/nxp/imx: Add all UARTs clock frequency information

Kernel (9):

- f23a8cdd kernel: Fix k_*_sys_clock_always_on macro
- ec462f87 kernel: Remove unused definition
- 8aec0872 kernel: Fix bitwise operators with unsigned operators
- cc74ad08 kernel: Explicitly ignoring results of queue_insert
- 6699423a kernel: Explicitly ignoring memcpy return
- fc182430 kernel: userspace: reserve stack space to store local data
- a8b0b0d5 benchmarks: timing_info: Add hooks in the kernel for userspace.
- b6304e66 tracing: support generic tracing hooks
- a2248782 kernel: event_logger: remove kernel_event_logger

Libraries (2):

- 5c79101f constants: Use uppercase to indicate long
- 411662d3 lib: cmsis_rtos_v1: fix couple of nonconformities

Miscellaneous (5):

- 0866d18d irq: Fix irq_lock api usage
- 2626dda0 assert: Explicitly ignoring printk() return
- 030a65c4 util: Add WRITE_BIT macro to util.h
- 483910ab systemview: add support natively using tracing hooks
- 00bb7136 release: bump version to 1.13-rc1

Networking (16):

- 1a7e365f net: ip: Remove unused function
- 37837f5b net: ip: Add net_sprint_addr()
- 9d7711f0 net: ip: Redirect net_sprint_ipv*_addr() invocations
- 99dc5aef net: ip: Refactor usage of net_sprint_ip*()
- eeabc2ba net: if: Lower ram usage for IP address lifetime handling
- d529aef9 net: tls: Apply DTLS review fixes
- e3002751 net: ipv6: Centralize IPv6 send NS timeout through one k_delayed_work
- 51aa291f net: ipv6: Centralize ND reachable timeout through one k_delayed_work
- 58f3e183 net: ipv6: Separate IPv6 Neighbor functionality
- 8ddb3ba3 net: ipv6: Separate IPv6 MLD functionality
- 7aff94dc net: ipv6: Separate IPv6 fragment functionality
- 3bfc1385 net: if: Mark IPv6 address as preferred if lifetime is renewed
- 57a41a23 net: if: Remove IPv6 auto addresses if the prefix is removed
- a5f7e334 net: lldp: Fix timeout triggering if multiple workers
- 52126598 net: tcp: fix spurious TCP retries
- 49732b27 net: Move CONFIG_NET_OFFLOAD definition to net/ip/

Power Management (1):

- 2ad64785 subsys: power: Add OS managed Power Management framework

Samples (10):

- f5026a11 samples/mesh: Fix dev_uuid initialization from identity address
- 5d9e8189 samples: hello_world: remove single thread variant
- 1f19078e samples: apds9960: whitelist arduino_101_sss
- c9c8bbf2 samples: apds9960: whitelist reel board
- bd01344a samples/net/lldp/Kconfig: Get rid of leftover 'option env'
- 6c669ace samples: watchdog: Update watchdog example to new API
- 3f02e0d5 samples: remove kernel_event_logger sample
- 457fc799 samples: debug: remove sysview sample
- 84c352d0 samples: sensor: adxl372: Add ADXL372 sample application
- b69d2861 samples: subsys: Add sample app to demo OS managed PM

Scripts (1):

- a56be6f5 Kconfiglib: Fix $srctree behavior for the top-level Kconfig file

Testing (26):

- 9956dfc7 tests: update test identifier
- 57db4151 tests: remove subsys from test identifier
- 1c721217 tests: smp: Additional tests to verify SMP functionality
- ba6763a1 tests: disable HDC1008 from build tests
- fe1797f6 tests: net: ethernet_mgmt: Don't recalculate deltaBW with no link
- aaaf20e6 tests: net: ptp: Check max number of interfaces
- db2cbe7e tests: net: iface: Initialize port number
- 47889cd1 tests: fatal: Add description and RTM links
- b468b24d tests: gpio: Added nRF board to gpio test
- d36aae15 tests: cmsis_rtos_v1: add negative tests for timer api
- f3e05666 tests: kernel: fp_sharing: Added support for Cortex-M7
- ce88792a tests: fp_sharing: use filter
- 8c456f75 tests: mempool: Enhance tests to improve code coverage
- c9e3c938 tests/samples: watchdog: Update projects' configuration
- 667ad040 tests: benchmarks: timing_info: Add userspace related KPIs.
- 022588e8 tests: benchmarks: timing_info: Enable benchmarks for ARC.
- 43af891a tests: include: Add implementation of timestamp_serialize()
- 30b569e8 tests: benchmarks: timing_info: Discard selected measurements.
- bb918d85 tests: benchmarks: timing_info: Enable benchmarks for xtensa.
- 79f65d4d tests: benchmarks: timing_info: Enable benchmarks for nios2.
- 1d27b404 tests: benchmarks: timing_info: Enable benchmarks for riscv32.
- a4d1e36a tests: benchmarks: timing_info: Cleanup testcase.yaml
- 2a72f500 tests: smp: Modify test to verify thread delay
- 9038416b tests: net: ipv6: Add tests for verifying DAD timers
- ac47070d tests: qmsi: remove soc watch sample
- aa81a922 tests: build philosophers sample with systemview


Re: nrf52840_pca10059 startup

Henrik Brix Andersen
 

Hi,

Neither. I am applying the 3V briefly to the SWDCLK input to generate a low-to-high transition on that pin.
I have just retested. Applying 3V briefly to VDD_nRF has the same effect; the board starts up and the application springs to life.

VBUS_nRF is 5.19V when plugged into USB and VDD_nRF is 0.47V (when the application isn’t running for whatever reason).
After applying ~3V briefly to SWDCLK or VDD_nRF, the application springs to life. VBUS_nRF is the same as before (5.19V) but VDD_nRF is now ~3V (as expected from the initialisation code in boards/arm/nrf52840_pca10059/board.c).

After this, the board continues to function as expected (even after resets, reflashing, etc.) until the next cold-boot (removing VBUS and restoring it).

All help is much appreciated.

Regards,
Brix
--
Henrik Brix Andersen

On 28 Aug 2018, at 22.02, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Where are you applying the 3V? to VDD_nRF or VBUS_nRF? VBUS_nRF has a min, typ. and max of 4.35, 5, and 5.5 Volts. Can you measure the VDD_nRF, when you have the dongle plugged to USB port?

I dont have a dongle presently, reviewing the schematics, I see no reason why the chip should not be running the code in it.


From: Henrik Brix Andersen <henrik@brixandersen.dk>
Sent: Tuesday, August 28, 2018 9:08 PM
To: Chettimada, Vinayak Kariappa
Cc: Cufi, Carles; Zephyr Devel List; Di Santo, Emanuele
Subject: Re: [Zephyr-devel] nrf52840_pca10059 startup

Hi all,

I have found that a single low-to-high transition on the SWDCLK pin of the PCA10059 makes the application spring to life.
No debugger attached, no external circuitry at all. Just an external power source of 3V and a switch for applying a low-to-high transition of the SWDCLK line.

Could this have something to do with the internal DC-DC converter of the NRF52840?

Regards,
Brix
--
Henrik Brix Andersen

On 27 Aug 2018, at 22.20, Henrik Brix Andersen <henrik@brixandersen.dk> wrote:

Hi,

I am not using the NRF52832 configuration on the NRF52840 SoC; I merely noted that I have successfully used the same programmer (Atmel-ICE) for interacting with NRF52832 SoCs.

Yes, my application is samples/basic/blinky (and all other samples). I have tried the samples/bluetooth/peripheral sample; same issue.
When I initially flash the sample it starts up and everything works as intended. If I then disconnect USB power and reconnect it, nothing starts up (BLE scanner does not show the peripheral anymore).
A simple no-op SWD connection then does the trick; the application springs to life (without flashing a new binary).

I have tried a few of the USB samples as well; none of them shows up as a device on the USB bus.

Do you know if the original firmware binary (the one present on the device when shipping) for the PCA10059 is available anywhere? It could be interesting to see if that behaves correctly.
Are you able to share your locally built zephyr.bin file for the blinky sample with me?

Best regards,
Brix
--
Henrik Brix Andersen

On 27 Aug 2018, at 22.06, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Something you mention about using NRF52832 configuration, why would you want to use that on nRF52840 SoC?

You mention blinky as the example, is that the application you have trouble with? We tried that on our dongle, and see no issues.

I have tried BLE peripheral sample and hci_usb sample on nRF52840 merely powered from nRF USB interface, and see no issues.

Please confirm, that your application is samples/basic/blinky… also please try the samples/bluetooth/peripheral and let me know if you don’t see BLE advertising.

Regards,
Vinayak

On 27 Aug 2018, at 18:42, Henrik Brix Andersen <henrik@brixandersen.dk> wrote:

Hi Vinayak,

Thank you for getting back to me. I just tried reverting commit 26d22b0075cf5a71f13958ec1f2727ac7167eca4, but it does not fix the application behaviour.

Any other ideas are most welcome.

Best regards,
Brix

--
Henrik Brix Andersen

On 27 Aug 2018, at 12.52, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Hi,

I may have introduced a regression (bisected to) in 26d22b0075cf5a71f13958ec1f2727ac7167eca4

I notice that hci_usb sample fails to enumerate the bluetooth class device.

Will get back when I have something. Meanwhile, revert the above mentioned commit and do let me know if your application functions as expected.

Regards,
Vinayak


On 26 Aug 2018, at 19:18, Henrik Brix Andersen <henrik@brixandersen.dk> wrote:

Hi,

I am flashing the board using an Atmel-ICE debugger (using pyOCD 0.11.2) connected to a 10-pin debug connector soldered to the P1 footprint on the bottom of the board.

I am using the same configuration for several NRF52832 boards without issues.

Best regards,
Brix

--
Henrik Brix Andersen

On 26 Aug 2018, at 19.01, Cufi, Carles <Carles.Cufi@nordicsemi.no> wrote:

Hi there,

Can you tell us how you're flashing the board? Another Nordic Devkit, or a separate debug IC?

Also copying Emanuele who's doing most of the work on this board.

Regards,

Carles

On 26/08/2018, 18:07, "devel@lists.zephyrproject.org on behalf of Henrik Brix Andersen" <devel@lists.zephyrproject.org on behalf of henrik@brixandersen.dk> wrote:

Hi,

I have just acquired an NRF52840 Dongle (nrf52840_pca10059) and I am facing some difficulties with board startup.

When I flash a zephyr binary to the board (e.g. samples/basic/blinky) the board starts up fine and starts the application.
But when I disconnect the board from USB power and reconnect it, the application no longer starts (and the internal DC-DC converter does not seem to start-up either).

If I run no-op pyOCD command (e.g. pyocd-flashtool -t nrf52840) the application springs to life (e.g. for blinky, the LED starts to blink).
I am not using mcuboot or any other bootloader; just the bare-bone sample application.

What am I missing here?

Best regards,
Brix
--
Henrik Brix Andersen












Re: NRF52: GPIOTE Static 400 µA

Carles Cufi
 

Hi Ismael,

 

Copying the relevant people.

 

Carles

 

From: <devel@...> on behalf of ismael fillonneau <ismael.fillonneau@...>
Date: Tuesday, 28 August 2018 at 18:01
To: "devel@..." <devel@...>
Subject: [Zephyr-devel] NRF52: GPIOTE Static 400 µA

 

To all Nordic team,

Is there a patch in the pipe to fix GPIOTE used in the same time as I2C interface?

cf nordic bug:

http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.Rev2.errata%2Fdita%2Ferrata%2FnRF52832%2FRev2%2Flatest%2Fanomaly_832_89.html&cp=2_1_1_0_1_26

The pbm is that a lot of sensors are using I2C & interrupts(so GPIOTE) in the same time (ex: lsm6dsl, lis3mdl, hts221, lis2dh...) and NRF52 consumes 400uA statically.

Currently, nothing is done to desactivate I2C in the NRF52 but maybe someone has a PR coming soon.

Waiting your feedback.....


Regards,

Ismael Fillonneau

 


Re: [RFC/RFT PATCH] Coccinelle: Add support for coccinelle infrastructure

Kinder, David B <david.b.kinder@...>
 

Take a look at our developer guidelines for more information about contributing to the project, and in particular the contribution workflow:
http://docs.zephyrproject.org/contribute/contribute_guidelines.html#contribution-workflow

-- david

-----Original Message-----
From: devel@lists.zephyrproject.org [mailto:devel@lists.zephyrproject.org]
On Behalf Of Himanshu Jha
Sent: Tuesday, August 28, 2018 12:34 PM
To: Nashif, Anas <anas.nashif@intel.com>
Cc: devel@lists.zephyrproject.org; Julia Lawall <Julia.Lawall@lip6.fr>
Subject: Re: [Zephyr-devel] [RFC/RFT PATCH] Coccinelle: Add support for
coccinelle infrastructure

On Tue, Aug 28, 2018 at 06:57:07PM +0000, Nashif, Anas wrote:
Hi Jha,
Can you post this as a PR on github with the RFC details ?
Sure!

Now, I realised why there are no patches in devel-mailing list and instead
everyone creates PR via github.

But I've never tried PR in the past so please let me know if anything goes
wrong, when I send the request.


Thanks
--
Himanshu Jha
Undergraduate Student
Department of Electronics & Communication Guru Tegh Bahadur Institute of
Technology


Re: nrf52840_pca10059 startup

Chettimada, Vinayak Kariappa
 

Where are you applying the 3V? to VDD_nRF  or VBUS_nRF? VBUS_nRF has a min, typ. and max of 4.35, 5, and 5.5 Volts. Can you measure the VDD_nRF, when you have the dongle plugged to USB port?


I dont have a dongle presently, reviewing the schematics, I see no reason why the chip should not be running the code in it.




From: Henrik Brix Andersen <henrik@...>
Sent: Tuesday, August 28, 2018 9:08 PM
To: Chettimada, Vinayak Kariappa
Cc: Cufi, Carles; Zephyr Devel List; Di Santo, Emanuele
Subject: Re: [Zephyr-devel] nrf52840_pca10059 startup
 
Hi all,

I have found that a single low-to-high transition on the SWDCLK pin of the PCA10059 makes the application spring to life.
No debugger attached, no external circuitry at all. Just an external power source of 3V and a switch for applying a low-to-high transition of the SWDCLK line.

Could this have something to do with the internal DC-DC converter of the NRF52840?

Regards,
Brix
-- 
Henrik Brix Andersen

> On 27 Aug 2018, at 22.20, Henrik Brix Andersen <henrik@...> wrote:
>
> Hi,
>
> I am not using the NRF52832 configuration on the NRF52840 SoC; I merely noted that I have successfully used the same programmer (Atmel-ICE) for interacting with NRF52832 SoCs.
>
> Yes, my application is samples/basic/blinky (and all other samples). I have tried the samples/bluetooth/peripheral sample; same issue.
> When I initially flash the sample it starts up and everything works as intended. If I then disconnect USB power and reconnect it, nothing starts up (BLE scanner does not show the peripheral anymore).
> A simple no-op SWD connection then does the trick; the application springs to life (without flashing a new binary).
>
> I have tried a few of the USB samples as well; none of them shows up as a device on the USB bus.
>
> Do you know if the original firmware binary (the one present on the device when shipping) for the PCA10059 is available anywhere? It could be interesting to see if that behaves correctly.
> Are you able to share your locally built zephyr.bin file for the blinky sample with me?
>
> Best regards,
> Brix
> --
> Henrik Brix Andersen
>
>> On 27 Aug 2018, at 22.06, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:
>>
>> Something you mention about using NRF52832 configuration, why would you want to use that on nRF52840 SoC?
>>
>> You mention blinky as the example, is that the application you have trouble with? We tried that on our dongle, and see no issues.
>>
>> I have tried BLE peripheral sample and hci_usb sample on nRF52840 merely powered from nRF USB interface, and see no issues.
>>
>> Please confirm, that your application is samples/basic/blinky… also please try the samples/bluetooth/peripheral and let me know if you don’t see BLE advertising.
>>
>> Regards,
>> Vinayak
>>
>>> On 27 Aug 2018, at 18:42, Henrik Brix Andersen <henrik@...> wrote:
>>>
>>> Hi Vinayak,
>>>
>>> Thank you for getting back to me. I just tried reverting commit 26d22b0075cf5a71f13958ec1f2727ac7167eca4, but it does not fix the application behaviour.
>>>
>>> Any other ideas are most welcome.
>>>
>>> Best regards,
>>> Brix
>>>
>>> --
>>> Henrik Brix Andersen
>>>
>>>> On 27 Aug 2018, at 12.52, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I may have introduced a regression (bisected to) in 26d22b0075cf5a71f13958ec1f2727ac7167eca4
>>>>
>>>> I notice that hci_usb sample fails to enumerate the bluetooth class device.
>>>>
>>>> Will get back when I have something. Meanwhile, revert the above mentioned commit and do let me know if your application functions as expected.
>>>>
>>>> Regards,
>>>> Vinayak
>>>>
>>>>
>>>>> On 26 Aug 2018, at 19:18, Henrik Brix Andersen <henrik@...> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I am flashing the board using an Atmel-ICE debugger (using pyOCD 0.11.2) connected to a 10-pin debug connector soldered to the P1 footprint on the bottom of the board.
>>>>>
>>>>> I am using the same configuration for several NRF52832 boards without issues.
>>>>>
>>>>> Best regards,
>>>>> Brix
>>>>>
>>>>> --
>>>>> Henrik Brix Andersen
>>>>>
>>>>>> On 26 Aug 2018, at 19.01, Cufi, Carles <Carles.Cufi@...> wrote:
>>>>>>
>>>>>> Hi there,
>>>>>>
>>>>>> Can you tell us how you're flashing the board? Another Nordic Devkit, or a separate debug IC?
>>>>>>
>>>>>> Also copying Emanuele who's doing most of the work on this board.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Carles
>>>>>>
>>>>>> On 26/08/2018, 18:07, "devel@... on behalf of Henrik Brix Andersen" <devel@... on behalf of henrik@...> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have just acquired an NRF52840 Dongle (nrf52840_pca10059) and I am facing some difficulties with board startup.
>>>>>>
>>>>>> When I flash a zephyr binary to the board (e.g. samples/basic/blinky) the board starts up fine and starts the application.
>>>>>> But when I disconnect the board from USB power and reconnect it, the application no longer starts (and the internal DC-DC converter does not seem to start-up either).
>>>>>>
>>>>>> If I run no-op pyOCD command (e.g. pyocd-flashtool -t nrf52840) the application springs to life (e.g. for blinky, the LED starts to blink).
>>>>>> I am not using mcuboot or any other bootloader; just the bare-bone sample application.
>>>>>>
>>>>>> What am I missing here?
>>>>>>
>>>>>> Best regards,
>>>>>> Brix
>>>>>> --
>>>>>> Henrik Brix Andersen
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>
>
>


Re: [RFC/RFT PATCH] Coccinelle: Add support for coccinelle infrastructure

Himanshu Jha <himanshujha199640@...>
 

On Tue, Aug 28, 2018 at 06:57:07PM +0000, Nashif, Anas wrote:
Hi Jha,
Can you post this as a PR on github with the RFC details ?
Sure!

Now, I realised why there are no patches in devel-mailing
list and instead everyone creates PR via github.

But I've never tried PR in the past so please let me know
if anything goes wrong, when I send the request.


Thanks
--
Himanshu Jha
Undergraduate Student
Department of Electronics & Communication
Guru Tegh Bahadur Institute of Technology


Re: nrf52840_pca10059 startup

Henrik Brix Andersen
 

Hi all,

I have found that a single low-to-high transition on the SWDCLK pin of the PCA10059 makes the application spring to life.
No debugger attached, no external circuitry at all. Just an external power source of 3V and a switch for applying a low-to-high transition of the SWDCLK line.

Could this have something to do with the internal DC-DC converter of the NRF52840?

Regards,
Brix
--
Henrik Brix Andersen

On 27 Aug 2018, at 22.20, Henrik Brix Andersen <henrik@brixandersen.dk> wrote:

Hi,

I am not using the NRF52832 configuration on the NRF52840 SoC; I merely noted that I have successfully used the same programmer (Atmel-ICE) for interacting with NRF52832 SoCs.

Yes, my application is samples/basic/blinky (and all other samples). I have tried the samples/bluetooth/peripheral sample; same issue.
When I initially flash the sample it starts up and everything works as intended. If I then disconnect USB power and reconnect it, nothing starts up (BLE scanner does not show the peripheral anymore).
A simple no-op SWD connection then does the trick; the application springs to life (without flashing a new binary).

I have tried a few of the USB samples as well; none of them shows up as a device on the USB bus.

Do you know if the original firmware binary (the one present on the device when shipping) for the PCA10059 is available anywhere? It could be interesting to see if that behaves correctly.
Are you able to share your locally built zephyr.bin file for the blinky sample with me?

Best regards,
Brix
--
Henrik Brix Andersen

On 27 Aug 2018, at 22.06, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Something you mention about using NRF52832 configuration, why would you want to use that on nRF52840 SoC?

You mention blinky as the example, is that the application you have trouble with? We tried that on our dongle, and see no issues.

I have tried BLE peripheral sample and hci_usb sample on nRF52840 merely powered from nRF USB interface, and see no issues.

Please confirm, that your application is samples/basic/blinky… also please try the samples/bluetooth/peripheral and let me know if you don’t see BLE advertising.

Regards,
Vinayak

On 27 Aug 2018, at 18:42, Henrik Brix Andersen <henrik@brixandersen.dk> wrote:

Hi Vinayak,

Thank you for getting back to me. I just tried reverting commit 26d22b0075cf5a71f13958ec1f2727ac7167eca4, but it does not fix the application behaviour.

Any other ideas are most welcome.

Best regards,
Brix

--
Henrik Brix Andersen

On 27 Aug 2018, at 12.52, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Hi,

I may have introduced a regression (bisected to) in 26d22b0075cf5a71f13958ec1f2727ac7167eca4

I notice that hci_usb sample fails to enumerate the bluetooth class device.

Will get back when I have something. Meanwhile, revert the above mentioned commit and do let me know if your application functions as expected.

Regards,
Vinayak


On 26 Aug 2018, at 19:18, Henrik Brix Andersen <henrik@brixandersen.dk> wrote:

Hi,

I am flashing the board using an Atmel-ICE debugger (using pyOCD 0.11.2) connected to a 10-pin debug connector soldered to the P1 footprint on the bottom of the board.

I am using the same configuration for several NRF52832 boards without issues.

Best regards,
Brix

--
Henrik Brix Andersen

On 26 Aug 2018, at 19.01, Cufi, Carles <Carles.Cufi@nordicsemi.no> wrote:

Hi there,

Can you tell us how you're flashing the board? Another Nordic Devkit, or a separate debug IC?

Also copying Emanuele who's doing most of the work on this board.

Regards,

Carles

On 26/08/2018, 18:07, "devel@lists.zephyrproject.org on behalf of Henrik Brix Andersen" <devel@lists.zephyrproject.org on behalf of henrik@brixandersen.dk> wrote:

Hi,

I have just acquired an NRF52840 Dongle (nrf52840_pca10059) and I am facing some difficulties with board startup.

When I flash a zephyr binary to the board (e.g. samples/basic/blinky) the board starts up fine and starts the application.
But when I disconnect the board from USB power and reconnect it, the application no longer starts (and the internal DC-DC converter does not seem to start-up either).

If I run no-op pyOCD command (e.g. pyocd-flashtool -t nrf52840) the application springs to life (e.g. for blinky, the LED starts to blink).
I am not using mcuboot or any other bootloader; just the bare-bone sample application.

What am I missing here?

Best regards,
Brix
--
Henrik Brix Andersen












Re: [RFC/RFT PATCH] Coccinelle: Add support for coccinelle infrastructure

Nashif, Anas
 

Hi Jha,
Can you post this as a PR on github with the RFC details ?

Thanks

-----Original Message-----
From: Himanshu Jha [mailto:himanshujha199640@gmail.com]
Sent: Tuesday, August 28, 2018 11:33 AM
To: Nashif, Anas <anas.nashif@intel.com>; devel@lists.zephyrproject.org
Cc: Himanshu Jha <himanshujha199640@gmail.com>; Julia Lawall <Julia.Lawall@lip6.fr>
Subject: [RFC/RFT PATCH] Coccinelle: Add support for coccinelle infrastructure

'coccicheck' target is used to initiate Coccinelle tool with four different modes:

* 'patch' proposes a fix, when possible.
* 'report' generates a list in the following format:
file:line:column-column: message
* 'context' highlights lines of interest and their context in a
diff-like style. Lines of interest are indicated with '-'.
* 'org' generates a report in the Org mode format of Emacs.

Cc: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
---
Makefile | 14 +
doc/scripts/coccinelle.rst | 503 ++++++++++++++++++++++++++
scripts/coccicheck | 206 +++++++++++
scripts/coccinelle/null/badzero.cocci | 238 ++++++++++++
scripts/ld-version.sh | 11 +
5 files changed, 972 insertions(+)
create mode 100644 doc/scripts/coccinelle.rst create mode 100755 scripts/coccicheck create mode 100644 scripts/coccinelle/null/badzero.cocci
create mode 100755 scripts/ld-version.sh

diff --git a/Makefile b/Makefile
index 88c6c2cda..f1479d18b 100644
--- a/Makefile
+++ b/Makefile
@@ -15,3 +15,17 @@ export Q
# ---------------------------------------------------------------------------
htmldocs:
$(Q)$(MAKE) -C doc htmldocs
+
+# SHELL used by kbuild
+CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
+ else if [ -x /bin/bash ]; then echo /bin/bash; \
+ else echo sh; fi ; fi)
+
+ifeq ("$(origin M)", "command line")
+ KBUILD_EXTMOD := $(M)
+endif
+
+export KBUILD_EXTMOD
+
+coccicheck:
+ $(Q)$(CONFIG_SHELL) $(ZEPHYR_BASE)/scripts/$@
diff --git a/doc/scripts/coccinelle.rst b/doc/scripts/coccinelle.rst new file mode 100644 index 000000000..be2bba35b
--- /dev/null
+++ b/doc/scripts/coccinelle.rst
@@ -0,0 +1,503 @@
+.. Copyright 2010 Nicolas Palix <npalix@diku.dk> .. Copyright 2010
+Julia Lawall <julia@diku.dk> .. Copyright 2010 Gilles Muller
+<Gilles.Muller@lip6.fr>
+
+.. highlight:: none
+
+Coccinelle
+==========
+
+Coccinelle is a tool for pattern matching and text transformation that
+has many uses in kernel development, including the application of
+complex, tree-wide patches and detection of problematic programming patterns.
+
+Getting Coccinelle
+-------------------
+
+The semantic patches included in the kernel use features and options
+which are provided by Coccinelle version 1.0.0-rc11 and above.
+Using earlier versions will fail as the option names used by the
+Coccinelle files and coccicheck have been updated.
+
+Coccinelle is available through the package manager of many
+distributions, e.g. :
+
+ - Debian
+ - Fedora
+ - Ubuntu
+ - OpenSUSE
+ - Arch Linux
+ - NetBSD
+ - FreeBSD
+
+Some distribution packages are obsolete and it is recommended to use
+the latest version released from the Coccinelle homepage at
+http://coccinelle.lip6.fr/
+
+Or from Github at:
+
+https://github.com/coccinelle/coccinelle
+
+Once you have it, run the following commands::
+
+ ./autogen
+ ./configure
+ make
+
+as a regular user, and install it with::
+
+ sudo make install
+
+More detailed installation instructions to build from source can be
+found at:
+
+https://github.com/coccinelle/coccinelle/blob/master/install.txt
+
+Supplemental documentation
+---------------------------
+
+For supplemental documentation refer to the wiki:
+
+https://bottest.wiki.kernel.org/coccicheck
+
+The wiki documentation always refers to the linux-next version of the script.
+
+For Semantic Patch Language(SmPL) grammar documentation refer to:
+
+http://coccinelle.lip6.fr/documentation.php
+
+Using Coccinelle on the Linux kernel
+------------------------------------
+
+A Coccinelle-specific target is defined in the top level Makefile. This
+target is named ``coccicheck`` and calls the ``coccicheck`` front-end
+in the ``scripts`` directory.
+
+Four basic modes are defined: ``patch``, ``report``, ``context``, and
+``org``. The mode to use is specified by setting the MODE variable with
+``MODE=<mode>``.
+
+- ``patch`` proposes a fix, when possible.
+
+- ``report`` generates a list in the following format:
+ file:line:column-column: message
+
+- ``context`` highlights lines of interest and their context in a
+ diff-like style.Lines of interest are indicated with ``-``.
+
+- ``org`` generates a report in the Org mode format of Emacs.
+
+Note that not all semantic patches implement all modes. For easy use of
+Coccinelle, the default mode is "report".
+
+Two other modes provide some common combinations of these modes.
+
+- ``chain`` tries the previous modes in the order above until one succeeds.
+
+- ``rep+ctxt`` runs successively the report mode and the context mode.
+ It should be used with the C option (described later)
+ which checks the code on a file basis.
+
+Examples
+~~~~~~~~
+
+To make a report for every semantic patch, run the following command::
+
+ make coccicheck MODE=report
+
+To produce patches, run::
+
+ make coccicheck MODE=patch
+
+
+The coccicheck target applies every semantic patch available in the
+sub-directories of ``scripts/coccinelle`` to the entire Linux kernel.
+
+For each semantic patch, a commit message is proposed. It gives a
+description of the problem being checked by the semantic patch, and
+includes a reference to Coccinelle.
+
+As any static code analyzer, Coccinelle produces false positives. Thus,
+reports must be carefully checked, and patches reviewed.
+
+To enable verbose messages set the V= variable, for example::
+
+ make coccicheck MODE=report V=1
+
+Coccinelle parallelization
+---------------------------
+
+By default, coccicheck tries to run as parallel as possible. To change
+the parallelism, set the J= variable. For example, to run across 4 CPUs::
+
+ make coccicheck MODE=report J=4
+
+As of Coccinelle 1.0.2 Coccinelle uses Ocaml parmap for
+parallelization, if support for this is detected you will benefit from parmap parallelization.
+
+When parmap is enabled coccicheck will enable dynamic load balancing by
+using ``--chunksize 1`` argument, this ensures we keep feeding threads
+with work one by one, so that we avoid the situation where most work
+gets done by only a few threads. With dynamic load balancing, if a
+thread finishes early we keep feeding it more work.
+
+When parmap is enabled, if an error occurs in Coccinelle, this error
+value is propagated back, the return value of the ``make coccicheck``
+captures this return value.
+
+Using Coccinelle with a single semantic patch
+---------------------------------------------
+
+The optional make variable COCCI can be used to check a single semantic
+patch. In that case, the variable must be initialized with the name of
+the semantic patch to apply.
+
+For instance::
+
+ make coccicheck COCCI=<my_SP.cocci> MODE=patch
+
+or::
+
+ make coccicheck COCCI=<my_SP.cocci> MODE=report
+
+
+Controlling Which Files are Processed by Coccinelle
+---------------------------------------------------
+
+By default the entire kernel source tree is checked.
+
+To apply Coccinelle to a specific directory, ``M=`` can be used.
+For example, to check drivers/net/wireless/ one may write::
+
+ make coccicheck M=drivers/net/wireless/
+
+To apply Coccinelle on a file basis, instead of a directory basis, the
+following command may be used::
+
+ make C=1 CHECK="scripts/coccicheck"
+
+To check only newly edited code, use the value 2 for the C flag, i.e.::
+
+ make C=2 CHECK="scripts/coccicheck"
+
+In these modes, which works on a file basis, there is no information
+about semantic patches displayed, and no commit message proposed.
+
+This runs every semantic patch in scripts/coccinelle by default. The
+COCCI variable may additionally be used to only apply a single semantic
+patch as shown in the previous section.
+
+The "report" mode is the default. You can select another one with the
+MODE variable explained above.
+
+Debugging Coccinelle SmPL patches
+---------------------------------
+
+Using coccicheck is best as it provides in the spatch command line
+include options matching the options used when we compile the kernel.
+You can learn what these options are by using V=1, you could then
+manually run Coccinelle with debug options added.
+
+Alternatively you can debug running Coccinelle against SmPL patches by
+asking for stderr to be redirected to stderr, by default stderr is
+redirected to /dev/null, if you'd like to capture stderr you can
+specify the ``DEBUG_FILE="file.txt"`` option to coccicheck. For
+instance::
+
+ rm -f cocci.err
+ make coccicheck COCCI=scripts/coccinelle/free/kfree.cocci MODE=report DEBUG_FILE=cocci.err
+ cat cocci.err
+
+You can use SPFLAGS to add debugging flags, for instance you may want
+to add both --profile --show-trying to SPFLAGS when debugging. For
+instance you may want to use::
+
+ rm -f err.log
+ export COCCI=scripts/coccinelle/misc/irqf_oneshot.cocci
+ make coccicheck DEBUG_FILE="err.log" MODE=report SPFLAGS="--profile
+ --show-trying" M=./drivers/mfd/arizona-irq.c
+
+err.log will now have the profiling information, while stdout will
+provide some progress information as Coccinelle moves forward with
+work.
+
+DEBUG_FILE support is only supported when using coccinelle >= 1.0.2.
+
+.cocciconfig support
+--------------------
+
+Coccinelle supports reading .cocciconfig for default Coccinelle options
+that should be used every time spatch is spawned, the order of
+precedence for variables for .cocciconfig is as follows:
+
+- Your current user's home directory is processed first
+- Your directory from which spatch is called is processed next
+- The directory provided with the --dir option is processed last, if
+used
+
+Since coccicheck runs through make, it naturally runs from the kernel
+proper dir, as such the second rule above would be implied for picking
+up a .cocciconfig when using ``make coccicheck``.
+
+``make coccicheck`` also supports using M= targets. If you do not
+supply any M= target, it is assumed you want to target the entire kernel.
+The kernel coccicheck script has::
+
+ if [ "$KBUILD_EXTMOD" = "" ] ; then
+ OPTIONS="--dir $srctree $COCCIINCLUDE"
+ else
+ OPTIONS="--dir $KBUILD_EXTMOD $COCCIINCLUDE"
+ fi
+
+KBUILD_EXTMOD is set when an explicit target with M= is used. For both
+cases the spatch --dir argument is used, as such third rule applies
+when whether M= is used or not, and when M= is used the target
+directory can have its own .cocciconfig file. When M= is not passed as
+an argument to coccicheck the target directory is the same as the directory from where spatch was called.
+
+If not using the kernel's coccicheck target, keep the above precedence
+order logic of .cocciconfig reading. If using the kernel's coccicheck
+target, override any of the kernel's .coccicheck's settings using SPFLAGS.
+
+We help Coccinelle when used against Linux with a set of sensible
+defaults options for Linux with our own Linux .cocciconfig. This hints
+to coccinelle git can be used for ``git grep`` queries over coccigrep.
+A timeout of 200 seconds should suffice for now.
+
+The options picked up by coccinelle when reading a .cocciconfig do not
+appear as arguments to spatch processes running on your system, to
+confirm what options will be used by Coccinelle run::
+
+ spatch --print-options-only
+
+You can override with your own preferred index option by using SPFLAGS.
+Take note that when there are conflicting options Coccinelle takes
+precedence for the last options passed. Using .cocciconfig is possible
+to use idutils, however given the order of precedence followed by
+Coccinelle, since the kernel now carries its own .cocciconfig, you will
+need to use SPFLAGS to use idutils if desired. See below section
+"Additional flags" for more details on how to use idutils.
+
+Additional flags
+----------------
+
+Additional flags can be passed to spatch through the SPFLAGS variable.
+This works as Coccinelle respects the last flags given to it when
+options are in conflict. ::
+
+ make SPFLAGS=--use-glimpse coccicheck
+
+Coccinelle supports idutils as well but requires coccinelle >= 1.0.6.
+When no ID file is specified coccinelle assumes your ID database file
+is in the file .id-utils.index on the top level of the kernel,
+coccinelle carries a script scripts/idutils_index.sh which creates the database with::
+
+ mkid -i C --output .id-utils.index
+
+If you have another database filename you can also just symlink with
+this name. ::
+
+ make SPFLAGS=--use-idutils coccicheck
+
+Alternatively you can specify the database filename explicitly, for
+instance::
+
+ make SPFLAGS="--use-idutils /full-path/to/ID" coccicheck
+
+See ``spatch --help`` to learn more about spatch options.
+
+Note that the ``--use-glimpse`` and ``--use-idutils`` options require
+external tools for indexing the code. None of them is thus active by
+default. However, by indexing the code with one of these tools, and
+according to the cocci file used, spatch could proceed the entire code
+base more quickly.
+
+SmPL patch specific options
+---------------------------
+
+SmPL patches can have their own requirements for options passed to
+Coccinelle. SmPL patch specific options can be provided by providing
+them at the top of the SmPL patch, for instance::
+
+ // Options: --no-includes --include-headers
+
+SmPL patch Coccinelle requirements
+----------------------------------
+
+As Coccinelle features get added some more advanced SmPL patches may
+require newer versions of Coccinelle. If an SmPL patch requires at
+least a version of Coccinelle, this can be specified as follows, as an
+example if requiring at least Coccinelle >= 1.0.5::
+
+ // Requires: 1.0.5
+
+Proposing new semantic patches
+-------------------------------
+
+New semantic patches can be proposed and submitted by kernel
+developers. For sake of clarity, they should be organized in the
+sub-directories of ``scripts/coccinelle/``.
+
+
+Detailed description of the ``report`` mode
+-------------------------------------------
+
+``report`` generates a list in the following format::
+
+ file:line:column-column: message
+
+Example
+~~~~~~~
+
+Running::
+
+ make coccicheck MODE=report
+COCCI=scripts/coccinelle/api/err_cast.cocci
+
+will execute the following part of the SmPL script::
+
+ <smpl>
+ @r depends on !context && !patch && (org || report)@
+ expression x;
+ position p;
+ @@
+
+ ERR_PTR@p(PTR_ERR(x))
+
+ @script:python depends on report@
+ p << r.p;
+ x << r.x;
+ @@
+
+ msg="ERR_CAST can be used with %s" % (x)
+ coccilib.report.print_report(p[0], msg)
+ </smpl>
+
+This SmPL excerpt generates entries on the standard output, as
+illustrated below::
+
+ /home/user/linux/crypto/ctr.c:188:9-16: ERR_CAST can be used with alg
+ /home/user/linux/crypto/authenc.c:619:9-16: ERR_CAST can be used with auth
+ /home/user/linux/crypto/xts.c:227:9-16: ERR_CAST can be used with
+ alg
+
+
+Detailed description of the ``patch`` mode
+------------------------------------------
+
+When the ``patch`` mode is available, it proposes a fix for each
+problem identified.
+
+Example
+~~~~~~~
+
+Running::
+
+ make coccicheck MODE=patch COCCI=scripts/coccinelle/api/err_cast.cocci
+
+will execute the following part of the SmPL script::
+
+ <smpl>
+ @ depends on !context && patch && !org && !report @
+ expression x;
+ @@
+
+ - ERR_PTR(PTR_ERR(x))
+ + ERR_CAST(x)
+ </smpl>
+
+This SmPL excerpt generates patch hunks on the standard output, as
+illustrated below::
+
+ diff -u -p a/crypto/ctr.c b/crypto/ctr.c
+ --- a/crypto/ctr.c 2010-05-26 10:49:38.000000000 +0200
+ +++ b/crypto/ctr.c 2010-06-03 23:44:49.000000000 +0200
+ @@ -185,7 +185,7 @@ static struct crypto_instance *crypto_ct
+ alg = crypto_attr_alg(tb[1], CRYPTO_ALG_TYPE_CIPHER,
+ CRYPTO_ALG_TYPE_MASK);
+ if (IS_ERR(alg))
+ - return ERR_PTR(PTR_ERR(alg));
+ + return ERR_CAST(alg);
+
+ /* Block size must be >= 4 bytes. */
+ err = -EINVAL;
+
+Detailed description of the ``context`` mode
+--------------------------------------------
+
+``context`` highlights lines of interest and their context in a
+diff-like style.
+
+ **NOTE**: The diff-like output generated is NOT an applicable patch. The
+ intent of the ``context`` mode is to highlight the important lines
+ (annotated with minus, ``-``) and gives some surrounding context
+ lines around. This output can be used with the diff mode of
+ Emacs to review the code.
+
+Example
+~~~~~~~
+
+Running::
+
+ make coccicheck MODE=context
+COCCI=scripts/coccinelle/api/err_cast.cocci
+
+will execute the following part of the SmPL script::
+
+ <smpl>
+ @ depends on context && !patch && !org && !report@
+ expression x;
+ @@
+
+ * ERR_PTR(PTR_ERR(x))
+ </smpl>
+
+This SmPL excerpt generates diff hunks on the standard output, as
+illustrated below::
+
+ diff -u -p /home/user/linux/crypto/ctr.c /tmp/nothing
+ --- /home/user/linux/crypto/ctr.c 2010-05-26 10:49:38.000000000 +0200
+ +++ /tmp/nothing
+ @@ -185,7 +185,6 @@ static struct crypto_instance *crypto_ct
+ alg = crypto_attr_alg(tb[1], CRYPTO_ALG_TYPE_CIPHER,
+ CRYPTO_ALG_TYPE_MASK);
+ if (IS_ERR(alg))
+ - return ERR_PTR(PTR_ERR(alg));
+
+ /* Block size must be >= 4 bytes. */
+ err = -EINVAL;
+
+Detailed description of the ``org`` mode
+----------------------------------------
+
+``org`` generates a report in the Org mode format of Emacs.
+
+Example
+~~~~~~~
+
+Running::
+
+ make coccicheck MODE=org COCCI=scripts/coccinelle/api/err_cast.cocci
+
+will execute the following part of the SmPL script::
+
+ <smpl>
+ @r depends on !context && !patch && (org || report)@
+ expression x;
+ position p;
+ @@
+
+ ERR_PTR@p(PTR_ERR(x))
+
+ @script:python depends on org@
+ p << r.p;
+ x << r.x;
+ @@
+
+ msg="ERR_CAST can be used with %s" % (x)
+ msg_safe=msg.replace("[","@(").replace("]",")")
+ coccilib.org.print_todo(p[0], msg_safe)
+ </smpl>
+
+This SmPL excerpt generates Org entries on the standard output, as
+illustrated below::
+
+ * TODO [[view:/home/user/linux/crypto/ctr.c::face=ovl-face1::linb=188::colb=9::cole=16][ERR_CAST can be used with alg]]
+ * TODO [[view:/home/user/linux/crypto/authenc.c::face=ovl-face1::linb=619::colb=9::cole=16][ERR_CAST can be used with auth]]
+ * TODO
+ [[view:/home/user/linux/crypto/xts.c::face=ovl-face1::linb=227::colb=9
+ ::cole=16][ERR_CAST can be used with alg]]
diff --git a/scripts/coccicheck b/scripts/coccicheck new file mode 100755 index 000000000..081a0bf06
--- /dev/null
+++ b/scripts/coccicheck
@@ -0,0 +1,206 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+# Linux kernel coccicheck
+#
+# Read Documentation/dev-tools/coccinelle.rst
+#
+# This script requires at least spatch
+# version 1.0.0-rc11.
+
+DIR="$(dirname $(readlink -f $0))/.."
+SPATCH="`which ${SPATCH:=spatch}`"
+
+if [ ! -x "$SPATCH" ]; then
+ echo 'spatch is part of the Coccinelle project and is available at http://coccinelle.lip6.fr/';
+ exit 1
+fi
+
+SPATCH_VERSION=$($SPATCH --version | head -1 | awk '{print $3}')
+SPATCH_VERSION_NUM=$(echo $SPATCH_VERSION |
+${DIR}/scripts/ld-version.sh)
+
+# The verbosity may be set by the environmental parameter V= # as for
+example with 'make V=1 coccicheck'
+
+if [ -n "$V" -a "$V" != "0" ]; then
+ VERBOSE="$V"
+else
+ VERBOSE=0
+fi
+
+FLAGS="--very-quiet"
+
+# You can use SPFLAGS to append extra arguments to coccicheck or
+override any # heuristics done in this file as Coccinelle accepts the
+last options when # options conflict.
+#
+# A good example for use of SPFLAGS is if you want to debug your cocci
+script, # you can for instance use the following:
+#
+# $ export COCCI=scripts/coccinelle/misc/irqf_oneshot.cocci
+# $ make coccicheck MODE=report DEBUG_FILE="all.err" SPFLAGS="--profile
+--show-trying" M=./drivers/mfd/arizona-irq.c # # "--show-trying" should
+show you what rule is being processed as it goes to # stdout, you do
+not need a debug file for that. The profile output will be # be sent to
+stdout, if you provide a DEBUG_FILE the profiling data can be #
+inspected there.
+#
+# --profile will not output if --very-quiet is used, so avoid it.
+echo $SPFLAGS | egrep -e "--profile|--show-trying" 2>&1 > /dev/null if
+[ $? -eq 0 ]; then
+ FLAGS="--quiet"
+fi
+
+# spatch only allows include directories with the syntax "-I include"
+# while gcc also allows "-Iinclude" and "-include include"
+COCCIINCLUDE=${LINUXINCLUDE//-I/-I }
+COCCIINCLUDE=${COCCIINCLUDE// -include/ --include}
+
+if [ "$KBUILD_EXTMOD" = "" ] ; then
+ OPTIONS="--dir $ZEPHYR_BASE $COCCIINCLUDE"
+else
+ OPTIONS="--dir $KBUILD_EXTMOD $COCCIINCLUDE"
+fi
+
+if [ -z "$J" ]; then
+ NPROC=$(getconf _NPROCESSORS_ONLN)
+else
+ NPROC="$J"
+fi
+
+if [ "$KBUILD_EXTMOD" != "" ] ; then
+ OPTIONS="--patch $ZEPHYR_BASE $OPTIONS"
+fi
+
+# You can override by using SPFLAGS
+if [ "$NPROC" != "1" ]; then
+ # Using 0 should work as well, refer to _SC_NPROCESSORS_ONLN use on
+ # https://github.com/rdicosmo/parmap/blob/master/setcore_stubs.c
+ OPTIONS="$OPTIONS --jobs $NPROC --chunksize 1"
+fi
+
+if [ "$MODE" = "" ] ; then
+ echo 'You have not explicitly specified the mode to use. Using default "report" mode.'
+ echo 'Available modes are the following: patch, report, context, org'
+ echo 'You can specify the mode with "make coccicheck MODE=<mode>"'
+ echo 'Note however that some modes are not implemented by some semantic patches.'
+ MODE="report"
+fi
+
+if [ "$MODE" = "chain" ] ; then
+ echo 'You have selected the "chain" mode.'
+ echo 'All available modes will be tried (in that order): patch, report, context, org'
+elif [ "$MODE" = "report" -o "$MODE" = "org" ] ; then
+ FLAGS="--no-show-diff $FLAGS"
+fi
+
+ echo ''
+ echo 'Please check for false positives in the output before submitting a patch.'
+ echo 'When using "patch" mode, carefully review the patch before submitting it.'
+ echo ''
+
+run_cmd_parmap() {
+ if [ $VERBOSE -ne 0 ] ; then
+ echo "Running ($NPROC in parallel): $@"
+ fi
+ echo $@ >>$DEBUG_FILE
+ $@ 2>>$DEBUG_FILE
+ err=$?
+ if [[ $err -ne 0 ]]; then
+ echo "coccicheck failed"
+ exit $err
+ fi
+}
+
+# You can override heuristics with SPFLAGS, these must always go last
+OPTIONS="$OPTIONS $SPFLAGS"
+
+coccinelle () {
+ COCCI="$1"
+
+ OPT=`grep "Options:" $COCCI | cut -d':' -f2`
+ REQ=`grep "Requires:" $COCCI | cut -d':' -f2 | sed "s| ||"`
+ REQ_NUM=$(echo $REQ | ${DIR}/scripts/ld-version.sh)
+ if [ "$REQ_NUM" != "0" ] ; then
+ if [ "$SPATCH_VERSION_NUM" -lt "$REQ_NUM" ] ; then
+ echo "Skipping coccinelle SmPL patch: $COCCI"
+ echo "You have coccinelle: $SPATCH_VERSION"
+ echo "This SmPL patch requires: $REQ"
+ return
+ fi
+ fi
+
+# The option '--parse-cocci' can be used to syntactically check the SmPL files.
+#
+# $SPATCH -D $MODE $FLAGS -parse_cocci $COCCI $OPT > /dev/null
+
+ if [ $VERBOSE -ne 0 ] ; then
+
+ FILE=${COCCI#$ZEPHYR_BASE/}
+
+ echo "Processing `basename $COCCI`"
+ echo "with option(s) \"$OPT\""
+ echo ''
+ echo 'Message example to submit a patch:'
+
+ sed -ne 's|^///||p' $COCCI
+
+ if [ "$MODE" = "patch" ] ; then
+ echo ' The semantic patch that makes this change is available'
+ elif [ "$MODE" = "report" ] ; then
+ echo ' The semantic patch that makes this report is available'
+ elif [ "$MODE" = "context" ] ; then
+ echo ' The semantic patch that spots this code is available'
+ elif [ "$MODE" = "org" ] ; then
+ echo ' The semantic patch that makes this Org report is available'
+ else
+ echo ' The semantic patch that makes this output is available'
+ fi
+ echo " in $FILE."
+ echo ''
+ echo ' More information about semantic patching is available at'
+ echo ' http://coccinelle.lip6.fr/';
+ echo ''
+
+ if [ "`sed -ne 's|^//#||p' $COCCI`" ] ; then
+ echo 'Semantic patch information:'
+ sed -ne 's|^//#||p' $COCCI
+ echo ''
+ fi
+ fi
+
+ if [ "$MODE" = "chain" ] ; then
+ run_cmd_parmap $SPATCH -D patch \
+ $FLAGS --cocci-file $COCCI $OPT $OPTIONS || \
+ run_cmd_parmap $SPATCH -D report \
+ $FLAGS --cocci-file $COCCI $OPT $OPTIONS --no-show-diff || \
+ run_cmd_parmap $SPATCH -D context \
+ $FLAGS --cocci-file $COCCI $OPT $OPTIONS || \
+ run_cmd_parmap $SPATCH -D org \
+ $FLAGS --cocci-file $COCCI $OPT $OPTIONS --no-show-diff || exit 1
+ elif [ "$MODE" = "rep+ctxt" ] ; then
+ run_cmd_parmap $SPATCH -D report \
+ $FLAGS --cocci-file $COCCI $OPT $OPTIONS --no-show-diff && \
+ run_cmd_parmap $SPATCH -D context \
+ $FLAGS --cocci-file $COCCI $OPT $OPTIONS || exit 1
+ else
+ run_cmd_parmap $SPATCH -D $MODE $FLAGS --cocci-file $COCCI $OPT $OPTIONS || exit 1
+ fi
+
+}
+
+if [ "$DEBUG_FILE" != "/dev/null" -a "$DEBUG_FILE" != "" ]; then
+ if [ -f $DEBUG_FILE ]; then
+ echo "Debug file $DEBUG_FILE exists, bailing"
+ exit
+ fi
+else
+ DEBUG_FILE="/dev/null"
+fi
+
+if [ "$COCCI" = "" ] ; then
+ for f in `find $ZEPHYR_BASE/scripts/coccinelle/ -name '*.cocci' -type f | sort`; do
+ coccinelle $f
+ done
+else
+ coccinelle $COCCI
+fi
diff --git a/scripts/coccinelle/null/badzero.cocci b/scripts/coccinelle/null/badzero.cocci
new file mode 100644
index 000000000..f597c8007
--- /dev/null
+++ b/scripts/coccinelle/null/badzero.cocci
@@ -0,0 +1,238 @@
+/// Compare pointer-typed values to NULL rather than 0 /// //# This
+makes an effort to choose between !x and x == NULL. !x is used //# if
+it has previously been used with the function used to initialize x.
+//# This relies on type information. More type information can be
+obtained //# using the option -all_includes and the option -I to
+specify an //# include path.
+//
+// Confidence: High
+// Copyright: (C) 2012 Julia Lawall, INRIA/LIP6. GPLv2.
+// Copyright: (C) 2012 Gilles Muller, INRIA/LiP6. GPLv2.
+// URL: http://coccinelle.lip6.fr/
+// Requires: 1.0.0
+// Options:
+
+virtual patch
+virtual context
+virtual org
+virtual report
+
+@initialize:ocaml@
+@@
+let negtable = Hashtbl.create 101
+
+@depends on patch@
+expression *E;
+identifier f;
+@@
+
+(
+ (E = f(...)) ==
+- 0
++ NULL
+|
+ (E = f(...)) !=
+- 0
++ NULL
+|
+- 0
++ NULL
+ == (E = f(...))
+|
+- 0
++ NULL
+ != (E = f(...))
+)
+
+
+@t1 depends on !patch@
+expression *E;
+identifier f;
+position p;
+@@
+
+(
+ (E = f(...)) ==
+* 0@p
+|
+ (E = f(...)) !=
+* 0@p
+|
+* 0@p
+ == (E = f(...))
+|
+* 0@p
+ != (E = f(...))
+)
+
+@script:python depends on org@
+p << t1.p;
+@@
+
+coccilib.org.print_todo(p[0], "WARNING comparing pointer to 0")
+
+@script:python depends on report@
+p << t1.p;
+@@
+
+coccilib.report.print_report(p[0], "WARNING comparing pointer to 0")
+
+// Tests of returned values
+
+@s@
+identifier f;
+expression E,E1;
+@@
+
+ E = f(...)
+ ... when != E = E1
+ !E
+
+@script:ocaml depends on s@
+f << s.f;
+@@
+
+try let _ = Hashtbl.find negtable f in () with Not_found -> Hashtbl.add
+negtable f ()
+
+@ r disable is_zero,isnt_zero exists @
+expression *E;
+identifier f;
+@@
+
+E = f(...)
+...
+(E == 0
+|E != 0
+|0 == E
+|0 != E
+)
+
+@script:ocaml@
+f << r.f;
+@@
+
+try let _ = Hashtbl.find negtable f in () with Not_found ->
+include_match false
+
+// This rule may lead to inconsistent path problems, if E is defined in
+two // places @ depends on patch disable is_zero,isnt_zero @ expression
+*E; expression E1; identifier r.f; @@
+
+E = f(...)
+<...
+(
+- E == 0
++ !E
+|
+- E != 0
++ E
+|
+- 0 == E
++ !E
+|
+- 0 != E
++ E
+)
+...>
+?E = E1
+
+@t2 depends on !patch disable is_zero,isnt_zero @ expression *E;
+expression E1; identifier r.f; position p1; position p2; @@
+
+E = f(...)
+<...
+(
+* E == 0@p1
+|
+* E != 0@p2
+|
+* 0@p1 == E
+|
+* 0@p1 != E
+)
+...>
+?E = E1
+
+@script:python depends on org@
+p << t2.p1;
+@@
+
+coccilib.org.print_todo(p[0], "WARNING comparing pointer to 0, suggest
+!E")
+
+@script:python depends on org@
+p << t2.p2;
+@@
+
+coccilib.org.print_todo(p[0], "WARNING comparing pointer to 0")
+
+@script:python depends on report@
+p << t2.p1;
+@@
+
+coccilib.report.print_report(p[0], "WARNING comparing pointer to 0,
+suggest !E")
+
+@script:python depends on report@
+p << t2.p2;
+@@
+
+coccilib.report.print_report(p[0], "WARNING comparing pointer to 0")
+
+@ depends on patch disable is_zero,isnt_zero @ expression *E; @@
+
+(
+ E ==
+- 0
++ NULL
+|
+ E !=
+- 0
++ NULL
+|
+- 0
++ NULL
+ == E
+|
+- 0
++ NULL
+ != E
+)
+
+@ t3 depends on !patch disable is_zero,isnt_zero @ expression *E;
+position p; @@
+
+(
+* E == 0@p
+|
+* E != 0@p
+|
+* 0@p == E
+|
+* 0@p != E
+)
+
+@script:python depends on org@
+p << t3.p;
+@@
+
+coccilib.org.print_todo(p[0], "WARNING comparing pointer to 0")
+
+@script:python depends on report@
+p << t3.p;
+@@
+
+coccilib.report.print_report(p[0], "WARNING comparing pointer to 0")
diff --git a/scripts/ld-version.sh b/scripts/ld-version.sh new file mode 100755 index 000000000..f2be0ff9a
--- /dev/null
+++ b/scripts/ld-version.sh
@@ -0,0 +1,11 @@
+#!/usr/bin/awk -f
+# SPDX-License-Identifier: GPL-2.0
+# extract linker version number from stdin and turn into single number
+ {
+ gsub(".*\\)", "");
+ gsub(".*version ", "");
+ gsub("-.*", "");
+ split($1,a, ".");
+ print a[1]*100000000 + a[2]*1000000 + a[3]*10000;
+ exit
+ }
--
2.17.1


Re: 回复:回复:[Zephyr-devel] hciconfig tools error with nrf52832 running zephyr

Maureen Helm
 

From: sxzxchen@... <sxzxchen@...>
Sent: Monday, August 27, 2018 11:52 AM
To: Johan Hedberg <johan.hedberg@...>
Cc: Maureen Helm <maureen.helm@...>; devel@...
Subject: 回复:回复:[Zephyr-devel] hciconfig tools error with nrf52832 running zephyr

 

ohsorry that I missed the dot.it is 4.1.15 actually

发自我的华为手机



-------- 原始邮件 --------
题:Re: 回复:[Zephyr-devel] hciconfig tools error with nrf52832 running zephyr
发件人:Johan Hedberg
收件人:sxzxchen@...
抄送:Maureen Helm ,devel@...


Earlier you said it was 4.1.15. Which one was a typo? :)

Johan

On Tue, Aug 28, 2018, sxzxchen@... wrote:
> imx6ullwith linux kernel version 4.15
>
> 发自我的华为手机
>
>
> -------- 原始邮件 --------
> 题:Re: [Zephyr-devel] hciconfig tools error with nrf52832 running zephyr
> 发件人:Maureen Helm
> 收件人:sxzxchen@...,Johan Hedberg
> 抄送:devel@...
>
>
>
>
> Which NXP device are you running embedded Linux? I can check to see if we
> have plans to update the kernel version.
>
>
>
> From: devel@... On
> Behalf Of sxzxchen@...
> Sent: Monday, August 27, 2018 7:28 AM
> To: Johan Hedberg
> Cc: devel@...
> Subject: Re: [Zephyr-devel] hciconfig tools error with nrf52832 running
> zephyr
>
>
>
> Thanks for your explanation.since the embedded linux version is bound with
> the chip, I cannot update it easily.So is there any ways to solve this
> problem without updating linux version ?
>
>
>
>
>
>
>
> At 2018-08-24 13:24:28, "Johan Hedberg" wrote:
>
> >Hi,
>
> >
>
> >On Thu, Aug 23, 2018, sxzxchen@... wrote:
>
> >> I bought a official nrf52832 development kits and ported zephyr
>
> >> project successfully. It runs fine with my ubuntu host,via btattach
>
> >> and btmgmt tools.But it didn't work with my nxp embedded linux,the
>
> >> linux version is 4.1.15 and supports hciattach hciconfig tools
>
> >> only.When I tried to bring the bluetooth module up with hciconfig hci0
>
> >> up,an error comes up:
>
> >
>
> >The 4.1 kernel is too old to support controllers without a public
>
> >address. IIRC you need at least a 4.4 kernel, but ideally something much
>
> >newer than that.
>
> >
>
> >Johan
>
>
>
>
>
>
>


Re: [RFC/RFT PATCH] Coccinelle: Add support for coccinelle infrastructure

Himanshu Jha <himanshujha199640@...>
 

On Tue, Aug 28, 2018 at 09:03:26PM +0530, Himanshu Jha wrote:
'coccicheck' target is used to initiate Coccinelle tool
with four different modes:

* 'patch' proposes a fix, when possible.
* 'report' generates a list in the following format:
file:line:column-column: message
* 'context' highlights lines of interest and their context in a
diff-like style. Lines of interest are indicated with '-'.
* 'org' generates a report in the Org mode format of Emacs.

Cc: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
---
Assumptions:
-----------

I hope everyone has setup their Zephyr Environment, and if not
then please use run before testing:

$ export ZEPHYR_BASE=$( builtin cd "$( dirname "$DIR" )" && pwd ${PWD_OPT})

Because this variable is used in 'scripts/coccicheck' to determine the
root source code tree.

Please read the 'coccinelle.rst' documentation and follow the installation
instructions. It is always advised to install using the latest sources
from Github to fully support Coccinelle.

Queries:
-------

1. Is there any bleeding edge branch to base the work on which regularly
gets updated like '-next' tree in the mainline kernel ?

2. Copyrights: Zephyr uses Apache 2.0 License and the 'coccicheck' scripts
inherited from the mainline kernel use GPLv2 License. So, what is the
correct license to be used ?
Note: I see 'checkpatch.pl' is copied as-is with few tweaks and uses
GPLv2.

3. IIRC Anas pointed out in the TSC meeting to exclude few directories
to be parsed/cleaned-up since they were vendor specific(or something
like that). So, what directories should be ignored ?


P.S: This patch is just to initiate discussion/suggestions/rants and
much more constructed patch shall be sent soon.

Please test and let me know if there are any bugs/issues.

For Coccinelle specific queries contact the list: cocci@systeme.lip6.fr

For now, we have only included "badzero.cocci" to show how everything
works and will post more cocci rules based on Zephyr and would need
your help and suggestions to frame new rules.


Some Testing Results:
--------------------

-------------------------------------------------------------------------------
himanshu@himanshu-Vostro-3559:~/zephyr$ export ZEPHYR_BASE=$( builtin cd "$( dirname "$DIR" )" && pwd ${PWD_OPT})
himanshu@himanshu-Vostro-3559:~/zephyr$ make coccicheck MODE=report V=1

Please check for false positives in the output before submitting a patch.
When using "patch" mode, carefully review the patch before submitting it.

Processing badzero.cocci
with option(s) ""

Message example to submit a patch:
Compare pointer-typed values to NULL rather than 0

The semantic patch that makes this report is available
in scripts/coccinelle/null/badzero.cocci.

More information about semantic patching is available at
http://coccinelle.lip6.fr/

Semantic patch information:
This makes an effort to choose between !x and x == NULL. !x is used
if it has previously been used with the function used to initialize x.
This relies on type information. More type information can be obtained
using the option -all_includes and the option -I to specify an
include path.

Running (4 in parallel): /usr/local/bin/spatch -D report --no-show-diff --very-quiet --cocci-file /home/himanshu/zephyr/scripts/coccinelle/null/badzero.cocci --dir /home/himanshu/zephyr --jobs 4 --chunksize 1
/home/himanshu/zephyr/tests/crypto/ctr_prng/src/ctr_prng.c:304:20-21: WARNING comparing pointer to 0
/home/himanshu/zephyr/tests/crypto/ctr_prng/src/ctr_prng.c:310:18-19: WARNING comparing pointer to 0
/home/himanshu/zephyr/tests/crypto/ctr_prng/src/ctr_prng.c:316:18-19: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/hal/nxp/mcux/drivers/imx/fsl_trng.c:1245:22-23: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/hal/nxp/mcux/drivers/imx/fsl_trng.c:1522:17-18: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/hal/nxp/mcux/drivers/imx/fsl_trng.c:1522:38-39: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/lib/crypto/tinycrypt/source/ctr_prng.c:219:6-7: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/lib/crypto/tinycrypt/source/ctr_prng.c:219:20-21: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/lib/crypto/tinycrypt/source/ctr_prng.c:225:7-8: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/lib/crypto/tinycrypt/source/ctr_prng.c:129:5-6: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/lib/crypto/tinycrypt/source/ctr_prng.c:140:6-7: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/lib/crypto/tinycrypt/source/ctr_prng.c:140:20-21: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/lib/crypto/tinycrypt/source/ctr_prng.c:175:5-6: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/lib/crypto/tinycrypt/source/ctr_prng.c:187:6-7: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/lib/crypto/tinycrypt/source/ctr_prng.c:274:5-6: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/lib/crypto/tinycrypt/source/ctr_prng.c:76:5-6: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/lib/crypto/tinycrypt/source/ctr_prng.c:102:6-7: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/debug/segger/systemview/SEGGER_SYSVIEW.c:2350:23-24: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/debug/segger/systemview/SEGGER_SYSVIEW.c:2434:23-24: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/debug/segger/systemview/SEGGER_SYSVIEW.c:2438:21-22: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/debug/segger/systemview/SEGGER_SYSVIEW.c:2442:19-20: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/debug/segger/systemview/SEGGER_SYSVIEW.c:2472:23-24: WARNING comparing pointer to 0
/home/himanshu/zephyr/samples/mpu/mpu_stack_guard_test/src/main.c:48:14-15: WARNING comparing pointer to 0
/home/himanshu/zephyr/lib/libc/minimal/source/stdlib/strtol.c:116:15-16: WARNING comparing pointer to 0
/home/himanshu/zephyr/lib/libc/minimal/source/stdlib/strtoul.c:95:15-16: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/hal/nxp/mcux/drivers/kinetis/fsl_trng.c:1245:22-23: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/hal/nxp/mcux/drivers/kinetis/fsl_trng.c:1522:17-18: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/hal/nxp/mcux/drivers/kinetis/fsl_trng.c:1522:38-39: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/hal/ti/simplelink/source/ti/devices/cc32xx/driverlib/spi.c:253:15-16: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/hal/ti/simplelink/source/ti/devices/cc32xx/driverlib/spi.c:263:14-15: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/hal/ti/simplelink/source/ti/devices/cc32xx/driverlib/spi.c:385:15-16: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/hal/ti/simplelink/source/ti/devices/cc32xx/driverlib/spi.c:395:14-15: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/hal/ti/simplelink/source/ti/devices/cc32xx/driverlib/spi.c:120:15-16: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/hal/ti/simplelink/source/ti/devices/cc32xx/driverlib/spi.c:130:14-15: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/hal/st/stm32cube/stm32f0xx/drivers/src/stm32f0xx_hal_tim.c:399:17-18: WARNING comparing pointer to 0
/home/himanshu/zephyr/samples/basic/threads/src/main.c:62:29-30: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/hal/st/stm32cube/stm32f7xx/drivers/src/stm32f7xx_hal_tim.c:480:17-18: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/hal/st/stm32cube/stm32f7xx/drivers/src/stm32f7xx_hal_tim.c:3890:23-24: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/hal/st/stm32cube/stm32f7xx/drivers/src/stm32f7xx_hal_tim.c:3665:23-24: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/hal/st/stm32cube/stm32f7xx/drivers/src/stm32f7xx_hal_tim.c:2843:20-21: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/hal/st/stm32cube/stm32f7xx/drivers/src/stm32f7xx_hal_tim.c:2843:37-38: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/hal/st/stm32cube/stm32f7xx/drivers/src/stm32f7xx_hal_tim.c:1958:17-18: WARNING comparing pointer to 0
/home/himanshu/zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c:799:16-17: WARNING comparing pointer to 0, suggest !E
/home/himanshu/zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c:9066:24-25: WARNING comparing pointer to 0
/home/himanshu/zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c:8878:22-23: WARNING comparing pointer to 0
/home/himanshu/zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c:4011:25-26: WARNING comparing pointer to 0
/home/himanshu/zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c:799:16-17: WARNING comparing pointer to 0
/home/himanshu/zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c:3388:34-35: WARNING comparing pointer to 0
/home/himanshu/zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c:2805:27-28: WARNING comparing pointer to 0
/home/himanshu/zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c:2876:26-27: WARNING comparing pointer to 0
/home/himanshu/zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c:10561:28-29: WARNING comparing pointer to 0
/home/himanshu/zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c:8766:28-29: WARNING comparing pointer to 0
/home/himanshu/zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c:8769:29-30: WARNING comparing pointer to 0
/home/himanshu/zephyr/subsys/settings/src/settings.c:298:14-15: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/hal/ti/simplelink/source/ti/drivers/net/wifi/source/netapp.c:1294:28-29: WARNING comparing pointer to 0
/home/himanshu/zephyr/ext/lib/crypto/mbedtls/library/ecp.c:1332:17-18: WARNING comparing pointer to 0

himanshu@himanshu-Vostro-3559:~/zephyr$ make coccicheck MODE=patch V=1

Please check for false positives in the output before submitting a patch.
When using "patch" mode, carefully review the patch before submitting it.

Processing badzero.cocci
with option(s) ""

Message example to submit a patch:
Compare pointer-typed values to NULL rather than 0

The semantic patch that makes this change is available
in scripts/coccinelle/null/badzero.cocci.

More information about semantic patching is available at
http://coccinelle.lip6.fr/

Semantic patch information:
This makes an effort to choose between !x and x == NULL. !x is used
if it has previously been used with the function used to initialize x.
This relies on type information. More type information can be obtained
using the option -all_includes and the option -I to specify an
include path.

Running (4 in parallel): /usr/local/bin/spatch -D patch --very-quiet --cocci-file /home/himanshu/zephyr/scripts/coccinelle/null/badzero.cocci --dir /home/himanshu/zephyr --jobs 4 --chunksize 1
diff -u -p a/ext/hal/st/stm32cube/stm32f0xx/drivers/src/stm32f0xx_hal_tim.c b/ext/hal/st/stm32cube/stm32f0xx/drivers/src/stm32f0xx_hal_tim.c
--- a/ext/hal/st/stm32cube/stm32f0xx/drivers/src/stm32f0xx_hal_tim.c
+++ b/ext/hal/st/stm32cube/stm32f0xx/drivers/src/stm32f0xx_hal_tim.c
@@ -396,7 +396,7 @@ HAL_StatusTypeDef HAL_TIM_Base_Start_DMA
}
else if((htim->State == HAL_TIM_STATE_READY))
{
- if((pData == 0 ) && (Length > 0))
+ if((pData == NULL ) && (Length > 0))
{
return HAL_ERROR;
}
diff -u -p a/ext/lib/crypto/mbedtls/library/ecp.c b/ext/lib/crypto/mbedtls/library/ecp.c
--- a/ext/lib/crypto/mbedtls/library/ecp.c
+++ b/ext/lib/crypto/mbedtls/library/ecp.c
@@ -1329,7 +1329,7 @@ static int ecp_mul_comb_core( const mbed
i = d;
MBEDTLS_MPI_CHK( ecp_select_comb( grp, R, T, t_len, x[i] ) );
MBEDTLS_MPI_CHK( mbedtls_mpi_lset( &R->Z, 1 ) );
- if( f_rng != 0 )
+ if( f_rng != NULL )
MBEDTLS_MPI_CHK( ecp_randomize_jac( grp, R, f_rng, p_rng ) );

while( i-- != 0 )
diff -u -p a/ext/lib/crypto/tinycrypt/source/ctr_prng.c b/ext/lib/crypto/tinycrypt/source/ctr_prng.c
--- a/ext/lib/crypto/tinycrypt/source/ctr_prng.c
+++ b/ext/lib/crypto/tinycrypt/source/ctr_prng.c
@@ -73,7 +73,7 @@ static void arrInc(uint8_t arr[], unsign
*/
static void tc_ctr_prng_update(TCCtrPrng_t * const ctx, uint8_t const * const providedData)
{
- if (0 != ctx) {
+ if (NULL != ctx) {
/* 10.2.1.2 step 1 */
uint8_t temp[TC_AES_KEY_SIZE + TC_AES_BLOCK_SIZE];
unsigned int len = 0U;
@@ -99,7 +99,7 @@ static void tc_ctr_prng_update(TCCtrPrng
}

/* 10.2.1.2 step 4 */
- if (0 != providedData) {
+ if (NULL != providedData) {
unsigned int i;
for (i = 0U; i < sizeof temp; i++) {
temp[i] ^= providedData[i];
@@ -126,7 +126,7 @@ int tc_ctr_prng_init(TCCtrPrng_t * const
uint8_t seed_material[TC_AES_KEY_SIZE + TC_AES_BLOCK_SIZE];
uint8_t zeroArr[TC_AES_BLOCK_SIZE] = {0U};

- if (0 != personalization) {
+ if (NULL != personalization) {
/* 10.2.1.3.1 step 1 */
unsigned int len = pLen;
if (len > sizeof personalization_buf) {
@@ -137,7 +137,7 @@ int tc_ctr_prng_init(TCCtrPrng_t * const
memcpy(personalization_buf, personalization, len);
}

- if ((0 != ctx) && (0 != entropy) && (entropyLen >= sizeof seed_material)) {
+ if ((NULL != ctx) && (NULL != entropy) && (entropyLen >= sizeof seed_material)) {
/* 10.2.1.3.1 step 3 */
memcpy(seed_material, entropy, sizeof seed_material);
for (i = 0U; i < sizeof seed_material; i++) {
@@ -172,7 +172,7 @@ int tc_ctr_prng_reseed(TCCtrPrng_t * con
uint8_t additional_input_buf[TC_AES_KEY_SIZE + TC_AES_BLOCK_SIZE] = {0U};
uint8_t seed_material[TC_AES_KEY_SIZE + TC_AES_BLOCK_SIZE];

- if (0 != additional_input) {
+ if (NULL != additional_input) {
/* 10.2.1.4.1 step 1 */
unsigned int len = additionallen;
if (len > sizeof additional_input_buf) {
@@ -184,7 +184,7 @@ int tc_ctr_prng_reseed(TCCtrPrng_t * con
}

unsigned int seedlen = (unsigned int)TC_AES_KEY_SIZE + (unsigned int)TC_AES_BLOCK_SIZE;
- if ((0 != ctx) && (entropyLen >= seedlen)) {
+ if ((NULL != ctx) && (entropyLen >= seedlen)) {
/* 10.2.1.4.1 step 3 */
memcpy(seed_material, entropy, sizeof seed_material);
for (i = 0U; i < sizeof seed_material; i++) {
@@ -216,13 +216,13 @@ int tc_ctr_prng_generate(TCCtrPrng_t * c

unsigned int result = TC_CRYPTO_FAIL;

- if ((0 != ctx) && (0 != out) && (outlen < MAX_BYTES_PER_REQ)) {
+ if ((NULL != ctx) && (NULL != out) && (outlen < MAX_BYTES_PER_REQ)) {
/* 10.2.1.5.1 step 1 */
if (ctx->reseedCount > MAX_REQS_BEFORE_RESEED) {
result = TC_CTR_PRNG_RESEED_REQ;
} else {
uint8_t additional_input_buf[TC_AES_KEY_SIZE + TC_AES_BLOCK_SIZE] = {0U};
- if (0 != additional_input) {
+ if (NULL != additional_input) {
/* 10.2.1.5.1 step 2 */
unsigned int len = additionallen;
if (len > sizeof additional_input_buf) {
@@ -271,7 +271,7 @@ int tc_ctr_prng_generate(TCCtrPrng_t * c

void tc_ctr_prng_uninstantiate(TCCtrPrng_t * const ctx)
{
- if (0 != ctx) {
+ if (NULL != ctx) {
memset(ctx->key.words, 0x00, sizeof ctx->key.words);
memset(ctx->V, 0x00, sizeof ctx->V);
ctx->reseedCount = 0U;
diff -u -p a/samples/mpu/mpu_stack_guard_test/src/main.c b/samples/mpu/mpu_stack_guard_test/src/main.c
--- a/samples/mpu/mpu_stack_guard_test/src/main.c
+++ b/samples/mpu/mpu_stack_guard_test/src/main.c
@@ -45,7 +45,7 @@ u32_t recursive_loop(u32_t counter, int
}
}
counter++;
- if (dummy == 0)
+ if (dummy == NULL)
return counter;
return recursive_loop(counter, num, dummy)
+recursive_loop(counter, num, dummy);
diff -u -p a/samples/basic/threads/src/main.c b/samples/basic/threads/src/main.c
--- a/samples/basic/threads/src/main.c
+++ b/samples/basic/threads/src/main.c
@@ -59,7 +59,7 @@ void blink(const char *port, u32_t sleep

size_t size = sizeof(struct printk_data_t);
char *mem_ptr = k_malloc(size);
- __ASSERT_NO_MSG(mem_ptr != 0);
+ __ASSERT_NO_MSG(mem_ptr != NULL);

memcpy(mem_ptr, &tx_data, size);

diff -u -p a/lib/libc/minimal/source/stdlib/strtol.c b/lib/libc/minimal/source/stdlib/strtol.c
--- a/lib/libc/minimal/source/stdlib/strtol.c
+++ b/lib/libc/minimal/source/stdlib/strtol.c
@@ -113,7 +113,7 @@ long strtol(const char *nptr, char **end
errno = ERANGE;
} else if (neg)
acc = -acc;
- if (endptr != 0)
+ if (endptr != NULL)
*endptr = (char *)(any ? s - 1 : nptr);
return acc;
}
diff -u -p a/ext/hal/nxp/mcux/drivers/imx/fsl_trng.c b/ext/hal/nxp/mcux/drivers/imx/fsl_trng.c
--- a/ext/hal/nxp/mcux/drivers/imx/fsl_trng.c
+++ b/ext/hal/nxp/mcux/drivers/imx/fsl_trng.c
@@ -1242,7 +1242,7 @@ status_t TRNG_GetDefaultConfig(trng_conf
{
status_t result;

- if (userConfig != 0)
+ if (userConfig != NULL)
{
userConfig->lock = TRNG_USER_CONFIG_DEFAULT_LOCK;
userConfig->clockMode = kTRNG_ClockModeRingOscillator;
@@ -1519,7 +1519,7 @@ status_t TRNG_Init(TRNG_Type *base, cons
status_t result;

/* Check input parameters.*/
- if ((base != 0) && (userConfig != 0))
+ if ((base != NULL) && (userConfig != NULL))
{
#if !(defined(FSL_SDK_DISABLE_DRIVER_CLOCK_CONTROL) && FSL_SDK_DISABLE_DRIVER_CLOCK_CONTROL)
/* Enable the clock gate. */
diff -u -p a/ext/hal/ti/simplelink/source/ti/drivers/net/wifi/source/netapp.c b/ext/hal/ti/simplelink/source/ti/drivers/net/wifi/source/netapp.c
--- a/ext/hal/ti/simplelink/source/ti/drivers/net/wifi/source/netapp.c
+++ b/ext/hal/ti/simplelink/source/ti/drivers/net/wifi/source/netapp.c
@@ -1291,7 +1291,7 @@ _SlReturnVal_t sl_NetAppRecv( _u16 Handl
_SlArgsData_t pArgsData;

/* Validate input arguments */
- if ((NULL == pData) || (0==DataLen))
+ if ((NULL == pData) || (NULL==DataLen))
{
return SL_ERROR_BSD_EINVAL;
}
diff -u -p a/subsys/bluetooth/controller/ll_sw/ctrl.c b/subsys/bluetooth/controller/ll_sw/ctrl.c
--- a/subsys/bluetooth/controller/ll_sw/ctrl.c
+++ b/subsys/bluetooth/controller/ll_sw/ctrl.c
@@ -796,7 +796,7 @@ static u32_t isr_rx_adv_sr_report(struct
u8_t pdu_len;

node_rx = packet_rx_reserve_get(3);
- if (node_rx == 0) {
+ if (!node_rx) {
return 1;
}

@@ -2802,7 +2802,7 @@ isr_rx_conn_pkt_ctrl(struct radio_pdu_no
conn->llcp_conn_param.ack--;

/* set mutex */
- if (_radio.conn_upd == 0) {
+ if (_radio.conn_upd == NULL) {
_radio.conn_upd = conn;
}
}
@@ -2873,7 +2873,7 @@ isr_rx_conn_pkt_ctrl(struct radio_pdu_no
conn->llcp_conn_param.ack--;

/* set mutex */
- if (_radio.conn_upd == 0) {
+ if (_radio.conn_upd == NULL) {
_radio.conn_upd = conn;
}
} else {
@@ -3385,7 +3385,7 @@ isr_rx_conn_pkt(struct radio_pdu_node_rx
/* check so that we will NEVER use the rx buffer reserved for empty
* packet and internal control enqueue
*/
- (packet_rx_reserve_get(3) != 0) &&
+ (packet_rx_reserve_get(3) != NULL) &&
((_radio.fc_ena == 0) ||
((_radio.link_rx_head == _radio.link_rx_tail) &&
(_radio.fc_req == _radio.fc_ack)) ||
@@ -4008,7 +4008,7 @@ static inline void isr_close_conn(void)
u8_t force;

/* Local initiated terminate happened */
- if (_radio.conn_curr == 0) {
+ if (_radio.conn_curr == NULL) {
return;
}

@@ -8763,10 +8763,10 @@ static void packet_tx_enqueue(u8_t max)
pdu_data_q_tx->handle);

if (conn->handle == pdu_data_q_tx->handle) {
- if (conn->pkt_tx_data == 0) {
+ if (conn->pkt_tx_data == NULL) {
conn->pkt_tx_data = node_tx_new;

- if (conn->pkt_tx_head == 0) {
+ if (conn->pkt_tx_head == NULL) {
conn->pkt_tx_head = node_tx_new;
conn->pkt_tx_last = NULL;
}
@@ -8875,7 +8875,7 @@ static void ctrl_tx_enqueue(struct conne
}

/* Update last pointer if ctrl added at end of tx list */
- if (node_tx->next == 0) {
+ if (node_tx->next == NULL) {
conn->pkt_tx_last = node_tx;
}
}
@@ -9063,7 +9063,7 @@ static u32_t conn_update(struct connecti
/* set mutex, if only not already set. As a master the mutex shall
* be set, but a slave we accept it as new 'set' of mutex.
*/
- if (_radio.conn_upd == 0) {
+ if (_radio.conn_upd == NULL) {
LL_ASSERT(conn->role);

_radio.conn_upd = conn;
@@ -10558,7 +10558,7 @@ u32_t ll_connect_disable(void)
{
u32_t status;

- if (_radio.scanner.conn == 0) {
+ if (_radio.scanner.conn == NULL) {
return BT_HCI_ERR_CMD_DISALLOWED;
}

diff -u -p a/tests/crypto/ctr_prng/src/ctr_prng.c b/tests/crypto/ctr_prng/src/ctr_prng.c
--- a/tests/crypto/ctr_prng/src/ctr_prng.c
+++ b/tests/crypto/ctr_prng/src/ctr_prng.c
@@ -301,19 +301,19 @@ static int test_prng_vector(struct prng_
ent_len = strlen(v->entropy) / 2;
exp_len = strlen(v->expected) / 2;

- if (v->personal != 0) {
+ if (v->personal != NULL) {
personal = per;
hex_str_to_num(personal, v->personal);
plen = strlen(v->personal) / 2;
}

- if (v->extra1 != 0) {
+ if (v->extra1 != NULL) {
extra1 = ai1;
hex_str_to_num(extra1, v->extra1);
extra1_len = strlen(v->extra1) / 2;
}

- if (v->extra2 != 0) {
+ if (v->extra2 != NULL) {
extra2 = ai2;
hex_str_to_num(extra2, v->extra2);
extra2_len = strlen(v->extra2) / 2;
diff -u -p a/lib/libc/minimal/source/stdlib/strtoul.c b/lib/libc/minimal/source/stdlib/strtoul.c
--- a/lib/libc/minimal/source/stdlib/strtoul.c
+++ b/lib/libc/minimal/source/stdlib/strtoul.c
@@ -92,7 +92,7 @@ unsigned long strtoul(const char *nptr,
errno = ERANGE;
} else if (neg)
acc = -acc;
- if (endptr != 0)
+ if (endptr != NULL)
*endptr = (char *)(any ? s - 1 : nptr);
return acc;
}
diff -u -p a/ext/hal/ti/simplelink/source/ti/devices/cc32xx/driverlib/spi.c b/ext/hal/ti/simplelink/source/ti/devices/cc32xx/driverlib/spi.c
--- a/ext/hal/ti/simplelink/source/ti/devices/cc32xx/driverlib/spi.c
+++ b/ext/hal/ti/simplelink/source/ti/devices/cc32xx/driverlib/spi.c
@@ -117,7 +117,7 @@ static long SPITransfer8(unsigned long u
//
// Check if output buffer pointer is 0
//
- if(ucDout == 0)
+ if(ucDout == NULL)
{
ulOutIncr = 0;
ulTxDummy = 0xFFFFFFFF;
@@ -127,7 +127,7 @@ static long SPITransfer8(unsigned long u
//
// Check if input buffer pointer is 0
//
- if(ucDin == 0)
+ if(ucDin == NULL)
{
ulInIncr = 0;
ucDin = (unsigned char *)&ulRxDummy;
@@ -250,7 +250,7 @@ static long SPITransfer16(unsigned long
//
// Check if output buffer pointer is 0
//
- if(usDout == 0)
+ if(usDout == NULL)
{
ulOutIncr = 0;
ulTxDummy = 0xFFFFFFFF;
@@ -260,7 +260,7 @@ static long SPITransfer16(unsigned long
//
// Check if input buffer pointer is 0
//
- if(usDin == 0)
+ if(usDin == NULL)
{
ulInIncr = 0;
usDin = (unsigned short *)&ulRxDummy;
@@ -382,7 +382,7 @@ static long SPITransfer32(unsigned long
//
// Check if output buffer pointer is 0
//
- if(ulDout == 0)
+ if(ulDout == NULL)
{
ulOutIncr = 0;
ulTxDummy = 0xFFFFFFFF;
@@ -392,7 +392,7 @@ static long SPITransfer32(unsigned long
//
// Check if input buffer pointer is 0
//
- if(ulDin == 0)
+ if(ulDin == NULL)
{
ulInIncr = 0;
ulDin = &ulRxDummy;
diff -u -p a/ext/hal/st/stm32cube/stm32f7xx/drivers/src/stm32f7xx_hal_tim.c b/ext/hal/st/stm32cube/stm32f7xx/drivers/src/stm32f7xx_hal_tim.c
--- a/ext/hal/st/stm32cube/stm32f7xx/drivers/src/stm32f7xx_hal_tim.c
+++ b/ext/hal/st/stm32cube/stm32f7xx/drivers/src/stm32f7xx_hal_tim.c
@@ -477,7 +477,7 @@ HAL_StatusTypeDef HAL_TIM_Base_Start_DMA
}
else if((htim->State == HAL_TIM_STATE_READY))
{
- if((pData == 0 ) && (Length > 0))
+ if((pData == NULL ) && (Length > 0))
{
return HAL_ERROR;
}
@@ -1955,7 +1955,7 @@ HAL_StatusTypeDef HAL_TIM_IC_Start_DMA(T
}
else if((htim->State == HAL_TIM_STATE_READY))
{
- if((pData == 0 ) && (Length > 0))
+ if((pData == NULL ) && (Length > 0))
{
return HAL_ERROR;
}
@@ -2840,7 +2840,7 @@ HAL_StatusTypeDef HAL_TIM_Encoder_Start_
}
else if((htim->State == HAL_TIM_STATE_READY))
{
- if((((pData1 == 0) || (pData2 == 0) )) && (Length > 0))
+ if((((pData1 == NULL) || (pData2 == NULL) )) && (Length > 0))
{
return HAL_ERROR;
}
@@ -3662,7 +3662,7 @@ HAL_StatusTypeDef HAL_TIM_DMABurst_Write
}
else if((htim->State == HAL_TIM_STATE_READY))
{
- if((BurstBuffer == 0 ) && (BurstLength > 0))
+ if((BurstBuffer == NULL ) && (BurstLength > 0))
{
return HAL_ERROR;
}
@@ -3887,7 +3887,7 @@ HAL_StatusTypeDef HAL_TIM_DMABurst_ReadS
}
else if((htim->State == HAL_TIM_STATE_READY))
{
- if((BurstBuffer == 0 ) && (BurstLength > 0))
+ if((BurstBuffer == NULL ) && (BurstLength > 0))
{
return HAL_ERROR;
}
diff -u -p a/subsys/settings/src/settings.c b/subsys/settings/src/settings.c
--- a/subsys/settings/src/settings.c
+++ b/subsys/settings/src/settings.c
@@ -295,7 +295,7 @@ static s64_t dec_to_s64(char *p_str, cha
p_str++;
}

- if (e_ptr != 0)
+ if (e_ptr != NULL)
*e_ptr = p_str;

if (neg) {
diff -u -p a/ext/hal/nxp/mcux/drivers/kinetis/fsl_trng.c b/ext/hal/nxp/mcux/drivers/kinetis/fsl_trng.c
--- a/ext/hal/nxp/mcux/drivers/kinetis/fsl_trng.c
+++ b/ext/hal/nxp/mcux/drivers/kinetis/fsl_trng.c
@@ -1242,7 +1242,7 @@ status_t TRNG_GetDefaultConfig(trng_conf
{
status_t result;

- if (userConfig != 0)
+ if (userConfig != NULL)
{
userConfig->lock = TRNG_USER_CONFIG_DEFAULT_LOCK;
userConfig->clockMode = kTRNG_ClockModeRingOscillator;
@@ -1519,7 +1519,7 @@ status_t TRNG_Init(TRNG_Type *base, cons
status_t result;

/* Check input parameters.*/
- if ((base != 0) && (userConfig != 0))
+ if ((base != NULL) && (userConfig != NULL))
{
#if !(defined(FSL_SDK_DISABLE_DRIVER_CLOCK_CONTROL) && FSL_SDK_DISABLE_DRIVER_CLOCK_CONTROL)
/* Enable the clock gate. */
diff -u -p a/ext/debug/segger/systemview/SEGGER_SYSVIEW.c b/ext/debug/segger/systemview/SEGGER_SYSVIEW.c
--- a/ext/debug/segger/systemview/SEGGER_SYSVIEW.c
+++ b/ext/debug/segger/systemview/SEGGER_SYSVIEW.c
@@ -2347,7 +2347,7 @@ U32 SEGGER_SYSVIEW_ShrinkId(U32 Id) {
*/
void SEGGER_SYSVIEW_RegisterModule(SEGGER_SYSVIEW_MODULE* pModule) {
SEGGER_SYSVIEW_LOCK();
- if (_pFirstModule == 0) {
+ if (_pFirstModule == NULL) {
//
// No module registered, yet.
// Start list with new module.
@@ -2431,15 +2431,15 @@ void SEGGER_SYSVIEW_SendModule(U8 Module
SEGGER_SYSVIEW_MODULE* pModule;
U32 n;

- if (_pFirstModule != 0) {
+ if (_pFirstModule != NULL) {
pModule = _pFirstModule;
for (n = 0; n < ModuleId; n++) {
pModule = pModule->pNext;
- if (pModule == 0) {
+ if (pModule == NULL) {
break;
}
}
- if (pModule != 0) {
+ if (pModule != NULL) {
U8* pPayload;
U8* pPayloadStart;
RECORD_START(SEGGER_SYSVIEW_INFO_SIZE + 2 * SEGGER_SYSVIEW_QUANTA_U32 + 1 + SEGGER_SYSVIEW_MAX_STRING_LEN);
@@ -2469,7 +2469,7 @@ void SEGGER_SYSVIEW_SendModule(U8 Module
void SEGGER_SYSVIEW_SendModuleDescription(void) {
SEGGER_SYSVIEW_MODULE* pModule;

- if (_pFirstModule != 0) {
+ if (_pFirstModule != NULL) {
pModule = _pFirstModule;
do {
if (pModule->pfSendModuleDesc) {

himanshu@himanshu-Vostro-3559:~/zephyr$ make coccicheck MODE=org V=1

Please check for false positives in the output before submitting a patch.
When using "patch" mode, carefully review the patch before submitting it.

Processing badzero.cocci
with option(s) ""

Message example to submit a patch:
Compare pointer-typed values to NULL rather than 0

The semantic patch that makes this Org report is available
in scripts/coccinelle/null/badzero.cocci.

More information about semantic patching is available at
http://coccinelle.lip6.fr/

Semantic patch information:
This makes an effort to choose between !x and x == NULL. !x is used
if it has previously been used with the function used to initialize x.
This relies on type information. More type information can be obtained
using the option -all_includes and the option -I to specify an
include path.

Running (4 in parallel): /usr/local/bin/spatch -D org --no-show-diff --very-quiet --cocci-file /home/himanshu/zephyr/scripts/coccinelle/null/badzero.cocci --dir /home/himanshu/zephyr --jobs 4 --chunksize 1
* TODO [[view:/home/himanshu/zephyr/tests/crypto/ctr_prng/src/ctr_prng.c::face=ovl-face1::linb=304::colb=20::cole=21][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/tests/crypto/ctr_prng/src/ctr_prng.c::face=ovl-face1::linb=310::colb=18::cole=19][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/tests/crypto/ctr_prng/src/ctr_prng.c::face=ovl-face1::linb=316::colb=18::cole=19][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/hal/nxp/mcux/drivers/kinetis/fsl_trng.c::face=ovl-face1::linb=1245::colb=22::cole=23][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/hal/nxp/mcux/drivers/kinetis/fsl_trng.c::face=ovl-face1::linb=1522::colb=17::cole=18][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/hal/nxp/mcux/drivers/kinetis/fsl_trng.c::face=ovl-face1::linb=1522::colb=38::cole=39][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/hal/nxp/mcux/drivers/imx/fsl_trng.c::face=ovl-face1::linb=1245::colb=22::cole=23][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/hal/nxp/mcux/drivers/imx/fsl_trng.c::face=ovl-face1::linb=1522::colb=17::cole=18][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/hal/nxp/mcux/drivers/imx/fsl_trng.c::face=ovl-face1::linb=1522::colb=38::cole=39][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/hal/st/stm32cube/stm32f0xx/drivers/src/stm32f0xx_hal_tim.c::face=ovl-face1::linb=399::colb=17::cole=18][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/hal/st/stm32cube/stm32f7xx/drivers/src/stm32f7xx_hal_tim.c::face=ovl-face1::linb=480::colb=17::cole=18][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/hal/st/stm32cube/stm32f7xx/drivers/src/stm32f7xx_hal_tim.c::face=ovl-face1::linb=3890::colb=23::cole=24][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/hal/st/stm32cube/stm32f7xx/drivers/src/stm32f7xx_hal_tim.c::face=ovl-face1::linb=3665::colb=23::cole=24][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/hal/st/stm32cube/stm32f7xx/drivers/src/stm32f7xx_hal_tim.c::face=ovl-face1::linb=2843::colb=20::cole=21][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/hal/st/stm32cube/stm32f7xx/drivers/src/stm32f7xx_hal_tim.c::face=ovl-face1::linb=2843::colb=37::cole=38][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/hal/st/stm32cube/stm32f7xx/drivers/src/stm32f7xx_hal_tim.c::face=ovl-face1::linb=1958::colb=17::cole=18][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/lib/libc/minimal/source/stdlib/strtol.c::face=ovl-face1::linb=116::colb=15::cole=16][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/lib/libc/minimal/source/stdlib/strtoul.c::face=ovl-face1::linb=95::colb=15::cole=16][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/hal/ti/simplelink/source/ti/devices/cc32xx/driverlib/spi.c::face=ovl-face1::linb=253::colb=15::cole=16][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/hal/ti/simplelink/source/ti/devices/cc32xx/driverlib/spi.c::face=ovl-face1::linb=263::colb=14::cole=15][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/hal/ti/simplelink/source/ti/devices/cc32xx/driverlib/spi.c::face=ovl-face1::linb=385::colb=15::cole=16][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/hal/ti/simplelink/source/ti/devices/cc32xx/driverlib/spi.c::face=ovl-face1::linb=395::colb=14::cole=15][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/hal/ti/simplelink/source/ti/devices/cc32xx/driverlib/spi.c::face=ovl-face1::linb=120::colb=15::cole=16][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/hal/ti/simplelink/source/ti/devices/cc32xx/driverlib/spi.c::face=ovl-face1::linb=130::colb=14::cole=15][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/lib/crypto/mbedtls/library/ecp.c::face=ovl-face1::linb=1332::colb=17::cole=18][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/debug/segger/systemview/SEGGER_SYSVIEW.c::face=ovl-face1::linb=2350::colb=23::cole=24][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/debug/segger/systemview/SEGGER_SYSVIEW.c::face=ovl-face1::linb=2434::colb=23::cole=24][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/debug/segger/systemview/SEGGER_SYSVIEW.c::face=ovl-face1::linb=2438::colb=21::cole=22][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/debug/segger/systemview/SEGGER_SYSVIEW.c::face=ovl-face1::linb=2442::colb=19::cole=20][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/debug/segger/systemview/SEGGER_SYSVIEW.c::face=ovl-face1::linb=2472::colb=23::cole=24][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/samples/basic/threads/src/main.c::face=ovl-face1::linb=62::colb=29::cole=30][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c::face=ovl-face1::linb=799::colb=16::cole=17][WARNING comparing pointer to 0, suggest !E]]
* TODO [[view:/home/himanshu/zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c::face=ovl-face1::linb=9066::colb=24::cole=25][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c::face=ovl-face1::linb=8878::colb=22::cole=23][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c::face=ovl-face1::linb=4011::colb=25::cole=26][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c::face=ovl-face1::linb=799::colb=16::cole=17][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c::face=ovl-face1::linb=3388::colb=34::cole=35][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c::face=ovl-face1::linb=2805::colb=27::cole=28][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c::face=ovl-face1::linb=2876::colb=26::cole=27][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c::face=ovl-face1::linb=10561::colb=28::cole=29][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c::face=ovl-face1::linb=8766::colb=28::cole=29][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c::face=ovl-face1::linb=8769::colb=29::cole=30][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/hal/ti/simplelink/source/ti/drivers/net/wifi/source/netapp.c::face=ovl-face1::linb=1294::colb=28::cole=29][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/lib/crypto/tinycrypt/source/ctr_prng.c::face=ovl-face1::linb=219::colb=6::cole=7][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/lib/crypto/tinycrypt/source/ctr_prng.c::face=ovl-face1::linb=219::colb=20::cole=21][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/lib/crypto/tinycrypt/source/ctr_prng.c::face=ovl-face1::linb=225::colb=7::cole=8][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/lib/crypto/tinycrypt/source/ctr_prng.c::face=ovl-face1::linb=129::colb=5::cole=6][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/lib/crypto/tinycrypt/source/ctr_prng.c::face=ovl-face1::linb=140::colb=6::cole=7][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/lib/crypto/tinycrypt/source/ctr_prng.c::face=ovl-face1::linb=140::colb=20::cole=21][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/lib/crypto/tinycrypt/source/ctr_prng.c::face=ovl-face1::linb=175::colb=5::cole=6][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/lib/crypto/tinycrypt/source/ctr_prng.c::face=ovl-face1::linb=187::colb=6::cole=7][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/lib/crypto/tinycrypt/source/ctr_prng.c::face=ovl-face1::linb=274::colb=5::cole=6][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/lib/crypto/tinycrypt/source/ctr_prng.c::face=ovl-face1::linb=76::colb=5::cole=6][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/ext/lib/crypto/tinycrypt/source/ctr_prng.c::face=ovl-face1::linb=102::colb=6::cole=7][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/samples/mpu/mpu_stack_guard_test/src/main.c::face=ovl-face1::linb=48::colb=14::cole=15][WARNING comparing pointer to 0]]
* TODO [[view:/home/himanshu/zephyr/subsys/settings/src/settings.c::face=ovl-face1::linb=298::colb=14::cole=15][WARNING comparing pointer to 0]]

himanshu@himanshu-Vostro-3559:~/zephyr$ make coccicheck MODE=patch V=1 M=./subsys/settings/src/settings.c

Please check for false positives in the output before submitting a patch.
When using "patch" mode, carefully review the patch before submitting it.

Processing badzero.cocci
with option(s) ""

Message example to submit a patch:
Compare pointer-typed values to NULL rather than 0

The semantic patch that makes this change is available
in scripts/coccinelle/null/badzero.cocci.

More information about semantic patching is available at
http://coccinelle.lip6.fr/

Semantic patch information:
This makes an effort to choose between !x and x == NULL. !x is used
if it has previously been used with the function used to initialize x.
This relies on type information. More type information can be obtained
using the option -all_includes and the option -I to specify an
include path.

Running (4 in parallel): /usr/local/bin/spatch -D patch --very-quiet --cocci-file /home/himanshu/zephyr/scripts/coccinelle/null/badzero.cocci --patch /home/himanshu/zephyr --dir ./subsys/settings/src/settings.c --jobs 4 --chunksize 1
diff -u -p a/subsys/settings/src/settings.c b/subsys/settings/src/settings.c
--- a/subsys/settings/src/settings.c
+++ b/subsys/settings/src/settings.c
@@ -295,7 +295,7 @@ static s64_t dec_to_s64(char *p_str, cha
p_str++;
}

- if (e_ptr != 0)
+ if (e_ptr != NULL)
*e_ptr = p_str;

if (neg) {
-------------------------------------------------------------------------------


Thanks
--
Himanshu Jha
Undergraduate Student
Department of Electronics & Communication
Guru Tegh Bahadur Institute of Technology


NRF52: GPIOTE Static 400 µA

ismael fillonneau
 

To all Nordic team,

Is there a patch in the pipe to fix GPIOTE used in the same time as I2C interface?

cf nordic bug:

http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.Rev2.errata%2Fdita%2Ferrata%2FnRF52832%2FRev2%2Flatest%2Fanomaly_832_89.html&cp=2_1_1_0_1_26

The pbm is that a lot of sensors are using I2C & interrupts(so GPIOTE) in the same time (ex: lsm6dsl, lis3mdl, hts221, lis2dh...) and NRF52 consumes 400uA statically.

Currently, nothing is done to desactivate I2C in the NRF52 but maybe someone has a PR coming soon.

Waiting your feedback.....


Regards,

Ismael Fillonneau


[RFC/RFT PATCH] Coccinelle: Add support for coccinelle infrastructure

Himanshu Jha <himanshujha199640@...>
 

'coccicheck' target is used to initiate Coccinelle tool
with four different modes:

* 'patch' proposes a fix, when possible.
* 'report' generates a list in the following format:
file:line:column-column: message
* 'context' highlights lines of interest and their context in a
diff-like style. Lines of interest are indicated with '-'.
* 'org' generates a report in the Org mode format of Emacs.

Cc: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
---
Makefile | 14 +
doc/scripts/coccinelle.rst | 503 ++++++++++++++++++++++++++
scripts/coccicheck | 206 +++++++++++
scripts/coccinelle/null/badzero.cocci | 238 ++++++++++++
scripts/ld-version.sh | 11 +
5 files changed, 972 insertions(+)
create mode 100644 doc/scripts/coccinelle.rst
create mode 100755 scripts/coccicheck
create mode 100644 scripts/coccinelle/null/badzero.cocci
create mode 100755 scripts/ld-version.sh

diff --git a/Makefile b/Makefile
index 88c6c2cda..f1479d18b 100644
--- a/Makefile
+++ b/Makefile
@@ -15,3 +15,17 @@ export Q
# ---------------------------------------------------------------------------
htmldocs:
$(Q)$(MAKE) -C doc htmldocs
+
+# SHELL used by kbuild
+CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
+ else if [ -x /bin/bash ]; then echo /bin/bash; \
+ else echo sh; fi ; fi)
+
+ifeq ("$(origin M)", "command line")
+ KBUILD_EXTMOD := $(M)
+endif
+
+export KBUILD_EXTMOD
+
+coccicheck:
+ $(Q)$(CONFIG_SHELL) $(ZEPHYR_BASE)/scripts/$@
diff --git a/doc/scripts/coccinelle.rst b/doc/scripts/coccinelle.rst
new file mode 100644
index 000000000..be2bba35b
--- /dev/null
+++ b/doc/scripts/coccinelle.rst
@@ -0,0 +1,503 @@
+.. Copyright 2010 Nicolas Palix <npalix@diku.dk>
+.. Copyright 2010 Julia Lawall <julia@diku.dk>
+.. Copyright 2010 Gilles Muller <Gilles.Muller@lip6.fr>
+
+.. highlight:: none
+
+Coccinelle
+==========
+
+Coccinelle is a tool for pattern matching and text transformation that has
+many uses in kernel development, including the application of complex,
+tree-wide patches and detection of problematic programming patterns.
+
+Getting Coccinelle
+-------------------
+
+The semantic patches included in the kernel use features and options
+which are provided by Coccinelle version 1.0.0-rc11 and above.
+Using earlier versions will fail as the option names used by
+the Coccinelle files and coccicheck have been updated.
+
+Coccinelle is available through the package manager
+of many distributions, e.g. :
+
+ - Debian
+ - Fedora
+ - Ubuntu
+ - OpenSUSE
+ - Arch Linux
+ - NetBSD
+ - FreeBSD
+
+Some distribution packages are obsolete and it is recommended
+to use the latest version released from the Coccinelle homepage at
+http://coccinelle.lip6.fr/
+
+Or from Github at:
+
+https://github.com/coccinelle/coccinelle
+
+Once you have it, run the following commands::
+
+ ./autogen
+ ./configure
+ make
+
+as a regular user, and install it with::
+
+ sudo make install
+
+More detailed installation instructions to build from source can be
+found at:
+
+https://github.com/coccinelle/coccinelle/blob/master/install.txt
+
+Supplemental documentation
+---------------------------
+
+For supplemental documentation refer to the wiki:
+
+https://bottest.wiki.kernel.org/coccicheck
+
+The wiki documentation always refers to the linux-next version of the script.
+
+For Semantic Patch Language(SmPL) grammar documentation refer to:
+
+http://coccinelle.lip6.fr/documentation.php
+
+Using Coccinelle on the Linux kernel
+------------------------------------
+
+A Coccinelle-specific target is defined in the top level
+Makefile. This target is named ``coccicheck`` and calls the ``coccicheck``
+front-end in the ``scripts`` directory.
+
+Four basic modes are defined: ``patch``, ``report``, ``context``, and
+``org``. The mode to use is specified by setting the MODE variable with
+``MODE=<mode>``.
+
+- ``patch`` proposes a fix, when possible.
+
+- ``report`` generates a list in the following format:
+ file:line:column-column: message
+
+- ``context`` highlights lines of interest and their context in a
+ diff-like style.Lines of interest are indicated with ``-``.
+
+- ``org`` generates a report in the Org mode format of Emacs.
+
+Note that not all semantic patches implement all modes. For easy use
+of Coccinelle, the default mode is "report".
+
+Two other modes provide some common combinations of these modes.
+
+- ``chain`` tries the previous modes in the order above until one succeeds.
+
+- ``rep+ctxt`` runs successively the report mode and the context mode.
+ It should be used with the C option (described later)
+ which checks the code on a file basis.
+
+Examples
+~~~~~~~~
+
+To make a report for every semantic patch, run the following command::
+
+ make coccicheck MODE=report
+
+To produce patches, run::
+
+ make coccicheck MODE=patch
+
+
+The coccicheck target applies every semantic patch available in the
+sub-directories of ``scripts/coccinelle`` to the entire Linux kernel.
+
+For each semantic patch, a commit message is proposed. It gives a
+description of the problem being checked by the semantic patch, and
+includes a reference to Coccinelle.
+
+As any static code analyzer, Coccinelle produces false
+positives. Thus, reports must be carefully checked, and patches
+reviewed.
+
+To enable verbose messages set the V= variable, for example::
+
+ make coccicheck MODE=report V=1
+
+Coccinelle parallelization
+---------------------------
+
+By default, coccicheck tries to run as parallel as possible. To change
+the parallelism, set the J= variable. For example, to run across 4 CPUs::
+
+ make coccicheck MODE=report J=4
+
+As of Coccinelle 1.0.2 Coccinelle uses Ocaml parmap for parallelization,
+if support for this is detected you will benefit from parmap parallelization.
+
+When parmap is enabled coccicheck will enable dynamic load balancing by using
+``--chunksize 1`` argument, this ensures we keep feeding threads with work
+one by one, so that we avoid the situation where most work gets done by only
+a few threads. With dynamic load balancing, if a thread finishes early we keep
+feeding it more work.
+
+When parmap is enabled, if an error occurs in Coccinelle, this error
+value is propagated back, the return value of the ``make coccicheck``
+captures this return value.
+
+Using Coccinelle with a single semantic patch
+---------------------------------------------
+
+The optional make variable COCCI can be used to check a single
+semantic patch. In that case, the variable must be initialized with
+the name of the semantic patch to apply.
+
+For instance::
+
+ make coccicheck COCCI=<my_SP.cocci> MODE=patch
+
+or::
+
+ make coccicheck COCCI=<my_SP.cocci> MODE=report
+
+
+Controlling Which Files are Processed by Coccinelle
+---------------------------------------------------
+
+By default the entire kernel source tree is checked.
+
+To apply Coccinelle to a specific directory, ``M=`` can be used.
+For example, to check drivers/net/wireless/ one may write::
+
+ make coccicheck M=drivers/net/wireless/
+
+To apply Coccinelle on a file basis, instead of a directory basis, the
+following command may be used::
+
+ make C=1 CHECK="scripts/coccicheck"
+
+To check only newly edited code, use the value 2 for the C flag, i.e.::
+
+ make C=2 CHECK="scripts/coccicheck"
+
+In these modes, which works on a file basis, there is no information
+about semantic patches displayed, and no commit message proposed.
+
+This runs every semantic patch in scripts/coccinelle by default. The
+COCCI variable may additionally be used to only apply a single
+semantic patch as shown in the previous section.
+
+The "report" mode is the default. You can select another one with the
+MODE variable explained above.
+
+Debugging Coccinelle SmPL patches
+---------------------------------
+
+Using coccicheck is best as it provides in the spatch command line
+include options matching the options used when we compile the kernel.
+You can learn what these options are by using V=1, you could then
+manually run Coccinelle with debug options added.
+
+Alternatively you can debug running Coccinelle against SmPL patches
+by asking for stderr to be redirected to stderr, by default stderr
+is redirected to /dev/null, if you'd like to capture stderr you
+can specify the ``DEBUG_FILE="file.txt"`` option to coccicheck. For
+instance::
+
+ rm -f cocci.err
+ make coccicheck COCCI=scripts/coccinelle/free/kfree.cocci MODE=report DEBUG_FILE=cocci.err
+ cat cocci.err
+
+You can use SPFLAGS to add debugging flags, for instance you may want to
+add both --profile --show-trying to SPFLAGS when debugging. For instance
+you may want to use::
+
+ rm -f err.log
+ export COCCI=scripts/coccinelle/misc/irqf_oneshot.cocci
+ make coccicheck DEBUG_FILE="err.log" MODE=report SPFLAGS="--profile --show-trying" M=./drivers/mfd/arizona-irq.c
+
+err.log will now have the profiling information, while stdout will
+provide some progress information as Coccinelle moves forward with
+work.
+
+DEBUG_FILE support is only supported when using coccinelle >= 1.0.2.
+
+.cocciconfig support
+--------------------
+
+Coccinelle supports reading .cocciconfig for default Coccinelle options that
+should be used every time spatch is spawned, the order of precedence for
+variables for .cocciconfig is as follows:
+
+- Your current user's home directory is processed first
+- Your directory from which spatch is called is processed next
+- The directory provided with the --dir option is processed last, if used
+
+Since coccicheck runs through make, it naturally runs from the kernel
+proper dir, as such the second rule above would be implied for picking up a
+.cocciconfig when using ``make coccicheck``.
+
+``make coccicheck`` also supports using M= targets. If you do not supply
+any M= target, it is assumed you want to target the entire kernel.
+The kernel coccicheck script has::
+
+ if [ "$KBUILD_EXTMOD" = "" ] ; then
+ OPTIONS="--dir $srctree $COCCIINCLUDE"
+ else
+ OPTIONS="--dir $KBUILD_EXTMOD $COCCIINCLUDE"
+ fi
+
+KBUILD_EXTMOD is set when an explicit target with M= is used. For both cases
+the spatch --dir argument is used, as such third rule applies when whether M=
+is used or not, and when M= is used the target directory can have its own
+.cocciconfig file. When M= is not passed as an argument to coccicheck the
+target directory is the same as the directory from where spatch was called.
+
+If not using the kernel's coccicheck target, keep the above precedence
+order logic of .cocciconfig reading. If using the kernel's coccicheck target,
+override any of the kernel's .coccicheck's settings using SPFLAGS.
+
+We help Coccinelle when used against Linux with a set of sensible defaults
+options for Linux with our own Linux .cocciconfig. This hints to coccinelle
+git can be used for ``git grep`` queries over coccigrep. A timeout of 200
+seconds should suffice for now.
+
+The options picked up by coccinelle when reading a .cocciconfig do not appear
+as arguments to spatch processes running on your system, to confirm what
+options will be used by Coccinelle run::
+
+ spatch --print-options-only
+
+You can override with your own preferred index option by using SPFLAGS. Take
+note that when there are conflicting options Coccinelle takes precedence for
+the last options passed. Using .cocciconfig is possible to use idutils, however
+given the order of precedence followed by Coccinelle, since the kernel now
+carries its own .cocciconfig, you will need to use SPFLAGS to use idutils if
+desired. See below section "Additional flags" for more details on how to use
+idutils.
+
+Additional flags
+----------------
+
+Additional flags can be passed to spatch through the SPFLAGS
+variable. This works as Coccinelle respects the last flags
+given to it when options are in conflict. ::
+
+ make SPFLAGS=--use-glimpse coccicheck
+
+Coccinelle supports idutils as well but requires coccinelle >= 1.0.6.
+When no ID file is specified coccinelle assumes your ID database file
+is in the file .id-utils.index on the top level of the kernel, coccinelle
+carries a script scripts/idutils_index.sh which creates the database with::
+
+ mkid -i C --output .id-utils.index
+
+If you have another database filename you can also just symlink with this
+name. ::
+
+ make SPFLAGS=--use-idutils coccicheck
+
+Alternatively you can specify the database filename explicitly, for
+instance::
+
+ make SPFLAGS="--use-idutils /full-path/to/ID" coccicheck
+
+See ``spatch --help`` to learn more about spatch options.
+
+Note that the ``--use-glimpse`` and ``--use-idutils`` options
+require external tools for indexing the code. None of them is
+thus active by default. However, by indexing the code with
+one of these tools, and according to the cocci file used,
+spatch could proceed the entire code base more quickly.
+
+SmPL patch specific options
+---------------------------
+
+SmPL patches can have their own requirements for options passed
+to Coccinelle. SmPL patch specific options can be provided by
+providing them at the top of the SmPL patch, for instance::
+
+ // Options: --no-includes --include-headers
+
+SmPL patch Coccinelle requirements
+----------------------------------
+
+As Coccinelle features get added some more advanced SmPL patches
+may require newer versions of Coccinelle. If an SmPL patch requires
+at least a version of Coccinelle, this can be specified as follows,
+as an example if requiring at least Coccinelle >= 1.0.5::
+
+ // Requires: 1.0.5
+
+Proposing new semantic patches
+-------------------------------
+
+New semantic patches can be proposed and submitted by kernel
+developers. For sake of clarity, they should be organized in the
+sub-directories of ``scripts/coccinelle/``.
+
+
+Detailed description of the ``report`` mode
+-------------------------------------------
+
+``report`` generates a list in the following format::
+
+ file:line:column-column: message
+
+Example
+~~~~~~~
+
+Running::
+
+ make coccicheck MODE=report COCCI=scripts/coccinelle/api/err_cast.cocci
+
+will execute the following part of the SmPL script::
+
+ <smpl>
+ @r depends on !context && !patch && (org || report)@
+ expression x;
+ position p;
+ @@
+
+ ERR_PTR@p(PTR_ERR(x))
+
+ @script:python depends on report@
+ p << r.p;
+ x << r.x;
+ @@
+
+ msg="ERR_CAST can be used with %s" % (x)
+ coccilib.report.print_report(p[0], msg)
+ </smpl>
+
+This SmPL excerpt generates entries on the standard output, as
+illustrated below::
+
+ /home/user/linux/crypto/ctr.c:188:9-16: ERR_CAST can be used with alg
+ /home/user/linux/crypto/authenc.c:619:9-16: ERR_CAST can be used with auth
+ /home/user/linux/crypto/xts.c:227:9-16: ERR_CAST can be used with alg
+
+
+Detailed description of the ``patch`` mode
+------------------------------------------
+
+When the ``patch`` mode is available, it proposes a fix for each problem
+identified.
+
+Example
+~~~~~~~
+
+Running::
+
+ make coccicheck MODE=patch COCCI=scripts/coccinelle/api/err_cast.cocci
+
+will execute the following part of the SmPL script::
+
+ <smpl>
+ @ depends on !context && patch && !org && !report @
+ expression x;
+ @@
+
+ - ERR_PTR(PTR_ERR(x))
+ + ERR_CAST(x)
+ </smpl>
+
+This SmPL excerpt generates patch hunks on the standard output, as
+illustrated below::
+
+ diff -u -p a/crypto/ctr.c b/crypto/ctr.c
+ --- a/crypto/ctr.c 2010-05-26 10:49:38.000000000 +0200
+ +++ b/crypto/ctr.c 2010-06-03 23:44:49.000000000 +0200
+ @@ -185,7 +185,7 @@ static struct crypto_instance *crypto_ct
+ alg = crypto_attr_alg(tb[1], CRYPTO_ALG_TYPE_CIPHER,
+ CRYPTO_ALG_TYPE_MASK);
+ if (IS_ERR(alg))
+ - return ERR_PTR(PTR_ERR(alg));
+ + return ERR_CAST(alg);
+
+ /* Block size must be >= 4 bytes. */
+ err = -EINVAL;
+
+Detailed description of the ``context`` mode
+--------------------------------------------
+
+``context`` highlights lines of interest and their context
+in a diff-like style.
+
+ **NOTE**: The diff-like output generated is NOT an applicable patch. The
+ intent of the ``context`` mode is to highlight the important lines
+ (annotated with minus, ``-``) and gives some surrounding context
+ lines around. This output can be used with the diff mode of
+ Emacs to review the code.
+
+Example
+~~~~~~~
+
+Running::
+
+ make coccicheck MODE=context COCCI=scripts/coccinelle/api/err_cast.cocci
+
+will execute the following part of the SmPL script::
+
+ <smpl>
+ @ depends on context && !patch && !org && !report@
+ expression x;
+ @@
+
+ * ERR_PTR(PTR_ERR(x))
+ </smpl>
+
+This SmPL excerpt generates diff hunks on the standard output, as
+illustrated below::
+
+ diff -u -p /home/user/linux/crypto/ctr.c /tmp/nothing
+ --- /home/user/linux/crypto/ctr.c 2010-05-26 10:49:38.000000000 +0200
+ +++ /tmp/nothing
+ @@ -185,7 +185,6 @@ static struct crypto_instance *crypto_ct
+ alg = crypto_attr_alg(tb[1], CRYPTO_ALG_TYPE_CIPHER,
+ CRYPTO_ALG_TYPE_MASK);
+ if (IS_ERR(alg))
+ - return ERR_PTR(PTR_ERR(alg));
+
+ /* Block size must be >= 4 bytes. */
+ err = -EINVAL;
+
+Detailed description of the ``org`` mode
+----------------------------------------
+
+``org`` generates a report in the Org mode format of Emacs.
+
+Example
+~~~~~~~
+
+Running::
+
+ make coccicheck MODE=org COCCI=scripts/coccinelle/api/err_cast.cocci
+
+will execute the following part of the SmPL script::
+
+ <smpl>
+ @r depends on !context && !patch && (org || report)@
+ expression x;
+ position p;
+ @@
+
+ ERR_PTR@p(PTR_ERR(x))
+
+ @script:python depends on org@
+ p << r.p;
+ x << r.x;
+ @@
+
+ msg="ERR_CAST can be used with %s" % (x)
+ msg_safe=msg.replace("[","@(").replace("]",")")
+ coccilib.org.print_todo(p[0], msg_safe)
+ </smpl>
+
+This SmPL excerpt generates Org entries on the standard output, as
+illustrated below::
+
+ * TODO [[view:/home/user/linux/crypto/ctr.c::face=ovl-face1::linb=188::colb=9::cole=16][ERR_CAST can be used with alg]]
+ * TODO [[view:/home/user/linux/crypto/authenc.c::face=ovl-face1::linb=619::colb=9::cole=16][ERR_CAST can be used with auth]]
+ * TODO [[view:/home/user/linux/crypto/xts.c::face=ovl-face1::linb=227::colb=9::cole=16][ERR_CAST can be used with alg]]
diff --git a/scripts/coccicheck b/scripts/coccicheck
new file mode 100755
index 000000000..081a0bf06
--- /dev/null
+++ b/scripts/coccicheck
@@ -0,0 +1,206 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+# Linux kernel coccicheck
+#
+# Read Documentation/dev-tools/coccinelle.rst
+#
+# This script requires at least spatch
+# version 1.0.0-rc11.
+
+DIR="$(dirname $(readlink -f $0))/.."
+SPATCH="`which ${SPATCH:=spatch}`"
+
+if [ ! -x "$SPATCH" ]; then
+ echo 'spatch is part of the Coccinelle project and is available at http://coccinelle.lip6.fr/';
+ exit 1
+fi
+
+SPATCH_VERSION=$($SPATCH --version | head -1 | awk '{print $3}')
+SPATCH_VERSION_NUM=$(echo $SPATCH_VERSION | ${DIR}/scripts/ld-version.sh)
+
+# The verbosity may be set by the environmental parameter V=
+# as for example with 'make V=1 coccicheck'
+
+if [ -n "$V" -a "$V" != "0" ]; then
+ VERBOSE="$V"
+else
+ VERBOSE=0
+fi
+
+FLAGS="--very-quiet"
+
+# You can use SPFLAGS to append extra arguments to coccicheck or override any
+# heuristics done in this file as Coccinelle accepts the last options when
+# options conflict.
+#
+# A good example for use of SPFLAGS is if you want to debug your cocci script,
+# you can for instance use the following:
+#
+# $ export COCCI=scripts/coccinelle/misc/irqf_oneshot.cocci
+# $ make coccicheck MODE=report DEBUG_FILE="all.err" SPFLAGS="--profile --show-trying" M=./drivers/mfd/arizona-irq.c
+#
+# "--show-trying" should show you what rule is being processed as it goes to
+# stdout, you do not need a debug file for that. The profile output will be
+# be sent to stdout, if you provide a DEBUG_FILE the profiling data can be
+# inspected there.
+#
+# --profile will not output if --very-quiet is used, so avoid it.
+echo $SPFLAGS | egrep -e "--profile|--show-trying" 2>&1 > /dev/null
+if [ $? -eq 0 ]; then
+ FLAGS="--quiet"
+fi
+
+# spatch only allows include directories with the syntax "-I include"
+# while gcc also allows "-Iinclude" and "-include include"
+COCCIINCLUDE=${LINUXINCLUDE//-I/-I }
+COCCIINCLUDE=${COCCIINCLUDE// -include/ --include}
+
+if [ "$KBUILD_EXTMOD" = "" ] ; then
+ OPTIONS="--dir $ZEPHYR_BASE $COCCIINCLUDE"
+else
+ OPTIONS="--dir $KBUILD_EXTMOD $COCCIINCLUDE"
+fi
+
+if [ -z "$J" ]; then
+ NPROC=$(getconf _NPROCESSORS_ONLN)
+else
+ NPROC="$J"
+fi
+
+if [ "$KBUILD_EXTMOD" != "" ] ; then
+ OPTIONS="--patch $ZEPHYR_BASE $OPTIONS"
+fi
+
+# You can override by using SPFLAGS
+if [ "$NPROC" != "1" ]; then
+ # Using 0 should work as well, refer to _SC_NPROCESSORS_ONLN use on
+ # https://github.com/rdicosmo/parmap/blob/master/setcore_stubs.c
+ OPTIONS="$OPTIONS --jobs $NPROC --chunksize 1"
+fi
+
+if [ "$MODE" = "" ] ; then
+ echo 'You have not explicitly specified the mode to use. Using default "report" mode.'
+ echo 'Available modes are the following: patch, report, context, org'
+ echo 'You can specify the mode with "make coccicheck MODE=<mode>"'
+ echo 'Note however that some modes are not implemented by some semantic patches.'
+ MODE="report"
+fi
+
+if [ "$MODE" = "chain" ] ; then
+ echo 'You have selected the "chain" mode.'
+ echo 'All available modes will be tried (in that order): patch, report, context, org'
+elif [ "$MODE" = "report" -o "$MODE" = "org" ] ; then
+ FLAGS="--no-show-diff $FLAGS"
+fi
+
+ echo ''
+ echo 'Please check for false positives in the output before submitting a patch.'
+ echo 'When using "patch" mode, carefully review the patch before submitting it.'
+ echo ''
+
+run_cmd_parmap() {
+ if [ $VERBOSE -ne 0 ] ; then
+ echo "Running ($NPROC in parallel): $@"
+ fi
+ echo $@ >>$DEBUG_FILE
+ $@ 2>>$DEBUG_FILE
+ err=$?
+ if [[ $err -ne 0 ]]; then
+ echo "coccicheck failed"
+ exit $err
+ fi
+}
+
+# You can override heuristics with SPFLAGS, these must always go last
+OPTIONS="$OPTIONS $SPFLAGS"
+
+coccinelle () {
+ COCCI="$1"
+
+ OPT=`grep "Options:" $COCCI | cut -d':' -f2`
+ REQ=`grep "Requires:" $COCCI | cut -d':' -f2 | sed "s| ||"`
+ REQ_NUM=$(echo $REQ | ${DIR}/scripts/ld-version.sh)
+ if [ "$REQ_NUM" != "0" ] ; then
+ if [ "$SPATCH_VERSION_NUM" -lt "$REQ_NUM" ] ; then
+ echo "Skipping coccinelle SmPL patch: $COCCI"
+ echo "You have coccinelle: $SPATCH_VERSION"
+ echo "This SmPL patch requires: $REQ"
+ return
+ fi
+ fi
+
+# The option '--parse-cocci' can be used to syntactically check the SmPL files.
+#
+# $SPATCH -D $MODE $FLAGS -parse_cocci $COCCI $OPT > /dev/null
+
+ if [ $VERBOSE -ne 0 ] ; then
+
+ FILE=${COCCI#$ZEPHYR_BASE/}
+
+ echo "Processing `basename $COCCI`"
+ echo "with option(s) \"$OPT\""
+ echo ''
+ echo 'Message example to submit a patch:'
+
+ sed -ne 's|^///||p' $COCCI
+
+ if [ "$MODE" = "patch" ] ; then
+ echo ' The semantic patch that makes this change is available'
+ elif [ "$MODE" = "report" ] ; then
+ echo ' The semantic patch that makes this report is available'
+ elif [ "$MODE" = "context" ] ; then
+ echo ' The semantic patch that spots this code is available'
+ elif [ "$MODE" = "org" ] ; then
+ echo ' The semantic patch that makes this Org report is available'
+ else
+ echo ' The semantic patch that makes this output is available'
+ fi
+ echo " in $FILE."
+ echo ''
+ echo ' More information about semantic patching is available at'
+ echo ' http://coccinelle.lip6.fr/';
+ echo ''
+
+ if [ "`sed -ne 's|^//#||p' $COCCI`" ] ; then
+ echo 'Semantic patch information:'
+ sed -ne 's|^//#||p' $COCCI
+ echo ''
+ fi
+ fi
+
+ if [ "$MODE" = "chain" ] ; then
+ run_cmd_parmap $SPATCH -D patch \
+ $FLAGS --cocci-file $COCCI $OPT $OPTIONS || \
+ run_cmd_parmap $SPATCH -D report \
+ $FLAGS --cocci-file $COCCI $OPT $OPTIONS --no-show-diff || \
+ run_cmd_parmap $SPATCH -D context \
+ $FLAGS --cocci-file $COCCI $OPT $OPTIONS || \
+ run_cmd_parmap $SPATCH -D org \
+ $FLAGS --cocci-file $COCCI $OPT $OPTIONS --no-show-diff || exit 1
+ elif [ "$MODE" = "rep+ctxt" ] ; then
+ run_cmd_parmap $SPATCH -D report \
+ $FLAGS --cocci-file $COCCI $OPT $OPTIONS --no-show-diff && \
+ run_cmd_parmap $SPATCH -D context \
+ $FLAGS --cocci-file $COCCI $OPT $OPTIONS || exit 1
+ else
+ run_cmd_parmap $SPATCH -D $MODE $FLAGS --cocci-file $COCCI $OPT $OPTIONS || exit 1
+ fi
+
+}
+
+if [ "$DEBUG_FILE" != "/dev/null" -a "$DEBUG_FILE" != "" ]; then
+ if [ -f $DEBUG_FILE ]; then
+ echo "Debug file $DEBUG_FILE exists, bailing"
+ exit
+ fi
+else
+ DEBUG_FILE="/dev/null"
+fi
+
+if [ "$COCCI" = "" ] ; then
+ for f in `find $ZEPHYR_BASE/scripts/coccinelle/ -name '*.cocci' -type f | sort`; do
+ coccinelle $f
+ done
+else
+ coccinelle $COCCI
+fi
diff --git a/scripts/coccinelle/null/badzero.cocci b/scripts/coccinelle/null/badzero.cocci
new file mode 100644
index 000000000..f597c8007
--- /dev/null
+++ b/scripts/coccinelle/null/badzero.cocci
@@ -0,0 +1,238 @@
+/// Compare pointer-typed values to NULL rather than 0
+///
+//# This makes an effort to choose between !x and x == NULL. !x is used
+//# if it has previously been used with the function used to initialize x.
+//# This relies on type information. More type information can be obtained
+//# using the option -all_includes and the option -I to specify an
+//# include path.
+//
+// Confidence: High
+// Copyright: (C) 2012 Julia Lawall, INRIA/LIP6. GPLv2.
+// Copyright: (C) 2012 Gilles Muller, INRIA/LiP6. GPLv2.
+// URL: http://coccinelle.lip6.fr/
+// Requires: 1.0.0
+// Options:
+
+virtual patch
+virtual context
+virtual org
+virtual report
+
+@initialize:ocaml@
+@@
+let negtable = Hashtbl.create 101
+
+@depends on patch@
+expression *E;
+identifier f;
+@@
+
+(
+ (E = f(...)) ==
+- 0
++ NULL
+|
+ (E = f(...)) !=
+- 0
++ NULL
+|
+- 0
++ NULL
+ == (E = f(...))
+|
+- 0
++ NULL
+ != (E = f(...))
+)
+
+
+@t1 depends on !patch@
+expression *E;
+identifier f;
+position p;
+@@
+
+(
+ (E = f(...)) ==
+* 0@p
+|
+ (E = f(...)) !=
+* 0@p
+|
+* 0@p
+ == (E = f(...))
+|
+* 0@p
+ != (E = f(...))
+)
+
+@script:python depends on org@
+p << t1.p;
+@@
+
+coccilib.org.print_todo(p[0], "WARNING comparing pointer to 0")
+
+@script:python depends on report@
+p << t1.p;
+@@
+
+coccilib.report.print_report(p[0], "WARNING comparing pointer to 0")
+
+// Tests of returned values
+
+@s@
+identifier f;
+expression E,E1;
+@@
+
+ E = f(...)
+ ... when != E = E1
+ !E
+
+@script:ocaml depends on s@
+f << s.f;
+@@
+
+try let _ = Hashtbl.find negtable f in ()
+with Not_found -> Hashtbl.add negtable f ()
+
+@ r disable is_zero,isnt_zero exists @
+expression *E;
+identifier f;
+@@
+
+E = f(...)
+...
+(E == 0
+|E != 0
+|0 == E
+|0 != E
+)
+
+@script:ocaml@
+f << r.f;
+@@
+
+try let _ = Hashtbl.find negtable f in ()
+with Not_found -> include_match false
+
+// This rule may lead to inconsistent path problems, if E is defined in two
+// places
+@ depends on patch disable is_zero,isnt_zero @
+expression *E;
+expression E1;
+identifier r.f;
+@@
+
+E = f(...)
+<...
+(
+- E == 0
++ !E
+|
+- E != 0
++ E
+|
+- 0 == E
++ !E
+|
+- 0 != E
++ E
+)
+...>
+?E = E1
+
+@t2 depends on !patch disable is_zero,isnt_zero @
+expression *E;
+expression E1;
+identifier r.f;
+position p1;
+position p2;
+@@
+
+E = f(...)
+<...
+(
+* E == 0@p1
+|
+* E != 0@p2
+|
+* 0@p1 == E
+|
+* 0@p1 != E
+)
+...>
+?E = E1
+
+@script:python depends on org@
+p << t2.p1;
+@@
+
+coccilib.org.print_todo(p[0], "WARNING comparing pointer to 0, suggest !E")
+
+@script:python depends on org@
+p << t2.p2;
+@@
+
+coccilib.org.print_todo(p[0], "WARNING comparing pointer to 0")
+
+@script:python depends on report@
+p << t2.p1;
+@@
+
+coccilib.report.print_report(p[0], "WARNING comparing pointer to 0, suggest !E")
+
+@script:python depends on report@
+p << t2.p2;
+@@
+
+coccilib.report.print_report(p[0], "WARNING comparing pointer to 0")
+
+@ depends on patch disable is_zero,isnt_zero @
+expression *E;
+@@
+
+(
+ E ==
+- 0
++ NULL
+|
+ E !=
+- 0
++ NULL
+|
+- 0
++ NULL
+ == E
+|
+- 0
++ NULL
+ != E
+)
+
+@ t3 depends on !patch disable is_zero,isnt_zero @
+expression *E;
+position p;
+@@
+
+(
+* E == 0@p
+|
+* E != 0@p
+|
+* 0@p == E
+|
+* 0@p != E
+)
+
+@script:python depends on org@
+p << t3.p;
+@@
+
+coccilib.org.print_todo(p[0], "WARNING comparing pointer to 0")
+
+@script:python depends on report@
+p << t3.p;
+@@
+
+coccilib.report.print_report(p[0], "WARNING comparing pointer to 0")
diff --git a/scripts/ld-version.sh b/scripts/ld-version.sh
new file mode 100755
index 000000000..f2be0ff9a
--- /dev/null
+++ b/scripts/ld-version.sh
@@ -0,0 +1,11 @@
+#!/usr/bin/awk -f
+# SPDX-License-Identifier: GPL-2.0
+# extract linker version number from stdin and turn into single number
+ {
+ gsub(".*\\)", "");
+ gsub(".*version ", "");
+ gsub("-.*", "");
+ split($1,a, ".");
+ print a[1]*100000000 + a[2]*1000000 + a[3]*10000;
+ exit
+ }
--
2.17.1


Re: 回复:[Zephyr-devel] hciconfig tools error with nrf52832 running zephyr

Serafin
 

Hi


Well it should not be a big deal to compile a more modern Linux Kernel for i.mx6. Most things are mainline. 4.1 is EOL anyway.


Best regards

Serafin


On 27/08/18 18:16, sxzxchen@... wrote:
imx6ull,with linux kernel version 4.15

发自我的华为手机


-------- 原始邮件 --------
主题:Re: [Zephyr-devel] hciconfig tools error with nrf52832 running zephyr
发件人:Maureen Helm
收件人:sxzxchen@...,Johan Hedberg
抄送:devel@...


Which NXP device are you running embedded Linux? I can check to see if we have plans to update the kernel version.

 

From: devel@... <devel@...> On Behalf Of sxzxchen@...
Sent: Monday, August 27, 2018 7:28 AM
To: Johan Hedberg <johan.hedberg@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] hciconfig tools error with nrf52832 running zephyr

 

Thanks for your explanation.since the embedded linux version is bound  with the chip, I cannot update it easily.So is there any ways to solve this problem without updating linux version ?  




 


At 2018-08-24 13:24:28, "Johan Hedberg" <johan.hedberg@...> wrote:
>Hi,
>On Thu, Aug 23, 2018, sxzxchen@... wrote:
>> I bought a official nrf52832 development kits and ported zephyr
>> project successfully. It runs fine with my ubuntu host,via btattach
>> and btmgmt tools.But it didn't work with my nxp embedded linux,the
>> linux version is 4.1.15 and supports hciattach hciconfig tools
>> only.When I tried to bring the bluetooth module up with hciconfig hci0
>> up,an error comes up:
>The 4.1 kernel is too old to support controllers without a public
>address. IIRC you need at least a 4.4 kernel, but ideally something much
>newer than that.
>Johan

 

 



Re: NRF52 : use of NFFS file system

Carles Cufi
 

Hi Laurence,

 

I am copying a couple of people that might be able to help with NFFS config.

 

Carles

 

From: users@... <users@...> On Behalf Of Laurence Pasteau
Sent: 27 August 2018 10:06
To: users@...; devel@...
Subject: [Zephyr-users] NRF52 : use of NFFS file system

 

Hi everybody,

 

I worked on a board including a NRF52 and use the file system with NFFS but I never succeed in using it correctly.

 

I have a lot of errors depending on the configuration parameters that I set.

I reduce my problem to a little test that only writes in a loop 12 bytes in a single file. It fails very quickly.

Sometimes the operation seems good when checking the return value. However the file became a file of size null and a new file with another name appears with the previous file. Then some loops later, there is an error in a return value of the write function.

 

I tried to modify NFFS configuration.

In the two cases when  the CONFIG_NFFS_FILESYSTEM_MAX_BLOCK_SIZE is higher and when the global size of the file system is higher ; the test is good during a longer time before failing.

If I write 24 instead of 12 bytes or if I write in two files instead of one, the issue comes sooner.

 

I think something in my configuration (or in my software) is wrong. If someone can help me it would be very helpful.

 

Attached is the little test and the conf file. To reduce the time before failing, I change the file system size to 0x2000.

 

 

Here is my configuration (I don't use MCU_BOOT) :

 

In the dts file :

    partitions {
        compatible = "fixed-partitions";
        #address-cells = <1>;
        #size-cells = <1>;

        boot_partition: partition@0 {
            label = "mcuboot";
            reg = <0x00000000 0xc000>;
        };
        slot0_partition: partition@c000 {
            label = "image-0";
            reg = <0x0000C000 0x32000>;
        };
        slot1_partition: partition@3e000 {
            label = "image-1";
            reg = <0x0003E000 0x32000>;
        };
        scratch_partition: partition@70000 {
            label = "image-scratch";
            reg = <0x00070000 0xa000>;
        };

#if defined(CONFIG_FS_FLASH_STORAGE_PARTITION)
        storage_partition: partition@7a000 {
            label = "storage";
            reg = <0x0007a000 0x00002000>;
        };
#endif
    };

 

In the conf file :

CONFIG_SOC_FLASH_NRF=y
CONFIG_FS_NFFS_NUM_BLOCKS=1024
CONFIG_FS_NFFS_NUM_INODES=1024
CONFIG_FS_NFFS_NUM_CACHE_BLOCKS=1
CONFIG_FS_NFFS_NUM_CACHE_INODES=1
CONFIG_FS_NFFS_NUM_DIRS=4
CONFIG_FS_NFFS_NUM_FILES=4
CONFIG_FS_NFFS_NUM_INODES=64
CONFIG_HEAP_MEM_POOL_SIZE=4096
CONFIG_MAIN_STACK_SIZE=4096
CONFIG_NFFS_FILESYSTEM_MAX_AREAS=12
CONFIG_NFFS_FILESYSTEM_MAX_BLOCK_SIZE=128
CONFIG_FS_FLASH_STORAGE_PARTITION=y
CONFIG_SOC_FLASH_NRF_RADIO_SYNC=y

 

 

In the CMakeLists.txt :

set(BOARD nrf52_pca10040)

target_include_directories(app PRIVATE $ENV{ZEPHYR_BASE}/ext/fs/nffs/include)
target_link_libraries(app NFFS)

 

 

Thanks in advance for any help.

 

Regards,

Laurence

 

 

 

 


Re: Error compiling sample Hello World

Carles Cufi
 

Hi there,

 

Sounds like there’s an issue with DTC and a 32-bit host. While we do support a 32-bit version of it, I’ve never tested it myself since I don’t have access to a 32-bit Windows installation.

Did you install dtc using Chocolatey?

Could you try perhaps running dtc manually? Open a command prompt and then:

 

C:\Users\Carles>dtc --version

Version: DTC 1.4.4-ga81d4ca0-dirty

 

Thanks,

 

Carles

 

From: devel@... <devel@...> On Behalf Of IosuGorostiza
Sent: 28 August 2018 14:30
To: devel@...
Subject: [Zephyr-devel] Error compiling sample Hello World

 

Hi everybody:
I´m trying to compile the example hello_world as described in the Getting Started Guide. I follow every step of the guide but I´m not able to compile. I deleted everything and start again from the beggining several times and always get the same error. The steps I followed was for ARM.
I´m using the board nrf52_pca10040 in a PC with Windows 8.1 Enterprise 32bits.
Next, I paste what I obtained after executing the compiling instruction:

C:\Users\balcalde\zephyr\samples\hello_world\build>cmake -GNinja -DBOARD=nrf52_pca10040 ..

-- Found PythonInterp: C:/Python37/python.exe (found suitable version "3.7", minimum required is "3.4")

-- Selected BOARD nrf52_pca10040

Zephyr version: 1.13.0

Parsing Kconfig tree in C:/Users/balcalde/zephyr//Kconfig

Using C:/Users/balcalde/zephyr/boards/arm/nrf52_pca10040/nrf52_pca10040_defconfig as base

Merging C:/Users/balcalde/zephyr/samples/hello_world/prj.conf

-- Generating zephyr/include/generated/generated_dts_board.h

CMake Error at C:/Users/balcalde/zephyr/cmake/dts.cmake:84 (message):command failed with return code: Exit code 0xc0000135

 

Call Stack (most recent call first):

  C:/Users/balcalde/zephyr/cmake/app/boilerplate.cmake:278 (include)

  CMakeLists.txt:3 (include)

-- Configuring incomplete, errors occurred!

I spent many hours searching trough the web and reading zephyr documentation but I didn´t found anything that help me to solve that error.

I apprecite any help.
Thanks, best regards

 

 



 

 


Error compiling sample Hello World

IosuGorostiza <balcalde@...>
 

Hi everybody:
I´m trying to compile the example hello_world as described in the Getting Started Guide. I follow every step of the guide but I´m not able to compile. I deleted everything and start again from the beggining several times and always get the same error. The steps I followed was for ARM.
I´m using the board nrf52_pca10040 in a PC with Windows 8.1 Enterprise 32bits.
Next, I paste what I obtained after executing the compiling instruction:

C:\Users\balcalde\zephyr\samples\hello_world\build>cmake -GNinja -DBOARD=nrf52_pca10040 ..
-- Found PythonInterp: C:/Python37/python.exe (found suitable version "3.7", minimum required is "3.4")
-- Selected BOARD nrf52_pca10040
Zephyr version: 1.13.0
Parsing Kconfig tree in C:/Users/balcalde/zephyr//Kconfig
Using C:/Users/balcalde/zephyr/boards/arm/nrf52_pca10040/nrf52_pca10040_defconfig as base
Merging C:/Users/balcalde/zephyr/samples/hello_world/prj.conf
-- Generating zephyr/include/generated/generated_dts_board.h
CMake Error at C:/Users/balcalde/zephyr/cmake/dts.cmake:84 (message):command failed with return code: Exit code 0xc0000135
 
Call Stack (most recent call first):
  C:/Users/balcalde/zephyr/cmake/app/boilerplate.cmake:278 (include)
  CMakeLists.txt:3 (include)

-- Configuring incomplete, errors occurred!

I spent many hours searching trough the web and reading zephyr documentation but I didn´t found anything that help me to solve that error.

I apprecite any help.
Thanks, best regards
 
 



 
 

2561 - 2580 of 7602