commit d584221e683bbd173738603b83a315f27d27d043 upstream.
Several MFD child drivers register their class devices directly under
the parent device. This means you cannot blindly do devres conversions
so that deregistration ends up being tied to the parent device,
something which leads to use-after-free on driver unbind when the class
device is released while still being registered.
Fixes: 50154e29e5 ("leds: lm3533: Use devm_led_classdev_register")
Cc: stable <stable@vger.kernel.org> # 4.6
Cc: Amitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6f4aa35744f69ed9b0bf5a736c9ca9b44bc1dcea upstream.
Several MFD child drivers register their class devices directly under
the parent device. This means you cannot blindly do devres conversions
so that deregistration ends up being tied to the parent device,
something which leads to use-after-free on driver unbind when the class
device is released while still being registered.
Fixes: eed16255d6 ("leds: da903x: Use devm_led_classdev_register")
Cc: stable <stable@vger.kernel.org> # 4.6
Cc: Amitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a0972fff09479dd09b731360a3a0b09e4fb4d415 upstream.
Several MFD child drivers register their class devices directly under
the parent device. This means you cannot use devres so that
deregistration ends up being tied to the parent device, something which
leads to use-after-free on driver unbind when the class device is
released while still being registered.
Fixes: 11e1bbc116 ("leds: lm36274: Introduce the TI LM36274 LED driver")
Cc: stable <stable@vger.kernel.org> # 5.3
Cc: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 47a459ecc800a17109d0c496a4e21e478806ee40 upstream.
Several MFD child drivers register their class devices directly under
the parent device. This means you cannot blindly do devres conversions
so that deregistration ends up being tied to the parent device,
something which leads to use-after-free on driver unbind when the class
device is released while still being registered.
Fixes: 8d3b6a4001 ("leds: wm831x-status: Use devm_led_classdev_register")
Cc: stable <stable@vger.kernel.org> # 4.6
Cc: Amitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f7e6b19bc76471ba03725fe58e0c218a3d6266c3 upstream.
When doing a "write" ioctl call, properly check that we have permissions
to do so before copying anything from userspace or anything else so we
can "fail fast". This includes also covering the MEMWRITE ioctl which
previously missed checking for this.
Cc: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Vignesh Raghavendra <vigneshr@ti.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[rw: Fixed locking issue]
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ebfdfeeae8c01fcb2b3b74ffaf03876e20835d2d upstream.
vgacon_scrollback_update() always leaves enbough room in the scrollback
buffer for the next call, but if the console size changed that room
might not actually be enough, and so we need to re-check.
The check should be in the loop since vgacon_scrollback_cur->tail is
updated in the loop and count may be more than 1 when triggered by CSI M,
as Jiri's PoC:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/ioctl.h>
#include <fcntl.h>
int main(int argc, char** argv)
{
int fd = open("/dev/tty1", O_RDWR);
unsigned short size[3] = {25, 200, 0};
ioctl(fd, 0x5609, size); // VT_RESIZE
write(fd, "\e[1;1H", 6);
for (int i = 0; i < 30; i++)
write(fd, "\e[10M", 5);
}
It leads to various crashes as vgacon_scrollback_update writes out of
the buffer:
BUG: unable to handle page fault for address: ffffc900001752a0
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
RIP: 0010:mutex_unlock+0x13/0x30
...
Call Trace:
n_tty_write+0x1a0/0x4d0
tty_write+0x1a0/0x2e0
Or to KASAN reports:
BUG: KASAN: slab-out-of-bounds in vgacon_scroll+0x57a/0x8ed
This fixes CVE-2020-14331.
Reported-by: 张云海 <zhangyunhai@nsfocus.com>
Reported-by: Yang Yingliang <yangyingliang@huawei.com>
Reported-by: Kyungtae Kim <kt0755@gmail.com>
Fixes: 15bdab959c ([PATCH] vgacon: Add support for soft scrollback)
Cc: stable@vger.kernel.org
Cc: linux-fbdev@vger.kernel.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Solar Designer <solar@openwall.com>
Cc: "Srivatsa S. Bhat" <srivatsa@csail.mit.edu>
Cc: Anthony Liguori <aliguori@amazon.com>
Cc: Yang Yingliang <yangyingliang@huawei.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Yunhai Zhang <zhangyunhai@nsfocus.com>
Link: https://lore.kernel.org/r/9fb43895-ca91-9b07-ebfd-808cf854ca95@nsfocus.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 55c7549819e438f40a3ef1d8ac5c38b73390bcb7 upstream.
When running `make coccicheck` in report mode using the
add_namespace.cocci file, it will fail for files that contain
MODULE_LICENSE. Those match the replacement precondition, but spatch
errors out as virtual.ns is not set.
In order to fix that, add the virtual rule nsdeps and only do search and
replace if that rule has been explicitly requested.
In order to make spatch happy in report mode, we also need a dummy rule,
as otherwise it errors out with "No rules apply". Using a script:python
rule appears unrelated and odd, but this is the shortest I could come up
with.
Adjust scripts/nsdeps accordingly to set the nsdeps rule when run trough
`make nsdeps`.
Suggested-by: Julia Lawall <julia.lawall@inria.fr>
Fixes: c7c4e29fb5 ("scripts: add_namespace: Fix coccicheck failed")
Cc: YueHaibing <yuehaibing@huawei.com>
Cc: jeyu@kernel.org
Cc: cocci@systeme.lip6.fr
Cc: stable@vger.kernel.org
Signed-off-by: Matthias Maennich <maennich@google.com>
Reported-by: Shuah Khan <skhan@linuxfoundation.org>
Acked-by: Julia Lawall <julia.lawall@inria.fr>
Link: https://lore.kernel.org/r/20200604164145.173925-1-maennich@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit beb4ee6770a89646659e6a2178538d2b13e2654e upstream.
smk_write_relabel_self() frees memory from the task's credentials with
no locking, which can easily cause a use-after-free because multiple
tasks can share the same credentials structure.
Fix this by using prepare_creds() and commit_creds() to correctly modify
the task's credentials.
Reproducer for "BUG: KASAN: use-after-free in smk_write_relabel_self":
#include <fcntl.h>
#include <pthread.h>
#include <unistd.h>
static void *thrproc(void *arg)
{
int fd = open("/sys/fs/smackfs/relabel-self", O_WRONLY);
for (;;) write(fd, "foo", 3);
}
int main()
{
pthread_t t;
pthread_create(&t, NULL, thrproc, NULL);
thrproc(NULL);
}
Reported-by: syzbot+e6416dabb497a650da40@syzkaller.appspotmail.com
Fixes: 38416e5393 ("Smack: limited capability for changing process label")
Cc: <stable@vger.kernel.org> # v4.4+
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4b836a1426cb0f1ef2a6e211d7e553221594f8fc upstream.
Binder is designed such that a binder_proc never has references to
itself. If this rule is violated, memory corruption can occur when a
process sends a transaction to itself; see e.g.
<https://syzkaller.appspot.com/bug?extid=09e05aba06723a94d43d>.
There is a remaining edgecase through which such a transaction-to-self
can still occur from the context of a task with BINDER_SET_CONTEXT_MGR
access:
- task A opens /dev/binder twice, creating binder_proc instances P1
and P2
- P1 becomes context manager
- P2 calls ACQUIRE on the magic handle 0, allocating index 0 in its
handle table
- P1 dies (by closing the /dev/binder fd and waiting a bit)
- P2 becomes context manager
- P2 calls ACQUIRE on the magic handle 0, allocating index 1 in its
handle table
[this triggers a warning: "binder: 1974:1974 tried to acquire
reference to desc 0, got 1 instead"]
- task B opens /dev/binder once, creating binder_proc instance P3
- P3 calls P2 (via magic handle 0) with (void*)1 as argument (two-way
transaction)
- P2 receives the handle and uses it to call P3 (two-way transaction)
- P3 calls P2 (via magic handle 0) (two-way transaction)
- P2 calls P2 (via handle 1) (two-way transaction)
And then, if P2 does *NOT* accept the incoming transaction work, but
instead closes the binder fd, we get a crash.
Solve it by preventing the context manager from using ACQUIRE on ref 0.
There shouldn't be any legitimate reason for the context manager to do
that.
Additionally, print a warning if someone manages to find another way to
trigger a transaction-to-self bug in the future.
Cc: stable@vger.kernel.org
Fixes: 457b9a6f09 ("Staging: android: add binder driver")
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Jann Horn <jannh@google.com>
Reviewed-by: Martijn Coenen <maco@android.com>
Link: https://lore.kernel.org/r/20200727120424.1627555-1-jannh@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 254503a2b186caa668a188dbbd7ab0d25149c0a5 upstream.
The drm/omap driver was fixed to correct an issue where using a
divider of 32 breaks the DSS despite the TRM stating 32 is a valid
number. Through experimentation, it appears that 31 works, and
it is consistent with the value used by the drm/omap driver.
This patch fixes the divider for fbdev driver instead of the drm.
Fixes: f76ee892a9 ("omapfb: copy omapdss & displays for omapfb")
Cc: <stable@vger.kernel.org> #4.5+
Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Dave Airlie <airlied@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
[b.zolnierkie: mark patch as applicable to stable 4.5+ (was 4.9+)]
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630182636.439015-1-aford173@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 75bbd2ea50ba1c5d9da878a17e92eac02fe0fd3a upstream.
Check `num_rsp` before using it as for-loop counter.
Cc: stable@vger.kernel.org
Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 51c19bf3d5cfaa66571e4b88ba2a6f6295311101 upstream.
Check upon `num_rsp` is insufficient. A malformed event packet with a
large `num_rsp` number makes hci_extended_inquiry_result_evt() go out
of bounds. Fix it.
This patch fixes the following syzbot bug:
https://syzkaller.appspot.com/bug?id=4bf11aa05c4ca51ce0df86e500fce486552dc8d2
Reported-by: syzbot+d8489a79b781849b9c46@syzkaller.appspotmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 11536442a3b4e1de6890ea5e805908debb74f94a upstream.
The variable authmode can be uninitialized. The danger would be if
it equals to _WPA_IE_ID_ (0xdd) or _WPA2_IE_ID_ (0x33). We can avoid
this by setting it to zero instead. This is the approach that was
used in the rtl8723bs driver.
Fixes: 7b464c9fa5 ("staging: r8188eu: Add files for new driver - part 4")
Co-developed-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200728072153.9202-1-dinghao.liu@zju.edu.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3e338d3c95c735dc3265a86016bb4c022ec7cadc upstream.
syzbot report [1] describes a deadlock when write operation against an
ashmem fd executed at the time when ashmem is shrinking its cache results
in the following lock sequence:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(fs_reclaim);
lock(&sb->s_type->i_mutex_key#13);
lock(fs_reclaim);
lock(&sb->s_type->i_mutex_key#13);
kswapd takes fs_reclaim and then inode_lock while generic_perform_write
takes inode_lock and then fs_reclaim. However ashmem does not support
writing into backing shmem with a write syscall. The only way to change
its content is to mmap it and operate on mapped memory. Therefore the race
that lockdep is warning about is not valid. Resolve this by introducing a
separate lockdep class for the backing shmem inodes.
[1]: https://lkml.kernel.org/lkml/0000000000000b5f9d059aa2037f@google.com/
Reported-by: syzbot+7a0d9d0b26efefe61780@syzkaller.appspotmail.com
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
Link: https://lore.kernel.org/r/20200730192632.3088194-1-surenb@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 80982c7e834e5d4e325b6ce33757012ecafdf0bb upstream.
Some ioctls via OSS sequencer API may race and lead to UAF when the
port create and delete are performed concurrently, as spotted by a
couple of syzkaller cases. This patch is an attempt to address it by
serializing the ioctls with the existing register_mutex.
Basically OSS sequencer API is an obsoleted interface and was designed
without much consideration of the concurrency. There are very few
applications with it, and the concurrent performance isn't asked,
hence this "big hammer" approach should be good enough.
Reported-by: syzbot+1a54a94bd32716796edd@syzkaller.appspotmail.com
Reported-by: syzbot+9d2abfef257f3e2d4713@syzkaller.appspotmail.com
Suggested-by: Hillf Danton <hdanton@sina.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200804185815.2453-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7fe3530427e52dd53cd7366914864e29215180a4 upstream.
The ca0113 command had the wrong group_id, 0x48 when it should've been
0x30. The front microphone selection should now work.
Signed-off-by: Connor McAdams <conmanx360@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200803002928.8638-3-conmanx360@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a00dc409de455b64e6cb2f6d40cdb8237cdb2e83 upstream.
When the ZxR headphone gain control was added, the ca0132_switch_get
function was not updated, which meant that the changes to the control
state were not saved when entering/exiting alsamixer.
Signed-off-by: Connor McAdams <conmanx360@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200803002928.8638-1-conmanx360@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit cc5edb1bd3f7bfe450f767b12423f6673822427b upstream.
Add a new quirk ID for the Recon3D, as tested by me.
Signed-off-by: Connor McAdams <conmanx360@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200803002928.8638-2-conmanx360@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f1ec5be17b9aafbc5f573da023850566b43d8e5e upstream.
There are several Loongson-3 based laptops produced by CZC or Lemote,
they use alc269/alc662 codecs and need specific pin-tables, this patch
add their pin-tables.
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1596360400-32425-1-git-send-email-chenhc@lemote.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 07c9983b567d0ef33aefc063299de95a987e12a8 upstream.
This reverts commit 9a6418487b56 ("ALSA: hda: call runtime_allow()
for all hda controllers").
The reverted patch already introduced some regressions on some
machines:
- on gemini-lake machines, the error of "azx_get_response timeout"
happens in the hda driver.
- on the machines with alc662 codec, the audio jack detection doesn't
work anymore.
Fixes: 9a6418487b56 ("ALSA: hda: call runtime_allow() for all hda controllers")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208511
Cc: <stable@vger.kernel.org>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Link: https://lore.kernel.org/r/20200803064638.6139-1-hui.wang@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
when ctx->sqo_mm is zero, io_sq_wq_submit_work() frees 'req'
without deleting it from 'task_list'. After that, 'req' is
accessed in io_ring_ctx_wait_and_kill() which lead to
a use-after-free.
Signed-off-by: Guoyu Huang <hgy5945@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Liu reports that he can trigger a NULL pointer dereference with
IORING_OP_SENDMSG, by changing the sqe->opcode after we've validated
that the previous opcode didn't need a file and didn't assign one.
Ensure we validate and read the opcode only once.
Reported-by: Liu Yong <pkfxxxing@gmail.com>
Tested-by: Liu Yong <pkfxxxing@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ec37198acca7b4c17b96247697406e47aafe0605 upstream.
I've confirmed that the ASMedia ASM1142 has the same problem as the
ASM2142/ASM3142, in that it too reports that it supports 64-bit DMA
addresses when in fact it does not. As with the ASM2142/ASM3142, this
can cause problems on systems where the upper bits matter, and adding
the XHCI_NO_64BIT_SUPPORT quirk completely fixes the issue.
Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Forest Crossman <cyrozap@gmail.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200728042408.180529-3-cyrozap@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1841cb255da41e87bed9573915891d056f80e2e7 upstream.
Not all ASMedia host controllers have a device ID that matches its part
number. #define some of these IDs to make it clearer at a glance which
chips require what quirks.
Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Forest Crossman <cyrozap@gmail.com>
Link: https://lore.kernel.org/r/20200728042408.180529-2-cyrozap@gmail.com
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 17a82716587e9d7c3b246a789add490b2b5dcab6 upstream.
In previous patches that added support for new iowarrior devices, the
handling of the report size was not done correct.
Fix that up and update the copyright date for the driver
Reworked from an original patch written by Christoph Jung.
Fixes: bab5417f5f01 ("USB: misc: iowarrior: add support for the 100 device")
Fixes: 5f6f8da2d7b5 ("USB: misc: iowarrior: add support for the 28 and 28L devices")
Fixes: 461d8deb26a7 ("USB: misc: iowarrior: add support for 2 OEMed devices")
Cc: stable <stable@kernel.org>
Reported-by: Christoph Jung <jung@codemercs.com>
Link: https://lore.kernel.org/r/20200726094939.1268978-1-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 90c91dfb86d0ff545bd329d3ddd72c147e2ae198 upstream.
Kan and Andi reported that we fail to kill rotation when the flexible
events go empty, but the context does not. XXX moar
Fixes: fd7d55172d ("perf/cgroups: Don't rotate events for cgroups unnecessarily")
Reported-by: Andi Kleen <ak@linux.intel.com>
Reported-by: Kan Liang <kan.liang@linux.intel.com>
Tested-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20200305123851.GX2596@hirez.programming.kicks-ass.net
Cc: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d2a4309c1ab6df424b2239fe2920d6f26f808d17 upstream.
When running qmi-firmware-update on the Sierra Wireless EM7305 in a Toshiba
laptop, it changed product ID to 0x9062 when entering QDL mode:
usb 2-4: new high-speed USB device number 78 using xhci_hcd
usb 2-4: New USB device found, idVendor=1199, idProduct=9062, bcdDevice= 0.00
usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 2-4: Product: EM7305
usb 2-4: Manufacturer: Sierra Wireless, Incorporated
The upgrade could complete after running
# echo 1199 9062 > /sys/bus/usb-serial/drivers/qcserial/new_id
qcserial 2-4:1.0: Qualcomm USB modem converter detected
usb 2-4: Qualcomm USB modem converter now attached to ttyUSB0
Signed-off-by: Erik Ekman <erik@kryo.se>
Link: https://lore.kernel.org/r/20200717185118.3640219-1-erik@kryo.se
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The abi for a number of core kernel structures changed due to the 6GHz
feature being backported, so update the .xml file to reflect this.
Leaf changes summary: 146 artifacts changed
Changed leaf types summary: 19 leaf types changed
Removed/Changed/Added functions summary: 3 Removed, 124 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
3 Removed functions:
[D] 'function int ieee80211_channel_to_frequency(int, nl80211_band)'
[D] 'function int ieee80211_frequency_to_channel(int)'
[D] 'function ieee80211_channel* ieee80211_get_channel(wiphy*, int)'
124 functions with some sub-type change:
'enum nl80211_attrs at nl80211.h:2469:1' changed:
type size hasn't changed
1 enumerator insertion:
'nl80211_attrs::NL80211_ATTR_HE_6GHZ_CAPABILITY' value '289'
3 enumerator changes:
'nl80211_attrs::NL80211_ATTR_MAX' from value '288' to '289' at nl80211.h:2472:1
'nl80211_attrs::NUM_NL80211_ATTR' from value '289' to '290' at nl80211.h:2472:1
'nl80211_attrs::__NL80211_ATTR_AFTER_LAST' from value '289' to '290' at nl80211.h:2472:1
2 impacted interfaces
'struct cfg80211_ap_settings at cfg80211.h:1036:1' changed (indirectly):
type size hasn't changed
there are data member changes:
type 'struct cfg80211_chan_def' of 'cfg80211_ap_settings::chandef' changed:
type size hasn't changed
1 data member insertion:
'u16 cfg80211_chan_def::freq1_offset', at offset 224 (in bits) at cfg80211.h:638:1
69 impacted interfaces
one impacted interface
'struct cfg80211_chan_def at cfg80211.h:606:1' changed:
details were reported earlier
'struct cfg80211_csa_settings at cfg80211.h:1082:1' changed (indirectly):
type size hasn't changed
there are data member changes:
type 'struct cfg80211_chan_def' of 'cfg80211_csa_settings::chandef' changed, as reported earlier
one impacted interface
'struct cfg80211_ibss_params at cfg80211.h:2475:1' changed (indirectly):
type size hasn't changed
there are data member changes:
type 'struct cfg80211_chan_def' of 'cfg80211_ibss_params::chandef' changed, as reported earlier
one impacted interface
'struct cfg80211_pmsr_request at cfg80211.h:3302:1' changed (indirectly):
type size hasn't changed
there are data member changes:
'cfg80211_pmsr_request_peer cfg80211_pmsr_request::peers[]' has *some* difference - please report as a bug
2 impacted interfaces
'struct cfg80211_pmsr_request_peer at cfg80211.h:3279:1' changed (indirectly):
type size hasn't changed
there are data member changes:
type 'struct cfg80211_chan_def' of 'cfg80211_pmsr_request_peer::chandef' changed, as reported earlier
2 impacted interfaces
'struct ieee80211_bss_conf at mac80211.h:608:1' changed (indirectly):
type size hasn't changed
there are data member changes:
type 'struct cfg80211_chan_def' of 'ieee80211_bss_conf::chandef' changed, as reported earlier
22 impacted interfaces
'struct ieee80211_chanctx_conf at mac80211.h:225:1' changed (indirectly):
type size hasn't changed
there are data member changes:
type 'struct cfg80211_chan_def' of 'ieee80211_chanctx_conf::def' changed, as reported earlier
type 'struct cfg80211_chan_def' of 'ieee80211_chanctx_conf::min_def' changed, as reported earlier
22 impacted interfaces
'struct ieee80211_channel at cfg80211.h:147:1' changed:
type size hasn't changed
1 data member insertion:
'u16 ieee80211_channel::freq_offset', at offset 64 (in bits) at cfg80211.h:151:1
there are data member changes:
'u16 ieee80211_channel::hw_value' offset changed from 64 to 80 (in bits) (by +16 bits)
75 impacted interfaces
'struct ieee80211_channel_switch at mac80211.h:1538:1' changed (indirectly):
type size hasn't changed
there are data member changes:
type 'struct cfg80211_chan_def' of 'ieee80211_channel_switch::chandef' changed, as reported earlier
one impacted interface
'struct ieee80211_conf at mac80211.h:1504:1' changed (indirectly):
type size hasn't changed
there are data member changes:
type 'struct cfg80211_chan_def' of 'ieee80211_conf::chandef' changed, as reported earlier
31 impacted interfaces
'struct ieee80211_hw at mac80211.h:2469:1' changed (indirectly):
type size hasn't changed
there are data member changes:
type 'struct ieee80211_conf' of 'ieee80211_hw::conf' changed, as reported earlier
31 impacted interfaces
'struct ieee80211_sband_iftype_data at cfg80211.h:341:1' changed:
type size changed from 464 to 480 (in bits)
1 data member insertion:
'ieee80211_he_6ghz_capa ieee80211_sband_iftype_data::he_6ghz_capa', at offset 456 (in bits) at cfg80211.h:348:1
54 impacted interfaces
'struct ieee80211_vif at mac80211.h:1609:1' changed (indirectly):
type size hasn't changed
there are data member changes:
type 'struct ieee80211_bss_conf' of 'ieee80211_vif::bss_conf' changed, as reported earlier
22 impacted interfaces
'struct mesh_setup at cfg80211.h:1850:1' changed (indirectly):
type size hasn't changed
there are data member changes:
type 'struct cfg80211_chan_def' of 'mesh_setup::chandef' changed, as reported earlier
one impacted interface
'struct ocb_setup at cfg80211.h:1878:1' changed (indirectly):
type size hasn't changed
there are data member changes:
type 'struct cfg80211_chan_def' of 'ocb_setup::chandef' changed, as reported earlier
one impacted interface
'struct station_parameters at cfg80211.h:1201:1' changed:
type size changed from 1216 to 1280 (in bits)
1 data member insertion:
'const ieee80211_he_6ghz_capa* station_parameters::he_6ghz_capa', at offset 1216 (in bits) at cfg80211.h:1261:1
one impacted interface
'struct wireless_dev at cfg80211.h:5011:1' changed (indirectly):
type size hasn't changed
there are data member changes:
type 'struct cfg80211_chan_def' of 'wireless_dev::preset_chandef' changed, as reported earlier
type 'struct cfg80211_chan_def' of 'wireless_dev::chandef' changed, as reported earlier
54 impacted interfaces
Bug: 163110886
Cc: Vamsi Krishna <vamsin@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ic791893fb3919ab2c9bd1bbeb478e6cb98d1deab
On 6 GHz band, HE capabilities must be available for all of
the interface types, otherwise we shouldn't use 6 GHz. Check
this.
Bug: 163110886
Link: https://lore.kernel.org/r/20200528213443.5881cb3c8c4a.I583b54172f91f98d44af64a16c5826fe458cbb27@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Change-Id: I6091b10c85d34eb7ec8324a8e6d5ea3e1efecedc
(cherry picked from commit f438136528482f98535889c9a6f99bbacdd92870)
Signed-off-by: Vamsi Krishna <vamsin@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
On the 6 GHz band, HE should be used, but without any direct HT/VHT
capabilities, instead the HE 6 GHz band capabilities will capture
the relevant information. Reject HT/VHT capabilities here.
Bug: 163110886
Link: https://lore.kernel.org/r/20200528213443.bfe89c35459a.Ibba5e066fa0087fd49d13cfee89d196ea0c68ae2@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
(cherry picked from commit 461ce35d5535c1479384f67fcf4bfc3f3610edca)
Change-Id: Ife9644cc1c2533255863593861a3e79eb5dac56b
Signed-off-by: Vamsi Krishna <vamsin@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
If a 6 GHz channel exists, then we can probably safely assume that
the device actually supports it, and then it should support most
bandwidths.
This will probably need to be extended to check the interface type
and then dig into the HE capabilities for that though, to have the
correct bandwidth check.
Bug: 163110886
Link: https://lore.kernel.org/r/20200528213443.d4864ef52e92.I82f09b2b14a56413ce20376d09967fe954a033eb@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Change-Id: Ia393e0ef876ca6251e58dd546fa336eeaf9a398e
(cherry picked from commit ba8f6a037f790147438173029799f54c9d3065f2)
Signed-off-by: Vamsi Krishna <vamsin@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
On 6 GHz, the 6 GHz capabilities element should be added, do that.
Bug: 163110886
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
[add commit message]
Link: https://lore.kernel.org/r/20200528213443.8ee764f0cde0.I2b0c66b60e11818c97c9803e04a6a197c6376243@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Change-Id: Iba5daa73817072fdea78cd37c1f30b0323deca6f
(cherry picked from commit 2ad2274c58ee2dcaf9ccde5c63ff30f59b138f77)
Signed-off-by: Vamsi Krishna <vamsin@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Construct HE 6 GHz band capability element (IEEE 802.11ax/D6.0,
9.4.2.261) for association request and mesh beacon. The 6 GHz
capability information is passed by driver through iftypes caps.
Bug: 163110886
Signed-off-by: Rajkumar Manoharan <rmanohar@codeaurora.org>
Link: https://lore.kernel.org/r/1589399105-25472-7-git-send-email-rmanohar@codeaurora.org
[handle SMPS, adjust for previous patches, reserve SKB space properly,
change to handle SKB directly]
Link: https://lore.kernel.org/r/20200528213443.643aa8101111.I3f9747c1147480f65445f13eda5c4a5ed4e86757@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Change-Id: I0f4de7b83bd2e7e0f33a294589478ad0d0802b6e
(cherry picked from commit 24a2042cb22fdfc7feef0df9622f0d9d71b8ced1)
Signed-off-by: Vamsi Krishna <vamsin@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
These capabilities cover what would otherwise be transported
in HT/VHT capabilities, but only a subset thereof that is
actually needed on 6 GHz with HE already present. Expose the
capabilities to userspace, drivers are expected to set them
as using the 6 GHz band (currently) requires HE capability.
Bug: 163110886
Link: https://lore.kernel.org/r/20200528213443.244cd5cb9db8.Icd8c773277a88c837e7e3af1d4d1013cc3b66543@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Change-Id: I08e42cb07c3cb1faacb325888ca77bcd2c91507b
(cherry picked from commit 223952177296c34d9c8de9cde33204caffe55725)
Signed-off-by: Vamsi Krishna <vamsin@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Add the HE extended element IDs and the definitions for the
HE 6 GHz band capabilities element, from Draft 5.0.
Bug: 163110886
Link: https://lore.kernel.org/r/20200528213443.1a6689fe093f.Ifdc5400fb01779351354daf38663ebeea03c9ad9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Change-Id: I1de902cc0c4b57c57308641fb87244b5b7eb23e4
(cherry picked from commit 8b30808d9be4183fab17f0b0e68eea88c94ff15a)
Signed-off-by: Vamsi Krishna <vamsin@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Add some code to obtain and parse the 6 GHz operation field
inside the HE operation element.
While at it, fix the required length using sizeof() the new
struct, which is 5 instead of 4 now.
Bug: 163110886
Link: https://lore.kernel.org/r/20200528213443.42ca72c45ca9.Id74bc1b03da9ea6574f9bc70deeb60dfc1634359@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Change-Id: I3044bbe8adee64db9021924f4bf21812566cec07
(cherry picked from commit 821273a5a502eebaae005557907d122d1e9b7b98)
Signed-off-by: Vamsi Krishna <vamsin@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This allows identifying whether or not a channel is a PSC
(preferred scanning channel).
Bug: 163110886
Link: https://lore.kernel.org/r/20200528213443.414363ecf62c.Ic15e681a0e249eab7350a06ceb582cca8bb9a080@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Change-Id: Ia0b369ead18ce1d1e585df9467d680be4aa8adef
(cherry picked from commit afbc9c9e8bfe71e8bd12a8c01bedd969fbab8f0e)
Signed-off-by: Vamsi Krishna <vamsin@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
The 6GHz band does not have regulatory approval yet, but things are
moving forward. However, that has led to a change in the channelization
of the 6GHz band which has been accepted in the 11ax specification. It
also fixes a missing MHZ_TO_KHZ() macro for 6GHz channels while at it.
This change is primarily thrown in to discuss how to deal with it.
I noticed ath11k adding 6G support with old channelization and ditto
for iw. It probably involves changes in hostapd as well.
Bug: 163110886
Cc: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
Cc: Jouni Malinen <jouni@w1.fi>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://lore.kernel.org/r/edf07cdd-ad15-4012-3afd-d8b961a80b69@broadcom.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Change-Id: Iefd17472ad19dfaa0479bf4890bffc21b8f940e7
(cherry picked from commit d1a1646c0de7b0083d42a1ada72a3ec243bfcc6d)
Signed-off-by: Vamsi Krishna <vamsin@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
The updates to change to kHz frequencies and the 6 GHz
additions evidently overlapped (or rather, I didn't see
it when applying the latter), so the 6 GHz is broken.
Fix this.
Bug: 163110886
Fixes: 934f4c7dd3a5 ("cfg80211: express channels with a KHz component")
Link: https://lore.kernel.org/r/20200529140425.1bf824f6911b.I4a1174916b8f5965af4366999eb9ffc7a0347470@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Change-Id: If0507c87b898302c091de22f69714eb11eada75b
(cherry picked from commit 5e9cf0f0a3e98992184442de24253fe1b9c40f2e)
Signed-off-by: Vamsi Krishna <vamsin@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Some bands (S1G) define channels centered on a non-integer
MHz. Give ieee80211_channel and cfg80211_chan_def a
freq_offset component where the final frequency can be
expressed as:
MHZ_TO_KHZ(chan->center_freq) + chan->freq_offset;
Also provide some helper functions to do the frequency
conversion and test for equality.
Retain the existing interface to frequency and channel
conversion helpers, and expose new ones which handle
frequencies in units of KHz.
Some internal functions (net/wireless/chan.c) pass around
a frequency value. Convert these to units of KHz.
mesh, ibss, wext, etc. are currently ignored.
Bug: 163110886
Signed-off-by: Thomas Pedersen <thomas@adapt-ip.com>
Link: https://lore.kernel.org/r/20200402011810.22947-3-thomas@adapt-ip.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Change-Id: I058afb696c69e7047d5573bda334d04f684f1215
(cherry picked from commit 934f4c7dd3a544bb8000f7436f1f0e12e04ebc37)
Signed-off-by: Vamsi Krishna <vamsin@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Set flush cti for both etr and etb. Set FlushandStop bit to default
value of FFCR in enablement function. Config the correct trigger number
of flush and reset cti for both etr and etb.
Change-Id: Idee3802e5a69aca521a6259f9936ddb8361a87d4
Signed-off-by: Tao Zhang <taozha@codeaurora.org>
Signed-off-by: Mao Jinlong <jinlmao@codeaurora.org>
setup_fifo_xfer/setup_gsi_xfer api may fail while transfer
preparation, return error to the client in such case instead
of advancing with the erroneous transfer to prevent unpredictable
transfer scenarios.
Change-Id: I559fbc1dd26248c639cd0f0e1844dafbada703ce
Signed-off-by: Mukesh Kumar Savaliya <msavaliy@codeaurora.org>
For I2C and SPI, CMD_DONE should be enabled only in fifo mode for
transfer completion. Disable CMD_DONE for DMA mode and cancel cmd
to avoid race condition between cmd_done, dma_done and cmd_done,
cancel_irq.
Change-Id: Ib1dc10d3e17c2b3df17097f2a4bc60b159d76709
Signed-off-by: Mukesh Kumar Savaliya <msavaliy@codeaurora.org>
Reinitialize fifo cur_wr, cur_rd and gi2c->xfer for every transfer.
Add "MSM_GPI_QUP_FW_ERROR" event to callback event list. Dump GSI
registers in case of Channel RESET failure.
Change-Id: I243fb140d663fccd79676bdc6760702809fb4d68
Signed-off-by: Mukesh Kumar Savaliya <msavaliy@codeaurora.org>
Signed-off-by: Vipin Deep Kaur <vkaur@codeaurora.org>
This is a squash of the following two commits taken from msm-4.14
1) commit <e629221afd65> ("Perf: core: create/delete shared
kernel events").
Frequently drivers want to monitor some event like L2 misses
and cycles+instructions. If more than 1 driver wants to monitor
the same event and the event attributes are the same then we
can create just one instance of the event and let drivers
share the event. Add shared event create and delete
routines.
2) commit <f0453c73e167> ("perf: Add support for user and
kernel event sharing").
The ARM PMU counters are limited in number. Even for counting
similar events, the PMU driver allocates a new counter. Hence,
counters configured to count similar events are shared. This
was only possible for the kernel clients, but not for user-space
clients. Hence, as an extension to this, the kernel and the
user-space are now able to share the similar events. The counters
can be shared between user-space only clients, kernel only clients,
and among user-space and kernel clients. The kernel and user's
attr->type (hardware/raw) and attr->config should be same for them to
share the same counter.
Additionally,
Current enablement of kernel event sharing is not GKI
compliant. Make the sharing of kernel events configurable
so it can be enabled only on non-GKI builds.
Add dependency for enablement of sharing of user events on
enablement of sharing of kernel events.
Change-Id: I784db5a20968ba7fca20659186f23890bf6cc503
Signed-off-by: Patrick Fay <pfay@codeaurora.org>
Signed-off-by: Raghavendra Rao Ananta <rananta@codeaurora.org>
Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org>
[kaushalk@codeaurora.org: Make event sharing configurable, add dependencies]
Signed-off-by: Kaushal Kumar <kaushalk@codeaurora.org>
Update the DMA RX FSM reset sequence as per HPG recommendations.
Currently driver calling msm_geni_serial_rx_fsm_rst() even in case of
RX inactive. RX FSM reset command generates RX_RESET_DONE bit. There
is a possible race between polling for RX_RESET and ISR for RX_RESET.
This can result into introducing delay during BT open.
Fix this by updating RX FSM reset sequence only in case of
cancel command timeout.
Change-Id: I90532aa72fdad462a616eded3e149bc6b721fe7b
Signed-off-by: Chandana Kishori Chiluveru <cchiluve@codeaurora.org>
