text:
add Users.GetByID + Update

Just adding missing functionality.
I wasn't able to test, because on my M1 keycloak did not come to life with docker-compose. I tried with the bitnami image to no avail.
I hope tests run through without issues 🙃

got the keycloak to work with an amd64 image, test was successful.

@zemirco could you merge this? I can also make adjustments if needed.

I would have some other suggestions as well and intend to use this library in more cases. Any chance we could join forces and you'd add me to the maintainers? We can have a chat any time.

Thank you for the PR. It's been a weird time the last months. We had our third child and covid also made the whole situation more complicated. Promise to be a better maintainer in the future 😄
We're currently on holiday but will test and merge as soon as we're back. Hopefully next week!
btw I also made the docker images work on my MacBook but forgot how :) It was about checking out a repo and then checking out a dedicated branch and building from source. Could you also update the README.md where you describe this process?

One thing I noticed. Could you please add dedicated tests for each method? Right now you're testing both methods in a single test. Sometimes this might sound cumbersome but it's nice to have dedicated tests for each method and not mix multiple methods in a single test.

no problem @zemirco , fixed.

good job! thank you

authors: DrPsychick zemirco

repo: zemirco/keycloak


text:
higher level libraries listed in the readme proper section

Hello, I've noticed, that more and more often people ask for things not directly related to ruby-kafka itself (as a lower level driver). I propose a proper section, where all the tools that are ruby-kafka dependent and that have stable development are listed.
Please move it to the top / bottom accordingly to your view on where section like that should be.
AS IS: There is no section that would point people to solutions that are ruby-kafka dependent, but that provide a higher level abstractions.
TO BE: A Higher level libraries section with all the frameworks and tools that are based on ruby-kafka (that I know), but that provide some additional functionalities and that can be used "out of the box" without having to understand how things work on a ruby-kafka and kafka level.

@dasch  I highly doubt, that the ci fail is related to my changes :D

@mensfeld the CI is a bit flaky, unfortunately.
:+1:

source: gharchive/pull-request

authors: dasch mensfeld

repo: zendesk/ruby-kafka

license_type: permissive

license_source: bigquery


text:
src_dir is deprecated

Coveralls throws errors when src_dir is set.

Thanks, @Koopzington! Merged to develop for release with 2.7.0.

authors: Koopzington weierophinney

repo: zendframework/zend-dom

license_source: github-api


text:
Update head-script.md

[X] Is this related to documentation?
typo: Missing > at the example

Thanks, @rcapile!

sorry I made things worse.
The documentation uses >  to create a quote. It works fine in GitHub, but breaks completely at zf doc site.
https://docs.zendframework.com/zend-view/helpers/head-script/#headscript
I looking up if this a bug from mkdocs or there is something missing

ping @froschdesign
what do you think about it?

@rcapile

it seems that fenced code blocks inside a quote does not work well with mkdocs

This is not a problem of MkDocs: https://python-markdown.github.io/extensions/fenced_code_blocks/#syntax

I just find out this is a known bug with no fix in sight
https://github.com/Python-Markdown/markdown/issues/53

@rcapile

I just find out this is a known bug with no fix in sight

Unfortunately, it's not supported and not a bug.

@froschdesign do you think we can solve it somehow by separate script in our template?
As we are doing couple other things - table_fix_pipes.php, table_responsive.php, etc...

@webimpress
As workaround we can replace the backticks with the standard Markdown for code blocks (4 spaces). Then we can rewrite the HTML from:

…

to

…

Then the code can be read but without colour.

@rcapile all is working fine now :) We have made some changes in the template and fenced code blocks are working correctly. Thanks!

authors: froschdesign rcapile webimpress

repo: zendframework/zend-view


text:
[3.0] RFC: Split branches with 2.x and 3.x please

Split branches with 2.x and 3.x please.
I can see many issue opened for 3.0. the main zf2 branch only have two main branch, master and develop,
Should we split 2.x and 3.x into two branches? that we can easily keep watching the 2.x stable branch and 3.x develop branch ?

@netroby http://framework.zend.com/blog/announcing-the-zend-framework-3-roadmap.html . If I understand correctly 2.4 needs to be released. Then it will be split into individual components, and there after 3.0 development starts. ( Was also reading something about 2.5 may or may not need. Things are still not so clear though )

master -> this branch will catch up the latest stable (3.0 stable ?)
develop -> this branch will match the 3.x develop
2.x-stable -> this branch will match 2.x stable branch
split into different branch can be friendly to developers who want to track the product  (2.x was heavily using )

In this moment we are discussing to find best approach.. But the next step is 2.4

@netroby It makes no sense at this time to split into separate branches. The repo will look quite different once we split out the components, and any on-going 2.X development after 2.4 will be security and critical bugfixes only — which we can apply to branches checked out from the latest release tags.

source: gharchive/issue

authors: gianarb harikt netroby weierophinney


text:
浏览记录模块有问题

浏览记录部分的滑动有问题，只能直接滑到最左/最右的么，如果有很多条的浏览记录，中间部分的看不到了,如果我滑到了最右，访问浏览记录最前面的数据，也不会滑到最左边，没有继续优化么

你好，很遗憾！该项目不再维护，推荐使用vue3+vite2 研发的 egg-admin-pro


text:
Add test for registration of integration stack components

Pre-requisites
Please ensure you have done the following:

[x] I have read the CONTRIBUTING.md document.
[x] If my change requires a change to the documentation, I have updated the documentation accordingly.
[x] I have added tests to cover my changes.

Types of changes

[ ] 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 change)

Describe changes
Add test for registration of integration stack components

The tool to debug it is tmate and you can find a usage of it here: https://github.com/tiangolo/sqlmodel/blob/main/.github/workflows/publish.yml

@htahir1 Thanks!

repo: zenml-io/zenml


text:
Wrong output from printk() with CONFIG_CBPRINTF_NANO=y

Describe the bug
I want to use CONFIG_CBPRINTF_NANO=y.
For %lu the output can be wrong
To Reproduce
I take the blinky sample from zephyr\samples\basic\blinky
I add to prj.conf: CONFIG_CBPRINTF_NANO=y
I add the following code to main()
const unsigned int ui  =  4000000000U;
const   signed int sip = +2000000000;
const   signed int sin = -2000000000;

const unsigned long ul  =  4000000000UL;
const   signed long slp = +2000000000L;
const   signed long sln = -2000000000L;

printk("ui: %u\n", ui);
printk("si?: %d - %d\n", sin, sip);

printk("ul: %lu\n", ul);
printk("sl?: %ld - %ld\n", sln, slp);

Expected behavior
Output should be:
ui: 4000000000
si?: -2000000000 - 2000000000
ul: 4000000000
sl?: -2000000000 - 2000000000
Output is:
ui: 4000000000
si?: -2000000000 - 2000000000
ul: 18446744073414584320
sl?: -2000000000 - 2000000000
Impact
Can't use CONFIG_CBPRINTF_NANO=y
Environment (please complete the following information):

OS: Windows 10
Toolchain: nRF connect SDK 1.60 with "Booting Zephyr OS build v2.6.0-rc1-ncs1"

Please see #38188 for the fix.

authors: CanastraRF npitre

repo: zephyrproject-rtos/zephyr


text:
BLE central_ht only receives 7 notifications

Discussed in https://github.com/zephyrproject-rtos/zephyr/discussions/38760
Originally posted by 1hannah11 September 23, 2021
Hi, I've been using the Bluetooth Central_ht sample with a few changes (displaying data differently and changed uuids for my peripheral) and I only receive 7 "notifications" from the notify_func, although I am constantly sending data from the peripheral which is connected. after 7 notifications it doesn't disconnect or unsubscribe it just acts as if its not receiving any data. If i connect a different central to the peripheral I receive constant data as I should be.
I am using a microbit V1 for the BLE peripheral and a Microbit V2 as the BLE central.  The code for the peripheral is .ino.
Does any one know why I am encountering this problem?
Changes I made to the Central_ht sample:
//Declaring Temp Service UUIDs
#define BT_UUID_TEMP_SERVICE_VAL 0xccc0  //declares uuid
#define BT_UUID_TEMP_SERVICE \
	BT_UUID_DECLARE_16(BT_UUID_TEMP_SERVICE_VAL) //creates 16 bit uuid
//Temperature reading characterisatic uuid
#define BT_UUID_CHARACTERISTIC_VAL 0xccc1
#define BT_UUID_TEMP_READING\
	BT_UUID_DECLARE_16(BT_UUID_CHARACTERISTIC_VAL)

And:
static uint8_t notify_func(struct bt_conn *conn,
			   struct bt_gatt_subscribe_params *params,
			   const void *data, uint16_t length)
{

	if (!data) {
		printk("[UNSUBSCRIBED]\n");
		params->value_handle = 0U;
		return BT_GATT_ITER_STOP;
	}

	float rawData = ((float *)data)[0];
	double temperature = (float)rawData;

	printf("Temperature %gC.\n", temperature);

	return BT_GATT_ITER_CONTINUE;
}

@1hannah11

it just acts as if its not receiving any data.

Can you enable CONFIG_BT_DEBUG_GATT and then post the output you get in the central please?

I just tested the vanilla sample and works fine. This must be on your code. I suggest you ask in Discord or go back to the original GitHub discussion because this doesn't look like a bug in Zephyr.


text:
Modbus RTU allow non-compliant client configuration

The Modbus RTU driver (modbus_serial.c) hard-codes the nr of stopbits for the serial line to 1 if using parity or 2 without parity.
This corresponds to the Modbus RTU specification but there exists sensor devices which sends non-conform RTU frames with one stopbit and no parity.
In this case the modbus rtu driver reports a "frame length error" without delivering the data - at least on the nrf52 platform.
Background:

If a nrf52840 is configured to 2 stopbits, it not only sends 2 stopbits but it also expects receiving two stopbits. Effectly it is a parity set to mark which is a hardware restriction.
When hardcoding modbus_serial.c to one stopbit, this specific (misbehaved) sensor works.

Expected behavior
The nr of stopbits (1 or 2) should be a modbus config parameter which defaults to the modbus rtu specification when not defined (0).
Impact
None
Logs and console output
[10:22:29.106,384]  modbus_serial: Frame length error
Environment (please complete the following information):

OS: Linux
Toolchain Zephyr SDK
Commit: c71dd808345b33b005a9cbba0a1f22edec729daf

This corresponds to the Modbus RTU specification but there exists sensor devices which sends non-conform RTU frames with one stopbit and no parity.

This is not a bug because, as you write, the frames are not spec compliant and therefore your sensor is not a MODBUS RTU device. There is https://github.com/zephyrproject-rtos/zephyr/pull/40558 to allow this kind of frames but that should be limited to client configuration.

Ok, but adding a parameter eg. "nr_stopbits" to "struct modbus_iface_param" which defaults (when 0) to the RTU standard would solve the problem for modbus client as well for server configurations without side effects (or not?)

This is related to https://github.com/zephyrproject-rtos/zephyr/pull/40558 We will update the pr in a few weeks.

authors: chrta jfischer-no mjm987


text:
Clicking a link leads to "Sorry, Page Not Found", where they ask to notify this GitHub

Hi!
I'm currently trying to implement the qdec peripheral in my code. While browsing the documentation I ended up at a "Sorry, Page Not Found"-page, where they kindly ask to report this to you.
Reproduce :

Go to this page: https://docs.zephyrproject.org/3.0.0/reference/devicetree/bindings/sensor/nordic%2Cnrf-qdec.html
Click the on the "latest development version" at the top of the page.

This is not that big of an issue, but since it says "If you got this error by following a link, please let us know by creating an issue on GitHub", I figured why not?
Have a nice day!

dts bindings have been relocated, in this case https://docs.zephyrproject.org/latest/build/dts/api/bindings/sensor/nordic,nrf-qdec.html. The "latest" link is added to all pages, but those that are removed in "latest" will lead to 404.

authors: Tsjerfell gmarull


text:
WebUSB sample not recognized correctly in Windows 10

Describe the bug
Automatic driver installation does not work for the WebUSB sample. It just gets assigned the null GUID and is shown with a warning triangle. Zadig also shows that the device did not get the correct WICD. On Linux, the WebUSB stuff seems to work fine, so I presume this is mostly related to the MS OS 2.0 descriptors / BOS entry. The MS OS 1.0 stuff seems to be irrelevant for anything newer than Windows 7.
To Reproduce

Build the WebUSB sample with an nRF52 or nRF53 DK. (I don't think this is hardware-related.)
Plug into a Windows 10 machine or VM

Expected behavior
The WinUSB driver should be installed automatically, the device should not be should with a warning symbol in the device manager. The GUID should be reported correctly.
Impact
This is a showstopper for me since it prevents me from implementing my current project: A Zephyr implementation of CMSIS-DAP v2. The automatic driver installation part is mandatory to conform to the spec.
Environment (please complete the following information):

Windows 10
Zephyr 3.3.0

This is a showstopper for me since it prevents me from implementing my current project: A Zephyr implementation of CMSIS-DAP v2. The automatic driver installation part is mandatory to conform to the spec.

Have you seen this? https://github.com/zephyrproject-rtos/zephyr/pull/53798

Yes, I'm trying to finish that one for Johann. :)

The problem is definitely in MS OS 2.0 descriptor. One of the issue is that
https://github.com/zephyrproject-rtos/zephyr/blob/c6c93e394d6a52c4541d39135681fc81b8df7dd5/samples/subsys/usb/webusb/src/main.c#L40
hardcodes the first interface index to 0x02 while the sample when built for nrf52840dk_nrf52840 has only one interface with number 0.
Changing the index itself doesn't seem to be enough though.

authors: carlescufi maxd-nordic tmon-nordic


text:
Bluetooth: Mesh: Update models metadata API

Introduction
The current implementation of the models metadata API in Bluetooth Mesh subsystem is as follows:

Current API has metadata pointer const struct bt_mesh_models_metadata_entry * in the model contexts that have metadata (For example: in struct bt_mesh_health_srv). The actual variable that is used for preparing models metadata status response (const struct bt_mesh_models_metadata_entry * const * const metadata;) resides in struct bt_mesh_model in access.h. The metadata double pointer in access layer gets simply assigned from the metadata pointer in corresponding model context. The pointer in model context has no other usage.

The metadata double pointer in access.h adds extra complexity.

Problem description
This implementation is inefficient, a bit complex, and requires two variants of model initializer macros for each model that supports optional metadata.
Proposed change
Simplify and optimize API by removing redundant pointer in model context.
Detailed RFC

Remove redundant pointer from model context.
Just have a single variant of a model initializer macro in model header file.
Replace double pointer by single pointer in access.h.

Proposed change (Detailed)

Remove redundant pointer from model context.
Just have a single variant of a model initializer macro in model header file.
Replace double pointer by single pointer in access.h.

See PR #71281.
Dependencies
Zephyr code is affected only in three files:

Health Server Model context and Health Server Model init macro in health_srv.h header
Model context in access.h
Relevant updates in shell.h

Impact:

For implementations not using optional metadata feature of health server model: nothing changes.
For implementations using optional metadata feature: address of the application defined metadata structure will have to be supplied at a different place than before. This should be trivial change. This is documented in migration guide.

Concerns and Unresolved Questions
none so far
Alternatives
No specific alternative. Proposed solution in PR #71281 emerged as a result of design discussions.

Architecture WG:

No objections


text:
net: coap_client: GET with observe

Looked through the code and got the distinct impression that observe isn't supported (I'd be chuffed if someone told me I was mistaken though). It seems like a low-to-mid complexity feature to implement so I may end up taking a crack at it but I figured I'd ping here first so see what's up @rlubos  @jukkar

Have you looked at the CoAP client and server samples? They both demonstrate the observe functionality.

@kartben I have but this enhancement is regarding the actual coap_client

For reference, I tried modifying handle_response() so that it doesn't unset request_ongoing flag when the request is an observe:
fail:
	client->response_ready = false;
	if (ret != 0 || !coap_request_is_observe(&internal_req->request)) {
		internal_req->request_ongoing = false;
	}
	return ret;

This worked beautifully. But there's still the architectural issues remaining. Since coap_client wasn't written to be a infinity-recv:ing daemon, there's no API:s to shut it down/cancel requests and so forth. That request will stick around forever. Not sure what the cleanest "cancel" API would be tho...

Please feel free to rip this apart: https://github.com/zephyrproject-rtos/zephyr/pull/72159 @rlubos @jukkar

Well, the PR is merged so which should theoretically mean this issue is closabe. But the PR was severely incomplete and should really be augmented so let's keep this open :P

The incomplete PR has been augmented so this is actually supported

authors: kartben tautologyclub


text:
SPI DMA with SPI FLASH not working for STM32H7XX

Describe the bug
SPI DMA with serial flash not working for STM32H7XX due to cache memory validation which got added in this PR,
#57786
To Reproduce
Steps to reproduce the behavior:

We have tested this example with some modification for NUCLEO STM32H743ZI with Click 11 ( External Flash - https://www.mikroe.com/flash-11-click) for this https://github.com/zephyrproject-rtos/zephyr/tree/v3.6.0/samples/drivers/spi_flash
I will attached the modified code soon.
In Project Config ( Prj.conf ), If we disable this CONFIG_SPI_STM32_DMA=n, SPI Flash is working.
In Project Config ( Prj.conf ), If we enable this CONFIG_SPI_STM32_DMA=y, SPI Flash is not working.
If we keep CONFIG_SPI_STM32_DMA=y and comment this code at line number 959 to 964, it is working

By further debugging, It is failing buf_within_nocache memory validation.

Expected behavior
It should work with buf_within_nocache along with SPI DMA
Logs and console output
Not working Logs :

Working Logs after commenting below code :

Environment (please complete the following information):

OS: Windows
Toolchain : Zephyr SDK, ...
Commit SHA or Version used : Zephyr v3.6.0

cc : @darshanmirajkar-eaton

triaging as low as this seems to be specific to just one SoC series

Commit SHA or Version used : Zephyr v3.6.0

As mentionned V3.6.0 is no longer supported. Would you m mind confirming that your seeing the same issue on v3.7.0 ?

authors: bhardadinesh-eaton erwango kartben


text:
tests/power/power_states fail on arduino101:x86

Commit: 0d0b221efa6abab94204cd3663641c92a95b1126
E#1      @srrsotc03/a101-05  console output: ***** delaying boot 1000ms (per build configuration) *****
E#1      @srrsotc03/a101-05  console output: ***** Booting Zephyr OS 1.13.0-rc1 (delayed boot 1000ms) *****
E#1      @srrsotc03/a101-05  console output: Running test suite test_power_states
E#1      @srrsotc03/a101-05  console output: ===================================================================
E#1      @srrsotc03/a101-05  console output: starting test - test_power_state
E#1      @srrsotc03/a101-05  console output: Quark SE(arc): Power Management sample application
E#1      @srrsotc03/a101-05  console output: Entering SYS_POWER_STATE_CPU_LPS state
E#1      @srrsotc03/a101-05  console output: Exiting SYS_POWER_STATE_CPU_LPS state
E#1      @srrsotc03/a101-05  console output: Not enough time for PM operations (ticks: 101).
E#1      @srrsotc03/a101-05  console output: Time elapsed from suspend to resume is 5010 milliseconds
E#1      @srrsotc03/a101-05  console output: Back to the application
E#1      @srrsotc03/a101-05  console output:
E#1      @srrsotc03/a101-05  console output: Entering SYS_POWER_STATE_CPU_LPS_1 state
E#1      @srrsotc03/a101-05  console output: Exiting SYS_POWER_STATE_CPU_LPS_1 state
E#1      @srrsotc03/a101-05  console output: Entering SYS_POWER_STATE_DEEP_SLEEP state
E#1      @srrsotc03/a101-05  console output: Woke up with RTC (pin:1)
E#1      @srrsotc03/a101-05  console output: Exiting SYS_POWER_STATE_DEEP_SLEEP state
E#1      @srrsotc03/a101-05  console output: Entering SYS_POWER_STATE_DEEP_SLEEP_1 state

There is no output after this, assuming target never woke up from deep sleep.

#9576 fixes this, hence closing.

authors: nniranjhana yerabolu


text:
boards: cc3220sf: Fix board toolchain capability metadata

The cc3220sf_launchxl board is AFAICT not compatible with the
toolchain variant 'gnuarmemb'. To avoid triggering CI failures we
remove this compatibility declaration from the metadata.
Signed-off-by: Sebastian Bøe sebastian.boe@nordicsemi.no

NB: I am certain that cc3220sf_launchxl is broken with gnuarmemb. Try the sample samples/net/wifi to observe this.
But I don't know why, or if this is expected. So it might be that the correct fix here is to resolve the incompatibility, not to drop compatibility.

Error message:
ccache /home/sebo/Downloads/gcc-arm-none-eabi-7-2018-q2-update/bin/arm-none-eabi-gcc -DBUILD_VERSION=zephyr-v1.13.0-928-g9e676b485f -DKERNEL -DSL_PLATFORM_MULTI_THREADED -DSL_SUPPORT_IPV6 -DUSE_CC3220_ROM_DRV_API -D_FORTIFY_SOURCE=2 -D__LINUX_ERRNO_EXTENSIONS__ -D__ZEPHYR__=1 -I../../../../kernel/include -I../../../../arch/arm/include -I../../../../soc/arm/ti_simplelink/cc32xx -I../../../../soc/arm/ti_simplelink/cc32xx/include -I../../../../soc/arm/ti_simplelink/include -I../../../../boards/arm/cc3220sf_launchxl -I../../../../include -I../../../../include/drivers -Izephyr/include/generated -isystem /home/sebo/Downloads/gcc-arm-none-eabi-7-2018-q2-update/bin/../lib/gcc/arm-none-eabi/7.3.1/include -isystem /home/sebo/Downloads/gcc-arm-none-eabi-7-2018-q2-update/bin/../lib/gcc/arm-none-eabi/7.3.1/include-fixed -I/home/sebo/Downloads/gcc-arm-none-eabi-7-2018-q2-update/arm-none-eabi/include -I../../../../ext/hal/cmsis/Include -I../../../../ext/hal/ti/simplelink/source/ti/devices/cc32xx/. -I../../../../ext/hal/ti/simplelink/source/ti/devices/cc32xx/inc -I../../../../ext/hal/ti/simplelink/source/ti/devices/cc32xx/driverlib -I../../../../ext/hal/ti/simplelink/. -I../../../../ext/hal/ti/simplelink/source -I../../../../ext/hal/ti/simplelink/kernel/zephyr/dpl -I../../../../drivers/wifi/simplelink/. -I../../../../ext/hal/ti/simplelink/source/ti/drivers/net/wifi/porting -I../../../../ext/hal/ti/simplelink/source/ti/drivers/net/wifi/bsd -Og -g -Wall -Wformat -Wformat-security -Wno-format-zero-length -imacros /home/sebo/zephyr/samples/net/wifi/b/zephyr/include/generated/autoconf.h -ffreestanding -Wno-main -mthumb -mcpu=cortex-m4 -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-strict-overflow -Wno-pointer-sign -Wno-unused-but-set-variable -fno-reorder-functions -fno-defer-pop -Werror=implicit-int -Wpointer-arith -ffunction-sections -fdata-sections -mabi=aapcs -march=armv7e-m -std=c99 -MD -MT zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj -MF zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj.d -o zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj   -c /home/sebo/zephyr/arch/arm/core/offsets/offsets.c
In file included from ../../../../kernel/include/kernel_structs.h:10:0,
                 from /home/sebo/zephyr/arch/arm/core/offsets/offsets.c:26:
../../../../include/kernel.h: In function 'k_enable_sys_clock_always_on':
../../../../include/kernel.h:1677:10: error: 'ENOTSUP' undeclared (first use in this function)
  return -ENOTSUP;
          ^~~~~~~
../../../../include/kernel.h:1677:10: note: each undeclared identifier is reported only once for each function it appears in

Codecov Report

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

@@            Coverage Diff             @@
##           master   #10554      +/-   ##
==========================================
- Coverage   53.34%   53.18%   -0.16%
==========================================
  Files         210      210
  Lines       25825    25825
  Branches     5686     5686
==========================================
- Hits        13776    13735      -41
- Misses       9734     9781      +47
+ Partials     2315     2309       -6

Impacted Files
Coverage Δ

include/posix/posix_sched.h
0% <0%> (-100%)
:arrow_down:

lib/posix/pthread_barrier.c
0% <0%> (-100%)
:arrow_down:

lib/posix/pthread_cond.c
62.5% <0%> (-20.84%)
:arrow_down:

lib/posix/pthread.c
68.03% <0%> (-12.33%)
:arrow_down:

lib/posix/pthread_mutex.c
76.38% <0%> (-1.39%)
:arrow_down:

lib/posix/pthread_sched.c
62.5% <0%> (+20.83%)
:arrow_up:

Continue to review full report at Codecov.

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

LGTM.
The 'gnuarmemb' was a copy-paste error.  I've only been building with Zephyr toolchain up to now.
I know there is more interest in adding the TI CGT, but haven't had the cycles to get back to that effort.

Error message:

what test shows this?

NB: I am certain that cc3220sf_launchxl is broken with gnuarmemb. Try the sample samples/net/wifi to observe this.

The issue I don't think is exactly cc3220sf_launchxl related, its that we are pickup errno.h from ./ext/hal/ti/simplelink/source/ti/drivers/net/wifi/bsd/errno.h when building with gnuarmemb, not sure why right now.

Ok, so the issue is related to how we set the system includes for zephyr toolchain vs gnuarmemb. For zephyr we set --sysroot /opt/zephyr-sdk-0.9.3/sysroots/armv5-zephyr-eabi/usr (which gets errno.h from ther).  On gnuarmemb we don't set --sysroot

@GAnthony any idea what's the implication if we drop include the bsd dir:
diff --git a/drivers/wifi/simplelink/CMakeLists.txt b/drivers/wifi/simplelink/CMakeLists.txt
index 43fc9efb41..bfbf59beb8 100644
--- a/drivers/wifi/simplelink/CMakeLists.txt
+++ b/drivers/wifi/simplelink/CMakeLists.txt
@@ -4,7 +4,6 @@ if(CONFIG_WIFI_SIMPLELINK)
     $ENV{ZEPHYR_BASE}/ext/hal/ti/simplelink/kernel/zephyr/dpl
     $ENV{ZEPHYR_BASE}/ext/hal/ti/simplelink/source
     $ENV{ZEPHYR_BASE}/ext/hal/ti/simplelink/source/ti/drivers/net/wifi/porting
-    $ENV{ZEPHYR_BASE}/ext/hal/ti/simplelink/source/ti/drivers/net/wifi/bsd
     )
   zephyr_sources(
     simplelink_support.c

@galak, I think the bsd include dir line can be removed (it compiles without it there).
I think that bsd include directory is a vestige from older days when the simplelink driver was calling the TI BSD socket APIs.   Now, it's calling underlying sl_ socket APIs.
The SDK host driver needs both the system errno.h and SDK's errno.h to do a mapping of error numbers, but that is handled by explicitly including .../bsd/errno.h in the source.
So, bottom line, I think it is OK to remove.

Updated the PR to remove the include path instead of dropping support for gnuarmemb.

authors: GAnthony SebastianBoe codecov-io galak


text:
Timer rewrite phase 3: drivers

Just like the last (still active) PR #10303 this builds on top of the previous one and adds extra patches.
In this case, it takes advantage of the much simpler timer driver API to actually implement much simpler drivers for ARM SysTick and Intel HPET.  Seriously, these are like 4x smaller now.
They support all the features the old ones did, and now work with tickless pervasively (and enable tickless by default, as there's essentially no downside anymore).
Please review.  Also please test if you can, especially on SysTick hardware (I've only run tests on Qemu and the two boards I have on my desk).
I have similar rewrites in progress for Xtensa and RISC-V MTIME (which are very similar in structure to HPET) and will append those here as I finish them.
While this can be merged as a single unit, it's probably best to merge the older pull request first to smooth the transition.  I'll rebase this one as soon as the older one goes in.

Codecov Report

Merging #10556 into master will decrease coverage by 0.1%.
The diff coverage is 85.56%.

@@            Coverage Diff             @@
##           master   #10556      +/-   ##
==========================================
- Coverage   53.18%   53.08%   -0.11%
==========================================
  Files         210      213       +3
  Lines       25825    25824       -1
  Branches     5686     5693       +7
==========================================
- Hits        13735    13708      -27
- Misses       9781     9807      +26
  Partials     2309     2309

Impacted Files
Coverage Δ

kernel/include/kernel_structs.h
100% <ø> (ø)
:arrow_up:

kernel/include/kswap.h
100% <ø> (ø)
:arrow_up:

kernel/include/wait_q.h
100% <ø> (ø)
:arrow_up:

drivers/timer/sys_clock_init.c
0% <0%> (ø)

kernel/include/timeout_q.h
100% <100%> (+4.16%)
:arrow_up:

kernel/include/ksched.h
94.25% <100%> (ø)
:arrow_up:

include/kernel.h
98.48% <100%> (-0.05%)
:arrow_down:

kernel/idle.c
100% <100%> (+11.11%)
:arrow_up:

kernel/work_q.c
94.73% <100%> (ø)
:arrow_up:

kernel/thread.c
93.5% <100%> (+0.04%)
:arrow_up:

... and 15 more

Continue to review full report at Codecov.

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

Update with some fixes to HPET...
...and a reworked nrf_rtc_timer driver that really wants review from Nordic folks.  It works for me on a nrf52_pca10056 at least, but needs validation on broader hardware.  The size should make review easy at least.

Rebased.  Fixed an issue on nrf where the driver and kernel don't care about the symbol name of the ISR, but one test does.

@andyross I ran the dining philosophers sample on HiFive 1 in both tickfull and tickless configurations and it appears to be running happily with the new driver.

Rebased.  Add an xtensa driver (tested so far only on qemu, my esp32 is acting funny at the moment).  Also adds a workaround for nrf52_bsim along the lines of the existing qemu one (i.e. disable tickless when the we're in a host emulation environment that uses host time as the reference).
At this point I think this whole path is complete.  I don't plan on doing rewrites of the Pulpino driver (for which I don't have hardware) or ARC (for which my only hardware is... cumbersome).  Nios II would be possible as it has a qemu variant, but looking at it the hardware seems to be a regular interrupt kind of thing and wouldn't support tickless anyway (rather: it's possible the hardware does, but the existing driver doesn't use those bits).

Rebased.  Fixed a nasty initialization bug on ARM that was exposed by the mps2 target.  Added @nategraff-sifive's suggested fix for the 64 bit rollover condition (that I still don't really see, looking at it -- though this version is still optimizable by the compiler to the 32 bit one we want, so there's not reason not to do it this way).
Should be good to merge at this point.  Please review.

APIC timer refactoring is coming as part of x86_64, FWIW.  In fact the need for that is sort of the initial germ that got me started on this whole timer saga.

Rebased and pushed a final version.  All code is present, all tests are passing.  All needed workaround (e.g. for nrf54_bsim's spin loops) are already in the tree.  I think all criticism is addressed.  Needs final review.

authors: andyross codecov-io nategraff-sifive


text:
samples: usb: remove app.overlay

Remove app.overlay because referenced node
was remove in the commit 5071eeec8bb1
("dts: Remove unused virtualcom device node from dts")'.

So how do we tell now which serial device to use in the case of usb cdc?

So how do we tell now which serial device to use in the case of usb cdc?

CONFIG_UART_CONSOLE_ON_DEV_NAME="CDC_ACM_0" see samples/subsys/usb/console/prj.conf

I got it now, there is also DT_UART_CONSOLE_ON_DEV_NAME. 5071eee should be reverted and CONFIG_UART_CONSOLE_ON_DEV_NAME="CDC_ACM_0" removed from samples/subsys/usb/console/prj.conf

authors: jfischer-phytec-iot nashif


text:
dts: xilinx_zynqmp: Remove stray 0 from interrupt-parent

'interrupt-parent' should contain just the phandle of the node
interrupts are sent to.
This node (gic: interrupt-controller@f9010000) doesn't generate any
interrupts, so the 'interrupt-parent' value is never used (this is why
it wasn't caught). It'll give an error later with 'interrupt-parent'
declared as 'type: phandle' in bindings though.
Don't know what was intended. Just remove the 0.

Re-based this to master, as I see this as more of a bug fix, so should go into 2.0.0

authors: galak ulfalizer


text:
dts/binding/sensor: Fix ST sensors irq-gpios property being required

Change binding for ST sensors property 'irq-gpios' to optional for the
cases of in which its obvious from the driver that the property is
optional (there's an ifdef based on the #define
DT_INST_0_ST_LIS2DH_IRQ_GPIOS_*).
Signed-off-by: Kumar Gala kumar.gala@linaro.org

@avisconti guessing that maybe all the cases are optional as others are ifdef'd around CONFIG__TRIGGER being enabled.

@avisconti @ulfalizer pls, take a quick look here

LGTM
Just a question: what is the benefit of declaring irq-gpios as optional?

Its a correctness / validation thing.  As we improve validation of dts v bindings noticed a that the binding requires the property but several dts don't have it (so thus its an optional property).

Closed because this change is in the topic-dts branch already.

authors: galak ioannisg


text:
Stm32 g0 improvements

Add device tree nodes and peripheral support for STM32G0.
Add alt mode gpio mux support definitions for STM32G0 71xx and 81xx and 41xx and 31xx series for pinmux helper.
Signed-off-by: Kieran Levin ktl@frame.work

I will look at splitting this out.

Please rebase, following merge of #23285

I started breaking this out to:
https://github.com/zephyrproject-rtos/zephyr/pull/23657
https://github.com/zephyrproject-rtos/zephyr/pull/23659


text:
xtensa: log: add missing strdup

Fix missing log_strdup call
Signed-off-by: Sylvio Alves sylvio.alves@espressif.com

Hm... these are fatal error log which means the logging subsystem is already in immediate mode (AFAIK). IIRC, there is no need to do strdup() when in immediate mode. Did logging complain about missing strdup()?

Hm... these are fatal error log which means the logging subsystem is already in immediate mode (AFAIK). IIRC, there is no need to do strdup() when in immediate mode. Did logging complain about missing strdup()?

Yes. Right after app crashes, it floods the terminal with lots of missing strdup(). This PR fixes that. However, I couldn't figure out whether it is ESP32 issue or general.

(Mine is a soft -1, btw.  No complaints about merging per se, I just don't think this is a root cause and want someone to figure out whether it is or not.  Feel free to override.)

@andyross, I guess it might related to ESP32 environment then. Let me re-check the linker script on logging stuff.
[00:00:00.617,000] <err> os:  ** FATAL EXCEPTION
[00:00:00.617,000] <err> os:  ** CPU 0 EXCCAUSE 28 (load prohibited)
[00:00:00.617,000] <err> os:  **  PC 0x400d153d VADDR 0xf0004
[00:00:00.617,000] <err> os:  **  PS 0x60f20
[00:00:00.617,000] <err> os:  **    (INTLEVEL:0 EXCM: 0 UM:1 RING:0 WOE:1 OWB:15 CALLINC:2)
[00:00:00.617,000] <err> os:  **  A0 0x8008af06  SP 0x3ffe7210  A2 0xf0004  A3 0x3ffc0ce0
[00:00:00.617,000] <err> os:  **  A4 0x60f23  A5 0x3ffc0bc8  A6 (nil)  A7 (nil)
[00:00:00.617,000] <err> os:  **  A8 (nil)  A9 0x3ffe71e0 A10 0x2c A11 0x120c
[00:00:00.617,000] <err> os:  ** A12 0x241 A13 0x7fff A14 (nil) A15 (nil)
[00:00:00.617,000] <err> os:  ** LBEG 0x400d1b80 LEND 0x400d1b8a LCOUNT (nil)
[00:00:00.617,000] <err> os:  ** SAR 0x19
[00:00:00.630,000] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00:00:00.630,000] <err> os: Current thread: 0x3ffc08d0 (unknown)
[00:00:00.733,000] <err> log: argument 2 in source os log message " ** CPU %d EXCCAUSE %d (%s)" missinglog_strdup().
[00:00:00.805,000] <err> log: argument 1 in source os log message ">>> ZEPHYR FATAL ERROR %d: %s on CPU %d" missinglog_strdup().
[00:00:00.820,000] <err> log: argument 2 in source log log message "argument %d in source %s log message "%s" missinglog_strdup()." missinglog_strdup().
[00:00:00.820,000] <err> log: argument 1 in source log log message "argument %d in source %s log message "%s" missinglog_strdup()." missinglog_strdup().
[00:00:00.831,000] <err> log: argument 2 in source log log message "argument %d in source %s log message "%s" missinglog_strdup()." missinglog_strdup().

Yeah, the smoking gun is that the log subsystem is warning about its own log messages needing a strdup. :)
I don't know exactly how this is supposed to work, but I suspect it relies on string literals living in a specific address range that the linker tells Zephyr about.  My guess this is missing on esp32.

Hi, thanks for those inputs. In fact it is related to linker/rom area on ESP32.
I'll open a new PR once I get it fixed.

authors: andyross dcpleung sylvioalves


text:
hal: nxp: Update to SDK 2.10.0

Updating to the SDK 2.10.0 for select platforms.
Fixes #37619
Signed-off-by: David Leach david.leach@nxp.com

@dleach02 I need 2 days full testing on this, will feedback once finish

@dleach02 looks like failure with lpcxpresso55s69_ns. I know @microbuilder was asking about updating the SDK around the TFM integration, so he might be aware of what fix we need for TFM.

@dleach02 are we waiting on something here to merge things here?

@galak, I'm just waiting on the finish of an internal testing run on our HW range. Should be ready by tomorrow (it found issues over the weekend).

@dleach02 I merged the HAL side of this, can you update this PR now.

Okay... I messed that up... give me a moment to fix this

Okay... my 'git-fu' is not strong... new PR: #37680

authors: dleach02 galak hakehuang


text:
Rework the support for Adafruit 2.8 TFT display on Arduino Nano 33 BLE

This is a follow-up PR to https://github.com/zephyrproject-rtos/zephyr/pull/43927
First commit extends the DTS for Arduino Nano 33 BLE with the definition for the arduino nano r3 header as per the binding document. The second changes the way we make the Adafruit 2.8 TFT display work. It now registers a virtual connector that maps 3 pins from the regular arduino Rev3 header to the nano pins by referencing the arduino_nano_header label. We also alias the I2C and SPI interfaces so that they can be used directly by the overlay for the shield.
The mapping is only included if the support for the shield is built with machine set to arduino_nano_33_ble and has no effect on any peripherals.
@jfischer-no @carlescufi

This can be further improved, I will write about this in detail ASAP.

@brgl Please take a look at https://github.com/brgl/zephyr/pull/1,

@carlescufi does it look good to you now?

authors: brgl jfischer-no


text:
drivers: clock_control: clock_stm32_ll_h7: Make LSE driving configurable

Make the LSE driving capability of a STM32H7 configurable via devicetree.
Fixes #44737.
Signed-off-by: Benedikt Schmidt benedikt.schmidt@embedded-solutions.at

Tested on a H735.
Reference manual checked for:

STM32H723XX
STM32H735XX
STM32H725XX
STM32H7A3XX
STM32H7B3XX
STM32H743XX
STM32H753XX
STM32H750XX
STM32H745XX
STM32H747XX

@benediktibk  thanks for adding this property.
Could it be included in other stm32 mcus which have that feature on their LSE (stm32f0, stm32G4 etc) in a similar way,

My results from checking the reference manuals from the already available SoCs in zephyr:
has the feature:

stm32f030x4
stm32f030x8
stm32f030xc
stm32f070xb
stm32f031x6
stm32f051x8
stm32f072xb
stm32f091xc
stm32f098xx
stm32f302x8
stm32f303x8
stm32f303xc
stm32f303xe
stm32f334x8
stm32f373xc
stm32u575xx
stm32u585xx
stm32wb55xx
stm32f723xx
stm32f745xx
stm32f746xx
stm32f756xx
stm32f767xx
stm32f769xx
stm32g0b0xx
stm32g030xx
stm32g050xx
stm32g070xx
stm32g0b1xx
stm32g0c1xx
stm32g031xx
stm32g041xx
stm32g051xx
stm32g061xx
stm32g071xx
stm32g081xx
stm32g4a1xx
stm32g431rb
stm32g441xx
stm32g473xx
stm32g474re
stm32g483xx
stm32g484xx
stm32g491xx
stm32l010xb
stm32l011xx
stm32l031xx
stm32l051xx
stm32l071xx
stm32l072xx
stm32l053xx
stm32l073xx
stm32l4r5xx
stm32l4r9xx
stm32l4s5xx
stm32l412xx
stm32l422xx
stm32l432xx
stm32l433xx
stm32l452xx
stm32l462xx
stm32l471xx
stm32l475xx
stm32l476xx
stm32l496xx
stm32l552xx
stm32l562xx
stm32wl54xx
stm32wl55xx
stm32wle4xx
stm32wle5xx
stm32mp15_m4

does not have the feature:

stm32f100xx
stm32f103xx
stm32f105xc
stm32f107xc
stm32f205xx
stm32f207xx
stm32f401xc
stm32f401xe
stm32f405xx
stm32f407xx
stm32f415xx
stm32f417xx
stm32f437xx
stm32f427xx
stm32f429xx
stm32f410xx
stm32f411xe
stm32f412xx
stm32f413xx
stm32f446xx
stm32f469xx
stm32l151x8a
stm32l151xb
stm32l151xba
stm32l151xc
stm32l152xc
stm32l152xe

Hence, I would continue to add the following bindings, similar to the one of the H7 series:

st,stm32f0-lse-clock.yaml
st,stm32f3-lse-clock.yaml
st,stm32u5-lse-clock.yaml
st,stm32wb-lse-clock.yaml
st,stm32f7-lse-clock.yaml
st,stm32g0-lse-clock.yaml
st,stm32g4-lse-clock.yaml
st,stm32l0-lse-clock.yaml
st,stm32l4-lse-clock.yaml
st,stm32l5-lse-clock.yaml
st,stm32wl-lse-clock.yaml

Does this sound reasonable to you @FRASTM ?

While implementing this I realized that for some SoCs the LSE is not really implemented, at least I couldn't find a call to LL_RCC_LSE_Enable:

F0
F3
F7
G0
L0

I still went ahead and at least added the properties for them.
And there is one more additional problem, stm32_counter kinda is in conflict with the LSE configuration with the clock control. Seems problematic, but for the moment I kept it as it is.

The LPTIM timer as well enables LSE. I feel like only the clock control should enable LSE?

@benediktibk thanks for listing all the stm32 and giving an exhaustive view.

The LPTIM timer as well enables LSE. I feel like only the clock control should enable LSE?

This is right. On going proposal for this is https://github.com/zephyrproject-rtos/zephyr/pull/42097.

@erwango Anything still missing?

authors: FRASTM benediktibk erwango


text:
driver: gpio: npcx: correct the usage of npcx voltage flags

In npcx ec series, two detection levels, 3.3V (default) and 1.8V are supported during gpio configuration. But the current implementation always selects default detection level whether NPCX_GPIO_VOLTAGE_1P8 is set. This PR is a fix for this issue.
The regression has been introduced in b1552001bf0b544b3210b6586ec15167cdbf7bc0
Signed-off-by: Mulin Chao mlchao@nuvoton.com

Flagging as hotfix since this is a regression and causing problem in testing downstream.

authors: MulinChao fabiobaltieri


text:
Drivers: DAI: Intel: DMIC: Shorten unmute ramp time

This change produces more quickly in the stream valid audio samples. The start fade-in ramp can be shortened to 100 ms for 48 kHz and 200 ms for 16 kHz. It was before 200 ms and 400 ms. The updated DMIC hardware in allows to do this change.

Here's two screenshots of captured wavs at 48 kHz and 16 kHz, the signal is lab noise with 50 dB amplification done in audio editor to see the ramp to happen. The start transients are mitigated well by the FW driver controlled HW gain ramps with new durations:


text:
doc: porting: boards: Update the terminology diagram

The current diagram uses a custom font that does not render correctly on some browsers. Replace it with a common font (Courier New) instead so that there are no rendering issues.

@nordicjm @tejlmand can you check if this works fine now?
https://builds.zephyrproject.io/zephyr/pr/71579/docs/hardware/porting/board_porting.html#board-terminology
https://builds.zephyrproject.io/zephyr/pr/71579/docs/_images/board-terminology.svg

@nordicjm @tejlmand can you check if this works fine now?
https://builds.zephyrproject.io/zephyr/pr/71579/docs/hardware/porting/board_porting.html#board-terminology https://builds.zephyrproject.io/zephyr/pr/71579/docs/_images/board-terminology.svg

Is broken, the texts wraps around to a second line after the nrf5340/. Maybe make the svg and text box slightly bigger

@nordicjm @tejlmand can you check if this works fine now?
https://builds.zephyrproject.io/zephyr/pr/71579/docs/hardware/porting/board_porting.html#board-terminology https://builds.zephyrproject.io/zephyr/pr/71579/docs/_images/board-terminology.svg

Is broken, the texts wraps around to a second line after the nrf5340/. Maybe make the svg and text box slightly bigger

Can you check again @nordicjm?

I noticed shadows has been removed in the updated picture.
Is that intentional ?

I noticed shadows has been removed in the updated picture. Is that intentional ?

No, oversight. But no big deal

No, oversight. But no big deal

I agree, if it was a big deal I would have requested changes 😉
Just wanted to pass on my observation, to give the chance of update the picture in case you prefer the shadows.

authors: carlescufi nordicjm tejlmand


text:
kconfig: zephyr: Set default BUILD_NO_GAP_FILL to Y

Set default BUILD_NO_GAP_FILL to Y.
It fixes generation of huge .hex files, even they can have many gigabytes.
.elf files do not have filled gaps, so no any need to fill gaps for .hex.

That might be the case with hex file but is certainly not the case with bin files, for which things like MCUboot signing rely upon

No problem The BUILD_NO_GAP_FILL influence the behaviour for the .hex files.
Just checked with the MCUBoot test application. No issues.
Also many platforms already set it to Y.
Guess, it was not set to Y by mistake.

Hi @nordicjm
Are you still asking for a rework? What exactly?

See also: https://github.com/zephyrproject-rtos/zephyr/pull/71414/commits/2bce63e526856b82d232f24ff4199845b660c5f4

It fixes generation of huge .hex files, even they can have many gigabytes.

To fix something then it must be considered broken 😉
Whether gap fill per default is to be considered broken depends highly on the target. Especially bin files often needs to be gap filled, as a bin file doesn't contain address information.
This change is impacting all board targets (as well as hex, bin,and s19 file conversion) and thus might cause regression which are not discovered until later, because ci doesn't flash all boards.
However, this change does do something good for llvm, because the llvm objcopy doesn't support gap fill per default.
Huge hex files will only be generated on targets where the hex file has content at both low and high addresses in the address space.
For now I would prefer a less intrusive PR, perhaps one which targets the SoC family in question, like it's done here:
https://github.com/zephyrproject-rtos/zephyr/blob/9036400ad0d034a8db05504d3620ce7190deb893/soc/ti/k3/am6x/Kconfig.defconfig#L45-L46
Also feel free to have the adjustment enabled per default when llvm is used as toolchain.

Hi @tejlmand
The mentioned "default y if SOC_" is just a very narrow workaround.
In this commit we are making a fix for all platforms, as there is no use case in Zephyr that requires gap filling in .hex.
Since we don't fill gaps for elf, we don't want to fill them in .hex, especially as a default behavior.

@butok seems you missed:

Especially bin files often needs to be gap filled, as a bin file doesn't contain address information.

even if removing gap fill setting, objcopy will still fill the gap when converting to bin files, because bin files does not contain address information. But now you get gaps filled with 0x00, instead of 0xFF, which is not optimal for a flash.

as there is no use case in Zephyr that requires gap filling in .hex.

https://github.com/zephyrproject-rtos/zephyr/pull/8822

@butok seems you missed:

Especially bin files often needs to be gap filled, as a bin file doesn't contain address information.

even if removing gap fill setting, objcopy will still fill the gap when converting to bin files, because bin files does not contain address information. But now you get gaps filled with 0x00, instead of 0xFF, which is not optimal for a flash.

as there is no use case in Zephyr that requires gap filling in .hex.

#8822

@butok seems you missed:

Especially bin files often needs to be gap filled, as a bin file doesn't contain address information.

even if removing gap fill setting, objcopy will still fill the gap when converting to bin files, because bin files does not contain address information. But now you get gaps filled with 0x00, instead of 0xFF, which is not optimal for a flash.

as there is no use case in Zephyr that requires gap filling in .hex.

#8822

Zephyr is using objcopy to generate binary files from .elf (not from .hex)
As this configuration parameter has no influence on .bin, the .bin file is not touched.

Zephyr is using objcopy to generate binary files from .elf (not from .hex)

and did anyone write that bin files were created from hex files ?
Bin files are created from the elf file, and the gap fill setting is used for s19, hex, and bin files, as I wrote earlier.
And if you read the help text for the setting you are changing then that should be clear:
https://github.com/zephyrproject-rtos/zephyr/blob/edb71f0ba176edb96a1ffd212b2c0a5de09392bc/Kconfig.zephyr#L696-L697
Although the help text could be improved, because objcopy (which is used for gnu and llvm toolchains) will actually always gap fill, but objcopy defaults to 0x00 if no gap fill argument is given (and as explained earlier, 0x00 is not desirable).

As this configuration parameter has no influence on .bin, the .bin file is not touched.

Wrong.
https://github.com/zephyrproject-rtos/zephyr/blob/edb71f0ba176edb96a1ffd212b2c0a5de09392bc/CMakeLists.txt#L1583-L1585
https://github.com/zephyrproject-rtos/zephyr/blob/edb71f0ba176edb96a1ffd212b2c0a5de09392bc/CMakeLists.txt#L1666-L1670
Please take the needed time to look how a given setting is used before changing its default behavior.

Zephyr is using objcopy to generate binary files from .elf (not from .hex)

and did anyone write that bin files were created from hex files ?
Bin files are created from the elf file, and the gap fill setting is used for s19, hex, and bin files, as I wrote earlier.
And if you read the help text for the setting you are changing then that should be clear:
https://github.com/zephyrproject-rtos/zephyr/blob/edb71f0ba176edb96a1ffd212b2c0a5de09392bc/Kconfig.zephyr#L696-L697
Although the help text could be improved, because objcopy (which is used for gnu and llvm toolchains) will actually always gap fill, but objcopy defaults to 0x00 if no gap fill argument is given (and as explained earlier, 0x00 is not desirable).

As this configuration parameter has no influence on .bin, the .bin file is not touched.

Wrong.
https://github.com/zephyrproject-rtos/zephyr/blob/edb71f0ba176edb96a1ffd212b2c0a5de09392bc/CMakeLists.txt#L1583-L1585
https://github.com/zephyrproject-rtos/zephyr/blob/edb71f0ba176edb96a1ffd212b2c0a5de09392bc/CMakeLists.txt#L1666-L1670
Please take the needed time to look how a given setting is used before changing its default behavior.

Now we have.

Elf (no gaps) =>.hex (gaps filled by 0xFF by default)
Elf (no gaps) =>.bin (gaps filled by 0xFF by default, by 0x00 otherwise)

New proposal:
To split CONFIG_BUILD_NO_GAP_FILL to 2 configuration parameters for better output control: CONFIG_BUILD_BIN_NO_GAP_FILL (default N) and CONFIG_BUILD_HEX_NO_GAP_FILL (default Y):

Elf (no gaps) => .hex (no gaps, by default. Same as .elf)
Elf (no gaps) => .bin (gaps filled by 0xFF by default, by 0x00 otherwise)

What do you think?

New proposal:
To split CONFIG_BUILD_NO_GAP_FILL to 2 configuration parameters for better output control: CONFIG_BUILD_BIN_NO_GAP_FILL (default N) and CONFIG_BUILD_HEX_NO_GAP_FILL (default Y):

I understand you proposal, but is this really adding value to users ?
Now users creating both bin and hex files needs to enable or disable gap fill for both.
So far I don't see any real value in splitting the config into two, unless one wanted to keep the option of having a bin file with a gap-fill of 0xFF, but no gap-fill for the hex. But that's not your use-case because your board most likely already disables bin-output, because the bin file in your case would suffer the huge file (regardless of gap-fill) due to the address space in use.
Also you never replied to the original reason for having gap fill in hex files:

as there is no use case in Zephyr that requires gap filling in .hex.

https://github.com/zephyrproject-rtos/zephyr/pull/8822

regarding nRF boards, enabling or disabling gap fill is not impacting flashing times in my local tests, so i'm not having a strong opinion on that specific part, but others might, ref: https://github.com/zephyrproject-rtos/zephyr/pull/8822#pullrequestreview-136488615.
I will let others comment on whether flash time is significantly impacted by no gap fill.
My main concern lies with changing a default value in ways that suddenly impact others in unexpected ways, unless this has been discussed within a broader audience.

Also you never replied to the original reason for having gap fill in hex files:

There is no any reason to fill gaps for .hex files.
I am going to do a new PR

avoid any gaps for .hex files to make it equal to .elf.
no change for the BUILD_NO_GAP_FILL default value.
BUILD_NO_GAP_FILL will control only .bin files.

Also you never replied to the original reason for having gap fill in hex files:

There is no any reason to fill gaps for .hex files.

there should not be.
And re-checking #8822, then it actually could be that they are flashing the bin-files, and not the hex files.
Flashing bin-files would more logically explain why flash writing times improves (writing 0x00 vs. no writing on 0xFF).
As bin files are always gap-filled, then it's not a matter on gap fill for those, more the pattern to use.
Thus introducing a gap-fill pattern with default value of 0xFF.
Then a BUILD_HEX_GAP_FILL can be introduced instead of BUILD_NO_GAP_FILL.
Old setting should be deprecated and kept for two releases.

Closed this PR.
An improvement to be done in a different form.

authors: butok tejlmand


text:
scripts: Don't fail CI if using deprecated DT prop

Add parameter to EDT class init for enabling a warning if a property on a node in DT is deprecated the default is True since this is the current behavior.
Add argument to gen_defines.py to suppres warning if a DT property appearing on a node is deprecated. If this argument is not set, the current behavior (no suppression) will be used.
Set the gen_defines argument in the twister runner.py so that CI doesn't fail when using a deprecated DT property.
The purpose of this is to allow deprecating DT properties and still using them in-tree if they have not yet been removed from a binding.

The purpose of this is to allow deprecating DT properties and still using them in-tree if they have not yet been removed from a binding.

Bit confused with this, if we deprecate something, it should not be used as per https://docs.zephyrproject.org/latest/build/dts/bindings-syntax.html#deprecated

(This warning is upgraded to an error in the Test Runner (Twister) for upstream pull requests.)

The purpose of this is to allow deprecating DT properties and still using them in-tree if they have not yet been removed from a binding.

This goes against our policy. If something is deprecated, it should not be used in-tree. This ensures that a migration strategy is in place whenever we deprecate something, be it code, devicetree bindings, properties, Kconfig options, ...

We already have things deprecated in tree and we don't fail CI for it. How is a DT binding any different. The issue is that marking a property as deprecated will cause CI to fail unless you remove all of that thing, when the rule as far as I know is that it should be around for 2 more releases.

The purpose of this is to allow deprecating DT properties and still using them in-tree if they have not yet been removed from a binding.

Bit confused with this, if we deprecate something, it should not be used as per https://docs.zephyrproject.org/latest/build/dts/bindings-syntax.html#deprecated

(This warning is upgraded to an error in the Test Runner (Twister) for upstream pull requests.)

Thanks, I need to update that documentation in this PR too. I don't think using a deprecated PR should fail twister.

Also to be clear, the warnings are still there from DTC all the time and from EDT when building without twister.

The purpose of this is to allow deprecating DT properties and still using them in-tree if they have not yet been removed from a binding.

This goes against our policy. If something is deprecated, it should not be used in-tree. This ensures that a migration strategy is in place whenever we deprecate something, be it code, devicetree bindings, properties, Kconfig options, ...

@henrikbrixandersen, we have a policy to mark something for deprecation to alert the downstream user and then after a period to actually remove the item. What we discovered is that you can't mark a DT prop for deprecation because CI treats the warning generated as an error thus failing CI.
So I'll turn the question around a bit. How would you propose we mark a DT prop for deprecation? Should we just outright delete it and let the downstream just discover the deletion on their own or do we want to provide for a mechanism that is similar to how we deprecate APIs where there is the warning?

@henrikbrixandersen, we have a policy to mark something for deprecation to alert the downstream user and then after a period to actually remove the item. What we discovered is that you can't mark a DT prop for deprecation because CI treats the warning generated as an error thus failing CI.
So I'll turn the question around a bit. How would you propose we mark a DT prop for deprecation? Should we just outright delete it and let the downstream just discover the deletion on their own or do we want to provide for a mechanism that is similar to how we deprecate APIs where there is the warning period before it goes away?

From https://docs.zephyrproject.org/latest/develop/api/api_lifecycle.html#deprecated:

Code using the deprecated API needs to be modified to remove usage of said API

So, deprecation requires removal of all in-tree uses of the deprecated API.

We already have things deprecated in tree and we don't fail CI for it.

Can you please provide examples of this?

Code using the deprecated API needs to be modified to remove usage of said API

So, deprecation requires removal of all in-tree uses of the deprecated API. Devicetree properties are APIs in this context.

Okay. Fair enough. We discussed this more in today's standup. This is related to a PR @mmahadevan108 has. He did not remove the references to the property so this is our disconnect.

The purpose of this is to allow deprecating DT properties and still using them in-tree if they have not yet been removed from a binding.

This goes against our policy. If something is deprecated, it should not be used in-tree. This ensures that a migration strategy is in place whenever we deprecate something, be it code, devicetree bindings, properties, Kconfig options, ...

We already have things deprecated in tree and we don't fail CI for it. How is a DT binding any different. The issue is that marking a property as deprecated will cause CI to fail unless you remove all of that thing from tree, when the rule as far as I know is that it should be around for 2 more releases.

This is not true, use of deprecated e.g. macros in code will emit warnings and a warning is an instant build failure on CI

The purpose of this is to allow deprecating DT properties and still using them in-tree if they have not yet been removed from a binding.

This goes against our policy. If something is deprecated, it should not be used in-tree. This ensures that a migration strategy is in place whenever we deprecate something, be it code, devicetree bindings, properties, Kconfig options, ...

We already have things deprecated in tree and we don't fail CI for it. How is a DT binding any different. The issue is that marking a property as deprecated will cause CI to fail unless you remove all of that thing from tree, when the rule as far as I know is that it should be around for 2 more releases.

This is not true, use of deprecated e.g. macros in code will emit warnings and a warning is an instant build failure on CI

Deprecated Kconfigs fail CI?

Deprecated Kconfigs fail CI?

As requested earlier - do you have an example of in-tree usage of deprecated APIs/features being used, but not triggering a failure in CI? If yes, that is a bug and needs to be fixed.

authors: decsny dleach02 henrikbrixandersen nordicjm


text:
Add support  STM32F769 SoC and the STM32F769I-DISCO board

This patch series adds basic supports for the STM32F769 SoC on the STM32F769I-DISCO board.
I have tested it running hello-world,base blinky and threads.

Codecov Report

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

@@           Coverage Diff           @@
##           master    #8736   +/-   ##
=======================================
  Coverage   52.36%   52.36%
=======================================
  Files         195      195
  Lines       24696    24696
  Branches     5128     5128
=======================================
  Hits        12931    12931
  Misses       9695     9695
  Partials     2070     2070

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 b4dae00...7312f30. Read the comment docs.

authors: codecov-io jinyongiot


text:
tests: FIFO: Add description and RTM links

Add doxygen groups, description and RTM links for
FIFO test cases
Signed-off-by: Ajay Kishore ajay.kishore@intel.com

Codecov Report

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

@@           Coverage Diff           @@
##           master    #9410   +/-   ##
=======================================
  Coverage   52.51%   52.51%
=======================================
  Files         202      202
  Lines       25396    25396
  Branches     5328     5328
=======================================
  Hits        13337    13337
  Misses       9960     9960
  Partials     2099     2099

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 61ec512...581ab59. Read the comment docs.

authors: ajaykish codecov-io


text:
Adding support for the BME680 environmental sensor

Hi,
We would like to add support for the BME680 environmental sensor. We hope that the driver is fit for merging.

@BoschSensortec thanks for the fixes. However in order to apply those you need to rebase interactively the existing commits, instead of adding a new commit on top.
You can find more information here:
http://docs.zephyrproject.org/contribute/contribute_guidelines.html#contribution-workflow

Hi @carlescufi & @SebastianBoe,
Your requested changes have been added.

Hi @carlescufi,
Do the existing commits need to be rebased?

@BoschSensortec yes, so commit 585f06b8d7995db0ae83988f8080dd168a5dddbd needs to go away and its contents need to go to the relevant existing commits.

Hi @carlescufi,
Review changes now done as requested.

@BoschSensortec I believe, you would need to sign-off your commits, to get the CI test passing.

@BoschSensortec I believe, you would need to sign-off your commits, to get the CI test passing.

Yep, indeed. Just rebase and use git commit --amend -s for each commit.

Hi @ioannisg & @carlescufi,
Added the sign-off messages as requested. Does the DCO have to be added to the sign-off messages?

@BoschSensortec no, this is fine now, thanks. Hopefully we allow non-human names for the sign-off :) Typically this is a "First Last first.last@company.com"

@BoschSensortec there are still some issues with your commit messages:
https://app.shippable.com/github/zephyrproject-rtos/zephyr/runs/21727/5/tests
The long lines and trailing whitespace should be simple to fix.
This one:
author email (Bosch Sensortec <github@bosch-sensortec.com>) needs to match one of the signed-off-by entries.
You need to amend the commit author by using git commit --amend --author="Name <email>"

Hi @carlescufi & @himanshujha199640,
Your comments have been addressed.

@BoschSensortec thanks! I'm happy with this as-is. I think there's a build failure but it seems unrelated to your PR. Maybe @MaureenHelm can comment on that one.

On Wed, Sep 05, 2018 at 11:04:33PM -0700, Bosch Sensortec wrote:

BoschSensortec commented on this pull request.

+#define BME680_REG_COEFF3               0x00
+#define BME680_REG_FIELD0               0x1d
+#define BME680_REG_IDAC_HEAT0           0x50
+#define BME680_REG_RES_HEAT0            0x5A
+#define BME680_REG_GAS_WAIT0            0x64
+#define BME680_REG_SHD_HEATR_DUR        0x6E
+#define BME680_REG_CTRL_GAS_0           0x70
+#define BME680_REG_CTRL_GAS_1           0x71
+#define BME680_REG_CTRL_HUM             0x72
+#define BME680_REG_CTRL_MEAS            0x74
+#define BME680_REG_CONFIG               0x75
+#define BME680_REG_MEM_PAGE             0xf3
+#define BME680_REG_UNIQUE_ID            0x83
+#define BME680_REG_COEFF1               0x8a
+#define BME680_REG_CHIP_ID              0xd0
In order to have leaner code, like in the BME680 API, addresses above 0x7f are on a different page when operation over the SPI interface. Hence, instead of checking in each API for the interface selected or even having separate drivers for SPI and I2C, denoting the pages in this manner allows for a unified driver. This taken care of in the bme680_get_regs and bme680_set_regs APIs which allows the rest of the code to only handle the I2C addresses.

Yes, the SPI interface indeed difficult to implement consisting of
differnet memory page(Page 0 & Page 1).
I would be happy to see the SPI interface in future.
And I well aware of BSEC integration with BME680 API so that may break
and would require a lot of rework.
My comments are just to put the code in nice category.
--
Himanshu Jha
Undergraduate Student
Department of Electronics & Communication
Guru Tegh Bahadur Institute of Technology

Hi @galak,
We do not have the means and know-how to add and test the device tree at this point in time.

On Mon, Sep 10, 2018 at 11:17:06PM -0700, Bosch Sensortec wrote:

BoschSensortec commented on this pull request.

val->val1 = data->calc_gas_resistance;

val->val2 = 0;

break;

default:

return -EINVAL;

}

return 0;
+}

+static int bme680_read_compensation(struct bme680_data *data)
+{

u8_t buff[BME680_LEN_COEFF_ALL];
int err = 0;

err = bme680_reg_read(data, BME680_REG_COEFF1, buff, BME680_LEN_COEFF1);

The sensor does support register auto-increment, but the registers are at different positions in the register map. Also looking forward, when SPI support would be added, these registers would be in different pages.

Page 0(0x00 to 0x7F) is only required for doing:

Soft reset.
checking ID.

Page 1(0x7F to 0xFF) has other registers:
And the compensation parameters start from:
https://github.com/torvalds/linux/blob/master/drivers/iio/chemical/bme680.h#L64
#define BME680_T2_LSB_REG       0x8A
..
..
#define BME680_GH3_REG          0xEE
So, I believe pages have nothing to do with compensation data.
Correct me if I'm wrong somewhere!
@MaureenHelm These compensation parameters are programmed into
the devices' NVM during production and can't be altered by the user.
So, it is often called "constant" compensation parameters. Now, these
compensation parameters are used into those "weird" looking
compensation functions/algorithm to get the processed output data.
So, IMHO these parameters should be read serially with error handling
and stored into the private/config structure using the regular byte
ordering functions sys_le16_to_cpu. And these constants don't change,
therefore its better to read them only "once" during the device probe
and use it for the whole cycle.
--
Himanshu Jha
Undergraduate Student
Department of Electronics & Communication
Guru Tegh Bahadur Institute of Technology

On Tue, Sep 11, 2018 at 05:25:51PM -0700, Maureen Helm wrote:

MaureenHelm commented on this pull request.
sys_le16_to_cpu doesn't make sense in this case since the parameters have been read into an array of u8_t and they're not all the same type (you can't cast to an array of u16_t).

Take a look here:
https://github.com/torvalds/linux/blob/master/drivers/iio/chemical/bme680_core.c#L96

Adds necessary error handling check on each parameter.
Removes usage of BME680_CONCAT_BYTES macro.

Upto you to deicde which implementation is better for
Zephyr.
--
Himanshu Jha
Undergraduate Student
Department of Electronics & Communication
Guru Tegh Bahadur Institute of Technology

@BoschSensortec any idea on this? I just started work on the BME680 driver myself but then I saw this so an estimate on a working PR would be nice!

@BoschSensortec will you be able to address @MaureenHelm's comments?

Hi @carlescufi, the only pending item is the updated datasheet, when it is available via our website the comments from @MaureenHelm will addressed.

Hi @carlescufi, the only pending item is the updated datasheet, when it is available via our website the comments from @MaureenHelm will addressed.

And when would be it available at your website with updated info ?
The other sensors of the Bosch family have much more detailed info in their respective datasheet. They describe about what different configuration of sampling ratios, IIR filter coefficient values, etc should be used for say when using at a weather station.
Now, while testing this device in various configs such higher sampling rate + filter on + ULP produces:
T: 0.000000; P: 0.000000; H: 0.000000; G: 0.000000
And my past experiecnce with this particular sensor says that you need to always check if the sensor heater plate got heated to the desired temperature or not ? If it didn't, then just abort or signal user
-ERETRY or something like that.
Pg 34/50
5.3.5.6 Heater Stability Status
Heater temperature stability for target heater resistance is indicated heat_stab_x status bits.
Just check this bit before fetching the gas reading!
Because it is verly likely that if a user selects
400 degC + 197ms + very low sampling rates + filter off
config then heater will not get heated to the target heater temperature.
And if you provde various facilites for user to select using Kconfig then why not provide them the liberty change the ambient temperature through Kconfig as well which is hardcoded currently as:
s32_t amb_temp = 25;    /* Assume ambient temperature to be 25 deg C */
Ambient temp plays a major role in the gas reading.
As @MaureenHelm pointed use vendor prefixes as followed in linux kernel:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/vendor-prefixes.txt#n60
I'm also curious how are you testing this sensor ? Development board setup ?
How are you planning to use it with BSEC ?
It is likely that I will re-work this driver at few places in future and your answers will surely help me as to what direction should be followed.

Hi @carlescufi, the only pending item is the updated datasheet, when it is available via our website the comments from @MaureenHelm will addressed.

@BoschSensortec we need documentation first. Please add a README.rst in the sample root folder similar to: https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/sensor/fxos8700/README.rst
There's also a bunch of unadressed comments that are unrelated to the datasheet. If you address those and add the README we can merge and then follow-up with a PR once the datasheet is available:
https://github.com/zephyrproject-rtos/zephyr/pull/9798#pullrequestreview-160929483
https://github.com/zephyrproject-rtos/zephyr/pull/9798#discussion_r222117430
https://github.com/zephyrproject-rtos/zephyr/pull/9798#discussion_r222117639
https://github.com/zephyrproject-rtos/zephyr/pull/9798#discussion_r222118774
https://github.com/zephyrproject-rtos/zephyr/pull/9798#discussion_r222120737
https://github.com/zephyrproject-rtos/zephyr/pull/9798#discussion_r222121167

@carlescufi , @galak , @jhn-nordic
Awaiting final reviews on the datasheet prior to publishing, and then this PR will be completed. Tracked via direct mail.

      The driver should have dts support, look at bosch,bme280 for an example.

@galak,
Could please provide a link to a concrete documentation of the DTS concept and it's use? Hacking around with already existing files is tedious and often frustrating for devlopers who are new to Zephyr.
Thank you.

Could please provide a link to a concrete documentation of the DTS concept and it's use? Hacking around with already existing files is tedious and often frustrating for devlopers who are new to Zephyr.
Thank you.

It's on my todo list to write up a doc on how to "develop" a sensor driver from a DTS point of view.  I'll look at what you've got and try and use it as an example for my doc.

Hi @galak ,
Could you review the changes to the dts file?

@MaureenHelm,
The changes requested are now added. Awaiting your feedback. Note that the datasheet request is still ongoing but will definitely be out when ready.

Hi @galak and @MaureenHelm ,
The dts/bindings/sensor directory is missing an owner.

@BoschSensortec regarding the code owners, can you add please a line like:
dts/bindings/sensor/*bme680*

and this should fix the issue.
Thanks!

@BoschSensortec regarding the CODEOWNERS file, can you please add a line in it like:
dts/bindings/sensor/bme680
and this should fix the issue.
Thanks!

Hi @carlescufi,
of course. Thanks.

@BoschSensortec can you please rebase on top of the latest master?

Hi @carlescufi,
Rebase is completed. Can you check it again?

So in sample.yaml we depend on bme680, but do we have any boards that are going to set that?  Just concerned we aren't going to ever build the sample as part of sanitycheck.

So in sample.yaml we depend on bme680, but do we have any boards that are going to set that? Just concerned we aren't going to ever build the sample as part of sanitycheck.

@galak I know we have a board (upcoming nRF91-based one) that will use this. I will see if we can send this upstream, but I am not sure about that. If that wasn't the case, is there a way to force the build for this sensor even if there is no board that actually has it physically?
@joakimtoe care to comment?

So in sample.yaml we depend on bme680, but do we have any boards that are going to set that? Just concerned we aren't going to ever build the sample as part of sanitycheck.

@galak I know we have a board (upcoming nRF91-based one) that will use this. I will see if we can send this upstream, but I am not sure about that. If that wasn't the case, is there a way to force the build for this sensor even if there is no board that actually has it physically?
@joakimtoe care to comment?

Yes! We have a nRF91 board with this sensor on its way, expected later this year. We do not want to upstream this board until its publicly available to avoid confusion.

Hi @MaureenHelm @BoschSensortec
I've noticed that Bosch have now published a new datasheet (Arpil 2019):
https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BME680-DS001.pdf
We need the driver for Zephyr as soon as possible, so it would be great if the release of the new datasheet could push this PR forward.
We've gone throught the comments holding the PR back. To me it seems that not all the "magic values" and compensation operations are documented in the datasheet, but it rather refers to the BME680 driver that Bosch host on GitHub for further details (see for instance bottom, page 19):
https://github.com/BoschSensortec/BME680_driver/blob/63bb5336/bme680.c
The Linux driver that was provided by @himanshujha199640 and accepted by Linux also refers to the Bosch driver for details. Would it be sufficient for the Zephyr driver to do this as well, so that this PR can get some traction? It looks like Bosch will not provide insight into all details, but will stick to referring to their implementation for the compensation algorithms.
cc @carlescufi @joakimtoe

Here are the comments that I've found that are still unaddressed, though could be more:

https://github.com/zephyrproject-rtos/zephyr/pull/9798#discussion_r215633823 regarding 64-bit division (contains a question directed at @carlescufi )
https://github.com/zephyrproject-rtos/zephyr/pull/9798#discussion_r222119628 regarding documentation updates per new datasheet. AFAICT these are not documented in the new datasheet, but it's referred to the Bosch driver for details.
https://github.com/zephyrproject-rtos/zephyr/pull/9798 regarding unused struct member

@MaureenHelm @BoschSensortec I took the liberty of rebasing and fixing the CI issues

@jtguggedal
I looked at the new datasheet and couldn't see anything new/updated section.
I was expecting rectification of spi_mem_page register info in this new revision. Please correct
me if I'm @BoschSensortec that Pg 24/50 says:
After power-on, spi_mem_page is in its reset state and page 0 (0x80 to 0xFF) will be active. Page 1 (0x00 to 0x7F) will be
active on setting spi_mem_page to 1.

But Pg 26/50:
In SPI mode complete memory page is accessed using page 0 & page 1. Register spi_mem_page is used for page selection.
After power-on, spi_mem_page is in its reset state and page 0(0x00 to 0x7F) will be active. Page1 (0x7F to 0xFF) will be
active on setting spi_mem_page.

I believe page 0 is (0x80 - 0xFF) & page 1(0x00 - 7F).
Talking about the complex compensation function: Yeah even Jonathan(IIO subsystem maintainer) was
reluctant to apply my patch.
Read note in the commit message: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1b3bd8592780c87c5eddabbe98666b086bbaee36
And his reply: https://lore.kernel.org/linux-iio/20180728114028.3c1bbe81@archlinux/
OTOH, if you look at other drivers of Bosch family such as bmp280, bme280, etc., they also share
the same complex algorithms. It's just that for bme680 it gives ref to bme680 github API while for others
those algorithms were mentioned in the datasheet itself.
IIRC @BoschSensortec can provide you the maths involved in IAQ calculation(maybe compensation algorithms too) but that can't be shared publicy(Non-Disclosure Agreement) ;-)

@himanshujha199640 Yeah, it seems that there wasn't much new to the new datasheet revision after all. I'll  keep an eye on new revisions, and will send a patch with updated documentation if the datasheet contains more explanations in the future.

authors: BoschSensortec carlescufi ekarlso galak himanshujha199640 ioannisg joakimtoe jtguggedal


text:
Flow typing for sample arrays source is broken

Missing/Incorrect APIs
Flow typing is broken for objects and arrays with stores in sample source
Cannot call sample because property kind is missing in object
https://share.effector.dev/VkA5DP1n

Relevant documentation
https://effector.now.sh/docs/api/effector/sample#objects-and-arrays-with-stores-in-sample-source

With sample we are close to reaching limits of both flow and typescript and further improvements requires advanced research and for flow we didn't found any solution for that case yet
Tests for that case
Usage of type snapshots

authors: cannatrade zerobias

repo: zerobias/effector

license: MIT


text:
Fundamental issue with information difference between user and backend

One fundamental issue to the general approach is that of the difference of information between the user's view of the page and that which the backend uses. This difference of information can cause the backend to see different things from the user, and thus make different decisions about whether that site includes phishing or not.
Some ways are easier to solve: for example, the views of the backend and user differ if their screen resolutions differ (e.g. vertical screens, not full screen windows, mobile screens, higher resolution screens, etc). This could mean a logo or text is visible on one page, but not the other. Given the current approach for logo detection (top 3 with highest logo prob%), an attacker with full knowledge of the system can make a targeted website to avoid this by placing logos with higher confidence in a region that is only visible to the backend, but not the user. Can be fixed by sending over the client resolution, so the backend uses that resolution for making a screenshot. Will require updating e.g. the logo detection, current dataset only has 1920x1080 AFAIK.
Another issue is that the webserver hosting the phishing site may simply serve a different webpage when the backend connects to it versus when a user connects to it. This is trivial to pull off if the backend is a single server with a fixed IP address (determining the address is trivial, just visit the webserver and make the backend run a phishing detection, check the webserver logs for connecting IP). Best fix is probably to make the client send a screenshot, will also solve the issue mentioned above.
The last issue is more fundamental, as it is solely based on the fact that the backend uses a screenshot. For example, a phishing site may first have a page with full PayPal branding (logo, name and all), but no login form. Instead, it has a simple link button saying 'login', at which point a visitor is transferred to a page with a login form. This page does not need to have the same degree of branding, as the users knowledge already contains the connection to PayPal, so they know that they have to fill in their PayPal login details. However, the backend has not seen this previous page, so it will not have seen any branding, and simply think this is a generic login page. Due to the established connection in the visitors head with PayPal, the login page can even show other generic branding like 'money account login' without raising too much suspicion from an unaware visitor (for many the lack of branding would alert them, I hope). This new generic branding can be made to give back the phishing site on reverse image search, so the extension will detect this as not phishing.

another part of this issue is that some websites (e.g. facebook) have a cookie popup on their login page, blocking the view of the relevant part of the page in our screenshot. having this screenshot made by the extension will prevent this.

repo: zerohour-phishing-detection/zpd-server


text:
How to change the timeout param to deal with error context deadline exceeded

For some business methods that take a long time, rpc processing takes longer than the default 2s and returns a context deadline exceeded error. When I tried to extend the timeout period by modifying the Timeout parameter, I found that it did not take effect.
For example, I use time.sleep(5) in rpc to simulate a long time-consuming business method. I want to set the Timeout parameter  to 10s in the yaml config. There will not discuss whether the business time-consuming of 10s is reasonable.
Test 1
Only modify the Timeout in the api or rpc , the default 2s timeout will be executed, and then the error context deadline exceeded will be return.
Test 2
Set the Timeout parameter in api and rpc at the same time, you will found that after the 3s timeout, and error context deadline exceeded.  I found that the default value set in zrpc/internal/client.go in the source code is dialTimeout = time.Second * 3 https://github.com/zeromicro/go-zero/blob/9d528dddd620c6d5a32cb8eed38edd710093ece4/zrpc/internal/client.go#L18
Test 3
Set the Timeout parameter in api and rpc at the same time, and then set  rest.WithTimeout(time.Second*10)  in handler/Routes.go in api , you will found that it returns success.
But the file handler/Routes.go will be overwritten every time when the api template is regenerated, because this file is // Code generated by goctl. DO NOT EDIT.
So, what is the correct configuration method of Timeout?

go-zero version [v1.2.4]
goctl version [v1.2.4]

I don't really get the problem.
Timeout is in config file, it will not be overwritten.
And Timeout does work to control the timeout, so what's the problem?

Okay, I know. I will try again.

I seem to figure it out.

I seem to figure it out.

I have the same problem. So, what is the correct configuration method of Timeout? Thanks.

I seem to figure it out.

I have the same problem. So, what is the correct configuration method of Timeout? Thanks.

Don't forget to change both client and server sides.

I seem to figure it out.

I have the same problem. So, what is the correct configuration method of Timeout? Thanks.

Don't forget to change both client and server sides.

So, both rest.RestConf.Timeout、zrpc.RpcClientConf.Timeout and zrpc.RpcServerConf.Timeout should be changed, right?

authors: kevwan leafney stepbystep2

repo: zeromicro/go-zero


text:
Cannot return from function that uses zmq in python 3 django

I use python 3.6.6 anaconda 64 bit windows, zmq 4.2.5 I have very strange behavior: function can't return.
Server:
import zmq
import json

def main():
    context = zmq.Context()
    socket = context.socket(zmq.REP)
    #socket.setsockopt(zmq.RCVTIMEO, 1000)
    socket.setsockopt(zmq.SNDTIMEO, 1000)
    socket.bind(my_address)

    def send_response(**kwargs):
        try:
            #... Some kwargs standard preprocessing
            socket.send_string(json.dumps(kwargs))
        except zmq.ZMQBaseError:
            return False
        return True

    while True:
        try:
            msg = socket.recv().decode("utf-8")
        except zmq.ZMQBaseError:
            continue
        #... Processing
        if not send_response(error='Everything is wrong'):
            continue
        #... Processing

Client:
import zmq
import json

def do_request(**kwargs):
    context = zmq.Context()
    socket = context.socket(zmq.REQ)
    socket.setsockopt(zmq.RCVTIMEO, 5000)
    socket.setsockopt(zmq.SNDTIMEO, 1000)
    socket.connect(my_address)

    #... kwargs pre-rocessing
    try:
        socket.send_string(json.dumps(kwargs))
        response = json.loads(socket.recv().decode("utf-8"))
        #... Processing
        return response
    except zmq.ZMQBaseError as e:
        print(e)
        print("PING1!!!")
        return dict(error='Service temporarily unavailable', r_status=503)

def called_from_view():
    response = do_request(command='ping')
    print("PING2!!!")

It was working. I don't know what has changed. But now it is broken. When the server is shut down, client's do_request doesn't return the 'Service temporarily unavailable'. The response = json.loads(socket.recv().decode("utf-8")) throws an exception. In except section the python prints the PING1, but it doesn't print PING2 in called_from_view after that. Even with the empty return. I can't figure out why.
I create new socket in do_request because the client's called_from_view is called from django's view. I had other problems before with the global socket.

Sorry, the send_response must be defined after the socket definition. I've edited the example.
I've answered this question on Stack Overflow https://stackoverflow.com/questions/52433002/cannot-return-from-function-that-uses-zmq-in-python-3-django and was referenced with https://stackoverflow.com/questions/16531407/python-hangs-up-on-returning-from-a-function/16582128#16582128 with a solution:
socket = context.socket(zmq.REQ)
socket.setsockopt(zmq.LINGER, True) # or False, my testing says it works both ways.

LINGER is an integer, so False is 0 and True is 1 (or 1 millisecond), so the behavior is going to be effectively the same in both cases.

authors: minrk romikforest

repo: zeromq/pyzmq


text:
[Bug] Exception when terminating app in iOS

Since updating to Flutter 3.0, I've noticed that any forced quit in iOS (swipe up, exit app) triggers an exception. I've validated that this is isolated to the motion_sensors plugin by building a bare-bones app using the example code on pub.dev and doing the following:

Launch app in debug mode on connected device
Validate that accelerometer and other data streams are functioning and tracing data as expected on screen
Swipe up, exit
Crash

For what it is worth, I've also noticed this same behavior when using the sensors_plus plugin. However, the flutter_sensors plugin does not exhibit this 'crash on exit' behavior'.  I prefer motion_sensors to these plugins, however, for the easy access to the Absolute Orientation stream.
Below are my flutter doctor output and a crash log from TestFlight
flutter doctor -v
[✓] Flutter (Channel stable, 3.0.5, on macOS 12.4 21F79 darwin-x64, locale
    en-US)
    • Flutter version 3.0.5 at /Users/sean/Documents/dev/sdk/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision f1875d570e (6 days ago), 2022-07-13 11:24:16 -0700
    • Engine revision e85ea0e79c
    • Dart version 2.17.6
    • DevTools version 2.12.2

[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.0)
    • Android SDK at /Users/sean/Library/Android/sdk
    • Platform android-32, build-tools 33.0.0
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build
      11.0.12+0-b1504.28-7817840)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 13.4.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • CocoaPods version 1.11.3

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2021.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build
      11.0.12+0-b1504.28-7817840)

[✓] VS Code (version 1.69.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.44.0

[✓] Connected device (2 available)
    • macOS (desktop) • macos  • darwin-x64     • macOS 12.4 21F79 darwin-x64
    • Chrome (web)    • chrome • web-javascript • Google Chrome 103.0.5060.114

[✓] HTTP Host Availability
    • All required HTTP hosts are available

• No issues found!

testflight crashlog last exception backtrace
Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note:  EXC_CORPSE_NOTIFY
Triggered by Thread:  19

Last Exception Backtrace:
0   CoreFoundation                	0x1b1589288 __exceptionPreprocess + 220 (NSException.m:200)
1   libobjc.A.dylib               	0x1ca283744 objc_exception_throw + 60 (objc-exception.mm:565)
2   Foundation                    	0x1b2e16360 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 204 (NSException.m:242)
3   Flutter                       	0x10119a56c 0x101188000 + 75116
4   motion_sensors                	0x10103daf8 thunk for @escaping @callee_unowned @convention(block) (@unowned Swift.AnyObject?) -> () + 176 (<compiler-generated>:0)
5   motion_sensors                	0x10103fe24 $s14motion_sensors21AttitudeStreamHandlerC8onListen13withArguments9eventSinkSo12FlutterErrorCSgypSg_yAJctFySo14CMDeviceMotionCSg_s0M0_pSgtcfU_ + 448 (SwiftMotionSensorsPlugin.swift:0)
6   motion_sensors                	0x10103fe24 partial apply for closure #1 in AttitudeStreamHandler.onListen(withArguments:eventSink:) + 496 (<compiler-generated>:0)
7   motion_sensors                	0x10103e1b4 thunk for @escaping @callee_guaranteed (@guaranteed CMGyroData?, @guaranteed Error?) -> () + 80 (<compiler-generated>:0)
8   Foundation                    	0x1b2d35c1c __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 24 (NSOperation.m:1545)
9   Foundation                    	0x1b2d47f94 -[NSBlockOperation main] + 104 (NSOperation.m:1564)
10  Foundation                    	0x1b2d20214 __NSOPERATION_IS_INVOKING_MAIN__ + 24 (NSOperation.m:2189)
11  Foundation                    	0x1b2d315dc -[NSOperation start] + 788 (NSOperation.m:2206)
12  Foundation                    	0x1b2d34c68 __NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION__ + 24 (NSOperation.m:2220)
13  Foundation                    	0x1b2d42e10 __NSOQSchedule_f + 184 (NSOperation.m:2231)
14  libdispatch.dylib             	0x1b11ff830 _dispatch_block_async_invoke2 + 148 (queue.c:560)
15  libdispatch.dylib             	0x1b11f0a30 _dispatch_client_callout + 20 (object.m:560)
16  libdispatch.dylib             	0x1b11f3eec _dispatch_continuation_pop + 500 (inline_internal.h:2622)
17  libdispatch.dylib             	0x1b11f35f0 _dispatch_async_redirect_invoke + 736 (queue.c:835)
18  libdispatch.dylib             	0x1b1202164 _dispatch_root_queue_drain + 396 (inline_internal.h:0)
19  libdispatch.dylib             	0x1b120296c _dispatch_worker_thread2 + 164 (queue.c:6935)
20  libsystem_pthread.dylib       	0x222e48080 _pthread_wqthread + 228 (pthread.c:2612)
21  libsystem_pthread.dylib       	0x222e47e5c start_wqthread + 8 (:-1)

@zesage -- so i THINK this may be relevant to this mysterious issue. Our app uses a forced-right-rotation some time after initial start up (it starts in portrait, later it switches permanently to rotated right / landscape) ...
when we quit the app on iOS we noticed it generated a crash / report.
like the other users here. and had the 'feeling' that sometimes it didnt.
well, i just now figured out the conditions under which it crashes and when it doesnt. we are rotated right in our app. user then force quits and :
100% of the time it crashes if they force quit landscape style (swiping right as it were even though they are swing up in their minds)
and crashes 0% of the time if they force quit portrait style (swiping up = swiping up).
If that bit if new info helps in any way, that's all i can say i noticed. that's the only reproducible finding here.
also this is ONLY on iOS.
Cheers. and Thanks for this Lib!


text:
android版编译打包 正常，运行  就崩

E/cv::error(): OpenCV(3.4.2) Error: Unspecified error (FAILED: fs.is_open(). Can't open "/storage/emulated/0/pr/HorizonalFinemapping.prototxt") in bool cv::dnn::ReadProtoFromTextFile(const char*, google::protobuf::Message*), file /build/3_4_pack-android/opencv/modules/dnn/src/caffe/caffe_io.cpp, line 1121

加上旧版assets里面的文件

加上旧版assets里面的文件
--这个是哪里呀？

@yuxingfafu Prj-linux /model目录下面

谢谢，老铁，请教下你搞过港澳台的车牌么？怎么训练接入知道的不？

authors: huangjinhao lsy17096535 yuxingfafu

repo: zeusees/HyperLPR


text:
fix filtering of joined/referenced fields, add custom types support

typeCastField() is not used correctly for reference fields and joined entity fields
because of wrong $metadata object usage

filters doesn't support custom data types
added $fieldType passing to setParameter();

Coverage decreased (-1.8%) to 83.57% when pulling 6e6c375fcc89dd8b8da6ae2912417bbfea75fb93 on gegok:tsp-fix-filters into e1a286851b0a7122e94c06b2dba74febeb795122 on zfcampus:master.

@gegok We need tests to cover these changes and demonstrate the described issues.

Closing, due to lack of tests.

authors: coveralls gegok webimpress weierophinney

repo: zfcampus/zf-doctrine-querybuilder


text:
Wrong HTTP status code for authentication challenge

It seems the DefaultAuthorizationPostListener is changing the status to 403 even when an authentication challenge response with a 401 status code is set.
The following piece of code probably needs to be added:
    if ($response instanceof HttpResponse &&
            $response->getStatusCode() == 401) {
        return;
    }

Having the same problem when using zf-mvc-auth in Apigility:
There instead of the DefaultAuthorizationPostListener the problem is within the ZF\Apigility\MvcAuth\UnauthorizedListener which doesn't check if a user is authenticated or not e.g. by doing something simple like:
        $status = 403;
        if (!$mvcAuthEvent->hasAuthenticationResult()) {
// alternatively:
//     if ($mvcAuthEvent->getIdentity() instanceof \ZF\MvcAuth\Identity\GuestIdentity) {
            $status = 401;
        }
        $response = new ApiProblemResponse(new ApiProblem($status, 'Forbidden'));

The DefaultAuthorizationPostListener wasn't even called in my debugging cases as the UnauthorizedListener is called before and already returns a response which cancels the EVENT_AUTHORIZATION_POST. But in cases without Apigility the DefaultAuthorizationPostListener could probably do something similar.
I guess I'll add my own listener with higher priority or replace the UnauthorizedListener as there are multiple other issues and closed pull requests with the same unresolved problem. (#97, #106, #107, #127)

This repository has been closed and moved to laminas-api-tools/api-tools-mvc-auth; a new issue has been opened at https://github.com/laminas-api-tools/api-tools-mvc-auth/issues/8.

authors: JeSuisAlrick j-schumann weierophinney

repo: zfcampus/zf-mvc-auth


text:
插件生成器和插件列表的相关破坏性更新

[X] 插件列表命令
[x] 插件生成器重构：创建目录要变成但级目录
[ ] 插件生成器重构：检测并兼容旧版插件（zmplugin.json）
[ ] 插件生成器重构：帮助生成插件的 Git 仓库、GitHub Action、.gitignore 等文件

把安装命令的具体流程分到不同的类会不会比较好。
比如弄 GitCloneStrategy, VCSRemoteStrategy, ComposerPackageStrategy 之类，然后用责任链或者什么串起来？以后加新方式或者维护也方便写吧，比起全部写在命令里。

把安装命令的具体流程分到不同的类会不会比较好。 比如弄 GitCloneStrategy, VCSRemoteStrategy, ComposerPackageStrategy 之类，然后用责任链或者什么串起来？以后加新方式或者维护也方便写吧，比起全部写在命令里。

（摊手）这应该就是个分文件的问题，对开发者和用户应该是无感知的更新，后续可以有时间优化（或者你懂的，某人来写）。

TODO List 提到的最后一个 Actions、gitignore 等的更新需要配套的 GH Action 和 gitignore 文件写好，暂时不考虑在此 PR 内。

authors: crazywhalecc sunxyw

repo: zhamao-robot/zhamao-framework


text:
online生成的代码表现形式和online预览的不一致

版本号：
2.4.3
问题描述：
online模式下生成一对多(ERP模式)，新增时是弹出模态框，但是生成代码后，新增是edittable的形式了
截图&代码：
online在线测试

生成代码模式

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

你生成的是，选择ERP模板了吗。肯定没选

你生成的是，选择ERP模板了吗。肯定没选

哈，还真是，没注意，“以为”只要在表单那边选了ERP一对多就行了

你生成的是，选择ERP模板了吗。肯定没选
按你的那个试了，是模态框了，但是分列没了，都变成1列了

authors: wangleigithub zhangdaiscott

repo: zhangdaiscott/jeecg-boot


text:
QueryGenerator 生成查询语句

版本号：
当前版本
问题描述：
当QueryGenerator中public static  QueryWrapper initQueryWrapper(T searchObj,Map<String, String[]> parameterMap)， 在生成sql查询语句的时间。
可以将T中是否有TableFiedl注解对应起来生成sql语句。
例如：T对象。
public  class Test{
@TableField(value = "test_id")
private String  id;
}
生成的语句应该未： test_id like  ?
截图&代码：
友情提示： 未按格式要求发帖，会直接删掉。

没有明白，请补充描述，最好加上截图

authors: comeNie zhangdaiscott


text:
Added/extended --acceptable-status option

For details, see the commit message.
No review needed.
Tested manually on T224.

Coverage decreased (-0.09%) to 32.797% when pulling 4f3a72ab6ee7a681b1190ad8e1764a0655c30fef on andy/acceptable-status into 169ca05a7e42a9a41daa3f77992072f8735686e4 on master.

authors: andy-maier coveralls

repo: zhmcclient/zhmccli