sers?
Yes, it would help me. And users, too, I am quite sure. For me, if I mix
up two numbers while debugging, I am hunting ghosts for a while until I
realize my mistake. So:
Acked-by: Wolfram Sang
I think the main drawback is that ERRORCODES in vsprintf.c now need
maintenance, but I think it is worth
tually review all of this. But I trust you and we can fix things
later. So:
Acked-by: Wolfram Sang
I assume this goes in via your or doc-tree?
> Next/merge.log| 6 +-
This file doesn't exist upstream, though.
signature.asc
Description: PGP signature
ently located at
> Documentation/firmware-guide/acpi/enumeration.rst.
>
>
> Method 2: Instantiate the devices explicitly
For this I2C part:
Reviewed-by: Wolfram Sang
signature.asc
Description: PGP signature
Typo: the data line is called "SDA" not "SCA".
Signed-off-by: Wolfram Sang
---
Documentation/driver-api/gpio/driver.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/driver-api/gpio/driver.rst
b/Documentation/driver-api/gpio/driver.rs
Hi Boris,
> What we could do though, is expose I3C devices that do not have a
> driver in kernel space, like spidev does.
...
> Mark, Wolfram, Arnd, Greg, any opinion?
Is there a benefit for having drivers in userspace? My gut feeling is to
encourage people to write kernel drivers. If this is,
Boris,
> This patch series is a proposal for the I3C master driver for Synopsys IP.
Any news on the I3C mailing list? It is not much yet, still I was
wondering...
signature.asc
Description: PGP signature
Helps reading and hopefully avoids duplicates. Also, consistently add
the trailing '/' to make clear those are directories.
Signed-off-by: Wolfram Sang
---
MAINTAINERS | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9a
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
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. Th
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
> immu
This header only contains platform_data. Move it to the proper directory.
Signed-off-by: Wolfram Sang
---
Documentation/i2c/muxes/i2c-mux-gpio | 4 ++--
MAINTAINERS | 2 +-
drivers/i2c/busses/i2c-i801.c| 2 +-
drivers/i2c
This header only contains platform_data. Move it to the proper directory.
Signed-off-by: Wolfram Sang
---
Documentation/i2c/busses/i2c-ocores| 2 +-
drivers/i2c/busses/i2c-ocores.c| 2 +-
drivers/mfd/timberdale.c | 2 +-
include/linux
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 to
> +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 already
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
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
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
> (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
> - 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) */
> + /*
> + * Usi
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
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
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 proje
> > - info.archdata = &dev_ad;
>
> Why did you drop this?
If the removal is safe, it should be a seperate patch, I mean.
signature.asc
Description: PGP signature
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 = &dev_ad;
Why did you drop this?
Regards,
Wolfram
signature.asc
Description: PGP signature
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 of which are reported by
> > coccin
> 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
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 from its PM callbacks.
>
> Fi
> 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
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 the
> > 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 y
> 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. :)
> 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
> > The second way is to have a number of #ifdef and complex
> > Kconfig dependencies for the driver to only register the
> > device_driver objects for the buses that are enabled. This
> > is also doable, but everyone gets the logic wrong the first time.
>
> Hm, I understand now why you'd prefer
able busses
> like USB than I2C or SPI.
Acked-by: Wolfram Sang
> 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 sense.
> To me
> > 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
th
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 maste
> +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 pr
> > 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
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
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
---
Documentation/DMA-API.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/DMA
> 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 resen
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
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 sla
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
---
Documentation/driver-api/i2c.rst | 3 +
drivers/i2c/Makefile | 2 +-
drivers/i2c
The I2C core files were renamed, adapt the textfile to it.
Signed-off-by: Wolfram Sang
---
Documentation/i2c/dev-interface | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface
index bcf919d8625ceb
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
---
Documentation/driver-api/i2c.rst | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/Documentation/driver-api
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 w
include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: Wolfram Sang
---
Documentation/hwmon/ads1015| 2 +-
MAINTAINERS| 2 +-
drivers/hwmon/ads1015.c| 2
cm/linux/kernel/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 o
include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: Wolfram Sang
---
Documentation/hwmon/ltc4245| 2 +-
drivers/hwmon/ltc4245.c| 2 +-
include/linux/{i2c => platform_data}/ltc4245.h | 0
include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: Wolfram Sang
---
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
> 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
> 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 g
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")
>
> 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 clie
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 be
.
>
> Acked-by: Jonathan Cameron
> Signed-off-by: Peter Rosin
Acked-by: Wolfram Sang
signature.asc
Description: PGP signature
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
> Registers CID and CSD are already exported through sysfs so let's make
> this interface complete by adding missing OCR register.
This sentence was missing for me, thanks.
> Do I need to send v2 with updated change log?
Ulf will tell us.
signature.asc
Description: PGP signature
Bojan,
On Mon, Jul 04, 2016 at 01:56:55PM +0200, Bojan Prtvar wrote:
> Make operation conditions register (OCR) easily accessible from user space.
>
> Signed-off-by: Bojan Prtvar
You described "what" above. Can you add the "why", too?
Regards,
Wolfram
signature.asc
Description: PGP signa
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
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.
>
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 call
> (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: P
> > - 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 (Broadwell)
> 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
; Tested-by: Andrew Duggan
> Signed-off-by: Benjamin Tissoires
Did some high level review. Did not dig into datasheets.
Acked-by: Wolfram Sang
signature.asc
Description: PGP signature
> diff --git a/Documentation/i2c/smbus-protocol
> b/Documentation/i2c/smbus-protocol
> index 6012b12..4e07848 100644
> --- a/Documentation/i2c/smbus-protocol
> +++ b/Documentation/i2c/smbus-protocol
> @@ -199,6 +199,9 @@ alerting device's address.
>
> [S] [HostAddr] [Wr] A [DevAddr] A [DataLow]
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.
>
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 upda
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
> | \
>EEPRO
> 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 numb
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
> Yes, they look like reasonable complaints.
Thanks for fixing them. I just sent out my latest comments and when you
fix those and send V8, I'll apply that right away. I think we are safe
to fix the rest incrementally if needed. Note that I didn't review the
IIO and media patches, I trust the revi
> +static int i2c_mux_trylock_bus(struct i2c_adapter *adapter, int flags)
> +{
> + struct i2c_mux_priv *priv = adapter->algo_data;
> + struct i2c_adapter *parent = priv->muxc->parent;
> +
> + if (!rt_mutex_trylock(&parent->mux_lock))
> + return 0;
> + if (!(flags & I2C_L
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 flag
> Yes, obviously... I'll make that change locally and wait for the rest.
Another nit: You could use '--strict' with checkpatch and see if you
want to fix the issues reported. I am not keen on those (except for
'space around operators'), it's a matter of taste I guess, but maybe you
like some of th
> 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
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, an
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 flag
> 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 tha
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 fo
> > I'd suggest to rename 'adapters' into 'num_adapters' throughout this
> > patch. I think it makes the code a lot easier to understand.
>
> Hmm, you mean just the variable names, right? And not function names
> such as i2c_mux_reserve_(num_)adapters?
Yes, only variable names.
> > Despite that
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;
> +
> + if
> 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 wi
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
On Tue, Feb 02, 2016 at 08:41:25PM +0900, Masanari Iida wrote:
> This path fix spelling typos found in Documentation/i2c.
>
> Signed-off-by: Masanari Iida
Probably too late already, but still:
Acked-by: Wolfram Sang
Thanks!
signature.asc
Description: Digital signature
87 matches
Mail list logo
