| Message ID | 1363116094-8630-1-git-send-email-jhovold@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Mar 12, 2013 at 08:21:34PM +0100, Johan Hovold wrote: > Fix regression introduced by commit d2323cf773 ("onewire: w1-gpio: add > ext_pullup_enable pin in platform data") which added a gpio entry to the > platform data, but did not add the required initialisers to the board > files using it. Consequently, the driver would request gpio 0 at probe, > which could break other uses of the corresponding pin. > > On AT91 requesting gpio 0 changes the pin muxing for PIOA0, which, for > instance, breaks SPI0 on at91sam9g20. > > Cc: stable <stable@vger.kernel.org> > Signed-off-by: Johan Hovold <jhovold@gmail.com> > --- > > Not sure whose tree this should go in through, so adding relevant maintainers > and authors as CC. As I took the offending patch, I might as well take this fix for it as well. Unless anyone else objects? thanks, greg k-h
On Mar 13, 2013, at 4:20 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > On Tue, Mar 12, 2013 at 08:21:34PM +0100, Johan Hovold wrote: >> Fix regression introduced by commit d2323cf773 ("onewire: w1-gpio: add >> ext_pullup_enable pin in platform data") which added a gpio entry to the >> platform data, but did not add the required initialisers to the board >> files using it. Consequently, the driver would request gpio 0 at probe, >> which could break other uses of the corresponding pin. >> >> On AT91 requesting gpio 0 changes the pin muxing for PIOA0, which, for >> instance, breaks SPI0 on at91sam9g20. not only on AT91, 0 is a valid gpio >> >> Cc: stable <stable@vger.kernel.org> >> Signed-off-by: Johan Hovold <jhovold@gmail.com> >> --- >> >> Not sure whose tree this should go in through, so adding relevant maintainers >> and authors as CC. > > As I took the offending patch, I might as well take this fix for it as > well. > > Unless anyone else objects? Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Best Regards, J.
On Wed, Mar 13, 2013 at 04:24:20AM +0800, Jean-Christophe PLAGNIOL-VILLARD wrote: > On Mar 13, 2013, at 4:20 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > On Tue, Mar 12, 2013 at 08:21:34PM +0100, Johan Hovold wrote: > >> Fix regression introduced by commit d2323cf773 ("onewire: w1-gpio: add > >> ext_pullup_enable pin in platform data") which added a gpio entry to the > >> platform data, but did not add the required initialisers to the board > >> files using it. Consequently, the driver would request gpio 0 at probe, > >> which could break other uses of the corresponding pin. > >> > >> On AT91 requesting gpio 0 changes the pin muxing for PIOA0, which, for > >> instance, breaks SPI0 on at91sam9g20. > > not only on AT91, 0 is a valid gpio AT91 (and 9g20) was just an example of what the implications could be like. I discovered the change after having debugged broken MMC on a custom at91sam9g45 board. Johan
diff --git a/arch/arm/mach-at91/board-foxg20.c b/arch/arm/mach-at91/board-foxg20.c index 191d37c..1478294 100644 --- a/arch/arm/mach-at91/board-foxg20.c +++ b/arch/arm/mach-at91/board-foxg20.c @@ -176,6 +176,7 @@ static struct w1_gpio_platform_data w1_gpio_pdata = { /* If you choose to use a pin other than PB16 it needs to be 3.3V */ .pin = AT91_PIN_PB16, .is_open_drain = 1, + .ext_pullup_enable_pin = -EINVAL, }; static struct platform_device w1_device = { diff --git a/arch/arm/mach-at91/board-stamp9g20.c b/arch/arm/mach-at91/board-stamp9g20.c index 48a962b..58a6758 100644 --- a/arch/arm/mach-at91/board-stamp9g20.c +++ b/arch/arm/mach-at91/board-stamp9g20.c @@ -188,6 +188,7 @@ static struct spi_board_info portuxg20_spi_devices[] = { static struct w1_gpio_platform_data w1_gpio_pdata = { .pin = AT91_PIN_PA29, .is_open_drain = 1, + .ext_pullup_enable_pin = -EINVAL, }; static struct platform_device w1_device = { diff --git a/arch/arm/mach-ixp4xx/vulcan-setup.c b/arch/arm/mach-ixp4xx/vulcan-setup.c index 2798f43..1dddc1b 100644 --- a/arch/arm/mach-ixp4xx/vulcan-setup.c +++ b/arch/arm/mach-ixp4xx/vulcan-setup.c @@ -163,6 +163,7 @@ static struct platform_device vulcan_max6369 = { static struct w1_gpio_platform_data vulcan_w1_gpio_pdata = { .pin = 14, + .ext_pullup_enable_pin = -EINVAL, }; static struct platform_device vulcan_w1_gpio = { diff --git a/arch/arm/mach-pxa/raumfeld.c b/arch/arm/mach-pxa/raumfeld.c index 25b08bfa..6283fcb 100644 --- a/arch/arm/mach-pxa/raumfeld.c +++ b/arch/arm/mach-pxa/raumfeld.c @@ -505,6 +505,7 @@ static struct w1_gpio_platform_data w1_gpio_platform_data = { .pin = GPIO_ONE_WIRE, .is_open_drain = 0, .enable_external_pullup = w1_enable_external_pullup, + .ext_pullup_enable_pin = -EINVAL, }; struct platform_device raumfeld_w1_gpio_device = {
Fix regression introduced by commit d2323cf773 ("onewire: w1-gpio: add ext_pullup_enable pin in platform data") which added a gpio entry to the platform data, but did not add the required initialisers to the board files using it. Consequently, the driver would request gpio 0 at probe, which could break other uses of the corresponding pin. On AT91 requesting gpio 0 changes the pin muxing for PIOA0, which, for instance, breaks SPI0 on at91sam9g20. Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <jhovold@gmail.com> --- Not sure whose tree this should go in through, so adding relevant maintainers and authors as CC. /Johan arch/arm/mach-at91/board-foxg20.c | 1 + arch/arm/mach-at91/board-stamp9g20.c | 1 + arch/arm/mach-ixp4xx/vulcan-setup.c | 1 + arch/arm/mach-pxa/raumfeld.c | 1 + 4 files changed, 4 insertions(+)