text:
Zend_Locale_Format::toNumber() fails with setlocale(LC_ALL, 'de_DE')

I am not sure what causes this issue, as I am not able to reproduce it on every machine I have.
To test it I extended zf1/tests/Zend/Locale/FormatTest.php with the following code:
    public function testToNumberSetlocale()
    {
        setlocale(LC_ALL, 'de_DE'); // test setup
        $locale_de = new Zend_Locale('de_DE');
        var_dump(localeconv());
        $params_de = array('precision' => 2, 'locale' => $locale_de);
        $myFloat = 3.2;
        var_dump($myFloat);
        $test1 = Zend_Locale_Format::toNumber($myFloat, $params_de);
        $this->assertEquals("3,2", $test1);
    }

I am var_dumping the float to see if setlocale settings are active, it should output float(3,3) when everything i correct.
Unfortunately I get:
1) Zend_Locale_FormatTest::testToNumberSetlocale
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'3,20'
+'320,00'

I ran this test with phpunit 4.5.0,  PHP 5.3.26 on debian wheezy Linux dev 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux
I read about this problem on the internet, but none of the developers was ever able to reproduce it.
The exact same test is running successfully on my Mac with phpunit 4.5.0, PHP 5.4.24, Darwin mac 13.3.0 Darwin Kernel Version 13.3.0: Tue Jun  3 21:27:35 PDT 2014; root:xnu-2422.110.17~1/RELEASE_X86_64 x86_64
There is one difference in the output of localeconv() though:
Debian
array(18) {
  ["decimal_point"]=>
  string(1) ","
  ["thousands_sep"]=>
  string(1) "."
  ["int_curr_symbol"]=>
  string(4) "EUR "
  ["currency_symbol"]=>
  string(3) "EUR"
  ["mon_decimal_point"]=>
  string(1) ","
  ["mon_thousands_sep"]=>
  string(1) "."
  ["positive_sign"]=>
  string(0) ""
  ["negative_sign"]=>
  string(1) "-"
  ["int_frac_digits"]=>
  int(2)
  ["frac_digits"]=>
  int(2)
  ["p_cs_precedes"]=>
  int(0)
  ["p_sep_by_space"]=>
  int(1)
  ["n_cs_precedes"]=>
  int(0)
  ["n_sep_by_space"]=>
  int(1)
  ["p_sign_posn"]=>
  int(1)
  ["n_sign_posn"]=>
  int(1)
  ["grouping"]=>
  array(2) {
    [0]=>
    int(3)
    [1]=>
    int(3)
  }
  ["mon_grouping"]=>
  array(2) {
    [0]=>
    int(3)
    [1]=>
    int(3)
  }
}

Mac:
array(18) {
  ["decimal_point"]=>
  string(1) ","
  ["thousands_sep"]=>
  string(0) ""
  ["int_curr_symbol"]=>
  string(4) "EUR "
  ["currency_symbol"]=>
  string(2) "Eu"
  ["mon_decimal_point"]=>
  string(1) ","
  ["mon_thousands_sep"]=>
  string(1) "."
  ["positive_sign"]=>
  string(0) ""
  ["negative_sign"]=>
  string(1) "-"
  ["int_frac_digits"]=>
  int(2)
  ["frac_digits"]=>
  int(2)
  ["p_cs_precedes"]=>
  int(1)
  ["p_sep_by_space"]=>
  int(0)
  ["n_cs_precedes"]=>
  int(1)
  ["n_sep_by_space"]=>
  int(0)
  ["p_sign_posn"]=>
  int(1)
  ["n_sign_posn"]=>
  int(1)
  ["grouping"]=>
  array(1) {
    [0]=>
    int(127)
  }
  ["mon_grouping"]=>
  array(2) {
    [0]=>
    int(3)
    [1]=>
    int(3)
  }
}

There is no thousands separator defined on the mac! If I set the locale on the debian machine to it_IT the test runs succesfully with the following output for localeconv:
array(18) {
  ["decimal_point"]=>
  string(1) ","
  ["thousands_sep"]=>
  string(0) ""
  ["int_curr_symbol"]=>
  string(4) "EUR "
  ["currency_symbol"]=>
  string(3) "EUR"
  ["mon_decimal_point"]=>
  string(1) ","
  ["mon_thousands_sep"]=>
  string(1) "."
  ["positive_sign"]=>
  string(0) ""
  ["negative_sign"]=>
  string(1) "-"
  ["int_frac_digits"]=>
  int(2)
  ["frac_digits"]=>
  int(2)
  ["p_cs_precedes"]=>
  int(1)
  ["p_sep_by_space"]=>
  int(1)
  ["n_cs_precedes"]=>
  int(1)
  ["n_sep_by_space"]=>
  int(1)
  ["p_sign_posn"]=>
  int(1)
  ["n_sign_posn"]=>
  int(1)
  ["grouping"]=>
  array(0) {
  }
  ["mon_grouping"]=>
  array(2) {
    [0]=>
    int(3)
    [1]=>
    int(3)
  }
}

On the mac it_IT results in the following for localeconv:
array(18) {
  ["decimal_point"]=>
  string(1) ","
  ["thousands_sep"]=>
  string(2) ". "
  ["int_curr_symbol"]=>
  string(4) "EUR "
  ["currency_symbol"]=>
  string(2) "Eu"
  ["mon_decimal_point"]=>
  string(1) ","
  ["mon_thousands_sep"]=>
  string(1) "."
  ["positive_sign"]=>
  string(0) ""
  ["negative_sign"]=>
  string(1) "-"
  ["int_frac_digits"]=>
  int(2)
  ["frac_digits"]=>
  int(2)
  ["p_cs_precedes"]=>
  int(1)
  ["p_sep_by_space"]=>
  int(1)
  ["n_cs_precedes"]=>
  int(1)
  ["n_sep_by_space"]=>
  int(1)
  ["p_sign_posn"]=>
  int(1)
  ["n_sign_posn"]=>
  int(1)
  ["grouping"]=>
  array(0) {
  }
  ["mon_grouping"]=>
  array(2) {
    [0]=>
    int(3)
    [1]=>
    int(3)
  }
}

and runs successfully too, even though there is a thousands separator set.
Any help is appreciated, tell me if you need more information. Using Zend Framework 1.12.11, it also fails on 1.12.3

Please recheck with PHPs NumberFormatter class:
$fmt = new NumberFormatter('de_DE', NumberFormatter::DECIMAL);
$this->assertEquals('3,2', $fmt->format(3.2));

The test is successfull with the NumberFormatter assertion.

The test is successfull with the NumberFormatter assertion.

This is a good reason to refactor your application.

Excuse me, how is this related to my application? I'm just extending the original ZF1 unit tests with the provided test case completely independant of my application.
Moreover I don't see how a successfull test with the NumberFormatter class is an answer to the problem. The NumberFormatter class is not used in the Zend_Locale_* classes.

Moreover I don't see how a successfull test with the NumberFormatter class is an answer to the problem.  The NumberFormatter class is not used in the Zend_Locale_* classes.

You should use the NumberFormatter class instead of Zend_Locale. It could be the first step of the migration to the a newer ZF version.
Yes, my suggestions is a little bit radical, but Zend_Locale is buggy and slow. (It is also hard to maintain and a big fat code monster.)

OK, then there was a misunderstanding obviously ;).
Thank you for that suggestion. It is definitely a solution in this case. Please decide yourself what to do with this issue. If anybody is interested in investagating further and I can help with that, please let me know.

Please decide yourself what to do with this issue.

The current consideration is to mark Zend_Locale and Zend_Date as deprecated, but we need a migration path for both components.
Btw. Thanks for reporting!

authors: chmielot froschdesign


text:
Document compatibility with MH-Z14

According to datasheet, another sensor from Zhengzhou Winsen Electronics Technology, MH-Z14 has the same protocol as MH-Z19. At least I can't find any differences.
I tried this crate with MH-Z14 and it reads gas concentration successfully. This is my example repo.
I didn't yet checked if Zhengzhou Winsen Electronics Technology has any other sensors with the same protocol. This is webpage that lists CO2 sensors manufactured by this company.

Thank you for your findings, I've added it!

source: gharchive/issue

authors: kolen zenria

license_type: permissive

license_source: github-api


text:
tests/kernel/fatal/kernel.common.stack_sentinel fails on FRDM-KW41Z

With commit: aed767a98c00bc11b5455fb60c3a3d8f0bda37c0
Running via:
./scripts/sanitycheck -p frdm_kw41z --device-testing  --device-serial /dev/serial/by-id/usb-ARM_DAPLink_CMSIS-DAP_0201000028634e45000b5002673a0032a101000097969900-if01 -s tests/kernel/fatal/kernel.common.stack_sentinel
Get the following output:
***** Booting Zephyr OS build v2.0.0-rc1-173-gaed767a98c00 *****
Running test suite fatal
===================================================================
starting test - test_fatal
test alt thread 1: generic CPU exception
FATAL: ***** HARD FAULT *****
FATAL: r0/a1:  0x00000000  r1/a2:  0x00000000  r2/a3:  0x00000000
FATAL: r3/a4:  0x20000ac4 r12/ip:  0x20000158 r14/lr:  0x00000735
FATAL:  xpsr:  0x40000000
FATAL: Faulting instruction address (r15/pc): 0x20000ac4
FATAL: >>> ZEPHYR FATAL ERROR 0: CPU exception
FATAL: Current thread: 0x20000008 (unknown)
Caught system error -- reason 0
test alt thread 2: initiate kernel oops
FATAL: r0/a1:  0x00000003  r1/a2:  0x00000000  r2/a3:  0x00000003
FATAL: r3/a4:  0x00000000 r12/ip:  0x00000000 r14/lr:  0x00003991
FATAL:  xpsr:  0x01000000
FATAL: Faulting instruction address (r15/pc): 0x00000756
FATAL: >>> ZEPHYR FATAL ERROR 3: Kernel oops
FATAL: Current thread: 0x20000008 (unknown)
Caught system error -- reason 3
test alt thread 3: initiate kernel panic
FATAL: r0/a1:  0x00000004  r1/a2:  0x00000000  r2/a3:  0x00000004
FATAL: r3/a4:  0x00000000 r12/ip:  0x00000756 r14/lr:  0x00003991
FATAL:  xpsr:  0x01000000
FATAL: Faulting instruction address (r15/pc): 0x0000076e
FATAL: >>> ZEPHYR FATAL ERROR 4: Kernel panic
FATAL: Current thread: 0x20000008 (unknown)
Caught system error -- reason 4
test alt thread 4: fail assertion
ASSERTION FAIL [0] @ ZEPHYR_BASE/tests/kernel/fatal/src/main.c:123
	intentionally failed assertion
FATAL: r0/a1:  0x00000004  r1/a2:  0x0000007b  r2/a3:  0x000042d8
FATAL: r3/a4:  0x00000791 r12/ip:  0x0000076e r14/lr:  0x00000799
FATAL:  xpsr:  0x21000000
FATAL: Faulting instruction address (r15/pc): 0x00003c84
FATAL: >>> ZEPHYR FATAL ERROR 4: Kernel panic
FATAL: Current thread: 0x20000008 (unknown)
Caught system error -- reason 4
test stack sentinel overflow - timer irq
posting 1024 bytes of junk to stack...
FATAL: ***** HARD FAULT *****
FATAL: r0/a1:  0x00000002  r1/a2:  0xbbbbbbbb  r2/a3:  0xf0f0f0f0
FATAL: r3/a4:  0x200006d8 r12/ip:  0x20000000 r14/lr:  0x00001477
FATAL:  xpsr:  0x0100000f
FATAL: Faulting instruction address (r15/pc): 0x00002f30
FATAL: >>> ZEPHYR FATAL ERROR 0: CPU exception
FATAL: Current thread: 0x20000008 (unknown)
Caught system error -- reason 0
Wrong crash type got 0 expected 2

I don't have the board to test this. Does not seem to fail on frdm_k64f, @galak

I'll try with another Cortex M0+ I have available, and report back

Test passes on nrf51_pca10028 (Cortex-M0) but fails, similarly, on atsamr21_xpro (Cortex-M0+)

Looks like the root cause of this is that an SVC is triggered inside an interrupt, and the interrupt has equal priority. @andrewboie @galak why do we not reserve an IRQ level for SVC in Cortex-m0?

I know that without the BASEPRI, there's irq_lock() will disable SVC interrupts, as well; that might be the reason for not reserving the highest priority for SVC. But then, @andrewboie there is a bug in Z_ARCH_EXCEPT For ARM Cortex-M Baseline, cause svc's may not be blocked due to insufficient priority.

authors: galak ioannisg

repo: zephyrproject-rtos/zephyr


text:
reel_board: tests/net/ieee802154/fragment/ build failure

Describe the bug
Running tests/net/ieee802154/fragment/ on reel board. Build Failure encountered.
To Reproduce
Steps to reproduce the behavior:

west build -p auto -b reel_board tests/net/ieee802154/fragment/

Expected behavior
Be successfully built and test should pass.
Impact
Build failure
Logs and console output
-- west build: making build dir /home/ztest/zephyrproject/zephyr/build pristine
-- west build: generating a build system
Including boilerplate (Zephyr base): /home/ztest/zephyrproject/zephyr/cmake/app/boilerplate.cmake
-- Application: /home/ztest/zephyrproject/zephyr/tests/net/ieee802154/fragment
-- Zephyr version: 2.4.99 (/home/ztest/zephyrproject/zephyr)
-- Found Python3: /usr/bin/python3.9 (found suitable exact version "3.9.0") found components: Interpreter
-- Found west (found suitable version "0.8.0", minimum required is "0.7.1")
-- Board: reel_board
-- Cache files will be written to: /home/ztest/.cache/zephyr
-- Found toolchain: zephyr (/home/ztest/zephyr-sdk-0.11.4)
-- Found dtc: /home/ztest/zephyr-sdk-0.11.4/sysroots/x86_64-pokysdk-linux/usr/bin/dtc (found suitable version "1.5.0", minimum required is "1.4.6")
-- Found BOARD.dts: /home/ztest/zephyrproject/zephyr/boards/arm/reel_board/reel_board.dts
-- Generated zephyr.dts: /home/ztest/zephyrproject/zephyr/build/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: /home/ztest/zephyrproject/zephyr/build/zephyr/include/generated/devicetree_unfixed.h

warning: TEST_RANDOM_GENERATOR (defined at subsys/random/Kconfig:8) was assigned the value 'y' but
got the value 'n'. Check these unsatisfied dependencies: (!ENTROPY_HAS_DRIVER) (=n). See
http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_TEST_RANDOM_GENERATOR.html and/or look
up TEST_RANDOM_GENERATOR in the menuconfig/guiconfig interface. The Application Development Primer,
Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be
helpful too.

Parsing /home/ztest/zephyrproject/zephyr/Kconfig
Loaded configuration '/home/ztest/zephyrproject/zephyr/boards/arm/reel_board/reel_board_defconfig'
Merged configuration '/home/ztest/zephyrproject/zephyr/tests/net/ieee802154/fragment/prj.conf'
Configuration saved to '/home/ztest/zephyrproject/zephyr/build/zephyr/.config'
Kconfig header saved to '/home/ztest/zephyrproject/zephyr/build/zephyr/include/generated/autoconf.h'
-- The C compiler identification is GNU 9.2.0
-- The CXX compiler identification is GNU 9.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /home/ztest/zephyr-sdk-0.11.4/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc
-- Configuring done
-- Generating done
-- Build files have been written to: /home/ztest/zephyrproject/zephyr/build
-- west build: building application
[1/221] Preparing syscall dependency handling

[216/221] Linking C executable zephyr/zephyr_prebuilt.elf
FAILED: zephyr/zephyr_prebuilt.elf
: && ccache /home/ztest/zephyr-sdk-0.11.4/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc   zephyr/CMakeFiles/zephyr_prebuilt.dir/misc/empty_file.c.obj -o zephyr/zephyr_prebuilt.elf  -Wl,-T  zephyr/linker.cmd  -Wl,-Map=/home/ztest/zephyrproject/zephyr/build/zephyr/zephyr_prebuilt.map  -Wl,--whole-archive  app/libapp.a  zephyr/libzephyr.a  zephyr/arch/common/libarch__common.a  zephyr/arch/arch/arm/core/aarch32/libarch__arm__core__aarch32.a  zephyr/arch/arch/arm/core/aarch32/cortex_m/libarch__arm__core__aarch32__cortex_m.a  zephyr/arch/arch/arm/core/aarch32/cortex_m/mpu/libarch__arm__core__aarch32__cortex_m__mpu.a  zephyr/lib/libc/minimal/liblib__libc__minimal.a  zephyr/lib/posix/liblib__posix.a  zephyr/soc/arm/common/cortex_m/libsoc__arm__common__cortex_m.a  zephyr/soc/arm/nordic_nrf/nrf52/libsoc__arm__nordic_nrf__nrf52.a  zephyr/boards/arm/reel_board/libboards__arm__reel_board.a  zephyr/subsys/net/libsubsys__net.a  zephyr/subsys/net/l2/dummy/libsubsys__net__l2__dummy.a  zephyr/subsys/net/l2/ieee802154/libsubsys__net__l2__ieee802154.a  zephyr/subsys/net/ip/libsubsys__net__ip.a  zephyr/subsys/random/libsubsys__random.a  zephyr/subsys/testsuite/ztest/libsubsys__testsuite__ztest.a  zephyr/drivers/gpio/libdrivers__gpio.a  zephyr/drivers/i2c/libdrivers__i2c.a  zephyr/drivers/spi/libdrivers__spi.a  zephyr/drivers/serial/libdrivers__serial.a  zephyr/drivers/entropy/libdrivers__entropy.a  modules/nordic/lib..__modules__hal__nordic.a  -Wl,--no-whole-archive  zephyr/kernel/libkernel.a  zephyr/CMakeFiles/offsets.dir/./arch/arm/core/offsets/offsets.c.obj  -L"/home/ztest/zephyr-sdk-0.11.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/9.2.0/thumb/v7e-m/nofp"  -L/home/ztest/zephyrproject/zephyr/build/zephyr  -lgcc  -Wl,--print-memory-usage  zephyr/arch/common/libisr_tables.a  -mcpu=cortex-m4  -mthumb  -mabi=aapcs  -Wl,--gc-sections  -Wl,--build-id=none  -Wl,--sort-common=descending  -Wl,--sort-section=alignment  -Wl,-u,_OffsetAbsSyms  -Wl,-u,_ConfigAbsSyms  -nostdlib  -static  -no-pie  -Wl,-X  -Wl,-N  -Wl,--orphan-handling=warn && :
Memory region         Used Size  Region Size  %age Used
           FLASH:      107804 B         1 MB     10.28%
            SRAM:       43392 B       256 KB     16.55%
        IDT_LIST:         152 B         2 KB      7.42/home/ztest/zephyr-sdk-0.11.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/9.2.0/../../../../arm-zephyr-eabi/bin/ld: modules/nordic/lib..__modules__hal__nordic.a(nrf_802154_trx_ppi.c.obj): in function `nrf_802154_trx_ppi_for_fem_set':
/home/ztest/zephyrproject/modules/hal/nordic/drivers/nrf_radio_802154/src/nrf_802154_trx_ppi.c:206: undefined reference to `mpsl_fem_abort_extend'
/home/ztest/zephyr-sdk-0.11.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/9.2.0/../../../../arm-zephyr-eabi/bin/ld: /home/ztest/zephyrproject/modules/hal/nordic/drivers/nrf_radio_802154/src/nrf_802154_trx_ppi.c:207: undefined reference to `mpsl_fem_abort_extend'
collect2: error: ld returned 1 exit status
%
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: /usr/bin/cmake --build /home/ztest/zephyrproject/zephyr/build

Environment (please complete the following information):

OS: Linux Ubuntu 18.04.4 LTS
Toolchain Zephyr SDK 0.11.4
modules/hal/nordic/ commit id: b94fe9280c5a0d0dbd4e4aa214f3c6daea24a78f

This is already fixed on master.

authors: rlubos s-kelvin


text:
tests: sockets: tcp: add a tls test

Is your enhancement proposal related to a problem? Please describe.
Currently I'm attempting to use mbedTLS in a custom application and am creating a test to verify TLS in CI. The test is multi-threaded and uses TCP sockets with the TLS extensions; the server server socket is managed by one thread and the client socket is managed by the main thread.
My reference(s) for the application were the echo_server / echo_client sample applications and I'm just using the certificates / keys from those sample applications as-is. However, I'm experiencing a handshake error in TLS.
Describe the solution you'd like
It might be useful to have it a test that verified this kind of functionality in Zephyr CI
Describe alternatives you've considered
Have looked around for existing tests that exercise this particular setup, but have found none.
Additional context

I used this patch to get a bit more detail from mbedTLS
tls-debug.patch.txt


text:
Bluetooth: bt_conn_foreach() reports unstable conn ref before the connection is completed

Describe the bug
Calling bt_conn_foreach() in a loop to loop over active connection doesn't grantee that reported connection reference is usable.
bt_conn_foreach() reports unstable connection reference before reporting that connection reference by the 'connected' callback.
To Reproduce
Steps to reproduce the behavior:

Checkout this commit 364267a7037abc2bad840f5e1bc20c35827c85f2
Run ~/zephyrproject/zephyr/tests/bluetooth/bsim_bt/bsim_test_conn_stress/tests_scripts/conn_stress.sh

Expected behavior
Please find the execution log
d_01: @00:00:00.114719  [Peripheral] : Updated MTU: TX: 23 RX: 23 bytes
d_01: @00:00:00.114719  [Peripheral] : Connection 0x80d1f40 established : 60:5D:FC:C7:1A:F4 (random)
d_00: @00:00:00.114716  [Central] : Updated MTU: TX: 23 RX: 23 bytes
d_00: @00:00:00.114716  [Central] : Connection 0x80d1f40 established : 7A:7C:28:1F:71:40 (random)
d_00: @00:00:00.114716  [Central] : Active connections count : 1
d_00: @00:00:00.114716  [Central] : Connection reference store index 0
d_00: @00:00:00.115924  [Central] : Security level for connection 0x80d1f40 with peer 7A:7C:28:1F:71:40 (random) is set to : 2
d_00: @00:00:00.119751  [Central] : Scanning successfully started
d_00: @00:00:00.422994  [Central] : ------------------------------------------------------
d_00: @00:00:00.422994  [Central] : [DEVICE]: 68:11:15:89:AB:56 (random), AD evt type 0, AD data len 3, RSSI -35
d_00: @00:00:00.422994  [Central] : ------------------------------------------------------
d_00: @00:00:00.423750  [Central] : ------------------------------------------------------
d_00: @00:00:00.423750  [Central] : [DEVICE]: 68:11:15:89:AB:56 (random), AD evt type 4, AD data len 19, RSSI -35
d_00: @00:00:00.423750  [Central] : ------------------------------------------------------
d_00: @00:00:00.423750  [Central] : Device name : Zephyr Peripheral
d_00: @00:00:00.423751  [Central] : Scanning successfully stopped
d_00: @00:00:00.423751  [Central] : Connecting to 68:11:15:89:AB:56 (random)
d_00: @00:00:00.439087  [Central] get_conn_info_ref:84 : Couldn't find a reference for conn 0x80d1ff8
d_00: @00:00:00.459046  [Central] get_conn_info_ref:84 : Couldn't find a reference for conn 0x80d1ff8
d_00: @00:00:00.479004  [Central] get_conn_info_ref:84 : Couldn't find a reference for conn 0x80d1ff8
d_00: @00:00:00.498963  [Central] get_conn_info_ref:84 : Couldn't find a reference for conn 0x80d1ff8
d_00: @00:00:00.518921  [Central] get_conn_info_ref:84 : Couldn't find a reference for conn 0x80d1ff8
d_02: @00:00:00.531314  [Peripheral] : Updated MTU: TX: 23 RX: 23 bytes
d_02: @00:00:00.531314  [Peripheral] : Connection 0x80d1f40 established : 60:5D:FC:C7:1A:F4 (random)
d_00: @00:00:00.531311  [Central] : Updated MTU: TX: 23 RX: 23 bytes
d_00: @00:00:00.531311  [Central] : Connection 0x80d1ff8 established : 68:11:15:89:AB:56 (random)
d_00: @00:00:00.531311  [Central] : Active connections count : 2
d_00: @00:00:00.531311  [Central] : Connection reference store index 1
d_00: @00:00:00.532519  [Central] : Security level for connection 0x80d1ff8 with peer 68:11:15:89:AB:56 (random) is set to : 2
d_01: @00:00:00.766047  [Peripheral] : Security for 0x80d1f40 changed: 60:5D:FC:C7:1A:F4 (random) level 2
d_01: @00:00:00.778382  [Peripheral] : Discovering peer 60:5D:FC:C7:1A:F4 (random) primary service
d_00: @00:00:00.816240  [Central] : Security for conn (0) @ 0x80d1f40 changed: 7A:7C:28:1F:71:40 (random) level 2
d_00: @00:00:00.818299  [Central] : Discovering peer 7A:7C:28:1F:71:40 (random) primary service
d_00: @00:00:00.966371  [Central] : Primary Service Found
d_01: @00:00:01.016078  [Peripheral] : Primary Service Found
d_01: @00:00:01.066149  [Peripheral] : Service Characteristic Found
d_00: @00:00:01.066467  [Central] : Service Characteristic Found
d_02: @00:00:01.067218  [Peripheral] : Security for 0x80d1f40 changed: 60:5D:FC:C7:1A:F4 (random) level 2
d_02: @00:00:01.077759  [Peripheral] : Discovering peer 60:5D:FC:C7:1A:F4 (random) primary service
d_00: @00:00:01.117412  [Central] : Security for conn (1) @ 0x80d1ff8 changed: 68:11:15:89:AB:56 (random) level 2
d_00: @00:00:01.117676  [Central] : Discovering peer 68:11:15:89:AB:56 (random) primary service
d_01: @00:00:01.166082  [Peripheral] : [SUBSCRIBED] addr DE:CD:A2:21:EE:22 (random)
d_00: @00:00:01.166332  [Central] : [SUBSCRIBED] addr CB:04:A6:15:1F:50 (random) conn 0
d_00: @00:00:01.218121  [Central] : Primary Service Found
d_02: @00:00:01.267249  [Peripheral] : Primary Service Found
d_02: @00:00:01.317321  [Peripheral] : Service Characteristic Found
d_00: @00:00:01.317640  [Central] : Service Characteristic Found
d_02: @00:00:01.417253  [Peripheral] : [SUBSCRIBED] addr DE:CD:A2:21:EE:22 (random)
d_00: @00:00:01.417504  [Central] : [SUBSCRIBED] addr DD:D1:7D:F0:5F:33 (random) conn 1

Connection reference was reported by bt_conn_foreach()
d_00: @00:00:00.439087  [Central] get_conn_info_ref:84 : Couldn't find a reference for conn 0x80d1ff8
d_00: @00:00:00.459046  [Central] get_conn_info_ref:84 : Couldn't find a reference for conn 0x80d1ff8
d_00: @00:00:00.479004  [Central] get_conn_info_ref:84 : Couldn't find a reference for conn 0x80d1ff8
d_00: @00:00:00.498963  [Central] get_conn_info_ref:84 : Couldn't find a reference for conn 0x80d1ff8
d_00: @00:00:00.518921  [Central] get_conn_info_ref:84 : Couldn't find a reference for conn 0x80d1ff8

before being reported by the connected callback
d_00: @00:00:00.531311  [Central] : Connection 0x80d1ff8 established : 68:11:15:89:AB:56 (random)

bt_conn_foerach() ensures that there's a valid reference before calling the callback, and then releases the reference after the callback. So I doubt the issue is with bt_conn_foreach(). @ahmedmoheb-nordic could you study the code a bit further to figure out where the issue is? (it could also be in the test app)

Closing as duplicate of https://github.com/zephyrproject-rtos/zephyr/issues/53996

authors: ahmedmoheb-nordic carlescufi jhedberg


text:
dns resolve: fails after 60 seconds uptime

Describe the bug
I'm running an HTTP client application on STM32L4A6 Nucleo board + ENC28J60 module.
After few minutes, the DNS resolve fails to query addresses. I have observed this in my application but also in the console just doing net dns query google.fr plenty of time up to the first failure, which occurs after few minutes only after starting the application.
In my application getaddrinfo function returns error code -101.
My prj.conf particularly contains:
CONFIG_DNS_RESOLVER=y
CONFIG_DNS_RESOLVER_LOG_LEVEL_DBG=y

To Reproduce
Steps to reproduce the behavior:

On nucleo_l4a6 + enc28j60 build a projet with Ethernet support
in the console type net dns query google.fr

Expected behavior
DNS resolution working.
Impact
Blocking the development.
Logs and console output
In the console and after activating debug logs I see it is because of timeout:
[00:01:08.776,000] <dbg> net_dns_resolve: dns_resolve_name: (): DNS id will be 34471
[00:01:08.776,000] <dbg> net_dns_resolve: dns_write: (): [0] submitting work to server idx 0 for id 34471 hash 24745
[00:01:10.776,000] <dbg> net_dns_resolve: query_timeout: (sysworkq): Query timeout DNS req 34471 type 1 hash 24745
[00:01:10.776,000] <dbg> net_dns_resolve: dns_resolve_cancel_with_hash: (sysworkq): Cancelling DNS req 34471 (name my-server.com type 1 hash 24745)

Environment (please complete the following information):

OS: Linux
Toolchain: Zephyr SDK
I'm actually at zephyr commit ID e9a59518fcbd54f2ee27ea3f190a8fe7bd688f35 (v3.3.0-rc1 tag).

Additional context
DHCPv4 activated, no IPv6.
IP address is provided by the local router. DNS is provided at the same time, it's the local router (192.168.1.1) and the command net dns properly show the DNS address before and after the issue occurs.
Before the issue occur it is possible to do some ping in the console. After the issue occurs pings in the console fails with timeout.
The same application has been executed on stm32f746g_disco board (RMII Ethernet PHY) with no issues => the problem comes from ENC28J60 support.
Thanks for any support,
Joel

Hi @joelguittet,
Can you describe you network configuration please? (DHCP/IP static adress/DNS entries..)

Hello @RomainPelletant
Sure. I have DHCPv4 activated; no static IP addres. DNS server is the local router (properly shown in the shell) at 192.168.1.1.
Information added in the post above.
I just ran the dns_resolve sample on an other board (with no enc28j60 so te config is much different). It's properly working.
In the dns_resolve sample I notice there is a specific configuration as follow:
# Enable the DNS resolver
CONFIG_DNS_RESOLVER=y
# Enable additional buffers
CONFIG_DNS_RESOLVER_ADDITIONAL_BUF_CTR=5
# Enable additional queries
CONFIG_DNS_RESOLVER_ADDITIONAL_QUERIES=2
# Enable mDNS support
CONFIG_MDNS_RESOLVER=y
# Enable LLMNR support
CONFIG_LLMNR_RESOLVER=n

CONFIG_DNS_RESOLVER_MAX_SERVERS=2
CONFIG_DNS_SERVER_IP_ADDRESSES=y
CONFIG_DNS_NUM_CONCUR_QUERIES=5

But the documentation at https://docs.zephyrproject.org/latest/connectivity/networking/api/dns_resolve.html do not really explains the details of the CONFIG. Just to check the KConfig which is not enough I think.
I should maybe play with these settings, right ?
Regards,

If I am not wrong, DHCP shall add the right DNS entry (in your case 192.168.1.1).
To know where is the problem, you could add fix DNS entry like the following
CONFIG_DNS_SERVER_IP_ADDRESSES=y
CONFIG_DNS_SERVER1="192.168.1.1"
CONFIG_DNS_SERVER2="8.8.8.8"

Using the IP directly is working?

Seems this help, but after a quick moment, then I'm no more able to query DNS resolution. Using the shell, timeout or -11 error is reported. I will try to use some configuration settings from the dns_resolve sample.

Using configuration of the DNS from dns_resolve sample I got the same result: DNS resolution working at the beginning, but failing after few minutes.
Maybe it's due to enc28j60 driver ? Don't know how to determine this :-(

I'd check if the DNS server address does not get corrupted somehow (you can list configured servers with net dns).
Otherwise, if it's a driver issue, I'm not really of much use as I don't have experience with that particular one. Are you able to send any other packets when DNS starts to malfunction (for example with net udp command)?

Hello
net dns still show the DNS address after the issue occurs.
I have checked if something else can be done using the net ping 8.8.8.8 in the console. Before the issue occurs it's working. After the issue occurs I get "Ping timeout" error.
Note: When I opened the ticket the issue occurred 1 minute after uptime. But it seems to be generally 3 or 4 minutes after uptime.
It seems the issue is related to the ENC28J60 driver but it's strange I'm the first to report it. Isn't it ? Or maybe it is not used a lot ? I should receive an ESP01 module soon, I will check with this module if I get the error with my hardware and my application, this will confirm (or not) if this is due to enc28j60 driver.
Joel

Hello
I have build and ran my application on stm32f746g_disco board, which has RMII LAN8742A Ethernet PHY without any issue. The difference is only the Ethernet PHY. The configuration used was the same (DHCPv4, dynamic DNS address...)
We can conclude this is an issue with the ENC28J60 driver. I'm updating the first post of this thread to indicate this.
Joel

We can conclude this is an issue with the ENC28J60 driver. I'm updating the first post of this thread to indicate this.

Unfortunately this driver is currently unmaintained, so we need a volunteer to step up and provide a fix. Unassigning @rlubos since he is the maintainer of the networking stack and not individual drivers.

@carlescufi no problem I understand this. Will try W5500 and ESP01 as a replacement for my project. I'm not enough experienced with zephyr to start this kind of deep debugging on the networking parts :-)

@joelguittet FYI i am using eth_enc424j600 without any DNS issues

Thanks @RomainPelletant I just received this afternoon a W5500 module. Wired, reconfigured in the dts. Working. No modification of the app again. This is a double confirmation enc28j60 has issues.

I briefly tested it on nRF52840DK today. I used zperf sample (net ping 2001:db8::affe -c 1000 -i 10 -s 1000) and see MPU FAULT  <err> eth_enc28j60: Failed to read memory somewhere in buf_simple. And this reminds me of a weird bug that seemed to be a controller RX FIFO overflow that I fought in this driver few years ago, I finally gave up and implemented enc424j600 driver. If anyone wants to spend time on this, please reassign.

Hello
Working with W5500 interface since several months now I realize I now get some issues (my application is growing...)
And the reason is pretty simple and it was probably the root cause of the ENC28J60 issue here : this kind of chip offload the sockets but it's not integrated in Zephyr using offloading possibilities (see for example eswifi of winc1500 drivers in Zephyr).
As a consequence only a single socket can be used at a time.
Driver to be reworked to permit offloading the sockets instead of just using the first socket in a raw-access mode.
Joel

Working with W5500 interface since several months now I realize I now get some issues (my application is growing...)
And the reason is pretty simple and it was probably the root cause of the ENC28J60 issue here : this kind of chip offload the sockets but it's not integrated in Zephyr using offloading possibilities (see for example eswifi of winc1500 drivers in Zephyr).

This is ingenious causal inference.

@jfischer-no are you planning to work on this? (it's getting the Stale label auto-added)

@jfischer-no are you planning to work on this? (it's getting the Stale label auto-added)

https://github.com/zephyrproject-rtos/zephyr/issues/54199#issuecomment-1506944544
I do not think it is worth it.

@jfischer-no are you planning to work on this? (it's getting the Stale label auto-added)

#54199 (comment) I do not think it is worth it.

Ok, let’s close this then

authors: RomainPelletant carlescufi jfischer-no jhedberg joelguittet rlubos


text:
Bluetooth: Host: ATT: Expose ATT header sizes / Enable truncated notification support

Is your enhancement proposal related to a problem? Please describe.
If a notification is larger than the current GATT MTU, then an application/service may truncate the notification. However, it order to determine the maximum size of the truncated notification size, it needs to subtract 3 bytes from the MTU to account for the ATT notification header:

Not only is this not obvious from the ATT/GATT API for sending notifications, but the size of the header only exist in an internal header file, so any application wishing to do this will need to define the size itself: https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/bluetooth/audio/ascs.c#L152-L174
Describe the solution you'd like
The size of the ATT requests should be in a public API, so that an application can reliably use the public API to properly truncate notifications.
Describe alternatives you've considered
Alternatively we can add a truncate field in struct bt_gatt_notify_params so that the GATT layer will truncate the notification for the application. The downside of this is that the application won't know if the notification was truncated or not.
Additional context
With EATT it becomes even more difficult, as the enchanced ATT (EATT) bearers and unhanced ATT bearer may have different MTUs, and the application won't know which bearer is used by GATT.

Bluetooth WG (2024-04-18)

@alwa-nordic we can split this in two issues:

add the public definitions (and documentation)
fix EATT by a new API (see https://github.com/zephyrproject-rtos/zephyr/issues/64172)

authors: Thalley theob-pro


text:
git.cmake: let the environment override BUILD_VERSION

This is needed to remove noise when comparing binaries across git
commits and more generally for anyone who wants to manual
control/override the version number when building with or without a
.git/ subdirectory.
Signed-off-by: Marc Herbert marc.herbert@intel.com

Codecov Report

Merging #14594 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #14594   +/-   ##
=======================================
  Coverage   51.96%   51.96%
=======================================
  Files         309      309
  Lines       45576    45576
  Branches    10554    10554
=======================================
  Hits        23683    23683
  Misses      17083    17083
  Partials     4810     4810

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 100287d...df3b2f8. Read the comment docs.

source: gharchive/pull-request

authors: codecov-io marc-hb


text:
Introduce integration testing

his adds a new option, integration which is used to list platforms to use in integration testing (CI) and avoids whitelisting platforms. This will enable running those tests on real hardware if the --integration option is omitted.
--integration option is now not default, in the future this will be the default and will build/test a minimal set, running sanitycheck with more coverage will be possible use another option.
oh, one more thing in this PR: use native_posix exclusively where it makes sense and avoid massive build/running trivial stuff that is being tested elsewhere anyways..

I wish we had a better name than integration

Interestingly, the most common term of art in the industry for this kind of simplest-possible-but-still-comprehensive test to check for obvious bugs before merge is a "sanity check".  Though I'm reliably told that in the modern world that language is frowned on as not particularly inclusive.
Seriously, I've been staying out of this one for obvious reasons but it all looks good to me.

Interestingly, the most common term of art in the industry for this kind of simplest-possible-but-still-comprehensive test to check for obvious bugs before merge is a "sanity check". Though I'm reliably told that in the modern world that language is frowned on as not particularly inclusive.
Seriously, I've been staying out of this one for obvious reasons but it all looks good to me.

I wasnt thinking of it in those terms, just that integration didn't spring to mind the meaning of build/run this test for CI purposes.

I wasnt thinking of it in those terms, just that integration didn't spring to mind the meaning of build/run this test for CI purposes.

We have platform_whitelist to list the platforms that are supported by a test/sample, I think something like ci_whitelist would be more intuitive.

Some ideas for the name (I tried to avoid uninclusive language).
CI_smoketest, CI_BVT (build verification test), CI_verification, CI_smokelist, CI_scope. The CI prefix is optional, however, I think using it clearly shows the purpose of the list.

I wish we had a better name than integration, best I can come up with is ci.

what is the i in ci? :)

what is the i in ci? :)

I know :)

I wish we had a better name than integration, best I can come up with is ci.

what is the i in ci? :)

I have no problem with the name, the only thing I can think against is that this may bring some confusion with unit and integration tests, that in this cases refers to tests different components integration.

This option is not a replacement for platform_whitelist right ? In this case why platform_whitelist as removed in some commits ?

This option is not a replacement for platform_whitelist right ? In this case why platform_whitelist as removed in some commits ?

I believe the reason for this PR is the fact that whitelisting became an issue blocking proper on-target testing. If a whitelist exists it prevents the test from being run on any other platform, which is especially a problem in the context of test on the physical boards. Whitelisting ended up as a simple way to provide minimum test coverage (e.g. one writes a test based on a platform on his/her desk and adds the platform to the whitelist, which prevents the test from being run on any other platform) and also a list to minimize the scope of the CI testing to a limited subset of platforms. I believe the trend is to depreciate whitelisting and decouple 2 issues: the scope for the CI tests is given by the 'integration' list and the filtering of the tests runnability on a given platform will be based on dts compatibility.

Also not a fan of integration but cannot come up with something better either. Perhaps ci would be shorter and easier to understand?
Also, this closes #25104 right @nashif?

Also not a fan of integration but cannot come up with something better either. Perhaps ci would be shorter and easier to understand?

Again, ci is 'continuous integration', this is 'integration', so not sure what the issue is here.. This can also be run out of CI if someone wants a faster run locally, so it is not limited to ci.
and yes, it fixes  #25104.

authors: PerMac andyross carlescufi ceolin galak nashif stephanosio


text:
actions: update daily version for testing

Update versions.json with the daily commit that device testing will be
performed on.

Seems like it would be nice to have a date/timestamp in the json ;).

Seems like it would be nice to have a date/timestamp in the json ;).

yes, I just do not want to break people scripts with such a change. This will come soon though.

authors: galak nashif


text:
storage/stream: elimination of usage of the flash API internals

Module was using flash driver implementation API call
page_layout() which is a part of driver implementation
interface API.
This patch re-implements this part of code using
flash_page_foreach() public API function.
fixes #27487

@hakonfam could you please review this?

@hakonfam Ok, will look on this

authors: carlescufi nvlsianpu


text:
drivers: modem: Fix PDP context management for BG9X

If the PDP context is already opened ; it returns an error.
In this case, close the context and reopens it.
Signed-off-by: Thomas LE ROUX thomas.leroux@smile.fr

ping @bwasim For some reason I cannot add you as a reviewer to these bg9x PRs, you are also not mentioned in the CODEOWNERS file (not sure if those are related)

ping @bwasim For some reason I cannot add you as a reviewer to these bg9x PRs, you are also not mentioned in the CODEOWNERS file (not sure if those are related)

Here's a modified version of the PR previously done.
I've based myself on the flowchart for the TCP/IP / UDP scenario found on the datasheet : https://www.quectel.com/UploadImage/Downlad/Quectel_BG96_TCP(IP)_AT_Commands_Manual_V1.1.pdf

If there is an issue 3 consecutive times on opening the context we restart the module.
If the AT+QICLOSE command returns an error, we restart the module aswell.

Hello everybody. I am in line with Thomas suggestion. Can you please make a quick review and let us know if it is ok for you ?
@bwasim @jukkar

Changed the commit following @mniestroj 's recommandation.
Thanks a lot for those !

Updated. Should be good now !

@mniestroj any remark on this PR ?

authors: gpaquet85 jukkar tlr-id


text:
soc: arm: stm32l4 serie low power modes in debug config

The debug config will let the clocks active in STOP mode at init.
Following the #33131, the power.c part of the stm32wb is modified in the same way.
Signed-off-by: Francois Ramu francois.ramu@st.com

plus a comment in the commit msg for the minor fix in the Kconfig

rebase and change the substate range

rebase
changed info.substate_id in the pm_power_state_exit_post_ops function


text:
samples: tfm_integration: Enable psa_level_1 on stm32l562e_dk

Force TFM_ISOLATION_LEVEL and reuse memory mapping from tfm_ipc

^^ @yestin


text:
soc: riscv: priv: call __reset during boot

Call __reset instead of directly calling __initialize from the common RISC-V privileged SoC vectors __start. This allows injection of SoC specific reset code just after setting up the machine trap vector.
RISC-V privilege SoCs without the need for custom reset code can set CONFIG_INCLUDE_RESET_VECTOR=y to include a __reset stub which simply calls __initialize.
Fixes: #38396
Signed-off-by: Henrik Brix Andersen henrik@brixandersen.dk

I have tested the two QEMU boards with these changes, but I do not have access to the other affected hardware. I have verified the listings (zephyr.lst) output manually for all affected SoCs, though.
If anybody can provide further testing and verification on hardware that would be much appreciated.

The issue of leaving out __reset in the common boot code is a show stopper for an as of yet out-of-tree SoC port.

I should be able to test using beaglev_starlight_jh7100.
Actually, just reading the docs, I didn't realize an external script was necessary for modifying the .bin prior to flashing. Seems like something that should be in tree. Will file an issue.

I've tested these changes on litex-vexriscv board. The change in this SoC's Kconfig doesn't seem to have any negative impact.

I'll check on HiFive1 and HiFive Unmatched, please give me a moment.

It works correctly on HiFive1 rev.B and HiFive Unmatched.

beaglev_starlight_jh7100 was ok

authors: cfriedt fkokosinski henrikbrixandersen katsuster


text:
ARM: Introduce Infineon PSoC 6 SoC

This introduce an Infineon PSoC 6 SoC (https://github.com/zephyrproject-rtos/zephyr/issues/42883).
This is a first MR which include following part:

Infineon PSoC 6 SOC Devicetree
Infineon CAT1/PSoC 6 SOC integration
CAT1 UART driver / binding for uart
CAT1 GPIO driver / binding for gpio
CAT1 Pin controller driver / binding for pinctrl

The next PRs will include Counter driver, CYW42XXX BT HCI extension driver, CYW42XXX wifi driver, etc.
PSoC 6 Integration structure:

This PR has addressed comments from previous draft: https://github.com/zephyrproject-rtos/zephyr/pull/42725
To decrease number of files for review the tds and soc has files only for one MPN (CY8C624ABZI_S2D44), and die family (psoc6_02):

dts: arm: Introduce Infineon PSoC 6 SOC Devicetree
soc: arm: Introduce Infineon CAT1/PSoC 6 SOC integration

Rest of MPNs, die families will be added in separate PR .

Now compliance checks is clear. We have one warning, which is expected:
197cce89cd4a6ea3740ddc37f0edb00c0747702b:158: WARNING:NEW_TYPEDEFS: do not add new typedefs
#158: FILE: soc/arm/infineon_cat1/common/pinctrl_soc.h:48:
+typedef struct {

pinctrl requires to have typedef for pinctrl_soc_pin_t

Added clock control driver and Infineon CY8CPROTO-062-4343W board. This is all content for this PR.

@nandojve @gmarull @MaureenHelm @henrikbrixandersen reviews appreciated.

design and implement the west extension that the TSC voted must be created to manage binary blobs
use the process defined in the document associated with that vote to propose the blobs be added
work with espressif to migrate the existing blobs we've hacked in with an SoC-specific west extension to the generic solution

Before we can move on to the points described by @mbolivar-nordic above, we need to:

Transfer the contents of the working document to the official Zephyr doc
Define the process by which binary blobs are accepted by the TSC. I suggest expanding the external components section.

If you'd like we can collaborate on this @npal-cy. I could work on the docs and you could start drafting the west extension?

@carlescufi , @gmarull , @mbolivar-nordic thanks for comments. I will try address it as soon as possible..

Codecov Report

Merging #44211 (b9e8333) into main (4cc5c56) will increase coverage by 0.03%.
The diff coverage is n/a.

:exclamation: Current head b9e8333 differs from pull request most recent head a745fbb. Consider uploading reports for the commit a745fbb to get more accurate results

@@            Coverage Diff             @@
##             main   #44211      +/-   ##
==========================================
+ Coverage   49.98%   50.01%   +0.03%
==========================================
  Files         648      650       +2
  Lines       81236    82238    +1002
  Branches    19083    19303     +220
==========================================
+ Hits        40603    41130     +527
- Misses      33902    34393     +491
+ Partials     6731     6715      -16

Impacted Files
Coverage Δ

arch/posix/core/irq.c
86.66% <ø> (ø)

arch/posix/core/posix_core.c
100.00% <ø> (ø)

arch/posix/core/swap.c
100.00% <ø> (ø)

arch/posix/include/posix_arch_internal.h
100.00% <ø> (ø)

arch/x86/core/early_serial.c
70.83% <ø> (ø)

boards/posix/native_posix/cmdline.c
59.18% <ø> (ø)

boards/posix/native_posix/irq_ctrl.c
76.23% <ø> (ø)

boards/posix/native_posix/irq_handler.c
88.88% <ø> (ø)

include/zephyr/cache.h
0.00% <0.00%> (-100.00%)
:arrow_down:

include/zephyr/net/ieee802154_radio.h
0.00% <0.00%> (-100.00%)
:arrow_down:

... and 107 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4cc5c56...a745fbb. Read the comment docs.

@nandojve,
I do not know why i can't add answer under your comments. I got error "Could not resolve to a node with the global id of 'MDE3OlB1bGxSZXF1ZXN0UmV2aWV3'."...
regarding to https://github.com/zephyrproject-rtos/zephyr/pull/44211#discussion_r895001593
Yes, this is a blocking call which waits till the character is sent to UART FIFO. If the buffer is full it will for free place in FIFO.

@nandojve
regarding to https://github.com/zephyrproject-rtos/zephyr/pull/44211#discussion_r895002732
Peripheral-id used to select proper uart block from dts

@carlescufi
regarding to https://github.com/zephyrproject-rtos/zephyr/pull/44211#discussion_r893606892
Per DS, it is correct to have 13 i2c instances, 9 spi instances and 12 UARTs, as in current dts psoc6_02.dtsi file.
https://www.infineon.com/dgdl/Infineon-PSOC_6_MCU_CY8C62X8_CY8C62XA-DataSheet-v17_00-EN.pdf?fileId=8ac78c8c7d0d8da4017d0ee7d03a70b1

@nandojve regarding to #44211 (comment) Peripheral-id used to select proper uart block from dts

For this  function you must use clocks property.

For this function you must use clocks property.
in dts/arm/infineon/psoc6/psoc6_02/psoc6_02.dtsi, we use peripheral-id to define block number

		uart0: uart@40600000 {
			compatible = "infineon,mtbhal-uart";
			reg = <0x40600000 0x10000>;
			interrupts = <39 6>;
			peripheral-id = <0>;
			status = "disabled";
			label = "uart_0";
		};
		uart1: uart@40610000 {
			compatible = "infineon,mtbhal-uart";
			reg = <0x40610000 0x10000>;
			interrupts = <40 6>;
			peripheral-id = <1>;
			status = "disabled";
			label = "uart_1";
		};
		uart2: uart@40620000 {
			compatible = "infineon,mtbhal-uart";
			reg = <0x40620000 0x10000>;
			interrupts = <41 6>;
			peripheral-id = <2>;
			status = "disabled";
			label = "uart_2";
		};
...

driver drivers/serial/uart_ifx_cat1.c use this block_num during initialization in ifx_cat1_uart_init function.
info stores in config structure from INFINEON_CAT1_UART_INIT macro:
#define INFINEON_CAT1_UART_INIT(n)
...
     hw_resource = {					     \
	.type = CYHAL_RSC_SCB,			     \
	.block_num = DT_INST_PROP(n, peripheral_id), \
	}

Also, the new bindings need different compatibles to match the HW not HAL.

hi @galak,
we include 'mtbhal' in binding name (e.g infineon,mtbhal-uart.yaml), it means that all our our socs, which supports be our mtbhal will use the same bindings/drivers. For now, in this PR we integrating PSOC6, but we expect reuse same bindings/drivers for our new family of socs.
Do you see problem here?

hi @galak, we include 'mtbhal' in binding name (e.g infineon,mtbhal-uart.yaml), it means that all our socs, which supports by our mtbhal will use the same bindings/drivers. For now, in this PR we integrating PSOC6, but we expect reuse same bindings/drivers for our new family of socs.
Do you see problem here?

The devicetree compatibles should describe the hardware as if no HAL ever existed.  Its fine for the driver to utilize the HAL and support multiple different compatibles, but the devicetree itself should use compatibles that are descriptive of the hardware.

hi @galak, we include 'mtbhal' in binding name (e.g infineon,mtbhal-uart.yaml), it means that all our socs, which supports by our mtbhal will use the same bindings/drivers. For now, in this PR we integrating PSOC6, but we expect reuse same bindings/drivers for our new family of socs.
Do you see problem here?

The devicetree compatibles should describe the hardware as if no HAL ever existed. Its fine for the driver to utilize the HAL and support multiple different compatibles, but the devicetree itself should use compatibles that are descriptive of the hardware.

ok, we will rename form “Infineon, mtbhal-xxxx.." to “Infineon, cat1-xxxx.."

@npal-cy : any plan to finish this and getting it merged?

@jsiverskog, we are working on the required binary acquisition that is blocking this PR. There is quite a bit of review/comments here and so ideally, we would keep the PR open. Our goal is to have this PR ready by end of the month.
Thanks,
Ian

Infineon will be updating this PR during the next two weeks and will ask for re-review when ready.

Hi @carlescufi
We added blobs support in https://github.com/zephyrproject-rtos/zephyr/pull/44211/commits/64c2ed0ee5f31e31413b7bde7ecf90a7b814d7d6. It has dependency on hal_infineon repo updates.
All Twister build test are failed with cy8cproto_062_4343w board.
https://github.com/zephyrproject-rtos/zephyr/actions/runs/4054950354/jobs/6977556794
ninja: error:

'/__w/zephyr/modules/hal/infineon/zephyr/blobs/img/cat1cm0p/COMPONENT_CM0P_SLEEP/psoc6_02_cm0p_sleep.bin', needed by 'zephyr/include/generated/psoc6_cm0p_sleep.bin.inc', missing and no known rule to make it

Do we have any defined way to enable west blobs fetch for this board?
Regards,
Nazar

Hi @npal-cy

Do we have any defined way to enable west blobs fetch for this board for Twister test?

I'm afraid not. The TSC voted explicitly against enabling CI testing for components that require blobs.

hi @mbolivar-nordic,
Do you have any suggestion how we can enable Twister for cy8cproto_062_4343w board? as i am understanding with current status of CI this MR is blocked.
Thanks,
Nazar

Do you have any suggestion how we can enable Twister for cy8cproto_062_4343w board? as i am understanding with current status of CI this MR is blocked.

From memory, the short version of the deal that the project made with
contributors who want to submit things that require binary blobs
upstream is:

the contributions won't get any CI testing
it's the contributor's responsibility to test and ensure things work

I haven't looked at the PR's current status, but I would guess there
should be some way to limit twister from exercising your files to abide
by this deal. You'd have to take it up with the twister maintainers if
it's not clear from the twister documentation what that way is.

hi @mbolivar-nordic , thanks for your suggestion.
From Twister documentation i see only one option to use 'platform_exclude', but it is not suitable for us, because:

we want that our platform build (to catch any regression)
to use 'platform_exclude' need to update all projects in Zephyr tree.

One option which i see here:  I'll update my blobs integration modules\hal_infineon\cat1cm0p\CMakeLists.txt to include CM0+ image sources (psoc6_cm0p_sleep.c) only if we found binary file and could generate binaries file include (by using generate_inc_file_for_target). If we can't find binary file Cmake generates warning "Can't find CM0+ binaries, please execute: 'west blobs fetch hal_infineon'
It gives us possibility to have successful build in Twister even if west blobs fetch was not executed. From user protective:

In  board documentation we have instruction about Fetch Binary Blobs.
in build log cmake will generate Warning "Can't find CM0+ binaries, please execute: 'west blobs fetch hal_infineon'"

Hi @carlescufi, @gmarul, @nandojve, @mbolivar-nordic, @galak,
All comments are addressed, CI pass. Please do final review.
Thanks and Regards,
Nazar

Hi @npal-cy ,
I would like to ask you to remove my reference on CODEOWNERS and collaboration on MAINTAINERS file related to CY.
This means that after this PR got merged I should not be included anymore to participate on this architecture.
BR,
Gerson

Hi @npal-cy ,
I would like to ask you to remove my reference on CODEOWNERS and collaboration on MAINTAINERS file related to CY. This means that after this PR got merged I should not be included anymore to participate on this architecture.
BR, Gerson

Hi Gerson,
Done. Please double check https://github.com/zephyrproject-rtos/zephyr/pull/44211/commits/ed2ec5b1ea448cc5369d7c5388f12c0d6fbf6c02.
Regards,
Nazar

Hi @npal-cy ,
I would like to ask you to remove my reference on CODEOWNERS and collaboration on MAINTAINERS file related to CY. This means that after this PR got merged I should not be included anymore to participate on this architecture.
BR, Gerson

Hi Gerson,
Done. Please double check ed2ec5b.
Regards, Nazar

You should a PR then I can review.

Hi Gerson,
The changes was done in those two commits:
CODEOWNERS: Update codeowners for Infineon/Cypress sources
MAINTAINERS.yml: Update maintainers for Cypress sources
Thanks,
Nazar

I would suggest pulling out the CODEOWNER/MAINTAINERS.yml change into a separate PR.
sorry i missed "PR", i pulled out to different commits.  Let me change this.

@gmarull @mbolivar-nordic @galak please take another look

Hi @mniestroj and @galak,
Thanks for new portion of comments. I addressed them please review.
Regards,
Nazar

Updated RAM/ROM size implementation for CM0p images.
PSOC6/CAT1 stop works after commit 44628735, where was updated rom_start_offset(add to address instead of set.)
The following updates was done to handled  44628735 changes:

added own hidden SOC_PSOC6_CM0P_IMAGE_ROM/RAM_SIZE kconfig object to handle RAM/ROM size for PSOC6 CM0P images.
replaced ROM_START_OFFSET to SOC_PSOC6_CM0P_IMAGE_ROM_SIZE in soc/arm/infineon_cat1/psoc6/Kconfig.defconfig
replaced SRAM_OFFSET to SOC_PSOC6_CM0_IMAGE_RAM_SIZE in soc/arm/infineon_cat1/psoc6/Kconfig.defconfig
updated soc/arm/infineon_cat1/psoc6/rom_cm0image.ld and /soc/arm/infineon_cat1/psoc6/ram_cm0image.ld to use CONFIG_SOC_PSOC6_CM0P_IMAGE_ROM/RAM_SIZE

rebased commit: https://github.com/zephyrproject-rtos/zephyr/pull/44211/commits/fca19c19a0fb3e62facc936b2c4c1bf9cba99912

The Compliance Failures are just the usual pinctrl typedef.

authors: carlescufi codecov-commenter galak ifyall jsiverskog mbolivar-nordic nandojve npal-cy yurii2001lozyn


text:
RFC: Parse Kconfig to get driver API/feature info

The intent of this PR is to show how we can parse Kconfig data to extract driver API and feature information.  We map from devicetree compatible to Kconfig.
If we standardize on the Kconfig symbols names and pattern, we can utilize this as a means to extract info we need for things like multi-api, shell, userspace, docs, testing, etc.

Kumar, could you define 'feature' here?

Kumar, could you define 'feature' here? And clarifying the end goal of this update would help.

Feature here is meant to be defined as what capabilities a driver implements.  For something like serial drivers, this goes to what APIs are or not implemented.  So if you look at something like include/zephyr/drivers/uart.h and what CONFIG_, the set of features would be:
CONFIG_UART_ASYNC_API
CONFIG_UART_DRV_CMD
CONFIG_UART_INTERRUPT_DRIVEN
CONFIG_UART_LINE_CTRL
CONFIG_UART_WIDE_DATA

The end goal would be to provide a means that we can "query" this information for whatever needs we might have, for example we can generate docs for a board to describe what features are supported, based on its devicetree and this information.
In addition to the features, we also have the API information.  Today we don't have an easy way of associating a device with what API its supporting.  The "type" information of the api pointer isn't kept anywhere we can determine in an easy way.  There are some things we do for user space and parsing the ELF file to extract this info.  But we can easily associate a struct device with the API type.
In what format the data we extract is exposed is a TBD based on the needs at hand.
The first goal of this PR is to show the capability and discuss the idea of standardizing on conventions for use of Kconfig symbol naming for conveying API and features.

Please provide an example Kconfig file for some driver. I can't work out how the compatible property is defined in the Kconfig file.

Please provide an example Kconfig file for some driver. I can't work out how the compatible property is defined in the Kconfig file.

The compatible Kconfig properties are auto-generated (look at Kconfig/Kconfig.dts in the build dir).  All this does right now is output when you do the cmake config what API and features we can detect.
So for something like FRDM-K64F, we get:
dts compatible: "nxp,kinetis-ftfe"     Kconfig Symbol: SOC_FLASH_MCUX
api - FLASH_HAS_DRIVER_ENABLED

dts compatible: "nxp,kinetis-uart"     Kconfig Symbol: UART_MCUX
api - SERIAL_HAS_DRIVER

dts compatible: "nxp,kinetis-uart"     Kconfig Symbol: UART_MCUX
feature - SERIAL_SUPPORT_INTERRUPT

dts compatible: "nxp,kinetis-uart"     Kconfig Symbol: UART_MCUX
feature - SERIAL_SUPPORT_ASYNC

dts compatible: "nxp,kinetis-rnga"     Kconfig Symbol: ENTROPY_MCUX_RNGA
api - ENTROPY_HAS_DRIVER

For something like qemu_x86 we get:
dts compatible: "ns16550"     Kconfig Symbol: UART_NS16550
api - SERIAL_HAS_DRIVER

dts compatible: "ns16550"     Kconfig Symbol: UART_NS16550
feature - SERIAL_SUPPORT_INTERRUPT

dts compatible: "zephyr,sim-flash"     Kconfig Symbol: FLASH_SIMULATOR
api - FLASH_HAS_DRIVER_ENABLED

How would something like this look with the changes?
# Atmel SAM UART configuration options

# Copyright (c) 2017 Piotr Mienkowski
# Copyright (c) 2018 Justin Watson
# SPDX-License-Identifier: Apache-2.0

config UART_SAM
	bool "Atmel SAM MCU family UART driver"
	default y
	depends on DT_HAS_ATMEL_SAM_UART_ENABLED
	select SERIAL_HAS_DRIVER
	select SERIAL_SUPPORT_INTERRUPT
	help
	  This option enables the UARTx driver for Atmel SAM MCUs.

How would something like this look with the changes?
# Atmel SAM UART configuration options

# Copyright (c) 2017 Piotr Mienkowski
# Copyright (c) 2018 Justin Watson
# SPDX-License-Identifier: Apache-2.0

config UART_SAM
	bool "Atmel SAM MCU family UART driver"
	default y
	depends on DT_HAS_ATMEL_SAM_UART_ENABLED
	select SERIAL_HAS_DRIVER
	select SERIAL_SUPPORT_INTERRUPT
	help
	  This option enables the UARTx driver for Atmel SAM MCUs.

It would require no changes right?

So for something like sam_e70_xplained, we get:
dts compatible: "atmel,sam-flash-controller"     Kconfig Symbol: SOC_FLASH_SAM
api - FLASH_HAS_DRIVER_ENABLED

dts compatible: "atmel,sam-usart"     Kconfig Symbol: USART_SAM
api - SERIAL_HAS_DRIVER

dts compatible: "atmel,sam-usart"     Kconfig Symbol: USART_SAM
feature - SERIAL_SUPPORT_INTERRUPT

dts compatible: "atmel,sam-trng"     Kconfig Symbol: ENTROPY_SAM_RNG
api - ENTROPY_HAS_DRIVER

(No change to any Kconfig, boards, etc).

tdk_robokit1 might be a little more interesting as it has both uart and usart enabled:
dts compatible: "atmel,sam-flash-controller"     Kconfig Symbol: SOC_FLASH_SAM
api - FLASH_HAS_DRIVER_ENABLED

dts compatible: "atmel,sam-uart"     Kconfig Symbol: UART_SAM
api - SERIAL_HAS_DRIVER

dts compatible: "atmel,sam-uart"     Kconfig Symbol: UART_SAM
feature - SERIAL_SUPPORT_INTERRUPT

dts compatible: "atmel,sam-usart"     Kconfig Symbol: USART_SAM
api - SERIAL_HAS_DRIVER

dts compatible: "atmel,sam-usart"     Kconfig Symbol: USART_SAM
feature - SERIAL_SUPPORT_INTERRUPT

dts compatible: "atmel,sam-trng"     Kconfig Symbol: ENTROPY_SAM_RNG
api - ENTROPY_HAS_DRIVER

Some notes:

We should take out the SYM_TO_TYPE out of the kconfig.py script and in to one or more YAML/JSON files to allow for out-of-tree support for this feature. We can also do some validation on this files contents.apis:
    - uart:
        config: SERIAL_HAS_DRIVER
        features:
            - SERIAL_SUPPORT_INTERRUPT

We should export a dictionary of the node information data to a pickle like we do for EDTLIB to be used for downstream scripts.
We should move the devicetree/kconfig merging feature outside of the kconfig.py file to its own file.
I personally do not like the naming scheme SERIAL_HAS_DRIVER. I would prefer UART_DRIVER_API and UART_DRIVER_FEATURE_x

Also, We should add a config like DEVICE_DRIVER
config UART
    bool "uart"
    selects DEVICE_DRIVER

We could use this to validate that it has at least one API and a compatible property

One alternative to this solution is, as proposed previously, adding a device_type or api property to the bindings files. This doesn't require strict Kconfig symbols, names and patterns, and changes are isolated to the devicetree. The only feature which I find essential in this PR is associating a compatible with an API. Not sure if the "feature" is really that useful, especially if we can split up the APIs like UART for which it could be useful, into different bespoke APIs.
Unless this solution can bring way more useful features, I don't think the complexity is worth it

One alternative to this solution is, as proposed previously, adding a device_type or api property to the bindings files. This doesn't require strict Kconfig symbols, names and patterns, and changes are isolated to the devicetree. The only feature which I find essential in this PR is associating a compatible with an API. Not sure if the extracted "feature" property is really that useful, especially if we can split up the APIs like UART for which it could be useful, into different bespoke APIs.

I agree on api type in the bindings (in the yaml file so even if that's software feature being exposed, it's not strictly part of the DT which should only be about the hw, or are the yaml also under such rule?), it would be easier and more reliable to relate a compatible to an actual API.
But we may still need the features, some Kconfig options on certain drivers for can make a huge difference in behavior.
That said, @galak, could you expose exactly a few major use cases for such metadata extractions? You
Besides the informative use-case (docs and testing mostly, the shell: who would really use to know the details via the shell?), I don't see much critical use for it.
Any which way this is solved, it will require a very strict normalization of Kconfig options name in order to differentiate what is a feature and what is not (i.e. just a simple config thing such as an obscure internal timeout)

@gmarull
Adding api to bindings files is entirely appropriate according to ePAPR and Linux
The bindings file as described in ePAPR https://elinux.org/images/c/cf/Power_ePAPR_APPROVED_v1.1.pdf section 2.3.1 to 2.3.11 contains properties that are binding firmware to hardware, like "name", "model", "compatible", and the now (in some cases) deprecated "device_type". As stated on page 18, line 16 to 17: "An ePAPR-compliant device tree describes device information in a system that cannot necessarily be dynamically detected by a client program." Of which "device_type" or more aptly named, "api" falls in to. Regarding the Linux devicetree, the device_type is described here https://elinux.org/Device_Tree_Linux#device_type_property, and even further, the function which iterates through devices by said device_type property for_each_node_by_type is defined here in the Linux kernel https://github.com/torvalds/linux/blob/master/include/linux/of.h#L1343.
In summary:

The device_type / api property is in accordance with ePAPR
The device_property exists in the Linux devicetree bindings
Methods for getting device or devices by device type exists in the Linux kernel
We have a static device model, therefore we need a compile time macro for getting devices by device type.

The problems that need the API information
Some multi API models need to know the API, subsystems like shells and networking need to be able to group devices by supported API (the current solution for grouping network interfaces are a clear example of where being able to get all devices of a specific type would greatly reduce complexity) And if we want to add type safety in the future, we need to know what type of device something is to, (specifically to declare externs for it like we do for current generic devices).
In summary:

We may need it for multi API model
We could use it to greatly simplify the net_if grouping
We need it for shells to get both devices and their properties at compile time
We will need it for a type safe API model

With the simplicity of the already supported feature on Linux, and the gain we will immediately get for the shells, and may get for future uses, I see no good argument against adding the feature.
Having the feature added will retrospectively reduce complexity as we will not need to touch the kconfig system.

@galak
An additional note to the "alternative solution" comment i made earlier, we can do both if there is enough other information we can get from kconfig files, just get the API from the node as is done with the compatible.

One alternative to this solution is, as proposed previously, adding a device_type or api property to the bindings files. This doesn't require strict Kconfig symbols, names and patterns, and changes are isolated to the devicetree. The only feature which I find essential in this PR is associating a compatible with an API. Not sure if the extracted "feature" property is really that useful, especially if we can split up the APIs like UART for which it could be useful, into different bespoke APIs.

I agree on api type in the bindings (in the yaml file so even if that's software feature being exposed, it's not strictly part of the DT which should only be about the hw, or are the yaml also under such rule?), it would be easier and more reliable to relate a compatible to an actual API. But we may still need the features, some Kconfig options on certain drivers for can make a huge difference in behavior.

-1 on adding this info to bindings. Bindings are the schema of Devicetree, nothing else.

Ok, thus my question in parenthesis. I was not sure the yaml it was that tight to the dts files.

Btw, we are still missing why we need all this information. Can we come up with a problem that needs to be solved using it first?

:+1:

3. We need it for shells to get both devices and their properties at compile time

While I am not as skeptical towards the DTS device_type/api approach as I am towards the Kconfig/property files solutions, I would like to point out the distinction between "need" and "could use". The Zephyr shell is working without this feature just fine.

Devicetree is NOT the right place for this information.  I repeat that devicetree is meant to describe hardware and should be agnostic to the software it is running on.  One should be able to take a devicetree and use it with a different OS.  So encoding Zephyr specific API choices is devicetree does not make sense.

@tbursztyka @gmarull I think the main in zephyr use case is around multi-api device support.  The shell as @henrikbrixandersen mention works, but we can make it better with this information.  There is some need for sensors that having this information seems like it might be useful, but I don't quite understand the use / need there (@yperess @MaureenHelm can you chime on the sensor need).  There is some possible use with I3C and knowing the set of client devices.  Also possibly simplifying some of the userspace/syscall logic that is extracting API type information out of the ELF file.
And than there is all the information cases - docs, testing, etc.

The device_type / api property is in accordance with ePAPR

This property is deprecated (as mentioned in the paper). From DT-spec: https://github.com/devicetree-org/devicetree-specification/releases/download/v0.3/devicetree-specification-v0.3.pdf

The device_type property was used in IEEE 1275 to describe the device’s FCode programming model. Because DTSpec does
not have FCode, new use of the property is deprecated, and it should be included only on
cpu and memory nodes for compatibility with IEEE 1275–derived devicetrees.

Also, we should not mix device type with API type, these are different things. I could add to a sensor device_type = "sensor" but use the API I want, it doesn't have to be the Zephyr sensor API.

The point is that it and "model" exist, showing precedent for having other metadata than compatible in the bindings files, not whether or not that specific property is deprecated (which i even noted in the comment...).

The device_type / api property is in accordance with ePAPR

This property is deprecated (as mentioned in the paper). From DT-spec: https://github.com/devicetree-org/devicetree-specification/releases/download/v0.3/devicetree-specification-v0.3.pdf

The device_type property was used in IEEE 1275 to describe the device’s FCode programming model. Because DTSpec does
not have FCode, new use of the property is deprecated, and it should be included only on
cpu and memory nodes for compatibility with IEEE 1275–derived devicetrees.

Also, we should not mix device type with API type, these are different things. I could add to a sensor device_type = "sensor" but use the API I want, it doesn't have to be the Zephyr sensor API.

The point is that it and "model" exist, showing precedent for having other metadata than compatible in the bindings files, not whether or not that specific property is deprecated which i even noted in the comment... It not only exists, it is in use in Linux.

I understand the point some of those things are hold overs from true IEEE 1275 and aren't utilized anymore.  My point about encoding zephyr software choices in devicetree does not make sense and I don't support it.

@tbursztyka @gmarull I think the main in zephyr use case is around multi-api device support.

How would this PR help to solve the multi-api issue that #49374 tried to (and could, if all instances were DTS based) do?
I know there are different approach to an issue. But so far, on things related to device model, it seems to me we are piling up more code and workarounds to the existing model than actually fixing its core issues.

(...) And than there is all the information cases - docs, testing, etc.

Informational use cases are far from being critical, not sure it's worth piling up more hacks on devices just for it. At least before fixing the core issuse.

@tbursztyka @gmarull I think the main in zephyr use case is around multi-api device support.

How would this PR help to solve the multi-api issue that #49374 tried to (and could, if all instances were DTS based) do?
I know there are different approach to an issue. But so far, on things related to device model, it seems to me we are piling up more code and workarounds to the existing model than actually fixing its core issues.

This doesn't solve the multi-api issue by itself.  Its meant to demonstrate how to get the API type information associated with a devicetree compatible and driver (and thus can connect to a 'struct device').  Regardless of what solution we utilize we will have to have some means of associated and lookup the different API pointers for a "device".

(...) And than there is all the information cases - docs, testing, etc.

Informational use cases are far from being critical, not sure it's worth piling up more hacks on devices just for it. At least before fixing the core issuse.

I'm not sure what hack this is doing.  It's utilizing the existing Kconfig information we already have, and suggesting we standardize on some aspects of it.

While researching into yet another solution to the issue of device driver capabilities, I stumbled upon the following problems that we should be able to account for with these solutions.
The solution looks like this.
# The drivers kconfig symbol
driver: MODEM_GSM_PPP

# The devicetree compatibles this driver supports
compatible:
  - "quectel,bg95"
  - "quectel,bg96"
  - "simcom,sim-7080"
  - "ubloc,sara-r4"

# Which API(s) does the driver implement
api:
  - net_if

The additional solutions it provides is describing the device driver from the drivers perspective, what kconfig symbol selects the driver, which compatibles does it work with, and of course, the API. How does this PR handle one driver supporting multiple compatibles? can it?

It describes what kconfig symbol selects the driver, which compatibles it works with, and of course, the API. How does this PR handle one driver supporting multiple compatibles? can it?

Looking at the code it seems like the Kconfig MODEM_QUECTEL_BG9X is associated with quectel,bg9x.  I don't see the linkage to MODEM_GSM_PPP.  So we'd have the MODEM_QUECTEL_BG9X updated to have something like:
config MODEM_QUECTEL_BG9X
   depends on DT_HAS_QUECTEL_BG9X_ENABLED
   select NET_IF_API
    ...

It describes what kconfig symbol selects the driver, which compatibles it works with, and of course, the API. How does this PR handle one driver supporting multiple compatibles? can it?

Looking at the code it seems like the Kconfig MODEM_QUECTEL_BG9X is associated with quectel,bg9x. I don't see the linkage to MODEM_GSM_PPP. So we'd have the MODEM_QUECTEL_BG9X updated to have something like:
config MODEM_QUECTEL_BG9X
   depends on DT_HAS_QUECTEL_BG9X_ENABLED
   select NET_IF_API
    ...

The example is related to the currently existing device drivers/bindings. Can this solution solve the problem?
The modem drivers/bindings are bit messy currently, and will be updated to the example that i showed in the future. It should be possible to change which driver you use without changing the compatible.

I appreciate all the efforts on this topic, I'm sure it will be useful one way or the other. But remember, we still have no use for it. We have potential uses, so we don't really know if any of these proposals will fit. I'd go back to the original discussions and open RFCs if not in place:

We want multi-API. What are the options? Pros/Cons? Is meta-info required, or we have other alternatives?
We want better board docs. What do we want to have in a board page? Prepare a mockup that allows us to write requirements (e.g. need meta-info to do X).
...

We want better board docs. What do we want to have in a board page? Prepare a mockup that allows us to write requirements (e.g. need meta-info to do X).

I'm not familiar with how we do other doc generation for things like Kconfig or dts bindings, but in boards we tend to have a section/table like:
https://docs.zephyrproject.org/latest/boards/arm/lpcxpresso55s06/doc/index.html#supported-features
We could autogenerate that based on this information being extracted from devicetree and Kconfig.  (Thus it would always be correct and in sync).  The following commit shows how the table got updated recently to expose features on a driver level: https://github.com/zephyrproject-rtos/zephyr/commit/569ef4ce307264f1d11070bb88eaa1022c026f99

The modem drivers/bindings are bit messy currently, and will be updated to the example that i showed in the future. It should be possible to change which driver you use without changing the compatible, just by including MODEM_GSM_PPP instead of MODEM_QUECTEL_BG9X or reverse.

If we can describe the relationship in Kconfig than we can extract that information.  So its easy enough to have something like:
config MODEM_GSM_PPP
   depends on DT_HAS_COMPAT_QUECTEL_BG95_ENABLED || DT_HAS_COMPAT_QUECTEL_BG96_ENABLED || \
                        DT_HAS_COMPAT_SIMCOM_SIM_7080_ENABLED || DT_HAS_COMPAT_UBLOC_SARA_R4
   select NET_IF_API

We want multi-API. What are the options? Pros/Cons? Is meta-info required, or we have other alternatives?

We have a multi-API proposal from @bjarki-trackunit that requires meta-info (https://github.com/zephyrproject-rtos/zephyr/pull/48817).  This PR shows an alternate to using a yet another YAML file to describe devicetree compatible to driver API type association.

@galak as discussed at dev-review it'd be good to get a view of the use cases and problems to solve here, with links to the relevant issues that should have good descriptions of those.
There are already 30 comments on this issue. I'd really not have to read all of them to find the ones that have answers to basic questions like "why" and "for what" -- i.e. it'd be better for all the reviewers if you can update the PR description instead of answering inline.

@galak as discussed at dev-review it'd be good to get a view of the use cases and problems to solve here, with links to the relevant issues that should have good descriptions of those.
There are already 30 comments on this issue. I'd really not have to read all of them to find the ones that have answers to basic questions like "why" and "for what" -- i.e. it'd be better for all the reviewers if you can update the PR description instead of answering inline.

I'm going to close this PR for now since I agree, this is more about how to implement a solution to a specific problem, and not about the problems themselves.

authors: bjarki-trackunit galak gmarull henrikbrixandersen mbolivar-nordic tbursztyka yvanderv


text:
[RFC] mbedtls: Switch default MBEDTLS_CFG_FILE to config-mini-tls1_2.h

The previous default, "config-threadnet.h", is more or less arbitrary
choice made in a commit 312def2c7857 1.5 years ago. In particular,
it's not related to Thread support in Zephyr per se (there was no
such support at that time).
It doesn't make sense to have a default intended for a particular,
not widely used (yet) protocol. Instead, the default should work
out of the box with a contemporary widely deployed arrays of TLS
servers, which are HTTPS server. config-mini-tls1_2.h works with
https://google.com, and by extension, with many other servers on
the Internet.
So, have that as the default, and let applications with special
needs to override that to what they need.
Addresses: #6132
Signed-off-by: Paul Sokolovsky paul.sokolovsky@linaro.org

Codecov Report

Merging #6221 into master will decrease coverage by 3.28%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #6221      +/-   ##
==========================================
- Coverage   52.91%   49.63%   -3.29%
==========================================
  Files         414      423       +9
  Lines       40355    43781    +3426
  Branches     7807     8826    +1019
==========================================
+ Hits        21355    21729     +374
- Misses      15784    18912    +3128
+ Partials     3216     3140      -76

Impacted Files
Coverage Δ

ext/lib/crypto/mbedtls/library/ecp_curves.c
0% <0%> (-88.89%)
:arrow_down:

ext/lib/crypto/mbedtls/library/ecjpake.c
0% <0%> (-51.13%)
:arrow_down:

ext/lib/crypto/mbedtls/library/cmac.c
0% <0%> (-50.87%)
:arrow_down:

ext/lib/crypto/mbedtls/library/ecp.c
0% <0%> (-39.47%)
:arrow_down:

ext/lib/crypto/mbedtls/library/cipher_wrap.c
17.39% <0%> (-27.06%)
:arrow_down:

ext/lib/crypto/mbedtls/library/cipher.c
12.09% <0%> (-12.39%)
:arrow_down:

ext/lib/crypto/mbedtls/include/mbedtls/cipher.h
14.28% <0%> (-10.72%)
:arrow_down:

ext/lib/crypto/mbedtls/library/md_wrap.c
0% <0%> (-7.7%)
:arrow_down:

ext/lib/crypto/mbedtls/library/sha256.c
69.87% <0%> (-2.57%)
:arrow_down:

ext/lib/crypto/mbedtls/library/ccm.c
61.61% <0%> (-1.95%)
:arrow_down:

... and 28 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 91b681a...d1e9295. Read the comment docs.

@nashif : Yup, thanks for a quick approve, but this is indeed would be a kind of RFC, wouldn't like to do this behind other people's backs. And with a change like this, a few samples indeed may need to have CONFIG_MBEDTLS_CFG_FILE="config-threadnet.h" added to compensate. Will look into that, while waiting for feedback from folks. I'll be ok if this doesn't fir into 1.11 (but if it does, only better ;-) ).

Now even passes CI.

I am not sure if this qualify as an RFC, this is a PR that needs review (and comments) and I would take this for 1.11.

authors: codecov-io nashif pfalcon


text:
OCPP 1.6 native stack

Add a support for Open Charge Point Protocol(OCPP v1.6) native stack
Basic support for open charge point protocol v1.6 as native stack with
below functionality
1. Framework for ocpp stack and central system communication using RPC over
   websocket according to occp-j.
2. Core profile with basic PDU

If this PR is still a draft (as indicated by the title), you can mark it as a draft in github. Search "Still in progress?" and there is a link at top right hand side of the page.

depends on https://github.com/zephyrproject-rtos/zephyr/pull/66763

@jukkar @rlubos Thanks for your time to review. Addressed the review comments, please consider for re-review

@ssekar15 sorry for late reply, the code looks better but could you try to fix the CI issues before continuing the reviews. I feel that some of the review issues would be resolved if the CI would pass.

@ssekar15 sorry for late reply, the code looks better but could you try to fix the CI issues before continuing the reviews. I feel that some of the review issues would be resolved if the CI would pass.

@jukkar Thank you.. CI build issues are due to dependency https://github.com/zephyrproject-rtos/zephyr/pull/66763, I tried to pull one commit to check CI failure has fixed, unfortunately not. I will check on it, otherwise IMHO review shall be continued

@ssekar15 will you be able to address the pending comments?

@ssekar15 will you be able to address the pending comments?

@kartben Thank you for the review, yes I'm working on it

@ssekar15 are you planning to work on this PR?

omments re: documentation have been ad

@jukkar yes for sure... looking for json dependency PR or alternative

@ssekar15 I would suggest putting this PR In draft mode if it's not ready yet. This makes it clearer that it doesn't require attention from reviewers. Thanks!

authors: jukkar kartben ssekar15


text:
Bluetooth: Controller: Ignore bit 1 set in Initiating_PHYs

Ignore LE 2M PHY being set in Initiating_PHYs of the LE Extended Create Connection command.

@mtpr-ot @erbr-ot ... this is needed so that when Bluez supplies the Initiating_PHYs for 2M, the scanning parameter check ignores them as per spec.


text:
jwt: remove jwt_payload_len function

The function jwt_payload_len doesn't return payload length but returns used data in builder->buf
If jwt_payload_len is called after jwt_init_builder, header length will be returned
If jwt_payload_len is called after jwt_add_payload, header+payload length will be returned
If jwt_payload_len is called after jwt_sign, header+payload+sign length will be returned
So, this commit removes the function and uses strlen instead

ping @d3zd3z

I am inclined to agree that this is a fairly poorly named API. Although the code doesn't have any references to this function, other than this test, it is a public API, and we can't just remove it without going through the deprecation process. I have asked for clarification on discord, and it might be the case this doesn't need to (since it isn't documented).

authors: blemouzy d3zd3z kartben


text:
Bluetooth: Controller: Introduce EVENT_MAFS_MIN_US value

Introduce Controller dependent EVENT_MAFS_MIN_US value to use as the value when populating the aux offset between Extended Advertising primary and auxiliary channel PDUs.
This can be used as workaround for peers having difficulty receiving Extended Advertising PDUs with near 300 us MAFS values used in aux offset calculations.

As background, this is towards resolving a problem I posted in the Discord that @cvinayak was able to provide great insight into:

In theory, should there be any externally visible difference between an extended advertising set started with BT_LE_EXT_ADV_START_PARAM(0, 0) vs a set started with BT_LE_EXT_ADV_START_PARAM(0, 5) that restarts itself each time it terminates?
Attempting to connect to the first setup from my iPhone generally works on the first attempt, while the second setup results in a long list of Connection failed to establish errors.
The nRF52840 sends off the AUX_CONNECT_RSP, and then nothing happens...
I have a Wireshark trace of a "middle ground" (BT_LE_EXT_ADV_START_PARAM(0, 20)) that normally fails for a while and then eventually connects, and cannot see any difference in packets or timings between the attempts that fail and the one that eventually succeeds...
It's all very mysterious (and frustrating).  All done on Zephyr v3.7.0-rc3.

Pcap trace (change extension back to .pcapng once downloaded): weird_iphone_behaviour_pcapng.txt

authors: JordanYates cvinayak


text:
samples: xtensa_asm2: Cleanup stray IS_TEST reference

We removed IS_TEST a while ago.  Remove this stray reference
Signed-off-by: Kumar Gala kumar.gala@linaro.org

Codecov Report

Merging #7756 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #7756   +/-   ##
=======================================
  Coverage   55.01%   55.01%
=======================================
  Files         483      483
  Lines       53949    53949
  Branches    10494    10494
=======================================
  Hits        29680    29680
  Misses      19983    19983
  Partials     4286     4286

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cde6bef...e7a7ace. Read the comment docs.

authors: codecov-io galak


text:
[RFC] scripts: ci: check_compliance: Add python lint/format check

Introduction
As the codebase and contributions keep growing, so does all the python tooling.
This PR is intended to make python scripts more uniform and safe.
Proposed change
Add ruff as a linter and formatter for python files, and verify (new) files in CI.
Detailed RFC
Some hightlights:

ruff is a drop-in replacement for many popular python tools, and it is super fast.
The formatter output is PEP8 compliant and produces nearly identical output to black
Can fix issues for you
...

Current enabled linter rules:

[x] flake8-bugbear
[x] pycodestyle
[x] pyflakes
[x] isort (black profile)
[x] flake8-simplify
[x] pyupgrade

Many more can be added/enabled but this is a solid baseline.
Concerns
Existing files do not comply, so they are explicitly excluded. Ideally these are gradually converted to comply.
$ ruff check
Found 3708 errors.

$ ruff format --check
379 files would be reformatted, 34 files already formatted

Formatting is obviously opinionated, but I do think for python we should follow the popular kids, which are black and ruff.

Why add exclusions? If someone adds a new file e.g. a runner from an external source, they would have to fix the file, but if an existing runner which does not comply is excluded, that can be updated forever going forwards without having to comply? Or is the idea that new exclusions would be added, in which case what would be the point of having the check if everything is excluded?

This is up for debate off course, but the idea is to force new files to comply, while we gradually convert the existing ones. It could be brought up during a review to update a file you are touching to comply.

Why add exclusions? If someone adds a new file e.g. a runner from an external source, they would have to fix the file, but if an existing runner which does not comply is excluded, that can be updated forever going forwards without having to comply? Or is the idea that new exclusions would be added, in which case what would be the point of having the check if everything is excluded?

This is up for debate of course, but the idea is to force new files to comply, while we gradually convert the existing ones. It could be brought up during a review to update a file you are touching to comply.

This is something I asked about before because one of the files added from an external source, a uf2 one if I remember right, had some oddities about it, and someone said the file shouldn't be fixed because whilst it was being added to zephyr, it was not a zephyr file, and you then lose the ability to diff etc.

This is something I asked about before because one of the files added from an external source, a uf2 one if I remember right, had some oddities about it, and someone said the file shouldn't be fixed because whilst it was being added to zephyr, it was not a zephyr file, and you then lose the ability to diff etc.

I think this can be an exception, but that's what the exclude lists are for.

Can fix issues for you

can we use ruff to fix the issues in this PR?

can we use ruff to fix the issues in this PR?

Kind of chicken and egg, the check_compliance.py file itself is currently excluded because already existing issues.
$ ruff format --check scripts/ci/check_compliance.py
Would reformat: scripts/ci/check_compliance.py
1 file would be reformatted

$ ruff check scripts/ci/check_compliance.py
Found 25 errors.

Kind of chicken and egg, the check_compliance.py file itself is currently excluded because of already existing issues.

so if this PR merged, can we then use ruff to auto fix issues? if not, this could be a heavy loading

so if this PR merged, can we then use ruff to auto fix issues? if not, this could be a heavy loading

Yes! For the current selected rules:
$ ruff check
...
Found 3713 errors.
[*] 1972 fixable with the `--fix` option (506 hidden fixes can be enabled with the `--unsafe-fixes` option).

But I'd suggest doing fixes in separate PRs to make it easier to digest for reviewing, and it's best to double check automatic fixes.
Formatting can be done too, but this would result in a lot of git churn.

Seems like a good idea, curious why did you pick ruff instead of black? (I know pretty much nothing about these)

Seems like a good idea, curious why did you pick ruff instead of black? (I know pretty much nothing about these)

I think black is just a formatter while ruff does both linting & formatting?

Seems like a good idea, curious why did you pick ruff instead of black? (I know pretty much nothing about these)

It's all packed into one tool, so it should never contradict itself, while using different linter and formatter tools might need exceptions.
It's also super fast, and pleasant to work with. It can also be used as an LSP to get feedback directly in your IDE.

Rebased on main

Update:

Ignore SIM108 to allow if-else blocks instead of forcing ternary operator

@pdgendt where do you want to go from here? It's titled and tagged as RFC  but arguably good to go. Maybe arch wg? (though it's not really an architectural change but seems like any change with wide impact goes there these days)

I was thinking the same thing, wanted to bring this up during some workgroup meeting. Could be for arch or process? Maybe we need a tooling working group?
CC @carlescufi @nashif any suggestions?

I think process would be the "correct-er" one but if you want visibility arch is the one to go, I suggest bringing it up there.

are we going to keep pylint?

There's no conflict between these two, there is some overlap but I haven't added any of the PL rules in this PR.
We might favor enabling the PL rules from ruff and replace pylint with an actual type checker. But that's outside of the scope of this PR.

There's no conflict between these two, there is some overlap but I haven't added any of the PL rules in this PR.
We might favor enabling the PL rules from ruff and replace pylint with an actual type checker. But that's outside of the scope of this PR.

but it is suboptimal if we have two linters doing python, at leasr from a developer experience. For example, if there is a violation that is detected by both, will we get two warnings?

but it is suboptimal if we have two linters doing python, at leasr from a developer experience. For example, if there is a violation that is detected by both, will we get two warnings?

Presumably, yes. But I haven't looked into the overlaps of the current configurations, this can be optimized on the go.
As you can see from the excludes file, there are a lot of linter issues that pylint hasn't reported on.

I think that before doing this (or at least as part of this) we should at least batch fix the files that are obviously not imported and meant to track an external project, I guess anything under arch, doc, samples, script, tests...

I think that before doing this (or at least as part of this) we should at least batch fix the files that are obviously not imported and meant to track an external project, I guess anything under arch, doc, samples, script, tests...

I was going to do it the other way around, this PR is to prevent any new issues from this point forward.

I was going to do it the other way around, this PR is to prevent any new issues from this point forward.

Yup that makes sense.

summarize the issue: linter+formatter check for any new python file
@nashif: asks how this behaves with the current files (out of compliance), current files/exclusions woul
d not trigger
@pdgendt: most of these can be fixed esily, will do some folowup to look into this, the tool has an option
to change the file inline and also do only "safe" changes
no conerns on trying this for new files

FYI: this isn't running only for new files, as it seems like people were expecting.  It's now running on all changes to any python file, to, um hilarious effect, see #81154

FYI: this isn't running only for new files, as it seems like people were expecting.  It's now running on all changes to any python file, to, um hilarious effect, see #81154

As noted in the linked issue, you moved existing files so updating the ruff-excludes entries accordingly should bring you back on track.

authors: andyross fabiobaltieri hakehuang kartben nashif nordicjm pdgendt


text:
shell: Fix command completion logic

The original code (introduced by commit d5db35204a4) looked like this before
the last rewrite/cleanup:
   if (default_module != -1) {
           return (str == NULL) ? dest : -1;
   }

However with the cleanup the logic seems to have gotten reversed.
Fixes #8501
Signed-off-by: Johan Hedberg johan.hedberg@intel.com

note: I haven't tested this, and in fact I'm unsure how the issue manifests itself (perhaps @walter-xie could help provide a test case?). That said, looking at the original code, and the code after the latest redesign/cleanup, it seems obvious that the logic has gotten reversed here.

Codecov Report

Merging #8537 into master will not change coverage.
The diff coverage is 0%.

@@           Coverage Diff           @@
##           master    #8537   +/-   ##
=======================================
  Coverage   63.92%   63.92%
=======================================
  Files         427      427
  Lines       41100    41100
  Branches     6939     6939
=======================================
  Hits        26275    26275
  Misses      11678    11678
  Partials     3147     3147

Impacted Files
Coverage Δ

subsys/shell/shell.c
47.16% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c633637...92c5db0. Read the comment docs.

authors: codecov-io jhedberg


text:
Add ESLint and Prettier configs; Apply linting;

The PR introduce ESLint and Prettier support 🍾

Linting is set up on a pre commit hook so it is impossible to commit code without compiling and linting it
There are base configs for both ESLint and Prettier
Editor extension are available for prettier so a code will be formatted on every save

Only cli and lib projects are linted at that moment and warnings are ignored. We have to try this config first and make sure we are comfortable with it. Next steps are:

Linting tests as well
Linting other projects
Fixing warnings

I belive that code consistency is more important than personal preferences yet I want to be absolutely sure that you guys – @spalladino and @jcarpanelli  are comfortable with these rules. Let me know if anything feels wrong and we'll figure it out.
PS As @spalladino requested semicolons are in.

Absolutely we'll remove it!

repo: zeppelinos/zos

license: MIT


text:
chore: use latest Nuxt release tweet

Because it's sexier :D

Because it's sexier :D

Sexy indeed!

authors: Atinux zernonia

repo: zernonia/nuxt-lego


text:
Local Storage Quota Reached on Resources

Describe the bug
If localStorage quota is reached, resources fail silently to synchronize.
To Reproduce
Just upload a lot of images to the stamp tool.
Expected behavior
Warn the user if quota is exceeded, and mark non-persisted images maybe? We should use IndexedDB for this too.
Screenshots
The console error for quota reached.

Desktop (please complete the following information):

OS: Endeavor OS (Arch Linux)
Browser Firefox 107.0.1
Version f279c84 (testing branch)

Additional context
Should probably use IndexedDB for this, as it almost as compatible as localStorage and allow for a much larger storage. Config should still use localStorage.

Should be fixed on b71731b

Still no warning when quota is reached though.

It's fixed partially on b71731b, now using IndexedDB instead of localStorage. No check for quota was added, but IndexedDB quotas are pretty large, so that can be done later.


text:
Join Chat API

Is there available option for join group chat via invite link?

Just found it, check this:
'messages.importChatInvite'

repo: zerobias/telegram-mtproto

license: mit

license_source: bigquery