It is not good idea to mix static and dynamic I2C adapter numbering. In
this particular case on Lynxpoint we had graphics I2C adapter which took
the first numbers preventing the designware I2C driver from using the
adapter numbers it preferred.
Since Lynxpoint support was just introduced and there is no hardware available
outside Intel we can fix this by switching to use dynamic adapter numbering
instead of static.
Signed-off-by: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx>
---
Changes to v1:
- Updated commit message to mention that this change should not
cause regressions as there are no real users for Lynxpoint
I2C controller driver yet.
drivers/i2c/busses/i2c-designware-platdrv.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 94b3a4d..0735ccf 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -56,20 +56,11 @@ static u32 i2c_dw_get_clk_rate_khz(struct dw_i2c_dev *dev)
static int dw_i2c_acpi_configure(struct platform_device *pdev)
{
struct dw_i2c_dev *dev = platform_get_drvdata(pdev);
- struct acpi_device *adev;
- int busno, ret;
if (!ACPI_HANDLE(&pdev->dev))
return -ENODEV;
- ret = acpi_bus_get_device(ACPI_HANDLE(&pdev->dev), &adev);
- if (ret)
- return -ENODEV;
-
dev->adapter.nr = -1;
- if (adev->pnp.unique_id && !kstrtoint(adev->pnp.unique_id, 0, &busno))
- dev->adapter.nr = busno;
-
dev->tx_fifo_depth = 32;
dev->rx_fifo_depth = 32;
return 0;
--
1.7.10.4
--
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
