Re: [RFC/PATCH 0/4] usb: core: Add Support for getting PTM_STATUS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 26 Oct 2017, Felipe Balbi wrote:

> Felipe Balbi <felipe.balbi@xxxxxxxxxxxxxxx> writes:
> 
> > Hi,
> >
> > Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes:
> >> On Wed, 25 Oct 2017, Felipe Balbi wrote:
> >>
> >>> Hi,
> >>> 
> >>> The following series was compile-tested only (so far, at least). I
> >>> wanted to get some comments from folks to see what you guys think
> >>> about this before running tests.
> >>> 
> >>> I don't have any device available which would support PTM_STATUS so I
> >>> guess I'd have to implement it on g_zero, if at all possible.
> >>> 
> >>> Best Regards
> >>> 
> >>> Felipe Balbi (4):
> >>>   usb: core: add Status Type definitions
> >>>   usb: core: rename usb_get_status() 'type' argument to 'recip'
> >>>   usb: core: add a 'type' parameter to usb_get_status()
> >>>   usb: core: add two usb get status helpers
> >>
> >> You should switch the order of patches 3 and 4.  That is, replace
> >> usb_get_status() with usb_get_std_status() first, and then add the type
> >> parameter and the other helper routine.  That way you won't have to
> >> update all the callers twice.
> >
> > heh, good point :-)
> 
> Actually, without patch 3 where it is, I won't have the new 'type'
> parameter to write the helpers. What I could do, is in a single patch
> add the helpers (and the new argument) while also converting all current
> users to usb_get_std_status(). That would basically be a combination of
> patches 3 and 4.

Make patch 3 add the first helper (usb_get_std_status) and convert all
the callers.  The helper can simply call the existing routine, with no
extra argument.

Then patch 4 will add the extra argument and the new helper.  It won't 
have to update the callers at all, just change the first helper.

As for inlines, I don't really care much either way.  Do whatever you 
think is best.  (But I do not believe the compiler will inline the 
routines automatically if they are defined in a separate .c source 
file.)

Alan Stern

> The resulting patch would be that large, actually. See diffstat below:
> 
>  drivers/staging/wlan-ng/hfa384x_usb.c |  8 ++++----
>  drivers/usb/core/driver.c             |  4 ++--
>  drivers/usb/core/hub.c                | 13 ++++++------
>  drivers/usb/core/message.c            | 62 +++++++++++++++++++++++++++++++++++++++++++++++++-------
>  drivers/usb/misc/usbtest.c            | 10 ++++++---
>  include/linux/usb.h                   |  5 ++++-
>  6 files changed, 79 insertions(+), 23 deletions(-)
> 
> However it's a little more changes in a single patch. Your call, I'm
> fine either way :-)

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux