summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-12-22hwmon: (k10temp) Remove support for displaying voltage and current on Zen CPUsGuenter Roeck
Voltages and current are reported by Zen CPUs. However, the means to do so is undocumented, changes from CPU to CPU, and the raw data is not calibrated. Calibration information is available, but again not documented. This results in less than perfect user experience, up to concerns that loading the driver might possibly damage the hardware (by reporting out-of range voltages). Effectively support for reporting voltages and current is not maintainable. Drop it. Cc: Artem S. Tashkinov <aros@gmx.com> Cc: Wei Huang <wei.huang2@amd.com> Tested-by: Wei Huang <wei.huang2@amd.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-12-22block: update some copyrightsChristoph Hellwig
Update copyrights for files that have gotten some major rewrites lately. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-12-22block: remove a pointless self-reference in block_dev.cChristoph Hellwig
There is no point in duplicating the file name in the top of the file comment. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-12-22MAINTAINERS: add fs/block_dev.c to the block sectionChristoph Hellwig
fs/block_dev.c is a pretty integral part of the block layer, so make sure it is mentioned in MAINTAINERS. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-12-22ALSA/hda: apply jack fixup for the Acer Veriton N4640G/N6640G/N2510GChris Chiu
This Acer Veriton N4640G/N6640G/N2510G desktops have 2 headphone jacks(front and rear), and a separate Mic In jack. The rear headphone jack is actually a line out jack but always silent while playing audio. The front 'Mic In' also fails the jack sensing. Apply the ALC269_FIXUP_LIFEBOOK to have all audio jacks to work as expected. Signed-off-by: Chris Chiu <chiu@endlessos.org> Signed-off-by: Jian-Hong Pan <jhp@endlessos.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201222150459.9545-2-chiu@endlessos.org Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-12-22ALSA: hda/realtek: Apply jack fixup for Quanta NL3Chris Chiu
The Quanta NL3 laptop has both a headphone output jack and a headset jack, on the right edge of the chassis. The pin information suggests that both of these are at the Front. The PulseAudio is confused to differentiate them so one of the jack can neither get the jack sense working nor the audio output. The ALC269_FIXUP_LIFEBOOK chained with ALC269_FIXUP_QUANTA_MUTE can help to differentiate 2 jacks and get the 'Auto-Mute Mode' working correctly. Signed-off-by: Chris Chiu <chiu@endlessos.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201222150459.9545-1-chiu@endlessos.org Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-12-22dm cache: simplify the return expression of load_mapping()Zheng Yongjun
Simplify the return expression. Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2020-12-22Merge branches 'acpi-scan', 'acpi-pnp' and 'acpi-sleep'Rafael J. Wysocki
* acpi-scan: ACPI: scan: Add Intel Baytrail Mailbox Device to acpi_ignore_dep_ids ACPI: scan: Avoid unnecessary second pass in acpi_bus_scan() ACPI: scan: Defer enumeration of devices with _DEP lists ACPI: scan: Evaluate _DEP before adding the device * acpi-pnp: ACPI: PNP: compare the string length in the matching_id() * acpi-sleep: ACPI: PM: s2idle: Move x86-specific code to the x86 directory ACPI: PM: s2idle: Add AMD support to handle _DSM
2020-12-22ALSA: usb-audio: Add implicit feeback support for the BOSS GT-1Mike Oliphant
The BOSS GT-1 (USB ID 0582:01d6) requires implicit feedback like other similar BOSS devices. This patch adds this support. [ rearranged the table entry in the ID order -- tiwai ] Signed-off-by: Mike Oliphant <oliphant@nostatic.org> Link: https://lore.kernel.org/r/20201221215533.2511-1-oliphant@nostatic.org Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-12-21RISC-V: Fix usage of memblock_enforce_memory_limitAtish Patra
memblock_enforce_memory_limit accepts the maximum memory size not the maximum address that can be handled by kernel. Fix the function invocation accordingly. Fixes: 1bd14a66ee52 ("RISC-V: Remove any memblock representing unusable memory area") Cc: stable@vger.kernel.org Reported-by: Bin Meng <bin.meng@windriver.com> Tested-by: Bin Meng <bin.meng@windriver.com> Acked-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Atish Patra <atish.patra@wdc.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-12-22exfat: Avoid allocating upcase table using kcalloc()Artem Labazov
The table for Unicode upcase conversion requires an order-5 allocation, which may fail on a highly-fragmented system: pool-udisksd: page allocation failure: order:5, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null), cpuset=/,mems_allowed=0 CPU: 4 PID: 3756880 Comm: pool-udisksd Tainted: G U 5.8.10-200.fc32.x86_64 #1 Hardware name: Dell Inc. XPS 13 9360/0PVG6D, BIOS 2.13.0 11/14/2019 Call Trace: dump_stack+0x6b/0x88 warn_alloc.cold+0x75/0xd9 ? _cond_resched+0x16/0x40 ? __alloc_pages_direct_compact+0x144/0x150 __alloc_pages_slowpath.constprop.0+0xcfa/0xd30 ? __schedule+0x28a/0x840 ? __wait_on_bit_lock+0x92/0xa0 __alloc_pages_nodemask+0x2df/0x320 kmalloc_order+0x1b/0x80 kmalloc_order_trace+0x1d/0xa0 exfat_create_upcase_table+0x115/0x390 [exfat] exfat_fill_super+0x3ef/0x7f0 [exfat] ? sget_fc+0x1d0/0x240 ? exfat_init_fs_context+0x120/0x120 [exfat] get_tree_bdev+0x15c/0x250 vfs_get_tree+0x25/0xb0 do_mount+0x7c3/0xaf0 ? copy_mount_options+0xab/0x180 __x64_sys_mount+0x8e/0xd0 do_syscall_64+0x4d/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Make the driver use kvcalloc() to eliminate the issue. Fixes: 370e812b3ec1 ("exfat: add nls operations") Cc: stable@vger.kernel.org #v5.7+ Signed-off-by: Artem Labazov <123321artyom@gmail.com> Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
2020-12-21fix hostfs_open() use of ->f_path.dentryAl Viro
this is one of the cases where we need to use d_real() - we are using more than the name of dentry here. ->d_sb is used as well, so in case of hostfs being used as a layer we get the wrong superblock. Reported-by: Johannes Berg <johannes@sipsolutions.net> Tested-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2020-12-21net: mvpp2: Fix GoP port 3 Networking Complex Control configurationsStefan Chulski
During GoP port 2 Networking Complex Control mode of operation configurations, also GoP port 3 mode of operation was wrongly set. Patch removes these configurations. Fixes: f84bf386f395 ("net: mvpp2: initialize the GoP") Acked-by: Marcin Wojtas <mw@semihalf.com> Signed-off-by: Stefan Chulski <stefanc@marvell.com> Link: https://lore.kernel.org/r/1608462149-1702-1-git-send-email-stefanc@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-12-21ppp: Fix PPPIOCUNBRIDGECHAN request numberGuillaume Nault
PPPIOCGL2TPSTATS already uses 54. This shouldn't be a problem in practice, but let's keep the logical decreasing assignment scheme. Fixes: 4cf476ced45d ("ppp: add PPPIOCBRIDGECHAN and PPPIOCUNBRIDGECHAN ioctls") Signed-off-by: Guillaume Nault <gnault@redhat.com> Link: https://lore.kernel.org/r/e3a4c355e3820331d8e1fffef8522739aae58b57.1608380117.git.gnault@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-12-21atm: idt77252: call pci_disable_device() on error pathDan Carpenter
This error path needs to disable the pci device before returning. Fixes: ede58ef28e10 ("atm: remove deprecated use of pci api") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/X93dmC4NX0vbTpGp@mwanda Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-12-21ionic: account for vlan tag len in rx buffer lenShannon Nelson
Let the FW know we have enough receive buffer space for the vlan tag if it isn't stripped. Fixes: 0f3154e6bcb3 ("ionic: Add Tx and Rx handling") Signed-off-by: Shannon Nelson <snelson@pensando.io> Link: https://lore.kernel.org/r/20201218215001.64696-1-snelson@pensando.io Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-12-21Merge branch 'ucc_geth-fixes'Jakub Kicinski
Rasmus Villemoes says: ==================== ucc_geth fixes This is three bug fixes that fell out of a series of cleanups of the ucc_geth driver. ==================== Link: https://lore.kernel.org/r/20201218105538.30563-1-rasmus.villemoes@prevas.dk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-12-21ethernet: ucc_geth: fix use-after-free in ucc_geth_remove()Rasmus Villemoes
ugeth is the netdiv_priv() part of the netdevice. Accessing the memory pointed to by ugeth (such as done by ucc_geth_memclean() and the two of_node_puts) after free_netdev() is thus use-after-free. Fixes: 80a9fad8e89a ("ucc_geth: fix module removal") Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-12-21ethernet: ucc_geth: fix definition and size of ucc_geth_tx_global_pramRasmus Villemoes
Table 8-53 in the QUICC Engine Reference manual shows definitions of fields up to a size of 192 bytes, not just 128. But in table 8-111, one does find the text Base Address of the Global Transmitter Parameter RAM Page. [...] The user needs to allocate 128 bytes for this page. The address must be aligned to the page size. I've checked both rev. 7 (11/2015) and rev. 9 (05/2018) of the manual; they both have this inconsistency (and the table numbers are the same). Adding a bit of debug printing, on my board the struct ucc_geth_tx_global_pram is allocated at offset 0x880, while the (opaque) ucc_geth_thread_data_tx gets allocated immediately afterwards, at 0x900. So whatever the engine writes into the thread data overlaps with the tail of the global tx pram (and devmem says that something does get written during a simple ping). I haven't observed any failure that could be attributed to this, but it seems to be the kind of thing that would be extremely hard to debug. So extend the struct definition so that we do allocate 192 bytes. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-12-21ethernet: ucc_geth: set dev->max_mtu to 1518Rasmus Villemoes
All the buffers and registers are already set up appropriately for an MTU slightly above 1500, so we just need to expose this to the networking stack. AFAICT, there's no need to implement .ndo_change_mtu when the receive buffers are always set up to support the max_mtu. This fixes several warnings during boot on our mpc8309-board with an embedded mv88e6250 switch: mv88e6085 mdio@e0102120:10: nonfatal error -34 setting MTU 1500 on port 0 ... mv88e6085 mdio@e0102120:10: nonfatal error -34 setting MTU 1500 on port 4 ucc_geth e0102000.ethernet eth1: error -22 setting MTU to 1504 to include DSA overhead The last line explains what the DSA stack tries to do: achieving an MTU of 1500 on-the-wire requires that the master netdevice connected to the CPU port supports an MTU of 1500+the tagging overhead. Fixes: bfcb813203e6 ("net: dsa: configure the MTU for switch ports") Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-12-21net: systemport: set dev->max_mtu to UMAC_MAX_MTU_SIZEFlorian Fainelli
The driver is already allocating receive buffers of 2KiB and the Ethernet MAC is configured to accept frames up to UMAC_MAX_MTU_SIZE. Fixes: bfcb813203e6 ("net: dsa: configure the MTU for switch ports") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20201218173843.141046-1-f.fainelli@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-12-22bpf: Add schedule point in htab_init_buckets()Eric Dumazet
We noticed that with a LOCKDEP enabled kernel, allocating a hash table with 65536 buckets would use more than 60ms. htab_init_buckets() runs from process context, it is safe to schedule to avoid latency spikes. Fixes: c50eb518e262 ("bpf: Use separate lockdep class for each hashtab") Reported-by: John Sperbeck <jsperbeck@google.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Song Liu <songliubraving@fb.com> Link: https://lore.kernel.org/bpf/20201221192506.707584-1-eric.dumazet@gmail.com
2020-12-21io_uring: fix ignoring xa_store errorsPavel Begunkov
xa_store() may fail, check the result. Cc: stable@vger.kernel.org # 5.10 Fixes: 0f2122045b946 ("io_uring: don't rely on weak ->files references") Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-12-21dm ebs: avoid double unlikely() notation when using IS_ERR()Antonio Quartulli
The definition of IS_ERR() already applies the unlikely() notation when checking the error status of the passed pointer. For this reason there is no need to have the same notation outside of IS_ERR() itself. Clean up code by removing redundant notation. Signed-off-by: Antonio Quartulli <a@unstable.cc> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2020-12-21dm verity: skip verity work if I/O error when system is shutting downHyeongseok Kim
If emergency system shutdown is called, like by thermal shutdown, a dm device could be alive when the block device couldn't process I/O requests anymore. In this state, the handling of I/O errors by new dm I/O requests or by those already in-flight can lead to a verity corruption state, which is a misjudgment. So, skip verity work in response to I/O error when system is shutting down. Signed-off-by: Hyeongseok Kim <hyeongseok@gmail.com> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2020-12-21Merge tag 'clk-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux Pull clk updates from Stephen Boyd: "The core framework got some nice improvements this time around. We gained the ability to get struct clk pointers from a struct clk_hw so that clk providers can consume the clks they provide, if they need to do something like that. This has been a long missing part of the clk provider API that will help us move away from exposing a struct clk pointer in the struct clk_hw. Tracepoints are added for the clk_set_rate() "range" functions, similar to the tracepoints we already have for clk_set_rate() and we added a column to debugfs to help developers understand the hardware enable state of clks in case firmware or bootloader state is different than what is expected. Overall the core changes are mostly improving the clk driver writing experience. At the driver level, we have the usual collection of driver updates and new drivers for new SoCs. This time around the Qualcomm folks introduced a good handful of clk drivers for various parts of three or four SoCs. The SiFive folks added a new clk driver for their FU740 SoCs, coming in second on the diffstat and then Atmel AT91 and Amlogic SoCs had lots of work done after that for various new features. One last thing to note in the driver area is that the i.MX driver has gained a new binding to support SCU clks after being on the list for many months. It uses a two cell binding which is sort of rare in clk DT bindings. Beyond that we have the usual set of driver fixes and tweaks that come from more testing and finding out that some configuration was wrong or that a driver could support being built as a module. Summary: Core: - Add some trace points for clk_set_rate() "range" functions - Add hardware enable information to clk_summary debugfs - Replace clk-provider.h with of_clk.h when possible - Add devm variant of clk_notifier_register() - Add clk_hw_get_clk() to generate a struct clk from a struct clk_hw New Drivers: - Bindings for Canaan K210 SoC clks - Support for SiFive FU740 PRCI - Camera clks on Qualcomm SC7180 SoCs - GCC and RPMh clks on Qualcomm SDX55 SoCs - RPMh clks on Qualcomm SM8350 SoCs - LPASS clks on Qualcomm SM8250 SoCs Updates: - DVFS support for AT91 clk driver - Update git repo branch for Renesas clock drivers - Add camera (CSI) and video-in (VIN) clocks on Renesas R-Car V3U - Add RPC (QSPI/HyperFLASH) clocks on Renesas RZ/G2M, RZ/G2N, and RZ/G2E - Stop using __raw_*() I/O accessors in Renesas clk drivers - One more conversion of DT bindings to json-schema - Make i.MX clk-gate2 driver more flexible - New two cell binding for i.MX SCU clks - Drop of_match_ptr() in i.MX8 clk drivers - Add arch dependencies for Rockchip clk drivers - Fix i2s on Rockchip rk3066 - Add MIPI DSI clks on Amlogic axg and g12 SoCs - Support modular builds of Amlogic clk drivers - Fix an Amlogic Video PLL clock dependency - Samsung Kconfig dependencies updates for better compile test coverage - Refactoring of the Samsung PLL clocks driver - Small Tegra driver cleanups - Minor fixes to Ingenic and VC5 clk drivers - Cleanup patches to remove unused variables and plug memory leaks" * tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: (134 commits) dt-binding: clock: Document canaan,k210-clk bindings dt-bindings: Add Canaan vendor prefix clk: vc5: Use "idt,voltage-microvolt" instead of "idt,voltage-microvolts" clk: ingenic: Fix divider calculation with div tables clk: sunxi-ng: Make sure divider tables have sentinel clk: s2mps11: Fix a resource leak in error handling paths in the probe function clk: mvebu: a3700: fix the XTAL MODE pin to MPP1_9 clk: si5351: Wait for bit clear after PLL reset clk: at91: sam9x60: remove atmel,osc-bypass support clk: at91: sama7g5: register cpu clock clk: at91: clk-master: re-factor master clock clk: at91: sama7g5: do not allow cpu pll to go higher than 1GHz clk: at91: sama7g5: decrease lower limit for MCK0 rate clk: at91: sama7g5: remove mck0 from parent list of other clocks clk: at91: clk-sam9x60-pll: allow runtime changes for pll clk: at91: sama7g5: add 5th divisor for mck0 layout and characteristics clk: at91: clk-master: add 5th divisor for mck master clk: at91: sama7g5: allow SYS and CPU PLLs to be exported and referenced in DT dt-bindings: clock: at91: add sama7g5 pll defines clk: at91: sama7g5: fix compilation error ...
2020-12-21Merge tag 'm68knommu-for-v5.11' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu Pull m68knommu updates from Greg Ungerer: - cleanup of 68328 code - align BSS section to 32bit * tag 'm68knommu-for-v5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu: m68k: m68328: remove duplicate code m68k: m68328: move platform code to separate files m68knommu: align BSS section to 4-byte boundaries
2020-12-21Merge tag '9p-for-5.11-rc1' of git://github.com/martinetd/linuxLinus Torvalds
Pull 9p update from Dominique Martinet: - fix long-standing limitation on open-unlink-fop pattern - add refcount to p9_fid (fixes the above and will allow for more cleanups and simplifications in the future) * tag '9p-for-5.11-rc1' of git://github.com/martinetd/linux: 9p: Remove unnecessary IS_ERR() check 9p: Uninitialized variable in v9fs_writeback_fid() 9p: Fix writeback fid incorrectly being attached to dentry 9p: apply review requests for fid refcounting 9p: add refcount to p9_fid struct fs/9p: search open fids first fs/9p: track open fids fs/9p: fix create-unlink-getattr idiom
2020-12-21MAINTAINERS: switch to different email addressArend van Spriel
Switching to private mail account as work email is polluted with a legal disclaimer. Just making it extra clear by changing the email address in the MAINTAINERS file as well. Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Arend van Spriel <aspriel@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201220141807.17278-1-aspriel@gmail.com
2020-12-21docs: admin-guide: Fix default value of max_map_count in sysctl/vm.rstFengfei Xi
Since the default value of sysctl_max_map_count is defined as DEFAULT_MAX_MAP_COUNT from mm/util.c int sysctl_max_map_count __read_mostly = DEFAULT_MAX_MAP_COUNT; DEFAULT_MAX_MAP_COUNT is defined as 65530 (65535-5) in include/linux/mm.h #define MAPCOUNT_ELF_CORE_MARGIN (5) #define DEFAULT_MAX_MAP_COUNT (USHRT_MAX - MAPCOUNT_ELF_CORE_MARGIN) Signed-off-by: Fengfei Xi <xi.fengfei@h3c.com> Link: https://lore.kernel.org/r/20201210082134.36957-1-xi.fengfei@h3c.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2020-12-21Documentation/submitting-patches: Document the SoB chainBorislav Petkov
Document what a chain of Signed-off-by's in a patch commit message should mean, explicitly. This has been carved out from a tip subsystem handbook patchset by Thomas Gleixner: https://lkml.kernel.org/r/20181107171010.421878737@linutronix.de and incorporates follow-on comments. Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lore.kernel.org/r/20201217183756.GE23634@zn.tnic Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2020-12-21Documentation: process: Correct numberingMilan Lakhani
Renumber the steps in submit-checklist.rst as some numbers were skipped. Signed-off-by: Milan Lakhani <milan.lakhani@codethink.co.uk> Link: https://lore.kernel.org/r/1608064956-5512-1-git-send-email-milan.lakhani@codethink.co.uk Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2020-12-21docs: submitting-patches: Trivial - fix grammatical errorLee Jones
"it is a used" does not make sense. Should be "it is used". Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20201216134654.271508-1-lee.jones@linaro.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2020-12-21powerpc/32: Fix vmap stack - Properly set r1 before activating MMU on ↵Christophe Leroy
syscall too We need r1 to be properly set before activating MMU, otherwise any new exception taken while saving registers into the stack in syscall prologs will use the user stack, which is wrong and will even lockup or crash when KUAP is selected. Do that by switching the meaning of r11 and r1 until we have saved r1 to the stack: copy r1 into r11 and setup the new stack pointer in r1. To avoid complicating and impacting all generic and specific prolog code (and more), copy back r1 into r11 once r11 is save onto the stack. We could get rid of copying r1 back and forth at the cost of rewriting everything to use r1 instead of r11 all the way when CONFIG_VMAP_STACK is set, but the effort is probably not worth it for now. Fixes: da7bb43ab9da ("powerpc/32: Fix vmap stack - Properly set r1 before activating MMU") Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/a3d819d5c348cee9783a311d5d3f3ba9b48fd219.1608531452.git.christophe.leroy@csgroup.eu
2020-12-21Merge branch 'devel-stable' into for-nextRussell King
2020-12-21Merge branches 'fixes' and 'misc' into for-nextRussell King
2020-12-21ARM: 9027/1: head.S: explicitly map DT even if it lives in the first ↵Ard Biesheuvel
physical section The early ATAGS/DT mapping code uses SECTION_SHIFT to mask low order bits of R2, and decides that no ATAGS/DTB were provided if the resulting value is 0x0. This means that on systems where DRAM starts at 0x0 (such as Raspberry Pi), no explicit mapping of the DT will be created if R2 points into the first 1 MB section of memory. This was not a problem before, because the decompressed kernel is loaded at the base of DRAM and mapped using sections as well, and so as long as the DT is referenced via a virtual address that uses the same translation (the linear map, in this case), things work fine. However, commit 7a1be318f579 ("9012/1: move device tree mapping out of linear region") changes this, and now the DT is referenced via a virtual address that is disjoint from the linear mapping of DRAM, and so we need the early code to create the DT mapping unconditionally. So let's create the early DT mapping for any value of R2 != 0x0. Reported-by: "kernelci.org bot" <bot@kernelci.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-12-21ARM: 9038/1: Link with '-z norelro'Nathan Chancellor
When linking a multi_v7_defconfig + CONFIG_KASAN=y kernel with LD=ld.lld, the following error occurs: $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 zImage ld.lld: error: section: .exit.data is not contiguous with other relro sections LLD defaults to '-z relro', which is unneeded for the kernel because program headers are not used nor is there any position independent code generation or linking for ARM. Add '-z norelro' to LDFLAGS_vmlinux to avoid this error. Link: https://github.com/ClangBuiltLinux/linux/issues/1189 Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-12-21ARM: 9037/1: uncompress: Add OF_DT_MAGIC macroGeert Uytterhoeven
The DTB magic marker is stored as a 32-bit big-endian value, and thus depends on the CPU's endianness. Add a macro to define this value in native endianness, to reduce #ifdef clutter and (future) duplication. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-12-21ARM: 9036/1: uncompress: Fix dbgadtb size parameter nameGeert Uytterhoeven
The dbgadtb macro is passed the size of the appended DTB, not the end address. Fixes: c03e41470e901123 ("ARM: 9010/1: uncompress: Print the location of appended DTB") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-12-21ARM: 9035/1: uncompress: Add be32tocpu macroGeert Uytterhoeven
DTB stores all values as 32-bit big-endian integers. Add a macro to convert such values to native CPU endianness, to reduce duplication. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-12-21ARM: 9033/1: arm/smp: Drop the macro S(x,s)Anshuman Khandual
Mapping between IPI type index and its string is direct without requiring an additional offset. Hence the existing macro S(x, s) is now redundant and can just be dropped. This also makes the code clean and simple. Cc: Marc Zyngier <maz@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-12-21ARM: 9032/1: arm/mm: Convert PUD level pgtable helper macros into functionsAnshuman Khandual
Macros used as functions can be problematic from the compiler perspective. There was a build failure report caused primarily because of non reference of an argument variable. Hence convert PUD level pgtable helper macros into functions in order to avoid such problems in the future. In the process, it fixes the argument variables sequence in set_pud() which probably remained hidden for being a macro. https://lore.kernel.org/linux-mm/202011020749.5XQ3Hfzc-lkp@intel.com/ https://lore.kernel.org/linux-mm/5fa49698.Vu2O3r+dU20UoEJ+%25lkp@intel.com/ Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-12-21ARM: 9031/1: hyp-stub: remove unused .L__boot_cpu_mode_offset symbolArd Biesheuvel
Commit aaac3733171fca94 ("ARM: kvm: replace open coded VA->PA calculations with adr_l call") removed all uses of .L__boot_cpu_mode_offset, so there is no longer a need to define it. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-12-21ARM: 9044/1: vfp: use undef hook for VFP support detectionArd Biesheuvel
Commit f77ac2e378be9dd6 ("ARM: 9030/1: entry: omit FP emulation for UND exceptions taken in kernel mode") failed to take into account that there is in fact a case where we relied on this code path: during boot, the VFP detection code issues a read of FPSID, which will trigger an undef exception on cores that lack VFP support. So let's reinstate this logic using an undef hook which is registered only for the duration of the initcall to vpf_init(), and which sets VFP_arch to a non-zero value - as before - if no VFP support is present. Fixes: f77ac2e378be9dd6 ("ARM: 9030/1: entry: omit FP emulation for UND ...") Reported-by: "kernelci.org bot" <bot@kernelci.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-12-21powerpc/vdso: Fix DOTSYM for 32-bit LE VDSOMichael Ellerman
Skirmisher reported on IRC that the 32-bit LE VDSO was hanging. This turned out to be due to a branch to self in eg. __kernel_gettimeofday. Looking at the disassembly with objdump -dR shows why: 00000528 <__kernel_gettimeofday>: 528: f0 ff 21 94 stwu r1,-16(r1) 52c: a6 02 08 7c mflr r0 530: f0 ff 21 94 stwu r1,-16(r1) 534: 14 00 01 90 stw r0,20(r1) 538: 05 00 9f 42 bcl 20,4*cr7+so,53c <__kernel_gettimeofday+0x14> 53c: a6 02 a8 7c mflr r5 540: ff ff a5 3c addis r5,r5,-1 544: c4 fa a5 38 addi r5,r5,-1340 548: f0 00 a5 38 addi r5,r5,240 54c: 01 00 00 48 bl 54c <__kernel_gettimeofday+0x24> 54c: R_PPC_REL24 .__c_kernel_gettimeofday Because we don't process relocations for the VDSO, this branch remains a branch from 0x54c to 0x54c. With the preceding patch to prohibit R_PPC_REL24 relocations, we instead get a build failure: 0000054c R_PPC_REL24 .__c_kernel_gettimeofday 00000598 R_PPC_REL24 .__c_kernel_clock_gettime 000005e4 R_PPC_REL24 .__c_kernel_clock_gettime64 00000630 R_PPC_REL24 .__c_kernel_clock_getres 0000067c R_PPC_REL24 .__c_kernel_time arch/powerpc/kernel/vdso32/vdso32.so.dbg: dynamic relocations are not supported The root cause is that we're branching to `.__c_kernel_gettimeofday`. But this is 32-bit LE code, which doesn't use function descriptors, so there are no dot symbols. The reason we're trying to branch to a dot symbol is because we're using the DOTSYM macro, but the ifdefs we use to define the DOTSYM macro do not currently work for 32-bit LE. So like previous commits we need to differentiate if the current compilation unit is 64-bit, rather than the kernel as a whole. ie. switch from CONFIG_PPC64 to __powerpc64__. With that fixed 32-bit LE code gets the empty version of DOTSYM, which just resolves to the original symbol name, leading to a direct branch and no relocations: 000003f8 <__kernel_gettimeofday>: 3f8: f0 ff 21 94 stwu r1,-16(r1) 3fc: a6 02 08 7c mflr r0 400: f0 ff 21 94 stwu r1,-16(r1) 404: 14 00 01 90 stw r0,20(r1) 408: 05 00 9f 42 bcl 20,4*cr7+so,40c <__kernel_gettimeofday+0x14> 40c: a6 02 a8 7c mflr r5 410: ff ff a5 3c addis r5,r5,-1 414: f4 fb a5 38 addi r5,r5,-1036 418: f0 00 a5 38 addi r5,r5,240 41c: 85 06 00 48 bl aa0 <__c_kernel_gettimeofday> Fixes: ab037dd87a2f ("powerpc/vdso: Switch VDSO to generic C implementation.") Reported-by: "Will Springer <skirmisher@protonmail.com>" Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201218111619.1206391-3-mpe@ellerman.id.au
2020-12-21powerpc/vdso: Don't pass 64-bit ABI cflags to 32-bit VDSOMichael Ellerman
When building the 32-bit VDSO, we are building 32-bit code as part of a 64-bit kernel build. That requires us to tweak the cflags to trick the compiler into building 32-bit code for us. The main way we do that is by passing -m32, but there are other options that affect code generation and ABI selection. In particular when building vgettimeofday.c, we end up passing -mcall-aixdesc because it's in KBUILD_CFLAGS, which causes the compiler to generate function descriptors, and dot symbols, eg: $ nm arch/powerpc/kernel/vdso32/vgettimeofday.o 000005d0 T .__c_kernel_clock_getres 00000024 D __c_kernel_clock_getres ... We get away with that at the moment because we also use the DOTSYM macro, and that is also incorrectly prepending a '.' in 32-bit VDSO code due to a separate bug. But we shouldn't be generating function descriptors for this file, there's no 32-bit ABI that includes function descriptors, so the resulting object file is some frankenstein and it's surprising that it even links. So filter out all the ABI-related options we add to CFLAGS for 64-bit builds, so that they're not used when building 32-bit code. With that we only see regular text symbols: $ nm arch/powerpc/kernel/vdso32/vgettimeofday.o michael@alpine1-p1 000005d0 T __c_kernel_clock_getres 00000000 T __c_kernel_clock_gettime 00000200 T __c_kernel_clock_gettime64 00000410 T __c_kernel_gettimeofday 00000650 T __c_kernel_time Fixes: ab037dd87a2f ("powerpc/vdso: Switch VDSO to generic C implementation.") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201218111619.1206391-2-mpe@ellerman.id.au
2020-12-21powerpc/vdso: Block R_PPC_REL24 relocationsMichael Ellerman
Add R_PPC_REL24 relocations to the list of relocations we do NOT support in the VDSO. These are generated in some cases and we do not support relocating them at runtime, so if they appear then the VDSO will not work at runtime, therefore it's preferable to break the build if we see them. Fixes: ab037dd87a2f ("powerpc/vdso: Switch VDSO to generic C implementation.") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201218111619.1206391-1-mpe@ellerman.id.au
2020-12-21powerpc/smp: Add __init to init_big_cores()Cédric Le Goater
It fixes this link warning: WARNING: modpost: vmlinux.o(.text.unlikely+0x2d98): Section mismatch in reference from the function init_big_cores.isra.0() to the function .init.text:init_thread_group_cache_map() The function init_big_cores.isra.0() references the function __init init_thread_group_cache_map(). This is often because init_big_cores.isra.0 lacks a __init annotation or the annotation of init_thread_group_cache_map is wrong. Fixes: 425752c63b6f ("powerpc: Detect the presence of big-cores via "ibm, thread-groups"") Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201221074154.403779-1-clg@kaod.org
2020-12-21powerpc/time: Force inlining of get_tb()Christophe Leroy
Force inlining of get_tb() in order to avoid getting following function in vdso32, leading to suboptimal performance in clock_gettime() 00000688 <.get_tb>: 688: 7c 6d 42 a6 mftbu r3 68c: 7c 8c 42 a6 mftb r4 690: 7d 2d 42 a6 mftbu r9 694: 7c 03 48 40 cmplw r3,r9 698: 40 e2 ff f0 bne+ 688 <.get_tb> 69c: 4e 80 00 20 blr Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/df05d53eed1210cf1aa76d1fb44aa0fab29c018e.1608488286.git.christophe.leroy@csgroup.eu
generated by cgit (git 2.34.1) at 2025-09-13 04:57:09 +0000