- Jun 27, 2023
-
-
Robert Nelson authored
v5.4.18-2021_0114 Signed-off-by:Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Reference: v5.4.18 Signed-off-by: -
Robert Nelson authored
Reference: v5.5.19 Signed-off-by: -
Robert Nelson authored
Reference: 1657f11c Signed-off-by:
-
Robert Nelson authored
Reference: v5.4.189 Signed-off-by: -
Robert Nelson authored
Reference: v5.12.19 Signed-off-by: -
-
-
-
-
Robert Nelson authored
Signed-off-by: -
-
Jason Kridner authoredFrom https://github.com/statropy/wpanusb
-
-
Robert Nelson authored
Signed-off-by: -
-
-
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by:
-
- Mar 29, 2021
-
-
LCPD Auto Merger authored
TI-Feature: connectivity TI-Branch: connectivity-ti-linux-5.4.y * 'connectivity-ti-linux-5.4.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/connectivity : net: ethernet: ti: am65-cpsw-qos: fix dma per-queue rate checks Signed-off-by:
LCPD Auto Merger <lcpd_integration@list.ti.com>
-
- Mar 28, 2021
-
-
There is a HW limitation that dma per-queue rate limiting has to be enabled sequentially from hi->lo channels. The driver performs checks for above, but does it incorrectly, as result it's not possible to disable rate limiting for the channel: echo 100 > /sys/class/net/eth0/queues/tx-7/tx_maxrate echo 0 > /sys/class/net/eth0/queues/tx-7/tx_maxrate ^ will fail. This patch fixes above issue. Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
Vignesh Raghavendra <vigneshr@ti.com>
-
- Mar 26, 2021
-
-
Aparna Balasubramanian authored
Merge tag 'v5.4.106' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into ti-linux-5.4.y This is the 5.4.106 stable release. * tag 'v5.4.106' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (925 commits) Linux 5.4.106 xen/events: avoid handling the same event on two cpus at the same time xen/events: don't unmask an event channel when an eoi is pending xen/events: reset affinity of 2-level event when tearing it down KVM: arm64: Reject VM creation when the default IPA size is unsupported KVM: arm64: Ensure I-cache isolation between vcpus of a same VM nvme: release namespace head reference on error nvme: unlink head after removing last namespace KVM: arm64: Fix exclusive limit for IPA size x86/unwind/orc: Disable KASAN checking in the ORC unwinder, part 2 binfmt_misc: fix possible deadlock in bm_register_write powerpc/64s: Fix instruction encoding for lis in ppc_function_entry() sched/membarrier: fix missing local execution of ipi_sync_r...
-
LCPD Auto Merger authored
TI-Feature: connectivity TI-Branch: connectivity-ti-linux-5.4.y * 'connectivity-ti-linux-5.4.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/connectivity : net: ethernet: ti: am65-cpsw: fix cut-thru link speed cfg Signed-off-by:
-
For cut-thru to be enabled the link speed has to be configured in CPSW_PN_SPEED_REG which supports two modes: - link speed auto detection which is implemented by driver by default - link speed manual configuration The driver checks CPSW_PN_SPEED_REG after link up event is detected by PHY and CPSW_PN_MAC_CONTROL_REG is configured. It was identified that depending on setup and runtime conditions the speed auto-detection can happen with different delays, so when driver reads CPSW_PN_SPEED_REG it sees that link speed has not been detected yet and disables cut-thru. Its recommended to use following delays after Link up is detected and MAC_SL configured - 15us in 10/100 mode and 3us in 1G mode. Hence, fix cut-thru link speed configuration be adding 40us delay before reading CPSW_PN_SPEED_REG and implement fall back to manual configuration if link speed auto detection fails. Signed-off-by:
-
- Mar 23, 2021
-
-
LCPD Auto Merger authored
TI-Feature: connectivity TI-Branch: connectivity-ti-linux-5.4.y * 'connectivity-ti-linux-5.4.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/connectivity : net: ethernet: ti: prueth: fix handling packets with timestamp Signed-off-by:
-
- Mar 19, 2021
-
-
The packets with timestamp (TS) got the TS placed in the data block following the packet data and TS data block has corresponding Buffer descriptor allocated. Now ICSS prueth driver reads packet data and TS properly, but releases only Buffer descriptors allocated for Packet data and misses Buffer descriptor allocated for TS. As result, the queue rd_ptr points on Buffer descriptor allocated for TS when driver switches to next packet processing which is all 0. This situation is detected by driver as critical error and driver tries to recover by discarding all existing packets in the RX queue (rd_ptr = wr_ptr). Hence, fix packets with timestamp processing by properly account Buffer descriptor allocated for TS. Fixes: 813f7dc8 ("net: ti: prueth: Add support for reading timestamps from rx packets") Signed-off-by:
-
- Mar 18, 2021
-
-
LCPD Auto Merger authored
TI-Feature: connectivity TI-Branch: connectivity-ti-linux-5.4.y * 'connectivity-ti-linux-5.4.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/connectivity : PCI: endpoint: Initialize "epf->node" in pci_epf_create() phy: cadence-torrent: Add delay for PIPE clock to be stable Signed-off-by:
-
Modify pci_epf_create() to take "struct device_node" as an argument and initialize epf->node. There is a race condition wherein probe of pci-epf-ntb.c gets invoked before epf->node is initialized in pci_epf_of_create(). Fix it here. Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
-
- Mar 17, 2021
-
-
The Torrent spec specifies delay of 660.5us after phy_reset is asserted by the controller. So provide a delay of 2ms in ->phy_on() callback where the SERDES is already configured in bootloader. Signed-off-by:
-
Greg Kroah-Hartman authored
Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Jason Self <jason@bluehome.net> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Hulk Robot <hulkrobot@huawei.com> Tested-by:
Ross Schmidt <ross.schm.dev@gmail.com> Link: https://lore.kernel.org/r/20210315135550.333963635@linuxfoundation.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Juergen Gross authored
commit b6622798 upstream. When changing the cpu affinity of an event it can happen today that (with some unlucky timing) the same event will be handled on the old and the new cpu at the same time. Avoid that by adding an "event active" flag to the per-event data and call the handler only if this flag isn't set. Cc: stable@vger.kernel.org Reported-by:
Julien Grall <julien@xen.org> Signed-off-by:
Juergen Gross <jgross@suse.com> Reviewed-by:
Julien Grall <jgrall@amazon.com> Link: https://lore.kernel.org/r/20210306161833.4552-4-jgross@suse.com Signed-off-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by:
-
Juergen Gross authored
commit 25da4618 upstream. An event channel should be kept masked when an eoi is pending for it. When being migrated to another cpu it might be unmasked, though. In order to avoid this keep three different flags for each event channel to be able to distinguish "normal" masking/unmasking from eoi related masking/unmasking and temporary masking. The event channel should only be able to generate an interrupt if all flags are cleared. Cc: stable@vger.kernel.org Fixes: 54c9de89 ("xen/events: add a new "late EOI" evtchn framework") Reported-by:
Ross Lagerwall <ross.lagerwall@citrix.com> Link: https://lore.kernel.org/r/20210306161833.4552-3-jgross@suse.com [boris -- corrected Fixed tag format] Signed-off-by:
-
Juergen Gross authored
commit 9e77d96b upstream. When creating a new event channel with 2-level events the affinity needs to be reset initially in order to avoid using an old affinity from earlier usage of the event channel port. So when tearing an event channel down reset all affinity bits. The same applies to the affinity when onlining a vcpu: all old affinity settings for this vcpu must be reset. As percpu events get initialized before the percpu event channel hook is called, resetting of the affinities happens after offlining a vcpu (this is working, as initial percpu memory is zeroed out). Cc: stable@vger.kernel.org Reported-by:
-
Marc Zyngier authored
Commit 7d717558 upstream. KVM/arm64 has forever used a 40bit default IPA space, partially due to its 32bit heritage (where the only choice is 40bit). However, there are implementations in the wild that have a *cough* much smaller *cough* IPA space, which leads to a misprogramming of VTCR_EL2, and a guest that is stuck on its first memory access if userspace dares to ask for the default IPA setting (which most VMMs do). Instead, blundly reject the creation of such VM, as we can't satisfy the requirements from userspace (with a one-off warning). Also clarify the boot warning, and document that the VM creation will fail when an unsupported IPA size is provided. Although this is an ABI change, it doesn't really change much for userspace: - the guest couldn't run before this change, but no error was returned. At least userspace knows what is happening. - a memory slot that was accepted because it did fit the default IPA space now doesn't even get a chance to be registered. The other thing that is left doing is to convince userspace to actually use the IPA space setting instead of relying on the antiquated default. Fixes: 233a7cb2 ("kvm: arm64: Allow tuning the physical address size for VM") Signed-off-by:
Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org Reviewed-by:
Andrew Jones <drjones@redhat.com> Reviewed-by:
Eric Auger <eric.auger@redhat.com> Link: https://lore.kernel.org/r/20210311100016.3830038-2-maz@kernel.org Signed-off-by:
-
Marc Zyngier authored
Commit 01dc9262 upstream. It recently became apparent that the ARMv8 architecture has interesting rules regarding attributes being used when fetching instructions if the MMU is off at Stage-1. In this situation, the CPU is allowed to fetch from the PoC and allocate into the I-cache (unless the memory is mapped with the XN attribute at Stage-2). If we transpose this to vcpus sharing a single physical CPU, it is possible for a vcpu running with its MMU off to influence another vcpu running with its MMU on, as the latter is expected to fetch from the PoU (and self-patching code doesn't flush below that level). In order to solve this, reuse the vcpu-private TLB invalidation code to apply the same policy to the I-cache, nuking it every time the vcpu runs on a physical CPU that ran another vcpu of the same VM in the past. This involve renaming __kvm_tlb_flush_local_vmid() to __kvm_flush_cpu_context(), and insert...
-
Keith Busch authored
commit ac262508 upstream. If a namespace identification does not match the subsystem's head for that NSID, release the reference that was taken when the matching head was initially found. Signed-off-by:
Keith Busch <kbusch@kernel.org> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Keith Busch authored
commit d5675729 upstream. The driver had been unlinking the namespace head from the subsystem's list only after the last reference was released, and outside of the list's subsys->lock protection. There is no reason to track an empty head, so unlink the entry from the subsystem's list when the last namespace using that head is removed and with the mutex lock protecting the list update. The next namespace to attach reusing the previous NSID will allocate a new head rather than find the old head with mismatched identifiers. Signed-off-by:
-
Marc Zyngier authored
commit 262b003d upstream. When registering a memslot, we check the size and location of that memslot against the IPA size to ensure that we can provide guest access to the whole of the memory. Unfortunately, this check rejects memslot that end-up at the exact limit of the addressing capability for a given IPA size. For example, it refuses the creation of a 2GB memslot at 0x8000000 with a 32bit IPA space. Fix it by relaxing the check to accept a memslot reaching the limit of the IPA space. Fixes: c3058d5d ("arm/arm64: KVM: Ensure memslots are within KVM_PHYS_SIZE") Reviewed-by:
-
