Message ID | 20230223210743.9819-1-mario.limonciello@amd.com (mailing list archive) |
---|---|
Headers | show |
Series | Fix problems fetching TBT3 DROM from AMD USB4 routers | expand |
Hi Mario, On Thu, Feb 23, 2023 at 03:07:40PM -0600, Mario Limonciello wrote: > TBT3 devices when connected to an AMD USB4 router occasionally fail to > properly respond to requests for the DROM via bit banging. > > Depending upon which part of the request failed will impact the severity. > A number of workarounds have been put in place to let the driver handle > the failed requests: > > commit e87491a9fd4e3 ("thunderbolt: Retry DROM reads for more failure scenarios") > commit a283de3ec646f ("thunderbolt: Do not resume routers if UID is not set") > commit 6915812bbd109 ("thunderbolt: Do not make DROM read success compulsory") > commit f022ff7bf377 ("thunderbolt: Retry DROM read once if parsing fails") > > Still even with these changes the failures do make it through. In comparing > other CM implementations utilized on AMD systems, they all access the > DROM directly from the NVM. > > To avoid triggering this issue, try to get the DROM directly from the NVM > in Linux as well when devices have an LC. > > v4: > * Style fixups > * Fixup for wrong path for USB4 devices > > Mario Limonciello (3): > thunderbolt: Adjust how NVM reading works > thunderbolt: use `tb_eeprom_get_drom_offset` to discover DROM offset > thunderbolt: Refactor DROM reading I split the device side into a separate function too, renamed root switch to host router (as that's the correct USB4 term), and fixed a couple style issues and applied to thunderbolt.git/next, thanks! Please check that I did not mess up anything :)
[Public] > -----Original Message----- > From: Mika Westerberg <mika.westerberg@linux.intel.com> > Sent: Monday, March 6, 2023 03:58 > To: Limonciello, Mario <Mario.Limonciello@amd.com> > Cc: linux-usb@vger.kernel.org; Mehta, Sanju <Sanju.Mehta@amd.com>; > linux-kernel@vger.kernel.org > Subject: Re: [PATCH v4 0/3] Fix problems fetching TBT3 DROM from AMD > USB4 routers > > Hi Mario, > > On Thu, Feb 23, 2023 at 03:07:40PM -0600, Mario Limonciello wrote: > > TBT3 devices when connected to an AMD USB4 router occasionally fail to > > properly respond to requests for the DROM via bit banging. > > > > Depending upon which part of the request failed will impact the severity. > > A number of workarounds have been put in place to let the driver handle > > the failed requests: > > > > commit e87491a9fd4e3 ("thunderbolt: Retry DROM reads for more failure > scenarios") > > commit a283de3ec646f ("thunderbolt: Do not resume routers if UID is not > set") > > commit 6915812bbd109 ("thunderbolt: Do not make DROM read success > compulsory") > > commit f022ff7bf377 ("thunderbolt: Retry DROM read once if parsing fails") > > > > Still even with these changes the failures do make it through. In comparing > > other CM implementations utilized on AMD systems, they all access the > > DROM directly from the NVM. > > > > To avoid triggering this issue, try to get the DROM directly from the NVM > > in Linux as well when devices have an LC. > > > > v4: > > * Style fixups > > * Fixup for wrong path for USB4 devices > > > > Mario Limonciello (3): > > thunderbolt: Adjust how NVM reading works > > thunderbolt: use `tb_eeprom_get_drom_offset` to discover DROM offset > > thunderbolt: Refactor DROM reading > > I split the device side into a separate function too, renamed root > switch to host router (as that's the correct USB4 term), and fixed a > couple style issues and applied to thunderbolt.git/next, thanks! > > Please check that I did not mess up anything :) They look good, thanks! Would you consider to take 8d7f459107f74fbbdde3dd5b3874d2e748cb8a21 to the RC though, or would prefer to let it bake in next?
Hi, On Mon, Mar 06, 2023 at 03:14:07PM +0000, Limonciello, Mario wrote: > [Public] > > > > > -----Original Message----- > > From: Mika Westerberg <mika.westerberg@linux.intel.com> > > Sent: Monday, March 6, 2023 03:58 > > To: Limonciello, Mario <Mario.Limonciello@amd.com> > > Cc: linux-usb@vger.kernel.org; Mehta, Sanju <Sanju.Mehta@amd.com>; > > linux-kernel@vger.kernel.org > > Subject: Re: [PATCH v4 0/3] Fix problems fetching TBT3 DROM from AMD > > USB4 routers > > > > Hi Mario, > > > > On Thu, Feb 23, 2023 at 03:07:40PM -0600, Mario Limonciello wrote: > > > TBT3 devices when connected to an AMD USB4 router occasionally fail to > > > properly respond to requests for the DROM via bit banging. > > > > > > Depending upon which part of the request failed will impact the severity. > > > A number of workarounds have been put in place to let the driver handle > > > the failed requests: > > > > > > commit e87491a9fd4e3 ("thunderbolt: Retry DROM reads for more failure > > scenarios") > > > commit a283de3ec646f ("thunderbolt: Do not resume routers if UID is not > > set") > > > commit 6915812bbd109 ("thunderbolt: Do not make DROM read success > > compulsory") > > > commit f022ff7bf377 ("thunderbolt: Retry DROM read once if parsing fails") > > > > > > Still even with these changes the failures do make it through. In comparing > > > other CM implementations utilized on AMD systems, they all access the > > > DROM directly from the NVM. > > > > > > To avoid triggering this issue, try to get the DROM directly from the NVM > > > in Linux as well when devices have an LC. > > > > > > v4: > > > * Style fixups > > > * Fixup for wrong path for USB4 devices > > > > > > Mario Limonciello (3): > > > thunderbolt: Adjust how NVM reading works > > > thunderbolt: use `tb_eeprom_get_drom_offset` to discover DROM offset > > > thunderbolt: Refactor DROM reading > > > > I split the device side into a separate function too, renamed root > > switch to host router (as that's the correct USB4 term), and fixed a > > couple style issues and applied to thunderbolt.git/next, thanks! > > > > Please check that I did not mess up anything :) > > They look good, thanks! Thanks for checking! > Would you consider to take 8d7f459107f74fbbdde3dd5b3874d2e748cb8a21 to > the RC though, or would prefer to let it bake in next? I would like to keep it too in next just to make sure nothing breaks accidentally.