* [PATCH v3 01/11] dt-bindings: mfd: add DT bindings for max77650
From: Bartosz Golaszewski @ 2019-02-01 9:47 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Linus Walleij, Dmitry Torokhov,
Jacek Anaszewski, Pavel Machek, Lee Jones, Sebastian Reichel,
Liam Girdwood, Greg Kroah-Hartman
Cc: linux-kernel, linux-gpio, devicetree, linux-input, linux-leds,
linux-pm, Bartosz Golaszewski
In-Reply-To: <20190201094736.32057-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Add a DT binding document for max77650 ultra-low power PMIC. This
describes the core mfd device.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
.../devicetree/bindings/mfd/max77650.txt | 28 +++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/max77650.txt
diff --git a/Documentation/devicetree/bindings/mfd/max77650.txt b/Documentation/devicetree/bindings/mfd/max77650.txt
new file mode 100644
index 000000000000..84631d3b1e14
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max77650.txt
@@ -0,0 +1,28 @@
+MAX77650 ultra low-power PMIC from Maxim Integrated.
+
+Required properties:
+-------------------
+- compatible: Must be "maxim,max77650"
+- reg: I2C device address.
+- interrupts: The interrupt on the parent the controller is
+ connected to.
+- interrupt-parent: phandle of the parent interrupt controller.
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells: Must be <2>.
+
+For device-tree bindings of sub-modules (regulator, power supply, GPIO, LEDs
+and onkey) refer to the binding documents under the respective sub-system
+directories.
+
+Example:
+--------
+
+ pmic: max77650@48 {
+ compatible = "maxim,max77650";
+ reg = <0x48>;
+
+ interrupt-controller;
+ interrupt-parent = <&gpio2>;
+ #interrupt-cells = <2>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+ };
--
2.20.1
^ permalink raw reply related
* [PATCH v3 00/11] mfd: add support for max77650 PMIC
From: Bartosz Golaszewski @ 2019-02-01 9:47 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Linus Walleij, Dmitry Torokhov,
Jacek Anaszewski, Pavel Machek, Lee Jones, Sebastian Reichel,
Liam Girdwood, Greg Kroah-Hartman
Cc: linux-kernel, linux-gpio, devicetree, linux-input, linux-leds,
linux-pm, Bartosz Golaszewski
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-6 add the DT binding documents. Patches 7-12 add all drivers.
Last patch adds a MAINTAINERS entry for this device.
Note that patch 8/13 depends on commit 03c87b95ac04 ("regulator: provide
rdev_get_regmap()") which was picked up by Mark Brown for v5.1.
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
Bartosz Golaszewski (11):
dt-bindings: mfd: add DT bindings for max77650
dt-bindings: power: supply: add DT bindings for max77650
dt-bindings: gpio: add DT bindings for max77650
dt-bindings: leds: add DT bindings for max77650
dt-bindings: input: add DT bindings for max77650
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/gpio/gpio-max77650.txt | 34 ++
.../bindings/input/max77650-onkey.txt | 26 ++
.../bindings/leds/leds-max77650.txt | 57 +++
.../devicetree/bindings/mfd/max77650.txt | 28 ++
.../power/supply/max77650-charger.txt | 27 ++
MAINTAINERS | 14 +
drivers/gpio/Kconfig | 7 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-max77650.c | 189 ++++++++++
drivers/input/misc/Kconfig | 9 +
drivers/input/misc/Makefile | 1 +
drivers/input/misc/max77650-onkey.c | 127 +++++++
drivers/leds/Kconfig | 6 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-max77650.c | 147 ++++++++
drivers/mfd/Kconfig | 11 +
drivers/mfd/Makefile | 1 +
drivers/mfd/max77650.c | 342 +++++++++++++++++
drivers/power/supply/Kconfig | 7 +
drivers/power/supply/Makefile | 1 +
drivers/power/supply/max77650-charger.c | 355 ++++++++++++++++++
include/linux/mfd/max77650.h | 59 +++
22 files changed, 1450 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-max77650.txt
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.20.1
^ permalink raw reply
* Re: [PATCH] HID: intel-ish-hid: Use VID/PID from ISH
From: Benjamin Tissoires @ 2019-02-01 9:46 UTC (permalink / raw)
To: Srinivas Pandruvada; +Cc: Jiri Kosina, open list:HID CORE LAYER, lkml
In-Reply-To: <20190130213217.8060-1-srinivas.pandruvada@linux.intel.com>
On Wed, Jan 30, 2019 at 10:32 PM Srinivas Pandruvada
<srinivas.pandruvada@linux.intel.com> wrote:
>
> The Intel ISH HID can now have other devices attached to it, not just
> sensors. Hence ISH HID transport is no longer just used for sensors.
> Currently the vendor and product id is hardcoded for sensors, but they
> can be obtained from ISH firmware for the real device. The driver already
> extract them and store as part of device_info structure in client_data.
> So use vendor id/product id obtained from the ISH firmware.
>
> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> ---
Applied to for-5.1/ish
Cheers,
Benjamin
> drivers/hid/intel-ish-hid/ishtp-hid.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/intel-ish-hid/ishtp-hid.c b/drivers/hid/intel-ish-hid/ishtp-hid.c
> index e918d78e541c..bc4c536f3c0d 100644
> --- a/drivers/hid/intel-ish-hid/ishtp-hid.c
> +++ b/drivers/hid/intel-ish-hid/ishtp-hid.c
> @@ -206,8 +206,8 @@ int ishtp_hid_probe(unsigned int cur_hid_dev,
> hid->bus = BUS_INTEL_ISHTP;
> hid->dev.parent = &client_data->cl_device->dev;
> hid->version = le16_to_cpu(ISH_HID_VERSION);
> - hid->vendor = le16_to_cpu(ISH_HID_VENDOR);
> - hid->product = le16_to_cpu(ISH_HID_PRODUCT);
> + hid->vendor = le16_to_cpu(client_data->hid_devices[cur_hid_dev].vid);
> + hid->product = le16_to_cpu(client_data->hid_devices[cur_hid_dev].pid);
> snprintf(hid->name, sizeof(hid->name), "%s %04X:%04X", "hid-ishtp",
> hid->vendor, hid->product);
>
> --
> 2.17.2
>
^ permalink raw reply
* Re: [PATCH v2 12/13] input: max77650: add onkey support
From: Lee Jones @ 2019-02-01 9:11 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Mark Brown, Bartosz Golaszewski, Rob Herring, Mark Rutland,
Linus Walleij, Jacek Anaszewski, Pavel Machek, Sebastian Reichel,
Liam Girdwood, Greg Kroah-Hartman, Linux Kernel Mailing List,
open list:GPIO SUBSYSTEM, devicetree, Linux Input,
Linux LED Subsystem, Linux PM list, Bartosz Golaszewski
In-Reply-To: <CAKdAkRQUAMsT7SA7oAaEmLrkZ6hOdAqCC9RC6HGRsjJ+TvASrQ@mail.gmail.com>
On Thu, 31 Jan 2019, Dmitry Torokhov wrote:
> On Thu, Jan 31, 2019 at 4:28 AM Mark Brown <broonie@kernel.org> wrote:
> >
> > On Thu, Jan 31, 2019 at 09:15:01AM +0100, Bartosz Golaszewski wrote:
> >
> > > I'm not sure what the policy is on merging MFD drivers, but I'm seeing
> > > that Mark Brown has already picked up the regulator part into his tree
> > > (including the binding document). I think you can just pick up the
> > > input patches and it will simply not show up in Kconfig until the core
> > > mfd module is upstream.
> >
> > > @Mark: could you please confirm it?
> >
> > Right, as it's a new MFD the Kconfig will stop it causing build breakage
> > until the MFD is merged. I'm doing it partly just to cut down on the
> > amount of mail from resends while the rest of the series gets reviewed.
>
> Ugh, I might have pulled it in if it did not reference the new header
> file. As a rule I try to enable all symbols that result in input
> devices being created so as much of input code is covered... I'd
> prefer input piece be merged with MFD.
That's no problem.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v3 2/4] Input: goodix - Add AVDD28-supply regulator support
From: Dmitry Torokhov @ 2019-02-01 8:18 UTC (permalink / raw)
To: Jagan Teki
Cc: Chen-Yu Tsai, linux-input@vger.kernel.org, linux-kernel,
Michael Trimarchi, linux-amarula
In-Reply-To: <CAMty3ZB_=VaX+_03B=ATVKzRyBHnTijC3Z8y3+DNAZcPf-=3-Q@mail.gmail.com>
On Thu, Jan 31, 2019 at 12:00 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> On Wed, Jan 9, 2019 at 1:10 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> >
> > Hi Jagan,
> >
> > On Sat, Dec 15, 2018 at 08:48:00PM +0530, Jagan Teki wrote:
> > > Goodix CTP controllers have AVDD28 pin connected to voltage
> > > regulator which may not be turned on by default, like for GT5663.
> > >
> > > Add support for such ctp used boards by adding voltage regulator
> > > handling code to goodix ctp driver.
> > >
> > > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > > ---
> > > drivers/input/touchscreen/goodix.c | 33 +++++++++++++++++++++++++-----
> > > 1 file changed, 28 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/input/touchscreen/goodix.c b/drivers/input/touchscreen/goodix.c
> > > index f2d9c2c41885..7371f6946098 100644
> > > --- a/drivers/input/touchscreen/goodix.c
> > > +++ b/drivers/input/touchscreen/goodix.c
> > > @@ -27,6 +27,7 @@
> > > #include <linux/delay.h>
> > > #include <linux/irq.h>
> > > #include <linux/interrupt.h>
> > > +#include <linux/regulator/consumer.h>
> > > #include <linux/slab.h>
> > > #include <linux/acpi.h>
> > > #include <linux/of.h>
> > > @@ -47,6 +48,7 @@ struct goodix_ts_data {
> > > struct touchscreen_properties prop;
> > > unsigned int max_touch_num;
> > > unsigned int int_trigger_type;
> > > + struct regulator *avdd28;
> > > struct gpio_desc *gpiod_int;
> > > struct gpio_desc *gpiod_rst;
> > > u16 id;
> > > @@ -786,25 +788,41 @@ static int goodix_ts_probe(struct i2c_client *client,
> > > if (error)
> > > return error;
> > >
> > > + ts->avdd28 = devm_regulator_get(&client->dev, "AVDD28");
> > > + if (IS_ERR(ts->avdd28)) {
> > > + error = PTR_ERR(ts->avdd28);
> > > + if (error != -EPROBE_DEFER)
> > > + dev_err(&client->dev,
> > > + "Failed to get AVDD28 regulator: %d\n", error);
> > > + return error;
> > > + }
> > > +
> > > + /* power the controller */
> > > + error = regulator_enable(ts->avdd28);
> > > + if (error) {
> > > + dev_err(&client->dev, "Controller fail to enable AVDD28\n");
> > > + return error;
> > > + }
> > > +
> > > if (ts->gpiod_int && ts->gpiod_rst) {
> > > /* reset the controller */
> > > error = goodix_reset(ts);
> > > if (error) {
> > > dev_err(&client->dev, "Controller reset failed.\n");
> > > - return error;
> > > + goto error;
> > > }
> > > }
> > >
> > > error = goodix_i2c_test(client);
> > > if (error) {
> > > dev_err(&client->dev, "I2C communication failure: %d\n", error);
> > > - return error;
> > > + goto error;
> > > }
> > >
> > > error = goodix_read_version(ts);
> > > if (error) {
> > > dev_err(&client->dev, "Read version failed.\n");
> > > - return error;
> > > + goto error;
> > > }
> > >
> > > ts->chip = goodix_get_chip_data(ts->id);
> > > @@ -823,23 +841,28 @@ static int goodix_ts_probe(struct i2c_client *client,
> > > dev_err(&client->dev,
> > > "Failed to invoke firmware loader: %d\n",
> > > error);
> > > - return error;
> > > + goto error;
> > > }
> > >
> > > return 0;
> > > } else {
> > > error = goodix_configure_dev(ts);
> > > if (error)
> > > - return error;
> > > + goto error;
> > > }
> > >
> > > return 0;
> > > +
> > > +error:
> > > + regulator_disable(ts->avdd28);
> > > + return error;
> > > }
> > >
> > > static int goodix_ts_remove(struct i2c_client *client)
> > > {
> > > struct goodix_ts_data *ts = i2c_get_clientdata(client);
> > >
> > > + regulator_disable(ts->avdd28);
> >
> > This may be disabling the regulator too early. Please use
> > devm_add_action_or_reset() to install a custom devm handler that would
> > disable the regulator in line with the rest of devm unwinding flow.
>
> Like handler with only regulator_disable?
Right.
> and would that call from suspend or not need?
No, it will only be called when device is unbound from the driver or
when probe fails. If you need to control regulator in suspend/resume
you can do it with normal regulator_enable() and regulator_disable()
calls.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3 2/4] Input: goodix - Add AVDD28-supply regulator support
From: Jagan Teki @ 2019-01-31 20:00 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Chen-Yu Tsai, linux-input, linux-kernel, Michael Trimarchi,
linux-amarula
In-Reply-To: <20190107230009.wfzozb6g6ucymngw@penguin>
On Wed, Jan 9, 2019 at 1:10 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> Hi Jagan,
>
> On Sat, Dec 15, 2018 at 08:48:00PM +0530, Jagan Teki wrote:
> > Goodix CTP controllers have AVDD28 pin connected to voltage
> > regulator which may not be turned on by default, like for GT5663.
> >
> > Add support for such ctp used boards by adding voltage regulator
> > handling code to goodix ctp driver.
> >
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > ---
> > drivers/input/touchscreen/goodix.c | 33 +++++++++++++++++++++++++-----
> > 1 file changed, 28 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/input/touchscreen/goodix.c b/drivers/input/touchscreen/goodix.c
> > index f2d9c2c41885..7371f6946098 100644
> > --- a/drivers/input/touchscreen/goodix.c
> > +++ b/drivers/input/touchscreen/goodix.c
> > @@ -27,6 +27,7 @@
> > #include <linux/delay.h>
> > #include <linux/irq.h>
> > #include <linux/interrupt.h>
> > +#include <linux/regulator/consumer.h>
> > #include <linux/slab.h>
> > #include <linux/acpi.h>
> > #include <linux/of.h>
> > @@ -47,6 +48,7 @@ struct goodix_ts_data {
> > struct touchscreen_properties prop;
> > unsigned int max_touch_num;
> > unsigned int int_trigger_type;
> > + struct regulator *avdd28;
> > struct gpio_desc *gpiod_int;
> > struct gpio_desc *gpiod_rst;
> > u16 id;
> > @@ -786,25 +788,41 @@ static int goodix_ts_probe(struct i2c_client *client,
> > if (error)
> > return error;
> >
> > + ts->avdd28 = devm_regulator_get(&client->dev, "AVDD28");
> > + if (IS_ERR(ts->avdd28)) {
> > + error = PTR_ERR(ts->avdd28);
> > + if (error != -EPROBE_DEFER)
> > + dev_err(&client->dev,
> > + "Failed to get AVDD28 regulator: %d\n", error);
> > + return error;
> > + }
> > +
> > + /* power the controller */
> > + error = regulator_enable(ts->avdd28);
> > + if (error) {
> > + dev_err(&client->dev, "Controller fail to enable AVDD28\n");
> > + return error;
> > + }
> > +
> > if (ts->gpiod_int && ts->gpiod_rst) {
> > /* reset the controller */
> > error = goodix_reset(ts);
> > if (error) {
> > dev_err(&client->dev, "Controller reset failed.\n");
> > - return error;
> > + goto error;
> > }
> > }
> >
> > error = goodix_i2c_test(client);
> > if (error) {
> > dev_err(&client->dev, "I2C communication failure: %d\n", error);
> > - return error;
> > + goto error;
> > }
> >
> > error = goodix_read_version(ts);
> > if (error) {
> > dev_err(&client->dev, "Read version failed.\n");
> > - return error;
> > + goto error;
> > }
> >
> > ts->chip = goodix_get_chip_data(ts->id);
> > @@ -823,23 +841,28 @@ static int goodix_ts_probe(struct i2c_client *client,
> > dev_err(&client->dev,
> > "Failed to invoke firmware loader: %d\n",
> > error);
> > - return error;
> > + goto error;
> > }
> >
> > return 0;
> > } else {
> > error = goodix_configure_dev(ts);
> > if (error)
> > - return error;
> > + goto error;
> > }
> >
> > return 0;
> > +
> > +error:
> > + regulator_disable(ts->avdd28);
> > + return error;
> > }
> >
> > static int goodix_ts_remove(struct i2c_client *client)
> > {
> > struct goodix_ts_data *ts = i2c_get_clientdata(client);
> >
> > + regulator_disable(ts->avdd28);
>
> This may be disabling the regulator too early. Please use
> devm_add_action_or_reset() to install a custom devm handler that would
> disable the regulator in line with the rest of devm unwinding flow.
Like handler with only regulator_disable? and would that call from
suspend or not need?
^ permalink raw reply
* Re: [PATCH v2 12/13] input: max77650: add onkey support
From: Dmitry Torokhov @ 2019-01-31 19:18 UTC (permalink / raw)
To: Mark Brown
Cc: Bartosz Golaszewski, Rob Herring, Mark Rutland, Linus Walleij,
Jacek Anaszewski, Pavel Machek, Lee Jones, Sebastian Reichel,
Liam Girdwood, Greg Kroah-Hartman, Linux Kernel Mailing List,
open list:GPIO SUBSYSTEM, devicetree, Linux Input,
Linux LED Subsystem, Linux PM list, Bartosz Golaszewski
In-Reply-To: <20190131122813.GB20797@sirena.org.uk>
On Thu, Jan 31, 2019 at 4:28 AM Mark Brown <broonie@kernel.org> wrote:
>
> On Thu, Jan 31, 2019 at 09:15:01AM +0100, Bartosz Golaszewski wrote:
>
> > I'm not sure what the policy is on merging MFD drivers, but I'm seeing
> > that Mark Brown has already picked up the regulator part into his tree
> > (including the binding document). I think you can just pick up the
> > input patches and it will simply not show up in Kconfig until the core
> > mfd module is upstream.
>
> > @Mark: could you please confirm it?
>
> Right, as it's a new MFD the Kconfig will stop it causing build breakage
> until the MFD is merged. I'm doing it partly just to cut down on the
> amount of mail from resends while the rest of the series gets reviewed.
Ugh, I might have pulled it in if it did not reference the new header
file. As a rule I try to enable all symbols that result in input
devices being created so as much of input code is covered... I'd
prefer input piece be merged with MFD.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 12/13] input: max77650: add onkey support
From: Mark Brown @ 2019-01-31 12:28 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Dmitry Torokhov, Rob Herring, Mark Rutland, Linus Walleij,
Jacek Anaszewski, Pavel Machek, Lee Jones, Sebastian Reichel,
Liam Girdwood, Greg Kroah-Hartman, Linux Kernel Mailing List,
open list:GPIO SUBSYSTEM, devicetree, Linux Input,
Linux LED Subsystem, Linux PM list, Bartosz Golaszewski
In-Reply-To: <CAMRc=McaqqmU6S_Yz35ZMvhWtWO4hTASA0fmL5CT4JizbYgu4Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 639 bytes --]
On Thu, Jan 31, 2019 at 09:15:01AM +0100, Bartosz Golaszewski wrote:
> I'm not sure what the policy is on merging MFD drivers, but I'm seeing
> that Mark Brown has already picked up the regulator part into his tree
> (including the binding document). I think you can just pick up the
> input patches and it will simply not show up in Kconfig until the core
> mfd module is upstream.
> @Mark: could you please confirm it?
Right, as it's a new MFD the Kconfig will stop it causing build breakage
until the MFD is merged. I'm doing it partly just to cut down on the
amount of mail from resends while the rest of the series gets reviewed.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] platform/x86: silead_dmi: Add touchscreen platform data for the Chuwi Hi8 Air tablet
From: Kai Renzig @ 2019-01-31 10:49 UTC (permalink / raw)
To: Hans de Goede, Darren Hart, Andy Shevchenko
Cc: linux-input, platform-driver-x86, linux-kernel, Kai Renzig
Add touchscreen platform data for the Chuwi Hi8 Air tablet.
Signed-off-by: Kai Renzig <k.renzig@gmail.com>
---
drivers/platform/x86/touchscreen_dmi.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/platform/x86/touchscreen_dmi.c b/drivers/platform/x86/touchscreen_dmi.c
index 8c5d47c0aea6..48e5d92040ab 100644
--- a/drivers/platform/x86/touchscreen_dmi.c
+++ b/drivers/platform/x86/touchscreen_dmi.c
@@ -41,6 +41,20 @@ static const struct ts_dmi_data chuwi_hi8_data = {
.properties = chuwi_hi8_props,
};
+static const struct property_entry chuwi_hi8_air_props[] = {
+ PROPERTY_ENTRY_U32("touchscreen-size-x", 1728),
+ PROPERTY_ENTRY_U32("touchscreen-size-y", 1148),
+ PROPERTY_ENTRY_BOOL("touchscreen-swapped-x-y"),
+ PROPERTY_ENTRY_STRING("firmware-name", "gsl3680-chuwi-hi8-air.fw"),
+ PROPERTY_ENTRY_U32("silead,max-fingers", 10),
+ { }
+};
+
+static const struct ts_dmi_data chuwi_hi8_air_data = {
+ .acpi_name = "MSSL1680:00",
+ .properties = chuwi_hi8_air_props,
+};
+
static const struct property_entry chuwi_hi8_pro_props[] = {
PROPERTY_ENTRY_U32("touchscreen-min-x", 6),
PROPERTY_ENTRY_U32("touchscreen-min-y", 3),
@@ -497,6 +511,15 @@ static const struct dmi_system_id touchscreen_dmi_table[] = {
DMI_MATCH(DMI_BIOS_VERSION, "H1D_S806_206"),
},
},
+ {
+ /* Chuwi Hi8 Air (CWI543) */
+ .driver_data = (void *)&chuwi_hi8_air_data,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Default string"),
+ DMI_MATCH(DMI_BOARD_NAME, "Cherry Trail CR"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Hi8 Air"),
+ },
+ },
{
/* Chuwi Hi8 Pro (CWI513) */
.driver_data = (void *)&chuwi_hi8_pro_data,
--
2.19.1
^ permalink raw reply related
* Re: [PATCH v2 12/13] input: max77650: add onkey support
From: Bartosz Golaszewski @ 2019-01-31 8:15 UTC (permalink / raw)
To: Dmitry Torokhov, Mark Brown
Cc: Rob Herring, Mark Rutland, Linus Walleij, Jacek Anaszewski,
Pavel Machek, Lee Jones, Sebastian Reichel, Liam Girdwood,
Greg Kroah-Hartman, Linux Kernel Mailing List,
open list:GPIO SUBSYSTEM, devicetree, Linux Input,
Linux LED Subsystem, Linux PM list, Bartosz Golaszewski
In-Reply-To: <20190130185328.GA149208@dtor-ws>
śr., 30 sty 2019 o 19:53 Dmitry Torokhov <dmitry.torokhov@gmail.com> napisał(a):
>
> On Tue, Jan 29, 2019 at 02:35:44PM +0100, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> >
> > Add support for the push- and slide-button events for max77650.
> >
> > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>
> Please feel free to merge with other patches (MFD tree I suppose?).
>
Hi Dmitry,
I'm not sure what the policy is on merging MFD drivers, but I'm seeing
that Mark Brown has already picked up the regulator part into his tree
(including the binding document). I think you can just pick up the
input patches and it will simply not show up in Kconfig until the core
mfd module is upstream.
@Mark: could you please confirm it?
Best regards,
Bartosz Golaszewski
^ permalink raw reply
* [PATCH] HID: intel-ish-hid: Use VID/PID from ISH
From: Srinivas Pandruvada @ 2019-01-30 21:32 UTC (permalink / raw)
To: jikos, benjamin.tissoires; +Cc: linux-input, linux-kernel, Srinivas Pandruvada
The Intel ISH HID can now have other devices attached to it, not just
sensors. Hence ISH HID transport is no longer just used for sensors.
Currently the vendor and product id is hardcoded for sensors, but they
can be obtained from ISH firmware for the real device. The driver already
extract them and store as part of device_info structure in client_data.
So use vendor id/product id obtained from the ISH firmware.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
drivers/hid/intel-ish-hid/ishtp-hid.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/intel-ish-hid/ishtp-hid.c b/drivers/hid/intel-ish-hid/ishtp-hid.c
index e918d78e541c..bc4c536f3c0d 100644
--- a/drivers/hid/intel-ish-hid/ishtp-hid.c
+++ b/drivers/hid/intel-ish-hid/ishtp-hid.c
@@ -206,8 +206,8 @@ int ishtp_hid_probe(unsigned int cur_hid_dev,
hid->bus = BUS_INTEL_ISHTP;
hid->dev.parent = &client_data->cl_device->dev;
hid->version = le16_to_cpu(ISH_HID_VERSION);
- hid->vendor = le16_to_cpu(ISH_HID_VENDOR);
- hid->product = le16_to_cpu(ISH_HID_PRODUCT);
+ hid->vendor = le16_to_cpu(client_data->hid_devices[cur_hid_dev].vid);
+ hid->product = le16_to_cpu(client_data->hid_devices[cur_hid_dev].pid);
snprintf(hid->name, sizeof(hid->name), "%s %04X:%04X", "hid-ishtp",
hid->vendor, hid->product);
--
2.17.2
^ permalink raw reply related
* Re: [PATCH 1/3] Input: lpc32xx-key - add clocks property and fix DT binding example
From: Vladimir Zapolskiy @ 2019-01-30 21:22 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring
Cc: devicetree, linux-input, linux-arm-kernel, Sylvain Lemieux
In-Reply-To: <20190126142921.16041-2-vz@mleia.com>
Hi Rob, Dmitry,
On 01/26/2019 04:29 PM, Vladimir Zapolskiy wrote:
> The keypad controller on NXP LPC32xx requires its clock gate to be open,
> therefore add description of the requires 'clocks' property.
>
> In addition adjust the example by adding description of required 'clocks'
> property and by fixing 'interrupts' property.
>
> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
> ---
> Documentation/devicetree/bindings/input/lpc32xx-key.txt | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/input/lpc32xx-key.txt b/Documentation/devicetree/bindings/input/lpc32xx-key.txt
> index bcf62f856358..2b075a080d30 100644
> --- a/Documentation/devicetree/bindings/input/lpc32xx-key.txt
> +++ b/Documentation/devicetree/bindings/input/lpc32xx-key.txt
> @@ -8,6 +8,7 @@ Required Properties:
> - reg: Physical base address of the controller and length of memory mapped
> region.
> - interrupts: The interrupt number to the cpu.
> +- clocks: phandle to clock controller plus clock-specifier pair
> - nxp,debounce-delay-ms: Debounce delay in ms
> - nxp,scan-delay-ms: Repeated scan period in ms
> - linux,keymap: the key-code to be reported when the key is pressed
> @@ -22,7 +23,9 @@ Example:
> key@40050000 {
> compatible = "nxp,lpc3220-key";
> reg = <0x40050000 0x1000>;
> - interrupts = <54 0>;
> + clocks = <&clk LPC32XX_CLK_KEY>;
> + interrupt-parent = <&sic1>;
> + interrupts = <22 IRQ_TYPE_LEVEL_HIGH>;
> keypad,num-rows = <1>;
> keypad,num-columns = <1>;
> nxp,debounce-delay-ms = <3>;
>
if you find time, please review/ack this change before 5.0-rc5 to give
me a chance to push it through ARM tree, thank you in advance.
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v2] doc: Change LXR references to elixir.bootlin.com
From: Federico Vaga @ 2019-01-30 21:21 UTC (permalink / raw)
To: Jonathan Neuschäfer
Cc: linux-doc, Kepplinger Martin, Stephen Boyd, Dmitry Torokhov,
Jonathan Corbet, Markus Heiser, Alessia Mantegazza, Michael Rodin,
Minghui Liu, Grigory Shipunov, Mathieu Poirier, Charles Keepax,
Coly Li, Mauro Carvalho Chehab, Matthias Brugger, Jeff Kirsher,
Guenter Roeck, Takashi Iwai, linux-input
In-Reply-To: <20190130172528.7552-1-j.neuschaefer@gmx.net>
On 2019-01-30 18:25, Jonathan Neuschäfer wrote:
> Recently, Free Electrons was renamed to Bootlin[1]. Less recently, the
> Linux Cross Reference (LXR) at lxr.free-electrons.com was replaced by
> Elixir[2], and lxr.free-electrons.com redirected first to
> elixir.free-electrons.com and now to elixir.bootlin.com.
>
> [1]: https://bootlin.com/blog/free-electrons-becomes-bootlin/
> [2]: https://github.com/free-electrons/elixir
>
> Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Acked-by: Federico Vaga <federico.vaga@vaga.pv.it>
> ---
>
> v2:
> - Fix ident search URL, as suggested by Martin Kepplinger
> - Add trailing slash, which I accidentally dropped in v1 in
> Documentation/translations/it_IT/process/howto.rst
>
> v1:
> https://lore.kernel.org/lkml/20190129142923.5743-1-j.neuschaefer@gmx.net/
> ---
> Documentation/input/devices/xpad.rst | 2 +-
> Documentation/process/howto.rst | 2 +-
> Documentation/process/kernel-docs.rst | 2 +-
> Documentation/translations/it_IT/process/howto.rst | 2 +-
> Documentation/translations/ja_JP/howto.rst | 2 +-
> Documentation/translations/ko_KR/howto.rst | 2 +-
> 6 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/input/devices/xpad.rst
> b/Documentation/input/devices/xpad.rst
> index b8bd65962dd8..173c2acda9fd 100644
> --- a/Documentation/input/devices/xpad.rst
> +++ b/Documentation/input/devices/xpad.rst
> @@ -218,7 +218,7 @@ References
> .. [1] http://euc.jp/periphs/xbox-controller.ja.html (ITO Takayuki)
> .. [2] http://xpad.xbox-scene.com/
> .. [3] http://www.markosweb.com/www/xboxhackz.com/
> -.. [4] http://lxr.free-electrons.com/ident?i=xpad_device
> +.. [4] https://elixir.bootlin.com/linux/latest/ident/xpad_device
>
>
> Historic Edits
> diff --git a/Documentation/process/howto.rst
> b/Documentation/process/howto.rst
> index 00c8ddd2ed2c..64deab5cfb3b 100644
> --- a/Documentation/process/howto.rst
> +++ b/Documentation/process/howto.rst
> @@ -225,7 +225,7 @@ Cross-Reference project, which is able to present
> source code in a
> self-referential, indexed webpage format. An excellent up-to-date
> repository of the kernel code may be found at:
>
> - http://lxr.free-electrons.com/
> + https://elixir.bootlin.com/
>
>
> The development process
> diff --git a/Documentation/process/kernel-docs.rst
> b/Documentation/process/kernel-docs.rst
> index 3fb28de556e4..ab12dddc773e 100644
> --- a/Documentation/process/kernel-docs.rst
> +++ b/Documentation/process/kernel-docs.rst
> @@ -565,7 +565,7 @@ Miscellaneous
>
> * Name: **Cross-Referencing Linux**
>
> - :URL: http://lxr.free-electrons.com/
> + :URL: https://elixir.bootlin.com/
> :Keywords: Browsing source code.
> :Description: Another web-based Linux kernel source code
> browser.
> Lots of cross references to variables and functions. You can
> see
> diff --git a/Documentation/translations/it_IT/process/howto.rst
> b/Documentation/translations/it_IT/process/howto.rst
> index 909e6a55bc43..f9a44b1af89d 100644
> --- a/Documentation/translations/it_IT/process/howto.rst
> +++ b/Documentation/translations/it_IT/process/howto.rst
> @@ -234,7 +234,7 @@ il progetto Linux Cross-Reference, che è in grado
> di presentare codice
> sorgente in un formato autoreferenziale ed indicizzato. Un eccellente
> ed
> aggiornata fonte di consultazione del codice del kernel la potete
> trovare qui:
>
> - http://lxr.free-electrons.com/
> + https://elixir.bootlin.com/
>
>
> Il processo di sviluppo
> diff --git a/Documentation/translations/ja_JP/howto.rst
> b/Documentation/translations/ja_JP/howto.rst
> index f3116381c26b..2ca9389d5915 100644
> --- a/Documentation/translations/ja_JP/howto.rst
> +++ b/Documentation/translations/ja_JP/howto.rst
> @@ -245,7 +245,7 @@ Linux カーネルソースツリーの中に含まれる、きれいにし、
> できます。この最新の素晴しいカーネルコードのリポジトリは以下で見つかり
> ます -
>
> - http://lxr.free-electrons.com/
> + https://elixir.bootlin.com/
>
> 開発プロセス
> ------------
> diff --git a/Documentation/translations/ko_KR/howto.rst
> b/Documentation/translations/ko_KR/howto.rst
> index a8197e072599..9fc869087e9c 100644
> --- a/Documentation/translations/ko_KR/howto.rst
> +++ b/Documentation/translations/ko_KR/howto.rst
> @@ -235,7 +235,7 @@ ReST 마크업을 사용하는 문서들은 Documentation/output 에 생성된
> 소스코드를 인덱스된 웹 페이지들의 형태로 보여준다. 최신의 멋진 커널
> 코드 저장소는 다음을 통하여 참조할 수 있다.
>
> - http://lxr.free-electrons.com/
> + https://elixir.bootlin.com/
>
>
> 개발 프로세스
--
Federico Vaga
http://www.federicovaga.it/
^ permalink raw reply
* Re: [PATCH v2 11/13] leds: max77650: add LEDs support
From: Jacek Anaszewski @ 2019-01-30 19:59 UTC (permalink / raw)
To: Bartosz Golaszewski, Rob Herring, Mark Rutland, Linus Walleij,
Dmitry Torokhov, Pavel Machek, Lee Jones, Sebastian Reichel,
Liam Girdwood, Mark Brown, Greg Kroah-Hartman
Cc: linux-kernel, linux-gpio, devicetree, linux-input, linux-leds,
linux-pm, Bartosz Golaszewski
In-Reply-To: <20190129133545.1931-13-brgl@bgdev.pl>
Hi Bartosz,
Thank you for the update.
One more thing drew my attention, please refer below.
On 1/29/19 2:35 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> This adds basic support for LEDs for the max77650 PMIC. The device has
> three current sinks for driving LEDs.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> drivers/leds/Kconfig | 6 ++
> drivers/leds/Makefile | 1 +
> drivers/leds/leds-max77650.c | 152 +++++++++++++++++++++++++++++++++++
> 3 files changed, 159 insertions(+)
> create mode 100644 drivers/leds/leds-max77650.c
>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index a72f97fca57b..6e7a8f51eccc 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -608,6 +608,12 @@ config LEDS_TLC591XX
> This option enables support for Texas Instruments TLC59108
> and TLC59116 LED controllers.
>
> +config LEDS_MAX77650
> + tristate "LED support for Maxim MAX77650 PMIC"
> + depends on MFD_MAX77650
> + help
> + LEDs driver for MAX77650 family of PMICs from Maxim Integrated."
> +
> config LEDS_MAX77693
> tristate "LED support for MAX77693 Flash"
> depends on LEDS_CLASS_FLASH
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index 4c1b0054f379..f48b2404dbb7 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -61,6 +61,7 @@ obj-$(CONFIG_LEDS_MC13783) += leds-mc13783.o
> obj-$(CONFIG_LEDS_NS2) += leds-ns2.o
> obj-$(CONFIG_LEDS_NETXBIG) += leds-netxbig.o
> obj-$(CONFIG_LEDS_ASIC3) += leds-asic3.o
> +obj-$(CONFIG_LEDS_MAX77650) += leds-max77650.o
> obj-$(CONFIG_LEDS_MAX77693) += leds-max77693.o
> obj-$(CONFIG_LEDS_MAX8997) += leds-max8997.o
> obj-$(CONFIG_LEDS_LM355x) += leds-lm355x.o
> diff --git a/drivers/leds/leds-max77650.c b/drivers/leds/leds-max77650.c
> new file mode 100644
> index 000000000000..e3a3c0e79b7a
> --- /dev/null
> +++ b/drivers/leds/leds-max77650.c
> @@ -0,0 +1,152 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (C) 2018 BayLibre SAS
> +// Author: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> +//
> +// LED driver for MAXIM 77650/77651 charger/power-supply.
> +
> +#include <linux/i2c.h>
> +#include <linux/leds.h>
> +#include <linux/mfd/max77650.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +
> +#define MAX77650_NUM_LEDS 3
> +
> +#define MAX77650_LED_A_BASE 0x40
> +#define MAX77650_LED_B_BASE 0x43
> +
> +#define MAX77650_LED_BR_MASK GENMASK(4, 0)
> +#define MAX77650_LED_EN_MASK GENMASK(7, 6)
> +
> +/* Enable EN_LED_MSTR. */
> +#define MAX77650_LED_TOP_DEFAULT BIT(0)
> +
> +#define MAX77650_LED_ENABLE GENMASK(7, 6)
> +#define MAX77650_LED_DISABLE 0x00
> +
> +#define MAX77650_LED_A_DEFAULT MAX77650_LED_DISABLE
> +/* 100% on duty */
> +#define MAX77650_LED_B_DEFAULT GENMASK(3, 0)
> +
> +struct max77650_led {
> + struct led_classdev cdev;
> + struct regmap *map;
> + unsigned int regA;
> + unsigned int regB;
> +};
> +
> +static struct max77650_led *max77650_to_led(struct led_classdev *cdev)
> +{
> + return container_of(cdev, struct max77650_led, cdev);
> +}
> +
> +static int max77650_led_brightness_set(struct led_classdev *cdev,
> + enum led_brightness brightness)
> +{
> + struct max77650_led *led = max77650_to_led(cdev);
> + int val, mask;
> +
> + mask = MAX77650_LED_BR_MASK | MAX77650_LED_EN_MASK;
> +
> + if (brightness == LED_OFF) {
> + val = MAX77650_LED_DISABLE;
> + } else {
> + val = MAX77650_LED_ENABLE;
> + /*
> + * We can set the brightness with 5-bit resolution.
> + *
> + * For brightness == 1, the bits we're writing will be 0, but
> + * since we keep LED_FS0 set to 12.8mA full-scale range, the
> + * LED will be lit slightly.
> + */
> + val |= brightness / 8;
We have max_brightness property and you seem not to use it.
With 5-bit brightness resolution it should be initialized
to 32 and then we will be able to avoid the division here.
> + }
> +
> + return regmap_update_bits(led->map, led->regA, mask, val);
> +}
> +
> +static int max77650_led_probe(struct platform_device *pdev)
> +{
> + struct device_node *of_node, *child;
> + struct max77650_led *leds, *led;
> + struct device *parent;
> + struct device *dev;
> + struct regmap *map;
> + const char *label;
> + int rv, num_leds;
> + u32 reg;
> +
> + dev = &pdev->dev;
> + parent = dev->parent;
> + of_node = dev->of_node;
> +
> + if (!of_node)
> + return -ENODEV;
> +
> + leds = devm_kcalloc(dev, sizeof(*leds), MAX77650_NUM_LEDS, GFP_KERNEL);
> + if (!leds)
> + return -ENOMEM;
> +
> + map = dev_get_regmap(dev->parent, NULL);
> + if (!map)
> + return -ENODEV;
> +
> + num_leds = of_get_child_count(of_node);
> + if (!num_leds || num_leds > MAX77650_NUM_LEDS)
> + return -ENODEV;
> +
> + for_each_child_of_node(of_node, child) {
> + rv = of_property_read_u32(child, "reg", ®);
> + if (rv || reg >= MAX77650_NUM_LEDS)
> + return -EINVAL;
> +
> + led = &leds[reg];
> + led->map = map;
> + led->regA = MAX77650_LED_A_BASE + reg;
> + led->regB = MAX77650_LED_B_BASE + reg;
> + led->cdev.brightness_set_blocking = max77650_led_brightness_set;
> +
> + label = of_get_property(child, "label", NULL);
> + if (!label) {
> + led->cdev.name = "max77650::";
> + } else {
> + led->cdev.name = devm_kasprintf(dev, GFP_KERNEL,
> + "max77650:%s", label);
> + if (!led->cdev.name)
> + return -ENOMEM;
> + }
> +
> + of_property_read_string(child, "linux,default-trigger",
> + &led->cdev.default_trigger);
> +
> + rv = devm_of_led_classdev_register(dev, child, &led->cdev);
> + if (rv)
> + return rv;
> +
> + rv = regmap_write(map, led->regA, MAX77650_LED_A_DEFAULT);
> + if (rv)
> + return rv;
> +
> + rv = regmap_write(map, led->regB, MAX77650_LED_B_DEFAULT);
> + if (rv)
> + return rv;
> + }
> +
> + return regmap_write(map,
> + MAX77650_REG_CNFG_LED_TOP,
> + MAX77650_LED_TOP_DEFAULT);
> +}
> +
> +static struct platform_driver max77650_led_driver = {
> + .driver = {
> + .name = "max77650-led",
> + },
> + .probe = max77650_led_probe,
> +};
> +module_platform_driver(max77650_led_driver);
> +
> +MODULE_DESCRIPTION("MAXIM 77650/77651 LED driver");
> +MODULE_AUTHOR("Bartosz Golaszewski <bgolaszewski@baylibre.com>");
> +MODULE_LICENSE("GPL v2");
>
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Re: [PATCH v2 05/13] dt-bindings: leds: add DT bindings for max77650
From: Jacek Anaszewski @ 2019-01-30 19:58 UTC (permalink / raw)
To: Bartosz Golaszewski, Rob Herring, Mark Rutland, Linus Walleij,
Dmitry Torokhov, Pavel Machek, Lee Jones, Sebastian Reichel,
Liam Girdwood, Mark Brown, Greg Kroah-Hartman
Cc: linux-kernel, linux-gpio, devicetree, linux-input, linux-leds,
linux-pm, Bartosz Golaszewski
In-Reply-To: <20190129133545.1931-7-brgl@bgdev.pl>
Hi Bartosz,
Thank you for addressing my remarks.
On 1/29/19 2:35 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> Add the DT binding document for the LEDs module of max77650.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> .../bindings/leds/leds-max77650.txt | 57 +++++++++++++++++++
> 1 file changed, 57 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/leds/leds-max77650.txt
>
> diff --git a/Documentation/devicetree/bindings/leds/leds-max77650.txt b/Documentation/devicetree/bindings/leds/leds-max77650.txt
> new file mode 100644
> index 000000000000..b2fac8e719a6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/leds-max77650.txt
> @@ -0,0 +1,57 @@
> +LED driver for MAX77650 PMIC from Maxim Integrated.
> +
> +This module is part of the MAX77650 MFD device. For more details
> +see Documentation/devicetree/bindings/mfd/max77650.txt.
> +
> +The LED controller is represented as a sub-node of the PMIC node on
> +the device tree.
> +
> +This device has three current sinks.
> +
> +Required properties:
> +--------------------
> +- compatible: Must be "maxim,max77650-led"
> +- #address-cells: Must be <1>.
> +- #size-cells: Must be <0>.
> +
> +Each LED is represented as a sub-node of the LED-controller node. Up to
> +three sub-nodes can be defined.
> +
> +Required properties of the sub-node:
> +------------------------------------
> +
> +- reg: Must be <0>, <1> or <2>.
> +
> +Optional properties of the sub-node:
> +------------------------------------
> +
> +- label: See Documentation/devicetree/bindings/leds/common.txt
> +- linux,default-trigger: See Documentation/devicetree/bindings/leds/common.txt
> +
> +For more details, please refer to the generic GPIO DT binding document
> +<devicetree/bindings/gpio/gpio.txt>.
> +
> +Example:
> +--------
> +
> + leds {
> + compatible = "maxim,max77650-leds";
s/leds/led/
With that:
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + led@0 {
> + reg = <0>;
> + label = "blue:usr0";
> + };
> +
> + led@1 {
> + reg = <1>;
> + label = "red:usr1";
> + linux,default-trigger = "heartbeat";
> + };
> +
> + led@2 {
> + reg = <2>;
> + label = "green:usr2";
> + };
> + };
>
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Re: [PATCH v2 12/13] input: max77650: add onkey support
From: Dmitry Torokhov @ 2019-01-30 18:53 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Rob Herring, Mark Rutland, Linus Walleij, Jacek Anaszewski,
Pavel Machek, Lee Jones, Sebastian Reichel, Liam Girdwood,
Mark Brown, Greg Kroah-Hartman, linux-kernel, linux-gpio,
devicetree, linux-input, linux-leds, linux-pm,
Bartosz Golaszewski
In-Reply-To: <20190129133545.1931-14-brgl@bgdev.pl>
On Tue, Jan 29, 2019 at 02:35:44PM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> Add support for the push- and slide-button events for max77650.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Please feel free to merge with other patches (MFD tree I suppose?).
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] doc: Change LXR references to elixir.bootlin.com
From: Martin Kepplinger @ 2019-01-30 18:16 UTC (permalink / raw)
To: Jonathan Neuschäfer, linux-doc
Cc: Stephen Boyd, Dmitry Torokhov, Jonathan Corbet, Federico Vaga,
Markus Heiser, Alessia Mantegazza, Michael Rodin, Minghui Liu,
Grigory Shipunov, Mathieu Poirier, Charles Keepax, Coly Li,
Mauro Carvalho Chehab, Matthias Brugger, Jeff Kirsher,
Guenter Roeck, Takashi Iwai, linux-input, linux-kernel
In-Reply-To: <20190130172528.7552-1-j.neuschaefer@gmx.net>
[-- Attachment #1: Type: text/plain, Size: 1582 bytes --]
Martin Kepplinger | Entwicklung Software
GINZINGER ELECTRONIC SYSTEMS GMBH
Tel.: +43 7723 5422 157
Mail: martin.kepplinger@ginzinger.com
Web: www.ginzinger.com
On 30.01.19 18:25, Jonathan Neuschäfer wrote:
> Recently, Free Electrons was renamed to Bootlin[1]. Less recently, the
> Linux Cross Reference (LXR) at lxr.free-electrons.com was replaced by
> Elixir[2], and lxr.free-electrons.com redirected first to
> elixir.free-electrons.com and now to elixir.bootlin.com.
>
> [1]: https://bootlin.com/blog/free-electrons-becomes-bootlin/
> [2]: https://github.com/free-electrons/elixir
>
> Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
> ---
>
> v2:
> - Fix ident search URL, as suggested by Martin Kepplinger
> - Add trailing slash, which I accidentally dropped in v1 in
> Documentation/translations/it_IT/process/howto.rst
>
Reviewed-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
thanks
________________________________________
Ginzinger electronic systems GmbH
Gewerbegebiet Pirath 16
4952 Weng im Innkreis
www.ginzinger.com
Firmenbuchnummer: FN 364958d
Firmenbuchgericht: Ried im Innkreis
UID-Nr.: ATU66521089
Diese Nachricht ist vertraulich und darf nicht an andere Personen weitergegeben oder von diesen verwendet werden. Verständigen Sie uns, wenn Sie irrtümlich eine Mitteilung empfangen haben.
This message is confidential. It may not be disclosed to, or used by, anyone other than the addressee. If you receive this message by mistake, please advise the sender.
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3616 bytes --]
^ permalink raw reply
* [PATCH v2] doc: Change LXR references to elixir.bootlin.com
From: Jonathan Neuschäfer @ 2019-01-30 17:25 UTC (permalink / raw)
To: linux-doc
Cc: Kepplinger Martin, Stephen Boyd, Jonathan Neuschäfer,
Dmitry Torokhov, Jonathan Corbet, Federico Vaga, Markus Heiser,
Alessia Mantegazza, Michael Rodin, Minghui Liu, Grigory Shipunov,
Mathieu Poirier, Charles Keepax, Coly Li, Mauro Carvalho Chehab,
Matthias Brugger, Jeff Kirsher
Recently, Free Electrons was renamed to Bootlin[1]. Less recently, the
Linux Cross Reference (LXR) at lxr.free-electrons.com was replaced by
Elixir[2], and lxr.free-electrons.com redirected first to
elixir.free-electrons.com and now to elixir.bootlin.com.
[1]: https://bootlin.com/blog/free-electrons-becomes-bootlin/
[2]: https://github.com/free-electrons/elixir
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
v2:
- Fix ident search URL, as suggested by Martin Kepplinger
- Add trailing slash, which I accidentally dropped in v1 in
Documentation/translations/it_IT/process/howto.rst
v1: https://lore.kernel.org/lkml/20190129142923.5743-1-j.neuschaefer@gmx.net/
---
Documentation/input/devices/xpad.rst | 2 +-
Documentation/process/howto.rst | 2 +-
Documentation/process/kernel-docs.rst | 2 +-
Documentation/translations/it_IT/process/howto.rst | 2 +-
Documentation/translations/ja_JP/howto.rst | 2 +-
Documentation/translations/ko_KR/howto.rst | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/input/devices/xpad.rst b/Documentation/input/devices/xpad.rst
index b8bd65962dd8..173c2acda9fd 100644
--- a/Documentation/input/devices/xpad.rst
+++ b/Documentation/input/devices/xpad.rst
@@ -218,7 +218,7 @@ References
.. [1] http://euc.jp/periphs/xbox-controller.ja.html (ITO Takayuki)
.. [2] http://xpad.xbox-scene.com/
.. [3] http://www.markosweb.com/www/xboxhackz.com/
-.. [4] http://lxr.free-electrons.com/ident?i=xpad_device
+.. [4] https://elixir.bootlin.com/linux/latest/ident/xpad_device
Historic Edits
diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
index 00c8ddd2ed2c..64deab5cfb3b 100644
--- a/Documentation/process/howto.rst
+++ b/Documentation/process/howto.rst
@@ -225,7 +225,7 @@ Cross-Reference project, which is able to present source code in a
self-referential, indexed webpage format. An excellent up-to-date
repository of the kernel code may be found at:
- http://lxr.free-electrons.com/
+ https://elixir.bootlin.com/
The development process
diff --git a/Documentation/process/kernel-docs.rst b/Documentation/process/kernel-docs.rst
index 3fb28de556e4..ab12dddc773e 100644
--- a/Documentation/process/kernel-docs.rst
+++ b/Documentation/process/kernel-docs.rst
@@ -565,7 +565,7 @@ Miscellaneous
* Name: **Cross-Referencing Linux**
- :URL: http://lxr.free-electrons.com/
+ :URL: https://elixir.bootlin.com/
:Keywords: Browsing source code.
:Description: Another web-based Linux kernel source code browser.
Lots of cross references to variables and functions. You can see
diff --git a/Documentation/translations/it_IT/process/howto.rst b/Documentation/translations/it_IT/process/howto.rst
index 909e6a55bc43..f9a44b1af89d 100644
--- a/Documentation/translations/it_IT/process/howto.rst
+++ b/Documentation/translations/it_IT/process/howto.rst
@@ -234,7 +234,7 @@ il progetto Linux Cross-Reference, che è in grado di presentare codice
sorgente in un formato autoreferenziale ed indicizzato. Un eccellente ed
aggiornata fonte di consultazione del codice del kernel la potete trovare qui:
- http://lxr.free-electrons.com/
+ https://elixir.bootlin.com/
Il processo di sviluppo
diff --git a/Documentation/translations/ja_JP/howto.rst b/Documentation/translations/ja_JP/howto.rst
index f3116381c26b..2ca9389d5915 100644
--- a/Documentation/translations/ja_JP/howto.rst
+++ b/Documentation/translations/ja_JP/howto.rst
@@ -245,7 +245,7 @@ Linux カーネルソースツリーの中に含まれる、きれいにし、
できます。この最新の素晴しいカーネルコードのリポジトリは以下で見つかり
ます -
- http://lxr.free-electrons.com/
+ https://elixir.bootlin.com/
開発プロセス
------------
diff --git a/Documentation/translations/ko_KR/howto.rst b/Documentation/translations/ko_KR/howto.rst
index a8197e072599..9fc869087e9c 100644
--- a/Documentation/translations/ko_KR/howto.rst
+++ b/Documentation/translations/ko_KR/howto.rst
@@ -235,7 +235,7 @@ ReST 마크업을 사용하는 문서들은 Documentation/output 에 생성된
소스코드를 인덱스된 웹 페이지들의 형태로 보여준다. 최신의 멋진 커널
코드 저장소는 다음을 통하여 참조할 수 있다.
- http://lxr.free-electrons.com/
+ https://elixir.bootlin.com/
개발 프로세스
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] gpio fixup domain
From: Linus Walleij @ 2019-01-30 9:42 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Rob Herring, Mark Rutland, Dmitry Torokhov, Jacek Anaszewski,
Pavel Machek, Lee Jones, Sebastian Reichel, Liam Girdwood,
Mark Brown, Greg Kroah-Hartman, Linux Kernel Mailing List,
open list:GPIO SUBSYSTEM, devicetree, Linux Input,
Linux LED Subsystem, Linux PM list, Bartosz Golaszewski
In-Reply-To: <CAMRc=Md4iTPi_i3EO5QT2SW1S2__8mMe22+9tcO7VUE2_hPNiw@mail.gmail.com>
On Tue, Jan 29, 2019 at 2:39 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> wt., 29 sty 2019 o 14:35 Bartosz Golaszewski <brgl@bgdev.pl> napisał(a):
>
> Please ignore this one, it got lost on the way. It was just experimentation.
Pretty interesting experiment anyways! Now both GPIO maintainers
know the intricacies of the hierarchical irq domains, which is a win
in itself when we try to come up with some generic handling here.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 10/13] gpio: max77650: add GPIO support
From: Linus Walleij @ 2019-01-30 9:40 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Rob Herring, Mark Rutland, Dmitry Torokhov, Jacek Anaszewski,
Pavel Machek, Lee Jones, Sebastian Reichel, Liam Girdwood,
Mark Brown, Greg Kroah-Hartman, linux-kernel@vger.kernel.org,
open list:GPIO SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Input, Linux LED Subsystem, Linux PM list,
Bartosz Golaszewski
In-Reply-To: <20190129133545.1931-12-brgl@bgdev.pl>
On Tue, Jan 29, 2019 at 2:36 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> Add GPIO support for max77650 mfd device. This PMIC exposes a single
> GPIO line.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [bug report] Input: add st-keyscan driver
From: Gabriel FERNANDEZ @ 2019-01-30 8:58 UTC (permalink / raw)
To: Ken Sloat, Dmitry Torokhov
Cc: Dan Carpenter, linux-input, lkml, Nate Drude, Giuseppe CONDORELLI
In-Reply-To: <CAPo_4QCMX+oYw2ZcBgSiLcEzgTJMJB=E-xdXWe_Xg2a=FmQ+Rg@mail.gmail.com>
Hi all,
I prefer to fix it. I guess people used their own correction.
I will send you a fix asap.
Best Regards
Gabriel
On 1/27/19 2:20 AM, Ken Sloat wrote:
> On Sat, Jan 26, 2019 at 5:15 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
>> On Sat, Jan 26, 2019 at 1:25 PM Ken Sloat
>> <ken.sloat@ohmlinxelectronics.com> wrote:
>>> On Tue, Jan 22, 2019 at 1:53 PM Dan Carpenter <dan.carpenter@oracle.com> wrote:
>>>> Hello Gabriel FERNANDEZ,
>>> Hello Dan,
>>>
>>> I have added CCs for the maintainers as well as Gabriel Fernandez as
>>> currently you just have the linux-input mailing list
>>>
>>>> The patch 062589b13991: "Input: add st-keyscan driver" from Apr 12,
>>>> 2014, leads to the following static checker warning:
>>>>
>>>> drivers/input/keyboard/st-keyscan.c:156 keyscan_probe()
>>>> error: potential zalloc NULL dereference: 'keypad_data->input_dev'
>>>>
>>>> drivers/input/keyboard/st-keyscan.c
>>>> 125 static int keyscan_probe(struct platform_device *pdev)
>>>> 126 {
>>>> 127 struct st_keyscan *keypad_data;
>>>> 128 struct input_dev *input_dev;
>>>> 129 struct resource *res;
>>>> 130 int error;
>>>> 131
>>>> 132 if (!pdev->dev.of_node) {
>>>> 133 dev_err(&pdev->dev, "no DT data present\n");
>>>> 134 return -EINVAL;
>>>> 135 }
>>>> 136
>>>> 137 keypad_data = devm_kzalloc(&pdev->dev, sizeof(*keypad_data),
>>>> 138 GFP_KERNEL);
>>>> 139 if (!keypad_data)
>>>> 140 return -ENOMEM;
>>>> 141
>>>> 142 input_dev = devm_input_allocate_device(&pdev->dev);
>>>> 143 if (!input_dev) {
>>>> 144 dev_err(&pdev->dev, "failed to allocate the input device\n");
>>>> 145 return -ENOMEM;
>>>> 146 }
>>>> 147
>>>> 148 input_dev->name = pdev->name;
>>>> 149 input_dev->phys = "keyscan-keys/input0";
>>>> 150 input_dev->dev.parent = &pdev->dev;
>>>> 151 input_dev->open = keyscan_open;
>>>> 152 input_dev->close = keyscan_close;
>>>> 153
>>>> 154 input_dev->id.bustype = BUS_HOST;
>>>> 155
>>>> --> 156 error = keypad_matrix_key_parse_dt(keypad_data);
>>>> ^^^^^^^^^^^
>>> I agree with you this would be a problem
>>> to clarify the NULL derefence would occur here within keypad_matrix_key_parse_dt
>>>
>>> struct device *dev = keypad_data->input_dev->dev.parent;
>>>
>>>> This assumes we have set "keypad_data->input_dev = input_dev;" but we
>>>> don't do that until...
>>>>
>>>> 157 if (error)
>>>> 158 return error;
>>>> 159
>>>> 160 error = matrix_keypad_build_keymap(NULL, NULL,
>>>> 161 keypad_data->n_rows,
>>>> 162 keypad_data->n_cols,
>>>> 163 NULL, input_dev);
>>>> 164 if (error) {
>>>> 165 dev_err(&pdev->dev, "failed to build keymap\n");
>>>> 166 return error;
>>>> 167 }
>>>> 168
>>>> 169 input_set_drvdata(input_dev, keypad_data);
>>>> 170
>>>> 171 keypad_data->input_dev = input_dev;
>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>
>>>> this line here. This driver has never worked and it was included almost
>>>> five years ago. Is it worth fixing?
>>>>
>>>> 172
>>>> 173 res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>> 174 keypad_data->base = devm_ioremap_resource(&pdev->dev, res);
>>>> 175 if (IS_ERR(keypad_data->base))
>>>> 176 return PTR_ERR(keypad_data->base);
>>>> 177
>>>>
>>>> regards,
>>>> dan carpenter
>>>>
>>> Here is the interesting thing, I was looking on patchwork, and several
>>> of the patches including what appears to be the latest actually set
>>> "keypad_data->input_dev = input_dev" before calling
>>> "keypad_matrix_key_parse_dt"
>>>
>>> From v4 on patchwork
>>> + if (IS_ERR(keypad_data->clk)) {
>>> + dev_err(&pdev->dev, "cannot get clock");
>>> + return PTR_ERR(keypad_data->clk);
>>> + }
>>> +
>>> + keypad_data->input_dev = input_dev;
>>> +
>>> + input_dev->name = pdev->name;
>>> + input_dev->phys = "keyscan-keys/input0";
>>> + input_dev->dev.parent = &pdev->dev;
>>> + input_dev->open = keyscan_open;
>>> + input_dev->close = keyscan_close;
>>> +
>>> + input_dev->id.bustype = BUS_HOST;
>>> +
>>> + error = keypad_matrix_key_parse_dt(keypad_data);
>>>
>>> According to patchwork, these aren't listed as accepted, so I'm not
>>> sure where the exact accepted patch came from. Looking at the commit
>>> log, it looks like the issue you showed above was made in the original
>>> commit 062589b1399176a9c14bc68e16169f40439d658c so I'm not quite sure
>>> what is going on here. Maybe the maintainer can chime in with the
>>> original patch/mailing list discussion on this. For reference, I've
>>> added the patchwork links below
>>> https://patchwork.kernel.org/patch/3854341/
>>> https://patchwork.kernel.org/patch/3968891/
>>> https://patchwork.kernel.org/patch/3969991/
>> It may very well be that I messed up when applying the patch. I guess
>> whatever platform that is using the driver has not attempted to update
>> their kernel since then.
>>
>> Thanks.
>>
>> --
>> Dmitry
> Hi Dmitry,
>
> Thanks for the quick response. Yes I was just looking at the other
> mailing lists patchwork and while comments were missing on the
> linux-input list for the v4 patch, there was a discussion on the
> regular kernel mailing list:
> https://lore.kernel.org/patchwork/patch/455450/#630445
>
> It looks like you told him he didn't need to submit a v5 but generated
> one based on the changes suggested in the discussion:
>
> [begin quote]
> On Wed, Apr 16, 2014 at 10:49:29AM +0200, Gabriel Fernandez wrote:
>> On 13 April 2014 07:10, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
>>> Does the version of the patch below still work for you?
>>>
>> Yes it's was tested on b2000 and b2089 sti boards.
>>
>>> Thanks.
>>>
>>> --
>>> Dmitry
>>>
>> Thanks for yours remarks, i will prepare a v5 versions.
>
> If the version I sent to you works then you do not need to prepare v5,
> I'll just apply what I have.
>
> Thanks!
> [end quote]
>
> So I guess Dan's original question remains, should this be fixed
> considering it's so old and apparently nobody could possibly be using
> it in the kernel since it doesn't work (in which case the driver
> should probably be dropped) or should we fix it?
>
> Thanks,
> Ken Sloat
^ permalink raw reply
* Re: [PATCH v3] HID: i2c-hid: Ignore input report if there's no data present on Elan touchpanels
From: Kai-Heng Feng @ 2019-01-30 3:50 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Jiri Kosina, open list:HID CORE LAYER, lkml
In-Reply-To: <CAO-hwJ+CF-obuUK9T=x0ggJRLBNmM3H6-FfKjv2y0LT96C=TUg@mail.gmail.com>
> On Jan 29, 2019, at 18:05, Benjamin Tissoires <benjamin.tissoires@redhat.com> wrote:
>
> On Mon, Jan 21, 2019 at 4:30 AM Kai-Heng Feng
> <kai.heng.feng@canonical.com> wrote:
>>
>>
>>
>>> On Jan 18, 2019, at 23:50, Benjamin Tissoires <benjamin.tissoires@redhat.com> wrote:
>>>
>>> Hi Kai-Heng,
>>>
>>> On Mon, Jan 7, 2019 at 8:24 AM Kai-Heng Feng
>>> <kai.heng.feng@canonical.com> wrote:
>>>>
>>>> While using Elan touchpads, the message floods:
>>>> [ 136.138487] i2c_hid i2c-DELL08D6:00: i2c_hid_get_input: incomplete report (14/65535)
>>>>
>>>> Though the message flood is annoying, the device it self works without
>>>> any issue. I suspect that the device in question takes too much time to
>>>> pull the IRQ back to high after I2C host has done reading its data.
>>>>
>>>> Since the host receives all useful data, let's ignore the input report
>>>> when there's no data.
>>>>
>>>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
>>>
>>> Thanks for the v3.
>>>
>>> This patch has just been brought to my attention, and I have one
>>> question before applying it:
>>> are those messages (without your patch) occurring all the time, or
>>> just after resume?
>>
>> All the time.
>>
>> The touchpad works fine though. The entire report is 0xff, so it can be
>> safely ignored.
>
> Couple of things:
> - I have forgotten to tell you that I have applied this patch in
> for-5.1/i2c-hid, it will be pushed to linux-next today.
Thanks!
> - Dell told me that a BIOS fix was solving the issue. We can still
> quarry the patch, but there should not be a strong need for it when
> users upgrade their BIOS.
Multiple platforms are affected by this issue [1], so the patch can still be really helpful.
[1] https://bugs.launchpad.net/bugs/1784152
Kai-Heng
>
> Cheers,
> Benjamin
>
>>
>>>
>>> I wonder if the pm_suspend delay we talked about in the other thread
>>> would fix that issue in a cleaner way.
>>
>> I’ve replied in another thread, unfortunately it can’t.
>>
>> We can introduce msleep() between each commands though, but I don’t
>> think it’s good either.
>>
>> Kai-Heng
>>
>>>
>>> Cheers,
>>> Benjamin
>>>
>>>> ---
>>>> v3:
>>>> Fix compiler error/warnings.
>>>>
>>>> v2:
>>>> Use dev_warn_once() to warn the user about the situation.
>>>>
>>>> drivers/hid/i2c-hid/i2c-hid-core.c | 9 +++++++++
>>>> 1 file changed, 9 insertions(+)
>>>>
>>>> diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
>>>> index 8555ce7e737b..2f940c1de616 100644
>>>> --- a/drivers/hid/i2c-hid/i2c-hid-core.c
>>>> +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
>>>> @@ -50,6 +50,7 @@
>>>> #define I2C_HID_QUIRK_NO_IRQ_AFTER_RESET BIT(1)
>>>> #define I2C_HID_QUIRK_NO_RUNTIME_PM BIT(2)
>>>> #define I2C_HID_QUIRK_DELAY_AFTER_SLEEP BIT(3)
>>>> +#define I2C_HID_QUIRK_BOGUS_IRQ BIT(4)
>>>>
>>>> /* flags */
>>>> #define I2C_HID_STARTED 0
>>>> @@ -179,6 +180,8 @@ static const struct i2c_hid_quirks {
>>>> I2C_HID_QUIRK_DELAY_AFTER_SLEEP },
>>>> { USB_VENDOR_ID_LG, I2C_DEVICE_ID_LG_8001,
>>>> I2C_HID_QUIRK_NO_RUNTIME_PM },
>>>> + { USB_VENDOR_ID_ELAN, HID_ANY_ID,
>>>> + I2C_HID_QUIRK_BOGUS_IRQ },
>>>> { 0, 0 }
>>>> };
>>>>
>>>> @@ -503,6 +506,12 @@ static void i2c_hid_get_input(struct i2c_hid *ihid)
>>>> return;
>>>> }
>>>>
>>>> + if (ihid->quirks & I2C_HID_QUIRK_BOGUS_IRQ && ret_size == 0xffff) {
>>>> + dev_warn_once(&ihid->client->dev, "%s: IRQ triggered but "
>>>> + "there's no data\n", __func__);
>>>> + return;
>>>> + }
>>>> +
>>>> if ((ret_size > size) || (ret_size < 2)) {
>>>> dev_err(&ihid->client->dev, "%s: incomplete report (%d/%d)\n",
>>>> __func__, size, ret_size);
>>>> --
>>>> 2.17.1
^ permalink raw reply
* Re: [PATCH] doc: Change LXR references to elixir.bootlin.com
From: Jonathan Neuschäfer @ 2019-01-29 15:27 UTC (permalink / raw)
To: Kepplinger Martin
Cc: Jonathan Neuschäfer, linux-doc@vger.kernel.org,
Dmitry Torokhov, Jonathan Corbet, Federico Vaga, Markus Heiser,
Minghui Liu, Michael Rodin, Grigory Shipunov, Alessia Mantegazza,
Stephen Boyd, Mauro Carvalho Chehab, Takashi Iwai,
Matthias Brugger, Guenter Roeck, Jeff Kirsher,
linux-input@vger.kernel.org
In-Reply-To: <2755754cdd8e4bd3956648f9fb6315c2@ginzinger.com>
[-- Attachment #1: Type: text/plain, Size: 432 bytes --]
On Tue, Jan 29, 2019 at 03:01:18PM +0000, Kepplinger Martin wrote:
[...]
> -.. [4] http://lxr.free-electrons.com/ident?i=xpad_device
> +.. [4] https://elixir.bootlin.com/ident?i=xpad_device
>
> that seems to be wrong. I think it's https://elixir.bootlin.com/linux/latest/ident/xpad_device
Oops. Indeed, it doesn't work with the old syntax. I'll fix this in v2.
> other than that, good.
Thanks,
Jonathan Neuschäfer
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* AW: [PATCH] doc: Change LXR references to elixir.bootlin.com
From: Kepplinger Martin @ 2019-01-29 15:01 UTC (permalink / raw)
To: Jonathan Neuschäfer, linux-doc@vger.kernel.org
Cc: Dmitry Torokhov, Jonathan Corbet, Federico Vaga, Markus Heiser,
Minghui Liu, Michael Rodin, Grigory Shipunov, Alessia Mantegazza,
Stephen Boyd, Mauro Carvalho Chehab, Takashi Iwai,
Matthias Brugger, Guenter Roeck, Jeff Kirsher,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20190129142923.5743-1-j.neuschaefer@gmx.net>
[-- Attachment #1: Type: text/plain, Size: 2197 bytes --]
________________________________________
Von: linux-input-owner@vger.kernel.org [linux-input-owner@vger.kernel.org] im Auftrag von Jonathan Neuschäfer [j.neuschaefer@gmx.net]
Gesendet: Dienstag, 29. Jänner 2019 15:29
An: linux-doc@vger.kernel.org
Cc: Jonathan Neuschäfer; Dmitry Torokhov; Jonathan Corbet; Federico Vaga; Markus Heiser; Minghui Liu; Michael Rodin; Grigory Shipunov; Alessia Mantegazza; Stephen Boyd; Mauro Carvalho Chehab; Takashi Iwai; Matthias Brugger; Guenter Roeck; Jeff Kirsher; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org
Betreff: [PATCH] doc: Change LXR references to elixir.bootlin.com
Recently, Free Electrons was renamed to Bootlin[1]. Less recently, the
Linux Cross Reference (LXR) at lxr.free-electrons.com was replaced by
Elixir[2], and lxr.free-electrons.com redirected first to
elixir.free-electrons.com and now to elixir.bootlin.com.
[1]: https://bootlin.com/blog/free-electrons-becomes-bootlin/
[2]: https://github.com/free-electrons/elixir
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
Documentation/input/devices/xpad.rst | 2 +-
Documentation/process/howto.rst | 2 +-
Documentation/process/kernel-docs.rst | 2 +-
Documentation/translations/it_IT/process/howto.rst | 2 +-
Documentation/translations/ja_JP/howto.rst | 2 +-
Documentation/translations/ko_KR/howto.rst | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/input/devices/xpad.rst b/Documentation/input/devices/xpad.rst
index b8bd65962dd8..95d410b27a96 100644
--- a/Documentation/input/devices/xpad.rst
+++ b/Documentation/input/devices/xpad.rst
@@ -218,7 +218,7 @@ References
.. [1] http://euc.jp/periphs/xbox-controller.ja.html (ITO Takayuki)
.. [2] http://xpad.xbox-scene.com/
.. [3] http://www.markosweb.com/www/xboxhackz.com/
-.. [4] http://lxr.free-electrons.com/ident?i=xpad_device
+.. [4] https://elixir.bootlin.com/ident?i=xpad_device
that seems to be wrong. I think it's https://elixir.bootlin.com/linux/latest/ident/xpad_device
other than that, good.
thanks,
martin
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3616 bytes --]
^ permalink raw reply related
* [PATCH] doc: Change LXR references to elixir.bootlin.com
From: Jonathan Neuschäfer @ 2019-01-29 14:29 UTC (permalink / raw)
To: linux-doc
Cc: Jonathan Neuschäfer, Dmitry Torokhov, Jonathan Corbet,
Federico Vaga, Markus Heiser, Minghui Liu, Michael Rodin,
Grigory Shipunov, Alessia Mantegazza, Stephen Boyd,
Mauro Carvalho Chehab, Takashi Iwai, Matthias Brugger,
Guenter Roeck, Jeff Kirsher, linux-input, linux-kernel
Recently, Free Electrons was renamed to Bootlin[1]. Less recently, the
Linux Cross Reference (LXR) at lxr.free-electrons.com was replaced by
Elixir[2], and lxr.free-electrons.com redirected first to
elixir.free-electrons.com and now to elixir.bootlin.com.
[1]: https://bootlin.com/blog/free-electrons-becomes-bootlin/
[2]: https://github.com/free-electrons/elixir
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
Documentation/input/devices/xpad.rst | 2 +-
Documentation/process/howto.rst | 2 +-
Documentation/process/kernel-docs.rst | 2 +-
Documentation/translations/it_IT/process/howto.rst | 2 +-
Documentation/translations/ja_JP/howto.rst | 2 +-
Documentation/translations/ko_KR/howto.rst | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/input/devices/xpad.rst b/Documentation/input/devices/xpad.rst
index b8bd65962dd8..95d410b27a96 100644
--- a/Documentation/input/devices/xpad.rst
+++ b/Documentation/input/devices/xpad.rst
@@ -218,7 +218,7 @@ References
.. [1] http://euc.jp/periphs/xbox-controller.ja.html (ITO Takayuki)
.. [2] http://xpad.xbox-scene.com/
.. [3] http://www.markosweb.com/www/xboxhackz.com/
-.. [4] http://lxr.free-electrons.com/ident?i=xpad_device
+.. [4] https://elixir.bootlin.com/ident?i=xpad_device
Historic Edits
diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
index 58b2f46c4f98..bdd2eda81a1c 100644
--- a/Documentation/process/howto.rst
+++ b/Documentation/process/howto.rst
@@ -225,7 +225,7 @@ Cross-Reference project, which is able to present source code in a
self-referential, indexed webpage format. An excellent up-to-date
repository of the kernel code may be found at:
- http://lxr.free-electrons.com/
+ https://elixir.bootlin.com/
The development process
diff --git a/Documentation/process/kernel-docs.rst b/Documentation/process/kernel-docs.rst
index 3fb28de556e4..ab12dddc773e 100644
--- a/Documentation/process/kernel-docs.rst
+++ b/Documentation/process/kernel-docs.rst
@@ -565,7 +565,7 @@ Miscellaneous
* Name: **Cross-Referencing Linux**
- :URL: http://lxr.free-electrons.com/
+ :URL: https://elixir.bootlin.com/
:Keywords: Browsing source code.
:Description: Another web-based Linux kernel source code browser.
Lots of cross references to variables and functions. You can see
diff --git a/Documentation/translations/it_IT/process/howto.rst b/Documentation/translations/it_IT/process/howto.rst
index 909e6a55bc43..b323c4b309a5 100644
--- a/Documentation/translations/it_IT/process/howto.rst
+++ b/Documentation/translations/it_IT/process/howto.rst
@@ -234,7 +234,7 @@ il progetto Linux Cross-Reference, che è in grado di presentare codice
sorgente in un formato autoreferenziale ed indicizzato. Un eccellente ed
aggiornata fonte di consultazione del codice del kernel la potete trovare qui:
- http://lxr.free-electrons.com/
+ https://elixir.bootlin.com
Il processo di sviluppo
diff --git a/Documentation/translations/ja_JP/howto.rst b/Documentation/translations/ja_JP/howto.rst
index f3116381c26b..2ca9389d5915 100644
--- a/Documentation/translations/ja_JP/howto.rst
+++ b/Documentation/translations/ja_JP/howto.rst
@@ -245,7 +245,7 @@ Linux カーネルソースツリーの中に含まれる、きれいにし、
できます。この最新の素晴しいカーネルコードのリポジトリは以下で見つかり
ます -
- http://lxr.free-electrons.com/
+ https://elixir.bootlin.com/
開発プロセス
------------
diff --git a/Documentation/translations/ko_KR/howto.rst b/Documentation/translations/ko_KR/howto.rst
index a8197e072599..9fc869087e9c 100644
--- a/Documentation/translations/ko_KR/howto.rst
+++ b/Documentation/translations/ko_KR/howto.rst
@@ -235,7 +235,7 @@ ReST 마크업을 사용하는 문서들은 Documentation/output 에 생성된
소스코드를 인덱스된 웹 페이지들의 형태로 보여준다. 최신의 멋진 커널
코드 저장소는 다음을 통하여 참조할 수 있다.
- http://lxr.free-electrons.com/
+ https://elixir.bootlin.com/
개발 프로세스
--
2.20.1
^ 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