text:
zephyr/zephyr/cmake/modules/dts.cmake:366 [...]: No such file or directory

Describe the bug
When running west build, the process stops with an error
To Reproduce
Steps to reproduce the behavior:

west build -p -b litex_vexriscv zephyr/samples/subsys/shell/shell_module

Expected behavior
The build runs to completion.
Impact
Showstopper (no zephyr.bin).
Logs and console output
$ python3 -m west build zephyr_clnx
-- west build: generating a build system
Loading Zephyr default modules (Zephyr base (cached)).
[redacted]
-- Including generated dts.cmake file: /.../zephyr/build/zephyr/dts.cmake
CMake Error at /.../zephyr/zephyr/cmake/modules/dts.cmake:366 (message):
  command failed with return code: No such file or directory
Call Stack (most recent call first):
  /.../zephyr/zephyr/cmake/modules/zephyr_default.cmake:129 (include)
  /.../zephyr/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:66 (include)
  /.../zephyr/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:97 (include_boilerplate)
  CMakeLists.txt:7 (find_package)

-- Configuring incomplete, errors occurred!
FATAL ERROR: command exited with status 1: /usr/bin/cmake -DWEST_PYTHON=/.../.venv/bin/python3 -B/.../zephyr/build -GNinja -S/.../zephyr/zephyr_clnx
make: *** [Makefile:105: zephyr/build/zephyr/zephyr.bin] Error 1

Environment (please complete the following information):

OS: Linux vm1 6.1.0-12-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.52-1 (2023-09-07) x86_64 GNU/Linux
Toolchain zephyr-sdk-0.16.3-rc1
Commit SHA: 7fca0aa8a6932bfd599552cd17be7b0d1d16b407

It also happened on this system, with the native toolchain (riscv-none-elf-):
Linux lap1 6.1.46-0-lts #1-Alpine SMP PREEMPT_DYNAMIC Thu, 17 Aug 2023 14:11:55 +0000 x86_64 Linux
Additional context
I only open this so that the error message shows-up in the issue search. :)

I'll bet you anything in the part you've handily covered up with [redacted] is a message that reads something like "You have not provided a board using BOARD=x, this will likely fail"

Sorry for involving your time, I planned to provide a message with the solution right away, but had a call immediately and did not have time to provide a proper open reproducer, which would have been allowing you to reproduce.
Perhaps I should have been waiting to have the reproducer before reporting...
I do have that message you mentioned!
The CMakeLists.txt is indeed providing the board rather than the command line.
Even without the warning, this appeared to be working lately, but switching to another environment and pulling  from a few Zephyr repos seemed to change the behavior.
With strace, I noticed this:
[pid 13587] execve("/.../zephyr/zephyr-sdk-0.16.3-rc1/sysroots/x86_64-pokysdk-linux/usr/bin/dtc", ["/.../z"..., "-Wunique_unit_address_if_enabled", "-v"], 0x7ffe28abb488 /* 29 vars */) = -1 ENOENT (No such file or directory)
[pid 13587] write(10, "No such file or directory", 25) = 25
[pid 13587] exit_group(1)               = ?
[pid 13567] <... read resumed>"", 1)    = 0
[pid 13567] close(11)                   = 0
[pid 13567] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 13567] read(9, "No such file or directory", 1024) = 25
[pid 13567] read(9, "", 999)            = 0
[pid 13567] close(9)                    = 0
[pid 13567] kill(13587, SIGSTOP)        = 0
[pid 13567] openat(AT_FDCWD, "/proc", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 9
...

So it appears that the "No such file or directory" is coming from the lack of the dtc command... Or problem related to dynamic libraries.
Either way, I will provide a reproducer soon. Thank you for your time and apologies for this incomplete bug report!

This might be related to my Zephyr-SDK:
vm1$ dtc --version
Version: DTC 1.6.1
vm1$ zephyr-sdk-0.16.3-rc1/sysroots/x86_64-pokysdk-linux/usr/bin/dtc --version
-bash: zephyr-sdk-0.16.3-rc1/sysroots/x86_64-pokysdk-linux/usr/bin/dtc: cannot execute: required file not found
vm1$127

Here is the full log (thanks to the power of sed!)
(venv) vm1$ west build -p -b litex_vexriscv zephyr_clnx 2>&1 | sed 's,path_with_the_project_name_not_so_confidential_but_well,...,g'
-- west build: making build dir /.../zephyr/build pristine
-- west build: generating a build system
Loading Zephyr default modules (Zephyr base).
-- Application: /.../zephyr/zephyr_clnx
-- CMake version: 3.25.1
-- Found Python3: /.../.venv/bin/python3 (found suitable version "3.11.2", minimum required is "3.8") found components: Interpreter
-- Cache files will be written to: /home/tinyvision/.cache/zephyr
-- Zephyr version: 3.4.99 (/.../zephyr/zephyr)
-- Found west (found suitable version "1.1.0", minimum required is "0.14.0")
-- Board: litex_vexriscv
-- ZEPHYR_TOOLCHAIN_VARIANT not set, trying to locate Zephyr SDK
-- Found host-tools: zephyr 0.16.3 (/.../zephyr/zephyr-sdk-0.16.3-rc1)
-- Found toolchain: zephyr 0.16.3 (/.../zephyr/zephyr-sdk-0.16.3-rc1)
-- Found Dtc: /.../zephyr/zephyr-sdk-0.16.3-rc1/sysroots/x86_64-pokysdk-linux/usr/bin/dtc (Required is at least version "1.4.6")
-- Found BOARD.dts: /.../zephyr/zephyr/boards/riscv/litex_vexriscv/litex_vexriscv.dts
-- Found devicetree overlay: app.overlay
-- Found devicetree overlay: litex.overlay
-- Generated zephyr.dts: /.../zephyr/build/zephyr/zephyr.dts
-- Generated devicetree_generated.h: /.../zephyr/build/zephyr/include/generated/devicetree_generated.h
-- Including generated dts.cmake file: /.../zephyr/build/zephyr/dts.cmake
CMake Error at /.../zephyr/zephyr/cmake/modules/dts.cmake:366 (message):
  command failed with return code: No such file or directory
Call Stack (most recent call first):
  /.../zephyr/zephyr/cmake/modules/zephyr_default.cmake:129 (include)
  /.../zephyr/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:66 (include)
  /.../zephyr/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:92 (include_boilerplate)
  CMakeLists.txt:7 (find_package)

-- Configuring incomplete, errors occurred!
FATAL ERROR: command exited with status 1: /usr/bin/cmake -DWEST_PYTHON=/.../.venv/bin/python3 -B/.../zephyr/build -GNinja -DBOARD=litex_vexriscv -S/.../zephyr/zephyr_clnx
(venv) vm1$

Ah, a new SDK published 4 days ago. Downloading and trying again now...

yes I did which did not affect the out come (but thank you for the suggestion).
The problem was closely related!
It appears that something wrong went with the SDK installation, and running the setup again fixed it for me:
(venv) vm1$ cd zephyr-sdk-0.16.3
(venv) vm1$ bash setup.sh -h
Zephyr SDK 0.16.3 Setup

Installing host tools ...

All done.
(venv) vm1$ sysroots/x86_64-pokysdk-linux/usr/bin/dtc --version
Version: DTC 1.6.0-dirty
(venv) vm1$

So reinstalling the host tools fixed the issue! \o/
It is possible that my installation was interrupted on the first attempt, or that anything else caused that issue.
This shows that in case the host tools have some problem, dts.cmake might be the first one to complain (through failed invocation of dtc).

Thank you everyone! The bug was not related to Zephyr in the end, but to one particular host/setup (me).
Closing this :)

authors: josuah thedjnK


text:
posix: implement fopen()

This is part of the See POSIX Roadmap for LTSv3 (RFC #51211).
fopen() is required as part of POSIX_DEVICE_IO Subprofiling Option Group.
For more information, please refer to https://pubs.opengroup.org/onlinepubs/9699919799/functions/fopen.html

Implementing this should fix #66132
cc @carlescufi

Hi @cfriedt , I would like to implement this as well (and bunch of other posix methods like fclose, foef, ferror, and modifying fwrite)  since I'm already working on implementing the fread. Thanks!

Hi @stephanosio, Have you already started coding? I'd like to help you by working on this problem. Thanks !

Hi @stephanosio, Have you already started coding? I'd like to help you by working on this problem. Thanks !

@brosier01 - feel free to get started. I think what we'll need is a zvfs_fopen() syscall. A libc fopen() call would just be a wrapper around the syscall.

source: gharchive/issue

authors: RAJAGOPALAN-GANGADHARAN brosier01 cfriedt ycsin

repo: zephyrproject-rtos/zephyr

license_type: permissive

license_source: github-api


text:
[DNM] shell: shell_uart: add ring_buffers and interrupt support

Improved RX path to use ring buffer for incoming data instead of single
byte buffer. Improved TX path to use ring buffer. Added support for
asynchronous UART API (interrupts).
Signed-off-by: Krzysztof Chruscinski krzysztof.chruscinski@nordicsemi.no

Codecov Report

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

@@           Coverage Diff           @@
##           master   #10923   +/-   ##
=======================================
  Coverage    53.3%    53.3%
=======================================
  Files         215      215
  Lines       25900    25900
  Branches     5708     5708
=======================================
  Hits        13805    13805
  Misses       9776     9776
  Partials     2319     2319

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 7b4b7f5...4c71928. Read the comment docs.

It is rebased on #10924, added DNM label which i will remove one #10924 is merged.

sample net/echo_server with netusb with log and shell enable is near its ROM limits (~99% of ROM used) on quark_se_c1000 so any increase is causing compilation failure. I already hit that in #10794 and now here. Here i solved it by disabling built-in commands in shell to save some bytes (~1k). On this branch it is now at 98,05% but this approach will not fly for long. @jukkar what would you suggest for long term?

One easy way to lower the memory consumption is to lower network buffer count, but there is also a limit there after which the device is not very usable from networking point of view. What this limit is depends lot of use cases.
@finikorg has been tweaking the netusb stuff lately with this board, do you have any suggestions for lowering memory?

So, as usual, this just duplicates effort of subsys/console, instead of reusing and improving it. Well, let there be parallel pathways, until they intersect. I'll be happy to give +1 when same is done to my piece, https://github.com/zephyrproject-rtos/zephyr/pull/10765 ;-).
And please specify which boards were tested with this patch - we can expect it's not working with some (or more). (That's also the reason why I don't want to make too much changes at once in #10765 - currently refactor leaves alone (mostly) known-good ISR handling).

@pfalcon

So, as usual, this just duplicates effort of subsys/console, instead of reusing and improving it. Well, let there be parallel pathways, until they intersect. I'll be happy to give +1 when same is done to my piece, #10765 ;-).

Yes, it was started weeks before #10765 was public. I expect they will intersect at some point. I accept you offer: you got +1 for #10765, i'm waiting for mine :).

And please specify which boards were tested with this patch - we can expect it's not working with some (or more). (That's also the reason why I don't want to make too much changes at once in #10765 - currently refactor leaves alone (mostly) known-good ISR handling).

Tested on nrf52. ISR UART backend is use by default if platform supports uart with interrupts. Will see how many uarts implements interrupts correctly.

One easy way to lower the memory consumption is to lower network buffer count, but there is also a limit there after which the device is not very usable from networking point of view. What this limit is depends lot of use cases.
@finikorg has been tweaking the netusb stuff lately with this board, do you have any suggestions for lowering memory?

I am afraid I took too rough approach disabling IPv6 ;)

@nordic-krch:

And please specify which boards were tested with this patch

Tested on nrf52. ISR UART backend is use by default if platform supports uart with interrupts.

For references, subsys/console when was written was tested at least on arduino_101 (that's a "different" beast), frdm_k64f, 96b_carbon (these are about the same). Testing included being able to paste more than the rx buffer. That was one of the prompting point and requirement for subsys/console - it was developed for MicroPython porting, and it has "paste mode", which allows you to copy and paste code from a host file, manual, etc. That's the most practical way small-scale repeated interaction, and before subsys/console, nothing in Zephyr allowed pastes to work reliably.

Will see how many uarts implements interrupts correctly.

We now have report (https://github.com/zephyrproject-rtos/zephyr/issues/10726) that subsys/console glitches on a particular STM32 chip. And as subsys/console is just a generic produces/consumer queues + ISR, then the problem would be either in UART driver, or that this particular chip has IRQ process not fitting into the model (and I spent enough time to chart what would be the appropriate IRQ handling model for UART drivers, again, it work for as diverse cases as 16550 (arduino_101) and common single-byte RX/TX regs as a baselines for ARM chips). My current mental solution for that is console/subsys (to be upgraded to ring_buffer, like here) is a reference, baseline implementation. It should move to drivers/serial, and a particular driver can either use it, or can override completely. All that are just draft thoughts, should be considered for interaction with https://github.com/zephyrproject-rtos/zephyr/pull/10820, etc.

@jarz-nordic please take another look, i've added blocking support to the backend (to handle panic case). Also moved rx polling period to kconfig.

@nordic-krch: So, how well did you test this patch with various qemu targets? Are you aware of https://github.com/zephyrproject-rtos/zephyr/issues/8869 for example? In summary, interrupt-driven UART is great boon for real hardware, and curse for QEMU emulations, which don't have faithful IRQ emulation, sometimes even remotely.
All in all, I see obvious shell behavior regressions with this patch for BOARD=mps2_an385 in qemu (and that's about to become the default qemu target for arm).

@pfalcon : Old shell was also interrupt driven for Rx.

@pfalcon : Old shell was also interrupt driven for Rx.

Old shell as in "old shell", or as in "new shell before this PR"? The old shell had a pretty fun design, which didn't work well even on real hardware (e.g. for pastes). Here we discuss the problem with QEMU and this particular PR.

@pfalcon : old shell as a old shell. So this is not a regression but something we need to improve :)

@jarz-nordic :

old shell as an old shell. So this is not a regression but something we need to improve :)

Yeah, we mostly left old shell behind (https://github.com/zephyrproject-rtos/zephyr/issues/10769 is again mostly to prove the point that if we replace "old" with "new", we should port over the functionality by default, or someone will ask why we didn't, and we'll need to have an answer, preferably good).
So, this is not regression re: old shell. This is qemu-specific regression before and after this patch. You're right that we need to deal with it. Let's move discussion to a more suitable place, I'll see if we can repurpose some existing ticket or it's better to create new.

@pfalcon

So, how well did you test this patch with various qemu targets?

Well, i think that we have uart.h api that i should be able to rely on. If specific driver implements interrupt version then it's not my fault if it is faulty :). If qemu interrupt driven uart is lousy then it should be improved or disabled or we should have big banner somewhere do not trust drivers, test all before any change

@nordic-krch, @jarz-nordic: Let's move discussion to https://github.com/zephyrproject-rtos/zephyr/issues/8869 please.

source: gharchive/pull-request

authors: codecov-io finikorg jarz-nordic jukkar nordic-krch pfalcon


text:
samples: cmsis_rtos_v1: Disable tests on qemu_xtensa

We get an intermittent fail when running on qemu_xtensa.  Disable this
sample for now on that platform to allow sanitycheck / CI to pass for
other PRs.
Signed-off-by: Kumar Gala kumar.gala@linaro.org

Would like to see if this should be broadened to only run/build the samples/portability/cmsis_rtos_v1 on ARM

Would like to see if this should be broadened to only run/build the samples/portability/cmsis_rtos_v1 on ARM

could be, but this should actually be HW agnostic.

Codecov Report

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

@@           Coverage Diff           @@
##           master   #11936   +/-   ##
=======================================
  Coverage   48.16%   48.16%
=======================================
  Files         281      281
  Lines       43355    43355
  Branches    10391    10391
=======================================
  Hits        20883    20883
  Misses      18318    18318
  Partials     4154     4154

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 8a8d4d3...c99d710. Read the comment docs.

authors: codecov-io galak nashif


text:
RFC: API Change: usb: Make users call usb_enable. Provide global status callback.

This PR is for resolving point 1 from #13403
This PR address problem presented in #21419

@carlescufi @emob-nordic @finikorg After reviewing this and #20011 I think we should not introduce USB_DEVICE_AUTO_ENABLE and drop 7bc65fabccc57cb8d4235ac9a8d2a604b33ba856

Note that once there's an option to add a callback after USB has been initialized we need a way to ensure that the application tracks the state correctly: either by returning the state, or by having the callback invoked with an initial state when it's registered.

This callback is used for notification only. The stack does not have to care about what application does with that. btw, I think a message queue or mailbox would be a better solution, but needs more work.

As implemented the new USB device state enumeration is not used. It should be removed, or the DC states mapped to device states. This is the blocker, the rest is commentary.

The usb_device_state was prepared for users so they will not create their own enum for this. Nothing more.
I understand that ideally user_state_callback should use usb_device_state as an input parameter but:

from what I checked it would only apply for nordic (some vendors forward only 2 statuses which is weird but it is done like this and its not my intention here to correct drivers).

Ideally We would have field device_state in usb_dev singleton and then based on status callback we could change the state internally in the device and then call  proper user callback to keep him informed about the state.
Just to clarify the view of this PR. What basically happens here is:

throw away the hid_ops.status_cb and makes it global per device, not per class as this should never be class specific.

which is a little odd. It's not obvious how those map to device states (which should be extended to include a "DISCONNECTED" state, if that enum is going to be used).

usb_state will not include DISCONNECTED state as its not consistent with the spec and for this I would not agree with You.

Just to clarify the view of this PR. What basically happens here is:

throw away the hid_ops.status_cb and makes it global per device, not per class as this should never be class specific.

That's a good goal.

The usb_device_state was prepared for users so they will not create their own enum for this. Nothing more.
usb_state will not include DISCONNECTED state as its not consistent with the spec

I don't see the value in providing this enum if it's not going to be handled by the driver.  To this point AFAIK no classes have had any use for these states.  Even if they did, your point that some vendor implementations don't provide enough detail through DC states to distinguish them suggests they aren't generally useful.
Whatever receives the state changes will still have to interpret the DC states provided in the callback and translate them into whatever states are important.  For me that's "connected/working" and "disconnected/not working".  I do not care about the finer-grained states in enum usb_state.
I need a compelling reason why enum usb_state should remain, or fairly consistent agreement from the "real" USB maintainers that it should be here even if it's not used, before I withdraw the NAK.

I need a compelling reason why enum usb_state should remain, or fairly consistent agreement from the "real" USB maintainers that it should be here even if it's not used, before I withdraw the NAK.

I've discussed it internally and I agree in this matter. It's not common to all drivers (unfortunate) so shall not be there.

@pabigot, @jfischer-phytec-iot  I've updated suggested changes. Please check it once again and approve if it's fine.

As per the API meeting, @emob-nordic please bring back the Kconfig option to conditionally disable the auto-powerup of the USB stack into this PR.

As per the API meeting, @emob-nordic please bring back the Kconfig option in #20011 to conditionally disable the auto-powerup of the USB stack into this PR.

Disagree, that is not the problem, the cb argument breaks the API.

As per the API meeting, @emob-nordic please bring back the Kconfig option in #20011 to conditionally disable the auto-powerup of the USB stack into this PR.

Disagree, that is not the problem, the cb argument breaks the API.
But there is more to discuss, this PR breaks also netusb support.

I will leave this discussion for USB sync meeting today.

@emob-nordic  please follow the new procedure and let's not introduce the Kconfig option, taking the opportunity to clean this up since we are introducing incompatible changes anyway.

Seems like there should be some usage documentation changes for this (other than in the doxygen comments and release notes)...

What would You suggest? I was following the process and hoped this is sufficient.

Seems like there should be some usage documentation changes for this (other than in the doxygen comments and release notes)...

I proposed a rewritten section in the release notes. Beyond this and the doxygen changes, there is currently no documentation which explains to the users the USB subsystem usage, so I do not think any further changes are necessary until we add more documentation @dbkinder.
The change follows standard procedure as pointed out by @emob-nordic

authors: carlescufi emob-nordic jfischer-phytec-iot pabigot


text:
[RFC][DNM] Asynchronous i2c and sensor API with hts221 example

It is a demonstration of proposed i2c and sensor API extension (#21538).
Following things are implemented:

i2c_mngr api and implementation
i2c_ll api and implementation for nordic platform.
extended i2c api to be able to use i2c_mngr if present and provide sync api on top of that
extended sensor API with async call
modified hts221 sensor to support reading temperature and humidity asynchronously
modified samples/sensor/hts221 to work in 2 modes: periodic sensor read from thread or asynchronously from k_timer (interrupt context). I've removed all printing to only get sensor related processing. Sample runs on nordic thingy52 (pca20020).~~

EDIT:
Changes:

added async_client is a generic way of controlling asynchronous operations (extracted from onoff service)
added draft of  qop_mngr module which is a generic module for performing queued operations. qop_mngr is using async_client
added i2c_common.c which implements i2c_mngr which is capable of queueing i2c transactions.
extened i2c API:

added i2c_single_transfer function for asynchronous single i2c message handling. This function must be implemented to enable asynchronous API for the driver.
added struct i2c_transaction
added helper macros for creating typical i2c transfers (I2C_MSG_TXRX(), I2C_MSG_TXTX())
added struct i2c_common_data which contains i2c_mngr data and must be part of the driver data
added i2c_schedule(dev, transaction) for performing asynchronous transactions

modified i2c_nrfx_twim.c which implements single transfer function
modified HTS221 driver to use transaction for initialization

@nordic-krch I guess you can close this, since you said in https://github.com/zephyrproject-rtos/zephyr/pull/23075#issuecomment-591256066 that that PR is a replacement for this one?

Closing this one as updated approach will be using queued operation manager and asynchronous sequence manager #23075.

Closing this one as updated approach will be using queued operation manager and asynchronous sequence manager #23075.

See #23371

authors: mbolivar nordic-krch


text:
Bluetooth: Controller: HCI: Fixing the bug to store 12 bit IQ samples

While IQ samples are captured in 12 bit resolution as described in
the documents of nRF chipsets, 4 bits of the data was omitted by
the software when it was reported to other components by HCI layer.
Now it stores the IQ samples as they are captured at the origin in
a 16 bit signed integer.
Signed-off-by: Saleh Mehdikhani saleh.mehdikhani@unikie.com

The issue has described here: https://github.com/zephyrproject-rtos/zephyr/issues/37391

This PR should be closed. IQ samples can't be reported as uint16_t due to BT Core spec 5.1 Vol 4. Part E, 7.7.65.21 LE Connectionless IQ Report event.

Yes it could not be reported as 16 bit, but maybe omitting the 4 least significant bits is not a good solution as I discussed in the above message. In practice the 4 most significant bits are not used too much, but we are keeping this 4 MSB and losing the LSB.
Anther problem is "out of range samples" as described here:
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fps_nrf5340%2Fradio.html&anchor=concept_dfe_iq_sampling
These out of ranges are reported by the hardware as -32768, which is then reported as 0 after shifting and casting.

Yes it could not be reported as 16 bit, but maybe omitting the 4 least significant bits is not a good solution as I discussed in the above message. In practice the 4 most significant bits are not used too much, but we are keeping this 4 MSB and losing the LSB.

Anther problem is "out of range samples" as described here:
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fps_nrf5340%2Fradio.html&anchor=concept_dfe_iq_sampling
These out of ranges are reported by the hardware as -32768, which is then reported as 0 after shifting and casting.

@saleh-unikie I've implemented the most straightforward approach to comply with BT Core spec. Yes, there is lost in accuracy, that is unfortunate. You are welcome to provide alternative form of transformation of original IQ samples to 8 bit values. I suggest to close this PR and issue in Github. Provide separate PR with alternative implementation. Also make the alternative  transformation to be possible to select by Kconfig options.

@saleh-unikie and @ppryga can a software AGC implementation be used without compromising the validity of the samples?

@saleh-unikie and @ppryga can a software AGC implementation be used without compromising the validity of the samples?

I wouldn't go that path. Let Radio control the AGC, The range of IQ  samples is more related with ADC resolution.
@saleh-unikie

Anther problem is "out of range samples" as described here:
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fps_nrf5340%2Fradio.html&anchor=concept_dfe_iq_sampling
These out of ranges are reported by the hardware as -32768, which is then reported as 0 after shifting and casting.

From BT Core spec stand point of view, there is no special meaning for any I and Q value except 0x80 No valid sample available.
There is no value reserved for other purposes. So even if you use 0xFF to inform host about oversaturation it would be meaningful only for Nordic implementation. You can't expect interoperability in that regard.

@carlescufi this PR may be closed. If merged then HCI event HCI_LE_Connectionless_IQ_Report will not comply to BT Core spec. 5.1.

authors: cvinayak ppryga saleh-unikie


text:
Permanent extended advertisement sending example

Ext adv sample created for @cvinayak - see ble channel in discord

Something does not add up - if I apply adapt your code for the 52840dk and test it there, I still have the same issue:
id: 1146 - received: 467 - failed: 315
I only added the CONFIG_BT_CTLR_ADV_EXT=y to each prj.conf

This phenomena can also be seen if you execute the ISO_BROADCAST and ISO_RECEIVE samples from the current main branch. I've attached a short video where you can see the broadcaster on the left side and the receiver on the right. The code has not been changed but I've commented out some printk statements on the receiver side (Executed on two nrf52dk boards).
Here you can find the video: https://youtu.be/X1s2B4AWipY


text:
Bluetooth: host: Fix missing net_buf_unref

When call bt_conn_send_cb with conn state not connect,
will cause buffer unref.
Signed-off-by: Lingao Meng menglingao@xiaomi.com

From the documentation of the function:
/* Send data over a connection
 *
 * Buffer ownership is transferred to stack in case of success.
 *
 * Calling this from RX thread is assumed to never fail so the return can be
 * ignored.
 */
int bt_conn_send_cb(struct bt_conn *conn, struct net_buf *buf,
		    bt_conn_tx_cb_t cb, void *user_data);

Buffer ownership is transferred to stack in case of success. => I think this is intentional, and that the stack should not unref teh buffer in case of error.

@Thalley correct, or then we change the semantics of the function and make sure that all callers update their expectations regarding buffer ownership (not sure if we want that - there's probably a reason why caller ownership is retained for error situations).
Btw, considering the quoted "Calling this from RX thread is assumed to never fail so the return can be ignored" part of the documentation. Is this still true and accurate after #40273 was merged? @LingaoM any comment?

Closing: Not a bug since implementation matches documentation. See https://github.com/zephyrproject-rtos/zephyr/pull/44922#issuecomment-1102296411.
Consider opening a ticket for an API change if you want to get this change in.

Closing: Not a bug since implementation matches documentation. See #44922 (comment).
Consider opening a ticket for an API change if you want to get this change in.

Just to be clear: This is an internal function and not part of a public API.

authors: LingaoM Thalley alwa-nordic jhedberg


text:
templates: bug: ask if the bug is a regression

Heya, when triaging bugs I often find unclear whether it's a "new" issue or a regression. Regressions are easy to bisect, but one needs the right hardware which we often don't have. Maybe asking explicitly may help a bit with both.
Let me know what you think.
-- 8< --
Add a note to the bug report GitHub template asking if the bug is a
regression, and asking for a bisected commit if available.
This should make regression bugs easier to triage, or even point the
author to the solution.

Good idea


text:
twister: Add esp32 section name to overflow check

esp32 platforms can overflow their dram0_1_seg so add that section name
to the overflow check in twister.  We were seeing this with the
samples/arch/smp/pi/sample.smp.pi test and would get:
zephyr_pre0.elf section noinit' will not fit in region dram0_1_seg'
region `dram0_1_seg' overflowed by 17456 bytes
Fixes #49164
Signed-off-by: Kumar Gala galak@kernel.org

@stephanosio  @galak, would that make not "not hacky" if we rename ESP32 sections to DRAM, DRAM1 and IRAM?

would that make not "hacky" if we rename ESP32 sections to DRAM, DRAM1 and IRAM?

No, naming has nothing to do with it (though, following the existing naming convention would be nice).
I was more referring to how it tries to whitelist every memory region that is allowed to overflow (very platform-dependent), instead of blacklisting those that are not allowed to overflow.

authors: galak stephanosio sylvioalves


text:
Maintainers: remove myself as docs collaborator

I am still interested in contributing to the documentation, but I am
tired of the spam I'm getting from zephyrbot whenever any pull request
touches anything in doc/.

We should have two areas, one is for documentation infrastructure and some key files like top level indexes and common high level areas.
Second area probably for GSG and other high level guides, but subsystems and other content should be covered by existing areas in the MAINTAINER file. Documentation of a subsystem or a service should be maintained and reviewed by the maintainer of that subsystem and not by one single person!

authors: mbolivar-nordic nashif


text:
drivers: gpio: mec172x: Prevent voltage drop in gpio during reconfigu…

If a gpio is already configured as output (e.g. by ROM bootloader) and then is reconfigured by app as output again but different gpio flags. There is glitch since driver is temporary changing gpio direction.

Hi Alberto, Any change will require full retest of all GPIO driver features.  I am worried this may break the sequence trying to prevent the spurious interrupt when interrupt detection is first enabled.

Alberto, Any change will require full retest of all GPIO driver features. I am worried this may break the sequence trying to prevent the spurious interrupt when interrupt detection is first enabled.

@scottwcpg Agreed, will run of test cases only after that will move it to ready. Maybe need to add additional test cases to catch these glitches. So far I have only checked via register dump that there is no difference in final gpio register config with and without this change.
Apart from potential regression do you see any other problem with this change?

fyi @yerabolu

@albertofloyd What about the case where ROM set the pin as output and Zephyr application wants the pin to be an input?  The mask value does not clear direction so the pin remains output.

authors: albertofloyd scottwcpg


text:
drivers: intc: mchp_ecia_xec: Ensure correct device init order

We need to ensure that the XEC GIRQs are initialized after the XEC ECIA device.  Right now we depend on the linker ordering things correctly since everything is at INTC_INIT_PRIORITY priority
Set the XEC GIRQs to 41 so the init priority is one more than INTC_INIT_PRIORITY that is used by xec-ecia.

We see an issue when building with the arm-clang compiler as its linker sorts the device init order in a different way than the GNU linker does.


text:
drivers: spi: spi_nrfx_spim: Add CPOL handling on SCK pin

Pin state after SPIM deinitialization is based on pinctrl configuration. On the other hand, CPOL is set during runtime. With the introduction of the power-optimized SPIM driver, it disables the peripheral instance once the transfer is completed. As a result, the GPIO takes control over the SCK pin and drives it based on pinctrl configuration which causes an invalid SCK state when the transaction is configured with CPOL (Clock Polarity).
To address this issue, a patch was introduced to the SPIM driver. Now, when a SPIM instance is configured with CPOL, the driver is setting in the runtime the correct state of the SCK pin.
The PR addresses concerns in the comment https://github.com/zephyrproject-rtos/zephyr/pull/61280#issuecomment-1669621931 placed in PR with another solution to CPOL handling on SCK pin.

I guess #61280 can be closed.

authors: anangl awojasinski-nordicsemi


text:
doc: release-notes: Add 3.5.0 release notes for networking

Add 3.5.0 release notes for networking.

Just rebased after https://github.com/zephyrproject-rtos/zephyr/commit/d52cb2202fd1239b106a3a3b730ec2dd6ef5a1ee was merged.

Looks like there's a CI build failure, likely because of #63074

authors: jhedberg rlubos


text:
[DNM] build: namespace generated headers with zephyr/

Namespaced the generated headers with zephyr/ to prevent potential conflict with other headers.
Introduced a Kconfig (CONFIG_LEGACY_GENERATED_INCLUDE_PATH) to support legacy generated header include paths in the mean time.
Fixes #60377

[x] Missing changes to the 2 repos that depend on this are required in order to merge the PR

sof

https://github.com/thesofproject/sof/pull/8459

percepio

https://github.com/percepio/percepio/pull/5
https://github.com/percepio/percepio/pull/6

[ ] Missing a entry to the migration document

this PR is getting more involved than I initially expected

@ycsin hey thanks for putting this together, since it's a major change I added the treewide and architecture review tags so this can be discussed in the architecture WG (cc @carlescufi)

Rebased on top of main
Moved LEGACY_GENERATED_INCLUDE_PATH into the Compatibility menu

Another compilation issue getting fixed @ #64251

Ran this again the push CI job in the testing repo (https://github.com/zephyrproject-rtos/zephyr-testing/runs/18077860182) single failure but it's unrelated. Great job there, hopefully we can merge it soon, too bad we did not make to this at the last arch wg, we should probably do it early next time, I don't see any objections here anyway.
Needs a rebase btw.

rebased and remove modifications to scripts/kconfig/kconfiglib.py

rebased again for #64464

Architecture WG:

Checked that we do not have an applicable Kconfig option anymore that can be used, instead we will need the new CONFIG_LEGACY_GENERATED_INCLUDE_PATH.
Missing changes to the 2 repos that depend on this are required in order to merge the PR
Missing a entry to the migration document

this PR is getting more involved than I initially expected
EDIT: And CI is complaining about some lines that are not modified in this PR:

@ycsin - those compliance issues could also be fixed in a separate PR. This one will require a respin anyway, so that might be a good option

I'm not sure which category should this change falls into in the migration guide, any idea?

build system

This needs a rebase. Is the target milestone still v3.6.0?

This needs a rebase. Is the target milestone still v3.6.0?

I'm not sure tbh, does this need to go thru an architecture review?

I'm not sure tbh, does this need to go thru an architecture review?

Yes, it needs to follow the process described here: https://docs.zephyrproject.org/latest/contribute/guidelines.html#treewide-changes

Please do continue the work here, +1 from on CI and arch wg agreement

This PR should be ready for the architecture review now

testing the changes for autoconf.h, list of files that includes the autoconf.h:
(.venv) ycsin@LAPTOP-ROG:~/zephyrproject$ find . -type f -exec grep -H '#include [<|"]autoconf\.h[>|"]' {} +
./modules/hal/stm32/scripts/tests/genllheaders/data/stm32_ll_tim.h:#include <autoconf.h>
./modules/hal/stm32/scripts/tests/genllheaders/data/stm32_ll_usart.h:#include <autoconf.h>
./modules/hal/stm32/scripts/genllheaders/header-template.j2:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_fmpi2c.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_lptim.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_wwdg.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_icache.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_gpio.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_pwr.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_adc.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_bdma.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_spi.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_utils.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_delayblock.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_dlyb.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_lpuart.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_opamp.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_ipcc.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_hsem.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_rcc.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_dmamux.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_dac.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_i3c.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_dma2d.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_i2c.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_system.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_comp.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_hrtim.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_swpmi.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_tim.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_crc.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_cortex.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_ucpd.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_cordic.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_dcache.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_sdmmc.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_lpgpio.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_fmac.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_usart.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_exti.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_rng.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_mdma.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_iwdg.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_dma.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_bus.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_crs.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_fmc.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_pka.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_rtc.h:#include <autoconf.h>
./modules/hal/stm32/stm32cube/common_ll/include/stm32_ll_fsmc.h:#include <autoconf.h>
./modules/hal/nxp/s32/mcux/devices/S32K344/S32K344_features.h:#include "autoconf.h"

Seems like it works this time, not sure what I missed last time for the autoconf.h changes. cc @carlescufi

rebased to fix conflicts

The PR branchs in percepio are now merged while this branch isn't, which is likely to cause havoc to percepio users?

Needs rebase

Removed Architecture Review as it had been reviewed a few months ago, it just requires approvals from the maintainers now.

Rebased and ran the script to update some new #include additions

@tejlmand Please revisit.

Things are failing now because LEGACY_GENERATED_INCLUDE_PATH is now disabled by default (previously it was enabled by default).
Currently I'm just trying to see if hal_stm32 is the only one affected by the latest change, I think it probably makes sense to enable the LEGACY_GENERATED_INCLUDE_PATH by default so that this PR has less dependencies on the external modules, and disable + deprecate that after we have all PRs in external modules repo merged.

[ ] wait for CI to pass (CONFIG_LEGACY_GENERATED_INCLUDE_PATH=n)
[ ] Remove last commit (4b03a50bcd49ca4bffc2accfda7283b04f317371) (
[ ] Wait for CI to pass again (CONFIG_LEGACY_GENERATED_INCLUDE_PATH=y)

[ ] wait for CI to pass (CONFIG_LEGACY_GENERATED_INCLUDE_PATH=n)

[ ] Remove last commit (4b03a50bcd49ca4bffc2accfda7283b04f317371)

[ ] Wait for CI to pass again (CONFIG_LEGACY_GENERATED_INCLUDE_PATH=y)

If CI passes with CONFIG_LEGACY_GENERATED_INCLUDE_PATH=n, why revert it?

[ ]  wait for CI to pass (CONFIG_LEGACY_GENERATED_INCLUDE_PATH=n)
[ ]  Remove last commit (4b03a50)
[ ]  Wait for CI to pass again (CONFIG_LEGACY_GENERATED_INCLUDE_PATH=y)

If CI passes with CONFIG_LEGACY_GENERATED_INCLUDE_PATH=n, why revert it?

The CI pass because the last commit updates the modules to point at my PRs. Correct me if I'm wrong, the west.yml will only be updated when these PRs are merged, so in the mean time we need to enable CONFIG_LEGACY_GENERATED_INCLUDE_PATH until they are merged and west.yml updated.
I also agree with @gmarull that the downstream shouldn't break immediately when they sync to the latest main branch after this is merge, i.e. a nightly CI build that tracks the latest main. We will show them a nice warning message that asks them to update (while we wait for the west.yml to be updated anyway):

Once all upstream stuff have been updated to work properly, we can stop enabling the CONFIG_LEGACY_GENERATED_INCLUDE_PATH by default and the downstream app will fail to compile, if they are still using the legacy path. They will have to enable the Kconfig explicitly and be presented with an additional deprecation warning.

CI finally passed 🥳
Will revert the last commit now

@cfriedt @nordicjm @finikorg @fabiobaltieri @de-nordic @dcpleung @mbolivar-ampere
This PR is now ready (again), could you please take another look again?
@gmarull this PR should align with #41543 and consistent with the header migration PR that you have made in the past (~v3.1.0?), could you please review?

This may use some coordination help from someone from @zephyrproject-rtos/release, plenty of dependencies, plus probably something will pop up after merge as well, worth keeping it in mind.

ping assignee @tejlmand, PTAL, thanks!

ping assignee @tejlmand, PTAL, thanks!

another ping @tejlmand

🥳🍀🤞

Just FYI https://github.com/thesofproject/sof/actions/runs/9278328176/job/25529164408
FileNotFoundError:  No such file or directory:
  '/zep_workspace/build-lnl/zephyr/include/generated/autoconf.h'

That's because one Python script in SOF extracts values from autoconf.h after the build.
The C compilation was fine and the CONFIG_LEGACY_GENERATED_INCLUDE_PATH warning was printed by CMake as expected.
Just FYI.

authors: carlescufi cfriedt fabiobaltieri henrikbrixandersen marc-hb nordicjm teburd ycsin


text:
X86 linker regions

This patch series implements some changes for memory protection:

Various memory regions in the x86 linker script are now page-aligned so that they can have different access policies in the MMU
The memory regions configured at boot time now use regions defined by the linker
Refactored linker variables in linker-defs.h

There's an issue on ARM with one of these patches, fixing..


text:
cleanup: soc: esp32: IDF_TARGET parameters removal

IDF_TARGET parameters removed from soc/Kconfig and landed on Espressif hal

This PR is depending on https://github.com/zephyrproject-rtos/zephyr/pull/75793 approval


text:
ipc: icbmsg: Add support for POSIX arch targets

Add support in this IPC backend for POSIX arch targets in general, and ensure the nrf5340bsim defines the buffer which will be used.
Fixes #78099

CC @dchat-nordic

Closing in favour of https://github.com/zephyrproject-rtos/zephyr/pull/78390


text:
subsys: usb: update bcdUSB to 2.00

Update bcdUSB to 2.00
resolves #7570

Codecov Report

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

@@           Coverage Diff           @@
##           master    #7822   +/-   ##
=======================================
  Coverage   55.01%   55.01%
=======================================
  Files         483      483
  Lines       53946    53946
  Branches    10493    10493
=======================================
  Hits        29678    29678
  Misses      19982    19982
  Partials     4286     4286

Continue to review full report at Codecov.

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

authors: codecov-io jfischer-phytec-iot


text:
arch: arm: clean-up "default n" entries in Kconfig option definitions

This commit removes the depreciated "default n" entries from
boolean K-config options in arch/arm.
Signed-off-by: Ioannis Glaropoulos Ioannis.Glaropoulos@nordicsemi.no
The "default n" entries were introduced when merging #6748 into master.

Codecov Report

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

@@           Coverage Diff           @@
##           master    #9436   +/-   ##
=======================================
  Coverage   52.17%   52.17%
=======================================
  Files         212      212
  Lines       25892    25892
  Branches     5561     5561
=======================================
  Hits        13508    13508
  Misses      10126    10126
  Partials     2258     2258

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 993c349...5ad02e7. Read the comment docs.

As an unrelated note, arch/arm/core/cortex_m/tz/Kconfig isn't sourced anywhere. Wonder if it was meant to be sourced in arch/arm/core/Kconfig. That's where arch/arm/core/cortex_m/mpu/Kconfig gets sourced.

That was not part of #6748, but will be included in a a follow-up PR.

authors: codecov-io ioannisg


text:
Add guides about the token and vouching process

Add a section explaining how to interact with the token and vouching contracts through the CLI.
We may also want to add some details about those contracts and where are they published.

Fixed by #331

authors: ajsantander facuspagnuolo

repo: zeppelinos/zos

license: MIT


text:
Support word extraction with one annotation multiple rows

Also addressed part of #37

repo: zequnyu/cmdict


text:
Adicionar búsqueda por id de la sesión para los que usan mooodle plugin collaborate

El código del proyecto PyCollab es muy útil, pero en el caso de nuestra universidad tenemos open LMS con plugin para collaborate ultra no LTI, la búsqueda por nombre de la sesión nos arroja varias grabaciones debido que no se maneja un nombre único de la sesión, nuestros usuarios suelen usar nombres genéricos somo por ejemplo: "Sesión 1".
python CollabMoodle.py -s moodle_plugin_sessions.txt -w 100

Hemos colocado una versión actualizada, Basado en el escenario (Reporte desde Collaborate Manager Institutional – tanto Attendance report  como Recordings report ) se puede utilizar los descrito en el Escenario 3.

authors: roxanapmh zerausolrac

repo: zerausolrac/PyCollab


text:
dot  net core support and async

the library dosn't support .net core platform or shows a warning message if added to project
lacks  async support

I have replied in #7

repo: zerodhatech/dotnetkiteconnect


text:
Added azure keyvault functionality

Naming conventions problems:

Arguments vault-prefix, vault-mapping, should those be left as is? Since they now also apply to azure keyvault and the naming would be more clear if it was just prefix and mapping. But this would break backwards compatibility so maybe leave those two and add  prefix,  mapping as new arguments that do the same thing?
I named the new function for azure keyvault azure since i think it would be more confusing to name it keyvault because we already have vault. Again because of backwards compatibility don't think we should change vault.

Thank you :)

authors: vajura zerok

repo: zerok/tpl


text:
Add "shorten.lua" file.

Following https://github.com/zeromicro/zero-doc/blob/47c959da3c9938dbccefb565c3bddce232807299/website/i18n/en/docusaurus-plugin-content-docs/current/extension/shorturl.md example, last step I want to test benchmark.
Use wrk -t10 -c1000 -d30s -s shorturl.lua --latency "http://localhost:8888", it turns shorturl.lua: cannot open shorturl.lua: No such file or directory, please add shorturl.lua for testing.

I encountered the same problem forllowing the example. I think the team should include the shorturl.lua file as not all knows what to input in the lua file.

Because wrk has some bugs on last requests before stopping. We turned into the tool hey. I can't find the shorturl.lua. It's just a simple test script.

authors: Dhuliang kevwan tommy921092

repo: zeromicro/go-zero


text:
goctl  specifications and recommendations

Could you unify the usage specifications of the goctl?
goctl model mysql ddl --src user.sql --dir .
goctl api go --api user.api --dir .
Why not change the input files to --src and the output files to --dir
It is recommended to add the function of modifying the generated file name

In the logic directory, I don't want the generated filenames to contain '_logic'.

@sunviv 看我fork的一个版本，我目前都去掉了这些，

Thanks for the feedback. In the early, goctl was developed by multiple people, each with the same hobby. At first, everyone focused on solving problems. When these problems were discovered, it was too late to modify them.

Thanks for the feedback. In the early, goctl was developed by multiple people, each with the same hobby. At first, everyone focused on solving problems. When these problems were discovered, it was too late to modify them.

And how to modify the file name generated by goctl?

@kesonan 有打算给types支持分组的计划嘛

@kesonan 有打算给types支持分组的计划嘛

There is no plan support, the API does not have the concept of packages, grouping will bring negative effects and duplicate code

@sunviv  https://github.com/go-sh/go-zero/commit/9da3b6839811e92df608bb5a19fd2bdcac9cfba7  可以试试这个分支

authors: kesonan sunviv xhochipe


text:
Support for non-texture obj

I have some non-texture obj file, such as the one https://graphics.stanford.edu/~mdfisher/Data/Meshes/bunny.ob. I expect some thing like this image
Can you support it? Thank in advanced

Has fixed it, but no illumination.

I found this guy https://github.com/hemanthrajv/flutter_3d_obj/blob/a34d26e144eb9b26ef2f7552c7e128828f71ce0c/lib/flutter_3d_obj.dart#L241 has implemented illumination base on normalize light vector and normal vector of face. Hope it help


text:
feat: add message to withdraw emission rewards

Description

Add a message to enable observers to collect emission rewards

Closes: https://github.com/zeta-chain/node/issues/1653
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Include instructions and any relevant details so others can reproduce.

[ ] Tested CCTX in localnet
[ ] Tested in development environment
[ ] Go unit tests
[ ] Go integration tests
[ ] Tested via GitHub Actions

Checklist:

[ ] I have added unit tests that prove my fix feature works

I'm not sure to understand. Why creating a withdraw object in the message and processing it in the endblocker, instead of directly processing it in the message? What does the WithdrawEmission object brings on top of WithdrawableEmission?

This is to prevent more than one emission withdraw in the same block. Although I can't really think of a condition which,would allow observers to withdraw more rewards than they own , Using the endblock and processing all withdraws in the block at once makes the logic a bit safer
I don't think it adds much of an overhead on top of a regular tx .

I'm not sure to understand. Why creating a withdraw object in the message and processing it in the endblocker, instead of directly processing it in the message? What does the WithdrawEmission object brings on top of WithdrawableEmission?

This is to prevent more than one emission withdraw in the same block. Although I can't really think of a condition which,would allow observers to withdraw more rewards than they own , Using the endblock and processing all withdraws in the block at once makes the logic a bit safer I don't think it adds much of an overhead on top of a regular tx .

I don't get it.
We have a WithdrawableEmissions object, already in the store, containing the amount an address can withdraw.
We're implementing a MsgWithdrawEmission that creates a WithdrawEmissions containing the exact same fields as above.
The end blocker iterates these WithdrawEmissions, send funds to user, delete WithdrawEmissions and subtract WithdrawableEmissions from value in WithdrawEmissions
Why not directly having MsgWithdrawEmission that decrease WithdrawableEmissions and send funds to user?

This is to prevent more than one emission withdraw in the same block.

Why is it a problem if we verify that the withdrawn amount is below withdrawable amount?

Although I can't really think of a condition which,would allow observers to withdraw more rewards than they own

How does using a intermediate end blocker add more protection for this?

Closing pr for now to make changes mentioned above cc @lumtis

authors: kingpinXD lumtis

repo: zeta-chain/node


text:
Android emulator + virtualbox x86_64

Using virtualbox (linux) flutter_meedu_videoplayer: ^4.2.13
Got emulator android-x86_64-7.1-r5.iso from https://www.fosshub.com/Android-x86-old.html
I/ExoPlayerImpl( 4274): Init 3067a64 [ExoPlayerLib/2.18.7] [x86_64, VirtualBox, innotek GmbH, 25]
D/NetworkSecurityConfig( 4274): No Network Security Config specified, using platform default
W/AudioCapabilities( 4274): Unsupported mime audio/ac3
W/AudioCapabilities( 4274): Unsupported mime audio/alac
W/AudioCapabilities( 4274): Unsupported mime audio/x-ape
W/AudioCapabilities( 4274): Unsupported mime audio/ffmpeg
W/AudioCapabilities( 4274): Unsupported mime audio/dts
W/AudioCapabilities( 4274): Unsupported mime audio/mpeg-L2
W/AudioCapabilities( 4274): Unsupported mime audio/vnd.rn-realaudio
W/AudioCapabilities( 4274): Unsupported mime audio/x-ms-wma
W/VideoCapabilities( 4274): Unsupported mime video/divx
W/VideoCapabilities( 4274): Unsupported mime video/x-flv
W/VideoCapabilities( 4274): Unsupported mime video/vnd.rn-realvideo
W/VideoCapabilities( 4274): Unsupported mime video/vc1
W/VideoCapabilities( 4274): Unsupported mime video/ffmpeg
W/VideoCapabilities( 4274): Unsupported mime video/x-ms-wmv
I/VideoCapabilities( 4274): Unsupported profile 4 for video/mp4v-es
I/OMXClient( 4274): MuxOMX ctor
I/MediaCodec( 4274): [OMX.ffmpeg.h264.decoder] setting surface generation to 4376577
E/ACodec  ( 4274): [OMX.ffmpeg.h264.decoder] storeMetaDataInBuffers failed w/ err -1010
I/ACodec  ( 4274): codec does not support config priority (err -1010)
I/OMXClient( 4274): MuxOMX ctor
I/ACodec  ( 4274): codec does not support config priority (err -2147483648)
I/ACodec  ( 4274): codec does not support config operating rate (err -2147483648)
D/AudioTrack( 4274): Client defaulted notificationFrames to 6156 for frameCount 12312
D/MediaCodec( 4274): [OMX.ffmpeg.h264.decoder] setting dataspace on output surface to #104
D/SoftwareRenderer( 4274): setting dataspace on output surface to #104

also

I/ExoPlayerImpl( 3316): Release 9629843 [ExoPlayerLib/2.18.7] [x86_64, VirtualBox, innotek GmbH, 25] [goog.exo.core, goog.exo.exoplayer, goog.exo.decoder, goog.exo.datasource, goog.exo.extractor]
W/MessageQueue( 3316): Handler (android.os.Handler) {fc97423} sending message to a Handler on a dead thread
W/MessageQueue( 3316): java.lang.IllegalStateException: Handler (android.os.Handler) {fc97423} sending message to a Handler on a dead thread
W/MessageQueue( 3316):  at android.os.MessageQueue.enqueueMessage(MessageQueue.java:543)
W/MessageQueue( 3316):  at android.os.Handler.enqueueMessage(Handler.java:643)
W/MessageQueue( 3316):  at android.os.Handler.sendMessageAtTime(Handler.java:612)
W/MessageQueue( 3316):  at android.os.Handler.sendMessageDelayed(Handler.java:582)
W/MessageQueue( 3316):  at android.os.Handler.post(Handler.java:338)
W/MessageQueue( 3316):  at com.google.android.exoplayer2.source.ProgressiveMediaPeriod.onLengthKnown(ProgressiveMediaPeriod.java:711)
W/MessageQueue( 3316):  at com.google.android.exoplayer2.source.ProgressiveMediaPeriod.access$600(ProgressiveMediaPeriod.java:72)
W/MessageQueue( 3316):  at com.google.android.exoplayer2.source.ProgressiveMediaPeriod$ExtractingLoadable.load(ProgressiveMediaPeriod.java:1008)
W/MessageQueue( 3316):  at com.google.android.exoplayer2.upstream.Loader$LoadTask.run(Loader.java:412)
W/MessageQueue( 3316):  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
W/MessageQueue( 3316):  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
W/MessageQueue( 3316):  at java.lang.Thread.run(Thread.java:761)

If both media_kit and video_player fail
I have nothing to do, I use them to play the videos so I can't edit them and errors posted doesn't help much sadly 😢


text:
phicomm-n1 小钢炮 Docker无法使用

System : Linux phicomm-n1 4.9.76 #1 SMP PREEMPT Thu Apr 11 20:39:46 CST 2019 aarch64 GNU/Linux
System : Linux version 4.9.76 (hacklog@arch-8700k) (gcc version 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ecfbc167ef90065c0eeb7f91977701] (Linaro GCC 7.3-2018.05) ) #1 SMP PREEMPT Thu Apr 11 20:39:46 CST 2019
Docker : Docker version v18.09.2, build v18.09.2
使用debian/ubuntu不改端口默认，一直提示在创建。
debian改了默认端口均为8088，直接日志standard_init_linux.go:207: exec user process caused "exec format error"

ARM64?

ARM64?

对的 ARM

ARM64?

对的 ARM

等我明天抽空做镜像，现在做的都是x86

ARM64?

对的 ARM

debian tag的镜像支持arm64了，你现在可以拉下来跑

debian tag的镜像支持arm64了，你现在可以拉下来跑

部署成功了，正常了

license: WTFPL


text:
performance worse than Mask R-CNN

Hello,
First of all thank you for sharing your work!
I tried to train a model on my own dataset (wildlife animal data) with different hyperparameters but the performance does not reach Mask R-CNN. (0.66 AP with RefineMask against 0.7 AP with Mask R CNN)
I trained it on a single gpu.
In another issue you wrote that this isnt possible, could the lower batchsize be the reason for the bad performance?
Thank you in advance!

Hello,
First of all thank you for sharing your work! I tried to train a model on my own dataset (wildlife animal data) with different hyperparameters but the performance does not reach Mask R-CNN. (0.66 AP with RefineMask against 0.7 AP with Mask R CNN) I trained it on a single gpu. In another issue you wrote that this isnt possible, could the lower batchsize be the reason for the bad performance?
Thank you in advance!

I have never tried single GPU training on both Mask R-CNN and our proposed RefineMask, except for debugging or testing;

The small batch size may be the reason, you can try a larger batch size per GPU;

Quality of the mask annotations may also affect the Improvements of RefineMask, but it should not be worse than Mask R-CNN.


text:
Training Code

您好，我对您的代码挺感兴趣的，请问大概啥时候能开源训练部分代码呢？

现在公司已经放假了，上班之后就尽量会早点来源的，其实可以参考reppoints，包括正负样本设置几乎一样@zhu2014yi

好的，非常感谢

现在公司已经放假了，上班之后就尽量会早点来源的，其实可以参考reppoints，包括正负样本设置几乎一样@zhu2014yi


text:
can not real push data to wowza

I have already created a stream to wowza, but use OutboundStream.PublishVideoData or OutboundStream.PublishAudioData can not real push data to wowza. Stream status is active but Bytes In is 0. There is no err return.
What can I do for check this error.

还是用中文说吧。 我尝试使用这个库进行rtmp流的推送，我下载了wowza做测试server。建立流的过程中并没有出错，看wowza的统计页面也能看到有新的stream。中间会收到connection succeeded的command。在OnStreamCreated的回调中调用Publish（“streamName”， “live”）后，再调用OutboundStream的PublishVideoData和PublishAudioData，在wowza看来，bytes in 一直是0，中间也不会报错。如果用ffmpeg来推rtmp流的话，是没有问题的。

wowza没有用过。
如果你有公网测试服务器，把信息发到我的gmail邮箱，我可以测试看看。

什么时候能支持wowza 服务器 ？

加我QQ：7123862
2016-08-30 11:57 GMT+08:00 vincent notifications@github.com:

什么时候能支持wowza 服务器 ？
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/zhangpeihao/gortmp/issues/12#issuecomment-243326361,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABu0oEYTN1YJmmxZ8W_oy2R33QhbA-pks5qk6oOgaJpZM4EHpI1
.

已经支持了

authors: vincentqiu wangziUSTC zhangpeihao

repo: zhangpeihao/gortmp

license: mit

license_source: bigquery


text:
Merge pull request #10 from zhangpeiqian2010/master

私钥分存与恢复

合入新的变更


text:
Stresses Input data required ?

Hello,
I would like to know which inputs are necessary ?

I understand that a test mesh must be generated (and not a surfac triangle mesh as STL) ?
Do I really need the principal stresses field data (texte file) ? Even if I don't want to slice by taking structurak strength into account (only optimization of support structures and quality finish) ?

thank you

Hey,
I am not the author of this, but maybe I can help you, since at the moment I am trying to figure this project out as well. If you do not want to take the structural strength part into account, you don't need the data file, as far as I know.
My workflow on creating the .tet file if you don't need FEA Analysis, is first using TetGen to create a .mesh and then use Mouette to convert it to .tet format.
Before opening the file with the software, you also need to modify the _updateFrameworkParameter() function in the MainWindow.cpp and add your file there, or otherwise no option will appear for your model in the software. The Parameters there are not documented very well, so try copying it from one of the other models set there.

Hi @yvanblanchard, the stress file is generated by FEA software, if we don't need the SR (strength reinforcement), there is no need to input the stress field.
@moorjuli Thanks for your kind reply and help.

Great. Thank both of you !

authors: moorjuli yvanblanchard zhangty019


text:
🛑 ZY is down

In 77877b0, ZY (https://ziyuan.baidu.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ZY is back up in 01002e4.

repo: zhaodylan/uptime-ziyuan


text:
miss keys

miss keys when load model
07/03/2019 01:07:13 - INFO - __main__ -   device: cuda n_gpu: 4, distributed training: False, 16-bits training: False
07/03/2019 01:07:41 - INFO - __main__ -   train examples 577157
07/03/2019 01:07:45 - INFO - __main__ -   load bert weight
07/03/2019 01:07:46 - INFO - __main__ -   missing keys:['classifier.weight', 'classifier.bias', 'idiom_embedding.weight']
07/03/2019 01:07:46 - INFO - __main__ -   unexpected keys:['cls.predictions.bias', 'cls.predictions.transform.dense.weight', 'cls.predictions.transform.dense.bias', 'cls.predictions.transform.LayerNorm.weight', 'cls.predictions.transform.LayerNorm.bias', 'cls.predictions.decoder.weight', 'cls.seq_relationship.weight', 'cls.seq_relationship.bias']
07/03/2019 01:07:46 - INFO - __main__ -   error msgs:[]

I found this phenomenon seems not to affect the training of model. So you may ignore it.


text:
How to use unet.hdf5 to generate mask for test image?

As the title, after the training, I get a unet.hdf5 file, how can I use directly?

I also need to use the hdf5 file. Does anyone have the answer?

run test_predict.py :)

@tynefung where is the test_predict.py?

hello,you guys. I solved this problem.
Firstly, you can build a file termed 'test.py' which is the same path with 'model.py' file.
Secondly, write these codes in 'test.py' file:
from model import *
from data import *
#os.environ["CUDA_VISIBLE_DEVICES"] = "0"
model = unet()
testGene = testGenerator("data/membrane/test",126)
results = model.predict_generator(testGene,126,verbose=1)
saveResult("data/membrane/test",results)
At last,run 'test.py'.
Notes: the number of 126 in 'results' equals the number of test images.
If you have question, plz send email to me.
QQ:1121399040

how to train and test this model???

hello,you guys. I solved this problem.
Firstly, you can build a file termed 'test.py' which is the same path with 'model.py' file.
Secondly, write these codes in 'test.py' file:
from model import *
from data import *
#os.environ["CUDA_VISIBLE_DEVICES"] = "0"
model = unet()
testGene = testGenerator("data/membrane/test",126)
results = model.predict_generator(testGene,126,verbose=1)
saveResult("data/membrane/test",results)
At last,run 'test.py'. Notes: the number of 126 in 'results' equals the number of test images.
If you have question, plz send email to me. QQ:1121399040

Where can I download pre-trained weights?

authors: ChengxiHAN Tao-Zhou YJonmo freedom9393 ggsf13 manvirvirk tynefung

repo: zhixuhao/unet


text:
🛑 腾讯云 COS 节点 is down

In 205acec, 腾讯云 COS 节点 (https://lisz.ink) was down:

HTTP code: 0
Response time: 0 ms

Resolved: 腾讯云 COS 节点 is back up in 98cd847.

repo: zhonger/upptime


text:
楼主您好，能否将每个选项卡页弹出的新增修改删除等模态框，不要遮挡全局页面，只是遮挡当前选项卡页面

楼主您好，能否将每个选项卡页弹出的新增修改删除等模态框，不要遮挡全局页面，只是遮挡当前选项卡页面，这样可以暂停当前选项卡的操作，切换到其它选项卡，以功能急盼回复

element弹窗组件内嵌在当前界面有问题。

authors: jinwmmail zhontai


text:
add getObjectKeys method to JSONValue

add getObjectKeys method, used for traverse JSON object.

你好，你发的邮件已经收到，我会尽快回复的。周传瑞

thanks for your commit

repo: zhouchuanrui/JSONinSV


text:
Removing private SSH key

I noticed you had commited a private ssh key to your repo.
"I know. It was intentional."
Sorry to bother you then. Feel free to ignore this PR.
You know you can also secure private data while keeping it under source control.
"I didn't notice. What is this file? Is it a problem?"
This can be a very bad thing
"I keep accidentally typing git add ., any way I can prevent that from being an issue?"
There are a couple of steps you should take immediately:

Avoid commands like git add . and git add *. It's better to be more explicit when you can.
Assume your key is compromised. Unassociate it from any accounts you are using it for and generate a new key.
Store your keys in a location outside of your project.
Use a .gitignore file to prevent accidental commits of certain files.

Github also has a page about how to remove sensitive data from a repo.
Hope this PR finds you well

It is intentional. Thanks.


text:
速度修改无效

速度修改无效，无论改多大，测试都是2m/s，太慢了

无法复现，请提供更多信息

authors: wilinz zhufucdev

repo: zhufucdev/MotionEmulator


text:
install.php可以被利用来恶意重装靶场

不知道这算不算漏洞。。。刚入门。index.php中通过检验数据库是否可以连上数据库来判断是否配置完成。但是却可以直接访问install.php来直接覆盖掉原来数据库中的数据。我觉得应该在配置文件中设置一个$installed变量来控制已经安装，然后install.php读取这个变量来判断是否需要安装。

你小子挺厉害啊，靶场里面找漏洞。
你就当是靶场里面的一个“用来练习的漏洞”吧。（不过实际环境中，这种情况确实是有问题的）

其实我是试着练审计的，里面一些知识我还不熟，比如sql注入一点不熟悉。还有一个问题是今天看出来的，sqli_iu/sqli_mem.php里面把用户信息拿出来时可以进行xss攻击，注册时只对sql进行escape，输出时没有escape

authors: xiezhuojin zhuifengshaonianhanlu

repo: zhuifengshaonianhanlu/pikachu


text:
Freezes VS Code

Not sure what information I can provide, but I thought I'd just report it. This addon freeze vs code for me. I verified this by disabling the extension. This happens every time in at least one of my projects. I have other projects that freeze occasionally but given that nature, there's no way for me to verify this extension is the cause of those. Happy to provide more information if directed.

I'm aware of this problem, it was reported some time ago, and the solution is to create a language server. It's quite hard to reproduce, and it seems to occur when you have a workspace with lots of CSS files. I'm working on it on my free time, but I can't give you a due date. Thanks for taking your time to report it. :)

@zignd I dont know if this is related, but my VSCode no longer provides intellisense.  Disabling the extension fixes, and enabling breaks.

@cgatian It is. When the extension takes too long to cache the classes, it compromises the VS Code as a whole. I will work on a language server tonight so that we can have this workload in a separate process.

Can you provide an update to at least prevent the behavior? I maintain an extension package that this uses, and don't want others to run into the bug.

I have the same issue on my large projects, vscode freezes when the extension is caching classes

I guess this issue has been fixed in the latest update. All thanks goes to Erich Gamma for this great pull request https://github.com/zignd/HTML-CSS-Class-Completion/pull/90.

authors: bardiainjast cgatian jensengar zignd

repo: zignd/HTML-CSS-Class-Completion


text:
[Device Support Request] _TZE200_c2fmom5z", "TS0601

This new Tuya Air Box seems to be similar to the existing TuyaCO2SensorGPP class(ts0601_air_quality.py), I could get the sensor up and working just by adding the new model info entry.
    MODELS_INFO: [
        ("_TZE200_ryfmq5rl", "TS0601"),
        ("_TZE200_yvx5lh6k", "TS0601"),
        ("_TZE200_dwcarsat", "TS0601"),
        ("_TZE200_c2fmom5z", "TS0601"),
    ],

However it seems that the VOC and HCHO sensor values position are swapped? Unless the VOC sensor excludes HCHO values in the calculation, I get impossible HCHO to VOC ratio.
For example
VOC: 8 µg/m³
HCHO: 19ppm (assuming unit is wrong and should be ppb, 19 ppb of HCHO is 0.023 mg/m3 which is way above the 0.008 mg/m3

You should post the device signature so that people can better help.

"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=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": 260,
"device_type": "0x0051",
"in_clusters": [
"0x0000",
"0x0004",
"0x0005",
"0xef00"
],
"out_clusters": [
"0x000a",
"0x0019"
]
},
"242": {
"profile_id": 41440,
"device_type": "0x0061",
"in_clusters": [],
"out_clusters": [
"0x0021"
]
}
},
"manufacturer": "_TZE200_c2fmom5z",
"model": "TS0601",
"class": "zigpy.device.Device"
}

I also have this device, device signatures seem to match
{
  "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=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": 260,
      "device_type": "0x0051",
      "in_clusters": [
        "0x0000",
        "0x0004",
        "0x0005",
        "0xef00"
      ],
      "out_clusters": [
        "0x000a",
        "0x0019"
      ]
    },
    "242": {
      "profile_id": 41440,
      "device_type": "0x0061",
      "in_clusters": [],
      "out_clusters": [
        "0x0021"
      ]
    }
  },
  "manufacturer": "_TZE200_c2fmom5z",
  "model": "TS0601",
  "class": "zigpy.device.Device"
}

What other information would you need to get this added?

New to HA and also have this device. I have an identical signature to that which @egelmex provided. The device is detected and added but of course shows no useful sensor information from HA's perspective.
Please let me know if there's any additional steps I should take or information I could provide. :-)

Looks like this was fixed in #2073

authors: Hogesyx Tropaion egelmex padadof2 zatricky

repo: zigpy/zha-device-handlers


text:
[Device Support Request] Immax NEO Smart Siren Zigbee 3.0

Immax NEO Smart Siren Zigbee 3.0
https://www.immax.eu/immax-neo-smart-siren-zigbee-3-0-p11154/
Is discovered fine by ZHA, but unfortunately no entities show up. It seems a quirk is needed...
Describe the solution you'd like
Entities for armed/disarmed/armed-home, battery, alarm and others if possible to show up in HA

If you want someone to help you, you should attach as much information as possible about the device, for example the one indicated in the [Device Support Request] template:

device signature
diagnostic information

That way we can guide you to try to get a solution to your problem.

Probably it's very similar to #2035 : adding its ID to the correct file will probably fix it.

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=0, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, 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": "0x0403",
      "in_clusters": [
        "0x0000",
        "0x0001",
        "0x0003",
        "0x0004",
        "0x0005",
        "0x0500",
        "0x0502",
        "0xeeff"
      ],
      "out_clusters": [
        "0x0003",
        "0x0019"
      ]
    }
  },
  "manufacturer": "_TYZB01_b6eaxdlh",
  "model": "TS0219",
  "class": "zigpy.device.Device"
}

Diagnostic information
{
  "home_assistant": {
    "installation_type": "Home Assistant OS",
    "version": "2022.12.8",
    "dev": false,
    "hassio": true,
    "virtualenv": false,
    "python_version": "3.10.7",
    "docker": true,
    "arch": "x86_64",
    "timezone": "Europe/Warsaw",
    "os_name": "Linux",
    "os_version": "5.15.80",
    "supervisor": "2022.12.1",
    "host_os": "Home Assistant OS 9.4",
    "docker_version": "20.10.19",
    "chassis": "vm",
    "run_as_root": true
  },
  "custom_components": {
    "hacs": {
      "version": "1.28.4",
      "requirements": [
        "aiogithubapi>=22.2.4"
      ]
    },
    "nodered": {
      "version": "1.1.2",
      "requirements": []
    }
  },
  "integration_manifest": {
    "domain": "zha",
    "name": "Zigbee Home Automation",
    "config_flow": true,
    "documentation": "https://www.home-assistant.io/integrations/zha",
    "requirements": [
      "bellows==0.34.5",
      "pyserial==3.5",
      "pyserial-asyncio==0.6",
      "zha-quirks==0.0.89",
      "zigpy-deconz==0.19.2",
      "zigpy==0.52.3",
      "zigpy-xbee==0.16.2",
      "zigpy-zigate==0.10.3",
      "zigpy-znp==0.9.2"
    ],
    "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"
        ]
      }
    ],
    "codeowners": [
      "@dmulcahey",
      "@adminiuga",
      "@puddly"
    ],
    "zeroconf": [
      {
        "type": "_esphomelib._tcp.local.",
        "name": "tube*"
      },
      {
        "type": "_zigate-zigbee-gateway._tcp.local.",
        "name": "*zigate*"
      },
      {
        "type": "_zigstar_gw._tcp.local.",
        "name": "*zigstar*"
      }
    ],
    "dependencies": [
      "file_upload"
    ],
    "after_dependencies": [
      "onboarding",
      "usb",
      "zeroconf"
    ],
    "iot_class": "local_polling",
    "loggers": [
      "aiosqlite",
      "bellows",
      "crccheck",
      "pure_pcapy3",
      "zhaquirks",
      "zigpy",
      "zigpy_deconz",
      "zigpy_xbee",
      "zigpy_zigate",
      "zigpy_znp"
    ],
    "is_built_in": true
  },
  "data": {
    "ieee": "**REDACTED**",
    "nwk": 14151,
    "manufacturer": "_TYZB01_b6eaxdlh",
    "model": "TS0219",
    "name": "_TYZB01_b6eaxdlh TS0219",
    "quirk_applied": false,
    "quirk_class": "zigpy.device.Device",
    "manufacturer_code": 0,
    "power_source": "Mains",
    "lqi": 255,
    "rssi": -77,
    "last_seen": "2023-01-09T22:28:38",
    "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.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice: 142>, manufacturer_code=0, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, 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": "0x0403",
          "in_clusters": [
            "0x0000",
            "0x0001",
            "0x0003",
            "0x0004",
            "0x0005",
            "0x0500",
            "0x0502",
            "0xeeff"
          ],
          "out_clusters": [
            "0x0003",
            "0x0019"
          ]
        }
      }
    },
    "active_coordinator": false,
    "entities": [
      {
        "entity_id": "binary_sensor.tyzb01_b6eaxdlh_ts0219_iaszone",
        "name": "_TYZB01_b6eaxdlh TS0219"
      },
      {
        "entity_id": "button.tyzb01_b6eaxdlh_ts0219_identify",
        "name": "_TYZB01_b6eaxdlh TS0219"
      },
      {
        "entity_id": "select.tyzb01_b6eaxdlh_ts0219_default_siren_tone",
        "name": "_TYZB01_b6eaxdlh TS0219"
      },
      {
        "entity_id": "select.tyzb01_b6eaxdlh_ts0219_default_siren_level",
        "name": "_TYZB01_b6eaxdlh TS0219"
      },
      {
        "entity_id": "select.tyzb01_b6eaxdlh_ts0219_default_strobe_level",
        "name": "_TYZB01_b6eaxdlh TS0219"
      },
      {
        "entity_id": "select.tyzb01_b6eaxdlh_ts0219_default_strobe",
        "name": "_TYZB01_b6eaxdlh TS0219"
      },
      {
        "entity_id": "siren.tyzb01_b6eaxdlh_ts0219_siren",
        "name": "_TYZB01_b6eaxdlh TS0219"
      }
    ],
    "neighbors": [],
    "routes": [],
    "endpoint_names": [
      {
        "name": "IAS_WARNING_DEVICE"
      }
    ],
    "user_given_name": null,
    "device_reg_id": "402938d2a1aab22d204bdbce3da4539e",
    "area_id": null,
    "cluster_details": {
      "1": {
        "device_type": {
          "name": "IAS_WARNING_DEVICE",
          "id": 1027
        },
        "profile_id": 260,
        "in_clusters": {
          "0x0000": {
            "endpoint_attribute": "basic",
            "attributes": {
              "0x0004": {
                "attribute_name": "manufacturer",
                "value": "_TYZB01_b6eaxdlh"
              },
              "0x0005": {
                "attribute_name": "model",
                "value": "TS0219"
              },
              "0x0007": {
                "attribute_name": "power_source",
                "value": 2
              }
            },
            "unsupported_attributes": {}
          },
          "0x0001": {
            "endpoint_attribute": "power",
            "attributes": {
              "0x0020": {
                "attribute_name": "battery_voltage",
                "value": 42
              },
              "0x0021": {
                "attribute_name": "battery_percentage_remaining",
                "value": 200
              }
            },
            "unsupported_attributes": {}
          },
          "0x0003": {
            "endpoint_attribute": "identify",
            "attributes": {},
            "unsupported_attributes": {}
          },
          "0x0004": {
            "endpoint_attribute": "groups",
            "attributes": {},
            "unsupported_attributes": {}
          },
          "0x0005": {
            "endpoint_attribute": "scenes",
            "attributes": {},
            "unsupported_attributes": {}
          },
          "0x0500": {
            "endpoint_attribute": "ias_zone",
            "attributes": {
              "0x0000": {
                "attribute_name": "zone_state",
                "value": 1
              },
              "0x0001": {
                "attribute_name": "zone_type",
                "value": 549
              },
              "0x0002": {
                "attribute_name": "zone_status",
                "value": 16
              },
              "0x0010": {
                "attribute_name": "cie_addr",
                "value": [
                  201,
                  54,
                  7,
                  255,
                  255,
                  46,
                  33,
                  0
                ]
              }
            },
            "unsupported_attributes": {}
          },
          "0x0502": {
            "endpoint_attribute": "ias_wd",
            "attributes": {
              "0x0000": {
                "attribute_name": "max_duration",
                "value": 240
              }
            },
            "unsupported_attributes": {}
          },
          "0xeeff": {
            "endpoint_attribute": null,
            "attributes": {},
            "unsupported_attributes": {}
          }
        },
        "out_clusters": {
          "0x0003": {
            "endpoint_attribute": "identify",
            "attributes": {},
            "unsupported_attributes": {}
          },
          "0x0019": {
            "endpoint_attribute": "ota",
            "attributes": {},
            "unsupported_attributes": {}
          }
        }
      }
    }
  }
}

Also having one of these, it gets detected in 2023.01.02 but no entities shown
Someone made some more descriptive information about different models of it on this page
And this is the product description from seller.

authors: Ireczeq NdK73 PerJarlemark javicalle