text:
[Dynamic Routing] Mention nested routes in the docs

Hi team,
Looking at docs I was not able to find any info on nested dynamic routes. I found all the needed info on examples https://github.com/zeit/next.js/tree/canary/examples/dynamic-routing#the-idea-behind-the-example though.
I thought it would make sense to mention about nested routes on the docs to save someone's time.
Please let me know if this makes sense to you.
Thanks 🙏

@yuyokk That one is already a nested route, probably better to add a note to show the usage for multiple brackets, e.g: pages/[post]/[comment]

Stats from current PR

Default Server Mode (Increase detected ⚠)

General Overall increase ⚠

zeit/next.js canary
yuyokk/next.js patch-1
Change

buildDuration
21.8s
21.5s
-235ms

nodeModulesSize
41.2 MB
41.2 MB
⚠ +121 B

Client Bundles (main, webpack, commons)

zeit/next.js canary
yuyokk/next.js patch-1
Change

main-HASH.js
13.8 kB
13.8 kB
✓

main-HASH.js gzip
4.87 kB
4.87 kB
✓

webpack-HASH.js
1.53 kB
1.53 kB
✓

webpack-HASH.js gzip
746 B
746 B
✓

commons.HASH.js
194 kB
194 kB
✓

commons.HASH.js gzip
63.1 kB
63.1 kB
✓

Overall change

✓

Client Bundles (main, webpack, commons) Modern

zeit/next.js canary
yuyokk/next.js patch-1
Change

main-HASH.module.js
11.4 kB
11.4 kB
✓

main-HASH.module.js gzip
4.31 kB
4.31 kB
✓

webpack-HASH.module.js
1.53 kB
1.53 kB
✓

webpack-HASH.module.js gzip
746 B
746 B
✓

commons.HASH.module.js
175 kB
175 kB
✓

commons.HASH.module.js gzip
57.1 kB
57.1 kB
✓

Overall change

✓

Client Pages

zeit/next.js canary
yuyokk/next.js patch-1
Change

_app.js
1.9 kB
1.9 kB
✓

_app.js gzip
905 B
905 B
✓

_error.js
8.02 kB
8.02 kB
✓

_error.js gzip
3.12 kB
3.12 kB
✓

index.js
343 B
343 B
✓

index.js gzip
237 B
237 B
✓

link.js
4.07 kB
4.07 kB
✓

link.js gzip
1.79 kB
1.79 kB
✓

routerDirect.js
423 B
423 B
✓

routerDirect.js gzip
290 B
290 B
✓

withRouter.js
435 B
435 B
✓

withRouter.js gzip
286 B
287 B
⚠ +1 B

Overall change

✓

Client Pages Modern

zeit/next.js canary
yuyokk/next.js patch-1
Change

_app.module.js
1.79 kB
1.79 kB
✓

_app.module.js gzip
865 B
865 B
✓

_error.module.js
5.82 kB
5.82 kB
✓

_error.module.js gzip
2.33 kB
2.33 kB
✓

index.module.js
319 B
319 B
✓

index.module.js gzip
238 B
238 B
✓

link.module.js
3.78 kB
3.78 kB
✓

link.module.js gzip
1.7 kB
1.7 kB
⚠ +1 B

routerDirect.module.js
411 B
411 B
✓

routerDirect.module.js gzip
291 B
291 B
✓

withRouter.module.js
423 B
423 B
✓

withRouter.module.js gzip
288 B
288 B
✓

Overall change

✓

Fetched pages

zeit/next.js canary
yuyokk/next.js patch-1
Change

link
2.81 kB
2.81 kB
✓

link gzip
847 B
846 B
-1 B

index
2.76 kB
2.76 kB
✓

index gzip
836 B
837 B
⚠ +1 B

withRouter
2.82 kB
2.82 kB
✓

withRouter gzip
835 B
833 B
-2 B

Overall change

✓

Serverless Mode (Increase detected ⚠)

General Overall increase ⚠

zeit/next.js canary
yuyokk/next.js patch-1
Change

buildDuration
23.3s
23s
-265ms

nodeModulesSize
41.2 MB
41.2 MB
⚠ +121 B

Client Bundles (main, webpack, commons)

zeit/next.js canary
yuyokk/next.js patch-1
Change

main-HASH.js
13.8 kB
13.8 kB
✓

main-HASH.js gzip
4.87 kB
4.87 kB
✓

webpack-HASH.js
1.53 kB
1.53 kB
✓

webpack-HASH.js gzip
746 B
746 B
✓

commons.HASH.js
194 kB
194 kB
✓

commons.HASH.js gzip
63.1 kB
63.1 kB
✓

Overall change

✓

Client Bundles (main, webpack, commons) Modern

zeit/next.js canary
yuyokk/next.js patch-1
Change

main-HASH.module.js
11.4 kB
11.4 kB
✓

main-HASH.module.js gzip
4.31 kB
4.31 kB
✓

webpack-HASH.module.js
1.53 kB
1.53 kB
✓

webpack-HASH.module.js gzip
746 B
746 B
✓

commons.HASH.module.js
175 kB
175 kB
✓

commons.HASH.module.js gzip
57.1 kB
57.1 kB
✓

Overall change

✓

Client Pages

zeit/next.js canary
yuyokk/next.js patch-1
Change

_app.js
1.9 kB
1.9 kB
✓

_app.js gzip
905 B
905 B
✓

_error.js
8.02 kB
8.02 kB
✓

_error.js gzip
3.12 kB
3.12 kB
✓

index.js
343 B
343 B
✓

index.js gzip
237 B
237 B
✓

link.js
4.07 kB
4.07 kB
✓

link.js gzip
1.79 kB
1.79 kB
✓

routerDirect.js
423 B
423 B
✓

routerDirect.js gzip
290 B
290 B
✓

withRouter.js
435 B
435 B
✓

withRouter.js gzip
287 B
287 B
✓

Overall change

✓

Client Pages Modern

zeit/next.js canary
yuyokk/next.js patch-1
Change

_app.module.js
1.79 kB
1.79 kB
✓

_app.module.js gzip
865 B
865 B
✓

_error.module.js
5.82 kB
5.82 kB
✓

_error.module.js gzip
2.33 kB
2.33 kB
✓

index.module.js
319 B
319 B
✓

index.module.js gzip
238 B
238 B
✓

link.module.js
3.78 kB
3.78 kB
✓

link.module.js gzip
1.7 kB
1.7 kB
✓

routerDirect.module.js
411 B
411 B
✓

routerDirect.module.js gzip
291 B
291 B
✓

withRouter.module.js
423 B
423 B
✓

withRouter.module.js gzip
288 B
288 B
✓

Overall change

✓

Serverless bundles

zeit/next.js canary
yuyokk/next.js patch-1
Change

_error.js
247 kB
247 kB
✓

_error.js gzip
66.2 kB
66.2 kB
⚠ +1 B

index.js
247 kB
247 kB
✓

index.js gzip
66.5 kB
66.5 kB
✓

link.js
255 kB
255 kB
✓

link.js gzip
68.7 kB
68.7 kB
✓

routerDirect.js
248 kB
248 kB
✓

routerDirect.js gzip
66.4 kB
66.4 kB
✓

withRouter.js
248 kB
248 kB
✓

withRouter.js gzip
66.5 kB
66.5 kB
⚠ +1 B

Overall change

✓

Stats from current PR

Default Server Mode (Increase detected ⚠)

General Overall increase ⚠

zeit/next.js canary
yuyokk/next.js patch-1
Change

buildDuration
23.7s
24.1s
⚠ +400ms

nodeModulesSize
41.2 MB
41.2 MB
⚠ +99 B

Client Bundles (main, webpack, commons)

zeit/next.js canary
yuyokk/next.js patch-1
Change

main-HASH.js
13.8 kB
13.8 kB
✓

main-HASH.js gzip
4.87 kB
4.87 kB
✓

webpack-HASH.js
1.53 kB
1.53 kB
✓

webpack-HASH.js gzip
746 B
746 B
✓

commons.HASH.js
194 kB
194 kB
✓

commons.HASH.js gzip
63.1 kB
63.1 kB
✓

Overall change

✓

Client Bundles (main, webpack, commons) Modern

zeit/next.js canary
yuyokk/next.js patch-1
Change

main-HASH.module.js
11.4 kB
11.4 kB
✓

main-HASH.module.js gzip
4.31 kB
4.31 kB
✓

webpack-HASH.module.js
1.53 kB
1.53 kB
✓

webpack-HASH.module.js gzip
746 B
746 B
✓

commons.HASH.module.js
175 kB
175 kB
✓

commons.HASH.module.js gzip
57.1 kB
57.1 kB
✓

Overall change

✓

Client Pages

zeit/next.js canary
yuyokk/next.js patch-1
Change

_app.js
1.9 kB
1.9 kB
✓

_app.js gzip
905 B
905 B
✓

_error.js
8.02 kB
8.02 kB
✓

_error.js gzip
3.12 kB
3.12 kB
✓

index.js
343 B
343 B
✓

index.js gzip
237 B
237 B
✓

link.js
4.07 kB
4.07 kB
✓

link.js gzip
1.79 kB
1.79 kB
✓

routerDirect.js
423 B
423 B
✓

routerDirect.js gzip
290 B
290 B
✓

withRouter.js
435 B
435 B
✓

withRouter.js gzip
286 B
287 B
⚠ +1 B

Overall change

✓

Client Pages Modern

zeit/next.js canary
yuyokk/next.js patch-1
Change

_app.module.js
1.79 kB
1.79 kB
✓

_app.module.js gzip
865 B
865 B
✓

_error.module.js
5.82 kB
5.82 kB
✓

_error.module.js gzip
2.33 kB
2.33 kB
✓

index.module.js
319 B
319 B
✓

index.module.js gzip
238 B
238 B
✓

link.module.js
3.78 kB
3.78 kB
✓

link.module.js gzip
1.7 kB
1.7 kB
⚠ +1 B

routerDirect.module.js
411 B
411 B
✓

routerDirect.module.js gzip
291 B
291 B
✓

withRouter.module.js
423 B
423 B
✓

withRouter.module.js gzip
288 B
288 B
✓

Overall change

✓

Fetched pages

zeit/next.js canary
yuyokk/next.js patch-1
Change

link
2.81 kB
2.81 kB
✓

link gzip
848 B
846 B
-2 B

index
2.76 kB
2.76 kB
✓

index gzip
837 B
836 B
-1 B

withRouter
2.82 kB
2.82 kB
✓

withRouter gzip
833 B
832 B
-1 B

Overall change

✓

Serverless Mode (Increase detected ⚠)

General Overall increase ⚠

zeit/next.js canary
yuyokk/next.js patch-1
Change

buildDuration
25.3s
26.3s
⚠ +981ms

nodeModulesSize
41.2 MB
41.2 MB
⚠ +99 B

Client Bundles (main, webpack, commons)

zeit/next.js canary
yuyokk/next.js patch-1
Change

main-HASH.js
13.8 kB
13.8 kB
✓

main-HASH.js gzip
4.87 kB
4.87 kB
✓

webpack-HASH.js
1.53 kB
1.53 kB
✓

webpack-HASH.js gzip
746 B
746 B
✓

commons.HASH.js
194 kB
194 kB
✓

commons.HASH.js gzip
63.1 kB
63.1 kB
✓

Overall change

✓

Client Bundles (main, webpack, commons) Modern

zeit/next.js canary
yuyokk/next.js patch-1
Change

main-HASH.module.js
11.4 kB
11.4 kB
✓

main-HASH.module.js gzip
4.31 kB
4.31 kB
✓

webpack-HASH.module.js
1.53 kB
1.53 kB
✓

webpack-HASH.module.js gzip
746 B
746 B
✓

commons.HASH.module.js
175 kB
175 kB
✓

commons.HASH.module.js gzip
57.1 kB
57.1 kB
✓

Overall change

✓

Client Pages

zeit/next.js canary
yuyokk/next.js patch-1
Change

_app.js
1.9 kB
1.9 kB
✓

_app.js gzip
905 B
905 B
✓

_error.js
8.02 kB
8.02 kB
✓

_error.js gzip
3.12 kB
3.12 kB
✓

index.js
343 B
343 B
✓

index.js gzip
237 B
237 B
✓

link.js
4.07 kB
4.07 kB
✓

link.js gzip
1.79 kB
1.79 kB
✓

routerDirect.js
423 B
423 B
✓

routerDirect.js gzip
290 B
290 B
✓

withRouter.js
435 B
435 B
✓

withRouter.js gzip
287 B
287 B
✓

Overall change

✓

Client Pages Modern

zeit/next.js canary
yuyokk/next.js patch-1
Change

_app.module.js
1.79 kB
1.79 kB
✓

_app.module.js gzip
865 B
865 B
✓

_error.module.js
5.82 kB
5.82 kB
✓

_error.module.js gzip
2.33 kB
2.33 kB
✓

index.module.js
319 B
319 B
✓

index.module.js gzip
238 B
238 B
✓

link.module.js
3.78 kB
3.78 kB
✓

link.module.js gzip
1.7 kB
1.7 kB
✓

routerDirect.module.js
411 B
411 B
✓

routerDirect.module.js gzip
291 B
291 B
✓

withRouter.module.js
423 B
423 B
✓

withRouter.module.js gzip
288 B
288 B
✓

Overall change

✓

Serverless bundles

zeit/next.js canary
yuyokk/next.js patch-1
Change

_error.js
247 kB
247 kB
✓

_error.js gzip
66.2 kB
66.2 kB
✓

index.js
247 kB
247 kB
✓

index.js gzip
66.5 kB
66.5 kB
✓

link.js
255 kB
255 kB
✓

link.js gzip
68.7 kB
68.7 kB
-1 B

routerDirect.js
248 kB
248 kB
✓

routerDirect.js gzip
66.4 kB
66.4 kB
✓

withRouter.js
248 kB
248 kB
✓

withRouter.js gzip
66.5 kB
66.5 kB
⚠ +1 B

Overall change

✓

Stats from current PR

Default Server Mode (Increase detected ⚠)

General Overall increase ⚠

zeit/next.js canary
yuyokk/next.js patch-1
Change

buildDuration
20.6s
20.5s
-62ms

nodeModulesSize
41.2 MB
41.2 MB
⚠ +98 B

Client Bundles (main, webpack, commons)

zeit/next.js canary
yuyokk/next.js patch-1
Change

main-HASH.js
13.8 kB
13.8 kB
✓

main-HASH.js gzip
4.87 kB
4.87 kB
✓

webpack-HASH.js
1.53 kB
1.53 kB
✓

webpack-HASH.js gzip
746 B
746 B
✓

commons.HASH.js
194 kB
194 kB
✓

commons.HASH.js gzip
63.1 kB
63.1 kB
✓

Overall change

✓

Client Bundles (main, webpack, commons) Modern

zeit/next.js canary
yuyokk/next.js patch-1
Change

main-HASH.module.js
11.4 kB
11.4 kB
✓

main-HASH.module.js gzip
4.31 kB
4.31 kB
✓

webpack-HASH.module.js
1.53 kB
1.53 kB
✓

webpack-HASH.module.js gzip
746 B
746 B
✓

commons.HASH.module.js
175 kB
175 kB
✓

commons.HASH.module.js gzip
57.1 kB
57.1 kB
✓

Overall change

✓

Client Pages

zeit/next.js canary
yuyokk/next.js patch-1
Change

_app.js
1.9 kB
1.9 kB
✓

_app.js gzip
905 B
905 B
✓

_error.js
8.02 kB
8.02 kB
✓

_error.js gzip
3.12 kB
3.12 kB
✓

index.js
343 B
343 B
✓

index.js gzip
237 B
237 B
✓

link.js
4.07 kB
4.07 kB
✓

link.js gzip
1.79 kB
1.79 kB
✓

routerDirect.js
423 B
423 B
✓

routerDirect.js gzip
290 B
290 B
✓

withRouter.js
435 B
435 B
✓

withRouter.js gzip
287 B
287 B
✓

Overall change

✓

Client Pages Modern

zeit/next.js canary
yuyokk/next.js patch-1
Change

_app.module.js
1.79 kB
1.79 kB
✓

_app.module.js gzip
865 B
865 B
✓

_error.module.js
5.82 kB
5.82 kB
✓

_error.module.js gzip
2.33 kB
2.33 kB
✓

index.module.js
319 B
319 B
✓

index.module.js gzip
238 B
238 B
✓

link.module.js
3.78 kB
3.78 kB
✓

link.module.js gzip
1.7 kB
1.7 kB
✓

routerDirect.module.js
411 B
411 B
✓

routerDirect.module.js gzip
291 B
291 B
✓

withRouter.module.js
423 B
423 B
✓

withRouter.module.js gzip
288 B
288 B
✓

Overall change

✓

Fetched pages

zeit/next.js canary
yuyokk/next.js patch-1
Change

link
2.81 kB
2.81 kB
✓

link gzip
844 B
845 B
⚠ +1 B

index
2.76 kB
2.76 kB
✓

index gzip
838 B
835 B
-3 B

withRouter
2.82 kB
2.82 kB
✓

withRouter gzip
833 B
830 B
-3 B

Overall change

✓

Serverless Mode (Increase detected ⚠)

General Overall increase ⚠

zeit/next.js canary
yuyokk/next.js patch-1
Change

buildDuration
22.4s
21.8s
-602ms

nodeModulesSize
41.2 MB
41.2 MB
⚠ +98 B

Client Bundles (main, webpack, commons)

zeit/next.js canary
yuyokk/next.js patch-1
Change

main-HASH.js
13.8 kB
13.8 kB
✓

main-HASH.js gzip
4.87 kB
4.87 kB
✓

webpack-HASH.js
1.53 kB
1.53 kB
✓

webpack-HASH.js gzip
746 B
746 B
✓

commons.HASH.js
194 kB
194 kB
✓

commons.HASH.js gzip
63.1 kB
63.1 kB
✓

Overall change

✓

Client Bundles (main, webpack, commons) Modern

zeit/next.js canary
yuyokk/next.js patch-1
Change

main-HASH.module.js
11.4 kB
11.4 kB
✓

main-HASH.module.js gzip
4.31 kB
4.31 kB
✓

webpack-HASH.module.js
1.53 kB
1.53 kB
✓

webpack-HASH.module.js gzip
746 B
746 B
✓

commons.HASH.module.js
175 kB
175 kB
✓

commons.HASH.module.js gzip
57.1 kB
57.1 kB
✓

Overall change

✓

Client Pages

zeit/next.js canary
yuyokk/next.js patch-1
Change

_app.js
1.9 kB
1.9 kB
✓

_app.js gzip
905 B
905 B
✓

_error.js
8.02 kB
8.02 kB
✓

_error.js gzip
3.12 kB
3.12 kB
✓

index.js
343 B
343 B
✓

index.js gzip
237 B
237 B
✓

link.js
4.07 kB
4.07 kB
✓

link.js gzip
1.79 kB
1.79 kB
✓

routerDirect.js
423 B
423 B
✓

routerDirect.js gzip
290 B
290 B
✓

withRouter.js
435 B
435 B
✓

withRouter.js gzip
287 B
287 B
✓

Overall change

✓

Client Pages Modern

zeit/next.js canary
yuyokk/next.js patch-1
Change

_app.module.js
1.79 kB
1.79 kB
✓

_app.module.js gzip
865 B
865 B
✓

_error.module.js
5.82 kB
5.82 kB
✓

_error.module.js gzip
2.33 kB
2.33 kB
✓

index.module.js
319 B
319 B
✓

index.module.js gzip
238 B
238 B
✓

link.module.js
3.78 kB
3.78 kB
✓

link.module.js gzip
1.7 kB
1.7 kB
✓

routerDirect.module.js
411 B
411 B
✓

routerDirect.module.js gzip
291 B
291 B
✓

withRouter.module.js
423 B
423 B
✓

withRouter.module.js gzip
288 B
288 B
✓

Overall change

✓

Serverless bundles

zeit/next.js canary
yuyokk/next.js patch-1
Change

_error.js
247 kB
247 kB
✓

_error.js gzip
66.2 kB
66.2 kB
⚠ +1 B

index.js
247 kB
247 kB
✓

index.js gzip
66.5 kB
66.5 kB
⚠ +1 B

link.js
255 kB
255 kB
✓

link.js gzip
68.7 kB
68.7 kB
⚠ +2 B

routerDirect.js
248 kB
248 kB
✓

routerDirect.js gzip
66.4 kB
66.4 kB
⚠ +1 B

withRouter.js
248 kB
248 kB
✓

withRouter.js gzip
66.5 kB
66.5 kB
⚠ +1 B

Overall change

✓

Stats from current PR

Default Server Mode (Increase detected ⚠)

General Overall increase ⚠

zeit/next.js canary
yuyokk/next.js patch-1
Change

buildDuration
22.9s
23.3s
⚠ +385ms

nodeModulesSize
41.2 MB
41.2 MB
⚠ +212 B

Client Bundles (main, webpack, commons)

zeit/next.js canary
yuyokk/next.js patch-1
Change

main-HASH.js
13.8 kB
13.8 kB
✓

main-HASH.js gzip
4.87 kB
4.87 kB
✓

webpack-HASH.js
1.53 kB
1.53 kB
✓

webpack-HASH.js gzip
746 B
746 B
✓

commons.HASH.js
194 kB
194 kB
✓

commons.HASH.js gzip
63.1 kB
63.1 kB
✓

Overall change

✓

Client Bundles (main, webpack, commons) Modern

zeit/next.js canary
yuyokk/next.js patch-1
Change

main-HASH.module.js
11.4 kB
11.4 kB
✓

main-HASH.module.js gzip
4.31 kB
4.31 kB
✓

webpack-HASH.module.js
1.53 kB
1.53 kB
✓

webpack-HASH.module.js gzip
746 B
746 B
✓

commons.HASH.module.js
175 kB
175 kB
✓

commons.HASH.module.js gzip
57.1 kB
57.1 kB
✓

Overall change

✓

Client Pages

zeit/next.js canary
yuyokk/next.js patch-1
Change

_app.js
1.9 kB
1.9 kB
✓

_app.js gzip
905 B
905 B
✓

_error.js
8.02 kB
8.02 kB
✓

_error.js gzip
3.12 kB
3.12 kB
✓

index.js
343 B
343 B
✓

index.js gzip
237 B
237 B
✓

link.js
4.07 kB
4.07 kB
✓

link.js gzip
1.79 kB
1.79 kB
✓

routerDirect.js
423 B
423 B
✓

routerDirect.js gzip
290 B
290 B
✓

withRouter.js
435 B
435 B
✓

withRouter.js gzip
287 B
287 B
✓

Overall change

✓

Client Pages Modern

zeit/next.js canary
yuyokk/next.js patch-1
Change

_app.module.js
1.79 kB
1.79 kB
✓

_app.module.js gzip
865 B
865 B
✓

_error.module.js
5.82 kB
5.82 kB
✓

_error.module.js gzip
2.33 kB
2.33 kB
✓

index.module.js
319 B
319 B
✓

index.module.js gzip
238 B
238 B
✓

link.module.js
3.78 kB
3.78 kB
✓

link.module.js gzip
1.7 kB
1.7 kB
✓

routerDirect.module.js
411 B
411 B
✓

routerDirect.module.js gzip
291 B
291 B
✓

withRouter.module.js
423 B
423 B
✓

withRouter.module.js gzip
288 B
288 B
✓

Overall change

✓

Fetched pages

zeit/next.js canary
yuyokk/next.js patch-1
Change

link
2.81 kB
2.81 kB
✓

link gzip
846 B
846 B
✓

index
2.76 kB
2.76 kB
✓

index gzip
837 B
836 B
-1 B

withRouter
2.82 kB
2.82 kB
✓

withRouter gzip
834 B
835 B
⚠ +1 B

Overall change

✓

Serverless Mode (Increase detected ⚠)

General Overall increase ⚠

zeit/next.js canary
yuyokk/next.js patch-1
Change

buildDuration
25.3s
24.9s
-400ms

nodeModulesSize
41.2 MB
41.2 MB
⚠ +212 B

Client Bundles (main, webpack, commons)

zeit/next.js canary
yuyokk/next.js patch-1
Change

main-HASH.js
13.8 kB
13.8 kB
✓

main-HASH.js gzip
4.87 kB
4.87 kB
✓

webpack-HASH.js
1.53 kB
1.53 kB
✓

webpack-HASH.js gzip
746 B
746 B
✓

commons.HASH.js
194 kB
194 kB
✓

commons.HASH.js gzip
63.1 kB
63.1 kB
✓

Overall change

✓

Client Bundles (main, webpack, commons) Modern

zeit/next.js canary
yuyokk/next.js patch-1
Change

main-HASH.module.js
11.4 kB
11.4 kB
✓

main-HASH.module.js gzip
4.31 kB
4.31 kB
✓

webpack-HASH.module.js
1.53 kB
1.53 kB
✓

webpack-HASH.module.js gzip
746 B
746 B
✓

commons.HASH.module.js
175 kB
175 kB
✓

commons.HASH.module.js gzip
57.1 kB
57.1 kB
✓

Overall change

✓

Client Pages

zeit/next.js canary
yuyokk/next.js patch-1
Change

_app.js
1.9 kB
1.9 kB
✓

_app.js gzip
905 B
905 B
✓

_error.js
8.02 kB
8.02 kB
✓

_error.js gzip
3.12 kB
3.12 kB
✓

index.js
343 B
343 B
✓

index.js gzip
237 B
237 B
✓

link.js
4.07 kB
4.07 kB
✓

link.js gzip
1.79 kB
1.79 kB
✓

routerDirect.js
423 B
423 B
✓

routerDirect.js gzip
290 B
290 B
✓

withRouter.js
435 B
435 B
✓

withRouter.js gzip
287 B
287 B
✓

Overall change

✓

Client Pages Modern

zeit/next.js canary
yuyokk/next.js patch-1
Change

_app.module.js
1.79 kB
1.79 kB
✓

_app.module.js gzip
865 B
865 B
✓

_error.module.js
5.82 kB
5.82 kB
✓

_error.module.js gzip
2.33 kB
2.33 kB
✓

index.module.js
319 B
319 B
✓

index.module.js gzip
238 B
238 B
✓

link.module.js
3.78 kB
3.78 kB
✓

link.module.js gzip
1.7 kB
1.7 kB
✓

routerDirect.module.js
411 B
411 B
✓

routerDirect.module.js gzip
291 B
291 B
✓

withRouter.module.js
423 B
423 B
✓

withRouter.module.js gzip
288 B
288 B
✓

Overall change

✓

Serverless bundles

zeit/next.js canary
yuyokk/next.js patch-1
Change

_error.js
247 kB
247 kB
✓

_error.js gzip
66.2 kB
66.2 kB
-1 B

index.js
247 kB
247 kB
✓

index.js gzip
66.5 kB
66.5 kB
✓

link.js
255 kB
255 kB
✓

link.js gzip
68.7 kB
68.7 kB
✓

routerDirect.js
248 kB
248 kB
✓

routerDirect.js gzip
66.4 kB
66.4 kB
✓

withRouter.js
248 kB
248 kB
✓

withRouter.js gzip
66.5 kB
66.5 kB
✓

Overall change

✓

authors: ijjk lfades yuyokk


text:
Fix pseudo selectors and classes

This branch fixes pseudo selector and classes being suffixed when they should not.
:root {}
::before {}
:hover {}
p :hover {}

should not be suffixed (except for the p ofc)

🤔 actually they should be suffixed probably then we may want to whitelist only a few of them like :root – it is not quite clear to me how to use such a selector, probably making it global is even wrong.

I will discard this PR and investigate / think further

source: gharchive/pull-request

repo: zeit/styled-jsx

license: mit

license_type: permissive

license_source: bigquery


text:
User Definable XML Data Structures

Kenix had the idea of allowing new data structures to be defined in a Game.xml. These would take advantage of the existing ZResource types, especially primitives and vectors. This should make ZAP a bit more extendable, allowing it to mirror structs in the game codebase.

In retrospect this probably isn't going to be needed.

source: gharchive/issue

repo: zeldaret/ZAPD

license: MIT

license_source: github-api


text:
Delay value decryption on chrome

This pull request adds a new ValueFilterFunc to kooky. If there is no filter regarding Value in the cookie, it is unnecessary to decrypt its value. We checks if there is a ValueFilterFunc in the filters before performing the decryption. After filtering is complete, the Value field is populated with the result of the decrypt.

But there is a risk this change may break code that using custom filter without wrapping it in ValueFilterFunc, it always gets empty value.

repo: zellyn/kooky


text:
Enhancement: Raise minimum PHP version to PHP 7.1

This PR

[x] raises the minimum PHP version from PHP 5.5 to PHP 7.1
[x] updates phpunit/phpunit
[ ] ...

💁♂ For reference, see http://tinyletter.com/mwopzend/letters/zend-framework-community-news-for-the-week-of-2017-04-20.

@localheinz
Develop branch!

Ha, thank you, @froschdesign! Will take a look later!

@froschdesign @weierophinney
What do you think, should we also use

strict types
scalar type hints
return type declarations

?

@localheinz

strict types
scalar type hints
return type declarations

Void return types
Nullable types
"iterable" pseudo-type
…

All features which simplify the code and make the interfaces more clear.

Btw. HHVM makes no sense if we allow failures on Travis.

authors: froschdesign localheinz

repo: zendframework/zend-file


text:
Add webimpress/http-middleware-compatibility support

Add webimpress/http-middleware-compatibility support to make zend-mvc fully compatible with zend-stratigility 2.1

I've written up a proposal for how we should go about updating to PSR-15 on the forums:

https://discourse.zendframework.com/t/psr-15-compatibility-issues-and-proposal/378

Please read and comment there before moving forwards with the current pull request.

authors: Xerkus weierophinney

repo: zendframework/zend-mvc


text:
Performance Fix

unsetting a non-existing rule doesn't throw an error.
In our Project this change improves loading time from 55 sec to 0.5 sec
(14412 Resources, 11694 Rules)

ZF1 has reached its EOL and is no longer maintained.

authors: froschdesign schrankenstein


text:
Wrong syntax (hook from #7609)

The issue in the subject was closed by Bittarman but the evidence showed points to anoter repository.
The file Version\Version.php of 2.4.4 release has a wrong declaration of constants, wich broke the entire aplication.
The line 23 of this file shoud be something like this:
const VERSION = '2.4.4'
Look at https://github.com/zendframework/zf2/blob/release-2.4.4/library/Zend/Version/Version.php to see the problem.
Thanks.

Confirm

Fixed, and replaced the release-2.4.4 tag with the fixed version.

Thanks guys! :D

authors: Maks3w danilomrgouvea weierophinney


text:
Typo in #6598 pull request.

Fixing of IntlException instance name

Urgh, this is obviously because I couldn't get to write a test case for that exception -.- Thanks for spotting it!

You welcome =). By the way, this exception exists in PHP >=5.5.0. I don't know how PHP < 5.5.0 will behave in this situation. I will try to write test for this when I have time.

@filipp-qoma <5.5.0 uses a manual throwing mechanism

@filipp-qoma merged, thanks!
master: zendframework/zf2@f6a01fc2879be05e608196dd73cb925a47382664
develop: zendframework/zf2@56bb6fea69556add75dfabed75565e99559b9f4f

authors: Ocramius filipp-qoma


text:
Bullet and Number size not changing with Font Size

Hi,
I am using numbering part for the editor but the size of number remain same even if I increase the font size to Huge.

Please address this upstream with the underlying editor, Quill. The issue may have been fixed in the upcoming 1.0.0 release.
https://github.com/quilljs/quill

Issue still exist on the    "quill": "^1.3.7"  version of quillJS. so open this issue again.

This issue still exist in 2.0.0

repo: zenoamaro/react-quill


text:
CLion CMake error while opening nRF-Connect-SDK project

Hello!
I'm trying to reload CMake in an nRF-Connect-SDK project in the CLion IDE.
TL;DR: the error is:

CMake File API: D:\Programming\Embedded\Projects\SES\ncs\custom_project\custom_project\build_clion: no reply dir found

I've been using this guide:
https://blog.jetbrains.com/clion/2021/04/using-nrf52-with-cmake-connect-sdk/
My current toolchain and CMake settings are like these (the SDK version is 1.6.1):

The project starts reloading, it detects zephyr, west, etc., the build directory is created, but eventually it stumbles upon this error:
CMake File API: D:\Programming\Embedded\Projects\SES\ncs\custom_project\custom_project\build_clion: no reply dir found
I can see that in D:\Programming\Embedded\Projects\SES\ncs\custom_project\custom_project\build_clion.cmake\api\v1 there is only "query" directory, but no "reply".
"query" directory contains these empty files:

I'll list the CMake output from the stage where it fails here:
`-- libmetal version: 1.0.0 (D:/Programming/Embedded/Projects/SES/ncs/custom_project/custom_project)
-- Build type:  Debug
-- Host:    Windows/AMD64
-- Target:  Generic/arm
-- Machine: cortexm
-- Looking for include file stdatomic.h
-- Looking for include file stdatomic.h - found
-- open-amp version: 1.0.0 (D:/Programming/Embedded/Projects/SES/ncs/modules/lib/open-amp/open-amp)
-- Host:    Windows/AMD64
-- Target:  Generic/arm
-- Machine: cortexm
-- C_FLAGS :  -Wall -Wextra
-- Looking for include file fcntl.h
-- Looking for include file fcntl.h - found
CMake Warning at D:/Programming/Embedded/Projects/SES/ncs/zephyr/CMakeLists.txt:1635 (message):
    The CMake build type was set to 'Debug', but the optimization flag was set to '-Os'.
    This may be intentional and the warning can be turned off by setting the CMake variable 'NO_BUILD_TYPE_WARNING'

Partition 'mcuboot' is not included in the dynamic resolving since it is statically defined.
Partition 'mcuboot_pad' is not included in the dynamic resolving since it is statically defined.
Partition 'mcuboot_primary' is not included in the dynamic resolving since it is statically defined.
Partition 'mcuboot_primary_app' is not included in the dynamic resolving since it is statically defined.
Partition 'mcuboot_secondary' is not included in the dynamic resolving since it is statically defined.
Partition 'pcd_sram' is not included in the dynamic resolving since it is statically defined.
Partition 'rpmsg_nrf53_sram' is not included in the dynamic resolving since it is statically defined.
-- Configuring done
CMake Warning (dev) at D:/Programming/Embedded/Projects/SES/ncs/zephyr/cmake/linker/ld/target.cmake:33 (add_custom_command):
Policy CMP0116 is not set: Ninja generators transform DEPFILEs from
add_custom_command().  Run "cmake --help-policy CMP0116" for policy
details.  Use the cmake_policy command to set the policy and suppress this
warning.
Call Stack (most recent call first):
D:/Programming/Embedded/Projects/SES/ncs/zephyr/CMakeLists.txt:1198 (configure_linker_script)
This warning is for project developers.  Use -Wno-dev to suppress it.
CMake Warning (dev) at D:/Programming/Embedded/Projects/SES/ncs/zephyr/cmake/linker/ld/target.cmake:33 (add_custom_command):
Policy CMP0116 is not set: Ninja generators transform DEPFILEs from
add_custom_command().  Run "cmake --help-policy CMP0116" for policy
details.  Use the cmake_policy command to set the policy and suppress this
warning.
Call Stack (most recent call first):
D:/Programming/Embedded/Projects/SES/ncs/zephyr/CMakeLists.txt:1253 (configure_linker_script)
This warning is for project developers.  Use -Wno-dev to suppress it.
-- Generating done
-- Build files have been written to: D:/Programming/Embedded/Projects/SES/ncs/custom_project/custom_project/build_clion/build
CMake File API: D:\Programming\Embedded\Projects\SES\ncs\custom_project\custom_project\build_clion: no reply dir found
[Failed to reload]`

Sorry, but we don't support CLion officially, and this is the Zephyr project, not Nordic's nRF Connect SDK. You can either post this in a GitHub discussion referring instead to a version of Zephyr or post the question in the Nordic Devzone.

authors: carlescufi ilyaTanko

repo: zephyrproject-rtos/zephyr


text:
LwM2M: device hang after requesting a firmware update to a loopback device IP

Tested against commit b678895a6dadff7a10cb5ff6927ae74cc49fbae0
Issue a PACKAGE URI firmware update (/5/0/1) w/ URI set as coap://127.0.0.1:7783/large to start the firmware update process. The device will hang shortly after receive the request from server.
Issue is reproducible on both Qemu_x86 and FRDM K64F
Debug log as below

[net/conn] [DBG] net_conn_input: (0x00403660): Check UDP listener for pkt 0x00406060 src port 5683 dst port 37042 family 10 chksum 0x1186 len 48
[net/conn] [DBG] net_conn_input: (0x00403660): [0] match found cb 0x0000f302 ud 0x00400080 rank 0x33
[net/ctx] [DBG] packet_received: (0x00403660): Set appdata 0x0040564e to len 40 (total 88)
[lib/lwm2m_engine] [DBG] lwm2m_udp_receive: checking for reply from [2001:db8::2]
[lib/lwm2m_engine] [DBG] handle_request: No accept option given. Assume OMA TLV.
[net/app] [DBG] _net_app_select_net_ctx_debug: (0x00403660): Selecting 0x00403480 net_ctx (net_app_get_net_pkt():960)
[lwm2m_obj_firmware] [DBG] package_uri_write_cb: PACKAGE_URI WRITE: coap://127.0.0.1:7783/large
[lwm2m_obj_firmware] [DBG] lwm2m_firmware_set_update_state: Update state = 0
[lwm2m_obj_firmware] [DBG] lwm2m_firmware_set_update_result: Update result = 0
[lwm2m_obj_firmware] [DBG] lwm2m_firmware_set_update_state: Update state = 1
[net/ipv6] [DBG] net_ipv6_prepare_for_send: (0x00403660): No default route to 2001:db8::2
[net/ipv6] [DBG] net_ipv6_prepare_for_send: (0x00403660): Neighbor lookup 0x00422260 (0) iface 0x00422ca0 addr 2001:db8::2 state stale
[net/ipv6] [DBG] net_ipv6_prepare_for_send: (0x00403660): Neighbor 0x00422260 addr D6:EF:DF:AA:6D:81
[net/ipv6] [DBG] ipv6_nbr_set_state: (0x00403660): nbr 0x00422260 stale -> delay
[net/ethernet] [DBG] ethernet_send: (0x00403660): src 00:00:5E:00:53:4C dst D6:EF:DF:AA:6D:81 type 0x86dd len 53
[net/core] [DBG] processing_data: (0x00403660): Consumed pkt 0x00406060
[net/if] [DBG] net_if_tx: (0x00403720): Processing (pkt 0x00405de0, data len 53) network packet
[net/if] [DBG] net_if_tx: (0x00403720): Calling context send cb 0x00403480 token 0x00000000 status 0
[net/ctx] [DBG] net_context_bind: (0x00404330): Context 0x004034dc binding to UDP 192.0.2.1:59282 iface 0x00422ca0
[net/app] [DBG] _net_app_print_info: (0x00404330): net app connect 192.0.2.1:59282 -> 127.0.0.1:7783
[lwm2m_obj_firmware_pull] [INF] firmware_transfer: Connecting to server 127.0.0.1:7783/large, port 7783
[net/app] [DBG] _net_app_select_net_ctx_debug: (0x00404330): Selecting 0x004034dc net_ctx (net_app_connect():664)
[net/conn] [DBG] net_conn_register: (0x00404330): [1/2/17/0x33] remote 0x004034f0/127.0.0.1/7783 local 0x004212f4/192.0.2.1/59282 cb 0x0000f302 ud 0x00402c20
[net/app] [DBG] _net_app_select_net_ctx_debug: (0x00404330): Selecting 0x004034dc net_ctx (net_app_get_net_pkt():960)
[net/core] [DBG] net_send_data: (0x00404330): Loopback pkt 0x00405de0 back to us
[net/ipv4] [DBG] net_ipv4_process_pkt: (0x00404330): IPv4 packet received from 127.0.0.1 to 192.0.2.1
[net/conn] [DBG] net_conn_input: (0x00404330): Check UDP listener for pkt 0x00405de0 src port 59282 dst port 7783 family 2 chksum 0xee7e len 49
[net/conn] [DBG] net_conn_input: (0x00404330): No match found.
[net/icmpv4] [DBG] net_icmpv4_send_error: (0x00404330): Sending ICMPv4 Error Message type 3 code 3 from 192.0.2.1 to 127.0.0.1
[net/core] [DBG] net_send_data: (0x00404330): Loopback pkt 0x00405d60 back to us
[net/ipv4] [DBG] net_ipv4_process_pkt: (0x00404330): IPv4 packet received from 127.0.0.1 to 192.0.2.1
[net/ipv4] [DBG] process_icmpv4_pkt: (0x00404330): ICMPv4 packet received type 3 code 3
[net/core] [DBG] processing_data: (0x00404330): Dropping pkt 0x00405d60
[net/core] [DBG] processing_data: (0x00404330): Dropping pkt 0x00405de0

Digging a bit more.
It seems that the packet sent to loopback device will be unreferenced immediately when the packet.
lwm2m_send_message() doesn't get a chance to call coap_pending_cycle() to increase the reference count to avoid the packet from being freed which result in the device hang.
If I requested a firmware pull from an IP other than loopback, it seems that an ARP packet is generated and issued first for the IP resolving and then the firmware pull request packet.
The timing seems long enough for lwm2m_send_message() to call coap_pending_message() to increase the reference count to protect the packet from being released.

Another issue is that, even if the packet is correctly protected. The loop device will swap the src/dst IP.
For protocol like coap which do the retransmission at the application layer.
The packet it reserved is actually modified after the first attempt.

It seems that the packet sent to loopback device will be unreferenced immediately when the packet.

There's a missing word apparently.

For protocol like coap which do the retransmission at the application layer.

Ditto.

It's not cleat what's the problem is being reported here? Do you report that if you randomly try to use loopback (which loopback exactly?) that COAP fails randomly? Or do you use loopback on purpose? Which? What are your expectations?
(Asking as the author of https://github.com/zephyrproject-rtos/zephyr/pull/4461 , though I'm not even sure you use that loopback).

Let me clarify.
LwM2M server can send a URL to LwM2M client to ask it to perform a firmware pull.
I accidentally enter an URL "coap://127.0.0.1:7783/large" to the client.
Client then tries to send an UDP packet to 127.0.0.1, port 7783 which will be looped back to the client and the connection manager will drop the packet immediately for no one is listening to the port 7783 at client (NOTE: at this point, the packet reference is decreased to 0).
Later on, the LwM2M client realized that it did not receive any confirmation packet at CoAP layer. It will try to retransmit the packet again. But of course, the packet is already been released and the data are corrupted.

I think the issues is that LwM2M should protect the packet from being released by the lower layers.
And I'm expecting the packet stays the same even if it sends through the loopback device.

I accidentally enter an URL "coap://127.0.0.1:7783/large" to the client.

That explains it, so you by a chance tried that and saw it break "spectacularly".
I don't think the problem is LwM2M related though, or should be handled on LwM2M level. It likely affects other UDP (or maybe not just UDP based) services.
Besides the patch linked above, you may also look at https://github.com/zephyrproject-rtos/zephyr/pull/4956 as another patch touched those matters.
And if you'd like to "address" it somehow quick, you might try to disable loopback handling and see how it behaves then.

The CONFIG_NET_LOOPBACK is unset at my case.

authors: pfalcon rbtchc


text:
Build options broken with sysbuild

After investigating https://github.com/zephyrproject-rtos/zephyr/issues/79057, we have discovered that build options, both with west and ninja, are broken with sysbuild.
So, this works:
west build -b nrf54h20dk/nrf54h20/cpuapp --build-opt=-j1 samples/hello_world (built by a single core)
but this is broken:
west build -b nrf54h20dk/nrf54h20/cpuapp --build-opt=-j1 --sysbuild samples/hello_world (ignores the-j1, uses all cores)
The only way to limit the cores with sysbuild is:
CMAKE_BUILD_PARALLEL_LEVEL=1 west build -b nrf54h20dk/nrf54h20/cpuapp --sysbuild samples/hello_world

Please use our bug template when reporting bugs. You need to edit this issue to include the information requested in https://github.com/zephyrproject-rtos/zephyr/blob/main/.github/ISSUE_TEMPLATE/001_bug_report.md

--build-opt=-j1 (ignores the-j1, uses all cores)

What happens when you invoke ninja -C build/ -j1 directly?

west build -b nrf54h20dk/nrf54h20/cpuapp --build-opt=-j1 --sysbuild samples/hello_world

Still uses all the cores.

Please use our bug template when reporting bugs. You need to edit this issue to include the information requested in https://github.com/zephyrproject-rtos/zephyr/blob/main/.github/ISSUE_TEMPLATE/001_bug_report.md

Fixed, sorry!

authors: carlescufi henrikbrixandersen marc-hb


text:
Resolve inconsistent cell name for IRQ type in device trees

Introduction
Let's consolidate over a single name to describe the IRQ type in interrupt controller bindings.
Problem description
There are currently 7 interrupt controller bindings using "sense" as cell name to describe the IRQ type and 6 using "flags". Drivers that shall be used with different controllers may be forced to look after both cell names - or fail to do that, see e.g.
https://github.com/zephyrproject-rtos/zephyr/blob/c710f8892beef3e486dded2f0ad4394e4a4d9aa0/drivers/serial/uart_ns16550.c#L1791
This is a source of subtle problems.
Proposed change
I have no strong preference about a unified name. We can either pick one of the two or maybe even rename them all to type so that using IRQ_TYPE_* constants for it feels more natural. I'm happy to write a PR for any of such renamings.
Future bindings should then be forced to use the new name for the flags/sense/type cell.
Dependencies
None.
Concerns and Unresolved Questions
See above: decision about the name is needed.
Alternatives
Applying lots of changes like this:
diff --git a/drivers/serial/uart_ns16550.c b/drivers/serial/uart_ns16550.c
index a46dc34aad7..8e1b39e436e 100644
--- a/drivers/serial/uart_ns16550.c
+++ b/drivers/serial/uart_ns16550.c
@@ -1787,9 +1787,12 @@ static const struct uart_driver_api uart_ns16550_driver_api = {
 };

 #define UART_NS16550_IRQ_FLAGS(n) \
-	COND_CODE_1(DT_INST_IRQ_HAS_CELL(n, sense),                           \
-		    (DT_INST_IRQ(n, sense)),                                  \
-		    (0))
+	(COND_CODE_1(DT_INST_IRQ_HAS_CELL(n, flags),                          \
+		     (DT_INST_IRQ(n, flags)),                                 \
+		     (0)) |                                                   \
+	 COND_CODE_1(DT_INST_IRQ_HAS_CELL(n, sense),                          \
+		     (DT_INST_IRQ(n, sense)),                                 \
+		     (0)))

 /* IO-port or MMIO based UART */
 #define UART_NS16550_IRQ_CONFIG(n)                                            \

One could also provide some common macro for that, of course, but all that would look strange.

@glneo


text:
[Coverity CID :186583] Error handling issues in /samples/net/sockets/dumb_http_server/src/socket_dumb_http.c

Static code scan issues seen in File: /samples/net/sockets/dumb_http_server/src/socket_dumb_http.c
Category: Error handling issues
Function: main
Component: Samples
CID: 186583
Please fix or provide comments to square it off in coverity in the link: https://scan9.coverity.com/reports.htm#v32951/p12996

Working on addressing this issue!


text:
NET/WIFI shell improvement

Add support for tcp receive to net shell
Remove SSID length arg from wifi shell

Thanks for splitting
Commit "net: shell: net: Add tcp receive command":

This command waits for TCP data and prints number of bytes received.
Useful for testing purpose.

Can we expand the description to say: "This command waits for TCP data on connection previously established with "tcp connect" and prints number of bytes received. Useful for testing purpose."
Because my initial motion was: "What, we support listening server sockets in the shell?"
Oh and btw, is it really the case that only number of bytes printed? Seems not much useful to me, what about printing the actual data?

Codecov Report

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

@@           Coverage Diff           @@
##           master   #11660   +/-   ##
=======================================
  Coverage   48.23%   48.23%
=======================================
  Files         279      279
  Lines       43291    43291
  Branches    10359    10359
=======================================
  Hits        20881    20881
  Misses      18270    18270
  Partials     4140     4140

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 80a8cfc...84900ee. Read the comment docs.

@tbursztyka:

However, all offloaded wifi API takes a string so I won't block this PR.

Thanks for comment, I assume you implemented that shell command originally, so there's no need to got blame and ask somebody else ;-).
Of related question however - @jarz-nordic, does shell support quoted strings, like "my cute AP name"?

Please do not use shell_fprintf outside of command context.

Oh, how life could be simpler if we used printk inside command context either, like before ;-).
P.S. Still yet need to see if it'll be possible to revamp MicroPython Zephyr port redirection to shell commands, where they're called from MicroPython's command context. Just afraid to start digging into it ;-).

@pfalcon

does shell support quoted strings, like "my cute AP name"?

Yes it does, try shell example: demo params "\"test moj\""

You can use printk inside command context but it has consequences:

Your message will not be printed during command execution.
Order of printed text may be surprising... :)

@pfalcon
I am glad about that :)
btw.
I am currently working on a major rework of help print functionality, it will save plenty of flash and it will take out responsibility from the user to remember about implementing help handler inside a command handler.

I'd say that's adequate compromise. But if we really want to perfectalize it for such a case, may make "ssid len" param optional. I.e. a single number is a channel, 2 numbers - ssid len and channel.

Seems like a good idea to me.
@loicpoulain would you mind changing your patch to implement it that way?

@tbursztyka, yes I can make this optional.

@jukkar : If callback is called when when user is typing a command then it will mess displayed text.

If callback is called when when user is typing a new command then it will mess displayed text.

Isn't the same case with printk() which would either mess the displayed text or print the output in totally different place like console instead of currently active shell?

@jukkar : When printk is connected to the logger its print message will be synchronized by shell.

@loicpoulain could you rebase against latest master and re-submit?

authors: codecov-io jarz-nordic jukkar loicpoulain pfalcon tbursztyka


text:
samples: bluetooth: central_hr: Tracking vendor specific UUID128

Add support for discovery of vendor specific UUID128 and reading
the data associated with that service. If permissions require
authentication / encryption then raise the security level of the
connection.
The Central_HR can now work together with the Peripheral sample
which exposes both standard services (HRS) and a vendor specific
created with UUID128. If the peripheral sample is compiled with
a fixed passkey option, the scanning and connection between these
devices happen automatically.
Signed-off-by: Cristi Caciuloiu cristian.caciuloiu@nxp.com

I don’t have a problem with that but I just want to make sure that it is the right decision. The central sample is simpler than the Central HR. So simpler than “hello world”.
Maybe a new sample? If so, name it central_vnd?
From: Joakim Andersson notifications@github.com
Sent: luni, 10 februarie 2020 17:33
To: zephyrproject-rtos/zephyr zephyr@noreply.github.com
Cc: Cristi Caciuloiu cristian.caciuloiu@nxp.com; Author author@noreply.github.com
Subject: [EXT] Re: [zephyrproject-rtos/zephyr] samples: bluetooth: central_hr: Tracking vendor specific UUID128 (#22599)
Caution: EXT Email
@joerchan requested changes on this pull request.
Please move to the central sample instead, and remove the cmake passed configuration define.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F22599%3Femail_source%3Dnotifications%26email_token%3DAM7AGPYIZ2TRLJIEMGP4DHLRCFXRJA5CNFSM4KRPBKAKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCU4J4SA%23pullrequestreview-356032072&data=02|01|cristian.caciuloiu%40nxp.com|1d72b3f7d4f34ab5effe08d7ae3e756c|686ea1d3bc2b4c6fa92cd99c5c301635|0|0|637169455587652449&sdata=nXr7UXAsLYQTCCJkH3u%2FkE94KaTl4FN1iRn7ZU7V74s%3D&reserved=0, or unsubscribehttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAM7AGPZEKA5KWNBNCETCWSLRCFXRJANCNFSM4KRPBKAA&data=02|01|cristian.caciuloiu%40nxp.com|1d72b3f7d4f34ab5effe08d7ae3e756c|686ea1d3bc2b4c6fa92cd99c5c301635|0|0|637169455587652449&sdata=2QqQ4IJQe7YZ2uPy%2FwUy7OlSkcVxG86pA4cHes422DM%3D&reserved=0.

I don’t have a problem with that but I just want to make sure that it is the right decision. The central sample is simpler than the Central HR. So simpler than “hello world”. Maybe a new sample? If so, name it central_vnd?

I think changing central sample is fine, make it match peripheral sample, if splitting to central and central_vnd then I think we should split peripheral in the same way.

@cristic-devel Will you follow up on this PR?

@cristic-devel Need to know if you plan on following up on this PR. If not, we can close it.

Hi,
The PR can be closed.
Thanks
Cristi

From: David Leach notifications@github.com
Sent: Friday, June 12, 2020 1:09 AM
To: zephyrproject-rtos/zephyr zephyr@noreply.github.com
Cc: Cristi Caciuloiu cristian.caciuloiu@nxp.com; Mention mention@noreply.github.com
Subject: [EXT] Re: [zephyrproject-rtos/zephyr] samples: bluetooth: central_hr: Tracking vendor specific UUID128 (#22599)
Caution: EXT Email
@cristic-develhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcristic-devel&data=02|01|cristian.caciuloiu%40nxp.com|784948e6c5904b6d199908d80e540c00|686ea1d3bc2b4c6fa92cd99c5c301635|0|0|637275101422239016&sdata=4RYvpNFFSrve6C21oE3GJC7e%2B5bNgqDrrnq%2BTtV6Mzo%3D&reserved=0 Need to know if you plan on following up on this PR. If not, we can close it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F22599%23issuecomment-642955973&data=02|01|cristian.caciuloiu%40nxp.com|784948e6c5904b6d199908d80e540c00|686ea1d3bc2b4c6fa92cd99c5c301635|0|0|637275101422249009&sdata=u2FSbF6Y0vsNSKCFbZxmgIkWPLCUVR9ZMsw9DD3Xwd8%3D&reserved=0, or unsubscribehttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAM7AGPYATA5ZO4UTLEMIYRDRWFIXZANCNFSM4KRPBKAA&data=02|01|cristian.caciuloiu%40nxp.com|784948e6c5904b6d199908d80e540c00|686ea1d3bc2b4c6fa92cd99c5c301635|0|0|637275101422249009&sdata=wj6ve2RxnqFfMcfgQlj6Y14ELxS%2FBLIQnQTD124jSik%3D&reserved=0.

authors: cristic-devel dleach02 joerchan


text:
tests: mem protection test check CPU scrubs registers after syscall

Add new memory protection test, that verifies CPU scrubs registers after syscall. Leaving of sensitive data in the CPU registers, can make open a door for attacks and vulnerabilities.
To verify that CPU registers are scrubbed, I created test test_after_syscall_cpu_scrubs_regs()
Test verifies upon exit of a system call back to the calling thread, the kernel scrubs CPU registers for sensitive data.
Please review and give comments, if you think that my solution is not correct. Also I didn't implement that test for ARC, because not an expert in ARC, so looking for community help who knows ARC.
ARC currently not implemented and not supported for that test.
Signed-off-by: Maksim Masalski maksim.masalski@intel.com

@andrewboie I'm looking for your comments about that PR, I need someone who is good at ASM and CPU registers to review that code suggestion.

@LeiW000 @wentongwu Please review that test when you have time.

Also I didn't implement that test for ARC, because not an expert in ARC, so looking for community help who knows ARC.
ARC currently not implemented and not supported for that test.

@maksimmasalski IMHO this test is validating architecture-specific low-level implementation of the syscall framework and therefore it could better fit under the ARCH-specific test directory. I think that the mem_protect/syscalls suite should not deal with ARCH-related assembly and, instead, it should verify the syscall stuff up to the kernel level.
There's already a syscall-related test under tests/arch/arm/arm_thread_swap, which you could use for Cortex-M register scrub, and the same thing should be more or less done for each Architecture that supports system calls (user mode). Otherwise this is not scaling well, considering that we're soon getting more ARCHes doing user mode (Risc-v, other ARM variants, etc.); we do not want to maintain all the different ASM code for all ARCHes inside a kernel test.
As an ARCH-maintainer, I would like all ARCH-related code validation with ARCH-specific assembly considerations to be under a single test directory.
This would also solve your problem of not doing the work for ARC; essentially it is the ARC-maintainer's responsibility to test the underlying assembly stuff around system calls.

@maksimmasalski IMHO this test is validating architecture-specific low-level implementation of the syscall framework and therefore it could better fit under the ARCH-specific test directory. I think that the mem_protect/syscalls suite should not deal with ARCH-related assembly and, instead, it should verify the syscall stuff up to the kernel level.
There's already a syscall-related test under tests/arch/arm/arm_thread_swap, which you could use for Cortex-M register scrub, and the same thing should be more or less done for each Architecture that supports system calls (user mode). Otherwise this is not scaling well, considering that we're soon getting more ARCHes doing user mode (Risc-v, other ARM variants, etc.); we do not want to maintain all the different ASM code for all ARCHes inside a kernel test.
As an ARCH-maintainer, I would like all ARCH-related code validation with ARCH-specific assembly considerations to be under a single test directory.
This would also solve your problem of not doing the work for ARC; essentially it is the ARC-maintainer's responsibility to test the underlying assembly stuff around system calls.

Thank you for the reply. I understand key points:

Cortex-M has tests/arch/arm/arm_thread_swap where I can put my test code
The same I can do for x86, put my test code into tests/arch/x86
If I want to add ARC test, I can ask you or ask you for your help, if I will create a draft idea of that test.

Do I have that right?

Cortex-M has tests/arch/arm/arm_thread_swap where I can put my test code

Yeap, that's right.
This makes sense, cause people reading the ARM tests understand better what r0 - r3 registers are, but I cannot say the same for generic readers of kernel tests :)

The same I can do for x86, put my test code into tests/arch/x86

Yes, if you wish to, but I won't be able to review those.

If I want to add ARC test, I can ask you or ask you for your help, if I will create a draft idea of that test.

Better to ask anyone fro Synopsys about this.

Started to move test to arch folder, and refactored it by removing unnecessary operations in the code.
Started from ARM and created new PR #27878

authors: ioannisg maksimmasalski


text:
manifest: mcuboot update for bringing upstream bugfixes

Synchronization to latest MCUboot is impossible now due the lack of compatibility with TFM module.
This PR is for bringing as much fixes as possible from the upsteram project.
MCUboot fork was updated in order to bring bugfixes from its
upstream:

introduce MCUBOOT_CPU_IDLE() for support low power single thread
(fixes single thread power consumption)
Allow not working secondary image device and boot form primary
device if image available
fixes memory alignment of the RAM buffer that is used to temporarily
store data during swap.
update devicetree py package lib files include path in assembly
serial recovery: cbor_encoder: fix str encoding macros
zephyr: Kconfig: fix board references
do not set defaults for LOG_IMMEDIATE Kconfig
boot: Do not use irq_lock() if using arm cleanup
Kconfig: fix deadlock on cryptolib selectors

Signed-off-by: Andrzej Puzdrowski andrzej.puzdrowski@nordicsemi.no
fixes https://github.com/zephyrproject-rtos/zephyr/issues/38402

How much complexity will this add when we do want to upgrade to the latest? (e.g. 1.8.0).

@d3zd3z This will be quite easy - simplest (always working) approach is to revert all cherry-picked commit and do the upmerge. Most probably I will do the synch as usually (just let me know when).


text:
gen_kobject_list.py: device driver support

Device drivers need to be treated like other kernel objects, with
thread-level permissions and validation of struct device pointers passed
in from userspace when making API calls.
However it's not sufficient to identify an object as a driver, we need
to know what subsystem it belongs to (if any) so that userspace cannot,
for example, make Ethernet driver API calls using a UART driver object.
Upon encountering a variable representing a device struct, we look at
the value of its driver_api member. If that corresponds to an instance
of a driver API struct belonging to a known subsystem, the proper
K_OBJ_DRIVER_* enumeration type will be associated with this device in
the generated gperf table.
If there is no API struct or it doesn't correspond to a known subsystem,
the device is omitted from the table; it's presumably used internally
by the kernel or is a singleton with specific APIs for it that do not
take a struct device parameter.
The list of kobjects and subsystems in the script is simplified since
the enumeration type name is strongly derived from the name of the data
structure.
A device objects is marked as initialized after its init function has
been run at boot.
Signed-off-by: Andrew Boie andrew.p.boie@intel.com

updated based on @lpereira review


text:
Agilex shell example

Add example design with "shell" command line for intel_socfpga_agilex_socdk board. We will support shell command for all supported drivers and features for our customer through this example design.

Hi @nashif , kindly help to review this Intel SoC FPGA Agilex pull request

Hi @teburd,
This will be the first initial bring up patch for Agilex board specific sample code. I will introduce Agilex board specific shell command (Agilex SDM Mailbox) in my future patch, I will upstream the Mailbox driver next week.
Thanks

Hi @nashif @carlocaione,
Can you please help to review this pull request? Thanks a lot for your help. I don't know how to invite reviewers.

Hi @teburd,
This will be the first initial bring up patch for Agilex board specific sample code. I will introduce Agilex board specific shell command (Agilex SDM Mailbox) in my future patch, I will upstream the Mailbox driver next week.
Thanks

That makes sense, ignore my commentary above then

Thanks.

why do we need this to be specific for a board when you can use existing and cross board shell samples? Dedicated and new samples need to do more than just that.

Hi Anas,
This will be the first initial bring up patch for Agilex board specific sample code. We will introduce Agilex board specific shell command (example: Agilex SDM Mailbox) in my near future patch to show case user the features specific to Agilex board.
Besides, "shell" is first sample designs as general purpose for all user to intel_socfpga_agilex_socdk. We also plan to include other board specific samples. So, we think of consolidate all samples for Agilex under Agilex board.
Thanks,
Siew Chin

Hi @nashif , is this patch acceptable to integrate into mainline?

FYI, I have also posted pull request "https://github.com/zephyrproject-rtos/zephyr/pull/43256" for Arm SIP SVC (sip_svc) driver.  Agilex SDM "mailbox" shell command will be introduced based on this sip_svc driver in future in Agilex board level shell command.

@nashif can this be integrated into main branch?

@nashif can this be integrated into main branch?

no, we do not want to have a shell example for each board we had in the tree. The sample code does really nothing and it just enables a shell module You could probably describe how to enable the shell in the board documentation or have this sample outside of Zephyr.

authors: nashif siclim


text:
LoRaWAN: Add Clock Synchronization Service

This PR adds an implementation of the Application Layer Clock Synchronization (TS003) service specified by the LoRa Alliance.
Clock synchronization is required for firmware-upgrade over the air (FUOTA). This PR splits out the first parts of the entire FUOTA PR #49284 to make review easier.
As for the rest of the LoRaWAN implementation in Zephyr, it uses some functions provided by the LoRaMac-node module developed by Semtech.
The clock synchronization process is started by the application and afterwards runs in the background in its own work queue thread.
Testing
The implementation has been successfully tested with ChirpStack and AWS IoT.
For testing with ChirpStack, the FUOTA server is needed in addition to the normal ChirpStack deployment.

Thanks a lot for your reviews @JordanYates @rerickson1 @Mani-Sadhasivam. I have addressed all your comments.

@Mani-Sadhasivam could you please have another look?

@JordanYates and @Mani-Sadhasivam. Your requested changes have been implemented. Sorry for the delay, got stuck with other work in between...

@Mani-Sadhasivam can you please have a look again? The comments you had have been addressed.


text:
Bluetooth: Mesh: avoid ll fragmentation for l2cap for mesh

Mesh sends via gatt proxy max 30 bytes frame prepared in advance. Default 27 bytes frame size always causes ll fragmentation that decreases gatt proxy performance. 37 bytes max length allows to fit mesh proxy frame in the single ll frame.
Signed-off-by: Aleksandr Khromykh aleksandr.khromykh@nordicsemi.no

@LingaoM, I answered your question. For some reason, re-request functionality on GitHub website stopped working for me :(
Please review it one more time.


text:
ITE: drivers/usb/device: Add USB Device Controller Support

Add USB Device Driver (usb_dc) of ITE IT82xx2
TEST=west build -p always -b it82xx2_evb
with the sample zephyr/sample/subsys/usb/hid
Signed-off-by: BJ Chen bj.chen@ite.com.tw

Please note, you implement a driver using the API we like to scrap ASAP.

Please note, you implement a driver using the API we like to scrap ASAP.

Can you point to the new USB device controller API? What is the timeline for switching over to the new API?

There is meta-issue for USB support, https://github.com/zephyrproject-rtos/zephyr/issues/42066

Dear sirs,
I upload again for rebasing the upstream/main with adding the following lines in boards/riscv/it82xx2_evb/it82xx2_evb.dts:

sw1-sw3 aliases:

		sw1 = &button1;
		sw2 = &button2;
		sw3 = &button3;

button1-3

		button1: button_1 {
			gpios = <&gpioc 4 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
			label = "Push button switch 1";
		};
		button2: button_2 {
			gpios = <&gpioe 3 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
			label = "Push button switch 2";
		};
		button3: button_3 {
			gpios = <&gpioe 4 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
			label = "Push button switch 3";
		};

Thanks again for your re-visiting.

Please note, you implement a driver using the API we like to scrap ASAP.

Can you point to the new USB device controller API? What is the timeline for switching over to the new API?

There is meta-issue for USB support, #42066

Truly appreciative of your notifications, sir. I believe that we'll move on to follow the USB device "next" afterwards. However, due to the requirements of some running projects, we'd still have to use the potentially deprecated old implementation temporarily for current situation.
We'll start to study related and required information about the new USB support ASAP.
Thanks again for your kindly guidance & best regards,
BJ

Please note, you implement a driver using the API we like to scrap ASAP.

Can you point to the new USB device controller API? What is the timeline for switching over to the new API?

There is meta-issue for USB support, #42066

Truly appreciative of your notifications, sir. I believe that we'll move on to follow the USB device "next" afterwards. However, due to the requirements of some running projects, we'd still have to use the potentially deprecated old implementation temporarily for current situation.
We'll start to study related and required information about the new USB support ASAP.
Thanks again for your kindly guidance & best regards,
BJ

Dear sirs,
Following #57028,  I made some modifications as follows:
`	if (ep_idx >= MAX_NUM_ENDPOINTS) {
LOG_WRN("Invalid Endpoint Number 0x%02x", cfg->ep_addr);
return -EINVAL;
}
if ((ep_idx != 0) && (!in && ep_idx % FIFO_NUM != 2)) {
	LOG_WRN("Invalid Endpoint Number 0x%02x", cfg->ep_addr);
	return -EINVAL;
}

if ((ep_idx != 0) && (in && ep_idx % FIFO_NUM == 2)) {
	LOG_WRN("Invalid Endpoint Number 0x%02x", cfg->ep_addr);
	return -EINVAL;
}

`
Please revisit if you're available.
Thanks again & Best regards,
BJ

Dear sirs,
Following https://github.com/zephyrproject-rtos/zephyr/pull/57028, I made some modifications as follows:
if (ep_idx >= MAX_NUM_ENDPOINTS) { LOG_WRN("Invalid Endpoint Number 0x%02x", cfg->ep_addr); return -EINVAL; }
`
if ((ep_idx != 0) && (!in && ep_idx % FIFO_NUM != 2)) {
LOG_WRN("Invalid Endpoint Number 0x%02x", cfg->ep_addr);
return -EINVAL;
}
if ((ep_idx != 0) && (in && ep_idx % FIFO_NUM == 2)) {
LOG_WRN("Invalid Endpoint Number 0x%02x", cfg->ep_addr);
return -EINVAL;
}
`
Please revisit if you're available.
Thanks again & Best regards,
BJ

Dear sirs,
This update is to follow the #57028, we made some modifications towards the usb_dc_ep_check_cap().
`
if (ep_idx >= MAX_NUM_ENDPOINTS) {
LOG_WRN("Invalid Endpoint Number 0x%02x", cfg->ep_addr);
return -EINVAL;
}
if ((ep_idx != 0) && (!in && ep_idx % FIFO_NUM != 2)) {
	LOG_WRN("Invalid Endpoint Number 0x%02x", cfg->ep_addr);
	return -EINVAL;
}

if ((ep_idx != 0) && (in && ep_idx % FIFO_NUM == 2)) {
	LOG_WRN("Invalid Endpoint Number 0x%02x", cfg->ep_addr);
	return -EINVAL;
}

`
Truly grateful for your revisiting.
Regards,
BJ

Dear sirs,
This update is to follow the #57028, we made some modifications towards the usb_dc_ep_check_cap() as follows:
`	if ((ep_idx != 0) && (!in && ep_idx % FIFO_NUM != 2)) {
LOG_WRN("Invalid Endpoint Number 0x%02x", cfg->ep_addr);
return -EINVAL;
}
if ((ep_idx != 0) && (in && ep_idx % FIFO_NUM == 2)) {
	LOG_WRN("Invalid Endpoint Number 0x%02x", cfg->ep_addr);
	return -EINVAL;
}`

Truly grateful for your revisiting.
Regards,
BJ

Dear sirs,
This update is to follow the #57028, we made some modifications towards two conditions in the usb_dc_ep_check_cap() as follows:
Condition 1.
((ep_idx != 0) && (!in && ep_idx % FIFO_NUM != 2))
Condition 2.
((ep_idx != 0) && (in && ep_idx % FIFO_NUM == 2))
The conditions above is about the chip-level FIFO assignment.
Truly grateful for your revisiting & Best regards,
BJ

Additional modifications in this commit to fix some potential errors:

Fix the EPN_EXT_CTRL2 ready bit definition for extended endpoints:
#define READY_BITS			0x0F

exception handling:

`
static void ep_in_out_config(uint8_t idx)
{
uint8_t ep_trans = (epn_ext_ctrl[idx].EPN_EXT_CTRL2 >> 4) & READY_BITS;
if (udata0.ep_data[ep_trans].ep_status == EP_CONFIG_IN) {
	if (ep_trans < 4) {
		if (!!(ep_regs[idx].EP_CTRL & EP_OUTDATA_SEQ)) {
			ep_regs[idx].EP_CTRL &= ~EP_OUTDATA_SEQ;
		} else {
			ep_regs[idx].EP_CTRL |= EP_OUTDATA_SEQ;
		}
	} else {
		usb_extend_ep_ctrl(ep_trans, EXT_EP_DATA_SEQ_INV);
	}

	if (udata0.ep_data[ep_trans].cb_in) {
		udata0.ep_data[ep_trans].cb_in(ep_trans | 0x80,
			USB_DC_EP_DATA_IN);
	}

} else {
	if (udata0.ep_data[ep_trans].cb_out) {
		udata0.ep_data[ep_trans].cb_out(ep_trans,
			USB_DC_EP_DATA_OUT);
	}
}

}
`
Add the condition if (udata0.ep_data[ep_trans].cb_in) { & if (udata0.ep_data[ep_trans].cb_out) {  to avoid exceptions.
Thanks again for your great patience and revisiting.

Dear sirs,
This upload is also modified for resolving the ep_status being set wrong in usb_dc_ep_configure() as follows:
`
if (ep_idx < EP4) {
(in) ? (ep_regs[ep_idx].EP_CTRL |= EP_DIRECTION | EP_OUTDATA_SEQ) :
(ep_regs[ep_idx].EP_CTRL &= ~EP_DIRECTION);
} else {

	(in) ? (usb_extend_ep_ctrl(ep_idx, EXT_EP_DIR_IN)) :
		(usb_extend_ep_ctrl(ep_idx, EXT_EP_DIR_OUT));

	if (in) {
		usb_extend_ep_ctrl(ep_idx, EXT_EP_DATA_SEQ_1);
	}

	LOG_DBG("ep_status %d", udata0.ep_data[ep_idx].ep_status);
}

(in) ? (udata0.ep_data[ep_idx].ep_status = EP_CONFIG_IN) :
	(udata0.ep_data[ep_idx].ep_status = EP_CONFIG_OUT);

ep_fifo_ctrl[reg_idx] |= reg_val;

`
Thanks again for your revisiting.

Dear sirs,
This upload is also modified for resolving the ep_status being set wrong in usb_dc_ep_configure() as follows:
if (ep_idx < EP4) {
(in) ? (ep_regs[ep_idx].EP_CTRL |= EP_DIRECTION | EP_OUTDATA_SEQ) :
(ep_regs[ep_idx].EP_CTRL &= ~EP_DIRECTION);
} else {
(in) ? (usb_extend_ep_ctrl(ep_idx, EXT_EP_DIR_IN)) :
(usb_extend_ep_ctrl(ep_idx, EXT_EP_DIR_OUT));
if (in) {
	usb_extend_ep_ctrl(ep_idx, EXT_EP_DATA_SEQ_1);
}
LOG_DBG("ep_status %d", udata0.ep_data[ep_idx].ep_status);

}
(in) ? (udata0.ep_data[ep_idx].ep_status = EP_CONFIG_IN) :
(udata0.ep_data[ep_idx].ep_status = EP_CONFIG_OUT);
ep_fifo_ctrl[reg_idx] |= reg_val;
Thanks again for your revisiting.

Dear sirs,
Thanks again for your revisiting & time sharing.
This update is about fixing the ep_status being set wrongly in the usb_dc_ep_configure() as the following figure:
	if (ep_idx < EP4) {
		(in) ? (ep_regs[ep_idx].EP_CTRL |= EP_DIRECTION | EP_OUTDATA_SEQ) :
			(ep_regs[ep_idx].EP_CTRL &= ~EP_DIRECTION);

	} else {

		(in) ? (usb_extend_ep_ctrl(ep_idx, EXT_EP_DIR_IN)) :
			(usb_extend_ep_ctrl(ep_idx, EXT_EP_DIR_OUT));

		if (in) {
			usb_extend_ep_ctrl(ep_idx, EXT_EP_DATA_SEQ_1);
		}

		LOG_DBG("ep_status %d", udata0.ep_data[ep_idx].ep_status);
	}

	(in) ? (udata0.ep_data[ep_idx].ep_status = EP_CONFIG_IN) :
		(udata0.ep_data[ep_idx].ep_status = EP_CONFIG_OUT);

	ep_fifo_ctrl[reg_idx] |= reg_val;

Dear sirs,
The latest update add the zephyr_udc0 back and also usb_device in the boards/riscv/it82xx2_evb/it82xx2_evb.yaml.
Thanks again for your revisiting.

Dear sirs,
In the latest update, we add the zephyr_udc0 back and we also add usb_device in the boards/riscv/it82xx2_evb/it82xx2_evb.yaml.
Thanks again for your revisiting.

@itebj please rebase to fix conflicts

@itebj please rebase to fix conflicts

Dear sirs,
I just couldn't upload anymore when I try to git push, the error messages was shown as follows:
>>>  git push zephyr-fork z-usb -f
Username for 'https://github.com': bj.chen@ite.com.tw
Password for 'https://bj.chen@ite.com.tw@github.com':
Enumerating objects: 59317, done.
Counting objects: 100% (59314/59314), done.
Delta compression using up to 4 threads
Compressing objects: 100% (21709/21709), done.
Writing objects: 100% (52717/52717), 16.30 MiB | 18.38 MiB/s, done.
Total 52717 (delta 39103), reused 41279 (delta 29057), pack-reused 0
error: RPC failed; HTTP 408 curl 22 The requested URL returned error: 408
send-pack: unexpected disconnect while reading sideband packet
fatal: the remote end hung up unexpectedly
Everything up-to-date

I am not pretty sure what just happened but maybe it's about my clicking the "Resolving Conflicts" button.

Dear sirs,
Well, it seems that the git pushing work again, thanks again for your revisiting.
Best regards,
BJ

authors: carlescufi itebj jfischer-no


text:
DNM: cmake: compiler: add double promotion warning

Too many times, code is pushed that includes floats that really becomes doubles and C implicit promotion rules will want to make floats into doubles very easily. As zephyr primarily targets low-end process that may not have a double precision floating point unit, enable this flag globally for now.
DEPENDS ON

[x] https://github.com/zephyrproject-rtos/zephyr/pull/38651
[x] https://github.com/zephyrproject-rtos/zephyr/pull/40448
[x] https://github.com/picolibc/picolibc/pull/364
[x] ~~https://github.com/zephyrproject-rtos/zephyr/pull/56955~~
[x] https://github.com/zephyrproject-rtos/zephyr/pull/58479
[x] https://github.com/zephyrproject-rtos/zephyr/pull/57265
[x] https://github.com/zephyrproject-rtos/zephyr/pull/57266
[x] https://github.com/zephyrproject-rtos/zephyr/pull/56957
[x] https://github.com/zephyrproject-rtos/zephyr/pull/57303
[x] https://github.com/zephyrproject-rtos/zephyr/pull/57304
[x] https://github.com/zephyrproject-rtos/hal_st/pull/15
[x] https://github.com/NordicSemiconductor/zcbor/pull/326
[x] https://github.com/WurthElektronik/Sensors-SDK_STM32/pull/3
[x] https://github.com/zephyrproject-rtos/zephyr/pull/60378
[x] https://github.com/zephyrproject-rtos/hal_espressif/pull/224
[x] https://github.com/zephyrproject-rtos/zephyr/pull/60403
[x] https://github.com/zephyrproject-rtos/zephyr/pull/60593
[x] https://github.com/zephyrproject-rtos/zephyr/pull/60594
[x] https://github.com/zephyrproject-rtos/zephyr/pull/60595
[x] https://github.com/zephyrproject-rtos/zephyr/pull/60596
[x] https://github.com/zephyrproject-rtos/zephyr/pull/60598
[x] https://github.com/zephyrproject-rtos/hal_openisa/pull/8
[x] https://github.com/zephyrproject-rtos/zephyr/pull/60602
[x] https://github.com/zephyrproject-rtos/zephyr/pull/60605
[x] https://github.com/zephyrproject-rtos/zephyr/pull/61771
[x] https://github.com/zephyrproject-rtos/zephyr/pull/61772
[x] https://github.com/zephyrproject-rtos/zephyr/pull/61807
and likely others to come as the CI finds it all

Yes, we definitely want this warning enabled by default. Building picolibc with -Werror=double-promotion yielded dozens of fixes and made the resulting library free of double operations when using only float values.
However, fixes to make this work should probably land in separate PR/PRs, but having them appear here first so that we can let CI check to make sure they're sufficient seems like a good plan. Should we mark this as DNM until then?
Once the patches that fix the promotion bugs have landed, I'd be happy to approve this.

Agreed, it should be marked as DNM until all the little double promotion bugs are squashed in seperate PRs.
My only worry is with modules that have double-promotion issues, that's what stopped me the last time I try to integrated this flag by default to in zephyr

My only worry is with modules that have double-promotion issues, that's what stopped me the last time I try to integrated this flag by default to in zephyr, but some may of been fixed since then.... #38958

Yeah, it's tedious but there is a pretty reasonable process. Post a PR to the module repo, then post a PR to the zephyr repo that pulls the module branch. It's documented somewhere even ...

It appears CMSIS-DSP is getting dinged as well, but these were fixed in https://github.com/ARM-software/CMSIS-DSP/commit/5fac45cc967f2f6b8592856a32ce04fae2245143
Those should be resolved in the cmsis-dsp, cmsis-nn, tflite-micro update https://github.com/zephyrproject-rtos/zephyr/pull/56957

There two more modules, one is an ST audio library and another the hal_wurthelektronik.
both of these appear to be tied to upstream repos
FAILED: modules/st/CMakeFiles/..__modules__hal__st.dir/audio/microphone/OpenPDMFilter.c.obj
ccache /opt/toolchains/zephyr-sdk-0.16.0/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc -DCORE_CM4 -DHSE_VALUE=16000000 -DKERNEL -DSTM32F412Cx -DUSE_FULL_LL_DRIVER -DUSE_HAL_DRIVER -D__PROGRAM_START -D__ZEPHYR__=1 -I/__w/zephyr/zephyr/include -I/__w/zephyr/zephyr/twister-out/96b_argonkey/samples/boards/96b_argonkey/microphone/sample.board.96b_argonkey.microphone/zephyr/include/generated -I/__w/zephyr/zephyr/soc/arm/st_stm32/stm32f4 -I/__w/zephyr/zephyr/drivers -I/__w/zephyr/zephyr/soc/arm/st_stm32/common -I/__w/zephyr/modules/hal/cmsis/CMSIS/Core/Include -I/__w/zephyr/modules/hal/st/audio/microphone -I/__w/zephyr/modules/hal/stm32/stm32cube/stm32f4xx/soc -I/__w/zephyr/modules/hal/stm32/stm32cube/stm32f4xx/drivers/include -I/__w/zephyr/modules/hal/stm32/stm32cube/stm32f4xx/drivers/include/Legacy -I/__w/zephyr/modules/hal/stm32/stm32cube/common_ll/include -isystem /__w/zephyr/zephyr/lib/libc/minimal/include -isystem /opt/toolchains/zephyr-sdk-0.16.0/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/include -isystem /opt/toolchains/zephyr-sdk-0.16.0/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/include-fixed -fno-strict-aliasing -Werror -Os -imacros /__w/zephyr/zephyr/twister-out/96b_argonkey/samples/boards/96b_argonkey/microphone/sample.board.96b_argonkey.microphone/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -gdwarf-4 -fdiagnostics-color=always -mcpu=cortex-m4 -mthumb -mabi=aapcs --sysroot=/opt/toolchains/zephyr-sdk-0.16.0/arm-zephyr-eabi/arm-zephyr-eabi -imacros /__w/zephyr/zephyr/include/zephyr/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wdouble-promotion -Wno-pointer-sign -Wpointer-arith -Wexpansion-to-defined -Wno-unused-but-set-variable -Werror=implicit-int -fno-pic -fno-pie -fno-asynchronous-unwind-tables -fno-reorder-functions --param=min-pagesize=0 -fno-defer-pop -fmacro-prefix-map=/__w/zephyr/zephyr/samples/boards/96b_argonkey/microphone=CMAKE_SOURCE_DIR -fmacro-prefix-map=/__w/zephyr/zephyr=ZEPHYR_BASE -fmacro-prefix-map=/__w/zephyr=WEST_TOPDIR -ffunction-sections -fdata-sections -std=c99 -nostdinc -MD -MT modules/st/CMakeFiles/..__modules__hal__st.dir/audio/microphone/OpenPDMFilter.c.obj -MF modules/st/CMakeFiles/..__modules__hal__st.dir/audio/microphone/OpenPDMFilter.c.obj.d -o modules/st/CMakeFiles/..__modules__hal__st.dir/audio/microphone/OpenPDMFilter.c.obj -c /__w/zephyr/modules/hal/st/audio/microphone/OpenPDMFilter.c
/__w/zephyr/modules/hal/st/audio/microphone/OpenPDMFilter.c: In function 'Open_PDM_Filter_Init':
/__w/zephyr/modules/hal/st/audio/microphone/OpenPDMFilter.c:180:88: error: implicit conversion from 'float' to 'double' to match other operand of binary expression [-Werror=double-promotion]
  180 |   Param->LP_ALFA = (Param->LP_HZ != 0 ? (uint16_t) (Param->LP_HZ * 256 / (Param->LP_HZ + Param->Fs / (2 * 3.14159))) : 0);
      |                                                                                ^
/__w/zephyr/modules/hal/st/audio/microphone/OpenPDMFilter.c:180:72: error: implicit conversion from 'float' to 'double' to match other operand of binary expression [-Werror=double-promotion]
  180 |   Param->LP_ALFA = (Param->LP_HZ != 0 ? (uint16_t) (Param->LP_HZ * 256 / (Param->LP_HZ + Param->Fs / (2 * 3.14159))) : 0);
      |                                                                        ^
/__w/zephyr/modules/hal/st/audio/microphone/OpenPDMFilter.c:181:84: error: implicit conversion from 'float' to 'double' to match other operand of binary expression [-Werror=double-promotion]
  181 |   Param->HP_ALFA = (Param->HP_HZ != 0 ? (uint16_t) (Param->Fs * 256 / (2 * 3.14159 * Param->HP_HZ + Param->Fs)) : 0);
      |                                                                                ^
cc1: all warnings being treated as errors

[38/463] Building C object zephyr/CMakeFiles/zephyr.dir/__w/zephyr/modules/hal/wurthelektronik/sensors/WeSensorsSDK/WSEN_PDUS_25131308XXX01/WSEN_PDUS_25131308XXX01.c.obj
FAILED: zephyr/CMakeFiles/zephyr.dir/__w/zephyr/modules/hal/wurthelektronik/sensors/WeSensorsSDK/WSEN_PDUS_25131308XXX01/WSEN_PDUS_25131308XXX01.c.obj
ccache /usr/lib/llvm-16/bin/clang -DKERNEL -D_POSIX_C_SOURCE=200809 -D_XOPEN_SOURCE=600 -D_XOPEN_SOURCE_EXTENDED -D__ZEPHYR__=1 -I/__w/zephyr/zephyr/kernel/include -I/__w/zephyr/zephyr/arch/posix/include -I/__w/zephyr/zephyr/include -I/__w/zephyr/zephyr/twister-out/native_posix/tests/drivers/build_all/sensor/sensors.build.trigger.own/zephyr/include/generated -I/__w/zephyr/zephyr/soc/posix/inf_clock -I/__w/zephyr/zephyr/boards/posix/native_posix -I/__w/zephyr/zephyr/subsys/testsuite/include -I/__w/zephyr/modules/hal/st/sensor/vl53l0x/api/core/inc -I/__w/zephyr/zephyr/drivers/sensor/vl53l0x -I/__w/zephyr/modules/hal/st/sensor/vl53l1x/api/core/inc -I/__w/zephyr/zephyr/drivers/sensor/vl53l1x -I/__w/zephyr/modules/hal/st/sensor/stmemsc/hts221_STdC/driver -I/__w/zephyr/modules/hal/st/sensor/stmemsc/i3g4250d_STdC/driver -I/__w/zephyr/modules/hal/st/sensor/stmemsc/iis2dh_STdC/driver -I/__w/zephyr/modules/hal/st/sensor/stmemsc/iis2dlpc_STdC/driver -I/__w/zephyr/modules/hal/st/sensor/stmemsc/iis2iclx_STdC/driver -I/__w/zephyr/modules/hal/st/sensor/stmemsc/iis2mdc_STdC/driver -I/__w/zephyr/modules/hal/st/sensor/stmemsc/iis3dhhc_STdC/driver -I/__w/zephyr/modules/hal/st/sensor/stmemsc/ism330dhcx_STdC/driver -I/__w/zephyr/modules/hal/st/sensor/stmemsc/lis2ds12_STdC/driver -I/__w/zephyr/modules/hal/st/sensor/stmemsc/lis2dw12_STdC/driver -I/__w/zephyr/modules/hal/st/sensor/stmemsc/lis2mdl_STdC/driver -I/__w/zephyr/modules/hal/st/sensor/stmemsc/lps22hh_STdC/driver -I/__w/zephyr/modules/hal/st/sensor/stmemsc/lsm6dso_STdC/driver -I/__w/zephyr/modules/hal/st/sensor/stmemsc/stts751_STdC/driver -I/__w/zephyr/modules/hal/wurthelektronik/sensors/. -I/__w/zephyr/modules/hal/wurthelektronik/sensors/WeSensorsSDK -I/__w/zephyr/modules/hal/wurthelektronik/sensors/WeSensorsSDK/WSEN_HIDS_2523020210001 -I/__w/zephyr/modules/hal/wurthelektronik/sensors/WeSensorsSDK/WSEN_PADS_2511020213301 -I/__w/zephyr/modules/hal/wurthelektronik/sensors/WeSensorsSDK/WSEN_PDUS_25131308XXX01 -I/__w/zephyr/modules/hal/wurthelektronik/sensors/WeSensorsSDK/WSEN_TIDS_2521020222501 -fno-strict-aliasing -Werror -Os -imacros /__w/zephyr/zephyr/twister-out/native_posix/tests/drivers/build_all/sensor/sensors.build.trigger.own/zephyr/include/generated/autoconf.h -fno-common -g -gdwarf-4 -fcolor-diagnostics --config /__w/zephyr/zephyr/cmake/toolchain/llvm/clang.cfg -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-unused-but-set-variable -Wno-typedef-redefinition -Wno-deprecated-non-prototype -Wdouble-promotion -Wno-pointer-sign -Wpointer-arith -Wno-sometimes-uninitialized -Wno-shift-overflow -Wno-missing-braces -Wno-self-assign -Wno-address-of-packed-member -Wno-unused-function -Wno-initializer-overrides -Wno-section -Wno-unknown-warning-option -Wno-unused-variable -Wno-format-invalid-specifier -Wno-gnu -Wno-tautological-compare -Werror=implicit-int -fno-pic -fno-pie -fno-asynchronous-unwind-tables -Wno-vla -fmacro-prefix-map=/__w/zephyr/zephyr/tests/drivers/build_all/sensor=CMAKE_SOURCE_DIR -fmacro-prefix-map=/__w/zephyr/zephyr=ZEPHYR_BASE -fmacro-prefix-map=/__w/zephyr=WEST_TOPDIR -ffunction-sections -fdata-sections -m32 -include /__w/zephyr/zephyr/arch/posix/include/posix_cheats.h -std=c11 -MD -MT zephyr/CMakeFiles/zephyr.dir/__w/zephyr/modules/hal/wurthelektronik/sensors/WeSensorsSDK/WSEN_PDUS_25131308XXX01/WSEN_PDUS_25131308XXX01.c.obj -MF zephyr/CMakeFiles/zephyr.dir/__w/zephyr/modules/hal/wurthelektronik/sensors/WeSensorsSDK/WSEN_PDUS_25131308XXX01/WSEN_PDUS_25131308XXX01.c.obj.d -o zephyr/CMakeFiles/zephyr.dir/__w/zephyr/modules/hal/wurthelektronik/sensors/WeSensorsSDK/WSEN_PDUS_25131308XXX01/WSEN_PDUS_25131308XXX01.c.obj -c /__w/zephyr/modules/hal/wurthelektronik/sensors/WeSensorsSDK/WSEN_PDUS_25131308XXX01/WSEN_PDUS_25131308XXX01.c
/__w/zephyr/modules/hal/wurthelektronik/sensors/WeSensorsSDK/WSEN_PDUS_25131308XXX01/WSEN_PDUS_25131308XXX01.c:180:17: error: implicit conversion increases floating-point precision: 'float' to 'double' [-Werror,-Wdouble-promotion]
  *tempDegC = (((float) (rawTemp - T_MIN_VAL_PDUS) * 4.272) / 1000);
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~
1 error generated.
[39/463] Building C object zephyr/CMakeFiles/zephyr.dir/__w/zephyr/modules/hal/wurthelektronik/sensors/WeSensorsSDK/WSEN_PADS_2511020213301/WSEN_PADS_2511020213301.c.obj
FAILED: zephyr/CMakeFiles/zephyr.dir/__w/zephyr/modules/hal/wurthelektronik/sensors/WeSensorsSDK/WSEN_PADS_2511020213301/WSEN_PADS_2511020213301.c.obj
ccache /usr/lib/llvm-16/bin/clang -DKERNEL -D_POSIX_C_SOURCE=200809 -D_XOPEN_SOURCE=600 -D_XOPEN_SOURCE_EXTENDED -D__ZEPHYR__=1 -I/__w/zephyr/zephyr/kernel/include -I/__w/zephyr/zephyr/arch/posix/include -I/__w/zephyr/zephyr/include -I/__w/zephyr/zephyr/twister-out/native_posix/tests/drivers/build_all/sensor/sensors.build.trigger.own/zephyr/include/generated -I/__w/zephyr/zephyr/soc/posix/inf_clock -I/__w/zephyr/zephyr/boards/posix/native_posix -I/__w/zephyr/zephyr/subsys/testsuite/include -I/__w/zephyr/modules/hal/st/sensor/vl53l0x/api/core/inc -I/__w/zephyr/zephyr/drivers/sensor/vl53l0x -I/__w/zephyr/modules/hal/st/sensor/vl53l1x/api/core/inc -I/__w/zephyr/zephyr/drivers/sensor/vl53l1x -I/__w/zephyr/modules/hal/st/sensor/stmemsc/hts221_STdC/driver -I/__w/zephyr/modules/hal/st/sensor/stmemsc/i3g4250d_STdC/driver -I/__w/zephyr/modules/hal/st/sensor/stmemsc/iis2dh_STdC/driver -I/__w/zephyr/modules/hal/st/sensor/stmemsc/iis2dlpc_STdC/driver -I/__w/zephyr/modules/hal/st/sensor/stmemsc/iis2iclx_STdC/driver -I/__w/zephyr/modules/hal/st/sensor/stmemsc/iis2mdc_STdC/driver -I/__w/zephyr/modules/hal/st/sensor/stmemsc/iis3dhhc_STdC/driver -I/__w/zephyr/modules/hal/st/sensor/stmemsc/ism330dhcx_STdC/driver -I/__w/zephyr/modules/hal/st/sensor/stmemsc/lis2ds12_STdC/driver -I/__w/zephyr/modules/hal/st/sensor/stmemsc/lis2dw12_STdC/driver -I/__w/zephyr/modules/hal/st/sensor/stmemsc/lis2mdl_STdC/driver -I/__w/zephyr/modules/hal/st/sensor/stmemsc/lps22hh_STdC/driver -I/__w/zephyr/modules/hal/st/sensor/stmemsc/lsm6dso_STdC/driver -I/__w/zephyr/modules/hal/st/sensor/stmemsc/stts751_STdC/driver -I/__w/zephyr/modules/hal/wurthelektronik/sensors/. -I/__w/zephyr/modules/hal/wurthelektronik/sensors/WeSensorsSDK -I/__w/zephyr/modules/hal/wurthelektronik/sensors/WeSensorsSDK/WSEN_HIDS_2523020210001 -I/__w/zephyr/modules/hal/wurthelektronik/sensors/WeSensorsSDK/WSEN_PADS_2511020213301 -I/__w/zephyr/modules/hal/wurthelektronik/sensors/WeSensorsSDK/WSEN_PDUS_25131308XXX01 -I/__w/zephyr/modules/hal/wurthelektronik/sensors/WeSensorsSDK/WSEN_TIDS_2521020222501 -fno-strict-aliasing -Werror -Os -imacros /__w/zephyr/zephyr/twister-out/native_posix/tests/drivers/build_all/sensor/sensors.build.trigger.own/zephyr/include/generated/autoconf.h -fno-common -g -gdwarf-4 -fcolor-diagnostics --config /__w/zephyr/zephyr/cmake/toolchain/llvm/clang.cfg -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-unused-but-set-variable -Wno-typedef-redefinition -Wno-deprecated-non-prototype -Wdouble-promotion -Wno-pointer-sign -Wpointer-arith -Wno-sometimes-uninitialized -Wno-shift-overflow -Wno-missing-braces -Wno-self-assign -Wno-address-of-packed-member -Wno-unused-function -Wno-initializer-overrides -Wno-section -Wno-unknown-warning-option -Wno-unused-variable -Wno-format-invalid-specifier -Wno-gnu -Wno-tautological-compare -Werror=implicit-int -fno-pic -fno-pie -fno-asynchronous-unwind-tables -Wno-vla -fmacro-prefix-map=/__w/zephyr/zephyr/tests/drivers/build_all/sensor=CMAKE_SOURCE_DIR -fmacro-prefix-map=/__w/zephyr/zephyr=ZEPHYR_BASE -fmacro-prefix-map=/__w/zephyr=WEST_TOPDIR -ffunction-sections -fdata-sections -m32 -include /__w/zephyr/zephyr/arch/posix/include/posix_cheats.h -std=c11 -MD -MT zephyr/CMakeFiles/zephyr.dir/__w/zephyr/modules/hal/wurthelektronik/sensors/WeSensorsSDK/WSEN_PADS_2511020213301/WSEN_PADS_2511020213301.c.obj -MF zephyr/CMakeFiles/zephyr.dir/__w/zephyr/modules/hal/wurthelektronik/sensors/WeSensorsSDK/WSEN_PADS_2511020213301/WSEN_PADS_2511020213301.c.obj.d -o zephyr/CMakeFiles/zephyr.dir/__w/zephyr/modules/hal/wurthelektronik/sensors/WeSensorsSDK/WSEN_PADS_2511020213301/WSEN_PADS_2511020213301.c.obj -c /__w/zephyr/modules/hal/wurthelektronik/sensors/WeSensorsSDK/WSEN_PADS_2511020213301/WSEN_PADS_2511020213301.c
/__w/zephyr/modules/hal/wurthelektronik/sensors/WeSensorsSDK/WSEN_PADS_2511020213301/WSEN_PADS_2511020213301.c:2124:11: error: implicit conversion increases floating-point precision: 'float' to 'double' [-Werror,-Wdouble-promotion]
  return ((float) rawPres) * 0.00625;
          ^~~~~~~~~~~~~~~  ~
1 error generated.

https://github.com/WurthElektronik/Sensors-SDK_STM32
(Rant beginning here) I'm rather appalled that wurthelektronik was allowed make the driver a module, looking in to their SDK they claimed was necessary for it to only only come in as a module, all it does is just reg reads and writes.... that ain't special, that's what every existing sensor driver does on its own already and the reg writes the zephyr driver uses from the SDK is extremely minimal from all the ones the sdk includes. A good point was raised during that discussion how this can easily maintained that will need to be reformatted with every Zephyr change and it appears to not of been updated ... but it was still allowed to get through >_<

@XenuIsWatching - have you considered adding yourself as a collaborator to any areas in the MAINTAINERS.yml file? You've made a lot of really valuable additions all over the map, and we need more representation from Meta 😁 ♾

@nordic-krch - can you PTAL w.r.t. cbprintf errors?

@erwango - assigned the related hal_st PR to you, PTAL

@XenuIsWatching - please ping me if something isn't moving along for you.

@cfriedt I just starting one week vacation. I can take a look after that but were are those cbprintf errors? I could not find them when briefly inspected CI failures.

@cfriedt I just starting one week vacation. I can take a look after that but were are those cbprintf errors? I could not find them when briefly inspected CI failures.

Ah, no worries then - I'll see if I can pinpoint them. Enjoy! 🏖🍹

@XenuIsWatching thanks for driving this effort! The CI run you are getting in this PR is going to be a different set of what runs on main after a push, so even if you can get a clear pass here then it may find more issues once it's merged and it'll likely have to be reverted. To test for that using the server CI you can use the https://github.com/zephyrproject-rtos/zephyr-testing/ repository, just make sure to match the CI push run wildcard v*-branch, then you can merge all your in-flight fixes locally and push it there, this is an example: https://github.com/zephyrproject-rtos/zephyr-testing/tree/vfabio-testing-branch. Not sure you have permissions to push there directly, but if not we can surely look into it.

@XenuIsWatching - please update to resolve conflicts (sqrtf.c has been fixed in the linked PR)

Apparently, I don't have permission to push directly to https://github.com/zephyrproject-rtos/zephyr-testing

There you go:
https://github.com/zephyrproject-rtos/zephyr-testing/tree/vfabio-57154-branch
https://github.com/zephyrproject-rtos/zephyr-testing/runs/15095827873
Let me know if you need a rerun on an updated version.

Apparently, I don't have permission to push directly to https://github.com/zephyrproject-rtos/zephyr-testing

There you go: https://github.com/zephyrproject-rtos/zephyr-testing/tree/vfabio-57154-branch https://github.com/zephyrproject-rtos/zephyr-testing/runs/15095827873
Let me know if you need a rerun on an updated version.

Thanks! I found alot with that. I cherry-pick'ed all the open PRs in to here, and now I need an updated version

Thanks! I found alot with that. I cherry-pick'ed all the open PRs in to here, and now I need an updated version

Good stuff, updated https://github.com/zephyrproject-rtos/zephyr-testing/tree/vfabio-57154-branch to 7615ee8d68, running now.

Thanks! I found alot with that. I cherry-pick'ed all the open PRs in to here, and now I need an updated version

Good stuff, updated https://github.com/zephyrproject-rtos/zephyr-testing/tree/vfabio-57154-branch to 7615ee8, running now.

It appears i dun goofed, I didn't wait for the CI to finish running on my new changes for https://github.com/zephyrproject-rtos/zephyr/pull/56957 and the error log is just too full :/  I'll get those fixed and likely we're going to have have to bring it over it again to zephyr-testing once I get that

It appears i dun goofed, I didn't wait for the CI to finish running on my new changes for #56957 and the error log is just too full :/ I'll get those fixed and likely we're going to have have to bring it over it again to zephyr-testing once I get that

No prob, updated to 058fdcfef1.

@XenuIsWatching looks like this needs a rebase

I rebased it as some things need to be merged, but there is still some work that needs to be done in one module, the "zcbor" as well as some modules need to have their commit hash updated to include the double promotions fixes
I don't know when I can get back to it as my daughter popped out in August and I'm on paternity leave until February.

It appears i dun goofed, I didn't wait for the CI to finish running on my new changes for #56957 and the error log is just too full :/ I'll get those fixed and likely we're going to have have to bring it over it again to zephyr-testing once I get that

No prob, updated to 058fdcf.

@fabiobaltieri Would it be possible to do it again?

@fabiobaltieri Would it be possible to do it again?

Of course, just ran git fetch origin refs/pull/57154/head && git push -f testing FETCH_HEAD:refs/heads/vfabio-57154-branch, https://github.com/zephyrproject-rtos/zephyr-testing/tree/vfabio-57154-branch

I don't know when I can get back to it as my daughter popped out in August and I'm on paternity leave until February.

Congratulations 👶👨🍼 🎉

I did a local twister -b run and it looks this is really close -- if we can get the proposed fixes merged in, we should be good to go. I'd be happy to shepherd this change in if Ryan would like to step away until Feb; all of the hard work has been done, and getting this merged requires careful coordination so that additional regressions don't get merged in the middle.

I did a local twister -b run and it looks this is really close -- if we can get the proposed fixes merged in, we should be good to go. I'd be happy to shepherd this change in if Ryan would like to step away until Feb; all of the hard work has been done, and getting this merged requires careful coordination so that additional regressions don't get merged in the middle.

Yeah... it is close, except for the big one. zscilib is full of double promotion issues when I looked in to. I'd expect every single floating point constant within there would have to be within a macro which would put a f after it if it is compiling for single precision.
The other simple thing remaining is just getting the hashes updated for the modules. Those are already stacked within this PR
I did get around to pushing https://github.com/zephyrproject-rtos/zephyr/pull/66241 which looks like the only one that was introduced since then

It appears for the test_sqrt ""fixes"", NAN gets defined in picolibc which forces it to a float, which prevents the test_sqrt.c from using it's own definition. This is one of the CI failures that it uncovered.
https://github.com/picolibc/picolibc/blob/a97720d2a6970239b1dd3936685a372f13303339/newlib/libc/include/math.h#L68C15-L68C29
@keith-packard Do you have any thoughts on this?

I don't know when I can get back to it as my daughter popped out in August and I'm on paternity leave until February.

Congratulations 👶 🎉 🎁

@microbuilder When I try to run the tests for zscilib with twister -p mps2_an521 -T modules/lib/zscilib/tests locally, get this error
/home/ryanmcclelland/zephyrproject/modules/lib/zscilib/tests/prj.conf:4: warning: attempt to assign the value 'y' to the undefined symbol ZSL
/home/ryanmcclelland/zephyrproject/twister-out/mps2_an521/zsl.core.c.double/twister/testsuite_extra.conf:1: warning: attempt to assign the value 'n' to the undefined symbol ZSL_SINGLE_PRECISION
/home/ryanmcclelland/zephyrproject/twister-out/mps2_an521/zsl.core.c.double/twister/testsuite_extra.conf:2: warning: attempt to assign the value '0' to the undefined symbol ZSL_PLATFORM_OPT
error: Aborting due to Kconfig warnings

Am I missing something? I did a fresh west init and west update

@XenuIsWatching I tried here and no error either
~/zephyrproject/zephyr$ ./scripts/twister -p mps2_an521 -T ../modules/lib/zscilib/tests
...
INFO    - Total complete:    2/   2  100%  skipped:    0, failed:    0, error:    0
...
~/zephyrproject/modules/lib/zscilib$ git grep 'config ZSL'
Kconfig.zscilib:config ZSL

Is it there?

git grep 'config ZSL'

yep... I tried the same on a different linux computer and distro as well... same result
(.venv) ryanmcclelland@RyansComputer:~/zephyrproject/modules/lib/zscilib$ git grep 'config ZSL'
Kconfig.zscilib:config ZSL
Kconfig.zscilib:config ZSL_SINGLE_PRECISION
Kconfig.zscilib:config ZSL_PLATFORM_OPT
Kconfig.zscilib:config ZSL_VECTOR_INLINE
Kconfig.zscilib:config ZSL_MATRIX_INLINE
Kconfig.zscilib:config ZSL_BOUNDS_CHECKS
Kconfig.zscilib:config ZSL_SHELL
Kconfig.zscilib:config ZSL_SHELL_CLR
Kconfig.zscilib:config ZSL_SHELL_ORIENT
Kconfig.zscilib:config ZSL_CLR_RGBF_BOUND_CAP

@XenuIsWatching zscilib is an optional lib, do you have it enbled? west config manifest.group-filter -- +optional

west config manifest.group-filter -- +optional

I see... that' must of been a new "feature" that I must of missed.

It appears for the test_sqrt ""fixes"", NAN gets defined in picolibc which forces it to a float, which prevents the test_sqrt.c from using it's own definition. This is one of the CI failures that it uncovered. https://github.com/picolibc/picolibc/blob/a97720d2a6970239b1dd3936685a372f13303339/newlib/libc/include/math.h#L68C15-L68C29
@keith-packard Do you have any thoughts on this?

With zscilib fixed (hopefully), it looks like this is the last thing (I hope) before all the CIs are passing with this compilier flag

@XenuIsWatching I merged in the changes to zscilib if you want to update the manifest. Thanks for putting those together.

zcbor:196f985c31673a5e80a2c2959d61853f25a26551 is ok

but it needs to be merged into https://github.com/zephyrproject-rtos/zcbor

@fabiobaltieri Can you merge this into zephyr-testing again? I really hope this is the last time as it now appears all the checkboxes are now checked :)

@XenuIsWatching  hey welcome back! There you have it: https://github.com/zephyrproject-rtos/zephyr-testing/tree/vfabio-57154-branch

authors: XenuIsWatching cfriedt fabiobaltieri keith-packard microbuilder nordic-krch nordicjm tejlmand


text:
input: add a gpio qdec input driver

Hi, wrote this for GPIO based rotary encoded (scroller wheels) to feed data to input devices. Originally wrote this in 2021 as a sensor driver but I think it makes sense to have it as an input device as it's probably a common use case (lvgl has a a concept of input encoder as well, ZMK has a driver as well), so I rewrote it as an input driver and added an timeout and idle mode so it should play well with battery powerd devices.
Let me know what you think.

Add a GPIO based quadrature decoder driver that reports relative axes movements using the input subsystem.

All done, one open question on the naming, also added a line for initializing the state at init time based on the actual gpio values, noticed it was missing the first step on an encoder with two steps per period, that fixed it.

nothing seems to be building it, can you add it to some driver build test?

nothing seems to be building it, can you add it to some driver build test?

Yeah good point, I can add an input under build_all to catch drivers that are not under something else (i2c), mind if I do it as a followup?

authors: fabiobaltieri nashif