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 7EEB3C433EF for ; Fri, 4 Mar 2022 17:24:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231638AbiCDRYs (ORCPT ); Fri, 4 Mar 2022 12:24:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49326 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230213AbiCDRYr (ORCPT ); Fri, 4 Mar 2022 12:24:47 -0500 Received: from mail-yw1-f174.google.com (mail-yw1-f174.google.com [209.85.128.174]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6086E156C75 for ; Fri, 4 Mar 2022 09:23:59 -0800 (PST) Received: by mail-yw1-f174.google.com with SMTP id 00721157ae682-2dc28791ecbso85459907b3.4 for ; Fri, 04 Mar 2022 09:23:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fG19ikPUR6MlFUzUu5C8Yp2dYlinRGD24BB+wEQPspM=; b=t3mJ2ifw/3zmfyjJcV82U6U98r9hZDwgKDapznAiVSEFzDDiFCpERREXu6500mRCQS H6lB/34IPKyU8qgZidG4OH7MOHmRanRLsWY76kfx9b0dPG0NNhVI/ckr2tLDj+qLuw/u z++aIXqcJHGW8lAyio688M2Cf0qaNAPAE+GGiuPQ9P/wCgBmqSsP0gf/vf1nd+1GlO2B ZVNUj4U9Np8vW0eavDtcQrZuSqclrw+eferK12AVJbWHXWBvrXyc347bfb3vvteg8DAj jAgAucDIuRZyDatM4MlKxvCOaiBzORf1zublj1E9N3Y1NA4WF46TDy0ZUKmttetiF4tZ mehQ== X-Gm-Message-State: AOAM533n1NIeYNN31bDdBD81KJTztdH/SOZobuPdRDHvLhuY2ccAEdd7 IfkIC0NEeqakkq015hA1CO66PjTkNitnxrTAqV14touGWG8= X-Google-Smtp-Source: ABdhPJykaTI5dihl88vmURyShlsZpRxOBIrZlqA8FJi8YKVr7Pk4utfUgjYWnJ7kqyNBrq2fQwAJMjAjXazB+0dBP4E= X-Received: by 2002:a81:6bc6:0:b0:2db:fe24:d5ee with SMTP id g189-20020a816bc6000000b002dbfe24d5eemr16583360ywc.392.1646414637996; Fri, 04 Mar 2022 09:23:57 -0800 (PST) MIME-Version: 1.0 References: <20220304105420.1059585-1-mailhol.vincent@wanadoo.fr> In-Reply-To: From: Vincent MAILHOL Date: Sat, 5 Mar 2022 02:23:46 +0900 Message-ID: Subject: Re: [PATCH] usb: rework usb_maxpacket() and remove its third argument To: Greg Kroah-Hartman Cc: linux-usb@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org On Fri. 4 Mar. 2022 at 23:20, Greg Kroah-Hartman wrote: > 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.) Thank you for the explanation :) If I understand correctly, I should: * First change linux/usb.h * Wait for other trees to pull the patch * Change the drivers * Clean up linux/usb.h I did not find the inspiration for a better name so I would like to keep the old one. Would the below code meet your expectation of "doing some crazy macros"? | static inline u16 __usb_maxpacket(struct usb_device *dev, int pipe) | { | return usb_endpoint_maxp(&usb_pipe_endpoint(dev, pipe)->desc); | } | | #define usb_maxpacket(dev, pipe, deprecated...) __usb_maxpacket(dev, pipe) Thank you, Yours sincerely, Vincent Mailhol