lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 29 Mar 2020 10:31:14 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     Gwendal Grignou <gwendal@...omium.org>
Cc:     Benson Leung <bleung@...omium.org>,
        Enric Balletbo i Serra <enric.balletbo@...labora.com>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        linux-iio <linux-iio@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v7 12/12] iio: cros_ec: flush as hwfifo attribute

On Sat, 28 Mar 2020 17:33:48 -0700
Gwendal Grignou <gwendal@...omium.org> wrote:

> On Sat, Mar 28, 2020 at 10:22 AM Jonathan Cameron
> <jic23@...23.retrosnub.co.uk> wrote:
> >
> > On Fri, 27 Mar 2020 15:34:43 -0700
> > Gwendal Grignou <gwendal@...omium.org> wrote:
> >  
> > > Add buffer/hwfifo_flush. It is not part of the ABI, but it follows ST
> > > and HID lead: Tells the sensor hub to send to the host all pending
> > > sensor events.
> > >
> > > Signed-off-by: Gwendal Grignou <gwendal@...omium.org>  
> >
> > Unless I'm missing something there aren't any other drivers providing
> > an explicit flush attribute.  
> The flush attribute comes from a  requirement from Android to ask the
> sensorhub to flush the samples still in its FIFO queue. (see
> https://source.android.com/devices/sensors/hal-interface#flush_sensor)
> It has been implemented in the ST Android HAL, which expects a
> hw_fifo_flush attribute.:
> https://github.com/STMicroelectronics/STMems_Android_Sensor_HAL_IIO/blob/STMems_Android_Sensor_HAL_IIO/src/utils.cpp#L31
> 
> But I misread kernel ST code; as you said, the request to flush
> appends only when the buffer is enabled/disabled or the sensor
> suspended, it is not exposed to user space.
> 
> For Bosh sensor : there is a patch that was proposed a while back:
> "http://lkml.iu.edu/hypermail/linux/kernel/1504.3/03270.html", but it
> never reached mainline.
> 
> For HID, the attribute is defined in the HID specification (31C) :
> https://www.usb.org/sites/default/files/hutrr59_-_usages_for_wearables_0.pdf
> but I could not find a publicly available proposed change request that uses it.
> 
> Anyhow, it was a mistake to put this patch in the current patch set. I
> need it on chromebook for supporting Android, but it should be
> discussed more widely to have it part of the ABI, or define a better
> solution.
> 
> > The nearest equivalent is the flush
> > callback which reads out stuff that is in a fifo to be read, but which
> > hasn't yet reached a watermark to trigger normal readback.
> >
> > Can we do something similar here?
> >
> > If not this needs ABI documentation in Documentation/ABI/testing/...
> > I'm not keen on it in becoming general ABI unless I'm missing a
> > strong argument in favour of it.
> >
> > Jonathan  
> Thank you for your support,
> Gwendal.

Agreed, lets separate this one out for now.

So Enric, please pick up patches 1-11 and we can revisit this one
as a separate series.

Thanks!

Jonathan

> >
> >  
> > > ---
> > > No changes in v7.
> > > New in v6.
> > >
> > >  .../cros_ec_sensors/cros_ec_sensors_core.c    | 28 +++++++++++++++++++
> > >  1 file changed, 28 insertions(+)
> > >
> > > diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> > > index c831915ca7e56..aaf124a82e0e4 100644
> > > --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> > > +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> > > @@ -113,6 +113,33 @@ static int cros_ec_sensor_set_ec_rate(struct cros_ec_sensors_core_state *st,
> > >       return ret;
> > >  }
> > >
> > > +static ssize_t cros_ec_sensors_flush(struct device *dev,
> > > +                                  struct device_attribute *attr,
> > > +                                  const char *buf, size_t len)
> > > +{
> > > +     struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> > > +     struct cros_ec_sensors_core_state *st = iio_priv(indio_dev);
> > > +     int ret = 0;
> > > +     bool flush;
> > > +
> > > +     ret = strtobool(buf, &flush);
> > > +     if (ret < 0)
> > > +             return ret;
> > > +     if (!flush)
> > > +             return -EINVAL;
> > > +
> > > +     mutex_lock(&st->cmd_lock);
> > > +     st->param.cmd = MOTIONSENSE_CMD_FIFO_FLUSH;
> > > +     ret = cros_ec_motion_send_host_cmd(st, 0);
> > > +     if (ret != 0)
> > > +             dev_warn(&indio_dev->dev, "Unable to flush sensor\n");
> > > +     mutex_unlock(&st->cmd_lock);
> > > +     return ret ? ret : len;
> > > +}
> > > +
> > > +static IIO_DEVICE_ATTR(hwfifo_flush, 0644, NULL,
> > > +                    cros_ec_sensors_flush, 0);
> > > +
> > >  static ssize_t cros_ec_sensor_set_report_latency(struct device *dev,
> > >                                                struct device_attribute *attr,
> > >                                                const char *buf, size_t len)
> > > @@ -175,6 +202,7 @@ static ssize_t hwfifo_watermark_max_show(struct device *dev,
> > >  static IIO_DEVICE_ATTR_RO(hwfifo_watermark_max, 0);
> > >
> > >  const struct attribute *cros_ec_sensor_fifo_attributes[] = {
> > > +     &iio_dev_attr_hwfifo_flush.dev_attr.attr,
> > >       &iio_dev_attr_hwfifo_timeout.dev_attr.attr,
> > >       &iio_dev_attr_hwfifo_watermark_max.dev_attr.attr,
> > >       NULL,  
> >  

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ