[My apology - this editor apparently removes all the blank spaces, thus messing up the simple diagram. Just note there're two dashed lines each representing an I2C bus. And there're two I2C devices mentioned: dev-1 and dev-m, representing 'm' devices on the 2nd I2C bus]

First let me depict the system blocks:

I2C-0 I2C
CPU ------------- uC ---+------------+----
| |
dev-1 ..... dev-m

There is an I2C bus master on the CPU. It's already UP and running, and shows up as /dev/i2c-0. There is another micro-controller (uC) connected to the CPU, and it implements another I2C bus. The driver (.ko and .so) running on CPU is already available for this I2C bus. Hanging off it is a bunch of I2C devices we already supported on a different platform.

We want to reuse much of these I2C device drivers and application codes. Where should we make change to integrate the .ko and .so to port these drivers over with minimal code changes, and without destroying the /dev/i2c-0 functionalities?

By the same token, and hopefully, public domain utilities like i2cget, i2cset could also be used to access this 2nd i2c bus.

Configure your Linux system to add the second I2C bus and then use the applications code you have. You do not need to port a driver.

When you say port, where did you get the source from? That is really the key to what you need to do.

Does this setup work on any OS?



Some version of linux or what. Some of these devices have some support by the OEM's too.

Plenty of sites have help.
https://www.kernel.org/doc/Documenta.../dev-interface
https://elinux.org/Interfacing_with_I2C_Devices

Maybe there is misunderstanding. We already have a lot of codes, drivers and applications, sitting on all the I2C devices from another platform. This new platform copies a lot of those hardware design, except the I2C controller is replaced. If we try to simply use the new driver directly, we could be changing a lot of codes, as the signatures of the drivers are different. Alternative is to write wrappers.

The new I2C driver (.ko and .so) is released by the vendor providing us the CPU module. I'm thinking about "plug and play" - plugging in the new I2C driver somewhere, and the rest of the I2C dependent codes simply work. I've been looking into the I2C driver architecture, in which they talk about Client, Core, Adaptor, Bus, Class, Algorithm etc., along the line of the Linux Kernel Driver Model. At this point, I've a feeling we may need to look into defining wrapping for the bus/algorithm objects.

To answer your specific question - this 3rd party driver is proven to work on Linux (YP), as we run its demo code, and had implemented some i2cget/i2cset utilities on top of it.
Thoughts?

Your question is rather broad. Is there anything more specific?

Hi AwesomMachine, have you read my original post? I thought all needed background information is there, and the specific question is also there.