On Wed, Dec 02, 2020 at 07:54:40AM -0800, Doug Anderson wrote:

On Wed, Dec 2, 2020 at 7:20 AM Benjamin Tissoires
[off-list ref] wrote:

quoted

On Tue, Dec 1, 2020 at 10:12 PM Doug Anderson [off-list ref] wrote:

quoted

On Wed, Nov 11, 2020 at 4:41 PM Douglas Anderson [off-list ref] wrote:

quoted

 .../bindings/input/goodix,gt7375p.yaml        |  65 +++++
 arch/arm64/configs/defconfig                  |   3 +-
 drivers/hid/Makefile                          |   2 +-
 drivers/hid/i2c-hid/Kconfig                   |  47 +++-
 drivers/hid/i2c-hid/Makefile                  |   6 +-
 drivers/hid/i2c-hid/i2c-hid-acpi.c            | 159 +++++++++++
 drivers/hid/i2c-hid/i2c-hid-core.c            | 254 +++---------------
 drivers/hid/i2c-hid/i2c-hid-of-goodix.c       | 116 ++++++++
 drivers/hid/i2c-hid/i2c-hid-of.c              | 143 ++++++++++
 drivers/hid/i2c-hid/i2c-hid.h                 |  22 ++
 include/linux/platform_data/i2c-hid.h         |  41 ---
 11 files changed, 596 insertions(+), 262 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/goodix,gt7375p.yaml
 create mode 100644 drivers/hid/i2c-hid/i2c-hid-acpi.c
 create mode 100644 drivers/hid/i2c-hid/i2c-hid-of-goodix.c
 create mode 100644 drivers/hid/i2c-hid/i2c-hid-of.c
 delete mode 100644 include/linux/platform_data/i2c-hid.h

Are there any additional changes that folks would like with this
series?  It's not crazy urgent to get it in, but it touches enough
lines of code that it'd be nice to get it in before other patches land
and it gets merge conflicts.

Sorry for the delay. I was having an internal deadline last week. I
just re-read the code, and I am quite happy with it. I also just
tested it on the i2c-hid w/ acpi machine I have here, and it seems OK.

So other than that, do we need to have approvals for patch 2/4
(arch/arm64/configs/defconfig)? I can easily take that in the HID
tree, but I prefer having the approval from the maintainers first.
Catalin, Will?

From my past knowledge of the arm64 defconfig, I think it's a bit of a
free-for-all, sort of like updates to the "MAINTAINERS" file.  Doing a
"git log" on it I see commits happen from every corner and very few of
them have Acks.  I think many (but not all) of the commits to this
file go through trees that feed into the SoC tree (Arnd and Olof)
because those maintainers care about enabling drivers for boards that
they're supporting, but changes come from elsewhere too.

Obviously an Ack wouldn't hurt, though.  Since get_maintainer points
at Will and Catalin I wouldn't say no if one of them wanted to Ack
patch #2 in the series.  ;-)

For the avoidance of doubt:

Acked-by: Will Deacon <will@kernel.org>

on patch 2. But yes, although there are a few things I really care about
in defconfig (e.g. things like page size!), generally speaking we don't
need to Ack everything that changes in there.

That said, might be worth checking whether arm-soc have any defconfig
changes queued in -next so you don't end up with conflicts.

Will