summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-09-16x86/msi: Move compose message callback where it belongsThomas Gleixner
Composing the MSI message at the MSI chip level is wrong because the underlying parent domain is the one which knows how the message should be composed for the direct vector delivery or the interrupt remapping table entry. The interrupt remapping aware PCI/MSI chip does that already. Make the direct delivery chip do the same and move the composition of the direct delivery MSI message to the vector domain irq chip. This prepares for the upcoming device MSI support to avoid having architecture specific knowledge in the device MSI domain irq chips. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20200826112331.157603198@linutronix.de
2020-09-16genirq/chip: Use the first chip in irq_chip_compose_msi_msg()Thomas Gleixner
The documentation of irq_chip_compose_msi_msg() claims that with hierarchical irq domains the first chip in the hierarchy which has an irq_compose_msi_msg() callback is chosen. But the code just keeps iterating after it finds a chip with a compose callback. The x86 HPET MSI implementation relies on that behaviour, but that does not make it more correct. The message should always be composed at the domain which manages the underlying resource (e.g. APIC or remap table) because that domain knows about the required layout of the message. On X86 the following hierarchies exist: 1) vector -------- PCI/MSI 2) vector -- IR -- PCI/MSI The vector domain has a different message format than the IR (remapping) domain. So obviously the PCI/MSI domain can't compose the message without having knowledge about the parent domain, which is exactly the opposite of what hierarchical domains want to achieve. X86 actually has two different PCI/MSI chips where #1 has a compose callback and #2 does not. #2 delegates the composition to the remap domain where it belongs, but #1 does it at the PCI/MSI level. For the upcoming device MSI support it's necessary to change this and just let the first domain which can compose the message take care of it. That way the top level chip does not have to worry about it and the device MSI code does not need special knowledge about topologies. It just sets the compose callback to NULL and lets the hierarchy pick the first chip which has one. Due to that the attempt to move the compose callback from the direct delivery PCI/MSI domain to the vector domain made the system fail to boot with interrupt remapping enabled because in the remapping case irq_chip_compose_msi_msg() keeps iterating and choses the compose callback of the vector domain which obviously creates the wrong format for the remap table. Break out of the loop when the first irq chip with a compose callback is found and fixup the HPET code temporarily. That workaround will be removed once the direct delivery compose callback is moved to the place where it belongs in the vector domain. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200826112331.047917603@linutronix.de
2020-09-16PCI: vmd: Dont abuse vector irqomain as parentThomas Gleixner
VMD has it's own PCI/MSI interrupt domain which is not in any way depending on the x86 vector domain. PCI devices behind VMD share the VMD MSIX vector entries via a VMD specific message translation to the actual VMD MSIX vector. The VMD device interrupt handler for the VMD MSIX vectors invokes all interrupt handlers of the devices which share a vector. Making the x86 vector domain the actual parent of the VMD irq domain is pointless and actually counterproductive. When a device interrupt is requested then it will activate the interrupt which traverses down the hierarchy and consumes an interrupt vector in the vector domain which is never used. The domain is self contained and has no parent dependencies, so just hand in NULL for the parent and be done with it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20200826112330.928952181@linutronix.de
2020-09-16x86/init: Remove unused init opsThomas Gleixner
Some past platform removal forgot to get rid of this unused ballast. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20200826112330.806095671@linutronix.de
2020-09-16iommu/amd: Prevent NULL pointer dereferenceThomas Gleixner
Dereferencing irq_data before checking it for NULL is suboptimal. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Joerg Roedel <jroedel@suse.de>
2020-09-16seqlock: Unbreak lockdeppeterz@infradead.org
seqcount_LOCKNAME_init() needs to be a macro due to the lockdep annotation in seqcount_init(). Since a macro cannot define another macro, we need to effectively revert commit: e4e9ab3f9f91 ("seqlock: Fold seqcount_LOCKNAME_init() definition"). Fixes: e4e9ab3f9f91 ("seqlock: Fold seqcount_LOCKNAME_init() definition") Reported-by: Qian Cai <cai@redhat.com> Debugged-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Qian Cai <cai@redhat.com> Link: https://lkml.kernel.org/r/20200915143028.GB2674@hirez.programming.kicks-ass.net
2020-09-16locking/percpu-rwsem: Use this_cpu_{inc,dec}() for read_countHou Tao
The __this_cpu*() accessors are (in general) IRQ-unsafe which, given that percpu-rwsem is a blocking primitive, should be just fine. However, file_end_write() is used from IRQ context and will cause load-store issues on architectures where the per-cpu accessors are not natively irq-safe. Fix it by using the IRQ-safe this_cpu_*() for operations on read_count. This will generate more expensive code on a number of platforms, which might cause a performance regression for some of the other percpu-rwsem users. If any such is reported, we can consider alternative solutions. Fixes: 70fe2f48152e ("aio: fix freeze protection of aio writes") Signed-off-by: Hou Tao <houtao1@huawei.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Will Deacon <will@kernel.org> Acked-by: Oleg Nesterov <oleg@redhat.com> Link: https://lkml.kernel.org/r/20200915140750.137881-1-houtao1@huawei.com
2020-09-16ipmi: add retry in try_get_dev_id()Xianting Tian
Use a retry machanism to give the BMC more opportunities to correctly respond when we receive specific completion codes. This is similar to what is done in __get_device_id(). Signed-off-by: Xianting Tian <tian.xianting@h3c.com> Message-Id: <20200916062129.26129-1-tian.xianting@h3c.com> [Moved GET_DEVICE_ID_MAX_RETRY to include/linux/ipmi.h, reworded some text.] Signed-off-by: Corey Minyard <cminyard@mvista.com>
2020-09-16perf stat: Fix the ratio comments of miss-eventsQi Liu
'perf stat' displays miss ratio of L1-dcache, L1-icache, dTLB cache, iTLB cache and LL-cache. Take L1-dcache for example, miss ratio is caculated as "L1-dcache-load-misses/L1-dcache-loads". So "of all L1-dcache hits" is unsuitable to describe it, and "of all L1-dcache accesses" seems better. The comments of L1-icache, dTLB cache, iTLB cache and LL-cache are fixed in the same way. Signed-off-by: Qi Liu <liuqi115@huawei.com> Reviewed-by: Andi Kleen <ak@linux.intel.com> Cc: linuxarm@huawei.com Link: http://lore.kernel.org/lkml/1600253331-10535-1-git-send-email-liuqi115@huawei.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-09-16softirq: Add debug check to __raise_softirq_irqoff()Jiafei Pan
__raise_softirq_irqoff() must be called with interrupts disabled to protect the per CPU softirq pending state update against an interrupt and soft interrupt handling on return from interrupt. Add a lockdep assertion to validate the calling convention. [ tglx: Massaged changelog ] Signed-off-by: Jiafei Pan <Jiafei.Pan@nxp.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20200814045522.45719-1-Jiafei.Pan@nxp.com
2020-09-16sticon: remove no-op sticon_set_origin()Tetsuo Handa
We don't need to call vc->vc_sw->con_set_origin() from set_origin() if it is no-op. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Link: https://lore.kernel.org/r/20200915000019.3422-2-penguin-kernel@I-love.SAKURA.ne.jp Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16newport_con: remove no-op newport_set_origin()Tetsuo Handa
We don't need to call vc->vc_sw->con_set_origin() from set_origin() if it is no-op. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Link: https://lore.kernel.org/r/20200915000019.3422-1-penguin-kernel@I-love.SAKURA.ne.jp Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16fbcon: Fix user font detection test at fbcon_resize().Tetsuo Handa
syzbot is reporting OOB read at fbcon_resize() [1], for commit 39b3cffb8cf31117 ("fbcon: prevent user font height or width change from causing potential out-of-bounds access") is by error using registered_fb[con2fb_map[vc->vc_num]]->fbcon_par->p->userfont (which was set to non-zero) instead of fb_display[vc->vc_num].userfont (which remains zero for that display). We could remove tricky userfont flag [2], for we can determine it by comparing address of the font data and addresses of built-in font data. But since that commit is failing to fix the original OOB read [3], this patch keeps the change minimal in case we decide to revert altogether. [1] https://syzkaller.appspot.com/bug?id=ebcbbb6576958a496500fee9cf7aa83ea00b5920 [2] https://syzkaller.appspot.com/text?tag=Patch&x=14030853900000 [3] https://syzkaller.appspot.com/bug?id=6fba8c186d97cf1011ab17660e633b1cc4e080c9 Reported-by: syzbot <syzbot+b38b1ef6edf0c74a8d97@syzkaller.appspotmail.com> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Fixes: 39b3cffb8cf31117 ("fbcon: prevent user font height or width change from causing potential out-of-bounds access") Cc: George Kennedy <george.kennedy@oracle.com> Link: https://lore.kernel.org/r/f6e3e611-8704-1263-d163-f52c906a4f06@I-love.SAKURA.ne.jp Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16net/mlx5: IPsec: make spdxcheck.py happyLukas Bulwahn
Commit 2d64663cd559 ("net/mlx5: IPsec: Add HW crypto offload support") provided a proper SPDX license expression, but slipped in a typo. Fortunately, ./scripts/spdxcheck.py warns: drivers/net/ethernet/mellanox/mlx5/core/accel/ipsec_offload.c: 1:39 \ Invalid License ID: Linux-OpenIBt Remove the typo and make spdxcheck.py happy. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16LICENSES/deprecated: add Zlib license textMikhail Zaslonko
The new files contributed to zlib have Zlib SPDX license identifier. Since there was no Zlib license text in LICENSES, scripts/spdxcheck.py reported the following errors: lib/zlib_dfltcc/dfltcc.c: 1:28 Invalid License ID: Zlib lib/zlib_dfltcc/dfltcc.h: 1:28 Invalid License ID: Zlib lib/zlib_dfltcc/dfltcc_deflate.c: 1:28 Invalid License ID: Zlib lib/zlib_dfltcc/dfltcc_inflate.c: 1:28 Invalid License ID: Zlib lib/zlib_dfltcc/dfltcc_util.h: 1:28 Invalid License ID: Zlib The patch adds Zlib SPDX license to LICENSES/deprecated, thus resolving the issues reported by spdxcheck. Suggested-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Mikhail Zaslonko <zaslonko@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16LICENSE: add GFDL deprecated licensesMauro Carvalho Chehab
There are some files under Documentation which uses deprecated versions of GNU Free Documentation License, on both versions 1.1 and 1.2. On all cases, the license is with no Invariant Sections, Front-Cover Texts or Back-Cover Texts. Add the text file for them, as we'll start using SPDX for those. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16net/qla3xxx: Convert to SPDX license identifiersThomas Gleixner
All files related to this driver contain the following notice: See LICENSE.qla3xxx for copyright and licensing details. LICENSE.qla3xxx can be found in Documentation/networking/device_drivers/qlogic/. The file contains: - A copyright notice This copyright notice is redundant as all files contain the same copyright notice already - A license notice You may modify and redistribute the device driver code under the GNU General Public License (a copy of which is attached hereto as Exhibit A) published by the Free Software Foundation (version 2 or a later version). This can be replaced with the corresponding SPDX license identifier (GPL-2.0-or-later) in the source files which reference this license file. - A license for the device firmware This license is pointless in the context of the kernel as the firmware is not distributed as part of the kernel. LICENSE.qla2xxx contained exactly the same firmware license which was removed with commit bc3f957c069f ("[SCSI] qla2xxx: Update LICENSE.qla2xxx."). The firmware license is there due to the fact that the out of tree driver tarball which was available from the qlogic website contained the firmware binary. The firmware license in the qla3xxx license file got probably forgotten when the other qlogic license files were updated. Remove the notices and add the SPDX license identifier GPL-2.0-or-later to the source files. Finally remove the now redundant LICENSE.qla3xxx file. Reviewed-by: Richard Fontana <rfontana@redhat.com> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16net/qlge: Convert to SPDX license identifiersThomas Gleixner
All files related to this driver contain the following notice: See LICENSE.qlge for copyright and licensing details. LICENSE.qlge can be found in Documentation/networking/device_drivers/qlogic/. The file contains: - A copyright notice This copyright notice is redundant as all files contain the same copyright notice already - A license notice You may modify and redistribute the device driver code under the GNU General Public License (a copy of which is attached hereto as Exhibit A) published by the Free Software Foundation (version 2). This can be replaced with the corresponding SPDX license identifier (GPL-2.0-only) in the source files which reference this license file. - The full GPLv2 license text A redundant copy of LICENSES/preferred/GPL-2.0 Remove the notices and add the SPDX license identifier GPL-2.0-only to the source files. Finally remove the now redundant LICENSE.qlge file. Reviewed-by: Richard Fontana <rfontana@redhat.com> Reviewed-by: Jilayne Lovejoy <opensource@jilayne.com> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16net/qlcnic: Convert to SPDX license identifiersThomas Gleixner
All files in this driver directory contain the following notice: See LICENSE.qlcnic for copyright and licensing details. LICENSE.qlacnic can be found in Documentation/networking/device_drivers/qlogic/. The file contains: - A copyright notice This copyright notice is redundant as all files contain the same copyright notice already - A license notice You may modify and redistribute the device driver code under the GNU General Public License (a copy of which is attached hereto as Exhibit A) published by the Free Software Foundation (version 2). This can be replaced with the corresponding SPDX license identifier (GPL-2.0-only) in the source files which reference this license file. - The full GPLv2 license text A redundant copy of LICENSES/preferred/GPL-2.0 Remove the notices and add the SPDX license identifier GPL-2.0-only to the source files. Finally remove the now redundant LICENSE.qlcnic file. Reviewed-by: Richard Fontana <rfontana@redhat.com> Reviewed-by: Jilayne Lovejoy <opensource@jilayne.com> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Acked-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16scsi/qla2xxx: Convert to SPDX license identifiersThomas Gleixner
All files in this driver directory contain the following notice: See LICENSE.qla2xxx for copyright and licensing details. LICENSE.qla2xxx can be found in Documentation/scsi/. The file contains: - A copyright notice This copyright notice is redundant as all files contain the same copyright notice already - A license notice You may modify and redistribute the device driver code under the GNU General Public License (a copy of which is attached hereto as Exhibit A) published by the Free Software Foundation (version 2). This can be replaced with the corresponding SPDX license identifier (GPL-2.0-only) in the source files which reference this license file. - The full GPLv2 license text A redundant copy of LICENSES/preferred/GPL-2.0 Remove the notices and add the SPDX license identifier GPL-2.0-only to the source files. Finally remove the now redundant LICENSE.qla2xxx file. Reviewed-by: Richard Fontana <rfontana@redhat.com> Reviewed-by: Jilayne Lovejoy <opensource@jilayne.com> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Acked-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Acked-by: Nilesh Javali <njavali@marvell.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16scsi/qla4xxx: Convert to SPDX license identifiersThomas Gleixner
All files in this driver directory contain the following notice: See LICENSE.qla4xxx for copyright and licensing details. LICENSE.qla4xxx can be found in Documentation/scsi/. The file contains: - A copyright notice This copyright notice is redundant as all files contain the same copyright notice already - A license notice You may modify and redistribute the device driver code under the GNU General Public License (a copy of which is attached hereto as Exhibit A) published by the Free Software Foundation (version 2). - The full GPLv2 license text This can be replaced with the corresponding SPDX license identifier (GPL-2.0-only) in the source files which reference this license file. - The full GPLv2 license text A redundant copy of LICENSES/preferred/GPL-2.0 Remove the notices and add the SPDX license identifier GPL-2.0-only to the source files. Finally remove the now redundant LICENSE.qla4xxx file. Reviewed-by: Richard Fontana <rfontana@redhat.com> Reviewed-by: Jilayne Lovejoy <opensource@jilayne.com> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Acked-by: Nilesh Javali <njavali@marvell.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16tty: serial: qcom_geni_serial: Fix the UART wakeup issuesatya priya
As a part of system suspend uart_port_suspend is called from the Serial driver, which calls set_mctrl passing mctrl as 0. This makes RFR high(NOT_READY) during suspend. Due to this BT SoC is not able to send wakeup bytes to UART during suspend. Include if check for non-suspend case to keep RFR low during suspend. Signed-off-by: satya priya <skakit@codeaurora.org> Reviewed-by: Akash Asthana <akashast@codeaurora.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/1599742438-16811-5-git-send-email-skakit@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16powercap: RAPL: Add support for LakefieldRicardo Neri
Simply add Lakefield model ID. No additional changes are needed. Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> [ rjw: Minor subject edit ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-09-16serial: 8250_pci: Add Realtek 816a and 816bTobias Diedrich
These serial ports are exposed by the OOB-management-engine on RealManage-enabled network cards (e.g. AMD DASH enabled systems using Realtek cards). Because these have 3 BARs, they fail the "num_iomem <= 1" check in serial_pci_guess_board. I've manually checked the two IOMEM regions and BAR 2 doesn't seem to respond to reads, but BAR 4 seems to be an MMIO version of the IO ports (untested). With this change, the ports are detected: 0000:02:00.1: ttyS0 at I/O 0x2200 (irq = 82, base_baud = 115200) is a 16550A 0000:02:00.2: ttyS1 at I/O 0x2100 (irq = 55, base_baud = 115200) is a 16550A lspci output: 02:00.1 0700: 10ec:816a (rev 0e) (prog-if 02 [16550]) Subsystem: 17aa:5082 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort+ <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin B routed to IRQ 82 IOMMU group: 11 Region 0: I/O ports at 2200 [size=256] Region 2: Memory at fd715000 (64-bit, non-prefetchable) [size=4K] Region 4: Memory at fd704000 (64-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 Capabilities: [70] Express (v2) Endpoint, MSI 01 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 <64us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0.000W DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq+ AuxPwr+ TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s unlimited, L1 <64us ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+ LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s (ok), Width x1 (ok) TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ NROPrPrP- LTR+ 10BitTagComp- 10BitTagReq- OBFF Via message/WAKE#, ExtFmt- EETLPPrefix- EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- FRS- TPHComp- ExtTPHComp- AtomicOpsCap: 32bit- 64bit- 128bitCAS- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- OBFF Disabled, AtomicOpsCtl: ReqEn- LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1- EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest- Retimer- 2Retimers- CrosslinkRes: unsupported Capabilities: [b0] MSI-X: Enable- Count=4 Masked- Vector table: BAR=4 offset=00000000 PBA: BAR=4 offset=00000800 Capabilities: [d0] Vital Product Data Not readable Capabilities: [100 v2] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn- MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- HeaderLog: 00000000 00000000 00000000 00000000 Capabilities: [160 v1] Device Serial Number 00-00-00-00-00-00-00-00 Capabilities: [170 v1] Latency Tolerance Reporting Max snoop latency: 0ns Max no snoop latency: 0ns Capabilities: [178 v1] L1 PM Substates L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+ PortCommonModeRestoreTime=150us PortTPowerOnTime=150us L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1- T_CommonMode=0us LTR1.2_Threshold=0ns L1SubCtl2: T_PwrOn=10us 02:00.2 0700: 10ec:816b (rev 0e) [...same...] Signed-off-by: Tobias Diedrich <tobiasdiedrich@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200914173628.GA22508@yamamaya.is-a-geek.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16serial: core: fix console port-lock regressionJohan Hovold
Fix the port-lock initialisation regression introduced by commit a3cb39d258ef ("serial: core: Allow detach and attach serial device for console") by making sure that the lock is again initialised during console setup. The console may be registered before the serial controller has been probed in which case the port lock needs to be initialised during console setup by a call to uart_set_options(). The console-detach changes introduced a regression in several drivers by effectively removing that initialisation by not initialising the lock when the port is used as a console (which is always the case during console setup). Add back the early lock initialisation and instead use a new console-reinit flag to handle the case where a console is being re-attached through sysfs. The question whether the console-detach interface should have been added in the first place is left for another discussion. Note that the console-enabled check in uart_set_options() is not redundant because of kgdboc, which can end up reinitialising an already enabled console (see commit 42b6a1baa3ec ("serial_core: Don't re-initialize a previously initialized spinlock.")). Fixes: a3cb39d258ef ("serial: core: Allow detach and attach serial device for console") Cc: stable <stable@vger.kernel.org> # 5.7 Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200909143101.15389-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16serial: core: fix port-lock initialisationJohan Hovold
Commit f743061a85f5 ("serial: core: Initialise spin lock before use in uart_configure_port()") tried to work around a breakage introduced by commit a3cb39d258ef ("serial: core: Allow detach and attach serial device for console") by adding a second initialisation of the port lock when registering the port. As reported by the build robots [1], this doesn't really solve the regression introduced by the console-detach changes and also adds a second redundant initialisation of the lock for normal ports. Start cleaning up this mess by removing the redundant initialisation and making sure that the port lock is again initialised once-only for ports that aren't already in use as a console. [1] https://lore.kernel.org/r/20200802054852.GR23458@shao2-debian Fixes: f743061a85f5 ("serial: core: Initialise spin lock before use in uart_configure_port()") Fixes: a3cb39d258ef ("serial: core: Allow detach and attach serial device for console") Cc: stable <stable@vger.kernel.org> # 5.7 Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200909143101.15389-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16tty: serial: qcom_geni_serial: 115.2 is a better console default than 9600Douglas Anderson
Commit c5cbc78acf69 ("tty: serial: qcom_geni_serial: Initialize baud in qcom_geni_console_setup") fixed a bug by initting a variable that was used in some cases without initialization. However, the "default" baud rate picked by that CL was probably not the best choice. The chances that anyone out there is trying to run a system with kernel messages piped out over a 9600 baud serial port is just about nil. Console messages are printed in a blocking manner. At 9600 baud we print about 1 character per millisecond which means that printing a 40-byte message to the console will take ~40 ms. While it would probably work, it's going to make boot _very_ slow and probably cause the occasional timeout here and there in drivers (heck, even at 115200 console delays can wreck havoc). This has already bit at least two people that I'm aware of that tried to enable serial console by just adding "console=ttyMSM0" (instead of "console=ttyMSM0,115200n8") to the command line, so it seems like it'd be nice to fix. Let's switch the default to 115200. Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Akash Asthana <akashast@codeaurora.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200911080054.1.I4c00b921c2f17b6988688046fa7be0f729f8d591@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16serial: pmac_zilog: use for_each_child_of_node() macroQinglang Miao
Use for_each_child_of_node() macro instead of open coding it. Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com> Link: https://lore.kernel.org/r/20200916062138.191188-1-miaoqinglang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16tty: serial: 8250_mtk: set regshift for mmio32Hsin-Yi Wang
To use mmio32, we also need to set regshift. Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Acked-by: Eddie Huang <eddie.huang@mediatek.com> Link: https://lore.kernel.org/r/20200915054825.3289105-2-hsinyi@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16tty: serial: print earlycon info after match->setupHsin-Yi Wang
8250 devices may modify iotype in their own earlycon setup. For example: 8250_mtk and 8250_uniphier force iotype to be MMIO32. Print earlycon info after match->setup to reflect actual earlycon info. Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Link: https://lore.kernel.org/r/20200915054825.3289105-1-hsinyi@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16serial: ucc_uart: make qe_uart_set_mctrl() staticJason Yan
This eliminates the following sparse warning: drivers/tty/serial/ucc_uart.c:286:6: warning: symbol 'qe_uart_set_mctrl' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Acked-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Jason Yan <yanaijie@huawei.com> Link: https://lore.kernel.org/r/20200912033834.143166-1-yanaijie@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16serial: 8250_pci: Remove unused function get_pci_irq()YueHaibing
It is not used since commit 8428413b1d14 ("serial: 8250_pci: Implement MSI(-X) support") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20200909135103.17768-1-yuehaibing@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16usb: typec: intel_pmc_mux: Handle SCU IPC error conditionsMadhusudanarao Amara
Check and return if there are errors. The response bits are valid only on no errors. Fixes: b7404a29cd3d ("usb: typec: intel_pmc_mux: Definitions for response status bits") Signed-off-by: Madhusudanarao Amara <madhusudanarao.amara@intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200916091102.27118-4-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16USB: quirks: Add USB_QUIRK_IGNORE_REMOTE_WAKEUP quirk for BYD zhaoxin notebookPenghao
Add a USB_QUIRK_IGNORE_REMOTE_WAKEUP quirk for the BYD zhaoxin notebook. This notebook come with usb touchpad. And we would like to disable touchpad wakeup on this notebook by default. Signed-off-by: Penghao <penghao@uniontech.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200907023026.28189-1-penghao@uniontech.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16USB: UAS: fix disconnect by unplugging a hubOliver Neukum
The SCSI layer can go into an ugly loop if you ignore that a device is gone. You need to report an error in the command rather than in the return value of the queue method. We need to specifically check for ENODEV. The issue goes back to the introduction of the driver. Fixes: 115bb1ffa54c3 ("USB: Add UAS driver") Signed-off-by: Oliver Neukum <oneukum@suse.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200916094026.30085-2-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16usb: typec: ucsi: Prevent mode overrunHeikki Krogerus
Sometimes the embedded controller firmware does not terminate the list of alternate modes that the partner supports in its response to the GET_ALTERNATE_MODES command. Instead the firmware returns the supported alternate modes over and over again until the driver stops requesting them. If that happens, the number of modes for each alternate mode will exceed the maximum 6 that is defined in the USB Power Delivery specification. Making sure that can't happen by adding a check for it. This fixes NULL pointer dereference that is caused by the overrun. Fixes: ad74b8649beaf ("usb: typec: ucsi: Preliminary support for alternate modes") Cc: stable@vger.kernel.org Reported-by: Zwane Mwaikambo <zwanem@gmail.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200916090034.25119-3-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16usb: typec: ucsi: acpi: Increase command completion timeout valueHeikki Krogerus
UCSI specification quite clearly states that if a command can't be completed in 10ms, the firmware must notify about BUSY condition. Unfortunately almost none of the platforms (the firmware on them) generate the BUSY notification even if a command can't be completed in time. The driver already considered that, and used a timeout value of 5 seconds, but processing especially the alternate mode discovery commands takes often considerable amount of time from the firmware, much more than the 5 seconds. That happens especially after bootup when devices are already connected to the USB Type-C connector. For now on those platforms the alternate mode discovery has simply failed because of the timeout. To improve the situation, increasing the timeout value for the command completion to 1 minute. That should give enough time for even the slowest firmware to process the commands. Fixes: f56de278e8ec ("usb: typec: ucsi: acpi: Move to the new API") Cc: stable@vger.kernel.org Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200916090034.25119-2-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-16cpufreq: qcom: Don't add frequencies without an OPPMatthias Kaehlcke
The driver currently adds all frequencies from the hardware LUT to the cpufreq table, regardless of whether the corresponding OPP exists. This prevents devices from disabling certain OPPs through the device tree and can result in CPU frequencies for which the interconnect bandwidth can't be adjusted. Only add frequencies with an OPP entry. Fixes: 55538fbc79e9 ("cpufreq: qcom: Read voltage LUT and populate OPP") Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-09-16cpufreq: qcom-hw: Add cpufreq support for SM8250 SoCManivannan Sadhasivam
SM8250 SoC uses EPSS block for carrying out the cpufreq duties. Hence, add support for it in the driver with relevant dev data. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Amit Kucheria <amitk@kernel.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-09-16cpufreq: qcom-hw: Use of_device_get_match_data for offsets and row sizeManivannan Sadhasivam
For preparing the driver to handle further SoC revisions, let's use the of_device_get_match_data() API for getting the device specific offsets and row size instead of defining them globally. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-09-16cpufreq: qcom-hw: Use devm_platform_ioremap_resource() to simplify codeManivannan Sadhasivam
devm_platform_ioremap_resource() is the combination of platform_get_resource() and devm_ioremap_resource(). Hence, use it to simplify the code a bit. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Amit Kucheria <amitk@kernel.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-09-16dt-bindings: cpufreq: cpufreq-qcom-hw: Document Qcom EPSS compatibleManivannan Sadhasivam
The hardware block which carries out CPUFreq operations on SM8250 SoC is called EPSS. Hence, document the compatible. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Amit Kucheria <amitk@kernel.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-09-16cpufreq: qcom-hw: Make use of cpufreq driver_data for passing pdevManivannan Sadhasivam
Get rid of global_pdev pointer and make use of cpufreq driver_data for passing the reference of pdev. This aligns with what other cpufreq drivers are doing. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-09-16cpufreq: armada-37xx: Add missing MODULE_DEVICE_TABLEPali Rohár
CONFIG_ARM_ARMADA_37XX_CPUFREQ is tristate option and therefore this cpufreq driver can be compiled as a module. This patch adds missing MODULE_DEVICE_TABLE which generates correct modalias for automatic loading of this cpufreq driver when is compiled as an external module. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Pali Rohár <pali@kernel.org> Fixes: 92ce45fb875d7 ("cpufreq: Add DVFS support for Armada 37xx") [ Viresh: Added __maybe_unused ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-09-16cpufreq: arm: Kconfig: add CPUFREQ_DT depend for STI CPUFREQAlain Volmat
The sti cpufreq driver is relying on the CPUFREQ_DT driver hence add the depends within the Kconfig.arm Signed-off-by: Alain Volmat <avolmat@me.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-09-16cpufreq: dt-platdev: Blacklist st,stih418 SoCAlain Volmat
Add st,stih418 SoC in the blacklist since the cpufreq driver for this platform is already registering the driver. Signed-off-by: Alain Volmat <avolmat@me.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-09-16cpufreq: sti-cpufreq: add stih418 supportAlain Volmat
The STiH418 can be controlled the same way as STiH407 & STiH410 regarding cpufreq. Signed-off-by: Alain Volmat <avolmat@me.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-09-16cpufreq: s5pv210: Use dev_err instead of pr_err in probeKrzysztof Kozlowski
dev_err() allows easily to identify the device printing the message so no need for __func__. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> [ Viresh: Don't remove update to result variable ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-09-16cpufreq: s5pv210: Simplify with dev_err_probe()Krzysztof Kozlowski
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and also it prints the error value. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-09-16cpufreq: tegra186: Fix initial frequencyJon Hunter
Commit 6cc3d0e9a097 ("cpufreq: tegra186: add CPUFREQ_NEED_INITIAL_FREQ_CHECK flag") fixed CPUFREQ support for Tegra186 but as a consequence the following warnings are now seen on boot ... cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 0 KHz cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to: 2035200 KHz cpufreq: cpufreq_online: CPU1: Running at unlisted freq: 0 KHz cpufreq: cpufreq_online: CPU1: Unlisted initial frequency changed to: 2035200 KHz cpufreq: cpufreq_online: CPU2: Running at unlisted freq: 0 KHz cpufreq: cpufreq_online: CPU2: Unlisted initial frequency changed to: 2035200 KHz cpufreq: cpufreq_online: CPU3: Running at unlisted freq: 0 KHz cpufreq: cpufreq_online: CPU3: Unlisted initial frequency changed to: 2035200 KHz cpufreq: cpufreq_online: CPU4: Running at unlisted freq: 0 KHz cpufreq: cpufreq_online: CPU4: Unlisted initial frequency changed to: 2035200 KHz cpufreq: cpufreq_online: CPU5: Running at unlisted freq: 0 KHz cpufreq: cpufreq_online: CPU5: Unlisted initial frequency changed to: 2035200 KHz Fix this by adding a 'get' callback for the Tegra186 CPUFREQ driver to retrieve the current operating frequency for a given CPU. The 'get' callback uses the current 'ndiv' value that is programmed to determine that current operating frequency. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> [ Viresh: Return 0 on error ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
generated by cgit (git 2.34.1) at 2025-10-02 18:23:07 +0000