* Re: barebox - rk3568
From: Ahmad Fatoum @ 2022-01-05 12:08 UTC (permalink / raw)
To: Frank Wunderlich, barebox
In-Reply-To: <trinity-c26cce2b-95ff-45dc-9d60-3a1eebfa088b-1641285545326@3c-app-gmx-bap27>
Hello Frank,
On 04.01.22 09:39, Frank Wunderlich wrote:
> Hi,
>
> i have a prototype rk3568 board (bpi-r2-pro).
>
> is it possible to flash only barebox instead of uboot? in documentation i found only "creating SD-card", but i dont want to break existing partitions.
>
> https://www.barebox.org/doc/latest/boards/rockchip.html#rockchip-rk3568
>
> says it starts from sector 32, my first block for uboot (idblock.bin=spl+raminit) starts at 64, full uboot in partition at 8M.
You probably figured it out by now, but the discrepancy is likely due to differing
block sizes. barebox documentation has `dd bs=1024`, while the default is 512.
boot firmware is a single chunk with barebox, so no separate second stage bootloader
partition.
> As it differs a bit from evb can i add new dts like in uboot?
You can check out the commit adding the EVB or the Pine64 Quartz64:
8d14f8e898b4 ("arm: rockchip: add support for the quartz64 board")
Feel free to send patches for your board along the same lines. :)
Cheers,
Ahmad
>
> regards Frank
>
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: move i915_reg_read_ioctl declaration to intel_uncore.h
From: Patchwork @ 2022-01-05 12:13 UTC (permalink / raw)
To: Jani Nikula; +Cc: intel-gfx
In-Reply-To: <20220105100520.976092-1-jani.nikula@intel.com>
[-- Attachment #1: Type: text/plain, Size: 30314 bytes --]
== Series Details ==
Series: series starting with [1/2] drm/i915: move i915_reg_read_ioctl declaration to intel_uncore.h
URL : https://patchwork.freedesktop.org/series/98499/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11047_full -> Patchwork_21925_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_21925_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_21925_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (13 -> 12)
------------------------------
Missing (1): shard-dg1
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_21925_full:
### IGT changes ###
#### Possible regressions ####
* igt@kms_frontbuffer_tracking@psr-1p-rte:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-tglb6/igt@kms_frontbuffer_tracking@psr-1p-rte.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-tglb8/igt@kms_frontbuffer_tracking@psr-1p-rte.html
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_create@create-clear:
- {shard-rkl}: NOTRUN -> ([PASS][3], [INCOMPLETE][4])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-rkl-4/igt@gem_create@create-clear.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-rkl-5/igt@gem_create@create-clear.html
* igt@gem_exec_whisper@basic-fds-priority:
- {shard-rkl}: NOTRUN -> [INCOMPLETE][5] +1 similar issue
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-rkl-5/igt@gem_exec_whisper@basic-fds-priority.html
* igt@gem_exec_whisper@basic-queues-priority:
- {shard-rkl}: [PASS][6] -> [DMESG-FAIL][7]
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-rkl-6/igt@gem_exec_whisper@basic-queues-priority.html
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-rkl-5/igt@gem_exec_whisper@basic-queues-priority.html
* igt@gem_flink_race@flink_close:
- {shard-rkl}: [PASS][8] -> [INCOMPLETE][9]
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-rkl-1/igt@gem_flink_race@flink_close.html
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-rkl-5/igt@gem_flink_race@flink_close.html
* igt@i915_pm_dc@dc6-psr:
- {shard-tglu}: NOTRUN -> [SKIP][10]
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-tglu-1/igt@i915_pm_dc@dc6-psr.html
* igt@testdisplay:
- {shard-tglu}: [PASS][11] -> [DMESG-WARN][12]
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-tglu-1/igt@testdisplay.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-tglu-5/igt@testdisplay.html
Known issues
------------
Here are the changes found in Patchwork_21925_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_create@create-massive:
- shard-tglb: NOTRUN -> [DMESG-WARN][13] ([i915#3002])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-tglb7/igt@gem_create@create-massive.html
* igt@gem_eio@in-flight-contexts-immediate:
- shard-tglb: [PASS][14] -> [TIMEOUT][15] ([i915#3063])
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-tglb7/igt@gem_eio@in-flight-contexts-immediate.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-tglb3/igt@gem_eio@in-flight-contexts-immediate.html
* igt@gem_eio@in-flight-suspend:
- shard-apl: NOTRUN -> [DMESG-WARN][16] ([i915#180])
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-apl6/igt@gem_eio@in-flight-suspend.html
* igt@gem_exec_fair@basic-flow@rcs0:
- shard-skl: NOTRUN -> [SKIP][17] ([fdo#109271]) +190 similar issues
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-skl5/igt@gem_exec_fair@basic-flow@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-kbl: [PASS][18] -> [FAIL][19] ([i915#2842]) +1 similar issue
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-kbl4/igt@gem_exec_fair@basic-pace-solo@rcs0.html
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-kbl7/igt@gem_exec_fair@basic-pace-solo@rcs0.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][20] -> [FAIL][21] ([i915#2849])
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-iclb5/igt@gem_exec_fair@basic-throttle@rcs0.html
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-iclb1/igt@gem_exec_fair@basic-throttle@rcs0.html
* igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][22] -> [SKIP][23] ([i915#2190])
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-tglb1/igt@gem_huc_copy@huc-copy.html
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-tglb6/igt@gem_huc_copy@huc-copy.html
* igt@gem_lmem_swapping@parallel-random:
- shard-apl: NOTRUN -> [SKIP][24] ([fdo#109271] / [i915#4613])
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-apl7/igt@gem_lmem_swapping@parallel-random.html
- shard-kbl: NOTRUN -> [SKIP][25] ([fdo#109271] / [i915#4613]) +1 similar issue
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-kbl4/igt@gem_lmem_swapping@parallel-random.html
* igt@gem_lmem_swapping@random:
- shard-skl: NOTRUN -> [SKIP][26] ([fdo#109271] / [i915#4613])
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-skl2/igt@gem_lmem_swapping@random.html
* igt@gem_lmem_swapping@smem-oom:
- shard-tglb: NOTRUN -> [SKIP][27] ([i915#4613])
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-tglb7/igt@gem_lmem_swapping@smem-oom.html
* igt@gem_userptr_blits@input-checking:
- shard-skl: NOTRUN -> [DMESG-WARN][28] ([i915#3002]) +1 similar issue
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-skl5/igt@gem_userptr_blits@input-checking.html
* igt@gem_workarounds@suspend-resume:
- shard-kbl: [PASS][29] -> [DMESG-WARN][30] ([i915#180])
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-kbl6/igt@gem_workarounds@suspend-resume.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-kbl4/igt@gem_workarounds@suspend-resume.html
* igt@gen9_exec_parse@allowed-all:
- shard-glk: [PASS][31] -> [DMESG-WARN][32] ([i915#1436] / [i915#716])
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-glk2/igt@gen9_exec_parse@allowed-all.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-glk8/igt@gen9_exec_parse@allowed-all.html
* igt@i915_pm_dc@dc6-dpms:
- shard-kbl: NOTRUN -> [FAIL][33] ([i915#454])
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-kbl3/igt@i915_pm_dc@dc6-dpms.html
* igt@i915_suspend@debugfs-reader:
- shard-apl: [PASS][34] -> [DMESG-WARN][35] ([i915#180]) +1 similar issue
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-apl4/igt@i915_suspend@debugfs-reader.html
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-apl3/igt@i915_suspend@debugfs-reader.html
* igt@kms_async_flips@alternate-sync-async-flip:
- shard-skl: [PASS][36] -> [FAIL][37] ([i915#2521])
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-skl10/igt@kms_async_flips@alternate-sync-async-flip.html
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-skl9/igt@kms_async_flips@alternate-sync-async-flip.html
- shard-glk: [PASS][38] -> [FAIL][39] ([i915#2521])
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-glk4/igt@kms_async_flips@alternate-sync-async-flip.html
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-glk2/igt@kms_async_flips@alternate-sync-async-flip.html
* igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0-async-flip:
- shard-skl: NOTRUN -> [FAIL][40] ([i915#3763])
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-skl6/igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0-async-flip.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0-hflip:
- shard-apl: NOTRUN -> [SKIP][41] ([fdo#109271] / [i915#3777])
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-apl7/igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0-hflip.html
- shard-kbl: NOTRUN -> [SKIP][42] ([fdo#109271] / [i915#3777])
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-kbl4/igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0-hflip.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip:
- shard-skl: NOTRUN -> [FAIL][43] ([i915#3743]) +2 similar issues
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-skl5/igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-hflip:
- shard-skl: NOTRUN -> [SKIP][44] ([fdo#109271] / [i915#3777])
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-skl6/igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-hflip.html
* igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_rc_ccs_cc:
- shard-kbl: NOTRUN -> [SKIP][45] ([fdo#109271] / [i915#3886]) +3 similar issues
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-kbl3/igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-b-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc:
- shard-skl: NOTRUN -> [SKIP][46] ([fdo#109271] / [i915#3886]) +10 similar issues
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-skl6/igt@kms_ccs@pipe-b-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-c-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc:
- shard-apl: NOTRUN -> [SKIP][47] ([fdo#109271] / [i915#3886]) +5 similar issues
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-apl3/igt@kms_ccs@pipe-c-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_chamelium@dp-hpd-storm-disable:
- shard-apl: NOTRUN -> [SKIP][48] ([fdo#109271] / [fdo#111827]) +4 similar issues
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-apl7/igt@kms_chamelium@dp-hpd-storm-disable.html
* igt@kms_color_chamelium@pipe-a-ctm-blue-to-red:
- shard-kbl: NOTRUN -> [SKIP][49] ([fdo#109271] / [fdo#111827]) +5 similar issues
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-kbl3/igt@kms_color_chamelium@pipe-a-ctm-blue-to-red.html
* igt@kms_color_chamelium@pipe-b-ctm-max:
- shard-skl: NOTRUN -> [SKIP][50] ([fdo#109271] / [fdo#111827]) +14 similar issues
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-skl2/igt@kms_color_chamelium@pipe-b-ctm-max.html
* igt@kms_content_protection@atomic-dpms:
- shard-apl: NOTRUN -> [TIMEOUT][51] ([i915#1319])
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-apl3/igt@kms_content_protection@atomic-dpms.html
- shard-kbl: NOTRUN -> [TIMEOUT][52] ([i915#1319])
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-kbl4/igt@kms_content_protection@atomic-dpms.html
* igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-kbl: NOTRUN -> [DMESG-WARN][53] ([i915#180])
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-kbl4/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
* igt@kms_cursor_crc@pipe-d-cursor-512x170-random:
- shard-tglb: NOTRUN -> [SKIP][54] ([fdo#109279] / [i915#3359])
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-tglb7/igt@kms_cursor_crc@pipe-d-cursor-512x170-random.html
* igt@kms_cursor_edge_walk@pipe-d-64x64-left-edge:
- shard-kbl: NOTRUN -> [SKIP][55] ([fdo#109271]) +83 similar issues
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-kbl3/igt@kms_cursor_edge_walk@pipe-d-64x64-left-edge.html
* igt@kms_cursor_legacy@2x-cursor-vs-flip-atomic:
- shard-tglb: NOTRUN -> [SKIP][56] ([fdo#109274] / [fdo#111825])
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-tglb7/igt@kms_cursor_legacy@2x-cursor-vs-flip-atomic.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-iclb: [PASS][57] -> [FAIL][58] ([i915#2346])
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-iclb7/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-iclb7/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytile-downscaling:
- shard-iclb: [PASS][59] -> [SKIP][60] ([i915#3701])
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-iclb1/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytile-downscaling.html
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-iclb2/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytile-downscaling.html
* igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-mmap-wc:
- shard-tglb: NOTRUN -> [SKIP][61] ([fdo#109280] / [fdo#111825]) +1 similar issue
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-tglb7/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-mmap-wc.html
* igt@kms_pipe_crc_basic@disable-crc-after-crtc-pipe-d:
- shard-apl: NOTRUN -> [SKIP][62] ([fdo#109271] / [i915#533])
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-apl7/igt@kms_pipe_crc_basic@disable-crc-after-crtc-pipe-d.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-d:
- shard-skl: NOTRUN -> [SKIP][63] ([fdo#109271] / [i915#533])
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-skl5/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-d.html
* igt@kms_plane_alpha_blend@pipe-a-alpha-7efc:
- shard-skl: NOTRUN -> [FAIL][64] ([fdo#108145] / [i915#265]) +1 similar issue
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-skl3/igt@kms_plane_alpha_blend@pipe-a-alpha-7efc.html
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: [PASS][65] -> [FAIL][66] ([fdo#108145] / [i915#265])
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-skl4/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-skl9/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
* igt@kms_psr2_sf@overlay-plane-update-continuous-sf:
- shard-apl: NOTRUN -> [SKIP][67] ([fdo#109271] / [i915#658])
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-apl8/igt@kms_psr2_sf@overlay-plane-update-continuous-sf.html
* igt@kms_psr2_sf@primary-plane-update-sf-dmg-area:
- shard-kbl: NOTRUN -> [SKIP][68] ([fdo#109271] / [i915#658])
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-kbl3/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area.html
* igt@kms_psr2_su@frontbuffer-xrgb8888:
- shard-skl: NOTRUN -> [SKIP][69] ([fdo#109271] / [i915#658]) +1 similar issue
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-skl3/igt@kms_psr2_su@frontbuffer-xrgb8888.html
* igt@kms_psr@psr2_sprite_blt:
- shard-iclb: [PASS][70] -> [SKIP][71] ([fdo#109441])
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-iclb2/igt@kms_psr@psr2_sprite_blt.html
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-iclb5/igt@kms_psr@psr2_sprite_blt.html
* igt@kms_vblank@pipe-d-ts-continuation-idle:
- shard-apl: NOTRUN -> [SKIP][72] ([fdo#109271]) +92 similar issues
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-apl6/igt@kms_vblank@pipe-d-ts-continuation-idle.html
* igt@kms_vblank@pipe-d-wait-idle:
- shard-kbl: NOTRUN -> [SKIP][73] ([fdo#109271] / [i915#533]) +2 similar issues
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-kbl3/igt@kms_vblank@pipe-d-wait-idle.html
* igt@kms_writeback@writeback-invalid-parameters:
- shard-kbl: NOTRUN -> [SKIP][74] ([fdo#109271] / [i915#2437])
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-kbl4/igt@kms_writeback@writeback-invalid-parameters.html
- shard-apl: NOTRUN -> [SKIP][75] ([fdo#109271] / [i915#2437])
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-apl7/igt@kms_writeback@writeback-invalid-parameters.html
* igt@kms_writeback@writeback-pixel-formats:
- shard-skl: NOTRUN -> [SKIP][76] ([fdo#109271] / [i915#2437])
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-skl2/igt@kms_writeback@writeback-pixel-formats.html
* igt@nouveau_crc@pipe-b-ctx-flip-detection:
- shard-tglb: NOTRUN -> [SKIP][77] ([i915#2530])
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-tglb7/igt@nouveau_crc@pipe-b-ctx-flip-detection.html
* igt@perf@polling-parameterized:
- shard-skl: NOTRUN -> [FAIL][78] ([i915#1542])
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-skl2/igt@perf@polling-parameterized.html
* igt@perf@short-reads:
- shard-skl: NOTRUN -> [FAIL][79] ([i915#51])
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-skl6/igt@perf@short-reads.html
* igt@sysfs_clients@create:
- shard-skl: NOTRUN -> [SKIP][80] ([fdo#109271] / [i915#2994]) +1 similar issue
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-skl6/igt@sysfs_clients@create.html
* igt@sysfs_clients@fair-0:
- shard-kbl: NOTRUN -> [SKIP][81] ([fdo#109271] / [i915#2994])
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-kbl3/igt@sysfs_clients@fair-0.html
#### Possible fixes ####
* igt@feature_discovery@psr2:
- {shard-rkl}: [SKIP][82] ([i915#658]) -> [PASS][83]
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-rkl-1/igt@feature_discovery@psr2.html
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-rkl-6/igt@feature_discovery@psr2.html
* igt@gem_ctx_shared@detached-shared-gtt:
- {shard-rkl}: [INCOMPLETE][84] -> [PASS][85] +2 similar issues
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-rkl-5/igt@gem_ctx_shared@detached-shared-gtt.html
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-rkl-6/igt@gem_ctx_shared@detached-shared-gtt.html
* igt@gem_eio@unwedge-stress:
- shard-iclb: [TIMEOUT][86] ([i915#2481] / [i915#3070]) -> [PASS][87]
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-iclb2/igt@gem_eio@unwedge-stress.html
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-iclb6/igt@gem_eio@unwedge-stress.html
* igt@gem_exec_balancer@bonded-pair:
- {shard-tglu}: [FAIL][88] ([i915#1888]) -> [PASS][89]
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-tglu-1/igt@gem_exec_balancer@bonded-pair.html
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-tglu-7/igt@gem_exec_balancer@bonded-pair.html
* igt@gem_exec_balancer@parallel-out-fence:
- shard-iclb: [SKIP][90] ([i915#4525]) -> [PASS][91] +1 similar issue
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-iclb8/igt@gem_exec_balancer@parallel-out-fence.html
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-iclb1/igt@gem_exec_balancer@parallel-out-fence.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [FAIL][92] ([i915#2842]) -> [PASS][93]
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-iclb1/igt@gem_exec_fair@basic-none-share@rcs0.html
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-iclb2/igt@gem_exec_fair@basic-none-share@rcs0.html
* igt@gem_exec_fair@basic-none@rcs0:
- shard-kbl: [FAIL][94] ([i915#2842]) -> [PASS][95] +1 similar issue
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-kbl1/igt@gem_exec_fair@basic-none@rcs0.html
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-kbl1/igt@gem_exec_fair@basic-none@rcs0.html
* igt@gem_exec_fair@basic-none@vecs0:
- shard-apl: [FAIL][96] ([i915#2842]) -> [PASS][97] +1 similar issue
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-apl4/igt@gem_exec_fair@basic-none@vecs0.html
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-apl3/igt@gem_exec_fair@basic-none@vecs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [FAIL][98] ([i915#2842]) -> [PASS][99]
[98]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-tglb6/igt@gem_exec_fair@basic-pace-share@rcs0.html
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-tglb3/igt@gem_exec_fair@basic-pace-share@rcs0.html
- {shard-rkl}: [FAIL][100] ([i915#2842]) -> ([PASS][101], [PASS][102])
[100]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-rkl-1/igt@gem_exec_fair@basic-pace-share@rcs0.html
[101]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-rkl-2/igt@gem_exec_fair@basic-pace-share@rcs0.html
[102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-rkl-4/igt@gem_exec_fair@basic-pace-share@rcs0.html
* igt@gem_exec_whisper@basic-contexts-priority:
- {shard-rkl}: [DMESG-FAIL][103] -> ([PASS][104], [PASS][105])
[103]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-rkl-5/igt@gem_exec_whisper@basic-contexts-priority.html
[104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-rkl-1/igt@gem_exec_whisper@basic-contexts-priority.html
[105]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-rkl-4/igt@gem_exec_whisper@basic-contexts-priority.html
* igt@gem_exec_whisper@basic-queues-priority-all:
- shard-glk: [DMESG-WARN][106] ([i915#118]) -> [PASS][107] +1 similar issue
[106]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-glk7/igt@gem_exec_whisper@basic-queues-priority-all.html
[107]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-glk5/igt@gem_exec_whisper@basic-queues-priority-all.html
* igt@gen9_exec_parse@allowed-single:
- shard-skl: [DMESG-WARN][108] ([i915#1436] / [i915#716]) -> [PASS][109]
[108]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-skl6/igt@gen9_exec_parse@allowed-single.html
[109]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-skl5/igt@gen9_exec_parse@allowed-single.html
* igt@i915_module_load@reload-with-fault-injection:
- shard-skl: [DMESG-WARN][110] ([i915#1982]) -> [PASS][111]
[110]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-skl8/igt@i915_module_load@reload-with-fault-injection.html
[111]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-skl10/igt@i915_module_load@reload-with-fault-injection.html
* igt@i915_pm_dc@dc9-dpms:
- shard-iclb: [SKIP][112] ([i915#4281]) -> [PASS][113]
[112]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-iclb3/igt@i915_pm_dc@dc9-dpms.html
[113]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-iclb1/igt@i915_pm_dc@dc9-dpms.html
* igt@i915_pm_rc6_residency@rc6-fence:
- {shard-tglu}: [WARN][114] ([i915#2681]) -> [PASS][115]
[114]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-tglu-1/igt@i915_pm_rc6_residency@rc6-fence.html
[115]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-tglu-5/igt@i915_pm_rc6_residency@rc6-fence.html
* igt@i915_pm_rpm@dpms-mode-unset-lpsp:
- {shard-rkl}: [SKIP][116] ([i915#1397]) -> [PASS][117]
[116]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-rkl-1/igt@i915_pm_rpm@dpms-mode-unset-lpsp.html
[117]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-rkl-6/igt@i915_pm_rpm@dpms-mode-unset-lpsp.html
* igt@i915_selftest@live@gt_pm:
- {shard-tglu}: [DMESG-FAIL][118] ([i915#3987]) -> [PASS][119]
[118]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-tglu-8/igt@i915_selftest@live@gt_pm.html
[119]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-tglu-8/igt@i915_selftest@live@gt_pm.html
* igt@i915_suspend@fence-restore-tiled2untiled:
- shard-apl: [DMESG-WARN][120] ([i915#180]) -> [PASS][121] +3 similar issues
[120]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-apl8/igt@i915_suspend@fence-restore-tiled2untiled.html
[121]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-apl8/igt@i915_suspend@fence-restore-tiled2untiled.html
* igt@i915_suspend@sysfs-reader:
- shard-kbl: [DMESG-WARN][122] ([i915#180]) -> [PASS][123] +1 similar issue
[122]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-kbl6/igt@i915_suspend@sysfs-reader.html
[123]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-kbl4/igt@i915_suspend@sysfs-reader.html
* igt@kms_big_fb@linear-16bpp-rotate-180:
- {shard-tglu}: [DMESG-WARN][124] ([i915#402]) -> [PASS][125]
[124]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-tglu-1/igt@kms_big_fb@linear-16bpp-rotate-180.html
[125]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-tglu-5/igt@kms_big_fb@linear-16bpp-rotate-180.html
* igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_rc_ccs:
- {shard-rkl}: [SKIP][126] ([i915#1845] / [i915#4098]) -> [PASS][127] +1 similar issue
[126]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-rkl-1/igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_rc_ccs.html
[127]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-rkl-6/igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_rc_ccs.html
* igt@kms_color@pipe-a-ctm-max:
- {shard-rkl}: [SKIP][128] ([i915#1149] / [i915#1849]) -> [PASS][129]
[128]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-rkl-5/igt@kms_color@pipe-a-ctm-max.html
[129]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-rkl-6/igt@kms_color@pipe-a-ctm-max.html
* igt@kms_color@pipe-a-legacy-gamma:
- {shard-rkl}: [SKIP][130] ([i915#1849] / [i915#4070]) -> [PASS][131] +3 similar issues
[130]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-rkl-1/igt@kms_color@pipe-a-legacy-gamma.html
[131]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-rkl-6/igt@kms_color@pipe-a-legacy-gamma.html
* igt@kms_color@pipe-b-ctm-max:
- {shard-rkl}: [SKIP][132] ([i915#1149] / [i915#1849] / [i915#4070]) -> [PASS][133]
[132]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-rkl-1/igt@kms_color@pipe-b-ctm-max.html
[133]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-rkl-6/igt@kms_color@pipe-b-ctm-max.html
* igt@kms_cursor_crc@pipe-a-cursor-128x128-rapid-movement:
- {shard-rkl}: [SKIP][134] ([fdo#112022] / [i915#4070]) -> [PASS][135] +2 similar issues
[134]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-rkl-1/igt@kms_cursor_crc@pipe-a-cursor-128x128-rapid-movement.html
[135]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-rkl-6/igt@kms_cursor_crc@pipe-a-cursor-128x128-rapid-movement.html
* igt@kms_cursor_crc@pipe-b-cursor-64x64-sliding:
- {shard-rkl}: ([SKIP][136], [SKIP][137]) ([fdo#112022] / [i915#4070]) -> [PASS][138]
[136]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-rkl-1/igt@kms_cursor_crc@pipe-b-cursor-64x64-sliding.html
[137]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-rkl-4/igt@kms_cursor_crc@pipe-b-cursor-64x64-sliding.html
[138]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-rkl-6/igt@kms_cursor_crc@pipe-b-cursor-64x64-sliding.html
* igt@kms_cursor_legacy@cursor-vs-flip-varying-size:
- {shard-rkl}: [SKIP][139] ([fdo#111825] / [i915#4070]) -> [PASS][140] +1 similar issue
[139]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-rkl-1/igt@kms_cursor_legacy@cursor-vs-flip-varying-size.html
[140]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-rkl-6/igt@kms_cursor_legacy@cursor-vs-flip-varying-size.html
* igt@kms_cursor_legacy@cursora-vs-flipa-legacy:
- {shard-rkl}: ([SKIP][141], [SKIP][142]) ([fdo#111825] / [i915#4070]) -> [PASS][143]
[141]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-rkl-4/igt@kms_cursor_legacy@cursora-vs-flipa-legacy.html
[142]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-rkl-1/igt@kms_cursor_legacy@cursora-vs-flipa-legacy.html
[143]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-rkl-6/igt@kms_cursor_legacy@cursora-vs-flipa-legacy.html
* igt@kms_cursor_legacy@flip-vs-cursor-toggle:
- shard-iclb: [FAIL][144] ([i915#2346]) -> [PASS][145] +1 similar issue
[144]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-iclb7/igt@kms_cursor_legacy@flip-vs-cursor-toggle.html
[145]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/shard-iclb4/igt@kms_cursor_legacy@flip-vs-cur
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/index.html
[-- Attachment #2: Type: text/html, Size: 33405 bytes --]
^ permalink raw reply
* [PATCH v2] gpu/drm: fix potential memleak in error branch
From: Bernard Zhao @ 2022-01-05 12:13 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Daniel Vetter, dri-devel, linux-kernel
Cc: Bernard Zhao
This patch try to fix potential memleak in error branch.
For example:
nv50_sor_create ->nv50_mstm_new-> drm_dp_mst_topology_mgr_init,
In function drm_dp_mst_topology_mgr_init, there are five error
branches, error branch just return error code, no free called.
And we see that the caller didn`t do the drm_dp_mst_topology_mgr_destroy job.
In this case, this may bring in the risk of memleak issue.
Signed-off-by: Bernard Zhao <bernard@vivo.com>
---
drivers/gpu/drm/drm_dp_mst_topology.c | 22 ++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c
index f3d79eda94bb..f73b180dee73 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -5501,7 +5501,10 @@ int drm_dp_mst_topology_mgr_init(struct drm_dp_mst_topology_mgr *mgr,
int max_lane_count, int max_link_rate,
int conn_base_id)
{
- struct drm_dp_mst_topology_state *mst_state;
+ struct drm_dp_mst_topology_state *mst_state = NULL;
+
+ mgr->payloads = NULL;
+ mgr->proposed_vcpis = NULL;
mutex_init(&mgr->lock);
mutex_init(&mgr->qlock);
@@ -5523,7 +5526,7 @@ int drm_dp_mst_topology_mgr_init(struct drm_dp_mst_topology_mgr *mgr,
*/
mgr->delayed_destroy_wq = alloc_ordered_workqueue("drm_dp_mst_wq", 0);
if (mgr->delayed_destroy_wq == NULL)
- return -ENOMEM;
+ goto out;
INIT_WORK(&mgr->work, drm_dp_mst_link_probe_work);
INIT_WORK(&mgr->tx_work, drm_dp_tx_work);
@@ -5539,18 +5542,18 @@ int drm_dp_mst_topology_mgr_init(struct drm_dp_mst_topology_mgr *mgr,
mgr->conn_base_id = conn_base_id;
if (max_payloads + 1 > sizeof(mgr->payload_mask) * 8 ||
max_payloads + 1 > sizeof(mgr->vcpi_mask) * 8)
- return -EINVAL;
+ goto failed;
mgr->payloads = kcalloc(max_payloads, sizeof(struct drm_dp_payload), GFP_KERNEL);
if (!mgr->payloads)
- return -ENOMEM;
+ goto failed;
mgr->proposed_vcpis = kcalloc(max_payloads, sizeof(struct drm_dp_vcpi *), GFP_KERNEL);
if (!mgr->proposed_vcpis)
- return -ENOMEM;
+ goto failed;
set_bit(0, &mgr->payload_mask);
mst_state = kzalloc(sizeof(*mst_state), GFP_KERNEL);
if (mst_state == NULL)
- return -ENOMEM;
+ goto failed;
mst_state->total_avail_slots = 63;
mst_state->start_slot = 1;
@@ -5563,6 +5566,13 @@ int drm_dp_mst_topology_mgr_init(struct drm_dp_mst_topology_mgr *mgr,
&drm_dp_mst_topology_state_funcs);
return 0;
+
+failed:
+ kfree(mgr->proposed_vcpis);
+ kfree(mgr->payloads);
+ destroy_workqueue(mgr->delayed_destroy_wq);
+out:
+ return -ENOMEM;
}
EXPORT_SYMBOL(drm_dp_mst_topology_mgr_init);
--
2.33.1
^ permalink raw reply related
* Re: [PATCH] crypto: use signed variable to store status and error checking
From: Giovanni Cabiddu @ 2022-01-05 12:13 UTC (permalink / raw)
To: Muhammad Usama Anjum
Cc: Herbert Xu, David S. Miller, open list:QAT DRIVER,
open list:CRYPTO API, open list
In-Reply-To: <YdS+cgcyKdXUQaU+@debian-BULLSEYE-live-builder-AMD64>
Thanks for your patch.
Patches to the qat driver have the following headline
crypto: qat - ...
not just
crypto: ...
On Wed, Jan 05, 2022 at 02:38:58AM +0500, Muhammad Usama Anjum wrote:
> ret should be signed. adf_cfg_get_param_value and match_string return
Use () when refer to the function().
> signed statuses. The return status may be saved wrongly in unsigned ret
> variable. Correct the data type of ret to signed int.
>
> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
After fixing,
Acked-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Regards,
--
Giovanni
^ permalink raw reply
* Re: [PATCH 00/11] Add support for SUNIV and F1C100s.
From: Andre Przywara @ 2022-01-05 12:14 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Jesse Taube, u-boot, jagan, hdegoede, sjg, marek.behun, festevam,
narmstrong, tharvey, christianshewitt, pbrobinson, lokeshvutla,
jernej.skrabec, hs, samuel, arnaud.ferraris, giulio.benetti,
thirtythreeforty
In-Reply-To: <16f1b5aed8b616547084c64d2ec4398446681392.camel@aosc.io>
On Wed, 05 Jan 2022 19:36:29 +0800
Icenowy Zheng <icenowy@aosc.io> wrote:
Hi Jesse,
> 在 2022-01-04星期二的 19:34 -0500，Jesse Taube写道：
> > This patch set aims to add suport for the SUNIV and F1C100s.
> > Suport has been in linux for a while now, but not in u-boot.
> >
> > This patchset contains:
> > - CPU specific initialization code
> > - SUNIV dram driver
> > - SUNIV clock driver adaption
> > - SUNIV gpio driver adaption
> > - SUNIV uart driver adaption
> > - F1C100s basic support
> >
> > I am hoping to get Icenowy's patches in as it seems she hasnt
> > submitted
> > in a while. The only edits I made to her code is rebasing it against
> > ML
> > and changing some formating. I also re-grouped her commits.
>
> I got too lazy to send it (because I think F1C100s is just too weak)...
>
> >
> > I am wondering if the dram driver should be moved into device drivers
> > rather than in mach-sunxi.
> > I am also wondering if it is okay to submit some one elses code,
> > and if so how should I do so.
>
> As you are keeping my SoB and adding yours, it's totally okay.
Thanks Icenowy for confirming!
Jesse: yes, it's perfectly fine to send patches from someone else, as
long as you keep the authorship, their SoB, and add your's.
Typical reasons are lack of time or interest from the original author.
But it's customary to ask the author first, and care should be taken
when changing patches, as this might not be in the interest of the
original author (and they are the ones who will get blamed for bugs).
Also please mark the series either as a Resend or as a v2.
So with Icenowy's confirmation above I consider this fine.
But what was actually holding back this series was lack of review,
testing and/or interest. Similar to Icenowy my personal interest in
crufty old cores is somewhat limited, so this wasn't very high on my
priority list.
So given that there is apparently some interest now:
Can you confirm that you have reviewed the series, or at least tested
this? I would be interested to know if a second pair of eyes had a
look, and to what extent. I don't have any hardware, so would need to
rely on others to make sure this code is somewhat sane.
And it basically looks like a v2 of Icenowy's series, so can you give a
Changelog of the differences? I skimmed over her original series back
then, so I would be interested in what makes this version special.
Cheers,
Andre
> Thanks for cleaning up these patches! ;-)
>
> >
> > Icenowy Zheng (11):
> > arm: arm926ej-s: start.S: port save_boot_params support from armv7
> > code
> > arm: arm926ej-s: add sunxi code
> > dt-bindings: clock: Add initial suniv headers
> > dt-bindings: reset: Add initial suniv headers
> > ARM: sunxi: Add support for F1C100s
> > sunxi: Add F1C100s DRAM initial support
> > sunxi: board: Add support for SUNIV
> > configs: sunxi: Add common SUNIV header
> > sunxi: Add support for SUNIV architecture
> > ARM: dts: suniv: Add device tree files for F1C100s
> > configs: sunxi: Add support for Lichee Pi Nano
> >
> > arch/arm/cpu/arm926ejs/Makefile | 1 +
> > arch/arm/cpu/arm926ejs/start.S | 19 +
> > arch/arm/cpu/arm926ejs/sunxi/Makefile | 15 +
> > arch/arm/cpu/arm926ejs/sunxi/config.mk | 6 +
> > arch/arm/cpu/arm926ejs/sunxi/fel_utils.S | 37 ++
> > arch/arm/cpu/arm926ejs/sunxi/lowlevel_init.S | 67 +++
> > arch/arm/cpu/arm926ejs/sunxi/start.c | 1 +
> > arch/arm/cpu/arm926ejs/sunxi/timer.c | 114 +++++
> > arch/arm/cpu/arm926ejs/sunxi/u-boot-spl.lds | 62 +++
> > arch/arm/dts/Makefile | 2 +
> > arch/arm/dts/suniv-f1c100s-licheepi-nano.dts | 64 +++
> > arch/arm/dts/suniv-f1c100s.dtsi | 6 +
> > arch/arm/dts/suniv.dtsi | 224 ++++++++++
> > arch/arm/include/asm/arch-sunxi/clock.h | 2 +-
> > arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 25 ++
> > arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 8 +
> > arch/arm/include/asm/arch-sunxi/dram.h | 2 +
> > arch/arm/include/asm/arch-sunxi/dram_suniv.h | 46 ++
> > arch/arm/include/asm/arch-sunxi/gpio.h | 1 +
> > arch/arm/mach-sunxi/Kconfig | 16 +-
> > arch/arm/mach-sunxi/Makefile | 2 +
> > arch/arm/mach-sunxi/board.c | 31 +-
> > arch/arm/mach-sunxi/clock.c | 3 +-
> > arch/arm/mach-sunxi/clock_sun6i.c | 46 +-
> > arch/arm/mach-sunxi/cpu_info.c | 2 +
> > arch/arm/mach-sunxi/dram_helpers.c | 4 +
> > arch/arm/mach-sunxi/dram_suniv.c | 420
> > ++++++++++++++++++
> > board/sunxi/board.c | 4 +-
> > configs/licheepi_nano_defconfig | 13 +
> > configs/licheepi_nano_spiflash_defconfig | 25 ++
> > include/configs/suniv.h | 14 +
> > include/configs/sunxi-common.h | 67 ++-
> > include/dt-bindings/clock/suniv-ccu.h | 68 +++
> > include/dt-bindings/reset/suniv-ccu.h | 36 ++
> > 34 files changed, 1424 insertions(+), 29 deletions(-)
> > create mode 100644 arch/arm/cpu/arm926ejs/sunxi/Makefile
> > create mode 100644 arch/arm/cpu/arm926ejs/sunxi/config.mk
> > create mode 100644 arch/arm/cpu/arm926ejs/sunxi/fel_utils.S
> > create mode 100644 arch/arm/cpu/arm926ejs/sunxi/lowlevel_init.S
> > create mode 100644 arch/arm/cpu/arm926ejs/sunxi/start.c
> > create mode 100644 arch/arm/cpu/arm926ejs/sunxi/timer.c
> > create mode 100644 arch/arm/cpu/arm926ejs/sunxi/u-boot-spl.lds
> > create mode 100644 arch/arm/dts/suniv-f1c100s-licheepi-nano.dts
> > create mode 100644 arch/arm/dts/suniv-f1c100s.dtsi
> > create mode 100644 arch/arm/dts/suniv.dtsi
> > create mode 100644 arch/arm/include/asm/arch-sunxi/dram_suniv.h
> > create mode 100644 arch/arm/mach-sunxi/dram_suniv.c
> > create mode 100644 configs/licheepi_nano_defconfig
> > create mode 100644 configs/licheepi_nano_spiflash_defconfig
> > create mode 100644 include/configs/suniv.h
> > create mode 100644 include/dt-bindings/clock/suniv-ccu.h
> > create mode 100644 include/dt-bindings/reset/suniv-ccu.h
> >
>
>
^ permalink raw reply
* Re: [RFC PATCH 00/10] KVM: selftests: Add support for test-selectable ucall implementations
From: Michael Roth @ 2022-01-04 23:35 UTC (permalink / raw)
To: Sean Christopherson
Cc: Brijesh Singh, kvm, David Hildenbrand, Marc Orr, linux-kselftest,
H . Peter Anvin, Claudio Imbrenda, Shuah Khan, kvmarm,
Nathan Tempelman, Janosch Frank, Marc Zyngier, Joerg Roedel, x86,
Ingo Molnar, Mingwei Zhang, Christian Borntraeger, Tom Lendacky,
Borislav Petkov, Thomas Gleixner, Varad Gautam, Jim Mattson,
Steve Rutherford, linux-kernel, Vitaly Kuznetsov, David Woodhouse
In-Reply-To: <Yc4gcJdhxthBKUUd@google.com>
On Thu, Dec 30, 2021 at 09:11:12PM +0000, Sean Christopherson wrote:
> On Fri, Dec 10, 2021, Michael Roth wrote:
> > To summarize, x86 relies on a ucall based on using PIO intructions to generate
> > an exit to userspace and provide the GVA of a dynamically-allocated ucall
> > struct that resides in guest memory and contains information about how to
> > handle/interpret the exit. This doesn't work for SEV guests for 3 main reasons:
> >
> > 1) The guest memory is generally encrypted during run-time, so the guest
> > needs to ensure the ucall struct is allocated in shared memory.
> > 2) The guest page table is also encrypted, so the address would need to be a
> > GPA instead of a GVA.
> > 3) The guest vCPU register may also be encrypted in the case of
> > SEV-ES/SEV-SNP, so the approach of examining vCPU register state has
> > additional requirements such as requiring guest code to implement a #VC
> > handler that can provide the appropriate registers via a vmgexit.
> >
> > To address these issues, the SEV selftest RFC1 patchset introduced a set of new
> > SEV-specific interfaces that closely mirrored the functionality of
> > ucall()/get_ucall(), but relied on a pre-allocated/static ucall buffer in
> > shared guest memory so it that guest code could pass messages/state to the host
> > by simply writing to this pre-arranged shared memory region and then generating
> > an exit to userspace (via a halt instruction).
> >
> > Paolo suggested instead implementing support for test/guest-specific ucall
> > implementations that could be used as an alternative to the default PIO-based
> > ucall implementations as-needed based on test/guest requirements, while still
> > allowing for tests to use a common set interfaces like ucall()/get_ucall().
>
> This all seems way more complicated than it needs to be. HLT is _worse_ than
> PIO on x86 because it triggers a userspace exit if and only if the local APIC is
> not in-kernel. That is bound to bite someone.
Hmmm, fair point. It's easy for me to just not use in-kernel APIC in
the current SEV tests to avoid the issue, but HLT is being made
available as an available ucall implementation for other tests as well,
and given in-kernel APIC is set up automatically maybe it's not robust
enough.
> not in-kernel. That is bound to bite someone. The only issue with SEV is the
> address, not the VM-Exit mechanism. That doesn't change with SEV-ES, SEV-SNP,
> or TDX, as PIO and HLT will both get reflected as #VC/#VE, i.e. the guest side
> needs to be updated to use VMGEXIT/TDCALL no matter what, at which point having
> the hypercall request PIO emulation is just as easy as requesting HLT.
I'm not aware of any #VC handling needed for HLT in the case of
SEV-ES/SEV-SNP. That was one of the reasons for the SEV tests using
this ucall implementation. Of course, at some point, we'd want full support
for PIO/MMIO/etc. in the #VC handler, but it's not something I'd planned on
adding until after the SEV-SNP tests, since it seems like we'd need to
import a bunch of intruction decoding code from elsewhere in the kernel,
which is a lot of churn that's not immediately necessary for getting at least
some basic tests in place. Since the HLT implementation is only 20 lines of
code it seemed like a reasonable stop-gap until we start getting more CoCo
tests in place. But the in-kernel APIC issue probably needs more
consideration...
Perhaps for *just* PIO, the intruction decoding can be open-coded so it
can be added to the initial #VC handler implementation, which would avoid the
need for HLT implementation. I'll take a look at that.
>
> I also don't like having to differentiate between a "shared" and "regular" ucall.
> I kind of like having to explicitly pass the ucall object being used, but that
> puts undue burden on simple single-vCPU tests.
I tried to avoid it, but I got hung up on that fact that pre-allocating
arrays/lists of ucall structs needs to be done for each VM, and so we'd
end up needing some way for a guest to identify which pool it's ucall
struct should be allocated from. But you've gotten around that by just
sync_global_to_guest()'ing for each pool at the time ucall_init() is
called, so the guest only ever sees it's particular pool. Then the switch
from writing GVA to writing GPA solves the translation problem. Nice.
>
> The inability to read guest private memory is really the only issue, and that can
> be easily solved without completely revamping the ucall framework, and without
> having to update a huge pile of tests to make them place nice with private memory.
I think the first 5 patches in this series are still relevant cleanups
vs. having a complete standalone ucall implementation for each arch, and Andrew
has also already started looking at other header cleanups related to
patch #1, so maybe Paolo would still like to queue those. Would also
provide a better starting point for having a centralized allocator for
the ucall structs, which you hinted at wanting below.
But the subsequent patches that add the ucall_shared() interfaces should
probably be set aside for now in favor of your proposal.
>
> This would also be a good opportunity to clean up the stupidity of tests having to
> manually call ucall_init(), drop the unused/pointless @arg from ucall_init(), and
> maybe even fix arm64's lurking landmine of not being SMP safe (the address is shared
> by all vCPUs).
I thought you *didn't* want to update a huge pile of tests :) I suppose
it's unavoidable, since with your proposal, having something like ucall_init()
being called at some point is required, as opposed to the current
implementation where it is optional. Are you intending to have it be
called automatically by vm_create*()?
>
> To reduce the burden on tests and avoid ordering issues with creating vCPUs,
> allocate a ucall struct for every possible vCPU when the VM is created and stuff
> the GPA of the struct in the struct itself so that the guest can communicate the
> GPA instead of the GVA. Then confidential VMs just need to make all structs shared.
So a separate call like:
ucall_make_shared(vm->ucall_list)
? Might need some good documentation/assertions to make sure it gets
called at the right place for confidential VMs, and may need some extra
hooks in SEV selftest implementation for switching from private to shared
after the memory has already been allocated, but seems reasonable.
>
> If all architectures have a way to access a vCPU ID, the ucall structs could be
> stored as a simple array. If not, a list based allocator would probably suffice.
I think list allocator is nicer, generating #VCs for both the PIO and the
cpuid checks for vCPU lookup seems like a lot of extra noise to sift
through while debugging where an errant test is failing, and doesn't seem to
have any disadvantage vs. an array.
Thanks,
Mike
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply
* Re: [PATCH v5 4/4] KVM: mmu: remove over-aggressive warnings
From: David Stevens @ 2022-01-05 7:14 UTC (permalink / raw)
To: Sean Christopherson
Cc: Wanpeng Li, kvm, Marc Zyngier, Joerg Roedel, linux-kernel,
Paolo Bonzini, Will Deacon, kvmarm, linux-arm-kernel, Jim Mattson
In-Reply-To: <Yc4G23rrSxS59br5@google.com>
On Fri, Dec 31, 2021 at 4:22 AM Sean Christopherson <seanjc@google.com> wrote:
>
> On Mon, Nov 29, 2021, David Stevens wrote:
> > From: David Stevens <stevensd@chromium.org>
> >
> > Remove two warnings that require ref counts for pages to be non-zero, as
> > mapped pfns from follow_pfn may not have an initialized ref count.
> >
> > Signed-off-by: David Stevens <stevensd@chromium.org>
> > ---
> > arch/x86/kvm/mmu/mmu.c | 7 -------
> > virt/kvm/kvm_main.c | 2 +-
> > 2 files changed, 1 insertion(+), 8 deletions(-)
> >
> > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> > index 0626395ff1d9..7c4c7fededf0 100644
> > --- a/arch/x86/kvm/mmu/mmu.c
> > +++ b/arch/x86/kvm/mmu/mmu.c
> > @@ -621,13 +621,6 @@ static int mmu_spte_clear_track_bits(struct kvm *kvm, u64 *sptep)
> >
> > pfn = spte_to_pfn(old_spte);
> >
> > - /*
> > - * KVM does not hold the refcount of the page used by
> > - * kvm mmu, before reclaiming the page, we should
> > - * unmap it from mmu first.
> > - */
> > - WARN_ON(!kvm_is_reserved_pfn(pfn) && !page_count(pfn_to_page(pfn)));
> > -
> > if (is_accessed_spte(old_spte))
> > kvm_set_pfn_accessed(pfn);
> >
> > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > index 16a8a71f20bf..d81edcb3e107 100644
> > --- a/virt/kvm/kvm_main.c
> > +++ b/virt/kvm/kvm_main.c
> > @@ -170,7 +170,7 @@ bool kvm_is_zone_device_pfn(kvm_pfn_t pfn)
> > * the device has been pinned, e.g. by get_user_pages(). WARN if the
> > * page_count() is zero to help detect bad usage of this helper.
>
> Stale comment.
>
> > */
> > - if (!pfn_valid(pfn) || WARN_ON_ONCE(!page_count(pfn_to_page(pfn))))
> > + if (!pfn_valid(pfn) || !page_count(pfn_to_page(pfn)))
>
> Hrm, I know the whole point of this series is to support pages without an elevated
> refcount, but this WARN was extremely helpful in catching several use-after-free
> bugs in the TDP MMU. We talked about burying a slow check behind MMU_WARN_ON, but
> that isn't very helpful because no one runs with MMU_WARN_ON, and this is also a
> type of check that's most useful if it runs in production.
>
> IIUC, this series explicitly disallows using pfns that have a struct page without
> refcounting, and the issue with the WARN here is that kvm_is_zone_device_pfn() is
> called by kvm_is_reserved_pfn() before ensure_pfn_ref() rejects problematic pages,
> i.e. triggers false positive.
>
> So, can't we preserve the use-after-free benefits of the check by moving it to
> where KVM releases the PFN? I.e.
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index fbca2e232e94..675b835525fa 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -2904,15 +2904,19 @@ EXPORT_SYMBOL_GPL(kvm_release_pfn_dirty);
>
> void kvm_set_pfn_dirty(kvm_pfn_t pfn)
> {
> - if (!kvm_is_reserved_pfn(pfn) && !kvm_is_zone_device_pfn(pfn))
> + if (!kvm_is_reserved_pfn(pfn) && !kvm_is_zone_device_pfn(pfn)) {
> + WARN_ON_ONCE(!page_count(pfn_to_page(pfn)));
> SetPageDirty(pfn_to_page(pfn));
> + }
> }
> EXPORT_SYMBOL_GPL(kvm_set_pfn_dirty);
I'm still seeing this warning show up via __handle_changed_spte
calling kvm_set_pfn_dirty:
[ 113.350473] kvm_set_pfn_dirty+0x26/0x3e
[ 113.354861] __handle_changed_spte+0x452/0x4f6
[ 113.359841] __handle_changed_spte+0x452/0x4f6
[ 113.364819] __handle_changed_spte+0x452/0x4f6
[ 113.369790] zap_gfn_range+0x1de/0x27a
[ 113.373992] kvm_tdp_mmu_zap_invalidated_roots+0x64/0xb8
[ 113.379945] kvm_mmu_zap_all_fast+0x18c/0x1c1
[ 113.384827] kvm_page_track_flush_slot+0x55/0x87
[ 113.390000] kvm_set_memslot+0x137/0x455
[ 113.394394] kvm_delete_memslot+0x5c/0x91
[ 113.398888] __kvm_set_memory_region+0x3c0/0x5e6
[ 113.404061] kvm_set_memory_region+0x45/0x74
[ 113.408844] kvm_vm_ioctl+0x563/0x60c
I wasn't seeing it for my particular test case, but the gfn aging code
might trigger the warning as well.
I don't know if setting the dirty/accessed bits in non-refcounted
struct pages is problematic. The only way I can see to avoid it would
be to try to map from the spte to the vma and then check its flags. If
setting the flags is benign, then we'd need to do that lookup to
differentiate the safe case from the use-after-free case. Do you have
any advice on how to handle this?
-David
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply
* Re: [oe] [meta-networking][PATCH v2] ifupdown-ng: Add recipe
From: Otavio Salvador @ 2022-01-05 12:14 UTC (permalink / raw)
To: Alex Kiernan; +Cc: OpenEmbedded Devel List, Alex Kiernan
In-Reply-To: <20220103163754.32439-1-alexk@zuma.ai>
Em seg., 3 de jan. de 2022 às 13:37, Alex Kiernan
<alex.kiernan@gmail.com> escreveu:
>
> ifupdown-ng is a network device manager that is largely compatible with
> Debian ifupdown, BusyBox ifupdown and Cumulus Networks' ifupdown2.
>
> Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
> Signed-off-by: Alex Kiernan <alexk@zuma.ai>
> ---
> Changes in v2:
> - drop merged upstream SBINDIR patch
>
> .../ifupdown-ng/ifupdown-ng_0.11.3.bb | 45 +++++++++++++++++++
> 1 file changed, 45 insertions(+)
> create mode 100644 meta-networking/recipes-support/ifupdown-ng/ifupdown-ng_0.11.3.bb
>
> diff --git a/meta-networking/recipes-support/ifupdown-ng/ifupdown-ng_0.11.3.bb b/meta-networking/recipes-support/ifupdown-ng/ifupdown-ng_0.11.3.bb
> new file mode 100644
...
> +do_compile () {
> + oe_runmake
> +}
> +
> +do_install () {
> + oe_runmake 'DESTDIR=${D}' install
> +}
The do_compile and do_install could be dropped as this is the default.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply
* Re: [PATCH v2 3/5] KVM: SVM: fix race between interrupt delivery and AVIC inhibition
From: Maxim Levitsky @ 2022-01-05 12:15 UTC (permalink / raw)
To: Paolo Bonzini, Sean Christopherson
Cc: kvm, Jim Mattson, Thomas Gleixner, Joerg Roedel,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), Vitaly Kuznetsov,
Borislav Petkov, linux-kernel, Dave Hansen, H. Peter Anvin,
Wanpeng Li, Ingo Molnar
In-Reply-To: <ee5811a7-55a8-158a-7454-7166c045dbc3@redhat.com>
On Wed, 2022-01-05 at 12:54 +0100, Paolo Bonzini wrote:
> On 1/5/22 12:03, Maxim Levitsky wrote:
> > > Hmm, my preference would be to keep the "return -1" even though apicv_active must
> > > be rechecked. That would help highlight that returning "failure" after this point
> > > is not an option as it would result in kvm_lapic_set_irr() being called twice.
> > I don't mind either - this will fix the tracepoint I recently added to report the
> > number of interrupts that were delivered by AVIC/APICv - with this patch,
> > all of them count as such.
>
> Perhaps we can move the tracepoints in the delivery functions. This
> also makes them more precise in the rare case where apicv_active changes
> in the middle of the function.
That is what I was thinking to do as well, but I don't mind returning the 'return -1' as well.
Best regards,
Maxim Levitsky
>
> Paolo
>
^ permalink raw reply
* Re: [oe] [meta-networking][PATCH v2] ifupdown-ng: Add recipe
From: Otavio Salvador @ 2022-01-05 12:16 UTC (permalink / raw)
To: Ross Burton; +Cc: Alex Kiernan, OpenEmbedded Devel List, Alex Kiernan
In-Reply-To: <CAAnfSTvy_xKboMuVNqodt5PduOtdj+tNM+qPc84X-Z=vKtSRWw@mail.gmail.com>
Hello Ross,
Em ter., 4 de jan. de 2022 às 07:28, Ross Burton <ross@burtonini.com> escreveu:
> On Mon, 3 Jan 2022 at 16:40, Alex Kiernan <alex.kiernan@gmail.com> wrote:
> > ifupdown-ng is a network device manager that is largely compatible with
> > Debian ifupdown, BusyBox ifupdown and Cumulus Networks' ifupdown2.
>
> If this is a superior alternative, should this be merged into oe-core
> as the replacement for the existing ifupdown scripts?
I think we could consider it but it'd be interesting to check the size
difference between both so we can have a clear idea on the impact of
it.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply
* Re: [External] RE: Upgrading the components with latest version
From: Jagade, Nachiket @ 2022-01-05 12:17 UTC (permalink / raw)
To: Shanmugam, Dhinesh Kumar, Nagalikar, Shivasharan
Cc: Ankam, Ravindra, Sridhara Murthy, Vinay, S, Ramesh,
Duttagupta, Amitsurjya, meta-ti@lists.yoctoproject.org,
Pabolu, ramgopala
In-Reply-To: <DM5PR07MB3943DF7B09CDEA638E450171814B9@DM5PR07MB3943.namprd07.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 5084 bytes --]
Hi Shiv,
We are working on TI am335x sitara based platform.
We have adopted Yocto build as per your suggestion and created custom distro which is a mix of arago and poky.
Reason is that when we last checked, arago distro did not had latest version of open source packages.
Also some layers were not available in arago and we had to resolve many dependencies while compiling.
We created this custom distro long ago using Dunfell 3.1.2 branch.
Now we want to make a new distro with latest versions of all required packages.
So shall we go with 3.4 Honister or with latest dunfell release 3.1.13? Which release has full ti support for chipset and other drivers ?
What will you suggest to achieve this?
Thanks,
Nachiket
From: Nagalikar, Shivasharan <shivasharan.nagalikar@ti.com<mailto:shivasharan.nagalikar@ti.com>>
Sent: Friday, June 19, 2020 6:19 PM
To: Sridhara Murthy, Vinay <Vinay.SridharaMurthy@Honeywell.com<mailto:Vinay.SridharaMurthy@Honeywell.com>>; Ankam, Ravindra <Ravindra.Ankam@Honeywell.com<mailto:Ravindra.Ankam@Honeywell.com>>
Cc: Shanmugam, Dhinesh Kumar <s-dhinesh@ti.com<mailto:s-dhinesh@ti.com>>
Subject: RE: [External] RE: Upgrading the components with latest version
Hi Ravi/Sridhara,
In that case I suggest adopt to the Yacto build and have your custom components selected as per your requirements. Note that the SDK is provided to cater to larger set of customers for their
quick usage. If there are any specific requirements then its suggested to use the Yacto. Please see if it's very much required to migrate then only upgrade as some packages may not be stable that are available in opensource.
Please refer:
https://processors.wiki.ti.com/index.php/Sitara_Linux_Training:_Getting_Started_with_Openembedded<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprocessors.wiki.ti.com%2Findex.php%2FSitara_Linux_Training%3A_Getting_Started_with_Openembedded&data=04%7C01%7CNachiketRahul.Jagade%40Honeywell.com%7Cbea0534eb52d457f654f08d9d010d959%7C96ece5269c7d48b08daf8b93c90a5d18%7C0%7C0%7C637769593045545960%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=r3tbbnMbtp7ZCy9T4FhxvY21LLoGA6e46e3jyhtVshY%3D&reserved=0>
Best Regards, Shiv
From: Sridhara Murthy, Vinay [mailto:Vinay.SridharaMurthy@Honeywell.com]
Sent: Friday, June 19, 2020 6:08 PM
To: Ankam, Ravindra; Nagalikar, Shivasharan
Cc: Shanmugam, Dhinesh Kumar
Subject: [EXTERNAL] RE: [External] RE: Upgrading the components with latest version
Hi Shiv,
If we provide a list of components, would it be possible for you to provide the updated SDK packages.
Please let us know as this would accelerate for us.
Regards
Vinay
From: Ankam, Ravindra <Ravindra.Ankam@Honeywell.com<mailto:Ravindra.Ankam@Honeywell.com>>
Sent: Friday, June 19, 2020 6:01 PM
To: Nagalikar, Shivasharan <shivasharan.nagalikar@ti.com<mailto:shivasharan.nagalikar@ti.com>>
Cc: Shanmugam, Dhinesh Kumar <s-dhinesh@ti.com<mailto:s-dhinesh@ti.com>>; Sridhara Murthy, Vinay <Vinay.SridharaMurthy@Honeywell.com<mailto:Vinay.SridharaMurthy@Honeywell.com>>
Subject: RE: [External] RE: Upgrading the components with latest version
Hi Shiv,
Thank you for quick response. Unfortunately compiling each individually is complex and also we need to compile updated dependent packages as well.
As I mentioned earlier, we are using TI SDK.
Thanks and regards,
Ravi
From: Nagalikar, Shivasharan <shivasharan.nagalikar@ti.com<mailto:shivasharan.nagalikar@ti.com>>
Sent: Friday, June 19, 2020 12:51 PM
To: Ankam, Ravindra <Ravindra.Ankam@Honeywell.com<mailto:Ravindra.Ankam@Honeywell.com>>
Cc: Shanmugam, Dhinesh Kumar <s-dhinesh@ti.com<mailto:s-dhinesh@ti.com>>; Sridhara Murthy, Vinay <Vinay.SridharaMurthy@Honeywell.com<mailto:Vinay.SridharaMurthy@Honeywell.com>>
Subject: [External] RE: Upgrading the components with latest version
Hi Ravi,
There are two options.
1. If you are using the Yacto build system then you can change the bitbake layers to point to updated version of the below components.
2. If you are using the SDK then you can download the source code of the version you are looking and cross compile with the SDK provided compiler tool chain.
Best Regards, Shiv
From: Ankam, Ravindra [mailto:Ravindra.Ankam@Honeywell.com]
Sent: Friday, June 19, 2020 10:45 AM
To: Nagalikar, Shivasharan
Cc: Shanmugam, Dhinesh Kumar; Sridhara Murthy, Vinay
Subject: [EXTERNAL] Upgrading the components with latest version
Hi Shiv,
We had used the TI SDK 06.01.00.08 version. This SDK has many components not updated with latest version.
We want to update these components to address vulnerabilities in the components by using the latest version.
I have checked with latest TI SDK 06.03.00.106 version but both SDKs have same version for most of the components.
E.g. perl (5.24.4), zlib (3.23.1) etc.
Is there any other way to update these components?
Thanks and regards,
Ravi
[-- Attachment #2: Type: text/html, Size: 14335 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] ACPI / x86: ac and battery device quirk work
From: Hans de Goede @ 2022-01-05 12:17 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Len Brown, ACPI Devel Maling List, Stephan Gerhold
In-Reply-To: <CAJZ5v0g545AoFd1Z==gzJe4cR_n-7PTCUn8QBiLcV1GtUxvW2Q@mail.gmail.com>
Hi,
On 1/4/22 21:03, Rafael J. Wysocki wrote:
> On Tue, Jan 4, 2022 at 4:08 PM Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> Hi Rafael,
>>
>> On 1/4/22 15:52, Rafael J. Wysocki wrote:
>>> On Thu, Dec 30, 2021 at 8:31 PM Hans de Goede <hdegoede@redhat.com> wrote:
>>>>
>>>> Hi Rafael,
>>>>
>>>> Here are 2 patches for ACPI ac and battery device quirk handling on x86,
>>>> the first one refactors the almost identical quirk handling in ac.c and
>>>> battery.c out into a shared helper.
>>>>
>>>> And the 2nd patch then uses the now shared code to also skip / ignore
>>>> ac and battery devices on x86 Android tablets with known broken DSDTs.
>>>>
>>>> Note this applies on top of my:
>>>> "[PATCH v2 0/3] ACPI / pdx86: Add support for x86 Android tablets with broken DSDTs"
>>>> series which you've just merged into your bleeding edge branch.
>>>>
>>>> Regards,
>>>>
>>>> Hans
>>>>
>>>>
>>>> Hans de Goede (2):
>>>> ACPI / x86: Introduce an acpi_quirk_skip_acpi_ac_and_battery() helper
>>>> ACPI / x86: Skip ac and battery devices on x86 Android tablets with
>>>> broken DSDTs
>>>>
>>>> drivers/acpi/ac.c | 43 ++------------------
>>>> drivers/acpi/battery.c | 42 ++------------------
>>>> drivers/acpi/x86/utils.c | 86 ++++++++++++++++++++++++++++++++++++----
>>>> include/acpi/acpi_bus.h | 5 +++
>>>> 4 files changed, 90 insertions(+), 86 deletions(-)
>>>
>>> Applied as 5.17 material.
>>>
>>> Note that the changes here clashed with some recent battery driver
>>> changes, so I needed to resolve the merge conflict. Please double
>>> check the result.
>>
>> Sorry about the conflict.
>>
>> I just checked and something indeed went wrong with the merge.
>>
>> Checking drivers/acpi/battery.c from your bleeding-edge
>> branch there a bunch of now dead code still present there
>> related to setting the now never checked battery_check_pmic
>> global quirk flag:
>>
>> Line 55: "static int battery_check_pmic = 1;"
>>
>> Line 1105-1111:
>>
>> """
>> static int __init
>> battery_do_not_check_pmic_quirk(const struct dmi_system_id *d)
>> {
>> battery_check_pmic = 0;
>> return 0;
>> }
>>
>> """
>>
>> Line 1146-1161:
>>
>> """
>> {
>> /* ECS EF20EA, AXP288 PMIC but uses separate fuel-gauge */
>> .callback = battery_do_not_check_pmic_quirk,
>> .matches = {
>> DMI_MATCH(DMI_PRODUCT_NAME, "EF20EA"),
>> },
>> },
>> {
>> /* Lenovo Ideapad Miix 320, AXP288 PMIC, separate fuel-gauge */
>> .callback = battery_do_not_check_pmic_quirk,
>> .matches = {
>> DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>> DMI_MATCH(DMI_PRODUCT_NAME, "80XF"),
>> DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo MIIX 320-10ICR"),
>> },
>> },
>> """
>>
>> Since this all just sets the now no longer checked battery_check_pmic flag, it
>> is harmless, but all of this can be removed.
>
> OK, I redid the merge, please check again.
This looks good now, thanks.
Regards,
Hans
^ permalink raw reply
* drivers/net/dsa/ocelot/felix.c:1329 felix_check_xtr_pkt() error: uninitialized symbol 'err'.
From: Dan Carpenter @ 2022-01-05 12:18 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 4456 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: c741e49150dbb0c0aebe234389f4aa8b47958fa8
commit: 0a6f17c6ae2116809a7b7eb6dd3eab59ef5460ef net: dsa: tag_ocelot_8021q: add support for PTP timestamping
config: x86_64-randconfig-m001-20211210 (https://download.01.org/0day-ci/archive/20211211/202112110349.5CNAwmu6-lkp(a)intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
smatch warnings:
drivers/net/dsa/ocelot/felix.c:1329 felix_check_xtr_pkt() error: uninitialized symbol 'err'.
vim +/err +1329 drivers/net/dsa/ocelot/felix.c
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1286 static bool felix_check_xtr_pkt(struct ocelot *ocelot, unsigned int ptp_type)
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1287 {
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1288 struct felix *felix = ocelot_to_felix(ocelot);
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1289 int err, grp = 0;
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1290
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1291 if (felix->tag_proto != DSA_TAG_PROTO_OCELOT_8021Q)
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1292 return false;
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1293
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1294 if (!felix->info->quirk_no_xtr_irq)
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1295 return false;
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1296
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1297 if (ptp_type == PTP_CLASS_NONE)
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1298 return false;
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1299
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1300 while (ocelot_read(ocelot, QS_XTR_DATA_PRESENT) & BIT(grp)) {
Can this be false on the first iteration through the loop?
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1301 struct sk_buff *skb;
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1302 unsigned int type;
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1303
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1304 err = ocelot_xtr_poll_frame(ocelot, grp, &skb);
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1305 if (err)
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1306 goto out;
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1307
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1308 /* We trap to the CPU port module all PTP frames, but
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1309 * felix_rxtstamp() only gets called for event frames.
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1310 * So we need to avoid sending duplicate general
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1311 * message frames by running a second BPF classifier
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1312 * here and dropping those.
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1313 */
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1314 __skb_push(skb, ETH_HLEN);
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1315
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1316 type = ptp_classify_raw(skb);
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1317
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1318 __skb_pull(skb, ETH_HLEN);
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1319
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1320 if (type == PTP_CLASS_NONE) {
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1321 kfree_skb(skb);
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1322 continue;
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1323 }
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1324
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1325 netif_rx(skb);
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1326 }
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1327
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1328 out:
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 @1329 if (err < 0)
^^^
That's what triggers the warning.
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1330 ocelot_drain_cpu_queue(ocelot, 0);
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1331
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1332 return true;
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1333 }
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* drivers/net/dsa/ocelot/felix.c:1329 felix_check_xtr_pkt() error: uninitialized symbol 'err'.
From: Dan Carpenter @ 2022-01-05 12:18 UTC (permalink / raw)
To: kbuild, Vladimir Oltean; +Cc: lkp, kbuild-all, linux-kernel, Florian Fainelli
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: c741e49150dbb0c0aebe234389f4aa8b47958fa8
commit: 0a6f17c6ae2116809a7b7eb6dd3eab59ef5460ef net: dsa: tag_ocelot_8021q: add support for PTP timestamping
config: x86_64-randconfig-m001-20211210 (https://download.01.org/0day-ci/archive/20211211/202112110349.5CNAwmu6-lkp@intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
smatch warnings:
drivers/net/dsa/ocelot/felix.c:1329 felix_check_xtr_pkt() error: uninitialized symbol 'err'.
vim +/err +1329 drivers/net/dsa/ocelot/felix.c
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1286 static bool felix_check_xtr_pkt(struct ocelot *ocelot, unsigned int ptp_type)
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1287 {
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1288 struct felix *felix = ocelot_to_felix(ocelot);
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1289 int err, grp = 0;
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1290
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1291 if (felix->tag_proto != DSA_TAG_PROTO_OCELOT_8021Q)
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1292 return false;
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1293
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1294 if (!felix->info->quirk_no_xtr_irq)
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1295 return false;
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1296
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1297 if (ptp_type == PTP_CLASS_NONE)
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1298 return false;
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1299
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1300 while (ocelot_read(ocelot, QS_XTR_DATA_PRESENT) & BIT(grp)) {
Can this be false on the first iteration through the loop?
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1301 struct sk_buff *skb;
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1302 unsigned int type;
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1303
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1304 err = ocelot_xtr_poll_frame(ocelot, grp, &skb);
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1305 if (err)
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1306 goto out;
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1307
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1308 /* We trap to the CPU port module all PTP frames, but
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1309 * felix_rxtstamp() only gets called for event frames.
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1310 * So we need to avoid sending duplicate general
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1311 * message frames by running a second BPF classifier
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1312 * here and dropping those.
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1313 */
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1314 __skb_push(skb, ETH_HLEN);
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1315
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1316 type = ptp_classify_raw(skb);
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1317
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1318 __skb_pull(skb, ETH_HLEN);
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1319
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1320 if (type == PTP_CLASS_NONE) {
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1321 kfree_skb(skb);
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1322 continue;
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1323 }
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1324
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1325 netif_rx(skb);
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1326 }
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1327
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1328 out:
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 @1329 if (err < 0)
^^^
That's what triggers the warning.
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1330 ocelot_drain_cpu_queue(ocelot, 0);
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1331
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1332 return true;
0a6f17c6ae2116 Vladimir Oltean 2021-02-14 1333 }
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH v2 03/11] usb: gadget: f_uac2: Support multiple sampling rates
From: Pavel Hofman @ 2022-01-05 12:20 UTC (permalink / raw)
To: John Keeping
Cc: linux-usb, Ruslan Bilovol, Felipe Balbi, Jerome Brunet,
Julian Scheel, Greg Kroah-Hartman
In-Reply-To: <YdRouHVKWDjea6D3@donbot>
Dne 04. 01. 22 v 16:33 John Keeping napsal(a):
> On Wed, Dec 22, 2021 at 11:01:16AM +0100, Pavel Hofman wrote:
>>
>> Dne 21. 12. 21 v 12:59 John Keeping napsal(a):
>>> On Mon, Dec 20, 2021 at 10:11:22PM +0100, Pavel Hofman wrote:
>>>> From: Julian Scheel <julian@jusst.de>
>>>>
>>>> A list of sampling rates can be specified via configfs. All enabled
>>>> sampling rates are sent to the USB host on request. When the host
>>>> selects a sampling rate the internal active rate is updated.
>>>>
>>>> Config strings with single value stay compatible with the previous version.
>>>>
>>>> Multiple samplerates passed as configuration arrays to g_audio module
>>>> when built for f_uac2.
>>>>
>>>> Signed-off-by: Julian Scheel <julian@jusst.de>
>>>> Signed-off-by: Pavel Hofman <pavel.hofman@ivitera.com>
>>>> ---
> [snip]
>>>> };
>>>> static inline struct f_uac2 *func_to_uac2(struct usb_function *f)
>>>> @@ -166,7 +167,7 @@ static struct uac_clock_source_descriptor in_clk_src_desc = {
>>>> .bDescriptorSubtype = UAC2_CLOCK_SOURCE,
>>>> /* .bClockID = DYNAMIC */
>>>> .bmAttributes = UAC_CLOCK_SOURCE_TYPE_INT_FIXED,
>>>> - .bmControls = (CONTROL_RDONLY << CLK_FREQ_CTRL),
>>>> + .bmControls = (CONTROL_RDWR << CLK_FREQ_CTRL),
>>>> .bAssocTerminal = 0,
>>>> };
>>>> @@ -178,7 +179,7 @@ static struct uac_clock_source_descriptor out_clk_src_desc = {
>>>> .bDescriptorSubtype = UAC2_CLOCK_SOURCE,
>>>> /* .bClockID = DYNAMIC */
>>>> .bmAttributes = UAC_CLOCK_SOURCE_TYPE_INT_FIXED,
>>>> - .bmControls = (CONTROL_RDONLY << CLK_FREQ_CTRL),
>>>> + .bmControls = (CONTROL_RDWR << CLK_FREQ_CTRL),
>>>> .bAssocTerminal = 0,
>>>> };
>>>> @@ -635,12 +636,32 @@ struct cntrl_cur_lay3 {
>>>> };
>>>> struct cntrl_range_lay3 {
>>>> - __le16 wNumSubRanges;
>>>> __le32 dMIN;
>>>> __le32 dMAX;
>>>> __le32 dRES;
>>>> } __packed;
>>>> +#define ranges_size(c) (sizeof(c.wNumSubRanges) + c.wNumSubRanges \
>>>> + * sizeof(struct cntrl_ranges_lay3))
>>>> +
>>>> +struct cntrl_ranges_lay3 {
>>>> + __u16 wNumSubRanges;
>>>> + struct cntrl_range_lay3 r[UAC_MAX_RATES];
>>>> +} __packed;
>>>
>>> These structures are now inconsistent between cntrl_range_lay2 and
>>> cntrl_range_lay3. Would it be better to make these flex arrays? I
>>> guess that will make the code that uses it more complicated, but at the
>>> moment it looks like these are trying to be generic while in reality
>>> being quite specific to the one place that uses them at the moment.
>>
>> I am afraid I do not know exactly how to do that. Please can you post an
>> example? The rate control requires u32 (u16 is too small). Thanks a lot.
>
> After the change in this patch, we end up with:
>
> struct cntrl_range_lay2 {
> __le16 wNumSubRanges;
> __le16 wMIN;
> __le16 wMAX;
> __le16 wRES;
> } __packed;
>
> struct cntrl_range_lay3 {
> __le32 dMIN;
> __le32 dMAX;
> __le32 dRES;
> } __packed;
>
> so there are two structures with similar names but totally different
> structure, which I think risks confusion in the future.
>
> I wonder if DECLARE_UAC2_FEATURE_UNIT_DESCRIPTOR in linux/usb/audio-v2.h
> provides inspiration here, so potentially something like:
>
> #define DECLARE_UAC2_CNTRL_RANGE_LAY3(n) \
> struct uac2_cntrl_range_lay3_##n { \
> __le16 wNumSubRanges; \
> struct cntrl_range_le32 r[n]; \
> } __packed;
>
> DECLARE_UAC2_CNTRL_RANGE_LAY3(UAC_MAX_RATES);
Thanks, I will try to follow your suggestion in the next patchset version.
>
>>>> +static int get_max_srate(const int *srates)
>>>> +{
>>>> + int i, max_srate = 0;
>>>> +
>>>> + for (i = 0; i < UAC_MAX_RATES; i++) {
>>>> + if (srates[i] == 0)
>>>> + break;
>>>> + if (srates[i] > max_srate)
>>>> + max_srate = srates[i];
>>>> + }
>>>> + return max_srate;
>>>> +}
>>>> +
>>>> static int set_ep_max_packet_size(const struct f_uac2_opts *uac2_opts,
>>>> struct usb_endpoint_descriptor *ep_desc,
>>>> enum usb_device_speed speed, bool is_playback)
>>>> @@ -667,11 +688,11 @@ static int set_ep_max_packet_size(const struct f_uac2_opts *uac2_opts,
>>>> if (is_playback) {
>>>> chmask = uac2_opts->p_chmask;
>>>> - srate = uac2_opts->p_srate;
>>>> + srate = get_max_srate(uac2_opts->p_srates);
>>>> ssize = uac2_opts->p_ssize;
>>>> } else {
>>>> chmask = uac2_opts->c_chmask;
>>>> - srate = uac2_opts->c_srate;
>>>> + srate = get_max_srate(uac2_opts->c_srates);
>>>> ssize = uac2_opts->c_ssize;
>>>> }
>>>> @@ -912,10 +933,10 @@ static int afunc_validate_opts(struct g_audio *agdev, struct device *dev)
>>>> } else if ((opts->c_ssize < 1) || (opts->c_ssize > 4)) {
>>>> dev_err(dev, "Error: incorrect capture sample size\n");
>>>> return -EINVAL;
>>>> - } else if (!opts->p_srate) {
>>>> + } else if (!opts->p_srates[0]) {
>>>> dev_err(dev, "Error: incorrect playback sampling rate\n");
>>>> return -EINVAL;
>>>> - } else if (!opts->c_srate) {
>>>> + } else if (!opts->c_srates[0]) {
>>>> dev_err(dev, "Error: incorrect capture sampling rate\n");
>>>> return -EINVAL;
>>>> }
>>>> @@ -1210,7 +1231,8 @@ afunc_bind(struct usb_configuration *cfg, struct usb_function *fn)
>>>> agdev->params.p_chmask = uac2_opts->p_chmask;
>>>> agdev->params.p_srate = uac2_opts->p_srate;
>>>> - agdev->params.p_srates[0] = uac2_opts->p_srate;
>>>> + memcpy(agdev->params.p_srates, uac2_opts->p_srates,
>>>> + sizeof(agdev->params.p_srates));
>>>> agdev->params.p_ssize = uac2_opts->p_ssize;
>>>> if (FUIN_EN(uac2_opts)) {
>>>> agdev->params.p_fu.id = USB_IN_FU_ID;
>>>> @@ -1222,7 +1244,8 @@ afunc_bind(struct usb_configuration *cfg, struct usb_function *fn)
>>>> }
>>>> agdev->params.c_chmask = uac2_opts->c_chmask;
>>>> agdev->params.c_srate = uac2_opts->c_srate;
>>>> - agdev->params.c_srates[0] = uac2_opts->c_srate;
>>>> + memcpy(agdev->params.c_srates, uac2_opts->c_srates,
>>>> + sizeof(agdev->params.c_srates));
>>>> agdev->params.c_ssize = uac2_opts->c_ssize;
>>>> if (FUOUT_EN(uac2_opts)) {
>>>> agdev->params.c_fu.id = USB_OUT_FU_ID;
>>>> @@ -1502,28 +1525,39 @@ in_rq_range(struct usb_function *fn, const struct usb_ctrlrequest *cr)
>>>> u8 entity_id = (w_index >> 8) & 0xff;
>>>> u8 control_selector = w_value >> 8;
>>>> int value = -EOPNOTSUPP;
>>>> - int p_srate, c_srate;
>>>> -
>>>> - p_srate = opts->p_srate;
>>>> - c_srate = opts->c_srate;
>>>> if ((entity_id == USB_IN_CLK_ID) || (entity_id == USB_OUT_CLK_ID)) {
>>>> if (control_selector == UAC2_CS_CONTROL_SAM_FREQ) {
>>>> - struct cntrl_range_lay3 r;
>>>> + struct cntrl_ranges_lay3 rs;
>>>> + int i;
>>>> + int wNumSubRanges = 0;
>>>> + int srate;
>>>> + int *srates;
>>>> if (entity_id == USB_IN_CLK_ID)
>>>> - r.dMIN = cpu_to_le32(p_srate);
>>>> + srates = opts->p_srates;
>>>> else if (entity_id == USB_OUT_CLK_ID)
>>>> - r.dMIN = cpu_to_le32(c_srate);
>>>> + srates = opts->c_srates;
>>>> else
>>>> return -EOPNOTSUPP;
>>>> -
>>>> - r.dMAX = r.dMIN;
>>>> - r.dRES = 0;
>>>> - r.wNumSubRanges = cpu_to_le16(1);
>>>> -
>>>> - value = min_t(unsigned int, w_length, sizeof(r));
>>>> - memcpy(req->buf, &r, value);
>>>> + for (i = 0; i < UAC_MAX_RATES; i++) {
>>>> + srate = srates[i];
>>>> + if (srate == 0)
>>>> + break;
>>>> +
>>>> + rs.r[wNumSubRanges].dMIN = cpu_to_le32(srate);
>>>> + rs.r[wNumSubRanges].dMAX = cpu_to_le32(srate);
>>>> + rs.r[wNumSubRanges].dRES = 0;
>>>> + wNumSubRanges++;
>>>> + dev_dbg(&agdev->gadget->dev,
>>>> + "%s(): clk %d: rate ID %d: %d\n",
>>>> + __func__, entity_id, wNumSubRanges, srate);
>>>> + }
>>>> + rs.wNumSubRanges = cpu_to_le16(wNumSubRanges);
>>>> + value = min_t(unsigned int, w_length, ranges_size(rs));
>>>> + dev_dbg(&agdev->gadget->dev, "%s(): sending %d rates, size %d\n",
>>>> + __func__, rs.wNumSubRanges, value);
>>>> + memcpy(req->buf, &rs, value);
>>>> } else {
>>>> dev_err(&agdev->gadget->dev,
>>>> "%s:%d control_selector=%d TODO!\n",
>>>> @@ -1582,6 +1616,28 @@ ac_rq_in(struct usb_function *fn, const struct usb_ctrlrequest *cr)
>>>> return -EOPNOTSUPP;
>>>> }
>>>> +static void uac2_cs_control_sam_freq(struct usb_ep *ep, struct usb_request *req)
>>>> +{
>>>> + struct usb_function *fn = ep->driver_data;
>>>> + struct g_audio *agdev = func_to_g_audio(fn);
>>>> + struct f_uac2 *uac2 = func_to_uac2(fn);
>>>> + struct f_uac2_opts *opts = g_audio_to_uac2_opts(agdev);
>>>> + u32 val;
>>>> +
>>>> + if (req->actual != 4)
>>>> + return;
>>>> +
>>>> + val = le32_to_cpu(*((u32 *)req->buf));
>>>> + dev_dbg(&agdev->gadget->dev, "%s val: %d.\n", __func__, val);
>>>> + if (uac2->ctl_id == USB_IN_CLK_ID) {
>>>> + opts->p_srate = val;
>>>
>>> Don't you need to hold opts->lock to change this?
>>> I'm not sure opts should be changed here though - that's the setup phase
>>> and this is "current state", so shouldn't it move to struct f_uac2?
>>
>> OK. I moved the current p_srate/c_srate from struct opts to f_uac2,
>> initialized with first value of opts->p_srates/c_srates[0] in afunc_bind.
>> The struct f_uac2 has no lock yet. Should I add the lock mutex to f_uac2 and
>> be locking f_uac2 access here in uac2_cs_control_sam_freq?
>
> Could we move this into struct uac_rtd_params and use the existing lock
> there to guard it?
>
> It would need accessor functions as that structure's local to u_audio.c,
> but there's already u_audio_set_playback_srate() so that isn't a big
> change.
I have already moved p_/c_srate from uac_params to uac_rtd_params in
u_audio.c in the next version of the patchset. But IIUC the currently
selected playback/capture rate is required within f_uac2 too, in
in_rq_cur() in:
if (control_selector == UAC2_CS_CONTROL_SAM_FREQ) {
...
if (entity_id == USB_IN_CLK_ID)
c.dCUR = cpu_to_le32(p_srate);
else if (entity_id == USB_OUT_CLK_ID)
c.dCUR = cpu_to_le32(c_srate);
...
}
Thanks,
Pavel.
^ permalink raw reply
* Re: [PATCH 22/22] drm: rockchip: Add VOP2 driver
From: Sascha Hauer @ 2022-01-05 12:20 UTC (permalink / raw)
To: Andy Yan
Cc: devicetree, Benjamin Gaignard, Sandy Huang, dri-devel, Kever Yang,
linux-rockchip, Michael Riesch, kernel, Peter Geis,
linux-arm-kernel
In-Reply-To: <a0942adc-52c1-811e-0de6-d0616266ce2d@rock-chips.com>
Hi Andy,
On Tue, Jan 04, 2022 at 07:07:23PM +0800, Andy Yan wrote:
>
>
> I thinks we should be very carefully about switch to regmap.
>
> Most of the registers are take effect by frame sync(that is you write the
> config done bit and when vsync interrupt come),
>
> Not only windows register, but also the SYS_CTRL, post processor(VP0/1/2),
> OVERLAY, hdr and so on.
That's why I marked these as nonvolatile, so that reading the registers
comes from the cache. I may have missed some registers, these could be
added when needed.
> > + ret = vop2_win_init(vop2);
> > + if (ret)
> > + return ret;
> Do you have a count about how much time the function vop2_win_init cost ?
No. Why does that matter?
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH 22/22] drm: rockchip: Add VOP2 driver
From: Sascha Hauer @ 2022-01-05 12:20 UTC (permalink / raw)
To: Andy Yan
Cc: dri-devel, linux-arm-kernel, linux-rockchip, devicetree, kernel,
Benjamin Gaignard, Michael Riesch, Sandy Huang,
Heiko Stübner, Peter Geis, Kever Yang
In-Reply-To: <a0942adc-52c1-811e-0de6-d0616266ce2d@rock-chips.com>
Hi Andy,
On Tue, Jan 04, 2022 at 07:07:23PM +0800, Andy Yan wrote:
>
>
> I thinks we should be very carefully about switch to regmap.
>
> Most of the registers are take effect by frame sync(that is you write the
> config done bit and when vsync interrupt come),
>
> Not only windows register, but also the SYS_CTRL, post processor(VP0/1/2),
> OVERLAY, hdr and so on.
That's why I marked these as nonvolatile, so that reading the registers
comes from the cache. I may have missed some registers, these could be
added when needed.
> > + ret = vop2_win_init(vop2);
> > + if (ret)
> > + return ret;
> Do you have a count about how much time the function vop2_win_init cost ?
No. Why does that matter?
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH 22/22] drm: rockchip: Add VOP2 driver
From: Sascha Hauer @ 2022-01-05 12:20 UTC (permalink / raw)
To: Andy Yan
Cc: dri-devel, linux-arm-kernel, linux-rockchip, devicetree, kernel,
Benjamin Gaignard, Michael Riesch, Sandy Huang,
Heiko Stübner, Peter Geis, Kever Yang
In-Reply-To: <a0942adc-52c1-811e-0de6-d0616266ce2d@rock-chips.com>
Hi Andy,
On Tue, Jan 04, 2022 at 07:07:23PM +0800, Andy Yan wrote:
>
>
> I thinks we should be very carefully about switch to regmap.
>
> Most of the registers are take effect by frame sync(that is you write the
> config done bit and when vsync interrupt come),
>
> Not only windows register, but also the SYS_CTRL, post processor(VP0/1/2),
> OVERLAY, hdr and so on.
That's why I marked these as nonvolatile, so that reading the registers
comes from the cache. I may have missed some registers, these could be
added when needed.
> > + ret = vop2_win_init(vop2);
> > + if (ret)
> > + return ret;
> Do you have a count about how much time the function vop2_win_init cost ?
No. Why does that matter?
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* [kvalo-ath:pending 52/56] drivers/net/wireless/ath/ath11k/wmi.c:5651 ath11k_wmi_tlv_fw_stats_data_parse() error: uninitialized symbol 'len'.
From: Dan Carpenter @ 2022-01-05 12:21 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 6873 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git pending
head: 34cbb4043dca455fca888e1ced323e588912b6a2
commit: bc5c448b70ff141f8a2b5cbbab79fba08d7a1be0 [52/56] ath11k: report rssi of each chain to mac80211 for QCA6390/WCN6855
config: riscv-randconfig-m031-20211210 (https://download.01.org/0day-ci/archive/20211211/202112110427.o6xDAKfE-lkp(a)intel.com/config)
compiler: riscv64-linux-gcc (GCC) 11.2.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
New smatch warnings:
drivers/net/wireless/ath/ath11k/wmi.c:5651 ath11k_wmi_tlv_fw_stats_data_parse() error: uninitialized symbol 'len'.
Old smatch warnings:
arch/riscv/include/asm/atomic.h:317 arch_atomic_sub_if_positive() warn: inconsistent indenting
drivers/net/wireless/ath/ath11k/wmi.c:5674 ath11k_wmi_tlv_fw_stats_data_parse() error: uninitialized symbol 'len'.
drivers/net/wireless/ath/ath11k/wmi.c:5695 ath11k_wmi_tlv_fw_stats_data_parse() error: uninitialized symbol 'len'.
vim +/len +5651 drivers/net/wireless/ath/ath11k/wmi.c
bc5c448b70ff14 Wen Gong 2021-12-08 5629 static int ath11k_wmi_tlv_fw_stats_data_parse(struct ath11k_base *ab,
bc5c448b70ff14 Wen Gong 2021-12-08 5630 struct wmi_tlv_fw_stats_parse *parse,
bc5c448b70ff14 Wen Gong 2021-12-08 5631 const void *ptr)
bc5c448b70ff14 Wen Gong 2021-12-08 5632 {
bc5c448b70ff14 Wen Gong 2021-12-08 5633 struct ath11k_fw_stats *stats = parse->stats;
bc5c448b70ff14 Wen Gong 2021-12-08 5634 const struct wmi_stats_event *ev = parse->ev;
bc5c448b70ff14 Wen Gong 2021-12-08 5635 int i;
bc5c448b70ff14 Wen Gong 2021-12-08 5636 const void *data = ptr;
bc5c448b70ff14 Wen Gong 2021-12-08 5637 u32 len;
bc5c448b70ff14 Wen Gong 2021-12-08 5638
bc5c448b70ff14 Wen Gong 2021-12-08 5639 if (!ev) {
bc5c448b70ff14 Wen Gong 2021-12-08 5640 ath11k_warn(ab, "failed to fetch update stats ev");
bc5c448b70ff14 Wen Gong 2021-12-08 5641 return -EPROTO;
bc5c448b70ff14 Wen Gong 2021-12-08 5642 }
d5c65159f28953 Kalle Valo 2019-11-23 5643
d5c65159f28953 Kalle Valo 2019-11-23 5644 stats->stats_id = 0;
d5c65159f28953 Kalle Valo 2019-11-23 5645
d5c65159f28953 Kalle Valo 2019-11-23 5646 for (i = 0; i < ev->num_pdev_stats; i++) {
d5c65159f28953 Kalle Valo 2019-11-23 5647 const struct wmi_pdev_stats *src;
d5c65159f28953 Kalle Valo 2019-11-23 5648 struct ath11k_fw_stats_pdev *dst;
d5c65159f28953 Kalle Valo 2019-11-23 5649
d5c65159f28953 Kalle Valo 2019-11-23 5650 src = data;
bc5c448b70ff14 Wen Gong 2021-12-08 @5651 if (len < sizeof(*src))
"len" is never initialized.
d5c65159f28953 Kalle Valo 2019-11-23 5652 return -EPROTO;
d5c65159f28953 Kalle Valo 2019-11-23 5653
d5c65159f28953 Kalle Valo 2019-11-23 5654 stats->stats_id = WMI_REQUEST_PDEV_STAT;
d5c65159f28953 Kalle Valo 2019-11-23 5655
d5c65159f28953 Kalle Valo 2019-11-23 5656 data += sizeof(*src);
d5c65159f28953 Kalle Valo 2019-11-23 5657 len -= sizeof(*src);
d5c65159f28953 Kalle Valo 2019-11-23 5658
d5c65159f28953 Kalle Valo 2019-11-23 5659 dst = kzalloc(sizeof(*dst), GFP_ATOMIC);
d5c65159f28953 Kalle Valo 2019-11-23 5660 if (!dst)
d5c65159f28953 Kalle Valo 2019-11-23 5661 continue;
d5c65159f28953 Kalle Valo 2019-11-23 5662
d5c65159f28953 Kalle Valo 2019-11-23 5663 ath11k_wmi_pull_pdev_stats_base(&src->base, dst);
d5c65159f28953 Kalle Valo 2019-11-23 5664 ath11k_wmi_pull_pdev_stats_tx(&src->tx, dst);
d5c65159f28953 Kalle Valo 2019-11-23 5665 ath11k_wmi_pull_pdev_stats_rx(&src->rx, dst);
d5c65159f28953 Kalle Valo 2019-11-23 5666 list_add_tail(&dst->list, &stats->pdevs);
d5c65159f28953 Kalle Valo 2019-11-23 5667 }
d5c65159f28953 Kalle Valo 2019-11-23 5668
d5c65159f28953 Kalle Valo 2019-11-23 5669 for (i = 0; i < ev->num_vdev_stats; i++) {
d5c65159f28953 Kalle Valo 2019-11-23 5670 const struct wmi_vdev_stats *src;
d5c65159f28953 Kalle Valo 2019-11-23 5671 struct ath11k_fw_stats_vdev *dst;
d5c65159f28953 Kalle Valo 2019-11-23 5672
d5c65159f28953 Kalle Valo 2019-11-23 5673 src = data;
bc5c448b70ff14 Wen Gong 2021-12-08 5674 if (len < sizeof(*src))
d5c65159f28953 Kalle Valo 2019-11-23 5675 return -EPROTO;
d5c65159f28953 Kalle Valo 2019-11-23 5676
d5c65159f28953 Kalle Valo 2019-11-23 5677 stats->stats_id = WMI_REQUEST_VDEV_STAT;
d5c65159f28953 Kalle Valo 2019-11-23 5678
d5c65159f28953 Kalle Valo 2019-11-23 5679 data += sizeof(*src);
d5c65159f28953 Kalle Valo 2019-11-23 5680 len -= sizeof(*src);
d5c65159f28953 Kalle Valo 2019-11-23 5681
d5c65159f28953 Kalle Valo 2019-11-23 5682 dst = kzalloc(sizeof(*dst), GFP_ATOMIC);
d5c65159f28953 Kalle Valo 2019-11-23 5683 if (!dst)
d5c65159f28953 Kalle Valo 2019-11-23 5684 continue;
d5c65159f28953 Kalle Valo 2019-11-23 5685
d5c65159f28953 Kalle Valo 2019-11-23 5686 ath11k_wmi_pull_vdev_stats(src, dst);
d5c65159f28953 Kalle Valo 2019-11-23 5687 list_add_tail(&dst->list, &stats->vdevs);
d5c65159f28953 Kalle Valo 2019-11-23 5688 }
d5c65159f28953 Kalle Valo 2019-11-23 5689
d5c65159f28953 Kalle Valo 2019-11-23 5690 for (i = 0; i < ev->num_bcn_stats; i++) {
d5c65159f28953 Kalle Valo 2019-11-23 5691 const struct wmi_bcn_stats *src;
d5c65159f28953 Kalle Valo 2019-11-23 5692 struct ath11k_fw_stats_bcn *dst;
d5c65159f28953 Kalle Valo 2019-11-23 5693
d5c65159f28953 Kalle Valo 2019-11-23 5694 src = data;
bc5c448b70ff14 Wen Gong 2021-12-08 5695 if (len < sizeof(*src))
d5c65159f28953 Kalle Valo 2019-11-23 5696 return -EPROTO;
d5c65159f28953 Kalle Valo 2019-11-23 5697
d5c65159f28953 Kalle Valo 2019-11-23 5698 stats->stats_id = WMI_REQUEST_BCN_STAT;
d5c65159f28953 Kalle Valo 2019-11-23 5699
d5c65159f28953 Kalle Valo 2019-11-23 5700 data += sizeof(*src);
d5c65159f28953 Kalle Valo 2019-11-23 5701 len -= sizeof(*src);
d5c65159f28953 Kalle Valo 2019-11-23 5702
d5c65159f28953 Kalle Valo 2019-11-23 5703 dst = kzalloc(sizeof(*dst), GFP_ATOMIC);
d5c65159f28953 Kalle Valo 2019-11-23 5704 if (!dst)
d5c65159f28953 Kalle Valo 2019-11-23 5705 continue;
d5c65159f28953 Kalle Valo 2019-11-23 5706
d5c65159f28953 Kalle Valo 2019-11-23 5707 ath11k_wmi_pull_bcn_stats(src, dst);
d5c65159f28953 Kalle Valo 2019-11-23 5708 list_add_tail(&dst->list, &stats->bcn);
d5c65159f28953 Kalle Valo 2019-11-23 5709 }
d5c65159f28953 Kalle Valo 2019-11-23 5710
d5c65159f28953 Kalle Valo 2019-11-23 5711 return 0;
d5c65159f28953 Kalle Valo 2019-11-23 5712 }
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
^ permalink raw reply
* Re: [PATCH 22/22] drm: rockchip: Add VOP2 driver
From: Sascha Hauer @ 2022-01-05 12:20 UTC (permalink / raw)
To: Andy Yan
Cc: dri-devel, linux-arm-kernel, linux-rockchip, devicetree, kernel,
Benjamin Gaignard, Michael Riesch, Sandy Huang,
Heiko Stübner, Peter Geis, Kever Yang
In-Reply-To: <a0942adc-52c1-811e-0de6-d0616266ce2d@rock-chips.com>
Hi Andy,
On Tue, Jan 04, 2022 at 07:07:23PM +0800, Andy Yan wrote:
>
>
> I thinks we should be very carefully about switch to regmap.
>
> Most of the registers are take effect by frame sync(that is you write the
> config done bit and when vsync interrupt come),
>
> Not only windows register, but also the SYS_CTRL, post processor(VP0/1/2),
> OVERLAY, hdr and so on.
That's why I marked these as nonvolatile, so that reading the registers
comes from the cache. I may have missed some registers, these could be
added when needed.
> > + ret = vop2_win_init(vop2);
> > + if (ret)
> > + return ret;
> Do you have a count about how much time the function vop2_win_init cost ?
No. Why does that matter?
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [kvalo-ath:pending 52/56] drivers/net/wireless/ath/ath11k/wmi.c:5651 ath11k_wmi_tlv_fw_stats_data_parse() error: uninitialized symbol 'len'.
From: Dan Carpenter @ 2022-01-05 12:21 UTC (permalink / raw)
To: kbuild, Wen Gong
Cc: lkp, kbuild-all, Kalle Valo, ath10k, linux-kernel, Kalle Valo
tree: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git pending
head: 34cbb4043dca455fca888e1ced323e588912b6a2
commit: bc5c448b70ff141f8a2b5cbbab79fba08d7a1be0 [52/56] ath11k: report rssi of each chain to mac80211 for QCA6390/WCN6855
config: riscv-randconfig-m031-20211210 (https://download.01.org/0day-ci/archive/20211211/202112110427.o6xDAKfE-lkp@intel.com/config)
compiler: riscv64-linux-gcc (GCC) 11.2.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
New smatch warnings:
drivers/net/wireless/ath/ath11k/wmi.c:5651 ath11k_wmi_tlv_fw_stats_data_parse() error: uninitialized symbol 'len'.
Old smatch warnings:
arch/riscv/include/asm/atomic.h:317 arch_atomic_sub_if_positive() warn: inconsistent indenting
drivers/net/wireless/ath/ath11k/wmi.c:5674 ath11k_wmi_tlv_fw_stats_data_parse() error: uninitialized symbol 'len'.
drivers/net/wireless/ath/ath11k/wmi.c:5695 ath11k_wmi_tlv_fw_stats_data_parse() error: uninitialized symbol 'len'.
vim +/len +5651 drivers/net/wireless/ath/ath11k/wmi.c
bc5c448b70ff14 Wen Gong 2021-12-08 5629 static int ath11k_wmi_tlv_fw_stats_data_parse(struct ath11k_base *ab,
bc5c448b70ff14 Wen Gong 2021-12-08 5630 struct wmi_tlv_fw_stats_parse *parse,
bc5c448b70ff14 Wen Gong 2021-12-08 5631 const void *ptr)
bc5c448b70ff14 Wen Gong 2021-12-08 5632 {
bc5c448b70ff14 Wen Gong 2021-12-08 5633 struct ath11k_fw_stats *stats = parse->stats;
bc5c448b70ff14 Wen Gong 2021-12-08 5634 const struct wmi_stats_event *ev = parse->ev;
bc5c448b70ff14 Wen Gong 2021-12-08 5635 int i;
bc5c448b70ff14 Wen Gong 2021-12-08 5636 const void *data = ptr;
bc5c448b70ff14 Wen Gong 2021-12-08 5637 u32 len;
bc5c448b70ff14 Wen Gong 2021-12-08 5638
bc5c448b70ff14 Wen Gong 2021-12-08 5639 if (!ev) {
bc5c448b70ff14 Wen Gong 2021-12-08 5640 ath11k_warn(ab, "failed to fetch update stats ev");
bc5c448b70ff14 Wen Gong 2021-12-08 5641 return -EPROTO;
bc5c448b70ff14 Wen Gong 2021-12-08 5642 }
d5c65159f28953 Kalle Valo 2019-11-23 5643
d5c65159f28953 Kalle Valo 2019-11-23 5644 stats->stats_id = 0;
d5c65159f28953 Kalle Valo 2019-11-23 5645
d5c65159f28953 Kalle Valo 2019-11-23 5646 for (i = 0; i < ev->num_pdev_stats; i++) {
d5c65159f28953 Kalle Valo 2019-11-23 5647 const struct wmi_pdev_stats *src;
d5c65159f28953 Kalle Valo 2019-11-23 5648 struct ath11k_fw_stats_pdev *dst;
d5c65159f28953 Kalle Valo 2019-11-23 5649
d5c65159f28953 Kalle Valo 2019-11-23 5650 src = data;
bc5c448b70ff14 Wen Gong 2021-12-08 @5651 if (len < sizeof(*src))
"len" is never initialized.
d5c65159f28953 Kalle Valo 2019-11-23 5652 return -EPROTO;
d5c65159f28953 Kalle Valo 2019-11-23 5653
d5c65159f28953 Kalle Valo 2019-11-23 5654 stats->stats_id = WMI_REQUEST_PDEV_STAT;
d5c65159f28953 Kalle Valo 2019-11-23 5655
d5c65159f28953 Kalle Valo 2019-11-23 5656 data += sizeof(*src);
d5c65159f28953 Kalle Valo 2019-11-23 5657 len -= sizeof(*src);
d5c65159f28953 Kalle Valo 2019-11-23 5658
d5c65159f28953 Kalle Valo 2019-11-23 5659 dst = kzalloc(sizeof(*dst), GFP_ATOMIC);
d5c65159f28953 Kalle Valo 2019-11-23 5660 if (!dst)
d5c65159f28953 Kalle Valo 2019-11-23 5661 continue;
d5c65159f28953 Kalle Valo 2019-11-23 5662
d5c65159f28953 Kalle Valo 2019-11-23 5663 ath11k_wmi_pull_pdev_stats_base(&src->base, dst);
d5c65159f28953 Kalle Valo 2019-11-23 5664 ath11k_wmi_pull_pdev_stats_tx(&src->tx, dst);
d5c65159f28953 Kalle Valo 2019-11-23 5665 ath11k_wmi_pull_pdev_stats_rx(&src->rx, dst);
d5c65159f28953 Kalle Valo 2019-11-23 5666 list_add_tail(&dst->list, &stats->pdevs);
d5c65159f28953 Kalle Valo 2019-11-23 5667 }
d5c65159f28953 Kalle Valo 2019-11-23 5668
d5c65159f28953 Kalle Valo 2019-11-23 5669 for (i = 0; i < ev->num_vdev_stats; i++) {
d5c65159f28953 Kalle Valo 2019-11-23 5670 const struct wmi_vdev_stats *src;
d5c65159f28953 Kalle Valo 2019-11-23 5671 struct ath11k_fw_stats_vdev *dst;
d5c65159f28953 Kalle Valo 2019-11-23 5672
d5c65159f28953 Kalle Valo 2019-11-23 5673 src = data;
bc5c448b70ff14 Wen Gong 2021-12-08 5674 if (len < sizeof(*src))
d5c65159f28953 Kalle Valo 2019-11-23 5675 return -EPROTO;
d5c65159f28953 Kalle Valo 2019-11-23 5676
d5c65159f28953 Kalle Valo 2019-11-23 5677 stats->stats_id = WMI_REQUEST_VDEV_STAT;
d5c65159f28953 Kalle Valo 2019-11-23 5678
d5c65159f28953 Kalle Valo 2019-11-23 5679 data += sizeof(*src);
d5c65159f28953 Kalle Valo 2019-11-23 5680 len -= sizeof(*src);
d5c65159f28953 Kalle Valo 2019-11-23 5681
d5c65159f28953 Kalle Valo 2019-11-23 5682 dst = kzalloc(sizeof(*dst), GFP_ATOMIC);
d5c65159f28953 Kalle Valo 2019-11-23 5683 if (!dst)
d5c65159f28953 Kalle Valo 2019-11-23 5684 continue;
d5c65159f28953 Kalle Valo 2019-11-23 5685
d5c65159f28953 Kalle Valo 2019-11-23 5686 ath11k_wmi_pull_vdev_stats(src, dst);
d5c65159f28953 Kalle Valo 2019-11-23 5687 list_add_tail(&dst->list, &stats->vdevs);
d5c65159f28953 Kalle Valo 2019-11-23 5688 }
d5c65159f28953 Kalle Valo 2019-11-23 5689
d5c65159f28953 Kalle Valo 2019-11-23 5690 for (i = 0; i < ev->num_bcn_stats; i++) {
d5c65159f28953 Kalle Valo 2019-11-23 5691 const struct wmi_bcn_stats *src;
d5c65159f28953 Kalle Valo 2019-11-23 5692 struct ath11k_fw_stats_bcn *dst;
d5c65159f28953 Kalle Valo 2019-11-23 5693
d5c65159f28953 Kalle Valo 2019-11-23 5694 src = data;
bc5c448b70ff14 Wen Gong 2021-12-08 5695 if (len < sizeof(*src))
d5c65159f28953 Kalle Valo 2019-11-23 5696 return -EPROTO;
d5c65159f28953 Kalle Valo 2019-11-23 5697
d5c65159f28953 Kalle Valo 2019-11-23 5698 stats->stats_id = WMI_REQUEST_BCN_STAT;
d5c65159f28953 Kalle Valo 2019-11-23 5699
d5c65159f28953 Kalle Valo 2019-11-23 5700 data += sizeof(*src);
d5c65159f28953 Kalle Valo 2019-11-23 5701 len -= sizeof(*src);
d5c65159f28953 Kalle Valo 2019-11-23 5702
d5c65159f28953 Kalle Valo 2019-11-23 5703 dst = kzalloc(sizeof(*dst), GFP_ATOMIC);
d5c65159f28953 Kalle Valo 2019-11-23 5704 if (!dst)
d5c65159f28953 Kalle Valo 2019-11-23 5705 continue;
d5c65159f28953 Kalle Valo 2019-11-23 5706
d5c65159f28953 Kalle Valo 2019-11-23 5707 ath11k_wmi_pull_bcn_stats(src, dst);
d5c65159f28953 Kalle Valo 2019-11-23 5708 list_add_tail(&dst->list, &stats->bcn);
d5c65159f28953 Kalle Valo 2019-11-23 5709 }
d5c65159f28953 Kalle Valo 2019-11-23 5710
d5c65159f28953 Kalle Valo 2019-11-23 5711 return 0;
d5c65159f28953 Kalle Valo 2019-11-23 5712 }
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [kvalo-ath:pending 52/56] drivers/net/wireless/ath/ath11k/wmi.c:5651 ath11k_wmi_tlv_fw_stats_data_parse() error: uninitialized symbol 'len'.
From: Dan Carpenter @ 2022-01-05 12:21 UTC (permalink / raw)
To: kbuild, Wen Gong
Cc: lkp, kbuild-all, Kalle Valo, ath10k, linux-kernel, Kalle Valo
tree: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git pending
head: 34cbb4043dca455fca888e1ced323e588912b6a2
commit: bc5c448b70ff141f8a2b5cbbab79fba08d7a1be0 [52/56] ath11k: report rssi of each chain to mac80211 for QCA6390/WCN6855
config: riscv-randconfig-m031-20211210 (https://download.01.org/0day-ci/archive/20211211/202112110427.o6xDAKfE-lkp@intel.com/config)
compiler: riscv64-linux-gcc (GCC) 11.2.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
New smatch warnings:
drivers/net/wireless/ath/ath11k/wmi.c:5651 ath11k_wmi_tlv_fw_stats_data_parse() error: uninitialized symbol 'len'.
Old smatch warnings:
arch/riscv/include/asm/atomic.h:317 arch_atomic_sub_if_positive() warn: inconsistent indenting
drivers/net/wireless/ath/ath11k/wmi.c:5674 ath11k_wmi_tlv_fw_stats_data_parse() error: uninitialized symbol 'len'.
drivers/net/wireless/ath/ath11k/wmi.c:5695 ath11k_wmi_tlv_fw_stats_data_parse() error: uninitialized symbol 'len'.
vim +/len +5651 drivers/net/wireless/ath/ath11k/wmi.c
bc5c448b70ff14 Wen Gong 2021-12-08 5629 static int ath11k_wmi_tlv_fw_stats_data_parse(struct ath11k_base *ab,
bc5c448b70ff14 Wen Gong 2021-12-08 5630 struct wmi_tlv_fw_stats_parse *parse,
bc5c448b70ff14 Wen Gong 2021-12-08 5631 const void *ptr)
bc5c448b70ff14 Wen Gong 2021-12-08 5632 {
bc5c448b70ff14 Wen Gong 2021-12-08 5633 struct ath11k_fw_stats *stats = parse->stats;
bc5c448b70ff14 Wen Gong 2021-12-08 5634 const struct wmi_stats_event *ev = parse->ev;
bc5c448b70ff14 Wen Gong 2021-12-08 5635 int i;
bc5c448b70ff14 Wen Gong 2021-12-08 5636 const void *data = ptr;
bc5c448b70ff14 Wen Gong 2021-12-08 5637 u32 len;
bc5c448b70ff14 Wen Gong 2021-12-08 5638
bc5c448b70ff14 Wen Gong 2021-12-08 5639 if (!ev) {
bc5c448b70ff14 Wen Gong 2021-12-08 5640 ath11k_warn(ab, "failed to fetch update stats ev");
bc5c448b70ff14 Wen Gong 2021-12-08 5641 return -EPROTO;
bc5c448b70ff14 Wen Gong 2021-12-08 5642 }
d5c65159f28953 Kalle Valo 2019-11-23 5643
d5c65159f28953 Kalle Valo 2019-11-23 5644 stats->stats_id = 0;
d5c65159f28953 Kalle Valo 2019-11-23 5645
d5c65159f28953 Kalle Valo 2019-11-23 5646 for (i = 0; i < ev->num_pdev_stats; i++) {
d5c65159f28953 Kalle Valo 2019-11-23 5647 const struct wmi_pdev_stats *src;
d5c65159f28953 Kalle Valo 2019-11-23 5648 struct ath11k_fw_stats_pdev *dst;
d5c65159f28953 Kalle Valo 2019-11-23 5649
d5c65159f28953 Kalle Valo 2019-11-23 5650 src = data;
bc5c448b70ff14 Wen Gong 2021-12-08 @5651 if (len < sizeof(*src))
"len" is never initialized.
d5c65159f28953 Kalle Valo 2019-11-23 5652 return -EPROTO;
d5c65159f28953 Kalle Valo 2019-11-23 5653
d5c65159f28953 Kalle Valo 2019-11-23 5654 stats->stats_id = WMI_REQUEST_PDEV_STAT;
d5c65159f28953 Kalle Valo 2019-11-23 5655
d5c65159f28953 Kalle Valo 2019-11-23 5656 data += sizeof(*src);
d5c65159f28953 Kalle Valo 2019-11-23 5657 len -= sizeof(*src);
d5c65159f28953 Kalle Valo 2019-11-23 5658
d5c65159f28953 Kalle Valo 2019-11-23 5659 dst = kzalloc(sizeof(*dst), GFP_ATOMIC);
d5c65159f28953 Kalle Valo 2019-11-23 5660 if (!dst)
d5c65159f28953 Kalle Valo 2019-11-23 5661 continue;
d5c65159f28953 Kalle Valo 2019-11-23 5662
d5c65159f28953 Kalle Valo 2019-11-23 5663 ath11k_wmi_pull_pdev_stats_base(&src->base, dst);
d5c65159f28953 Kalle Valo 2019-11-23 5664 ath11k_wmi_pull_pdev_stats_tx(&src->tx, dst);
d5c65159f28953 Kalle Valo 2019-11-23 5665 ath11k_wmi_pull_pdev_stats_rx(&src->rx, dst);
d5c65159f28953 Kalle Valo 2019-11-23 5666 list_add_tail(&dst->list, &stats->pdevs);
d5c65159f28953 Kalle Valo 2019-11-23 5667 }
d5c65159f28953 Kalle Valo 2019-11-23 5668
d5c65159f28953 Kalle Valo 2019-11-23 5669 for (i = 0; i < ev->num_vdev_stats; i++) {
d5c65159f28953 Kalle Valo 2019-11-23 5670 const struct wmi_vdev_stats *src;
d5c65159f28953 Kalle Valo 2019-11-23 5671 struct ath11k_fw_stats_vdev *dst;
d5c65159f28953 Kalle Valo 2019-11-23 5672
d5c65159f28953 Kalle Valo 2019-11-23 5673 src = data;
bc5c448b70ff14 Wen Gong 2021-12-08 5674 if (len < sizeof(*src))
d5c65159f28953 Kalle Valo 2019-11-23 5675 return -EPROTO;
d5c65159f28953 Kalle Valo 2019-11-23 5676
d5c65159f28953 Kalle Valo 2019-11-23 5677 stats->stats_id = WMI_REQUEST_VDEV_STAT;
d5c65159f28953 Kalle Valo 2019-11-23 5678
d5c65159f28953 Kalle Valo 2019-11-23 5679 data += sizeof(*src);
d5c65159f28953 Kalle Valo 2019-11-23 5680 len -= sizeof(*src);
d5c65159f28953 Kalle Valo 2019-11-23 5681
d5c65159f28953 Kalle Valo 2019-11-23 5682 dst = kzalloc(sizeof(*dst), GFP_ATOMIC);
d5c65159f28953 Kalle Valo 2019-11-23 5683 if (!dst)
d5c65159f28953 Kalle Valo 2019-11-23 5684 continue;
d5c65159f28953 Kalle Valo 2019-11-23 5685
d5c65159f28953 Kalle Valo 2019-11-23 5686 ath11k_wmi_pull_vdev_stats(src, dst);
d5c65159f28953 Kalle Valo 2019-11-23 5687 list_add_tail(&dst->list, &stats->vdevs);
d5c65159f28953 Kalle Valo 2019-11-23 5688 }
d5c65159f28953 Kalle Valo 2019-11-23 5689
d5c65159f28953 Kalle Valo 2019-11-23 5690 for (i = 0; i < ev->num_bcn_stats; i++) {
d5c65159f28953 Kalle Valo 2019-11-23 5691 const struct wmi_bcn_stats *src;
d5c65159f28953 Kalle Valo 2019-11-23 5692 struct ath11k_fw_stats_bcn *dst;
d5c65159f28953 Kalle Valo 2019-11-23 5693
d5c65159f28953 Kalle Valo 2019-11-23 5694 src = data;
bc5c448b70ff14 Wen Gong 2021-12-08 5695 if (len < sizeof(*src))
d5c65159f28953 Kalle Valo 2019-11-23 5696 return -EPROTO;
d5c65159f28953 Kalle Valo 2019-11-23 5697
d5c65159f28953 Kalle Valo 2019-11-23 5698 stats->stats_id = WMI_REQUEST_BCN_STAT;
d5c65159f28953 Kalle Valo 2019-11-23 5699
d5c65159f28953 Kalle Valo 2019-11-23 5700 data += sizeof(*src);
d5c65159f28953 Kalle Valo 2019-11-23 5701 len -= sizeof(*src);
d5c65159f28953 Kalle Valo 2019-11-23 5702
d5c65159f28953 Kalle Valo 2019-11-23 5703 dst = kzalloc(sizeof(*dst), GFP_ATOMIC);
d5c65159f28953 Kalle Valo 2019-11-23 5704 if (!dst)
d5c65159f28953 Kalle Valo 2019-11-23 5705 continue;
d5c65159f28953 Kalle Valo 2019-11-23 5706
d5c65159f28953 Kalle Valo 2019-11-23 5707 ath11k_wmi_pull_bcn_stats(src, dst);
d5c65159f28953 Kalle Valo 2019-11-23 5708 list_add_tail(&dst->list, &stats->bcn);
d5c65159f28953 Kalle Valo 2019-11-23 5709 }
d5c65159f28953 Kalle Valo 2019-11-23 5710
d5c65159f28953 Kalle Valo 2019-11-23 5711 return 0;
d5c65159f28953 Kalle Valo 2019-11-23 5712 }
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* [PATCH yocto-autobuilder2] Run oe-selftest-arm jobs on the Arm workers only
From: Ross Burton @ 2022-01-05 12:23 UTC (permalink / raw)
To: yocto
Signed-off-by: Ross Burton <ross.burton@arm.com>
---
config.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/config.py b/config.py
index ea042c6..5e3e7a5 100644
--- a/config.py
+++ b/config.py
@@ -172,6 +172,7 @@ builder_to_workers = {
"oe-selftest-fedora": workers_fedora,
"oe-selftest-opensuse": workers_opensuse,
"oe-selftest-centos": workers_centos,
+ "oe-selftest-arm": workers_arm,
"reproducible-ubuntu": workers_ubuntu,
"reproducible-debian": workers_debian,
"reproducible-fedora": workers_fedora,
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v2 -next] scsi: storvsc: Fix unsigned comparison to zero
From: Wei Liu @ 2022-01-05 12:23 UTC (permalink / raw)
To: Martin K. Petersen
Cc: YueHaibing, kys, haiyangz, sthemmin, wei.liu, decui, jejb,
mikelley, Tianyu.Lan, longli, linux-hyperv, linux-scsi,
linux-kernel
In-Reply-To: <yq135m2zqw1.fsf@ca-mkp.ca.oracle.com>
On Wed, Jan 05, 2022 at 12:41:31AM -0500, Martin K. Petersen wrote:
>
> YueHaibing,
>
> > The unsigned variable sg_count is being assigned a return value
> > from the call to scsi_dma_map() that can return -ENOMEM.
> >
> > Fixes: 743b237c3a7b ("scsi: storvsc: Add Isolation VM support for
> > storvsc driver")
>
> This should probably go through the Hyper-V tree - I presume that's
> where the offending commit is sitting?
Hi Martin
I will pick this up.
Thanks,
Wei.
>
> Otherwise I can take this after -rc1 is out.
>
> --
> Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* Re: [PATCH 2/5] ASoC: rt5640: Allow snd_soc_component_set_jack() to override the codec IRQ
From: Hans de Goede @ 2022-01-05 12:22 UTC (permalink / raw)
To: Mark Brown
Cc: Cezary Rojewski, alsa-devel, Jie Yang, Pierre-Louis Bossart,
Liam Girdwood, Bard Liao
In-Reply-To: <Yc8EMRxc07NphgcR@sirena.org.uk>
Hi,
On 12/31/21 14:22, Mark Brown wrote:
> On Mon, Dec 27, 2021 at 04:33:41PM +0100, Hans de Goede wrote:
>> On some boards where the firmware/fwnode information is in essence
>> read-only (x86 + ACPI boards) the i2c_client for the codec may contain
>> the wrong IRQ or no IRQ at all.
>
> This doesn't apply against current code, please check and resend.
Ok, I will send a v2 rebased on top of broonie/sound.git/for-next
Regards,
Hans
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.