On 29/02/2024 20:46, Jeff Johnson wrote: > On 2/29/2024 10:40 AM, Conor Dooley wrote: > >> On Wed, Feb 28, 2024 at 06:37:08PM +0200, Kalle Valo wrote: >> >>> Marc Gonzalez 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? >> 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. > > FWIW I've compared ath10k to the out-of-tree Android driver and there > are discrepancies in this area. I've asked the development team that > supports ath10k to provide a recommendation. Hello Jeff, Have you heard back from the dev team? Do they confirm that an issue involving missing MSA_READY notifications was ever noticed? What devices were affected? (All msm8998? A subset of msm8998?) Was the issue eventually fixed? (Probably fixed, otherwise newer devices would be affected) -- Regards.
