Age | Commit message (Collapse) | Author | Files | Lines |
|
* 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
|
|
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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
|
|
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: [email protected]
Reported-by: Bin Meng <[email protected]>
Tested-by: Bin Meng <[email protected]>
Acked-by: Mike Rapoport <[email protected]>
Signed-off-by: Atish Patra <[email protected]>
Signed-off-by: Palmer Dabbelt <[email protected]>
|
|
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: [email protected] #v5.7+
Signed-off-by: Artem Labazov <[email protected]>
Signed-off-by: Namjae Jeon <[email protected]>
|
|
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 <[email protected]>
Tested-by: Johannes Berg <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Stefan Chulski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
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 <[email protected]>
Link: https://lore.kernel.org/r/e3a4c355e3820331d8e1fffef8522739aae58b57.1608380117.git.gnault@redhat.com
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
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 <[email protected]>
Link: https://lore.kernel.org/r/X93dmC4NX0vbTpGp@mwanda
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
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/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
Reviewed-by: Vladimir Oltean <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Vladimir Oltean <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Eric Dumazet <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Acked-by: Song Liu <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
|
|
xa_store() may fail, check the result.
Cc: [email protected] # 5.10
Fixes: 0f2122045b946 ("io_uring: don't rely on weak ->files references")
Signed-off-by: Pavel Begunkov <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Mike Snitzer <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Sami Tolvanen <[email protected]>
Signed-off-by: Mike Snitzer <[email protected]>
|
|
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
...
|
|
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
|
|
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
|
|
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 <[email protected]>
Signed-off-by: Arend van Spriel <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jonathan Corbet <[email protected]>
|
|
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/[email protected]
and incorporates follow-on comments.
Signed-off-by: Borislav Petkov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jonathan Corbet <[email protected]>
|
|
Renumber the steps in submit-checklist.rst as some numbers were skipped.
Signed-off-by: Milan Lakhani <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jonathan Corbet <[email protected]>
|
|
"it is a used" does not make sense. Should be "it is used".
Signed-off-by: Lee Jones <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jonathan Corbet <[email protected]>
|
|
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: [email protected] # v5.10+
Signed-off-by: Christophe Leroy <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/a3d819d5c348cee9783a311d5d3f3ba9b48fd219.1608531452.git.christophe.leroy@csgroup.eu
|
|
|
|
|
|
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" <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Ard Biesheuvel <[email protected]>
Signed-off-by: Russell King <[email protected]>
|
|
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 <[email protected]>
Tested-by: Nick Desaulniers <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
Signed-off-by: Russell King <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Ard Biesheuvel <[email protected]>
Reviewed-by: Nicolas Pitre <[email protected]>
Signed-off-by: Russell King <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Russell King <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Ard Biesheuvel <[email protected]>
Reviewed-by: Nicolas Pitre <[email protected]>
Signed-off-by: Russell King <[email protected]>
|
|
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 <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Anshuman Khandual <[email protected]>
Signed-off-by: Russell King <[email protected]>
|
|
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/[email protected]/
https://lore.kernel.org/linux-mm/5fa49698.Vu2O3r+dU20UoEJ+%[email protected]/
Cc: Andrew Morton <[email protected]>
Cc: [email protected]
Cc: [email protected]
Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Anshuman Khandual <[email protected]>
Signed-off-by: Russell King <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Russell King <[email protected]>
|
|
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" <[email protected]>
Signed-off-by: Ard Biesheuvel <[email protected]>
Signed-off-by: Russell King <[email protected]>
|
|
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 <[email protected]>"
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/df05d53eed1210cf1aa76d1fb44aa0fab29c018e.1608488286.git.christophe.leroy@csgroup.eu
|
|
The lkp robot reported that some configs fail to build, for example
mpc85xx_smp_defconfig, with:
cc1: fatal error: opening output file arch/powerpc/boot/dts/fsl/.mpc8540ads.dtb.dts.tmp: No such file or directory
This bisects to:
cc8a51ca6f05 ("kbuild: always create directories of targets")
Although that commit claims to be about in-tree builds, it somehow
breaks out-of-tree builds. But presumably it's just exposing a latent
bug in our Makefiles.
We can fix it by adding to targets for dts/fsl in the same way that we
do for dts.
Fixes: cc8a51ca6f05 ("kbuild: always create directories of targets")
Reported-by: kernel test robot <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
When turbo has been disabled by the BIOS, but HWP_CAP.GUARANTEED is
changed later, user space may want to take advantage of this increased
guaranteed performance.
HWP_CAP.GUARANTEED is not a static value. It can be adjusted by an
out-of-band agent or during an Intel Speed Select performance level
change. The HWP_CAP.MAX is still the maximum achievable performance
with turbo disabled by the BIOS, so HWP_CAP.GUARANTEED can still
change as long as it remains less than or equal to HWP_CAP.MAX.
When HWP_CAP.GUARANTEED is changed, the sysfs base_frequency
attribute shows the most recent guaranteed frequency value. This
attribute can be used by user space software to update the scaling
min/max limits of the CPU.
Currently, the ->setpolicy() callback already uses the latest
HWP_CAP values when setting HWP_REQ, but the ->verify() callback will
restrict the user settings to the to old guaranteed performance value
which prevents user space from making use of the extra CPU capacity
theoretically available to it after increasing HWP_CAP.GUARANTEED.
To address this, read HWP_CAP in intel_pstate_verify_cpu_policy()
to obtain the maximum P-state that can be used and use that to
confine the policy max limit instead of using the cached and
possibly stale pstate.max_freq value for this purpose.
For consistency, update intel_pstate_update_perf_limits() to use the
maximum available P-state returned by intel_pstate_get_hwp_max() to
compute the maximum frequency instead of using the return value of
intel_pstate_get_max_freq() which, again, may be stale.
This issue is a side-effect of fixing the scaling frequency limits in
commit eacc9c5a927e ("cpufreq: intel_pstate: Fix intel_pstate_get_hwp_max()
for turbo disabled") which corrected the setting of the reduced scaling
frequency values, but caused stale HWP_CAP.GUARANTEED to be used in
the case at hand.
Fixes: eacc9c5a927e ("cpufreq: intel_pstate: Fix intel_pstate_get_hwp_max() for turbo disabled")
Reported-by: Srinivas Pandruvada <[email protected]>
Tested-by: Srinivas Pandruvada <[email protected]>
Cc: 5.8+ <[email protected]> # 5.8+
Signed-off-by: Rafael J. Wysocki <[email protected]>
|
|
ASUS PRIME TRX40 PRO-S mobo with 0b05:1918 needs the same quirk alias
for another ASUS mobo (0b05:1917) for the proper mixer mapping, etc.
Add the corresponding entry.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=210783
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
|
|
Remove redundant comments
Signed-off-by: YangHui <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
|
|
This is a typo.
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
$(error-if,...) is expanded to an empty string. Currently, it relies on
eval_clause() returning xstrdup("") when all attempts for expansion fail,
but the correct implementation is to make do_error_if() return xstrdup("").
Fixes: 1d6272e6fe43 ("kconfig: add 'info', 'warning-if', and 'error-if' built-in functions")
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
Document best practises for using architecture and platform dependencies.
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
|