On Fri, Mar 20, 2026 at 10:41 AM Louis Chauvet
<[email protected]> wrote:
>
> Hi Jim,
>
> Thanks for this new iteration, the whole series is in good shape, and I am
> also interested in the "future work", you can count on me for
> tests/reviews.
>
> This series is very long, but early patches are trivials or tiny fixes
> (4..11), can you apply them to reduce the overall size?
>
lib/ "belongs" to GregKH, so its his call.
IIRC, he has applied low-risk things case-by-case up until rc3,
I dont know his criteria for doing so, or his assessment of
how low-risk the initial patches are, but we're past that milepost,
so its a more-than-usual ask.
> I will add this series on my kernel to test it on "everyday life", I will
> report issues if I have.
yay. that should be helpful
> In addition, can you move the accel and class offset implementation after
> the rest? I think the "basic" part is good and could be merged soon (my
> comments are minor). This way Lukas can start to work on a stable basis.
>
They are already quite late in the stack, do you mean _USE_ after all
the drm patches ?
Im testing v12 now, it has a few noteworthy changes:
(I will work your feedback in soon).
1- Ive found a way to address this TODO-ish item:
drm: restore CONFIG_DRM_USE_DYNAMIC_DEBUG un-BROKEN
Time for some thorough CI.
Also, the previous 18 patches could perhaps be replaced by a single
invocation of DYNDBG_CLASSMAP_USE, from a C-file linked into all drm
drivers & helpers. I didn't find such a file, nor a drm-client
linkage item in the Makefile.
+subdir-ccflags-$(CONFIG_DRM_USE_DYNAMIC_DEBUG) +=
-DDYNAMIC_DEBUG_MODULE -include
$(srctree)/drivers/gpu/drm/drm_dyndbg_classmap_mgr.h
injects that new file into every compilation unit,
the file has a single call: DYNAMIC_DEBUG_CLASSMAP_USE(drm_debug_classes)
with a few #ifdefs.
the approach has the advantages of:
a- no 18 1-liner patches needed
b- no need for future drivers to call the macro explicitly (since its injected)
disadvantages:
c- redundant class-user records (1 per object), 315 extras in i915
d- mysterious, action-at-a-distance
a- is fixable, by introducing a MODULE_MAIN, added once per driver/helper
but thats not much different than adding the DRM_CLASSMAP_USE() itself.
2- Ive split up patch 1, the BOUNDED_SECTION_* patch
a- split BOUNDED_* macros to include/asm-generic/bounded_sections.lds.h
b- include it from vmlinux.lds.h
c- imitate include/asm-generic/codetag.lds.h --> dyndbg.lds.h
d- scripts/module.lds.S includes c), calls MOD_DYNDBG_SECTIONS()
this addresses some lost sections in DRM-drivers, the problem was exposed by 1
> Thanks,
> Louis Chauvet
>
> --
> Louis Chauvet <[email protected]>
