[PATCH linux dev-4.10 v2] arm: dts: aspeed: Add IR35221 instances to dev tree

[Joel Stanley]

On Thu, May 25, 2017 at 10:54 AM, Brad Bishop
<bradleyb at fuzziesquirrel.com> wrote:

>>>> This breaks userspace, as userspace assumes it can access the i2c
>>>> devices through /dev/i2c-x.
>>>>
>>>
>>> Joel, or anyone able to answer…
>>>
>>> Do you know which application?  I wasn’t aware of any applications using i2c-dev...
>>
>> The one I noticed was vrm-control.sh.

> I’m not sure how to handle this.  We obviously still need to run these workarounds,
> but we also need the regulator temperatures.
>
> The only thing I can think of is exposing what these scripts need via sysfs attributes.
>
> Is there any alternative?

There are two options:

Write from userspace

We could unbind the driver, make the relevant configuration changes in
userspace, and then re-bind the driver. This has the benefit of being
sure that the driver will still work, and does not require any kernel
work.

A sub-option of this is to do the same without unbinding the driver.
Userspace can specify a "force" flag in the ioctl, which allows it to
write to the i2c device even when a kernel driver is bound. The upside
here is less messing around with unbinding, but the drawback is
userspace may change the hardware state that the driver depends on,
leading to instability. We could audit the drivers to make sure the
state we're changing from userspace does not affect the driver, and/or
fix the driver so it still behaves.

Add functionality to the driver

Look at adding the required configuration to the driver. Either
through device tree properties, or sysfs files. This is would require
looking at the writes we need to do, and working out how they can be
integrated.

As discussed today, we will go with writing from userspace after
unbinding the driver.

As I've already merged the ir35221 patch into the kernel, completing
the unbinding work is blocking an update of the kernel. Do we have a
ticket opened for this work?

Cheers,

Joel