On Mon, Jun 15, 2026 at 06:09:17PM +0530, Praveen Talari wrote: > Hi > > On 15-06-2026 16:12, Greg Kroah-Hartman wrote: > > On Mon, Jun 15, 2026 at 03:26:25PM +0530, Praveen Talari wrote: > > > HI Steven, > > > > > > On 29-05-2026 19:44, Steven Rostedt wrote: > > > > On Tue, 26 May 2026 23:07:39 +0530 > > > > Praveen Talari <[email protected]> wrote: > > > > > > > > > +DECLARE_EVENT_CLASS(geni_serial_data, > > > > > + TP_PROTO(struct device *dev, const u8 *buf, > > > > > unsigned int len), > > > > > + TP_ARGS(dev, buf, len), > > > > > + > > > > > + TP_STRUCT__entry(__string(name, dev_name(dev)) > > > > > + __field(unsigned int, len) > > > > > + __dynamic_array(u8, data, len) > > > > > + ), > > > > > + > > > > > + TP_fast_assign(__assign_str(name); > > > > > + __entry->len = len; > > > > > + memcpy(__get_dynamic_array(data), > > > > > buf, len); > > > > > + ), > > > > > + > > > > > + TP_printk("%s: len=%u data=%s", > > > > > + __get_str(name), __entry->len, > > > > > + __print_hex(__get_dynamic_array(data), > > > > > __entry->len)) > > > > > +); > > > > No need to save the length of the dynamic array in __entry->len because > > > > it's already saved in the metadata of the dynamic array that is stored > > > > on the buffer. Instead you can have: > > > > > > > > DECLARE_EVENT_CLASS(geni_serial_data, > > > > TP_PROTO(struct device *dev, const u8 *buf, > > > > unsigned int len), > > > > TP_ARGS(dev, buf, len), > > > > > > > > TP_STRUCT__entry(__string(name, dev_name(dev)) > > > > __dynamic_array(u8, data, len) > > > > ), > > > > > > > > TP_fast_assign(__assign_str(name); > > > > memcpy(__get_dynamic_array(data), > > > > buf, len); > > > > ), > > > > > > > > TP_printk("%s: len=%u data=%s", > > > > __get_str(name), __entry->len, > > > > __print_hex(__get_dynamic_array(data), > > > > __get_dynamic_array_len(data))) > > > > ); > > > > > > > > That will save you 4 bytes per event on the ring buffer. And a few > > > > cycles not having to store the redundant information. > > > This patch has already been accepted and is available in linux-next. > > Great, can you send a fixup for it? Or want me to revert this instead? > > can i add fix patch in same series by removing original patch(0/1)?
We can never rewrite a public git tree. So either revert and redo it as a new patch, or send a fix for this one, your choice. thanks, greg k-h
