Re: [PATCH] wifi: brcmfmac: Check the return value of of_property_read_string_index

["Stefan Dösinger" <stefan@codeweavers.com>]

[-- Attachment #1: Type: text/plain, Size: 1747 bytes --]

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 #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]