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 <[email protected]>
---
drivers/bcma/driver_gpio.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
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)
--
2.2.2
On 15 April 2015 at 15:07, Felix Fietkau <[email protected]> wrote:
> Signed-off-by: Felix Fietkau <[email protected]>
Looks OK, thanks.
On 15 April 2015 at 16:36, Felix Fietkau <[email protected]> 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.
--
Rafał
On 2015-04-15 16:33, Rafał Miłecki wrote:
> On 15 April 2015 at 15:07, Felix Fietkau <[email protected]> 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
On 15 April 2015 at 15:07, Felix Fietkau <[email protected]> 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.
--
Rafał
Signed-off-by: Felix Fietkau <[email protected]>
---
drivers/bcma/driver_gpio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bcma/driver_gpio.c b/drivers/bcma/driver_gpio.c
index 9b8d9bf..5f6018e 100644
--- a/drivers/bcma/driver_gpio.c
+++ b/drivers/bcma/driver_gpio.c
@@ -226,6 +226,7 @@ int bcma_gpio_init(struct bcma_drv_cc *cc)
chip->of_node = cc->core->dev.of_node;
#endif
switch (bus->chipinfo.id) {
+ case BCMA_CHIP_ID_BCM4707:
case BCMA_CHIP_ID_BCM5357:
case BCMA_CHIP_ID_BCM53572:
chip->ngpio = 32;
--
2.2.2
> 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 <[email protected]>
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