* Re: [PATCH RFC v5 0/6] ARM: pxa: GPIO descriptor conversions
From: Andy Shevchenko @ 2023-10-05 9:14 UTC (permalink / raw)
To: Duje Mihanović
Cc: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King,
Alan Stern, Greg Kroah-Hartman, Linus Walleij,
Bartosz Golaszewski, Dmitry Torokhov, Mark Brown,
linux-arm-kernel, linux-kernel, linux-usb, linux-gpio,
linux-input, linux-spi
In-Reply-To: <20231004-pxa-gpio-v5-0-d99ae6fceea8@skole.hr>
On Wed, Oct 04, 2023 at 04:56:24PM +0200, Duje Mihanović wrote:
> Hello,
>
> Small series to convert some of the board files in the mach-pxa directory
> to use the new GPIO descriptor interface.
>
> Most notably, the am200epd, am300epd and Spitz matrix keypad among
> others are not converted in this series.
Why is it still RFC?
I believe it's already good enough to be considered as a real material.
OTOH "RFT" might make sense. I'm not sure there are any users on the
planet Earth that have this Sharp device up and running with newest
kernels.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] HID: multitouch: Add required quirk for Synaptics 0xcd7e device
From: Rain @ 2023-10-05 2:33 UTC (permalink / raw)
To: Rahul Rameshbabu
Cc: Jiri Kosina, Benjamin Tissoires, Henrik Rydberg, linux-input,
linux-kernel
In-Reply-To: <8734ypls3y.fsf@protonmail.com>
On Wed, Oct 4, 2023, at 19:29, Rahul Rameshbabu wrote:
> On Wed, 04 Oct, 2023 12:01:27 -0700 "Rain" <rain@sunshowers.io> wrote:
>> On Sun, Sep 17, 2023, at 09:18, Rahul Rameshbabu wrote:
>>> Register the Synaptics device as a special multitouch device with certain
>>> quirks that may improve usability of the touchpad device.
>>>
>>> Reported-by: Rain <rain@sunshowers.io>
>>> Closes:
>>> https://lore.kernel.org/linux-input/2bbb8e1d-1793-4df1-810f-cb0137341ff4@app.fastmail.com/
>>> Signed-off-by: Rahul Rameshbabu <sergeantsagara@protonmail.com>
>>> ---
>>>
>>> Notes:
>>> Theory:
>>>
>>> I think the Synaptics device in the related email to the linux-input
>>> mailing list requires certain quirks like MT_QUIRK_HOVERING to correctly
>>> reconfigure the distance configuration for multitouch events. This might
>>> explain why light touches were not registered originally when
>>> MT_CLS_DEFAULT was used by default for the device. Would like to have
>>> this patch tested before being merged. A Tested-by: git trailer can then
>>> be appended.
>>>
>>> drivers/hid/hid-multitouch.c | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
>>> index 521b2ffb4244..8db4ae05febc 100644
>>> --- a/drivers/hid/hid-multitouch.c
>>> +++ b/drivers/hid/hid-multitouch.c
>>> @@ -2144,6 +2144,10 @@ static const struct hid_device_id mt_devices[] = {
>>> USB_DEVICE_ID_MTP_STM)},
>>>
>>> /* Synaptics devices */
>>> + { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT,
>>> + HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
>>> + USB_VENDOR_ID_SYNAPTICS, 0xcd7e) },
>>
>> Thanks for the patch! I haven't tested it yet but it looks promising.
>>
>> The vendor ID isn't USB_VENDOR_ID_SYNAPTICS (0x06cb),
>> however -- it's SYNA7DB5 (0x7db5) which I guess is an alternative vendor
>> ID for Synaptics. Would be worth fixing that.
>
> Hi Rain,
>
> I think you might be confusing the device name string with the vendor
> id, based on my interpretation of the output you shared.
>
> [ 2.034760] input: SYNA7DB5:00 06CB:CD7E Mouse as
> /devices/platform/AMDI0010:00/i2c-0/i2c-SYNA7DB5:00/0018:06CB:CD7E.0001/input/input1
> [ 2.034865] input: SYNA7DB5:00 06CB:CD7E Touchpad as
> /devices/platform/AMDI0010:00/i2c-0/i2c-SYNA7DB5:00/0018:06CB:CD7E.0001/input/input2
>
> The first column has a device name but what we are interested in is the
> second column, '06CB:CD7E'. 0x06CB is the vendor id and 0xCD7E is the
> device id. Hope that makes sense and let me know if you think this is
> off.
Ah, got it, thank you! I was definitely misreading what was going on and
was a bit thrown off by the "SYNA7DB5". Sorry about the confusion.
> In general for these types of issues, I think the right direction would
> be to make quirks loadable in userspace through HID-BPF where DEs or
> some systemd subsystem can help users load quirks needed for their HID
> devices rather than building a list of quirks in the driver. This is
> something I am interested in exploring.
That would definitely be very interesting.
Thanks again for the fix.
^ permalink raw reply
* Re: [PATCH] HID: multitouch: Add required quirk for Synaptics 0xcd7e device
From: Rahul Rameshbabu @ 2023-10-05 2:29 UTC (permalink / raw)
To: Rain
Cc: Jiri Kosina, Benjamin Tissoires, Henrik Rydberg, linux-input,
linux-kernel
In-Reply-To: <e0f33dd3-1a35-4c76-889f-a80e42da2ded@app.fastmail.com>
On Wed, 04 Oct, 2023 12:01:27 -0700 "Rain" <rain@sunshowers.io> wrote:
> On Sun, Sep 17, 2023, at 09:18, Rahul Rameshbabu wrote:
>> Register the Synaptics device as a special multitouch device with certain
>> quirks that may improve usability of the touchpad device.
>>
>> Reported-by: Rain <rain@sunshowers.io>
>> Closes:
>> https://lore.kernel.org/linux-input/2bbb8e1d-1793-4df1-810f-cb0137341ff4@app.fastmail.com/
>> Signed-off-by: Rahul Rameshbabu <sergeantsagara@protonmail.com>
>> ---
>>
>> Notes:
>> Theory:
>>
>> I think the Synaptics device in the related email to the linux-input
>> mailing list requires certain quirks like MT_QUIRK_HOVERING to correctly
>> reconfigure the distance configuration for multitouch events. This might
>> explain why light touches were not registered originally when
>> MT_CLS_DEFAULT was used by default for the device. Would like to have
>> this patch tested before being merged. A Tested-by: git trailer can then
>> be appended.
>>
>> drivers/hid/hid-multitouch.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
>> index 521b2ffb4244..8db4ae05febc 100644
>> --- a/drivers/hid/hid-multitouch.c
>> +++ b/drivers/hid/hid-multitouch.c
>> @@ -2144,6 +2144,10 @@ static const struct hid_device_id mt_devices[] = {
>> USB_DEVICE_ID_MTP_STM)},
>>
>> /* Synaptics devices */
>> + { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT,
>> + HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
>> + USB_VENDOR_ID_SYNAPTICS, 0xcd7e) },
>
> Thanks for the patch! I haven't tested it yet but it looks promising.
>
> The vendor ID isn't USB_VENDOR_ID_SYNAPTICS (0x06cb),
> however -- it's SYNA7DB5 (0x7db5) which I guess is an alternative vendor
> ID for Synaptics. Would be worth fixing that.
Hi Rain,
I think you might be confusing the device name string with the vendor
id, based on my interpretation of the output you shared.
[ 2.034760] input: SYNA7DB5:00 06CB:CD7E Mouse as /devices/platform/AMDI0010:00/i2c-0/i2c-SYNA7DB5:00/0018:06CB:CD7E.0001/input/input1
[ 2.034865] input: SYNA7DB5:00 06CB:CD7E Touchpad as /devices/platform/AMDI0010:00/i2c-0/i2c-SYNA7DB5:00/0018:06CB:CD7E.0001/input/input2
The first column has a device name but what we are interested in is the
second column, '06CB:CD7E'. 0x06CB is the vendor id and 0xCD7E is the
device id. Hope that makes sense and let me know if you think this is
off.
In general for these types of issues, I think the right direction would
be to make quirks loadable in userspace through HID-BPF where DEs or
some systemd subsystem can help users load quirks needed for their HID
devices rather than building a list of quirks in the driver. This is
something I am interested in exploring.
Thanks,
Rahul Rameshbabu
>
>> +
>> { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT,
>> HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
>> USB_VENDOR_ID_SYNAPTICS, 0xce08) },
>> --
>> 2.40.1
^ permalink raw reply
* Re: [PATCH] Input: elantech - fix fast_reconnect callback in ps2 mode
From: Jeffery Miller @ 2023-10-05 0:35 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Dmitry Torokhov, regressions, benjamin.tissoires, linux,
Andrew Duggan, Andrew Duggan, loic.poulain, linux-input,
linux-kernel
In-Reply-To: <2023100418-clapping-driven-bc09@gregkh>
On Wed, Oct 4, 2023 at 1:19 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> What commit id does this fix? Should it also have a cc: stable tag?
>
A crash was observed after commit 92e24e0e57f7 ("Input: psmouse - add
delay when deactivating for SMBus mode") which
is not in stable.
I don't think so. The underlying issue was introduced in commit
8eb92e5c9133 ("Input: psmouse - add support for SMBus companions") but
wasn't causing a noticed problem.
^ permalink raw reply
* [PATCH v2] Input: psmouse - fix fast_reconnect function for PS/2 mode
From: Jeffery Miller @ 2023-10-05 0:20 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-kernel, linux-input, Andrew Duggan, Andrew Duggan,
loic.poulain, linux, benjamin.tissoires, Jeffery Miller
Make elantech_setup_ps2 and synaptics_init_ps2 set an appropriate
fast_reconnect pointer when the PS/2 mode is used.
When the SMBus connection is attempted psmouse_smbus_init sets
the fast_reconnect pointer to psmouse_smbus_reconnect. When this fails
elantech_setup_ps2 and synaptics_init_ps2 will fallback to PS/2
mode replacing the psmouse private data.
This was causing an issue on resume since psmouse_smbus_reconnect was
being called while in PS/2 mode and attempting to use the invalid
private data.
This issue was uncovered when psmouse_smbus_reconnect started attempting
to use more of the data structure.
Reported-by: Thorsten Leemhuis <linux@leemhuis.info>
Closes: https://lore.kernel.org/all/ca0109fa-c64b-43c1-a651-75b294d750a1@leemhuis.info/
Fixes: 92e24e0e57f7 ("Input: psmouse - add delay when deactivating for SMBus mode")
Tested-by: Thorsten Leemhuis <linux@leemhuis.info>
Signed-off-by: Jeffery Miller <jefferymiller@google.com>
---
The other callbacks set in psmouse_smbus_init are already replaced.
Changes in v2:
- Also set fast_reconnect in the synaptics ps2 fallback path from review
comments.
- Add Fixes: tag to the commit that uncovered the problem.
drivers/input/mouse/elantech.c | 1 +
drivers/input/mouse/synaptics.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index 2118b2075f43..4e38229404b4 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -2114,6 +2114,7 @@ static int elantech_setup_ps2(struct psmouse *psmouse,
psmouse->protocol_handler = elantech_process_byte;
psmouse->disconnect = elantech_disconnect;
psmouse->reconnect = elantech_reconnect;
+ psmouse->fast_reconnect = NULL;
psmouse->pktsize = info->hw_version > 1 ? 6 : 4;
return 0;
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index ada299ec5bba..cefc74b3b34b 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -1623,6 +1623,7 @@ static int synaptics_init_ps2(struct psmouse *psmouse,
psmouse->set_rate = synaptics_set_rate;
psmouse->disconnect = synaptics_disconnect;
psmouse->reconnect = synaptics_reconnect;
+ psmouse->fast_reconnect = NULL;
psmouse->cleanup = synaptics_reset;
/* Synaptics can usually stay in sync without extra help */
psmouse->resync_time = 0;
--
2.42.0.582.g8ccd20d70d-goog
^ permalink raw reply related
* Re: [PATCH] Input: elantech - fix fast_reconnect callback in ps2 mode
From: Jeffery Miller @ 2023-10-05 0:13 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: regressions, benjamin.tissoires, linux, Andrew Duggan,
Andrew Duggan, loic.poulain, Greg Kroah-Hartman, linux-input,
linux-kernel
In-Reply-To: <ZR1yUFJ8a9Zt606N@penguin>
Dmitry,
On Wed, Oct 4, 2023 at 9:11 AM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> In fact, now that I think about it more, we should rework the original
> patch that added the delay, so that we do not wait these 30 msec in the
> "fast" reconnect handler. It turns out your original approach was
> better, but we should not be using retries, but rather the existing
> reset_delay_ms already defined in rmi platform data. I would appreciate
> if you try the draft patch at the end of this email (to be applied after
> reverting your original one adding the delay in psmouse-smbus.c).
I tested the draft patch and it works. I did revert the previous delay
patch while testing it.
>
> I think we need a similar change in synaptics.c as that one also can
> fall back to PS/2 mode.
>
Ah, good point, yes it does appear this needs to be done as well.
I have tested and will post an new version of the patch to include
the fix in synaptics.c as well.
Thanks,
Jeff
^ permalink raw reply
* [PATCH] platform/x86: touchscreen_dmi: Add info for the Positivo C4128B
From: Renan Guilherme Lebre Ramos @ 2023-10-04 23:59 UTC (permalink / raw)
To: linux-input, hdegoede; +Cc: Renan Guilherme Lebre Ramos
Add information for the Positivo C4128B, a notebook/tablet convertible.
Link: https://github.com/onitake/gsl-firmware/pull/217
Signed-off-by: Renan Guilherme Lebre Ramos <japareaggae@gmail.com>
---
drivers/platform/x86/touchscreen_dmi.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/platform/x86/touchscreen_dmi.c b/drivers/platform/x86/touchscreen_dmi.c
index f9301a9382e7..0f6b30285381 100644
--- a/drivers/platform/x86/touchscreen_dmi.c
+++ b/drivers/platform/x86/touchscreen_dmi.c
@@ -756,6 +756,21 @@ static const struct ts_dmi_data pipo_w11_data = {
.properties = pipo_w11_props,
};
+static const struct property_entry positivo_c4128b_props[] = {
+ PROPERTY_ENTRY_U32("touchscreen-min-x", 4),
+ PROPERTY_ENTRY_U32("touchscreen-min-y", 13),
+ PROPERTY_ENTRY_U32("touchscreen-size-x", 1915),
+ PROPERTY_ENTRY_U32("touchscreen-size-y", 1269),
+ PROPERTY_ENTRY_STRING("firmware-name", "gsl1680-positivo-c4128b.fw"),
+ PROPERTY_ENTRY_U32("silead,max-fingers", 10),
+ { }
+};
+
+static const struct ts_dmi_data positivo_c4128b_data = {
+ .acpi_name = "MSSL1680:00",
+ .properties = positivo_c4128b_props,
+};
+
static const struct property_entry pov_mobii_wintab_p800w_v20_props[] = {
PROPERTY_ENTRY_U32("touchscreen-min-x", 32),
PROPERTY_ENTRY_U32("touchscreen-min-y", 16),
@@ -1480,6 +1495,14 @@ const struct dmi_system_id touchscreen_dmi_table[] = {
DMI_MATCH(DMI_BIOS_VERSION, "MOMO.G.WI71C.MABMRBA02"),
},
},
+ {
+ /* Positivo C4128B */
+ .driver_data = (void *)&positivo_c4128b_data,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Positivo Tecnologia SA"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "C4128B-1"),
+ },
+ },
{
/* Point of View mobii wintab p800w (v2.0) */
.driver_data = (void *)&pov_mobii_wintab_p800w_v20_data,
--
2.42.0
^ permalink raw reply related
* Re: [PATCH] hid: cp2112: Fix duplicate workqueue initialization
From: Jiri Kosina @ 2023-10-04 19:19 UTC (permalink / raw)
To: andriy.shevchenko@linux.intel.com
Cc: Danny Kaehn, benjamin.tissoires@redhat.com,
linux-input@vger.kernel.org, Ethan Twardy
In-Reply-To: <ZQwQDZD3Yj9JFgMz@smile.fi.intel.com>
On Thu, 21 Sep 2023, andriy.shevchenko@linux.intel.com wrote:
> On Wed, Sep 20, 2023 at 07:10:15PM +0000, Danny Kaehn wrote:
> > On Wed, 2023-09-20 at 16:04 +0300, Andy Shevchenko wrote:
> > > On Tue, Sep 19, 2023 at 04:22:45PM -0500, Danny Kaehn wrote:
> > > > Previously the cp2112 driver called INIT_DELAYED_WORK within
> > > > cp2112_gpio_irq_startup, resulting in duplicate initilizations of the
> > > > workqueue on subsequent IRQ startups following an initial request. This
> > > > resulted in a warning in set_work_data in workqueue.c, as well as a rare
> > > > NULL dereference within process_one_work in workqueue.c.
> > > >
> > > > Initialize the workqueue within _probe instead.
I have applied the patch now, thanks.
> > > Does it deserve a Fixes tag?
> >
> > I'm not sure -- it does technically fix 13de9cca514ed63604263cad87ca8cb36e9b6489
> > (HID: cp2112: add IRQ chip handling), but does not apply cleanly to that
> > revision (a.e. with git am)
From my very own direct experience I can assure you, that the Fixes: tag
is being heavily used outside of -stable process: e.g. by distros who
don't base on -stable on purpose.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: Add quirk to ignore the touchscreen battery on HP ENVY 15-eu0556ng
From: Jiri Kosina @ 2023-10-04 19:16 UTC (permalink / raw)
To: Fabian Vogt; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <4537226.LvFx2qVVIh@fabians-envy>
On Tue, 3 Oct 2023, Fabian Vogt wrote:
> Like various other devices using similar hardware, this model reports a
> perpetually empty battery (0-1%).
>
> Join the others and apply HID_BATTERY_QUIRK_IGNORE.
>
> Signed-off-by: Fabian Vogt <fabian@ritter-vogt.de>
> ---
> drivers/hid/hid-ids.h | 1 +
> drivers/hid/hid-input.c | 2 ++
> 2 files changed, 3 insertions(+)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 7e499992a793..e4d2dfd5d253 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -425,6 +425,7 @@
> #define I2C_DEVICE_ID_HP_SPECTRE_X360_13T_AW100 0x29F5
> #define I2C_DEVICE_ID_HP_SPECTRE_X360_14T_EA100_V1 0x2BED
> #define I2C_DEVICE_ID_HP_SPECTRE_X360_14T_EA100_V2 0x2BEE
> +#define I2C_DEVICE_ID_HP_ENVY_X360_15_EU0556NG 0x2D02
>
> #define USB_VENDOR_ID_ELECOM 0x056e
> #define USB_DEVICE_ID_ELECOM_BM084 0x0061
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index 0235cc1690a1..c8b20d44b147 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -409,6 +409,8 @@ static const struct hid_device_id hid_battery_quirks[] = {
> HID_BATTERY_QUIRK_IGNORE },
> { HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, I2C_DEVICE_ID_HP_SPECTRE_X360_14T_EA100_V2),
> HID_BATTERY_QUIRK_IGNORE },
> + { HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, I2C_DEVICE_ID_HP_ENVY_X360_15_EU0556NG),
> + HID_BATTERY_QUIRK_IGNORE },
> {}
Applied, thanks Fabian.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: intel-ish-hid: ipc: Disable and reenable ACPI GPE bit
From: Jiri Kosina @ 2023-10-04 19:14 UTC (permalink / raw)
To: Srinivas Pandruvada
Cc: benjamin.tissoires, linux-input, linux-kernel, Kai-Heng Feng
In-Reply-To: <20231003155332.1855569-1-srinivas.pandruvada@linux.intel.com>
On Tue, 3 Oct 2023, Srinivas Pandruvada wrote:
> The EHL (Elkhart Lake) based platforms provide a OOB (Out of band)
> service, which allows to wakup device when the system is in S5 (Soft-Off
> state). This OOB service can be enabled/disabled from BIOS settings. When
> enabled, the ISH device gets PME wake capability. To enable PME wakeup,
> driver also needs to enable ACPI GPE bit.
>
> On resume, BIOS will clear the wakeup bit. So driver need to re-enable it
> in resume function to keep the next wakeup capability. But this BIOS
> clearing of wakeup bit doesn't decrement internal OS GPE reference count,
> so this reenabling on every resume will cause reference count to overflow.
>
> So first disable and reenable ACPI GPE bit using acpi_disable_gpe().
>
> Fixes: 2e23a70edabe ("HID: intel-ish-hid: ipc: finish power flow for EHL OOB")
> Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> Closes: https://lore.kernel.org/lkml/CAAd53p4=oLYiH2YbVSmrPNj1zpMcfp=Wxbasb5vhMXOWCArLCg@mail.gmail.com/T/
> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> ---
> drivers/hid/intel-ish-hid/ipc/pci-ish.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> index 55cb25038e63..710fda5f19e1 100644
> --- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> +++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> @@ -133,6 +133,14 @@ static int enable_gpe(struct device *dev)
> }
> wakeup = &adev->wakeup;
>
> + /*
> + * Call acpi_disable_gpe(), so that reference count
> + * gpe_event_info->runtime_count doesn't overflow.
> + * When gpe_event_info->runtime_count = 0, the call
> + * to acpi_disable_gpe() simply return.
> + */
> + acpi_disable_gpe(wakeup->gpe_device, wakeup->gpe_number);
> +
> acpi_sts = acpi_enable_gpe(wakeup->gpe_device, wakeup->gpe_number);
> if (ACPI_FAILURE(acpi_sts)) {
> dev_err(dev, "enable ose_gpe failed\n");
Applied, thanks Srinivas.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: multitouch: Add required quirk for Synaptics 0xcd7e device
From: Rain @ 2023-10-04 19:01 UTC (permalink / raw)
To: Rahul Rameshbabu, Jiri Kosina, Benjamin Tissoires, Henrik Rydberg
Cc: linux-input, linux-kernel
In-Reply-To: <20230917161802.39716-1-sergeantsagara@protonmail.com>
On Sun, Sep 17, 2023, at 09:18, Rahul Rameshbabu wrote:
> Register the Synaptics device as a special multitouch device with certain
> quirks that may improve usability of the touchpad device.
>
> Reported-by: Rain <rain@sunshowers.io>
> Closes:
> https://lore.kernel.org/linux-input/2bbb8e1d-1793-4df1-810f-cb0137341ff4@app.fastmail.com/
> Signed-off-by: Rahul Rameshbabu <sergeantsagara@protonmail.com>
> ---
>
> Notes:
> Theory:
>
> I think the Synaptics device in the related email to the linux-input
> mailing list requires certain quirks like MT_QUIRK_HOVERING to correctly
> reconfigure the distance configuration for multitouch events. This might
> explain why light touches were not registered originally when
> MT_CLS_DEFAULT was used by default for the device. Would like to have
> this patch tested before being merged. A Tested-by: git trailer can then
> be appended.
>
> drivers/hid/hid-multitouch.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 521b2ffb4244..8db4ae05febc 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -2144,6 +2144,10 @@ static const struct hid_device_id mt_devices[] = {
> USB_DEVICE_ID_MTP_STM)},
>
> /* Synaptics devices */
> + { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT,
> + HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
> + USB_VENDOR_ID_SYNAPTICS, 0xcd7e) },
Thanks for the patch! I haven't tested it yet but it looks promising.
The vendor ID isn't USB_VENDOR_ID_SYNAPTICS (0x06cb),
however -- it's SYNA7DB5 (0x7db5) which I guess is an alternative vendor
ID for Synaptics. Would be worth fixing that.
> +
> { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT,
> HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
> USB_VENDOR_ID_SYNAPTICS, 0xce08) },
> --
> 2.40.1
--
Rain
(they/she)
^ permalink raw reply
* Re: [PATCH v5 RESEND] HID: nintendo: cleanup LED code
From: Jiri Kosina @ 2023-10-04 19:08 UTC (permalink / raw)
To: Martino Fontana
Cc: djogorchock, benjamin.tissoires, linux-input, linux-kernel
In-Reply-To: <20230924141547.11597-1-tinozzo123@gmail.com>
On Sun, 24 Sep 2023, Martino Fontana wrote:
> - Support player LED patterns up to 8 players.
> (Note that the behavior still consinsts in increasing the player number
> every time a controller is connected, never decreasing it. It should be
> as is described in https://bugzilla.kernel.org/show_bug.cgi?id=216225.
> However, any implementation here would stop making sense as soon as a
> non-Nintendo controller is connected, which is why I'm not bothering.)
>
> - Split part of `joycon_home_led_brightness_set` (which is called by hid)
> into `joycon_set_home_led` (which is what actually sets the LEDs), for
> consistency with player LEDs.
>
> - `joycon_player_led_brightness_set` won't try it to "determine which
> player led this is" anymore: it's already looking at every LED
> brightness value.
>
> - Instead of first registering the `led_classdev`, then attempting to set
> the LED and unregistering the `led_classdev` if it fails, first attempt
> to set the LED, then register the `led_classdev` only if it succeeds
> (the class is still filled up in either case).
>
> - If setting the player LEDs fails, still attempt setting the home LED.
> (I don't know there's a third party controller where this may actually
> happen, but who knows...)
>
> - Use `JC_NUM_LEDS` where appropriate instead of 4.
>
> - Print return codes in more places.
>
> - Use spinlock instead of mutex for `input_num`. Copy its value to a local
> variable, so that it can be unlocked immediately.
>
> - `input_num` starts counting from 0
>
> - Less holding of mutexes in general.
>
> Signed-off-by: Martino Fontana <tinozzo123@gmail.com>
> ---
> Changes for v2:
>
> Applied suggestions, commit message explains more stuff, restored `return ret`
> when `devm_led_classdev_register` fails (since all other hid drivers do this).
> If setting LED fails, `hid_warn` now explicitly says "skipping registration".
>
> Changes for v3 and v4:
>
> Fixed errors and warnings from test robot.
>
> Changes for v5:
>
> I thought that when connecting the controller on an actual Nintendo Switch,
> only the nth player LED would turn on, which is true... on Wii and Wii U.
> So I reverted that, and to compensate, now this supports the LED patterns
> up to 8 players.
>
> drivers/hid/hid-nintendo.c | 133 +++++++++++++++++++++----------------
> 1 file changed, 76 insertions(+), 57 deletions(-)
Applied, thank you.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v3] HID: nintendo: reinitialize USB Pro Controller after resuming from suspend
From: Jiri Kosina @ 2023-10-04 19:04 UTC (permalink / raw)
To: Martino Fontana
Cc: djogorchock, benjamin.tissoires, linux-input, linux-kernel
In-Reply-To: <20230924140927.9844-2-tinozzo123@gmail.com>
On Sun, 24 Sep 2023, Martino Fontana wrote:
> When suspending the computer, a Switch Pro Controller connected via USB will
> lose its internal status. However, because the USB connection was technically
> never lost, when resuming the computer, the driver will attempt to communicate
> with the controller as if nothing happened (and fail).
> Because of this, the user was forced to manually disconnect the controller
> (or to press the sync button on the controller to power it off), so that it
> can be re-initialized.
>
> With this patch, the controller will be automatically re-initialized after
> resuming from suspend.
>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=216233
>
> Signed-off-by: Martino Fontana <tinozzo123@gmail.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: lenovo: Detect quirk-free fw on cptkbd and stop applying workaround
From: Jiri Kosina @ 2023-10-04 19:02 UTC (permalink / raw)
To: Mikhail Khvainitski; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20230923231522.94060-2-me@khvoinitsky.org>
On Sun, 24 Sep 2023, Mikhail Khvainitski wrote:
> Built-in firmware of cptkbd handles scrolling by itself (when middle
> button is pressed) but with issues: it does not support horizontal and
> hi-res scrolling and upon middle button release it sends middle button
> click even if there was a scrolling event. Commit 3cb5ff0220e3 ("HID:
> lenovo: Hide middle-button press until release") workarounds last
> issue but it's impossible to workaround scrolling-related issues
> without firmware modification.
>
> Likely, Dennis Schneider has reverse engineered the firmware and
> provided an instruction on how to patch it [1]. However,
> aforementioned workaround prevents userspace (libinput) from knowing
> exact moment when middle button has been pressed down and performing
> "On-Button scrolling". This commit detects correctly-behaving patched
> firmware if cursor movement events has been received during middle
> button being pressed and stops applying workaround for this device.
>
> Link: https://hohlerde.org/rauch/en/elektronik/projekte/tpkbd-fix/ [1]
>
> Signed-off-by: Mikhail Khvainitski <me@khvoinitsky.org>
Applied to for-6.7/lenovo, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v3 0/3] HID: nvidia-shield: Fix the error handling path of shield_probe()
From: Jiri Kosina @ 2023-10-04 18:58 UTC (permalink / raw)
To: Rahul Rameshbabu
Cc: Benjamin Tissoires, Christophe JAILLET, kernel-janitors,
linux-input, linux-kernel
In-Reply-To: <20230918115432.30076-1-rrameshbabu@nvidia.com>
On Mon, 18 Sep 2023, Rahul Rameshbabu wrote:
> This series fixes some missing clean-up function calls in the error handling of
> the probe.
>
> Patch 1 and 2 fix some similar issues introduced in 2 different commits (hence 2
> patches)
>
> Patch 3 is an enhancement that creates a common function for cleaning up
> thunderstrike instances.
>
> Changes:
>
> v1->v2:
> - Add the LED_RETAIN_AT_SHUTDOWN flag to prevent
> led_classdev_unregister from trying to set the LED to off before a
> successful call to hid_hw_start.
> - Rename err_haptics label to err_ts_create to make the label name more
> accurate.
> - Re-order operations in thunderstrike_destroy to be in LIFO order with
> regards to the operations in thunderstrike_create.
> v2->v3:
> - Refactor thunderstrike_destroy to take a thunderstrike instance
> pointer as a parameter and prevent a variable from being unused
> in shield_probe.
>
> Link: https://lore.kernel.org/linux-input/cover.1693070958.git.christophe.jaillet@wanadoo.fr/
> Link: https://lore.kernel.org/linux-input/20230918041345.59859-1-rrameshbabu@nvidia.com/
>
> Notes from Rahul:
> - Thank you so much Christophe for these patches.
> - Sent v2 without accounting for the fact that thunderstrike_destroy in v1
> makes the thunderstrike instance in shield_probe unused. Tested v3 with W=1.
>
> Christophe JAILLET (3):
> HID: nvidia-shield: Fix a missing led_classdev_unregister() in the
> probe error handling path
> HID: nvidia-shield: Fix some missing function calls() in the probe
> error handling path
> HID: nvidia-shield: Introduce thunderstrike_destroy()
I have applied 1/3 and 2/3 to for-6.6/upstream-fixes and 3/3 to
for-6.7/nvidia-shield.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: multitouch: Add required quirk for Synaptics 0xcd7e device
From: Jiri Kosina @ 2023-10-04 18:54 UTC (permalink / raw)
To: Rahul Rameshbabu
Cc: Benjamin Tissoires, Henrik Rydberg, linux-input, linux-kernel,
Rain
In-Reply-To: <20230917161802.39716-1-sergeantsagara@protonmail.com>
On Sun, 17 Sep 2023, Rahul Rameshbabu wrote:
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multi
> touch.c
> index 521b2ffb4244..8db4ae05febc 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -2144,6 +2144,10 @@ static const struct hid_device_id mt_devices[] = {
> USB_DEVICE_ID_MTP_STM)},
>
> /* Synaptics devices */
> + { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT,
> + HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
> + USB_VENDOR_ID_SYNAPTICS, 0xcd7e) },
> +
> { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT,
> HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: nvidia-shield: Select POWER_SUPPLY Kconfig option
From: Jiri Kosina @ 2023-10-04 18:49 UTC (permalink / raw)
To: Rahul Rameshbabu; +Cc: Benjamin Tissoires, linux-input
In-Reply-To: <875y478ngn.fsf@nvidia.com>
On Mon, 18 Sep 2023, Rahul Rameshbabu wrote:
> >> Battery information reported by the driver depends on the power supply
> >> subsystem. Select the required subsystem when the HID_NVIDIA_SHIELD
> >> Kconfig option is enabled.
> >>
> >> Fixes: 3ab196f88237 ("HID: nvidia-shield: Add battery support for Thunderstrike")
> >> Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
> >> ---
> >> drivers/hid/Kconfig | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> >> index e11c1c803676..dc227f477601 100644
> >> --- a/drivers/hid/Kconfig
> >> +++ b/drivers/hid/Kconfig
> >> @@ -792,6 +792,7 @@ config HID_NVIDIA_SHIELD
> >> tristate "NVIDIA SHIELD devices"
> >> depends on USB_HID
> >> depends on BT_HIDP
> >> + select POWER_SUPPLY
> >
> > Is there a reason not to do it the standard way using 'depends on', and
> > not vice versa?
>
> I originally used 'depends on' for POWER_SUPPLY. I took a look at
> drivers/hid/Kconfig and saw that all modules that depended on
> POWER_SUPPLY in the hid subsystem used 'select' instead. I figured I
> should follow the trend.
You are right.
I still don't like the fact that we are forcefully selecting POWER_SUPPLY
like this, but that's a 6.7 material.
Appplied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH RESEND] Input: xpad - Add HyperX Clutch Gladiate Support
From: Nguyen, Max @ 2023-10-04 18:47 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: maxwell.nguyen, chris.toledanes, carl.ng, linux-input
In-Reply-To: <ZQfgV76yld8XGtG9@google.com>
On 9/17/2023 10:29 PM, Dmitry Torokhov wrote:
> On Fri, Sep 15, 2023 at 06:44:52PM -0700, HP Dev wrote:
>> Hi Dmitry,
>> That should be ok. Thanks again for your support.
> Great, applied, thank you.
Hi Dmitry,
What's the typical process for the patch to merge to the main branch
once it is applied? Just curious for future reference.
Also, should I reference this link for the latest?
https://github.com/torvalds/linux/blob/master/drivers/input/joystick/xpad.c
Regards, Max
^ permalink raw reply
* [PATCH v3] Input: powermate - fix use-after-free in powermate_config_complete
From: Javier Carrasco @ 2023-10-04 14:36 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input, linux-kernel, Javier Carrasco,
syzbot+0434ac83f907a1dbdd1e
syzbot has found a use-after-free bug [1] in the powermate driver. This
happens when the device is disconnected, which leads to a memory free
from the powermate_device struct.
When an asynchronous control message completes after the kfree and its
callback is invoked, the lock does not exist anymore and hence the bug.
Use usb_kill_urb() on pm->config to cancel any in-progress requests upon
device disconnection.
[1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Reported-by: syzbot+0434ac83f907a1dbdd1e@syzkaller.appspotmail.com
---
Changes in v3:
- Let usb_kill_urb on pm->irq where it is i.e. before unregistering the
device.
- Link to v2: https://lore.kernel.org/r/20230916-topic-powermate_use_after_free-v2-1-505f49019f2f@gmail.com
Changes in v2:
- Use usb_kill_urb() on pm->config upon device disconnection.
- Link to v1: https://lore.kernel.org/r/20230916-topic-powermate_use_after_free-v1-1-2ffa46652869@gmail.com
---
drivers/input/misc/powermate.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/misc/powermate.c b/drivers/input/misc/powermate.c
index c1c733a9cb89..db2ba89adaef 100644
--- a/drivers/input/misc/powermate.c
+++ b/drivers/input/misc/powermate.c
@@ -425,6 +425,7 @@ static void powermate_disconnect(struct usb_interface *intf)
pm->requires_update = 0;
usb_kill_urb(pm->irq);
input_unregister_device(pm->input);
+ usb_kill_urb(pm->config);
usb_free_urb(pm->irq);
usb_free_urb(pm->config);
powermate_free_buffers(interface_to_usbdev(intf), pm);
---
base-commit: cefc06e4de1477dbdc3cb2a91d4b1873b7797a5c
change-id: 20230916-topic-powermate_use_after_free-c703c7969c91
Best regards,
--
Javier Carrasco <javier.carrasco.cruz@gmail.com>
^ permalink raw reply related
* [PATCH RFC v5 6/6] input: ads7846: Move wait_for_sync() logic to driver
From: Duje Mihanović @ 2023-10-04 14:56 UTC (permalink / raw)
To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King,
Alan Stern, Greg Kroah-Hartman, Linus Walleij,
Bartosz Golaszewski, Andy Shevchenko, Dmitry Torokhov, Mark Brown
Cc: linux-arm-kernel, linux-kernel, linux-usb, linux-gpio,
linux-input, linux-spi, Duje Mihanović
In-Reply-To: <20231004-pxa-gpio-v5-0-d99ae6fceea8@skole.hr>
If this code is left in the board file, the sync GPIO would have to be
separated into another lookup table during conversion to the GPIO
descriptor API (which is also done in this patch).
The only user of this code (Sharp Spitz) is also converted in this
patch.
Suggested-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
---
arch/arm/mach-pxa/spitz.c | 12 ++----------
drivers/input/touchscreen/ads7846.c | 22 +++++++++++++++-------
include/linux/spi/ads7846.h | 1 -
3 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index 26ec29c9cd1b..e8bc0249b503 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -520,22 +520,12 @@ static inline void spitz_leds_init(void) {}
* SSP Devices
******************************************************************************/
#if defined(CONFIG_SPI_PXA2XX) || defined(CONFIG_SPI_PXA2XX_MODULE)
-static void spitz_ads7846_wait_for_hsync(void)
-{
- while (gpio_get_value(SPITZ_GPIO_HSYNC))
- cpu_relax();
-
- while (!gpio_get_value(SPITZ_GPIO_HSYNC))
- cpu_relax();
-}
-
static struct ads7846_platform_data spitz_ads7846_info = {
.model = 7846,
.vref_delay_usecs = 100,
.x_plate_ohms = 419,
.y_plate_ohms = 486,
.pressure_max = 1024,
- .wait_for_sync = spitz_ads7846_wait_for_hsync,
};
static struct gpiod_lookup_table spitz_ads7846_gpio_table = {
@@ -543,6 +533,8 @@ static struct gpiod_lookup_table spitz_ads7846_gpio_table = {
.table = {
GPIO_LOOKUP("gpio-pxa", SPITZ_GPIO_TP_INT,
"pendown", GPIO_ACTIVE_LOW),
+ GPIO_LOOKUP("gpio-pxa", SPITZ_GPIO_HSYNC,
+ "sync", GPIO_ACTIVE_LOW),
{ }
},
};
diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
index faea40dd66d0..139b0f3735d0 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -138,8 +138,7 @@ struct ads7846 {
void *filter_data;
int (*get_pendown_state)(void);
struct gpio_desc *gpio_pendown;
-
- void (*wait_for_sync)(void);
+ struct gpio_desc *sync;
};
enum ads7846_filter {
@@ -636,9 +635,15 @@ static const struct attribute_group ads784x_attr_group = {
};
/*--------------------------------------------------------------------------*/
-
-static void null_wait_for_sync(void)
+static void ads7846_wait_for_sync_gpio(struct ads7846 *ts)
{
+ if (!ts->sync)
+ return;
+ while (!gpiod_get_value(ts->sync))
+ cpu_relax();
+
+ while (gpiod_get_value(ts->sync))
+ cpu_relax();
}
static int ads7846_debounce_filter(void *ads, int data_idx, int *val)
@@ -803,7 +808,7 @@ static void ads7846_read_state(struct ads7846 *ts)
packet->last_cmd_idx = 0;
while (true) {
- ts->wait_for_sync();
+ ads7846_wait_for_sync_gpio(ts);
m = &ts->msg[msg_idx];
error = spi_sync(ts->spi, m);
@@ -1261,8 +1266,6 @@ static int ads7846_probe(struct spi_device *spi)
ts->penirq_recheck_delay_usecs =
pdata->penirq_recheck_delay_usecs;
- ts->wait_for_sync = pdata->wait_for_sync ? : null_wait_for_sync;
-
snprintf(ts->phys, sizeof(ts->phys), "%s/input0", dev_name(dev));
snprintf(ts->name, sizeof(ts->name), "ADS%d Touchscreen", ts->model);
@@ -1361,6 +1364,11 @@ static int ads7846_probe(struct spi_device *spi)
if (err)
return err;
+ ts->sync = devm_gpiod_get_optional(dev, "sync", GPIOD_IN);
+ if (IS_ERR(ts->sync))
+ return dev_err_probe(dev, PTR_ERR(ts->sync),
+ "Failed to get sync GPIO");
+
err = input_register_device(input_dev);
if (err)
return err;
diff --git a/include/linux/spi/ads7846.h b/include/linux/spi/ads7846.h
index a04c1c34c344..fa7c4f119023 100644
--- a/include/linux/spi/ads7846.h
+++ b/include/linux/spi/ads7846.h
@@ -38,7 +38,6 @@ struct ads7846_platform_data {
int gpio_pendown_debounce; /* platform specific debounce time for
* the gpio_pendown */
int (*get_pendown_state)(void);
- void (*wait_for_sync)(void);
bool wakeup;
unsigned long irq_flags;
};
--
2.42.0
^ permalink raw reply related
* [PATCH RFC v5 1/6] ARM: pxa: Convert Spitz OHCI to GPIO descriptors
From: Duje Mihanović @ 2023-10-04 14:56 UTC (permalink / raw)
To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King,
Alan Stern, Greg Kroah-Hartman, Linus Walleij,
Bartosz Golaszewski, Andy Shevchenko, Dmitry Torokhov, Mark Brown
Cc: linux-arm-kernel, linux-kernel, linux-usb, linux-gpio,
linux-input, linux-spi, Duje Mihanović
In-Reply-To: <20231004-pxa-gpio-v5-0-d99ae6fceea8@skole.hr>
Sharp's Spitz board still uses the legacy GPIO interface for controlling
a GPIO pin related to the USB host controller.
Convert this function to use the new GPIO descriptor interface.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
---
arch/arm/mach-pxa/spitz.c | 13 ++++++-------
drivers/usb/host/ohci-pxa27x.c | 7 +++++++
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index cc691b199429..535e2b2e997b 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -649,23 +649,22 @@ static inline void spitz_mmc_init(void) {}
* USB Host
******************************************************************************/
#if defined(CONFIG_USB_OHCI_HCD) || defined(CONFIG_USB_OHCI_HCD_MODULE)
+GPIO_LOOKUP_SINGLE(spitz_usb_host_gpio_table, "pxa27x-ohci", "gpio-pxa",
+ SPITZ_GPIO_USB_HOST, "usb-host", GPIO_ACTIVE_LOW);
+
static int spitz_ohci_init(struct device *dev)
{
- int err;
-
- err = gpio_request(SPITZ_GPIO_USB_HOST, "USB_HOST");
- if (err)
- return err;
+ gpiod_add_lookup_table(&spitz_usb_host_gpio_table);
/* Only Port 2 is connected, setup USB Port 2 Output Control Register */
UP2OCR = UP2OCR_HXS | UP2OCR_HXOE | UP2OCR_DPPDE | UP2OCR_DMPDE;
- return gpio_direction_output(SPITZ_GPIO_USB_HOST, 1);
+ return 0;
}
static void spitz_ohci_exit(struct device *dev)
{
- gpio_free(SPITZ_GPIO_USB_HOST);
+ gpiod_remove_lookup_table(&spitz_usb_host_gpio_table);
}
static struct pxaohci_platform_data spitz_ohci_platform_data = {
diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index 357d9aee38a3..876842b940c0 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -121,6 +121,7 @@ struct pxa27x_ohci {
void __iomem *mmio_base;
struct regulator *vbus[3];
bool vbus_enabled[3];
+ struct gpio_desc *usb_host;
};
#define to_pxa27x_ohci(hcd) (struct pxa27x_ohci *)(hcd_to_ohci(hcd)->priv)
@@ -447,6 +448,10 @@ static int ohci_hcd_pxa27x_probe(struct platform_device *pdev)
pxa_ohci = to_pxa27x_ohci(hcd);
pxa_ohci->clk = usb_clk;
pxa_ohci->mmio_base = (void __iomem *)hcd->regs;
+ pxa_ohci->usb_host = gpiod_get_optional(&pdev->dev, "usb-host", GPIOD_OUT_LOW);
+ if (IS_ERR(pxa_ohci->usb_host))
+ return dev_err_probe(&pdev->dev, PTR_ERR(pxa_ohci->usb_host),
+ "failed to get USB host GPIO\n");
for (i = 0; i < 3; ++i) {
char name[6];
@@ -512,6 +517,8 @@ static void ohci_hcd_pxa27x_remove(struct platform_device *pdev)
for (i = 0; i < 3; ++i)
pxa27x_ohci_set_vbus_power(pxa_ohci, i, false);
+ gpiod_put(pxa_ohci->usb_host);
+
usb_put_hcd(hcd);
}
--
2.42.0
^ permalink raw reply related
* [PATCH RFC v5 2/6] ARM: pxa: Convert Spitz LEDs to GPIO descriptors
From: Duje Mihanović @ 2023-10-04 14:56 UTC (permalink / raw)
To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King,
Alan Stern, Greg Kroah-Hartman, Linus Walleij,
Bartosz Golaszewski, Andy Shevchenko, Dmitry Torokhov, Mark Brown
Cc: linux-arm-kernel, linux-kernel, linux-usb, linux-gpio,
linux-input, linux-spi, Duje Mihanović
In-Reply-To: <20231004-pxa-gpio-v5-0-d99ae6fceea8@skole.hr>
Sharp's Spitz board still uses the legacy GPIO interface for configuring
its two onboard LEDs.
Convert them to use the GPIO descriptor interface.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
---
arch/arm/mach-pxa/spitz.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index 535e2b2e997b..b6a4085e9fb0 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -452,16 +452,25 @@ static inline void spitz_keys_init(void) {}
* LEDs
******************************************************************************/
#if defined(CONFIG_LEDS_GPIO) || defined(CONFIG_LEDS_GPIO_MODULE)
+static struct gpiod_lookup_table spitz_led_gpio_table = {
+ .dev_id = "leds-gpio",
+ .table = {
+ GPIO_LOOKUP_IDX("pxa-gpio", SPITZ_GPIO_LED_ORANGE, NULL, 0,
+ GPIO_ACTIVE_HIGH),
+ GPIO_LOOKUP_IDX("pxa-gpio", SPITZ_GPIO_LED_GREEN, NULL, 1,
+ GPIO_ACTIVE_HIGH),
+ { }
+ }
+};
+
static struct gpio_led spitz_gpio_leds[] = {
{
.name = "spitz:amber:charge",
.default_trigger = "sharpsl-charge",
- .gpio = SPITZ_GPIO_LED_ORANGE,
},
{
.name = "spitz:green:hddactivity",
.default_trigger = "disk-activity",
- .gpio = SPITZ_GPIO_LED_GREEN,
},
};
@@ -480,7 +489,12 @@ static struct platform_device spitz_led_device = {
static void __init spitz_leds_init(void)
{
+ gpiod_add_lookup_table(&spitz_led_gpio_table);
platform_device_register(&spitz_led_device);
+ spitz_gpio_leds[0].gpiod = gpiod_get_index(&spitz_led_device.dev,
+ NULL, 0, GPIOD_ASIS);
+ spitz_gpio_leds[1].gpiod = gpiod_get_index(&spitz_led_device.dev,
+ NULL, 1, GPIOD_ASIS);
}
#else
static inline void spitz_leds_init(void) {}
--
2.42.0
^ permalink raw reply related
* [PATCH RFC v5 5/6] ARM: pxa: Convert gumstix Bluetooth to GPIO descriptors
From: Duje Mihanović @ 2023-10-04 14:56 UTC (permalink / raw)
To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King,
Alan Stern, Greg Kroah-Hartman, Linus Walleij,
Bartosz Golaszewski, Andy Shevchenko, Dmitry Torokhov, Mark Brown
Cc: linux-arm-kernel, linux-kernel, linux-usb, linux-gpio,
linux-input, linux-spi, Duje Mihanović
In-Reply-To: <20231004-pxa-gpio-v5-0-d99ae6fceea8@skole.hr>
Gumstix still uses the legacy GPIO interface for resetting the Bluetooth
device.
Convert it to use the GPIO descriptor interface.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
---
arch/arm/mach-pxa/gumstix.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-pxa/gumstix.c b/arch/arm/mach-pxa/gumstix.c
index c9f0f62187bd..0bca6e2c80a9 100644
--- a/arch/arm/mach-pxa/gumstix.c
+++ b/arch/arm/mach-pxa/gumstix.c
@@ -20,8 +20,8 @@
#include <linux/delay.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
+#include <linux/gpio/consumer.h>
#include <linux/gpio/machine.h>
-#include <linux/gpio.h>
#include <linux/err.h>
#include <linux/clk.h>
@@ -129,6 +129,11 @@ static void gumstix_udc_init(void)
#endif
#ifdef CONFIG_BT
+GPIO_LOOKUP_SINGLE(gumstix_bt_gpio_table, "pxa2xx-uart.1", "pxa-gpio",
+ GPIO_GUMSTIX_BTRESET, "BTRST", GPIO_ACTIVE_LOW);
+
+static struct gpio_desc *bt_reset;
+
/* Normally, the bootloader would have enabled this 32kHz clock but many
** boards still have u-boot 1.1.4 so we check if it has been turned on and
** if not, we turn it on with a warning message. */
@@ -153,24 +158,19 @@ static void gumstix_setup_bt_clock(void)
static void __init gumstix_bluetooth_init(void)
{
- int err;
+ gpiod_add_lookup_table(&gumstix_bt_gpio_table);
gumstix_setup_bt_clock();
- err = gpio_request(GPIO_GUMSTIX_BTRESET, "BTRST");
- if (err) {
+ bt_reset = gpiod_get(&pxa_device_btuart.dev, "BTRST", GPIOD_OUT_HIGH);
+ if (IS_ERR(bt_reset)) {
pr_err("gumstix: failed request gpio for bluetooth reset\n");
return;
}
- err = gpio_direction_output(GPIO_GUMSTIX_BTRESET, 1);
- if (err) {
- pr_err("gumstix: can't reset bluetooth\n");
- return;
- }
- gpio_set_value(GPIO_GUMSTIX_BTRESET, 0);
+ gpiod_set_value(bt_reset, 1);
udelay(100);
- gpio_set_value(GPIO_GUMSTIX_BTRESET, 1);
+ gpiod_set_value(bt_reset, 0);
}
#else
static void gumstix_bluetooth_init(void)
--
2.42.0
^ permalink raw reply related
* [PATCH RFC v5 4/6] ARM: pxa: Convert reset driver to GPIO descriptors
From: Duje Mihanović @ 2023-10-04 14:56 UTC (permalink / raw)
To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King,
Alan Stern, Greg Kroah-Hartman, Linus Walleij,
Bartosz Golaszewski, Andy Shevchenko, Dmitry Torokhov, Mark Brown
Cc: linux-arm-kernel, linux-kernel, linux-usb, linux-gpio,
linux-input, linux-spi, Duje Mihanović
In-Reply-To: <20231004-pxa-gpio-v5-0-d99ae6fceea8@skole.hr>
The PXA reset driver still uses the legacy GPIO interface for
configuring and asserting the reset pin.
Convert it to use the GPIO descriptor interface.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
---
arch/arm/mach-pxa/reset.c | 39 +++++++++++++--------------------------
arch/arm/mach-pxa/reset.h | 3 +--
arch/arm/mach-pxa/spitz.c | 6 +++++-
3 files changed, 19 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-pxa/reset.c b/arch/arm/mach-pxa/reset.c
index 27293549f8ad..08bc104b9411 100644
--- a/arch/arm/mach-pxa/reset.c
+++ b/arch/arm/mach-pxa/reset.c
@@ -2,7 +2,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/delay.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
#include <linux/io.h>
#include <asm/proc-fns.h>
#include <asm/system_misc.h>
@@ -14,33 +14,20 @@
static void do_hw_reset(void);
-static int reset_gpio = -1;
+static struct gpio_desc *reset_gpio;
-int init_gpio_reset(int gpio, int output, int level)
+int init_gpio_reset(int output, int level)
{
- int rc;
-
- rc = gpio_request(gpio, "reset generator");
- if (rc) {
- printk(KERN_ERR "Can't request reset_gpio\n");
- goto out;
+ reset_gpio = gpiod_get(NULL, "reset", GPIOD_ASIS);
+ if (IS_ERR(reset_gpio)) {
+ pr_err("Can't request reset_gpio: %pe\n", reset_gpio);
+ return PTR_ERR(reset_gpio);
}
if (output)
- rc = gpio_direction_output(gpio, level);
+ return gpiod_direction_output(reset_gpio, level);
else
- rc = gpio_direction_input(gpio);
- if (rc) {
- printk(KERN_ERR "Can't configure reset_gpio\n");
- gpio_free(gpio);
- goto out;
- }
-
-out:
- if (!rc)
- reset_gpio = gpio;
-
- return rc;
+ return gpiod_direction_input(reset_gpio);
}
/*
@@ -50,16 +37,16 @@ int init_gpio_reset(int gpio, int output, int level)
*/
static void do_gpio_reset(void)
{
- BUG_ON(reset_gpio == -1);
+ BUG_ON(IS_ERR(reset_gpio));
/* drive it low */
- gpio_direction_output(reset_gpio, 0);
+ gpiod_direction_output(reset_gpio, 0);
mdelay(2);
/* rising edge or drive high */
- gpio_set_value(reset_gpio, 1);
+ gpiod_set_value(reset_gpio, 1);
mdelay(2);
/* falling edge */
- gpio_set_value(reset_gpio, 0);
+ gpiod_set_value(reset_gpio, 0);
/* give it some time */
mdelay(10);
diff --git a/arch/arm/mach-pxa/reset.h b/arch/arm/mach-pxa/reset.h
index 963dd190bc13..5864f61a0e94 100644
--- a/arch/arm/mach-pxa/reset.h
+++ b/arch/arm/mach-pxa/reset.h
@@ -13,10 +13,9 @@ extern void pxa_register_wdt(unsigned int reset_status);
/**
* init_gpio_reset() - register GPIO as reset generator
- * @gpio: gpio nr
* @output: set gpio as output instead of input during normal work
* @level: output level
*/
-extern int init_gpio_reset(int gpio, int output, int level);
+extern int init_gpio_reset(int output, int level);
#endif /* __ASM_ARCH_RESET_H */
diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index 965354e64c68..26ec29c9cd1b 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -1024,9 +1024,13 @@ static void spitz_restart(enum reboot_mode mode, const char *cmd)
spitz_poweroff();
}
+GPIO_LOOKUP_SINGLE(spitz_reset_gpio_table, NULL, "pxa-gpio",
+ SPITZ_GPIO_ON_RESET, "reset", GPIO_ACTIVE_HIGH);
+
static void __init spitz_init(void)
{
- init_gpio_reset(SPITZ_GPIO_ON_RESET, 1, 0);
+ gpiod_add_lookup_table(&spitz_reset_gpio_table);
+ init_gpio_reset(1, 0);
pm_power_off = spitz_poweroff;
PMCR = 0x00;
--
2.42.0
^ permalink raw reply related
* [PATCH RFC v5 3/6] ARM: pxa: Convert Spitz CF power control to GPIO descriptors
From: Duje Mihanović @ 2023-10-04 14:56 UTC (permalink / raw)
To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King,
Alan Stern, Greg Kroah-Hartman, Linus Walleij,
Bartosz Golaszewski, Andy Shevchenko, Dmitry Torokhov, Mark Brown
Cc: linux-arm-kernel, linux-kernel, linux-usb, linux-gpio,
linux-input, linux-spi, Duje Mihanović
In-Reply-To: <20231004-pxa-gpio-v5-0-d99ae6fceea8@skole.hr>
Sharp's Spitz board still uses the legacy GPIO interface for controlling
the power supply to its CF and SD card slots.
Convert it to use the GPIO descriptor interface.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
---
arch/arm/mach-pxa/spitz.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index b6a4085e9fb0..965354e64c68 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -133,6 +133,10 @@ static unsigned long spitz_pin_config[] __initdata = {
* Scoop GPIO expander
******************************************************************************/
#if defined(CONFIG_SHARP_SCOOP) || defined(CONFIG_SHARP_SCOOP_MODULE)
+GPIO_LOOKUP_SINGLE(spitz_card_pwr_ctrl_gpio_table, "pxa2xx-mci.0",
+ "sharp-scoop", SPITZ_GPIO_CF_POWER, "cf_power",
+ GPIO_ACTIVE_HIGH);
+
/* SCOOP Device #1 */
static struct resource spitz_scoop_1_resources[] = {
[0] = {
@@ -190,6 +194,7 @@ struct platform_device spitz_scoop_2_device = {
static void __init spitz_scoop_init(void)
{
platform_device_register(&spitz_scoop_1_device);
+ gpiod_add_lookup_table(&spitz_card_pwr_ctrl_gpio_table);
/* Akita doesn't have the second SCOOP chip */
if (!machine_is_akita())
@@ -201,9 +206,18 @@ static void __maybe_unused spitz_card_pwr_ctrl(uint8_t enable, uint8_t new_cpr)
{
unsigned short cpr;
unsigned long flags;
+ struct gpio_desc *cf_power;
+
+ cf_power = gpiod_get(&pxa_device_mci.dev, "cf_power", GPIOD_ASIS);
+ if (IS_ERR(cf_power)) {
+ dev_err(&pxa_device_mci.dev,
+ "failed to get power control GPIO with %ld\n",
+ PTR_ERR(cf_power));
+ return;
+ }
if (new_cpr & 0x7) {
- gpio_set_value(SPITZ_GPIO_CF_POWER, 1);
+ gpiod_direction_output(cf_power, 1);
mdelay(5);
}
@@ -222,8 +236,10 @@ static void __maybe_unused spitz_card_pwr_ctrl(uint8_t enable, uint8_t new_cpr)
if (!(cpr & 0x7)) {
mdelay(1);
- gpio_set_value(SPITZ_GPIO_CF_POWER, 0);
+ gpiod_direction_output(cf_power, 0);
}
+
+ gpiod_put(cf_power);
}
#else
--
2.42.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox