All of lore.kernel.org
 help / color / mirror / Atom feed
From: <Mario.Limonciello@dell.com>
To: <pali.rohar@gmail.com>
Cc: <kai.heng.feng@canonical.com>, <mjg59@srcf.ucam.org>,
	<dvhart@infradead.org>, <andy@infradead.org>, <tiwai@suse.com>,
	<platform-driver-x86@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <alsa-devel@alsa-project.org>
Subject: RE: [PATCH v2 3/3] ALSA: hda: Disabled unused audio controller for Dell platforms with Switchable Graphics
Date: Fri, 9 Mar 2018 09:59:39 +0000	[thread overview]
Message-ID: <09eadabb264f401a88b427744505adf8@ausx13mpc124.AMER.DELL.COM> (raw)
In-Reply-To: <20180309094600.m24d3zbzdsmls7aw@pali>

> > Pali is your concern that this code for matching vendor/subsystem is running
> > on non-Dell too?  The only other recommendation I think that can be to restrict
> > to matching Dell OEM strings in SMBIOS table, but I don't think that's any better
> > than the matching for VID/SSVID.
> 
> My concern is about adding a new machine specific code into generic
> driver, which check is done just by PCI vendor and subvendor.
> 
> In future there can be new models or other PCI devices which matches
> above condition even they would not have any switchable graphics, nor
> they would manufactured by Dell.

Uh Dell subsystem ID means it's Dell no?

> 
> Also I can imagine that in future (or maybe already now?) it is possible
> to find PCI device which pass above checks and connect this PCI device
> into desktop /server / any non-laptop device.
> 
> If this switchable graphics solution is specific to dell laptops, then
> rather checking for PCI vendor/subvevendor main check, there should be
> main check via DMI strings.

Right now this is affected to both AIO desktop and laptops.

IIRC you won't end up with switchable graphics in traditional desktop that you
can remove PCI card.  If this code was run on a traditional desktop with a 
AMD PCI card that BIOS query result should be invalid token (which will infer
switchable off to this routine).

> 
> Hardware is changing relatively quickly and there is absolutely no
> guarantee that e.g. NVIDIA would not start providing audio controller in
> similar like AMD and it would be put in those Dell machines.

Kai Heng can explain exactly why NVIDIA isn't affected.
This is probably good information to include in the commit message too.

> 
> > > >
> > > > Interesting question would be, how handle this situation Windows?
> > >
> > > I don't know how this platform handles this on Windows, I guess we need
> > > Mario to shed some lights here.
> >
> > Sorry I don't have this information to share.   I don't think it's too useful here
> > anyway though because Windows driver architecture is much different in this
> > area.
> >
> >
> 
> --
> Pali Rohár
> pali.rohar@gmail.com

WARNING: multiple messages have this Message-ID (diff)
From: <Mario.Limonciello@dell.com>
To: pali.rohar@gmail.com
Cc: kai.heng.feng@canonical.com, mjg59@srcf.ucam.org,
	dvhart@infradead.org, andy@infradead.org, tiwai@suse.com,
	platform-driver-x86@vger.kernel.org,
	linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org
Subject: RE: [PATCH v2 3/3] ALSA: hda: Disabled unused audio controller for Dell platforms with Switchable Graphics
Date: Fri, 9 Mar 2018 09:59:39 +0000	[thread overview]
Message-ID: <09eadabb264f401a88b427744505adf8@ausx13mpc124.AMER.DELL.COM> (raw)
In-Reply-To: <20180309094600.m24d3zbzdsmls7aw@pali>

> > Pali is your concern that this code for matching vendor/subsystem is running
> > on non-Dell too?  The only other recommendation I think that can be to restrict
> > to matching Dell OEM strings in SMBIOS table, but I don't think that's any better
> > than the matching for VID/SSVID.
> 
> My concern is about adding a new machine specific code into generic
> driver, which check is done just by PCI vendor and subvendor.
> 
> In future there can be new models or other PCI devices which matches
> above condition even they would not have any switchable graphics, nor
> they would manufactured by Dell.

Uh Dell subsystem ID means it's Dell no?

> 
> Also I can imagine that in future (or maybe already now?) it is possible
> to find PCI device which pass above checks and connect this PCI device
> into desktop /server / any non-laptop device.
> 
> If this switchable graphics solution is specific to dell laptops, then
> rather checking for PCI vendor/subvevendor main check, there should be
> main check via DMI strings.

Right now this is affected to both AIO desktop and laptops.

IIRC you won't end up with switchable graphics in traditional desktop that you
can remove PCI card.  If this code was run on a traditional desktop with a 
AMD PCI card that BIOS query result should be invalid token (which will infer
switchable off to this routine).

> 
> Hardware is changing relatively quickly and there is absolutely no
> guarantee that e.g. NVIDIA would not start providing audio controller in
> similar like AMD and it would be put in those Dell machines.

Kai Heng can explain exactly why NVIDIA isn't affected.
This is probably good information to include in the commit message too.

> 
> > > >
> > > > Interesting question would be, how handle this situation Windows?
> > >
> > > I don't know how this platform handles this on Windows, I guess we need
> > > Mario to shed some lights here.
> >
> > Sorry I don't have this information to share.   I don't think it's too useful here
> > anyway though because Windows driver architecture is much different in this
> > area.
> >
> >
> 
> --
> Pali Rohár
> pali.rohar@gmail.com

  reply	other threads:[~2018-03-09  9:59 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-08  9:10 [PATCH v2 1/3] dell-led: Change dell-led.h to dell-common.h Kai-Heng Feng
2018-03-08  9:10 ` [PATCH v2 2/3] platform/x86: dell-*: Add interface for switchable graphics status query Kai-Heng Feng
2018-03-08 16:38   ` Pali Rohár
2018-03-08 16:38     ` Pali Rohár
2018-03-09  8:14     ` Kai Heng Feng
2018-03-08  9:10 ` [PATCH v2 3/3] ALSA: hda: Disabled unused audio controller for Dell platforms with Switchable Graphics Kai-Heng Feng
2018-03-08  9:38   ` [alsa-devel] " Lukas Wunner
2018-03-08 10:38     ` Kai Heng Feng
2018-03-08 10:38       ` Kai Heng Feng
2018-03-08 11:30       ` [alsa-devel] " Lukas Wunner
2018-03-08 11:30         ` Lukas Wunner
2018-03-09  8:22         ` [alsa-devel] " Kai Heng Feng
2018-03-09  9:02   ` Pali Rohár
2018-03-09  9:02     ` Pali Rohár
2018-03-09  9:30     ` Kai Heng Feng
2018-03-09  9:34       ` Mario.Limonciello
2018-03-09  9:34         ` Mario.Limonciello
2018-03-09  9:46         ` Pali Rohár
2018-03-09  9:46           ` Pali Rohár
2018-03-09  9:59           ` Mario.Limonciello [this message]
2018-03-09  9:59             ` Mario.Limonciello
2018-03-10 10:38             ` Pali Rohár
2018-03-10 10:38               ` Pali Rohár
2018-03-11 14:03               ` Mario.Limonciello
2018-03-11 14:03                 ` Mario.Limonciello
2018-03-11 14:30                 ` Pali Rohár
2018-03-11 14:30                   ` Pali Rohár
2018-03-12  1:30                   ` Mario.Limonciello
2018-03-12  1:30                     ` Mario.Limonciello
2018-03-13  7:56                     ` Kai Heng Feng
2018-03-13  7:56                       ` Kai Heng Feng
2018-03-13  8:13                       ` Mario.Limonciello
2018-03-13  8:13                         ` Mario.Limonciello
2018-03-10  6:50       ` Lukas Wunner
2018-03-10  6:50         ` Lukas Wunner
2018-03-10 10:40         ` Pali Rohár
2018-03-10 10:40           ` Pali Rohár
2018-03-11 14:06         ` Mario.Limonciello
2018-03-11 14:06           ` Mario.Limonciello
2018-03-13  8:24         ` Kai Heng Feng
2018-04-07 16:44 ` [PATCH v2 1/3] dell-led: Change dell-led.h to dell-common.h Darren Hart
2018-04-07 16:44   ` Darren Hart

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=09eadabb264f401a88b427744505adf8@ausx13mpc124.AMER.DELL.COM \
    --to=mario.limonciello@dell.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=andy@infradead.org \
    --cc=dvhart@infradead.org \
    --cc=kai.heng.feng@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjg59@srcf.ucam.org \
    --cc=pali.rohar@gmail.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=tiwai@suse.com \
    /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.