From: Lukas Wunner <lukas@wunner.de>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Ronald Tschalär" <ronald@innovation.ch>,
"Rob Herring" <robh@kernel.org>, "Jiri Slaby" <jslaby@suse.com>,
"Maximilian Luz" <luzmaximilian@gmail.com>,
linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>
Subject: Re: [PATCH] serdev: Fix detection of UART devices on Apple machines.
Date: Sun, 23 Feb 2020 09:22:01 +0100 [thread overview]
Message-ID: <20200223082201.urcwwykmggxsmkoo@wunner.de> (raw)
In-Reply-To: <20200220064723.GA3192090@kroah.com>
On Thu, Feb 20, 2020 at 07:47:23AM +0100, Greg Kroah-Hartman wrote:
> On Wed, Feb 19, 2020 at 10:33:35PM -0800, Ronald Tschalär wrote:
> > On Wed, Feb 19, 2020 at 12:15:19PM +0100, Greg Kroah-Hartman wrote:
> > > On Tue, Feb 11, 2020 at 11:47:23AM -0800, Ronald Tschalär wrote:
> > > > +#include <linux/platform_data/x86/apple.h>
> > >
> > > Why is this needed? Just for the x86_apple_machine variable?
>
> That's fine, but what I am objecting to is platform-specific include
> files being added to random common kernel code. There's no real reason
> for this other than one specific hardware platform has a quirk. Are we
> supposed to keep this pattern up by doing tons of:
> #include <linux/platform_data/x86/vendor_X>
> #include <linux/platform_data/x86/vendor_Y>
> #include <linux/platform_data/x86/vendor_Z>
> all through the kernel?
>
> That's a serious regression to the "bad old days" of platform specific
> crud being required in each and every driver subsystem.
>
> Now I know it's not your fault this is needed for your one change, but
> can you work on a patch series to fix this all up so that it is not
> needed? I'm sure the x86 maintainers don't want to see this spread
> around.
Andy (+cc) submitted a patch for the change you're requesting in January:
https://lore.kernel.org/lkml/20200122112306.64598-2-andriy.shevchenko@linux.intel.com/
The x86 maintainers haven't picked it up yet.
Ronald's patch fixes a regression. Please apply it at your earliest
convenience.
Thanks,
Lukas
prev parent reply other threads:[~2020-02-23 8:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-11 19:47 [PATCH] serdev: Fix detection of UART devices on Apple machines Ronald Tschalär
2020-02-19 11:15 ` Greg Kroah-Hartman
2020-02-20 6:33 ` Life is hard, and then you die
2020-02-20 6:47 ` Greg Kroah-Hartman
2020-02-23 8:22 ` Lukas Wunner [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=20200223082201.urcwwykmggxsmkoo@wunner.de \
--to=lukas@wunner.de \
--cc=andriy.shevchenko@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=luzmaximilian@gmail.com \
--cc=robh@kernel.org \
--cc=ronald@innovation.ch \
/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.