linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Shawn Guo <shawn.guo@linaro.org>
Cc: Jeffrey Hugo <jhugo@codeaurora.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH] gpiolib: acpi: support override broken GPIO number in ACPI table
Date: Wed, 3 Mar 2021 11:42:28 +0200	[thread overview]
Message-ID: <YD9aBB0a3V4OhTCV@smile.fi.intel.com> (raw)
In-Reply-To: <20210303084508.GA17424@dragon>

On Wed, Mar 03, 2021 at 04:45:09PM +0800, Shawn Guo wrote:
> On Wed, Mar 03, 2021 at 10:06:53AM +0200, Andy Shevchenko wrote:
> > Since the mapping of those wake IRQs is totally platform specific, it needs a
> > platform driver. On above mentioned x86 platforms we have a one you may take as
> > an example (good or bad it's another story):
> > drivers/platform/x86/intel_int0002_vgpio.c.
> > 
> > I think you will need something like this somewhere in ARM platform
> > infrastructure in the Linux kernel.
> 
> Well, you have the Virtual GPIO controller defined in ACPI as device
> "INT0002", but we do not have such a thing.  I'm not sure it makes much
> sense to create a baseless driver.

It has similarities and differences. In your case you need to have somewhere
some piece of the code that will do proper things, but it shouldn't be GPIO
ACPI layer.

> > That said, I don't see that those numbers are "broken", they have their own
> > meaning and specific mapping to the real GPIOs and it's so platform specific,
> > that we can't treat it as a quirk.
> 
> Those numbers have their own meaning only for Windows.  It's OS specific
> rather than platform specific.

Platform is a combination of hardware, PCB and uC firmwares. AFAIU that
platform was never designed for use in Linux, correct? So, it is not the same
as any other platform on the same SoC.

> Snapdragon platform manual has explicit
> numbering of every single GPIO pin.  Those broken numbers in ACPI table
> violate the hardware specification and are *broken* to Linux which
> implements GPIO driver properly.

No, they are not broken. They have a specific (Windows way) meaning. There is
no quirk implied.

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2021-03-03 12:58 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-26  3:39 [PATCH] gpiolib: acpi: support override broken GPIO number in ACPI table Shawn Guo
2021-02-26  9:12 ` Andy Shevchenko
2021-02-26  9:39   ` Shawn Guo
2021-02-26 10:57     ` Andy Shevchenko
2021-02-26 11:19       ` Andy Shevchenko
2021-02-27  3:19         ` Shawn Guo
2021-03-01 12:17           ` Andy Shevchenko
2021-03-02  0:27             ` Shawn Guo
2021-03-02 12:21               ` Andy Shevchenko
2021-03-03  5:02                 ` Jeffrey Hugo
2021-03-03  8:06                   ` Andy Shevchenko
2021-03-03  8:45                     ` Shawn Guo
2021-03-03  9:42                       ` Andy Shevchenko [this message]
2021-03-03 17:08                     ` Jeffrey Hugo
2021-03-03  9:43                   ` Shawn Guo
2021-03-03 15:10                     ` Jeffrey Hugo
2021-03-03 15:57                       ` Bjorn Andersson
2021-03-03 17:32                         ` Andy Shevchenko
2021-03-04  6:37                         ` Shawn Guo
2021-03-04  6:59                           ` Shawn Guo
2021-02-27  3:46       ` Shawn Guo
2021-03-01 12:19         ` Andy Shevchenko
2021-03-02  0:44           ` Shawn Guo
2021-03-02 10:36             ` Andy Shevchenko
2021-03-03  9:47 ` Andy Shevchenko
2021-03-04 19:32   ` Hans de Goede
2021-03-04 20:16     ` Andy Shevchenko
2021-03-05  1:14     ` Shawn Guo
2021-03-05  9:10       ` Hans de Goede
2021-03-05 10:08         ` Andy Shevchenko
2021-03-05 10:10           ` Andy Shevchenko
2021-03-05 11:26         ` Shawn Guo
2021-03-05 12:12           ` Hans de Goede

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=YD9aBB0a3V4OhTCV@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=jhugo@codeaurora.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=shawn.guo@linaro.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).