From nobody Tue Mar 22 18:05:19 2022 X-Original-To: freebsd-usb@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5C4671A1462C for ; Tue, 22 Mar 2022 18:05:42 +0000 (UTC) (envelope-from farhan@farhan.codes) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KNKCn3hHWz3lN2 for ; Tue, 22 Mar 2022 18:05:41 +0000 (UTC) (envelope-from farhan@farhan.codes) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 926825C01EC for ; Tue, 22 Mar 2022 14:05:40 -0400 (EDT) Received: from imap45 ([10.202.2.95]) by compute1.internal (MEProxy); Tue, 22 Mar 2022 14:05:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=farhan.codes; h= cc:content-type:date:date:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to; s=fm2; bh=D 2N8zuVoQWfYFiUe+ML/9gx5mx2Ex4TGXmaBpSHugyo=; b=px+oe950RYeXVvZT7 dry6CUSuuaq8+T1EiPUkg+N6uYvKuWQDMhPAG84mdLGnUHTnOGBx41ncyNNBFg9I S3jgQdG4J6U3hnQKu/MP5uNivQzHEsxFMD51j71GSqh5g3vYJMx9FZwDUsxFULIX ydOysF3BH/g2jU0Lfy3GqCAbFLhDwdPkIqMmKE4YfmM70PH/0EidYylt8BAVJ4vy uiGNsqpdKd314kRzz2PeBuIzzwGFZrxXV2ycAA5P10OrsugvZkeGcBwlDQfQ4aoI IZxD6eCHp34GHRv9S/dLWul6qgQZwe62QJYjCXNf6RgbR7RLaSXsmV/8fqPZNGHe JUenQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=D2N8zuVoQWfYFiUe+ML/9gx5mx2Ex4TGXmaBpSHug yo=; b=nc0X6DAkJONaVd3RC+bNgiQkAiEr04EHDFA4h+yW+2MTR9xiB5DTGm9QD cOcOnGhfAQZRpIq/e7S0Zg+7//9KWMCcH3YQvE2S9RgL/IT1Iz6Nx6vNEvCcktsy ILk3HJ1j0j4QttzZu/w/YDOIzsjOgZbIOa1BcKKnpazXCI6KPHBHslZRzpKbF0xW GaQq6XJRuBXCx+qdERne1THrlX84g8k9bVlvAfuRkXrPYI9HOSjzxIwza51FMf8i mjvy2zPrpZggaAIos9aMIc5NbjuAPjFPXDJtcACs/fgcEZH+6NV350f6YUwRTb/k 0PSExF026T2hhTVgQqN8oZtRCetBw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudeghedguddthecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtre erreertdenucfhrhhomhepfdfhrghrhhgrnhcumfhhrghnfdcuoehfrghrhhgrnhesfhgr rhhhrghnrdgtohguvghsqeenucggtffrrghtthgvrhhnpefhvdefueejueektdffjeejhe eigfevueevgfffheejhedvfeetvddvjeevtdegffenucffohhmrghinhepghhithhhuhgs rdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epfhgrrhhhrghnsehfrghrhhgrnhdrtghouggvsh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 15C4124A007C; Tue, 22 Mar 2022 14:05:40 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4907-g25ce6f34a9-fm-20220311.001-g25ce6f34 List-Id: FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-usb List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-usb@freebsd.org X-BeenThere: freebsd-usb@freebsd.org Mime-Version: 1.0 Message-Id: <57ff6d47-79b3-4409-b804-108fe7d62e9d@www.fastmail.com> Date: Tue, 22 Mar 2022 14:05:19 -0400 From: "Farhan Khan" To: freebsd-usb@freebsd.org Subject: Understanding USB callback events and sequence Content-Type: multipart/alternative; boundary=5950a9e3350143c090d056536e154453 X-Rspamd-Queue-Id: 4KNKCn3hHWz3lN2 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=farhan.codes header.s=fm2 header.b=px+oe950; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=nc0X6DAk; dmarc=none; spf=pass (mx1.freebsd.org: domain of farhan@farhan.codes designates 66.111.4.28 as permitted sender) smtp.mailfrom=farhan@farhan.codes X-Spamd-Result: default: False [-3.59 / 15.00]; XM_UA_NO_VERSION(0.01)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.28:from]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.28]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[farhan.codes:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-0.997]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.28:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[farhan.codes:s=fm2,messagingengine.com:s=fm3]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-usb@freebsd.org]; DMARC_NA(0.00)[farhan.codes]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; MLMMJ_DEST(0.00)[freebsd-usb]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N --5950a9e3350143c090d056536e154453 Content-Type: text/plain Hi all, I am trying to understand how the structure of the USB callback and have a few questions. The relevant manual page is usbdi(9). The manual talks about the 3 states of the callback: USB_ST_SETUP, USB_ST_TRANSFERRED, and default (error). I am not clear on the difference between USB_ST_SETUP and USB_ST_TRANSFERRED. The manual seems to suggest that USB_ST_SETUP is where the USB packet is sent, which leads me to think USB_ST_TRANSFERRED is cleanup? From looking at examples, this appears to be how thinks are done. What triggers the event? From testing, it seems that usbd_transfer_start(9) triggers the callback with USB_ST_SETUP. If so, what triggers USB_ST_TRANSFERRED. Why is it necessary? Also, when I read examples I see that in some places the expected `break` in the `select` is removed with a note saying "fall through". Wouldn't this double-send the USB packet, or at least sent another packet during the USB_ST_TRANSFERRED stage? For example here: https://github.com/freebsd/freebsd-src/blob/9a6695532b3997e4e2bc3fe57481cc49be5e9e93/sys/dev/usb/wlan/if_rsu.c#L2671 Finally, I have been looking at USB traffic under wireshark (interpreted from usbdump -w file.pcap) and I see that every USB packet has a response from the device. Is this response packet handled by one of the RX callbacks? Or is this the same as TX's USB_ST_TRANSFERRED? Thank you and pardon the multiple questions! -- Farhan Khan PGP Fingerprint: 1312 89CE 663E 1EB2 179C 1C83 C41D 2281 F8DA C0DE --5950a9e3350143c090d056536e154453 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi all,

I am trying to understand how the structure of the USB call= back and have a few questions. The relevant manual page is usbdi(9).

The manual talks about the 3 states of the callback:=  USB_ST_SETUP, USB_ST_TRANSFERRED, and default (error). I am= not clear on the difference between USB_ST_SETUP and USB_ST_TRAN= SFERRED. The manual seems to suggest that USB_ST_SETUP is where the USB pac= ket is sent, which leads me to think USB_ST_TRANSFERRED is cleanup? From lo= oking at examples, this appears to be how thinks are done.
What triggers the event? From testing, it seems that usbd_tran= sfer_start(9) triggers the callback with USB_ST_SETUP. If so, what triggers=  USB_ST_TRANSFERRED. Why is it necessary?

Als= o, when I read examples I see that in some places the expected `break` in t= he `select` is removed with a note saying "fall through". Wouldn't this dou= ble-send the USB packet, or at least sent another packet during the US= B_ST_TRANSFERRED stage? For example here:

Finally, I have been looking at USB traffic = under wireshark (interpreted from usbdump -w file.pcap) and I see that ever= y USB packet has a response from the device. Is this response packet h= andled by one of the RX callbacks? Or is this the same as TX's USB_ST_= TRANSFERRED?

Thank you and pardon the multiple que= stions!

--
Farhan Khan
PGP Fingerprint: 1312 89CE 663E 1EB2 179C 1C83 C41D 2281 F8DA C0= DE


--5950a9e3350143c090d056536e154453--