All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Glauber <jan.glauber@caviumnetworks.com>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: Wolfram Sang <wsa-dev@sang-engineering.com>,
	linux-i2c@vger.kernel.org,
	Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com>
Subject: Re: [PATCH 4/4] i2c: octeon: thunderx: Add I2C_CLASS_HWMON
Date: Thu, 20 Apr 2017 11:16:32 +0200	[thread overview]
Message-ID: <20170420091632.GA8383@hc> (raw)
In-Reply-To: <20170125204923.2mxtlszvco6wxjok@ninjato>

On Wed, Jan 25, 2017 at 09:49:23PM +0100, Wolfram Sang wrote:
> On Sun, Dec 11, 2016 at 11:04:35PM +0100, Wolfram Sang wrote:
> > On Fri, Dec 09, 2016 at 10:31:58AM +0100, Jan Glauber wrote:
> > > It was reported that ipmi_ssif fails to create the
> > > ipmi device on some systems if the adapter class is not containing
> > > I2C_CLASS_HWMON. Fix it by setting the class.
> > > 
> > > Reported-by: Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com>
> > > Signed-off-by: Jan Glauber <jglauber@cavium.com>
> > 
> > The intention of adapter classes is to *limit* probing to a certain
> > class of devices. If a class is needed to *enable* probing, then
> > something there looks wrong. From the details given, this must be solved
> > elsewhere I'd say.
> 
> Makes sense?
> 

Hi Wolfram,

I've looked at this again because apparently auto-detection of BMCs
(ipmi_ssif driver) is not working anymore.

Debugging it shows that ssif_probe is not called when ipmi_ssif is
trying to automatically detect BMCs. Adding the i2c device manually
works fine (ssif_probe called).

Setting the class value in the ThunderX i2c driver to I2C_CLASS_HWMON
makes the autodection of ipmi_ssif work.

Looking for clues how to solve this (because you mentioned this might be
the wrong solution) I've stumbled over this:

Documentation/i2c/writing-clients:
  You simply have to define a detect callback which will attempt to
  identify supported devices (returning 0 for supported ones and -ENODEV
  for unsupported ones), a list of addresses to probe, and a device type
  (or class) so that only I2C buses which may have that type of device
  connected (and not otherwise enumerated) will be probed.  For example,
  a driver for a hardware monitoring chip for which auto-detection is
  needed would set its class to I2C_CLASS_HWMON, and only I2C adapters
  with a class including I2C_CLASS_HWMON would be probed by this driver.
  Note that the absence of matching classes does not prevent the use of
  a device of that type on the given I2C adapter.  All it prevents is
  auto-detection; explicit instantiation of devices is still possible.

We do want auto-detection, so either this text is wrong or setting
I2C_CLASS_HWMON in our i2c adapter is correct. Am I missing
something?

thanks,
Jan

  parent reply	other threads:[~2017-04-20  9:16 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-09  9:31 [PATCH 0/4] i2c octeon & thunderx bug fixes Jan Glauber
2016-12-09  9:31 ` [PATCH 1/4] i2c: octeon: thunderx: TWSI software reset in recovery Jan Glauber
2016-12-11 22:01   ` Wolfram Sang
2016-12-09  9:31 ` [PATCH 2/4] i2c: octeon: thunderx: Remove double-check after interrupt Jan Glauber
2016-12-11 22:01   ` Wolfram Sang
2016-12-09  9:31 ` [PATCH 3/4] i2c: octeon: thunderx: Limit register access retries Jan Glauber
2016-12-11 22:01   ` Wolfram Sang
2016-12-12 16:07     ` Jan Glauber
2016-12-12 16:07       ` Jan Glauber
2016-12-13 20:32       ` Wolfram Sang
2016-12-17 18:29   ` Wolfram Sang
2016-12-09  9:31 ` [PATCH 4/4] i2c: octeon: thunderx: Add I2C_CLASS_HWMON Jan Glauber
2016-12-11 22:04   ` Wolfram Sang
2017-01-25 20:49     ` Wolfram Sang
2017-01-26  6:10       ` Jan Glauber
2017-01-26  6:10         ` Jan Glauber
2017-04-20  9:16       ` Jan Glauber [this message]
2017-04-20 15:55         ` Wolfram Sang
2017-04-20 17:27           ` Jan Glauber
2017-04-21  6:29             ` Wolfram Sang
2017-04-21 14:31               ` Jan Glauber

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=20170420091632.GA8383@hc \
    --to=jan.glauber@caviumnetworks.com \
    --cc=Vadim.Lomovtsev@caviumnetworks.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=wsa-dev@sang-engineering.com \
    --cc=wsa@the-dreams.de \
    /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.