Re: phosphor-bittware repository

[Patrick Williams <patrick@stwcx.xyz>]

[-- Attachment #1: Type: text/plain, Size: 1775 bytes --]

On Tue, May 19, 2020 at 06:47:48AM +0000, Ben_Pai@wistron.com wrote:
> Because the 250-soc card needs to adjust the io expander to get the relevant information (e.g. temperature, VPD ...).

Is this IO expander on the i2c bus itself, like a mux or hub, or is it
some specialized register set to switch between logic banks?  In either
case though, I don't know why you couldn't create a kernel driver for
controlling access to the various logic blocks.  If it is like an
i2c-mux, there is a number of implementations of that in the kernel
already.

> I think a dynamic detection function may be needed to handle the presence of the card and dynamically adjust the io expander.

I'm not sure what you mean by "dynamic detection function" here.  If you
just mean detecting the presence of the card by a GPIO or i2c probe
call, entity-manager can handle some of that for you, I believe.  You
don't need to put the card into the device tree directly, but you could
instead do some kind of probe call to ensure the device is present and
then manually 'bind' the i2c address to a kernel driver.  Entity-manager
already supports doing this.

> On the other hand, I just want to be able to integrate all the functions.

I think you're going to end up duplicating a lot of code that already exists
in the kernel this way and that is why I'm trying to steer you away from
it.  Just as a simple example on the sensors, we have two
implementations that can already consume Linux-hwmon data and give you
the dbus objects "for free".  If you go the direction of putting it all
in userspace, you're going to have to implement all the i2c activity,
hwmon-like polling, and dbus objects all yourself.  This isn't a trivial
amount of code.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]