From: Steven Rostedt <rostedt@goodmis.org>

The i2c_write and i2c_reply events save the length of the message in the
ring buffer. It also uses __dynamic_array() to save the message itself. As
the length of the __dynamic_array() is saved in the meta data of the array
there's no reason to also save it in the event itself. The length can now
be accessed by __get_dynamic_array_len(). Use that instead.

Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
---
[
  NOTE: This removes the "len" field from these events. If that "len" field
  is used by filters or user space tooling, then this will break that. If
  that is the case, then this patch should NOT be accepted.

  I'm only sending it because I noticed the redundancy in the event when
  looking at events that have of "%*p..." in their print formats.
]

 include/trace/events/i2c.h | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/include/trace/events/i2c.h b/include/trace/events/i2c.h
index 142a23c6593c..757f331f3a9c 100644
--- a/include/trace/events/i2c.h
+++ b/include/trace/events/i2c.h
@@ -31,14 +31,12 @@ TRACE_EVENT_FN(i2c_write,
 		       __field(__u16,	msg_nr			)
 		       __field(__u16,	addr			)
 		       __field(__u16,	flags			)
-		       __field(__u16,	len			)
 		       __dynamic_array(__u8, buf, msg->len)	),
 	       TP_fast_assign(
 		       __entry->adapter_nr = adap->nr;
 		       __entry->msg_nr = num;
 		       __entry->addr = msg->addr;
 		       __entry->flags = msg->flags;
-		       __entry->len = msg->len;
 		       memcpy(__get_dynamic_array(buf), msg->buf, msg->len);
 			      ),
 	       TP_printk("i2c-%d #%u a=%03x f=%04x l=%u [%*phD]",
@@ -46,8 +44,8 @@ TRACE_EVENT_FN(i2c_write,
 			 __entry->msg_nr,
 			 __entry->addr,
 			 __entry->flags,
-			 __entry->len,
-			 __entry->len, __get_dynamic_array(buf)
+			 __get_dynamic_array_len(buf),
+			 __get_dynamic_array_len(buf), __get_dynamic_array(buf)
 			 ),
 	       i2c_transfer_trace_reg,
 	       i2c_transfer_trace_unreg);
@@ -95,14 +93,12 @@ TRACE_EVENT_FN(i2c_reply,
 		       __field(__u16,	msg_nr			)
 		       __field(__u16,	addr			)
 		       __field(__u16,	flags			)
-		       __field(__u16,	len			)
 		       __dynamic_array(__u8, buf, msg->len)	),
 	       TP_fast_assign(
 		       __entry->adapter_nr = adap->nr;
 		       __entry->msg_nr = num;
 		       __entry->addr = msg->addr;
 		       __entry->flags = msg->flags;
-		       __entry->len = msg->len;
 		       memcpy(__get_dynamic_array(buf), msg->buf, msg->len);
 			      ),
 	       TP_printk("i2c-%d #%u a=%03x f=%04x l=%u [%*phD]",
@@ -110,8 +106,8 @@ TRACE_EVENT_FN(i2c_reply,
 			 __entry->msg_nr,
 			 __entry->addr,
 			 __entry->flags,
-			 __entry->len,
-			 __entry->len, __get_dynamic_array(buf)
+			 __get_dynamic_array_len(buf),
+			 __get_dynamic_array_len(buf), __get_dynamic_array(buf)
 			 ),
 	       i2c_transfer_trace_reg,
 	       i2c_transfer_trace_unreg);
-- 
2.47.2

>   NOTE: This removes the "len" field from these events. If that "len" field
>   is used by filters or user space tooling, then this will break that. If
>   that is the case, then this patch should NOT be accepted.

I have no idea if someone uses it, or even how to find out if someone
uses it. To avoid regressions, I prefer to leave it as is. But thanks
for letting me know!