[alsa-devel] [PATCH v2 3/3] ALSA: hda: Disabled unused audio controller for Dell platforms with Switchable Graphics

[Mario.Limonciello at dell.com]

> -----Original Message-----
> From: Kai Heng Feng [mailto:kai.heng.feng at canonical.com]
> Sent: Tuesday, March 13, 2018 3:56 PM
> To: Limonciello, Mario <Mario_Limonciello at Dell.com>
> Cc: pali.rohar at gmail.com; mjg59 at srcf.ucam.org; dvhart at infradead.org;
> andy at infradead.org; tiwai at suse.com; platform-driver-x86 at vger.kernel.org; Linux
> Kernel Mailing List <linux-kernel at vger.kernel.org>; alsa-devel at alsa-project.org
> Subject: Re: [PATCH v2 3/3] ALSA: hda: Disabled unused audio controller for Dell
> platforms with Switchable Graphics
> 
> 
> 
> > On Mar 12, 2018, at 9:30 AM, Mario.Limonciello at dell.com wrote:
> >
> >>> I think the missing aspect is that this is only used in AIO and laptop
> >>> form
> >>> factors where the discrete graphics is in a non-removable form factor.
> >>
> >> Why we are not checking if kernel is running on AIO or laptop form
> >> factor then? Or it is not possible?
> >
> > Kai Heng, can you please confirm if AIO sets chassis type properly?
> > It should be 0Dh.
> >
> > If so, then I think as second check for chassis type should be possible for
> > next version of this patch.
> 
> The chassis type is correctly set as 0Dh on AIOs.
> 
> >
> >> Basically what I see there is that we need to detect if current HW
> >> platform has switchable graphics and check how is configured AUDIO MUX.
> >>
> >> But instead of directly checking hw state of audio MUX, we are trying to
> >> check something different which could get us information of state of the
> >> audio mux.
> >>
> >> I suspect that we do not have a way how to check audio MUX directly, so
> >> it needs to be done indirectly -- via some Dell SMBIOS call and some
> >> other heuristic. This is something which should be specified either in
> >> comment or in commit message (problem of type: we need X, but check for
> >> Y).
> >>
> >> And if we are doing this check indirectly, we should do the most
> >> specific test and not more general.
> >
> > Right.
> >
> >> I think that PCI vendor ID check of audio device is more general test
> >> then checking if kernel is running on Dell laptop (check via DMI). And
> >> if we can check also if running on AIO or laptop form, then it would be
> >> more specific test.
> >>
> >>> Running with your hypothetical though, what would happen is if it's
> >>> on a non-Dell machine the PCI check would pass and then the code
> >>> would not be executed by dell-laptop (since dell-smbios didn't load).
> >>
> >> Right.
> >>
> >>> If it was on a Dell machine it would load but the BIOS would return
> >>> either Switchable graphics turned off, or invalid token.
> >>>
> >>> Even though these aren't real for switchable graphics on Dell I don't
> >>> see a problem with either of these situations if it ever came up.
> >>
> >> I see, this solution is working...
> >>
> >> ... but, I see there a very bad precedense. What would happen if another
> >> laptop manufactor comes with similar solution for hybrid graphics. Does
> >> it mean that hda audio driver would try to call for every one vendor its
> >> vendor dependent API function (EFI, SMM, WMI, whatever) to check if
> >> current HW has some switchable graphics and needs special checks?
> >>
> >> Those vendor dependent API functions (which Dell SMBIOS is) should be
> >> really called on vendor hardware.
> >>
> >> Otherwise audio drivers would load bunch of the other vendor dependent
> >> platform modules and all of those modules (except maximally one) just
> >> return error.
> >
> > Sure the more specific the check the less symbol requests needed that
> > will fail.
> >
> > Kai Heng,
> >
> > Can you please use Alex Hung's OEM strings patch in your series to match
> > "Dell System" in OEM strings too?
> 
> Sure, but this probably need to wait till it gets merged in Linus' tree.
> 

It's already in -next isn't it?  Isn't that sufficient to indicate your patch depends
on that?  Or it could come through platform-x86 tree too if needed.  During
the merge window one of the duplicates will get dropped.

> >
> > Between chassis type, OEM strings match, and AMD vendor/Dell subsystem
> > vendor that should satisfy all of Pali's concerns I think.
> >
> > If anyone thinks that's too much, please speak up.
> >
> >>> Compiling a whitelist is a wasted effort because it will have to change
> >>> Every year for every new platform that has AMD switchable graphics.
> >>
> >> I agree, But see that this patch already uses vendor ID whitelisting.
> >
> > I mean making a whitelist of all individual affected Dell platforms will
> > grow
> > each year.  I want to avoid that approach.