On Wed, 20 May 2015 17:46:44 +0200
Richard Weinberger wrote:
> On Wed, May 20, 2015 at 5:27 PM, Sudip Mukherjee
> wrote:
> > Lets give the parport subsystem a proper name and start
> > maintaining the files.
>
> Excuse me, but usually someone takes over the maintainer role after
> proving that
On Fri, 30 Jan 2015 16:36:27 +
Alexandre Daoud wrote:
> Hey Linux-i2c,
>
> I have a bit of an unorthodox question for this mailing list but you guys
> seem like the only people who could help me at this point.
>
> I have a Dell Venue 11 Pro tablet with the Lynxpoint I2C busses (INT33C2,
>
On Sun, 2 Nov 2014 14:58:07 +0100
Wolfram Sang wrote:
> So, I recently learned that there is wait_for_completion_io_* because one I2C
> driver uses it instead of wait_for_completion_*. I want consistency, so
> technically the io-versions seem to be the correct ones to me, because, well,
> we are
On Fri, 12 Sep 2014 10:36:07 -0700
"David E. Box" wrote:
> +#if IS_ENABLED(CONFIG_I2C_SHARED_CONTROLLER)
> +extern int i2c_acquire_ownership(struct device *dev);
> +extern int i2c_release_ownership(struct device *dev);
> +#endif
You can just have the prototypes anyway - no need for more ifdefs t
On Mon, 2 Jun 2014 14:41:03 +0100
Lee Jones wrote:
> Currently the I2C framework insists on devices supplying an I2C ID
> table. Many of the devices which do so unnecessarily adding quite a
> few wasted lines to kernel code. This patch allows drivers a means
> to 'not' supply the aforementione
> I had to check BYT specs about that and I couldn't find if it does
> posted-writes.
Then I would assume it does unless you can find a hardware engineer to
sign a statement in blood to that effect 8)
> Actually the following patch should fix the problem as well. Just move the
> HW enable to hap
On Sat, 5 Apr 2014 09:13:16 +0300
"Westerberg, Mika" wrote:
> On Sat, Apr 05, 2014 at 12:54:33AM +0300, Du, Wenkai wrote:
> > >Interrupt masking is done already after each transaction.
> >
> > At end of transfer, the code uses __i2c_dw_enable(dev, false) to disable
> > adapter. This function doe
> I'm suggesting identifying a range of addresses on a bus with a "port"
> (or whatever it should be called). Multiple ports could claim
> non-overlapping ranges on the same bus.
Which is fine until you meant a mux or a device that can be moved about
by writing to it, or has a wide range of addre
> example, lots of graphics drivers provide i2c busses, and those busses
> often contain eeproms, and, in theory, things should know that the
> eeprom is associated with a particular graphics port, for example.
> Unfortunately, the i2c core does not know that, things like
> decode-dimms will try to
