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? greg k-h
