* [PATCH] i2c: Prevent runtime suspend of adapter when Host Notify is required
From: Jarkko Nikula @ 2019-04-30 14:23 UTC (permalink / raw)
To: linux-i2c
Cc: Wolfram Sang, Keijo Vaara, linux-input, Bjorn Helgaas,
Rafael J . Wysocki, Jarkko Nikula, stable
Multiple users have reported their Synaptics touchpad has stopped
working between v4.20.1 and v4.20.2 when using SMBus interface.
The culprit for this appeared to be commit c5eb1190074c ("PCI / PM: Allow
runtime PM without callback functions") that fixed the runtime PM for
i2c-i801 SMBus adapter. Those Synaptics touchpad are using i2c-i801
for SMBus communication and testing showed they are able to get back
working by preventing the runtime suspend of adapter.
Normally when i2c-i801 SMBus adapter transmits with the client it resumes
before operation and autosuspends after.
However, if client requires SMBus Host Notify protocol, what those
Synaptics touchpads do, then the host adapter must not go to runtime
suspend since then it cannot process incoming SMBus Host Notify commands
the client may send.
Fix this by keeping I2C/SMBus adapter active in case client requires
Host Notify.
Reported-by: Keijo Vaara <ferdasyn@rocketmail.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203297
Fixes: c5eb1190074c ("PCI / PM: Allow runtime PM without callback functions")
Cc: stable@vger.kernel.org # v4.20+
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
---
Keijo: could you test this does it fix the issue you reported? This is
practically the same diff I sent earlier what you probably haven't tested yet.
I wanted to send a commitable fix in case it works since I'll be out of
office in a few coming days.
---
drivers/i2c/i2c-core-base.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 38af18645133..8149c9e32b69 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -327,6 +327,8 @@ static int i2c_device_probe(struct device *dev)
if (client->flags & I2C_CLIENT_HOST_NOTIFY) {
dev_dbg(dev, "Using Host Notify IRQ\n");
+ /* Keep adapter active when Host Notify is required */
+ pm_runtime_get_sync(&client->adapter->dev);
irq = i2c_smbus_host_notify_to_irq(client);
} else if (dev->of_node) {
irq = of_irq_get_byname(dev->of_node, "irq");
@@ -431,6 +433,8 @@ static int i2c_device_remove(struct device *dev)
device_init_wakeup(&client->dev, false);
client->irq = client->init_irq;
+ if (client->flags & I2C_CLIENT_HOST_NOTIFY)
+ pm_runtime_put(&client->adapter->dev);
return status;
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH][next] HID: logitech-dj: fix spelling mistake "Unexpect" -> "Unexpected"
From: Jiri Kosina @ 2019-04-30 13:32 UTC (permalink / raw)
To: Colin King; +Cc: Benjamin Tissoires, linux-input, kernel-janitors, linux-kernel
In-Reply-To: <20190426131631.26692-1-colin.king@canonical.com>
On Fri, 26 Apr 2019, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> There is a spelling mistake in a hid_err error message, fix it.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied to for-5.2/logitech. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v10 00/11] mfd: add support for max77650 PMIC
From: Bartosz Golaszewski @ 2019-04-30 9:11 UTC (permalink / raw)
To: Lee Jones
Cc: Linux Kernel Mailing List, open list:GPIO SUBSYSTEM, devicetree,
Linux Input, Linux LED Subsystem, Jacek Anaszewski,
Dmitry Torokhov, Linus Walleij, Linux PM list, Rob Herring,
Bartosz Golaszewski, Greg Kroah-Hartman, Liam Girdwood,
Sebastian Reichel, Pavel Machek, Mark Rutland
In-Reply-To: <20190423090451.23711-1-brgl@bgdev.pl>
wt., 23 kwi 2019 o 11:04 Bartosz Golaszewski <brgl@bgdev.pl> napisał(a):
>
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> This series adds support for max77650 ultra low-power PMIC. It provides
> the core mfd driver and a set of five sub-drivers for the regulator,
> power supply, gpio, leds and input subsystems.
>
> Patches 1-4 add the DT binding documents. Patch 5 documents mfd_add_devices().
> Patches 6-10 add all drivers. Last patch adds a MAINTAINERS entry for this
> device.
>
> The regulator part is already upstream.
>
> v1 -> v2:
> =========
>
> General:
> - use C++ style comments for the SPDX license identifier and the
> copyright header
> - s/MODULE_LICENSE("GPL")/MODULE_LICENSE("GPL v2")/
> - lookup the virtual interrupt numbers in the MFD driver, setup
> resources for child devices and use platform_get_irq_byname()
> in sub-drivers
> - picked up review tags
> - use devm_request_any_context_irq() for interrupt requests
>
> LEDs:
> - changed the max77650_leds_ prefix to max77650_led_
> - drop the max77650_leds structure as the only field it held was the
> regmap pointer, move said pointer to struct max77650_led
> - change the driver name to "max77650-led"
> - drop the last return value check and return the result of
> regmap_write() directly
> - change the labeling scheme to one consistent with other LED drivers
>
> ONKEY:
> - drop the key reporting helper and call the input functions directly
> from interrupt handlers
> - rename the rv local variable to error
> - drop parent device asignment
>
> Regulator:
> - drop the unnecessary init_data lookup from the driver code
> - drop unnecessary include
>
> Charger:
> - disable the charger on driver remove
> - change the power supply type to POWER_SUPPLY_TYPE_USB
>
> GPIO:
> - drop interrupt support until we have correct implementation of hierarchical
> irqs in gpiolib
>
> v2 -> v3:
> =========
>
> General:
> - dropped regulator patches as they're already in Mark Brown's branch
>
> LED:
> - fix the compatible string in the DT binding example
> - use the max_brightness property
> - use a common prefix ("MAX77650_LED") for all defines in the driver
>
> MFD:
> - add the MODULE_DEVICE_TABLE()
> - add a sentinel to the of_device_id array
> - constify the pointers to irq names
> - use an enum instead of defines for interrupt indexes
>
> v3 -> v4:
> =========
>
> GPIO:
> - as discussed with Linus Walleij: the gpio-controller is now part of
> the core mfd module (we don't spawn a sub-node anymore), the binding
> document for GPIO has been dropped, the GPIO properties have been
> defined in the binding document for the mfd core, the interrupt
> functionality has been reintroduced with the irq directly passed from
> the mfd part
> - due to the above changes the Reviewed-by tag from Linus was dropped
>
> v4 -> v5:
> =========
>
> General:
> - add a patch documenting mfd_add_devices()
>
> MFD:
> - pass the regmap irq_chip irq domain to mfd over mfd_add_devices so that
> the hw interrupts from resources can be correctly mapped to virtual irqs
> - remove the enum listing cell indexes
> - extend Kconfig help
> - add a link to the programming manual
> - use REGMAP_IRQ_REG() for regmap interrupts (except for GPI which has
> is composed of two hw interrupts for rising and falling edge)
> - add error messages in probe
> - use PLATFORM_DEVID_NONE constant in devm_mfd_add_devices()
> - set irq_base to 0 in regmap_add_irq_chip() as other users to, it's only
> relevant if it's > 0
>
> Charger:
> - use non-maxim specific property names for minimum input voltage and current
> limit
> - code shrink by using the enable/disable charger helpers everywhere
> - use more descriptive names for constants
>
> Onkey:
> - use EV_SW event type for slide mode
>
> LED:
> - remove stray " from Kconfig help
>
> v5 -> v6:
> =========
>
> MFD:
> - remove stray spaces in the binding document
> - rename the example dt node
> - remove unnecessary interrupt-parent property from the bindings
>
> LED:
> - add a missing dependency on LEDS_CLASS to Kconfig
>
> Onkey:
> - use boolean for the slide button property
>
> Charger:
> - fix the property names in DT example
> - make constants even more readable
>
> v6 -> v7:
> =========
>
> Charger:
> - rename the current limit property to current-limit-microamp
>
> v7 -> v8:
> =========
>
> General:
> - collected acks from Lee
> - changed the documentation for mfd_add_devices() as suggested by Lee
> - rebased on top of v5.1-rc3
>
> v8 > v9:
> ========
>
> General:
> - collected new tags
> - rebased on top of v5.1-rc4
>
> MFD:
> - various improvements in error messages
> - coding style tweaks
>
> Charger:
> - named the two optional properties in a more descriptive way, so that
> we can make them generic for charger bindings if more potential users
> appear
>
> v9 -> v10:
> ==========
>
> General:
> - added the review tag from Sebastian
> - rebased on top of v5.1-rc6
>
> Charger:
> - fixed the example in the binding document
>
> Bartosz Golaszewski (11):
> dt-bindings: mfd: add DT bindings for max77650
> dt-bindings: power: supply: add DT bindings for max77650
> dt-bindings: leds: add DT bindings for max77650
> dt-bindings: input: add DT bindings for max77650
> mfd: core: document mfd_add_devices()
> mfd: max77650: new core mfd driver
> power: supply: max77650: add support for battery charger
> gpio: max77650: add GPIO support
> leds: max77650: add LEDs support
> input: max77650: add onkey support
> MAINTAINERS: add an entry for max77650 mfd driver
>
> .../bindings/input/max77650-onkey.txt | 26 ++
> .../bindings/leds/leds-max77650.txt | 57 +++
> .../devicetree/bindings/mfd/max77650.txt | 46 +++
> .../power/supply/max77650-charger.txt | 28 ++
> MAINTAINERS | 14 +
> drivers/gpio/Kconfig | 7 +
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-max77650.c | 190 +++++++++
> drivers/input/misc/Kconfig | 9 +
> drivers/input/misc/Makefile | 1 +
> drivers/input/misc/max77650-onkey.c | 121 ++++++
> drivers/leds/Kconfig | 6 +
> drivers/leds/Makefile | 1 +
> drivers/leds/leds-max77650.c | 147 +++++++
> drivers/mfd/Kconfig | 14 +
> drivers/mfd/Makefile | 1 +
> drivers/mfd/max77650.c | 232 +++++++++++
> drivers/mfd/mfd-core.c | 13 +
> drivers/power/supply/Kconfig | 7 +
> drivers/power/supply/Makefile | 1 +
> drivers/power/supply/max77650-charger.c | 368 ++++++++++++++++++
> include/linux/mfd/max77650.h | 59 +++
> 22 files changed, 1349 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/max77650-onkey.txt
> create mode 100644 Documentation/devicetree/bindings/leds/leds-max77650.txt
> create mode 100644 Documentation/devicetree/bindings/mfd/max77650.txt
> create mode 100644 Documentation/devicetree/bindings/power/supply/max77650-charger.txt
> create mode 100644 drivers/gpio/gpio-max77650.c
> create mode 100644 drivers/input/misc/max77650-onkey.c
> create mode 100644 drivers/leds/leds-max77650.c
> create mode 100644 drivers/mfd/max77650.c
> create mode 100644 drivers/power/supply/max77650-charger.c
> create mode 100644 include/linux/mfd/max77650.h
>
> --
> 2.21.0
>
Hi Lee,
just a gentle ping before I leave on vacation.
All the relevant Acks are there. Any chance of getting this in for
v5.2? Obviously this cannot cause any regressions so it shouldn't be
too late in the release cycle.
Thanks in advance,
Bartosz Golaszewski
^ permalink raw reply
* Re: [PATCH v5 2/3] Input: add a driver for GPIO controllable vibrators
From: Dmitry Torokhov @ 2019-04-30 7:14 UTC (permalink / raw)
To: Luca Weiss
Cc: Rob Herring, Mark Rutland, Mauro Carvalho Chehab,
Pascal PAILLET-LME, Coly Li, Lee Jones, Xiaotong Lu, Brian Masney,
Rob Herring, Baolin Wang, David Brown,
open list:ARM/QUALCOMM SUPPORT,
open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20190426194747.22256-2-luca@z3ntu.xyz>
On Fri, Apr 26, 2019 at 09:47:46PM +0200, Luca Weiss wrote:
> Provide a simple driver for GPIO controllable vibrators.
> It will be used by the Fairphone 2.
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Applied, thank you.
> ---
> drivers/input/misc/Kconfig | 12 ++
> drivers/input/misc/Makefile | 1 +
> drivers/input/misc/gpio-vibra.c | 209 ++++++++++++++++++++++++++++++++
> 3 files changed, 222 insertions(+)
> create mode 100644 drivers/input/misc/gpio-vibra.c
>
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index e15ed1bb8558..6dfe9e2fe5b1 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -290,6 +290,18 @@ config INPUT_GPIO_DECODER
> To compile this driver as a module, choose M here: the module
> will be called gpio_decoder.
>
> +config INPUT_GPIO_VIBRA
> + tristate "GPIO vibrator support"
> + depends on GPIOLIB || COMPILE_TEST
> + select INPUT_FF_MEMLESS
> + help
> + Say Y here to get support for GPIO based vibrator devices.
> +
> + If unsure, say N.
> +
> + To compile this driver as a module, choose M here: the module will be
> + called gpio-vibra.
> +
> config INPUT_IXP4XX_BEEPER
> tristate "IXP4XX Beeper support"
> depends on ARCH_IXP4XX
> diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
> index b936c5b1d4ac..f38ebbdb05e2 100644
> --- a/drivers/input/misc/Makefile
> +++ b/drivers/input/misc/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_INPUT_DRV2667_HAPTICS) += drv2667.o
> obj-$(CONFIG_INPUT_GP2A) += gp2ap002a00f.o
> obj-$(CONFIG_INPUT_GPIO_BEEPER) += gpio-beeper.o
> obj-$(CONFIG_INPUT_GPIO_DECODER) += gpio_decoder.o
> +obj-$(CONFIG_INPUT_GPIO_VIBRA) += gpio-vibra.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/gpio-vibra.c b/drivers/input/misc/gpio-vibra.c
> new file mode 100644
> index 000000000000..b76c81015de9
> --- /dev/null
> +++ b/drivers/input/misc/gpio-vibra.c
> @@ -0,0 +1,209 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * GPIO vibrator driver
> + *
> + * Copyright (C) 2019 Luca Weiss <luca@z3ntu.xyz>
> + *
> + * Based on PWM vibrator driver:
> + * Copyright (C) 2017 Collabora Ltd.
> + *
> + * Based on previous work from:
> + * Copyright (C) 2012 Dmitry Torokhov <dmitry.torokhov@gmail.com>
> + *
> + * Based on PWM beeper driver:
> + * Copyright (C) 2010, Lars-Peter Clausen <lars@metafoo.de>
> + */
> +
> +#include <linux/gpio/consumer.h>
> +#include <linux/input.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/property.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/slab.h>
> +
> +struct gpio_vibrator {
> + struct input_dev *input;
> + struct gpio_desc *gpio;
> + struct regulator *vcc;
> +
> + struct work_struct play_work;
> + bool running;
> + bool vcc_on;
> +};
> +
> +static int gpio_vibrator_start(struct gpio_vibrator *vibrator)
> +{
> + struct device *pdev = vibrator->input->dev.parent;
> + int err;
> +
> + if (!vibrator->vcc_on) {
> + err = regulator_enable(vibrator->vcc);
> + if (err) {
> + dev_err(pdev, "failed to enable regulator: %d\n", err);
> + return err;
> + }
> + vibrator->vcc_on = true;
> + }
> +
> + gpiod_set_value_cansleep(vibrator->gpio, 1);
> +
> + return 0;
> +}
> +
> +static void gpio_vibrator_stop(struct gpio_vibrator *vibrator)
> +{
> + gpiod_set_value_cansleep(vibrator->gpio, 0);
> +
> + if (vibrator->vcc_on) {
> + regulator_disable(vibrator->vcc);
> + vibrator->vcc_on = false;
> + }
> +}
> +
> +static void gpio_vibrator_play_work(struct work_struct *work)
> +{
> + struct gpio_vibrator *vibrator =
> + container_of(work, struct gpio_vibrator, play_work);
> +
> + if (vibrator->running)
> + gpio_vibrator_start(vibrator);
> + else
> + gpio_vibrator_stop(vibrator);
> +}
> +
> +static int gpio_vibrator_play_effect(struct input_dev *dev, void *data,
> + struct ff_effect *effect)
> +{
> + struct gpio_vibrator *vibrator = input_get_drvdata(dev);
> +
> + int level = effect->u.rumble.strong_magnitude;
> +
> + if (!level)
> + level = effect->u.rumble.weak_magnitude;
> +
> + if (level)
> + vibrator->running = true;
> + else
> + vibrator->running = false;
> +
> + schedule_work(&vibrator->play_work);
> +
> + return 0;
> +}
> +
> +static void gpio_vibrator_close(struct input_dev *input)
> +{
> + struct gpio_vibrator *vibrator = input_get_drvdata(input);
> +
> + cancel_work_sync(&vibrator->play_work);
> + gpio_vibrator_stop(vibrator);
> + vibrator->running = false;
> +}
> +
> +static int gpio_vibrator_probe(struct platform_device *pdev)
> +{
> + struct gpio_vibrator *vibrator;
> + int err;
> +
> + vibrator = devm_kzalloc(&pdev->dev, sizeof(*vibrator), GFP_KERNEL);
> + if (!vibrator)
> + return -ENOMEM;
> +
> + vibrator->input = devm_input_allocate_device(&pdev->dev);
> + if (!vibrator->input)
> + return -ENOMEM;
> +
> + vibrator->vcc = devm_regulator_get(&pdev->dev, "vcc");
> + err = PTR_ERR_OR_ZERO(vibrator->vcc);
> + if (err) {
> + if (err != -EPROBE_DEFER)
> + dev_err(&pdev->dev, "Failed to request regulator: %d\n",
> + err);
> + return err;
> + }
> +
> + vibrator->gpio = devm_gpiod_get(&pdev->dev, "enable", GPIOD_OUT_LOW);
> + err = PTR_ERR_OR_ZERO(vibrator->gpio);
> + if (err) {
> + if (err != -EPROBE_DEFER)
> + dev_err(&pdev->dev, "Failed to request main gpio: %d\n",
> + err);
> + return err;
> + }
> +
> + INIT_WORK(&vibrator->play_work, gpio_vibrator_play_work);
> +
> + vibrator->input->name = "gpio-vibrator";
> + vibrator->input->id.bustype = BUS_HOST;
> + vibrator->input->close = gpio_vibrator_close;
> +
> + input_set_drvdata(vibrator->input, vibrator);
> + input_set_capability(vibrator->input, EV_FF, FF_RUMBLE);
> +
> + err = input_ff_create_memless(vibrator->input, NULL,
> + gpio_vibrator_play_effect);
> + if (err) {
> + dev_err(&pdev->dev, "Couldn't create FF dev: %d\n", err);
> + return err;
> + }
> +
> + err = input_register_device(vibrator->input);
> + if (err) {
> + dev_err(&pdev->dev, "Couldn't register input dev: %d\n", err);
> + return err;
> + }
> +
> + platform_set_drvdata(pdev, vibrator);
> +
> + return 0;
> +}
> +
> +static int __maybe_unused gpio_vibrator_suspend(struct device *dev)
> +{
> + struct gpio_vibrator *vibrator = dev_get_drvdata(dev);
> +
> + cancel_work_sync(&vibrator->play_work);
> + if (vibrator->running)
> + gpio_vibrator_stop(vibrator);
> +
> + return 0;
> +}
> +
> +static int __maybe_unused gpio_vibrator_resume(struct device *dev)
> +{
> + struct gpio_vibrator *vibrator = dev_get_drvdata(dev);
> +
> + if (vibrator->running)
> + gpio_vibrator_start(vibrator);
> +
> + return 0;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(gpio_vibrator_pm_ops,
> + gpio_vibrator_suspend, gpio_vibrator_resume);
> +
> +#ifdef CONFIG_OF
> +static const struct of_device_id gpio_vibra_dt_match_table[] = {
> + { .compatible = "gpio-vibrator" },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, gpio_vibra_dt_match_table);
> +#endif
> +
> +static struct platform_driver gpio_vibrator_driver = {
> + .probe = gpio_vibrator_probe,
> + .driver = {
> + .name = "gpio-vibrator",
> + .pm = &gpio_vibrator_pm_ops,
> + .of_match_table = of_match_ptr(gpio_vibra_dt_match_table),
> + },
> +};
> +module_platform_driver(gpio_vibrator_driver);
> +
> +MODULE_AUTHOR("Luca Weiss <luca@z3ntu.xy>");
> +MODULE_DESCRIPTION("GPIO vibrator driver");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:gpio-vibrator");
> --
> 2.21.0
>
--
Dmitry
^ permalink raw reply
* Re: [SOLVED] PROBLEM: Elan touchpad regression on Kernel 5.0.10
From: Outvi V @ 2019-04-30 6:16 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, linux-kernel
In-Reply-To: <0c87e12c-c964-40a3-b97e-af2286c318c4@www.fastmail.com>
Hello,
After a cold restart, this problems seem to be solved automatically on kernel 5.0.10.
Regards,
On Tue, Apr 30, 2019, at 12:21, Outvi V wrote:
> Hello,
>
> [1.] One line summary of the problem: Elan touchpad regression on Kernel 5.0.10
>
> [2.] Full description of the problem/report:
> Elan touchpad does not work on 5.0.10 while working on 5.0.9
>
> [3.] Keywords: elan_i2c_core elan i2c touchpad 5.0.10
>
> [4.] Kernel information
> [4.1.] Kernel version:
> Linux version 5.0.10-arch1-1-ARCH (builduser@heftig-2592) (gcc
> version 8.3.0 (GCC)) #1 SMP PREEMPT Sat Apr 27 20:06:45 UTC 2019
> [4.2.] Kernel .config file:
> I'm not sure, but I think it may be referring to
>
> https://git.archlinux.org/svntogit/packages.git/tree/trunk/config?h=packages/linux
> [5.] Most recent kernel version which did not have the bug: 5.0.9
>
> [6.] Output of Oops.. message (if applicable) with symbolic information
> resolved (Not appliable)
> [7.] A small shell script or example program which triggers the
> problem: (Not appliable)
>
> [8.] Environment
> [8.1.] Software (add the output of the ver_linux script here)
>
> Linux sheltty 5.0.10-arch1-1-ARCH #1 SMP PREEMPT Sat Apr 27 20:06:45
> UTC 2019 x86_64 GNU/Linux
>
> GNU C 8.3.0
> GNU Make 4.2.1
> Binutils 2.32
> Util-linux 2.33.2
> Mount 2.33.2
> Module-init-tools 26
> E2fsprogs 1.45.0
> Jfsutils 1.1.15
> Reiserfsprogs 3.6.27
> Xfsprogs 4.20.0
> PPP 2.4.7
> Linux C Library 2.29
> Dynamic linker (ldd) 2.29
> Linux C++ Library 6.0.25
> Procps 3.3.15
> Kbd 2.0.4
> Console-tools 2.0.4
> Sh-utils 8.31
> Udev 242
> Modules Loaded 8021q 8250_dw ac ac97_bus acpi_thermal_rel
> aesni_intel aes_x86_64 agpgart ahci arc4 atkbd battery bbswitch
> bluetooth btbcm btintel btrtl btusb cfg80211 coretemp crc16
> crc32c_generic crc32c_intel crc32_pclmul crct10dif_pclmul cryptd
> crypto_simd crypto_user drm drm_kms_helper ecdh_generic elan_i2c evdev
> ext4 fat fb_sys_fops fscrypto garp ghash_clmulni_intel glue_helper hid
> hid_generic i2c_algo_bit i2c_hid i2c_i801 i8042 i915 idma64 input_leds
> int3400_thermal int3403_thermal int340x_thermal_zone intel_cstate
> intel_gtt intel_lpss intel_lpss_pci intel_pch_thermal intel_powerclamp
> intel_rapl intel_rapl_perf intel_soc_dts_iosf intel_uncore
> intel_wmi_thunderbolt ip_tables irqbypass iTCO_vendor_support iTCO_wdt
> jbd2 joydev kvm kvmgt kvm_intel ledtrig_audio libahci libata libphy
> libps2 llc mac80211 mac_hid mbcache mdev media mei mei_me mousedev mrp
> nls_cp437 nls_iso8859_1 pcc_cpufreq processor_thermal_device r8169
> r8822be realtek rfkill rng_core scsi_mod serio serio_raw snd
> snd_compress snd_hda_codec snd_hda_codec_generic snd_hda_codec_hdmi
> snd_hda_codec_realtek snd_hda_core snd_hda_ext_core snd_hda_intel
> snd_hwdep snd_pcm snd_pcm_dmaengine snd_soc_acpi
> snd_soc_acpi_intel_match snd_soc_core snd_soc_hdac_hda snd_soc_skl
> snd_soc_skl_ipc snd_soc_sst_dsp snd_soc_sst_ipc snd_timer soundcore stp
> syscopyarea sysfillrect sysimgblt tpm tpm_crb tpm_tis tpm_tis_core
> typec typec_ucsi ucsi_acpi usbhid uvcvideo vfat vfio vfio_iommu_type1
> vfio_mdev videobuf2_common videobuf2_memops videobuf2_v4l2
> videobuf2_vmalloc videodev wmi wmi_bmof x86_pkg_temp_thermal xhci_hcd
> xhci_pci x_tables
>
> [8.2.] Processor information (from /proc/cpuinfo): (Maybe not appliable)
> [8.3.] Module information (from /proc/modules):
>
> (Parts related to i2c and elan:)
>
> i2c_algo_bit 16384 1 i915, Live 0x0000000000000000
> i2c_hid 32768 0 - Live 0x0000000000000000
> hid 147456 3 hid_generic,usbhid,i2c_hid, Live 0x0000000000000000
> elan_i2c 49152 0 - Live 0x0000000000000000
> i2c_i801 36864 0 - Live 0x0000000000000000
>
> [8.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
>
> /proc/ioports:
> 0000-0000 : PCI Bus 0000:00
> 0000-0000 : dma1
> 0000-0000 : pic1
> 0000-0000 : iTCO_wdt
> 0000-0000 : timer0
> 0000-0000 : timer1
> 0000-0000 : keyboard
> 0000-0000 : PNP0C09:00
> 0000-0000 : EC data
> 0000-0000 : keyboard
> 0000-0000 : PNP0C09:00
> 0000-0000 : EC cmd
> 0000-0000 : rtc0
> 0000-0000 : dma page reg
> 0000-0000 : pic2
> 0000-0000 : dma2
> 0000-0000 : fpu
> 0000-0000 : PNP0C04:00
> 0000-0000 : iTCO_wdt
> 0000-0000 : pnp 00:02
> 0000-0000 : PCI conf1
> 0000-0000 : PCI Bus 0000:00
> 0000-0000 : pnp 00:02
> 0000-0000 : pnp 00:00
> 0000-0000 : ACPI PM1a_EVT_BLK
> 0000-0000 : ACPI PM1a_CNT_BLK
> 0000-0000 : ACPI PM_TMR
> 0000-0000 : ACPI CPU throttle
> 0000-0000 : ACPI PM2_CNT_BLK
> 0000-0000 : pnp 00:04
> 0000-0000 : ACPI GPE0_BLK
> 0000-0000 : pnp 00:01
> 0000-0000 : PCI Bus 0000:08
> 0000-0000 : 0000:08:00.0
> 0000-0000 : PCI Bus 0000:07
> 0000-0000 : 0000:07:00.0
> 0000-0000 : r8822be
> 0000-0000 : PCI Bus 0000:01
> 0000-0000 : 0000:01:00.0
> 0000-0000 : 0000:00:02.0
> 0000-0000 : 0000:00:1f.4
> 0000-0000 : i801_smbus
> 0000-0000 : 0000:00:17.0
> 0000-0000 : ahci
> 0000-0000 : 0000:00:17.0
> 0000-0000 : ahci
> 0000-0000 : 0000:00:17.0
> 0000-0000 : ahci
>
>
> [8.5.] PCI information
> It seems to be long (over 700 lines) and unrelated to this
> regression. Omitted to avoid flooding. I've kept an archive so feel
> free to ask me to post it if needed.
>
> [8.6.] SCSI information (from /proc/scsi/scsi): (Empty)
> [8.7.] Other information that might be relevant to the problem:
>
> dmesg is constantly showing "elan_i2c i2c-ELAN061B:00: invalid report
> id data (d)".
> I checked the git log and it is likely to be related to commit
> "95df599f95f398b0a34d081dadfdee3126e58163".
> I'm using Arch Linux, its kernel repository link: [1]
> I checked the related file "elan_i2c_core.c" in Arch Linux's kernel
> repository [2], and it is the same as in 5.0.10 on kernel.org.
> My laptop is a Lenovo Legion Y7000.
>
> Links:
> [1]. https://git.archlinux.org/linux.git
> [2].
> https://git.archlinux.org/linux.git/tree/drivers/input/mouse/elan_i2c_core.c?h=v5.0.10-arch1
>
> Please don't hesitate if more information or operation is needed.
^ permalink raw reply
* PROBLEM: Elan touchpad regression on Kernel 5.0.10
From: Outvi V @ 2019-04-30 4:20 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, linux-kernel
Hello,
[1.] One line summary of the problem: Elan touchpad regression on Kernel 5.0.10
[2.] Full description of the problem/report:
Elan touchpad does not work on 5.0.10 while working on 5.0.9
[3.] Keywords: elan_i2c_core elan i2c touchpad 5.0.10
[4.] Kernel information
[4.1.] Kernel version:
Linux version 5.0.10-arch1-1-ARCH (builduser@heftig-2592) (gcc version 8.3.0 (GCC)) #1 SMP PREEMPT Sat Apr 27 20:06:45 UTC 2019
[4.2.] Kernel .config file:
I'm not sure, but I think it may be referring to
https://git.archlinux.org/svntogit/packages.git/tree/trunk/config?h=packages/linux
[5.] Most recent kernel version which did not have the bug: 5.0.9
[6.] Output of Oops.. message (if applicable) with symbolic information
resolved (Not appliable)
[7.] A small shell script or example program which triggers the
problem: (Not appliable)
[8.] Environment
[8.1.] Software (add the output of the ver_linux script here)
Linux sheltty 5.0.10-arch1-1-ARCH #1 SMP PREEMPT Sat Apr 27 20:06:45 UTC 2019 x86_64 GNU/Linux
GNU C 8.3.0
GNU Make 4.2.1
Binutils 2.32
Util-linux 2.33.2
Mount 2.33.2
Module-init-tools 26
E2fsprogs 1.45.0
Jfsutils 1.1.15
Reiserfsprogs 3.6.27
Xfsprogs 4.20.0
PPP 2.4.7
Linux C Library 2.29
Dynamic linker (ldd) 2.29
Linux C++ Library 6.0.25
Procps 3.3.15
Kbd 2.0.4
Console-tools 2.0.4
Sh-utils 8.31
Udev 242
Modules Loaded 8021q 8250_dw ac ac97_bus acpi_thermal_rel aesni_intel aes_x86_64 agpgart ahci arc4 atkbd battery bbswitch bluetooth btbcm btintel btrtl btusb cfg80211 coretemp crc16 crc32c_generic crc32c_intel crc32_pclmul crct10dif_pclmul cryptd crypto_simd crypto_user drm drm_kms_helper ecdh_generic elan_i2c evdev ext4 fat fb_sys_fops fscrypto garp ghash_clmulni_intel glue_helper hid hid_generic i2c_algo_bit i2c_hid i2c_i801 i8042 i915 idma64 input_leds int3400_thermal int3403_thermal int340x_thermal_zone intel_cstate intel_gtt intel_lpss intel_lpss_pci intel_pch_thermal intel_powerclamp intel_rapl intel_rapl_perf intel_soc_dts_iosf intel_uncore intel_wmi_thunderbolt ip_tables irqbypass iTCO_vendor_support iTCO_wdt jbd2 joydev kvm kvmgt kvm_intel ledtrig_audio libahci libata libphy libps2 llc mac80211 mac_hid mbcache mdev media mei mei_me mousedev mrp nls_cp437 nls_iso8859_1 pcc_cpufreq processor_thermal_device r8169 r8822be realtek rfkill rng_core scsi_mod serio serio_raw snd snd_compress snd_hda_codec snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_core snd_hda_ext_core snd_hda_intel snd_hwdep snd_pcm snd_pcm_dmaengine snd_soc_acpi snd_soc_acpi_intel_match snd_soc_core snd_soc_hdac_hda snd_soc_skl snd_soc_skl_ipc snd_soc_sst_dsp snd_soc_sst_ipc snd_timer soundcore stp syscopyarea sysfillrect sysimgblt tpm tpm_crb tpm_tis tpm_tis_core typec typec_ucsi ucsi_acpi usbhid uvcvideo vfat vfio vfio_iommu_type1 vfio_mdev videobuf2_common videobuf2_memops videobuf2_v4l2 videobuf2_vmalloc videodev wmi wmi_bmof x86_pkg_temp_thermal xhci_hcd xhci_pci x_tables
[8.2.] Processor information (from /proc/cpuinfo): (Maybe not appliable)
[8.3.] Module information (from /proc/modules):
(Parts related to i2c and elan:)
i2c_algo_bit 16384 1 i915, Live 0x0000000000000000
i2c_hid 32768 0 - Live 0x0000000000000000
hid 147456 3 hid_generic,usbhid,i2c_hid, Live 0x0000000000000000
elan_i2c 49152 0 - Live 0x0000000000000000
i2c_i801 36864 0 - Live 0x0000000000000000
[8.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
/proc/ioports:
0000-0000 : PCI Bus 0000:00
0000-0000 : dma1
0000-0000 : pic1
0000-0000 : iTCO_wdt
0000-0000 : timer0
0000-0000 : timer1
0000-0000 : keyboard
0000-0000 : PNP0C09:00
0000-0000 : EC data
0000-0000 : keyboard
0000-0000 : PNP0C09:00
0000-0000 : EC cmd
0000-0000 : rtc0
0000-0000 : dma page reg
0000-0000 : pic2
0000-0000 : dma2
0000-0000 : fpu
0000-0000 : PNP0C04:00
0000-0000 : iTCO_wdt
0000-0000 : pnp 00:02
0000-0000 : PCI conf1
0000-0000 : PCI Bus 0000:00
0000-0000 : pnp 00:02
0000-0000 : pnp 00:00
0000-0000 : ACPI PM1a_EVT_BLK
0000-0000 : ACPI PM1a_CNT_BLK
0000-0000 : ACPI PM_TMR
0000-0000 : ACPI CPU throttle
0000-0000 : ACPI PM2_CNT_BLK
0000-0000 : pnp 00:04
0000-0000 : ACPI GPE0_BLK
0000-0000 : pnp 00:01
0000-0000 : PCI Bus 0000:08
0000-0000 : 0000:08:00.0
0000-0000 : PCI Bus 0000:07
0000-0000 : 0000:07:00.0
0000-0000 : r8822be
0000-0000 : PCI Bus 0000:01
0000-0000 : 0000:01:00.0
0000-0000 : 0000:00:02.0
0000-0000 : 0000:00:1f.4
0000-0000 : i801_smbus
0000-0000 : 0000:00:17.0
0000-0000 : ahci
0000-0000 : 0000:00:17.0
0000-0000 : ahci
0000-0000 : 0000:00:17.0
0000-0000 : ahci
[8.5.] PCI information
It seems to be long (over 700 lines) and unrelated to this regression. Omitted to avoid flooding. I've kept an archive so feel free to ask me to post it if needed.
[8.6.] SCSI information (from /proc/scsi/scsi): (Empty)
[8.7.] Other information that might be relevant to the problem:
dmesg is constantly showing "elan_i2c i2c-ELAN061B:00: invalid report id data (d)".
I checked the git log and it is likely to be related to commit "95df599f95f398b0a34d081dadfdee3126e58163".
I'm using Arch Linux, its kernel repository link: [1]
I checked the related file "elan_i2c_core.c" in Arch Linux's kernel repository [2], and it is the same as in 5.0.10 on kernel.org.
My laptop is a Lenovo Legion Y7000.
Links:
[1]. https://git.archlinux.org/linux.git
[2]. https://git.archlinux.org/linux.git/tree/drivers/input/mouse/elan_i2c_core.c?h=v5.0.10-arch1
Please don't hesitate if more information or operation is needed.
^ permalink raw reply
* Re: [PATCH 4/4] input: keyboard: gpio-keys-polled: skip oftree code when CONFIG_OF disabled
From: Enrico Weigelt, metux IT consult @ 2019-04-29 21:40 UTC (permalink / raw)
To: Frank Rowand, Enrico Weigelt, metux IT consult, linux-kernel
Cc: dmitry.torokhov, linux-input
In-Reply-To: <2a760b29-9f0b-ffa7-03dd-47ddb074563a@gmail.com>
On 29.04.19 21:44, Frank Rowand wrote:
> On 4/16/19 12:57 PM, Enrico Weigelt, metux IT consult wrote:
>> we don't need to build in oftree probing stuff when oftree isn't
>> enabled at all.
>>
>> Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
>> ---
>> drivers/input/keyboard/gpio_keys_polled.c | 8 +++++++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/input/keyboard/gpio_keys_polled.c b/drivers/input/keyboard/gpio_keys_polled.c
>> index 3f773b2..fbccb89 100644
>> --- a/drivers/input/keyboard/gpio_keys_polled.c
>> +++ b/drivers/input/keyboard/gpio_keys_polled.c
>> @@ -147,6 +147,7 @@ static void gpio_keys_polled_close(struct input_polled_dev *dev)
>> static struct gpio_keys_platform_data *
>> gpio_keys_polled_get_devtree_pdata(struct device *dev)
>> {
>> +#ifdef CONFIG_OF
>> struct gpio_keys_platform_data *pdata;
>> struct gpio_keys_button *button;
>> struct fwnode_handle *child;
>> @@ -200,6 +201,9 @@ static void gpio_keys_polled_close(struct input_polled_dev *dev)
>> }
>>
>> return pdata;
>> +#else /* CONFIG_OF */
>> + return ERR_PTR(-ENOENT);
>> +#endif /* CONFIG_OF */
>> }
>>
>> static void gpio_keys_polled_set_abs_params(struct input_dev *input,
>> @@ -226,7 +230,7 @@ static void gpio_keys_polled_set_abs_params(struct input_dev *input,
>> { .compatible = "gpio-keys-polled", },
>> { },
>> };
>
>
>> -MODULE_DEVICE_TABLE(of, gpio_keys_polled_of_match);
>> +MODULE_DEVICE_TABLE_OF(gpio_keys_polled_of_match);
>
> Not needed, when you use of_match_ptr() -- see below.
Shall I remove the MODULE_DEVICE_TABLE... line completely ?
I'd like to have nothing of-related compiled in, when oftree isn't
enabled.
>> static struct gpio_desc *gpio_keys_polled_get_gpiod_fwnode(
>> struct device *dev,
>> @@ -452,7 +456,9 @@ static int gpio_keys_polled_probe(struct platform_device *pdev)
>> .probe = gpio_keys_polled_probe,
>> .driver = {
>> .name = DRV_NAME,
>
>> +#ifdef CONFIG_OF
>> .of_match_table = gpio_keys_polled_of_match,
>> +#endif /* CONFIG_OF */
>
> No need for the #ifdef, use of_match_ptr():
>
> .of_match_table = of_match_ptr(gpio_keys_polled_of_match),
Ok, thanks.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
^ permalink raw reply
* Re: [PATCH 1/4] mod_devicetable: helper macro for declaring oftree module device table
From: Frank Rowand @ 2019-04-29 19:48 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult, Dmitry Torokhov,
Enrico Weigelt, metux IT consult
Cc: linux-kernel, linux-input
In-Reply-To: <fc747fb3-e670-79a2-f4bc-b989dee469fa@metux.net>
On 4/24/19 3:48 AM, Enrico Weigelt, metux IT consult wrote:
> On 19.04.19 09:40, Dmitry Torokhov wrote:
>> Hi Enrico,
>>
>> On Tue, Apr 16, 2019 at 09:57:22PM +0200, Enrico Weigelt, metux IT consult wrote:
>>> Little helper macro that declares an oftree module device table,
>>> if CONFIG_OF is enabled. Otherwise it's just noop.
>>>
>>> This is also helpful if some drivers can be built w/ or w/o
>>> oftree support.
>>
>> This should go to OF folks, please.
>
> hmm, they should be CCed, if my script works right.
> This one is only needed for the 4th patch (skip oftree...).
Your script did not work (BTDT). I just happened to notice this on lkml.
-Frank
>
>
> --mtx
>
^ permalink raw reply
* Re: [PATCH 4/4] input: keyboard: gpio-keys-polled: skip oftree code when CONFIG_OF disabled
From: Frank Rowand @ 2019-04-29 19:44 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult, linux-kernel
Cc: dmitry.torokhov, linux-input
In-Reply-To: <1555444645-15156-5-git-send-email-info@metux.net>
On 4/16/19 12:57 PM, Enrico Weigelt, metux IT consult wrote:
> we don't need to build in oftree probing stuff when oftree isn't
> enabled at all.
>
> Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
> ---
> drivers/input/keyboard/gpio_keys_polled.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/keyboard/gpio_keys_polled.c b/drivers/input/keyboard/gpio_keys_polled.c
> index 3f773b2..fbccb89 100644
> --- a/drivers/input/keyboard/gpio_keys_polled.c
> +++ b/drivers/input/keyboard/gpio_keys_polled.c
> @@ -147,6 +147,7 @@ static void gpio_keys_polled_close(struct input_polled_dev *dev)
> static struct gpio_keys_platform_data *
> gpio_keys_polled_get_devtree_pdata(struct device *dev)
> {
> +#ifdef CONFIG_OF
> struct gpio_keys_platform_data *pdata;
> struct gpio_keys_button *button;
> struct fwnode_handle *child;
> @@ -200,6 +201,9 @@ static void gpio_keys_polled_close(struct input_polled_dev *dev)
> }
>
> return pdata;
> +#else /* CONFIG_OF */
> + return ERR_PTR(-ENOENT);
> +#endif /* CONFIG_OF */
> }
>
> static void gpio_keys_polled_set_abs_params(struct input_dev *input,
> @@ -226,7 +230,7 @@ static void gpio_keys_polled_set_abs_params(struct input_dev *input,
> { .compatible = "gpio-keys-polled", },
> { },
> };
> -MODULE_DEVICE_TABLE(of, gpio_keys_polled_of_match);
> +MODULE_DEVICE_TABLE_OF(gpio_keys_polled_of_match);
Not needed, when you use of_match_ptr() -- see below.
>
> static struct gpio_desc *gpio_keys_polled_get_gpiod_fwnode(
> struct device *dev,
> @@ -452,7 +456,9 @@ static int gpio_keys_polled_probe(struct platform_device *pdev)
> .probe = gpio_keys_polled_probe,
> .driver = {
> .name = DRV_NAME,
> +#ifdef CONFIG_OF
> .of_match_table = gpio_keys_polled_of_match,
> +#endif /* CONFIG_OF */
No need for the #ifdef, use of_match_ptr():
.of_match_table = of_match_ptr(gpio_keys_polled_of_match),
> },
> };
> module_platform_driver(gpio_keys_polled_driver);
>
^ permalink raw reply
* Re: [PATCH v3 3/3] arm64: dts: qcom: Add Lenovo Miix 630
From: Jeffrey Hugo @ 2019-04-29 15:16 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Rob Herring, Mark Rutland, Andy Gross, David Brown, Lee Jones,
Dmitry Torokhov, Jiri Kosina, Benjamin Tissoires,
open list:HID CORE LAYER, devicetree, linux-arm-msm, lkml
In-Reply-To: <20190427044245.GD3137@builder>
On Fri, Apr 26, 2019 at 10:42 PM Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
>
> On Mon 15 Apr 09:11 PDT 2019, Jeffrey Hugo wrote:
> > diff --git a/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi b/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi
> [..]
> > + thermal-zones {
> > + battery-thermal {
> > + polling-delay-passive = <250>;
> > + polling-delay = <1000>;
> > +
> > + thermal-sensors = <&tsens0 0>;
>
> I guess you inherited the battery and skin thermal nodes from my MTP
> dts. Unfortunately after talking to Amit I think I got these wrong, and
> they should be &pmi8998_adc 0 and 5 instead.
>
> Can you confirm this?
Yeah, I pulled thermal from the MTP. Someone pointed this out on the
v4 series. I haven't circled back to it yet.
>
> > +
> > + trips {
> > + battery_crit: trip0 {
> > + temperature = <60000>;
> > + hysteresis = <2000>;
> > + type = "critical";
> > + };
> > + };
> > + };
>
> Regards,
> Bjorn
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: input: add Elan 400 combo keyboard/touchpad over i2c
From: Jeffrey Hugo @ 2019-04-29 15:15 UTC (permalink / raw)
To: Rob Herring
Cc: Benjamin Tissoires, Mark Rutland, Lee Jones, Bjorn Andersson,
Dmitry Torokhov, Andy Gross, David Brown, Jiri Kosina,
open list:HID CORE LAYER, devicetree, linux-arm-msm, lkml
In-Reply-To: <20190426224908.GA30389@bogus>
On Fri, Apr 26, 2019 at 4:49 PM Rob Herring <robh@kernel.org> wrote:
>
> On Thu, Apr 18, 2019 at 11:35:42AM +0200, Benjamin Tissoires wrote:
> > On Mon, Apr 15, 2019 at 6:11 PM Jeffrey Hugo <jeffrey.l.hugo@gmail.com> wrote:
> > >
> > > The Elan 400 combo keyboard/touchpad over i2c device is a distinct device
> > > from the Elan 400 standalone touchpad device. The combo device has been
> > > found in the Lenovo Miix 630 and HP Envy x2 laptops.
> > >
> > > Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
> > > ---
> >
> > With my comments in 2/3, I wonder if you need this patch at all then.
>
> I don't really follow the discussion in 2/3, but you should still have
> specific compatibles even if right now you don't need them.
>
> >
> > Cheers,
> > Benjamin
> >
> > > .../devicetree/bindings/input/elan,combo400-i2c.txt | 11 +++++++++++
> > > 1 file changed, 11 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/input/elan,combo400-i2c.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/input/elan,combo400-i2c.txt b/Documentation/devicetree/bindings/input/elan,combo400-i2c.txt
> > > new file mode 100644
> > > index 000000000000..fb700a29148d
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/input/elan,combo400-i2c.txt
> > > @@ -0,0 +1,11 @@
> > > +Elantech 0400 I2C combination Keyboard/Touchpad
> > > +
> > > +This binding describes an Elan device with pid 0x0400, that is a combination
> > > +keyboard + touchpad device. This binding does not cover an Elan device with
> > > +pid 0x0400 that is solely a standalone touchpad device.
> > > +
> > > +Required properties:
> > > +- compatible: should be "elan,combo400-i2c"
> > > +
> > > +This binding is compatible with the HID over I2C binding, which is specified
> > > +in hid-over-i2c.txt in this directory.
>
> Separate is fine, but we've been adding compatibles to hid-over-i2c.txt.
Are you just referring to "wacom,w9013" ?
^ permalink raw reply
* Re: [Bug 203297] Synaptics touchpad TM-3127 functionality broken by PCI runtime power management patch on 4.20.2
From: Jean Delvare @ 2019-04-29 9:45 UTC (permalink / raw)
To: Benjamin Tissoires, Jarkko Nikula
Cc: Bjorn Helgaas, Keijo Vaara, Rafael J. Wysocki, Dmitry Torokhov,
linux-pm, linux-pci, lkml, linux-input, Wolfram Sang
In-Reply-To: <CAO-hwJLCPd-KfoK7OnSpEWG4B5cYfsH3J0tYAxJeVMqHyJEN1A@mail.gmail.com>
On Mon, 2019-04-29 at 10:53 +0200, Benjamin Tissoires wrote:
> On Mon, Apr 29, 2019 at 10:38 AM Jarkko Nikula
> <jarkko.nikula@linux.intel.com> wrote:
> > I got another thought about this. I noticed these input drivers need
> > SMBus Host Notify, maybe that explain the PM dependency? If that's the
> > only dependency then we could prevent the controller suspend if there is
> > a client needing host notify mechanism. IMHO that's less hack than the
> > patch to rmi_smbus.c.
>
> So currently, AFAIK, only Synaptics (rmi4) and Elantech are using
> SMBus Host Notify.
> So this patch would prevent the same bugs for those 2 vendors, which is good.
>
> It took me some time to understand why this would be less than a hack.
> And indeed, given that Host Notify relies on the I2C connection to be
> ready for the IRQ, we can not put the controller in suspend like we do
> for others where the IRQ controller is still ready.
>
> So yes, that could work from me. Not sure what Wolfram and Jean would
> say though.
I would say OK with me, this looks like the cleanest solution to me, so
if testing is positive, let's go with it.
--
Jean Delvare
SUSE L3 Support
^ permalink raw reply
* Re: [Bug 203297] Synaptics touchpad TM-3127 functionality broken by PCI runtime power management patch on 4.20.2
From: Benjamin Tissoires @ 2019-04-29 8:53 UTC (permalink / raw)
To: Jarkko Nikula
Cc: Bjorn Helgaas, Keijo Vaara, Jean Delvare, Rafael J. Wysocki,
Dmitry Torokhov, linux-pm, linux-pci, lkml,
open list:HID CORE LAYER, Wolfram Sang
In-Reply-To: <e96a7220-974f-1df6-70ee-695ee815057f@linux.intel.com>
On Mon, Apr 29, 2019 at 10:38 AM Jarkko Nikula
<jarkko.nikula@linux.intel.com> wrote:
>
> On 4/29/19 10:45 AM, Benjamin Tissoires wrote:
> >> I would like to ask help from input subsystem experts what kind of SMBus
> >> power state dependency Synaptics RMI4 SMBus devices have since it cease
> >> to work if SMBus controllers idles between transfers and how this is
> >> best to fix?
> >
> > Hmm, I am not sure there is such an existing architecture you could
> > use in a simple patch.
> >
> > rmi-driver.c does indeed create an input device we could use to toggle
> > on/off the PM state, but those callbacks are not wired to the
> > transport driver (rmi_smbus.c), so it would required a little bit of
> > extra work. And then, there are other RMI4 functions (firmware
> > upgrade) that would not be happy if PM is in suspend while there is no
> > open input node.
> >
> I see.
>
> I got another thought about this. I noticed these input drivers need
> SMBus Host Notify, maybe that explain the PM dependency? If that's the
> only dependency then we could prevent the controller suspend if there is
> a client needing host notify mechanism. IMHO that's less hack than the
> patch to rmi_smbus.c.
So currently, AFAIK, only Synaptics (rmi4) and Elantech are using
SMBus Host Notify.
So this patch would prevent the same bugs for those 2 vendors, which is good.
It took me some time to understand why this would be less than a hack.
And indeed, given that Host Notify relies on the I2C connection to be
ready for the IRQ, we can not put the controller in suspend like we do
for others where the IRQ controller is still ready.
So yes, that could work from me. Not sure what Wolfram and Jean would
say though.
>
> Keijo: care to test does this idea would fix the issue (without the
> previous patch)? I also attached the diff.
>
> diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
> index 38af18645133..d54eafad7727 100644
> --- a/drivers/i2c/i2c-core-base.c
> +++ b/drivers/i2c/i2c-core-base.c
> @@ -327,6 +327,8 @@ static int i2c_device_probe(struct device *dev)
>
> if (client->flags & I2C_CLIENT_HOST_NOTIFY) {
> dev_dbg(dev, "Using Host Notify IRQ\n");
> + /* Adapter should not suspend for Host Notify */
> + pm_runtime_get_sync(&client->adapter->dev);
> irq = i2c_smbus_host_notify_to_irq(client);
> } else if (dev->of_node) {
> irq = of_irq_get_byname(dev->of_node, "irq");
> @@ -431,6 +433,8 @@ static int i2c_device_remove(struct device *dev)
> device_init_wakeup(&client->dev, false);
>
> client->irq = client->init_irq;
> + if (client->flags & I2C_CLIENT_HOST_NOTIFY)
> + pm_runtime_put(&client->adapter->dev);
>
> return status;
> }
>
> > So I think this "hack" (with Mika's comments addressed) should go in
> > until someone starts propagating the PM states correctly.
> >
> I guess you mean the Rafael's pm_runtime_get_sync() comment?
Oops, yes, that one, sorry :)
Cheers,
Benjamin
^ permalink raw reply
* Re: [Bug 203297] Synaptics touchpad TM-3127 functionality broken by PCI runtime power management patch on 4.20.2
From: Jarkko Nikula @ 2019-04-29 8:36 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Bjorn Helgaas, Keijo Vaara, Jean Delvare, Rafael J. Wysocki,
Dmitry Torokhov, linux-pm, linux-pci, lkml,
open list:HID CORE LAYER
In-Reply-To: <CAO-hwJKvXO6L7m0g1D6wycFP=Wu_qLDyLXTtmm0TkpxT5Z8ygw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2231 bytes --]
On 4/29/19 10:45 AM, Benjamin Tissoires wrote:
>> I would like to ask help from input subsystem experts what kind of SMBus
>> power state dependency Synaptics RMI4 SMBus devices have since it cease
>> to work if SMBus controllers idles between transfers and how this is
>> best to fix?
>
> Hmm, I am not sure there is such an existing architecture you could
> use in a simple patch.
>
> rmi-driver.c does indeed create an input device we could use to toggle
> on/off the PM state, but those callbacks are not wired to the
> transport driver (rmi_smbus.c), so it would required a little bit of
> extra work. And then, there are other RMI4 functions (firmware
> upgrade) that would not be happy if PM is in suspend while there is no
> open input node.
>
I see.
I got another thought about this. I noticed these input drivers need
SMBus Host Notify, maybe that explain the PM dependency? If that's the
only dependency then we could prevent the controller suspend if there is
a client needing host notify mechanism. IMHO that's less hack than the
patch to rmi_smbus.c.
Keijo: care to test does this idea would fix the issue (without the
previous patch)? I also attached the diff.
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 38af18645133..d54eafad7727 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -327,6 +327,8 @@ static int i2c_device_probe(struct device *dev)
if (client->flags & I2C_CLIENT_HOST_NOTIFY) {
dev_dbg(dev, "Using Host Notify IRQ\n");
+ /* Adapter should not suspend for Host Notify */
+ pm_runtime_get_sync(&client->adapter->dev);
irq = i2c_smbus_host_notify_to_irq(client);
} else if (dev->of_node) {
irq = of_irq_get_byname(dev->of_node, "irq");
@@ -431,6 +433,8 @@ static int i2c_device_remove(struct device *dev)
device_init_wakeup(&client->dev, false);
client->irq = client->init_irq;
+ if (client->flags & I2C_CLIENT_HOST_NOTIFY)
+ pm_runtime_put(&client->adapter->dev);
return status;
}
> So I think this "hack" (with Mika's comments addressed) should go in
> until someone starts propagating the PM states correctly.
>
I guess you mean the Rafael's pm_runtime_get_sync() comment?
--
Jarkko
[-- Attachment #2: i2c-core-host-notify-pm.diff --]
[-- Type: text/x-patch, Size: 830 bytes --]
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 38af18645133..d54eafad7727 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -327,6 +327,8 @@ static int i2c_device_probe(struct device *dev)
if (client->flags & I2C_CLIENT_HOST_NOTIFY) {
dev_dbg(dev, "Using Host Notify IRQ\n");
+ /* Adapter should not suspend for Host Notify */
+ pm_runtime_get_sync(&client->adapter->dev);
irq = i2c_smbus_host_notify_to_irq(client);
} else if (dev->of_node) {
irq = of_irq_get_byname(dev->of_node, "irq");
@@ -431,6 +433,8 @@ static int i2c_device_remove(struct device *dev)
device_init_wakeup(&client->dev, false);
client->irq = client->init_irq;
+ if (client->flags & I2C_CLIENT_HOST_NOTIFY)
+ pm_runtime_put(&client->adapter->dev);
return status;
}
^ permalink raw reply related
* Re: [Bug 203297] Synaptics touchpad TM-3127 functionality broken by PCI runtime power management patch on 4.20.2
From: Benjamin Tissoires @ 2019-04-29 7:45 UTC (permalink / raw)
To: Jarkko Nikula
Cc: Bjorn Helgaas, Keijo Vaara, Jean Delvare, Rafael J. Wysocki,
Dmitry Torokhov, linux-pm, linux-pci, lkml,
open list:HID CORE LAYER
In-Reply-To: <3a1139ef-10ed-6923-73c5-30fbf0c065c3@linux.intel.com>
On Fri, Apr 26, 2019 at 2:14 PM Jarkko Nikula
<jarkko.nikula@linux.intel.com> wrote:
>
> On 4/22/19 4:08 PM, Bjorn Helgaas wrote:
> > https://bugzilla.kernel.org/show_bug.cgi?id=203297
> >
> > Regression, suspected but as yet unconfirmed cause:
> >
> > c5eb1190074c ("PCI / PM: Allow runtime PM without callback functions")
> >
> > backported to 4.20 stable as 39e1be324c2f.
> >
> With help of Keijo it was confirmed above patch broke the Synaptics
> touchpad. Not bisected but touchpad works again by forcing the i2c-i801
> SMBus controller always on:
> "echo on >/sys/bus/pci/devices/0000\:00\:1f.3/power/control"
>
> Above patch is a generalized fix that fixed the runtime PM regression on
> i2c-i801 and re-allow the controller go to runtime suspend when idle. So
> most probably Synaptics touchpad was broken by i2c-i801 runtime PM also
> before but got unnoticed. Which is easy since on many platforms SMBus
> controller doesn't necessarily have the PCI PM capabilities.
>
> I would like to ask help from input subsystem experts what kind of SMBus
> power state dependency Synaptics RMI4 SMBus devices have since it cease
> to work if SMBus controllers idles between transfers and how this is
> best to fix?
Hmm, I am not sure there is such an existing architecture you could
use in a simple patch.
rmi-driver.c does indeed create an input device we could use to toggle
on/off the PM state, but those callbacks are not wired to the
transport driver (rmi_smbus.c), so it would required a little bit of
extra work. And then, there are other RMI4 functions (firmware
upgrade) that would not be happy if PM is in suspend while there is no
open input node.
So I think this "hack" (with Mika's comments addressed) should go in
until someone starts propagating the PM states correctly.
Cheers,
Benjamin
>
> Instead of revert I think we'd need to have some method to force SMBus
> controller on whenever the touchpad is active, like when there is a
> userspace listening.
>
> I'm not expert in this area so as quick proof of concept I had a
> following hack which forces the I2C/SMBus adapter, and eventually the
> parent PCI device of it on when the RMI4 SMBus device is probed and let
> the SMBus controller to idle when removed.
>
> According to Keijo it fixes the issue but I like to hear input experts
> for better place to put these.
>
> diff --git a/drivers/input/rmi4/rmi_smbus.c b/drivers/input/rmi4/rmi_smbus.c
> index b6ccf39c6a7b..2b11d69be313 100644
> --- a/drivers/input/rmi4/rmi_smbus.c
> +++ b/drivers/input/rmi4/rmi_smbus.c
> @@ -16,6 +16,7 @@
> #include <linux/lockdep.h>
> #include <linux/module.h>
> #include <linux/pm.h>
> +#include <linux/pm_runtime.h>
> #include <linux/rmi.h>
> #include <linux/slab.h>
> #include "rmi_driver.h"
> @@ -332,6 +333,9 @@ static int rmi_smb_probe(struct i2c_client *client,
>
> dev_info(&client->dev, "registering SMbus-connected sensor\n");
>
> + /* Force SMBus adapter on while RMI4 device is connected */
> + pm_runtime_get(&client->adapter->dev);
> +
> error = rmi_register_transport_device(&rmi_smb->xport);
> if (error) {
> dev_err(&client->dev, "failed to register sensor: %d\n", error);
> @@ -346,6 +350,7 @@ static int rmi_smb_remove(struct i2c_client *client)
> struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client);
>
> rmi_unregister_transport_device(&rmi_smb->xport);
> + pm_runtime_put(&client->adapter->dev);
>
> return 0;
> }
>
> --
> Jarkko
^ permalink raw reply
* Re: [Bug 203297] Synaptics touchpad TM-3127 functionality broken by PCI runtime power management patch on 4.20.2
From: Rafael J. Wysocki @ 2019-04-29 7:04 UTC (permalink / raw)
To: Jarkko Nikula
Cc: Bjorn Helgaas, Keijo Vaara, Jean Delvare, Rafael J. Wysocki,
Benjamin Tissoires, Dmitry Torokhov, Linux PM, Linux PCI,
Linux Kernel Mailing List, linux-input
In-Reply-To: <3a1139ef-10ed-6923-73c5-30fbf0c065c3@linux.intel.com>
On Fri, Apr 26, 2019 at 2:14 PM Jarkko Nikula
<jarkko.nikula@linux.intel.com> wrote:
>
> On 4/22/19 4:08 PM, Bjorn Helgaas wrote:
> > https://bugzilla.kernel.org/show_bug.cgi?id=203297
> >
> > Regression, suspected but as yet unconfirmed cause:
> >
> > c5eb1190074c ("PCI / PM: Allow runtime PM without callback functions")
> >
> > backported to 4.20 stable as 39e1be324c2f.
> >
> With help of Keijo it was confirmed above patch broke the Synaptics
> touchpad. Not bisected but touchpad works again by forcing the i2c-i801
> SMBus controller always on:
> "echo on >/sys/bus/pci/devices/0000\:00\:1f.3/power/control"
>
> Above patch is a generalized fix that fixed the runtime PM regression on
> i2c-i801 and re-allow the controller go to runtime suspend when idle. So
> most probably Synaptics touchpad was broken by i2c-i801 runtime PM also
> before but got unnoticed. Which is easy since on many platforms SMBus
> controller doesn't necessarily have the PCI PM capabilities.
>
> I would like to ask help from input subsystem experts what kind of SMBus
> power state dependency Synaptics RMI4 SMBus devices have since it cease
> to work if SMBus controllers idles between transfers and how this is
> best to fix?
>
> Instead of revert I think we'd need to have some method to force SMBus
> controller on whenever the touchpad is active, like when there is a
> userspace listening.
>
> I'm not expert in this area so as quick proof of concept I had a
> following hack which forces the I2C/SMBus adapter, and eventually the
> parent PCI device of it on when the RMI4 SMBus device is probed and let
> the SMBus controller to idle when removed.
>
> According to Keijo it fixes the issue but I like to hear input experts
> for better place to put these.
>
> diff --git a/drivers/input/rmi4/rmi_smbus.c b/drivers/input/rmi4/rmi_smbus.c
> index b6ccf39c6a7b..2b11d69be313 100644
> --- a/drivers/input/rmi4/rmi_smbus.c
> +++ b/drivers/input/rmi4/rmi_smbus.c
> @@ -16,6 +16,7 @@
> #include <linux/lockdep.h>
> #include <linux/module.h>
> #include <linux/pm.h>
> +#include <linux/pm_runtime.h>
> #include <linux/rmi.h>
> #include <linux/slab.h>
> #include "rmi_driver.h"
> @@ -332,6 +333,9 @@ static int rmi_smb_probe(struct i2c_client *client,
>
> dev_info(&client->dev, "registering SMbus-connected sensor\n");
>
> + /* Force SMBus adapter on while RMI4 device is connected */
> + pm_runtime_get(&client->adapter->dev);
That should be pm_runtime_get_sync() IMO.
Otherwise, the rmi_register_transport_device() may be called before
completing the PM transition.
> +
> error = rmi_register_transport_device(&rmi_smb->xport);
> if (error) {
> dev_err(&client->dev, "failed to register sensor: %d\n", error);
> @@ -346,6 +350,7 @@ static int rmi_smb_remove(struct i2c_client *client)
> struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client);
>
> rmi_unregister_transport_device(&rmi_smb->xport);
> + pm_runtime_put(&client->adapter->dev);
>
> return 0;
> }
>
> --
> Jarkko
^ permalink raw reply
* Re: [git pull] Input updates for v5.1-rc6
From: pr-tracker-bot @ 2019-04-28 18:05 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Linus Torvalds, linux-kernel, linux-input
In-Reply-To: <20190427223854.GA97206@dtor-ws>
The pull request you sent on Sat, 27 Apr 2019 15:38:54 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/25cce03b1d06e4b742f6dafdda2f4d80c13bdc18
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* RE: [PATCH] input: imx6ul_tsc: use devm_platform_ioremap_resource() to simplify code
From: Anson Huang @ 2019-04-28 6:30 UTC (permalink / raw)
To: Mukesh Ojha, dmitry.torokhov@gmail.com, shawnguo@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
linux-input@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <d3b8cf17-36bb-d79d-7d60-76ae2416075d@codeaurora.org>
Ping...
> -----Original Message-----
> From: Mukesh Ojha [mailto:mojha@codeaurora.org]
> Sent: Monday, April 1, 2019 4:02 PM
> To: Anson Huang <anson.huang@nxp.com>; dmitry.torokhov@gmail.com;
> shawnguo@kernel.org; s.hauer@pengutronix.de; kernel@pengutronix.de;
> festevam@gmail.com; linux-input@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; linux-kernel@vger.kernel.org
> Cc: dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH] input: imx6ul_tsc: use
> devm_platform_ioremap_resource() to simplify code
>
>
> On 4/1/2019 10:49 AM, Anson Huang wrote:
> > Use the new helper devm_platform_ioremap_resource() which wraps the
> > platform_get_resource() and devm_ioremap_resource() together, to
> > simplify the code.
> >
> > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
>
>
> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
>
> Cheers,
> -Mukesh
>
> > ---
> > drivers/input/touchscreen/imx6ul_tsc.c | 8 ++------
> > 1 file changed, 2 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/input/touchscreen/imx6ul_tsc.c
> > b/drivers/input/touchscreen/imx6ul_tsc.c
> > index c10fc59..e04eecd 100644
> > --- a/drivers/input/touchscreen/imx6ul_tsc.c
> > +++ b/drivers/input/touchscreen/imx6ul_tsc.c
> > @@ -364,8 +364,6 @@ static int imx6ul_tsc_probe(struct platform_device
> *pdev)
> > struct device_node *np = pdev->dev.of_node;
> > struct imx6ul_tsc *tsc;
> > struct input_dev *input_dev;
> > - struct resource *tsc_mem;
> > - struct resource *adc_mem;
> > int err;
> > int tsc_irq;
> > int adc_irq;
> > @@ -403,16 +401,14 @@ static int imx6ul_tsc_probe(struct
> platform_device *pdev)
> > return err;
> > }
> >
> > - tsc_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > - tsc->tsc_regs = devm_ioremap_resource(&pdev->dev, tsc_mem);
> > + tsc->tsc_regs = devm_platform_ioremap_resource(pdev, 0);
> > if (IS_ERR(tsc->tsc_regs)) {
> > err = PTR_ERR(tsc->tsc_regs);
> > dev_err(&pdev->dev, "failed to remap tsc memory: %d\n",
> err);
> > return err;
> > }
> >
> > - adc_mem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> > - tsc->adc_regs = devm_ioremap_resource(&pdev->dev, adc_mem);
> > + tsc->adc_regs = devm_platform_ioremap_resource(pdev, 1);
> > if (IS_ERR(tsc->adc_regs)) {
> > err = PTR_ERR(tsc->adc_regs);
> > dev_err(&pdev->dev, "failed to remap adc memory: %d\n",
> err);
^ permalink raw reply
* [git pull] Input updates for v5.1-rc6
From: Dmitry Torokhov @ 2019-04-27 22:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-input
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
to receive updates for the input subsystem. Just a couple of fixups for
Synaptics RMI4 driver and allowing snvs_pwrkey to be selected on more
boards.
Changelog:
---------
Jacky Bai (1):
Input: snvs_pwrkey - make it depend on ARCH_MXC
Lucas Stach (1):
Input: synaptics-rmi4 - write config register values to the right offset
Pan Bian (1):
Input: synaptics-rmi4 - fix possible double free
Diffstat:
--------
drivers/input/keyboard/Kconfig | 2 +-
drivers/input/rmi4/rmi_driver.c | 6 +-----
drivers/input/rmi4/rmi_f11.c | 2 +-
3 files changed, 3 insertions(+), 7 deletions(-)
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3 3/3] arm64: dts: qcom: Add Lenovo Miix 630
From: Bjorn Andersson @ 2019-04-27 4:42 UTC (permalink / raw)
To: Jeffrey Hugo
Cc: robh+dt, mark.rutland, agross, david.brown, lee.jones,
dmitry.torokhov, jikos, benjamin.tissoires, linux-input,
devicetree, linux-arm-msm, linux-kernel
In-Reply-To: <20190415161115.16466-1-jeffrey.l.hugo@gmail.com>
On Mon 15 Apr 09:11 PDT 2019, Jeffrey Hugo wrote:
> diff --git a/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi b/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi
[..]
> + thermal-zones {
> + battery-thermal {
> + polling-delay-passive = <250>;
> + polling-delay = <1000>;
> +
> + thermal-sensors = <&tsens0 0>;
I guess you inherited the battery and skin thermal nodes from my MTP
dts. Unfortunately after talking to Amit I think I got these wrong, and
they should be &pmi8998_adc 0 and 5 instead.
Can you confirm this?
> +
> + trips {
> + battery_crit: trip0 {
> + temperature = <60000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH] input: pm8xxx-vibrator: fix a potential NULL pointer dereference
From: Dmitry Torokhov @ 2019-04-27 0:27 UTC (permalink / raw)
To: Kangjie Lu; +Cc: pakki001, linux-input, linux-kernel
In-Reply-To: <20190309053922.22212-1-kjlu@umn.edu>
Hi Kangjie,
On Fri, Mar 08, 2019 at 11:39:21PM -0600, Kangjie Lu wrote:
> In case of_device_get_match_data fails to find the matched data,
> returns -ENODEV
How can this happen? We will not match again the device if compatible is
not present in the table.
If this happens I'd rather we crash and burn instead of silently
ignoring the failure.
Thanks.
>
> Signed-off-by: Kangjie Lu <kjlu@umn.edu>
> ---
> drivers/input/misc/pm8xxx-vibrator.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/input/misc/pm8xxx-vibrator.c b/drivers/input/misc/pm8xxx-vibrator.c
> index 7dd1c1fbe42a..740e59c11808 100644
> --- a/drivers/input/misc/pm8xxx-vibrator.c
> +++ b/drivers/input/misc/pm8xxx-vibrator.c
> @@ -196,6 +196,8 @@ static int pm8xxx_vib_probe(struct platform_device *pdev)
> vib->vib_input_dev = input_dev;
>
> regs = of_device_get_match_data(&pdev->dev);
> + if (unlikely(!regs))
> + return -ENODEV;
>
> /* operate in manual mode */
> error = regmap_read(vib->regmap, regs->drv_addr, &val);
> --
> 2.17.1
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH 2/2] HID: input: add mapping for KEY_KBD_LAYOUT_NEXT
From: Dmitry Torokhov @ 2019-04-26 23:33 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Jiri Kosina, open list:HID CORE LAYER, lkml, gwink
In-Reply-To: <CAO-hwJ+=n0Nh7XbcWRLeO5ay43YVwWK6vmMB=A5H23JKCWCUtg@mail.gmail.com>
On Fri, Apr 26, 2019 at 08:38:29AM +0200, Benjamin Tissoires wrote:
> On Thu, Apr 25, 2019 at 6:38 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> >
> > HUTRR56 defined a new usage code on consumer page to cycle through
> > set of keyboard layouts, let's add this mapping.
> >
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > ---
>
> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>
> I don't think this will collide with the HID tree, so IMO, you can
> take this through yours if you want.
OK, I will do that, thanks!
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: input: add Elan 400 combo keyboard/touchpad over i2c
From: Rob Herring @ 2019-04-26 22:49 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jeffrey Hugo, mark.rutland, Lee Jones, bjorn.andersson,
Dmitry Torokhov, agross, David Brown, Jiri Kosina,
open list:HID CORE LAYER, devicetree, linux-arm-msm, lkml
In-Reply-To: <CAO-hwJJ_BRRHL44yaZ=d_K-9iq1cyONn0rR+VW3ukW1M2Ma0ug@mail.gmail.com>
On Thu, Apr 18, 2019 at 11:35:42AM +0200, Benjamin Tissoires wrote:
> On Mon, Apr 15, 2019 at 6:11 PM Jeffrey Hugo <jeffrey.l.hugo@gmail.com> wrote:
> >
> > The Elan 400 combo keyboard/touchpad over i2c device is a distinct device
> > from the Elan 400 standalone touchpad device. The combo device has been
> > found in the Lenovo Miix 630 and HP Envy x2 laptops.
> >
> > Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
> > ---
>
> With my comments in 2/3, I wonder if you need this patch at all then.
I don't really follow the discussion in 2/3, but you should still have
specific compatibles even if right now you don't need them.
>
> Cheers,
> Benjamin
>
> > .../devicetree/bindings/input/elan,combo400-i2c.txt | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/input/elan,combo400-i2c.txt
> >
> > diff --git a/Documentation/devicetree/bindings/input/elan,combo400-i2c.txt b/Documentation/devicetree/bindings/input/elan,combo400-i2c.txt
> > new file mode 100644
> > index 000000000000..fb700a29148d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/elan,combo400-i2c.txt
> > @@ -0,0 +1,11 @@
> > +Elantech 0400 I2C combination Keyboard/Touchpad
> > +
> > +This binding describes an Elan device with pid 0x0400, that is a combination
> > +keyboard + touchpad device. This binding does not cover an Elan device with
> > +pid 0x0400 that is solely a standalone touchpad device.
> > +
> > +Required properties:
> > +- compatible: should be "elan,combo400-i2c"
> > +
> > +This binding is compatible with the HID over I2C binding, which is specified
> > +in hid-over-i2c.txt in this directory.
Separate is fine, but we've been adding compatibles to hid-over-i2c.txt.
Rob
^ permalink raw reply
* Re: [PATCH v2 2/3] input: keyboard: gpio_keys_polled: use gpio lookup table
From: Sven Van Asbroeck @ 2019-04-26 20:16 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: Linux Kernel Mailing List, Dmitry Torokhov, linux-input
In-Reply-To: <1556305282-24148-3-git-send-email-info@metux.net>
On Fri, Apr 26, 2019 at 3:03 PM Enrico Weigelt, metux IT consult
<info@metux.net> wrote:
>
> +static struct gpio_desc *gpio_keys_polled_get_gpiod_fwnode(
> + struct device *dev,
> + int idx,
> + const char *desc)
> +{
> + struct gpio_desc *gpiod;
> + struct fwnode_handle *child;
> + int x;
> +
> + /* get the idx'th child node */
> + child = device_get_next_child_node(dev, NULL);
> + while (child && x) {
> + child = device_get_next_child_node(dev, child);
> + x--;
> + }
x is uninitialized here.
^ permalink raw reply
* [PATCH v5 3/3] ARM: dts: msm8974-FP2: Add vibration motor
From: Luca Weiss @ 2019-04-26 19:47 UTC (permalink / raw)
Cc: Dmitry Torokhov, Rob Herring, Mark Rutland, Mauro Carvalho Chehab,
Pascal PAILLET-LME, Coly Li, Lee Jones, Xiaotong Lu, Brian Masney,
Rob Herring, Baolin Wang, David Brown,
open list:ARM/QUALCOMM SUPPORT,
open list:INPUT KEYBOARD, MOUSE, JOYSTICK , TOUCHSCREEN...,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Luca Weiss
In-Reply-To: <20190426194747.22256-1-luca@z3ntu.xyz>
Add a node describing the vibration motor on the Fairphone 2.
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
---
arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts b/arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts
index 643c57f84818..bf402ae39226 100644
--- a/arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts
@@ -50,6 +50,12 @@
};
};
+ vibrator {
+ compatible = "gpio-vibrator";
+ enable-gpios = <&msmgpio 86 GPIO_ACTIVE_HIGH>;
+ vcc-supply = <&pm8941_l18>;
+ };
+
smd {
rpm {
rpm_requests {
--
2.21.0
^ permalink raw reply related
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