16:25 <gromero> Hi. In the past, on archs like x86 and PPC64, I would find the precise instructions given a kernel call trace by just using objdump -S ./vmlinuz. But now with UEFI and PE I understand that vmlinuz is pure binary. So how can I list the function names and the asm for the instructions in the functions if I only have the image (vmlinuz) and the System.map?

16:31 <krzk> lag: robher: tagr: ukleinek: Lee, you picked up MFD patch which unfortunately depends on PWM. Proper cover letters are still too difficult for Qualcom :/

16:32 <krzk> lag: can you also pick up bindings for PWM? Thread is: https://lore.kernel.org/all/20231005160550.2423075-1-quic_devipriy@quicinc.com/

16:32 <krzk> lag: the patch which is required by MFD is: https://lore.kernel.org/all/20231005160550.2423075-3-quic_devipriy@quicinc.com/

16:33 <krzk> lag: without that patch, next is not happy: mfd/qcom,tcsr.example.dtb: syscon@1937000: pwm@a010: False schema does not allow

16:34 <krzk> alternatively the PWM bits could be applied and go via PWM tree - next will be fine, although there will be some bisectability-window when merged to Linus

16:34 <lag> I can do it with a tagr Ack

16:35 <lag> Does MFD depend on PWM or vice versa?

16:35 <lag> Usually other subsystems depend on MFD

16:35 <lag> (I haven't looked)

16:36 <lag> Oh, it's a binding thing

16:36 <lag> How will that harm bisectablity?

16:37 <ukleinek> it harms dtb_check I assume

16:37 <lag> Who's running dtb_check during a bisect?

16:37 <lag> Should be fine for tagr to pick it up

16:40 <krzk> lag: it affects check of bindings themselve - dt_binding__check

16:40 <krzk> so like a warning, but I agree that it is a minor thing, so can go via tagr as well