June 2021 - Linux-stable-mirror

[patch 4/8] x86/fpu: Limit xstate copy size in xstateregs_set()

by Thomas Gleixner

If the count argument is larger than the xstate size, this will happily copy beyond the end of xstate. Fixes: 91c3dba7dbc1 ("x86/fpu/xstate: Fix PTRACE frames for XSAVES") Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org --- arch/x86/kernel/fpu/regset.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/kernel/fpu/regset.c +++ b/arch/x86/kernel/fpu/regset.c @@ -117,7 +117,7 @@ int xstateregs_set(struct task_struct *t /* * A whole standard-format XSAVE buffer is needed: */ - if ((pos != 0) || (count < fpu_user_xstate_size)) + if (pos != 0 || count != fpu_user_xstate_size) return -EFAULT; xsave = &fpu->state.xsave;

3 years, 11 months

2
1
0 0

Re: [PATCH] ALSA: timer: Fix master timer notification

by Jaroslav Kysela

On 02. 06. 21 13:38, Takashi Iwai wrote: > snd_timer_notify1() calls the notification to each slave for a master > event, but it passes a wrong event number. It should be +10 offset, > corresponding to SNDRV_TIMER_EVENT_MXXX, but it's incorrectly with > +100 offset. Casually this was spotted by UBSAN check via syzkaller. > > Reported-by: syzbot+d102fa5b35335a7e544e(a)syzkaller.appspotmail.com > Cc: <stable(a)vger.kernel.org> > Link: https://lore.kernel.org/r/000000000000e5560e05c3bd1d63@google.com > Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Reviewed-by: Jaroslav Kysela <perex(a)perex.cz> > --- > sound/core/timer.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/sound/core/timer.c b/sound/core/timer.c > index 6898b1ac0d7f..92b7008fcdb8 100644 > --- a/sound/core/timer.c > +++ b/sound/core/timer.c > @@ -520,9 +520,10 @@ static void snd_timer_notify1(struct snd_timer_instance *ti, int event) > return; > if (timer->hw.flags & SNDRV_TIMER_HW_SLAVE) > return; > + event += 10; /* convert to SNDRV_TIMER_EVENT_MXXX */ > list_for_each_entry(ts, &ti->slave_active_head, active_list) > if (ts->ccallback) > - ts->ccallback(ts, event + 100, &tstamp, resolution); > + ts->ccallback(ts, event, &tstamp, resolution); > } > > /* start/continue a master timer */ > -- Jaroslav Kysela <perex(a)perex.cz> Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

3 years, 11 months

1
0
0 0

[patch 2/8] x86/fpu: Prevent state corruption in __fpu__restore_sig()

by Thomas Gleixner

From: Thomas Gleixner <tglx(a)linutronix.de> The non-compacted slowpath uses __copy_from_user() and copies the entire user buffer into the kernel buffer, verbatim. This means that the kernel buffer may now contain entirely invalid state on which XRSTOR will #GP. validate_user_xstate_header() can detect some of that corruption, but that leaves the onus on callers to clear the buffer. Prior to XSAVES support it was possible just to reinitialize the buffer, completely, but with supervisor states that is not longer possible as the buffer clearing code split got it backwards. Fixing that is possible, but not corrupting the state in the first place is more robust. Avoid corruption of the kernel XSAVE buffer by using copy_user_to_xstate() which validates the XSAVE header contents before copying the actual states to the kernel. copy_user_to_xstate() was previously only called for compacted-format kernel buffers, but it works for both compacted and non-compacted forms. Using it for the non-compacted form is slower because of multiple __copy_from_user() operations, but that cost is less important than robust code in an already slow path. [ Changelog polished by Dave Hansen ] Fixes: b860eb8dce59 ("x86/fpu/xstate: Define new functions for clearing fpregs and xstates") Reported-by: syzbot+2067e764dbcd10721e2e(a)syzkaller.appspotmail.com Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org --- arch/x86/include/asm/fpu/xstate.h | 4 ---- arch/x86/kernel/fpu/signal.c | 9 +-------- arch/x86/kernel/fpu/xstate.c | 2 +- 3 files changed, 2 insertions(+), 13 deletions(-) --- a/arch/x86/include/asm/fpu/xstate.h +++ b/arch/x86/include/asm/fpu/xstate.h @@ -112,8 +112,4 @@ void copy_supervisor_to_kernel(struct xr void copy_dynamic_supervisor_to_kernel(struct xregs_state *xstate, u64 mask); void copy_kernel_to_dynamic_supervisor(struct xregs_state *xstate, u64 mask); - -/* Validate an xstate header supplied by userspace (ptrace or sigreturn) */ -int validate_user_xstate_header(const struct xstate_header *hdr); - #endif --- a/arch/x86/kernel/fpu/signal.c +++ b/arch/x86/kernel/fpu/signal.c @@ -405,14 +405,7 @@ static int __fpu__restore_sig(void __use if (use_xsave() && !fx_only) { u64 init_bv = xfeatures_mask_user() & ~user_xfeatures; - if (using_compacted_format()) { - ret = copy_user_to_xstate(&fpu->state.xsave, buf_fx); - } else { - ret = __copy_from_user(&fpu->state.xsave, buf_fx, state_size); - - if (!ret && state_size > offsetof(struct xregs_state, header)) - ret = validate_user_xstate_header(&fpu->state.xsave.header); - } + ret = copy_user_to_xstate(&fpu->state.xsave, buf_fx); if (ret) goto err_out; --- a/arch/x86/kernel/fpu/xstate.c +++ b/arch/x86/kernel/fpu/xstate.c @@ -515,7 +515,7 @@ int using_compacted_format(void) } /* Validate an xstate header supplied by userspace (ptrace or sigreturn) */ -int validate_user_xstate_header(const struct xstate_header *hdr) +static int validate_user_xstate_header(const struct xstate_header *hdr) { /* No unknown or supervisor features may be set */ if (hdr->xfeatures & ~xfeatures_mask_user())

3 years, 11 months

2
3
0 0

[PATCH 1/2] Bluetooth: btrtl: rename USB fw for RTL8761

by Joakim Tjernlund

From: Joakim Tjernlund <Joakim.Tjernlund(a)infinera.com> According Realteks own BT drivers firmware RTL8761B is for UART and RTL8761BU is for USB. Change existing 8761B to UART and add an 8761BU entry for USB Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund(a)infinera.com> Cc: stable(a)vger.kernel.org --- drivers/bluetooth/btrtl.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/bluetooth/btrtl.c b/drivers/bluetooth/btrtl.c index e7fe5fb22753..ccef8b2cfee2 100644 --- a/drivers/bluetooth/btrtl.c +++ b/drivers/bluetooth/btrtl.c @@ -132,12 +132,19 @@ static const struct id_table ic_id_table[] = { .cfg_name = "rtl_bt/rtl8761a_config" }, /* 8761B */ - { IC_INFO(RTL_ROM_LMP_8761A, 0xb, 0xa, HCI_USB), + { IC_INFO(RTL_ROM_LMP_8761A, 0xb, 0xa, HCI_UART), .config_needed = false, .has_rom_version = true, .fw_name = "rtl_bt/rtl8761b_fw.bin", .cfg_name = "rtl_bt/rtl8761b_config" }, + /* 8761BU */ + { IC_INFO(RTL_ROM_LMP_8761A, 0xb, 0xa, HCI_USB), + .config_needed = false, + .has_rom_version = true, + .fw_name = "rtl_bt/rtl8761bu_fw.bin", + .cfg_name = "rtl_bt/rtl8761bu_config" }, + /* 8822C with UART interface */ { IC_INFO(RTL_ROM_LMP_8822B, 0xc, 0xa, HCI_UART), .config_needed = true, -- 2.31.1

3 years, 11 months

2
2
0 0

patch "usb: pd: Set PD_T_SINK_WAIT_CAP to 310ms" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: pd: Set PD_T_SINK_WAIT_CAP to 310ms to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 6490fa565534fa83593278267785a694fd378a2b Mon Sep 17 00:00:00 2001 From: Kyle Tso <kyletso(a)google.com> Date: Fri, 28 May 2021 16:16:13 +0800 Subject: usb: pd: Set PD_T_SINK_WAIT_CAP to 310ms Current timer PD_T_SINK_WAIT_CAP is set to 240ms which will violate the SinkWaitCapTimer (tTypeCSinkWaitCap 310 - 620 ms) defined in the PD Spec if the port is faster enough when running the state machine. Set it to the lower bound 310ms to ensure the timeout is in Spec. Fixes: f0690a25a140 ("staging: typec: USB Type-C Port Manager (tcpm)") Cc: stable <stable(a)vger.kernel.org> Reviewed-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Kyle Tso <kyletso(a)google.com> Link: https://lore.kernel.org/r/20210528081613.730661-1-kyletso@google.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/linux/usb/pd.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/usb/pd.h b/include/linux/usb/pd.h index bf00259493e0..96b7ff66f074 100644 --- a/include/linux/usb/pd.h +++ b/include/linux/usb/pd.h @@ -460,7 +460,7 @@ static inline unsigned int rdo_max_power(u32 rdo) #define PD_T_RECEIVER_RESPONSE 15 /* 15ms max */ #define PD_T_SOURCE_ACTIVITY 45 #define PD_T_SINK_ACTIVITY 135 -#define PD_T_SINK_WAIT_CAP 240 +#define PD_T_SINK_WAIT_CAP 310 /* 310 - 620 ms */ #define PD_T_PS_TRANSITION 500 #define PD_T_SRC_TRANSITION 35 #define PD_T_DRP_SNK 40 -- 2.31.1

3 years, 11 months

1
0
0 0

patch "usb: dwc3: gadget: Bail from dwc3_gadget_exit() if dwc->gadget is" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: dwc3: gadget: Bail from dwc3_gadget_exit() if dwc->gadget is to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 03715ea2e3dbbc56947137ce3b4ac18a726b2f87 Mon Sep 17 00:00:00 2001 From: Jack Pham <jackp(a)codeaurora.org> Date: Fri, 28 May 2021 09:04:05 -0700 Subject: usb: dwc3: gadget: Bail from dwc3_gadget_exit() if dwc->gadget is NULL There exists a possible scenario in which dwc3_gadget_init() can fail: during during host -> peripheral mode switch in dwc3_set_mode(), and a pending gadget driver fails to bind. Then, if the DRD undergoes another mode switch from peripheral->host the resulting dwc3_gadget_exit() will attempt to reference an invalid and dangling dwc->gadget pointer as well as call dma_free_coherent() on unmapped DMA pointers. The exact scenario can be reproduced as follows: - Start DWC3 in peripheral mode - Configure ConfigFS gadget with FunctionFS instance (or use g_ffs) - Run FunctionFS userspace application (open EPs, write descriptors, etc) - Bind gadget driver to DWC3's UDC - Switch DWC3 to host mode => dwc3_gadget_exit() is called. usb_del_gadget() will put the ConfigFS driver instance on the gadget_driver_pending_list - Stop FunctionFS application (closes the ep files) - Switch DWC3 to peripheral mode => dwc3_gadget_init() fails as usb_add_gadget() calls check_pending_gadget_drivers() and attempts to rebind the UDC to the ConfigFS gadget but fails with -19 (-ENODEV) because the FFS instance is not in FFS_ACTIVE state (userspace has not re-opened and written the descriptors yet, i.e. desc_ready!=0). - Switch DWC3 back to host mode => dwc3_gadget_exit() is called again, but this time dwc->gadget is invalid. Although it can be argued that userspace should take responsibility for ensuring that the FunctionFS application be ready prior to allowing the composite driver bind to the UDC, failure to do so should not result in a panic from the kernel driver. Fix this by setting dwc->gadget to NULL in the failure path of dwc3_gadget_init() and add a check to dwc3_gadget_exit() to bail out unless the gadget pointer is valid. Fixes: e81a7018d93a ("usb: dwc3: allocate gadget structure dynamically") Cc: <stable(a)vger.kernel.org> Reviewed-by: Peter Chen <peter.chen(a)kernel.org> Signed-off-by: Jack Pham <jackp(a)codeaurora.org> Link: https://lore.kernel.org/r/20210528160405.17550-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/dwc3/gadget.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 2577488456da..88270eee8a48 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -4045,6 +4045,7 @@ int dwc3_gadget_init(struct dwc3 *dwc) dwc3_gadget_free_endpoints(dwc); err4: usb_put_gadget(dwc->gadget); + dwc->gadget = NULL; err3: dma_free_coherent(dwc->sysdev, DWC3_BOUNCE_SIZE, dwc->bounce, dwc->bounce_addr); @@ -4064,6 +4065,9 @@ int dwc3_gadget_init(struct dwc3 *dwc) void dwc3_gadget_exit(struct dwc3 *dwc) { + if (!dwc->gadget) + return; + usb_del_gadget(dwc->gadget); dwc3_gadget_free_endpoints(dwc); usb_put_gadget(dwc->gadget); -- 2.31.1

3 years, 11 months

1
0
0 0

[git:media_stage/master] media: rtl28xxu: fix zero-length control request

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: rtl28xxu: fix zero-length control request Author: Johan Hovold <johan(a)kernel.org> Date: Mon May 24 13:09:20 2021 +0200 The direction of the pipe argument must match the request-type direction bit or control requests may fail depending on the host-controller-driver implementation. Control transfers without a data stage are treated as OUT requests by the USB stack and should be using usb_sndctrlpipe(). Failing to do so will now trigger a warning. Fix the zero-length i2c-read request used for type detection by attempting to read a single byte instead. Reported-by: syzbot+faf11bbadc5a372564da(a)syzkaller.appspotmail.com Fixes: d0f232e823af ("[media] rtl28xxu: add heuristic to detect chip type") Cc: stable(a)vger.kernel.org # 4.0 Cc: Antti Palosaari <crope(a)iki.fi> Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c index 97ed17a141bb..2c04ed8af0e4 100644 --- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c +++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c @@ -612,8 +612,9 @@ static int rtl28xxu_read_config(struct dvb_usb_device *d) static int rtl28xxu_identify_state(struct dvb_usb_device *d, const char **name) { struct rtl28xxu_dev *dev = d_to_priv(d); + u8 buf[1]; int ret; - struct rtl28xxu_req req_demod_i2c = {0x0020, CMD_I2C_DA_RD, 0, NULL}; + struct rtl28xxu_req req_demod_i2c = {0x0020, CMD_I2C_DA_RD, 1, buf}; dev_dbg(&d->intf->dev, "\n");

3 years, 11 months

2
1
0 0

[git:media_tree/master] media: rtl28xxu: fix zero-length control request

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: rtl28xxu: fix zero-length control request Author: Johan Hovold <johan(a)kernel.org> Date: Mon May 24 13:09:20 2021 +0200 The direction of the pipe argument must match the request-type direction bit or control requests may fail depending on the host-controller-driver implementation. Control transfers without a data stage are treated as OUT requests by the USB stack and should be using usb_sndctrlpipe(). Failing to do so will now trigger a warning. Fix the zero-length i2c-read request used for type detection by attempting to read a single byte instead. Reported-by: syzbot+faf11bbadc5a372564da(a)syzkaller.appspotmail.com Fixes: d0f232e823af ("[media] rtl28xxu: add heuristic to detect chip type") Cc: stable(a)vger.kernel.org # 4.0 Cc: Antti Palosaari <crope(a)iki.fi> Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c index 97ed17a141bb..2c04ed8af0e4 100644 --- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c +++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c @@ -612,8 +612,9 @@ static int rtl28xxu_read_config(struct dvb_usb_device *d) static int rtl28xxu_identify_state(struct dvb_usb_device *d, const char **name) { struct rtl28xxu_dev *dev = d_to_priv(d); + u8 buf[1]; int ret; - struct rtl28xxu_req req_demod_i2c = {0x0020, CMD_I2C_DA_RD, 0, NULL}; + struct rtl28xxu_req req_demod_i2c = {0x0020, CMD_I2C_DA_RD, 1, buf}; dev_dbg(&d->intf->dev, "\n");

3 years, 11 months

1
0
0 0

[git:media_tree/master] media: gspca/sunplus: fix zero-length control requests

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: gspca/sunplus: fix zero-length control requests Author: Johan Hovold <johan(a)kernel.org> Date: Mon May 24 13:09:19 2021 +0200 The direction of the pipe argument must match the request-type direction bit or control requests may fail depending on the host-controller-driver implementation. Control transfers without a data stage are treated as OUT requests by the USB stack and should be using usb_sndctrlpipe(). Failing to do so will now trigger a warning. Fix the single zero-length control request which was using the read-register helper, and update the helper so that zero-length reads fail with an error message instead. Fixes: 6a7eba24e4f0 ("V4L/DVB (8157): gspca: all subdrivers") Cc: stable(a)vger.kernel.org # 2.6.27 Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> drivers/media/usb/gspca/sunplus.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- diff --git a/drivers/media/usb/gspca/sunplus.c b/drivers/media/usb/gspca/sunplus.c index ace3da40006e..971dee0a56da 100644 --- a/drivers/media/usb/gspca/sunplus.c +++ b/drivers/media/usb/gspca/sunplus.c @@ -242,6 +242,10 @@ static void reg_r(struct gspca_dev *gspca_dev, gspca_err(gspca_dev, "reg_r: buffer overflow\n"); return; } + if (len == 0) { + gspca_err(gspca_dev, "reg_r: zero-length read\n"); + return; + } if (gspca_dev->usb_err < 0) return; ret = usb_control_msg(gspca_dev->dev, @@ -250,7 +254,7 @@ static void reg_r(struct gspca_dev *gspca_dev, USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE, 0, /* value */ index, - len ? gspca_dev->usb_buf : NULL, len, + gspca_dev->usb_buf, len, 500); if (ret < 0) { pr_err("reg_r err %d\n", ret); @@ -727,7 +731,7 @@ static int sd_start(struct gspca_dev *gspca_dev) case MegaImageVI: reg_w_riv(gspca_dev, 0xf0, 0, 0); spca504B_WaitCmdStatus(gspca_dev); - reg_r(gspca_dev, 0xf0, 4, 0); + reg_w_riv(gspca_dev, 0xf0, 4, 0); spca504B_WaitCmdStatus(gspca_dev); break; default:

3 years, 11 months

1
0
0 0

[git:media_stage/master] media: gspca/sunplus: fix zero-length control requests

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: gspca/sunplus: fix zero-length control requests Author: Johan Hovold <johan(a)kernel.org> Date: Mon May 24 13:09:19 2021 +0200 The direction of the pipe argument must match the request-type direction bit or control requests may fail depending on the host-controller-driver implementation. Control transfers without a data stage are treated as OUT requests by the USB stack and should be using usb_sndctrlpipe(). Failing to do so will now trigger a warning. Fix the single zero-length control request which was using the read-register helper, and update the helper so that zero-length reads fail with an error message instead. Fixes: 6a7eba24e4f0 ("V4L/DVB (8157): gspca: all subdrivers") Cc: stable(a)vger.kernel.org # 2.6.27 Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> drivers/media/usb/gspca/sunplus.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- diff --git a/drivers/media/usb/gspca/sunplus.c b/drivers/media/usb/gspca/sunplus.c index ace3da40006e..971dee0a56da 100644 --- a/drivers/media/usb/gspca/sunplus.c +++ b/drivers/media/usb/gspca/sunplus.c @@ -242,6 +242,10 @@ static void reg_r(struct gspca_dev *gspca_dev, gspca_err(gspca_dev, "reg_r: buffer overflow\n"); return; } + if (len == 0) { + gspca_err(gspca_dev, "reg_r: zero-length read\n"); + return; + } if (gspca_dev->usb_err < 0) return; ret = usb_control_msg(gspca_dev->dev, @@ -250,7 +254,7 @@ static void reg_r(struct gspca_dev *gspca_dev, USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE, 0, /* value */ index, - len ? gspca_dev->usb_buf : NULL, len, + gspca_dev->usb_buf, len, 500); if (ret < 0) { pr_err("reg_r err %d\n", ret); @@ -727,7 +731,7 @@ static int sd_start(struct gspca_dev *gspca_dev) case MegaImageVI: reg_w_riv(gspca_dev, 0xf0, 0, 0); spca504B_WaitCmdStatus(gspca_dev); - reg_r(gspca_dev, 0xf0, 4, 0); + reg_w_riv(gspca_dev, 0xf0, 4, 0); spca504B_WaitCmdStatus(gspca_dev); break; default:

3 years, 11 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2021