On Wed, Feb 19, 2020 at 10:33:35PM -0800, Life is hard, and then you die 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: > > > On Apple devices the _CRS method returns an empty resource template, and > > > the resource settings are instead provided by the _DSM method. But > > > commit 33364d63c75d6182fa369cea80315cf1bb0ee38e (serdev: Add ACPI > > > devices by ResourceSource field) changed the search for serdev devices > > > to require valid, non-empty resource template, thereby breaking Apple > > > devices and causing bluetooth devices to not be found. > > > > > > This expands the check so that if we don't find a valid template, and > > > we're on an Apple machine, then just check for the device being an > > > immediate child of the controller and having a "baud" property. > > > > > > Cc: <stable@xxxxxxxxxxxxxxx> # 5.5 > > > Signed-off-by: Ronald Tschalär <ronald@xxxxxxxxxxxxx> > > > --- > > > drivers/tty/serdev/core.c | 10 ++++++++++ > > > 1 file changed, 10 insertions(+) > > > > > > diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c > > > index ce5309d00280..0f64a10ba51f 100644 > > > --- a/drivers/tty/serdev/core.c > > > +++ b/drivers/tty/serdev/core.c > > > @@ -18,6 +18,7 @@ > > > #include <linux/sched.h> > > > #include <linux/serdev.h> > > > #include <linux/slab.h> > > > +#include <linux/platform_data/x86/apple.h> > > > > Why is this needed? Just for the x86_apple_machine variable? > > Yes. > > > Why do we still have platform_data for new systems anymore? Can't this > > go into a much more generic location? Like as an inline function? > > I'm not sure I follow you. What exactly would you like to see in the > function? The check that sets this variable? Note that this was > originally pulled out into a variable that is set once for performance > reasons - see commit 630b3aff8a51c. 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. Heck, ARM doesn't even need this kind of mess :) thanks, greg k-h
