Re: [PATCH v6 03/24] iio: make use of devm_iio_kfifo_buffer_setup() helper

[Matt Ranostay]

On Tue, Feb 16, 2021 at 3:46 PM Gwendal Grignou  wrote:
>
> Reviewed-by: Gwendal Grignou 

Looks fine to me as well.

Reviewed-by: Matt Ranostay 

>
> On Mon, Feb 15, 2021 at 4:11 AM Jonathan Cameron  wrote:
> >
> > On Mon, 15 Feb 2021 12:40:22 +0200
> > Alexandru Ardelean  wrote:
> >
> > > All drivers that already call devm_iio_kfifo_allocate() &
> > > iio_device_attach_buffer() are simple to convert to
> > > iio_device_attach_kfifo_buffer() in a single go.
> > >
> > > This change does that; the unwind order is preserved.
> > > What is important, is that the devm_iio_kfifo_buffer_setup() be called
> > > after the indio_dev->modes is assigned, to make sure that
> > > INDIO_BUFFER_SOFTWARE flag is set and not overridden by the assignment to
> > > indio_dev->modes.
> > >
> > > Also, the INDIO_BUFFER_SOFTWARE has been removed from the assignments of
> > > 'indio_dev->modes' because it is set by devm_iio_kfifo_buffer_setup().
> > >
> > > Signed-off-by: Alexandru Ardelean 
> > I 'think' this one is is in the obviously correct category so I've
> > applied it to the togreg branch of iio.git and pushed out as testing.
> > Note there is still plenty of time for any additional feedback,
> > particularly as the CC list was a little sparse.
> >
> > I've +CCd those who I know are still active maintainers of some
> > of the affected drivers.
> >
> > Jonathan
> >
> > > ---
> > >  drivers/iio/accel/ssp_accel_sensor.c  | 14 ---
> > >  drivers/iio/adc/ina2xx-adc.c  | 14 +--
> > >  drivers/iio/adc/ti_am335x_adc.c   | 18 ---
> > >  .../cros_ec_sensors/cros_ec_sensors_core.c| 13 ---
> > >  drivers/iio/gyro/ssp_gyro_sensor.c| 14 ---
> > >  drivers/iio/health/max30100.c | 16 ++---
> > >  drivers/iio/health/max30102.c | 16 ++---
> > >  .../iio/imu/inv_icm42600/inv_icm42600_accel.c | 14 +--
> > >  .../iio/imu/inv_icm42600/inv_icm42600_gyro.c  | 13 +--
> > >  .../iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c| 15 +---
> > >  drivers/iio/light/acpi-als.c  | 12 --
> > >  drivers/iio/light/apds9960.c  | 16 ++---
> > >  .../staging/iio/impedance-analyzer/ad5933.c   | 23 ---
> > >  13 files changed, 74 insertions(+), 124 deletions(-)
> > >
> > > diff --git a/drivers/iio/accel/ssp_accel_sensor.c 
> > > b/drivers/iio/accel/ssp_accel_sensor.c
> > > index 474477e91b5e..04dcb2b657ee 100644
> > > --- a/drivers/iio/accel/ssp_accel_sensor.c
> > > +++ b/drivers/iio/accel/ssp_accel_sensor.c
> > > @@ -96,7 +96,6 @@ static int ssp_accel_probe(struct platform_device *pdev)
> > >   int ret;
> > >   struct iio_dev *indio_dev;
> > >   struct ssp_sensor_data *spd;
> > > - struct iio_buffer *buffer;
> > >
> > >   indio_dev = devm_iio_device_alloc(>dev, sizeof(*spd));
> > >   if (!indio_dev)
> > > @@ -109,18 +108,15 @@ static int ssp_accel_probe(struct platform_device 
> > > *pdev)
> > >
> > >   indio_dev->name = ssp_accel_device_name;
> > >   indio_dev->info = _accel_iio_info;
> > > - indio_dev->modes = INDIO_BUFFER_SOFTWARE;
> > >   indio_dev->channels = ssp_acc_channels;
> > >   indio_dev->num_channels = ARRAY_SIZE(ssp_acc_channels);
> > >   indio_dev->available_scan_masks = ssp_accel_scan_mask;
> > >
> > > - buffer = devm_iio_kfifo_allocate(>dev);
> > > - if (!buffer)
> > > - return -ENOMEM;
> > > -
> > > - iio_device_attach_buffer(indio_dev, buffer);
> > > -
> > > - indio_dev->setup_ops = _accel_buffer_ops;
> > > + ret = devm_iio_kfifo_buffer_setup(>dev, indio_dev,
> > > +   INDIO_BUFFER_SOFTWARE,
> > > +   _accel_buffer_ops);
> > > + if (ret)
> > > + return ret;
> > >
> > >   platform_set_drvdata(pdev, indio_dev);
> > >
> > > diff --git a/drivers/iio/adc/ina2xx-adc.c b/drivers/iio/adc/ina2xx-adc.c
> > > index b573ec60a8b8..2ae54258b221 100644
> > > --- a/drivers/iio/adc/ina2xx-adc.c
> > > +++ b/drivers/iio/adc/ina2xx-adc.c
> > > @@ -953,7 +953,6 @@ static int ina2xx_pr

Re: [PATCH] iio:light:apds9960 add detection for MSHW0184 ACPI device in apds9960 driver

[Matt Ranostay]

On Sat, Dec 19, 2020 at 5:51 PM Max Leiter  wrote:
>
> The device is used in the Microsoft Surface Book 3 and Surface Pro 7
>
> Signed-off-by: Max Leiter 

Reviewed-by: Matt Ranostay 

> ---
>  drivers/iio/light/apds9960.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/iio/light/apds9960.c b/drivers/iio/light/apds9960.c
> index 9afb3fcc74e6..20719141c03a 100644
> --- a/drivers/iio/light/apds9960.c
> +++ b/drivers/iio/light/apds9960.c
> @@ -8,6 +8,7 @@
>   * TODO: gesture + proximity calib offsets
>   */
>
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1113,6 +1114,12 @@ static const struct i2c_device_id apds9960_id[] = {
>  };
>  MODULE_DEVICE_TABLE(i2c, apds9960_id);
>
> +static const struct acpi_device_id apds9960_acpi_match[] = {
> +   { "MSHW0184" },
> +   { }
> +};
> +MODULE_DEVICE_TABLE(acpi, apds9960_acpi_match);
> +
>  static const struct of_device_id apds9960_of_match[] = {
> { .compatible = "avago,apds9960" },
> { }
> @@ -1124,6 +1131,7 @@ static struct i2c_driver apds9960_driver = {
> .name   = APDS9960_DRV_NAME,
> .of_match_table = apds9960_of_match,
> .pm = _pm_ops,
> +   .acpi_match_table = apds9960_acpi_match,
> },
> .probe  = apds9960_probe,
> .remove = apds9960_remove,
> --
> 2.29.2
>

Re: [PATCH] iio: light: apds9960: remove unneeded semicolon

[Matt Ranostay]

On Tue, Oct 27, 2020 at 1:14 PM  wrote:
>
> From: Tom Rix 
>
> A semicolon is not needed after a switch statement.
>

Acked-by: Matt Ranostay 

> Signed-off-by: Tom Rix 
> ---
>  drivers/iio/light/apds9960.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iio/light/apds9960.c b/drivers/iio/light/apds9960.c
> index 9afb3fcc74e6..547e7f9d6920 100644
> --- a/drivers/iio/light/apds9960.c
> +++ b/drivers/iio/light/apds9960.c
> @@ -561,7 +561,7 @@ static int apds9960_write_raw(struct iio_dev *indio_dev,
> }
> default:
> return -EINVAL;
> -   };
> +   }
>
> return 0;
>  }
> --
> 2.18.1
>

Re: [PATCH] iio: proximity: as3935 change of_property_read to device_property_read

[Matt Ranostay]

On Fri, Oct 16, 2020 at 11:41 AM Vaishnav M A  wrote:
>
>
> This patch aims to replace the of_property_read_u32 for reading
> the ams,tuning-capacitor-pf, ams,nflwdth properties with
> device_property_read_u32.
>
> Thanks and Regards,
> Vaishnav M A

Could you explain a bit more in the commit message why this is needed?

Also you pop comments that shouldn't be in the commit message below
the "---" line :)

>
> Signed-off-by: Vaishnav M A 
> ---
>  drivers/iio/proximity/as3935.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/proximity/as3935.c b/drivers/iio/proximity/as3935.c
> index c339e7339ec8..7e47ddf89a56 100644
> --- a/drivers/iio/proximity/as3935.c
> +++ b/drivers/iio/proximity/as3935.c
> @@ -355,7 +355,6 @@ static int as3935_probe(struct spi_device *spi)
> struct iio_dev *indio_dev;
> struct iio_trigger *trig;
> struct as3935_state *st;
> -   struct device_node *np = spi->dev.of_node;
> int ret;
>
> /* Be sure lightning event interrupt is specified */
> @@ -374,7 +373,7 @@ static int as3935_probe(struct spi_device *spi)
> spi_set_drvdata(spi, indio_dev);
> mutex_init(>lock);
>
> -   ret = of_property_read_u32(np,
> +   ret = device_property_read_u32(>dev,
> "ams,tuning-capacitor-pf", >tune_cap);
> if (ret) {
> st->tune_cap = 0;
> @@ -390,7 +389,7 @@ static int as3935_probe(struct spi_device *spi)
> return -EINVAL;
> }
>
> -   ret = of_property_read_u32(np,
> +   ret = device_property_read_u32(>dev,
> "ams,nflwdth", >nflwdth_reg);
> if (!ret && st->nflwdth_reg > AS3935_NFLWDTH_MASK) {
> dev_err(>dev,
> --
> 2.25.1
>

Re: [PATCH 5.4 047/215] iio:humidity:hdc100x Fix alignment and data leak issues

[Matt Ranostay]

On Mon, Jul 20, 2020 at 9:50 AM Joe Perches  wrote:
>
> On Mon, 2020-07-20 at 17:35 +0200, Greg Kroah-Hartman wrote:
> > From: Jonathan Cameron 
> >
> > commit ea5e7a7bb6205d24371373cd80325db1bc15eded upstream.
> >
> > One of a class of bugs pointed out by Lars in a recent review.
> > iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
> > to the size of the timestamp (8 bytes).  This is not guaranteed in
> > this driver which uses an array of smaller elements on the stack.
> > As Lars also noted this anti pattern can involve a leak of data to
> > userspace and that indeed can happen here.  We close both issues by
> > moving to a suitable structure in the iio_priv() data.
> > This data is allocated with kzalloc so no data can leak apart
> > from previous readings.
> []
> > +++ b/drivers/iio/humidity/hdc100x.c
> > @@ -38,6 +38,11 @@ struct hdc100x_data {
> >
> >   /* integration time of the sensor */
> >   int adc_int_us[2];
> > + /* Ensure natural alignment of timestamp */
> > + struct {
> > + __be16 channels[2];
> > + s64 ts __aligned(8);
>
> Why does an s64 need __aligned(8) ?

This is due to on 32-bit x86 it is aligned to 4 bytes by default.

- Matt

> This seems needlessly redundant.
>
> Isn't this naturally aligned by the compiler?
>
> The struct isn't packed.
>

Re: [PATCH v2] Replace HTTP links with HTTPS ones: Documentation/devicetree/bindings/iio

[Matt Ranostay]

On Sat, Jul 4, 2020 at 12:34 PM Alexander A. Klimov
 wrote:
>
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>

With regards to the drivers that I've authored the changes look good to me.

Reviewed-by: Matt Ranostay 


> Deterministic algorithm:
> For each file:
>   If not .svg:
> For each line:
>   If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
>   If both the HTTP and HTTPS versions
>   return 200 OK and serve the same content:
> Replace HTTP with HTTPS.
>
> Signed-off-by: Alexander A. Klimov 
> ---
>  Changes in v2:
>  Addressed 
> https://lore.kernel.org/linux-iio/20200704173459.78ceec60@archlinux/
>
>  Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml  | 4 ++--
>  Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt  | 2 +-
>  Documentation/devicetree/bindings/iio/iio-bindings.txt| 2 +-
>  Documentation/devicetree/bindings/iio/light/apds9300.txt  | 2 +-
>  Documentation/devicetree/bindings/iio/light/apds9960.txt  | 2 +-
>  Documentation/devicetree/bindings/iio/light/opt3001.txt   | 2 +-
>  Documentation/devicetree/bindings/iio/light/vl6180.txt| 2 +-
>  .../devicetree/bindings/iio/potentiometer/mcp41010.txt| 2 +-
>  .../devicetree/bindings/iio/potentiostat/lmp91000.txt | 4 ++--
>  .../devicetree/bindings/iio/pressure/asc,dlhl60d.yaml | 2 +-
>  .../devicetree/bindings/iio/proximity/devantech-srf04.yaml| 4 ++--
>  11 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml 
> b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml
> index d124eba1ce54..fd4eaa3d0ab4 100644
> --- a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml
> +++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml
> @@ -12,8 +12,8 @@ maintainers:
>  description: |
>Analog Devices ADXL345/ADXL375 3-Axis Digital Accelerometers that supports
>both I2C & SPI interfaces.
> -http://www.analog.com/en/products/mems/accelerometers/adxl345.html
> -
> http://www.analog.com/en/products/sensors-mems/accelerometers/adxl375.html
> +https://www.analog.com/en/products/mems/accelerometers/adxl345.html
> +
> https://www.analog.com/en/products/sensors-mems/accelerometers/adxl375.html
>
>  properties:
>compatible:
> diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt 
> b/Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt
> index 639c94ed83e9..17af395b99d9 100644
> --- a/Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt
> +++ b/Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt
> @@ -6,7 +6,7 @@ Is is programmable through an SPI interface.
>
>  The internal DACs are loaded when the LOADDACS pin is pulled down.
>
> -http://www.ti.com/lit/ds/sbas106/sbas106.pdf
> +https://www.ti.com/lit/ds/sbas106/sbas106.pdf
>
>  Required Properties:
>  - compatible: Should be one of:
> diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt 
> b/Documentation/devicetree/bindings/iio/iio-bindings.txt
> index af33267727f4..aa63cac7323e 100644
> --- a/Documentation/devicetree/bindings/iio/iio-bindings.txt
> +++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt
> @@ -9,7 +9,7 @@ specifier is an array of one or more cells identifying the IIO
>  output on a device. The length of an IIO specifier is defined by the
>  value of a #io-channel-cells property in the IIO provider node.
>
> -[1] http://marc.info/?l=linux-iio=135902119507483=2
> +[1] https://marc.info/?l=linux-iio=135902119507483=2
>
>  ==IIO providers==
>
> diff --git a/Documentation/devicetree/bindings/iio/light/apds9300.txt 
> b/Documentation/devicetree/bindings/iio/light/apds9300.txt
> index aa199e09a493..3aa6db3ee99d 100644
> --- a/Documentation/devicetree/bindings/iio/light/apds9300.txt
> +++ b/Documentation/devicetree/bindings/iio/light/apds9300.txt
> @@ -1,6 +1,6 @@
>  * Avago APDS9300 ambient light sensor
>
> -http://www.avagotech.com/docs/AV02-1077EN
> +https://www.avagotech.com/docs/AV02-1077EN
>
>  Required properties:
>
> diff --git a/Documentation/devicetree/bindings/iio/light/apds9960.txt 
> b/Documentation/devicetree/bindings/iio/light/apds9960.txt
> index 3af325ad194b..c53ddb81c4aa 100644
> --- a/Documentation/devicetree/bindings/iio/light/apds9960.txt
> +++ b/Documentation/devicetree/bindings/iio/light/apds9960.txt
> @@ -1,6 +1,6 @@
>  * Avago APDS9960 gesture/RGB/ALS/proximity sensor
>
> -http://www.avagotech.com/docs/AV02-4191EN
> +https://www.avagotech.com/docs/AV02-4191EN
>

Re: [PATCH] iio: improve IIO_CONCENTRATION channel type description

[Matt Ranostay]

On Mon, Jun 1, 2020 at 9:18 AM Tomasz Duszynski
 wrote:
>
> IIO_CONCENTRATION together with INFO_RAW specifier is used for reporting
> raw concentrations of pollutants. Raw value should be meaningless
> before being properly scaled. Because of that description shouldn't
> mention raw value unit whatsoever.
>
> Fix this by rephrasing existing description so it follows conventions
> used throughout IIO ABI docs.

Acked-by: Matt Ranostay 

>
> Fixes: 8ff6b3bc94930 ("iio: chemical: Add IIO_CONCENTRATION channel type")
> Signed-off-by: Tomasz Duszynski 
> ---
>  Documentation/ABI/testing/sysfs-bus-iio | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
> b/Documentation/ABI/testing/sysfs-bus-iio
> index d3e53a6d8331..5c62bfb0f3f5 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -1569,7 +1569,8 @@ What: 
> /sys/bus/iio/devices/iio:deviceX/in_concentrationX_voc_raw
>  KernelVersion: 4.3
>  Contact:   linux-...@vger.kernel.org
>  Description:
> -   Raw (unscaled no offset etc.) percentage reading of a 
> substance.
> +   Raw (unscaled no offset etc.) reading of a substance. Units
> +   after application of scale and offset are percents.
>
>  What:  /sys/bus/iio/devices/iio:deviceX/in_resistance_raw
>  What:  /sys/bus/iio/devices/iio:deviceX/in_resistanceX_raw
> --
> 2.26.2
>

Re: [PATCH v2 2/3] iio: dps310: Temperature measurement errata

[Matt Ranostay]

On Thu, May 9, 2019 at 11:17 PM Eddie James  wrote:
>
>
> On 5/8/19 10:09 PM, Matt Ranostay wrote:
> > On Thu, May 9, 2019 at 3:36 AM Eddie James  wrote:
> >> From: Christopher Bostic 
> >>
> >> Add a manufacturer's suggested workaround to deal with early revisions
> >> of chip that don't indicate correct temperature. Readings can be in the
> >> ~60C range when they should be in the ~20's.
> >>
> >> Signed-off-by: Christopher Bostic 
> >> Signed-off-by: Joel Stanley 
> >> Signed-off-by: Eddie James 
> >> ---
> >>   drivers/iio/pressure/dps310.c | 51 
> >> ++-
> >>   1 file changed, 50 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/iio/pressure/dps310.c b/drivers/iio/pressure/dps310.c
> >> index 7afaa88..c42808e 100644
> >> --- a/drivers/iio/pressure/dps310.c
> >> +++ b/drivers/iio/pressure/dps310.c
> >> @@ -221,6 +221,9 @@ static bool dps310_is_writeable_reg(struct device 
> >> *dev, unsigned int reg)
> >>  case DPS310_MEAS_CFG:
> >>  case DPS310_CFG_REG:
> >>  case DPS310_RESET:
> >> +   case 0x0e:
> >> +   case 0x0f:
> >> +   case 0x62:
> > What is with the magic values? Are they not documented to what they
> > are, and hence not defining enum values for them?
> >
> > - Matt
>
>
> Thats correct. These don't show up in the data sheet so I left them as
> raw values. Chris, do you know what the source for these values was?

Please at least make a comment in the code stating as much.

- Matt
>
> Thanks,
>
> Eddie
>
>
> >
> >>  return true;
> >>  default:
> >>  return false;
> >> @@ -237,6 +240,7 @@ static bool dps310_is_volatile_reg(struct device *dev, 
> >> unsigned int reg)
> >>  case DPS310_TMP_B1:
> >>  case DPS310_TMP_B2:
> >>  case DPS310_MEAS_CFG:
> >> +   case 0x32:
> >>  return true;
> >>  default:
> >>  return false;
> >> @@ -314,7 +318,7 @@ static int dps310_read_raw(struct iio_dev *iio,
> >>  .writeable_reg = dps310_is_writeable_reg,
> >>  .volatile_reg = dps310_is_volatile_reg,
> >>  .cache_type = REGCACHE_RBTREE,
> >> -   .max_register = 0x29,
> >> +   .max_register = 0x62,
> >>   };
> >>
> >>   static const struct iio_info dps310_info = {
> >> @@ -322,6 +326,47 @@ static int dps310_read_raw(struct iio_dev *iio,
> >>  .write_raw = dps310_write_raw,
> >>   };
> >>
> >> +/*
> >> + * Some verions of chip will read temperatures in the ~60C range when
> >> + * its actually ~20C. This is the manufacturer recommended workaround
> >> + * to correct the issue.
> >> + */
> >> +static int dps310_temp_workaround(struct dps310_data *data)
> >> +{
> >> +   int r, reg;
> >> +
> >> +   r = regmap_read(data->regmap, 0x32, );
> >> +   if (r < 0)
> >> +   return r;
> >> +
> >> +   /*
> >> +* If bit 1 is set then the device is okay, and the workaround 
> >> does not
> >> +* need to be applied
> >> +*/
> >> +   if (reg & BIT(1))
> >> +   return 0;
> >> +
> >> +   r = regmap_write(data->regmap, 0x0e, 0xA5);
> >> +   if (r < 0)
> >> +   return r;
> >> +
> >> +   r = regmap_write(data->regmap, 0x0f, 0x96);
> >> +   if (r < 0)
> >> +   return r;
> >> +
> >> +   r = regmap_write(data->regmap, 0x62, 0x02);
> >> +   if (r < 0)
> >> +   return r;
> >> +
> >> +   r = regmap_write(data->regmap, 0x0e, 0x00);
> >> +   if (r < 0)
> >> +   return r;
> >> +
> >> +   r = regmap_write(data->regmap, 0x0f, 0x00);
> >> +
> >> +   return r;
> >> +}
> >> +
> >>   static int dps310_probe(struct i2c_client *client,
> >>  const struct i2c_device_id *id)
> >>   {
> >> @@ -383,6 +428,10 @@ static int dps310_probe(struct i2c_client *client,
> >>  if (r < 0)
> >>  goto err;
> >>
> >> +   r = dps310_temp_workaround(data);
> >> +   if (r < 0)
> >> +   return r;
> >> +
> >>  r = devm_iio_device_register(>dev, iio);
> >>  if (r)
> >>  goto err;
> >> --
> >> 1.8.3.1
> >>
>

Re: [PATCH v2 2/3] iio: dps310: Temperature measurement errata

[Matt Ranostay]

On Thu, May 9, 2019 at 3:36 AM Eddie James  wrote:
>
> From: Christopher Bostic 
>
> Add a manufacturer's suggested workaround to deal with early revisions
> of chip that don't indicate correct temperature. Readings can be in the
> ~60C range when they should be in the ~20's.
>
> Signed-off-by: Christopher Bostic 
> Signed-off-by: Joel Stanley 
> Signed-off-by: Eddie James 
> ---
>  drivers/iio/pressure/dps310.c | 51 
> ++-
>  1 file changed, 50 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/pressure/dps310.c b/drivers/iio/pressure/dps310.c
> index 7afaa88..c42808e 100644
> --- a/drivers/iio/pressure/dps310.c
> +++ b/drivers/iio/pressure/dps310.c
> @@ -221,6 +221,9 @@ static bool dps310_is_writeable_reg(struct device *dev, 
> unsigned int reg)
> case DPS310_MEAS_CFG:
> case DPS310_CFG_REG:
> case DPS310_RESET:
> +   case 0x0e:
> +   case 0x0f:
> +   case 0x62:

What is with the magic values? Are they not documented to what they
are, and hence not defining enum values for them?

- Matt

> return true;
> default:
> return false;
> @@ -237,6 +240,7 @@ static bool dps310_is_volatile_reg(struct device *dev, 
> unsigned int reg)
> case DPS310_TMP_B1:
> case DPS310_TMP_B2:
> case DPS310_MEAS_CFG:
> +   case 0x32:
> return true;
> default:
> return false;
> @@ -314,7 +318,7 @@ static int dps310_read_raw(struct iio_dev *iio,
> .writeable_reg = dps310_is_writeable_reg,
> .volatile_reg = dps310_is_volatile_reg,
> .cache_type = REGCACHE_RBTREE,
> -   .max_register = 0x29,
> +   .max_register = 0x62,
>  };
>
>  static const struct iio_info dps310_info = {
> @@ -322,6 +326,47 @@ static int dps310_read_raw(struct iio_dev *iio,
> .write_raw = dps310_write_raw,
>  };
>
> +/*
> + * Some verions of chip will read temperatures in the ~60C range when
> + * its actually ~20C. This is the manufacturer recommended workaround
> + * to correct the issue.
> + */
> +static int dps310_temp_workaround(struct dps310_data *data)
> +{
> +   int r, reg;
> +
> +   r = regmap_read(data->regmap, 0x32, );
> +   if (r < 0)
> +   return r;
> +
> +   /*
> +* If bit 1 is set then the device is okay, and the workaround does 
> not
> +* need to be applied
> +*/
> +   if (reg & BIT(1))
> +   return 0;
> +
> +   r = regmap_write(data->regmap, 0x0e, 0xA5);
> +   if (r < 0)
> +   return r;
> +
> +   r = regmap_write(data->regmap, 0x0f, 0x96);
> +   if (r < 0)
> +   return r;
> +
> +   r = regmap_write(data->regmap, 0x62, 0x02);
> +   if (r < 0)
> +   return r;
> +
> +   r = regmap_write(data->regmap, 0x0e, 0x00);
> +   if (r < 0)
> +   return r;
> +
> +   r = regmap_write(data->regmap, 0x0f, 0x00);
> +
> +   return r;
> +}
> +
>  static int dps310_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
>  {
> @@ -383,6 +428,10 @@ static int dps310_probe(struct i2c_client *client,
> if (r < 0)
> goto err;
>
> +   r = dps310_temp_workaround(data);
> +   if (r < 0)
> +   return r;
> +
> r = devm_iio_device_register(>dev, iio);
> if (r)
> goto err;
> --
> 1.8.3.1
>

Re: [PATCH v2] iio: temperature: maxim_thermocouple: declare missing of table

[Matt Ranostay]

On Wed, Apr 24, 2019 at 5:42 AM Daniel Gomez  wrote:
>
> Add missing  table for SPI driver relying on SPI
> device match since compatible is in a DT binding or in a DTS.
>
> Before this patch:
> modinfo drivers/iio/temperature/maxim_thermocouple.ko | grep alias
> alias:  spi:max31855
> alias:  spi:max6675
>
> After this patch:
> modinfo drivers/iio/temperature/maxim_thermocouple.ko | grep alias
> alias:  spi:max31855
> alias:  spi:max6675
> alias:  of:N*T*Cmaxim,max31855C*
> alias:  of:N*T*Cmaxim,max31855
> alias:  of:N*T*Cmaxim,max6675C*
> alias:  of:N*T*Cmaxim,max6675

Heh oops I missed that somehow in initial development.

Acked-by: Matt Ranostay 

>
> Reported-by: Javier Martinez Canillas 
> Signed-off-by: Daniel Gomez 
> ---
>  drivers/iio/temperature/maxim_thermocouple.c | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/drivers/iio/temperature/maxim_thermocouple.c 
> b/drivers/iio/temperature/maxim_thermocouple.c
> index c31b963..c613a64 100644
> --- a/drivers/iio/temperature/maxim_thermocouple.c
> +++ b/drivers/iio/temperature/maxim_thermocouple.c
> @@ -10,6 +10,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -262,9 +264,17 @@ static const struct spi_device_id 
> maxim_thermocouple_id[] = {
>  };
>  MODULE_DEVICE_TABLE(spi, maxim_thermocouple_id);
>
> +static const struct of_device_id maxim_thermocouple_of_match[] = {
> +{ .compatible = "maxim,max6675" },
> +{ .compatible = "maxim,max31855" },
> +{ },
> +};
> +MODULE_DEVICE_TABLE(of, maxim_thermocouple_of_match);
> +
>  static struct spi_driver maxim_thermocouple_driver = {
> .driver = {
> .name   = MAXIM_THERMOCOUPLE_DRV_NAME,
> +   .of_match_table = maxim_thermocouple_of_match,
> },
> .probe  = maxim_thermocouple_probe,
> .remove = maxim_thermocouple_remove,
> --
> 2.7.4
>

Re: [PATCH] drivers: iio: proximity: This patch fix the following checkpatch warning.

[Matt Ranostay]

On Mon, Apr 22, 2019 at 6:48 PM Jonathan Cameron  wrote:
>
> On Thu, 18 Apr 2019 16:23:51 -0700
> Matt Ranostay  wrote:
>
> > See comments inline
> >
> > On Wed, Apr 17, 2019 at 11:15 AM Mohan Kumar  
> > wrote:
> > >
> > > As per Documentation/timers/timers-howto.txt Msleep < 20ms can sleep for
> > > up to 20ms. so use usleep_range.
> > >
> > > Signed-off-by: Mohan Kumar 
> > > ---
> > >  drivers/iio/proximity/mb1232.c | 2 +-
> > >  drivers/iio/proximity/srf08.c  | 4 ++--
> > >  2 files changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/iio/proximity/mb1232.c 
> > > b/drivers/iio/proximity/mb1232.c
> > > index 166b3e6..74f7eae 100644
> > > --- a/drivers/iio/proximity/mb1232.c
> > > +++ b/drivers/iio/proximity/mb1232.c
> > > @@ -81,7 +81,7 @@ static s16 mb1232_read_distance(struct mb1232_data 
> > > *data)
> > > }
> > > } else {
> > > /* use simple sleep if announce irq is not connected */
> > > -   msleep(15);
> > > +   usleep_range(15000, 2);
> >
> > This is actually less than ideal.. because usleep_range uses the
> > hrtimers which forces an interrupt.
> >
> > Unless you actually need to read between 15ms and 20ms it is best just
> > to leave the msleep() as it is, and let it take a bit longer
> > if required.
> Good response.  Perhaps Mohan could follow up with a patch to add
> a comment to this effect to save anyone else trying to 'fix' this
> issue in future?

Change of the warning message in the checkpatch.pl script you mean?

- Matt

>
> Thanks,
>
> Jonathan
> >
> > - Matt
> >
> > > }
> > >
> > > ret = i2c_master_recv(client, (char *), sizeof(buf));
> > > diff --git a/drivers/iio/proximity/srf08.c b/drivers/iio/proximity/srf08.c
> > > index f2bf783..605a582 100644
> > > --- a/drivers/iio/proximity/srf08.c
> > > +++ b/drivers/iio/proximity/srf08.c
> > > @@ -150,7 +150,7 @@ static int srf08_read_ranging(struct srf08_data *data)
> > >  * polling for not more than 20 ms should be enough
> > >  */
> > > waittime = 1 + data->range_mm / 172;
> > > -   msleep(waittime);
> > > +   usleep_range(waittime * 1000, (waittime * 1000) + 2000);
> > > for (i = 0; i < 4; i++) {
> > > ret = i2c_smbus_read_byte_data(data->client,
> > > SRF08_READ_SW_REVISION);
> > > @@ -158,7 +158,7 @@ static int srf08_read_ranging(struct srf08_data *data)
> > > /* check if a valid version number is read */
> > > if (ret < 255 && ret > 0)
> > > break;
> > > -   msleep(5);
> > > +   usleep_range(5000, 15000);
> > > }
> > >
> > > if (ret >= 255 || ret <= 0) {
> > > --
> > > 2.7.4
> > >
>

Re: [PATCH] drivers: iio: proximity: This patch fix the following checkpatch warning.

[Matt Ranostay]

See comments inline

On Wed, Apr 17, 2019 at 11:15 AM Mohan Kumar  wrote:
>
> As per Documentation/timers/timers-howto.txt Msleep < 20ms can sleep for
> up to 20ms. so use usleep_range.
>
> Signed-off-by: Mohan Kumar 
> ---
>  drivers/iio/proximity/mb1232.c | 2 +-
>  drivers/iio/proximity/srf08.c  | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/proximity/mb1232.c b/drivers/iio/proximity/mb1232.c
> index 166b3e6..74f7eae 100644
> --- a/drivers/iio/proximity/mb1232.c
> +++ b/drivers/iio/proximity/mb1232.c
> @@ -81,7 +81,7 @@ static s16 mb1232_read_distance(struct mb1232_data *data)
> }
> } else {
> /* use simple sleep if announce irq is not connected */
> -   msleep(15);
> +   usleep_range(15000, 2);

This is actually less than ideal.. because usleep_range uses the
hrtimers which forces an interrupt.

Unless you actually need to read between 15ms and 20ms it is best just
to leave the msleep() as it is, and let it take a bit longer
if required.

- Matt

> }
>
> ret = i2c_master_recv(client, (char *), sizeof(buf));
> diff --git a/drivers/iio/proximity/srf08.c b/drivers/iio/proximity/srf08.c
> index f2bf783..605a582 100644
> --- a/drivers/iio/proximity/srf08.c
> +++ b/drivers/iio/proximity/srf08.c
> @@ -150,7 +150,7 @@ static int srf08_read_ranging(struct srf08_data *data)
>  * polling for not more than 20 ms should be enough
>  */
> waittime = 1 + data->range_mm / 172;
> -   msleep(waittime);
> +   usleep_range(waittime * 1000, (waittime * 1000) + 2000);
> for (i = 0; i < 4; i++) {
> ret = i2c_smbus_read_byte_data(data->client,
> SRF08_READ_SW_REVISION);
> @@ -158,7 +158,7 @@ static int srf08_read_ranging(struct srf08_data *data)
> /* check if a valid version number is read */
> if (ret < 255 && ret > 0)
> break;
> -   msleep(5);
> +   usleep_range(5000, 15000);
> }
>
> if (ret >= 255 || ret <= 0) {
> --
> 2.7.4
>

Re: [PATCH 0/5] *** SUBJECT HERE ***

[Matt Ranostay]

You may want to change "*** SUBJECT HERE ***"  in the future :)

- Matt

On Sat, Mar 23, 2019 at 5:53 AM Cristian Sicilia
 wrote:
>
> Some source refactoring, parameters aligment and camel case clearing.
>
> Replacement of bool to bitfield in a struct, but not found
> the population to check if it is done correctly.
>
> Cristian Sicilia (5):
>   staging: iio: adc: Tab alignment
>   staging: iio: adc: Converted bool to bitfield format
>   staging: iio: adc: Avoid precedence issues in macro
>   staging: iio: adc: Adding temp var to improve readability
>   staging: iio: adc: Remove CamelCase notation
>
>  drivers/staging/iio/adc/ad7192.h  |  16 +++---
>  drivers/staging/iio/adc/ad7280a.c | 109 
> ++
>  2 files changed, 60 insertions(+), 65 deletions(-)
>
> --
> 2.7.4
>

Re: [PATCH] Staging: iio: ad7192: replaced bool in struct

[Matt Ranostay]

> On Dec 24, 2018, at 01:58, Himanshu Jha  wrote:
> 
>> On Fri, Dec 21, 2018 at 03:26:26PM -0800, Amir Mahdi Ghorbanian wrote:
>> Replaced bool in struct with unsigned int bitfield to conserve space and
>> more clearly define size of varibales

Important thing to note is depending on padding, alignment, and position of 
field it probably won’t save any space.

Also for internal unpacked structures it really makes little sense to save a 
few bytes of data. Don’t read into that packed structures are good.. they 
usually aren’t :)

- Matt
>> 
>> Signed-off-by: Amir Mahdi Ghorbanian 
>> ---
> 
> There was some discussion on this at Outreachy list:
> https://groups.google.com/d/msg/outreachy-kernel/xpQAl-Gn8HA/yqcQRG_qBgAJ
> 
> I think unless you post some statistics about 'conserving' space, 
> it is unlikely that maintainers will apply it.
> 
> This idea was originally given by Linus and that thread of discussion 
> is worth reading too.
> 
>> drivers/staging/iio/adc/ad7192.h | 14 +++---
>> 1 file changed, 7 insertions(+), 7 deletions(-)
>> 
>> diff --git a/drivers/staging/iio/adc/ad7192.h 
>> b/drivers/staging/iio/adc/ad7192.h
>> index 7433a43..7d3e62f 100644
>> --- a/drivers/staging/iio/adc/ad7192.h
>> +++ b/drivers/staging/iio/adc/ad7192.h
>> @@ -35,13 +35,13 @@ struct ad7192_platform_data {
>>u16vref_mv;
>>u8clock_source_sel;
>>u32ext_clk_hz;
>> -boolrefin2_en;
>> -boolrej60_en;
>> -boolsinc3_en;
>> -boolchop_en;
>> -boolbuf_en;
>> -boolunipolar_en;
>> -boolburnout_curr_en;
>> +unsigned intrefin2_en : 1;
>> +unsigned intrej60_en : 1;
>> +unsigned intsinc3_en : 1;
>> +unsigned intchop_en : 1;
>> +unsigned intbuf_en : 1;
>> +unsigned intunipolar_en : 1;
>> +unsigned intburnout_curr_en : 1;
>> };
>> 
>> #endif /* IIO_ADC_AD7192_H_ */
>> -- 
>> 2.7.4
>> 
> 
> Goodluck!
> 
> -- 
> Himanshu Jha
> Undergraduate Student
> Department of Electronics & Communication
> Guru Tegh Bahadur Institute of Technology

Re: [PATCH v3 1/3] iio: add IIO_MASSCONCENTRATION channel type

[Matt Ranostay]

On Wed, Dec 12, 2018 at 10:31 AM Tomasz Duszynski  wrote:
>
> Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
> is de facto standard. Existing air quality sensors usually follow
> this convention and are capable of returning measurements using
> this unit.
>
> IIO currently does not offer suitable channel type for this
> type of measurements hence this patch adds this.
>
> In addition, extra modifiers are introduced used for distinguishing
> between fine pm1, pm2p5 and coarse pm4, pm10 particle measurements, i.e
> IIO_MOD_PM1, IIO_MOD_PM25 and IIO_MOD_PM4, IIO_MOD_PM10.
>
> pmX consists of particles with aerodynamic diameter less or equal to
> X micrometers.
>

Acked-by: Matt Ranostay 

> Signed-off-by: Tomasz Duszynski 
> ---
>  Documentation/ABI/testing/sysfs-bus-iio | 17 -
>  drivers/iio/industrialio-core.c |  5 +
>  include/uapi/linux/iio/types.h  |  5 +
>  tools/iio/iio_event_monitor.c   | 10 ++
>  4 files changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
> b/Documentation/ABI/testing/sysfs-bus-iio
> index 8127a08e366d..ad9579a9385f 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -1684,4 +1684,19 @@ KernelVersion:   4.18
>  Contact:   linux-...@vger.kernel.org
>  Description:
> Raw (unscaled) phase difference reading from channel Y
> -   that can be processed to radians.
> \ No newline at end of file
> +   that can be processed to radians.
> +
> +What:  
> /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm1_input
> +What:  
> /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm1_input
> +What:  
> /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> +What:  
> /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> +What:  
> /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm4_input
> +What:  
> /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm4_input
> +What:  
> /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> +What:  
> /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> +KernelVersion: 4.21
> +Contact:   linux-...@vger.kernel.org
> +Description:
> +   Mass concentration reading of particulate matter in ug / m3.
> +   pmX consists of particles with aerodynamic diameter less or
> +   equal to X micrometers.
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 4f5cd9f60870..4700fd5d8c90 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] = {
> [IIO_GRAVITY]  = "gravity",
> [IIO_POSITIONRELATIVE]  = "positionrelative",
> [IIO_PHASE] = "phase",
> +   [IIO_MASSCONCENTRATION] = "massconcentration",
>  };
>
>  static const char * const iio_modifier_names[] = {
> @@ -127,6 +128,10 @@ static const char * const iio_modifier_names[] = {
> [IIO_MOD_Q] = "q",
> [IIO_MOD_CO2] = "co2",
> [IIO_MOD_VOC] = "voc",
> +   [IIO_MOD_PM1] = "pm1",
> +   [IIO_MOD_PM2P5] = "pm2p5",
> +   [IIO_MOD_PM4] = "pm4",
> +   [IIO_MOD_PM10] = "pm10",
>  };
>
>  /* relies on pairs of these shared then separate */
> diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
> index 92baabc103ac..c59adac24b1c 100644
> --- a/include/uapi/linux/iio/types.h
> +++ b/include/uapi/linux/iio/types.h
> @@ -46,6 +46,7 @@ enum iio_chan_type {
> IIO_GRAVITY,
> IIO_POSITIONRELATIVE,
> IIO_PHASE,
> +   IIO_MASSCONCENTRATION,
>  };
>
>  enum iio_modifier {
> @@ -87,6 +88,10 @@ enum iio_modifier {
> IIO_MOD_VOC,
> IIO_MOD_LIGHT_UV,
> IIO_MOD_LIGHT_DUV,
> +   IIO_MOD_PM1,
> +   IIO_MOD_PM2P5,
> +   IIO_MOD_PM4,
> +   IIO_MOD_PM10,
>  };
>
>  enum iio_event_type {
> diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> index ac2de6b7e89f..f6b8003fbe3c 100644
> --- a/tools/iio/iio_event_monitor.c
> +++ b/tools/iio/iio_event_monitor.c
> @@ -60,6 +60,7 @@ static const char * const iio_chan_type_name_spec[] = {
> [IIO_GRAVITY] = "gravity",
> [IIO_POSITIONRELATIVE] = "positionrelative",
> [IIO_PHASE] = "phase",
> +   [IIO_MASSCO

Re: [PATCH v3 1/3] iio: Add modifiers for ethanol and H2 gases

[Matt Ranostay]

On Thu, Dec 13, 2018 at 6:44 AM Andreas Brauchli
 wrote:
>
> Add ethanol and H2 gas modifiers:
> * IIO_MOD_ETHANOL

Was going to ask why this wasn't a chemical formula like the rest of
the modifiers, but C2H6O would be a bit wordy/unclear :).

> * IIO_MOD_H2
>

Acked-by: Matt Ranostay 

> Signed-off-by: Andreas Brauchli 
> ---
>  Documentation/ABI/testing/sysfs-bus-iio | 4 
>  include/uapi/linux/iio/types.h  | 2 ++
>  tools/iio/iio_event_monitor.c   | 4 
>  3 files changed, 10 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
> b/Documentation/ABI/testing/sysfs-bus-iio
> index 8127a08e366d..6d64521bf565 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -1554,6 +1554,10 @@ What:
> /sys/bus/iio/devices/iio:deviceX/in_concentration_raw
>  What:  /sys/bus/iio/devices/iio:deviceX/in_concentrationX_raw
>  What:  /sys/bus/iio/devices/iio:deviceX/in_concentration_co2_raw
>  What:  /sys/bus/iio/devices/iio:deviceX/in_concentrationX_co2_raw
> +What:  /sys/bus/iio/devices/iio:deviceX/in_concentration_ethanol_raw
> +What:  /sys/bus/iio/devices/iio:deviceX/in_concentrationX_ethanol_raw
> +What:  /sys/bus/iio/devices/iio:deviceX/in_concentration_h2_raw
> +What:  /sys/bus/iio/devices/iio:deviceX/in_concentrationX_h2_raw
>  What:  /sys/bus/iio/devices/iio:deviceX/in_concentration_voc_raw
>  What:  /sys/bus/iio/devices/iio:deviceX/in_concentrationX_voc_raw
>  KernelVersion: 4.3
> diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
> index 92baabc103ac..04a6649fa442 100644
> --- a/include/uapi/linux/iio/types.h
> +++ b/include/uapi/linux/iio/types.h
> @@ -87,6 +87,8 @@ enum iio_modifier {
> IIO_MOD_VOC,
> IIO_MOD_LIGHT_UV,
> IIO_MOD_LIGHT_DUV,
> +   IIO_MOD_ETHANOL,
> +   IIO_MOD_H2,
>  };
>
>  enum iio_event_type {
> diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> index ac2de6b7e89f..f29c885f4b28 100644
> --- a/tools/iio/iio_event_monitor.c
> +++ b/tools/iio/iio_event_monitor.c
> @@ -114,6 +114,8 @@ static const char * const iio_modifier_names[] = {
> [IIO_MOD_I] = "i",
> [IIO_MOD_Q] = "q",
> [IIO_MOD_CO2] = "co2",
> +   [IIO_MOD_ETHANOL] = "ethanol",
> +   [IIO_MOD_H2] = "h2",
> [IIO_MOD_VOC] = "voc",
>  };
>
> @@ -199,6 +201,8 @@ static bool event_is_known(struct iio_event_data *event)
> case IIO_MOD_I:
> case IIO_MOD_Q:
> case IIO_MOD_CO2:
> +   case IIO_MOD_ETHANOL:
> +   case IIO_MOD_H2:
> case IIO_MOD_VOC:
> break;
> default:
> --
> 2.17.1
>

Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type

[Matt Ranostay]

On Sat, Dec 1, 2018 at 5:48 PM Jonathan Cameron
 wrote:
>
> On Sun, 25 Nov 2018 16:44:23 +0100
> Tomasz Duszynski  wrote:
>
> > On Sun, Nov 25, 2018 at 06:14:44AM -0800, Matt Ranostay wrote:
> > > On Sun, Nov 25, 2018 at 6:03 AM Jonathan Cameron
> > >  wrote:
> > > >
> > > > On Sun, 25 Nov 2018 05:51:32 -0800
> > > > Matt Ranostay  wrote:
> > > >
> > > > > On Sat, Nov 24, 2018 at 2:14 PM Tomasz Duszynski  
> > > > > wrote:
> > > > > >
> > > > > > Measuring particulate matter in ug / m3 (micro-grams per cubic 
> > > > > > meter)
> > > > > > is de facto standard. Existing air quality sensors usually follow
> > > > > > this convention and are capable of returning measurements using
> > > > > > this unit.
> > > > > >
> > > > > > IIO currently does not offer suitable channel type for this
> > > > > > type of measurements hence this patch adds this.
> > > > > >
> > > > > > In addition, two modifiers are introduced used for distinguishing
> > > > > > between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> > > > > > IIO_MOD_PM10 and IIO_MOD_PM2p5.
> > > > > >
> > > > > > Signed-off-by: Tomasz Duszynski 
> > > > > > ---
> > > > > >  Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
> > > > > >  drivers/iio/industrialio-core.c |  3 +++
> > > > > >  include/uapi/linux/iio/types.h  |  3 +++
> > > > > >  tools/iio/iio_event_monitor.c   |  6 ++
> > > > > >  4 files changed, 22 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
> > > > > > b/Documentation/ABI/testing/sysfs-bus-iio
> > > > > > index 8127a08e366d..ce0ed140660d 100644
> > > > > > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > > > > > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > > > > > @@ -1684,4 +1684,13 @@ KernelVersion:   4.18
> > > > > >  Contact:   linux-...@vger.kernel.org
> > > > > >  Description:
> > > > > > Raw (unscaled) phase difference reading from 
> > > > > > channel Y
> > > > > > -   that can be processed to radians.
> > > > > > \ No newline at end of file
> > > > > > +   that can be processed to radians.
> > > > > > +
> > > > > > +What:  
> > > > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> > > > > > +What:  
> > > > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> > > > > > +What:  
> > > > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> > > > > > +What:  
> > > > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> > > > > > +KernelVersion: 4.21
> > > > > > +Contact:   linux-...@vger.kernel.org
> > > > > > +Description:
> > > > > > +   Mass concentration reading of particulate matter in 
> > > > > > ug / m3.
> > > > > > diff --git a/drivers/iio/industrialio-core.c 
> > > > > > b/drivers/iio/industrialio-core.c
> > > > > > index a062cfddc5af..2a9ef600c1fb 100644
> > > > > > --- a/drivers/iio/industrialio-core.c
> > > > > > +++ b/drivers/iio/industrialio-core.c
> > > > > > @@ -87,6 +87,7 @@ static const char * const 
> > > > > > iio_chan_type_name_spec[] = {
> > > > > > [IIO_GRAVITY]  = "gravity",
> > > > > > [IIO_POSITIONRELATIVE]  = "positionrelative",
> > > > > > [IIO_PHASE] = "phase",
> > > > > > +   [IIO_MASSCONCENTRATION] = "massconcentration",
> > > > > >  };
> > > > > >
> > > > > >  static const char * const iio_modifier_names[] = {
> > > > > > @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] 
> > > > > > = {
> > > > > > [IIO_MOD_Q] = "q",
> >

Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type

[Matt Ranostay]

On Sat, Dec 1, 2018 at 5:48 PM Jonathan Cameron
 wrote:
>
> On Sun, 25 Nov 2018 16:44:23 +0100
> Tomasz Duszynski  wrote:
>
> > On Sun, Nov 25, 2018 at 06:14:44AM -0800, Matt Ranostay wrote:
> > > On Sun, Nov 25, 2018 at 6:03 AM Jonathan Cameron
> > >  wrote:
> > > >
> > > > On Sun, 25 Nov 2018 05:51:32 -0800
> > > > Matt Ranostay  wrote:
> > > >
> > > > > On Sat, Nov 24, 2018 at 2:14 PM Tomasz Duszynski  
> > > > > wrote:
> > > > > >
> > > > > > Measuring particulate matter in ug / m3 (micro-grams per cubic 
> > > > > > meter)
> > > > > > is de facto standard. Existing air quality sensors usually follow
> > > > > > this convention and are capable of returning measurements using
> > > > > > this unit.
> > > > > >
> > > > > > IIO currently does not offer suitable channel type for this
> > > > > > type of measurements hence this patch adds this.
> > > > > >
> > > > > > In addition, two modifiers are introduced used for distinguishing
> > > > > > between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> > > > > > IIO_MOD_PM10 and IIO_MOD_PM2p5.
> > > > > >
> > > > > > Signed-off-by: Tomasz Duszynski 
> > > > > > ---
> > > > > >  Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
> > > > > >  drivers/iio/industrialio-core.c |  3 +++
> > > > > >  include/uapi/linux/iio/types.h  |  3 +++
> > > > > >  tools/iio/iio_event_monitor.c   |  6 ++
> > > > > >  4 files changed, 22 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
> > > > > > b/Documentation/ABI/testing/sysfs-bus-iio
> > > > > > index 8127a08e366d..ce0ed140660d 100644
> > > > > > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > > > > > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > > > > > @@ -1684,4 +1684,13 @@ KernelVersion:   4.18
> > > > > >  Contact:   linux-...@vger.kernel.org
> > > > > >  Description:
> > > > > > Raw (unscaled) phase difference reading from 
> > > > > > channel Y
> > > > > > -   that can be processed to radians.
> > > > > > \ No newline at end of file
> > > > > > +   that can be processed to radians.
> > > > > > +
> > > > > > +What:  
> > > > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> > > > > > +What:  
> > > > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> > > > > > +What:  
> > > > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> > > > > > +What:  
> > > > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> > > > > > +KernelVersion: 4.21
> > > > > > +Contact:   linux-...@vger.kernel.org
> > > > > > +Description:
> > > > > > +   Mass concentration reading of particulate matter in 
> > > > > > ug / m3.
> > > > > > diff --git a/drivers/iio/industrialio-core.c 
> > > > > > b/drivers/iio/industrialio-core.c
> > > > > > index a062cfddc5af..2a9ef600c1fb 100644
> > > > > > --- a/drivers/iio/industrialio-core.c
> > > > > > +++ b/drivers/iio/industrialio-core.c
> > > > > > @@ -87,6 +87,7 @@ static const char * const 
> > > > > > iio_chan_type_name_spec[] = {
> > > > > > [IIO_GRAVITY]  = "gravity",
> > > > > > [IIO_POSITIONRELATIVE]  = "positionrelative",
> > > > > > [IIO_PHASE] = "phase",
> > > > > > +   [IIO_MASSCONCENTRATION] = "massconcentration",
> > > > > >  };
> > > > > >
> > > > > >  static const char * const iio_modifier_names[] = {
> > > > > > @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] 
> > > > > > = {
> > > > > > [IIO_MOD_Q] = "q",
> >

Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type

[Matt Ranostay]

On Sun, Nov 25, 2018 at 6:03 AM Jonathan Cameron
 wrote:
>
> On Sun, 25 Nov 2018 05:51:32 -0800
> Matt Ranostay  wrote:
>
> > On Sat, Nov 24, 2018 at 2:14 PM Tomasz Duszynski  wrote:
> > >
> > > Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
> > > is de facto standard. Existing air quality sensors usually follow
> > > this convention and are capable of returning measurements using
> > > this unit.
> > >
> > > IIO currently does not offer suitable channel type for this
> > > type of measurements hence this patch adds this.
> > >
> > > In addition, two modifiers are introduced used for distinguishing
> > > between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> > > IIO_MOD_PM10 and IIO_MOD_PM2p5.
> > >
> > > Signed-off-by: Tomasz Duszynski 
> > > ---
> > >  Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
> > >  drivers/iio/industrialio-core.c |  3 +++
> > >  include/uapi/linux/iio/types.h  |  3 +++
> > >  tools/iio/iio_event_monitor.c   |  6 ++
> > >  4 files changed, 22 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
> > > b/Documentation/ABI/testing/sysfs-bus-iio
> > > index 8127a08e366d..ce0ed140660d 100644
> > > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > > @@ -1684,4 +1684,13 @@ KernelVersion:   4.18
> > >  Contact:   linux-...@vger.kernel.org
> > >  Description:
> > > Raw (unscaled) phase difference reading from channel Y
> > > -   that can be processed to radians.
> > > \ No newline at end of file
> > > +   that can be processed to radians.
> > > +
> > > +What:  
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> > > +What:  
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> > > +What:  
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> > > +What:  
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> > > +KernelVersion: 4.21
> > > +Contact:   linux-...@vger.kernel.org
> > > +Description:
> > > +   Mass concentration reading of particulate matter in ug / 
> > > m3.
> > > diff --git a/drivers/iio/industrialio-core.c 
> > > b/drivers/iio/industrialio-core.c
> > > index a062cfddc5af..2a9ef600c1fb 100644
> > > --- a/drivers/iio/industrialio-core.c
> > > +++ b/drivers/iio/industrialio-core.c
> > > @@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] = {
> > > [IIO_GRAVITY]  = "gravity",
> > > [IIO_POSITIONRELATIVE]  = "positionrelative",
> > > [IIO_PHASE] = "phase",
> > > +   [IIO_MASSCONCENTRATION] = "massconcentration",
> > >  };
> > >
> > >  static const char * const iio_modifier_names[] = {
> > > @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] = {
> > > [IIO_MOD_Q] = "q",
> > > [IIO_MOD_CO2] = "co2",
> > > [IIO_MOD_VOC] = "voc",
> > > +   [IIO_MOD_PM2p5] = "pm2p5",
> > > +   [IIO_MOD_PM10] = "pm10",
> > >  };
> > >
> > >  /* relies on pairs of these shared then separate */
> > > diff --git a/include/uapi/linux/iio/types.h 
> > > b/include/uapi/linux/iio/types.h
> > > index 92baabc103ac..465044b42af5 100644
> > > --- a/include/uapi/linux/iio/types.h
> > > +++ b/include/uapi/linux/iio/types.h
> > > @@ -46,6 +46,7 @@ enum iio_chan_type {
> > > IIO_GRAVITY,
> > > IIO_POSITIONRELATIVE,
> > > IIO_PHASE,
> > > +   IIO_MASSCONCENTRATION,
> >
> > So I'm guessing IIO_CONCENTRATION can't be scaled to the micro-grams
> > per cubic meter?
>
> Currently concentration is defined as a percentage reading of a substance
> (which does make me wonder if it is meant to be percentage of the volume or
> percentage of the mass?)  Either way, if can't convert to a density 
> measurement
> as it's a unit free ratio (I think).

Seems like it can be both..  guessing all the atmosphere ( CO2, VOC,
etc) ones are mass/density because on how they work.
But the electro-conductivity sensor that is using IIO_CONCENTRATI

Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type

[Matt Ranostay]

On Sun, Nov 25, 2018 at 6:03 AM Jonathan Cameron
 wrote:
>
> On Sun, 25 Nov 2018 05:51:32 -0800
> Matt Ranostay  wrote:
>
> > On Sat, Nov 24, 2018 at 2:14 PM Tomasz Duszynski  wrote:
> > >
> > > Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
> > > is de facto standard. Existing air quality sensors usually follow
> > > this convention and are capable of returning measurements using
> > > this unit.
> > >
> > > IIO currently does not offer suitable channel type for this
> > > type of measurements hence this patch adds this.
> > >
> > > In addition, two modifiers are introduced used for distinguishing
> > > between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> > > IIO_MOD_PM10 and IIO_MOD_PM2p5.
> > >
> > > Signed-off-by: Tomasz Duszynski 
> > > ---
> > >  Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
> > >  drivers/iio/industrialio-core.c |  3 +++
> > >  include/uapi/linux/iio/types.h  |  3 +++
> > >  tools/iio/iio_event_monitor.c   |  6 ++
> > >  4 files changed, 22 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
> > > b/Documentation/ABI/testing/sysfs-bus-iio
> > > index 8127a08e366d..ce0ed140660d 100644
> > > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > > @@ -1684,4 +1684,13 @@ KernelVersion:   4.18
> > >  Contact:   linux-...@vger.kernel.org
> > >  Description:
> > > Raw (unscaled) phase difference reading from channel Y
> > > -   that can be processed to radians.
> > > \ No newline at end of file
> > > +   that can be processed to radians.
> > > +
> > > +What:  
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> > > +What:  
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> > > +What:  
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> > > +What:  
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> > > +KernelVersion: 4.21
> > > +Contact:   linux-...@vger.kernel.org
> > > +Description:
> > > +   Mass concentration reading of particulate matter in ug / 
> > > m3.
> > > diff --git a/drivers/iio/industrialio-core.c 
> > > b/drivers/iio/industrialio-core.c
> > > index a062cfddc5af..2a9ef600c1fb 100644
> > > --- a/drivers/iio/industrialio-core.c
> > > +++ b/drivers/iio/industrialio-core.c
> > > @@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] = {
> > > [IIO_GRAVITY]  = "gravity",
> > > [IIO_POSITIONRELATIVE]  = "positionrelative",
> > > [IIO_PHASE] = "phase",
> > > +   [IIO_MASSCONCENTRATION] = "massconcentration",
> > >  };
> > >
> > >  static const char * const iio_modifier_names[] = {
> > > @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] = {
> > > [IIO_MOD_Q] = "q",
> > > [IIO_MOD_CO2] = "co2",
> > > [IIO_MOD_VOC] = "voc",
> > > +   [IIO_MOD_PM2p5] = "pm2p5",
> > > +   [IIO_MOD_PM10] = "pm10",
> > >  };
> > >
> > >  /* relies on pairs of these shared then separate */
> > > diff --git a/include/uapi/linux/iio/types.h 
> > > b/include/uapi/linux/iio/types.h
> > > index 92baabc103ac..465044b42af5 100644
> > > --- a/include/uapi/linux/iio/types.h
> > > +++ b/include/uapi/linux/iio/types.h
> > > @@ -46,6 +46,7 @@ enum iio_chan_type {
> > > IIO_GRAVITY,
> > > IIO_POSITIONRELATIVE,
> > > IIO_PHASE,
> > > +   IIO_MASSCONCENTRATION,
> >
> > So I'm guessing IIO_CONCENTRATION can't be scaled to the micro-grams
> > per cubic meter?
>
> Currently concentration is defined as a percentage reading of a substance
> (which does make me wonder if it is meant to be percentage of the volume or
> percentage of the mass?)  Either way, if can't convert to a density 
> measurement
> as it's a unit free ratio (I think).

Seems like it can be both..  guessing all the atmosphere ( CO2, VOC,
etc) ones are mass/density because on how they work.
But the electro-conductivity sensor that is using IIO_CONCENTRATI

Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type

[Matt Ranostay]

On Sat, Nov 24, 2018 at 2:14 PM Tomasz Duszynski  wrote:
>
> Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
> is de facto standard. Existing air quality sensors usually follow
> this convention and are capable of returning measurements using
> this unit.
>
> IIO currently does not offer suitable channel type for this
> type of measurements hence this patch adds this.
>
> In addition, two modifiers are introduced used for distinguishing
> between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> IIO_MOD_PM10 and IIO_MOD_PM2p5.
>
> Signed-off-by: Tomasz Duszynski 
> ---
>  Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
>  drivers/iio/industrialio-core.c |  3 +++
>  include/uapi/linux/iio/types.h  |  3 +++
>  tools/iio/iio_event_monitor.c   |  6 ++
>  4 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
> b/Documentation/ABI/testing/sysfs-bus-iio
> index 8127a08e366d..ce0ed140660d 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -1684,4 +1684,13 @@ KernelVersion:   4.18
>  Contact:   linux-...@vger.kernel.org
>  Description:
> Raw (unscaled) phase difference reading from channel Y
> -   that can be processed to radians.
> \ No newline at end of file
> +   that can be processed to radians.
> +
> +What:  
> /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> +What:  
> /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> +What:  
> /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> +What:  
> /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> +KernelVersion: 4.21
> +Contact:   linux-...@vger.kernel.org
> +Description:
> +   Mass concentration reading of particulate matter in ug / m3.
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index a062cfddc5af..2a9ef600c1fb 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] = {
> [IIO_GRAVITY]  = "gravity",
> [IIO_POSITIONRELATIVE]  = "positionrelative",
> [IIO_PHASE] = "phase",
> +   [IIO_MASSCONCENTRATION] = "massconcentration",
>  };
>
>  static const char * const iio_modifier_names[] = {
> @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] = {
> [IIO_MOD_Q] = "q",
> [IIO_MOD_CO2] = "co2",
> [IIO_MOD_VOC] = "voc",
> +   [IIO_MOD_PM2p5] = "pm2p5",
> +   [IIO_MOD_PM10] = "pm10",
>  };
>
>  /* relies on pairs of these shared then separate */
> diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
> index 92baabc103ac..465044b42af5 100644
> --- a/include/uapi/linux/iio/types.h
> +++ b/include/uapi/linux/iio/types.h
> @@ -46,6 +46,7 @@ enum iio_chan_type {
> IIO_GRAVITY,
> IIO_POSITIONRELATIVE,
> IIO_PHASE,
> +   IIO_MASSCONCENTRATION,

So I'm guessing IIO_CONCENTRATION can't be scaled to the micro-grams
per cubic meter?

>  };
>
>  enum iio_modifier {
> @@ -87,6 +88,8 @@ enum iio_modifier {
> IIO_MOD_VOC,
> IIO_MOD_LIGHT_UV,
> IIO_MOD_LIGHT_DUV,
> +   IIO_MOD_PM2p5,

I know this is unit of measure but the lowercase p in IIO_MOD_PM2p5 is
a bit non-standard for iio defines/enum.

- Matt

> +   IIO_MOD_PM10,
>  };
>
>  enum iio_event_type {
> diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> index ac2de6b7e89f..f0fcfeddba2b 100644
> --- a/tools/iio/iio_event_monitor.c
> +++ b/tools/iio/iio_event_monitor.c
> @@ -60,6 +60,7 @@ static const char * const iio_chan_type_name_spec[] = {
> [IIO_GRAVITY] = "gravity",
> [IIO_POSITIONRELATIVE] = "positionrelative",
> [IIO_PHASE] = "phase",
> +   [IIO_MASSCONCENTRATION] = "massconcentration",
>  };
>
>  static const char * const iio_ev_type_text[] = {
> @@ -115,6 +116,8 @@ static const char * const iio_modifier_names[] = {
> [IIO_MOD_Q] = "q",
> [IIO_MOD_CO2] = "co2",
> [IIO_MOD_VOC] = "voc",
> +   [IIO_MOD_PM2p5] = "pm2p5",
> +   [IIO_MOD_PM10] = "pm10",
>  };
>
>  static bool event_is_known(struct iio_event_data *event)
> @@ -156,6 +159,7 @@ static bool event_is_known(struct iio_event_data *event)
> case IIO_GRAVITY:
> case IIO_POSITIONRELATIVE:
> case IIO_PHASE:
> +   case IIO_MASSCONCENTRATION:
> break;
> default:
> return false;
> @@ -200,6 +204,8 @@ static bool event_is_known(struct iio_event_data *event)
> case IIO_MOD_Q:
> case IIO_MOD_CO2:
> case IIO_MOD_VOC:
> +   case IIO_MOD_PM2p5:
> +   case IIO_MOD_PM10:
> break;
> default:
> return false;
> --
> 2.19.2
>

Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type

[Matt Ranostay]

On Sat, Nov 24, 2018 at 2:14 PM Tomasz Duszynski  wrote:
>
> Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
> is de facto standard. Existing air quality sensors usually follow
> this convention and are capable of returning measurements using
> this unit.
>
> IIO currently does not offer suitable channel type for this
> type of measurements hence this patch adds this.
>
> In addition, two modifiers are introduced used for distinguishing
> between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> IIO_MOD_PM10 and IIO_MOD_PM2p5.
>
> Signed-off-by: Tomasz Duszynski 
> ---
>  Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
>  drivers/iio/industrialio-core.c |  3 +++
>  include/uapi/linux/iio/types.h  |  3 +++
>  tools/iio/iio_event_monitor.c   |  6 ++
>  4 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
> b/Documentation/ABI/testing/sysfs-bus-iio
> index 8127a08e366d..ce0ed140660d 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -1684,4 +1684,13 @@ KernelVersion:   4.18
>  Contact:   linux-...@vger.kernel.org
>  Description:
> Raw (unscaled) phase difference reading from channel Y
> -   that can be processed to radians.
> \ No newline at end of file
> +   that can be processed to radians.
> +
> +What:  
> /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> +What:  
> /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> +What:  
> /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> +What:  
> /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> +KernelVersion: 4.21
> +Contact:   linux-...@vger.kernel.org
> +Description:
> +   Mass concentration reading of particulate matter in ug / m3.
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index a062cfddc5af..2a9ef600c1fb 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] = {
> [IIO_GRAVITY]  = "gravity",
> [IIO_POSITIONRELATIVE]  = "positionrelative",
> [IIO_PHASE] = "phase",
> +   [IIO_MASSCONCENTRATION] = "massconcentration",
>  };
>
>  static const char * const iio_modifier_names[] = {
> @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] = {
> [IIO_MOD_Q] = "q",
> [IIO_MOD_CO2] = "co2",
> [IIO_MOD_VOC] = "voc",
> +   [IIO_MOD_PM2p5] = "pm2p5",
> +   [IIO_MOD_PM10] = "pm10",
>  };
>
>  /* relies on pairs of these shared then separate */
> diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
> index 92baabc103ac..465044b42af5 100644
> --- a/include/uapi/linux/iio/types.h
> +++ b/include/uapi/linux/iio/types.h
> @@ -46,6 +46,7 @@ enum iio_chan_type {
> IIO_GRAVITY,
> IIO_POSITIONRELATIVE,
> IIO_PHASE,
> +   IIO_MASSCONCENTRATION,

So I'm guessing IIO_CONCENTRATION can't be scaled to the micro-grams
per cubic meter?

>  };
>
>  enum iio_modifier {
> @@ -87,6 +88,8 @@ enum iio_modifier {
> IIO_MOD_VOC,
> IIO_MOD_LIGHT_UV,
> IIO_MOD_LIGHT_DUV,
> +   IIO_MOD_PM2p5,

I know this is unit of measure but the lowercase p in IIO_MOD_PM2p5 is
a bit non-standard for iio defines/enum.

- Matt

> +   IIO_MOD_PM10,
>  };
>
>  enum iio_event_type {
> diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> index ac2de6b7e89f..f0fcfeddba2b 100644
> --- a/tools/iio/iio_event_monitor.c
> +++ b/tools/iio/iio_event_monitor.c
> @@ -60,6 +60,7 @@ static const char * const iio_chan_type_name_spec[] = {
> [IIO_GRAVITY] = "gravity",
> [IIO_POSITIONRELATIVE] = "positionrelative",
> [IIO_PHASE] = "phase",
> +   [IIO_MASSCONCENTRATION] = "massconcentration",
>  };
>
>  static const char * const iio_ev_type_text[] = {
> @@ -115,6 +116,8 @@ static const char * const iio_modifier_names[] = {
> [IIO_MOD_Q] = "q",
> [IIO_MOD_CO2] = "co2",
> [IIO_MOD_VOC] = "voc",
> +   [IIO_MOD_PM2p5] = "pm2p5",
> +   [IIO_MOD_PM10] = "pm10",
>  };
>
>  static bool event_is_known(struct iio_event_data *event)
> @@ -156,6 +159,7 @@ static bool event_is_known(struct iio_event_data *event)
> case IIO_GRAVITY:
> case IIO_POSITIONRELATIVE:
> case IIO_PHASE:
> +   case IIO_MASSCONCENTRATION:
> break;
> default:
> return false;
> @@ -200,6 +204,8 @@ static bool event_is_known(struct iio_event_data *event)
> case IIO_MOD_Q:
> case IIO_MOD_CO2:
> case IIO_MOD_VOC:
> +   case IIO_MOD_PM2p5:
> +   case IIO_MOD_PM10:
> break;
> default:
> return false;
> --
> 2.19.2
>

Re: [PATCH] iio: adc: ina2xx: fix missing break statement

[Matt Ranostay]

On Tue, Oct 9, 2018 at 5:09 AM Colin King  wrote:
>
> From: Colin Ian King 
>
> The IIO_CHAN_INFO_SCALE case is missing a break statement and in
> the unlikely event that chan->address is not matched in the nested
> switch statement then the code falls through to the following
> IIO_CHAN_INFO_HARDWAREGAIN case.  Fix this by adding the missing
> break.   While we are fixing this, it's probably a good idea to
> add in a break statement to the IIO_CHAN_INFO_HARDWAREGAIN case
> too (this is a moot point).
>
> Detected by CoverityScan, CID#1462408 ("Missing break in switch")

I'm not familiar with running Coverity scans myself, but is this CID
some publicly accessible report?
If it is an in-house scan then it should be dropped IMHO

- Matt

>
> Fixes: ca6a2d86acae ("iio: adc: ina2xx: Allow setting Shunt Voltage PGA gain 
> and Bus Voltage range")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/iio/adc/ina2xx-adc.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/iio/adc/ina2xx-adc.c b/drivers/iio/adc/ina2xx-adc.c
> index d1239624187d..9bc5986780b9 100644
> --- a/drivers/iio/adc/ina2xx-adc.c
> +++ b/drivers/iio/adc/ina2xx-adc.c
> @@ -250,6 +250,7 @@ static int ina2xx_read_raw(struct iio_dev *indio_dev,
> *val2 = chip->shunt_resistor_uohm;
> return IIO_VAL_FRACTIONAL;
> }
> +   break;
>
> case IIO_CHAN_INFO_HARDWAREGAIN:
> switch (chan->address) {
> @@ -262,6 +263,7 @@ static int ina2xx_read_raw(struct iio_dev *indio_dev,
> *val = chip->range_vbus == 32 ? 1 : 2;
> return IIO_VAL_INT;
> }
> +   break;
> }
>
> return -EINVAL;
> --
> 2.17.1
>

Re: [PATCH] iio: adc: ina2xx: fix missing break statement

[Matt Ranostay]

On Tue, Oct 9, 2018 at 5:09 AM Colin King  wrote:
>
> From: Colin Ian King 
>
> The IIO_CHAN_INFO_SCALE case is missing a break statement and in
> the unlikely event that chan->address is not matched in the nested
> switch statement then the code falls through to the following
> IIO_CHAN_INFO_HARDWAREGAIN case.  Fix this by adding the missing
> break.   While we are fixing this, it's probably a good idea to
> add in a break statement to the IIO_CHAN_INFO_HARDWAREGAIN case
> too (this is a moot point).
>
> Detected by CoverityScan, CID#1462408 ("Missing break in switch")

I'm not familiar with running Coverity scans myself, but is this CID
some publicly accessible report?
If it is an in-house scan then it should be dropped IMHO

- Matt

>
> Fixes: ca6a2d86acae ("iio: adc: ina2xx: Allow setting Shunt Voltage PGA gain 
> and Bus Voltage range")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/iio/adc/ina2xx-adc.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/iio/adc/ina2xx-adc.c b/drivers/iio/adc/ina2xx-adc.c
> index d1239624187d..9bc5986780b9 100644
> --- a/drivers/iio/adc/ina2xx-adc.c
> +++ b/drivers/iio/adc/ina2xx-adc.c
> @@ -250,6 +250,7 @@ static int ina2xx_read_raw(struct iio_dev *indio_dev,
> *val2 = chip->shunt_resistor_uohm;
> return IIO_VAL_FRACTIONAL;
> }
> +   break;
>
> case IIO_CHAN_INFO_HARDWAREGAIN:
> switch (chan->address) {
> @@ -262,6 +263,7 @@ static int ina2xx_read_raw(struct iio_dev *indio_dev,
> *val = chip->range_vbus == 32 ? 1 : 2;
> return IIO_VAL_INT;
> }
> +   break;
> }
>
> return -EINVAL;
> --
> 2.17.1
>

Re: [PATCH] iio: proximity: lidar-v2: replace i2c block access method with the one already implemented.

[Matt Ranostay]

On Wed, Sep 12, 2018 at 8:51 PM Song Qiang  wrote:
>
> This driver tries to access a block of data on a i2c bus and it tries
> to manually make a device command frame and a consecutively read frame,
> then uses i2c_transfer() to read data. But this has already been
> implemented in i2c_smbus_read_i2c_block_data().
> Sorry for not having this device by my hand, which is a little expansive
> for me, but I have another i2c device and tested with both i2c_transfer()
> and i2c_smbus_read_i2c_block_data() and they all ends the same.
> I'm not familiar with the SMBus, don't know if the lidar_smbus_xfer()
> function is the same as i2c_smbus_read_block_data()? The original code
> is commented with something I'm not sure, but I think if it's a standard
> SMBus, it should be able to use in here.
> Hoping for someone to explain.
>

Yes actually there is a reason for this insanity!

It isn't actually SMBUS (note the lidar_smbus_xfer function below it)
and has a odd way to read registers via I2C.
Basically the I2C_M_STOP flags is the reason you can use the standard
i2c_smbus_read_i2c_block_data().

Page 6 in this datasheet
* 
http://static.garmin.com/pumac/LIDAR_Lite_v3_Operation_Manual_and_Technical_Specifications.pdf

> Signed-off-by: Song Qiang 
> ---
>  .../iio/proximity/pulsedlight-lidar-lite-v2.c  | 18 +-
>  1 file changed, 1 insertion(+), 17 deletions(-)
>
> diff --git a/drivers/iio/proximity/pulsedlight-lidar-lite-v2.c 
> b/drivers/iio/proximity/pulsedlight-lidar-lite-v2.c
> index 47af54f14756..ca880ba8e820 100644
> --- a/drivers/iio/proximity/pulsedlight-lidar-lite-v2.c
> +++ b/drivers/iio/proximity/pulsedlight-lidar-lite-v2.c
> @@ -63,23 +63,7 @@ static const struct iio_chan_spec lidar_channels[] = {
>
>  static int lidar_i2c_xfer(struct lidar_data *data, u8 reg, u8 *val, int len)
>  {
> -   struct i2c_client *client = data->client;
> -   struct i2c_msg msg[2];
> -   int ret;
> -
> -   msg[0].addr = client->addr;
> -   msg[0].flags = client->flags | I2C_M_STOP;
> -   msg[0].len = 1;
> -   msg[0].buf  = (char *) 
> -
> -   msg[1].addr = client->addr;
> -   msg[1].flags = client->flags | I2C_M_RD;
> -   msg[1].len = len;
> -   msg[1].buf = (char *) val;
> -
> -   ret = i2c_transfer(client->adapter, msg, 2);
> -
> -   return (ret == 2) ? 0 : -EIO;
> +   return i2c_smbus_read_i2c_block_data(data->client, reg, len, val);
>  }
>
>  static int lidar_smbus_xfer(struct lidar_data *data, u8 reg, u8 *val, int 
> len)
> --
> 2.17.1
>

Re: [PATCH] iio: proximity: lidar-v2: replace i2c block access method with the one already implemented.

[Matt Ranostay]

On Wed, Sep 12, 2018 at 8:51 PM Song Qiang  wrote:
>
> This driver tries to access a block of data on a i2c bus and it tries
> to manually make a device command frame and a consecutively read frame,
> then uses i2c_transfer() to read data. But this has already been
> implemented in i2c_smbus_read_i2c_block_data().
> Sorry for not having this device by my hand, which is a little expansive
> for me, but I have another i2c device and tested with both i2c_transfer()
> and i2c_smbus_read_i2c_block_data() and they all ends the same.
> I'm not familiar with the SMBus, don't know if the lidar_smbus_xfer()
> function is the same as i2c_smbus_read_block_data()? The original code
> is commented with something I'm not sure, but I think if it's a standard
> SMBus, it should be able to use in here.
> Hoping for someone to explain.
>

Yes actually there is a reason for this insanity!

It isn't actually SMBUS (note the lidar_smbus_xfer function below it)
and has a odd way to read registers via I2C.
Basically the I2C_M_STOP flags is the reason you can use the standard
i2c_smbus_read_i2c_block_data().

Page 6 in this datasheet
* 
http://static.garmin.com/pumac/LIDAR_Lite_v3_Operation_Manual_and_Technical_Specifications.pdf

> Signed-off-by: Song Qiang 
> ---
>  .../iio/proximity/pulsedlight-lidar-lite-v2.c  | 18 +-
>  1 file changed, 1 insertion(+), 17 deletions(-)
>
> diff --git a/drivers/iio/proximity/pulsedlight-lidar-lite-v2.c 
> b/drivers/iio/proximity/pulsedlight-lidar-lite-v2.c
> index 47af54f14756..ca880ba8e820 100644
> --- a/drivers/iio/proximity/pulsedlight-lidar-lite-v2.c
> +++ b/drivers/iio/proximity/pulsedlight-lidar-lite-v2.c
> @@ -63,23 +63,7 @@ static const struct iio_chan_spec lidar_channels[] = {
>
>  static int lidar_i2c_xfer(struct lidar_data *data, u8 reg, u8 *val, int len)
>  {
> -   struct i2c_client *client = data->client;
> -   struct i2c_msg msg[2];
> -   int ret;
> -
> -   msg[0].addr = client->addr;
> -   msg[0].flags = client->flags | I2C_M_STOP;
> -   msg[0].len = 1;
> -   msg[0].buf  = (char *) 
> -
> -   msg[1].addr = client->addr;
> -   msg[1].flags = client->flags | I2C_M_RD;
> -   msg[1].len = len;
> -   msg[1].buf = (char *) val;
> -
> -   ret = i2c_transfer(client->adapter, msg, 2);
> -
> -   return (ret == 2) ? 0 : -EIO;
> +   return i2c_smbus_read_i2c_block_data(data->client, reg, len, val);
>  }
>
>  static int lidar_smbus_xfer(struct lidar_data *data, u8 reg, u8 *val, int 
> len)
> --
> 2.17.1
>

Re: [PATCH v3] iio: chemical: Add support for Bosch BME680 sensor

[Matt Ranostay]

On Wed, Jul 11, 2018 at 5:13 AM, Himanshu Jha
 wrote:
> Bosch BME680 is a 4-in-1 sensor with temperature, pressure, humidity
> and gas sensing capability. It supports both I2C and SPI communication
> protocol for effective data communication.
>
> The device supports two modes:
>
> 1. Sleep mode
> 2. Forced mode
>
> The measurements only takes place when forced mode is triggered and a
> single TPHG cycle is performed by the sensor. The sensor automatically
> goes to sleep after afterwards.
>
> The device has various calibration constants/parameters programmed into
> devices' non-volatile memory(NVM) during production and can't be altered
> by the user. These constants are used in the compensation functions to
> get the required compensated readings along with the raw data. The
> compensation functions/algorithms are provided by Bosch Sensortec GmbH
> via their API[1]. As these don't change during the measurement cycle,
> therefore we read and store them at the probe. The default configs
> supplied by Bosch are also set at probe.
>
> 0-day tested with build success.
>
> GSoC-2018: https://summerofcode.withgoogle.com/projects/#6691473790074880
> Mentor: Daniel Baluta
> [1] https://github.com/BoschSensortec/BME680_driver
> Datasheet:
> https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BME680-DS001-00.pdf
>
> Cc: Daniel Baluta 
> Signed-off-by: Himanshu Jha 
> ---
>
> v3:
>-moved files to chemical directory instead of a dedicated directory.
>-read calibration parameters serially with endian conversions.
>-drop some return ret.
>-removed few unnecessary casts safely.
>-added 'u' suffix to explicitly specify unsigned for large values
> and thereby fixing comiler warning.
>-left aligned all comments.
>-added a comment explaining heater stability failure.
>
> v2:
>-Used devm_add_action() to add a generic remove method for
> both I2C & SPI driver.
>-Introduction of compensation functions.
>-chip initialisation routines moved to respective I2C and SPI
> driver.
>-Introduction of gas sensing rountines.
>-Simplified Kconfig to reduce various options.
>
>  drivers/iio/chemical/Kconfig   |  25 +
>  drivers/iio/chemical/Makefile  |   3 +
>  drivers/iio/chemical/bme680.h  |  99 
>  drivers/iio/chemical/bme680_core.c | 946 
> +
>  drivers/iio/chemical/bme680_i2c.c  |  83 
>  drivers/iio/chemical/bme680_spi.c  | 123 +
>  6 files changed, 1279 insertions(+)
>  create mode 100644 drivers/iio/chemical/bme680.h
>  create mode 100644 drivers/iio/chemical/bme680_core.c
>  create mode 100644 drivers/iio/chemical/bme680_i2c.c
>  create mode 100644 drivers/iio/chemical/bme680_spi.c
>
> diff --git a/drivers/iio/chemical/Kconfig b/drivers/iio/chemical/Kconfig
> index 5cb5be7..24790a8 100644
> --- a/drivers/iio/chemical/Kconfig
> +++ b/drivers/iio/chemical/Kconfig
> @@ -21,6 +21,31 @@ config ATLAS_PH_SENSOR
>  To compile this driver as module, choose M here: the
>  module will be called atlas-ph-sensor.
>
> +config BME680
> +   tristate "Bosch Sensortec BME680 sensor driver"
> +   depends on (I2C || SPI)
> +   select REGMAP
> +   select BME680_I2C if (I2C)
> +   select BME680_SPI if (SPI)

Don't think you actually need parentheses around any of these, but of
course then again doesn't hurt

> +   help
> + Say yes here to build support for Bosch Sensortec BME680 sensor with
> + temperature, pressure, humidity and gas sensing capability.
> +
> + This driver can also be built as a module. If so, the module for I2C
> + would be called bme680_i2c and bme680_spi for SPI support.
> +
> +config BME680_I2C
> +   tristate
> +   depends on BME680
> +   depends on I2C

Wouldn't  "depends on I2C && BME680"  be cleaner?  Maybe someone else
here can tell me if I'm too nit-picky :)

> +   select REGMAP_I2C
> +
> +config BME680_SPI
> +   tristate
> +   depends on BME680
> +   depends on SPI

Same only with SPI

> +   select REGMAP_SPI
> +
>  config CCS811
> tristate "AMS CCS811 VOC sensor"
> depends on I2C
> diff --git a/drivers/iio/chemical/Makefile b/drivers/iio/chemical/Makefile
> index a629b29..2f4c4ba 100644
> --- a/drivers/iio/chemical/Makefile
> +++ b/drivers/iio/chemical/Makefile
> @@ -4,6 +4,9 @@
>
>  # When adding new entries keep the list in alphabetical order
>  obj-$(CONFIG_ATLAS_PH_SENSOR)  += atlas-ph-sensor.o
> +obj-$(CONFIG_BME680) += bme680_core.o
> +obj-$(CONFIG_BME680_I2C) += bme680_i2c.o
> +obj-$(CONFIG_BME680_SPI) += bme680_spi.o
>  obj-$(CONFIG_CCS811)   += ccs811.o
>  obj-$(CONFIG_IAQCORE)  += ams-iaq-core.o
>  obj-$(CONFIG_VZ89X)+= vz89x.o
> diff --git a/drivers/iio/chemical/bme680.h b/drivers/iio/chemical/bme680.h
> new file mode 100644
> index 000..80c4190
> --- /dev/null
> +++ b/drivers/iio/chemical/bme680.h
> @@ -0,0 +1,99 @@
> +/* 

Re: [PATCH v3] iio: chemical: Add support for Bosch BME680 sensor

[Matt Ranostay]

On Wed, Jul 11, 2018 at 5:13 AM, Himanshu Jha
 wrote:
> Bosch BME680 is a 4-in-1 sensor with temperature, pressure, humidity
> and gas sensing capability. It supports both I2C and SPI communication
> protocol for effective data communication.
>
> The device supports two modes:
>
> 1. Sleep mode
> 2. Forced mode
>
> The measurements only takes place when forced mode is triggered and a
> single TPHG cycle is performed by the sensor. The sensor automatically
> goes to sleep after afterwards.
>
> The device has various calibration constants/parameters programmed into
> devices' non-volatile memory(NVM) during production and can't be altered
> by the user. These constants are used in the compensation functions to
> get the required compensated readings along with the raw data. The
> compensation functions/algorithms are provided by Bosch Sensortec GmbH
> via their API[1]. As these don't change during the measurement cycle,
> therefore we read and store them at the probe. The default configs
> supplied by Bosch are also set at probe.
>
> 0-day tested with build success.
>
> GSoC-2018: https://summerofcode.withgoogle.com/projects/#6691473790074880
> Mentor: Daniel Baluta
> [1] https://github.com/BoschSensortec/BME680_driver
> Datasheet:
> https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BME680-DS001-00.pdf
>
> Cc: Daniel Baluta 
> Signed-off-by: Himanshu Jha 
> ---
>
> v3:
>-moved files to chemical directory instead of a dedicated directory.
>-read calibration parameters serially with endian conversions.
>-drop some return ret.
>-removed few unnecessary casts safely.
>-added 'u' suffix to explicitly specify unsigned for large values
> and thereby fixing comiler warning.
>-left aligned all comments.
>-added a comment explaining heater stability failure.
>
> v2:
>-Used devm_add_action() to add a generic remove method for
> both I2C & SPI driver.
>-Introduction of compensation functions.
>-chip initialisation routines moved to respective I2C and SPI
> driver.
>-Introduction of gas sensing rountines.
>-Simplified Kconfig to reduce various options.
>
>  drivers/iio/chemical/Kconfig   |  25 +
>  drivers/iio/chemical/Makefile  |   3 +
>  drivers/iio/chemical/bme680.h  |  99 
>  drivers/iio/chemical/bme680_core.c | 946 
> +
>  drivers/iio/chemical/bme680_i2c.c  |  83 
>  drivers/iio/chemical/bme680_spi.c  | 123 +
>  6 files changed, 1279 insertions(+)
>  create mode 100644 drivers/iio/chemical/bme680.h
>  create mode 100644 drivers/iio/chemical/bme680_core.c
>  create mode 100644 drivers/iio/chemical/bme680_i2c.c
>  create mode 100644 drivers/iio/chemical/bme680_spi.c
>
> diff --git a/drivers/iio/chemical/Kconfig b/drivers/iio/chemical/Kconfig
> index 5cb5be7..24790a8 100644
> --- a/drivers/iio/chemical/Kconfig
> +++ b/drivers/iio/chemical/Kconfig
> @@ -21,6 +21,31 @@ config ATLAS_PH_SENSOR
>  To compile this driver as module, choose M here: the
>  module will be called atlas-ph-sensor.
>
> +config BME680
> +   tristate "Bosch Sensortec BME680 sensor driver"
> +   depends on (I2C || SPI)
> +   select REGMAP
> +   select BME680_I2C if (I2C)
> +   select BME680_SPI if (SPI)

Don't think you actually need parentheses around any of these, but of
course then again doesn't hurt

> +   help
> + Say yes here to build support for Bosch Sensortec BME680 sensor with
> + temperature, pressure, humidity and gas sensing capability.
> +
> + This driver can also be built as a module. If so, the module for I2C
> + would be called bme680_i2c and bme680_spi for SPI support.
> +
> +config BME680_I2C
> +   tristate
> +   depends on BME680
> +   depends on I2C

Wouldn't  "depends on I2C && BME680"  be cleaner?  Maybe someone else
here can tell me if I'm too nit-picky :)

> +   select REGMAP_I2C
> +
> +config BME680_SPI
> +   tristate
> +   depends on BME680
> +   depends on SPI

Same only with SPI

> +   select REGMAP_SPI
> +
>  config CCS811
> tristate "AMS CCS811 VOC sensor"
> depends on I2C
> diff --git a/drivers/iio/chemical/Makefile b/drivers/iio/chemical/Makefile
> index a629b29..2f4c4ba 100644
> --- a/drivers/iio/chemical/Makefile
> +++ b/drivers/iio/chemical/Makefile
> @@ -4,6 +4,9 @@
>
>  # When adding new entries keep the list in alphabetical order
>  obj-$(CONFIG_ATLAS_PH_SENSOR)  += atlas-ph-sensor.o
> +obj-$(CONFIG_BME680) += bme680_core.o
> +obj-$(CONFIG_BME680_I2C) += bme680_i2c.o
> +obj-$(CONFIG_BME680_SPI) += bme680_spi.o
>  obj-$(CONFIG_CCS811)   += ccs811.o
>  obj-$(CONFIG_IAQCORE)  += ams-iaq-core.o
>  obj-$(CONFIG_VZ89X)+= vz89x.o
> diff --git a/drivers/iio/chemical/bme680.h b/drivers/iio/chemical/bme680.h
> new file mode 100644
> index 000..80c4190
> --- /dev/null
> +++ b/drivers/iio/chemical/bme680.h
> @@ -0,0 +1,99 @@
> +/* 

[PATCH] tsl2550: fix lux1_input error in low light

[Matt Ranostay]

ADC channel 0 photodiode detects both infrared + visible light,
but ADC channel 1 just detects infrared. However, the latter is a bit
more sensitive in that range so complete darkness or low light causes
a error condition in which the chan0 - chan1 is negative that
results in a -EAGAIN.

This patch changes the resulting lux1_input sysfs attribute message from
"Resource temporarily unavailable" to a user-grokable lux value of 0.

Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Signed-off-by: Matt Ranostay 
---
 drivers/misc/tsl2550.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/tsl2550.c b/drivers/misc/tsl2550.c
index adf46072cb37..3fce3b6a3624 100644
--- a/drivers/misc/tsl2550.c
+++ b/drivers/misc/tsl2550.c
@@ -177,7 +177,7 @@ static int tsl2550_calculate_lux(u8 ch0, u8 ch1)
} else
lux = 0;
else
-   return -EAGAIN;
+   return 0;
 
/* LUX range check */
return lux > TSL2550_MAX_LUX ? TSL2550_MAX_LUX : lux;
-- 
2.14.1

[PATCH] tsl2550: fix lux1_input error in low light

[Matt Ranostay]

ADC channel 0 photodiode detects both infrared + visible light,
but ADC channel 1 just detects infrared. However, the latter is a bit
more sensitive in that range so complete darkness or low light causes
a error condition in which the chan0 - chan1 is negative that
results in a -EAGAIN.

This patch changes the resulting lux1_input sysfs attribute message from
"Resource temporarily unavailable" to a user-grokable lux value of 0.

Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Signed-off-by: Matt Ranostay 
---
 drivers/misc/tsl2550.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/tsl2550.c b/drivers/misc/tsl2550.c
index adf46072cb37..3fce3b6a3624 100644
--- a/drivers/misc/tsl2550.c
+++ b/drivers/misc/tsl2550.c
@@ -177,7 +177,7 @@ static int tsl2550_calculate_lux(u8 ch0, u8 ch1)
} else
lux = 0;
else
-   return -EAGAIN;
+   return 0;
 
/* LUX range check */
return lux > TSL2550_MAX_LUX ? TSL2550_MAX_LUX : lux;
-- 
2.14.1

Re: [RFC PATCH 1/1] power: supply: bq27xxx: Call power_supply_changed on status change

[Matt Ranostay]

Commit message please :)

On Tue, Feb 27, 2018 at 5:04 PM, Merlijn Wajer  wrote:
> Signed-off-by: Merlijn Wajer 
> ---

Single patch changes usually don't have a cover letter. you put more
detail here in the cutoff section (aka after --- above)


>  drivers/power/supply/bq27xxx_battery.c | 59 
> +-
>  include/linux/power/bq27xxx_battery.h  |  1 +
>  2 files changed, 30 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/power/supply/bq27xxx_battery.c 
> b/drivers/power/supply/bq27xxx_battery.c
> index 0a203672744c..218d153fb431 100644
> --- a/drivers/power/supply/bq27xxx_battery.c
> +++ b/drivers/power/supply/bq27xxx_battery.c
> @@ -1527,6 +1527,31 @@ static int bq27xxx_battery_read_health(struct 
> bq27xxx_device_info *di)
> return POWER_SUPPLY_HEALTH_GOOD;
>  }
>
> +static int bq27xxx_battery_read_status(struct bq27xxx_device_info *di)
> +{
> +   int status;
> +
> +   if (di->opts & BQ27XXX_O_ZERO) {
> +   if (di->cache.flags & BQ27000_FLAG_FC)
> +   status = POWER_SUPPLY_STATUS_FULL;
> +   else if (di->cache.flags & BQ27000_FLAG_CHGS)
> +   status = POWER_SUPPLY_STATUS_CHARGING;
> +   else if (power_supply_am_i_supplied(di->bat) > 0)
> +   status = POWER_SUPPLY_STATUS_NOT_CHARGING;
> +   else
> +   status = POWER_SUPPLY_STATUS_DISCHARGING;
> +   } else {
> +   if (di->cache.flags & BQ27XXX_FLAG_FC)
> +   status = POWER_SUPPLY_STATUS_FULL;
> +   else if (di->cache.flags & BQ27XXX_FLAG_DSC)
> +   status = POWER_SUPPLY_STATUS_DISCHARGING;
> +   else
> +   status = POWER_SUPPLY_STATUS_CHARGING;
> +   }
> +
> +   return status;
> +}
> +
>  void bq27xxx_battery_update(struct bq27xxx_device_info *di)
>  {
> struct bq27xxx_reg_cache cache = {0, };
> @@ -1547,6 +1572,7 @@ void bq27xxx_battery_update(struct bq27xxx_device_info 
> *di)
> cache.time_to_full = -ENODATA;
> cache.charge_full = -ENODATA;
> cache.health = -ENODATA;
> +   cache.status = bq27xxx_battery_read_status(di);
> } else {
> if (di->regs[BQ27XXX_REG_TTE] != INVALID_REG_ADDR)
> cache.time_to_empty = 
> bq27xxx_battery_read_time(di, BQ27XXX_REG_TTE);
> @@ -1559,6 +1585,7 @@ void bq27xxx_battery_update(struct bq27xxx_device_info 
> *di)
> if (di->regs[BQ27XXX_REG_AE] != INVALID_REG_ADDR)
> cache.energy = 
> bq27xxx_battery_read_energy(di);
> cache.health = bq27xxx_battery_read_health(di);
> +   cache.status = bq27xxx_battery_read_status(di);
> }
> if (di->regs[BQ27XXX_REG_CYCT] != INVALID_REG_ADDR)
> cache.cycle_count = bq27xxx_battery_read_cyct(di);
> @@ -1570,7 +1597,7 @@ void bq27xxx_battery_update(struct bq27xxx_device_info 
> *di)
> di->charge_design_full = 
> bq27xxx_battery_read_dcap(di);
> }
>
> -   if (di->cache.capacity != cache.capacity)
> +   if ((di->cache.capacity != cache.capacity) || (di->cache.status != 
> cache.status))
> power_supply_changed(di->bat);
>
> if (memcmp(>cache, , sizeof(cache)) != 0)
> @@ -1625,34 +1652,6 @@ static int bq27xxx_battery_current(struct 
> bq27xxx_device_info *di,
> return 0;
>  }
>
> -static int bq27xxx_battery_status(struct bq27xxx_device_info *di,
> - union power_supply_propval *val)
> -{
> -   int status;
> -
> -   if (di->opts & BQ27XXX_O_ZERO) {
> -   if (di->cache.flags & BQ27000_FLAG_FC)
> -   status = POWER_SUPPLY_STATUS_FULL;
> -   else if (di->cache.flags & BQ27000_FLAG_CHGS)
> -   status = POWER_SUPPLY_STATUS_CHARGING;
> -   else if (power_supply_am_i_supplied(di->bat) > 0)
> -   status = POWER_SUPPLY_STATUS_NOT_CHARGING;
> -   else
> -   status = POWER_SUPPLY_STATUS_DISCHARGING;
> -   } else {
> -   if (di->cache.flags & BQ27XXX_FLAG_FC)
> -   status = POWER_SUPPLY_STATUS_FULL;
> -   else if (di->cache.flags & BQ27XXX_FLAG_DSC)
> -   status = POWER_SUPPLY_STATUS_DISCHARGING;
> -   else
> -   status = POWER_SUPPLY_STATUS_CHARGING;
> -   }
> -
> -   val->intval = status;
> -
> -   return 0;
> -}
> -
>  static int bq27xxx_battery_capacity_level(struct bq27xxx_device_info *di,
>   union power_supply_propval *val)
>  {
> @@ -1733,7 +1732,7 @@ static int 

Re: [RFC PATCH 1/1] power: supply: bq27xxx: Call power_supply_changed on status change

[Matt Ranostay]

Commit message please :)

On Tue, Feb 27, 2018 at 5:04 PM, Merlijn Wajer  wrote:
> Signed-off-by: Merlijn Wajer 
> ---

Single patch changes usually don't have a cover letter. you put more
detail here in the cutoff section (aka after --- above)


>  drivers/power/supply/bq27xxx_battery.c | 59 
> +-
>  include/linux/power/bq27xxx_battery.h  |  1 +
>  2 files changed, 30 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/power/supply/bq27xxx_battery.c 
> b/drivers/power/supply/bq27xxx_battery.c
> index 0a203672744c..218d153fb431 100644
> --- a/drivers/power/supply/bq27xxx_battery.c
> +++ b/drivers/power/supply/bq27xxx_battery.c
> @@ -1527,6 +1527,31 @@ static int bq27xxx_battery_read_health(struct 
> bq27xxx_device_info *di)
> return POWER_SUPPLY_HEALTH_GOOD;
>  }
>
> +static int bq27xxx_battery_read_status(struct bq27xxx_device_info *di)
> +{
> +   int status;
> +
> +   if (di->opts & BQ27XXX_O_ZERO) {
> +   if (di->cache.flags & BQ27000_FLAG_FC)
> +   status = POWER_SUPPLY_STATUS_FULL;
> +   else if (di->cache.flags & BQ27000_FLAG_CHGS)
> +   status = POWER_SUPPLY_STATUS_CHARGING;
> +   else if (power_supply_am_i_supplied(di->bat) > 0)
> +   status = POWER_SUPPLY_STATUS_NOT_CHARGING;
> +   else
> +   status = POWER_SUPPLY_STATUS_DISCHARGING;
> +   } else {
> +   if (di->cache.flags & BQ27XXX_FLAG_FC)
> +   status = POWER_SUPPLY_STATUS_FULL;
> +   else if (di->cache.flags & BQ27XXX_FLAG_DSC)
> +   status = POWER_SUPPLY_STATUS_DISCHARGING;
> +   else
> +   status = POWER_SUPPLY_STATUS_CHARGING;
> +   }
> +
> +   return status;
> +}
> +
>  void bq27xxx_battery_update(struct bq27xxx_device_info *di)
>  {
> struct bq27xxx_reg_cache cache = {0, };
> @@ -1547,6 +1572,7 @@ void bq27xxx_battery_update(struct bq27xxx_device_info 
> *di)
> cache.time_to_full = -ENODATA;
> cache.charge_full = -ENODATA;
> cache.health = -ENODATA;
> +   cache.status = bq27xxx_battery_read_status(di);
> } else {
> if (di->regs[BQ27XXX_REG_TTE] != INVALID_REG_ADDR)
> cache.time_to_empty = 
> bq27xxx_battery_read_time(di, BQ27XXX_REG_TTE);
> @@ -1559,6 +1585,7 @@ void bq27xxx_battery_update(struct bq27xxx_device_info 
> *di)
> if (di->regs[BQ27XXX_REG_AE] != INVALID_REG_ADDR)
> cache.energy = 
> bq27xxx_battery_read_energy(di);
> cache.health = bq27xxx_battery_read_health(di);
> +   cache.status = bq27xxx_battery_read_status(di);
> }
> if (di->regs[BQ27XXX_REG_CYCT] != INVALID_REG_ADDR)
> cache.cycle_count = bq27xxx_battery_read_cyct(di);
> @@ -1570,7 +1597,7 @@ void bq27xxx_battery_update(struct bq27xxx_device_info 
> *di)
> di->charge_design_full = 
> bq27xxx_battery_read_dcap(di);
> }
>
> -   if (di->cache.capacity != cache.capacity)
> +   if ((di->cache.capacity != cache.capacity) || (di->cache.status != 
> cache.status))
> power_supply_changed(di->bat);
>
> if (memcmp(>cache, , sizeof(cache)) != 0)
> @@ -1625,34 +1652,6 @@ static int bq27xxx_battery_current(struct 
> bq27xxx_device_info *di,
> return 0;
>  }
>
> -static int bq27xxx_battery_status(struct bq27xxx_device_info *di,
> - union power_supply_propval *val)
> -{
> -   int status;
> -
> -   if (di->opts & BQ27XXX_O_ZERO) {
> -   if (di->cache.flags & BQ27000_FLAG_FC)
> -   status = POWER_SUPPLY_STATUS_FULL;
> -   else if (di->cache.flags & BQ27000_FLAG_CHGS)
> -   status = POWER_SUPPLY_STATUS_CHARGING;
> -   else if (power_supply_am_i_supplied(di->bat) > 0)
> -   status = POWER_SUPPLY_STATUS_NOT_CHARGING;
> -   else
> -   status = POWER_SUPPLY_STATUS_DISCHARGING;
> -   } else {
> -   if (di->cache.flags & BQ27XXX_FLAG_FC)
> -   status = POWER_SUPPLY_STATUS_FULL;
> -   else if (di->cache.flags & BQ27XXX_FLAG_DSC)
> -   status = POWER_SUPPLY_STATUS_DISCHARGING;
> -   else
> -   status = POWER_SUPPLY_STATUS_CHARGING;
> -   }
> -
> -   val->intval = status;
> -
> -   return 0;
> -}
> -
>  static int bq27xxx_battery_capacity_level(struct bq27xxx_device_info *di,
>   union power_supply_propval *val)
>  {
> @@ -1733,7 +1732,7 @@ static int bq27xxx_battery_get_property(struct 
> power_supply 

Re: [PATCH v2] IIO: bmp280-core.c: fix error in humidity calculation

[Matt Ranostay]

On Mon, Apr 10, 2017 at 10:00 AM, Andreas Klinger <a...@it-klinger.de> wrote:
> While calculating the compensation of the humidity there are negative values
> interpreted as unsigned because of unsigned variables used.  These values as
> well as the constants need to be casted to signed as indicated by the
> documentation of the sensor.
>
> Changes in v2:
> - cast also constants to signed; otherwise calculation is not correct
>
> I removed the Acked-By of Linus Walleij because of another change in the
> calculation. Don't know how it should be treated.
>
> Signed-off-by: Andreas Klinger <a...@it-klinger.de>

Reviewed-by: Matt Ranostay <matt.ranos...@konsulko.com>

> ---
>  drivers/iio/pressure/bmp280-core.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iio/pressure/bmp280-core.c 
> b/drivers/iio/pressure/bmp280-core.c
> index 4d18826ac63c..d82b788374b6 100644
> --- a/drivers/iio/pressure/bmp280-core.c
> +++ b/drivers/iio/pressure/bmp280-core.c
> @@ -175,11 +175,12 @@ static u32 bmp280_compensate_humidity(struct 
> bmp280_data *data,
> }
> H6 = sign_extend32(tmp, 7);
>
> -   var = ((s32)data->t_fine) - 76800;
> -   var = adc_humidity << 14) - (H4 << 20) - (H5 * var)) + 16384) >> 
> 15)
> -   * (((var * H6) >> 10) * (((var * H3) >> 11) + 32768)) >> 
> 10)
> -   + 2097152) * H2 + 8192) >> 14);
> -   var -= var >> 15) * (var >> 15)) >> 7) * H1) >> 4;
> +   var = ((s32)data->t_fine) - (s32)76800;
> +   var = adc_humidity << 14) - (H4 << 20) - (H5 * var))
> +   + (s32)16384) >> 15) * (((var * H6) >> 10)
> +   * (((var * (s32)H3) >> 11) + (s32)32768)) >> 10)
> +   + (s32)2097152) * H2 + 8192) >> 14);
> +   var -= var >> 15) * (var >> 15)) >> 7) * (s32)H1) >> 4;
>
> return var >> 12;
>  };
> --
> 2.1.4
>
>
> --

Re: [PATCH v2] IIO: bmp280-core.c: fix error in humidity calculation

[Matt Ranostay]

On Mon, Apr 10, 2017 at 10:00 AM, Andreas Klinger  wrote:
> While calculating the compensation of the humidity there are negative values
> interpreted as unsigned because of unsigned variables used.  These values as
> well as the constants need to be casted to signed as indicated by the
> documentation of the sensor.
>
> Changes in v2:
> - cast also constants to signed; otherwise calculation is not correct
>
> I removed the Acked-By of Linus Walleij because of another change in the
> calculation. Don't know how it should be treated.
>
> Signed-off-by: Andreas Klinger 

Reviewed-by: Matt Ranostay 

> ---
>  drivers/iio/pressure/bmp280-core.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iio/pressure/bmp280-core.c 
> b/drivers/iio/pressure/bmp280-core.c
> index 4d18826ac63c..d82b788374b6 100644
> --- a/drivers/iio/pressure/bmp280-core.c
> +++ b/drivers/iio/pressure/bmp280-core.c
> @@ -175,11 +175,12 @@ static u32 bmp280_compensate_humidity(struct 
> bmp280_data *data,
> }
> H6 = sign_extend32(tmp, 7);
>
> -   var = ((s32)data->t_fine) - 76800;
> -   var = adc_humidity << 14) - (H4 << 20) - (H5 * var)) + 16384) >> 
> 15)
> -   * (((var * H6) >> 10) * (((var * H3) >> 11) + 32768)) >> 
> 10)
> -   + 2097152) * H2 + 8192) >> 14);
> -   var -= var >> 15) * (var >> 15)) >> 7) * H1) >> 4;
> +   var = ((s32)data->t_fine) - (s32)76800;
> +   var = adc_humidity << 14) - (H4 << 20) - (H5 * var))
> +   + (s32)16384) >> 15) * (((var * H6) >> 10)
> +   * (((var * (s32)H3) >> 11) + (s32)32768)) >> 10)
> +   + (s32)2097152) * H2 + 8192) >> 14);
> +   var -= var >> 15) * (var >> 15)) >> 7) * (s32)H1) >> 4;
>
> return var >> 12;
>  };
> --
> 2.1.4
>
>
> --

Re: [PATCH] IIO: bmp280-core.c: fix error in humidity calculation

[Matt Ranostay]

On Fri, Apr 7, 2017 at 12:27 PM, Andreas Klinger <a...@it-klinger.de> wrote:
> Hi Matt,
>
> i've extracted the error condition in a small userspace application for
> demonstration. Just compile and see that in this case the variable H3 is zero
> but the whole term evaluates differently if treated as unsigned or signed.
>
> The whole example including the values of the variables are taken from the 
> real
> driver.
>

Ok now I see what you are referencing from the datasheet, and can
confirm the values are incorrect.

Just a suggestion rather than have all those casts it would be easier
to just change H1 and H3 types
to signed integers.

Thanks,

Matt


> Andreas
>
>
> Now the example:
>
> ---
>
> /*
>  * humidity.c
>  * this test program is just for demonstrating the difference in the
>  * calculation of humidity compensation with BME280 sensor
>  *
>  * This program is free software; you can redistribute it and/or modify
>  * it under the terms of the GNU General Public License version 2 as
>  * published by the Free Software Foundation.
>  *
>  */
>
> #include 
> #include 
>
> int main(int argn, char* argv[])
> {
> int adc_humidity = 28275;
> int t_fine = 50623;
> unsigned int H1 = 75, H3 = 0;
> int H2 = 360, H4 = 324, H5 = 0, H6 = 30;
> int var;
>
> var = -26177;
> /* extracted errornous term with cast */
> printf("with cast:%d\n", (((var * H6) >> 10) * (((var * (int)H3) 
> >> 11)
> + (int)32768)) >> 10);
> /* extracted errornous term now without a cast */
> printf("without cast: %d\n", (((var * H6) >> 10) * (((var * H3) >> 11)
> + 32768)) >> 10);
>
> printf("\n");
> printf("t_fine: %d; humidity: %d\nH: %d; %d; %d; %d; %d; %d\n",
> t_fine, adc_humidity, H1, H2, H3, H4, H5, H6);
> printf("\n");
>
> /* the whole example taken from the driver */
> /* with the cast as proposed by the documentation */
> var = ((int)t_fine) - (int)76800;
> var = adc_humidity << 14) - (H4 << 20) - (H5 * var))
> + (int)16384) >> 15) * (((var * H6) >> 10)
> * (((var * (int)H3) >> 11) + (int)32768)) >> 10)
> + (int)2097152) * H2 + 8192) >> 14);
> var -= var >> 15) * (var >> 15)) >> 7) * (int)H1) >> 4;
>
> printf("with cast:var: %d\n", var>>12);
> printf("\n");
>
> /* now the same calculation without the cast */
> var = (t_fine) - 76800;
> var = adc_humidity << 14) - (H4 << 20) - (H5 * var))
> + 16384) >> 15) * (((var * H6) >> 10)
> * (((var * H3) >> 11) + 32768)) >> 10)
> + 2097152) * H2 + 8192) >> 14);
> var -= ((((var >> 15) * (var >> 15)) >> 7) * H1) >> 4;
>
> printf("without cast: var: %d\n", var>>12);
>
> return 0;
> }
>
> ---
>
> Output:
>
> with cast:-24544
> without cast: 4169760
>
> t_fine: 50623; humidity: 28275
> H: 75; 360; 0; 324; 0; 30
>
> with cast:var: 41671
>
> without cast: var: 124497
>
> ---
>
> Matt Ranostay <matt.ranos...@konsulko.com> schrieb am Thu, 06. Apr 23:13:
>> On Mon, Apr 3, 2017 at 11:16 PM, Matt Ranostay
>> <matt.ranos...@konsulko.com> wrote:
>> > On Sun, Apr 2, 2017 at 10:29 AM, Andreas Klinger <a...@it-klinger.de> 
>> > wrote:
>> >> Linus Walleij <linus.wall...@linaro.org> schrieb am Sun, 02. Apr 16:56:
>> >>> On Sun, Apr 2, 2017 at 11:32 AM, Jonathan Cameron <ji...@kernel.org> 
>> >>> wrote:
>> >>> > On 27/03/17 11:06, Andreas Klinger wrote:
>> >>> >> While calculating the compensation of the humidity there are negative
>> >>> >> values interpreted as unsigned because of unsigned variables used.
>> >>> >> These values need to be casted to signed as indicated by the 
>> >>> >> documentation
>> >>> >> of the sensor.
>> >>> >>
>> >>> >> Signed-off-by: Andreas Klinger <a...@it-klinger.de>
>> >>> >
>> >>> > Looks superficially right to me, but would like an Ack from Linus 
&

Re: [PATCH] IIO: bmp280-core.c: fix error in humidity calculation

[Matt Ranostay]

On Fri, Apr 7, 2017 at 12:27 PM, Andreas Klinger  wrote:
> Hi Matt,
>
> i've extracted the error condition in a small userspace application for
> demonstration. Just compile and see that in this case the variable H3 is zero
> but the whole term evaluates differently if treated as unsigned or signed.
>
> The whole example including the values of the variables are taken from the 
> real
> driver.
>

Ok now I see what you are referencing from the datasheet, and can
confirm the values are incorrect.

Just a suggestion rather than have all those casts it would be easier
to just change H1 and H3 types
to signed integers.

Thanks,

Matt


> Andreas
>
>
> Now the example:
>
> ---
>
> /*
>  * humidity.c
>  * this test program is just for demonstrating the difference in the
>  * calculation of humidity compensation with BME280 sensor
>  *
>  * This program is free software; you can redistribute it and/or modify
>  * it under the terms of the GNU General Public License version 2 as
>  * published by the Free Software Foundation.
>  *
>  */
>
> #include 
> #include 
>
> int main(int argn, char* argv[])
> {
> int adc_humidity = 28275;
> int t_fine = 50623;
> unsigned int H1 = 75, H3 = 0;
> int H2 = 360, H4 = 324, H5 = 0, H6 = 30;
> int var;
>
> var = -26177;
> /* extracted errornous term with cast */
> printf("with cast:%d\n", (((var * H6) >> 10) * (((var * (int)H3) 
> >> 11)
> + (int)32768)) >> 10);
> /* extracted errornous term now without a cast */
> printf("without cast: %d\n", (((var * H6) >> 10) * (((var * H3) >> 11)
> + 32768)) >> 10);
>
> printf("\n");
> printf("t_fine: %d; humidity: %d\nH: %d; %d; %d; %d; %d; %d\n",
> t_fine, adc_humidity, H1, H2, H3, H4, H5, H6);
> printf("\n");
>
> /* the whole example taken from the driver */
> /* with the cast as proposed by the documentation */
> var = ((int)t_fine) - (int)76800;
> var = adc_humidity << 14) - (H4 << 20) - (H5 * var))
> + (int)16384) >> 15) * (((var * H6) >> 10)
> * (((var * (int)H3) >> 11) + (int)32768)) >> 10)
> + (int)2097152) * H2 + 8192) >> 14);
> var -= var >> 15) * (var >> 15)) >> 7) * (int)H1) >> 4;
>
> printf("with cast:var: %d\n", var>>12);
> printf("\n");
>
> /* now the same calculation without the cast */
> var = (t_fine) - 76800;
> var = adc_humidity << 14) - (H4 << 20) - (H5 * var))
> + 16384) >> 15) * (((var * H6) >> 10)
> * (((var * H3) >> 11) + 32768)) >> 10)
> + 2097152) * H2 + 8192) >> 14);
> var -= var >> 15) * (var >> 15)) >> 7) * H1) >> 4;
>
> printf("without cast: var: %d\n", var>>12);
>
> return 0;
> }
>
> ---
>
> Output:
>
> with cast:-24544
> without cast: 4169760
>
> t_fine: 50623; humidity: 28275
> H: 75; 360; 0; 324; 0; 30
>
> with cast:var: 41671
>
> without cast: var: 124497
>
> ---
>
> Matt Ranostay  schrieb am Thu, 06. Apr 23:13:
>> On Mon, Apr 3, 2017 at 11:16 PM, Matt Ranostay
>>  wrote:
>> > On Sun, Apr 2, 2017 at 10:29 AM, Andreas Klinger  
>> > wrote:
>> >> Linus Walleij  schrieb am Sun, 02. Apr 16:56:
>> >>> On Sun, Apr 2, 2017 at 11:32 AM, Jonathan Cameron  
>> >>> wrote:
>> >>> > On 27/03/17 11:06, Andreas Klinger wrote:
>> >>> >> While calculating the compensation of the humidity there are negative
>> >>> >> values interpreted as unsigned because of unsigned variables used.
>> >>> >> These values need to be casted to signed as indicated by the 
>> >>> >> documentation
>> >>> >> of the sensor.
>> >>> >>
>> >>> >> Signed-off-by: Andreas Klinger 
>> >>> >
>> >>> > Looks superficially right to me, but would like an Ack from Linus 
>> >>> > Walleij.
>> >>>
>> >>> I didn't work on these calculations, only infrastructure for the driver
>> >>> but FWIW:
>> >>>

Re: [PATCH] IIO: bmp280-core.c: fix error in humidity calculation

[Matt Ranostay]

On Mon, Apr 3, 2017 at 11:16 PM, Matt Ranostay
<matt.ranos...@konsulko.com> wrote:
> On Sun, Apr 2, 2017 at 10:29 AM, Andreas Klinger <a...@it-klinger.de> wrote:
>> Linus Walleij <linus.wall...@linaro.org> schrieb am Sun, 02. Apr 16:56:
>>> On Sun, Apr 2, 2017 at 11:32 AM, Jonathan Cameron <ji...@kernel.org> wrote:
>>> > On 27/03/17 11:06, Andreas Klinger wrote:
>>> >> While calculating the compensation of the humidity there are negative
>>> >> values interpreted as unsigned because of unsigned variables used.
>>> >> These values need to be casted to signed as indicated by the 
>>> >> documentation
>>> >> of the sensor.
>>> >>
>>> >> Signed-off-by: Andreas Klinger <a...@it-klinger.de>
>>> >
>>> > Looks superficially right to me, but would like an Ack from Linus Walleij.
>>>
>>> I didn't work on these calculations, only infrastructure for the driver
>>> but FWIW:
>>> Acked-by: Linus Walleij <linus.wall...@linaro.org>
>>>
>>> Matt Ranostay @Intel is the person you probably want to ACK it though,
>>> he added the humidity calculations :)
>>
>> It just turned out that there must be another error in the calculation. I'll 
>> fix
>> and test it first.
>>
>> When i'm done i'll send a new version of the patch.
>>
>
> Ok will hold off till review till the next patchset... BTW this
> datasheet's calculations made my eyes bleed so it is quiet likely it
> has bugs...

Hmm the datatypes you are casting to s32 are already signed
integers...  Interested in what you found on what the actual bug is.

>
> Thanks,
>
> Matt
>
>> Andreas
>>
>>>
>>> Yours,
>>> Linus Walleij
>>
>> --
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] IIO: bmp280-core.c: fix error in humidity calculation

[Matt Ranostay]

On Mon, Apr 3, 2017 at 11:16 PM, Matt Ranostay
 wrote:
> On Sun, Apr 2, 2017 at 10:29 AM, Andreas Klinger  wrote:
>> Linus Walleij  schrieb am Sun, 02. Apr 16:56:
>>> On Sun, Apr 2, 2017 at 11:32 AM, Jonathan Cameron  wrote:
>>> > On 27/03/17 11:06, Andreas Klinger wrote:
>>> >> While calculating the compensation of the humidity there are negative
>>> >> values interpreted as unsigned because of unsigned variables used.
>>> >> These values need to be casted to signed as indicated by the 
>>> >> documentation
>>> >> of the sensor.
>>> >>
>>> >> Signed-off-by: Andreas Klinger 
>>> >
>>> > Looks superficially right to me, but would like an Ack from Linus Walleij.
>>>
>>> I didn't work on these calculations, only infrastructure for the driver
>>> but FWIW:
>>> Acked-by: Linus Walleij 
>>>
>>> Matt Ranostay @Intel is the person you probably want to ACK it though,
>>> he added the humidity calculations :)
>>
>> It just turned out that there must be another error in the calculation. I'll 
>> fix
>> and test it first.
>>
>> When i'm done i'll send a new version of the patch.
>>
>
> Ok will hold off till review till the next patchset... BTW this
> datasheet's calculations made my eyes bleed so it is quiet likely it
> has bugs...

Hmm the datatypes you are casting to s32 are already signed
integers...  Interested in what you found on what the actual bug is.

>
> Thanks,
>
> Matt
>
>> Andreas
>>
>>>
>>> Yours,
>>> Linus Walleij
>>
>> --
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] IIO: bmp280-core.c: fix error in humidity calculation

[Matt Ranostay]

On Sun, Apr 2, 2017 at 10:29 AM, Andreas Klinger <a...@it-klinger.de> wrote:
> Linus Walleij <linus.wall...@linaro.org> schrieb am Sun, 02. Apr 16:56:
>> On Sun, Apr 2, 2017 at 11:32 AM, Jonathan Cameron <ji...@kernel.org> wrote:
>> > On 27/03/17 11:06, Andreas Klinger wrote:
>> >> While calculating the compensation of the humidity there are negative
>> >> values interpreted as unsigned because of unsigned variables used.
>> >> These values need to be casted to signed as indicated by the documentation
>> >> of the sensor.
>> >>
>> >> Signed-off-by: Andreas Klinger <a...@it-klinger.de>
>> >
>> > Looks superficially right to me, but would like an Ack from Linus Walleij.
>>
>> I didn't work on these calculations, only infrastructure for the driver
>> but FWIW:
>> Acked-by: Linus Walleij <linus.wall...@linaro.org>
>>
>> Matt Ranostay @Intel is the person you probably want to ACK it though,
>> he added the humidity calculations :)
>
> It just turned out that there must be another error in the calculation. I'll 
> fix
> and test it first.
>
> When i'm done i'll send a new version of the patch.
>

Ok will hold off till review till the next patchset... BTW this
datasheet's calculations made my eyes bleed so it is quiet likely it
has bugs...

Thanks,

Matt

> Andreas
>
>>
>> Yours,
>> Linus Walleij
>
> --
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] IIO: bmp280-core.c: fix error in humidity calculation

[Matt Ranostay]

On Sun, Apr 2, 2017 at 10:29 AM, Andreas Klinger  wrote:
> Linus Walleij  schrieb am Sun, 02. Apr 16:56:
>> On Sun, Apr 2, 2017 at 11:32 AM, Jonathan Cameron  wrote:
>> > On 27/03/17 11:06, Andreas Klinger wrote:
>> >> While calculating the compensation of the humidity there are negative
>> >> values interpreted as unsigned because of unsigned variables used.
>> >> These values need to be casted to signed as indicated by the documentation
>> >> of the sensor.
>> >>
>> >> Signed-off-by: Andreas Klinger 
>> >
>> > Looks superficially right to me, but would like an Ack from Linus Walleij.
>>
>> I didn't work on these calculations, only infrastructure for the driver
>> but FWIW:
>> Acked-by: Linus Walleij 
>>
>> Matt Ranostay @Intel is the person you probably want to ACK it though,
>> he added the humidity calculations :)
>
> It just turned out that there must be another error in the calculation. I'll 
> fix
> and test it first.
>
> When i'm done i'll send a new version of the patch.
>

Ok will hold off till review till the next patchset... BTW this
datasheet's calculations made my eyes bleed so it is quiet likely it
has bugs...

Thanks,

Matt

> Andreas
>
>>
>> Yours,
>> Linus Walleij
>
> --
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RESEND 2/2] pps: fix padding issue with PPS_FETCH for ioctl_compat

[Matt Ranostay]

Issue is that x86 32-bit aligns to 4-bytes instead of 8-bytes
so this patchset works around the issue and corrects the data
returned in pps_fdata_compat.

Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Acked-by: Rodolfo Giometti <giome...@enneenne.com>
Signed-off-by: Matt Ranostay <matt.ranos...@konsulko.com>
---
 drivers/pps/pps.c| 110 ++-
 include/uapi/linux/pps.h |  19 
 2 files changed, 98 insertions(+), 31 deletions(-)

diff --git a/drivers/pps/pps.c b/drivers/pps/pps.c
index 452ead5a5e52..6eb0db37dd88 100644
--- a/drivers/pps/pps.c
+++ b/drivers/pps/pps.c
@@ -64,6 +64,43 @@ static int pps_cdev_fasync(int fd, struct file *file, int on)
return fasync_helper(fd, file, on, >async_queue);
 }
 
+static int pps_cdev_pps_fetch(struct pps_device *pps, struct pps_fdata *fdata)
+{
+   unsigned int ev = pps->last_ev;
+   int err = 0;
+
+   /* Manage the timeout */
+   if (fdata->timeout.flags & PPS_TIME_INVALID)
+   err = wait_event_interruptible(pps->queue,
+   ev != pps->last_ev);
+   else {
+   unsigned long ticks;
+
+   dev_dbg(pps->dev, "timeout %lld.%09d\n",
+   (long long) fdata->timeout.sec,
+   fdata->timeout.nsec);
+   ticks = fdata->timeout.sec * HZ;
+   ticks += fdata->timeout.nsec / (NSEC_PER_SEC / HZ);
+
+   if (ticks != 0) {
+   err = wait_event_interruptible_timeout(
+   pps->queue,
+   ev != pps->last_ev,
+   ticks);
+   if (err == 0)
+   return -ETIMEDOUT;
+   }
+   }
+
+   /* Check for pending signals */
+   if (err == -ERESTARTSYS) {
+   dev_dbg(pps->dev, "pending signal caught\n");
+   return -EINTR;
+   }
+
+   return 0;
+}
+
 static long pps_cdev_ioctl(struct file *file,
unsigned int cmd, unsigned long arg)
 {
@@ -144,7 +181,6 @@ static long pps_cdev_ioctl(struct file *file,
 
case PPS_FETCH: {
struct pps_fdata fdata;
-   unsigned int ev;
 
dev_dbg(pps->dev, "PPS_FETCH\n");
 
@@ -152,36 +188,9 @@ static long pps_cdev_ioctl(struct file *file,
if (err)
return -EFAULT;
 
-   ev = pps->last_ev;
-
-   /* Manage the timeout */
-   if (fdata.timeout.flags & PPS_TIME_INVALID)
-   err = wait_event_interruptible(pps->queue,
-   ev != pps->last_ev);
-   else {
-   unsigned long ticks;
-
-   dev_dbg(pps->dev, "timeout %lld.%09d\n",
-   (long long) fdata.timeout.sec,
-   fdata.timeout.nsec);
-   ticks = fdata.timeout.sec * HZ;
-   ticks += fdata.timeout.nsec / (NSEC_PER_SEC / HZ);
-
-   if (ticks != 0) {
-   err = wait_event_interruptible_timeout(
-   pps->queue,
-   ev != pps->last_ev,
-   ticks);
-   if (err == 0)
-   return -ETIMEDOUT;
-   }
-   }
-
-   /* Check for pending signals */
-   if (err == -ERESTARTSYS) {
-   dev_dbg(pps->dev, "pending signal caught\n");
-   return -EINTR;
-   }
+   err = pps_cdev_pps_fetch(pps, );
+   if (err)
+   return err;
 
/* Return the fetched timestamp */
spin_lock_irq(>lock);
@@ -246,8 +255,47 @@ static long pps_cdev_ioctl(struct file *file,
 static long pps_cdev_compat_ioctl(struct file *file,
unsigned int cmd, unsigned long arg)
 {
+   struct pps_device *pps = file->private_data;
+   void __user *uarg = (void __user *) arg;
+
cmd = _IOC(_IOC_DIR(cmd), _IOC_TYPE(cmd), _IOC_NR(cmd), sizeof(void *));
 
+   if (cmd == PPS_FETCH) {
+   struct pps_fdata_compat compat;
+   struct pps_fdata fdata;
+   int err;
+
+   dev_dbg(pps->dev, "PPS_FETCH\n");
+
+   err = copy_from_user(, uarg, sizeof(struct 
pps_fdata_compat));
+   if (err)
+   return -EFAULT;
+
+   memcpy(, ,
+   sizeof(struct p

[PATCH RESEND 2/2] pps: fix padding issue with PPS_FETCH for ioctl_compat

[Matt Ranostay]

Issue is that x86 32-bit aligns to 4-bytes instead of 8-bytes
so this patchset works around the issue and corrects the data
returned in pps_fdata_compat.

Cc: Greg Kroah-Hartman 
Acked-by: Rodolfo Giometti 
Signed-off-by: Matt Ranostay 
---
 drivers/pps/pps.c| 110 ++-
 include/uapi/linux/pps.h |  19 
 2 files changed, 98 insertions(+), 31 deletions(-)

diff --git a/drivers/pps/pps.c b/drivers/pps/pps.c
index 452ead5a5e52..6eb0db37dd88 100644
--- a/drivers/pps/pps.c
+++ b/drivers/pps/pps.c
@@ -64,6 +64,43 @@ static int pps_cdev_fasync(int fd, struct file *file, int on)
return fasync_helper(fd, file, on, >async_queue);
 }
 
+static int pps_cdev_pps_fetch(struct pps_device *pps, struct pps_fdata *fdata)
+{
+   unsigned int ev = pps->last_ev;
+   int err = 0;
+
+   /* Manage the timeout */
+   if (fdata->timeout.flags & PPS_TIME_INVALID)
+   err = wait_event_interruptible(pps->queue,
+   ev != pps->last_ev);
+   else {
+   unsigned long ticks;
+
+   dev_dbg(pps->dev, "timeout %lld.%09d\n",
+   (long long) fdata->timeout.sec,
+   fdata->timeout.nsec);
+   ticks = fdata->timeout.sec * HZ;
+   ticks += fdata->timeout.nsec / (NSEC_PER_SEC / HZ);
+
+   if (ticks != 0) {
+   err = wait_event_interruptible_timeout(
+   pps->queue,
+   ev != pps->last_ev,
+   ticks);
+   if (err == 0)
+   return -ETIMEDOUT;
+   }
+   }
+
+   /* Check for pending signals */
+   if (err == -ERESTARTSYS) {
+   dev_dbg(pps->dev, "pending signal caught\n");
+   return -EINTR;
+   }
+
+   return 0;
+}
+
 static long pps_cdev_ioctl(struct file *file,
unsigned int cmd, unsigned long arg)
 {
@@ -144,7 +181,6 @@ static long pps_cdev_ioctl(struct file *file,
 
case PPS_FETCH: {
struct pps_fdata fdata;
-   unsigned int ev;
 
dev_dbg(pps->dev, "PPS_FETCH\n");
 
@@ -152,36 +188,9 @@ static long pps_cdev_ioctl(struct file *file,
if (err)
return -EFAULT;
 
-   ev = pps->last_ev;
-
-   /* Manage the timeout */
-   if (fdata.timeout.flags & PPS_TIME_INVALID)
-   err = wait_event_interruptible(pps->queue,
-   ev != pps->last_ev);
-   else {
-   unsigned long ticks;
-
-   dev_dbg(pps->dev, "timeout %lld.%09d\n",
-   (long long) fdata.timeout.sec,
-   fdata.timeout.nsec);
-   ticks = fdata.timeout.sec * HZ;
-   ticks += fdata.timeout.nsec / (NSEC_PER_SEC / HZ);
-
-   if (ticks != 0) {
-   err = wait_event_interruptible_timeout(
-   pps->queue,
-   ev != pps->last_ev,
-   ticks);
-   if (err == 0)
-   return -ETIMEDOUT;
-   }
-   }
-
-   /* Check for pending signals */
-   if (err == -ERESTARTSYS) {
-   dev_dbg(pps->dev, "pending signal caught\n");
-   return -EINTR;
-   }
+   err = pps_cdev_pps_fetch(pps, );
+   if (err)
+   return err;
 
/* Return the fetched timestamp */
spin_lock_irq(>lock);
@@ -246,8 +255,47 @@ static long pps_cdev_ioctl(struct file *file,
 static long pps_cdev_compat_ioctl(struct file *file,
unsigned int cmd, unsigned long arg)
 {
+   struct pps_device *pps = file->private_data;
+   void __user *uarg = (void __user *) arg;
+
cmd = _IOC(_IOC_DIR(cmd), _IOC_TYPE(cmd), _IOC_NR(cmd), sizeof(void *));
 
+   if (cmd == PPS_FETCH) {
+   struct pps_fdata_compat compat;
+   struct pps_fdata fdata;
+   int err;
+
+   dev_dbg(pps->dev, "PPS_FETCH\n");
+
+   err = copy_from_user(, uarg, sizeof(struct 
pps_fdata_compat));
+   if (err)
+   return -EFAULT;
+
+   memcpy(, ,
+   sizeof(struct pps_ktime_compat));
+
+   err = pps_cdev_pps_fetch(pps, );
+

[PATCH RESEND 1/2] pps: add ioctl_compat function to correct ioctl definitions

[Matt Ranostay]

ioctl definitions use the pointer size of the architecture which
is fine when userspace and kernel are the same bitsize. This
patchset workarounds an issue with mixed bitsize kernel + userspace
by rewriting the cmd to the kernelspace architecture pointer size.

Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Acked-by: Rodolfo Giometti <giome...@enneenne.com>
Signed-off-by: Matt Ranostay <matt.ranos...@konsulko.com>
---
 drivers/pps/pps.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/pps/pps.c b/drivers/pps/pps.c
index 2f07cd615665..452ead5a5e52 100644
--- a/drivers/pps/pps.c
+++ b/drivers/pps/pps.c
@@ -242,6 +242,18 @@ static long pps_cdev_ioctl(struct file *file,
return 0;
 }
 
+#ifdef CONFIG_COMPAT
+static long pps_cdev_compat_ioctl(struct file *file,
+   unsigned int cmd, unsigned long arg)
+{
+   cmd = _IOC(_IOC_DIR(cmd), _IOC_TYPE(cmd), _IOC_NR(cmd), sizeof(void *));
+
+   return pps_cdev_ioctl(file, cmd, arg);
+}
+#else
+#define pps_cdev_compat_ioctl  NULL
+#endif
+
 static int pps_cdev_open(struct inode *inode, struct file *file)
 {
struct pps_device *pps = container_of(inode->i_cdev,
@@ -268,6 +280,7 @@ static const struct file_operations pps_cdev_fops = {
.llseek = no_llseek,
.poll   = pps_cdev_poll,
.fasync = pps_cdev_fasync,
+   .compat_ioctl   = pps_cdev_compat_ioctl,
.unlocked_ioctl = pps_cdev_ioctl,
.open   = pps_cdev_open,
.release= pps_cdev_release,
-- 
2.10.2

[PATCH RESEND 1/2] pps: add ioctl_compat function to correct ioctl definitions

[Matt Ranostay]

ioctl definitions use the pointer size of the architecture which
is fine when userspace and kernel are the same bitsize. This
patchset workarounds an issue with mixed bitsize kernel + userspace
by rewriting the cmd to the kernelspace architecture pointer size.

Cc: Greg Kroah-Hartman 
Acked-by: Rodolfo Giometti 
Signed-off-by: Matt Ranostay 
---
 drivers/pps/pps.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/pps/pps.c b/drivers/pps/pps.c
index 2f07cd615665..452ead5a5e52 100644
--- a/drivers/pps/pps.c
+++ b/drivers/pps/pps.c
@@ -242,6 +242,18 @@ static long pps_cdev_ioctl(struct file *file,
return 0;
 }
 
+#ifdef CONFIG_COMPAT
+static long pps_cdev_compat_ioctl(struct file *file,
+   unsigned int cmd, unsigned long arg)
+{
+   cmd = _IOC(_IOC_DIR(cmd), _IOC_TYPE(cmd), _IOC_NR(cmd), sizeof(void *));
+
+   return pps_cdev_ioctl(file, cmd, arg);
+}
+#else
+#define pps_cdev_compat_ioctl  NULL
+#endif
+
 static int pps_cdev_open(struct inode *inode, struct file *file)
 {
struct pps_device *pps = container_of(inode->i_cdev,
@@ -268,6 +280,7 @@ static const struct file_operations pps_cdev_fops = {
.llseek = no_llseek,
.poll   = pps_cdev_poll,
.fasync = pps_cdev_fasync,
+   .compat_ioctl   = pps_cdev_compat_ioctl,
.unlocked_ioctl = pps_cdev_ioctl,
.open   = pps_cdev_open,
.release= pps_cdev_release,
-- 
2.10.2

[PATCH RESEND 0/2] pps: add ioctl_compat support

[Matt Ranostay]

This series fixes issues with 32-bit userspace + 64-bit kernel data
structures, and along with fixing incorrect ioctl definitions in
a ABI stable way.

Changes from initial submission:
* add Rodolfo's Acked-by to patchsets
* add Greg K-H to Cc list, since there isn't a pps tree to merge in
  changes

Matt Ranostay (2):
  pps: add ioctl_compat function to correct ioctl definitions
  pps: fix padding issue with PPS_FETCH for ioctl_compat

 drivers/pps/pps.c| 123 +++
 include/uapi/linux/pps.h |  19 
 2 files changed, 111 insertions(+), 31 deletions(-)

-- 
2.10.2

[PATCH RESEND 0/2] pps: add ioctl_compat support

[Matt Ranostay]

This series fixes issues with 32-bit userspace + 64-bit kernel data
structures, and along with fixing incorrect ioctl definitions in
a ABI stable way.

Changes from initial submission:
* add Rodolfo's Acked-by to patchsets
* add Greg K-H to Cc list, since there isn't a pps tree to merge in
  changes

Matt Ranostay (2):
  pps: add ioctl_compat function to correct ioctl definitions
  pps: fix padding issue with PPS_FETCH for ioctl_compat

 drivers/pps/pps.c| 123 +++
 include/uapi/linux/pps.h |  19 
 2 files changed, 111 insertions(+), 31 deletions(-)

-- 
2.10.2

[PATCH 2/2] pps: fix padding issue with PPS_FETCH for ioctl_compat

[Matt Ranostay]

Issue is that x86 32-bit aligns to 4-bytes instead of 8-bytes
so this patchset works around the issue and corrects the data
returned in pps_fdata_compat.

Cc: Rodolfo Giometti <giome...@enneenne.com>
Cc: Moritz Fischer <m...@kernel.org>
Cc: George McCollister <george.mccollis...@gmail.com>
Signed-off-by: Matt Ranostay <matt.ranos...@konsulko.com>
---
 drivers/pps/pps.c| 110 ++-
 include/uapi/linux/pps.h |  19 
 2 files changed, 98 insertions(+), 31 deletions(-)

diff --git a/drivers/pps/pps.c b/drivers/pps/pps.c
index 452ead5a5e52..6eb0db37dd88 100644
--- a/drivers/pps/pps.c
+++ b/drivers/pps/pps.c
@@ -64,6 +64,43 @@ static int pps_cdev_fasync(int fd, struct file *file, int on)
return fasync_helper(fd, file, on, >async_queue);
 }
 
+static int pps_cdev_pps_fetch(struct pps_device *pps, struct pps_fdata *fdata)
+{
+   unsigned int ev = pps->last_ev;
+   int err = 0;
+
+   /* Manage the timeout */
+   if (fdata->timeout.flags & PPS_TIME_INVALID)
+   err = wait_event_interruptible(pps->queue,
+   ev != pps->last_ev);
+   else {
+   unsigned long ticks;
+
+   dev_dbg(pps->dev, "timeout %lld.%09d\n",
+   (long long) fdata->timeout.sec,
+   fdata->timeout.nsec);
+   ticks = fdata->timeout.sec * HZ;
+   ticks += fdata->timeout.nsec / (NSEC_PER_SEC / HZ);
+
+   if (ticks != 0) {
+   err = wait_event_interruptible_timeout(
+   pps->queue,
+   ev != pps->last_ev,
+   ticks);
+   if (err == 0)
+   return -ETIMEDOUT;
+   }
+   }
+
+   /* Check for pending signals */
+   if (err == -ERESTARTSYS) {
+   dev_dbg(pps->dev, "pending signal caught\n");
+   return -EINTR;
+   }
+
+   return 0;
+}
+
 static long pps_cdev_ioctl(struct file *file,
unsigned int cmd, unsigned long arg)
 {
@@ -144,7 +181,6 @@ static long pps_cdev_ioctl(struct file *file,
 
case PPS_FETCH: {
struct pps_fdata fdata;
-   unsigned int ev;
 
dev_dbg(pps->dev, "PPS_FETCH\n");
 
@@ -152,36 +188,9 @@ static long pps_cdev_ioctl(struct file *file,
if (err)
return -EFAULT;
 
-   ev = pps->last_ev;
-
-   /* Manage the timeout */
-   if (fdata.timeout.flags & PPS_TIME_INVALID)
-   err = wait_event_interruptible(pps->queue,
-   ev != pps->last_ev);
-   else {
-   unsigned long ticks;
-
-   dev_dbg(pps->dev, "timeout %lld.%09d\n",
-   (long long) fdata.timeout.sec,
-   fdata.timeout.nsec);
-   ticks = fdata.timeout.sec * HZ;
-   ticks += fdata.timeout.nsec / (NSEC_PER_SEC / HZ);
-
-   if (ticks != 0) {
-   err = wait_event_interruptible_timeout(
-   pps->queue,
-   ev != pps->last_ev,
-   ticks);
-   if (err == 0)
-   return -ETIMEDOUT;
-   }
-   }
-
-   /* Check for pending signals */
-   if (err == -ERESTARTSYS) {
-   dev_dbg(pps->dev, "pending signal caught\n");
-   return -EINTR;
-   }
+   err = pps_cdev_pps_fetch(pps, );
+   if (err)
+   return err;
 
/* Return the fetched timestamp */
spin_lock_irq(>lock);
@@ -246,8 +255,47 @@ static long pps_cdev_ioctl(struct file *file,
 static long pps_cdev_compat_ioctl(struct file *file,
unsigned int cmd, unsigned long arg)
 {
+   struct pps_device *pps = file->private_data;
+   void __user *uarg = (void __user *) arg;
+
cmd = _IOC(_IOC_DIR(cmd), _IOC_TYPE(cmd), _IOC_NR(cmd), sizeof(void *));
 
+   if (cmd == PPS_FETCH) {
+   struct pps_fdata_compat compat;
+   struct pps_fdata fdata;
+   int err;
+
+   dev_dbg(pps->dev, "PPS_FETCH\n");
+
+   err = copy_from_user(, uarg, sizeof(struct 
pps_fdata_compat));
+   if (err)
+   return -EFAULT;
+
+   memcpy(, ,
+   

[PATCH 2/2] pps: fix padding issue with PPS_FETCH for ioctl_compat

[Matt Ranostay]

Issue is that x86 32-bit aligns to 4-bytes instead of 8-bytes
so this patchset works around the issue and corrects the data
returned in pps_fdata_compat.

Cc: Rodolfo Giometti 
Cc: Moritz Fischer 
Cc: George McCollister 
Signed-off-by: Matt Ranostay 
---
 drivers/pps/pps.c| 110 ++-
 include/uapi/linux/pps.h |  19 
 2 files changed, 98 insertions(+), 31 deletions(-)

diff --git a/drivers/pps/pps.c b/drivers/pps/pps.c
index 452ead5a5e52..6eb0db37dd88 100644
--- a/drivers/pps/pps.c
+++ b/drivers/pps/pps.c
@@ -64,6 +64,43 @@ static int pps_cdev_fasync(int fd, struct file *file, int on)
return fasync_helper(fd, file, on, >async_queue);
 }
 
+static int pps_cdev_pps_fetch(struct pps_device *pps, struct pps_fdata *fdata)
+{
+   unsigned int ev = pps->last_ev;
+   int err = 0;
+
+   /* Manage the timeout */
+   if (fdata->timeout.flags & PPS_TIME_INVALID)
+   err = wait_event_interruptible(pps->queue,
+   ev != pps->last_ev);
+   else {
+   unsigned long ticks;
+
+   dev_dbg(pps->dev, "timeout %lld.%09d\n",
+   (long long) fdata->timeout.sec,
+   fdata->timeout.nsec);
+   ticks = fdata->timeout.sec * HZ;
+   ticks += fdata->timeout.nsec / (NSEC_PER_SEC / HZ);
+
+   if (ticks != 0) {
+   err = wait_event_interruptible_timeout(
+   pps->queue,
+   ev != pps->last_ev,
+   ticks);
+   if (err == 0)
+   return -ETIMEDOUT;
+   }
+   }
+
+   /* Check for pending signals */
+   if (err == -ERESTARTSYS) {
+   dev_dbg(pps->dev, "pending signal caught\n");
+   return -EINTR;
+   }
+
+   return 0;
+}
+
 static long pps_cdev_ioctl(struct file *file,
unsigned int cmd, unsigned long arg)
 {
@@ -144,7 +181,6 @@ static long pps_cdev_ioctl(struct file *file,
 
case PPS_FETCH: {
struct pps_fdata fdata;
-   unsigned int ev;
 
dev_dbg(pps->dev, "PPS_FETCH\n");
 
@@ -152,36 +188,9 @@ static long pps_cdev_ioctl(struct file *file,
if (err)
return -EFAULT;
 
-   ev = pps->last_ev;
-
-   /* Manage the timeout */
-   if (fdata.timeout.flags & PPS_TIME_INVALID)
-   err = wait_event_interruptible(pps->queue,
-   ev != pps->last_ev);
-   else {
-   unsigned long ticks;
-
-   dev_dbg(pps->dev, "timeout %lld.%09d\n",
-   (long long) fdata.timeout.sec,
-   fdata.timeout.nsec);
-   ticks = fdata.timeout.sec * HZ;
-   ticks += fdata.timeout.nsec / (NSEC_PER_SEC / HZ);
-
-   if (ticks != 0) {
-   err = wait_event_interruptible_timeout(
-   pps->queue,
-   ev != pps->last_ev,
-   ticks);
-   if (err == 0)
-   return -ETIMEDOUT;
-   }
-   }
-
-   /* Check for pending signals */
-   if (err == -ERESTARTSYS) {
-   dev_dbg(pps->dev, "pending signal caught\n");
-   return -EINTR;
-   }
+   err = pps_cdev_pps_fetch(pps, );
+   if (err)
+   return err;
 
/* Return the fetched timestamp */
spin_lock_irq(>lock);
@@ -246,8 +255,47 @@ static long pps_cdev_ioctl(struct file *file,
 static long pps_cdev_compat_ioctl(struct file *file,
unsigned int cmd, unsigned long arg)
 {
+   struct pps_device *pps = file->private_data;
+   void __user *uarg = (void __user *) arg;
+
cmd = _IOC(_IOC_DIR(cmd), _IOC_TYPE(cmd), _IOC_NR(cmd), sizeof(void *));
 
+   if (cmd == PPS_FETCH) {
+   struct pps_fdata_compat compat;
+   struct pps_fdata fdata;
+   int err;
+
+   dev_dbg(pps->dev, "PPS_FETCH\n");
+
+   err = copy_from_user(, uarg, sizeof(struct 
pps_fdata_compat));
+   if (err)
+   return -EFAULT;
+
+   memcpy(, ,
+   sizeof(struct pps_ktime_compat));
+
+   err = pps_cdev_pps_fetch(pps, );
+

[PATCH 1/2] pps: add ioctl_compat function to correct ioctl definitions

[Matt Ranostay]

ioctl definitions use the pointer size of the architecture which
is fine when userspace and kernel are the same bitsize. This
patchset workarounds an issue with mixed bitsize kernel + userspace
by rewriting the cmd to the kernelspace architecture pointer size.

Cc: Rodolfo Giometti <giome...@enneenne.com>
Cc: Moritz Fischer <m...@kernel.org>
Cc: George McCollister <george.mccollis...@gmail.com>
Signed-off-by: Matt Ranostay <matt.ranos...@konsulko.com>
---
 drivers/pps/pps.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/pps/pps.c b/drivers/pps/pps.c
index 2f07cd615665..452ead5a5e52 100644
--- a/drivers/pps/pps.c
+++ b/drivers/pps/pps.c
@@ -242,6 +242,18 @@ static long pps_cdev_ioctl(struct file *file,
return 0;
 }
 
+#ifdef CONFIG_COMPAT
+static long pps_cdev_compat_ioctl(struct file *file,
+   unsigned int cmd, unsigned long arg)
+{
+   cmd = _IOC(_IOC_DIR(cmd), _IOC_TYPE(cmd), _IOC_NR(cmd), sizeof(void *));
+
+   return pps_cdev_ioctl(file, cmd, arg);
+}
+#else
+#define pps_cdev_compat_ioctl  NULL
+#endif
+
 static int pps_cdev_open(struct inode *inode, struct file *file)
 {
struct pps_device *pps = container_of(inode->i_cdev,
@@ -268,6 +280,7 @@ static const struct file_operations pps_cdev_fops = {
.llseek = no_llseek,
.poll   = pps_cdev_poll,
.fasync = pps_cdev_fasync,
+   .compat_ioctl   = pps_cdev_compat_ioctl,
.unlocked_ioctl = pps_cdev_ioctl,
.open   = pps_cdev_open,
.release= pps_cdev_release,
-- 
2.10.2

[PATCH 1/2] pps: add ioctl_compat function to correct ioctl definitions

[Matt Ranostay]

ioctl definitions use the pointer size of the architecture which
is fine when userspace and kernel are the same bitsize. This
patchset workarounds an issue with mixed bitsize kernel + userspace
by rewriting the cmd to the kernelspace architecture pointer size.

Cc: Rodolfo Giometti 
Cc: Moritz Fischer 
Cc: George McCollister 
Signed-off-by: Matt Ranostay 
---
 drivers/pps/pps.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/pps/pps.c b/drivers/pps/pps.c
index 2f07cd615665..452ead5a5e52 100644
--- a/drivers/pps/pps.c
+++ b/drivers/pps/pps.c
@@ -242,6 +242,18 @@ static long pps_cdev_ioctl(struct file *file,
return 0;
 }
 
+#ifdef CONFIG_COMPAT
+static long pps_cdev_compat_ioctl(struct file *file,
+   unsigned int cmd, unsigned long arg)
+{
+   cmd = _IOC(_IOC_DIR(cmd), _IOC_TYPE(cmd), _IOC_NR(cmd), sizeof(void *));
+
+   return pps_cdev_ioctl(file, cmd, arg);
+}
+#else
+#define pps_cdev_compat_ioctl  NULL
+#endif
+
 static int pps_cdev_open(struct inode *inode, struct file *file)
 {
struct pps_device *pps = container_of(inode->i_cdev,
@@ -268,6 +280,7 @@ static const struct file_operations pps_cdev_fops = {
.llseek = no_llseek,
.poll   = pps_cdev_poll,
.fasync = pps_cdev_fasync,
+   .compat_ioctl   = pps_cdev_compat_ioctl,
.unlocked_ioctl = pps_cdev_ioctl,
.open   = pps_cdev_open,
.release= pps_cdev_release,
-- 
2.10.2

[PATCH 0/2] pps: add ioctl_compat support

[Matt Ranostay]

This series fixes issues with 32-bit userspace + 64-bit kernel data
structures, and along with fixing incorrect ioctl definitions in
a ABI stable way

Matt Ranostay (2):
  pps: add ioctl_compat function to correct ioctl definitions
  pps: fix padding issue with PPS_FETCH for ioctl_compat

 drivers/pps/pps.c| 123 +++
 include/uapi/linux/pps.h |  19 
 2 files changed, 111 insertions(+), 31 deletions(-)

-- 
2.10.2

[PATCH 0/2] pps: add ioctl_compat support

[Matt Ranostay]

This series fixes issues with 32-bit userspace + 64-bit kernel data
structures, and along with fixing incorrect ioctl definitions in
a ABI stable way

Matt Ranostay (2):
  pps: add ioctl_compat function to correct ioctl definitions
  pps: fix padding issue with PPS_FETCH for ioctl_compat

 drivers/pps/pps.c| 123 +++
 include/uapi/linux/pps.h |  19 
 2 files changed, 111 insertions(+), 31 deletions(-)

-- 
2.10.2

Re: [PATCH 2/4] iio: chemical: add driver for dsm501/ppd42ns particle sensors

[Matt Ranostay]

> On Feb 5, 2017, at 08:24, Tomasz Duszynski  wrote:
> 
> Thanks for review!
> 
>> On Sun, Feb 05, 2017 at 04:19:47PM +0100, Peter Meerwald-Stadler wrote:
>> 
>>> This patch adds support for dsm501 and ppd42ns particle sensors.
>> 
>> quick comments below
>> G
>>> Both sensors work on the same principle. Heater (resistor) heats up air
>>> in sensor chamber which induces upward flow. Particles convect up through
>>> a light beam provided by internal infra-red LED. Light scattered by
>>> particles is picked by photodiode and internal electronics outputs PWM
>>> signal.
>>> 
>>> Measuring low time occupancy of the signal during 30s measurement period
>>> particles number in cubic meter can be computed.
>>> 

This a SI unit?

Also this maybe could be better off in drivers/iio/light... as much I like to 
have other people in drivers/iio/chemical 
>>> Signed-off-by: Tomasz Duszynski 
>>> ---
>>> drivers/iio/chemical/Kconfig  |  10 ++
>>> drivers/iio/chemical/Makefile |   1 +
>>> drivers/iio/chemical/dsm501.c | 231 
>>> ++
>>> 3 files changed, 242 insertions(+)
>>> create mode 100644 drivers/iio/chemical/dsm501.c
>>> 
>>> diff --git a/drivers/iio/chemical/Kconfig b/drivers/iio/chemical/Kconfig
>>> index cea7f9857a1f..986d612aa77f 100644
>>> --- a/drivers/iio/chemical/Kconfig
>>> +++ b/drivers/iio/chemical/Kconfig
>>> @@ -21,6 +21,16 @@ config ATLAS_PH_SENSOR
>>> To compile this driver as module, choose M here: the
>>> module will be called atlas-ph-sensor.
>>> 
>>> +config DSM501
>>> +tristate "Samyoung DSM501 particle sensor"
>>> +depends on GPIOLIB
>>> +help
>>> + Say yes here to build support for the Samyoung DSM501
>>> + particle sensor.
>>> +
>>> + To compile this driver as a module, choose M here: the module
>>> + will be called dsm501.
>>> +
>>> config IAQCORE
>>>tristate "AMS iAQ-Core VOC sensors"
>>>depends on I2C
>>> diff --git a/drivers/iio/chemical/Makefile b/drivers/iio/chemical/Makefile
>>> index b02202b41289..76f50ff8ba7d 100644
>>> --- a/drivers/iio/chemical/Makefile
>>> +++ b/drivers/iio/chemical/Makefile
>>> @@ -4,5 +4,6 @@
>>> 
>>> # When adding new entries keep the list in alphabetical order
>>> obj-$(CONFIG_ATLAS_PH_SENSOR)+= atlas-ph-sensor.o
>>> +obj-$(CONFIG_DSM501)+= dsm501.o
>>> obj-$(CONFIG_IAQCORE)+= ams-iaq-core.o
>>> obj-$(CONFIG_VZ89X)+= vz89x.o
>>> diff --git a/drivers/iio/chemical/dsm501.c b/drivers/iio/chemical/dsm501.c
>>> new file mode 100644
>>> index ..013f6b3bfd48
>>> --- /dev/null
>>> +++ b/drivers/iio/chemical/dsm501.c
>>> @@ -0,0 +1,231 @@
>>> +/*
>>> + * Samyoung DSM501 particle sensor driver
>>> + *
>>> + * Copyright (C) 2017 Tomasz Duszynski 
>>> + *
>>> + * Datasheets:
>>> + *  http://www.samyoungsnc.com/products/3-1%20Specification%20DSM501.pdf
>>> + *  http://wiki.timelab.org/images/f/f9/PPD42NS.pdf
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation; either version 2 of the License, or
>>> + * (at your option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#define DSM501_DRV_NAME "dsm501"
>>> +#defineDSM501_IRQ_NAME "dsm501_irq"
>> 
>> replace tab by space
> Ack.
>> 
>>> +
>>> +#define DSM501_DEFAULT_MEASUREMENT_TIME 30 /* seconds */
>>> +
>>> +struct dsm501_data {
>>> +ktime_t ts;
>>> +ktime_t low_time;
>>> +ktime_t meas_time;
>>> +
>>> +int irq;
>>> +struct gpio_desc *gpio;
>>> +
>>> +struct mutex lock;
>>> +
>>> +int (*number_concentration)(struct dsm501_data *data);
>>> +};
>>> +
>>> +/*
>>> + * Series of data points in Fig. 8-3 (Low Ratio vs Particle)
>>> + * can be approximated by following polynomials:
>>> + *
>>> + * p(r) = 0 (undefined) for r < 4
>>> + * p(r) = 2353564.2r - 4373814.7 for 4 <= r < 20
>>> + * p(r) = 4788112.4r - 53581390 for r >= 20
>>> + *
>>> + * Note: Result is in pcs/m3. To convert to pcs/0.01cf multiply
>>> + * by 0.0002831685.
>> 
>> is cf needed?
> No. I've put that sidenote so that others looking at figures in
> datahseets won't scratch their heads why units here are pcs/m3 and
> pcs/0.01cf there. Anyway I am happy to drop that part.
>> 
>>> + */
>>> +static int dsm501_number_concentartion(struct dsm501_data *data)
>>> +{
>>> +s64 retval = 0, r = div64_s64(ktime_to_ns(data->low_time) * 100,
>>> +  

Re: [PATCH 2/4] iio: chemical: add driver for dsm501/ppd42ns particle sensors

[Matt Ranostay]

> On Feb 5, 2017, at 08:24, Tomasz Duszynski  wrote:
> 
> Thanks for review!
> 
>> On Sun, Feb 05, 2017 at 04:19:47PM +0100, Peter Meerwald-Stadler wrote:
>> 
>>> This patch adds support for dsm501 and ppd42ns particle sensors.
>> 
>> quick comments below
>> G
>>> Both sensors work on the same principle. Heater (resistor) heats up air
>>> in sensor chamber which induces upward flow. Particles convect up through
>>> a light beam provided by internal infra-red LED. Light scattered by
>>> particles is picked by photodiode and internal electronics outputs PWM
>>> signal.
>>> 
>>> Measuring low time occupancy of the signal during 30s measurement period
>>> particles number in cubic meter can be computed.
>>> 

This a SI unit?

Also this maybe could be better off in drivers/iio/light... as much I like to 
have other people in drivers/iio/chemical 
>>> Signed-off-by: Tomasz Duszynski 
>>> ---
>>> drivers/iio/chemical/Kconfig  |  10 ++
>>> drivers/iio/chemical/Makefile |   1 +
>>> drivers/iio/chemical/dsm501.c | 231 
>>> ++
>>> 3 files changed, 242 insertions(+)
>>> create mode 100644 drivers/iio/chemical/dsm501.c
>>> 
>>> diff --git a/drivers/iio/chemical/Kconfig b/drivers/iio/chemical/Kconfig
>>> index cea7f9857a1f..986d612aa77f 100644
>>> --- a/drivers/iio/chemical/Kconfig
>>> +++ b/drivers/iio/chemical/Kconfig
>>> @@ -21,6 +21,16 @@ config ATLAS_PH_SENSOR
>>> To compile this driver as module, choose M here: the
>>> module will be called atlas-ph-sensor.
>>> 
>>> +config DSM501
>>> +tristate "Samyoung DSM501 particle sensor"
>>> +depends on GPIOLIB
>>> +help
>>> + Say yes here to build support for the Samyoung DSM501
>>> + particle sensor.
>>> +
>>> + To compile this driver as a module, choose M here: the module
>>> + will be called dsm501.
>>> +
>>> config IAQCORE
>>>tristate "AMS iAQ-Core VOC sensors"
>>>depends on I2C
>>> diff --git a/drivers/iio/chemical/Makefile b/drivers/iio/chemical/Makefile
>>> index b02202b41289..76f50ff8ba7d 100644
>>> --- a/drivers/iio/chemical/Makefile
>>> +++ b/drivers/iio/chemical/Makefile
>>> @@ -4,5 +4,6 @@
>>> 
>>> # When adding new entries keep the list in alphabetical order
>>> obj-$(CONFIG_ATLAS_PH_SENSOR)+= atlas-ph-sensor.o
>>> +obj-$(CONFIG_DSM501)+= dsm501.o
>>> obj-$(CONFIG_IAQCORE)+= ams-iaq-core.o
>>> obj-$(CONFIG_VZ89X)+= vz89x.o
>>> diff --git a/drivers/iio/chemical/dsm501.c b/drivers/iio/chemical/dsm501.c
>>> new file mode 100644
>>> index ..013f6b3bfd48
>>> --- /dev/null
>>> +++ b/drivers/iio/chemical/dsm501.c
>>> @@ -0,0 +1,231 @@
>>> +/*
>>> + * Samyoung DSM501 particle sensor driver
>>> + *
>>> + * Copyright (C) 2017 Tomasz Duszynski 
>>> + *
>>> + * Datasheets:
>>> + *  http://www.samyoungsnc.com/products/3-1%20Specification%20DSM501.pdf
>>> + *  http://wiki.timelab.org/images/f/f9/PPD42NS.pdf
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation; either version 2 of the License, or
>>> + * (at your option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#define DSM501_DRV_NAME "dsm501"
>>> +#defineDSM501_IRQ_NAME "dsm501_irq"
>> 
>> replace tab by space
> Ack.
>> 
>>> +
>>> +#define DSM501_DEFAULT_MEASUREMENT_TIME 30 /* seconds */
>>> +
>>> +struct dsm501_data {
>>> +ktime_t ts;
>>> +ktime_t low_time;
>>> +ktime_t meas_time;
>>> +
>>> +int irq;
>>> +struct gpio_desc *gpio;
>>> +
>>> +struct mutex lock;
>>> +
>>> +int (*number_concentration)(struct dsm501_data *data);
>>> +};
>>> +
>>> +/*
>>> + * Series of data points in Fig. 8-3 (Low Ratio vs Particle)
>>> + * can be approximated by following polynomials:
>>> + *
>>> + * p(r) = 0 (undefined) for r < 4
>>> + * p(r) = 2353564.2r - 4373814.7 for 4 <= r < 20
>>> + * p(r) = 4788112.4r - 53581390 for r >= 20
>>> + *
>>> + * Note: Result is in pcs/m3. To convert to pcs/0.01cf multiply
>>> + * by 0.0002831685.
>> 
>> is cf needed?
> No. I've put that sidenote so that others looking at figures in
> datahseets won't scratch their heads why units here are pcs/m3 and
> pcs/0.01cf there. Anyway I am happy to drop that part.
>> 
>>> + */
>>> +static int dsm501_number_concentartion(struct dsm501_data *data)
>>> +{
>>> +s64 retval = 0, r = div64_s64(ktime_to_ns(data->low_time) * 100,
>>> +  ktime_to_ns(data->meas_time));
>>> +
>>> +if (r >= 4 && r < 20)
>>> +retval = 

[PATCH] mailmap: Change email to new Konsulko email

[Matt Ranostay]

Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
---
 .mailmap | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.mailmap b/.mailmap
index 67dc22ffc9a8..e775f792d436 100644
--- a/.mailmap
+++ b/.mailmap
@@ -109,6 +109,7 @@ Mauro Carvalho Chehab <mche...@kernel.org> 
<mche...@osg.samsung.com>
 Mauro Carvalho Chehab <mche...@kernel.org> <mche...@s-opensource.com>
 Matt Ranostay <mranos...@gmail.com> Matthew Ranostay 
<mranos...@embeddedalley.com>
 Matt Ranostay <mranos...@gmail.com> <matt.ranos...@intel.com>
+Matt Ranostay <matt.ranos...@konsulko.com> <matt@ranostay.consulting>
 Mayuresh Janorkar <ma...@ti.com>
 Michael Buesch <m...@bues.ch>
 Michel Dänzer <mic...@tungstengraphics.com>
-- 
2.10.2

[PATCH] mailmap: Change email to new Konsulko email

[Matt Ranostay]

Signed-off-by: Matt Ranostay 
---
 .mailmap | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.mailmap b/.mailmap
index 67dc22ffc9a8..e775f792d436 100644
--- a/.mailmap
+++ b/.mailmap
@@ -109,6 +109,7 @@ Mauro Carvalho Chehab  

 Mauro Carvalho Chehab  
 Matt Ranostay  Matthew Ranostay 

 Matt Ranostay  
+Matt Ranostay  
 Mayuresh Janorkar 
 Michael Buesch 
 Michel Dänzer 
-- 
2.10.2

Re: [PATCH v3 1/2] devicetree: document new marvell-8xxx and pwrseq-sd8787 options

[Matt Ranostay]

On Mon, Jan 23, 2017 at 9:04 AM, Rob Herring <r...@kernel.org> wrote:
> On Fri, Jan 20, 2017 at 09:50:38PM -0800, Matt Ranostay wrote:
>> Cc: devicet...@vger.kernel.org
>> Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
>> ---
>>  .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt  | 14 
>> ++
>>  .../devicetree/bindings/net/wireless/marvell-8xxx.txt  |  7 ++-
>>  2 files changed, 20 insertions(+), 1 deletion(-)
>>  create mode 100644 
>> Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt 
>> b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>> new file mode 100644
>> index ..4bb56766982e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>> @@ -0,0 +1,14 @@
>> +* Marvell SD8787 power sequence provider
>> +
>> +Required properties:
>> +- compatible: must be "mmc-pwrseq-sd8787".
>> +- powerdown-gpio: contains a power down GPIO specifier with active state
>> +- reset-gpio: contains a reset GPIO specifier with active state
>
> My comments on the previous v3 still apply.

Ah yikes.. forgot to increment the patchset.  And noticed the gpio
isn't gpios... will fixed in "v4"

Thanks,

Matt

>
>> +
>> +Example:
>> +
>> + wifi_pwrseq: wifi_pwrseq {
>> + compatible = "mmc-pwrseq-sd8787";
>> + powerdown-gpio = <_gpio 0 GPIO_ACTIVE_LOW>;
>> + reset-gpio = <_gpio 1 GPIO_ACTIVE_LOW>;
>> + }

Re: [PATCH v3 1/2] devicetree: document new marvell-8xxx and pwrseq-sd8787 options

[Matt Ranostay]

On Mon, Jan 23, 2017 at 9:04 AM, Rob Herring  wrote:
> On Fri, Jan 20, 2017 at 09:50:38PM -0800, Matt Ranostay wrote:
>> Cc: devicet...@vger.kernel.org
>> Signed-off-by: Matt Ranostay 
>> ---
>>  .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt  | 14 
>> ++
>>  .../devicetree/bindings/net/wireless/marvell-8xxx.txt  |  7 ++-
>>  2 files changed, 20 insertions(+), 1 deletion(-)
>>  create mode 100644 
>> Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt 
>> b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>> new file mode 100644
>> index ..4bb56766982e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>> @@ -0,0 +1,14 @@
>> +* Marvell SD8787 power sequence provider
>> +
>> +Required properties:
>> +- compatible: must be "mmc-pwrseq-sd8787".
>> +- powerdown-gpio: contains a power down GPIO specifier with active state
>> +- reset-gpio: contains a reset GPIO specifier with active state
>
> My comments on the previous v3 still apply.

Ah yikes.. forgot to increment the patchset.  And noticed the gpio
isn't gpios... will fixed in "v4"

Thanks,

Matt

>
>> +
>> +Example:
>> +
>> + wifi_pwrseq: wifi_pwrseq {
>> + compatible = "mmc-pwrseq-sd8787";
>> + powerdown-gpio = <_gpio 0 GPIO_ACTIVE_LOW>;
>> + reset-gpio = <_gpio 1 GPIO_ACTIVE_LOW>;
>> + }

[PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
This can be abstracted to other chipsets if needed in the future.

Cc: Tony Lindgren <t...@atomide.com>
Cc: Ulf Hansson <ulf.hans...@linaro.org>
Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
---
 drivers/mmc/core/Kconfig |  10 
 drivers/mmc/core/Makefile|   1 +
 drivers/mmc/core/pwrseq_sd8787.c | 117 +++
 3 files changed, 128 insertions(+)
 create mode 100644 drivers/mmc/core/pwrseq_sd8787.c

diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index cdfa8520a4b1..fc1ecdaaa9ca 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -12,6 +12,16 @@ config PWRSEQ_EMMC
  This driver can also be built as a module. If so, the module
  will be called pwrseq_emmc.
 
+config PWRSEQ_SD8787
+   tristate "HW reset support for SD8787 BT + Wifi module"
+   depends on OF && (MWIFIEX || BT_MRVL_SDIO)
+   help
+ This selects hardware reset support for the SD8787 BT + Wifi
+ module. By default this option is set to n.
+
+ This driver can also be built as a module. If so, the module
+ will be called pwrseq_sd8787.
+
 config PWRSEQ_SIMPLE
tristate "Simple HW reset support for MMC"
default y
diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
index b2a257dc644f..0f81464fa824 100644
--- a/drivers/mmc/core/Makefile
+++ b/drivers/mmc/core/Makefile
@@ -10,6 +10,7 @@ mmc_core-y:= core.o bus.o host.o \
   quirks.o slot-gpio.o
 mmc_core-$(CONFIG_OF)  += pwrseq.o
 obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o
+obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o
 obj-$(CONFIG_PWRSEQ_EMMC)  += pwrseq_emmc.o
 mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
 obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o
diff --git a/drivers/mmc/core/pwrseq_sd8787.c b/drivers/mmc/core/pwrseq_sd8787.c
new file mode 100644
index ..1a21e14458d3
--- /dev/null
+++ b/drivers/mmc/core/pwrseq_sd8787.c
@@ -0,0 +1,117 @@
+/*
+ * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT + Wifi chip
+ *
+ * Copyright (C) 2016 Matt Ranostay <matt@ranostay.consulting>
+ *
+ * Based on the original work pwrseq_simple.c
+ *  Copyright (C) 2014 Linaro Ltd
+ *  Author: Ulf Hansson <ulf.hans...@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "pwrseq.h"
+
+struct mmc_pwrseq_sd8787 {
+   struct mmc_pwrseq pwrseq;
+   struct gpio_desc *reset_gpio;
+   struct gpio_desc *pwrdn_gpio;
+};
+
+#define to_pwrseq_sd8787(p) container_of(p, struct mmc_pwrseq_sd8787, pwrseq)
+
+static void mmc_pwrseq_sd8787_pre_power_on(struct mmc_host *host)
+{
+   struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
+
+   gpiod_set_value_cansleep(pwrseq->reset_gpio, 1);
+
+   msleep(300);
+   gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 1);
+}
+
+static void mmc_pwrseq_sd8787_power_off(struct mmc_host *host)
+{
+   struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
+
+   gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 0);
+   gpiod_set_value_cansleep(pwrseq->reset_gpio, 0);
+}
+
+static const struct mmc_pwrseq_ops mmc_pwrseq_sd8787_ops = {
+   .pre_power_on = mmc_pwrseq_sd8787_pre_power_on,
+   .power_off = mmc_pwrseq_sd8787_power_off,
+};
+
+static const struct of_device_id mmc_pwrseq_sd8787_of_match[] = {
+   { .compatible = "mmc-pwrseq-sd8787",},
+   {/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, mmc_pwrseq_sd8787_of_match);
+
+static int mmc_pwrseq_sd8787_probe(struct platform_device *pdev)
+{
+   struct mmc_pwrseq_sd8787 *pwrseq;
+   struct device *dev = >dev;
+
+   pwrseq = devm_kzalloc(dev, sizeof(*pwrseq), GFP_KERNEL);
+   if (!pwrseq)
+   return -ENOMEM;
+
+   pwrseq->pwrdn_gpio = devm_gpiod_get(dev, "powerdown", GPIOD_OUT_LOW);
+   if (IS_ERR(pwrseq->pwrdn_gpio))
+   return PTR_ERR(pwrseq->pwrdn_gpio);
+
+   pwrseq->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
+   if (IS_ERR(pwrseq->reset_gpio))
+   return PTR_ERR(pwrseq->reset_gpio);
+
+   pwrseq->pwrseq.dev =

[PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
This can be abstracted to other chipsets if needed in the future.

Cc: Tony Lindgren 
Cc: Ulf Hansson 
Signed-off-by: Matt Ranostay 
---
 drivers/mmc/core/Kconfig |  10 
 drivers/mmc/core/Makefile|   1 +
 drivers/mmc/core/pwrseq_sd8787.c | 117 +++
 3 files changed, 128 insertions(+)
 create mode 100644 drivers/mmc/core/pwrseq_sd8787.c

diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index cdfa8520a4b1..fc1ecdaaa9ca 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -12,6 +12,16 @@ config PWRSEQ_EMMC
  This driver can also be built as a module. If so, the module
  will be called pwrseq_emmc.
 
+config PWRSEQ_SD8787
+   tristate "HW reset support for SD8787 BT + Wifi module"
+   depends on OF && (MWIFIEX || BT_MRVL_SDIO)
+   help
+ This selects hardware reset support for the SD8787 BT + Wifi
+ module. By default this option is set to n.
+
+ This driver can also be built as a module. If so, the module
+ will be called pwrseq_sd8787.
+
 config PWRSEQ_SIMPLE
tristate "Simple HW reset support for MMC"
default y
diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
index b2a257dc644f..0f81464fa824 100644
--- a/drivers/mmc/core/Makefile
+++ b/drivers/mmc/core/Makefile
@@ -10,6 +10,7 @@ mmc_core-y:= core.o bus.o host.o \
   quirks.o slot-gpio.o
 mmc_core-$(CONFIG_OF)  += pwrseq.o
 obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o
+obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o
 obj-$(CONFIG_PWRSEQ_EMMC)  += pwrseq_emmc.o
 mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
 obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o
diff --git a/drivers/mmc/core/pwrseq_sd8787.c b/drivers/mmc/core/pwrseq_sd8787.c
new file mode 100644
index ..1a21e14458d3
--- /dev/null
+++ b/drivers/mmc/core/pwrseq_sd8787.c
@@ -0,0 +1,117 @@
+/*
+ * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT + Wifi chip
+ *
+ * Copyright (C) 2016 Matt Ranostay 
+ *
+ * Based on the original work pwrseq_simple.c
+ *  Copyright (C) 2014 Linaro Ltd
+ *  Author: Ulf Hansson 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "pwrseq.h"
+
+struct mmc_pwrseq_sd8787 {
+   struct mmc_pwrseq pwrseq;
+   struct gpio_desc *reset_gpio;
+   struct gpio_desc *pwrdn_gpio;
+};
+
+#define to_pwrseq_sd8787(p) container_of(p, struct mmc_pwrseq_sd8787, pwrseq)
+
+static void mmc_pwrseq_sd8787_pre_power_on(struct mmc_host *host)
+{
+   struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
+
+   gpiod_set_value_cansleep(pwrseq->reset_gpio, 1);
+
+   msleep(300);
+   gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 1);
+}
+
+static void mmc_pwrseq_sd8787_power_off(struct mmc_host *host)
+{
+   struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
+
+   gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 0);
+   gpiod_set_value_cansleep(pwrseq->reset_gpio, 0);
+}
+
+static const struct mmc_pwrseq_ops mmc_pwrseq_sd8787_ops = {
+   .pre_power_on = mmc_pwrseq_sd8787_pre_power_on,
+   .power_off = mmc_pwrseq_sd8787_power_off,
+};
+
+static const struct of_device_id mmc_pwrseq_sd8787_of_match[] = {
+   { .compatible = "mmc-pwrseq-sd8787",},
+   {/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, mmc_pwrseq_sd8787_of_match);
+
+static int mmc_pwrseq_sd8787_probe(struct platform_device *pdev)
+{
+   struct mmc_pwrseq_sd8787 *pwrseq;
+   struct device *dev = >dev;
+
+   pwrseq = devm_kzalloc(dev, sizeof(*pwrseq), GFP_KERNEL);
+   if (!pwrseq)
+   return -ENOMEM;
+
+   pwrseq->pwrdn_gpio = devm_gpiod_get(dev, "powerdown", GPIOD_OUT_LOW);
+   if (IS_ERR(pwrseq->pwrdn_gpio))
+   return PTR_ERR(pwrseq->pwrdn_gpio);
+
+   pwrseq->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
+   if (IS_ERR(pwrseq->reset_gpio))
+   return PTR_ERR(pwrseq->reset_gpio);
+
+   pwrseq->pwrseq.dev = dev;
+   pwrseq->pwrseq.ops = _pwrseq_sd8787_ops;
+   pwrseq->pwrseq.owner = THIS_MODULE;
+   platform_set_drvdata(pdev, pwrseq);
+

[PATCH v3 1/2] devicetree: document new marvell-8xxx and pwrseq-sd8787 options

[Matt Ranostay]

Cc: devicet...@vger.kernel.org
Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
---
 .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt  | 14 ++
 .../devicetree/bindings/net/wireless/marvell-8xxx.txt  |  7 ++-
 2 files changed, 20 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt

diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt 
b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
new file mode 100644
index ..4bb56766982e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
@@ -0,0 +1,14 @@
+* Marvell SD8787 power sequence provider
+
+Required properties:
+- compatible: must be "mmc-pwrseq-sd8787".
+- powerdown-gpio: contains a power down GPIO specifier with active state
+- reset-gpio: contains a reset GPIO specifier with active state
+
+Example:
+
+   wifi_pwrseq: wifi_pwrseq {
+   compatible = "mmc-pwrseq-sd8787";
+   powerdown-gpio = <_gpio 0 GPIO_ACTIVE_LOW>;
+   reset-gpio = <_gpio 1 GPIO_ACTIVE_LOW>;
+   }
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt 
b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
index 980b16df74c3..0854451ff91d 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -1,4 +1,4 @@
-Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
+Marvell 8787/8897/8997 (sd8787/sd8897/sd8997/pcie8997) SDIO/PCIE devices
 --
 
 This node provides properties for controlling the Marvell SDIO/PCIE wireless 
device.
@@ -8,6 +8,7 @@ connects the device to the system.
 Required properties:
 
   - compatible : should be one of the following:
+   * "marvell,sd8787"
* "marvell,sd8897"
* "marvell,sd8997"
* "pci11ab,2b42"
@@ -34,6 +35,9 @@ Optional properties:
 so that the wifi chip can wakeup host platform under certain 
condition.
 during system resume, the irq will be disabled to make sure
 unnecessary interrupt is not received.
+  - vmmc-supply: a phandle of a regulator, supplying VCC to the card
+  - mmc-pwrseq:  phandle to the MMC power sequence node. See "mmc-pwrseq-*"
+for documentation of MMC power sequence bindings.
 
 Example:
 
@@ -46,6 +50,7 @@ so that firmware can wakeup host using this device side pin.
  {
status = "okay";
vmmc-supply = <_en_reg>;
+   mmc-pwrseq = <_pwrseq>;
bus-width = <4>;
cap-power-off-card;
keep-power-in-suspend;
-- 
2.10.2

[PATCH v3 1/2] devicetree: document new marvell-8xxx and pwrseq-sd8787 options

[Matt Ranostay]

Cc: devicet...@vger.kernel.org
Signed-off-by: Matt Ranostay 
---
 .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt  | 14 ++
 .../devicetree/bindings/net/wireless/marvell-8xxx.txt  |  7 ++-
 2 files changed, 20 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt

diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt 
b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
new file mode 100644
index ..4bb56766982e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
@@ -0,0 +1,14 @@
+* Marvell SD8787 power sequence provider
+
+Required properties:
+- compatible: must be "mmc-pwrseq-sd8787".
+- powerdown-gpio: contains a power down GPIO specifier with active state
+- reset-gpio: contains a reset GPIO specifier with active state
+
+Example:
+
+   wifi_pwrseq: wifi_pwrseq {
+   compatible = "mmc-pwrseq-sd8787";
+   powerdown-gpio = <_gpio 0 GPIO_ACTIVE_LOW>;
+   reset-gpio = <_gpio 1 GPIO_ACTIVE_LOW>;
+   }
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt 
b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
index 980b16df74c3..0854451ff91d 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -1,4 +1,4 @@
-Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
+Marvell 8787/8897/8997 (sd8787/sd8897/sd8997/pcie8997) SDIO/PCIE devices
 --
 
 This node provides properties for controlling the Marvell SDIO/PCIE wireless 
device.
@@ -8,6 +8,7 @@ connects the device to the system.
 Required properties:
 
   - compatible : should be one of the following:
+   * "marvell,sd8787"
* "marvell,sd8897"
* "marvell,sd8997"
* "pci11ab,2b42"
@@ -34,6 +35,9 @@ Optional properties:
 so that the wifi chip can wakeup host platform under certain 
condition.
 during system resume, the irq will be disabled to make sure
 unnecessary interrupt is not received.
+  - vmmc-supply: a phandle of a regulator, supplying VCC to the card
+  - mmc-pwrseq:  phandle to the MMC power sequence node. See "mmc-pwrseq-*"
+for documentation of MMC power sequence bindings.
 
 Example:
 
@@ -46,6 +50,7 @@ so that firmware can wakeup host using this device side pin.
  {
status = "okay";
vmmc-supply = <_en_reg>;
+   mmc-pwrseq = <_pwrseq>;
bus-width = <4>;
cap-power-off-card;
keep-power-in-suspend;
-- 
2.10.2

[PATCH v3 0/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

Changes from v1:
* split devictree docs from pwrseq changes
* rebase devicetree documents due to filename change
* rebase pwrseq patchset

Changes from v2:
* update device tree bindings to powerdown-gpios and document
  active state

Matt Ranostay (2):
  devicetree: document new marvell-8xxx and pwrseq-sd8787 options
  mmc: pwrseq: add support for Marvell SD8787 chip

 .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt  |  14 +++
 .../bindings/net/wireless/marvell-8xxx.txt |   7 +-
 drivers/mmc/core/Kconfig   |  10 ++
 drivers/mmc/core/Makefile  |   1 +
 drivers/mmc/core/pwrseq_sd8787.c   | 117 +
 5 files changed, 148 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
 create mode 100644 drivers/mmc/core/pwrseq_sd8787.c

-- 
2.10.2

[PATCH v3 0/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

Changes from v1:
* split devictree docs from pwrseq changes
* rebase devicetree documents due to filename change
* rebase pwrseq patchset

Changes from v2:
* update device tree bindings to powerdown-gpios and document
  active state

Matt Ranostay (2):
  devicetree: document new marvell-8xxx and pwrseq-sd8787 options
  mmc: pwrseq: add support for Marvell SD8787 chip

 .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt  |  14 +++
 .../bindings/net/wireless/marvell-8xxx.txt |   7 +-
 drivers/mmc/core/Kconfig   |  10 ++
 drivers/mmc/core/Makefile  |   1 +
 drivers/mmc/core/pwrseq_sd8787.c   | 117 +
 5 files changed, 148 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
 create mode 100644 drivers/mmc/core/pwrseq_sd8787.c

-- 
2.10.2

Re: [PATCH v3] iio: light: acpi-als: Properly enable on ASUS Zenbooks

[Matt Ranostay]

On Thu, Jan 19, 2017 at 11:01 AM, Josef Gajdusek  wrote:
> ASUS Zenbooks need several special ACPI calls to enable the ALS peripheral.
> Otherwise, reads just return 0.
>
> Signed-off-by: Josef Gajdusek 
> ---
>  drivers/iio/light/acpi-als.c | 60 
> 
>  1 file changed, 60 insertions(+)
>
> diff --git a/drivers/iio/light/acpi-als.c b/drivers/iio/light/acpi-als.c
> index f0b47c5..43417c9 100644
> --- a/drivers/iio/light/acpi-als.c
> +++ b/drivers/iio/light/acpi-als.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -39,6 +40,9 @@
>  #define ACPI_ALS_DEVICE_NAME   "acpi-als"
>  #define ACPI_ALS_NOTIFY_ILLUMINANCE0x80
>
> +#define ACPI_ALS_ASUS_TALS "\\_SB.PCI0.LPCB.EC0.TALS"
> +#define ACPI_ALS_ASUS_ALSC "\\_SB.ATKD.ALSC"

Not sure I like these one off defines... this could easily get out of hand.
Also too lazy to pop out the ACPI spec what does TALS and ALSC mean?

> +
>  ACPI_MODULE_NAME("acpi-als");
>
>  /*
> @@ -170,6 +174,46 @@ static int acpi_als_read_raw(struct iio_dev *indio_dev,
> return IIO_VAL_INT;
>  }
>
> +static int acpi_als_quirk_asus_zenbook_add(struct acpi_als *als)
> +{
> +   acpi_status status;
> +
> +   status = acpi_execute_simple_method(NULL, ACPI_ALS_ASUS_TALS, 1);
> +   if (ACPI_FAILURE(status)) {
> +   ACPI_EXCEPTION((AE_INFO, status, "Error enabling ALS by %s",
> +   ACPI_ALS_ASUS_TALS));
> +   return -EIO;
> +   }
> +   status = acpi_execute_simple_method(NULL, ACPI_ALS_ASUS_ALSC, 1);
> +   if (ACPI_FAILURE(status)) {
> +   ACPI_EXCEPTION((AE_INFO, status, "Error enabling ALS by %s",
> +   ACPI_ALS_ASUS_ALSC));
> +   return -EIO;
> +   }
> +
> +   return 0;
> +}
> +
> +struct quirk_entry {
> +   int (*add)(struct acpi_als *als);

Maybe put the defines above in here.

 .tals  = "\\_SB.PCI0.LPCB.EC0.TALS",
 .alsc = ""\\_SB.ATKD.ALSC"
.

> +};
> +
> +static struct quirk_entry acpi_als_quirk_asus_zenbook = {
> +   .add = acpi_als_quirk_asus_zenbook_add
> +};
> +
> +static const struct dmi_system_id acpi_als_quirks[] = {
> +   {
> +   .ident = "ASUSTeK COMPUTER INC. UX",
> +   .matches = {
> +   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> +   DMI_MATCH(DMI_PRODUCT_NAME, "UX"),

Really is the DMI_PRODUCT_NAME only two characters? You are likely
going to need another DMI property to match on.


Thanks,

Matt

> +   },
> +   .driver_data = _als_quirk_asus_zenbook,
> +   },
> +   {},
> +};
> +
>  static const struct iio_info acpi_als_info = {
> .driver_module  = THIS_MODULE,
> .read_raw   = acpi_als_read_raw,
> @@ -180,6 +224,9 @@ static int acpi_als_add(struct acpi_device *device)
> struct acpi_als *als;
> struct iio_dev *indio_dev;
> struct iio_buffer *buffer;
> +   const struct dmi_system_id *dmiid;
> +   struct quirk_entry *quirk;
> +   int ret;
>
> indio_dev = devm_iio_device_alloc(>dev, sizeof(*als));
> if (!indio_dev)
> @@ -191,6 +238,19 @@ static int acpi_als_add(struct acpi_device *device)
> als->device = device;
> mutex_init(>lock);
>
> +   dmiid = dmi_first_match(acpi_als_quirks);
> +   if (dmiid) {
> +   dev_dbg(>dev, "Detected quirk for %s\n", 
> dmiid->ident);
> +   quirk = dmiid->driver_data;
> +   ret = quirk->add(als);
> +   if (ret) {
> +   dev_err(>dev,
> +   "Executing quirk for %s failed - %d",
> +   dmiid->ident, ret);
> +   return ret;
> +   }
> +   }
> +
> indio_dev->name = ACPI_ALS_DEVICE_NAME;
> indio_dev->dev.parent = >dev;
> indio_dev->info = _als_info;
> --
> 2.10.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] iio: light: acpi-als: Properly enable on ASUS Zenbooks

[Matt Ranostay]

On Thu, Jan 19, 2017 at 11:01 AM, Josef Gajdusek  wrote:
> ASUS Zenbooks need several special ACPI calls to enable the ALS peripheral.
> Otherwise, reads just return 0.
>
> Signed-off-by: Josef Gajdusek 
> ---
>  drivers/iio/light/acpi-als.c | 60 
> 
>  1 file changed, 60 insertions(+)
>
> diff --git a/drivers/iio/light/acpi-als.c b/drivers/iio/light/acpi-als.c
> index f0b47c5..43417c9 100644
> --- a/drivers/iio/light/acpi-als.c
> +++ b/drivers/iio/light/acpi-als.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -39,6 +40,9 @@
>  #define ACPI_ALS_DEVICE_NAME   "acpi-als"
>  #define ACPI_ALS_NOTIFY_ILLUMINANCE0x80
>
> +#define ACPI_ALS_ASUS_TALS "\\_SB.PCI0.LPCB.EC0.TALS"
> +#define ACPI_ALS_ASUS_ALSC "\\_SB.ATKD.ALSC"

Not sure I like these one off defines... this could easily get out of hand.
Also too lazy to pop out the ACPI spec what does TALS and ALSC mean?

> +
>  ACPI_MODULE_NAME("acpi-als");
>
>  /*
> @@ -170,6 +174,46 @@ static int acpi_als_read_raw(struct iio_dev *indio_dev,
> return IIO_VAL_INT;
>  }
>
> +static int acpi_als_quirk_asus_zenbook_add(struct acpi_als *als)
> +{
> +   acpi_status status;
> +
> +   status = acpi_execute_simple_method(NULL, ACPI_ALS_ASUS_TALS, 1);
> +   if (ACPI_FAILURE(status)) {
> +   ACPI_EXCEPTION((AE_INFO, status, "Error enabling ALS by %s",
> +   ACPI_ALS_ASUS_TALS));
> +   return -EIO;
> +   }
> +   status = acpi_execute_simple_method(NULL, ACPI_ALS_ASUS_ALSC, 1);
> +   if (ACPI_FAILURE(status)) {
> +   ACPI_EXCEPTION((AE_INFO, status, "Error enabling ALS by %s",
> +   ACPI_ALS_ASUS_ALSC));
> +   return -EIO;
> +   }
> +
> +   return 0;
> +}
> +
> +struct quirk_entry {
> +   int (*add)(struct acpi_als *als);

Maybe put the defines above in here.

 .tals  = "\\_SB.PCI0.LPCB.EC0.TALS",
 .alsc = ""\\_SB.ATKD.ALSC"
.

> +};
> +
> +static struct quirk_entry acpi_als_quirk_asus_zenbook = {
> +   .add = acpi_als_quirk_asus_zenbook_add
> +};
> +
> +static const struct dmi_system_id acpi_als_quirks[] = {
> +   {
> +   .ident = "ASUSTeK COMPUTER INC. UX",
> +   .matches = {
> +   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> +   DMI_MATCH(DMI_PRODUCT_NAME, "UX"),

Really is the DMI_PRODUCT_NAME only two characters? You are likely
going to need another DMI property to match on.


Thanks,

Matt

> +   },
> +   .driver_data = _als_quirk_asus_zenbook,
> +   },
> +   {},
> +};
> +
>  static const struct iio_info acpi_als_info = {
> .driver_module  = THIS_MODULE,
> .read_raw   = acpi_als_read_raw,
> @@ -180,6 +224,9 @@ static int acpi_als_add(struct acpi_device *device)
> struct acpi_als *als;
> struct iio_dev *indio_dev;
> struct iio_buffer *buffer;
> +   const struct dmi_system_id *dmiid;
> +   struct quirk_entry *quirk;
> +   int ret;
>
> indio_dev = devm_iio_device_alloc(>dev, sizeof(*als));
> if (!indio_dev)
> @@ -191,6 +238,19 @@ static int acpi_als_add(struct acpi_device *device)
> als->device = device;
> mutex_init(>lock);
>
> +   dmiid = dmi_first_match(acpi_als_quirks);
> +   if (dmiid) {
> +   dev_dbg(>dev, "Detected quirk for %s\n", 
> dmiid->ident);
> +   quirk = dmiid->driver_data;
> +   ret = quirk->add(als);
> +   if (ret) {
> +   dev_err(>dev,
> +   "Executing quirk for %s failed - %d",
> +   dmiid->ident, ret);
> +   return ret;
> +   }
> +   }
> +
> indio_dev->name = ACPI_ALS_DEVICE_NAME;
> indio_dev->dev.parent = >dev;
> indio_dev->info = _als_info;
> --
> 2.10.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

On Sun, Jan 15, 2017 at 6:35 PM, Shawn Lin <shawn@rock-chips.com> wrote:
> On 2017/1/16 5:41, Matt Ranostay wrote:
>>
>> On Thu, Jan 12, 2017 at 11:16 PM, Shawn Lin <shawn@rock-chips.com>
>> wrote:
>>>
>>> On 2017/1/13 13:29, Matt Ranostay wrote:
>>>>
>>>>
>>>> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
>>>> This can be abstracted to other chipsets if needed in the future.
>>>>
>>>> Cc: Tony Lindgren <t...@atomide.com>
>>>> Cc: Ulf Hansson <ulf.hans...@linaro.org>
>>>> Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
>>>> ---
>>>>  drivers/mmc/core/Kconfig |  10 
>>>>  drivers/mmc/core/Makefile|   1 +
>>>>  drivers/mmc/core/pwrseq_sd8787.c | 117
>>>> +++
>>>>  3 files changed, 128 insertions(+)
>>>>  create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
>>>>
>>>> diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
>>>> index cdfa8520a4b1..fc1ecdaaa9ca 100644
>>>> --- a/drivers/mmc/core/Kconfig
>>>> +++ b/drivers/mmc/core/Kconfig
>>>> @@ -12,6 +12,16 @@ config PWRSEQ_EMMC
>>>>   This driver can also be built as a module. If so, the module
>>>>   will be called pwrseq_emmc.
>>>>
>>>> +config PWRSEQ_SD8787
>>>> +   tristate "HW reset support for SD8787 BT + Wifi module"
>>>> +   depends on OF && (MWIFIEX || BT_MRVL_SDIO)
>>>> +   help
>>>> + This selects hardware reset support for the SD8787 BT + Wifi
>>>> + module. By default this option is set to n.
>>>> +
>>>> + This driver can also be built as a module. If so, the module
>>>> + will be called pwrseq_sd8787.
>>>> +
>>>
>>>
>>>
>>> I don't like this way, as we have a chance to list lots
>>> configure options here. wifi A,B,C,D...Z, all of them need a
>>> new section here if needed?
>>>
>>> Instead, could you just extent pwrseq_simple.c and add you
>>> .compatible = "mmc-pwrseq-sd8787", "mmc-pwrseq-simple"?
>>
>>
>> You mean all the chipset pwrseqs linked into the pwrseq-simple module?
>
>
> What I mean was if you just extent the pwrseq-simple a bit, you could
> just add your chipset pwrseqs linked into the pwrseq-simple. But if you
> need a different *pattern* of pwrseqs, you should need a new name, for
> instance, pwrseq-sdio.c etc... But please don't use the name of
> sd8787? So if I use a wifi named ABC but using the same pwrseq pattenr,
> should I include your "mmc-pwrseq- sd8787" for that or I need a new
> mmc-pwrseq-ABC.c?

Ah so pwrseq-sdio.c seems reasonable and having chipsets functions
defined in a structure. That could be abstracted out for other
chipsets that could needed in the future.

- Matt

>
>
>>
>> Ulf your thoughts on this?
>>
>>>
>>>
>>>
>>>>  config PWRSEQ_SIMPLE
>>>> tristate "Simple HW reset support for MMC"
>>>> default y
>>>> diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
>>>> index b2a257dc644f..0f81464fa824 100644
>>>> --- a/drivers/mmc/core/Makefile
>>>> +++ b/drivers/mmc/core/Makefile
>>>> @@ -10,6 +10,7 @@ mmc_core-y    := core.o bus.o host.o \
>>>>quirks.o slot-gpio.o
>>>>  mmc_core-$(CONFIG_OF)  += pwrseq.o
>>>>  obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o
>>>> +obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o
>>>>  obj-$(CONFIG_PWRSEQ_EMMC)  += pwrseq_emmc.o
>>>>  mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
>>>>  obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o
>>>> diff --git a/drivers/mmc/core/pwrseq_sd8787.c
>>>> b/drivers/mmc/core/pwrseq_sd8787.c
>>>> new file mode 100644
>>>> index ..f4080fe6439e
>>>> --- /dev/null
>>>> +++ b/drivers/mmc/core/pwrseq_sd8787.c
>>>> @@ -0,0 +1,117 @@
>>>> +/*
>>>> + * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT +
>>>> Wifi
>>>> chip
>>>> + *
>>>> + * Copyright (C) 2016 Matt Ranostay <matt@ranostay.consulting>
>>>> + *
>>>> + * 

Re: [PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

On Sun, Jan 15, 2017 at 6:35 PM, Shawn Lin  wrote:
> On 2017/1/16 5:41, Matt Ranostay wrote:
>>
>> On Thu, Jan 12, 2017 at 11:16 PM, Shawn Lin 
>> wrote:
>>>
>>> On 2017/1/13 13:29, Matt Ranostay wrote:
>>>>
>>>>
>>>> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
>>>> This can be abstracted to other chipsets if needed in the future.
>>>>
>>>> Cc: Tony Lindgren 
>>>> Cc: Ulf Hansson 
>>>> Signed-off-by: Matt Ranostay 
>>>> ---
>>>>  drivers/mmc/core/Kconfig |  10 
>>>>  drivers/mmc/core/Makefile|   1 +
>>>>  drivers/mmc/core/pwrseq_sd8787.c | 117
>>>> +++
>>>>  3 files changed, 128 insertions(+)
>>>>  create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
>>>>
>>>> diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
>>>> index cdfa8520a4b1..fc1ecdaaa9ca 100644
>>>> --- a/drivers/mmc/core/Kconfig
>>>> +++ b/drivers/mmc/core/Kconfig
>>>> @@ -12,6 +12,16 @@ config PWRSEQ_EMMC
>>>>   This driver can also be built as a module. If so, the module
>>>>   will be called pwrseq_emmc.
>>>>
>>>> +config PWRSEQ_SD8787
>>>> +   tristate "HW reset support for SD8787 BT + Wifi module"
>>>> +   depends on OF && (MWIFIEX || BT_MRVL_SDIO)
>>>> +   help
>>>> + This selects hardware reset support for the SD8787 BT + Wifi
>>>> + module. By default this option is set to n.
>>>> +
>>>> + This driver can also be built as a module. If so, the module
>>>> + will be called pwrseq_sd8787.
>>>> +
>>>
>>>
>>>
>>> I don't like this way, as we have a chance to list lots
>>> configure options here. wifi A,B,C,D...Z, all of them need a
>>> new section here if needed?
>>>
>>> Instead, could you just extent pwrseq_simple.c and add you
>>> .compatible = "mmc-pwrseq-sd8787", "mmc-pwrseq-simple"?
>>
>>
>> You mean all the chipset pwrseqs linked into the pwrseq-simple module?
>
>
> What I mean was if you just extent the pwrseq-simple a bit, you could
> just add your chipset pwrseqs linked into the pwrseq-simple. But if you
> need a different *pattern* of pwrseqs, you should need a new name, for
> instance, pwrseq-sdio.c etc... But please don't use the name of
> sd8787? So if I use a wifi named ABC but using the same pwrseq pattenr,
> should I include your "mmc-pwrseq- sd8787" for that or I need a new
> mmc-pwrseq-ABC.c?

Ah so pwrseq-sdio.c seems reasonable and having chipsets functions
defined in a structure. That could be abstracted out for other
chipsets that could needed in the future.

- Matt

>
>
>>
>> Ulf your thoughts on this?
>>
>>>
>>>
>>>
>>>>  config PWRSEQ_SIMPLE
>>>> tristate "Simple HW reset support for MMC"
>>>> default y
>>>> diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
>>>> index b2a257dc644f..0f81464fa824 100644
>>>> --- a/drivers/mmc/core/Makefile
>>>> +++ b/drivers/mmc/core/Makefile
>>>> @@ -10,6 +10,7 @@ mmc_core-y:= core.o bus.o host.o \
>>>>quirks.o slot-gpio.o
>>>>  mmc_core-$(CONFIG_OF)  += pwrseq.o
>>>>  obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o
>>>> +obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o
>>>>  obj-$(CONFIG_PWRSEQ_EMMC)  += pwrseq_emmc.o
>>>>  mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
>>>>  obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o
>>>> diff --git a/drivers/mmc/core/pwrseq_sd8787.c
>>>> b/drivers/mmc/core/pwrseq_sd8787.c
>>>> new file mode 100644
>>>> index ..f4080fe6439e
>>>> --- /dev/null
>>>> +++ b/drivers/mmc/core/pwrseq_sd8787.c
>>>> @@ -0,0 +1,117 @@
>>>> +/*
>>>> + * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT +
>>>> Wifi
>>>> chip
>>>> + *
>>>> + * Copyright (C) 2016 Matt Ranostay 
>>>> + *
>>>> + * Based on the original work pwrseq_simple.c
>>>> + *  Copyright (C) 2014 Linaro Ltd
>>>> + *  Author: Ulf Hansson 
>>>> + *
>>>> + * This p

Re: [PATCH] iio: health: max30100: use msleep() for long uncritical delays

[Matt Ranostay]

On Mon, Jan 16, 2017 at 7:35 AM, Nicholas Mc Guire <hof...@osadl.org> wrote:
> ulseep_range() uses hrtimers and provides no advantage over msleep()
> for larger delays. Fix up the 35ms delays here to use msleep() and
> reduce the load on the hrtimer subsystem.

Ok makes sense.  Also long as it guaranteed to be at least 35 milliseconds.

Reviewed-by: Matt Ranostay <matt.ranos...@konsulko.com>

>
> Fixes: commit 4d33615df58b ("iio: light: add MAX30100 oximeter driver 
> support")
> Link: http://lkml.org/lkml/2017/1/11/377
> Signed-off-by: Nicholas Mc Guire <hof...@osadl.org>
> ---
> Problem located with coccinelle script
>
> Patch was compile tested with: x86_64_defconfig + CONFIG_IIO=m +
> CONFIG_MAX30100=m
>
> Patch is aginast 4.10-rc3 (localversion-next is next-20170116)
>
>  drivers/iio/health/max30100.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iio/health/max30100.c b/drivers/iio/health/max30100.c
> index 90ab8a2d..9648c69 100644
> --- a/drivers/iio/health/max30100.c
> +++ b/drivers/iio/health/max30100.c
> @@ -378,7 +378,7 @@ static int max30100_get_temp(struct max30100_data *data, 
> int *val)
> if (ret)
> return ret;
>
> -   usleep_range(35000, 5);
> +   msleep(35);
>
> return max30100_read_temp(data, val);
>  }
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] iio: health: max30100: use msleep() for long uncritical delays

[Matt Ranostay]

On Mon, Jan 16, 2017 at 7:35 AM, Nicholas Mc Guire  wrote:
> ulseep_range() uses hrtimers and provides no advantage over msleep()
> for larger delays. Fix up the 35ms delays here to use msleep() and
> reduce the load on the hrtimer subsystem.

Ok makes sense.  Also long as it guaranteed to be at least 35 milliseconds.

Reviewed-by: Matt Ranostay 

>
> Fixes: commit 4d33615df58b ("iio: light: add MAX30100 oximeter driver 
> support")
> Link: http://lkml.org/lkml/2017/1/11/377
> Signed-off-by: Nicholas Mc Guire 
> ---
> Problem located with coccinelle script
>
> Patch was compile tested with: x86_64_defconfig + CONFIG_IIO=m +
> CONFIG_MAX30100=m
>
> Patch is aginast 4.10-rc3 (localversion-next is next-20170116)
>
>  drivers/iio/health/max30100.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iio/health/max30100.c b/drivers/iio/health/max30100.c
> index 90ab8a2d..9648c69 100644
> --- a/drivers/iio/health/max30100.c
> +++ b/drivers/iio/health/max30100.c
> @@ -378,7 +378,7 @@ static int max30100_get_temp(struct max30100_data *data, 
> int *val)
> if (ret)
> return ret;
>
> -   usleep_range(35000, 5);
> +   msleep(35);
>
> return max30100_read_temp(data, val);
>  }
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

On Thu, Jan 12, 2017 at 11:16 PM, Shawn Lin <shawn@rock-chips.com> wrote:
> On 2017/1/13 13:29, Matt Ranostay wrote:
>>
>> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
>> This can be abstracted to other chipsets if needed in the future.
>>
>> Cc: Tony Lindgren <t...@atomide.com>
>> Cc: Ulf Hansson <ulf.hans...@linaro.org>
>> Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
>> ---
>>  drivers/mmc/core/Kconfig |  10 
>>  drivers/mmc/core/Makefile|   1 +
>>  drivers/mmc/core/pwrseq_sd8787.c | 117
>> +++
>>  3 files changed, 128 insertions(+)
>>  create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
>>
>> diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
>> index cdfa8520a4b1..fc1ecdaaa9ca 100644
>> --- a/drivers/mmc/core/Kconfig
>> +++ b/drivers/mmc/core/Kconfig
>> @@ -12,6 +12,16 @@ config PWRSEQ_EMMC
>>   This driver can also be built as a module. If so, the module
>>   will be called pwrseq_emmc.
>>
>> +config PWRSEQ_SD8787
>> +   tristate "HW reset support for SD8787 BT + Wifi module"
>> +   depends on OF && (MWIFIEX || BT_MRVL_SDIO)
>> +   help
>> + This selects hardware reset support for the SD8787 BT + Wifi
>> + module. By default this option is set to n.
>> +
>> + This driver can also be built as a module. If so, the module
>> + will be called pwrseq_sd8787.
>> +
>
>
> I don't like this way, as we have a chance to list lots
> configure options here. wifi A,B,C,D...Z, all of them need a
> new section here if needed?
>
> Instead, could you just extent pwrseq_simple.c and add you
> .compatible = "mmc-pwrseq-sd8787", "mmc-pwrseq-simple"?

You mean all the chipset pwrseqs linked into the pwrseq-simple module?

Ulf your thoughts on this?

>
>
>
>>  config PWRSEQ_SIMPLE
>> tristate "Simple HW reset support for MMC"
>> default y
>> diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
>> index b2a257dc644f..0f81464fa824 100644
>> --- a/drivers/mmc/core/Makefile
>> +++ b/drivers/mmc/core/Makefile
>> @@ -10,6 +10,7 @@ mmc_core-y:= core.o bus.o host.o \
>>quirks.o slot-gpio.o
>>  mmc_core-$(CONFIG_OF)  += pwrseq.o
>>  obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o
>> +obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o
>>  obj-$(CONFIG_PWRSEQ_EMMC)  += pwrseq_emmc.o
>>  mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
>>  obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o
>> diff --git a/drivers/mmc/core/pwrseq_sd8787.c
>> b/drivers/mmc/core/pwrseq_sd8787.c
>> new file mode 100644
>> index ..f4080fe6439e
>> --- /dev/null
>> +++ b/drivers/mmc/core/pwrseq_sd8787.c
>> @@ -0,0 +1,117 @@
>> +/*
>> + * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT + Wifi
>> chip
>> + *
>> + * Copyright (C) 2016 Matt Ranostay <matt@ranostay.consulting>
>> + *
>> + * Based on the original work pwrseq_simple.c
>> + *  Copyright (C) 2014 Linaro Ltd
>> + *  Author: Ulf Hansson <ulf.hans...@linaro.org>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +#include "pwrseq.h"
>> +
>> +struct mmc_pwrseq_sd8787 {
>> +   struct mmc_pwrseq pwrseq;
>> +   struct gpio_desc *reset_gpio;
>> +   struct gpio_desc *pwrdn_gpio;
>> +};
>> +
>> +#define to_pwrseq_sd8787(p) container_of(p, struct mmc_pwrseq_sd8787,
>> pwrseq)
>> +
>> +static void mmc_pwrseq_sd8787_pre_power_on(struct mmc_host *host)
>> +{
>> +   struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq)

Re: [PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

On Thu, Jan 12, 2017 at 11:16 PM, Shawn Lin  wrote:
> On 2017/1/13 13:29, Matt Ranostay wrote:
>>
>> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
>> This can be abstracted to other chipsets if needed in the future.
>>
>> Cc: Tony Lindgren 
>> Cc: Ulf Hansson 
>> Signed-off-by: Matt Ranostay 
>> ---
>>  drivers/mmc/core/Kconfig |  10 
>>  drivers/mmc/core/Makefile|   1 +
>>  drivers/mmc/core/pwrseq_sd8787.c | 117
>> +++
>>  3 files changed, 128 insertions(+)
>>  create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
>>
>> diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
>> index cdfa8520a4b1..fc1ecdaaa9ca 100644
>> --- a/drivers/mmc/core/Kconfig
>> +++ b/drivers/mmc/core/Kconfig
>> @@ -12,6 +12,16 @@ config PWRSEQ_EMMC
>>   This driver can also be built as a module. If so, the module
>>   will be called pwrseq_emmc.
>>
>> +config PWRSEQ_SD8787
>> +   tristate "HW reset support for SD8787 BT + Wifi module"
>> +   depends on OF && (MWIFIEX || BT_MRVL_SDIO)
>> +   help
>> + This selects hardware reset support for the SD8787 BT + Wifi
>> + module. By default this option is set to n.
>> +
>> + This driver can also be built as a module. If so, the module
>> + will be called pwrseq_sd8787.
>> +
>
>
> I don't like this way, as we have a chance to list lots
> configure options here. wifi A,B,C,D...Z, all of them need a
> new section here if needed?
>
> Instead, could you just extent pwrseq_simple.c and add you
> .compatible = "mmc-pwrseq-sd8787", "mmc-pwrseq-simple"?

You mean all the chipset pwrseqs linked into the pwrseq-simple module?

Ulf your thoughts on this?

>
>
>
>>  config PWRSEQ_SIMPLE
>> tristate "Simple HW reset support for MMC"
>> default y
>> diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
>> index b2a257dc644f..0f81464fa824 100644
>> --- a/drivers/mmc/core/Makefile
>> +++ b/drivers/mmc/core/Makefile
>> @@ -10,6 +10,7 @@ mmc_core-y:= core.o bus.o host.o \
>>quirks.o slot-gpio.o
>>  mmc_core-$(CONFIG_OF)  += pwrseq.o
>>  obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o
>> +obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o
>>  obj-$(CONFIG_PWRSEQ_EMMC)  += pwrseq_emmc.o
>>  mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
>>  obj-$(CONFIG_MMC_BLOCK)    += mmc_block.o
>> diff --git a/drivers/mmc/core/pwrseq_sd8787.c
>> b/drivers/mmc/core/pwrseq_sd8787.c
>> new file mode 100644
>> index ..f4080fe6439e
>> --- /dev/null
>> +++ b/drivers/mmc/core/pwrseq_sd8787.c
>> @@ -0,0 +1,117 @@
>> +/*
>> + * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT + Wifi
>> chip
>> + *
>> + * Copyright (C) 2016 Matt Ranostay 
>> + *
>> + * Based on the original work pwrseq_simple.c
>> + *  Copyright (C) 2014 Linaro Ltd
>> + *  Author: Ulf Hansson 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +#include "pwrseq.h"
>> +
>> +struct mmc_pwrseq_sd8787 {
>> +   struct mmc_pwrseq pwrseq;
>> +   struct gpio_desc *reset_gpio;
>> +   struct gpio_desc *pwrdn_gpio;
>> +};
>> +
>> +#define to_pwrseq_sd8787(p) container_of(p, struct mmc_pwrseq_sd8787,
>> pwrseq)
>> +
>> +static void mmc_pwrseq_sd8787_pre_power_on(struct mmc_host *host)
>> +{
>> +   struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
>> +
>> +   gpiod_set_value_cansleep(pwrseq->reset_gpio, 1);
>> +
>> +   msleep(300);
>> +   gpiod_set_value_cans

[PATCH v3 1/2] devicetree: document new marvell-8xxx and pwrseq-sd8787 options

[Matt Ranostay]

Cc: devicet...@vger.kernel.org
Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
---
 .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt  | 14 ++
 .../devicetree/bindings/net/wireless/marvell-8xxx.txt  |  7 ++-
 2 files changed, 20 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt

diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt 
b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
new file mode 100644
index ..1b658351629b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
@@ -0,0 +1,14 @@
+* Marvell SD8787 power sequence provider
+
+Required properties:
+- compatible: must be "mmc-pwrseq-sd8787".
+- pwndn-gpio: contains a power down GPIO specifier.
+- reset-gpio: contains a reset GPIO specifier.
+
+Example:
+
+   wifi_pwrseq: wifi_pwrseq {
+   compatible = "mmc-pwrseq-sd8787";
+   pwrdn-gpio = <_gpio 0 GPIO_ACTIVE_LOW>;
+   reset-gpio = <_gpio 1 GPIO_ACTIVE_LOW>;
+   }
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt 
b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
index 980b16df74c3..0854451ff91d 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -1,4 +1,4 @@
-Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
+Marvell 8787/8897/8997 (sd8787/sd8897/sd8997/pcie8997) SDIO/PCIE devices
 --
 
 This node provides properties for controlling the Marvell SDIO/PCIE wireless 
device.
@@ -8,6 +8,7 @@ connects the device to the system.
 Required properties:
 
   - compatible : should be one of the following:
+   * "marvell,sd8787"
* "marvell,sd8897"
* "marvell,sd8997"
* "pci11ab,2b42"
@@ -34,6 +35,9 @@ Optional properties:
 so that the wifi chip can wakeup host platform under certain 
condition.
 during system resume, the irq will be disabled to make sure
 unnecessary interrupt is not received.
+  - vmmc-supply: a phandle of a regulator, supplying VCC to the card
+  - mmc-pwrseq:  phandle to the MMC power sequence node. See "mmc-pwrseq-*"
+for documentation of MMC power sequence bindings.
 
 Example:
 
@@ -46,6 +50,7 @@ so that firmware can wakeup host using this device side pin.
  {
status = "okay";
vmmc-supply = <_en_reg>;
+   mmc-pwrseq = <_pwrseq>;
bus-width = <4>;
cap-power-off-card;
keep-power-in-suspend;
-- 
2.10.2

[PATCH v3 1/2] devicetree: document new marvell-8xxx and pwrseq-sd8787 options

[Matt Ranostay]

Cc: devicet...@vger.kernel.org
Signed-off-by: Matt Ranostay 
---
 .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt  | 14 ++
 .../devicetree/bindings/net/wireless/marvell-8xxx.txt  |  7 ++-
 2 files changed, 20 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt

diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt 
b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
new file mode 100644
index ..1b658351629b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
@@ -0,0 +1,14 @@
+* Marvell SD8787 power sequence provider
+
+Required properties:
+- compatible: must be "mmc-pwrseq-sd8787".
+- pwndn-gpio: contains a power down GPIO specifier.
+- reset-gpio: contains a reset GPIO specifier.
+
+Example:
+
+   wifi_pwrseq: wifi_pwrseq {
+   compatible = "mmc-pwrseq-sd8787";
+   pwrdn-gpio = <_gpio 0 GPIO_ACTIVE_LOW>;
+   reset-gpio = <_gpio 1 GPIO_ACTIVE_LOW>;
+   }
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt 
b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
index 980b16df74c3..0854451ff91d 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -1,4 +1,4 @@
-Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
+Marvell 8787/8897/8997 (sd8787/sd8897/sd8997/pcie8997) SDIO/PCIE devices
 --
 
 This node provides properties for controlling the Marvell SDIO/PCIE wireless 
device.
@@ -8,6 +8,7 @@ connects the device to the system.
 Required properties:
 
   - compatible : should be one of the following:
+   * "marvell,sd8787"
* "marvell,sd8897"
* "marvell,sd8997"
* "pci11ab,2b42"
@@ -34,6 +35,9 @@ Optional properties:
 so that the wifi chip can wakeup host platform under certain 
condition.
 during system resume, the irq will be disabled to make sure
 unnecessary interrupt is not received.
+  - vmmc-supply: a phandle of a regulator, supplying VCC to the card
+  - mmc-pwrseq:  phandle to the MMC power sequence node. See "mmc-pwrseq-*"
+for documentation of MMC power sequence bindings.
 
 Example:
 
@@ -46,6 +50,7 @@ so that firmware can wakeup host using this device side pin.
  {
status = "okay";
vmmc-supply = <_en_reg>;
+   mmc-pwrseq = <_pwrseq>;
bus-width = <4>;
cap-power-off-card;
keep-power-in-suspend;
-- 
2.10.2

[PATCH v3 0/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

Changes from v1:
* split devictree docs from pwrseq changes
* rebase devicetree documents due to filename change
* rebase pwrseq patchset

Changes from v2:
* fix rookie mistake missing the main source file and docs

Matt Ranostay (2):
  devicetree: document new marvell-8xxx and pwrseq-sd8787 options
  mmc: pwrseq: add support for Marvell SD8787 chip

 .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt  |  14 +++
 .../bindings/net/wireless/marvell-8xxx.txt |   7 +-
 drivers/mmc/core/Kconfig   |  10 ++
 drivers/mmc/core/Makefile  |   1 +
 drivers/mmc/core/pwrseq_sd8787.c   | 117 +
 5 files changed, 148 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
 create mode 100644 drivers/mmc/core/pwrseq_sd8787.c

-- 
2.10.2

[PATCH v3 0/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

Changes from v1:
* split devictree docs from pwrseq changes
* rebase devicetree documents due to filename change
* rebase pwrseq patchset

Changes from v2:
* fix rookie mistake missing the main source file and docs

Matt Ranostay (2):
  devicetree: document new marvell-8xxx and pwrseq-sd8787 options
  mmc: pwrseq: add support for Marvell SD8787 chip

 .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt  |  14 +++
 .../bindings/net/wireless/marvell-8xxx.txt |   7 +-
 drivers/mmc/core/Kconfig   |  10 ++
 drivers/mmc/core/Makefile  |   1 +
 drivers/mmc/core/pwrseq_sd8787.c   | 117 +
 5 files changed, 148 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
 create mode 100644 drivers/mmc/core/pwrseq_sd8787.c

-- 
2.10.2

[PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
This can be abstracted to other chipsets if needed in the future.

Cc: Tony Lindgren <t...@atomide.com>
Cc: Ulf Hansson <ulf.hans...@linaro.org>
Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
---
 drivers/mmc/core/Kconfig |  10 
 drivers/mmc/core/Makefile|   1 +
 drivers/mmc/core/pwrseq_sd8787.c | 117 +++
 3 files changed, 128 insertions(+)
 create mode 100644 drivers/mmc/core/pwrseq_sd8787.c

diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index cdfa8520a4b1..fc1ecdaaa9ca 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -12,6 +12,16 @@ config PWRSEQ_EMMC
  This driver can also be built as a module. If so, the module
  will be called pwrseq_emmc.
 
+config PWRSEQ_SD8787
+   tristate "HW reset support for SD8787 BT + Wifi module"
+   depends on OF && (MWIFIEX || BT_MRVL_SDIO)
+   help
+ This selects hardware reset support for the SD8787 BT + Wifi
+ module. By default this option is set to n.
+
+ This driver can also be built as a module. If so, the module
+ will be called pwrseq_sd8787.
+
 config PWRSEQ_SIMPLE
tristate "Simple HW reset support for MMC"
default y
diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
index b2a257dc644f..0f81464fa824 100644
--- a/drivers/mmc/core/Makefile
+++ b/drivers/mmc/core/Makefile
@@ -10,6 +10,7 @@ mmc_core-y:= core.o bus.o host.o \
   quirks.o slot-gpio.o
 mmc_core-$(CONFIG_OF)  += pwrseq.o
 obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o
+obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o
 obj-$(CONFIG_PWRSEQ_EMMC)  += pwrseq_emmc.o
 mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
 obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o
diff --git a/drivers/mmc/core/pwrseq_sd8787.c b/drivers/mmc/core/pwrseq_sd8787.c
new file mode 100644
index ..f4080fe6439e
--- /dev/null
+++ b/drivers/mmc/core/pwrseq_sd8787.c
@@ -0,0 +1,117 @@
+/*
+ * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT + Wifi chip
+ *
+ * Copyright (C) 2016 Matt Ranostay <matt@ranostay.consulting>
+ *
+ * Based on the original work pwrseq_simple.c
+ *  Copyright (C) 2014 Linaro Ltd
+ *  Author: Ulf Hansson <ulf.hans...@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "pwrseq.h"
+
+struct mmc_pwrseq_sd8787 {
+   struct mmc_pwrseq pwrseq;
+   struct gpio_desc *reset_gpio;
+   struct gpio_desc *pwrdn_gpio;
+};
+
+#define to_pwrseq_sd8787(p) container_of(p, struct mmc_pwrseq_sd8787, pwrseq)
+
+static void mmc_pwrseq_sd8787_pre_power_on(struct mmc_host *host)
+{
+   struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
+
+   gpiod_set_value_cansleep(pwrseq->reset_gpio, 1);
+
+   msleep(300);
+   gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 1);
+}
+
+static void mmc_pwrseq_sd8787_power_off(struct mmc_host *host)
+{
+   struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
+
+   gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 0);
+   gpiod_set_value_cansleep(pwrseq->reset_gpio, 0);
+}
+
+static const struct mmc_pwrseq_ops mmc_pwrseq_sd8787_ops = {
+   .pre_power_on = mmc_pwrseq_sd8787_pre_power_on,
+   .power_off = mmc_pwrseq_sd8787_power_off,
+};
+
+static const struct of_device_id mmc_pwrseq_sd8787_of_match[] = {
+   { .compatible = "mmc-pwrseq-sd8787",},
+   {/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, mmc_pwrseq_sd8787_of_match);
+
+static int mmc_pwrseq_sd8787_probe(struct platform_device *pdev)
+{
+   struct mmc_pwrseq_sd8787 *pwrseq;
+   struct device *dev = >dev;
+
+   pwrseq = devm_kzalloc(dev, sizeof(*pwrseq), GFP_KERNEL);
+   if (!pwrseq)
+   return -ENOMEM;
+
+   pwrseq->pwrdn_gpio = devm_gpiod_get(dev, "pwrdn", GPIOD_OUT_LOW);
+   if (IS_ERR(pwrseq->pwrdn_gpio))
+   return PTR_ERR(pwrseq->pwrdn_gpio);
+
+   pwrseq->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
+   if (IS_ERR(pwrseq->reset_gpio))
+   return PTR_ERR(pwrseq->reset_gpio);
+
+   pwrseq->pwrseq.dev =

[PATCH v3 0/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

Changes from v1:
* split devictree docs from pwrseq changes
* rebase devicetree documents due to filename change
* rebase pwrseq patchset

Changes from v2:
* fix rookie mistake missing the main source file and docs

Matt Ranostay (2):
  devicetree: document new marvell-8xxx and pwrseq-sd8787 options
  mmc: pwrseq: add support for Marvell SD8787 chip

 .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt  |  14 +++
 .../bindings/net/wireless/marvell-8xxx.txt |   7 +-
 drivers/mmc/core/Kconfig   |  10 ++
 drivers/mmc/core/Makefile  |   1 +
 drivers/mmc/core/pwrseq_sd8787.c   | 117 +
 5 files changed, 148 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
 create mode 100644 drivers/mmc/core/pwrseq_sd8787.c

-- 
2.10.2

[PATCH v3 0/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

Changes from v1:
* split devictree docs from pwrseq changes
* rebase devicetree documents due to filename change
* rebase pwrseq patchset

Changes from v2:
* fix rookie mistake missing the main source file and docs

Matt Ranostay (2):
  devicetree: document new marvell-8xxx and pwrseq-sd8787 options
  mmc: pwrseq: add support for Marvell SD8787 chip

 .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt  |  14 +++
 .../bindings/net/wireless/marvell-8xxx.txt |   7 +-
 drivers/mmc/core/Kconfig   |  10 ++
 drivers/mmc/core/Makefile  |   1 +
 drivers/mmc/core/pwrseq_sd8787.c   | 117 +
 5 files changed, 148 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
 create mode 100644 drivers/mmc/core/pwrseq_sd8787.c

-- 
2.10.2

[PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
This can be abstracted to other chipsets if needed in the future.

Cc: Tony Lindgren 
Cc: Ulf Hansson 
Signed-off-by: Matt Ranostay 
---
 drivers/mmc/core/Kconfig |  10 
 drivers/mmc/core/Makefile|   1 +
 drivers/mmc/core/pwrseq_sd8787.c | 117 +++
 3 files changed, 128 insertions(+)
 create mode 100644 drivers/mmc/core/pwrseq_sd8787.c

diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index cdfa8520a4b1..fc1ecdaaa9ca 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -12,6 +12,16 @@ config PWRSEQ_EMMC
  This driver can also be built as a module. If so, the module
  will be called pwrseq_emmc.
 
+config PWRSEQ_SD8787
+   tristate "HW reset support for SD8787 BT + Wifi module"
+   depends on OF && (MWIFIEX || BT_MRVL_SDIO)
+   help
+ This selects hardware reset support for the SD8787 BT + Wifi
+ module. By default this option is set to n.
+
+ This driver can also be built as a module. If so, the module
+ will be called pwrseq_sd8787.
+
 config PWRSEQ_SIMPLE
tristate "Simple HW reset support for MMC"
default y
diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
index b2a257dc644f..0f81464fa824 100644
--- a/drivers/mmc/core/Makefile
+++ b/drivers/mmc/core/Makefile
@@ -10,6 +10,7 @@ mmc_core-y:= core.o bus.o host.o \
   quirks.o slot-gpio.o
 mmc_core-$(CONFIG_OF)  += pwrseq.o
 obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o
+obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o
 obj-$(CONFIG_PWRSEQ_EMMC)  += pwrseq_emmc.o
 mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
 obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o
diff --git a/drivers/mmc/core/pwrseq_sd8787.c b/drivers/mmc/core/pwrseq_sd8787.c
new file mode 100644
index ..f4080fe6439e
--- /dev/null
+++ b/drivers/mmc/core/pwrseq_sd8787.c
@@ -0,0 +1,117 @@
+/*
+ * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT + Wifi chip
+ *
+ * Copyright (C) 2016 Matt Ranostay 
+ *
+ * Based on the original work pwrseq_simple.c
+ *  Copyright (C) 2014 Linaro Ltd
+ *  Author: Ulf Hansson 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "pwrseq.h"
+
+struct mmc_pwrseq_sd8787 {
+   struct mmc_pwrseq pwrseq;
+   struct gpio_desc *reset_gpio;
+   struct gpio_desc *pwrdn_gpio;
+};
+
+#define to_pwrseq_sd8787(p) container_of(p, struct mmc_pwrseq_sd8787, pwrseq)
+
+static void mmc_pwrseq_sd8787_pre_power_on(struct mmc_host *host)
+{
+   struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
+
+   gpiod_set_value_cansleep(pwrseq->reset_gpio, 1);
+
+   msleep(300);
+   gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 1);
+}
+
+static void mmc_pwrseq_sd8787_power_off(struct mmc_host *host)
+{
+   struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
+
+   gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 0);
+   gpiod_set_value_cansleep(pwrseq->reset_gpio, 0);
+}
+
+static const struct mmc_pwrseq_ops mmc_pwrseq_sd8787_ops = {
+   .pre_power_on = mmc_pwrseq_sd8787_pre_power_on,
+   .power_off = mmc_pwrseq_sd8787_power_off,
+};
+
+static const struct of_device_id mmc_pwrseq_sd8787_of_match[] = {
+   { .compatible = "mmc-pwrseq-sd8787",},
+   {/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, mmc_pwrseq_sd8787_of_match);
+
+static int mmc_pwrseq_sd8787_probe(struct platform_device *pdev)
+{
+   struct mmc_pwrseq_sd8787 *pwrseq;
+   struct device *dev = >dev;
+
+   pwrseq = devm_kzalloc(dev, sizeof(*pwrseq), GFP_KERNEL);
+   if (!pwrseq)
+   return -ENOMEM;
+
+   pwrseq->pwrdn_gpio = devm_gpiod_get(dev, "pwrdn", GPIOD_OUT_LOW);
+   if (IS_ERR(pwrseq->pwrdn_gpio))
+   return PTR_ERR(pwrseq->pwrdn_gpio);
+
+   pwrseq->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
+   if (IS_ERR(pwrseq->reset_gpio))
+   return PTR_ERR(pwrseq->reset_gpio);
+
+   pwrseq->pwrseq.dev = dev;
+   pwrseq->pwrseq.ops = _pwrseq_sd8787_ops;
+   pwrseq->pwrseq.owner = THIS_MODULE;
+   platform_set_drvdata(pdev, pwrseq);
+

Re: [PATCH v2 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

On Thu, Jan 12, 2017 at 9:22 PM, Matt Ranostay <matt@ranostay.consulting> wrote:
> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
> This can be abstracted to other chipsets if needed in the future.


Er crap seems how the main patch file got dropped out. Resubmitting in
a minute... sorry!

>
> Cc: Tony Lindgren <t...@atomide.com>
> Cc: Ulf Hansson <ulf.hans...@linaro.org>
> Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
> ---
>  drivers/mmc/core/Kconfig  | 10 ++
>  drivers/mmc/core/Makefile |  1 +
>  2 files changed, 11 insertions(+)
>
> diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
> index cdfa8520a4b1..fc1ecdaaa9ca 100644
> --- a/drivers/mmc/core/Kconfig
> +++ b/drivers/mmc/core/Kconfig
> @@ -12,6 +12,16 @@ config PWRSEQ_EMMC
>   This driver can also be built as a module. If so, the module
>   will be called pwrseq_emmc.
>
> +config PWRSEQ_SD8787
> +   tristate "HW reset support for SD8787 BT + Wifi module"
> +   depends on OF && (MWIFIEX || BT_MRVL_SDIO)
> +   help
> + This selects hardware reset support for the SD8787 BT + Wifi
> + module. By default this option is set to n.
> +
> + This driver can also be built as a module. If so, the module
> + will be called pwrseq_sd8787.
> +
>  config PWRSEQ_SIMPLE
> tristate "Simple HW reset support for MMC"
> default y
> diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
> index b2a257dc644f..0f81464fa824 100644
> --- a/drivers/mmc/core/Makefile
> +++ b/drivers/mmc/core/Makefile
> @@ -10,6 +10,7 @@ mmc_core-y:= core.o bus.o host.o \
>quirks.o slot-gpio.o
>  mmc_core-$(CONFIG_OF)  += pwrseq.o
>  obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o
> +obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o
>  obj-$(CONFIG_PWRSEQ_EMMC)  += pwrseq_emmc.o
>  mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
>  obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o
> --
> 2.10.2
>

Re: [PATCH v2 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

On Thu, Jan 12, 2017 at 9:22 PM, Matt Ranostay  wrote:
> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
> This can be abstracted to other chipsets if needed in the future.


Er crap seems how the main patch file got dropped out. Resubmitting in
a minute... sorry!

>
> Cc: Tony Lindgren 
> Cc: Ulf Hansson 
> Signed-off-by: Matt Ranostay 
> ---
>  drivers/mmc/core/Kconfig  | 10 ++
>  drivers/mmc/core/Makefile |  1 +
>  2 files changed, 11 insertions(+)
>
> diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
> index cdfa8520a4b1..fc1ecdaaa9ca 100644
> --- a/drivers/mmc/core/Kconfig
> +++ b/drivers/mmc/core/Kconfig
> @@ -12,6 +12,16 @@ config PWRSEQ_EMMC
>   This driver can also be built as a module. If so, the module
>   will be called pwrseq_emmc.
>
> +config PWRSEQ_SD8787
> +   tristate "HW reset support for SD8787 BT + Wifi module"
> +   depends on OF && (MWIFIEX || BT_MRVL_SDIO)
> +   help
> + This selects hardware reset support for the SD8787 BT + Wifi
> + module. By default this option is set to n.
> +
> + This driver can also be built as a module. If so, the module
> + will be called pwrseq_sd8787.
> +
>  config PWRSEQ_SIMPLE
> tristate "Simple HW reset support for MMC"
> default y
> diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
> index b2a257dc644f..0f81464fa824 100644
> --- a/drivers/mmc/core/Makefile
> +++ b/drivers/mmc/core/Makefile
> @@ -10,6 +10,7 @@ mmc_core-y:= core.o bus.o host.o \
>quirks.o slot-gpio.o
>  mmc_core-$(CONFIG_OF)  += pwrseq.o
>  obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o
> +obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o
>  obj-$(CONFIG_PWRSEQ_EMMC)  += pwrseq_emmc.o
>  mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
>  obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o
> --
> 2.10.2
>

[PATCH v2 1/2] devicetree: document vmmc-supply and mmc-pwrseq options

[Matt Ranostay]

Cc: devicet...@vger.kernel.org
Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
---
 Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt 
b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
index 980b16df74c3..0854451ff91d 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -1,4 +1,4 @@
-Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
+Marvell 8787/8897/8997 (sd8787/sd8897/sd8997/pcie8997) SDIO/PCIE devices
 --
 
 This node provides properties for controlling the Marvell SDIO/PCIE wireless 
device.
@@ -8,6 +8,7 @@ connects the device to the system.
 Required properties:
 
   - compatible : should be one of the following:
+   * "marvell,sd8787"
* "marvell,sd8897"
* "marvell,sd8997"
* "pci11ab,2b42"
@@ -34,6 +35,9 @@ Optional properties:
 so that the wifi chip can wakeup host platform under certain 
condition.
 during system resume, the irq will be disabled to make sure
 unnecessary interrupt is not received.
+  - vmmc-supply: a phandle of a regulator, supplying VCC to the card
+  - mmc-pwrseq:  phandle to the MMC power sequence node. See "mmc-pwrseq-*"
+for documentation of MMC power sequence bindings.
 
 Example:
 
@@ -46,6 +50,7 @@ so that firmware can wakeup host using this device side pin.
  {
status = "okay";
vmmc-supply = <_en_reg>;
+   mmc-pwrseq = <_pwrseq>;
bus-width = <4>;
cap-power-off-card;
keep-power-in-suspend;
-- 
2.10.2

[PATCH v2 1/2] devicetree: document vmmc-supply and mmc-pwrseq options

[Matt Ranostay]

Cc: devicet...@vger.kernel.org
Signed-off-by: Matt Ranostay 
---
 Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt 
b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
index 980b16df74c3..0854451ff91d 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -1,4 +1,4 @@
-Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
+Marvell 8787/8897/8997 (sd8787/sd8897/sd8997/pcie8997) SDIO/PCIE devices
 --
 
 This node provides properties for controlling the Marvell SDIO/PCIE wireless 
device.
@@ -8,6 +8,7 @@ connects the device to the system.
 Required properties:
 
   - compatible : should be one of the following:
+   * "marvell,sd8787"
* "marvell,sd8897"
* "marvell,sd8997"
* "pci11ab,2b42"
@@ -34,6 +35,9 @@ Optional properties:
 so that the wifi chip can wakeup host platform under certain 
condition.
 during system resume, the irq will be disabled to make sure
 unnecessary interrupt is not received.
+  - vmmc-supply: a phandle of a regulator, supplying VCC to the card
+  - mmc-pwrseq:  phandle to the MMC power sequence node. See "mmc-pwrseq-*"
+for documentation of MMC power sequence bindings.
 
 Example:
 
@@ -46,6 +50,7 @@ so that firmware can wakeup host using this device side pin.
  {
status = "okay";
vmmc-supply = <_en_reg>;
+   mmc-pwrseq = <_pwrseq>;
bus-width = <4>;
cap-power-off-card;
keep-power-in-suspend;
-- 
2.10.2

[PATCH v2 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
This can be abstracted to other chipsets if needed in the future.

Cc: Tony Lindgren <t...@atomide.com>
Cc: Ulf Hansson <ulf.hans...@linaro.org>
Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
---
 drivers/mmc/core/Kconfig  | 10 ++
 drivers/mmc/core/Makefile |  1 +
 2 files changed, 11 insertions(+)

diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index cdfa8520a4b1..fc1ecdaaa9ca 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -12,6 +12,16 @@ config PWRSEQ_EMMC
  This driver can also be built as a module. If so, the module
  will be called pwrseq_emmc.
 
+config PWRSEQ_SD8787
+   tristate "HW reset support for SD8787 BT + Wifi module"
+   depends on OF && (MWIFIEX || BT_MRVL_SDIO)
+   help
+ This selects hardware reset support for the SD8787 BT + Wifi
+ module. By default this option is set to n.
+
+ This driver can also be built as a module. If so, the module
+ will be called pwrseq_sd8787.
+
 config PWRSEQ_SIMPLE
tristate "Simple HW reset support for MMC"
default y
diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
index b2a257dc644f..0f81464fa824 100644
--- a/drivers/mmc/core/Makefile
+++ b/drivers/mmc/core/Makefile
@@ -10,6 +10,7 @@ mmc_core-y:= core.o bus.o host.o \
   quirks.o slot-gpio.o
 mmc_core-$(CONFIG_OF)  += pwrseq.o
 obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o
+obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o
 obj-$(CONFIG_PWRSEQ_EMMC)  += pwrseq_emmc.o
 mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
 obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o
-- 
2.10.2

[PATCH v2 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
This can be abstracted to other chipsets if needed in the future.

Cc: Tony Lindgren 
Cc: Ulf Hansson 
Signed-off-by: Matt Ranostay 
---
 drivers/mmc/core/Kconfig  | 10 ++
 drivers/mmc/core/Makefile |  1 +
 2 files changed, 11 insertions(+)

diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index cdfa8520a4b1..fc1ecdaaa9ca 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -12,6 +12,16 @@ config PWRSEQ_EMMC
  This driver can also be built as a module. If so, the module
  will be called pwrseq_emmc.
 
+config PWRSEQ_SD8787
+   tristate "HW reset support for SD8787 BT + Wifi module"
+   depends on OF && (MWIFIEX || BT_MRVL_SDIO)
+   help
+ This selects hardware reset support for the SD8787 BT + Wifi
+ module. By default this option is set to n.
+
+ This driver can also be built as a module. If so, the module
+ will be called pwrseq_sd8787.
+
 config PWRSEQ_SIMPLE
tristate "Simple HW reset support for MMC"
default y
diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
index b2a257dc644f..0f81464fa824 100644
--- a/drivers/mmc/core/Makefile
+++ b/drivers/mmc/core/Makefile
@@ -10,6 +10,7 @@ mmc_core-y:= core.o bus.o host.o \
   quirks.o slot-gpio.o
 mmc_core-$(CONFIG_OF)  += pwrseq.o
 obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o
+obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o
 obj-$(CONFIG_PWRSEQ_EMMC)  += pwrseq_emmc.o
 mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
 obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o
-- 
2.10.2

[PATCH v2 0/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

Changes from v1:
* split devictree docs from pwrseq changes
* rebase devicetree documents due to filename change
* rebase pwrseq patchset

Matt Ranostay (2):
  devicetree: document vmmc-supply and mmc-pwrseq options
  mmc: pwrseq: add support for Marvell SD8787 chip

 .../devicetree/bindings/net/wireless/marvell-8xxx.txt  |  7 ++-
 drivers/mmc/core/Kconfig   | 10 ++
 drivers/mmc/core/Makefile  |  1 +
 3 files changed, 17 insertions(+), 1 deletion(-)

-- 
2.10.2

[PATCH v2 0/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

Changes from v1:
* split devictree docs from pwrseq changes
* rebase devicetree documents due to filename change
* rebase pwrseq patchset

Matt Ranostay (2):
  devicetree: document vmmc-supply and mmc-pwrseq options
  mmc: pwrseq: add support for Marvell SD8787 chip

 .../devicetree/bindings/net/wireless/marvell-8xxx.txt  |  7 ++-
 drivers/mmc/core/Kconfig   | 10 ++
 drivers/mmc/core/Makefile  |  1 +
 3 files changed, 17 insertions(+), 1 deletion(-)

-- 
2.10.2

Re: [RFC] pps: fixing CONFIG_COMPAT issues

[Matt Ranostay]

On Fri, Dec 23, 2016 at 7:04 AM, Rodolfo Giometti <giome...@enneenne.com> wrote:
> On 12/22/16 21:39, Matt Ranostay wrote:
>>
>>
>> What would be the best way to fix the padding issue without breaking
>> userspace applications? Just fixing the alignment with explicit
>> padding is of course the clean easy way, but bashing the data in
>> compat_ioctl would avoid breakage.
>
>
> Hi Matt,
>
> I've no experience in this topic... I'm sorry! :(
>
> Maybe is better waiting for David's advices? In the meantime I'm going to
> study the problem a bit better.

Just poking to see if anyone has a better solution. Since the long
holidays are over :)

Thanks,

Matt

>
> Ciao,
>
> Rodolfo
>
> --
>
> HCE Engineering  e-mail: giome...@hce-engineering.com
> GNU/Linux Solutions  giome...@enneenne.com
> Linux Device Driver  giome...@linux.it
> Embedded Systems phone:  +39 349 2432127
> UNIX programming skype:  rodolfo.giometti
> Cosino Project - the quick prototyping embedded system - www.cosino.io
> Freelance ICT Italia - Consulente ICT Italia - www.consulenti-ict.it

Re: [RFC] pps: fixing CONFIG_COMPAT issues

[Matt Ranostay]

On Fri, Dec 23, 2016 at 7:04 AM, Rodolfo Giometti  wrote:
> On 12/22/16 21:39, Matt Ranostay wrote:
>>
>>
>> What would be the best way to fix the padding issue without breaking
>> userspace applications? Just fixing the alignment with explicit
>> padding is of course the clean easy way, but bashing the data in
>> compat_ioctl would avoid breakage.
>
>
> Hi Matt,
>
> I've no experience in this topic... I'm sorry! :(
>
> Maybe is better waiting for David's advices? In the meantime I'm going to
> study the problem a bit better.

Just poking to see if anyone has a better solution. Since the long
holidays are over :)

Thanks,

Matt

>
> Ciao,
>
> Rodolfo
>
> --
>
> HCE Engineering  e-mail: giome...@hce-engineering.com
> GNU/Linux Solutions  giome...@enneenne.com
> Linux Device Driver  giome...@linux.it
> Embedded Systems phone:  +39 349 2432127
> UNIX programming skype:  rodolfo.giometti
> Cosino Project - the quick prototyping embedded system - www.cosino.io
> Freelance ICT Italia - Consulente ICT Italia - www.consulenti-ict.it

[RFC] pps: fixing CONFIG_COMPAT issues

[Matt Ranostay]

Rodolfo,

I'd like to get some feedback on what would be an upstreamable patch
series for correcting some issues with a 64-bit kernel and using a
32-bit userspace.

First issue is the compat_ioctl has to be sort of hacked since the
IOCTL defines are using pointer sizes in the macro generation (which
works if you don't mix bit sizes of the kernel and userspace) which
should have been just the struct size originally

#define PPS_GETPARAMS   _IOR('p', 0xa1, struct pps_kparams *)
#define PPS_SETPARAMS   _IOW('p', 0xa2, struct pps_kparams *)
#define PPS_GETCAP  _IOR('p', 0xa3, int *)
#define PPS_FETCH   _IOWR('p', 0xa4, struct pps_fdata *)
#define PPS_KC_BIND _IOW('p', 0xa5, struct pps_bind_args *)

So basically the workaround we have for that is as follows:

...
static long pps_cdev_compat_ioctl(struct file *file,
   unsigned int cmd, unsigned long arg)
{
   cmd = _IOC(_IOC_DIR(cmd), _IOC_TYPE(cmd), _IOC_NR(cmd), sizeof(void *));
   return pps_cdev_ioctl(file, cmd, arg);
}
...


Now the bigger and more ABI breaking issue is with the padding in
struct pps_ktime (which David Woodhouse has a comment in the header).
Which is worked around by __attribute__((aligned, 4)) which of course
breaks userspace for a precompiled 64-bit binary.

So the issue is that on 32-bit x86 aligns at 4-bytes, but 64-bit is at
8-bytes, so the data ferried from the former userspace to the latter
kernel is incorrect. For instance struct pps_kinfo is padded 4 bytes
more in between info and timeout members.

What would be the best way to fix the padding issue without breaking
userspace applications? Just fixing the alignment with explicit
padding is of course the clean easy way, but bashing the data in
compat_ioctl would avoid breakage.


Thanks,

Matt

[RFC] pps: fixing CONFIG_COMPAT issues

[Matt Ranostay]

Rodolfo,

I'd like to get some feedback on what would be an upstreamable patch
series for correcting some issues with a 64-bit kernel and using a
32-bit userspace.

First issue is the compat_ioctl has to be sort of hacked since the
IOCTL defines are using pointer sizes in the macro generation (which
works if you don't mix bit sizes of the kernel and userspace) which
should have been just the struct size originally

#define PPS_GETPARAMS   _IOR('p', 0xa1, struct pps_kparams *)
#define PPS_SETPARAMS   _IOW('p', 0xa2, struct pps_kparams *)
#define PPS_GETCAP  _IOR('p', 0xa3, int *)
#define PPS_FETCH   _IOWR('p', 0xa4, struct pps_fdata *)
#define PPS_KC_BIND _IOW('p', 0xa5, struct pps_bind_args *)

So basically the workaround we have for that is as follows:

...
static long pps_cdev_compat_ioctl(struct file *file,
   unsigned int cmd, unsigned long arg)
{
   cmd = _IOC(_IOC_DIR(cmd), _IOC_TYPE(cmd), _IOC_NR(cmd), sizeof(void *));
   return pps_cdev_ioctl(file, cmd, arg);
}
...


Now the bigger and more ABI breaking issue is with the padding in
struct pps_ktime (which David Woodhouse has a comment in the header).
Which is worked around by __attribute__((aligned, 4)) which of course
breaks userspace for a precompiled 64-bit binary.

So the issue is that on 32-bit x86 aligns at 4-bytes, but 64-bit is at
8-bytes, so the data ferried from the former userspace to the latter
kernel is incorrect. For instance struct pps_kinfo is padded 4 bytes
more in between info and timeout members.

What would be the best way to fix the padding issue without breaking
userspace applications? Just fixing the alignment with explicit
padding is of course the clean easy way, but bashing the data in
compat_ioctl would avoid breakage.


Thanks,

Matt

Re: [PATCH 2/2] iio: adc: hx711: Add IIO driver for AVIA HX711

[Matt Ranostay]

On Tue, Dec 13, 2016 at 10:02 AM, Andreas Klinger  wrote:
> This is the IIO driver for AVIA HX711 ADC which ist mostly used in weighting
> cells.

First off cool that this is finally getting a driver... I'll have to
get the SparkFun breakout and really cheap scale to test :).

>
> The protocol is quite simple and using GPIO's:
> One GPIO is used as clock (SCK) while another GPIO is read (DOUT)
>
> Signed-off-by: Andreas Klinger 
> ---
>  drivers/iio/adc/Kconfig  |  13 +++
>  drivers/iio/adc/Makefile |   1 +
>  drivers/iio/adc/hx711.c  | 269 
> +++
>  3 files changed, 283 insertions(+)
>  create mode 100644 drivers/iio/adc/hx711.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 932de1f9d1e7..7902b50fcf32 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -205,6 +205,19 @@ config HI8435
>   This driver can also be built as a module. If so, the module will be
>   called hi8435.
>
> +config HX711
> +   tristate "AVIA HX711 ADC for weight cells"
> +   depends on GPIOLIB
> +   help
> + If you say yes here you get support for AVIA HX711 ADC which is used
> + for weight cells
> +
> + This driver uses two GPIO's, one for setting the clock and the other
> + one for getting the data
> +
> + This driver can also be built as a module. If so, the module will be
> + called hx711.
> +
>  config INA2XX_ADC
> tristate "Texas Instruments INA2xx Power Monitors IIO driver"
> depends on I2C && !SENSORS_INA2XX
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index b1aa456e6af3..d46e289900ef 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -21,6 +21,7 @@ obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
>  obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
>  obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
>  obj-$(CONFIG_HI8435) += hi8435.o
> +obj-$(CONFIG_HX711) += hx711.o
>  obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o
>  obj-$(CONFIG_INA2XX_ADC) += ina2xx-adc.o
>  obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
> diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
> new file mode 100644
> index ..cbc89e467985
> --- /dev/null
> +++ b/drivers/iio/adc/hx711.c
> @@ -0,0 +1,269 @@
> +/*
> + * HX711: analog to digital converter for weight sensor module
> + *
> + * Copyright (c) Andreas Klinger 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define HX711_GAIN_32  2   /* gain = 32 for channel B  */
> +#define HX711_GAIN_64  3   /* gain = 64 for channel A  */
> +#define HX711_GAIN_128 1   /* gain = 128 for channel A */
> +
> +
> +struct hx711_data {
> +   struct device   *dev;
> +   dev_t   devt;
> +   struct gpio_desc*gpiod_sck;
> +   struct gpio_desc*gpiod_dout;
> +   int gain_pulse;
> +   struct mutexlock;
> +};
> +
> +static void hx711_reset(struct hx711_data *hx711_data)
> +{
> +   int val;
> +   int i;
> +
> +   val = gpiod_get_value(hx711_data->gpiod_dout);

could move the val assignment here to the initialization don't think
it will hit 80 chars

> +   if (val) {

move "int i" here to avoid compiler initialization warnings

> +   dev_warn(hx711_data->dev, "RESET-HX711\n");
> +
> +   gpiod_set_value(hx711_data->gpiod_sck, 1);
> +   udelay(80);

IIRC this chip has quite a bit of latency thresholds, can't use
usleep_range? Single core embedded systems could have an issue with
continuous  polling.

> +   gpiod_set_value(hx711_data->gpiod_sck, 0);
> +
> +   for (i = 0; i < 1000; i++) {
> +   val = gpiod_get_value(hx711_data->gpiod_dout);
> +   if (!val)
> +   break;
> +   /* sleep at least 1 ms*/
> +   msleep(1);
> +   }
> +   }
> +}
> +
> +static int hx711_cycle(struct hx711_data *hx711_data)
> +{
> +   int val;
> +
> +   /* if preempted for more then 60us while SCK is high:
> +* hx711 is going in reset
> +* ==> measuring is false
> +*/
> +  

Re: [PATCH 2/2] iio: adc: hx711: Add IIO driver for AVIA HX711

[Matt Ranostay]

On Tue, Dec 13, 2016 at 10:02 AM, Andreas Klinger  wrote:
> This is the IIO driver for AVIA HX711 ADC which ist mostly used in weighting
> cells.

First off cool that this is finally getting a driver... I'll have to
get the SparkFun breakout and really cheap scale to test :).

>
> The protocol is quite simple and using GPIO's:
> One GPIO is used as clock (SCK) while another GPIO is read (DOUT)
>
> Signed-off-by: Andreas Klinger 
> ---
>  drivers/iio/adc/Kconfig  |  13 +++
>  drivers/iio/adc/Makefile |   1 +
>  drivers/iio/adc/hx711.c  | 269 
> +++
>  3 files changed, 283 insertions(+)
>  create mode 100644 drivers/iio/adc/hx711.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 932de1f9d1e7..7902b50fcf32 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -205,6 +205,19 @@ config HI8435
>   This driver can also be built as a module. If so, the module will be
>   called hi8435.
>
> +config HX711
> +   tristate "AVIA HX711 ADC for weight cells"
> +   depends on GPIOLIB
> +   help
> + If you say yes here you get support for AVIA HX711 ADC which is used
> + for weight cells
> +
> + This driver uses two GPIO's, one for setting the clock and the other
> + one for getting the data
> +
> + This driver can also be built as a module. If so, the module will be
> + called hx711.
> +
>  config INA2XX_ADC
> tristate "Texas Instruments INA2xx Power Monitors IIO driver"
> depends on I2C && !SENSORS_INA2XX
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index b1aa456e6af3..d46e289900ef 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -21,6 +21,7 @@ obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
>  obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
>  obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
>  obj-$(CONFIG_HI8435) += hi8435.o
> +obj-$(CONFIG_HX711) += hx711.o
>  obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o
>  obj-$(CONFIG_INA2XX_ADC) += ina2xx-adc.o
>  obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
> diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
> new file mode 100644
> index ..cbc89e467985
> --- /dev/null
> +++ b/drivers/iio/adc/hx711.c
> @@ -0,0 +1,269 @@
> +/*
> + * HX711: analog to digital converter for weight sensor module
> + *
> + * Copyright (c) Andreas Klinger 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define HX711_GAIN_32  2   /* gain = 32 for channel B  */
> +#define HX711_GAIN_64  3   /* gain = 64 for channel A  */
> +#define HX711_GAIN_128 1   /* gain = 128 for channel A */
> +
> +
> +struct hx711_data {
> +   struct device   *dev;
> +   dev_t   devt;
> +   struct gpio_desc*gpiod_sck;
> +   struct gpio_desc*gpiod_dout;
> +   int gain_pulse;
> +   struct mutexlock;
> +};
> +
> +static void hx711_reset(struct hx711_data *hx711_data)
> +{
> +   int val;
> +   int i;
> +
> +   val = gpiod_get_value(hx711_data->gpiod_dout);

could move the val assignment here to the initialization don't think
it will hit 80 chars

> +   if (val) {

move "int i" here to avoid compiler initialization warnings

> +   dev_warn(hx711_data->dev, "RESET-HX711\n");
> +
> +   gpiod_set_value(hx711_data->gpiod_sck, 1);
> +   udelay(80);

IIRC this chip has quite a bit of latency thresholds, can't use
usleep_range? Single core embedded systems could have an issue with
continuous  polling.

> +   gpiod_set_value(hx711_data->gpiod_sck, 0);
> +
> +   for (i = 0; i < 1000; i++) {
> +   val = gpiod_get_value(hx711_data->gpiod_dout);
> +   if (!val)
> +   break;
> +   /* sleep at least 1 ms*/
> +   msleep(1);
> +   }
> +   }
> +}
> +
> +static int hx711_cycle(struct hx711_data *hx711_data)
> +{
> +   int val;
> +
> +   /* if preempted for more then 60us while SCK is high:
> +* hx711 is going in reset
> +* ==> measuring is false
> +*/
> +   preempt_disable();
> +   

[PATCH RESEND] tsl2550: fix lux1_input error in low light

[Matt Ranostay]

ADC channel 0 photodiode detects both infrared + visible light,
but ADC channel 1 just detects infrared. However, the latter is a bit
more sensitive in that range so complete darkness or low light causes
a error condition in which the chan0 - chan1 is negative that
results in a -EAGAIN.

This patch changes the resulting lux1_input sysfs attribute message from
"Resource temporarily unavailable" to a user-grokable lux value of 0.

Cc: Arnd Bergmann <a...@arndb.de>
Cc: Drew Fustini <pdp7p...@gmail.com>
Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
---
 drivers/misc/tsl2550.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/tsl2550.c b/drivers/misc/tsl2550.c
index 87a13374fdc0..eb5761067310 100644
--- a/drivers/misc/tsl2550.c
+++ b/drivers/misc/tsl2550.c
@@ -177,7 +177,7 @@ static int tsl2550_calculate_lux(u8 ch0, u8 ch1)
} else
lux = 0;
else
-   return -EAGAIN;
+   return 0;
 
/* LUX range check */
return lux > TSL2550_MAX_LUX ? TSL2550_MAX_LUX : lux;
-- 
2.7.4

[PATCH RESEND] tsl2550: fix lux1_input error in low light

[Matt Ranostay]

ADC channel 0 photodiode detects both infrared + visible light,
but ADC channel 1 just detects infrared. However, the latter is a bit
more sensitive in that range so complete darkness or low light causes
a error condition in which the chan0 - chan1 is negative that
results in a -EAGAIN.

This patch changes the resulting lux1_input sysfs attribute message from
"Resource temporarily unavailable" to a user-grokable lux value of 0.

Cc: Arnd Bergmann 
Cc: Drew Fustini 
Signed-off-by: Matt Ranostay 
---
 drivers/misc/tsl2550.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/tsl2550.c b/drivers/misc/tsl2550.c
index 87a13374fdc0..eb5761067310 100644
--- a/drivers/misc/tsl2550.c
+++ b/drivers/misc/tsl2550.c
@@ -177,7 +177,7 @@ static int tsl2550_calculate_lux(u8 ch0, u8 ch1)
} else
lux = 0;
else
-   return -EAGAIN;
+   return 0;
 
/* LUX range check */
return lux > TSL2550_MAX_LUX ? TSL2550_MAX_LUX : lux;
-- 
2.7.4

Re: [PATCH] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

On Tue, Nov 29, 2016 at 9:13 AM, Javier Martinez Canillas
<jav...@dowhile0.org> wrote:
> Hello Matt,
>
> On Thu, Nov 17, 2016 at 10:55 PM, Matt Ranostay
> <matt@ranostay.consulting> wrote:
>> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
>> This can be abstracted to other chipsets if needed in the future.
>>
>> Cc: Tony Lindgren <t...@atomide.com>
>> Cc: Ulf Hansson <ulf.hans...@linaro.org>
>> Cc: Mark Rutland <mark.rutl...@arm.com>
>> Cc: Srinivas Kandagatla <srinivas.kandaga...@linaro.org>
>> Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
>> ---
>>  .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt  |  14 +++
>>  .../bindings/net/wireless/marvell-sd8xxx.txt   |   4 +
>>  drivers/mmc/core/Kconfig   |  10 ++
>>  drivers/mmc/core/Makefile  |   1 +
>>  drivers/mmc/core/pwrseq_sd8787.c   | 117 
>> +
>>  5 files changed, 146 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>>  create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt 
>> b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>
> According Documentation/devicetree/bindings/submitting-patches.txt,
> the DT bindings patches should posted as a separate patch.

Ok will do.

>
>> new file mode 100644
>> index ..1b658351629b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>> @@ -0,0 +1,14 @@
>> +* Marvell SD8787 power sequence provider
>> +
>> +Required properties:
>> +- compatible: must be "mmc-pwrseq-sd8787".
>
> Since this is not a generic binding, the compatible string should have
> a vendor prefix.
>

Makes sense to me.


>> +- pwndn-gpio: contains a power down GPIO specifier.
>> +- reset-gpio: contains a reset GPIO specifier.
>> +
>
> I wonder if we really need a custom power sequence provider for just
> this SDIO WiFI chip though. AFAICT the only missing piece in
> mmc-pwrseq-simple is the power down GPIO property, so maybe
> mmc-pwrseq-simple could be extended instead to have an optional
> powerdown-gpios property and instead in the Marvell SD8787 DT binding
> can be mentioned which mmc-pwrseq-simple properties are required for
> the device.
>

The reason we didn't do that is we need delay between the two
assertions/desertions of GPIOs. It wouldn't seems good practice to
hack the pwrseq-simple for this...

>> +Example:
>> +
>> +   wifi_pwrseq: wifi_pwrseq {
>> +   compatible = "mmc-pwrseq-sd8787";
>> +   pwrdn-gpio = <_gpio 0 GPIO_ACTIVE_LOW>;
>> +   reset-gpio = <_gpio 1 GPIO_ACTIVE_LOW>;
>> +   }
>> diff --git 
>> a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt 
>> b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>
> Does this patch depend on a previous posted series? I don't see this
> file in today's linux-next...

Got renamed to ->
Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt it
seems very recently.

>
>> index c421aba0a5bc..08fd65d35725 100644
>> --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>> @@ -32,6 +32,9 @@ Optional properties:
>>  so that the wifi chip can wakeup host platform under 
>> certain condition.
>>  during system resume, the irq will be disabled to make sure
>>  unnecessary interrupt is not received.
>> +  - vmmc-supply: a phandle of a regulator, supplying VCC to the card
>> +  - mmc-pwrseq:  phandle to the MMC power sequence node. See "mmc-pwrseq-*"
>> +for documentation of MMC power sequence bindings.
>>
>>  Example:
>>
>> @@ -44,6 +47,7 @@ so that firmware can wakeup host using this device side 
>> pin.
>>   {
>> status = "okay";
>> vmmc-supply = <_en_reg>;
>> +   mmc-pwrseq = <_pwrseq>;
>> bus-width = <4>;
>> cap-power-off-card;
>> keep-power-in-suspend;
>
> I think this change should be split in a separate patch as well.
>
> Best regards,
> Javier

Re: [PATCH] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

On Tue, Nov 29, 2016 at 9:13 AM, Javier Martinez Canillas
 wrote:
> Hello Matt,
>
> On Thu, Nov 17, 2016 at 10:55 PM, Matt Ranostay
>  wrote:
>> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
>> This can be abstracted to other chipsets if needed in the future.
>>
>> Cc: Tony Lindgren 
>> Cc: Ulf Hansson 
>> Cc: Mark Rutland 
>> Cc: Srinivas Kandagatla 
>> Signed-off-by: Matt Ranostay 
>> ---
>>  .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt  |  14 +++
>>  .../bindings/net/wireless/marvell-sd8xxx.txt   |   4 +
>>  drivers/mmc/core/Kconfig   |  10 ++
>>  drivers/mmc/core/Makefile  |   1 +
>>  drivers/mmc/core/pwrseq_sd8787.c   | 117 
>> +
>>  5 files changed, 146 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>>  create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt 
>> b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>
> According Documentation/devicetree/bindings/submitting-patches.txt,
> the DT bindings patches should posted as a separate patch.

Ok will do.

>
>> new file mode 100644
>> index ..1b658351629b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>> @@ -0,0 +1,14 @@
>> +* Marvell SD8787 power sequence provider
>> +
>> +Required properties:
>> +- compatible: must be "mmc-pwrseq-sd8787".
>
> Since this is not a generic binding, the compatible string should have
> a vendor prefix.
>

Makes sense to me.


>> +- pwndn-gpio: contains a power down GPIO specifier.
>> +- reset-gpio: contains a reset GPIO specifier.
>> +
>
> I wonder if we really need a custom power sequence provider for just
> this SDIO WiFI chip though. AFAICT the only missing piece in
> mmc-pwrseq-simple is the power down GPIO property, so maybe
> mmc-pwrseq-simple could be extended instead to have an optional
> powerdown-gpios property and instead in the Marvell SD8787 DT binding
> can be mentioned which mmc-pwrseq-simple properties are required for
> the device.
>

The reason we didn't do that is we need delay between the two
assertions/desertions of GPIOs. It wouldn't seems good practice to
hack the pwrseq-simple for this...

>> +Example:
>> +
>> +   wifi_pwrseq: wifi_pwrseq {
>> +   compatible = "mmc-pwrseq-sd8787";
>> +   pwrdn-gpio = <_gpio 0 GPIO_ACTIVE_LOW>;
>> +   reset-gpio = <_gpio 1 GPIO_ACTIVE_LOW>;
>> +   }
>> diff --git 
>> a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt 
>> b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>
> Does this patch depend on a previous posted series? I don't see this
> file in today's linux-next...

Got renamed to ->
Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt it
seems very recently.

>
>> index c421aba0a5bc..08fd65d35725 100644
>> --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>> @@ -32,6 +32,9 @@ Optional properties:
>>  so that the wifi chip can wakeup host platform under 
>> certain condition.
>>  during system resume, the irq will be disabled to make sure
>>  unnecessary interrupt is not received.
>> +  - vmmc-supply: a phandle of a regulator, supplying VCC to the card
>> +  - mmc-pwrseq:  phandle to the MMC power sequence node. See "mmc-pwrseq-*"
>> +for documentation of MMC power sequence bindings.
>>
>>  Example:
>>
>> @@ -44,6 +47,7 @@ so that firmware can wakeup host using this device side 
>> pin.
>>   {
>> status = "okay";
>> vmmc-supply = <_en_reg>;
>> +   mmc-pwrseq = <_pwrseq>;
>> bus-width = <4>;
>> cap-power-off-card;
>> keep-power-in-suspend;
>
> I think this change should be split in a separate patch as well.
>
> Best regards,
> Javier

Re: [PATCH v3] media: i2c-polling: add i2c-polling driver

[Matt Ranostay]

On Wed, Nov 23, 2016 at 10:31 PM, Matt Ranostay
<matt@ranostay.consulting> wrote:
> On Wed, Nov 23, 2016 at 8:30 AM, Laurent Pinchart
> <laurent.pinch...@ideasonboard.com> wrote:
>> Hi Matt,
>>
>> Thank you for the patch.
>>
>> On Tuesday 22 Nov 2016 17:18:40 Matt Ranostay wrote:
>>> There are several thermal sensors that only have a low-speed bus
>>> interface but output valid video data. This patchset enables support
>>> for the AMG88xx "Grid-Eye" sensor family.
>>>
>>> Cc: Attila Kinali <att...@kinali.ch>
>>> Cc: Marek Vasut <ma...@denx.de>
>>> Cc: Luca Barbato <lu_z...@gentoo.org>
>>> Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
>>> ---
>>> Changes from v1:
>>> * correct i2c_polling_remove() operations
>>> * fixed delay calcuation in buffer_queue()
>>> * add include linux/slab.h
>>>
>>> Changes from v2:
>>> * fix build error due to typo in include of slab.h
>>>
>>>  drivers/media/i2c/Kconfig   |   8 +
>>>  drivers/media/i2c/Makefile  |   1 +
>>>  drivers/media/i2c/i2c-polling.c | 469 +
>>
>> Just looking at the driver name I believe a rename is needed. i2c-polling is 
>> a
>> very generic name and would mislead many people into thinking about an I2C
>> subsystem core feature instead of a video driver. "video-i2c" is one option,
>> I'm open to other ideas.
>>
>>>  3 files changed, 478 insertions(+)
>>>  create mode 100644 drivers/media/i2c/i2c-polling.c
>>>
>>> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
>>> index b31fa6fae009..d840e7be0036 100644
>>> --- a/drivers/media/i2c/Kconfig
>>> +++ b/drivers/media/i2c/Kconfig
>>> @@ -768,6 +768,14 @@ config VIDEO_M52790
>>>
>>>To compile this driver as a module, choose M here: the
>>>module will be called m52790.
>>> +
>>> +config VIDEO_I2C_POLLING
>>> + tristate "I2C polling video support"
>>> + depends on VIDEO_V4L2 && I2C
>>> + select VIDEOBUF2_VMALLOC
>>> + ---help---
>>> +   Enable the I2C polling video support which supports the following:
>>> +* Panasonic AMG88xx Grid-Eye Sensors
>>>  endmenu
>>>
>>>  menu "Sensors used on soc_camera driver"
>>> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
>>> index 92773b2e6225..8182ec9f66b9 100644
>>> --- a/drivers/media/i2c/Makefile
>>> +++ b/drivers/media/i2c/Makefile
>>> @@ -79,6 +79,7 @@ obj-$(CONFIG_VIDEO_LM3646)  += lm3646.o
>>>  obj-$(CONFIG_VIDEO_SMIAPP_PLL)   += smiapp-pll.o
>>>  obj-$(CONFIG_VIDEO_AK881X)   += ak881x.o
>>>  obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
>>> +obj-$(CONFIG_VIDEO_I2C_POLLING)  += i2c-polling.o
>>>  obj-$(CONFIG_VIDEO_ML86V7667)+= ml86v7667.o
>>>  obj-$(CONFIG_VIDEO_OV2659)   += ov2659.o
>>>  obj-$(CONFIG_VIDEO_TC358743) += tc358743.o
>>> diff --git a/drivers/media/i2c/i2c-polling.c
>>> b/drivers/media/i2c/i2c-polling.c new file mode 100644
>>> index ..46a4eecde2d2
>>> --- /dev/null
>>> +++ b/drivers/media/i2c/i2c-polling.c
>>> @@ -0,0 +1,469 @@
>>> +/*
>>> + * i2c_polling.c - Support for polling I2C video devices
>>> + *
>>> + * Copyright (C) 2016 Matt Ranostay <mranostay@ranostay.consulting>
>>> + *
>>> + * Based on the orginal work drivers/media/parport/bw-qcam.c
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation; either version 2 of the License, or
>>> + * (at your option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + * Supported:
>>> + * - Panasonic AMG88xx Grid-Eye Sensors
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>
>> I don't think you implement device tree support, is linux/of.h needed ? Or
>> maybe you could implement device tree support ;-)
>>
>>> +#include

Re: [PATCH v3] media: i2c-polling: add i2c-polling driver

[Matt Ranostay]

On Wed, Nov 23, 2016 at 10:31 PM, Matt Ranostay
 wrote:
> On Wed, Nov 23, 2016 at 8:30 AM, Laurent Pinchart
>  wrote:
>> Hi Matt,
>>
>> Thank you for the patch.
>>
>> On Tuesday 22 Nov 2016 17:18:40 Matt Ranostay wrote:
>>> There are several thermal sensors that only have a low-speed bus
>>> interface but output valid video data. This patchset enables support
>>> for the AMG88xx "Grid-Eye" sensor family.
>>>
>>> Cc: Attila Kinali 
>>> Cc: Marek Vasut 
>>> Cc: Luca Barbato 
>>> Signed-off-by: Matt Ranostay 
>>> ---
>>> Changes from v1:
>>> * correct i2c_polling_remove() operations
>>> * fixed delay calcuation in buffer_queue()
>>> * add include linux/slab.h
>>>
>>> Changes from v2:
>>> * fix build error due to typo in include of slab.h
>>>
>>>  drivers/media/i2c/Kconfig   |   8 +
>>>  drivers/media/i2c/Makefile  |   1 +
>>>  drivers/media/i2c/i2c-polling.c | 469 +
>>
>> Just looking at the driver name I believe a rename is needed. i2c-polling is 
>> a
>> very generic name and would mislead many people into thinking about an I2C
>> subsystem core feature instead of a video driver. "video-i2c" is one option,
>> I'm open to other ideas.
>>
>>>  3 files changed, 478 insertions(+)
>>>  create mode 100644 drivers/media/i2c/i2c-polling.c
>>>
>>> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
>>> index b31fa6fae009..d840e7be0036 100644
>>> --- a/drivers/media/i2c/Kconfig
>>> +++ b/drivers/media/i2c/Kconfig
>>> @@ -768,6 +768,14 @@ config VIDEO_M52790
>>>
>>>To compile this driver as a module, choose M here: the
>>>module will be called m52790.
>>> +
>>> +config VIDEO_I2C_POLLING
>>> + tristate "I2C polling video support"
>>> + depends on VIDEO_V4L2 && I2C
>>> + select VIDEOBUF2_VMALLOC
>>> + ---help---
>>> +   Enable the I2C polling video support which supports the following:
>>> +* Panasonic AMG88xx Grid-Eye Sensors
>>>  endmenu
>>>
>>>  menu "Sensors used on soc_camera driver"
>>> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
>>> index 92773b2e6225..8182ec9f66b9 100644
>>> --- a/drivers/media/i2c/Makefile
>>> +++ b/drivers/media/i2c/Makefile
>>> @@ -79,6 +79,7 @@ obj-$(CONFIG_VIDEO_LM3646)  += lm3646.o
>>>  obj-$(CONFIG_VIDEO_SMIAPP_PLL)   += smiapp-pll.o
>>>  obj-$(CONFIG_VIDEO_AK881X)   += ak881x.o
>>>  obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
>>> +obj-$(CONFIG_VIDEO_I2C_POLLING)  += i2c-polling.o
>>>  obj-$(CONFIG_VIDEO_ML86V7667)+= ml86v7667.o
>>>  obj-$(CONFIG_VIDEO_OV2659)   += ov2659.o
>>>  obj-$(CONFIG_VIDEO_TC358743) += tc358743.o
>>> diff --git a/drivers/media/i2c/i2c-polling.c
>>> b/drivers/media/i2c/i2c-polling.c new file mode 100644
>>> index ..46a4eecde2d2
>>> --- /dev/null
>>> +++ b/drivers/media/i2c/i2c-polling.c
>>> @@ -0,0 +1,469 @@
>>> +/*
>>> + * i2c_polling.c - Support for polling I2C video devices
>>> + *
>>> + * Copyright (C) 2016 Matt Ranostay 
>>> + *
>>> + * Based on the orginal work drivers/media/parport/bw-qcam.c
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation; either version 2 of the License, or
>>> + * (at your option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + * Supported:
>>> + * - Panasonic AMG88xx Grid-Eye Sensors
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>
>> I don't think you implement device tree support, is linux/of.h needed ? Or
>> maybe you could implement device tree support ;-)
>>
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +