Re: i2c-eg20t: regression since i2c_add_numbered_adapter change

From: Feng Tang
Date: Thu Aug 23 2012 - 04:34:25 EST


Hi,

On Wed, 22 Aug 2012 11:17:51 +0200
Alexander Stein <alexander.stein@xxxxxxxxxxxxxxxxxxxxx> wrote:

> Hello,
>
> Am Mittwoch, 22. August 2012, 16:04:39 schrieb Feng Tang:
> > > Why use a fixed one? Give the driver (and maybe every i2c bus driver) a parameter which sets the base bus number it should use.
> > > E.g. i2c-eg20t.base-bus-num=2 so it will register the bus numbers starting from 2. If this parameter is unset. It would use the first free one, thus simply using i2c_add_adapter.
> >
> > The reason we need a fixed number is it is easier for platform code
> > which needs to register dozens of i2c devices to different controllers
> > with i2c_register_board_info, and they need provide a bus number for
> > each i2c device, this _binding_ info is not detectable but have to
> > be fixed.
>
> Yes, I'm aware of that. With "Why use a fixed one?" I meant why hard-code it into the driver. I should be changeable.
> Because this is/was not possible in general to use i2c_register_board_info, so we used an echo to /sys/bus/i2c/devices/i2c-0/new_device or /sys/bus/i2c/devices/i2c-1/new_device.

Yeah, our EG20T kernel used to use the same "echo /sys/bus/i2c/devices/i2c-x/new_device"
way, but we found out it is not convenient for:
1. needs extra user space script, why not make it just work in kernel after
boot? We have several i2c devices like touchscreen/radio which we wants them
just work without depending user space action.
2. The i2c bus number is not fixed, which make the user space script even
harder, as that number depends whether we compile into kernel all the i2c
controllers (eg20t and isch) and whether these driver are compiled as
modules and their loading order.

Thus we come out with this fixed bus number registering.

As I said before, either your module parameter "base_bus_num" solution
or my fixed bus number offset are ok to me. Will you cook a patch?

Thanks,
Feng

--
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/