| Message ID | 1429103273-89272-1-git-send-email-nbd@openwrt.org (mailing list archive) |
|---|---|
| State | Accepted |
| Delegated to: | Kalle Valo |
| Headers | show |
On 15 April 2015 at 15:07, Felix Fietkau <nbd@openwrt.org> wrote: > @@ -235,16 +235,17 @@ int bcma_gpio_init(struct bcma_drv_cc *cc) > } > > /* > - * On MIPS we register GPIO devices (LEDs, buttons) using absolute GPIO > - * pin numbers. We don't have Device Tree there and we can't really use > - * relative (per chip) numbers. > - * So let's use predictable base for BCM47XX and "random" for all other. > + * Register SoC GPIO devices with absolute GPIO pin base. > + * On MIPS, we don't have Device Tree and we can't use relative (per chip) > + * GPIO numbers. > + * On some ARM devices, user space may want to access some system GPIO > + * pins directly, which is easier to do with a predictable GPIO base. > */ > -#if IS_BUILTIN(CONFIG_BCM47XX) > - chip->base = bus->num * BCMA_GPIO_MAX_PINS; > -#else > - chip->base = -1; > -#endif > + if (IS_BUILTIN(CONFIG_BCM47XX) || > + cc->core->bus->hosttype == BCMA_HOSTTYPE_SOC) > + chip->base = bus->num * BCMA_GPIO_MAX_PINS; > + else > + chip->base = -1; Is there any chance you will need predictable GPIO numbers of extra bcma buses on ARM? Like accessing GPIO of PCIe card from user space? Then you could prefer IS_BUILTIN(CONFIG_ARCH_BCM_5301X) Anyway, I'm OK with this patch.
On 2015-04-15 16:33, Rafa? Mi?ecki wrote: > On 15 April 2015 at 15:07, Felix Fietkau <nbd@openwrt.org> wrote: >> @@ -235,16 +235,17 @@ int bcma_gpio_init(struct bcma_drv_cc *cc) >> } >> >> /* >> - * On MIPS we register GPIO devices (LEDs, buttons) using absolute GPIO >> - * pin numbers. We don't have Device Tree there and we can't really use >> - * relative (per chip) numbers. >> - * So let's use predictable base for BCM47XX and "random" for all other. >> + * Register SoC GPIO devices with absolute GPIO pin base. >> + * On MIPS, we don't have Device Tree and we can't use relative (per chip) >> + * GPIO numbers. >> + * On some ARM devices, user space may want to access some system GPIO >> + * pins directly, which is easier to do with a predictable GPIO base. >> */ >> -#if IS_BUILTIN(CONFIG_BCM47XX) >> - chip->base = bus->num * BCMA_GPIO_MAX_PINS; >> -#else >> - chip->base = -1; >> -#endif >> + if (IS_BUILTIN(CONFIG_BCM47XX) || >> + cc->core->bus->hosttype == BCMA_HOSTTYPE_SOC) >> + chip->base = bus->num * BCMA_GPIO_MAX_PINS; >> + else >> + chip->base = -1; > > Is there any chance you will need predictable GPIO numbers of extra > bcma buses on ARM? Like accessing GPIO of PCIe card from user space? > Then you could prefer IS_BUILTIN(CONFIG_ARCH_BCM_5301X) > > Anyway, I'm OK with this patch. I don't think I need it, and I didn't want this change to produce conflicts on multi-arch builds, so I limited it to the SoC bus only. - Felix -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 15 April 2015 at 16:36, Felix Fietkau <nbd@openwrt.org> wrote: > On 2015-04-15 16:33, Rafa? Mi?ecki wrote: >> Anyway, I'm OK with this patch. > I don't think I need it, and I didn't want this change to produce > conflicts on multi-arch builds, so I limited it to the SoC bus only. OK, thanks.
> On some BCM5301x ARM devices, user space still needs to control some > system GPIO pins for which no driver exists. This is a lot easier to do > with a predictable GPIO base. > > Signed-off-by: Felix Fietkau <nbd@openwrt.org> Thanks, 2 patches applied to wireless-drivers-next.git: 2d57b7126d6d bcma: use absolute base for SoC GPIO pins f022ea52d9a5 bcma: enable 32 GPIO pins for BCM4707 Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/bcma/driver_gpio.c b/drivers/bcma/driver_gpio.c index 74ccb02..9b8d9bf 100644 --- a/drivers/bcma/driver_gpio.c +++ b/drivers/bcma/driver_gpio.c @@ -235,16 +235,17 @@ int bcma_gpio_init(struct bcma_drv_cc *cc) } /* - * On MIPS we register GPIO devices (LEDs, buttons) using absolute GPIO - * pin numbers. We don't have Device Tree there and we can't really use - * relative (per chip) numbers. - * So let's use predictable base for BCM47XX and "random" for all other. + * Register SoC GPIO devices with absolute GPIO pin base. + * On MIPS, we don't have Device Tree and we can't use relative (per chip) + * GPIO numbers. + * On some ARM devices, user space may want to access some system GPIO + * pins directly, which is easier to do with a predictable GPIO base. */ -#if IS_BUILTIN(CONFIG_BCM47XX) - chip->base = bus->num * BCMA_GPIO_MAX_PINS; -#else - chip->base = -1; -#endif + if (IS_BUILTIN(CONFIG_BCM47XX) || + cc->core->bus->hosttype == BCMA_HOSTTYPE_SOC) + chip->base = bus->num * BCMA_GPIO_MAX_PINS; + else + chip->base = -1; err = bcma_gpio_irq_domain_init(cc); if (err)
On some BCM5301x ARM devices, user space still needs to control some system GPIO pins for which no driver exists. This is a lot easier to do with a predictable GPIO base. Signed-off-by: Felix Fietkau <nbd@openwrt.org> --- drivers/bcma/driver_gpio.c | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-)