linux-kernel - Re: [PATCH v3 0/2] Support accelerometers for veyron

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 26 Jun 2019 22:40:00 +0200
From:   Enric Balletbo i Serra <enric.balletbo@...labora.com>
To:     Jonathan Cameron <jic23@...nel.org>
Cc:     Gwendal Grignou <gwendal@...omium.org>, bleung@...omium.org,
        groeck@...omium.org, fabien.lahoudere@...labora.com,
        dianders@...omium.org, linux-iio@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/2] Support accelerometers for veyron_minnie

Hi Jonathan,

On 26/6/19 21:21, Jonathan Cameron wrote:
> On Tue, 25 Jun 2019 19:09:50 +0200
> Enric Balletbo i Serra <enric.balletbo@...labora.com> wrote:
> 
>> Hi,
>>
>> On 25/6/19 0:53, Gwendal Grignou wrote:
>>> veyron_minnie - ASUS Chromebook Flip C100PA - embedded controller
>>> controls two accelerometers, one in the lid, one in the base.
>>> However, the EC firmware does not follow the new interface that
>>> cros_ec_accel driver use.
>>> Extend the legacy driver used on glimmer - Lenovo ThinkPad 11e
>>> Chromebook - to veyron_minnie.
>>> veyron_minnie being ARM based, issue command over the I2C bus to the EC
>>> instead of relying on the shared registers over LPC.
>>>
>>> Gwendal Grignou (2):
>>>   iio: cros_ec: Add sign vector in core for backward compatibility
>>>   iio: cros_ec: Extend legacy support to ARM device
>>>
>>> Changes in v3:
>>> - Fix commit message, add reviewed-by for first patch.
>>>
>>> Changes in v2:
>>> - Readd empty line to reduce amount of change in patch.
>>> - Remove Keywords used by ChromeOS commit queue.
>>>
>>>  drivers/iio/accel/Kconfig                     |   4 +-
>>>  drivers/iio/accel/cros_ec_accel_legacy.c      | 350 ++++--------------
>>>  .../cros_ec_sensors/cros_ec_sensors_core.c    |   4 +
>>>  .../linux/iio/common/cros_ec_sensors_core.h   |   1 +
>>>  4 files changed, 84 insertions(+), 275 deletions(-)
>>>   
>>
>> Just a side note that I think that this patch depends on [1] to have the legacy
>> sensors working on veyron minnie.
>>
>> For the full series:
>>
>> Tested-by: Enric Balletbo i Serra <enric.balletbo@...labora.com>
> Ah. I was assuming you mean a runtime dependency.  Whereas applying this
> on it's own is giving me a build problem:
> 
>  drivers/iio/accel/cros_ec_accel_legacy.c: In function ‘cros_ec_accel_legacy_read_cmd’:
> drivers/iio/accel/cros_ec_accel_legacy.c:50:16: error: ‘struct <anonymous>’ has no member named ‘max_sensor_count’

Right, this also build depends on the immutable branch (ib-mfd-cros-v5.3).


>    50 |  st->param.dump.max_sensor_count = CROS_EC_SENSOR_LEGACY_NUM;
>       |                ^
> make[3]: *** [scripts/Makefile.build:285: drivers/iio/accel/cros_ec_accel_legacy.o] Error 1
> make[2]: *** [scripts/Makefile.build:489: drivers/iio/accel] Error 2
> make[1]: *** [scripts/Makefile.build:489: drivers/iio] Error 2
> 
> Which I'll assume is related to that other set.
> 
> I'm happy for these to go another route to sit on top of that series.
> If not I'll pick them up for the next cycle via IIO.
> 
> Should they go another route,
> 
> Acked-by: Jonathan Cameron <Jonathan.Cameron@...wei.com> for both of them.

I'd be happy to pick this patch and add to the chrome-platform tree, ideally
once we manage to get [1] ready for land.

Thanks,
~ Enric

> 
>>
>>
>> [1] https://lkml.org/lkml/2019/6/18/268
>