lkml.org 
[lkml]   [2022]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 2/2] drivers/misc: add transfer ioctl for HPS
On Mon, Jan 31, 2022 at 9:23 AM Sami Kyostila <skyostil@chromium.org> wrote:
>
> I guess we could add an LSM hook for I2C transfers, but that would
> require baking device addresses into the SELinux policy which seems a
> little unfortunate.
>
> I think that leaves the options suggested by Arnd (thanks!):
>
> a) Add a generic way to expose device nodes for individual I2C devices
> (something like /dev/i2c/by-id/NN?).
>
> b) Make the ioctl interface more fully featured instead of just exposing I2C.
>
> I think I'm leaning toward (a) since it's not yet totally clear what
> the right high level abstraction for this type of device is (e.g.,
> should it be HID, in which case the protocol should probably become
> HID-I2C).

(adding i2c list to cc)

I think the implementation of the character device should be really
straightforward, it can probably just use the exact same ioctls
as the normal device, or a subset of them, and filter out any access
that has the wrong address with ioctl(fd, I2C_SLAVE, ...) or other
commands.

The tricky part is coming up with a sensible way of creating those
character device nodes, as there generic method of knowing what
is attached to the bus. I suppose this could be done either
automatically based on the nodes in DT, or it could be done
with user interaction like a new ioctl command on the normal
device node or some sysfs interface to create the chardev for
a particular slave device.

Arnd

\
 
 \ /
  Last update: 2022-01-31 13:53    [W:0.051 / U:2.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site