Re: [PATCH v1] usb: typec: tcpm: Add kernel config to wrap around tcpm logs

[Badhri Jagan Sridharan]

On Mon, Apr 10, 2023 at 2:00 AM Badhri Jagan Sridharan
<badhri@xxxxxxxxxx> wrote:
>
> On Mon, Apr 10, 2023 at 1:27 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Mon, Apr 10, 2023 at 01:08:55AM -0700, Badhri Jagan Sridharan wrote:
> > > On Mon, Apr 10, 2023 at 12:45 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > > >
> > > > On Mon, Apr 10, 2023 at 07:31:34AM +0000, Badhri Jagan Sridharan wrote:
> > > > > This change adds CONFIG_TCPM_LOG_WRAPAROUND which when set allows the
> > > > > logs to be wrapped around. Additionally, when set, does not clear
> > > > > the TCPM logs when dumped.
> > > > >
> > > > > Signed-off-by: Badhri Jagan Sridharan <badhri@xxxxxxxxxx>
> > > > > ---
> > > > >  drivers/usb/typec/tcpm/Kconfig | 6 ++++++
> > > > >  drivers/usb/typec/tcpm/tcpm.c  | 9 +++++++--
> > > > >  2 files changed, 13 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/usb/typec/tcpm/Kconfig b/drivers/usb/typec/tcpm/Kconfig
> > > > > index e6b88ca4a4b9..4dd2b594dfc9 100644
> > > > > --- a/drivers/usb/typec/tcpm/Kconfig
> > > > > +++ b/drivers/usb/typec/tcpm/Kconfig
> > > > > @@ -18,6 +18,12 @@ config TYPEC_TCPCI
> > > > >       help
> > > > >         Type-C Port Controller driver for TCPCI-compliant controller.
> > > > >
> > > > > +config TCPM_LOG_WRAPAROUND
> > > > > +     bool "Enable TCPM log wraparound"
> > > > > +     help
> > > > > +       When set, wraps around TCPM logs and does not clear the logs when dumped. TCPM logs by
> > > > > +       default gets cleared when dumped and does not wraparound when full.
> > > >
> > > > Kconfig help text needs to be wrapped at the properly width.
> > >
> > > I assumed that the width is 100 characters, but it looks like it is
> > > 80. Will fix it in the next version.
> > > >
> > > > And you do not provide any hint here as to why this is not the default
> > > > option, or why someone would want this.
> > >
> > > "TCPM logs by default gets cleared when dumped and does not wraparound
> > > when full." was intended
> > > to convey why someone would want to set this. Perhaps it's not effective.
> > >
> > > Does the below look better:
> > > "TCPM logs by default gets cleared when dumped and does not wraparound
> > > when full. This can be overridden by setting this config.
> > > When the config is set, TCPM wraps around logs and does not clear the
> > > logs when dumped."
> > >
> > > Also, I could make this default if that's OK with Guenter.
> > >
> > > >
> > > > So, why is this not just the default operation anyway?  Why would you
> > > > ever want the logs cleared?
> > >
> > > I remember Guenter mentioning that he was finding it useful to not
> > > wrap around the logs to fix problems
> > > during tcpm_register_port (init sequence). IMHO wrapping around the
> > > logs helps to triage interoperability
> > > issues uncovered during testing. So both approaches have their own advantages.
> >
> > But as this is a build-time option, what would cause someone to choose
> > one over the other, and then when the system is running, they can't
> > change them?
>
> During initial phases of bringup, it makes sense to not wrap around
> the logs, but, once bringup is done its most effective to wraparound
> so that interop issues reported by the end users can be triaged where
> TCPM logs are very effective.
> Also, without wrapping around, the logbuffer logs are completely stale
> after the user goes through a few USB connect and disconnect cycles
> till the system is rebooted.
> If we don't want to pursue the Kconfig option, we should atleast make
> TCPM default to wrapping the logs around when full so we could
> maximise the use of the logbuffer contents.
>

The other option that I could think of is to expose another debugfs node
that can be used to control wrapping around the logs in runtime.

Thanks,
Badhri

> >
> > That does not seem good at all.
> >
> > Why not just use tracing instead of this odd custom log buffer?  That's
> > a better solution overall, right?
>
> Tracing is not enabled by default in most systems. End users don't
> want to retry and reproduce the failure to collect traces even if they
> could reproduce it consistently.
> So tracing was not proving handy here.
>
> Thanks,
> Badhri
>
> >
> > thanks,
> >
> > greg k-h