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
next prev parent 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).