Removal of GENERIC_GPIO breaks -next

Removal of GENERIC_GPIO breaks -next

[Alexandre Courbot]

Hi Stephen,

It seems like the last few patches I pushed to my branch are going to
break powerpc/85xx due to a merge issue. I have tried to warn you by
email today but maybe you haven't read it yet.

arch/powerpc/platforms/85xx/Kconfig has a "select GENERIC_GPIO" which
will cause compilation breakage because I removed the GENERIC_GPIO
config option for all platforms. This line should be removed by my
"Convert selectors of GENERIC_GPIO to GPIOLIB" patch, but this line
slipped in between and is thus still here.

Also arch/arc/plat-tb10x/Kconfig now defines GENERIC_GPIO, this will
not cause breakage but should not be here anymore (ideally removed by
the "Remove GENERIC_GPIO config option" patch)

Apart from these two issues, things seem to have gone fine, but I'm
not sure how they should be addressed and by who?

Thanks,
Alex.

Re: Removal of GENERIC_GPIO breaks -next

[Christian Ruppert]

Hi Alexandre and Stephen,

Concerning the arch/arc/plat-tb10x/Kconfig issue, I already have a patch
pending which will select PINCTRL_TB10X and GPIO_TB10X for the TB10x
platform as soon as both drivers are accepted into the kernel. Both
drivers were submitted to lkml last week, see
http://www.spinics.net/lists/kernel/msg1515239.html and
http://www.spinics.net/lists/kernel/msg1515240.html.

I suggest to add the removal of GENERIC_GPIO to that patch and arrange
with Vineet to push it through the normal arc upstream when the TB10x
pinctrl/gpio drivers show up in linux-next. Alternatively, an
independent patch could be produced and applied either through the same
channel or sent to this list. Tell me what you prefer.

Greetings,
  Christian

On Wed, Apr 17, 2013 at 07:37:33PM +0900, Alexandre Courbot wrote:
> Hi Stephen,
> 
> It seems like the last few patches I pushed to my branch are going to
> break powerpc/85xx due to a merge issue. I have tried to warn you by
> email today but maybe you haven't read it yet.
> 
> arch/powerpc/platforms/85xx/Kconfig has a "select GENERIC_GPIO" which
> will cause compilation breakage because I removed the GENERIC_GPIO
> config option for all platforms. This line should be removed by my
> "Convert selectors of GENERIC_GPIO to GPIOLIB" patch, but this line
> slipped in between and is thus still here.
> 
> Also arch/arc/plat-tb10x/Kconfig now defines GENERIC_GPIO, this will
> not cause breakage but should not be here anymore (ideally removed by
> the "Remove GENERIC_GPIO config option" patch)
> 
> Apart from these two issues, things seem to have gone fine, but I'm
> not sure how they should be addressed and by who?
> 
> Thanks,
> Alex.

-- 
  Christian Ruppert              ,          <christian.ruppert@abilis.com>
                                /|
  Tel: +41/(0)22 816 19-42     //|                 3, Chemin du Pré-Fleuri
                             _// | bilis Systems   CH-1228 Plan-les-Ouates

Re: Removal of GENERIC_GPIO breaks -next

[Vineet Gupta]

On 04/17/2013 04:07 PM, Alexandre Courbot wrote:
> 
> Also arch/arc/plat-tb10x/Kconfig now defines GENERIC_GPIO, this will
> not cause breakage but should not be here anymore (ideally removed by
> the "Remove GENERIC_GPIO config option" patch)
> 
> Apart from these two issues, things seem to have gone fine, but I'm
> not sure how they should be addressed and by who?

For the arc issue - I thought we'd come to consensus already. Quoting your earlier
email:

"If the only reference to GENERIC_GPIO in your architecture or drivers is the
declaration of this config option, then it is perfectly fine - I will take care of
removing it when the time is right."

Anyhow it's a minor issue - since your code is in -next, maybe you can add the
following patch to your branch - rather than routing via my tree - better for
bisectablity. I compile tested here !

------------------->
From: Vineet Gupta <vgupta@synopsys.com>
Date: Wed, 17 Apr 2013 17:33:02 +0530
Subject: [PATCH] ARC: [TB10x] Remove GENERIC_GPIO

This tracks Alexandre Courbot's mainline GPIO rework

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
---
 arch/arc/plat-tb10x/Kconfig |    7 -------
 1 file changed, 7 deletions(-)

diff --git a/arch/arc/plat-tb10x/Kconfig b/arch/arc/plat-tb10x/Kconfig
index 4e12127..1d34521 100644
--- a/arch/arc/plat-tb10x/Kconfig
+++ b/arch/arc/plat-tb10x/Kconfig
@@ -27,10 +27,3 @@ menuconfig ARC_PLAT_TB10X
 	  Abilis Systems. TB10x is based on the ARC700 CPU architecture.
 	  Say Y if you are building a kernel for one of the SOCs in this
 	  series (e.g. TB100 or TB101). If in doubt say N.
-
-if ARC_PLAT_TB10X
-
-config GENERIC_GPIO
-	def_bool y
-
-endif
-- 
1.7.10.4

Re: Removal of GENERIC_GPIO breaks -next

[Alexandre Courbot]

On Wed, Apr 17, 2013 at 9:07 PM, Vineet Gupta
<Vineet.Gupta1@synopsys.com> wrote:
> On 04/17/2013 04:07 PM, Alexandre Courbot wrote:
>>
>> Also arch/arc/plat-tb10x/Kconfig now defines GENERIC_GPIO, this will
>> not cause breakage but should not be here anymore (ideally removed by
>> the "Remove GENERIC_GPIO config option" patch)
>>
>> Apart from these two issues, things seem to have gone fine, but I'm
>> not sure how they should be addressed and by who?
>
> For the arc issue - I thought we'd come to consensus already. Quoting your earlier
> email:
>
> "If the only reference to GENERIC_GPIO in your architecture or drivers is the
> declaration of this config option, then it is perfectly fine - I will take care of
> removing it when the time is right."
>
> Anyhow it's a minor issue - since your code is in -next, maybe you can add the
> following patch to your branch - rather than routing via my tree - better for
> bisectablity. I compile tested here !

Yes, I am not too worried about arc since it doesn't break anything.
But as you mention it would be better if the whole job could be done
by the same patch. The problem here is the merge order, for me to
address this I need to work after your patches. So maybe in the end my
series should be merged at the end of the merge window, and after all
architecture code is merged, to make sure I can address all instances.

Alex.

Re: Removal of GENERIC_GPIO breaks -next

[Vineet Gupta]

On 04/17/2013 06:34 PM, Alexandre Courbot wrote:
>
> Yes, I am not too worried about arc since it doesn't break anything.
> But as you mention it would be better if the whole job could be done
> by the same patch. The problem here is the merge order, for me to
> address this I need to work after your patches. 

OK I understand. Since your code touches a lot more stuff, I don't know if the
ordering should be governed by this small harmless patch alone :-)

> So maybe in the end my
> series should be merged at the end of the merge window, and after all
> architecture code is merged, to make sure I can address all instances.

You are touching a lot of arches anyways so you will have to be after them
anyways. Is that right ?

Anyhow lets park this patch for now - we can push it in the 3.10-rc cycle.

-Vineet

Re: Removal of GENERIC_GPIO breaks -next

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2993 bytes --]

Hi Alex,

On Wed, 17 Apr 2013 19:37:33 +0900 Alexandre Courbot <gnurou@gmail.com> wrote:
>
> It seems like the last few patches I pushed to my branch are going to
> break powerpc/85xx due to a merge issue. I have tried to warn you by
> email today but maybe you haven't read it yet.
> 
> arch/powerpc/platforms/85xx/Kconfig has a "select GENERIC_GPIO" which
> will cause compilation breakage because I removed the GENERIC_GPIO
> config option for all platforms. This line should be removed by my
> "Convert selectors of GENERIC_GPIO to GPIOLIB" patch, but this line
> slipped in between and is thus still here.
> 
> Also arch/arc/plat-tb10x/Kconfig now defines GENERIC_GPIO, this will
> not cause breakage but should not be here anymore (ideally removed by
> the "Remove GENERIC_GPIO config option" patch)
> 
> Apart from these two issues, things seem to have gone fine, but I'm
> not sure how they should be addressed and by who?

I have added the following two patches as merge fixups in linux-next.
You, or the maintainer of the tree with the conflicting patch will need
to send these (or something like them) to Linus when you ask him to pull.

For the clash with the galak tree (commit af7837c78d78
("powerpc/fsl-booke: Add B4_QDS board support")):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 18 Apr 2013 17:05:12 +1000
Subject: [PATCH] merge fix for Convert selectors of GENERIC_GPIO to GPIOLIB

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/powerpc/platforms/85xx/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index fbb3eb9..102c29e 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -327,7 +327,6 @@ config B4_QDS
 	select PPC_E500MC
 	select PHYS_64BIT
 	select SWIOTLB
-	select GENERIC_GPIO
 	select ARCH_REQUIRE_GPIOLIB
 	select HAS_RAPIDIO
 	select PPC_EPAPR_HV_PIC

For the clash with the i2c tree (commit b81dfaa01f70 ("i2c: mux: Add
i2c-arb-gpio-challenge 'mux' driver")):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 18 Apr 2013 17:08:14 +1000
Subject: [PATCH] merge fix 2 for Convert selectors of GENERIC_GPIO to GPIOLIB

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/i2c/muxes/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index b5329b0..f7f9865 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -7,7 +7,7 @@ menu "Multiplexer I2C Chip support"
 
 config I2C_ARB_GPIO_CHALLENGE
 	tristate "GPIO-based I2C arbitration"
-	depends on GENERIC_GPIO && OF
+	depends on GPIOLIB && OF
 	help
 	  If you say yes to this option, support will be included for an
 	  I2C multimaster arbitration scheme using GPIOs and a challenge &

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]