[PATCH v2 0/1] TCPM logbuffer wraparound

Badhri Jagan Sridharan posted 1 patch 3 months, 1 week ago
drivers/usb/typec/tcpm/Kconfig |  8 ++++++
drivers/usb/typec/tcpm/tcpm.c  | 51 ++++++++++++++++++++++++++++++++--
2 files changed, 57 insertions(+), 2 deletions(-)
[PATCH v2 0/1] TCPM logbuffer wraparound
Posted by Badhri Jagan Sridharan 3 months, 1 week ago
This is a follow up on a previous discussion:
https://lore.kernel.org/lkml/20230410073134.488762-1-badhri@google.com/.

With this change, TCPM log buffer will now wrap around when full and
will not self-clear upon being read (dumped). A Kconfig option and a
corresponding debugfs file node are introduced to allow opt-in back to
the previous, non-wrapping, self-clearing behavior if required.
This is an interim step while TCPM logging infrastructure is migrated
to the standard event trace system. 

Badhri Jagan Sridharan (1):
  tcpm: Wraparound tcpm log and dont clear them when read

 drivers/usb/typec/tcpm/Kconfig |  8 ++++++
 drivers/usb/typec/tcpm/tcpm.c  | 51 ++++++++++++++++++++++++++++++++--
 2 files changed, 57 insertions(+), 2 deletions(-)


base-commit: 18514fd70ea4ca9de137bb3bceeac1bac4bcad75
-- 
2.51.1.930.gacf6e81ea2-goog
Re: [PATCH v2 0/1] TCPM logbuffer wraparound
Posted by Greg KH 3 months, 1 week ago
On Mon, Nov 03, 2025 at 05:24:49AM +0000, Badhri Jagan Sridharan wrote:
> This is a follow up on a previous discussion:
> https://lore.kernel.org/lkml/20230410073134.488762-1-badhri@google.com/.
> 
> With this change, TCPM log buffer will now wrap around when full and
> will not self-clear upon being read (dumped). A Kconfig option and a
> corresponding debugfs file node are introduced to allow opt-in back to
> the previous, non-wrapping, self-clearing behavior if required.
> This is an interim step while TCPM logging infrastructure is migrated
> to the standard event trace system. 

Ick, no, let's just move to the standard trace format instead.  That
should be much simpler and get rid of custom user/kernel apis and
Kconfig options.  Overall you should end up removing a bunch of code
instead of adding new complexity like this.

thanks,

greg k-h