* 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
* [PATCH] HID: apple: Fix stuck function keys when using FN
From: Joao Moreno @ 2019-06-10 21:31 UTC (permalink / raw)
Cc: Joao Moreno, Jiri Kosina, Benjamin Tissoires, linux-input,
linux-kernel
This fixes an issue in which key down events for function keys would be
repeatedly emitted even after the user has raised the physical key. For
example, the driver fails to emit the F5 key up event when going through
the following steps:
- fnmode=1: hold FN, hold F5, release FN, release F5
- fnmode=2: hold F5, hold FN, release F5, release FN
The repeated F5 key down events can be easily verified using xev.
Signed-off-by: Joao Moreno <mail@joaomoreno.com>
---
drivers/hid/hid-apple.c | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
index 1cb41992aaa1..81867a6fa047 100644
--- a/drivers/hid/hid-apple.c
+++ b/drivers/hid/hid-apple.c
@@ -205,20 +205,21 @@ static int hidinput_apple_event(struct hid_device *hid, struct input_dev *input,
trans = apple_find_translation (table, usage->code);
if (trans) {
- if (test_bit(usage->code, asc->pressed_fn))
- do_translate = 1;
- else if (trans->flags & APPLE_FLAG_FKEY)
- do_translate = (fnmode == 2 && asc->fn_on) ||
- (fnmode == 1 && !asc->fn_on);
+ int fn_on = value ? asc->fn_on :
+ test_bit(usage->code, asc->pressed_fn);
+
+ if (!value)
+ clear_bit(usage->code, asc->pressed_fn);
+ else if (asc->fn_on)
+ set_bit(usage->code, asc->pressed_fn);
+
+ if (trans->flags & APPLE_FLAG_FKEY)
+ do_translate = (fnmode == 2 && fn_on) ||
+ (fnmode == 1 && !fn_on);
else
do_translate = asc->fn_on;
if (do_translate) {
- if (value)
- set_bit(usage->code, asc->pressed_fn);
- else
- clear_bit(usage->code, asc->pressed_fn);
-
input_event(input, usage->type, trans->to,
value);
--
2.19.1
^ permalink raw reply related
* [PATCH] HID: input: fix a4tech horizontal wheel custom usage id
From: Nicolas Saenz Julienne @ 2019-06-10 18:53 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: dmitry.torokhov, Nicolas Saenz Julienne, linux-input,
linux-kernel
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.
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 related
* Re: [PATCH 1/2] Input: synaptics-rmi4 - clear irqs before set irqs
From: Aaron Ma @ 2019-06-10 16:55 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input, linux-kernel, Cheiny, aduggan, benjamin.tissoires
In-Reply-To: <20190609165551.GB90002@dtor-ws>
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.
> 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.
Thanks,
Aaron
>
> Thanks,
>
> -- Dmitry
>
^ permalink raw reply
* Re: 答复: 答复: [PATCH] input: alps-fix the issue alps cs19 trackstick do not work.
From: Pali Rohár @ 2019-06-10 10:43 UTC (permalink / raw)
To: Xiaoxiao Liu
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: <OSBPR01MB4855A2A30A4F5E6BDCFE715FDA130@OSBPR01MB4855.jpnprd01.prod.outlook.com>
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-10 10:03 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: <OSBPR01MB4855707AC8ABB7CFBE5BBBD5DA130@OSBPR01MB4855.jpnprd01.prod.outlook.com>
++ Saito-san.
-----邮件原件-----
发件人: 劉 曉曉 Xiaoxiao Liu
发送时间: Monday, June 10, 2019 5:20 PM
收件人: Pali Rohár <pali.rohar@gmail.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>
主题: 答复: 答复: [PATCH] input: alps-fix the issue alps cs19 trackstick do not work.
Hi Pali,
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?
Xiaoxiao.Liu
-----邮件原件-----
发件人: 劉 曉曉 Xiaoxiao Liu
发送时间: Tuesday, May 28, 2019 3:55 PM
收件人: Pali Rohár <pali.rohar@gmail.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>
主题: 答复: 答复: [PATCH] input: alps-fix the issue alps cs19 trackstick do not work.
Add Kawase-san.
-----邮件原件-----
发件人: Pali Rohár <pali.rohar@gmail.com>
发送时间: Tuesday, May 28, 2019 3:18 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>
主题: Re: 答复: [PATCH] input: alps-fix the issue alps cs19 trackstick do not work.
On Tuesday 28 May 2019 01:37:14 Xiaoxiao Liu wrote:
> Add Saito-san.
>
> Hi Hui,
> Does it mean that your device (reported to kernel) sends only trackstick packets and not touchpad?
> -> Yes.
Ok, I think this answers all questions.
So your patch is not correct as it registers "fake" touchpad device even there is no touchpad at all.
You should fix your patch to not register touchpad input device, in your case it should register only trackstick device. I suggest to add some flag which would indicate such device (e.g. ALPS_ONLY_TRACKSTICK).
Also currently kernel exports following names when device has both trackstick and touchpad: "DualPoint Stick" and "DualPoint TouchPad".
And it exports name "GlidePoint" for touchpad-only device. So to be consistent you need to also modify this code for trackstick-only device.
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* [PATCH v3 3/3] iio: Add PAT9125 optical tracker sensor
From: Alexandre Mergnat @ 2019-06-10 9:29 UTC (permalink / raw)
To: robh+dt, mark.rutland, jic23
Cc: linux-kernel, linux-iio, baylibre-upstreaming, dmitry.torokhov,
linux-input, Alexandre Mergnat
In-Reply-To: <20190610092945.6330-1-amergnat@baylibre.com>
This adds support for PixArt Imaging’s miniature low power optical
navigation chip using LASER light source enabling digital surface tracking.
Feature and datasheet: [0]
This IIO driver allows to read delta or relative position on X and Y axis:
- The position relative to where the system started can be taken through
punctual "read_raw" which will issue a read in the device registers to
get the delta between last/current read and return the addition of all
the deltas.
- The delta can be retrieved using triggered buffer subscription
(i.e. iio_readdev). The buffer payload is:
|32 bits delta X|32 bits delta Y|timestamp|.
The possible I2C addresses are 0x73, 0x75 and 0x79.
X and Y axis CPI resolution can be get/set independently through IIO_SCALE.
The range value is 0-255 which means:
- 0 to ~1,275 Counts Per Inch on flat surface.
- 0 to ~630 Counts Per Rev on 1.0mm diameter STS shaft at 1.0mm distance.
More details on the datasheet.
The "position" directory is added to contain drivers which can provide
position data.
Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
[0]: http://www.pixart.com/products-detail/72/PAT9125EL-TKIT___TKMT
Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
---
drivers/iio/Kconfig | 1 +
drivers/iio/Makefile | 1 +
drivers/iio/position/Kconfig | 18 ++
drivers/iio/position/Makefile | 6 +
drivers/iio/position/pat9125.c | 499 +++++++++++++++++++++++++++++++++
5 files changed, 525 insertions(+)
create mode 100644 drivers/iio/position/Kconfig
create mode 100644 drivers/iio/position/Makefile
create mode 100644 drivers/iio/position/pat9125.c
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 1d736a4952ab..23d9780640e7 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -85,6 +85,7 @@ source "drivers/iio/light/Kconfig"
source "drivers/iio/magnetometer/Kconfig"
source "drivers/iio/multiplexer/Kconfig"
source "drivers/iio/orientation/Kconfig"
+source "drivers/iio/position/Kconfig"
if IIO_TRIGGER
source "drivers/iio/trigger/Kconfig"
endif #IIO_TRIGGER
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index bff682ad1cfb..1712011c0f4a 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -31,6 +31,7 @@ obj-y += light/
obj-y += magnetometer/
obj-y += multiplexer/
obj-y += orientation/
+obj-y += position/
obj-y += potentiometer/
obj-y += potentiostat/
obj-y += pressure/
diff --git a/drivers/iio/position/Kconfig b/drivers/iio/position/Kconfig
new file mode 100644
index 000000000000..1cf28896511c
--- /dev/null
+++ b/drivers/iio/position/Kconfig
@@ -0,0 +1,18 @@
+#
+# Optical tracker sensors
+#
+# When adding new entries keep the list in alphabetical order
+
+menu "Optical tracker sensors"
+
+config PAT9125
+ tristate "Optical tracker PAT9125 I2C driver"
+ depends on I2C
+ select IIO_BUFFER
+ help
+ Say yes here to build support for PAT9125 optical tracker
+ sensors.
+
+ To compile this driver as a module, say M here: the module will
+ be called pat9125.
+endmenu
diff --git a/drivers/iio/position/Makefile b/drivers/iio/position/Makefile
new file mode 100644
index 000000000000..cf294917ae2c
--- /dev/null
+++ b/drivers/iio/position/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for industrial I/O Optical tracker sensor drivers
+#
+
+# When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_PAT9125) += pat9125.o
diff --git a/drivers/iio/position/pat9125.c b/drivers/iio/position/pat9125.c
new file mode 100644
index 000000000000..22bf729bec9b
--- /dev/null
+++ b/drivers/iio/position/pat9125.c
@@ -0,0 +1,499 @@
+// SPDX-License-Identifier: (GPL-2.0)
+/*
+ * Copyright (C) 2019 BayLibre, SAS
+ * Author: Alexandre Mergnat <amergnat@baylibre.com>
+ */
+
+#include <linux/bitops.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/i2c.h>
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+#include <linux/iio/events.h>
+#include <linux/iio/buffer.h>
+#include <linux/iio/trigger.h>
+#include <linux/iio/trigger_consumer.h>
+#include <linux/iio/triggered_buffer.h>
+#include <linux/iio/kfifo_buf.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+
+/* I2C Address function to ID pin*/
+#define PAT9125_I2C_ADDR_HI 0x73
+#define PAT9125_I2C_ADDR_LO 0x75
+#define PAT9125_I2C_ADDR_NC 0x79
+
+/* Registers */
+#define PAT9125_PRD_ID1_REG 0x00
+#define PAT9125_PRD_ID2_REG 0x01
+#define PAT9125_MOTION_STATUS_REG 0x02
+#define PAT9125_DELTA_X_LO_REG 0x03
+#define PAT9125_DELTA_Y_LO_REG 0x04
+#define PAT9125_OP_MODE_REG 0x05
+#define PAT9125_CONFIG_REG 0x06
+#define PAT9125_WRITE_PROTEC_REG 0x09
+#define PAT9125_SLEEP1_REG 0x0A
+#define PAT9125_SLEEP2_REG 0x0B
+#define PAT9125_RES_X_REG 0x0D
+#define PAT9125_RES_Y_REG 0x0E
+#define PAT9125_DELTA_XY_HI_REG 0x12
+#define PAT9125_SHUTER_REG 0x14
+#define PAT9125_FRAME_AVG_REG 0x17
+#define PAT9125_ORIENTATION_REG 0x19
+
+/* Bits */
+#define PAT9125_VALID_MOTION_DATA_BIT BIT(7)
+#define PAT9125_RESET_BIT BIT(7)
+
+/* Registers' values */
+#define PAT9125_SENSOR_ID_VAL 0x31
+#define PAT9125_DISABLE_WRITE_PROTECT_VAL 0x5A
+#define PAT9125_ENABLE_WRITE_PROTECT_VAL 0x00
+
+/* Default Value of sampled value size */
+#define PAT9125_SAMPLED_VAL_BIT_SIZE 12
+
+struct pat9125_data {
+ struct regmap *regmap;
+ struct iio_trigger *indio_trig; /* Motion detection */
+ s32 delta_x;
+ s32 delta_y;
+ s32 position_x;
+ s32 position_y;
+ bool sampling;
+};
+
+static const struct iio_chan_spec pat9125_channels[] = {
+ {
+ .type = IIO_DISTANCE,
+ .modified = 1,
+ .channel2 = IIO_MOD_X,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
+ BIT(IIO_CHAN_INFO_SCALE),
+ .scan_index = 0,
+ .scan_type = {
+ .sign = 's',
+ .realbits = 32,
+ .storagebits = 32,
+ .endianness = IIO_CPU,
+ },
+ },
+ {
+ .type = IIO_DISTANCE,
+ .modified = 1,
+ .channel2 = IIO_MOD_Y,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
+ BIT(IIO_CHAN_INFO_SCALE),
+ .scan_index = 1,
+ .scan_type = {
+ .sign = 's',
+ .realbits = 32,
+ .storagebits = 32,
+ .endianness = IIO_CPU,
+ },
+ },
+ IIO_CHAN_SOFT_TIMESTAMP(2),
+};
+
+/**
+ * pat9125_write_pretected_reg() - Write value in protected register.
+ *
+ * @regmap: Pointer to I2C register map.
+ * @reg_addr: Register address.
+ * @reg_value: Value to be write in register.
+ *
+ * A value of zero will be returned on success, a negative errno will
+ * be returned in error cases.
+ */
+static int pat9125_write_pretected_reg(struct iio_dev *indio_dev,
+ u8 reg_addr, u8 reg_value)
+{
+ struct pat9125_data *data = iio_priv(indio_dev);
+ int ret;
+
+ ret = regmap_write(data->regmap,
+ PAT9125_WRITE_PROTEC_REG,
+ PAT9125_DISABLE_WRITE_PROTECT_VAL);
+ if (ret < 0) {
+ dev_err(indio_dev->dev.parent, "register 0x%x access failed %d\n",
+ PAT9125_WRITE_PROTEC_REG, ret);
+ return ret;
+ }
+
+ ret = regmap_write(data->regmap, reg_addr, reg_value);
+ if (ret < 0) {
+ dev_err(indio_dev->dev.parent, "register 0x%x access failed %d\n",
+ reg_addr, ret);
+ return ret;
+ }
+
+ ret = regmap_write(data->regmap,
+ PAT9125_WRITE_PROTEC_REG,
+ PAT9125_ENABLE_WRITE_PROTECT_VAL);
+ if (ret < 0) {
+ dev_err(indio_dev->dev.parent, "register 0x%x access failed %d\n",
+ PAT9125_WRITE_PROTEC_REG, ret);
+ return ret;
+ }
+ return 0;
+}
+/**
+ * pat9125_read_delta() - Read delta value, update delta & position data.
+ *
+ * @data: Driver's data structure.
+ *
+ * A value of zero will be returned on success, a negative errno will
+ * be returned in error cases.
+ */
+static int pat9125_read_delta(struct pat9125_data *data)
+{
+ struct regmap *regmap = data->regmap;
+ int status = 0;
+ int val_x = 0;
+ int val_y = 0;
+ int val_high_nibbles = 0;
+ int ret;
+
+ ret = regmap_read(regmap, PAT9125_MOTION_STATUS_REG, &status);
+ if (ret < 0)
+ return ret;
+
+ /* Check if motion is detected */
+ if (status & PAT9125_VALID_MOTION_DATA_BIT) {
+ ret = regmap_read(regmap, PAT9125_DELTA_X_LO_REG, &val_x);
+ if (ret < 0)
+ return ret;
+
+ ret = regmap_read(regmap, PAT9125_DELTA_Y_LO_REG, &val_y);
+ if (ret < 0)
+ return ret;
+
+ ret = regmap_read(regmap, PAT9125_DELTA_XY_HI_REG,
+ &val_high_nibbles);
+ if (ret < 0)
+ return ret;
+
+ val_x |= (val_high_nibbles << 4) & 0xF00;
+ val_y |= (val_high_nibbles << 8) & 0xF00;
+ val_x = sign_extend32(val_x,
+ PAT9125_SAMPLED_VAL_BIT_SIZE - 1);
+ val_y = sign_extend32(val_y,
+ PAT9125_SAMPLED_VAL_BIT_SIZE - 1);
+ data->position_x += val_x;
+ data->position_y += val_y;
+ data->delta_x = val_x;
+ data->delta_y = val_y;
+ }
+ return 0;
+}
+
+/**
+ * pat9125_read_raw() - Sample and return the value(s)
+ * function to the associated channel info enum.
+ **/
+static int pat9125_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val, int *val2, long mask)
+{
+ struct pat9125_data *data = iio_priv(indio_dev);
+ int ret;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ ret = pat9125_read_delta(data);
+ if (ret)
+ return ret;
+ switch (chan->channel2) {
+ case IIO_MOD_X:
+ *val = data->position_x;
+ return IIO_VAL_INT;
+ case IIO_MOD_Y:
+ *val = data->position_y;
+ return IIO_VAL_INT;
+ default:
+ return -EINVAL;
+ }
+ case IIO_CHAN_INFO_SCALE:
+ switch (chan->channel2) {
+ case IIO_MOD_X:
+ ret = regmap_read(data->regmap, PAT9125_RES_X_REG, val);
+ if (ret)
+ return ret;
+ else
+ return IIO_VAL_INT;
+ case IIO_MOD_Y:
+ ret = regmap_read(data->regmap, PAT9125_RES_Y_REG, val);
+ if (ret)
+ return ret;
+ else
+ return IIO_VAL_INT;
+ default:
+ return -EINVAL;
+ }
+ default:
+ return -EINVAL;
+ }
+}
+
+/**
+ * pat9125_write_raw() - Write the value(s)
+ * function to the associated channel info enum.
+ **/
+static int pat9125_write_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan, int val,
+ int val2, long mask)
+{
+ int ret;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_SCALE:
+ switch (chan->channel2) {
+ case IIO_MOD_X:
+ ret = pat9125_write_pretected_reg(indio_dev,
+ PAT9125_RES_X_REG, val);
+ return ret;
+ case IIO_MOD_Y:
+ ret = pat9125_write_pretected_reg(indio_dev,
+ PAT9125_RES_Y_REG, val);
+ return ret;
+ default:
+ return -EINVAL;
+ }
+ default:
+ return -EINVAL;
+ }
+}
+
+static irqreturn_t pat9125_threaded_trigger_handler(int irq, void *p)
+{
+ struct iio_poll_func *pf = p;
+ struct iio_dev *indio_dev = pf->indio_dev;
+ struct pat9125_data *data = iio_priv(indio_dev);
+ u8 buf[16]; /* Payload: Delta_X (4) | Delta_Y (4) | Timestamp (8) */
+ int ret;
+ s64 timestamp;
+
+ data->sampling = true;
+ ret = pat9125_read_delta(data);
+ if (ret) {
+ dev_err(indio_dev->dev.parent, "Read delta failed %d\n", ret);
+ return IRQ_NONE;
+ }
+ timestamp = iio_get_time_ns(indio_dev);
+ *((s32 *)&buf[0]) = data->delta_x;
+ *((s32 *)&buf[sizeof(s32)]) = data->delta_y;
+ data->delta_x = 0;
+ data->delta_y = 0;
+ iio_push_to_buffers_with_timestamp(indio_dev, buf, timestamp);
+ iio_trigger_notify_done(indio_dev->trig);
+ return IRQ_HANDLED;
+}
+
+/**
+ * pat9125_threaded_event_handler() - Threaded motion detection event handler
+ * @irq: The irq being handled.
+ * @private: struct iio_device pointer for the device.
+ */
+static irqreturn_t pat9125_threaded_event_handler(int irq, void *private)
+{
+ struct iio_dev *indio_dev = private;
+ struct pat9125_data *data = iio_priv(indio_dev);
+
+ iio_trigger_poll_chained(data->indio_trig);
+ return IRQ_HANDLED;
+}
+
+static int pat9125_buffer_postenable(struct iio_dev *indio_dev)
+{
+ struct pat9125_data *data = iio_priv(indio_dev);
+ int ret = 0;
+
+ ret = iio_triggered_buffer_postenable(indio_dev);
+ if (ret)
+ return ret;
+ /* Release interrupt pin on the device */
+ return pat9125_read_delta(data);
+}
+
+static const struct iio_buffer_setup_ops pat9125_buffer_ops = {
+ .postenable = pat9125_buffer_postenable,
+ .predisable = iio_triggered_buffer_predisable,
+};
+
+
+static const struct regmap_config pat9125_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+};
+
+static const struct iio_info pat9125_info = {
+ .read_raw = pat9125_read_raw,
+ .write_raw = pat9125_write_raw,
+};
+
+/*
+ * To detect if a new value is available, register status is checked. This
+ * method is safer than using a flag on GPIO IRQ to track event while sampling
+ * because falling edge is missed when device trig just after a read reg value
+ * (that happen for fast motions or high CPI setting).
+ *
+ * Note: To avoid infinite loop in "iio_trigger_notify_done" when it si not in
+ * buffer mode and kernel warning due to nested IRQ thread,
+ * this function must return 0.
+ */
+static int pat9125_trig_try_reenable(struct iio_trigger *trig)
+{
+ struct pat9125_data *data = iio_trigger_get_drvdata(trig);
+ struct regmap *regmap = data->regmap;
+ int status = 0;
+
+ if (data->sampling) {
+ regmap_read(regmap, PAT9125_MOTION_STATUS_REG, &status);
+ if (status & PAT9125_VALID_MOTION_DATA_BIT) {
+ data->sampling = false;
+ iio_trigger_poll_chained(data->indio_trig);
+ return 0;
+ }
+ }
+ data->sampling = false;
+ return 0;
+}
+
+static const struct iio_trigger_ops pat9125_trigger_ops = {
+ .try_reenable = pat9125_trig_try_reenable,
+};
+
+static int pat9125_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct pat9125_data *data;
+ struct iio_dev *indio_dev;
+ int ret, sensor_pid;
+
+ indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
+ if (!indio_dev) {
+ dev_err(&client->dev, "IIO device allocation failed\n");
+ return -ENOMEM;
+ }
+
+ data = iio_priv(indio_dev);
+ indio_dev->dev.parent = &client->dev;
+ indio_dev->name = id->name;
+ indio_dev->channels = pat9125_channels;
+ indio_dev->num_channels = ARRAY_SIZE(pat9125_channels);
+ indio_dev->info = &pat9125_info;
+ indio_dev->modes = INDIO_DIRECT_MODE;
+
+ ret = devm_iio_triggered_buffer_setup(&client->dev, indio_dev, NULL,
+ pat9125_threaded_trigger_handler, &pat9125_buffer_ops);
+ if (ret) {
+ dev_err(&client->dev, "unable to setup triggered buffer\n");
+ return ret;
+ }
+
+ data->indio_trig = devm_iio_trigger_alloc(&client->dev, "%s-dev%d",
+ indio_dev->name, indio_dev->id);
+ if (!data->indio_trig)
+ return -ENOMEM;
+ data->indio_trig->dev.parent = &client->dev;
+ data->indio_trig->ops = &pat9125_trigger_ops;
+ iio_trigger_set_drvdata(data->indio_trig, data);
+ ret = devm_iio_trigger_register(&client->dev, data->indio_trig);
+ if (ret) {
+ dev_err(&client->dev, "unable to register trigger\n");
+ return ret;
+ }
+
+ data->regmap = devm_regmap_init_i2c(client, &pat9125_regmap_config);
+ if (IS_ERR(data->regmap)) {
+ dev_err(&client->dev, "regmap init failed %ld\n",
+ PTR_ERR(data->regmap));
+ return PTR_ERR(data->regmap);
+ }
+
+ /* Check device ID */
+ ret = regmap_read(data->regmap, PAT9125_PRD_ID1_REG, &sensor_pid);
+ if (ret < 0) {
+ dev_err(&client->dev, "register 0x%x access failed %d\n",
+ PAT9125_PRD_ID1_REG, ret);
+ return ret;
+ }
+ if (sensor_pid != PAT9125_SENSOR_ID_VAL)
+ return -ENODEV;
+
+ /* Switch to bank0 (Magic number)*/
+ ret = regmap_write(data->regmap, 0x7F, 0x00);
+ if (ret < 0) {
+ dev_err(indio_dev->dev.parent, "register 0x%x access failed %d\n",
+ 0x7F, ret);
+ return ret;
+ }
+
+ /* Software reset */
+ ret = regmap_write_bits(data->regmap,
+ PAT9125_CONFIG_REG,
+ PAT9125_RESET_BIT,
+ 1);
+ if (ret < 0) {
+ dev_err(&client->dev, "register 0x%x access failed %d\n",
+ PAT9125_CONFIG_REG, ret);
+ return ret;
+ }
+
+ msleep(20);
+
+ /* Init GPIO IRQ */
+ if (client->irq) {
+ ret = devm_request_threaded_irq(&client->dev,
+ client->irq,
+ NULL,
+ pat9125_threaded_event_handler,
+ IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
+ "pat9125",
+ indio_dev);
+ if (ret) {
+ dev_err(&client->dev, "GPIO IRQ init failed\n");
+ return ret;
+ }
+ }
+
+ ret = devm_iio_device_register(&client->dev, indio_dev);
+ if (ret) {
+ dev_err(&client->dev, "IIO device register failed\n");
+ return ret;
+ }
+
+ i2c_set_clientdata(client, indio_dev);
+ return 0;
+}
+
+static const struct i2c_device_id pat9125_id[] = {
+ { "pat9125", 0 },
+ {}
+};
+MODULE_DEVICE_TABLE(i2c, pat9125_id);
+
+static const unsigned short normal_i2c[] = {
+ PAT9125_I2C_ADDR_HI,
+ PAT9125_I2C_ADDR_LO,
+ PAT9125_I2C_ADDR_NC,
+ I2C_CLIENT_END
+};
+
+static struct i2c_driver pat9125_driver = {
+ .driver = {
+ .name = "pat9125",
+ },
+ .probe = pat9125_probe,
+ .address_list = normal_i2c,
+ .id_table = pat9125_id,
+};
+
+module_i2c_driver(pat9125_driver);
+
+MODULE_AUTHOR("Alexandre Mergnat <amergnat@baylibre.com>");
+MODULE_DESCRIPTION("Optical Tracking sensor");
+MODULE_LICENSE("GPL");
--
2.17.1
^ permalink raw reply related
* [PATCH v3 2/3] dt-bindings: iio: position: Add docs pat9125
From: Alexandre Mergnat @ 2019-06-10 9:29 UTC (permalink / raw)
To: robh+dt, mark.rutland, jic23
Cc: linux-kernel, linux-iio, baylibre-upstreaming, dmitry.torokhov,
linux-input, Alexandre Mergnat
In-Reply-To: <20190610092945.6330-1-amergnat@baylibre.com>
Add documentation for the optical tracker PAT9125 and
"position" directory for chip which can provides position data.
Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
---
.../bindings/iio/position/pat9125.txt | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/position/pat9125.txt
diff --git a/Documentation/devicetree/bindings/iio/position/pat9125.txt b/Documentation/devicetree/bindings/iio/position/pat9125.txt
new file mode 100644
index 000000000000..4028aeef9b42
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/position/pat9125.txt
@@ -0,0 +1,18 @@
+PixArt Imaging PAT9125 Optical Tracking Miniature Chip device driver
+
+Required properties:
+ - compatible: must be "pixart,pat9125"
+ - reg: i2c address where to find the device
+ - interrupts: the sole interrupt generated by the device
+
+ Refer to interrupt-controller/interrupts.txt for generic
+ interrupt client node bindings.
+
+Example:
+
+pat9125@75 {
+ compatible = "pixart,pat9125";
+ reg = <0x75>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
+};
--
2.17.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox