On 2/22/08, Jochen Friedrich <[EMAIL PROTECTED]> wrote:
> Hi Jean,
>
>
> >> +/*
> >> + * Wait for patch from Jon Smirl
> >> + * #include "powerpc-common.h"
> >> + */
> >
> > It doesn't make sense to merge this comment upstream.
>
>
> I know you don't like the patch from Jon Smirl and you also explained your
> reasons.
> Fortunately, I2c no longer uses numeric device IDs but names. So what are
> the alternatives?
>
> 1. modify the I2c subsystem to accept OF names additionally to I2c names
> (proposed by Jon smirl).
The correct statement is: modify the i2c subsystem to support the
standard kernel driver aliasing mechanism. Leaving powerpc and OF out
of the argument for the moment, i2c has a custom aliasing scheme on
the x86 too.
So as a first step, can we remove the custom i2c aliasing scheme and
change i2c to use standard module aliases on the x86? Patches for this
already exist.
On 2/23/08, Jean Delvare <[EMAIL PROTECTED]> wrote:
> The problem I have with this is that it breaks compatibility. The chip
> name is not only used for device/driver matching, it is also exported
> to userspace as a sysfs attribute ("name"). Applications might rely on
> it. At least libsensors does.
I think there is some confusion here. The OF aliases are only used by
the kernel to load the correct driver. Would doing something like this
help?
static struct i2c_device_id pcf8563_id[] = {
{"pcf8563", 0, "sysfs_legacy_name"},
{"rtc8564", 0, "sysfs_legacy_name"},
OF_ID("phillips,pcf8563", &pcf8563_id[0], 0)
OF_ID("epson,rtc8564", &pcf8563_id[1], 0)
{},
};
MODULE_DEVICE_TABLE(i2c, pcf8563_id);
Then in the probe function you can use the pointer to find the base id
entry and i2c never has to be aware that the OF alias exists.
> 2. record the I2c name in the dts tree, either as separate tag (like
> linux,i2c-name="<i2c-name>")
Not really practical for the millions of machines (all PowerPC Macs)
already shipped.
> or as additional compatible entry (like compatible="...",
> "linux,<i2c-name>").
> 3. use a glue layer with a translation map.
Audio codecs have exactly the same problem. There are probably other
devices that also need mapping.
This mapping table will need to contain a map from the OF names to the
kernel driver names. It will need to stored permanently in RAM and
contain all possible mappings. This table will only grow in size.
The kernel has a widely used mechanism for mapping -- aliases in the
device drivers. Why do we want to build a new, parallel one?
What we are doing now is option 4.
4. Use kconfig to build custom kernels for each target system. Don't
load drivers automatically based on what the BIOS tells us.
--
Jon Smirl
[EMAIL PROTECTED]
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
