Hello Arend, Am Montag, 6. Januar 2025, 14:22:29 Ostafrikanische Zeit schrieb Stefan Dösinger: > Am Montag, 6. Januar 2025, 14:02:17 Ostafrikanische Zeit schrieb Arend van > > Spriel: > > On 1/6/2025 11:37 AM, Stefan Dösinger wrote: > > > Somewhen between 6.10 and 6.11 the driver started to crash on my > > > MacBookPro14,3. The property doesn't exist and 'tmp' remains > > > uninitialized, so we pass a random pointer to devm_kstrdup(). > > > > By the looks of it this is an intel-based platform. Is that correct? So > > does it have a devicetree? I would expect the root node find to fail, > > but apparently is does not. Strange though that root node does not have > > a compatible property. Anyway, the analysis looks sane so ... > > Yes, this is an Intel based MacBook Pro - the 2017 version. I have an updated theory why the codepath was entered: My kernel config had CONFIG_OF (and CONFIG_OF_OVERLAY) enabled. I did not provide any DTBs on boot, but this configuration apparently resulted in an empty root node being found. I also see an empty (0 byte) /proc/device-tree/name file. With CONFIG_OF=n the of.c file isn't compiled in the first place. I think we still want to patch the code. While enabling this option on standard x86 is arguably wrong, the driver shouldn't crash because of it. I don't know where CONFIG_OF=y came from. This is a kernel configuration grown over 15 years. I might have accidentally enabled it in a "make oldconfig" run, or I enabled it 'just in case' without knowing what I was doing - this particular Linux installation is on a USB drive that I plug into many different x86_64 computers, so I enabled pretty much every driver (as a module if possible).
Attachment:
signature.asc
Description: This is a digitally signed message part.
