text:
littlefs: Too small heap for file cache.

Describe the bug
fs_open for CONFIG_FS_LITTLEFS_NUM_FILESth file returns -ENOMEM.
I.e. CONFIG_FS_LITTLEFS_NUM_FILES=3 and when fs_open is caled for 3rd file it returns -ENOMEM.
After incrementing CONFIG_FS_LITTLEFS_NUM_FILES and opening only CONFIG_FS_LITTLEFS_NUM_FILES-1 files problem is not present.
After increasing file_cache_pool (in littlefs_fs.c) even by 128 bytes problem is not present (CONFIG_FS_LITTLEFS_NUM_FILES=3).
To Reproduce
Try to open at the same time CONFIG_FS_LITTLEFS_NUM_FILES number of files on littleFS.
Expected behavior
No error from fs_open.
Impact
annoyance
Logs and console output
None
Environment (please complete the following information):

OS: Linux
ToolchainZephyr SDK 0.12.1
Commit SHA c31ce55c583a3f68a6d4b815b1693d83098e2ab3

Additional context
Maybe commit fcd392f caused this problem because heap size available to user != declared size of heap.

#31597 may also be relevant.

#31597 may also be relevant.

I am unable to reproduce this problem.  Using an augmented test in https://github.com/pabigot/zephyr/commits/repro/31524 I can open the required number of files, and directories, on nrf52840dk_nrf52840 without error.  (Below this was done with the default count; reconfiguring to 3 also worked.)
CONFIG_FS_LITTLEFS_NUM_FILES=4
opening /sml/A
opening /sml/B
opening /sml/C
opening /sml/D
Close and unlink /sml/D
Close and unlink /sml/C
Close and unlink /sml/B
Close and unlink /sml/A
CONFIG_FS_LITTLEFS_NUM_DIRS=4
making and opening directory /sml/DA
making and opening directory /sml/DB
making and opening directory /sml/DC
making and opening directory /sml/DD
Close and rmdir /sml/DD
Close and rmdir /sml/DC
Close and rmdir /sml/DB
Close and rmdir /sml/DA
unmounting /sml

@r2r0 could you please check this on your configuration?  It may be specific to a particular type of flash or platform.

I am unable to reproduce this problem.  Using an augmented test in https://github.com/pabigot/zephyr/commits/repro/31524 I can open the required number of files, and directories, on nrf52840dk_nrf52840 without error.  (Below this was done with the default count; reconfiguring to 3 also worked.)
CONFIG_FS_LITTLEFS_NUM_FILES=4
opening /sml/A
opening /sml/B
opening /sml/C
opening /sml/D
Close and unlink /sml/D
Close and unlink /sml/C
Close and unlink /sml/B
Close and unlink /sml/A
CONFIG_FS_LITTLEFS_NUM_DIRS=4
making and opening directory /sml/DA
making and opening directory /sml/DB
making and opening directory /sml/DC
making and opening directory /sml/DD
Close and rmdir /sml/DD
Close and rmdir /sml/DC
Close and rmdir /sml/DB
Close and rmdir /sml/DA
unmounting /sml

@r2r0 could you please check this on your configuration?  It may be specific to a particular type of flash or platform.

Attached test fails on QEMU x86 and similar test (the same code and the same LITTLEFS config) also fails on our board with STM32WB55 (external FLASH over QSPI).
littlefs_max_files.zip

Attached test fails on QEMU x86 and similar test (the same code and the same LITTLEFS config) also fails on our board with STM32WB55 (external FLASH over QSPI).
littlefs_max_files.zip

@r2r0 thanks, that gave me the clue.  Please verify solution in #31781.

@r2r0 thanks, that gave me the clue.  Please verify solution in #31781.

@pabigot Thanks for quick reply.
It works but it looks for me a little weird because I expected that littleFS will allocate (in file_cache_pool):
CONFIG_FS_LITTLEFS_NUM_FILES * CONFIG_FS_LITTLEFS_CACHE_SIZE bytes
but now it allocates:
CONFIG_FS_LITTLEFS_NUM_FILES * CONFIG_FS_LITTLEFS_NUM_FILES * CONFIG_FS_LITTLEFS_CACHE_SIZE bytes
Did I miss something?

@pabigot Thanks for quick reply.
It works but it looks for me a little weird because I expected that littleFS will allocate (in file_cache_pool):
CONFIG_FS_LITTLEFS_NUM_FILES * CONFIG_FS_LITTLEFS_CACHE_SIZE bytes
but now it allocates:
CONFIG_FS_LITTLEFS_NUM_FILES * CONFIG_FS_LITTLEFS_NUM_FILES * CONFIG_FS_LITTLEFS_CACHE_SIZE bytes
Did I miss something?

Did I miss something?

No, apparently I did.  I'll take another look later.

Did I miss something?

No, apparently I did.  I'll take another look later.

So here's what's going on.
Originally the file cache used a mem_pool.  With that data structure it appears metadata associated with allocations was held separately, so that the entire requested storage space was available for application use.
In #28611 the k_mem_pool API was deprecated, and existing uses switched to a heap implementation.  It appears in this implementation metadata associated with allocations is taken from the pool itself, which breaks the expectation that you can reserve N blocks of size B and actually allocate N blocks of size B.
I've confirmed this by verifying that the test program above passes at commit 78614bf271c2669912730120fddb32e0102710e0 but breaks at commit fcd392f6ceff5d552d52b3337f373ed8ed14a30 where the deprecated API was replaced by a heap.
The Kconfig options used to allocate the space for per-file caches are completely obsoleted by the change in data structure.
What I've done in #31781 is deprecate the old mem_pool Kconfig options, and add a new option that provides more direct control of the size of the memory region to allocate file caches.  The chain of defaults producing that size have been updated to include the required slop so that allocating N blocks of size B works again.

So here's what's going on.
Originally the file cache used a mem_pool.  With that data structure it appears metadata associated with allocations was held separately, so that the entire requested storage space was available for application use.
In #28611 the k_mem_pool API was deprecated, and existing uses switched to a heap implementation.  It appears in this implementation metadata associated with allocations is taken from the pool itself, which breaks the expectation that you can reserve N blocks of size B and actually allocate N blocks of size B.
I've confirmed this by verifying that the test program above passes at commit 78614bf271c2669912730120fddb32e0102710e0 but breaks at commit fcd392f6ceff5d552d52b3337f373ed8ed14a30 where the deprecated API was replaced by a heap.
The Kconfig options used to allocate the space for per-file caches are completely obsoleted by the change in data structure.
What I've done in #31781 is deprecate the old mem_pool Kconfig options, and add a new option that provides more direct control of the size of the memory region to allocate file caches.  The chain of defaults producing that size have been updated to include the required slop so that allocating N blocks of size B works again.

So, my guessing about problem reason was correct, nice.
Thanks @pabigot , it works very well.

Let's leave this open until the fix is merged.


text:
reel board: Mesh badge demo fails to send BT Mesh message

Describe the bug
When flashing and setting up two reel boards with the mesh badge demo (samples/boards/reel-board/mesh_badge), sending a message via BT Mesh on button press fails with "Sending Failed!" on the reel board display.
Debug Log shows the error:
[00:00:55.785,339] <err> bt_mesh_access: bt_mesh_model_send: Model not bound to AppKey 0x0000
I am building the sample with the most recent main branch (5a62f2592f) and Zephyr SDK 0.16.0-beta1:
west build -b reel_board_v2 samples/boards/reel_board/mesh_badge/ -p && west flash
Connecting and sending the Name via the nRF-Connect works as described in the sample description. Just the BT Mesh send fails.
Please also mention any information which could help others to understand
the problem you're facing:

What target platform are you using? 2x reel_board_v2
What have you tried to diagnose or workaround this issue?
I have tried with v3.2.0 and v3.1.0. v3.2.0 seems broken as well, in v3.1.0 the demo works for me.
Is this a regression? If yes, have you been able to "git bisect" it to a
specific commit?
The behavior has been introduced in between Zephyr v3.1.0 and v3.2.0. I'm not sure how I can narrow it down further with a high effort.

To Reproduce
Steps to reproduce the behavior:

west build -b reel_board_v2 samples/boards/reel_board/mesh_badge/
west flash (for two reel boards)
Connect with the nRF Connect App as described and set up the name
Disconnect from the nRF Connect App
BT Mesh network got successfully created
Press the button 'a Button' on one of the boards

Expected behavior
The two boards should communicate with each other on a button press, showing the name of the sending board in the receiving boards display.
Impact
BT Mesh feature of the Demo does not work
Logs and console output
*** Booting Zephyr OS build v3.3.0-rc1-2-g5a62f2592ffe ***
Starting Board Demo
[00:00:00.879,760] <inf> fs_nvs: nvs_mount: 8 Sectors of 4096 bytes
[00:00:00.879,791] <inf> fs_nvs: nvs_mount: alloc wra: 0, ed8
[00:00:00.879,791] <inf> fs_nvs: nvs_mount: data wra: 0, 1b8
[00:00:00.884,368] <inf> bt_hci_core: hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.884,399] <inf> bt_hci_core: hci_vs_init: HW Variant: nRF52x (0x0002)
[00:00:00.884,429] <inf> bt_hci_core: hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 3.2 Build 99
[00:00:00.884,796] <inf> bt_hci_core: bt_init: No ID address. App must call settings_load()
Bluetooth initialized
Mesh initialized
[00:00:00.895,965] <inf> bt_hci_core: bt_dev_show_info: Identity: EB:7C:3B:78:30:F1 (random)
[00:00:00.895,996] <inf> bt_hci_core: bt_dev_show_info: HCI: version 5.3 (0x0c) revision 0x0000, manufacturer 0x05f1
[00:00:00.896,026] <inf> bt_hci_core: bt_dev_show_info: LMP: version 5.3 (0x0c) subver 0xffff
Already provisioned
Board started
Button pressed
Button released
[00:00:06.972,442] <err> bt_mesh_access: bt_mesh_model_send: Model not bound to AppKey 0x0000
motion!

Environment:

OS: Linux
Toolchain: Zephyr SDK 0.16.0-beta1
Commit SHA or Version used: 5a62f2592f

Additional context

@jremmert-phytec-iot could you please bisect the regression please?

@PavelVPV could you please take a look at this regression, did we break an API somewhere, given that this application used to work and now it no longer does?

Could be that default transport configuration has changed and one of these functions return error:
https://github.com/zephyrproject-rtos/zephyr/blob/74c44dc273c11da3836f9dc77b1921fd0c694484/samples/boards/reel_board/mesh_badge/src/mesh.c#L540-L560
@jremmert-phytec-iot, could you please add error code checking of these functions, then erase the device, flash the demo again and check if they succeed after provisioning.
As I see the demo provisions itself after disconnection from GATT here:
https://github.com/zephyrproject-rtos/zephyr/blob/74c44dc273c11da3836f9dc77b1921fd0c694484/samples/boards/reel_board/mesh_badge/src/main.c#L138-L142
So after disconnect you should see one of these messages:
https://github.com/zephyrproject-rtos/zephyr/blob/cc9d2102f2c2e8d3001c846f7a9f7f524490bb5f/samples/boards/reel_board/mesh_badge/src/mesh.c#L572-L580

@PavelVPV I added error checking and provisioned again, but could not observe an error with those function calls.
I can observe the text "Mesh Started\n Addr: 0x0bd3"
However, while testing I can sometimes observe that the devices crashes when initially connecting with my Android Smartphone or during paring after entering the PassKey in my Smartphone. I'm not sure if this is an other bug or if it is related.
As @carlescufi  suggested, I will try narrow it down and git bisect the regression.
Error during connecting with BLE:
ASSERTION FAIL [0] @ WEST_TOPDIR/zephyr/subsys/bluetooth/controller/ll_sw/nordic/lll/lll.c:473
	lll_preempt_calc: Actual EVENT_OVERHEAD_START_US = 6896
[00:00:17.116,363] <err> os: esf_dump: r0/a1:  0x00000003  r1/a2:  0x00000000  r2/a3:  0x00000003
[00:00:17.116,394] <err> os: esf_dump: r3/a4:  0x20001c00 r12/ip:  0x00000010 r14/lr:  0x00003d81
[00:00:17.116,394] <err> os: esf_dump:  xpsr:  0x41000028
[00:00:17.116,424] <err> os: esf_dump: Faulting instruction address (r15/pc): 0x00003d8c
[00:00:17.116,455] <err> os: z_fatal_error: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:00:17.116,455] <err> os: z_fatal_error: Fault during interrupt handling

[00:00:17.116,516] <err> os: z_fatal_error: Current thread: 0x20002d40 (unknown)
[00:00:17.191,680] <err> os: k_sys_fatal_error_handler: Halting system

Error during pairing after PassKey entry:
ASSERTION FAIL [0] @ WEST_TOPDIR/zephyr/subsys/bluetooth/controller/ll_sw/nordic/lll/lll.c:473
	lll_preempt_calc: Actual EVENT_OVERHEAD_START_US = 8850
[00:00:49.516,571] <err> os: esf_dump: r0/a1:  0x00000003  r1/a2:  0x00000000  r2/a3:  0x00000002
[00:00:49.516,571] <err> os: esf_dump: r3/a4:  0x20001c00 r12/ip:  0x00000010 r14/lr:  0x00003d81
[00:00:49.516,601] <err> os: esf_dump:  xpsr:  0x41000028
[00:00:49.516,601] <err> os: esf_dump: Faulting instruction address (r15/pc): 0x00003d8c
[00:00:49.516,632] <err> os: z_fatal_error: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:00:49.516,662] <err> os: z_fatal_error: Fault during interrupt handling

[00:00:49.516,693] <err> os: z_fatal_error: Current thread: 0x20003610 (unknown)
[00:00:49.589,996] <err> os: k_sys_fatal_error_handler: Halting system

git bisect showed that after the following commit the described error can be observed.
commit 867b88635d4c6963ab37dfe131b5bebc094c4f28
Author: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
Date:   Thu Jun 30 10:58:41 2022 +0200

    Bluetooth: Mesh: Don't do bulk tx of seg msgs

    In the current implementation of segmented messages transmission, the
    transport layer will put as many segments as it can into the advertiser
    buffer. If a long segmented message is transmitted, there is a chance
    that an ack will be received before the transport layer finishes sending
    the first batch of segments. This will trigger retransmissions of those
    segments that are marked as missing in the ack, that are also the
    segments that are scheduled (or about to be scheduled), but not sent
    out by the advertiser yet. Thus, the receiver may receive already
    received segments.

    This commit changes 2 things:
    - it prevents rescheduling transmission of missing segments upon
    reception of ack. Thus, ack doesn't cause segments duplication in the
    advertiser buffer;
    - it doesn't put all segments to the advertiser buffer. Thus, ack that
    acknowledges all segments can immediately stop rescheduling segments as
    they are already received;

    Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>

Note: While checking those relevant revisions you have to apply the following commit as well, otherwise the app won't start.
From the following commit the app generally starts again, but does not work
commit 0514c3b139bffd1813e862a1de42aece0f454c1e
Author: Maureen Helm <maureen.helm@intel.com>
Date:   Mon Aug 15 11:45:41 2022 -0500

    drivers: sensor: Fix apds9960 device pointer initialization

    Fixes a bus fault observed in samples/boards/reel_board/mesh_badge
    caused by dereferencing an uninitialized device pointer in the apds9960
    sensor driver. The device pointer needs to be initialized regardless of
    how CONFIG_APDS9960_TRIGGER is configured.

    Signed-off-by: Maureen Helm <maureen.helm@intel.com>

@jremmert-phytec-iot could you clarify: is the commit that you posted makes the assertion to happen or "Model not bound to AppKey" error?

Commit 1 (867b88635d4c6963ab37dfe131b5bebc094c4f28) causes the "Model not bound to AppKey" error.
Commit 2 (0514c3b139bffd1813e862a1de42aece0f454c1e) causes the assertion error.

git log --oneline
22c7c864fb (HEAD) drivers: sensor: Fix apds9960 device pointer initialization
867b88635d Bluetooth: Mesh: Don't do bulk tx of seg msgs

Additional settings in prj.conf:
CONFIG_LOG_FUNC_NAME_PREFIX_DBG=y
CONFIG_BT_MESH_DEBUG_MODEL=y
CONFIG_LOG_BUFFER_SIZE=4096
Starting Board Demo
Bluetooth initialized
Mesh initialized
Board started
[00:00:01.673,187] <inf> TI_HDC: Initialized device successfully
[00:00:01.688,446] <inf> fs_nvs: 8 Sectors of 4096 bytes
[00:00:01.688,446] <inf> fs_nvs: alloc wra: 0, fe8
[00:00:01.688,476] <inf> fs_nvs: data wra: 0, 0
[00:00:01.690,002] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:01.690,032] <inf> bt_hci_core: HW Variant: nRF52x (0x0002)
[00:00:01.690,063] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 3.1 Build 99
[00:00:01.690,429] <inf> bt_hci_core: No ID address. App must call settings_load()
[00:00:01.709,503] <inf> bt_hci_core: Identity: EB:7C:3B:78:30:F1 (random)
[00:00:01.709,533] <inf> bt_hci_core: HCI: version 5.3 (0x0c) revision 0x0000, manufacturer 0x05f1
[00:00:01.709,564] <inf> bt_hci_core: LMP: version 5.3 (0x0c) subver 0xffff
Connected (err 0x00)
Passkey:
872284
Pairing Failed (1)
Disconnected (reason 0x13)
Connected (err 0x00)
Passkey:
014574
Pairing Complete
Disconnected (reason 0x13)
[00:01:09.113Configuring...
Configuration complete
,647] <inf> bt_mesh_main: Primary Element: 0x4192
[00:01:09.113,647] <dbg> bt_mesh_main: bt_mesh_provision: net_idx 0x0000 flags 0x00 iv_index 0x0000
[00:01:09.197,235] <dbg> bt_mesh_cfg_srv: get_model: Company 0x05f1 ID 0x0000 addr 0x4192
[00:01:09.197,265] <dbg> bt_mesh_cfg_srv: mod_bind: model 0x20000308 key_idx 0x000
[00:01:09.197,265] <dbg> bt_mesh_cfg_srv: mod_app_bind: status 0x03
[00:01:09.197,509] <dbg> bt_mesh_cfg_srv: get_model: ID 0x1000 addr 0x4192
[00:01:09.197,540] <dbg> bt_mesh_cfg_srv: mod_bind: model 0x20000384 key_idx 0x000
[00:01:09.197,540] <dbg> bt_mesh_cfg_srv: mod_app_bind: status 0x03
[00:01:09.197,784] <dbg> bt_mesh_cfg_srv: get_model: ID 0x1100 addr 0x4192
[00:01:09.197,814] <dbg> bt_mesh_cfg_srv: mod_bind: model 0x200003a0 key_idx 0x000
[00:01:09.197,814] <dbg> bt_mesh_cfg_srv: mod_app_bind: status 0x03
[00:01:09.198,059] <dbg> bt_mesh_cfg_srv: get_model: ID 0x0002 addr 0x4192
[00:01:09.198,059] <dbg> bt_mesh_cfg_srv: mod_bind: model 0x20000368 key_idx 0x000
[00:01:09.198,089] <dbg> bt_mesh_cfg_srv: mod_app_bind: status 0x03
[00:01:09.198,333] <dbg> bt_mesh_cfg_srv: mod_sub_add: elem_addr 0x4192, sub_addr 0xc123
[00:01:09.198,364] <dbg> bt_mesh_cfg_srv: get_model: Company 0x05f1 ID 0x0000 addr 0x4192
[00:01:09.198,364] <dbg> bt_mesh_cfg_srv: send_mod_sub_status: status 0x00 elem_addr 0x4192 sub_addr 0xc123
[00:01:09.198,638] <dbg> bt_mesh_cfg_cli: mod_app_status: net_idx 0x0000 app_idx 0xfffe src 0x4192 len 9: 0392410000f1050000
[00:01:09.198,791] <dbg> bt_mesh_cfg_cli: mod_app_status: net_idx 0x0000 app_idx 0xfffe src 0x4192 len 7: 03924100000010
[00:01:09.198,944] <dbg> bt_mesh_cfg_cli: mod_app_status: net_idx 0x0000 app_idx 0xfffe src 0x4192 len 7: 03924100000011
[00:01:09.199,096] <dbg> bt_mesh_cfg_cli: mod_app_status: net_idx 0x0000 app_idx 0xfffe src 0x4192 len 7: 03924100000200
[00:01:09.199,249] <dbg> bt_mesh_cfg_cli: mod_sub_status: net_idx 0x0000 app_idx 0xfffe src 0x4192 len 9: 00924123c1f1050000
[00:01:09.199,523] <dbg> bt_mesh_cfg_srv: app_key_add: AppIdx 0x0000 NetIdx 0x0000
[00:01:09.201,263] <dbg> bt_mesh_cfg_cli: app_key_status: net_idx 0x0000 app_idx 0xfffe src 0x4192 len 4: 00000000
[00:01:09.201,599] <dbg> bt_mesh_cfg_srv: mod_pub_set: elem_addr 0x4192 pub_addr 0xc123 cred_flag 0
[00:01:09.201,599] <dbg> bt_mesh_cfg_srv: mod_pub_set: pub_app_idx 0x000, pub_ttl 31 pub_period 0x4a
[00:01:09.201,629] <dbg> bt_mesh_cfg_srv: mod_pub_set: retransmit 0x00 (count 0 interval 50ms)
[00:01:09.201,629] <dbg> bt_mesh_cfg_srv: get_model: Company 0x05f1 ID 0x0000 addr 0x4192
[00:01:09.202,148] <dbg> bt_mesh_cfg_cli: mod_pub_status: net_idx 0x0000 app_idx 0xfffe src 0x4192 len 14: 03924100000000000000f1050000

As a comparison the debug log, without 867b88635d4c6963ab37dfe131b5bebc094c4f28 and otherwise same settings.
** Booting Zephyr OS build zephyr-v3.1.0-1332-g8a9eeafb0357  ***
Starting Board Demo
Bluetooth initialized
Mesh initialized
Board started
[00:00:01.675,109] <inf> TI_HDC: Initialized device successfully
[00:00:01.690,368] <inf> fs_nvs: 8 Sectors of 4096 bytes
[00:00:01.690,399] <inf> fs_nvs: alloc wra: 0, fe8
[00:00:01.690,399] <inf> fs_nvs: data wra: 0, 0
[00:00:01.691,955] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:01.691,955] <inf> bt_hci_core: HW Variant: nRF52x (0x0002)
[00:00:01.691,986] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 3.1 Build 99
[00:00:01.692,352] <inf> bt_hci_core: No ID address. App must call settings_load()
[00:00:01.711,425] <inf> bt_hci_core: Identity: EB:7C:3B:78:30:F1 (random)
[00:00:01.711,456] <inf> bt_hci_core: HCI: version 5.3 (0x0c) revision 0x0000, manufacturer 0x05f1
[00:00:01.711,486] <inf> bt_hci_core: LMP: version 5.3 (0x0c) subver 0xffff
Connected (err 0x00)
Passkey:
843355
Pairing Failed (1)
Disconnected (reason 0x13)
Connected (err 0x00)
Passkey:
105182
Pairing Complete
Disconnected (reason 0x13)
Configuring...
Configuration complete
[00:00:59.018,310] <inf> bt_mesh_main: Primary Element: 0x1741
[00:00:59.018,341] <dbg> bt_mesh_main: bt_mesh_provision: net_idx 0x0000 flags 0x00 iv_index 0x0000
[00:00:59.101,623] <dbg> bt_mesh_cfg_srv: app_key_add: AppIdx 0x0000 NetIdx 0x0000
[00:00:59.103,271] <dbg> bt_mesh_cfg_srv: get_model: Company 0x05f1 ID 0x0000 addr 0x1741
[00:00:59.103,271] <dbg> bt_mesh_cfg_srv: mod_bind: model 0x20000308 key_idx 0x000
[00:00:59.103,302] <dbg> bt_mesh_cfg_srv: mod_app_bind: status 0x00
[00:00:59.103,546] <dbg> bt_mesh_cfg_srv: get_model: ID 0x1000 addr 0x1741
[00:00:59.103,576] <dbg> bt_mesh_cfg_srv: mod_bind: model 0x20000384 key_idx 0x000
[00:00:59.103,576] <dbg> bt_mesh_cfg_srv: mod_app_bind: status 0x00
[00:00:59.103,820] <dbg> bt_mesh_cfg_srv: get_model: ID 0x1100 addr 0x1741
[00:00:59.103,851] <dbg> bt_mesh_cfg_srv: mod_bind: model 0x200003a0 key_idx 0x000
[00:00:59.103,881] <dbg> bt_mesh_cfg_srv: mod_app_bind: status 0x00
[00:00:59.104,125] <dbg> bt_mesh_cfg_srv: get_model: ID 0x0002 addr 0x1741
[00:00:59.104,125] <dbg> bt_mesh_cfg_srv: mod_bind: model 0x20000368 key_idx 0x000
[00:00:59.104,156] <dbg> bt_mesh_cfg_srv: mod_app_bind: status 0x00
[00:00:59.104,400] <dbg> bt_mesh_cfg_srv: mod_sub_add: elem_addr 0x1741, sub_addr 0xc123
[00:00:59.104,400] <dbg> bt_mesh_cfg_srv: get_model: Company 0x05f1 ID 0x0000 addr 0x1741
[00:00:59.104,431] <dbg> bt_mesh_cfg_srv: send_mod_sub_status: status 0x00 elem_addr 0x1741 sub_addr 0xc123
[00:00:59.104,736] <dbg> bt_mesh_cfg_cli: app_key_status: net_idx 0x0000 app_idx 0xfffe src 0x1741 len 4: 00000000
[00:00:59.104,888] <dbg> bt_mesh_cfg_cli: mod_app_status: net_idx 0x0000 app_idx 0xfffe src 0x1741 len 9: 0041170000f1050000
[00:00:59.105,010] <dbg> bt_mesh_cfg_cli: mod_app_status: net_idx 0x0000 app_idx 0xfffe src 0x1741 len 7: 00411700000010
[00:00:59.105,163] <dbg> bt_mesh_cfg_cli: mod_app_status: net_idx 0x0000 app_idx 0xfffe src 0x1741 len 7: 00411700000011
[00:00:59.105,316] <dbg> bt_mesh_cfg_cli: mod_app_status: net_idx 0x0000 app_idx 0xfffe src 0x1741 len 7: 00411700000200
[00:00:59.105,468] <dbg> bt_mesh_cfg_cli: mod_sub_status: net_idx 0x0000 app_idx 0xfffe src 0x1741 len 9: 00411723c1f1050000
[00:00:59.105,804] <dbg> bt_mesh_cfg_srv: mod_pub_set: elem_addr 0x1741 pub_addr 0xc123 cred_flag 0
[00:00:59.105,834] <dbg> bt_mesh_cfg_srv: mod_pub_set: pub_app_idx 0x000, pub_ttl 31 pub_period 0x4a
[00:00:59.105,834] <dbg> bt_mesh_cfg_srv: mod_pub_set: retransmit 0x00 (count 0 interval 50ms)
[00:00:59.105,834] <dbg> bt_mesh_cfg_srv: get_model: Company 0x05f1 ID 0x0000 addr 0x1741
[00:00:59.105,865] <dbg> bt_mesh_cfg_srv: _mod_pub_set: period 10000 ms
[00:00:59.106,384] <dbg> bt_mesh_cfg_cli: mod_pub_status: net_idx 0x0000 app_idx 0xfffe src 0x1741 len 14: 00411723c100001f4a00f1050000

Ok, now I see. Thanks for the log. Previously (before https://github.com/zephyrproject-rtos/zephyr/commit/867b88635d4c6963ab37dfe131b5bebc094c4f28), the transport layer would push as much segments to the network layer as it can allocate using bt_mesh_adv_create. Because the default mesh stack configuration had enough adv buffers (CONFIG_BT_MESH_ADV_BUF_COUNT), the transport layer could push a complete Config AppKey Add message at once to the network layer without rescheduling inside. And the network layer could process the message immediately. So that when a next message comes (that is Config Model App Bind in the sample), the previous one would have an effect already. Therefore, adding appkey and binding worked when 2 functions are called in a row without waiting for the response.
Now, the transport layer pushes one segment at a time. And because the Configuration Client APIs are used asynchronous manner, the next function doesn't wait for the previous one to complete, tries to bind the not added appkey yet, and fails (mod_app_bind: status 0x03 in the first log). And the appkey is added after all binds attempts.
However, the previous implementation won't work if adv buffers were not enough to push a complete segmented message to the network layer. Then the same issue would happen as it happens with new implementation. So in my opinion, the application code is not correct anyway.
To solve this in the sample we need to either use Configuration Client API in a synchronous manner, but then we need to run start_mesh function from a different cooperative thread (not from the system workqueue thread, otherwise we the API will timeout). Or assign app_key_status callback to Configuration Client, and then bind the appkeys to models in from the callback. Ideally, all methods should wait for the corresponding callback before calling the next API.

@PavelVPV thanks for explaining the issue! I liked your idea to use the callback and gave it a try to make a fix. Can you have a look at it?

source: gharchive/issue

authors: PavelVPV carlescufi jremmert-phytec-iot

repo: zephyrproject-rtos/zephyr

license_type: permissive

license_source: github-api


text:
boards: mimxrt1050_evk: Enable lpuart3 for bluetooth hci

Enables instance 3 of the lpuart driver, adds dts fixups, and configures
pinmuxes to use bluetooth hci on the mimxrt1050_evk board. Updates board
documentation accordingly.
Tested with samples/bluetooth/peripheral_hr, with frdm_kw41z attached as
an arduino shield running the nxp hci controller application.

Codecov Report

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

@@           Coverage Diff           @@
##           master   #10194   +/-   ##
=======================================
  Coverage   53.03%   53.03%
=======================================
  Files         214      214
  Lines       26176    26176
  Branches     5642     5642
=======================================
  Hits        13883    13883
  Misses      10024    10024
  Partials     2269     2269

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 4e61ccd...4e899da. Read the comment docs.

source: gharchive/pull-request

authors: MaureenHelm codecov-io


text:
Bluetooth: Mesh: Prov confirm tx after confirm rx

According to Mesh Profile Specification 1.0.1 Figure 5.17, the
unprovisioned device should send its confirmation value after the
provisioner sends theirs. Previously, the confirmation value would be
sent immediately after OOB input complete. Now it waits for the
confirmation from the provisioner.
Fixes: #18178.
Signed-off-by: Trond Einar Snekvik Trond.Einar.Snekvik@nordicsemi.no

According to the specification, the provisioner sends an confirmation value only after the Input Complete PDU sent by the device when use input OOB method, so there is no need to exec code at the function below.
        if (atomic_test_and_clear_bit(link.flags, SEND_CONFIRM)) {
 		send_confirm();
 	}

https://github.com/zephyrproject-rtos/zephyr/blob/71d5d7b2808d35ad1d7939e795fb9a3a84eb4b3c/subsys/bluetooth/mesh/prov.c#L828-L864

That's true. I didn't want to change the intended behavior of the code, but if @jhedberg agrees, we can remove all the parallel parts of OOB input and confirmation, and get rid of the SEND_CONFIRMATION flag.

Yep, looks like the flag can be removed. Feel free to update the PR accordingly.

Removed the flags, and made it impossible to receive confirm before the input is completed. @jhedberg @menglingao1997 care to take another look?

Will anyone else review this bug-fix PR? @joerchan, @Vudentz ?

Will anyone else review this bug-fix PR? @joerchan, @Vudentz ?

I think it’s sufficient that I and @trond-snekvik are fine with it. Proceeding with merging since I think we want this in 1.14.1.

authors: ioannisg jhedberg menglingao1997 trond-snekvik


text:
net: openthread: fix initialization with link raw enabled

Fix the OpenThread initialization to prevent the IPv6 interface to be enabled when CONFIG_OPENTHREAD_RAW is set.

Hi, CI is green now.


text:
cmake: run gen_handles.py before zephyr_prebuilt.elf

This PR resolves multiple issues relating to resizing variables between linker passes.
The primary linker stage limitation is that the address space CANNOT shift between zephyr_prebuilt.elf and zephyr.elf, as kernel object addresses from zephyr_prebuilt.elf are used to generate hash tables for zephyr.elf when CONFIG_USERSPACE is enabled.
Rather that introducing a new linker stage, we can extend the use of an apparently little known third linker stage that is generated before zephyr_prebuilt.elf, app_smem_unaligned_prebuilt.elf. This stage is currently used when CONFIG_USERSPACE is enabled to count kernel objects in order to reserve space in zephyr_prebuilt.elf. This is basically the same thing we want to do with the device handle arrays.
With these changes, the final device handle arrays are already present in zephyr_prebuilt.elf. This finally resolves the initial reason the device dependency feature was reverted in #31548.
As an added bonus, the size of .rodata is strictly reduced, as devices no longer need multiple DEVICE_HANDLE_ENDS to pad the arrays.

Just a disclaimer, no new kobjects can be defined in GENERATED_APP_SOURCE_FILES otherwise the size of the hash table changes and this solution does not work.

I am not sure I get this. new kobjects relative to what? This PR only adds generation of the handles, which changes the memory layout of the image, but doesn't generate any kernel objects. Aside from that everything remains the same, so it's unclear to me why you raise this as a potential issue.

authors: JordanYates carlescufi


text:
linker: add DWARF-5 debug sections

DWARF-5 standard replaced the location list (.debug_loc) and range
list (.debug_ranges) sections with new sections (.debug_loclists
and .debug_rnglists).
They weren't handled which resulted in many orphan sections
reported as warnings by linker.
Signed-off-by: Michał Barnaś mb@semihalf.com

I had to add an additional line to remove my ITE warnings. Can you add .debug_line_str?

/* DWARF 5 */
SECTION_PROLOGUE(.debug_line_str, 0,)  { *(.debug_line_str) }
SECTION_PROLOGUE(.debug_loclists, 0,)  { *(.debug_loclists) }
SECTION_PROLOGUE(.debug_rnglists, 0,)  { *(.debug_rnglists) }

Sure, done and checked with hayato


text:
tests/bluetooth/tester: Add support for multiple GATT subscriptions

was affecting GATT/CL/GAI/BI-01-C qualification test

gentle ping

gentle ping

If you want a re-review, you can simply press the "Re-request review" button :)

authors: Thalley sjanc


text:
linker: rom_start_offset: add to address instead of set

The CONFIG_ROM_START_OFFSET is supposed to be added to the current when linking, instead of having the current address set to it. So fix that.
Not sure why it worked up to this point, but llvm/clang/lld complained that it could not move location counter backward.
Signed-off-by: Daniel Leung daniel.leung@intel.com

The CI failure is due to https://github.com/zephyrproject-rtos/zephyr/issues/54720 (which qemu_arc_em failed tests/kernel/mem_protect/syscalls/).

I'm confused why this somehow worked earlier too. Are we sure we don't have something else clobbering the value, making this code a noop (except for the "move backwards" behavior I guess)? Feels like there must be something else hidden. But then I guess that's always true with the linker stuff.

I checked the final linker.cmd and it was actually . = 0x0. Though, only lld complained. So it is possible ld interprets this as address 0x0000 of a particular section (where final address is offset by the section beginning address), while lld interprets this as absolute address in memory.


text:
Initial support for EFR32MG24

This PR introduces initial support for the BRD2601B (Mighty Gecko Radio Board) board. It consists of:

EFR32MG24 SoC support
BRD2601B board support
GPIO support
UART support

What uses sl_device_init_hfxo_config.h?

Hi @galak. This file is used by the HAL here: https://github.com/zephyrproject-rtos/hal_silabs/blob/master/gecko/CMakeLists.txt#L36-L41. Similar setup is used by the efr32bg_sltb010a board: https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/arm/efr32bg_sltb010a/sl_device_init_hfxo_config.h.

Hi @galak, please let me know if there is anything left for me to fix here before we can proceed with this PR.

@tgorochowik thanks for the review, I've applied the changes you suggested. PTAL at this PR.

Hi @dcpleung, @mnkp. Could you check if the UART/GPIO changes (respectively) are fine with you? Thanks!

Hi @tgorochowik, @dcpleung.
I had to force push to update the sha pointer to the hal_silabs repository after https://github.com/zephyrproject-rtos/hal_silabs/pull/22 got merged, dismissing your ACKs in the process. PTAL at this PR. Thanks!

Hi, I would like to add PWM-led light support for brd2601b based on this PR.
I made the following changes and verified them with the example samples/drivers/led_pwm.
However, after brushing the firmware into the device, the led lights did not flicker on the light change.
How do I change the code to make it work？
diff --git a/boards/arm/efr32xg24_dk2601b/efr32xg24_dk2601b.dts b/boards/arm/efr32xg24_dk2601b/efr32xg24_dk2601b.dts
index e7ff6d3555..cc26a4a385 100644
--- a/boards/arm/efr32xg24_dk2601b/efr32xg24_dk2601b.dts
+++ b/boards/arm/efr32xg24_dk2601b/efr32xg24_dk2601b.dts
@@ -7,6 +7,7 @@
 /dts-v1/;
 #include <silabs/efr32mg24b310f1536im48.dtsi>
 #include <silabs/efr32mg24-pinctrl.dtsi>
+#include <zephyr/dt-bindings/pwm/pwm.h>

 / {
 	model = "Silicon Labs BRD2601B (Mighty Gecko Radio Board)";
@@ -26,6 +27,7 @@
 		led2 = &blue_led;
 		sw0 = &button0;
 		sw1 = &button1;
+		pwm-led0 = &pwm_led0;
 	};

 	leds {
@@ -41,6 +43,15 @@
 		};
 	};

+	pwmleds {
+		compatible = "pwm-leds";
+		status = "okay";
+		pwm_led0: pwm_led0 {
+			label = "pwm_led0";
+			pwms = <&pwm0 0 PWM_MSEC(20) PWM_POLARITY_NORMAL>;
+		};
+	};
+
 	buttons {
 		compatible = "gpio-keys";
 		button0: button_0 {
@@ -69,6 +80,16 @@
 	status = "okay";
 };

+&timer0 {
+	status = "okay";
+
+	pwm0: pwm {
+		status = "okay";
+		pin-location = <GECKO_LOCATION(0) GECKO_PORT_B GECKO_PIN(0)>;
+		prescaler = <1024>;
+	};
+};
+
 &gpio {
 	status = "okay";
 };
diff --git a/drivers/pwm/pwm_gecko.c b/drivers/pwm/pwm_gecko.c
index 55c21a8681..cec2cb8a4b 100644
--- a/drivers/pwm/pwm_gecko.c
+++ b/drivers/pwm/pwm_gecko.c
@@ -11,6 +11,10 @@
 #include <em_cmu.h>
 #include <em_timer.h>

+#ifndef _TIMER_CC_CTRL_MODE_MASK
+#define _TIMER_CC_CTRL_MODE_MASK _TIMER_CFG_MODE_MASK
+#endif
+
 /** PWM configuration. */
 struct pwm_gecko_config {
 	TIMER_TypeDef *timer;
@@ -44,6 +48,11 @@ static int pwm_gecko_set_cycles(const struct device *dev, uint32_t channel,
 			(channel * _TIMER_ROUTELOC0_CC1LOC_SHIFT),
 			cfg->location << (channel * _TIMER_ROUTELOC0_CC1LOC_SHIFT));
 		BUS_RegMaskedSet(&cfg->timer->ROUTEPEN, 1 << channel);
+#elif defined(_GPIO_TIMER_ROUTEEN_MASK)
+  volatile uint32_t * route_register = &GPIO->TIMERROUTE[TIMER_NUM(cfg->timer)].CC0ROUTE;
+  route_register += cfg->channel;
+  *route_register = (cfg->port << _GPIO_TIMER_CC0ROUTE_PORT_SHIFT)
+                    | (cfg->pin << _GPIO_TIMER_CC0ROUTE_PIN_SHIFT);
 #else
 #error Unsupported device
 #endif
diff --git a/dts/arm/silabs/efr32mg24.dtsi b/dts/arm/silabs/efr32mg24.dtsi
index 5255f8e618..cb82bd25be 100644
--- a/dts/arm/silabs/efr32mg24.dtsi
+++ b/dts/arm/silabs/efr32mg24.dtsi
@@ -145,6 +145,18 @@
 			interrupts = <43 0>;
 			status = "disabled";
 		};
+
+		timer0: timer@50048000 {
+			compatible = "silabs,gecko-timers";
+			reg = <0x50048000 0x400>;
+			status = "disabled";
+
+			pwm {
+				compatible = "silabs,gecko-pwm";
+				status = "disabled";
+				#pwm-cells = <3>;
+			};
+		};
 	};
 };

Hi @tgorochowik, @mrfuchs.
I had to force push changes to address comments. PTAL at this PR. Thanks!

Hi @ihidchaos! I'm afraid I cannot help you, as we don't support PWM in this initial PR for this platform. Please feel free to create an issue for it after this PR is merged.

Hi, my project uses EFR32BG24BxxxF1536, is there any support?

authors: ZengYiiii fkokosinski ihidchaos


text:
kernel/sched: fix thread selection when ABORTING + PENDING

In commit d537267f, the check on thread abortion was moved from next_up to z_get_next_switch_handle. However, next_up is also called from z_swap_next_thread, so the check on thread abortion is now missing there. This sometimes caused the thread to be stuck in ABORTING + PENDING state during the test_smp_switch_torture in test/kernel/smp
To avoid such cases in the future, it is worth leaving the check in next_up

@vdsh-sc - can you please create a new issue / bug report (using the template) and copy your console output for the hung / failed torture test?
Ideally anyone should be able reproduce the bug / fix.

Issue: https://github.com/zephyrproject-rtos/zephyr/issues/60815

Fix signed-off

Let me stick bug and P1 labels on this to make sure it doesn't get forgotten.  It's a real kernel regression and should merge in some form.

I think it's clear that the platform-specific issue is platform-specific, so this can probably be merged.

Ah, but the compliance issues ... hmm...

@vdsh-sc - you likely need to do the following
# "--global" is optional below
git config --global user.name "Vadim Shakirov"
git commit --amend --author="Vadim Shakirov <vadim.shakirov@syntacore.com>"
git push --force syntacore

authors: andyross cfriedt vdsh-sc


text:
Documentation: Add new PREDEFINED tag

Documentation for bt_gatt_subscribe_params is not complete. CONFIG_BT_GATT_AUTO_DISCOVER_CCC need to be selected so Doxygen add see end_handle and disc_params.

Thanks! Please update the commit message/description as it's not properly describing the actual change anymore.

The commit message is correct, what do you want to change?

Also, why not also update ex. L1470, to make chan_opt visible in the docs? (didn't look at the entire file but I'm guessing there might be other similar places that could be updated)

I found that documentation miss while working on something else. I cannot go through the whole file currently.

Thanks! Please update the commit message/description as it's not properly describing the actual change anymore.

The commit message is correct, what do you want to change?

What I meant is that It's not really touching PREDEFINED anymore.

What I meant is that It's not really touching PREDEFINED anymore.

I see what you mean, it's not directly modifying PREDEFINED but I am not saying that. But it's still using __DOXYGEN__ tag from PREDEFINED.

authors: kartben theob-pro


text:
serial: stm32: clear state before enabling async transfer

Clear RXNE bit just before enabling the asynchronous transfer, not to trigger DMA to copy data received before enabling the transfer. Otherwise, it would look like old and new data were received together, because only the IDLE line (after new data) triggers IRQ to signal a new transfer.
Fixes: #64436

Hm... maybe wrap this in a kconfig as this also changes the runtime behavior if RX is disabled and re-enabled.

Makes sense, done.

Ping.

Let's close relative discussion before merging

Let's close relative discussion before merging

Marking DNM for now.

Set back to DNM as an alternate solution proposed to the same issue here:
https://github.com/zephyrproject-rtos/zephyr/pull/65320.
Let's agree on the one to keep

The solution I proposed which simply flushed the RX data register before enabling the UART RX is actually required, since there is always an additional byte received when enabling async RX without it. This is before any data has actually been transmitted, so its not due to "old" received data, as demonstrated within the PR #65320 as well.
If the solution in #65320 also fixes the issue described in #64436, then we need only add the RX flush.
Given that not flushing the RX data register leads to a bug, it makes no sense to allow the user to include the bug using a Kconfig option.

I've added a comment #65320. After applying the requested changes, both PRs are almost the same.

The solution I proposed which simply flushed the RX data register before enabling the UART RX is actually required, since there is always an additional byte received when enabling async RX without it.

According to this description, https://github.com/zephyrproject-rtos/zephyr/pull/65320 has a wider use case coverage. So I propose to keep that one. @niedzwiecki-dawid Is that fine for you ?

The solution I proposed which simply flushed the RX data register before enabling the UART RX is actually required, since there is always an additional byte received when enabling async RX without it.

According to this description, #65320 has a wider use case coverage. So I propose to keep that one. @niedzwiecki-dawid Is that fine for you ?

ATM, it is the same change except for the used Kconfig, so I'm totally fine with that.

Closing, because of mirror changes in #65320

authors: bjarki-trackunit dcpleung erwango niedzwiecki-dawid


text:
Cleanup cache initialization

Data and instruction cache initialization is currently a little bit messy. This PR aims at unifying the available config options and providing a more consistent approach on cache activation.
This is a follow up to #66443.
Open is to check where the caches were automatically enabled previously (SystemInit, Hal, ...) and disabling them directly after.

[ ] soc_rt10xx.c
[ ] soc_rt11xx.c
[ ] kv5x/soc.c
[ ] same70/soc.c
[ ] samv71/soc.c

Hi @benediktibk ,
In the case of SAM only:
The initial discussion around SAM cache started here #60425. Later the #61005 solve the issues and let user setup cache as it pleases. The default value is cache disabled and the below examples are for SAMV71 which have both I/D Cache available. User should add below lines on their own board.
I Cache only:
CONFIG_CACHE_MANAGEMENT=y
CONFIG_DCACHE=n
D Cache only:
CONFIG_CACHE_MANAGEMENT=y
CONFIG_ICACHE=n
I/D Cache disabled:
CONFIG_ICACHE=n
CONFIG_DCACHE=n
I/D Cache Enabled:
CONFIG_CACHE_MANAGEMENT=y
IMHO, cache should be user defined since user may want to use ITCM/DTCM for other purposes. So, I'm interested in know how this PR changes the above behavior?

Hi @benediktibk ,
In the case of SAM only:
The initial discussion around SAM cache started here #60425. Later the #61005 solve the issues and let user setup cache as it pleases. The default value is cache disabled and the below examples are for SAMV71 which have both I/D Cache available. User should add below lines on their own board.
I Cache only: CONFIG_CACHE_MANAGEMENT=y CONFIG_DCACHE=n
D Cache only: CONFIG_CACHE_MANAGEMENT=y CONFIG_ICACHE=n
I/D Cache disabled: CONFIG_ICACHE=n CONFIG_DCACHE=n
I/D Cache Enabled: CONFIG_CACHE_MANAGEMENT=y
IMHO, cache should be user defined since user may want to use ITCM/DTCM for other purposes. So, I'm interested in know how this PR changes the above behavior?

This seems to contradict what I got told in this PR earlier on by @carlocaione. If I understood it correctly SoCs should use in their init code sys_cache_data/instr_enable to enable the caches. Therefore, configuring CONFIG_CACHE_MANAGEMENT=n will result in disabled caches in anyway, and CONFIG_DCACHE and CONFIG_ICACHE will only indicate if the SoC has a cache or not.
Btw, I saw that in the of the PRs you explictly added a disable-call for the caches during initialization. Are the caches enabled using something else earlier on for these SoCs?

This seems to contradict what I got told in this PR earlier on by @carlocaione. If I understood it correctly SoCs should use in their init code sys_cache_data/instr_enable to enable the caches. Therefore, configuring CONFIG_CACHE_MANAGEMENT=n will result in disabled caches in anyway, and CONFIG_DCACHE and CONFIG_ICACHE will only indicate if the SoC has a cache or not.

yes, this is correct. @nandojve you should never toggle CONFIG_DCACHE yourself if you are using the Zephyr cache APIs.
I'll try to better explain what is the rationale here (when using the proper cache APIs):

All the zephyr code should use the sys_cache_* API to do cache operations so that the code is agnostic about the actual hardware it is running on.
The only switch that the user could use to disable / enable the cache operations is CONFIG_CACHE_MANAGEMENT and nothing else. If the hardware does not support cache ops that option is doing nothing from the beginning (see following point), otherwise we are simply converting all the cache operations to -ENOTSUP when setting that to =n.
At SoC level the SoC is defining CONFIG_{D,I}CACHE whether we support cache operations at SoC level. If the SoC does not support caches, it simply do not define those and the sys_cache_* ops are falling to -ENOTSUP.

All the zephyr code should use the sys_cache_* API to do cache operations so that the code is agnostic about the actual hardware it is running on.

One small caveat: If external code (for instance HAL) is used for the initalization, which automatically activates caches, the caches have to be deactivated directly after such a call using a low level function call, not sys_cache_. Then during the SoC initialization later on sys_cache_ can be used to activate the caches.
@carlocaione Correct?

One small caveat: If external code (for instance HAL) is used for the initalization, which automatically activates caches, the caches have to be deactivated directly after such a call using a low level function call, not sys_cache__. Then during the SoC initialization later on sys_cache__ can be used to activate the caches.
@carlocaione Correct?

Well yes but I would consider that an HAL issue to be honest. The HAL should not enable the caches behind the user backs, is is up to the OS doing that.

Unfortunately, I'm gonna need some additional information which I could not figure out by myself. For these systems the caches were explicitly disabled during startup. I assume from this fact (and sometimes also a comment was hinting towards this) that a previous call to something like SystemInit, ... automatically enables the caches. We came to the conclusion that it will be necessary to revert these changes directly after this calls.
Could the mentioned people please help me out finding the correct spots?

soc_rt10xx.c, soc_rt11xx.c, kv5x/soc.c: @dleach02
same70/soc.c, samv71/soc.c: @nandojve

Unfortunately, I'm gonna need some additional information which I could not figure out by myself. For these systems the caches were explicitly disabled during startup. I assume from this fact (and sometimes also a comment was hinting towards this) that a previous call to something like SystemInit, ... automatically enables the caches. We came to the conclusion that it will be necessary to revert these changes directly after these calls.
Could the mentioned people please help me out finding the correct spots?

soc_rt10xx.c, soc_rt11xx.c, kv5x/soc.c: @dleach02
same70/soc.c, samv71/soc.c: @nandojve

In the Atmel all SoC's are using only one entry point to configure the platform which is z_arm_platform_init. If there are any other entry point in the whole initialization that enable/disable cache outside SoC code IMHO that is wrong. After z_arm_platform_init the system should check and use cache if they are available, that is it. It is not possible to the system know everything about the platform, which may include internal flash registers to configure the cache size (for instance). Which means that when customer enables a cache the SRAM size is decreased and that must be considered at build time for this platform (so linker scripts etc). Only the user/customer know that and sometimes the HW need to be programmed to be correct (so it is not only about SW).
The only way that I see to system try configure this is providing a dedicated API, something like _z_arm_platform_cache_XXX. With that, the SoC may implement accordingly the cache initialization. However this could let to other problems like multiple initialization stages.

@nandojve Okay, I think we agree about the one spot where caches should be enabled or disabled and configured correctly. I'm only wondering why there are explicit calls to SCB_DisableI/DCache in z_arm_platform_init at the moment?
void z_arm_platform_init(void)
{
    if (IS_ENABLED(CONFIG_CACHE_MANAGEMENT) && IS_ENABLED(CONFIG_ICACHE)) {
        SCB_EnableICache();
    } else {
        SCB_DisableICache();
    }
    if (IS_ENABLED(CONFIG_CACHE_MANAGEMENT) && IS_ENABLED(CONFIG_DCACHE)) {
        SCB_EnableDCache();
    } else {
        SCB_DisableDCache();
    }

Are the caches automatically enabled previously, maybe as the default of the hardware?

@nandojve Okay, I think we agree about the one spot where caches should be enabled or disabled and configured correctly. I'm only wondering why there are explicit calls to SCB_DisableI/DCache in z_arm_platform_init at the moment?

They are there because on my perspective the SoC is responsible to do cache enable/disable.

void z_arm_platform_init(void)
{
    if (IS_ENABLED(CONFIG_CACHE_MANAGEMENT) && IS_ENABLED(CONFIG_ICACHE)) {
        SCB_EnableICache();
    } else {
        SCB_DisableICache();
    }
    if (IS_ENABLED(CONFIG_CACHE_MANAGEMENT) && IS_ENABLED(CONFIG_DCACHE)) {
        SCB_EnableDCache();
    } else {
        SCB_DisableDCache();
    }

Are the caches automatically enabled previously, maybe as the default of the hardware?

The SAME7x/V7x default configuration is that

DTCM is enabled by default at reset
ITCM is disabled by default at reset

You can get all details at 11.1.2 Tightly Coupled Memory (TCM) Interface in SAMV7 datasheet.

@carlocaione There are, of now, some spots where I have to disable caches, although CONFIG_CACHE_MANAGEMENT might be disabled. I decided to use arch_dcache_disable for this, as I did not want to spread calls to SCB_DisableDCache all over the place. Unfortunately, these functions are only built and linked if CONFIG_CACHE_MANAGEMENT is enabled. To work around this I introduced CONFIG_ANY_CACHE, which is basically the same as CONFIG_CACHE_MANAGEMENT but without a prompt.
Which version would you prefer, CONFIG_ANY_CACHE or calling SCB_DisableDCache directly? Or something completely different?
The problematic spots are:

arch/arm/core/cortex_m/scb.c
soc/arm/atmel_sam/same70/soc.c
soc/arm/atmel_sam/samv71/soc.c

Removed ANY_CACHE again and used direct calls to SCB_* wherever it was necessary.

Removed ANY_CACHE again and used direct calls to SCB_* wherever it was necessary.

Rebased to trigger CI as the github incident has been resolved.

authors: benediktibk carlocaione nandojve


text:
Bluetooth: ATT: Fix clearing context at disconnect

When att_disconnected is called a thread may be waiting for the tx_sem
but that is memset to 0, furthermore there exists a flag
ATT_DISCONNECTED to indicate the context is no longer valid so the use
of memset is not really required.
Fixes #8083
Signed-off-by: Luiz Augusto von Dentz luiz.von.dentz@intel.com

Codecov Report

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

@@           Coverage Diff           @@
##           master    #8201   +/-   ##
=======================================
  Coverage   64.53%   64.53%
=======================================
  Files         420      420
  Lines       40101    40101
  Branches     6762     6762
=======================================
  Hits        25881    25881
  Misses      11103    11103
  Partials     3117     3117

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 265f502...d2ca615. Read the comment docs.

@sjanc @jhedberg memset has been moved to accept.

authors: Vudentz codecov-io


text:
Dev cube update for v1.13

Updating ext/hal/st/stm32cube folder with up to date STM32Cube versions for following series:
F1: V1.6.0 > V1.6.1
F3: V1.9.0 > V1.9.1  (fixes 2 patches, cf commit message)
F4: V1.18.0 > V1.21.0
F7: V1.8.0 > V1.11.0
L4: V1.10 > V1.12.0 (fixes one patch,  cf commit message)

Codecov Report

Merging #8589 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #8589      +/-   ##
==========================================
- Coverage   64.17%   64.17%   -0.01%
==========================================
  Files         429      429
  Lines       41157    41157
  Branches     6925     6925
==========================================
- Hits        26414    26413       -1
- Misses      11586    11587       +1
  Partials     3157     3157

Impacted Files
Coverage Δ

samples/philosophers/src/main.c
96.87% <0%> (-1.57%)
:arrow_down:

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 aa2beb9...6f99199. Read the comment docs.

authors: codecov-io erwango


text:
format output is not a valid SQL

Tested on  "sql-formatter": "^4.0.2",
  console.log(
    format(
      `select "users".* from "users" where "users"."id" in where "certification_enrolments"."deleted_at" != 1)`
    )
  )

outputs
select
      "users".*
    from
      "users"
    where
      "users"."id" in
    where
      "certification_enrolments"."deleted_at" ! = 1
    )

expected output:
select
      "users".*
    from
      "users"
    where
      "users"."id" in
    where
      "certification_enrolments"."deleted_at" != 1
    )

the difference is there is not space between ! and =

The same happens with the || operator (concatenation)

+1 We are seeing this issue as well with = > when the expected output is =>.

Hi, this issue is fixed in my fork here:
https://github.com/inferrinizzard/prettier-sql
https://www.npmjs.com/package/prettier-sql

Fixed now in master branch.

authors: capaj ghenkhaus inferrinizzard nene pankgeorg

repo: zeroturnaround/sql-formatter

license: mit

license_source: bigquery


text:
Unix コマンドの unset に対応する操作を追加

環境変数の削除する方法が提供されていなかったので、実装してみました。
$ unset name としようとしたのですが、Windows のコマンドプロンプトでは、$ set name= とすると削除されるようなので、そのように実装しました。
$ set name= # これで消える
$ lua_e "nyagos.setenv('name', '')" # これでも消える

実装方法に問題などあれば、修正します。よろしくお願いいたします。

ありがとうございます。マージさせていただきました。

マージありがとうございます!

repo: zetamatta/nyagos


text:
Is HyperLPRLite Trained by HyperLPR-training?

There are several references of training codes in the readme.md. Is there a list that shows which model is trained by which code? Thanks in advance.

you can refer https://github.com/armaab/hyperlpr-train

Please, the hyperlpr-train is not using GRU, but HyperLPR is using GRU; CAN YOU PROVIDE CODE?

@soufianesabiri  hyperlpr-train is segmentation based code. if you want to train cnn e2e model, you can try https://github.com/armaab/hyperlpr-train

repo: zeusees/HyperLPR


text:
Do not use absolute paths to the textures

Minor usability note:
I think it would be a good idea to not use absolute paths to the textures in the output gltf files.
Or at least have an option for that.

While I agree with this statement, I'm not sure I understand this :) gltfpack currently preserves texture paths, are you saying that if the input paths are absolute, the output paths should be relative?

Well, probably there should be an option for that - to convert absolute paths to relative. I'd say this can save a lot of time for artists and other people. Because "it is working on my computer", but when I upload model - paths (from my laptop) could not be found.

Any chance you have an example of a model with absolute paths to make sure the fix for this issue properly addresses it?

I don't want to blindly fix this issue without examples, because the specific semantics of encoding absolute paths in glTF URIs is unclear to me (glTF spec doesn't require support for absolute paths either). I tried to find a tool that exports absolute paths but Blender doesn't do that and Substance Painter doesn't do that either. So I'm going to close this for now; feel free to reopen it with example files and the software that produced that.

Sorry, I missed your previous comment.
I think preserving path is completely valid behaviour. Nothing should be changed actually.

Thanks!

authors: sergeyreznik zeux

repo: zeux/meshoptimizer

license: MIT


text:
Add openzfs-tracking.sh script

This script is used to dynamically generate the OpenZFS Commit
Tracking page at http://build.zfsonlinux.org/openzfs-tracking.html.

I want to add some comments (links to wiki, etc) and table filter by commit status. Is it better to make new PR after this one or add my commit here?

Improvements are welcome! If you have a better version of the script can you open a new PR with this commit and then your changes applied on top.   Thanks.

@gmelikov actually let me just merge this since it's functional and useful.  This should make it easier for you to open a new PR with your various improvements.

Thanks. The auto-gen. HTML page is cool. Maybe one can integrate the 'scripts/openzfs-exceptions.txt' entries with a different color and a note like 'The OpenZFS commit isn't applicable to Linux'. That way every commit/issue is tracked even it is not applicable to ZoL.
And a question: It is right that the following path 'usr/src/uts/common/fs/zfs'  is twice entered in 'OPENZFS_PATHS=' and 'usr/src/cmd/mdb/common/modules/zfs' and 'usr/src/test/zfs-tests' is missing? Just compare the "Directories of interest for ZFS" in the OpenZFS README.md

@jumbi77 good idea, i'll try to implement it with another things!

authors: behlendorf gmelikov jumbi77

repo: zfsonlinux/zfs-buildbot


text:
Support SwiftPM

Added support of Swift Package Manager.
I removed module.modulemap and DKPhotoGallery.h.
I thought these files are unused, but if it needed, please notice me.

Thanks for your PR!!!


text:
多个公司用的话，数据独立，相同的页面怎么分配权限

版本号：
2.20
问题描述：
多个公司用的话，数据独立，相同的页面怎么分配权限
截图&代码：
😿
友情提示： 未按格式要求发帖，会直接删掉。

通过数据权限控制，或者saas多租户模式
https://github.com/zhangdaiscott/jeecg-boot/issues/166

authors: kevin-lr zhangdaiscott

repo: zhangdaiscott/jeecg-boot


text:
内嵌子表单显示字段越多，多选框及其序号宽度也会增加

版本号：jeecg-boot 2.2
问题描述：
在线表单开发 内嵌子表单  随着子表单字段增多 多选框及其序号宽度也会增加
截图&代码：

友情提示： 未按格式要求发帖，会直接删掉。

已修复


text:
🛑 Omics Rocks is down

In 8fb4d08, Omics Rocks (https://omics.rocks) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Omics Rocks is back up in f740aac after .

repo: zhanxw/upptime


text:
🛑 ZY is down

In 2ed7a83, ZY (https://ziyuan.baidu.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ZY is back up in 0013101.

repo: zhaodylan/uptime-ziyuan


text:
{"message":"Invalid handler specified"}

Could not add integration because of error Config flow could not be loaded: {"message":"Invalid handler specified"}

Logs Home Assistant

Home Assistant Core:
2024.11.3

Hi, thanks for the info. Please update the integration to 1.2.0 and check if the problem is solved!

authors: truongbber zhbjsh

repo: zhbjsh/homeassistant-ssh


text:
The rest subjects of real video datasets

Hello, I notice that the real video dataset consists of 4 subjects. And there are only two of them released. Will you release the rest two subjects for research? Thank you very much.

hey,
no, we are not planning to release more subjects.

authors: yuangan zhengyuf

repo: zhengyuf/IMavatar


text:
TS类型 与文档不一致

🐛 Bug Report

index.d.ts  中的  PlaySource  全部是必传，而文档是可选的
issue  中提到过  autoplay ，源码也有， 但 index.d.ts  没有

还有顺带吐槽一句
PlayerContainerProps 应该导出才用的方便啊

因为后期没太有精力维护 ts 文档（主要我们用不到），欢迎 PR

authors: lancelot-song waltcow xiaoyuhen

repo: zhihu/griffith


text:
About code

hi,Hello, can you ask what version of Pytorch is needed for this code to run?
thanks！

You should be able to run it on the latest pytorch.


text:
project: import prebuilt NCNN for multimodal poc

thanks to NCNN and opencv-mobile, an initial version of AI Agent by NCNN is available in this project at the first time:

all "real/hardcore/interesting" things will be done in native layer(C/C++) and I like this style and thanks to NCNN and opencv-mobile again.

merge to master before validate/verify with a clean clone in fresh directory.

repo: zhouwg/kantv


text:
Fix: Changing time configuration with keyboard did not work - #402

Hi, I fixed the #402.
I would like you to pay attention to the comments in the ConfigSlider.tsx in 2nd commit.
That is something we should fix by making another commit but I wanted to include main developers in this.
Tested on windows portable & installer.
https://github.com/zidoro/pomatez/assets/45315917/cba50181-61f5-4c50-ba02-1643e09df132

Hi, @ziadevcom kindly fix the pre-commit checks, and then I'll merge this PR.
Please read this https://github.com/zidoro/pomatez#pencil-pre-commit.
Thank you! 💪🏼

@roldanjr I am not sure why it's failing.
I tried to download pre-commit & it gave error. It is asking me to download Microsoft build tools.
It's 7GB, I am working from my laptop right now because my computer fried & it's a very light weight machine. It can't afford software like that.

Im surprised its asking for that, i thought you just needed python installed.
The command to dirtily do it should be pre-commit run --all-files

This does not work either. I guess there is no other option than to download 7GB of bloat that I don't need. I am really disappointed that this will be the reason for not being able to push the changes.

It's alright @ziadevcom it's just a minor thing. Maybe @sekwah41 and I will fix this later but for now I'll merge this PR :)
Thank you @ziadevcom 🙇🏼

Thank you @roldanjr @sekwah41
I appreciate it.

authors: roldanjr sekwah41 ziadevcom

repo: zidoro/pomatez


text:
command 'html-css-class-completion.cache' not found

After updating to the newest vsCode 1.21.0-insider the plugin seems not to work anymore, even after fully wiping vsCode and the extension, it now only throws an error when I try to cache css:
command 'html-css-class-completion.cache' not found

Hi @7twin, that's very weird, I just tried the extension on VS Code 1.20.1 and on VS Code 1.21.0-insider, installed the extension on both and tried the automatic initial cache it performs, triggering the cache through the lightning icon and the "> Cache CSS class definition." All those use cases succeeded.
Which version of the extension are you on? The latest version is 1.17.1 from 02/18/2018.

Hi @zignd I am on 1.17.1

Is there any log messages on your Developer Tools (Help > Toggle Developer Tools)? Especially error one. Would you mind posting them here?
Thanks!

@zignd oh, it might have to do with me recently uninstalling node and something getting corrupted along the way? it can't find lodash:
Activating extension 'Zignd.html-css-class-completion' failed: Cannot find module 'lodash'.
Is there any way I could fix this, without reinstalling vscode etc. (including node) again?

Reinstalling node, wiping all extensions from %USERPROFILE%\.vscode-insiders\extensions and reinstalling vsCode solved the issue.

repo: zignd/HTML-CSS-Class-Completion


text:
[Device Support Request] Generic ZigBee bulbs (Gledopto whitelabel?)

I purchased a mix of second hand ZigBee bulbs. They all appear to be an unlabelled version of Gledopto bulbs as they have the same pairing process and appear identical in product shots. I have successfully paired them with ZHA and can turn them on and off from the HA Light Card but have no control over color temperature or brightness in the standard cards (controls which are provided but have no effect).
Going into 'manage zigbee device' from the device menu allows me to fire off zigbee commands that change both the brightness and the color temperature (see images at bottom)
So I know the hardware supports it.
Their Manufacturer is listed as "ZigBee/CCT" and the model as "CCT Light"
Describe the solution you'd like
As they appear to be generic Gledopto bulbs I see 2 possible solutions:

If someone could guide me to how to modify an existing quirk I'll gladly do that
If a generic quirk for this "ZigBee/CCT, CCT Light" were available that would also solve my issue

I have tried to make a custom quirk but it doesn't seem to 'take' even after removing and repairing one of the bulbs.

Device signature
{
  "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice: 142>, manufacturer_code=4137, maximum_buffer_size=127, maximum_incoming_transfer_size=90, server_mask=11264, maximum_outgoing_transfer_size=90, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False)",
  "endpoints": {
    "1": {
      "profile_id": 260,
      "device_type": "0x010c",
      "in_clusters": [
        "0x0000",
        "0x0003",
        "0x0004",
        "0x0005",
        "0x0006",
        "0x0008",
        "0x0300",
        "0x1000",
        "0x100f",
        "0xffff"
      ],
      "out_clusters": [
        "0x0019",
        "0x100f"
      ]
    },
    "242": {
      "profile_id": 41440,
      "device_type": "0x0066",
      "in_clusters": [
        "0x0021"
      ],
      "out_clusters": [
        "0x0021"
      ]
    }
  },
  "manufacturer": "ZigBee/CCT",
  "model": "CCT Light",
  "class": "zigpy.device.Device"
}

Diagnostic information
# I couldn't download diagnostics, it just opens an empty tab, will try again later and post it here if I'm successful

Additional logs
Paste any additional debug logs here.
Don't remove the extra line breaks outside the ``` marks.

Additional context
using this interface lets me change the temperature and

brightness in the standard cards (controls which are provided but have no effect).

Just to confirm, when the light is already on and you're just changing the brightness through the UI, the brightness of the actual bulb does not change at all and the UI also reverts to the old brightness?
Or does the bulb change brightness and the UI just doesn't reflect that?

Please install this as a custom quirk and let me know if it works.

Custom Quirk (click to expand)
"""Quirk for ZigBee/CCT CCT Light."""

from zigpy.profiles import zha
from zigpy.quirks import CustomCluster, CustomDevice
from zigpy.zcl.clusters.general import (
    Basic,
    GreenPowerProxy,
    Groups,
    Identify,
    LevelControl,
    OnOff,
    Ota,
    Scenes,
)
from zigpy.zcl.clusters.lighting import (
    Color,
)
from zigpy.zcl.clusters.lightlink import (
    LightLink,
)
from zhaquirks.const import (
    DEVICE_TYPE,
    ENDPOINTS,
    INPUT_CLUSTERS,
    MODELS_INFO,
    OUTPUT_CLUSTERS,
    PROFILE_ID,
)
from zhaquirks.kof.kof_mr101z import NoReplyMixin

class LevelControlNoReply(NoReplyMixin, CustomCluster, LevelControl):
    """LevelControl cluster that does not require default responses."""

    void_input_commands = {cmd.id for cmd in LevelControl.commands_by_name.values()}

class ZigbeeCctCctLight(CustomDevice):
    """Zigbee/Cct CCT Light custom device implementation."""

    signature = {
        MODELS_INFO: [("ZigBee/CCT", "CCT Light")],
        ENDPOINTS: {
            1: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.COLOR_TEMPERATURE_LIGHT,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    Identify.cluster_id,
                    Groups.cluster_id,
                    Scenes.cluster_id,
                    OnOff.cluster_id,
                    LevelControl.cluster_id,
                    Color.cluster_id,
                    LightLink.cluster_id,
                    0x100F,
                    0xFFFF,
                ],
                OUTPUT_CLUSTERS: [
                    Ota.cluster_id,
                    0x100F,
                ],
            },
            242: {
                PROFILE_ID: 41440,
                DEVICE_TYPE: 0x0066,
                INPUT_CLUSTERS: [
                    GreenPowerProxy.cluster_id,
                ],
                OUTPUT_CLUSTERS: [
                    GreenPowerProxy.cluster_id,
                ],
            },
        },
    }

    replacement = {
        ENDPOINTS: {
            1: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.COLOR_TEMPERATURE_LIGHT,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    Identify.cluster_id,
                    Groups.cluster_id,
                    Scenes.cluster_id,
                    OnOff.cluster_id,
                    LevelControlNoReply,
                    Color.cluster_id,
                    LightLink.cluster_id,
                    0x100F,
                    0xFFFF,
                ],
                OUTPUT_CLUSTERS: [
                    Ota.cluster_id,
                    0x100F,
                ],
            },
            242: {
                PROFILE_ID: 41440,
                DEVICE_TYPE: 0x0066,
                INPUT_CLUSTERS: [
                    GreenPowerProxy.cluster_id,
                ],
                OUTPUT_CLUSTERS: [
                    GreenPowerProxy.cluster_id,
                ],
            },
        },
    }

Hello again,
In a bittersweet development, I plugged the bulbs back in to confirm if the behaviour was "move back to x%" or not and found that the bulbs now properly allow level and color control...
I did upgrade from 2023.3 (version at time of report) to 2023.4 but the bulbs do not report as using a quirk so am not sure if that's the change.
So, while I'm of course happy that they seem to now "just work", I am a little embarrassed at you having spent effort apparently needlessly @TheJulianJES .
In any case, thank you very much for your help and since I've now confirmed that all 4 bulbs work, can close this issue.

authors: TheJulianJES agryson

repo: zigpy/zha-device-handlers


text:
[Device Support Request] Garaze opener TS0601 by _TZE204_nklqjk62

Problem description
Hello,
I bought garage opener and it was not recognized by HA and Sonoff dongle . I found lot of articles about MQTT and HA Addons and how HA Core in docker is bad. That's why I'd like to thank everybody here to this activity.
I'd like to ask you to add garage opener  based on TS0601 from manufacturer _TZE204_nklqjk62.
Solution description
I've made script based on https://github.com/zigpy/zha-device-handlers/issues/1260, which works for me. I just changed model signature.
I'd like to ask about the signal. Currently it's switch, which means that it holds state ON. For controlling gate is used short signal. E.g. push button. Should it be solved by automation or is possible to change definition of signal to simulate push button?
Screenshots/Video
Screenshots/Video
[Paste/upload your media here]

Device signature
Device signature
{
  "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.FullFunctionDevice|MainsPowered|RxOnWhenIdle|AllocateAddress: 142>, manufacturer_code=4417, maximum_buffer_size=66, maximum_incoming_transfer_size=66, server_mask=10752, maximum_outgoing_transfer_size=66, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False)",
  "endpoints": {
    "1": {
      "profile_id": "0x0104",
      "device_type": "0x0051",
      "input_clusters": [
        "0x0000",
        "0x0004",
        "0x0005",
        "0x0006",
        "0xef00"
      ],
      "output_clusters": [
        "0x000a",
        "0x0019"
      ]
    },
    "2": {
      "profile_id": "0x0104",
      "device_type": "0x0402",
      "input_clusters": [
        "0x0500"
      ],
      "output_clusters": []
    },
    "242": {
      "profile_id": "0xa1e0",
      "device_type": "0x0061",
      "input_clusters": [],
      "output_clusters": [
        "0x0021"
      ]
    }
  },
  "manufacturer": "_TZE204_nklqjk62",
  "model": "TS0601",
  "class": "garage2.TuyaGarageSwitchTO"
}

Diagnostic information
Diagnostic information
{
  "home_assistant": {
    "installation_type": "Home Assistant Container",
    "version": "2023.11.2",
    "dev": false,
    "hassio": false,
    "virtualenv": false,
    "python_version": "3.11.6",
    "docker": true,
    "arch": "aarch64",
    "timezone": "Europe/Belgrade",
    "os_name": "Linux",
    "os_version": "5.15.74-v8+",
    "run_as_root": true
  },
  "custom_components": {
    "hacs": {
      "version": "1.32.1",
      "requirements": [
        "aiogithubapi>=22.10.1"
      ]
    }
  },
  "integration_manifest": {
    "domain": "zha",
    "name": "Zigbee Home Automation",
    "after_dependencies": [
      "onboarding",
      "usb"
    ],
    "codeowners": [
      "@dmulcahey",
      "@adminiuga",
      "@puddly"
    ],
    "config_flow": true,
    "dependencies": [
      "file_upload"
    ],
    "documentation": "https://www.home-assistant.io/integrations/zha",
    "iot_class": "local_polling",
    "loggers": [
      "aiosqlite",
      "bellows",
      "crccheck",
      "pure_pcapy3",
      "zhaquirks",
      "zigpy",
      "zigpy_deconz",
      "zigpy_xbee",
      "zigpy_zigate",
      "zigpy_znp",
      "universal_silabs_flasher"
    ],
    "requirements": [
      "bellows==0.36.8",
      "pyserial==3.5",
      "pyserial-asyncio==0.6",
      "zha-quirks==0.0.106",
      "zigpy-deconz==0.21.1",
      "zigpy==0.59.0",
      "zigpy-xbee==0.19.0",
      "zigpy-zigate==0.11.0",
      "zigpy-znp==0.11.6",
      "universal-silabs-flasher==0.0.14",
      "pyserial-asyncio-fast==0.11"
    ],
    "usb": [
      {
        "vid": "10C4",
        "pid": "EA60",
        "description": "*2652*",
        "known_devices": [
          "slae.sh cc2652rb stick"
        ]
      },
      {
        "vid": "1A86",
        "pid": "55D4",
        "description": "*sonoff*plus*",
        "known_devices": [
          "sonoff zigbee dongle plus v2"
        ]
      },
      {
        "vid": "10C4",
        "pid": "EA60",
        "description": "*sonoff*plus*",
        "known_devices": [
          "sonoff zigbee dongle plus"
        ]
      },
      {
        "vid": "10C4",
        "pid": "EA60",
        "description": "*tubeszb*",
        "known_devices": [
          "TubesZB Coordinator"
        ]
      },
      {
        "vid": "1A86",
        "pid": "7523",
        "description": "*tubeszb*",
        "known_devices": [
          "TubesZB Coordinator"
        ]
      },
      {
        "vid": "1A86",
        "pid": "7523",
        "description": "*zigstar*",
        "known_devices": [
          "ZigStar Coordinators"
        ]
      },
      {
        "vid": "1CF1",
        "pid": "0030",
        "description": "*conbee*",
        "known_devices": [
          "Conbee II"
        ]
      },
      {
        "vid": "10C4",
        "pid": "8A2A",
        "description": "*zigbee*",
        "known_devices": [
          "Nortek HUSBZB-1"
        ]
      },
      {
        "vid": "0403",
        "pid": "6015",
        "description": "*zigate*",
        "known_devices": [
          "ZiGate+"
        ]
      },
      {
        "vid": "10C4",
        "pid": "EA60",
        "description": "*zigate*",
        "known_devices": [
          "ZiGate"
        ]
      },
      {
        "vid": "10C4",
        "pid": "8B34",
        "description": "*bv 2010/10*",
        "known_devices": [
          "Bitron Video AV2010/10"
        ]
      }
    ],
    "zeroconf": [
      {
        "type": "_esphomelib._tcp.local.",
        "name": "tube*"
      },
      {
        "type": "_zigate-zigbee-gateway._tcp.local.",
        "name": "*zigate*"
      },
      {
        "type": "_zigstar_gw._tcp.local.",
        "name": "*zigstar*"
      },
      {
        "type": "_uzg-01._tcp.local.",
        "name": "uzg-01*"
      },
      {
        "type": "_slzb-06._tcp.local.",
        "name": "slzb-06*"
      }
    ],
    "is_built_in": true
  },
  "data": {
    "ieee": "**REDACTED**",
    "nwk": 3607,
    "manufacturer": "_TZE204_nklqjk62",
    "model": "TS0601",
    "name": "_TZE204_nklqjk62 TS0601",
    "quirk_applied": true,
    "quirk_class": "garage2.TuyaGarageSwitchTO",
    "quirk_id": null,
    "manufacturer_code": 4417,
    "power_source": "Mains",
    "lqi": 136,
    "rssi": -66,
    "last_seen": "2023-11-14T19:33:01",
    "available": true,
    "device_type": "Router",
    "signature": {
      "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.FullFunctionDevice|MainsPowered|RxOnWhenIdle|AllocateAddress: 142>, manufacturer_code=4417, maximum_buffer_size=66, maximum_incoming_transfer_size=66, server_mask=10752, maximum_outgoing_transfer_size=66, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False)",
      "endpoints": {
        "1": {
          "profile_id": "0x0104",
          "device_type": "0x0051",
          "input_clusters": [
            "0x0000",
            "0x0004",
            "0x0005",
            "0x0006",
            "0xef00"
          ],
          "output_clusters": [
            "0x000a",
            "0x0019"
          ]
        },
        "2": {
          "profile_id": "0x0104",
          "device_type": "0x0402",
          "input_clusters": [
            "0x0500"
          ],
          "output_clusters": []
        },
        "242": {
          "profile_id": "0xa1e0",
          "device_type": "0x0061",
          "input_clusters": [],
          "output_clusters": [
            "0x0021"
          ]
        }
      },
      "manufacturer": "_TZE204_nklqjk62",
      "model": "TS0601"
    },
    "active_coordinator": false,
    "entities": [
      {
        "entity_id": "binary_sensor.tze204_nklqjk62_ts0601_otevirani",
        "name": "_TZE204_nklqjk62 TS0601"
      },
      {
        "entity_id": "switch.tze204_nklqjk62_ts0601_vypinac",
        "name": "_TZE204_nklqjk62 TS0601"
      }
    ],
    "neighbors": [],
    "routes": [],
    "endpoint_names": [
      {
        "name": "SMART_PLUG"
      },
      {
        "name": "IAS_ZONE"
      },
      {
        "name": "PROXY_BASIC"
      }
    ],
    "user_given_name": null,
    "device_reg_id": "ab2a607861149a011b7490213674e86b",
    "area_id": "garaz_2",
    "cluster_details": {
      "1": {
        "device_type": {
          "name": "SMART_PLUG",
          "id": 81
        },
        "profile_id": 260,
        "in_clusters": {
          "0x0000": {
            "endpoint_attribute": "basic",
            "attributes": {
              "0x0001": {
                "attribute_name": "app_version",
                "value": 74
              }
            },
            "unsupported_attributes": {}
          },
          "0x0004": {
            "endpoint_attribute": "groups",
            "attributes": {},
            "unsupported_attributes": {}
          },
          "0x0005": {
            "endpoint_attribute": "scenes",
            "attributes": {},
            "unsupported_attributes": {}
          },
          "0xef00": {
            "endpoint_attribute": "tuya_manufacturer",
            "attributes": {
              "0xef0b": {
                "attribute_name": "dp_11",
                "value": 0
              },
              "0xef0c": {
                "attribute_name": "dp_12",
                "value": 1
              },
              "0xef02": {
                "attribute_name": "dp_2",
                "value": 0
              },
              "0xef04": {
                "attribute_name": "dp_4",
                "value": 10
              },
              "0xef05": {
                "attribute_name": "dp_5",
                "value": 3600
              },
              "0xef00": {
                "attribute_name": "mcu_version",
                "value": "1.0.0"
              }
            },
            "unsupported_attributes": {}
          },
          "0x0006": {
            "endpoint_attribute": "on_off",
            "attributes": {
              "0x0000": {
                "attribute_name": "on_off",
                "value": 0
              }
            },
            "unsupported_attributes": {
              "0x0000": {
                "attribute_name": "on_off"
              },
              "0x4003": {
                "attribute_name": "start_up_on_off"
              }
            }
          }
        },
        "out_clusters": {
          "0x000a": {
            "endpoint_attribute": "time",
            "attributes": {},
            "unsupported_attributes": {}
          },
          "0x0019": {
            "endpoint_attribute": "ota",
            "attributes": {},
            "unsupported_attributes": {}
          }
        }
      },
      "2": {
        "device_type": {
          "name": "IAS_ZONE",
          "id": 1026
        },
        "profile_id": 260,
        "in_clusters": {
          "0x0500": {
            "endpoint_attribute": "ias_zone",
            "attributes": {
              "0x0010": {
                "attribute_name": "cie_addr",
                "value": [
                  202,
                  142,
                  168,
                  254,
                  255,
                  141,
                  121,
                  224
                ]
              },
              "0x0002": {
                "attribute_name": "zone_status",
                "value": 0
              },
              "0x0001": {
                "attribute_name": "zone_type",
                "value": 21
              }
            },
            "unsupported_attributes": {
              "0x0000": {
                "attribute_name": "zone_state"
              },
              "0x0002": {
                "attribute_name": "zone_status"
              }
            }
          }
        },
        "out_clusters": {}
      },
      "242": {
        "device_type": {
          "name": "PROXY_BASIC",
          "id": 97
        },
        "profile_id": 41440,
        "in_clusters": {},
        "out_clusters": {
          "0x0021": {
            "endpoint_attribute": "green_power",
            "attributes": {},
            "unsupported_attributes": {}
          }
        }
      }
    }
  }
}

Logs
Logs
[Paste the logs here]

Custom quirk
Custom quirk
"""Tuya based cover and blinds."""
from typing import Dict

from zigpy.profiles import zha
from zigpy.quirks import CustomDevice
import zigpy.types as t
from zigpy.zcl.clusters.general import Basic, GreenPowerProxy, Groups, Ota, Scenes, Time
from zigpy.zcl.clusters.security import IasZone

from zhaquirks.const import (
    DEVICE_TYPE,
    ENDPOINTS,
    INPUT_CLUSTERS,
    MODELS_INFO,
    OUTPUT_CLUSTERS,
    PROFILE_ID,
)

from zhaquirks.tuya import NoManufacturerCluster, TuyaLocalCluster
from zhaquirks.tuya.mcu import (
    DPToAttributeMapping,
    TuyaMCUCluster,
    TuyaOnOff,
    TuyaOnOffNM,
)

ZONE_TYPE = 0x0001

class ContactSwitchCluster(TuyaLocalCluster, IasZone):
    """Tuya ContactSwitch Sensor."""
    _CONSTANT_ATTRIBUTES = {ZONE_TYPE: IasZone.ZoneType.Contact_Switch}

class TuyaGarageManufCluster(NoManufacturerCluster, TuyaMCUCluster):
    """Tuya garage door opener."""
    attributes = TuyaMCUCluster.attributes.copy()
    attributes.update(
        {
            # ramdom attribute IDs
            0xEF02: ("dp_2", t.uint32_t, True),
            0xEF04: ("dp_4", t.uint32_t, True),
            0xEF05: ("dp_5", t.uint32_t, True),
            0xEF0B: ("dp_11", t.Bool, True),
            0xEF0C: ("dp_12", t.enum8, True),
        }
    )

    dp_to_attribute: Dict[int, DPToAttributeMapping] = {
        # garage door trigger ¿on movement, on open, on closed?
        1: DPToAttributeMapping(
            TuyaOnOffNM.ep_attribute,
            "on_off"
        ),
        2: DPToAttributeMapping(
            TuyaMCUCluster.ep_attribute,
            "dp_2"
        ),
        3: DPToAttributeMapping(
            ContactSwitchCluster.ep_attribute,
            "zone_status",
            #TuyaDPType.BOOL,
            lambda x: IasZone.ZoneStatus.Alarm_1 if x else 0,
            endpoint_id=2,
        ),
        4: DPToAttributeMapping(
            TuyaMCUCluster.ep_attribute,
            "dp_4"
        ),
        5: DPToAttributeMapping(
            TuyaMCUCluster.ep_attribute,
            "dp_5"
        ),
        11: DPToAttributeMapping(
            TuyaMCUCluster.ep_attribute,
            "dp_11"
        ),
        # garage door status (open, closed, ...)
        12: DPToAttributeMapping(
            TuyaMCUCluster.ep_attribute,
            "dp_12"
        ),
    }

    data_point_handlers = {
        1: "_dp_2_attr_update",
        2: "_dp_2_attr_update",
        3: "_dp_2_attr_update",
        4: "_dp_2_attr_update",
        5: "_dp_2_attr_update",
        11: "_dp_2_attr_update",
        12: "_dp_2_attr_update",
    }

class TuyaGarageSwitchTO(CustomDevice):
    """Tuya Garage switch."""

    signature = {
        MODELS_INFO: [
            ("_TZE204_nklqjk62", "TS0601"),
#            ("_TZE200_wfxuhoea", "TS0601"),
        ],
        ENDPOINTS: {
            # <SimpleDescriptor endpoint=1 profile=260 device_type=0x0051
            # input_clusters=[0, 4, 5, 61184]
            # output_clusters=[10, 25]>
            1: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.SMART_PLUG,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    Groups.cluster_id,
                    Scenes.cluster_id,
                    TuyaGarageManufCluster.cluster_id,
                ],
                OUTPUT_CLUSTERS: [Time.cluster_id, Ota.cluster_id],
            },
            # <SimpleDescriptor endpoint=242 profile=41440 device_type=97
            # input_clusters=[]
            # output_clusters=[33]
            242: {
                PROFILE_ID: 41440,
                DEVICE_TYPE: 97,
                INPUT_CLUSTERS: [],
                OUTPUT_CLUSTERS: [GreenPowerProxy.cluster_id],
            },
        },
    }

    replacement = {
        ENDPOINTS: {
            1: {
                DEVICE_TYPE: zha.DeviceType.SMART_PLUG,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    Groups.cluster_id,
                    Scenes.cluster_id,
                    TuyaGarageManufCluster,
                    TuyaOnOffNM,
                ],
                OUTPUT_CLUSTERS: [Time.cluster_id, Ota.cluster_id],
            },
            2: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.IAS_ZONE,
                INPUT_CLUSTERS: [
                    ContactSwitchCluster
                ],
                OUTPUT_CLUSTERS: [],
            },
            242: {
                PROFILE_ID: 41440,
                DEVICE_TYPE: 97,
                INPUT_CLUSTERS: [],
                OUTPUT_CLUSTERS: [GreenPowerProxy.cluster_id],
            },
        },
    }

Additional information
Thank you in advance!

Hi there,
I have the same TS0601 by _TZE204_nklqjk62 via Sonoff dongle and ZHA
would be good for others if we could make it work without a Zigbee Quirk

yup i have 2 of these as well, going through the setup right now, would be better if it was streamlined a little

authors: BrtnikFM lNOFXl xxrb86


text:
Rename update to async_update for consistency

SSIA

Does this need any changes in Core?

Does this need any changes in Core?

I still have to look but I don’t think so.

Shouldn't need any changes in core: homeassistant/components/zha/entity.py#L137-L141 (and don't see update() being called anywhere else either)

thx. I just double checked as well and I agree.

authors: dmulcahey puddly

repo: zigpy/zha


text:
get_sequence_output is not contextualized

Hi,
I finally managed to use get_sequence_output to get word embeddings after dealing with random embeddings due to dropout, random seed, etc.
However, get_sequence_output() doesn't seem to be contextualized. If you have a string that says 'Bank river.' and get the embeddings for Bank, and try another one with Bank robber.', the embeddings for Bankis identical in both tests. In BERT and other contextualized transformers, theBank` has a different vector since the context is not the same.
I tried to play around with a mask, segments, etc. but it's always the same embeddings for a given word in different contexts. I followed the advice, some examples, etc. and the following is my configs:
xlnetConfig = XLNetConfig(FLAGS=None, json_path=json_path)
xlnetRunConfig = RunConfig(
        is_training=False,
        use_tpu=False,
        use_bfloat16=False,
        dropout=0.0,
        dropatt=0.0
)

Even though I've seen some examples using 0.1 for dropout like here, but they have random embeddings issue: https://github.com/amansrivastava17/embedding-as-service/tree/master/server/embedding_as_service/text/xlnet using
Are my XLNet config and run config correct to use the pre-trained weights/checkpoints?

Unfortunately, I couldn't find any solution. It seems for some reason (could be totally my mistake) the XLnet pre-trained models are not aware of their surrounding tokens. So no matter what you put before or after unlike BERT it will always generate the same vectors.

repo: zihangdai/xlnet


text:
Installation is broken with the latest released minor version minio==7.2.2

Getting errors during startup, due to this: https://github.com/minio/minio-py/issues/1378.
I had to manually specify minio==7.2.0 to make it work.

The minio of pymilvus conflicts with the urllib3 dependency in requests==2.26.0 that milvus_cli depends on.
Will try to fix it in next release

authors: nameczz o-nix


text:
Upgrading graphql to 3.0.2 breaks subscriptions

Describe the bug
The subscriptions worked fine with package version 3.0.1-beta.2 of graphql. Upgrading to 3.0.2 made my subscriptions throw the following error:
Connecting to VM Service at ws://localhost:1025/ws[log] Logged in!
flutter: Connecting to websocket: ws://<serverURL>
flutter: Connected to websocket.
flutter: There was an error causing connection lost: Converting object to an encodable object failed: Instance of 'InitOperation'
flutter: Disconnected from websocket.
flutter: Scheduling to connect in 5 seconds...
flutter: Caught error: NoSuchMethodError: The method 'where' was called on null.
Receiver: null
Tried calling: where(Closure: (GraphQLSocketMessage) => bool)
flutter: #0      Object.noSuchMethod  (dart:core-patch/object_patch.dart:53:5)
#1      SocketClient.subscribe.<anonymous closure>.<anonymous closure>
package:graphql/src/socket_client.dart:284
[...]

The debug console points the issue at file graphql-3.0.2/lib/src/socket_client.dart:284
To Reproduce
I have the following scenario:
String serverURL = "<serverURL>",
String subscriptionURL = "<subscriptionURL>";

HttpClient httpClient = HttpClient();

final httpLink = HttpLink(
  uri: serverURL,
  httpClient: ioClient,
);

final authLink = AuthLink(
  getToken: () async => 'Bearer $_token',
);

final webSocketLink = WebSocketLink(
  url: subscriptionURL,
  config: SocketClientConfig(
    autoReconnect: true,
    inactivityTimeout: Duration(minutes: 5),
    initPayload: () => {'api-key': _token},
  ),
);

final link = Link.from([authLink, httpLink, webSocketLink]);

return GraphQLClient(
  cache: NormalizedInMemoryCache(
    dataIdFromObject: typenameDataIdFromObject,
  ),
  link: link,
);

And later on, create my subscription like so:
Stream<Project> subscribeProject(String projectId) async* {
  final subOperation = Operation(
    documentNode: gql(Subscriptions.SubscribeProject),
    variables: {'id': projectId},
  );

  await for (FetchResult result in gqlClient.subscribe(subOperation)) {
    try {
      yield Project.fromJson(result.data['project']);
    } catch (e) {
      debugPrint(e);
    }
  }
}

Expected behavior
Do not see an error stacktrace.
Flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, v1.17.2, on Mac OS X 10.15.4 19E287, locale en-CA)
[!] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
    ✗ Android SDK file not found: adb.
[✓] Xcode - develop for iOS and macOS (Xcode 11.4.1)
[!] Android Studio (version 3.5)
    ✗ Flutter plugin not installed; this adds Flutter specific functionality.
    ✗ Dart plugin not installed; this adds Dart specific functionality.
[✓] VS Code (version 1.45.1)
[✓] Connected device (1 available)

! Doctor found issues in 2 categories.

initPayload should be a literal value ({'api-key': _token}) and not a callback (() => {'api-key': _token}) which is why this is failing to serialize initially.
Going through the diff (even against master) I don't think there's a particular change causing this: https://github.com/zino-app/graphql-flutter/compare/v3.0.1-beta.2...master. The error could certainly be clearer though

@micimize Has any example how to use initialPayload with async data? Like AuthLink with getToken?

@micimize Has any example how to use initialPayload with async data? Like AuthLink with getToken?
Before version 4.0.0-alpha.0, I used it like this:
final WebSocketLink websocketLink = WebSocketLink(
  subscriptionUri,
  config: SocketClientConfig(
    autoReconnect: true,
    inactivityTimeout: Duration(seconds: 30),
    initPayload: () async {
      final String token = await Hive.box('auth').get('token');

      if (token == null || token.isEmpty) return {};

      return {
        "headers": {"Authorization": 'Bearer ' + token}
      };
    },
  ),
);

@RodolfoSilva sorry – amended my comment above. Looks like we need to apply the async initialPayload handling logic from beta to gql_websocket_link

Thanks @micimize

@micimize I send a PR. (https://github.com/gql-dart/gql/pull/122)

Any idea when this fix will make its way into master?

@NotHolst,
I think @micimize is waiting @klavs

4.0.0-alpha.6 revived the old WebSocketLink and should resolve this

authors: NotHolst RodolfoSilva gtupak micimize

repo: zino-app/graphql-flutter


text:
cannot use context headers in GraphQL's subscription function.

Is my code.
final WebSocketLink websocketLink = WebSocketLink(
      'test',
      config: SocketClientConfig(
        initialPayload: {
          "headers": {},
        },
      ),
    );

I don't want to use headers in the code above.
Please look at the code below.
SubscriptionOptions(
            operationName: 'messages',
            document: gql(r'''
              subscription messages($where: messages_bool_exp!) {
                messages(where: $where) {
                  ...messagesFragment
                }
              }
                ''' +
                fragments +
                '''
            '''),
            variables: {
              "where": {
                "id": {
                  "_eq": "test",
                },
              },
            },
            fetchPolicy: FetchPolicy.cacheAndNetwork,
            context: Context().withEntry(
              HttpLinkHeaders(
                headers: headers(idToken),
              ),
            ),
          );

Here I want to add a header to the context.
For general queries other than subscriptions, the context header works fine.
error message : cannot start as connection_init failed with : Missing Authorization header in JWT authentication mode.

This is a known issue – you can use this workaround in the meantime

Thanks for the answer but it's not the workaround I want

@micimize the workaround works amazing. will headers  be added in the next WSLink?

@kateile after seeing the null safety v5 release to a stable version (along with its dependencies in the gql project), I do not plan on making any more feature or improvement contributions. Aside from the reasons I mentioned in #763, I have stopped using GraphQL in my own project and unfortunately it no longer makes sense for me to continue contributing here.
I haven't seen @HofmannZ or @eusdima around here in a long time so unless someone else steps in as active maintainer this project can be considered in low maintenance mode. Some people have expressed some interest in contributing in #762 but we'll see. Hopefully when I get around to the walkthrough vid it will help users PR fixes to their own problems.

@vincenzopalazzo can we solve this too in the coming updates?

Hi @kateile, these are some things that I can put in the queue, but do you test it with the last version of the package?
If yes, could you please propose a reproducible example?

@vincenzopalazzo this is more an API tweak for how to provide headers to the WebSocketLink. In essence, it would be adding a parameter to the default connect parameter, rather than requiring overriding it, so that a user could do the following:
SocketClientConfig(
  ...
- connect: (url, protocols) =>
-   IOWebSocketChannel.connect(url, protocols: protocols, headers: myCustomHeaders)
+ headers: myCustomHeaders
)

I implemented the feature suggested by @micimize (BTW thanks), in the following PR https://github.com/zino-hofmann/graphql-flutter/pull/1016
I'm releasing the new beta version (beta.6), so we will be happy to receive feedback from the users

Thank you very much. I will always support you!

authors: kateile kim-mini6 micimize vincenzopalazzo

repo: zino-hofmann/graphql-flutter


text:
Update http4s-dsl to 0.23.5

Updates org.http4s:http4s-dsl from 0.21.30 to 0.23.5.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Applied Migrations

github:http4s/http4s/v0_22?sha=v0.22.0

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.http4s", artifactId = "http4s-dsl" } ]

labels: library-update, semver-minor, scalafix-migrations

Superseded by #459.

repo: zio/zio-json