Skip to contentSkip to conversation

label string for kirkwood gpiochip

DISCUSSION Holger Brunck 2 participants 4 messages Dec 15, 2011 – Dec 17, 2011

lore
Share & tools
lore
#0 lore raw

Hi,
we recently switched with our kirkwood based board to a newer kernel version. Our application code is written in that way if someone request an gpio in userspace that he do search the gpiochip via the gpio label.

The newer kernel version handles the gpiochip on kirkwood in a different way. The orion_gpio_init function in arch/arm/mach-kirkwood/irq.c was called twice. Once for first 32 gpios and a second time for the remaining 18 gpios. This causes that the gpio framework shows two gpiochips in the sysfs with the same label (orion_gpio).

[@km_kirkwood /]# cat /sys/class/gpio/gpiochip0/label orion_gpio
[@km_kirkwood /]# cat /sys/class/gpio/gpiochip32/label orion_gpio

So my question is simply, shouldn't be the string for a gpiochip unique in the system and therefore this should be fixed or was this intended?

Best regards
Holger Brunck

#1 lore raw
Quoted 11 lines · Holger Brunck

Hi,
we recently switched with our kirkwood based board to a newer kernel version. Our application code is written in that way if someone request an gpio in userspace that he do search the gpiochip via the gpio label.

The newer kernel version handles the gpiochip on kirkwood in a different way. The orion_gpio_init function in arch/arm/mach-kirkwood/irq.c was called twice. Once for first 32 gpios and a second time for the remaining 18 gpios. This causes that the gpio framework shows two gpiochips in the sysfs with the same label (orion_gpio).

Quoted 7 lines

[@km_kirkwood /]# cat /sys/class/gpio/gpiochip0/label orion_gpio
[@km_kirkwood /]# cat /sys/class/gpio/gpiochip32/label orion_gpio

So my question is simply, shouldn't be the string for a gpiochip unique in the system and therefore this should be fixed or was this intended?

I don't think that was intended.

Nicolas

#2 lore raw
Quoted 12 lines · Nicolas Pitre
Quoted 12 lines

The newer kernel version handles the gpiochip on kirkwood in a different way. The orion_gpio_init function in arch/arm/mach-kirkwood/irq.c was called twice. Once for first 32 gpios and a second time for the remaining 18 gpios. This causes that the gpio framework shows two gpiochips in the sysfs with the same label (orion_gpio).

[@km_kirkwood /]# cat /sys/class/gpio/gpiochip0/label orion_gpio
[@km_kirkwood /]# cat /sys/class/gpio/gpiochip32/label orion_gpio

Quoted 5 lines
Quoted 2 lines

So my question is simply, shouldn't be the string for a gpiochip unique in the system and therefore this should be fixed or was this intended?

I don't think that was intended.

Ok, how should this be done? We could add an additional param chip_label to

void __init orion_gpio_init(int gpio_base, int ngpio,

                            u32 base, int mask_offset, int secondary_irq_base);

and fix the callers accordingly or we could add a simple static counter in orion_gpio_init and add a suffix _0, _1, _2 to the label to make it unique without touching the clients...

Best regards
Holger

#3 lore raw
Quoted 19 lines · Holger Brunck
Quoted 12 lines · Nicolas Pitre
Quoted 12 lines

The newer kernel version handles the gpiochip on kirkwood in a different way. The orion_gpio_init function in arch/arm/mach-kirkwood/irq.c was called twice. Once for first 32 gpios and a second time for the remaining 18 gpios. This causes that the gpio framework shows two gpiochips in the sysfs with the same label (orion_gpio).

[@km_kirkwood /]# cat /sys/class/gpio/gpiochip0/label orion_gpio
[@km_kirkwood /]# cat /sys/class/gpio/gpiochip32/label orion_gpio

Quoted 5 lines
Quoted 2 lines

So my question is simply, shouldn't be the string for a gpiochip unique in the system and therefore this should be fixed or was this intended?

I don't think that was intended.

Quoted 8 lines

Ok, how should this be done? We could add an additional param chip_label to

void __init orion_gpio_init(int gpio_base, int ngpio,

                            u32 base, int mask_offset, int secondary_irq_base);

and fix the callers accordingly or we could add a simple static counter in orion_gpio_init and add a suffix _0, _1, _2 to the label to make it unique without touching the clients...

The later would be less intrusive at this point.

Eventually this should be hooked into the pinctrl subsystem.

Nicolas