zephyr-master_fork#1
Closed
kartmpk wants to merge 2 commits intozephyrproject-rtos:masterfrom
kartmpk:master
Closed
zephyr-master_fork#1kartmpk wants to merge 2 commits intozephyrproject-rtos:masterfrom kartmpk:master
kartmpk wants to merge 2 commits intozephyrproject-rtos:masterfrom
kartmpk:master
Conversation
added 2 commits
November 1, 2016 17:32
Signed-off-by: Prasanna Karthik <pkarthik@intrinsyc.com>
Signed-off-by: Prasanna Karthik <pkarthik@intrinsyc.com>
zephyr-github
pushed a commit
that referenced
this pull request
Mar 15, 2017
The current implementation of stm32_gpio_set() uses the GPIO output data register to change the state of individual GPIOs. The generated assembler needs at least 3 instructions: load / modify / store. This opens a small race window, for example if a thread and an interrupt both try to change the state of the same GPIO bank. Use the GPIO bit set/reset register to perform the atomic change without locking. This also has the benefit of a more optimised implementation, which can be useful for GPIO-intensive work. Compare the new version: 08000c98 <stm32_gpio_set>: 8000c98: f001 010f and.w r1, r1, #15 8000c9c: 2301 movs r3, #1 8000c9e: b902 cbnz r2, 8000ca2 <stm32_gpio_set+0xa> 8000ca0: 3110 adds r1, #16 8000ca2: 408b lsls r3, r1 8000ca4: 6183 str r3, [r0, #24] 8000ca6: 2000 movs r0, #0 8000ca8: 4770 bx lr and the old one: 08000c98 <stm32_gpio_set>: 8000c98: 2301 movs r3, #1 8000c9a: f001 010f and.w r1, r1, #15 8000c9e: fa03 f101 lsl.w r1, r3, r1 8000ca2: 6943 ldr r3, [r0, #20] 8000ca4: b10a cbz r2, 8000caa <stm32_gpio_set+0x12> 8000ca6: 4319 orrs r1, r3 8000ca8: e001 b.n 8000cae <stm32_gpio_set+0x16> 8000caa: ea23 0101 bic.w r1, r3, r1 8000cae: 6141 str r1, [r0, #20] 8000cb0: 2000 movs r0, #0 8000cb2: 4770 bx lr Change-Id: Ie5800d1c345016028d1b9a099f5d74cac35f592a Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
zephyr-github
pushed a commit
that referenced
this pull request
Mar 17, 2017
The current implementation of stm32_gpio_set() uses the GPIO output data register to change the state of individual GPIOs. The generated assembler needs at least 3 instructions: load / modify / store. This opens a small race window, for example if a thread and an interrupt both try to change the state of the same GPIO bank. Use the GPIO bit set/reset register to perform the atomic change without locking. This also has the benefit of a more optimised implementation, which can be useful for GPIO-intensive work. Compare the new version: 08000c98 <stm32_gpio_set>: 8000c98: f001 010f and.w r1, r1, #15 8000c9c: 2301 movs r3, #1 8000c9e: b902 cbnz r2, 8000ca2 <stm32_gpio_set+0xa> 8000ca0: 3110 adds r1, #16 8000ca2: 408b lsls r3, r1 8000ca4: 6183 str r3, [r0, #24] 8000ca6: 2000 movs r0, #0 8000ca8: 4770 bx lr and the old one: 08000c98 <stm32_gpio_set>: 8000c98: 2301 movs r3, #1 8000c9a: f001 010f and.w r1, r1, #15 8000c9e: fa03 f101 lsl.w r1, r3, r1 8000ca2: 6943 ldr r3, [r0, #20] 8000ca4: b10a cbz r2, 8000caa <stm32_gpio_set+0x12> 8000ca6: 4319 orrs r1, r3 8000ca8: e001 b.n 8000cae <stm32_gpio_set+0x16> 8000caa: ea23 0101 bic.w r1, r3, r1 8000cae: 6141 str r1, [r0, #20] 8000cb0: 2000 movs r0, #0 8000cb2: 4770 bx lr Change-Id: Ie5800d1c345016028d1b9a099f5d74cac35f592a Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
zephyr-github
pushed a commit
that referenced
this pull request
Mar 21, 2017
The current implementation of stm32_gpio_set() uses the GPIO output data register to change the state of individual GPIOs. The generated assembler needs at least 3 instructions: load / modify / store. This opens a small race window, for example if a thread and an interrupt both try to change the state of the same GPIO bank. Use the GPIO bit set/reset register to perform the atomic change without locking. This also has the benefit of a more optimised implementation, which can be useful for GPIO-intensive work. Compare the new version: 08000c98 <stm32_gpio_set>: 8000c98: f001 010f and.w r1, r1, #15 8000c9c: 2301 movs r3, #1 8000c9e: b902 cbnz r2, 8000ca2 <stm32_gpio_set+0xa> 8000ca0: 3110 adds r1, #16 8000ca2: 408b lsls r3, r1 8000ca4: 6183 str r3, [r0, #24] 8000ca6: 2000 movs r0, #0 8000ca8: 4770 bx lr and the old one: 08000c98 <stm32_gpio_set>: 8000c98: 2301 movs r3, #1 8000c9a: f001 010f and.w r1, r1, #15 8000c9e: fa03 f101 lsl.w r1, r3, r1 8000ca2: 6943 ldr r3, [r0, #20] 8000ca4: b10a cbz r2, 8000caa <stm32_gpio_set+0x12> 8000ca6: 4319 orrs r1, r3 8000ca8: e001 b.n 8000cae <stm32_gpio_set+0x16> 8000caa: ea23 0101 bic.w r1, r3, r1 8000cae: 6141 str r1, [r0, #20] 8000cb0: 2000 movs r0, #0 8000cb2: 4770 bx lr Change-Id: Ie5800d1c345016028d1b9a099f5d74cac35f592a Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
zephyr-github
pushed a commit
that referenced
this pull request
Mar 27, 2017
The current implementation of stm32_gpio_set() uses the GPIO output data register to change the state of individual GPIOs. The generated assembler needs at least 3 instructions: load / modify / store. This opens a small race window, for example if a thread and an interrupt both try to change the state of the same GPIO bank. Use the GPIO bit set/reset register to perform the atomic change without locking. This also has the benefit of a more optimised implementation, which can be useful for GPIO-intensive work. Compare the new version: 08000c98 <stm32_gpio_set>: 8000c98: f001 010f and.w r1, r1, #15 8000c9c: 2301 movs r3, #1 8000c9e: b902 cbnz r2, 8000ca2 <stm32_gpio_set+0xa> 8000ca0: 3110 adds r1, #16 8000ca2: 408b lsls r3, r1 8000ca4: 6183 str r3, [r0, #24] 8000ca6: 2000 movs r0, #0 8000ca8: 4770 bx lr and the old one: 08000c98 <stm32_gpio_set>: 8000c98: 2301 movs r3, #1 8000c9a: f001 010f and.w r1, r1, #15 8000c9e: fa03 f101 lsl.w r1, r3, r1 8000ca2: 6943 ldr r3, [r0, #20] 8000ca4: b10a cbz r2, 8000caa <stm32_gpio_set+0x12> 8000ca6: 4319 orrs r1, r3 8000ca8: e001 b.n 8000cae <stm32_gpio_set+0x16> 8000caa: ea23 0101 bic.w r1, r3, r1 8000cae: 6141 str r1, [r0, #20] 8000cb0: 2000 movs r0, #0 8000cb2: 4770 bx lr Change-Id: Ie5800d1c345016028d1b9a099f5d74cac35f592a Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
This was referenced Sep 23, 2017
Closed
1 task
1 task
josuah
referenced
this pull request
in josuah/zephyr
Oct 13, 2025
1 task
ndrs-pst
added a commit
to DDC-NDRS/zephyr_rtos
that referenced
this pull request
Nov 14, 2025
# Conflicts: # drivers/ethernet/eth_stm32_hal_priv.h # drivers/ethernet/eth_stm32_hal_v2.c # drivers/ethernet/phy/CMakeLists.txt # drivers/sdhc/sdhc_spi.c # include/zephyr/device.h # include/zephyr/net/wifi_mgmt.h # include/zephyr/rtio/rtio.h # include/zephyr/sys/util.h # subsys/modem/modem_cmux.c # subsys/shell/backends/shell_uart.c # subsys/usb/device_next/usbd_ch9.c
nashif
pushed a commit
that referenced
this pull request
Nov 20, 2025
nashif
pushed a commit
that referenced
this pull request
Nov 20, 2025
Add SCK and WS signals to a shared signal set between Flexcomm #1 and Flexcomm #3 for the mimxrt685_evk/mimxrt685s/cm33. This enables the board to both transmit and receive audio, as the BCK and WS signals produced by the WM8904 codec are only connected to the Flexcomm #1 peripheral. Signed-off-by: Vit Stanicek <vit.stanicek@nxp.com>
Merged
ndrs-pst
added a commit
to DDC-NDRS/zephyr_rtos
that referenced
this pull request
Nov 24, 2025
# Conflicts: # drivers/i2c/i2c_ifx_cat1_pdl.c # kernel/device.c # west.yml
1 task
namjoshiniks
added a commit
to namjoshiniks/zephyr
that referenced
this pull request
Dec 30, 2025
Per RFC9112 (REF zephyrproject-rtos#1), HTTP/1.1 server is expected to be backward compatible with HTTP1.0 request. Mainly HTTP/1.0 does not support 1) Transfer Encoding : chunked 2) KeepAlives So, this change will identify the HTTP protocol version in the request and respond accordingly. REF# 1) https://httpwg.org/specs/rfc9112.html Tested: 1) Verified that HTTP/1.1 requests are served as usual i.e. with chunked transfer encoding and the connection is a Keep Alive connection Query exits after 10s, indicating that the client connection to the HTTP server is a Keep Alive. ``` time printf "GET /telem HTTP/1.1\r\nHost: 192.0.3.11\r\n\r\n" | nc 192.0.3.11 80 real 0m10.185s <- Indicates connection was kept active for 10s user 0m0.023s sys 0m0.023s ``` `Transfer Encoding : chunked` header and chunked encoding metadata (chunk size hex bytes, crlf, termination byte 0) are present in the response. ``` HTTP/1.1 200 OK Transfer-Encoding: chunked <- Chunked encoding header Content-Type: text/html 3e8 <- Chunk size hex bytes : /health/secondsdevice_ae:9a:22:48:0f:70"seconds0 + /health/locatedevice_ae:9a:22:48:0f:70"0 / /network/mac-addressdevice_ae:9a:22:48:0f:70" . . . 3e8 <- Chunk size hex byte _PLUS_rawdevice_ae:9a:22:48:0f:70"0 6 /dev/ISHARE_CBU_MINUS_rawdevice_ae:9a:22:48:0f:70"0 . . . /dev/part_iddevice_ae:9a:22:48:0f:70"0��������� , /dev/part_typedevice_ae:9a:22:48:0f:70"0 7 /dev/part_telemetry_disabledevice_ae:9a:22:48:0f:70"0 0 <- Termination Byte 0 ``` 2) Verfied that HTTP/1.0 requests are served with response without chunked transfer encoding and the connection is closed immediately. Query exits immediately indicating the connection is closed immediately ``` time printf "GET /telem HTTP/1.0\r\nHost: 192.0.3.11\r\n\r\n" | nc 192.0.3.11 80 real 0m0.186s <- Indicates connection was terminated immediately. user 0m0.018s sys 0m0.030s ``` `Transfer Encoding : chunked` header and chunked encoding metadata (chunk size hex bytes, crlf) not present in the response ``` HTTP/1.1 200 OK Content-Type: text/html : /health/uptimedevice_ae:9a:22:48:0f:70"seconds0 + /health/locatedevice_ae:9a:22:48:0f:70"0 / /network/mac-addressdevice_ae:9a:22:48:0f:70" . . . 3 /dev/part_iddevice_ae:9a:22:48:0f:70"0��������� , /dev/part_typedevice_ae:9a:22:48:0f:70"0 7 /dev/can_telemetry_disabledevice_ae:9a:22:48:0f:70"0 ``` Signed-off-by: Nikhil Namjoshi <nikhilnamjoshi@google.com>
namjoshiniks
added a commit
to namjoshiniks/zephyr
that referenced
this pull request
Dec 30, 2025
Per RFC9112 (REF zephyrproject-rtos#1), HTTP/1.1 server is expected to be backward compatible with HTTP1.0 request. Mainly HTTP/1.0 does not support 1) Transfer Encoding : chunked 2) KeepAlives So, this change will identify the HTTP protocol version in the request and respond accordingly. REF# 1) https://httpwg.org/specs/rfc9112.html Tested: 1) Verified that HTTP/1.1 requests are served as usual i.e. with chunked transfer encoding and the connection is a Keep Alive connection Query exits after 10s, indicating that the client connection to the HTTP server is a Keep Alive. ``` time printf "GET /telem HTTP/1.1\r\nHost: 192.0.3.11\r\n\r\n" | nc 192.0.3.11 80 real 0m10.185s <- Indicates connection was kept active for 10s user 0m0.023s sys 0m0.023s ``` `Transfer Encoding : chunked` header and chunked encoding metadata (chunk size hex bytes, crlf, termination byte 0) are present in the response. ``` HTTP/1.1 200 OK Transfer-Encoding: chunked <- Chunked encoding header Content-Type: text/html 3e8 <- Chunk size hex bytes : /health/secondsdevice_ae:9a:22:48:0f:70"seconds0 + /health/locatedevice_ae:9a:22:48:0f:70"0 / /network/mac-addressdevice_ae:9a:22:48:0f:70" . . . 3e8 <- Chunk size hex byte _PLUS_rawdevice_ae:9a:22:48:0f:70"0 6 /dev/ISHARE_CBU_MINUS_rawdevice_ae:9a:22:48:0f:70"0 . . . /dev/part_iddevice_ae:9a:22:48:0f:70"0��������� , /dev/part_typedevice_ae:9a:22:48:0f:70"0 7 /dev/part_telemetry_disabledevice_ae:9a:22:48:0f:70"0 0 <- Termination Byte 0 ``` 2) Verfied that HTTP/1.0 requests are served with response without chunked transfer encoding and the connection is closed immediately. Query exits immediately indicating the connection is closed immediately ``` time printf "GET /telem HTTP/1.0\r\nHost: 192.0.3.11\r\n\r\n" | nc 192.0.3.11 80 real 0m0.186s <- Indicates connection was terminated immediately. user 0m0.018s sys 0m0.030s ``` `Transfer Encoding : chunked` header and chunked encoding metadata (chunk size hex bytes, crlf) not present in the response ``` HTTP/1.1 200 OK Content-Type: text/html : /health/uptimedevice_ae:9a:22:48:0f:70"seconds0 + /health/locatedevice_ae:9a:22:48:0f:70"0 / /network/mac-addressdevice_ae:9a:22:48:0f:70" . . . 3 /dev/part_iddevice_ae:9a:22:48:0f:70"0��������� , /dev/part_typedevice_ae:9a:22:48:0f:70"0 7 /dev/can_telemetry_disabledevice_ae:9a:22:48:0f:70"0 ``` Signed-off-by: Nikhil Namjoshi <nikhilnamjoshi@google.com>
namjoshiniks
added a commit
to namjoshiniks/zephyr
that referenced
this pull request
Dec 30, 2025
Per RFC9112 (REF zephyrproject-rtos#1), HTTP/1.1 server is expected to be backward compatible with HTTP1.0 request. Mainly HTTP/1.0 does not support 1) Transfer Encoding : chunked 2) KeepAlives So, this change will identify the HTTP protocol version in the request and respond accordingly. REF# 1) https://httpwg.org/specs/rfc9112.html Tested: 1) Verified that HTTP/1.1 requests are served as usual i.e. with chunked transfer encoding and the connection is a Keep Alive connection Query exits after 10s, indicating that the client connection to the HTTP server is a Keep Alive. ``` time printf "GET /telem HTTP/1.1\r\nHost: 192.0.3.11\r\n\r\n" | nc 192.0.3.11 80 real 0m10.185s <- Indicates connection was kept active for 10s user 0m0.023s sys 0m0.023s ``` `Transfer Encoding : chunked` header and chunked encoding metadata (chunk size hex bytes, crlf, termination byte 0) are present in the response. ``` HTTP/1.1 200 OK Transfer-Encoding: chunked <- Chunked encoding header Content-Type: text/html 3e8 <- Chunk size hex bytes : /health/secondsdevice_ae:9a:22:48:0f:70"seconds0 + /health/locatedevice_ae:9a:22:48:0f:70"0 / /network/mac-addressdevice_ae:9a:22:48:0f:70" . . . 3e8 <- Chunk size hex byte _PLUS_rawdevice_ae:9a:22:48:0f:70"0 6 /dev/ISHARE_CBU_MINUS_rawdevice_ae:9a:22:48:0f:70"0 . . . /dev/part_iddevice_ae:9a:22:48:0f:70"0��������� , /dev/part_typedevice_ae:9a:22:48:0f:70"0 7 /dev/part_telemetry_disabledevice_ae:9a:22:48:0f:70"0 0 <- Termination Byte 0 ``` 2) Verfied that HTTP/1.0 requests are served with response without chunked transfer encoding and the connection is closed immediately. Query exits immediately indicating the connection is closed immediately ``` time printf "GET /telem HTTP/1.0\r\nHost: 192.0.3.11\r\n\r\n" | nc 192.0.3.11 80 real 0m0.186s <- Indicates connection was terminated immediately. user 0m0.018s sys 0m0.030s ``` `Transfer Encoding : chunked` header and chunked encoding metadata (chunk size hex bytes, crlf) not present in the response ``` HTTP/1.1 200 OK Content-Type: text/html : /health/uptimedevice_ae:9a:22:48:0f:70"seconds0 + /health/locatedevice_ae:9a:22:48:0f:70"0 / /network/mac-addressdevice_ae:9a:22:48:0f:70" . . . 3 /dev/part_iddevice_ae:9a:22:48:0f:70"0��������� , /dev/part_typedevice_ae:9a:22:48:0f:70"0 7 /dev/can_telemetry_disabledevice_ae:9a:22:48:0f:70"0 ``` Signed-off-by: Nikhil Namjoshi <nikhilnamjoshi@google.com>
namjoshiniks
added a commit
to namjoshiniks/zephyr
that referenced
this pull request
Dec 31, 2025
Per RFC9112 (REF zephyrproject-rtos#1), HTTP/1.1 server is expected to be backward compatible with HTTP1.0 request. Mainly HTTP/1.0 does not support 1) Transfer Encoding : chunked 2) KeepAlives So, this change will identify the HTTP protocol version in the request and respond accordingly. REF# 1) https://httpwg.org/specs/rfc9112.html Tested: 1) Verified that HTTP/1.1 requests are served as usual i.e. with chunked transfer encoding and the connection is a Keep Alive connection Query exits after 10s, indicating that the client connection to the HTTP server is a Keep Alive. ``` time printf "GET /telem HTTP/1.1\r\nHost: 192.0.3.11\r\n\r\n" | nc 192.0.3.11 80 real 0m10.185s <- Indicates connection was kept active for 10s user 0m0.023s sys 0m0.023s ``` `Transfer Encoding : chunked` header and chunked encoding metadata (chunk size hex bytes, crlf, termination byte 0) are present in the response. ``` HTTP/1.1 200 OK Transfer-Encoding: chunked <- Chunked encoding header Content-Type: text/html 3e8 <- Chunk size hex bytes : /health/secondsdevice_ae:9a:22:48:0f:70"seconds0 + /health/locatedevice_ae:9a:22:48:0f:70"0 / /network/mac-addressdevice_ae:9a:22:48:0f:70" . . . 3e8 <- Chunk size hex byte _PLUS_rawdevice_ae:9a:22:48:0f:70"0 6 /dev/ISHARE_CBU_MINUS_rawdevice_ae:9a:22:48:0f:70"0 . . . /dev/part_iddevice_ae:9a:22:48:0f:70"0��������� , /dev/part_typedevice_ae:9a:22:48:0f:70"0 7 /dev/part_telemetry_disabledevice_ae:9a:22:48:0f:70"0 0 <- Termination Byte 0 ``` 2) Verfied that HTTP/1.0 requests are served with response without chunked transfer encoding and the connection is closed immediately. Query exits immediately indicating the connection is closed immediately ``` time printf "GET /telem HTTP/1.0\r\nHost: 192.0.3.11\r\n\r\n" | nc 192.0.3.11 80 real 0m0.186s <- Indicates connection was terminated immediately. user 0m0.018s sys 0m0.030s ``` `Transfer Encoding : chunked` header and chunked encoding metadata (chunk size hex bytes, crlf) not present in the response ``` HTTP/1.1 200 OK Content-Type: text/html : /health/uptimedevice_ae:9a:22:48:0f:70"seconds0 + /health/locatedevice_ae:9a:22:48:0f:70"0 / /network/mac-addressdevice_ae:9a:22:48:0f:70" . . . 3 /dev/part_iddevice_ae:9a:22:48:0f:70"0��������� , /dev/part_typedevice_ae:9a:22:48:0f:70"0 7 /dev/can_telemetry_disabledevice_ae:9a:22:48:0f:70"0 ``` Signed-off-by: Nikhil Namjoshi <nikhilnamjoshi@google.com>
namjoshiniks
added a commit
to namjoshiniks/zephyr
that referenced
this pull request
Jan 2, 2026
Per RFC9112 (REF zephyrproject-rtos#1), HTTP/1.1 server is expected to be backward compatible with HTTP1.0 request. Mainly HTTP/1.0 does not support 1) Transfer Encoding : chunked 2) KeepAlives So, this change will identify the HTTP protocol version in the request and respond accordingly. REF# 1) https://httpwg.org/specs/rfc9112.html Tested: 1) Verified that HTTP/1.1 requests are served as usual i.e. with chunked transfer encoding and the connection is a Keep Alive connection Query exits after 10s, indicating that the client connection to the HTTP server is a Keep Alive. ``` time printf "GET /telem HTTP/1.1\r\nHost: 192.0.3.11\r\n\r\n" | nc 192.0.3.11 80 real 0m10.185s <- Indicates connection was kept active for 10s user 0m0.023s sys 0m0.023s ``` `Transfer Encoding : chunked` header and chunked encoding metadata (chunk size hex bytes, crlf, termination byte 0) are present in the response. ``` HTTP/1.1 200 OK Transfer-Encoding: chunked <- Chunked encoding header Content-Type: text/html 3e8 <- Chunk size hex bytes : /health/secondsdevice_ae:9a:22:48:0f:70"seconds0 + /health/locatedevice_ae:9a:22:48:0f:70"0 / /network/mac-addressdevice_ae:9a:22:48:0f:70" . . . 3e8 <- Chunk size hex byte _PLUS_rawdevice_ae:9a:22:48:0f:70"0 6 /dev/ISHARE_CBU_MINUS_rawdevice_ae:9a:22:48:0f:70"0 . . . /dev/part_iddevice_ae:9a:22:48:0f:70"0��������� , /dev/part_typedevice_ae:9a:22:48:0f:70"0 7 /dev/part_telemetry_disabledevice_ae:9a:22:48:0f:70"0 0 <- Termination Byte 0 ``` 2) Verfied that HTTP/1.0 requests are served with response without chunked transfer encoding and the connection is closed immediately. Query exits immediately indicating the connection is closed immediately ``` time printf "GET /telem HTTP/1.0\r\nHost: 192.0.3.11\r\n\r\n" | nc 192.0.3.11 80 real 0m0.186s <- Indicates connection was terminated immediately. user 0m0.018s sys 0m0.030s ``` `Transfer Encoding : chunked` header and chunked encoding metadata (chunk size hex bytes, crlf) not present in the response ``` HTTP/1.1 200 OK Content-Type: text/html : /health/uptimedevice_ae:9a:22:48:0f:70"seconds0 + /health/locatedevice_ae:9a:22:48:0f:70"0 / /network/mac-addressdevice_ae:9a:22:48:0f:70" . . . 3 /dev/part_iddevice_ae:9a:22:48:0f:70"0��������� , /dev/part_typedevice_ae:9a:22:48:0f:70"0 7 /dev/can_telemetry_disabledevice_ae:9a:22:48:0f:70"0 ``` Signed-off-by: Nikhil Namjoshi <nikhilnamjoshi@google.com>
fabiobaltieri
pushed a commit
that referenced
this pull request
Jan 8, 2026
Per RFC9112 (REF #1), HTTP/1.1 server is expected to be backward compatible with HTTP1.0 request. Mainly HTTP/1.0 does not support 1) Transfer Encoding : chunked 2) KeepAlives So, this change will identify the HTTP protocol version in the request and respond accordingly. REF# 1) https://httpwg.org/specs/rfc9112.html Tested: 1) Verified that HTTP/1.1 requests are served as usual i.e. with chunked transfer encoding and the connection is a Keep Alive connection Query exits after 10s, indicating that the client connection to the HTTP server is a Keep Alive. ``` time printf "GET /telem HTTP/1.1\r\nHost: 192.0.3.11\r\n\r\n" | nc 192.0.3.11 80 real 0m10.185s <- Indicates connection was kept active for 10s user 0m0.023s sys 0m0.023s ``` `Transfer Encoding : chunked` header and chunked encoding metadata (chunk size hex bytes, crlf, termination byte 0) are present in the response. ``` HTTP/1.1 200 OK Transfer-Encoding: chunked <- Chunked encoding header Content-Type: text/html 3e8 <- Chunk size hex bytes : /health/secondsdevice_ae:9a:22:48:0f:70"seconds0 + /health/locatedevice_ae:9a:22:48:0f:70"0 / /network/mac-addressdevice_ae:9a:22:48:0f:70" . . . 3e8 <- Chunk size hex byte _PLUS_rawdevice_ae:9a:22:48:0f:70"0 6 /dev/ISHARE_CBU_MINUS_rawdevice_ae:9a:22:48:0f:70"0 . . . /dev/part_iddevice_ae:9a:22:48:0f:70"0��������� , /dev/part_typedevice_ae:9a:22:48:0f:70"0 7 /dev/part_telemetry_disabledevice_ae:9a:22:48:0f:70"0 0 <- Termination Byte 0 ``` 2) Verfied that HTTP/1.0 requests are served with response without chunked transfer encoding and the connection is closed immediately. Query exits immediately indicating the connection is closed immediately ``` time printf "GET /telem HTTP/1.0\r\nHost: 192.0.3.11\r\n\r\n" | nc 192.0.3.11 80 real 0m0.186s <- Indicates connection was terminated immediately. user 0m0.018s sys 0m0.030s ``` `Transfer Encoding : chunked` header and chunked encoding metadata (chunk size hex bytes, crlf) not present in the response ``` HTTP/1.1 200 OK Content-Type: text/html : /health/uptimedevice_ae:9a:22:48:0f:70"seconds0 + /health/locatedevice_ae:9a:22:48:0f:70"0 / /network/mac-addressdevice_ae:9a:22:48:0f:70" . . . 3 /dev/part_iddevice_ae:9a:22:48:0f:70"0��������� , /dev/part_typedevice_ae:9a:22:48:0f:70"0 7 /dev/can_telemetry_disabledevice_ae:9a:22:48:0f:70"0 ``` Signed-off-by: Nikhil Namjoshi <nikhilnamjoshi@google.com>
marcmo
pushed a commit
to esrlabs/zephyr
that referenced
this pull request
Jan 30, 2026
wearyzen
pushed a commit
to wearyzen/zephyr
that referenced
this pull request
Feb 14, 2026
I'm at a loss here. The feature this test case wants to see (on ARMv7M, not ARMv6M) is the ability to take a irq_lock() inside a system call and then see that future system calls from the same thread continue to hold the lock. That's not documented AFAICT. It's also just a terrible idea because either: 1. The obvious denial of service implications if user code is allowed to run in an unpreemptible mode, or: 2. The broken locking promise if this is implemented to release the lock and reacquire it in an attempt to avoid zephyrproject-rtos#1. (FWIW: my read of the code is that zephyrproject-rtos#1 is the current implementation. But hilariously the test isn't able to tell the difference!) And in any case it's not how any of our other platforms work (or can work, in some cases), making this a non-portable system call API/feature at best. Leave it in place for now out of conservatism, but disable with the new arch_switch() code, whose behavior matches that of other Zephyr userspaces. Signed-off-by: Andy Ross <andyross@google.com>
1 task
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.