Re: [PATCH 2/3] ARM: dts: uniphier: add ProXstream2 Vodka board support

[Arnd Bergmann]

On Friday 16 October 2015 14:24:30 Masahiro Yamada wrote:
> 
> No, it is not a typo, but intentional.
> 
> 
> i2c0 - i2c3 are connected to the pads of the SoC package.
> On the other hand, i2c-4 - i2c-6 are connected to
> internal devices inside the SoC package.
> 
> i2c-4 - i2c-6 are always connected to the same hardware
> devices and always used for the same purpose.
> 
> 
> My expected scenario is:
> 
> [1] i2c0 - i2c3 are connected to the on-board devices
>     depending on board variants.
>     On some boards, their status is "okay" and
>     on some boards, their status is "disabled".
> 
> [2] i2c4 - i2c6 are always used to communicate
>     with in-package devices.  The status is always "okay".

I think you are getting confused because the data sheet uses
the same names as the kernel, but they are really different
things.

How about boards that have i2c connectors that are labeled
differently?

We want the aliases to match whatever is written on the
board normally, to make it easier for users.

> [3] Some user-land applications may want to have access
>      through the same character devices,
>       /dev/i2c4, /dev/i2c5, /dev/i2c6

That user space would however only work on boards with the
same SoC, which is not a safe assumption to make. Either
it should be specific to just one board which has a known
set of buses, or it should be done in a way that works
across SoC generations of families.

Ideally the devices on the internal buses would have an
in-kernel driver that exports a high-level API to avoid this
problem. What devices are these?

> If your way is adopted,
> the real hardware "i2c4" might be aligned to /dev/i2c1 on some boards,
> and /dev/i2c2 on others, etc.

Right, I think that is how it should be. You could also make
the chip's i2c4 always link to user space /dev/i2c0 if you
want to keep those stable, but as I said that is still not
a good (software) system design.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/