| Age | Commit message (Collapse) | Author |
|---|
|
Replace a pipeline of echo and sed with printf to decrease process forks.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
|
|
These two files are very similar. Unify them.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Mickaël Salaün <mic@linux.microsoft.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
|
|
This script is only used in certs/Makefile, so certs/ is a better
home for it.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Mickaël Salaün <mic@linux.microsoft.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
|
|
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.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/all/202207240252.ZY5hSCNB-lkp@intel.com/
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Chenglin Xu <chenglin.xu@mediatek.com>
Link: https://lore.kernel.org/r/20220727132637.76d6073f@endymion.delvare
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
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.
Bug report: https://www.spinics.net/lists/alsa-devel/msg145609.html
This is a semi-automatic email about new static checker warnings.
The patch ae92dcbee8b6: "ASoC: mediatek: mt8186: support tdm in
platform driver" from May 23, 2022, leads to the following Smatch
complaint:
sound/soc/mediatek/mt8186/mt8186-dai-tdm.c:424 mtk_dai_tdm_hw_params()
warn: variable dereferenced before check 'tdm_priv' (see line 406)
sound/soc/mediatek/mt8186/mt8186-dai-tdm.c
405 struct mtk_afe_tdm_priv *tdm_priv = afe_priv->dai_priv[tdm_id];
406 unsigned int tdm_mode = tdm_priv->tdm_mode;
^^^^^^^^^^^^^^^^^^^
Lot's of dereferences
407 unsigned int data_mode = tdm_priv->data_mode;
408 unsigned int rate = params_rate(params);
409 unsigned int channels = params_channels(params);
410 snd_pcm_format_t format = params_format(params);
411 unsigned int bit_width =
412 snd_pcm_format_physical_width(format);
413 unsigned int tdm_channels = (data_mode == TDM_DATA_ONE_PIN) ?
414 get_tdm_ch_per_sdata(tdm_mode, channels) : 2;
415 unsigned int lrck_width =
416 get_tdm_lrck_width(format, tdm_mode);
417 unsigned int tdm_con = 0;
418 bool slave_mode = tdm_priv->slave_mode;
419 bool lrck_inv = tdm_priv->lck_invert;
420 bool bck_inv = tdm_priv->bck_invert;
421 unsigned int tran_rate;
422 unsigned int tran_relatch_rate;
423
424 if (!tdm_priv) {
^^^^^^^^^
Checked too late
425 dev_err(afe->dev, "%s(), tdm_priv == NULL", __func__);
426 return -EINVAL;
Fixes: ae92dcbee8b6 ("ASoC: mediatek: mt8186: support tdm in platform driver")
Signed-off-by: Jiaxin Yu <jiaxin.yu@mediatek.com>
Link: https://lore.kernel.org/r/20220726154220.28141-1-jiaxin.yu@mediatek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This one is unused since
181b6f40e9ea ("x86/microcode: Rip out the OLD_INTERFACE")
so comment it out.
Link: https://lore.kernel.org/r/20220525161232.14924-1-bp@alien8.de
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20220727114948.30123-1-bp@alien8.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
IBS support has been enhanced with two new features in upcoming uarch:
1. DataSrc extension and
2. L3 miss filtering.
Additional set of bits has been introduced in IBS registers to use these
features. Define these new bits into arch/x86/ header.
[ bp: Massage commit message. ]
Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20220604044519.594-7-ravi.bangoria@amd.com
|
|
With GCC 12, corenet64_smp_defconfig leads to the following build errors:
CC arch/powerpc/kernel/irq.o
{standard input}: Assembler messages:
{standard input}:3616: Error: unrecognized opcode: `wrteei'
{standard input}:5689: Error: unrecognized opcode: `wrteei'
CC arch/powerpc/kernel/pmc.o
{standard input}: Assembler messages:
{standard input}:42: Error: unrecognized opcode: `mfpmr'
{standard input}:53: Error: unrecognized opcode: `mtpmr'
CC arch/powerpc/kernel/io.o
{standard input}: Assembler messages:
{standard input}:376: Error: unrecognized opcode: `mbar'
...
CC arch/powerpc/mm/nohash/book3e_hugetlbpage.o
{standard input}: Assembler messages:
{standard input}:291: Error: unrecognized opcode: `tlbsx'
{standard input}:482: Error: unrecognized opcode: `tlbwe'
{standard input}:608: Error: unrecognized opcode: `lbarx'
{standard input}:608: Error: unrecognized opcode: `stbcx.'
-mpcu=powerpc64 cannot be used anymore for book3e, it must be a booke CPU.
But then we get:
CC arch/powerpc/lib/xor_vmx.o
cc1: error: AltiVec not supported in this target
Altivec is not supported with -mcpu=e5500 so don't allow selection
of altivec when e5500 is selected.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/77255a5a957967723b84d0356d9e5fb21569f4e8.1657549153.git.christophe.leroy@csgroup.eu
|
|
Building ppc40x_defconfig leads to following error
CC arch/powerpc/kernel/idle.o
{standard input}: Assembler messages:
{standard input}:67: Error: unrecognized opcode: `wrteei'
{standard input}:78: Error: unrecognized opcode: `wrteei'
Add -mcpu=440 by default and alternatively 464 and 476.
Once that's done, -mcpu=powerpc is only for book3s/32 now.
But then comes
CC arch/powerpc/kernel/io.o
{standard input}: Assembler messages:
{standard input}:198: Error: unrecognized opcode: `eieio'
{standard input}:230: Error: unrecognized opcode: `eieio'
{standard input}:245: Error: unrecognized opcode: `eieio'
{standard input}:254: Error: unrecognized opcode: `eieio'
{standard input}:273: Error: unrecognized opcode: `eieio'
{standard input}:396: Error: unrecognized opcode: `eieio'
{standard input}:404: Error: unrecognized opcode: `eieio'
{standard input}:423: Error: unrecognized opcode: `eieio'
{standard input}:512: Error: unrecognized opcode: `eieio'
{standard input}:520: Error: unrecognized opcode: `eieio'
{standard input}:539: Error: unrecognized opcode: `eieio'
{standard input}:628: Error: unrecognized opcode: `eieio'
{standard input}:636: Error: unrecognized opcode: `eieio'
{standard input}:655: Error: unrecognized opcode: `eieio'
Fix it by replacing eieio by mbar on booke.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/b0d982e223314ed82ab959f5d4ad2c4c00bedb99.1657549153.git.christophe.leroy@csgroup.eu
|
|
Building ppc40x_defconfig leads to following error
CC arch/powerpc/kernel/process.o
{standard input}: Assembler messages:
{standard input}:626: Error: unrecognized opcode: `wrteei'
Add -mcpu=405 by default.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/d344a42c99061cfe10a28e00de4e31a1363f4251.1657549153.git.christophe.leroy@csgroup.eu
|
|
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.
Reported-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Tested-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/d4df724691351531bf46d685d654689e5dfa0d74.1657549153.git.christophe.leroy@csgroup.eu
|
|
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.
Fixes: 0e00a8c9fd92 ("powerpc: Allow CPU selection also on PPC32")
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/8abab4888da69ff78b73a56f64d9678a7bf684e9.1657549153.git.christophe.leroy@csgroup.eu
|
|
We have PPC_INST_SETB then build the 'setb' instruction in the
user.
Instead, define PPC_RAW_SETB() and use it.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/b08a4f26919a8f8cdcf7544ab552d9c1c63418b5.1657205708.git.christophe.leroy@csgroup.eu
|
|
Add and use PPC_RAW_TRAP() instead of opencoding.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/52c7e522e56a38e3ff0363906919445920005a8f.1657205708.git.christophe.leroy@csgroup.eu
|
|
ppc_opcode_t is just an u32. There is no point in hiding u32
behind such a typedef. Remove it.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/b2d762191b095530789ac8b71b167c6740bb6aed.1657205708.git.christophe.leroy@csgroup.eu
|
|
Commit 9850b6c69356 ("arch: powerpc: Remove oprofile") removed
oprofile.
Remove all remaining parts of it.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/298432fe1a14c0a415760011d72c3f0999efd5e2.1657204631.git.christophe.leroy@csgroup.eu
|
|
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.
Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Reviewed-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
[chleroy: Added power10 and fixed checkpatch issues]
Reviewed-and-tested-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Reviewed-and-tested-By: Kajol Jain <kjain@linux.ibm.com> [For 24x7 side changes]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20c0ee7f99dbf0dbf8658df6b39f84753e6db1ef.1657204631.git.christophe.leroy@csgroup.eu
|
|
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().
Fixes: 4291d085b0b0 ("powerpc/32s: Make pte_update() non atomic on 603 core")
Reported-by: Erhard Furtner <erhard_f@mailbox.org>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/2ee707512b8b212b079b877f4ceb525a1606a3fb.1656655567.git.christophe.leroy@csgroup.eu
|
|
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")
Reported-by: Maxime Bizon <mbizon@freebox.fr>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/ce7f04a39593934d9b1ee68c69144ccd3d4da4a1.1655202804.git.christophe.leroy@csgroup.eu
|
|
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.
Fixes: da1adea07576 ("powerpc/8xx: Allow STRICT_KERNEL_RwX with pinned TLB")
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/db3fc14f3bfa6215b0786ef58a6e2bc1e1f964d7.1655202804.git.christophe.leroy@csgroup.eu
|
|
cpu_to_node() is not yet available (setup_arch() is called before
setup_per_cpu_areas() by start_kernel()).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220711030653.150950-1-npiggin@gmail.com
|
|
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.
Remove it and replace with a comment.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220525022358.780745-4-npiggin@gmail.com
|
|
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."
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220525022358.780745-3-npiggin@gmail.com
|
|
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.
Skip the workaround on POWER10 and later.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220525022358.780745-2-npiggin@gmail.com
|
|
Take the arm64 HWCAP documentation file and adjust it for powerpc.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
[mpe: Fix ARCH_2_05 comment, as noticed by Tulio.]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220715012636.165948-1-npiggin@gmail.com
|
|
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.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220520123649.258440-1-npiggin@gmail.com
|
|
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.
Signed-off-by: Pali Rohár <pali@kernel.org>
[mpe: Minor change log wording]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220706104308.5390-6-pali@kernel.org
|
|
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.
[1] - https://lore.kernel.org/linuxppc-dev/1148016268.13249.14.camel@localhost.localdomain/
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220706104308.5390-5-pali@kernel.org
|
|
Function pci_create_OF_bus_map() is used only in chrp code.
So hide it from all other platforms.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220706104308.5390-4-pali@kernel.org
|
|
Function pcibios_make_OF_bus_map() is used only in pci_32.c. So make it
static.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220706104308.5390-3-pali@kernel.org
|
|
Function pci_device_from_OF_node() is used only in powermac code. So
hide it from all other platforms.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220706104308.5390-2-pali@kernel.org
|
|
CPLD firmware can reset board by writing value 0x01 at CPLD memory offset
0x0d. Define syscon-reboot node for this reset support.
Fixes: 54c15ec3b738 ("powerpc: dts: Add DTS file for CZ.NIC Turris 1.x routers")
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220713134429.18748-1-pali@kernel.org
|
|
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.
With this change lspci -b output is:
$ lspci -bvnn
00:00.0 PCI bridge [0604]: Freescale Semiconductor Inc P2020E [1957:0070] (rev 21) (prog-if 00 [Normal decode])
Capabilities: [4c] Express Root Port (Slot-), MSI 00
Without any "Invalid class" error. So class code was properly reflected
into standard (read-only) PCI register 0x08.
Same fix is already implemented in U-Boot pcie_fsl.c driver in commit:
http://source.denx.de/u-boot/u-boot/-/commit/d18d06ac35229345a0af80977a408cfbe1d1015b
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.
Cc: stable@vger.kernel.org
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220706101043.4867-1-pali@kernel.org
|
|
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).
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220725015619.618070-1-masahiroy@kernel.org
|
|
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.
Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220713154729.80789-5-ldufour@linux.ibm.com
|
|
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.
Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220713154729.80789-4-ldufour@linux.ibm.com
|
|
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.
Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
[mpe: Squash in build fix from Laurent, reported by Sachin]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220713154729.80789-3-ldufour@linux.ibm.com
|
|
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.
====================
Link: https://lore.kernel.org/all/20220727104939.279022-1-mailhol.vincent@wanadoo.fr
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
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.
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Link: https://lore.kernel.org/all/20220727104939.279022-4-mailhol.vincent@wanadoo.fr
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
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.
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Link: https://lore.kernel.org/all/20220727104939.279022-3-mailhol.vincent@wanadoo.fr
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
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.
This patch reduces the footprint by 14 bytes:
| $ ./scripts/bloat-o-meter drivers/net/can/slcan/slcan.{old,new}.o
| drivers/net/can/slcan/slcan.o
| add/remove: 0/1 grow/shrink: 1/0 up/down: 15/-29 (-14)
| Function old new delta
| slcan_open 1010 1025 +15
| slcan_set_ethtool_ops 29 - -29
| Total: Before=11115, After=11101, chg -0.13%
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Link: https://lore.kernel.org/all/20220727104939.279022-2-mailhol.vincent@wanadoo.fr
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
Remove duplicate 'in'.
Change 'entrys' to 'entries'.
Signed-off-by: Zhang Jiaming <jiaming@nfschina.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220622082524.21304-1-jiaming@nfschina.com
|
|
Remove references to struct mchp_i2s_caps as they are not used.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/20220727090814.2446111-3-claudiu.beznea@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
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.
Fixes: ef265c55c1ac ("ASoC: mchp-spdifrx: add driver for SPDIF RX")
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/20220727090814.2446111-2-claudiu.beznea@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The double `the' is duplicated in line 1540, remove one.
Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220715050053.24382-1-wangborong@cdjrlc.com
Link: https://lore.kernel.org/r/20220722083031.74847-1-slark_xiao@163.com
Link: https://lore.kernel.org/r/20220722084158.75647-1-slark_xiao@163.com
Link: https://lore.kernel.org/r/20220722084833.76159-1-slark_xiao@163.com
|
|
time_after deals with timer wrapping correctly.
Signed-off-by: Li Qiong <liqiong@nfschina.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220606135449.23256-1-liqiong@nfschina.com
Link: https://lore.kernel.org/r/20220618131305.13101-1-wangxiang@cdjrlc.com
Link: https://lore.kernel.org/r/20220715050016.24164-1-wangborong@cdjrlc.com
|
|
After successfull station association, if station queues are disabled for
some reason, the related lists are not emptied. So if some new element is
added to the list in iwl_mvm_mac_wake_tx_queue, it can match with the old
one and produce a BUG like this:
[ 46.535263] list_add corruption. prev->next should be next (ffff94c1c318a360), but was 0000000000000000. (prev=ffff94c1d02d3388).
[ 46.535283] ------------[ cut here ]------------
[ 46.535284] kernel BUG at lib/list_debug.c:26!
[ 46.535290] invalid opcode: 0000 [#1] PREEMPT SMP PTI
[ 46.585304] CPU: 0 PID: 623 Comm: wpa_supplicant Not tainted 5.19.0-rc3+ #1
[ 46.592380] Hardware name: Dell Inc. Inspiron 660s/0478VN , BIOS A07 08/24/2012
[ 46.600336] RIP: 0010:__list_add_valid.cold+0x3d/0x3f
[ 46.605475] Code: f2 4c 89 c1 48 89 fe 48 c7 c7 c8 40 67 93 e8 20 cc fd ff 0f 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 70 40 67 93 e8 09 cc fd ff <0f> 0b 48 89 fe 48 c7 c7 00 41 67 93 e8 f8 cb fd ff 0f 0b 48 89 d1
[ 46.624469] RSP: 0018:ffffb20800ab76d8 EFLAGS: 00010286
[ 46.629854] RAX: 0000000000000075 RBX: ffff94c1c318a0e0 RCX: 0000000000000000
[ 46.637105] RDX: 0000000000000201 RSI: ffffffff9365e100 RDI: 00000000ffffffff
[ 46.644356] RBP: ffff94c1c5f43370 R08: 0000000000000075 R09: 3064316334396666
[ 46.651607] R10: 3364323064316334 R11: 39666666663d7665 R12: ffff94c1c5f43388
[ 46.658857] R13: ffff94c1d02d3388 R14: ffff94c1c318a360 R15: ffff94c1cf2289c0
[ 46.666108] FS: 00007f65634ff7c0(0000) GS:ffff94c1da200000(0000) knlGS:0000000000000000
[ 46.674331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 46.680170] CR2: 00007f7dfe984460 CR3: 000000010e894003 CR4: 00000000000606f0
[ 46.687422] Call Trace:
[ 46.689906] <TASK>
[ 46.691950] iwl_mvm_mac_wake_tx_queue+0xec/0x15c [iwlmvm]
[ 46.697601] ieee80211_queue_skb+0x4b3/0x720 [mac80211]
[ 46.702973] ? sta_info_get+0x46/0x60 [mac80211]
[ 46.707703] ieee80211_tx+0xad/0x110 [mac80211]
[ 46.712355] __ieee80211_tx_skb_tid_band+0x71/0x90 [mac80211]
...
In order to avoid this problem, we must also remove the related lists when
station queues are disabled.
Fixes: cfbc6c4c5b91c ("iwlwifi: mvm: support mac80211 TXQs model")
Reported-by: Takayuki Nagata <tnagata@redhat.com>
Reported-by: Petr Stourac <pstourac@redhat.com>
Tested-by: Petr Stourac <pstourac@redhat.com>
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220719153542.81466-1-jtornosm@redhat.com
|
|
When building with Clang we encounter these warnings:
| drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c:1108:47: error:
| format specifies type 'unsigned char' but the argument has type 's16'
| (aka 'short') [-Werror,-Wformat] IWL_DEBUG_INFO(mvm, "\tburst index:
| %hhu\n", res->ftm.burst_index);
-
| drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c:1111:47: error:
| format specifies type 'unsigned char' but the argument has type 's32'
| (aka 'int') [-Werror,-Wformat] IWL_DEBUG_INFO(mvm, "\trssi spread:
| %hhu\n", res->ftm.rssi_spread);
The previous format specifier `%hhu` describes a u8 but our arguments
are wider than this which means bits are potentially being lost.
Variadic functions (printf-like) undergo default argument promotion.
Documentation/core-api/printk-formats.rst specifically recommends using
the promoted-to-type's format flag.
As per C11 6.3.1.1:
(https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf) `If an int
can represent all values of the original type ..., the value is
converted to an int; otherwise, it is converted to an unsigned int.
These are called the integer promotions.` Thus it makes sense to change
`%hhu` to `%d` for both instances of the warning.
Link: https://github.com/ClangBuiltLinux/linux/issues/378
Signed-off-by: Justin Stitt <justinstitt@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220711222919.2043613-1-justinstitt@google.com
|
|
Commit 7a4836560a61 changes simple_write_to_buffer() with memdup_user()
but it forgets to change the value to be returned that came from
simple_write_to_buffer() call. It results in the following warning:
warning: variable 'rc' is uninitialized when used here [-Wuninitialized]
return rc;
^~
Remove rc variable and just return the passed in length if the
memdup_user() succeeds.
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Reported-by: kernel test robot <lkp@intel.com>
Fixes: 7a4836560a6198d245d5732e26f94898b12eb760 ("wifi: wil6210: debugfs: fix info leak in wil_write_file_wmi()")
Fixes: ff974e4083341383d3dd4079e52ed30f57f376f0 ("wil6210: debugfs interface to send raw WMI command")
Signed-off-by: Ammar Faizi <ammarfaizi2@gnuweeb.org>
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220724202452.61846-1-ammar.faizi@intel.com
|
|
This reverts commit ec038c6127fa772d2c5604e329f22371830d5fa6. Tyler reported
that on L390 Yoga Thinkpad with QCA6390 the suspend was failing because of this commit.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.9
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215881
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220708164656.29549-1-kvalo@kernel.org
|
