User userspace access to I2C device acquired by kernel driver

User userspace access to I2C device acquired by kernel driver

[Patryk]

Hi,
Suppose that I have an I2C device (CPLD MAX10 with custom
configuration) that implements the following functionalities:
- GPIO Expander && Interrupt controller
- Watchdog

Suppose that I want to create a Kernel driver that will handle GPIO
Expander and Interrupt controller parts whereas the watchdog
functionality will be handled in Userspace using /sys/class/i2c-dev

Correct me if I'm wrong - but if the kernel driver claims that it
handles the communication with a particular device, does it
automatically prevent userspace programs from communicating with this
device using i2c-dev? So splitting responsibilities between kernel and
userspace which both handle the same physical device will not work,
yes?
For me it makes sense because accessing the device that is already
used by a kernel, from userspace might be unexpected by the kernel,
however, I haven't found any solid confirmation (it may be my poor
research though)

Best regards
Patryk

Re: User userspace access to I2C device acquired by kernel driver

[Stefan Lengfeld]

Hi Patryk,

On Tue, Mar 26, 2024 at 01:26:10PM +0100, Patryk wrote:
> Suppose that I want to create a Kernel driver that will handle GPIO
> Expander and Interrupt controller parts whereas the watchdog
> functionality will be handled in Userspace using /sys/class/i2c-dev
> 
> Correct me if I'm wrong - but if the kernel driver claims that it
> handles the communication with a particular device, does it
> automatically prevent userspace programs from communicating with this
> device using i2c-dev?

Yes, if a device is claimed by a kernel driver, userspace cannot claim
it again. This prevents accidental usages of I2C devices from userspace.

> So splitting responsibilities between kernel and userspace which both
> handle the same physical device will not work, yes?

No, it can work. For the i2c-dev userspace API there exists the flag 

    #define I2C_SLAVE_FORCE	0x0706	/* Use this slave address, even if it
    				           is already in use by a driver! */

See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/i2c-dev.h#n29

So userspace can override the safety check and also use the I2C device,
by providing this flag.

> For me it makes sense because accessing the device that is already
> used by a kernel, from userspace might be unexpected by the kernel,
> however, I haven't found any solid confirmation (it may be my poor
> research though)

Yes, you can very easily mess things up, if a kernel driver and a
userspace driver uses the same device at once. It would require
carefully programming and coordination to make it work correctly and
robust. Nevertheless if you really really want it, you can do it.

But why? 

> Suppose that I have an I2C device (CPLD MAX10 with custom
> configuration) that implements the following functionalities:
> - GPIO Expander && Interrupt controller
> - Watchdog

It's possible and already done to implement a kernel watchdog driver and
combine all the functionalites (gpio expander, interrupt controller and
watchdog) in a multi-function device (MFD)[1],

Kind regards,
Stefan

[1]: https://bootlin.com/pub/conferences/2015/elce/belloni-mfd-regmap-syscon/belloni-mfd-regmap-syscon.pdf

-- 
website:     https://stefan.lengfeld.xyz/
pgp-key id:  0xE44A23B289092311
download:    https://stefan.lengfeld.xyz/key.gpg
fingerprint: CAFC B28D 1612 3A5C 2D31  45F0 E44A 23B2 8909 2311

Re: User userspace access to I2C device acquired by kernel driver

[Patryk]

Hi Stefan,

czw., 28 mar 2024 o 00:33 Stefan Lengfeld <stefan@lengfeld.xyz> napisał(a):
> It's possible and already done to implement a kernel watchdog driver and
> combine all the functionalites (gpio expander, interrupt controller and
> watchdog) in a multi-function device (MFD)[1],
> [1]: https://bootlin.com/pub/conferences/2015/elce/belloni-mfd-regmap-syscon/belloni-mfd-regmap-syscon.pdf

This is even more information than I could expect, and that's totally
satisfying for me, I'll also explore MFD devices a bit more, as I have
a feeling that I've already seen something like this in the tps65086
device driver.

Best regards,
Patryk