From: Wolfram Sang <wsa@the-dreams.de>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Tali Perry <tali.perry1@gmail.com>,
Ofer Yehielli <ofery@google.com>,
Brendan Higgins <brendanhiggins@google.com>,
avifishman70@gmail.com, Tomer Maimon <tmaimon77@gmail.com>,
kfting@nuvoton.com, Patrick Venture <venture@google.com>,
Nancy Yuen <yuenn@google.com>,
Benjamin Fair <benjaminfair@google.com>,
Rob Herring <robh+dt@kernel.org>,
linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org,
OpenBMC Maillist <openbmc@lists.ozlabs.org>,
devicetree <devicetree@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v12 2/3] i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver
Date: Thu, 21 May 2020 22:37:58 +0200 [thread overview]
Message-ID: <20200521203758.GA20150@ninjato> (raw)
In-Reply-To: <20200521145347.GO1634618@smile.fi.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]
> > > I wondered also about DEBUG_FS entries. I can see their value when
> > > developing the driver. But since this is done now, do they really help a
> > > user to debug a difficult case? I am not sure, and then I wonder if we
> > > should have that code in upstream. I am open for discussion, though.
> >
> > The user wanted to have health monitor implemented on top of the driver.
> > The user has 16 channels connected the multiple devices. All are operated
> > using various daemons in the system. Sometimes the slave devices are power down.
> > Therefor the user wanted to track the health status of the devices.
>
> Ah, then there are these options I have in mind (Wolfram, FYI as well!):
> 1) push with debugfs as a temporary solution and convert to devlink health protocol [1];
> 2) drop it and develop devlink_health solution;
> 3) push debugfs and wait if I²C will gain devlink health support
No need for 2). We can push it now and convert it later. That being
said, I wonder if [1] is suitable for this driver? Things like NACKs and
timeouts happen regularly on an I2C bus and are not a state of bad
health.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Wolfram Sang <wsa@the-dreams.de>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: devicetree <devicetree@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Tomer Maimon <tmaimon77@gmail.com>, Nancy Yuen <yuenn@google.com>,
avifishman70@gmail.com, Patrick Venture <venture@google.com>,
OpenBMC Maillist <openbmc@lists.ozlabs.org>,
Brendan Higgins <brendanhiggins@google.com>,
Ofer Yehielli <ofery@google.com>,
Tali Perry <tali.perry1@gmail.com>,
kfting@nuvoton.com, Rob Herring <robh+dt@kernel.org>,
linux-i2c@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Benjamin Fair <benjaminfair@google.com>
Subject: Re: [PATCH v12 2/3] i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver
Date: Thu, 21 May 2020 22:37:58 +0200 [thread overview]
Message-ID: <20200521203758.GA20150@ninjato> (raw)
In-Reply-To: <20200521145347.GO1634618@smile.fi.intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 1148 bytes --]
> > > I wondered also about DEBUG_FS entries. I can see their value when
> > > developing the driver. But since this is done now, do they really help a
> > > user to debug a difficult case? I am not sure, and then I wonder if we
> > > should have that code in upstream. I am open for discussion, though.
> >
> > The user wanted to have health monitor implemented on top of the driver.
> > The user has 16 channels connected the multiple devices. All are operated
> > using various daemons in the system. Sometimes the slave devices are power down.
> > Therefor the user wanted to track the health status of the devices.
>
> Ah, then there are these options I have in mind (Wolfram, FYI as well!):
> 1) push with debugfs as a temporary solution and convert to devlink health protocol [1];
> 2) drop it and develop devlink_health solution;
> 3) push debugfs and wait if I²C will gain devlink health support
No need for 2). We can push it now and convert it later. That being
said, I wonder if [1] is suitable for this driver? Things like NACKs and
timeouts happen regularly on an I2C bus and are not a state of bad
health.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-05-21 20:38 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-21 11:09 [PATCH v12 0/3] i2c: npcm7xx: add NPCM i2c controller driver Tali Perry
2020-05-21 11:09 ` Tali Perry
2020-05-21 11:09 ` [PATCH v12 1/3] dt-bindings: i2c: npcm7xx: add NPCM I2C controller Tali Perry
2020-05-21 11:09 ` Tali Perry
2020-05-21 19:58 ` robh
2020-05-21 19:58 ` robh
2020-05-21 11:09 ` [PATCH v12 2/3] i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver Tali Perry
2020-05-21 11:09 ` Tali Perry
2020-05-21 14:23 ` Andy Shevchenko
2020-05-21 14:23 ` Andy Shevchenko
2020-05-21 14:31 ` Wolfram Sang
2020-05-21 14:31 ` Wolfram Sang
2020-05-21 14:45 ` Tali Perry
2020-05-21 14:45 ` Tali Perry
2020-05-21 14:53 ` Andy Shevchenko
2020-05-21 14:53 ` Andy Shevchenko
2020-05-21 20:37 ` Wolfram Sang [this message]
2020-05-21 20:37 ` Wolfram Sang
2020-05-21 20:47 ` Tali Perry
2020-05-21 20:47 ` Tali Perry
2020-05-21 21:21 ` Wolfram Sang
2020-05-21 21:21 ` Wolfram Sang
2020-05-22 14:45 ` Wolfram Sang
2020-05-22 14:45 ` Wolfram Sang
2020-05-21 11:09 ` [PATCH v12 3/3] i2c: npcm7xx: Add support for slave mode for Nuvoton Tali Perry
2020-05-21 11:09 ` Tali Perry
2020-05-21 14:36 ` Andy Shevchenko
2020-05-21 14:36 ` Andy Shevchenko
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=20200521203758.GA20150@ninjato \
--to=wsa@the-dreams.de \
--cc=andriy.shevchenko@linux.intel.com \
--cc=avifishman70@gmail.com \
--cc=benjaminfair@google.com \
--cc=brendanhiggins@google.com \
--cc=devicetree@vger.kernel.org \
--cc=kfting@nuvoton.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ofery@google.com \
--cc=openbmc@lists.ozlabs.org \
--cc=robh+dt@kernel.org \
--cc=tali.perry1@gmail.com \
--cc=tmaimon77@gmail.com \
--cc=venture@google.com \
--cc=yuenn@google.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.