On 02/17/2014 11:23 AM, Dmitry Torokhov wrote:
On Fri, Feb 14, 2014 at 03:00:43PM -0800, Christopher Heiny wrote:
On 02/13/2014 01:54 PM, Dmitry Torokhov wrote:
On Thu, Feb 13, 2014 at 11:23:44AM -0800, Christopher Heiny wrote:
On 02/12/2014 09:27 PM, Dmitry Torokhov wrote:
Do not write configuration data in probe(), we have config() for that.

Then we should call config() in rmi_function_probe() to ensure that
any platform data or device tree configuration settings get written
to the device.

Well, yes, we may elect to update device configuration in probe, but
then we should not be doing that 2nd time in ->config(). We shoudl pick
either one or another.

But as the code currently stands, config() is only called when a
device reset is detected, not during initialization.  So if there's
platform specific configuration data that needs to be written to a
function, it won't get written until after a device reset occurs,
which might never happen.  So either we need to write that data (or
call config()) in each function's probe(), or in
rmi_function_probe().

Ah, I missed the fact that we do not normally call ->config() unless
device was reset. BTW, if device was reset, shouldn't we tear down
everything and then reenumerate all functions?

That's only required if the reset is a result of the device being reflashed. Since we're dropping support for user-space control of reflash, and will instead use an in-driver reflash, we know which resets are the result of a reflash and which aren't. The reflash code will do the following sequence:

- tell the core to tear down the functions
- perform the reflash operation
- reset the device
- tell the core to re-enumerate the functions


                                        Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to