RE: [PATCH] usb: gadget: make f_loopback/f_sourcesink standalone

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

 



> From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> Sent: Thursday, May 12, 2022 12:48 PM
> To: Linyu Yuan (QUIC) <quic_linyyuan@xxxxxxxxxxx>
> Cc: Felipe Balbi <balbi@xxxxxxxxxx>; linux-usb@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH] usb: gadget: make f_loopback/f_sourcesink standalone
> 
> On Thu, May 12, 2022 at 04:20:32AM +0000, Linyu Yuan (QUIC) wrote:
> > > From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> > > Sent: Thursday, May 12, 2022 12:10 PM
> > > To: Linyu Yuan (QUIC) <quic_linyyuan@xxxxxxxxxxx>
> > > Cc: Felipe Balbi <balbi@xxxxxxxxxx>; linux-usb@xxxxxxxxxxxxxxx
> > > Subject: Re: [PATCH] usb: gadget: make f_loopback/f_sourcesink
> standalone
> > >
> > > On Thu, May 12, 2022 at 10:21:34AM +0800, Linyu Yuan wrote:
> > > > First remove lb_modinit() and lb_modexit() call from f_sourcesink as
> both
> > > > function belong to f_loopback.c, also there is no need to export
> > > > disable_endpoints() from f_sourcesink, change it to static type.
> > > >
> > > > After first step, we can use DECLARE_USB_FUNCTION_INIT() macro in
> > > > f_sourcesink to create module init/exit function implicit as it only
> > > > register/unregister one usb function driver.
> > > >
> > > > In f_loopback disable_loopback() function, just add two
> usb_ep_disable()
> > > > call, it will safe to remove original disable_endpoints() call
> > > > which belong to f_sourcesink, and it also safe to use macro
> > > > DECLARE_USB_FUNCTION_INIT() for module init/exit purpose.
> > > >
> > > > Now it is safe to remove function prototype of lb_modinit(),
> > > > lb_modexit() and disable_endpoints() from g_zero.h.
> > > >
> > > > Change Makefile to build f_loopback/f_sourcesink as standalone
> module.
> > >
> > > This describes a lot of what you are doing, but not why you want to do
> > > any of this.
> > >
> > > Please read the kernel documentation for how to write a good kernel
> > > changelog, as-is, I do not understand why this change should be accepted
> > > at all.
> >
> > Can you share more about it ? is it description reason or code change itself  ?
> 
> Here's the relevant text from my patch bot, which I should have
> triggered for this submission, that explains it a lot better:
> 
> -----------
> 
> - You did not specify a description of why the patch is needed, or
>   possibly, any description at all, in the email body.  Please read the
>   section entitled "The canonical patch format" in the kernel file,
>   Documentation/SubmittingPatches for what is needed in order to
>   properly describe the change.
> 
> - You did not write a descriptive Subject: for the patch, allowing Greg,
>   and everyone else, to know what this patch is all about.  Please read
>   the section entitled "The canonical patch format" in the kernel file,
>   Documentation/SubmittingPatches for what a proper Subject: line should
>   look like.
> 
> ---------------
> 
> Does that help?

Got it,

Or not I think I made some cray thing that you said
"I do not understand why this change should be accepted at all"

> 
> greg k-h




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

  Powered by Linux