* Re: [PATCH 27/47] input: keyboard: remove bf54x driver
From: Dmitry Torokhov @ 2018-03-14 16:04 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-kernel, linux-input
In-Reply-To: <20180314153603.3127932-28-arnd@arndb.de>
On Wed, Mar 14, 2018 at 04:35:40PM +0100, Arnd Bergmann wrote:
> The blackfin architecture is getting removed, so this
> driver is now obsolete.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Please take it through your tree with the rest of bfin removal patches.
> ---
> drivers/input/keyboard/Kconfig | 9 -
> drivers/input/keyboard/Makefile | 1 -
> drivers/input/keyboard/bf54x-keys.c | 396 ------------------------------------
> 3 files changed, 406 deletions(-)
> delete mode 100644 drivers/input/keyboard/bf54x-keys.c
>
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index 4c4ab1ced235..2b469cc47a78 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -157,15 +157,6 @@ config KEYBOARD_QT2160
> This driver can also be built as a module. If so, the module
> will be called qt2160.
>
> -config KEYBOARD_BFIN
> - tristate "Blackfin BF54x keypad support"
> - depends on (BF54x && !BF544)
> - help
> - Say Y here if you want to use the BF54x keypad.
> -
> - To compile this driver as a module, choose M here: the
> - module will be called bf54x-keys.
> -
> config KEYBOARD_CLPS711X
> tristate "CLPS711X Keypad support"
> depends on OF_GPIO && (ARCH_CLPS711X || COMPILE_TEST)
> diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
> index 526e68294e6e..8fab920afa58 100644
> --- a/drivers/input/keyboard/Makefile
> +++ b/drivers/input/keyboard/Makefile
> @@ -13,7 +13,6 @@ obj-$(CONFIG_KEYBOARD_AMIGA) += amikbd.o
> obj-$(CONFIG_KEYBOARD_ATARI) += atakbd.o
> obj-$(CONFIG_KEYBOARD_ATKBD) += atkbd.o
> obj-$(CONFIG_KEYBOARD_BCM) += bcm-keypad.o
> -obj-$(CONFIG_KEYBOARD_BFIN) += bf54x-keys.o
> obj-$(CONFIG_KEYBOARD_CAP11XX) += cap11xx.o
> obj-$(CONFIG_KEYBOARD_CLPS711X) += clps711x-keypad.o
> obj-$(CONFIG_KEYBOARD_CROS_EC) += cros_ec_keyb.o
> diff --git a/drivers/input/keyboard/bf54x-keys.c b/drivers/input/keyboard/bf54x-keys.c
> deleted file mode 100644
> index 8a07a426f88e..000000000000
> --
> 2.9.0
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH 28/47] input: misc: remove blackfin rotary driver
From: Dmitry Torokhov @ 2018-03-14 16:04 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-kernel, linux-input
In-Reply-To: <20180314153603.3127932-29-arnd@arndb.de>
On Wed, Mar 14, 2018 at 04:35:41PM +0100, Arnd Bergmann wrote:
> The blackfin architecture is getting removed, so this
> one is obsolete as well.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Please take it through your tree with the rest of bfin removal patches.
> ---
> drivers/input/misc/Kconfig | 9 -
> drivers/input/misc/Makefile | 1 -
> drivers/input/misc/bfin_rotary.c | 294 ------------------------------
> include/linux/platform_data/bfin_rotary.h | 117 ------------
> 4 files changed, 421 deletions(-)
> delete mode 100644 drivers/input/misc/bfin_rotary.c
> delete mode 100644 include/linux/platform_data/bfin_rotary.h
>
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 6a3c753b093b..572b15fa18c2 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -655,15 +655,6 @@ config INPUT_DM355EVM
> To compile this driver as a module, choose M here: the
> module will be called dm355evm_keys.
>
> -config INPUT_BFIN_ROTARY
> - tristate "Blackfin Rotary support"
> - depends on BF54x || BF52x
> - help
> - Say Y here if you want to use the Blackfin Rotary.
> -
> - To compile this driver as a module, choose M here: the
> - module will be called bfin-rotary.
> -
> config INPUT_WM831X_ON
> tristate "WM831X ON pin"
> depends on MFD_WM831X
> diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
> index 8cc58f362bb8..72cde28649e2 100644
> --- a/drivers/input/misc/Makefile
> +++ b/drivers/input/misc/Makefile
> @@ -19,7 +19,6 @@ obj-$(CONFIG_INPUT_ARIZONA_HAPTICS) += arizona-haptics.o
> obj-$(CONFIG_INPUT_ATI_REMOTE2) += ati_remote2.o
> obj-$(CONFIG_INPUT_ATLAS_BTNS) += atlas_btns.o
> obj-$(CONFIG_INPUT_ATMEL_CAPTOUCH) += atmel_captouch.o
> -obj-$(CONFIG_INPUT_BFIN_ROTARY) += bfin_rotary.o
> obj-$(CONFIG_INPUT_BMA150) += bma150.o
> obj-$(CONFIG_INPUT_CM109) += cm109.o
> obj-$(CONFIG_INPUT_CMA3000) += cma3000_d0x.o
> diff --git a/drivers/input/misc/bfin_rotary.c b/drivers/input/misc/bfin_rotary.c
> deleted file mode 100644
> index 799ce3d2820e..000000000000
> diff --git a/include/linux/platform_data/bfin_rotary.h b/include/linux/platform_data/bfin_rotary.h
> deleted file mode 100644
> index 98829370fee2..000000000000
> --
> 2.9.0
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH v4] HID: google: add google hammer HID driver
From: Benjamin Tissoires @ 2018-03-14 16:16 UTC (permalink / raw)
To: Nicolas Boichat; +Cc: Jiri Kosina, lkml, open list:HID CORE LAYER, groeck, dtor
In-Reply-To: <20180314052219.224622-1-drinkcat@chromium.org>
Hi Nicolas,
On Wed, Mar 14, 2018 at 6:22 AM, Nicolas Boichat <drinkcat@chromium.org> wrote:
> From: Wei-Ning Huang <wnhuang@chromium.org>
>
> Add Google hammer HID driver. This driver allow us to control hammer
> keyboard backlight and support future features.
>
> We add a new HID quirk, that allows us to have the keyboard interface
> to bind to google-hammer driver, while the touchpad interface can
> bind to the multitouch driver.
>
> Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
> Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
> ---
>
> Changes since v3:
> - Rebase on latest linux-next/master, which moved the quirk list from
> hid-core.c to hid-quirks.c. Also, completely rework the logic to make
> it possible to bind google-hammer driver to keyboard interface, and
> generic multitouch driver to touchpad interface, as it is much simpler
> to do now that quirks are read early in hid_add_device.
Ouch, this logic seems too convoluted for me.
Just to be sure:
- some of your devices export 2 USB interfaces on the same device (so
same VID/PID)
- one of this interface should be handled by hid-multitouch
- the other should be handled by hid-google-hammer
- the purpose of the new quirk and HID class are to allow
hid-google-hammer to only bind on the non multitouch interface
Am I correct?
If I am, given that we now don't need to blacklist the drivers for
hid-generic since e04a0442d33b8cf183bba38646447b891bb02123, I do not
understand why simply declaring "{ HID_DEVICE(BUS_USB,
HID_GROUP_GENERIC, USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_HAMMER)
}," (same for the 2 others) is not enough to have hid-google-hammer
binding only on the non-multitouch interface.
Could you please give a shot at it?
> - Add dynamic backlight detection support (only such devices have an
> output HID descriptor).
> - Add support for wand (one more USB product ID).
> - Add SPDX-License-Identifier, fix one minor formatting issue.
>
> drivers/hid/Kconfig | 6 ++
> drivers/hid/Makefile | 1 +
> drivers/hid/hid-core.c | 4 ++
> drivers/hid/hid-google-hammer.c | 116 ++++++++++++++++++++++++++++++++
> drivers/hid/hid-ids.h | 3 +
> drivers/hid/hid-quirks.c | 5 ++
> include/linux/hid.h | 2 +
> 7 files changed, 137 insertions(+)
> create mode 100644 drivers/hid/hid-google-hammer.c
>
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index 1fce4c94e5ac..60252fd796f6 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -339,6 +339,12 @@ config HOLTEK_FF
> Say Y here if you have a Holtek On Line Grip based game controller
> and want to have force feedback support for it.
>
> +config HID_GOOGLE_HAMMER
> + tristate "Google Hammer Keyboard"
> + depends on USB_HID && LEDS_CLASS
> + ---help---
> + Say Y here if you have a Google Hammer device.
> +
> config HID_GT683R
> tristate "MSI GT68xR LED support"
> depends on LEDS_CLASS && USB_HID
> diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
> index 713601c7bfa6..17a8bd97da9d 100644
> --- a/drivers/hid/Makefile
> +++ b/drivers/hid/Makefile
> @@ -45,6 +45,7 @@ obj-$(CONFIG_HID_ELO) += hid-elo.o
> obj-$(CONFIG_HID_EZKEY) += hid-ezkey.o
> obj-$(CONFIG_HID_GEMBIRD) += hid-gembird.o
> obj-$(CONFIG_HID_GFRM) += hid-gfrm.o
> +obj-$(CONFIG_HID_GOOGLE_HAMMER) += hid-google-hammer.o
> obj-$(CONFIG_HID_GT683R) += hid-gt683r.o
> obj-$(CONFIG_HID_GYRATION) += hid-gyration.o
> obj-$(CONFIG_HID_HOLTEK) += hid-holtek-kbd.o
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 36af26c2565b..61c7d135d680 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -2116,6 +2116,10 @@ int hid_add_device(struct hid_device *hdev)
> ret = hid_scan_report(hdev);
> if (ret)
> hid_warn(hdev, "bad device descriptor (%d)\n", ret);
> +
> + if (hdev->quirks & HID_QUIRK_NO_GENERIC &&
> + hdev->group == HID_GROUP_GENERIC)
> + hdev->group = HID_GROUP_GENERIC_OVERRIDE;
> }
>
> /* XXX hack, any other cleaner solution after the driver core
> diff --git a/drivers/hid/hid-google-hammer.c b/drivers/hid/hid-google-hammer.c
> new file mode 100644
> index 000000000000..e7ad042a8464
> --- /dev/null
> +++ b/drivers/hid/hid-google-hammer.c
> @@ -0,0 +1,116 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * HID driver for Google Hammer device.
> + *
> + * Copyright (c) 2017 Google Inc.
> + * Author: Wei-Ning Huang <wnhuang@google.com>
> + */
> +
> +/*
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the Free
> + * Software Foundation; either version 2 of the License, or (at your option)
> + * any later version.
> + */
> +
> +#include <linux/hid.h>
> +#include <linux/leds.h>
> +#include <linux/module.h>
> +#include <linux/usb.h>
Generally that's a no from me to include usb.h. I'd rather have you
decide on which interface to create the LEDs based on the report
descriptors, so we can replay the device with uhid without crashing
the kernel.
> +
> +#include "hid-ids.h"
> +
> +#define MAX_BRIGHTNESS 100
> +
> +struct hammer_kbd_leds {
> + struct led_classdev cdev;
> + struct hid_device *hdev;
> + u8 buf[2] ____cacheline_aligned;
> +};
> +
> +static int hammer_kbd_brightness_set_blocking(struct led_classdev *cdev,
> + enum led_brightness br)
> +{
> + struct hammer_kbd_leds *led = container_of(cdev,
> + struct hammer_kbd_leds,
> + cdev);
> + int ret;
> +
> + led->buf[0] = 0;
> + led->buf[1] = br;
> +
> + ret = hid_hw_output_report(led->hdev, led->buf, sizeof(led->buf));
> + if (ret == -ENOSYS)
> + ret = hid_hw_raw_request(led->hdev, 0, led->buf,
> + sizeof(led->buf),
> + HID_OUTPUT_REPORT,
> + HID_REQ_SET_REPORT);
> + if (ret < 0)
> + hid_err(led->hdev, "failed to set keyboard backlight: %d\n",
> + ret);
> + return ret;
> +}
> +
> +static int hammer_register_leds(struct hid_device *hdev)
> +{
> + struct hammer_kbd_leds *kbd_backlight;
> +
> + kbd_backlight = devm_kzalloc(&hdev->dev,
> + sizeof(*kbd_backlight),
> + GFP_KERNEL);
> + if (!kbd_backlight)
> + return -ENOMEM;
> +
> + kbd_backlight->hdev = hdev;
> + kbd_backlight->cdev.name = "hammer::kbd_backlight";
> + kbd_backlight->cdev.max_brightness = MAX_BRIGHTNESS;
> + kbd_backlight->cdev.brightness_set_blocking =
> + hammer_kbd_brightness_set_blocking;
> + kbd_backlight->cdev.flags = LED_HW_PLUGGABLE;
> +
> + /* Set backlight to 0% initially. */
> + hammer_kbd_brightness_set_blocking(&kbd_backlight->cdev, 0);
> +
> + return devm_led_classdev_register(&hdev->dev, &kbd_backlight->cdev);
> +}
> +
> +static int hammer_input_configured(struct hid_device *hdev,
> + struct hid_input *hi)
> +{
> + struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
> +
> + struct list_head *report_list =
> + &hdev->report_enum[HID_OUTPUT_REPORT].report_list;
> +
> + if (intf->cur_altsetting->desc.bInterfaceProtocol ==
> + USB_INTERFACE_PROTOCOL_KEYBOARD && !list_empty(report_list)) {
See above. I am pretty sure you can find something in the report
descriptor to discriminate the LED capable device from the others.
Cheers,
Benjamin
> + int err = hammer_register_leds(hdev);
> +
> + if (err)
> + hid_warn(hdev,
> + "Failed to register keyboard backlight: %d\n",
> + err);
> + }
> +
> + return 0;
> +}
> +
> +static const struct hid_device_id hammer_devices[] = {
> + { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC_OVERRIDE,
> + USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_HAMMER) },
> + { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC_OVERRIDE,
> + USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_STAFF) },
> + { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC_OVERRIDE,
> + USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_WAND) },
> + { }
> +};
> +MODULE_DEVICE_TABLE(hid, hammer_devices);
> +
> +static struct hid_driver hammer_driver = {
> + .name = "hammer",
> + .id_table = hammer_devices,
> + .input_configured = hammer_input_configured,
> +};
> +module_hid_driver(hammer_driver);
> +
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 41f227a841fb..5a3a7ead3012 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -448,7 +448,10 @@
> #define USB_DEVICE_ID_GOODTOUCH_000f 0x000f
>
> #define USB_VENDOR_ID_GOOGLE 0x18d1
> +#define USB_DEVICE_ID_GOOGLE_HAMMER 0x5022
> #define USB_DEVICE_ID_GOOGLE_TOUCH_ROSE 0x5028
> +#define USB_DEVICE_ID_GOOGLE_STAFF 0x502b
> +#define USB_DEVICE_ID_GOOGLE_WAND 0x502d
>
> #define USB_VENDOR_ID_GOTOP 0x08f2
> #define USB_DEVICE_ID_SUPER_Q2 0x007f
> diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
> index 587e2681a53f..d112a14da200 100644
> --- a/drivers/hid/hid-quirks.c
> +++ b/drivers/hid/hid-quirks.c
> @@ -84,6 +84,11 @@ static const struct hid_device_id hid_quirks[] = {
> { HID_USB_DEVICE(USB_VENDOR_ID_FREESCALE, USB_DEVICE_ID_FREESCALE_MX28), HID_QUIRK_NOGET },
> { HID_USB_DEVICE(USB_VENDOR_ID_FUTABA, USB_DEVICE_ID_LED_DISPLAY), HID_QUIRK_NO_INIT_REPORTS },
> { HID_USB_DEVICE(USB_VENDOR_ID_GREENASIA, USB_DEVICE_ID_GREENASIA_DUAL_USB_JOYPAD), HID_QUIRK_MULTI_INPUT },
> +#if IS_ENABLED(CONFIG_HID_GOOGLE_HAMMER)
> + { HID_USB_DEVICE(USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_HAMMER), HID_QUIRK_NO_GENERIC },
> + { HID_USB_DEVICE(USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_STAFF), HID_QUIRK_NO_GENERIC },
> + { HID_USB_DEVICE(USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_WAND), HID_QUIRK_NO_GENERIC },
> +#endif
> { HID_USB_DEVICE(USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_DRIVING), HID_QUIRK_BADPAD | HID_QUIRK_MULTI_INPUT },
> { HID_USB_DEVICE(USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_FIGHTING), HID_QUIRK_BADPAD | HID_QUIRK_MULTI_INPUT },
> { HID_USB_DEVICE(USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_FLYING), HID_QUIRK_BADPAD | HID_QUIRK_MULTI_INPUT },
> diff --git a/include/linux/hid.h b/include/linux/hid.h
> index dfea5a656a1a..f2655265f8b5 100644
> --- a/include/linux/hid.h
> +++ b/include/linux/hid.h
> @@ -340,6 +340,7 @@ struct hid_item {
> #define HID_QUIRK_NO_EMPTY_INPUT 0x00000100
> /* 0x00000200 reserved for backward compatibility, was NO_INIT_INPUT_REPORTS */
> #define HID_QUIRK_ALWAYS_POLL 0x00000400
> +#define HID_QUIRK_NO_GENERIC 0x00000800
> #define HID_QUIRK_SKIP_OUTPUT_REPORTS 0x00010000
> #define HID_QUIRK_SKIP_OUTPUT_REPORT_ID 0x00020000
> #define HID_QUIRK_NO_OUTPUT_REPORTS_ON_INTR_EP 0x00040000
> @@ -359,6 +360,7 @@ struct hid_item {
> #define HID_GROUP_MULTITOUCH 0x0002
> #define HID_GROUP_SENSOR_HUB 0x0003
> #define HID_GROUP_MULTITOUCH_WIN_8 0x0004
> +#define HID_GROUP_GENERIC_OVERRIDE 0x0005
>
> /*
> * Vendor specific HID device groups
> --
> 2.16.2.804.g6dcf76e118-goog
>
^ permalink raw reply
* Re: [RESEND PATCH] Input: joystick/analog - Use get_cycles() on PPC
From: Dmitry Torokhov @ 2018-03-14 16:39 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linux-input, linux-kernel, linuxppc-dev
In-Reply-To: <20180314111752.1748-1-mpe@ellerman.id.au>
On Wed, Mar 14, 2018 at 10:17:52PM +1100, Michael Ellerman wrote:
> The analog joystick driver spits a warning at us:
>
> drivers/input/joystick/analog.c:176:2: warning: #warning Precise timer
> not defined for this architecture.
>
> PPC has get_cycles() so use that.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied, thank you.
> ---
> drivers/input/joystick/analog.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
> This is the third resend, I'll take it via the powerpc tree if no one else
> does.
>
> cheers
>
> diff --git a/drivers/input/joystick/analog.c b/drivers/input/joystick/analog.c
> index c868a878c84f..a942c4ccd2af 100644
> --- a/drivers/input/joystick/analog.c
> +++ b/drivers/input/joystick/analog.c
> @@ -163,7 +163,7 @@ static unsigned int get_time_pit(void)
> #define GET_TIME(x) do { x = (unsigned int)rdtsc(); } while (0)
> #define DELTA(x,y) ((y)-(x))
> #define TIME_NAME "TSC"
> -#elif defined(__alpha__) || defined(CONFIG_MN10300) || defined(CONFIG_ARM) || defined(CONFIG_ARM64) || defined(CONFIG_RISCV) || defined(CONFIG_TILE)
> +#elif defined(__alpha__) || defined(CONFIG_MN10300) || defined(CONFIG_ARM) || defined(CONFIG_ARM64) || defined(CONFIG_PPC) || defined(CONFIG_RISCV) || defined(CONFIG_TILE)
> #define GET_TIME(x) do { x = get_cycles(); } while (0)
> #define DELTA(x,y) ((y)-(x))
> #define TIME_NAME "get_cycles"
> --
> 2.14.1
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH v5 0/4] new driver for Valve Steam Controller
From: Benjamin Tissoires @ 2018-03-14 16:39 UTC (permalink / raw)
To: Rodrigo Rivas Costa
Cc: Clément VUCHENER, Jiri Kosina, Pierre-Loup A. Griffais,
Cameron Gutman, lkml, linux-input
In-Reply-To: <20180312205158.GB21621@casa>
On Mon, Mar 12, 2018 at 9:51 PM, Rodrigo Rivas Costa
<rodrigorivascosta@gmail.com> wrote:
> On Mon, Mar 12, 2018 at 03:30:43PM +0100, Clément VUCHENER wrote:
>> 2018-03-11 20:58 GMT+01:00 Rodrigo Rivas Costa <rodrigorivascosta@gmail.com>:
>> > This patchset implements a driver for Valve Steam Controller, based on a
>> > reverse analysis by myself.
>> >
>> > Sorry, I've been out of town for a few weeks and couldn't keep up with this...
>> >
>> > @Pierre-Loup and @Clément, could you please have another look at this and
>> > check if it is worthy? Benjamin will not commit it without an express ACK from
>> > Valve. Of course he is right to be cautious, but I checked this driver with
>> > the Steam Client and all seems to go just fine. I think that there is a lot of
>> > Linux out of the desktop that could use this driver and cannot use the Steam
>> > Client. Worst case scenario, this driver can now be blacklisted, but I hope
>> > that will not be needed.
>>
>> I tested the driver with my 4.15 fedora kernel (I only built the
>> module not the whole kernel) and I got double inputs (your driver
>> input device + steam uinput device) when testing Shovel Knight with
>> Steam Big Picture. It seems to work fine when the inputs are the same,
>> but after changing the controller configuration in Steam, the issue
>> became apparent.
>
> I assumed that when several joysticks are available, games would listen
> to one one of them. It looks like I'm wrong, and some (many?) games will
> listen to all available joysticks at the same time. Thus having two
> logical joysticks that represent the same physical one is not good.
Yeah, the general rule of thumb is "think of the worst thing that can
happen, someone will do something worst".
>
> An easy solution would be that Steam Client grabs this driver
> (ioctl(EVIOCGRAB)) when creating the uinput device. Another solution
> would be that Steam Client blacklists this driver, of course.
This is 2 solutions that rely on a userspace change, and this is not
acceptable in its current form. What if people do not upgrade Steam
client but upgrade their kernel? Well, Steam might be able to force
people to always run the latest shiny available version, but for other
games, you can't expect people to have a compatible version of the
userspace stack.
Also, "blacklisting the driver" from Steam client is something the OS
can do, but not the client when you run on a different distribution.
You need root for that, and I don't want to give root permissions to
Steam (or to any user space client that shouldn't have root privileges
for what it matters).
>
>> And without Steam and your external tool, you get double inputs too. I
>> tried RetroArch and it was unusable because of the keyboard inputs
>> from the lizard mode (e.g. pressing B also presses Esc and quits
>> RetroArch). Having to download and compile an external tool to make
>> the driver work properly may be too difficult for the user. Your goal
>> was to provide an alternative to user space drivers but now you
>> actually depend on (a very simple) one.
>
> Yes, I noticed that. TBH, this driver without Steam Client or the
> user-space tool is not very nice, precisely because you'll get constant
> Escape and Enter presses, and most games react to those.
>
> Frankly speaking, I'm not sure how to proceed. I can think of the
> following options:
> 1.Steam Client installation could add a file to blacklist
> hid-steam, just as it adds a few udev rules.
But what about RetroArch? And what if you install Steam but want to
play SDL games that could benefit from your driver?
> 2.The default CONFIG_HID_STEAM can be changed to "n". Maybe only
> on the architectures for which there is a Steam Client available.
> This way DIY projects will still be able to use it.
But this will make the decision to include or not the driver in
distributions harder. And if no distribution uses it, you won't have
free tests, and you will be alone to maintain it. So that's not ideal
either
> 3.This driver could be abandoned :-(. Just use Steam Client if possible or
> any of the user-mode drivers available.
This would be a waste for everybody as it's always better when we share.
>
> If we decide for 1 or 2, then the lizard mode could be disabled without
> ill effects. We could even enable the gyro and all the other gadgets
> without worring about current compatibility.
To me, 1 is out of the question. The kernel can't expect a user space
change especially if you are knowingly introducing a bug for the end
user.
2 is still on the table IMO, and 3 would be a shame.
I know we already discussed about sysfs and module parameters, but if
the driver will conflict with a userspace stack, the only way would be
to have a (dynamic) parameter "enhanced_mode" or
"kernel_awesome_support" or whatever which would be a boolean, that
defaults to false that Steam can eventually lookup if they want so in
the future we can default it to true. When this parameter is set, the
driver will create the inputs and toggle the various modes, while when
it's toggled off, it'll clean up itself and keep the device as if it
were connected to hid-generic. Bonus point, this removes the need for
the simple user space tool that enables the mode.
>
> At the end of the day, I think that it is up to Valve what to do.
Again, Valve is a big player here, but do not underestimate other
projects (like RetroArch mentioned above) because if you break their
workflow, they will have the right to request a revert of the commit
because it breaks some random user playing games in the far end of
Antarctica (yes, penguins do love to play games :-P )
Cheers,
Benjamin
> Best Regards.
> Rodrigo.
>
>> Also the button and axis codes do not match the gamepad API doc
>> (https://www.kernel.org/doc/Documentation/input/gamepad.txt).
>>
>> >
>> > For full reference, I'm adding a full changelog of this patchset.
>> >
>> > Changes in v5:
>> > * Fix license SPDX to GPL-2.0+.
>> > * Minor stylistic changes (BIT(3) instead 0x08 and so on).
>> >
>> > Changes in v4:
>> > * Add command to check the wireless connection status on probe, without
>> > waiting for a message (thanks to Clément Vuchener for the tip).
>> > * Removed the error code on redundant connection/disconnection messages. That
>> > was harmless but polluted dmesg.
>> > * Added buttons for touching the left-pad and right-pad.
>> > * Fixed a misplaced #include from 2/4 to 1/4.
>> >
>> > Changes in v3:
>> > * Use RCU to do the dynamic connec/disconnect of wireless devices.
>> > * Remove entries in hid-quirks.c as they are no longer needed. This allows
>> > this module to be blacklisted without side effects.
>> > * Do not bypass the virtual keyboard/mouse HID devices to avoid breaking
>> > existing use cases (lizard mode). A user-space tool to do that is
>> > linked.
>> > * Fully separated axes for joystick and left-pad. As it happens.
>> > * Add fuzz values for left/right pad axes, they are a little wiggly.
>> >
>> > Changes in v2:
>> > * Remove references to USB. Now the interesting interfaces are selected by
>> > looking for the ones with feature reports.
>> > * Feature reports buffers are allocated with hid_alloc_report_buf().
>> > * Feature report length is checked, to avoid overflows in case of
>> > corrupt/malicius USB devices.
>> > * Resolution added to the ABS axes.
>> > * A lot of minor cleanups.
>> >
>> > Rodrigo Rivas Costa (4):
>> > HID: add driver for Valve Steam Controller
>> > HID: steam: add serial number information.
>> > HID: steam: command to check wireless connection
>> > HID: steam: add battery device.
>> >
>> > drivers/hid/Kconfig | 8 +
>> > drivers/hid/Makefile | 1 +
>> > drivers/hid/hid-ids.h | 4 +
>> > drivers/hid/hid-steam.c | 794 ++++++++++++++++++++++++++++++++++++++++++++++++
>> > 4 files changed, 807 insertions(+)
>> > create mode 100644 drivers/hid/hid-steam.c
>> >
>> > --
>> > 2.16.2
>> >
^ permalink raw reply
* Re: [PATCH V2] Input: pm8941-pwrkey: add resin key capabilities
From: Dmitry Torokhov @ 2018-03-14 16:43 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Tirupathi Reddy, robh+dt, mark.rutland, linux-input,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20180314024048.GA11034@tuxbook-pro>
On Tue, Mar 13, 2018 at 07:40:48PM -0700, Bjorn Andersson wrote:
> On Tue 13 Mar 01:35 PDT 2018, Tirupathi Reddy wrote:
>
> > Add resin key support to handle different types of key events
> > defined in different platforms.
> >
> > Signed-off-by: Tirupathi Reddy <tirupath@codeaurora.org>
> > ---
> > .../bindings/input/qcom,pm8941-pwrkey.txt | 20 ++++++-
> > drivers/input/misc/pm8941-pwrkey.c | 65 +++++++++++++++++++++-
> > 2 files changed, 83 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
> > index 07bf55f..f499cf8 100644
> > --- a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
> > +++ b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
> > @@ -20,6 +20,14 @@ PROPERTIES
> > defined by the binding document describing the node's
> > interrupt parent.
> >
> > +- interrupt-names:
> > + Usage: required
> > + Value type: <stringlist>
> > + Definition: Interrupt names. This list must match up 1-to-1 with the
> > + interrupts specified in the 'interrupts' property. "kpdpwr"
> > + must be specified and should be the first entry of the list.
> > + "resin" may be specified for some platforms.
> > +
> > - debounce:
> > Usage: optional
> > Value type: <u32>
> > @@ -32,12 +40,22 @@ PROPERTIES
> > Definition: presence of this property indicates that the KPDPWR_N pin
> > should be configured for pull up.
> >
> > +- linux,code:
> > + Usage: required for "resin" key
> > + Value type: <u32>
> > + Definition: The input key-code associated with the resin key.
> > + Use the linux event codes defined in
> > + include/dt-bindings/input/linux-event-codes.h
>
> For completeness sake I think this should list both the key code for the
> power key and for the RESIN key.
>
> > +
> > EXAMPLE
> >
> > pwrkey@800 {
> > compatible = "qcom,pm8941-pwrkey";
> > reg = <0x800>;
> > - interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>;
> > + interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>,
> > + <0x0 0x8 1 IRQ_TYPE_EDGE_BOTH>;
> > + interrupt-names = "kpdpwr", "resin";
> > debounce = <15625>;
> > bias-pull-up;
>
> Do we need to support defining the bias for the resin as well?
>
> Perhaps it makes more sense to describe the RESIN key with a separate
> compatible and define that in a node of its own (we can still implement
> this in the same driver - if there's any chance of reuse...).
>
> > + linux,code = <KEY_VOLUMEDOWN>;
> > };
> > diff --git a/drivers/input/misc/pm8941-pwrkey.c b/drivers/input/misc/pm8941-pwrkey.c
> > index 18ad956..2fffc7c 100644
> > --- a/drivers/input/misc/pm8941-pwrkey.c
> > +++ b/drivers/input/misc/pm8941-pwrkey.c
> > @@ -28,6 +28,7 @@
> >
> > #define PON_RT_STS 0x10
> > #define PON_KPDPWR_N_SET BIT(0)
> > +#define PON_RESIN_N_SET BIT(1)
> >
> > #define PON_PS_HOLD_RST_CTL 0x5a
> > #define PON_PS_HOLD_RST_CTL2 0x5b
> > @@ -46,6 +47,7 @@
> > struct pm8941_pwrkey {
> > struct device *dev;
> > int irq;
> > + u32 resin_key_code;
> > u32 baseaddr;
> > struct regmap *regmap;
> > struct input_dev *input;
> > @@ -130,6 +132,24 @@ static irqreturn_t pm8941_pwrkey_irq(int irq, void *_data)
> > return IRQ_HANDLED;
> > }
> >
> > +static irqreturn_t pm8941_resinkey_irq(int irq, void *_data)
> > +{
> > + struct pm8941_pwrkey *pwrkey = _data;
> > + unsigned int sts;
> > + int error;
> > +
> > + error = regmap_read(pwrkey->regmap,
> > + pwrkey->baseaddr + PON_RT_STS, &sts);
>
> This needs to be broken because the line is 81 chars long, if you use a
> shorter name for the return value (e.g. "ret") you don't need to do
> this.
I prefer keeping it as "error" please.
>
> > + if (error)
> > + return IRQ_HANDLED;
> > +
> > + input_report_key(pwrkey->input, pwrkey->resin_key_code,
> > + !!(sts & PON_RESIN_N_SET));
>
> Put pwrkey->resin_key_code in a local variable named "key" (or even
> key_code) and you don't need to line wrap this one.
>
> > + input_sync(pwrkey->input);
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
>
> Regards,
> Bjorn
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: appletouch - use true and false for boolean values
From: Dmitry Torokhov @ 2018-03-14 17:09 UTC (permalink / raw)
To: Gustavo A. R. Silva; +Cc: linux-input, linux-kernel, Gustavo A. R. Silva
In-Reply-To: <20180306000043.GA1603@embeddedgus>
On Mon, Mar 05, 2018 at 06:00:43PM -0600, Gustavo A. R. Silva wrote:
> Assign true or false to boolean variables instead of an integer value.
>
> This issue was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied, thank you.
> ---
> drivers/input/mouse/appletouch.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/input/mouse/appletouch.c b/drivers/input/mouse/appletouch.c
> index 81a695d..032d279 100644
> --- a/drivers/input/mouse/appletouch.c
> +++ b/drivers/input/mouse/appletouch.c
> @@ -587,7 +587,7 @@ static void atp_complete_geyser_1_2(struct urb *urb)
> /* Perform size detection, if not done already */
> if (unlikely(!dev->size_detect_done)) {
> atp_detect_size(dev);
> - dev->size_detect_done = 1;
> + dev->size_detect_done = true;
> goto exit;
> }
> }
> @@ -813,7 +813,7 @@ static int atp_open(struct input_dev *input)
> if (usb_submit_urb(dev->urb, GFP_ATOMIC))
> return -EIO;
>
> - dev->open = 1;
> + dev->open = true;
> return 0;
> }
>
> @@ -823,7 +823,7 @@ static void atp_close(struct input_dev *input)
>
> usb_kill_urb(dev->urb);
> cancel_work_sync(&dev->work);
> - dev->open = 0;
> + dev->open = false;
> }
>
> static int atp_handle_geyser(struct atp *dev)
> --
> 2.7.4
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 4/4] input: misc: Add Gateworks System Controller support
From: Tim Harvey @ 2018-03-14 17:13 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Lee Jones, Rob Herring, Mark Rutland, Mark Brown, linux-kernel,
devicetree, linux-arm-kernel, linux-hwmon, linux-input
In-Reply-To: <20180310184502.GE260013@dtor-ws>
On Sat, Mar 10, 2018 at 10:45 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Mon, Mar 05, 2018 at 02:02:41PM -0800, Tim Harvey wrote:
>> Add support for dispatching Linux Input events for the various interrupts
>> the Gateworks System Controller provides.
>>
>> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>> Signed-off-by: Tim Harvey <tharvey@gateworks.com>
>> ---
>> v2:
>> - reword Kconfig
>> - revise license comment block
>> - remove unnecessary read of status register
>> - remove unnecessary setting of input->dev.parent
>> - use dt bindings for irq to keycode mapping
>> - add support for platform-data
>> - remove work-queue
>>
>> drivers/input/misc/Kconfig | 9 ++
>> drivers/input/misc/Makefile | 1 +
>> drivers/input/misc/gsc-input.c | 180 ++++++++++++++++++++++++++++++++
>> include/linux/platform_data/gsc_input.h | 30 ++++++
>> 4 files changed, 220 insertions(+)
>> create mode 100644 drivers/input/misc/gsc-input.c
>> create mode 100644 include/linux/platform_data/gsc_input.h
>>
>> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
>> index 9f082a3..e05f4fe 100644
>> --- a/drivers/input/misc/Kconfig
>> +++ b/drivers/input/misc/Kconfig
>> @@ -117,6 +117,15 @@ config INPUT_E3X0_BUTTON
>> To compile this driver as a module, choose M here: the
>> module will be called e3x0_button.
>>
>> +config INPUT_GSC
>> + tristate "Gateworks System Controller input support"
>> + depends on MFD_GSC
>> + help
>> + Support GSC events as Linux input events.
>> +
>> + To compile this driver as a module, choose M here: the
>> + module will be called gsc_input.
>> +
>> config INPUT_PCSPKR
>> tristate "PC Speaker support"
>> depends on PCSPKR_PLATFORM
>> diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
>> index 4b6118d..969debe 100644
>> --- a/drivers/input/misc/Makefile
>> +++ b/drivers/input/misc/Makefile
>> @@ -38,6 +38,7 @@ obj-$(CONFIG_INPUT_GP2A) += gp2ap002a00f.o
>> obj-$(CONFIG_INPUT_GPIO_BEEPER) += gpio-beeper.o
>> obj-$(CONFIG_INPUT_GPIO_TILT_POLLED) += gpio_tilt_polled.o
>> obj-$(CONFIG_INPUT_GPIO_DECODER) += gpio_decoder.o
>> +obj-$(CONFIG_INPUT_GSC) += gsc-input.o
>> obj-$(CONFIG_INPUT_HISI_POWERKEY) += hisi_powerkey.o
>> obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o
>> obj-$(CONFIG_INPUT_IMS_PCU) += ims-pcu.o
>> diff --git a/drivers/input/misc/gsc-input.c b/drivers/input/misc/gsc-input.c
>> new file mode 100644
>> index 0000000..27b5e93
>> --- /dev/null
>> +++ b/drivers/input/misc/gsc-input.c
>> @@ -0,0 +1,180 @@
>> +/* SPDX-License-Identifier: GPL-2.0
>> + *
>> + * Copyright (C) 2018 Gateworks Corporation
>> + *
>> + * This driver dispatches Linux input events for GSC interrupt events
>> + */
>> +#include <linux/input.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/of_irq.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/regmap.h>
>> +
>> +#include <linux/mfd/gsc.h>
>> +#include <linux/platform_data/gsc_input.h>
>> +
>> +struct gsc_input_button_priv {
>> + struct input_dev *input;
>> + const struct gsc_input_button *button;
>> +};
>> +
>> +struct gsc_input_data {
>> + struct gsc_dev *gsc;
>> + struct gsc_input_platform_data *pdata;
>> + struct input_dev *input;
>> + struct gsc_input_button_priv *buttons;
>> + int nbuttons;
>> + unsigned int irqs[];
>> +#if 0
>> + int irq;
>> + struct work_struct irq_work;
>> + struct mutex mutex;
>> +#endif
>> +};
>> +
>> +static irqreturn_t gsc_input_irq(int irq, void *data)
>> +{
>> + const struct gsc_input_button_priv *button_priv = data;
>> + struct input_dev *input = button_priv->input;
>> +
>> + dev_dbg(&input->dev, "irq%d code=%d\n", irq, button_priv->button->code);
>> + input_report_key(input, button_priv->button->code, 1);
>> + input_sync(input);
>> + input_report_key(input, button_priv->button->code, 0);
>> + input_sync(input);
>> +
>> + return IRQ_HANDLED;
>
> Hmm, so in the end this is just a bunch of buttons connected to
> interrupt lines. We already have a driver for that, called gpio-keys. It
> can work in pure interrupt mode (i.e. do not need real GPIO pin, just
> interrupt, and it will generate key down and up events when interrupt
> arrives, with possible delay for the up event).
>
Dmitry,
Yes that's what it does and yes your correct the gpio-keys driver will
work perfect for that. Thanks for calling me out on that - I had not
realized the gpio-keys driver could work from 'interrupts'.
I'll remove the input driver in my next submission. At least I know
how to properly write an input driver now from your previous review :)
Thanks,
Tim
^ permalink raw reply
* Re: [PATCH v4] HID: google: add google hammer HID driver
From: Dmitry Torokhov @ 2018-03-14 18:05 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Nicolas Boichat, Jiri Kosina, lkml, open list:HID CORE LAYER,
Guenter Roeck, Dmitry Torokhov
In-Reply-To: <CAO-hwJ+MqTubu6+QMOV6QkxR1_ph7OBx2hnBkPr9MfCs9YSPhQ@mail.gmail.com>
On Wed, Mar 14, 2018 at 9:16 AM, Benjamin Tissoires
<benjamin.tissoires@redhat.com> wrote:
>
> Hi Nicolas,
>
> On Wed, Mar 14, 2018 at 6:22 AM, Nicolas Boichat <drinkcat@chromium.org> wrote:
> > From: Wei-Ning Huang <wnhuang@chromium.org>
> >
> > Add Google hammer HID driver. This driver allow us to control hammer
> > keyboard backlight and support future features.
> >
> > We add a new HID quirk, that allows us to have the keyboard interface
> > to bind to google-hammer driver, while the touchpad interface can
> > bind to the multitouch driver.
> >
> > Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
> > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
> > ---
> >
> > Changes since v3:
> > - Rebase on latest linux-next/master, which moved the quirk list from
> > hid-core.c to hid-quirks.c. Also, completely rework the logic to make
> > it possible to bind google-hammer driver to keyboard interface, and
> > generic multitouch driver to touchpad interface, as it is much simpler
> > to do now that quirks are read early in hid_add_device.
>
> Ouch, this logic seems too convoluted for me.
>
> Just to be sure:
> - some of your devices export 2 USB interfaces on the same device (so
> same VID/PID)
> - one of this interface should be handled by hid-multitouch
> - the other should be handled by hid-google-hammer
> - the purpose of the new quirk and HID class are to allow
> hid-google-hammer to only bind on the non multitouch interface
>
> Am I correct?
>
> If I am, given that we now don't need to blacklist the drivers for
> hid-generic since e04a0442d33b8cf183bba38646447b891bb02123, I do not
> understand why simply declaring "{ HID_DEVICE(BUS_USB,
> HID_GROUP_GENERIC, USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_HAMMER)
> }," (same for the 2 others) is not enough to have hid-google-hammer
> binding only on the non-multitouch interface.
>
> Could you please give a shot at it?
>
Ah, cool, if we now forcibly try to rebind devices from generic HID to
specialized driver when it appears, then we indeed to not have to do
this dance with "overrides".
>
> > - Add dynamic backlight detection support (only such devices have an
> > output HID descriptor).
> > - Add support for wand (one more USB product ID).
> > - Add SPDX-License-Identifier, fix one minor formatting issue.
> >
> > drivers/hid/Kconfig | 6 ++
> > drivers/hid/Makefile | 1 +
> > drivers/hid/hid-core.c | 4 ++
> > drivers/hid/hid-google-hammer.c | 116 ++++++++++++++++++++++++++++++++
> > drivers/hid/hid-ids.h | 3 +
> > drivers/hid/hid-quirks.c | 5 ++
> > include/linux/hid.h | 2 +
> > 7 files changed, 137 insertions(+)
> > create mode 100644 drivers/hid/hid-google-hammer.c
> >
> > diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> > index 1fce4c94e5ac..60252fd796f6 100644
> > --- a/drivers/hid/Kconfig
> > +++ b/drivers/hid/Kconfig
> > @@ -339,6 +339,12 @@ config HOLTEK_FF
> > Say Y here if you have a Holtek On Line Grip based game controller
> > and want to have force feedback support for it.
> >
> > +config HID_GOOGLE_HAMMER
> > + tristate "Google Hammer Keyboard"
> > + depends on USB_HID && LEDS_CLASS
> > + ---help---
> > + Say Y here if you have a Google Hammer device.
> > +
> > config HID_GT683R
> > tristate "MSI GT68xR LED support"
> > depends on LEDS_CLASS && USB_HID
> > diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
> > index 713601c7bfa6..17a8bd97da9d 100644
> > --- a/drivers/hid/Makefile
> > +++ b/drivers/hid/Makefile
> > @@ -45,6 +45,7 @@ obj-$(CONFIG_HID_ELO) += hid-elo.o
> > obj-$(CONFIG_HID_EZKEY) += hid-ezkey.o
> > obj-$(CONFIG_HID_GEMBIRD) += hid-gembird.o
> > obj-$(CONFIG_HID_GFRM) += hid-gfrm.o
> > +obj-$(CONFIG_HID_GOOGLE_HAMMER) += hid-google-hammer.o
> > obj-$(CONFIG_HID_GT683R) += hid-gt683r.o
> > obj-$(CONFIG_HID_GYRATION) += hid-gyration.o
> > obj-$(CONFIG_HID_HOLTEK) += hid-holtek-kbd.o
> > diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> > index 36af26c2565b..61c7d135d680 100644
> > --- a/drivers/hid/hid-core.c
> > +++ b/drivers/hid/hid-core.c
> > @@ -2116,6 +2116,10 @@ int hid_add_device(struct hid_device *hdev)
> > ret = hid_scan_report(hdev);
> > if (ret)
> > hid_warn(hdev, "bad device descriptor (%d)\n", ret);
> > +
> > + if (hdev->quirks & HID_QUIRK_NO_GENERIC &&
> > + hdev->group == HID_GROUP_GENERIC)
> > + hdev->group = HID_GROUP_GENERIC_OVERRIDE;
> > }
> >
> > /* XXX hack, any other cleaner solution after the driver core
> > diff --git a/drivers/hid/hid-google-hammer.c b/drivers/hid/hid-google-hammer.c
> > new file mode 100644
> > index 000000000000..e7ad042a8464
> > --- /dev/null
> > +++ b/drivers/hid/hid-google-hammer.c
> > @@ -0,0 +1,116 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * HID driver for Google Hammer device.
> > + *
> > + * Copyright (c) 2017 Google Inc.
> > + * Author: Wei-Ning Huang <wnhuang@google.com>
> > + */
> > +
> > +/*
> > + * This program is free software; you can redistribute it and/or modify it
> > + * under the terms of the GNU General Public License as published by the Free
> > + * Software Foundation; either version 2 of the License, or (at your option)
> > + * any later version.
> > + */
> > +
> > +#include <linux/hid.h>
> > +#include <linux/leds.h>
> > +#include <linux/module.h>
> > +#include <linux/usb.h>
>
> Generally that's a no from me to include usb.h. I'd rather have you
> decide on which interface to create the LEDs based on the report
> descriptors, so we can replay the device with uhid without crashing
> the kernel.
>
> > +
> > +#include "hid-ids.h"
> > +
> > +#define MAX_BRIGHTNESS 100
> > +
> > +struct hammer_kbd_leds {
> > + struct led_classdev cdev;
> > + struct hid_device *hdev;
> > + u8 buf[2] ____cacheline_aligned;
> > +};
> > +
> > +static int hammer_kbd_brightness_set_blocking(struct led_classdev *cdev,
> > + enum led_brightness br)
> > +{
> > + struct hammer_kbd_leds *led = container_of(cdev,
> > + struct hammer_kbd_leds,
> > + cdev);
> > + int ret;
> > +
> > + led->buf[0] = 0;
> > + led->buf[1] = br;
> > +
> > + ret = hid_hw_output_report(led->hdev, led->buf, sizeof(led->buf));
> > + if (ret == -ENOSYS)
> > + ret = hid_hw_raw_request(led->hdev, 0, led->buf,
> > + sizeof(led->buf),
> > + HID_OUTPUT_REPORT,
> > + HID_REQ_SET_REPORT);
> > + if (ret < 0)
> > + hid_err(led->hdev, "failed to set keyboard backlight: %d\n",
> > + ret);
> > + return ret;
> > +}
> > +
> > +static int hammer_register_leds(struct hid_device *hdev)
> > +{
> > + struct hammer_kbd_leds *kbd_backlight;
> > +
> > + kbd_backlight = devm_kzalloc(&hdev->dev,
> > + sizeof(*kbd_backlight),
> > + GFP_KERNEL);
> > + if (!kbd_backlight)
> > + return -ENOMEM;
> > +
> > + kbd_backlight->hdev = hdev;
> > + kbd_backlight->cdev.name = "hammer::kbd_backlight";
> > + kbd_backlight->cdev.max_brightness = MAX_BRIGHTNESS;
> > + kbd_backlight->cdev.brightness_set_blocking =
> > + hammer_kbd_brightness_set_blocking;
> > + kbd_backlight->cdev.flags = LED_HW_PLUGGABLE;
> > +
> > + /* Set backlight to 0% initially. */
> > + hammer_kbd_brightness_set_blocking(&kbd_backlight->cdev, 0);
> > +
> > + return devm_led_classdev_register(&hdev->dev, &kbd_backlight->cdev);
> > +}
> > +
> > +static int hammer_input_configured(struct hid_device *hdev,
> > + struct hid_input *hi)
> > +{
> > + struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
> > +
> > + struct list_head *report_list =
> > + &hdev->report_enum[HID_OUTPUT_REPORT].report_list;
> > +
> > + if (intf->cur_altsetting->desc.bInterfaceProtocol ==
> > + USB_INTERFACE_PROTOCOL_KEYBOARD && !list_empty(report_list)) {
>
> See above. I am pretty sure you can find something in the report
> descriptor to discriminate the LED capable device from the others.
>
> Cheers,
> Benjamin
>
> > + int err = hammer_register_leds(hdev);
> > +
> > + if (err)
> > + hid_warn(hdev,
> > + "Failed to register keyboard backlight: %d\n",
> > + err);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static const struct hid_device_id hammer_devices[] = {
> > + { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC_OVERRIDE,
> > + USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_HAMMER) },
> > + { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC_OVERRIDE,
> > + USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_STAFF) },
> > + { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC_OVERRIDE,
> > + USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_WAND) },
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(hid, hammer_devices);
> > +
> > +static struct hid_driver hammer_driver = {
> > + .name = "hammer",
> > + .id_table = hammer_devices,
> > + .input_configured = hammer_input_configured,
> > +};
> > +module_hid_driver(hammer_driver);
> > +
> > +MODULE_LICENSE("GPL");
> > diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> > index 41f227a841fb..5a3a7ead3012 100644
> > --- a/drivers/hid/hid-ids.h
> > +++ b/drivers/hid/hid-ids.h
> > @@ -448,7 +448,10 @@
> > #define USB_DEVICE_ID_GOODTOUCH_000f 0x000f
> >
> > #define USB_VENDOR_ID_GOOGLE 0x18d1
> > +#define USB_DEVICE_ID_GOOGLE_HAMMER 0x5022
> > #define USB_DEVICE_ID_GOOGLE_TOUCH_ROSE 0x5028
> > +#define USB_DEVICE_ID_GOOGLE_STAFF 0x502b
> > +#define USB_DEVICE_ID_GOOGLE_WAND 0x502d
> >
> > #define USB_VENDOR_ID_GOTOP 0x08f2
> > #define USB_DEVICE_ID_SUPER_Q2 0x007f
> > diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
> > index 587e2681a53f..d112a14da200 100644
> > --- a/drivers/hid/hid-quirks.c
> > +++ b/drivers/hid/hid-quirks.c
> > @@ -84,6 +84,11 @@ static const struct hid_device_id hid_quirks[] = {
> > { HID_USB_DEVICE(USB_VENDOR_ID_FREESCALE, USB_DEVICE_ID_FREESCALE_MX28), HID_QUIRK_NOGET },
> > { HID_USB_DEVICE(USB_VENDOR_ID_FUTABA, USB_DEVICE_ID_LED_DISPLAY), HID_QUIRK_NO_INIT_REPORTS },
> > { HID_USB_DEVICE(USB_VENDOR_ID_GREENASIA, USB_DEVICE_ID_GREENASIA_DUAL_USB_JOYPAD), HID_QUIRK_MULTI_INPUT },
> > +#if IS_ENABLED(CONFIG_HID_GOOGLE_HAMMER)
> > + { HID_USB_DEVICE(USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_HAMMER), HID_QUIRK_NO_GENERIC },
> > + { HID_USB_DEVICE(USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_STAFF), HID_QUIRK_NO_GENERIC },
> > + { HID_USB_DEVICE(USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_WAND), HID_QUIRK_NO_GENERIC },
> > +#endif
> > { HID_USB_DEVICE(USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_DRIVING), HID_QUIRK_BADPAD | HID_QUIRK_MULTI_INPUT },
> > { HID_USB_DEVICE(USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_FIGHTING), HID_QUIRK_BADPAD | HID_QUIRK_MULTI_INPUT },
> > { HID_USB_DEVICE(USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_FLYING), HID_QUIRK_BADPAD | HID_QUIRK_MULTI_INPUT },
> > diff --git a/include/linux/hid.h b/include/linux/hid.h
> > index dfea5a656a1a..f2655265f8b5 100644
> > --- a/include/linux/hid.h
> > +++ b/include/linux/hid.h
> > @@ -340,6 +340,7 @@ struct hid_item {
> > #define HID_QUIRK_NO_EMPTY_INPUT 0x00000100
> > /* 0x00000200 reserved for backward compatibility, was NO_INIT_INPUT_REPORTS */
> > #define HID_QUIRK_ALWAYS_POLL 0x00000400
> > +#define HID_QUIRK_NO_GENERIC 0x00000800
> > #define HID_QUIRK_SKIP_OUTPUT_REPORTS 0x00010000
> > #define HID_QUIRK_SKIP_OUTPUT_REPORT_ID 0x00020000
> > #define HID_QUIRK_NO_OUTPUT_REPORTS_ON_INTR_EP 0x00040000
> > @@ -359,6 +360,7 @@ struct hid_item {
> > #define HID_GROUP_MULTITOUCH 0x0002
> > #define HID_GROUP_SENSOR_HUB 0x0003
> > #define HID_GROUP_MULTITOUCH_WIN_8 0x0004
> > +#define HID_GROUP_GENERIC_OVERRIDE 0x0005
> >
> > /*
> > * Vendor specific HID device groups
> > --
> > 2.16.2.804.g6dcf76e118-goog
> >
^ permalink raw reply
* Re: [PATCH 01/14] Input: atmel_mxt_ts - do not pass suspend mode in platform data
From: Nick Dyer @ 2018-03-14 20:51 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, Benson Leung, Olof Johansson, linux-kernel
In-Reply-To: <20180312190907.174301-2-dmitry.torokhov@gmail.com>
Hi Dmitry-
Thanks for sending these patches!
On Mon, Mar 12, 2018 at 12:08:54PM -0700, Dmitry Torokhov wrote:
> The way we are supposed to put controller to sleep and wake it up does not
> depend on the platform, but rather on controller itself. Controllers using
> T9 require manipulating T9 control register, while others, using newer
> T100, should be put to sleep by adjusting T7 power config.
I'm afraid this is actually a misconception. If you look at object table
for the older T9 device, you'll find it has the T7 object and it in fact
works exactly the same way as the T100-based device.
The MXT_SUSPEND_T9_CTRL is in there because on your older Pixel devices
the config saved into NVRAM on the touch controller has a zero byte in
the T9 CTRL setting, meaning the touch controller will never wake up
unless the driver knows to write 0x83 into it.
> We'll keep pdata->suspend_mode for now and remove it when we rework
> chromeos-laptop driver.
>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> drivers/input/touchscreen/atmel_mxt_ts.c | 15 ++++++---------
> 1 file changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
> index 7659bc48f1db8..1aabfae1297ba 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> @@ -2868,8 +2868,8 @@ static const struct attribute_group mxt_attr_group = {
>
> static void mxt_start(struct mxt_data *data)
> {
> - switch (data->pdata->suspend_mode) {
> - case MXT_SUSPEND_T9_CTRL:
> + switch (data->multitouch) {
> + case MXT_TOUCH_MULTI_T9:
> mxt_soft_reset(data);
>
> /* Touch enable */
> @@ -2878,7 +2878,7 @@ static void mxt_start(struct mxt_data *data)
> MXT_TOUCH_MULTI_T9, MXT_T9_CTRL, 0x83);
> break;
>
> - case MXT_SUSPEND_DEEP_SLEEP:
> + case MXT_TOUCH_MULTITOUCHSCREEN_T100:
> default:
> mxt_set_t7_power_cfg(data, MXT_POWER_CFG_RUN);
>
> @@ -2886,19 +2886,18 @@ static void mxt_start(struct mxt_data *data)
> mxt_t6_command(data, MXT_COMMAND_CALIBRATE, 1, false);
> break;
> }
> -
> }
>
> static void mxt_stop(struct mxt_data *data)
> {
> - switch (data->pdata->suspend_mode) {
> - case MXT_SUSPEND_T9_CTRL:
> + switch (data->multitouch) {
> + case MXT_TOUCH_MULTI_T9:
> /* Touch disable */
> mxt_write_object(data,
> MXT_TOUCH_MULTI_T9, MXT_T9_CTRL, 0);
> break;
>
> - case MXT_SUSPEND_DEEP_SLEEP:
> + case MXT_TOUCH_MULTITOUCHSCREEN_T100:
> default:
> mxt_set_t7_power_cfg(data, MXT_POWER_CFG_DEEPSLEEP);
> break;
> @@ -2954,8 +2953,6 @@ static const struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
> pdata->t19_keymap = keymap;
> }
>
> - pdata->suspend_mode = MXT_SUSPEND_DEEP_SLEEP;
> -
> return pdata;
> }
> #else
> --
> 2.16.2.660.g709887971b-goog
>
^ permalink raw reply
* Re: [PATCH 02/14] Input: atmel_mxt_ts - switch from OF to generic device properties
From: Nick Dyer @ 2018-03-14 20:51 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, Benson Leung, Olof Johansson, linux-kernel
In-Reply-To: <20180312190907.174301-3-dmitry.torokhov@gmail.com>
On Mon, Mar 12, 2018 at 12:08:55PM -0700, Dmitry Torokhov wrote:
> Instead of using OF-specific APIs to fecth device properties, let's switch
> to generic device properties API. This will allow us to use device
> properties on legacy ChromeOS devices and get rid of platform data down
> the road.
>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Nick Dyer <nick@shmanahar.org>
> ---
> drivers/input/touchscreen/atmel_mxt_ts.c | 59 ++++++++++++------------
> 1 file changed, 30 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
> index 1aabfae1297ba..072b78d3c6e00 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> @@ -29,6 +29,7 @@
> #include <linux/of.h>
> #include <linux/slab.h>
> #include <linux/gpio/consumer.h>
> +#include <linux/property.h>
> #include <asm/unaligned.h>
> #include <media/v4l2-device.h>
> #include <media/v4l2-ioctl.h>
> @@ -2920,47 +2921,52 @@ static void mxt_input_close(struct input_dev *dev)
> mxt_stop(data);
> }
>
> -#ifdef CONFIG_OF
> -static const struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
> +static const struct mxt_platform_data *
> +mxt_parse_device_properties(struct i2c_client *client)
> {
> + static const char keymap_property[] = "linux,gpio-keymap";
> struct mxt_platform_data *pdata;
> - struct device_node *np = client->dev.of_node;
> u32 *keymap;
> - int proplen, ret;
> -
> - if (!np)
> - return ERR_PTR(-ENOENT);
> + int n_keys;
> + int error;
>
> pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
> if (!pdata)
> return ERR_PTR(-ENOMEM);
>
> - if (of_find_property(np, "linux,gpio-keymap", &proplen)) {
> - pdata->t19_num_keys = proplen / sizeof(u32);
> + if (device_property_present(&client->dev, keymap_property)) {
> + n_keys = device_property_read_u32_array(&client->dev,
> + keymap_property,
> + NULL, 0);
> + if (n_keys <= 0) {
> + error = n_keys < 0 ? n_keys : -EINVAL;
> + dev_err(&client->dev,
> + "invalid/malformed '%s' property: %d\n",
> + keymap_property, error);
> + return ERR_PTR(error);
> + }
>
> - keymap = devm_kzalloc(&client->dev,
> - pdata->t19_num_keys * sizeof(keymap[0]),
> - GFP_KERNEL);
> + keymap = devm_kmalloc_array(&client->dev, n_keys, sizeof(u32),
> + GFP_KERNEL);
> if (!keymap)
> return ERR_PTR(-ENOMEM);
>
> - ret = of_property_read_u32_array(np, "linux,gpio-keymap",
> - keymap, pdata->t19_num_keys);
> - if (ret)
> - dev_warn(&client->dev,
> - "Couldn't read linux,gpio-keymap: %d\n", ret);
> + error = device_property_read_u32_array(&client->dev,
> + keymap_property,
> + keymap, n_keys);
> + if (error) {
> + dev_err(&client->dev,
> + "failed to parse '%s' property: %d\n",
> + keymap_property, error);
> + return ERR_PTR(error);
> + }
>
> pdata->t19_keymap = keymap;
> + pdata->t19_num_keys = n_keys;
> }
>
> return pdata;
> }
> -#else
> -static const struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
> -{
> - return ERR_PTR(-ENOENT);
> -}
> -#endif
>
> #ifdef CONFIG_ACPI
>
> @@ -3094,16 +3100,11 @@ mxt_get_platform_data(struct i2c_client *client)
> if (pdata)
> return pdata;
>
> - pdata = mxt_parse_dt(client);
> - if (!IS_ERR(pdata) || PTR_ERR(pdata) != -ENOENT)
> - return pdata;
> -
> pdata = mxt_parse_acpi(client);
> if (!IS_ERR(pdata) || PTR_ERR(pdata) != -ENOENT)
> return pdata;
>
> - dev_err(&client->dev, "No platform data specified\n");
> - return ERR_PTR(-EINVAL);
> + return mxt_parse_device_properties(client);
> }
>
> static int mxt_probe(struct i2c_client *client, const struct i2c_device_id *id)
> --
> 2.16.2.660.g709887971b-goog
>
^ permalink raw reply
* Re: [PATCH 03/14] Input: atmel_mxt_ts - switch ChromeOS ACPI devices to generic props
From: Nick Dyer @ 2018-03-14 20:52 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, Benson Leung, Olof Johansson, linux-kernel
In-Reply-To: <20180312190907.174301-4-dmitry.torokhov@gmail.com>
On Mon, Mar 12, 2018 at 12:08:56PM -0700, Dmitry Torokhov wrote:
> Move older ChromeOS devices describing Atmel controllers in ACPI, but not
> providing enough details to configure the controllers properly, from
> platform data over to generic device properties. This will allow us
> remove support for platform data later on, leaving only generic device
> properties in place.
>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Nick Dyer <nick@shmanahar.org>
> ---
> drivers/input/touchscreen/atmel_mxt_ts.c | 63 +++++++++++++++---------
> 1 file changed, 40 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
> index 072b78d3c6e00..cf2aac4e79ae8 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> @@ -2972,7 +2972,7 @@ mxt_parse_device_properties(struct i2c_client *client)
>
> struct mxt_acpi_platform_data {
> const char *hid;
> - struct mxt_platform_data pdata;
> + const struct property_entry *props;
> };
>
> static unsigned int samus_touchpad_buttons[] = {
> @@ -2982,14 +2982,16 @@ static unsigned int samus_touchpad_buttons[] = {
> BTN_LEFT
> };
>
> +static const struct property_entry samus_touchpad_props[] = {
> + PROPERTY_ENTRY_U32_ARRAY("linux,gpio-keymap", samus_touchpad_buttons),
> + { }
> +};
> +
> static struct mxt_acpi_platform_data samus_platform_data[] = {
> {
> /* Touchpad */
> .hid = "ATML0000",
> - .pdata = {
> - .t19_num_keys = ARRAY_SIZE(samus_touchpad_buttons),
> - .t19_keymap = samus_touchpad_buttons,
> - },
> + .props = samus_touchpad_props,
> },
> {
> /* Touchscreen */
> @@ -3007,14 +3009,16 @@ static unsigned int chromebook_tp_buttons[] = {
> BTN_LEFT
> };
>
> +static const struct property_entry chromebook_tp_props[] = {
> + PROPERTY_ENTRY_U32_ARRAY("linux,gpio-keymap", chromebook_tp_buttons),
> + { }
> +};
> +
> static struct mxt_acpi_platform_data chromebook_platform_data[] = {
> {
> /* Touchpad */
> .hid = "ATML0000",
> - .pdata = {
> - .t19_num_keys = ARRAY_SIZE(chromebook_tp_buttons),
> - .t19_keymap = chromebook_tp_buttons,
> - },
> + .props = chromebook_tp_props,
> },
> {
> /* Touchscreen */
> @@ -3044,7 +3048,7 @@ static const struct dmi_system_id mxt_dmi_table[] = {
> { }
> };
>
> -static const struct mxt_platform_data *mxt_parse_acpi(struct i2c_client *client)
> +static int mxt_acpi_probe(struct i2c_client *client)
> {
> struct acpi_device *adev;
> const struct dmi_system_id *system_id;
> @@ -3061,33 +3065,46 @@ static const struct mxt_platform_data *mxt_parse_acpi(struct i2c_client *client)
> * as a threshold.
> */
> if (client->addr < 0x40)
> - return ERR_PTR(-ENXIO);
> + return -ENXIO;
>
> adev = ACPI_COMPANION(&client->dev);
> if (!adev)
> - return ERR_PTR(-ENOENT);
> + return -ENOENT;
>
> system_id = dmi_first_match(mxt_dmi_table);
> if (!system_id)
> - return ERR_PTR(-ENOENT);
> + return -ENOENT;
>
> acpi_pdata = system_id->driver_data;
> if (!acpi_pdata)
> - return ERR_PTR(-ENOENT);
> + return -ENOENT;
>
> while (acpi_pdata->hid) {
> - if (!strcmp(acpi_device_hid(adev), acpi_pdata->hid))
> - return &acpi_pdata->pdata;
> + if (!strcmp(acpi_device_hid(adev), acpi_pdata->hid)) {
> + /*
> + * Remove previously installed properties if we
> + * are probing this device not for the very first
> + * time.
> + */
> + device_remove_properties(&client->dev);
> +
> + /*
> + * Now install the platform-specific properties
> + * that are missing from ACPI.
> + */
> + device_add_properties(&client->dev, acpi_pdata->props);
> + break;
> + }
>
> acpi_pdata++;
> }
>
> - return ERR_PTR(-ENOENT);
> + return 0;
> }
> #else
> -static const struct mxt_platform_data *mxt_parse_acpi(struct i2c_client *client)
> +static int mxt_acpi_probe(struct i2c_client *client)
> {
> - return ERR_PTR(-ENOENT);
> + return -ENOENT;
> }
> #endif
>
> @@ -3100,10 +3117,6 @@ mxt_get_platform_data(struct i2c_client *client)
> if (pdata)
> return pdata;
>
> - pdata = mxt_parse_acpi(client);
> - if (!IS_ERR(pdata) || PTR_ERR(pdata) != -ENOENT)
> - return pdata;
> -
> return mxt_parse_device_properties(client);
> }
>
> @@ -3113,6 +3126,10 @@ static int mxt_probe(struct i2c_client *client, const struct i2c_device_id *id)
> const struct mxt_platform_data *pdata;
> int error;
>
> + error = mxt_acpi_probe(client);
> + if (error && error != -ENOENT)
> + return error;
> +
> pdata = mxt_get_platform_data(client);
> if (IS_ERR(pdata))
> return PTR_ERR(pdata);
> --
> 2.16.2.660.g709887971b-goog
>
^ permalink raw reply
* Re: [PATCH 14/14] Input: atmel_mxt_ts - remove platform data support
From: Nick Dyer @ 2018-03-14 20:59 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, Benson Leung, Olof Johansson, linux-kernel
In-Reply-To: <20180312190907.174301-15-dmitry.torokhov@gmail.com>
On Mon, Mar 12, 2018 at 12:09:07PM -0700, Dmitry Torokhov wrote:
> Date: Mon, 12 Mar 2018 12:09:07 -0700
> From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> To: linux-input@vger.kernel.org, Benson Leung <bleung@chromium.org>
> Cc: Nick Dyer <nick@shmanahar.org>, Olof Johansson <olof@lixom.net>,
> linux-kernel@vger.kernel.org
> Subject: [PATCH 14/14] Input: atmel_mxt_ts - remove platform data support
>
> Now that there are no users of custom Atmel platform data, and everyone
> has switched to the generic device properties, we can remove support for
> the platform data.
Thanks, this is a nice tidy up.
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> MAINTAINERS | 1 -
> drivers/input/touchscreen/atmel_mxt_ts.c | 125 +++++++++------------
> include/linux/platform_data/atmel_mxt_ts.h | 31 -----
> 3 files changed, 50 insertions(+), 107 deletions(-)
> delete mode 100644 include/linux/platform_data/atmel_mxt_ts.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4623caf8d72d8..37b70874a4771 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2394,7 +2394,6 @@ T: git git://github.com/ndyer/linux.git
> S: Maintained
> F: Documentation/devicetree/bindings/input/atmel,maxtouch.txt
> F: drivers/input/touchscreen/atmel_mxt_ts.c
> -F: include/linux/platform_data/atmel_mxt_ts.h
>
> ATMEL SAMA5D2 ADC DRIVER
> M: Ludovic Desroches <ludovic.desroches@microchip.com>
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
> index cf2aac4e79ae8..642211254acc4 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> @@ -23,10 +23,10 @@
> #include <linux/delay.h>
> #include <linux/firmware.h>
> #include <linux/i2c.h>
> -#include <linux/platform_data/atmel_mxt_ts.h>
> #include <linux/input/mt.h>
> #include <linux/interrupt.h>
> #include <linux/of.h>
> +#include <linux/property.h>
> #include <linux/slab.h>
> #include <linux/gpio/consumer.h>
> #include <linux/property.h>
> @@ -274,7 +274,6 @@ struct mxt_data {
> struct i2c_client *client;
> struct input_dev *input_dev;
> char phys[64]; /* device physical location */
> - const struct mxt_platform_data *pdata;
> struct mxt_object *object_table;
> struct mxt_info info;
> unsigned int irq;
> @@ -325,6 +324,9 @@ struct mxt_data {
>
> /* for config update handling */
> struct completion crc_completion;
> +
> + u32 *t19_keymap;
> + unsigned int t19_num_keys;
> };
>
> struct mxt_vb2_buffer {
> @@ -743,15 +745,14 @@ static int mxt_write_object(struct mxt_data *data,
> static void mxt_input_button(struct mxt_data *data, u8 *message)
> {
> struct input_dev *input = data->input_dev;
> - const struct mxt_platform_data *pdata = data->pdata;
> int i;
>
> - for (i = 0; i < pdata->t19_num_keys; i++) {
> - if (pdata->t19_keymap[i] == KEY_RESERVED)
> + for (i = 0; i < data->t19_num_keys; i++) {
> + if (data->t19_keymap[i] == KEY_RESERVED)
> continue;
>
> /* Active-low switch */
> - input_report_key(input, pdata->t19_keymap[i],
> + input_report_key(input, data->t19_keymap[i],
> !(message[1] & BIT(i)));
> }
> }
> @@ -759,7 +760,7 @@ static void mxt_input_button(struct mxt_data *data, u8 *message)
> static void mxt_input_sync(struct mxt_data *data)
> {
> input_mt_report_pointer_emulation(data->input_dev,
> - data->pdata->t19_num_keys);
> + data->t19_num_keys);
> input_sync(data->input_dev);
> }
>
> @@ -1859,7 +1860,6 @@ static void mxt_input_close(struct input_dev *dev);
> static void mxt_set_up_as_touchpad(struct input_dev *input_dev,
> struct mxt_data *data)
> {
> - const struct mxt_platform_data *pdata = data->pdata;
> int i;
>
> input_dev->name = "Atmel maXTouch Touchpad";
> @@ -1873,15 +1873,14 @@ static void mxt_set_up_as_touchpad(struct input_dev *input_dev,
> input_abs_set_res(input_dev, ABS_MT_POSITION_Y,
> MXT_PIXELS_PER_MM);
>
> - for (i = 0; i < pdata->t19_num_keys; i++)
> - if (pdata->t19_keymap[i] != KEY_RESERVED)
> + for (i = 0; i < data->t19_num_keys; i++)
> + if (data->t19_keymap[i] != KEY_RESERVED)
> input_set_capability(input_dev, EV_KEY,
> - pdata->t19_keymap[i]);
> + data->t19_keymap[i]);
> }
>
> static int mxt_initialize_input_device(struct mxt_data *data)
> {
> - const struct mxt_platform_data *pdata = data->pdata;
> struct device *dev = &data->client->dev;
> struct input_dev *input_dev;
> int error;
> @@ -1947,7 +1946,7 @@ static int mxt_initialize_input_device(struct mxt_data *data)
> }
>
> /* If device has buttons we assume it is a touchpad */
> - if (pdata->t19_num_keys) {
> + if (data->t19_num_keys) {
> mxt_set_up_as_touchpad(input_dev, data);
> mt_flags |= INPUT_MT_POINTER;
> } else {
> @@ -2921,51 +2920,42 @@ static void mxt_input_close(struct input_dev *dev)
> mxt_stop(data);
> }
>
> -static const struct mxt_platform_data *
> -mxt_parse_device_properties(struct i2c_client *client)
> +static int mxt_parse_device_properties(struct mxt_data *data)
> {
> static const char keymap_property[] = "linux,gpio-keymap";
> - struct mxt_platform_data *pdata;
> + struct device *dev = &data->client->dev;
> u32 *keymap;
> int n_keys;
> int error;
>
> - pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
> - if (!pdata)
> - return ERR_PTR(-ENOMEM);
> -
> - if (device_property_present(&client->dev, keymap_property)) {
> - n_keys = device_property_read_u32_array(&client->dev,
> - keymap_property,
> + if (device_property_present(dev, keymap_property)) {
> + n_keys = device_property_read_u32_array(dev, keymap_property,
> NULL, 0);
> if (n_keys <= 0) {
> error = n_keys < 0 ? n_keys : -EINVAL;
> - dev_err(&client->dev,
> - "invalid/malformed '%s' property: %d\n",
> + dev_err(dev, "invalid/malformed '%s' property: %d\n",
> keymap_property, error);
> - return ERR_PTR(error);
> + return error;
> }
>
> - keymap = devm_kmalloc_array(&client->dev, n_keys, sizeof(u32),
> + keymap = devm_kmalloc_array(dev, n_keys, sizeof(*keymap),
> GFP_KERNEL);
> if (!keymap)
> - return ERR_PTR(-ENOMEM);
> + return -ENOMEM;
>
> - error = device_property_read_u32_array(&client->dev,
> - keymap_property,
> + error = device_property_read_u32_array(dev, keymap_property,
> keymap, n_keys);
> if (error) {
> - dev_err(&client->dev,
> - "failed to parse '%s' property: %d\n",
> + dev_err(dev, "failed to parse '%s' property: %d\n",
> keymap_property, error);
> - return ERR_PTR(error);
> + return error;
> }
>
> - pdata->t19_keymap = keymap;
> - pdata->t19_num_keys = n_keys;
> + data->t19_keymap = keymap;
> + data->t19_num_keys = n_keys;
> }
>
> - return pdata;
> + return 0;
> }
>
> #ifdef CONFIG_ACPI
> @@ -3048,25 +3038,12 @@ static const struct dmi_system_id mxt_dmi_table[] = {
> { }
> };
>
> -static int mxt_acpi_probe(struct i2c_client *client)
> +static int mxt_prepare_acpi_properties(struct i2c_client *client)
> {
> struct acpi_device *adev;
> const struct dmi_system_id *system_id;
> const struct mxt_acpi_platform_data *acpi_pdata;
>
> - /*
> - * Ignore ACPI devices representing bootloader mode.
> - *
> - * This is a bit of a hack: Google Chromebook BIOS creates ACPI
> - * devices for both application and bootloader modes, but we are
> - * interested in application mode only (if device is in bootloader
> - * mode we'll end up switching into application anyway). So far
> - * application mode addresses were all above 0x40, so we'll use it
> - * as a threshold.
> - */
> - if (client->addr < 0x40)
> - return -ENXIO;
Could you use 0x4a, since that's the lowest application mode address,
same in the other place.
Can I ask if you've checked the behaviour if the device is probed while
it's already in bootloader mode? Ideally you want to be able to recover
from a bad firmware flash.
> -
> adev = ACPI_COMPANION(&client->dev);
> if (!adev)
> return -ENOENT;
> @@ -3102,37 +3079,29 @@ static int mxt_acpi_probe(struct i2c_client *client)
> return 0;
> }
> #else
> -static int mxt_acpi_probe(struct i2c_client *client)
> +static int mxt_prepare_acpi_properties(struct i2c_client *client)
> {
> return -ENOENT;
> }
> #endif
>
> -static const struct mxt_platform_data *
> -mxt_get_platform_data(struct i2c_client *client)
> -{
> - const struct mxt_platform_data *pdata;
> -
> - pdata = dev_get_platdata(&client->dev);
> - if (pdata)
> - return pdata;
> -
> - return mxt_parse_device_properties(client);
> -}
> -
> static int mxt_probe(struct i2c_client *client, const struct i2c_device_id *id)
> {
> struct mxt_data *data;
> - const struct mxt_platform_data *pdata;
> int error;
>
> - error = mxt_acpi_probe(client);
> - if (error && error != -ENOENT)
> - return error;
> -
> - pdata = mxt_get_platform_data(client);
> - if (IS_ERR(pdata))
> - return PTR_ERR(pdata);
> + /*
> + * Ignore ACPI devices representing bootloader mode.
> + *
> + * This is a bit of a hack: Google Chromebook BIOS creates ACPI
> + * devices for both application and bootloader modes, but we are
> + * interested in application mode only (if device is in bootloader
> + * mode we'll end up switching into application anyway). So far
> + * application mode addresses were all above 0x40, so we'll use it
> + * as a threshold.
> + */
> + if (ACPI_COMPANION(&client->dev) && client->addr < 0x40)
> + return -ENXIO;
>
> data = devm_kzalloc(&client->dev, sizeof(struct mxt_data), GFP_KERNEL);
> if (!data)
> @@ -3142,7 +3111,6 @@ static int mxt_probe(struct i2c_client *client, const struct i2c_device_id *id)
> client->adapter->nr, client->addr);
>
> data->client = client;
> - data->pdata = pdata;
> data->irq = client->irq;
> i2c_set_clientdata(client, data);
>
> @@ -3150,6 +3118,14 @@ static int mxt_probe(struct i2c_client *client, const struct i2c_device_id *id)
> init_completion(&data->reset_completion);
> init_completion(&data->crc_completion);
>
> + error = mxt_prepare_acpi_properties(client);
> + if (error && error != -ENOENT)
> + return error;
> +
> + error = mxt_parse_device_properties(data);
> + if (error)
> + return error;
> +
> data->reset_gpio = devm_gpiod_get_optional(&client->dev,
> "reset", GPIOD_OUT_LOW);
> if (IS_ERR(data->reset_gpio)) {
> @@ -3159,8 +3135,7 @@ static int mxt_probe(struct i2c_client *client, const struct i2c_device_id *id)
> }
>
> error = devm_request_threaded_irq(&client->dev, client->irq,
> - NULL, mxt_interrupt,
> - pdata->irqflags | IRQF_ONESHOT,
> + NULL, mxt_interrupt, IRQF_ONESHOT,
> client->name, data);
> if (error) {
> dev_err(&client->dev, "Failed to register interrupt\n");
> @@ -3280,7 +3255,7 @@ MODULE_DEVICE_TABLE(i2c, mxt_id);
> static struct i2c_driver mxt_driver = {
> .driver = {
> .name = "atmel_mxt_ts",
> - .of_match_table = of_match_ptr(mxt_of_match),
> + .of_match_table = mxt_of_match,
> .acpi_match_table = ACPI_PTR(mxt_acpi_id),
> .pm = &mxt_pm_ops,
> },
> diff --git a/include/linux/platform_data/atmel_mxt_ts.h b/include/linux/platform_data/atmel_mxt_ts.h
> deleted file mode 100644
> index 695035a8d7fb9..0000000000000
> --- a/include/linux/platform_data/atmel_mxt_ts.h
> +++ /dev/null
> @@ -1,31 +0,0 @@
> -/*
> - * Atmel maXTouch Touchscreen driver
> - *
> - * Copyright (C) 2010 Samsung Electronics Co.Ltd
> - * Author: Joonyoung Shim <jy0922.shim@samsung.com>
> - *
> - * This program is free software; you can redistribute it and/or modify it
> - * under the terms of the GNU General Public License as published by the
> - * Free Software Foundation; either version 2 of the License, or (at your
> - * option) any later version.
> - */
> -
> -#ifndef __LINUX_PLATFORM_DATA_ATMEL_MXT_TS_H
> -#define __LINUX_PLATFORM_DATA_ATMEL_MXT_TS_H
> -
> -#include <linux/types.h>
> -
> -enum mxt_suspend_mode {
> - MXT_SUSPEND_DEEP_SLEEP = 0,
> - MXT_SUSPEND_T9_CTRL = 1,
> -};
> -
> -/* The platform data for the Atmel maXTouch touchscreen driver */
> -struct mxt_platform_data {
> - unsigned long irqflags;
> - u8 t19_num_keys;
> - const unsigned int *t19_keymap;
> - enum mxt_suspend_mode suspend_mode;
> -};
> -
> -#endif /* __LINUX_PLATFORM_DATA_ATMEL_MXT_TS_H */
> --
> 2.16.2.660.g709887971b-goog
>
^ permalink raw reply
* Re: [PATCH 00/47] arch-removal: device drivers
From: Rafael J. Wysocki @ 2018-03-14 22:45 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Ulf Hansson, open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
Wolfram Sang, linux-iio, Viresh Kumar, Linus Walleij,
alexandre.belloni, linux-ide, netdev, linux-mtd, linux-i2c,
linux-rtc, Lars-Peter Clausen, Herbert Xu, Jonathan Corbet,
open list:DOCUMENTATION, Alan Stern, linux-serial, Jiri Slaby,
linux-mmc, shli, wg, linux-crypto, Linux PWM List, linux-watchdog
In-Reply-To: <20180314153603.3127932-1-arnd@arndb.de>
On Wed, Mar 14, 2018 at 4:35 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> Hi driver maintainers,
>
> I just posted one series with the removal of eight architectures,
> see https://lkml.org/lkml/2018/3/14/505 for details, or
> https://lwn.net/Articles/748074/ for more background.
>
> These are the device drivers that go along with them. I have already
> picked up the drivers for arch/metag/ into my tree, they were reviewed
> earlier.
>
> Please let me know if you have any concerns with the patch, or if you
> prefer to pick up the patches in your respective trees. I created
> the patches with 'git format-patch -D', so they will not apply without
> manually removing those files.
>
> For anything else, I'd keep the removal patches in my asm-generic tree
> and will send a pull request for 4.17 along with the actual arch removal.
Please include the cpufreq patches into that and you can add ACKs from
me on them if that helps.
Thanks!
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH] Input: alps - Demystify trackstick initialization for v3 and v6 protocols
From: Pali Rohár @ 2018-03-14 22:58 UTC (permalink / raw)
To: Masaki Ota
Cc: Dmitry Torokhov, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <TYXPR01MB0719092EDE164BA6C576A1C7C7D10@TYXPR01MB0719.jpnprd01.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1618 bytes --]
Hi! Thank you for information.
Your PS/2 Aux Port Control description seems to really matches. Just
there is reverse order of bits. Bit 0 in description is highest,
therefore matches BIT(7) macro.
Bit 6 in description (BIT(1) in code) describes SP Extended Mode which
alps.c enabled. And in that description is written:
"If 1 SP is extended packet format (driver must set SP raw mode and GP
absolute mode)."
Do you have any idea what "SP raw mode" is? How to set it? For me it
looks like it could be that extended mode of trackstick itself.
"GP absolute mode" I guess is GlidePoint absolute mode, therefore enable
6 byte absolute mode for touchpad.
And for Bit 7 (BIT(0)) is written:
This bit is used with the PS/2 Aux port to use the Pass-Thru mode ( see
appendix A ). Do you have some information about this appendix A?
On Wednesday 14 March 2018 10:21:43 Masaki Ota wrote:
> Hi, Pali,
>
> I just picked up the spec which relates with trackstic.
>
> Best Regards,
> Masaki Ota
> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@gmail.com]
> Sent: Tuesday, March 13, 2018 8:14 AM
> To: 太田 真喜 Masaki Ota <masaki.ota@jp.alps.com>; Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: linux-input@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] Input: alps - Demystify trackstick initialization for v3 and v6 protocols
>
> Masaki, if you have access to the internal ALPS v3 / Rushmore documentation, I would like to have a review of this patch or confirmation of those information :-)
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply
* Re: [PATCH v4] HID: google: add google hammer HID driver
From: Nicolas Boichat @ 2018-03-15 1:22 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Benjamin Tissoires, Jiri Kosina, lkml, open list:HID CORE LAYER,
Guenter Roeck
In-Reply-To: <CAE_wzQ_Bw3bh-e_KX-y+4PODeCo7PAGHih9zsWZFNAcA5c0F1Q@mail.gmail.com>
On Thu, Mar 15, 2018 at 2:05 AM, Dmitry Torokhov <dtor@chromium.org> wrote:
> On Wed, Mar 14, 2018 at 9:16 AM, Benjamin Tissoires
> <benjamin.tissoires@redhat.com> wrote:
>>
>> Hi Nicolas,
>>
>> On Wed, Mar 14, 2018 at 6:22 AM, Nicolas Boichat <drinkcat@chromium.org> wrote:
>> > From: Wei-Ning Huang <wnhuang@chromium.org>
>> >
>> > Add Google hammer HID driver. This driver allow us to control hammer
>> > keyboard backlight and support future features.
>> >
>> > We add a new HID quirk, that allows us to have the keyboard interface
>> > to bind to google-hammer driver, while the touchpad interface can
>> > bind to the multitouch driver.
>> >
>> > Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
>> > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
>> > ---
>> >
>> > Changes since v3:
>> > - Rebase on latest linux-next/master, which moved the quirk list from
>> > hid-core.c to hid-quirks.c. Also, completely rework the logic to make
>> > it possible to bind google-hammer driver to keyboard interface, and
>> > generic multitouch driver to touchpad interface, as it is much simpler
>> > to do now that quirks are read early in hid_add_device.
>>
>> Ouch, this logic seems too convoluted for me.
>>
>> Just to be sure:
>> - some of your devices export 2 USB interfaces on the same device (so
>> same VID/PID)
>> - one of this interface should be handled by hid-multitouch
>> - the other should be handled by hid-google-hammer
>> - the purpose of the new quirk and HID class are to allow
>> hid-google-hammer to only bind on the non multitouch interface
>>
>> Am I correct?
>>
>> If I am, given that we now don't need to blacklist the drivers for
>> hid-generic since e04a0442d33b8cf183bba38646447b891bb02123, I do not
>> understand why simply declaring "{ HID_DEVICE(BUS_USB,
>> HID_GROUP_GENERIC, USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_HAMMER)
>> }," (same for the 2 others) is not enough to have hid-google-hammer
>> binding only on the non-multitouch interface.
>>
>> Could you please give a shot at it?
>>
>
> Ah, cool, if we now forcibly try to rebind devices from generic HID to
> specialized driver when it appears, then we indeed to not have to do
> this dance with "overrides".
Nice, that works, thanks Benjamin. v5 coming up in a few minutes.
>>
>> > - Add dynamic backlight detection support (only such devices have an
>> > output HID descriptor).
>> > - Add support for wand (one more USB product ID).
>> > - Add SPDX-License-Identifier, fix one minor formatting issue.
>> >
>> > drivers/hid/Kconfig | 6 ++
>> > drivers/hid/Makefile | 1 +
>> > drivers/hid/hid-core.c | 4 ++
>> > drivers/hid/hid-google-hammer.c | 116 ++++++++++++++++++++++++++++++++
>> > drivers/hid/hid-ids.h | 3 +
>> > drivers/hid/hid-quirks.c | 5 ++
>> > include/linux/hid.h | 2 +
>> > 7 files changed, 137 insertions(+)
>> > create mode 100644 drivers/hid/hid-google-hammer.c
>> >
>> > diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
>> > index 1fce4c94e5ac..60252fd796f6 100644
>> > --- a/drivers/hid/Kconfig
>> > +++ b/drivers/hid/Kconfig
>> > @@ -339,6 +339,12 @@ config HOLTEK_FF
>> > Say Y here if you have a Holtek On Line Grip based game controller
>> > and want to have force feedback support for it.
>> >
>> > +config HID_GOOGLE_HAMMER
>> > + tristate "Google Hammer Keyboard"
>> > + depends on USB_HID && LEDS_CLASS
>> > + ---help---
>> > + Say Y here if you have a Google Hammer device.
>> > +
>> > config HID_GT683R
>> > tristate "MSI GT68xR LED support"
>> > depends on LEDS_CLASS && USB_HID
>> > diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
>> > index 713601c7bfa6..17a8bd97da9d 100644
>> > --- a/drivers/hid/Makefile
>> > +++ b/drivers/hid/Makefile
>> > @@ -45,6 +45,7 @@ obj-$(CONFIG_HID_ELO) += hid-elo.o
>> > obj-$(CONFIG_HID_EZKEY) += hid-ezkey.o
>> > obj-$(CONFIG_HID_GEMBIRD) += hid-gembird.o
>> > obj-$(CONFIG_HID_GFRM) += hid-gfrm.o
>> > +obj-$(CONFIG_HID_GOOGLE_HAMMER) += hid-google-hammer.o
>> > obj-$(CONFIG_HID_GT683R) += hid-gt683r.o
>> > obj-$(CONFIG_HID_GYRATION) += hid-gyration.o
>> > obj-$(CONFIG_HID_HOLTEK) += hid-holtek-kbd.o
>> > diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
>> > index 36af26c2565b..61c7d135d680 100644
>> > --- a/drivers/hid/hid-core.c
>> > +++ b/drivers/hid/hid-core.c
>> > @@ -2116,6 +2116,10 @@ int hid_add_device(struct hid_device *hdev)
>> > ret = hid_scan_report(hdev);
>> > if (ret)
>> > hid_warn(hdev, "bad device descriptor (%d)\n", ret);
>> > +
>> > + if (hdev->quirks & HID_QUIRK_NO_GENERIC &&
>> > + hdev->group == HID_GROUP_GENERIC)
>> > + hdev->group = HID_GROUP_GENERIC_OVERRIDE;
>> > }
>> >
>> > /* XXX hack, any other cleaner solution after the driver core
>> > diff --git a/drivers/hid/hid-google-hammer.c b/drivers/hid/hid-google-hammer.c
>> > new file mode 100644
>> > index 000000000000..e7ad042a8464
>> > --- /dev/null
>> > +++ b/drivers/hid/hid-google-hammer.c
>> > @@ -0,0 +1,116 @@
>> > +// SPDX-License-Identifier: GPL-2.0+
>> > +/*
>> > + * HID driver for Google Hammer device.
>> > + *
>> > + * Copyright (c) 2017 Google Inc.
>> > + * Author: Wei-Ning Huang <wnhuang@google.com>
>> > + */
>> > +
>> > +/*
>> > + * This program is free software; you can redistribute it and/or modify it
>> > + * under the terms of the GNU General Public License as published by the Free
>> > + * Software Foundation; either version 2 of the License, or (at your option)
>> > + * any later version.
>> > + */
>> > +
>> > +#include <linux/hid.h>
>> > +#include <linux/leds.h>
>> > +#include <linux/module.h>
>> > +#include <linux/usb.h>
>>
>> Generally that's a no from me to include usb.h. I'd rather have you
>> decide on which interface to create the LEDs based on the report
>> descriptors, so we can replay the device with uhid without crashing
>> the kernel.
>>
>> > +
>> > +#include "hid-ids.h"
>> > +
>> > +#define MAX_BRIGHTNESS 100
>> > +
>> > +struct hammer_kbd_leds {
>> > + struct led_classdev cdev;
>> > + struct hid_device *hdev;
>> > + u8 buf[2] ____cacheline_aligned;
>> > +};
>> > +
>> > +static int hammer_kbd_brightness_set_blocking(struct led_classdev *cdev,
>> > + enum led_brightness br)
>> > +{
>> > + struct hammer_kbd_leds *led = container_of(cdev,
>> > + struct hammer_kbd_leds,
>> > + cdev);
>> > + int ret;
>> > +
>> > + led->buf[0] = 0;
>> > + led->buf[1] = br;
>> > +
>> > + ret = hid_hw_output_report(led->hdev, led->buf, sizeof(led->buf));
>> > + if (ret == -ENOSYS)
>> > + ret = hid_hw_raw_request(led->hdev, 0, led->buf,
>> > + sizeof(led->buf),
>> > + HID_OUTPUT_REPORT,
>> > + HID_REQ_SET_REPORT);
>> > + if (ret < 0)
>> > + hid_err(led->hdev, "failed to set keyboard backlight: %d\n",
>> > + ret);
>> > + return ret;
>> > +}
>> > +
>> > +static int hammer_register_leds(struct hid_device *hdev)
>> > +{
>> > + struct hammer_kbd_leds *kbd_backlight;
>> > +
>> > + kbd_backlight = devm_kzalloc(&hdev->dev,
>> > + sizeof(*kbd_backlight),
>> > + GFP_KERNEL);
>> > + if (!kbd_backlight)
>> > + return -ENOMEM;
>> > +
>> > + kbd_backlight->hdev = hdev;
>> > + kbd_backlight->cdev.name = "hammer::kbd_backlight";
>> > + kbd_backlight->cdev.max_brightness = MAX_BRIGHTNESS;
>> > + kbd_backlight->cdev.brightness_set_blocking =
>> > + hammer_kbd_brightness_set_blocking;
>> > + kbd_backlight->cdev.flags = LED_HW_PLUGGABLE;
>> > +
>> > + /* Set backlight to 0% initially. */
>> > + hammer_kbd_brightness_set_blocking(&kbd_backlight->cdev, 0);
>> > +
>> > + return devm_led_classdev_register(&hdev->dev, &kbd_backlight->cdev);
>> > +}
>> > +
>> > +static int hammer_input_configured(struct hid_device *hdev,
>> > + struct hid_input *hi)
>> > +{
>> > + struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
>> > +
>> > + struct list_head *report_list =
>> > + &hdev->report_enum[HID_OUTPUT_REPORT].report_list;
>> > +
>> > + if (intf->cur_altsetting->desc.bInterfaceProtocol ==
>> > + USB_INTERFACE_PROTOCOL_KEYBOARD && !list_empty(report_list)) {
>>
>> See above. I am pretty sure you can find something in the report
>> descriptor to discriminate the LED capable device from the others.
>>
>> Cheers,
>> Benjamin
>>
>> > + int err = hammer_register_leds(hdev);
>> > +
>> > + if (err)
>> > + hid_warn(hdev,
>> > + "Failed to register keyboard backlight: %d\n",
>> > + err);
>> > + }
>> > +
>> > + return 0;
>> > +}
>> > +
>> > +static const struct hid_device_id hammer_devices[] = {
>> > + { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC_OVERRIDE,
>> > + USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_HAMMER) },
>> > + { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC_OVERRIDE,
>> > + USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_STAFF) },
>> > + { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC_OVERRIDE,
>> > + USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_WAND) },
>> > + { }
>> > +};
>> > +MODULE_DEVICE_TABLE(hid, hammer_devices);
>> > +
>> > +static struct hid_driver hammer_driver = {
>> > + .name = "hammer",
>> > + .id_table = hammer_devices,
>> > + .input_configured = hammer_input_configured,
>> > +};
>> > +module_hid_driver(hammer_driver);
>> > +
>> > +MODULE_LICENSE("GPL");
>> > diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
>> > index 41f227a841fb..5a3a7ead3012 100644
>> > --- a/drivers/hid/hid-ids.h
>> > +++ b/drivers/hid/hid-ids.h
>> > @@ -448,7 +448,10 @@
>> > #define USB_DEVICE_ID_GOODTOUCH_000f 0x000f
>> >
>> > #define USB_VENDOR_ID_GOOGLE 0x18d1
>> > +#define USB_DEVICE_ID_GOOGLE_HAMMER 0x5022
>> > #define USB_DEVICE_ID_GOOGLE_TOUCH_ROSE 0x5028
>> > +#define USB_DEVICE_ID_GOOGLE_STAFF 0x502b
>> > +#define USB_DEVICE_ID_GOOGLE_WAND 0x502d
>> >
>> > #define USB_VENDOR_ID_GOTOP 0x08f2
>> > #define USB_DEVICE_ID_SUPER_Q2 0x007f
>> > diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
>> > index 587e2681a53f..d112a14da200 100644
>> > --- a/drivers/hid/hid-quirks.c
>> > +++ b/drivers/hid/hid-quirks.c
>> > @@ -84,6 +84,11 @@ static const struct hid_device_id hid_quirks[] = {
>> > { HID_USB_DEVICE(USB_VENDOR_ID_FREESCALE, USB_DEVICE_ID_FREESCALE_MX28), HID_QUIRK_NOGET },
>> > { HID_USB_DEVICE(USB_VENDOR_ID_FUTABA, USB_DEVICE_ID_LED_DISPLAY), HID_QUIRK_NO_INIT_REPORTS },
>> > { HID_USB_DEVICE(USB_VENDOR_ID_GREENASIA, USB_DEVICE_ID_GREENASIA_DUAL_USB_JOYPAD), HID_QUIRK_MULTI_INPUT },
>> > +#if IS_ENABLED(CONFIG_HID_GOOGLE_HAMMER)
>> > + { HID_USB_DEVICE(USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_HAMMER), HID_QUIRK_NO_GENERIC },
>> > + { HID_USB_DEVICE(USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_STAFF), HID_QUIRK_NO_GENERIC },
>> > + { HID_USB_DEVICE(USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_WAND), HID_QUIRK_NO_GENERIC },
>> > +#endif
>> > { HID_USB_DEVICE(USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_DRIVING), HID_QUIRK_BADPAD | HID_QUIRK_MULTI_INPUT },
>> > { HID_USB_DEVICE(USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_FIGHTING), HID_QUIRK_BADPAD | HID_QUIRK_MULTI_INPUT },
>> > { HID_USB_DEVICE(USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_FLYING), HID_QUIRK_BADPAD | HID_QUIRK_MULTI_INPUT },
>> > diff --git a/include/linux/hid.h b/include/linux/hid.h
>> > index dfea5a656a1a..f2655265f8b5 100644
>> > --- a/include/linux/hid.h
>> > +++ b/include/linux/hid.h
>> > @@ -340,6 +340,7 @@ struct hid_item {
>> > #define HID_QUIRK_NO_EMPTY_INPUT 0x00000100
>> > /* 0x00000200 reserved for backward compatibility, was NO_INIT_INPUT_REPORTS */
>> > #define HID_QUIRK_ALWAYS_POLL 0x00000400
>> > +#define HID_QUIRK_NO_GENERIC 0x00000800
>> > #define HID_QUIRK_SKIP_OUTPUT_REPORTS 0x00010000
>> > #define HID_QUIRK_SKIP_OUTPUT_REPORT_ID 0x00020000
>> > #define HID_QUIRK_NO_OUTPUT_REPORTS_ON_INTR_EP 0x00040000
>> > @@ -359,6 +360,7 @@ struct hid_item {
>> > #define HID_GROUP_MULTITOUCH 0x0002
>> > #define HID_GROUP_SENSOR_HUB 0x0003
>> > #define HID_GROUP_MULTITOUCH_WIN_8 0x0004
>> > +#define HID_GROUP_GENERIC_OVERRIDE 0x0005
>> >
>> > /*
>> > * Vendor specific HID device groups
>> > --
>> > 2.16.2.804.g6dcf76e118-goog
>> >
<div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 15,
2018 at 2:05 AM, Dmitry Torokhov <span dir="ltr"><<a
href="mailto:dtor@chromium.org"
target="_blank">dtor@chromium.org</a>></span> wrote:<br><blockquote
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed,
Mar 14, 2018 at 9:16 AM, Benjamin Tissoires<br>
<<a href="mailto:benjamin.tissoires@redhat.com">benjamin.tissoires@redhat.com</a><wbr>>
wrote:<br>
><br>
> Hi Nicolas,<br>
><br>
> On Wed, Mar 14, 2018 at 6:22 AM, Nicolas Boichat <<a
href="mailto:drinkcat@chromium.org">drinkcat@chromium.org</a>>
wrote:<br>
> > From: Wei-Ning Huang <<a
href="mailto:wnhuang@chromium.org">wnhuang@chromium.org</a>><br>
> ><br>
> > Add Google hammer HID driver. This driver allow us to
control hammer<br>
> > keyboard backlight and support future features.<br>
> ><br>
> > We add a new HID quirk, that allows us to have the keyboard
interface<br>
> > to bind to google-hammer driver, while the touchpad interface can<br>
> > bind to the multitouch driver.<br>
> ><br>
> > Signed-off-by: Wei-Ning Huang <<a
href="mailto:wnhuang@google.com">wnhuang@google.com</a>><br>
> > Signed-off-by: Nicolas Boichat <<a
href="mailto:drinkcat@chromium.org">drinkcat@chromium.org</a>><br>
> > ---<br>
> ><br>
> > Changes since v3:<br>
> > - Rebase on latest linux-next/master, which moved the
quirk list from<br>
> > hid-core.c to hid-quirks.c. Also, completely
rework the logic to make<br>
> > it possible to bind google-hammer driver to
keyboard interface, and<br>
> > generic multitouch driver to touchpad
interface, as it is much simpler<br>
> > to do now that quirks are read early in
hid_add_device.<br>
><br>
> Ouch, this logic seems too convoluted for me.<br>
><br>
> Just to be sure:<br>
> - some of your devices export 2 USB interfaces on the same device (so<br>
> same VID/PID)<br>
> - one of this interface should be handled by hid-multitouch<br>
> - the other should be handled by hid-google-hammer<br>
> - the purpose of the new quirk and HID class are to allow<br>
> hid-google-hammer to only bind on the non multitouch interface<br>
><br>
> Am I correct?<br>
><br>
> If I am, given that we now don't need to blacklist the drivers for<br>
> hid-generic since e04a0442d33b8cf183bba38646447b<wbr>891bb02123,
I do not<br>
> understand why simply declaring "{ HID_DEVICE(BUS_USB,<br>
> HID_GROUP_GENERIC, USB_VENDOR_ID_GOOGLE,
USB_DEVICE_ID_GOOGLE_HAMMER)<br>
> }," (same for the 2 others) is not enough to have hid-google-hammer<br>
> binding only on the non-multitouch interface.<br>
><br>
> Could you please give a shot at it?<br>
><br>
<br>
</div></div>Ah, cool, if we now forcibly try to rebind devices from
generic HID to<br>
specialized driver when it appears, then we indeed to not have to do<br>
this dance with "overrides".<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> > - Add dynamic backlight detection support (only such
devices have an<br>
> > output HID descriptor).<br>
> > - Add support for wand (one more USB product ID).<br>
> > - Add SPDX-License-Identifier, fix one minor
formatting issue.<br>
> ><br>
> > drivers/hid/Kconfig
| 6 ++<br>
> > drivers/hid/Makefile
| 1 +<br>
> > drivers/hid/hid-core.c
| 4 ++<br>
> > drivers/hid/hid-google-hammer.<wbr>c | 116
++++++++++++++++++++++++++++++<wbr>++<br>
> > drivers/hid/hid-ids.h
| 3 +<br>
> > drivers/hid/hid-quirks.c
| 5 ++<br>
> > include/linux/hid.h
| 2 +<br>
> > 7 files changed, 137 insertions(+)<br>
> > create mode 100644 drivers/hid/hid-google-hammer.<wbr>c<br>
> ><br>
> > diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig<br>
> > index 1fce4c94e5ac..60252fd796f6 100644<br>
> > --- a/drivers/hid/Kconfig<br>
> > +++ b/drivers/hid/Kconfig<br>
> > @@ -339,6 +339,12 @@ config HOLTEK_FF<br>
> > Say Y here if you
have a Holtek On Line Grip based game controller<br>
> > and want to have
force feedback support for it.<br>
> ><br>
> > +config HID_GOOGLE_HAMMER<br>
> > + tristate "Google Hammer Keyboard"<br>
> > + depends on USB_HID &&
LEDS_CLASS<br>
> > + ---help---<br>
> > + Say Y here if you have a Google
Hammer device.<br>
> > +<br>
> > config HID_GT683R<br>
> > tristate "MSI GT68xR LED support"<br>
> > depends on LEDS_CLASS
&& USB_HID<br>
> > diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile<br>
> > index 713601c7bfa6..17a8bd97da9d 100644<br>
> > --- a/drivers/hid/Makefile<br>
> > +++ b/drivers/hid/Makefile<br>
> > @@ -45,6 +45,7 @@ obj-$(CONFIG_HID_ELO)
+= hid-elo.o<br>
> > obj-$(CONFIG_HID_EZKEY)
+= hid-ezkey.o<br>
> > obj-$(CONFIG_HID_GEMBIRD) +=
hid-gembird.o<br>
> > obj-$(CONFIG_HID_GFRM)
+= hid-gfrm.o<br>
> > +obj-$(CONFIG_HID_GOOGLE_<wbr>HAMMER)
+= hid-google-hammer.o<br>
> > obj-$(CONFIG_HID_GT683R) +=
hid-gt683r.o<br>
> > obj-$(CONFIG_HID_GYRATION) +=
hid-gyration.o<br>
> > obj-$(CONFIG_HID_HOLTEK) +=
hid-holtek-kbd.o<br>
> > diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c<br>
> > index 36af26c2565b..61c7d135d680 100644<br>
> > --- a/drivers/hid/hid-core.c<br>
> > +++ b/drivers/hid/hid-core.c<br>
> > @@ -2116,6 +2116,10 @@ int hid_add_device(struct hid_device *hdev)<br>
> >
ret = hid_scan_report(hdev);<br>
> >
if (ret)<br>
> >
hid_warn(hdev, "bad device
descriptor (%d)\n", ret);<br>
> > +<br>
> > + if
(hdev->quirks & HID_QUIRK_NO_GENERIC &&<br>
> > +
hdev->group
== HID_GROUP_GENERIC)<br>
> > +
hdev->group =
HID_GROUP_GENERIC_OVERRIDE;<br>
> > }<br>
> ><br>
> > /* XXX hack, any other
cleaner solution after the driver core<br>
> > diff --git a/drivers/hid/hid-google-<wbr>hammer.c
b/drivers/hid/hid-google-<wbr>hammer.c<br>
> > new file mode 100644<br>
> > index 000000000000..e7ad042a8464<br>
> > --- /dev/null<br>
> > +++ b/drivers/hid/hid-google-<wbr>hammer.c<br>
> > @@ -0,0 +1,116 @@<br>
> > +// SPDX-License-Identifier: GPL-2.0+<br>
> > +/*<br>
> > + * HID driver for Google Hammer device.<br>
> > + *<br>
> > + * Copyright (c) 2017 Google Inc.<br>
> > + * Author: Wei-Ning Huang <<a
href="mailto:wnhuang@google.com">wnhuang@google.com</a>><br>
> > + */<br>
> > +<br>
> > +/*<br>
> > + * This program is free software; you can redistribute it
and/or modify it<br>
> > + * under the terms of the GNU General Public License as
published by the Free<br>
> > + * Software Foundation; either version 2 of the License, or
(at your option)<br>
> > + * any later version.<br>
> > + */<br>
> > +<br>
> > +#include <linux/hid.h><br>
> > +#include <linux/leds.h><br>
> > +#include <linux/module.h><br>
> > +#include <linux/usb.h><br>
><br>
> Generally that's a no from me to include usb.h. I'd rather have you<br>
> decide on which interface to create the LEDs based on the report<br>
> descriptors, so we can replay the device with uhid without crashing<br>
> the kernel.<br>
><br>
> > +<br>
> > +#include "hid-ids.h"<br>
> > +<br>
> > +#define MAX_BRIGHTNESS 100<br>
> > +<br>
> > +struct hammer_kbd_leds {<br>
> > + struct led_classdev cdev;<br>
> > + struct hid_device *hdev;<br>
> > + u8 buf[2] ____cacheline_aligned;<br>
> > +};<br>
> > +<br>
> > +static int hammer_kbd_brightness_set_<wbr>blocking(struct
led_classdev *cdev,<br>
> > + enum
led_brightness br)<br>
> > +{<br>
> > + struct hammer_kbd_leds *led =
container_of(cdev,<br>
> > +
struct
hammer_kbd_leds,<br>
> > +
cdev);<br>
> > + int ret;<br>
> > +<br>
> > + led->buf[0] = 0;<br>
> > + led->buf[1] = br;<br>
> > +<br>
> > + ret =
hid_hw_output_report(led-><wbr>hdev, led->buf,
sizeof(led->buf));<br>
> > + if (ret == -ENOSYS)<br>
> > + ret
= hid_hw_raw_request(led->hdev, 0, led->buf,<br>
> > +
sizeof(led->buf),<br>
> > +
HID_OUTPUT_REPORT,<br>
> > +
HID_REQ_SET_REPORT);<br>
> > + if (ret < 0)<br>
> > +
hid_err(led->hdev, "failed to set keyboard backlight:
%d\n",<br>
> > +
ret);<br>
> > + return ret;<br>
> > +}<br>
> > +<br>
> > +static int hammer_register_leds(struct hid_device *hdev)<br>
> > +{<br>
> > + struct hammer_kbd_leds *kbd_backlight;<br>
> > +<br>
> > + kbd_backlight =
devm_kzalloc(&hdev->dev,<br>
> > +
sizeof(*kbd_backlight),<br>
> > +
GFP_KERNEL);<br>
> > + if (!kbd_backlight)<br>
> > +
return -ENOMEM;<br>
> > +<br>
> > + kbd_backlight->hdev = hdev;<br>
> > + kbd_backlight-><a
href="http://cdev.name"
data-saferedirecturl="https://www.google.com/url?hl=en&q=http://cdev.name&source=gmail&ust=1521158409163000&usg=AFQjCNEh3tKanACY7TMM3ATXduCC0nKCtQ"
rel="noreferrer" target="_blank">cdev.name</a> =
"hammer::kbd_backlight";<br>
> > +
kbd_backlight->cdev.max_<wbr>brightness = MAX_BRIGHTNESS;<br>
> > +
kbd_backlight->cdev.<wbr>brightness_set_blocking =<br>
> > +
hammer_kbd_brightness_set_<wbr>blocking;<br>
> > + kbd_backlight->cdev.flags =
LED_HW_PLUGGABLE;<br>
> > +<br>
> > + /* Set backlight to 0% initially. */<br>
> > +
hammer_kbd_brightness_set_<wbr>blocking(&kbd_backlight->cdev,
0);<br>
> > +<br>
> > + return
devm_led_classdev_register(&<wbr>hdev->dev,
&kbd_backlight->cdev);<br>
> > +}<br>
> > +<br>
> > +static int hammer_input_configured(struct hid_device *hdev,<br>
> > +
struct
hid_input *hi)<br>
> > +{<br>
> > + struct usb_interface *intf =
to_usb_interface(hdev->dev.<wbr>parent);<br>
> > +<br>
> > + struct list_head *report_list =<br>
> > +
&hdev->report_enum[HID_OUTPUT_<wbr>REPORT].report_list;<br>
> > +<br>
> > + if
(intf->cur_altsetting->desc.<wbr>bInterfaceProtocol ==<br>
> > +
USB_INTERFACE_PROTOCOL_<wbr>KEYBOARD &&
!list_empty(report_list)) {<br>
><br>
> See above. I am pretty sure you can find something in the report<br>
> descriptor to discriminate the LED capable device from the others.<br>
><br>
> Cheers,<br>
> Benjamin<br>
><br>
> > + int
err = hammer_register_leds(hdev);<br>
> > +<br>
> > + if (err)<br>
> > +
hid_warn(hdev,<br>
> > +
"Failed to
register keyboard backlight: %d\n",<br>
> > +
err);<br>
> > + }<br>
> > +<br>
> > + return 0;<br>
> > +}<br>
> > +<br>
> > +static const struct hid_device_id hammer_devices[] = {<br>
> > + { HID_DEVICE(BUS_USB,
HID_GROUP_GENERIC_OVERRIDE,<br>
> > +
USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_HAMMER)
},<br>
> > + { HID_DEVICE(BUS_USB,
HID_GROUP_GENERIC_OVERRIDE,<br>
> > +
USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_STAFF) },<br>
> > + { HID_DEVICE(BUS_USB,
HID_GROUP_GENERIC_OVERRIDE,<br>
> > +
USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_WAND) },<br>
> > + { }<br>
> > +};<br>
> > +MODULE_DEVICE_TABLE(hid, hammer_devices);<br>
> > +<br>
> > +static struct hid_driver hammer_driver = {<br>
> > + .name = "hammer",<br>
> > + .id_table = hammer_devices,<br>
> > + .input_configured =
hammer_input_configured,<br>
> > +};<br>
> > +module_hid_driver(hammer_<wbr>driver);<br>
> > +<br>
> > +MODULE_LICENSE("GPL");<br>
> > diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h<br>
> > index 41f227a841fb..5a3a7ead3012 100644<br>
> > --- a/drivers/hid/hid-ids.h<br>
> > +++ b/drivers/hid/hid-ids.h<br>
> > @@ -448,7 +448,10 @@<br>
> > #define USB_DEVICE_ID_GOODTOUCH_000f 0x000f<br>
> ><br>
> > #define USB_VENDOR_ID_GOOGLE
0x18d1<br>
> > +#define USB_DEVICE_ID_GOOGLE_HAMMER 0x5022<br>
> > #define USB_DEVICE_ID_GOOGLE_TOUCH_<wbr>ROSE
0x5028<br>
> > +#define USB_DEVICE_ID_GOOGLE_STAFF 0x502b<br>
> > +#define USB_DEVICE_ID_GOOGLE_WAND 0x502d<br>
> ><br>
> > #define USB_VENDOR_ID_GOTOP
0x08f2<br>
> > #define USB_DEVICE_ID_SUPER_Q2
0x007f<br>
> > diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c<br>
> > index 587e2681a53f..d112a14da200 100644<br>
> > --- a/drivers/hid/hid-quirks.c<br>
> > +++ b/drivers/hid/hid-quirks.c<br>
> > @@ -84,6 +84,11 @@ static const struct hid_device_id
hid_quirks[] = {<br>
> > {
HID_USB_DEVICE(USB_VENDOR_ID_<wbr>FREESCALE,
USB_DEVICE_ID_FREESCALE_MX28), HID_QUIRK_NOGET },<br>
> > {
HID_USB_DEVICE(USB_VENDOR_ID_<wbr>FUTABA, USB_DEVICE_ID_LED_DISPLAY),
HID_QUIRK_NO_INIT_REPORTS },<br>
> > {
HID_USB_DEVICE(USB_VENDOR_ID_<wbr>GREENASIA,
USB_DEVICE_ID_GREENASIA_DUAL_<wbr>USB_JOYPAD), HID_QUIRK_MULTI_INPUT
},<br>
> > +#if IS_ENABLED(CONFIG_HID_GOOGLE_<wbr>HAMMER)<br>
> > + {
HID_USB_DEVICE(USB_VENDOR_ID_<wbr>GOOGLE,
USB_DEVICE_ID_GOOGLE_HAMMER), HID_QUIRK_NO_GENERIC },<br>
> > + {
HID_USB_DEVICE(USB_VENDOR_ID_<wbr>GOOGLE, USB_DEVICE_ID_GOOGLE_STAFF),
HID_QUIRK_NO_GENERIC },<br>
> > + {
HID_USB_DEVICE(USB_VENDOR_ID_<wbr>GOOGLE, USB_DEVICE_ID_GOOGLE_WAND),
HID_QUIRK_NO_GENERIC },<br>
> > +#endif<br>
> > {
HID_USB_DEVICE(USB_VENDOR_ID_<wbr>HAPP, USB_DEVICE_ID_UGCI_DRIVING),
HID_QUIRK_BADPAD | HID_QUIRK_MULTI_INPUT },<br>
> > {
HID_USB_DEVICE(USB_VENDOR_ID_<wbr>HAPP, USB_DEVICE_ID_UGCI_FIGHTING),
HID_QUIRK_BADPAD | HID_QUIRK_MULTI_INPUT },<br>
> > {
HID_USB_DEVICE(USB_VENDOR_ID_<wbr>HAPP, USB_DEVICE_ID_UGCI_FLYING),
HID_QUIRK_BADPAD | HID_QUIRK_MULTI_INPUT },<br>
> > diff --git a/include/linux/hid.h b/include/linux/hid.h<br>
> > index dfea5a656a1a..f2655265f8b5 100644<br>
> > --- a/include/linux/hid.h<br>
> > +++ b/include/linux/hid.h<br>
> > @@ -340,6 +340,7 @@ struct hid_item {<br>
> > #define HID_QUIRK_NO_EMPTY_INPUT
0x00000100<br>
> > /* 0x00000200 reserved for backward compatibility, was
NO_INIT_INPUT_REPORTS */<br>
> > #define HID_QUIRK_ALWAYS_POLL
0x00000400<br>
> > +#define HID_QUIRK_NO_GENERIC
0x00000800<br>
> > #define HID_QUIRK_SKIP_OUTPUT_REPORTS
0x00010000<br>
> > #define HID_QUIRK_SKIP_OUTPUT_REPORT_<wbr>ID
0x00020000<br>
> > #define HID_QUIRK_NO_OUTPUT_REPORTS_<wbr>ON_INTR_EP
0x00040000<br>
> > @@ -359,6 +360,7 @@ struct hid_item {<br>
> > #define HID_GROUP_MULTITOUCH
0x0002<br>
> > #define HID_GROUP_SENSOR_HUB
0x0003<br>
> > #define HID_GROUP_MULTITOUCH_WIN_8
0x0004<br>
> > +#define HID_GROUP_GENERIC_OVERRIDE
0x0005<br>
> ><br>
> > /*<br>
> > * Vendor specific HID device groups<br>
> > --<br>
> > 2.16.2.804.g6dcf76e118-goog<br>
> ><br>
</div></div></blockquote></div><br></div>
^ permalink raw reply
* [PATCH] HID: google: add google hammer HID driver
From: Nicolas Boichat @ 2018-03-15 1:28 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Benjamin Tissoires, linux-kernel, linux-input, groeck, dtor
From: Wei-Ning Huang <wnhuang@chromium.org>
Add Google hammer HID driver. This driver allow us to control hammer
keyboard backlight and support future features.
Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
---
Changes since v4:
- HID quirk is actually not necessary, as recent kernel always prefers
binding specialized drivers over hid-generic.
- Rework backlight detection, relying only on HID report descriptor. We
also make the test a little more specific, to make sure the output
descriptor is actually a backlight control.
Changes since v3:
- Rebase on latest linux-next/master, which moved the quirk list from
hid-core.c to hid-quirks.c. Also, completely rework the logic to make
it possible to bind google-hammer driver to keyboard interface, and
generic multitouch driver to touchpad interface, as it is much simpler
to do now that quirks are read early in hid_add_device.
- Add dynamic backlight detection support (only such devices have an
output HID descriptor).
- Add support for wand (one more USB product ID).
- Add SPDX-License-Identifier, fix one minor formatting issue.
drivers/hid/Kconfig | 6 ++
drivers/hid/Makefile | 1 +
drivers/hid/hid-google-hammer.c | 124 ++++++++++++++++++++++++++++++++
drivers/hid/hid-ids.h | 3 +
4 files changed, 134 insertions(+)
create mode 100644 drivers/hid/hid-google-hammer.c
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 1fce4c94e5ac..60252fd796f6 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -339,6 +339,12 @@ config HOLTEK_FF
Say Y here if you have a Holtek On Line Grip based game controller
and want to have force feedback support for it.
+config HID_GOOGLE_HAMMER
+ tristate "Google Hammer Keyboard"
+ depends on USB_HID && LEDS_CLASS
+ ---help---
+ Say Y here if you have a Google Hammer device.
+
config HID_GT683R
tristate "MSI GT68xR LED support"
depends on LEDS_CLASS && USB_HID
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index 713601c7bfa6..17a8bd97da9d 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_HID_ELO) += hid-elo.o
obj-$(CONFIG_HID_EZKEY) += hid-ezkey.o
obj-$(CONFIG_HID_GEMBIRD) += hid-gembird.o
obj-$(CONFIG_HID_GFRM) += hid-gfrm.o
+obj-$(CONFIG_HID_GOOGLE_HAMMER) += hid-google-hammer.o
obj-$(CONFIG_HID_GT683R) += hid-gt683r.o
obj-$(CONFIG_HID_GYRATION) += hid-gyration.o
obj-$(CONFIG_HID_HOLTEK) += hid-holtek-kbd.o
diff --git a/drivers/hid/hid-google-hammer.c b/drivers/hid/hid-google-hammer.c
new file mode 100644
index 000000000000..6486469ce0f6
--- /dev/null
+++ b/drivers/hid/hid-google-hammer.c
@@ -0,0 +1,124 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * HID driver for Google Hammer device.
+ *
+ * Copyright (c) 2017 Google Inc.
+ * Author: Wei-Ning Huang <wnhuang@google.com>
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+#include <linux/hid.h>
+#include <linux/leds.h>
+#include <linux/module.h>
+
+#include "hid-ids.h"
+
+#define MAX_BRIGHTNESS 100
+
+/* HID usage for keyboard backlight (Alphanumeric display brightness) */
+#define HID_AD_BRIGHTNESS 0x00140046
+
+struct hammer_kbd_leds {
+ struct led_classdev cdev;
+ struct hid_device *hdev;
+ u8 buf[2] ____cacheline_aligned;
+};
+
+static int hammer_kbd_brightness_set_blocking(struct led_classdev *cdev,
+ enum led_brightness br)
+{
+ struct hammer_kbd_leds *led = container_of(cdev,
+ struct hammer_kbd_leds,
+ cdev);
+ int ret;
+
+ led->buf[0] = 0;
+ led->buf[1] = br;
+
+ ret = hid_hw_output_report(led->hdev, led->buf, sizeof(led->buf));
+ if (ret == -ENOSYS)
+ ret = hid_hw_raw_request(led->hdev, 0, led->buf,
+ sizeof(led->buf),
+ HID_OUTPUT_REPORT,
+ HID_REQ_SET_REPORT);
+ if (ret < 0)
+ hid_err(led->hdev, "failed to set keyboard backlight: %d\n",
+ ret);
+ return ret;
+}
+
+static int hammer_register_leds(struct hid_device *hdev)
+{
+ struct hammer_kbd_leds *kbd_backlight;
+
+ kbd_backlight = devm_kzalloc(&hdev->dev,
+ sizeof(*kbd_backlight),
+ GFP_KERNEL);
+ if (!kbd_backlight)
+ return -ENOMEM;
+
+ kbd_backlight->hdev = hdev;
+ kbd_backlight->cdev.name = "hammer::kbd_backlight";
+ kbd_backlight->cdev.max_brightness = MAX_BRIGHTNESS;
+ kbd_backlight->cdev.brightness_set_blocking =
+ hammer_kbd_brightness_set_blocking;
+ kbd_backlight->cdev.flags = LED_HW_PLUGGABLE;
+
+ /* Set backlight to 0% initially. */
+ hammer_kbd_brightness_set_blocking(&kbd_backlight->cdev, 0);
+
+ return devm_led_classdev_register(&hdev->dev, &kbd_backlight->cdev);
+}
+
+static int hammer_input_configured(struct hid_device *hdev,
+ struct hid_input *hi)
+{
+ struct list_head *report_list =
+ &hdev->report_enum[HID_OUTPUT_REPORT].report_list;
+ struct hid_report *report;
+
+ if (list_empty(report_list))
+ return 0;
+
+ report = list_first_entry(report_list, struct hid_report, list);
+
+ if (report->maxfield == 1 &&
+ report->field[0]->application == HID_GD_KEYBOARD &&
+ report->field[0]->maxusage == 1 &&
+ report->field[0]->usage[0].hid == HID_AD_BRIGHTNESS) {
+ int err = hammer_register_leds(hdev);
+
+ if (err)
+ hid_warn(hdev,
+ "Failed to register keyboard backlight: %d\n",
+ err);
+ }
+
+ return 0;
+}
+
+static const struct hid_device_id hammer_devices[] = {
+ { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC,
+ USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_HAMMER) },
+ { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC,
+ USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_STAFF) },
+ { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC,
+ USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_WAND) },
+ { }
+};
+MODULE_DEVICE_TABLE(hid, hammer_devices);
+
+static struct hid_driver hammer_driver = {
+ .name = "hammer",
+ .id_table = hammer_devices,
+ .input_configured = hammer_input_configured,
+};
+module_hid_driver(hammer_driver);
+
+MODULE_LICENSE("GPL");
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 41f227a841fb..5a3a7ead3012 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -448,7 +448,10 @@
#define USB_DEVICE_ID_GOODTOUCH_000f 0x000f
#define USB_VENDOR_ID_GOOGLE 0x18d1
+#define USB_DEVICE_ID_GOOGLE_HAMMER 0x5022
#define USB_DEVICE_ID_GOOGLE_TOUCH_ROSE 0x5028
+#define USB_DEVICE_ID_GOOGLE_STAFF 0x502b
+#define USB_DEVICE_ID_GOOGLE_WAND 0x502d
#define USB_VENDOR_ID_GOTOP 0x08f2
#define USB_DEVICE_ID_SUPER_Q2 0x007f
--
2.16.2.804.g6dcf76e118-goog
^ permalink raw reply related
* Re: [PATCH 00/47] arch-removal: device drivers
From: Boris Brezillon @ 2018-03-15 5:32 UTC (permalink / raw)
To: Arnd Bergmann
Cc: ulf.hansson, linux-usb, wsa, linux-iio, viresh.kumar,
linus.walleij, alexandre.belloni, linux-ide, netdev, linux-mtd,
linux-i2c, linux-rtc, lars, herbert, corbet, linux-doc, stern,
linux-serial, jslaby, linux-mmc, shli, wg, linux-crypto,
linux-pwm, linux-watchdog, alsa-devel, b.zolnierkie, linux-input,
linux-can, linux-raid, linux-gpio, broonie, bp, linux-fbdev,
mchehab
In-Reply-To: <20180314153603.3127932-1-arnd@arndb.de>
Hi Arnd,
On Wed, 14 Mar 2018 16:35:13 +0100
Arnd Bergmann <arnd@arndb.de> wrote:
> Hi driver maintainers,
>
> I just posted one series with the removal of eight architectures,
> see https://lkml.org/lkml/2018/3/14/505 for details, or
> https://lwn.net/Articles/748074/ for more background.
>
> These are the device drivers that go along with them. I have already
> picked up the drivers for arch/metag/ into my tree, they were reviewed
> earlier.
>
> Please let me know if you have any concerns with the patch, or if you
> prefer to pick up the patches in your respective trees. I created
> the patches with 'git format-patch -D', so they will not apply without
> manually removing those files.
>
> For anything else, I'd keep the removal patches in my asm-generic tree
> and will send a pull request for 4.17 along with the actual arch removal.
>
> Arnd
>
> Arnd Bergmann
> edac: remove tile driver
> net: tile: remove ethernet drivers
> net: adi: remove blackfin ethernet drivers
> net: 8390: remove m32r specific bits
> net: remove cris etrax ethernet driver
> net: smsc: remove m32r specific smc91x configuration
> raid: remove tile specific raid6 implementation
> rtc: remove tile driver
> rtc: remove bfin driver
> char: remove obsolete ds1302 rtc driver
> char: remove tile-srom.c
> char: remove blackfin OTP driver
> pcmcia: remove m32r drivers
> pcmcia: remove blackfin driver
> ASoC: remove blackfin drivers
> video/logo: remove obsolete logo files
> fbdev: remove blackfin drivers
> fbdev: s1d13xxxfb: remove m32r specific hacks
> crypto: remove blackfin CRC driver
> media: platform: remove blackfin capture driver
> media: platform: remove m32r specific arv driver
> cpufreq: remove blackfin driver
> cpufreq: remove cris specific drivers
> gpio: remove etraxfs driver
> pinctrl: remove adi2/blackfin drivers
> ata: remove bf54x driver
> input: keyboard: remove bf54x driver
> input: misc: remove blackfin rotary driver
> mmc: remove bfin_sdh driver
> can: remove bfin_can driver
> watchdog: remove bfin_wdt driver
> mtd: maps: remove bfin-async-flash driver
> mtd: nand: remove bf5xx_nand driver
If you don't mind, I'd like to take the mtd patches through the MTD
tree. As you've probably noticed, nand code has been moved around and
it's easier for me to carry those 2 simple changes in my tree than
creating an immutable branch.
Let me know if this is a problem.
Regards,
Boris
--
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH V2] Input: pm8941-pwrkey: add resin key capabilities
From: Tirupathi Reddy T @ 2018-03-15 8:10 UTC (permalink / raw)
To: Dmitry Torokhov, Bjorn Andersson
Cc: robh+dt, mark.rutland, linux-input, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20180314164346.GA74407@dtor-ws>
Hi,
On 3/14/2018 10:13 PM, Dmitry Torokhov wrote:
> On Tue, Mar 13, 2018 at 07:40:48PM -0700, Bjorn Andersson wrote:
>> On Tue 13 Mar 01:35 PDT 2018, Tirupathi Reddy wrote:
>>
>>> Add resin key support to handle different types of key events
>>> defined in different platforms.
>>>
>>> Signed-off-by: Tirupathi Reddy <tirupath@codeaurora.org>
>>> ---
>>> .../bindings/input/qcom,pm8941-pwrkey.txt | 20 ++++++-
>>> drivers/input/misc/pm8941-pwrkey.c | 65 +++++++++++++++++++++-
>>> 2 files changed, 83 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
>>> index 07bf55f..f499cf8 100644
>>> --- a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
>>> +++ b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
>>> @@ -20,6 +20,14 @@ PROPERTIES
>>> defined by the binding document describing the node's
>>> interrupt parent.
>>>
>>> +- interrupt-names:
>>> + Usage: required
>>> + Value type: <stringlist>
>>> + Definition: Interrupt names. This list must match up 1-to-1 with the
>>> + interrupts specified in the 'interrupts' property. "kpdpwr"
>>> + must be specified and should be the first entry of the list.
>>> + "resin" may be specified for some platforms.
>>> +
>>> - debounce:
>>> Usage: optional
>>> Value type: <u32>
>>> @@ -32,12 +40,22 @@ PROPERTIES
>>> Definition: presence of this property indicates that the KPDPWR_N pin
>>> should be configured for pull up.
>>>
>>> +- linux,code:
>>> + Usage: required for "resin" key
>>> + Value type: <u32>
>>> + Definition: The input key-code associated with the resin key.
>>> + Use the linux event codes defined in
>>> + include/dt-bindings/input/linux-event-codes.h
>> For completeness sake I think this should list both the key code for the
>> power key and for the RESIN key.
Then it breaks existing DT nodes.
Since pwrkey functionality is fixed across platforms, "linux,code"
specification through device tree is not required for it.
>>> +
>>> EXAMPLE
>>>
>>> pwrkey@800 {
>>> compatible = "qcom,pm8941-pwrkey";
>>> reg = <0x800>;
>>> - interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>;
>>> + interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>,
>>> + <0x0 0x8 1 IRQ_TYPE_EDGE_BOTH>;
>>> + interrupt-names = "kpdpwr", "resin";
>>> debounce = <15625>;
>>> bias-pull-up;
>> Do we need to support defining the bias for the resin as well?
Good point, will add this support in Patch V3. Also, the debounce
configuration
in HW is common across power-key and resin.
>>
>> Perhaps it makes more sense to describe the RESIN key with a separate
>> compatible and define that in a node of its own (we can still implement
>> this in the same driver - if there's any chance of reuse...).
The PMIC peripheral/module called PON(Power on) generates these key events.
Pwrkey(KPDPWR_N) is the primary supported key by this module, the others are
optional. The resin may be supported a "defined" key. How about using
the below
logic for resin key without breaking the existing DTs as shown below:
pwrkey@800 {
compatible = "qcom,pm8941-pwrkey";
reg = <0x800>;
interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>;
debounce = <15625>;
bias-pull-up;
resin {
interrupts = <0x0 0x8 1 IRQ_TYPE_EDGE_BOTH>;
linux,code = <KEY_VOLUMEDOWN>;
bias-pull-up;
};
};
>>> + linux,code = <KEY_VOLUMEDOWN>;
>>> };
>>> diff --git a/drivers/input/misc/pm8941-pwrkey.c b/drivers/input/misc/pm8941-pwrkey.c
>>> index 18ad956..2fffc7c 100644
>>> --- a/drivers/input/misc/pm8941-pwrkey.c
>>> +++ b/drivers/input/misc/pm8941-pwrkey.c
>>> @@ -28,6 +28,7 @@
>>>
>>> #define PON_RT_STS 0x10
>>> #define PON_KPDPWR_N_SET BIT(0)
>>> +#define PON_RESIN_N_SET BIT(1)
>>>
>>> #define PON_PS_HOLD_RST_CTL 0x5a
>>> #define PON_PS_HOLD_RST_CTL2 0x5b
>>> @@ -46,6 +47,7 @@
>>> struct pm8941_pwrkey {
>>> struct device *dev;
>>> int irq;
>>> + u32 resin_key_code;
>>> u32 baseaddr;
>>> struct regmap *regmap;
>>> struct input_dev *input;
>>> @@ -130,6 +132,24 @@ static irqreturn_t pm8941_pwrkey_irq(int irq, void *_data)
>>> return IRQ_HANDLED;
>>> }
>>>
>>> +static irqreturn_t pm8941_resinkey_irq(int irq, void *_data)
>>> +{
>>> + struct pm8941_pwrkey *pwrkey = _data;
>>> + unsigned int sts;
>>> + int error;
>>> +
>>> + error = regmap_read(pwrkey->regmap,
>>> + pwrkey->baseaddr + PON_RT_STS, &sts);
>> This needs to be broken because the line is 81 chars long, if you use a
>> shorter name for the return value (e.g. "ret") you don't need to do
>> this.
> I prefer keeping it as "error" please.
Okay. I will keep it as "error".
>>> + if (error)
>>> + return IRQ_HANDLED;
>>> +
>>> + input_report_key(pwrkey->input, pwrkey->resin_key_code,
>>> + !!(sts & PON_RESIN_N_SET));
>> Put pwrkey->resin_key_code in a local variable named "key" (or even
>> key_code) and you don't need to line wrap this one.
Okay. I will address it in Patch V3.
>>> + input_sync(pwrkey->input);
>>> +
>>> + return IRQ_HANDLED;
>>> +}
>>> +
>> Regards,
>> Bjorn
^ permalink raw reply
* Re: [PATCH 00/47] arch-removal: device drivers
From: Arnd Bergmann @ 2018-03-15 9:09 UTC (permalink / raw)
To: Boris Brezillon
Cc: Ulf Hansson, linux-usb, Wolfram Sang, linux-iio, Viresh Kumar,
Linus Walleij, Alexandre Belloni, IDE-ML, Networking, linux-mtd,
linux-i2c, linux-rtc, Lars-Peter Clausen, Herbert Xu,
Jonathan Corbet, open list:DOCUMENTATION, Alan Stern,
linux-serial, Jiri Slaby, linux-mmc, Shaohua Li, wg,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE, linux-pwm
In-Reply-To: <20180315063238.3303b8d1@bbrezillon>
On Thu, Mar 15, 2018 at 6:32 AM, Boris Brezillon
<boris.brezillon@bootlin.com> wrote:
> Hi Arnd,
>
> On Wed, 14 Mar 2018 16:35:13 +0100
> Arnd Bergmann <arnd@arndb.de> wrote:
>
>> Hi driver maintainers,
>>
>> I just posted one series with the removal of eight architectures,
>> see https://lkml.org/lkml/2018/3/14/505 for details, or
>> https://lwn.net/Articles/748074/ for more background.
>>
>> These are the device drivers that go along with them. I have already
>> picked up the drivers for arch/metag/ into my tree, they were reviewed
>> earlier.
>>
>> Please let me know if you have any concerns with the patch, or if you
>> prefer to pick up the patches in your respective trees. I created
>> the patches with 'git format-patch -D', so they will not apply without
>> manually removing those files.
>>
>> For anything else, I'd keep the removal patches in my asm-generic tree
>> and will send a pull request for 4.17 along with the actual arch removal.
>>
>
> If you don't mind, I'd like to take the mtd patches through the MTD
> tree. As you've probably noticed, nand code has been moved around and
> it's easier for me to carry those 2 simple changes in my tree than
> creating an immutable branch.
>
> Let me know if this is a problem.
Sounds good, I've removed the two patches from my tree now.
I've already sent a version of those that is based on your latest tree to
you for inclusion.
Arnd
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH 00/16] remove eight obsolete architectures
From: David Howells @ 2018-03-15 9:42 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arch, linux-block, linux-fbdev, linux-watchdog, linux-doc,
netdev, linux-usb, linux-wireless, linux-kernel, linux-pwm,
linux-spi, dhowells, linux-ide, dri-devel, linux-input,
linux-fsdevel, linux-mm, linux-rtc
In-Reply-To: <20180314143529.1456168-1-arnd@arndb.de>
Do we have anything left that still implements NOMMU?
David
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 00/16] remove eight obsolete architectures
From: Geert Uytterhoeven @ 2018-03-15 9:48 UTC (permalink / raw)
To: David Howells
Cc: Linux-Arch, Linux PWM List, Linux Fbdev development list,
Linux Watchdog Mailing List, Arnd Bergmann, linux-doc, netdev,
USB list, linux-wireless, Linux Kernel Mailing List,
DRI Development, linux-spi, linux-block, linux-ide, linux-input,
Linux FS Devel, Linux MM, linux-rtc
In-Reply-To: <2929.1521106970@warthog.procyon.org.uk>
Hi David,
On Thu, Mar 15, 2018 at 10:42 AM, David Howells <dhowells@redhat.com> wrote:
> Do we have anything left that still implements NOMMU?
Sure: arm, c6x, m68k, microblaze, and sh.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 00/16] remove eight obsolete architectures
From: Arnd Bergmann @ 2018-03-15 9:56 UTC (permalink / raw)
To: David Howells
Cc: linux-arch, linux-pwm, linux-fbdev, linux-watchdog,
open list:DOCUMENTATION, Networking, linux-usb, linux-wireless,
Linux Kernel Mailing List, dri-devel, linux-spi, linux-block,
IDE-ML, open list:HID CORE LAYER, Linux FS-devel Mailing List,
Linux-MM, linux-rtc
In-Reply-To: <2929.1521106970@warthog.procyon.org.uk>
On Thu, Mar 15, 2018 at 10:42 AM, David Howells <dhowells@redhat.com> wrote:
> Do we have anything left that still implements NOMMU?
Yes, plenty. I was wondering the same thing, but it seems that the architectures
we remove are almost completely representative of what we support overall,
except that they are all not licensed to 3rd parties, unlike many of the ones we
keep.
I've made an overview of the remaining architectures for my own reference[1].
The remaining NOMMU architectures are:
- arch/arm has ARMv7-M (Cortex-M microcontroller), which is actually
gaining traction
- arch/sh has an open-source J2 core that was added not that long ago,
it seems to
be the only SH compatible core that anyone is working on.
- arch/microblaze supports both MMU/NOMMU modes (most use an MMU)
- arch/m68k supports several NOMMU targets, both the coldfire SoCs and the
classic processors
- c6x has no MMU
Arnd
[1] https://docs.google.com/spreadsheets/d/1QxMvW5jpVG2jb4RM9CQQl27-wVpNYOa-_3K2RVKifb0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 00/16] remove eight obsolete architectures
From: Hannes Reinecke @ 2018-03-15 9:59 UTC (permalink / raw)
To: David Howells, Arnd Bergmann
Cc: linux-arch-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-block-u79uwXL29TY76Z2rM5mHXA,
linux-ide-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-pwm-u79uwXL29TY76Z2rM5mHXA,
linux-rtc-u79uwXL29TY76Z2rM5mHXA,
linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg
In-Reply-To: <2929.1521106970-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
On 03/15/2018 10:42 AM, David Howells wrote:
> Do we have anything left that still implements NOMMU?
>
RISC-V ?
(evil grin :-)
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare-l3A5Bk7waGM@public.gmane.org +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH 00/16] remove eight obsolete architectures
From: Arnd Bergmann @ 2018-03-15 10:42 UTC (permalink / raw)
To: Hannes Reinecke
Cc: linux-arch, linux-block, linux-fbdev, linux-watchdog,
open list:DOCUMENTATION, Networking, linux-usb, linux-wireless,
Linux Kernel Mailing List, linux-pwm, linux-spi, David Howells,
IDE-ML, dri-devel, open list:HID CORE LAYER,
Linux FS-devel Mailing List, Linux-MM, linux-rtc
In-Reply-To: <6c9d075c-d7a8-72a5-9b2d-af1feaa06c6c@suse.de>
On Thu, Mar 15, 2018 at 10:59 AM, Hannes Reinecke <hare@suse.de> wrote:
> On 03/15/2018 10:42 AM, David Howells wrote:
>> Do we have anything left that still implements NOMMU?
>>
> RISC-V ?
> (evil grin :-)
Is anyone producing a chip that includes enough of the Privileged ISA spec
to have things like system calls, but not the MMU parts?
I thought at least initially the kernel only supports hardware that has a rather
complete feature set.
Arnd
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox