[PATCH 0/4][SRU][D][E][F][OEM-B][OEM-B-OSP1] The system cannot resume from S3 if user unplugs the TB16 during suspend state
acelan.kao at canonical.com
Fri Nov 1 03:46:48 UTC 2019
I think you are mentioning the 4th commit.
It change the return type of pciehp_check_link_active() from bool to
int to indicate different state.
AFAIK, there is no other thread discuss this change, and Mika doesn't
reply to us if he will keep pushing the changes to upstream.
When I asked him if those commits introduce any regression he can
think of, he just reply "I don't think there is any risk of
Seth Forshee <seth.forshee at canonical.com> 於 2019年11月1日 週五 上午3:49寫道：
> On Wed, Oct 23, 2019 at 11:14:59AM +0800, AceLan Kao wrote:
> > BugLink: https://bugs.launchpad.net/bugs/1849269
> > [Impact]
> > Unplug TBT dock during S3 and then wakes up the system leads to system
> > hangs.
> > This not only happens on Dell TB16, but also Dell WD19TB. It's more like
> > a BIOS or TBT firmware issue that TBT firmware doesn't re-create the PCIe
> > tunnels.
> > [Fix]
> > Mika provides 4 patches to fix this issue, but only 2 are accepted and are
> > included in linus' tree. We need especially the 4th commit to fix the
> > issue, so we keep the 3rd and 4th commits as sauce patches.
> > [Test]
> > Verified on Dell Precision 5530 + WD19TB
> > [Regression Potential]
> > Low, those patches doesn't change the code path much. The 4th commit adds
> > some checks to return failure state, and it should be safe for those
> > machines which is working well.
> I was reading through the upstream thread, and as of a week ago it
> appeared that they were discussing a change to the
> pciehp_check_link_active() changes, which I do not see in the patches
> you sent. Do you know if another iteration of the patches is
> forthcoming, and if so shouldn't we wait and take that version?
More information about the kernel-team