linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Christopher Heiny <cheiny@synaptics.com>
Cc: Linus Walleij <linus.walleij@stericsson.com>,
	Linux Input <linux-input@vger.kernel.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Allie Xiong <axiong@synaptics.com>, Vivian Ly <vly@synaptics.com>,
	Daniel Rosenberg <daniel.rosenberg@synaptics.com>,
	Alexandra Chin <alexandra.chin@tw.synaptics.com>,
	Joerie de Gram <j.de.gram@gmail.com>,
	Wolfram Sang <w.sang@pengutronix.de>,
	Mathieu Poirier <mathieu.poirier@linaro.org>
Subject: Re: [PATCH 2/4] Input: RMI4 - move sensor driver and F01 handler into the core
Date: Thu, 29 Nov 2012 09:21:20 -0800	[thread overview]
Message-ID: <20121129172120.GA3656@core.coreip.homeip.net> (raw)
In-Reply-To: <50B6EA88.2010506@synaptics.com>

Hi Chris,
On Wed, Nov 28, 2012 at 08:54:32PM -0800, Christopher Heiny wrote:
> On 11/27/2012 01:21 AM, Dmitry Torokhov wrote:
> >There is no point in having the sensor driver and F01 handler separate
> >from the RMI core since it is not useful without them and having them
> >all together simplifies initialization among other things.
> 
> Hi Dmitry,
> 
> I've been looking at this patch as well as your patch 3/4 changes,
> and I'm not sure it's for the better.
> 
> One thing that confuses me is that these appear to go against the
> advice we've been getting over the past months to rely more on
> standard kernel bus and driver implementations, instead of the
> "roll-your-own" implementation we had been using before.
> 
> More importantly, the patches inextricably link the sensor driver
> implementation and the F01 driver implementation to the bus
> implementation, and means that any given system can have only one
> way of managing F01.  As you observed, a sensor is pretty much
> useless without an F01 handler, but I am reasonably sure that there
> will be future systems that have more than one RMI4 sensor in them,
> and there is a strong possibility that these sensors may have
> different requirements for handling F01.  In the near future, then,
> these changes will have to be refactored back to something more like
> the structure of our 2012/11/16 patch set.
> 
> Additionally, having F01 as a special case means that when we start
> implementing things such as support for request_firmware(), there
> will have to be a bunch of special case code to deal with F01, since
> it's no longer "just another function driver".  That seems to go in
> exactly the opposite direction of the simplification that you're
> trying to achieve.

But F01 continues to being "just another function driver" even with my
changes. It is still registered as rmi_fucntion_handler and uses
standard matching mechanisms to bind to rmi_functions registered by the
sensor driver. What I changed is the fact that rmi_f01 is no longer a
separate module which could be loaded after loading rmi_bus and it can't
be unloaded without unloading rmi_bus. This simplifies things and makes
it easier to have rmi core compiled as a module.

Also I do not quite follow your idea that devices might have different
requirements for handling F01. If that is true then be _can't_ implement
"F01" as "another function driver"... But that is orthogonal for the 3/4
change we are discussing here.

Thanks.

-- 
Dmitry

  reply	other threads:[~2012-11-29 17:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-27  9:21 [PATCH 1/4] Input RMI4 - rename rmi_function_container to rmi_function Dmitry Torokhov
2012-11-27  9:21 ` [PATCH 2/4] Input: RMI4 - move sensor driver and F01 handler into the core Dmitry Torokhov
2012-11-29  4:54   ` Christopher Heiny
2012-11-29 17:21     ` Dmitry Torokhov [this message]
2012-12-02  2:36       ` Christopher Heiny
2012-11-27  9:21 ` [PATCH 3/4] Input: RMI4 - move function registration " Dmitry Torokhov
2012-11-27  9:21 ` [PATCH 4/4] Input: RMI4 - introduce rmi_module_driver() macro Dmitry Torokhov
2012-11-27 23:46   ` Christopher Heiny
2012-11-27 23:43 ` [PATCH 1/4] Input RMI4 - rename rmi_function_container to rmi_function Christopher Heiny
2012-11-28  7:09   ` Dmitry Torokhov

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=20121129172120.GA3656@core.coreip.homeip.net \
    --to=dmitry.torokhov@gmail.com \
    --cc=alexandra.chin@tw.synaptics.com \
    --cc=axiong@synaptics.com \
    --cc=cheiny@synaptics.com \
    --cc=daniel.rosenberg@synaptics.com \
    --cc=j.de.gram@gmail.com \
    --cc=linus.walleij@stericsson.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=vly@synaptics.com \
    --cc=w.sang@pengutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).