Re: [PATCH v4] gpio: Driver for SYSCON-based GPIOs

[Alexander Shiyan <shc_work@xxxxxxx>]

On Tue, 18 Feb 2014 15:25:20 -0800
Olof Johansson <olof@xxxxxxxxx> wrote:

> On Thu, Jan 30, 2014 at 02:54:36PM +0100, Linus Walleij wrote:
> > On Mon, Jan 13, 2014 at 5:56 PM, Alexander Shiyan <shc_work@xxxxxxx> wrote:
> > 
> > > SYSCON driver was designed for using memory areas (registers)
> > > that are used in several subsystems. There are systems (CPUs)
> > > which use bits in one register for various purposes and thus
> > > should be handled by various kernel subsystems. This driver
> > > allows you to use the individual SYSCON bits as GPIOs.
> > > ARM CLPS711X SYSFLG1 input lines has been added as first user
> > > of this driver.
> > >
> > > Signed-off-by: Alexander Shiyan <shc_work@xxxxxxx>
> > 
> > Oh the pain. I am so ambivalent of this patch as it obfuscates
> > some stuff about the hardware that the driver should know,
> > while at the same time being elegant in a way.
> > 
> > What does the ARM SoC maintainers think about this approach?
> > 
> > Arnd, Olof, Kevin: is this something you'd like to see deployed?
> 
> I think the binding needs to be adjusted -- syscon has nothing to do with
> the binding, that's a Linux construct.
> 
> Really, if this is rephrased it becomes much more clear that this is a useful
> driver:
> 
> CLPS711X implements a few GPIO lines in a register area that is shared with
> other system registers. This is a driver for those GPIO lines, implemented
> using the shared syscon infrastructure in the kernel.
> 
> And then take out syscon from the name of the driver (and the binding).
> 
> If we have more drivers like these down the road we can make a common shared
> binding, but until then I don't think there's much point in it.

Is this proposed to remove the generic implementation?
Linus, what is your opinion on this?

-- 
Alexander Shiyan <shc_work@xxxxxxx>
--
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