[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190831094940.GA1138@kunai>
Date: Sat, 31 Aug 2019 11:49:41 +0200
From: Wolfram Sang <wsa@...-dreams.de>
To: Ray Jui <ray.jui@...adcom.com>
Cc: Rayagonda Kokatanur <rayagonda.kokatanur@...adcom.com>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>, linux-i2c@...r.kernel.org,
devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org,
bcm-kernel-feedback-list@...adcom.com,
Florian Fainelli <f.fainelli@...il.com>,
Lori Hikichi <lori.hikichi@...adcom.com>,
Icarus Chau <icarus.chau@...adcom.com>,
Shivaraj Shetty <sshetty1@...adcom.com>
Subject: Re: [PATCH v1 1/1] i2c: iproc: Add i2c repeated start capability
Hi Ray,
> > With all the limitations in place, I wonder if it might be easier to
> > implement an smbus_xfer callback instead? What is left that makes this
> > controller more than SMBus and real I2C?
> >
>
> Right. But what is the implication of using smbus_xfer instead of
> master_xfer in our driver?
>
> Does it mean it will break existing functions of the i2c app that our
> customers developed based on i2cdev (e.g., I2C_RDWR)?
If the customers uses I2C_RDWR (and it cannot be mapped to i2c_smbus_*
calls) then this is an indication that there is some I2C functionality
left which the HW can provide. I'd be interested which one, though.
>
> 1) Does
Maybe you wanted to describe it here and it got accidently cut off?
Regards,
Wolfram
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists