Pending Cleanup patches for 4.7

From: Ivan Safonov <[email protected]>

"(thermometer < 0) ? 0 : (thermometer == X)" is equivalent to "thermometer == X" for X >= 0.

Signed-off-by Ivan Safonov <[email protected]>

[Updated commit message]

Signed-off-by Julian Calaby <[email protected]>

From: Ivan Safonov <[email protected]>

"(thermometer < 0) ? 0 : (thermometer == X)" is equivalent to "thermometer == X" for X >= 0.

Signed-off-by Ivan Safonov <[email protected]>

[Updated commit message]

Signed-off-by Julian Calaby <[email protected]>

From: Geliang Tang <[email protected]>

Use to_pci_dev() instead of open-coding it.

Signed-off-by Geliang Tang <[email protected]>

Signed-off-by Julian Calaby <[email protected]>

---
 drivers/net/wireless/intel/ipw2x00/ipw2100.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

From: Geliang Tang <[email protected]>

Use to_delayed_work() instead of open-coding it.

Signed-off-by Geliang Tang <[email protected]>

[Update commit message]

Signed-off-by Julian Calaby <[email protected]>

---
  drivers/net/wireless/realtek/rtlwifi/wifi.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/wireless/realtek/rtlwifi/wifi.h +1 -1

index 554d814..edece53 100644
@@ -2867,7 +2867,7 @@ value to host byte ordering.*/
  	(ppsc->cur_ps_level |= _ps_flg)
 
  #define container_of_dwork_rtl(x, y, z) \
-	container_of(container_of(x, struct delayed_work, work), y, z)
+	container_of(to_delayed_work(x), y, z)
 
  #define FILL_OCTET_STRING(_os, _octet, _len)	\
  		(_os).octet = (u8 *)(_octet);		\

Also remove an unused label.

Quoted 1 line

Also remove an unused label.

Is such a commit message a bit too short?

Hi Markus,

Quoted 3 lines · SF Markus Elfring

Quoted 1 line

Also remove an unused label.

Is such a commit message a bit too short?

I don't think so, but I don't decide these sorts of things.

Does anyone else have an opinion on this?

Quoted 11 lines · Julian Calaby

Hi Markus,

Quoted 3 lines · SF Markus Elfring

Quoted 1 line

Also remove an unused label.

Is such a commit message a bit too short?

I don't think so, but I don't decide these sorts of things.

Does anyone else have an opinion on this?

This is certainly not something where we need to redo the patch but since you asked for the future. A lot of web archives put the subject and the body of the email far apart:

http://marc.info/?l=linux-wireless&m=145826783627087&w=2

lkml.org is the same way.

It makes these types of patch descriptions awkward.

In rsi_send_data_pkt(), the following variables are assigned to before they're used:

Quoted 2 lines

In rsi_send_data_pkt(), the following variables are assigned to before they're used:

Thanks for your interest in this update suggestion.
How do you think about to add the function name also to such a mail subject so that the potential for confusion with an other change can be eventually reduced around the source file "rsi_91x_pkt.c"?

From: Jia-Ju Bai <[email protected]>

When dev_alloc_skb or pci_dma_mapping_error in rtl8180_init_rx_ring fails, the memory allocated by pci_zalloc_consistent is not freed.

This patch fixes the bug by adding pci_free_consistent in error handling code.

Signed-off-by Jia-Ju Bai <[email protected]>

Signed-off-by Julian Calaby <[email protected]>

---

Could someone else please review this?

In particular, immediately after the call to pci_zalloc_coherent(), it fails if the result is null or if '(unsigned long)result & 0xFF'.

Is the second arm of the or statement possible, and if so, should we be pci_free_coherent()ing the result there too?

I've had a quick scout around and this check seems to be particular to realtek drivers.

Thanks,

Julian Calaby

---
 drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c | 4 ++++
 1 file changed, 4 insertions(+)

drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c +4 -1

index c76af5d..a8a23d5 100644
@@ -1018,6 +1018,8 @@ static int rtl8180_init_rx_ring(struct ieee80211_hw *dev)
                dma_addr_t *mapping;
                entry = priv->rx_ring + priv->rx_ring_sz*i;
                if (!skb) {
+                       pci_free_consistent(priv->pdev, priv->rx_ring_sz * 32,
+                                       priv->rx_ring, priv->rx_ring_dma);
                        wiphy_err(dev->wiphy, "Cannot allocate RX skb\n");
                        return -ENOMEM;
                }

@@ -1028,6 +1030,8 @@ static int rtl8180_init_rx_ring(struct ieee80211_hw *dev)
 
                if (pci_dma_mapping_error(priv->pdev, *mapping)) {
                        kfree_skb(skb);
+                       pci_free_consistent(priv->pdev, priv->rx_ring_sz * 32,
+                                       priv->rx_ring, priv->rx_ring_dma);
                        wiphy_err(dev->wiphy, "Cannot map DMA for RX skb\n");
                        return -ENOMEM;
                }
--

2.7.0

Quoted 11 lines · Julian Calaby

From: Jia-Ju Bai <[email protected]>

When dev_alloc_skb or pci_dma_mapping_error in rtl8180_init_rx_ring fails, the memory allocated by pci_zalloc_consistent is not freed.

This patch fixes the bug by adding pci_free_consistent in error handling code.

Signed-off-by Jia-Ju Bai <[email protected]>

Signed-off-by Julian Calaby <[email protected]>

Quoted 3 lines

---

Could someone else please review this?

This patch does address one leak, but the piece of code it changes is totally leaky and IMHO it probably needs to be reworked more deeply, maybe in a single shot. This is why I didn't acked the patch.

BTW if you feel that this could be better than nothing, please feel free to apply it :).

Quoted 5 lines

In particular, immediately after the call to pci_zalloc_coherent(), it fails if the result is null or if '(unsigned long)result & 0xFF'.

Is the second arm of the or statement possible, and if so, should we be pci_free_coherent()ing the result there too?

I honestly don't know if the coherent allocator is supposed to always return page-aligned memory areas (I'm assuming a page wouldn't be smaller than 256 bytes); AFAIK no one ever hit that.

If there are cases/archs where it can really happen, then allocating an oversized memory area, and providing to the HW an aligned pointer inside that area, may be the way to go (IIRC calling pci_set_consistent_dma_mask() with 0xFFFFFF00 does not provides any benefit, but again, I'm not sure).

Either way, If we do that, or if we can trust that it does never really happen, then we can drop the check (or maybe just change it in a BUG_ON() just to be paranoid).

To address your question - if we let this check stay there - then of course we need to take care of freeing the memory whenever the allocator succeeds but that check fails.

Quoted 2 lines

I've had a quick scout around and this check seems to be particular to realtek drivers.

The HW needs DMA rings to be 256-byte aligned. I never tried to see what happens if we break the rule, but I suspect that the HW will attempt DMAs to bad addresses (actually masked with 0xFFFFFF00); If that's the case, then we really need to avoid this..

Hi Andrea,

Quoted 14 lines · Andrea Merello

Quoted 11 lines · Julian Calaby

From: Jia-Ju Bai <[email protected]>

When dev_alloc_skb or pci_dma_mapping_error in rtl8180_init_rx_ring fails, the memory allocated by pci_zalloc_consistent is not freed.

This patch fixes the bug by adding pci_free_consistent in error handling code.

Signed-off-by Jia-Ju Bai <[email protected]>

Signed-off-by Julian Calaby <[email protected]>

Quoted 7 lines

Quoted 3 lines

---

Could someone else please review this?

This patch does address one leak, but the piece of code it changes is totally leaky and IMHO it probably needs to be reworked more deeply, maybe in a single shot. This is why I didn't acked the patch.

Ugh.

I can't work on this as I don't have hardware to test it with, could you (or someone who does) please have a good look at this section of the Realtek drivers (I see a lot of this pattern repeated in them) and craft (a) patch(es) to fix this properly?

Quoted 2 lines

BTW if you feel that this could be better than nothing, please feel free to apply it :).

IMHO this patch makes things better in that there's less options for a leak, however I marked this as "morework" as it clearly doesn't solve the _entire_ problem.

I feel it should be applied as it does make it better, however this isn't my driver and I'd appreciate a nod of approval from someone who knows it better than I do.

Quoted 6 lines

Quoted 5 lines

In particular, immediately after the call to pci_zalloc_coherent(), it fails if the result is null or if '(unsigned long)result & 0xFF'.

Is the second arm of the or statement possible, and if so, should we be pci_free_coherent()ing the result there too?

Quoted 8 lines

I honestly don't know if the coherent allocator is supposed to always return page-aligned memory areas (I'm assuming a page wouldn't be smaller than 256 bytes); AFAIK no one ever hit that.

If there are cases/archs where it can really happen, then allocating an oversized memory area, and providing to the HW an aligned pointer inside that area, may be the way to go (IIRC calling pci_set_consistent_dma_mask() with 0xFFFFFF00 does not provides any benefit, but again, I'm not sure).

I believe that calling *_set_*_dma_mask() is how it's supposed to be done. If this isn't working, then that's a bug elsewhere. IMHO drivers should be able to say "we need a DMA address like *this*" and it's the PCI / DMA code's responsibility to either provide a compatible one or fail. Drivers shouldn't be working around bugs in the services they use.

Quoted 3 lines

Either way, If we do that, or if we can trust that it does never really happen, then we can drop the check (or maybe just change it in a BUG_ON() just to be paranoid).

A WARN_ON() and failing gracefully would be the ideal way to do this IMHO, however it really shouldn't be necessary.

Quoted 3 lines

To address your question - if we let this check stay there - then of course we need to take care of freeing the memory whenever the allocator succeeds but that check fails.

I'll craft a followup patch to add a WARN_ON(), free the memory and fail in this case.

Quoted 7 lines

Quoted 2 lines

I've had a quick scout around and this check seems to be particular to realtek drivers.

The HW needs DMA rings to be 256-byte aligned. I never tried to see what happens if we break the rule, but I suspect that the HW will attempt DMAs to bad addresses (actually masked with 0xFFFFFF00); If that's the case, then we really need to avoid this..

I guess if we got an address like 0x.....048 then we could arguably just tell the hardware we start at 0x.....100, however that's a terrible solution. This really needs to be addressed at the "source" i.e. informing the allocator what our requirements are and if it doesn't produce correct results, fixing it, not working around it in the driver.

Thanks,

--
Julian Calaby

Email: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/

From: Jia-Ju Bai <[email protected]>

When dev_alloc_skb or pci_dma_mapping_error in rtl8180_init_rx_ring fails, the memory allocated by pci_zalloc_consistent is not freed.

This patch fixes the bug by adding pci_free_consistent in error handling code.

Signed-off-by Jia-Ju Bai <[email protected]>

Signed-off-by Julian Calaby <[email protected]>

From: Byeoungwook Kim <[email protected]>

Doing it this way improves readability.

Signed-off-by Byeoungwook Kim <[email protected]>

[Rewrote commit message]

Signed-off-by Julian Calaby <[email protected]>

---

... or does it.

Honesltly, this is only in this list as Byeoungwook asked about it and I can see _some_ sort of reason why it exists.

Larry, if you don't like this, please NACK it and we'll never speak of it again.

Thanks,

Julian Calaby

---
  drivers/net/wireless/realtek/rtlwifi/core.c | 20 ++++++++++++++------
  1 file changed, 14 insertions(+), 6 deletions(-)

drivers/net/wireless/realtek/rtlwifi/core.c +14 -6

index 0f48048..1cf367f 100644
@@ -53,18 +53,26 @@ EXPORT_SYMBOL(channel5g_80m);
 
  void rtl_addr_delay(u32 addr)
  {
-	if (addr == 0xfe)
+	switch (addr) {
+	case 0xfe:
  		msleep(50);
-	else if (addr == 0xfd)
+		break;
+	case 0xfd:
  		msleep(5);
-	else if (addr == 0xfc)
+		break;
+	case 0xfc:
  		msleep(1);
-	else if (addr == 0xfb)
+		break;
+	case 0xfb:
  		usleep_range(50, 100);
-	else if (addr == 0xfa)
+		break;
+	case 0xfa:
  		usleep_range(5, 10);
-	else if (addr == 0xf9)
+		break;
+	case 0xf9:
  		usleep_range(1, 2);
+		break;
+	}
  }
  EXPORT_SYMBOL(rtl_addr_delay);
 

Quoted 19 lines · Julian Calaby

From: Byeoungwook Kim <[email protected]>

Doing it this way improves readability.

Signed-off-by Byeoungwook Kim <[email protected]>

[Rewrote commit message]

Signed-off-by Julian Calaby <[email protected]>

---

... or does it.

Honesltly, this is only in this list as Byeoungwook asked about it and I can see _some_ sort of reason why it exists.

Larry, if you don't like this, please NACK it and we'll never speak of it again.

Quoted 6 lines

Thanks,

Julian Calaby

---
  drivers/net/wireless/realtek/rtlwifi/core.c | 20 ++++++++++++++------
  1 file changed, 14 insertions(+), 6 deletions(-)

I thought I had already NACKed it, but just in case:

NACK.

From: Jia-Ju Bai <[email protected]>

When il4965_hw_nic_init in __il4965_up fails, the memory allocated by iwl4965_sta_alloc_lq in iwl4965_alloc_bcast_station is not freed.

This patches adds il_dealloc_bcast_stations in the error handling code of __il4965_up to fix this problem.

This patch has been tested in real device, and it actually fixes the bug.

Signed-off-by Jia-Ju Bai <[email protected]>

Acked-by Stanislaw Gruszka <[email protected]>

Signed-off-by Julian Calaby <[email protected]>

---
 drivers/net/wireless/intel/iwlegacy/4965-mac.c | 1 +
 1 file changed, 1 insertion(+)

drivers/net/wireless/intel/iwlegacy/4965-mac.c +0 -0

index b75f4ef..30d9dd3 100644

Quoted 9 lines · Julian Calaby

From: Jia-Ju Bai <[email protected]>

When il4965_hw_nic_init in __il4965_up fails, the memory allocated by iwl4965_sta_alloc_lq in iwl4965_alloc_bcast_station is not freed.

This patches adds il_dealloc_bcast_stations in the error handling code of __il4965_up to fix this problem.

This patch has been tested in real device, and it actually fixes the bug.

Could the call trace from the bug be provided ?

Quoted 12 lines

Signed-off-by Jia-Ju Bai <[email protected]>

Acked-by Stanislaw Gruszka <[email protected]>

Signed-off-by Julian Calaby <[email protected]>

---
 drivers/net/wireless/intel/iwlegacy/4965-mac.c | 1 +
 1 file changed, 1 insertion(+)

drivers/net/wireless/intel/iwlegacy/4965-mac.c +0 -0

index b75f4ef..30d9dd3 100644

drivers/net/wireless/intel/iwlegacy/4965-mac.c __il4965_up(struct il_priv *il) · line 5580

Quoted 4 lines

drivers/net/wireless/intel/iwlegacy/4965-mac.c +1 -0

@@ -5577,6 +5577,7 @@ __il4965_up(struct il_priv *il)
      ret = il4965_hw_nic_init(il);
      if (ret) {
              IL_ERR("Unable to init nic\n");
+             il_dealloc_bcast_stations(il);

I missed that before, but now this look suspicious for me.

il_dealloc_bcast_stations() do:

                il->num_stations--;
                BUG_ON(il->num_stations < 0);

But on il4965_alloc_bcast_station() we do not increase il->num_stations Hence either this BUG_ON should be removed or il->num_stations should be increased during allocation.

I don't think you're right. Looking closely at the code, il->num_stations gets incremented in il_prep_station() which is called unconditionally from il4965_alloc_bcast_station().

So I think this and the following patch are fine.

In some of the non-success return paths, the memory allocated by iwl4965_sta_alloc_lq() in iwl4965_alloc_bcast_station() is not freed.

In particular:
- if the card isn't ready after il4965_prepare_card_hw()
- if the card is hardware-rfkilled

In the hardware rfkilled path, the driver enables the rfkill interrupt. When the card is unrfkilled and this interrupt is raised we end up calling il4965_bg_restart() which calls __il4965_up() which calls iwl4965_alloc_bcast_station() again.

Suggested-by Jia-Ju Bai <[email protected]>

Signed-off-by Julian Calaby <[email protected]>

---

This is only compile tested as I don't have compatible hardware. I also don't know the driver enough to know that this is truly correct - however it looks right and I stand by my analysis.

Could someone else please review this?

In some of the non-success return paths, the memory allocated by iwl4965_sta_alloc_lq() in iwl4965_alloc_bcast_station() is not freed.

In particular:
- if the card isn't ready after il4965_prepare_card_hw()
- if the card is hardware-rfkilled

In the hardware rfkilled path, the driver enables the rfkill interrupt. When the card is unrfkilled and this interrupt is raised we end up calling il4965_bg_restart() which calls __il4965_up() which calls iwl4965_alloc_bcast_station() again.

Suggested-by Jia-Ju Bai <[email protected]>

Signed-off-by Julian Calaby <[email protected]>

---

This is only compile tested as I don't have compatible hardware. I also don't know the driver enough to know that this is truly correct - however it looks right and I stand by my analysis.

Could someone else please review this?

From: Markus Elfring <[email protected]>

Rename a jump label according to the current Linux coding style convention.

Signed-off-by Markus Elfring <[email protected]>

[Rewrote commit title]

Signed-off-by Julian Calaby <[email protected]>

---

This was controversial when introduced, however the change is obvious and harmless and is, in the worst case, just churn.

I'm only including this as it meets my criteria for sheparding pending
patches: it's sane, obviously correct or reviewable by me, and doesn't require any work to apply.

This does meet those requirements, however given how controviersial it was when introduced, I'm not expecting people to be enthusiastic about applying it.

Quoted 17 lines · Julian Calaby

From: Markus Elfring <[email protected]>

Rename a jump label according to the current Linux coding style convention.

Signed-off-by Markus Elfring <[email protected]>

[Rewrote commit title]

Signed-off-by Julian Calaby <[email protected]>

---

This was controversial when introduced, however the change is obvious and harmless and is, in the worst case, just churn.

I'm only including this as it meets my criteria for sheparding pending
patches: it's sane, obviously correct or reviewable by me, and doesn't require any work to apply.

Quoted 3 lines

This does meet those requirements, however given how controviersial it was when introduced, I'm not expecting people to be enthusiastic about applying it.

I don't see the sense of that change, NACK

From: Markus Elfring <[email protected]>

Rename a jump label according to the current Linux coding style convention.

Signed-off-by Markus Elfring <[email protected]>

[Rewrote commit title]

Signed-off-by Julian Calaby <[email protected]>

---

This was controversial when introduced, however the change is obvious and harmless and is, in the worst case, just churn.

I'm only including this as it meets my criteria for sheparding pending
patches: it's sane, obviously correct or reviewable by me, and doesn't require any work to apply.

This does meet those requirements, however given how controviersial it was when introduced, I'm not expecting people to be enthusiastic about applying it.

Thanks,

Quoted 21 lines · Julian Calaby

From: Markus Elfring <[email protected]>

Rename a jump label according to the current Linux coding style convention.

Signed-off-by Markus Elfring <[email protected]>

[Rewrote commit title]

Signed-off-by Julian Calaby <[email protected]>

---

This was controversial when introduced, however the change is obvious and harmless and is, in the worst case, just churn.

I'm only including this as it meets my criteria for sheparding pending
patches: it's sane, obviously correct or reviewable by me, and doesn't require any work to apply.

This does meet those requirements, however given how controviersial it was when introduced, I'm not expecting people to be enthusiastic about applying it.

Quoted 1 line

Thanks,

It's a bad idea to mark this sort of patch as controversial. It's bikeshed stuff. Either apply it or don't but don't lets spend any more time thinking about it.

Actual controversial patches have a long term impact.

This is a set of all patches in patchwork which were pending when the 4.6 merge window opened that meet the following criteria:

1. They're sane
2. They're either obviously correct, I can review them, or they've been reviewed or ACK'd by someone else.
3. They don't require any code changes to make them applyable.

That said, if anyone doesn't like any of these patches for any reason, just give me a reason and I'll drop it.

I've split the pending patches into 4 sets as detailed below. All patches have been rebased to apply in order on wireless-drivers-next at wireless-drivers-next-for-davem-2016-03-14.

Quoted 8 lines · Julian Calaby

This is a set of all patches in patchwork which were pending when the 4.6 merge window opened that meet the following criteria:

1. They're sane
2. They're either obviously correct, I can review them, or they've been reviewed or ACK'd by someone else.
3. They don't require any code changes to make them applyable.

Quoted 6 lines

That said, if anyone doesn't like any of these patches for any reason, just give me a reason and I'll drop it.

I've split the pending patches into 4 sets as detailed below. All patches have been rebased to apply in order on wireless-drivers-next at wireless-drivers-next-for-davem-2016-03-14.

Thank you for working on this, this is very helpful.

I have deferred patch 14 and dropped patch 19[1], the rest I'm planning to apply soon. I also tried to remove the original patches from deferred queue by moving them to state "superseded", but I might missed something.

[1] Oddly I cannot find patch 19 from patchwork, I don't know what happened to it. I do see it on the mailing list, though.

Quoted 17 lines · Kalle Valo

Quoted 14 lines · Julian Calaby

This is a set of all patches in patchwork which were pending when the 4.6 merge window opened that meet the following criteria:

1. They're sane
2. They're either obviously correct, I can review them, or they've been reviewed or ACK'd by someone else.
3. They don't require any code changes to make them applyable.

That said, if anyone doesn't like any of these patches for any reason, just give me a reason and I'll drop it.

I've split the pending patches into 4 sets as detailed below. All patches have been rebased to apply in order on wireless-drivers-next at wireless-drivers-next-for-davem-2016-03-14.

Quoted 6 lines

Thank you for working on this, this is very helpful.

I have deferred patch 14 and dropped patch 19[1], the rest I'm planning to apply soon. I also tried to remove the original patches from deferred queue by moving them to state "superseded", but I might missed something.

Quoted 2 lines

[1] Oddly I cannot find patch 19 from patchwork, I don't know what happened to it. I do see it on the mailing list, though.

Actually another nacked patch 16 also has disappeared from patchwork, so I'm not going to apply that either. I'm starting to wonder that maybe you removed these yourself from patchwork?

Hi Kalle,

Quoted 21 lines · Kalle Valo

Quoted 19 lines · Kalle Valo

Quoted 8 lines · Julian Calaby

This is a set of all patches in patchwork which were pending when the 4.6 merge window opened that meet the following criteria:

1. They're sane
2. They're either obviously correct, I can review them, or they've been reviewed or ACK'd by someone else.
3. They don't require any code changes to make them applyable.

Quoted 6 lines

That said, if anyone doesn't like any of these patches for any reason, just give me a reason and I'll drop it.

I've split the pending patches into 4 sets as detailed below. All patches have been rebased to apply in order on wireless-drivers-next at wireless-drivers-next-for-davem-2016-03-14.

Thank you for working on this, this is very helpful.

Quoted 4 lines

Quoted 4 lines

I have deferred patch 14 and dropped patch 19[1], the rest I'm planning to apply soon. I also tried to remove the original patches from deferred queue by moving them to state "superseded", but I might missed something.

I'll check that later and give you a list of patchwork URLs for anything you missed.

Quoted 7 lines · Julian Calaby

Hi Kalle,

Quoted 4 lines · Kalle Valo

Quoted 2 lines · Kalle Valo

Thank you for working on this, this is very helpful.

Quoted 7 lines

Quoted 4 lines

Quoted 4 lines

I have deferred patch 14 and dropped patch 19[1], the rest I'm planning to apply soon. I also tried to remove the original patches from deferred queue by moving them to state "superseded", but I might missed something.

I'll check that later and give you a list of patchwork URLs for anything you missed.

Ok, from the bundles I initially produced, you missed the following:
https://patchwork.kernel.org/patch/7939701/
https://patchwork.kernel.org/patch/8003841/
https://patchwork.kernel.org/patch/8049041/
https://patchwork.kernel.org/patch/8049011/
https://patchwork.kernel.org/patch/7940021/
https://patchwork.kernel.org/patch/8040161/
https://patchwork.kernel.org/patch/8040181/
https://patchwork.kernel.org/patch/8197881/

And this one has the status "changes requested", however I resubmitted it as patch #15 without the stupid bits and you applied it:
https://patchwork.kernel.org/patch/8040201/

Beyond that, here's some earlier versions of the patches I picked up:
https://patchwork.kernel.org/patch/8197051/
https://patchwork.kernel.org/patch/7993931/
https://patchwork.kernel.org/patch/8040201/

This one should be dropped as it's too awful for me to endorse:
https://patchwork.kernel.org/patch/7940001/

And this one is obsolete as it's already been applied in some form:
https://patchwork.kernel.org/patch/8197071/

(If it'd make it easier for you, I can throw these all in a bundle.)

I'll poke people for reviews for patch 14 and there's also a patch I missed in my first run-through that applies without changes, so I'll give it a reviewed-by so it's back on your radar.

Quoted 6 lines

Quoted 2 lines

[1] Oddly I cannot find patch 19 from patchwork, I don't know what happened to it. I do see it on the mailing list, though.

Actually another nacked patch 16 also has disappeared from patchwork, so I'm not going to apply that either. I'm starting to wonder that maybe you removed these yourself from patchwork?

I did do that: I updated both to "Rejected" when people NACKed them.

Should I not have done that? I thought I was making things easier for you.