[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200527064307.GK89269@dtor-ws>
Date: Tue, 26 May 2020 23:43:07 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Jiada Wang <jiada_wang@...tor.com>
Cc: nick@...anahar.org, jikos@...nel.org,
benjamin.tissoires@...hat.com, bsz@...ihalf.com,
linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
erosca@...adit-jv.com, Andrew_Gabbasov@...tor.com
Subject: Re: [PATCH v11 00/56] atmel_mxt_ts misc
Hi Jiada,
On Thu, May 07, 2020 at 10:56:00PM -0700, Jiada Wang wrote:
> This patch-set forward ports Nick Dyer's work in ndyer/linux github
> repository as long as some other features and fixes
Sorry for ignoring the series for quite a while. I guess my biggest
issue with the series is that quite a bit of patches are trying to
handle the fallout from a very unfortunate design decision in the
driver: the fact that it attempts to automatically upload firmware and
config on every boot/probe. This design was done at my urging because I
did not have access to the technical documentation and did not realize
that the controller has non-volatile memory for both firmware and
configuration. We should only attempt to automatically load firmware
where device does not have non-volatile memory and is unable function
otherwise, in all other cases we better leave it to userspace to decide
whether to execute firmware update and when. The kernel should only
provide facilities so that userspace can initiate firmware update. This
design has worked well for Chrome OS for many years (it used Atmel
controllers in several products), and I would like to bring it to the
mainline.
Thanks.
--
Dmitry
Powered by blists - more mailing lists