aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-11-10i40e, xsk: uninitialized variable in i40e_clean_rx_irq_zc()Dan Carpenter1-1/+1
The "failure" variable is used without being initialized. It should be set to false. Fixes: 8cbf74149903 ("i40e, xsk: move buffer allocation out of the Rx processing loop") Signed-off-by: Dan Carpenter <[email protected]> Acked-by: Björn Töpel <[email protected]> Tested-by: George Kuruvinakunnel <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2020-11-10i40e: Fix MAC address setting for a VF via Host/VMSlawomir Laba1-2/+24
Fix MAC setting flow for the PF driver. Update the unicast VF's MAC address in VF structure if it is a new setting in i40e_vc_add_mac_addr_msg. When unicast MAC address gets deleted, record that and set the new unicast MAC address that is already waiting in the filter list. This logic is based on the order of messages arriving to the PF driver. Without this change the MAC address setting was interpreted incorrectly in the following use cases: 1) Print incorrect VF MAC or zero MAC ip link show dev $pf 2) Don't preserve MAC between driver reload rmmod iavf; modprobe iavf 3) Update VF MAC when macvlan was set ip link add link $vf address $mac $vf.1 type macvlan 4) Failed to update mac address when VF was trusted ip link set dev $vf address $mac This includes all other configurations including above commands. Fixes: f657a6e1313b ("i40e: Fix VF driver MAC address configuration") Signed-off-by: Slawomir Laba <[email protected]> Tested-by: Konrad Jankowski <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2020-11-10selftest: fix flower terse dump testsVlad Buslov1-2/+2
Iproute2 tc classifier terse dump has been accepted with modified syntax. Update the tests accordingly. Signed-off-by: Vlad Buslov <[email protected]> Fixes: e7534fd42a99 ("selftests: implement flower classifier terse dump tests") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-10um: Call pgtable_pmd_page_dtor() in __pmd_free_tlb()Richard Weinberger1-1/+7
Commit b2b29d6d0119 ("mm: account PMD tables like PTE tables") uncovered a bug in uml, we forgot to call the destructor. While we are here, give x a sane name. Reported-by: Anton Ivanov <[email protected]> Co-developed-by: Matthew Wilcox (Oracle) <[email protected]> Signed-off-by: Richard Weinberger <[email protected]> Tested-by: Christopher Obbard <[email protected]>
2020-11-10Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds1-1/+4
Pull core dump fix from Al Viro: "Fix for multithreaded coredump playing fast and loose with getting registers of secondary threads; if a secondary gets caught in the middle of exit(2), the conditition it will be stopped in for dumper to examine might be unusual enough for things to go wrong. Quite a few architectures are fine with that, but some are not." * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: don't dump the threads that had been already exiting when zapped.
2020-11-10Merge tag 'for-5.10-rc3-tag' of ↵Linus Torvalds8-39/+48
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fixes from David Sterba: "A handful of minor fixes and updates: - handle missing device replace item on mount (syzbot report) - fix space reservation calculation when finishing relocation - fix memory leak on error path in ref-verify (debugging feature) - fix potential overflow during defrag on 32bit arches - minor code update to silence smatch warning - minor error message updates" * tag 'for-5.10-rc3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: ref-verify: fix memory leak in btrfs_ref_tree_mod btrfs: dev-replace: fail mount if we don't have replace item with target device btrfs: scrub: update message regarding read-only status btrfs: clean up NULL checks in qgroup_unreserve_range() btrfs: fix min reserved size calculation in merge_reloc_root btrfs: print the block rsv type when we fail our reservation btrfs: fix potential overflow in cluster_pages_for_defrag on 32bit arch
2020-11-10Merge tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/fs/fscrypt/fscryptLinus Torvalds1-3/+1
Pull fscrypt fix from Eric Biggers: "Fix a regression where a new WARN_ON() was reachable when using FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32 on ext4, causing xfstest generic/602 to sometimes fail on ext4" * tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/fs/fscrypt/fscrypt: fscrypt: remove reachable WARN in fscrypt_setup_iv_ino_lblk_32_key()
2020-11-10Merge branch 'turbostat' of ↵Linus Torvalds5-140/+509
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux Pull turbostat updates from Len Brown: "Update update to version 20.09.30, one kernel side fix" * 'turbostat' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux: tools/power turbostat: update version number powercap: restrict energy meter to root access tools/power turbostat: harden against cpu hotplug tools/power turbostat: adjust for temperature offset tools/power turbostat: Build with _FILE_OFFSET_BITS=64 tools/power turbostat: Support AMD Family 19h tools/power turbostat: Remove empty columns for Jacobsville tools/power turbostat: Add a new GFXAMHz column that exposes gt_act_freq_mhz. tools/power x86_energy_perf_policy: Input/output error in a VM tools/power turbostat: Skip pc8, pc9, pc10 columns, if they are disabled tools/power turbostat: Support additional CPU model numbers tools/power turbostat: Fix output formatting for ACPI CST enumeration tools/power turbostat: Replace HTTP links with HTTPS ones: TURBOSTAT UTILITY tools/power turbostat: Use sched_getcpu() instead of hardcoded cpu 0 tools/power turbostat: Enable accumulate RAPL display tools/power turbostat: Introduce functions to accumulate RAPL consumption tools/power turbostat: Make the energy variable to be 64 bit tools/power turbostat: Always print idle in the system configuration header tools/power turbostat: Print /dev/cpu_dma_latency
2020-11-10ACPI: DPTF: Support Alder LakeSrinivas Pandruvada4-0/+10
Add Alder Lake ACPI IDs for DPTF devices. Signed-off-by: Srinivas Pandruvada <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-11-10Documentation: ACPI: fix spelling mistakesFlavio Suligoi2-5/+5
Signed-off-by: Flavio Suligoi <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-11-10sched/debug: Fix memory corruption caused by multiple small reads of flagsColin Ian King1-6/+6
Reading /proc/sys/kernel/sched_domain/cpu*/domain0/flags mutliple times with small reads causes oopses with slub corruption issues because the kfree is free'ing an offset from a previous allocation. Fix this by adding in a new pointer 'buf' for the allocation and kfree and use the temporary pointer tmp to handle memory copies of the buf offsets. Fixes: 5b9f8ff7b320 ("sched/debug: Output SD flag names rather than their values") Reported-by: Jeff Bastian <[email protected]> Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Valentin Schneider <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-11-10sched/fair: Prefer prev cpu in asymmetric wakeup pathVincent Guittot1-24/+43
During fast wakeup path, scheduler always check whether local or prev cpus are good candidates for the task before looking for other cpus in the domain. With commit b7a331615d25 ("sched/fair: Add asymmetric CPU capacity wakeup scan") the heterogenous system gains a dedicated path but doesn't try to reuse prev cpu whenever possible. If the previous cpu is idle and belong to the LLC domain, we should check it 1st before looking for another cpu because it stays one of the best candidate and this also stabilizes task placement on the system. This change aligns asymmetric path behavior with symmetric one and reduces cases where the task migrates across all cpus of the sd_asym_cpucapacity domains at wakeup. This change does not impact normal EAS mode but only the overloaded case or when EAS is not used. - On hikey960 with performance governor (EAS disable) ./perf bench sched pipe -T -l 50000 mainline w/ patch # migrations 999364 0 ops/sec 149313(+/-0.28%) 182587(+/- 0.40) +22% - On hikey with performance governor ./perf bench sched pipe -T -l 50000 mainline w/ patch # migrations 0 0 ops/sec 47721(+/-0.76%) 47899(+/- 0.56) +0.4% According to test on hikey, the patch doesn't impact symmetric system compared to current implementation (only tested on arm64) Also read the uclamped value of task's utilization at most twice instead instead each time we compare task's utilization with cpu's capacity. Fixes: b7a331615d25 ("sched/fair: Add asymmetric CPU capacity wakeup scan") Signed-off-by: Vincent Guittot <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Tested-by: Dietmar Eggemann <[email protected]> Reviewed-by: Valentin Schneider <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-11-10sched/fair: Ensure tasks spreading in LLC during LBVincent Guittot1-1/+2
schbench shows latency increase for 95 percentile above since: commit 0b0695f2b34a ("sched/fair: Rework load_balance()") Align the behavior of the load balancer with the wake up path, which tries to select an idle CPU which belongs to the LLC for a waking task. calculate_imbalance() will use nr_running instead of the spare capacity when CPUs share resources (ie cache) at the domain level. This will ensure a better spread of tasks on idle CPUs. Running schbench on a hikey (8cores arm64) shows the problem: tip/sched/core : schbench -m 2 -t 4 -s 10000 -c 1000000 -r 10 Latency percentiles (usec) 50.0th: 33 75.0th: 45 90.0th: 51 95.0th: 4152 *99.0th: 14288 99.5th: 14288 99.9th: 14288 min=0, max=14276 tip/sched/core + patch : schbench -m 2 -t 4 -s 10000 -c 1000000 -r 10 Latency percentiles (usec) 50.0th: 34 75.0th: 47 90.0th: 52 95.0th: 78 *99.0th: 94 99.5th: 94 99.9th: 94 min=0, max=94 Fixes: 0b0695f2b34a ("sched/fair: Rework load_balance()") Reported-by: Chris Mason <[email protected]> Suggested-by: Rik van Riel <[email protected]> Signed-off-by: Vincent Guittot <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Rik van Riel <[email protected]> Tested-by: Rik van Riel <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-11-10perf/x86/intel/uncore: Fix Add BW copypastaArnd Bergmann1-1/+1
gcc -Wextra points out a duplicate initialization of one array member: arch/x86/events/intel/uncore_snb.c:478:37: warning: initialized field overwritten [-Woverride-init] 478 | [SNB_PCI_UNCORE_IMC_DATA_READS] = { SNB_UNCORE_PCI_IMC_DATA_WRITES_BASE, The only sensible explanation is that a duplicate 'READS' was used instead of the correct 'WRITES', so change it back. Fixes: 24633d901ea4 ("perf/x86/intel/uncore: Add BW counters for GT, IA and IO breakdown") Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-11-10lockdep: Avoid to modify chain keys in validate_chain()Boqun Feng1-10/+9
Chris Wilson reported a problem spotted by check_chain_key(): a chain key got changed in validate_chain() because we modify the ->read in validate_chain() to skip checks for dependency adding, and ->read is taken into calculation for chain key since commit f611e8cf98ec ("lockdep: Take read/write status in consideration when generate chainkey"). Fix this by avoiding to modify ->read in validate_chain() based on two facts: a) since we now support recursive read lock detection, there is no need to skip checks for dependency adding for recursive readers, b) since we have a), there is only one case left (nest_lock) where we want to skip checks in validate_chain(), we simply remove the modification for ->read and rely on the return value of check_deadlock() to skip the dependency adding. Reported-by: Chris Wilson <[email protected]> Signed-off-by: Boqun Feng <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-11-10cpufreq: intel_pstate: Take CPUFREQ_GOV_STRICT_TARGET into accountRafael J. Wysocki1-7/+9
Make intel_pstate take the new CPUFREQ_GOV_STRICT_TARGET governor flag into account when it operates in the passive mode with HWP enabled, so as to fix the "powersave" governor behavior in that case (currently, HWP is allowed to scale the performance all the way up to the policy max limit when the "powersave" governor is used, but it should be constrained to the policy min limit then). Fixes: f6ebbcf08f37 ("cpufreq: intel_pstate: Implement passive mode with HWP enabled") Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Viresh Kumar <[email protected]> Cc: 5.9+ <[email protected]> # 5.9+: 9a2a9ebc0a75 cpufreq: Introduce governor flags Cc: 5.9+ <[email protected]> # 5.9+: 218f66870181 cpufreq: Introduce CPUFREQ_GOV_STRICT_TARGET Cc: 5.9+ <[email protected]> # 5.9+: ea9364bbadf1 cpufreq: Add strict_target to struct cpufreq_policy
2020-11-10cpufreq: Add strict_target to struct cpufreq_policyRafael J. Wysocki2-0/+8
Add a new field to be set when the CPUFREQ_GOV_STRICT_TARGET flag is set for the current governor to struct cpufreq_policy, so that the drivers needing to check CPUFREQ_GOV_STRICT_TARGET do not have to access the governor object during every frequency transition. Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Viresh Kumar <[email protected]>
2020-11-10cpufreq: Introduce CPUFREQ_GOV_STRICT_TARGETRafael J. Wysocki3-0/+5
Introduce a new governor flag, CPUFREQ_GOV_STRICT_TARGET, for the governors that want the target frequency to be set exactly to the given value without leaving any room for adjustments on the hardware side and set this flag for the powersave and performance governors. Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Viresh Kumar <[email protected]>
2020-11-10cpufreq: Introduce governor flagsRafael J. Wysocki4-5/+10
A new cpufreq governor flag will be added subsequently, so replace the bool dynamic_switching fleid in struct cpufreq_governor with a flags field and introduce CPUFREQ_GOV_DYNAMIC_SWITCHING to set for the "dynamic switching" governors instead of it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Viresh Kumar <[email protected]>
2020-11-10tools/power turbostat: update version numberLen Brown1-1/+1
goodbye summer... Signed-off-by: Len Brown <[email protected]>
2020-11-10powercap: restrict energy meter to root accessLen Brown1-2/+2
Remove non-privileged user access to power data contained in /sys/class/powercap/intel-rapl*/*/energy_uj Non-privileged users currently have read access to power data and can use this data to form a security attack. Some privileged drivers/applications need read access to this data, but don't expose it to non-privileged users. For example, thermald uses this data to ensure that power management works correctly. Thus removing non-privileged access is preferred over completely disabling this power reporting capability with CONFIG_INTEL_RAPL=n. Fixes: 95677a9a3847 ("PowerCap: Fix mode for energy counter") Signed-off-by: Len Brown <[email protected]> Cc: [email protected]
2020-11-10nbd: fix a block_device refcount leak in nbd_releaseChristoph Hellwig1-0/+1
bdget_disk needs to be paired with bdput to not leak a reference on the block device inode. Fixes: 08ba91ee6e2c ("nbd: Add the nbd NBD_DISCONNECT_ON_CLOSE config flag.") Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Josef Bacik <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-11-10Merge tag 'nvme-5.10-2020-11-10' of git://git.infradead.org/nvme into block-5.10Jens Axboe1-2/+0
Pull NVMe fix from Christoph: "nvme fixes for 5.10: - don't clear the read-only bit on a revalidate (Sagi Grimberg)" * tag 'nvme-5.10-2020-11-10' of git://git.infradead.org/nvme: nvme: fix incorrect behavior when BLKROSET is called by the user
2020-11-10Merge tag 'intel-pinctrl-v5.10-2' of ↵Linus Walleij1-10/+30
git://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel into fixes intel-pinctrl for v5.10-2 * Respect bias setting when comes from ACPI The following is an automated git shortlog grouped by driver: intel: - Set default bias in case no particular value given - Fix 2 kOhm bias which is 833 Ohm
2020-11-10pinctrl: qcom: sm8250: Specify PDC mapBjorn Andersson1-0/+18
Specify the PDC mapping for SM8250, so that gpio interrupts are propertly mapped to the wakeup IRQs of the PDC. Fixes: 4e3ec9e407ad ("pinctrl: qcom: Add sm8250 pinctrl driver.") Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-11-10pinctrl: qcom: Move clearing pending IRQ to .irq_request_resources callbackMaulik Shah1-13/+19
When GPIOs that are routed to PDC are used as output they can still latch the IRQ pending at GIC. As a result the spurious IRQ was handled when the client driver change the direction to input to starts using it as IRQ. Currently such erroneous latched IRQ are cleared with .irq_enable callback however if the driver continue to use GPIO as interrupt and invokes disable_irq() followed by enable_irq() then everytime during enable_irq() previously latched interrupt gets cleared. This can make edge IRQs not seen after enable_irq() if they had arrived after the driver has invoked disable_irq() and were pending at GIC. Move clearing erroneous IRQ to .irq_request_resources callback as this is the place where GPIO direction is changed as input and its locked as IRQ. While at this add a missing check to invoke msm_gpio_irq_clear_unmask() from .irq_enable callback only when GPIO is not routed to PDC. Fixes: e35a6ae0eb3a ("pinctrl/msm: Setup GPIO chip in hierarchy") Signed-off-by: Maulik Shah <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-11-10pinctrl: amd: use higher precision for 512 RtcClkCoiby Xu1-1/+1
RTC is 32.768kHz thus 512 RtcClk equals 15625 usec. The documentation likely has dropped precision and that's why the driver mistakenly took the slightly deviated value. Cc: [email protected] Reported-by: Andy Shevchenko <[email protected]> Suggested-by: Andy Shevchenko <[email protected]> Suggested-by: Hans de Goede <[email protected]> Signed-off-by: Coiby Xu <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/linux-gpio/[email protected]/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-11-10pinctrl: amd: fix incorrect way to disable debounce filterCoiby Xu1-2/+2
The correct way to disable debounce filter is to clear bit 5 and 6 of the register. Cc: [email protected] Signed-off-by: Coiby Xu <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Cc: Hans de Goede <[email protected]> Link: https://lore.kernel.org/linux-gpio/[email protected]/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-11-10Merge tag 'gpio-fixes-for-v5.10-rc3' of ↵Linus Walleij5-26/+74
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into fixes gpio fixes for v5.10-rc3 - fix missing conversion to gpiolib irqchip in gpio-dwapb - fix bank properties for ast2600 variant in gpio-aspeed - make sysfs work again when the character device is disabled - fix interrupt handling in gpio-pcie-idio-24
2020-11-10arm64: smp: Tell RCU about CPUs that fail to come onlineWill Deacon2-1/+2
Commit ce3d31ad3cac ("arm64/smp: Move rcu_cpu_starting() earlier") ensured that RCU is informed early about incoming CPUs that might end up calling into printk() before they are online. However, if such a CPU fails the early CPU feature compatibility checks in check_local_cpu_capabilities(), then it will be powered off or parked without informing RCU, leading to an endless stream of stalls: | rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: | rcu: 2-O...: (0 ticks this GP) idle=002/1/0x4000000000000000 softirq=0/0 fqs=2593 | (detected by 0, t=5252 jiffies, g=9317, q=136) | Task dump for CPU 2: | task:swapper/2 state:R running task stack: 0 pid: 0 ppid: 1 flags:0x00000028 | Call trace: | ret_from_fork+0x0/0x30 Ensure that the dying CPU invokes rcu_report_dead() prior to being powered off or parked. Cc: Qian Cai <[email protected]> Cc: "Paul E. McKenney" <[email protected]> Reviewed-by: Paul E. McKenney <[email protected]> Suggested-by: Qian Cai <[email protected]> Link: https://lore.kernel.org/r/20201105222242.GA8842@willie-the-truck Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-11-10arm64: psci: Avoid printing in cpu_psci_cpu_die()Will Deacon1-4/+1
cpu_psci_cpu_die() is called in the context of the dying CPU, which will no longer be online or tracked by RCU. It is therefore not generally safe to call printk() if the PSCI "cpu off" request fails, so remove the pr_crit() invocation. Cc: Qian Cai <[email protected]> Cc: "Paul E. McKenney" <[email protected]> Cc: Catalin Marinas <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-11-10arm64: kexec_file: Fix sparse warningWill Deacon1-1/+1
Sparse gets cross about us returning 0 from image_load(), which has a return type of 'void *': >> arch/arm64/kernel/kexec_image.c:130:16: sparse: sparse: Using plain integer as NULL pointer Return NULL instead, as we don't use the return value for anything if it does not indicate an error. Cc: Benjamin Gwin <[email protected]> Reported-by: kernel test robot <[email protected]> Fixes: 108aa503657e ("arm64: kexec_file: try more regions if loading segments fails") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-11-10arm64: errata: Fix handling of 1418040 with late CPU onliningWill Deacon2-3/+4
In a surprising turn of events, it transpires that CPU capabilities configured as ARM64_CPUCAP_WEAK_LOCAL_CPU_FEATURE are never set as the result of late-onlining. Therefore our handling of erratum 1418040 does not get activated if it is not required by any of the boot CPUs, even though we allow late-onlining of an affected CPU. In order to get things working again, replace the cpus_have_const_cap() invocation with an explicit check for the current CPU using this_cpu_has_cap(). Cc: Sai Prakash Ranjan <[email protected]> Cc: Stephen Boyd <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Mark Rutland <[email protected]> Reviewed-by: Suzuki K Poulose <[email protected]> Acked-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-11-10Revert "mmc: renesas_sdhi: workaround a regression when reinserting SD cards"Wolfram Sang1-13/+0
This reverts commit db1af1e9712920f47b5dc6a995fca3eec05ea85e. It was only a workaround to hide a regression. We now have proper fixes. Signed-off-by: Wolfram Sang <[email protected]> Tested-by: Niklas Söderlund <[email protected]> Reviewed-by: Yoshihiro Shimoda <[email protected]> Tested-by: Yoshihiro Shimoda <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2020-11-10mmc: tmio: bring tuning HW to a sane state with MMC_POWER_OFFWolfram Sang1-0/+3
When powering off a card, we need to disable the tuning HW (like SCC for the Renesas SDHI) to get to a sane state and allow for re-tuning new cards. This was hidden before because we wrongly did that in hw_reset() before which was an unintended use of hw_reset(). Now that we corrected the use of hw_reset() meanwhile, we revealed this shortcoming and need to fix it properly by explicitly calling the downgrade callback. Fixes: 6e7d4de10890 ("mmc: renesas_sdhi: move wrong 'hw_reset' to 'reset'") Suggested-by: Takeshi Saito <[email protected]> Reviewed-by: Takeshi Saito <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Tested-by: Niklas Söderlund <[email protected]> Reviewed-by: Yoshihiro Shimoda <[email protected]> Tested-by: Yoshihiro Shimoda <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2020-11-10mmc: tmio: when resetting, reset DMA controller, tooWolfram Sang1-2/+2
When applying a revert, the assumption that DMA only needs to be cleared in specific cases was wrong. We want to reset the DMA controller every time the rest of the HW gets reset, too. Fixes: 34e3211e5492 ("Revert "mmc: tmio: fix reset operation"") Reported-by: Yoshihiro Shimoda <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Tested-by: Niklas Söderlund <[email protected]> Reviewed-by: Yoshihiro Shimoda <[email protected]> Tested-by: Yoshihiro Shimoda <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2020-11-10mmc: sdhci-of-esdhc: Handle pulse width detection erratum for more SoCsYangbo Lu1-0/+2
Apply erratum workaround of unreliable pulse width detection to more affected platforms (LX2160A Rev2.0 and LS1028A Rev1.0). Signed-off-by: Yangbo Lu <[email protected]> Fixes: 48e304cc1970 ("mmc: sdhci-of-esdhc: workaround for unreliable pulse width detection") Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2020-11-10mmc: renesas_sdhi_core: Add missing tmio_mmc_host_free() at removeYoshihiro Shimoda1-0/+1
The commit 94b110aff867 ("mmc: tmio: add tmio_mmc_host_alloc/free()") added tmio_mmc_host_free(), but missed the function calling in the sh_mobile_sdhi_remove() at that time. So, fix it. Otherwise, we cannot rebind the sdhi/mmc devices when we use aliases of mmc. Fixes: 94b110aff867 ("mmc: tmio: add tmio_mmc_host_alloc/free()") Signed-off-by: Yoshihiro Shimoda <[email protected]> Reviewed-by: Wolfram Sang <[email protected]> Tested-by: Wolfram Sang <[email protected]> Reviewed-by: Niklas Söderlund <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/1604654730-29914-1-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Ulf Hansson <[email protected]>
2020-11-10KVM: arm64: Drop kvm_coproc.hMarc Zyngier7-44/+18
kvm_coproc.h used to serve as a compatibility layer for the files shared between the 32 and 64 bit ports. Another one bites the dust... Signed-off-by: Marc Zyngier <[email protected]>
2020-11-10KVM: arm64: Drop legacy copro shadow registerMarc Zyngier1-47/+1
Finally remove one of the biggest 32bit legacy: the copro shadow mapping. We won't missit. Signed-off-by: Marc Zyngier <[email protected]>
2020-11-10KVM: arm64: Drop is_aarch32 trap attributeMarc Zyngier3-8/+2
is_aarch32 is only used once, and can be trivially replaced by testing Op0 instead. Drop it. Signed-off-by: Marc Zyngier <[email protected]>
2020-11-10KVM: arm64: Drop is_32bit trap attributeMarc Zyngier3-6/+0
The is_32bit attribute is now completely unused, drop it. Signed-off-by: Marc Zyngier <[email protected]>
2020-11-10KVM: arm64: Map AArch32 cp14 register to AArch64 sysregsMarc Zyngier2-80/+37
Similarly to what has been done on the cp15 front, repaint the debug registers to use their AArch64 counterparts. This results in some simplification as we can remove the 32bit-specific accessors. Signed-off-by: Marc Zyngier <[email protected]>
2020-11-10KVM: arm64: Map AArch32 cp15 register to AArch64 sysregsMarc Zyngier1-48/+66
Move all the cp15 registers over to their AArch64 counterpart. This requires the annotation of a few of them (such as the usual DFAR/IFAR vs FAR_EL1), and a new helper that generates mask/shift pairs for the various configurations. Signed-off-by: Marc Zyngier <[email protected]>
2020-11-10KVM: arm64: Add AArch32 mapping annotationMarc Zyngier1-0/+7
In order to deal with the few AArch32 system registers that map to only a particular half of their AArch64 counterpart (such as DFAR and IFAR being colocated in FAR_EL1), let's add an optional annotation to the sysreg descriptor structure, indicating whether a register maps to the upper or lower 32bits of a register. Nothing is using these annotation yet. Signed-off-by: Marc Zyngier <[email protected]>
2020-11-10KVM: arm64: Move AArch32 exceptions over to AArch64 sysregsMarc Zyngier2-43/+20
The use of the AArch32-specific accessors have always been a bit annoying on 64bit, and it is time for a change. Let's move the AArch32 exception injection over to the AArch64 encoding, which requires us to split the two halves of FAR_EL1 into DFAR and IFAR. This enables us to drop the preempt_disable() games on VHE, and to kill the last user of the vcpu_cp15() macro. Signed-off-by: Marc Zyngier <[email protected]>
2020-11-10KVM: arm64: Introduce handling of AArch32 TTBCR2 trapsMarc Zyngier2-0/+2
ARMv8.2 introduced TTBCR2, which shares TCR_EL1 with TTBCR. Gracefully handle traps to this register when HCR_EL2.TVM is set. Cc: [email protected] Reported-by: James Morse <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2020-11-10KVM: arm64: Get rid of the AArch32 register mapping codeMarc Zyngier4-134/+26
The only use of the register mapping code was for the sake of the LR mapping, which we trivially solved in a previous patch. Get rid of the whole thing now. Signed-off-by: Marc Zyngier <[email protected]>
2020-11-10KVM: arm64: Consolidate exception injectionMarc Zyngier4-102/+73
Move the AArch32 exception injection code back into the inject_fault.c file, removing the need for a few non-static functions now that AArch32 host support is a thing of the past. Signed-off-by: Marc Zyngier <[email protected]>
2020-11-10KVM: arm64: Remove SPSR manipulation primitivesMarc Zyngier2-122/+0
The SPSR setting code is now completely unused, including that dealing with banked AArch32 SPSRs. Cleanup time. Acked-by: Mark Rutland <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.