[pull] master from torvalds:master #838

In commit 221abd4 ("staging: r8188eu: Remove no more necessary definitions and code"), two entries were removed from RTW_ChannelPlanMap[], but not replaced with zeros. The position within this table is important, thus the patch broke systems operating in regulatory domains osted later than entry 0x13 in the table. Unfortunately, the FCC entry comes before that point and most testers did not see this problem. Fixes: 221abd4 ("staging: r8188eu: Remove no more necessary definitions and code") Cc: Stable <stable@vger.kernel.org> # v5.5+ Reported-and-tested-by: Zameer Manji <zmanji@gmail.com> Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Phillip Potter <phil@philpotter.co.uk> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Link: https://lore.kernel.org/r/20211107173543.7486-1-Larry.Finger@lwfinger.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit b4a1ed0 ("fbdev: make FB_BACKLIGHT a tristate") forgot to update fbtft breaking its backlight support when FB_BACKLIGHT is a module. Since FB_TFT selects FB_BACKLIGHT there's no need for this conditional so just remove it and we're good. Fixes: b4a1ed0 ("fbdev: make FB_BACKLIGHT a tristate") Cc: <stable@vger.kernel.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://lore.kernel.org/r/20211105204358.2991-1-noralf@tronnes.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Use the GFP_ATOMIC flag of kzalloc() with two memory allocation in report_del_sta_event(). This function is called while holding spinlocks, therefore it is not allowed to sleep. With the GFP_ATOMIC type flag, the allocation is high priority and must not sleep. This issue is detected by Smatch which emits the following warning: "drivers/staging/r8188eu/core/rtw_mlme_ext.c:6848 report_del_sta_event() warn: sleeping in atomic context". After the change, the post-commit hook output the following message: "CHECK: Prefer kzalloc(sizeof(*pcmd_obj)...) over kzalloc(sizeof(struct cmd_obj)...)". According to the above "CHECK", use the preferred style in the first kzalloc(). Fixes: 79f712e ("staging: r8188eu: Remove wrappers for kalloc() and kzalloc()") Fixes: 1586512 ("staging: r8188eu: introduce new core dir for RTL8188eu driver") Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com> Link: https://lore.kernel.org/r/20211101191847.6749-1-fmdefrancesco@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: stable <stable@vger.kernel.org>

In function rtw_report_sec_ie() kzalloc() is called under a spinlock, so the allocation have to be atomic. Call tree: -> rtw_select_and_join_from_scanned_queue() <- takes a spinlock -> rtw_joinbss_cmd() -> rtw_restruct_sec_ie() -> rtw_report_sec_ie() Fixes: 2b42bd5 ("staging: r8188eu: introduce new os_dep dir for RTL8188eu driver") Cc: stable <stable@vger.kernel.org> Signed-off-by: Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20211108105537.31655-1-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Free "ptmp" before returning -EINVAL. Fixes: 2b42bd5 ("staging: r8188eu: introduce new os_dep dir for RTL8188eu driver") Cc: stable <stable@vger.kernel.org> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20211109114935.GC16587@kili Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The Netlogic XLP platform was removed in commit 95b8a5e ("MIPS: Remove NETLOGIC support"), so this driver is now dead. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Ganesan Ramalingam <ganesanr@broadcom.com> Cc: Jayachandran Chandrashekaran Nair <jchandra@broadcom.com> Cc: linux-staging@lists.linux.dev Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211109161401.2204280-1-robh@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

On IMX SoC's which support CMDQ the following can occur during high a high cpu load: mmc2: cqhci: ============ CQHCI REGISTER DUMP =========== mmc2: cqhci: Caps: 0x0000310a | Version: 0x00000510 mmc2: cqhci: Config: 0x00001001 | Control: 0x00000000 mmc2: cqhci: Int stat: 0x00000000 | Int enab: 0x00000006 mmc2: cqhci: Int sig: 0x00000006 | Int Coal: 0x00000000 mmc2: cqhci: TDL base: 0x8003f000 | TDL up32: 0x00000000 mmc2: cqhci: Doorbell: 0xbf01dfff | TCN: 0x00000000 mmc2: cqhci: Dev queue: 0x00000000 | Dev Pend: 0x08000000 mmc2: cqhci: Task clr: 0x00000000 | SSC1: 0x00011000 mmc2: cqhci: SSC2: 0x00000001 | DCMD rsp: 0x00000800 mmc2: cqhci: RED mask: 0xfdf9a080 | TERRI: 0x00000000 mmc2: cqhci: Resp idx: 0x0000000d | Resp arg: 0x00000000 mmc2: sdhci: ============ SDHCI REGISTER DUMP =========== mmc2: sdhci: Sys addr: 0x7c722000 | Version: 0x00000002 mmc2: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000020 mmc2: sdhci: Argument: 0x00018000 | Trn mode: 0x00000023 mmc2: sdhci: Present: 0x01f88008 | Host ctl: 0x00000030 mmc2: sdhci: Power: 0x00000002 | Blk gap: 0x00000080 mmc2: sdhci: Wake-up: 0x00000008 | Clock: 0x0000000f mmc2: sdhci: Timeout: 0x0000008f | Int stat: 0x00000000 mmc2: sdhci: Int enab: 0x107f4000 | Sig enab: 0x107f4000 mmc2: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000502 mmc2: sdhci: Caps: 0x07eb0000 | Caps_1: 0x8000b407 mmc2: sdhci: Cmd: 0x00000d1a | Max curr: 0x00ffffff mmc2: sdhci: Resp[0]: 0x00000000 | Resp[1]: 0xffc003ff mmc2: sdhci: Resp[2]: 0x328f5903 | Resp[3]: 0x00d07f01 mmc2: sdhci: Host ctl2: 0x00000088 mmc2: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0xfe179020 mmc2: sdhci-esdhc-imx: ========= ESDHC IMX DEBUG STATUS DUMP ==== mmc2: sdhci-esdhc-imx: cmd debug status: 0x2120 mmc2: sdhci-esdhc-imx: data debug status: 0x2200 mmc2: sdhci-esdhc-imx: trans debug status: 0x2300 mmc2: sdhci-esdhc-imx: dma debug status: 0x2400 mmc2: sdhci-esdhc-imx: adma debug status: 0x2510 mmc2: sdhci-esdhc-imx: fifo debug status: 0x2680 mmc2: sdhci-esdhc-imx: async fifo debug status: 0x2750 mmc2: sdhci: ============================================ For now, disable CMDQ support on the imx8qm/imx8qxp/imx8mm until the issue is found and resolved. Fixes: bb6e358 ("mmc: sdhci-esdhc-imx: add CMDQ support") Fixes: cde5e8e ("mmc: sdhci-esdhc-imx: Add an new esdhc_soc_data for i.MX8MM") Cc: stable@vger.kernel.org Signed-off-by: Tim Harvey <tharvey@gateworks.com> Reviewed-by: Haibo Chen <haibo.chen@nxp.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20211103165415.2016-1-tharvey@gateworks.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

When CONFIG_FUNCTION_GRAPH_TRACER is selected and the function graph tracer is in use, unwind_frame() may erroneously associate a traced function with an incorrect return address. This can happen when starting an unwind from a pt_regs, or when unwinding across an exception boundary. This can be seen when recording with perf while the function graph tracer is in use. For example: | # echo function_graph > /sys/kernel/debug/tracing/current_tracer | # perf record -g -e raw_syscalls:sys_enter:k /bin/true | # perf report ... reports the callchain erroneously as: | el0t_64_sync | el0t_64_sync_handler | el0_svc_common.constprop.0 | perf_callchain | get_perf_callchain | syscall_trace_enter | syscall_trace_enter ... whereas when the function graph tracer is not in use, it reports: | el0t_64_sync | el0t_64_sync_handler | el0_svc | do_el0_svc | el0_svc_common.constprop.0 | syscall_trace_enter | syscall_trace_enter The underlying problem is that ftrace_graph_get_ret_stack() takes an index offset from the most recent entry added to the fgraph return stack. We start an unwind at offset 0, and increment the offset each time we encounter a rewritten return address (i.e. when we see `return_to_handler`). This is broken in two cases: 1) Between creating a pt_regs and starting the unwind, function calls may place entries on the stack, leaving an arbitrary offset which we can only determine by performing a full unwind from the caller of the unwind code (and relying on none of the unwind code being instrumented). This can result in erroneous entries being reported in a backtrace recorded by perf or kfence when the function graph tracer is in use. Currently show_regs() is unaffected as dump_backtrace() performs an initial unwind. 2) When unwinding across an exception boundary (whether continuing an unwind or starting a new unwind from regs), we currently always skip the LR of the interrupted context. Where this was live and contained a rewritten address, we won't consume the corresponding fgraph ret stack entry, leaving subsequent entries off-by-one. This can result in erroneous entries being reported in a backtrace performed by any in-kernel unwinder when that backtrace crosses an exception boundary, with entries after the boundary being reported incorrectly. This includes perf, kfence, show_regs(), panic(), etc. To fix this, we need to be able to uniquely identify each rewritten return address such that we can map this back to the original return address. We can use HAVE_FUNCTION_GRAPH_RET_ADDR_PTR to associate each rewritten return address with a unique location on the stack. As the return address is passed in the LR (and so is not guaranteed a unique location in memory), we use the FP upon entry to the function (i.e. the address of the caller's frame record) as the return address pointer. Any nested call will have a different FP value as the caller must create its own frame record and update FP to point to this. Since ftrace_graph_ret_addr() requires the return address with the PAC stripped, the stripping of the PAC is moved before the fixup of the rewritten address. As we would unconditionally strip the PAC, moving this earlier is not harmful, and we can avoid a redundant strip in the return address fixup code. I've tested this with the perf case above, the ftrace selftests, and a number of ad-hoc unwinder tests. The tests all pass, and I have seen no unexpected behaviour as a result of this change. I've tested with pointer authentication under QEMU TCG where magic-sysrq+l correctly recovers the original return addresses. Note that this doesn't fix the issue of skipping a live LR at an exception boundary, which is a more general problem and requires more substantial rework. Were we to consume the LR in all cases this would result in warnings where the interrupted context's LR contains `return_to_handler`, but the FP has been altered, e.g. | func: | <--- ftrace entry ---> // logs FP & LR, rewrites LR | STP FP, LR, [SP, #-16]! | MOV FP, SP | <--- INTERRUPT ---> ... as ftrace_graph_get_ret_stack() fill not find a matching entry, triggering the WARN_ON_ONCE() in unwind_frame(). Link: https://lore.kernel.org/r/20211025164925.GB2001@C02TD0UTHF1T.local Link: https://lore.kernel.org/r/20211027132529.30027-1-mark.rutland@arm.com Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Madhavan T. Venkataraman <madvenka@linux.microsoft.com> Cc: Mark Brown <broonie@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Will Deacon <will@kernel.org> Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20211029162245.39761-1-mark.rutland@arm.com Signed-off-by: Will Deacon <will@kernel.org>

trans_pgd_create_copy() can hit "VM_BUG_ON(mm != &init_mm)" in the function pmd_populate_kernel(). This is the combined consequence of commit 5de5988 ("arm64: trans_pgd: pass NULL instead of init_mm to *_populate functions"), which replaced &init_mm with NULL and commit 59511cf ("arm64: mm: use XN table mapping attributes for user/kernel mappings"), which introduced the VM_BUG_ON. Since the former sounds reasonable, it is better to work on the later. From the perspective of trans_pgd, two groups of functions are considered in the later one: pmd_populate_kernel() mm == NULL should be fixed, else it hits VM_BUG_ON() p?d_populate() mm == NULL means PXN, that is OK, since trans_pgd only copies a linear map, no execution will happen on the map. So it is good enough to just relax VM_BUG_ON() to disregard mm == NULL Fixes: 59511cf ("arm64: mm: use XN table mapping attributes for user/kernel mappings") Signed-off-by: Pingfan Liu <kernelfans@gmail.com> Cc: <stable@vger.kernel.org> # 5.13.x Cc: Ard Biesheuvel <ardb@kernel.org> Cc: James Morse <james.morse@arm.com> Cc: Matthias Brugger <mbrugger@suse.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com> Link: https://lore.kernel.org/r/20211112052214.9086-1-kernelfans@gmail.com Signed-off-by: Will Deacon <will@kernel.org>

This configuration option provides a misc device as an API to userspace. Make this API usable without having to select the module as a transitive dependency. This also fixes an issue where localyesconfig would select CONFIG_XEN_PRIVCMD=m because it was not visible and defaulted to building as module. [boris: clarified help message per Jan's suggestion] Based-on-patch-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20211116143323.18866-1-jgross@suse.com Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

In case of errors in xenbus_init (e.g. missing xen_store_gfn parameter), we goto out_error but we forget to reset xen_store_domain_type to XS_UNKNOWN. As a consequence xenbus_probe_initcall and other initcalls will still try to initialize xenstore resulting into a crash at boot. [ 2.479830] Call trace: [ 2.482314] xb_init_comms+0x18/0x150 [ 2.486354] xs_init+0x34/0x138 [ 2.489786] xenbus_probe+0x4c/0x70 [ 2.498432] xenbus_probe_initcall+0x2c/0x7c [ 2.503944] do_one_initcall+0x54/0x1b8 [ 2.507358] kernel_init_freeable+0x1ac/0x210 [ 2.511617] kernel_init+0x28/0x130 [ 2.516112] ret_from_fork+0x10/0x20 Cc: <Stable@vger.kernel.org> Cc: jbeulich@suse.com Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com> Link: https://lore.kernel.org/r/20211115222719.2558207-1-sstabellini@kernel.org Reviewed-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

The block layer forces a minimum segment size of PAGE_SIZE, so a segment can be too big for the ADMA table, if PAGE_SIZE >= 64KiB. Fix by writing multiple descriptors, noting that the ADMA table is sized for 4KiB chunks anyway, so it will be big enough. Reported-and-tested-by: Bough Chen <haibo.chen@nxp.com> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20211115082345.802238-1-adrian.hunter@intel.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

snd_ctl_remove() has to be called with card->controls_rwsem held (when called after the card instantiation). This patch adds the missing rwsem calls around it. Fixes: 510e340 ("staging: greybus: audio: Add helper APIs for dynamic audio modules") Cc: stable <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20211116072027.18466-1-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The free_rtllib() function frees the "dev" pointer so there is use after free on the next line. Re-arrange things to avoid that. Fixes: 6689817 ("staging: rtl8192e: Fix unload/reload problem") Cc: stable <stable@vger.kernel.org> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20211117072016.GA5237@kili Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

During our predesign phase for DWC_usb32, the GHWPARAMS9 register offset was 0xc680. We revised our final design, and the GHWPARAMS9 offset is now moved to 0xc6e8 on release. Fixes: 1671038 ("usb: dwc3: Capture new capability register GHWPARAMS9") Cc: <stable@vger.kernel.org> Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/1541737108266a97208ff827805be1f32852590c.1635202893.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The End Transfer command from a stream endpoint will generate a NoStream event, and we should ignore it. Currently we set the flag DWC3_EP_IGNORE_NEXT_NOSTREAM to track this prior to sending the command, and it will be cleared on the next stream event. However, a stream event may be generated before the End Transfer command completion and prematurely clear the flag. Fix this by setting the flag on End Transfer completion instead. Fixes: 140ca4c ("usb: dwc3: gadget: Handle stream transfers") Cc: <stable@vger.kernel.org> Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/cee1253af4c3600edb878d11c9c08b040817ae23.1635203975.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The programming guide noted that the driver needs to verify if the link state is in U0 before executing the Start Transfer command. If it's not in U0, the driver needs to perform remote wakeup. This is not accurate. If the link state is in U1/U2, then the controller will not respond to link recovery request from DCTL.ULSTCHNGREQ. The Start Transfer command will trigger a link recovery if it is in U1/U2. A clarification will be added to the programming guide for all controller versions. The current implementation shouldn't cause any functional issue. It may occasionally report an invalid time out warning from failed link recovery request. The driver will still go ahead with the Start Transfer command if the remote wakeup fails. The new change only initiates remote wakeup where it is needed, which is when the link state is in L1/L2/U3. Fixes: c36d8e9 ("usb: dwc3: gadget: put link to U0 before Start Transfer") Cc: <stable@vger.kernel.org> Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/05b4a5fbfbd0863fc9b1d7af934a366219e3d0b4.1635204761.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Added updating of request frame number for elapsed frames, otherwise frame number will remain as previous use of request. This will allow function driver to correctly track frames in case of Missed ISOC occurs. Added setting request actual length to 0 for elapsed frames. In Slave mode when pushing data to RxFIFO by dwords, request actual length incrementing accordingly. But before whole packet will be pushed into RxFIFO and send to host can occurs Missed ISOC and data will not send to host. So, in this case request actual length should be reset to 0. Fixes: 91bb163 ("usb: dwc2: gadget: Fix ISOC flow for BDMA and Slave") Cc: stable <stable@vger.kernel.org> Reviewed-by: John Keeping <john@metanate.com> Signed-off-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com> Link: https://lore.kernel.org/r/c356baade6e9716d312d43df08d53ae557cb8037.1636011277.git.Minas.Harutyunyan@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Older device-trees don't specify padctrl interrupt and xhci-tegra driver now fails to probe with -EINVAL using those device-trees. Check interrupt presence and keep runtime PM disabled if it's missing to fix the trouble. Fixes: 971ee24 ("usb: xhci: tegra: Enable ELPG for runtime/system PM") Cc: <stable@vger.kernel.org> # 5.14+ Reported-by: Nicolas Chauvet <kwizart@gmail.com> Tested-by: Nicolas Chauvet <kwizart@gmail.com> # T124 TK1 Tested-by: Thomas Graichen <thomas.graichen@gmail.com> # T124 Nyan Big Tested-by: Thierry Reding <treding@nvidia.com> # Tegra CI Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20211107224455.10359-1-digetx@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

A successful 'clk_prepare_enable()' call should be balanced by a corresponding 'clk_disable_unprepare()' call in the error handling path of the probe, as already done in the remove function. Fixes: 2474922 ("usb: gadget: udc-xilinx: Add clock support") Reviewed-by: Shubhrajyoti Datta <shubhraj@xilinx.com> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/ec61a89b83ce34b53a3bdaacfd1413a9869cc608.1636302246.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

In the endpoint interrupt functions dwc3_gadget_endpoint_transfer_in_progress() and dwc3_gadget_endpoint_trbs_complete() will dereference the endpoint descriptor. But it could be cleared in __dwc3_gadget_ep_disable() when accessory disconnected. So we need to check whether it is null or not before dereferencing it. Fixes: f09ddcf ("usb: dwc3: gadget: Prevent EP queuing while stopping transfers") Cc: stable <stable@vger.kernel.org> Reviewed-by: Jack Pham <quic_jackp@quicinc.com> Signed-off-by: Albert Wang <albertccwang@google.com> Link: https://lore.kernel.org/r/20211109092642.3507692-1-albertccwang@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

A new commit in LLVM causes an error on the use of 'long double' when '-mno-x87' is used, which the kernel does through an alias, '-mno-80387' (see the LLVM commit below for more details around why it does this). drivers/usb/dwc2/hcd_queue.c:1744:25: error: expression requires 'long double' type support, but target 'x86_64-unknown-linux-gnu' does not support it delay = ktime_set(0, DWC2_RETRY_WAIT_DELAY); ^ drivers/usb/dwc2/hcd_queue.c:62:34: note: expanded from macro 'DWC2_RETRY_WAIT_DELAY' #define DWC2_RETRY_WAIT_DELAY (1 * 1E6L) ^ 1 error generated. This happens due to the use of a 'long double' literal. The 'E6' part of '1E6L' causes the literal to be a 'double' then the 'L' suffix promotes it to 'long double'. There is no visible reason for a floating point value in this driver, as the value is only used as a parameter to a function that expects an integer type. Use NSEC_PER_MSEC, which is the same integer value as '1E6L', to avoid changing functionality but fix the error. Link: ClangBuiltLinux#1497 Link: llvm/llvm-project@a8083d4 Fixes: 6ed30a7 ("usb: dwc2: host: use hrtimer for NAK retries") Cc: stable <stable@vger.kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: John Keeping <john@metanate.com> Acked-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20211105145802.2520658-1-nathan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

in case of a PCI dwc3 controller, leave the default DMA mask. Calling of a 64 bit DMA mask breaks the driver on cherrytrail based tablets like Cyberbook T116. Fixes: 45d3944 ("usb: dwc3: support 64 bit DMA in platform driver") Cc: stable <stable@vger.kernel.org> Reported-by: Hans De Goede <hdegoede@redhat.com> Tested-by: Fabio Aiuto <fabioaiuto83@gmail.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com> Link: https://lore.kernel.org/r/20211113142959.27191-1-fabioaiuto83@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The code that enables either BC_LVL or COMP_CHNG interrupt in tcpm_set_cc wrongly assumes that the interrupt is unmasked by writing 1 to the apropriate bit in the mask register. In fact, interrupts are enabled when the mask is 0, so the tcpm_set_cc enables interrupt for COMP_CHNG when it expects BC_LVL interrupt to be enabled. This causes inability of the driver to recognize cable unplug events in host mode (unplug is recognized only via a COMP_CHNG interrupt). In device mode this bug was masked by simultaneous triggering of the VBUS change interrupt, because of loss of VBUS when the port peer is providing power. Fixes: 48242e3 ("usb: typec: fusb302: Revert "Resolve fixed power role contract setup"") Cc: stable <stable@vger.kernel.org> Cc: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Ondrej Jirman <megous@megous.com> Link: https://lore.kernel.org/r/20211108102833.2793803-1-megous@megous.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xHC hardware can only have one slot in default state with address 0 waiting for a unique address at a time, otherwise "undefined behavior may occur" according to xhci spec 5.4.3.4 The address0_mutex exists to prevent this across both xhci roothubs. If hub_port_init() fails, it may unlock the mutex and exit with a xhci slot in default state. If the other xhci roothub calls hub_port_init() at this point we end up with two slots in default state. Make sure the address0_mutex protects the slot default state across hub_port_init() retries, until slot is addressed or disabled. Note, one known minor case is not fixed by this patch. If device needs to be reset during resume, but fails all hub_port_init() retries in usb_reset_and_verify_device(), then it's possible the slot is still left in default state when address0_mutex is unlocked. Cc: <stable@vger.kernel.org> Fixes: 638139e ("usb: hub: allow to process more usb hub events in parallel") Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211115221630.871204-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

…n probe If the first call to devm_usb_get_phy_by_phandle(dev, "fsl,usbphy", 0) fails with something other than -ENODEV then it leads to an error pointer dereference. For those errors we should just jump directly to the error handling. Fixes: 8253a34 ("usb: chipidea: ci_hdrc_imx: Also search for 'phys' phandle") Cc: stable <stable@vger.kernel.org> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20211117074923.GF5237@kili Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This is a partial revert of commit 29bc22a ("binder: use euid from cred instead of using task"). Setting sender_euid using proc->cred caused some Android system test regressions that need further investigation. It is a partial reversion because subsequent patches rely on proc->cred. Fixes: 29bc22a ("binder: use euid from cred instead of using task") Cc: stable@vger.kernel.org # 4.4+ Acked-by: Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by: Todd Kjos <tkjos@google.com> Change-Id: I9b1769a3510fed250bb21859ef8beebabe034c66 Link: https://lore.kernel.org/r/20211112180720.2858135-1-tkjos@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The prototype of mem_map_via_hcall() is missing in its header, so add it. Reported-by: kernel test robot <lkp@intel.com> Fixes: a43fb7d ("xen/pvh: Move Xen code for getting mem map via hcall out of common file") Signed-off-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20211119153913.21678-1-jgross@suse.com Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

Add the following Telit LE910S1 composition: 0x9200: tty Signed-off-by: Daniele Palmas <dnlplm@gmail.com> Link: https://lore.kernel.org/r/20211119140319.10448-1-dnlplm@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>

The i.MX 8QM DTS files use two compatibles, so update the binding to fix dtbs_check warnings like: arch/arm64/boot/dts/freescale/imx8qm-mek.dt.yaml: i2c@5a800000: compatible: ['fsl,imx8qm-lpi2c', 'fsl,imx7ulp-lpi2c'] is too long Signed-off-by: Abel Vesa <abel.vesa@nxp.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org>

If driver interrupts are enabled, SMBHSTCNT_INTREN will be 1 after the first transaction, and will stay to that value forever. This means that interrupts will be generated for both host-initiated transactions and also SMBus Alert events even after the driver is unloaded. To be on the safe side, we should restore the initial state of this bit at suspend and reboot time, as we do for several other configuration bits already and for the same reason: the BIOS should be handed the device in the same configuration state in which we received it. Otherwise interrupts may be generated which nobody will process. Signed-off-by: Jean Delvare <jdelvare@suse.de> Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>

Currently interrupt storm will occur from i2c-i801 after first transaction if SMB_ALERT signal is enabled and ever asserted. It is enough if the signal is asserted once even before the driver is loaded and does not recover because that interrupt is not acknowledged. This fix aims to fix it by two ways: - Add acknowledging for the SMB_ALERT interrupt status - Disable the SMB_ALERT interrupt on platforms where possible since the driver currently does not make use for it Acknowledging resets the SMB_ALERT interrupt status on all platforms and also should help to avoid interrupt storm on older platforms where the SMB_ALERT interrupt disabling is not available. For simplicity this fix reuses the host notify feature for disabling and restoring original register value. Link: https://bugzilla.kernel.org/show_bug.cgi?id=177311 Reported-by: ck+kernelbugzilla@bl4ckb0x.de Reported-by: stephane.poignant@protonmail.com Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: Jean Delvare <jdelvare@suse.de> Tested-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>

At least some PL2303GC have a bcdDevice of 0x105 instead of 0x100 as the datasheet claims. Add it to the list of known release numbers for the HXN (G) type. Note the chip type could only be determined indirectly based on its package being of QFP type, which appears to only be available for PL2303GC. Fixes: 894758d ("USB: serial: pl2303: tighten type HXN (G) detection") Cc: stable@vger.kernel.org # 5.13 Reported-by: Anton Lundin <glance@acc.umu.se> Link: https://lore.kernel.org/r/20211123071613.GZ108031@montezuma.acc.umu.se Link: https://lore.kernel.org/r/20211123091017.30708-1-johan@kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>

If a timeout is hit, it can result is incorrect data on the I2C bus and/or memory corruptions in the guest since the device can still be operating on the buffers it was given while the guest has freed them. Here is, for example, the start of a slub_debug splat which was triggered on the next transfer after one transfer was forced to timeout by setting a breakpoint in the backend (rust-vmm/vhost-device): BUG kmalloc-1k (Not tainted): Poison overwritten First byte 0x1 instead of 0x6b Allocated in virtio_i2c_xfer+0x65/0x35c age=350 cpu=0 pid=29 __kmalloc+0xc2/0x1c9 virtio_i2c_xfer+0x65/0x35c __i2c_transfer+0x429/0x57d i2c_transfer+0x115/0x134 i2cdev_ioctl_rdwr+0x16a/0x1de i2cdev_ioctl+0x247/0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 Freed in virtio_i2c_xfer+0x32e/0x35c age=244 cpu=0 pid=29 kfree+0x1bd/0x1cc virtio_i2c_xfer+0x32e/0x35c __i2c_transfer+0x429/0x57d i2c_transfer+0x115/0x134 i2cdev_ioctl_rdwr+0x16a/0x1de i2cdev_ioctl+0x247/0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 There is no simple fix for this (the driver would have to always create bounce buffers and hold on to them until the device eventually returns the buffers), so just disable the timeout support for now. Fixes: 3cfc883 ("i2c: virtio: add a virtio i2c frontend driver") Acked-by: Jie Deng <jie.deng@intel.com> Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Wolfram Sang <wsa@kernel.org>

Commit 5fa6863 ("spi: Check we have a spi_device_id for each DT compatible") added a test to check that every SPI driver has a spi_device_id for each DT compatiable string defined by the driver and warns if the spi_device_id is missing. The spi_device_id is missing for the MMC SPI driver and the following warning is now seen. WARNING KERN SPI driver mmc_spi has no spi_device_id for mmc-spi-slot Fix this by adding the necessary spi_device_id. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20211115113813.238044-1-jonathanh@nvidia.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

Sr is a repeated start, it is used in both I2C and SMBus protocols. Provide its description and replace start ("S") conditions with repeated start ("Sr") conditions when relevant. This allows the documentation to match the SMBus specification available at [1]. [1] http://www.smbus.org/specs/SMBus_3_1_20180319.pdf Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>

Fix the circular lock dependency and unbalanced unlock of addess0_mutex introduced when fixing an address0_mutex enumeration retry race in commit ae6dc22d2d1 ("usb: hub: Fix usb enumeration issue due to address0 race") Make sure locking order between port_dev->status_lock and address0_mutex is correct, and that address0_mutex is not unlocked in hub_port_connect "done:" codepath which may be reached without locking address0_mutex Fixes: 6ae6dc2 ("usb: hub: Fix usb enumeration issue due to address0 race") Cc: <stable@vger.kernel.org> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211123101656.1113518-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

SPSS should've been SSPS. Fixes: c9c14be ("usb: typec: tipd: Switch CD321X power state to S0") Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Sven Peter <sven@svenpeter.dev> Signed-off-by: Hector Martin <marcan@marcan.st> Link: https://lore.kernel.org/r/20211120030717.84287-2-marcan@marcan.st Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The power state switch needs to happen first, as that kickstarts the firmware into normal mode. Fixes: c9c14be ("usb: typec: tipd: Switch CD321X power state to S0") Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Sven Peter <sven@svenpeter.dev> Signed-off-by: Hector Martin <marcan@marcan.st> Link: https://lore.kernel.org/r/20211120030717.84287-3-marcan@marcan.st Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

When booting the xenbus driver will wait for PV devices to have connected to their backends before continuing. The timeout is different between essential and non-essential devices. Non-essential devices are identified by their nodenames directly in the xenbus driver, which requires to update this list in case a new device type being non-essential is added (this was missed for several types in the past). In order to avoid this problem, add a "not_essential" flag to struct xenbus_driver which can be set to "true" by the respective frontend. Set this flag for the frontends currently regarded to be not essential (vkbs and vfb) and use it for testing in the xenbus driver. Signed-off-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20211022064800.14978-2-jgross@suse.com Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

Similar to the virtual frame buffer (vfb) the pv display driver is not essential for booting the system. Set the respective flag. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: https://lore.kernel.org/r/20211022064800.14978-3-jgross@suse.com Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

The Xen pv console driver is not essential for boot. Set the respective flag. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: https://lore.kernel.org/r/20211022064800.14978-4-jgross@suse.com Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

The Xen pvcalls device is not essential for booting. Set the respective flag. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: https://lore.kernel.org/r/20211022064800.14978-5-jgross@suse.com Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

The Xen pv sound driver is not essential for booting. Set the respective flag. [boris: replace semicolon with comma] Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: https://lore.kernel.org/r/20211022064800.14978-6-jgross@suse.com Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

As Vincent reports in: https://lore.kernel.org/r/20211118163417.21617-1-vincent.whitchurch@axis.com The put_user() in schedule_tail() can get stuck in a livelock, similar to a problem recently fixed on riscv in commit: 285a76b ("riscv: evaluate put_user() arg before enabling user access") In __raw_put_user() we have a critical section between uaccess_ttbr0_enable() and uaccess_ttbr0_disable() where we cannot safely call into the scheduler without having taken an exception, as schedule() and other scheduling functions will not save/restore the TTBR0 state. If either of the `x` or `ptr` arguments to __raw_put_user() contain a blocking call, we may call into the scheduler within the critical section. This can result in two problems: 1) The access within the critical section will occur without the required TTBR0 tables installed. This will fault, and where the required tables permit access, the access will be retried without the required tables, resulting in a livelock. 2) When TTBR0 SW PAN is in use, check_and_switch_context() does not modify TTBR0, leaving a stale value installed. The mappings of the blocked task will erroneously be accessible to regular accesses in the context of the new task. Additionally, if the tables are subsequently freed, local TLB maintenance required to reuse the ASID may be lost, potentially resulting in TLB corruption (e.g. in the presence of CnP). The same issue exists for __raw_get_user() in the critical section between uaccess_ttbr0_enable() and uaccess_ttbr0_disable(). A similar issue exists for __get_kernel_nofault() and __put_kernel_nofault() for the critical section between __uaccess_enable_tco_async() and __uaccess_disable_tco_async(), as the TCO state is not context-switched by direct calls into the scheduler. Here the TCO state may be lost from the context of the current task, resulting in unexpected asynchronous tag check faults. It may also be leaked to another task, suppressing expected tag check faults. To fix all of these cases, we must ensure that we do not directly call into the scheduler in their respective critical sections. This patch reworks __raw_put_user(), __raw_get_user(), __get_kernel_nofault(), and __put_kernel_nofault(), ensuring that parameters are evaluated outside of the critical sections. To make this requirement clear, comments are added describing the problem, and line spaces added to separate the critical sections from other portions of the macros. For __raw_get_user() and __raw_put_user() the `err` parameter is conditionally assigned to, and we must currently evaluate this in the critical section. This behaviour is relied upon by the signal code, which uses chains of put_user_error() and get_user_error(), checking the return value at the end. In all cases, the `err` parameter is a plain int rather than a more complex expression with a blocking call, so this is safe. In future we should try to clean up the `err` usage to remove the potential for this to be a problem. Aside from the changes to time of evaluation, there should be no functional change as a result of this patch. Reported-by: Vincent Whitchurch <vincent.whitchurch@axis.com> Link: https://lore.kernel.org/r/20211118163417.21617-1-vincent.whitchurch@axis.com Fixes: f253d82 ("arm64: uaccess: refactor __{get,put}_user") Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20211122125820.55286-1-mark.rutland@arm.com Signed-off-by: Will Deacon <will@kernel.org>

If the xenstore page hasn't been allocated properly, reading the value of the related hvm_param (HVM_PARAM_STORE_PFN) won't actually return error. Instead, it will succeed and return zero. Instead of attempting to xen_remap a bad guest physical address, detect this condition and return early. Note that although a guest physical address of zero for HVM_PARAM_STORE_PFN is theoretically possible, it is not a good choice and zero has never been validly used in that capacity. Also recognize all bits set as an invalid value. For 32-bit Linux, any pfn above ULONG_MAX would get truncated. Pfns above ULONG_MAX should never be passed by the Xen tools to HVM guests anyway, so check for this condition and return early. Cc: stable@vger.kernel.org Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com> Reviewed-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Link: https://lore.kernel.org/r/20211123210748.1910236-1-sstabellini@kernel.org Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

Update the USB serial option driver support for the Fibocom FM101-GL Cat.6 LTE modules as there are actually several different variants. - VID:PID 2cb7:01a2, FM101-GL are laptop M.2 cards (with MBIM interfaces for /Linux/Chrome OS) - VID:PID 2cb7:01a4, FM101-GL for laptop debug M.2 cards(with adb interface for /Linux/Chrome OS) 0x01a2: mbim, tty, tty, diag, gnss 0x01a4: mbim, diag, tty, adb, gnss, gnss Here are the outputs of lsusb -v and usb-devices: T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 86 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 P: Vendor=2cb7 ProdID=01a2 Rev= 5.04 S: Manufacturer=Fibocom Wireless Inc. S: Product=Fibocom FM101-GL Module S: SerialNumber=673326ce C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=896mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=(none) I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=(none) I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=(none) I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=(none) Bus 002 Device 084: ID 2cb7:01a2 Fibocom Wireless Inc. Fibocom FM101-GL Module Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.20 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x2cb7 idProduct 0x01a2 bcdDevice 5.04 iManufacturer 1 Fibocom Wireless Inc. iProduct 2 Fibocom FM101-GL Module iSerial 3 673326ce bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x015d bNumInterfaces 6 bConfigurationValue 1 iConfiguration 4 MBIM_DUN_DUN_DIAG_NMEA bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 896mA Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 14 bFunctionProtocol 0 iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 14 bInterfaceProtocol 0 iInterface 5 Fibocom FM101-GL LTE Modem CDC Header: bcdCDC 1.10 CDC Union: bMasterInterface 0 bSlaveInterface 1 CDC MBIM: bcdMBIMVersion 1.00 wMaxControlMessage 4096 bNumberFilters 32 bMaxFilterSize 128 wMaxSegmentSize 2048 bmNetworkCapabilities 0x20 8-byte ntb input size CDC MBIM Extended: bcdMBIMExtendedVersion 1.00 bMaxOutstandingCommandMessages 64 wMTU 1500 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 9 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 bInterfaceProtocol 2 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 bInterfaceProtocol 2 iInterface 6 MBIM Data Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8e EP 14 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 6 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x0f EP 15 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 2 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 64 iInterface 0 ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 00 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 06 00 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 9 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 64 iInterface 0 ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 00 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 06 00 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 9 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 4 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 48 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 5 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 64 iInterface 0 ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 00 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 06 00 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x88 EP 8 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 9 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x87 EP 7 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 85 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 P: Vendor=2cb7 ProdID=01a4 Rev= 5.04 S: Manufacturer=Fibocom Wireless Inc. S: Product=Fibocom FM101-GL Module S: SerialNumber=673326ce C:* #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=896mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=(none) I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=(none) I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=(none) I:* If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=(none) Bus 002 Device 085: ID 2cb7:01a4 Fibocom Wireless Inc. Fibocom FM101-GL Module Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.20 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x2cb7 idProduct 0x01a4 bcdDevice 5.04 iManufacturer 1 Fibocom Wireless Inc. iProduct 2 Fibocom FM101-GL Module iSerial 3 673326ce bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0180 bNumInterfaces 7 bConfigurationValue 1 iConfiguration 4 MBIM_DIAG_DUN_ADB_GNSS_GNSS bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 896mA Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 14 bFunctionProtocol 0 iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 14 bInterfaceProtocol 0 iInterface 5 Fibocom FM101-GL LTE Modem CDC Header: bcdCDC 1.10 CDC Union: bMasterInterface 0 bSlaveInterface 1 CDC MBIM: bcdMBIMVersion 1.00 wMaxControlMessage 4096 bNumberFilters 32 bMaxFilterSize 128 wMaxSegmentSize 2048 bmNetworkCapabilities 0x20 8-byte ntb input size CDC MBIM Extended: bcdMBIMExtendedVersion 1.00 bMaxOutstandingCommandMessages 64 wMTU 1500 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 9 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 bInterfaceProtocol 2 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 bInterfaceProtocol 2 iInterface 6 MBIM Data Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8e EP 14 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 6 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x0f EP 15 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 2 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 48 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 64 iInterface 0 ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 00 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 06 00 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 9 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 4 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 66 bInterfaceProtocol 1 iInterface 8 ADB Interface Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 5 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 64 iInterface 0 ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 00 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 06 00 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x87 EP 7 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 9 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 6 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 64 iInterface 0 ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 00 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 06 00 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x89 EP 9 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 9 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x88 EP 8 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Signed-off-by: Mingjie Zhang <superzmj@fibocom.com> Link: https://lore.kernel.org/r/20211123133757.37475-1-superzmj@fibocom.com Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>

…ux/kernel/git/johan/usb-serial into usb-linus Johan writes: USB-serial fixes for 5.16-rc3 Here's a fix for a pl2303 type-detection issue and some new modem devices ids. All but the last commit have been in linux-next, and with no reported issues. * tag 'usb-serial-5.16-rc3' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: option: add Fibocom FM101-GL variants USB: serial: pl2303: fix GC type detection USB: serial: option: add Telit LE910S1 0x9200 composition

HYPERVISOR_get_debugreg() is being called from noinstr code, so it should be attributed "always_inline". Fixes: f4afb71 ("x86/xen: Make get_debugreg() noinstr") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: https://lore.kernel.org/r/20211125092056.24758-2-jgross@suse.com Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

HYPERVISOR_set_debugreg() is being called from noinstr code, so it should be attributed "always_inline". Fixes: 7361fac ("x86/xen: Make set_debugreg() noinstr") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: https://lore.kernel.org/r/20211125092056.24758-3-jgross@suse.com Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

…git/arm64/linux Pull arm64 fixes from Will Deacon: "Three arm64 fixes. The main one is a fix to the way in which we evaluate the macro arguments to our uaccess routines, which we _think_ might be the root cause behind some unkillable tasks we've seen in the Android arm64 CI farm (testing is ongoing). In any case, it's worth fixing. Other than that, we've toned down an over-zealous VM_BUG_ON() and fixed ftrace stack unwinding in a bunch of cases. Summary: - Evaluate uaccess macro arguments outside of the critical section - Tighten up VM_BUG_ON() in pmd_populate_kernel() to avoid false positive - Fix ftrace stack unwinding using HAVE_FUNCTION_GRAPH_RET_ADDR_PTR" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: uaccess: avoid blocking within critical sections arm64: mm: Fix VM_BUG_ON(mm != &init_mm) for trans_pgd arm64: ftrace: use HAVE_FUNCTION_GRAPH_RET_ADDR_PTR

…inux/kernel/git/xen/tip Pull xen fixes from Juergen Gross: - Kconfig fix to make it possible to control building of the privcmd driver - three fixes for issues identified by the kernel test robot - a five-patch series to simplify timeout handling for Xen PV driver initialization - two patches to fix error paths in xenstore/xenbus driver initialization * tag 'for-linus-5.16c-rc3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: xen: make HYPERVISOR_set_debugreg() always_inline xen: make HYPERVISOR_get_debugreg() always_inline xen: detect uninitialized xenbus in xenbus_init xen: flag xen_snd_front to be not essential for system boot xen: flag pvcalls-front to be not essential for system boot xen: flag hvc_xen to be not essential for system boot xen: flag xen_drm_front to be not essential for system boot xen: add "not_essential" flag to struct xenbus_driver xen/pvh: add missing prototype to header xen: don't continue xenstore initialization in case of errors xen/privcmd: make option visible in Kconfig

…kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: "I2C has an interrupt storm fix for the i801, better timeout handling for the new virtio driver, and some documentation fixes this time" * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: docs: i2c: smbus-protocol: mention the repeated start condition i2c: virtio: disable timeout handling i2c: i801: Fix interrupt storm from SMB_ALERT signal i2c: i801: Restore INTREN on unload dt-bindings: i2c: imx-lpi2c: Fix i.MX 8QM compatible matching

…l/git/ulfh/mmc Pull MMC host fixes from Ulf Hansson: - mmc_spi: Add SPI IDs to silence warning - sdhci: Fix ADMA for PAGE_SIZE >= 64KiB - sdhci-esdhc-imx: Disable broken CMDQ for imx8qm/imx8qxp/imx8mm * tag 'mmc-v5.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: mmc: spi: Add device-tree SPI IDs mmc: sdhci: Fix ADMA for PAGE_SIZE >= 64KiB mmc: sdhci-esdhc-imx: disable CMDQ support

…/git/gregkh/usb Pull USB fixes from Greg KH: "Here are a number of small USB fixes for reported problems for 5.16-rc3 They include: - typec driver fixes - new usb-serial driver ids - usb hub enumeration issues that were much reported - gadget driver fixes - dwc3 driver fix - chipidea driver fixe All of these have been in linux-next with no reported problems" * tag 'usb-5.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: USB: serial: option: add Fibocom FM101-GL variants usb: typec: tipd: Fix initialization sequence for cd321x usb: typec: tipd: Fix typo in cd321x_switch_power_state usb: hub: Fix locking issues with address0_mutex USB: serial: pl2303: fix GC type detection USB: serial: option: add Telit LE910S1 0x9200 composition usb: chipidea: ci_hdrc_imx: fix potential error pointer dereference in probe usb: hub: Fix usb enumeration issue due to address0 race usb: typec: fusb302: Fix masking of comparator and bc_lvl interrupts usb: dwc3: leave default DMA for PCI devices usb: dwc2: hcd_queue: Fix use of floating point literal usb: dwc3: gadget: Fix null pointer exception usb: gadget: udc-xilinx: Fix an error handling path in 'xudc_probe()' usb: xhci: tegra: Check padctrl interrupt presence in device tree usb: dwc2: gadget: Fix ISOC flow for elapsed frames usb: dwc3: gadget: Check for L1/L2/U3 for Start Transfer usb: dwc3: gadget: Ignore NoStream after End Transfer usb: dwc3: core: Revise GHWPARAMS9 offset

…rnel/git/gregkh/staging Pull staging fixes from Greg KH: "Here are some small staging driver fixes and one driver removal for 5.16-rc3. The fixes resolve a number of small issues found in 5.16-rc1, nothing huge at all. The driver removal was due to a platform being removed in 5.16-rc1, but this driver was forgotten about. It wasn't being built anymore so it's safe to delete. All have been in linux-next for a while with no reported problems" * tag 'staging-5.16-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: staging: rtl8192e: Fix use after free in _rtl92e_pci_disconnect() staging: greybus: Add missing rwsem around snd_ctl_remove() calls staging: Remove Netlogic XLP network driver staging: r8188eu: fix a memory leak in rtw_wx_read32() staging: r8188eu: use GFP_ATOMIC under spinlock staging: r8188eu: Use kzalloc() with GFP_ATOMIC in atomic context staging/fbtft: Fix backlight staging: r8188eu: Fix breakage introduced when 5G code was removed

…kernel/git/gregkh/char-misc Pull char/misc driver fix from Greg KH: "Here is a single binder driver fix for 5.16-rc3. It resolves a problem reported in the set of binder fixes that went into 5.16-rc1. It has been in linux-next for a while with no reported problems" * tag 'char-misc-5.16-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: binder: fix test regression due to sender_euid change

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[pull] master from torvalds:master #838

[pull] master from torvalds:master #838

Commits on Nov 15, 2021

Commits on Nov 16, 2021

Commits on Nov 17, 2021

Commits on Nov 19, 2021

Commits on Nov 22, 2021

Commits on Nov 23, 2021

Commits on Nov 24, 2021

Commits on Nov 25, 2021

Commits on Nov 26, 2021