From nobody Tue May 17 06:18:08 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 B56801B3539E for ; Tue, 17 May 2022 06:18:17 +0000 (UTC) (envelope-from farhan@farhan.codes) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) (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 4L2Qsh6WSdz3p9M for ; Tue, 17 May 2022 06:18:16 +0000 (UTC) (envelope-from farhan@farhan.codes) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.nyi.internal (Postfix) with ESMTP id 52A9358011C; Tue, 17 May 2022 02:18:10 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 17 May 2022 02:18:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=farhan.codes; h= cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; t=1652768290; x= 1652775490; bh=c6kcM2QSM3NV5LwWUnbGTIiIQ9DLJMbrezY6c1tAE2I=; b=g MjOOWMcOFyiQNqAn2F26xosNjSO8U5tez3FjXBoAUrCMxwKTyDd6LGnPifHhKvHR Zpb4BNxt+TDaVeF3ih9Co+nn432UG0pJ21IVDX69IAY8VVo+s0l5fPwIQtmYtiF8 8YQHuc4USdXWvc+aexfuS7qTcLXtFwv4iPGdo/qkMpPllZtZsaEbxMcvsBbrHQzd 7jH03D+f3TRuudQuAVHORdWZ4KN2OpDRTYQTWZsHA8XepSnglBinufRBe1yRTgmE p6U+/Mz8Ud+e0PuasOn0dv76se/Nj891yYdInnUc0ZADZPC6VkhhABk3kwjHEXSe JT9E8MoekH8emHFnOwdyw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1652768290; x=1652775490; bh=c 6kcM2QSM3NV5LwWUnbGTIiIQ9DLJMbrezY6c1tAE2I=; b=lOtpLgJSYbuDHMH/7 T1Tp1xyRm7VQ4N4cNzXbG+z+T4T7IO1EuozFdPlg/IBcy5QRaIxVaMlZTyKYn1PT J4ZoS+nDzWq7O9uJQle5NxyBuc8HaH2M2PszkI+4goY2fNMYZwQBXlGFYULhjsP6 7EkutoEWxTZVjbFQ8Azk+eHTFT0YQeu3Pu5kBfiCMfbVbUqsVgqWKQjcriyJUhOr ojJKvNvecXHCB32HESmBb7HsnPkauRT/RXkijaLA5Fntl/P5WjcbWm1OJPwvmyP3 5SV6UzbQTdS6DTiBN4Y4sCQV9B9CT0HMncDO83HPf+11w48hguF80JTGYvj4RCaA 1BS8g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrheeigddutdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkjghfggfgtgesthfure dttddtvdenucfhrhhomhephfgrrhhhrghnucfmhhgrnhcuoehfrghrhhgrnhesfhgrrhhh rghnrdgtohguvghsqeenucggtffrrghtthgvrhhnpeevvddvuefgjeekgeeuveefgfevfe evgfdvheejtddtvddtveehudekteeiueeuhfenucffohhmrghinheptghouggvrdhinhen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehfrghrhh grnhesfhgrrhhhrghnrdgtohguvghs X-ME-Proxy: Feedback-ID: i61914458:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 17 May 2022 02:18:09 -0400 (EDT) From: Farhan Khan To: freebsd-usb@freebsd.org, Hans Petter Selasky Subject: Re: Tx transfer not triggering corresponding Rx interrupt Date: Tue, 17 May 2022 02:18:08 -0400 Message-ID: <1861859.taCxCBeP46@fedora> In-Reply-To: <3c198f9b-724e-c482-5b12-344bc3fa5d96@selasky.org> References: <2550661.Lt9SDvczpP@fedora> <3c198f9b-724e-c482-5b12-344bc3fa5d96@selasky.org> 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 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Rspamd-Queue-Id: 4L2Qsh6WSdz3p9M X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=farhan.codes header.s=fm2 header.b="g MjOOWM"; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=lOtpLgJS; dmarc=none; spf=pass (mx1.freebsd.org: domain of farhan@farhan.codes designates 66.111.4.224 as permitted sender) smtp.mailfrom=farhan@farhan.codes X-Spamd-Result: default: False [-3.27 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[farhan.codes:s=fm2,messagingengine.com:s=fm1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.224]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_NA(0.00)[farhan.codes]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[farhan.codes:+,messagingengine.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.67)[-0.671]; MLMMJ_DEST(0.00)[freebsd-usb]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; CTE_CASE(0.50)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.224:from] X-ThisMailContainsUnwantedMimeParts: N On Monday, May 16, 2022 9:52:14 AM EDT Hans Petter Selasky wrote: > On 5/15/22 04:41, Farhan Khan wrote: > > Hi all, > > > > I am trying to understand why a USB Rx interrupt callback is not > > triggering. I am sending a USB Tx interrupt packet. The immediate next > > step is that the function will msleep(). The corresponding wakeup() > > occurs after an Rx interrupt. > > > > There is no explicit usbd_transfer_start() on the Rx interrupt. Elsewhere > > in the code there is an instance where an Tx interrupt should eventually > > result in a corresponding Rx interrupt that results in a wakeup(). That > > does not occurs here and I do not understand why not. > > Hi Farhan, > > OpenBSD and NetBSD it is simply different than in FreeBSD, so you need > to start all transfers that should receive or transmit data. I did this. No change in behavior. > > Problem: > Can you use these terms instead: > > IN packet (from device to host) > OUT packet (from host to device) > > Else I get confused what direction traffic is flowing. > > RX/TX terms are always relative to the local code. > > IN / OUT is fixed. Pardon, I will use IN/OUT. But you are correct, I intended Tx and Rx to be relative to the host. So Tx means OUT (from Host to device) and Rx means IN (from device to host). > > The msleep() located on line 1314 fails with EWOULDBLOCK. > > This sleep seems to be the equivalent of the acknowledgement that the Tx > > interrupt packet was received. > > > > ----------- > > Expected: > > > > I expect this to somehow result in the Rx interrupt, which runs the > > corresponding handler athn_usb_intr(). This function contains the wakeup() > > line on line 2556 (the AR_HTC_MSG_CONN_SVC case). > > > > ----------- > > This happens elsewhere: > > > > In athn_usb_load_firmware(), line 1011, there is a usbd_do_request(), > > followed by an msleep(). The wait_msg_id is AR_HTC_MSG_READY. The wakeup > > for this occurs only after an Rx interrupt is called on line 2538. > > > > ----------- > > Question rephrased: > > > > Why is a USB transfer resulting in an Rx interrupt in one place, even > > though a usbd_transfer_start() is not called on the Rx interrupt, but not > > for athn_usb_htc_connect_svc()/athn_usb_htc_msg()? > > > > How do I make this Tx transfer result in an Rx interrupt without having to > > manually call usbd_transfer_start() (OpenBSD does not appear to do this?) > > Because the USB stack is not the same! You need to study FreeBSD's USB > stack a bit more and you'll figure out. I have been reading example code and documentation for weeks now. This behavior is not documented anywhere. > > I do not understand the differences between usbd_do_request, > > usb_transfer_start and usbd_setup_xfer/usbd_transfer that might be > > resulting in different behavior, so any light on that would also help. > > usbd_do_request() is only for synchronous transfers on endpoint zero, > the control endpoint. It is a handy function to avoid allocating and > freeing USB transfers over and over again. Does this also result in automatic Rx/IN interrupt callbacks? If not, why is this happening? > > Function names might be similar, but the behaviour is very different! > > > ----------- > > Been stuck for some time, so any assistance is appreciated. > > Thank you! > : > :-) > > --HPS Do you have office hours during which we can speak? Perhaps IRC? I have asked this question a few times and I'm not getting it sufficiently answered. I suspect it is due to us getting lost in the details rather than focusing on the question. I apologize, my emails have been very verbose and perhaps unfocused. I'll try to keep this simple: In my driver I call usbd_do_transfer() followed by a msleep() **WITHOUT** calling usbd_transfer_start on the Rx/IN interrupt. The Rx/IN interrupt is necessary to run the associated wakeup(). This suggests the Rx/IN callback is happening, yet I see the callback for the Rx/IN interrupt happening. This is what I want to occur, but why is this happening **WITHOUT** being called? Similarly, is there a way to have an Rx/IN interrupt trigger after receiving a USB packet **WITHOUT** manually calling usbd_transfer_start() the way it is done with usbd_transfer_start()? The `interval` parameter, which seems like it should execute the callback on a regular interval, does not do anything at all. If I can get this question explained, I can hopefully make progress. Otherwise, I'm stuck and this seems like undocumented or inconsistent behavior. Failed strategies so far: * Manually calling the Rx/IN interrupt, changing msleep time to 10 seconds - Rx/IN callback happening late for some reason. And this just seems wrong. * Calling Rx/IN from within the Tx/OUT callback - Not possible due to mutex. Just to confirm, the device is sending the host an Rx/IN packet, I confirmed this with wireshark. Very stuck and confused :( - Farhan