From nobody Sun May 15 02:41:57 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 48D401AEE520 for ; Sun, 15 May 2022 02:41:59 +0000 (UTC) (envelope-from farhan@farhan.codes) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L16924gpmz4Z7g for ; Sun, 15 May 2022 02:41:58 +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 7FC185C0083 for ; Sat, 14 May 2022 22:41:58 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sat, 14 May 2022 22:41:58 -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:message-id:mime-version:reply-to:sender:subject :subject:to:to; s=fm2; t=1652582518; x=1652668918; bh=9zIB3hOcOb UG9quaMf4E7c0pvbzIECERg14QZNSeGRU=; b=Kzrjg+9kRjf+ghwfh86d82VkVf F/lueR3AONPKjXVdecQyUAAUpneHrl21yobDFc+xYhBEbrVtB1VHp4eaWWXPSoQk ze2s01Zb5ApHitAZDg8egokQJ4oyi3JxR0WvH5pUO5UUWphxjVHVPRNS4C0UWPAw c/5qU3sHYaTeSeDtefWkfsq4AC0Mq/yjRIH5L4cJndAYMYSrVJlQq5hjuDYaWlH3 qfrMvFociRcZbj1tgAqziIDUtyHbGV5NYhQYP2UyOYqODV1e4QYU35gSeQMnOEZf BYCSwEc3u/hclUmUjv6hNIwyjmrqEYoGrz93Z4qI/HAJwMKQWYqmVnSfoV0w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=fm1; t=1652582518; x= 1652668918; bh=9zIB3hOcObUG9quaMf4E7c0pvbzIECERg14QZNSeGRU=; b=O w+6lLY7VQkNupHLKwrnnsslMAnjBLAY5NHDycYfMx/o2TFDbAHxvwu1sW2/pj+N9 hy2E6mkHldvcysvQ2pO4ZrsHqLqWN/Qsyu7CF18jGKplmx4/G+wB/9kf+RQh40Pr zr1nMDW7Hrit8mE522YWUu0qAJQ7pqYKw8oy7uWuU4Ss8GiNiYsbGcPjQ0h4N5Kz B4dz/l6l3f2PPXymWPnw7iCj/SFzdVwLaAvmigaccqSSwbDnH37Y/15bUYKYVQx5 lGagvZHDDq21UpfmH3R91ml6kzs9+Rb8P17dBl29Us6k7XSbkEdKcDk41uOBj3aT 7Lc9OrjzHOCBkIWuiTt9A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrhedvgdehfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkfgggfgtsehtufertddttd dvnecuhfhrohhmpefhrghrhhgrnhcumfhhrghnuceofhgrrhhhrghnsehfrghrhhgrnhdr tghouggvsheqnecuggftrfgrthhtvghrnhepvdejkeetffelieejleeiffelfefhieeuge ejteekiedvudduhedvhfeggfehgedunecuffhomhgrihhnpehgihhthhhusgdrtghomhen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehfrghrhh grnhesfhgrrhhhrghnrdgtohguvghs X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sat, 14 May 2022 22:41:58 -0400 (EDT) From: Farhan Khan To: freebsd-usb@freebsd.org Subject: Tx transfer not triggering corresponding Rx interrupt Date: Sat, 14 May 2022 22:41:57 -0400 Message-ID: <2550661.Lt9SDvczpP@fedora> 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: 4L16924gpmz4Z7g X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=farhan.codes header.s=fm2 header.b=Kzrjg+9k; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="O w+6lLY"; dmarc=none; spf=pass (mx1.freebsd.org: domain of farhan@farhan.codes designates 66.111.4.27 as permitted sender) smtp.mailfrom=farhan@farhan.codes X-Spamd-Result: default: False [-3.59 / 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_LONG(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.27]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-usb@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_NOT_FQDN(0.50)[]; DKIM_TRACE(0.00)[farhan.codes:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[farhan.codes]; NEURAL_HAM_MEDIUM(-0.99)[-0.988]; 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.27:from] X-ThisMailContainsUnwantedMimeParts: N 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. ----------- Background: I am working on porting OpenBSD's athn(9) driver to FreeBSD. I loaded the firmware and I believe this is confirmed by sending a AR_HTC_MSG_READY message, which is https://github.com/khanzf/freebsd/blob/ 0ba9a9b92df496847058008598139e92f5e60850/sys/dev/athn/usb/if_athn_usb.c#L1009. There is an associated msleep() and wakeup() that suggest the firmware was successfully loaded. The wakeup occurs in the Rx interrupt handler. Then, there is a section where the driver sets up the Host Transport Communication (HTC) interface. The driver does a transfer of data of the Tx Interrupt, then immediately runs msleep(). The corresponding wakeup occurs when an Rx (not Tx) interrupt triggers and is processed. The code for this is located in athn_usb_htc_connect_svc(). My current implementation is here: https://github.com/khanzf/freebsd/blob/ 0ba9a9b92df496847058008598139e92f5e60850/sys/dev/athn/usb/if_athn_usb.c#L1293 The OpenBSD implementation is here: https://github.com/openbsd/src/blob/ 72a0854b669a0194895eeac5ffcdf5fc27bf2a30/sys/dev/usb/if_athn_usb.c#L809 Please note that in the OpenBSD implementation, the athn_usb_htc_msg() function calls usbd_setup_xfer/usbd_transfer, whereas my implementation calls usbd_transfer_start(). Also, OpenBSD opens the Rx Interrupt pipe with usbd_open_pipe_intr(), which gives the option for an interval. I suspect this is the same as the `interval` parameter in usb_config. I do not know if this is significant. ----------- Problem: 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?) 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. ----------- Been stuck for some time, so any assistance is appreciated. Thank you! - Farhan