Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp3832198rwl; Mon, 10 Apr 2023 01:34:44 -0700 (PDT) X-Google-Smtp-Source: AKy350ZM8Ss2m7f1Tlmux363du8HxnmDNbiKIRCOJOpX97GRLbFSLUcLpYf7snR4GvpMlk/osOBt X-Received: by 2002:a17:902:f9c6:b0:1a2:a284:d3bf with SMTP id kz6-20020a170902f9c600b001a2a284d3bfmr10630645plb.17.1681115683962; Mon, 10 Apr 2023 01:34:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681115683; cv=none; d=google.com; s=arc-20160816; b=yBsmL69tVsI3EPeK1EMvyu1hcKUTpVDZxGe5Sunrl+Ecr2OcipEPVoHFB3x/9dobNy vXy9jQeAYELYJtbES+N3dfpdm2sj+ZOXldq0LPwsAJ8QDdMQ0ZweeLMFDHmSsu8QpiVW qwp45bFFgmZ7kOC6vAYUWrk4F2UuEgGkPOfBTs/yctjTuhj2n7U7HkVScrGWBCSK+Z6j vpgsCkVn3Eh0Qg37yxzKApKhCzQDc2afLRE8n22+PMdwBYYDTg9Ot1LJLBbJKSQiwDQ3 WiGORqMGaSpJqbLB18KIyKU5WOw7zmqzLMz5fehPVBtQUs/xK8j/jMXH730d1Ym3980s PSCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=uaUGcVL3wVOlyr34CUHSGcS3eleV6c7XHRu4+D1ig1E=; b=NQ0ZIcDhhdKql0a12TWeJfSifEjMJ+HkZ9WqnkRZozsjLDebZnpzKiVEyz0vB1dz2y H1A5fWRmEl9ZVzFXsYo8XZJm0KPTYXXZgR1AdRDjL3ZOScERouZRKwadMsn2B9e72AoH Q8klh6pZYFcTsbgorKv3pVRH7GVgurKSeiPLhP0hBDjBDCpHONRVR/REWMVxX5Tobr+2 9pXLSxZ7ostnJdsjQeowdhdzOgsShKmgL7Jw13iYPWLEHIyMF0egLRVUBDQRhQZgg9wU Gm90yWVnKm30VSq7gggpmkfaD+Kfi4c3IjliPczw4yrSmkoWJWZyRIdBqdbfykmvqYWx Pp+g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=SEACWwOe; 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=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i15-20020a170902c94f00b001a51c26f601si7912902pla.627.2023.04.10.01.34.32; Mon, 10 Apr 2023 01:34:43 -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=@linuxfoundation.org header.s=korg header.b=SEACWwOe; 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=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229680AbjDJI1I (ORCPT + 99 others); Mon, 10 Apr 2023 04:27:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44538 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229536AbjDJI1E (ORCPT ); Mon, 10 Apr 2023 04:27:04 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EF27C30C8; Mon, 10 Apr 2023 01:27:02 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8876560C7F; Mon, 10 Apr 2023 08:27:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 72ED2C433D2; Mon, 10 Apr 2023 08:27:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1681115221; bh=wdrP0v6vCirsnZnScA2c36yAoABoqtZx/h3x+Po66Sg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SEACWwOemFrAUM+fsTXmC46Xz1a+AwRk6AJYzc6Hljf3dRc/QwS0JEP5yYgJTZsjT 8JU2cp509ahyUh9BrJgX2EcLR7FX/yLhQrUSFeGRDipEqgq7wR/olUDdW3dfH+laLd 8PIsyixh4sX+b8equqeE8bV7eeYg6XcfiUtaK1uI= Date: Mon, 10 Apr 2023 10:26:59 +0200 From: Greg KH To: Badhri Jagan Sridharan Cc: linux@roeck-us.net, heikki.krogerus@linux.intel.com, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1] usb: typec: tcpm: Add kernel config to wrap around tcpm logs Message-ID: <2023041004-antarctic-hardiness-524e@gregkh> References: <20230410073134.488762-1-badhri@google.com> <2023041028-irritate-starless-a42f@gregkh> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-5.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,SPF_HELO_NONE, SPF_PASS 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: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 > > > --- > > > 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