On Tue, 28 Jul 2015, Dmitry Torokhov wrote:

On Tue, Jul 28, 2015 at 09:40:19AM +0100, Lee Jones wrote:

quoted

On Mon, 27 Jul 2015, Dmitry Torokhov wrote:

quoted

On Mon, Jul 27, 2015 at 03:43:00PM -0700, Dmitry Torokhov wrote:

quoted

On Thu, Jul 23, 2015 at 05:17:41PM +0100, S Twiss wrote:

quoted

From: S Twiss <redacted>

Add device tree bindings for the DA9062 OnKey driver component

Signed-off-by: Steve Twiss <redacted>

---
Changes in V3:
 - Child driver specifics separated out into separate document
   in this case ../input/da9062-onkey.txt
Changes in V2:
 - No change

This patch applies against linux-next and next-20150708 


 .../devicetree/bindings/input/da9062-onkey.txt     | 36 ++++++++++++++++++++++
 Documentation/devicetree/bindings/mfd/da9062.txt   |  3 ++

I dropped bits for mfd/da9062.txt, changed to mention both 9062 and
9063, folded into the onkey patch and applied.

Argh, da9062 core is not in mainline yet... OK, below is the patch I
had; if Lee does not pick it up I'll re-apply it when da9062 core hits
mainline.

Hmm... that's annoying.  You've put the patch below your signature
'--', so my mailer cuts it off.

OK, sorry, I'll make sure to put in before the signature next time.

Appreciated.

quoted

[pasting]

quoted

Input: add DA9062 OnKey capability to DA9063 OnKey driver

From: S Twiss <redacted>

Add DA9062 OnKey support into the existing DA9063 OnKey driver component by
using generic access tables for common register and bit mask definitions.

The following change will add generic register and bit mask support to the
DA9063 OnKey.

The following alterations have been made to the DA9063 OnKey:

- Addition of a da906x_chip_config structure to hold all
  generic registers and bitmasks for this type of OnKey component.
- Addition of an struct of_device_id table for DA9063 and DA9062
  defaults
- Refactoring functions to use struct da9063_onkey accesses to generic
  registers/masks instead of using defines from registers.h
- Re-work of da9063_onkey_probe() to use of_match_node() and
  dev_get_regmap() to provide initialisation of generic registers and
  masks and access to regmap

Signed-off-by: Steve Twiss <redacted>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 .../devicetree/bindings/input/da9062-onkey.txt     |   32 +++++
 drivers/input/misc/Kconfig                         |    8 +
 drivers/input/misc/da9063_onkey.c                  |  129 ++++++++++++++++----
 3 files changed, 140 insertions(+), 29 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/da9062-onkey.txt

 
I'm confused.  What's the dependency?

There shouldn't be any issue applying input patches, just because
there isn't an MFD counterpart.  In fact, I would take prior
acceptance of the child into consideration (would be like a +1 vote)
when reviewing the MFD part.

It's this chunk:

+#include <linux/mfd/da9062/core.h>
+#include <linux/mfd/da9062/registers.h>

and these header files are not in mainline yet.

Ah, thanks for the clarification.

I will apply the other patches.

quoted

One suggestion however, I would ask for the DT binding and the driver
to be separated, as per [0].

[0] Documentation/devicetree/bindings/submitting-patches.txt

Right, but that says about submitting patches, not applying them ;)

When I chatted with Grant he said that the policy of separating binding
and code into separate patches is done so not to overwhelm devicetree
list and that is is perfectly fine to actually apply them as a single
commit. I try to combine them together so that when looking through
history they show up as one.

Got you. :)

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html