All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Daniel Palmer <daniel@0x0f.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: Wed, 6 Oct 2021 19:01:48 +0300	[thread overview]
Message-ID: <YV3IbKBrK0C7GtG0@smile.fi.intel.com> (raw)
In-Reply-To: <CAFr9PXkN-6MAExF-P8-Biej2yoQYB6eQDezwfPRX4bcXaayZfA@mail.gmail.com>

On Tue, Oct 05, 2021 at 09:41:33PM +0900, Daniel Palmer wrote:
> On Tue, 5 Oct 2021 at 21:14, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:

...

> > > For what it's worth I think the OF ids are a bit wasteful.
> >
> > Exactly my point, but fixing one driver of zillions does not solve the issue
> > in general.
> 
> I looked into making OF ids smaller globally. There seems to be 64
> bytes wasted from the start for the name and type fields as nothing
> uses them as far as I can tell.
> Then you have the array for the compatible string which is currently
> 128 bytes but the longest compatible string in the kernel is less than
> 64 from what I can tell.
> I understand that it's for future proofing etc. Adding a few hacks to
> my kernel to remove the unused fields and reduce the size of the
> compatible string saved a few tens of K.
> Which isn't a lot but might be the difference between the kernel
> fitting in a tiny SPI NOR partition or not.

What can you try is to somehow cut the sections during linking phase
if you know, that OF=n, or ACPI=n. Not sure how it would work, because
basically we will need to replace them with stubs to prevent drivers
from crashing. Nevertheless, One terminator entry is much better than
full bloated ID table(s)!

...

> Anyhow, thankyou for the interesting discussion. I'll just leave this
> in my tree for now so I don't have to see the warning.

You're welcome!

FWIW, I have sent my version of the patch, you are in Cc list there,
can you test and confirm that warning is gone for you?

-- 
With Best Regards,
Andy Shevchenko



      reply	other threads:[~2021-10-06 16:06 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
2021-10-05 12:14         ` Andy Shevchenko
2021-10-05 12:41           ` Daniel Palmer
2021-10-06 16:01             ` Andy Shevchenko [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:
  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=YV3IbKBrK0C7GtG0@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=daniel@0x0f.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.