All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-i2c <linux-i2c@vger.kernel.org>
Subject: Re: PMBus and SMBUS_BLOCK with "extended" lenght
Date: Wed, 19 Apr 2017 15:40:27 +1000	[thread overview]
Message-ID: <1492580427.25766.131.camel@kernel.crashing.org> (raw)
In-Reply-To: <20170331163336.4sy4br3i2o5etcoe@ninjato>

On Fri, 2017-03-31 at 18:33 +0200, Wolfram Sang wrote:
> Hi,
> 
> > Did anybody give thoughts to how we could support "smbus" block
> > transfers with a size up to 0xff ? This is an extension of smbus
> > that part of the PMbus protocol spec.
> 
> For completeness, SMBus Spec V3 (released 2015) increased the allowed
> transfer size to 255 as well.
> 
> > 
> > Our current code has a lot of places where I2C_SMBUS_BLOCK_MAX is
> > hard wired. Including down in almost all drivers.
> > 
> > So it would have to be an evolutionary process.
> > 
> > I was thinking a message flag along with a functionality bit
> > maybe ?
> 
> I have never really scratched my head about this issue yet and don't
> know of any on-going activity. It is notable, though, that we export
> I2C_SMBUS_BLOCK_MAX to userspace, too.

Right. I don't think we can change it. We could either define a whole
new set of block read/write that support "extended" max, or probably
easier, a msg flag indicating that this is supported.

We would need a backend bus capability as well since all the busses
today will barf if the device returns something larger than
I2C_SMBUS_BLOCK_MAX.

Not a huge deal, all this is just a thought, I don't think I have a
device to deal with today that will return more on any of my systems (I
can double check later). I just noticed that while reading the PMbus
spec.

Cheers,
Ben.

  reply	other threads:[~2017-04-19  5:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-31  8:17 PMBus and SMBUS_BLOCK with "extended" lenght Benjamin Herrenschmidt
2017-03-31 16:33 ` Wolfram Sang
2017-04-19  5:40   ` Benjamin Herrenschmidt [this message]
2017-04-19  6:54     ` Wolfram Sang

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=1492580427.25766.131.camel@kernel.crashing.org \
    --to=benh@kernel.crashing.org \
    --cc=linux-i2c@vger.kernel.org \
    --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.