* Re: [PATCH 00/10] Move part of cros-ec out of MFD subsystem
From: Andy Shevchenko @ 2019-06-04 16:07 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: Kate Stewart, Enno Luebbers, gwendal, Banajit Goswami,
Heiko Stuebner, Alexandre Belloni, linux-doc, Wolfram Sang,
Mark Brown, Manivannan Sadhasivam, Juergen Fitschen, alsa-devel,
Stefan Agner, Sebastian Reichel, Jilayne Lovejoy,
Benjamin Tissoires, Dmitry Torokhov, linux-i2c,
Peter Meerwald-Stadler, Dong Aisheng, Guenter Roeck,
Lorenzo Pieralisi, Ravi Chandra Sadineni <rav>
In-Reply-To: <20190604152019.16100-1-enric.balletbo@collabora.com>
On Tue, Jun 04, 2019 at 05:20:09PM +0200, Enric Balletbo i Serra wrote:
> Hi,
>
> This is the first attempt to clean up a bit more the cros-ec drivers
> to have a better separation on what is part of the MFD subsystem and what
> is part of platform/chrome.
>
> It'd be really nice have some reviews, acks and tested on different
> platforms from the chromiumos people before merge all this patchset, as
> this moves a lot of code.
>
> The major changes introduced by this patchset are:
> 1. Move the core driver to platform/chrome, as is not really related to
> an MFD device driver.
> 2. Create a new misc chardev driver to replace the chardev bits from
> cros-ec-dev (MFD)
> 3. Added some convenience structs in cros-ec-dev (MFD) to easy add more
> subdrivers and avoid to add more boiler plate.
>
> Once applied we have moved all the code to platform/chrome except the
> cros-ec-dev driver, which is the one that instantiates the different
> subdrivers as cells of the MFD device.
>
> I tested the following patches on Veyron, Kevin, Samus, Peach Pi and
> Peach Pit without noticing any problem, but they would need a lot of
> more tests. I'll continue testing while the reviewing process of this
> patchset.
>
If my tag helps, here it is:
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Waiting for your feedback,
> Enric
>
>
> Enric Balletbo i Serra (10):
> mfd / platform: cros_ec: Handle chained ECs as platform devices
> mfd / platform: cros_ec: Move cros-ec core driver out from MFD
> mfd / platform: cros_ec: Miscellaneous character device to talk with
> the EC
> mfd: cros_ec: Switch to use the new cros-ec-chardev driver
> mfd / platform: cros_ec: Rename config to a better name
> mfd / platform: cros_ec: Reorganize platform and mfd includes
> mfd: cros_ec: Update with SPDX Licence identifier and fix description
> mfd: cros_ec: Use kzalloc and cros_ec_cmd_xfer_status helper
> mfd: cros_ec: Add convenience struct to define dedicated CrOS EC MCUs
> mfd: cros_ec: Add convenience struct to define autodetectable CrOS EC
> subdevices
>
> Documentation/ioctl/ioctl-number.txt | 2 +-
> drivers/extcon/Kconfig | 2 +-
> drivers/extcon/extcon-usbc-cros-ec.c | 3 +-
> drivers/hid/Kconfig | 2 +-
> drivers/hid/hid-google-hammer.c | 4 +-
> drivers/i2c/busses/Kconfig | 2 +-
> drivers/i2c/busses/i2c-cros-ec-tunnel.c | 4 +-
> drivers/iio/accel/cros_ec_accel_legacy.c | 3 +-
> drivers/iio/common/cros_ec_sensors/Kconfig | 2 +-
> .../common/cros_ec_sensors/cros_ec_sensors.c | 3 +-
> .../cros_ec_sensors/cros_ec_sensors_core.c | 3 +-
> drivers/iio/light/cros_ec_light_prox.c | 3 +-
> drivers/iio/pressure/cros_ec_baro.c | 3 +-
> drivers/input/keyboard/Kconfig | 2 +-
> drivers/input/keyboard/cros_ec_keyb.c | 4 +-
> drivers/media/platform/Kconfig | 3 +-
> .../media/platform/cros-ec-cec/cros-ec-cec.c | 4 +-
> drivers/mfd/Kconfig | 26 +-
> drivers/mfd/Makefile | 4 +-
> drivers/mfd/cros_ec_dev.c | 433 +++++-------------
> drivers/platform/chrome/Kconfig | 48 +-
> drivers/platform/chrome/Makefile | 2 +
> drivers/{mfd => platform/chrome}/cros_ec.c | 64 +--
> drivers/platform/chrome/cros_ec_chardev.c | 279 +++++++++++
> drivers/platform/chrome/cros_ec_debugfs.c | 3 +-
> drivers/platform/chrome/cros_ec_i2c.c | 12 +-
> drivers/platform/chrome/cros_ec_lightbar.c | 3 +-
> drivers/platform/chrome/cros_ec_lpc.c | 7 +-
> drivers/platform/chrome/cros_ec_lpc_reg.c | 4 +-
> drivers/platform/chrome/cros_ec_proto.c | 3 +-
> drivers/platform/chrome/cros_ec_rpmsg.c | 6 +-
> drivers/platform/chrome/cros_ec_spi.c | 12 +-
> drivers/platform/chrome/cros_ec_sysfs.c | 3 +-
> drivers/platform/chrome/cros_ec_trace.c | 2 +-
> drivers/platform/chrome/cros_ec_trace.h | 4 +-
> drivers/platform/chrome/cros_ec_vbc.c | 3 +-
> drivers/platform/chrome/cros_usbpd_logger.c | 5 +-
> drivers/power/supply/Kconfig | 2 +-
> drivers/power/supply/cros_usbpd-charger.c | 5 +-
> drivers/pwm/Kconfig | 2 +-
> drivers/pwm/pwm-cros-ec.c | 4 +-
> drivers/rtc/Kconfig | 2 +-
> drivers/rtc/rtc-cros-ec.c | 3 +-
> .../linux/iio/common/cros_ec_sensors_core.h | 3 +-
> include/linux/mfd/cros_ec.h | 302 +-----------
> .../{mfd => platform_data}/cros_ec_commands.h | 0
> include/linux/platform_data/cros_ec_proto.h | 315 +++++++++++++
> .../uapi/linux/cros_ec_chardev.h | 18 +-
> sound/soc/codecs/cros_ec_codec.c | 4 +-
> sound/soc/qcom/Kconfig | 2 +-
> 50 files changed, 902 insertions(+), 732 deletions(-)
> rename drivers/{mfd => platform/chrome}/cros_ec.c (85%)
> create mode 100644 drivers/platform/chrome/cros_ec_chardev.c
> rename include/linux/{mfd => platform_data}/cros_ec_commands.h (100%)
> create mode 100644 include/linux/platform_data/cros_ec_proto.h
> rename drivers/mfd/cros_ec_dev.h => include/uapi/linux/cros_ec_chardev.h (70%)
>
> --
> 2.20.1
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: input: sun4i-lradc-keys: Add A64 compatible
From: Luca Weiss @ 2019-06-04 17:21 UTC (permalink / raw)
Cc: Luca Weiss, Hans de Goede, Dmitry Torokhov, Rob Herring,
Mark Rutland, Maxime Ripard, Chen-Yu Tsai,
open list:SUN4I LOW RES ADC ATTACHED TABLET KEYS DRIVER,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/Allwinner sunXi SoC support, open list,
~martijnbraam/pmos-upstream
Add the A64 compatible with a fallback to the A83T compatible.
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
---
Changes from v1:
- New patch. Document new compatible string.
Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt b/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
index 496125c6bfb7..507b737612ea 100644
--- a/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
+++ b/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
@@ -5,6 +5,7 @@ Required properties:
- compatible: should be one of the following string:
"allwinner,sun4i-a10-lradc-keys"
"allwinner,sun8i-a83t-r-lradc"
+ "allwinner,sun50i-a64-lradc", "allwinner,sun8i-a83t-r-lradc"
- reg: mmio address range of the chip
- interrupts: interrupt to which the chip is connected
- vref-supply: powersupply for the lradc reference voltage
--
2.21.0
^ permalink raw reply related
* [PATCH v2 2/2] arm64: dts: allwinner: a64: Add lradc node
From: Luca Weiss @ 2019-06-04 17:21 UTC (permalink / raw)
Cc: Luca Weiss, Hans de Goede, Dmitry Torokhov, Rob Herring,
Mark Rutland, Maxime Ripard, Chen-Yu Tsai,
open list:SUN4I LOW RES ADC ATTACHED TABLET KEYS DRIVER,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/Allwinner sunXi SoC support, open list,
~martijnbraam/pmos-upstream
In-Reply-To: <20190604172154.25472-1-luca@z3ntu.xyz>
Add a node describing the KEYADC on the A64.
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
---
Changes since v1:
- Use a a64 compatible with a fallback to the a83t one (the A64 also
uses a 3/4 voltage divider, as is the case with the A83T)
- Correct the reg property (size 0x100 => 0x400)
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 8c5b521e6389..ba0ab1045e00 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -730,6 +730,14 @@
status = "disabled";
};
+ lradc: lradc@1c21800 {
+ compatible = "allwinner,sun50i-a64-lradc",
+ "allwinner,sun8i-a83t-r-lradc";
+ reg = <0x01c21800 0x400>;
+ interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
i2s0: i2s@1c22000 {
#sound-dai-cells = <0>;
compatible = "allwinner,sun50i-a64-i2s",
--
2.21.0
^ permalink raw reply related
* Re: hid-related 5.2-rc1 boot hang
From: Jiri Kosina @ 2019-06-04 21:08 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Hans de Goede, Dave Hansen, open list:HID CORE LAYER, LKML
In-Reply-To: <CAO-hwJJWWRf8cCLCB3JdfFGCGPnp9ar9HC_QAg7crJ0y+pA-hg@mail.gmail.com>
On Tue, 4 Jun 2019, Benjamin Tissoires wrote:
> > Which should fix this. It is quite simple and safe, so if we get testing
> > feedback relatively soon, we could go with the fix instead of dropping the
> > product-id, your call.
>
> I should receive the M280 tomorrow, hopefully with the C52F. If the
> receiver is correct and the tests are successful, I'd prefer to take
> this one over the revert :)
Agreed at this release phase. And if it doesn't work, immediate revert for
now and proper fix for 5.3-rc1.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 00/10] Move part of cros-ec out of MFD subsystem
From: Randy Dunlap @ 2019-06-04 22:18 UTC (permalink / raw)
To: Enric Balletbo i Serra, linux-kernel
Cc: Kate Stewart, Enno Luebbers, gwendal, Banajit Goswami,
Heiko Stuebner, Alexandre Belloni, linux-doc, Wolfram Sang,
Mark Brown, Juergen Fitschen, alsa-devel, Stefan Agner,
Douglas Anderson, Jilayne Lovejoy, Benjamin Tissoires,
Guido Kiener, linux-i2c, Peter Meerwald-Stadler,
Manivannan Sadhasivam, Guenter Roeck, Lorenzo Pieralisi,
Ravi Chandra Sadineni, kernel
In-Reply-To: <20190604152019.16100-1-enric.balletbo@collabora.com>
On 6/4/19 8:20 AM, Enric Balletbo i Serra wrote:
> Hi,
>
> This is the first attempt to clean up a bit more the cros-ec drivers
> to have a better separation on what is part of the MFD subsystem and what
> is part of platform/chrome.
>
> It'd be really nice have some reviews, acks and tested on different
> platforms from the chromiumos people before merge all this patchset, as
> this moves a lot of code.
>
> The major changes introduced by this patchset are:
> 1. Move the core driver to platform/chrome, as is not really related to
> an MFD device driver.
> 2. Create a new misc chardev driver to replace the chardev bits from
> cros-ec-dev (MFD)
> 3. Added some convenience structs in cros-ec-dev (MFD) to easy add more
> subdrivers and avoid to add more boiler plate.
>
> Once applied we have moved all the code to platform/chrome except the
> cros-ec-dev driver, which is the one that instantiates the different
> subdrivers as cells of the MFD device.
>
> I tested the following patches on Veyron, Kevin, Samus, Peach Pi and
> Peach Pit without noticing any problem, but they would need a lot of
> more tests. I'll continue testing while the reviewing process of this
> patchset.
>
> Waiting for your feedback,
> Enric
>
Hi,
Was there a patch 02/10? I didn't see it.
What mailing list(s) was it sent to?
thanks.
>
> Enric Balletbo i Serra (10):
> mfd / platform: cros_ec: Handle chained ECs as platform devices
> mfd / platform: cros_ec: Move cros-ec core driver out from MFD
> mfd / platform: cros_ec: Miscellaneous character device to talk with
> the EC
> mfd: cros_ec: Switch to use the new cros-ec-chardev driver
> mfd / platform: cros_ec: Rename config to a better name
> mfd / platform: cros_ec: Reorganize platform and mfd includes
> mfd: cros_ec: Update with SPDX Licence identifier and fix description
> mfd: cros_ec: Use kzalloc and cros_ec_cmd_xfer_status helper
> mfd: cros_ec: Add convenience struct to define dedicated CrOS EC MCUs
> mfd: cros_ec: Add convenience struct to define autodetectable CrOS EC
> subdevices
>
> Documentation/ioctl/ioctl-number.txt | 2 +-
> drivers/extcon/Kconfig | 2 +-
> drivers/extcon/extcon-usbc-cros-ec.c | 3 +-
> drivers/hid/Kconfig | 2 +-
> drivers/hid/hid-google-hammer.c | 4 +-
> drivers/i2c/busses/Kconfig | 2 +-
> drivers/i2c/busses/i2c-cros-ec-tunnel.c | 4 +-
> drivers/iio/accel/cros_ec_accel_legacy.c | 3 +-
> drivers/iio/common/cros_ec_sensors/Kconfig | 2 +-
> .../common/cros_ec_sensors/cros_ec_sensors.c | 3 +-
> .../cros_ec_sensors/cros_ec_sensors_core.c | 3 +-
> drivers/iio/light/cros_ec_light_prox.c | 3 +-
> drivers/iio/pressure/cros_ec_baro.c | 3 +-
> drivers/input/keyboard/Kconfig | 2 +-
> drivers/input/keyboard/cros_ec_keyb.c | 4 +-
> drivers/media/platform/Kconfig | 3 +-
> .../media/platform/cros-ec-cec/cros-ec-cec.c | 4 +-
> drivers/mfd/Kconfig | 26 +-
> drivers/mfd/Makefile | 4 +-
> drivers/mfd/cros_ec_dev.c | 433 +++++-------------
> drivers/platform/chrome/Kconfig | 48 +-
> drivers/platform/chrome/Makefile | 2 +
> drivers/{mfd => platform/chrome}/cros_ec.c | 64 +--
> drivers/platform/chrome/cros_ec_chardev.c | 279 +++++++++++
> drivers/platform/chrome/cros_ec_debugfs.c | 3 +-
> drivers/platform/chrome/cros_ec_i2c.c | 12 +-
> drivers/platform/chrome/cros_ec_lightbar.c | 3 +-
> drivers/platform/chrome/cros_ec_lpc.c | 7 +-
> drivers/platform/chrome/cros_ec_lpc_reg.c | 4 +-
> drivers/platform/chrome/cros_ec_proto.c | 3 +-
> drivers/platform/chrome/cros_ec_rpmsg.c | 6 +-
> drivers/platform/chrome/cros_ec_spi.c | 12 +-
> drivers/platform/chrome/cros_ec_sysfs.c | 3 +-
> drivers/platform/chrome/cros_ec_trace.c | 2 +-
> drivers/platform/chrome/cros_ec_trace.h | 4 +-
> drivers/platform/chrome/cros_ec_vbc.c | 3 +-
> drivers/platform/chrome/cros_usbpd_logger.c | 5 +-
> drivers/power/supply/Kconfig | 2 +-
> drivers/power/supply/cros_usbpd-charger.c | 5 +-
> drivers/pwm/Kconfig | 2 +-
> drivers/pwm/pwm-cros-ec.c | 4 +-
> drivers/rtc/Kconfig | 2 +-
> drivers/rtc/rtc-cros-ec.c | 3 +-
> .../linux/iio/common/cros_ec_sensors_core.h | 3 +-
> include/linux/mfd/cros_ec.h | 302 +-----------
> .../{mfd => platform_data}/cros_ec_commands.h | 0
> include/linux/platform_data/cros_ec_proto.h | 315 +++++++++++++
> .../uapi/linux/cros_ec_chardev.h | 18 +-
> sound/soc/codecs/cros_ec_codec.c | 4 +-
> sound/soc/qcom/Kconfig | 2 +-
> 50 files changed, 902 insertions(+), 732 deletions(-)
> rename drivers/{mfd => platform/chrome}/cros_ec.c (85%)
> create mode 100644 drivers/platform/chrome/cros_ec_chardev.c
> rename include/linux/{mfd => platform_data}/cros_ec_commands.h (100%)
> create mode 100644 include/linux/platform_data/cros_ec_proto.h
> rename drivers/mfd/cros_ec_dev.h => include/uapi/linux/cros_ec_chardev.h (70%)
>
--
~Randy
^ permalink raw reply
* [PATCH 1/2] HID: hid-logitech-hidpp: Report battery voltage
From: Pedro Vanzella @ 2019-06-04 23:28 UTC (permalink / raw)
To: linux-input; +Cc: Pedro Vanzella, Jiri Kosina, Benjamin Tissoires, linux-kernel
Newer devices have a feature with id 0x1001 that reports the battery
voltage instead of the old feature with id 0x1000 that reports a
percentage.
This patch fetches and decodes this data for all devices that
support it.
Signed-off-by: Pedro Vanzella <pedro@pedrovanzella.com>
---
drivers/hid/hid-logitech-hidpp.c | 108 ++++++++++++++++++++++++++++++-
1 file changed, 106 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 72fc9c0566db..e68ea44b0d24 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -91,6 +91,7 @@ MODULE_PARM_DESC(disable_tap_to_click,
#define HIDPP_CAPABILITY_HIDPP20_BATTERY BIT(1)
#define HIDPP_CAPABILITY_BATTERY_MILEAGE BIT(2)
#define HIDPP_CAPABILITY_BATTERY_LEVEL_STATUS BIT(3)
+#define HIDPP_CAPABILITY_BATTERY_VOLTAGE BIT(4)
/*
* There are two hidpp protocols in use, the first version hidpp10 is known
@@ -139,12 +140,14 @@ struct hidpp_report {
struct hidpp_battery {
u8 feature_index;
u8 solar_feature_index;
+ u8 voltage_feature_index;
struct power_supply_desc desc;
struct power_supply *ps;
char name[64];
int status;
int capacity;
int level;
+ int voltage; /* in millivolts */
bool online;
};
@@ -1223,6 +1226,93 @@ static int hidpp20_battery_event(struct hidpp_device *hidpp,
return 0;
}
+/* -------------------------------------------------------------------------- */
+/* 0x1001: Battery voltage */
+/* -------------------------------------------------------------------------- */
+
+#define HIDPP_PAGE_BATTERY_VOLTAGE 0x1001
+
+#define CMD_BATTERY_VOLTAGE_GET_BATTERY_VOLTAGE 0x00
+
+static int hidpp20_battery_map_status_voltage(u8 data[3], int *voltage)
+{
+ int status;
+
+ switch (data[2]) {
+ case 0x00: /* discharging */
+ status = POWER_SUPPLY_STATUS_DISCHARGING;
+ break;
+ case 0x10: /* wireless charging */
+ case 0x80: /* charging */
+ status = POWER_SUPPLY_STATUS_CHARGING;
+ break;
+ case 0x81: /* fully charged */
+ status = POWER_SUPPLY_STATUS_FULL;
+ break;
+ default:
+ status = POWER_SUPPLY_STATUS_NOT_CHARGING;
+ }
+
+ *voltage = (data[0] << 8) + data[1];
+
+ return status;
+}
+
+static int hidpp20_battery_get_battery_voltage(struct hidpp_device *hidpp,
+ u8 feature_index,
+ int *status, int *voltage)
+{
+ struct hidpp_report response;
+ int ret;
+ u8 *params = (u8 *)response.fap.params;
+
+ ret = hidpp_send_fap_command_sync(hidpp, feature_index,
+ CMD_BATTERY_VOLTAGE_GET_BATTERY_VOLTAGE,
+ NULL, 0, &response);
+
+ if (ret > 0) {
+ hid_err(hidpp->hid_dev, "%s: received protocol error 0x%02x\n",
+ __func__, ret);
+ return -EPROTO;
+ }
+ if (ret)
+ return ret;
+
+ hidpp->capabilities |= HIDPP_CAPABILITY_BATTERY_VOLTAGE;
+
+ *status = hidpp20_battery_map_status_voltage(params, voltage);
+
+ return 0;
+}
+
+static int hidpp20_query_battery_voltage_info(struct hidpp_device *hidpp)
+{
+ u8 feature_type;
+ int ret;
+ int status, voltage;
+
+ if (hidpp->battery.voltage_feature_index == 0xff) {
+ ret = hidpp_root_get_feature(hidpp, HIDPP_PAGE_BATTERY_VOLTAGE,
+ &hidpp->battery.voltage_feature_index,
+ &feature_type);
+ if (ret)
+ return ret;
+ }
+
+ ret = hidpp20_battery_get_battery_voltage(hidpp,
+ hidpp->battery.voltage_feature_index,
+ &status, &voltage);
+
+ if (ret)
+ return ret;
+
+ hidpp->battery.status = status;
+ hidpp->battery.voltage = voltage;
+ hidpp->battery.online = status != POWER_SUPPLY_STATUS_NOT_CHARGING;
+
+ return 0;
+}
+
static enum power_supply_property hidpp_battery_props[] = {
POWER_SUPPLY_PROP_ONLINE,
POWER_SUPPLY_PROP_STATUS,
@@ -1232,6 +1322,7 @@ static enum power_supply_property hidpp_battery_props[] = {
POWER_SUPPLY_PROP_SERIAL_NUMBER,
0, /* placeholder for POWER_SUPPLY_PROP_CAPACITY, */
0, /* placeholder for POWER_SUPPLY_PROP_CAPACITY_LEVEL, */
+ 0, /* placeholder for POWER_SUPPLY_PROP_VOLTAGE_NOW, */
};
static int hidpp_battery_get_property(struct power_supply *psy,
@@ -1269,6 +1360,9 @@ static int hidpp_battery_get_property(struct power_supply *psy,
case POWER_SUPPLY_PROP_SERIAL_NUMBER:
val->strval = hidpp->hid_dev->uniq;
break;
+ case POWER_SUPPLY_PROP_VOLTAGE_NOW:
+ val->intval = hidpp->battery.voltage;
+ break;
default:
ret = -EINVAL;
break;
@@ -3208,12 +3302,16 @@ static int hidpp_initialize_battery(struct hidpp_device *hidpp)
hidpp->battery.feature_index = 0xff;
hidpp->battery.solar_feature_index = 0xff;
+ hidpp->battery.voltage_feature_index = 0xff;
if (hidpp->protocol_major >= 2) {
if (hidpp->quirks & HIDPP_QUIRK_CLASS_K750)
ret = hidpp_solar_request_battery_event(hidpp);
- else
+ else {
ret = hidpp20_query_battery_info(hidpp);
+ if (ret)
+ ret = hidpp20_query_battery_voltage_info(hidpp);
+ }
if (ret)
return ret;
@@ -3238,7 +3336,7 @@ static int hidpp_initialize_battery(struct hidpp_device *hidpp)
if (!battery_props)
return -ENOMEM;
- num_battery_props = ARRAY_SIZE(hidpp_battery_props) - 2;
+ num_battery_props = ARRAY_SIZE(hidpp_battery_props) - 3;
if (hidpp->capabilities & HIDPP_CAPABILITY_BATTERY_MILEAGE)
battery_props[num_battery_props++] =
@@ -3248,6 +3346,10 @@ static int hidpp_initialize_battery(struct hidpp_device *hidpp)
battery_props[num_battery_props++] =
POWER_SUPPLY_PROP_CAPACITY_LEVEL;
+ if (hidpp->capabilities & HIDPP_CAPABILITY_BATTERY_VOLTAGE)
+ battery_props[num_battery_props++] =
+ POWER_SUPPLY_PROP_VOLTAGE_NOW;
+
battery = &hidpp->battery;
n = atomic_inc_return(&battery_no) - 1;
@@ -3412,6 +3514,8 @@ static void hidpp_connect_event(struct hidpp_device *hidpp)
hidpp10_query_battery_status(hidpp);
} else if (hidpp->capabilities & HIDPP_CAPABILITY_HIDPP20_BATTERY) {
hidpp20_query_battery_info(hidpp);
+ if (hidpp->capabilities & HIDPP_CAPABILITY_BATTERY_VOLTAGE)
+ hidpp20_query_battery_voltage_info(hidpp);
}
if (hidpp->battery.ps)
power_supply_changed(hidpp->battery.ps);
--
2.21.0
^ permalink raw reply related
* [PATCH 2/2] HID: hid-logitech-hidpp: subscribe to battery voltage change events
From: Pedro Vanzella @ 2019-06-04 23:28 UTC (permalink / raw)
To: linux-input; +Cc: Pedro Vanzella, Jiri Kosina, Benjamin Tissoires, linux-kernel
In-Reply-To: <20190604232827.26008-1-pedro@pedrovanzella.com>
Same as with the other ways of reporting battery status,
fetch the battery voltage on raw hidpp events.
Signed-off-by: Pedro Vanzella <pedro@pedrovanzella.com>
---
drivers/hid/hid-logitech-hidpp.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index e68ea44b0d24..1eee206a0aed 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -1313,6 +1313,35 @@ static int hidpp20_query_battery_voltage_info(struct hidpp_device *hidpp)
return 0;
}
+static int hidpp20_battery_voltage_event(struct hidpp_device *hidpp,
+ u8 *data, int size)
+{
+ struct hidpp_report *report = (struct hidpp_report *)data;
+ int status, voltage;
+ bool changed;
+
+ if (report->fap.feature_index != hidpp->battery.voltage_feature_index ||
+ report->fap.funcindex_clientid !=
+ EVENT_BATTERY_LEVEL_STATUS_BROADCAST)
+ return 0;
+
+ status = hidpp20_battery_map_status_voltage(report->fap.params,
+ &voltage);
+
+ hidpp->battery.online = status != POWER_SUPPLY_STATUS_NOT_CHARGING;
+
+ changed = voltage != hidpp->battery.voltage ||
+ status != hidpp->battery.status;
+
+ if (changed) {
+ hidpp->battery.voltage = voltage;
+ hidpp->battery.status = status;
+ if (hidpp->battery.ps)
+ power_supply_changed(hidpp->battery.ps);
+ }
+ return 0;
+}
+
static enum power_supply_property hidpp_battery_props[] = {
POWER_SUPPLY_PROP_ONLINE,
POWER_SUPPLY_PROP_STATUS,
@@ -3181,6 +3210,9 @@ static int hidpp_raw_hidpp_event(struct hidpp_device *hidpp, u8 *data,
ret = hidpp_solar_battery_event(hidpp, data, size);
if (ret != 0)
return ret;
+ ret = hidpp20_battery_voltage_event(hidpp, data, size);
+ if (ret != 0)
+ return ret;
}
if (hidpp->capabilities & HIDPP_CAPABILITY_HIDPP10_BATTERY) {
--
2.21.0
^ permalink raw reply related
* Re: [PATCH 02/10] mfd / platform: cros_ec: Move cros-ec core driver out from MFD
From: Thierry Reding @ 2019-06-05 8:31 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: gwendal, Banajit Goswami, Vignesh R, Alexandre Belloni,
Wolfram Sang, linux-iio, Mark Brown, Juergen Fitschen, alsa-devel,
Stefan Agner, Sebastian Reichel, Benjamin Tissoires,
Karthikeyan Ramasubramanian, linux-i2c, Peter Meerwald-Stadler,
Manivannan Sadhasivam, Guenter Roeck, kernel, dtor,
Lars-Peter Clausen, Jean Delvare, Jacky Bai, linux-rtc,
Andy Shevchenko, Sean
In-Reply-To: <20190604152019.16100-3-enric.balletbo@collabora.com>
[-- Attachment #1.1: Type: text/plain, Size: 1762 bytes --]
On Tue, Jun 04, 2019 at 05:20:11PM +0200, Enric Balletbo i Serra wrote:
> Now, the ChromeOS EC core driver has nothing related to an MFD device, so
> move that driver from the MFD subsystem to the platform/chrome subsystem.
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> ---
>
> drivers/extcon/Kconfig | 2 +-
> drivers/hid/Kconfig | 2 +-
> drivers/i2c/busses/Kconfig | 2 +-
> drivers/iio/common/cros_ec_sensors/Kconfig | 2 +-
> drivers/input/keyboard/Kconfig | 2 +-
> drivers/media/platform/Kconfig | 3 +--
> drivers/mfd/Kconfig | 14 +-------------
> drivers/mfd/Makefile | 2 --
> drivers/platform/chrome/Kconfig | 21 +++++++++++++++++----
> drivers/platform/chrome/Makefile | 1 +
> drivers/{mfd => platform/chrome}/cros_ec.c | 0
> drivers/power/supply/Kconfig | 2 +-
> drivers/pwm/Kconfig | 2 +-
> drivers/rtc/Kconfig | 2 +-
> sound/soc/qcom/Kconfig | 2 +-
> 15 files changed, 29 insertions(+), 30 deletions(-)
> rename drivers/{mfd => platform/chrome}/cros_ec.c (100%)
[...]
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index dff5a93f7daa..99946e1bcc73 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -145,7 +145,7 @@ config PWM_CRC
>
> config PWM_CROS_EC
> tristate "ChromeOS EC PWM driver"
> - depends on MFD_CROS_EC
> + depends on CROS_EC
> help
> PWM driver for exposing a PWM attached to the ChromeOS Embedded
> Controller.
Acked-by: Thierry Reding <thierry.reding@gmail.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH 02/10] mfd / platform: cros_ec: Move cros-ec core driver out from MFD
From: Mark Brown @ 2019-06-05 10:02 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: gwendal, Banajit Goswami, Vignesh R, Alexandre Belloni,
Wolfram Sang, linux-iio, Juergen Fitschen, alsa-devel,
Stefan Agner, Sebastian Reichel, Benjamin Tissoires,
Karthikeyan Ramasubramanian, linux-i2c, Peter Meerwald-Stadler,
Manivannan Sadhasivam, Guenter Roeck, kernel, dtor,
Lars-Peter Clausen, Jean Delvare, Jacky Bai, linux-rtc,
Andy Shevchenko, Sean Young, Lee Jones <lee.jo>
In-Reply-To: <20190604152019.16100-3-enric.balletbo@collabora.com>
[-- Attachment #1.1: Type: text/plain, Size: 267 bytes --]
On Tue, Jun 04, 2019 at 05:20:11PM +0200, Enric Balletbo i Serra wrote:
> Now, the ChromeOS EC core driver has nothing related to an MFD device, so
> move that driver from the MFD subsystem to the platform/chrome subsystem.
Acked-by: Mark Brown <broonie@kernel.org>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH 06/10] mfd / platform: cros_ec: Reorganize platform and mfd includes
From: Mark Brown @ 2019-06-05 10:02 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: linux-kernel, gwendal, Guenter Roeck, Benson Leung, Lee Jones,
kernel, dtor, Mauro Carvalho Chehab, alsa-devel, Alessandro Zummo,
linux-iio, Fabien Lahoudere, Alexandre Belloni, linux-i2c,
linux-rtc, Heiko Stuebner, Brian Norris, Chanwoo Choi,
Benjamin Tissoires, Gustavo A. R. Silva, Sebastian Reichel,
Rushikesh
In-Reply-To: <20190604152019.16100-7-enric.balletbo@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 325 bytes --]
On Tue, Jun 04, 2019 at 05:20:15PM +0200, Enric Balletbo i Serra wrote:
> There is a bit of mess between cros-ec mfd includes and platform
> includes. For example, we have a linux/mfd/cros_ec.h include that
> exports the interface implemented in platform/chrome/cros_ec_proto.c. Or
Acked-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: allwinner: a64: Add lradc node
From: Maxime Ripard @ 2019-06-05 11:52 UTC (permalink / raw)
To: Luca Weiss
Cc: Hans de Goede, Dmitry Torokhov, Rob Herring, Mark Rutland,
Chen-Yu Tsai,
open list:SUN4I LOW RES ADC ATTACHED TABLET KEYS DRIVER,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/Allwinner sunXi SoC support, open list,
~martijnbraam/pmos-upstream
In-Reply-To: <20190604172154.25472-2-luca@z3ntu.xyz>
[-- Attachment #1: Type: text/plain, Size: 269 bytes --]
On Tue, Jun 04, 2019 at 07:21:54PM +0200, Luca Weiss wrote:
> Add a node describing the KEYADC on the A64.
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Applied both, thanks
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: hid-related 5.2-rc1 boot hang
From: Benjamin Tissoires @ 2019-06-05 12:29 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Hans de Goede, Dave Hansen, open list:HID CORE LAYER, LKML
In-Reply-To: <nycvar.YFH.7.76.1906042307260.27227@cbobk.fhfr.pm>
On Tue, Jun 4, 2019 at 11:08 PM Jiri Kosina <jikos@kernel.org> wrote:
>
> On Tue, 4 Jun 2019, Benjamin Tissoires wrote:
>
> > > Which should fix this. It is quite simple and safe, so if we get testing
> > > feedback relatively soon, we could go with the fix instead of dropping the
> > > product-id, your call.
> >
> > I should receive the M280 tomorrow, hopefully with the C52F. If the
> > receiver is correct and the tests are successful, I'd prefer to take
> > this one over the revert :)
>
> Agreed at this release phase. And if it doesn't work, immediate revert for
> now and proper fix for 5.3-rc1.
>
Mouse received, patch tested, patch validated.
Honestly, before fully reviewing the patch, I thought it would be more
5.3 material, but after a thorough review, there is nothing scary in
it and we can safely push it on top of the 5.2 branch.
I'm about to send the other mentioned reverts and push everything in 5.2-fixes
Cheers,
Benjamin
^ permalink raw reply
* [PATCH 0/4] few reverts and fixes for 5.2
From: Benjamin Tissoires @ 2019-06-05 12:44 UTC (permalink / raw)
To: Jiri Kosina, Hans de Goede, Dave Hansen, Kai-Heng Feng
Cc: linux-input, linux-kernel, Benjamin Tissoires
This has been already publicly discussed here, so I am just posting
for completeness.
patch 1:
request to revert it:
https://patchwork.kernel.org/patch/10844177/#22651385
patch 2&3:
related thread:
https://lkml.org/lkml/2019/5/28/778
patch 4:
bug link: https://bugzilla.kernel.org/show_bug.cgi?id=203619
and related thread: https://lkml.org/lkml/2019/5/28/778
Cheers,
Benjamin
Benjamin Tissoires (3):
Revert "HID: Increase maximum report size allowed by
hid_field_extract()"
Revert "HID: core: Do not call request_module() in async context"
Revert "HID: core: Call request_module before doing device_add"
Hans de Goede (1):
HID: logitech-dj: Fix 064d:c52f receiver support
drivers/hid/hid-core.c | 16 +++----------
drivers/hid/hid-logitech-dj.c | 42 ++++++++++++++++++++++-------------
2 files changed, 30 insertions(+), 28 deletions(-)
--
2.19.2
^ permalink raw reply
* [PATCH 1/4] Revert "HID: Increase maximum report size allowed by hid_field_extract()"
From: Benjamin Tissoires @ 2019-06-05 12:44 UTC (permalink / raw)
To: Jiri Kosina, Hans de Goede, Dave Hansen, Kai-Heng Feng
Cc: linux-input, linux-kernel, Benjamin Tissoires, stable
In-Reply-To: <20190605124408.8637-1-benjamin.tissoires@redhat.com>
This reverts commit 94a9992f7dbdfb28976b565af220e0c4a117144a.
The commit allows for more than 32 bits in hid_field_extract(),
but the return value is a 32 bits int.
So basically what this commit is doing is just silencing those
legitimate errors.
Revert to a previous situation in the hope that a proper
fix will be impletemented.
Fixes: 94a9992f7dbd ("HID: Increase maximum report size allowed by hid_field_extract()")
Cc: stable@vger.kernel.org # v5.1
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/hid/hid-core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 08d310723e96..205d6b82a706 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1311,10 +1311,10 @@ static u32 __extract(u8 *report, unsigned offset, int n)
u32 hid_field_extract(const struct hid_device *hid, u8 *report,
unsigned offset, unsigned n)
{
- if (n > 256) {
- hid_warn(hid, "hid_field_extract() called with n (%d) > 256! (%s)\n",
+ if (n > 32) {
+ hid_warn(hid, "hid_field_extract() called with n (%d) > 32! (%s)\n",
n, current->comm);
- n = 256;
+ n = 32;
}
return __extract(report, offset, n);
--
2.19.2
^ permalink raw reply related
* [PATCH 2/4] Revert "HID: core: Do not call request_module() in async context"
From: Benjamin Tissoires @ 2019-06-05 12:44 UTC (permalink / raw)
To: Jiri Kosina, Hans de Goede, Dave Hansen, Kai-Heng Feng
Cc: linux-input, linux-kernel, Benjamin Tissoires
In-Reply-To: <20190605124408.8637-1-benjamin.tissoires@redhat.com>
This reverts commit 4ceabaf7909d109db6afbffc4ed182741fc32043.
This patch and a025a18fe are giving extended timeouts
on boot for at least Ubuntu and OpenSuse.
Revert them until we get a better fix.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/hid/hid-core.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 205d6b82a706..fd9e7a4c107d 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -27,7 +27,6 @@
#include <linux/vmalloc.h>
#include <linux/sched.h>
#include <linux/semaphore.h>
-#include <linux/async.h>
#include <linux/hid.h>
#include <linux/hiddev.h>
@@ -2367,9 +2366,8 @@ int hid_add_device(struct hid_device *hdev)
* not first have hid-generic binding only to have it replaced
* immediately afterwards with a specialized driver.
*/
- if (!current_is_async())
- request_module("hid:b%04Xg%04Xv%08Xp%08X", hdev->bus,
- hdev->group, hdev->vendor, hdev->product);
+ request_module("hid:b%04Xg%04Xv%08Xp%08X",
+ hdev->bus, hdev->group, hdev->vendor, hdev->product);
hid_debug_register(hdev, dev_name(&hdev->dev));
ret = device_add(&hdev->dev);
--
2.19.2
^ permalink raw reply related
* [PATCH 3/4] Revert "HID: core: Call request_module before doing device_add"
From: Benjamin Tissoires @ 2019-06-05 12:44 UTC (permalink / raw)
To: Jiri Kosina, Hans de Goede, Dave Hansen, Kai-Heng Feng
Cc: linux-input, linux-kernel, Benjamin Tissoires
In-Reply-To: <20190605124408.8637-1-benjamin.tissoires@redhat.com>
This reverts commit a025a18fecd4429f4ca66b1746001263c052ecbb.
This patch and 4ceabaf79 are giving extended timeouts
on boot for at least Ubuntu and OpenSuse.
Revert them until we get a better fix.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203741
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/hid/hid-core.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index fd9e7a4c107d..210b81a56e1a 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2361,14 +2361,6 @@ int hid_add_device(struct hid_device *hdev)
dev_set_name(&hdev->dev, "%04X:%04X:%04X.%04X", hdev->bus,
hdev->vendor, hdev->product, atomic_inc_return(&id));
- /*
- * Try loading the module for the device before the add, so that we do
- * not first have hid-generic binding only to have it replaced
- * immediately afterwards with a specialized driver.
- */
- request_module("hid:b%04Xg%04Xv%08Xp%08X",
- hdev->bus, hdev->group, hdev->vendor, hdev->product);
-
hid_debug_register(hdev, dev_name(&hdev->dev));
ret = device_add(&hdev->dev);
if (!ret)
--
2.19.2
^ permalink raw reply related
* [PATCH 4/4] HID: logitech-dj: Fix 064d:c52f receiver support
From: Benjamin Tissoires @ 2019-06-05 12:44 UTC (permalink / raw)
To: Jiri Kosina, Hans de Goede, Dave Hansen, Kai-Heng Feng
Cc: linux-input, linux-kernel, Benjamin Tissoires
In-Reply-To: <20190605124408.8637-1-benjamin.tissoires@redhat.com>
From: Hans de Goede <hdegoede@redhat.com>
The c52f nano receiver is a mouse only receiver. This means that it needs
some special handling compared to the c534 nano receiver:
1) It sends unnumbered mouse reports with a size of 8 bytes, so we need
to extend the unnumbered mouse report handling to support reports upto
8 bytes large
2) It mouse reports have the same high-resolution format as those from the
gaming mouse receivers
3) It can report consumer/multimedia buttons on its second interface, since
this is a mouse-only receiver these must be forwarded to the mouse child
device and not to the keyboard child-device (which will not exist)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203619
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/hid/hid-logitech-dj.c | 42 ++++++++++++++++++++++-------------
1 file changed, 27 insertions(+), 15 deletions(-)
diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index 41baa4dbbfcc..c48e7030d3c9 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -128,6 +128,7 @@ enum recvr_type {
recvr_type_dj,
recvr_type_hidpp,
recvr_type_gaming_hidpp,
+ recvr_type_mouse_only,
recvr_type_27mhz,
recvr_type_bluetooth,
};
@@ -879,9 +880,12 @@ static void logi_dj_recv_queue_notification(struct dj_receiver_dev *djrcv_dev,
schedule_work(&djrcv_dev->work);
}
-static void logi_hidpp_dev_conn_notif_equad(struct hidpp_event *hidpp_report,
+static void logi_hidpp_dev_conn_notif_equad(struct hid_device *hdev,
+ struct hidpp_event *hidpp_report,
struct dj_workitem *workitem)
{
+ struct dj_receiver_dev *djrcv_dev = hid_get_drvdata(hdev);
+
workitem->type = WORKITEM_TYPE_PAIRED;
workitem->device_type = hidpp_report->params[HIDPP_PARAM_DEVICE_INFO] &
HIDPP_DEVICE_TYPE_MASK;
@@ -895,6 +899,8 @@ static void logi_hidpp_dev_conn_notif_equad(struct hidpp_event *hidpp_report,
break;
case REPORT_TYPE_MOUSE:
workitem->reports_supported |= STD_MOUSE | HIDPP;
+ if (djrcv_dev->type == recvr_type_mouse_only)
+ workitem->reports_supported |= MULTIMEDIA;
break;
}
}
@@ -938,7 +944,7 @@ static void logi_hidpp_recv_queue_notif(struct hid_device *hdev,
case 0x01:
device_type = "Bluetooth";
/* Bluetooth connect packet contents is the same as (e)QUAD */
- logi_hidpp_dev_conn_notif_equad(hidpp_report, &workitem);
+ logi_hidpp_dev_conn_notif_equad(hdev, hidpp_report, &workitem);
if (!(hidpp_report->params[HIDPP_PARAM_DEVICE_INFO] &
HIDPP_MANUFACTURER_MASK)) {
hid_info(hdev, "Non Logitech device connected on slot %d\n",
@@ -952,18 +958,18 @@ static void logi_hidpp_recv_queue_notif(struct hid_device *hdev,
break;
case 0x03:
device_type = "QUAD or eQUAD";
- logi_hidpp_dev_conn_notif_equad(hidpp_report, &workitem);
+ logi_hidpp_dev_conn_notif_equad(hdev, hidpp_report, &workitem);
break;
case 0x04:
device_type = "eQUAD step 4 DJ";
- logi_hidpp_dev_conn_notif_equad(hidpp_report, &workitem);
+ logi_hidpp_dev_conn_notif_equad(hdev, hidpp_report, &workitem);
break;
case 0x05:
device_type = "DFU Lite";
break;
case 0x06:
device_type = "eQUAD step 4 Lite";
- logi_hidpp_dev_conn_notif_equad(hidpp_report, &workitem);
+ logi_hidpp_dev_conn_notif_equad(hdev, hidpp_report, &workitem);
break;
case 0x07:
device_type = "eQUAD step 4 Gaming";
@@ -973,11 +979,11 @@ static void logi_hidpp_recv_queue_notif(struct hid_device *hdev,
break;
case 0x0a:
device_type = "eQUAD nano Lite";
- logi_hidpp_dev_conn_notif_equad(hidpp_report, &workitem);
+ logi_hidpp_dev_conn_notif_equad(hdev, hidpp_report, &workitem);
break;
case 0x0c:
device_type = "eQUAD Lightspeed";
- logi_hidpp_dev_conn_notif_equad(hidpp_report, &workitem);
+ logi_hidpp_dev_conn_notif_equad(hdev, hidpp_report, &workitem);
workitem.reports_supported |= STD_KEYBOARD;
break;
}
@@ -1330,7 +1336,8 @@ static int logi_dj_ll_parse(struct hid_device *hid)
if (djdev->reports_supported & STD_MOUSE) {
dbg_hid("%s: sending a mouse descriptor, reports_supported: %llx\n",
__func__, djdev->reports_supported);
- if (djdev->dj_receiver_dev->type == recvr_type_gaming_hidpp)
+ if (djdev->dj_receiver_dev->type == recvr_type_gaming_hidpp ||
+ djdev->dj_receiver_dev->type == recvr_type_mouse_only)
rdcat(rdesc, &rsize, mse_high_res_descriptor,
sizeof(mse_high_res_descriptor));
else if (djdev->dj_receiver_dev->type == recvr_type_27mhz)
@@ -1573,15 +1580,19 @@ static int logi_dj_raw_event(struct hid_device *hdev,
data[0] = data[1];
data[1] = 0;
}
- /* The 27 MHz mouse-only receiver sends unnumbered mouse data */
+ /*
+ * Mouse-only receivers send unnumbered mouse data. The 27 MHz
+ * receiver uses 6 byte packets, the nano receiver 8 bytes.
+ */
if (djrcv_dev->unnumbered_application == HID_GD_MOUSE &&
- size == 6) {
- u8 mouse_report[7];
+ size <= 8) {
+ u8 mouse_report[9];
/* Prepend report id */
mouse_report[0] = REPORT_TYPE_MOUSE;
- memcpy(mouse_report + 1, data, 6);
- logi_dj_recv_forward_input_report(hdev, mouse_report, 7);
+ memcpy(mouse_report + 1, data, size);
+ logi_dj_recv_forward_input_report(hdev, mouse_report,
+ size + 1);
}
return false;
@@ -1652,6 +1663,7 @@ static int logi_dj_probe(struct hid_device *hdev,
case recvr_type_dj: no_dj_interfaces = 3; break;
case recvr_type_hidpp: no_dj_interfaces = 2; break;
case recvr_type_gaming_hidpp: no_dj_interfaces = 3; break;
+ case recvr_type_mouse_only: no_dj_interfaces = 2; break;
case recvr_type_27mhz: no_dj_interfaces = 2; break;
case recvr_type_bluetooth: no_dj_interfaces = 2; break;
}
@@ -1825,10 +1837,10 @@ static const struct hid_device_id logi_dj_receivers[] = {
{HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_UNIFYING_RECEIVER_2),
.driver_data = recvr_type_dj},
- { /* Logitech Nano (non DJ) receiver */
+ { /* Logitech Nano mouse only receiver */
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_NANO_RECEIVER),
- .driver_data = recvr_type_hidpp},
+ .driver_data = recvr_type_mouse_only},
{ /* Logitech Nano (non DJ) receiver */
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_2),
--
2.19.2
^ permalink raw reply related
* Re: [PATCH 0/4] few reverts and fixes for 5.2
From: Jiri Kosina @ 2019-06-05 13:07 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Hans de Goede, Dave Hansen, Kai-Heng Feng, linux-input,
linux-kernel
In-Reply-To: <20190605124408.8637-1-benjamin.tissoires@redhat.com>
On Wed, 5 Jun 2019, Benjamin Tissoires wrote:
> This has been already publicly discussed here, so I am just posting
> for completeness.
>
> patch 1:
> request to revert it:
> https://patchwork.kernel.org/patch/10844177/#22651385
>
> patch 2&3:
> related thread:
> https://lkml.org/lkml/2019/5/28/778
>
> patch 4:
> bug link: https://bugzilla.kernel.org/show_bug.cgi?id=203619
> and related thread: https://lkml.org/lkml/2019/5/28/778
>
> Cheers,
> Benjamin
>
> Benjamin Tissoires (3):
> Revert "HID: Increase maximum report size allowed by
> hid_field_extract()"
> Revert "HID: core: Do not call request_module() in async context"
> Revert "HID: core: Call request_module before doing device_add"
>
> Hans de Goede (1):
> HID: logitech-dj: Fix 064d:c52f receiver support
For the set:
Acked-by: Jiri Kosina <jkosina@suse.cz>
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 02/10] mfd / platform: cros_ec: Move cros-ec core driver out from MFD
From: Wolfram Sang @ 2019-06-05 14:19 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: gwendal, Banajit Goswami, Vignesh R, Alexandre Belloni,
Liam Girdwood, linux-iio, Mark Brown, Juergen Fitschen,
alsa-devel, Stefan Agner, Sebastian Reichel, Benjamin Tissoires,
Karthikeyan Ramasubramanian, linux-i2c, Peter Meerwald-Stadler,
Manivannan Sadhasivam, Guenter Roeck, kernel, dtor,
Lars-Peter Clausen, Jean Delvare, Jacky Bai, linux-rtc,
Andy Shevchenko, Sean
In-Reply-To: <20190604152019.16100-3-enric.balletbo@collabora.com>
[-- Attachment #1.1: Type: text/plain, Size: 370 bytes --]
On Tue, Jun 04, 2019 at 05:20:11PM +0200, Enric Balletbo i Serra wrote:
> Now, the ChromeOS EC core driver has nothing related to an MFD device, so
> move that driver from the MFD subsystem to the platform/chrome subsystem.
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: Wolfram Sang <wsa@the-dreams.de> (for the I2C part)
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH 06/10] mfd / platform: cros_ec: Reorganize platform and mfd includes
From: Wolfram Sang @ 2019-06-05 14:20 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: linux-kernel, gwendal, Guenter Roeck, Benson Leung, Lee Jones,
kernel, dtor, Mauro Carvalho Chehab, alsa-devel, Alessandro Zummo,
linux-iio, Fabien Lahoudere, Alexandre Belloni, linux-i2c,
linux-rtc, Heiko Stuebner, Brian Norris, Chanwoo Choi,
Benjamin Tissoires, Gustavo A. R. Silva, Sebastian Reichel,
Rushikesh
In-Reply-To: <20190604152019.16100-7-enric.balletbo@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 1699 bytes --]
On Tue, Jun 04, 2019 at 05:20:15PM +0200, Enric Balletbo i Serra wrote:
> There is a bit of mess between cros-ec mfd includes and platform
> includes. For example, we have a linux/mfd/cros_ec.h include that
> exports the interface implemented in platform/chrome/cros_ec_proto.c. Or
> we have a linux/mfd/cros_ec_commands.h file that is non related to the
> multifunction device (in the sense that is not exporting any function of
> the mfd device). This causes crossed includes between mfd and
> platform/chrome subsystems and makes the code difficult to read, apart
> from creating 'curious' situations where a platform/chrome driver includes
> a linux/mfd/cros_ec.h file just to get the exported functions that are
> implemented in another platform/chrome driver.
>
> In order to have a better separation on what the cros-ec multifunction
> driver does and what the cros-ec core provides move and rework the
> affected includes doing:
>
> - Move cros_ec_commands.h to include/linux/platform_data/cros_ec_commands.h
> - Get rid of the parts that are implemented in the platform/chrome/cros_ec_proto.c
> driver from include/linux/mfd/cros_ec.h to a new file
> include/linux/platform_data/cros_ec_proto.h
> - Update all the drivers with the new includes, so
> - Drivers that only need to know about the protocol include
> - linux/platform_data/cros_ec_proto.h
> - linux/platform_data/cros_ec_commands.h
> - Drivers that need to know about the cros-ec mfd device also include
> - linux/mfd/cros_ec.h
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: Wolfram Sang <wsa@the-dreams.de> (for the I2C part)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 02/10] mfd / platform: cros_ec: Move cros-ec core driver out from MFD
From: Neil Armstrong @ 2019-06-05 14:23 UTC (permalink / raw)
To: Enric Balletbo i Serra, linux-kernel
Cc: gwendal, Banajit Goswami, Vignesh R, Alexandre Belloni,
Wolfram Sang, linux-iio, Mark Brown, Juergen Fitschen, alsa-devel,
Stefan Agner, Douglas Anderson, Benjamin Tissoires,
Karthikeyan Ramasubramanian, linux-i2c, Peter Meerwald-Stadler,
Manivannan Sadhasivam, Guenter Roeck, kernel, dtor,
Lars-Peter Clausen, Jean Delvare, Jacky Bai, linux-rtc,
Andy Shevchenko, Sean
In-Reply-To: <20190604152019.16100-3-enric.balletbo@collabora.com>
On 04/06/2019 17:20, Enric Balletbo i Serra wrote:
> Now, the ChromeOS EC core driver has nothing related to an MFD device, so
> move that driver from the MFD subsystem to the platform/chrome subsystem.
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> ---
>
> drivers/extcon/Kconfig | 2 +-
> drivers/hid/Kconfig | 2 +-
> drivers/i2c/busses/Kconfig | 2 +-
> drivers/iio/common/cros_ec_sensors/Kconfig | 2 +-
> drivers/input/keyboard/Kconfig | 2 +-
> drivers/media/platform/Kconfig | 3 +--
> drivers/mfd/Kconfig | 14 +-------------
> drivers/mfd/Makefile | 2 --
> drivers/platform/chrome/Kconfig | 21 +++++++++++++++++----
> drivers/platform/chrome/Makefile | 1 +
> drivers/{mfd => platform/chrome}/cros_ec.c | 0
> drivers/power/supply/Kconfig | 2 +-
> drivers/pwm/Kconfig | 2 +-
> drivers/rtc/Kconfig | 2 +-
> sound/soc/qcom/Kconfig | 2 +-
> 15 files changed, 29 insertions(+), 30 deletions(-)
> rename drivers/{mfd => platform/chrome}/cros_ec.c (100%)
>
Acked-by: Neil Armstrong <narmstrong@baylibre.com> # for the cros-cec part
^ permalink raw reply
* [PATCH] Input: alps: Drop unlikely before IS_ERR(_OR_NULL)
From: Kefeng Wang @ 2019-06-05 14:24 UTC (permalink / raw)
To: linux-kernel; +Cc: Kefeng Wang, Pali Rohár, Dmitry Torokhov, linux-input
In-Reply-To: <20190605142428.84784-1-wangkefeng.wang@huawei.com>
IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag,
so no need to do that again from its callers. Drop it.
Cc: "Pali Rohár" <pali.rohar@gmail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
drivers/input/mouse/alps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
index 0a6f7ca883e7..791ef0f826c5 100644
--- a/drivers/input/mouse/alps.c
+++ b/drivers/input/mouse/alps.c
@@ -1478,7 +1478,7 @@ static void alps_report_bare_ps2_packet(struct psmouse *psmouse,
/* On V2 devices the DualPoint Stick reports bare packets */
dev = priv->dev2;
dev2 = psmouse->dev;
- } else if (unlikely(IS_ERR_OR_NULL(priv->dev3))) {
+ } else if (IS_ERR_OR_NULL(priv->dev3)) {
/* Register dev3 mouse if we received PS/2 packet first time */
if (!IS_ERR(priv->dev3))
psmouse_queue_work(psmouse, &priv->dev3_register_work,
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 06/10] mfd / platform: cros_ec: Reorganize platform and mfd includes
From: Neil Armstrong @ 2019-06-05 14:26 UTC (permalink / raw)
To: Enric Balletbo i Serra, linux-kernel
Cc: gwendal, Guenter Roeck, Benson Leung, Lee Jones, kernel, dtor,
Mauro Carvalho Chehab, alsa-devel, Alessandro Zummo, linux-iio,
Fabien Lahoudere, Alexandre Belloni, linux-i2c, linux-rtc,
Heiko Stuebner, Brian Norris, Chanwoo Choi, Benjamin Tissoires,
Gustavo A. R. Silva, Sebastian Reichel, Rushikesh S Kadam
In-Reply-To: <20190604152019.16100-7-enric.balletbo@collabora.com>
On 04/06/2019 17:20, Enric Balletbo i Serra wrote:
> There is a bit of mess between cros-ec mfd includes and platform
> includes. For example, we have a linux/mfd/cros_ec.h include that
> exports the interface implemented in platform/chrome/cros_ec_proto.c. Or
> we have a linux/mfd/cros_ec_commands.h file that is non related to the
> multifunction device (in the sense that is not exporting any function of
> the mfd device). This causes crossed includes between mfd and
> platform/chrome subsystems and makes the code difficult to read, apart
> from creating 'curious' situations where a platform/chrome driver includes
> a linux/mfd/cros_ec.h file just to get the exported functions that are
> implemented in another platform/chrome driver.
>
> In order to have a better separation on what the cros-ec multifunction
> driver does and what the cros-ec core provides move and rework the
> affected includes doing:
>
> - Move cros_ec_commands.h to include/linux/platform_data/cros_ec_commands.h
> - Get rid of the parts that are implemented in the platform/chrome/cros_ec_proto.c
> driver from include/linux/mfd/cros_ec.h to a new file
> include/linux/platform_data/cros_ec_proto.h
> - Update all the drivers with the new includes, so
> - Drivers that only need to know about the protocol include
> - linux/platform_data/cros_ec_proto.h
> - linux/platform_data/cros_ec_commands.h
> - Drivers that need to know about the cros-ec mfd device also include
> - linux/mfd/cros_ec.h
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> ---
>
> drivers/extcon/extcon-usbc-cros-ec.c | 3 +-
> drivers/hid/hid-google-hammer.c | 4 +-
> drivers/i2c/busses/i2c-cros-ec-tunnel.c | 4 +-
> drivers/iio/accel/cros_ec_accel_legacy.c | 3 +-
> .../common/cros_ec_sensors/cros_ec_sensors.c | 3 +-
> .../cros_ec_sensors/cros_ec_sensors_core.c | 3 +-
> drivers/iio/light/cros_ec_light_prox.c | 3 +-
> drivers/iio/pressure/cros_ec_baro.c | 3 +-
> drivers/input/keyboard/cros_ec_keyb.c | 4 +-
> .../media/platform/cros-ec-cec/cros-ec-cec.c | 4 +-
> drivers/mfd/cros_ec_dev.c | 3 +-
> drivers/platform/chrome/cros_ec.c | 3 +-
> drivers/platform/chrome/cros_ec_chardev.c | 4 +-
> drivers/platform/chrome/cros_ec_debugfs.c | 3 +-
> drivers/platform/chrome/cros_ec_i2c.c | 4 +-
> drivers/platform/chrome/cros_ec_lightbar.c | 3 +-
> drivers/platform/chrome/cros_ec_lpc.c | 4 +-
> drivers/platform/chrome/cros_ec_lpc_reg.c | 4 +-
> drivers/platform/chrome/cros_ec_proto.c | 3 +-
> drivers/platform/chrome/cros_ec_rpmsg.c | 4 +-
> drivers/platform/chrome/cros_ec_spi.c | 4 +-
> drivers/platform/chrome/cros_ec_sysfs.c | 3 +-
> drivers/platform/chrome/cros_ec_trace.c | 2 +-
> drivers/platform/chrome/cros_ec_trace.h | 4 +-
> drivers/platform/chrome/cros_ec_vbc.c | 3 +-
> drivers/platform/chrome/cros_usbpd_logger.c | 5 +-
> drivers/power/supply/cros_usbpd-charger.c | 5 +-
> drivers/pwm/pwm-cros-ec.c | 4 +-
> drivers/rtc/rtc-cros-ec.c | 3 +-
> .../linux/iio/common/cros_ec_sensors_core.h | 3 +-
> include/linux/mfd/cros_ec.h | 306 -----------------
> .../{mfd => platform_data}/cros_ec_commands.h | 0
> include/linux/platform_data/cros_ec_proto.h | 315 ++++++++++++++++++
> sound/soc/codecs/cros_ec_codec.c | 4 +-
> 34 files changed, 379 insertions(+), 351 deletions(-)
> rename include/linux/{mfd => platform_data}/cros_ec_commands.h (100%)
> create mode 100644 include/linux/platform_data/cros_ec_proto.h
>
Acked-by: Neil Armstrong <narmstrong@baylibre.com> # for the cros-ec-cec part
^ permalink raw reply
* Re: [PATCH] Input: alps: Drop unlikely before IS_ERR(_OR_NULL)
From: Pali Rohár @ 2019-06-05 14:42 UTC (permalink / raw)
To: Kefeng Wang; +Cc: linux-kernel, Dmitry Torokhov, linux-input
In-Reply-To: <20190605142428.84784-5-wangkefeng.wang@huawei.com>
On Wednesday 05 June 2019 22:24:28 Kefeng Wang wrote:
> IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag,
> so no need to do that again from its callers. Drop it.
Hi! I already reviewed this patch and rejected it, see:
https://patchwork.kernel.org/patch/10817475/
> Cc: "Pali Rohár" <pali.rohar@gmail.com>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: linux-input@vger.kernel.org
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> ---
> drivers/input/mouse/alps.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
> index 0a6f7ca883e7..791ef0f826c5 100644
> --- a/drivers/input/mouse/alps.c
> +++ b/drivers/input/mouse/alps.c
> @@ -1478,7 +1478,7 @@ static void alps_report_bare_ps2_packet(struct psmouse *psmouse,
> /* On V2 devices the DualPoint Stick reports bare packets */
> dev = priv->dev2;
> dev2 = psmouse->dev;
> - } else if (unlikely(IS_ERR_OR_NULL(priv->dev3))) {
> + } else if (IS_ERR_OR_NULL(priv->dev3)) {
> /* Register dev3 mouse if we received PS/2 packet first time */
> if (!IS_ERR(priv->dev3))
> psmouse_queue_work(psmouse, &priv->dev3_register_work,
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [PATCH 02/10] mfd / platform: cros_ec: Move cros-ec core driver out from MFD
From: Alexandre Belloni @ 2019-06-05 16:25 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: gwendal, Banajit Goswami, Vignesh R, Sean Young, Wolfram Sang,
linux-iio, Mark Brown, Juergen Fitschen, alsa-devel, Stefan Agner,
Sebastian Reichel, Benjamin Tissoires,
Karthikeyan Ramasubramanian, linux-i2c, Peter Meerwald-Stadler,
Manivannan Sadhasivam, Guenter Roeck, kernel, dtor,
Lars-Peter Clausen, Jean Delvare, Jacky Bai, linux-rtc,
Andy Shevchenko, Ajay Gupta, Lee
In-Reply-To: <20190604152019.16100-3-enric.balletbo@collabora.com>
On 04/06/2019 17:20:11+0200, Enric Balletbo i Serra wrote:
> Now, the ChromeOS EC core driver has nothing related to an MFD device, so
> move that driver from the MFD subsystem to the platform/chrome subsystem.
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
>
> drivers/extcon/Kconfig | 2 +-
> drivers/hid/Kconfig | 2 +-
> drivers/i2c/busses/Kconfig | 2 +-
> drivers/iio/common/cros_ec_sensors/Kconfig | 2 +-
> drivers/input/keyboard/Kconfig | 2 +-
> drivers/media/platform/Kconfig | 3 +--
> drivers/mfd/Kconfig | 14 +-------------
> drivers/mfd/Makefile | 2 --
> drivers/platform/chrome/Kconfig | 21 +++++++++++++++++----
> drivers/platform/chrome/Makefile | 1 +
> drivers/{mfd => platform/chrome}/cros_ec.c | 0
> drivers/power/supply/Kconfig | 2 +-
> drivers/pwm/Kconfig | 2 +-
> drivers/rtc/Kconfig | 2 +-
> sound/soc/qcom/Kconfig | 2 +-
> 15 files changed, 29 insertions(+), 30 deletions(-)
> rename drivers/{mfd => platform/chrome}/cros_ec.c (100%)
>
> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> index 6f5af4196b8d..0ebc599c5e51 100644
> --- a/drivers/extcon/Kconfig
> +++ b/drivers/extcon/Kconfig
> @@ -169,7 +169,7 @@ config EXTCON_USB_GPIO
>
> config EXTCON_USBC_CROS_EC
> tristate "ChromeOS Embedded Controller EXTCON support"
> - depends on MFD_CROS_EC
> + depends on CROS_EC
> help
> Say Y here to enable USB Type C cable detection extcon support when
> using Chrome OS EC based USB Type-C ports.
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index 3872e03d9a59..a958b9625bba 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -376,7 +376,7 @@ config HOLTEK_FF
>
> config HID_GOOGLE_HAMMER
> tristate "Google Hammer Keyboard"
> - depends on USB_HID && LEDS_CLASS && MFD_CROS_EC
> + depends on USB_HID && LEDS_CLASS && CROS_EC
> ---help---
> Say Y here if you have a Google Hammer device.
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index ee5dfb5aee2a..42a224d08ec7 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -1336,7 +1336,7 @@ config I2C_SIBYTE
>
> config I2C_CROS_EC_TUNNEL
> tristate "ChromeOS EC tunnel I2C bus"
> - depends on MFD_CROS_EC
> + depends on CROS_EC
> help
> If you say yes here you get an I2C bus that will tunnel i2c commands
> through to the other side of the ChromeOS EC to the i2c bus
> diff --git a/drivers/iio/common/cros_ec_sensors/Kconfig b/drivers/iio/common/cros_ec_sensors/Kconfig
> index f9bf7ff7fcaf..55999104cd44 100644
> --- a/drivers/iio/common/cros_ec_sensors/Kconfig
> +++ b/drivers/iio/common/cros_ec_sensors/Kconfig
> @@ -4,7 +4,7 @@
> #
> config IIO_CROS_EC_SENSORS_CORE
> tristate "ChromeOS EC Sensors Core"
> - depends on SYSFS && MFD_CROS_EC
> + depends on SYSFS && CROS_EC
> select IIO_BUFFER
> select IIO_TRIGGERED_BUFFER
> help
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index 7c4f19dab34f..64555cc8d83e 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -729,7 +729,7 @@ config KEYBOARD_W90P910
> config KEYBOARD_CROS_EC
> tristate "ChromeOS EC keyboard"
> select INPUT_MATRIXKMAP
> - depends on MFD_CROS_EC
> + depends on CROS_EC
> help
> Say Y here to enable the matrix keyboard used by ChromeOS devices
> and implemented on the ChromeOS EC. You must enable one bus option
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index f2b5f27ebacb..adec7a0bfe1e 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -558,10 +558,9 @@ if CEC_PLATFORM_DRIVERS
>
> config VIDEO_CROS_EC_CEC
> tristate "ChromeOS EC CEC driver"
> - depends on MFD_CROS_EC
> + depends on CROS_EC
> select CEC_CORE
> select CEC_NOTIFIER
> - select CHROME_PLATFORMS
> select CROS_EC_PROTO
> help
> If you say yes here you will get support for the
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index a17d275bf1d4..ad0a5de74ef2 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -211,21 +211,9 @@ config MFD_AXP20X_RSB
> components like regulators or the PEK (Power Enable Key) under the
> corresponding menus.
>
> -config MFD_CROS_EC
> - tristate "ChromeOS Embedded Controller"
> - select MFD_CORE
> - select CHROME_PLATFORMS
> - select CROS_EC_PROTO
> - depends on X86 || ARM || ARM64 || COMPILE_TEST
> - help
> - If you say Y here you get support for the ChromeOS Embedded
> - Controller (EC) providing keyboard, battery and power services.
> - You also need to enable the driver for the bus you are using. The
> - protocol for talking to the EC is defined by the bus driver.
> -
> config MFD_CROS_EC_CHARDEV
> tristate "Chrome OS Embedded Controller userspace device interface"
> - depends on MFD_CROS_EC
> + depends on CROS_EC
> ---help---
> This driver adds support to talk with the ChromeOS EC from userspace.
>
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 52b1a90ff515..32327dc6bb45 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -13,8 +13,6 @@ obj-$(CONFIG_MFD_ASIC3) += asic3.o tmio_core.o
> obj-$(CONFIG_ARCH_BCM2835) += bcm2835-pm.o
> obj-$(CONFIG_MFD_BCM590XX) += bcm590xx.o
> obj-$(CONFIG_MFD_BD9571MWV) += bd9571mwv.o
> -cros_ec_core-objs := cros_ec.o
> -obj-$(CONFIG_MFD_CROS_EC) += cros_ec_core.o
> obj-$(CONFIG_MFD_CROS_EC_CHARDEV) += cros_ec_dev.o
> obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o
>
> diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig
> index 35bb5a2663f0..9417b982ad92 100644
> --- a/drivers/platform/chrome/Kconfig
> +++ b/drivers/platform/chrome/Kconfig
> @@ -50,9 +50,22 @@ config CHROMEOS_TBMC
> To compile this driver as a module, choose M here: the
> module will be called chromeos_tbmc.
>
> +config CROS_EC
> + tristate "ChromeOS Embedded Controller"
> + select CROS_EC_PROTO
> + depends on X86 || ARM || ARM64 || COMPILE_TEST
> + help
> + If you say Y here you get support for the ChromeOS Embedded
> + Controller (EC) providing keyboard, battery and power services.
> + You also need to enable the driver for the bus you are using. The
> + protocol for talking to the EC is defined by the bus driver.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called cros_ec.
> +
> config CROS_EC_I2C
> tristate "ChromeOS Embedded Controller (I2C)"
> - depends on MFD_CROS_EC && I2C
> + depends on CROS_EC && I2C
>
> help
> If you say Y here, you get support for talking to the ChromeOS
> @@ -62,7 +75,7 @@ config CROS_EC_I2C
>
> config CROS_EC_RPMSG
> tristate "ChromeOS Embedded Controller (rpmsg)"
> - depends on MFD_CROS_EC && RPMSG && OF
> + depends on CROS_EC && RPMSG && OF
> help
> If you say Y here, you get support for talking to the ChromeOS EC
> through rpmsg. This uses a simple byte-level protocol with a
> @@ -87,7 +100,7 @@ config CROS_EC_ISHTP
>
> config CROS_EC_SPI
> tristate "ChromeOS Embedded Controller (SPI)"
> - depends on MFD_CROS_EC && SPI
> + depends on CROS_EC && SPI
>
> ---help---
> If you say Y here, you get support for talking to the ChromeOS EC
> @@ -97,7 +110,7 @@ config CROS_EC_SPI
>
> config CROS_EC_LPC
> tristate "ChromeOS Embedded Controller (LPC)"
> - depends on MFD_CROS_EC && ACPI && (X86 || COMPILE_TEST)
> + depends on CROS_EC && ACPI && (X86 || COMPILE_TEST)
> help
> If you say Y here, you get support for talking to the ChromeOS EC
> over an LPC bus. This uses a simple byte-level protocol with a
> diff --git a/drivers/platform/chrome/Makefile b/drivers/platform/chrome/Makefile
> index c5583c48d1e5..ebb57e21923b 100644
> --- a/drivers/platform/chrome/Makefile
> +++ b/drivers/platform/chrome/Makefile
> @@ -6,6 +6,7 @@ CFLAGS_cros_ec_trace.o:= -I$(src)
> obj-$(CONFIG_CHROMEOS_LAPTOP) += chromeos_laptop.o
> obj-$(CONFIG_CHROMEOS_PSTORE) += chromeos_pstore.o
> obj-$(CONFIG_CHROMEOS_TBMC) += chromeos_tbmc.o
> +obj-$(CONFIG_CROS_EC) += cros_ec.o
> obj-$(CONFIG_CROS_EC_I2C) += cros_ec_i2c.o
> obj-$(CONFIG_CROS_EC_ISHTP) += cros_ec_ishtp.o
> obj-$(CONFIG_CROS_EC_RPMSG) += cros_ec_rpmsg.o
> diff --git a/drivers/mfd/cros_ec.c b/drivers/platform/chrome/cros_ec.c
> similarity index 100%
> rename from drivers/mfd/cros_ec.c
> rename to drivers/platform/chrome/cros_ec.c
> diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
> index dd7da41f230c..e05140771845 100644
> --- a/drivers/power/supply/Kconfig
> +++ b/drivers/power/supply/Kconfig
> @@ -656,7 +656,7 @@ config CHARGER_RT9455
>
> config CHARGER_CROS_USBPD
> tristate "ChromeOS EC based USBPD charger"
> - depends on MFD_CROS_EC
> + depends on CROS_EC
> default n
> help
> Say Y here to enable ChromeOS EC based USBPD charger
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index dff5a93f7daa..99946e1bcc73 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -145,7 +145,7 @@ config PWM_CRC
>
> config PWM_CROS_EC
> tristate "ChromeOS EC PWM driver"
> - depends on MFD_CROS_EC
> + depends on CROS_EC
> help
> PWM driver for exposing a PWM attached to the ChromeOS Embedded
> Controller.
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index 5c0790eed656..4eb311569fc4 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -1265,7 +1265,7 @@ config RTC_DRV_ZYNQMP
>
> config RTC_DRV_CROS_EC
> tristate "Chrome OS EC RTC driver"
> - depends on MFD_CROS_EC
> + depends on CROS_EC
> help
> If you say yes here you will get support for the
> Chrome OS Embedded Controller's RTC.
> diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig
> index 8e3e86619b35..60086858e920 100644
> --- a/sound/soc/qcom/Kconfig
> +++ b/sound/soc/qcom/Kconfig
> @@ -99,7 +99,7 @@ config SND_SOC_MSM8996
>
> config SND_SOC_SDM845
> tristate "SoC Machine driver for SDM845 boards"
> - depends on QCOM_APR && MFD_CROS_EC && I2C
> + depends on QCOM_APR && CROS_EC && I2C
> select SND_SOC_QDSP6
> select SND_SOC_QCOM_COMMON
> select SND_SOC_RT5663
> --
> 2.20.1
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox