Linux Input Archive on
 help / color / Atom feed
From: Hans de Goede <>
To: Bastien Nocera <>,
	Dmitry Torokhov <>
Cc:, kbuild test robot <>
Subject: Re: [PATCH] Input: goodix - Fix compilation when ACPI support is disabled
Date: Wed, 25 Mar 2020 15:55:44 +0100
Message-ID: <> (raw)
In-Reply-To: <>


On 3/25/20 3:10 PM, Bastien Nocera wrote:
> On Wed, 2020-03-25 at 15:05 +0100, Hans de Goede wrote:
>> Hi,
>> On 3/25/20 3:02 PM, Bastien Nocera wrote:
>>> On Wed, 2020-03-25 at 14:55 +0100, Hans de Goede wrote:
>>>> We could do something like that, but TBH I'm not a fan of that
>>>> adding extra wrappers makes it harder to see what the code is
>>>> actually doing.
>>>> I understand your dislike for the extra braces I added and
>>>> I'm fine with fixing that by adding __maybe_unused to the
>>>> variable declarations at the top. I don't really see what
>>>> the problem with the #ifdef-s is given how clean they are,
>>>> with the braces thing fixed by using __maybe_unused things
>>>> would look like e.g. this:
>>> It's not only the fact that there's extra #ifdef's, it's that the
>>> ifdef's need to be just "that". It's not "#ifdef FOO", it's "#if
>>> defined CONFIG_X86 && defined CONFIG_ACPI".
>> If that is the problem I would prefer adding:
>> /* Our special handling for GPIO accesses through ACPI is x86
>> specific */
>> #if defined CONFIG_X86 && defined CONFIG_ACPI
>> #endif
>> And use:
>> Elsewhere.
>> Would that work for you?
> That's slightly better, but I would still have preferred stubbing out
> those ACPI calls directly. Right now, the fact that we expect half of
> the commands to be stubbed out and the other half to not be called is
> just weird.

I agree that ideally we would have stubs for this in the include/linux/...
headers, but unfortunately that is not the case here; and fixing this
is tricky for the acpi case as explained before.

I'm not a fan of adding local stubs for this, so I'm going to go with

#if defined CONFIG_X86 && defined CONFIG_ACPI

+ using __maybe_unused to avoid the extra braces for v2, and then lets
see if Dmitry has anything to add to this discussion.



      reply index

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-25 10:33 Hans de Goede
2020-03-25 10:47 ` Bastien Nocera
2020-03-25 11:49   ` Hans de Goede
2020-03-25 12:11     ` Bastien Nocera
2020-03-25 13:55       ` Hans de Goede
2020-03-25 14:02         ` Bastien Nocera
2020-03-25 14:05           ` Hans de Goede
2020-03-25 14:10             ` Bastien Nocera
2020-03-25 14:55               ` Hans de Goede [this message]

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux Input Archive on

Archives are clonable:
	git clone --mirror linux-input/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-input linux-input/ \
	public-inbox-index linux-input

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone