Re: [PATCH] gpio: keep the GPIO line names internal

[Johan Hovold <johan@xxxxxxxxxx>]

On Mon, Oct 05, 2015 at 12:19:05PM +0200, Markus Pargmann wrote:
> On Mon, Oct 05, 2015 at 11:07:03AM +0100, Johan Hovold wrote:
> > On Mon, Oct 05, 2015 at 11:47:04AM +0200, Markus Pargmann wrote:
> > > On Sun, Oct 04, 2015 at 03:37:42PM +0200, Johan Hovold wrote:
> > 
> > > > You also need to revert ddd5404007b8 ("gpio-sysfs: Use gpio descriptor
> > > > name instead of gpiochip names array") however as this is an ABI change.  
> > > > Otherwise pins with a name in DT will now be exported using the gpio name
> > > > rather than number as they used to be. [ The current behaviour is
> > > > maintained by exporting names from chip->names for hard coded names
> > > > only. ]
> > > 
> > > Even for GPIOs from DT it is not a ABI change. The only GPIOs that have
> > > a GPIO name at the moment are using the GPIO hogging mechanism. But
> > > hogged GPIOs can't be exported to userspace so there is no difference
> > > for these.
> > 
> > Yes, but you're aiming at generalising the hogging mechanism so that
> > such pins can be requested, and that would break the ABI.
> 
> No, hogged GPIOs can not be requested afterwards.

Ok, you call it something different, but you're adding a way to
initialise a gpio during boot that can later be requested from userspace
(e.g. "[PATCH v2 3/3] gpiolib: Add GPIO initialization").

My point is that you cannot use this functionality for pins that are
currently used from userspace today without breaking the ABI.

> But you are right that GPIO names should probably not be added to
> existing DTs. But that's essentially the same with the currently used
> GPIO names array. Changing it would change the names in userspace as
> well.

But fortunately the names array is isolated to board files and some
legacy SOC controller drivers. We need to continue support that, but we
should not make things worse by allowing this to spread to DT.

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html