Jakub Kicinski [Tue, 26 Jul 2022 21:56:52 +0000 (14:56 -0700)]
add missing includes and forward declarations to networking includes under linux/
Similarly to a recent include/net/ cleanup, this patch adds
missing includes to networking headers under include/linux.
All these problems are currently masked by the existing users
including the missing dependency before the broken header.
A recent snafu where Intel ignored upstream feedback on a firmware
change, led to a late rc6 fix being required. In order to avoid this
in the future we should document some expectations around
linux-firmware.
I was originally going to write this for drm, but it seems quite generic
advice.
v2: rewritten with suggestions from Thorsten Leemhuis
v3: rewritten with suggestions from Mauro
Acked-by: Luis Chamberlain <mcgrof@kernel.org> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://lore.kernel.org/r/20220721044352.3110507-1-airlied@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Philipp Hortmann [Thu, 28 Jul 2022 05:59:45 +0000 (07:59 +0200)]
staging: vt6655: Convert macro vt6655_mac_clear_stck_ds to function
Convert once used macro to static function. Multiline macros are not
liked by kernel community. Rename variable byOrgValue to reg_value to
avoid CamelCase which is not accepted by checkpatch.pl. Change variable
declaration to u8 as this improves readability.
Peter Suti [Wed, 27 Jul 2022 07:35:50 +0000 (09:35 +0200)]
staging: fbtft: core: set smem_len before fb_deferred_io_init call
The fbtft_framebuffer_alloc() calls fb_deferred_io_init() before
initializing info->fix.smem_len. It is set to zero by the
framebuffer_alloc() function. It will trigger a WARN_ON() at the
start of fb_deferred_io_init() and the function will not do anything.
see warnings:
| lib/test_printf.c:157:52: error: format specifies type 'unsigned char'
| but the argument has type 'int' [-Werror,-Wformat]
test("0|1|1|128|255",
| "%hhu|%hhu|%hhu|%hhu|%hhu", 0, 1, 257, 128, -1);
-
| lib/test_printf.c:158:55: error: format specifies type 'char' but the
| argument has type 'int' [-Werror,-Wformat] test("0|1|1|-128|-1",
| "%hhd|%hhd|%hhd|%hhd|%hhd", 0, 1, 257, 128, -1);
-
| lib/test_printf.c:159:41: error: format specifies type 'unsigned
short'
| but the argument has type 'int' [-Werror,-Wformat]
| test("2015122420151225", "%ho%ho%#ho", 1037, 5282, -11627);
There's an ongoing movement to eventually enable the -Wformat flag for
clang. Previous patches have targeted incorrect usage of
format specifiers. In this case, however, the "incorrect" format
specifiers are intrinsically part of the test cases. Hence, fixing them
would be misaligned with their intended purpose. My proposed fix is to
simply disable the warnings so that one day a clean build of the kernel
with clang (and -Wformat enabled) would be possible. It would also keep
us in the green for alot of the CI bots.
This was the only function mentioned in the text, but was neither linked
nor documented. So document and link it, so that hyperlinking works in
the text.
tty: serial: serial_core, reformat kernel-doc for functions
There are many annotated functions in serial_core.c, but they do not
completely conform to the kernel-doc style. So reformat them and link
them from the Documentation.
Documentation: serial: move GPIO kernel-doc to the functions
The GPIO uart functions are documented in Documentation. Move and
transform this documentation into kernel-doc directly in the code and
reference it in Documentation using kernel-doc:.
This makes it easier to update, maintain and check by the build.
Documentation: serial: dedup kernel-doc for uart functions
Some of the serial (uart_*) functions are documented twice. Once as
kernel-doc along their sources and once in Documentation. So deduplicate
these texts, merge them into kernel-doc in the sources, and link them
using kernel-doc: from the Documentation.
To be properly linked and rendered, tabulators had to be removed from
the comments.
Sherry Sun [Mon, 25 Jul 2022 05:01:15 +0000 (13:01 +0800)]
tty: serial: fsl_lpuart: correct the count of break characters
The LPUART can't distinguish between a break signal and a framing error,
so need to count the break characters if there is a framing error and
received data is zero instead of the parity error.
Fixes: 5541a9bacfe5 ("serial: fsl_lpuart: handle break and make sysrq work") Reviewed-by: Michael Walle <michael@walle.cc> Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Link: https://lore.kernel.org/r/20220725050115.12396-1-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Dooks [Thu, 21 Jul 2022 21:24:30 +0000 (22:24 +0100)]
serial: stm32: make info structs static to avoid sparse warnings
The info structs are local only to the stm32-usart.c driver and are
triggering sparse warnings about being undecalred. Move these into
the main driver code and make them static to avoid the following
warnings:
drivers/tty/serial/stm32-usart.h:42:25: warning: symbol 'stm32f4_info' was not declared. Should it be static?
drivers/tty/serial/stm32-usart.h:63:25: warning: symbol 'stm32f7_info' was not declared. Should it be static?
drivers/tty/serial/stm32-usart.h:85:25: warning: symbol 'stm32h7_info' was not declared. Should it be static?
Shenwei Wang [Thu, 14 Jul 2022 18:58:58 +0000 (13:58 -0500)]
serial: fsl_lpuart: zero out parity bit in CS7 mode
The LPUART hardware doesn't zero out the parity bit on the received
characters. This behavior won't impact the use cases of CS8 because
the parity bit is the 9th bit which is not currently used by software.
But the parity bit for CS7 must be zeroed out by software in order to
get the correct raw data.
tty: serial: qcom-geni-serial: Fix get_clk_div_rate() which otherwise could return a sub-optimal clock rate.
In the logic around call to clk_round_rate(), for some corner conditions,
get_clk_div_rate() could return an sub-optimal clock rate. Also, if an
exact clock rate was not found lowest clock was being returned.
Search for suitable clock rate in 2 steps
a) exact match or within 2% tolerance
b) within 5% tolerance
This also takes care of corner conditions.
Fixes: c2194bc999d4 ("tty: serial: qcom-geni-serial: Remove uart frequency table. Instead, find suitable frequency with call to clk_round_rate") Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com> Link: https://lore.kernel.org/r/1657911343-1909-1-git-send-email-quic_vnivarth@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vincent Mailhol [Wed, 27 Jul 2022 10:16:31 +0000 (19:16 +0900)]
can: v(x)can: add software tx timestamps
TX timestamps were added to the can_put_echo_skb() function of can_dev
modules in [1]. However, vcan and vxcan do not rely on that function
and as such do not offer TX timestamping.
While it could be arguable whether TX timestamps are really needed for
virtual interfaces, we prefer to still add it so that all CAN drivers,
without exception, support the software TX timestamps.
Add a call to skb_tx_timestamp() in the vcan_tx() and vxcan_xmit()
functions so that the modules now support TX software timestamps.
Vincent Mailhol [Wed, 27 Jul 2022 10:16:30 +0000 (19:16 +0900)]
can: slcan: add software tx timestamps
TX timestamps were added to the can_put_echo_skb() function of can_dev
modules in [1]. However, slcan does not rely on that function and as
such does not offer TX timestamping.
Add a call to skb_tx_timestamp() in the slc_xmit() function so that
the module now supports TX software timestamps.
Vincent Mailhol [Wed, 27 Jul 2022 10:16:29 +0000 (19:16 +0900)]
can: janz-ican3: add software tx timestamp
TX timestamps were added to the can_put_echo_skb() function of can_dev
modules in [1]. However, janz-ican3 does not rely on that function but
instead implements its own echo_skb logic. As such it does not offer
TX timestamping.
Add a call to skb_tx_timestamp() in the ican3_put_echo_skb() function
so that the module now supports TX software timestamps.
Vincent Mailhol [Wed, 27 Jul 2022 10:16:28 +0000 (19:16 +0900)]
can: can327: add software tx timestamps
TX timestamps were added to the can_put_echo_skb() function of can_dev
modules in [1]. However, can327 does not rely on that function and as
such does not offer TX timestamping.
Add a call to skb_tx_timestamp() in the can327_netdev_start_xmit()
function so that the module now supports TX software timestamps.
With this series I try to finish the task, started with the series [1],
of completely removing the dependency of the slcan driver from the
userspace slcand/slcan_attach applications.
The series also contains patches that remove the legacy stuff (slcan_devs,
SLCAN_MAGIC, ...) and do some module cleanup.
The series has been created on top of the patches:
can: slcan: convert comments to network style comments
can: slcan: slcan_init() convert printk(LEVEL ...) to pr_level()
can: slcan: fix whitespace issues
can: slcan: convert comparison to NULL into !val
can: slcan: clean up if/else
can: slcan: use scnprintf() as a hardening measure
can: slcan: do not report txerr and rxerr during bus-off
can: slcan: do not sleep with a spin lock held
Changes since v3: https://lore.kernel.org/all/20220726210217.3368497-1-dario.binacchi@amarulasolutions.com
- Add Max Staudt's `Reviewed-by' tag.
- Drop the patch "ethtool: add support to get/set CAN bit time register".
- Drop the patch "can: slcan: add support to set bit time register (btr)".
- Remove the RFC prefix from the series.
Changes since v2: https://lore.kernel.org/all/20220725065419.3005015-1-dario.binacchi@amarulasolutions.com
- Update the commit message.
- Use 1 space in front of the =.
- Put the series as RFC again.
- Pick up the patch "can: slcan: use KBUILD_MODNAME and define pr_fmt to replace hardcoded names".
- Add the patch "ethtool: add support to get/set CAN bit time register"
to the series.
- Add the patch "can: slcan: add support to set bit time register (btr)"
to the series.
- Replace the link https://marc.info/?l=linux-can&m=165806705927851&w=2 with
https://lore.kernel.org/all/507b5973-d673-4755-3b64-b41cb9a13b6f@hartkopp.net.
- Add the `Suggested-by' tag.
Changes since RFC: https://lore.kernel.org/all/20220716170007.2020037-1-dario.binacchi@amarulasolutions.com
- Re-add headers that export at least one symbol used by the module.
- Update the commit description.
- Drop the old "slcan" name to use the standard canX interface naming.
- Remove comment on listen-only command.
- Update the commit subject and description.
- Add the patch "MAINTAINERS: Add myself as maintainer of the SLCAN driver"
to the series.
For non-legacy, i.e. ip based configuration, add support for listen-only
mode. If listen-only is requested send a listen-only ("L\r") command
instead of an open ("O\r") command to the adapter.
It is useless to define a custom function that does nothing but always
return the same error code. Better to use the generic can_change_mtu()
function.
can: slcan: change every `slc' occurrence in `slcan'
In the driver there are parts of code where the prefix `slc' is used and
others where the prefix `slcan' is used instead. The patch replaces
every occurrence of `slc' with `slcan', except for the netdev functions
where, to avoid compilation conflicts, it was necessary to replace `slc'
with `slcan_netdev'.
Taking inspiration from the drivers/net/can/can327.c driver and at the
suggestion of its author Max Staudt, I removed legacy stuff like
`SLCAN_MAGIC' and `slcan_devs' resulting in simplification of the code
and its maintainability.
The use of slcan_devs is derived from a very old kernel, since slip.c
is about 30 years old, so today's kernel allows us to remove it.
The .hangup() ldisc function, which only called the ldisc .close(), has
been removed since the ldisc layer calls .close() in a good place
anyway.
The old slcanX name has been dropped in order to use the standard canX
interface naming. The ioctl SIOCGIFNAME can be used to query the name of
the created interface. Furthermore, there are several ways to get stable
interfaces names in user space, e.g. udev or systemd-networkd.
The `maxdev' module parameter has also been removed.
Vincent Mailhol [Thu, 28 Jul 2022 07:02:48 +0000 (09:02 +0200)]
can: slcan: use KBUILD_MODNAME and define pr_fmt to replace hardcoded names
The driver uses the string "slcan" to populate
tty_ldisc_ops::name. KBUILD_MODNAME also evaluates to "slcan". Use
KBUILD_MODNAME to get rid on the hardcoded string names.
Similarly, the pr_info() and pr_err() hardcoded the "slcan"
prefix. Define pr_fmt so that the "slcan" prefix gets automatically
added.
powerpc: add support for syscall stack randomization
Add support for adding a random offset to the stack while handling
syscalls. This patch uses mftb() instead of get_random_int() for better
performance.
In order to avoid unconditional stack canaries on syscall entry (due to
the use of alloca()), also disable stack protector to avoid triggering
needless checks and slowing down the entry path. As there is no general
way to control stack protector coverage with a function attribute, this
must be disabled at the compilation unit level.
powerpc: Move system_call_exception() to syscall.c
This is a lead-up patch to enable syscall stack randomization, which
uses alloca() and makes the compiler add unconditional stack canaries
on syscall entry. In order to avoid triggering needless checks and
slowing down the entry path, the feature needs to disable stack
protector at the compilation unit level as there is no general way to
control stack protector coverage with a function attribute.
So move system_call_exception() to syscall.c to avoid affecting other
functions in interrupt.c.
powerpc/powernv: rename remaining rng powernv_ functions to pnv_
The preferred nomenclature is pnv_, not powernv_, but rng.c used
powernv_ for some reason, which isn't consistent with the rest. A recent
commit added a few pnv_ functions to rng.c, making the file a bit of a
mishmash. This commit just replaces the rest of them.
Fixes: f3eac426657d ("powerpc/powernv: wire up rng during setup_arch") Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Tested-by: Sachin Sant <sachinp@linux.ibm.com>
[mpe: Reorder after bug fix commits] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220727143219.2684192-3-mpe@ellerman.id.au
powerpc/powernv/kvm: Use darn for H_RANDOM on Power9
The existing logic in KVM to support guests calling H_RANDOM only works
on Power8, because it looks for an RNG in the device tree, but on Power9
we just use darn.
In addition the existing code needs to work in real mode, so we have the
special cased powernv_get_random_real_mode() to deal with that.
Instead just have KVM call ppc_md.get_random_seed(), and do the real
mode check inside of there, that way we use whatever RNG is available,
including darn on Power9.
Fixes: e928e9cb3601 ("KVM: PPC: Book3S HV: Add fast real-mode H_RANDOM implementation.") Cc: stable@vger.kernel.org # v4.1+ Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Tested-by: Sachin Sant <sachinp@linux.ibm.com>
[mpe: Rebase on previous commit, update change log appropriately] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220727143219.2684192-2-mpe@ellerman.id.au
Michael Ellerman [Wed, 27 Jul 2022 14:32:17 +0000 (00:32 +1000)]
powerpc/powernv: Avoid crashing if rng is NULL
On a bare-metal Power8 system that doesn't have an "ibm,power-rng", a
malicious QEMU and guest that ignore the absence of the
KVM_CAP_PPC_HWRNG flag, and calls H_RANDOM anyway, will dereference a
NULL pointer.
In practice all Power8 machines have an "ibm,power-rng", but let's not
rely on that, add a NULL check and early return in
powernv_get_random_real_mode().
Fixes: e928e9cb3601 ("KVM: PPC: Book3S HV: Add fast real-mode H_RANDOM implementation.") Cc: stable@vger.kernel.org # v4.1+ Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220727143219.2684192-1-mpe@ellerman.id.au
Rashmica Gupta [Fri, 17 Jun 2022 04:39:35 +0000 (14:39 +1000)]
selftests/powerpc: Fix matrix multiply assist test
The ISA states: "when ACC[i] contains defined data, the contents of VSRs
4×i to 4×i+3 are undefined until either a VSX Move From ACC instruction
is used to copy the contents of ACC[i] to VSRs 4×i to 4×i+3 or some other
instruction directly writes to one of these VSRs." We aren't doing this.
This test only works on Power10 because the hardware implementation
happens to map ACC0 to VSRs 0-3, but will fail on any other implementation
that doesn't do this. So add xxmfacc between writing to the accumulator
and accessing the VSRs.
Rashmica Gupta [Fri, 17 Jun 2022 04:28:05 +0000 (14:28 +1000)]
powerpc: make facility_unavailable_exception 64s
The facility unavailable exception is only available on ppc book3s
machines so use CONFIG_PPC_BOOK3S_64 rather than CONFIG_PPC64.
tm_unavailable is only called from facility_unavailable_exception so can
also be under this Kconfig symbol.
powerpc/platforms/83xx/suspend: Prevent unloading the driver
Returning an error in .remove() doesn't prevent a driver from being
unloaded. On unbind this only results in an error message, but the
device is remove anyhow.
I guess the author's idea of just returning -EPERM in .remove() was to
prevent unbinding a device. To achieve that set the suppress_bind_attrs
driver property and drop the useless .remove callback.
This is a preparation for making platform remove callbacks return void.
Pali Rohár [Wed, 4 May 2022 18:08:22 +0000 (20:08 +0200)]
powerpc/85xx: P2020: Add law_trgt_if property to PCIe DT nodes
DT law_trgt_if property defines Local Access Window Target Interface.
Local Access Window Target Interface is used for identifying individual
peripheral and mapping its memory to CPU. Interface id is defined by
hardware itself.
U-Boot uses law_trgt_if DT property in PCIe nodes for configuring memory
mapping of individual PCIe controllers.
Linux kernel fsl_pci.c driver currently does not touch Local Access Window
and expects that U-Boot configures it properly.
Add law_trgt_if property to PCIe DT nodes for P2020. This allows usage of
kernel P2020 PCIe DT nodes in U-Boot. And therefore allows to share P2020
DTS files between Linux kernel and U-Boot.
powerpc/pci: Prefer PCI domain assignment via DT 'linux,pci-domain' and alias
Other Linux architectures use DT property 'linux,pci-domain' for
specifying fixed PCI domain of PCI controller specified in Device-Tree.
And lot of Freescale powerpc boards have defined numbered pci alias in
Device-Tree for every PCIe controller which number specify preferred PCI
domain.
So prefer usage of DT property 'linux,pci-domain' (via function
of_get_pci_domain_nr()) and DT pci alias (via function
of_alias_get_id()) on powerpc architecture for assigning PCI domain to
PCI controller.
Fixes: 63a72284b159 ("powerpc/pci: Assign fixed PHB number based on device-tree properties") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220706102148.5060-2-pali@kernel.org
powerpc/pseries: define driver for Platform KeyStore
PowerVM provides an isolated Platform Keystore(PKS) storage allocation
for each LPAR with individually managed access controls to store
sensitive information securely. It provides a new set of hypervisor
calls for Linux kernel to access PKS storage.
Define POWER LPAR Platform KeyStore(PLPKS) driver using H_CALL interface
to access PKS storage.
powerpc/iommu: Fix iommu_table_in_use for a small default DMA window case
The existing iommu_table_in_use() helper checks if the kernel is using
any of TCEs. There are some reserved TCEs:
1) the very first one if DMA window starts from 0 to avoid having a zero
but still valid DMA handle;
2) it_reserved_start..it_reserved_end to exclude MMIO32 window in case
the default window spans across that - this is the default for the first
DMA window on PowerNV.
When 1) is the case and 2) is not the helper does not skip 1) and returns
wrong status.
This only seems occurring when passing through a PCI device to a nested
guest (not something we support really well) so it has not been seen
before.
This fixes the bug by adding a special case for no MMIO32 reservation.
Fixes: 3c33066a2190 ("powerpc/kernel/iommu: Add new iommu_table_in_use() helper") Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220714081119.3714605-1-aik@ozlabs.ru
pseries/iommu/ddw: Fix kdump to work in absence of ibm,dma-window
The pseries platform uses 32bit default DMA window (always 4K pages) and
optional 64bit DMA window available via DDW ("Dynamic DMA Windows"),
64K or 2M pages. For ages the default one was not removed and a huge
window was created in addition. Things changed with SRIOV-enabled
PowerVM which creates a default-and-bigger DMA window in 64bit space
(still using 4K pages) for IOV VFs so certain OSes do not need to use
the DDW API in order to utilize all available TCE budget.
Linux on the other hand removes the default window and creates a bigger
one (with more TCEs or/and a bigger page size - 64K/2M) in a bid to map
the entire RAM, and if the new window size is smaller than that - it
still uses this new bigger window. The result is that the default window
is removed but the "ibm,dma-window" property is not.
When kdump is invoked, the existing code tries reusing the existing 64bit
DMA window which location and parameters are stored in the device tree but
this fails as the new property does not make it to the kdump device tree
blob. So the code falls back to the default window which does not exist
anymore although the device tree says that it does. The result of that
is that PCI devices become unusable and cannot be used for kdumping.
This preserves the DMA64 and DIRECT64 properties in the device tree blob
for the crash kernel. Since the crash kernel setup is done after device
drivers are loaded and probed, the proper DMA config is stored at least
for boot time devices.
Because DDW window is optional and the code configures the default window
first, the existing code creates an IOMMU table descriptor for
the non-existing default DMA window. It is harmless for kdump as it does
not touch the actual window (only reads what is mapped and marks those IO
pages as used) but it is bad for kexec which clears it thinking it is
a smaller default window rather than a bigger DDW window.
This removes the "ibm,dma-window" property from the device tree after
a bigger window is created and the crash kernel setup picks it up.
Fixes: 381ceda88c4c ("powerpc/pseries/iommu: Make use of DDW for indirect mapping") Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Acked-by: Hari Bathini <hbathini@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220629060614.1680476-1-aik@ozlabs.ru
Hari Bathini [Thu, 30 Jun 2022 06:49:42 +0000 (12:19 +0530)]
powerpc/crash: save cpu register data in crash_smp_send_stop()
During kdump, two set of NMI IPIs are sent to secondary CPUs, if
'crash_kexec_post_notifiers' option is set. The first set of NMI IPIs
to stop the CPUs and the other set to collect register data. Instead,
capture register data for secondary CPUs while stopping them itself.
Also, fallback to smp_send_stop() in case the function gets called
without kdump configured.
Michael Ellerman [Wed, 27 Jul 2022 05:03:52 +0000 (15:03 +1000)]
EDAC/mpc85xx: Include required of headers directly
A subsequent commit to cleanup powerpc's asm/prom.h leads to build
errors in mpc85xx_edac.c due to missing headers. Include all required
headers directly to avoid the build failure.
Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
powerpc's asm/prom.h brings some headers that it doesn't need itself.
Once those headers are removed from asm/prom.h, the following
errors occur:
CC [M] drivers/scsi/cxlflash/ocxl_hw.o
drivers/scsi/cxlflash/ocxl_hw.c: In function 'afu_map_irq':
drivers/scsi/cxlflash/ocxl_hw.c:195:16: error: implicit declaration of function 'irq_create_mapping' [-Werror=implicit-function-declaration]
195 | virq = irq_create_mapping(NULL, irq->hwirq);
| ^~~~~~~~~~~~~~~~~~
drivers/scsi/cxlflash/ocxl_hw.c:222:9: error: implicit declaration of function 'irq_dispose_mapping' [-Werror=implicit-function-declaration]
222 | irq_dispose_mapping(virq);
| ^~~~~~~~~~~~~~~~~~~
drivers/scsi/cxlflash/ocxl_hw.c: In function 'afu_unmap_irq':
drivers/scsi/cxlflash/ocxl_hw.c:264:13: error: implicit declaration of function 'irq_find_mapping'; did you mean 'is_cow_mapping'? [-Werror=implicit-function-declaration]
264 | if (irq_find_mapping(NULL, irq->hwirq)) {
| ^~~~~~~~~~~~~~~~
| is_cow_mapping
cc1: some warnings being treated as errors
Marcin Wojtas [Tue, 26 Jul 2022 23:09:18 +0000 (01:09 +0200)]
net: dsa: mv88e6xxx: fix speed setting for CPU/DSA ports
Commit 3c783b83bd0f ("net: dsa: mv88e6xxx: get rid of SPEED_MAX setting")
stopped relying on SPEED_MAX constant and hardcoded speed settings
for the switch ports and rely on phylink configuration.
It turned out, however, that when the relevant code is called,
the mac_capabilites of CPU/DSA port remain unset.
mv88e6xxx_setup_port() is called via mv88e6xxx_setup() in
dsa_tree_setup_switches(), which precedes setting the caps in
phylink_get_caps down in the chain of dsa_tree_setup_ports().
As a result the mac_capabilites are 0 and the default speed for CPU/DSA
port is 10M at the start. To fix that, execute mv88e6xxx_get_caps()
and obtain the capabilities driectly.
Fixes: 3c783b83bd0f ("net: dsa: mv88e6xxx: get rid of SPEED_MAX setting") Signed-off-by: Marcin Wojtas <mw@semihalf.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20220726230918.2772378-1-mw@semihalf.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Thu, 28 Jul 2022 02:56:28 +0000 (19:56 -0700)]
Merge branch '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue
Tony Nguyen says:
====================
Intel Wired LAN Driver Updates 2022-07-26
This series contains updates to ice driver only.
Przemyslaw corrects accounting for VF VLANs to allow for correct number
of VLANs for untrusted VF. He also correct issue with checksum offload
on VXLAN tunnels.
Ani allows for two VSIs to share the same MAC address.
Maciej corrects checked bits for descriptor completion of loopback
* '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue:
ice: do not setup vlan for loopback VSI
ice: check (DD | EOF) bits on Rx descriptor rather than (EOP | RS)
ice: Fix VSIs unable to share unicast MAC
ice: Fix tunnel checksum offload with fragmented traffic
ice: Fix max VLANs available for VF
====================
Patrice Chotard [Wed, 29 Jun 2022 13:30:13 +0000 (15:30 +0200)]
mtd: spi-nor: fix spi_nor_spimem_setup_op() call in spi_nor_erase_{sector,chip}()
For erase operations, reg_proto must be used as indicated in
struct spi_nor description in spi-nor.h.
This issue was found when DT property spi-tx-bus-width is set to 4.
In this case the spi_mem_op->addr.buswidth is set to 4 for erase command
which is not correct.
Tested on stm32mp157c-ev1 board with mx66l51235f spi-nor.
Fixes: 0e30f47232ab ("mtd: spi-nor: add support for DTR protocol") Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
[ta: use nor->reg_proto in spi_nor_controller_ops_erase()] Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Tested-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Reviewed-by: Pratyush Yadav <p.yadav@ti.com> Link: https://lore.kernel.org/r/20220629133013.3382393-1-patrice.chotard@foss.st.com
mtd: spi-nor: spansion: Add s25hl-t/s25hs-t IDs and fixups
The S25HL-T/S25HS-T family is the Infineon SEMPER Flash with Quad SPI.
These Infineon chips support volatile version of configuration registers
and it is recommended to update volatile registers in the field application
due to a risk of the non-volatile registers corruption by power interrupt.
Add support for volatile QE bit.
For the single-die package parts (512Mb and 1Gb), only bottom 4KB and
uniform sector sizes are supported. This is due to missing or incorrect
entries in SMPT. Fixup for other sector sizes configurations will be
followed up as needed.
We need to track the flash's internal address mode as there are flashes
that can operate with 4B opcodes but unfortunately do not have a 4B opcode
correspondent for all the 3B opcodes. Such an example is the Infineon
Semper chips which provide 4B opcodes for read/program/erase but do not
provide 4B opcodes for Read/Write Any Register. These registers are
indexed by address and require the internal address mode of the flash
before Read/Write Any Register opcodes are issued.
4B opcodes are preferred over changing the flash's address mode to 4byte,
as set_4byte_addr_mode could be done in a non-volatile way and could break
the boot sequence. Thus we need to track the flash's internal address mode
so that we can use 4B opcodes together with opcodes that don't have a 4B
opcode correspondent. Track flash's internal address mode.
addr_mode_nbytes is discovered when parsing BFPT. For the
BFPT_DWORD1_ADDRESS_BYTES_3_OR_4 case, one could introduce a method that
queries the flash's internal address mode at run-time (works for Winbond).
If a run-time querying can not be accomplished or if SFDP is not defined
at all, but the address mode is volatile and resets to a default known
value at boot, one can change the default addr_mode_nbytes value of 3 by
introducing a flash_info flag. If the address mode can not be queried,
discovered and it is configured via a non-volatile register, we may
introduce a dt property, but it will harm the generic approach of the
jedec,spi-nor compatible. All this complexity is not needed now, so let it
for future development.
mtd: spi-nor: Do not change nor->addr_nbytes at SFDP parsing time
At the SFDP parsing time we should not change members of struct spi_nor,
but instead fill members of struct spi_nor_flash_parameters which could
later on be used by callers. The caller will then decide if SFDP params
should be used and more importantly when they should be used. Clean the
code flow and don't initialize nor->addr_nbytes at SFDP parsing time.
Address width was an unfortunate name, as it means the number of IO lines
used for the address, whereas in the code it is used as the number of
address bytes. s/addr_width/addr_nbytes throughout the entire SPI NOR
framework.
This happens when calling sctp_sendmsg without connecting to server first.
In this case, a data chunk already queues up in send queue of client side
when processing the INIT_ACK from server in sctp_process_init() where it
calls sctp_stream_init() to alloc stream_in. If it fails to alloc stream_in
all stream_out will be freed in sctp_stream_init's err path. Then in the
asoc freeing it will crash when dequeuing this data chunk as stream_out
is missing.
As we can't free stream out before dequeuing all data from send queue, and
this patch is to fix it by moving the err path stream_out/in freeing in
sctp_stream_init() to sctp_stream_free() which is eventually called when
freeing the asoc in sctp_association_free(). This fix also makes the code
in sctp_process_init() more clear.
Note that in sctp_association_init() when it fails in sctp_stream_init(),
sctp_association_free() will not be called, and in that case it should
go to 'stream_free' err path to free stream instead of 'fail_init'.
Sending a PTP packet can imply to use the normal TX driver datapath but
invoked from the driver's ptp worker. The kernel generic TX code
disables softirqs and preemption before calling specific driver TX code,
but the ptp worker does not. Although current ptp driver functionality
does not require it, there are several reasons for doing so:
1) The invoked code is always executed with softirqs disabled for non
PTP packets.
2) Better if a ptp packet transmission is not interrupted by softirq
handling which could lead to high latencies.
3) netdev_xmit_more used by the TX code requires preemption to be
disabled.
Indeed a solution for dealing with kernel preemption state based on static
kernel configuration is not possible since the introduction of dynamic
preemption level configuration at boot time using the static calls
functionality.
Mark Brown [Thu, 28 Jul 2022 00:21:40 +0000 (01:21 +0100)]
ASoC: atmel: one fix and one cleanup
Merge series from Claudiu Beznea <claudiu.beznea@microchip.com>:
Hi,
The series adds one fix for mchp-spdifrx and one cleanups for
mchp-spdifrx and mchp-spdifrx drivers.
Thank you,
Claudiu Beznea
Changes in v3:
- changed cover letter title s/few/one, s/cleanups/cleanup
- fix compilation error and warnings
- keep only patch 1/5 and patch 3/5 from previous version as the rest
of them were integrated
Changes in v2:
- s/tag/tab in the title of patch 2/5
Claudiu Beznea (2):
ASoC: mchp-spdifrx: disable end of block interrupt on failures
ASoC: mchp-spdiftx: remove references to mchp_i2s_caps
Mark Brown [Wed, 27 Jul 2022 23:01:30 +0000 (00:01 +0100)]
regulator: Consumer load management improvements
Merge series from Douglas Anderson <dianders@chromium.org>:
The main goal of this series is to make a small dent in cleaning up
the way we deal with regulator loads. The idea is to add some extra
functionality to the regulator "bulk" API so that consumers can
specify the load using that.
exec: Call kmap_local_page() in copy_string_kernel()
The use of kmap_atomic() is being deprecated in favor of kmap_local_page().
With kmap_local_page(), the mappings are per thread, CPU local and not
globally visible. Furthermore, the mappings can be acquired from any
context (including interrupts).
Therefore, replace kmap_atomic() with kmap_local_page() in
copy_string_kernel(). Instead of open-coding local mapping + memcpy(),
use memcpy_to_page(). Delete a redundant call to flush_dcache_page().
Tested with xfstests on a QEMU/ KVM x86_32 VM, 6GB RAM, booting a kernel
with HIGHMEM64GB enabled.
media: hantro: Remove dedicated control documentation
The dedicated control required by the HEVC support
was removed, and the driver now calculates the value
internally. Remove the ad-hoc documentation as well.
[hverkuil: remove hantro from Documentation/userspace-api/media/drivers/index.rst]
Kees Cook [Wed, 8 Jun 2022 21:40:24 +0000 (14:40 -0700)]
kasan: test: Silence GCC 12 warnings
GCC 12 continues to get smarter about array accesses. The KASAN tests
are expecting to explicitly test out-of-bounds conditions at run-time,
so hide the variable from GCC, to avoid warnings like:
../lib/test_kasan.c: In function 'ksize_uaf':
../lib/test_kasan.c:790:61: warning: array subscript 120 is outside array bounds of 'void[120]' [-Warray-bounds]
790 | KUNIT_EXPECT_KASAN_FAIL(test, ((volatile char *)ptr)[size]);
| ~~~~~~~~~~~~~~~~~~~~~~^~~~~~
../lib/test_kasan.c:97:9: note: in definition of macro 'KUNIT_EXPECT_KASAN_FAIL'
97 | expression; \
| ^~~~~~~~~~
SUNRPC: Don't reuse bvec on retransmission of the request
If a request is re-encoded and then retransmitted, we need to make sure
that we also re-encode the bvec, in case the page lists have changed.
Fixes: ff053dbbaffe ("SUNRPC: Move the call to xprt_send_pagedata() out of xprt_sock_sendmsg()") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Instead of listing directly properties typical for SPI peripherals,
reference the spi-peripheral-props.yaml schema. This allows using all
properties typical for SPI-connected devices, even these which device
bindings author did not tried yet.
Remove the spi-* properties which now come via spi-peripheral-props.yaml
schema, except for the cases when device schema adds some constraints
like maximum frequency.
While changing additionalProperties->unevaluatedProperties, put it in
typical place, just before example DTS.
Josef Bacik [Mon, 25 Jul 2022 17:05:05 +0000 (13:05 -0400)]
btrfs: reset RO counter on block group if we fail to relocate
With the automatic block group reclaim code we will preemptively try to
mark the block group RO before we start the relocation. We do this to
make sure we should actually try to relocate the block group.
However if we hit an error during the actual relocation we won't clean
up our RO counter and the block group will remain RO. This was observed
internally with file systems reporting less space available from df when
we had failed background relocations.
Fix this by doing the dec_ro in the error case.
Fixes: 18bb8bbf13c1 ("btrfs: zoned: automatically reclaim zones") CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Boris Burkov <boris@bur.io> Signed-off-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: David Sterba <dsterba@suse.com>
Sakari Ailus [Mon, 11 Jul 2022 11:26:06 +0000 (14:26 +0300)]
ACPI: property: Read buffer properties as integers
Instead of adding a new property type, read buffer properties as integers.
Even though the internal representation in ACPI is different, the data
type is the same (byte) than on 8-bit integers.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Sakari Ailus [Mon, 11 Jul 2022 11:26:03 +0000 (14:26 +0300)]
ACPI: property: Switch node property referencing from ifs to a switch
__acpi_node_get_property_reference() uses a series of if () statements for
testing the same variable. There's soon going to be one more value to be
tested.
Switch to use switch() instead.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Sakari Ailus [Mon, 11 Jul 2022 11:26:02 +0000 (14:26 +0300)]
ACPI: property: Move property ref argument parsing into a new function
Split out property reference argument parsing out of the
__acpi_node_get_property_reference() function into a new one,
acpi_get_ref_args(). The new function will be needed also for parsing
string references soon.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Sakari Ailus [Mon, 11 Jul 2022 11:26:01 +0000 (14:26 +0300)]
ACPI: property: Use acpi_object_type consistently in property ref parsing
The type of union acpi_object field type is acpi_object_type. Use that
instead of int.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Sakari Ailus [Mon, 11 Jul 2022 11:26:00 +0000 (14:26 +0300)]
ACPI: property: Tie data nodes to acpi handles
ACPICA allows associating additional information (i.e. pointers with
specific tag) to acpi_handles. The acpi_device's are associated to
acpi_handle's in acpi_tie_acpi_dev() in scan.c, do the same here for the
_DSD data nodes.
This allows direct data node references in properties, implemented later on
in the series.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Sakari Ailus [Mon, 11 Jul 2022 11:25:59 +0000 (14:25 +0300)]
ACPI: property: Return type of acpi_add_nondev_subnodes() should be bool
The value acpi_add_nondev_subnodes() returns is bool so change the return
type of the function to match that.
Fixes: 445b0eb058f5 ("ACPI / property: Add support for data-only subnodes") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
When building with Clang we encounter the following warning
(ARCH=hexagon + CONFIG_FRAME_WARN=0):
| ../drivers/misc/lkdtm/bugs.c:107:3: error: format specifies type
| 'unsigned long' but the argument has type 'int' [-Werror,-Wformat]
| REC_STACK_SIZE, recur_count);
| ^~~~~~~~~~~~~~
Cast REC_STACK_SIZE to `unsigned long` to match format specifier `%lu`
as well as maintain symmetry with `#define REC_STACK_SIZE
(_AC(CONFIG_FRAME_WARN, UL) / 2)`.
YiFei Zhu [Thu, 26 May 2022 22:34:07 +0000 (22:34 +0000)]
selftests/seccomp: Fix compile warning when CC=clang
clang has -Wconstant-conversion by default, and the constant 0xAAAAAAAAA
(9 As) being converted to an int, which is generally 32 bits, results
in the compile warning:
clang -Wl,-no-as-needed -Wall -isystem ../../../../usr/include/ -lpthread seccomp_bpf.c -lcap -o seccomp_bpf
seccomp_bpf.c:812:67: warning: implicit conversion from 'long' to 'int' changes value from 45812984490 to -1431655766 [-Wconstant-conversion]
int kill = kill_how == KILL_PROCESS ? SECCOMP_RET_KILL_PROCESS : 0xAAAAAAAAA;
~~~~ ^~~~~~~~~~~
1 warning generated.
-1431655766 is the expected truncation, 0xAAAAAAAA (8 As), so use
this directly in the code to avoid the warning.