linux-kernel - Re: [PATCH 0/3] LEGO MINDSTORMS I2C support

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:   Fri, 16 Sep 2016 15:05:45 -0500
From:   David Lechner <david@...hnology.com>
To:     Wolfram Sang <wsa@...-dreams.de>
Cc:     linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] LEGO MINDSTORMS I2C support

On 09/15/2016 03:00 PM, Wolfram Sang wrote:
> On Mon, Sep 05, 2016 at 03:40:11PM -0500, David Lechner wrote:
>> I'm working on getting LEGO MINDSTORMS[1] support in the Linux kernel.
>>
>> They have a system of modular sensors that are hot-plugable, some of which use
>> I2C communications. Unfortunately, these don't necessary follow standard I2C
>> conventions, but they do have a well-defined register layout, so they are
>> easy to detect.
>>
>> This set of patches addresses the hot-plugability of the sensors.
>>
>> [1]: http://mindstorms.lego.com
>
> Thanks!
>
> For a review, I'd need users of this functionality. In this case, a
> master driver and probably a sensor driver.

Work in progress drivers:

master: 
https://github.com/ev3dev/lego-linux-drivers/blob/master/ev3/legoev3_i2c.c
master: 
https://github.com/ev3dev/lego-linux-drivers/blob/master/evb/evb_pru_i2c.c
sensor: 
https://github.com/ev3dev/lego-linux-drivers/blob/master/sensors/nxt_i2c_sensor_core.c

> Can any regular I2C master
> talk to these devices if they support talking to addresses 0x00-0x7f?

Yes. I've tested this with the SoC I2C on Raspberry Pi. There are 
several 3rd party LEGO MINDSTORMS compatible addon boards for RPi that 
use the SoC I2C with LEGO sensors, which is part of my motivation for 
this patchset.

> My first impression is that using a class is not the proper approach
> because classes were used to limit access to devices, not to extend.
> However, I'd need to see more code to check if that holds true.
>

I'm certainly open to other suggestions. This just seemed like the 
obvious way to me.