Hi again, Felipe Balbi <balbi@xxxxxxxxxx> writes: > Linyu Yuan <quic_linyyuan@xxxxxxxxxxx> writes: >> add trace in function gadget_dev_desc_UDC_store() >> will show when user space enable/disable the gadget. >> >> Signed-off-by: Linyu Yuan <quic_linyyuan@xxxxxxxxxxx> >> --- >> drivers/usb/gadget/Makefile | 1 + >> drivers/usb/gadget/configfs.c | 3 +++ >> drivers/usb/gadget/configfs_trace.c | 7 +++++++ >> drivers/usb/gadget/configfs_trace.h | 39 +++++++++++++++++++++++++++++++++++++ >> 4 files changed, 50 insertions(+) >> create mode 100644 drivers/usb/gadget/configfs_trace.c >> create mode 100644 drivers/usb/gadget/configfs_trace.h >> >> diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile >> index 130dad7..8e9c2b8 100644 >> --- a/drivers/usb/gadget/Makefile >> +++ b/drivers/usb/gadget/Makefile >> @@ -9,5 +9,6 @@ ccflags-y += -I$(srctree)/drivers/usb/gadget/udc >> obj-$(CONFIG_USB_LIBCOMPOSITE) += libcomposite.o >> libcomposite-y := usbstring.o config.o epautoconf.o >> libcomposite-y += composite.o functions.o configfs.o u_f.o >> +libcomposite-y += configfs_trace.o >> >> obj-$(CONFIG_USB_GADGET) += udc/ function/ legacy/ >> diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c >> index 477e72a..f7f3af8 100644 >> --- a/drivers/usb/gadget/configfs.c >> +++ b/drivers/usb/gadget/configfs.c >> @@ -9,6 +9,7 @@ >> #include "configfs.h" >> #include "u_f.h" >> #include "u_os_desc.h" >> +#include "configfs_trace.h" >> >> int check_user_usb_string(const char *name, >> struct usb_gadget_strings *stringtab_dev) >> @@ -270,6 +271,8 @@ static ssize_t gadget_dev_desc_UDC_store(struct config_item *item, >> if (name[len - 1] == '\n') >> name[len - 1] = '\0'; >> >> + trace_gadget_dev_desc_UDC_store(config_item_name(item), name); > > why tracing only the names? This gives us no insight into whatever bug > may happen and we may want to use trace events to debug. Rather, try to > think of trace events as tracking the lifetime of the UDC and > gadget. Trace values that may change over time. > > I also think that all three patches could be combined into a single > commit, but that's up to discussion. nevermind this last paragraph, just saw that Greg asked you to split ;-) The first paragraph remains valid, though -- balbi
