i2c-mux-gpio platform device ID issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Peter,

I am anticipating an issue with driver i2c-mux-gpio. Right now there
are no user in the kernel tree (surprisingly...), but I'm about to add
the first one (for SMBus multiplexing on an x86 motherboard) and I
expect more will follow.

Right now I am allocating the multiplexer device with:

	platform_device_alloc("i2c-mux-gpio", -1);

This is OK as long as I am the only user. But if the same system needs
another instance of "i2c-mux-gpio", the second attempt will fail,
because both devices will have the same name and this isn't allowed by
the driver core. I could pass an instance ID at allocation time,
however it would have to be different for my driver and the other
driver, and there's no way to guarantee this for two random drivers.

Do you have any idea how we can solve this problem?

My only idea so far is to change the semantics of pdev->id == -1 from
"there's only one device" to "I don't care about the device ID".
Platform devices created with pdev->id == -1 would get an arbitrary ID
value, using an IDA-style mechanism. The IDA would be stored at the
platform driver level. It has the drawback of adding some burden to all
platform drivers, but I'm not sure how much yet, it might be just
acceptable.

If a per-driver IDA isn't acceptable, then we can go for a global IDA,
but then we can't re-use pdev->id == -1 for it. We'd have to introduce
pdev->id == -2 for drivers which want a dynamically allocated unique
ID. Actually this might be a better approach, as it's less intrusive.

Opinions?

-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux