On Thu, Feb 08, 2024 at 10:28:22PM +0000, Thinh Nguyen wrote: > On Thu, Feb 08, 2024, Conor Dooley wrote: > > On Wed, Feb 07, 2024 at 05:14:01PM -0500, Frank Li wrote: > > > On Wed, Feb 07, 2024 at 10:05:23PM +0000, Conor Dooley wrote: > > > > On Wed, Feb 07, 2024 at 05:00:17PM -0500, Frank Li wrote: > > > > > Since dt maintainer give comments at old thread > > > > > https://lore.kernel.org/linux-usb/20240119213130.3147517-1-Frank.Li@xxxxxxx/ > > > > > > > > > > The patch v4 already merged. > > > > > https://lore.kernel.org/linux-usb/20240124152525.3910311-1-Frank.Li@xxxxxxx/ > > > > > > > > > > So submit new patch to rename snps,host-vbus-glitches-quirk to > > > > > snps,host-vbus-glitches to align dt maintainer's comments. > > > > > > > > I thought the last comment left on the v1 was Thinh agreeing that a > > > > DT property was not needed here and we should be able to apply this > > > > conditionally? > > > > > > I don't think so. This is workaround. We can use this track which chip > > > actually need this. If some year later, such chips already end of life. > > > We have chance to clear up these code. Otherwise, it will keep there for > > > ever. > > > > > And I am not sure that the side effect for other chips. Workaround should > > > be applied as less as possible. > > > > I'd rather do it unconditionally if we can, but if you and Thinh think > > that we cannot do it unconditionally then sure, keep the property. > > > > Perhaps I wasn't clear. I meant I agree that we don't need a new quirk > property. If anything, it should be safer to keep vbus disabled before > handing over to xhci driver. We should be able to do this > unconditionally. Okay, if everyone think unconditional is good. I can submit new patch to remove these. Frank > > BR, > Thinh
