All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sui Chen <suichen@google.com>
To: Joe Perches <joe@perches.com>, linux-kernel@vger.kernel.org
Cc: openbmc@lists.ozlabs.org, linux-i2c@vger.kernel.org,
	joel@jms.id.au, andrew@aj.id.au, tali.perry1@gmail.com,
	benjaminfair@google.com, krellan@google.com
Subject: Re: [RFC Patch v2 1/3] i2c debug counters as sysfs attributes
Date: Thu, 2 Dec 2021 21:35:13 -0800	[thread overview]
Message-ID: <c3e3d7fe-765e-defa-275b-0b5e731c77ce@google.com> (raw)
In-Reply-To: <10e59e850894524d34cc7d89c126ab9133e6a1a7.camel@perches.com>

On 12/2/21 6:50 PM, Joe Perches wrote:
> On Thu, 2021-12-02 at 18:37 -0800, Sui Chen wrote:
>> This change adds a few example I2C debug counters as sysfs attributes:
>> - ber_cnt (bus error count)
>> - nack_cnt (NACK count)
>> - rec_fail_cnt, rec_succ_cnt (recovery failure/success count)
>> - timeout_cnt (timeout count)
>> - i2c_speed (bus frequency)
>> - tx_complete_cnt (transaction completed, including both as an initiator
>>    and as a target)
>>
>> The function i2c_adapter_create_stats_folder creates a stats directory
>> in the device's sysfs directory to hold the debug counters. The platform
>> drivers are responsible for instantiating the counters in the stats
>> directory if applicable.
> 
> Please try to use scripts/checkpatch.pl on your patches and see if
> you should be more 'typical kernel style' compliant.
> 
> Ideally, use the --strict option too.
> 

Hello Joe,

I thank and really appreciate your spending time commenting on the 
patch, and on its previous version too. I ran checkpatch.pl and found a 
few code style fixes on patches 1 and 2.
Sorry for not checking the format before sending the email, I will 
definitely do the format check next time.

Regarding the patch itself, code style aside, we're wondering if this 
idea of exporting I2C statistics to sysfs looks reasonable? Do we need 
to accompany this change with design documents too (similar to PCIe AER 
reporting?)

We have done some more I2C-related performance and reliability tests; 
however it might take some more efforts to explore those ideas and 
summarize them into patches/documents. For now we would like to know 
about the comments on this sysfs attribute change first, since it is the 
initial step to the larger effort. Any comments will be greatly appreciated.

Thanks,
Sui

WARNING: multiple messages have this Message-ID (diff)
From: Sui Chen <suichen@google.com>
To: Joe Perches <joe@perches.com>, linux-kernel@vger.kernel.org
Cc: benjaminfair@google.com, andrew@aj.id.au,
	openbmc@lists.ozlabs.org, tali.perry1@gmail.com,
	krellan@google.com, linux-i2c@vger.kernel.org
Subject: Re: [RFC Patch v2 1/3] i2c debug counters as sysfs attributes
Date: Thu, 2 Dec 2021 21:35:13 -0800	[thread overview]
Message-ID: <c3e3d7fe-765e-defa-275b-0b5e731c77ce@google.com> (raw)
In-Reply-To: <10e59e850894524d34cc7d89c126ab9133e6a1a7.camel@perches.com>

On 12/2/21 6:50 PM, Joe Perches wrote:
> On Thu, 2021-12-02 at 18:37 -0800, Sui Chen wrote:
>> This change adds a few example I2C debug counters as sysfs attributes:
>> - ber_cnt (bus error count)
>> - nack_cnt (NACK count)
>> - rec_fail_cnt, rec_succ_cnt (recovery failure/success count)
>> - timeout_cnt (timeout count)
>> - i2c_speed (bus frequency)
>> - tx_complete_cnt (transaction completed, including both as an initiator
>>    and as a target)
>>
>> The function i2c_adapter_create_stats_folder creates a stats directory
>> in the device's sysfs directory to hold the debug counters. The platform
>> drivers are responsible for instantiating the counters in the stats
>> directory if applicable.
> 
> Please try to use scripts/checkpatch.pl on your patches and see if
> you should be more 'typical kernel style' compliant.
> 
> Ideally, use the --strict option too.
> 

Hello Joe,

I thank and really appreciate your spending time commenting on the 
patch, and on its previous version too. I ran checkpatch.pl and found a 
few code style fixes on patches 1 and 2.
Sorry for not checking the format before sending the email, I will 
definitely do the format check next time.

Regarding the patch itself, code style aside, we're wondering if this 
idea of exporting I2C statistics to sysfs looks reasonable? Do we need 
to accompany this change with design documents too (similar to PCIe AER 
reporting?)

We have done some more I2C-related performance and reliability tests; 
however it might take some more efforts to explore those ideas and 
summarize them into patches/documents. For now we would like to know 
about the comments on this sysfs attribute change first, since it is the 
initial step to the larger effort. Any comments will be greatly appreciated.

Thanks,
Sui

  reply	other threads:[~2021-12-03  5:35 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-03  2:37 [RFC Patch v2 0/3] I2C statistics as sysfs attributes Sui Chen
2021-12-03  2:37 ` Sui Chen
2021-12-03  2:37 ` [RFC Patch v2 1/3] i2c debug counters " Sui Chen
2021-12-03  2:37   ` Sui Chen
2021-12-03  2:50   ` Joe Perches
2021-12-03  2:50     ` Joe Perches
2021-12-03  5:35     ` Sui Chen [this message]
2021-12-03  5:35       ` Sui Chen
2021-12-03  5:54   ` Joe Perches
2021-12-03  5:54     ` Joe Perches
2021-12-03 12:36   ` kernel test robot
2021-12-03 14:18   ` kernel test robot
2021-12-03  2:37 ` [RFC Patch v2 2/3] i2c: npcm7xx: add tx_complete counter Sui Chen
2021-12-03  2:37   ` Sui Chen
2021-12-03  2:37 ` [RFC Patch v2 3/3] add npcm7xx debug counters as sysfs attributes Sui Chen
2021-12-03  2:37   ` Sui Chen
2021-12-03 21:15   ` kernel test robot
2021-12-03 16:37 ` [RFC Patch v2 0/3] I2C statistics " Wolfram Sang
2021-12-03 16:37   ` Wolfram Sang
2021-12-07 16:00   ` Sui Chen
2022-01-03  9:44     ` Wolfram Sang
2022-01-03  9:44       ` Wolfram Sang
2021-12-05  0:40 [RFC Patch v2 1/3] i2c debug counters " kernel test robot
2021-12-06 14:03 ` Dan Carpenter
2021-12-05  1:43 kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c3e3d7fe-765e-defa-275b-0b5e731c77ce@google.com \
    --to=suichen@google.com \
    --cc=andrew@aj.id.au \
    --cc=benjaminfair@google.com \
    --cc=joe@perches.com \
    --cc=joel@jms.id.au \
    --cc=krellan@google.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=openbmc@lists.ozlabs.org \
    --cc=tali.perry1@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.