aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2020-10-12Merge tag 'm68k-for-v5.10-tag1' of ↵Linus Torvalds3-27/+48
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k Pull m68k updates from Geert Uytterhoeven: - Conversion of the Mac IDE driver to a platform driver - Minor cleanups and fixes * tag 'm68k-for-v5.10-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k: ide/macide: Convert Mac IDE driver to platform driver m68k: Replace HTTP links with HTTPS ones m68k: mm: Remove superfluous memblock_alloc*() casts m68k: mm: Use PAGE_ALIGNED() helper m68k: Sort selects in main Kconfig m68k: amiga: Clean up Amiga hardware configuration m68k: Revive _TIF_* masks m68k: Correct some typos in comments m68k: Use get_kernel_nofault() in show_registers() zorro: Fix address space collision message with RAM expansion boards m68k: amiga: Fix Denise detection on OCS
2020-10-12Merge tag 'arm64-upstream' of ↵Linus Torvalds12-225/+2004
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 updates from Will Deacon: "There's quite a lot of code here, but much of it is due to the addition of a new PMU driver as well as some arm64-specific selftests which is an area where we've traditionally been lagging a bit. In terms of exciting features, this includes support for the Memory Tagging Extension which narrowly missed 5.9, hopefully allowing userspace to run with use-after-free detection in production on CPUs that support it. Work is ongoing to integrate the feature with KASAN for 5.11. Another change that I'm excited about (assuming they get the hardware right) is preparing the ASID allocator for sharing the CPU page-table with the SMMU. Those changes will also come in via Joerg with the IOMMU pull. We do stray outside of our usual directories in a few places, mostly due to core changes required by MTE. Although much of this has been Acked, there were a couple of places where we unfortunately didn't get any review feedback. Other than that, we ran into a handful of minor conflicts in -next, but nothing that should post any issues. Summary: - Userspace support for the Memory Tagging Extension introduced by Armv8.5. Kernel support (via KASAN) is likely to follow in 5.11. - Selftests for MTE, Pointer Authentication and FPSIMD/SVE context switching. - Fix and subsequent rewrite of our Spectre mitigations, including the addition of support for PR_SPEC_DISABLE_NOEXEC. - Support for the Armv8.3 Pointer Authentication enhancements. - Support for ASID pinning, which is required when sharing page-tables with the SMMU. - MM updates, including treating flush_tlb_fix_spurious_fault() as a no-op. - Perf/PMU driver updates, including addition of the ARM CMN PMU driver and also support to handle CPU PMU IRQs as NMIs. - Allow prefetchable PCI BARs to be exposed to userspace using normal non-cacheable mappings. - Implementation of ARCH_STACKWALK for unwinding. - Improve reporting of unexpected kernel traps due to BPF JIT failure. - Improve robustness of user-visible HWCAP strings and their corresponding numerical constants. - Removal of TEXT_OFFSET. - Removal of some unused functions, parameters and prototypes. - Removal of MPIDR-based topology detection in favour of firmware description. - Cleanups to handling of SVE and FPSIMD register state in preparation for potential future optimisation of handling across syscalls. - Cleanups to the SDEI driver in preparation for support in KVM. - Miscellaneous cleanups and refactoring work" * tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (148 commits) Revert "arm64: initialize per-cpu offsets earlier" arm64: random: Remove no longer needed prototypes arm64: initialize per-cpu offsets earlier kselftest/arm64: Check mte tagged user address in kernel kselftest/arm64: Verify KSM page merge for MTE pages kselftest/arm64: Verify all different mmap MTE options kselftest/arm64: Check forked child mte memory accessibility kselftest/arm64: Verify mte tag inclusion via prctl kselftest/arm64: Add utilities and a test to validate mte memory perf: arm-cmn: Fix conversion specifiers for node type perf: arm-cmn: Fix unsigned comparison to less than zero arm64: dbm: Invalidate local TLB when setting TCR_EL1.HD arm64: mm: Make flush_tlb_fix_spurious_fault() a no-op arm64: Add support for PR_SPEC_DISABLE_NOEXEC prctl() option arm64: Pull in task_stack_page() to Spectre-v4 mitigation code KVM: arm64: Allow patching EL2 vectors even with KASLR is not enabled arm64: Get rid of arm64_ssbd_state KVM: arm64: Convert ARCH_WORKAROUND_2 to arm64_get_spectre_v4_state() KVM: arm64: Get rid of kvm_arm_have_ssbd() KVM: arm64: Simplify handling of ARCH_WORKAROUND_2 ...
2020-10-12Merge tag 'tpmdd-next-v5.10' of ↵Linus Torvalds6-21/+243
git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd Pull tpm updates from Jarkko Sakkinen: "Support for a new TPM device and fixes and Git URL change (infraded -> korg)" * tag 'tpmdd-next-v5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd: MAINTAINERS: TPM DEVICE DRIVER: Update GIT tpm_tis: Add a check for invalid status tpm: use %*ph to print small buffer dt-bindings: Add SynQucer TPM MMIO as a trivial device tpm: tis: add support for MMIO TPM on SynQuacer
2020-10-12Merge branch 'efi/urgent' into efi/core, to pick up fixesIngo Molnar7-33/+44
These fixes missed the v5.9 merge window, pick them up for early v5.10 merge. Signed-off-by: Ingo Molnar <[email protected]>
2020-10-12Merge branch 'edac-drivers' into edac-updates-for-v5.10Borislav Petkov3-0/+362
Signed-off-by: Borislav Petkov <[email protected]>
2020-10-11Merge tag 'irqchip-5.10' of ↵Thomas Gleixner22-432/+2023
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core Pull irqchip updates from Marc Zyngier: Core changes: - Allow irq retriggering to follow a hierarchy - Allow interrupt hierarchies to be trimmed at allocation time - Allow interrupts to be hidden from /proc/interrupts (IPIs) - Introduce stub for set_handle_irq() when !GENERIC_IRQ_MULTI_HANDLER - New per-cpu IPI handling flow Architecture changes: - Move arm/arm64 IPI handling to the core interrupt code, removing the home brewed accounting Driver updates: - New driver for the MStar (and more recently Mediatek) platforms - New driver for the Actions Owl SIRQ controller - New driver for the TI PRUSS infrastructure - Wake-up support for the Qualcomm PDC controller - Primary interrupt controller support for the Designware APB ICTL - Convert the IPI code for GIC, GICv3, hip04, armada-270-xp and bcm2836 to using standard interrupts - Improve GICv3 pseudo-NMI support to deal with both non-secure and secure priorities on arm64 - Convert the GIC/GICv3 drivers to using HW-based irq retrigger - A sprinkling of dev_err_probe() conversion - A set of NVIDIA Tegra fixes for interrupt hierarchy corruption - A reset fix for the Loongson HTVEC driver - A couple of error handling fixes in the TI SCI drivers
2020-10-10Merge branch 'i2c/for-current' of ↵Linus Torvalds2-19/+39
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: "Some more driver bugfixes for I2C. Including a revert - the updated series for it will come during the next merge window" * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: owl: Clear NACK and BUS error bits Revert "i2c: imx: Fix reset of I2SR_IAL flag" i2c: meson: fixup rate calculation with filter delay i2c: meson: keep peripheral clock enabled i2c: meson: fix clock setting overwrite i2c: imx: Fix reset of I2SR_IAL flag
2020-10-10Merge branch 'irq/mstar' into irq/irqchip-nextMarc Zyngier3-0/+208
Signed-off-by: Marc Zyngier <[email protected]>
2020-10-10irqchip/irq-mst: Add MStar interrupt controller supportMark-PK Tsai3-0/+208
Add MStar interrupt controller support using hierarchy irq domain. Signed-off-by: Mark-PK Tsai <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Tested-by: Daniel Palmer <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-10Merge branch 'irq/irqchip-fixes' into irq/irqchip-nextMarc Zyngier3-6/+6
Signed-off-by: Marc Zyngier <[email protected]>
2020-10-10Merge branch 'irq/tegra-pmc' into irq/irqchip-nextMarc Zyngier2-54/+52
Signed-off-by: Marc Zyngier <[email protected]>
2020-10-10i2c: owl: Clear NACK and BUS error bitsCristian Ciocaltea1-0/+6
When the NACK and BUS error bits are set by the hardware, the driver is responsible for clearing them by writing "1" into the corresponding status registers. Hence perform the necessary operations in owl_i2c_interrupt(). Fixes: d211e62af466 ("i2c: Add Actions Semiconductor Owl family S900 I2C driver") Reported-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Cristian Ciocaltea <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2020-10-10soc/tegra: pmc: Don't create fake interrupt hierarchy levelsMarc Zyngier1-48/+7
The Tegra PMC driver does ungodly things with the interrupt hierarchy, repeatedly corrupting it by pulling hwirq numbers out of thin air, overriding existing IRQ mappings and changing the handling flow of unsuspecting users. All of this is done in the name of preserving the interrupt hierarchy even when these levels do not exist in the HW. Together with the use of proper IRQs for IPIs, this leads to an unbootable system as the rescheduling IPI gets repeatedly repurposed for random drivers... Instead, let's simply mark the level from which the hierarchy does not make sense for the HW, and let the core code trim the usused levels from the hierarchy. Signed-off-by: Marc Zyngier <[email protected]>
2020-10-10soc/tegra: pmc: Allow optional irq parent callbacksMarc Zyngier1-4/+32
Make the PMC driver resistent to variable depth interrupt hierarchy, which we are about to introduce. Signed-off-by: Marc Zyngier <[email protected]>
2020-10-10gpio: tegra186: Allow optional irq parent callbacksMarc Zyngier1-2/+13
Make the tegra186 GPIO driver resistent to variable depth interrupt hierarchy, which we are about to introduce. No functionnal change yet. Signed-off-by: Marc Zyngier <[email protected]>
2020-10-10Revert "i2c: imx: Fix reset of I2SR_IAL flag"Wolfram Sang1-15/+5
This reverts commit fa4d30556883f2eaab425b88ba9904865a4d00f3. An updated version was sent. So, revert this version and give the new version more time for testing. Signed-off-by: Wolfram Sang <[email protected]>
2020-10-09Merge tag 'spi-fix-v5.9-rc8' of ↵Linus Torvalds1-2/+3
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fix from Mark Brown: "One last minute fix for v5.9 which has been causing crashes in test systems with the fsl-dspi driver when they hit deferred probe (and which I probably let cook in next a bit longer than is ideal). And an update to MAINTAINERS reflecting Serge's extensive and detailed recent work on the DesignWare driver" * tag 'spi-fix-v5.9-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: MAINTAINERS: Add maintainer of DW APB SSI driver spi: fsl-dspi: fix NULL pointer dereference
2020-10-09ata: ahci: mvebu: Make SATA PHY optional for Armada 3720Pali Rohár3-2/+4
Older ATF does not provide SMC call for SATA phy power on functionality and therefore initialization of ahci_mvebu is failing when older version of ATF is using. In this case phy_power_on() function returns -EOPNOTSUPP. This patch adds a new hflag AHCI_HFLAG_IGN_NOTSUPP_POWER_ON which cause that ahci_platform_enable_phys() would ignore -EOPNOTSUPP errors from phy_power_on() call. It fixes initialization of ahci_mvebu on Espressobin boards where is older Marvell's Arm Trusted Firmware without SMC call for SATA phy power. This is regression introduced in commit 8e18c8e58da64 ("arm64: dts: marvell: armada-3720-espressobin: declare SATA PHY property") where SATA phy was defined and therefore ahci_platform_enable_phys() on Espressobin started failing. Fixes: 8e18c8e58da64 ("arm64: dts: marvell: armada-3720-espressobin: declare SATA PHY property") Signed-off-by: Pali Rohár <[email protected]> Tested-by: Tomasz Maciej Nowak <[email protected]> Cc: <[email protected]> # 5.1+: ea17a0f153af: phy: marvell: comphy: Convert internal SMCC firmware return codes to errno Signed-off-by: Jens Axboe <[email protected]>
2020-10-09Merge tag 'for-v5.9-rc' of ↵Linus Torvalds1-0/+6
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply Pull power supply fix from Sebastian Reichel: "Just a single change to revert enablement of packet error checking for battery data on Chromebooks, since some of their embedded controllers do not handle it correctly" * tag 'for-v5.9-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: power: supply: sbs-battery: chromebook workaround for PEC
2020-10-09Merge tag 'gpio-v5.9-3' of ↵Linus Torvalds2-3/+16
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO fixes from Linus Walleij: "Some late fixes: one IRQ issue and one compilation issue for UML. - Fix a compilation issue with User Mode Linux - Handle spurious interrupts properly in the PCA953x driver" * tag 'gpio-v5.9-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: gpio: pca953x: Survive spurious interrupts gpiolib: Disable compat ->read() code in UML case
2020-10-09EDAC/amd64: Set proper family type for Family 19h Models 20h-2FhYazen Ghannam1-0/+6
AMD Family 19h Models 20h-2Fh use the same PCI IDs as Family 17h Models 70h-7Fh. The same family ops and number of channels also apply. Use the Family17h Model 70h family_type and ops for Family 19h Models 20h-2Fh. Update the controller name to match the system. Signed-off-by: Yazen Ghannam <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-10-09Merge tag 'mmc-v5.9-rc4-4' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc Pull MMC fix from Ulf Hansson: "Assign a proper discard granularity rather than incorrectly set it to zero" * tag 'mmc-v5.9-rc4-4' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: mmc: core: don't set limits.discard_granularity as 0
2020-10-09Merge tag 'drm-fixes-2020-10-09' of git://anongit.freedesktop.org/drm/drmLinus Torvalds6-15/+48
Pull amdgpu drm fixes from Dave Airlie: "Fixes trickling in this week. Alex had a final fix for the newest GPU they introduced in rc1, along with one build regression and one crasher fix. Cross my fingers that's it for 5.9: - Fix a crash on renoir if you override the IP discovery parameter - Fix the build on ARC platforms - Display fix for Sienna Cichlid" * tag 'drm-fixes-2020-10-09' of git://anongit.freedesktop.org/drm/drm: drm/amd/display: Change ABM config init interface drm/amdgpu/swsmu: fix ARC build errors drm/amdgpu: fix NULL pointer dereference for Renoir
2020-10-09Merge remote-tracking branch 'spi/for-5.10' into spi-nextMark Brown43-1148/+2680
2020-10-09Merge remote-tracking branch 'spi/for-5.9' into spi-linusMark Brown2-3/+7
2020-10-09spi: cadence: Add SPI transfer delaysDaniel Mack1-1/+1
When processing an SPI transfer, honor the delay that might be passed along with it. Signed-off-by: Daniel Mack <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-09mmc: sdhci_am654: Fix module autoloadFaiz Abbas1-0/+1
Add a MODULE_DEVICE_TABLE() entry so that the driver is autoloaded when built as a module. Signed-off-by: Faiz Abbas <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2020-10-09Merge branch 'fixes' into nextUlf Hansson1-1/+1
2020-10-09mmc: core: don't set limits.discard_granularity as 0Coly Li1-1/+1
In mmc_queue_setup_discard() the mmc driver queue's discard_granularity might be set as 0 (when card->pref_erase > max_discard) while the mmc device still declares to support discard operation. This is buggy and triggered the following kernel warning message, WARNING: CPU: 0 PID: 135 at __blkdev_issue_discard+0x200/0x294 CPU: 0 PID: 135 Comm: f2fs_discard-17 Not tainted 5.9.0-rc6 #1 Hardware name: Google Kevin (DT) pstate: 00000005 (nzcv daif -PAN -UAO BTYPE=--) pc : __blkdev_issue_discard+0x200/0x294 lr : __blkdev_issue_discard+0x54/0x294 sp : ffff800011dd3b10 x29: ffff800011dd3b10 x28: 0000000000000000 x27: ffff800011dd3cc4 x26: ffff800011dd3e18 x25: 000000000004e69b x24: 0000000000000c40 x23: ffff0000f1deaaf0 x22: ffff0000f2849200 x21: 00000000002734d8 x20: 0000000000000008 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000394 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 00000000000008b0 x9 : ffff800011dd3cb0 x8 : 000000000004e69b x7 : 0000000000000000 x6 : ffff0000f1926400 x5 : ffff0000f1940800 x4 : 0000000000000000 x3 : 0000000000000c40 x2 : 0000000000000008 x1 : 00000000002734d8 x0 : 0000000000000000 Call trace: __blkdev_issue_discard+0x200/0x294 __submit_discard_cmd+0x128/0x374 __issue_discard_cmd_orderly+0x188/0x244 __issue_discard_cmd+0x2e8/0x33c issue_discard_thread+0xe8/0x2f0 kthread+0x11c/0x120 ret_from_fork+0x10/0x1c ---[ end trace e4c8023d33dfe77a ]--- This patch fixes the issue by setting discard_granularity as SECTOR_SIZE instead of 0 when (card->pref_erase > max_discard) is true. Now no more complain from __blkdev_issue_discard() for the improper value of discard granularity. This issue is exposed after commit b35fd7422c2f ("block: check queue's limits.discard_granularity in __blkdev_issue_discard()"), a "Fixes:" tag is also added for the commit to make sure people won't miss this patch after applying the change of __blkdev_issue_discard(). Fixes: e056a1b5b67b ("mmc: queue: let host controllers specify maximum discard timeout") Fixes: b35fd7422c2f ("block: check queue's limits.discard_granularity in __blkdev_issue_discard()"). Reported-and-tested-by: Vicente Bergas <[email protected]> Signed-off-by: Coly Li <[email protected]> Acked-by: Adrian Hunter <[email protected]> Cc: Ulf Hansson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2020-10-08md/raid5: fix oops during stripe resizingSong Liu1-2/+2
KoWei reported crash during raid5 reshape: [ 1032.252932] Oops: 0002 [#1] SMP PTI [...] [ 1032.252943] RIP: 0010:memcpy_erms+0x6/0x10 [...] [ 1032.252947] RSP: 0018:ffffba1ac0c03b78 EFLAGS: 00010286 [ 1032.252949] RAX: 0000784ac0000000 RBX: ffff91bec3d09740 RCX: 0000000000001000 [ 1032.252951] RDX: 0000000000001000 RSI: ffff91be6781c000 RDI: 0000784ac0000000 [ 1032.252953] RBP: ffffba1ac0c03bd8 R08: 0000000000001000 R09: ffffba1ac0c03bf8 [ 1032.252954] R10: 0000000000000000 R11: 0000000000000000 R12: ffffba1ac0c03bf8 [ 1032.252955] R13: 0000000000001000 R14: 0000000000000000 R15: 0000000000000000 [ 1032.252958] FS: 0000000000000000(0000) GS:ffff91becf500000(0000) knlGS:0000000000000000 [ 1032.252959] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1032.252961] CR2: 0000784ac0000000 CR3: 000000031780a002 CR4: 00000000001606e0 [ 1032.252962] Call Trace: [ 1032.252969] ? async_memcpy+0x179/0x1000 [async_memcpy] [ 1032.252977] ? raid5_release_stripe+0x8e/0x110 [raid456] [ 1032.252982] handle_stripe_expansion+0x15a/0x1f0 [raid456] [ 1032.252988] handle_stripe+0x592/0x1270 [raid456] [ 1032.252993] handle_active_stripes.isra.0+0x3cb/0x5a0 [raid456] [ 1032.252999] raid5d+0x35c/0x550 [raid456] [ 1032.253002] ? schedule+0x42/0xb0 [ 1032.253006] ? schedule_timeout+0x10e/0x160 [ 1032.253011] md_thread+0x97/0x160 [ 1032.253015] ? wait_woken+0x80/0x80 [ 1032.253019] kthread+0x104/0x140 [ 1032.253022] ? md_start_sync+0x60/0x60 [ 1032.253024] ? kthread_park+0x90/0x90 [ 1032.253027] ret_from_fork+0x35/0x40 This is because cache_size_mutex was unlocked too early in resize_stripes, which races with grow_one_stripe() that grow_one_stripe() allocates a stripe with wrong pool_size. Fix this issue by unlocking cache_size_mutex after updating pool_size. Cc: <[email protected]> # v4.4+ Reported-by: KoWei Sung <[email protected]> Signed-off-by: Song Liu <[email protected]>
2020-10-08md/bitmap: fix memory leak of temporary bitmapZhao Heming2-1/+3
Callers of get_bitmap_from_slot() are responsible to free the bitmap. Suggested-by: Guoqing Jiang <[email protected]> Signed-off-by: Zhao Heming <[email protected]> Signed-off-by: Song Liu <[email protected]>
2020-10-08md: fix the checking of wrong work queueGuoqing Jiang1-1/+1
It should check md_rdev_misc_wq instead of md_misc_wq. Fixes: cc1ffe61c026 ("md: add new workqueue for delete rdev") Cc: <[email protected]> # v5.8+ Signed-off-by: Guoqing Jiang <[email protected]> Signed-off-by: Song Liu <[email protected]>
2020-10-08md/bitmap: md_bitmap_get_counter returns wrong blocksZhao Heming1-1/+1
md_bitmap_get_counter() has code: ``` if (bitmap->bp[page].hijacked || bitmap->bp[page].map == NULL) csize = ((sector_t)1) << (bitmap->chunkshift + PAGE_COUNTER_SHIFT - 1); ``` The minus 1 is wrong, this branch should report 2048 bits of space. With "-1" action, this only report 1024 bit of space. This bug code returns wrong blocks, but it doesn't inflence bitmap logic: 1. Most callers focus this function return value (the counter of offset), not the parameter blocks. 2. The bug is only triggered when hijacked is true or map is NULL. the hijacked true condition is very rare. the "map == null" only true when array is creating or resizing. 3. Even the caller gets wrong blocks, current code makes caller just to call md_bitmap_get_counter() one more time. Signed-off-by: Zhao Heming <[email protected]> Signed-off-by: Song Liu <[email protected]>
2020-10-08md/bitmap: md_bitmap_read_sb uses wrong bitmap blocksZhao Heming1-2/+2
The patched code is used to get chunks number, should use round-up div to replace current sector_div. The same code is in md_bitmap_resize(): ``` chunks = DIV_ROUND_UP_SECTOR_T(blocks, 1 << chunkshift); ``` Signed-off-by: Zhao Heming <[email protected]> Signed-off-by: Song Liu <[email protected]>
2020-10-08md/raid0: remove unused function is_io_in_chunk_boundary()Jason Yan1-17/+0
This function is no longger needed after commit 20d0189b1012 ("block: Introduce new bio_split()"). Signed-off-by: Jason Yan <[email protected]> Signed-off-by: Song Liu <[email protected]>
2020-10-08Merge tag 'block5.9-2020-10-08' of git://git.kernel.dk/linux-blockLinus Torvalds1-1/+3
Pull block fixes from Jens Axboe: "A few fixes that should go into this release: - NVMe controller error path reference fix (Chaitanya) - Fix regression with IBM partitions on non-dasd devices (Christoph) - Fix a missing clear in the compat CDROM packet structure (Peilin)" * tag 'block5.9-2020-10-08' of git://git.kernel.dk/linux-block: partitions/ibm: fix non-DASD devices nvme-core: put ctrl ref when module ref get fail block/scsi-ioctl: Fix kernel-infoleak in scsi_put_cdrom_generic_arg()
2020-10-09power: supply: sbs-battery: chromebook workaround for PECSebastian Reichel1-0/+6
Looks like the I2C tunnel implementation from Chromebook's embedded controller does not handle PEC correctly. Fix this by disabling PEC for batteries behind those I2C tunnels as a workaround. Note, that some Chromebooks actually have been reported to have working PEC support (with I2C tunnel). Since the problem has not yet been fully understood this simply reverts all Chromebooks to not use PEC for now. Reported-by: "Milan P. Stanić" <[email protected]> Reported-by: Vicente Bergas <[email protected]> CC: Enric Balletbo i Serra <[email protected]> Fixes: 7222bd603dd2 ("power: supply: sbs-battery: add PEC support") Tested-by: Vicente Bergas <[email protected]> Tested-by: "Milan P. Stanić" <[email protected]> Signed-off-by: Sebastian Reichel <[email protected]>
2020-10-08spi: dw: Add Baikal-T1 SPI Controller glue driverSerge Semin3-0/+368
Baikal-T1 is equipped with three DW APB SSI-based MMIO SPI controllers. Two of them are pretty much normal: with IRQ, DMA, FIFOs of 64 words depth, 4x CSs, but the third one as being a part of the Baikal-T1 System Boot Controller has got a very limited resources: no IRQ, no DMA, only a single native chip-select and Tx/Rx FIFO with just 8 words depth available. In order to provide a transparent initial boot code execution the Boot SPI controller is also utilized by an vendor-specific IP-block, which exposes an SPI flash direct mapping interface. Since both direct mapping and SPI controller normal utilization are mutual exclusive only one of these interfaces can be used to access an external SPI slave device. That's why a dedicated mux is embedded into the System Boot Controller. All of that is taken into account in the Baikal-T1-specific DW APB SSI glue driver implemented by means of the DW SPI core module. Co-developed-by: Ramil Zaripov <[email protected]> Signed-off-by: Ramil Zaripov <[email protected]> Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Add poll-based SPI transfers supportSerge Semin1-1/+39
A functionality of the poll-based transfer has been removed by commit 1ceb09717e98 ("spi: dw: remove cs_control and poll_mode members from chip_data") with a justification that "there is no user of one anymore". It turns out one of our DW APB SSI core is synthesized with no IRQ line attached and the only possible way of using it is to implement a poll-based SPI transfer procedure. So we have to get the removed functionality back, but with some alterations described below. First of all the poll-based transfer is activated only if the DW SPI controller doesn't have an IRQ line attached and the Linux IRQ number is initialized with the IRQ_NOTCONNECTED value. Secondly the transfer procedure is now executed with a delay performed between writer and reader methods. The delay value is calculated based on the number of data words expected to be received on the current iteration. Finally the errors status is checked on each iteration. Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Introduce max mem-ops SPI bus frequency settingSerge Semin2-1/+4
In some circumstances the current implementation of the SPI memory operations may occasionally fail even though they are executed in the atomic context. This may happen if the system bus is relatively slow in comparison to the SPI bus frequency, or there is a concurrent access to it, which makes the MMIO-operations occasionally stalling before push-pulling data from the DW APB SPI FIFOs. These two problems we've discovered on the Baikal-T1 SoC. In order to fix them we have no choice but to set an artificial limitation on the SPI bus speed. Note currently this limitation will be only applicable for the memory operations, since the standard SPI core interface is implemented with an assumption that there is no problem with the automatic CS toggling. Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Add memory operations supportSerge Semin3-0/+315
Aside from the synchronous Tx-Rx mode, which has been utilized to create the normal SPI transfers in the framework of the DW SSI driver, DW SPI controller supports Tx-only and EEPROM-read modes. The former one just enables the controller to transmit all the data from the Tx FIFO ignoring anything retrieved from the MISO lane. The later mode is so called write-then-read operation: DW SPI controller first pushes out all the data from the Tx FIFO, after that it'll automatically receive as much data as has been specified by means of the CTRLR1 register. Both of those modes can be used to implement the memory operations supported by the SPI-memory subsystem. The memory operation implementation is pretty much straightforward, except a few peculiarities we have had to take into account to make things working. Since DW SPI controller doesn't provide a way to directly set and clear the native CS lane level, but instead automatically de-asserts it when a transfer going on, we have to make sure the Tx FIFO isn't empty during entire Tx procedure. In addition we also need to read data from the Rx FIFO as fast as possible to prevent it' overflow with automatically fetched incoming traffic. The denoted peculiarities get to cause even more problems if DW SSI controller is equipped with relatively small FIFO and is connected to a relatively slow system bus (APB) (with respect to the SPI bus speed). In order to workaround the problems for as much as it's possible, the memory operation execution procedure collects all the Tx data into a single buffer and disables the local IRQs to speed the write-then-optionally-read method up. Note the provided memory operations are utilized by default only if a glue driver hasn't provided a custom version of ones and this is not a DW APB SSI controller with fixed automatic CS toggle functionality. Co-developed-by: Ramil Zaripov <[email protected]> Signed-off-by: Ramil Zaripov <[email protected]> Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Add generic DW SSI status-check methodSerge Semin3-18/+37
The DW SSI errors handling method can be generically implemented for all types of the transfers: IRQ, DMA and poll-based ones. It will be a function which checks the overflow/underflow error flags and resets the controller if any of them is set. In the framework of this commit we make use of the new method to detect the errors in the IRQ- and DMA-based SPI transfer execution procedures. Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Move num-of retries parameter to the header fileSerge Semin2-3/+4
The parameter will be needed for another wait-done method being added in the framework of the SPI memory operation modification in a further commit. Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Explicitly de-assert CS on SPI transfer completionSerge Semin1-1/+1
By design of the currently available native set_cs callback, the CS de-assertion will be done only if it's required by the corresponding controller capability. But in order to pre-fill the Tx FIFO buffer with data during the SPI memory ops execution the SER register needs to be left cleared before that. We'll also need a way to explicitly set and clear the corresponding CS bit at a certain moment of the operation. Let's alter the set_cs function then to also de-activate the CS, when it's required. Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: De-assert chip-select on resetSerge Semin1-3/+4
SPI memory operations implementation will require to have the CS register cleared before executing the operation in order not to have the transmission automatically started prior the Tx FIFO is pre-initialized. Let's clear the register then on explicit controller reset to fulfil the requirements in case of an error or having the CS left set by a bootloader or another software. Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Discard chip enabling on DMA setup errorSerge Semin1-3/+1
It's pointless to enable the chip back if the DMA setup procedure fails, since we'll disable it on the next transfer anyway. For the same reason We don't do that in case of a failure detected in any other methods called from the transfer_one() method. While at it consider any non-zero value returned from the dma_setup callback to be erroneous as it's supposed to be in the kernel. Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Unmask IRQs after enabling the chipSerge Semin1-2/+2
It's theoretically erroneous to enable IRQ before the chip is turned on. If IRQ handler gets executed before the chip is enabled, then any data written to the Tx FIFO will be just ignored. I say "theoretically" because we haven't noticed any problem with that, but let's fix it anyway just in case... Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Perform IRQ setup in a dedicated functionSerge Semin1-18/+23
In order to make the transfer_one() callback method more readable and for unification with the DMA-based transfer, let's detach the IRQ setup procedure into a dedicated function. While at it rename the IRQ-based transfer handler function to be dw_spi-prefixe and looking more like the DMA-related one. Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Refactor IRQ-based SPI transfer procedureSerge Semin1-9/+24
Current IRQ-based SPI transfer execution procedure doesn't work well at the final stage of the execution. If all the Tx data is sent out (written to the Tx FIFO) but there is some data left to receive, the Tx FIFO Empty IRQ will constantly happen until all of the requested inbound data is received. Though for a short period of time, but it will make the system less responsive. In order to fix that let's refactor the SPI transfer execution procedure by taking the Rx FIFO Full IRQ into account. We'll read and write SPI transfer data each time the IRQ happens as before. If all the outbound data is sent out, we'll disable the Tx FIFO Empty IRQ. If there is still some data to receive, we'll adjust the Rx FIFO Threshold level, so the next IRQ would be raised at the moment of all incoming data being available in the Rx FIFO. Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-10-08spi: dw: Refactor data IO procedureSerge Semin2-23/+19
The Tx and Rx data write/read procedure can be significantly simplified by using Tx/Rx transfer lengths instead of the end pointers. By having the Tx/Rx data leftover lengths (in the number of transfer words) we can get rid of all subtraction and division operations utilized here and there in the tx_max(), rx_max(), dw_writer() and dw_reader() methods. Such modification will not only give us the more optimized IO procedures, but will make the data IO methods much more readable than before. Signed-off-by: Serge Semin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.