[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140110085939.3d96c7e6@endymion.delvare>
Date: Fri, 10 Jan 2014 08:59:39 +0100
From: Jean Delvare <khali@...ux-fr.org>
To: Benson Leung <bleung@...omium.org>
Cc: Wolfram Sang <wsa@...-dreams.de>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
andriy.shevchenko@...ux.intel.com, jacmet@...site.dk,
linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org,
Duncan Laurie <dlaurie@...omium.org>
Subject: Re: [PATCH 2/2] i2c-designware-pci: Index Haswell ULT bus names
from 0
On Thu, 9 Jan 2014 16:12:14 -0800, Benson Leung wrote:
> Our devices and our platforms have some other requirements which
> turned me away from using i2c_register_board_info.
>
> i2c_register_board_info looks to create predeclarations for a specific
> i2c bus... However, right now, the chromeos_laptop driver is
> structured to do explicit declaration (using i2c_new_probed_device)
> *after* the busses have come up.
>
> Specifically, we have a class of atmel_mxt i2c touchpad/touchscreen
> devices that may appear at different addresses depending on whether
> the touch device is in bootloader mode or operational mode.
>
> For that reason, the chromeos_laptop driver uses i2c_new_probed_device
> with a list of possible addresses when dealing with the atmel touch
> device.
>
> You can see the driver here :
> drivers/platform/chrome/chromeos_laptop.c
>
> Is there some way of getting the "probe" behavior while using
> i2c_register_board_info?
No, i2c_register_board_info works only for devices which are always
present at a known address.
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists