- 08 12月, 2021 2 次提交
-
-
由 Mike Tipton 提交于
Before commit fc0c209c ("clk: Allow parents to be specified without string names") child clks couldn't find their parent until the parent clk was added to a list in __clk_core_init(). After that commit, child clks can reference their parent clks directly via a clk_hw pointer, or they can lookup that clk_hw pointer via DT if the parent clk is registered with an OF clk provider. The common clk framework treats hw->core being non-NULL as "the clk is registered" per the logic within clk_core_fill_parent_index(): parent = entry->hw->core; /* * We have a direct reference but it isn't registered yet? * Orphan it and let clk_reparent() update the orphan status * when the parent is registered. */ if (!parent) Therefore we need to be extra careful to not set hw->core until the clk is fully registered with the clk framework. Otherwise we can get into a situation where a child finds a parent clk and we move the child clk off the orphan list when the parent isn't actually registered, wrecking our enable accounting and breaking critical clks. Consider the following scenario: CPU0 CPU1 ---- ---- struct clk_hw clkBad; struct clk_hw clkA; clkA.init.parent_hws = { &clkBad }; clk_hw_register(&clkA) clk_hw_register(&clkBad) ... __clk_register() hw->core = core ... __clk_register() __clk_core_init() clk_prepare_lock() __clk_init_parent() clk_core_get_parent_by_index() clk_core_fill_parent_index() if (entry->hw) { parent = entry->hw->core; At this point, 'parent' points to clkBad even though clkBad hasn't been fully registered yet. Ouch! A similar problem can happen if a clk controller registers orphan clks that are referenced in the DT node of another clk controller. Let's fix all this by only setting the hw->core pointer underneath the clk prepare lock in __clk_core_init(). This way we know that clk_core_fill_parent_index() can't see hw->core be non-NULL until the clk is fully registered. Fixes: fc0c209c ("clk: Allow parents to be specified without string names") Signed-off-by: NMike Tipton <quic_mdtipton@quicinc.com> Link: https://lore.kernel.org/r/20211109043438.4639-1-quic_mdtipton@quicinc.com [sboyd@kernel.org: Reword commit text, update comment] Signed-off-by: NStephen Boyd <sboyd@kernel.org>
-
由 Dan Carpenter 提交于
This frees "name" and then tries to display in as part of the error message on the next line. Swap the order. Fixes: 1b2189f3 ("clk: versatile: clk-icst: Ensure clock names are unique") Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20211117072604.GC5237@kiliReviewed-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NStephen Boyd <sboyd@kernel.org>
-
- 07 12月, 2021 1 次提交
-
-
由 Martin Botka 提交于
Without this change eMMC runs at overclocked freq. Swap the ops to not OC the eMMC. Signed-off-by: NMartin Botka <martin.botka@somainline.org> Link: https://lore.kernel.org/r/20211130212015.25232-1-martin.botka@somainline.orgReviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org> Fixes: 4b8d6ae5 ("clk: qcom: Add SM6125 (TRINKET) GCC driver") Signed-off-by: NStephen Boyd <sboyd@kernel.org>
-
- 03 12月, 2021 3 次提交
-
-
由 Miles Chen 提交于
Replace builtin_platform_driver_probe with module_platform_driver_probe because CONFIG_CLK_IMX8QXP can be set to =m (kernel module). Fixes: e0d0d4d8 ("clk: imx8qxp: Support building i.MX8QXP clock driver as module") Cc: Fabio Estevam <festevam@gmail.com> Cc: Stephen Boyd <sboyd@kernel.org> Signed-off-by: NMiles Chen <miles.chen@mediatek.com> Link: https://lore.kernel.org/r/20210904235418.2442-1-miles.chen@mediatek.comReviewed-by: NFabio Estevam <festevam@gmail.com> Reviewed-by: NStephen Boyd <sboyd@kernel.org> Signed-off-by: NStephen Boyd <sboyd@kernel.org>
-
由 Bjorn Andersson 提交于
In the event that the bootloader has configured the Trion PLL as source for the display clocks, e.g. for the continuous splashscreen, then there will also be RCGs that are clocked by this instance. Reconfiguring, and in particular disabling the output of, the PLL will cause issues for these downstream RCGs and has been shown to prevent them from being re-parented. Follow downstream and skip configuration if it's determined that the PLL is already running. Fixes: 59128c20 ("clk: qcom: clk-alpha-pll: Add support for controlling Lucid PLLs") Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: NRobert Foss <robert.foss@linaro.org> Reviewed-by: NVinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20211123162508.153711-1-bjorn.andersson@linaro.orgSigned-off-by: NStephen Boyd <sboyd@kernel.org>
-
由 Dmitry Baryshkov 提交于
The function mux_get_parent() uses qcom_find_src_index() to find the parent clock index, which is incorrect: qcom_find_src_index() uses src enum for the lookup, while mux_get_parent() should use cfg field (which corresponds to the register value). Add qcom_find_cfg_index() function doing this kind of lookup and use it for mux parent lookup. Fixes: df964016 ("clk: qcom: add parent map for regmap mux") Cc: stable@vger.kernel.org Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20211115233407.1046179-1-dmitry.baryshkov@linaro.orgSigned-off-by: NStephen Boyd <sboyd@kernel.org>
-
- 13 11月, 2021 4 次提交
-
-
由 Linus Torvalds 提交于
Commit aeb58c86 ("thermal/drivers/int340x: processor_thermal: Suppot 64 bit RFIM responses") started using 'readq()' to read 64-bit status responses from the int340x hardware. That's all fine and good, but on 32-bit targets a 64-bit 'readq()' is ambiguous, since it's no longer an atomic access. Some hardware might require 64-bit accesses, and other hardware might want low word first or high word first. It's quite likely that the driver isn't relevant in a 32-bit environment any more, and there's a patch floating around to just make it depend on X86_64, but let's make it buildable on x86-32 anyway. The driver previously just read the low 32 bits, so the hardware certainly is ok with 32-bit reads, and in a little-endian environment the low word first model is the natural one. So just add the include for the 'io-64-nonatomic-lo-hi.h' version. Fixes: aeb58c86 ("thermal/drivers/int340x: processor_thermal: Suppot 64 bit RFIM responses") Reported-by: NJakub Kicinski <kuba@kernel.org> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Marc Zyngier 提交于
Since 04128418 ("of/irq: Allow matching of an interrupt-map local to an interrupt controller"), the irq code favors using an interrupt-map over a interrupt-controller property if both are available, while the earlier behaviour was to ignore the interrupt-map altogether. However, we now end-up with the opposite behaviour, which is to ignore the interrupt-controller property even if the interrupt-map fails to match its input. This new behaviour breaks the AmigaOne X1000 machine, which ships with an extremely "creative" (read: broken) device tree. Fix this by allowing the interrupt-controller property to be selected when interrupt-map fails to match anything. Fixes: 04128418 ("of/irq: Allow matching of an interrupt-map local to an interrupt controller") Reported-by: NChristian Zigotzky <chzigotzky@xenosoft.de> Reviewed-by: NRob Herring <robh@kernel.org> Signed-off-by: NMarc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/78308692-02e6-9544-4035-3171a8e1e6d4@xenosoft.de Link: https://lore.kernel.org/r/20211112143644.434995-1-maz@kernel.org Cc: Bjorn Helgaas <bhelgaas@google.com>
-
由 Guo Ren 提交于
When using "devm_request_threaded_irq(,,,,IRQF_ONESHOT,,)" in a driver, only the first interrupt is handled, and following interrupts are never delivered (initially reported in [1]). That's because the RISC-V PLIC cannot EOI masked interrupts, as explained in the description of Interrupt Completion in the PLIC spec [2]: <quote> The PLIC signals it has completed executing an interrupt handler by writing the interrupt ID it received from the claim to the claim/complete register. The PLIC does not check whether the completion ID is the same as the last claim ID for that target. If the completion ID does not match an interrupt source that *is currently enabled* for the target, the completion is silently ignored. </quote> Re-enable the interrupt before completion if it has been masked during the handling, and remask it afterwards. [1] http://lists.infradead.org/pipermail/linux-riscv/2021-July/007441.html [2] https://github.com/riscv/riscv-plic-spec/blob/8bc15a35d07c9edf7b5d23fec9728302595ffc4d/riscv-plic.adoc Fixes: bb0fed1c ("irqchip/sifive-plic: Switch to fasteoi flow") Reported-by: NVincent Pelletier <plr.vincent@gmail.com> Tested-by: NNikita Shubin <nikita.shubin@maquefel.me> Signed-off-by: NGuo Ren <guoren@linux.alibaba.com> Cc: stable@vger.kernel.org Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Atish Patra <atish.patra@wdc.com> Reviewed-by: NAnup Patel <anup@brainfault.org> [maz: amended commit message] Signed-off-by: NMarc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211105094748.3894453-1-guoren@kernel.org
-
由 Guo Ren 提交于
The mask/unmask must be implemented, and enable/disable supplement them if the HW requires something different at startup time. When irq source is disabled by mask, mpintc could complete irq normally. So drop enable/disable if favour of mask/unmask. Signed-off-by: NGuo Ren <guoren@linux.alibaba.com> Signed-off-by: NMarc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211101134534.3804542-1-guoren@kernel.org
-
- 12 11月, 2021 8 次提交
-
-
由 Rob Herring 提交于
Commit 2d3de197 ("ARM: dts: arm: Update ICST clock nodes 'reg' and node names") moved to using generic node names. That results in trying to register multiple clocks with the same name. Fix this by including the unit-address in the clock name. Fixes: 2d3de197 ("ARM: dts: arm: Update ICST clock nodes 'reg' and node names") Cc: stable@vger.kernel.org Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Stephen Boyd <sboyd@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-clk@vger.kernel.org Signed-off-by: NRob Herring <robh@kernel.org> Reviewed-by: NStephen Boyd <sboyd@kernel.org> Reviewed-by: NLinus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20211109164650.2233507-3-robh@kernel.org
-
由 Rob Herring 提交于
Commit 25b892b5 ("ARM: dts: arm: Update register-bit-led nodes 'reg' and node names") added a 'reg' property to nodes. This change has the side effect of changing how the kernel generates the device name. The assumption was a translatable 'reg' address is unique. However, in the case of the register-bit-led binding (and a few others) that is not the case. The 'mask' property must also be used in this case to make a unique device name. Fixes: 25b892b5 ("ARM: dts: arm: Update register-bit-led nodes 'reg' and node names") Reported-by: NGuenter Roeck <linux@roeck-us.net> Cc: stable@vger.kernel.org Cc: Frank Rowand <frowand.list@gmail.com> Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: NRob Herring <robh@kernel.org> Reviewed-by: NLinus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20211109164650.2233507-2-robh@kernel.orgSigned-off-by: NRob Herring <robh@kernel.org>
-
由 Paul Cercueil 提交于
Tidy up a bit the tree, by prefixing all include/dt-bindings/clock/ files related to Ingenic SoCs with 'ingenic,'. Signed-off-by: NPaul Cercueil <paul@crapouillou.net> Acked-by: NRob Herring <robh@kernel.org> Acked-by: NStephen Boyd <sboyd@kernel.org> Signed-off-by: NRob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211016133322.40771-1-paul@crapouillou.net
-
由 Damien Le Moal 提交于
ahci_shost_attr_group is referenced only in drivers/ata/libahci.c. Declare it as static. Fixes: c3f69c7f ("scsi: ata: Switch to attribute groups") Cc: Bart Van Assche <bvanassche@acm.org> Signed-off-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com> Reviewed-by: NChristoph Hellwig <hch@lst.de>
-
由 Damien Le Moal 提交于
ACS-3 introduced the ATA Identify Device Data log as mandatory. A warning message currently signals to the user if a device does not report supporting this log page in the log directory page, regardless of the ATA version of the device. Furthermore, this warning will appear for all attempts at accessing this missing log page during device revalidation. Since it is useless to constantly access the log directory and warn about this lack of support once we have discovered that the device does not support this log page, introduce the horkage flag ATA_HORKAGE_NO_ID_DEV_LOG to mark a device as lacking support for the Identify Device Data log page. Set this flag when ata_log_supported() returns false in ata_identify_page_supported(). The warning is printed only if the device ATA level is 10 or above (ACS-3 or above), and only once on device scan. With this flag set, the log directory page is not accessed again to test for Identify Device Data log page support. Signed-off-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com>
-
由 Bjorn Helgaas 提交于
This reverts commit 2a4d9408. Robert reported a NULL pointer dereference caused by the PCI core (local_pci_probe()) calling the i2c_designware_pci driver's .runtime_resume() method before the .probe() method. i2c_dw_pci_resume() depends on initialization done by i2c_dw_pci_probe(). Prior to 2a4d9408 ("PCI: Use to_pci_driver() instead of pci_dev->driver"), pci_pm_runtime_resume() avoided calling the .runtime_resume() method because pci_dev->driver had not been set yet. 2a4d9408 and b5f9c644 ("PCI: Remove struct pci_dev->driver"), removed pci_dev->driver, replacing it by device->driver, which *has* been set by this time, so pci_pm_runtime_resume() called the .runtime_resume() method when it previously had not. Fixes: 2a4d9408 ("PCI: Use to_pci_driver() instead of pci_dev->driver") Link: https://lore.kernel.org/linux-i2c/CAP145pgdrdiMAT7=-iB1DMgA7t_bMqTcJL4N0=6u8kNY3EU0dw@mail.gmail.com/Reported-by: NRobert Święcki <robert@swiecki.net> Tested-by: NRobert Święcki <robert@swiecki.net> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
This reverts commit b5f9c644. Revert b5f9c644 ("PCI: Remove struct pci_dev->driver"), which is needed to revert 2a4d9408 ("PCI: Use to_pci_driver() instead of pci_dev->driver"). 2a4d9408 caused a NULL pointer dereference reported by Robert Święcki. Details in the revert of that commit. Fixes: 2a4d9408 ("PCI: Use to_pci_driver() instead of pci_dev->driver") Link: https://lore.kernel.org/linux-i2c/CAP145pgdrdiMAT7=-iB1DMgA7t_bMqTcJL4N0=6u8kNY3EU0dw@mail.gmail.com/Reported-by: NRobert Święcki <robert@swiecki.net> Tested-by: NRobert Święcki <robert@swiecki.net> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Alistair Popple 提交于
MIGRATE_PFN_LOCKED is used to indicate to migrate_vma_prepare() that a source page was already locked during migrate_vma_collect(). If it wasn't then the a second attempt is made to lock the page. However if the first attempt failed it's unlikely a second attempt will succeed, and the retry adds complexity. So clean this up by removing the retry and MIGRATE_PFN_LOCKED flag. Destination pages are also meant to have the MIGRATE_PFN_LOCKED flag set, but nothing actually checks that. Link: https://lkml.kernel.org/r/20211025041608.289017-1-apopple@nvidia.comSigned-off-by: NAlistair Popple <apopple@nvidia.com> Reviewed-by: NRalph Campbell <rcampbell@nvidia.com> Acked-by: NFelix Kuehling <Felix.Kuehling@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Jerome Glisse <jglisse@redhat.com> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Zi Yan <ziy@nvidia.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 11 11月, 2021 13 次提交
-
-
由 Wang ShaoBo 提交于
When testing cpu online and offline, warning happened like this: [ 146.746743] WARNING: CPU: 92 PID: 974 at kernel/sched/topology.c:2215 build_sched_domains+0x81c/0x11b0 [ 146.749988] CPU: 92 PID: 974 Comm: kworker/92:2 Not tainted 5.15.0 #9 [ 146.750402] Hardware name: Huawei TaiShan 2280 V2/BC82AMDDA, BIOS 1.79 08/21/2021 [ 146.751213] Workqueue: events cpuset_hotplug_workfn [ 146.751629] pstate: 00400009 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 146.752048] pc : build_sched_domains+0x81c/0x11b0 [ 146.752461] lr : build_sched_domains+0x414/0x11b0 [ 146.752860] sp : ffff800040a83a80 [ 146.753247] x29: ffff800040a83a80 x28: ffff20801f13a980 x27: ffff20800448ae00 [ 146.753644] x26: ffff800012a858e8 x25: ffff800012ea48c0 x24: 0000000000000000 [ 146.754039] x23: ffff800010ab7d60 x22: ffff800012f03758 x21: 000000000000005f [ 146.754427] x20: 000000000000005c x19: ffff004080012840 x18: ffffffffffffffff [ 146.754814] x17: 3661613030303230 x16: 30303078303a3239 x15: ffff800011f92b48 [ 146.755197] x14: ffff20be3f95cef6 x13: 2e6e69616d6f642d x12: 6465686373204c4c [ 146.755578] x11: ffff20bf7fc83a00 x10: 0000000000000040 x9 : 0000000000000000 [ 146.755957] x8 : 0000000000000002 x7 : ffffffffe0000000 x6 : 0000000000000002 [ 146.756334] x5 : 0000000090000000 x4 : 00000000f0000000 x3 : 0000000000000001 [ 146.756705] x2 : 0000000000000080 x1 : ffff800012f03860 x0 : 0000000000000001 [ 146.757070] Call trace: [ 146.757421] build_sched_domains+0x81c/0x11b0 [ 146.757771] partition_sched_domains_locked+0x57c/0x978 [ 146.758118] rebuild_sched_domains_locked+0x44c/0x7f0 [ 146.758460] rebuild_sched_domains+0x2c/0x48 [ 146.758791] cpuset_hotplug_workfn+0x3fc/0x888 [ 146.759114] process_one_work+0x1f4/0x480 [ 146.759429] worker_thread+0x48/0x460 [ 146.759734] kthread+0x158/0x168 [ 146.760030] ret_from_fork+0x10/0x20 [ 146.760318] ---[ end trace 82c44aad6900e81a ]--- For some architectures like risc-v and arm64 which use common code clear_cpu_topology() in shutting down CPUx, When CONFIG_SCHED_CLUSTER is set, cluster_sibling in cpu_topology of each sibling adjacent to CPUx is missed clearing, this causes checking failed in topology_span_sane() and rebuilding topology failure at end when CPU online. Different sibling's cluster_sibling in cpu_topology[] when CPU92 offline (CPU 92, 93, 94, 95 are in one cluster): Before revision: CPU [92] [93] [94] [95] cluster_sibling [92] [92-95] [92-95] [92-95] After revision: CPU [92] [93] [94] [95] cluster_sibling [92] [93-95] [93-95] [93-95] Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NDietmar Eggemann <dietmar.eggemann@arm.com> Acked-by: NBarry Song <song.bao.hua@hisilicon.com> Tested-by: NDietmar Eggemann <dietmar.eggemann@arm.com> Link: https://lore.kernel.org/r/20211110095856.469360-1-bobo.shaobowang@huawei.com
-
由 M Chetan Kumar 提交于
curr_phase is unused. Removed the dead code. Fixes: 8d9be063 ("net: wwan: iosm: transport layer support for fw flashing/cd") Reported-by: Nkernel test robot <lkp@intel.com> Signed-off-by: NM Chetan Kumar <m.chetan.kumar@linux.intel.com> Reviewed-by: NLoic Poulain <loic.poulain@linaro.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Rahul Lakkireddy 提交于
Ensure diagnostics monitoring support is implemented for the SFF 8472 compliant port module and set the correct length for ethtool port module eeprom read. Fixes: f56ec676 ("cxgb4: Add support for ethtool i2c dump") Signed-off-by: NManoj Malviya <manojmalviya@chelsio.com> Signed-off-by: NRahul Lakkireddy <rahul.lakkireddy@chelsio.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Thomas Gleixner 提交于
free_msi_irqs() frees the MSI entries before destroying the sysfs entries which are exposing them. Nothing prevents a concurrent free while a sysfs file is read and accesses the possibly freed entry. Move the sysfs release ahead of freeing the entries. Fixes: 1c51b50c ("PCI/MSI: Export MSI mode using attributes, not kobjects") Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Bjorn Helgaas <helgaas@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/87sfw5305m.ffs@tglx
-
由 Marc Zyngier 提交于
The ION AHCI device pretends that MSI masking isn't a thing, while it actually implements it and needs MSIs to be unmasked to work. Add a quirk to that effect. Reported-by: NRui Salvaterra <rsalvaterra@gmail.com> Signed-off-by: NMarc Zyngier <maz@kernel.org> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Tested-by: NRui Salvaterra <rsalvaterra@gmail.com> Reviewed-by: NThomas Gleixner <tglx@linutronix.de> Cc: Bjorn Helgaas <helgaas@kernel.org> Link: https://lore.kernel.org/r/CALjTZvbzYfBuLB+H=fj2J+9=DxjQ2Uqcy0if_PvmJ-nU-qEgkg@mail.gmail.com Link: https://lore.kernel.org/r/20211104180130.3825416-3-maz@kernel.org
-
由 Marc Zyngier 提交于
It appears that some devices are lying about their mask capability, pretending that they don't have it, while they actually do. The net result is that now that we don't enable MSIs on such endpoint. Add a new per-device flag to deal with this. Further patches will make use of it, sadly. Signed-off-by: NMarc Zyngier <maz@kernel.org> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Reviewed-by: NThomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20211104180130.3825416-2-maz@kernel.org Cc: Bjorn Helgaas <helgaas@kernel.org>
-
由 Thomas Gleixner 提交于
The recent rework of PCI/MSI[X] masking moved the non-mask checks from the low level accessors into the higher level mask/unmask functions. This missed the fact that these accessors can be invoked from other places as well. The missing checks break XEN-PV which sets pci_msi_ignore_mask and also violates the virtual MSIX and the msi_attrib.maskbit protections. Instead of sprinkling checks all over the place, lift them back into the low level accessor functions. To avoid checking three different conditions combine them into one property of msi_desc::msi_attrib. [ josef: Fixed the missed conversion in the core code ] Fixes: fcacdfbe ("PCI/MSI: Provide a new set of mask and unmask functions") Reported-by: NJosef Johansson <josef@oderland.se> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Tested-by: NJosef Johansson <josef@oderland.se> Cc: Bjorn Helgaas <helgaas@kernel.org> Cc: stable@vger.kernel.org
-
由 xinhui pan 提交于
BO might sit in a wrong lru list as there is a small period of memory moving and lru list updating. Lets skip eviction if we hit such mismatch. Suggested-by: NChristian König <christian.koenig@amd.com> Signed-off-by: Nxinhui pan <xinhui.pan@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211110043149.57554-2-xinhui.pan@amd.comSigned-off-by: NChristian König <christian.koenig@amd.com>
-
由 Xu Wang 提交于
The print function dev_err() is redundant because platform_get_irq() already prints an error. Signed-off-by: NXu Wang <vulab@iscas.ac.cn> Signed-off-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com>
-
由 Damien Le Moal 提交于
Some ATA drives are very slow to respond to READ_LOG_EXT and READ_LOG_DMA_EXT commands issued from ata_dev_configure() when the device is revalidated right after resuming a system or inserting the ATA adapter driver (e.g. ahci). The default 5s timeout (ATA_EH_CMD_DFL_TIMEOUT) used for these commands is too short, causing errors during the device configuration. Ex: ... ata9: SATA max UDMA/133 abar m524288@0x9d200000 port 0x9d200400 irq 209 ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300) ata9.00: ATA-9: XXX XXXXXXXXXXXXXXX, XXXXXXXX, max UDMA/133 ata9.00: qc timeout (cmd 0x2f) ata9.00: Read log page 0x00 failed, Emask 0x4 ata9.00: Read log page 0x00 failed, Emask 0x40 ata9.00: NCQ Send/Recv Log not supported ata9.00: Read log page 0x08 failed, Emask 0x40 ata9.00: 27344764928 sectors, multi 16: LBA48 NCQ (depth 32), AA ata9.00: Read log page 0x00 failed, Emask 0x40 ata9.00: ATA Identify Device Log not supported ata9.00: failed to set xfermode (err_mask=0x40) ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300) ata9.00: configured for UDMA/133 ... The timeout error causes a soft reset of the drive link, followed in most cases by a successful revalidation as that give enough time to the drive to become fully ready to quickly process the read log commands. However, in some cases, this also fails resulting in the device being dropped. Fix this by using adding the ata_eh_revalidate_timeouts entries for the READ_LOG_EXT and READ_LOG_DMA_EXT commands. This defines a timeout increased to 15s, retriable one time. Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org> Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be> Cc: stable@vger.kernel.org Signed-off-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com>
-
由 Guchun Chen 提交于
Fixes: 96b8dd44 ("drm/amdgpu/amdgpu_vcn: convert to IP version checking") Signed-off-by: NFlora Cui <flora.cui@amd.com> Signed-off-by: NGuchun Chen <guchun.chen@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Guchun Chen 提交于
Fixes: b05b9c59 ("drm/amdgpu: clean up set IP function") Signed-off-by: NGuchun Chen <guchun.chen@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Shirish S 提交于
[Why] Video plane gets rejected for non-zero src_y and src_x on DCN2.x. [How] Limit the rejection till DCN1.x and verified MPO, by dragging video playback beyond display's left (0, 0) co-ordinates. Fixes: d89f6048 ("drm/amd/display: Reject non-zero src_y and src_x for video planes") Signed-off-by: NShirish S <shirish.s@amd.com> Reviewed-by: NHarry Wentland <harry.wentland@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 10 11月, 2021 9 次提交
-
-
由 Dan Carpenter 提交于
There is a minus character missing from ERR_PTR(ENOMEM) so if this allocation fails it will lead to an Oops in the caller. Fixes: dc48516e ("net/mlx5: Lag, add support to create definers for LAG") Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Reviewed-by: NLeon Romanovsky <leonro@nvidia.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dan Carpenter 提交于
The u64_stats_update_end() call is supposed to be inside the curly braces so it pairs with the u64_stats_update_begin(). Fixes: 37149e93 ("gve: Implement packet continuation for RX.") Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Aleksander Jan Bajkowski 提交于
This fixes the error detected when compiling the driver. Fixes: 14d4e308 ("net: lantiq: configure the burst length in ethernet drivers") Reported-by: Nkernel test robot <lkp@intel.com> Signed-off-by: NAleksander Jan Bajkowski <olek2@wp.pl> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Marek Behún 提交于
Commit bfe301eb ("net: mvpp2: convert to use mac_prepare()/mac_finish()") introduced a bug wherein it leaves the MAC RESET register asserted after mac_finish(), due to wrong order of function calls. Before it was: .mac_config() mvpp22_mode_reconfigure() assert reset mvpp2_xlg_config() deassert reset Now it is: .mac_prepare() .mac_config() mvpp2_xlg_config() deassert reset .mac_finish() mvpp2_xlg_config() assert reset Obviously this is wrong. This bug is triggered when phylink tries to change the PHY interface mode from a GMAC mode (sgmii, 1000base-x, 2500base-x) to XLG mode (10gbase-r, xaui). The XLG mode does not work since reset is left asserted. Only after ifconfig down && ifconfig up is called will the XLG mode work. Move the call to mvpp22_mode_reconfigure() to .mac_prepare() implementation. Since some of the subsequent functions need to know whether the interface is being changed, we unfortunately also need to pass around the new interface mode before setting port->phy_interface. Fixes: bfe301eb ("net: mvpp2: convert to use mac_prepare()/mac_finish()") Signed-off-by: NMarek Behún <kabel@kernel.org> Signed-off-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Christophe JAILLET 提交于
It is spurious to allocate a bitmap without initializing it. So, better safe than sorry, initialize it to 0 at least to have some known values. While at it, switch to the devm_bitmap_ API which is less verbose. Fixes: 4b41d343 ("net: ethernet: ti: cpsw: allow untagged traffic on host port") Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David Hildenbrand 提交于
The initial virtio-mem spec states that while unplugged memory should not be read, the device still has to allow for reading unplugged memory inside the usable region. The primary motivation for this default handling was to simplify bringup of virtio-mem, because there were corner cases where Linux might have accidentially read unplugged memory inside added Linux memory blocks. In the meantime, we: 1. Removed /dev/kmem in commit bbcd53c9 ("drivers/char: remove /dev/kmem for good") 2. Disallowed access to virtio-mem device memory via /dev/mem in commit 2128f4e2 ("virtio-mem: disallow mapping virtio-mem memory via /dev/mem") 3. Sanitized access to virtio-mem device memory via /proc/kcore in commit 0daa322b ("fs/proc/kcore: don't read offline sections, logically offline pages and hwpoisoned pages") 4. Sanitized access to virtio-mem device memory via /proc/vmcore in commit ce281462 ("virtio-mem: kdump mode to sanitize /proc/vmcore access") "Accidential" access to unplugged memory is no longer possible; we can support the new VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE feature that will be required by some hypervisors implementing virtio-mem in the near future. Acked-by: NMichael S. Tsirkin <mst@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Marek Kedzierski <mkedzier@redhat.com> Cc: Hui Zhu <teawater@gmail.com> Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Cc: Wei Yang <richard.weiyang@linux.alibaba.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com>
-
由 Vladimir Oltean 提交于
Commit fe28c53e ("net: stmmac: fix taprio configuration when base_time is in the past") allowed some base time values in the past, but apparently not all, the base-time value of 0 (Jan 1st 1970) is still explicitly denied by the driver. Remove the bogus check. Fixes: b60189e0 ("net: stmmac: Integrate EST with TAPRIO scheduler API") Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: NKurt Kanzenbach <kurt@linutronix.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Guangbin Huang 提交于
Currently, driver only allow configuring ETS bandwidth of TCs according to the max TC number queried from firmware. However, the hardware actually supports 8 TCs and users may need to configure ETS bandwidth of all TCs, so remove the restriction. Fixes: 330baff5 ("net: hns3: add ETS TC weight setting in SSU module") Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Guangbin Huang 提交于
If users set unicast mac address for VFs by PF, they need to guarantee all VFs' address is different. This patch removes the check mac address exist of VFs, for usrs can refresh mac addresses of all VFs directly without need to modify the exist mac address to other value firstly. Fixes: 8e6de441 ("net: hns3: add support for configuring VF MAC from the host") Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-