* Re: [PATCH] Input: xpad - add Lenovo Legion Go controllers
From: Hans de Goede @ 2023-11-16 18:20 UTC (permalink / raw)
To: Brenton Simpson, Dmitry Torokhov
Cc: Erica Taylor, Vicki Pfau, nate, linux-input, linux-kernel,
Ismael Ferreras Morezuelas, Cameron Gutman
In-Reply-To: <CAAL3-=88exVfuL1Y-kvPNbsU+d-UTfDLFViWVObFLtbC4xueeA@mail.gmail.com>
Hi Brenton,
On 11/16/23 18:45, Brenton Simpson wrote:
> When the controllers are both attached (or detached), they appear as
> 0x17ef, 0x6182. When only one is attached, they appear as
> 0x17ef, 0x6184.
>
> 84 (mixed attachment) is already recognized as a gamepad by Linux. This
> patch adds 82 (both attached/detached).
>
> These controllers have many more buttons than is typical. With this
> patch, here's what's functional when it presents as 82:
>
> Recognized:
>
> - X, Y, A, B
> - both analog sticks, including L3/R3
> - D-pad
> - menu and capture buttons
> - rumble
>
> Not yet recognized:
>
> - start, select
> - 4 rear paddle buttons (Y1, Y2, Y3, M3)
> - gyroscope
>
> (There are also non-functional buttons when reporting as 84 that are
> out-of-scope for this patch.)
>
> Signed-off-by: Brenton Simpson <appsforartists@google.com>
> ---
> drivers/input/joystick/xpad.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
> index f5c21565bb3cec..ecfcea8740a009 100644
> --- a/drivers/input/joystick/xpad.c
> +++ b/drivers/input/joystick/xpad.c
> @@ -127,6 +127,7 @@ static const struct xpad_device {
> u8 mapping;
> u8 xtype;
> } xpad_device[] = {
It looks like your workflow of copy-pasting this into your
email client has turned the tabs in the patch into a single space
character.
This and possibly other issues (line-wrapping, wrong end-of-line type)
is why using git send-email is the preferred way to submit kernel
patches.
Maybe try using Brenton Simpson <appsforartists+kernel@google.com>
for both the author and signed-off-by fields and then use
git send-email ?
Regards,
Hans
p.s.
Might be best to send the next attempt just to me, until you've
figured out a working email setup. And then once we have things
working, re-submit to the right people ?
> + { 0x17ef, 0x6182, "Lenovo Legion Go Controller (unified)", 0, XTYPE_XBOX360 },
> { 0x0079, 0x18d4, "GPD Win 2 X-Box Controller", 0, XTYPE_XBOX360 },
> { 0x03eb, 0xff01, "Wooting One (Legacy)", 0, XTYPE_XBOX360 },
> { 0x03eb, 0xff02, "Wooting Two (Legacy)", 0, XTYPE_XBOX360 },
> @@ -459,6 +460,7 @@ static const signed short xpad_btn_paddles[] = {
>
> static const struct usb_device_id xpad_table[] = {
> { USB_INTERFACE_INFO('X', 'B', 0) }, /* Xbox USB-IF not-approved class */
> + XPAD_XBOX360_VENDOR(0x17ef), /* Lenovo */
> XPAD_XBOX360_VENDOR(0x0079), /* GPD Win 2 controller */
> XPAD_XBOX360_VENDOR(0x03eb), /* Wooting Keyboards (Legacy) */
> XPAD_XBOXONE_VENDOR(0x03f0), /* HP HyperX Xbox One controllers */
>
^ permalink raw reply
* [PATCH] Input: xpad - add Lenovo Legion Go controllers
From: Brenton Simpson @ 2023-11-16 17:45 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Erica Taylor, Vicki Pfau, nate, linux-input, linux-kernel,
Ismael Ferreras Morezuelas, Cameron Gutman, Hans de Goede
When the controllers are both attached (or detached), they appear as
0x17ef, 0x6182. When only one is attached, they appear as
0x17ef, 0x6184.
84 (mixed attachment) is already recognized as a gamepad by Linux. This
patch adds 82 (both attached/detached).
These controllers have many more buttons than is typical. With this
patch, here's what's functional when it presents as 82:
Recognized:
- X, Y, A, B
- both analog sticks, including L3/R3
- D-pad
- menu and capture buttons
- rumble
Not yet recognized:
- start, select
- 4 rear paddle buttons (Y1, Y2, Y3, M3)
- gyroscope
(There are also non-functional buttons when reporting as 84 that are
out-of-scope for this patch.)
Signed-off-by: Brenton Simpson <appsforartists@google.com>
---
drivers/input/joystick/xpad.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index f5c21565bb3cec..ecfcea8740a009 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -127,6 +127,7 @@ static const struct xpad_device {
u8 mapping;
u8 xtype;
} xpad_device[] = {
+ { 0x17ef, 0x6182, "Lenovo Legion Go Controller (unified)", 0, XTYPE_XBOX360 },
{ 0x0079, 0x18d4, "GPD Win 2 X-Box Controller", 0, XTYPE_XBOX360 },
{ 0x03eb, 0xff01, "Wooting One (Legacy)", 0, XTYPE_XBOX360 },
{ 0x03eb, 0xff02, "Wooting Two (Legacy)", 0, XTYPE_XBOX360 },
@@ -459,6 +460,7 @@ static const signed short xpad_btn_paddles[] = {
static const struct usb_device_id xpad_table[] = {
{ USB_INTERFACE_INFO('X', 'B', 0) }, /* Xbox USB-IF not-approved class */
+ XPAD_XBOX360_VENDOR(0x17ef), /* Lenovo */
XPAD_XBOX360_VENDOR(0x0079), /* GPD Win 2 controller */
XPAD_XBOX360_VENDOR(0x03eb), /* Wooting Keyboards (Legacy) */
XPAD_XBOXONE_VENDOR(0x03f0), /* HP HyperX Xbox One controllers */
^ permalink raw reply related
* Re: [PATCH v5 1/3] dt-bindings: input: microchip,cap11xx: add advanced sensitivity settings
From: Krzysztof Kozlowski @ 2023-11-16 17:24 UTC (permalink / raw)
To: Jiri Valek - 2N, krzysztof.kozlowski+dt, dmitry.torokhov
Cc: devicetree, linux-input, linux-kernel, robh+dt, u.kleine-koenig
In-Reply-To: <368eea0d-0445-4286-8489-9a4a109606db@axis.com>
On 16/11/2023 17:00, Jiri Valek - 2N wrote:
>>> + The number of entries must correspond to the number of channels.
>>> +
>>> patternProperties:
>>> "^led@[0-7]$":
>>
>>
>> Best regards,
>> Krzysztof
>>
>
> So are these changes fine for you?
> If yes I prepare new patch revision.
Yes
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 0/7] HID: i2c-hid: Rework wait for reset to match Windows
From: Hans de Goede @ 2023-11-16 16:46 UTC (permalink / raw)
To: Julian Sax
Cc: Jiri Kosina, Benjamin Tissoires, Douglas Anderson, ahormann,
Bruno Jesus, Dietrich, kloxdami, Tim Aldridge, Rene Wagner,
Federico Ricchiuto, linux-input
In-Reply-To: <94818595-be2d-4cba-bd82-1585b8d11fed@gmx.de>
Hi,
On 11/8/23 21:41, Julian Sax wrote:
>
> Am 04.11.23 um 12:17 schrieb Hans de Goede:
>> Julian, I've added you to the Cc because you developed the code
>> for touchpads where the HID report descriptors are missing and are
>> provided by the kernel through a DMI quirk. The behavior for these
>> touchpads should be unchanged, but if you can test on a laptop
>> with such a touchpad that would be great.
>>
>
> Hi Hans,
>
> I just tested the touchpad with these patches, everything still works fine.
That is good to hear, thank you for testing.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH v5 1/3] dt-bindings: input: microchip,cap11xx: add advanced sensitivity settings
From: Jiri Valek - 2N @ 2023-11-16 16:00 UTC (permalink / raw)
To: Krzysztof Kozlowski, krzysztof.kozlowski+dt, dmitry.torokhov
Cc: devicetree, linux-input, linux-kernel, robh+dt, u.kleine-koenig
In-Reply-To: <eede2e04-45e5-46fb-ba00-fec0a7862711@linaro.org>
On 11/10/23 09:22, Krzysztof Kozlowski wrote:
> On 08/11/2023 16:56, Jiri Valek - 2N wrote:
>> Add support for advanced sensitivity settings and signal guard feature.
>>
>> Signed-off-by: Jiri Valek - 2N <jiriv@axis.com>
>> ---
>> .../bindings/input/microchip,cap11xx.yaml | 76 ++++++++++++++++++-
>> 1 file changed, 73 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
>> index 5b5d4f7d3482..aa97702c43ef 100644
>> --- a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
>> +++ b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
>> @@ -45,13 +45,13 @@ properties:
>> Enables the Linux input system's autorepeat feature on the input device.
>>
>> linux,keycodes:
>> - minItems: 6
>> - maxItems: 6
>> + minItems: 3
>> + maxItems: 8
>> description: |
>> Specifies an array of numeric keycode values to
>> be used for the channels. If this property is
>> omitted, KEY_A, KEY_B, etc are used as defaults.
>> - The array must have exactly six entries.
>> + The number of entries must correspond to the number of channels.
>>
>> microchip,sensor-gain:
>> $ref: /schemas/types.yaml#/definitions/uint32
>> @@ -70,6 +70,55 @@ properties:
>> open drain. This property allows using the active
>> high push-pull output.
>>
>> + microchip,sensitivity-delta-sense:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + default: 32
>> + enum: [1, 2, 4, 8, 16, 32, 64, 128]
>> + description:
>> + Optional parameter. Controls the sensitivity multiplier of a touch detection.
>> + At the more sensitive settings, touches are detected for a smaller delta
>
> Which values are more sensitive?
Higher value means more sensitive settings.
I will add this line to description.
>
>> + capacitance corresponding to a “lighter” touch.
>
> Looks like you use some non-ASCII characters for ".
I will fix it.
>
>> +
>> + microchip,signal-guard:
>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>> + minItems: 3
>> + maxItems: 8
>> + items:
>> + minimum: 0
>> + maximum: 1
>> + description: |
>> + Optional parameter supported only for CAP129x.
>> + 0 - off
>> + 1 - on
>> + The signal guard isolates the signal from virtual grounds.
>> + If enabled then the behavior of the channel is changed to signal guard.
>> + The number of entries must correspond to the number of channels.
>> +
>> + microchip,input-treshold:
>
> typo: threshold
I will fix it in Documentation and also in source code.
Copy paste error...
>
>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>> + minItems: 3
>> + maxItems: 8
>> + items:
>> + minimum: 0
>> + maximum: 127
>> + description:
>> + Optional parameter. Specifies the delta threshold that is used to
>
> Drop everywhere the "optional parameter". It's redundant. required:
> block tells what is / is not optional.
OK will be fixed.
>
>> + determine if a touch has been detected.
>
> In what units are the values?
According to the datasheet it is dimensionless, no more info.
A higher value means a larger difference in capacitance is required for a touch to be registered.
>
>> + The number of entries must correspond to the number of channels.
>> +
>> + microchip,calib-sensitivity:
>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>> + minItems: 3
>> + maxItems: 8
>> + items:
>> + minimum: 1
>> + maximum: 4
>> + description:
>> + Optional parameter supported only for CAP129x. Specifies an array of
>> + numeric values that controls the gain used by the calibration routine to
>> + enable sensor inputs to be more sensitive for proximity detection.
>
> Gain is usually in dB, isn't it?
Usually yes, but again there are no units in datasheet.
There is note that gain is based on capacitance touch pad capacitance range
1 - 5-50pF
2 - 0-25pF
4 - 0-12.5pF
I will add this to description and change items to enum: [1, 2, 4]
>
>> + The number of entries must correspond to the number of channels.
>> +
>> patternProperties:
>> "^led@[0-7]$":
>
>
> Best regards,
> Krzysztof
>
So are these changes fine for you?
If yes I prepare new patch revision.
Best regards,
Jiri
^ permalink raw reply
* Re: [PATCH 11/32] hid/picolcd_fb: Set FBINFO_VIRTFB flag
From: Javier Martinez Canillas @ 2023-11-16 10:27 UTC (permalink / raw)
To: Thomas Zimmermann, deller
Cc: linux-fbdev, dri-devel, Thomas Zimmermann, Bruno Prémont,
Jiri Kosina, Benjamin Tissoires, linux-input
In-Reply-To: <20231115102954.7102-12-tzimmermann@suse.de>
Thomas Zimmermann <tzimmermann@suse.de> writes:
> The picolcd_fb driver operates on system memory. Mark the framebuffer
> accordingly. Helpers operating on the framebuffer memory will test
> for the presence of this flag.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: "Bruno Prémont" <bonbons@linux-vserver.org>
> Cc: Jiri Kosina <jikos@kernel.org>
> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> Cc: linux-input@vger.kernel.org
> ---
> drivers/hid/hid-picolcd_fb.c | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply
* Re: [PATCH v5 3/3] Input: cap11xx - remove unnecessary IRQ parsing
From: Jiri Valek - 2N @ 2023-11-16 7:43 UTC (permalink / raw)
To: Rob Herring
Cc: krzysztof.kozlowski+dt, dmitry.torokhov, devicetree, linux-input,
linux-kernel, u.kleine-koenig
In-Reply-To: <CAL_JsqL3veRuuDqWnZ+eUTP5Mvz5WffYktrBh6HqyARRThzmYQ@mail.gmail.com>
On 11/8/23 20:53, Rob Herring wrote:
> On Wed, Nov 8, 2023 at 9:57 AM Jiri Valek - 2N <jiriv@axis.com> wrote:
>>
>> Separate IRQ parsing is not necessary, I2C core do the job.
>>
>> Signed-off-by: Jiri Valek - 2N <jiriv@axis.com>
>> ---
>> drivers/input/keyboard/cap11xx.c | 10 ++--------
>> 1 file changed, 2 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
>> index 4711ea985627..ccca9936ef25 100644
>> --- a/drivers/input/keyboard/cap11xx.c
>> +++ b/drivers/input/keyboard/cap11xx.c
>> @@ -518,7 +518,7 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client)
>> struct device *dev = &i2c_client->dev;
>> struct cap11xx_priv *priv;
>> const struct cap11xx_hw_model *cap;
>> - int i, error, irq;
>> + int i, error;
>> unsigned int val, rev;
>>
>> if (id->driver_data >= ARRAY_SIZE(cap11xx_devices)) {
>> @@ -624,13 +624,7 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client)
>> if (error)
>> return error;
>>
>> - irq = irq_of_parse_and_map(dev->of_node, 0);
>
> Probably can drop the include of of_irq.h as well.
Ack. Thanks for notice!
^ permalink raw reply
* Re: [RFC PATCH v2 0/7] of: Introduce hardware prober driver
From: Chen-Yu Tsai @ 2023-11-16 5:11 UTC (permalink / raw)
To: Doug Anderson
Cc: Rob Herring, AngeloGioacchino Del Regno, Frank Rowand,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger, Hsin-Yi Wang,
Dmitry Torokhov, andriy.shevchenko, Jiri Kosina, linus.walleij,
broonie, gregkh, hdegoede, james.clark, james, keescook, rafael,
tglx, Jeff LaBundy, linux-input, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel, Johan Hovold
In-Reply-To: <CAD=FV=XO5VNuaVKwBHLQC1ukdpHQO0-XTaKnRM=rigbcdOytgQ@mail.gmail.com>
On Thu, Nov 16, 2023 at 6:14 AM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Wed, Nov 15, 2023 at 4:35 PM Rob Herring <robh+dt@kernel.org> wrote:
> >
> > On Wed, Nov 15, 2023 at 2:45 PM Doug Anderson <dianders@chromium.org> wrote:
> > >
> > > Hi,
> > >
> > > On Wed, Nov 15, 2023 at 2:28 PM Rob Herring <robh+dt@kernel.org> wrote:
> > > >
> > > > > So if we're searching the whole device tree for "failed-needs-probe"
> > > > > then we need to figure out which devices are related to each other. If
> > > > > a given board has second sources for MIPI panels, touchscreens, and
> > > > > trackpads then we need to know which of the "failed-needs-probe"
> > > > > devices are trackpads, which are touchscreens, and which are MIPI
> > > > > panels. Do you have any suggestions for how we should do that? Maybe
> > > > > it was in some other thread that I missed? I guess we could have a
> > > > > board-specific table mapping (compatible + node name + reg) to a
> > > > > class, but that feels awkward.
> > > >
> > > > Node name is supposed to correspond to device class, so why not use
> > > > that (no path or unit-address.) and nothing else (well, besides
> > > > "status")?
> > >
> > > One problem is that I could imagine having two second source trackpads
> > > that both have the same i2c address. That would give them the same
> > > name, right? I guess you could maybe come up with some sort of suffix
> > > rule? Like
> > >
> > > trackpad-1@10 {
> > > compatible = "elan,blah";
> > > ret = <0x10>;
> > > status = "failed-needs-probe";
> > > ...
> > > }
> > > trackpad-2@10 {
> > > compatible = "goodix,gt7375p";
> > > ret = <0x10>;
> > > status = "failed-needs-probe";
> > > ...
> > > }
> > >
> > > Then I guess the class would be "trackpad"?
> >
> > That issue is somewhat orthogonal because it is not following the spec.
>
> I'm not sure why you say it's orthogonal. The whole reason why we get
> into the situation above is that we could have two devices, only one
> of which is present (hence the status of "failed-needs-probe"), that
> are the same type and have the same "reg" address.
>
> Essentially the whole "failed-needs-probe" is extending the spec,
> right? While extending the spec, we also need to talk about what to do
> if some of the devices that we need to probe have the same class and
> the same "reg".
If it's at the same address, then you would need some device specific
probing code, like reading a register back and checking if matches
some known value. This could be done by passing in some kind of table,
but it is by no means as generic as checking if an address responds.
This is what we have on MT8186 Tentacruel. We do have the ability to
differentiate using the SKU ID for the same address case, but I'm happy
to try other methods if it helps everyone else.
ChenYu
> > I'm not sure mixing the 2 styles of node names is a good idea. While
> > not used too much, matching by node name does ignore the unit-address,
> > but I'm not sure we could ignore a '-N'.
> >
> > I think our options are either add something to the unit-address or
> > use i2c-mux binding. Adding to the unit-address is not unprecedented.
> > I did that for some of the register bit level bindings where you have
> > a node for different bits at the same address. The downside is
> > unit-address is bus specific, so we'd have to add that for multiple
> > buses. For the i2c-mux, it's perhaps a bit complex and I'm not sure
> > what if anything you'd have to do to manage the mux that's not really
> > there.
>
> Somehow it feels weird to use an i2c-mux because there's no real mux
> present, right? ...so this would be a virtual (bogus) device that
> doesn't really exist in hardware.
>
> ...though I guess if the "mux" type binding is OK then maybe we just
> use that as the HW prober, at least for i2c devices...
>
> -Doug
^ permalink raw reply
* Re: [RFC PATCH v2 0/7] of: Introduce hardware prober driver
From: Chen-Yu Tsai @ 2023-11-16 5:07 UTC (permalink / raw)
To: Rob Herring
Cc: Doug Anderson, AngeloGioacchino Del Regno, Frank Rowand,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger, Hsin-Yi Wang,
Dmitry Torokhov, andriy.shevchenko, Jiri Kosina, linus.walleij,
broonie, gregkh, hdegoede, james.clark, james, keescook,
petr.tesarik.ext, rafael, tglx, Jeff LaBundy, linux-input,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
Johan Hovold
In-Reply-To: <CAL_JsqKR_YD6hm4Lv+OuCKms8Ha61BZRKUuiLYPgSkz3_3NCFA@mail.gmail.com>
On Thu, Nov 16, 2023 at 5:35 AM Rob Herring <robh+dt@kernel.org> wrote:
>
> On Wed, Nov 15, 2023 at 2:45 PM Doug Anderson <dianders@chromium.org> wrote:
> >
> > Hi,
> >
> > On Wed, Nov 15, 2023 at 2:28 PM Rob Herring <robh+dt@kernel.org> wrote:
> > >
> > > > So if we're searching the whole device tree for "failed-needs-probe"
> > > > then we need to figure out which devices are related to each other. If
> > > > a given board has second sources for MIPI panels, touchscreens, and
> > > > trackpads then we need to know which of the "failed-needs-probe"
> > > > devices are trackpads, which are touchscreens, and which are MIPI
> > > > panels. Do you have any suggestions for how we should do that? Maybe
> > > > it was in some other thread that I missed? I guess we could have a
> > > > board-specific table mapping (compatible + node name + reg) to a
> > > > class, but that feels awkward.
> > >
> > > Node name is supposed to correspond to device class, so why not use
> > > that (no path or unit-address.) and nothing else (well, besides
> > > "status")?
> >
> > One problem is that I could imagine having two second source trackpads
> > that both have the same i2c address. That would give them the same
> > name, right? I guess you could maybe come up with some sort of suffix
> > rule? Like
> >
> > trackpad-1@10 {
> > compatible = "elan,blah";
> > ret = <0x10>;
> > status = "failed-needs-probe";
> > ...
> > }
> > trackpad-2@10 {
> > compatible = "goodix,gt7375p";
> > ret = <0x10>;
> > status = "failed-needs-probe";
> > ...
> > }
> >
> > Then I guess the class would be "trackpad"?
>
> That issue is somewhat orthogonal because it is not following the spec.
>
> I'm not sure mixing the 2 styles of node names is a good idea. While
> not used too much, matching by node name does ignore the unit-address,
> but I'm not sure we could ignore a '-N'.
of_node_name_prefix() solves that. I assume that's the intended use case?
> I think our options are either add something to the unit-address or
> use i2c-mux binding. Adding to the unit-address is not unprecedented.
> I did that for some of the register bit level bindings where you have
> a node for different bits at the same address. The downside is
> unit-address is bus specific, so we'd have to add that for multiple
> buses. For the i2c-mux, it's perhaps a bit complex and I'm not sure
> what if anything you'd have to do to manage the mux that's not really
> there.
>
> Rob
^ permalink raw reply
* Re: [PATCH 6/7] ARM: dts: qcom: apq8026-samsung-milletwifi: Enable Wi-Fi and Bluetooth
From: kernel test robot @ 2023-11-16 4:24 UTC (permalink / raw)
To: Bryant Mairs, Andy Gross, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Linus Walleij, linux-arm-msm, devicetree, linux-kernel,
linux-input
Cc: oe-kbuild-all
In-Reply-To: <20231105204759.37107-7-bryant@mai.rs>
Hi Bryant,
kernel test robot noticed the following build errors:
[auto build test ERROR on robh/for-next]
[also build test ERROR on dtor-input/next dtor-input/for-linus linus/master v6.7-rc1 next-20231115]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Bryant-Mairs/dt-bindings-input-melfas-mms114-add-MMS252-compatible/20231106-045021
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
patch link: https://lore.kernel.org/r/20231105204759.37107-7-bryant%40mai.rs
patch subject: [PATCH 6/7] ARM: dts: qcom: apq8026-samsung-milletwifi: Enable Wi-Fi and Bluetooth
config: arm-allyesconfig (https://download.01.org/0day-ci/archive/20231116/202311161232.aXIYGTAD-lkp@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231116/202311161232.aXIYGTAD-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202311161232.aXIYGTAD-lkp@intel.com/
All errors (new ones prefixed by >>):
Error: arch/arm/boot/dts/qcom/qcom-apq8026-samsung-milletwifi.dts:15.15-26 Label or path mba_region not found
Error: arch/arm/boot/dts/qcom/qcom-apq8026-samsung-milletwifi.dts:16.15-27 Label or path mpss_region not found
Error: arch/arm/boot/dts/qcom/qcom-apq8026-samsung-milletwifi.dts:18.15-28 Label or path wcnss_region not found
>> Error: arch/arm/boot/dts/qcom/qcom-apq8026-samsung-milletwifi.dts:313.1-8 Label or path pronto not found
FATAL ERROR: Syntax error parsing input tree
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [syzbot] Monthly input report (Nov 2023)
From: syzbot @ 2023-11-16 4:11 UTC (permalink / raw)
To: linux-input, linux-kernel, syzkaller-bugs
Hello input maintainers/developers,
This is a 31-day syzbot report for the input subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/input
During the period, 1 new issues were detected and 0 were fixed.
In total, 13 issues are still open and 51 have been fixed so far.
Some of the still happening issues:
Ref Crashes Repro Title
<1> 3671 Yes WARNING in input_mt_init_slots
https://syzkaller.appspot.com/bug?extid=0122fa359a69694395d5
<2> 281 No possible deadlock in evdev_pass_values (2)
https://syzkaller.appspot.com/bug?extid=13d3cb2a3dc61e6092f5
<3> 121 Yes WARNING in cm109_urb_irq_callback/usb_submit_urb
https://syzkaller.appspot.com/bug?extid=2d6d691af5ab4b7e66df
<4> 57 Yes INFO: task hung in uhid_char_release
https://syzkaller.appspot.com/bug?extid=8fe2d362af0e1cba8735
<5> 38 Yes WARNING in bcm5974_start_traffic/usb_submit_urb
https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
To disable reminders for individual bugs, reply with the following command:
#syz set <Ref> no-reminders
To change bug's subsystems, reply with:
#syz set <Ref> subsystems: new-subsystem
You may send multiple commands in a single email message.
^ permalink raw reply
* Re: [RFC PATCH v2 0/7] of: Introduce hardware prober driver
From: Doug Anderson @ 2023-11-15 22:13 UTC (permalink / raw)
To: Rob Herring
Cc: AngeloGioacchino Del Regno, Chen-Yu Tsai, Frank Rowand,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger, Hsin-Yi Wang,
Dmitry Torokhov, andriy.shevchenko, Jiri Kosina, linus.walleij,
broonie, gregkh, hdegoede, james.clark, james, keescook,
petr.tesarik.ext, rafael, tglx, Jeff LaBundy, linux-input,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
Johan Hovold
In-Reply-To: <CAL_JsqKR_YD6hm4Lv+OuCKms8Ha61BZRKUuiLYPgSkz3_3NCFA@mail.gmail.com>
Hi,
On Wed, Nov 15, 2023 at 4:35 PM Rob Herring <robh+dt@kernel.org> wrote:
>
> On Wed, Nov 15, 2023 at 2:45 PM Doug Anderson <dianders@chromium.org> wrote:
> >
> > Hi,
> >
> > On Wed, Nov 15, 2023 at 2:28 PM Rob Herring <robh+dt@kernel.org> wrote:
> > >
> > > > So if we're searching the whole device tree for "failed-needs-probe"
> > > > then we need to figure out which devices are related to each other. If
> > > > a given board has second sources for MIPI panels, touchscreens, and
> > > > trackpads then we need to know which of the "failed-needs-probe"
> > > > devices are trackpads, which are touchscreens, and which are MIPI
> > > > panels. Do you have any suggestions for how we should do that? Maybe
> > > > it was in some other thread that I missed? I guess we could have a
> > > > board-specific table mapping (compatible + node name + reg) to a
> > > > class, but that feels awkward.
> > >
> > > Node name is supposed to correspond to device class, so why not use
> > > that (no path or unit-address.) and nothing else (well, besides
> > > "status")?
> >
> > One problem is that I could imagine having two second source trackpads
> > that both have the same i2c address. That would give them the same
> > name, right? I guess you could maybe come up with some sort of suffix
> > rule? Like
> >
> > trackpad-1@10 {
> > compatible = "elan,blah";
> > ret = <0x10>;
> > status = "failed-needs-probe";
> > ...
> > }
> > trackpad-2@10 {
> > compatible = "goodix,gt7375p";
> > ret = <0x10>;
> > status = "failed-needs-probe";
> > ...
> > }
> >
> > Then I guess the class would be "trackpad"?
>
> That issue is somewhat orthogonal because it is not following the spec.
I'm not sure why you say it's orthogonal. The whole reason why we get
into the situation above is that we could have two devices, only one
of which is present (hence the status of "failed-needs-probe"), that
are the same type and have the same "reg" address.
Essentially the whole "failed-needs-probe" is extending the spec,
right? While extending the spec, we also need to talk about what to do
if some of the devices that we need to probe have the same class and
the same "reg".
> I'm not sure mixing the 2 styles of node names is a good idea. While
> not used too much, matching by node name does ignore the unit-address,
> but I'm not sure we could ignore a '-N'.
>
> I think our options are either add something to the unit-address or
> use i2c-mux binding. Adding to the unit-address is not unprecedented.
> I did that for some of the register bit level bindings where you have
> a node for different bits at the same address. The downside is
> unit-address is bus specific, so we'd have to add that for multiple
> buses. For the i2c-mux, it's perhaps a bit complex and I'm not sure
> what if anything you'd have to do to manage the mux that's not really
> there.
Somehow it feels weird to use an i2c-mux because there's no real mux
present, right? ...so this would be a virtual (bogus) device that
doesn't really exist in hardware.
...though I guess if the "mux" type binding is OK then maybe we just
use that as the HW prober, at least for i2c devices...
-Doug
^ permalink raw reply
* Re: [RFC PATCH v2 0/7] of: Introduce hardware prober driver
From: Rob Herring @ 2023-11-15 21:34 UTC (permalink / raw)
To: Doug Anderson
Cc: AngeloGioacchino Del Regno, Chen-Yu Tsai, Frank Rowand,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger, Hsin-Yi Wang,
Dmitry Torokhov, andriy.shevchenko, Jiri Kosina, linus.walleij,
broonie, gregkh, hdegoede, james.clark, james, keescook,
petr.tesarik.ext, rafael, tglx, Jeff LaBundy, linux-input,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
Johan Hovold
In-Reply-To: <CAD=FV=X-17COQ2-tycV1bSuCrGy7MJ88Un8nA-a-ODexvgi9TQ@mail.gmail.com>
On Wed, Nov 15, 2023 at 2:45 PM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Wed, Nov 15, 2023 at 2:28 PM Rob Herring <robh+dt@kernel.org> wrote:
> >
> > > So if we're searching the whole device tree for "failed-needs-probe"
> > > then we need to figure out which devices are related to each other. If
> > > a given board has second sources for MIPI panels, touchscreens, and
> > > trackpads then we need to know which of the "failed-needs-probe"
> > > devices are trackpads, which are touchscreens, and which are MIPI
> > > panels. Do you have any suggestions for how we should do that? Maybe
> > > it was in some other thread that I missed? I guess we could have a
> > > board-specific table mapping (compatible + node name + reg) to a
> > > class, but that feels awkward.
> >
> > Node name is supposed to correspond to device class, so why not use
> > that (no path or unit-address.) and nothing else (well, besides
> > "status")?
>
> One problem is that I could imagine having two second source trackpads
> that both have the same i2c address. That would give them the same
> name, right? I guess you could maybe come up with some sort of suffix
> rule? Like
>
> trackpad-1@10 {
> compatible = "elan,blah";
> ret = <0x10>;
> status = "failed-needs-probe";
> ...
> }
> trackpad-2@10 {
> compatible = "goodix,gt7375p";
> ret = <0x10>;
> status = "failed-needs-probe";
> ...
> }
>
> Then I guess the class would be "trackpad"?
That issue is somewhat orthogonal because it is not following the spec.
I'm not sure mixing the 2 styles of node names is a good idea. While
not used too much, matching by node name does ignore the unit-address,
but I'm not sure we could ignore a '-N'.
I think our options are either add something to the unit-address or
use i2c-mux binding. Adding to the unit-address is not unprecedented.
I did that for some of the register bit level bindings where you have
a node for different bits at the same address. The downside is
unit-address is bus specific, so we'd have to add that for multiple
buses. For the i2c-mux, it's perhaps a bit complex and I'm not sure
what if anything you'd have to do to manage the mux that's not really
there.
Rob
^ permalink raw reply
* Re: [RFC PATCH v2 0/7] of: Introduce hardware prober driver
From: Doug Anderson @ 2023-11-15 20:44 UTC (permalink / raw)
To: Rob Herring
Cc: AngeloGioacchino Del Regno, Chen-Yu Tsai, Frank Rowand,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger, Hsin-Yi Wang,
Dmitry Torokhov, andriy.shevchenko, Jiri Kosina, linus.walleij,
broonie, gregkh, hdegoede, james.clark, james, keescook,
petr.tesarik.ext, rafael, tglx, Jeff LaBundy, linux-input,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
Johan Hovold
In-Reply-To: <CAL_Jsq+puq20EWkQg1RTs2zfmh4DGbqz1krp+19c=wPXnLT5dA@mail.gmail.com>
Hi,
On Wed, Nov 15, 2023 at 2:28 PM Rob Herring <robh+dt@kernel.org> wrote:
>
> > So if we're searching the whole device tree for "failed-needs-probe"
> > then we need to figure out which devices are related to each other. If
> > a given board has second sources for MIPI panels, touchscreens, and
> > trackpads then we need to know which of the "failed-needs-probe"
> > devices are trackpads, which are touchscreens, and which are MIPI
> > panels. Do you have any suggestions for how we should do that? Maybe
> > it was in some other thread that I missed? I guess we could have a
> > board-specific table mapping (compatible + node name + reg) to a
> > class, but that feels awkward.
>
> Node name is supposed to correspond to device class, so why not use
> that (no path or unit-address.) and nothing else (well, besides
> "status")?
One problem is that I could imagine having two second source trackpads
that both have the same i2c address. That would give them the same
name, right? I guess you could maybe come up with some sort of suffix
rule? Like
trackpad-1@10 {
compatible = "elan,blah";
ret = <0x10>;
status = "failed-needs-probe";
...
}
trackpad-2@10 {
compatible = "goodix,gt7375p";
ret = <0x10>;
status = "failed-needs-probe";
...
}
Then I guess the class would be "trackpad"?
-Doug
^ permalink raw reply
* Re: [RFC PATCH v2 0/7] of: Introduce hardware prober driver
From: Rob Herring @ 2023-11-15 19:28 UTC (permalink / raw)
To: Doug Anderson
Cc: AngeloGioacchino Del Regno, Chen-Yu Tsai, Frank Rowand,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger, Hsin-Yi Wang,
Dmitry Torokhov, andriy.shevchenko, Jiri Kosina, linus.walleij,
broonie, gregkh, hdegoede, james.clark, james, keescook,
petr.tesarik.ext, rafael, tglx, Jeff LaBundy, linux-input,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
Johan Hovold
In-Reply-To: <CAD=FV=VUZy9DaZgKafSpXXopD5k8ExGSR97BjAqC5tupPoxNfQ@mail.gmail.com>
On Fri, Nov 10, 2023 at 6:12 PM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Thu, Nov 9, 2023 at 5:52 AM Rob Herring <robh+dt@kernel.org> wrote:
> >
> > > > End of background from Doug's cover letter.
> > >
> > > I think that using "status" is not a good idea, I find that confusing.
> >
> > "status" is what defines a device's state in terms of enabled,
> > present, available. That's exactly what we're expressing here.
> >
> > Now, I do not think we should be mixing the device class (e.g.
> > touchscreen) into status. I said this on v1, but apparently that was
> > not listened to.
>
> Interesting. I must have missed the "don't mix device class into
> status" part. Do you have a link to your post about that? Maybe
> there's other stuff I missed... Having the device class stuck at the
> end there was at least part of my last post [1] which gathered no
> response.
https://lore.kernel.org/all/CAL_JsqKK0tjeXNv=a8L3k0AjhCa15XOq1tPWqVod9mycsKXJHg@mail.gmail.com/
"I would not combine the 2 things. Knowing the class/type of the device
may be useful independent of your problem."
> I think one of the reasons that I felt we needed to mux the device
> class into status was that it was going to make the code a lot less
> fragile. Everything I've seen indicates that you don't want us to
> create a "HW prober" node that could be used to provide relevant
> phandles for different classes of devices, so the "HW prober" code
> needs to either search through the whole device tree for a status of
> "failed-needs-probe" or needs to contain per-board, hardcoded,
> fully-qualified paths.
>
> I don't think we want to include hardcoded, fully-qualified paths in
> the code. That would mean that if someone changed a node name
> somewhere in the path to one of the devices that we're dealing with
> then it would break.
Right, nothing should depend on the full path. That's not an ABI just
like the device path in sysfs is not (despite what Android HALs do).
> So if we're searching the whole device tree for "failed-needs-probe"
> then we need to figure out which devices are related to each other. If
> a given board has second sources for MIPI panels, touchscreens, and
> trackpads then we need to know which of the "failed-needs-probe"
> devices are trackpads, which are touchscreens, and which are MIPI
> panels. Do you have any suggestions for how we should do that? Maybe
> it was in some other thread that I missed? I guess we could have a
> board-specific table mapping (compatible + node name + reg) to a
> class, but that feels awkward.
Node name is supposed to correspond to device class, so why not use
that (no path or unit-address.) and nothing else (well, besides
"status")?
Rob
^ permalink raw reply
* [PATCH v2] Input: atkbd - Skip ATKBD_CMD_GETID in translated mode
From: Hans de Goede @ 2023-11-15 17:46 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Hans de Goede, linux-input, Shang Ye, gurevitch, Egor Ignatov,
Anton Zhilyaev
There have been multiple reports of keyboard issues on recent laptop models
which can be worked around by setting i8042.dumbkbd, with the downside
being this breaks the capslock LED.
It seems that these issues are caused by recent laptops getting confused by
ATKBD_CMD_GETID. Rather then adding and endless growing list of quirks for
this, just skip ATKBD_CMD_GETID alltogether on laptops in translated mode.
The main goal of sending ATKBD_CMD_GETID is to skip binding to ps/2
mice/touchpads and those are never used in translated mode.
Examples of laptop models which benefit from skipping ATKBD_CMD_GETID:
* "HP Laptop 15s-fq2xxx", "HP laptop 15s-fq4xxx" and "HP Laptop 15-dy2xxx"
models the kbd stops working for the first 2 - 5 minutes after boot
(waiting for EC watchdog reset?)
* On "HP Spectre x360 13-aw2xxx" atkbd fails to probe the keyboard
* At least 9 different Lenovo models have issues with ATKBD_CMD_GETID, see:
https://github.com/yescallop/atkbd-nogetid
This has been tested on:
1. A MSI B550M PRO-VDH WIFI desktop, where the i8042 controller is not
in translated mode when no keyboard is plugged in and with a ps/2 kbd
a "AT Translated Set 2 keyboard" /dev/input/event# node shows up
2. A Lenovo ThinkPad X1 Yoga gen 8 (always has a translated set 2 keyboard)
Reported-by: Shang Ye <yesh25@mail2.sysu.edu.cn>
Closes: https://lore.kernel.org/linux-input/886D6167733841AE+20231017135318.11142-1-yesh25@mail2.sysu.edu.cn/
Closes: https://github.com/yescallop/atkbd-nogetid
Reported-by: gurevitch <mail@gurevit.ch>
Closes: https://lore.kernel.org/linux-input/2iAJTwqZV6lQs26cTb38RNYqxvsink6SRmrZ5h0cBUSuf9NT0tZTsf9fEAbbto2maavHJEOP8GA1evlKa6xjKOsaskDhtJWxjcnrgPigzVo=@gurevit.ch/
Reported-by: Egor Ignatov <egori@altlinux.org>
Closes: https://lore.kernel.org/all/20210609073333.8425-1-egori@altlinux.org/
Reported-by: Anton Zhilyaev <anton@cpp.in>
Closes: https://lore.kernel.org/linux-input/20210201160336.16008-1-anton@cpp.in/
Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2086156
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Note this supersedes my previous atkbd series:
https://lore.kernel.org/linux-input/20231005201544.26983-1-hdegoede@redhat.com/
---
Changes in v2:
- Add DMI check for laptop chassis types and only skip ATKBD_CMD_GETID
on laptops with the i8042 in translated mode
---
drivers/input/keyboard/atkbd.c | 61 +++++++++++++++++++++++++++++++---
1 file changed, 57 insertions(+), 4 deletions(-)
diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
index c92e544c792d..5667f1e80839 100644
--- a/drivers/input/keyboard/atkbd.c
+++ b/drivers/input/keyboard/atkbd.c
@@ -765,6 +765,59 @@ static void atkbd_deactivate(struct atkbd *atkbd)
ps2dev->serio->phys);
}
+#ifdef CONFIG_X86
+static const struct dmi_system_id atkbd_dmi_laptop_table[] = {
+ {
+ .matches = {
+ DMI_EXACT_MATCH(DMI_CHASSIS_TYPE, "8"), /* Portable */
+ },
+ },
+ {
+ .matches = {
+ DMI_EXACT_MATCH(DMI_CHASSIS_TYPE, "9"), /* Laptop */
+ },
+ },
+ {
+ .matches = {
+ DMI_EXACT_MATCH(DMI_CHASSIS_TYPE, "10"), /* Notebook */
+ },
+ },
+ {
+ .matches = {
+ DMI_EXACT_MATCH(DMI_CHASSIS_TYPE, "14"), /* Sub-Notebook */
+ },
+ },
+ {
+ .matches = {
+ DMI_EXACT_MATCH(DMI_CHASSIS_TYPE, "31"), /* Convertible */
+ },
+ },
+ {
+ .matches = {
+ DMI_EXACT_MATCH(DMI_CHASSIS_TYPE, "32"), /* Detachable */
+ },
+ },
+ { }
+};
+
+/*
+ * On many modern laptops ATKBD_CMD_GETID may cause problems, on these laptops
+ * the controller is always in translated mode. In this mode mice/touchpads will
+ * not work. So in this case simply assume a keyboard is connected to avoid
+ * confusing some laptop keyboards.
+ *
+ * Skipping ATKBD_CMD_GETID ends up using a fake keyboard id. Using a fake id is
+ * ok in translated mode, only atkbd_select_set() checks atkbd->id and in
+ * translated mode that is a no-op.
+ */
+static bool atkbd_skip_getid(struct atkbd *atkbd)
+{
+ return atkbd->translated && dmi_check_system(atkbd_dmi_laptop_table);
+}
+#else
+static inline bool atkbd_skip_getid(struct atkbd *atkbd) { return false; }
+#endif
+
/*
* atkbd_probe() probes for an AT keyboard on a serio port.
*/
@@ -794,12 +847,12 @@ static int atkbd_probe(struct atkbd *atkbd)
*/
param[0] = param[1] = 0xa5; /* initialize with invalid values */
- if (ps2_command(ps2dev, param, ATKBD_CMD_GETID)) {
+ if (atkbd_skip_getid(atkbd) || ps2_command(ps2dev, param, ATKBD_CMD_GETID)) {
/*
- * If the get ID command failed, we check if we can at least set the LEDs on
- * the keyboard. This should work on every keyboard out there. It also turns
- * the LEDs off, which we want anyway.
+ * If the get ID command was skipped or failed, we check if we can at least set
+ * the LEDs on the keyboard. This should work on every keyboard out there.
+ * It also turns the LEDs off, which we want anyway.
*/
param[0] = 0;
if (ps2_command(ps2dev, param, ATKBD_CMD_SETLEDS))
--
2.41.0
^ permalink raw reply related
* Re: [PATCH] Input: atkbd - Skip ATKBD_CMD_GETID in translated mode
From: Hans de Goede @ 2023-11-15 17:45 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input, Shang Ye, gurevitch, Egor Ignatov, Anton Zhilyaev
In-Reply-To: <ZVOZUa1i9dQfm76M@google.com>
Hi Dmitry,
Thank you for the review.
On 11/14/23 16:59, Dmitry Torokhov wrote:
> Hi Hans,
>
> On Mon, Nov 06, 2023 at 04:54:29PM +0100, Hans de Goede wrote:
>> There have been multiple reports of keyboard issues on recent laptop models
>> which can be worked around by setting i8042.dumbkbd, with the downside
>> being this breaks the capslock LED.
>>
>> It seems that these issues are caused by recent laptops getting confused by
>> ATKBD_CMD_GETID. Rather then adding and endless growing list of quirks for
>> this, lets just skip ATKBD_CMD_GETID alltogether when in translated mode.
>>
>> The main goal of sending ATKBD_CMD_GETID is to skip binding to ps/2
>> mice/touchpads and those are never used in translated mode.
>>
>> Examples of laptop models which benefit from skipping ATKBD_CMD_GETID:
>>
>> * "HP Laptop 15s-fq2xxx", "HP laptop 15s-fq4xxx" and "HP Laptop 15-dy2xxx"
>> models the kbd stops working for the first 2 - 5 minutes after boot
>> (waiting for EC watchdog reset?)
>>
>> * On "HP Spectre x360 13-aw2xxx" atkbd fails to probe the keyboard
>>
>> * At least 9 different Lenovo models have issues with ATKBD_CMD_GETID, see:
>> https://github.com/yaescallop/atkbd-nogetid
>>
>> Note this also removes the "NCD terminal keyboards are only supported on
>> non-translating controllers." warning since that code is now unreachable.
>>
>> This has been tested on:
>>
>> 1. A MSI B550M PRO-VDH WIFI desktop, where the i8042 controller is not
>> in translated mode when no keyboard is plugged in and with a ps/2 kbd
>> a "AT Translated Set 2 keyboard" /dev/input/event# node shows up
>>
>> 2. A Dell Latitude 9420 (always has a "AT Translated Set 2 keyboard")
>>
>> 3. A Lenovo ThinkPad X1 Yoga gen 8 (idem)
>
> I agree that the mice/touchpads are not going to work if the controller
> is in translated mode, however I wonder if on a device with external
> PS/2 ports we could not end up with a port in translated mode with
> "wrong" device plugged in.
>
> Can we consider not skipping the check completely, but rather use DMI to
> check the chassis type (we already have a similar check in 8042)
> and skip ATKBD_CMD_GETID on mobile devices, but still try
> ATKBD_CMD_SETLEDS on them?
I think that should work. At least the patches from:
https://github.com/yescallop/atkbd-nogetid
for the affected Lenovo models to exactly that and from my (remote)
debugging of the issue on one of the HP laptops I expect it to work
fine there too.
I've prepared a v2 implementing this and I'll send v2 out
right after this email.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH RESEND] Input: synaptics: enable InterTouch for ThinkPad L14 G1
From: Dmitry Torokhov @ 2023-11-15 16:57 UTC (permalink / raw)
To: José Pekkarinen
Cc: skhan, rrangel, jefferymiller, linux-input, linux-kernel-mentees
In-Reply-To: <20231114063607.71772-1-jose.pekkarinen@foxhound.fi>
On Tue, Nov 14, 2023 at 08:36:07AM +0200, José Pekkarinen wrote:
> Observed on dmesg of my laptop I see the following
> output:
>
> [ 19.898700] psmouse serio1: synaptics: queried max coordinates: x [..5678], y [..4694]
> [ 19.936057] psmouse serio1: synaptics: queried min coordinates: x [1266..], y [1162..]
> [ 19.936076] psmouse serio1: synaptics: Your touchpad (PNP: LEN0411 PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-input@vger.kernel.org.
> [ 20.008901] psmouse serio1: synaptics: Touchpad model: 1, fw: 10.32, id: 0x1e2a1, caps: 0xf014a3/0x940300/0x12e800/0x500000, board id: 3471, fw id: 2909640
> [ 20.008925] psmouse serio1: synaptics: serio: Synaptics pass-through port at isa0060/serio1/input0
> [ 20.053344] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input7
> [ 20.397608] mousedev: PS/2 mouse device common for all mice
>
> This patch will add its pnp id to the smbus list to
> produce the setup of intertouch for the device.
>
> Signed-off-by: José Pekkarinen <jose.pekkarinen@foxhound.fi>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] dt-bindings: input: samsung,s6sy761: convert to DT schema
From: Dmitry Torokhov @ 2023-11-15 16:30 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andi Shyti,
linux-input, devicetree, linux-kernel
In-Reply-To: <20231111143221.55452-1-krzysztof.kozlowski@linaro.org>
On Sat, Nov 11, 2023 at 03:32:21PM +0100, Krzysztof Kozlowski wrote:
> Convert Samsung S6SY761 touchscreen controller bindings to DT schema.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v1 1/1] treewide, spi: Get rid of SPI_MASTER_HALF_DUPLEX
From: Dmitry Torokhov @ 2023-11-15 16:28 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Cameron, Yang Yingliang, Greg Kroah-Hartman, Mark Brown,
linux-input, linux-kernel, linux-mmc, netdev, linux-usb,
linux-spi, Ulf Hansson, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
In-Reply-To: <20231113111249.3982461-1-andriy.shevchenko@linux.intel.com>
On Mon, Nov 13, 2023 at 01:12:49PM +0200, Andy Shevchenko wrote:
> The SPI_MASTER_HALF_DUPLEX is the legacy name of a definition
> for a half duplex flag. Since all others had been replaced with
> the respective SPI_CONTROLLER prefix get rid of the last one
> as well. There is no functional change intended.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> # for input
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v1 1/1] treewide, spi: Get rid of SPI_MASTER_HALF_DUPLEX
From: Ulf Hansson @ 2023-11-15 15:37 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Cameron, Yang Yingliang, Greg Kroah-Hartman, Mark Brown,
linux-input, linux-kernel, linux-mmc, netdev, linux-usb,
linux-spi, Dmitry Torokhov, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
In-Reply-To: <20231113111249.3982461-1-andriy.shevchenko@linux.intel.com>
On Mon, 13 Nov 2023 at 12:15, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> The SPI_MASTER_HALF_DUPLEX is the legacy name of a definition
> for a half duplex flag. Since all others had been replaced with
> the respective SPI_CONTROLLER prefix get rid of the last one
> as well. There is no functional change intended.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # For MMC
> ---
> drivers/input/rmi4/rmi_spi.c | 2 +-
> drivers/mmc/host/mmc_spi.c | 2 +-
> drivers/net/ethernet/micrel/ks8851_spi.c | 4 ++--
> drivers/usb/gadget/udc/max3420_udc.c | 2 +-
> include/linux/spi/spi.h | 2 --
> 5 files changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/input/rmi4/rmi_spi.c b/drivers/input/rmi4/rmi_spi.c
> index 852aeb0b2c07..07c866f42296 100644
> --- a/drivers/input/rmi4/rmi_spi.c
> +++ b/drivers/input/rmi4/rmi_spi.c
> @@ -375,7 +375,7 @@ static int rmi_spi_probe(struct spi_device *spi)
> struct rmi_device_platform_data *spi_pdata = spi->dev.platform_data;
> int error;
>
> - if (spi->master->flags & SPI_MASTER_HALF_DUPLEX)
> + if (spi->master->flags & SPI_CONTROLLER_HALF_DUPLEX)
> return -EINVAL;
>
> rmi_spi = devm_kzalloc(&spi->dev, sizeof(struct rmi_spi_xport),
> diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
> index cc333ad67cac..b0cccef4cfbf 100644
> --- a/drivers/mmc/host/mmc_spi.c
> +++ b/drivers/mmc/host/mmc_spi.c
> @@ -1322,7 +1322,7 @@ static int mmc_spi_probe(struct spi_device *spi)
> /* We rely on full duplex transfers, mostly to reduce
> * per-transfer overheads (by making fewer transfers).
> */
> - if (spi->master->flags & SPI_MASTER_HALF_DUPLEX)
> + if (spi->master->flags & SPI_CONTROLLER_HALF_DUPLEX)
> return -EINVAL;
>
> /* MMC and SD specs only seem to care that sampling is on the
> diff --git a/drivers/net/ethernet/micrel/ks8851_spi.c b/drivers/net/ethernet/micrel/ks8851_spi.c
> index 70bc7253454f..7c41623dac90 100644
> --- a/drivers/net/ethernet/micrel/ks8851_spi.c
> +++ b/drivers/net/ethernet/micrel/ks8851_spi.c
> @@ -156,7 +156,7 @@ static void ks8851_rdreg(struct ks8851_net *ks, unsigned int op,
>
> txb[0] = cpu_to_le16(op | KS_SPIOP_RD);
>
> - if (kss->spidev->master->flags & SPI_MASTER_HALF_DUPLEX) {
> + if (kss->spidev->master->flags & SPI_CONTROLLER_HALF_DUPLEX) {
> msg = &kss->spi_msg2;
> xfer = kss->spi_xfer2;
>
> @@ -180,7 +180,7 @@ static void ks8851_rdreg(struct ks8851_net *ks, unsigned int op,
> ret = spi_sync(kss->spidev, msg);
> if (ret < 0)
> netdev_err(ks->netdev, "read: spi_sync() failed\n");
> - else if (kss->spidev->master->flags & SPI_MASTER_HALF_DUPLEX)
> + else if (kss->spidev->master->flags & SPI_CONTROLLER_HALF_DUPLEX)
> memcpy(rxb, trx, rxl);
> else
> memcpy(rxb, trx + 2, rxl);
> diff --git a/drivers/usb/gadget/udc/max3420_udc.c b/drivers/usb/gadget/udc/max3420_udc.c
> index 2d57786d3db7..89e8cf2a2a7d 100644
> --- a/drivers/usb/gadget/udc/max3420_udc.c
> +++ b/drivers/usb/gadget/udc/max3420_udc.c
> @@ -1201,7 +1201,7 @@ static int max3420_probe(struct spi_device *spi)
> int err, irq;
> u8 reg[8];
>
> - if (spi->master->flags & SPI_MASTER_HALF_DUPLEX) {
> + if (spi->master->flags & SPI_CONTROLLER_HALF_DUPLEX) {
> dev_err(&spi->dev, "UDC needs full duplex to work\n");
> return -EINVAL;
> }
> diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
> index 255a0562aea5..7b4baff63c5c 100644
> --- a/include/linux/spi/spi.h
> +++ b/include/linux/spi/spi.h
> @@ -1638,8 +1638,6 @@ spi_transfer_is_last(struct spi_controller *ctlr, struct spi_transfer *xfer)
> /* Compatibility layer */
> #define spi_master spi_controller
>
> -#define SPI_MASTER_HALF_DUPLEX SPI_CONTROLLER_HALF_DUPLEX
> -
> #define spi_master_get_devdata(_ctlr) spi_controller_get_devdata(_ctlr)
> #define spi_master_set_devdata(_ctlr, _data) \
> spi_controller_set_devdata(_ctlr, _data)
> --
> 2.43.0.rc1.1.gbec44491f096
>
^ permalink raw reply
* Re: Requesting your attention and expertise regarding a Tablet/Kernel issue
From: Benjamin Tissoires @ 2023-11-15 15:14 UTC (permalink / raw)
To: David Revoy
Cc: José Expósito, Eric GOUYER, Illia Ostapyshyn, jkosina,
jason.gerecke, linux-input, linux-kernel
In-Reply-To: <CAO-hwJ+jwmTE-v7FsPi3f70mB8SqUha7Ek9DtptZ0auiFpGM7w@mail.gmail.com>
Hi David,
On Tue, Nov 14, 2023 at 3:35 PM Benjamin Tissoires
<benjamin.tissoires@redhat.com> wrote:
[...]
> > > Could you please once again attach the hid-recorder of the Pro 24
> > > while doing the following sequence:
> > > - touch with the tip of the stylus the tablet
> > > - while touching, press the upper button (the problematic one)
> > > - still while touching, release the button
> > > - remove the stylus
> >
> > Sure, you'll find the action (repeated three times) recorded here [2]
>
> Thanks a lot. However, I realized this morning 2 issues (sorry):
> - you made the recording while the HID-BPF program was attached, which
> is now obvious that anyone would do that. But the program sometimes
> discards events, so I am not sure now if sometimes the device is not
> sending the spurious events, or if the filter was acting correctly.
> (Note to self, next time, while in the testing phase, do not blindly
> discard the events, but remap them to an ignored report)
> - that device is really "interesting" in how it behaves with the
> eraser mode emulation: when you press the second button while touching
> the pen, we get a spurious release of the touch event... And this
> leads me to think that I'm not sure about all of the transitions we
> can have with buttons :(
>
> TL;DR: there is still work to do for me and for you if you still agree
> to send me more traces.
>
I managed to refine the bpf filter. Assuming I am correct in what I
understand from the device, of course.
Also this time I made sure the original events are still around but
unprocessed by the input layer :)
So it would be nice if you could try the artifacts of job 51600738[4].
Again, download them (udev-hid-bpf_0.1.0-4-g5ab02ec.tar.xz), unpack,
sudo ./install --verbose, then unplug/replug the artist Pro 24.
Then, I'll need the following sequence (ideally repeated twice or
three times, given that your last record show a slight difference in
the first and second attempt):
- outside of the proximity of the sensor, press the upper button
- approach the stylus to the surface keeping the upper button pressed
- touch the surface with the tip while holding the upper button pressed
- release the upper button while keeping the tip pressed (like previously)
- press once again the upper button while keeping the tip touching the
surface (like previously)
- lift of the pen, keeping the upper button pressed, and still in
range of the sensor
- remove the pen from the proximity of the sensor entirely (move away
20 cm or so), while still keeping the upper button pressed
It's actually longer to describe than to execute :)
> >
> > > you could also give a test of the artifacts of job 51469284[3].
> > >
> > > The points to check are:
> > > - if you right click while touching the surface, do you still get only
> > > a right click or some weird glitches in addition to it?
> > > - if you right click while not touching (hovering), no glitches?
> >
> > I tested. It's a bit hard to tell if it causes glitches or if the
> > behavior is normal or not. I'm not using the right-click this way.
> > I always use it in "hover mode". With artifact or without, the
> > behavior is while the tip is pressed, the right-click quickly
> > 'disapear' but it is probably normal because I test on contextual
> > menu and clicking somewhere else makes this type of menu disapear.
>
> AFAICT you used the artifacts from job 51469284. Which is good. But as
> I mentioned above, the tablet is sending a spurious event I haven't
> anticipated, which results in a left click (well release/click) from
> the host point of view. And that very well explains the disappearance
> of the right-click menu.
I think I managed to remove the spurious release/click with the latest
udev-hid-bpf pipeline.
>
> >
> > I hope this will help,
>
> It does, but there are glitches that I'd like to fix. I need to iron
> out the bpf filter for those use cases. I rewrote the tests today to
> take those into account (assuming I understand the HW enough) and I
> think they are better now.
>
> But I would also totally understand that you had enough debugging and
> you would rather focus on using the tablets, instead of debugging
> them. In which case, someone else from the community might help me.
>
> Cheers,
> Benjamin
>
>
> > Cheers,
> >
> > David
> >
> > [1] https://www.davidrevoy.com/article1002/how-a-kernel-developer-made-my-styluses-work-again
> > [2] https://www.peppercarrot.com/extras/mailing-list/hid-records/XPPEN-Artist-24-Pro/XPPEN-Artist-24-Pro_pen_tip-contact-and-action-press-release-upper-stylus-button-x3.txt
> >
Cheers,
Benjamin
[4] https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/jobs/51600738
^ permalink raw reply
* [PATCH 11/32] hid/picolcd_fb: Set FBINFO_VIRTFB flag
From: Thomas Zimmermann @ 2023-11-15 10:19 UTC (permalink / raw)
To: deller, javierm
Cc: linux-fbdev, dri-devel, Thomas Zimmermann, Bruno Prémont,
Jiri Kosina, Benjamin Tissoires, linux-input
In-Reply-To: <20231115102954.7102-1-tzimmermann@suse.de>
The picolcd_fb driver operates on system memory. Mark the framebuffer
accordingly. Helpers operating on the framebuffer memory will test
for the presence of this flag.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: "Bruno Prémont" <bonbons@linux-vserver.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: linux-input@vger.kernel.org
---
drivers/hid/hid-picolcd_fb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/hid-picolcd_fb.c b/drivers/hid/hid-picolcd_fb.c
index a4dccdcda26fc..d7dddd99d325e 100644
--- a/drivers/hid/hid-picolcd_fb.c
+++ b/drivers/hid/hid-picolcd_fb.c
@@ -505,6 +505,7 @@ int picolcd_init_framebuffer(struct picolcd_data *data)
dev_err(dev, "can't get a free page for framebuffer\n");
goto err_nomem;
}
+ info->flags |= FBINFO_VIRTFB;
info->screen_buffer = fbdata->bitmap;
info->fix.smem_start = (unsigned long)fbdata->bitmap;
memset(fbdata->vbitmap, 0xff, PICOLCDFB_SIZE);
--
2.42.0
^ permalink raw reply related
* [PATCH] HID: wacom: Remove AES power_supply after extended inactivity
From: Tatsunosuke Tobita @ 2023-11-14 23:57 UTC (permalink / raw)
To: linux-input, Benjamin Tissoires, Jiri Kosina
Cc: Ping Cheng, Jason Gerecke, Aaron Armstrong Skomra, Joshua Dickens,
Tatsunosuke Tobita, Tatsunosuke Tobita, Jason Gerecke,
Aaron Skomra, Josh Dickens
Even if a user does not use their AES pen for an extended period,
the battery power supply attributes continue to exist.
This results in the desktop showing battery status for a pen
that is no longer in use and which may in fact be in a different
state (e.g. the user may be charging the pen).
To avoid confusion and ensure userspace has an accurate view
of the battery state, this patch automatically removes
the power_supply after 30 minutes of inactivity.
Signed-off-by: Tatsunosuke Tobita <tatsunosuke.tobita@wacom.com>
Reviewed-by: Jason Gerecke <Jason.Gerecke@wacom.com>
Reviewed-by: Aaron Skomra <aaron.skomra@wacom.com>
Reviewed-by: Josh Dickens <joshua.dickens@wacom.com>
---
drivers/hid/wacom.h | 1 +
drivers/hid/wacom_sys.c | 8 ++++++++
drivers/hid/wacom_wac.c | 12 +++++++++++-
drivers/hid/wacom_wac.h | 1 +
4 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/wacom.h b/drivers/hid/wacom.h
index 166a76c9bcad..77c5fb26cd14 100644
--- a/drivers/hid/wacom.h
+++ b/drivers/hid/wacom.h
@@ -164,6 +164,7 @@ struct wacom {
struct work_struct battery_work;
struct work_struct remote_work;
struct delayed_work init_work;
+ struct delayed_work aes_battery_work;
struct wacom_remote *remote;
struct work_struct mode_change_work;
struct timer_list idleprox_timer;
diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 3f704b8072e8..b613f11ed949 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -1813,6 +1813,13 @@ static void wacom_destroy_battery(struct wacom *wacom)
}
}
+static void wacom_aes_battery_handler(struct work_struct *work)
+{
+ struct wacom *wacom = container_of(work, struct wacom, aes_battery_work.work);
+
+ wacom_destroy_battery(wacom);
+}
+
static ssize_t wacom_show_speed(struct device *dev,
struct device_attribute
*attr, char *buf)
@@ -2794,6 +2801,7 @@ static int wacom_probe(struct hid_device *hdev,
mutex_init(&wacom->lock);
INIT_DELAYED_WORK(&wacom->init_work, wacom_init_work);
+ INIT_DELAYED_WORK(&wacom->aes_battery_work, wacom_aes_battery_handler);
INIT_WORK(&wacom->wireless_work, wacom_wireless_work);
INIT_WORK(&wacom->battery_work, wacom_battery_work);
INIT_WORK(&wacom->remote_work, wacom_remote_work);
diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index 471db78dbbf0..c205198ded11 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -2528,11 +2528,12 @@ static void wacom_wac_pen_report(struct hid_device *hdev,
struct input_dev *input = wacom_wac->pen_input;
bool range = wacom_wac->hid_data.inrange_state;
bool sense = wacom_wac->hid_data.sense_state;
+ bool entering_range = !wacom_wac->tool[0] && range;
if (wacom_wac->is_invalid_bt_frame)
return;
- if (!wacom_wac->tool[0] && range) { /* first in range */
+ if (entering_range) { /* first in range */
/* Going into range select tool */
if (wacom_wac->hid_data.invert_state)
wacom_wac->tool[0] = BTN_TOOL_RUBBER;
@@ -2583,6 +2584,15 @@ static void wacom_wac_pen_report(struct hid_device *hdev,
input_sync(input);
}
+ /* Handle AES battery timeout behavior */
+ if (wacom_wac->features.quirks & WACOM_QUIRK_AESPEN) {
+ if (entering_range)
+ cancel_delayed_work(&wacom->aes_battery_work);
+ if (!sense)
+ schedule_delayed_work(&wacom->aes_battery_work,
+ msecs_to_jiffies(WACOM_AES_BATTERY_TIMEOUT));
+ }
+
if (!sense) {
wacom_wac->tool[0] = 0;
wacom_wac->id[0] = 0;
diff --git a/drivers/hid/wacom_wac.h b/drivers/hid/wacom_wac.h
index 57e185f18d53..e63b1e806e34 100644
--- a/drivers/hid/wacom_wac.h
+++ b/drivers/hid/wacom_wac.h
@@ -14,6 +14,7 @@
#define WACOM_MAX_REMOTES 5
#define WACOM_STATUS_UNKNOWN 255
#define WACOM_REMOTE_BATTERY_TIMEOUT 21000000000ll
+#define WACOM_AES_BATTERY_TIMEOUT 1800000
/* packet length for individual models */
#define WACOM_PKGLEN_BBFUN 9
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v8 1/2] dt-bindings: input: bindings for Adafruit Seesaw Gamepad
From: Krzysztof Kozlowski @ 2023-11-14 20:32 UTC (permalink / raw)
To: Thomas Weißschuh, Anshul Dalal
Cc: linux-input, devicetree, Conor Dooley, Dmitry Torokhov,
linux-kernel, Conor Dooley, Rob Herring, Krzysztof Kozlowski,
Jeff LaBundy, linux-kernel-mentees
In-Reply-To: <0defc0e3-dc15-459d-9e71-64f3c38a6931@t-8ch.de>
On 14/11/2023 20:20, Thomas Weißschuh wrote:
> On 2023-11-08 06:23:35+0530, Anshul Dalal wrote:
>> Adds bindings for the Adafruit Seesaw Gamepad.
>>
>> The gamepad functions as an i2c device with the default address of 0x50
>> and has an IRQ pin that can be enabled in the driver to allow for a rising
>> edge trigger on each button press or joystick movement.
>>
>> Product page:
>> https://www.adafruit.com/product/5743
>> Arduino driver:
>> https://github.com/adafruit/Adafruit_Seesaw
>>
>> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>> Signed-off-by: Anshul Dalal <anshulusr@gmail.com>
>> ---
>>
>> Changes for v8:
>> - no updates
>>
>> Changes for v7:
>> - no updates
>>
>> Changes for v6:
>> - no updates
>>
>> Changes for v5:
>> - Added link to the datasheet
>>
>> Changes for v4:
>> - Fixed the URI for the id field
>> - Added `interrupts` property
>>
>> Changes for v3:
>> - Updated id field to reflect updated file name from previous version
>> - Added `reg` property
>>
>> Changes for v2:
>> - Renamed file to `adafruit,seesaw-gamepad.yaml`
>> - Removed quotes for `$id` and `$schema`
>> - Removed "Bindings for" from the description
>> - Changed node name to the generic name "joystick"
>> - Changed compatible to 'adafruit,seesaw-gamepad' instead of
>> 'adafruit,seesaw_gamepad'
>> ---
>> .../input/adafruit,seesaw-gamepad.yaml | 60 +++++++++++++++++++
>> 1 file changed, 60 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/input/adafruit,seesaw-gamepad.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/input/adafruit,seesaw-gamepad.yaml b/Documentation/devicetree/bindings/input/adafruit,seesaw-gamepad.yaml
>> new file mode 100644
>> index 000000000000..3f0d1c5a3b9b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/input/adafruit,seesaw-gamepad.yaml
>> @@ -0,0 +1,60 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/input/adafruit,seesaw-gamepad.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Adafruit Mini I2C Gamepad with seesaw
>> +
>> +maintainers:
>> + - Anshul Dalal <anshulusr@gmail.com>
>> +
>> +description: |
>> + Adafruit Mini I2C Gamepad
>> +
>> + +-----------------------------+
>> + | ___ |
>> + | / \ (X) |
>> + | | S | __ __ (Y) (A) |
>> + | \___/ |ST| |SE| (B) |
>> + | |
>> + +-----------------------------+
>> +
>> + S -> 10-bit percision bidirectional analog joystick
>> + ST -> Start
>> + SE -> Select
>> + X, A, B, Y -> Digital action buttons
>> +
>> + Datasheet: https://cdn-learn.adafruit.com/downloads/pdf/gamepad-qt.pdf
>> + Product page: https://www.adafruit.com/product/5743
>> + Arduino Driver: https://github.com/adafruit/Adafruit_Seesaw
>> +
>> +properties:
>> + compatible:
>> + const: adafruit,seesaw-gamepad
>
> I don't really have any clue about devicetree, but shouldn't the actual
> driver have an id-table for this "compatible"?
It should, why was it dropped?
>
> It had one up to v5 of the patchset.
>
> Jeff had some comments about the OF aspect [0], but to me the state now
> seems incorrect.
> Maybe the DT can be dropped completely?
>
> Jeff, could you advise?
>
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + interrupts:
>> + maxItems: 1
>> + description:
>> + The gamepad's IRQ pin triggers a rising edge if interrupts are enabled.
>
> Interrupts are not supported yet by the driver.
> Should the property be there already?
Bindings describe the hardware, no the driver. If the hardware has
interrupt line, it should be described here.
Best regards,
Krzysztof
^ 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