* [PATCH] HID: uclogic: Add support for Huion HS64 tablet
From: Kyle Godbey @ 2019-06-15 23:15 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, linux-input; +Cc: linux-kernel, Kyle Godbey
Add support for Huion HS64 drawing tablet to hid-uclogic
Signed-off-by: Kyle Godbey <me@kyle.ee>
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-uclogic-core.c | 2 ++
drivers/hid/hid-uclogic-params.c | 2 ++
3 files changed, 5 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 84e0c78d73cd..86ed32dd18ca 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -569,6 +569,7 @@
#define USB_VENDOR_ID_HUION 0x256c
#define USB_DEVICE_ID_HUION_TABLET 0x006e
+#define USB_DEVICE_ID_HUION_HS64 0x006d
#define USB_VENDOR_ID_IBM 0x04b3
#define USB_DEVICE_ID_IBM_SCROLLPOINT_III 0x3100
diff --git a/drivers/hid/hid-uclogic-core.c b/drivers/hid/hid-uclogic-core.c
index 8fe02d81265d..914fb527ae7a 100644
--- a/drivers/hid/hid-uclogic-core.c
+++ b/drivers/hid/hid-uclogic-core.c
@@ -369,6 +369,8 @@ static const struct hid_device_id uclogic_devices[] = {
USB_DEVICE_ID_UCLOGIC_TABLET_TWHA60) },
{ HID_USB_DEVICE(USB_VENDOR_ID_HUION,
USB_DEVICE_ID_HUION_TABLET) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_HUION,
+ USB_DEVICE_ID_HUION_HS64) },
{ HID_USB_DEVICE(USB_VENDOR_ID_UCLOGIC,
USB_DEVICE_ID_HUION_TABLET) },
{ HID_USB_DEVICE(USB_VENDOR_ID_UCLOGIC,
diff --git a/drivers/hid/hid-uclogic-params.c b/drivers/hid/hid-uclogic-params.c
index 0187c9f8fc22..273d784fff66 100644
--- a/drivers/hid/hid-uclogic-params.c
+++ b/drivers/hid/hid-uclogic-params.c
@@ -977,6 +977,8 @@ int uclogic_params_init(struct uclogic_params *params,
/* FALL THROUGH */
case VID_PID(USB_VENDOR_ID_HUION,
USB_DEVICE_ID_HUION_TABLET):
+ case VID_PID(USB_VENDOR_ID_HUION,
+ USB_DEVICE_ID_HUION_HS64):
case VID_PID(USB_VENDOR_ID_UCLOGIC,
USB_DEVICE_ID_HUION_TABLET):
case VID_PID(USB_VENDOR_ID_UCLOGIC,
--
2.21.0
^ permalink raw reply related
* Re: [PATCH 2/2] HID: wacom: Don't report anything prior to the tool entering range
From: Greg KH @ 2019-06-15 15:32 UTC (permalink / raw)
To: Jason Gerecke
Cc: # v3.17+, Sasha Levin, Linux Input, Ping Cheng,
Aaron Armstrong Skomra, Jason Gerecke, Aaron Armstrong Skomra
In-Reply-To: <20190612071042.GA13698@kroah.com>
On Wed, Jun 12, 2019 at 09:10:42AM +0200, Greg KH wrote:
> On Tue, Jun 11, 2019 at 01:45:36PM -0700, Jason Gerecke wrote:
> > On Tue, Jun 11, 2019 at 12:22 PM Greg KH <greg@kroah.com> wrote:
> > >
> > > On Tue, Jun 11, 2019 at 12:02:47PM -0700, Jason Gerecke wrote:
> > > > I haven't been keeping a close eye on this and just noticed that this
> > > > patch set doesn't seem to have been merged into stable. There's also a
> > > > second patch series (beginning with "[PATCH 1/3] HID: wacom: Send
> > > > BTN_TOUCH in response to INTUOSP2_BT eraser contact") that hasn't seen
> > > > any stable activity either.
> > > >
> > > > Any idea what's up?
> > >
> > > I don't see these in my queue at all.
> > >
> > > What is the git commit id of these patches in Linus's tree?
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > Ah, looks like the HID tree's "for-5.2/fixes" branch hasn't been
> > pulled yet. That could explain things.
> >
> > 69dbdfffef20c715df9f381b2cee4e9e0a4efd93 HID: wacom: Sync INTUOSP2_BT
> > touch state after each frame if necessary
> > 6441fc781c344df61402be1fde582c4491fa35fa HID: wacom: Correct button
> > numbering 2nd-gen Intuos Pro over Bluetooth
> > fe7f8d73d1af19b678171170e4e5384deb57833d HID: wacom: Send BTN_TOUCH in
> > response to INTUOSP2_BT eraser contact
> > e92a7be7fe5b2510fa60965eaf25f9e3dc08b8cc HID: wacom: Don't report
> > anything prior to the tool entering range
> > 2cc08800a6b9fcda7c7afbcf2da1a6e8808da725 HID: wacom: Don't set tool
> > type until we're in range
>
> There is nothing I can do until the patches are in Linus's tree, sorry.
Now applied for the ones that I could, you should have some "FAILED"
emails for the rejects that did not apply to 4.14.y
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/2] HID: input: make sure the wheel high resolution multiplier is set
From: Greg KH @ 2019-06-15 15:29 UTC (permalink / raw)
To: Thomas Backlund
Cc: James Feeney, Benjamin Tissoires, Peter Hutterer, Sasha Levin,
Jiri Kosina, linux-input, linux-kernel, stable
In-Reply-To: <e158e981-47e6-a7f8-6416-4eff7af2c5d0@mageia.org>
On Sat, Jun 15, 2019 at 12:03:04PM +0300, Thomas Backlund wrote:
> Den 15-06-2019 kl. 08:50, skrev Greg KH:
> > On Fri, Jun 14, 2019 at 04:09:35PM -0600, James Feeney wrote:
> > > Hey Everyone
> > >
> > > On 4/24/19 10:41 AM, Benjamin Tissoires wrote:
> > > > > > For a patch to be picked up by stable, it first needs to go in Linus'
> > > > > > tree. Currently we are working on 5.1, so any stable patches need to
> > > > > > go in 5.1 first. Then, once they hit Linus' tree, the stable team will
> > > > > > pick them and backport them in the appropriate stable tree.
> > >
> > > Hmm - so, I just booted linux 5.1.9, and this patch set is *still* missing from the kernel.
> > >
> > > Is there anything that we can do about this?
> >
> > What is the git commit id of the patch in Linus's tree?
> >
> > As I said before, it can not be backported until it shows up there
> > first.
> >
>
> That would be:
> d43c17ead879ba7c076dc2f5fd80cd76047c9ff4
>
> and
>
> 39b3c3a5fbc5d744114e497d35bf0c12f798c134
Thanks, now queued up.
greg k-h
^ permalink raw reply
* Re: [PATCH 1/2] HID: input: make sure the wheel high resolution multiplier is set
From: Thomas Backlund @ 2019-06-15 9:03 UTC (permalink / raw)
To: Greg KH, James Feeney
Cc: Benjamin Tissoires, Peter Hutterer, Sasha Levin, Jiri Kosina,
linux-input, linux-kernel, stable
In-Reply-To: <20190615055019.GC23883@kroah.com>
Den 15-06-2019 kl. 08:50, skrev Greg KH:
> On Fri, Jun 14, 2019 at 04:09:35PM -0600, James Feeney wrote:
>> Hey Everyone
>>
>> On 4/24/19 10:41 AM, Benjamin Tissoires wrote:
>>>>> For a patch to be picked up by stable, it first needs to go in Linus'
>>>>> tree. Currently we are working on 5.1, so any stable patches need to
>>>>> go in 5.1 first. Then, once they hit Linus' tree, the stable team will
>>>>> pick them and backport them in the appropriate stable tree.
>>
>> Hmm - so, I just booted linux 5.1.9, and this patch set is *still* missing from the kernel.
>>
>> Is there anything that we can do about this?
>
> What is the git commit id of the patch in Linus's tree?
>
> As I said before, it can not be backported until it shows up there
> first.
>
That would be:
d43c17ead879ba7c076dc2f5fd80cd76047c9ff4
and
39b3c3a5fbc5d744114e497d35bf0c12f798c134
^ permalink raw reply
* Re: [PATCH 1/2] HID: input: make sure the wheel high resolution multiplier is set
From: Greg KH @ 2019-06-15 5:50 UTC (permalink / raw)
To: James Feeney
Cc: Benjamin Tissoires, Peter Hutterer, Sasha Levin, Jiri Kosina,
linux-input, linux-kernel, stable
In-Reply-To: <b6410e5d-b165-7a9b-2ef5-eb44c8de7753@nurealm.net>
On Fri, Jun 14, 2019 at 04:09:35PM -0600, James Feeney wrote:
> Hey Everyone
>
> On 4/24/19 10:41 AM, Benjamin Tissoires wrote:
> >>> For a patch to be picked up by stable, it first needs to go in Linus'
> >>> tree. Currently we are working on 5.1, so any stable patches need to
> >>> go in 5.1 first. Then, once they hit Linus' tree, the stable team will
> >>> pick them and backport them in the appropriate stable tree.
>
> Hmm - so, I just booted linux 5.1.9, and this patch set is *still* missing from the kernel.
>
> Is there anything that we can do about this?
What is the git commit id of the patch in Linus's tree?
As I said before, it can not be backported until it shows up there
first.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/2] HID: input: make sure the wheel high resolution multiplier is set
From: James Feeney @ 2019-06-14 22:09 UTC (permalink / raw)
To: Benjamin Tissoires, Peter Hutterer, Sasha Levin, Jiri Kosina
Cc: linux-input, linux-kernel, stable
In-Reply-To: <CAO-hwJK614pzseUsGqH65fCnrm=N7970i4_mqi0m1gdkY=J0ag@mail.gmail.com>
Hey Everyone
On 4/24/19 10:41 AM, Benjamin Tissoires wrote:
>>> For a patch to be picked up by stable, it first needs to go in Linus'
>>> tree. Currently we are working on 5.1, so any stable patches need to
>>> go in 5.1 first. Then, once they hit Linus' tree, the stable team will
>>> pick them and backport them in the appropriate stable tree.
Hmm - so, I just booted linux 5.1.9, and this patch set is *still* missing from the kernel.
Is there anything that we can do about this?
James
^ permalink raw reply
* Re: [PATCH] Input: cros_ec_keyb: mask out extra flags in event_type
From: Benson Leung @ 2019-06-14 19:32 UTC (permalink / raw)
To: Ting Shen
Cc: LKML, Nicolas Boichat, Pi-Hsun Shih, Enrico Granata,
Enric Balletbo i Serra, Heiko Stuebner, Guenter Roeck,
Brian Norris, Benson Leung, Dmitry Torokhov, linux-input,
Colin Ian King
In-Reply-To: <20190614065438.142867-1-phoenixshen@chromium.org>
[-- Attachment #1: Type: text/plain, Size: 584 bytes --]
Hi Ting,
On Fri, Jun 14, 2019 at 02:54:38PM +0800, Ting Shen wrote:
> http://crosreview.com/1341159 added a EC_MKBP_HAS_MORE_EVENTS flag to
> the event_type field, the receiver side should mask out this extra bit when
> processing the event.
>
> Signed-off-by: Ting Shen <phoenixshen@chromium.org>
>
Reviewed-by: Benson Leung <bleung@chromium.org>
Looks good for chrome-platform, once ib-mfd-cros-v5.3 is merged.
Thanks,
Benson
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
bleung@google.com
Chromium OS Project
bleung@chromium.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] Input: cros_ec_keyb: mask out extra flags in event_type
From: Dmitry Torokhov @ 2019-06-14 19:19 UTC (permalink / raw)
To: Benson Leung
Cc: Enrico Granata, Ting Shen, LKML, Nicolas Boichat, Pi-Hsun Shih,
Enrico Granata, Enric Balletbo i Serra, Heiko Stuebner,
Guenter Roeck, Brian Norris, Benson Leung, linux-input,
Colin Ian King, gwendal, Lee Jones
In-Reply-To: <20190614190957.GA243443@google.com>
On Fri, Jun 14, 2019 at 12:09:57PM -0700, Benson Leung wrote:
> Hi Dmitry,
>
> On Fri, Jun 14, 2019 at 11:55:33AM -0700, Dmitry Torokhov wrote:
> > On Fri, Jun 14, 2019 at 11:27:03AM -0700, Enrico Granata wrote:
> > > On Thu, Jun 13, 2019 at 11:54 PM Ting Shen <phoenixshen@chromium.org> wrote:
> > > >
> > > > http://crosreview.com/1341159 added a EC_MKBP_HAS_MORE_EVENTS flag to
> > > > the event_type field, the receiver side should mask out this extra bit when
> > > > processing the event.
> > > >
> > > > Signed-off-by: Ting Shen <phoenixshen@chromium.org>
> > >
> > > Reviewed-by: Enrico Granata <egranata@google.com>
> >
> > EC_MKBP_EVENT_TYPE_MASK is not in Linus' tree. It would be better to
> > merge this path through whatever tree that is bringing in that
> > definition.
> >
> > Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>
> Yup, this looks like it's coming in through Lee's MFD tree, a series from
> Gwendal to update cros_ec_commands.h.
>
> 784dd15c930f mfd: cros_ec: Fix event processing API
>
> That commit is in the immutable branch for v5.3 here:
> git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-cros-v5.3
>
> I'd recommend the chrome-platform tree since we'll be pulling in that IB too
> for some other refactoring Enric is working on.
Yeah, I'm fine with this going through chrome-platform.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: cros_ec_keyb: mask out extra flags in event_type
From: Benson Leung @ 2019-06-14 19:09 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Enrico Granata, Ting Shen, LKML, Nicolas Boichat, Pi-Hsun Shih,
Enrico Granata, Enric Balletbo i Serra, Heiko Stuebner,
Guenter Roeck, Brian Norris, Benson Leung, linux-input,
Colin Ian King, gwendal, Lee Jones
In-Reply-To: <20190614185533.GA142889@dtor-ws>
[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]
Hi Dmitry,
On Fri, Jun 14, 2019 at 11:55:33AM -0700, Dmitry Torokhov wrote:
> On Fri, Jun 14, 2019 at 11:27:03AM -0700, Enrico Granata wrote:
> > On Thu, Jun 13, 2019 at 11:54 PM Ting Shen <phoenixshen@chromium.org> wrote:
> > >
> > > http://crosreview.com/1341159 added a EC_MKBP_HAS_MORE_EVENTS flag to
> > > the event_type field, the receiver side should mask out this extra bit when
> > > processing the event.
> > >
> > > Signed-off-by: Ting Shen <phoenixshen@chromium.org>
> >
> > Reviewed-by: Enrico Granata <egranata@google.com>
>
> EC_MKBP_EVENT_TYPE_MASK is not in Linus' tree. It would be better to
> merge this path through whatever tree that is bringing in that
> definition.
>
> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Yup, this looks like it's coming in through Lee's MFD tree, a series from
Gwendal to update cros_ec_commands.h.
784dd15c930f mfd: cros_ec: Fix event processing API
That commit is in the immutable branch for v5.3 here:
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-cros-v5.3
I'd recommend the chrome-platform tree since we'll be pulling in that IB too
for some other refactoring Enric is working on.
Thanks,
Benson
>
> Thanks.
>
> --
> Dmitry
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
bleung@google.com
Chromium OS Project
bleung@chromium.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] Input: cros_ec_keyb: mask out extra flags in event_type
From: Dmitry Torokhov @ 2019-06-14 18:55 UTC (permalink / raw)
To: Enrico Granata
Cc: Ting Shen, LKML, Nicolas Boichat, Pi-Hsun Shih, Enrico Granata,
Enric Balletbo i Serra, Heiko Stuebner, Guenter Roeck,
Brian Norris, Benson Leung, linux-input, Colin Ian King
In-Reply-To: <CAPR809sASD=MrQkJULVBgc_iqiPKE2xr8eUR0d4qymQkLUYRaw@mail.gmail.com>
On Fri, Jun 14, 2019 at 11:27:03AM -0700, Enrico Granata wrote:
> On Thu, Jun 13, 2019 at 11:54 PM Ting Shen <phoenixshen@chromium.org> wrote:
> >
> > http://crosreview.com/1341159 added a EC_MKBP_HAS_MORE_EVENTS flag to
> > the event_type field, the receiver side should mask out this extra bit when
> > processing the event.
> >
> > Signed-off-by: Ting Shen <phoenixshen@chromium.org>
>
> Reviewed-by: Enrico Granata <egranata@google.com>
EC_MKBP_EVENT_TYPE_MASK is not in Linus' tree. It would be better to
merge this path through whatever tree that is bringing in that
definition.
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: cros_ec_keyb: mask out extra flags in event_type
From: Enrico Granata @ 2019-06-14 18:27 UTC (permalink / raw)
To: Ting Shen
Cc: LKML, Nicolas Boichat, Pi-Hsun Shih, Enrico Granata,
Enric Balletbo i Serra, Heiko Stuebner, Guenter Roeck,
Brian Norris, Benson Leung, Dmitry Torokhov, linux-input,
Colin Ian King
In-Reply-To: <20190614065438.142867-1-phoenixshen@chromium.org>
On Thu, Jun 13, 2019 at 11:54 PM Ting Shen <phoenixshen@chromium.org> wrote:
>
> http://crosreview.com/1341159 added a EC_MKBP_HAS_MORE_EVENTS flag to
> the event_type field, the receiver side should mask out this extra bit when
> processing the event.
>
> Signed-off-by: Ting Shen <phoenixshen@chromium.org>
Reviewed-by: Enrico Granata <egranata@google.com>
>
> ---
>
> drivers/input/keyboard/cros_ec_keyb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/keyboard/cros_ec_keyb.c b/drivers/input/keyboard/cros_ec_keyb.c
> index d5600118159835..38cb6d82d8fe67 100644
> --- a/drivers/input/keyboard/cros_ec_keyb.c
> +++ b/drivers/input/keyboard/cros_ec_keyb.c
> @@ -237,7 +237,7 @@ static int cros_ec_keyb_work(struct notifier_block *nb,
> if (queued_during_suspend && !device_may_wakeup(ckdev->dev))
> return NOTIFY_OK;
>
> - switch (ckdev->ec->event_data.event_type) {
> + switch (ckdev->ec->event_data.event_type & EC_MKBP_EVENT_TYPE_MASK) {
> case EC_MKBP_EVENT_KEY_MATRIX:
> pm_wakeup_event(ckdev->dev, 0);
>
> --
> 2.22.0.rc2.383.gf4fbbf30c2-goog
>
^ permalink raw reply
* [PATCH v2 06/10] mfd / platform: cros_ec: Reorganize platform and mfd includes
From: Enric Balletbo i Serra @ 2019-06-14 16:36 UTC (permalink / raw)
To: linux-kernel
Cc: gwendal, Guenter Roeck, Benson Leung, Lee Jones, kernel, dtor,
Andy Shevchenko, Mark Brown, Wolfram Sang, Neil Armstrong,
Alexandre Belloni, Jonathan Cameron, Benjamin Tissoires,
Dmitry Torokhov, Sebastian Reichel, Mauro Carvalho Chehab,
alsa-devel, Alessandro Zummo, linux-iio, Fabien Lahoudere
In-Reply-To: <20190614163635.22413-1-enric.balletbo@collabora.com>
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: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
Changes in v2: None
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_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 +-
33 files changed, 377 insertions(+), 349 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 d465bcde9fc4..7572fe096c72 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -19,11 +19,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_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 02f9e8257581..a4167dfd85bf 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 7e9c3984ef6a..ed8eca28c195 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 related
* Re: [PATCH v1] Input: rotary-encoder - Add gpio as push button
From: Maxime Ripard @ 2019-06-14 14:51 UTC (permalink / raw)
To: Mylène Josserand
Cc: dmitry.torokhov, robh+dt, mark.rutland, linux-input, devicetree,
linux-kernel, thomas.petazzoni
In-Reply-To: <20190614133651.28396-1-mylene.josserand@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]
Hi Mylene,
On Fri, Jun 14, 2019 at 03:36:51PM +0200, Mylène Josserand wrote:
> Add the support of a gpio that can be defined as a push button.
> Thanks to that, it is possible to emit a keycode in case of a
> "push" event, if the rotary supports that.
>
> The keycode to emit is defined using "linux,code" property
> (such as in gpio-keys).
>
> Signed-off-by: Mylène Josserand <mylene.josserand@bootlin.com>
> ---
> .../devicetree/bindings/input/rotary-encoder.txt | 5 +++
> drivers/input/misc/rotary_encoder.c | 50 ++++++++++++++++++++++
> 2 files changed, 55 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt b/Documentation/devicetree/bindings/input/rotary-encoder.txt
> index a644408b33b8..1cfce5d0b5c4 100644
> --- a/Documentation/devicetree/bindings/input/rotary-encoder.txt
> +++ b/Documentation/devicetree/bindings/input/rotary-encoder.txt
> @@ -22,6 +22,9 @@ Optional properties:
> - wakeup-source: Boolean, rotary encoder can wake up the system.
> - rotary-encoder,encoding: String, the method used to encode steps.
> Supported are "gray" (the default and more common) and "binary".
> +- push-gpio: a gpio to be used as a detection of a push from the rotary.
According to Documentation/devicetree/bindings/gpio/gpio.txt, GPIO
properties with a -gpio suffix are now deprecated in favor of the
-gpios suffix.
> +- linux,code: keycode to emit with the push-gpio of this rotary encoder.
> + Required property in case "push-gpio"'s one is used.
I guess we should make it clear in the property name that it's the
keycode emitted at push. Otherwise, it will be ambiguous between the
rotary itself, or the button.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH 3/3] video: fbdev: don't print error message on framebuffer_alloc() failure
From: Bartlomiej Zolnierkiewicz @ 2019-06-14 14:51 UTC (permalink / raw)
To: linux-fbdev, dri-devel, linux-kernel, linux-input
Cc: Benjamin Tissoires, Bruno Prémont, Jiri Kosina
In-Reply-To: <CGME20190614145128eucas1p2783e7d644ef8823d211896298e8988fc@eucas1p2.samsung.com>
framebuffer_alloc() can fail only on kzalloc() memory allocation
failure and since kzalloc() will print error message in such case
we can omit printing extra error message in drivers (which BTW is
what the majority of framebuffer_alloc() users is doing already).
Cc: "Bruno Prémont" <bonbons@linux-vserver.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
---
drivers/hid/hid-picolcd_fb.c | 4 +---
drivers/video/fbdev/amifb.c | 4 +---
drivers/video/fbdev/arkfb.c | 4 +---
drivers/video/fbdev/atmel_lcdfb.c | 4 +---
drivers/video/fbdev/aty/aty128fb.c | 5 ++---
drivers/video/fbdev/aty/atyfb_base.c | 10 ++++------
drivers/video/fbdev/aty/radeon_base.c | 2 --
drivers/video/fbdev/chipsfb.c | 1 -
drivers/video/fbdev/cirrusfb.c | 5 +----
drivers/video/fbdev/da8xx-fb.c | 1 -
drivers/video/fbdev/efifb.c | 1 -
drivers/video/fbdev/grvga.c | 4 +---
drivers/video/fbdev/gxt4500.c | 5 ++---
drivers/video/fbdev/hyperv_fb.c | 4 +---
drivers/video/fbdev/i740fb.c | 4 +---
drivers/video/fbdev/imsttfb.c | 5 +----
drivers/video/fbdev/intelfb/intelfbdrv.c | 5 ++---
drivers/video/fbdev/jz4740_fb.c | 4 +---
drivers/video/fbdev/mb862xx/mb862xxfbdrv.c | 5 +----
drivers/video/fbdev/mbx/mbxfb.c | 4 +---
drivers/video/fbdev/omap/omapfb_main.c | 2 --
drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 6 +-----
drivers/video/fbdev/platinumfb.c | 5 ++---
drivers/video/fbdev/pmag-aa-fb.c | 4 +---
drivers/video/fbdev/pmag-ba-fb.c | 4 +---
drivers/video/fbdev/pmagb-b-fb.c | 4 +---
drivers/video/fbdev/pvr2fb.c | 6 +-----
drivers/video/fbdev/riva/fbdev.c | 1 -
drivers/video/fbdev/s3c-fb.c | 4 +---
drivers/video/fbdev/s3fb.c | 4 +---
drivers/video/fbdev/sh_mobile_lcdcfb.c | 8 ++------
drivers/video/fbdev/sm501fb.c | 4 +---
drivers/video/fbdev/sm712fb.c | 1 -
drivers/video/fbdev/smscufx.c | 4 +---
drivers/video/fbdev/ssd1307fb.c | 4 +---
drivers/video/fbdev/sunxvr1000.c | 1 -
drivers/video/fbdev/sunxvr2500.c | 1 -
drivers/video/fbdev/sunxvr500.c | 1 -
drivers/video/fbdev/tgafb.c | 4 +---
drivers/video/fbdev/udlfb.c | 4 +---
drivers/video/fbdev/via/viafbdev.c | 6 +-----
drivers/video/fbdev/vt8623fb.c | 4 +---
42 files changed, 40 insertions(+), 123 deletions(-)
Index: b/drivers/hid/hid-picolcd_fb.c
===================================================================
--- a/drivers/hid/hid-picolcd_fb.c
+++ b/drivers/hid/hid-picolcd_fb.c
@@ -522,10 +522,8 @@ int picolcd_init_framebuffer(struct pico
sizeof(struct fb_deferred_io) +
sizeof(struct picolcd_fb_data) +
PICOLCDFB_SIZE, dev);
- if (info == NULL) {
- dev_err(dev, "failed to allocate a framebuffer\n");
+ if (!info)
goto err_nomem;
- }
info->fbdefio = info->par;
*info->fbdefio = picolcd_fb_defio;
Index: b/drivers/video/fbdev/amifb.c
===================================================================
--- a/drivers/video/fbdev/amifb.c
+++ b/drivers/video/fbdev/amifb.c
@@ -3554,10 +3554,8 @@ static int __init amifb_probe(struct pla
custom.dmacon = DMAF_ALL | DMAF_MASTER;
info = framebuffer_alloc(sizeof(struct amifb_par), &pdev->dev);
- if (!info) {
- dev_err(&pdev->dev, "framebuffer_alloc failed\n");
+ if (!info)
return -ENOMEM;
- }
strcpy(info->fix.id, "Amiga ");
info->fix.visual = FB_VISUAL_PSEUDOCOLOR;
Index: b/drivers/video/fbdev/arkfb.c
===================================================================
--- a/drivers/video/fbdev/arkfb.c
+++ b/drivers/video/fbdev/arkfb.c
@@ -954,10 +954,8 @@ static int ark_pci_probe(struct pci_dev
/* Allocate and fill driver data structure */
info = framebuffer_alloc(sizeof(struct arkfb_info), &(dev->dev));
- if (! info) {
- dev_err(&(dev->dev), "cannot allocate memory\n");
+ if (!info)
return -ENOMEM;
- }
par = info->par;
mutex_init(&par->open_lock);
Index: b/drivers/video/fbdev/atmel_lcdfb.c
===================================================================
--- a/drivers/video/fbdev/atmel_lcdfb.c
+++ b/drivers/video/fbdev/atmel_lcdfb.c
@@ -1053,10 +1053,8 @@ static int __init atmel_lcdfb_probe(stru
ret = -ENOMEM;
info = framebuffer_alloc(sizeof(struct atmel_lcdfb_info), dev);
- if (!info) {
- dev_err(dev, "cannot allocate memory\n");
+ if (!info)
goto out;
- }
sinfo = info->par;
sinfo->pdev = pdev;
Index: b/drivers/video/fbdev/aty/aty128fb.c
===================================================================
--- a/drivers/video/fbdev/aty/aty128fb.c
+++ b/drivers/video/fbdev/aty/aty128fb.c
@@ -2102,10 +2102,9 @@ static int aty128_probe(struct pci_dev *
/* We have the resources. Now virtualize them */
info = framebuffer_alloc(sizeof(struct aty128fb_par), &pdev->dev);
- if (info == NULL) {
- printk(KERN_ERR "aty128fb: can't alloc fb_info_aty128\n");
+ if (!info)
goto err_free_mmio;
- }
+
par = info->par;
info->pseudo_palette = par->pseudo_palette;
Index: b/drivers/video/fbdev/aty/atyfb_base.c
===================================================================
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -3550,10 +3550,9 @@ static int atyfb_pci_probe(struct pci_de
/* Allocate framebuffer */
info = framebuffer_alloc(sizeof(struct atyfb_par), &pdev->dev);
- if (!info) {
- PRINTKE("atyfb_pci_probe() can't alloc fb_info\n");
+ if (!info)
return -ENOMEM;
- }
+
par = info->par;
par->bus_type = PCI;
info->fix = atyfb_fix;
@@ -3643,10 +3642,9 @@ static int __init atyfb_atari_probe(void
}
info = framebuffer_alloc(sizeof(struct atyfb_par), NULL);
- if (!info) {
- PRINTKE("atyfb_atari_probe() can't alloc fb_info\n");
+ if (!info)
return -ENOMEM;
- }
+
par = info->par;
info->fix = atyfb_fix;
Index: b/drivers/video/fbdev/aty/radeon_base.c
===================================================================
--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -2294,8 +2294,6 @@ static int radeonfb_pci_register(struct
info = framebuffer_alloc(sizeof(struct radeonfb_info), &pdev->dev);
if (!info) {
- printk (KERN_ERR "radeonfb (%s): could not allocate memory\n",
- pci_name(pdev));
ret = -ENOMEM;
goto err_disable;
}
Index: b/drivers/video/fbdev/chipsfb.c
===================================================================
--- a/drivers/video/fbdev/chipsfb.c
+++ b/drivers/video/fbdev/chipsfb.c
@@ -366,7 +366,6 @@ static int chipsfb_pci_init(struct pci_d
p = framebuffer_alloc(0, &dp->dev);
if (p == NULL) {
- dev_err(&dp->dev, "Cannot allocate framebuffer structure\n");
rc = -ENOMEM;
goto err_disable;
}
Index: b/drivers/video/fbdev/cirrusfb.c
===================================================================
--- a/drivers/video/fbdev/cirrusfb.c
+++ b/drivers/video/fbdev/cirrusfb.c
@@ -2093,7 +2093,6 @@ static int cirrusfb_pci_register(struct
info = framebuffer_alloc(sizeof(struct cirrusfb_info), &pdev->dev);
if (!info) {
- printk(KERN_ERR "cirrusfb: could not allocate memory\n");
ret = -ENOMEM;
goto err_out;
}
@@ -2206,10 +2205,8 @@ static int cirrusfb_zorro_register(struc
struct cirrusfb_info *cinfo;
info = framebuffer_alloc(sizeof(struct cirrusfb_info), &z->dev);
- if (!info) {
- printk(KERN_ERR "cirrusfb: could not allocate memory\n");
+ if (!info)
return -ENOMEM;
- }
zcl = (const struct zorrocl *)ent->driver_data;
btype = zcl->type;
Index: b/drivers/video/fbdev/da8xx-fb.c
===================================================================
--- a/drivers/video/fbdev/da8xx-fb.c
+++ b/drivers/video/fbdev/da8xx-fb.c
@@ -1400,7 +1400,6 @@ static int fb_probe(struct platform_devi
da8xx_fb_info = framebuffer_alloc(sizeof(struct da8xx_fb_par),
&device->dev);
if (!da8xx_fb_info) {
- dev_dbg(&device->dev, "Memory allocation failed for fb_info\n");
ret = -ENOMEM;
goto err_pm_runtime_disable;
}
Index: b/drivers/video/fbdev/efifb.c
===================================================================
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -448,7 +448,6 @@ static int efifb_probe(struct platform_d
info = framebuffer_alloc(sizeof(u32) * 16, &dev->dev);
if (!info) {
- pr_err("efifb: cannot allocate framebuffer\n");
err = -ENOMEM;
goto err_release_mem;
}
Index: b/drivers/video/fbdev/grvga.c
===================================================================
--- a/drivers/video/fbdev/grvga.c
+++ b/drivers/video/fbdev/grvga.c
@@ -341,10 +341,8 @@ static int grvga_probe(struct platform_d
char *options = NULL, *mode_opt = NULL;
info = framebuffer_alloc(sizeof(struct grvga_par), &dev->dev);
- if (!info) {
- dev_err(&dev->dev, "framebuffer_alloc failed\n");
+ if (!info)
return -ENOMEM;
- }
/* Expecting: "grvga: modestring, [addr:<framebuffer physical address>], [size:<framebuffer size>]
*
Index: b/drivers/video/fbdev/gxt4500.c
===================================================================
--- a/drivers/video/fbdev/gxt4500.c
+++ b/drivers/video/fbdev/gxt4500.c
@@ -642,10 +642,9 @@ static int gxt4500_probe(struct pci_dev
}
info = framebuffer_alloc(sizeof(struct gxt4500_par), &pdev->dev);
- if (!info) {
- dev_err(&pdev->dev, "gxt4500: cannot alloc FB info record\n");
+ if (!info)
goto err_free_fb;
- }
+
par = info->par;
cardtype = ent->driver_data;
par->refclk_ps = cardinfo[cardtype].refclk_ps;
Index: b/drivers/video/fbdev/hyperv_fb.c
===================================================================
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -771,10 +771,8 @@ static int hvfb_probe(struct hv_device *
int ret;
info = framebuffer_alloc(sizeof(struct hvfb_par), &hdev->device);
- if (!info) {
- pr_err("No memory for framebuffer info\n");
+ if (!info)
return -ENOMEM;
- }
par = info->par;
par->info = info;
Index: b/drivers/video/fbdev/i740fb.c
===================================================================
--- a/drivers/video/fbdev/i740fb.c
+++ b/drivers/video/fbdev/i740fb.c
@@ -1005,10 +1005,8 @@ static int i740fb_probe(struct pci_dev *
u8 *edid;
info = framebuffer_alloc(sizeof(struct i740fb_par), &(dev->dev));
- if (!info) {
- dev_err(&(dev->dev), "cannot allocate framebuffer\n");
+ if (!info)
return -ENOMEM;
- }
par = info->par;
mutex_init(&par->open_lock);
Index: b/drivers/video/fbdev/imsttfb.c
===================================================================
--- a/drivers/video/fbdev/imsttfb.c
+++ b/drivers/video/fbdev/imsttfb.c
@@ -1477,11 +1477,8 @@ static int imsttfb_probe(struct pci_dev
printk(KERN_ERR "imsttfb: no OF node for pci device\n");
info = framebuffer_alloc(sizeof(struct imstt_par), &pdev->dev);
-
- if (!info) {
- printk(KERN_ERR "imsttfb: Can't allocate memory\n");
+ if (!info)
return -ENOMEM;
- }
par = info->par;
Index: b/drivers/video/fbdev/intelfb/intelfbdrv.c
===================================================================
--- a/drivers/video/fbdev/intelfb/intelfbdrv.c
+++ b/drivers/video/fbdev/intelfb/intelfbdrv.c
@@ -491,10 +491,9 @@ static int intelfb_pci_register(struct p
}
info = framebuffer_alloc(sizeof(struct intelfb_info), &pdev->dev);
- if (!info) {
- ERR_MSG("Could not allocate memory for intelfb_info.\n");
+ if (!info)
return -ENOMEM;
- }
+
if (fb_alloc_cmap(&info->cmap, 256, 1) < 0) {
ERR_MSG("Could not allocate cmap for intelfb_info.\n");
goto err_out_cmap;
Index: b/drivers/video/fbdev/jz4740_fb.c
===================================================================
--- a/drivers/video/fbdev/jz4740_fb.c
+++ b/drivers/video/fbdev/jz4740_fb.c
@@ -544,10 +544,8 @@ static int jzfb_probe(struct platform_de
}
fb = framebuffer_alloc(sizeof(struct jzfb), &pdev->dev);
- if (!fb) {
- dev_err(&pdev->dev, "Failed to allocate framebuffer device\n");
+ if (!fb)
return -ENOMEM;
- }
fb->fbops = &jzfb_ops;
fb->flags = FBINFO_DEFAULT;
Index: b/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c
===================================================================
--- a/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c
+++ b/drivers/video/fbdev/mb862xx/mb862xxfbdrv.c
@@ -684,10 +684,8 @@ static int of_platform_mb862xx_probe(str
}
info = framebuffer_alloc(sizeof(struct mb862xxfb_par), dev);
- if (info == NULL) {
- dev_err(dev, "cannot allocate framebuffer\n");
+ if (!info)
return -ENOMEM;
- }
par = info->par;
par->info = info;
@@ -1009,7 +1007,6 @@ static int mb862xx_pci_probe(struct pci_
info = framebuffer_alloc(sizeof(struct mb862xxfb_par), dev);
if (!info) {
- dev_err(dev, "framebuffer alloc failed\n");
ret = -ENOMEM;
goto dis_dev;
}
Index: b/drivers/video/fbdev/mbx/mbxfb.c
===================================================================
--- a/drivers/video/fbdev/mbx/mbxfb.c
+++ b/drivers/video/fbdev/mbx/mbxfb.c
@@ -899,10 +899,8 @@ static int mbxfb_probe(struct platform_d
}
fbi = framebuffer_alloc(sizeof(struct mbxfb_info), &dev->dev);
- if (fbi == NULL) {
- dev_err(&dev->dev, "framebuffer_alloc failed\n");
+ if (!fbi)
return -ENOMEM;
- }
mfbi = fbi->par;
fbi->pseudo_palette = mfbi->pseudo_palette;
Index: b/drivers/video/fbdev/omap/omapfb_main.c
===================================================================
--- a/drivers/video/fbdev/omap/omapfb_main.c
+++ b/drivers/video/fbdev/omap/omapfb_main.c
@@ -1515,8 +1515,6 @@ static int planes_init(struct omapfb_dev
fbi = framebuffer_alloc(sizeof(struct omapfb_plane_struct),
fbdev->dev);
if (fbi == NULL) {
- dev_err(fbdev->dev,
- "unable to allocate memory for plane info\n");
planes_cleanup(fbdev);
return -ENOMEM;
}
Index: b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
===================================================================
--- a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
@@ -1892,12 +1892,8 @@ static int omapfb_create_framebuffers(st
fbi = framebuffer_alloc(sizeof(struct omapfb_info),
fbdev->dev);
-
- if (fbi == NULL) {
- dev_err(fbdev->dev,
- "unable to allocate memory for plane info\n");
+ if (!fbi)
return -ENOMEM;
- }
clear_fb_info(fbi);
Index: b/drivers/video/fbdev/platinumfb.c
===================================================================
--- a/drivers/video/fbdev/platinumfb.c
+++ b/drivers/video/fbdev/platinumfb.c
@@ -538,10 +538,9 @@ static int platinumfb_probe(struct platf
dev_info(&odev->dev, "Found Apple Platinum video hardware\n");
info = framebuffer_alloc(sizeof(*pinfo), &odev->dev);
- if (info == NULL) {
- dev_err(&odev->dev, "Failed to allocate fbdev !\n");
+ if (!info)
return -ENOMEM;
- }
+
pinfo = info->par;
if (of_address_to_resource(dp, 0, &pinfo->rsrc_reg) ||
Index: b/drivers/video/fbdev/pmag-aa-fb.c
===================================================================
--- a/drivers/video/fbdev/pmag-aa-fb.c
+++ b/drivers/video/fbdev/pmag-aa-fb.c
@@ -165,10 +165,8 @@ static int pmagaafb_probe(struct device
int err;
info = framebuffer_alloc(sizeof(struct aafb_par), dev);
- if (!info) {
- printk(KERN_ERR "%s: Cannot allocate memory\n", dev_name(dev));
+ if (!info)
return -ENOMEM;
- }
par = info->par;
dev_set_drvdata(dev, info);
Index: b/drivers/video/fbdev/pmag-ba-fb.c
===================================================================
--- a/drivers/video/fbdev/pmag-ba-fb.c
+++ b/drivers/video/fbdev/pmag-ba-fb.c
@@ -150,10 +150,8 @@ static int pmagbafb_probe(struct device
int err;
info = framebuffer_alloc(sizeof(struct pmagbafb_par), dev);
- if (!info) {
- printk(KERN_ERR "%s: Cannot allocate memory\n", dev_name(dev));
+ if (!info)
return -ENOMEM;
- }
par = info->par;
dev_set_drvdata(dev, info);
Index: b/drivers/video/fbdev/pmagb-b-fb.c
===================================================================
--- a/drivers/video/fbdev/pmagb-b-fb.c
+++ b/drivers/video/fbdev/pmagb-b-fb.c
@@ -257,10 +257,8 @@ static int pmagbbfb_probe(struct device
int err;
info = framebuffer_alloc(sizeof(struct pmagbbfb_par), dev);
- if (!info) {
- printk(KERN_ERR "%s: Cannot allocate memory\n", dev_name(dev));
+ if (!info)
return -ENOMEM;
- }
par = info->par;
dev_set_drvdata(dev, info);
Index: b/drivers/video/fbdev/pvr2fb.c
===================================================================
--- a/drivers/video/fbdev/pvr2fb.c
+++ b/drivers/video/fbdev/pvr2fb.c
@@ -1069,12 +1069,8 @@ static int __init pvr2fb_init(void)
#endif
fb_info = framebuffer_alloc(sizeof(struct pvr2fb_par), NULL);
-
- if (!fb_info) {
- printk(KERN_ERR "Failed to allocate memory for fb_info\n");
+ if (!fb_info)
return -ENOMEM;
- }
-
currentpar = fb_info->par;
Index: b/drivers/video/fbdev/riva/fbdev.c
===================================================================
--- a/drivers/video/fbdev/riva/fbdev.c
+++ b/drivers/video/fbdev/riva/fbdev.c
@@ -1902,7 +1902,6 @@ static int rivafb_probe(struct pci_dev *
info = framebuffer_alloc(sizeof(struct riva_par), &pd->dev);
if (!info) {
- printk (KERN_ERR PFX "could not allocate memory\n");
ret = -ENOMEM;
goto err_ret;
}
Index: b/drivers/video/fbdev/s3c-fb.c
===================================================================
--- a/drivers/video/fbdev/s3c-fb.c
+++ b/drivers/video/fbdev/s3c-fb.c
@@ -1189,10 +1189,8 @@ static int s3c_fb_probe_win(struct s3c_f
fbinfo = framebuffer_alloc(sizeof(struct s3c_fb_win) +
palette_size * sizeof(u32), sfb->dev);
- if (!fbinfo) {
- dev_err(sfb->dev, "failed to allocate framebuffer\n");
+ if (!fbinfo)
return -ENOMEM;
- }
windata = sfb->pdata->win[win_no];
initmode = *sfb->pdata->vtiming;
Index: b/drivers/video/fbdev/s3fb.c
===================================================================
--- a/drivers/video/fbdev/s3fb.c
+++ b/drivers/video/fbdev/s3fb.c
@@ -1128,10 +1128,8 @@ static int s3_pci_probe(struct pci_dev *
/* Allocate and fill driver data structure */
info = framebuffer_alloc(sizeof(struct s3fb_info), &(dev->dev));
- if (!info) {
- dev_err(&(dev->dev), "cannot allocate memory\n");
+ if (!info)
return -ENOMEM;
- }
par = info->par;
mutex_init(&par->open_lock);
Index: b/drivers/video/fbdev/sh_mobile_lcdcfb.c
===================================================================
--- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
+++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
@@ -1644,10 +1644,8 @@ sh_mobile_lcdc_overlay_fb_init(struct sh
/* Allocate and initialize the frame buffer device. */
info = framebuffer_alloc(0, priv->dev);
- if (info == NULL) {
- dev_err(priv->dev, "unable to allocate fb_info\n");
+ if (!info)
return -ENOMEM;
- }
ovl->info = info;
@@ -2138,10 +2136,8 @@ sh_mobile_lcdc_channel_fb_init(struct sh
* list and allocate the color map.
*/
info = framebuffer_alloc(0, priv->dev);
- if (info == NULL) {
- dev_err(priv->dev, "unable to allocate fb_info\n");
+ if (!info)
return -ENOMEM;
- }
ch->info = info;
Index: b/drivers/video/fbdev/sm501fb.c
===================================================================
--- a/drivers/video/fbdev/sm501fb.c
+++ b/drivers/video/fbdev/sm501fb.c
@@ -1868,10 +1868,8 @@ static int sm501fb_probe_one(struct sm50
}
fbi = framebuffer_alloc(sizeof(struct sm501fb_par), info->dev);
- if (fbi == NULL) {
- dev_err(info->dev, "cannot allocate %s framebuffer\n", name);
+ if (!fbi)
return -ENOMEM;
- }
par = fbi->par;
par->info = info;
Index: b/drivers/video/fbdev/sm712fb.c
===================================================================
--- a/drivers/video/fbdev/sm712fb.c
+++ b/drivers/video/fbdev/sm712fb.c
@@ -1538,7 +1538,6 @@ static int smtcfb_pci_probe(struct pci_d
info = framebuffer_alloc(sizeof(*sfb), &pdev->dev);
if (!info) {
- dev_err(&pdev->dev, "framebuffer_alloc failed\n");
err = -ENOMEM;
goto failed_free;
}
Index: b/drivers/video/fbdev/smscufx.c
===================================================================
--- a/drivers/video/fbdev/smscufx.c
+++ b/drivers/video/fbdev/smscufx.c
@@ -1653,10 +1653,8 @@ static int ufx_usb_probe(struct usb_inte
/* allocates framebuffer driver structure, not framebuffer memory */
info = framebuffer_alloc(0, &usbdev->dev);
- if (!info) {
- dev_err(dev->gdev, "framebuffer_alloc failed\n");
+ if (!info)
goto e_nomem;
- }
dev->info = info;
info->par = dev;
Index: b/drivers/video/fbdev/ssd1307fb.c
===================================================================
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -556,10 +556,8 @@ static int ssd1307fb_probe(struct i2c_cl
}
info = framebuffer_alloc(sizeof(struct ssd1307fb_par), &client->dev);
- if (!info) {
- dev_err(&client->dev, "Couldn't allocate framebuffer.\n");
+ if (!info)
return -ENOMEM;
- }
par = info->par;
par->info = info;
Index: b/drivers/video/fbdev/sunxvr1000.c
===================================================================
--- a/drivers/video/fbdev/sunxvr1000.c
+++ b/drivers/video/fbdev/sunxvr1000.c
@@ -121,7 +121,6 @@ static int gfb_probe(struct platform_dev
info = framebuffer_alloc(sizeof(struct gfb_info), &op->dev);
if (!info) {
- printk(KERN_ERR "gfb: Cannot allocate fb_info\n");
err = -ENOMEM;
goto err_out;
}
Index: b/drivers/video/fbdev/sunxvr2500.c
===================================================================
--- a/drivers/video/fbdev/sunxvr2500.c
+++ b/drivers/video/fbdev/sunxvr2500.c
@@ -132,7 +132,6 @@ static int s3d_pci_register(struct pci_d
info = framebuffer_alloc(sizeof(struct s3d_info), &pdev->dev);
if (!info) {
- printk(KERN_ERR "s3d: Cannot allocate fb_info\n");
err = -ENOMEM;
goto err_disable;
}
Index: b/drivers/video/fbdev/sunxvr500.c
===================================================================
--- a/drivers/video/fbdev/sunxvr500.c
+++ b/drivers/video/fbdev/sunxvr500.c
@@ -272,7 +272,6 @@ static int e3d_pci_register(struct pci_d
info = framebuffer_alloc(sizeof(struct e3d_info), &pdev->dev);
if (!info) {
- printk(KERN_ERR "e3d: Cannot allocate fb_info\n");
err = -ENOMEM;
goto err_disable;
}
Index: b/drivers/video/fbdev/tgafb.c
===================================================================
--- a/drivers/video/fbdev/tgafb.c
+++ b/drivers/video/fbdev/tgafb.c
@@ -1416,10 +1416,8 @@ static int tgafb_register(struct device
/* Allocate the fb and par structures. */
info = framebuffer_alloc(sizeof(struct tga_par), dev);
- if (!info) {
- printk(KERN_ERR "tgafb: Cannot allocate memory\n");
+ if (!info)
return -ENOMEM;
- }
par = info->par;
dev_set_drvdata(dev, info);
Index: b/drivers/video/fbdev/udlfb.c
===================================================================
--- a/drivers/video/fbdev/udlfb.c
+++ b/drivers/video/fbdev/udlfb.c
@@ -1689,10 +1689,8 @@ static int dlfb_usb_probe(struct usb_int
/* allocates framebuffer driver structure, not framebuffer memory */
info = framebuffer_alloc(0, &dlfb->udev->dev);
- if (!info) {
- dev_err(&dlfb->udev->dev, "framebuffer_alloc failed\n");
+ if (!info)
goto error;
- }
dlfb->info = info;
info->par = dlfb;
Index: b/drivers/video/fbdev/via/viafbdev.c
===================================================================
--- a/drivers/video/fbdev/via/viafbdev.c
+++ b/drivers/video/fbdev/via/viafbdev.c
@@ -1756,10 +1756,8 @@ int via_fb_pci_probe(struct viafb_dev *v
viafbinfo = framebuffer_alloc(viafb_par_length +
ALIGN(sizeof(struct viafb_shared), BITS_PER_LONG/8),
&vdev->pdev->dev);
- if (!viafbinfo) {
- printk(KERN_ERR"Could not allocate memory for viafb_info.\n");
+ if (!viafbinfo)
return -ENOMEM;
- }
viaparinfo = (struct viafb_par *)viafbinfo->par;
viaparinfo->shared = viafbinfo->par + viafb_par_length;
@@ -1834,8 +1832,6 @@ int via_fb_pci_probe(struct viafb_dev *v
viafbinfo1 = framebuffer_alloc(viafb_par_length,
&vdev->pdev->dev);
if (!viafbinfo1) {
- printk(KERN_ERR
- "allocate the second framebuffer struct error\n");
rc = -ENOMEM;
goto out_fb_release;
}
Index: b/drivers/video/fbdev/vt8623fb.c
===================================================================
--- a/drivers/video/fbdev/vt8623fb.c
+++ b/drivers/video/fbdev/vt8623fb.c
@@ -669,10 +669,8 @@ static int vt8623_pci_probe(struct pci_d
/* Allocate and fill driver data structure */
info = framebuffer_alloc(sizeof(struct vt8623fb_info), &(dev->dev));
- if (! info) {
- dev_err(&(dev->dev), "cannot allocate memory\n");
+ if (!info)
return -ENOMEM;
- }
par = info->par;
mutex_init(&par->open_lock);
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2] HID: input: fix a4tech horizontal wheel custom usage
From: Nicolas Saenz Julienne @ 2019-06-14 14:25 UTC (permalink / raw)
To: Benjamin Tissoires, wbauer1
Cc: Jiri Kosina, Dmitry Torokhov, open list:HID CORE LAYER, lkml
In-Reply-To: <CAO-hwJ+Nm+i+ehGurAxD3EQBX8-TFQ7p4J-1rV55fVA=NazgAw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5224 bytes --]
On Fri, 2019-06-14 at 15:36 +0200, Benjamin Tissoires wrote:
> Hi Wolfgang,
>
> On Thu, Jun 13, 2019 at 1:49 PM Wolfgang Bauer <wbauer@tmo.at> wrote:
> > On Tuesday, 11. Juni 2019, 16:42:37 Benjamin Tissoires wrote:
> > > On Tue, Jun 11, 2019 at 2:13 PM Nicolas Saenz Julienne
> > >
> > > <nsaenzjulienne@suse.de> wrote:
> > > > 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.
> >
> > My name is Wolfgang, not Wolfram... ;-)
>
> ouch, sorry for that (I am more used to talk to the I2C maintainer apparently)
>
> > But never mind.
> >
> > I tested the patch meanwhile on top of kernel 5.2.rc4, where the mouse wheel
> > actually worked.
>
> Actually, I am a little bit lost here.
>
> The patch mentions a fix of c01908a14bf73, which is in 5.1 final.
> So if your mouse works in 5.2.rc4, I am not sure how
> HID-a4tech-fix-horizontal-scrolling.patch could break it.
>
> Could you be slightly more specific in what "works" and what doesn't?
Hi Benjamin,
First of all here's the descriptor:
0x05, 0x01, /* Usage Page (Desktop), */
0x09, 0x02, /* Usage (Mouse), */
0xA1, 0x01, /* Collection (Application), */
0x09, 0x01, /* Usage (Pointer), */
0xA1, 0x00, /* Collection (Physical), */
0x05, 0x09, /* Usage Page (Button), */
0x19, 0x01, /* Usage Minimum (01h), */
0x29, 0x08, /* Usage Maximum (08h), */
0x15, 0x00, /* Logical Minimum (0), */
0x25, 0x01, /* Logical Maximum (1), */
0x75, 0x01, /* Report Size (1), */
0x95, 0x08, /* Report Count (8), */
0x81, 0x02, /* Input (Variable), */
0x05, 0x01, /* Usage Page (Desktop), */
0x09, 0x30, /* Usage (X), */
0x09, 0x31, /* Usage (Y), */
0x09, 0x38, /* Usage (Wheel), */
0x09, 0xB8, /* Usage (B8h), */
0x15, 0x81, /* Logical Minimum (-127), */
0x25, 0x7F, /* Logical Maximum (127), */
0x75, 0x08, /* Report Size (8), */
0x95, 0x04, /* Report Count (4), */
0x81, 0x06, /* Input (Variable, Relative), */
0xC0, /* End Collection, */
0xC0 /* End Collection
Sorry for the confusion, I'll try to explain the situation:
In v5.2-rc4 without "HID-a4tech-fix-horizontal-scrolling.patch" the vertical
wheel works out of luck as it's mapped to REL_WHEEL_HIGH_RES, which hid-a4tech
ignores and lets hid-input process, the horizontal wheel is broken. On top of
that Usage(0xB8) is also ignored by both hid-a4tech and hid-input as it isn't
mapped to anything.
There are two distinct bugs here:
- High resolution wheel processing in hid-a4tech not being implemented,
breaking horizontal wheels.
- hid-a4tech not taking care of Usage(0xB8) correctly as it depended on it
being mapped to "Rel.Misc". That behaviour changed in v5.1 with "HID:
input: add mapping for "Toggle Display" key".
Once high resolution wheel reports are fixed and handled in hid-a4tech's custom
event, the mouse breaks as it's the processing of Usage(0xB8) that triggers the
input_events, which is being ignored.
You'll probably ask how come we didn't see this when
"HID-a4tech-fix-horizontal-scrolling.patch" was merged. It's due to the fact it
was tested on an older kernel, v5.0.15, that didn't contain "HID: input: add
mapping for "Toggle Display" key"[1].
So that's why I added that specific fix tag. For LTS kernels, it is possible
that "Toggle Display" support was back-ported but not the high resolution
wheels support.
Hope it made things more clear.
Regards,
Nicolas
[1]
https://lkml.kernel.org/lkml/nycvar.YFH.7.76.1906010028440.1962@cbobk.fhfr.pm/T/
>
> Do we have the report descriptors available somewhere?
> And if not, could you run hid-recorder from
> https://gitlab.freedesktop.org/libevdev/hid-tools and attach the logs
> when you move the horizontal wheel?
>
> Cheers,
> Benjamin
>
> > As the patch didn't apply cleanly (it's obviously based upon
> >
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=abf82e8f7e9af40a49e3d905187c662a43c96c8f
, called
> > "HID-
> > a4tech-fix-horizontal-scrolling.patch" below), I added that patch as well.
> >
> > My results:
> > kernel 5.2.rc4 works
> > kernel 5.2.rc4 + HID-a4tech-fix-horizontal-scrolling.patch is broken
> > kernel 5.2.rc4 + HID-a4tech-fix-horizontal-scrolling.patch +
> > HID-input-fix-a4tech-horizontal-wheel-custom-usage.patch (i.e. this patch)
> > works again
> >
> > kernel 5.2.rc4 + HID-input-fix-a4tech-horizontal-wheel-custom-usage.patch
> > works as well.
> >
> > So AFAICT this patch seems to be fine.
> >
> > For completeness, this is my mouse as listed by lsusb:
> > Bus 003 Device 002: ID 09da:000a A4Tech Co., Ltd. Optical Mouse Opto 510D /
> > OP-620D
> >
> > Kind Regards,
> > Wolfgang
> >
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v6 3/5] arm64: dts: qcom: Add Lenovo Miix 630
From: Rob Clark @ 2019-06-14 14:08 UTC (permalink / raw)
To: Jeffrey Hugo
Cc: Bjorn Andersson, agross, Benjamin Tissoires, Dmitry Torokhov,
jikos, Hans de Goede, Lee Jones, xnox, Rob Herring, Mark Rutland,
linux-input, devicetree, linux-arm-msm, Linux Kernel Mailing List
In-Reply-To: <CAF6AEGvAkCqNXg-NwxfpYJteWs6hfBnOb0yJN6vQOnmMck-HDQ@mail.gmail.com>
On Fri, Jun 14, 2019 at 6:44 AM Rob Clark <robdclark@gmail.com> wrote:
>
> On Thu, Jun 13, 2019 at 10:17 AM Jeffrey Hugo <jeffrey.l.hugo@gmail.com> wrote:
> >
> > This adds the initial DT for the Lenovo Miix 630 laptop. Supported
> > functionality includes USB (host), microSD-card, keyboard, and trackpad.
> >
> > Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
> > ---
>
> [snip]
>
> > diff --git a/arch/arm64/boot/dts/qcom/msm8998-lenovo-miix-630.dts b/arch/arm64/boot/dts/qcom/msm8998-lenovo-miix-630.dts
> > new file mode 100644
> > index 000000000000..407c6a32911c
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/qcom/msm8998-lenovo-miix-630.dts
> > @@ -0,0 +1,30 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/* Copyright (c) 2019, Jeffrey Hugo. All rights reserved. */
> > +
> > +/dts-v1/;
> > +
> > +#include "msm8998-clamshell.dtsi"
> > +
> > +/ {
> > + model = "Lenovo Miix 630";
> > + compatible = "lenovo,miix-630", "qcom,msm8998";
> > +};
>
>
> So, I'm not sure if there is some precedent for this (but maybe we
> haven't really had this problem before).. but as I mentioned on
> #arch64-laptops, I think we should put vendor/product/board-id strings
> from SMBIOS table in the dts files. That could be used by grub to
> find the correct dtb file to load in a generic way. (Ie, look for a
> match of all three strings, and maybe fallback to a match on just
> vendor+product??)
>
> At any rate, how the strings are used can be refined later. But I
> think we should include the strings from the beginning for anything
> that is booting via UEFI. It's perhaps more useful than the
> compatible string.
>
perhaps something like:
dmi-compatible = "LENOVO 81JL/LNVNB161216", "LENOVO 81JL";
??
(well, those are the strings from my yoga c630, not sure what they are
on the miix 630.. but you get the idea)
BR,
-R
^ permalink raw reply
* Re: [PATCH v6 3/5] arm64: dts: qcom: Add Lenovo Miix 630
From: Rob Clark @ 2019-06-14 13:44 UTC (permalink / raw)
To: Jeffrey Hugo
Cc: Bjorn Andersson, agross, Benjamin Tissoires, Dmitry Torokhov,
jikos, Hans de Goede, Lee Jones, xnox, Rob Herring, Mark Rutland,
linux-input, devicetree, linux-arm-msm, Linux Kernel Mailing List
In-Reply-To: <20190612212748.32246-1-jeffrey.l.hugo@gmail.com>
On Thu, Jun 13, 2019 at 10:17 AM Jeffrey Hugo <jeffrey.l.hugo@gmail.com> wrote:
>
> This adds the initial DT for the Lenovo Miix 630 laptop. Supported
> functionality includes USB (host), microSD-card, keyboard, and trackpad.
>
> Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
> ---
[snip]
> diff --git a/arch/arm64/boot/dts/qcom/msm8998-lenovo-miix-630.dts b/arch/arm64/boot/dts/qcom/msm8998-lenovo-miix-630.dts
> new file mode 100644
> index 000000000000..407c6a32911c
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/msm8998-lenovo-miix-630.dts
> @@ -0,0 +1,30 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright (c) 2019, Jeffrey Hugo. All rights reserved. */
> +
> +/dts-v1/;
> +
> +#include "msm8998-clamshell.dtsi"
> +
> +/ {
> + model = "Lenovo Miix 630";
> + compatible = "lenovo,miix-630", "qcom,msm8998";
> +};
So, I'm not sure if there is some precedent for this (but maybe we
haven't really had this problem before).. but as I mentioned on
#arch64-laptops, I think we should put vendor/product/board-id strings
from SMBIOS table in the dts files. That could be used by grub to
find the correct dtb file to load in a generic way. (Ie, look for a
match of all three strings, and maybe fallback to a match on just
vendor+product??)
At any rate, how the strings are used can be refined later. But I
think we should include the strings from the beginning for anything
that is booting via UEFI. It's perhaps more useful than the
compatible string.
BR,
-R
^ permalink raw reply
* [PATCH v1] Input: rotary-encoder - Add gpio as push button
From: Mylène Josserand @ 2019-06-14 13:36 UTC (permalink / raw)
To: dmitry.torokhov, robh+dt, mark.rutland
Cc: linux-input, devicetree, linux-kernel, mylene.josserand,
thomas.petazzoni
Add the support of a gpio that can be defined as a push button.
Thanks to that, it is possible to emit a keycode in case of a
"push" event, if the rotary supports that.
The keycode to emit is defined using "linux,code" property
(such as in gpio-keys).
Signed-off-by: Mylène Josserand <mylene.josserand@bootlin.com>
---
.../devicetree/bindings/input/rotary-encoder.txt | 5 +++
drivers/input/misc/rotary_encoder.c | 50 ++++++++++++++++++++++
2 files changed, 55 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt b/Documentation/devicetree/bindings/input/rotary-encoder.txt
index a644408b33b8..1cfce5d0b5c4 100644
--- a/Documentation/devicetree/bindings/input/rotary-encoder.txt
+++ b/Documentation/devicetree/bindings/input/rotary-encoder.txt
@@ -22,6 +22,9 @@ Optional properties:
- wakeup-source: Boolean, rotary encoder can wake up the system.
- rotary-encoder,encoding: String, the method used to encode steps.
Supported are "gray" (the default and more common) and "binary".
+- push-gpio: a gpio to be used as a detection of a push from the rotary.
+- linux,code: keycode to emit with the push-gpio of this rotary encoder.
+ Required property in case "push-gpio"'s one is used.
Deprecated properties:
- rotary-encoder,half-period: Makes the driver work on half-period mode.
@@ -47,4 +50,6 @@ Example:
rotary-encoder,steps = <24>;
rotary-encoder,encoding = "binary";
rotary-encoder,rollover;
+ push-gpio = <&gpio 20 0>;
+ linux-code = <28> /* KEY_ENTER */
};
diff --git a/drivers/input/misc/rotary_encoder.c b/drivers/input/misc/rotary_encoder.c
index d748897bf5e9..556995fb7dde 100644
--- a/drivers/input/misc/rotary_encoder.c
+++ b/drivers/input/misc/rotary_encoder.c
@@ -47,8 +47,10 @@ struct rotary_encoder {
unsigned int pos;
struct gpio_descs *gpios;
+ struct gpio_desc *gpio_push;
unsigned int *irq;
+ unsigned int code;
bool armed;
signed char dir; /* 1 - clockwise, -1 - CCW */
@@ -56,6 +58,23 @@ struct rotary_encoder {
unsigned int last_stable;
};
+static irqreturn_t rotary_push_irq(int irq, void *dev_id)
+{
+ struct rotary_encoder *encoder = dev_id;
+ int val;
+
+ mutex_lock(&encoder->access_mutex);
+
+ val = gpiod_get_value_cansleep(encoder->gpio_push);
+
+ input_report_key(encoder->input, encoder->code, val);
+ input_sync(encoder->input);
+
+ mutex_unlock(&encoder->access_mutex);
+
+ return IRQ_HANDLED;
+}
+
static unsigned int rotary_encoder_get_state(struct rotary_encoder *encoder)
{
int i;
@@ -190,6 +209,7 @@ static int rotary_encoder_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct rotary_encoder *encoder;
struct input_dev *input;
+ unsigned int irq_push;
irq_handler_t handler;
u32 steps_per_period;
unsigned int i;
@@ -250,6 +270,20 @@ static int rotary_encoder_probe(struct platform_device *pdev)
return -EINVAL;
}
+ encoder->gpio_push = devm_gpiod_get_optional(dev, "push", GPIOD_IN);
+ if (IS_ERR(encoder->gpio_push)) {
+ dev_err(dev, "unable to get gpio-push\n");
+ return PTR_ERR(encoder->gpio_push);
+ }
+
+ if (encoder->gpio_push) {
+ if (device_property_read_u32(dev, "linux,code",
+ &encoder->code)) {
+ dev_err(dev, "gpio-push without keycode\n");
+ return -EINVAL;
+ }
+ }
+
input = devm_input_allocate_device(dev);
if (!input)
return -ENOMEM;
@@ -306,6 +340,22 @@ static int rotary_encoder_probe(struct platform_device *pdev)
}
}
+ if (encoder->gpio_push) {
+ input_set_capability(encoder->input, EV_KEY, encoder->code);
+
+ irq_push = gpiod_to_irq(encoder->gpio_push);
+ err = devm_request_threaded_irq(dev, irq_push,
+ NULL, rotary_push_irq,
+ IRQF_TRIGGER_RISING |
+ IRQF_TRIGGER_FALLING |
+ IRQF_ONESHOT,
+ DRV_NAME, encoder);
+ if (err) {
+ dev_err(dev, "unable to request IRQ %d\n", irq_push);
+ return err;
+ }
+ }
+
err = input_register_device(input);
if (err) {
dev_err(dev, "failed to register input device\n");
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v2] HID: input: fix a4tech horizontal wheel custom usage
From: Benjamin Tissoires @ 2019-06-14 13:36 UTC (permalink / raw)
To: wbauer1
Cc: Nicolas Saenz Julienne, Jiri Kosina, Dmitry Torokhov,
open list:HID CORE LAYER, lkml
In-Reply-To: <5346893.KeHrH3GHoD@linux-lf90.site>
Hi Wolfgang,
On Thu, Jun 13, 2019 at 1:49 PM Wolfgang Bauer <wbauer@tmo.at> wrote:
>
> On Tuesday, 11. Juni 2019, 16:42:37 Benjamin Tissoires wrote:
> > On Tue, Jun 11, 2019 at 2:13 PM Nicolas Saenz Julienne
> >
> > <nsaenzjulienne@suse.de> wrote:
> > > 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.
>
> My name is Wolfgang, not Wolfram... ;-)
ouch, sorry for that (I am more used to talk to the I2C maintainer apparently)
> But never mind.
>
> I tested the patch meanwhile on top of kernel 5.2.rc4, where the mouse wheel
> actually worked.
Actually, I am a little bit lost here.
The patch mentions a fix of c01908a14bf73, which is in 5.1 final.
So if your mouse works in 5.2.rc4, I am not sure how
HID-a4tech-fix-horizontal-scrolling.patch could break it.
Could you be slightly more specific in what "works" and what doesn't?
Do we have the report descriptors available somewhere?
And if not, could you run hid-recorder from
https://gitlab.freedesktop.org/libevdev/hid-tools and attach the logs
when you move the horizontal wheel?
Cheers,
Benjamin
> As the patch didn't apply cleanly (it's obviously based upon
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=abf82e8f7e9af40a49e3d905187c662a43c96c8f , called "HID-
> a4tech-fix-horizontal-scrolling.patch" below), I added that patch as well.
>
> My results:
> kernel 5.2.rc4 works
> kernel 5.2.rc4 + HID-a4tech-fix-horizontal-scrolling.patch is broken
> kernel 5.2.rc4 + HID-a4tech-fix-horizontal-scrolling.patch +
> HID-input-fix-a4tech-horizontal-wheel-custom-usage.patch (i.e. this patch)
> works again
>
> kernel 5.2.rc4 + HID-input-fix-a4tech-horizontal-wheel-custom-usage.patch
> works as well.
>
> So AFAICT this patch seems to be fine.
>
> For completeness, this is my mouse as listed by lsusb:
> Bus 003 Device 002: ID 09da:000a A4Tech Co., Ltd. Optical Mouse Opto 510D /
> OP-620D
>
> Kind Regards,
> Wolfgang
>
^ permalink raw reply
* Re: Regression post "HID: core: move Usage Page concatenation to Main item"
From: Benjamin Tissoires @ 2019-06-14 13:32 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: Jean-Baptiste Théou, Jiri Kosina, open list:HID CORE LAYER,
lkml
In-Reply-To: <65865f56882af2baf8389458c5e6f05096f36818.camel@suse.de>
On Fri, Jun 14, 2019 at 2:29 PM Nicolas Saenz Julienne
<nsaenzjulienne@suse.de> wrote:
>
> On Fri, 2019-06-14 at 10:52 +0200, Nicolas Saenz Julienne wrote:
> > On Fri, 2019-06-14 at 09:02 +0900, Jean-Baptiste Théou wrote:
> > > Sorry - Please find the public link:
> > >
> > >
> >
> https://android.googlesource.com/platform/cts/+/master/tests/tests/hardware/res/raw/asus_gamepad_register.json
> > > Best regards
> > >
> > > On Fri, Jun 14, 2019 at 9:01 AM Jean-Baptiste Théou <jb@essential.com>
> > > wrote:
> > > > Hi,
> > > >
> > > > This patch (58e75155009cc800005629955d3482f36a1e0eec) is triggering a
> > > > regression with the following descriptor (report not working as
> > > > expected)
> > > >
> > > >
> >
> https://partner-android.googlesource.com/platform/cts/+/refs/heads/q-fs-release/tests/tests/hardware/res/raw/asus_gamepad_register.json
> > > > Didn't see anything obviously wrong with this gamepad descriptor, so
> > > > not sure what's trigger the regression.
> > > >
> > > > Thanks a lot
> > > >
> > > > Best regards
> >
> > Added Benjamin to the mail thread.
> >
> > For the record here's the report descritor, I have the feeling the issue is
> > related to the Usage Page being defined in the middle of the Usage
> > ennumeration.
> >
> > 0x05, 0x01, /* Usage Page (Desktop), */
> > 0x09, 0x05, /* Usage (Gamepad), */
> > 0xA1, 0x01, /* Collection (Application), */
> > 0x85, 0x01, /* Report ID (1), */
> > 0x05, 0x09, /* Usage Page (Button), */
> > 0x0A, 0x01, 0x00, /* Usage (01h), */
> > 0x0A, 0x02, 0x00, /* Usage (02h), */
> > 0x0A, 0x04, 0x00, /* Usage (04h), */
> > 0x0A, 0x05, 0x00, /* Usage (05h), */
> > 0x0A, 0x07, 0x00, /* Usage (07h), */
> > 0x0A, 0x08, 0x00, /* Usage (08h), */
> > 0x0A, 0x0E, 0x00, /* Usage (0Eh), */
> > 0x0A, 0x0F, 0x00, /* Usage (0Fh), */
> > 0x0A, 0x0D, 0x00, /* Usage (0Dh), */
> > 0x05, 0x0C, /* Usage Page (Consumer), */
> > 0x0A, 0x24, 0x02, /* Usage (AC Back), */
> > 0x0A, 0x23, 0x02, /* Usage (AC Home), */
> > 0x15, 0x00, /* Logical Minimum (0), */
> > 0x25, 0x01, /* Logical Maximum (1), */
> > 0x75, 0x01, /* Report Size (1), */
> > 0x95, 0x0B, /* Report Count (11), */
> > 0x81, 0x02, /* Input (Variable), */
> > 0x75, 0x01, /* Report Size (1), */
> > 0x95, 0x01, /* Report Count (1), */
> > 0x81, 0x03, /* Input (Constant, Variable), */
> > 0x05, 0x01, /* Usage Page (Desktop), */
> > 0x75, 0x04, /* Report Size (4), */
> > 0x95, 0x01, /* Report Count (1), */
> > 0x25, 0x07, /* Logical Maximum (7), */
> > 0x46, 0x3B, 0x01, /* Physical Maximum (315), */
> > 0x66, 0x14, 0x00, /* Unit (Degrees), */
> > 0x09, 0x39, /* Usage (Hat Switch), */
> > 0x81, 0x42, /* Input (Variable, Null State), */
> > 0x66, 0x00, 0x00, /* Unit, */
> > 0x09, 0x01, /* Usage (Pointer), */
> > 0xA1, 0x00, /* Collection (Physical), */
> > 0x09, 0x30, /* Usage (X), */
> > 0x09, 0x31, /* Usage (Y), */
> > 0x09, 0x32, /* Usage (Z), */
> > 0x09, 0x35, /* Usage (Rz), */
> > 0x05, 0x02, /* Usage Page (Simulation), */
> > 0x09, 0xC5, /* Usage (C5h), */
> > 0x09, 0xC4, /* Usage (C4h), */
> > 0x15, 0x00, /* Logical Minimum (0), */
> > 0x26, 0xFF, 0x00, /* Logical Maximum (255), */
> > 0x35, 0x00, /* Physical Minimum (0), */
> > 0x46, 0xFF, 0x00, /* Physical Maximum (255), */
> > 0x75, 0x08, /* Report Size (8), */
> > 0x95, 0x06, /* Report Count (6), */
> > 0x81, 0x02, /* Input (Variable), */
>
> Well as it was stated in 57e75155009 ("HID: core: move Usage Page concatenation
> to Main item"):
>
> The spec is not pretty clear as 5.2.2.7 states "Any usage that follows
> is interpreted as a Usage ID and concatenated with the Usage Page".
> While 5.2.2.8 states "When the parser encounters a main item it
> concatenates the last declared Usage Page with a Usage to form a
> complete usage value." Being somewhat contradictory it was decided to
> match Window's implementation, which follows 5.2.2.8.
>
> This breaks the Report above as X, Y, Z and Rz will be concatenanted with the
> 'Simulation' Usage Page as opposed to the 'Desktop' one.
>
> Based on the USB IDs can't find much information on this Gamepad, is it a real
> one? If so I guess the solution would be to fix the report descriptor in a
> custom driver. Otherwise I'd suggest fixing the descriptors directly on the
> test suite.
And most of all, how does the joypad behave on Windows?
If no quirks is used in Windows, then maybe wee are not doing the
right thing, but AFAICT, the patch was added to mimic Windows :/
Cheers,
Benjamin
>
> Regards,
> Nicolas
>
> > 0xC0, /* End Collection, */
> > 0x85, 0x02, /* Report ID (2), */
> > 0x05, 0x08, /* Usage Page (LED), */
> > 0x0A, 0x01, 0x00, /* Usage (01h), */
> > 0x0A, 0x02, 0x00, /* Usage (02h), */
> > 0x0A, 0x03, 0x00, /* Usage (03h), */
> > 0x0A, 0x04, 0x00, /* Usage (04h), */
> > 0x15, 0x00, /* Logical Minimum (0), */
> > 0x25, 0x01, /* Logical Maximum (1), */
> > 0x75, 0x01, /* Report Size (1), */
> > 0x95, 0x04, /* Report Count (4), */
> > 0x91, 0x02, /* Output (Variable), */
> > 0x75, 0x04, /* Report Size (4), */
> > 0x95, 0x01, /* Report Count (1), */
> > 0x91, 0x03, /* Output (Constant, Variable), */
> > 0xC0, /* End Collection, */
> > 0x05, 0x0C, /* Usage Page (Consumer), */
> > 0x09, 0x01, /* Usage (Consumer Control), */
> > 0xA1, 0x01, /* Collection (Application), */
> > 0x85, 0x03, /* Report ID (3), */
> > 0x05, 0x01, /* Usage Page (Desktop), */
> > 0x09, 0x06, /* Usage (Keyboard), */
> > 0xA1, 0x02, /* Collection (Logical), */
> > 0x05, 0x06, /* Usage Page (Device), */
> > 0x09, 0x20, /* Usage (20h), */
> > 0x15, 0x00, /* Logical Minimum (0), */
> > 0x26, 0xFF, 0x00, /* Logical Maximum (255), */
> > 0x75, 0x08, /* Report Size (8), */
> > 0x95, 0x01, /* Report Count (1), */
> > 0x81, 0x02, /* Input (Variable), */
> > 0x06, 0xBC, 0xFF, /* Usage Page (FFBCh), */
> > 0x0A, 0xAD, 0xBD, /* Usage (BDADh), */
> > 0x75, 0x08, /* Report Size (8), */
> > 0x95, 0x06, /* Report Count (6), */
> > 0x81, 0x02, /* Input (Variable), */
> > 0xC0, /* End Collection, */
> > 0xC0 /* End Collection */
> >
>
^ permalink raw reply
* Re: Regression post "HID: core: move Usage Page concatenation to Main item"
From: Nicolas Saenz Julienne @ 2019-06-14 12:28 UTC (permalink / raw)
To: Jean-Baptiste Théou, Jiri Kosina, linux-input, linux-kernel,
Benjamin Tissoires
In-Reply-To: <1ed66b4e9090b802259aa0fce5da1e22bcaeaafc.camel@suse.de>
[-- Attachment #1: Type: text/plain, Size: 7809 bytes --]
On Fri, 2019-06-14 at 10:52 +0200, Nicolas Saenz Julienne wrote:
> On Fri, 2019-06-14 at 09:02 +0900, Jean-Baptiste Théou wrote:
> > Sorry - Please find the public link:
> >
> >
>
https://android.googlesource.com/platform/cts/+/master/tests/tests/hardware/res/raw/asus_gamepad_register.json
> > Best regards
> >
> > On Fri, Jun 14, 2019 at 9:01 AM Jean-Baptiste Théou <jb@essential.com>
> > wrote:
> > > Hi,
> > >
> > > This patch (58e75155009cc800005629955d3482f36a1e0eec) is triggering a
> > > regression with the following descriptor (report not working as
> > > expected)
> > >
> > >
>
https://partner-android.googlesource.com/platform/cts/+/refs/heads/q-fs-release/tests/tests/hardware/res/raw/asus_gamepad_register.json
> > > Didn't see anything obviously wrong with this gamepad descriptor, so
> > > not sure what's trigger the regression.
> > >
> > > Thanks a lot
> > >
> > > Best regards
>
> Added Benjamin to the mail thread.
>
> For the record here's the report descritor, I have the feeling the issue is
> related to the Usage Page being defined in the middle of the Usage
> ennumeration.
>
> 0x05, 0x01, /* Usage Page (Desktop), */
> 0x09, 0x05, /* Usage (Gamepad), */
> 0xA1, 0x01, /* Collection (Application), */
> 0x85, 0x01, /* Report ID (1), */
> 0x05, 0x09, /* Usage Page (Button), */
> 0x0A, 0x01, 0x00, /* Usage (01h), */
> 0x0A, 0x02, 0x00, /* Usage (02h), */
> 0x0A, 0x04, 0x00, /* Usage (04h), */
> 0x0A, 0x05, 0x00, /* Usage (05h), */
> 0x0A, 0x07, 0x00, /* Usage (07h), */
> 0x0A, 0x08, 0x00, /* Usage (08h), */
> 0x0A, 0x0E, 0x00, /* Usage (0Eh), */
> 0x0A, 0x0F, 0x00, /* Usage (0Fh), */
> 0x0A, 0x0D, 0x00, /* Usage (0Dh), */
> 0x05, 0x0C, /* Usage Page (Consumer), */
> 0x0A, 0x24, 0x02, /* Usage (AC Back), */
> 0x0A, 0x23, 0x02, /* Usage (AC Home), */
> 0x15, 0x00, /* Logical Minimum (0), */
> 0x25, 0x01, /* Logical Maximum (1), */
> 0x75, 0x01, /* Report Size (1), */
> 0x95, 0x0B, /* Report Count (11), */
> 0x81, 0x02, /* Input (Variable), */
> 0x75, 0x01, /* Report Size (1), */
> 0x95, 0x01, /* Report Count (1), */
> 0x81, 0x03, /* Input (Constant, Variable), */
> 0x05, 0x01, /* Usage Page (Desktop), */
> 0x75, 0x04, /* Report Size (4), */
> 0x95, 0x01, /* Report Count (1), */
> 0x25, 0x07, /* Logical Maximum (7), */
> 0x46, 0x3B, 0x01, /* Physical Maximum (315), */
> 0x66, 0x14, 0x00, /* Unit (Degrees), */
> 0x09, 0x39, /* Usage (Hat Switch), */
> 0x81, 0x42, /* Input (Variable, Null State), */
> 0x66, 0x00, 0x00, /* Unit, */
> 0x09, 0x01, /* Usage (Pointer), */
> 0xA1, 0x00, /* Collection (Physical), */
> 0x09, 0x30, /* Usage (X), */
> 0x09, 0x31, /* Usage (Y), */
> 0x09, 0x32, /* Usage (Z), */
> 0x09, 0x35, /* Usage (Rz), */
> 0x05, 0x02, /* Usage Page (Simulation), */
> 0x09, 0xC5, /* Usage (C5h), */
> 0x09, 0xC4, /* Usage (C4h), */
> 0x15, 0x00, /* Logical Minimum (0), */
> 0x26, 0xFF, 0x00, /* Logical Maximum (255), */
> 0x35, 0x00, /* Physical Minimum (0), */
> 0x46, 0xFF, 0x00, /* Physical Maximum (255), */
> 0x75, 0x08, /* Report Size (8), */
> 0x95, 0x06, /* Report Count (6), */
> 0x81, 0x02, /* Input (Variable), */
Well as it was stated in 57e75155009 ("HID: core: move Usage Page concatenation
to Main item"):
The spec is not pretty clear as 5.2.2.7 states "Any usage that follows
is interpreted as a Usage ID and concatenated with the Usage Page".
While 5.2.2.8 states "When the parser encounters a main item it
concatenates the last declared Usage Page with a Usage to form a
complete usage value." Being somewhat contradictory it was decided to
match Window's implementation, which follows 5.2.2.8.
This breaks the Report above as X, Y, Z and Rz will be concatenanted with the
'Simulation' Usage Page as opposed to the 'Desktop' one.
Based on the USB IDs can't find much information on this Gamepad, is it a real
one? If so I guess the solution would be to fix the report descriptor in a
custom driver. Otherwise I'd suggest fixing the descriptors directly on the
test suite.
Regards,
Nicolas
> 0xC0, /* End Collection, */
> 0x85, 0x02, /* Report ID (2), */
> 0x05, 0x08, /* Usage Page (LED), */
> 0x0A, 0x01, 0x00, /* Usage (01h), */
> 0x0A, 0x02, 0x00, /* Usage (02h), */
> 0x0A, 0x03, 0x00, /* Usage (03h), */
> 0x0A, 0x04, 0x00, /* Usage (04h), */
> 0x15, 0x00, /* Logical Minimum (0), */
> 0x25, 0x01, /* Logical Maximum (1), */
> 0x75, 0x01, /* Report Size (1), */
> 0x95, 0x04, /* Report Count (4), */
> 0x91, 0x02, /* Output (Variable), */
> 0x75, 0x04, /* Report Size (4), */
> 0x95, 0x01, /* Report Count (1), */
> 0x91, 0x03, /* Output (Constant, Variable), */
> 0xC0, /* End Collection, */
> 0x05, 0x0C, /* Usage Page (Consumer), */
> 0x09, 0x01, /* Usage (Consumer Control), */
> 0xA1, 0x01, /* Collection (Application), */
> 0x85, 0x03, /* Report ID (3), */
> 0x05, 0x01, /* Usage Page (Desktop), */
> 0x09, 0x06, /* Usage (Keyboard), */
> 0xA1, 0x02, /* Collection (Logical), */
> 0x05, 0x06, /* Usage Page (Device), */
> 0x09, 0x20, /* Usage (20h), */
> 0x15, 0x00, /* Logical Minimum (0), */
> 0x26, 0xFF, 0x00, /* Logical Maximum (255), */
> 0x75, 0x08, /* Report Size (8), */
> 0x95, 0x01, /* Report Count (1), */
> 0x81, 0x02, /* Input (Variable), */
> 0x06, 0xBC, 0xFF, /* Usage Page (FFBCh), */
> 0x0A, 0xAD, 0xBD, /* Usage (BDADh), */
> 0x75, 0x08, /* Report Size (8), */
> 0x95, 0x06, /* Report Count (6), */
> 0x81, 0x02, /* Input (Variable), */
> 0xC0, /* End Collection, */
> 0xC0 /* End Collection */
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2] HID: input: fix a4tech horizontal wheel custom usage
From: Wolfgang Bauer @ 2019-06-14 12:00 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Nicolas Saenz Julienne, Jiri Kosina, Dmitry Torokhov,
open list:HID CORE LAYER, lkml
In-Reply-To: <CAO-hwJLAiC1o-kZ5epZHtO2GK+zc5x28pYbZH-XsY4yAuBmHWw@mail.gmail.com>
I tested linux-next (20190612) meanwhile as well.
My mouse wheel doesn't work with that kernel, this patch fixes it.
Kind Regards,
Wolfgang
^ permalink raw reply
* [PATCH] HID: multitouch: Add pointstick support for ALPS Touchpad
From: Kai-Heng Feng @ 2019-06-14 8:56 UTC (permalink / raw)
To: jikos, benjamin.tissoires; +Cc: linux-input, linux-kernel, Kai-Heng Feng
There's a new ALPS touchpad/pointstick combo device that requires
MT_CLS_WIN_8_DUAL to make its pointsitck work as a mouse.
The device can be found on HP ZBook 17 G5.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-multitouch.c | 4 ++++
2 files changed, 5 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index eac0c54c5970..5311c62aeb88 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -80,6 +80,7 @@
#define HID_DEVICE_ID_ALPS_U1_DUAL_3BTN_PTP 0x1220
#define HID_DEVICE_ID_ALPS_U1 0x1215
#define HID_DEVICE_ID_ALPS_T4_BTNLESS 0x120C
+#define HID_DEVICE_ID_ALPS_1222 0x1222
#define USB_VENDOR_ID_AMI 0x046b
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 5df5dd56ecc8..b603c14d043b 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -1776,6 +1776,10 @@ static const struct hid_device_id mt_devices[] = {
HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
USB_VENDOR_ID_ALPS_JP,
HID_DEVICE_ID_ALPS_U1_DUAL_3BTN_PTP) },
+ { .driver_data = MT_CLS_WIN_8_DUAL,
+ HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
+ USB_VENDOR_ID_ALPS_JP,
+ HID_DEVICE_ID_ALPS_1222) },
/* Lenovo X1 TAB Gen 2 */
{ .driver_data = MT_CLS_WIN_8_DUAL,
--
2.17.1
^ permalink raw reply related
* Re: Regression post "HID: core: move Usage Page concatenation to Main item"
From: Nicolas Saenz Julienne @ 2019-06-14 8:52 UTC (permalink / raw)
To: Jean-Baptiste Théou, Jiri Kosina, linux-input, linux-kernel,
Benjamin Tissoires
In-Reply-To: <CAEXycpKJvSsyDQjeCC4YqmtN5tpmO15g8D-_3mrunY-NL1w4Qw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6618 bytes --]
On Fri, 2019-06-14 at 09:02 +0900, Jean-Baptiste Théou wrote:
> Sorry - Please find the public link:
>
>
https://android.googlesource.com/platform/cts/+/master/tests/tests/hardware/res/raw/asus_gamepad_register.json
>
> Best regards
>
> On Fri, Jun 14, 2019 at 9:01 AM Jean-Baptiste Théou <jb@essential.com> wrote:
> > Hi,
> >
> > This patch (58e75155009cc800005629955d3482f36a1e0eec) is triggering a
> > regression with the following descriptor (report not working as
> > expected)
> >
> >
https://partner-android.googlesource.com/platform/cts/+/refs/heads/q-fs-release/tests/tests/hardware/res/raw/asus_gamepad_register.json
> >
> > Didn't see anything obviously wrong with this gamepad descriptor, so
> > not sure what's trigger the regression.
> >
> > Thanks a lot
> >
> > Best regards
Added Benjamin to the mail thread.
For the record here's the report descritor, I have the feeling the issue is
related to the Usage Page being defined in the middle of the Usage
ennumeration.
0x05, 0x01, /* Usage Page (Desktop), */
0x09, 0x05, /* Usage (Gamepad), */
0xA1, 0x01, /* Collection (Application), */
0x85, 0x01, /* Report ID (1), */
0x05, 0x09, /* Usage Page (Button), */
0x0A, 0x01, 0x00, /* Usage (01h), */
0x0A, 0x02, 0x00, /* Usage (02h), */
0x0A, 0x04, 0x00, /* Usage (04h), */
0x0A, 0x05, 0x00, /* Usage (05h), */
0x0A, 0x07, 0x00, /* Usage (07h), */
0x0A, 0x08, 0x00, /* Usage (08h), */
0x0A, 0x0E, 0x00, /* Usage (0Eh), */
0x0A, 0x0F, 0x00, /* Usage (0Fh), */
0x0A, 0x0D, 0x00, /* Usage (0Dh), */
0x05, 0x0C, /* Usage Page (Consumer), */
0x0A, 0x24, 0x02, /* Usage (AC Back), */
0x0A, 0x23, 0x02, /* Usage (AC Home), */
0x15, 0x00, /* Logical Minimum (0), */
0x25, 0x01, /* Logical Maximum (1), */
0x75, 0x01, /* Report Size (1), */
0x95, 0x0B, /* Report Count (11), */
0x81, 0x02, /* Input (Variable), */
0x75, 0x01, /* Report Size (1), */
0x95, 0x01, /* Report Count (1), */
0x81, 0x03, /* Input (Constant, Variable), */
0x05, 0x01, /* Usage Page (Desktop), */
0x75, 0x04, /* Report Size (4), */
0x95, 0x01, /* Report Count (1), */
0x25, 0x07, /* Logical Maximum (7), */
0x46, 0x3B, 0x01, /* Physical Maximum (315), */
0x66, 0x14, 0x00, /* Unit (Degrees), */
0x09, 0x39, /* Usage (Hat Switch), */
0x81, 0x42, /* Input (Variable, Null State), */
0x66, 0x00, 0x00, /* Unit, */
0x09, 0x01, /* Usage (Pointer), */
0xA1, 0x00, /* Collection (Physical), */
0x09, 0x30, /* Usage (X), */
0x09, 0x31, /* Usage (Y), */
0x09, 0x32, /* Usage (Z), */
0x09, 0x35, /* Usage (Rz), */
0x05, 0x02, /* Usage Page (Simulation), */
0x09, 0xC5, /* Usage (C5h), */
0x09, 0xC4, /* Usage (C4h), */
0x15, 0x00, /* Logical Minimum (0), */
0x26, 0xFF, 0x00, /* Logical Maximum (255), */
0x35, 0x00, /* Physical Minimum (0), */
0x46, 0xFF, 0x00, /* Physical Maximum (255), */
0x75, 0x08, /* Report Size (8), */
0x95, 0x06, /* Report Count (6), */
0x81, 0x02, /* Input (Variable), */
0xC0, /* End Collection, */
0x85, 0x02, /* Report ID (2), */
0x05, 0x08, /* Usage Page (LED), */
0x0A, 0x01, 0x00, /* Usage (01h), */
0x0A, 0x02, 0x00, /* Usage (02h), */
0x0A, 0x03, 0x00, /* Usage (03h), */
0x0A, 0x04, 0x00, /* Usage (04h), */
0x15, 0x00, /* Logical Minimum (0), */
0x25, 0x01, /* Logical Maximum (1), */
0x75, 0x01, /* Report Size (1), */
0x95, 0x04, /* Report Count (4), */
0x91, 0x02, /* Output (Variable), */
0x75, 0x04, /* Report Size (4), */
0x95, 0x01, /* Report Count (1), */
0x91, 0x03, /* Output (Constant, Variable), */
0xC0, /* End Collection, */
0x05, 0x0C, /* Usage Page (Consumer), */
0x09, 0x01, /* Usage (Consumer Control), */
0xA1, 0x01, /* Collection (Application), */
0x85, 0x03, /* Report ID (3), */
0x05, 0x01, /* Usage Page (Desktop), */
0x09, 0x06, /* Usage (Keyboard), */
0xA1, 0x02, /* Collection (Logical), */
0x05, 0x06, /* Usage Page (Device), */
0x09, 0x20, /* Usage (20h), */
0x15, 0x00, /* Logical Minimum (0), */
0x26, 0xFF, 0x00, /* Logical Maximum (255), */
0x75, 0x08, /* Report Size (8), */
0x95, 0x01, /* Report Count (1), */
0x81, 0x02, /* Input (Variable), */
0x06, 0xBC, 0xFF, /* Usage Page (FFBCh), */
0x0A, 0xAD, 0xBD, /* Usage (BDADh), */
0x75, 0x08, /* Report Size (8), */
0x95, 0x06, /* Report Count (6), */
0x81, 0x02, /* Input (Variable), */
0xC0, /* End Collection, */
0xC0 /* End Collection */
Regads,
Nicolas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: Regression post "HID: core: move Usage Page concatenation to Main item"
From: Nicolas Saenz Julienne @ 2019-06-14 8:29 UTC (permalink / raw)
To: Jean-Baptiste Théou, Jiri Kosina, linux-input, linux-kernel
In-Reply-To: <CAEXycp+Y-x7N_Yr==Xy_CT5K_a1DZYc85w1OUV+cKC5ZN+KB1g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 629 bytes --]
On Fri, 2019-06-14 at 09:01 +0900, Jean-Baptiste Théou wrote:
> Hi,
>
> This patch (58e75155009cc800005629955d3482f36a1e0eec) is triggering a
> regression with the following descriptor (report not working as
> expected)
>
>
https://partner-android.googlesource.com/platform/cts/+/refs/heads/q-fs-release/tests/tests/hardware/res/raw/asus_gamepad_register.json
>
> Didn't see anything obviously wrong with this gamepad descriptor, so
> not sure what's trigger the regression.
>
I'll have a look at it.
Do you have any more information on the regression? What exactly isn't working?
Regards,
Nicolas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox