| Message ID | 20190828063119.22248-1-tiwai@suse.de |
|---|---|
| State | Accepted |
| Delegated to: | David Miller |
| Headers | show |
| Series | sky2: Disable MSI on yet another ASUS boards (P6Xxxx) | expand |
From: Takashi Iwai <tiwai@suse.de> Date: Wed, 28 Aug 2019 08:31:19 +0200 > A similar workaround for the suspend/resume problem is needed for yet > another ASUS machines, P6X models. Like the previous fix, the BIOS > doesn't provide the standard DMI_SYS_* entry, so again DMI_BOARD_* > entries are used instead. > > Reported-and-tested-by: SteveM <swm@swm1.com> > Signed-off-by: Takashi Iwai <tiwai@suse.de> Applied, but this is getting suspicious. It looks like MSI generally is not restored properly on resume on these boards, so maybe there simply needs to be a generic PCI quirk for that?
On Thu, 29 Aug 2019 01:09:37 +0200, David Miller wrote: > > From: Takashi Iwai <tiwai@suse.de> > Date: Wed, 28 Aug 2019 08:31:19 +0200 > > > A similar workaround for the suspend/resume problem is needed for yet > > another ASUS machines, P6X models. Like the previous fix, the BIOS > > doesn't provide the standard DMI_SYS_* entry, so again DMI_BOARD_* > > entries are used instead. > > > > Reported-and-tested-by: SteveM <swm@swm1.com> > > Signed-off-by: Takashi Iwai <tiwai@suse.de> > > Applied, but this is getting suspicious. > > It looks like MSI generally is not restored properly on resume on these > boards, so maybe there simply needs to be a generic PCI quirk for that? Yes, I wondered that, too. But, e.g. HD-audio should use MSI on Intel platforms, and if the problem were generic, it must suffer from the same issue, and I haven't heard of such, so far. So it's likely specific to some limited devices, as it seems. Thanks! Takashi
From: Takashi Iwai <tiwai@suse.de> Date: Thu, 29 Aug 2019 07:20:44 +0200 > On Thu, 29 Aug 2019 01:09:37 +0200, > David Miller wrote: >> >> From: Takashi Iwai <tiwai@suse.de> >> Date: Wed, 28 Aug 2019 08:31:19 +0200 >> >> > A similar workaround for the suspend/resume problem is needed for yet >> > another ASUS machines, P6X models. Like the previous fix, the BIOS >> > doesn't provide the standard DMI_SYS_* entry, so again DMI_BOARD_* >> > entries are used instead. >> > >> > Reported-and-tested-by: SteveM <swm@swm1.com> >> > Signed-off-by: Takashi Iwai <tiwai@suse.de> >> >> Applied, but this is getting suspicious. >> >> It looks like MSI generally is not restored properly on resume on these >> boards, so maybe there simply needs to be a generic PCI quirk for that? > > Yes, I wondered that, too. > But, e.g. HD-audio should use MSI on Intel platforms, and if the > problem were generic, it must suffer from the same issue, and I > haven't heard of such, so far. So it's likely specific to some > limited devices, as it seems. There must be some state of MSI state on the sky2 chip that is restored by most BIOS/chipsets but not this one. Some part of PCI config space or something.
diff --git a/drivers/net/ethernet/marvell/sky2.c b/drivers/net/ethernet/marvell/sky2.c index c2e00bb587cd..5f56ee83e3b1 100644 --- a/drivers/net/ethernet/marvell/sky2.c +++ b/drivers/net/ethernet/marvell/sky2.c @@ -4931,6 +4931,13 @@ static const struct dmi_system_id msi_blacklist[] = { DMI_MATCH(DMI_BOARD_NAME, "P6T"), }, }, + { + .ident = "ASUS P6X", + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."), + DMI_MATCH(DMI_BOARD_NAME, "P6X"), + }, + }, {} };
A similar workaround for the suspend/resume problem is needed for yet another ASUS machines, P6X models. Like the previous fix, the BIOS doesn't provide the standard DMI_SYS_* entry, so again DMI_BOARD_* entries are used instead. Reported-and-tested-by: SteveM <swm@swm1.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> --- drivers/net/ethernet/marvell/sky2.c | 7 +++++++ 1 file changed, 7 insertions(+)