[PATCH 2/2] MAINTAINERS: add i2c to the excludes for Documentation

I'll handle these myself but thanks for providing the fallback! Signed-off-by: Wolfram Sang --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 2698ee553008..39c39dd6fba6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4487,6 +4487,7 @@ F

Re: [PATCH v5 3/5] i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C controller

Hi, On Fri, Mar 23, 2018 at 02:20:59PM -0600, Karthikeyan Ramasubramanian wrote: > This bus driver supports the GENI based i2c hardware controller in the > Qualcomm SOCs. The Qualcomm Generic Interface (GENI) is a programmable > module supporting a wide range of serial interfaces including I2C.

Re: [PATCH 0/7] i2c: clean up include/linux/i2c-*

On Thu, Apr 19, 2018 at 10:00:06PM +0200, Wolfram Sang wrote: > Move all plain platform_data includes to the platform_data-dir > (except for i2c-pnx which can be moved into the driver itself). > > My preference is to take these patches via the i2c tree. I can provide an > i

[PATCH 2/7] i2c: i2c-mux-gpio: move header to platform_data

This header only contains platform_data. Move it to the proper directory. Signed-off-by: Wolfram Sang <w...@the-dreams.de> --- Documentation/i2c/muxes/i2c-mux-gpio | 4 ++-- MAINTAINERS | 2 +- drivers/i2c/busses/i2c-i801.c

[PATCH 3/7] i2c: i2c-ocores: move header to platform_data

This header only contains platform_data. Move it to the proper directory. Signed-off-by: Wolfram Sang <w...@the-dreams.de> --- Documentation/i2c/busses/i2c-ocores| 2 +- drivers/i2c/busses/i2c-ocores.c| 2 +- drivers/mfd/timberdale.c

[PATCH 0/7] i2c: clean up include/linux/i2c-*

if dependencies are against us. The current branch can be found here: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/platform_data and buildbot had no complaints. Looking forward to comments or Acks, Revs... Kind regards, Wolfram Wolfram Sang (7): i2c: i2c-gpio: move header

Re: [PATCH v3 2/3] Documentation/i2c: sync docs with current state of i2c-tools

> +The above functions are made available by linking against the libi2c library, > +which is provided by the i2c-tools project. See: > +https://git.kernel.org/pub/scm/utils/i2c-tools/i2c-tools.git/. In the beginning, we say that '#include ' is needed. Shouldn't we mention i2c-tools there

Re: [PATCH v3 3/3] Documentation/i2c: adopt kernel commenting style in examples

On Fri, Apr 13, 2018 at 10:42:57AM -0700, Sam Hansen wrote: > The example I2C code is rewritten to adopt the preferred kernel block > commenting style. > > Signed-off-by: Sam Hansen Applied to for-current, thanks! signature.asc Description: PGP signature

Re: [PATCH v3 2/3] Documentation/i2c: sync docs with current state of i2c-tools

On Fri, Apr 13, 2018 at 10:42:56AM -0700, Sam Hansen wrote: > Currently, Documentation/i2c/dev-interface describes the use of > i2c_smbus_* helper routines as static inlined functions provided by > linux/i2c-dev.h. Work has been done to refactor the linux/i2c-dev.h file > in the i2c-tools project

Re: [PATCH v3 1/3] Documentation/i2c: whitespace cleanup

On Fri, Apr 13, 2018 at 10:42:55AM -0700, Sam Hansen wrote: > This strips trailing whitespace in Documentation/i2c/dev-interface. > > Signed-off-by: Sam Hansen Applied to for-current, thanks! signature.asc Description: PGP signature

Re: [PATCH] Documentation/i2c: sync docs with current state of i2c-tools.

> (also, did I send the v3 patch series threaded correctly?) Yes, that worked. Thanks! Things to improve there: I was both in To: and CC: field, so I got mails twice. Jean was missing completely. signature.asc Description: PGP signature

Re: [PATCH v2 3/3] Documentation/i2c: adopt kernel commenting style in examples

> - int adapter_nr = 2; /* probably dynamically determined */ Such comments are actually OK. > -/* ERROR HANDLING; you can check errno to see what went wrong */ Such as well. > - /* Using I2C Write, equivalent of > - i2c_smbus_write_word_data(file, reg, 0x6543) */ > + /* > + *

Re: [PATCH v2 2/3] Documentation/i2c: sync docs with current state of i2c-tools

On Fri, Apr 13, 2018 at 09:44:04AM -0700, Sam Hansen wrote: > Currently, Documentation/i2c/dev-interface describes the use of > i2c_smbus_* helper routines as static inlined functions provided by > linux/i2c-dev.h. Work has been done to refactor the linux/i2c-dev.h file > in the i2c-tools project

Re: [PATCH v2 1/3] Documentation/i2c: whitespace cleanup

On Fri, Apr 13, 2018 at 09:44:03AM -0700, Sam Hansen wrote: > This strips trailing whitespace in Documentation/i2c/dev-interface. > > Signed-off-by: Sam Hansen Looks good to me. But please send new series as seperate threads. signature.asc Description: PGP signature

Re: [PATCH] Documentation/i2c: sync docs with current state of i2c-tools.

Hi, On Thu, Apr 12, 2018 at 02:33:42PM -0700, Sam Hansen wrote: > Currently, Documentation/i2c/dev-interface describes the use of i2c_smbus_* > helper routines as static inlined functions provided by linux/i2c-dev.h. Work > has been done to refactor the linux/i2c-dev.h file in the i2c-tools

Re: [PATCH v3 01/11] i2c: Export of_i2c_get_board_info()

> > - info.archdata = _ad; > > Why did you drop this? If the removal is safe, it should be a seperate patch, I mean. signature.asc Description: PGP signature

Re: [PATCH v3 01/11] i2c: Export of_i2c_get_board_info()

Hi Boris, > - rebase on v4.15-rc1 This code has changed a little meanwhile. Please check my for-next branch. Some changes are identical, some similar. > - info.archdata = _ad; Why did you drop this? Regards, Wolfram signature.asc Description: PGP signature

Re: [PATCH] Documentation: i2c: drop unnecessary .owner field in examples

On Mon, Jan 15, 2018 at 10:24:52PM +0200, Andy Shevchenko wrote: > On Mon, Jan 15, 2018 at 2:08 PM, Nicholas Mc Guire wrote: > > From: Nicholas Mc Guire > > > > Currently there are a few drivers that still set the .owner > > in the i2c_driver structure - all

Re: [RFC 0/5] Add I3C subsystem

> MIPI has opened the I3C spec [1], it can be downloaded here [2]. Wow, that's good news. And so fast. Congrats and thanks a lot! signature.asc Description: PGP signature

Re: [PATCH 11/12] PM: i2c-designware-platdrv: Optimize power management

On Mon, Oct 16, 2017 at 03:31:17AM +0200, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Optimize the power management in i2c-designware-platdrv by making it > set the DPM_FLAG_SMART_SUSPEND and DPM_FLAG_LEAVE_SUSPENDED which > allows some code to be dropped

Re: Documentation: add Kernel Driver Statement to the kernel

> Not that sphinx doesn't have it's own issues, but you have to admit it > is much better now than it used to be, right? That goes without saying, but we still added plain textfiles to Documentation/ since 2008, so I was wondering... signature.asc Description: PGP signature

Re: Documentation: add Kernel Driver Statement to the kernel

On Fri, Oct 06, 2017 at 11:10:38AM +0200, gre...@linuxfoundation.org wrote: > Way back in 2008 we didn't have "robust" in-kernel documentation system, > so the idea of putting something like the kernel driver statement in the > kernel tree wasn't even imagined. But now that has changed, so add

Re: [RFC 2/5] i3c: Add core I3C infrastructure

> > Yes, my wording was a bit too strong. It is possible, sure. Yet, I > > understood that one of the features of I3C is to have in-band interrupt > > support. We will see if the demand for backward compatibility or "saving > > pins" is higher. > > > > Indeed, you can use in-band interrupts if

Re: [RFC 2/5] i3c: Add core I3C infrastructure

> I'm surprised they didn't allow for slave clock stretching when > communicating with a legacy i2c device, it will prohibit use of a rather > large class of devices. :( Yes, but I3C is push/pull IIRC. > As for interrupts you are always free to wire up an out-of-band > interrupt like before. :)

Re: [RFC 2/5] i3c: Add core I3C infrastructure

> I do not know of any real devices as of today (all my tests have been > done with a dummy/fake I3C slaves emulated with a slave IP), I see. > spec clearly describe what legacy/static addresses are for and one of > their use case is to connect an I3C device on an I2C bus and let it act > as an

Re: [RFC 2/5] i3c: Add core I3C infrastructure

s > like USB than I2C or SPI. Acked-by: Wolfram Sang <w...@the-dreams.de> > Of course, I can move all the code in drivers/i2c/, but that won't > change the fact that I3C and I2C busses are completely different > with little to share between them. That wouldn't make sen

Re: [RFC 0/5] Add I3C subsystem

> > I agree this is the least invasive and also the most compatible > > approach. The other solution would probably be to have some kind of > > emulation layer? > > Could you detail a bit more what you mean by "emulation layer"? Not really. That was more a extremly high level approach of what

Re: [RFC 0/5] Add I3C subsystem

Hi Boris, > This patch series is a proposal for a new I3C [1] subsystem. Nice. Good luck with that! Some hi-level comments from me related to I2C. I can't say a lot more because the specs are not public :( > - the bus element is a separate object and is not implicitly described > by the

Re: [RFC 2/5] i3c: Add core I3C infrastructure

> +This document is just a brief introduction to the I3C protocol and the > concepts > +it brings on the table. If you need more information, please refer to the > MIPI > +I3C specification. I wish I could. > + > +Introduction > + > + > +The I3C (I-Cube-C) is a MIPI standardized

Re: [PATCH v15 00/13] mux controller abstraction and iio/i2c muxes

> > All now queued up, nice work, thanks for sticking with this. > > *big sigh of relief* I can imagine. Great work, Peda! Congrats. signature.asc Description: PGP signature

Re: [PATCH 0/8] i2c: refactor core and break out blocks

On Fri, May 26, 2017 at 10:20:51AM +0200, Wolfram Sang wrote: > Yes, I wanted to do this for years now... The I2C core became a huge > monolithic > blob getting harder and harder to maintain. This series breaks out some > functional parts into seperate files. This makes the code easi

[PATCH] Documentation: DMA API: fix a typo in a function name

Correct the typo, the wrongly typed function does not exist. Fixes: 6c9c6d6301287e ("dma-debug: New interfaces to debug dma mapping errors") Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- Documentation/DMA-API.txt | 2 +- 1 file changed, 1 insertion(+), 1 d

Re: [PATCH 0/8] i2c: refactor core and break out blocks

> If you don't mind sending the whole series to the intel-gfx list (Cc'd), > our CI will run a bunch of tests on it, exercising our use of the I2C > adapter interfaces for display data channel and I2C over Display Port > native aux. Cool, that sounds very helpful! Thanks for the offer, I'll

[PATCH 1/8] i2c: rename core source file to allow refactorization

The I2C core became quite huge and its monolithic structure makes maintenance hard. So, prepare to break out some functionality into seperate files by renaming the source file. Note that we keep the resulting object name constant to avoid regressions. Signed-off-by: Wolfram Sang &l

[PATCH 0/8] i2c: refactor core and break out blocks

are there yet and the series is ready. Looking forward to comments. A branch can be found here: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/core-refactor Kind regards, Wolfram Wolfram Sang (8): i2c: rename core source file to allow refactorization i2c: break out slave support

[PATCH 3/8] i2c: break out smbus support into seperate file

Break out the exported SMBus functions and the emulation layer into a seperate file. This also involved splitting up the tracing header into an I2C and an SMBus part. Signed-off-by: Wolfram Sang <w...@the-dreams.de> --- Documentation/driver-api/i2c.rst | 3 + drivers/i2c/Ma

[PATCH 6/8] docs: i2c: dev-interface: adapt to new filenames of the i2c core

The I2C core files were renamed, adapt the textfile to it. Signed-off-by: Wolfram Sang <w...@the-dreams.de> --- Documentation/i2c/dev-interface | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-int

[PATCH] docs: driver-api: i2c: remove some outdated information

a) Linux can be an I2C slave meanwhile b) all drivers except one use the driver model currently Update the documentation. Signed-off-by: Wolfram Sang <w...@the-dreams.de> --- Documentation/driver-api/i2c.rst | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff

Re: [PATCH 0/5] hwmon: move include files out of include/linux/i2c

Hi Guenter, > > Note that some files don't seem to have upstream > > users in board code, so they maybe could even be removed? I didn't check for > > While I understand where you are coming from, I am not typically that > aggressive. > Such removals force vendors who are not really forthcoming

[PATCH 1/5] hwmon: ads1015: move header file out of I2C realm

include/linux/i2c is not for client devices. Move the header file to a more appropriate location. Signed-off-by: Wolfram Sang <w...@the-dreams.de> --- Documentation/hwmon/ads1015| 2 +- MAINTAINERS| 2 +- drivers/hwmon/ads

[PATCH 0/5] hwmon: move include files out of include/linux/i2c

/git/wsa/linux.git i2c/platform_data Thanks and kind regards, Wolfram Wolfram Sang (5): hwmon: ads1015: move header file out of I2C realm hwmon: ds620: move header file out of I2C realm hwmon: ltc4245: move header file out of I2C realm hwmon: max6639: move header file out of I2C realm

[PATCH 3/5] hwmon: ltc4245: move header file out of I2C realm

include/linux/i2c is not for client devices. Move the header file to a more appropriate location. Signed-off-by: Wolfram Sang <w...@the-dreams.de> --- Documentation/hwmon/ltc4245| 2 +- drivers/hwmon/ltc4245.c| 2 +- include/linux/{i2c => plat

[PATCH 5/5] hwmon: pmbus: move header file out of I2C realm

include/linux/i2c is not for client devices. Move the header file to a more appropriate location. Signed-off-by: Wolfram Sang <w...@the-dreams.de> --- I decided to not move it to 'platform_data' but just one level up because 'pmbus.h' sounds pretty generic to me like 'i2c.h'. And it

Re: [PATCH v9 00/10] mux controller abstraction and iio/i2c muxes

> And conflicts -- if they show up -- will probably be trivial given the > nature of the series. Famous last words... Heh. I agree, though :) signature.asc Description: PGP signature

Re: [PATCH v9 00/10] mux controller abstraction and iio/i2c muxes

> Jonathan, Wolfram, do you have any preferences on how this should be > coordinated regarding the new iio and i2c drivers (and iio changes)? You got the acks, all is fine, I think. > My plan is to at some point declare the branch immutable. Then both of > you can pull it in. Or? Yup, sounds

Re: [PATCH] i2c: i2c-mux-gpio: rename i2c-gpio-mux to i2c-mux-gpio

On Tue, Feb 07, 2017 at 10:41:55PM +0100, Peter Rosin wrote: > The rename did the wrong thing for this documentation file all those > years ago. Fix that as well as the neglected rename of the platform > data structure. > > Fixes: e7065e20d9a6 ("i2c: Rename last mux driver to standard pattern") >

Re: [PATCH linux v2 0/6] drivers: hwmon: Add On-Chip Controller driver

> This patchset adds a hwmon driver to support the OCC (On-Chip Controller) > on the IBM POWER8 and POWER9 processors, from a BMC (Baseboard Management > Controller). The OCC is an embedded processor that provides real time > power and thermal monitoring. Please don't cc the I2C list for I2C

Re: [PATCH v7 00/12] mux controller abstraction and iio/i2c muxes

Hi peda, > One thing that I would like to do, but don't see a solution > for, is to move the mux control code that is present in > various drivers in drivers/i2c/muxes to this new minimalistic > muxing subsystem, thus converting all present i2c muxes (but > perhaps not gates and arbitrators) to

Re: [PATCH v7 10/12] i2c: i2c-mux-simple: new driver

ogy. > > Acked-by: Jonathan Cameron <ji...@kernel.org> > Signed-off-by: Peter Rosin <p...@axentia.se> Acked-by: Wolfram Sang <w...@the-dreams.de> signature.asc Description: PGP signature

Re: [PATCH] i2c: i2c-topology: fix minor whitespace nit

On Thu, Nov 10, 2016 at 03:03:21PM +0100, Peter Rosin wrote: > Signed-off-by: Peter Rosin Applied to for-current, thanks! signature.asc Description: PGP signature

Re: [PATCH v8 3/4] i2c: i801: add support of Host Notify

On Thu, Jun 23, 2016 at 01:55:52PM -0700, Dmitry Torokhov wrote: > On Thu, Jun 16, 2016 at 08:09:42AM +0200, Wolfram Sang wrote: > > > > - removed the .resume hook as upstream changed suspend/resume hooks and > > > > there > > > > is no need in the end to

Re: [PATCH v8 1/4] i2c: add a protocol parameter to the alert callback

On Thu, Jun 09, 2016 at 04:53:47PM +0200, Benjamin Tissoires wrote: > .alert() is meant to be generic, but there is currently no way > for the device driver to know which protocol generated the alert. > Add a parameter in .alert() to help the device driver to understand > what is given in data. >

Re: [PATCH v8 2/4] i2c-smbus: add SMBus Host Notify support

On Thu, Jun 09, 2016 at 04:53:48PM +0200, Benjamin Tissoires wrote: > SMBus Host Notify allows a slave device to act as a master on a bus to > notify the host of an interrupt. On Intel chipsets, the functionality > is directly implemented in the firmware. We just need to export a > function to

Re: [PATCH v8 3/4] i2c: i801: add support of Host Notify

> (i2c-i801) can be carried over through the input tree. So as long as > you don't need to have a new feature without users for a short period > of time, that's fine by me :) That's fine. I have extremly high trust that the user of the feature will be added soon ;) signature.asc Description:

Re: [PATCH v8 3/4] i2c: i801: add support of Host Notify

> > - removed the .resume hook as upstream changed suspend/resume hooks and > > there > > is no need in the end to re-enable host notify on resume (tested on Lenovo > > t440 and t450). > > Actually, this hook seemed to be required on the Lenovo T440 (Haswell) > but not on the T450

Re: [PATCH v7 0/4] i2c-smbus: add support for HOST NOTIFY

> OK. I'll try to fetch those pending patches on patchwork and see how the > merge would behave. Thanks. If you have time for a bit of a reviewing eye on them, this would also be much appreciated :) signature.asc Description: PGP signature

Re: [PATCH v7 3/4] i2c: i801: add support of Host Notify

> Tested-by: Andrew Duggan <adug...@synaptics.com> > Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> Did some high level review. Did not dig into datasheets. Acked-by: Wolfram Sang <w...@the-dreams.de> signature.asc Description: PGP signature

Re: [PATCH v7 1/4] i2c: add a protocol parameter to the alert callback

On Tue, May 31, 2016 at 12:03:02PM +0200, Benjamin Tissoires wrote: > .alert() is meant to be generic, but there is currently no way > for the device driver to know which protocol generated the alert. > Add a parameter in .alert() to help the device driver to understand > what is given in data. >

Re: [PATCH v7 0/4] i2c-smbus: add support for HOST NOTIFY

Hi Benjamin, > this is mostly a resubmission of the v6 with the acks, tested-by and few typos > here and there. I actually reviewed v6 but got an NMI so writing the mails fell through the cracks :( Sorry about that! Good news is that the code is fine from my point of view, some documentation

Re: [PATCH v9 0/9] i2c mux cleanup and locking update

On Wed, May 04, 2016 at 10:15:26PM +0200, Peter Rosin wrote: > Hi! > > I have a pair of boards with this i2c topology: > >GPIO ---| -- BAT1 > | v / >I2C -+--B---+ MUX > | \ >

Re: [PATCH v7 16/24] i2c: allow adapter drivers to override the adapter locking

> A question on best practices here... I already did a v8 (but only as > a branch) so I think this will be v9, bit that's a minor detail. The > real question is what I should do about patches 1-15 that are already > in next? Send them too? If not, should I send 16-24 with the same old > patch

Re: [PATCH v7 16/24] i2c: allow adapter drivers to override the adapter locking

Hi Peter, thanks for the detailed explanation! > So maybe there should be only one flag, e.g. I2C_LOCK_ROOT_ADAPTER? > I.e. perhaps leave the future for later? I think this makes the current code easier understandable at this point, but I'll leave the decision to you. I am fine with both. Maybe

Re: [PATCH v7 16/24] i2c: allow adapter drivers to override the adapter locking

On Wed, Apr 20, 2016 at 05:17:56PM +0200, Peter Rosin wrote: > Add i2c_lock_bus() and i2c_unlock_bus(), which call the new lock_bus and > unlock_bus ops in the adapter. These funcs/ops take an additional flags > argument that indicates for what purpose the adapter is locked. > > There are two

Re: [PATCH v7 22/24] [media] rtl2832: change the i2c gate to be mux-locked

> So, I think all is ok, or do you need more than Tested-by? I think this will do. Thanks! signature.asc Description: PGP signature

Re: [PATCH v7 22/24] [media] rtl2832: change the i2c gate to be mux-locked

On Wed, Apr 20, 2016 at 05:18:02PM +0200, Peter Rosin wrote: > The root i2c adapter lock is then no longer held by the i2c mux during > accesses behind the i2c gate, and such accesses need to take that lock > just like any other ordinary i2c accesses do. > > So, declare the i2c gate mux-locked,

Re: [PATCH v7 00/24] i2c mux cleanup and locking update

> The problem with waiting until 4.8 with the rest of the series is that it > will likely go stale, e.g. patch 22 ([media] rtl2832: change the i2c gate > to be mux-locked) touches a ton of register accesses in that driver since > it removes a regmap wrapper that is rendered obsolete. Expecting

Re: [PATCH v7 00/24] i2c mux cleanup and locking update

This was the diff of v6: > 32 files changed, 1277 insertions(+), 915 deletions(-) This is v7: > 32 files changed, 1225 insertions(+), 916 deletions(-) So, we gained a little overall. And while the individual drivers have a few lines more now, I still think it is more readable. So, thanks

Re: [PATCH v6 01/24] i2c-mux: add common data for every i2c-mux instance

Hi Peter, first high-level review: > +int i2c_mux_reserve_adapters(struct i2c_mux_core *muxc, int adapters) I'd suggest to rename 'adapters' into 'num_adapters' throughout this patch. I think it makes the code a lot easier to understand. > +{ > + struct i2c_adapter **adapter; > + > +

Re: [PATCH v6 00/24] i2c mux cleanup and locking update

> can obviously take forever. At the same time, many of the patches are kind > of mechanical, and feels rather safe. I agree about the mechanical stuff, thus my suggestion. We do what we can about testing and reviewing. And once it reaches linux-next (hopefully next week latest), test coverage

Re: [PATCH v6 00/24] i2c mux cleanup and locking update

Hi Peter, > To summarize the series, there's some i2c-mux infrastructure cleanup work > first (I think that part stands by itself as desireable regardless), the > locking changes are in 16/24 and after with the real meat in 18/24. There > is some documentation added in 19/24 while 20/24 and after