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

PATCH [email protected] 2 participants 5 messages Dec 11, 2019

Subsystems (2)

Stable branch TI wilink wireless drivers

lore

Share & tools

lore

[email protected]

author maintainer

2019-12-11 14:06 UTC #0 lore raw

The patch below was submitted to be applied to the 5.4-stable tree.

I fail to see how this patch meets the stable kernel rules as found at Documentation/process/stable-kernel-rules.rst.

I could be totally wrong, and if so, please respond to <[email protected]> and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From 9b8d7072d6552ee5c57e5765f211f267041f9557 Mon Sep 17 00:00:00 2001
From: "H. Nikolaus Schaller" <[email protected]>
Date: Thu, 7 Nov 2019 11:30:35 +0100
Subject: [PATCH] net: wireless: ti: wl1251 add device tree support

We will have the wl1251 defined as a child node of the mmc interface and can read setup for gpios, interrupts and the ti,use-eeprom property from there instead of pdata to be provided by pdata-quirks.

Fixes 81eef6ca9201 ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel")

Signed-off-by H. Nikolaus Schaller <[email protected]>

Acked-by Kalle Valo <[email protected]>

Cc <[email protected]> # v4.7+

[Ulf: Fixed up some complaints from checkpatch]

Signed-off-by Ulf Hansson <[email protected]>

drivers/net/wireless/ti/wl1251/sdio.c +15 -0

index 677f1146ccf0..f1224b948f83 100644
@@ -16,6 +16,9 @@
 #include <linux/irq.h>
 #include <linux/pm_runtime.h>
 #include <linux/gpio.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+#include <linux/of_irq.h>
 
 #include "wl1251.h"

@@ -217,6 +220,7 @@ static int wl1251_sdio_probe(struct sdio_func *func,
 	struct ieee80211_hw *hw;
 	struct wl1251_sdio *wl_sdio;
 	const struct wl1251_platform_data *wl1251_board_data;
+	struct device_node *np = func->dev.of_node;
 
 	hw = wl1251_alloc_hw();
 	if (IS_ERR(hw))

@@ -248,6 +252,17 @@ static int wl1251_sdio_probe(struct sdio_func *func,
 		wl->power_gpio = wl1251_board_data->power_gpio;
 		wl->irq = wl1251_board_data->irq;
 		wl->use_eeprom = wl1251_board_data->use_eeprom;
+	} else if (np) {
+		wl->use_eeprom = of_property_read_bool(np,
+						       "ti,wl1251-has-eeprom");
+		wl->power_gpio = of_get_named_gpio(np, "ti,power-gpio", 0);
+		wl->irq = of_irq_get(np, 0);
+
+		if (wl->power_gpio == -EPROBE_DEFER ||
+		    wl->irq == -EPROBE_DEFER) {
+			ret = -EPROBE_DEFER;
+			goto disable;
+		}
 	}
 
 	if (gpio_is_valid(wl->power_gpio)) {

H. Nikolaus Schaller

2019-12-11 14:19 UTC #1 lore raw

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.

BR and thanks,
Nikolaus Schaller

Quoted 75 lines

Am 11.12.2019 um 15:06 schrieb <[email protected]> <[email protected]>:
The patch below was submitted to be applied to the 5.4-stable tree.
I fail to see how this patch meets the stable kernel rules as found at Documentation/process/stable-kernel-rules.rst.
I could be totally wrong, and if so, please respond to <[email protected]> and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 9b8d7072d6552ee5c57e5765f211f267041f9557 Mon Sep 17 00:00:00 2001
From: "H. Nikolaus Schaller" <[email protected]>
Date: Thu, 7 Nov 2019 11:30:35 +0100
Subject: [PATCH] net: wireless: ti: wl1251 add device tree support
We will have the wl1251 defined as a child node of the mmc interface and can read setup for gpios, interrupts and the ti,use-eeprom property from there instead of pdata to be provided by pdata-quirks.
Fixes 81eef6ca9201 ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel")
Signed-off-by H. Nikolaus Schaller <[email protected]>
Acked-by Kalle Valo <[email protected]>
Cc <[email protected]> # v4.7+
[Ulf: Fixed up some complaints from checkpatch]
Signed-off-by Ulf Hansson <[email protected]>
drivers/net/wireless/ti/wl1251/sdio.c +15 -0
index 677f1146ccf0..f1224b948f83 100644
@@ -16,6 +16,9 @@
 #include <linux/irq.h>
 #include <linux/pm_runtime.h>
 #include <linux/gpio.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+#include <linux/of_irq.h>
 
 #include "wl1251.h"
 
@@ -217,6 +220,7 @@ static int wl1251_sdio_probe(struct sdio_func *func,
 	struct ieee80211_hw *hw;
 	struct wl1251_sdio *wl_sdio;
 	const struct wl1251_platform_data *wl1251_board_data;
+	struct device_node *np = func->dev.of_node;
 
 	hw = wl1251_alloc_hw();
 	if (IS_ERR(hw))
@@ -248,6 +252,17 @@ static int wl1251_sdio_probe(struct sdio_func *func,
 		wl->power_gpio = wl1251_board_data->power_gpio;
 		wl->irq = wl1251_board_data->irq;
 		wl->use_eeprom = wl1251_board_data->use_eeprom;
+	} else if (np) {
+		wl->use_eeprom = of_property_read_bool(np,
+						       "ti,wl1251-has-eeprom");
+		wl->power_gpio = of_get_named_gpio(np, "ti,power-gpio", 0);
+		wl->irq = of_irq_get(np, 0);
+
+		if (wl->power_gpio == -EPROBE_DEFER ||
+		    wl->irq == -EPROBE_DEFER) {
+			ret = -EPROBE_DEFER;
+			goto disable;
+		}
 	}
 
 	if (gpio_is_valid(wl->power_gpio)) {

Greg KH

author maintainer

2019-12-11 14:24 UTC #2 lore raw

Quoted 10 lines · H. Nikolaus Schaller

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?

confused,

greg k-h

H. Nikolaus Schaller

2019-12-11 14:44 UTC #3 lore raw

Quoted 12 lines

Am 11.12.2019 um 15:24 schrieb Greg KH <[email protected]>:
Quoted 8 lines · H. Nikolaus Schaller
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")

Quoted 7 lines

Quoted 2 lines
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

H. Nikolaus Schaller

2019-12-11 15:04 UTC #4 lore raw

In reply to Greg KH

Quoted 12 lines

Am 11.12.2019 um 15:24 schrieb Greg KH <[email protected]>:
Quoted 8 lines · H. Nikolaus Schaller
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")

Quoted 7 lines

Quoted 2 lines
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?

Here is also the cover letter for the series when they were originally submitted to fix linux-next:

https://lore.kernel.org/patchwork/cover/1142016/

Unfortunately that gets lost by the transition to stable.

BR,
Nikolaus Schaller