From: Joerg Roedel <joro@8bytes.org>
To: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iommu/amd: Override wrong IVRS IOAPIC on Raven Ridge systems
Date: Wed, 14 Aug 2019 10:55:57 +0200 [thread overview]
Message-ID: <20190814085557.GB24321@8bytes.org> (raw)
In-Reply-To: <9CDD544D-DE4C-4AC6-B0DC-CD30C99EA71C@canonical.com>
On Tue, Aug 13, 2019 at 11:58:48AM +0800, Kai-Heng Feng wrote:
> at 23:39, Joerg Roedel <joro@8bytes.org> wrote:
>
> > On Thu, Aug 08, 2019 at 06:17:07PM +0800, Kai-Heng Feng wrote:
> > > Raven Ridge systems may have malfunction touchpad or hang at boot if
> > > incorrect IVRS IOAPIC is provided by BIOS.
> > >
> > > Users already found correct "ivrs_ioapic=" values, let's put them inside
> > > kernel to workaround buggy BIOS.
> >
> > Will that still work when a fixed BIOS for these laptops is released?
>
> Do you mean that we should stop applying these quirks once a BIOS fix is
> confirmed?
My concern is just that these quirks break some systems that don't need
them.
> We can modify the quirk to compare BIOS version, if there’s an unlikely BIOS
> update really fixes the issue.
> Before that happens, I think it’s OK to let the quirks stay this way.
A BIOS version check is not making things better here as it might lock
out systems that need the quirk. I think we can leave it as it for now,
but can you create a new file amd_iommu_quirks.c and move the code
there. And in the struct and function names please make clear that it is
about ivrs-quirks.
Regards,
Joerg
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Joerg Roedel <joro@8bytes.org>
To: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iommu/amd: Override wrong IVRS IOAPIC on Raven Ridge systems
Date: Wed, 14 Aug 2019 10:55:57 +0200 [thread overview]
Message-ID: <20190814085557.GB24321@8bytes.org> (raw)
In-Reply-To: <9CDD544D-DE4C-4AC6-B0DC-CD30C99EA71C@canonical.com>
On Tue, Aug 13, 2019 at 11:58:48AM +0800, Kai-Heng Feng wrote:
> at 23:39, Joerg Roedel <joro@8bytes.org> wrote:
>
> > On Thu, Aug 08, 2019 at 06:17:07PM +0800, Kai-Heng Feng wrote:
> > > Raven Ridge systems may have malfunction touchpad or hang at boot if
> > > incorrect IVRS IOAPIC is provided by BIOS.
> > >
> > > Users already found correct "ivrs_ioapic=" values, let's put them inside
> > > kernel to workaround buggy BIOS.
> >
> > Will that still work when a fixed BIOS for these laptops is released?
>
> Do you mean that we should stop applying these quirks once a BIOS fix is
> confirmed?
My concern is just that these quirks break some systems that don't need
them.
> We can modify the quirk to compare BIOS version, if there’s an unlikely BIOS
> update really fixes the issue.
> Before that happens, I think it’s OK to let the quirks stay this way.
A BIOS version check is not making things better here as it might lock
out systems that need the quirk. I think we can leave it as it for now,
but can you create a new file amd_iommu_quirks.c and move the code
there. And in the struct and function names please make clear that it is
about ivrs-quirks.
Regards,
Joerg
next prev parent reply other threads:[~2019-08-14 8:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-08 10:17 [PATCH] iommu/amd: Override wrong IVRS IOAPIC on Raven Ridge systems Kai-Heng Feng
2019-08-08 10:17 ` Kai-Heng Feng
2019-08-09 15:39 ` Joerg Roedel
2019-08-09 15:39 ` Joerg Roedel
2019-08-13 3:58 ` Kai-Heng Feng
2019-08-13 3:58 ` Kai-Heng Feng
2019-08-14 8:55 ` Joerg Roedel [this message]
2019-08-14 8:55 ` Joerg Roedel
2019-08-17 6:35 ` [PATCH v2] " Kai-Heng Feng
2019-08-17 6:35 ` Kai-Heng Feng
2019-08-19 6:56 ` kbuild test robot
2019-08-19 6:56 ` kbuild test robot
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=20190814085557.GB24321@8bytes.org \
--to=joro@8bytes.org \
--cc=iommu@lists.linux-foundation.org \
--cc=kai.heng.feng@canonical.com \
--cc=linux-kernel@vger.kernel.org \
/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.