On 8/3/22 15:56, jim.cromie@xxxxxxxxx wrote: > On Wed, Jul 20, 2022 at 9:32 AM Jim Cromie <jim.cromie@xxxxxxxxx> wrote: >> > >> Hi Jason, Greg, DRM-folk, >> >> This adds 'typed' "class FOO" support to dynamic-debug, where 'typed' >> means either DISJOINT (like drm debug categories), or VERBOSE (like >> nouveau debug-levels). Use it in DRM modules: core, helpers, and in >> drivers i915, amdgpu, nouveau. >> > > This revision fell over, on a conflict with something in drm-MUMBLE > > Error: patch https://urldefense.com/v3/__https://patchwork.freedesktop.org/api/1.0/series/106427/revisions/2/mbox/__;!!GjvTz_vk!UCPl5Uf32cDVwwysMTfaLwoGLWomargFXuR8HjBA3xsUOjxXHXC5hneAkP4iWK91yc-LjjJxWW89-51Z$ > not applied > Applying: dyndbg: fix static_branch manipulation > Applying: dyndbg: fix module.dyndbg handling > Applying: dyndbg: show both old and new in change-info > Applying: dyndbg: reverse module walk in cat control > Applying: dyndbg: reverse module.callsite walk in cat control > Applying: dyndbg: use ESCAPE_SPACE for cat control > Applying: dyndbg: let query-modname override actual module name > Applying: dyndbg: add test_dynamic_debug module > Applying: dyndbg: drop EXPORTed dynamic_debug_exec_queries > > Jason, > those above are decent maintenance patches, particularly the drop export. > It would be nice to trim this unused api this cycle. Hi Jim, Agreed - I was thinking the same thing. Feel free to add Acked-by: Jason Baron <jbaron@xxxxxxxxxx> to those first 9. > > Applying: dyndbg: add class_id to pr_debug callsites > Applying: dyndbg: add __pr_debug_cls for testing > Applying: dyndbg: add DECLARE_DYNDBG_CLASSMAP > Applying: kernel/module: add __dyndbg_classes section > Applying: dyndbg: add ddebug_attach_module_classes > Applying: dyndbg: validate class FOO by checking with module > Applying: dyndbg: add drm.debug style bitmap support > Applying: dyndbg: test DECLARE_DYNDBG_CLASSMAP, sysfs nodes > Applying: doc-dyndbg: describe "class CLASS_NAME" query support > Applying: doc-dyndbg: edit dynamic-debug-howto for brevity, audience > Applying: drm_print: condense enum drm_debug_category > Applying: drm: POC drm on dyndbg - use in core, 2 helpers, 3 drivers. > Applying: drm_print: interpose drm_*dbg with forwarding macros > Applying: drm_print: wrap drm_*_dbg in dyndbg descriptor factory macro > Using index info to reconstruct a base tree... > M drivers/gpu/drm/Kconfig > M drivers/gpu/drm/Makefile > Falling back to patching base and 3-way merge... > Auto-merging drivers/gpu/drm/Makefile > Auto-merging drivers/gpu/drm/Kconfig > CONFLICT (content): Merge conflict in drivers/gpu/drm/Kconfig > error: Failed to merge in the changes. > > > Before I resend, I should sort out that possible conflict > which tree is patchwork applied upon ? > > or was it just transient ? after 5.19 I rebased a copy onto drm-next/drm-next, > and there was nothing to fix - I will revisit presently.. Not sure, if it's a minor conflict maybe Greg KH can sort it when he pulls it in? If not yeah might be important to rebase first...Greg? Thanks, -Jason
