From: Wolfram Sang <wsa@kernel.org>
To: Sui Chen <suichen@google.com>
Cc: linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org,
openbmc@lists.ozlabs.org, joel@jms.id.au, andrew@aj.id.au,
tali.perry1@gmail.com, benjaminfair@google.com,
krellan@google.com, kernel test robot <lkp@intel.com>
Subject: Re: [RFC Patch v3 1/3] i2c debug counters as sysfs attributes
Date: Mon, 7 Feb 2022 14:01:06 +0100 [thread overview]
Message-ID: <YgEYEk355t8C4J1x@shikoro> (raw)
In-Reply-To: <20211221174344.1249202-2-suichen@google.com>
[-- Attachment #1: Type: text/plain, Size: 2026 bytes --]
Hi,
I finally had some time to look at your proposal. As I wrote last time,
you convinced me to have the stats in sysfs for apple-to-apple
comparisons.
One change I'd like to see is to let the I2C core handle the stats and
not the individual bus drivers. From what I see, the I2C core could
handle all this if the bus drivers use proper fault codes.
> - ber_cnt (bus error count)
I'm not sure what exactly "bus error" means in this case. But I think it
can be translated to any not-otherwise handled errno returned by
__i2c_transfer() or __i2c_smbus_transfer(). I also think it should be
named "bus_errors". Do we really need the "cnt" suffix?
> - nack_cnt (NACK count)
This would be -ENXIO for __i2c_transfer and friends. Name should be
"NACKs"?
> - rec_fail_cnt, rec_succ_cnt (recovery failure/success count)
This would be the return code of i2c_recover_bus(). Names should be
"recovery_failures" and "recovery_successes"?
> - timeout_cnt (timeout count)
This would be -ETIMEDOUT for __i2c_transfer and friends. Name should be
"timeouts"?
> - i2c_speed (bus frequency)
Yes, we can have that. I don't think this is really a stat, though. It
is an attribute of an adapter. It has been requested before:
http://patchwork.ozlabs.org/project/linux-i2c/patch/1413403411-8895-4-git-send-email-octavian.purdila@intel.com/
http://patchwork.ozlabs.org/project/linux-i2c/patch/20181210084111.6938-2-tudor.ambarus@microchip.com/
http://patchwork.ozlabs.org/project/linux-i2c/patch/20201013100314.216154-1-tali.perry1@gmail.com/
So, I think we can tackle it again but it is orthogonal from the stats
series.
> - tx_complete_cnt (transaction completed, including both as an initiator
> and as a target)
This would be retval == num_msgs for __i2c_transfer and friends. I also
think it should be named "transfers_completed". "tx" often goes with
"rx" as a pair. I really wondered "why only tx" first.
So, let's keep at the high level first. What do you think about my
suggestions?
Thanks and happy hacking,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Wolfram Sang <wsa@kernel.org>
To: Sui Chen <suichen@google.com>
Cc: benjaminfair@google.com, andrew@aj.id.au,
openbmc@lists.ozlabs.org, linux-kernel@vger.kernel.org,
tali.perry1@gmail.com, krellan@google.com,
kernel test robot <lkp@intel.com>,
linux-i2c@vger.kernel.org
Subject: Re: [RFC Patch v3 1/3] i2c debug counters as sysfs attributes
Date: Mon, 7 Feb 2022 14:01:06 +0100 [thread overview]
Message-ID: <YgEYEk355t8C4J1x@shikoro> (raw)
In-Reply-To: <20211221174344.1249202-2-suichen@google.com>
[-- Attachment #1: Type: text/plain, Size: 2026 bytes --]
Hi,
I finally had some time to look at your proposal. As I wrote last time,
you convinced me to have the stats in sysfs for apple-to-apple
comparisons.
One change I'd like to see is to let the I2C core handle the stats and
not the individual bus drivers. From what I see, the I2C core could
handle all this if the bus drivers use proper fault codes.
> - ber_cnt (bus error count)
I'm not sure what exactly "bus error" means in this case. But I think it
can be translated to any not-otherwise handled errno returned by
__i2c_transfer() or __i2c_smbus_transfer(). I also think it should be
named "bus_errors". Do we really need the "cnt" suffix?
> - nack_cnt (NACK count)
This would be -ENXIO for __i2c_transfer and friends. Name should be
"NACKs"?
> - rec_fail_cnt, rec_succ_cnt (recovery failure/success count)
This would be the return code of i2c_recover_bus(). Names should be
"recovery_failures" and "recovery_successes"?
> - timeout_cnt (timeout count)
This would be -ETIMEDOUT for __i2c_transfer and friends. Name should be
"timeouts"?
> - i2c_speed (bus frequency)
Yes, we can have that. I don't think this is really a stat, though. It
is an attribute of an adapter. It has been requested before:
http://patchwork.ozlabs.org/project/linux-i2c/patch/1413403411-8895-4-git-send-email-octavian.purdila@intel.com/
http://patchwork.ozlabs.org/project/linux-i2c/patch/20181210084111.6938-2-tudor.ambarus@microchip.com/
http://patchwork.ozlabs.org/project/linux-i2c/patch/20201013100314.216154-1-tali.perry1@gmail.com/
So, I think we can tackle it again but it is orthogonal from the stats
series.
> - tx_complete_cnt (transaction completed, including both as an initiator
> and as a target)
This would be retval == num_msgs for __i2c_transfer and friends. I also
think it should be named "transfers_completed". "tx" often goes with
"rx" as a pair. I really wondered "why only tx" first.
So, let's keep at the high level first. What do you think about my
suggestions?
Thanks and happy hacking,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-02-07 13:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-21 17:43 [RFC Patch v3 0/3] I2C statistics as sysfs attributes Sui Chen
2021-12-21 17:43 ` Sui Chen
2021-12-21 17:43 ` [RFC Patch v3 1/3] i2c debug counters " Sui Chen
2021-12-21 17:43 ` Sui Chen
2022-02-07 13:01 ` Wolfram Sang [this message]
2022-02-07 13:01 ` Wolfram Sang
2021-12-21 17:43 ` [RFC Patch v3 2/3] i2c: npcm7xx: add tx_complete counter Sui Chen
2021-12-21 17:43 ` Sui Chen
2021-12-21 17:43 ` [RFC Patch v3 3/3] add npcm7xx debug counters as sysfs attributes Sui Chen
2021-12-21 17:43 ` Sui Chen
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=YgEYEk355t8C4J1x@shikoro \
--to=wsa@kernel.org \
--cc=andrew@aj.id.au \
--cc=benjaminfair@google.com \
--cc=joel@jms.id.au \
--cc=krellan@google.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=openbmc@lists.ozlabs.org \
--cc=suichen@google.com \
--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.