PR/56050 CVS commit: [netbsd-9] src/sys/dev/usb

["Martin Husemann" <martin%netbsd.org@localhost>]

The following reply was made to PR kern/56050; it has been noted by GNATS.

From: "Martin Husemann" <martin%netbsd.org@localhost>
To: gnats-bugs%gnats.NetBSD.org@localhost
Cc: 
Subject: PR/56050 CVS commit: [netbsd-9] src/sys/dev/usb
Date: Mon, 21 Jun 2021 17:11:46 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Mon Jun 21 17:11:46 UTC 2021
 
 Modified Files:
 	src/sys/dev/usb [netbsd-9]: xhci.c xhcireg.h xhcivar.h
 
 Log Message:
 Pull up following revision(s) (requested by riastradh in ticket #1301):
 
 	sys/dev/usb/xhci.c: revision 1.140
 	sys/dev/usb/xhci.c: revision 1.141
 	sys/dev/usb/xhci.c: revision 1.143
 	sys/dev/usb/xhcivar.h: revision 1.18
 	sys/dev/usb/xhcivar.h: revision 1.19
 	sys/dev/usb/xhcireg.h: revision 1.19
 	sys/dev/usb/xhci.c: revision 1.139
 
 xhci(4): Draft suspend/resume.
 
 Work almost entirely done and tested by maya@ based on xhci 1.2 spec;
 tidied up and tweaked by me.
 
 Not sure about issuing Stop Endpoint commands or ensuring the Command
 Ring is in the Stopped or Idle state, but this seems to work as is,
 so it's already an improvement over what we had before which was no
 xhci suspend/resume at all.
 
 In particular, it's not clear to us:
 - if we don't have any pending USB activity whether we need to issue
   the Stop Endpoints or quiesce the command ring; but
 - if we do have any pending USB activity whether issuing Stop
   Endpoint is enough or whether we also need to do anything to
   synchronize with other software logic to quiesce it too.
 
 xhci(4): Block commands and issue Stop Endpoint on suspend.
 
 xhci: Fix logic in waiting for command queue access.
 _Either_ an existing command in progress, _or_ an existing suspend in
 progress that is not done by us, should block us; the logic I wrote
 previously erroneously blocked only if both conditions happened at
 the same time.
 
 Should fix issue reported by Andrius V in the PR kern/56050 followup
 discussion.
 
 xhci(4): Wait USB_RESUME_WAIT ms, not 20 ms.
 Better to use the named constant, and although the spec says 20 ms is
 enough, apparently for some devices it's not.
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.107.2.7 -r1.107.2.8 src/sys/dev/usb/xhci.c
 cvs rdiff -u -r1.13 -r1.13.2.1 src/sys/dev/usb/xhcireg.h
 cvs rdiff -u -r1.11 -r1.11.4.1 src/sys/dev/usb/xhcivar.h
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.