From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7B63AC433F5 for ; Fri, 4 Mar 2022 14:20:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235076AbiCDOVC (ORCPT ); Fri, 4 Mar 2022 09:21:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58032 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231664AbiCDOVB (ORCPT ); Fri, 4 Mar 2022 09:21:01 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 30D851BA92A for ; Fri, 4 Mar 2022 06:20:14 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C1812617E4 for ; Fri, 4 Mar 2022 14:20:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 43B45C340E9; Fri, 4 Mar 2022 14:20:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646403613; bh=82RHPbKYaBxahcxTnnqX7gZSoXp6vzfHXkknNkVXsIM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Otzd1uMpSaT8Fhgw7h78oksXKn9VhihG5rD1+6kjPE0uuA7EksPwgd/5G0OmSPh1S 0JR5d/CyxBf9C4ueQCw5XmowFwO7pdtyHjzROdPfebB1f/HyqdaqEA5ZSbphtudjNe ipnGUcJRZ+DtwzQY6oiyZqvtZDkfBi+NTpBi5Z2A= Date: Fri, 4 Mar 2022 15:20:08 +0100 From: Greg Kroah-Hartman To: Vincent Mailhol Cc: linux-usb@vger.kernel.org, Jiri Kosina , Benjamin Tissoires , Ville Syrjala , Dmitry Torokhov , Henk Vergonet , Sean Young , Mauro Carvalho Chehab , Benjamin Valentin , Oliver Neukum , "David S. Miller" , Jakub Kicinski , Woojung Huh , Felix Fietkau , Lorenzo Bianconi , Ryder Lee , Kalle Valo , Matthias Brugger , Stanislaw Gruszka , Helmut Schaa , Duncan Sands , Alan Stern , Olav Kongas , Rui Miguel Silva , Jaroslav Kysela , Takashi Iwai , Clemens Ladisch , UNGLinuxDriver@microchip.com, Shayne Chen , Sean Wang , Leon Romanovsky , Hans Verkuil , Kees Cook , Zheng Yongjun , Thomas Toye , Mathias Nyman , Thinh Nguyen , Kai-Heng Feng , Chris Chiu , Rajat Jain , Kelly Devilliv , Shubhankar Kuranagatti , Cai Huoqing , Geert Uytterhoeven , "Gustavo A. R. Silva" , Lad Prabhakar , Will Deacon , Davidlohr Bueso , Mark Tomlinson , Peter Zijlstra , Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , Arnd Bergmann , Wei Yongjun , Colin Ian King , Len Baker , gushengxian Subject: Re: [PATCH] usb: rework usb_maxpacket() and remove its third argument Message-ID: References: <20220304105420.1059585-1-mailhol.vincent@wanadoo.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220304105420.1059585-1-mailhol.vincent@wanadoo.fr> Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org On Fri, Mar 04, 2022 at 07:53:50PM +0900, Vincent Mailhol wrote: > Change the prototype of usb_maxpacket() from: > | static inline __u16 > | usb_maxpacket(struct usb_device *udev, int pipe, int is_out) > > into: > | static inline u16 usb_maxpacket(struct usb_device *dev, int pipe) > > and rewrite the function. > > Rationale: > > * The third argument of usb_maxpacket(): is_out can be derived from > its second one: pipe using usb_pipeout(pipe). Furthermore, > usb_pipoout(pipe) is being called within usb_maxpacket() > regardless to confirm the input. > > * This function is not exposed to the UAPI so return type should be > u16, not __u16. > > * Let's not reinvent the wheel and rely on usb_endpoint_maxp() to > make this a one liner function. > > All the users of usb_endpoint_maxp() are then updated. > > Two of the users: oxu210hp-hcd.c and isp1760-hcd.c rely on a local > macro: max_packet() to mask the maximum size. Because this masking is > already performed by usb_maxpacket(), this patch also removes these > redundant sanitization and remove the local macro if not needed any > more (keep it in oxu210hp-hcd.c which uses it elsewhere but remove it > in isp1760-hcd.c). This type of "change all callers of this function" is brutal to do like this, as is evident by the number of people you had to cc: here. How about doing it the normal way. Create a new function, with the proper options you wish to see be used, and then move everyone over to it, and when that is done, remove the old function. Bonus points for doing this with some crazy macros to keep the old name in the end (it can be done, but I don't recommend it for the faint-of-heart, so it's not required.) thanks, greg k-h