* Re: [PATCH 0/5] HID: playstation: various DS4 and DualSense fixes
From: Jiri Kosina @ 2023-01-18 9:13 UTC (permalink / raw)
To: Roderick Colenbrander
Cc: Benjamin Tissoires, linux-input, Roderick Colenbrander
In-Reply-To: <20230106015910.3031670-1-roderick.colenbrander@sony.com>
On Thu, 5 Jan 2023, Roderick Colenbrander wrote:
> Hi,
>
> This patch set contains a number of small fixes and stability improvements.
>
> The stability patches are most critical as they prevent kernel crashes.
> Over the years there have been various buggy devices usually clone devices,
> but now apparently some official devices with wiped calibration data.
> It is hard to handle all permutations of devices as some have constants,
> some have broken constants (e.g. wrong sign of a coefficient). We disable
> calibration when we see an invalid 0 denominator. The patch adds the same
> logic to both the DualShock4 and DualSense code.
>
> As part of the calibration stability improvements, a thorough review was
> performed of the calibration code as it was suspected it was potentially
> incorrect. It was found to be only slightly wrong for the handling of the
> bias of the gyroscopes. Two patches fix this for both DualShock4 and DualSense.
> There is only a marginal impact on practical values as the bias values
> tend to be quite small.
>
> Thanks,
> Roderick Colenbrander
> Sony Interactive Entertainment, LLC
I am splitting the stability ones (for 6.2) from the small improvements /
cleanups (for 6.3).
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 4/5] HID: playstation: correct DualShock4 gyro bias handling.
From: Jiri Kosina @ 2023-01-18 9:12 UTC (permalink / raw)
To: Roderick Colenbrander
Cc: Benjamin Tissoires, linux-input, Roderick Colenbrander
In-Reply-To: <20230106015910.3031670-5-roderick.colenbrander@sony.com>
On Thu, 5 Jan 2023, Roderick Colenbrander wrote:
> The bias for the gyroscope is not used correctly. The sensor bias
> needs to be used in calculation of the 'sensivity' instead of being
> an offset.
>
> In practice this has little input on the values as the bias values
> tends to be small (+/- 20).
>
> Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Applied to for-6.3/sony.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 5/5] HID: playstation: correct DualSense gyro bias handling.
From: Jiri Kosina @ 2023-01-18 9:12 UTC (permalink / raw)
To: Roderick Colenbrander
Cc: Benjamin Tissoires, linux-input, Roderick Colenbrander
In-Reply-To: <20230106015910.3031670-6-roderick.colenbrander@sony.com>
On Thu, 5 Jan 2023, Roderick Colenbrander wrote:
> The bias for the gyroscope is not used correctly. The sensor bias
> needs to be used in calculation of the 'sensivity' instead of being
> an offset.
>
> In practice this has little input on the values as the bias values
> tends to be small (+/- 20).
>
> Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Applied to for-6.3/sony.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 3/5] HID: playstation: sanity check DualSense calibration data.
From: Jiri Kosina @ 2023-01-18 9:11 UTC (permalink / raw)
To: Roderick Colenbrander
Cc: Benjamin Tissoires, linux-input, Roderick Colenbrander
In-Reply-To: <20230106015910.3031670-4-roderick.colenbrander@sony.com>
On Thu, 5 Jan 2023, Roderick Colenbrander wrote:
> Make sure calibration values are defined to prevent potential kernel
> crashes. This fixes a hypothetical issue for virtual or clone devices
> inspired by a similar fix for DS4.
>
> Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Applied to for-6.2/upstream-fixes.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 2/5] HID: playstation: sanity check DualShock4 calibration data.
From: Jiri Kosina @ 2023-01-18 9:10 UTC (permalink / raw)
To: Roderick Colenbrander
Cc: Benjamin Tissoires, linux-input, Roderick Colenbrander,
Alain Carlucci
In-Reply-To: <20230106015910.3031670-3-roderick.colenbrander@sony.com>
On Thu, 5 Jan 2023, Roderick Colenbrander wrote:
> Some DualShock4 devices report invalid calibration data resulting
> in kernel oopses due to division by zero during report handling.
>
> The devices affected generally appear to be clone devices, which don't
> implement all reports properly and don't populate proper calibration
> data. The issue may have been seen on an official device with erased
> calibration reports.
>
> This patch prevents the crashes by essentially disabling calibration
> when invalid values are detected.
>
> Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
> Tested-by: Alain Carlucci <alain.carlucci@gmail.com>
Applied to for-6.2/upstream-fixes.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v6 RESEND] HID: multitouch: Add quirks for flipped axes
From: Jiri Kosina @ 2023-01-18 9:09 UTC (permalink / raw)
To: Allen Ballway
Cc: benjamin.tissoires, dmitry.torokhov, dtor, linux-input,
linux-kernel, rydberg
In-Reply-To: <20230110202550.651091-1-ballway@chromium.org>
On Tue, 10 Jan 2023, Allen Ballway wrote:
> Certain touchscreen devices, such as the ELAN9034, are oriented
> incorrectly and report touches on opposite points on the X and Y axes.
> For example, a 100x200 screen touched at (10,20) would report (90, 180)
> and vice versa.
>
> This is fixed by adding device quirks to transform the touch points
> into the correct spaces, from X -> MAX(X) - X, and Y -> MAX(Y) - Y.
>
> Signed-off-by: Allen Ballway <ballway@chromium.org>
> ---
> V5 -> V6: Add another IS_ENABLED check for CONFIG_I2C_DMI_CORE because
> the module may not be there at all.
>
> V4 -> V5: Add IS_ENABLED check for CONFIG_DMI to prevent linker error.
>
> V3 -> V4: Move quirk logic to i2c_hid_get_dmi_quirks and remove
> duplicate quirks from hid-multitouch.
>
> V2 -> V3: Use existing HID_QUIRK_*_INVERT and match the quirk in
> hid-quirk, passing down to hid-multitouch through the hid device.
>
> V1 -> V2: Address review comments, change to use DMI match. Confirmed
> MT_TOOL_X/Y require transformation and update orientation based on
> flipped axes.
Appplied, thank you.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: amd_sfh: Add support for tablet-mode-switch sensor
From: Basavaraj Natikar @ 2023-01-18 9:06 UTC (permalink / raw)
To: Jiri Kosina, Adrian Freund
Cc: linux-input, linux-kernel, Basavaraj Natikar, Benjamin Tissoires,
Luke D. Jones, Ivan Dovgal
In-Reply-To: <nycvar.YFH.7.76.2301180948450.1734@cbobk.fhfr.pm>
On 1/18/2023 2:19 PM, Jiri Kosina wrote:
> On Sun, 18 Dec 2022, Adrian Freund wrote:
>
>> This patch adds support for the tablet mode switch sensors on
>> convertible devices where that sensor is managed by AMD SFH, like the
>> Asus Flow X13 and the Lenovo ThinkPad L13 Yoga Gen2 (AMD).
>>
>> Co-developed-by: Ivan Dovgal <iv.dovg@gmail.com>
>> Signed-off-by: Ivan Dovgal <iv.dovg@gmail.com>
>> Co-developed-by: Luke D. Jones <luke@ljones.dev>
>> Signed-off-by: Luke D. Jones <luke@ljones.dev>
>> Signed-off-by: Adrian Freund <adrian@freund.io>
Whole patch does not take any input data validation from any sensors
Please specify what are valid values?
Thanks,
--
Basavaraj
^ permalink raw reply
* Re: [PATCH v2 1/2] HID: i2c-hid: acpi: Drop unneded NULL check of adev
From: Jiri Kosina @ 2023-01-18 9:06 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Dmitry Torokhov, Raul E Rangel, Benjamin Tissoires, linux-input,
linux-kernel
In-Reply-To: <20230116154621.16135-1-andriy.shevchenko@linux.intel.com>
On Mon, 16 Jan 2023, Andy Shevchenko wrote:
> The driver is enumerated on ACPI platforms, so adev is valid.
> Since there is no valid I²C ID table provided, there is no
> possibility to bind a device to this driver via user space.
> Hence, drop unneeded NULL check of adev.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Applied both to hid.git#for-6.3/i2c-hid. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 1/2] HID: core: Provide new max_buffer_size attribute to over-ride the default
From: Jiri Kosina @ 2023-01-18 9:03 UTC (permalink / raw)
To: Lee Jones; +Cc: benjamin.tissoires, avid.rheinsberg, linux-kernel, linux-input
In-Reply-To: <20230113150557.1308176-1-lee@kernel.org>
On Fri, 13 Jan 2023, Lee Jones wrote:
> Presently, when a report is processed, its size is compared solely
> against the value specified by user-space.
While I am generally fine with the idea, I don't understand this sentence.
What exactly do you mean by 'specified by user-space'? It's defined as a
compile-time constant.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v3] HID: Recognize sensors with application collections
From: Jiri Kosina @ 2023-01-18 8:54 UTC (permalink / raw)
To: Aditya Garg
Cc: benjamin.tissoires@redhat.com, jic23@kernel.org,
srinivas.pandruvada@linux.intel.com, linux-input@vger.kernel.org,
LKML, linux-iio@vger.kernel.org, orlandoch.dev@gmail.com,
ronald@innovation.ch
In-Reply-To: <9E66CF6F-99A0-4CC5-9FA0-3A9DCFCA0388@live.com>
On Wed, 11 Jan 2023, Aditya Garg wrote:
> From: Ronald Tschalär <ronald@innovation.ch>
>
> According to HUTRR39 logical sensor devices may be nested inside
> physical collections or may be specified in multiple top-level
> application collections (see page 59, strategies 1 and 2). However,
> the current code was only recognizing those with physical collections.
>
> This issue turned up in the T2 MacBook Pros which define the ALS in
> a top-level application collection.
>
> Signed-off-by: Ronald Tschalär <ronald@innovation.ch>
> Signed-off-by: Aditya Garg <gargaditya08@live.com>
Makes sense. Queued in for-6.3/hid-core. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Custom Software Development
From: Corey Webb @ 2023-01-18 8:50 UTC (permalink / raw)
To: linux-input
Hi,
I would like to reach the person responsible for the implementation of your company's goals, vision and mission or the decision-maker in the development of your technology strategy.
I represent provider of lucrative IT solutions that remove the barriers to process development resulting from limited access to appropriate IT resources.
We guarantee you access to the knowledge and experience of outstanding 3,000 software developers from Poland and 500 professional consultants and senior developers in the United States and other Western countries.
We respond to a variety of needs, ranging from expanding your project team with specialists with specific skills to supporting project managers, experienced innovation teams to creating a Minimum Viable Project (MVP).
The comprehensiveness of our services guarantees you dynamic software development including creation, testing and implementation systems that are the backbone of effective management of the entire organization.
A partnership that lasts for years is the best proof that our clients meet their unique requirements within a specific timeframe, introduce new opportunities and grow their business while we solve their problems.
Are you available for a brief call? I will be looking forward to hearing from you.
Best regards
Corey Webb
^ permalink raw reply
* Re: [PATCH] HID: sony: remove DualShock4 support.
From: Jiri Kosina @ 2023-01-18 8:50 UTC (permalink / raw)
To: Roderick Colenbrander
Cc: Benjamin Tissoires, linux-input, Roderick Colenbrander
In-Reply-To: <20230106211425.3048993-1-roderick.colenbrander@sony.com>
On Fri, 6 Jan 2023, Roderick Colenbrander wrote:
> Now that hid-playstation provides DualShock4 support, remove
> DualShock4 support from hid-sony as it is redundant.
>
> Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
> ---
> drivers/hid/hid-sony.c | 1021 ++--------------------------------------
> 1 file changed, 40 insertions(+), 981 deletions(-)
What's not to like about this diffstat :)
Applied, thanks Roderick.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: amd_sfh: Add support for tablet-mode-switch sensor
From: Jiri Kosina @ 2023-01-18 8:49 UTC (permalink / raw)
To: Adrian Freund
Cc: linux-input, linux-kernel, Basavaraj Natikar, Benjamin Tissoires,
Luke D. Jones, Ivan Dovgal
In-Reply-To: <20221218214723.14735-1-adrian@freund.io>
On Sun, 18 Dec 2022, Adrian Freund wrote:
> This patch adds support for the tablet mode switch sensors on
> convertible devices where that sensor is managed by AMD SFH, like the
> Asus Flow X13 and the Lenovo ThinkPad L13 Yoga Gen2 (AMD).
>
> Co-developed-by: Ivan Dovgal <iv.dovg@gmail.com>
> Signed-off-by: Ivan Dovgal <iv.dovg@gmail.com>
> Co-developed-by: Luke D. Jones <luke@ljones.dev>
> Signed-off-by: Luke D. Jones <luke@ljones.dev>
> Signed-off-by: Adrian Freund <adrian@freund.io>
Basavaraj, could you please review this? Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: uclogic: Use KUNIT_EXPECT_MEMEQ
From: Jiri Kosina @ 2023-01-18 8:47 UTC (permalink / raw)
To: José Expósito
Cc: benjamin.tissoires, mcanal, mairacanal, linux-input, linux-kernel
In-Reply-To: <20221226125736.18053-1-jose.exposito89@gmail.com>
On Mon, 26 Dec 2022, José Expósito wrote:
> Commit b8a926bea8b1 ("kunit: Introduce KUNIT_EXPECT_MEMEQ and
> KUNIT_EXPECT_MEMNEQ macros") introduced a new macro to compare blocks of
> memory and, if the test fails, print the result in a human friendly
> format. For example, this is the output of a test failure:
>
> Expected res == params->expected, but
> res ==
> 01 02 aa 00 00 00 03 bb 00 <00> 00 04 05
> params->expected ==
> 01 02 aa 00 00 00 03 bb 00 <01> 00 04 05
>
> Use this new macro to replace KUNIT_EXPECT_EQ + memcmp.
>
> Signed-off-by: José Expósito <jose.exposito89@gmail.com>
> ---
> drivers/hid/hid-uclogic-rdesc-test.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/hid/hid-uclogic-rdesc-test.c b/drivers/hid/hid-uclogic-rdesc-test.c
> index b429c541bf2f..90bf4e586e01 100644
> --- a/drivers/hid/hid-uclogic-rdesc-test.c
> +++ b/drivers/hid/hid-uclogic-rdesc-test.c
> @@ -197,8 +197,7 @@ static void hid_test_uclogic_template(struct kunit *test)
> params->param_list,
> params->param_num);
> KUNIT_ASSERT_NOT_ERR_OR_NULL(test, res);
> - KUNIT_EXPECT_EQ(test, 0,
> - memcmp(res, params->expected, params->template_size));
> + KUNIT_EXPECT_MEMEQ(test, res, params->expected, params->template_size);
> kfree(res);
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: uclogic: Add support for XP-PEN Deco 01 V2
From: Jiri Kosina @ 2023-01-18 8:43 UTC (permalink / raw)
To: José Expósito
Cc: benjamin.tissoires, linux-input, linux-kernel, Mark Waddoups
In-Reply-To: <20221226123456.14822-1-jose.exposito89@gmail.com>
On Mon, 26 Dec 2022, José Expósito wrote:
> The XP-PEN Deco 01 V2 is a UGEE v2 device with a frame with 8 buttons.
> Its pen has 2 buttons, supports tilt and pressure.
>
> Add its ID in order to support the device.
>
> Link: https://gitlab.freedesktop.org/libinput/libinput/-/issues/839
> Tested-by: Mark Waddoups <mwaddoups@gmail.com>
> Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Applied to hid.git#for-6.2/upstream-fixes. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 0/2] HID: i2c-hid: use standard debugging APIs
From: Jiri Kosina @ 2023-01-18 8:41 UTC (permalink / raw)
To: Thomas Weißschuh; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20221223-hid-dbg-v1-0-f641e80263eb@weissschuh.net>
On Fri, 23 Dec 2022, Thomas Weißschuh wrote:
> When trying to debug i2c-hid I was not able to use the builtin debug
> mechanism because the "debug" module parameter is not writable.
>
> We can change i2c-hid to use the standard kernel debugging APIs which are
> more discoverable and have more features.
>
> There is a bit of a stilistic conflict between consistently using
> i2c_hid_dbg() and consistently using dev_<level>().
>
> The second patch aligns debugging on i2c_hid_dbg().
> If this is unneeded, feel free to drop it.
>
> It would also be easy to just use dev_dbg() everywhere for consistency.
>
> To: Jiri Kosina <jikos@kernel.org>
> To: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> Cc: linux-input@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
>
> ---
> Thomas Weißschuh (2):
> HID: i2c-hid: switch to standard debugging APIs
> HID: i2c-hid: use uniform debugging APIs
>
> drivers/hid/i2c-hid/i2c-hid-core.c | 15 +++------------
> 1 file changed, 3 insertions(+), 12 deletions(-)
Applied to for-6.3/i2c-hid branch, thanks Thomas.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 0/6] HID: uclogic: Add support for XP-PEN Deco PRO SW and MW
From: Jiri Kosina @ 2023-01-18 8:46 UTC (permalink / raw)
To: José Expósito; +Cc: benjamin.tissoires, linux-input, linux-kernel
In-Reply-To: <20221226125454.16106-1-jose.exposito89@gmail.com>
On Mon, 26 Dec 2022, José Expósito wrote:
> Hi!
>
> This series add support for the XP-PEN Deco PRO SW and MW drawing
> tablets.
>
> Both tablets are similar, the only difference between them is their
> size and their IDs. I own one of them and Andreas helped me test the
> other one, so thanks a lot!
>
> Please note that this series might cause conflicts with [1], but they
> should be really easy to fix/I can rebase once it is merged.
>
> About the patches:
>
> - The first patch introduces a quirks to be able to fix the frame type
> reported by these devices.
> - The second patch adds another quirks to know whether a tablet has
> battery or not. I didn't find any difference in the information
> reported by the firmware nor in the Windows driver to obtain this
> information, so I added a manual flag.
> - The fourth patch adds a generic mechanism to schedule jobs when an
> event is received, in this case, to reconnect the tablet.
> - The last two patches add support for the tablets.
>
> Best wishes,
> José Expósito
>
> [1] [PATCH] HID: uclogic: Add support for XP-PEN Deco 01 V2
> https://lore.kernel.org/linux-input/20221226123456.14822-1-jose.exposito89@gmail.com/T/
I have queued this in for-6.3/uclogic branch. The conflict is a nobrainer,
so that shouldn't be an issue at all.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v7 0/8] Add MediaTek MT6357 PMIC support
From: Alexandre Mergnat @ 2023-01-18 8:37 UTC (permalink / raw)
To: Matthias Brugger
Cc: Kevin Hilman, Mark Brown, Liam Girdwood, Alexandre Belloni,
Krzysztof Kozlowski, Alessandro Zummo, Rob Herring, Fabien Parent,
Tianping Fang, Flora Fu, Chen Zhong, Sean Wang, Lee Jones,
Pavel Machek, Dmitry Torokhov, linux-mediatek,
AngeloGioacchino Del Regno, linux-kernel, Rob Herring,
Mattijs Korpershoek, linux-rtc, linux-input, devicetree,
linux-arm-kernel, Krzysztof Kozlowski, Fabien Parent, linux-leds
In-Reply-To: <CAFGrd9qZzpxPWpiEOJacc9m2WDFB8Mgr5U5too89mZmqqFir_Q@mail.gmail.com>
Hi Matthias,
Gentle ping to merge the v8 rebased on top of v6.2-tmp/soc.
https://lore.kernel.org/r/20221005-mt6357-support-v8-0-560caaafee53@baylibre.com
Thanks,
Alex
Le lun. 2 janv. 2023 à 17:10, Alexandre Mergnat
<amergnat@baylibre.com> a écrit :
>
> > >> This patch series adds MFD, PMIC keys, and regulator support for MT6357.
> > >> MT6357 is a MediaTek PMIC very similar to MT6358.
> > >
> > > The regulator driver (and bindings) were merged by Mark. Could you take
> > > the rest of this series via your mediatek tree? The input driver (and
> > > bindings) are ack'd by Dmitry.
> > >
> >
> > Yes I can do that but 3/8 does not apply cleanly. Could you please rebase on top
> > of v6.2-tmp/soc?
>
> Hi Matthias,
>
> I've pushed the V8 rebased on top of v6.2-tmp/soc.
> https://lore.kernel.org/r/20221005-mt6357-support-v8-0-560caaafee53@baylibre.com
>
> Thanks,
> Alex
^ permalink raw reply
* Re: remove arch/sh
From: Geert Uytterhoeven @ 2023-01-18 7:46 UTC (permalink / raw)
To: Rob Landley
Cc: Christoph Hellwig, John Paul Adrian Glaubitz, Yoshinori Sato,
Rich Felker, Arnd Bergmann, Greg Kroah-Hartman, Laurent Pinchart,
Kieran Bingham, Geert Uytterhoeven, linux-kernel, linux-watchdog,
devicetree, linux-arch, dmaengine, dri-devel, linux-renesas-soc,
linux-i2c, linux-input, linux-media, linux-mmc, linux-mtd, netdev,
linux-gpio, linux-rtc, linux-spi, linux-serial, linux-usb,
linux-fbdev, alsa-devel, linux-sh
In-Reply-To: <7329212f-b1a0-41eb-99b3-a56eb1d23138@landley.net>
Hi Rob,
On Wed, Jan 18, 2023 at 5:50 AM Rob Landley <rob@landley.net> wrote:
> On 1/17/23 14:26, Geert Uytterhoeven wrote:
> > On Tue, Jan 17, 2023 at 8:01 PM Rob Landley <rob@landley.net> wrote:
> >> I'm lazy and mostly test each new sh4 build under qemu -M r2d because it's
> >> really convenient: neither of my physical boards boot from SD card so replacing
> >> the kernel requires reflashing soldered in flash. (They'll net mount userspace
> >> but I haven't gotten either bootloader to net-boot a kernel.)
> >
> > On my landisk (with boots from CompactFLASH), I boot the original 2.6.22
> > kernel, and use kexec to boot-test each and every renesas-drivers
> > release. Note that this requires both the original 2.6.22 kernel
> > and matching kexec-tools.
>
> I make it a point to run _current_ kernels in all my mkroot systems, including
> sh4. What I shipped was 6.1 is:
>
> # cat /proc/version
> Linux version 6.1.0 (landley@driftwood) (sh4-linux-musl-cc (GCC) 9.4.0, GNU ld
> (GNU Binutils) 2.33.1) #1 Tue Jan 10 16:32:07 CST 2023
I think you misunderstood: renesas-drivers releases[1] are current
kernels.
Linux version 6.2.0-rc3-landisk-01864-g0c6453b3e5f6 (geert@rox)
(sh4-linux-gnu-gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0, GNU ld (GNU
Binutils for Ubuntu) 2.38) #125 Tue Jan 10 14:29:01 CET 2023
I use 2.6.22 and kexec as a boot loader for newer kernels, to avoid
juggling CF cards. I cannot install a newer base kernel on the CF,
as kexec is broken upstream.
> > Apparently both upstreamed kernel and
> > kexec-tools support for SH are different, and incompatible with each
> > other, so you cannot kexec from a contemporary kernel.
>
> Sure you can. Using toybox's insmod and modprobe, anyway. (That's the target I
> tested those on... :)
>
> Haven't messed with signing or compression or anything yet, my insmod is just
> doing syscall(SYS_finit_module) and then falling back to SYS_init_module if that
> fails and either fd was 0 or errno was ENOSYS. (Don't ask me why
> SYS_finit_module doesn't work on stdin...)
>
> https://github.com/landley/toybox/blob/master/toys/other/insmod.c#L31
>
> https://landley.net/toybox/downloads/binaries/0.8.9/toybox-sh4
Again, I think you're talking about something different.
Does kexec work for you?
> > I tried working my way up from 2.6.22, but gave up around 2.6.29.
> > Probably I should do this with r2d and qemu instead ;-)
>
> I have current running there. I've had current running there for years. Config
> attached...
>
> > Both r2d and landisk are SH7751.
>
> Cool. Shouldn't be hard to get landisk running current then.
Current kernels work fine on landisk with an old Debian userspace
on CF. The 8139cp driver is a bit flaky: last time I tried nfsroot,
that didn't work well.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: remove arch/sh
From: Rob Landley @ 2023-01-18 5:03 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Christoph Hellwig, John Paul Adrian Glaubitz, Yoshinori Sato,
Rich Felker, Arnd Bergmann, Greg Kroah-Hartman, Laurent Pinchart,
Kieran Bingham, Geert Uytterhoeven, linux-kernel, linux-watchdog,
devicetree, linux-arch, dmaengine, dri-devel, linux-renesas-soc,
linux-i2c, linux-input, linux-media, linux-mmc, linux-mtd, netdev,
linux-gpio, linux-rtc, linux-spi, linux-serial, linux-usb,
linux-fbdev, alsa-devel, linux-sh
In-Reply-To: <CAMuHMdUJm5QvzH8hvqwvn9O6qSbzNOapabjw5nh9DJd0F55Zdg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7466 bytes --]
On 1/17/23 14:26, Geert Uytterhoeven wrote:
> Hi Rob,
>
> On Tue, Jan 17, 2023 at 8:01 PM Rob Landley <rob@landley.net> wrote:
>> On 1/16/23 01:13, Christoph Hellwig wrote:
>> > On Fri, Jan 13, 2023 at 09:09:52AM +0100, John Paul Adrian Glaubitz wrote:
>> >> I'm still maintaining and using this port in Debian.
>> >>
>> >> It's a bit disappointing that people keep hammering on it. It works fine for me.
>> >
>> > What platforms do you (or your users) use it on?
>>
>> 3 j-core boards, two sh4 boards (the sh7760 one I patched the kernel of), and an
>> sh4 emulator.
>>
>> I have multiple j-core systems (sh2 compatible with extensions, nommu, 3
>> different kinds of boards running it here). There's an existing mmu version of
>> j-core that's sh3 flavored but they want to redo it so it hasn't been publicly
>> released yet, I have yet to get that to run Linux because the mmu code would
>> need adapting, but the most recent customer projects were on the existing nommu
>> SOC, as was last year's ASIC work via sky130.
>
> J4 still vaporware?
The 'existing mmu version' is the theoretical basis for J4 (the move from J3 to
J4 is tiny from an instruction set perspective, it was more about internal chip
architecture, primarily multi-issue with tomasulo). It exists, but we haven't
had a product that uses it and the engineer who was tasked to work on it got
reassigned during the pandemic.
The real problem is the existing implementation is a branch off of an older SOC
version so repotting it to the current tree (which among other things builds
under a different VHDL toolchain) is some work. The "conflict requiring actual
staring at" isn't the MMU, it's the instruction cancellation logic that backs
out half-finished instructions when the MMU complains partway through an
instruction that's multiple steps of microcode, so we have to back _out_ what
it's already done so it can be cleanly restarted after handling the fault.
That's got merge conflicts all over the place with the current stuff...
Not actually _hard_, but not something we've sat down and done. We spent those
cycles last year working on an ASIC implementation through Google's Sky130
OpenLane/OpenRoad stuff (see https://github.com/j-core/openlane-vhdl-build for
our in-house toolchain build for that; Google passes around a magic docker that
most people use, we trimmed off most of the dependencies and build it in a clean
debootstrap). And that was trying to make an ASIC out of the small simple
version, because Google's entire asic/skywater partnership was... fraught?
We also tried to get the previous generation of ASIC tools to work before giving
up and trying to get what Google was working on to work:
https://landley.net/notes-2022.html#26-01-2022
https://landley.net/notes-2022.html#28-01-2022
We targeted "known working SOC that we've been using a long time" to try to make
a physical silicon chip out of (and the first version isn't even the J2 2xSMP
SOC with all the cache and peripherals, it was a derivative of the ICE40 port
that's single processor running straight from SRAM with no DRAM controller), on
the theory we can always do a more complicated one later an what we were really
trying to establish here is that Google's ASIC development tools and process
could be made to work. (Which is kind of a heavy lift, they burned two shuttles
full of mostly dead chips that we know of before admitting "those timing
annotations we were talking about actually DO need to go all the way through"...
Jeff has the URLs to the bug reports in OpenLane/Road's github...)
(Sorry, one of OpenLane/OpenRoad is the DARPA project out of Sandia National
Laboratory, and the other is Google doing a large extremely complicated thing
analogous to the AOSP build on top of Darpa's work using a lot different
programming languages and FOREST of build and runtime package dependencies, and
I can never remember which is which. The Google thing is the one distributed in
a docker because it's considered impossible to build rom source by everybody
except us, because we're funny that way. And added VHDL support instead of just
Verilog so needed to rebuild from source anyway to do that.)
>> My physical sh4 boards are a Johnson Controls N40 (sh7760 chipset) and the
>> little blue one is... sh4a I think? (It can run the same userspace, I haven't
>> replaced that board's kernel since I got it, I think it's the type Glaubitz is
>> using? It's mostly in case he had an issue I couldn't reproduce on different
>> hardware, or if I spill something on my N40.)
>>
>> I also have a physical sh2 board on the shelf which I haven't touched in years
>> (used to comparison test during j2 development, and then the j2 boards replaced it).
>>
>> I'm lazy and mostly test each new sh4 build under qemu -M r2d because it's
>> really convenient: neither of my physical boards boot from SD card so replacing
>> the kernel requires reflashing soldered in flash. (They'll net mount userspace
>> but I haven't gotten either bootloader to net-boot a kernel.)
>
> On my landisk (with boots from CompactFLASH), I boot the original 2.6.22
> kernel, and use kexec to boot-test each and every renesas-drivers
> release. Note that this requires both the original 2.6.22 kernel
> and matching kexec-tools.
I make it a point to run _current_ kernels in all my mkroot systems, including
sh4. What I shipped was 6.1 is:
# cat /proc/version
Linux version 6.1.0 (landley@driftwood) (sh4-linux-musl-cc (GCC) 9.4.0, GNU ld
(GNU Binutils) 2.33.1) #1 Tue Jan 10 16:32:07 CST 2023
At the JCI contract where I got the N40 I forward ported the kernel version to a
release that was I think 2 back from the current release because there was a
race condition in the flash support I didn't have time to track down? (Only
showed up under sustained load so the test case took hours to run, and we had a
ship schedule...)
I've been meaning to get together with somebody to get the blue board updated,
but I've been busy with other things...
> Apparently both upstreamed kernel and
> kexec-tools support for SH are different, and incompatible with each
> other, so you cannot kexec from a contemporary kernel.
Sure you can. Using toybox's insmod and modprobe, anyway. (That's the target I
tested those on... :)
Haven't messed with signing or compression or anything yet, my insmod is just
doing syscall(SYS_finit_module) and then falling back to SYS_init_module if that
fails and either fd was 0 or errno was ENOSYS. (Don't ask me why
SYS_finit_module doesn't work on stdin...)
https://github.com/landley/toybox/blob/master/toys/other/insmod.c#L31
https://landley.net/toybox/downloads/binaries/0.8.9/toybox-sh4
> I tried working my way up from 2.6.22, but gave up around 2.6.29.
> Probably I should do this with r2d and qemu instead ;-)
I have current running there. I've had current running there for years. Config
attached...
> Both r2d and landisk are SH7751.
Cool. Shouldn't be hard to get landisk running current then.
> Probably SH7722/'23'24 (e.g. Migo-R and Ecovec boards) are also
> worth keeping. Most on-SoC blocks have drivers with DT support,
> as they are shared with ARM. So the hardest part is clock and
> interrupt-controller support.
J-core is using device tree already. Shouldn't be hard to do a device tree for
the qemu version, and then for landisk.
> Unfortunately I no longer have access to the (remote) Migo-R.
There's more stuff in Japan, but that's a Jeff question...
Rob
[-- Attachment #2: linux-fullconfig.gz --]
[-- Type: application/gzip, Size: 11830 bytes --]
[-- Attachment #3: linux-miniconfig --]
[-- Type: text/plain, Size: 1342 bytes --]
# make ARCH=sh allnoconfig KCONFIG_ALLCONFIG=linux-miniconfig
# make ARCH=sh -j $(nproc)
# boot arch/sh/boot/zImage
# architecture 0
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_SCRIPT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_RD_GZIP=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT2=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_UTF8=y
CONFIG_MISC_FILESYSTEMS=y
CONFIG_SQUASHFS=y
CONFIG_SQUASHFS_XATTR=y
CONFIG_SQUASHFS_ZLIB=y
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IPV6=y
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
CONFIG_NETCONSOLE=y
CONFIG_ETHERNET=y
CONFIG_COMPAT_32BIT_TIME=y
CONFIG_EARLY_PRINTK=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# architecture specific
CONFIG_CPU_SUBTYPE_SH7751R=y
CONFIG_MMU=y
CONFIG_VSYSCALL=y
CONFIG_SH_FPU=y
CONFIG_SH_RTS7751R2D=y
CONFIG_RTS7751R2D_PLUS=y
CONFIG_SERIAL_SH_SCI=y
CONFIG_SERIAL_SH_SCI_CONSOLE=y
CONFIG_PCI=y
CONFIG_NET_VENDOR_REALTEK=y
CONFIG_8139CP=y
CONFIG_PCI=y
CONFIG_BLK_DEV_SD=y
CONFIG_ATA=y
CONFIG_ATA_SFF=y
CONFIG_ATA_BMDMA=y
CONFIG_PATA_PLATFORM=y
CONFIG_BINFMT_ELF_FDPIC=y
CONFIG_BINFMT_FLAT=y
# architecture specific
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_FSCACHE=m
CONFIG_CACHEFILES=m
CONFIG_MEMORY_START=0x0c000000
^ permalink raw reply
* Re: remove arch/sh
From: D. Jeff Dionne @ 2023-01-18 0:10 UTC (permalink / raw)
To: Guenter Roeck
Cc: Geert Uytterhoeven, Rob Landley, Christoph Hellwig,
John Paul Adrian Glaubitz, Yoshinori Sato, Rich Felker,
Arnd Bergmann, Greg Kroah-Hartman, Laurent Pinchart,
Kieran Bingham, Geert Uytterhoeven, linux-kernel, linux-watchdog,
devicetree, linux-arch, dmaengine, dri-devel, linux-renesas-soc,
linux-i2c, linux-input, linux-media, linux-mmc, linux-mtd, netdev,
linux-gpio, linux-rtc, linux-spi, linux-serial, linux-usb,
linux-fbdev, alsa-devel, linux-sh
In-Reply-To: <c9ce648e-e63e-8a47-03c6-7c7e30d8dbc7@roeck-us.net>
> Since there are people around with real hardware .... is sh in big endian mode
> (sheb) real ? Its qemu support is quite limited; most PCI devices don't work
> due to endianness issues. It would be interesting to know if this works better
> with real hardware.
Hi Guenter,
SH big endian works very well, and is in use on J-Core J2 SMP (hardware w/FPGA, simulation and ASIC this year) as well as some of the Hitachi / Renesas IoT chips e.g. SH7619.
It’s the base of the real new line of development (as opposed to backward looking support of older SH chips). New chipsets will be based on the same RTL.
But does it actually work? Yes, we have (new) devices such as a USB Wireguard based VPN hardware dongle, that are J2 (SH2 2 core SMP) that are in use with Linux sheb, nommu and fdpic. MMU chips will be little endian.
Cheers,
J.
> Thanks,
> Guenter
>
^ permalink raw reply
* Re: [PATCH 2/2] HID: hid-steam: Add rumble on Deck
From: Lyude Paul @ 2023-01-17 23:16 UTC (permalink / raw)
To: Vicki Pfau, Jiri Kosina, Benjamin Tissoires, linux-input
In-Reply-To: <20230111012336.2915827-2-vi@endrift.com>
On Tue, 2023-01-10 at 17:23 -0800, Vicki Pfau wrote:
> The Steam Deck includes a new report that allows for emulating XInput-style
> rumble motors with the Deck's actuators. This adds support for passing these
> values directly to the Deck.
>
> Signed-off-by: Vicki Pfau <vi@endrift.com>
> ---
> drivers/hid/Kconfig | 8 ++++++
> drivers/hid/hid-steam.c | 55 +++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 63 insertions(+)
>
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index e2a5d30c8895..e9de0a2d3cd3 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -1025,6 +1025,14 @@ config HID_STEAM
> without running the Steam Client. It supports both the wired and
> the wireless adaptor.
>
> +config STEAM_FF
> + bool "Steam Deck force feedback support"
> + depends on HID_STEAM
> + select INPUT_FF_MEMLESS
> + help
> + Say Y here if you want to enable force feedback support for the Steam
> + Deck.
> +
> config HID_STEELSERIES
> tristate "Steelseries SRW-S1 steering wheel support"
> help
> diff --git a/drivers/hid/hid-steam.c b/drivers/hid/hid-steam.c
> index efd192d6c51a..788b5baaf145 100644
> --- a/drivers/hid/hid-steam.c
> +++ b/drivers/hid/hid-steam.c
> @@ -91,6 +91,7 @@ static LIST_HEAD(steam_devices);
> #define STEAM_CMD_FORCEFEEDBAK 0x8f
> #define STEAM_CMD_REQUEST_COMM_STATUS 0xb4
> #define STEAM_CMD_GET_SERIAL 0xae
> +#define STEAM_CMD_HAPTIC_RUMBLE 0xeb
>
> /* Some useful register ids */
> #define STEAM_REG_LPAD_MODE 0x07
> @@ -134,6 +135,9 @@ struct steam_device {
> u8 battery_charge;
> u16 voltage;
> struct delayed_work heartbeat;
> + struct work_struct rumble_work;
> + u16 rumble_left;
> + u16 rumble_right;
> };
>
> static int steam_recv_report(struct steam_device *steam,
> @@ -290,6 +294,45 @@ static inline int steam_request_conn_status(struct steam_device *steam)
> return steam_send_report_byte(steam, STEAM_CMD_REQUEST_COMM_STATUS);
> }
>
> +static inline int steam_haptic_rumble(struct steam_device *steam,
> + u16 intensity, u16 left_speed, u16 right_speed,
> + u8 left_gain, u8 right_gain)
> +{
> + u8 report[11] = {STEAM_CMD_HAPTIC_RUMBLE, 9};
> +
> + report[3] = intensity & 0xFF;
> + report[4] = intensity >> 8;
> + report[5] = left_speed & 0xFF;
> + report[6] = left_speed >> 8;
> + report[7] = right_speed & 0xFF;
> + report[8] = right_speed >> 8;
> + report[9] = left_gain;
> + report[10] = right_gain;
> +
> + return steam_send_report(steam, report, sizeof(report));
> +}
> +
> +static void steam_haptic_rumble_cb(struct work_struct *work)
> +{
> + struct steam_device *steam = container_of(work, struct steam_device,
> + rumble_work);
> + steam_haptic_rumble(steam, 0, steam->rumble_left,
> + steam->rumble_right, 2, 0);
> +}
> +
> +#ifdef CONFIG_STEAM_FF
> +static int steam_play_effect(struct input_dev *dev, void *data,
> + struct ff_effect *effect)
> +{
> + struct steam_device *steam = input_get_drvdata(dev);
> +
> + steam->rumble_left = effect->u.rumble.strong_magnitude;
> + steam->rumble_right = effect->u.rumble.weak_magnitude;
> +
> + return schedule_work(&steam->rumble_work);
> +}
> +#endif
> +
> static void steam_set_lizard_mode(struct steam_device *steam, bool enable)
> {
> if (enable) {
> @@ -541,6 +584,15 @@ static int steam_input_register(struct steam_device *steam)
> input_abs_set_res(input, ABS_HAT0X, STEAM_PAD_RESOLUTION);
> input_abs_set_res(input, ABS_HAT0Y, STEAM_PAD_RESOLUTION);
>
> +#ifdef CONFIG_STEAM_FF
> + if (steam->quirks & STEAM_QUIRK_DECK) {
> + input_set_capability(input, EV_FF, FF_RUMBLE);
> + ret = input_ff_create_memless(input, NULL, steam_play_effect);
> + if (ret)
> + goto init_ff_fail;
> + }
> +#endif
> +
> ret = input_register_device(input);
> if (ret)
> goto input_register_fail;
> @@ -549,6 +601,7 @@ static int steam_input_register(struct steam_device *steam)
> return 0;
>
> input_register_fail:
> +init_ff_fail:
JFYI, this actually causes a compilation warning with CONFIG_STEAM_FF
disabled:
drivers/hid/hid-steam.c: In function ‘steam_input_register’:
drivers/hid/hid-steam.c:604:1: warning: label ‘init_ff_fail’ defined but not
used [-Wunused-label]
604 | init_ff_fail:
| ^~~~~~~~~~~~
TBH I think we should be fine just reusing the input_register_fail: jump label
for this instead of adding another label.
FWIW as well if you want: you could just drop the Kconfig option for this
entirely, which bentiss may or may not want. It would at least leave a little
less chance for compilation warnings like this, since the more Kconfig options
you have for a module the higher the chance you'll leave a warning by mistake
in some random kernel config.
If you end up deciding to leave the Kconfig in I'd at least update the commit
message to mention explicitly you added it so people notice it even if they
don't look at the diff (e.g. maintainers just merging reviewed patches).
I have no hard opinion either way as long as we fix the compilation warning
:). With the issues mentioned here addressed, this patch is:
Reviewed-by: Lyude Paul <lyude@redhat.com>
> input_free_device(input);
> return ret;
> }
> @@ -842,6 +895,7 @@ static int steam_probe(struct hid_device *hdev,
> INIT_WORK(&steam->work_connect, steam_work_connect_cb);
> INIT_LIST_HEAD(&steam->list);
> INIT_DEFERRABLE_WORK(&steam->heartbeat, steam_lizard_mode_heartbeat);
> + INIT_WORK(&steam->rumble_work, steam_haptic_rumble_cb);
>
> steam->client_hdev = steam_create_client_hid(hdev);
> if (IS_ERR(steam->client_hdev)) {
> @@ -898,6 +952,7 @@ static int steam_probe(struct hid_device *hdev,
> client_hdev_fail:
> cancel_work_sync(&steam->work_connect);
> cancel_delayed_work_sync(&steam->heartbeat);
> + cancel_work_sync(&steam->rumble_work);
> steam_alloc_fail:
> hid_err(hdev, "%s: failed with error %d\n",
> __func__, ret);
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
^ permalink raw reply
* Re: remove arch/sh
From: Guenter Roeck @ 2023-01-17 23:05 UTC (permalink / raw)
To: Geert Uytterhoeven, Rob Landley
Cc: Christoph Hellwig, John Paul Adrian Glaubitz, Yoshinori Sato,
Rich Felker, Arnd Bergmann, Greg Kroah-Hartman, Laurent Pinchart,
Kieran Bingham, Geert Uytterhoeven, linux-kernel, linux-watchdog,
devicetree, linux-arch, dmaengine, dri-devel, linux-renesas-soc,
linux-i2c, linux-input, linux-media, linux-mmc, linux-mtd, netdev,
linux-gpio, linux-rtc, linux-spi, linux-serial, linux-usb,
linux-fbdev, alsa-devel, linux-sh
In-Reply-To: <CAMuHMdUJm5QvzH8hvqwvn9O6qSbzNOapabjw5nh9DJd0F55Zdg@mail.gmail.com>
On 1/17/23 12:26, Geert Uytterhoeven wrote:
> Hi Rob,
>
> On Tue, Jan 17, 2023 at 8:01 PM Rob Landley <rob@landley.net> wrote:
>> On 1/16/23 01:13, Christoph Hellwig wrote:
>>> On Fri, Jan 13, 2023 at 09:09:52AM +0100, John Paul Adrian Glaubitz wrote:
>>>> I'm still maintaining and using this port in Debian.
>>>>
>>>> It's a bit disappointing that people keep hammering on it. It works fine for me.
>>>
>>> What platforms do you (or your users) use it on?
>>
>> 3 j-core boards, two sh4 boards (the sh7760 one I patched the kernel of), and an
>> sh4 emulator.
>>
>> I have multiple j-core systems (sh2 compatible with extensions, nommu, 3
>> different kinds of boards running it here). There's an existing mmu version of
>> j-core that's sh3 flavored but they want to redo it so it hasn't been publicly
>> released yet, I have yet to get that to run Linux because the mmu code would
>> need adapting, but the most recent customer projects were on the existing nommu
>> SOC, as was last year's ASIC work via sky130.
>
> J4 still vaporware?
>
>> My physical sh4 boards are a Johnson Controls N40 (sh7760 chipset) and the
>> little blue one is... sh4a I think? (It can run the same userspace, I haven't
>> replaced that board's kernel since I got it, I think it's the type Glaubitz is
>> using? It's mostly in case he had an issue I couldn't reproduce on different
>> hardware, or if I spill something on my N40.)
>>
>> I also have a physical sh2 board on the shelf which I haven't touched in years
>> (used to comparison test during j2 development, and then the j2 boards replaced it).
>>
>> I'm lazy and mostly test each new sh4 build under qemu -M r2d because it's
>> really convenient: neither of my physical boards boot from SD card so replacing
>> the kernel requires reflashing soldered in flash. (They'll net mount userspace
>> but I haven't gotten either bootloader to net-boot a kernel.)
>
> On my landisk (with boots from CompactFLASH), I boot the original 2.6.22
> kernel, and use kexec to boot-test each and every renesas-drivers
> release. Note that this requires both the original 2.6.22 kernel
> and matching kexec-tools. Apparently both upstreamed kernel and
> kexec-tools support for SH are different, and incompatible with each
> other, so you cannot kexec from a contemporary kernel.
> I tried working my way up from 2.6.22, but gave up around 2.6.29.
> Probably I should do this with r2d and qemu instead ;-)
>
> Both r2d and landisk are SH7751.
>
> Probably SH7722/'23'24 (e.g. Migo-R and Ecovec boards) are also
> worth keeping. Most on-SoC blocks have drivers with DT support,
> as they are shared with ARM. So the hardest part is clock and
> interrupt-controller support.
> Unfortunately I no longer have access to the (remote) Migo-R.
>
Since there are people around with real hardware .... is sh in big endian mode
(sheb) real ? Its qemu support is quite limited; most PCI devices don't work
due to endianness issues. It would be interesting to know if this works better
with real hardware.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH 1/2] HID: hid-steam: Add Steam Deck support
From: Lyude Paul @ 2023-01-17 22:58 UTC (permalink / raw)
To: Vicki Pfau, Jiri Kosina, Benjamin Tissoires, linux-input
In-Reply-To: <20230111012336.2915827-1-vi@endrift.com>
Honestly this looks mostly fine! There's at least one thing we probably want
to fix: now that this driver supports both the steam controller and steam
deck, we should rename the config option from:
"Steam controller support" to
"Steam controller/Deck support"
Or something along those lines, along with updating the config description. I
mainly just mention this since otherwise, you actually can't tell that this
enables the steam deck from menuconfig unless you set the option to M or Y
first. A couple of bikesheds below:
On Tue, 2023-01-10 at 17:23 -0800, Vicki Pfau wrote:
> Add preliminary support for the Steam Deck's controller interface. Currently,
> this only supports the controller inputs and toggling lizard mode. It does not
> support any of the advanced features, such as the motion sensors or
> force-feedback.
>
> The Steam Deck also includes a heartbeat for lizard mode that switches it back
> on if no reports have been received within a few milliseconds. The official
> Steam client handles this by sending a handful of configuration reports every
> few ms, so we copy this behavior by sending configuration reports to disable
> the mouse and reset the digital mappings every 5ms. As this isn't needed for
> the older Steam Controller, this is only done on the Steam Deck.
>
> Signed-off-by: Vicki Pfau <vi@endrift.com>
> ---
> drivers/hid/hid-ids.h | 1 +
> drivers/hid/hid-steam.c | 335 ++++++++++++++++++++++++++++++++++++----
> 2 files changed, 306 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 82713ef3aaa6..33269113acc7 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -1183,6 +1183,7 @@
> #define USB_VENDOR_ID_VALVE 0x28de
> #define USB_DEVICE_ID_STEAM_CONTROLLER 0x1102
> #define USB_DEVICE_ID_STEAM_CONTROLLER_WIRELESS 0x1142
> +#define USB_DEVICE_ID_STEAM_DECK 0x1205
>
> #define USB_VENDOR_ID_STEELSERIES 0x1038
> #define USB_DEVICE_ID_STEELSERIES_SRWS1 0x1410
> diff --git a/drivers/hid/hid-steam.c b/drivers/hid/hid-steam.c
> index 8ee43cb225fc..efd192d6c51a 100644
> --- a/drivers/hid/hid-steam.c
> +++ b/drivers/hid/hid-steam.c
> @@ -3,6 +3,7 @@
> * HID driver for Valve Steam Controller
> *
> * Copyright (c) 2018 Rodrigo Rivas Costa <rodrigorivascosta@gmail.com>
> + * Copyright (c) 2022 Valve Software
> *
> * Supports both the wired and wireless interfaces.
> *
> @@ -53,6 +54,7 @@ static DEFINE_MUTEX(steam_devices_lock);
> static LIST_HEAD(steam_devices);
>
> #define STEAM_QUIRK_WIRELESS BIT(0)
> +#define STEAM_QUIRK_DECK BIT(1)
>
> /* Touch pads are 40 mm in diameter and 65535 units */
> #define STEAM_PAD_RESOLUTION 1638
> @@ -60,6 +62,10 @@ static LIST_HEAD(steam_devices);
> #define STEAM_TRIGGER_RESOLUTION 51
> /* Joystick runs are about 5 mm and 256 units */
> #define STEAM_JOYSTICK_RESOLUTION 51
> +/* Trigger runs are about 6 mm and 32768 units */
> +#define STEAM_DECK_TRIGGER_RESOLUTION 5461
> +/* Joystick runs are about 5 mm and 32768 units */
> +#define STEAM_DECK_JOYSTICK_RESOLUTION 6553
>
> #define STEAM_PAD_FUZZ 256
>
> @@ -92,11 +98,14 @@ static LIST_HEAD(steam_devices);
> #define STEAM_REG_RPAD_MARGIN 0x18
> #define STEAM_REG_LED 0x2d
> #define STEAM_REG_GYRO_MODE 0x30
> +#define STEAM_REG_LPAD_CLICK_PRESSURE 0x34
> +#define STEAM_REG_RPAD_CLICK_PRESSURE 0x35
>
> /* Raw event identifiers */
> #define STEAM_EV_INPUT_DATA 0x01
> #define STEAM_EV_CONNECT 0x03
> #define STEAM_EV_BATTERY 0x04
> +#define STEAM_EV_DECK_INPUT_DATA 0x09
>
> /* Values for GYRO_MODE (bitmask) */
> #define STEAM_GYRO_MODE_OFF 0x0000
> @@ -124,6 +133,7 @@ struct steam_device {
> struct power_supply __rcu *battery;
> u8 battery_charge;
> u16 voltage;
> + struct delayed_work heartbeat;
> };
>
> static int steam_recv_report(struct steam_device *steam,
> @@ -193,7 +203,7 @@ static int steam_send_report(struct steam_device *steam,
> */
> do {
> ret = hid_hw_raw_request(steam->hdev, 0,
> - buf, size + 1,
> + buf, max(size, 64) + 1,
> HID_FEATURE_REPORT, HID_REQ_SET_REPORT);
> if (ret != -EPIPE)
> break;
> @@ -219,6 +229,7 @@ static int steam_write_registers(struct steam_device *steam,
> u8 reg;
> u16 val;
> u8 cmd[64] = {STEAM_CMD_WRITE_REGISTER, 0x00};
> + int ret;
> va_list args;
>
> va_start(args, steam);
> @@ -234,7 +245,16 @@ static int steam_write_registers(struct steam_device *steam,
> }
> va_end(args);
>
> - return steam_send_report(steam, cmd, 2 + cmd[1]);
> + ret = steam_send_report(steam, cmd, 2 + cmd[1]);
> + if (ret < 0)
> + return ret;
> +
> + /*
> + * Sometimes a lingering report for this command can
> + * get read back instead of the last set report if
> + * this isn't explicitly queried
> + */
> + return steam_recv_report(steam, cmd, 2 + cmd[1]);
> }
>
> static int steam_get_serial(struct steam_device *steam)
> @@ -280,13 +300,32 @@ static void steam_set_lizard_mode(struct steam_device *steam, bool enable)
> steam_write_registers(steam,
> STEAM_REG_RPAD_MARGIN, 0x01, /* enable margin */
> 0);
> +
> + cancel_delayed_work_sync(&steam->heartbeat);
> } else {
> /* disable esc, enter, cursor */
> steam_send_report_byte(steam, STEAM_CMD_CLEAR_MAPPINGS);
> - steam_write_registers(steam,
> - STEAM_REG_RPAD_MODE, 0x07, /* disable mouse */
> - STEAM_REG_RPAD_MARGIN, 0x00, /* disable margin */
> - 0);
> +
> + if (steam->quirks & STEAM_QUIRK_DECK) {
> + steam_write_registers(steam,
> + STEAM_REG_RPAD_MARGIN, 0x00, /* disable margin */
> + STEAM_REG_LPAD_MODE, 0x07, /* disable mouse */
> + STEAM_REG_RPAD_MODE, 0x07, /* disable mouse */
> + STEAM_REG_LPAD_CLICK_PRESSURE, 0xFFFF, /* disable clicky pad */
> + STEAM_REG_RPAD_CLICK_PRESSURE, 0xFFFF, /* disable clicky pad */
> + 0);
> + /*
> + * The Steam Deck has a watchdog that automatically enables
> + * lizard mode if it doesn't see any traffic for too long
> + */
> + schedule_delayed_work(&steam->heartbeat, 5 * HZ);
> + } else {
> + steam_write_registers(steam,
> + STEAM_REG_RPAD_MARGIN, 0x00, /* disable margin */
> + STEAM_REG_LPAD_MODE, 0x07, /* disable mouse */
> + STEAM_REG_RPAD_MODE, 0x07, /* disable mouse */
> + 0);
> + }
> }
> }
>
> @@ -413,8 +452,8 @@ static int steam_input_register(struct steam_device *steam)
> input->open = steam_input_open;
> input->close = steam_input_close;
>
> - input->name = (steam->quirks & STEAM_QUIRK_WIRELESS) ?
> - "Wireless Steam Controller" :
> + input->name = (steam->quirks & STEAM_QUIRK_WIRELESS) ? "Wireless Steam Controller" :
> + (steam->quirks & STEAM_QUIRK_DECK) ? "Steam Deck" :
> "Steam Controller";
> input->phys = hdev->phys;
> input->uniq = steam->serial_no;
> @@ -438,33 +477,69 @@ static int steam_input_register(struct steam_device *steam)
> input_set_capability(input, EV_KEY, BTN_SELECT);
> input_set_capability(input, EV_KEY, BTN_MODE);
> input_set_capability(input, EV_KEY, BTN_START);
> - input_set_capability(input, EV_KEY, BTN_GEAR_DOWN);
> - input_set_capability(input, EV_KEY, BTN_GEAR_UP);
> input_set_capability(input, EV_KEY, BTN_THUMBR);
> input_set_capability(input, EV_KEY, BTN_THUMBL);
> input_set_capability(input, EV_KEY, BTN_THUMB);
> input_set_capability(input, EV_KEY, BTN_THUMB2);
> + if (steam->quirks & STEAM_QUIRK_DECK) {
> + input_set_capability(input, EV_KEY, BTN_BASE);
> + input_set_capability(input, EV_KEY, BTN_TRIGGER_HAPPY1);
> + input_set_capability(input, EV_KEY, BTN_TRIGGER_HAPPY2);
> + input_set_capability(input, EV_KEY, BTN_TRIGGER_HAPPY3);
> + input_set_capability(input, EV_KEY, BTN_TRIGGER_HAPPY4);
> + } else {
> + input_set_capability(input, EV_KEY, BTN_GEAR_DOWN);
> + input_set_capability(input, EV_KEY, BTN_GEAR_UP);
> + }
>
> - input_set_abs_params(input, ABS_HAT2Y, 0, 255, 0, 0);
> - input_set_abs_params(input, ABS_HAT2X, 0, 255, 0, 0);
> input_set_abs_params(input, ABS_X, -32767, 32767, 0, 0);
> input_set_abs_params(input, ABS_Y, -32767, 32767, 0, 0);
> - input_set_abs_params(input, ABS_RX, -32767, 32767,
> - STEAM_PAD_FUZZ, 0);
> - input_set_abs_params(input, ABS_RY, -32767, 32767,
> - STEAM_PAD_FUZZ, 0);
> - input_set_abs_params(input, ABS_HAT0X, -32767, 32767,
> - STEAM_PAD_FUZZ, 0);
> - input_set_abs_params(input, ABS_HAT0Y, -32767, 32767,
> - STEAM_PAD_FUZZ, 0);
> - input_abs_set_res(input, ABS_X, STEAM_JOYSTICK_RESOLUTION);
> - input_abs_set_res(input, ABS_Y, STEAM_JOYSTICK_RESOLUTION);
> - input_abs_set_res(input, ABS_RX, STEAM_PAD_RESOLUTION);
> - input_abs_set_res(input, ABS_RY, STEAM_PAD_RESOLUTION);
> + if (steam->quirks & STEAM_QUIRK_DECK) {
> + input_set_abs_params(input, ABS_HAT2Y, 0, 32767, 0, 0);
> + input_set_abs_params(input, ABS_HAT2X, 0, 32767, 0, 0);
> +
> + input_set_abs_params(input, ABS_RX, -32767, 32767, 0, 0);
> + input_set_abs_params(input, ABS_RY, -32767, 32767, 0, 0);
> +
> + input_set_abs_params(input, ABS_HAT0X, -32767, 32767,
> + STEAM_PAD_FUZZ, 0);
> + input_set_abs_params(input, ABS_HAT0Y, -32767, 32767,
> + STEAM_PAD_FUZZ, 0);
> + input_set_abs_params(input, ABS_HAT1X, -32767, 32767,
> + STEAM_PAD_FUZZ, 0);
> + input_set_abs_params(input, ABS_HAT1Y, -32767, 32767,
> + STEAM_PAD_FUZZ, 0);
> +
> + input_abs_set_res(input, ABS_X, STEAM_DECK_JOYSTICK_RESOLUTION);
> + input_abs_set_res(input, ABS_Y, STEAM_DECK_JOYSTICK_RESOLUTION);
> + input_abs_set_res(input, ABS_RX, STEAM_DECK_JOYSTICK_RESOLUTION);
> + input_abs_set_res(input, ABS_RY, STEAM_DECK_JOYSTICK_RESOLUTION);
> + input_abs_set_res(input, ABS_HAT1X, STEAM_PAD_RESOLUTION);
> + input_abs_set_res(input, ABS_HAT1Y, STEAM_PAD_RESOLUTION);
> + input_abs_set_res(input, ABS_HAT2Y, STEAM_DECK_TRIGGER_RESOLUTION);
> + input_abs_set_res(input, ABS_HAT2X, STEAM_DECK_TRIGGER_RESOLUTION);
> + } else {
> + input_set_abs_params(input, ABS_HAT2Y, 0, 255, 0, 0);
> + input_set_abs_params(input, ABS_HAT2X, 0, 255, 0, 0);
> +
> + input_set_abs_params(input, ABS_RX, -32767, 32767,
> + STEAM_PAD_FUZZ, 0);
> + input_set_abs_params(input, ABS_RY, -32767, 32767,
> + STEAM_PAD_FUZZ, 0);
> + input_set_abs_params(input, ABS_HAT0X, -32767, 32767,
> + STEAM_PAD_FUZZ, 0);
> + input_set_abs_params(input, ABS_HAT0Y, -32767, 32767,
> + STEAM_PAD_FUZZ, 0);
Any reason we don't keep the abs_params for ABS_HAT0X/ABS_HAT0Y above the if?
seems like they're identical between the controller and steam deck. Feel free
to leave it be if you think it's clearer to read like this though.
> +
> + input_abs_set_res(input, ABS_X, STEAM_JOYSTICK_RESOLUTION);
> + input_abs_set_res(input, ABS_Y, STEAM_JOYSTICK_RESOLUTION);
> + input_abs_set_res(input, ABS_RX, STEAM_PAD_RESOLUTION);
> + input_abs_set_res(input, ABS_RY, STEAM_PAD_RESOLUTION);
> + input_abs_set_res(input, ABS_HAT2Y, STEAM_TRIGGER_RESOLUTION);
> + input_abs_set_res(input, ABS_HAT2X, STEAM_TRIGGER_RESOLUTION);
> + }
> input_abs_set_res(input, ABS_HAT0X, STEAM_PAD_RESOLUTION);
> input_abs_set_res(input, ABS_HAT0Y, STEAM_PAD_RESOLUTION);
> - input_abs_set_res(input, ABS_HAT2Y, STEAM_TRIGGER_RESOLUTION);
> - input_abs_set_res(input, ABS_HAT2X, STEAM_TRIGGER_RESOLUTION);
>
> ret = input_register_device(input);
> if (ret)
> @@ -612,6 +687,22 @@ static bool steam_is_valve_interface(struct hid_device *hdev)
> return !list_empty(&rep_enum->report_list);
> }
>
> +static void steam_lizard_mode_heartbeat(struct work_struct *work)
> +{
> + struct steam_device *steam = container_of(work, struct steam_device,
> + heartbeat.work);
I'd probably align the start of heartbeat.work to start at the column
immediately after container_of() so it looks like this:
container_of(work, struct steam_device,
heartbeat.work)
That's basically it for this patch though, everything else looks fine to me
:). With the indenting issue fixed and kernel config description clarified
this is:
Reviewed-by: Lyude Paul <lyude@redhat.com>
> +
> + mutex_lock(&steam->mutex);
> + if (!steam->client_opened) {
> + steam_send_report_byte(steam, STEAM_CMD_CLEAR_MAPPINGS);
> + steam_write_registers(steam,
> + STEAM_REG_RPAD_MODE, 0x07, /* disable mouse */
> + 0);
> + schedule_delayed_work(&steam->heartbeat, 5 * HZ);
> + }
> + mutex_unlock(&steam->mutex);
> +}
> +
> static int steam_client_ll_parse(struct hid_device *hdev)
> {
> struct steam_device *steam = hdev->driver_data;
> @@ -750,6 +841,7 @@ static int steam_probe(struct hid_device *hdev,
> steam->quirks = id->driver_data;
> INIT_WORK(&steam->work_connect, steam_work_connect_cb);
> INIT_LIST_HEAD(&steam->list);
> + INIT_DEFERRABLE_WORK(&steam->heartbeat, steam_lizard_mode_heartbeat);
>
> steam->client_hdev = steam_create_client_hid(hdev);
> if (IS_ERR(steam->client_hdev)) {
> @@ -805,6 +897,7 @@ static int steam_probe(struct hid_device *hdev,
> hid_destroy_device(steam->client_hdev);
> client_hdev_fail:
> cancel_work_sync(&steam->work_connect);
> + cancel_delayed_work_sync(&steam->heartbeat);
> steam_alloc_fail:
> hid_err(hdev, "%s: failed with error %d\n",
> __func__, ret);
> @@ -823,6 +916,7 @@ static void steam_remove(struct hid_device *hdev)
> hid_destroy_device(steam->client_hdev);
> steam->client_opened = false;
> cancel_work_sync(&steam->work_connect);
> + cancel_delayed_work_sync(&steam->heartbeat);
> if (steam->quirks & STEAM_QUIRK_WIRELESS) {
> hid_info(hdev, "Steam wireless receiver disconnected");
> }
> @@ -906,10 +1000,10 @@ static inline s16 steam_le16(u8 *data)
> * 8.5 | BTN_B | button B
> * 8.6 | BTN_X | button X
> * 8.7 | BTN_A | button A
> - * 9.0 | BTN_DPAD_UP | lef-pad up
> - * 9.1 | BTN_DPAD_RIGHT | lef-pad right
> - * 9.2 | BTN_DPAD_LEFT | lef-pad left
> - * 9.3 | BTN_DPAD_DOWN | lef-pad down
> + * 9.0 | BTN_DPAD_UP | left-pad up
> + * 9.1 | BTN_DPAD_RIGHT | left-pad right
> + * 9.2 | BTN_DPAD_LEFT | left-pad left
> + * 9.3 | BTN_DPAD_DOWN | left-pad down
> * 9.4 | BTN_SELECT | menu left
> * 9.5 | BTN_MODE | steam logo
> * 9.6 | BTN_START | menu right
> @@ -993,6 +1087,172 @@ static void steam_do_input_event(struct steam_device *steam,
> input_sync(input);
> }
>
> +/*
> + * The size for this message payload is 56.
> + * The known values are:
> + * Offset| Type | Mapped to |Meaning
> + * -------+-------+-----------+--------------------------
> + * 4-7 | u32 | -- | sequence number
> + * 8-15 | u64 | see below | buttons
> + * 16-17 | s16 | ABS_HAT0X | left-pad X value
> + * 18-19 | s16 | ABS_HAT0Y | left-pad Y value
> + * 20-21 | s16 | ABS_HAT1X | right-pad X value
> + * 22-23 | s16 | ABS_HAT1Y | right-pad Y value
> + * 24-25 | s16 | -- | accelerometer X value
> + * 26-27 | s16 | -- | accelerometer Y value
> + * 28-29 | s16 | -- | accelerometer Z value
> + * 30-31 | s16 | -- | gyro X value
> + * 32-33 | s16 | -- | gyro Y value
> + * 34-35 | s16 | -- | gyro Z value
> + * 36-37 | s16 | -- | quaternion W value
> + * 38-39 | s16 | -- | quaternion X value
> + * 40-41 | s16 | -- | quaternion Y value
> + * 42-43 | s16 | -- | quaternion Z value
> + * 44-45 | u16 | ABS_HAT2Y | left trigger (uncalibrated)
> + * 46-47 | u16 | ABS_HAT2X | right trigger (uncalibrated)
> + * 48-49 | s16 | ABS_X | left joystick X
> + * 50-51 | s16 | ABS_Y | left joystick Y
> + * 52-53 | s16 | ABS_RX | right joystick X
> + * 54-55 | s16 | ABS_RY | right joystick Y
> + * 56-57 | u16 | -- | left pad pressure
> + * 58-59 | u16 | -- | right pad pressure
> + *
> + * The buttons are:
> + * Bit | Mapped to | Description
> + * ------+------------+--------------------------------
> + * 8.0 | BTN_TR2 | right trigger fully pressed
> + * 8.1 | BTN_TL2 | left trigger fully pressed
> + * 8.2 | BTN_TR | right shoulder
> + * 8.3 | BTN_TL | left shoulder
> + * 8.4 | BTN_Y | button Y
> + * 8.5 | BTN_B | button B
> + * 8.6 | BTN_X | button X
> + * 8.7 | BTN_A | button A
> + * 9.0 | BTN_DPAD_UP | left-pad up
> + * 9.1 | BTN_DPAD_RIGHT | left-pad right
> + * 9.2 | BTN_DPAD_LEFT | left-pad left
> + * 9.3 | BTN_DPAD_DOWN | left-pad down
> + * 9.4 | BTN_SELECT | menu left
> + * 9.5 | BTN_MODE | steam logo
> + * 9.6 | BTN_START | menu right
> + * 9.7 | BTN_TRIGGER_HAPPY3 | left bottom grip button
> + * 10.0 | BTN_TRIGGER_HAPPY4 | right bottom grip button
> + * 10.1 | BTN_THUMB | left pad pressed
> + * 10.2 | BTN_THUMB2 | right pad pressed
> + * 10.3 | -- | left pad touched
> + * 10.4 | -- | right pad touched
> + * 10.5 | -- | unknown
> + * 10.6 | BTN_THUMBL | left joystick clicked
> + * 10.7 | -- | unknown
> + * 11.0 | -- | unknown
> + * 11.1 | -- | unknown
> + * 11.2 | BTN_THUMBR | right joystick clicked
> + * 11.3 | -- | unknown
> + * 11.4 | -- | unknown
> + * 11.5 | -- | unknown
> + * 11.6 | -- | unknown
> + * 11.7 | -- | unknown
> + * 12.0 | -- | unknown
> + * 12.1 | -- | unknown
> + * 12.2 | -- | unknown
> + * 12.3 | -- | unknown
> + * 12.4 | -- | unknown
> + * 12.5 | -- | unknown
> + * 12.6 | -- | unknown
> + * 12.7 | -- | unknown
> + * 13.0 | -- | unknown
> + * 13.1 | BTN_TRIGGER_HAPPY1 | left top grip button
> + * 13.2 | BTN_TRIGGER_HAPPY2 | right top grip button
> + * 13.3 | -- | unknown
> + * 13.4 | -- | unknown
> + * 13.5 | -- | unknown
> + * 13.6 | -- | left joystick touched
> + * 13.7 | -- | right joystick touched
> + * 14.0 | -- | unknown
> + * 14.1 | -- | unknown
> + * 14.2 | BTN_BASE | quick access button
> + * 14.3 | -- | unknown
> + * 14.4 | -- | unknown
> + * 14.5 | -- | unknown
> + * 14.6 | -- | unknown
> + * 14.7 | -- | unknown
> + * 15.0 | -- | unknown
> + * 15.1 | -- | unknown
> + * 15.2 | -- | unknown
> + * 15.3 | -- | unknown
> + * 15.4 | -- | unknown
> + * 15.5 | -- | unknown
> + * 15.6 | -- | unknown
> + * 15.7 | -- | unknown
> + */
> +static void steam_do_deck_input_event(struct steam_device *steam,
> + struct input_dev *input, u8 *data)
> +{
> + u8 b8, b9, b10, b11, b13, b14;
> + bool lpad_touched, rpad_touched;
> +
> + b8 = data[8];
> + b9 = data[9];
> + b10 = data[10];
> + b11 = data[11];
> + b13 = data[13];
> + b14 = data[14];
> +
> + lpad_touched = b10 & BIT(3);
> + rpad_touched = b10 & BIT(4);
> +
> + if (lpad_touched) {
> + input_report_abs(input, ABS_HAT0X, steam_le16(data + 16));
> + input_report_abs(input, ABS_HAT0Y, steam_le16(data + 18));
> + } else {
> + input_report_abs(input, ABS_HAT0X, 0);
> + input_report_abs(input, ABS_HAT0Y, 0);
> + }
> +
> + if (rpad_touched) {
> + input_report_abs(input, ABS_HAT1X, steam_le16(data + 20));
> + input_report_abs(input, ABS_HAT1Y, steam_le16(data + 22));
> + } else {
> + input_report_abs(input, ABS_HAT1X, 0);
> + input_report_abs(input, ABS_HAT1Y, 0);
> + }
> +
> + input_report_abs(input, ABS_X, steam_le16(data + 48));
> + input_report_abs(input, ABS_Y, -steam_le16(data + 50));
> + input_report_abs(input, ABS_RX, steam_le16(data + 52));
> + input_report_abs(input, ABS_RY, -steam_le16(data + 54));
> +
> + input_report_abs(input, ABS_HAT2Y, steam_le16(data + 44));
> + input_report_abs(input, ABS_HAT2X, steam_le16(data + 46));
> +
> + input_event(input, EV_KEY, BTN_TR2, !!(b8 & BIT(0)));
> + input_event(input, EV_KEY, BTN_TL2, !!(b8 & BIT(1)));
> + input_event(input, EV_KEY, BTN_TR, !!(b8 & BIT(2)));
> + input_event(input, EV_KEY, BTN_TL, !!(b8 & BIT(3)));
> + input_event(input, EV_KEY, BTN_Y, !!(b8 & BIT(4)));
> + input_event(input, EV_KEY, BTN_B, !!(b8 & BIT(5)));
> + input_event(input, EV_KEY, BTN_X, !!(b8 & BIT(6)));
> + input_event(input, EV_KEY, BTN_A, !!(b8 & BIT(7)));
> + input_event(input, EV_KEY, BTN_SELECT, !!(b9 & BIT(4)));
> + input_event(input, EV_KEY, BTN_MODE, !!(b9 & BIT(5)));
> + input_event(input, EV_KEY, BTN_START, !!(b9 & BIT(6)));
> + input_event(input, EV_KEY, BTN_TRIGGER_HAPPY3, !!(b9 & BIT(7)));
> + input_event(input, EV_KEY, BTN_TRIGGER_HAPPY4, !!(b10 & BIT(0)));
> + input_event(input, EV_KEY, BTN_THUMBL, !!(b10 & BIT(6)));
> + input_event(input, EV_KEY, BTN_THUMBR, !!(b11 & BIT(2)));
> + input_event(input, EV_KEY, BTN_DPAD_UP, !!(b9 & BIT(0)));
> + input_event(input, EV_KEY, BTN_DPAD_RIGHT, !!(b9 & BIT(1)));
> + input_event(input, EV_KEY, BTN_DPAD_LEFT, !!(b9 & BIT(2)));
> + input_event(input, EV_KEY, BTN_DPAD_DOWN, !!(b9 & BIT(3)));
> + input_event(input, EV_KEY, BTN_THUMB, !!(b10 & BIT(1)));
> + input_event(input, EV_KEY, BTN_THUMB2, !!(b10 & BIT(2)));
> + input_event(input, EV_KEY, BTN_TRIGGER_HAPPY1, !!(b13 & BIT(1)));
> + input_event(input, EV_KEY, BTN_TRIGGER_HAPPY2, !!(b13 & BIT(2)));
> + input_event(input, EV_KEY, BTN_BASE, !!(b14 & BIT(2)));
> +
> + input_sync(input);
> +}
> +
> /*
> * The size for this message payload is 11.
> * The known values are:
> @@ -1052,6 +1312,7 @@ static int steam_raw_event(struct hid_device *hdev,
> * 0x01: input data (60 bytes)
> * 0x03: wireless connect/disconnect (1 byte)
> * 0x04: battery status (11 bytes)
> + * 0x09: Steam Deck input data (56 bytes)
> */
>
> if (size != 64 || data[0] != 1 || data[1] != 0)
> @@ -1067,6 +1328,15 @@ static int steam_raw_event(struct hid_device *hdev,
> steam_do_input_event(steam, input, data);
> rcu_read_unlock();
> break;
> + case STEAM_EV_DECK_INPUT_DATA:
> + if (steam->client_opened)
> + return 0;
> + rcu_read_lock();
> + input = rcu_dereference(steam->input);
> + if (likely(input))
> + steam_do_deck_input_event(steam, input, data);
> + rcu_read_unlock();
> + break;
> case STEAM_EV_CONNECT:
> /*
> * The payload of this event is a single byte:
> @@ -1141,6 +1411,11 @@ static const struct hid_device_id steam_controllers[] = {
> USB_DEVICE_ID_STEAM_CONTROLLER_WIRELESS),
> .driver_data = STEAM_QUIRK_WIRELESS
> },
> + { /* Steam Deck */
> + HID_USB_DEVICE(USB_VENDOR_ID_VALVE,
> + USB_DEVICE_ID_STEAM_DECK),
> + .driver_data = STEAM_QUIRK_DECK
> + },
> {}
> };
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
^ permalink raw reply
* Re: [PATCH 05/22] sound: remove sh-specific sounds/soc/sh drivers
From: Kuninori Morimoto @ 2023-01-17 22:52 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Yoshinori Sato, Rich Felker, Arnd Bergmann, Greg Kroah-Hartman,
Laurent Pinchart, Kieran Bingham, Geert Uytterhoeven,
linux-kernel, linux-watchdog, devicetree, linux-arch, dmaengine,
dri-devel, linux-renesas-soc, linux-i2c, linux-input, linux-media,
linux-mmc, linux-mtd, netdev, linux-gpio, linux-rtc, linux-spi,
linux-serial, linux-usb, linux-fbdev, alsa-devel, linux-sh
In-Reply-To: <20230113062339.1909087-6-hch@lst.de>
Hi Christoph
>
> Now that arch/sh is removed these drivers are dead code.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
(snip)
> sound/soc/sh/fsi.c | 9 -
(snip)
> config SND_SOC_SH4_FSI
> tristate "SH4 FSI support"
> depends on COMMON_CLK
You can remove sound/soc/sh/fsi.c
It is for SH SoC.
Thank you for your help !!
Best regards
---
Kuninori Morimoto
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox