Re: WTF: patch "[PATCH] net: wireless: ti: wl1251 add device tree support" was seriously submitted to be applied to the 5.4-stable tree?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Am 11.12.2019 um 15:24 schrieb Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>:
> 
> On Wed, Dec 11, 2019 at 03:19:19PM +0100, H. Nikolaus Schaller wrote:
>> Hi Greg,
>> I have checked with Documentation/process/stable-kernel-rules.rst but not found out
>> what is failing.
>> 
>> Basically this belongs to a series to fix a bug
>> 
>> 81eef6ca9201 ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel")
>> 
>> that exists since v4.7 and has been hidden by patches which came into the kernel over
>> the time.
> 
> I do not understand at all.
> 
> What does tagging all of these random wifi driver commits with cc:
> stable have to do with an old mmc commit from 4.7-rc1?

v4.7 received the commit ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel").

This commit itself is not bad but has a bad side-effect that it breaks the device tree
and platform quirks of the wl1251 connected to mmc3 port of the OpenPandora.

The reason turned out to be because it now requires a device tree record for the mmc port
while the v4.7 status was to have a mmc port created by a platform quirk - without scanning
the DT.

To be able to fix that we have to
* modify the device tree
* remove the platform quirk for pandora and replace by DT based instantiation of the mmc port
* make sure that what the platform quirk does is still done in the mmc subsystem
* fix some assumptions introduced by later patches which make the device non-detectable

The only alternative I can imagine would be to revert "mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel".

This would fix WiFi for OpenPandora. But - besides you can't simply git revert any more - it
would require fixing much more subsystems than omap_hsmmc + mmc + wl1251 + Pandora device tree.

Yes, it is unfortunate that nobody did care about this bug (although known) before I
recently did a git bisect to identify this commit. So it got buried under a thick layer
of kernel patches so that getting back a working solution touches areas outside the omap_hsmmc
driver.

Does this better explain what the rationale is?

BR and thanks,
Nikolaus Schaller



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux