Conor Dooley <conor@xxxxxxxxxx> writes: > On Wed, Feb 28, 2024 at 06:37:08PM +0200, Kalle Valo wrote: >> Marc Gonzalez <mgonzalez@xxxxxxxxxx> writes: > >> > As mentioned in my other reply, there are several msm8998-based >> > devices affected by this issue. Is it not appropriate to consider >> > a kernel-based work-around? >> >> Sorry, not following you here. But I'll try to answer anyway: >> >> I have understood that Device Tree is supposed to describe hardware, not >> software. This is why having this property in DT does not look right >> place for this. For example, if the ath10k firmware is fixed then DT >> would have to be changed even though nothing changed in hardware. But of >> course DT maintainers have the final say. > > I dunno, if the firmware affects the functionality of the hardware in a > way that cannot be detected from the operating system at runtime how > else is it supposed to deal with that? This is why we implemented in ath10k firmware-N.bin with all sorts of meta data about the firmware. There are a lots of different ath10k firmware branches and they have differences which ath10k needs to take into account. firmware-N.bin tells all that info to ath10k runtime, per firmware release. > The devicetree is supposed to describe hardware, yes, but at a certain > point the line between firmware and hardware is invisible :) > Not describing software is mostly about not using it to determine > software policy in the operating system. For me it feels wrong to use DT for handling WLAN firmware differences. For example, what if the ath10k firmware in linux-firmware is fixed? Are we expecting that DT in existing boards is updated? But how is the DT update going to be synced with linux-firmware releases? Sure, in this case it most likely won't matter but as a generic solution this looks very fragile to me. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
