From: Wolfram Sang <wsa@the-dreams.de>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Neelesh Gupta <neelegup@linux.vnet.ibm.com>,
linuxppc-dev@ozlabs.org, linux-i2c@vger.kernel.org
Subject: Re: [PATCH v2] i2c: Driver to expose PowerNV platform i2c busses
Date: Tue, 25 Nov 2014 18:14:03 +0100 [thread overview]
Message-ID: <20141125171403.GA9716@katana> (raw)
In-Reply-To: <1416889937.4998.54.camel@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 2155 bytes --]
On Tue, Nov 25, 2014 at 03:32:17PM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2014-11-24 at 13:18 +0100, Wolfram Sang wrote:
> >
> > I think there are now 3 drivers in my queue which are not fully I2C
> > compatible but more supporting the very minimum to, say, read an
> > eeprom.
> > I am not feeling well to allow them to use I2C_FUNC_I2C. So, I want to
> > think about ways how to communicate deficiencies like "only 255 byte"
> > or
> > "only WRRD messages" to users of that I2C controller. This is most
> > likely not happening before 3.19. But assistance is very welcome.
>
> There are drivers doing that already, this is afaik common practice.
Well, there are drivers doing it, but to me this is somewhere between a
hack and a workaround. Somehow like using subsys_initcall() to overcome
probe ordering issues. That has never been nice and I still don't have a
solution how to convert those drivers back to module_init() + deferred
probe without causing regressions. As a result, people still want to
copy that behaviour.
> Please don't gate the merging process to some hypothetical rework that
> will imply reworking also a number of user space tools and in-kernel i2c
> device drivers. Basically that would mean "your platform won't be
> supported upstream for the next year and btw, rewrite all userspace".
Call me naive but I don't think we need to rewrite all userspace. That
is what I am at least aiming for.
> By all means let's create new "smbus" APIs for >1 bytes offset but let's
> not make it a gate to merging drivers using the existing way of doing
> things that has been so far perfectly functional.
You say "let's", yet my experience is that once I accept a patch like
yours, people are off with their support leaving me alone with the
topic. Not because they are evil, but because they also have tons of
other stuff to do. I perfectly understand I know this myself. And then,
more and more people will come asking for the same as you and the
situation gets harder and harder to fix.
That all being said, the driver has other issues which I will mention in
a seperate thread.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2014-11-25 17:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-16 17:17 [PATCH v2] i2c: Driver to expose PowerNV platform i2c busses Neelesh Gupta
2014-11-20 14:22 ` Neelesh Gupta
2014-11-24 12:18 ` Wolfram Sang
2014-11-25 4:32 ` Benjamin Herrenschmidt
2014-11-25 17:14 ` Wolfram Sang [this message]
2014-11-25 17:53 ` Wolfram Sang
2014-11-25 20:36 ` Benjamin Herrenschmidt
2014-12-01 16:56 ` 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=20141125171403.GA9716@katana \
--to=wsa@the-dreams.de \
--cc=benh@kernel.crashing.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=neelegup@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).