public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Marc Lehmann <schmorp@schmorp.de>,
	linux-gpio@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: Re: [PATCH resend 2/3] gpiolib: acpi: Rename honor_wakeup option to ignore_wake, add extra quirk
Date: Tue, 25 Feb 2020 14:34:25 +0200	[thread overview]
Message-ID: <20200225123425.GK10400@smile.fi.intel.com> (raw)
In-Reply-To: <e0c39a89-bcac-4315-d764-5853eb77537d@redhat.com>

On Tue, Feb 25, 2020 at 12:26:04PM +0100, Hans de Goede wrote:
> On 2/25/20 11:54 AM, Andy Shevchenko wrote:
> > On Tue, Feb 25, 2020 at 11:27:52AM +0100, Hans de Goede wrote:

...

> > In general I'm fine with this, but looking to the history of your changes I'm
> > afraid that in future it will require more than one pin to be listed or
> > something like this.
> 
> The only models which need this so far are the weird HP X2 models which
> use an external embedded controller with the tablet version of BYT / CHT
> which is just al sorts of hacked together. Also see:
> 
> https://lore.kernel.org/stable/20200223153208.312005-1-hdegoede@redhat.com/T/#u
> 
> For other parts of the same device which also rather "hacked together"
> HP made these models really really interesting...
> 
> With that said I cannot guarantee that we won't need something similar
> for some other botched-up device.

...

> > > +static int ignore_wake = IGNORE_WAKE_AUTO;
> > > +module_param(ignore_wake, int, 0444);
> > > +MODULE_PARM_DESC(ignore_wake,
> > > +	"Ignore ACPI wake flag: x=ignore-for-pin-x, -1=auto, -2=all, -3=none");
> > 
> > Perhaps we may take list of pins or a bitmap (see bitmap list parsers API).
> 
> I guess you mean bitmap_parse_user / bitmap_print_to_pagebuf, the problem
> is that for a more generic solution we need a wat to specify the
> GPIO controller + the pin, so we would get a list of <name>,<pin> pairs
> and then need to parse that, e.g. :
> 
> 	gpiolib_acpi.ignore_wake=INT33FC:00,0x1c;INT33FC:01;0x12
> 
> I agree that if we really want to future proof this that then this is
> the way we should go. This does mean adding a bunch of extra code for
> parsing this, but I guess that would be better then my current hack.
> 
> Please let me know if you prefer going this route then I will respin
> the patches to work this way.

Let's do it as a list of pairs, but in slightly different format (I see some
potential to derive a generic parser, based on users described in
Documentation/admin-guide/kernel-parameters.txt), i.e.

	ignore_wake=pin:controller[,pin:controller[,...]]

...

> > > -MODULE_PARM_DESC(honor_wakeup,
> > > -		 "Honor the ACPI wake-capable flag: 0=no, 1=yes, -1=auto");

> > Isn't it now a part of ABI? I don't think we may remove it, though we may ignore it.
> > Or do something else.
> > 
> > (One of the reasons why I hate module parameters)
> 
> I personally do not subscribe to the module parameters are part of the kernel ABI
> crowd. I do not think Linus has ever stated something like that ?  For long existing
> often used module parameters treating them as such makes a ton of sense, but this
> one is quite new and AFAIK almost nobody is using it. So my vote would be to just
> drop it. If we get push back we can easily restore it in some form.

I'm fine with dropping it, perhaps add a phrase to the commit message about
(safe) removal.

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2020-02-25 12:34 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-25 10:27 [PATCH resend 1/3] gpiolib: acpi: ignore-wakeup handling rework Hans de Goede
2020-02-25 10:27 ` [PATCH resend 1/3] gpiolib: acpi: Correct comment for HP x2 10 honor_wakeup quirk Hans de Goede
2020-02-25 10:27 ` [PATCH resend 2/3] gpiolib: acpi: Rename honor_wakeup option to ignore_wake, add extra quirk Hans de Goede
2020-02-25 10:54   ` Andy Shevchenko
2020-02-25 11:26     ` Hans de Goede
2020-02-25 12:34       ` Andy Shevchenko [this message]
2020-02-25 12:57         ` Andy Shevchenko
2020-02-28 11:22           ` Hans de Goede
2020-02-28 13:16             ` Andy Shevchenko
2020-02-29 20:57             ` Hans de Goede
2020-03-02  9:30               ` Andy Shevchenko
2020-03-02  9:46                 ` Hans de Goede
2020-03-02 10:57                   ` Andy Shevchenko
2020-02-25 10:27 ` [PATCH resend 3/3] gpiolib: acpi: Add quirk to ignore EC gpio wakeups for 1 more HP x2 10 model Hans de Goede
2020-02-25 10:28 ` [PATCH resend 1/3] gpiolib: acpi: ignore-wakeup handling rework Hans de Goede
2020-02-28 22:54 ` Linus Walleij
2020-02-29 18:14   ` 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=20200225123425.GK10400@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=hdegoede@redhat.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=schmorp@schmorp.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox