mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Duggan <aduggan@synaptics.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: <linux-input@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Jiri Kosina <jikos@kernel.org>,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	Vincent Huang <vincent.huang@tw.synaptics.com>,
	Nick Dyer <nick@shmanahar.org>, Chris Healy <cphealy@gmail.com>,
	<devicetree@vger.kernel.org>, Mark Rutland <mark.rutland@arm.com>,
	Rob Herring <robh@kernel.org>
Subject: Re: [PATCH v3 3/8] Input: synaptics-rmi4: Add dribble and palm gesture parameters to device tree
Date: Fri, 22 Jul 2016 11:32:02 -0700	[thread overview]
Message-ID: <682368c2-5692-5905-7538-36ce2e3d262f@synaptics.com> (raw)
In-Reply-To: <20160722165239.GA5036@dtor-ws>

On 07/22/2016 09:52 AM, Dmitry Torokhov wrote:
> On Wed, Jul 13, 2016 at 11:08:42PM -0700, Andrew Duggan wrote:
>> Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
>> ---
>> This version includes Nick's suggestion of adding force to the device tree
>> parameters so make it obvious that these parameters overwrite the
>> default values set in the firware config.
> Why do we want to support overwriting firmware behavior in DT instead of
> flashing new firmware as needed by the product?

If the firmware was configured incorrectly it might just be easier to 
add a device tree entry. This would allow platform owners to make the 
change without having to get Synaptics involved or have access to our 
tools. Customers have also requested using the same module and firmware 
across multiple platforms. Tracking which firmware is on which part 
would create an additional support burden and not all platforms have an 
automated way of checking and updating firmware versions in the event 
that a system is build with a module which has the incorrect firmware.

It is possible that neither of these cases will ever happen and the 
bindings will never be used. I figured it was better to have the options 
available if needed. But, if we want to avoid having tons of device tree 
parameters which are never used then we can leave this patch out and I 
can resubmit it if there is a platform which ends up needing them.

Andrew

> Thanks.
>

  reply	other threads:[~2016-07-22 18:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-14  6:08 Andrew Duggan
2016-07-16 22:49 ` Rob Herring
2016-07-22 15:08 ` Linus Walleij
2016-07-22 16:52 ` Dmitry Torokhov
2016-07-22 18:32   ` Andrew Duggan [this message]
2016-07-24 14:29     ` Linus Walleij

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=682368c2-5692-5905-7538-36ce2e3d262f@synaptics.com \
    --to=aduggan@synaptics.com \
    --cc=benjamin.tissoires@redhat.com \
    --cc=cphealy@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=jikos@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=nick@shmanahar.org \
    --cc=robh@kernel.org \
    --cc=vincent.huang@tw.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®