- Sep 20, 2022
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220916100446.916515275@linuxfoundation.org Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Bagas Sanjaya <bagasdotme@gmail.com> Tested-by:
Ron Economos <re@w6rz.net> Tested-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jarrah Gosbell authored
commit 80b9ebd3 upstream. Add compatible string for GT1158 missing from the previous patch. Fixes: 425fe470 ("Input: goodix - add support for GT1158") Signed-off-by:
Jarrah Gosbell <kernel@undef.tools> Link: https://lore.kernel.org/r/20220813043821.9981-1-kernel@undef.tools Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Sindhu-Devale authored
commit 2c884443 upstream. Send with invalidate verb call can pass in an uninitialized s/g array with 0 sge's which is filled into irdma WQE and causes a HW asynchronous event. Fix this by using the s/g array in irdma post send only when its valid. Fixes: 551c46ed ("RDMA/irdma: Add user/kernel shared libraries") Signed-off-by:
Sindhu-Devale <sindhu.devale@intel.com> Signed-off-by:
Shiraz Saleem <shiraz.saleem@intel.com> Link: https://lore.kernel.org/r/20220906223244.1119-5-shiraz.saleem@intel.com Signed-off-by:
Leon Romanovsky <leon@kernel.org> Signed-off-by:
-
Jing Leng authored
commit f511aef2 upstream. On page 362 of the USB3.2 specification ( https://usb.org/sites/default/files/usb_32_20210125.zip), The 'SuperSpeed Endpoint Companion Descriptor' shall only be returned by Enhanced SuperSpeed devices that are operating at Gen X speed. Each endpoint described in an interface is followed by a 'SuperSpeed Endpoint Companion Descriptor'. If users use SuperSpeed UDC, host can't recognize the device if endpoint doesn't have 'SuperSpeed Endpoint Companion Descriptor' followed. Currently in the uac2 driver code: 1. ss_epout_desc_comp follows ss_epout_desc; 2. ss_epin_fback_desc_comp follows ss_epin_fback_desc; 3. ss_epin_desc_comp follows ss_epin_desc; 4. Only ss_ep_int_desc endpoint doesn't have 'SuperSpeed Endpoint Companion Descriptor' followed, so we should add it. Fixes: eaf6cbe0 ("usb: gadget: f_uac2: add volume and mute support") Cc: stable <stable@kernel.org> Signed-off-by:
Jing Leng <jleng@ambarella.com> Signed-off-by:
Jack Pham <quic_jackp@quicinc.com> Link: https://lore.kernel.org/r/20220721014815.14453-1-quic_jackp@quicinc.com Signed-off-by:
-
Colin Ian King authored
commit 18d6b39e upstream. There are bunch of statements where the indentation is not correct, clean these up. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20210902224758.57600-1-colin.king@canonical.com Signed-off-by:
-
Mathew McBride authored
commit 9a472613 upstream. The soc/fsl/dpio driver will perform a soc_device_match() to determine the optimal cache settings for a given CPU core. If FSL_GUTS is not enabled, this search will fail and the driver will not configure cache stashing for the given DPIO, and a string of "unknown SoC" messages will appear: fsl_mc_dpio dpio.7: unknown SoC version fsl_mc_dpio dpio.6: unknown SoC version fsl_mc_dpio dpio.5: unknown SoC version Fixes: 51da14e9 ("soc: fsl: dpio: configure cache stashing destination") Signed-off-by:
Mathew McBride <matt@traverse.com.au> Reviewed-by:
Ioana Ciornei <ioana.ciornei@nxp.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220901052149.23873-2-matt@traverse.com.au ' Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Jann Horn authored
This is a stable-specific patch. I botched the stable-specific rewrite of commit b67fbebd ("mmu_gather: Force tlb-flush VM_PFNMAP vmas"): As Hugh pointed out, unmap_region() actually operates on a list of VMAs, and the variable "vma" merely points to the first VMA in that list. So if we want to check whether any of the VMAs we're operating on is PFNMAP or MIXEDMAP, we have to iterate through the list and check each VMA. Signed-off-by:
Jann Horn <jannh@google.com> Signed-off-by:
-
Hu Xiaoying authored
[ Upstream commit c61feaee ] USB external storage device(0x0b05:1932), use gnome-disk-utility tools to test usb write < 30MB/s. if does not to load module of uas for this device, can increase the write speed from 20MB/s to >40MB/s. Suggested-by:
Matthias Kaehlcke <mka@chromium.org> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Hu Xiaoying <huxiaoying@kylinos.cn> Link: https://lore.kernel.org/r/20220901045737.3438046-1-huxiaoying@kylinos.cn Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Hans de Goede authored
[ Upstream commit c3b82d26 ] 2 keymap fixes for the Acer Aspire One AOD270 and the same hardware rebranded as Packard Bell Dot SC: 1. The F2 key is marked with a big '?' symbol on the Packard Bell Dot SC, this sends WMID_HOTKEY_EVENTs with a scancode of 0x27 add a mapping for this. 2. Scancode 0x61 is KEY_SWITCHVIDEOMODE. Usually this is a duplicate input event with the "Video Bus" input device events. But on these devices the "Video Bus" does not send events for this key. Map 0x61 to KEY_UNKNOWN instead of using KE_IGNORE so that udev/hwdb can override it on these devs. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20220829163544.5288-1-hdegoede@redhat.com Signed-off-by:
-
Yu Zhe authored
[ Upstream commit 6bb0d64c ] The platform_get_irq() returns negative error codes. It can't actually return zero. Signed-off-by:
Yu Zhe <yuzhe@nfschina.com> Link: https://lore.kernel.org/r/20220825011844.8536-1-yuzhe@nfschina.com Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
-
Kurt Kanzenbach authored
[ Upstream commit 52267ce2 ] In case the source port cannot be decoded, print the warning only once. This still brings attention to the user and does not spam the logs at the same time. Signed-off-by:
Kurt Kanzenbach <kurt@linutronix.de> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20220830163448.8921-1-kurt@linutronix.de Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Chengming Gui authored
[ Upstream commit 39c84b8e ] Restrict the ucode loading check to avoid frontdoor loading error. Signed-off-by:
Chengming Gui <Jack.Gui@amd.com> Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Maurizio Lombardi authored
[ Upstream commit 478814a5 ] TCP_FIN_WAIT2 and TCP_LAST_ACK were not handled, the connection is closing so we can ignore them and avoid printing the "unhandled state" warning message. [ 1298.852386] nvmet_tcp: queue 2 unhandled state 5 [ 1298.879112] nvmet_tcp: queue 7 unhandled state 5 [ 1298.884253] nvmet_tcp: queue 8 unhandled state 5 [ 1298.889475] nvmet_tcp: queue 9 unhandled state 5 v2: Do not call nvmet_tcp_schedule_release_queue(), just ignore the fin_wait2 and last_ack states. Signed-off-by:
Maurizio Lombardi <mlombard@redhat.com> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Reviewed-by:
Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Greg Tulli authored
[ Upstream commit 9c9c7116 ] Add a new iforce_device entry to support the Boeder Force Feedback Wheel device. Signed-off-by:
Greg Tulli <greg.iforce@gmail.com> Link: https://lore.kernel.org/r/3256420-c8ac-31b-8499-3c488a9880fd@gmail.com Signed-off-by:
-
Li Qiong authored
[ Upstream commit ffd7bddd ] The rc code is 0 at the error path "status & CC2520_STATUS_TX_UNDERFLOW". Assign rc code with '-EINVAL' at this error path to fix it. Signed-off-by:
Li Qiong <liqiong@nfschina.com> Link: https://lore.kernel.org/r/20220829071259.18330-1-liqiong@nfschina.com Signed-off-by:
Stefan Schmidt <stefan@datenfreihafen.org> Signed-off-by:
-
Wei Yongjun authored
[ Upstream commit 303e6da9 ] GPIO mockup debugfs is created in gpio_mockup_probe() but forgot to remove when remove device. This patch add a devm managed callback for removing them. Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by:
-
Kai-Heng Feng authored
[ Upstream commit 2ca1c94c ] Commit d60cd063 ("PM: ACPI: reboot: Use S5 for reboot") caused a reboot hang on one Dell servers so the commit was reverted. Someone managed to collect the AER log and it's caused by MSI: [ 148.762067] ACPI: Preparing to enter system sleep state S5 [ 148.794638] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 5 [ 148.803731] {1}[Hardware Error]: event severity: recoverable [ 148.810191] {1}[Hardware Error]: Error 0, type: fatal [ 148.816088] {1}[Hardware Error]: section_type: PCIe error [ 148.822391] {1}[Hardware Error]: port_type: 0, PCIe end point [ 148.829026] {1}[Hardware Error]: version: 3.0 [ 148.834266] {1}[Hardware Error]: command: 0x0006, status: 0x0010 [ 148.841140] {1}[Hardware Error]: device_id: 0000:04:00.0 [ 148.847309] {1}[Hardware Error]: slot: 0 [ 148.852077] {1}[Hardware Error]: secondary_bus: 0x00 [ 148.857876] {1}[Hardware Error]: vendor_id: 0x14e4, device_id: 0x165f [ 148.865145] {1}[Hardware Error]: class_code: 020000 [ 148.870845] {1}[Hardware Error]: aer_uncor_status: 0x00100000, aer_uncor_mask: 0x00010000 [ 148.879842] {1}[Hardware Error]: aer_uncor_severity: 0x000ef030 [ 148.886575] {1}[Hardware Error]: TLP Header: 40000001 0000030f 90028090 00000000 [ 148.894823] tg3 0000:04:00.0: AER: aer_status: 0x00100000, aer_mask: 0x00010000 [ 148.902795] tg3 0000:04:00.0: AER: [20] UnsupReq (First) [ 148.910234] tg3 0000:04:00.0: AER: aer_layer=Transaction Layer, aer_agent=Requester ID [ 148.918806] tg3 0000:04:00.0: AER: aer_uncor_severity: 0x000ef030 [ 148.925558] tg3 0000:04:00.0: AER: TLP Header: 40000001 0000030f 90028090 00000000 The MSI is probably raised by incoming packets, so power down the device and disable bus mastering to stop the traffic, as user confirmed this approach works. In addition to that, be extra safe and cancel reset task if it's running. Cc: Josef Bacik <josef@toxicpanda.com> Link: https://lore.kernel.org/all/b8db79e6857c41dab4ef08bdf826ea7c47e3bafc.1615947283.git.josef@toxicpanda.com/ BugLink: https://bugs.launchpad.net/bugs/1917471 Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Reviewed-by:
Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20220826002530.1153296-1-kai.heng.feng@canonical.com Signed-off-by:
-
Even Xu authored
[ Upstream commit e1fa0767 ] There is a timing issue captured during ishtp client sending stress tests. It was observed during stress tests that ISH firmware is getting out of ordered messages. This is a rare scenario as the current set of ISH client drivers don't send much data to firmware. But this may not be the case going forward. When message size is bigger than IPC MTU, ishtp splits the message into fragments and uses serialized async method to send message fragments. The call stack: ishtp_cl_send_msg_ipc->ipc_tx_callback(first fregment)-> ishtp_send_msg(with callback)->write_ipc_to_queue-> write_ipc_from_queue->callback->ipc_tx_callback(next fregment)...... When an ipc write complete interrupt is received, driver also calls write_ipc_from_queue->ipc_tx_callback in ISR to start sending of next fragment. Through ipc_tx_callback uses spin_lock to protect message splitting, as the serialized sending method will call back to ipc_tx_callback again, so it doesn't put sending under spin_lock, it causes driver cannot guarantee all fragments be sent in order. Considering this scenario: ipc_tx_callback just finished a fragment splitting, and not call ishtp_send_msg yet, there is a write complete interrupt happens, then ISR->write_ipc_from_queue ->ipc_tx_callback->ishtp_send_msg->write_ipc_to_queue...... Because ISR has higher exec priority than normal thread, this causes the new fragment be sent out before previous fragment. This disordered message causes invalid message to firmware. The solution is, to send fragments synchronously: Use ishtp_write_message writing fragments into tx queue directly one by one, instead of ishtp_send_msg only writing one fragment with completion callback. As no completion callback be used, so change ipc_tx_callback to ipc_tx_send. Signed-off-by:
Even Xu <even.xu@intel.com> Acked-by:
Srinivas Pandruvada <srinivas.pandruvada@intel.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Jason Wang authored
[ Upstream commit 94553f8a ] The double `like' is duplicated in the comment, remove one. Signed-off-by:
Jason Wang <wangborong@cdjrlc.com> Signed-off-by:
-
Krzysztof Kozlowski authored
[ Upstream commit 76747020 ] BMG160 has two interrupt pins to which interrupts can be freely mapped. Correct the schema to express such case and fix warnings like: qcom/msm8916-alcatel-idol347.dtb: gyroscope@68: interrupts: [[97, 1], [98, 1]] is too long However the basic issue still persists - the interrupts should come in a defined order. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220805075503.16983-1-krzysztof.kozlowski@linaro.org Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Rob Clark authored
[ Upstream commit 174974d8 ] If the previous thing cat'ing $debugfs/rd left the FIFO full, then subsequent open could deadlock in rd_write() (because open is blocked, not giving a chance for read() to consume any data in the FIFO). Also it is generally a good idea to clear out old data from the FIFO. Signed-off-by:
Rob Clark <robdclark@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/496706/ Link: https://lore.kernel.org/r/20220807160901.2353471-2-robdclark@gmail.com Signed-off-by:
-
Maximilian Luz authored
[ Upstream commit 84b8e403 ] The Surface Laptop Go 2 seems to have the same SAM client devices as the Surface Laptop Go 1, so re-use its node group. Signed-off-by:
Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20220810140133.99087-1-luzmaximilian@gmail.com Signed-off-by:
-
Ondrej Jirman authored
[ Upstream commit 425fe470 ] This controller is used by PinePhone and PinePhone Pro. Support for the PinePhone Pro will be added in a later patch set. Signed-off-by:
Ondrej Jirman <megi@xff.cz> Signed-off-by:
-
Lu Baolu authored
[ Upstream commit 0c5f6c0d ] The translation table copying code for kdump kernels is currently based on the extended root/context entry formats of ECS mode defined in older VT-d v2.5, and doesn't handle the scalable mode formats. This causes the kexec capture kernel boot failure with DMAR faults if the IOMMU was enabled in scalable mode by the previous kernel. The ECS mode has already been deprecated by the VT-d spec since v3.0 and Intel IOMMU driver doesn't support this mode as there's no real hardware implementation. Hence this converts ECS checking in copying table code into scalable mode. The existing copying code consumes a bit in the context entry as a mark of copied entry. It needs to work for the old format as well as for the extended context entries. As it's hard to find such a common bit for both legacy and scalable mode context entries. This replaces it with a per- IOMMU bitmap. Fixes: 7373a8cc ("iommu/vt-d: Setup context and enable RID2PASID support") Cc: stable@vger.kernel.org Reported-by:
Jerry Snitselaar <jsnitsel@redhat.com> Tested-by:
Wen Jin <wen.jin@intel.com> Signed-off-by:
Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20220817011035.3250131-1-baolu.lu@linux.intel.com Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Brian Norris authored
[ Upstream commit 47311db8 ] Users may have explicitly configured their tracefs permissions; we shouldn't overwrite those just because a second mount appeared. Only clobber if the options were provided at mount time. Note: the previous behavior was especially surprising in the presence of automounted /sys/kernel/debug/tracing/. Existing behavior: ## Pre-existing status: tracefs is 0755. # stat -c '%A' /sys/kernel/tracing/ drwxr-xr-x ## (Re)trigger the automount. # umount /sys/kernel/debug/tracing # stat -c '%A' /sys/kernel/debug/tracing/. drwx------ ## Unexpected: the automount changed mode for other mount instances. # stat -c '%A' /sys/kernel/tracing/ drwx------ New behavior (after this change): ## Pre-existing status: tracefs is 0755. # stat -c '%A' /sys/kernel/tracing/ drwxr-xr-x ## (Re)trigger the automount. # umount /sys/kernel/debug/tracing # stat -c '%A' /sys/kernel/debug/tracing/. drwxr-xr-x ## Expected: the automount does not change other mount instances. # stat -c '%A' /sys/kernel/tracing/ drwxr-xr-x Link: https://lkml.kernel.org/r/20220826174353.2.Iab6e5ea57963d6deca5311b27fb7226790d44406@changeid Cc: stable@vger.kernel.org Fixes: 4282d606 ("tracefs: Add new tracefs file system") Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by:
-
Yipeng Zou authored
[ Upstream commit 54c39319 ] Currently, The arguments passing to lockdep_hardirqs_{on,off} was fixed in CALLER_ADDR0. The function trace_hardirqs_on_caller should have been intended to use caller_addr to represent the address that caller wants to be traced. For example, lockdep log in riscv showing the last {enabled,disabled} at __trace_hardirqs_{on,off} all the time(if called by): [ 57.853175] hardirqs last enabled at (2519): __trace_hardirqs_on+0xc/0x14 [ 57.853848] hardirqs last disabled at (2520): __trace_hardirqs_off+0xc/0x14 After use trace_hardirqs_xx_caller, we can get more effective information: [ 53.781428] hardirqs last enabled at (2595): restore_all+0xe/0x66 [ 53.782185] hardirqs last disabled at (2596): ret_from_exception+0xa/0x10 Link: https://lkml.kernel.org/r/20220901104515.135162-2-zouyipeng@huawei.com Cc: stable@vger.kernel.org Fixes: c3bc8fd6 ("tracing: Centralize preemptirq tracepoints and unify their usage") Signed-off-by:
Yipeng Zou <zouyipeng@huawei.com> Signed-off-by:
-
Borislav Petkov authored
[ Upstream commit e87f4152 ] Force-inline two stack helpers to fix the following objtool warnings: vmlinux.o: warning: objtool: in_task_stack()+0xc: call to task_stack_page() leaves .noinstr.text section vmlinux.o: warning: objtool: in_entry_stack()+0x10: call to cpu_entry_stack() leaves .noinstr.text section Signed-off-by:
Borislav Petkov <bp@suse.de> Acked-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20220324183607.31717-2-bp@alien8.de Stable-dep-of: 54c39319 ("tracing: hold caller_addr to hardirq_{enable,disable}_ip") Signed-off-by:
-
Borislav Petkov authored
[ Upstream commit ace1a985 ] Fix: vmlinux.o: warning: objtool: __sev_es_nmi_complete()+0x8b: call to __phys_addr_nodebug() leaves .noinstr.text section Signed-off-by:
-
Nick Desaulniers authored
[ Upstream commit 8b023acc ] While looking into a bug related to the compiler's handling of addresses of labels, I noticed some uses of _THIS_IP_ seemed unused in lockdep. Drive by cleanup. -Wunused-parameter: kernel/locking/lockdep.c:1383:22: warning: unused parameter 'ip' kernel/locking/lockdep.c:4246:48: warning: unused parameter 'ip' kernel/locking/lockdep.c:4844:19: warning: unused parameter 'ip' Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Waiman Long <longman@redhat.com> Link: https://lore.kernel.org/r/20220314221909.2027027-1-ndesaulniers@google.com Stable-dep-of: 54c39319 ("tracing: hold caller_addr to hardirq_{enable,disable}_ip") Signed-off-by:
-
Claudiu Beznea authored
[ Upstream commit 7f41d52c ] Min and max output ranges of regulators need to satisfy board requirements not PMIC requirements. Thus adjust device tree to cope with this. Fixes: 7540629e ("ARM: dts: at91: add sama7g5 SoC DT and sama7g5-ek") Signed-off-by:
Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/20220826083927.3107272-7-claudiu.beznea@microchip.com Signed-off-by:
-
Claudiu Beznea authored
[ Upstream commit 279d626d ] Fix low limit for CPU regulator. Otherwise setting voltages lower than 1.125V will not be allowed (CPUFreq will not be allowed to set proper voltages on proper frequencies). Signed-off-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20220113144900.906370-7-claudiu.beznea@microchip.com Stable-dep-of: 7f41d52c ("ARM: dts: at91: sama7g5ek: specify proper regulator output ranges") Signed-off-by:
-
Marco Felsch authored
[ Upstream commit af7d78c9 ] Drop the "winbond,w25q16dw" compatible since it causes to set the MODALIAS to w25q16dw which is not specified within spi-nor id table. Fix this by use the common "jedec,spi-nor" compatible. Fixes: 21252127 ("ARM: dts: imx6qdl-kontron-samx6i: add Kontron SMARC SoM Support") Signed-off-by:
Marco Felsch <m.felsch@pengutronix.de> Signed-off-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
-
Krzysztof Kozlowski authored
[ Upstream commit ba9fe460 ] The node names should be generic and SPI NOR dtschema expects "flash". Signed-off-by:
-
Chuanhong Guo authored
commit 9946e39f upstream. IRQ override isn't needed on modern AMD Zen systems. There's an active low keyboard IRQ on AMD Ryzen 6000 and it will stay this way on newer platforms. This IRQ override breaks keyboards for almost all Ryzen 6000 laptops currently on the market. Skip this IRQ override for all AMD Zen platforms because this IRQ override is supposed to be a workaround for buggy ACPI DSDT and we can't have a long list of all future AMD CPUs/Laptops in the kernel code. If a device with buggy ACPI DSDT shows up, a separated list containing just them should be created. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216118 Suggested-by:
Mario Limonciello <mario.limonciello@amd.com> Signed-off-by:
Chuanhong Guo <gch981213@gmail.com> Acked-by:
XiaoYan Li <lxy.lixiaoyan@gmail.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Dave Wysochanski authored
commit 0ebeebcf upstream. Fixes the following WARN_ON WARNING: CPU: 2 PID: 18678 at fs/nfs/inode.c:123 nfs_clear_inode+0x3b/0x50 [nfs] ... Call Trace: nfs4_evict_inode+0x57/0x70 [nfsv4] evict+0xd1/0x180 dispose_list+0x48/0x60 evict_inodes+0x156/0x190 generic_shutdown_super+0x37/0x110 nfs_kill_super+0x1d/0x40 [nfs] deactivate_locked_super+0x36/0xa0 Signed-off-by:
Dave Wysochanski <dwysocha@redhat.com> Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by:
-
- Sep 15, 2022
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220913140357.323297659@linuxfoundation.org Tested-by:
Bagas Sanjaya <bagasdotme@gmail.com>=20> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
-
Claudiu Beznea authored
[ Upstream commit dc300570 ] Remove CONFIG_SOC_SAMA7 dependency to avoid having #ifdef preprocessor directives in driver code (arch/arm/mach-at91/pm.c). This prepares the code for next commits. Signed-off-by:
-
Arnaldo Carvalho de Melo authored
commit 9d5f0c36 upstream. Its more intention revealing, and if we're interested in the odd cases where this may end up truncating we can do debug checks at one centralized place. Motivation, of all the container builds, fedora rawhide started complaining of: util/machine.c: In function ‘machine__create_modules’: util/machine.c:1419:50: error: ‘%s’ directive output may be truncated writing up to 255 bytes into a region of size between 0 and 4095 [-Werror=format-truncation=] 1419 | snprintf(path, sizeof(path), "%s/%s", dir_name, dent->d_name); | ^~ In file included from /usr/include/stdio.h:894, from util/branch.h:9, from util/callchain.h:8, from util/machine.c:7: In function ‘snprintf’, inlined from ‘maps__set_modules_path_dir’ at util/machine.c:1419:3, inlined from ‘machine__set_modules_path’ at util/machine.c:1473:9, inlined from ‘machine__create_modules’ at util/machine.c:1519:7: /usr/include/bits/stdio2.h:71:10: note: ‘__builtin___snprintf_chk’ output between 2 and 4352 bytes into a destination of size 4096 There are other places where we should use path__join(), but lets get rid of this one first. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Acked-by:
Ian Rogers <irogers@google.com> Link: Link: https://lore.kernel.org/r/YebZKjwgfdOz0lAs@kernel.org Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
Jisheng Zhang <jszhang@kernel.org> Signed-off-by:
-
Neil Armstrong authored
commit 7cd70656 upstream. Since this bridge is tied to the connector, it acts like a passthrough, so concerning the output & input bus formats, either pass the bus formats from the previous bridge or return fallback data like done in the bridge function: drm_atomic_bridge_chain_select_bus_fmts() & select_bus_fmt_recursive. This permits avoiding skipping the negociation if the remaining bridge chain has all the bits in place. Without this bus fmt negociation breaks on drm/meson HDMI pipeline when attaching dw-hdmi with DRM_BRIDGE_ATTACH_NO_CONNECTOR, because the last bridge of the display-connector doesn't implement buf fmt callbacks and MEDIA_BUS_FMT_FIXED is used leading to select an unsupported default bus format from dw-hdmi. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211020123947.2585572-2-narmstrong@baylibre.com Cc: Stefan Agner <stefan@agner.ch> Signed-off-by:
-
Ionela Voinescu authored
commit e89d120c upstream. The AMU counter AMEVCNTR01 (constant counter) should increment at the same rate as the system counter. On affected Cortex-A510 cores, AMEVCNTR01 increments incorrectly giving a significantly higher output value. This results in inaccurate task scheduler utilization tracking and incorrect feedback on CPU frequency. Work around this problem by returning 0 when reading the affected counter in key locations that results in disabling all users of this counter from using it either for frequency invariance or as FFH reference counter. This effect is the same to firmware disabling affected counters. Details on how the two features are affected by this erratum: - AMU counters will not be used for frequency invariance for affected CPUs and CPUs in the same cpufreq policy. AMUs can still be used for frequency invariance for unaffected CPUs in the system. Although unlikely, if no alternative method can be found to support frequency invariance for affected CPUs (cpufreq based or solution based on platform counters) frequency invariance will be disabled. Please check the chapter on frequency invariance at Documentation/scheduler/sched-capacity.rst for details of its effect. - Given that FFH can be used to fetch either the core or constant counter values, restrictions are lifted regarding any of these counters returning a valid (!0) value. Therefore FFH is considered supported if there is a least one CPU that support AMUs, independent of any counters being disabled or affected by this erratum. Clarifying comments are now added to the cpc_ffh_supported(), cpu_read_constcnt() and cpu_read_corecnt() functions. The above is achieved through adding a new erratum: ARM64_ERRATUM_2457168. Signed-off-by:
Ionela Voinescu <ionela.voinescu@arm.com> Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: James Morse <james.morse@arm.com> Link: https://lore.kernel.org/r/20220819103050.24211-1-ionela.voinescu@arm.com Signed-off-by:
-
