Some generic review comments for this patch
1. Normally, defconfig should be a separate patch. You need not
post the entire defconfig, but only the changes to the Makefiles and
the Kconfig files.
2. All RMI specific files can be moved to a separate driver folder
in input/ like drivers/input/rmi/*.
We are also using the Synaptics RMI4 touch pad on our U8500 platform.
We had to make some changes to these posted drivers to make it work on
our platform. Also, we modified the touch screen driver to be compliant
to the kernel coding guidelines, but as a stand alone driver though.
I will soon post out an RFC for our patch which we got working on our board.
Please do have a look and we would like you guys to incorporate these changes
into your final patch sets as well, so that we can avoid any re-works later on
when your patch set gets merged into the mainline kernel.
Thanks very much for your input!
We'll be changing the patch structure with our next submission, as the
current patch file is getting kind of large and clumsy. We'll split the
defconfig out into its own patch at that point.
We'll also be eliminating the Hungarian notation in the next submission.
Your suggestion regarding the location of the RMI specific files is
interesting. We'll defer to Dmitry on where he'd like to see those
files placed, though.
Unfortunately, the patch you submitted appears to be based on the older
monolithic RMI3/Android driver, which is limited in functionality and
maintainability. Also, your submitted patch appears to be specific to
the U8500 platform.
The aim of the current work is to develop a platform independent modular
driver that will support all RMI4 functionality in a generic fashion.
We'll be more than happy to work with your team to develop support for
the U8500 under the modular structure. If we proceed in that direction,
it eliminates redundant effort and the need for any rework when our
driver gets merged into the mainline.
I think the first step there should be for your team to resubmit your
work as modifications of the current development effort, rather than
backporting the current effort onto the obsolete framework. Although
that involves upfront work for your team in the near term, it provides a
reduction in effort all around going forward:
- your team doesn't need to keep back-patching changes onto
the obsolete driver structure
- our team doesn't need to keep forward-patching U8500
related changes into the current driver structure
In a recent email conversation with me, Dmitry indicated that he will be
creating a development branch for this work in the near future. That
will greatly facilitate this effort.