Re: [PATCH 1/2] GPIO: Add support for dual channel in gpio-xilinx.c

From: Linus Walleij
Date: Mon Jun 24 2013 - 06:01:18 EST


On Thu, Jun 20, 2013 at 2:12 PM, Michal Simek <monstr@xxxxxxxxx> wrote:

> xlnx,is-dual is always present in the HW and in all DTSes and it
> is generated for several years
>
> Based on my experience with hardware guys what happen when they add
> new channel is that they will use xlnx,is-dual = 2 for 3 channels,
> xlnx,is-dual = 3 for 4 channels, etc. They won't care about names
> but they are working like that.
>
> It means for me is really problematic it try to work with this
> value as boolean even that name is confusing.

OK I will have to live with this.

The problem with reviewing DT bindings is that for me as a
subsystem maintainer I'm interacting with a quite complex
universe:

1. Bindings from people like the MIPS camp where some people
obviously sat down in a committee meeting and tried to define
a binding in advance, which is then deployed and we have to
support. Sometimes a real nice piece of work such as the
PCI hose mappings.

2. Bindings that we need to evolve as part of this community
review process, where the judgement of a mapping's
applicability and sanity is very much up to the subsystem
maintainer. (This is the vast class of bindings.)

3. Bindings that John Doe from Idaho came up with in his
basement and then deployed to the entire world, so that
we cannot review or amend it but just have to support as
they are because they are already live in numerous
systems.

This would be a case of (3) whereas I'm mostly used to
a binding discussion of type (2) and that is why this gets
so locked up.

> That's why it is much easier for me to start to use new property
> which will describe number of channels but this value is not
> used in design tools. Let's say number-of-channels = 1 or 2
> in DT binding which will describe number channels in this IP.
> Is this acceptable for you?

This is much nicer and readable.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/