On Mon, 7 May 2018 06:35:51 -0300
Mauro Carvalho Chehab wrote:
> Solve those Sphinx warnings:
>
> ./include/linux/iio/iio.h:270: warning: Function parameter or member
> 'scan_type.sign' not described in 'iio_chan_spec'
> ./include/linux/iio/iio.h:270:
On Sat, 10 Mar 2018 23:07:30 +0100
Andreas Brauchli wrote:
> Support Sensirion SGP30 and SGPC3 multi-pixel I2C gas sensors
>
> Supported Features:
>
> * Indoor Air Quality (IAQ) concentrations for
> - tVOC (in_concentration_voc_input)
> - CO2eq
On Tue, 17 Oct 2017 13:58:21 -0700
Guenter Roeck wrote:
> On Tue, Oct 17, 2017 at 03:36:31PM -0500, Rob Herring wrote:
> > On Thu, Oct 12, 2017 at 02:36:04PM +0200, Maciej Purski wrote:
> > > Add optional max expected current property which allows calibrating
> > > the ina
On Wed, 11 Oct 2017 16:42:53 +0200
Maciej Purski <m.pur...@samsung.com> wrote:
> On 10/09/2017 03:35 PM, Jonathan Cameron wrote:
> > On Mon, 9 Oct 2017 10:08:42 +0200
> > Maciej Purski <m.pur...@samsung.com> wrote:
> >
> >> On 10/08/2017 11:47 AM, Jona
On Mon, 9 Oct 2017 10:08:42 +0200
Maciej Purski <m.pur...@samsung.com> wrote:
> On 10/08/2017 11:47 AM, Jonathan Cameron wrote:
> > On Wed, 04 Oct 2017 09:11:31 +0200
> > Maciej Purski <m.pur...@samsung.com> wrote:
> >
> >> On 10/01/2017 12:29 PM, Jona
On Wed, 04 Oct 2017 09:11:31 +0200
Maciej Purski <m.pur...@samsung.com> wrote:
> On 10/01/2017 12:29 PM, Jonathan Cameron wrote:
> > On Thu, 28 Sep 2017 14:50:12 +0200
> > Maciej Purski <m.pur...@samsung.com> wrote:
> >
> >> Max expected current is
On Thu, 28 Sep 2017 14:50:14 +0200
Maciej Purski wrote:
> Add optional max expected current property which allows calibrating
> the ina sensor in order to achieve requested precision. Document
> the changes in Documentation/hwmon/ina2xx.
>
This is introducing new generic
On Thu, 28 Sep 2017 14:50:12 +0200
Maciej Purski wrote:
> Max expected current is used for calculating calibration register value,
> Current LSB and Power LSB according to equations found in ina datasheet.
> Max expected current is now implicitly set to default value,
>
e:
> >> This patch adds documentation for the uncore PMUs on HiSilicon SoC.
> >>
> >> Reviewed-by: Jonathan Cameron <jonathan.came...@huawei.com>
> >> Signed-off-by: Shaokun Zhang <zhangshao...@hisilicon.com>
> >> S
On Mon, 14 Aug 2017 18:21:15 +0300
Gilad Ben-Yossef wrote:
> Invoking a possibly async. crypto op and waiting for completion
> while correctly handling backlog processing is a common task
> in the crypto API implementation and outside users of it.
>
> This patch adds a
On 14 August 2017 17:54:22 GMT+08:00, Bartosz Golaszewski <b...@bgdev.pl> wrote:
>2017-08-12 13:43 GMT+02:00 Jonathan Cameron <ji...@kernel.org>:
>> On Tue, 1 Aug 2017 16:50:26 +0200
>> Bartosz Golaszewski <b...@bgdev.pl> wrote:
>>
>>> Implement a
On Tue, 1 Aug 2017 16:50:27 +0200
Bartosz Golaszewski <b...@bgdev.pl> wrote:
> Add a resource managed version of irq_sim_init(). This can be
> conveniently used in device drivers.
>
> Signed-off-by: Bartosz Golaszewski <b...@bgdev.pl>
Looks pretty standard to me.
Ac
ht forward to me.
Acked-by: Jonathan Cameron <jonathan.came...@huawei.com>
> ---
> drivers/gpio/Kconfig | 2 +-
> drivers/gpio/gpio-mockup.c | 77
> +-
> 2 files changed, 8 insertions(+), 71 deletions(-)
>
> diff --git a/
nd
> retrieving the allocated interrupt numbers based on the offset of the
> dummy interrupt in the simulator struct.
>
> Signed-off-by: Bartosz Golaszewski <b...@bgdev.pl>
Looks good to me.
Reviewed-by: Jonathan Cameron <jonathan.came...@huawei.com>
Only tiny thing is the l
On Wed, 19 Jul 2017 14:20:12 +0200
Bartosz Golaszewski wrote:
> Implement a simple, irq_work-based framework for simulating
> interrupts. Currently the API exposes routines for initializing and
> deinitializing the simulator object, enqueueing the interrupts and
> retrieving the
On Thu, 20 Jul 2017 21:03:19 +0800
Zhangshaokun <zhangshao...@hisilicon.com> wrote:
> Hi Jonathan
>
> On 2017/7/19 17:19, Jonathan Cameron wrote:
> > On Tue, 18 Jul 2017 15:59:55 +0800
> > Shaokun Zhang <zhangshao...@hisilicon.com> wrote:
> >
> >&
On Tue, 18 Jul 2017 15:59:56 +0800
Shaokun Zhang wrote:
> This patch adds support for L3C PMU driver in HiSilicon SoC chip, Each
> L3C has own control, counter and interrupt registers and is an separate
> PMU. For each L3C PMU, it has 8-programable counters and
On Tue, 18 Jul 2017 15:59:55 +0800
Shaokun Zhang wrote:
> This patch adds support HiSilicon SoC uncore PMU driver framework and
> interfaces.
>
> Signed-off-by: Shaokun Zhang
> Signed-off-by: Anurup M
A couple of
On Tue, 18 Jul 2017 15:59:54 +0800
Shaokun Zhang wrote:
> This patch adds documentation for the uncore PMUs on HiSilicon SoC.
>
> Signed-off-by: Shaokun Zhang
> Signed-off-by: Anurup M
Hi Shaokun,
Sorry for the
On 3 March 2017 16:52:47 GMT+00:00, Wolfram Sang wrote:
>
>> 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
On 27/01/17 22:09, Peter Rosin wrote:
> On 2017-01-27 20:50, Rob Herring wrote:
>> On Wed, Jan 18, 2017 at 04:57:12PM +0100, Peter Rosin wrote:
>>> Analog Devices ADG792A/G is a triple 4:1 mux.
>>>
>>> Acked-by: Jonathan Cameron <ji...@kernel.org>
>&
On 18/01/17 15:57, Peter Rosin wrote:
> Allow bindings for a GPIO controlled mux to be specified in the
> mux consumer node.
>
> Signed-off-by: Peter Rosin
Code is good as far as I am concerned. Only question is whether this
is worth the hassle given the normal bindings don't
On 08/01/17 21:56, Peter Rosin wrote:
> On 2017-01-08 11:28, Jonathan Cameron wrote:
>> On 05/01/17 16:21, Peter Rosin wrote:
>>> On 2017-01-04 13:16, Peter Rosin wrote:
>>>> Signed-off-by: Peter Rosin <p...@axentia.se>
>&g
On 04/01/17 12:16, Peter Rosin wrote:
> Analog Devices ADG792A/G is a triple 4:1 mux.
>
> Signed-off-by: Peter Rosin <p...@axentia.se>
Reviewed-by: Jonathan Cameron <ji...@kernel.org>
A nice little driver. Hopefully this example will do the job of
convincing people a
On 04/01/17 12:16, Peter Rosin wrote:
> Analog Devices ADG792A/G is a triple 4:1 mux.
>
> Signed-off-by: Peter Rosin <p...@axentia.se>
I think this is about as neat as we can make it.
Acked-by: Jonathan Cameron <ji...@kernel.org>
> ---
> .../devicetree/bindings/mux/
On 04/01/17 12:16, Peter Rosin wrote:
> Signed-off-by: Peter Rosin <p...@axentia.se>
Acked-by: Jonathan Cameron <ji...@kernel.org>
> ---
> .../bindings/iio/multiplexer/io-channel-mux.txt| 39
> ++
> MAINTAINERS
le (independent) mux controllers.
>
> Signed-off-by: Peter Rosin <p...@axentia.se>
Reviewed-by: Jonathan Cameron <ji...@kernel.org>
> ---
> Documentation/driver-model/devres.txt | 8 +
> MAINTAINERS | 2 +
> drivers/Kconfig
On 04/01/17 12:16, Peter Rosin wrote:
> Signed-off-by: Peter Rosin <p...@axentia.se>
Looks neat and tidy to me.
Acked-by: Jonathan Cameron <ji...@kernel.org>
> ---
> .../devicetree/bindings/mux/mux-controller.txt | 26
> ++
> 1 file changed,
On 04/01/17 12:16, Peter Rosin wrote:
> Signed-off-by: Peter Rosin <p...@axentia.se>
Looks good to me.
Acked-by: Jonathan Cameron <ji...@kernel.org>
> ---
> .../devicetree/bindings/i2c/i2c-mux-simple.txt | 81
> ++
> 1 file changed, 81 insertio
On 04/01/17 12:16, Peter Rosin wrote:
> Signed-off-by: Peter Rosin <p...@axentia.se>
Acked-by: Jonathan Cameron <ji...@kernel.org>
> ---
> Documentation/driver-model/devres.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentatio
On 02/01/17 11:00, Peter Rosin wrote:
> On 2017-01-01 12:24, Jonathan Cameron wrote:
>> On 30/11/16 08:17, Peter Rosin wrote:
>>> Analog Devices ADG792A/G is a triple 4:1 mux.
>>>
>>> Signed-off-by: Peter Rosin <p...@axentia.se>
>>
On 02/01/17 16:01, Peter Rosin wrote:
> On 2017-01-01 12:00, Jonathan Cameron wrote:
>> On 30/11/16 08:17, Peter Rosin wrote:
>>> Analog Devices ADG792A/G is a triple 4:1 mux.
>>>
>>> Signed-off-by: Peter Rosin <p...@axentia.se>
>> Few comments inlin
On 2 January 2017 09:26:03 GMT+00:00, Jani Nikula <jani.nik...@linux.intel.com>
wrote:
>On Sun, 01 Jan 2017, Jonathan Cameron <ji...@kernel.org> wrote:
>> Hi All,
>>
>> I have very little idea how the internals of the kernel-doc
>processing
>>
On 2 January 2017 09:14:34 GMT+00:00, Peter Rosin <p...@axentia.se> wrote:
>On 2016-12-31 17:19, Jonathan Cameron wrote:
>> On 30/11/16 08:16, Peter Rosin wrote:
>>> Add a new minimalistic subsystem that handles multiplexer
>controllers.
>>> When mul
Hi All,
I have very little idea how the internals of the kernel-doc processing
code work, but was wondering if it would be possible to suppress warnings
of the type:
./include/linux/iio/buffer.h:142: warning: Excess struct/union/enum/typedef
member 'ref' description in 'iio_buffer'
when the
On 30/11/16 08:17, Peter Rosin wrote:
> Analog Devices ADG792A/G is a triple 4:1 mux.
>
> Signed-off-by: Peter Rosin
Looks pretty good. Some minor suggestions inline.
This convinced me of two things:
1. Need a separate subsystem directory for muxes - having them under misc
is
On 30/11/16 08:17, Peter Rosin wrote:
> Analog Devices ADG792A/G is a triple 4:1 mux.
>
> Signed-off-by: Peter Rosin
Few comments inline. Worth adding anything about the gpio (output pins) to
the binding at this stage as well? Would certainly be nice to support
them.
Jonathan
ff-by: Peter Rosin <p...@axentia.se>
Looks good to me though as I haven't really commented on it I'll give
an Ack rather than a reviewed by.
Acked-by: Jonathan Cameron <ji...@kernel.org>
> ---
> drivers/i2c/muxes/Kconfig | 13 +++
> drivers/i2c/muxes/Makefile
tem.
>
> Cache any ext_info values from the parent iio channel, creating a private
> copy of the ext_info attributes for each multiplexer state/channel.
>
> Signed-off-by: Peter Rosin <p...@axentia.se>
Other than binding naming, I'm happy with this - so pending that changing..
On 30/11/16 08:16, Peter Rosin wrote:
> Add a new minimalistic subsystem that handles multiplexer controllers.
> When multiplexers are used in various places in the kernel, and the
> same multiplexer controller can be used for several independent things,
> there should be one place to implement
exibility and complexity. Which probably means we'll
have an application it doesn't stretch to before the day is out...
Acked-by: Jonathan Cameron <ji...@kernel.org>
> ---
> .../devicetree/bindings/misc/mux-controller.txt| 127
> +
> .../devicetree
On 12/12/16 12:18, Peter Rosin wrote:
> On 2016-12-10 19:21, Jonathan Cameron wrote:
>> On 06/12/16 09:18, Peter Rosin wrote:
>>> On 2016-12-06 00:26, Rob Herring wrote:
>>>> On Wed, Nov 30, 2016 at 09:16:58AM +0100, Peter Rosin wrote:
>>>>>
On 30/11/16 08:16, Peter Rosin wrote:
> Extend the inkern api with functions for reading and writing ext_info
> of iio channels.
>
> Signed-off-by: Peter Rosin <p...@axentia.se>
Acked-by: Jonathan Cameron <ji...@kernel.org>
It may make more sense to take this particular
This is a manual conversion of the existing DocBook documentation
for IIO. The intent is not to substantially change any of the
content in this patch, but to give a base to build upon.
Signed-off-by: Jonathan Cameron <ji...@kernel.org>
---
Documentation/driver-api/iio/buffe
there's a typo at Description
>
> - at sysfs-class-cxl, it is using the ":" character at a
> file preamble, causing it to be misinterpreted as a
> tag.
>
> - On the other files, instead of "What", they use "Where".
>
> Signed
On 01/06/16 13:34, Laxman Dewangan wrote:
> The INA3221 is a three-channel, high-side current and bus voltage monitor
> with an I2C interface from Texas Instruments. The INA3221 monitors both
> shunt voltage drops and bus supply voltages in addition to having
> programmable conversion times and
On 03/06/16 11:06, Jonathan Cameron wrote:
> On 01/06/16 13:34, Laxman Dewangan wrote:
>> The INA3221 is a three-channel, high-side current and bus voltage monitor
>> with an I2C interface from Texas Instruments. The INA3221 monitors both
>> shunt voltage drops and bus supply
On 01/06/16 13:34, Laxman Dewangan wrote:
> The INA3221 is a three-channel, high-side current and bus voltage monitor
> with an I2C interface from Texas Instruments. The INA3221 monitors both
> shunt voltage drops and bus supply voltages in addition to having
> programmable conversion times and
On 06/04/16 11:31, Laxman Dewangan wrote:
> Some of kernel driver uses the IIO framework to get the sensor
> value via ADC or IIO HW driver. The client driver get iio channel
> by iio_channel_get_all() and release it by calling
> iio_channel_release_all().
>
> Add resource managed version
On 06/04/16 11:31, Laxman Dewangan wrote:
> Some of kernel driver uses the IIO framework to get the sensor
> value via ADC or IIO HW driver. The client driver get iio channel
> by iio_channel_get() and release it by calling iio_channel_release().
>
> Add resource managed version (devm_*) of these
On 03/04/16 12:51, Peter Rosin wrote:
> On 2016-04-03 12:51, Jonathan Cameron wrote:
>> On 03/04/16 09:52, Peter Rosin wrote:
>>> From: Peter Rosin <p...@axentia.se>
>>>
>>> Allocate an explicit i2c mux core to handle parent and child adapters
>>>
On 06/04/16 11:31, Laxman Dewangan wrote:
> Some of kernel driver uses the IIO framework to get the sensor
> value via ADC or IIO HW driver. The client driver get iio channel
> by iio_channel_get() and release it by calling iio_channel_release().
>
> Add resource managed version (devm_*) of these
On 06/04/16 15:58, Laxman Dewangan wrote:
> Hi Daniel,
>
>
> On Wednesday 06 April 2016 07:19 PM, Daniel Baluta wrote:
>> On Wed, Apr 6, 2016 at 1:31 PM, Laxman Dewangan wrote:
>>> Some of kernel driver uses the IIO framework to get the sensor
>>> value via ADC or IIO HW
t looks to be a fairly mechanical change so
if no one is currently setup to test it, then don't let it hold up the
series too long!
Acked-by: Jonathan Cameron <ji...@kernel.org>
Jonathan
> ---
> drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c | 2 +-
> drivers/iio/imu/inv_mpu6050/inv_
54 matches
Mail list logo