All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Palmer <daniel@0x0f.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-serial@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] serial: 8250_dw: Mark acpi match table as maybe unused
Date: Fri, 1 Oct 2021 09:16:24 +0900	[thread overview]
Message-ID: <CAFr9PXmVQFDdMiMUgg4v7DAcFkdaUtFeaXOyW4_NrVd5oYKSSA@mail.gmail.com> (raw)
In-Reply-To: <YVYmTL8WsgYnxPwc@smile.fi.intel.com>

Hi Andy,

On Fri, 1 Oct 2021 at 06:04, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> > Doesn't this mean the ACPI table ends up in kernels that will never use ACPI?
>
> Yes. Is it a problem (*)? If so, you need to use ifdeffery, since __maybe_unused is
> not for the ID tables.

Ok, is there a reason it's not for the ID tables? Does it break something?

> *) while justifying this you also need to show why it's a problem specific
> to the ACPI IDs and not a problem for OF ones, which we have tons of in the
> Linux kernel without any guards (ifdeffery).

To be honest I don't care about this too much. I just wanted to cut
down some of the noise when I build my patch backlog so that warnings
in the stuff I'm trying to mainline are more visible.

For what it's worth I think the OF ids are a bit wasteful. For some
drivers where there are tons of broken variations they add a few K of
unneeded data. But since everyone now has gigabytes of memory I doubt
they care...
I'm working with 64MB. :)

Cheers,

Daniel

  reply	other threads:[~2021-10-01  0:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-30 12:49 [PATCH] serial: 8250_dw: Mark acpi match table as maybe unused Daniel Palmer
2021-09-30 15:23 ` Andy Shevchenko
2021-09-30 15:31   ` Daniel Palmer
2021-09-30 21:04     ` Andy Shevchenko
2021-10-01  0:16       ` Daniel Palmer [this message]
2021-10-05 12:14         ` Andy Shevchenko
2021-10-05 12:41           ` Daniel Palmer
2021-10-06 16:01             ` Andy Shevchenko

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=CAFr9PXmVQFDdMiMUgg4v7DAcFkdaUtFeaXOyW4_NrVd5oYKSSA@mail.gmail.com \
    --to=daniel@0x0f.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.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 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.