* Re: [PATCH 2/2] Input: atmel_mxt_ts - support capacitive keys
From: Linus Walleij @ 2023-03-06 22:54 UTC (permalink / raw)
To: André Apitzsch
Cc: Nick Dyer, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, linux-input,
devicetree, linux-arm-kernel, linux-kernel,
~postmarketos/upstreaming
In-Reply-To: <20230227205035.18551-2-git@apitzsch.eu>
On Mon, Feb 27, 2023 at 9:50 PM André Apitzsch <git@apitzsch.eu> wrote:
> Add support for touch keys found in some Atmel touch controller
> configurations.
>
> Signed-off-by: André Apitzsch <git@apitzsch.eu>
Looks good to me.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [GIT PULL] intel-gpio for 6.3-1
From: Arnd Bergmann @ 2023-03-07 8:09 UTC (permalink / raw)
To: Andy Shevchenko, Linus Walleij
Cc: Andy Shevchenko, open list:GPIO SUBSYSTEM, linux-arm-kernel,
linux-input, Bartosz Golaszewski, Dmitry Torokhov
In-Reply-To: <ZAZqy+LFkZuj+T4P@surfacebook>
On Mon, Mar 6, 2023, at 23:35, andy.shevchenko@gmail.com wrote:
> Mon, Mar 06, 2023 at 10:50:40PM +0100, Linus Walleij kirjoitti:
>> On Mon, Mar 6, 2023 at 4:14 PM Andy Shevchenko
>> <andriy.shevchenko@linux.intel.com> wrote:
>>
>> > Hi Linux GPIO maintainers et al.,
>> >
>> > Combined series to clean up headers in the GPIO library and drivers.
>> > Along with it, drop a few unused legacy APIs.
>> >
>> > This tag is immutable, enjoy!
>>
>> Thanks for coordinating and getting this sorted and tested Andy, perfect
>> job as always!
>
> You're welcome!
>
>> > intel-gpio for v6.3-1
>>
>> But I think you mean it for v6.4?
>
> Well, techically speaking it didn't make v6.3-rc1 due to cross-dependencies.
> Starting from it it may be applied to v6.3 or to v6.4.
>
> Up to you and Bart, but I prefer not to rebrand the tag, if it's an option.
I think it was clear that this would not make it into 6.3 after
the decision to rebase on top of 6.3-rc1. However, the tag name
and description both look like they make sense for 6.4 the way
you wrote them.
Arnd
^ permalink raw reply
* Re: [PATCH 2/2] Input: atmel_mxt_ts - support capacitive keys
From: Claudiu.Beznea @ 2023-03-07 8:57 UTC (permalink / raw)
To: git, nick, dmitry.torokhov, robh+dt, krzysztof.kozlowski+dt,
Nicolas.Ferre, alexandre.belloni, linus.walleij, linux-input,
devicetree, linux-arm-kernel, linux-kernel
Cc: ~postmarketos/upstreaming
In-Reply-To: <20230227205035.18551-2-git@apitzsch.eu>
On 27.02.2023 22:50, André Apitzsch wrote:
> [Some people who received this message don't often get email from git@apitzsch.eu. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> Add support for touch keys found in some Atmel touch controller
> configurations.
>
> Signed-off-by: André Apitzsch <git@apitzsch.eu>
Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
> ---
> drivers/input/touchscreen/atmel_mxt_ts.c | 85 ++++++++++++++++++++++++
> 1 file changed, 85 insertions(+)
>
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
> index 996bf434e1cb..eb368dd1abf0 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> @@ -55,6 +55,7 @@
> #define MXT_TOUCH_KEYARRAY_T15 15
> #define MXT_TOUCH_PROXIMITY_T23 23
> #define MXT_TOUCH_PROXKEY_T52 52
> +#define MXT_TOUCH_PTC_KEYS_T97 97
> #define MXT_PROCI_GRIPFACE_T20 20
> #define MXT_PROCG_NOISE_T22 22
> #define MXT_PROCI_ONETOUCH_T24 24
> @@ -326,9 +327,13 @@ struct mxt_data {
> u16 T71_address;
> u8 T9_reportid_min;
> u8 T9_reportid_max;
> + u8 T15_reportid_min;
> + u8 T15_reportid_max;
> u16 T18_address;
> u8 T19_reportid;
> u16 T44_address;
> + u8 T97_reportid_min;
> + u8 T97_reportid_max;
> u8 T100_reportid_min;
> u8 T100_reportid_max;
>
> @@ -344,6 +349,9 @@ struct mxt_data {
> u32 *t19_keymap;
> unsigned int t19_num_keys;
>
> + u32 *t15_keymap;
> + unsigned int t15_num_keys;
> +
> enum mxt_suspend_mode suspend_mode;
>
> u32 wakeup_method;
> @@ -375,6 +383,7 @@ static bool mxt_object_readable(unsigned int type)
> case MXT_TOUCH_KEYARRAY_T15:
> case MXT_TOUCH_PROXIMITY_T23:
> case MXT_TOUCH_PROXKEY_T52:
> + case MXT_TOUCH_PTC_KEYS_T97:
> case MXT_TOUCH_MULTITOUCHSCREEN_T100:
> case MXT_PROCI_GRIPFACE_T20:
> case MXT_PROCG_NOISE_T22:
> @@ -891,6 +900,25 @@ static void mxt_proc_t9_message(struct mxt_data *data, u8 *message)
> data->update_input = true;
> }
>
> +static void mxt_proc_t15_messages(struct mxt_data *data, u8 *message)
> +{
> + struct input_dev *input_dev = data->input_dev;
> + unsigned long keystates = get_unaligned_le32(&message[2]);
> + int key;
> +
> + for (key = 0; key < data->t15_num_keys; key++) {
> + input_report_key(input_dev, data->t15_keymap[key],
> + !!(keystates & BIT(key)));
> + }
> +
> + data->update_input = true;
> +}
> +
> +static void mxt_proc_t97_messages(struct mxt_data *data, u8 *message)
> +{
> + mxt_proc_t15_messages(data, message);
> +}
> +
> static void mxt_proc_t100_message(struct mxt_data *data, u8 *message)
> {
> struct device *dev = &data->client->dev;
> @@ -1017,6 +1045,12 @@ static int mxt_proc_message(struct mxt_data *data, u8 *message)
> } else if (report_id >= data->T9_reportid_min &&
> report_id <= data->T9_reportid_max) {
> mxt_proc_t9_message(data, message);
> + } else if (report_id >= data->T15_reportid_min &&
> + report_id <= data->T15_reportid_max) {
> + mxt_proc_t15_messages(data, message);
> + } else if (report_id >= data->T97_reportid_min &&
> + report_id <= data->T97_reportid_max) {
> + mxt_proc_t97_messages(data, message);
> } else if (report_id >= data->T100_reportid_min &&
> report_id <= data->T100_reportid_max) {
> mxt_proc_t100_message(data, message);
> @@ -1689,9 +1723,13 @@ static void mxt_free_object_table(struct mxt_data *data)
> data->T71_address = 0;
> data->T9_reportid_min = 0;
> data->T9_reportid_max = 0;
> + data->T15_reportid_min = 0;
> + data->T15_reportid_max = 0;
> data->T18_address = 0;
> data->T19_reportid = 0;
> data->T44_address = 0;
> + data->T97_reportid_min = 0;
> + data->T97_reportid_max = 0;
> data->T100_reportid_min = 0;
> data->T100_reportid_max = 0;
> data->max_reportid = 0;
> @@ -1764,6 +1802,10 @@ static int mxt_parse_object_table(struct mxt_data *data,
> object->num_report_ids - 1;
> data->num_touchids = object->num_report_ids;
> break;
> + case MXT_TOUCH_KEYARRAY_T15:
> + data->T15_reportid_min = min_id;
> + data->T15_reportid_max = max_id;
> + break;
> case MXT_SPT_COMMSCONFIG_T18:
> data->T18_address = object->start_address;
> break;
> @@ -1773,6 +1815,10 @@ static int mxt_parse_object_table(struct mxt_data *data,
> case MXT_SPT_GPIOPWM_T19:
> data->T19_reportid = min_id;
> break;
> + case MXT_TOUCH_PTC_KEYS_T97:
> + data->T97_reportid_min = min_id;
> + data->T97_reportid_max = max_id;
> + break;
> case MXT_TOUCH_MULTITOUCHSCREEN_T100:
> data->multitouch = MXT_TOUCH_MULTITOUCHSCREEN_T100;
> data->T100_reportid_min = min_id;
> @@ -2050,6 +2096,7 @@ static int mxt_initialize_input_device(struct mxt_data *data)
> int error;
> unsigned int num_mt_slots;
> unsigned int mt_flags = 0;
> + int i;
>
> switch (data->multitouch) {
> case MXT_TOUCH_MULTI_T9:
> @@ -2095,6 +2142,10 @@ static int mxt_initialize_input_device(struct mxt_data *data)
> input_dev->open = mxt_input_open;
> input_dev->close = mxt_input_close;
>
> + input_dev->keycode = data->t15_keymap;
> + input_dev->keycodemax = data->t15_num_keys;
> + input_dev->keycodesize = sizeof(data->t15_keymap[0]);
> +
> input_set_capability(input_dev, EV_KEY, BTN_TOUCH);
>
> /* For single touch */
> @@ -2162,6 +2213,12 @@ static int mxt_initialize_input_device(struct mxt_data *data)
> 0, 255, 0, 0);
> }
>
> + /* For T15 and T97 Key Array */
> + if (data->T15_reportid_min || data->T97_reportid_min) {
> + for (i = 0; i < data->t15_num_keys; i++)
> + input_set_capability(input_dev, EV_KEY, data->t15_keymap[i]);
> + }
> +
> input_set_drvdata(input_dev, data);
>
> error = input_register_device(input_dev);
> @@ -3080,8 +3137,10 @@ static void mxt_input_close(struct input_dev *dev)
> static int mxt_parse_device_properties(struct mxt_data *data)
> {
> static const char keymap_property[] = "linux,gpio-keymap";
> + static const char buttons_property[] = "linux,keycodes";
> struct device *dev = &data->client->dev;
> u32 *keymap;
> + u32 *buttonmap;
> int n_keys;
> int error;
>
> @@ -3111,6 +3170,32 @@ static int mxt_parse_device_properties(struct mxt_data *data)
> data->t19_num_keys = n_keys;
> }
>
> + if (device_property_present(dev, buttons_property)) {
> + n_keys = device_property_count_u32(dev, buttons_property);
> + if (n_keys <= 0) {
> + error = n_keys < 0 ? n_keys : -EINVAL;
> + dev_err(dev, "invalid/malformed '%s' property: %d\n",
> + buttons_property, error);
> + return error;
> + }
> +
> + buttonmap = devm_kmalloc_array(dev, n_keys, sizeof(*buttonmap),
> + GFP_KERNEL);
> + if (!buttonmap)
> + return -ENOMEM;
> +
> + error = device_property_read_u32_array(dev, buttons_property,
> + buttonmap, n_keys);
> + if (error) {
> + dev_err(dev, "failed to parse '%s' property: %d\n",
> + buttons_property, error);
> + return error;
> + }
> +
> + data->t15_keymap = buttonmap;
> + data->t15_num_keys = n_keys;
> + }
> +
> return 0;
> }
>
> --
> 2.39.2
>
^ permalink raw reply
* Re: [GIT PULL] intel-gpio for 6.3-1
From: Andy Shevchenko @ 2023-03-07 9:51 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linus Walleij, Andy Shevchenko, open list:GPIO SUBSYSTEM,
linux-arm-kernel, linux-input, Bartosz Golaszewski,
Dmitry Torokhov
In-Reply-To: <e4cdd1f9-fc79-4f91-a4df-ab5f5a94faa3@app.fastmail.com>
On Tue, Mar 7, 2023 at 10:09 AM Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Mar 6, 2023, at 23:35, andy.shevchenko@gmail.com wrote:
> > Mon, Mar 06, 2023 at 10:50:40PM +0100, Linus Walleij kirjoitti:
> >> On Mon, Mar 6, 2023 at 4:14 PM Andy Shevchenko
> >> <andriy.shevchenko@linux.intel.com> wrote:
> >>
> >> > Hi Linux GPIO maintainers et al.,
> >> >
> >> > Combined series to clean up headers in the GPIO library and drivers.
> >> > Along with it, drop a few unused legacy APIs.
> >> >
> >> > This tag is immutable, enjoy!
> >>
> >> Thanks for coordinating and getting this sorted and tested Andy, perfect
> >> job as always!
> >
> > You're welcome!
> >
> >> > intel-gpio for v6.3-1
> >>
> >> But I think you mean it for v6.4?
> >
> > Well, techically speaking it didn't make v6.3-rc1 due to cross-dependencies.
> > Starting from it it may be applied to v6.3 or to v6.4.
> >
> > Up to you and Bart, but I prefer not to rebrand the tag, if it's an option.
>
> I think it was clear that this would not make it into 6.3 after
> the decision to rebase on top of 6.3-rc1. However, the tag name
> and description both look like they make sense for 6.4 the way
> you wrote them.
Okay, I will rre-tag this.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [GIT PULL] intel-gpio for 6.3-1
From: Andy Shevchenko @ 2023-03-07 11:42 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linus Walleij, open list:GPIO SUBSYSTEM, linux-arm-kernel,
linux-input, Bartosz Golaszewski, Dmitry Torokhov
In-Reply-To: <CAHp75Vds2cLoTciFdQmEZsXsS0ND_HJmn1MNm6hsApFazkFAHg@mail.gmail.com>
On Tue, Mar 07, 2023 at 11:51:44AM +0200, Andy Shevchenko wrote:
> On Tue, Mar 7, 2023 at 10:09 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > On Mon, Mar 6, 2023, at 23:35, andy.shevchenko@gmail.com wrote:
> > > Mon, Mar 06, 2023 at 10:50:40PM +0100, Linus Walleij kirjoitti:
> > >> On Mon, Mar 6, 2023 at 4:14 PM Andy Shevchenko
> > >> <andriy.shevchenko@linux.intel.com> wrote:
> > >>
> > >> > Hi Linux GPIO maintainers et al.,
> > >> >
> > >> > Combined series to clean up headers in the GPIO library and drivers.
> > >> > Along with it, drop a few unused legacy APIs.
> > >> >
> > >> > This tag is immutable, enjoy!
> > >>
> > >> Thanks for coordinating and getting this sorted and tested Andy, perfect
> > >> job as always!
> > >
> > > You're welcome!
> > >
> > >> > intel-gpio for v6.3-1
> > >>
> > >> But I think you mean it for v6.4?
> > >
> > > Well, techically speaking it didn't make v6.3-rc1 due to cross-dependencies.
> > > Starting from it it may be applied to v6.3 or to v6.4.
> > >
> > > Up to you and Bart, but I prefer not to rebrand the tag, if it's an option.
> >
> > I think it was clear that this would not make it into 6.3 after
> > the decision to rebase on top of 6.3-rc1. However, the tag name
> > and description both look like they make sense for 6.4 the way
> > you wrote them.
>
> Okay, I will rre-tag this.
Now it's tagged as intel-gpio-v6.4-1. Should I send a new PR?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v8 3/3] HID: cp2112: Fwnode Support
From: Benjamin Tissoires @ 2023-03-07 13:17 UTC (permalink / raw)
To: Andy Shevchenko, Daniel Kaehn
Cc: Hans de Goede, robh+dt, krzysztof.kozlowski+dt, jikos,
bartosz.golaszewski, dmitry.torokhov, devicetree, linux-input,
ethan.twardy
In-Reply-To: <ZAZOvEvqNDq6jZNB@smile.fi.intel.com>
On Mar 06 2023, Andy Shevchenko wrote:
> On Mon, Mar 06, 2023 at 01:40:16PM -0600, Daniel Kaehn wrote:
>
> ...
>
> > Device (SE9)
> > {
> > Name (_ADR, 0x001D0001) // _ADR: Address
> > Device (RHUB)
> > {
> > Name (_ADR, Zero)
> > Device (CP2) // the USB-hid & CP2112 shared node
> > {
> > Name (_ADR, One)
> > }
> > }
> > }
> >
> > If I'm understanding correctly, this adds the SE9 device as function 1
> > of PCI device 0x1d,
>
> To be precise this does not add the device. It adds a description of
> the companion device in case the real one will appear on the PCI bus
> with BDF 00:1d.1.
>
> > then RHUB as the USB controller it provides, and finally, CP2 as the
> > USB device attached to port 1 of the controller.
> >
> > With this as the loaded dsdt table, the USB device now has a firmware_node :)
> > #> cat /sys/bus/usb/devices/3-1:1.0/firmware_node/path
> > \_SB_.PCI0.SE9_.RHUB.CP2_
> >
> > After applying my patches, the HID device also references this node:
> > #> cat /sys/bus/hid/devices/0003:10C4:EA90.0003/firmware_node/path
> > \_SB_.PCI0.SE9_.RHUB.CP2_
> >
Great! Thanks a lot for that. Turns out that with both of your inputs I
can also do the same, but without the need for OVMF and DSDT patching,
with just an SSDT override.
Turns out that the override documentation [1] mentions "This option
allows loading of user defined SSDTs from initrd and it is useful when
the system does not support EFI or ..."
FWIW, I am attaching my full DSDT override in case it is valuable:
(on my system, the default USB controller (non-xhc) is at PCI address
1.2, which explains the slight difference). It can be loaded in the same
way you are overriding the full DSDT, but with just that compilation
output:
---
DefinitionBlock ("cp2112.aml", "SSDT", 5, "", "CP2112", 1)
{
External (_SB_.PCI0, DeviceObj)
Scope (\_SB_.PCI0)
{
Device (USB0)
{
Name (_ADR, 0x00010002) // _ADR: Address
Device (RHUB)
{
Name (_ADR, Zero)
Device (CP21) // the USB-hid & CP2112 shared node
{
Name (_ADR, One)
Device (I2C)
{
Name (_ADR, Zero)
Name (_STA, 0x0F)
}
Device (GPIO)
{
Name (_ADR, One)
Name (_STA, 0x0F)
}
}
}
}
}
Scope (\_SB_.PCI0.USB0.RHUB.CP21.I2C)
{
Device (TPD0)
{
Name (_HID, "RMI40001")
Name (_CID, "PNP0C50")
Name (_STA, 0x0F)
Name (SBFB, ResourceTemplate ()
{
I2cSerialBusV2 (0x00c, ControllerInitiated, 100000,
AddressingMode7Bit, "\\_SB_.PCI0.USB0.RHUB.CP21.I2C",
0x00, ResourceConsumer,, Exclusive,
)
})
Name (SBFG, ResourceTemplate ()
{
GpioInt (Level, ActiveLow, Exclusive, PullDefault, 0x0000,
"\\_SB_.PCI0.USB0.RHUB.CP21.GPIO", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0002
}
})
Method(_CRS, 0x0, NotSerialized)
{
Return (ConcatenateResTemplate (SBFB, SBFG))
}
Method(_DSM, 0x4, Serialized)
{
// DSM UUID
switch (ToBuffer (Arg0))
{
// ACPI DSM UUID for HIDI2C
case (ToUUID ("3CDFF6F7-4267-4555-AD05-B30A3D8938DE"))
{
// DSM Function
switch (ToInteger (Arg2))
{
// Function 0: Query function, return based on revision
case(0)
{
// DSM Revision
switch (ToInteger (Arg1))
{
// Revision 1: Function 1 supported
case (1)
{
Return (Buffer (One) { 0x03 })
}
default
{
// Revision 2+: no functions supported
Return (Buffer (One) { 0x00 })
}
}
}
// Function 1 : HID Function
case(1)
{
// HID Descriptor Address
Return (0x0020)
}
default
{
// Functions 2+: not supported
Return (Buffer (One) { 0x00 })
}
}
}
default
{
// No other GUIDs supported
Return (Buffer (One) { 0x00 })
}
}
}
}
}
}
---
This almost works. Almost because the I2C device is correctly created,
but I have an issue with the GpioInt call which is not properly set by
the kernel and which returns -EDEFER. /o\
> > With this all said -- I noticed iasl prints this statement when trying
> > to create a node with a lowercase name:
> > "At least one lower case letter found in NameSeg, ASL is case
> > insensitive - converting to upper case (GPIO)"
>
> Yes, because it should be in the upper case.
>
> > I wonder if this suggests that adding a call to toupper() to
> > acpi_fwnode_get_named_child_node would be
> > an appropriate solution for the node name casing issue....
>
> I dunno. You need to ask in the linux-acpi@ mailing list.
> To me this is corner case that can't be easily solved
> (because two different specifications treat it differently.
>
> You also need to ask DT people about capital letters there.
> And my guts tell me that it's probably also carved in the spec
> as "must be lower case" or alike.
FWIW while trying to enable this, at some point I named the I2C and the
GPIO entries "I2C0" and "GPI0" (with the number '0', not the letter
'o'), and it was not working as you would expect.
It is commonly accepted in the ACPI world that the names do not carry
meaning AFAICT, and so I think I agree with Andy's initial comment
regarding using indexes, not names to also fetch the I2C and GPIO nodes.
You can probably have a fallback mechanism for when "i2c" is not
present, or simply check if you are in DT or not and use the names only
if we are in DT.
Thanks a lot to both of you, this will be tremendously helpful to me.
Cheers,
Benjamin
[1] https://www.kernel.org/doc/html/latest/admin-guide/acpi/ssdt-overlays.html#loading-acpi-ssdts-from-initrd
^ permalink raw reply
* [GIT PULL] intel-gpio for 6.4-1
From: Andy Shevchenko @ 2023-03-07 13:25 UTC (permalink / raw)
To: Linux GPIO, linux-arm-kernel, linux-input
Cc: Linus Walleij, Bartosz Golaszewski, Andy Shevchenko,
Arnd Bergmann, Dmitry Torokhov
Hi Linux GPIO maintainers et al.,
Combined series to clean up headers in the GPIO library and drivers.
Along with it, drop a few unused legacy APIs.
This tag is immutable, enjoy!
Thanks,
With Best Regards,
Andy Shevchenko
The following changes since commit fe15c26ee26efa11741a7b632e9f23b01aca4cc6:
Linux 6.3-rc1 (2023-03-05 14:52:03 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-gpio-intel.git tags/intel-gpio-v6.4-1
for you to fetch changes up to 380c7ba3923c6e471aff0f951a6cf42e8dec2c79:
gpiolib: Clean up headers (2023-03-06 12:33:02 +0200)
----------------------------------------------------------------
intel-gpio for v6.4-1
* Remove some of the legacy APIs that are not used anymore
* Clean up headers in the GPIO library and drivers
The following is an automated git shortlog grouped by driver:
aggregator:
- Add missing header(s)
ARM:
- s3c64xx: Use the right include
- orion/gpio: Use the right include
gpiolib:
- Clean up headers
- Group forward declarations in consumer.h
- Deduplicate forward declarations in consumer.h
- Drop unused forward declaration from driver.h
- split of_mm_gpio_chip out of linux/of_gpio.h
- split linux/gpio/driver.h out of linux/gpio.h
- remove legacy gpio_export()
- remove gpio_set_debounce()
- remove asm-generic/gpio.h
- coldfire: remove custom asm/gpio.h
- remove empty asm/gpio.h files
- Make the legacy <linux/gpio.h> consumer-only
hte:
- tegra-194: Use proper includes
reg:
- Add missing header(s)
regmap:
- Add missing header(s)
----------------------------------------------------------------
Andy Shevchenko (7):
gpio: aggregator: Add missing header(s)
gpio: reg: Add missing header(s)
gpio: regmap: Add missing header(s)
gpiolib: Drop unused forward declaration from driver.h
gpiolib: Deduplicate forward declarations in consumer.h
gpiolib: Group forward declarations in consumer.h
gpiolib: Clean up headers
Arnd Bergmann (7):
gpiolib: remove empty asm/gpio.h files
gpiolib: coldfire: remove custom asm/gpio.h
gpiolib: remove asm-generic/gpio.h
gpiolib: remove gpio_set_debounce()
gpiolib: remove legacy gpio_export()
gpiolib: split linux/gpio/driver.h out of linux/gpio.h
gpiolib: split of_mm_gpio_chip out of linux/of_gpio.h
Linus Walleij (4):
ARM: orion/gpio: Use the right include
ARM: s3c64xx: Use the right include
hte: tegra-194: Use proper includes
gpiolib: Make the legacy <linux/gpio.h> consumer-only
Documentation/admin-guide/gpio/sysfs.rst | 2 +-
Documentation/driver-api/gpio/legacy.rst | 23 ----
.../translations/zh_CN/driver-api/gpio/legacy.rst | 20 ---
Documentation/translations/zh_TW/gpio.txt | 19 ---
MAINTAINERS | 1 -
arch/arm/Kconfig | 1 -
arch/arm/include/asm/gpio.h | 21 ---
arch/arm/mach-omap1/irq.c | 1 +
arch/arm/mach-omap2/pdata-quirks.c | 9 +-
arch/arm/mach-orion5x/board-rd88f5182.c | 1 +
arch/arm/mach-s3c/s3c64xx.c | 2 +-
arch/arm/mach-sa1100/assabet.c | 1 +
arch/arm/plat-orion/gpio.c | 5 +-
arch/m68k/Kconfig.cpu | 1 -
arch/m68k/include/asm/gpio.h | 95 -------------
arch/m68k/include/asm/mcfgpio.h | 2 +-
arch/powerpc/platforms/44x/Kconfig | 1 +
arch/powerpc/platforms/4xx/gpio.c | 2 +-
arch/powerpc/platforms/8xx/Kconfig | 1 +
arch/powerpc/platforms/8xx/cpm1.c | 2 +-
arch/powerpc/platforms/Kconfig | 2 +
arch/powerpc/sysdev/cpm_common.c | 2 +-
arch/sh/Kconfig | 1 -
arch/sh/boards/board-magicpanelr2.c | 1 +
arch/sh/boards/mach-ap325rxa/setup.c | 7 +-
arch/sh/include/asm/gpio.h | 45 -------
drivers/gpio/Kconfig | 19 +--
drivers/gpio/TODO | 15 ++-
drivers/gpio/gpio-aggregator.c | 9 +-
drivers/gpio/gpio-altera.c | 2 +-
drivers/gpio/gpio-davinci.c | 2 -
drivers/gpio/gpio-mm-lantiq.c | 2 +-
drivers/gpio/gpio-mpc5200.c | 2 +-
drivers/gpio/gpio-reg.c | 12 +-
drivers/gpio/gpio-regmap.c | 12 +-
drivers/gpio/gpiolib-acpi.c | 10 +-
drivers/gpio/gpiolib-acpi.h | 1 -
drivers/gpio/gpiolib-of.c | 9 +-
drivers/gpio/gpiolib-of.h | 1 -
drivers/gpio/gpiolib-swnode.c | 5 +-
drivers/gpio/gpiolib-sysfs.c | 25 +++-
drivers/gpio/gpiolib.c | 9 +-
drivers/hte/hte-tegra194-test.c | 10 +-
drivers/input/touchscreen/ads7846.c | 5 +-
drivers/media/pci/sta2x11/sta2x11_vip.c | 10 +-
drivers/net/ieee802154/ca8210.c | 3 +-
.../net/wireless/broadcom/brcm80211/brcmsmac/led.c | 1 +
drivers/pinctrl/core.c | 1 -
drivers/soc/fsl/qe/gpio.c | 2 +-
include/asm-generic/gpio.h | 147 ---------------------
include/linux/gpio.h | 104 +++++++++------
include/linux/gpio/consumer.h | 24 ++--
include/linux/gpio/driver.h | 31 +++--
include/linux/gpio/legacy-of-mm-gpiochip.h | 36 +++++
include/linux/mfd/ucb1x00.h | 1 +
include/linux/of_gpio.h | 21 ---
56 files changed, 271 insertions(+), 528 deletions(-)
delete mode 100644 arch/arm/include/asm/gpio.h
delete mode 100644 arch/m68k/include/asm/gpio.h
delete mode 100644 arch/sh/include/asm/gpio.h
delete mode 100644 include/asm-generic/gpio.h
create mode 100644 include/linux/gpio/legacy-of-mm-gpiochip.h
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v8 3/3] HID: cp2112: Fwnode Support
From: Daniel Kaehn @ 2023-03-07 13:53 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Andy Shevchenko, Hans de Goede, robh+dt, krzysztof.kozlowski+dt,
jikos, bartosz.golaszewski, dmitry.torokhov, devicetree,
linux-input, ethan.twardy
In-Reply-To: <20230307131706.olnb4qzo4ynu7gce@mail.corp.redhat.com>
On Tue, Mar 7, 2023 at 7:17 AM Benjamin Tissoires
<benjamin.tissoires@redhat.com> wrote:
>
> On Mar 06 2023, Andy Shevchenko wrote:
> > On Mon, Mar 06, 2023 at 01:40:16PM -0600, Daniel Kaehn wrote:
> >
> > ...
> >
> > > Device (SE9)
> > > {
> > > Name (_ADR, 0x001D0001) // _ADR: Address
> > > Device (RHUB)
> > > {
> > > Name (_ADR, Zero)
> > > Device (CP2) // the USB-hid & CP2112 shared node
> > > {
> > > Name (_ADR, One)
> > > }
> > > }
> > > }
> > >
> > > If I'm understanding correctly, this adds the SE9 device as function 1
> > > of PCI device 0x1d,
> >
> > To be precise this does not add the device. It adds a description of
> > the companion device in case the real one will appear on the PCI bus
> > with BDF 00:1d.1.
> >
> > > then RHUB as the USB controller it provides, and finally, CP2 as the
> > > USB device attached to port 1 of the controller.
> > >
> > > With this as the loaded dsdt table, the USB device now has a firmware_node :)
> > > #> cat /sys/bus/usb/devices/3-1:1.0/firmware_node/path
> > > \_SB_.PCI0.SE9_.RHUB.CP2_
> > >
> > > After applying my patches, the HID device also references this node:
> > > #> cat /sys/bus/hid/devices/0003:10C4:EA90.0003/firmware_node/path
> > > \_SB_.PCI0.SE9_.RHUB.CP2_
> > >
>
> Great! Thanks a lot for that. Turns out that with both of your inputs I
> can also do the same, but without the need for OVMF and DSDT patching,
> with just an SSDT override.
>
Ah, interesting.. I tried the SSDT override route initially, but tried
applying it
through EFI variables and through configfs, neither of which worked since
they appeared to be applied after the relevant drivers were already loaded
(at least that was my suspicion). I wonder if loading the overlay through the
initramfs was the key.
> Turns out that the override documentation [1] mentions "This option
> allows loading of user defined SSDTs from initrd and it is useful when
> the system does not support EFI or ..."
>
> FWIW, I am attaching my full DSDT override in case it is valuable:
> (on my system, the default USB controller (non-xhc) is at PCI address
> 1.2, which explains the slight difference). It can be loaded in the same
> way you are overriding the full DSDT, but with just that compilation
> output:
>
> ---
> DefinitionBlock ("cp2112.aml", "SSDT", 5, "", "CP2112", 1)
> {
> External (_SB_.PCI0, DeviceObj)
>
> Scope (\_SB_.PCI0)
> {
> Device (USB0)
> {
> Name (_ADR, 0x00010002) // _ADR: Address
> Device (RHUB)
> {
> Name (_ADR, Zero)
> Device (CP21) // the USB-hid & CP2112 shared node
> {
> Name (_ADR, One)
> Device (I2C)
> {
> Name (_ADR, Zero)
> Name (_STA, 0x0F)
> }
>
> Device (GPIO)
> {
> Name (_ADR, One)
> Name (_STA, 0x0F)
> }
> }
> }
> }
> }
To get this to work -- I assume you had to change the driver to look
for uppercase
"GPIO" and "I2C", or some similar change?
>
> Scope (\_SB_.PCI0.USB0.RHUB.CP21.I2C)
> {
> Device (TPD0)
> {
> Name (_HID, "RMI40001")
> Name (_CID, "PNP0C50")
> Name (_STA, 0x0F)
>
> Name (SBFB, ResourceTemplate ()
> {
> I2cSerialBusV2 (0x00c, ControllerInitiated, 100000,
> AddressingMode7Bit, "\\_SB_.PCI0.USB0.RHUB.CP21.I2C",
> 0x00, ResourceConsumer,, Exclusive,
> )
> })
> Name (SBFG, ResourceTemplate ()
> {
> GpioInt (Level, ActiveLow, Exclusive, PullDefault, 0x0000,
> "\\_SB_.PCI0.USB0.RHUB.CP21.GPIO", 0x00, ResourceConsumer, ,
> )
> { // Pin list
> 0x0002
> }
> })
> Method(_CRS, 0x0, NotSerialized)
> {
> Return (ConcatenateResTemplate (SBFB, SBFG))
> }
>
> Method(_DSM, 0x4, Serialized)
> {
> // DSM UUID
> switch (ToBuffer (Arg0))
> {
> // ACPI DSM UUID for HIDI2C
> case (ToUUID ("3CDFF6F7-4267-4555-AD05-B30A3D8938DE"))
> {
> // DSM Function
> switch (ToInteger (Arg2))
> {
> // Function 0: Query function, return based on revision
> case(0)
> {
> // DSM Revision
> switch (ToInteger (Arg1))
> {
> // Revision 1: Function 1 supported
> case (1)
> {
> Return (Buffer (One) { 0x03 })
> }
>
> default
> {
> // Revision 2+: no functions supported
> Return (Buffer (One) { 0x00 })
> }
> }
> }
>
> // Function 1 : HID Function
> case(1)
> {
> // HID Descriptor Address
> Return (0x0020)
> }
>
> default
> {
> // Functions 2+: not supported
> Return (Buffer (One) { 0x00 })
> }
> }
> }
>
> default
> {
> // No other GUIDs supported
> Return (Buffer (One) { 0x00 })
> }
> }
> }
> }
> }
> }
> ---
>
> This almost works. Almost because the I2C device is correctly created,
> but I have an issue with the GpioInt call which is not properly set by
> the kernel and which returns -EDEFER. /o\
>
Ahh, yep, I've had this issue as well -- I suspect the issue you're
having is that the
CP2112 driver initializes the i2c controller before the gpiochip, and
if any i2c devices
on the bus depend on the CP2112's gpio, the probe will never succeed!
I have made
and been testing with a patch to fix this, but since it was midway
through submitting
this series, thought it might be bad practice to "tack on" additional
patches to a patchset
mid-review (since it only causes an issue in some (admittedly fairly
common) use-cases)
so I was going to send it as an individual patch once (if) these were applied.
If you think that would be necessary to include for these to merge,
I'd be happy to append
it to this review. I also have another patch which adds i2c bus
recovery to the driver, but
that seems independent enough that it should be sent on its own.
> > > With this all said -- I noticed iasl prints this statement when trying
> > > to create a node with a lowercase name:
> > > "At least one lower case letter found in NameSeg, ASL is case
> > > insensitive - converting to upper case (GPIO)"
> >
> > Yes, because it should be in the upper case.
> >
> > > I wonder if this suggests that adding a call to toupper() to
> > > acpi_fwnode_get_named_child_node would be
> > > an appropriate solution for the node name casing issue....
> >
> > I dunno. You need to ask in the linux-acpi@ mailing list.
> > To me this is corner case that can't be easily solved
> > (because two different specifications treat it differently.
> >
> > You also need to ask DT people about capital letters there.
> > And my guts tell me that it's probably also carved in the spec
> > as "must be lower case" or alike.
>
> FWIW while trying to enable this, at some point I named the I2C and the
> GPIO entries "I2C0" and "GPI0" (with the number '0', not the letter
> 'o'), and it was not working as you would expect.
>
> It is commonly accepted in the ACPI world that the names do not carry
> meaning AFAICT, and so I think I agree with Andy's initial comment
> regarding using indexes, not names to also fetch the I2C and GPIO nodes.
> You can probably have a fallback mechanism for when "i2c" is not
> present, or simply check if you are in DT or not and use the names only
> if we are in DT.
More and more, after actually seeing and working with ACPI, I suspect that
you both are right. Maybe (hopefully) though, there is some unified way that can
be made to do this, so that individual drivers won't have to directly code for /
be aware of the differences in the firmware languages (at least, that seemed
to be the intent of the fw_node/device api in the first place). Maybe a
`device_get_child_by_name_or_index` (terribly long name) sort of function
might fill in that gap?
I plan to send an email asking this question more generically to ACPI & DT folks
as Andy suggested, so hopefully there will be some ideas.
>
> Thanks a lot to both of you, this will be tremendously helpful to me.
>
> Cheers,
> Benjamin
>
Thanks for testing this out! Glad that ACPI support ended up being worked into
this after all :)
^ permalink raw reply
* Re: [PATCH v8 3/3] HID: cp2112: Fwnode Support
From: Benjamin Tissoires @ 2023-03-07 14:48 UTC (permalink / raw)
To: Daniel Kaehn
Cc: Andy Shevchenko, Hans de Goede, robh+dt, krzysztof.kozlowski+dt,
jikos, bartosz.golaszewski, dmitry.torokhov, devicetree,
linux-input, ethan.twardy
In-Reply-To: <CAP+ZCCcbXqPOY5Xzq9v8JNSzH9+xOqgfkTezJdLQY=vwQco4vQ@mail.gmail.com>
On Mar 07 2023, Daniel Kaehn wrote:
> On Tue, Mar 7, 2023 at 7:17 AM Benjamin Tissoires
> <benjamin.tissoires@redhat.com> wrote:
> >
> > On Mar 06 2023, Andy Shevchenko wrote:
> > > On Mon, Mar 06, 2023 at 01:40:16PM -0600, Daniel Kaehn wrote:
> > >
> > > ...
> > >
> > > > Device (SE9)
> > > > {
> > > > Name (_ADR, 0x001D0001) // _ADR: Address
> > > > Device (RHUB)
> > > > {
> > > > Name (_ADR, Zero)
> > > > Device (CP2) // the USB-hid & CP2112 shared node
> > > > {
> > > > Name (_ADR, One)
> > > > }
> > > > }
> > > > }
> > > >
> > > > If I'm understanding correctly, this adds the SE9 device as function 1
> > > > of PCI device 0x1d,
> > >
> > > To be precise this does not add the device. It adds a description of
> > > the companion device in case the real one will appear on the PCI bus
> > > with BDF 00:1d.1.
> > >
> > > > then RHUB as the USB controller it provides, and finally, CP2 as the
> > > > USB device attached to port 1 of the controller.
> > > >
> > > > With this as the loaded dsdt table, the USB device now has a firmware_node :)
> > > > #> cat /sys/bus/usb/devices/3-1:1.0/firmware_node/path
> > > > \_SB_.PCI0.SE9_.RHUB.CP2_
> > > >
> > > > After applying my patches, the HID device also references this node:
> > > > #> cat /sys/bus/hid/devices/0003:10C4:EA90.0003/firmware_node/path
> > > > \_SB_.PCI0.SE9_.RHUB.CP2_
> > > >
> >
> > Great! Thanks a lot for that. Turns out that with both of your inputs I
> > can also do the same, but without the need for OVMF and DSDT patching,
> > with just an SSDT override.
> >
> Ah, interesting.. I tried the SSDT override route initially, but tried
> applying it
> through EFI variables and through configfs, neither of which worked since
> they appeared to be applied after the relevant drivers were already loaded
> (at least that was my suspicion). I wonder if loading the overlay through the
> initramfs was the key.
Yeah, there were a few items missing from a "blank" qemu:
- loading the SSDT overlay in the initramfs so it's seen before anything
else
- actually define the description of the device in the DSDT at the
matching PCI bus address
- your patch :)
>
> > Turns out that the override documentation [1] mentions "This option
> > allows loading of user defined SSDTs from initrd and it is useful when
> > the system does not support EFI or ..."
> >
> > FWIW, I am attaching my full DSDT override in case it is valuable:
> > (on my system, the default USB controller (non-xhc) is at PCI address
> > 1.2, which explains the slight difference). It can be loaded in the same
> > way you are overriding the full DSDT, but with just that compilation
> > output:
> >
> > ---
> > DefinitionBlock ("cp2112.aml", "SSDT", 5, "", "CP2112", 1)
> > {
> > External (_SB_.PCI0, DeviceObj)
> >
> > Scope (\_SB_.PCI0)
> > {
> > Device (USB0)
> > {
> > Name (_ADR, 0x00010002) // _ADR: Address
> > Device (RHUB)
> > {
> > Name (_ADR, Zero)
> > Device (CP21) // the USB-hid & CP2112 shared node
> > {
> > Name (_ADR, One)
> > Device (I2C)
> > {
> > Name (_ADR, Zero)
> > Name (_STA, 0x0F)
> > }
> >
> > Device (GPIO)
> > {
> > Name (_ADR, One)
> > Name (_STA, 0x0F)
> > }
> > }
> > }
> > }
> > }
>
> To get this to work -- I assume you had to change the driver to look
> for uppercase
> "GPIO" and "I2C", or some similar change?
>
>
> >
> > Scope (\_SB_.PCI0.USB0.RHUB.CP21.I2C)
> > {
> > Device (TPD0)
> > {
> > Name (_HID, "RMI40001")
> > Name (_CID, "PNP0C50")
> > Name (_STA, 0x0F)
> >
> > Name (SBFB, ResourceTemplate ()
> > {
> > I2cSerialBusV2 (0x00c, ControllerInitiated, 100000,
> > AddressingMode7Bit, "\\_SB_.PCI0.USB0.RHUB.CP21.I2C",
> > 0x00, ResourceConsumer,, Exclusive,
> > )
> > })
> > Name (SBFG, ResourceTemplate ()
> > {
> > GpioInt (Level, ActiveLow, Exclusive, PullDefault, 0x0000,
> > "\\_SB_.PCI0.USB0.RHUB.CP21.GPIO", 0x00, ResourceConsumer, ,
> > )
> > { // Pin list
> > 0x0002
> > }
> > })
> > Method(_CRS, 0x0, NotSerialized)
> > {
> > Return (ConcatenateResTemplate (SBFB, SBFG))
> > }
> >
> > Method(_DSM, 0x4, Serialized)
> > {
> > // DSM UUID
> > switch (ToBuffer (Arg0))
> > {
> > // ACPI DSM UUID for HIDI2C
> > case (ToUUID ("3CDFF6F7-4267-4555-AD05-B30A3D8938DE"))
> > {
> > // DSM Function
> > switch (ToInteger (Arg2))
> > {
> > // Function 0: Query function, return based on revision
> > case(0)
> > {
> > // DSM Revision
> > switch (ToInteger (Arg1))
> > {
> > // Revision 1: Function 1 supported
> > case (1)
> > {
> > Return (Buffer (One) { 0x03 })
> > }
> >
> > default
> > {
> > // Revision 2+: no functions supported
> > Return (Buffer (One) { 0x00 })
> > }
> > }
> > }
> >
> > // Function 1 : HID Function
> > case(1)
> > {
> > // HID Descriptor Address
> > Return (0x0020)
> > }
> >
> > default
> > {
> > // Functions 2+: not supported
> > Return (Buffer (One) { 0x00 })
> > }
> > }
> > }
> >
> > default
> > {
> > // No other GUIDs supported
> > Return (Buffer (One) { 0x00 })
> > }
> > }
> > }
> > }
> > }
> > }
> > ---
> >
> > This almost works. Almost because the I2C device is correctly created,
> > but I have an issue with the GpioInt call which is not properly set by
> > the kernel and which returns -EDEFER. /o\
> >
>
> Ahh, yep, I've had this issue as well -- I suspect the issue you're
> having is that the
> CP2112 driver initializes the i2c controller before the gpiochip, and
> if any i2c devices
> on the bus depend on the CP2112's gpio, the probe will never succeed!
> I have made
> and been testing with a patch to fix this, but since it was midway
> through submitting
> this series, thought it might be bad practice to "tack on" additional
> patches to a patchset
> mid-review (since it only causes an issue in some (admittedly fairly
> common) use-cases)
> so I was going to send it as an individual patch once (if) these were applied.
>
I don't think this is the issue. When the device is initially probed,
the I2C acpi implementation tries to attach an IRQ, but failed at it,
returning -EPROBE_DEFER, which makes the device being retried a few
times.
After I get my shell available I even get the pr_err I included few
seconds later, for a last attempt by the kernel to bind it when
everything has settled.
So I can see that the device gets probed, and that all ACPI resources
are tried to get the IRQ.
Right now, I see that it's attempting to bind to the acpi resource in
acpi_dev_resource_interrupt() (in file drivers/acpi/resources.c), but
instead of having a ACPI_RESOURCE_TYPE_EXTENDED_IRQ I only get a
ACPI_RESOURCE_TYPE_GPIO for the GpioInt() definition in the _CRS method.
So I am missing the proper transition from GpioInt to IRQ in the acpi.
Note that I tried applying what was describe at
Documentation/firmware_guide/acpi/gpio-properties.rst but the _DSD
method doesn't seem to be properly applied to the CP2112 GPIO, which is
highly suspicious.
> If you think that would be necessary to include for these to merge,
> I'd be happy to append
> it to this review. I also have another patch which adds i2c bus
> recovery to the driver, but
> that seems independent enough that it should be sent on its own.
As I mentioned above I don't think the issue is in the ordering of the
I2C vs gpio resources.
>
> > > > With this all said -- I noticed iasl prints this statement when trying
> > > > to create a node with a lowercase name:
> > > > "At least one lower case letter found in NameSeg, ASL is case
> > > > insensitive - converting to upper case (GPIO)"
> > >
> > > Yes, because it should be in the upper case.
> > >
> > > > I wonder if this suggests that adding a call to toupper() to
> > > > acpi_fwnode_get_named_child_node would be
> > > > an appropriate solution for the node name casing issue....
> > >
> > > I dunno. You need to ask in the linux-acpi@ mailing list.
> > > To me this is corner case that can't be easily solved
> > > (because two different specifications treat it differently.
> > >
> > > You also need to ask DT people about capital letters there.
> > > And my guts tell me that it's probably also carved in the spec
> > > as "must be lower case" or alike.
> >
> > FWIW while trying to enable this, at some point I named the I2C and the
> > GPIO entries "I2C0" and "GPI0" (with the number '0', not the letter
> > 'o'), and it was not working as you would expect.
> >
> > It is commonly accepted in the ACPI world that the names do not carry
> > meaning AFAICT, and so I think I agree with Andy's initial comment
> > regarding using indexes, not names to also fetch the I2C and GPIO nodes.
> > You can probably have a fallback mechanism for when "i2c" is not
> > present, or simply check if you are in DT or not and use the names only
> > if we are in DT.
>
> More and more, after actually seeing and working with ACPI, I suspect that
> you both are right. Maybe (hopefully) though, there is some unified way that can
> be made to do this, so that individual drivers won't have to directly code for /
> be aware of the differences in the firmware languages (at least, that seemed
> to be the intent of the fw_node/device api in the first place). Maybe a
> `device_get_child_by_name_or_index` (terribly long name) sort of function
> might fill in that gap?
I don't know. Though the _DSD documentation I mentioned above looks very
similar to what you are describing in the DT case, so maybe the ACPI
folks will just tell us "why don't you use XXXX?" and we will have the
solution :) (we can't be the first to have that same issue TBH)
>
> I plan to send an email asking this question more generically to ACPI & DT folks
> as Andy suggested, so hopefully there will be some ideas.
>
> >
> > Thanks a lot to both of you, this will be tremendously helpful to me.
> >
> > Cheers,
> > Benjamin
> >
> Thanks for testing this out! Glad that ACPI support ended up being worked into
> this after all :)
Cheers,
Benjamin
^ permalink raw reply
* [PATCH v3 1/2] Input: hideep - Silence error in SW_RESET()
From: Hans de Goede @ 2023-03-07 15:57 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Hans de Goede, linux-input
In-Reply-To: <20230307155755.136968-1-hdegoede@redhat.com>
On some models the first HIDEEP_SYSCON_WDT_CON write alone is enough to
cause the controller to reset, causing the second write to fail:
i2c-hideep_ts: write to register 0x52000014 (0x000001) failed: -121
Switch this write to a raw hideep_pgm_w_mem() to avoid an error getting
logged in this case.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/input/touchscreen/hideep.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/hideep.c b/drivers/input/touchscreen/hideep.c
index ff4bb4c14898..373c1269485f 100644
--- a/drivers/input/touchscreen/hideep.c
+++ b/drivers/input/touchscreen/hideep.c
@@ -271,9 +271,14 @@ static int hideep_pgm_w_reg(struct hideep_ts *ts, u32 addr, u32 val)
#define SW_RESET_IN_PGM(clk) \
{ \
+ __be32 data = cpu_to_be32(0x01); \
hideep_pgm_w_reg(ts, HIDEEP_SYSCON_WDT_CNT, (clk)); \
hideep_pgm_w_reg(ts, HIDEEP_SYSCON_WDT_CON, 0x03); \
- hideep_pgm_w_reg(ts, HIDEEP_SYSCON_WDT_CON, 0x01); \
+ /* \
+ * The first write may already cause a reset, use a raw \
+ * write for the second write to avoid error logging. \
+ */ \
+ hideep_pgm_w_mem(ts, HIDEEP_SYSCON_WDT_CON, &data, 1); \
}
#define SET_FLASH_PIO(ce) \
--
2.39.1
^ permalink raw reply related
* [PATCH v3 0/2] Input: hideep - 2 HiDeep touchscreen patches
From: Hans de Goede @ 2023-03-07 15:57 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Hans de Goede, linux-input
Hi Dmitry,
Here are 2 patches for the HiDeep touchscreen driver.
Changes in v3:
- Do not add the x86/acpi only "hideep,reset-work-mode" property to
the dt-bindings doc
Changes in v2:
- Add "Optionally reset controller work mode to native HiDeep protocol"
patch
Regards,
Hans
Hans de Goede (2):
Input: hideep - Silence error in SW_RESET()
Input: hideep - Optionally reset controller work mode to native HiDeep
protocol
drivers/input/touchscreen/hideep.c | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
--
2.39.1
^ permalink raw reply
* [PATCH v3 2/2] Input: hideep - Optionally reset controller work mode to native HiDeep protocol
From: Hans de Goede @ 2023-03-07 15:57 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Hans de Goede, linux-input
In-Reply-To: <20230307155755.136968-1-hdegoede@redhat.com>
The HiDeep IST940E touchscreen controller used on the Lenovo Yoga Book X90F
convertible comes up in HID mode by default.
This works well on the X91F Windows model where the touchscreen is
correctly described in ACPI and ACPI takes care of controlling
the reset GPIO and regulators.
But the X90F ships with Android and the ACPI tables on this model don't
describe the touchscreen. Instead this is hardcoded in the vendor kernel.
The vendor kernel uses the touchscreen in native HiDeep 20 (2.0?) protocol
mode and switches the controller to this mode by writing 0 to reg 0x081e.
Adjusting the i2c-hid code to deal with the reset-gpio and regulators on
this non devicetree (but rather broken ACPI) convertible is somewhat tricky
and the native protocol reports ABS_MT_PRESSURE and ABS_MT_TOUCH_MAJOR
which are not reported in HID mode, so it is preferable to use the native
mode.
Add support to the hideep driver to reset the work-mode to the native
HiDeep protocol to allow using it on the Lenovo Yoga Book X90F.
This is guarded behind a new "hideep,reset-work-mode" boolean property,
to avoid changing behavior on other devices.
For the record: I did test using the i2c-hid driver with some quick hacks
and it does work. The I2C-HID descriptor is available from address 0x0020,
just like on the X91F Windows model.
So far the new "hideep,reset-work-mode" property is only used on x86/ACPI
(non devicetree) devs. IOW it is not used in actual devicetree files.
The devicetree-bindings maintainers have requested properties like these
to not be added to the devicetree-bindings, so the new property is
deliberately not added to the existing devicetree-bindings.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v3:
- Do not add the x86/acpi only property to the dt-bindings doc
Changes in v2:
- New patch in v2 of this patch-set
---
drivers/input/touchscreen/hideep.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/input/touchscreen/hideep.c b/drivers/input/touchscreen/hideep.c
index 373c1269485f..452914b78bf9 100644
--- a/drivers/input/touchscreen/hideep.c
+++ b/drivers/input/touchscreen/hideep.c
@@ -35,6 +35,7 @@
#define HIDEEP_EVENT_ADDR 0x240
/* command list */
+#define HIDEEP_WORK_MODE 0x081e
#define HIDEEP_RESET_CMD 0x9800
/* event bit */
@@ -964,6 +965,17 @@ static const struct attribute_group hideep_ts_attr_group = {
.attrs = hideep_ts_sysfs_entries,
};
+static void hideep_set_work_mode(struct hideep_ts *ts)
+{
+ /*
+ * Reset touch report format to the native HiDeep 20 protocol if requested.
+ * This is necessary to make touchscreens which come up in I2C-HID mode
+ * work with this driver.
+ */
+ if (device_property_read_bool(&ts->client->dev, "hideep,reset-work-mode"))
+ regmap_write(ts->reg, HIDEEP_WORK_MODE, 0x00);
+}
+
static int __maybe_unused hideep_suspend(struct device *dev)
{
struct i2c_client *client = to_i2c_client(dev);
@@ -987,6 +999,8 @@ static int __maybe_unused hideep_resume(struct device *dev)
return error;
}
+ hideep_set_work_mode(ts);
+
enable_irq(client->irq);
return 0;
@@ -1063,6 +1077,8 @@ static int hideep_probe(struct i2c_client *client)
return error;
}
+ hideep_set_work_mode(ts);
+
error = hideep_init_input(ts);
if (error)
return error;
--
2.39.1
^ permalink raw reply related
* Re: [PATCH v8 3/3] HID: cp2112: Fwnode Support
From: Andy Shevchenko @ 2023-03-07 18:14 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Daniel Kaehn, Hans de Goede, robh+dt, krzysztof.kozlowski+dt,
jikos, bartosz.golaszewski, dmitry.torokhov, devicetree,
linux-input, ethan.twardy
In-Reply-To: <20230307131706.olnb4qzo4ynu7gce@mail.corp.redhat.com>
On Tue, Mar 07, 2023 at 02:17:06PM +0100, Benjamin Tissoires wrote:
> On Mar 06 2023, Andy Shevchenko wrote:
> > On Mon, Mar 06, 2023 at 01:40:16PM -0600, Daniel Kaehn wrote:
...
> This almost works. Almost because the I2C device is correctly created,
> but I have an issue with the GpioInt call which is not properly set by
> the kernel and which returns -EDEFER. /o\
You can try to utilize _DEP method, but I dunno if it implemented that way in
the Linux that helps your case.
> > > With this all said -- I noticed iasl prints this statement when trying
> > > to create a node with a lowercase name:
> > > "At least one lower case letter found in NameSeg, ASL is case
> > > insensitive - converting to upper case (GPIO)"
> >
> > Yes, because it should be in the upper case.
> >
> > > I wonder if this suggests that adding a call to toupper() to
> > > acpi_fwnode_get_named_child_node would be
> > > an appropriate solution for the node name casing issue....
> >
> > I dunno. You need to ask in the linux-acpi@ mailing list.
> > To me this is corner case that can't be easily solved
> > (because two different specifications treat it differently.
> >
> > You also need to ask DT people about capital letters there.
> > And my guts tell me that it's probably also carved in the spec
> > as "must be lower case" or alike.
>
> FWIW while trying to enable this, at some point I named the I2C and the
> GPIO entries "I2C0" and "GPI0" (with the number '0', not the letter
> 'o'), and it was not working as you would expect.
>
> It is commonly accepted in the ACPI world that the names do not carry
> meaning AFAICT, and so I think I agree with Andy's initial comment
> regarding using indexes, not names to also fetch the I2C and GPIO nodes.
> You can probably have a fallback mechanism for when "i2c" is not
> present, or simply check if you are in DT or not and use the names only
> if we are in DT.
The solution is to provide in the main node the list of cell names, that way
you will always know the indices:
Device (DEV) {
_DSD
"cell-names" { "i2c", "gpio" } // index of the name is the
// index of the cell
Device (I2C0) {
}
Device (GPI0) {
}
}
Problem solved.
> Thanks a lot to both of you, this will be tremendously helpful to me.
You're welcome!
> [1] https://www.kernel.org/doc/html/latest/admin-guide/acpi/ssdt-overlays.html#loading-acpi-ssdts-from-initrd
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v8 3/3] HID: cp2112: Fwnode Support
From: Andy Shevchenko @ 2023-03-07 18:15 UTC (permalink / raw)
To: Daniel Kaehn
Cc: Benjamin Tissoires, Hans de Goede, robh+dt,
krzysztof.kozlowski+dt, jikos, bartosz.golaszewski,
dmitry.torokhov, devicetree, linux-input, ethan.twardy
In-Reply-To: <CAP+ZCCcbXqPOY5Xzq9v8JNSzH9+xOqgfkTezJdLQY=vwQco4vQ@mail.gmail.com>
On Tue, Mar 07, 2023 at 07:53:20AM -0600, Daniel Kaehn wrote:
> On Tue, Mar 7, 2023 at 7:17 AM Benjamin Tissoires
> <benjamin.tissoires@redhat.com> wrote:
...
> More and more, after actually seeing and working with ACPI, I suspect that
> you both are right. Maybe (hopefully) though, there is some unified way that can
> be made to do this, so that individual drivers won't have to directly code for /
> be aware of the differences in the firmware languages (at least, that seemed
> to be the intent of the fw_node/device api in the first place). Maybe a
> `device_get_child_by_name_or_index` (terribly long name) sort of function
> might fill in that gap?
Look also at the solution I proposed in response to Benjamin in my previous
email.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v8 3/3] HID: cp2112: Fwnode Support
From: Andy Shevchenko @ 2023-03-07 18:18 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Daniel Kaehn, Hans de Goede, robh+dt, krzysztof.kozlowski+dt,
jikos, bartosz.golaszewski, dmitry.torokhov, devicetree,
linux-input, ethan.twardy
In-Reply-To: <20230307144852.ueyaotkeeqfjlgk7@mail.corp.redhat.com>
On Tue, Mar 07, 2023 at 03:48:52PM +0100, Benjamin Tissoires wrote:
> On Mar 07 2023, Daniel Kaehn wrote:
...
> So I can see that the device gets probed, and that all ACPI resources
> are tried to get the IRQ.
> Right now, I see that it's attempting to bind to the acpi resource in
> acpi_dev_resource_interrupt() (in file drivers/acpi/resources.c), but
> instead of having a ACPI_RESOURCE_TYPE_EXTENDED_IRQ I only get a
> ACPI_RESOURCE_TYPE_GPIO for the GpioInt() definition in the _CRS method.
>
> So I am missing the proper transition from GpioInt to IRQ in the acpi.
I'm not sure I understand what this means.
The Linux kernel takes either Interrupt() resource (which is
IOxAPIC / GIC / etc) or GpioInt() (which is GPIO based).
In both cases I²C framework submits this into client's IRQ field.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v8 3/3] HID: cp2112: Fwnode Support
From: Daniel Kaehn @ 2023-03-07 19:57 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Benjamin Tissoires, Hans de Goede, robh+dt,
krzysztof.kozlowski+dt, jikos, bartosz.golaszewski,
dmitry.torokhov, devicetree, linux-input, ethan.twardy
In-Reply-To: <ZAd+/fHeQ3zuvoTN@smile.fi.intel.com>
On Tue, Mar 7, 2023 at 12:14 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Tue, Mar 07, 2023 at 02:17:06PM +0100, Benjamin Tissoires wrote:
> > On Mar 06 2023, Andy Shevchenko wrote:
> > It is commonly accepted in the ACPI world that the names do not carry
> > meaning AFAICT, and so I think I agree with Andy's initial comment
> > regarding using indexes, not names to also fetch the I2C and GPIO nodes.
> > You can probably have a fallback mechanism for when "i2c" is not
> > present, or simply check if you are in DT or not and use the names only
> > if we are in DT.
>
> The solution is to provide in the main node the list of cell names, that way
> you will always know the indices:
>
> Device (DEV) {
> _DSD
> "cell-names" { "i2c", "gpio" } // index of the name is the
> // index of the cell
>
> Device (I2C0) {
> }
>
> Device (GPI0) {
> }
> }
>
> Problem solved.
>
Just to make sure I'm understanding you correctly:
Are you proposing that specifically this driver directly reads "cell-names"
from the ACPI DSD to implement this indexing? Or are you proposing a
kernel-wide mechanism of "overriding" a fwnode name with ACPI?
(assuming this doesn't exist already, and I'm not just missing it in
the kernel source)
Or are you proposing something else entirely?
(apologies if this should be obvious -- throwing up the ACPI newbie
card again here :) )
In any case, would this be something I should post to the email chain
with DT and ACPI
folks for opinions before I start to implement it?
Thanks,
Danny Kaehn
^ permalink raw reply
* Re: [PATCH v0 0/2] HID: nintendo: avoid BT rumble disconnections
From: Silvan Jegen @ 2023-03-07 21:03 UTC (permalink / raw)
To: Daniel J. Ogorchock
Cc: linux-input, jikos, benjamin.tissoires, Roderick.Colenbrander
In-Reply-To: <20230203215119.435091-1-djogorchock@gmail.com>
Hi
"Daniel J. Ogorchock" <djogorchock@gmail.com> wrote:
> The hid-nintendo driver has been plagued by an issue where rumble
> command traffic to bluetooth-connected controllers can cause frequent
> power downs of the controllers.
>
> Digging into other pro controller driver implementations, I've not found
> anything that hid-nintendo is doing incorrectly. Some implementations
> seem to be working around the same problem (e.g. libsdl's hidapi
> implementation rate limits rumble commands to avoid the problem).
>
> [...]
>
> Daniel J. Ogorchock (2):
> HID: nintendo: prevent rumble queue overruns
> HID: nintendo: fix rumble rate limiter
>
> drivers/hid/hid-nintendo.c | 95 ++++++++++++++++++++++++++++++++++----
> 1 file changed, 86 insertions(+), 9 deletions(-)
I haven't tested this but the code of this series looks good to me.
Reviewed-by: Silvan Jegen <s.jegen@gmail.com>
^ permalink raw reply
* Re: [PATCH v0 0/2] HID: nintendo: avoid BT rumble disconnections
From: Silvan Jegen @ 2023-03-07 21:06 UTC (permalink / raw)
To: Daniel J. Ogorchock
Cc: linux-input, jikos, benjamin.tissoires, Roderick.Colenbrander
In-Reply-To: <20230203215119.435091-1-djogorchock@gmail.com>
"Daniel J. Ogorchock" <djogorchock@gmail.com> wrote:
> The hid-nintendo driver has been plagued by an issue where rumble
> command traffic to bluetooth-connected controllers can cause frequent
> power downs of the controllers.
>
> [...]
>
> My suspicion is that the core issue is somewhere in the bluez stack. My
> next step is to investigate that lead in more detail. This patchset at
> least allows for use of the controllers via bluetooth with rumble
> enabled without frequently disconnecting.
>
> Daniel J. Ogorchock (2):
> HID: nintendo: prevent rumble queue overruns
> HID: nintendo: fix rumble rate limiter
>
> drivers/hid/hid-nintendo.c | 95 ++++++++++++++++++++++++++++++++++----
> 1 file changed, 86 insertions(+), 9 deletions(-)
I haven't tested this but the code looks good to me.
Reviewed-by: Silvan Jegen <s.jegen@gmail.com>
^ permalink raw reply
* [PATCH v2] Add rumble support to latest xbox controllers
From: Siarhei Vishniakou @ 2023-03-07 21:35 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, linux-input, linux-kernel
Cc: Siarhei Vishniakou
Currently, rumble is only supported via bluetooth on a single xbox
controller, called 'model 1708'. On the back of the device, it's named
'wireless controller for xbox one'. However, in 2021, Microsoft released
a firmware update for this controller. As part of this update, the HID
descriptor of the device changed. The product ID was also changed from
0x02fd to 0x0b20. On this controller, rumble was supported via
hid-microsoft, which matched against the old product id (0x02fd). As a
result, the firmware update broke rumble support on this controller.
The hid-microsoft driver actually supports rumble on the new firmware,
as well. So simply adding new product id is sufficient to bring back
this support.
After discussing further with the xbox team, it was pointed out that
another xbox controller, xbox elite series 2, can be supported in a
similar way.
Add rumble support for all of these devices in this patch. Two of the
devices have received firmware updates that caused their product id's to
change. Both old and new firmware versions of these devices were tested.
The tested controllers are:
1. 'wireless controller for xbox one', model 1708
2. 'xbox wireless controller', model 1914. This is also sometimes
referred to as 'xbox series S|X'.
3. 'elite series 2', model 1797.
The tested configurations are:
1. model 1708, pid 0x02fd (old firmware)
2. model 1708, pid 0x0b20 (new firmware)
3. model 1914, pid 0x0b13
4. model 1797, pid 0x0b05 (old firmware)
5. model 1797, pid 0x0b22 (new firmware)
I verified rumble support on both bluetooth and usb.
Signed-off-by: Siarhei Vishniakou <svv@google.com>
Change-Id: I3337a7ab5f40759c85bf67bf0dbe5d4de31ce1ff
---
drivers/hid/hid-ids.h | 6 +++++-
drivers/hid/hid-microsoft.c | 11 ++++++++++-
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 053853a891c5..c9b75f8ba49a 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -903,7 +903,11 @@
#define USB_DEVICE_ID_MS_TYPE_COVER_2 0x07a9
#define USB_DEVICE_ID_MS_POWER_COVER 0x07da
#define USB_DEVICE_ID_MS_SURFACE3_COVER 0x07de
-#define USB_DEVICE_ID_MS_XBOX_ONE_S_CONTROLLER 0x02fd
+#define USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1708 0x02fd
+#define USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1708_BLE 0x0b20
+#define USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1914 0x0b13
+#define USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1797 0x0b05
+#define USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1797_BLE 0x0b22
#define USB_DEVICE_ID_MS_PIXART_MOUSE 0x00cb
#define USB_DEVICE_ID_8BITDO_SN30_PRO_PLUS 0x02e0
diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
index 071fd093a5f4..9345e2bfd56e 100644
--- a/drivers/hid/hid-microsoft.c
+++ b/drivers/hid/hid-microsoft.c
@@ -446,7 +446,16 @@ static const struct hid_device_id ms_devices[] = {
.driver_data = MS_PRESENTER },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, 0x091B),
.driver_data = MS_SURFACE_DIAL },
- { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_XBOX_ONE_S_CONTROLLER),
+
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1708),
+ .driver_data = MS_QUIRK_FF },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1708_BLE),
+ .driver_data = MS_QUIRK_FF },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1914),
+ .driver_data = MS_QUIRK_FF },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1797),
+ .driver_data = MS_QUIRK_FF },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1797_BLE),
.driver_data = MS_QUIRK_FF },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_8BITDO_SN30_PRO_PLUS),
.driver_data = MS_QUIRK_FF },
--
2.40.0.rc0.216.gc4246ad0f0-goog
^ permalink raw reply related
* RE: [PATCH v5 3/3] arm64: dts: imx93: Add the bbnsm dts node
From: Jacky Bai @ 2023-03-08 9:58 UTC (permalink / raw)
To: lee@kernel.org, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, dmitry.torokhov@gmail.com,
a.zummo@towertech.it, alexandre.belloni@bootlin.com
Cc: devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-input@vger.kernel.org, linux-rtc@vger.kernel.org,
kernel@pengutronix.de, dl-linux-imx, festevam@gmail.com
In-Reply-To: <20230215024117.3357341-4-ping.bai@nxp.com>
Hi Shawn,
Can you help pick this patch?
BR
> Subject: [PATCH v5 3/3] arm64: dts: imx93: Add the bbnsm dts node
>
> Add the bbnsm node for RTC & ON/OFF button support
>
> Signed-off-by: Jacky Bai <ping.bai@nxp.com>
> ---
> - v5 changes: no
>
> - v4 changes:
> - update the compatible string to align with binding file
>
> - v3 changes:
> - remove 'nxp,bbnsm-regmap' property to align with binding doc
>
> - v2 changes:
> - update the regmap property to align with binding doc
> ---
> arch/arm64/boot/dts/freescale/imx93.dtsi | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx93.dtsi
> b/arch/arm64/boot/dts/freescale/imx93.dtsi
> index 2076f9c9983a..e772c136e895 100644
> --- a/arch/arm64/boot/dts/freescale/imx93.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx93.dtsi
> @@ -243,6 +243,22 @@ iomuxc: pinctrl@443c0000 {
> status = "okay";
> };
>
> + bbnsm: bbnsm@44440000 {
> + compatible = "nxp,imx93-bbnsm", "syscon", "simple-mfd";
> + reg = <0x44440000 0x10000>;
> +
> + bbnsm_rtc: rtc {
> + compatible = "nxp,imx93-bbnsm-rtc";
> + interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + bbnsm_pwrkey: pwrkey {
> + compatible = "nxp,imx93-bbnsm-pwrkey";
> + interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
> + linux,code = <KEY_POWER>;
> + };
> + };
> +
> clk: clock-controller@44450000 {
> compatible = "fsl,imx93-ccm";
> reg = <0x44450000 0x10000>;
> --
> 2.34.1
^ permalink raw reply
* Re: [GIT PULL] intel-gpio for 6.3-1
From: Bartosz Golaszewski @ 2023-03-08 10:03 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Arnd Bergmann, Linus Walleij, open list:GPIO SUBSYSTEM,
linux-arm-kernel, linux-input, Dmitry Torokhov
In-Reply-To: <ZAcjM5Ceivzyghcf@smile.fi.intel.com>
On Tue, Mar 7, 2023 at 12:42 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Tue, Mar 07, 2023 at 11:51:44AM +0200, Andy Shevchenko wrote:
> > On Tue, Mar 7, 2023 at 10:09 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Mon, Mar 6, 2023, at 23:35, andy.shevchenko@gmail.com wrote:
> > > > Mon, Mar 06, 2023 at 10:50:40PM +0100, Linus Walleij kirjoitti:
> > > >> On Mon, Mar 6, 2023 at 4:14 PM Andy Shevchenko
> > > >> <andriy.shevchenko@linux.intel.com> wrote:
> > > >>
> > > >> > Hi Linux GPIO maintainers et al.,
> > > >> >
> > > >> > Combined series to clean up headers in the GPIO library and drivers.
> > > >> > Along with it, drop a few unused legacy APIs.
> > > >> >
> > > >> > This tag is immutable, enjoy!
> > > >>
> > > >> Thanks for coordinating and getting this sorted and tested Andy, perfect
> > > >> job as always!
> > > >
> > > > You're welcome!
> > > >
> > > >> > intel-gpio for v6.3-1
> > > >>
> > > >> But I think you mean it for v6.4?
> > > >
> > > > Well, techically speaking it didn't make v6.3-rc1 due to cross-dependencies.
> > > > Starting from it it may be applied to v6.3 or to v6.4.
> > > >
> > > > Up to you and Bart, but I prefer not to rebrand the tag, if it's an option.
> > >
> > > I think it was clear that this would not make it into 6.3 after
> > > the decision to rebase on top of 6.3-rc1. However, the tag name
> > > and description both look like they make sense for 6.4 the way
> > > you wrote them.
> >
> > Okay, I will rre-tag this.
>
> Now it's tagged as intel-gpio-v6.4-1. Should I send a new PR?
>
Yes, please.
Bart
^ permalink raw reply
* Re: [GIT PULL] intel-gpio for 6.4-1
From: Bartosz Golaszewski @ 2023-03-08 10:09 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Linux GPIO, linux-arm-kernel, linux-input, Linus Walleij,
Arnd Bergmann, Dmitry Torokhov
In-Reply-To: <ZAc7VMQouzAB/Sk+@black.fi.intel.com>
On Tue, Mar 7, 2023 at 2:25 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> Hi Linux GPIO maintainers et al.,
>
> Combined series to clean up headers in the GPIO library and drivers.
> Along with it, drop a few unused legacy APIs.
>
> This tag is immutable, enjoy!
>
> Thanks,
>
> With Best Regards,
> Andy Shevchenko
>
> The following changes since commit fe15c26ee26efa11741a7b632e9f23b01aca4cc6:
>
> Linux 6.3-rc1 (2023-03-05 14:52:03 -0800)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-gpio-intel.git tags/intel-gpio-v6.4-1
>
> for you to fetch changes up to 380c7ba3923c6e471aff0f951a6cf42e8dec2c79:
>
> gpiolib: Clean up headers (2023-03-06 12:33:02 +0200)
>
Pulled, thanks!
Bart
^ permalink raw reply
* Re: [PATCH v2] Add rumble support to latest xbox controllers
From: Bastien Nocera @ 2023-03-08 10:22 UTC (permalink / raw)
To: Siarhei Vishniakou, Jiri Kosina, Benjamin Tissoires, linux-input,
linux-kernel
In-Reply-To: <20230307213536.2299487-1-svv@google.com>
On Tue, 2023-03-07 at 13:35 -0800, Siarhei Vishniakou wrote:
> Currently, rumble is only supported via bluetooth on a single xbox
> controller, called 'model 1708'. On the back of the device, it's
> named
> 'wireless controller for xbox one'. However, in 2021, Microsoft
> released
> a firmware update for this controller. As part of this update, the
> HID
> descriptor of the device changed. The product ID was also changed
> from
> 0x02fd to 0x0b20. On this controller, rumble was supported via
> hid-microsoft, which matched against the old product id (0x02fd). As
> a
> result, the firmware update broke rumble support on this controller.
>
> The hid-microsoft driver actually supports rumble on the new
> firmware,
> as well. So simply adding new product id is sufficient to bring back
> this support.
>
> After discussing further with the xbox team, it was pointed out that
> another xbox controller, xbox elite series 2, can be supported in a
> similar way.
>
> Add rumble support for all of these devices in this patch. Two of the
> devices have received firmware updates that caused their product id's
> to
> change. Both old and new firmware versions of these devices were
> tested.
>
> The tested controllers are:
>
> 1. 'wireless controller for xbox one', model 1708
> 2. 'xbox wireless controller', model 1914. This is also sometimes
> referred to as 'xbox series S|X'.
> 3. 'elite series 2', model 1797.
>
> The tested configurations are:
> 1. model 1708, pid 0x02fd (old firmware)
> 2. model 1708, pid 0x0b20 (new firmware)
> 3. model 1914, pid 0x0b13
> 4. model 1797, pid 0x0b05 (old firmware)
> 5. model 1797, pid 0x0b22 (new firmware)
>
> I verified rumble support on both bluetooth and usb.
Looks good although I would personally have preferred separate patches
for each controller.
Reviewed-by: Bastien Nocera <hadess@hadess.net>
Would a link to:
https://en.wikipedia.org/wiki/Xbox_Wireless_Controller#Summary
also be useful to make which model is which clearer in the minds of
future readers?
Cheers
>
> Signed-off-by: Siarhei Vishniakou <svv@google.com>
> Change-Id: I3337a7ab5f40759c85bf67bf0dbe5d4de31ce1ff
> ---
> drivers/hid/hid-ids.h | 6 +++++-
> drivers/hid/hid-microsoft.c | 11 ++++++++++-
> 2 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 053853a891c5..c9b75f8ba49a 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -903,7 +903,11 @@
> #define USB_DEVICE_ID_MS_TYPE_COVER_2 0x07a9
> #define USB_DEVICE_ID_MS_POWER_COVER 0x07da
> #define USB_DEVICE_ID_MS_SURFACE3_COVER 0x07de
> -#define USB_DEVICE_ID_MS_XBOX_ONE_S_CONTROLLER 0x02fd
> +#define USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1708 0x02fd
> +#define
> USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1708_BLE 0x0b20
> +#define USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1914 0x0b13
> +#define USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1797 0x0b05
> +#define
> USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1797_BLE 0x0b22
> #define USB_DEVICE_ID_MS_PIXART_MOUSE 0x00cb
> #define USB_DEVICE_ID_8BITDO_SN30_PRO_PLUS 0x02e0
>
> diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-
> microsoft.c
> index 071fd093a5f4..9345e2bfd56e 100644
> --- a/drivers/hid/hid-microsoft.c
> +++ b/drivers/hid/hid-microsoft.c
> @@ -446,7 +446,16 @@ static const struct hid_device_id ms_devices[] =
> {
> .driver_data = MS_PRESENTER },
> { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, 0x091B),
> .driver_data = MS_SURFACE_DIAL },
> - { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT,
> USB_DEVICE_ID_MS_XBOX_ONE_S_CONTROLLER),
> +
> + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT,
> USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1708),
> + .driver_data = MS_QUIRK_FF },
> + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT,
> USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1708_BLE),
> + .driver_data = MS_QUIRK_FF },
> + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT,
> USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1914),
> + .driver_data = MS_QUIRK_FF },
> + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT,
> USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1797),
> + .driver_data = MS_QUIRK_FF },
> + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT,
> USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1797_BLE),
> .driver_data = MS_QUIRK_FF },
> { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT,
> USB_DEVICE_ID_8BITDO_SN30_PRO_PLUS),
> .driver_data = MS_QUIRK_FF },
^ permalink raw reply
* RE: [PATCH v5 3/3] arm64: dts: imx93: Add the bbnsm dts node
From: Alexander Stein @ 2023-03-08 10:32 UTC (permalink / raw)
To: lee@kernel.org, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, dmitry.torokhov@gmail.com,
a.zummo@towertech.it, alexandre.belloni@bootlin.com,
linux-arm-kernel
Cc: devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-input@vger.kernel.org, linux-rtc@vger.kernel.org,
kernel@pengutronix.de, dl-linux-imx, festevam@gmail.com,
Jacky Bai
In-Reply-To: <AM9PR04MB8650E01C4772DF3D48A3564587B49@AM9PR04MB8650.eurprd04.prod.outlook.com>
Hi,
Am Mittwoch, 8. März 2023, 10:58:00 CET schrieb Jacky Bai:
> Hi Shawn,
>
> Can you help pick this patch?
Just for completeness:
Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com>
on TQMa93xx
Best regards,
Alexander
> BR
>
> > Subject: [PATCH v5 3/3] arm64: dts: imx93: Add the bbnsm dts node
> >
> > Add the bbnsm node for RTC & ON/OFF button support
> >
> > Signed-off-by: Jacky Bai <ping.bai@nxp.com>
> > ---
> >
> > - v5 changes: no
> >
> > - v4 changes:
> > - update the compatible string to align with binding file
> >
> > - v3 changes:
> > - remove 'nxp,bbnsm-regmap' property to align with binding doc
> >
> > - v2 changes:
> > - update the regmap property to align with binding doc
> >
> > ---
> >
> > arch/arm64/boot/dts/freescale/imx93.dtsi | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx93.dtsi
> > b/arch/arm64/boot/dts/freescale/imx93.dtsi
> > index 2076f9c9983a..e772c136e895 100644
> > --- a/arch/arm64/boot/dts/freescale/imx93.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx93.dtsi
> > @@ -243,6 +243,22 @@ iomuxc: pinctrl@443c0000 {
> >
> > status = "okay";
> >
> > };
> >
> > + bbnsm: bbnsm@44440000 {
> > + compatible = "nxp,imx93-bbnsm",
"syscon", "simple-mfd";
> > + reg = <0x44440000 0x10000>;
> > +
> > + bbnsm_rtc: rtc {
> > + compatible = "nxp,imx93-
bbnsm-rtc";
> > + interrupts = <GIC_SPI 73
IRQ_TYPE_LEVEL_HIGH>;
> > + };
> > +
> > + bbnsm_pwrkey: pwrkey {
> > + compatible = "nxp,imx93-
bbnsm-pwrkey";
> > + interrupts = <GIC_SPI 73
IRQ_TYPE_LEVEL_HIGH>;
> > + linux,code = <KEY_POWER>;
> > + };
> > + };
> > +
> >
> > clk: clock-controller@44450000 {
> >
> > compatible = "fsl,imx93-ccm";
> > reg = <0x44450000 0x10000>;
> >
> > --
> > 2.34.1
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
^ permalink raw reply
* Re: [PATCH v8 3/3] HID: cp2112: Fwnode Support
From: Andy Shevchenko @ 2023-03-08 12:41 UTC (permalink / raw)
To: Daniel Kaehn
Cc: Benjamin Tissoires, Hans de Goede, robh+dt,
krzysztof.kozlowski+dt, jikos, bartosz.golaszewski,
dmitry.torokhov, devicetree, linux-input, ethan.twardy
In-Reply-To: <CAP+ZCCe6mdtNmg0QEtQKFCKMyhM9xRffFoMHtxHEGnjNOEAedg@mail.gmail.com>
On Tue, Mar 07, 2023 at 01:57:27PM -0600, Daniel Kaehn wrote:
> On Tue, Mar 7, 2023 at 12:14 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Tue, Mar 07, 2023 at 02:17:06PM +0100, Benjamin Tissoires wrote:
> > > On Mar 06 2023, Andy Shevchenko wrote:
...
> > > It is commonly accepted in the ACPI world that the names do not carry
> > > meaning AFAICT, and so I think I agree with Andy's initial comment
> > > regarding using indexes, not names to also fetch the I2C and GPIO nodes.
> > > You can probably have a fallback mechanism for when "i2c" is not
> > > present, or simply check if you are in DT or not and use the names only
> > > if we are in DT.
> >
> > The solution is to provide in the main node the list of cell names, that way
> > you will always know the indices:
> >
> > Device (DEV) {
> > _DSD
> > "cell-names" { "i2c", "gpio" } // index of the name is the
> > // index of the cell
> >
> > Device (I2C0) {
> > }
> >
> > Device (GPI0) {
> > }
> > }
> >
> > Problem solved.
>
> Just to make sure I'm understanding you correctly:
>
> Are you proposing that specifically this driver directly reads "cell-names"
> from the ACPI DSD to implement this indexing? Or are you proposing a
> kernel-wide mechanism of "overriding" a fwnode name with ACPI?
> (assuming this doesn't exist already, and I'm not just missing it in
> the kernel source)
>
> Or are you proposing something else entirely?
> (apologies if this should be obvious -- throwing up the ACPI newbie
> card again here :) )
Out of the three listed above I'm proposing the first one.
(Maybe it can be called 'reg-names', but it depends on the hardware)
Also look into hierarchical _DSD (it is similar to the children
of the device node without being separate devices).
> In any case, would this be something I should post to the email chain
> with DT and ACPI
> folks for opinions before I start to implement it?
May be, the -names approach is already used widely for clock, interrupt, reset,
phy and nvmem. So it's something we know about.
--
With Best Regards,
Andy Shevchenko
^ 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