Instead of the magic numbers 1<<11 and 1<<12 use the constants
from msr-index.h. This makes it obvious where those bits
of MSR_IA32_MISC_ENABLE are consumed (and in fact that Linux
consumes them at all) to simple minds that grep for
MSR_IA32_MISC_ENABLE_.*_UNAVAIL.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20220719174714.2410374-1-pbonzini@redhat.com
The comment says this should be GENMASK_ULL(47, 12), so do that!
GENMASK_ULL() is available in assembly since:
95b980d62d ("linux/bits.h: make BIT(), GENMASK(), and friends available in assembly")
Signed-off-by: Joey Gouly <joey.gouly@arm.com>
Link: https://lore.kernel.org/all/20171221164851.edxq536yobjuagwe@armageddon.cambridge.arm.com/
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Kristina Martsenko <kristina.martsenko@arm.com>
Reviewed-by: Kristina Martsenko <kristina.martsenko@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20220708140056.10123-1-joey.gouly@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Cortex-A57 and Cortex-A72 have an erratum where an interrupt that
occurs between a pair of AES instructions in aarch32 mode may corrupt
the ELR. The task will subsequently produce the wrong AES result.
The AES instructions are part of the cryptographic extensions, which are
optional. User-space software will detect the support for these
instructions from the hwcaps. If the platform doesn't support these
instructions a software implementation should be used.
Remove the hwcap bits on affected parts to indicate user-space should
not use the AES instructions.
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20220714161523.279570-3-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
When the NUMA nodes are sorted by checking ACPI SRAT (GICC AFFINITY)
sub-table, it's impossible for acpi_map_pxm_to_node() to return
any value, which is greater than or equal to MAX_NUMNODES. Lets drop
the unnecessary check in acpi_numa_gicc_affinity_init().
No functional change intended.
Signed-off-by: Gavin Shan <gshan@redhat.com>
Link: https://lore.kernel.org/r/20220718064232.3464373-1-gshan@redhat.com
Signed-off-by: Will Deacon <will@kernel.org>
The flags for KVM_CAP_X86_USER_SPACE_MSR and KVM_X86_SET_MSR_FILTER
have no protection for their unused bits. Without protection, future
development for these features will be difficult. Add the protection
needed to make it possible to extend these features in the future.
Signed-off-by: Aaron Lewis <aaronlewis@google.com>
Message-Id: <20220714161314.1715227-1-aaronlewis@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
When a CPU enters an idle state, a non-initialized AMX register state may
be the cause of preventing a deeper low-power state. Other extended
register states whether initialized or not do not impact the CPU idle
state.
The new helper can ensure the AMX state is initialized before the CPU is
idle, and it will be used by the intel idle driver.
Check the AMX_TILE feature bit before using XGETBV1 as a chain of
dependencies was established via cpuid_deps[]: AMX->XFD->XGETBV1.
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20220608164748.11864-2-chang.seok.bae@intel.com
Commit aa44284960 ("x86/mm/tlb: Avoid reading mm_tlb_gen when
possible") introduced an optimization to skip superfluous TLB
flushes based on the generation provided in flush_tlb_info.
However, arch_tlbbatch_flush() does not provide any generation in
flush_tlb_info and populates the flush_tlb_info generation with
0. This 0 is causes the flush_tlb_info to be interpreted as a
superfluous, old flush. As a result, try_to_unmap_one() would
not perform any TLB flushes.
Fix it by checking whether f->new_tlb_gen is nonzero. Zero value
is anyhow is an invalid generation value. To avoid future
confusion, introduce TLB_GENERATION_INVALID constant and use it
properly. Add warnings to ensure no partial flushes are done with
TLB_GENERATION_INVALID or when f->mm is NULL, since this does not
make any sense.
In addition, add the missing unlikely().
[ dhansen: change VM_BUG_ON() -> VM_WARN_ON(), clarify changelog ]
Fixes: aa44284960 ("x86/mm/tlb: Avoid reading mm_tlb_gen when possible")
Reported-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Nadav Amit <namit@vmware.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Tested-by: Hugh Dickins <hughd@google.com>
Link: https://lkml.kernel.org/r/20220710232837.3618-1-namit@vmware.com
Merge the new SoC support from Tomer Maimon:
"This patchset adds initial support for the Nuvoton
Arbel NPCM8XX Board Management controller (BMC) SoC family.
The Nuvoton Arbel NPCM8XX SoC is a fourth-generation BMC.
The NPCM8XX computing subsystem comprises a quadcore ARM
Cortex A35 ARM-V8 architecture.
This patchset adds minimal architecture and drivers such as:
Clocksource, Clock, Reset, and WD.
Some of the Arbel NPCM8XX peripherals are based on Poleg NPCM7XX.
This patchset was tested on the Arbel NPCM8XX evaluation board."
I'm leaving out the clk controller driver, which is still under
review.
* nuvoton/newsoc:
arm64: defconfig: Add Nuvoton NPCM family support
arm64: dts: nuvoton: Add initial NPCM845 EVB device tree
arm64: dts: nuvoton: Add initial NPCM8XX device tree
arm64: npcm: Add support for Nuvoton NPCM8XX BMC SoC
dt-bindings: arm: npcm: Add nuvoton,npcm845 GCR compatible string
dt-bindings: arm: npcm: Add nuvoton,npcm845 compatible string
dt-bindings: arm: npcm: Add maintainer
reset: npcm: Add NPCM8XX support
dt-bindings: reset: npcm: Add support for NPCM8XX
reset: npcm: using syscon instead of device data
ARM: dts: nuvoton: add reset syscon property
dt-bindings: reset: npcm: add GCR syscon property
dt-binding: clk: npcm845: Add binding for Nuvoton NPCM8XX Clock
dt-bindings: watchdog: npcm: Add npcm845 compatible string
dt-bindings: timer: npcm: Add npcm845 compatible string
This adds initial device tree support for the Nuvoton NPCM845 Board
Management controller (BMC) SoC family.
The NPCM845 based quad-core Cortex-A35 ARMv8 architecture and have
various peripheral IPs.
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This adds support for the Nuvoton NPCM8XX Board Management
controller (BMC) SoC family.
The NPCM8XX based quad-core Cortex-A35 ARMv8 architecture.
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Add nuvoton,sysgcr syscon property to the reset node to handle the general
control registers.
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This commit makes sure the drivers for the 98DX2530 pin controller is
enabled.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Vadym Kochan <vadym.kochan@plvision.eu>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
The 98DX2530 SoC is the Control and Management CPU integrated into
the Marvell 98DX25xx and 98DX35xx series of switch chip (internally
referred to as AlleyCat5 and AlleyCat5X).
These files have been taken from the Marvell SDK and lightly cleaned
up with the License and copyright retained.
gregory.clement: use specific cpu type: cortex-a55 instead of armv8 in
cpu nodes, armv8 being reserved for the arm virtual models that are
not meant to implement a particular CPU type.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Signed-off-by: Vadym Kochan <vadym.kochan@plvision.eu>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
The kernel log contains complaints about i2c11 and i2c14 lacking
clock-frequency, specify a reasonable value to suppress this warning.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20220717034403.2135027-4-bjorn.andersson@linaro.org
Both vdda-1p2-supply and vdda-0p9-supply regulators are controlled
by dp combo phy. Therefore remove them from dp controller.
Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/1657556603-15024-1-git-send-email-quic_khsieh@quicinc.com
The Qualcomm USB PHYs are not critical for reaching the ramdisk to load
modules, so they can be demoted to be built as such instead of builtin.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20220712031821.4134712-1-bjorn.andersson@linaro.org
qcom-cpufreq-hw finds turbo-mode in the LUT hardware tables
and slaps the flag on the last element, so there's no reason
to add it in the dts, so remove it.
Signed-off-by: Steev Klimaszewski <steev@kali.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220718230109.8193-1-steev@kali.org
Add a Kconfig entry for MSM8909 and the "qcom,msm8909-smp" CPU
enable-method. The ARM Cortex-A7 cores are booted just like on MSM8226.
Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220705143523.3390944-9-stephan.gerhold@kernkonzept.com
When booting a Thinkpad x13s, we see the message
[ 0.997647] cpu cpu0: failed to update OPP for freq=300000
So, lets add in 300MHz to make it happy
Signed-off-by: Steev Klimaszewski <steev@kali.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220718225714.8074-1-steev@kali.org
On AMD IBRS does not prevent Retbleed; as such use IBPB before a
firmware call to flush the branch history state.
And because in order to do an EFI call, the kernel maps a whole lot of
the kernel page table into the EFI page table, do an IBPB just in case
in order to prevent the scenario of poisoning the BTB and causing an EFI
call using the unprotected RET there.
[ bp: Massage. ]
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20220715194550.793957-1-cascardo@canonical.com
The LED controller node is disabled because the leds-turris-omnia driver
does not support setting the LED blinking to be controlled by the MCU.
The patches for that have now been sent [1], so let's enable the node.
[1] https://lore.kernel.org/linux-leds/20220704105955.15474-1-kabel@kernel.org/T/
Signed-off-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
The marvell PHY driver changes the LED[0] pin function to "On - 1000
Mbps Link, Off - Else".
Turris Omnia expects that the function is "On - Link, Blink - Activity,
Off - No link".
Use the `marvell,reg-init` DT property to change the function.
In the future, once netdev trigger will support HW offloading, we will
be able to have this configured via the combination of PHY driver and
leds-turris-omnia driver.
Signed-off-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
- The code relies on rc_pci_fixup being called, which only happens
when CONFIG_PCI_QUIRKS is enabled, so add that to Kconfig. Omitting
this causes a booting failure with a non-obvious cause.
- Update rc_pci_fixup to set the class properly, copying the
more modern style from other places
- Correct the rc_pci_fixup comment
This patch just re-applies commit 1dc831bf53 ("ARM: Kirkwood: Update
PCI-E fixup") for all other Marvell ARM platforms which have same buggy
PCIe controller and do not use pci-mvebu.c controller driver yet.
Long-term goal for these Marvell ARM platforms should be conversion to
pci-mvebu.c controller driver and removal of these fixups in arch code.
Signed-off-by: Pali Rohár <pali@kernel.org>
Cc: Jason Gunthorpe <jgg@nvidia.com>
Cc: stable@vger.kernel.org
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
The sys_clk frequency is 165.625MHz. The register reference of the
Generic Clock controller lists the CPU clock as 600MHz, the DDR clock as
300MHz and the SYS clock as 162.5MHz. This is wrong. It was first
noticed during the fan driver development and it was measured and
verified via the CLK_MON output of the SoC which can be configured to
output sys_clk/64.
The core PLL settings (which drives the SYS clock) seems to be as
follows:
DIVF = 52
DIVQ = 3
DIVR = 1
With a refernce clock of 25MHz, this means we have a post divider clock
Fpfd = Fref / (DIVR + 1) = 25MHz / (1 + 1) = 12.5MHz
The resulting VCO frequency is then
Fvco = Fpfd * (DIVF + 1) * 2 = 12.5MHz * (52 + 1) * 2 = 1325MHz
And the output frequency is
Fout = Fvco / 2^DIVQ = 1325MHz / 2^3 = 165.625Mhz
This all adds up to the constrains of the PLL:
10MHz <= Fpfd <= 200MHz
20MHz <= Fout <= 1000MHz
1000MHz <= Fvco <= 2000MHz
Fixes: 290deaa10c ("ARM: dts: add DT for lan966 SoC and 2-port board pcb8291")
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Kavyasree Kotagiri <kavyasree.kotagiri@microchip.com>
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/20220326194028.2945985-1-michael@walle.cc
can accomodate a XenPV guest due to how the latter is setting up the PAT
machinery
Now that the retbleed nightmare is public, here's the first round of
fallout fixes:
- Fix a build failure on 32-bit due to missing include
- Remove an untraining point in espfix64 return path
- other small cleanups
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEzv7L6UO9uDPlPSfHEsHwGGHeVUoFAmLTudcACgkQEsHwGGHe
VUrY4BAAtWm7wC6T8rzovbsyticj6kcehRMBEXxtlEP5LOeltR0dbNaIGskrS2Li
Q9YxxtQhbZPXqzqB+xeHVhDPThzsd3+wRvvetmR4fW/c3XCYr+fLLFjHj0NEvX0P
lQzuY8GKWGU/QTrjKSKclGvqyB692Fvdu4YImlnrGSbR6ywwVttditd3YNJR0w1q
7S4zq90uwWuX6cTLqXIcbKbhssOjcR1Agj9+bE8i+rzyB2VtNoihJCJh0pTJAn3P
RaXnxI/7J6Y+5imPf5/ywu8gxhvGBTy5MU/1v2pw939EurU9tmhVkNVWdO2g/qYY
V+Y1nj9xV0ucL4hlUBqAFdM+5jFC89Ey1X2tSgUgSl+44L/d8IIjVCp6inVoyCzE
Olbc6q7A/V8PNXfo4g6gDwVc3Ii53Fwgtu8xVHkwPGfjly6+yZ9O/RUBXcBAOnpU
jfS9LSc/Ro7kxqFy32beUgB7wwhMpkYuHe6ECxrvXj1IK13y3OkdxFzm03ty7S/E
BwjrkltDia9BQ6i4Ywy+qSBYkSH6+sxxt4pboB+ft6/p2JIw4YJIp9PRqzPAG0jx
JTjcZ9YAr7zPNlWp5e30BjGawgbuKPq0wkF1r6QD+3VzNf9+SSDmtkYGWeAyTTP2
SkzLy5QCNBTeeq0FZVYZFm/vcF7wccQhQdwNcezxygKAmihH0xw=
=ND3p
-----END PGP SIGNATURE-----
Merge tag 'x86_urgent_for_v5.19_rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Borislav Petkov:
- Improve the check whether the kernel supports WP mappings so that it
can accomodate a XenPV guest due to how the latter is setting up the
PAT machinery
- Now that the retbleed nightmare is public, here's the first round of
fallout fixes:
* Fix a build failure on 32-bit due to missing include
* Remove an untraining point in espfix64 return path
* other small cleanups
* tag 'x86_urgent_for_v5.19_rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/bugs: Remove apostrophe typo
um: Add missing apply_returns()
x86/entry: Remove UNTRAIN_RET from native_irq_return_ldt
x86/bugs: Mark retbleed_strings static
x86/pat: Fix x86_has_pat_wp()
x86/asm/32: Fix ANNOTATE_UNRET_SAFE use on 32-bit
The remoteproc configuration in qcom-msm8974.dtsi is incomplete because
it lacks the regulator supplies that should be added in the board DT
files. Some of the msm8974 boards are currently missing the regulator
supplies and should have the remoteprocs disabled to avoid making use
of the incomplete configuration.
This also fixes dtbs_check warnings after moving "qcom,msm8974-mss-pil"
to DT schema, which rightfully complains that the -supply properties
are missing for some boards:
qcom-apq8074-dragonboard.dtb:
remoteproc@fc880000: 'pll-supply' is a required property
From schema: remoteproc/qcom,msm8916-mss-pil.yaml
remoteproc@fc880000: 'mss-supply' is a required property
From schema: remoteproc/qcom,msm8916-mss-pil.yaml
remoteproc@fc880000: 'oneOf' conditional failed, one must be fixed:
'power-domains' is a required property
'power-domain-names' is a required property, or
'cx-supply' is a required property
'mx-supply' is a required property
Cc: Luca Weiss <luca@z3ntu.xyz>
Cc: Konrad Dybcio <konrad.dybcio@somainline.org>
Fixes: f300826d27 ("ARM: dts: qcom-msm8974: Sort and clean up nodes")
Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220712124421.3129206-4-stephan.gerhold@kernkonzept.com
Add missing hwlock for ipq8064 dtsi provided by qcom,sfpb-mutex.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
[bjorn: Moved the node inside /soc]
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220707102040.1859-2-ansuelsmth@gmail.com
Add speedbin efuse nvmem cell needed for the opp table for the CPU
freqs.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Tested-by: Jonathan McDowell <noodles@earth.li>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220707010943.20857-10-ansuelsmth@gmail.com
Add some tag for gsbi to make them usable for ipq8064 SoC. Add missing
gsbi7 i2c node and gsbi1 node.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Tested-by: Jonathan McDowell <noodles@earth.li>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220707010943.20857-8-ansuelsmth@gmail.com
The current value for pci IO is problematic for ath10k wifi card
commonly connected to ipq8064 SoC.
The current value is probably a typo and is actually uncommon to find
1MB IO space even on a x86 arch. Also with recent changes to the pci
driver, pci1 and pci2 now fails to function as any connected device
fails any reg read/write. Reduce this to 64K as it should be more than
enough and 3 * 64K of total IO space doesn't exceed the IO_SPACE_LIMIT
hardcoded for the ARM arch.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Tested-by: Jonathan McDowell <noodles@earth.li>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220707010943.20857-7-ansuelsmth@gmail.com
Disable usb phy by default. When the usb phy were pushed, half of them
were flagged as disabled by mistake.
Correctly disable all usb phy and enable them only if a device actually
use them.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220707010943.20857-6-ansuelsmth@gmail.com
Add specific ipq8064 dtsi with smb208 rpm regulators.
Qcom advise to use this configuration but it's not mandatory and OEM
can decide to implement their own regulators.
smb208 regulators are used to scale CPU voltage, L2 cache voltage and
Ubi32 cores.
There regulators are controlled by rpm and to correctly works gsbi4-i2c
require to be NEVER disabled or rpm will reject any regulator change
request.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Tested-by: Jonathan McDowell <noodles@earth.li>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220707010943.20857-4-ansuelsmth@gmail.com
Add missing definition for mdio0 pins used for gpio-bitbang driver,i2c4
pins and rgmii2 pins for ipq8064.
Drop i2c4_pins node from ipq8064-ap148 dts as it's now moved to ipq8064
dtsi.
Drop mdio0_pins node from ipq8064-rb3011 dts as it's now moved to
ipq8064 dtsi.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Tested-by: Jonathan McDowell <noodles@earth.li>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220707010943.20857-2-ansuelsmth@gmail.com
Nexus 5 has a RGB LED connected to the TRILED and hence channels 7, 6 and
5 of the LPG. Add a node describing this.
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Signed-off-by: André Almeida <andrealmeid@collabora.com>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220505164336.13210-1-luca@z3ntu.xyz
FP2 has a RGB LED connected to the TRILED and hence channels 7, 6 and
5 of the LPG. Add a node describing this.
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220505163029.6541-1-luca@z3ntu.xyz
