* Re: [PATCH 01/22] gpu/drm: remove the shmobile drm driver
From: Christoph Hellwig @ 2023-02-03 7:15 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Christoph Hellwig, Yoshinori Sato, Rich Felker, Arnd Bergmann,
Greg Kroah-Hartman, 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: <Y8EMZ0GI5rtor9xr@pendragon.ideasonboard.com>
So given that the big series doesn't go in, can we get this removal
picked up through the drm tree?
^ permalink raw reply
* Re: remove arch/sh
From: Christoph Hellwig @ 2023-02-03 7:14 UTC (permalink / raw)
To: John Paul Adrian Glaubitz
Cc: Christoph Hellwig, 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: <40dc1bc1-d9cd-d9be-188e-5167ebae235c@physik.fu-berlin.de>
On Mon, Jan 16, 2023 at 09:52:10AM +0100, John Paul Adrian Glaubitz wrote:
> We have had a discussion between multiple people invested in the SuperH port and
> I have decided to volunteer as a co-maintainer of the port to support Rich Felker
> when he isn't available.
So, this still isn't reflected in MAINTAINERS in linux-next. When
do you plan to take over? What platforms will remain supported and
what can we start dropping due to being unused and unmaintained?
^ permalink raw reply
* Re: [PATCH] HID: amd_sfh: if no sensors are enabled, clean up
From: Basavaraj Natikar @ 2023-02-03 7:14 UTC (permalink / raw)
To: Mario Limonciello, Basavaraj Natikar, Jiri Kosina
Cc: Xaver Hugl, Jiri Kosina, Benjamin Tissoires, linux-input,
linux-kernel
In-Reply-To: <20230112190131.24460-1-mario.limonciello@amd.com>
On 1/13/2023 12:31 AM, Mario Limonciello wrote:
> It was reported that commit b300667b33b2 ("HID: amd_sfh: Disable the
> interrupt for all command") had caused increased resume time on HP Envy
> x360.
>
> Before this commit 3 sensors were reported, but they were not actually
> functional. After this commit the sensors are no longer reported, but
> also the resume time increased.
>
> To avoid this problem explicitly look for the number of disabled sensors.
> If all the sensors are disabled, clean everything up.
>
> Fixes: b300667b33b2 ("HID: amd_sfh: Disable the interrupt for all command")
> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2115
> Reported-by: Xaver Hugl <xaver.hugl@gmail.com>
> Tested-by: Xaver Hugl <xaver.hugl@gmail.com>
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> ---
> drivers/hid/amd-sfh-hid/amd_sfh_client.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_client.c b/drivers/hid/amd-sfh-hid/amd_sfh_client.c
> index ab125f79408f2..7469691b4a633 100644
> --- a/drivers/hid/amd-sfh-hid/amd_sfh_client.c
> +++ b/drivers/hid/amd-sfh-hid/amd_sfh_client.c
> @@ -227,6 +227,7 @@ int amd_sfh_hid_client_init(struct amd_mp2_dev *privdata)
> cl_data->num_hid_devices = amd_mp2_get_sensor_num(privdata, &cl_data->sensor_idx[0]);
> if (cl_data->num_hid_devices == 0)
> return -ENODEV;
> + cl_data->hid_dev_count = cl_data->num_hid_devices;
to manage more effectively. we can remove above statement by
declaring bool is_any_sensors_enabled = false; in declaration block or in
cl_data
>
> INIT_DELAYED_WORK(&cl_data->work, amd_sfh_work);
> INIT_DELAYED_WORK(&cl_data->work_buffer, amd_sfh_work_buffer);
> @@ -301,12 +302,18 @@ int amd_sfh_hid_client_init(struct amd_mp2_dev *privdata)
> cl_data->sensor_sts[i]);
> goto cleanup;
> }
we can add else or just beginning of this block as
is_any_sensors_enabled = true;
> + } else {
> + mp2_ops->stop(privdata, cl_data->sensor_idx[i]);
> + status = amd_sfh_wait_for_response
> + (privdata, cl_data->sensor_idx[i], SENSOR_DISABLED);
slightly more checks even not required but good to have to make sure in right path
i.e. return status is not used so can we make it like below
if (status != SENSOR_ENABLED) {
cl_data->sensor_sts[i] = SENSOR_DISABLED;
dev_dbg(dev, "sid 0x%x (%s) status 0x%x\n",cl_data->sensor_idx[i],
get_sensor_name(cl_data->sensor_idx[i]),
cl_data->sensor_sts[i]);
}
> + cl_data->hid_dev_count--;
not needed we can use is_any_sensors_enabled
> }
> dev_dbg(dev, "sid 0x%x (%s) status 0x%x\n",
> cl_data->sensor_idx[i], get_sensor_name(cl_data->sensor_idx[i]),
> cl_data->sensor_sts[i]);
> }
> - if (mp2_ops->discovery_status && mp2_ops->discovery_status(privdata) == 0) {
> + if (!cl_data->hid_dev_count ||
can be changed if (is_any_sensors_enabled == false ||
> + (mp2_ops->discovery_status && mp2_ops->discovery_status(privdata) == 0)) {
> amd_sfh_hid_client_deinit(privdata);
> for (i = 0; i < cl_data->num_hid_devices; i++) {
>
>
more debug information like
dev_warn(dev, "Failed to discover, sensors not enabled is_any_sensors_enabled %d\n", is_any_sensors_enabled
);
^ permalink raw reply
* Re: [PATCH] HID: multitouch: Fix typo in config check
From: kernel test robot @ 2023-02-03 6:52 UTC (permalink / raw)
To: Allen Ballway, benjamin.tissoires
Cc: llvm, oe-kbuild-all, jikos, lukas.bulwahn, linux-input,
linux-kernel, Allen Ballway
In-Reply-To: <20230202144149.1.I7f213388b358718068c63acb698dc4937716cf35@changeid>
Hi Allen,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on hid/for-next]
[also build test ERROR on next-20230203]
[cannot apply to linus/master v6.2-rc6]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Allen-Ballway/HID-multitouch-Fix-typo-in-config-check/20230202-224919
base: https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-next
patch link: https://lore.kernel.org/r/20230202144149.1.I7f213388b358718068c63acb698dc4937716cf35%40changeid
patch subject: [PATCH] HID: multitouch: Fix typo in config check
config: x86_64-randconfig-a003 (https://download.01.org/0day-ci/archive/20230203/202302031440.9V6esF8X-lkp@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/intel-lab-lkp/linux/commit/a2331d08db1030f3e3f2e0d9c9232780c27d954a
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Allen-Ballway/HID-multitouch-Fix-typo-in-config-check/20230202-224919
git checkout a2331d08db1030f3e3f2e0d9c9232780c27d954a
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=x86_64 olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> ld.lld: error: undefined symbol: i2c_hid_get_dmi_quirks
>>> referenced by hid-quirks.c:1305 (drivers/hid/hid-quirks.c:1305)
>>> vmlinux.o:(hid_lookup_quirk)
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
^ permalink raw reply
* Re: [PATCH] HID: multitouch: Fix typo in config check
From: kernel test robot @ 2023-02-03 3:18 UTC (permalink / raw)
To: Allen Ballway, benjamin.tissoires
Cc: oe-kbuild-all, jikos, lukas.bulwahn, linux-input, linux-kernel,
Allen Ballway
In-Reply-To: <20230202144149.1.I7f213388b358718068c63acb698dc4937716cf35@changeid>
Hi Allen,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on hid/for-next]
[also build test ERROR on next-20230202]
[cannot apply to linus/master v6.2-rc6]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Allen-Ballway/HID-multitouch-Fix-typo-in-config-check/20230202-224919
base: https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-next
patch link: https://lore.kernel.org/r/20230202144149.1.I7f213388b358718068c63acb698dc4937716cf35%40changeid
patch subject: [PATCH] HID: multitouch: Fix typo in config check
config: x86_64-randconfig-a006 (https://download.01.org/0day-ci/archive/20230203/202302031117.u6FdSXY2-lkp@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-8) 11.3.0
reproduce (this is a W=1 build):
# https://github.com/intel-lab-lkp/linux/commit/a2331d08db1030f3e3f2e0d9c9232780c27d954a
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Allen-Ballway/HID-multitouch-Fix-typo-in-config-check/20230202-224919
git checkout a2331d08db1030f3e3f2e0d9c9232780c27d954a
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=x86_64 olddefconfig
make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
ld: vmlinux.o: in function `hid_lookup_quirk':
>> drivers/hid/hid-quirks.c:1305: undefined reference to `i2c_hid_get_dmi_quirks'
vim +1305 drivers/hid/hid-quirks.c
d5d3e202753cc0 Benjamin Tissoires 2017-11-20 1258
d5d3e202753cc0 Benjamin Tissoires 2017-11-20 1259 /**
0603616a5bf6cd Randy Dunlap 2021-01-19 1260 * hid_lookup_quirk - return any quirks associated with a HID device
d5d3e202753cc0 Benjamin Tissoires 2017-11-20 1261 * @hdev: the HID device to look for
d5d3e202753cc0 Benjamin Tissoires 2017-11-20 1262 *
d5d3e202753cc0 Benjamin Tissoires 2017-11-20 1263 * Description:
d5d3e202753cc0 Benjamin Tissoires 2017-11-20 1264 * Given a HID device, return any quirks associated with that device.
d5d3e202753cc0 Benjamin Tissoires 2017-11-20 1265 *
0603616a5bf6cd Randy Dunlap 2021-01-19 1266 * Return: an unsigned long quirks value.
d5d3e202753cc0 Benjamin Tissoires 2017-11-20 1267 */
d5d3e202753cc0 Benjamin Tissoires 2017-11-20 1268 unsigned long hid_lookup_quirk(const struct hid_device *hdev)
d5d3e202753cc0 Benjamin Tissoires 2017-11-20 1269 {
d5d3e202753cc0 Benjamin Tissoires 2017-11-20 1270 unsigned long quirks = 0;
d5d3e202753cc0 Benjamin Tissoires 2017-11-20 1271 const struct hid_device_id *quirk_entry = NULL;
d5d3e202753cc0 Benjamin Tissoires 2017-11-20 1272
d5d3e202753cc0 Benjamin Tissoires 2017-11-20 1273 /* NCR devices must not be queried for reports */
d5d3e202753cc0 Benjamin Tissoires 2017-11-20 1274 if (hdev->bus == BUS_USB &&
d5d3e202753cc0 Benjamin Tissoires 2017-11-20 1275 hdev->vendor == USB_VENDOR_ID_NCR &&
d5d3e202753cc0 Benjamin Tissoires 2017-11-20 1276 hdev->product >= USB_DEVICE_ID_NCR_FIRST &&
d5d3e202753cc0 Benjamin Tissoires 2017-11-20 1277 hdev->product <= USB_DEVICE_ID_NCR_LAST)
d5d3e202753cc0 Benjamin Tissoires 2017-11-20 1278 return HID_QUIRK_NO_INIT_REPORTS;
d5d3e202753cc0 Benjamin Tissoires 2017-11-20 1279
d5158e020c4593 Niels Skou Olsen 2017-10-04 1280 /* These devices must be ignored if version (bcdDevice) is too old */
d5158e020c4593 Niels Skou Olsen 2017-10-04 1281 if (hdev->bus == BUS_USB && hdev->vendor == USB_VENDOR_ID_JABRA) {
d5158e020c4593 Niels Skou Olsen 2017-10-04 1282 switch (hdev->product) {
d5158e020c4593 Niels Skou Olsen 2017-10-04 1283 case USB_DEVICE_ID_JABRA_SPEAK_410:
d5158e020c4593 Niels Skou Olsen 2017-10-04 1284 if (hdev->version < 0x0111)
d5158e020c4593 Niels Skou Olsen 2017-10-04 1285 return HID_QUIRK_IGNORE;
d5158e020c4593 Niels Skou Olsen 2017-10-04 1286 break;
d5158e020c4593 Niels Skou Olsen 2017-10-04 1287 case USB_DEVICE_ID_JABRA_SPEAK_510:
d5158e020c4593 Niels Skou Olsen 2017-10-04 1288 if (hdev->version < 0x0214)
d5158e020c4593 Niels Skou Olsen 2017-10-04 1289 return HID_QUIRK_IGNORE;
d5158e020c4593 Niels Skou Olsen 2017-10-04 1290 break;
d5158e020c4593 Niels Skou Olsen 2017-10-04 1291 }
d5158e020c4593 Niels Skou Olsen 2017-10-04 1292 }
d5158e020c4593 Niels Skou Olsen 2017-10-04 1293
d5d3e202753cc0 Benjamin Tissoires 2017-11-20 1294 mutex_lock(&dquirks_lock);
d5d3e202753cc0 Benjamin Tissoires 2017-11-20 1295 quirk_entry = hid_exists_dquirk(hdev);
d5d3e202753cc0 Benjamin Tissoires 2017-11-20 1296 if (quirk_entry)
d5d3e202753cc0 Benjamin Tissoires 2017-11-20 1297 quirks = quirk_entry->driver_data;
6e65d9d5492f37 Benjamin Tissoires 2017-11-20 1298 else
6e65d9d5492f37 Benjamin Tissoires 2017-11-20 1299 quirks = hid_gets_squirk(hdev);
d5d3e202753cc0 Benjamin Tissoires 2017-11-20 1300 mutex_unlock(&dquirks_lock);
d5d3e202753cc0 Benjamin Tissoires 2017-11-20 1301
a2f416bf062a38 Allen Ballway 2023-01-10 1302 /* Get quirks specific to I2C devices */
a2331d08db1030 Allen Ballway 2023-02-02 1303 if (IS_ENABLED(CONFIG_I2C_HID_CORE) && IS_ENABLED(CONFIG_DMI) &&
a2f416bf062a38 Allen Ballway 2023-01-10 1304 hdev->bus == BUS_I2C)
a2f416bf062a38 Allen Ballway 2023-01-10 @1305 quirks |= i2c_hid_get_dmi_quirks(hdev->vendor, hdev->product);
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
^ permalink raw reply
* Re: Suspend with ps2 keyboard/mice
From: Zack Rusin @ 2023-02-03 2:53 UTC (permalink / raw)
To: dmitry.torokhov@gmail.com
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Michael Banack
In-Reply-To: <Y9tUPM/UV1quMebq@google.com>
On Wed, 2023-02-01 at 22:12 -0800, dmitry.torokhov@gmail.com wrote:
> On Thu, Feb 02, 2023 at 03:23:34AM +0000, Zack Rusin wrote:
> > So the kernels i8042 module specifically calls device_set_wakeup_enable only on
> > the
> > keyboard port. Then because of the a1cec0617738 psbase leaves the mouse enabled
> > on
> > suspend which, in case of a mouse move/click right before the suspend makes sure
> > Linux will never wake up.
> >
> > That's because the dataport will be effectively latched to the mouse (mouse irq
> > wasn't serviced in the guest) and it won't be possible to deliver a keyboard
> > interrupt anymore, and mouse interrupts won't wake Linux.
> >
> > Our suggestion would be to simply remove the:
> > ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_ENABLE);
> > added in a1cec0617738 . I don't have access to HP nx7400 from 2007 but it seems
> > like
> > that code breaks every other well formed ps/2 controller with suspend/wakeup.
> >
> > I think the ps2 mouse has to be disabled on suspend in order to be able to get
> > the
> > keyboard interrupts required to wake up. Otherwise if the mouse is supposed to
> > be
> > really enabled (but mouse irq's will be ignored), then how does the PS/2
> > controller
> > decide whether to return mouse or keyboard data when they do the data port read?
>
> IIRC the reason we leave mouse enabled is because firmware on multiple
> devices was unhappy if the mouse was disabled on suspend. It was not
> only nx7400, but others as well. I am not sure if newer generation
> devices exhibit the same problem or not.
>
> Regarding inability to deliver keyboard interrupt: I am not sure why you
> are saying that Embedded Controller (EC) can not raise IRQ1 and IRQ12
> together. Also, they do not have to be wakeup sources, I think on some
> designs these signals were wired to other pins as well, and those were
> actually configured to wake up the AP.
>
> Both mouse and keyboard data are coming from the same data port, so it
> really up to the Embedded Controller to figure out what data it wants to
> send first, and Linux is using the same interrupt handler for both IRQ1
> and IRQ12, and can dispatch data as needed. But you do not need to read
> the data to wake up the system. You just need EC to actually signal
> interrupt that is configured as a wakeup source.
>
> I think you should look into how you implement EC and make sure it does
> not get stuck.
That makes sense. Thanks a lot for going over this. We were being overly cautious
with the IRQ delivery and would not deliver IRQ's on PS/2 unless the dataport had
data from the respective device. We went back now and checked Win98 and WinXP to
make sure that they actually don't depend on the IRQ number that's delivered to
figure out the routing and it looks like they properly do check the status register.
So we went ahead and fixed it in our code.
For the kernel I will write a small patch just for vmmouse that overwrites the serio
cleanup to avoid the enabling of the mouse on suspend just to fix it for folks who
won't be running our latest hypervisors and everything should be fine.
z
^ permalink raw reply
* [PATCH 3/3] Input: xpad - add support for 8BitDo Ultimate Wireless controller dongle
From: Vicki Pfau @ 2023-02-03 2:27 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, linux-input
Cc: Pierre-Loup A. Griffais, Josh Cotton
In-Reply-To: <20230203022758.3982393-1-vi@endrift.com>
From: "Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com>
Add the VID and PID of the 8BitDo Ultimate Wireless controller dongle
Signed-off-by: Josh Cotton <jcotton42@outlook.com>
---
drivers/input/joystick/xpad.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 16bc3cd4c2b7..403b57e8176b 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -359,6 +359,7 @@ static const struct xpad_device {
{ 0x24c6, 0xfafe, "Rock Candy Gamepad for Xbox 360", 0, XTYPE_XBOX360 },
{ 0x2563, 0x058d, "OneXPlayer Gamepad", 0, XTYPE_XBOX360 },
{ 0x2dc8, 0x2000, "8BitDo Pro 2 Wired Controller fox Xbox", 0, XTYPE_XBOXONE },
+ { 0x2dc8, 0x3106, "8BitDo Ultimate Wireless Controller", 0, XTYPE_XBOX360 },
{ 0x31e3, 0x1100, "Wooting One", 0, XTYPE_XBOX360 },
{ 0x31e3, 0x1200, "Wooting Two", 0, XTYPE_XBOX360 },
{ 0x31e3, 0x1210, "Wooting Lekker", 0, XTYPE_XBOX360 },
@@ -494,6 +495,7 @@ static const struct usb_device_id xpad_table[] = {
XPAD_XBOX360_VENDOR(0x260d), /* Dareu H101 */
XPAD_XBOX360_VENDOR(0x2c22), /* Qanba Controllers */
XPAD_XBOXONE_VENDOR(0x2dc8), /* 8BitDo Pro 2 Wired Controller for Xbox */
+ XPAD_XBOX360_VENDOR(0x2dc8), /* 8BitDo Ultimate Wireless Controller */
XPAD_XBOXONE_VENDOR(0x2e24), /* Hyperkin Duke X-Box One pad */
XPAD_XBOX360_VENDOR(0x2f24), /* GameSir Controllers */
XPAD_XBOX360_VENDOR(0x31e3), /* Wooting Keyboards */
--
2.39.1
^ permalink raw reply related
* [PATCH 1/3] Input: xpad - Treat Qanba controllers as Xbox360 controllers
From: Vicki Pfau @ 2023-02-03 2:27 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, linux-input
Cc: Pierre-Loup A. Griffais, Cristian Ciocaltea
From: "Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com>
They act that way in PC mode.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
drivers/input/joystick/xpad.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 2959d80f7fdb..bb65c8268963 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -492,6 +492,7 @@ static const struct usb_device_id xpad_table[] = {
XPAD_XBOXONE_VENDOR(0x24c6), /* PowerA Controllers */
XPAD_XBOX360_VENDOR(0x2563), /* OneXPlayer Gamepad */
XPAD_XBOX360_VENDOR(0x260d), /* Dareu H101 */
+ XPAD_XBOX360_VENDOR(0x2c22), /* Qanba Controllers */
XPAD_XBOXONE_VENDOR(0x2dc8), /* 8BitDo Pro 2 Wired Controller for Xbox */
XPAD_XBOXONE_VENDOR(0x2e24), /* Hyperkin Duke X-Box One pad */
XPAD_XBOX360_VENDOR(0x2f24), /* GameSir Controllers */
--
2.39.1
^ permalink raw reply related
* [PATCH 2/3] Input: xpad - fix PowerA EnWired Controller guide button
From: Vicki Pfau @ 2023-02-03 2:27 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, linux-input; +Cc: Vicki Pfau
In-Reply-To: <20230203022758.3982393-1-vi@endrift.com>
This commit explicitly disables the audio interface the same way the official
driver does. This is needed for some controllers, such as the PowerA Enhanced
Wired Controller for Series X|S (0x20d6:0x200e) to report the guide button.
Signed-off-by: Vicki Pfau <vi@endrift.com>
---
drivers/input/joystick/xpad.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index bb65c8268963..16bc3cd4c2b7 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -1390,6 +1390,13 @@ static int xpad_start_xbox_one(struct usb_xpad *xpad)
unsigned long flags;
int retval;
+ /* Explicitly disable the audio interface. This is needed for some
+ * controllers, such as the PowerA Enhanced Wired Controller
+ * for Series X|S (0x20d6:0x200e) to report the guide button */
+ retval = usb_set_interface(xpad->udev, 1, 0);
+ if (retval)
+ return retval;
+
spin_lock_irqsave(&xpad->odata_lock, flags);
/*
--
2.39.1
^ permalink raw reply related
* [PATCH] HID: multitouch: Fix typo in config check
From: Allen Ballway @ 2023-02-02 14:47 UTC (permalink / raw)
To: benjamin.tissoires
Cc: jikos, lukas.bulwahn, linux-input, linux-kernel, Allen Ballway
Fixes a typo causing a config check to look for a nonexistent config,
leaving the affected code unusable.
Signed-off-by: Allen Ballway <ballway@chromium.org>
---
drivers/hid/hid-quirks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 78452faf3c9b4..8417066b5ff72 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -1300,7 +1300,7 @@ unsigned long hid_lookup_quirk(const struct hid_device *hdev)
mutex_unlock(&dquirks_lock);
/* Get quirks specific to I2C devices */
- if (IS_ENABLED(CONFIG_I2C_DMI_CORE) && IS_ENABLED(CONFIG_DMI) &&
+ if (IS_ENABLED(CONFIG_I2C_HID_CORE) && IS_ENABLED(CONFIG_DMI) &&
hdev->bus == BUS_I2C)
quirks |= i2c_hid_get_dmi_quirks(hdev->vendor, hdev->product);
--
2.39.1.456.gfc5497dd1b-goog
^ permalink raw reply related
* Re: Linux 6.1 and 6.2-rc make mousewheel on Logitech G903 (046d:c091) report too many non-hires events
From: Bastien Nocera @ 2023-02-02 12:21 UTC (permalink / raw)
To: Tobias Klausmann,
Linux kernel regression tracking (Thorsten Leemhuis)
Cc: Salvatore Bonaccorso, linux-input, regressions
In-Reply-To: <Y9VPBpcyEK61cNC1@skade.schwarzvogel.de>
Hey Tobias,
On Sat, 2023-01-28 at 17:36 +0100, Tobias Klausmann wrote:
> Hi!
>
> On Sat, 28 Jan 2023, Linux kernel regression tracking (Thorsten
> Leemhuis) wrote:
> > On 28.01.23 16:39, Salvatore Bonaccorso wrote:
> > > Let's loop in as well the regresssions list.
> >
> > Thx for that.
> >
> > TWIMC, I assume it's the same issue as this one:
> > https://bugzilla.kernel.org/show_bug.cgi?id=216885
>
> That is correct.
I've posted debug patches on the bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=216885#c29
I'll post a patch to either fix the bug, or disable the functionality
on those devices as soon as I have enough information.
Cheers
^ permalink raw reply
* Re: [PATCH] HID: use standard debug APIs
From: Bastien Nocera @ 2023-02-02 10:15 UTC (permalink / raw)
To: Thomas Weißschuh, Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel
In-Reply-To: <20230129215352.oglktngi2rvp6sfd@t-8ch.de>
On Sun, 2023-01-29 at 21:53 +0000, Thomas Weißschuh wrote:
> Hi Jiri, hi Benjamin,
>
> On Fri, Dec 23, 2022 at 09:30:19PM +0000, Thomas Weißschuh wrote:
> > The custom "debug" module parameter is fairly inflexible.
> > It can only manage debugging for all calls dbg_hid() at the same
> > time.
> >
> > Furthermore it creates a mismatch between calls to hid_dbg() which
> > can
> > be managed by CONFIG_DYNAMIC_DEBUG and dbg_hid() which is managed
> > by the
> > module parameter.
> >
> > Furthermore the change to pr_debug() allows the debugging
> > statements to
> > be completely compiled-out if desired.
> >
> > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> > ---
> >
> > Note: This removes the possibility to enable debugging for the HID
> > core
> > and all drivers at the same time.
> > If this is still desirable it could probably be implemented with
> > the new
> > DYNAMIC_DEBUG class feature.
> > ---
> > drivers/hid/hid-core.c | 9 ---------
> > include/linux/hid.h | 8 +-------
> > 2 files changed, 1 insertion(+), 16 deletions(-)
> >
> > diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> > index bd47628da6be..4facfb446986 100644
> > --- a/drivers/hid/hid-core.c
> > +++ b/drivers/hid/hid-core.c
> > @@ -41,11 +41,6 @@
> >
> > #define DRIVER_DESC "HID core driver"
> >
> > -int hid_debug = 0;
> > -module_param_named(debug, hid_debug, int, 0600);
> > -MODULE_PARM_DESC(debug, "toggle HID debugging messages");
> > -EXPORT_SYMBOL_GPL(hid_debug);
> > -
> > static int hid_ignore_special_drivers = 0;
> > module_param_named(ignore_special_drivers,
> > hid_ignore_special_drivers, int, 0600);
> > MODULE_PARM_DESC(ignore_special_drivers, "Ignore any special
> > drivers and handle all devices by generic driver");
> > @@ -2909,10 +2904,6 @@ static int __init hid_init(void)
> > {
> > int ret;
> >
> > - if (hid_debug)
> > - pr_warn("hid_debug is now used solely for parser
> > and driver debugging.\n"
> > - "debugfs is now used for inspecting the
> > device (report descriptor, reports)\n");
> > -
> > ret = bus_register(&hid_bus_type);
> > if (ret) {
> > pr_err("can't register hid bus\n");
> > diff --git a/include/linux/hid.h b/include/linux/hid.h
> > index 8677ae38599e..676f501507aa 100644
> > --- a/include/linux/hid.h
> > +++ b/include/linux/hid.h
> > @@ -882,8 +882,6 @@ static inline bool hid_is_usb(struct hid_device
> > *hdev)
> >
> > /* HID core API */
> >
> > -extern int hid_debug;
> > -
> > extern bool hid_ignore(struct hid_device *);
> > extern int hid_add_device(struct hid_device *);
> > extern void hid_destroy_device(struct hid_device *);
> > @@ -1191,11 +1189,7 @@ int hid_pidff_init(struct hid_device *hid);
> > #define hid_pidff_init NULL
> > #endif
> >
> > -#define dbg_hid(fmt,
> > ...) \
> > -do
> > {
> > \
> > - if
> > (hid_debug) \
> > - printk(KERN_DEBUG "%s: " fmt, __FILE__,
> > ##__VA_ARGS__); \
> > -} while (0)
> > +#define dbg_hid(fmt, ...) pr_debug("%s: " fmt, __FILE__,
> > ##__VA_ARGS__)
> >
> > #define hid_err(hid, fmt, ...) \
> > dev_err(&(hid)->dev, fmt, ##__VA_ARGS__)
>
> any feedback on this patch?
>
> Please note that this is *not* the same as the already merged
> 34ba3657a503 ("HID: i2c-hid: switch to standard debugging APIs")
You can add:
Tested-by: Bastien Nocera <hadess@hadess.net>
to this one
I tested it as a way to debug the Logitech G903 regression.
I should note that it's pretty weird to have a dbg_hid() and a
hid_dbg() that do pretty much the same thing, but that was a pre-
existing problem.
>
> > ---
> > base-commit: 51094a24b85e29138b7fa82ef1e1b4fe19c90046
> > change-id: 20221223-hid-dbg-2f3eeddddd53
> >
> > Best regards,
> > --
> > Thomas Weißschuh <linux@weissschuh.net>
>
> Thanks,
> Thomas
^ permalink raw reply
* Re: [PATCH] HID: add KEY_CAMERA_FOCUS event in HID
From: qi feng @ 2023-02-02 9:56 UTC (permalink / raw)
To: Jiri Kosina; +Cc: linux-input, linux-kernel, fengqi, Benjamin Tissoires
In-Reply-To: <nycvar.YFH.7.76.2301301527100.1734@cbobk.fhfr.pm>
I resubmitted V2 according to the standard, please help me to review it
thanks a lot
Jiri Kosina <jikos@kernel.org> 于2023年1月30日周一 22:28写道：
>
> On Sun, 29 Jan 2023, qi feng wrote:
>
> > Hi,
> > Our Bluetooth Handle needs the focus function, which is missing in the
> > current map
> > If our setting is unreasonable, do you have other suggested values
>
> If the device is under your control, wouldn't it be better to let it
> produce something more defined by HID standard? (see e.g. 0x90 -- Camera
> Control Page).
>
> Thanks,
>
> --
> Jiri Kosina
> SUSE Labs
>
^ permalink raw reply
* Re: Suspend with ps2 keyboard/mice
From: dmitry.torokhov @ 2023-02-02 6:12 UTC (permalink / raw)
To: Zack Rusin
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Michael Banack
In-Reply-To: <6d7b3cda248c7ca14d6fb3c8fbd49345306ae46e.camel@vmware.com>
Hi Zack,
On Thu, Feb 02, 2023 at 03:23:34AM +0000, Zack Rusin wrote:
> Hi, Dmitry.
>
> We've been scratching our heads about:
> a1cec0617738 ("Input: psmouse - properly reset mouse on shutdown/suspend")
> because we're having trouble seeing how it can work with suspend on ps2. We were
> planning to wait another 4 years to get to a 20 year anniversary of that patch but
> we figured 16 is probably good enough.
Heh, yeah, it's been a while.
>
> So the kernels i8042 module specifically calls device_set_wakeup_enable only on the
> keyboard port. Then because of the a1cec0617738 psbase leaves the mouse enabled on
> suspend which, in case of a mouse move/click right before the suspend makes sure
> Linux will never wake up.
>
> That's because the dataport will be effectively latched to the mouse (mouse irq
> wasn't serviced in the guest) and it won't be possible to deliver a keyboard
> interrupt anymore, and mouse interrupts won't wake Linux.
>
> Our suggestion would be to simply remove the:
> ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_ENABLE);
> added in a1cec0617738 . I don't have access to HP nx7400 from 2007 but it seems like
> that code breaks every other well formed ps/2 controller with suspend/wakeup.
>
> I think the ps2 mouse has to be disabled on suspend in order to be able to get the
> keyboard interrupts required to wake up. Otherwise if the mouse is supposed to be
> really enabled (but mouse irq's will be ignored), then how does the PS/2 controller
> decide whether to return mouse or keyboard data when they do the data port read?
IIRC the reason we leave mouse enabled is because firmware on multiple
devices was unhappy if the mouse was disabled on suspend. It was not
only nx7400, but others as well. I am not sure if newer generation
devices exhibit the same problem or not.
Regarding inability to deliver keyboard interrupt: I am not sure why you
are saying that Embedded Controller (EC) can not raise IRQ1 and IRQ12
together. Also, they do not have to be wakeup sources, I think on some
designs these signals were wired to other pins as well, and those were
actually configured to wake up the AP.
Both mouse and keyboard data are coming from the same data port, so it
really up to the Embedded Controller to figure out what data it wants to
send first, and Linux is using the same interrupt handler for both IRQ1
and IRQ12, and can dispatch data as needed. But you do not need to read
the data to wake up the system. You just need EC to actually signal
interrupt that is configured as a wakeup source.
I think you should look into how you implement EC and make sure it does
not get stuck.
Thanks.
--
Dmitry
^ permalink raw reply
* Suspend with ps2 keyboard/mice
From: Zack Rusin @ 2023-02-02 3:23 UTC (permalink / raw)
To: dmitry.torokhov@gmail.com
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Michael Banack
Hi, Dmitry.
We've been scratching our heads about:
a1cec0617738 ("Input: psmouse - properly reset mouse on shutdown/suspend")
because we're having trouble seeing how it can work with suspend on ps2. We were
planning to wait another 4 years to get to a 20 year anniversary of that patch but
we figured 16 is probably good enough.
So the kernels i8042 module specifically calls device_set_wakeup_enable only on the
keyboard port. Then because of the a1cec0617738 psbase leaves the mouse enabled on
suspend which, in case of a mouse move/click right before the suspend makes sure
Linux will never wake up.
That's because the dataport will be effectively latched to the mouse (mouse irq
wasn't serviced in the guest) and it won't be possible to deliver a keyboard
interrupt anymore, and mouse interrupts won't wake Linux.
Our suggestion would be to simply remove the:
ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_ENABLE);
added in a1cec0617738 . I don't have access to HP nx7400 from 2007 but it seems like
that code breaks every other well formed ps/2 controller with suspend/wakeup.
I think the ps2 mouse has to be disabled on suspend in order to be able to get the
keyboard interrupts required to wake up. Otherwise if the mouse is supposed to be
really enabled (but mouse irq's will be ignored), then how does the PS/2 controller
decide whether to return mouse or keyboard data when they do the data port read?
z
^ permalink raw reply
* [PATCH] dt-bindings: input: pwm-beeper: add volume
From: Manuel Traut @ 2023-02-01 17:10 UTC (permalink / raw)
To: linux-kernel
Cc: Manuel Traut, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
linux-input, devicetree
In-Reply-To: <d4c1da7b-5b49-6bbf-4470-b3f2eef7f745@linaro.org>
Add an array of supported volume levels and a default volume level.
Signed-off-by: Manuel Traut <manuel.traut@mt.com>
---
.../devicetree/bindings/input/pwm-beeper.yaml | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.yaml b/Documentation/devicetree/bindings/input/pwm-beeper.yaml
index 1ebc3a46d934..7ea2954cdd6a 100644
--- a/Documentation/devicetree/bindings/input/pwm-beeper.yaml
+++ b/Documentation/devicetree/bindings/input/pwm-beeper.yaml
@@ -25,6 +25,18 @@ properties:
beeper-hz:
description: bell frequency in Hz
+ volume-levels-bp:
+ description: >
+ Please note that the actual volume of most beepers is
+ highly non-linear, which means that low volume levels
+ are probably somewhere in the range of 10 to 300 (0.1-3%
+ duty cycle).
+ maximum: 5000
+
+ default-volume-level-bp:
+ description: >
+ The default volume level.
+
required:
- compatible
- pwms
@@ -36,4 +48,6 @@ examples:
beeper {
compatible = "pwm-beeper";
pwms = <&pwm0>;
+ volume-levels-bp = <0 80 200 400 5000>;
+ default-volume-level-bp = <80>;
};
--
2.39.1
^ permalink raw reply related
* Re: [PATCH v10 3/4] dt-bindings: input: pwm-beeper: add volume
From: Krzysztof Kozlowski @ 2023-02-01 16:15 UTC (permalink / raw)
To: Manuel Traut, linux-kernel
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Frieder Schrempf, linux-input, devicetree
In-Reply-To: <20230201152128.614439-4-manuel.traut@mt.com>
On 01/02/2023 16:21, Manuel Traut wrote:
> Adds an array of supported volume levels and a default volume level.
Adds -> Add
>
> Signed-off-by: Manuel Traut <manuel.traut@mt.com>
> ---
> .../devicetree/bindings/input/pwm-beeper.yaml | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
Thank you for your patch. There is something to discuss/improve.
> diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.yaml b/Documentation/devicetree/bindings/input/pwm-beeper.yaml
> index 1ebc3a46d934..6599e28ba5e6 100644
> --- a/Documentation/devicetree/bindings/input/pwm-beeper.yaml
> +++ b/Documentation/devicetree/bindings/input/pwm-beeper.yaml
> @@ -25,6 +25,21 @@ properties:
> beeper-hz:
> description: bell frequency in Hz
>
> + volume-levels-bp:
> + description: >
> + Array of PWM duty cycle values that correspond to
> + linear volume levels. These need to be in the range of
> + 0 to 5000, while 0 means 0% duty cycle (mute) and 5000
> + means 50% duty cycle (max volume).
Is range 0-5000 limitation of the device? If so, this should not be
free-form text, but "maximum: 5000" (minimum is 0 anyway).
> + Please note that the actual volume of most beepers is
> + highly non-linear, which means that low volume levels
> + are probably somewhere in the range of 10 to 300 (0.1-3%
> + duty cycle).
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v10 4/4] input: pwm-beeper: set volume levels by devicetree
From: Manuel Traut @ 2023-02-01 15:21 UTC (permalink / raw)
To: linux-kernel
Cc: Frieder Schrempf, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Manuel Traut, linux-input, devicetree
In-Reply-To: <20230201152128.614439-1-manuel.traut@mt.com>
From: Frieder Schrempf <frieder.schrempf@kontron.de>
Add devicetree bindings to define supported volume levels and the
default volume level.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Manuel Traut <manuel.traut@mt.com>
Tested-by: Manuel Traut <manuel.traut@mt.com>
---
drivers/input/misc/pwm-beeper.c | 73 +++++++++++++++++++++++++--------
1 file changed, 55 insertions(+), 18 deletions(-)
diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
index 214d3fa0a06d..fc367a249490 100644
--- a/drivers/input/misc/pwm-beeper.c
+++ b/drivers/input/misc/pwm-beeper.c
@@ -93,7 +93,7 @@ static int pwm_beeper_on(struct pwm_beeper *beeper, unsigned long period)
state.enabled = true;
state.period = period;
- pwm_set_relative_duty_cycle(&state, beeper->volume_levels[beeper->volume], 1000);
+ pwm_set_relative_duty_cycle(&state, beeper->volume_levels[beeper->volume], 10000);
error = pwm_apply_state(beeper->pwm, &state);
if (error)
@@ -181,8 +181,9 @@ static int pwm_beeper_probe(struct platform_device *pdev)
struct pwm_beeper *beeper;
struct pwm_state state;
u32 bell_frequency;
- int error;
+ int error, i, length;
size_t size;
+ u32 value;
beeper = devm_kzalloc(dev, sizeof(*beeper), GFP_KERNEL);
if (!beeper)
@@ -228,23 +229,59 @@ static int pwm_beeper_probe(struct platform_device *pdev)
beeper->bell_frequency = bell_frequency;
- beeper->max_volume = 4;
-
- size = sizeof(*beeper->volume_levels) *
- (beeper->max_volume + 1);
-
- beeper->volume_levels = devm_kzalloc(&(pdev->dev), size,
- GFP_KERNEL);
- if (!beeper->volume_levels)
- return -ENOMEM;
-
- beeper->volume_levels[0] = 0;
- beeper->volume_levels[1] = 80;
- beeper->volume_levels[2] = 200;
- beeper->volume_levels[3] = 400;
- beeper->volume_levels[4] = 5000;
+ /* determine the number of volume levels */
+ length = device_property_read_u32_array(&pdev->dev, "volume-levels-bp", NULL, 0);
+ if (length <= 0) {
+ dev_dbg(&pdev->dev, "no volume levels specified, using max volume\n");
+ beeper->max_volume = 1;
+ } else
+ beeper->max_volume = length;
+
+ /* read volume levels from DT property */
+ if (beeper->max_volume > 0) {
+ size = sizeof(*beeper->volume_levels) * beeper->max_volume;
+
+ beeper->volume_levels = devm_kzalloc(&(pdev->dev), size,
+ GFP_KERNEL);
+ if (!beeper->volume_levels)
+ return -ENOMEM;
+
+ if (length > 0) {
+ error = device_property_read_u32_array(&pdev->dev, "volume-levels-bp",
+ beeper->volume_levels,
+ beeper->max_volume);
+
+ if (error < 0)
+ return error;
+
+ error = device_property_read_u32(&pdev->dev, "default-volume-level-bp",
+ &value);
+
+ if (error < 0) {
+ dev_dbg(&pdev->dev, "no default volume specified, using max volume\n");
+ value = beeper->max_volume - 1;
+ } else {
+ for (i = 0; i < length; i++) {
+ if (beeper->volume_levels[i] == value) {
+ value = i;
+ break;
+ }
+ }
+ if (value != i) {
+ dev_dbg(&pdev->dev,
+ "default-volume-level-bp %d invalid, using %d\n",
+ value, beeper->max_volume - 1);
+ value = beeper->max_volume - 1;
+ }
+ }
+ } else {
+ beeper->volume_levels[0] = 5000;
+ value = 0;
+ }
- beeper->volume = beeper->max_volume;
+ beeper->volume = value;
+ beeper->max_volume--;
+ }
beeper->input = devm_input_allocate_device(dev);
if (!beeper->input) {
--
2.39.1
^ permalink raw reply related
* [PATCH v10 3/4] dt-bindings: input: pwm-beeper: add volume
From: Manuel Traut @ 2023-02-01 15:21 UTC (permalink / raw)
To: linux-kernel
Cc: Manuel Traut, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Frieder Schrempf, linux-input, devicetree
In-Reply-To: <20230201152128.614439-1-manuel.traut@mt.com>
Adds an array of supported volume levels and a default volume level.
Signed-off-by: Manuel Traut <manuel.traut@mt.com>
---
.../devicetree/bindings/input/pwm-beeper.yaml | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.yaml b/Documentation/devicetree/bindings/input/pwm-beeper.yaml
index 1ebc3a46d934..6599e28ba5e6 100644
--- a/Documentation/devicetree/bindings/input/pwm-beeper.yaml
+++ b/Documentation/devicetree/bindings/input/pwm-beeper.yaml
@@ -25,6 +25,21 @@ properties:
beeper-hz:
description: bell frequency in Hz
+ volume-levels-bp:
+ description: >
+ Array of PWM duty cycle values that correspond to
+ linear volume levels. These need to be in the range of
+ 0 to 5000, while 0 means 0% duty cycle (mute) and 5000
+ means 50% duty cycle (max volume).
+ Please note that the actual volume of most beepers is
+ highly non-linear, which means that low volume levels
+ are probably somewhere in the range of 10 to 300 (0.1-3%
+ duty cycle).
+
+ default-volume-level-bp:
+ description: >
+ The default volume level.
+
required:
- compatible
- pwms
@@ -36,4 +51,6 @@ examples:
beeper {
compatible = "pwm-beeper";
pwms = <&pwm0>;
+ volume-levels-bp = <0 80 200 400 5000>;
+ default-volume-level-bp = <80>;
};
--
2.39.1
^ permalink raw reply related
* [PATCH v10 2/4] input: pwm-beeper: add feature to set volume via sysfs
From: Manuel Traut @ 2023-02-01 15:21 UTC (permalink / raw)
To: linux-kernel
Cc: Frieder Schrempf, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Manuel Traut, linux-input, devicetree
In-Reply-To: <20230201152128.614439-1-manuel.traut@mt.com>
From: Frieder Schrempf <frieder.schrempf@kontron.de>
Make the driver accept switching volume levels via sysfs.
This can be helpful if the beep/bell sound intensity needs
to be adapted to the environment of the device.
The volume adjustment is done by changing the duty cycle of
the pwm signal.
Add a sysfs interface with 5 default volume levels:
0 - mute
..
4 - max. volume
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Manuel Traut <manuel.traut@mt.com>
Tested-by: Manuel Traut <manuel.traut@mt.com>
---
.../ABI/testing/sysfs-devices-pwm-beeper | 17 ++++
drivers/input/misc/pwm-beeper.c | 96 ++++++++++++++++++-
2 files changed, 112 insertions(+), 1 deletion(-)
create mode 100644 Documentation/ABI/testing/sysfs-devices-pwm-beeper
diff --git a/Documentation/ABI/testing/sysfs-devices-pwm-beeper b/Documentation/ABI/testing/sysfs-devices-pwm-beeper
new file mode 100644
index 000000000000..d2a22516f31d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-pwm-beeper
@@ -0,0 +1,17 @@
+What: /sys/devices/.../pwm-beeper/volume
+Date: January 2023
+KernelVersion:
+Contact: Frieder Schrempf <frieder.schrempf@kontron.de>
+Description:
+ Control the volume of this pwm-beeper. Values
+ are between 0 and max_volume. This file will also
+ show the current volume level stored in the driver.
+
+What: /sys/devices/.../pwm-beeper/max_volume
+Date: February 2023
+KernelVersion:
+Contact: Frieder Schrempf <frieder.schrempf@kontron.de>
+Description:
+ This file shows the maximum volume level that can be
+ assigned to volume.
+
diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
index d6b12477748a..214d3fa0a06d 100644
--- a/drivers/input/misc/pwm-beeper.c
+++ b/drivers/input/misc/pwm-beeper.c
@@ -1,9 +1,14 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* Copyright (C) 2010, Lars-Peter Clausen <lars@metafoo.de>
+ *
+ * Copyright (C) 2016, Frieder Schrempf <frieder.schrempf@kontron.de>
+ * (volume support)
+ *
* PWM beeper driver
*/
+#include <linux/device.h>
#include <linux/input.h>
#include <linux/regulator/consumer.h>
#include <linux/module.h>
@@ -24,10 +29,61 @@ struct pwm_beeper {
unsigned int bell_frequency;
bool suspended;
bool amplifier_on;
+ unsigned int volume;
+ unsigned int *volume_levels;
+ unsigned int max_volume;
};
#define HZ_TO_NANOSECONDS(x) (1000000000UL/(x))
+static ssize_t volume_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct pwm_beeper *beeper = dev_get_drvdata(dev);
+
+ return sprintf(buf, "%d\n", beeper->volume);
+}
+
+static ssize_t max_volume_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct pwm_beeper *beeper = dev_get_drvdata(dev);
+
+ return sprintf(buf, "%d\n", beeper->max_volume);
+}
+
+static ssize_t volume_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ int rc;
+ struct pwm_beeper *beeper = dev_get_drvdata(dev);
+ unsigned int volume;
+
+ rc = kstrtouint(buf, 0, &volume);
+ if (rc)
+ return rc;
+
+ if (volume > beeper->max_volume)
+ return -EINVAL;
+ pr_debug("set volume to %u\n", volume);
+ beeper->volume = volume;
+
+ return count;
+}
+
+static DEVICE_ATTR_RW(volume);
+static DEVICE_ATTR_RO(max_volume);
+
+static struct attribute *pwm_beeper_attributes[] = {
+ &dev_attr_volume.attr,
+ &dev_attr_max_volume.attr,
+ NULL,
+};
+
+static struct attribute_group pwm_beeper_attribute_group = {
+ .attrs = pwm_beeper_attributes,
+};
+
static int pwm_beeper_on(struct pwm_beeper *beeper, unsigned long period)
{
struct pwm_state state;
@@ -37,7 +93,7 @@ static int pwm_beeper_on(struct pwm_beeper *beeper, unsigned long period)
state.enabled = true;
state.period = period;
- pwm_set_relative_duty_cycle(&state, 50, 100);
+ pwm_set_relative_duty_cycle(&state, beeper->volume_levels[beeper->volume], 1000);
error = pwm_apply_state(beeper->pwm, &state);
if (error)
@@ -126,6 +182,7 @@ static int pwm_beeper_probe(struct platform_device *pdev)
struct pwm_state state;
u32 bell_frequency;
int error;
+ size_t size;
beeper = devm_kzalloc(dev, sizeof(*beeper), GFP_KERNEL);
if (!beeper)
@@ -171,6 +228,24 @@ static int pwm_beeper_probe(struct platform_device *pdev)
beeper->bell_frequency = bell_frequency;
+ beeper->max_volume = 4;
+
+ size = sizeof(*beeper->volume_levels) *
+ (beeper->max_volume + 1);
+
+ beeper->volume_levels = devm_kzalloc(&(pdev->dev), size,
+ GFP_KERNEL);
+ if (!beeper->volume_levels)
+ return -ENOMEM;
+
+ beeper->volume_levels[0] = 0;
+ beeper->volume_levels[1] = 80;
+ beeper->volume_levels[2] = 200;
+ beeper->volume_levels[3] = 400;
+ beeper->volume_levels[4] = 5000;
+
+ beeper->volume = beeper->max_volume;
+
beeper->input = devm_input_allocate_device(dev);
if (!beeper->input) {
dev_err(dev, "Failed to allocate input device\n");
@@ -192,8 +267,15 @@ static int pwm_beeper_probe(struct platform_device *pdev)
input_set_drvdata(beeper->input, beeper);
+ error = sysfs_create_group(&pdev->dev.kobj, &pwm_beeper_attribute_group);
+ if (error) {
+ dev_err(&pdev->dev, "Failed to create sysfs group: %d\n", error);
+ return error;
+ }
+
error = input_register_device(beeper->input);
if (error) {
+ sysfs_remove_group(&pdev->dev.kobj, &pwm_beeper_attribute_group);
dev_err(dev, "Failed to register input device: %d\n", error);
return error;
}
@@ -203,6 +285,17 @@ static int pwm_beeper_probe(struct platform_device *pdev)
return 0;
}
+static int pwm_beeper_remove(struct platform_device *pdev)
+{
+ struct pwm_beeper *beeper;
+
+ beeper = platform_get_drvdata(pdev);
+ input_unregister_device(beeper->input);
+ sysfs_remove_group(&pdev->dev.kobj, &pwm_beeper_attribute_group);
+
+ return 0;
+}
+
static int __maybe_unused pwm_beeper_suspend(struct device *dev)
{
struct pwm_beeper *beeper = dev_get_drvdata(dev);
@@ -248,6 +341,7 @@ MODULE_DEVICE_TABLE(of, pwm_beeper_match);
static struct platform_driver pwm_beeper_driver = {
.probe = pwm_beeper_probe,
+ .remove = pwm_beeper_remove,
.driver = {
.name = "pwm-beeper",
.pm = &pwm_beeper_pm_ops,
--
2.39.1
^ permalink raw reply related
* [PATCH v10 1/4] dt-bindings: input: pwm-beeper: Convert txt bindings to yaml
From: Manuel Traut @ 2023-02-01 15:21 UTC (permalink / raw)
To: linux-kernel
Cc: Manuel Traut, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Frieder Schrempf, linux-input, devicetree, Rob Herring
In-Reply-To: <20230201152128.614439-1-manuel.traut@mt.com>
Converts txt binding to new YAML format.
Signed-off-by: Manuel Traut <manuel.traut@mt.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/input/pwm-beeper.txt | 24 ------------
.../devicetree/bindings/input/pwm-beeper.yaml | 39 +++++++++++++++++++
2 files changed, 39 insertions(+), 24 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/pwm-beeper.txt
create mode 100644 Documentation/devicetree/bindings/input/pwm-beeper.yaml
diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.txt b/Documentation/devicetree/bindings/input/pwm-beeper.txt
deleted file mode 100644
index 8fc0e48c20db..000000000000
--- a/Documentation/devicetree/bindings/input/pwm-beeper.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-* PWM beeper device tree bindings
-
-Registers a PWM device as beeper.
-
-Required properties:
-- compatible: should be "pwm-beeper"
-- pwms: phandle to the physical PWM device
-
-Optional properties:
-- amp-supply: phandle to a regulator that acts as an amplifier for the beeper
-- beeper-hz: bell frequency in Hz
-
-Example:
-
-beeper_amp: amplifier {
- compatible = "fixed-regulator";
- gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
-};
-
-beeper {
- compatible = "pwm-beeper";
- pwms = <&pwm0>;
- amp-supply = <&beeper_amp>;
-};
diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.yaml b/Documentation/devicetree/bindings/input/pwm-beeper.yaml
new file mode 100644
index 000000000000..1ebc3a46d934
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/pwm-beeper.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/pwm-beeper.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PWM beeper
+
+maintainers:
+ - Dmitry Torokhov <dmitry.torokhov@gmail.com>
+
+description: Registers a PWM device as beeper.
+
+properties:
+ compatible:
+ const: pwm-beeper
+
+ pwms:
+ maxItems: 1
+
+ amp-supply:
+ description: >
+ regulator that acts as an amplifier for the beeper
+
+ beeper-hz:
+ description: bell frequency in Hz
+
+required:
+ - compatible
+ - pwms
+
+additionalProperties: false
+
+examples:
+ - |
+ beeper {
+ compatible = "pwm-beeper";
+ pwms = <&pwm0>;
+ };
--
2.39.1
^ permalink raw reply related
* [PATCH v10 0/4] input: pwm-beeper: add feature to set volume level
From: Manuel Traut @ 2023-02-01 15:21 UTC (permalink / raw)
To: linux-kernel
Cc: Manuel Traut, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Frieder Schrempf, linux-input, devicetree
This implements volume control for the pwm-beeper via sysfs.
The first patch changes the devicetree documentation from txt to yaml.
The original author of the volume support patches is Frieder Schrempf.
I picked them from this [0] LKML thread from 2017. Since it looks like
his email address changed in the meantime I changed it in the Author
and Signed-off-by, as well as in the copyright statements.
I did some minor changes on the patches that they apply and work with
the current kernel.
checkpatch still reports warnings regarding the changes:
* from txt to yaml of the devicetree documentation:
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
WARNING: DT binding docs and includes should be a separate patch.
* and the introduction of Documentation/ABI/testing/sysfs-devices-pwm-beeper:
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
I am not sure how to fix these warnings. So any suggestion would be helpful.
Changes since v9 [1]:
* [1/4] dt-bindings: input: pwm-beeper: Convert txt bindings to yaml
* added Reviewed-by tag from Rob Herring
* [3/4] dt-bindings: input: pwm-beeper: add volume
* Added missing unit specifier in examples
Changes since v8 [2]:
* yaml devicetree doc:
* reordered patches to introduce dt-bindings before usage
* drop quotes from $id and $schema references
* amp-supply: simplify description
* examples: remove unneeded amp device node
* use -bp suffix for volume-levels and default-volume
* specify default-volume as value instead of pointer into volume-array
* fixup to work with new dt-binding specification
* squash patches as suggested by Frieder
Changes since v7 [3]:
* yaml devicetree doc:
* Use shorter subject
* Fix indent
* Use units
* 'make dt_binding_check' succeeds
* 'make dtbs_check' does not report new errors
* Reworded commit messages avoiding 'this patch' phrase
* Fix wrong indent in [PATCH 5/5 v7] input: pwm-beeper: handle module unloading properly
* Use current date in Documentation/ABI/testing/sysfs-devices-pwm-beeper
* Hopefully fixed my setup that
* mails are CC'ed correctly
* patches are sent as replies to the cover letter
Changes since v6 [4]:
* Convert devicetree binding documentation from txt to yaml
* Use DEVICE_ATTR_[RO|RW] properly
* Change Frieders Mail address
* Added Signed-off and Tested-by statements
* Fix module unloading
Frieder Schrempf (2):
input: pwm-beeper: add feature to set volume via sysfs
input: pwm-beeper: set volume levels by devicetree
Manuel Traut (2):
dt-bindings: input: pwm-beeper: Convert txt bindings to yaml
dt-bindings: input: pwm-beeper: add volume
.../ABI/testing/sysfs-devices-pwm-beeper | 17 +++
.../devicetree/bindings/input/pwm-beeper.txt | 24 ----
.../devicetree/bindings/input/pwm-beeper.yaml | 56 ++++++++
drivers/input/misc/pwm-beeper.c | 135 +++++++++++++++++-
4 files changed, 206 insertions(+), 26 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-devices-pwm-beeper
delete mode 100644 Documentation/devicetree/bindings/input/pwm-beeper.txt
create mode 100644 Documentation/devicetree/bindings/input/pwm-beeper.yaml
[0] https://lore.kernel.org/all/cover.1487323753.git.frieder.schrempf@exceet.de/
[1] https://lore.kernel.org/lkml/20230130135650.1407156-1-manuel.traut@mt.com/
[2] https://lore.kernel.org/lkml/20230126091825.220646-1-manuel.traut@mt.com/
[3] https://lore.kernel.org/all/Y9AIq3cSNzI9T%2FdU@mt.com/
[4] https://lkml.org/lkml/2023/1/24/379
--
2.39.1
^ permalink raw reply
* Re: Dependency on non-existing config I2C_DMI_CORE in commit a2f416bf062a ("HID: multitouch: Add quirks for flipped axes")
From: Benjamin Tissoires @ 2023-02-01 10:42 UTC (permalink / raw)
To: Allen Ballway
Cc: Lukas Bulwahn, linux-input, Jiri Kosina, Jiri Kosina,
Henrik Rydberg, Linux Kernel Mailing List
In-Reply-To: <CAEs41JBMqSCk4U4aQc08DRL5hHDteRmdt1-TGQg0-niko5MF_w@mail.gmail.com>
Hi Allen,
On Tue, Jan 31, 2023 at 3:44 PM Allen Ballway <ballway@chromium.org> wrote:
>
> Hi Lukas,
>
> Thanks for catching this, that's definitely a mistake in my code.
> That was supposed to be CONFIG_I2C_HID_CORE.
>
> Should I send a follow-up patch for this, or another revision for the patch?
> It looks like it hasn't been pulled into the mainline branch yet and I'm not
> familiar with updating it while in a maintainer branch.
I saw that you sent a followup on the initial series, but can you
instead send a fix on top of
https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git/log/?h=for-6.3/multitouch
(hid.git tree, branch for-6.3/multitouch)?
Cheers,
Benjamin
>
> Thanks,
> Allen
>
> On Mon, Jan 30, 2023 at 3:44 AM Lukas Bulwahn <lukas.bulwahn@gmail.com> wrote:
> >
> > Dear Allen,
> >
> > with commit a2f416bf062a ("HID: multitouch: Add quirks for flipped
> > axes"), you add code that is dependent on the CONFIG_I2C_DMI_CORE.
> > However, this config symbol has not been defined anywhere in the
> > kernel repository. Is this a mistake in your code and you intended to
> > refer to another config symbol? Is there another patch to come that
> > adds this config symbol? Or is this a config symbol that only exists
> > in some out-of-tree repository?
> >
> > Something might be odd here, because this code is effectively dead now
> > with being dependent on a non-existing config symbol.
> >
> > Best regards,
> >
> > Lukas
>
^ permalink raw reply
* Re: [PATCH v9 3/4] dt-bindings: input: pwm-beeper: add volume
From: Krzysztof Kozlowski @ 2023-02-01 8:37 UTC (permalink / raw)
To: Manuel Traut, linux-kernel
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Frieder Schrempf, linux-input, devicetree
In-Reply-To: <20230130135650.1407156-4-manuel.traut@mt.com>
On 30/01/2023 14:56, Manuel Traut wrote:
> Adds an array of supported volume levels and a default volume level.
>
> Signed-off-by: Manuel Traut <manuel.traut@mt.com>
> ---
> .../devicetree/bindings/input/pwm-beeper.yaml | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.yaml b/Documentation/devicetree/bindings/input/pwm-beeper.yaml
> index 1ebc3a46d934..ca9efab7efbf 100644
> --- a/Documentation/devicetree/bindings/input/pwm-beeper.yaml
> +++ b/Documentation/devicetree/bindings/input/pwm-beeper.yaml
> @@ -25,6 +25,21 @@ properties:
> beeper-hz:
> description: bell frequency in Hz
>
> + volume-levels-bp:
> + description: >
Does not look like you tested the bindings. Please run `make
dt_binding_check` (see
Documentation/devicetree/bindings/writing-schema.rst for instructions).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] input: cyttsp5: Fix bitmask for touch buttons
From: Alistair @ 2023-02-01 8:00 UTC (permalink / raw)
To: Richard Kjerstadius, linux-input
Cc: Richard Kjerstadius, Linus Walleij, Dmitry Torokhov,
Linux Kernel Mailing List
In-Reply-To: <20230127102903.3317089-1-richard.kjerstadius@teledyne.com>
On Fri, 27 Jan 2023, at 8:29 PM, Richard Kjerstadius wrote:
> Prior to this patch, the bitmask ends up being 0x3, as opposed to 0x1
> which likely was the intention. The erroneous bit results in the driver
> reporting 2 different button activations in designs with 2 or more
> buttons.
>
> To detect which button has been pressed, cyttsp5_btn_attention() uses a
> for loop to iterate through the input buffer, while shifting and
> applying a bitmask to determine the state for each button.
> Unfortunately, when the bitmask is 0x3 and there are multiple buttons,
> this procedure falls apart.
>
> Consider a design with 3 buttons. Pressing the third button will result
> in a call to cyttsp5_btn_attention() with the input buffer containing
> 0x4 (binary 0100). In the first iteration of the for loop cur_btn_state
> will be:
>
> (0x4 >> 0 * 1) & 0x3 = 0x4 & 0x3 = 0x0
>
> This is correct. However, in the next iteration this happens:
>
> (0x4 >> 1 * 1) & 0x3 = 0x2 & 0x3 = 0x2
>
> Which means that a key event for key 1 is generated, even though it's
> not really active. In the third iteration, the loop detects the button
> that was actually pressed:
>
> (0x4 >> 2 * 1) & 0x3 = 0x1 & 0x3 = 0x1
>
> This key event is the only one that should have been detected, but it is
> accompanied by the preceding key. Ensuring the applied mask is 0x1
> solves this problem.
>
> Signed-off-by: Richard Kjerstadius <richard.kjerstadius@teledyne.com>
Reviewed-by: Alistair Francis <alistair@alistair23.me>
Alistair
> ---
> drivers/input/touchscreen/cyttsp5.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/touchscreen/cyttsp5.c b/drivers/input/touchscreen/cyttsp5.c
> index 4a23d6231382..16caffa35dd9 100644
> --- a/drivers/input/touchscreen/cyttsp5.c
> +++ b/drivers/input/touchscreen/cyttsp5.c
> @@ -29,7 +29,7 @@
> #define CY_MAX_INPUT 512
> #define CYTTSP5_PREALLOCATED_CMD_BUFFER 32
> #define CY_BITS_PER_BTN 1
> -#define CY_NUM_BTN_EVENT_ID GENMASK(CY_BITS_PER_BTN, 0)
> +#define CY_NUM_BTN_EVENT_ID GENMASK(CY_BITS_PER_BTN - 1, 0)
>
> #define MAX_AREA 255
> #define HID_OUTPUT_BL_SOP 0x1
> --
> 2.39.0
>
>
^ 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