Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Sender: Guenter Roeck <groeck7@gmail.com>
Message-ID: <233780b0-dc7f-aaef-518e-51fe33498cd7@roeck-us.net>
Date:   Mon, 10 Apr 2023 15:12:59 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.9.0
Content-Language: en-US
To:     Badhri Jagan Sridharan <badhri@google.com>
Cc:     Greg KH <gregkh@linuxfoundation.org>,
        heikki.krogerus@linux.intel.com, linux-usb@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <20230410073134.488762-1-badhri@google.com>
 <2023041028-irritate-starless-a42f@gregkh>
 <CAPTae5KZ0zkaCWrtPYzyX8oTyvDhBhc-hvxyHn9VHZ32UOqJ3g@mail.gmail.com>
 <2023041004-antarctic-hardiness-524e@gregkh>
 <CAPTae5JFC8WUzjrMeiyw7tYfWpsZUQThrrvG_etx7Fb2KP6y6A@mail.gmail.com>
 <b1ac0ab9-e6f3-4301-a231-519752e4a735@roeck-us.net>
 <CAPTae5LbWVc4Bdiwe69cwwxEGfSYvRv=419dUGR1u8n-WUkYAA@mail.gmail.com>
From:   Guenter Roeck <linux@roeck-us.net>
Subject: Re: [PATCH v1] usb: typec: tcpm: Add kernel config to wrap around
 tcpm logs
In-Reply-To: <CAPTae5LbWVc4Bdiwe69cwwxEGfSYvRv=419dUGR1u8n-WUkYAA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 4/10/23 13:57, Badhri Jagan Sridharan wrote:
> On Mon, Apr 10, 2023 at 10:00 AM Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> On Mon, Apr 10, 2023 at 02:00:08AM -0700, Badhri Jagan Sridharan wrote:
>>> On Mon, Apr 10, 2023 at 1:27 AM Greg KH <gregkh@linuxfoundation.org> 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@linuxfoundation.org> 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@google.com>
>>>>>>> ---
>>>>>>>   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.
>>
>> Not really, because the problem tends to be the remote device
>> (or at least it used to be), not a driver under development.
> 
> Thanks for clarifying Guenter !
> Right now if we DONT wrap around, once an issue is observed with a
> remote device, the logs have to be cleared(if already full) and then
> the issue has to be reproduced to collect the TCPM logbuffer
> logsagain.
> 
> Having a log available _all_ the time, not just when explicitly
> enabled is still very useful to catch hard to reproduce intertop
> issues.
> 
> Given this would you be OK if I change the logic to wrap around always ?
> 
> IMHO based on what I have seen in the last couple of years, this would
> also cover the boot with accessory connected as if the link gets into
> a reset loop, the sequence after the reset reveals what had gone
> wrong.
> 

I have no strong opinion. As I said, maybe conditions have changed.
When I wrote the code, failure conditions happened all the time, and
reset loops overwrote the log repeatedly. I didn't implement the current
code because I was lazy or something, it was because wrap-around
did not work for me. Again, maybe the situation has changed.
And, to follow-up on Greg's question, maybe switching to tracing
instead of re-implementing it would make sense nowadays. I simply
don't know. I'll accept whatever solution you and Greg can agree on.

Thanks,
Guenter