* Re: hid-logitech-dj support for Anywhere 3SB
From: Allan Sandfeld Jensen @ 2024-04-13 8:52 UTC (permalink / raw)
To: linux-input, Filipe Laíns
In-Reply-To: <7f829b15729acba79d24299da0c12cbfead175c5.camel@riseup.net>
[-- Attachment #1: Type: text/plain, Size: 5324 bytes --]
On Saturday 13 April 2024 10:33:29 CEST Filipe Laíns wrote:
> On Sat, 2024-04-13 at 10:20 +0200, Allan Sandfeld Jensen wrote:
> > On Friday 12 April 2024 21:53:31 CEST Filipe Laíns wrote:
> > > On Fri, 2024-04-12 at 11:10 +0200, Allan Sandfeld Jensen wrote:
> > > > Hello,
> > > >
> > > > I am writing because you are listed as author of the hid-logitech-dj
> > > > driver. I recently bought a Logitech Anywhere 3SB mouse, and found
> > > > Linux
> > > > didn't recognize it. Thinking it was a simple case of new IDs not
> > > > recognized, I quickly added them to the logitch HID++ drivers (patch
> > > > attached), both for USB with the new receiver and for the Bluetooth
> > > > direct connection.
> > > >
> > > > I have noticed however that the patch while causing them to be
> > > > recognized
> > > > and interacted with as HID++ devices, it has a flaw. The scroll wheel
> > > > events are reported by the linux kernel as being in hires mode, while
> > > > haven't actually enabled it on the mouse. You can fix that using
> > > > Solaar,
> > > > but some piece is missing to enable it correctly in the driver. Since
> > > > this is no longer a trivial fix. I wanted to reach out. Do you have
> > > > any
> > > > suggestions?
> > > >
> > > > Best regards
> > > > Allan
> > >
> > > Hi Allan,
> > >
> > > Thank you for reaching out.
> > >
> > > What likely is happening here is Solaar overwriting the configuration
> > > that
> > > the kernel driver sets, as that would happen after the driver talks to
> > > the
> > > device.
> > >
> > > The settings in question need support in both the kernel and the
> > > userspace
> > > input stack (libinput) for them to work appropriately, it's not like
> > > configuring RGB or other sort setting on the device that works
> > > standalone.
> >
> > We already have the support in the kernel and libinput. That is why I am
> > expanding it to recognize this new device id.(?)
>
> Yes, that sounds right.
>
> > > I have, multiple times now, asked for Solaar to not expose these low
> > > level
> > > settings that need support from other parts of the input stack, leaving
> > > them to the kernel to configure.
> > > I have been inactive in the Solaar project for quite some time now, so I
> > > don't feel like yet again make a big deal out of this there, so that
> > > this
> > > decision is reconsidered. I have already spent a significant amount of
> > > effort there, and nowadays I barely have energy to go through my day and
> > > deal with my all my responsibilities and other OSS project involvements,
> > > so
> > > I sadly have no more energy to spare there.
> > >
> > > My recommendation is: disable Solaar from running at startup, restart
> > > the
> > > system, and see if that solves your problem. If it does, report this
> > > issue
> > > again to the Solaar upstream, then depending on that outcome, make a
> > > decision on how to proceed. It may be that setting the high-resolution
> > > settings in Solaar, which are expected by the driver, works, but it
> > > might
> > > not be super reliable, because since Solaar is overwriting the settings
> > > configured by the kernel driver, if anything in the kernel driver
> > > changes,
> > > then the setting you have configured in Solaar might no longer be
> > > correct.
> > > There are alternatives to Solaar that do not have this issue, like
> > > libratbag, but these generally are feature lacking on the productivity
> > > line
> > > of Logitech projects.
> > >
> > > Sorry I wasn't able to help much, but I hope that this clarifies things
> > > a
> > > bit, and helps you solve your problem.
> >
> > Thanks. You are right, it works with solaar uninstalled, I only installed
> > it to check the details of a device not recognized by the kernel.
> >
> > So the patch as send to you before is then upstreamable. Is there anything
> > more I need to do, to facilitate the upstreaming?
> >
> > Best regards
> > Allan
>
> Great to hear!
>
> The patch you sent seems pretty good for upstreaming, I would maybe just
> split the Makefile changes into a separate patch and submit those
> separately, if that's something you actually want to upstream.
> Additionally, it seems to me like the mouse can work wired, so I would also
> add the USB PID of the wired connection to the hidpp driver, that way
> everything should work as expected on all interfaces.
>
Right. I thought I had remove those changes. I had the weirdest issue when
building the kernel, where echo wouldn't terminate. It worked when I replaced
echo with another command, so I ended up using perl -e print. Still no idea, I
assume some interaction between my shell and the combination of quiet and echo
in a Makefile, but it doesnt matter, not part of the patch.
It doesn't seem like the mouse communicates over the USB cable, only draws
power. This appears consistent with my old Anywhere 2S mouse.
So where should I send the patch now? It has been at least 15 years since I
contributed anything to the kernel, and I understand sending patches to the
central mailing list is frowned upon now. Do you take if from here, or do I
need to send it to a submodule maintainer above you?
Best regards
Allan
[-- Attachment #2: 0002-Logitech-Anywhere-3SB-support.patch --]
[-- Type: text/x-patch, Size: 3678 bytes --]
From f998faa55c4f5988a958f7af50eacfcb0452451c Mon Sep 17 00:00:00 2001
From: Allan Sandfeld Jensen <allan.jensen@qt.io>
Date: Wed, 10 Apr 2024 15:23:40 +0200
Subject: [PATCH 2/2] Logitech Anywhere 3SB support
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-logitech-dj.c | 10 +++++++++-
drivers/hid/hid-logitech-hidpp.c | 2 ++
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 2235d78784b1..4b79c4578d32 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -849,6 +849,7 @@
#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1 0xc539
#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1_1 0xc53f
#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_POWERPLAY 0xc53a
+#define USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER 0xc548
#define USB_DEVICE_ID_SPACETRAVELLER 0xc623
#define USB_DEVICE_ID_SPACENAVIGATOR 0xc626
#define USB_DEVICE_ID_DINOVO_DESKTOP 0xc704
diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index c358778e070b..92b41ae5a47c 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -120,6 +120,7 @@ enum recvr_type {
recvr_type_27mhz,
recvr_type_bluetooth,
recvr_type_dinovo,
+ recvr_type_bolt,
};
struct dj_report {
@@ -1068,6 +1069,7 @@ static void logi_hidpp_recv_queue_notif(struct hid_device *hdev,
workitem.reports_supported |= STD_KEYBOARD;
break;
case 0x0f:
+ case 0x10:
case 0x11:
device_type = "eQUAD Lightspeed 1.2";
logi_hidpp_dev_conn_notif_equad(hdev, hidpp_report, &workitem);
@@ -1430,7 +1432,8 @@ static int logi_dj_ll_parse(struct hid_device *hid)
dbg_hid("%s: sending a mouse descriptor, reports_supported: %llx\n",
__func__, djdev->reports_supported);
if (djdev->dj_receiver_dev->type == recvr_type_gaming_hidpp ||
- djdev->dj_receiver_dev->type == recvr_type_mouse_only)
+ djdev->dj_receiver_dev->type == recvr_type_mouse_only ||
+ djdev->dj_receiver_dev->type == recvr_type_bolt)
rdcat(rdesc, &rsize, mse_high_res_descriptor,
sizeof(mse_high_res_descriptor));
else if (djdev->dj_receiver_dev->type == recvr_type_27mhz)
@@ -1773,6 +1776,7 @@ static int logi_dj_probe(struct hid_device *hdev,
case recvr_type_dj: no_dj_interfaces = 3; break;
case recvr_type_hidpp: no_dj_interfaces = 2; break;
case recvr_type_gaming_hidpp: no_dj_interfaces = 3; break;
+ case recvr_type_bolt: no_dj_interfaces = 4; break;
case recvr_type_mouse_only: no_dj_interfaces = 2; break;
case recvr_type_27mhz: no_dj_interfaces = 2; break;
case recvr_type_bluetooth: no_dj_interfaces = 2; break;
@@ -1950,6 +1954,10 @@ static const struct hid_device_id logi_dj_receivers[] = {
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_UNIFYING_RECEIVER_2),
.driver_data = recvr_type_dj},
+ { /* Logitech bolt receiver (0xc548) */
+ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
+ USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER),
+ .driver_data = recvr_type_bolt},
{ /* Logitech Nano mouse only receiver (0xc52f) */
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 3c00e6ac8e76..509142982daa 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -4380,6 +4380,8 @@ static const struct hid_device_id hidpp_devices[] = {
HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb023) },
{ /* MX Master 3S mouse over Bluetooth */
HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb034) },
+ { /* MX Anywhere 3SB mouse over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb038) },
{}
};
--
2.39.2
^ permalink raw reply related
* Re: hid-logitech-dj support for Anywhere 3SB
From: Filipe Laíns @ 2024-04-13 9:25 UTC (permalink / raw)
To: Allan Sandfeld Jensen, linux-input
In-Reply-To: <10451816.nUPlyArG6x@twilight>
[-- Attachment #1: Type: text/plain, Size: 6640 bytes --]
On Sat, 2024-04-13 at 10:52 +0200, Allan Sandfeld Jensen wrote:
> On Saturday 13 April 2024 10:33:29 CEST Filipe Laíns wrote:
> > On Sat, 2024-04-13 at 10:20 +0200, Allan Sandfeld Jensen wrote:
> > > On Friday 12 April 2024 21:53:31 CEST Filipe Laíns wrote:
> > > > On Fri, 2024-04-12 at 11:10 +0200, Allan Sandfeld Jensen wrote:
> > > > > Hello,
> > > > >
> > > > > I am writing because you are listed as author of the hid-logitech-dj
> > > > > driver. I recently bought a Logitech Anywhere 3SB mouse, and found
> > > > > Linux
> > > > > didn't recognize it. Thinking it was a simple case of new IDs not
> > > > > recognized, I quickly added them to the logitch HID++ drivers (patch
> > > > > attached), both for USB with the new receiver and for the Bluetooth
> > > > > direct connection.
> > > > >
> > > > > I have noticed however that the patch while causing them to be
> > > > > recognized
> > > > > and interacted with as HID++ devices, it has a flaw. The scroll wheel
> > > > > events are reported by the linux kernel as being in hires mode, while
> > > > > haven't actually enabled it on the mouse. You can fix that using
> > > > > Solaar,
> > > > > but some piece is missing to enable it correctly in the driver. Since
> > > > > this is no longer a trivial fix. I wanted to reach out. Do you have
> > > > > any
> > > > > suggestions?
> > > > >
> > > > > Best regards
> > > > > Allan
> > > >
> > > > Hi Allan,
> > > >
> > > > Thank you for reaching out.
> > > >
> > > > What likely is happening here is Solaar overwriting the configuration
> > > > that
> > > > the kernel driver sets, as that would happen after the driver talks to
> > > > the
> > > > device.
> > > >
> > > > The settings in question need support in both the kernel and the
> > > > userspace
> > > > input stack (libinput) for them to work appropriately, it's not like
> > > > configuring RGB or other sort setting on the device that works
> > > > standalone.
> > >
> > > We already have the support in the kernel and libinput. That is why I am
> > > expanding it to recognize this new device id.(?)
> >
> > Yes, that sounds right.
> >
> > > > I have, multiple times now, asked for Solaar to not expose these low
> > > > level
> > > > settings that need support from other parts of the input stack, leaving
> > > > them to the kernel to configure.
> > > > I have been inactive in the Solaar project for quite some time now, so I
> > > > don't feel like yet again make a big deal out of this there, so that
> > > > this
> > > > decision is reconsidered. I have already spent a significant amount of
> > > > effort there, and nowadays I barely have energy to go through my day and
> > > > deal with my all my responsibilities and other OSS project involvements,
> > > > so
> > > > I sadly have no more energy to spare there.
> > > >
> > > > My recommendation is: disable Solaar from running at startup, restart
> > > > the
> > > > system, and see if that solves your problem. If it does, report this
> > > > issue
> > > > again to the Solaar upstream, then depending on that outcome, make a
> > > > decision on how to proceed. It may be that setting the high-resolution
> > > > settings in Solaar, which are expected by the driver, works, but it
> > > > might
> > > > not be super reliable, because since Solaar is overwriting the settings
> > > > configured by the kernel driver, if anything in the kernel driver
> > > > changes,
> > > > then the setting you have configured in Solaar might no longer be
> > > > correct.
> > > > There are alternatives to Solaar that do not have this issue, like
> > > > libratbag, but these generally are feature lacking on the productivity
> > > > line
> > > > of Logitech projects.
> > > >
> > > > Sorry I wasn't able to help much, but I hope that this clarifies things
> > > > a
> > > > bit, and helps you solve your problem.
> > >
> > > Thanks. You are right, it works with solaar uninstalled, I only installed
> > > it to check the details of a device not recognized by the kernel.
> > >
> > > So the patch as send to you before is then upstreamable. Is there anything
> > > more I need to do, to facilitate the upstreaming?
> > >
> > > Best regards
> > > Allan
> >
> > Great to hear!
> >
> > The patch you sent seems pretty good for upstreaming, I would maybe just
> > split the Makefile changes into a separate patch and submit those
> > separately, if that's something you actually want to upstream.
> > Additionally, it seems to me like the mouse can work wired, so I would also
> > add the USB PID of the wired connection to the hidpp driver, that way
> > everything should work as expected on all interfaces.
> >
> Right. I thought I had remove those changes. I had the weirdest issue when
> building the kernel, where echo wouldn't terminate. It worked when I replaced
> echo with another command, so I ended up using perl -e print. Still no idea, I
> assume some interaction between my shell and the combination of quiet and echo
> in a Makefile, but it doesnt matter, not part of the patch.
>
> It doesn't seem like the mouse communicates over the USB cable, only draws
> power. This appears consistent with my old Anywhere 2S mouse.
>
> So where should I send the patch now? It has been at least 15 years since I
> contributed anything to the kernel, and I understand sending patches to the
> central mailing list is frowned upon now. Do you take if from here, or do I
> need to send it to a submodule maintainer above you?
>
> Best regards
> Allan
>
The standard practice is to run scripts/get_maintainer.pl to find the
recipients. In your case:
$ scripts/get_maintainer.pl drivers/hid/hid-logitech-hidpp.c
"Filipe Laíns" <lains@riseup.net> (reviewer:HID LOGITECH DRIVERS)
Bastien Nocera <hadess@hadess.net> (reviewer:HID++ LOGITECH DRIVERS)
Jiri Kosina <jikos@kernel.org> (maintainer:HID CORE LAYER)
Benjamin Tissoires <benjamin.tissoires@redhat.com> (maintainer:HID CORE LAYER)
linux-input@vger.kernel.org (open list:HID LOGITECH DRIVERS)
linux-kernel@vger.kernel.org (open list)
$ scripts/get_maintainer.pl drivers/hid/hid-logitech-dj.c
"Filipe Laíns" <lains@riseup.net> (reviewer:HID LOGITECH DRIVERS)
Jiri Kosina <jikos@kernel.org> (maintainer:HID CORE LAYER)
Benjamin Tissoires <benjamin.tissoires@redhat.com> (maintainer:HID CORE LAYER)
linux-input@vger.kernel.org (open list:HID LOGITECH DRIVERS)
linux-kernel@vger.kernel.org (open list)
Then you can just git-send-mail to all the recipients listed there.
Cheers,
Filipe Laíns
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] Logitech Anywhere 3SB support
From: kde @ 2024-04-13 9:54 UTC (permalink / raw)
To: lains, hadess, jikos, benjamin.tissoires, linux-input,
linux-kernel
Cc: Allan Sandfeld Jensen
From: Allan Sandfeld Jensen <allan.jensen@qt.io>
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-logitech-dj.c | 10 +++++++++-
drivers/hid/hid-logitech-hidpp.c | 2 ++
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 2235d78784b1..4b79c4578d32 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -849,6 +849,7 @@
#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1 0xc539
#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1_1 0xc53f
#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_POWERPLAY 0xc53a
+#define USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER 0xc548
#define USB_DEVICE_ID_SPACETRAVELLER 0xc623
#define USB_DEVICE_ID_SPACENAVIGATOR 0xc626
#define USB_DEVICE_ID_DINOVO_DESKTOP 0xc704
diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index c358778e070b..92b41ae5a47c 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -120,6 +120,7 @@ enum recvr_type {
recvr_type_27mhz,
recvr_type_bluetooth,
recvr_type_dinovo,
+ recvr_type_bolt,
};
struct dj_report {
@@ -1068,6 +1069,7 @@ static void logi_hidpp_recv_queue_notif(struct hid_device *hdev,
workitem.reports_supported |= STD_KEYBOARD;
break;
case 0x0f:
+ case 0x10:
case 0x11:
device_type = "eQUAD Lightspeed 1.2";
logi_hidpp_dev_conn_notif_equad(hdev, hidpp_report, &workitem);
@@ -1430,7 +1432,8 @@ static int logi_dj_ll_parse(struct hid_device *hid)
dbg_hid("%s: sending a mouse descriptor, reports_supported: %llx\n",
__func__, djdev->reports_supported);
if (djdev->dj_receiver_dev->type == recvr_type_gaming_hidpp ||
- djdev->dj_receiver_dev->type == recvr_type_mouse_only)
+ djdev->dj_receiver_dev->type == recvr_type_mouse_only ||
+ djdev->dj_receiver_dev->type == recvr_type_bolt)
rdcat(rdesc, &rsize, mse_high_res_descriptor,
sizeof(mse_high_res_descriptor));
else if (djdev->dj_receiver_dev->type == recvr_type_27mhz)
@@ -1773,6 +1776,7 @@ static int logi_dj_probe(struct hid_device *hdev,
case recvr_type_dj: no_dj_interfaces = 3; break;
case recvr_type_hidpp: no_dj_interfaces = 2; break;
case recvr_type_gaming_hidpp: no_dj_interfaces = 3; break;
+ case recvr_type_bolt: no_dj_interfaces = 4; break;
case recvr_type_mouse_only: no_dj_interfaces = 2; break;
case recvr_type_27mhz: no_dj_interfaces = 2; break;
case recvr_type_bluetooth: no_dj_interfaces = 2; break;
@@ -1950,6 +1954,10 @@ static const struct hid_device_id logi_dj_receivers[] = {
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_UNIFYING_RECEIVER_2),
.driver_data = recvr_type_dj},
+ { /* Logitech bolt receiver (0xc548) */
+ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
+ USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER),
+ .driver_data = recvr_type_bolt},
{ /* Logitech Nano mouse only receiver (0xc52f) */
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 3c00e6ac8e76..509142982daa 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -4380,6 +4380,8 @@ static const struct hid_device_id hidpp_devices[] = {
HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb023) },
{ /* MX Master 3S mouse over Bluetooth */
HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb034) },
+ { /* MX Anywhere 3SB mouse over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb038) },
{}
};
--
2.39.2
^ permalink raw reply related
* [PATCH] HID: hid-debug: fix Moir -> Moire typo
From: Thomas Kuehne @ 2024-04-13 12:20 UTC (permalink / raw)
To: jikos, bentiss; +Cc: linux-input
This adds the letter "e" to fix hid_usage_table' HorizontalMoir and
VerticalMoir entries.
Signed-off-by: ThomasKuehne <2562574+ThomasKuehne@users.noreply.github.com>
---
drivers/hid/hid-debug.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c
index add353a17853..a62e71a5ccef 100644
--- a/drivers/hid/hid-debug.c
+++ b/drivers/hid/hid-debug.c
@@ -2361,8 +2361,8 @@ static const struct hid_usage_entry hid_usage_table[] = {
{ 0x82, 0x0048, "TopCornerDistortionBalance" },
{ 0x82, 0x004a, "BottomCornerDistortionControl" },
{ 0x82, 0x004c, "BottomCornerDistortionBalance" },
- { 0x82, 0x0056, "HorizontalMoir" },
- { 0x82, 0x0058, "VerticalMoir" },
+ { 0x82, 0x0056, "HorizontalMoire" },
+ { 0x82, 0x0058, "VerticalMoire" },
{ 0x82, 0x005e, "InputLevelSelect" },
{ 0x82, 0x0060, "InputSourceSelect" },
{ 0x82, 0x006c, "RedVideoBlackLevel" },
base-commit: 9ed46da14b9b9b2ad4edb3b0c545b6dbe5c00d39
--
2.40.1
^ permalink raw reply related
* [PATCH] HID: hid-debug: more informative output for EV_KEY
From: Thomas Kuehne @ 2024-04-13 12:23 UTC (permalink / raw)
To: jikos, bentiss; +Cc: linux-input, linux-kernel
Currently hid-debug's hid_resolv_event prints questions marks for
all entries without explicit mapping information. This makes
debugging unnecessarily complicated as multiple different
keys may simply result in the same uninformative output.
Some common event codes are deliberately not defined in
input-event-codes.h. For example the 16th gamepad key.
Instead, print the hexadecimal codes for all events without symbolic
names.
Signed-off-by: Thomas Kuehne <thomas.kuehne@gmx.li>
---
drivers/hid/hid-debug.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c
index add353a17853..0a0c435a1284 100644
--- a/drivers/hid/hid-debug.c
+++ b/drivers/hid/hid-debug.c
@@ -3582,8 +3582,15 @@ static const char **names[EV_MAX + 1] = {
static void hid_resolv_event(__u8 type, __u16 code, struct seq_file *f)
{
- seq_printf(f, "%s.%s", events[type] ? events[type] : "?",
- names[type] ? (names[type][code] ? names[type][code] : "?") : "?");
+ if (events[type])
+ seq_printf(f, "%s.", events[type]);
+ else
+ seq_printf(f, "%02x.", type);
+
+ if (names[type] && names[type][code])
+ seq_printf(f, "%s", names[type][code]);
+ else
+ seq_printf(f, "%04x", code);
}
static void hid_dump_input_mapping(struct hid_device *hid, struct seq_file *f)
base-commit: 9ed46da14b9b9b2ad4edb3b0c545b6dbe5c00d39
--
2.40.1
^ permalink raw reply related
* [PATCH] HID: hid-debug: add EV_FF and FF_STATUS mappings
From: Thomas Kuehne @ 2024-04-13 12:39 UTC (permalink / raw)
To: jikos, bentiss; +Cc: linux-input, linux-kernel
Currently hid-debug only output question marks for all force
feedback related input mapping making debugging gamepads
with force feedback a challenge.
This adds the necessary mapping information to output
EV_FF and FF_STATUS related information.
Signed-off-by: Thomas Kuehne <thomas.kuehne@gmx.li>
---
drivers/hid/hid-debug.c | 28 +++++++++++++++++++++++++++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c
index add353a17853..bd9bb235363f 100644
--- a/drivers/hid/hid-debug.c
+++ b/drivers/hid/hid-debug.c
@@ -3572,12 +3572,38 @@ static const char *software[SW_CNT] = {
[SW_MACHINE_COVER] = "MachineCover",
};
+static const char *force[FF_CNT] = {
+ [FF_RUMBLE] = "FF_RUMBLE",
+ [FF_PERIODIC] = "FF_PERIODIC",
+ [FF_CONSTANT] = "FF_CONSTANT",
+ [FF_SPRING] = "FF_SPRING",
+ [FF_FRICTION] = "FF_FRICTION",
+ [FF_DAMPER] = "FF_DAMPER",
+ [FF_INERTIA] = "FF_INERTIA",
+ [FF_RAMP] = "FF_RAMP",
+ [FF_SQUARE] = "FF_SQUARE",
+ [FF_TRIANGLE] = "FF_TRIANGLE",
+ [FF_SINE] = "FF_SINE",
+ [FF_SAW_UP] = "FF_SAW_UP",
+ [FF_SAW_DOWN] = "FF_SAW_DOWN",
+ [FF_CUSTOM] = "FF_CUSTOM",
+ [FF_GAIN] = "FF_GAIN",
+ [FF_AUTOCENTER] = "FF_AUTOCENTER",
+ [FF_MAX] = "FF_MAX",
+};
+
+static const char *force_status[FF_STATUS_MAX + 1] = {
+ [FF_STATUS_STOPPED] = "FF_STATUS_STOPPED",
+ [FF_STATUS_PLAYING] = "FF_STATUS_PLAYING",
+};
+
static const char **names[EV_MAX + 1] = {
[EV_SYN] = syncs, [EV_KEY] = keys,
[EV_REL] = relatives, [EV_ABS] = absolutes,
[EV_MSC] = misc, [EV_LED] = leds,
[EV_SND] = sounds, [EV_REP] = repeats,
- [EV_SW] = software,
+ [EV_SW] = software, [EV_FF] = force,
+ [EV_FF_STATUS] = force_status,
};
static void hid_resolv_event(__u8 type, __u16 code, struct seq_file *f)
base-commit: 9ed46da14b9b9b2ad4edb3b0c545b6dbe5c00d39
--
2.40.1
^ permalink raw reply related
* [PATCH RESEND] HID: sony: Remove usage of the deprecated ida_simple_xx() API
From: Christophe JAILLET @ 2024-04-14 9:58 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: linux-kernel, kernel-janitors, Christophe JAILLET, linux-input
ida_alloc() and ida_free() should be preferred to the deprecated
ida_simple_get() and ida_simple_remove().
This is less verbose.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
This patch has been sent about 3 months ago [1].
A gentle reminder has been sent 1 month later [2].
Neither one got any reply.
So, I'm adding Andrew Morton in To:, in order to help in the merge process.
Context:
=======
All patches to remove the ida_simple API have been sent.
Matthew Wilcox seems happy with the on going work. (see [3])
Based on next-20240412
$git grep ida_simple_get | wc -l
25
Based on next-20240220
$git grep ida_simple_get | wc -l
36
https://elixir.bootlin.com/linux/v6.8-rc3/A/ident/ida_simple_get
50
https://elixir.bootlin.com/linux/v6.7.4/A/ident/ida_simple_get
81
Thanks
CJ
[1]: https://lore.kernel.org/all/9c092dc6db15984d98732510bb052bb00683489b.1705005258.git.christophe.jaillet@wanadoo.fr/https://lore.kernel.org/all/19b538bc05c11747a3dd9fa204fde91942063d52.1698831460.git.christophe.jaillet@wanadoo.fr/
[2]: https://lore.kernel.org/all/a1af20a9-951f-4a5d-8a60-04ded8d6f9a0@wanadoo.fr/
[3]: https://lore.kernel.org/all/ZaqruGVz734zjxrZ@casper.infradead.org/
---
drivers/hid/hid-sony.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index ebc0aa4e4345..55c0ad61d524 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -1844,8 +1844,7 @@ static int sony_set_device_id(struct sony_sc *sc)
* All others are set to -1.
*/
if (sc->quirks & SIXAXIS_CONTROLLER) {
- ret = ida_simple_get(&sony_device_id_allocator, 0, 0,
- GFP_KERNEL);
+ ret = ida_alloc(&sony_device_id_allocator, GFP_KERNEL);
if (ret < 0) {
sc->device_id = -1;
return ret;
@@ -1861,7 +1860,7 @@ static int sony_set_device_id(struct sony_sc *sc)
static void sony_release_device_id(struct sony_sc *sc)
{
if (sc->device_id >= 0) {
- ida_simple_remove(&sony_device_id_allocator, sc->device_id);
+ ida_free(&sony_device_id_allocator, sc->device_id);
sc->device_id = -1;
}
}
--
2.44.0
^ permalink raw reply related
* [PATCH RESEND] HID: sony: Remove usage of the deprecated ida_simple_xx() API
From: Christophe JAILLET @ 2024-04-14 10:03 UTC (permalink / raw)
To: akpm, Jiri Kosina, Benjamin Tissoires
Cc: linux-kernel, kernel-janitors, Christophe JAILLET, linux-input
ida_alloc() and ida_free() should be preferred to the deprecated
ida_simple_get() and ida_simple_remove().
This is less verbose.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
This patch has been sent about 3 months ago [1].
A gentle reminder has been sent 1 month later [2].
Neither one got any reply.
So, I'm adding Andrew Morton in To:, in order to help in the merge process.
Context:
=======
All patches to remove the ida_simple API have been sent.
Matthew Wilcox seems happy with the on going work. (see [3])
Based on next-20240412
$git grep ida_simple_get | wc -l
25
Based on next-20240220
$git grep ida_simple_get | wc -l
36
https://elixir.bootlin.com/linux/v6.8-rc3/A/ident/ida_simple_get
50
https://elixir.bootlin.com/linux/v6.7.4/A/ident/ida_simple_get
81
Thanks
CJ
[1]: https://lore.kernel.org/all/9c092dc6db15984d98732510bb052bb00683489b.1705005258.git.christophe.jaillet@wanadoo.fr/https://lore.kernel.org/all/19b538bc05c11747a3dd9fa204fde91942063d52.1698831460.git.christophe.jaillet@wanadoo.fr/
[2]: https://lore.kernel.org/all/a1af20a9-951f-4a5d-8a60-04ded8d6f9a0@wanadoo.fr/
[3]: https://lore.kernel.org/all/ZaqruGVz734zjxrZ@casper.infradead.org/
---
drivers/hid/hid-sony.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index ebc0aa4e4345..55c0ad61d524 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -1844,8 +1844,7 @@ static int sony_set_device_id(struct sony_sc *sc)
* All others are set to -1.
*/
if (sc->quirks & SIXAXIS_CONTROLLER) {
- ret = ida_simple_get(&sony_device_id_allocator, 0, 0,
- GFP_KERNEL);
+ ret = ida_alloc(&sony_device_id_allocator, GFP_KERNEL);
if (ret < 0) {
sc->device_id = -1;
return ret;
@@ -1861,7 +1860,7 @@ static int sony_set_device_id(struct sony_sc *sc)
static void sony_release_device_id(struct sony_sc *sc)
{
if (sc->device_id >= 0) {
- ida_simple_remove(&sony_device_id_allocator, sc->device_id);
+ ida_free(&sony_device_id_allocator, sc->device_id);
sc->device_id = -1;
}
}
--
2.44.0
^ permalink raw reply related
* [PATCH v1] HID: playstation: DS4: Fix calibration workaround for clone devices
From: Max Staudt @ 2024-04-14 16:12 UTC (permalink / raw)
To: Roderick Colenbrander, Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, max
The logic in dualshock4_get_calibration_data() used uninitialised data
in case of a failed kzalloc() for the transfer buffer.
The solution is to group all business logic and all sanity checks
together, and jump only to the latter in case of an error.
While we're at it, factor out the axes' labelling, since it must happen
either way for input_report_abs() to succeed later on.
Thanks to Dan Carpenter for the Smatch static checker warning.
Fixes: a48a7cd85f55 ("HID: playstation: DS4: Don't fail on calibration data request")
Signed-off-by: Max Staudt <max@enpas.org>
---
drivers/hid/hid-playstation.c | 63 ++++++++++++++++++-----------------
1 file changed, 33 insertions(+), 30 deletions(-)
diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index edc46fc02e9a..998e79be45ac 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -1787,7 +1787,7 @@ static int dualshock4_get_calibration_data(struct dualshock4 *ds4)
buf = kzalloc(DS4_FEATURE_REPORT_CALIBRATION_SIZE, GFP_KERNEL);
if (!buf) {
ret = -ENOMEM;
- goto no_buffer_tail_check;
+ goto transfer_failed;
}
/* We should normally receive the feature report data we asked
@@ -1807,6 +1807,7 @@ static int dualshock4_get_calibration_data(struct dualshock4 *ds4)
hid_warn(hdev, "Failed to retrieve DualShock4 calibration info: %d\n", ret);
ret = -EILSEQ;
+ goto transfer_failed;
} else {
break;
}
@@ -1815,17 +1816,19 @@ static int dualshock4_get_calibration_data(struct dualshock4 *ds4)
buf = kzalloc(DS4_FEATURE_REPORT_CALIBRATION_BT_SIZE, GFP_KERNEL);
if (!buf) {
ret = -ENOMEM;
- goto no_buffer_tail_check;
+ goto transfer_failed;
}
ret = ps_get_report(hdev, DS4_FEATURE_REPORT_CALIBRATION_BT, buf,
DS4_FEATURE_REPORT_CALIBRATION_BT_SIZE, true);
- if (ret)
+ if (ret) {
hid_warn(hdev, "Failed to retrieve DualShock4 calibration info: %d\n", ret);
+ goto transfer_failed;
+ }
}
- /* Parse buffer. If the transfer failed, this safely copies zeroes. */
+ /* Transfer succeeded - parse the calibration data received. */
gyro_pitch_bias = get_unaligned_le16(&buf[1]);
gyro_yaw_bias = get_unaligned_le16(&buf[3]);
gyro_roll_bias = get_unaligned_le16(&buf[5]);
@@ -1854,71 +1857,71 @@ static int dualshock4_get_calibration_data(struct dualshock4 *ds4)
acc_z_plus = get_unaligned_le16(&buf[31]);
acc_z_minus = get_unaligned_le16(&buf[33]);
+ /* Done parsing the buffer, so let's free it. */
+ kfree(buf);
+
/*
* Set gyroscope calibration and normalization parameters.
* Data values will be normalized to 1/DS4_GYRO_RES_PER_DEG_S degree/s.
*/
speed_2x = (gyro_speed_plus + gyro_speed_minus);
- ds4->gyro_calib_data[0].abs_code = ABS_RX;
ds4->gyro_calib_data[0].bias = 0;
ds4->gyro_calib_data[0].sens_numer = speed_2x*DS4_GYRO_RES_PER_DEG_S;
ds4->gyro_calib_data[0].sens_denom = abs(gyro_pitch_plus - gyro_pitch_bias) +
abs(gyro_pitch_minus - gyro_pitch_bias);
- ds4->gyro_calib_data[1].abs_code = ABS_RY;
ds4->gyro_calib_data[1].bias = 0;
ds4->gyro_calib_data[1].sens_numer = speed_2x*DS4_GYRO_RES_PER_DEG_S;
ds4->gyro_calib_data[1].sens_denom = abs(gyro_yaw_plus - gyro_yaw_bias) +
abs(gyro_yaw_minus - gyro_yaw_bias);
- ds4->gyro_calib_data[2].abs_code = ABS_RZ;
ds4->gyro_calib_data[2].bias = 0;
ds4->gyro_calib_data[2].sens_numer = speed_2x*DS4_GYRO_RES_PER_DEG_S;
ds4->gyro_calib_data[2].sens_denom = abs(gyro_roll_plus - gyro_roll_bias) +
abs(gyro_roll_minus - gyro_roll_bias);
- /* Done parsing the buffer, so let's free it. */
- kfree(buf);
-
-no_buffer_tail_check:
-
- /*
- * Sanity check gyro calibration data. This is needed to prevent crashes
- * during report handling of virtual, clone or broken devices not implementing
- * calibration data properly.
- */
- for (i = 0; i < ARRAY_SIZE(ds4->gyro_calib_data); i++) {
- if (ds4->gyro_calib_data[i].sens_denom == 0) {
- hid_warn(hdev, "Invalid gyro calibration data for axis (%d), disabling calibration.",
- ds4->gyro_calib_data[i].abs_code);
- ds4->gyro_calib_data[i].bias = 0;
- ds4->gyro_calib_data[i].sens_numer = DS4_GYRO_RANGE;
- ds4->gyro_calib_data[i].sens_denom = S16_MAX;
- }
- }
-
/*
* Set accelerometer calibration and normalization parameters.
* Data values will be normalized to 1/DS4_ACC_RES_PER_G g.
*/
range_2g = acc_x_plus - acc_x_minus;
- ds4->accel_calib_data[0].abs_code = ABS_X;
ds4->accel_calib_data[0].bias = acc_x_plus - range_2g / 2;
ds4->accel_calib_data[0].sens_numer = 2*DS4_ACC_RES_PER_G;
ds4->accel_calib_data[0].sens_denom = range_2g;
range_2g = acc_y_plus - acc_y_minus;
- ds4->accel_calib_data[1].abs_code = ABS_Y;
ds4->accel_calib_data[1].bias = acc_y_plus - range_2g / 2;
ds4->accel_calib_data[1].sens_numer = 2*DS4_ACC_RES_PER_G;
ds4->accel_calib_data[1].sens_denom = range_2g;
range_2g = acc_z_plus - acc_z_minus;
- ds4->accel_calib_data[2].abs_code = ABS_Z;
ds4->accel_calib_data[2].bias = acc_z_plus - range_2g / 2;
ds4->accel_calib_data[2].sens_numer = 2*DS4_ACC_RES_PER_G;
ds4->accel_calib_data[2].sens_denom = range_2g;
+transfer_failed:
+ ds4->gyro_calib_data[0].abs_code = ABS_RX;
+ ds4->gyro_calib_data[1].abs_code = ABS_RY;
+ ds4->gyro_calib_data[2].abs_code = ABS_RZ;
+ ds4->accel_calib_data[0].abs_code = ABS_X;
+ ds4->accel_calib_data[1].abs_code = ABS_Y;
+ ds4->accel_calib_data[2].abs_code = ABS_Z;
+
+ /*
+ * Sanity check gyro calibration data. This is needed to prevent crashes
+ * during report handling of virtual, clone or broken devices not implementing
+ * calibration data properly.
+ */
+ for (i = 0; i < ARRAY_SIZE(ds4->gyro_calib_data); i++) {
+ if (ds4->gyro_calib_data[i].sens_denom == 0) {
+ hid_warn(hdev, "Invalid gyro calibration data for axis (%d), disabling calibration.",
+ ds4->gyro_calib_data[i].abs_code);
+ ds4->gyro_calib_data[i].bias = 0;
+ ds4->gyro_calib_data[i].sens_numer = DS4_GYRO_RANGE;
+ ds4->gyro_calib_data[i].sens_denom = S16_MAX;
+ }
+ }
+
/*
* Sanity check accelerometer calibration data. This is needed to prevent crashes
* during report handling of virtual, clone or broken devices not implementing calibration
--
2.39.2
^ permalink raw reply related
* [PATCH 00/18] backlight: Constify lcd_ops
From: Krzysztof Kozlowski @ 2024-04-14 16:35 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller,
Bruno Prémont, Jiri Kosina, Benjamin Tissoires,
Alexander Shiyan, Sascha Hauer, Pengutronix Kernel Team,
Shawn Guo, Fabio Estevam
Cc: dri-devel, linux-fbdev, linux-kernel, linux-input,
linux-arm-kernel, imx, linux-omap, Krzysztof Kozlowski
Hi,
Dependencies
============
All further patches depend on the first patch. Therefore everything
could go via backlight tree (please ack) or via cross-tree pulls. Or
whatever maintainer choose, just coordinate this with backlight.
Best regards,
Krzysztof
---
Krzysztof Kozlowski (18):
backlight: Constify lcd_ops
backlight: ams369fg06: Constify lcd_ops
backlight: corgi_lcd: Constify lcd_ops
backlight: hx8357: Constify lcd_ops
backlight: ili922x: Constify lcd_ops
backlight: ili9320: Constify lcd_ops
backlight: jornada720_lcd: Constify lcd_ops
backlight: l4f00242t03: Constify lcd_ops
backlight: lms283gf05: Constify lcd_ops
backlight: lms501kf03: Constify lcd_ops
backlight: ltv350qv: Constify lcd_ops
backlight: otm3225a: Constify lcd_ops
backlight: platform_lcd: Constify lcd_ops
backlight: tdo24m: Constify lcd_ops
HID: picoLCD: Constify lcd_ops
fbdev: clps711x: Constify lcd_ops
fbdev: imx: Constify lcd_ops
fbdev: omap: lcd_ams_delta: Constify lcd_ops
drivers/hid/hid-picolcd_lcd.c | 2 +-
drivers/video/backlight/ams369fg06.c | 2 +-
drivers/video/backlight/corgi_lcd.c | 2 +-
drivers/video/backlight/hx8357.c | 2 +-
drivers/video/backlight/ili922x.c | 2 +-
drivers/video/backlight/ili9320.c | 2 +-
drivers/video/backlight/jornada720_lcd.c | 2 +-
drivers/video/backlight/l4f00242t03.c | 2 +-
drivers/video/backlight/lcd.c | 4 ++--
drivers/video/backlight/lms283gf05.c | 2 +-
drivers/video/backlight/lms501kf03.c | 2 +-
drivers/video/backlight/ltv350qv.c | 2 +-
drivers/video/backlight/otm3225a.c | 2 +-
drivers/video/backlight/platform_lcd.c | 2 +-
drivers/video/backlight/tdo24m.c | 2 +-
drivers/video/fbdev/clps711x-fb.c | 2 +-
drivers/video/fbdev/imxfb.c | 2 +-
drivers/video/fbdev/omap/lcd_ams_delta.c | 2 +-
include/linux/lcd.h | 6 +++---
19 files changed, 22 insertions(+), 22 deletions(-)
---
base-commit: 9ed46da14b9b9b2ad4edb3b0c545b6dbe5c00d39
change-id: 20240414-video-backlight-lcd-ops-276d8439ffb8
Best regards,
--
Krzysztof Kozlowski <krzk@kernel.org>
^ permalink raw reply
* [PATCH 01/18] backlight: Constify lcd_ops
From: Krzysztof Kozlowski @ 2024-04-14 16:35 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller,
Bruno Prémont, Jiri Kosina, Benjamin Tissoires,
Alexander Shiyan, Sascha Hauer, Pengutronix Kernel Team,
Shawn Guo, Fabio Estevam
Cc: dri-devel, linux-fbdev, linux-kernel, linux-input,
linux-arm-kernel, imx, linux-omap, Krzysztof Kozlowski
In-Reply-To: <20240414-video-backlight-lcd-ops-v1-0-9b37fcbf546a@kernel.org>
'struct lcd_ops' passed in lcd_device_register() is not modified by core
backlight code, so it can be made const for code safety. This allows
drivers to also define the structure as const.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
drivers/video/backlight/lcd.c | 4 ++--
include/linux/lcd.h | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/video/backlight/lcd.c b/drivers/video/backlight/lcd.c
index ba4771cbd781..ceec90ca758b 100644
--- a/drivers/video/backlight/lcd.c
+++ b/drivers/video/backlight/lcd.c
@@ -191,7 +191,7 @@ static const struct class lcd_class = {
* or a pointer to the newly allocated device.
*/
struct lcd_device *lcd_device_register(const char *name, struct device *parent,
- void *devdata, struct lcd_ops *ops)
+ void *devdata, const struct lcd_ops *ops)
{
struct lcd_device *new_ld;
int rc;
@@ -279,7 +279,7 @@ static int devm_lcd_device_match(struct device *dev, void *res, void *data)
*/
struct lcd_device *devm_lcd_device_register(struct device *dev,
const char *name, struct device *parent,
- void *devdata, struct lcd_ops *ops)
+ void *devdata, const struct lcd_ops *ops)
{
struct lcd_device **ptr, *lcd;
diff --git a/include/linux/lcd.h b/include/linux/lcd.h
index 238fb1dfed98..68703a51dc53 100644
--- a/include/linux/lcd.h
+++ b/include/linux/lcd.h
@@ -61,7 +61,7 @@ struct lcd_device {
points to something in the body of that driver, it is also invalid. */
struct mutex ops_lock;
/* If this is NULL, the backing module is unloaded */
- struct lcd_ops *ops;
+ const struct lcd_ops *ops;
/* Serialise access to set_power method */
struct mutex update_lock;
/* The framebuffer notifier block */
@@ -102,10 +102,10 @@ static inline void lcd_set_power(struct lcd_device *ld, int power)
}
extern struct lcd_device *lcd_device_register(const char *name,
- struct device *parent, void *devdata, struct lcd_ops *ops);
+ struct device *parent, void *devdata, const struct lcd_ops *ops);
extern struct lcd_device *devm_lcd_device_register(struct device *dev,
const char *name, struct device *parent,
- void *devdata, struct lcd_ops *ops);
+ void *devdata, const struct lcd_ops *ops);
extern void lcd_device_unregister(struct lcd_device *ld);
extern void devm_lcd_device_unregister(struct device *dev,
struct lcd_device *ld);
--
2.34.1
^ permalink raw reply related
* [PATCH 02/18] backlight: ams369fg06: Constify lcd_ops
From: Krzysztof Kozlowski @ 2024-04-14 16:36 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller,
Bruno Prémont, Jiri Kosina, Benjamin Tissoires,
Alexander Shiyan, Sascha Hauer, Pengutronix Kernel Team,
Shawn Guo, Fabio Estevam
Cc: dri-devel, linux-fbdev, linux-kernel, linux-input,
linux-arm-kernel, imx, linux-omap, Krzysztof Kozlowski
In-Reply-To: <20240414-video-backlight-lcd-ops-v1-0-9b37fcbf546a@kernel.org>
'struct lcd_ops' is not modified by core backlight code, so it can be
made const for increased code safety.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
drivers/video/backlight/ams369fg06.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/ams369fg06.c b/drivers/video/backlight/ams369fg06.c
index 522dd81110b8..57ec205d2bd2 100644
--- a/drivers/video/backlight/ams369fg06.c
+++ b/drivers/video/backlight/ams369fg06.c
@@ -427,7 +427,7 @@ static int ams369fg06_set_brightness(struct backlight_device *bd)
return ret;
}
-static struct lcd_ops ams369fg06_lcd_ops = {
+static const struct lcd_ops ams369fg06_lcd_ops = {
.get_power = ams369fg06_get_power,
.set_power = ams369fg06_set_power,
};
--
2.34.1
^ permalink raw reply related
* [PATCH 03/18] backlight: corgi_lcd: Constify lcd_ops
From: Krzysztof Kozlowski @ 2024-04-14 16:36 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller,
Bruno Prémont, Jiri Kosina, Benjamin Tissoires,
Alexander Shiyan, Sascha Hauer, Pengutronix Kernel Team,
Shawn Guo, Fabio Estevam
Cc: dri-devel, linux-fbdev, linux-kernel, linux-input,
linux-arm-kernel, imx, linux-omap, Krzysztof Kozlowski
In-Reply-To: <20240414-video-backlight-lcd-ops-v1-0-9b37fcbf546a@kernel.org>
'struct lcd_ops' is not modified by core backlight code, so it can be
made const for increased code safety.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
drivers/video/backlight/corgi_lcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/corgi_lcd.c b/drivers/video/backlight/corgi_lcd.c
index dd765098ad98..aad1680c9075 100644
--- a/drivers/video/backlight/corgi_lcd.c
+++ b/drivers/video/backlight/corgi_lcd.c
@@ -380,7 +380,7 @@ static int corgi_lcd_get_power(struct lcd_device *ld)
return lcd->power;
}
-static struct lcd_ops corgi_lcd_ops = {
+static const struct lcd_ops corgi_lcd_ops = {
.get_power = corgi_lcd_get_power,
.set_power = corgi_lcd_set_power,
.set_mode = corgi_lcd_set_mode,
--
2.34.1
^ permalink raw reply related
* [PATCH 04/18] backlight: hx8357: Constify lcd_ops
From: Krzysztof Kozlowski @ 2024-04-14 16:36 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller,
Bruno Prémont, Jiri Kosina, Benjamin Tissoires,
Alexander Shiyan, Sascha Hauer, Pengutronix Kernel Team,
Shawn Guo, Fabio Estevam
Cc: dri-devel, linux-fbdev, linux-kernel, linux-input,
linux-arm-kernel, imx, linux-omap, Krzysztof Kozlowski
In-Reply-To: <20240414-video-backlight-lcd-ops-v1-0-9b37fcbf546a@kernel.org>
'struct lcd_ops' is not modified by core backlight code, so it can be
made const for increased code safety.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
drivers/video/backlight/hx8357.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/hx8357.c b/drivers/video/backlight/hx8357.c
index 339d9128fbde..cdd7b7686723 100644
--- a/drivers/video/backlight/hx8357.c
+++ b/drivers/video/backlight/hx8357.c
@@ -559,7 +559,7 @@ static int hx8357_get_power(struct lcd_device *lcdev)
return lcd->state;
}
-static struct lcd_ops hx8357_ops = {
+static const struct lcd_ops hx8357_ops = {
.set_power = hx8357_set_power,
.get_power = hx8357_get_power,
};
--
2.34.1
^ permalink raw reply related
* [PATCH 05/18] backlight: ili922x: Constify lcd_ops
From: Krzysztof Kozlowski @ 2024-04-14 16:36 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller,
Bruno Prémont, Jiri Kosina, Benjamin Tissoires,
Alexander Shiyan, Sascha Hauer, Pengutronix Kernel Team,
Shawn Guo, Fabio Estevam
Cc: dri-devel, linux-fbdev, linux-kernel, linux-input,
linux-arm-kernel, imx, linux-omap, Krzysztof Kozlowski
In-Reply-To: <20240414-video-backlight-lcd-ops-v1-0-9b37fcbf546a@kernel.org>
'struct lcd_ops' is not modified by core backlight code, so it can be
made const for increased code safety.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
drivers/video/backlight/ili922x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/ili922x.c b/drivers/video/backlight/ili922x.c
index c8e0e655dc86..7683e209ad6b 100644
--- a/drivers/video/backlight/ili922x.c
+++ b/drivers/video/backlight/ili922x.c
@@ -472,7 +472,7 @@ static int ili922x_get_power(struct lcd_device *ld)
return ili->power;
}
-static struct lcd_ops ili922x_ops = {
+static const struct lcd_ops ili922x_ops = {
.get_power = ili922x_get_power,
.set_power = ili922x_set_power,
};
--
2.34.1
^ permalink raw reply related
* [PATCH 06/18] backlight: ili9320: Constify lcd_ops
From: Krzysztof Kozlowski @ 2024-04-14 16:36 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller,
Bruno Prémont, Jiri Kosina, Benjamin Tissoires,
Alexander Shiyan, Sascha Hauer, Pengutronix Kernel Team,
Shawn Guo, Fabio Estevam
Cc: dri-devel, linux-fbdev, linux-kernel, linux-input,
linux-arm-kernel, imx, linux-omap, Krzysztof Kozlowski
In-Reply-To: <20240414-video-backlight-lcd-ops-v1-0-9b37fcbf546a@kernel.org>
'struct lcd_ops' is not modified by core backlight code, so it can be
made const for increased code safety.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
drivers/video/backlight/ili9320.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/ili9320.c b/drivers/video/backlight/ili9320.c
index 2acd2708f8ca..3e318d1891b6 100644
--- a/drivers/video/backlight/ili9320.c
+++ b/drivers/video/backlight/ili9320.c
@@ -161,7 +161,7 @@ static int ili9320_get_power(struct lcd_device *ld)
return lcd->power;
}
-static struct lcd_ops ili9320_ops = {
+static const struct lcd_ops ili9320_ops = {
.get_power = ili9320_get_power,
.set_power = ili9320_set_power,
};
--
2.34.1
^ permalink raw reply related
* [PATCH 07/18] backlight: jornada720_lcd: Constify lcd_ops
From: Krzysztof Kozlowski @ 2024-04-14 16:36 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller,
Bruno Prémont, Jiri Kosina, Benjamin Tissoires,
Alexander Shiyan, Sascha Hauer, Pengutronix Kernel Team,
Shawn Guo, Fabio Estevam
Cc: dri-devel, linux-fbdev, linux-kernel, linux-input,
linux-arm-kernel, imx, linux-omap, Krzysztof Kozlowski
In-Reply-To: <20240414-video-backlight-lcd-ops-v1-0-9b37fcbf546a@kernel.org>
'struct lcd_ops' is not modified by core backlight code, so it can be
made const for increased code safety.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
drivers/video/backlight/jornada720_lcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/jornada720_lcd.c b/drivers/video/backlight/jornada720_lcd.c
index 6796a7c2db25..5c64fa61e810 100644
--- a/drivers/video/backlight/jornada720_lcd.c
+++ b/drivers/video/backlight/jornada720_lcd.c
@@ -81,7 +81,7 @@ static int jornada_lcd_set_power(struct lcd_device *ld, int power)
return 0;
}
-static struct lcd_ops jornada_lcd_props = {
+static const struct lcd_ops jornada_lcd_props = {
.get_contrast = jornada_lcd_get_contrast,
.set_contrast = jornada_lcd_set_contrast,
.get_power = jornada_lcd_get_power,
--
2.34.1
^ permalink raw reply related
* [PATCH 08/18] backlight: l4f00242t03: Constify lcd_ops
From: Krzysztof Kozlowski @ 2024-04-14 16:36 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller,
Bruno Prémont, Jiri Kosina, Benjamin Tissoires,
Alexander Shiyan, Sascha Hauer, Pengutronix Kernel Team,
Shawn Guo, Fabio Estevam
Cc: dri-devel, linux-fbdev, linux-kernel, linux-input,
linux-arm-kernel, imx, linux-omap, Krzysztof Kozlowski
In-Reply-To: <20240414-video-backlight-lcd-ops-v1-0-9b37fcbf546a@kernel.org>
'struct lcd_ops' is not modified by core backlight code, so it can be
made const for increased code safety.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
drivers/video/backlight/l4f00242t03.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/l4f00242t03.c b/drivers/video/backlight/l4f00242t03.c
index bd5137ee203b..dd0874f8c7ff 100644
--- a/drivers/video/backlight/l4f00242t03.c
+++ b/drivers/video/backlight/l4f00242t03.c
@@ -158,7 +158,7 @@ static int l4f00242t03_lcd_power_set(struct lcd_device *ld, int power)
return 0;
}
-static struct lcd_ops l4f_ops = {
+static const struct lcd_ops l4f_ops = {
.set_power = l4f00242t03_lcd_power_set,
.get_power = l4f00242t03_lcd_power_get,
};
--
2.34.1
^ permalink raw reply related
* [PATCH 09/18] backlight: lms283gf05: Constify lcd_ops
From: Krzysztof Kozlowski @ 2024-04-14 16:36 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller,
Bruno Prémont, Jiri Kosina, Benjamin Tissoires,
Alexander Shiyan, Sascha Hauer, Pengutronix Kernel Team,
Shawn Guo, Fabio Estevam
Cc: dri-devel, linux-fbdev, linux-kernel, linux-input,
linux-arm-kernel, imx, linux-omap, Krzysztof Kozlowski
In-Reply-To: <20240414-video-backlight-lcd-ops-v1-0-9b37fcbf546a@kernel.org>
'struct lcd_ops' is not modified by core backlight code, so it can be
made const for increased code safety.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
drivers/video/backlight/lms283gf05.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/lms283gf05.c b/drivers/video/backlight/lms283gf05.c
index 36856962ed83..a65490e83d3d 100644
--- a/drivers/video/backlight/lms283gf05.c
+++ b/drivers/video/backlight/lms283gf05.c
@@ -139,7 +139,7 @@ static int lms283gf05_power_set(struct lcd_device *ld, int power)
return 0;
}
-static struct lcd_ops lms_ops = {
+static const struct lcd_ops lms_ops = {
.set_power = lms283gf05_power_set,
.get_power = NULL,
};
--
2.34.1
^ permalink raw reply related
* [PATCH 10/18] backlight: lms501kf03: Constify lcd_ops
From: Krzysztof Kozlowski @ 2024-04-14 16:36 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller,
Bruno Prémont, Jiri Kosina, Benjamin Tissoires,
Alexander Shiyan, Sascha Hauer, Pengutronix Kernel Team,
Shawn Guo, Fabio Estevam
Cc: dri-devel, linux-fbdev, linux-kernel, linux-input,
linux-arm-kernel, imx, linux-omap, Krzysztof Kozlowski
In-Reply-To: <20240414-video-backlight-lcd-ops-v1-0-9b37fcbf546a@kernel.org>
'struct lcd_ops' is not modified by core backlight code, so it can be
made const for increased code safety.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
drivers/video/backlight/lms501kf03.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/lms501kf03.c b/drivers/video/backlight/lms501kf03.c
index 5c46df8022bf..8aebe0af3391 100644
--- a/drivers/video/backlight/lms501kf03.c
+++ b/drivers/video/backlight/lms501kf03.c
@@ -304,7 +304,7 @@ static int lms501kf03_set_power(struct lcd_device *ld, int power)
return lms501kf03_power(lcd, power);
}
-static struct lcd_ops lms501kf03_lcd_ops = {
+static const struct lcd_ops lms501kf03_lcd_ops = {
.get_power = lms501kf03_get_power,
.set_power = lms501kf03_set_power,
};
--
2.34.1
^ permalink raw reply related
* [PATCH 11/18] backlight: ltv350qv: Constify lcd_ops
From: Krzysztof Kozlowski @ 2024-04-14 16:36 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller,
Bruno Prémont, Jiri Kosina, Benjamin Tissoires,
Alexander Shiyan, Sascha Hauer, Pengutronix Kernel Team,
Shawn Guo, Fabio Estevam
Cc: dri-devel, linux-fbdev, linux-kernel, linux-input,
linux-arm-kernel, imx, linux-omap, Krzysztof Kozlowski
In-Reply-To: <20240414-video-backlight-lcd-ops-v1-0-9b37fcbf546a@kernel.org>
'struct lcd_ops' is not modified by core backlight code, so it can be
made const for increased code safety.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
drivers/video/backlight/ltv350qv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/ltv350qv.c b/drivers/video/backlight/ltv350qv.c
index d54f501e4285..cdc4c087f230 100644
--- a/drivers/video/backlight/ltv350qv.c
+++ b/drivers/video/backlight/ltv350qv.c
@@ -217,7 +217,7 @@ static int ltv350qv_get_power(struct lcd_device *ld)
return lcd->power;
}
-static struct lcd_ops ltv_ops = {
+static const struct lcd_ops ltv_ops = {
.get_power = ltv350qv_get_power,
.set_power = ltv350qv_set_power,
};
--
2.34.1
^ permalink raw reply related
* [PATCH 12/18] backlight: otm3225a: Constify lcd_ops
From: Krzysztof Kozlowski @ 2024-04-14 16:36 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller,
Bruno Prémont, Jiri Kosina, Benjamin Tissoires,
Alexander Shiyan, Sascha Hauer, Pengutronix Kernel Team,
Shawn Guo, Fabio Estevam
Cc: dri-devel, linux-fbdev, linux-kernel, linux-input,
linux-arm-kernel, imx, linux-omap, Krzysztof Kozlowski
In-Reply-To: <20240414-video-backlight-lcd-ops-v1-0-9b37fcbf546a@kernel.org>
'struct lcd_ops' is not modified by core backlight code, so it can be
made const for increased code safety.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
drivers/video/backlight/otm3225a.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/otm3225a.c b/drivers/video/backlight/otm3225a.c
index 4568020abf3c..efe52fa08b07 100644
--- a/drivers/video/backlight/otm3225a.c
+++ b/drivers/video/backlight/otm3225a.c
@@ -205,7 +205,7 @@ static int otm3225a_get_power(struct lcd_device *ld)
return dd->power;
}
-static struct lcd_ops otm3225a_ops = {
+static const struct lcd_ops otm3225a_ops = {
.set_power = otm3225a_set_power,
.get_power = otm3225a_get_power,
};
--
2.34.1
^ permalink raw reply related
* [PATCH 13/18] backlight: platform_lcd: Constify lcd_ops
From: Krzysztof Kozlowski @ 2024-04-14 16:36 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller,
Bruno Prémont, Jiri Kosina, Benjamin Tissoires,
Alexander Shiyan, Sascha Hauer, Pengutronix Kernel Team,
Shawn Guo, Fabio Estevam
Cc: dri-devel, linux-fbdev, linux-kernel, linux-input,
linux-arm-kernel, imx, linux-omap, Krzysztof Kozlowski
In-Reply-To: <20240414-video-backlight-lcd-ops-v1-0-9b37fcbf546a@kernel.org>
'struct lcd_ops' is not modified by core backlight code, so it can be
made const for increased code safety.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
drivers/video/backlight/platform_lcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/platform_lcd.c b/drivers/video/backlight/platform_lcd.c
index dc37494baf42..76872f5c34c5 100644
--- a/drivers/video/backlight/platform_lcd.c
+++ b/drivers/video/backlight/platform_lcd.c
@@ -62,7 +62,7 @@ static int platform_lcd_match(struct lcd_device *lcd, struct fb_info *info)
return plcd->us->parent == info->device;
}
-static struct lcd_ops platform_lcd_ops = {
+static const struct lcd_ops platform_lcd_ops = {
.get_power = platform_lcd_get_power,
.set_power = platform_lcd_set_power,
.check_fb = platform_lcd_match,
--
2.34.1
^ permalink raw reply related
* [PATCH 14/18] backlight: tdo24m: Constify lcd_ops
From: Krzysztof Kozlowski @ 2024-04-14 16:36 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller,
Bruno Prémont, Jiri Kosina, Benjamin Tissoires,
Alexander Shiyan, Sascha Hauer, Pengutronix Kernel Team,
Shawn Guo, Fabio Estevam
Cc: dri-devel, linux-fbdev, linux-kernel, linux-input,
linux-arm-kernel, imx, linux-omap, Krzysztof Kozlowski
In-Reply-To: <20240414-video-backlight-lcd-ops-v1-0-9b37fcbf546a@kernel.org>
'struct lcd_ops' is not modified by core backlight code, so it can be
made const for increased code safety.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
drivers/video/backlight/tdo24m.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/tdo24m.c b/drivers/video/backlight/tdo24m.c
index fc6fbaf85594..c413b3c68e95 100644
--- a/drivers/video/backlight/tdo24m.c
+++ b/drivers/video/backlight/tdo24m.c
@@ -322,7 +322,7 @@ static int tdo24m_set_mode(struct lcd_device *ld, struct fb_videomode *m)
return lcd->adj_mode(lcd, mode);
}
-static struct lcd_ops tdo24m_ops = {
+static const struct lcd_ops tdo24m_ops = {
.get_power = tdo24m_get_power,
.set_power = tdo24m_set_power,
.set_mode = tdo24m_set_mode,
--
2.34.1
^ permalink raw reply related
* [PATCH 15/18] HID: picoLCD: Constify lcd_ops
From: Krzysztof Kozlowski @ 2024-04-14 16:36 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller,
Bruno Prémont, Jiri Kosina, Benjamin Tissoires,
Alexander Shiyan, Sascha Hauer, Pengutronix Kernel Team,
Shawn Guo, Fabio Estevam
Cc: dri-devel, linux-fbdev, linux-kernel, linux-input,
linux-arm-kernel, imx, linux-omap, Krzysztof Kozlowski
In-Reply-To: <20240414-video-backlight-lcd-ops-v1-0-9b37fcbf546a@kernel.org>
'struct lcd_ops' is not modified by core backlight code, so it can be
made const for increased code safety.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Depends on the first patch in the series.
---
drivers/hid/hid-picolcd_lcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-picolcd_lcd.c b/drivers/hid/hid-picolcd_lcd.c
index 0c4b76de8ae5..061a33ba7b1d 100644
--- a/drivers/hid/hid-picolcd_lcd.c
+++ b/drivers/hid/hid-picolcd_lcd.c
@@ -46,7 +46,7 @@ static int picolcd_check_lcd_fb(struct lcd_device *ldev, struct fb_info *fb)
return fb && fb == picolcd_fbinfo((struct picolcd_data *)lcd_get_data(ldev));
}
-static struct lcd_ops picolcd_lcdops = {
+static const struct lcd_ops picolcd_lcdops = {
.get_contrast = picolcd_get_contrast,
.set_contrast = picolcd_set_contrast,
.check_fb = picolcd_check_lcd_fb,
--
2.34.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox