From: Linus Walleij <linus.walleij@linaro.org>
To: Michal Simek <michal.simek@xilinx.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Michal Simek <monstr@monstr.eu>,
Steffen Trumtrar <s.trumtrar@pengutronix.de>,
Peter Crosthwaite <peter.crosthwaite@xilinx.com>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Rob Herring <robherring2@gmail.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] gpio: zynq: Setup chip->base based on alias ID
Date: Wed, 2 May 2018 15:56:05 +0200 [thread overview]
Message-ID: <CACRpkdaNJzW+LO97oxavzYJwfkj0xu7wxTNRaGiaKm98ON5JMA@mail.gmail.com> (raw)
In-Reply-To: <60652f48-2a98-414b-5cff-25890a6da37f@xilinx.com>
On Wed, May 2, 2018 at 3:41 PM, Michal Simek <michal.simek@xilinx.com> wrote:
> If you don't want this patch I understand that and it will become just
> another soc vendor patch out of mainline.
I don't really know what to do, so that is why I'm discussing.
It's one of those gray areas.
>From one point of view there is the purist stance that we should
only support what the mainline tree does, and be strict and
consistent so we don't accumulate to many nasty hacks.
On the other hand, it is completely possible that all users of this
particular driver actually must have this patch, and then I just
push them to use a deviant vendor tree for no good reason.
Would it be possible that I apply the patch, and somehow also
establish some understanding with all users of the Xilinx
platform that whatever legacy applications are out there
must start to migrate towards using the character device so
this reliance on the numberspace doesn't stick around forever?
For example can we make a patch to some systems like
arch/arm/boot/dts/zynq-*.dts
adding proper GPIO line names to these device trees, such
as was made in e.g. commit f6b1674d570aa1
"arm64: dts: qcom: sbc: Name GPIO lines"
After all that is what I strive for as maintainer, as the IETF
motto says:
"rough consensus and running code"
Yours,
Linus Walleij
WARNING: multiple messages have this Message-ID (diff)
From: linus.walleij@linaro.org (Linus Walleij)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] gpio: zynq: Setup chip->base based on alias ID
Date: Wed, 2 May 2018 15:56:05 +0200 [thread overview]
Message-ID: <CACRpkdaNJzW+LO97oxavzYJwfkj0xu7wxTNRaGiaKm98ON5JMA@mail.gmail.com> (raw)
In-Reply-To: <60652f48-2a98-414b-5cff-25890a6da37f@xilinx.com>
On Wed, May 2, 2018 at 3:41 PM, Michal Simek <michal.simek@xilinx.com> wrote:
> If you don't want this patch I understand that and it will become just
> another soc vendor patch out of mainline.
I don't really know what to do, so that is why I'm discussing.
It's one of those gray areas.
>From one point of view there is the purist stance that we should
only support what the mainline tree does, and be strict and
consistent so we don't accumulate to many nasty hacks.
On the other hand, it is completely possible that all users of this
particular driver actually must have this patch, and then I just
push them to use a deviant vendor tree for no good reason.
Would it be possible that I apply the patch, and somehow also
establish some understanding with all users of the Xilinx
platform that whatever legacy applications are out there
must start to migrate towards using the character device so
this reliance on the numberspace doesn't stick around forever?
For example can we make a patch to some systems like
arch/arm/boot/dts/zynq-*.dts
adding proper GPIO line names to these device trees, such
as was made in e.g. commit f6b1674d570aa1
"arm64: dts: qcom: sbc: Name GPIO lines"
After all that is what I strive for as maintainer, as the IETF
motto says:
"rough consensus and running code"
Yours,
Linus Walleij
next prev parent reply other threads:[~2018-05-02 13:56 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-11 13:55 [PATCH] gpio: zynq: Setup chip->base based on alias ID Michal Simek
2018-04-11 13:55 ` Michal Simek
2018-04-26 13:08 ` Linus Walleij
2018-04-26 13:08 ` Linus Walleij
2018-04-26 13:35 ` Michal Simek
2018-04-26 13:35 ` Michal Simek
2018-05-02 10:10 ` Linus Walleij
2018-05-02 10:10 ` Linus Walleij
2018-05-02 10:15 ` Michal Simek
2018-05-02 10:15 ` Michal Simek
2018-05-02 13:01 ` Linus Walleij
2018-05-02 13:01 ` Linus Walleij
2018-05-02 13:41 ` Michal Simek
2018-05-02 13:41 ` Michal Simek
2018-05-02 13:56 ` Linus Walleij [this message]
2018-05-02 13:56 ` Linus Walleij
2018-05-02 14:19 ` Michal Simek
2018-05-02 14:19 ` Michal Simek
2018-05-15 13:26 ` Michal Simek
2018-05-15 13:26 ` Michal Simek
2018-05-23 9:44 ` Linus Walleij
2018-05-23 9:44 ` Linus Walleij
2018-05-23 10:26 ` Michal Simek
2018-05-23 10:26 ` Michal Simek
2018-05-23 9:42 ` Linus Walleij
2018-05-23 9:42 ` Linus Walleij
2018-05-23 10:17 ` Michal Simek
2018-05-23 10:17 ` Michal Simek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACRpkdaNJzW+LO97oxavzYJwfkj0xu7wxTNRaGiaKm98ON5JMA@mail.gmail.com \
--to=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.simek@xilinx.com \
--cc=monstr@monstr.eu \
--cc=peter.crosthwaite@xilinx.com \
--cc=robherring2@gmail.com \
--cc=s.trumtrar@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.