All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christopher Heiny <cheiny@synaptics.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Andrew Duggan <aduggan@synaptics.com>,
	Vincent Huang <vincent.huang@tw.synaptics.com>,
	Vivian Ly <vly@synaptics.com>,
	Daniel Rosenberg <daniel.rosenberg@synaptics.com>,
	Linus Walleij <linus.walleij@stericsson.com>,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	Courtney Cavin <courtney.cavin@sonymobile.com>,
	Linux Input <linux-input@vger.kernel.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 03/11] Input: synaptics-rmi4 - do not update configuration in rmi_f01_probe()
Date: Tue, 18 Feb 2014 13:32:53 -0800	[thread overview]
Message-ID: <5303D185.8020302@synaptics.com> (raw)
In-Reply-To: <20140217192321.GC19223@core.coreip.homeip.net>

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

  reply	other threads:[~2014-02-18 21:32 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-13  5:27 [PATCH 01/11] Input: synaptics-rmi4 - do not kfree() managed memory in F01 Dmitry Torokhov
2014-02-13  5:27 ` [PATCH 02/11] Input: synaptics-rmi4 - remove unused rmi_f01_remove() Dmitry Torokhov
2014-02-13 19:11   ` Christopher Heiny
2014-02-13  5:27 ` [PATCH 03/11] Input: synaptics-rmi4 - do not update configuration in rmi_f01_probe() Dmitry Torokhov
2014-02-13 19:23   ` Christopher Heiny
2014-02-13 21:54     ` Dmitry Torokhov
2014-02-14 23:00       ` Christopher Heiny
2014-02-17 19:23         ` Dmitry Torokhov
2014-02-18 21:32           ` Christopher Heiny [this message]
2014-03-19  0:21   ` Christopher Heiny
2014-02-13  5:27 ` [PATCH 04/11] Input: synaptics-rmi4 - fix LTS handling in F01 Dmitry Torokhov
2014-02-13 19:32   ` Christopher Heiny
2014-02-14  8:05     ` Dmitry Torokhov
2014-02-13  5:27 ` [PATCH 05/11] Input: synaptics-rmi4 - remove control_mutex from f01_data Dmitry Torokhov
2014-02-13 23:01   ` Christopher Heiny
2014-02-13  5:27 ` [PATCH 06/11] Input: synaptics-rmi4 - remove device_status form f01_data Dmitry Torokhov
2014-02-13 21:15   ` Christopher Heiny
2014-02-13  5:27 ` [PATCH 07/11] Input: synaptics-rmi4 - rename instances of f01_data from data to f01 Dmitry Torokhov
2014-02-13 21:32   ` Christopher Heiny
2014-02-13  5:27 ` [PATCH 08/11] Input: synaptics-rmi4 - use rmi_read/rmi_write in F01 Dmitry Torokhov
2014-02-13 21:33   ` Christopher Heiny
2014-02-13  5:27 ` [PATCH 09/11] Input: synaptics-rmi4 - consolidate memory allocations " Dmitry Torokhov
2014-02-13 19:52   ` Christopher Heiny
2014-02-13  5:27 ` [PATCH 10/11] Input: synaptics-rmi4 - make accessor for platform data return const pointer Dmitry Torokhov
2014-02-13 20:00   ` Christopher Heiny
2014-02-13  5:27 ` [PATCH 11/11] Input: synaptics-rmi4 - remove data pointer from RMI fucntion structure Dmitry Torokhov
2014-02-13 21:33   ` Christopher Heiny
2014-02-13 19:11 ` [PATCH 01/11] Input: synaptics-rmi4 - do not kfree() managed memory in F01 Christopher Heiny

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5303D185.8020302@synaptics.com \
    --to=cheiny@synaptics.com \
    --cc=aduggan@synaptics.com \
    --cc=benjamin.tissoires@redhat.com \
    --cc=courtney.cavin@sonymobile.com \
    --cc=daniel.rosenberg@synaptics.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linus.walleij@stericsson.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vincent.huang@tw.synaptics.com \
    --cc=vly@synaptics.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.