Re: [PATCH v4 1/2] serial: qcom-geni: trace: Add tracepoint support for Qualcomm GENI serial

From: Greg Kroah-Hartman

Date: Mon Jun 15 2026 - 09:34:03 EST


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 <praveen.talari@xxxxxxxxxxxxxxxx> 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