- 07 Dec, 2021 36 commits
-
-
Cai Huoqing authored
use SPDX-License-Identifier instead of a verbose license text Link: https://lore.kernel.org/linux-media/20210916020006.8497-1-caihuoqing@baidu.com CC: Mauro Carvalho Chehab <mchehab@kernel.org>, <linux-media@vger.kernel.org>, <linux-kernel@vger.kernel.org> Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Krzysztof Kozlowski authored
The devices 0x187f,0x0202 and 0x187f,0x0301 are already on the list. Link: https://lore.kernel.org/linux-media/20210917092132.19576-1-krzysztof.kozlowski@canonical.comSigned-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Mauro Carvalho Chehab authored
Using stack-allocated pointers for USB message data don't work. This driver is almost OK with that, except for the I2C read logic. Fix it by using a temporary read buffer, just like on all other calls to m920x_read(). Link: https://lore.kernel.org/all/ccc99e48-de4f-045e-0fe4-61e3118e3f74@mida.se/ Reported-by: rkardell@mida.se Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Uwe Kleine-König authored
An spi remove callback is never called with an spi_device pointer that is NULL. Also it is only called for devices that probed successfully. As cxd2880_spi_probe() always sets driver data, spi_get_drvdata() cannot be NULL. Also the return value of spi remove callbacks is ignored anyway and not freeing resources in .remove() is a bad idea. Link: https://lore.kernel.org/linux-media/20211012153945.2651412-8-u.kleine-koenig@pengutronix.de Cc: Mark Brown <broonie@kernel.org>, kernel@pengutronix.de, linux-media@vger.kernel.org, linux-spi@vger.kernel.org Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Uwe Kleine-König authored
If disabling the hardware fails the driver propagates the error code to the i2c core. However this only results in a generic error message; the device still disappears. So instead emit a message that better describes the actual problem than the i2c core's "remove failed (ESOMETHING), will be ignored" and return 0 to suppress the generic message. Link: https://lore.kernel.org/linux-media/20211026194010.109029-1-u.kleine-koenig@pengutronix.de Cc: linux-media@vger.kernel.org, kernel@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Daniel Kamil Kozar authored
The module currently prints only "Rafael Micro r820t successfully identified" when successfully loaded, which might be misleading as the module actually supports various chip types. Link: https://lore.kernel.org/linux-media/20211119234401.271193-1-dkk089@gmail.com Cc: linux-kernel@vger.kernel.org, Daniel Kamil Kozar <dkk089@gmail.com> Signed-off-by: Daniel Kamil Kozar <dkk089@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Colin Ian King authored
There is a spelling mistake in a dev_dbg message. Fix it. Link: https://lore.kernel.org/linux-media/20211123090645.165299-1-colin.i.king@gmail.com Cc: kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Robert Schlabbach authored
Commit e955f959 ("media: si2157: Better check for running tuner in init") completely broke the "warm" tuner detection of the si2157 driver due to a simple endian error: The Si2157 CRYSTAL_TRIM property code is 0x0402 and needs to be transmitted LSB first. However, it was inserted MSB first, causing the warm detection to always fail and spam the kernel log with tuner initialization messages each time the DVB frontend device was closed and reopened: [ 312.215682] si2157 16-0060: found a 'Silicon Labs Si2157-A30' [ 312.264334] si2157 16-0060: firmware version: 3.0.5 [ 342.248593] si2157 16-0060: found a 'Silicon Labs Si2157-A30' [ 342.295743] si2157 16-0060: firmware version: 3.0.5 [ 372.328574] si2157 16-0060: found a 'Silicon Labs Si2157-A30' [ 372.385035] si2157 16-0060: firmware version: 3.0.5 Also, the reinitializations were observed disturb _other_ tuners on multi-tuner cards such as the Hauppauge WinTV-QuadHD, leading to missed or errored packets when one of the other DVB frontend devices on that card was opened. Fix the order of the property code bytes to make the warm detection work again, also reducing the tuner initialization message in the kernel log to once per power-on, as well as fixing the interference with other tuners. Link: https://lore.kernel.org/linux-media/trinity-2a86eb9d-6264-4387-95e1-ba7b79a4050f-1638392923493@3c-app-gmx-bap03 Fixes: e955f959 ("media: si2157: Better check for running tuner in init") Reported-by: Robert Schlabbach <robert_s@gmx.net> Signed-off-by: Robert Schlabbach <robert_s@gmx.net> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Colin Ian King authored
Pointer tsin is being assigned a value that is never read. The assignment is redundant and can be removed. Link: https://lore.kernel.org/linux-media/20211205003745.227491-1-colin.i.king@gmail.com Cc: kernel-janitors@vger.kernel.org Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Akira Yokosawa authored
The beginning part of the "existing HSV/HSL formats" table (line 7742) reads: .. raw:: latex \begingroup \tiny \setlength{\tabcolsep}{2pt} However, the ending part (line 7834) reads: .. raw:: latex \normalsize Fix the imbalance by replacing the \normalsize with \endgroup. Note: Actually, the imbalance is harmless and just results in an informative message near the bottom of userspace-api.log: (\end occurred inside a group at level 1) ### semi simple group (level 1) entered at line 70696 (\begingroup) ### bottom level Link: https://lore.kernel.org/linux-media/b3eeec4d-1a34-0a1a-3097-1ddea3b5f1c8@gmail.comSigned-off-by: Akira Yokosawa <akiyks@gmail.com> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Tsuchiya Yuto authored
There are two occurrences where the variable 'asd' is dereferenced before check. Fix this issue by using the variable after the check. Link: https://lore.kernel.org/linux-media/20211122074122.GA6581@kili/ Link: https://lore.kernel.org/linux-media/20211201141904.47231-1-kitakar@gmail.comReported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Colin Ian King authored
Don't populate the array idx_map on the stack but instead make it static const. Also makes the object code smaller by 16 bytes. Link: https://lore.kernel.org/linux-media/20211129230626.549090-1-colin.i.king@gmail.comSigned-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Dafna Hirschfeld authored
In function vb2_set_plane_payload, report if the given bytesused is bigger than the buffer size, and clamp it to the buffer size. Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Dafna Hirschfeld authored
In many places the bytesused field of struct vb2_buffer is set directly. Replace that with the function call vb2_set_plane_payload Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
The cec_devnode struct has a lock meant to serialize access to the fields of this struct. This lock is taken during device node (un)registration and when opening or releasing a filehandle to the device node. When the last open filehandle is closed the cec adapter might be disabled by calling the adap_enable driver callback with the devnode.lock held. However, if during that callback a message or event arrives then the driver will call one of the cec_queue_event() variants in cec-adap.c, and those will take the same devnode.lock to walk the open filehandle list. This obviously causes a deadlock. This is quite easy to reproduce with the cec-gpio driver since that uses the cec-pin framework which generated lots of events and uses a kernel thread for the processing, so when adap_enable is called the thread is still running and can generate events. But I suspect that it might also happen with other drivers if an interrupt arrives signaling e.g. a received message before adap_enable had a chance to disable the interrupts. This patch adds a new mutex to serialize access to the fhs list. When adap_enable() is called the devnode.lock mutex is held, but not devnode.lock_fhs. The event functions in cec-adap.c will now use devnode.lock_fhs instead of devnode.lock, ensuring that it is safe to call those functions from the adap_enable callback. This specific issue only happens if the last open filehandle is closed and the physical address is invalid. This is not something that happens during normal operation, but it does happen when monitoring CEC traffic (e.g. cec-ctl --monitor) with an unconfigured CEC adapter. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: <stable@vger.kernel.org> # for v5.13 and up Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
The en/disable_irq() functions keep track of the 'depth': i.e. if interrupts are disabled twice, then it needs to enable_irq() calls to enable them again. The cec-pin framework didn't take this into accound and could disable irqs multiple times, and it expected that a single enable_irq() would enable them again. Move all calls to en/disable_irq() to the kthread where it is easy to keep track of the current irq state and ensure that multiple en/disable_irq calls never happen. If interrupts where disabled twice, then they would never turn on again, leaving the CEC adapter in a dead state. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Fixes: 865463fc (media: cec-pin: add error injection support) Cc: <stable@vger.kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
This field is only set, but never used. Drop it. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Rikard Falkeborn authored
The only usage of the v4l2_m2m_ops structs is to pass their address to v4l2_m2m_init() which takes a pointer to const struct v4l2_m2m_ops as argument. Make them const to allow the compiler to put them in read-only memory. Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Zhou Qingyang authored
In mxb_attach(dev, info), saa7146_vv_init() is called to allocate a new memory for dev->vv_data. saa7146_vv_release() will be called on failure of mxb_probe(dev). There is a dereference of dev->vv_data in saa7146_vv_release(), which could lead to a NULL pointer dereference on failure of saa7146_vv_init(). Fix this bug by adding a check of saa7146_vv_init(). This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_VIDEO_MXB=m show no new warnings, and our static analyzer no longer warns about this code. Fixes: 03b1930e ("V4L/DVB: saa7146: fix regression of the av7110/budget-av driver") Signed-off-by: Zhou Qingyang <zhou1615@umn.edu> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Zhou Qingyang authored
In hexium_attach(dev, info), saa7146_vv_init() is called to allocate a new memory for dev->vv_data. In hexium_detach(), saa7146_vv_release() will be called and there is a dereference of dev->vv_data in saa7146_vv_release(), which could lead to a NULL pointer dereference on failure of saa7146_vv_init() according to the following logic. Both hexium_attach() and hexium_detach() are callback functions of the variable 'extension', so there exists a possible call chain directly from hexium_attach() to hexium_detach(): hexium_attach(dev, info) -- fail to alloc memory to dev->vv_data | in saa7146_vv_init(). | | hexium_detach() -- a dereference of dev->vv_data in saa7146_vv_release() Fix this bug by adding a check of saa7146_vv_init(). This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_VIDEO_HEXIUM_ORION=m show no new warnings, and our static analyzer no longer warns about this code. Signed-off-by: Zhou Qingyang <zhou1615@umn.edu> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Zhou Qingyang authored
In dib8000_init(), the variable fe is not freed or passed out on the failure of dib8000_identify(&state->i2c), which could lead to a memleak. Fix this bug by adding a kfree of fe in the error path. This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_DVB_DIB8000=m show no new warnings, and our static analyzer no longer warns about this code. Fixes: 77e2c0f5 ("V4L/DVB (12900): DiB8000: added support for DiBcom ISDB-T/ISDB-Tsb demodulator DiB8000") Signed-off-by: Zhou Qingyang <zhou1615@umn.edu> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Niklas Söderlund authored
There is no need to hold the group lock when unregistering the notifier, but doing so triggers a warning about a possible cyclic lock dependency. The lock warning cover the case where a subdevice is about to be bound to the notifier at the same time as it's unregistered. The locking for this scenario is handled in the v4l2-async framework so it's safe to remove the lock in the driver. This match the locking logic in the driver for when the notifier in question is registered. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Niklas Söderlund authored
The VIN driver have an internal concept of capture groups that covers multiple instances of the driver. This is handled using the shared media graph and a single notifier shared between all VIN instances. This design do not work well if an individual VIN where to be unbound on its own. The design could be improved up on to allow for this but would require large changes in the v4l2-async framework. To avoid the situation suppress the bind and unbind nodes in sysfs. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Niklas Söderlund authored
The v4l2-async framework's subdev notifiers do not behave correctly if a device in the middle of the pipeline is unbound and then rebound. The v4l2-subdevices upstream from the device being rebound gets confused as they receive no notification of the device unbound and can't cleanup their state and when they are rebound to the new v4l2-subdev notifier they try to reinitialize their internal state, this may include things as trying to create links that already exists and in some cases crash the system, for example the adv748x. This should be solved in the v4l2-async framework, but as a stop-gap measure suppress the bind and unbind sysfs nodes for the rcar-csi2 driver so it can't be used to crash the system. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Niklas Söderlund authored
This change fixes two issues with the size constraints for buffers. - There is no width alignment constraint for RGB formats. Prior to this change they were treated as YUV and as a result were more restricted than needed. Add a new check to differentiate between the two. - The minimum width and height supported is 5x2, not 2x4, this is an artifact from the driver's soc-camera days. Fix this incorrect assumption. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
hantro_v4l2.c includes media/videobuf2-dma-sg.h, which isn't used. And in fact, hantro doesn't use the vb2_dma_sg_memops at all, so this is confusing. Just drop both videobuf2 headers, they are not needed here. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Niklas Söderlund authored
Before reading which slot was captured to by examining the module status (VnMS) register, make sure something was captured at all by examining the interrupt status register (VnINTS). Failing this a buffer maybe completed before it was captured too. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Samuel Holland authored
D1 has a unique variant of the video engine, which appears to drop the VP8 support found on most earlier variants. Signed-off-by: Samuel Holland <samuel@sholland.org> Acked-by: Maxime Ripard <maxime@cerno.tech> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Samuel Holland authored
D1 contains a video engine similar to the one in other sunxi SoCs. Add a compatible for it. Signed-off-by: Samuel Holland <samuel@sholland.org> Acked-by: Maxime Ripard <maxime@cerno.tech> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Ricardo Ribalda authored
If the memory where ctrl_found is placed has the value of uvc_ctrl and __uvc_find_control does not find the control we will return an invalid index. Fixes: 6350d6a4 ("media: uvcvideo: Set error_idx during ctrl_commit errors") Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Ricardo Ribalda authored
If mappings points to an invalid memory, we will be invalid accessing it. Solve it by initializing the value of the variable mapping and by changing the order in the conditional statement (to avoid accessing mapping->id if not needed). Fix: kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] PREEMPT SMP KASAN NOPTI Fixes: 6350d6a4 ("media: uvcvideo: Set error_idx during ctrl_commit errors") Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
James Hilliard authored
Some uvc devices appear to require the maximum allowed USB timeout for GET_CUR/SET_CUR requests. So lets just bump the UVC control timeout to 5 seconds which is the same as the usb ctrl get/set defaults: USB_CTRL_GET_TIMEOUT 5000 USB_CTRL_SET_TIMEOUT 5000 It fixes the following runtime warnings: Failed to query (GET_CUR) UVC control 11 on unit 2: -110 (exp. 1). Failed to query (SET_CUR) UVC control 3 on unit 2: -110 (exp. 2). Signed-off-by: James Hilliard <james.hilliard1@gmail.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Ricardo Ribalda authored
Never return V4L2_COLORSPACE_DEFAULT. From the standard: """ In the absence of this descriptor, or in the case of “Unspecified” values within the descriptor, color matching defaults will be assumed. The color matching defaults are compliant with sRGB since the BT.709 transfer function and the sRGB transfer function are very similar. """ Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Tested-by: James Hilliard <james.hilliard1@gmail.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Johan Hovold authored
Add the missing bulk-endpoint max-packet sanity check to uvc_video_start_transfer() to avoid division by zero in uvc_alloc_urb_buffers() in case a malicious device has broken descriptors (or when doing descriptor fuzz testing). Note that USB core will reject URBs submitted for endpoints with zero wMaxPacketSize but that drivers doing packet-size calculations still need to handle this (cf. commit 2548288b ("USB: Fix: Don't skip endpoint descriptors with maxpacket=0")). Fixes: c0efd232 ("V4L/DVB (8145a): USB Video Class driver") Cc: stable@vger.kernel.org # 2.6.26 Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Colin Ian King authored
Currently when the allocation of map->name fails the error exit path does not kfree the previously allocated object map. Fix this by setting ret to -ENOMEM and taking the free_map exit error path to ensure map is kfree'd. Addresses-Coverity: ("Resource leak") Fixes: 70fa906d ("media: uvcvideo: Use control names from framework") Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Ricardo Ribalda <ribalda@chromium.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Mauro Carvalho Chehab authored
Linux 5.16-rc4 * tag 'v5.16-rc4': (984 commits) Linux 5.16-rc4 KVM: SVM: Do not terminate SEV-ES guests on GHCB validation failure KVM: SEV: Fall back to vmalloc for SEV-ES scratch area if necessary KVM: SEV: Return appropriate error codes if SEV-ES scratch setup fails parisc: Mark cr16 CPU clocksource unstable on all SMP machines parisc: Fix "make install" on newer debian releases sched/uclamp: Fix rq->uclamp_max not set on first enqueue preempt/dynamic: Fix setup_preempt_mode() return value cifs: avoid use of dstaddr as key for fscache client cookie cifs: add server conn_id to fscache client cookie cifs: wait for tcon resource_id before getting fscache super cifs: fix missed refcounting of ipc tcon x86/xen: Add xenpv_restore_regs_and_return_to_usermode() x86/entry: Use the correct fence macro after swapgs in kernel CR3 fget: check that the fd still exists after getting a ref to it x86/entry: Add a fence for kernel entry SWAPGS in paranoid_entry() x86/sev: Fix SEV-ES INS/OUTS instructions for word, dword, and qword powercap: DTPM: Drop unused local variable from init_dtpm() io-wq: don't retry task_work creation failure on fatal conditions serial: 8250_bcm7271: UART errors after resuming from S2 ...
-
- 05 Dec, 2021 4 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linuxLinus Torvalds authored
Pull parisc fixes from Helge Deller: "Some bug and warning fixes: - Fix "make install" to use debians "installkernel" script which is now in /usr/sbin - Fix the bindeb-pkg make target by giving the correct KBUILD_IMAGE file name - Fix compiler warnings by annotating parisc agp init functions with __init - Fix timekeeping on SMP machines with dual-core CPUs - Enable some more config options in the 64-bit defconfig" * tag 'for-5.16/parisc-6' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Mark cr16 CPU clocksource unstable on all SMP machines parisc: Fix "make install" on newer debian releases parisc/agp: Annotate parisc agp init functions with __init parisc: Enable sata sil, audit and usb support on 64-bit defconfig parisc: Fix KBUILD_IMAGE for self-extracting kernel
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usbLinus Torvalds authored
Pull USB fixes from Greg KH: "Here are some small USB fixes for a few reported issues. Included in here are: - xhci fix for a _much_ reported regression. I don't think there's a community distro that has not reported this problem yet :( - new USB quirk addition - cdns3 minor fixes - typec regression fix. All of these have been in linux-next with no reported problems, and the xhci fix has been reported by many to resolve their reported problem" * tag 'usb-5.16-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: usb: cdnsp: Fix a NULL pointer dereference in cdnsp_endpoint_init() usb: cdns3: gadget: fix new urb never complete if ep cancel previous requests usb: typec: tcpm: Wait in SNK_DEBOUNCED until disconnect USB: NO_LPM quirk Lenovo Powered USB-C Travel Hub xhci: Fix commad ring abort, write all 64 bits to CRCR register.
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/ttyLinus Torvalds authored
Pull tty/serial fixes from Greg KH: "Here are some small TTY and Serial driver fixes for 5.16-rc4 to resolve a number of reported problems. They include: - liteuart serial driver fixes - 8250_pci serial driver fixes for pericom devices - 8250 RTS line control fix while in RS-485 mode - tegra serial driver fix - msm_serial driver fix - pl011 serial driver new id - fsl_lpuart revert of broken change - 8250_bcm7271 serial driver fix - MAINTAINERS file update for rpmsg tty driver that came in 5.16-rc1 - vgacon fix for reported problem All of these, except for the 8250_bcm7271 fix have been in linux-next with no reported problem. The 8250_bcm7271 fix was added to the tree on Friday so no chance to be linux-next yet. But it should be fine as the affected developers submitted it" * tag 'tty-5.16-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: serial: 8250_bcm7271: UART errors after resuming from S2 serial: 8250_pci: rewrite pericom_do_set_divisor() serial: 8250_pci: Fix ACCES entries in pci_serial_quirks array serial: 8250: Fix RTS modem control while in rs485 mode Revert "tty: serial: fsl_lpuart: drop earlycon entry for i.MX8QXP" serial: tegra: Change lower tolerance baud rate limit for tegra20 and tegra30 serial: liteuart: relax compile-test dependencies serial: liteuart: fix minor-number leak on probe errors serial: liteuart: fix use-after-free and memleak on unbind serial: liteuart: Fix NULL pointer dereference in ->remove() vgacon: Propagate console boot parameters before calling `vc_resize' tty: serial: msm_serial: Deactivate RX DMA for polling support serial: pl011: Add ACPI SBSA UART match id serial: core: fix transmit-buffer reset and memleak MAINTAINERS: Add rpmsg tty driver maintainer
-