* Re: [PATCH 02/10] mfd / platform: cros_ec: Move cros-ec core driver out from MFD
From: Sebastian Reichel @ 2019-06-11 19:52 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, 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>
[-- Attachment #1.1: Type: text/plain, Size: 10857 bytes --]
Hi,
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: Sebastian Reichel <sebastian.reichel@collabora.com>
-- Sebastian
> 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
>
[-- 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 2/2] HID: wacom: Don't report anything prior to the tool entering range
From: Greg KH @ 2019-06-11 19:22 UTC (permalink / raw)
To: Jason Gerecke
Cc: # v3.17+, Sasha Levin, Linux Input, Ping Cheng,
Aaron Armstrong Skomra, Jason Gerecke, Aaron Armstrong Skomra
In-Reply-To: <CANRwn3RBK41mRJKUPDDptoq_So6_7UxR0toaauZvjT5U=OaHWw@mail.gmail.com>
On Tue, Jun 11, 2019 at 12:02:47PM -0700, Jason Gerecke wrote:
> I haven't been keeping a close eye on this and just noticed that this
> patch set doesn't seem to have been merged into stable. There's also a
> second patch series (beginning with "[PATCH 1/3] HID: wacom: Send
> BTN_TOUCH in response to INTUOSP2_BT eraser contact") that hasn't seen
> any stable activity either.
>
> Any idea what's up?
I don't see these in my queue at all.
What is the git commit id of these patches in Linus's tree?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 2/2] HID: wacom: Don't report anything prior to the tool entering range
From: Jason Gerecke @ 2019-06-11 19:02 UTC (permalink / raw)
To: # v3.17+, Sasha Levin
Cc: Linux Input, Ping Cheng, Aaron Armstrong Skomra, Jason Gerecke,
Aaron Armstrong Skomra
In-Reply-To: <20190426163531.9782-1-jason.gerecke@wacom.com>
I haven't been keeping a close eye on this and just noticed that this
patch set doesn't seem to have been merged into stable. There's also a
second patch series (beginning with "[PATCH 1/3] HID: wacom: Send
BTN_TOUCH in response to INTUOSP2_BT eraser contact") that hasn't seen
any stable activity either.
Any idea what's up?
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three, /
So you look at the sixty-fours....
On Fri, Apr 26, 2019 at 9:35 AM Gerecke, Jason <killertofu@gmail.com> wrote:
>
> From: Jason Gerecke <jason.gerecke@wacom.com>
>
> If the tool spends some time in prox before entering range, a series of
> events (e.g. ABS_DISTANCE, MSC_SERIAL) can be sent before we or userspace
> have any clue about the pen whose data is being reported. We need to hold
> off on reporting anything until the pen has entered range. Since we still
> want to report events that occur "in prox" after the pen has *left* range
> we use 'wacom-tool[0]' as the indicator that the pen did at one point
> enter range and provide us/userspace with tool type and serial number
> information.
>
> Fixes: a48324de6d ("HID: wacom: Bluetooth IRQ for Intuos Pro should handle prox/range")
> Cc: <stable@vger.kernel.org> # 4.11+
> Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
> Reviewed-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
> ---
> Version of patch specifically targeted to stable v4.14.113
>
> drivers/hid/wacom_wac.c | 21 ++++++++++++---------
> 1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
> index 03b04bc742dd..e4aeffa56018 100644
> --- a/drivers/hid/wacom_wac.c
> +++ b/drivers/hid/wacom_wac.c
> @@ -1271,17 +1271,20 @@ static void wacom_intuos_pro2_bt_pen(struct wacom_wac *wacom)
> input_report_abs(pen_input, ABS_Z, rotation);
> input_report_abs(pen_input, ABS_WHEEL, get_unaligned_le16(&frame[11]));
> }
> - input_report_abs(pen_input, ABS_PRESSURE, get_unaligned_le16(&frame[5]));
> - input_report_abs(pen_input, ABS_DISTANCE, range ? frame[13] : wacom->features.distance_max);
>
> - input_report_key(pen_input, BTN_TOUCH, frame[0] & 0x01);
> - input_report_key(pen_input, BTN_STYLUS, frame[0] & 0x02);
> - input_report_key(pen_input, BTN_STYLUS2, frame[0] & 0x04);
> + if (wacom->tool[0]) {
> + input_report_abs(pen_input, ABS_PRESSURE, get_unaligned_le16(&frame[5]));
> + input_report_abs(pen_input, ABS_DISTANCE, range ? frame[13] : wacom->features.distance_max);
>
> - input_report_key(pen_input, wacom->tool[0], prox);
> - input_event(pen_input, EV_MSC, MSC_SERIAL, wacom->serial[0]);
> - input_report_abs(pen_input, ABS_MISC,
> - wacom_intuos_id_mangle(wacom->id[0])); /* report tool id */
> + input_report_key(pen_input, BTN_TOUCH, frame[0] & 0x01);
> + input_report_key(pen_input, BTN_STYLUS, frame[0] & 0x02);
> + input_report_key(pen_input, BTN_STYLUS2, frame[0] & 0x04);
> +
> + input_report_key(pen_input, wacom->tool[0], prox);
> + input_event(pen_input, EV_MSC, MSC_SERIAL, wacom->serial[0]);
> + input_report_abs(pen_input, ABS_MISC,
> + wacom_intuos_id_mangle(wacom->id[0])); /* report tool id */
> + }
>
> wacom->shared->stylus_in_proximity = prox;
>
> --
> 2.21.0
>
^ permalink raw reply
* Re: 答复: 答复: 答复: [PATCH] input: alps-fix the issue alps cs19 trackstick do not work.
From: dmitry.torokhov @ 2019-06-11 17:45 UTC (permalink / raw)
To: Pali Rohár
Cc: Hui Wang, Xiaoxiao Liu, XiaoXiao Liu, peter.hutterer@who-t.net,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Xiaojian Cao, zhangfp1@lenovo.com, Naoki Saito, Hideo Kawase
In-Reply-To: <20190611173856.jjwoagud6doxvpy3@pali>
On Tue, Jun 11, 2019 at 07:38:56PM +0200, Pali Rohár wrote:
> On Tuesday 11 June 2019 10:32:28 dmitry.torokhov@gmail.com wrote:
> > On Tue, Jun 11, 2019 at 07:17:07PM +0200, Pali Rohár wrote:
> > > On Tuesday 11 June 2019 10:07:07 dmitry.torokhov@gmail.com wrote:
> > > > On Tue, Jun 11, 2019 at 09:23:33AM +0200, Pali Rohár wrote:
> > > > > On Tuesday 11 June 2019 12:32:33 Hui Wang wrote:
> > > > > > On 2019/6/11 上午11:23, Hui Wang wrote:
> > > > > > > On 2019/6/11 上午11:05, Xiaoxiao Liu wrote:
> > > > > > > > Hi Pali,
> > > > > > > >
> > > > > > > > I discussed with our FW team about this problem.
> > > > > > > > We think the V8 method means a touchpad feature and does not fit
> > > > > > > > the CS19 trackpoint device.
> > > > > > > > CS19 TrackPoint needn't use any Absolute (Raw) mode and is usually
> > > > > > > > use standard mouse data.
> > > > > > > > CS19 TrackPoint device is a completely different device with
> > > > > > > > DualPoint device of Dell/HP.
> > > > > > > > CS19 TrackPoint device is independent of Touchpad. (Touchpad is
> > > > > > > > connecting by I2C, TrackPoint is directly connecting with PS2 port.)
> > > > > > > > And it has completely another FW.
> > > > > > > >
> > > > > > > > So we think it is better to use the mouse mode for CS19 trackpoint.
> > > > > > >
> > > > > > > Maybe here is some mis-understanding, the mouse mode here doesn't mean
> > > > > > > we use psmouse-base.c for cs19 (bare ps/2 mouse), we plan to use
> > > > > > > trackpoint.c to drive this HW, so this trackpoint has all features a
> > > > > > > trackpoint should have.
> > > > > > >
> > > > > > And I sent a patch one month ago to let the the trackpoint.c to drive this
> > > > > > HW: https://www.spinics.net/lists/linux-input/msg61341.html, maybe that
> > > > > > patch is reference.
> > > > >
> > > > > So instead of creating blacklist, you should check for TP_VARIANT_ALPS
> > > > > in alps.c and disallow its usage.
> > > > >
> > > > > Or maybe better, move trackpoint.c detect code before alsp.c detect code
> > > > > in psmouse-base. And no changes in alps.c are needed.
> > > >
> > > > I'd be very cautions of moving around the protocol detection. It is very
> > > > fragile, so if we can detect trackpoint-only case in alps.c and skip on
> > > > to trackpoint I would prefer it.
> > >
> > > The main problem is that proposed trackpoint-only check in alps.c is
> > > basically what trackpoint.c is doing for checking if device is
> > > trackpoint (via function trackpoint_start_protocol()).
> > >
> > > So I'm not sure now what is the best solution...
> >
> > Unfortunately currently trackpoint is being probed only after we tried
> > Elan, Genius, and Logitech PS2++ protocols, and I am not sure if moving
> > trackpoint around will disturb them or not.
> >
> > I do not think there is much code duplication by pulling limited version
> > of trackpoint detection code into alps.c and then have it bail out when
> > it sees trackpoint-only device so trackpoint.c can handle it properly.
>
> Ok. Seems that it is the best solution.
>
> The last question is, should be use ALPS or Trackpoint protocol? Because
> it looks like that device can be configured to one or other.
>
> What are pros and cons of these two protocols?
As far as I know the device implements trackpoint protocol, although not
complete version. Several manufacturers started making trackponts once
IBM/Lenovo patents on the original one expired (I think).
The data stream is regular relative PS/2, bit it allows controlling
device behavior a bit, such as press-to-select option and device
sensitivity. IBM/Lenovo version has many more parameters.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: 答复: 答复: 答复: [PATCH] input: alps-fix the issue alps cs19 trackstick do not work.
From: Pali Rohár @ 2019-06-11 17:38 UTC (permalink / raw)
To: dmitry.torokhov@gmail.com
Cc: Hui Wang, Xiaoxiao Liu, XiaoXiao Liu, peter.hutterer@who-t.net,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Xiaojian Cao, zhangfp1@lenovo.com, Naoki Saito, Hideo Kawase
In-Reply-To: <20190611173228.GD143729@dtor-ws>
[-- Attachment #1: Type: text/plain, Size: 3202 bytes --]
On Tuesday 11 June 2019 10:32:28 dmitry.torokhov@gmail.com wrote:
> On Tue, Jun 11, 2019 at 07:17:07PM +0200, Pali Rohár wrote:
> > On Tuesday 11 June 2019 10:07:07 dmitry.torokhov@gmail.com wrote:
> > > On Tue, Jun 11, 2019 at 09:23:33AM +0200, Pali Rohár wrote:
> > > > On Tuesday 11 June 2019 12:32:33 Hui Wang wrote:
> > > > > On 2019/6/11 上午11:23, Hui Wang wrote:
> > > > > > On 2019/6/11 上午11:05, Xiaoxiao Liu wrote:
> > > > > > > Hi Pali,
> > > > > > >
> > > > > > > I discussed with our FW team about this problem.
> > > > > > > We think the V8 method means a touchpad feature and does not fit
> > > > > > > the CS19 trackpoint device.
> > > > > > > CS19 TrackPoint needn't use any Absolute (Raw) mode and is usually
> > > > > > > use standard mouse data.
> > > > > > > CS19 TrackPoint device is a completely different device with
> > > > > > > DualPoint device of Dell/HP.
> > > > > > > CS19 TrackPoint device is independent of Touchpad. (Touchpad is
> > > > > > > connecting by I2C, TrackPoint is directly connecting with PS2 port.)
> > > > > > > And it has completely another FW.
> > > > > > >
> > > > > > > So we think it is better to use the mouse mode for CS19 trackpoint.
> > > > > >
> > > > > > Maybe here is some mis-understanding, the mouse mode here doesn't mean
> > > > > > we use psmouse-base.c for cs19 (bare ps/2 mouse), we plan to use
> > > > > > trackpoint.c to drive this HW, so this trackpoint has all features a
> > > > > > trackpoint should have.
> > > > > >
> > > > > And I sent a patch one month ago to let the the trackpoint.c to drive this
> > > > > HW: https://www.spinics.net/lists/linux-input/msg61341.html, maybe that
> > > > > patch is reference.
> > > >
> > > > So instead of creating blacklist, you should check for TP_VARIANT_ALPS
> > > > in alps.c and disallow its usage.
> > > >
> > > > Or maybe better, move trackpoint.c detect code before alsp.c detect code
> > > > in psmouse-base. And no changes in alps.c are needed.
> > >
> > > I'd be very cautions of moving around the protocol detection. It is very
> > > fragile, so if we can detect trackpoint-only case in alps.c and skip on
> > > to trackpoint I would prefer it.
> >
> > The main problem is that proposed trackpoint-only check in alps.c is
> > basically what trackpoint.c is doing for checking if device is
> > trackpoint (via function trackpoint_start_protocol()).
> >
> > So I'm not sure now what is the best solution...
>
> Unfortunately currently trackpoint is being probed only after we tried
> Elan, Genius, and Logitech PS2++ protocols, and I am not sure if moving
> trackpoint around will disturb them or not.
>
> I do not think there is much code duplication by pulling limited version
> of trackpoint detection code into alps.c and then have it bail out when
> it sees trackpoint-only device so trackpoint.c can handle it properly.
Ok. Seems that it is the best solution.
The last question is, should be use ALPS or Trackpoint protocol? Because
it looks like that device can be configured to one or other.
What are pros and cons of these two protocols?
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] Input: synaptics-rmi4 - clear irqs before set irqs
From: Dmitry Torokhov @ 2019-06-11 17:35 UTC (permalink / raw)
To: Aaron Ma; +Cc: linux-input, linux-kernel, Cheiny, aduggan, benjamin.tissoires
In-Reply-To: <7da443d0-f433-c5a5-5194-707362eb2ee5@canonical.com>
On Tue, Jun 11, 2019 at 12:55:58AM +0800, Aaron Ma wrote:
>
> On 6/10/19 12:55 AM, Dmitry Torokhov wrote:
> > Hi Aaron,
> >
> > On Wed, Feb 20, 2019 at 05:41:59PM +0100, Aaron Ma wrote:
> >> rmi4 got spam data after S3 resume on some ThinkPads.
> >> Then TrackPoint lost when be detected by psmouse.
> >> Clear irqs status before set irqs will make TrackPoint back.
> > Could you please give me an idea as to what this spam data is?
> >
>
> It should be some data 0 during suspend/resume.
> Actually I don't know how these data 0 is produced.
> Not all synaptics touchpads have this issue.
>
> > In F03 probe we clear all pending data before enabling the function,
>
> Yes we did, but not after resume.
Yes, I understand that. The question I was asking: if we add code
consuming all pending data to f03->suspend(), similarly to what we are
doing at probe time, will it fix the issue with trackstick losing
synchronization and attempting disconnect?
>
> > maybe the same needs to be done on resume, instead of changing the way
> > we handle IRQ bits?
>
> This patch is supposed to clear irq status like it in fn probe. Not
> changing IRQ bits.
What I meant is changing how we enable IRQ bits. I would really prefer
we did not lose IRQ state for other functions when we enable interrupts
for given function.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: 答复: 答复: 答复: [PATCH] input: alps-fix the issue alps cs19 trackstick do not work.
From: dmitry.torokhov @ 2019-06-11 17:32 UTC (permalink / raw)
To: Pali Rohár
Cc: Hui Wang, Xiaoxiao Liu, XiaoXiao Liu, peter.hutterer@who-t.net,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Xiaojian Cao, zhangfp1@lenovo.com, Naoki Saito, Hideo Kawase
In-Reply-To: <20190611171707.tydk7rsmtzmjohky@pali>
On Tue, Jun 11, 2019 at 07:17:07PM +0200, Pali Rohár wrote:
> On Tuesday 11 June 2019 10:07:07 dmitry.torokhov@gmail.com wrote:
> > On Tue, Jun 11, 2019 at 09:23:33AM +0200, Pali Rohár wrote:
> > > On Tuesday 11 June 2019 12:32:33 Hui Wang wrote:
> > > > On 2019/6/11 上午11:23, Hui Wang wrote:
> > > > > On 2019/6/11 上午11:05, Xiaoxiao Liu wrote:
> > > > > > Hi Pali,
> > > > > >
> > > > > > I discussed with our FW team about this problem.
> > > > > > We think the V8 method means a touchpad feature and does not fit
> > > > > > the CS19 trackpoint device.
> > > > > > CS19 TrackPoint needn't use any Absolute (Raw) mode and is usually
> > > > > > use standard mouse data.
> > > > > > CS19 TrackPoint device is a completely different device with
> > > > > > DualPoint device of Dell/HP.
> > > > > > CS19 TrackPoint device is independent of Touchpad. (Touchpad is
> > > > > > connecting by I2C, TrackPoint is directly connecting with PS2 port.)
> > > > > > And it has completely another FW.
> > > > > >
> > > > > > So we think it is better to use the mouse mode for CS19 trackpoint.
> > > > >
> > > > > Maybe here is some mis-understanding, the mouse mode here doesn't mean
> > > > > we use psmouse-base.c for cs19 (bare ps/2 mouse), we plan to use
> > > > > trackpoint.c to drive this HW, so this trackpoint has all features a
> > > > > trackpoint should have.
> > > > >
> > > > And I sent a patch one month ago to let the the trackpoint.c to drive this
> > > > HW: https://www.spinics.net/lists/linux-input/msg61341.html, maybe that
> > > > patch is reference.
> > >
> > > So instead of creating blacklist, you should check for TP_VARIANT_ALPS
> > > in alps.c and disallow its usage.
> > >
> > > Or maybe better, move trackpoint.c detect code before alsp.c detect code
> > > in psmouse-base. And no changes in alps.c are needed.
> >
> > I'd be very cautions of moving around the protocol detection. It is very
> > fragile, so if we can detect trackpoint-only case in alps.c and skip on
> > to trackpoint I would prefer it.
>
> The main problem is that proposed trackpoint-only check in alps.c is
> basically what trackpoint.c is doing for checking if device is
> trackpoint (via function trackpoint_start_protocol()).
>
> So I'm not sure now what is the best solution...
Unfortunately currently trackpoint is being probed only after we tried
Elan, Genius, and Logitech PS2++ protocols, and I am not sure if moving
trackpoint around will disturb them or not.
I do not think there is much code duplication by pulling limited version
of trackpoint detection code into alps.c and then have it bail out when
it sees trackpoint-only device so trackpoint.c can handle it properly.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: 答复: 答复: 答复: [PATCH] input: alps-fix the issue alps cs19 trackstick do not work.
From: Pali Rohár @ 2019-06-11 17:17 UTC (permalink / raw)
To: dmitry.torokhov@gmail.com
Cc: Hui Wang, Xiaoxiao Liu, XiaoXiao Liu, peter.hutterer@who-t.net,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Xiaojian Cao, zhangfp1@lenovo.com, Naoki Saito, Hideo Kawase
In-Reply-To: <20190611170707.GA143729@dtor-ws>
[-- Attachment #1: Type: text/plain, Size: 2235 bytes --]
On Tuesday 11 June 2019 10:07:07 dmitry.torokhov@gmail.com wrote:
> On Tue, Jun 11, 2019 at 09:23:33AM +0200, Pali Rohár wrote:
> > On Tuesday 11 June 2019 12:32:33 Hui Wang wrote:
> > > On 2019/6/11 上午11:23, Hui Wang wrote:
> > > > On 2019/6/11 上午11:05, Xiaoxiao Liu wrote:
> > > > > Hi Pali,
> > > > >
> > > > > I discussed with our FW team about this problem.
> > > > > We think the V8 method means a touchpad feature and does not fit
> > > > > the CS19 trackpoint device.
> > > > > CS19 TrackPoint needn't use any Absolute (Raw) mode and is usually
> > > > > use standard mouse data.
> > > > > CS19 TrackPoint device is a completely different device with
> > > > > DualPoint device of Dell/HP.
> > > > > CS19 TrackPoint device is independent of Touchpad. (Touchpad is
> > > > > connecting by I2C, TrackPoint is directly connecting with PS2 port.)
> > > > > And it has completely another FW.
> > > > >
> > > > > So we think it is better to use the mouse mode for CS19 trackpoint.
> > > >
> > > > Maybe here is some mis-understanding, the mouse mode here doesn't mean
> > > > we use psmouse-base.c for cs19 (bare ps/2 mouse), we plan to use
> > > > trackpoint.c to drive this HW, so this trackpoint has all features a
> > > > trackpoint should have.
> > > >
> > > And I sent a patch one month ago to let the the trackpoint.c to drive this
> > > HW: https://www.spinics.net/lists/linux-input/msg61341.html, maybe that
> > > patch is reference.
> >
> > So instead of creating blacklist, you should check for TP_VARIANT_ALPS
> > in alps.c and disallow its usage.
> >
> > Or maybe better, move trackpoint.c detect code before alsp.c detect code
> > in psmouse-base. And no changes in alps.c are needed.
>
> I'd be very cautions of moving around the protocol detection. It is very
> fragile, so if we can detect trackpoint-only case in alps.c and skip on
> to trackpoint I would prefer it.
The main problem is that proposed trackpoint-only check in alps.c is
basically what trackpoint.c is doing for checking if device is
trackpoint (via function trackpoint_start_protocol()).
So I'm not sure now what is the best solution...
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply
* Re: [PATCH 06/10] mfd / platform: cros_ec: Reorganize platform and mfd includes
From: Dmitry Torokhov @ 2019-06-11 17:10 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>
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: Dmitry Torokhov <dmitry.torokhov@gmail.com> # for input
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 02/10] mfd / platform: cros_ec: Move cros-ec core driver out from MFD
From: Dmitry Torokhov @ 2019-06-11 17:09 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>
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: Dmitry Torokhov <dmitry.torokhov@gmail.com> # for input
Thanks.
--
Dmitry
^ permalink raw reply
* Re: 答复: 答复: 答复: [PATCH] input: alps-fix the issue alps cs19 trackstick do not work.
From: dmitry.torokhov @ 2019-06-11 17:07 UTC (permalink / raw)
To: Pali Rohár
Cc: Hui Wang, Xiaoxiao Liu, XiaoXiao Liu, peter.hutterer@who-t.net,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Xiaojian Cao, zhangfp1@lenovo.com, Naoki Saito, Hideo Kawase
In-Reply-To: <20190611072333.nd4va4q2m5epmukc@pali>
On Tue, Jun 11, 2019 at 09:23:33AM +0200, Pali Rohár wrote:
> On Tuesday 11 June 2019 12:32:33 Hui Wang wrote:
> > On 2019/6/11 上午11:23, Hui Wang wrote:
> > > On 2019/6/11 上午11:05, Xiaoxiao Liu wrote:
> > > > Hi Pali,
> > > >
> > > > I discussed with our FW team about this problem.
> > > > We think the V8 method means a touchpad feature and does not fit
> > > > the CS19 trackpoint device.
> > > > CS19 TrackPoint needn't use any Absolute (Raw) mode and is usually
> > > > use standard mouse data.
> > > > CS19 TrackPoint device is a completely different device with
> > > > DualPoint device of Dell/HP.
> > > > CS19 TrackPoint device is independent of Touchpad. (Touchpad is
> > > > connecting by I2C, TrackPoint is directly connecting with PS2 port.)
> > > > And it has completely another FW.
> > > >
> > > > So we think it is better to use the mouse mode for CS19 trackpoint.
> > >
> > > Maybe here is some mis-understanding, the mouse mode here doesn't mean
> > > we use psmouse-base.c for cs19 (bare ps/2 mouse), we plan to use
> > > trackpoint.c to drive this HW, so this trackpoint has all features a
> > > trackpoint should have.
> > >
> > And I sent a patch one month ago to let the the trackpoint.c to drive this
> > HW: https://www.spinics.net/lists/linux-input/msg61341.html, maybe that
> > patch is reference.
>
> So instead of creating blacklist, you should check for TP_VARIANT_ALPS
> in alps.c and disallow its usage.
>
> Or maybe better, move trackpoint.c detect code before alsp.c detect code
> in psmouse-base. And no changes in alps.c are needed.
I'd be very cautions of moving around the protocol detection. It is very
fragile, so if we can detect trackpoint-only case in alps.c and skip on
to trackpoint I would prefer it.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] HID: input: fix a4tech horizontal wheel custom usage
From: Benjamin Tissoires @ 2019-06-11 14:42 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: Jiri Kosina, Dmitry Torokhov, wbauer, open list:HID CORE LAYER,
lkml
In-Reply-To: <20190611121320.30267-1-nsaenzjulienne@suse.de>
On Tue, Jun 11, 2019 at 2:13 PM Nicolas Saenz Julienne
<nsaenzjulienne@suse.de> wrote:
>
> Some a4tech mice use the 'GenericDesktop.00b8' usage to inform whether
> the previous wheel report was horizontal or vertical. Before
> c01908a14bf73 ("HID: input: add mapping for "Toggle Display" key") this
> usage was being mapped to 'Relative.Misc'. After the patch it's simply
> ignored (usage->type == 0 & usage->code == 0). Which ultimately makes
> hid-a4tech ignore the WHEEL/HWHEEL selection event, as it has no
> usage->type.
>
> We shouldn't rely on a mapping for that usage as it's nonstandard and
> doesn't really map to an input event. So we bypass the mapping and make
> sure the custom event handling properly handles both reports.
>
> Fixes: c01908a14bf73 ("HID: input: add mapping for "Toggle Display" key")
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> ---
Yep, I like this one much better.
>
> NOTE: I CC'd Wolfgang as he's the one who can test this.
I'll wait for Wolfram to confirm that the patch works before pushing then.
>
> Changes since v1:
> - new approach, moved fix into hid-a4tech
>
> drivers/hid/hid-a4tech.c | 30 +++++++++++++++++++++++++++---
> 1 file changed, 27 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hid/hid-a4tech.c b/drivers/hid/hid-a4tech.c
> index 98bf694626f7..3a8c4a5971f7 100644
> --- a/drivers/hid/hid-a4tech.c
> +++ b/drivers/hid/hid-a4tech.c
> @@ -23,12 +23,36 @@
> #define A4_2WHEEL_MOUSE_HACK_7 0x01
> #define A4_2WHEEL_MOUSE_HACK_B8 0x02
>
> +#define A4_WHEEL_ORIENTATION (HID_UP_GENDESK | 0x000000b8)
> +
> struct a4tech_sc {
> unsigned long quirks;
> unsigned int hw_wheel;
> __s32 delayed_value;
> };
>
> +static int a4_input_mapping(struct hid_device *hdev, struct hid_input *hi,
> + struct hid_field *field, struct hid_usage *usage,
> + unsigned long **bit, int *max)
> +{
> + struct a4tech_sc *a4 = hid_get_drvdata(hdev);
> +
> + if (a4->quirks & A4_2WHEEL_MOUSE_HACK_B8 &&
> + usage->hid == A4_WHEEL_ORIENTATION) {
> + /*
> + * We do not want to have this usage mapped to anything as it's
> + * nonstandard and doesn't really behave like an HID report.
> + * It's only selecting the orientation (vertical/horizontal) of
> + * the previous mouse wheel report. The input_events will be
> + * generated once both reports are recorded in a4_event().
> + */
> + return -1;
You seem to be extra precocious here. This is basically what the
current hid-input.c mapping does. But I think it is for the best,
given that this time you are locking the behavior of this reserved
usage.
Cheers,
Benjamin
> + }
> +
> + return 0;
> +
> +}
> +
> static int a4_input_mapped(struct hid_device *hdev, struct hid_input *hi,
> struct hid_field *field, struct hid_usage *usage,
> unsigned long **bit, int *max)
> @@ -52,8 +76,7 @@ static int a4_event(struct hid_device *hdev, struct hid_field *field,
> struct a4tech_sc *a4 = hid_get_drvdata(hdev);
> struct input_dev *input;
>
> - if (!(hdev->claimed & HID_CLAIMED_INPUT) || !field->hidinput ||
> - !usage->type)
> + if (!(hdev->claimed & HID_CLAIMED_INPUT) || !field->hidinput)
> return 0;
>
> input = field->hidinput->input;
> @@ -64,7 +87,7 @@ static int a4_event(struct hid_device *hdev, struct hid_field *field,
> return 1;
> }
>
> - if (usage->hid == 0x000100b8) {
> + if (usage->hid == A4_WHEEL_ORIENTATION) {
> input_event(input, EV_REL, value ? REL_HWHEEL :
> REL_WHEEL, a4->delayed_value);
> input_event(input, EV_REL, value ? REL_HWHEEL_HI_RES :
> @@ -131,6 +154,7 @@ MODULE_DEVICE_TABLE(hid, a4_devices);
> static struct hid_driver a4_driver = {
> .name = "a4tech",
> .id_table = a4_devices,
> + .input_mapping = a4_input_mapping,
> .input_mapped = a4_input_mapped,
> .event = a4_event,
> .probe = a4_probe,
> --
> 2.21.0
>
^ permalink raw reply
* [PATCH v2] HID: input: fix a4tech horizontal wheel custom usage
From: Nicolas Saenz Julienne @ 2019-06-11 12:13 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: dmitry.torokhov, wbauer, Nicolas Saenz Julienne, linux-input,
linux-kernel
Some a4tech mice use the 'GenericDesktop.00b8' usage to inform whether
the previous wheel report was horizontal or vertical. Before
c01908a14bf73 ("HID: input: add mapping for "Toggle Display" key") this
usage was being mapped to 'Relative.Misc'. After the patch it's simply
ignored (usage->type == 0 & usage->code == 0). Which ultimately makes
hid-a4tech ignore the WHEEL/HWHEEL selection event, as it has no
usage->type.
We shouldn't rely on a mapping for that usage as it's nonstandard and
doesn't really map to an input event. So we bypass the mapping and make
sure the custom event handling properly handles both reports.
Fixes: c01908a14bf73 ("HID: input: add mapping for "Toggle Display" key")
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
NOTE: I CC'd Wolfgang as he's the one who can test this.
Changes since v1:
- new approach, moved fix into hid-a4tech
drivers/hid/hid-a4tech.c | 30 +++++++++++++++++++++++++++---
1 file changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-a4tech.c b/drivers/hid/hid-a4tech.c
index 98bf694626f7..3a8c4a5971f7 100644
--- a/drivers/hid/hid-a4tech.c
+++ b/drivers/hid/hid-a4tech.c
@@ -23,12 +23,36 @@
#define A4_2WHEEL_MOUSE_HACK_7 0x01
#define A4_2WHEEL_MOUSE_HACK_B8 0x02
+#define A4_WHEEL_ORIENTATION (HID_UP_GENDESK | 0x000000b8)
+
struct a4tech_sc {
unsigned long quirks;
unsigned int hw_wheel;
__s32 delayed_value;
};
+static int a4_input_mapping(struct hid_device *hdev, struct hid_input *hi,
+ struct hid_field *field, struct hid_usage *usage,
+ unsigned long **bit, int *max)
+{
+ struct a4tech_sc *a4 = hid_get_drvdata(hdev);
+
+ if (a4->quirks & A4_2WHEEL_MOUSE_HACK_B8 &&
+ usage->hid == A4_WHEEL_ORIENTATION) {
+ /*
+ * We do not want to have this usage mapped to anything as it's
+ * nonstandard and doesn't really behave like an HID report.
+ * It's only selecting the orientation (vertical/horizontal) of
+ * the previous mouse wheel report. The input_events will be
+ * generated once both reports are recorded in a4_event().
+ */
+ return -1;
+ }
+
+ return 0;
+
+}
+
static int a4_input_mapped(struct hid_device *hdev, struct hid_input *hi,
struct hid_field *field, struct hid_usage *usage,
unsigned long **bit, int *max)
@@ -52,8 +76,7 @@ static int a4_event(struct hid_device *hdev, struct hid_field *field,
struct a4tech_sc *a4 = hid_get_drvdata(hdev);
struct input_dev *input;
- if (!(hdev->claimed & HID_CLAIMED_INPUT) || !field->hidinput ||
- !usage->type)
+ if (!(hdev->claimed & HID_CLAIMED_INPUT) || !field->hidinput)
return 0;
input = field->hidinput->input;
@@ -64,7 +87,7 @@ static int a4_event(struct hid_device *hdev, struct hid_field *field,
return 1;
}
- if (usage->hid == 0x000100b8) {
+ if (usage->hid == A4_WHEEL_ORIENTATION) {
input_event(input, EV_REL, value ? REL_HWHEEL :
REL_WHEEL, a4->delayed_value);
input_event(input, EV_REL, value ? REL_HWHEEL_HI_RES :
@@ -131,6 +154,7 @@ MODULE_DEVICE_TABLE(hid, a4_devices);
static struct hid_driver a4_driver = {
.name = "a4tech",
.id_table = a4_devices,
+ .input_mapping = a4_input_mapping,
.input_mapped = a4_input_mapped,
.event = a4_event,
.probe = a4_probe,
--
2.21.0
^ permalink raw reply related
* Re: [PATCH] HID: input: fix a4tech horizontal wheel custom usage id
From: Nicolas Saenz Julienne @ 2019-06-11 11:33 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, Dmitry Torokhov, open list:HID CORE LAYER, lkml
In-Reply-To: <CAO-hwJJzYFQs_Jxc+3zYHzjM9G8zdTfBqdpO27hpKXRBKytvQA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2877 bytes --]
On Tue, 2019-06-11 at 10:43 +0200, Benjamin Tissoires wrote:
> Hi Nicolas,
>
> On Mon, Jun 10, 2019 at 8:54 PM Nicolas Saenz Julienne
> <nsaenzjulienne@suse.de> wrote:
> > Some a4tech mice use the 'GenericDesktop.00b8' usage id to inform
> > whether the previous wheel report was horizontal or vertical. Before
> > c01908a14bf73 ("HID: input: add mapping for "Toggle Display" key") this
> > usage id was being mapped to 'Relative.Misc'. After the patch it's
> > simply ignored (usage->type == 0 & usage->code == 0). Checking the HID
> > Usage Tables it turns out it's a reserved usage_id, so it makes sense to
> > map it the way it was. Ultimately this makes hid-a4tech ignore the
> > WHEEL/HWHEEL selection event, as it has no usage->type.
> >
> > The patch reverts the handling of the usage id back to it's previous
> > behavior.
>
> Hmm, if A4Tech is using a reserved usage, we shouldn't fix this in
> hid-input.c but in hid-a4tech instead.
> Because you won't know when someone else in the HID consortium will
> remap this usage to some other random axis, and your mouse will be
> broken again.
>
> How about you add a .input_mapping callback in hid-a4tech and map this
> usage there to your needs? This way you will be sure that such a
> situation will not happen again.
I agree it would be a cleaner solution.
In summary the first report indicates the wheel relative value, the second the
orientation. The first report is already being mapped to REL_WHEEL and
REL_WHEEL (or the high-res versions), but what would be a correct code for the
second report? The way I see it, we shouldn't map it to anything. And then
catch both events in the custom driver to build the input_event() accordinlgy
(as it's almost being done already). Is this somewhat correct? I'll send a
followup patch anyway so we have something more tangible comment on.
> > Fixes: c01908a14bf73 ("HID: input: add mapping for "Toggle Display" key")
> > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> > ---
> > drivers/hid/hid-input.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> > index 63855f275a38..6a956d5a195e 100644
> > --- a/drivers/hid/hid-input.c
> > +++ b/drivers/hid/hid-input.c
> > @@ -671,7 +671,7 @@ static void hidinput_configure_usage(struct hid_input
> > *hidinput, struct hid_fiel
> > if ((usage->hid & 0xf0) == 0xb0) { /* SC - Display */
> > switch (usage->hid & 0xf) {
> > case 0x05: map_key_clear(KEY_SWITCHVIDEOMODE);
> > break;
> > - default: goto ignore;
> > + default: goto unknown;
> > }
> > break;
> > }
> > --
> > 2.21.0
> >
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH -next] HID: logitech-dj: fix return value of logi_dj_recv_query_hidpp_devices
From: Benjamin Tissoires @ 2019-06-11 10:48 UTC (permalink / raw)
To: Yuehaibing
Cc: Jiri Kosina, Hans de Goede, jkosina, lkml,
open list:HID CORE LAYER
In-Reply-To: <50800f5e-867d-ded9-235c-b9c2db1c41ef@huawei.com>
On Tue, Jun 11, 2019 at 5:01 AM Yuehaibing <yuehaibing@huawei.com> wrote:
>
> Hi all,
>
> Friendly ping...
Applied to for-5.3/logitech
Thanks!
Cheers,
Benjamin
>
> On 2019/5/25 22:09, YueHaibing wrote:
> > We should return 'retval' as the correct return value
> > instead of always zero.
> >
> > Fixes: 74808f9115ce ("HID: logitech-dj: add support for non unifying receivers")
> > Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> > ---
> > drivers/hid/hid-logitech-dj.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
> > index 41baa4dbbfcc..7f8db602eec0 100644
> > --- a/drivers/hid/hid-logitech-dj.c
> > +++ b/drivers/hid/hid-logitech-dj.c
> > @@ -1133,7 +1133,7 @@ static int logi_dj_recv_query_hidpp_devices(struct dj_receiver_dev *djrcv_dev)
> > HID_REQ_SET_REPORT);
> >
> > kfree(hidpp_report);
> > - return 0;
> > + return retval;
> > }
> >
> > static int logi_dj_recv_query_paired_devices(struct dj_receiver_dev *djrcv_dev)
> >
>
^ permalink raw reply
* Re: [PATCH 02/10] mfd / platform: cros_ec: Move cros-ec core driver out from MFD
From: Benjamin Tissoires @ 2019-06-11 9:20 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: Gwendal Grignou, Banajit Goswami, Vignesh R, Alexandre Belloni,
Wolfram Sang, linux-iio, Mark Brown, Juergen Fitschen, alsa-devel,
Stefan Agner, Sebastian Reichel, Thierry Reding,
Karthikeyan Ramasubramanian, Linux I2C, Peter Meerwald-Stadler,
Manivannan Sadhasivam, Guenter Roeck, kernel, Dmitry Torokhov,
Lars-Peter Clausen, Jean Delvare, Jacky Bai, linux-rtc,
Andy Shevchenko <andriy.s>
In-Reply-To: <20190604152019.16100-3-enric.balletbo@collabora.com>
On Tue, Jun 4, 2019 at 5:20 PM Enric Balletbo i Serra
<enric.balletbo@collabora.com> 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: Benjamin Tissoires <benjamin.tissoires@redhat.com> # for the HID part
Cheers,
Benjamin
>
> 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
>
^ permalink raw reply
* Re: [PATCH 06/10] mfd / platform: cros_ec: Reorganize platform and mfd includes
From: Benjamin Tissoires @ 2019-06-11 9:20 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: lkml, Gwendal Grignou, Guenter Roeck, Benson Leung, Lee Jones,
kernel, Dmitry Torokhov, Mauro Carvalho Chehab, alsa-devel,
Alessandro Zummo, linux-iio, Fabien Lahoudere, Alexandre Belloni,
Linux I2C, linux-rtc, Heiko Stuebner, Brian Norris, Chanwoo Choi,
Gustavo A. R. Silva, Sebastian Reichel, Rus
In-Reply-To: <20190604152019.16100-7-enric.balletbo@collabora.com>
On Tue, Jun 4, 2019 at 5:21 PM Enric Balletbo i Serra
<enric.balletbo@collabora.com> 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: Benjamin Tissoires <benjamin.tissoires@redhat.com> # for the HID part
Cheers,
Benjamin
>
> 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
>
> diff --git a/drivers/extcon/extcon-usbc-cros-ec.c b/drivers/extcon/extcon-usbc-cros-ec.c
> index 43c0a936ab82..5290cc2d19d9 100644
> --- a/drivers/extcon/extcon-usbc-cros-ec.c
> +++ b/drivers/extcon/extcon-usbc-cros-ec.c
> @@ -6,10 +6,11 @@
>
> #include <linux/extcon-provider.h>
> #include <linux/kernel.h>
> -#include <linux/mfd/cros_ec.h>
> #include <linux/module.h>
> #include <linux/notifier.h>
> #include <linux/of.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
> #include <linux/platform_device.h>
> #include <linux/slab.h>
> #include <linux/sched.h>
> diff --git a/drivers/hid/hid-google-hammer.c b/drivers/hid/hid-google-hammer.c
> index ee5e0bdcf078..84f8c127ebdc 100644
> --- a/drivers/hid/hid-google-hammer.c
> +++ b/drivers/hid/hid-google-hammer.c
> @@ -16,9 +16,9 @@
> #include <linux/acpi.h>
> #include <linux/hid.h>
> #include <linux/leds.h>
> -#include <linux/mfd/cros_ec.h>
> -#include <linux/mfd/cros_ec_commands.h>
> #include <linux/module.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
> #include <linux/platform_device.h>
> #include <linux/pm_wakeup.h>
> #include <asm/unaligned.h>
> diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> index 82bcd9a78759..c551aa96a2e3 100644
> --- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> +++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> @@ -5,8 +5,8 @@
>
> #include <linux/module.h>
> #include <linux/i2c.h>
> -#include <linux/mfd/cros_ec.h>
> -#include <linux/mfd/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
> #include <linux/platform_device.h>
> #include <linux/slab.h>
>
> diff --git a/drivers/iio/accel/cros_ec_accel_legacy.c b/drivers/iio/accel/cros_ec_accel_legacy.c
> index 46bb2e421bb9..fd9a634f741e 100644
> --- a/drivers/iio/accel/cros_ec_accel_legacy.c
> +++ b/drivers/iio/accel/cros_ec_accel_legacy.c
> @@ -18,9 +18,10 @@
> #include <linux/iio/triggered_buffer.h>
> #include <linux/kernel.h>
> #include <linux/mfd/cros_ec.h>
> -#include <linux/mfd/cros_ec_commands.h>
> #include <linux/module.h>
> #include <linux/slab.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
> #include <linux/platform_device.h>
>
> #define DRV_NAME "cros-ec-accel-legacy"
> diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
> index 17af4e0fd5f8..40dc24ff0ee5 100644
> --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
> +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
> @@ -17,8 +17,9 @@
> #include <linux/iio/triggered_buffer.h>
> #include <linux/kernel.h>
> #include <linux/mfd/cros_ec.h>
> -#include <linux/mfd/cros_ec_commands.h>
> #include <linux/module.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
> #include <linux/platform_device.h>
> #include <linux/slab.h>
>
> diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> index 719a0df5aeeb..fd63315399ac 100644
> --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> @@ -14,9 +14,10 @@
> #include <linux/iio/trigger_consumer.h>
> #include <linux/kernel.h>
> #include <linux/mfd/cros_ec.h>
> -#include <linux/mfd/cros_ec_commands.h>
> #include <linux/module.h>
> #include <linux/slab.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
> #include <linux/platform_device.h>
>
> static char *cros_ec_loc[] = {
> diff --git a/drivers/iio/light/cros_ec_light_prox.c b/drivers/iio/light/cros_ec_light_prox.c
> index 308ee6ff2e22..437e0eae9178 100644
> --- a/drivers/iio/light/cros_ec_light_prox.c
> +++ b/drivers/iio/light/cros_ec_light_prox.c
> @@ -15,8 +15,9 @@
> #include <linux/iio/trigger_consumer.h>
> #include <linux/kernel.h>
> #include <linux/mfd/cros_ec.h>
> -#include <linux/mfd/cros_ec_commands.h>
> #include <linux/module.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
> #include <linux/platform_device.h>
> #include <linux/slab.h>
>
> diff --git a/drivers/iio/pressure/cros_ec_baro.c b/drivers/iio/pressure/cros_ec_baro.c
> index 034ce98d6e97..956dc01f1295 100644
> --- a/drivers/iio/pressure/cros_ec_baro.c
> +++ b/drivers/iio/pressure/cros_ec_baro.c
> @@ -15,9 +15,10 @@
> #include <linux/iio/trigger_consumer.h>
> #include <linux/kernel.h>
> #include <linux/mfd/cros_ec.h>
> -#include <linux/mfd/cros_ec_commands.h>
> #include <linux/module.h>
> #include <linux/slab.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
> #include <linux/platform_device.h>
>
> /*
> diff --git a/drivers/input/keyboard/cros_ec_keyb.c b/drivers/input/keyboard/cros_ec_keyb.c
> index d56001181598..2b71c5a51f90 100644
> --- a/drivers/input/keyboard/cros_ec_keyb.c
> +++ b/drivers/input/keyboard/cros_ec_keyb.c
> @@ -22,8 +22,8 @@
> #include <linux/slab.h>
> #include <linux/sysrq.h>
> #include <linux/input/matrix_keypad.h>
> -#include <linux/mfd/cros_ec.h>
> -#include <linux/mfd/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
>
> #include <asm/unaligned.h>
>
> diff --git a/drivers/media/platform/cros-ec-cec/cros-ec-cec.c b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
> index 068df9888dbf..2e4e263a4a94 100644
> --- a/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
> +++ b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
> @@ -16,8 +16,8 @@
> #include <linux/interrupt.h>
> #include <media/cec.h>
> #include <media/cec-notifier.h>
> -#include <linux/mfd/cros_ec.h>
> -#include <linux/mfd/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
>
> #define DRV_NAME "cros-ec-cec"
>
> diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
> index c7a5dfa36874..5481df4e1216 100644
> --- a/drivers/mfd/cros_ec_dev.c
> +++ b/drivers/mfd/cros_ec_dev.c
> @@ -7,11 +7,12 @@
>
> #include <linux/mfd/core.h>
> #include <linux/mfd/cros_ec.h>
> -#include <linux/mfd/cros_ec_commands.h>
> #include <linux/module.h>
> #include <linux/mod_devicetable.h>
> #include <linux/of_platform.h>
> #include <linux/platform_device.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
> #include <linux/slab.h>
>
> #define DRV_NAME "cros-ec-dev"
> diff --git a/drivers/platform/chrome/cros_ec.c b/drivers/platform/chrome/cros_ec.c
> index 11fced7917fc..9800597ccd96 100644
> --- a/drivers/platform/chrome/cros_ec.c
> +++ b/drivers/platform/chrome/cros_ec.c
> @@ -21,7 +21,8 @@
> #include <linux/interrupt.h>
> #include <linux/slab.h>
> #include <linux/module.h>
> -#include <linux/mfd/cros_ec.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
> #include <linux/suspend.h>
> #include <asm/unaligned.h>
>
> diff --git a/drivers/platform/chrome/cros_ec_chardev.c b/drivers/platform/chrome/cros_ec_chardev.c
> index 1a0a27080026..786b941a60df 100644
> --- a/drivers/platform/chrome/cros_ec_chardev.c
> +++ b/drivers/platform/chrome/cros_ec_chardev.c
> @@ -9,10 +9,10 @@
> #include <linux/device.h>
> #include <linux/fs.h>
> #include <linux/list.h>
> -#include <linux/mfd/cros_ec.h>
> -#include <linux/mfd/cros_ec_commands.h>
> #include <linux/miscdevice.h>
> #include <linux/module.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
> #include <linux/platform_device.h>
> #include <linux/slab.h>
> #include <linux/spinlock.h>
> diff --git a/drivers/platform/chrome/cros_ec_debugfs.c b/drivers/platform/chrome/cros_ec_debugfs.c
> index 4c2a27f6a6d0..b088d91be9c9 100644
> --- a/drivers/platform/chrome/cros_ec_debugfs.c
> +++ b/drivers/platform/chrome/cros_ec_debugfs.c
> @@ -8,9 +8,10 @@
> #include <linux/delay.h>
> #include <linux/fs.h>
> #include <linux/mfd/cros_ec.h>
> -#include <linux/mfd/cros_ec_commands.h>
> #include <linux/module.h>
> #include <linux/mutex.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
> #include <linux/platform_device.h>
> #include <linux/poll.h>
> #include <linux/sched.h>
> diff --git a/drivers/platform/chrome/cros_ec_i2c.c b/drivers/platform/chrome/cros_ec_i2c.c
> index 6bb82dfa7dae..9bd97bc8454b 100644
> --- a/drivers/platform/chrome/cros_ec_i2c.c
> +++ b/drivers/platform/chrome/cros_ec_i2c.c
> @@ -9,8 +9,8 @@
> #include <linux/module.h>
> #include <linux/i2c.h>
> #include <linux/interrupt.h>
> -#include <linux/mfd/cros_ec.h>
> -#include <linux/mfd/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
> #include <linux/platform_device.h>
> #include <linux/slab.h>
>
> diff --git a/drivers/platform/chrome/cros_ec_lightbar.c b/drivers/platform/chrome/cros_ec_lightbar.c
> index d30a6650b0b5..caa26da2c788 100644
> --- a/drivers/platform/chrome/cros_ec_lightbar.c
> +++ b/drivers/platform/chrome/cros_ec_lightbar.c
> @@ -9,8 +9,9 @@
> #include <linux/fs.h>
> #include <linux/kobject.h>
> #include <linux/mfd/cros_ec.h>
> -#include <linux/mfd/cros_ec_commands.h>
> #include <linux/module.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
> #include <linux/platform_device.h>
> #include <linux/sched.h>
> #include <linux/types.h>
> diff --git a/drivers/platform/chrome/cros_ec_lpc.c b/drivers/platform/chrome/cros_ec_lpc.c
> index 2c7e654cf89c..0c976e95998a 100644
> --- a/drivers/platform/chrome/cros_ec_lpc.c
> +++ b/drivers/platform/chrome/cros_ec_lpc.c
> @@ -16,9 +16,9 @@
> #include <linux/delay.h>
> #include <linux/io.h>
> #include <linux/interrupt.h>
> -#include <linux/mfd/cros_ec.h>
> -#include <linux/mfd/cros_ec_commands.h>
> #include <linux/module.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
> #include <linux/platform_device.h>
> #include <linux/printk.h>
> #include <linux/suspend.h>
> diff --git a/drivers/platform/chrome/cros_ec_lpc_reg.c b/drivers/platform/chrome/cros_ec_lpc_reg.c
> index 0f5cd0ac8b49..dec9a779e209 100644
> --- a/drivers/platform/chrome/cros_ec_lpc_reg.c
> +++ b/drivers/platform/chrome/cros_ec_lpc_reg.c
> @@ -4,8 +4,8 @@
> // Copyright (C) 2016 Google, Inc
>
> #include <linux/io.h>
> -#include <linux/mfd/cros_ec.h>
> -#include <linux/mfd/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
>
> #include "cros_ec_lpc_mec.h"
>
> diff --git a/drivers/platform/chrome/cros_ec_proto.c b/drivers/platform/chrome/cros_ec_proto.c
> index 3d2325197a68..f659f96bda12 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -3,10 +3,11 @@
> //
> // Copyright (C) 2015 Google, Inc
>
> -#include <linux/mfd/cros_ec.h>
> #include <linux/delay.h>
> #include <linux/device.h>
> #include <linux/module.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
> #include <linux/slab.h>
> #include <asm/unaligned.h>
>
> diff --git a/drivers/platform/chrome/cros_ec_rpmsg.c b/drivers/platform/chrome/cros_ec_rpmsg.c
> index 520e507bfa54..9633e5417686 100644
> --- a/drivers/platform/chrome/cros_ec_rpmsg.c
> +++ b/drivers/platform/chrome/cros_ec_rpmsg.c
> @@ -6,9 +6,9 @@
> #include <linux/delay.h>
> #include <linux/kernel.h>
> #include <linux/module.h>
> -#include <linux/mfd/cros_ec.h>
> -#include <linux/mfd/cros_ec_commands.h>
> #include <linux/of.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
> #include <linux/platform_device.h>
> #include <linux/rpmsg.h>
> #include <linux/slab.h>
> diff --git a/drivers/platform/chrome/cros_ec_spi.c b/drivers/platform/chrome/cros_ec_spi.c
> index 2e21f2776063..9006e1872942 100644
> --- a/drivers/platform/chrome/cros_ec_spi.c
> +++ b/drivers/platform/chrome/cros_ec_spi.c
> @@ -6,9 +6,9 @@
> #include <linux/delay.h>
> #include <linux/kernel.h>
> #include <linux/module.h>
> -#include <linux/mfd/cros_ec.h>
> -#include <linux/mfd/cros_ec_commands.h>
> #include <linux/of.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
> #include <linux/platform_device.h>
> #include <linux/slab.h>
> #include <linux/spi/spi.h>
> diff --git a/drivers/platform/chrome/cros_ec_sysfs.c b/drivers/platform/chrome/cros_ec_sysfs.c
> index fe0b7614ae1b..0caeb8d0989d 100644
> --- a/drivers/platform/chrome/cros_ec_sysfs.c
> +++ b/drivers/platform/chrome/cros_ec_sysfs.c
> @@ -9,8 +9,9 @@
> #include <linux/fs.h>
> #include <linux/kobject.h>
> #include <linux/mfd/cros_ec.h>
> -#include <linux/mfd/cros_ec_commands.h>
> #include <linux/module.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
> #include <linux/platform_device.h>
> #include <linux/printk.h>
> #include <linux/slab.h>
> diff --git a/drivers/platform/chrome/cros_ec_trace.c b/drivers/platform/chrome/cros_ec_trace.c
> index 0a76412095a9..6f80ff4532ae 100644
> --- a/drivers/platform/chrome/cros_ec_trace.c
> +++ b/drivers/platform/chrome/cros_ec_trace.c
> @@ -6,7 +6,7 @@
> #define TRACE_SYMBOL(a) {a, #a}
>
> // Generate the list using the following script:
> -// sed -n 's/^#define \(EC_CMD_[[:alnum:]_]*\)\s.*/\tTRACE_SYMBOL(\1), \\/p' include/linux/mfd/cros_ec_commands.h
> +// sed -n 's/^#define \(EC_CMD_[[:alnum:]_]*\)\s.*/\tTRACE_SYMBOL(\1), \\/p' include/linux/platform_data/cros_ec_commands.h
> #define EC_CMDS \
> TRACE_SYMBOL(EC_CMD_PROTO_VERSION), \
> TRACE_SYMBOL(EC_CMD_HELLO), \
> diff --git a/drivers/platform/chrome/cros_ec_trace.h b/drivers/platform/chrome/cros_ec_trace.h
> index 7ae3b89c78b9..0dd4df30fa89 100644
> --- a/drivers/platform/chrome/cros_ec_trace.h
> +++ b/drivers/platform/chrome/cros_ec_trace.h
> @@ -11,8 +11,10 @@
> #if !defined(_CROS_EC_TRACE_H_) || defined(TRACE_HEADER_MULTI_READ)
> #define _CROS_EC_TRACE_H_
>
> +#include <linux/bits.h>
> #include <linux/types.h>
> -#include <linux/mfd/cros_ec.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
>
> #include <linux/tracepoint.h>
>
> diff --git a/drivers/platform/chrome/cros_ec_vbc.c b/drivers/platform/chrome/cros_ec_vbc.c
> index 8392a1ec33a7..cffe119e7a7a 100644
> --- a/drivers/platform/chrome/cros_ec_vbc.c
> +++ b/drivers/platform/chrome/cros_ec_vbc.c
> @@ -7,8 +7,9 @@
> #include <linux/of.h>
> #include <linux/platform_device.h>
> #include <linux/mfd/cros_ec.h>
> -#include <linux/mfd/cros_ec_commands.h>
> #include <linux/module.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
> #include <linux/slab.h>
>
> #define DRV_NAME "cros-ec-vbc"
> diff --git a/drivers/platform/chrome/cros_usbpd_logger.c b/drivers/platform/chrome/cros_usbpd_logger.c
> index 7c7b267626a0..c549a9b49b56 100644
> --- a/drivers/platform/chrome/cros_usbpd_logger.c
> +++ b/drivers/platform/chrome/cros_usbpd_logger.c
> @@ -6,10 +6,11 @@
> */
>
> #include <linux/ktime.h>
> -#include <linux/math64.h>
> #include <linux/mfd/cros_ec.h>
> -#include <linux/mfd/cros_ec_commands.h>
> +#include <linux/math64.h>
> #include <linux/module.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
> #include <linux/platform_device.h>
> #include <linux/rtc.h>
>
> diff --git a/drivers/power/supply/cros_usbpd-charger.c b/drivers/power/supply/cros_usbpd-charger.c
> index 3a9ea94c3de3..6cc7c3910e09 100644
> --- a/drivers/power/supply/cros_usbpd-charger.c
> +++ b/drivers/power/supply/cros_usbpd-charger.c
> @@ -5,9 +5,10 @@
> * Copyright (c) 2014 - 2018 Google, Inc
> */
>
> -#include <linux/module.h>
> #include <linux/mfd/cros_ec.h>
> -#include <linux/mfd/cros_ec_commands.h>
> +#include <linux/module.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
> #include <linux/platform_device.h>
> #include <linux/power_supply.h>
> #include <linux/slab.h>
> diff --git a/drivers/pwm/pwm-cros-ec.c b/drivers/pwm/pwm-cros-ec.c
> index 98f6ac6cf6ab..85bea2d40b7d 100644
> --- a/drivers/pwm/pwm-cros-ec.c
> +++ b/drivers/pwm/pwm-cros-ec.c
> @@ -6,8 +6,8 @@
> */
>
> #include <linux/module.h>
> -#include <linux/mfd/cros_ec.h>
> -#include <linux/mfd/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
> #include <linux/platform_device.h>
> #include <linux/pwm.h>
> #include <linux/slab.h>
> diff --git a/drivers/rtc/rtc-cros-ec.c b/drivers/rtc/rtc-cros-ec.c
> index 4d6bf9304ceb..6909e01936d9 100644
> --- a/drivers/rtc/rtc-cros-ec.c
> +++ b/drivers/rtc/rtc-cros-ec.c
> @@ -6,8 +6,9 @@
>
> #include <linux/kernel.h>
> #include <linux/mfd/cros_ec.h>
> -#include <linux/mfd/cros_ec_commands.h>
> #include <linux/module.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
> #include <linux/platform_device.h>
> #include <linux/rtc.h>
> #include <linux/slab.h>
> diff --git a/include/linux/iio/common/cros_ec_sensors_core.h b/include/linux/iio/common/cros_ec_sensors_core.h
> index ce16445411ac..8a91669f5bed 100644
> --- a/include/linux/iio/common/cros_ec_sensors_core.h
> +++ b/include/linux/iio/common/cros_ec_sensors_core.h
> @@ -18,7 +18,8 @@
>
> #include <linux/iio/iio.h>
> #include <linux/irqreturn.h>
> -#include <linux/mfd/cros_ec.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
>
> enum {
> CROS_EC_SENSOR_X,
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index 2a1372d167b9..e0bae49535e1 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -16,184 +16,7 @@
> #ifndef __LINUX_MFD_CROS_EC_H
> #define __LINUX_MFD_CROS_EC_H
>
> -#include <linux/cdev.h>
> #include <linux/device.h>
> -#include <linux/notifier.h>
> -#include <linux/mfd/cros_ec_commands.h>
> -#include <linux/mutex.h>
> -
> -#define CROS_EC_DEV_NAME "cros_ec"
> -#define CROS_EC_DEV_FP_NAME "cros_fp"
> -#define CROS_EC_DEV_PD_NAME "cros_pd"
> -#define CROS_EC_DEV_TP_NAME "cros_tp"
> -#define CROS_EC_DEV_ISH_NAME "cros_ish"
> -
> -/*
> - * The EC is unresponsive for a time after a reboot command. Add a
> - * simple delay to make sure that the bus stays locked.
> - */
> -#define EC_REBOOT_DELAY_MS 50
> -
> -/*
> - * Max bus-specific overhead incurred by request/responses.
> - * I2C requires 1 additional byte for requests.
> - * I2C requires 2 additional bytes for responses.
> - * SPI requires up to 32 additional bytes for responses.
> - */
> -#define EC_PROTO_VERSION_UNKNOWN 0
> -#define EC_MAX_REQUEST_OVERHEAD 1
> -#define EC_MAX_RESPONSE_OVERHEAD 32
> -
> -/*
> - * Command interface between EC and AP, for LPC, I2C and SPI interfaces.
> - */
> -enum {
> - EC_MSG_TX_HEADER_BYTES = 3,
> - EC_MSG_TX_TRAILER_BYTES = 1,
> - EC_MSG_TX_PROTO_BYTES = EC_MSG_TX_HEADER_BYTES +
> - EC_MSG_TX_TRAILER_BYTES,
> - EC_MSG_RX_PROTO_BYTES = 3,
> -
> - /* Max length of messages for proto 2*/
> - EC_PROTO2_MSG_BYTES = EC_PROTO2_MAX_PARAM_SIZE +
> - EC_MSG_TX_PROTO_BYTES,
> -
> - EC_MAX_MSG_BYTES = 64 * 1024,
> -};
> -
> -/**
> - * struct cros_ec_command - Information about a ChromeOS EC command.
> - * @version: Command version number (often 0).
> - * @command: Command to send (EC_CMD_...).
> - * @outsize: Outgoing length in bytes.
> - * @insize: Max number of bytes to accept from the EC.
> - * @result: EC's response to the command (separate from communication failure).
> - * @data: Where to put the incoming data from EC and outgoing data to EC.
> - */
> -struct cros_ec_command {
> - uint32_t version;
> - uint32_t command;
> - uint32_t outsize;
> - uint32_t insize;
> - uint32_t result;
> - uint8_t data[0];
> -};
> -
> -/**
> - * struct cros_ec_device - Information about a ChromeOS EC device.
> - * @phys_name: Name of physical comms layer (e.g. 'i2c-4').
> - * @dev: Device pointer for physical comms device
> - * @was_wake_device: True if this device was set to wake the system from
> - * sleep at the last suspend.
> - * @cros_class: The class structure for this device.
> - * @cmd_readmem: Direct read of the EC memory-mapped region, if supported.
> - * @offset: Is within EC_LPC_ADDR_MEMMAP region.
> - * @bytes: Number of bytes to read. zero means "read a string" (including
> - * the trailing '\0'). At most only EC_MEMMAP_SIZE bytes can be
> - * read. Caller must ensure that the buffer is large enough for the
> - * result when reading a string.
> - * @max_request: Max size of message requested.
> - * @max_response: Max size of message response.
> - * @max_passthru: Max sice of passthru message.
> - * @proto_version: The protocol version used for this device.
> - * @priv: Private data.
> - * @irq: Interrupt to use.
> - * @id: Device id.
> - * @din: Input buffer (for data from EC). This buffer will always be
> - * dword-aligned and include enough space for up to 7 word-alignment
> - * bytes also, so we can ensure that the body of the message is always
> - * dword-aligned (64-bit). We use this alignment to keep ARM and x86
> - * happy. Probably word alignment would be OK, there might be a small
> - * performance advantage to using dword.
> - * @dout: Output buffer (for data to EC). This buffer will always be
> - * dword-aligned and include enough space for up to 7 word-alignment
> - * bytes also, so we can ensure that the body of the message is always
> - * dword-aligned (64-bit). We use this alignment to keep ARM and x86
> - * happy. Probably word alignment would be OK, there might be a small
> - * performance advantage to using dword.
> - * @din_size: Size of din buffer to allocate (zero to use static din).
> - * @dout_size: Size of dout buffer to allocate (zero to use static dout).
> - * @wake_enabled: True if this device can wake the system from sleep.
> - * @suspended: True if this device had been suspended.
> - * @cmd_xfer: Send command to EC and get response.
> - * Returns the number of bytes received if the communication
> - * succeeded, but that doesn't mean the EC was happy with the
> - * command. The caller should check msg.result for the EC's result
> - * code.
> - * @pkt_xfer: Send packet to EC and get response.
> - * @lock: One transaction at a time.
> - * @mkbp_event_supported: True if this EC supports the MKBP event protocol.
> - * @host_sleep_v1: True if this EC supports the sleep v1 command.
> - * @event_notifier: Interrupt event notifier for transport devices.
> - * @event_data: Raw payload transferred with the MKBP event.
> - * @event_size: Size in bytes of the event data.
> - * @host_event_wake_mask: Mask of host events that cause wake from suspend.
> - * @ec: The platform_device used by the mfd driver to interface with the
> - * main EC.
> - * @pd: The platform_device used by the mfd driver to interface with the
> - * PD behind an EC.
> - */
> -struct cros_ec_device {
> - /* These are used by other drivers that want to talk to the EC */
> - const char *phys_name;
> - struct device *dev;
> - bool was_wake_device;
> - struct class *cros_class;
> - int (*cmd_readmem)(struct cros_ec_device *ec, unsigned int offset,
> - unsigned int bytes, void *dest);
> -
> - /* These are used to implement the platform-specific interface */
> - u16 max_request;
> - u16 max_response;
> - u16 max_passthru;
> - u16 proto_version;
> - void *priv;
> - int irq;
> - u8 *din;
> - u8 *dout;
> - int din_size;
> - int dout_size;
> - bool wake_enabled;
> - bool suspended;
> - int (*cmd_xfer)(struct cros_ec_device *ec,
> - struct cros_ec_command *msg);
> - int (*pkt_xfer)(struct cros_ec_device *ec,
> - struct cros_ec_command *msg);
> - struct mutex lock;
> - bool mkbp_event_supported;
> - bool host_sleep_v1;
> - struct blocking_notifier_head event_notifier;
> -
> - struct ec_response_get_next_event_v1 event_data;
> - int event_size;
> - u32 host_event_wake_mask;
> -
> - /* The platform devices used by the mfd driver */
> - struct platform_device *ec;
> - struct platform_device *pd;
> -};
> -
> -/**
> - * struct cros_ec_sensor_platform - ChromeOS EC sensor platform information.
> - * @sensor_num: Id of the sensor, as reported by the EC.
> - */
> -struct cros_ec_sensor_platform {
> - u8 sensor_num;
> -};
> -
> -/**
> - * struct cros_ec_platform - ChromeOS EC platform information.
> - * @ec_name: Name of EC device (e.g. 'cros-ec', 'cros-pd', ...)
> - * used in /dev/ and sysfs.
> - * @cmd_offset: Offset to apply for each command. Set when
> - * registering a device behind another one.
> - */
> -struct cros_ec_platform {
> - const char *ec_name;
> - u16 cmd_offset;
> -};
> -
> -struct cros_ec_debugfs;
>
> /**
> * struct cros_ec_dev - ChromeOS EC device entry point.
> @@ -217,133 +40,4 @@ struct cros_ec_dev {
>
> #define to_cros_ec_dev(dev) container_of(dev, struct cros_ec_dev, class_dev)
>
> -/**
> - * cros_ec_suspend() - Handle a suspend operation for the ChromeOS EC device.
> - * @ec_dev: Device to suspend.
> - *
> - * This can be called by drivers to handle a suspend event.
> - *
> - * Return: 0 on success or negative error code.
> - */
> -int cros_ec_suspend(struct cros_ec_device *ec_dev);
> -
> -/**
> - * cros_ec_resume() - Handle a resume operation for the ChromeOS EC device.
> - * @ec_dev: Device to resume.
> - *
> - * This can be called by drivers to handle a resume event.
> - *
> - * Return: 0 on success or negative error code.
> - */
> -int cros_ec_resume(struct cros_ec_device *ec_dev);
> -
> -/**
> - * cros_ec_prepare_tx() - Prepare an outgoing message in the output buffer.
> - * @ec_dev: Device to register.
> - * @msg: Message to write.
> - *
> - * This is intended to be used by all ChromeOS EC drivers, but at present
> - * only SPI uses it. Once LPC uses the same protocol it can start using it.
> - * I2C could use it now, with a refactor of the existing code.
> - *
> - * Return: 0 on success or negative error code.
> - */
> -int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
> - struct cros_ec_command *msg);
> -
> -/**
> - * cros_ec_check_result() - Check ec_msg->result.
> - * @ec_dev: EC device.
> - * @msg: Message to check.
> - *
> - * This is used by ChromeOS EC drivers to check the ec_msg->result for
> - * errors and to warn about them.
> - *
> - * Return: 0 on success or negative error code.
> - */
> -int cros_ec_check_result(struct cros_ec_device *ec_dev,
> - struct cros_ec_command *msg);
> -
> -/**
> - * cros_ec_cmd_xfer() - Send a command to the ChromeOS EC.
> - * @ec_dev: EC device.
> - * @msg: Message to write.
> - *
> - * Call this to send a command to the ChromeOS EC. This should be used
> - * instead of calling the EC's cmd_xfer() callback directly.
> - *
> - * Return: 0 on success or negative error code.
> - */
> -int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
> - struct cros_ec_command *msg);
> -
> -/**
> - * cros_ec_cmd_xfer_status() - Send a command to the ChromeOS EC.
> - * @ec_dev: EC device.
> - * @msg: Message to write.
> - *
> - * This function is identical to cros_ec_cmd_xfer, except it returns success
> - * status only if both the command was transmitted successfully and the EC
> - * replied with success status. It's not necessary to check msg->result when
> - * using this function.
> - *
> - * Return: The number of bytes transferred on success or negative error code.
> - */
> -int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
> - struct cros_ec_command *msg);
> -
> -/**
> - * cros_ec_register() - Register a new ChromeOS EC, using the provided info.
> - * @ec_dev: Device to register.
> - *
> - * Before calling this, allocate a pointer to a new device and then fill
> - * in all the fields up to the --private-- marker.
> - *
> - * Return: 0 on success or negative error code.
> - */
> -int cros_ec_register(struct cros_ec_device *ec_dev);
> -
> -/**
> - * cros_ec_unregister() - Remove a ChromeOS EC.
> - * @ec_dev: Device to unregister.
> - *
> - * Call this to deregister a ChromeOS EC, then clean up any private data.
> - *
> - * Return: 0 on success or negative error code.
> - */
> -int cros_ec_unregister(struct cros_ec_device *ec_dev);
> -
> -/**
> - * cros_ec_query_all() - Query the protocol version supported by the
> - * ChromeOS EC.
> - * @ec_dev: Device to register.
> - *
> - * Return: 0 on success or negative error code.
> - */
> -int cros_ec_query_all(struct cros_ec_device *ec_dev);
> -
> -/**
> - * cros_ec_get_next_event() - Fetch next event from the ChromeOS EC.
> - * @ec_dev: Device to fetch event from.
> - * @wake_event: Pointer to a bool set to true upon return if the event might be
> - * treated as a wake event. Ignored if null.
> - *
> - * Return: negative error code on errors; 0 for no data; or else number of
> - * bytes received (i.e., an event was retrieved successfully). Event types are
> - * written out to @ec_dev->event_data.event_type on success.
> - */
> -int cros_ec_get_next_event(struct cros_ec_device *ec_dev, bool *wake_event);
> -
> -/**
> - * cros_ec_get_host_event() - Return a mask of event set by the ChromeOS EC.
> - * @ec_dev: Device to fetch event from.
> - *
> - * When MKBP is supported, when the EC raises an interrupt, we collect the
> - * events raised and call the functions in the ec notifier. This function
> - * is a helper to know which events are raised.
> - *
> - * Return: 0 on error or non-zero bitmask of one or more EC_HOST_EVENT_*.
> - */
> -u32 cros_ec_get_host_event(struct cros_ec_device *ec_dev);
> -
> #endif /* __LINUX_MFD_CROS_EC_H */
> diff --git a/include/linux/mfd/cros_ec_commands.h b/include/linux/platform_data/cros_ec_commands.h
> similarity index 100%
> rename from include/linux/mfd/cros_ec_commands.h
> rename to include/linux/platform_data/cros_ec_commands.h
> diff --git a/include/linux/platform_data/cros_ec_proto.h b/include/linux/platform_data/cros_ec_proto.h
> new file mode 100644
> index 000000000000..34dd9e5c1779
> --- /dev/null
> +++ b/include/linux/platform_data/cros_ec_proto.h
> @@ -0,0 +1,315 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * ChromeOS Embedded Controller protocol interface.
> + *
> + * Copyright (C) 2012 Google, Inc
> + */
> +
> +#ifndef __LINUX_CROS_EC_PROTO_H
> +#define __LINUX_CROS_EC_PROTO_H
> +
> +#include <linux/device.h>
> +#include <linux/mutex.h>
> +#include <linux/notifier.h>
> +
> +#define CROS_EC_DEV_NAME "cros_ec"
> +#define CROS_EC_DEV_FP_NAME "cros_fp"
> +#define CROS_EC_DEV_ISH_NAME "cros_ish"
> +#define CROS_EC_DEV_PD_NAME "cros_pd"
> +#define CROS_EC_DEV_TP_NAME "cros_tp"
> +
> +/*
> + * The EC is unresponsive for a time after a reboot command. Add a
> + * simple delay to make sure that the bus stays locked.
> + */
> +#define EC_REBOOT_DELAY_MS 50
> +
> +/*
> + * Max bus-specific overhead incurred by request/responses.
> + * I2C requires 1 additional byte for requests.
> + * I2C requires 2 additional bytes for responses.
> + * SPI requires up to 32 additional bytes for responses.
> + */
> +#define EC_PROTO_VERSION_UNKNOWN 0
> +#define EC_MAX_REQUEST_OVERHEAD 1
> +#define EC_MAX_RESPONSE_OVERHEAD 32
> +
> +/*
> + * Command interface between EC and AP, for LPC, I2C and SPI interfaces.
> + */
> +enum {
> + EC_MSG_TX_HEADER_BYTES = 3,
> + EC_MSG_TX_TRAILER_BYTES = 1,
> + EC_MSG_TX_PROTO_BYTES = EC_MSG_TX_HEADER_BYTES +
> + EC_MSG_TX_TRAILER_BYTES,
> + EC_MSG_RX_PROTO_BYTES = 3,
> +
> + /* Max length of messages for proto 2*/
> + EC_PROTO2_MSG_BYTES = EC_PROTO2_MAX_PARAM_SIZE +
> + EC_MSG_TX_PROTO_BYTES,
> +
> + EC_MAX_MSG_BYTES = 64 * 1024,
> +};
> +
> +/**
> + * struct cros_ec_command - Information about a ChromeOS EC command.
> + * @version: Command version number (often 0).
> + * @command: Command to send (EC_CMD_...).
> + * @outsize: Outgoing length in bytes.
> + * @insize: Max number of bytes to accept from the EC.
> + * @result: EC's response to the command (separate from communication failure).
> + * @data: Where to put the incoming data from EC and outgoing data to EC.
> + */
> +struct cros_ec_command {
> + uint32_t version;
> + uint32_t command;
> + uint32_t outsize;
> + uint32_t insize;
> + uint32_t result;
> + uint8_t data[0];
> +};
> +
> +/**
> + * struct cros_ec_device - Information about a ChromeOS EC device.
> + * @phys_name: Name of physical comms layer (e.g. 'i2c-4').
> + * @dev: Device pointer for physical comms device
> + * @was_wake_device: True if this device was set to wake the system from
> + * sleep at the last suspend.
> + * @cros_class: The class structure for this device.
> + * @cmd_readmem: Direct read of the EC memory-mapped region, if supported.
> + * @offset: Is within EC_LPC_ADDR_MEMMAP region.
> + * @bytes: Number of bytes to read. zero means "read a string" (including
> + * the trailing '\0'). At most only EC_MEMMAP_SIZE bytes can be
> + * read. Caller must ensure that the buffer is large enough for the
> + * result when reading a string.
> + * @max_request: Max size of message requested.
> + * @max_response: Max size of message response.
> + * @max_passthru: Max sice of passthru message.
> + * @proto_version: The protocol version used for this device.
> + * @priv: Private data.
> + * @irq: Interrupt to use.
> + * @id: Device id.
> + * @din: Input buffer (for data from EC). This buffer will always be
> + * dword-aligned and include enough space for up to 7 word-alignment
> + * bytes also, so we can ensure that the body of the message is always
> + * dword-aligned (64-bit). We use this alignment to keep ARM and x86
> + * happy. Probably word alignment would be OK, there might be a small
> + * performance advantage to using dword.
> + * @dout: Output buffer (for data to EC). This buffer will always be
> + * dword-aligned and include enough space for up to 7 word-alignment
> + * bytes also, so we can ensure that the body of the message is always
> + * dword-aligned (64-bit). We use this alignment to keep ARM and x86
> + * happy. Probably word alignment would be OK, there might be a small
> + * performance advantage to using dword.
> + * @din_size: Size of din buffer to allocate (zero to use static din).
> + * @dout_size: Size of dout buffer to allocate (zero to use static dout).
> + * @wake_enabled: True if this device can wake the system from sleep.
> + * @suspended: True if this device had been suspended.
> + * @cmd_xfer: Send command to EC and get response.
> + * Returns the number of bytes received if the communication
> + * succeeded, but that doesn't mean the EC was happy with the
> + * command. The caller should check msg.result for the EC's result
> + * code.
> + * @pkt_xfer: Send packet to EC and get response.
> + * @lock: One transaction at a time.
> + * @mkbp_event_supported: True if this EC supports the MKBP event protocol.
> + * @host_sleep_v1: True if this EC supports the sleep v1 command.
> + * @event_notifier: Interrupt event notifier for transport devices.
> + * @event_data: Raw payload transferred with the MKBP event.
> + * @event_size: Size in bytes of the event data.
> + * @host_event_wake_mask: Mask of host events that cause wake from suspend.
> + * @ec: The platform_device used by the mfd driver to interface with the
> + * main EC.
> + * @pd: The platform_device used by the mfd driver to interface with the
> + * PD behind an EC.
> + */
> +struct cros_ec_device {
> + /* These are used by other drivers that want to talk to the EC */
> + const char *phys_name;
> + struct device *dev;
> + bool was_wake_device;
> + struct class *cros_class;
> + int (*cmd_readmem)(struct cros_ec_device *ec, unsigned int offset,
> + unsigned int bytes, void *dest);
> +
> + /* These are used to implement the platform-specific interface */
> + u16 max_request;
> + u16 max_response;
> + u16 max_passthru;
> + u16 proto_version;
> + void *priv;
> + int irq;
> + u8 *din;
> + u8 *dout;
> + int din_size;
> + int dout_size;
> + bool wake_enabled;
> + bool suspended;
> + int (*cmd_xfer)(struct cros_ec_device *ec,
> + struct cros_ec_command *msg);
> + int (*pkt_xfer)(struct cros_ec_device *ec,
> + struct cros_ec_command *msg);
> + struct mutex lock;
> + bool mkbp_event_supported;
> + bool host_sleep_v1;
> + struct blocking_notifier_head event_notifier;
> +
> + struct ec_response_get_next_event_v1 event_data;
> + int event_size;
> + u32 host_event_wake_mask;
> +
> + /* The platform devices used by the mfd driver */
> + struct platform_device *ec;
> + struct platform_device *pd;
> +};
> +
> +/**
> + * struct cros_ec_sensor_platform - ChromeOS EC sensor platform information.
> + * @sensor_num: Id of the sensor, as reported by the EC.
> + */
> +struct cros_ec_sensor_platform {
> + u8 sensor_num;
> +};
> +
> +/**
> + * struct cros_ec_platform - ChromeOS EC platform information.
> + * @ec_name: Name of EC device (e.g. 'cros-ec', 'cros-pd', ...)
> + * used in /dev/ and sysfs.
> + * @cmd_offset: Offset to apply for each command. Set when
> + * registering a device behind another one.
> + */
> +struct cros_ec_platform {
> + const char *ec_name;
> + u16 cmd_offset;
> +};
> +
> +/**
> + * cros_ec_suspend() - Handle a suspend operation for the ChromeOS EC device.
> + * @ec_dev: Device to suspend.
> + *
> + * This can be called by drivers to handle a suspend event.
> + *
> + * Return: 0 on success or negative error code.
> + */
> +int cros_ec_suspend(struct cros_ec_device *ec_dev);
> +
> +/**
> + * cros_ec_resume() - Handle a resume operation for the ChromeOS EC device.
> + * @ec_dev: Device to resume.
> + *
> + * This can be called by drivers to handle a resume event.
> + *
> + * Return: 0 on success or negative error code.
> + */
> +int cros_ec_resume(struct cros_ec_device *ec_dev);
> +
> +/**
> + * cros_ec_prepare_tx() - Prepare an outgoing message in the output buffer.
> + * @ec_dev: Device to register.
> + * @msg: Message to write.
> + *
> + * This is intended to be used by all ChromeOS EC drivers, but at present
> + * only SPI uses it. Once LPC uses the same protocol it can start using it.
> + * I2C could use it now, with a refactor of the existing code.
> + *
> + * Return: 0 on success or negative error code.
> + */
> +int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
> + struct cros_ec_command *msg);
> +
> +/**
> + * cros_ec_check_result() - Check ec_msg->result.
> + * @ec_dev: EC device.
> + * @msg: Message to check.
> + *
> + * This is used by ChromeOS EC drivers to check the ec_msg->result for
> + * errors and to warn about them.
> + *
> + * Return: 0 on success or negative error code.
> + */
> +int cros_ec_check_result(struct cros_ec_device *ec_dev,
> + struct cros_ec_command *msg);
> +
> +/**
> + * cros_ec_cmd_xfer() - Send a command to the ChromeOS EC.
> + * @ec_dev: EC device.
> + * @msg: Message to write.
> + *
> + * Call this to send a command to the ChromeOS EC. This should be used
> + * instead of calling the EC's cmd_xfer() callback directly.
> + *
> + * Return: 0 on success or negative error code.
> + */
> +int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
> + struct cros_ec_command *msg);
> +
> +/**
> + * cros_ec_cmd_xfer_status() - Send a command to the ChromeOS EC.
> + * @ec_dev: EC device.
> + * @msg: Message to write.
> + *
> + * This function is identical to cros_ec_cmd_xfer, except it returns success
> + * status only if both the command was transmitted successfully and the EC
> + * replied with success status. It's not necessary to check msg->result when
> + * using this function.
> + *
> + * Return: The number of bytes transferred on success or negative error code.
> + */
> +int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
> + struct cros_ec_command *msg);
> +
> +/**
> + * cros_ec_register() - Register a new ChromeOS EC, using the provided info.
> + * @ec_dev: Device to register.
> + *
> + * Before calling this, allocate a pointer to a new device and then fill
> + * in all the fields up to the --private-- marker.
> + *
> + * Return: 0 on success or negative error code.
> + */
> +int cros_ec_register(struct cros_ec_device *ec_dev);
> +
> +/**
> + * cros_ec_unregister() - Remove a ChromeOS EC.
> + * @ec_dev: Device to unregister.
> + *
> + * Call this to deregister a ChromeOS EC, then clean up any private data.
> + *
> + * Return: 0 on success or negative error code.
> + */
> +int cros_ec_unregister(struct cros_ec_device *ec_dev);
> +
> +/**
> + * cros_ec_query_all() - Query the protocol version supported by the
> + * ChromeOS EC.
> + * @ec_dev: Device to register.
> + *
> + * Return: 0 on success or negative error code.
> + */
> +int cros_ec_query_all(struct cros_ec_device *ec_dev);
> +
> +/**
> + * cros_ec_get_next_event() - Fetch next event from the ChromeOS EC.
> + * @ec_dev: Device to fetch event from.
> + * @wake_event: Pointer to a bool set to true upon return if the event might be
> + * treated as a wake event. Ignored if null.
> + *
> + * Return: negative error code on errors; 0 for no data; or else number of
> + * bytes received (i.e., an event was retrieved successfully). Event types are
> + * written out to @ec_dev->event_data.event_type on success.
> + */
> +int cros_ec_get_next_event(struct cros_ec_device *ec_dev, bool *wake_event);
> +
> +/**
> + * cros_ec_get_host_event() - Return a mask of event set by the ChromeOS EC.
> + * @ec_dev: Device to fetch event from.
> + *
> + * When MKBP is supported, when the EC raises an interrupt, we collect the
> + * events raised and call the functions in the ec notifier. This function
> + * is a helper to know which events are raised.
> + *
> + * Return: 0 on error or non-zero bitmask of one or more EC_HOST_EVENT_*.
> + */
> +u32 cros_ec_get_host_event(struct cros_ec_device *ec_dev);
> +
> +#endif /* __LINUX_CROS_EC_PROTO_H */
> diff --git a/sound/soc/codecs/cros_ec_codec.c b/sound/soc/codecs/cros_ec_codec.c
> index 87830ed5ebf4..79bb4081d3c2 100644
> --- a/sound/soc/codecs/cros_ec_codec.c
> +++ b/sound/soc/codecs/cros_ec_codec.c
> @@ -9,9 +9,9 @@
> #include <linux/delay.h>
> #include <linux/device.h>
> #include <linux/kernel.h>
> -#include <linux/mfd/cros_ec.h>
> -#include <linux/mfd/cros_ec_commands.h>
> #include <linux/module.h>
> +#include <linux/platform_data/cros_ec_commands.h>
> +#include <linux/platform_data/cros_ec_proto.h>
> #include <linux/platform_device.h>
> #include <sound/pcm.h>
> #include <sound/pcm_params.h>
> --
> 2.20.1
>
^ permalink raw reply
* Re: [PATCH 1/3] mfd: apple-ibridge: Add Apple iBridge MFD driver.
From: Benjamin Tissoires @ 2019-06-11 9:03 UTC (permalink / raw)
To: Life is hard, and then you die
Cc: Jiri Kosina, Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Lee Jones, open list:HID CORE LAYER,
linux-iio, lkml
In-Reply-To: <20190610091948.GC16597@innovation.ch>
Hi ronald,
On Mon, Jun 10, 2019 at 11:20 AM Life is hard, and then you die
<ronald@innovation.ch> wrote:
>
>
> Hi Benjamin,
>
> Sorry for the extremely late reply - RL etc.
>
> On Fri, Apr 26, 2019 at 08:26:25AM +0200, Benjamin Tissoires wrote:
> > On Fri, Apr 26, 2019 at 7:56 AM Life is hard, and then you die
> > <ronald@innovation.ch> wrote:
> > >
> > > On Thu, Apr 25, 2019 at 11:39:12AM +0200, Benjamin Tissoires wrote:
> > > > On Thu, Apr 25, 2019 at 10:19 AM Life is hard, and then you die
> > > > <ronald@innovation.ch> wrote:
> > > > >
> > > > > Hi Benjamin,
> > > > >
> > > > > Thank you for looking at this.
> > > > >
> > > > > On Wed, Apr 24, 2019 at 04:18:23PM +0200, Benjamin Tissoires wrote:
> > > > > > On Mon, Apr 22, 2019 at 5:13 AM Ronald Tschalär <ronald@innovation.ch> wrote:
> > > > > > >
> > > > > > > The iBridge device provides access to several devices, including:
> > > > > > > - the Touch Bar
> > > > > > > - the iSight webcam
> > > > > > > - the light sensor
> > > > > > > - the fingerprint sensor
> > > > > > >
> > > > > > > This driver provides the core support for managing the iBridge device
> > > > > > > and the access to the underlying devices. In particular, since the
> > > > > > > functionality for the touch bar and light sensor is exposed via USB HID
> > > > > > > interfaces, and the same HID device is used for multiple functions, this
> > > > > > > driver provides a multiplexing layer that allows multiple HID drivers to
> > > > > > > be registered for a given HID device. This allows the touch bar and ALS
> > > > > > > driver to be separated out into their own modules.
> > > > > >
> > > > > > Sorry for coming late to the party, but IMO this series is far too
> > > > > > complex for what you need.
> > > > > >
> > > > > > As I read this and the first comment of drivers/mfd/apple-ibridge.c,
> > > > > > you need to have a HID driver that multiplex 2 other sub drivers
> > > > > > through one USB communication.
> > > > > > For that, you are using MFD, platform driver and you own sauce instead
> > > > > > of creating a bus.
> > > > >
> > > > > Basically correct. To be a bit more precise, there are currently two
> > > > > hid-devices and two drivers (touchbar and als) involved, with
> > > > > connections as follows (pardon the ugly ascii art):
> > > > >
> > > > > hdev1 --- tb-drv
> > > > > /
> > > > > /
> > > > > /
> > > > > hdev2 --- als-drv
> > > > >
> > > > > i.e. the touchbar driver talks to both hdev's, and hdev2's events
> > > > > (reports) are processed by both drivers (though each handles different
> > > > > reports).
> > > > >
> > > > > > So, how about we reuse entirely the HID subsystem which already
> > > > > > provides the capability you need (assuming I am correct above).
> > > > > > hid-logitech-dj already does the same kind of stuff and you could:
> > > > > > - create drivers/hid/hid-ibridge.c that handles USB_ID_PRODUCT_IBRIDGE
> > > > > > - hid-ibridge will then register itself to the hid subsystem with a
> > > > > > call to hid_hw_start(hdev, HID_CONNECT_HIDRAW) and
> > > > > > hid_device_io_start(hdev) to enable the events (so you don't create
> > > > > > useless input nodes for it)
> > > > > > - then you add your 2 new devices by calling hid_allocate_device() and
> > > > > > then hid_add_device(). You can even create a new HID group
> > > > > > APPLE_IBRIDGE and allocate 2 new PIDs for them to distinguish them
> > > > > > from the actual USB device.
> > > > > > - then you have 2 brand new HID devices you can create their driver as
> > > > > > a regular ones.
> > > > > >
> > > > > > hid-ibridge.c would just need to behave like any other hid transport
> > > > > > driver (see logi_dj_ll_driver in drivers/hid/hid-logitech-dj.c) and
> > > > > > you can get rid of at least the MFD and the platform part of your
> > > > > > drivers.
> > > > > >
> > > > > > Does it makes sense or am I missing something obvious in the middle?
> > > > >
> > > > > Yes, I think I understand, and I think this can work. Basically,
> > > > > instead of demux'ing at the hid-driver level as I am doing now (i.e.
> > > > > the iBridge hid-driver forwarding calls to the sub-hid-drivers), we
> > > > > demux at the hid-device level (events forwarded from iBridge hdev to
> > > > > all "virtual" sub-hdev's, and requests from sub-hdev's forwarded to
> > > > > the original hdev via an iBridge ll_driver attached to the
> > > > > sub-hdev's).
> > > > >
> > > > > So I would need to create 3 new "virtual" hid-devices (instances) as
> > > > > follows:
> > > > >
> > > > > hdev1 --- vhdev1 --- tb-drv
> > > > > /
> > > > > -- vhdev2 --
> > > > > /
> > > > > hdev2 --- vhdev3 --- als-drv
> > > > >
> > > > > (vhdev1 is probably not strictly necessary, but makes things more
> > > > > consistent).
> > > >
> > > > Oh, ok.
> > > >
> > > > How about the following:
> > > >
> > > > hdev1 and hdev2 are merged together in hid-apple-ibridge.c, and then
> > > > this driver creates 2 virtual hid drivers that are consistent
> > > >
> > > > like
> > > >
> > > > hdev1---ibridge-drv---vhdev1---tb-drv
> > > > hdev2--/ \--vhdev2---als-drv
> > >
> > > I don't think this will work. The problem is when the sub-drivers need
> > > to send a report or usb-command: how to they specify which hdev the
> > > report/command is destined for? While we could store the original hdev
> > > in each report (the hid_report's device field), that only works for
> > > hid_hw_request(), but not for things like hid_hw_raw_request() or
> > > hid_hw_output_report(). Now, currently I don't use the latter two; but
> > > I do need to send raw usb control messages in the touchbar driver
> > > (some commands are not proper hid reports), so it definitely breaks
> > > down there.
> > >
> > > Or am I missing something?
> >
> > I'd need to have a deeper look at the protocol, but you can emulate
> > pure HID devices by having your ibridge handling a translation from
> > set/get features/input to the usb control messages. Likewise, nothing
> > prevents you to slightly rewrite the report descriptors you present to
> > the als and touchbar to have a clear separation with the report ID.
> >
> > For example, if both hdev1 and hdev2 use a report ID of 0x01, you
> > could rewrite the report descriptor so that when you receive a report
> > with an id of 0x01 you send this to hdev1, but you can also translate
> > 0x11 to a report ID 0x01 to hdev2.
> > Likewise, report ID 0x42 could be a raw USB control message to the USB
> > under hdev2.
> >
> > Note that you will have to write 2 report descriptors for your new
> > devices, but you can take what makes sense from the original ones, and
> > just add a new collection with a vendor application with with an
> > opaque meaning (for the USB control messages).
>
> A couple things here. First of all, I went and rewrote the mfd driver
> with the hid-driver demultiplexer as a straight hid driver with 3
> (well, 4 actually) virtual hid devices, as first discussed above.
> This overall led to some simplifications, with only smaller
> adjustments in the Touch Bar and ALS drivers (the diff stat shows 468
> insertions, 825 deletions), so this looks good. Importantly (IMO),
> this leaves the whole awareness of the fact that the Touch Bar driver
> is talking to multiple usb interfaces and needs to coordinate
> appropriately between them (including things like which order they are
> accessed, sleep times between those accesses, and different power
> management) clearly in the Touch Bar driver, and the ibridge driver is
> still fairly generic unaware of any of the details that the
> sub-drivers need to worry about.
>
> Then I started looking more closely at your last suggestion above of
> creating only 2 virtual hid devices, with report descriptor
> merging/mangling and the addition of 3 custom reports (for the
> set-power, io-wait, and usb-control functionality), and I'm having
> trouble seeing the justification for it. AFAICT, the only advantage of
> this approach is that there are fewer virtual hid devices. But the
> disadvantages are significantly more code (especially in the ibridge
> driver) and more leakage of knowledge from the Touch Bar driver into
> the ibridge driver. In particular:
>
> * this leads to additional work, synchronization, and state management
> in the ibridge driver to deal with the fact that we have to wait for
> all (real) hid devices to be probed before we can start creating the
> virtual hid devices (and visa versa on removal).
> * merging and mangling those report descriptors requires re-parsing
> of the descriptors and dealing with various corner cases, which adds
> a bunch of code.
> * while the custom set-power and io-wait reports are simple, the
> custom usb-control report is ugly, because it actually ends up
> needing to compute some of the parameters and rewrite the data, as
> both those have values that require knowledge of the real underlying
> reports and usb interfaces (i.e. it's not a report for a generic
> usb-control call, but a very Touch Bar specific one, i.e. leaking
> particular Touch Bar driver knowledge into the ibridge driver).
> * In addition, while creating especially the custom usb-control
> report, I started to wonder if it's really worth serializing the
> parameters for the custom functions/report into an actual report
> buffer, just to be deserialized again two function calls down the
> stack. This became obvious when I was adding a helper function to
> the ibridge driver to serialize the function parameters, and at the
> same time writing a function right below it to deserialize those
> parameters again, all so we can call hid_hw_request() to pass them
> from the Touch Bar driver to the ibridge driver - but since the
> Touch Bar driver is already calling a custom function in the ibridge
> driver to serialize the parameters, it seems like that function
> might just as well make the desired underlying function call
> directly in the first place. Alternatively, the serializing
> functionality can be put in the Touch Bar driver instead, with the
> disadvantage that the implicit knowledge of the structure of the
> custom report is now spread over two modules. All of this seems
> somewhat ugly to me.
>
> Lastly, as hinted earlier, while this tries to hide the fact that
> there are actually multiple hid devices (aka usb interfaces) that are
> being driven by the Touch Bar driver, the Touch Bar driver still needs
> to be acutely aware of that fact because it cannot treat them equally.
> So now instead it clearly dealing with two different devices, it now
> has to do so indirectly by figuring out which reports (in the same
> virtual hid device) belong to which underlying real hid devices so it
> can treat those reports accordingly (e.g. when creating the reports to
> trigger set-power or usb-ctrl, instead of the desired device/interface
> being targeted directly, that info has to instead be passed somewhat
> opaquely via a report-id of a report that it happens to know is mapped
> to the desired device/interface).
>
> Sorry for the long-winded response. I hope it isn't too cryptic. But
> basically it boils down to: going for single virtual hid-device per
> real device adds a bunch of complexity and knowledge leaking from the
> Touch Bar driver the ibridge driver with AFAICT only a small advantage
> (namely fewer virtual devices).
>
I must confess that understanding all the details above without seeing
the code is rather hard.
However, if you have a simple and elegant solution right now that
doesn't imply the MFD driver, how about posting it now so we can
discuss it by looking at the code?
I am fine putting the above explanation in a commit message to justify
the current approach, but we are already talking about revision 3 when
I haven't seen revision 2.
Anyway, I can be convinced a design is better than the one I suggested.
And sometime it's better to not abstract too much if the overall gets
a little bit too complex.
So can you post your current WIP?
Cheers,
Benjamin
^ permalink raw reply
* Re: [PATCH] HID: input: fix a4tech horizontal wheel custom usage id
From: Benjamin Tissoires @ 2019-06-11 8:43 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: Jiri Kosina, Dmitry Torokhov, open list:HID CORE LAYER, lkml
In-Reply-To: <20190610185343.27614-1-nsaenzjulienne@suse.de>
Hi Nicolas,
On Mon, Jun 10, 2019 at 8:54 PM Nicolas Saenz Julienne
<nsaenzjulienne@suse.de> wrote:
>
> Some a4tech mice use the 'GenericDesktop.00b8' usage id to inform
> whether the previous wheel report was horizontal or vertical. Before
> c01908a14bf73 ("HID: input: add mapping for "Toggle Display" key") this
> usage id was being mapped to 'Relative.Misc'. After the patch it's
> simply ignored (usage->type == 0 & usage->code == 0). Checking the HID
> Usage Tables it turns out it's a reserved usage_id, so it makes sense to
> map it the way it was. Ultimately this makes hid-a4tech ignore the
> WHEEL/HWHEEL selection event, as it has no usage->type.
>
> The patch reverts the handling of the usage id back to it's previous
> behavior.
Hmm, if A4Tech is using a reserved usage, we shouldn't fix this in
hid-input.c but in hid-a4tech instead.
Because you won't know when someone else in the HID consortium will
remap this usage to some other random axis, and your mouse will be
broken again.
How about you add a .input_mapping callback in hid-a4tech and map this
usage there to your needs? This way you will be sure that such a
situation will not happen again.
Cheers,
Benjamin
>
> Fixes: c01908a14bf73 ("HID: input: add mapping for "Toggle Display" key")
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> ---
> drivers/hid/hid-input.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index 63855f275a38..6a956d5a195e 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -671,7 +671,7 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
> if ((usage->hid & 0xf0) == 0xb0) { /* SC - Display */
> switch (usage->hid & 0xf) {
> case 0x05: map_key_clear(KEY_SWITCHVIDEOMODE); break;
> - default: goto ignore;
> + default: goto unknown;
> }
> break;
> }
> --
> 2.21.0
>
^ permalink raw reply
* Re: [PATCH -next] HID: logitech-dj: fix return value of logi_dj_recv_query_hidpp_devices
From: Hans de Goede @ 2019-06-11 8:39 UTC (permalink / raw)
To: Yuehaibing, jikos, benjamin.tissoires, jkosina; +Cc: linux-kernel, linux-input
In-Reply-To: <50800f5e-867d-ded9-235c-b9c2db1c41ef@huawei.com>
Hi,
On 11-06-19 05:00, Yuehaibing wrote:
> Hi all,
>
> Friendly ping...
>
> On 2019/5/25 22:09, YueHaibing wrote:
>> We should return 'retval' as the correct return value
>> instead of always zero.
>>
>> Fixes: 74808f9115ce ("HID: logitech-dj: add support for non unifying receivers")
>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Patch looks good to me:
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Regards,
Hans
>> ---
>> drivers/hid/hid-logitech-dj.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
>> index 41baa4dbbfcc..7f8db602eec0 100644
>> --- a/drivers/hid/hid-logitech-dj.c
>> +++ b/drivers/hid/hid-logitech-dj.c
>> @@ -1133,7 +1133,7 @@ static int logi_dj_recv_query_hidpp_devices(struct dj_receiver_dev *djrcv_dev)
>> HID_REQ_SET_REPORT);
>>
>> kfree(hidpp_report);
>> - return 0;
>> + return retval;
>> }
>>
>> static int logi_dj_recv_query_paired_devices(struct dj_receiver_dev *djrcv_dev)
>>
>
^ permalink raw reply
* Re: 答复: 答复: 答复: [PATCH] input: alps-fix the issue alps cs19 trackstick do not work.
From: Pali Rohár @ 2019-06-11 7:23 UTC (permalink / raw)
To: Hui Wang
Cc: Xiaoxiao Liu, XiaoXiao Liu, dmitry.torokhov@gmail.com,
peter.hutterer@who-t.net, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, Xiaojian Cao, zhangfp1@lenovo.com,
Naoki Saito, Hideo Kawase
In-Reply-To: <5587ddb9-fb5f-03db-ac11-a696c85c5f2f@canonical.com>
On Tuesday 11 June 2019 12:32:33 Hui Wang wrote:
> On 2019/6/11 上午11:23, Hui Wang wrote:
> > On 2019/6/11 上午11:05, Xiaoxiao Liu wrote:
> > > Hi Pali,
> > >
> > > I discussed with our FW team about this problem.
> > > We think the V8 method means a touchpad feature and does not fit
> > > the CS19 trackpoint device.
> > > CS19 TrackPoint needn't use any Absolute (Raw) mode and is usually
> > > use standard mouse data.
> > > CS19 TrackPoint device is a completely different device with
> > > DualPoint device of Dell/HP.
> > > CS19 TrackPoint device is independent of Touchpad. (Touchpad is
> > > connecting by I2C, TrackPoint is directly connecting with PS2 port.)
> > > And it has completely another FW.
> > >
> > > So we think it is better to use the mouse mode for CS19 trackpoint.
> >
> > Maybe here is some mis-understanding, the mouse mode here doesn't mean
> > we use psmouse-base.c for cs19 (bare ps/2 mouse), we plan to use
> > trackpoint.c to drive this HW, so this trackpoint has all features a
> > trackpoint should have.
> >
> And I sent a patch one month ago to let the the trackpoint.c to drive this
> HW: https://www.spinics.net/lists/linux-input/msg61341.html, maybe that
> patch is reference.
So instead of creating blacklist, you should check for TP_VARIANT_ALPS
in alps.c and disallow its usage.
Or maybe better, move trackpoint.c detect code before alsp.c detect code
in psmouse-base. And no changes in alps.c are needed.
> > Regards,
> >
> > Hui.
> >
> > >
> > > Best Regards
> > > Shona
> > > -----邮件原件-----
> > > 发件人: Pali Rohár <pali.rohar@gmail.com>
> > > 发送时间: Monday, June 10, 2019 6:43 PM
> > > 收件人: 劉 曉曉 Xiaoxiao Liu <xiaoxiao.liu-1@cn.alps.com>
> > > 抄送: XiaoXiao Liu <sliuuxiaonxiao@gmail.com>;
> > > dmitry.torokhov@gmail.com; peter.hutterer@who-t.net;
> > > hui.wang@canonical.com; linux-input@vger.kernel.org;
> > > linux-kernel@vger.kernel.org; 曹 曉建 Xiaojian Cao
> > > <xiaojian.cao@cn.alps.com>; zhangfp1@lenovo.com; 斉藤 直樹 Naoki
> > > Saito <naoki.saito@alpsalpine.com>; 川瀬 英夫 Hideo Kawase
> > > <hideo.kawase@alpsalpine.com>
> > > 主题: Re: 答复: 答复: [PATCH] input: alps-fix the issue alps cs19
> > > trackstick do not work.
> > >
> > > On Monday 10 June 2019 10:03:51 Xiaoxiao Liu wrote:
> > > > Hi Pali,
> > > Hi!
> > >
> > > > We register our CS19 device as ALPS_ONLY_TRACKSTICK device.
> > > > And let the V8 protocol function support the process of
> > > > ALPS_ONLY_TRACKSTICK device.
> > > >
> > > > I want to confirm if this solution OK?
> > > Yes, it is fine. Just make sure that touchapad input device is not
> > > registered when this ALPS_ONLY_TRACKSTICK flag is set. So userspace
> > > would not see any fake/unavailable touchpad input device.
> > >
> > > > Xiaoxiao.Liu
> > > --
> > > Pali Rohár
> > > pali.rohar@gmail.com
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: 答复: 答复: 答复: [PATCH] input: alps-fix the issue alps cs19 trackstick do not work.
From: Hui Wang @ 2019-06-11 4:32 UTC (permalink / raw)
To: Xiaoxiao Liu, Pali Rohár
Cc: XiaoXiao Liu, dmitry.torokhov@gmail.com, peter.hutterer@who-t.net,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Xiaojian Cao, zhangfp1@lenovo.com, Naoki Saito, Hideo Kawase
In-Reply-To: <ed65f8af-fefb-3c40-e7b1-dde3605f30e3@canonical.com>
On 2019/6/11 上午11:23, Hui Wang wrote:
> On 2019/6/11 上午11:05, Xiaoxiao Liu wrote:
>> Hi Pali,
>>
>> I discussed with our FW team about this problem.
>> We think the V8 method means a touchpad feature and does not fit the
>> CS19 trackpoint device.
>> CS19 TrackPoint needn't use any Absolute (Raw) mode and is usually
>> use standard mouse data.
>> CS19 TrackPoint device is a completely different device with
>> DualPoint device of Dell/HP.
>> CS19 TrackPoint device is independent of Touchpad. (Touchpad is
>> connecting by I2C, TrackPoint is directly connecting with PS2 port.)
>> And it has completely another FW.
>>
>> So we think it is better to use the mouse mode for CS19 trackpoint.
>
> Maybe here is some mis-understanding, the mouse mode here doesn't
> mean we use psmouse-base.c for cs19 (bare ps/2 mouse), we plan to use
> trackpoint.c to drive this HW, so this trackpoint has all features a
> trackpoint should have.
>
And I sent a patch one month ago to let the the trackpoint.c to drive
this HW: https://www.spinics.net/lists/linux-input/msg61341.html, maybe
that patch is reference.
> Regards,
>
> Hui.
>
>>
>> Best Regards
>> Shona
>> -----邮件原件-----
>> 发件人: Pali Rohár <pali.rohar@gmail.com>
>> 发送时间: Monday, June 10, 2019 6:43 PM
>> 收件人: 劉 曉曉 Xiaoxiao Liu <xiaoxiao.liu-1@cn.alps.com>
>> 抄送: XiaoXiao Liu <sliuuxiaonxiao@gmail.com>;
>> dmitry.torokhov@gmail.com; peter.hutterer@who-t.net;
>> hui.wang@canonical.com; linux-input@vger.kernel.org;
>> linux-kernel@vger.kernel.org; 曹 曉建 Xiaojian Cao
>> <xiaojian.cao@cn.alps.com>; zhangfp1@lenovo.com; 斉藤 直樹 Naoki Saito
>> <naoki.saito@alpsalpine.com>; 川瀬 英夫 Hideo Kawase
>> <hideo.kawase@alpsalpine.com>
>> 主题: Re: 答复: 答复: [PATCH] input: alps-fix the issue alps cs19
>> trackstick do not work.
>>
>> On Monday 10 June 2019 10:03:51 Xiaoxiao Liu wrote:
>>> Hi Pali,
>> Hi!
>>
>>> We register our CS19 device as ALPS_ONLY_TRACKSTICK device.
>>> And let the V8 protocol function support the process of
>>> ALPS_ONLY_TRACKSTICK device.
>>>
>>> I want to confirm if this solution OK?
>> Yes, it is fine. Just make sure that touchapad input device is not
>> registered when this ALPS_ONLY_TRACKSTICK flag is set. So userspace
>> would not see any fake/unavailable touchpad input device.
>>
>>> Xiaoxiao.Liu
>> --
>> Pali Rohár
>> pali.rohar@gmail.com
^ permalink raw reply
* Re: 答复: 答复: 答复: [PATCH] input: alps-fix the issue alps cs19 trackstick do not work.
From: Hui Wang @ 2019-06-11 3:23 UTC (permalink / raw)
To: Xiaoxiao Liu, Pali Rohár
Cc: XiaoXiao Liu, dmitry.torokhov@gmail.com, peter.hutterer@who-t.net,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Xiaojian Cao, zhangfp1@lenovo.com, Naoki Saito, Hideo Kawase
In-Reply-To: <OSBPR01MB485504868362073ED434F82FDAED0@OSBPR01MB4855.jpnprd01.prod.outlook.com>
On 2019/6/11 上午11:05, Xiaoxiao Liu wrote:
> Hi Pali,
>
> I discussed with our FW team about this problem.
> We think the V8 method means a touchpad feature and does not fit the CS19 trackpoint device.
> CS19 TrackPoint needn't use any Absolute (Raw) mode and is usually use standard mouse data.
> CS19 TrackPoint device is a completely different device with DualPoint device of Dell/HP.
> CS19 TrackPoint device is independent of Touchpad. (Touchpad is connecting by I2C, TrackPoint is directly connecting with PS2 port.)
> And it has completely another FW.
>
> So we think it is better to use the mouse mode for CS19 trackpoint.
Maybe here is some mis-understanding, the mouse mode here doesn't mean
we use psmouse-base.c for cs19 (bare ps/2 mouse), we plan to use
trackpoint.c to drive this HW, so this trackpoint has all features a
trackpoint should have.
Regards,
Hui.
>
> Best Regards
> Shona
> -----邮件原件-----
> 发件人: Pali Rohár <pali.rohar@gmail.com>
> 发送时间: Monday, June 10, 2019 6:43 PM
> 收件人: 劉 曉曉 Xiaoxiao Liu <xiaoxiao.liu-1@cn.alps.com>
> 抄送: XiaoXiao Liu <sliuuxiaonxiao@gmail.com>; dmitry.torokhov@gmail.com; peter.hutterer@who-t.net; hui.wang@canonical.com; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org; 曹 曉建 Xiaojian Cao <xiaojian.cao@cn.alps.com>; zhangfp1@lenovo.com; 斉藤 直樹 Naoki Saito <naoki.saito@alpsalpine.com>; 川瀬 英夫 Hideo Kawase <hideo.kawase@alpsalpine.com>
> 主题: Re: 答复: 答复: [PATCH] input: alps-fix the issue alps cs19 trackstick do not work.
>
> On Monday 10 June 2019 10:03:51 Xiaoxiao Liu wrote:
>> Hi Pali,
> Hi!
>
>> We register our CS19 device as ALPS_ONLY_TRACKSTICK device.
>> And let the V8 protocol function support the process of ALPS_ONLY_TRACKSTICK device.
>>
>> I want to confirm if this solution OK?
> Yes, it is fine. Just make sure that touchapad input device is not registered when this ALPS_ONLY_TRACKSTICK flag is set. So userspace would not see any fake/unavailable touchpad input device.
>
>> Xiaoxiao.Liu
> --
> Pali Rohár
> pali.rohar@gmail.com
^ permalink raw reply
* 答复: 答复: 答复: [PATCH] input: alps-fix the issue alps cs19 trackstick do not work.
From: Xiaoxiao Liu @ 2019-06-11 3:05 UTC (permalink / raw)
To: Pali Rohár
Cc: XiaoXiao Liu, dmitry.torokhov@gmail.com, peter.hutterer@who-t.net,
hui.wang@canonical.com, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, Xiaojian Cao, zhangfp1@lenovo.com,
Naoki Saito, Hideo Kawase
In-Reply-To: <20190610104310.qa5snt7jpcljodfv@pali>
Hi Pali,
I discussed with our FW team about this problem.
We think the V8 method means a touchpad feature and does not fit the CS19 trackpoint device.
CS19 TrackPoint needn't use any Absolute (Raw) mode and is usually use standard mouse data.
CS19 TrackPoint device is a completely different device with DualPoint device of Dell/HP.
CS19 TrackPoint device is independent of Touchpad. (Touchpad is connecting by I2C, TrackPoint is directly connecting with PS2 port.)
And it has completely another FW.
So we think it is better to use the mouse mode for CS19 trackpoint.
Best Regards
Shona
-----邮件原件-----
发件人: Pali Rohár <pali.rohar@gmail.com>
发送时间: Monday, June 10, 2019 6:43 PM
收件人: 劉 曉曉 Xiaoxiao Liu <xiaoxiao.liu-1@cn.alps.com>
抄送: XiaoXiao Liu <sliuuxiaonxiao@gmail.com>; dmitry.torokhov@gmail.com; peter.hutterer@who-t.net; hui.wang@canonical.com; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org; 曹 曉建 Xiaojian Cao <xiaojian.cao@cn.alps.com>; zhangfp1@lenovo.com; 斉藤 直樹 Naoki Saito <naoki.saito@alpsalpine.com>; 川瀬 英夫 Hideo Kawase <hideo.kawase@alpsalpine.com>
主题: Re: 答复: 答复: [PATCH] input: alps-fix the issue alps cs19 trackstick do not work.
On Monday 10 June 2019 10:03:51 Xiaoxiao Liu wrote:
> Hi Pali,
Hi!
> We register our CS19 device as ALPS_ONLY_TRACKSTICK device.
> And let the V8 protocol function support the process of ALPS_ONLY_TRACKSTICK device.
>
> I want to confirm if this solution OK?
Yes, it is fine. Just make sure that touchapad input device is not registered when this ALPS_ONLY_TRACKSTICK flag is set. So userspace would not see any fake/unavailable touchpad input device.
> Xiaoxiao.Liu
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [PATCH -next] HID: logitech-dj: fix return value of logi_dj_recv_query_hidpp_devices
From: Yuehaibing @ 2019-06-11 3:00 UTC (permalink / raw)
To: jikos, benjamin.tissoires, hdegoede, jkosina; +Cc: linux-kernel, linux-input
In-Reply-To: <20190525140908.2804-1-yuehaibing@huawei.com>
Hi all,
Friendly ping...
On 2019/5/25 22:09, YueHaibing wrote:
> We should return 'retval' as the correct return value
> instead of always zero.
>
> Fixes: 74808f9115ce ("HID: logitech-dj: add support for non unifying receivers")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/hid/hid-logitech-dj.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
> index 41baa4dbbfcc..7f8db602eec0 100644
> --- a/drivers/hid/hid-logitech-dj.c
> +++ b/drivers/hid/hid-logitech-dj.c
> @@ -1133,7 +1133,7 @@ static int logi_dj_recv_query_hidpp_devices(struct dj_receiver_dev *djrcv_dev)
> HID_REQ_SET_REPORT);
>
> kfree(hidpp_report);
> - return 0;
> + return retval;
> }
>
> static int logi_dj_recv_query_paired_devices(struct dj_receiver_dev *djrcv_dev)
>
^ 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