* Re: [PATCH bpf-next v3 0/3] Annotate kfuncs in .BTF_ids section
From: Jiri Olsa @ 2024-01-13 13:57 UTC (permalink / raw)
To: Daniel Xu
Cc: Jiri Olsa, linux-input, coreteam, linux-arm-kernel, linux-kernel,
netfilter-devel, linux-kselftest, linux-trace-kernel, fsverity,
bpf, netdev, linux-stm32, cgroups, alexei.starovoitov, quentin,
alan.maguire, memxor
In-Reply-To: <2dhmwvfnnqnlrui2qcr5fob54gdsuse5caievct42trvvia6qe@p24nymz3uttv>
On Fri, Jan 12, 2024 at 01:03:59PM -0700, Daniel Xu wrote:
> On Fri, Jan 12, 2024 at 05:20:39PM +0100, Jiri Olsa wrote:
> > On Sat, Jan 06, 2024 at 11:24:07AM -0700, Daniel Xu wrote:
> > > === Description ===
> > >
> > > This is a bpf-treewide change that annotates all kfuncs as such inside
> > > .BTF_ids. This annotation eventually allows us to automatically generate
> > > kfunc prototypes from bpftool.
> > >
> > > We store this metadata inside a yet-unused flags field inside struct
> > > btf_id_set8 (thanks Kumar!). pahole will be taught where to look.
> > >
> > > More details about the full chain of events are available in commit 3's
> > > description.
> > >
> > > The accompanying pahole changes (still needs some cleanup) can be viewed
> > > here on this "frozen" branch [0].
> >
> > so the plan is to have bpftool support to generate header file
> > with detected kfuncs?
>
> Yep, that's the major use case. But I see other use cases as well like
ok, any chance you could already include it in the patchset?
would be a great way to test this.. maybe we could change
selftests to use that
thanks,
jirka
> precision probing of kfuncs. Rather than guess and check which progs can
> load (in the event of backwards incompatible kfunc changes), programs
> can look at kfunc type signature thru BTF.
^ permalink raw reply
* Re: [PATCH v3 1/4] iio: hid-sensor-als: Assign channels dynamically
From: Jonathan Cameron @ 2024-01-13 16:03 UTC (permalink / raw)
To: Srinivas Pandruvada
Cc: jikos, lars, Basavaraj.Natikar, linux-input, linux-iio,
linux-kernel
In-Reply-To: <20240109180007.3373784-2-srinivas.pandruvada@linux.intel.com>
On Tue, 9 Jan 2024 10:00:04 -0800
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> wrote:
> Instead of assuming that every channel defined statically by
> als_channels[] is present, assign dynamically based on presence of the
> respective usage id in the descriptor. This will allow to register ALS
> with limited channel support. Append the timestamp as the last channel.
>
> When not all usage ids are present, the scan index is adjusted to
> exclude unsupported channels.
>
> There is no intentional function changes done.
>
> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> ---
> v3:
> Addressed comments from Jonthan:
> - Remove channel allocation and move to iio_priv()
> - Parse all usage IDs in a single loop and continue
> for failure. This way the temperature and chromaticity
> will not need any special processing to parse usage ids.
> - Don't leave empty channel indexes
There isn't really a problem if you did want to leave them.
There are a number of other devices that do leave gaps and userspace
code shouldn't mind that. I don't mind them being more tightly packed
though so this is also fine.
I was just looking at the driver and noticed one other oddity.
In als_capture_sample, it always returns -EINVAL if the timestamp channel
is being queried.
>
> v2:
> New change
>
> drivers/iio/light/hid-sensor-als.c | 56 +++++++++++++++++++++---------
> 1 file changed, 39 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/iio/light/hid-sensor-als.c b/drivers/iio/light/hid-sensor-als.c
> index 5cd27f04b45e..72a7c01c97f8 100644
> --- a/drivers/iio/light/hid-sensor-als.c
> +++ b/drivers/iio/light/hid-sensor-als.c
> @@ -25,17 +25,26 @@ struct als_state {
> struct hid_sensor_hub_callbacks callbacks;
> struct hid_sensor_common common_attributes;
> struct hid_sensor_hub_attribute_info als[CHANNEL_SCAN_INDEX_MAX];
> + struct iio_chan_spec channels[CHANNEL_SCAN_INDEX_MAX + 1];
> struct {
> u32 illum[CHANNEL_SCAN_INDEX_MAX];
> + u32 scan_index[CHANNEL_SCAN_INDEX_MAX];
This looks unlikely to end up right with a varying number of channels.
I'm assuming the device always captures all available channels.
As such, if there are 2 channels the timestamp will end up at byte 8 onwards.
If there are 3 channels, byte 16 onwards etc.
Usually when we have a floating timestamp like this we just rely on expanding
the channel array to leave space and force the alignment of that to be suitable
for taking a timestamp.
I'm a bit confused not to see available_scan_mask being set though.
If userspace previously requested illumination only would the data
have ended up in the right location (offset 0?)
If you set available_scan_masks to specify all channels then the
IIO core will move things around for you. If it's not provided then
it is up to the driver to figure out where to put the data.
Otherwise the patch looks fine to me.
Jonathan
> u64 timestamp __aligned(8);
> } scan;
> int scale_pre_decml;
> int scale_post_decml;
> int scale_precision;
> int value_offset;
> + int num_channels;
> s64 timestamp;
> };
>
> +/* The order of usage ids must match scan index starting from CHANNEL_SCAN_INDEX_INTENSITY */
> +static const u32 als_usage_ids[] = {
> + HID_USAGE_SENSOR_LIGHT_ILLUM,
> + HID_USAGE_SENSOR_LIGHT_ILLUM,
> +};
> +
> static const u32 als_sensitivity_addresses[] = {
> HID_USAGE_SENSOR_DATA_LIGHT,
> HID_USAGE_SENSOR_LIGHT_ILLUM,
> @@ -216,11 +225,14 @@ static int als_capture_sample(struct hid_sensor_hub_device *hsdev,
> struct als_state *als_state = iio_priv(indio_dev);
> int ret = -EINVAL;
> u32 sample_data = *(u32 *)raw_data;
> + int scan_index;
>
> switch (usage_id) {
> case HID_USAGE_SENSOR_LIGHT_ILLUM:
> - als_state->scan.illum[CHANNEL_SCAN_INDEX_INTENSITY] = sample_data;
> - als_state->scan.illum[CHANNEL_SCAN_INDEX_ILLUM] = sample_data;
> + scan_index = als_state->scan.scan_index[CHANNEL_SCAN_INDEX_INTENSITY];
> + als_state->scan.illum[scan_index] = sample_data;
> + scan_index = als_state->scan.scan_index[CHANNEL_SCAN_INDEX_ILLUM];
> + als_state->scan.illum[scan_index] = sample_data;
> ret = 0;
> break;
> case HID_USAGE_SENSOR_TIME_TIMESTAMP:
> @@ -237,27 +249,39 @@ static int als_capture_sample(struct hid_sensor_hub_device *hsdev,
> /* Parse report which is specific to an usage id*/
> static int als_parse_report(struct platform_device *pdev,
> struct hid_sensor_hub_device *hsdev,
> - struct iio_chan_spec *channels,
> unsigned usage_id,
> struct als_state *st)
> {
> - int ret;
> + struct iio_chan_spec *channels;
> + int ret, index = 0;
> int i;
>
> + channels = st->channels;
> +
> for (i = 0; i <= CHANNEL_SCAN_INDEX_ILLUM; ++i) {
> ret = sensor_hub_input_get_attribute_info(hsdev,
> HID_INPUT_REPORT,
> usage_id,
> - HID_USAGE_SENSOR_LIGHT_ILLUM,
> + als_usage_ids[i],
> &st->als[i]);
> if (ret < 0)
> - return ret;
> - als_adjust_channel_bit_mask(channels, i, st->als[i].size);
> + continue;
> +
> + channels[index] = als_channels[i];
> + st->scan.scan_index[i] = index;
> +
> + als_adjust_channel_bit_mask(channels, index, st->als[i].size);
> + ++index;
>
> dev_dbg(&pdev->dev, "als %x:%x\n", st->als[i].index,
> st->als[i].report_id);
> }
>
> + st->num_channels = index;
> + /* Return success even if one usage id is present */
> + if (index)
> + ret = 0;
> +
> st->scale_precision = hid_sensor_format_scale(usage_id,
> &st->als[CHANNEL_SCAN_INDEX_INTENSITY],
> &st->scale_pre_decml, &st->scale_post_decml);
> @@ -293,15 +317,7 @@ static int hid_als_probe(struct platform_device *pdev)
> return ret;
> }
>
> - indio_dev->channels = devm_kmemdup(&pdev->dev, als_channels,
> - sizeof(als_channels), GFP_KERNEL);
> - if (!indio_dev->channels) {
> - dev_err(&pdev->dev, "failed to duplicate channels\n");
> - return -ENOMEM;
> - }
> -
> ret = als_parse_report(pdev, hsdev,
> - (struct iio_chan_spec *)indio_dev->channels,
> hsdev->usage,
> als_state);
> if (ret) {
> @@ -309,8 +325,14 @@ static int hid_als_probe(struct platform_device *pdev)
> return ret;
> }
>
> - indio_dev->num_channels =
> - ARRAY_SIZE(als_channels);
> + /* Add timestamp channel */
> + als_state->channels[als_state->num_channels] = als_channels[CHANNEL_SCAN_INDEX_TIMESTAMP];
> + als_state->channels[als_state->num_channels].scan_index = als_state->num_channels;
> +
> + /* +1 for adding timestamp channel */
> + indio_dev->num_channels = als_state->num_channels + 1;
> +
> + indio_dev->channels = als_state->channels;
> indio_dev->info = &als_info;
> indio_dev->name = name;
> indio_dev->modes = INDIO_DIRECT_MODE;
^ permalink raw reply
* Re: [PATCH bpf-next v3 0/3] Annotate kfuncs in .BTF_ids section
From: Daniel Xu @ 2024-01-13 16:17 UTC (permalink / raw)
To: Jiri Olsa
Cc: linux-input, coreteam, linux-arm-kernel, linux-kernel,
netfilter-devel, linux-kselftest, linux-trace-kernel, fsverity,
bpf, netdev, linux-stm32, cgroups, alexei.starovoitov, quentin,
alan.maguire, memxor
In-Reply-To: <ZaKW1AghwUnVz_c4@krava>
Hi Jiri,
On Sat, Jan 13, 2024 at 02:57:40PM +0100, Jiri Olsa wrote:
> On Fri, Jan 12, 2024 at 01:03:59PM -0700, Daniel Xu wrote:
> > On Fri, Jan 12, 2024 at 05:20:39PM +0100, Jiri Olsa wrote:
> > > On Sat, Jan 06, 2024 at 11:24:07AM -0700, Daniel Xu wrote:
> > > > === Description ===
> > > >
> > > > This is a bpf-treewide change that annotates all kfuncs as such inside
> > > > .BTF_ids. This annotation eventually allows us to automatically generate
> > > > kfunc prototypes from bpftool.
> > > >
> > > > We store this metadata inside a yet-unused flags field inside struct
> > > > btf_id_set8 (thanks Kumar!). pahole will be taught where to look.
> > > >
> > > > More details about the full chain of events are available in commit 3's
> > > > description.
> > > >
> > > > The accompanying pahole changes (still needs some cleanup) can be viewed
> > > > here on this "frozen" branch [0].
> > >
> > > so the plan is to have bpftool support to generate header file
> > > with detected kfuncs?
> >
> > Yep, that's the major use case. But I see other use cases as well like
>
> ok, any chance you could already include it in the patchset?
> would be a great way to test this.. maybe we could change
> selftests to use that
I haven't start working on that code yet, but I can.
Here is my plan FWIW:
1. Bump minimum required pahole version up. Or feature probe for
kfunc decl tag support. Whatever is the standard practice here.
2. Teach bpftool to dump kfunc prototypes, guarded behind a flag.
3. Flip bpftool flag on in selftest build and remove all manual kfunc
prototypes atomically in 1 commit.
I thought it'd be nicer to do it incrementally given all the moving
pieces. But if we want to land it all at once that is ok by me too.
Thanks,
Daniel
^ permalink raw reply
* 8BitDo USB controller disconnect/reconnect loop
From: Nikos Chantziaras @ 2024-01-13 17:02 UTC (permalink / raw)
To: linux-input
Hello.
Support for the 8BitDo Pro 2 Wired controller was added in kernel 6.3.
I'm currently using 6.6.11 (I use LTS kernels.)
When I connect the controller, it rumbles every few seconds. Looking at
dmesg, the reason is that it constantly disconnects and reconnects:
usb 1-4: new full-speed USB device number 6 using xhci_hcd
usb 1-4: New USB device found, idVendor=2dc8, idProduct=3106, bcdDevice=
1.14
usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-4: Product: 8BitDo Pro 2 Wired Controller
usb 1-4: Manufacturer: 8BitDo
usb 1-4: SerialNumber: 817EC44BB302
input: 8BitDo Pro 2 Wired Controller as
/devices/pci0000:00/0000:00:01.2/0000:02:00.0/usb1/1-4/1-4:1.0/input/input13
input input13: unable to receive magic message: -121
usb 1-4: USB disconnect, device number 6
xpad 1-4:1.0: xpad_try_sending_next_out_packet - usb_submit_urb failed
with result -19
usb 1-4: new full-speed USB device number 7 using xhci_hcd
usb 1-4: New USB device found, idVendor=2dc8, idProduct=3106, bcdDevice=
1.14
usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-4: Product: 8BitDo Pro 2 Wired Controller
usb 1-4: Manufacturer: 8BitDo
usb 1-4: SerialNumber: 817EC44BB302
input: 8BitDo Pro 2 Wired Controller as
/devices/pci0000:00/0000:00:01.2/0000:02:00.0/usb1/1-4/1-4:1.0/input/input14
input input14: unable to receive magic message: -121
usb 1-4: USB disconnect, device number 7
xpad 1-4:1.0: xpad_try_sending_next_out_packet - usb_submit_urb failed
with result -19
The index in /devices/ is also changing each time.
This goes on forever. It only stops happening when I launch an
application that uses the controller. Once I exit the application, this
behavior returns and it rumbles every 4 seconds or so.
Apparently this controller has a quirk where it needs to be polled once
in a while to keep it from disconnecting. I can't be sure why, but I
suspect it's because it tries to auto-detect the host system it's being
connected to. For example if it's connected to a PC, it switches to
X-Input mode. when it's connected to a Nintendo Switch, it switches to
that mode instead. But when it hasn't been polled for a few second, it
probably enters its auto-detection mode again.
While searching the web for this issue, I found other users with exactly
the same problem (I'm on Gentoo Linux, other users on Fedora and Arch
Linux.)
This behavior does not occur when using the controller in Microsoft
Windows 10. The controller's firmware is upgraded to the latest version
(1.03.)
Is there something I can do to fix this? Is there some kernel option or
perhaps a udev option I can use that would poll the controller once a
second or so to keep it alive?
^ permalink raw reply
* Re: [PATCH bpf-next v3 0/3] Annotate kfuncs in .BTF_ids section
From: Jiri Olsa @ 2024-01-13 19:49 UTC (permalink / raw)
To: Daniel Xu
Cc: Jiri Olsa, linux-input, coreteam, linux-arm-kernel, linux-kernel,
netfilter-devel, linux-kselftest, linux-trace-kernel, fsverity,
bpf, netdev, linux-stm32, cgroups, alexei.starovoitov, quentin,
alan.maguire, memxor
In-Reply-To: <nhpt647n2djmthtdkqzrfbpeuqkhfy567rt7qyqtymxejncbgr@4tpiyxy2sbcm>
On Sat, Jan 13, 2024 at 09:17:44AM -0700, Daniel Xu wrote:
> Hi Jiri,
>
> On Sat, Jan 13, 2024 at 02:57:40PM +0100, Jiri Olsa wrote:
> > On Fri, Jan 12, 2024 at 01:03:59PM -0700, Daniel Xu wrote:
> > > On Fri, Jan 12, 2024 at 05:20:39PM +0100, Jiri Olsa wrote:
> > > > On Sat, Jan 06, 2024 at 11:24:07AM -0700, Daniel Xu wrote:
> > > > > === Description ===
> > > > >
> > > > > This is a bpf-treewide change that annotates all kfuncs as such inside
> > > > > .BTF_ids. This annotation eventually allows us to automatically generate
> > > > > kfunc prototypes from bpftool.
> > > > >
> > > > > We store this metadata inside a yet-unused flags field inside struct
> > > > > btf_id_set8 (thanks Kumar!). pahole will be taught where to look.
> > > > >
> > > > > More details about the full chain of events are available in commit 3's
> > > > > description.
> > > > >
> > > > > The accompanying pahole changes (still needs some cleanup) can be viewed
> > > > > here on this "frozen" branch [0].
> > > >
> > > > so the plan is to have bpftool support to generate header file
> > > > with detected kfuncs?
> > >
> > > Yep, that's the major use case. But I see other use cases as well like
> >
> > ok, any chance you could already include it in the patchset?
> > would be a great way to test this.. maybe we could change
> > selftests to use that
>
> I haven't start working on that code yet, but I can.
>
> Here is my plan FWIW:
>
> 1. Bump minimum required pahole version up. Or feature probe for
> kfunc decl tag support. Whatever is the standard practice here.
>
> 2. Teach bpftool to dump kfunc prototypes, guarded behind a flag.
>
> 3. Flip bpftool flag on in selftest build and remove all manual kfunc
> prototypes atomically in 1 commit.
>
> I thought it'd be nicer to do it incrementally given all the moving
> pieces. But if we want to land it all at once that is ok by me too.
I think it'd be best to try the whole thing before we merge the change
to pahole.. I guess the tests changes can come later, but would be great
to try the kfunc dump and make sure it works as expected
jirka
^ permalink raw reply
* Re: [PATCH AUTOSEL 4.19 4/7] Input: amimouse - convert to platform remove callback returning void
From: Sasha Levin @ 2024-01-14 18:55 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Pavel Machek, linux-kernel, stable, Dmitry Torokhov, linux-input
In-Reply-To: <qkb22czelncqf43vr2kuz6i6npuq4juyr3ggl3jkdbp6t2uzfs@ftbna3qj6qhq>
On Tue, Jan 09, 2024 at 10:50:04PM +0100, Uwe Kleine-König wrote:
>On Tue, Jan 09, 2024 at 12:44:55PM +0100, Pavel Machek wrote:
>> Hi!
>>
>> > From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>> >
>> > [ Upstream commit 42b8ff47720258d1f6a4412e780a480c139773a0 ]
>> >
>> > The .remove() callback for a platform driver returns an int which makes
>> > many driver authors wrongly assume it's possible to do error handling by
>> > returning an error code. However the value returned is ignored (apart
>> > from emitting a warning) and this typically results in resource leaks.
>> >
>> > To improve here there is a quest to make the remove callback return
>> > void. In the first step of this quest all drivers are converted to
>> > .remove_new(), which already returns void. Eventually after all drivers
>> > are converted, .remove_new() will be renamed to .remove().
>> >
>> > Trivially convert this driver from always returning zero in the remove
>> > callback to the void returning variant.
>>
>> We don't really need this for -stable.
>
>Agreed! These patches shouldn't get backported to stable. Even if they
>are a dependency (which isn't the case for this patch AFAICT),
>backporting of later patches isn't hard even when dropping these
>patches.
I'll drop it, thanks!
--
Thanks,
Sasha
^ permalink raw reply
* [PATCH v2] HID: i2c-hid: Skip SET_POWER SLEEP for Cirque touchpad on system suspend
From: Kai-Heng Feng @ 2024-01-15 4:50 UTC (permalink / raw)
To: jikos, benjamin.tissoires
Cc: Kai-Heng Feng, Douglas Anderson, Hans de Goede, Maxime Ripard,
Thomas Weißschuh, Johan Hovold, linux-input, linux-kernel
There's a Cirque touchpad that wakes system up without anything touched
the touchpad. The input report is empty when this happens.
The reason is stated in HID over I2C spec, 7.2.8.2:
"If the DEVICE wishes to wake the HOST from its low power state, it can
issue a wake by asserting the interrupt."
This is fine if OS can put system back to suspend by identifying input
wakeup count stays the same on resume, like Chrome OS Dark Resume [0].
But for regular distro such policy is lacking.
Though the change doesn't bring any impact on power consumption for
touchpad is minimal, other i2c-hid device may depends on SLEEP control
power. So use a quirk to limit the change scope.
[0] https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/power_manager/docs/dark_resume.md
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
---
v2:
- Use quirk instead of applying the change universally.
drivers/hid/hid-ids.h | 3 +++
drivers/hid/i2c-hid/i2c-hid-core.c | 6 +++++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index fb30e228d35f..828a5c022c64 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -298,6 +298,9 @@
#define USB_VENDOR_ID_CIDC 0x1677
+#define I2C_VENDOR_ID_CIRQUE 0x0488
+#define I2C_PRODUCT_ID_CIRQUE_1063 0x1063
+
#define USB_VENDOR_ID_CJTOUCH 0x24b8
#define USB_DEVICE_ID_CJTOUCH_MULTI_TOUCH_0020 0x0020
#define USB_DEVICE_ID_CJTOUCH_MULTI_TOUCH_0040 0x0040
diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
index 90f316ae9819..2df1ab3c31cc 100644
--- a/drivers/hid/i2c-hid/i2c-hid-core.c
+++ b/drivers/hid/i2c-hid/i2c-hid-core.c
@@ -49,6 +49,7 @@
#define I2C_HID_QUIRK_RESET_ON_RESUME BIT(2)
#define I2C_HID_QUIRK_BAD_INPUT_SIZE BIT(3)
#define I2C_HID_QUIRK_NO_WAKEUP_AFTER_RESET BIT(4)
+#define I2C_HID_QUIRK_NO_SLEEP_ON_SUSPEND BIT(5)
/* Command opcodes */
#define I2C_HID_OPCODE_RESET 0x01
@@ -131,6 +132,8 @@ static const struct i2c_hid_quirks {
I2C_HID_QUIRK_RESET_ON_RESUME },
{ USB_VENDOR_ID_ITE, I2C_DEVICE_ID_ITE_LENOVO_LEGION_Y720,
I2C_HID_QUIRK_BAD_INPUT_SIZE },
+ { I2C_VENDOR_ID_CIRQUE, I2C_PRODUCT_ID_CIRQUE_1063,
+ I2C_HID_QUIRK_NO_SLEEP_ON_SUSPEND },
/*
* Sending the wakeup after reset actually break ELAN touchscreen controller
*/
@@ -956,7 +959,8 @@ static int i2c_hid_core_suspend(struct i2c_hid *ihid, bool force_poweroff)
return ret;
/* Save some power */
- i2c_hid_set_power(ihid, I2C_HID_PWR_SLEEP);
+ if (!(ihid->quirks & I2C_HID_QUIRK_NO_SLEEP_ON_SUSPEND))
+ i2c_hid_set_power(ihid, I2C_HID_PWR_SLEEP);
disable_irq(client->irq);
--
2.34.1
^ permalink raw reply related
* [dtor-input:for-linus] BUILD SUCCESS e2a2501af13cfeb1f21bb628db54c49d61949a53
From: kernel test robot @ 2024-01-15 8:02 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
branch HEAD: e2a2501af13cfeb1f21bb628db54c49d61949a53 Merge branch 'next' into for-linus
elapsed time: 1476m
configs tested: 157
configs skipped: 1
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc
alpha defconfig gcc
arc allnoconfig gcc
arc axs103_smp_defconfig gcc
arc defconfig gcc
arc haps_hs_defconfig gcc
arc randconfig-001-20240115 gcc
arc randconfig-002-20240115 gcc
arm allnoconfig gcc
arm pxa3xx_defconfig gcc
arm pxa_defconfig gcc
arm randconfig-001-20240115 gcc
arm randconfig-002-20240115 gcc
arm randconfig-003-20240115 gcc
arm randconfig-004-20240115 gcc
arm sama5_defconfig gcc
arm spear6xx_defconfig gcc
arm tegra_defconfig gcc
arm64 allmodconfig clang
arm64 allnoconfig gcc
arm64 defconfig gcc
arm64 randconfig-001-20240115 gcc
arm64 randconfig-002-20240115 gcc
arm64 randconfig-003-20240115 gcc
arm64 randconfig-004-20240115 gcc
csky alldefconfig gcc
csky allnoconfig gcc
csky defconfig gcc
csky randconfig-001-20240115 gcc
csky randconfig-002-20240115 gcc
hexagon allmodconfig clang
hexagon allyesconfig clang
i386 allmodconfig clang
i386 allnoconfig clang
i386 allyesconfig clang
i386 randconfig-011-20240115 clang
i386 randconfig-012-20240115 clang
i386 randconfig-013-20240115 clang
i386 randconfig-014-20240115 clang
i386 randconfig-015-20240115 clang
i386 randconfig-016-20240115 clang
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch allyesconfig gcc
loongarch defconfig gcc
loongarch loongson3_defconfig gcc
loongarch randconfig-001-20240115 gcc
loongarch randconfig-002-20240115 gcc
m68k allmodconfig gcc
m68k allnoconfig gcc
m68k allyesconfig gcc
m68k defconfig gcc
microblaze allmodconfig gcc
microblaze allnoconfig gcc
microblaze allyesconfig gcc
microblaze defconfig gcc
mips allmodconfig gcc
mips allyesconfig gcc
mips bcm47xx_defconfig gcc
mips loongson1b_defconfig gcc
nios2 allmodconfig gcc
nios2 allnoconfig gcc
nios2 allyesconfig gcc
nios2 defconfig gcc
nios2 randconfig-001-20240115 gcc
nios2 randconfig-002-20240115 gcc
openrisc allmodconfig gcc
openrisc allnoconfig gcc
openrisc allyesconfig gcc
openrisc defconfig gcc
parisc allmodconfig gcc
parisc allnoconfig gcc
parisc allyesconfig gcc
parisc defconfig gcc
parisc randconfig-001-20240115 gcc
parisc randconfig-002-20240115 gcc
parisc64 defconfig gcc
powerpc allmodconfig clang
powerpc allnoconfig gcc
powerpc allyesconfig clang
powerpc cell_defconfig gcc
powerpc cm5200_defconfig gcc
powerpc ep88xc_defconfig gcc
powerpc mpc837x_rdb_defconfig gcc
powerpc pasemi_defconfig gcc
powerpc randconfig-001-20240115 gcc
powerpc randconfig-002-20240115 gcc
powerpc randconfig-003-20240115 gcc
powerpc sequoia_defconfig gcc
powerpc warp_defconfig gcc
powerpc64 randconfig-001-20240115 gcc
powerpc64 randconfig-002-20240115 gcc
powerpc64 randconfig-003-20240115 gcc
riscv allmodconfig gcc
riscv allyesconfig gcc
riscv defconfig gcc
riscv nommu_k210_sdcard_defconfig gcc
riscv randconfig-001-20240115 gcc
riscv randconfig-002-20240115 gcc
riscv rv32_defconfig clang
s390 allmodconfig gcc
s390 allnoconfig gcc
s390 allyesconfig gcc
s390 defconfig gcc
sh allmodconfig gcc
sh allnoconfig gcc
sh allyesconfig gcc
sh defconfig gcc
sh hp6xx_defconfig gcc
sh randconfig-001-20240115 gcc
sh randconfig-002-20240115 gcc
sh rts7751r2dplus_defconfig gcc
sh shx3_defconfig gcc
sparc allmodconfig gcc
sparc allyesconfig gcc
sparc64 allmodconfig gcc
sparc64 allyesconfig gcc
sparc64 defconfig gcc
sparc64 randconfig-001-20240115 gcc
sparc64 randconfig-002-20240115 gcc
um allmodconfig clang
um allyesconfig clang
um defconfig gcc
um i386_defconfig gcc
um randconfig-001-20240115 gcc
um randconfig-002-20240115 gcc
um x86_64_defconfig gcc
x86_64 allyesconfig clang
x86_64 buildonly-randconfig-001-20240115 gcc
x86_64 buildonly-randconfig-002-20240115 gcc
x86_64 buildonly-randconfig-003-20240115 gcc
x86_64 buildonly-randconfig-004-20240115 gcc
x86_64 buildonly-randconfig-005-20240115 gcc
x86_64 buildonly-randconfig-006-20240115 gcc
x86_64 kexec gcc
x86_64 randconfig-011-20240115 gcc
x86_64 randconfig-012-20240115 gcc
x86_64 randconfig-013-20240115 gcc
x86_64 randconfig-014-20240115 gcc
x86_64 randconfig-015-20240115 gcc
x86_64 randconfig-016-20240115 gcc
x86_64 randconfig-071-20240115 gcc
x86_64 randconfig-072-20240115 gcc
x86_64 randconfig-073-20240115 gcc
x86_64 randconfig-074-20240115 gcc
x86_64 randconfig-075-20240115 gcc
x86_64 randconfig-076-20240115 gcc
x86_64 rhel-8.3-bpf gcc
x86_64 rhel-8.3-func gcc
x86_64 rhel-8.3-rust clang
x86_64 rhel-8.3 gcc
xtensa allnoconfig gcc
xtensa allyesconfig gcc
xtensa nommu_kc705_defconfig gcc
xtensa randconfig-001-20240115 gcc
xtensa randconfig-002-20240115 gcc
xtensa smp_lx200_defconfig gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [bug report] gpiolib: use a mutex to protect the list of GPIO devices
From: Dan Carpenter @ 2024-01-15 8:50 UTC (permalink / raw)
To: bartosz.golaszewski; +Cc: linux-wireless, linux-input
Hello Bartosz Golaszewski,
The patch 65a828bab158: "gpiolib: use a mutex to protect the list of
GPIO devices" from Dec 15, 2023 (linux-next), leads to the following
Smatch static checker warning:
drivers/net/wireless/ath/ath9k/hw.c:2836 ath9k_hw_gpio_get()
warn: sleeping in atomic context
drivers/net/wireless/ath/ath9k/hw.c
2826 val = MS_REG_READ(AR9285, gpio);
2827 else if (AR_SREV_9280(ah))
2828 val = MS_REG_READ(AR928X, gpio);
2829 else if (AR_DEVID_7010(ah))
2830 val = REG_READ(ah, AR7010_GPIO_IN) & BIT(gpio);
2831 else if (AR_SREV_9300_20_OR_LATER(ah))
2832 val = REG_READ(ah, AR_GPIO_IN(ah)) & BIT(gpio);
2833 else
2834 val = MS_REG_READ(AR, gpio);
2835 } else if (BIT(gpio) & ah->caps.gpio_requested) {
--> 2836 val = gpio_get_value(gpio) & BIT(gpio);
^^^^^^^^^^^^^^
2837 } else {
2838 WARN_ON(1);
2839 }
2840
2841 return !!val;
2842 }
Before gpio_get_value() took a spinlock but now it takes a mutex
(actually a rw semaphor now). The call tree where we are in atomic
context is:
ath_btcoex_period_timer() <- disables preempt
-> ath_detect_bt_priority()
-> ath9k_hw_gpio_get()
Another warning this change causes is:
drivers/input/keyboard/matrix_keypad.c:95 enable_row_irqs() warn: sleeping in atomic context
matrix_keypad_scan() <- disables preempt
-> enable_row_irqs()
drivers/input/keyboard/matrix_keypad.c:108 disable_row_irqs() warn: sleeping in atomic context
matrix_keypad_interrupt() <- disables preempt
-> disable_row_irqs()
regards,
dan carpenter
^ permalink raw reply
* Re: [bug report] gpiolib: use a mutex to protect the list of GPIO devices
From: Bartosz Golaszewski @ 2024-01-15 9:18 UTC (permalink / raw)
To: Dan Carpenter; +Cc: linux-wireless, linux-input, Linus Walleij
In-Reply-To: <f7b5ff1e-8f34-4d98-a7be-b826cb897dc8@moroto.mountain>
On Mon, 15 Jan 2024 at 09:50, Dan Carpenter <dan.carpenter@linaro.org> wrote:
>
> Hello Bartosz Golaszewski,
>
> The patch 65a828bab158: "gpiolib: use a mutex to protect the list of
> GPIO devices" from Dec 15, 2023 (linux-next), leads to the following
> Smatch static checker warning:
>
> drivers/net/wireless/ath/ath9k/hw.c:2836 ath9k_hw_gpio_get()
> warn: sleeping in atomic context
>
> drivers/net/wireless/ath/ath9k/hw.c
> 2826 val = MS_REG_READ(AR9285, gpio);
> 2827 else if (AR_SREV_9280(ah))
> 2828 val = MS_REG_READ(AR928X, gpio);
> 2829 else if (AR_DEVID_7010(ah))
> 2830 val = REG_READ(ah, AR7010_GPIO_IN) & BIT(gpio);
> 2831 else if (AR_SREV_9300_20_OR_LATER(ah))
> 2832 val = REG_READ(ah, AR_GPIO_IN(ah)) & BIT(gpio);
> 2833 else
> 2834 val = MS_REG_READ(AR, gpio);
> 2835 } else if (BIT(gpio) & ah->caps.gpio_requested) {
> --> 2836 val = gpio_get_value(gpio) & BIT(gpio);
> ^^^^^^^^^^^^^^
>
> 2837 } else {
> 2838 WARN_ON(1);
> 2839 }
> 2840
> 2841 return !!val;
> 2842 }
>
> Before gpio_get_value() took a spinlock but now it takes a mutex
> (actually a rw semaphor now). The call tree where we are in atomic
> context is:
>
> ath_btcoex_period_timer() <- disables preempt
> -> ath_detect_bt_priority()
> -> ath9k_hw_gpio_get()
>
> Another warning this change causes is:
>
> drivers/input/keyboard/matrix_keypad.c:95 enable_row_irqs() warn: sleeping in atomic context
> matrix_keypad_scan() <- disables preempt
> -> enable_row_irqs()
>
> drivers/input/keyboard/matrix_keypad.c:108 disable_row_irqs() warn: sleeping in atomic context
> matrix_keypad_interrupt() <- disables preempt
> -> disable_row_irqs()
>
> regards,
> dan carpenter
Ah, the legacy API is at it again. Every legacy gpio_get/set_value()
call results in calling gpio_to_desc() after which a chip lookup
follows, taking the sleeping lock). Ugh, I will have to revert this. I
think that the only way forward will be an SCRU protected list.
That is what 15 years of technical debt looks like sadly. :(
Bartosz
^ permalink raw reply
* Re: [PATCH 1/2] HID: hid-steam: remove pointless error message
From: Benjamin Tissoires @ 2024-01-15 13:45 UTC (permalink / raw)
To: Jiri Kosina, Dan Carpenter
Cc: Benjamin Tissoires, linux-input, linux-kernel, kernel-janitors
In-Reply-To: <305898fb-6bd4-4749-806c-05ec51bbeb80@moroto.mountain>
On Fri, 12 Jan 2024 17:34:14 +0300, Dan Carpenter wrote:
> This error message doesn't really add any information. If modprobe
> fails then the user will already know what the error code is. In the
> case of kmalloc() it's a style violation to print an error message for
> that because kmalloc has it's own better error messages built in.
>
>
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git (for-6.8/upstream-fixes), thanks!
[1/2] HID: hid-steam: remove pointless error message
https://git.kernel.org/hid/hid/c/a96681699611
[2/2] HID: hid-steam: Fix cleanup in probe()
https://git.kernel.org/hid/hid/c/a9f1da09c69f
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* [PATCH v1 3/7] HID: playstation: DS4: Don't fail on FW/HW version request
From: Max Staudt @ 2024-01-15 14:45 UTC (permalink / raw)
To: Roderick Colenbrander, Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, max
In-Reply-To: <20240115144538.12018-1-max@enpas.org>
Some third-party controllers can't report firmware/hardware version.
Unlike for the DualSense, the driver does not use these values for
anything in the DualShock 4 case, but merely exposes them via sysfs.
They will simply be 0x0.
Signed-off-by: Max Staudt <max@enpas.org>
---
drivers/hid/hid-playstation.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index 0a3c442af305..12321cae4416 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -2561,7 +2561,7 @@ static struct ps_device *dualshock4_create(struct hid_device *hdev)
ret = dualshock4_get_firmware_info(ds4);
if (ret) {
hid_err(hdev, "Failed to get firmware info from DualShock4\n");
- return ERR_PTR(ret);
+ hid_err(hdev, "HW/FW version data in sysfs will be invalid.\n");
}
ret = ps_devices_list_add(ps_dev);
--
2.39.2
^ permalink raw reply related
* [PATCH v1 1/7] HID: playstation: DS4: Fix LED blinking
From: Max Staudt @ 2024-01-15 14:45 UTC (permalink / raw)
To: Roderick Colenbrander, Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, max
In-Reply-To: <20240115144538.12018-1-max@enpas.org>
There was no way to disable blinking once enabled.
Disable it on brightness = 0, as per the Linux LED spec.
The driver reports back the values it sends to the controller, but they
need to be scaled back to milliseconds. Setting the LED blinking via
sysfs works as expected now.
Signed-off-by: Max Staudt <max@enpas.org>
---
drivers/hid/hid-playstation.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index 8ac8f7b8e317..7f50e13601f0 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -2037,8 +2037,9 @@ static int dualshock4_led_set_blink(struct led_classdev *led, unsigned long *del
dualshock4_schedule_work(ds4);
- *delay_on = ds4->lightbar_blink_on;
- *delay_off = ds4->lightbar_blink_off;
+ /* Report scaled values back to LED subsystem */
+ *delay_on = ds4->lightbar_blink_on * 10;
+ *delay_off = ds4->lightbar_blink_off * 10;
return 0;
}
@@ -2065,6 +2066,13 @@ static int dualshock4_led_set_brightness(struct led_classdev *led, enum led_brig
break;
case 3:
ds4->lightbar_enabled = !!value;
+
+ /* brightness = 0 also cancels blinking in Linux. */
+ if (!ds4->lightbar_enabled) {
+ ds4->lightbar_blink_off = 0;
+ ds4->lightbar_blink_on = 0;
+ ds4->update_lightbar_blink = true;
+ }
}
ds4->update_lightbar = true;
--
2.39.2
^ permalink raw reply related
* [PATCH v1 4/7] HID: playstation: DS4: Don't fail on calibration data request
From: Max Staudt @ 2024-01-15 14:45 UTC (permalink / raw)
To: Roderick Colenbrander, Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, max
In-Reply-To: <20240115144538.12018-1-max@enpas.org>
Some third-party controllers can't report calibration data for the
gyro/accelerometer.
We can still use the gamepad as-is, so let's do that.
Signed-off-by: Max Staudt <max@enpas.org>
---
drivers/hid/hid-playstation.c | 28 +++++++++++++++++-----------
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index 12321cae4416..2bf44bd3cc8a 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -1778,8 +1778,10 @@ static int dualshock4_get_calibration_data(struct dualshock4 *ds4)
int retries;
buf = kzalloc(DS4_FEATURE_REPORT_CALIBRATION_SIZE, GFP_KERNEL);
- if (!buf)
- return -ENOMEM;
+ if (!buf) {
+ ret = -ENOMEM;
+ goto no_buffer_tail_check;
+ }
/* We should normally receive the feature report data we asked
* for, but hidraw applications such as Steam can issue feature
@@ -1798,24 +1800,25 @@ static int dualshock4_get_calibration_data(struct dualshock4 *ds4)
hid_err(hdev, "Failed to retrieve DualShock4 calibration info: %d\n", ret);
ret = -EILSEQ;
- goto err_free;
} else {
break;
}
}
} else { /* Bluetooth */
buf = kzalloc(DS4_FEATURE_REPORT_CALIBRATION_BT_SIZE, GFP_KERNEL);
- if (!buf)
- return -ENOMEM;
+ if (!buf) {
+ ret = -ENOMEM;
+ goto no_buffer_tail_check;
+ }
ret = ps_get_report(hdev, DS4_FEATURE_REPORT_CALIBRATION_BT, buf,
DS4_FEATURE_REPORT_CALIBRATION_BT_SIZE, true);
- if (ret) {
+
+ if (ret)
hid_err(hdev, "Failed to retrieve DualShock4 calibration info: %d\n", ret);
- goto err_free;
- }
}
+ /* Parse buffer. If the transfer failed, this safely copies zeroes. */
gyro_pitch_bias = get_unaligned_le16(&buf[1]);
gyro_yaw_bias = get_unaligned_le16(&buf[3]);
gyro_roll_bias = get_unaligned_le16(&buf[5]);
@@ -1867,6 +1870,11 @@ static int dualshock4_get_calibration_data(struct dualshock4 *ds4)
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
@@ -1919,8 +1927,6 @@ static int dualshock4_get_calibration_data(struct dualshock4 *ds4)
}
}
-err_free:
- kfree(buf);
return ret;
}
@@ -2571,7 +2577,7 @@ static struct ps_device *dualshock4_create(struct hid_device *hdev)
ret = dualshock4_get_calibration_data(ds4);
if (ret) {
hid_err(hdev, "Failed to get calibration data from DualShock4\n");
- goto err;
+ hid_err(hdev, "Gyroscope and accelerometer will be inaccurate.\n");
}
ds4->gamepad = ps_gamepad_create(hdev, dualshock4_play_effect);
--
2.39.2
^ permalink raw reply related
* [PATCH v1 5/7] HID: playstation: DS4: Parse minimal report 0x01
From: Max Staudt @ 2024-01-15 14:45 UTC (permalink / raw)
To: Roderick Colenbrander, Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, max
In-Reply-To: <20240115144538.12018-1-max@enpas.org>
Some third-party controllers never switch to the full 0x11 report.
They keep sending the short 0x01 report, so let's parse that instead.
Signed-off-by: Max Staudt <max@enpas.org>
---
drivers/hid/hid-playstation.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index 2bf44bd3cc8a..086b0768fa51 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -287,6 +287,8 @@ struct dualsense_output_report {
#define DS4_INPUT_REPORT_USB 0x01
#define DS4_INPUT_REPORT_USB_SIZE 64
+#define DS4_INPUT_REPORT_BT_MINIMAL 0x01
+#define DS4_INPUT_REPORT_BT_MINIMAL_SIZE 10
#define DS4_INPUT_REPORT_BT 0x11
#define DS4_INPUT_REPORT_BT_SIZE 78
#define DS4_OUTPUT_REPORT_USB 0x05
@@ -2198,6 +2200,7 @@ static int dualshock4_parse_report(struct ps_device *ps_dev, struct hid_report *
int battery_status, i, j;
uint16_t sensor_timestamp;
unsigned long flags;
+ bool is_minimal = false;
/*
* DualShock4 in USB uses the full HID report for reportID 1, but
@@ -2225,6 +2228,18 @@ static int dualshock4_parse_report(struct ps_device *ps_dev, struct hid_report *
ds4_report = &bt->common;
num_touch_reports = bt->num_touch_reports;
touch_reports = bt->touch_reports;
+ } else if (hdev->bus == BUS_BLUETOOTH &&
+ report->id == DS4_INPUT_REPORT_BT_MINIMAL &&
+ size == DS4_INPUT_REPORT_BT_MINIMAL_SIZE) {
+ /* Some third-party pads never switch to the full 0x11 report.
+ * The short 0x01 report is 10 bytes long:
+ * u8 report_id == 0x01
+ * u8 first_bytes_of_full_report[9]
+ * So let's reuse the full report parser, and stop it after
+ * parsing the buttons.
+ */
+ ds4_report = (struct dualshock4_input_report_common *)&data[1];
+ is_minimal = true;
} else {
hid_err(hdev, "Unhandled reportID=%d\n", report->id);
return -1;
@@ -2258,6 +2273,9 @@ static int dualshock4_parse_report(struct ps_device *ps_dev, struct hid_report *
input_report_key(ds4->gamepad, BTN_MODE, ds4_report->buttons[2] & DS_BUTTONS2_PS_HOME);
input_sync(ds4->gamepad);
+ if (is_minimal)
+ goto finish_minimal;
+
/* Parse and calibrate gyroscope data. */
for (i = 0; i < ARRAY_SIZE(ds4_report->gyro); i++) {
int raw_data = (short)le16_to_cpu(ds4_report->gyro[i]);
@@ -2365,6 +2383,7 @@ static int dualshock4_parse_report(struct ps_device *ps_dev, struct hid_report *
ps_dev->battery_status = battery_status;
spin_unlock_irqrestore(&ps_dev->lock, flags);
+finish_minimal:
return 0;
}
--
2.39.2
^ permalink raw reply related
* [PATCH v1 6/7] HID: playstation: Simplify device type ID
From: Max Staudt @ 2024-01-15 14:45 UTC (permalink / raw)
To: Roderick Colenbrander, Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, max
In-Reply-To: <20240115144538.12018-1-max@enpas.org>
Distinguish PS4/PS5 type controllers using .driver_data in
MODULE_DEVICE_TABLE rather than by VID/PID.
This allows adding compatible controllers with different VID/PID.
Signed-off-by: Max Staudt <max@enpas.org>
---
drivers/hid/hid-playstation.c | 40 +++++++++++++++++++++++------------
1 file changed, 26 insertions(+), 14 deletions(-)
diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index 086b0768fa51..a0eb36d695d9 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -27,6 +27,11 @@ static DEFINE_IDA(ps_player_id_allocator);
#define HID_PLAYSTATION_VERSION_PATCH 0x8000
+enum PS_TYPE {
+ PS_TYPE_PS4_DUALSHOCK4,
+ PS_TYPE_PS5_DUALSENSE,
+};
+
/* Base class for playstation devices. */
struct ps_device {
struct list_head list;
@@ -2690,17 +2695,14 @@ static int ps_probe(struct hid_device *hdev, const struct hid_device_id *id)
goto err_stop;
}
- if (hdev->product == USB_DEVICE_ID_SONY_PS4_CONTROLLER ||
- hdev->product == USB_DEVICE_ID_SONY_PS4_CONTROLLER_2 ||
- hdev->product == USB_DEVICE_ID_SONY_PS4_CONTROLLER_DONGLE) {
+ if (id->driver_data == PS_TYPE_PS4_DUALSHOCK4) {
dev = dualshock4_create(hdev);
if (IS_ERR(dev)) {
hid_err(hdev, "Failed to create dualshock4.\n");
ret = PTR_ERR(dev);
goto err_close;
}
- } else if (hdev->product == USB_DEVICE_ID_SONY_PS5_CONTROLLER ||
- hdev->product == USB_DEVICE_ID_SONY_PS5_CONTROLLER_2) {
+ } else if (id->driver_data == PS_TYPE_PS5_DUALSENSE) {
dev = dualsense_create(hdev);
if (IS_ERR(dev)) {
hid_err(hdev, "Failed to create dualsense.\n");
@@ -2734,16 +2736,26 @@ static void ps_remove(struct hid_device *hdev)
static const struct hid_device_id ps_devices[] = {
/* Sony DualShock 4 controllers for PS4 */
- { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER) },
- { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER) },
- { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER_2) },
- { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER_2) },
- { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER_DONGLE) },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER),
+ .driver_data = PS_TYPE_PS4_DUALSHOCK4 },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER),
+ .driver_data = PS_TYPE_PS4_DUALSHOCK4 },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER_2),
+ .driver_data = PS_TYPE_PS4_DUALSHOCK4 },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER_2),
+ .driver_data = PS_TYPE_PS4_DUALSHOCK4 },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER_DONGLE),
+ .driver_data = PS_TYPE_PS4_DUALSHOCK4 },
+
/* Sony DualSense controllers for PS5 */
- { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS5_CONTROLLER) },
- { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS5_CONTROLLER) },
- { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS5_CONTROLLER_2) },
- { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS5_CONTROLLER_2) },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS5_CONTROLLER),
+ .driver_data = PS_TYPE_PS5_DUALSENSE },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS5_CONTROLLER),
+ .driver_data = PS_TYPE_PS5_DUALSENSE },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS5_CONTROLLER_2),
+ .driver_data = PS_TYPE_PS5_DUALSENSE },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS5_CONTROLLER_2),
+ .driver_data = PS_TYPE_PS5_DUALSENSE },
{ }
};
MODULE_DEVICE_TABLE(hid, ps_devices);
--
2.39.2
^ permalink raw reply related
* [PATCH v1 7/7] HID: playstation: DS4: Add VID/PID for SZ-MYPOWER controllers
From: Max Staudt @ 2024-01-15 14:45 UTC (permalink / raw)
To: Roderick Colenbrander, Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, max
In-Reply-To: <20240115144538.12018-1-max@enpas.org>
It seems like this USB VID is not officially assigned, so let's create a
hid-ids.h entry without a vendor or product name.
Signed-off-by: Max Staudt <max@enpas.org>
---
drivers/hid/hid-ids.h | 3 +++
drivers/hid/hid-playstation.c | 4 ++++
2 files changed, 7 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 72046039d1be..df831ab464a4 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -22,6 +22,9 @@
#define USB_DEVICE_ID_3M2256 0x0502
#define USB_DEVICE_ID_3M3266 0x0506
+#define USB_VENDOR_ID_7545 0x7545
+#define USB_DEVICE_ID_7545_0104 0x0104
+
#define USB_VENDOR_ID_A4TECH 0x09da
#define USB_DEVICE_ID_A4TECH_WCP32PU 0x0006
#define USB_DEVICE_ID_A4TECH_X5_005D 0x000a
diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index a0eb36d695d9..0aa474f1e96f 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -2747,6 +2747,10 @@ static const struct hid_device_id ps_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER_DONGLE),
.driver_data = PS_TYPE_PS4_DUALSHOCK4 },
+ /* Third-party controllers identifying as "SZ-MYPOWER" */
+ { HID_USB_DEVICE(USB_VENDOR_ID_7545, USB_DEVICE_ID_7545_0104),
+ .driver_data = PS_TYPE_PS4_DUALSHOCK4 },
+
/* Sony DualSense controllers for PS5 */
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS5_CONTROLLER),
.driver_data = PS_TYPE_PS5_DUALSENSE },
--
2.39.2
^ permalink raw reply related
* [PATCH v1] HID: nintendo: Don't fail on setting baud rate
From: Max Staudt @ 2024-01-15 14:50 UTC (permalink / raw)
To: Daniel J . Ogorchock, Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, max
Some third-party controllers can't change the baud rate.
We can still use the gamepad as-is, so let's do that.
Signed-off-by: Max Staudt <max@enpas.org>
---
drivers/hid/hid-nintendo.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-nintendo.c b/drivers/hid/hid-nintendo.c
index 997c3a1adaca..8cba0612c3ae 100644
--- a/drivers/hid/hid-nintendo.c
+++ b/drivers/hid/hid-nintendo.c
@@ -2164,8 +2164,11 @@ static int joycon_init(struct hid_device *hdev)
/* set baudrate for improved latency */
ret = joycon_send_usb(ctlr, JC_USB_CMD_BAUDRATE_3M, HZ);
if (ret) {
+ /*
+ * We can function with the default baudrate.
+ * Provide a warning, and continue on.
+ */
hid_err(hdev, "Failed to set baudrate; ret=%d\n", ret);
- goto out_unlock;
}
/* handshake */
ret = joycon_send_usb(ctlr, JC_USB_CMD_HANDSHAKE, HZ);
--
2.39.2
^ permalink raw reply related
* [PATCH v1 2/7] HID: playstation: DS4: Don't fail on MAC address request
From: Max Staudt @ 2024-01-15 14:45 UTC (permalink / raw)
To: Roderick Colenbrander, Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, max
In-Reply-To: <20240115144538.12018-1-max@enpas.org>
Some third-party controllers can't report their MAC address.
Since a unique ID is needed for ps_devices_list_add() and
ps_device_register_battery(), let's use hdev->id for this when we don't
have a MAC address.
Signed-off-by: Max Staudt <max@enpas.org>
---
drivers/hid/hid-playstation.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index 7f50e13601f0..0a3c442af305 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -1966,7 +1966,10 @@ static int dualshock4_get_mac_address(struct dualshock4 *ds4)
DS4_FEATURE_REPORT_PAIRING_INFO_SIZE, false);
if (ret) {
hid_err(hdev, "Failed to retrieve DualShock4 pairing info: %d\n", ret);
- goto err_free;
+ hid_err(hdev, "Generating fake MAC address for this device.\n");
+ buf[1] = (hdev->id >> 0) & 0xff;
+ buf[2] = (hdev->id >> 8) & 0xff;
+ buf[3] = (hdev->id >> 16) & 0xff;
}
memcpy(ds4->base.mac_address, &buf[1], sizeof(ds4->base.mac_address));
@@ -1986,7 +1989,6 @@ static int dualshock4_get_mac_address(struct dualshock4 *ds4)
return 0;
}
-err_free:
kfree(buf);
return ret;
}
@@ -2552,7 +2554,7 @@ static struct ps_device *dualshock4_create(struct hid_device *hdev)
ret = dualshock4_get_mac_address(ds4);
if (ret) {
hid_err(hdev, "Failed to get MAC address from DualShock4\n");
- return ERR_PTR(ret);
+ hid_err(hdev, "Can't detect simultaneous USB/BT connections from this device.\n");
}
snprintf(hdev->uniq, sizeof(hdev->uniq), "%pMR", ds4->base.mac_address);
--
2.39.2
^ permalink raw reply related
* [PATCH v1 0/7] HID: playstation: DS4: LED bugfix, third-party gamepad support
From: Max Staudt @ 2024-01-15 14:45 UTC (permalink / raw)
To: Roderick Colenbrander, Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, max
Dear hid-playstation maintainers,
Could you please have a look at the enclosed patches for the DualShock 4
driver in hid-playstation, and upstream them if possible?
There is one bugfix, and a few small patches to enable third-party
controllers. They sometimes don't implement features that they
semantically "don't need", but which currently trip the driver.
For example, for the DualShock 4, we don't actually need to know the
firmware version in order to work with the gamepad - unlike with the
DualSense, which has different driver logic depending on the version.
Finally, there are two patches to add a DS4 compatible controller with
an unassigned VID/PID - I'd appreciate your thoughts on that.
If I can make it easier to upstream these patches, please let me know.
Thanks!
Max
Patches in this series:
[PATCH v1 1/7] HID: playstation: DS4: Fix LED blinking
[PATCH v1 2/7] HID: playstation: DS4: Don't fail on MAC address
[PATCH v1 3/7] HID: playstation: DS4: Don't fail on FW/HW version
[PATCH v1 4/7] HID: playstation: DS4: Don't fail on calibration data
[PATCH v1 5/7] HID: playstation: DS4: Parse minimal report 0x01
[PATCH v1 6/7] HID: playstation: Simplify device type ID
[PATCH v1 7/7] HID: playstation: DS4: Add VID/PID for SZ-MYPOWER
^ permalink raw reply
* Re: element sizes in input_event struct on riscv32
From: Antonios Salios @ 2024-01-15 15:46 UTC (permalink / raw)
To: Arnd Bergmann, Dmitry Torokhov, Deepa Dinamani
Cc: rydberg, linux-input, linux-kernel, Jan Henrik Weinstock,
Lukas Jünger
In-Reply-To: <caa041d27b0fa45aad09a9a262038e3ae4099ca2.camel@mwa.re>
On Thu, 2023-12-21 at 14:38 +0100, Antonios Salios wrote:
> On Thu, 2023-12-21 at 12:28 +0000, Arnd Bergmann wrote:
> > On Thu, Dec 21, 2023, at 08:56, Antonios Salios wrote:
> > > On Tue, 2023-12-19 at 13:53 +0000, Arnd Bergmann wrote:
> > > > On Tue, Dec 19, 2023, at 02:50, Dmitry Torokhov wrote:
> >
> > I don't know what __TIMESIZE is, this is not part of the kernel ABI
> > as far as I can tell. __USE_TIME_BITS64 should be set by any 32-bit
> > architecture if the C library defines a 64-bit time_t, otherwise
> > the
> > kernel headers have no way of picking the correct definitions based
> > on preprocessor logic.
>
> Okay, I agree that this might be a libc problem then. I'll ask the
> glibc maintainers.
>
According to a glibc maintainer, __USE_TIME_BITS64 is not set on
architectures that use 64-bit time_t as default such as riscv32.
This can also be seen here [1].
Perhaps the kernel header needs to check the size of time_t in some
other way?
[1]
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/features-time64.h;hb=glibc-2.37
--
Antonios Salios
Software Engineer
MachineWare GmbH | www.machineware.de
Hühnermarkt 19, 52062 Aachen, Germany
Amtsgericht Aachen HRB25734
Geschäftsführung
Lukas Jünger
Dr.-Ing. Jan Henrik Weinstock
^ permalink raw reply
* Re: element sizes in input_event struct on riscv32
From: Arnd Bergmann @ 2024-01-15 16:11 UTC (permalink / raw)
To: Antonios Salios, Dmitry Torokhov, Deepa Dinamani
Cc: rydberg, linux-input, linux-kernel, Jan Henrik Weinstock,
Lukas Jünger
In-Reply-To: <20be7b9d5b8c0bef2a35da3d207c15eae75bfd4d.camel@mwa.re>
On Mon, Jan 15, 2024, at 16:46, Antonios Salios wrote:
> On Thu, 2023-12-21 at 14:38 +0100, Antonios Salios wrote:
>> On Thu, 2023-12-21 at 12:28 +0000, Arnd Bergmann wrote:
>> > On Thu, Dec 21, 2023, at 08:56, Antonios Salios wrote:
>> > > On Tue, 2023-12-19 at 13:53 +0000, Arnd Bergmann wrote:
>> > > > On Tue, Dec 19, 2023, at 02:50, Dmitry Torokhov wrote:
>> >
>> > I don't know what __TIMESIZE is, this is not part of the kernel ABI
>> > as far as I can tell. __USE_TIME_BITS64 should be set by any 32-bit
>> > architecture if the C library defines a 64-bit time_t, otherwise
>> > the
>> > kernel headers have no way of picking the correct definitions based
>> > on preprocessor logic.
>>
>> Okay, I agree that this might be a libc problem then. I'll ask the
>> glibc maintainers.
>>
>
> According to a glibc maintainer, __USE_TIME_BITS64 is not set on
> architectures that use 64-bit time_t as default such as riscv32.
> This can also be seen here [1].
>
> Perhaps the kernel header needs to check the size of time_t in some
> other way?
>
> [1]
> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/features-time64.h;hb=glibc-2.37
I don't see any better way, the kernel headers started using this
in 2018 based on the glibc design documents and discussions
with glibc maintainers, see the section on ioctls in
https://sourceware.org/glibc/wiki/Y2038ProofnessDesign
The kernel only relies on this macro for the sound and
input subsystem, but there are numerous applications and
libraries that copied the kernel definition because that
was defined as the only reliable method.
Maybe you can work around by patching the glibc sources
yourself?
Arnd
^ permalink raw reply
* [PATCH] dt-bindings: input: silead,gsl1680: do not override firmware-name $ref
From: Krzysztof Kozlowski @ 2024-01-15 18:20 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
dtschema package defines firmware-name as string-array, so individual
bindings should not make it a string but instead just narrow the number
of expected firmware file names.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
.../devicetree/bindings/input/touchscreen/silead,gsl1680.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml b/Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml
index 95b554be25b4..5381a96f4949 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml
@@ -31,7 +31,7 @@ properties:
maxItems: 1
firmware-name:
- $ref: /schemas/types.yaml#/definitions/string
+ maxItems: 1
description: >
File basename for board specific firmware
--
2.34.1
^ permalink raw reply related
* [PATCH v3] Input: adc-joystick: Handle inverted axes
From: Chris Morgan @ 2024-01-15 19:27 UTC (permalink / raw)
To: linux-input
Cc: contact, dmitry.torokhov, hdegoede, paul, peter.hutterer, svv,
biswarupp, Chris Morgan
From: Chris Morgan <macromorgan@hotmail.com>
When one or more axes are inverted, (where min > max), normalize the
data so that min < max and invert the values reported to the input
stack.
This ensures we can continue defining the device correctly in the
device tree while not breaking downstream assumptions that min is
always less than max.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Acked-by: Artur Rojek <contact@artur-rojek.eu>
---
Changes since V2:
- Explicitly set bool value to "true" instead of "1".
- Split adc_joystick_invert() function definition to 2 lines.
- Corrected changes message location.
Changes since V1:
- Moved proposed helper for inversion from input stack to adc-joystick
driver.
drivers/input/joystick/adc-joystick.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/input/joystick/adc-joystick.c b/drivers/input/joystick/adc-joystick.c
index c0deff5d4282..6b155e614b5a 100644
--- a/drivers/input/joystick/adc-joystick.c
+++ b/drivers/input/joystick/adc-joystick.c
@@ -18,6 +18,7 @@ struct adc_joystick_axis {
s32 range[2];
s32 fuzz;
s32 flat;
+ bool inverted;
};
struct adc_joystick {
@@ -29,6 +30,15 @@ struct adc_joystick {
bool polled;
};
+static int adc_joystick_invert(struct input_dev *dev,
+ unsigned int axis, int val)
+{
+ int min = dev->absinfo[axis].minimum;
+ int max = dev->absinfo[axis].maximum;
+
+ return (max + min) - val;
+}
+
static void adc_joystick_poll(struct input_dev *input)
{
struct adc_joystick *joy = input_get_drvdata(input);
@@ -38,6 +48,8 @@ static void adc_joystick_poll(struct input_dev *input)
ret = iio_read_channel_raw(&joy->chans[i], &val);
if (ret < 0)
return;
+ if (joy->axes[i].inverted)
+ val = adc_joystick_invert(input, i, val);
input_report_abs(input, joy->axes[i].code, val);
}
input_sync(input);
@@ -86,6 +98,8 @@ static int adc_joystick_handle(const void *data, void *private)
val = sign_extend32(val, msb);
else
val &= GENMASK(msb, 0);
+ if (joy->axes[i].inverted)
+ val = adc_joystick_invert(joy->input, i, val);
input_report_abs(joy->input, joy->axes[i].code, val);
}
@@ -168,11 +182,17 @@ static int adc_joystick_set_axes(struct device *dev, struct adc_joystick *joy)
goto err_fwnode_put;
}
+ if (axes[i].range[0] > axes[i].range[1]) {
+ dev_dbg(dev, "abs-axis %d inverted\n", i);
+ axes[i].inverted = true;
+ }
+
fwnode_property_read_u32(child, "abs-fuzz", &axes[i].fuzz);
fwnode_property_read_u32(child, "abs-flat", &axes[i].flat);
input_set_abs_params(joy->input, axes[i].code,
- axes[i].range[0], axes[i].range[1],
+ min_array(axes[i].range, 2),
+ max_array(axes[i].range, 2),
axes[i].fuzz, axes[i].flat);
input_set_capability(joy->input, EV_ABS, axes[i].code);
}
--
2.34.1
^ permalink raw reply related
* [PATCH] Input: Remove usage of the deprecated ida_simple_xx() API
From: Christophe JAILLET @ 2024-01-15 20:19 UTC (permalink / raw)
To: Dmitry Torokhov
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().
Note that the upper limit of ida_simple_get() is exclusive, but the one of
ida_alloc_range() is inclusive. So a -1 has been added when needed.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/input/input.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/input/input.c b/drivers/input/input.c
index f71ea4fb173f..de7884a5be39 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -2629,17 +2629,15 @@ int input_get_new_minor(int legacy_base, unsigned int legacy_num,
* locking is needed here.
*/
if (legacy_base >= 0) {
- int minor = ida_simple_get(&input_ida,
- legacy_base,
- legacy_base + legacy_num,
- GFP_KERNEL);
+ int minor = ida_alloc_range(&input_ida, legacy_base,
+ legacy_base + legacy_num - 1,
+ GFP_KERNEL);
if (minor >= 0 || !allow_dynamic)
return minor;
}
- return ida_simple_get(&input_ida,
- INPUT_FIRST_DYNAMIC_DEV, INPUT_MAX_CHAR_DEVICES,
- GFP_KERNEL);
+ return ida_alloc_range(&input_ida, INPUT_FIRST_DYNAMIC_DEV,
+ INPUT_MAX_CHAR_DEVICES - 1, GFP_KERNEL);
}
EXPORT_SYMBOL(input_get_new_minor);
@@ -2652,7 +2650,7 @@ EXPORT_SYMBOL(input_get_new_minor);
*/
void input_free_minor(unsigned int minor)
{
- ida_simple_remove(&input_ida, minor);
+ ida_free(&input_ida, minor);
}
EXPORT_SYMBOL(input_free_minor);
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox