Message ID | 20230410073134.488762-1-badhri@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp1738276vqo; Mon, 10 Apr 2023 00:53:53 -0700 (PDT) X-Google-Smtp-Source: AKy350Y0Fz7HFE2RrnSjyQtJFszChvasBUkDp18cgvU/pcqX9gwXHE/u8mPrL0Vg5Ut5jLJRId/C X-Received: by 2002:a05:6a20:ba9c:b0:db:c52b:1b1 with SMTP id fb28-20020a056a20ba9c00b000dbc52b01b1mr10946072pzb.11.1681113233036; Mon, 10 Apr 2023 00:53:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681113233; cv=none; d=google.com; s=arc-20160816; b=T4WjFpzV6fHc3n1kDHVvZoyORRdbg0uUQLXrFIjUXuLVabRjCcVvrfJYEYHjjnku08 DrnHEXVpuRVzwgxVEMhyENtScPj36fF0EaJFf/pXFYvRAd3yLTUAcUAlDvcBh4DBrck7 ETvttv+zkvMIfB2ZFaCDTl6a5UXOqwraqG8IdLe8Sppq6yzmZfTd3LdZyDw3zRja7fQU 0f769tURRh5lO9/JVGrL43sfcjZE9J7Q/20tMFhMVGrOWaZOeE5rpNixuskeibzBAmAi 0R+bEMH0X+IrmOfAuslbQWB0zrwaxjks9HKx20+AH+AzJC8wrphmCuMs19Uz/ii1VIyn n4Sw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:mime-version:date :dkim-signature; bh=XsjqIBb7Ia4TAnyJQH7l5g8jRueBhJOfzmgtMcl/GKU=; b=yjVRXOKBEPxAcg1g+NNNy4dUCwecUVwGkz7yOFhR+pgacMY1ppR58THStd72AUgFWZ rvKcyvi8p73256xMH8te+PU6918p73lgMcAa7VwA08JaRjqpoCOvLGtGKmmGy7oHT47A O0sQzY7YyfaBEC+XdUM6A7uYdQGoiW6UqE8sCHroGctxIw5xV95R3l77aITpy9Z48owa ZYwbt+ERiwxXLu59Tq3GYjtmhRJ7IkqoMaUxCh0Bi3yRYKW2XnxuVNpfOFQ3r4FWh9yb 2h/2m974/gmWz9R+DTHRwz32NvZOKcTYaA5oBmmpzHyPYpGW4QqjZ/00LdLhEpGSkJUd t+MA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=m6eMlr6I; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h124-20020a625382000000b0062565210347si10303814pfb.275.2023.04.10.00.53.41; Mon, 10 Apr 2023 00:53:53 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=m6eMlr6I; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229759AbjDJHcX (ORCPT <rfc822;a1648639935@gmail.com> + 99 others); Mon, 10 Apr 2023 03:32:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43722 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229642AbjDJHcW (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 10 Apr 2023 03:32:22 -0400 Received: from mail-pj1-x104a.google.com (mail-pj1-x104a.google.com [IPv6:2607:f8b0:4864:20::104a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E9E3449C2 for <linux-kernel@vger.kernel.org>; Mon, 10 Apr 2023 00:31:43 -0700 (PDT) Received: by mail-pj1-x104a.google.com with SMTP id s93-20020a17090a2f6600b0024670ac71caso1680333pjd.4 for <linux-kernel@vger.kernel.org>; Mon, 10 Apr 2023 00:31:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1681111898; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=XsjqIBb7Ia4TAnyJQH7l5g8jRueBhJOfzmgtMcl/GKU=; b=m6eMlr6IRRsKYg4YgpoBxj3rZB0vKRWzHjaaj+18miNfqGNHBiDwCxMoaWbCfTF92l PZZkKOzTFNGolO0Mo08YW0qeriAIxKjlNoy8VG/ol8o53WxJtIJj9wzyDJBcx440HTvS SxkClUwOaeEz/Sbw7bcqfvLsfEIvfSiacr6NHGtHYgCSMxAmCekGenYvzUk9Y0WIIeSF iu+LGvZAsxk17Rq1Jw+dxOLV1EgAh5iuEUtky/R/+WU3S5S4bpOXuiv57vkqg70/asgF fl5shxMYIZ75Ikzf9MIZawDPCdsRAC57KUPuwcUFPbVRd+o+TFpBepaWxsaLqRUXfnJ9 2cmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681111898; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=XsjqIBb7Ia4TAnyJQH7l5g8jRueBhJOfzmgtMcl/GKU=; b=AyNvk6OX5LjO9IUfecH1aqTU8rc6gr8FHmx5Ad6STIZRr+K2lpTSLaGHiNJ2Rt4Ym5 N3jt5t1K+dsYcXvNCw69PR/7wqrRdnROoDgE0wVuCz2RgImjc9MYrL72A5dfaeBMcUQJ J7njpa7EjuLXRTiFBI1KLjWkyMQG+QVNpH0HZZefSvxRhUSLzJ6tIY0XVTTLBxMWO6+E ZeiNMz2xkQ9L7xAXR6wBXKXkZQrZmvd+TjBeYKANOz59MGavaTreqMI1IEFen6yQuQr2 eVbS5LGnmthPQXGTjO8A21FXW8bXjef74FxrX3Gtr924jK4HFfFgGDpf0+933EwJkZMM GoWA== X-Gm-Message-State: AAQBX9dQQEry9QHy0C4jl0zoBcrxT+/99l3KISVBrG8KFVNcxsLdtgk1 9qK7zPtPpV+x4jPgPovucYEXvGm9xzo= X-Received: from badhri.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:6442]) (user=badhri job=sendgmr) by 2002:a17:903:13cd:b0:1a5:22f3:220e with SMTP id kd13-20020a17090313cd00b001a522f3220emr2419872plb.3.1681111898602; Mon, 10 Apr 2023 00:31:38 -0700 (PDT) Date: Mon, 10 Apr 2023 07:31:34 +0000 Mime-Version: 1.0 X-Mailer: git-send-email 2.40.0.577.gac1e443424-goog Message-ID: <20230410073134.488762-1-badhri@google.com> Subject: [PATCH v1] usb: typec: tcpm: Add kernel config to wrap around tcpm logs From: Badhri Jagan Sridharan <badhri@google.com> To: linux@roeck-us.net, heikki.krogerus@linux.intel.com, gregkh@linuxfoundation.org Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Badhri Jagan Sridharan <badhri@google.com> Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-7.7 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1762774989717775884?= X-GMAIL-MSGID: =?utf-8?q?1762774989717775884?= |
Series |
[v1] usb: typec: tcpm: Add kernel config to wrap around tcpm logs
|
|
Commit Message
Badhri Jagan Sridharan
April 10, 2023, 7:31 a.m. UTC
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(-)
Comments
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. And you do not provide any hint here as to why this is not the default option, or why someone would want this. So, why is this not just the default operation anyway? Why would you ever want the logs cleared? thanks, greg k-h
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. Thanks for taking the time to review ! - Badhri > > thanks, > > greg k-h
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? 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? thanks, greg k-h
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. 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. > > 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
On Mon, Apr 10, 2023 at 2:00 AM Badhri Jagan Sridharan <badhri@google.com> 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. > 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
On 4/10/23 01:08, 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. > The reason to not wrap around the buffer was that it tends to fill up quickly if something goes wrong. Initially I had it wrap around and often ended up seeing endless reset sequences in the log but not the actual problem. >> >> 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. > Yes, except that "testing" at the time included connecting an arbitrary new device to the type c port. Pretty much each of them had its own flaws. This was also the reason for not using tracing, because I wanted to have a log available _all_ the time, not just when explicitly enabled. Maybe the protocol is now more stable than it used to be, and switching to a wraparound buffer and/or to tracing makes more sense now. I can't really say. Guenter > Thanks for taking the time to review ! > - Badhri > >> >> thanks, >> >> greg k-h
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. > 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. Unless they are cleared. Again, the premise is wrong here. The idea was to ensure that the beginning of a problem is caught and available in the log, not its tail. This includes "beginning" as the behavior immediately after boot regarding an already connected device, and the behavior observed when inserting a device into the running system. Again, in both cases it was most important to catch the beginning of a problem, not its tail. > 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. > I don't really agree, but then I am not in a position to argue either. Maybe the premise and reasons have changed since I wrote the driver. Guenter > > > > 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
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. > > > 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. > > Unless they are cleared. Ah yes. I forgot about that. Wrapping around would still make TCPM logbuffer logs more effective to debug issues with remote device. Thanks, Badhri > > Again, the premise is wrong here. The idea was to ensure that the > beginning of a problem is caught and available in the log, not its tail. > This includes "beginning" as the behavior immediately after boot regarding > an already connected device, and the behavior observed when inserting > a device into the running system. Again, in both cases it was most > important to catch the beginning of a problem, not its tail. > > > 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. > > > > I don't really agree, but then I am not in a position to argue either. > Maybe the premise and reasons have changed since I wrote the driver. > > Guenter > > > > > > > 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
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
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. + if TYPEC_TCPCI config TYPEC_RT1711H diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index ab3a54662ed9..3f708749431b 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -619,7 +619,7 @@ static void _tcpm_log(struct tcpm_port *port, const char *fmt, va_list args) vsnprintf(tmpbuffer, sizeof(tmpbuffer), fmt, args); - if (tcpm_log_full(port)) { + if (!IS_ENABLED(CONFIG_TCPM_LOG_WRAPAROUND) && tcpm_log_full(port)) { port->logbuffer_head = max(port->logbuffer_head - 1, 0); strcpy(tmpbuffer, "overflow"); } @@ -644,6 +644,10 @@ static void _tcpm_log(struct tcpm_port *port, const char *fmt, va_list args) tmpbuffer); port->logbuffer_head = (port->logbuffer_head + 1) % LOG_BUFFER_ENTRIES; + if (IS_ENABLED(CONFIG_TCPM_LOG_WRAPAROUND) && port->logbuffer_head == port->logbuffer_tail) + port->logbuffer_tail = + (port->logbuffer_tail + 1) % LOG_BUFFER_ENTRIES; + abort: mutex_unlock(&port->logbuffer_lock); } @@ -746,7 +750,8 @@ static int tcpm_debug_show(struct seq_file *s, void *v) seq_printf(s, "%s\n", port->logbuffer[tail]); tail = (tail + 1) % LOG_BUFFER_ENTRIES; } - if (!seq_has_overflowed(s)) + + if (!IS_ENABLED(CONFIG_TCPM_LOG_WRAPAROUND) && !seq_has_overflowed(s)) port->logbuffer_tail = tail; mutex_unlock(&port->logbuffer_lock);