From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1F75B411FA6 for ; Mon, 3 Aug 2026 12:46:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785761217; cv=none; b=RwJUxPrj+oNMf5bz8La+MmlckDRoXqpssL0osW8VbzbSQwthVCvcDL7NIywAO4OqRSzQ7IUToqLFipKDrHxosAhw9oiFd8S/AbTv5XtOPhgumxChzi8IJmuVcrG9su35o1UjZ97+pM2vnNeS5m1Dau+YctFRahnoUxXLUaOlEfQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785761217; c=relaxed/simple; bh=3t2Y19LKMm77Slx5NukqzKKFy6+5z1A41mGry0j7HLY=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=LUf2XGwzytUjBNc0A7pKwtPDIMgSZvyl/daxxaqhDk14Y9Oe2hvCYfByTu6+cOA890trIKXk5RsY8MnUqyHB+TE6v19X36d5uaLf9r2qMAieb56+XYJ4893ZJ9VqK6ttCrGkaQBFViJYEwZ/sr0jhgdM2j9whxKfjbD9C/lnJ0Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=wyliodrin.com; spf=pass smtp.mailfrom=wyliodrin.com; dkim=pass (1024-bit key) header.d=wyliodrin.com header.i=@wyliodrin.com header.b=LvlzEj+u; arc=none smtp.client-ip=209.85.128.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=wyliodrin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=wyliodrin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=wyliodrin.com header.i=@wyliodrin.com header.b="LvlzEj+u" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4921eed3fa2so11128925e9.0 for ; Mon, 03 Aug 2026 05:46:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wyliodrin.com; s=google; t=1785761214; x=1786366014; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=eTIIU0RK6De8tsthf1eFYkTZzNYuQyIWVcByhEPLnjo=; b=LvlzEj+utmZe7TfshZDJHNYEQjGPFPwLrfiSYVzqwHM+9C0WbvGt0FTksPy1vx85Zc s5QPSZh5uI0lU0zXe9ApobOQyWx6KpIAfwAipsbGyjIBlbjM89LrvRRtrE7r6u8BOcoj b/NML6QqiV9XnmrHRsHWVlvCKwdFhIxoz2230= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785761214; x=1786366014; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=eTIIU0RK6De8tsthf1eFYkTZzNYuQyIWVcByhEPLnjo=; b=nDIIUvFGr/yNO78ag0aZ66S/tEe1sjXofTVpCh/4n5W+md5aXpviUY1AspeL8wD1M5 un98zIj3E3ndj//tuMnMxP5854lkoxshF4VoI1JjF225lNrY2bHi2JdGl1/aShNqaiUV QN0IIfCKwHaNB0hmxA1/14E6kCoOjPvQ5Cm+Ptc1421gR1ySHIPzOZLo1gSFHL7LlWfK LH3QCscKLZBMY9XsclUZWFgf5VYon3hEb5rWDVd5zJWKDkGk/yzaQQeQyDIjJMdkvC+V Uzr02nNfB2n005ZhLvOzJI/oXwwzsYtlu61sQ+Zo1MQFZlMZEp/QFa2viVqNoOOOsJYJ +9gQ== X-Forwarded-Encrypted: i=1; AHgh+RqD1jhPBncoGEZsuqfLYvNPtRcjyc8pcL6Me/vfedAoZ4mxkcUScmKWardJBPzOCMJ7/kpYb1jOfU9bbN8=@vger.kernel.org X-Gm-Message-State: AOJu0Yz7PARYzYsv6dyqBjXNJ8xXCTTvE8eWcB+M1Pu+5dAHtFDh8esO kwyqOlTnhMCndJ+F2gumdcnEcxrbCknPwfaJ8wfKFaVH/M+bQtJVHjkAlgB24IBgT9I= X-Gm-Gg: AR+sD125CaLgPPlkJMbr8gHNWwoNPVUKI88kqpfaC9epEkGhfrg0oftlIzK3rhXbW3T /AnQNRBnCbIpN1vX+d0lb0XZveP7G3a5z02OYt2gc5IZhQ7bxjUB7OYqcFOd9G0FoxisI4agRzn 3EfqdKajAIdaBpk5YznQSD8yij1rnt1yljsKAicVHTxEUu+pZCbDZaLN75Av6lx7MXmLmmFrQx3 UMoQI669scib37AysKB3sUsVK+C19P+zkkeUesdR0oyTZjy5Xh2pf38Ie4SKTLXad2Q/ac9pfFu X79H1b+Ak5hb//E3o7hdQGcUa/jkH0AL9c7dqgJZGGRF+GTYXHQF7FOyLyCSxeO6Gpxf0USHhRa QN2H03G6s+tkcmYmdtkfqAG8rkUdW5o1cq+ZIo9T2Hfiz7nUpQ1gux1gOAmWLktz4Ad9Oy9lmlf 58v8VmvGY2Pq6pZcjaThgK6nrxEmNg13sbXYmmDgN6L/R+oO86zQBsKSiVdgqa0zY62wtLteuYT VNwhQKPI96pH1mXgWGcpDoNHIgigmwYQA== X-Received: by 2002:a05:600c:5494:b0:493:bfad:9d99 with SMTP id 5b1f17b1804b1-4980c679d64mr214413325e9.13.1785761214212; Mon, 03 Aug 2026 05:46:54 -0700 (PDT) Received: from localhost ([217.73.170.83]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49807b85be7sm278310995e9.2.2026.08.03.05.46.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 Aug 2026 05:46:53 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 03 Aug 2026 15:46:44 +0300 Message-Id: Cc: "Miguel Ojeda" , "Boqun Feng" , "Gary Guo" , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , "Benno Lossin" , "Andreas Hindborg" , "Alice Ryhl" , "Trevor Gross" , "Danilo Krummrich" , "Daniel Almeida" , "Tamir Duberstein" , "Alexandre Courbot" , =?utf-8?q?Onur_=C3=96zkan?= , , , Subject: Re: [PATCH RFC 1/2] rust: usb: add endpoint abstraction From: "Alrexandru Radovici" To: "Greg Kroah-Hartman" , "Alexandru Radovici" X-Mailer: aerc 0.21.0 References: <20260801-rust-usb_control_msg-v1-0-655bb444b52c@wyliodrin.com> <20260801-rust-usb_control_msg-v1-1-655bb444b52c@wyliodrin.com> <2026080205-falsify-stalemate-175b@gregkh> In-Reply-To: <2026080205-falsify-stalemate-175b@gregkh> On Sun Aug 2, 2026 at 11:39 AM EEST, Greg Kroah-Hartman wrote: > On Sat, Aug 01, 2026 at 03:01:07AM +0300, Alexandru Radovici wrote: >> Add an abstraction for `struct usb_host_endpoint`, together with the >> accessors needed to reach one: `AlternateSetting` wrapping >> `struct usb_host_interface`, `Interface::alternate_settings()` and >> `Interface::current_alternate_setting()`, and `Device::control_endpoint(= )` >> for the default control endpoint, which no interface descriptor lists. > > Why? USB drivers shouldn't be messing with usb_host_endpoint structures > for the most part, what user do you have for this? The more I think of this, I think you are right. `HostEndpoint`'s accessor methods are only used for debug, as the `kernel` crate can access the actual `usb_host_endpoint` underneeth. For debug purposes, we should just derive the `Debug` trait instead. > >> `HostEndpoint` is generic over two sealed marker traits, >> `EndpointDirection` and `EndpointTransferType`, whose implementors are >> 1-ZSTs held in `PhantomData`. An endpoint borrowed from an alternate >> setting starts out generic in both; `as_in()`, `as_out()` and >> `as_control()` check the descriptor once and return a reference >> carrying the corresponding marker, so a function taking >> `&HostEndpoint` needs no check of its own. The type is >> `#[repr(transparent)]` over the C struct and the markers are >> zero-sized, so the refinement costs nothing and a slice of endpoints >> can be borrowed directly from the C array. >>=20 >> Control endpoints get a distinct `Bidirectional` marker rather than an >> IN or OUT one. A control transfer takes its direction from bit 7 of the >> setup packet's bmRequestType, and USB 2.0 section 9.6.6 defines the >> corresponding bit of bEndpointAddress as ignored for control endpoints. >> `as_in()` and `as_out()` are not implemented for `Bidirectional`, making >> calling them a compile error rather than a misleading result. > > Don't over-think USB endpoints, they are "just" a pipe that contain a > numbering scheme that the USB core uses. Is that what you are trying to > create here? What are you trying to "enforce" here that the C code does > not already do? My USB knowledge is limited, so I hope I am not saying something stupid here. My understanding is that drivers should not expect interfaces to map the same endpoints (numbers) every time. A driver should expect an interface to expose a certain number of endpoints, each one with a certain type, but the actual number of each exposed endpoint is not to be considered hardcoded. This means that drivers should anyway iterate over the endpoints to discover the numbers of the required endpoints. My idea is to leaverage Rust's type system to prevent users from supplying the wrong endpoint type at compile time rather then at runtime. By making the `HostEndpoint` its own Rust type with no public constructor, users will be forced to iterate the endpoints to discover the correct number for each endpoint that they require. Once they have it, users can hold to the reference as long as the interface is valid. By adding the `Dir` and `Type` generic markers, suplying the wrong endpoint to a function will be caught at compile time rather than at runtime. This should hopefully shorthen the debug work needed for a driver, as some of the errors become impossible. As endpoint 0 is always provided and basically _almost hardcoded_``, I adde= d the `control_endpoint` function.=20 Best regards, Alexandru