Douglas Anderson [Tue, 26 Jul 2022 17:38:21 +0000 (10:38 -0700)]
regulator: core: Allow specifying an initial load w/ the bulk API
There are a number of drivers that follow a pattern that looks like
this:
1. Use the regulator bulk API to get a bunch of regulators.
2. Set the load on each of the regulators to use whenever the
regulators are enabled.
Let's make this easier by just allowing the drivers to pass the load
in.
As part of this change we need to move the error printing in
regulator_bulk_get() around; let's switch to the new dev_err_probe()
to simplify it.
Alexander Stein [Wed, 27 Jul 2022 09:37:59 +0000 (11:37 +0200)]
dt-bindings: usb: Add binding for TI USB8041 hub controller
The TI USB8041 is a USB 3.0 hub controller with 4 ports.
This initial version of the binding only describes USB related aspects
of the USB8041, it does not cover the option of connecting the controller
as an i2c slave.
usb: misc: onboard-hub: add support for Microchip USB2514B USB 2.0 hub
Add support for Microchip USB2514B USB 2.0 hub to the onboard usb hub
driver. Adopt the generic usb-device compatible ("usbVID,PID").
Some STM32MP1 boards have this hub on-board, with a supply that needs to
be enabled for proper operation.
Allow properties and usb-device child nodes as defined in usb-hcd.yaml, by
using unevaluatedProperties: false. By the way, remove the "companion"
property as it's redundant with usb-hcd.yaml.
As example, this allows an onboard hub, to be described in generic-ehci
controller node:
usb {
compatible = "generic-ehci";
#address-cells = <1>;
#size-cells = <0>;
/* onboard HUB */
hub@1 {
compatible = "usb424,2514";
reg = <1>;
vdd-supply = <&v3v3>;
};
};
Without this, dtbs_check complains on '#address-cells', '#size-cells',
'hub@1' do not match any of the regexes: 'pinctrl-[0-9]+'
From schema: ..../generic-ehci.yaml
STM32G0 comes with STM32 bootloader in its system memory. Add support
for some I2C bootloader commands as described in application notes
AN2606 and AN4221, to enable STM32G0 UCSI firmware update.
Upon probing, the driver needs to know the STM32G0 state:
- In bootloader mode, STM32 G0 answers at i2c addr 0x51.
- In running mode, STM32 G0 firmware may answer at two address.
- The main address specified in DT is used for UCSI.
- 0x51 addr can be re-used for FW controls like getting software version
or jump to booloader request.
So probe using the main firmware i2c address first, before attempting
bootloader address (e.g. check for blank, erased or previously aborted
firmware update).
usb: typec: ucsi: stm32g0: add support for stm32g0 controller
STM32G0 provides an integrated USB Type-C and power delivery interface.
It can be programmed with a firmware to handle UCSI protocol over I2C
interface. A GPIO is used as an interrupt line.
Type-C connector can be used as a wakeup source (typically to detect
changes on the port, like attach or detach). PM suspend / resume routines
are used to enable wake irqs, and signal a wakeup event in case the IRQ
has fired while in suspend. The i2c core is doing the necessary
initialization when the "wakeup-source" flag is provided.
Note: the interrupt handler shouldn't be called before the i2c bus resumes.
So, the interrupts are disabled during suspend period, and re-enabled
upon resume, to avoid i2c transfer while suspended, from the irq handler.
dt-bindings: usb: typec: add bindings for stm32g0 controller
Add DT schema documentation for the STM32G0 Type-C PD (Power Delivery)
controller.
STM32G0 provides an integrated USB Type-C and power delivery interface.
It can be programmed with a firmware to handle UCSI protocol over I2C
interface. A GPIO is used as an interrupt line.
It may be used as a wakeup source, so use optional "wakeup-source" and
"power-domains" properties to support wakeup.
The firmware itself may be flashed or later updated (optional). Choice is
let to the application to allow firmware update. A default firmware could
be already programmed in production and be customized (to not allow it).
So the firmware-name is made optional to represent this option.
usb: typec: retimer: Add missing id check in match callback
The fwnode_connection_find_match() function handles two cases: named
references and graph endpoints. In the second case, the match function
passed in is called with the id to check for the match. However, the
match function for the recently added type-c retimer class assumes the
connection has already been matched (which is only true for the first
case).
The result is that with that change, all type-c nodes with graph
endpoints defer probe indefinitely, independently of having a retimer
connection or not.
Add the missing check, like is done by the type-c mux and usb role
switch code, to fix the issue.
Fixes: ddaf8d96f93b ("usb: typec: Add support for retimers") Reviewed-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Link: https://lore.kernel.org/r/20220725203129.1973260-1-nfraprado@collabora.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Stern [Thu, 21 Jul 2022 15:07:10 +0000 (11:07 -0400)]
USB: gadget: Fix use-after-free Read in usb_udc_uevent()
The syzbot fuzzer found a race between uevent callbacks and gadget
driver unregistration that can cause a use-after-free bug:
---------------------------------------------------------------
BUG: KASAN: use-after-free in usb_udc_uevent+0x11f/0x130
drivers/usb/gadget/udc/core.c:1732
Read of size 8 at addr ffff888078ce2050 by task udevd/2968
The bug occurs because usb_udc_uevent() dereferences udc->driver but
does so without acquiring the udc_lock mutex, which protects this
field. If the gadget driver is unbound from the udc concurrently with
uevent processing, the driver structure may be accessed after it has
been deallocated.
To prevent the race, we make sure that the routine holds the mutex
around the racing accesses.
Weitao Wang [Tue, 26 Jul 2022 07:49:18 +0000 (15:49 +0800)]
USB: HCD: Fix URB giveback issue in tasklet function
Usb core introduce the mechanism of giveback of URB in tasklet context to
reduce hardware interrupt handling time. On some test situation(such as
FIO with 4KB block size), when tasklet callback function called to
giveback URB, interrupt handler add URB node to the bh->head list also.
If check bh->head list again after finish all URB giveback of local_list,
then it may introduce a "dynamic balance" between giveback URB and add URB
to bh->head list. This tasklet callback function may not exit for a long
time, which will cause other tasklet function calls to be delayed. Some
real-time applications(such as KB and Mouse) will see noticeable lag.
In order to prevent the tasklet function from occupying the cpu for a long
time at a time, new URBS will not be added to the local_list even though
the bh->head list is not empty. But also need to ensure the left URB
giveback to be processed in time, so add a member high_prio for structure
giveback_urb_bh to prioritize tasklet and schelule this tasklet again if
bh->head list is not empty.
At the same time, we are able to prioritize tasklet through structure
member high_prio. So, replace the local high_prio_bh variable with this
structure member in usb_hcd_giveback_urb.
Fixes: 94dfd7edfd5c ("USB: HCD: support giveback of URB in tasklet context") Cc: stable <stable@kernel.org> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Weitao Wang <WeitaoWang-oc@zhaoxin.com> Link: https://lore.kernel.org/r/20220726074918.5114-1-WeitaoWang-oc@zhaoxin.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since commit 4736ebd7fcaff1eb8481c140ba494962847d6e0a ("usb: host:
xhci-plat: omit shared hcd if either root hub has no ports")
xhci->shared_hcd can be NULL, which causes the following Oops
on reboot:
Dan Carpenter [Fri, 22 Jul 2022 06:29:07 +0000 (09:29 +0300)]
usb: typec: anx7411: fix error checking in anx7411_get_gpio_irq()
This is a minor bug which means that certain error messages are not
printed.
The devm_gpiod_get_optional() function can return either error pointers
or NULL. It returns error pointers if there is an allocation failure,
or a similar issue. It returns NULL if no GPIO was assigned to the
requested function. Print an error in either case.
The gpiod_to_irq() function never returns zero. It either returns
a positive IRQ number or a negative error code.
Colin Ian King [Fri, 15 Jul 2022 22:56:57 +0000 (23:56 +0100)]
usb: phy: remove redundant store to variable var after & operation
There is no need to store the result of the & operation back to the
variable var. The store is redundant, replace &= with just &.
Cleans up clang scan warning:
drivers/usb/phy/phy-keystone.c:62:5: warning: Although the value stored to
'val' is used in the enclosing expression, the value is never actually read
from 'val' [deadcode.DeadStores]
Stefan Raspl [Mon, 25 Jul 2022 14:10:00 +0000 (16:10 +0200)]
net/smc: Enable module load on netlink usage
Previously, the smc and smc_diag modules were automatically loaded as
dependencies of the ism module whenever an ISM device was present.
With the pending rework of the ISM API, the smc module will no longer
automatically be loaded in presence of an ISM device. Usage of an AF_SMC
socket will still trigger loading of the smc modules, but usage of a
netlink socket will not.
This is addressed by setting the correct module aliases.
Signed-off-by: Stefan Raspl <raspl@linux.ibm.com> Signed-off-by: Wenjia Zhang < wenjia@linux.ibm.com> Reviewed-by: Tony Lu <tonylu@linux.alibaba.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Stefan Raspl [Mon, 25 Jul 2022 14:09:59 +0000 (16:09 +0200)]
net/smc: Pass on DMBE bit mask in IRQ handler
Make the DMBE bits, which are passed on individually in ism_move() as
parameter idx, available to the receiver.
Signed-off-by: Stefan Raspl <raspl@linux.ibm.com> Signed-off-by: Wenjia Zhang < wenjia@linux.ibm.com> Reviewed-by: Tony Lu <tonylu@linux.alibaba.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Stefan Raspl [Mon, 25 Jul 2022 14:09:58 +0000 (16:09 +0200)]
s390/ism: Cleanups
Reworked signature of the function to retrieve the system EID: No plausible
reason to use a double pointer. And neither to pass in the device as an
argument, as this identifier is by definition per system, not per device.
Plus some minor consistency edits.
Signed-off-by: Stefan Raspl <raspl@linux.ibm.com> Signed-off-by: Wenjia Zhang < wenjia@linux.ibm.com> Reviewed-by: Tony Lu <tonylu@linux.alibaba.com> Signed-off-by: David S. Miller <davem@davemloft.net>
This struct is used in a single place only, and its usage generates
inefficient code. Time to clean up!
Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Reviewed-and-tested-by: Stefan Raspl <raspl@linux.ibm.com> Signed-off-by: Wenjia Zhang < wenjia@linux.ibm.com> Reviewed-by: Tony Lu <tonylu@linux.alibaba.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Jason Wang [Mon, 25 Jul 2022 07:21:59 +0000 (15:21 +0800)]
virtio-net: fix the race between refill work and close
We try using cancel_delayed_work_sync() to prevent the work from
enabling NAPI. This is insufficient since we don't disable the source
of the refill work scheduling. This means an NAPI poll callback after
cancel_delayed_work_sync() can schedule the refill work then can
re-enable the NAPI that leads to use-after-free [1].
Since the work can enable NAPI, we can't simply disable NAPI before
calling cancel_delayed_work_sync(). So fix this by introducing a
dedicated boolean to control whether or not the work could be
scheduled from NAPI.
[1]
==================================================================
BUG: KASAN: use-after-free in refill_work+0x43/0xd4
Read of size 2 at addr ffff88810562c92e by task kworker/2:1/42
Fixes: b2baed69e605c ("virtio_net: set/cancel work on ndo_open/ndo_stop") Signed-off-by: Jason Wang <jasowang@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Randy Dunlap [Wed, 20 Jul 2022 17:37:49 +0000 (10:37 -0700)]
kconfig: Qt5: tell the user which packages are required
Along with saying "Please install Qt5 ...", tell exactly which
parts of Qt5 are needed. This is useful when parts of Qt5 are
installed but some of the required pieces are missing, and it
eliminates the need for the user to find the shell script and
the line in it that provide that information.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
kconfig: shorten the temporary directory name for cc-option
The cc-option macro creates the temporary directory, .tmp_$$$$.
Shell expands '$$' into its process ID. '$$$$' results in repeated PID.
In Makefile, '$$$$' is correct (see TMPOUT in scripts/Malefile.compiler)
because '$$' is an escape sequence of '$'. Make expands '$$$$' into '$$',
then shell expands it into the process ID.
This does not apply to Kconfig because Kconfig requires variable
references to be enclosed by curly braces, like ${variable}.
The '$' that is not followed by '{' loses its effect.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Tested-by: Nicolas Schier <nicolas@fjasle.eu>
Remove two dated config leak ignore entries from scripts/headers_install.sh:
arch/alpha/include/uapi/asm/setup.h does no more leak any CONFIG_* symbol to
user-space any more since commit 3cb8b1537f8a ("alpha: Move setup.h out of
uapi").
Same holds for include/uapi/asm-generic/fcntl.h since commit 306f7cc1e906
("uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in fcntl.h").
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
kbuild: rpm-pkg: fix build error when _arch is undefined
Cross-building (bin)rpm-pkg fails on several architectures.
For example, 'make ARCH=arm binrpm-pkg' fails like follows:
sh ./scripts/package/mkspec prebuilt > ./binkernel.spec
rpmbuild --define "_builddir ." --target \
arm -bb ./binkernel.spec
Building target platforms: arm
Building for target arm
warning: line 19: It's not recommended to have unversioned Obsoletes: Obsoletes: kernel-headers
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.0S8t2F
+ umask 022
+ cd .
+ mkdir -p /home/masahiro/rpmbuild/BUILDROOT/kernel-5.19.0_rc6-19.%{_arch}/boot
+ make -f ./Makefile image_name
+ cp arch/arm/boot/zImage /home/masahiro/rpmbuild/BUILDROOT/kernel-5.19.0_rc6-19.%{_arch}/boot/vmlinuz-5.19.0-rc6
+ make -f ./Makefile INSTALL_MOD_PATH=/home/masahiro/rpmbuild/BUILDROOT/kernel-5.19.0_rc6-19.%{_arch} modules_install
make[3]: *** No rule to make target '/home/masahiro/rpmbuild/BUILDROOT/kernel-5.19.0_rc6-19.arch/arm/crypto/aes-arm-bs.ko{_arch}/lib/modules/5.19.0-rc6/kernel/%', needed by '__modinst'. Stop.
make[2]: *** [Makefile:1768: modules_install] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.0S8t2F (%install)
By default, 'buildroot' contains %{_arch} (see /usr/lib/rpm/macros).
_arch is generally defined in /usr/lib/rpm/platforms/*/macros, where
the platform sub-directory is specified by --target= option for cross
builds.
If the given arch does not exist, %{_arch} is not expanded.
In the example above, --target=arm is passed to rpmbuild, but
/usr/lib/rpm/platforms/arm-linux/ does not exist.
The '%' character in the path confuses GNU make and rpmbuild.
The same occurs for such architectures as csky, microblaze, nios2, etc.
Define _arch if it has not been defined.
Reported-by: Jason Self <jason@bluehome.net> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Ondrej Mosnacek [Mon, 11 Jul 2022 12:09:23 +0000 (14:09 +0200)]
kbuild: dummy-tools: avoid tmpdir leak in dummy gcc
When passed -print-file-name=plugin, the dummy gcc script creates a
temporary directory that is never cleaned up. To avoid cluttering
$TMPDIR, instead use a static directory included in the source tree.
Fixes: 76426e238834 ("kbuild: add dummy toolchains to enable all cc-option etc. in Kconfig") Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
CONFIG_KALLSYMS_ALL is required for kernel live patching which is a
common use case that is enabled in some major distros. Update the
Kconfig help text to reflect that.
While at it, s/e.g./i.e./ to match the text intention.
Nick Desaulniers [Tue, 28 Jun 2022 21:04:07 +0000 (14:04 -0700)]
kbuild: drop support for CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3
The difference in most compilers between `-O3` and `-O2` is mostly down
to whether loops with statically determinable trip counts are fully
unrolled vs unrolled to a multiple of SIMD width.
This patch is effectively a revert of
commit 15f5db60a137 ("kbuild,arc: add
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3 for ARC") without re-adding
ARCH_CFLAGS
Ever since
commit cfdbc2e16e65 ("ARC: Build system: Makefiles, Kconfig, Linker
script")
ARC has been built with -O3, though the reason for doing so was not
specified in inline comments or the commit message. This commit does not
re-add -O3 to arch/arc/Makefile.
Folks looking to experiment with `-O3` (or any compiler flag for that
matter) may pass them along to the command line invocation of make:
$ make KCFLAGS=-O3
Code that looks to re-add an explicit Kconfig option for `-O3` should
provide:
1. A rigorous and reproducible performance profile of a reasonable
userspace workload that demonstrates a hot loop in the kernel that
would benefit from `-O3` over `-O2`.
2. Disassembly of said loop body before and after.
3. Provides stats on terms of increase in file size.
Jean Delvare [Wed, 27 Jul 2022 11:26:37 +0000 (13:26 +0200)]
regulator: mt6380: Fix unused array warning
With the following configuration options:
CONFIG_OF is not set
CONFIG_REGULATOR_MT6380=y
we get the following build warning:
CC drivers/regulator/mt6380-regulator.o
drivers/regulator/mt6380-regulator.c:322:34: warning: ‘mt6380_of_match’ defined but not used [-Wunused-const-variable=]
Fix this by annotating that array with __maybe_unused, as done in
various regulator drivers.
The afe_priv->dai_priv[] is allocated when platform driver probe(), if it
failed, the ASoC platform driver probe() will return fail first.
Therefore, this is excessive judgment, and the condition will never be
established.
powerpc/32: Don't always pass -mcpu=powerpc to the compiler
Since commit 4bf4f42a2feb ("powerpc/kbuild: Set default generic
machine type for 32-bit compile"), when building a 32 bits kernel
with a bi-arch version of GCC, or when building a book3s/32 kernel,
the option -mcpu=powerpc is passed to GCC at all time, relying on it
being eventually overriden by a subsequent -mcpu=xxxx.
But when building the same kernel with a 32 bits only version of GCC,
that is not done, relying on gcc being built with the expected default
CPU.
This logic has two problems. First, it is a bit fragile to rely on
whether the GCC version is bi-arch or not, because today we can have
bi-arch versions of GCC configured with a 32 bits default. Second,
there are some versions of GCC which don't support -mcpu=powerpc,
for instance for e500 SPE-only versions.
So, stop relying on this approximative logic and allow the user to
decide whether he/she wants to use the toolchain's default CPU or if
he/she wants to set one, and allow only possible CPUs based on the
selected target.
powerpc/32: Do not allow selection of e5500 or e6500 CPUs on PPC32
Commit 0e00a8c9fd92 ("powerpc: Allow CPU selection also on PPC32")
enlarged the CPU selection logic to PPC32 by removing depend to
PPC64, and failed to restrict that depend to E5500_CPU and E6500_CPU.
Fortunately that got unnoticed because -mcpu=8540 will override the
-mcpu=e500mc64 or -mpcu=e6500 as they are ealier, but that's
fragile and may no be right in the future.
Add back the depend PPC64 on E5500_CPU and E6500_CPU.
powerpc/perf: Use PVR rather than oprofile field to determine CPU version
Currently the perf CPU backend drivers detect what CPU they're on using
cur_cpu_spec->oprofile_cpu_type.
Although that works, it's a bit crufty to be using oprofile related fields,
especially seeing as oprofile is more or less unused these days.
It also means perf is reliant on the fragile logic in setup_cpu_spec()
which detects when we're using a logical PVR and copies back the PMU
related fields from the raw CPU entry. So lets check the PVR directly.
powerpc/32s: Fix boot failure with KASAN + SMP + JUMP_LABEL_FEATURE_CHECK_DEBUG
Since commit 4291d085b0b0 ("powerpc/32s: Make pte_update() non
atomic on 603 core"), pte_update() has been using
mmu_has_feature(MMU_FTR_HPTE_TABLE) to avoid a useless atomic
operation on 603 cores.
When kasan_early_init() sets up the early zero shadow, it uses
__set_pte_at(). On book3s/32, __set_pte_at() calls pte_update()
when CONFIG_SMP is selected in order to ensure the preservation of
_PAGE_HASHPTE in case of concurrent update of the PTE. But that's
too early for mmu_has_feature(), so when
CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG is selected, mmu_has_feature()
calls printk(). That's too early to call printk() because KASAN
early zero shadow page is not set up yet. It leads to a deadlock.
However, when kasan_early_init() is called, there is only one CPU
running and no risk of concurrent PTE update. So __set_pte_at() can
be called with the 'percpu' flag. With that flag set, the PTE is
written directly instead of being written via pte_update().
Christophe Leroy [Tue, 14 Jun 2022 10:34:09 +0000 (12:34 +0200)]
powerpc/32: Set an IBAT covering up to _einittext during init
Always set an IBAT covering up to _einittext during init because when
CONFIG_MODULES is not selected there is no reason to have an exception
handler for kernel instruction TLB misses.
It implies DBAT and IBAT are now totaly independent, IBATs are set
by setibat() and DBAT by setbat().
This allows to revert commit 9bb162fa26ed ("powerpc/603: Fix
boot failure with DEBUG_PAGEALLOC and KFENCE")
Christophe Leroy [Tue, 14 Jun 2022 10:34:08 +0000 (12:34 +0200)]
powerpc/32: Call mmu_mark_initmem_nx() regardless of data block mapping.
mark_initmem_nx() calls either mmu_mark_initmem_nx() or
set_memory_attr() based on return from v_block_mapped()
of _sinittext.
But we can now handle text and data independently, so that
text may be mapped by block even when data is mapped by pages.
On the 8xx for instance, at startup 32Mbytes of memory are
pinned in TLB. So the pinned entries need to go away for sinittext.
In next patch a BAT will be set to also covers sinittext on book3s/32.
So it will also be needed to call mmu_mark_initmem_nx() even when
data above sinittext is not mapped with BATs.
As this is highly dependent on the platform, call mmu_mark_initmem_nx()
regardless of data block mapping. Then the platform will know what to
do.
Modify 8xx mmu_mark_initmem_nx() so that inittext mapping is modified
only when pagealloc debug and kfence are not active, otherwise inittext
is mapped with standard pages. And don't do anything on kernel text
which is already mapped with PAGE_KERNEL_TEXT.
Nicholas Piggin [Wed, 25 May 2022 02:23:58 +0000 (12:23 +1000)]
powerpc/64s: Remove spurious fault flushing for NMMU
Commit 6d8278c414cb2 ("powerpc/64s/radix: do not flush TLB on spurious
fault") removed the TLB flush for spurious faults, except when a
coprocessor (nest MMU) maps the address space. This is not needed
because the NMMU workaround in the PTE permission upgrade paths
prevents PTEs existing with less restrictive access permissions than
their corresponding TLB entries have.
Nicholas Piggin [Wed, 25 May 2022 02:23:57 +0000 (12:23 +1000)]
powerpc/64s: POWER10 nest MMU can upgrade PTE access authority without TLB flush
The nest MMU in POWER9 does not re-fetch the PTE in response to
permission mismatch, contrary to the architecture[*] and unlike the core
MMU. This requires a TLB flush before upgrading permissions of valid
PTEs, for any address space with a coprocessor attached.
Per (non-public) Nest MMU Workbook, POWER10 nest MMU conforms to the
architecture in this regard, so skip the workaround.
[*] See: Power ISA Version 3.1B, 6.10.1.2 Modifying a Translation Table
Entry, Setting a Reference or Change Bit or Upgrading Access
Authority (PTE Subject to Atomic Hardware Updates):
"If the only change being made to a valid PTE that is subject to
atomic hardware updates is to set the Reference or Change bit to
1 or to upgrade access authority, a simpler sequence suffices
because the translation hardware will refetch the PTE if an
access is attempted for which the only problems were reference
and/or change bits needing to be set or insufficient access
authority."
Nicholas Piggin [Wed, 25 May 2022 02:23:56 +0000 (12:23 +1000)]
powerpc/64s: POWER10 nest MMU does not require flush escalation workaround
Per (non-public) Nest MMU Workbook, POWER10 and POWER9P NMMU does not
cache PTEs in PWC, so does not require PWC flush to invalidate these
translations.
Nicholas Piggin [Fri, 20 May 2022 12:36:49 +0000 (22:36 +1000)]
powerpc/vdso: Fix __kernel_sync_dicache sequence with coherent icache
Processors with coherent icache require the sequence sync ; icbi ; isync
to entire store->execute coherency. icbi (to any address) must be
executed to ensure isync flushes the pipeline. See "POWER9 Processor
User's Manual, 4.6.2.2 Instruction Cache Block Invalidate (icbi)" for
details.
__kernel_sync_dicache is missing icbi for the coherent icache path.
Add it.
powerpc/pci: Add config option for using all 256 PCI buses
By default on PPC32 PCI bus numbers are unique across all PCI domains.
So a system could have only 256 PCI buses independently of available PCI
domains.
This is due to filling DT property pci-OF-bus-map which does not support
a multi-domain setup.
On all powerpc platforms except chrp and powermac there is no DT
property pci-OF-bus-map anymore and therefore it is possible on
non-chrp/powermac platforms to avoid this limitation of maximum number
of 256 PCI buses in a system even on multi-domain setup.
But avoiding this limitation would mean that all PCI and PCIe devices
would be present on completely different BDF addresses as every PCI
domain starts numbering PCI bueses from zero (instead of the last bus
number of previous enumerated PCI domain). Such change could break
existing software which expects fixed PCI bus numbers.
So add a new config option CONFIG_PPC_PCI_BUS_NUM_DOMAIN_DEPENDENT which
enables this change. By default it is disabled. It causes the initial
value of hose->first_busno to be zero.
powerpc/pci: Disable filling pci-OF-bus-map for non-chrp/powermac
Creating or filling pci-OF-bus-map property in the device-tree is
deprecated since May 2006 [1] and was used only in old platforms like
PowerMac.
Currently kernel code handles it only for chrp and powermac code. So
completely disable filling pci-OF-bus-map property for non-chrp and
non-powermac platforms.
By default old pre-3.0 Freescale PCIe controllers reports invalid PCI Class
Code 0x0b20 for PCIe Root Port. It can be seen by lspci -b output on P2020
board which has this pre-3.0 controller:
$ lspci -bvnn
00:00.0 Power PC [0b20]: Freescale Semiconductor Inc P2020E [1957:0070] (rev 21)
!!! Invalid class 0b20 for header type 01
Capabilities: [4c] Express Root Port (Slot-), MSI 00
Fix this issue by programming correct PCI Class Code 0x0604 for PCIe Root
Port to the Freescale specific PCIe register 0x474.
Fix activated by U-Boot stay active also after booting Linux kernel.
But boards which use older U-Boot version without that fix are affected and
still require this fix.
So implement this class code fix also in kernel fsl_pci.c driver.
The .incbin assembler directive is much faster than bin2c + $(CC).
Do similar refactoring as in commit 4c0f032d4963 ("s390/purgatory:
Omit use of bin2c").
Please note the .quad directive matches to size_t in C (both 8 byte)
because the purgatory is compiled only for the 64-bit kernel.
(KEXEC_FILE depends on PPC64).
powerpc/pseries/mobility: set NMI watchdog factor during an LPM
During an LPM, while the memory transfer is in progress on the arrival
side, some latencies are generated when accessing not yet transferred
pages on the arrival side. Thus, the NMI watchdog may be triggered too
frequently, which increases the risk to hit an NMI interrupt in a bad
place in the kernel, leading to a kernel panic.
Disabling the Hard Lockup Watchdog until the memory transfer could be a
too strong work around, some users would want this timeout to be
eventually triggered if the system is hanging even during an LPM.
Introduce a new sysctl variable nmi_watchdog_factor. It allows to apply
a factor to the NMI watchdog timeout during an LPM. Just before the CPUs
are stopped for the switchover sequence, the NMI watchdog timer is set
to watchdog_thresh + factor%
A value of 0 has no effect. The default value is 200, meaning that the
NMI watchdog is set to 30s during LPM (based on a 10s watchdog_thresh
value). Once the memory transfer is achieved, the factor is reset to 0.
Setting this value to a high number is like disabling the NMI watchdog
during an LPM.
powerpc/watchdog: introduce a NMI watchdog's factor
Introduce a factor which would apply to the NMI watchdog timeout.
This factor is a percentage added to the watchdog_tresh value. The value is
set under the watchdog_mutex protection and lockup_detector_reconfigure()
is called to recompute wd_panic_timeout_tb.
Once the factor is set, it remains until it is set back to 0, which means
no impact.
In some circumstances it may be interesting to reconfigure the watchdog
from inside the kernel.
On PowerPC, this may helpful before and after a LPAR migration (LPM) is
initiated, because it implies some latencies, watchdog, and especially NMI
watchdog is expected to be triggered during this operation. Reconfiguring
the watchdog with a factor, would prevent it to happen too frequently
during LPM.
Rename lockup_detector_reconfigure() as __lockup_detector_reconfigure() and
create a new function lockup_detector_reconfigure() calling
__lockup_detector_reconfigure() under the protection of watchdog_mutex.
Merge patch series "can: export export slcan_ethtool_ops and remove setter functions"
Vincent Mailhol <mailhol.vincent@wanadoo.fr> says:
====================
The c_can, flexcan and slcan use a setter function to populate
net_device::ethtool_ops. Using a setter here add one additional
function call and add some small bloat in the object file. Exporting
the structure allow to remove this setter.
The mcp251xfd uses a similar pattern except that it does some
additional initialization. As such, this driver is left untouched.
* Statistics *
For the slcan driver, this patch reduces the object file by 14 bytes
(details in the first patch). Although we did not conduct a benchmark
for the other drivers but we expect the exact same figures.
Vincent Mailhol [Wed, 27 Jul 2022 10:49:39 +0000 (19:49 +0900)]
can: flexcan: export flexcan_ethtool_ops and remove flexcan_set_ethtool_ops()
The function flexcan_set_ethtool_ops() does one thing: populate
net_device::ethtool_ops. Instead, it is possible to directly assign
this field and remove one function call and slightly reduce the object
size. To do so, export flexcan_ethtool_ops so it becomes visible to
flexcan-core.c.
Vincent Mailhol [Wed, 27 Jul 2022 10:49:38 +0000 (19:49 +0900)]
can: c_can: export c_can_ethtool_ops and remove c_can_set_ethtool_ops()
The function c_can_set_ethtool_ops() does one thing: populate
net_device::ethtool_ops. Instead, it is possible to directly assign
this field and remove one function call and slightly reduce the object
size. To do so, export c_can_ethtool_ops so it becomes visible to
c_can_main.c.
Vincent Mailhol [Wed, 27 Jul 2022 10:49:37 +0000 (19:49 +0900)]
can: slcan: export slcan_ethtool_ops and remove slcan_set_ethtool_ops()
The function slcan_set_ethtool_ops() does one thing: populate
net_device::ethtool_ops. Instead, it is possible to directly assign
this field and remove one function call and slightly reduce the object
size. To do so, export slcan_ethtool_ops so it becomes visible to
sclan-core.c.
ASoC: mchp-spdifrx: disable end of block interrupt on failures
Disable end of block interrupt in case of wait for completion timeout
or errors to undo previously enable operation (done in
mchp_spdifrx_isr_blockend_en()). Otherwise we can end up with an
unbalanced reference counter for this interrupt.
projects / people / ms / linux.git / log
