[PATCH 0/2] staging: mt7621-pinctrl: use pinconf-generic in some driver ops

[PATCH 0/2] staging: mt7621-pinctrl: use pinconf-generic in some driver ops

[Sergio Paracuellos]

dt_node_to_map and dt_free_map operations can use pinconf-generic API's
instead of redefine operations in the driver. Make use of them cleaning
a bit driver's code.

Update DT accordly to make sure used bindings property in code match
with the board's DT bindings.

Changes are only compile-tested.

Hope this helps.

Best regards,
    Sergio Paracuellos

Sergio Paracuellos (2):
  staging: mt7621-pinctrl: use pinconf-generic for 'dt_node_to_map' and
    'dt_free_map'
  staging: mt7621-dts: use standard 'groups' instead of 'group' for
    pinctrl bindings

 drivers/staging/mt7621-dts/gbpc1.dts          |  4 +-
 drivers/staging/mt7621-dts/mt7621.dtsi        | 24 +++++------
 drivers/staging/mt7621-pinctrl/Kconfig        |  1 +
 .../staging/mt7621-pinctrl/pinctrl-rt2880.c   | 42 ++-----------------
 4 files changed, 18 insertions(+), 53 deletions(-)

-- 
2.19.1

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/2] staging: mt7621-pinctrl: use pinconf-generic for 'dt_node_to_map' and 'dt_free_map'

[Sergio Paracuellos]

Instead of reimplement afunction to do 'dt_node_to_map' task like
'rt2880_pinctrl_dt_node_to_map' make use of 'pinconf_generic_dt_node_to_map_all'
generic function for this task. Also use its equivalent function for free which
is 'pinconf_generic_dt_free_map'. Remove 'rt2880_pinctrl_dt_node_to_map' function
which is not needed anymore. This decrease a bit driver LOC and make it more
generic. To properly compile this changes 'GENERIC_PINCONF' option is selected
with the driver in its Kconfig file.

Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
---
 drivers/staging/mt7621-pinctrl/Kconfig        |  1 +
 .../staging/mt7621-pinctrl/pinctrl-rt2880.c   | 42 ++-----------------
 2 files changed, 4 insertions(+), 39 deletions(-)

diff --git a/drivers/staging/mt7621-pinctrl/Kconfig b/drivers/staging/mt7621-pinctrl/Kconfig
index 37cf9c3273be..fc3612711307 100644
--- a/drivers/staging/mt7621-pinctrl/Kconfig
+++ b/drivers/staging/mt7621-pinctrl/Kconfig
@@ -2,3 +2,4 @@ config PINCTRL_RT2880
 	bool "RT2800 pinctrl driver for RALINK/Mediatek SOCs"
 	depends on RALINK
 	select PINMUX
+	select GENERIC_PINCONF
diff --git a/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c b/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c
index b663ca43a525..80e7067cfb79 100644
--- a/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c
+++ b/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c
@@ -11,6 +11,7 @@
 #include <linux/of.h>
 #include <linux/pinctrl/pinctrl.h>
 #include <linux/pinctrl/pinconf.h>
+#include <linux/pinctrl/pinconf-generic.h>
 #include <linux/pinctrl/pinmux.h>
 #include <linux/pinctrl/consumer.h>
 #include <linux/pinctrl/machine.h>
@@ -73,49 +74,12 @@ static int rt2880_get_group_pins(struct pinctrl_dev *pctrldev,
 	return 0;
 }
 
-static int rt2880_pinctrl_dt_node_to_map(struct pinctrl_dev *pctrldev,
-					 struct device_node *np_config,
-					 struct pinctrl_map **map,
-					 unsigned int *num_maps)
-{
-	struct rt2880_priv *p = pinctrl_dev_get_drvdata(pctrldev);
-	struct property *prop;
-	const char *function_name, *group_name;
-	int ret;
-	int ngroups = 0;
-	unsigned int reserved_maps = 0;
-
-	for_each_node_with_property(np_config, "group")
-		ngroups++;
-
-	*num_maps = 0;
-	*map = NULL;
-	ret = pinctrl_utils_reserve_map(pctrldev, map, &reserved_maps,
-					num_maps, ngroups);
-	if (ret) {
-		dev_err(p->dev, "can't reserve map: %d\n", ret);
-		return ret;
-	}
-
-	of_property_for_each_string(np_config, "group", prop, group_name) {
-		ret = pinctrl_utils_add_map_mux(pctrldev, map, &reserved_maps,
-						num_maps, group_name,
-						function_name);
-		if (ret) {
-			dev_err(p->dev, "can't add map: %d\n", ret);
-			return ret;
-		}
-	}
-
-	return 0;
-}
-
 static const struct pinctrl_ops rt2880_pctrl_ops = {
 	.get_groups_count	= rt2880_get_group_count,
 	.get_group_name		= rt2880_get_group_name,
 	.get_group_pins		= rt2880_get_group_pins,
-	.dt_node_to_map		= rt2880_pinctrl_dt_node_to_map,
-	.dt_free_map		= pinctrl_utils_free_map,
+	.dt_node_to_map		= pinconf_generic_dt_node_to_map_all,
+	.dt_free_map		= pinconf_generic_dt_free_map,
 };
 
 static int rt2880_pmx_func_count(struct pinctrl_dev *pctrldev)
-- 
2.19.1

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/2] staging: mt7621-dts: use standard 'groups' instead of 'group' for pinctrl bindings

[Sergio Paracuellos]

Pinctrl generic functions looks for standard property 'groups' in DT to get
data and use in the driver. Change all of them.

Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
---
 drivers/staging/mt7621-dts/gbpc1.dts   |  4 ++--
 drivers/staging/mt7621-dts/mt7621.dtsi | 24 ++++++++++++------------
 2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/mt7621-dts/gbpc1.dts b/drivers/staging/mt7621-dts/gbpc1.dts
index 6a1699ce9455..b73385540216 100644
--- a/drivers/staging/mt7621-dts/gbpc1.dts
+++ b/drivers/staging/mt7621-dts/gbpc1.dts
@@ -136,8 +136,8 @@
 &pinctrl {
 	state_default: pinctrl0 {
 		gpio {
-			ralink,group = "wdt", "rgmii2", "uart3";
-			ralink,function = "gpio";
+			groups = "wdt", "rgmii2", "uart3";
+			function = "gpio";
 		};
 	};
 };
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi b/drivers/staging/mt7621-dts/mt7621.dtsi
index 60ddfb7699b0..a63b84015814 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -204,82 +204,82 @@
 
 		i2c_pins: i2c0 {
 			i2c0 {
-				group = "i2c";
+				groups = "i2c";
 				function = "i2c";
 			};
 		};
 
 		spi_pins: spi0 {
 			spi0 {
-				group = "spi";
+				groups = "spi";
 				function = "spi";
 			};
 		};
 
 		uart1_pins: uart1 {
 			uart1 {
-				group = "uart1";
+				groups = "uart1";
 				function = "uart1";
 			};
 		};
 
 		uart2_pins: uart2 {
 			uart2 {
-				group = "uart2";
+				groups = "uart2";
 				function = "uart2";
 			};
 		};
 
 		uart3_pins: uart3 {
 			uart3 {
-				group = "uart3";
+				groups = "uart3";
 				function = "uart3";
 			};
 		};
 
 		rgmii1_pins: rgmii1 {
 			rgmii1 {
-				group = "rgmii1";
+				groups = "rgmii1";
 				function = "rgmii1";
 			};
 		};
 
 		rgmii2_pins: rgmii2 {
 			rgmii2 {
-				group = "rgmii2";
+				groups = "rgmii2";
 				function = "rgmii2";
 			};
 		};
 
 		mdio_pins: mdio0 {
 			mdio0 {
-				group = "mdio";
+				groups = "mdio";
 				function = "mdio";
 			};
 		};
 
 		pcie_pins: pcie0 {
 			pcie0 {
-				group = "pcie";
+				groups = "pcie";
 				function = "pcie rst";
 			};
 		};
 
 		nand_pins: nand0 {
 			spi-nand {
-				group = "spi";
+				groups = "spi";
 				function = "nand1";
 			};
 
 			sdhci-nand {
-				group = "sdhci";
+				groups = "sdhci";
 				function = "nand2";
 			};
 		};
 
 		sdhci_pins: sdhci0 {
 			sdhci0 {
-				group = "sdhci";
+				groups = "sdhci";
 				function = "sdhci";
 			};
 		};
-- 
2.19.1

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 0/2] staging: mt7621-pinctrl: use pinconf-generic in some driver ops

[NeilBrown]

[-- Attachment #1.1: Type: text/plain, Size: 1450 bytes --]

On Mon, Dec 31 2018, Sergio Paracuellos wrote:

> dt_node_to_map and dt_free_map operations can use pinconf-generic API's
> instead of redefine operations in the driver. Make use of them cleaning
> a bit driver's code.
>
> Update DT accordly to make sure used bindings property in code match
> with the board's DT bindings.
>
> Changes are only compile-tested.

Thanks.  This appears to work for me.
It is awkward to test pinctrl changes because the firmware preconfigures
all the pins, so the hardware will work correctly if pinctrl does
nothing.
So I change the dts file to mis-configure some pins for driving LEDs,
and checked that the LEDs broken.  The fixed the dts, and the LEDs
started working again.
I think that will have to do.

Tested-by: NeilBrown <neil@brown.name>

Thanks,
NeilBrown


>
> Hope this helps.
>
> Best regards,
>     Sergio Paracuellos
>
> Sergio Paracuellos (2):
>   staging: mt7621-pinctrl: use pinconf-generic for 'dt_node_to_map' and
>     'dt_free_map'
>   staging: mt7621-dts: use standard 'groups' instead of 'group' for
>     pinctrl bindings
>
>  drivers/staging/mt7621-dts/gbpc1.dts          |  4 +-
>  drivers/staging/mt7621-dts/mt7621.dtsi        | 24 +++++------
>  drivers/staging/mt7621-pinctrl/Kconfig        |  1 +
>  .../staging/mt7621-pinctrl/pinctrl-rt2880.c   | 42 ++-----------------
>  4 files changed, 18 insertions(+), 53 deletions(-)
>
> -- 
> 2.19.1

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 169 bytes --]

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 0/2] staging: mt7621-pinctrl: use pinconf-generic in some driver ops

[Sergio Paracuellos]

On Thu, Jan 3, 2019 at 3:02 AM NeilBrown <neil@brown.name> wrote:
>
> On Mon, Dec 31 2018, Sergio Paracuellos wrote:
>
> > dt_node_to_map and dt_free_map operations can use pinconf-generic API's
> > instead of redefine operations in the driver. Make use of them cleaning
> > a bit driver's code.
> >
> > Update DT accordly to make sure used bindings property in code match
> > with the board's DT bindings.
> >
> > Changes are only compile-tested.
>
> Thanks.  This appears to work for me.
> It is awkward to test pinctrl changes because the firmware preconfigures
> all the pins, so the hardware will work correctly if pinctrl does
> nothing.
> So I change the dts file to mis-configure some pins for driving LEDs,
> and checked that the LEDs broken.  The fixed the dts, and the LEDs
> started working again.
> I think that will have to do.
>
> Tested-by: NeilBrown <neil@brown.name>
>
> Thanks,
> NeilBrown

Cool! Thanks for testing and let me know.

So, I sent this patch which solves a problem:

http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-December/130260.html

And this new patch is generated with that applied. Also this patch
solves the original problem
also and seems the way to go... Should be better to re-do this one
with all the fixed and reported by
tags added as a solution?

What do you prefer, Greg?

Thanks in advance.

Best regards,
    Sergio Paracuellos
>
>
> >
> > Hope this helps.
> >
> > Best regards,
> >     Sergio Paracuellos
> >
> > Sergio Paracuellos (2):
> >   staging: mt7621-pinctrl: use pinconf-generic for 'dt_node_to_map' and
> >     'dt_free_map'
> >   staging: mt7621-dts: use standard 'groups' instead of 'group' for
> >     pinctrl bindings
> >
> >  drivers/staging/mt7621-dts/gbpc1.dts          |  4 +-
> >  drivers/staging/mt7621-dts/mt7621.dtsi        | 24 +++++------
> >  drivers/staging/mt7621-pinctrl/Kconfig        |  1 +
> >  .../staging/mt7621-pinctrl/pinctrl-rt2880.c   | 42 ++-----------------
> >  4 files changed, 18 insertions(+), 53 deletions(-)
> >
> > --
> > 2.19.1
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 0/2] staging: mt7621-pinctrl: use pinconf-generic in some driver ops

[Greg KH]

On Thu, Jan 03, 2019 at 09:23:57AM +0100, Sergio Paracuellos wrote:
> On Thu, Jan 3, 2019 at 3:02 AM NeilBrown <neil@brown.name> wrote:
> >
> > On Mon, Dec 31 2018, Sergio Paracuellos wrote:
> >
> > > dt_node_to_map and dt_free_map operations can use pinconf-generic API's
> > > instead of redefine operations in the driver. Make use of them cleaning
> > > a bit driver's code.
> > >
> > > Update DT accordly to make sure used bindings property in code match
> > > with the board's DT bindings.
> > >
> > > Changes are only compile-tested.
> >
> > Thanks.  This appears to work for me.
> > It is awkward to test pinctrl changes because the firmware preconfigures
> > all the pins, so the hardware will work correctly if pinctrl does
> > nothing.
> > So I change the dts file to mis-configure some pins for driving LEDs,
> > and checked that the LEDs broken.  The fixed the dts, and the LEDs
> > started working again.
> > I think that will have to do.
> >
> > Tested-by: NeilBrown <neil@brown.name>
> >
> > Thanks,
> > NeilBrown
> 
> Cool! Thanks for testing and let me know.
> 
> So, I sent this patch which solves a problem:
> 
> http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-December/130260.html
> 
> And this new patch is generated with that applied. Also this patch
> solves the original problem
> also and seems the way to go... Should be better to re-do this one
> with all the fixed and reported by
> tags added as a solution?
> 
> What do you prefer, Greg?

I'm sorry, but I do not understand.  Is this 2 patch series not
acceptable to merge?  Should I drop it and use some other patch series?
Should I ignore some other patch series?

totally confused,

greg k-h
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 0/2] staging: mt7621-pinctrl: use pinconf-generic in some driver ops

[Sergio Paracuellos]

Hi Greg,

On Fri, Jan 4, 2019 at 9:32 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Thu, Jan 03, 2019 at 09:23:57AM +0100, Sergio Paracuellos wrote:
> > On Thu, Jan 3, 2019 at 3:02 AM NeilBrown <neil@brown.name> wrote:
> > >
> > > On Mon, Dec 31 2018, Sergio Paracuellos wrote:
> > >
> > > > dt_node_to_map and dt_free_map operations can use pinconf-generic API's
> > > > instead of redefine operations in the driver. Make use of them cleaning
> > > > a bit driver's code.
> > > >
> > > > Update DT accordly to make sure used bindings property in code match
> > > > with the board's DT bindings.
> > > >
> > > > Changes are only compile-tested.
> > >
> > > Thanks.  This appears to work for me.
> > > It is awkward to test pinctrl changes because the firmware preconfigures
> > > all the pins, so the hardware will work correctly if pinctrl does
> > > nothing.
> > > So I change the dts file to mis-configure some pins for driving LEDs,
> > > and checked that the LEDs broken.  The fixed the dts, and the LEDs
> > > started working again.
> > > I think that will have to do.
> > >
> > > Tested-by: NeilBrown <neil@brown.name>
> > >
> > > Thanks,
> > > NeilBrown
> >
> > Cool! Thanks for testing and let me know.
> >
> > So, I sent this patch which solves a problem:
> >
> > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-December/130260.html
> >
> > And this new patch is generated with that applied. Also this patch
> > solves the original problem
> > also and seems the way to go... Should be better to re-do this one
> > with all the fixed and reported by
> > tags added as a solution?
> >
> > What do you prefer, Greg?
>
> I'm sorry, but I do not understand.  Is this 2 patch series not
> acceptable to merge?  Should I drop it and use some other patch series?
> Should I ignore some other patch series?

Sorry, let me try to explain it better.
Both this series and the patch in [1] can solve the same problem. Both
of them also work. This series can be applied after the patch in [1].
as a clean up because this series are rebased onto it. So the question
here is you don't have problems to take both of them or if I should
re-do this one with two patches as a solution of the problem and
forget about the one in [1].

[1]: http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-December/130260.html

>
> totally confused,

Hope this clarified things a bit?
>
> greg k-h

Best regards,
    Sergio Paracuellos

Re: [PATCH 0/2] staging: mt7621-pinctrl: use pinconf-generic in some driver ops

[Greg KH]

On Fri, Jan 04, 2019 at 09:55:02AM +0100, Sergio Paracuellos wrote:
> Hi Greg,
> 
> On Fri, Jan 4, 2019 at 9:32 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Thu, Jan 03, 2019 at 09:23:57AM +0100, Sergio Paracuellos wrote:
> > > On Thu, Jan 3, 2019 at 3:02 AM NeilBrown <neil@brown.name> wrote:
> > > >
> > > > On Mon, Dec 31 2018, Sergio Paracuellos wrote:
> > > >
> > > > > dt_node_to_map and dt_free_map operations can use pinconf-generic API's
> > > > > instead of redefine operations in the driver. Make use of them cleaning
> > > > > a bit driver's code.
> > > > >
> > > > > Update DT accordly to make sure used bindings property in code match
> > > > > with the board's DT bindings.
> > > > >
> > > > > Changes are only compile-tested.
> > > >
> > > > Thanks.  This appears to work for me.
> > > > It is awkward to test pinctrl changes because the firmware preconfigures
> > > > all the pins, so the hardware will work correctly if pinctrl does
> > > > nothing.
> > > > So I change the dts file to mis-configure some pins for driving LEDs,
> > > > and checked that the LEDs broken.  The fixed the dts, and the LEDs
> > > > started working again.
> > > > I think that will have to do.
> > > >
> > > > Tested-by: NeilBrown <neil@brown.name>
> > > >
> > > > Thanks,
> > > > NeilBrown
> > >
> > > Cool! Thanks for testing and let me know.
> > >
> > > So, I sent this patch which solves a problem:
> > >
> > > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-December/130260.html
> > >
> > > And this new patch is generated with that applied. Also this patch
> > > solves the original problem
> > > also and seems the way to go... Should be better to re-do this one
> > > with all the fixed and reported by
> > > tags added as a solution?
> > >
> > > What do you prefer, Greg?
> >
> > I'm sorry, but I do not understand.  Is this 2 patch series not
> > acceptable to merge?  Should I drop it and use some other patch series?
> > Should I ignore some other patch series?
> 
> Sorry, let me try to explain it better.
> Both this series and the patch in [1] can solve the same problem. Both
> of them also work. This series can be applied after the patch in [1].
> as a clean up because this series are rebased onto it. So the question
> here is you don't have problems to take both of them or if I should
> re-do this one with two patches as a solution of the problem and
> forget about the one in [1].
> 
> [1]: http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-December/130260.html

How about I drop all of the pending patches from you, and you resend a
new series with whatever you think needs to be applied.  That makes it
very obvious as to what I need to ignore and what I need to
review/apply.

thanks,

greg k-h
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 0/2] staging: mt7621-pinctrl: use pinconf-generic in some driver ops

[Sergio Paracuellos]

On Fri, Jan 4, 2019 at 10:05 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Fri, Jan 04, 2019 at 09:55:02AM +0100, Sergio Paracuellos wrote:
> > Hi Greg,
> >
> > On Fri, Jan 4, 2019 at 9:32 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Thu, Jan 03, 2019 at 09:23:57AM +0100, Sergio Paracuellos wrote:
> > > > On Thu, Jan 3, 2019 at 3:02 AM NeilBrown <neil@brown.name> wrote:
> > > > >
> > > > > On Mon, Dec 31 2018, Sergio Paracuellos wrote:
> > > > >
> > > > > > dt_node_to_map and dt_free_map operations can use pinconf-generic API's
> > > > > > instead of redefine operations in the driver. Make use of them cleaning
> > > > > > a bit driver's code.
> > > > > >
> > > > > > Update DT accordly to make sure used bindings property in code match
> > > > > > with the board's DT bindings.
> > > > > >
> > > > > > Changes are only compile-tested.
> > > > >
> > > > > Thanks.  This appears to work for me.
> > > > > It is awkward to test pinctrl changes because the firmware preconfigures
> > > > > all the pins, so the hardware will work correctly if pinctrl does
> > > > > nothing.
> > > > > So I change the dts file to mis-configure some pins for driving LEDs,
> > > > > and checked that the LEDs broken.  The fixed the dts, and the LEDs
> > > > > started working again.
> > > > > I think that will have to do.
> > > > >
> > > > > Tested-by: NeilBrown <neil@brown.name>
> > > > >
> > > > > Thanks,
> > > > > NeilBrown
> > > >
> > > > Cool! Thanks for testing and let me know.
> > > >
> > > > So, I sent this patch which solves a problem:
> > > >
> > > > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-December/130260.html
> > > >
> > > > And this new patch is generated with that applied. Also this patch
> > > > solves the original problem
> > > > also and seems the way to go... Should be better to re-do this one
> > > > with all the fixed and reported by
> > > > tags added as a solution?
> > > >
> > > > What do you prefer, Greg?
> > >
> > > I'm sorry, but I do not understand.  Is this 2 patch series not
> > > acceptable to merge?  Should I drop it and use some other patch series?
> > > Should I ignore some other patch series?
> >
> > Sorry, let me try to explain it better.
> > Both this series and the patch in [1] can solve the same problem. Both
> > of them also work. This series can be applied after the patch in [1].
> > as a clean up because this series are rebased onto it. So the question
> > here is you don't have problems to take both of them or if I should
> > re-do this one with two patches as a solution of the problem and
> > forget about the one in [1].
> >
> > [1]: http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-December/130260.html
>
> How about I drop all of the pending patches from you, and you resend a
> new series with whatever you think needs to be applied.  That makes it
> very obvious as to what I need to ignore and what I need to
> review/apply.

Ok. I'll send the last series as a fix. Sorry for the noise.
>
> thanks,

>
> greg k-h

Best regards,
    Sergio Paracuellos