From: Linus Torvalds <torvalds@linux-foundation.org>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>,
soc@kernel.org, Linux ARM <linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
arm-soc <arm@kernel.org>
Subject: Re: [GIT PULL 3/6] ARM: SoC driver updates for 5.1
Date: Wed, 6 Mar 2019 10:28:30 -0800 [thread overview]
Message-ID: <CAHk-=wgGEzQXYoriCdx6MpdY86v5u+BfkHey9dKoU11A9F+Bdw@mail.gmail.com> (raw)
In-Reply-To: <20190306181557.fndmy5oks3sximeo@shell.armlinux.org.uk>
On Wed, Mar 6, 2019 at 10:16 AM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> Would it be worth splitting up mod_devicetable.h and having drivers
> include just the bus-specific device table header(s) that the driver
> requires?
That would certainly help rebuilds when it changes.
But maybe those changes are just not common enough to worry about, and
maybe it would result in more maintenance pain. Who knows?
I just wanted to mention it since it surprised me and I spent the few
minutes to figure out what the offending header file was, and see if
somebody feels motivated.
It does seem a bit pointless and wrong to have the core acpi.h header
file include this, and then cause files to be recompiled just because
some entirely unrelated device ID model changed.
So maybe it would indeed be better having each device type have its
own header file ("include/linux/acpi_devicetable.h"), and then for the
(few) cases that might want to handle _any_ type could include that
"mod_devicetable.h" that then just aggregates them?
But as mentioned, I'm not sure it's worth it, just throwing this issue
out to see what people think.
Linus
next prev parent reply other threads:[~2019-03-06 18:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-06 15:25 [GIT PULL 0/6] ARM: SoC changes for 5.1 Arnd Bergmann
2019-03-06 15:33 ` [GIT PULL 2/6] ARM: SoC device tree updates " Arnd Bergmann
2019-03-06 18:30 ` pr-tracker-bot
2019-03-06 15:34 ` [GIT PULL 3/6] ARM: SoC driver " Arnd Bergmann
2019-03-06 18:09 ` Linus Torvalds
2019-03-06 18:15 ` Russell King - ARM Linux admin
2019-03-06 18:28 ` Linus Torvalds [this message]
2019-03-06 18:30 ` pr-tracker-bot
2019-03-06 15:35 ` [GIT PULL 4/6] ARM: SoC defconfig " Arnd Bergmann
2019-03-06 18:15 ` Linus Torvalds
2019-03-06 19:49 ` Arnd Bergmann
2019-03-06 18:30 ` pr-tracker-bot
2019-03-06 15:36 ` [GIT PULL 5/6] ARM: New SoC family support " Arnd Bergmann
2019-03-06 18:30 ` pr-tracker-bot
2019-03-06 15:38 ` [GIT PULL 6/6] ARM: SoC late updates " Arnd Bergmann
2019-03-06 18:30 ` pr-tracker-bot
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='CAHk-=wgGEzQXYoriCdx6MpdY86v5u+BfkHey9dKoU11A9F+Bdw@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=arm@kernel.org \
--cc=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=soc@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 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).