user/sven/linux.git/drivers/extcon, branch v5.4.3

Merge tag 'tag-chrome-platform-for-v5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux

2019-09-19T21:14:28Z

Pull chrome platform updates from Benson Leung: "CrOS EC / MFD Migration: - Move cros_ec core driver from mfd into chrome platform. Wilco EC: - Add batt_ppid_info command to Wilco telemetry driver. CrOS EC: - cros_ec_rpmsg : Add support to inform EC of suspend/resume status - cros_ec_rpmsg : Fix race condition on probe failed - cros_ec_chardev : Add a poll handler to receive MKBP events Misc: - bugfixes in cros_usbpd_logger and cros_ec_ishtp" * tag 'tag-chrome-platform-for-v5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux: platform/chrome: cros_usbpd_logger: null check create_singlethread_workqueue platform/chrome: cros_ec_chardev: Add a poll handler to receive MKBP events platform/chrome: cros_ec_rpmsg: Fix race with host command when probe failed platform/chrome: chromeos_tbmc: Report wake events mfd: cros_ec: Use mfd_add_hotplug_devices() helper mfd: cros_ec: Add convenience struct to define autodetectable CrOS EC subdevices mfd: cros_ec: Add convenience struct to define dedicated CrOS EC MCUs mfd: cros_ec: Use kzalloc and cros_ec_cmd_xfer_status helper mfd / platform: cros_ec: Reorganize platform and mfd includes mfd / platform: cros_ec: Rename config to a better name mfd: cros_ec: Switch to use the new cros-ec-chardev driver mfd / platform: cros_ec: Miscellaneous character device to talk with the EC mfd / platform: cros_ec: Move cros-ec core driver out from MFD mfd / platform: cros_ec: Handle chained ECs as platform devices platform/chrome: cros_ec_rpmsg: Add host command AP sleep state support platform/chrome: chromeos_laptop: drop checks of NULL-safe functions platform/chrome: wilco_ec: Add batt_ppid_info command to telemetry driver

mfd / platform: cros_ec: Reorganize platform and mfd includes

2019-09-02T10:33:42Z

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 Acked-by: Andy Shevchenko Acked-by: Mark Brown Acked-by: Wolfram Sang Acked-by: Neil Armstrong Acked-by: Alexandre Belloni Acked-by: Jonathan Cameron Acked-by: Benjamin Tissoires Acked-by: Dmitry Torokhov Acked-by: Sebastian Reichel Acked-by: Chanwoo Choi Reviewed-by: Gwendal Grignou Tested-by: Gwendal Grignou Series changes: 3 - Fix dereferencing pointer to incomplete type 'struct cros_ec_dev' (lkp) Signed-off-by: Lee Jones

mfd / platform: cros_ec: Move cros-ec core driver out from MFD

2019-09-02T10:33:12Z

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 Acked-by: Andy Shevchenko Acked-by: Thierry Reding Acked-by: Mark Brown Acked-by: Wolfram Sang Acked-by: Neil Armstrong Acked-by: Alexandre Belloni Acked-by: Jonathan Cameron Acked-by: Benjamin Tissoires Acked-by: Dmitry Torokhov Acked-by: Sebastian Reichel Acked-by: Chanwoo Choi Reviewed-by: Gwendal Grignou Tested-by: Gwendal Grignou Signed-off-by: Lee Jones

extcon: adc-jack: Remove dev_err() usage after platform_get_irq()

2019-07-31T00:55:46Z

We don't need dev_err() messages when platform_get_irq() fails now that platform_get_irq() prints an error message itself when something goes wrong. Let's remove these prints with a simple semantic patch. Signed-off-by: Stephen Boyd [cw00.choi: Edit patch title and description for readability] Signed-off-by: Chanwoo Choi

extcon: axp288: Use for_each_set_bit() in axp288_extcon_log_rsi()

2019-07-29T01:24:14Z

This simplifies and standardizes axp288_extcon_log_rsi() by using for_each_set_bit() library function. Signed-off-by: Andy Shevchenko Signed-off-by: Chanwoo Choi

extcon: axp288: Add missed error check

2019-07-29T01:23:46Z

It seems from the very beginning the error check has been missed in axp288_extcon_log_rsi(). Add it here. Signed-off-by: Andy Shevchenko Signed-off-by: Chanwoo Choi

extcon: sm5502: Add IRQ_ONESHOT

2019-07-24T10:32:19Z

Do not fire irq again until thread done Signed-off-by: Vasyl Gomonovych Signed-off-by: Chanwoo Choi

extcon: gpio: Request reasonable interrupts

2019-07-24T10:20:19Z

The only thing that makes sense is to request a falling edge interrupt if the line is active low and a rising edge interrupt if the line is active high, so just do that and get rid of the assignment from platform data. The GPIO descriptor knows if the line is active high or low. Also make irq a local variable in probe(), it's not used anywhere else. Signed-off-by: Linus Walleij [cw00.choi: Fix build error of data->irq_flags] Signed-off-by: Chanwoo Choi

extcon: fsa9480: Support the FSA880 variant

2019-07-24T10:10:19Z

The older compatible variant of this chip is called FSA880 and works the same way, if we need some quirks in the future, it is good to let it have its own compatible string. Cc: devicetree@vger.kernel.org Signed-off-by: Linus Walleij Signed-off-by: Chanwoo Choi

extcon: extcon-max77843: convert to i2c_new_dummy_device

2019-07-24T09:59:05Z

Move from i2c_new_dummy() to i2c_new_dummy_device(), so we now get an ERRPTR which we use in error handling. Signed-off-by: Wolfram Sang Signed-off-by: Chanwoo Choi