), I think your series should be good to
go if the STATE_DEACTIVATED fix has been verified independently.
Thanks!
--
Jiri Kosina
SUSE Labs
+++
drivers/hid/hid-cp2112.c | 22 +--
drivers/hid/hid-google-hammer.c| 2 ++
drivers/hid/hid-ids.h | 2 ++
drivers/hid/wacom_wac.c| 8 +++
8 files changed, 59 insertions(+), 20 deletions(-)
--
Jiri Kosina
SUSE Labs
(out of possibly many)
userspace-visible sysfs entry has been created during module insertion and
made available to userspace, there is never going to be rollback happening
that'd be removing that first sysfs entry again?
Thanks,
--
Jiri Kosina
SUSE Labs
n't handle error handling during
modprobe (which, one would hope, is supported), and should be fixed.
If there is a particular issue in kernel dynamic linker that causes crash
on module removal, we'd better off fixing it. Is there one such that makes
you claim module removal unsupported?
Thanks,
ng to have Yunsheng Lin's (CCing) fix [1] tested in the
coming days. If it works, then we can consider proceeding with it,
otherwise I am all for reverting the whole NOLOCK stuff.
[1]
https://lore.kernel.org/linux-can/1616641991-14847-1-git-send-email-linyunsh...@huawei.com/T/#u
--
Jiri Kosina
SUSE Labs
with back in 2019.
Unless there are
(a) any nice ideas how to solve this in an elegant way without
(re-)introducing extra spinlock (Cong's fix) or
(b) any objections to revert as per the argumentation above
I'll be happy to send a revert of the whole NOLOCK implementation next
week.
Thanks,
--
Jiri Kosina
SUSE Labs
quot;) added a generic infrastructure to achieve the same.
> Replace our bespoke solution with the generic one.
>
> Reviewed-by: Jens Axboe
> Reviewed-by: Petr Mladek
> Signed-off-by: Miroslav Benes
Pushed out to livepatching#for-5.13/signal.
--
Jiri Kosina
SUSE Labs
lows a single
> HID device to be connected and, furthermore, only allows a single output
> report, specifically one for the caps lock LED. This is implemented in
> the second patch.
>
> See the commit messages of the respective patches for more details.
Now queued in hid.git#for-5.13/surface
gt; >
> > Thanks,
> >
>
> [ CC Chris Murphy ]
>
> A week ago Chris sent an email to linux-wireless with pointing to:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=212297
>
> AFAICS, that is the same bug.
Indeed, it is. Chris, if you want to provide your Tested-by:, the (yet
unmerged) patch to test can be found here:
https://patchwork.kernel.org/project/linux-wireless/patch/nycvar.yfh.7.76.2103021125430.12...@cbobk.fhfr.pm/
--
Jiri Kosina
SUSE Labs
the maintainers, but as far as I am concerned, it
> > > > definitely is a 5.12 material, as it fixes real scheduling bug.
> > >
> > > Yes, please take this to w-d. We have a similar patch internally, but
> > > there's a backlog and it will take me some time to get to it. I'll
> > > resolve eventual conflicts when time comes.
> >
> > Ok, can I have your ack for patchwork?
>
> Sorry, forgot that.
>
> Acked-by: Luca Coelho
Sorry for sounding like broken record :) but this fix is still not in any
tree as far as I can tell. And it's fixing real scheduling in atomic bug.
Thanks,
--
Jiri Kosina
SUSE Labs
goto out;
> > > + }
> >
> > This patch is completely broken and breaks bonding functionality
> > altogether for me.
>
> Is Linus's tree also broken for you? This showed up in 5.12-rc3.
Yes, it is.
--
Jiri Kosina
SUSE Labs
On Fri, 19 Mar 2021, Jiri Kosina wrote:
> > [ Upstream commit 2055a99da8a253a357bdfd359b3338ef3375a26c ]
> >
> > When slave is NULL or slave_ops->ndo_neigh_setup is NULL, no error
> > return code of bond_neigh_init() is assigned.
> > To fix this bug, ret is ass
= slave->dev->netdev_ops;
> - if (!slave_ops->ndo_neigh_setup)
> + if (!slave_ops->ndo_neigh_setup) {
> + ret = -EINVAL;
> goto out;
> + }
This patch is completely broken and breaks bonding functionality
altogether for me.
--
Jiri Kosina
SUSE Labs
vers/hid/intel-ish-hid/ishtp/hbm.h | 1 +
> 2 files changed, 4 insertions(+), 3 deletions(-)
Applied, thanks.
--
Jiri Kosina
SUSE Labs
gt; + msgs[0].len);
> return -EOPNOTSUPP;
> }
Applied, thanks Dan.
--
Jiri Kosina
SUSE Labs
On Tue, 16 Mar 2021, Marcel Holtmann wrote:
> > Fixes: eab2404ba798 ("Bluetooth: Add BT_PHY socket option")
> > Signed-off-by: Jiri Kosina
> > ---
> > net/bluetooth/hci_conn.c | 4
> > 1 file changed, 4 deletions(-)
>
> patch has been
From: Jiri Kosina
Commit eab2404ba798 ("Bluetooth: Add BT_PHY socket option") added a
dependency between socket lock and hci_dev->lock that could lead to
deadlock.
It turns out that hci_conn_get_phy() is not in any way relying on hdev
being immutable during the runtime of
On Thu, 4 Mar 2021, Jiri Kosina wrote:
> ==
> WARNING: possible circular locking dependency detected
> 5.12.0-rc1-00026-g73d464503354 #10 Not tainted
> --
> bluetoothd
with the functionality it provides.
> >
> > Tested-by: Aaron Jones (FTDI-UK)
>
> Aaron, thanks for giving it a try - much appreciated!
I have now queued the driver in hid.git#for-5.13/ft260. Thanks,
--
Jiri Kosina
SUSE Labs
On Sat, 13 Mar 2021, Kalle Valo wrote:
> >> > From: Jiri Kosina
> >> >
> >> > It's possible for iwl_pcie_enqueue_hcmd() to be called with hard IRQs
> >> > disabled (e.g. from LED core). We can't enable BHs in such a situation.
> >> &
On Mon, 8 Mar 2021, Jiri Kosina wrote:
> > From: Jiri Kosina
> >
> > It's possible for iwl_pcie_enqueue_hcmd() to be called with hard IRQs
> > disabled (e.g. from LED core). We can't enable BHs in such a situation.
> >
> > Turn the unconditional BH-enab
look good to
> > me.
> Sorry, I missed this series.
> No objection for taking these patches.
Thanks. Applied with your Acked-by:
If you disagree with that interpretation of your statement above, please
holler :)
Thanks,
--
Jiri Kosina
SUSE Labs
m_wac_finger_slot(struct wacom_wac
> *wacom_wac,
> !wacom_wac->shared->is_touch_on) {
> if (!wacom_wac->shared->touch_down)
> return;
> - prox = 0;
> + prox = false;
> }
Applied, thanks.
--
Jiri Kosina
SUSE Labs
hid_device *hdev,
> struct hid_input *hi)
>
> if (input_register_device(data->input2)) {
> input_free_device(input2);
> + ret = -ENOENT;
> goto exit;
> }
> }
Applied, thanks.
--
Jiri Kosina
SUSE Labs
to firmware
> to be compatible with the previous version.
Could you please make the changelog more verbose -- namely what
user-visible issue this is fixing?
Thanks.
--
Jiri Kosina
SUSE Labs
n reporting
>
> drivers/hid/hid-input.c | 47 +---
> drivers/hid/hid-multitouch.c | 18 --
> 2 files changed, 55 insertions(+), 10 deletions(-)
Benjamin, this patchset looks good to me; do you have any objections on
queuing it for 5.13?
Thanks,
--
Jiri Kosina
SUSE Labs
g duplicate events on driver level? Do you happen to know why
> they occur in the first place? Are any other headsets affected?
Makes one wonder how the Windows driver is dealing with this indeed.
Anyway, as there doesn't seem to be better cure available for now, I have
applied the patch. Thanks,
--
Jiri Kosina
SUSE Labs
On Sat, 6 Feb 2021, Uwe Kleine-König wrote:
> A remove callback is only ever called for a bound device. So there is no
> need to check for device or driver being NULL.
Srinivas, any objections to this patchset? The cleanups look good to me.
Thanks,
--
Jiri Kosina
SUSE Labs
ERBALL 0x503c
> #define USB_DEVICE_ID_GOOGLE_MAGNEMITE 0x503d
> #define USB_DEVICE_ID_GOOGLE_MOONBALL0x5044
> +#define USB_DEVICE_ID_GOOGLE_DON 0x5050
>
> #define USB_VENDOR_ID_GOTOP 0x08f2
> #define USB_DEVICE_ID_SUPER_Q2 0x007f
Applied, thanks.
--
Jiri Kosina
SUSE Labs
aptop here before
> > > merging, but I'd like to know if delaying to 5.13 is OK or if we need
> > > this in 5.12.
> >
> > I'd like to do it the standard way and have it bake in for-next to see if
> > it really doesn't break anything, so unless there are convicing arguments
> > for 5.12-rcX, I'd rathre queue this for 5.13.
>
> For the record, I'm not in hurry with this, up to you how to proceed.
> Thanks!
Queued in for-5.13/i2c-hid. Thanks,
--
Jiri Kosina
SUSE Labs
On Tue, 2 Mar 2021, Jiri Kosina wrote:
> From: Jiri Kosina
>
> It's possible for iwl_pcie_enqueue_hcmd() to be called with hard IRQs
> disabled (e.g. from LED core). We can't enable BHs in such a situation.
>
> Turn the unconditional BH-enable/BH-disable code into
RAX: ffda RBX: 0019 RCX: 7fb73df33eee
RDX: 000e RSI: 0112 RDI: 0018
RBP: R08: 7fffcfbbbf44 R09:
R10: 7fffcfbbbf3c R11: 0203 R12:
R13: 0018 R14: 0000
big issue :) So let it be.
BTW, how about the other fix I sent? It's also fixing a real functional
issue, so it IMHO is a -rc material
https://lore.kernel.org/linux-wireless/nycvar.yfh.7.76.2103021125430.12...@cbobk.fhfr.pm/
Thanks,
--
Jiri Kosina
SUSE Labs
;) part from the patch
subject.
--
Jiri Kosina
SUSE Labs
ork or lore, hopefully it shows
> up later.
Not sure about patchwork, but vger had hiccup (again) earlier today,
everything depending on the ML traffic is probably slower.
lore has it now though:
https://lore.kernel.org/lkml/nycvar.yfh.7.76.2103021134060.12...@cbobk.fhfr.pm/
Thanks,
--
Jiri Kosina
SUSE Labs
From: Jiri Kosina
We can't call netif_napi_add() with rxq-lock held, as there is a potential
for deadlock as spotted by lockdep (see below). rxq->lock is not
protecting anything over the netif_napi_add() codepath anyway, so let's
drop it just before calling into N
From: Jiri Kosina
It's possible for iwl_pcie_enqueue_hcmd() to be called with hard IRQs
disabled (e.g. from LED core). We can't enable BHs in such a situation.
Turn the unconditional BH-enable/BH-disable code into
hardirq-disable/conditional-enable.
This fixes the warning below.
WARNING
ire+0x277/0x3d0
[ 21.919327] iwl_mvm_send_cmd+0x32/0x80 [iwlmvm]
[ 21.923616] iwl_mvm_led_set+0xc2/0xe0 [iwlmvm]
codepath, but I'll look into it separately.
From: Jiri Kosina
Subject: [PATCH] iwlwifi: don't call netif_napi_add() with rxq->lock held
We can't call netif_napi_add() w
On Mon, 1 Mar 2021, Jiri Kosina wrote:
> I am getting the splat below with Linus' tree as of today (5.11-rc1,
> fe07bfda2fb). I haven't started to look into the code yet, but apparently
> this has been already reported by Heiner here:
>
> https://www.spinics.net/lists
Hi,
I am getting the splat below with Linus' tree as of today (5.11-rc1,
fe07bfda2fb). I haven't started to look into the code yet, but apparently
this has been already reported by Heiner here:
https://www.spinics.net/lists/linux-wireless/msg208353.html
so before I start digging deep
> this in 5.12.
I'd like to do it the standard way and have it bake in for-next to see if
it really doesn't break anything, so unless there are convicing arguments
for 5.12-rcX, I'd rathre queue this for 5.13.
Thanks,
--
Jiri Kosina
SUSE Labs
ystation.c
create mode 100644 drivers/hid/i2c-hid/i2c-hid-acpi.c
create mode 100644 drivers/hid/i2c-hid/i2c-hid-of-goodix.c
create mode 100644 drivers/hid/i2c-hid/i2c-hid-of.c
delete mode 100644 include/linux/platform_data/i2c-hid.h
--
Jiri Kosina
SUSE Labs
e already reviewed on the
> linux-input LKML, but without the LED class bits.
FWIW, as discussed elsewhere, I am fully in favor of this solution.
Thanks!
--
Jiri Kosina
SUSE Labs
line below. I'll fix that whilst applying
> unless you need to respin for some reason.
>
> I'm fine with the series, but looking for an Ack from Jiri
> for the HID header changes.
Acked-by: Jiri Kosina
Thanks,
--
Jiri Kosina
SUSE Labs
On Fri, 22 Jan 2021, Elia Devito wrote:
> Battery status is reported for the HP Spectre X360 Convertible 15-df0xxx
> even if it does not have a battery. Prevent it to always report the
> battery as low.
>
> Signed-off-by: Elia Devito
Applied, thanks.
--
Jiri Kosina
SUSE Labs
"amd_sfh_quirks_get_sensor_mask"
> - struct dmi_system_id -> const struct dmi_system_id
Nehal, Sandeep, can you please review this patchset? Thanks.
--
Jiri Kosina
SUSE Labs
nic when seeing a G Pro X Superlight
> connected to the Powerplay receiver and won't send any input events to
> userspace! The kernel will warn about this so the issue should be easy
> to identify, but it is still very worrying how hard it will fail :(
Applied to for-5.11/upstream-fixes, thanks Filipe.
--
Jiri Kosina
SUSE Labs
On Mon, 8 Feb 2021, Srinivas Pandruvada wrote:
> > Added Tiger Lake H PCI device ID to the supported device list.
> >
> > Signed-off-by: You-Sheng Yang
> Acked-by: Srinivas Pandruvada
Applied, thanks.
--
Jiri Kosina
SUSE Labs
wouldn't be the
> prefered approach :P
Benjamin, do you have any other idea how to accomplish this without this
kind of spaghetti-style conditions?
If not, I am tempted to apply the patch as is.
Thanks,
--
Jiri Kosina
SUSE Labs
gt; https://github.com/libratbag/libratbag/issues/1124
>
> Fixes: e400071a805d6 ("HID: logitech-dj: add the G602 receiver")
> Cc:
> Signed-off-by: Filipe Laíns
> ---
>
> Changes in v2:
> - added missing Fixes: anc Cc: tags
Applied, thanks Filipe.
--
Jiri Kosina
SUSE Labs
gt; https://github.com/libratbag/libratbag/issues/1124
>
> Signed-off-by: Filipe Laíns
Given this is a regression, could you please add proper Fixes: and Cc:
stable tags?
Thank you,
--
Jiri Kosina
SUSE Labs
/hid-roccat-arvo.c:149:8-16: WARNING: use scnprintf or
> sprintf.
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
Appplied.
--
Jiri Kosina
SUSE Labs
t; struct hid_device *hdev = to_hid_device(dev);
> struct wacom *wacom = hid_get_drvdata(hdev);
>
> - return snprintf(buf, PAGE_SIZE, "%i\n", wacom->wacom_wac.bt_high_speed);
> + return sysfs_emit(buf, "%i\n", wacom->wacom_wac.bt_high_speed);
> }
Applied, thanks.
--
Jiri Kosina
SUSE Labs
86 7952 256 278946cf6 drivers/hid/hid-lg-g15.o
>
> After:
>text data bss dec hex filename
> 19543 8016 256 278156ca7 drivers/hid/hid-lg-g15.o
>
> (gcc version 10.2.0)
>
> Signed-off-by: Colin Ian King
Applied.
--
Jiri Kosina
SUSE Labs
> inject metadata work again, despite current libblkid. (Fortunately, most
> use cdrom these days.)
-stable we can do only after the commit lands in Linus' tree.
Once that happens, I believe we can just as the version we have in
openSUSE 15.2 kernel for now as-is:
https://github.com/openSUSE/kernel-source/commit/ab10a7db5f5b721bf2145e6eab9358a751dd0e5b
--
Jiri Kosina
SUSE Labs
he
patch?
Thanks,
--
Jiri Kosina
SUSE Labs
gt; This is not a problem on detachable base attach, as the device,
> by itself, sends a report after it is booted up.
>
> Signed-off-by: Nicolas Boichat
Applied, thanks Nicolas.
--
Jiri Kosina
SUSE Labs
ts with
> keyboard report, if one has already been processed.
>
> Signed-off-by: Dmitry Torokhov
> ---
Queued in for-5.12/core. Thanks,
--
Jiri Kosina
SUSE Labs
drivers/hid/hid-multitouch.c | 3 ++-
drivers/hid/wacom_sys.c | 7 ---
drivers/hid/wacom_wac.h | 2 +-
3 files changed, 7 insertions(+), 5 deletions(-)
--
Jiri Kosina
SUSE Labs
On Tue, 19 Jan 2021, Randy Dunlap wrote:
> Clean up kernel-doc notation in 2 files
> and in drivers/hid/hid-quirks.c.
>
> Cc: Jiri Kosina
> Cc: Benjamin Tissoires
> Cc: linux-in...@vger.kernel.org
>
> rebase & resend:
> [PATCH 1/2 v2] HID: correct kernel-doc no
On Fri, 22 Jan 2021, Jiri Kosina wrote:
> > > This series adds a document, mainly written by Mark Rutland, which
> > > makes explicit the requirements for implementing reliable stacktrace
> > > in order to aid architectures adding this feature. It also updates
&
togreg branch of iio.git and pushed out as testing for
> > the autobuilders to see if they can break it.
> Hi Jiri,
>
> Just realised this is in HID rather than IIO. I hope you don't mind as
> it's now deep in a tree I'd rather not rebase.
>
> Sorry about that.
No worries, feel free to keep it in your tree.
Thanks,
--
Jiri Kosina
SUSE Labs
g tree unless there are any
additional last-minutes comments.
Thanks,
--
Jiri Kosina
SUSE Labs
From: Jiri Kosina
This issue was originally fixed in 09954bad4 ("floppy: refactor open()
flags handling").
The fix as a side-effect, however, introduce issue for open(O_ACCMODE)
that is being used for ioctl-only open. I wrote a fix for that, but
instead of it being merged, f
On Thu, 21 Jan 2021, Denis Efremov wrote:
> > From: Jiri Kosina
> > Subject: [PATCH v2] floppy: reintroduce O_NDELAY fix
> >
> > Originally fixed in 09954bad4 ("floppy: refactor open() flags handling")
> > then reverted for unknown reason in f2791
On Thu, 21 Jan 2021, Jiri Kosina wrote:
> I am currently waiting for confirmation by the original reporter that the
> patch below fixes the issue.
... a now a patch that actually compiles :) (made a mistake when
forward-porting from the older kernel on which this has been reported).
still keeping the original O_NDELAY bug fixed.
Cc: sta...@vger.kernel.org # v4.5+
Reported-by: Wim Osterholt
Tested-by: Wim Osterholt
Signed-off-by: Jiri Kosina
=
Fixes: 09954bad4 ("floppy: refactor open() flags handling")
Fixes: f2791e7ead ("Revert "floppy: refactor open(
On Mon, 25 Jul 2016, Jens Axboe wrote:
> > From: Jiri Kosina
> >
> > Commit 09954bad4 ("floppy: refactor open() flags handling"), as a
> > side-effect, causes open(/dev/fdX, O_ACCMODE) to fail. It turns out that
> > this is being used setfdprm userspace fo
but I guess that is C for
> you right? Names don't scale well with code quantity :P
Alright ... thug life :) Let's just keep it the way it is.
> > > > Could you please use standard kernel commenting style here?
> > >
> > > Oops, sorry. Will do :)
I have adjusted the
PIDs.
> Also note that vendor id 0x12ba is used by a variety of different rhythm
> controllers on the ps3.
>
> Signed-off-by: Sanjay Govind
>
> Fix some incorrect constants after a refactor
I have removed the sentence above and applied, thanks.
--
Jiri Kosina
SUSE Labs
the same size.
Now applied, sorry for the delay and thanks for the fix.
--
Jiri Kosina
SUSE Labs
/hid/hid-uclogic-params.c | 2 +-
drivers/hid/hid-wiimote-core.c | 2 +-
drivers/hid/wacom_sys.c | 35 +---
13 files changed, 55 insertions(+), 12 deletions(-)
--
Jiri Kosina
SUSE Labs
to Linus shortly.
--
Jiri Kosina
SUSE Labs
On Thu, 24 Dec 2020, Nicolas Boichat wrote:
> This forces reading the base folded status anytime the device is
> probed.
Could you please provide a little bit more verbose changelog (namely what
is the actual problem this patch is fixing)? Thanks.
--
Jiri Kosina
SUSE Labs
for this hotkey, learned the device will send
> with 0x11 as the report ID and 0x1 as the value when the key is pressed
> down.
>
> This patch maps the event as KEY_RFKILL.
>
> Signed-off-by: Jian-Hong Pan
> ---
> v2: Remove the duplicated key pressed check.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
f them, we are just better off with the
> > > battery
> > > + percentage. */
> >
> > Could you please use standard kernel commenting style here?
>
> Oops, sorry. Will do :)
Thanks,
--
Jiri Kosina
SUSE Labs
On Mon, 4 Jan 2021, Filipe Laíns wrote:
> Tested. The device gets correctly exported to userspace and I can see
> mouse and keyboard events.
>
> Signed-off-by: Filipe Laíns
Applied to hid.git#for-5.11/upstream-fixes.
--
Jiri Kosina
SUSE Labs
& (1 << (n - 1)) ? value | (~0U << n) : value;
>
> Fixes: dde5845a529f ("[PATCH] Generic HID layer - code split")
> Signed-off-by: Randy Dunlap
> Reported-by: syzbot+1e911ad71dd4ea72e...@syzkaller.appspotmail.com
> Cc: Jiri Kosina
> Cc: Benjamin Tissoires
&
age() ?
[ ... snip ... ]
> + /* if the device supports state of charge (battery percentage) we won't
> +export the battery level information. there are 4 possible battery
> +levels and they all are optional, this means that the device might
> +not support any of them, we are just better off with the battery
> +percentage. */
Could you please use standard kernel commenting style here?
Thanks,
--
Jiri Kosina
SUSE Labs
mean that the person does actually
still have that hardware, and we could ask him to test with hid-generic.
Thanks,
--
Jiri Kosina
SUSE Labs
rspace via setkeycode() (udev/systemd
is shipping a lot of such mappings already -- see evdev/keyboard
definitions in hwdb).
Thanks,
--
Jiri Kosina
SUSE Labs
On Tue, 15 Dec 2020, t...@redhat.com wrote:
> From: Tom Rix
>
> See Documentation/core-api/printk-formats.rst.
> h should no longer be used in the format specifier for printk.
>
> Signed-off-by: Tom Rix
Applied, thanks.
--
Jiri Kosina
SUSE Labs
On Tue, 15 Dec 2020, t...@redhat.com wrote:
> From: Tom Rix
>
> See Documentation/core-api/printk-formats.rst.
> h should no longer be used in the format specifier for printk.
>
> Signed-off-by: Tom Rix
Applied this one too. Thanks Tom.
--
Jiri Kosina
SUSE Labs
t; drivers/hid/intel-ish-hid/ipc/hw-ish.h | 1 +
> drivers/hid/intel-ish-hid/ipc/ipc.c | 27 +
> drivers/hid/intel-ish-hid/ipc/pci-ish.c | 54 -
> 3 files changed, 81 insertions(+), 1 deletion(-)
Applied to hid.git#for-5.12/intel-ish.
--
Jiri Kosina
SUSE Labs
t; drivers/hid/intel-ish-hid/ipc/hw-ish.h | 1 +
> drivers/hid/intel-ish-hid/ipc/ipc.c | 27 +
> drivers/hid/intel-ish-hid/ipc/pci-ish.c | 54 -
> 3 files changed, 81 insertions(+), 1 deletion(-)
Srinivas, can I please get your Acked-by / Reviewed-by for this? Thanks,
--
Jiri Kosina
SUSE Labs
nueabi-ld: hid-sony.c:(.text+0x900): undefined reference to
> `crc32_le'
> arm-linux-gnueabi-ld: drivers/hid/hid-sony.o:hid-sony.c:(.text+0x4408): more
> undefined references to `crc32_le' follow
>
> Signed-off-by: Arnd Bergmann
Applied, thanks Arnd.
--
Jiri Kosina
SUSE Labs
nd the variable name to dma_addr for consistency.
>
> Fixes: 4b2c53d93a4b ("SFH:Transport Driver to add support of AMD Sensor
> Fusion Hub (SFH)")
> Signed-off-by: Arnd Bergmann
Good catch; queued for 5.11, thanks.
--
Jiri Kosina
SUSE Labs
On Wed, 30 Dec 2020, Kai-Heng Feng wrote:
> Pointstick and its left/right buttons on HP EliteBook 850 G7 need
> multi-input quirk to work correctly.
Applied to hid.git#for-5.11/upstream-fixes. Thanks,
--
Jiri Kosina
SUSE Labs
On Mon, 28 Dec 2020, Randy Dunlap wrote:
> Make editing corrections to all files in Documentation/hid/.
>
> Cc: Jiri Kosina
> Cc: Benjamin Tissoires
> Cc: linux-in...@vger.kernel.org
> Cc: Jonathan Cameron
> Cc: Srinivas Pandruvada
> Cc: linux-...@vger.kernel.org
>
y these sensors
> based on manufacturer and serial number property in the report.
>
> This change is identifying hinge sensor when the manufacturer is "INTEL".
> This creates a platform device so that a sensor driver can be loaded to
> process these sensors.
>
> S
the devices in question are EOL, and GTCO is not
> willing to extend resources for that, so let's simply remove the driver.
Acked-by: Jiri Kosina
>
> Note that our HID support has greatly improved over the last 10 years,
> we may also consider reverting 6f8d9e26e7de ("hid-co
unsign
> > usages = max_t(unsigned, parser->local.usage_index,
> > parser->global.report_count);
> >
> > - field = hid_register_field(report, usages, parser->global.report_count);
> > + field = hid_register_field(report, usages);
> > if (!field)
> > return 0;
> >
> > --
> > 2.29.2.576.ga3fc446d84-goog
> >
>
> Hi Jiri and Benjamin,
>
> This is a friendly reminder in case this got lost in your inbox.
Hi Will,
I am planning to merge it once the merge window is over.
--
Jiri Kosina
SUSE Labs
for V470 bluetooth mouse
HID: ite: Add support for Acer S1002 keyboard-dock
Jing Xiangfeng (1):
HID: intel-ish-hid: Remove unnecessary assignment to variable rv
Jiri Kosina (2):
HID: SFH: Add documentation
HID: elecom: drop stray comment
Julian Sax (1):
HID: i2c-hid
On Wed, 25 Nov 2020, Pascal Giard wrote:
> This commit adds support for the Guitar Hero Live PS3 and Wii U dongles.
Applied, thanks Pascal.
--
Jiri Kosina
SUSE Labs
n_fixup(hdev, rdesc, *rsize, 8);
> > + /*mouse_button_fixup(hdev, rdesc, *rsize, 13, 15, 21, 31, 8);*/
>
> I'm very very sorry, I noticed that I've forgotten to remove this
> commented-out line...
> This "13, 15, 21, 31" line should be removed completely.
No worries, I've dropped that one already. Thanks,
--
Jiri Kosina
SUSE Labs
nks. I'll merge that one, I promise :) Sorry for not
having catched this in v1 already.
--
Jiri Kosina
SUSE Labs
for a report descriptor.
>
> Add parameters to `mouse_button_fixup` function, in order to support
> fixing report descriptors for more models.
I have applied both patches, thank you.
--
Jiri Kosina
SUSE Labs
BIT(17)
> +#define GHL_GUITAR_CONTROLLER BIT(18)
Hi Pascal,
thanks for fixing the previous version. This one looks good to me, I just
have one remaining question -- why do we need both quirks here? Given the
particular VID/PID gets both of them set anyway (and only that VID/PID),
and the code is shared, what is the point of consuming the extra bit?
Thanks,
--
Jiri Kosina
SUSE Labs
data bss dec hex filename
> 204377 42832 576 247785 3c7e9 drivers/hid/wacom_old.ko
> 204240 42064 576 246880 3c460 drivers/hid/wacom_new.ko
Applied, thanks Rikard.
--
Jiri Kosina
SUSE Labs
unknown;
>
> default: goto unknown;
This makes my eyes hurt :) But adding the annotation would be ugly as
well, so let me just take it as-is.
Thanks,
--
Jiri Kosina
SUSE Labs
1 - 100 of 6650 matches
Mail list logo
