IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
To convert the 32bit id registers to use the sysreg generation, they
must first have a regular pattern, to match the symbols the script
generates.
Ensure symbols for the ID_PFR1_EL1 register have an _EL1 suffix,
and use lower case in feature names where the arm-arm does the same.
No functional change.
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-10-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
To convert the 32bit id registers to use the sysreg generation, they
must first have a regular pattern, to match the symbols the script
generates.
Ensure symbols for the ID_PFR0_EL1 register have an _EL1 suffix,
and use lower case in feature names where the arm-arm does the same.
No functional change.
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-9-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
To convert the 32bit id registers to use the sysreg generation, they
must first have a regular pattern, to match the symbols the script
generates.
Ensure symbols for the ID_ISAR6_EL1 register have an _EL1 suffix.
No functional change.
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-8-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
To convert the 32bit id registers to use the sysreg generation, they
must first have a regular pattern, to match the symbols the script
generates.
Ensure symbols for the ID_ISAR5_EL1 register have an _EL1 suffix.
No functional change.
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-7-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
To convert the 32bit id registers to use the sysreg generation, they
must first have a regular pattern, to match the symbols the script
generates.
Ensure symbols for the ID_ISAR4_EL1 register have an _EL1 suffix,
and use lower-case for feature names where the arm-arm does the same.
No functional change.
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-6-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
To convert the 32bit id registers to use the sysreg generation, they
must first have a regular pattern, to match the symbols the script
generates.
Ensure symbols for the ID_ISAR0_EL1 register have an _EL1 suffix,
and use lower-case for feature names where the arm-arm does the same.
To functional change.
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-5-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
To convert the 32bit id registers to use the sysreg generation, they
must first have a regular pattern, to match the symbols the script
generates.
Ensure symbols for the ID_MMFR5_EL1 register have an _EL1 suffix.
No functional change.
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-4-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
To convert the 32bit id registers to use the sysreg generation, they
must first have a regular pattern, to match the symbols the script
generates.
Ensure symbols for the ID_MMFR4_EL1 register have an _EL1 suffix,
and use lower case in feature names where the arm-arm does the same.
No functional change.
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-3-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
To convert the 32bit id registers to use the sysreg generation, they
must first have a regular pattern, to match the symbols the script
generates. The scripts would like to follow exactly what is in the
arm-arm, which uses lower case for some of these feature names.
Ensure symbols for the ID_MMFR0_EL1 register have an _EL1 suffix,
and use lower case in feature names where the arm-arm does the same.
No functional change.
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20221130171637.718182-2-james.morse@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
This reverts commit 23715a26c8d81291, which introduced some code in
assembler that manipulates both the ordinary and the shadow call stack
pointer in a way that could potentially be taken advantage of. So let's
revert it, and do a better job the next time around.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
find_timens_vvar_page() is not architecture-specific, as can be seen from
how all five per-architecture versions of it are the same.
(arm64, powerpc and riscv are exactly the same; x86 and s390 have two
characters difference inside a comment, less blank lines, and mark the
!CONFIG_TIME_NS version as inline.)
Refactor the five copies into a central copy in kernel/time/namespace.c.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20221130115320.2918447-1-jannh@google.com
Enable the Qualcomm SM6115 / SM4250 TLMM pinctrl and GCC clock drivers.
They need to be builtin to ensure that the UART is allowed to probe
before user space needs a console.
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221128200834.1776868-1-bhupesh.sharma@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
for 6.2, please pull the following:
- Rafal describes the timer/watchdog block for the BCM4908 and BCM6858
SoCs
- Krzysztof corrects invalid "reg" properties for the memory nodes that
were off by one digit
- Pierre updates a number of cache Device Tree node properties to be
schema compliant
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAmOGWkoACgkQh9CWnEQH
BwTM3hAAz6n7Ncc6ZU+v+sUkfGw5mHYr8tO0SM+nFADGxqd1Rjs+rdyoAxVWnKOY
tC/9Y+l66JmPrwlXJN9dFnRoUjAv8zp09R34ptTpvkBXs5VSC1tppknw14fRQsXk
xZl0oz+TNzoWkb2fWXx8uQdM3WX/R/cfs52kbxVobx2Z27BXSZs8em9PjFRqNKed
1fHHTFuD7JAQX8g575W4vkcP8k0vA4yAGpZdqekAo2A8FaZhQ/DnOszUEQuQNjn2
Wr8Arl8vrBJS8LXBPjPPIzKQlE5+8khR1ESLS+11MKSaP4zTRAB+elpPsiWkqqDv
BfwQVFQs7KCNoPV6WqsltiIoh4/uP70dwUapF9Tye0MqhZ4ZH4C8PBCh8b80H5Wb
h1T78x+6SnzH0rlPjssdfHKNWVSubUvnU7deNA84OrNpxJCrdi5eNf3gZytaU480
550wkDBBuiffYdXplw5LCjxyKIcJ3KoLVyHqQkQ4sCinC8hDWzcA/oOeiAZyedwf
P/cDs+JlOyDwSdeQMkMmaDtKoW8oVaQ6+v9BBKNBl+vvr4l1HlFeEtt30bDvQ6CT
/cOdHhL/ki5FljPsRgF9Uf/Jp9jGF41Ph20Zo636ArQVG4pwGWM3hNTE/J3XSSzj
jBHSdsm346iT55ajqci+5/TWlxUUBvhaIVuj203Q5Z5EAvfqJvY=
=l7Fu
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmOHh+8ACgkQmmx57+YA
GNm88xAAmR3TUNIQiN9ovK7Ibjp9OA+DLXJPDBdplPVB2Y4DigcYNshbJUdJI1He
RLi8npUB3XccLS72tyZA76AYHFD5/zugf0y7erZQTw9eNesd4aXVWfVNWn5tJoVy
4GfewjUg6EmP3kpBsXfKMZak5M8dggZONH0Lkpe7QkquKSut29ku9LxT3Y3Gtzs4
ERNku3T4m7ozgp3LWYg5KHBuEpK2lPvC4hhZnP6+8sChfWJiJwONOWUeXz+P2z5p
vkHQIoqbye42rnwc02gQk79EXmjS/ggEmaCJhU1sS9YnO7QSIC/5hGuQ+spc5Lob
RDGRGDeFG71DbFOVYFWF9Aj1+hxqaY/lJrIRfgjwuxxzuItFMrYytXjZdYGHIoJu
M+ZMt2/cHfQ/0tDA9bkDiK8OmN5D/61OqkAU/CeWwPYY4Ci+t3jkSZP3LI3P5wHV
WB7UUxanM6g7uzaTINFkUAgx6Ljr8edW0pB6nrigei50BZwnRD7B5FbYEaPmbC9B
um+BpnM06oE9+X+V4uh6iYnLBtRcpdLgWk7lzcgoLKyAxxVpyT6+qRBJ7vN/NVaR
nOY7IGMXyTohCvitg4RTssP1vf1VoYEguw4NRdqpgRbeAFy6s8xxSDq7EXxfcRfF
CJlMy7P+XXOKY7ZRi+1yNj/Un30ymRDE2yXrFbKjX9yIZj/0q6Q=
=8S30
-----END PGP SIGNATURE-----
Merge tag 'arm-soc/for-6.2/devicetree-arm64' of https://github.com/Broadcom/stblinux into soc/dt
This pull request contains Broadcom ARM64-based SoCs Device Tree updates
for 6.2, please pull the following:
- Rafal describes the timer/watchdog block for the BCM4908 and BCM6858
SoCs
- Krzysztof corrects invalid "reg" properties for the memory nodes that
were off by one digit
- Pierre updates a number of cache Device Tree node properties to be
schema compliant
* tag 'arm-soc/for-6.2/devicetree-arm64' of https://github.com/Broadcom/stblinux:
arm64: dts: Update cache properties for broadcom
arm64: dts: broadcom: trim addresses to 8 digits
arm64: dts: broadcom: bcmbca: bcm6858: add TWD block
arm64: dts: broadcom: bcmbca: bcm4908: add TWD block timer
Link: https://lore.kernel.org/r/20221129191755.542584-2-f.fainelli@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Just few addtions including updates to cache information on various
platforms to align well with the bindings, addition of cache information
on FVP Rev C model, addition of SPE to Foundation model and updates to
LED node names.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmOF8SgACgkQAEG6vDF+
4ph7uhAAs+XsDmozvzn6q7XtgEDAsSmuXSSmdLawW9dOWBm4h9yP+b0ShfHasSlN
Z/tg/Erc2IGLW6bYwam0JGLyzast2ifOVJfCe1M7Whfep3j2o/SV2eN43qnjSwwp
enryQNw7hF9ShEHtvvBqruHg8BWNQqCBvJRAKHtemcXeXhaad0b32y53ahdbzB0o
FAGD/i2KRJeghlw2s0lw4+jiV+W5UodoEZ4WbxQJSjTcUyqeDLiqfhs0KoHTJjaM
s8rHKHRxRr+Wctibf25JW5iiBhe7ON9rb+KRVubI0jp9LVauO+dzujnR2dP+SbUC
wc61U2G0QEZof+QCSYfVVQbuJ1bLVUzl6hJMl+c5VHSBq6x75jCCHdCq9PlTlXGl
nmBPVP5haDgO17WsJuO5absawsBJehihwC0JLkk6bWnm15+XE7NnMDDLZRHSNuU9
zterk4LVN7d94o+/WwK8XeZtzFfFS4l0OlIDBYWoP0hljvHc/p4jXOh2vvFucPmN
L/YORmb8Vrj2Ql0NY+NPiHt1MDFIOftcYSufBuzzMQJw3pYQAQMFHKc3rUxB6Xee
6CAikSuBWWO7qdY9yP8Fk+GceLrACSk5C/1pJOA2cBQiLw1whYI+4RRzn0g+Su9Z
VN5KU6tP44tE0625ip5wLwcV1TiBa7ghKCezav+4b+TUFxLM0Yw=
=Of6J
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmOHhtEACgkQmmx57+YA
GNkW1g//dZ1xCZ7m0Zduhqp6dfLkC9IUyhkguIba3HsKLL5A1t4E5/AfZM7befQr
rWZZTeeGQtpBlWo0/X2BjtNkcyDH02fU3Mk7mM3raOO/MF+C0IEAmaLWOkiekgYf
dHg5ig2GKVI71wPRtYa0JfwFztgnkhGdMS+PSvELxDlisziVwSaGYOW+1DEZibU6
hMTOZzePFvaI7Q6iP9N6uyLLiLnddrg2ar37z2ummsMgxVd51Eoe6IPzEa2B3bWB
KswrPcVZ2XTINiOleMN9kE8awsZJOacIiNXP8oluffcu/03tLlwv3UYr5RDddtp8
9K2GtXJ1wzvqXbpHo4a1AMwPkgUbcFgLZSl9ypZZP+afwIxxfunr7Ca0gdwBI4GR
5cCrEih9SXGeegrzMz4wa5f5PuxDyeyRHzFzpnDX5z+6+8Q85tGUdDa6cazoBQyS
U11Ty+zu+6NGWVPGz3e6udaJUkkQfF1TO0Kb9EtmNhOh6avj0J4kQT9Vx7PeoXpW
LRPlBt8TLktS7/9jpAvdk0cLkULRqjLlONDRhdrIzGwW3+fMGVyMyWCWnNSu6ia/
M57KTbfZsuq1p223arIC4z6YHPe0JKl5fgEaYRl9fVf3YcMPhrwllsLom5/xf25S
2K7scuKw/AGE+2GSvVgyqyeqeeu+OaYpYkhtXZHVEMBuvBir7Oo=
=GlOv
-----END PGP SIGNATURE-----
Merge tag 'juno-updates-6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/dt
Armv8 Juno/FVP updates for v6.2
Just few addtions including updates to cache information on various
platforms to align well with the bindings, addition of cache information
on FVP Rev C model, addition of SPE to Foundation model and updates to
LED node names.
* tag 'juno-updates-6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
ARM: dts: vexpress: align LED node names with dtschema
arm64: dts: fvp: Add information about L1 and L2 caches
arm64: dts: fvp: Add SPE to Foundation FVP
arm64: dts: Update cache properties for Arm Ltd platforms
arm64: dts: juno: Add thermal critical trip points
Link: https://lore.kernel.org/r/20221129115111.2464233-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This introduces support for SM4250, SM6115, SM6375 and SDM670 platforms
and Sony Xperia 10 IV, Google Pixel 3a, OnePlus 3, OnePlus 3T, Google
Pazquel and OnePlus Nord N100.
A wide variety of updates to align with DeviceTree bindings across
many/most platforms is introduced, and incorrectly styled comments are
adjusted across the tree.
Apps RSC is added to the cluster-idle power-domain across SM8150,
SM8250, SM8350 and SM8450, to ensure sleep and wake votes are flushed as
the last core is being powered down.
Remoteproc firmware patches are aligned with agreed upon structure used
in linux-firmware across Inforce 6560, Lenovo Miix 630, various Sony
Xperia devices and Samsung Galaxy Book2 (although these are not
available in linux-firmware today).
On IPQ8074 CPU clocks are added, thermal zones are introduced and vqmmc
supply is specified for the HK01 board.
Alcatel OneTouch Idol 3 gains LED nodes and Samsung Galaxy A3U gained
vibrator support.
The application subsystem's IOMMU and the display subsystem is enabled
for MSM8953.
A new CPU frequency table is introduced for MSM8996Pro, to properly
describe it separate of MSM8996. The GPU opp-table is extended as well.
On SC7180 USB is marked as a wakeup source, USB gains required-opps to
ensure that the core voltage rail is voted for as needed. The
description of the fingerprint sensor in Trogdor is corrected.
On SC7280 Wake-on-WLAN is introduced, and PHY parameters for the SNPS
USB PHY is defined across SC7280.
The memory map across Google Herobrine is adjusted, to regain unused
memory on the WiFi SKUs. A LTE SKU of the Evoker board is introduced
and the bard gains touchscreen.
NVME support is disabled on Villager boards, as it's not used.
PCIe support is introduced on SC8280XP, with NVMe, SDX55 (5G) and WiFi
enabled on the Lenovo Thinkpad X13s and Compute Reference Device. ADCs
and thermal zones are intrduced for the same. Lenovo Thinkpad X13s
gains LID switch support.
Fairphone FP3 gains touchscreen support.
Support for Xiaomi Poco F1 variant with EBBG panel.
The round-robin ADC is enabled across DB845c, OnePlus devices and
Pocophone F1 devices.
The displayport controller on SDM845 is introduced.
SM6350 gains SDHCI support and on Sony Xperia 10 III sd-card,
touchscreen and GPI DMA is enabled.
Fairphone FP4 got SD-card support.
UFS PHY register ranges are corrected across SM8150, SM8250, SM8350 and
SM8450.
Sony Xperia 1 II got NFC support and Sony Xperia 5 III got PMIC
regulators defined and USB definition corrected, to enable USB3.
The SDHCI controller is described for SM8450 and microSD support is
enabled for the HDK and QRD devices.
SM8450 also gains camera CCI interface and display clock controller.
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmN/QfsVHGFuZGVyc3Nv
bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3FR8wP/3ynHPC8Kq/exZfb2n5M6gS3+3YZ
BxwCcjcwMCMBwFZUZ4LPYDctd+TL8rJ0htnK9Foq61i8FJl2cUqvU/OKtfD3W9gO
wTzZC1bZJItZCreb4T7Kj2t3hBhO5dkG+UgbovfOgk9tJXvgNbio66ZGJqKDtU92
ubIAJxFERACERT9g6gtAdBa2BEofG/zI2ei8HqkKP/7u51XXtRNzVCYXyHM8TydL
M03U6snZNJkkj+UM8Wzrg9mxkheAOSyo0nLK58Lje2I4CjV5WToCZUICqm7z7l36
GoBnDXaRacmb0gIco9sGMo5K7jNqQ/6U1JVJRAb+NNM16fp0mKOboZ8SLKI9oT6g
9UXiylzzz0buvNzzTu7HF8JRNQvxBnLKC+nE/ekWQm6uhsmJ9DkrMBnxn5fyZ1iL
5uFXcaVDagVQCdHOfYntQzKEGsoPwg0KQJbjoM+T3tkQX5NcWVP+06uYLWqRxgk5
jTn98JXK+2w4yYdhCKr8U71mBoWwoYwOZiEnZlL+P+52gZUoWDgA65BGnoqYk2cW
2KsfB+EM3ggye6a4X/gVVuCR8bYO5+YIUyoBWLRKd51xw0Mr99KUc+ugTmCKGZpW
31p/NhgdvfOK9qLRhEVH9zDT24Jqo1tRF2NgtJrFufMcYbdNbB8BA22aDLoTbE0m
Kru1n0WaaU4vBIbm
=0+lj
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmOHYjwACgkQmmx57+YA
GNn21Q/7B5vrpo21COOlybRqhhAJYKo1kouED1EW4Fh1qQ0PejkDEU9CZYuvTNyw
l0sFewhdpV9cEhSDm6nuk+wcs15r3tBp9fWWWBMbLLi+MohO0rY3Wi7ZIZDbK9N8
B1UqkCASqLRYbny6kT0JztlhdEAHlEJ2Bc63pHhVYdj74xyLm+ByIgGV0o0fWhNM
dUtJwz+W+uYMg/5OFj/UMLBvXFdDzz/LmYKS8UYP0sxmhOUJd1yTqxyqCxECWe6z
OgGeB+2bQ297OyWdQjZk6tucZcjpP0y6qtL1PQaDtfqMVXsaDKNqa+C1eTvTEQWT
tzOuWq4I5z7+vEe3JlKwHFmeblvD5FhNqUzyJabxXbTpe7m7sLbyeJdYaXXd6lmk
0hBAJdSNNqAoIMMXUWwDxzaTDzKq648fteP0VZIC2B24iSRz6tt2FhLi6X1Lh0Tj
LDHsbHvQIY3cFmYqIbgRt+lMxyy+pZWRuZFhMeIrNE1T4OQn2X3l5DlGAjUw2i51
KXWUHeUSWWE39FyV/V72BDIPM/kGrESdJACko989ZinKdvKSyyz9Tl4qKsYUWAFH
XZf3BvvsP20WKLvF79n500RBOh0J2uhTGTv6zphXXj5nRvv6NFiS1C+MWwaVnO4L
HABmamTgb/rkP36J7nOD3iBQxuYG4i/hDLG66Zibhf9gqUDAWV4=
=c209
-----END PGP SIGNATURE-----
Merge tag 'qcom-arm64-for-6.2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/dt
Qualcomm ARM64 DTS updates for 6.2
This introduces support for SM4250, SM6115, SM6375 and SDM670 platforms
and Sony Xperia 10 IV, Google Pixel 3a, OnePlus 3, OnePlus 3T, Google
Pazquel and OnePlus Nord N100.
A wide variety of updates to align with DeviceTree bindings across
many/most platforms is introduced, and incorrectly styled comments are
adjusted across the tree.
Apps RSC is added to the cluster-idle power-domain across SM8150,
SM8250, SM8350 and SM8450, to ensure sleep and wake votes are flushed as
the last core is being powered down.
Remoteproc firmware patches are aligned with agreed upon structure used
in linux-firmware across Inforce 6560, Lenovo Miix 630, various Sony
Xperia devices and Samsung Galaxy Book2 (although these are not
available in linux-firmware today).
On IPQ8074 CPU clocks are added, thermal zones are introduced and vqmmc
supply is specified for the HK01 board.
Alcatel OneTouch Idol 3 gains LED nodes and Samsung Galaxy A3U gained
vibrator support.
The application subsystem's IOMMU and the display subsystem is enabled
for MSM8953.
A new CPU frequency table is introduced for MSM8996Pro, to properly
describe it separate of MSM8996. The GPU opp-table is extended as well.
On SC7180 USB is marked as a wakeup source, USB gains required-opps to
ensure that the core voltage rail is voted for as needed. The
description of the fingerprint sensor in Trogdor is corrected.
On SC7280 Wake-on-WLAN is introduced, and PHY parameters for the SNPS
USB PHY is defined across SC7280.
The memory map across Google Herobrine is adjusted, to regain unused
memory on the WiFi SKUs. A LTE SKU of the Evoker board is introduced
and the bard gains touchscreen.
NVME support is disabled on Villager boards, as it's not used.
PCIe support is introduced on SC8280XP, with NVMe, SDX55 (5G) and WiFi
enabled on the Lenovo Thinkpad X13s and Compute Reference Device. ADCs
and thermal zones are intrduced for the same. Lenovo Thinkpad X13s
gains LID switch support.
Fairphone FP3 gains touchscreen support.
Support for Xiaomi Poco F1 variant with EBBG panel.
The round-robin ADC is enabled across DB845c, OnePlus devices and
Pocophone F1 devices.
The displayport controller on SDM845 is introduced.
SM6350 gains SDHCI support and on Sony Xperia 10 III sd-card,
touchscreen and GPI DMA is enabled.
Fairphone FP4 got SD-card support.
UFS PHY register ranges are corrected across SM8150, SM8250, SM8350 and
SM8450.
Sony Xperia 1 II got NFC support and Sony Xperia 5 III got PMIC
regulators defined and USB definition corrected, to enable USB3.
The SDHCI controller is described for SM8450 and microSD support is
enabled for the HDK and QRD devices.
SM8450 also gains camera CCI interface and display clock controller.
* tag 'qcom-arm64-for-6.2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (261 commits)
arm64: dts: qcom: sdm845-polaris: Don't duplicate DMA assignment
arm64: dts: qcom: sm8350-sagami: Wire up USB regulators and fix USB3
arm64: dts: qcom: sm8350-sagami: Add most RPMh regulators
arm64: dts: qcom: sc7280: Make herobrine-audio-rt5682 mic dtsi's match more
arm64: dts: qcom: trim addresses to 8 digits
arm64: dts: msm8998: unify PCIe clock order withMSM8996
arm64: dts: msm8998: add MSM8998 specific compatible
arm64: dts: qcom: sc8280xp-x13s: enable WiFi controller
arm64: dts: qcom: sc8280xp-x13s: enable modem
arm64: dts: qcom: sc8280xp-x13s: enable NVMe SSD
arm64: dts: qcom: sc8280xp-crd: enable WiFi controller
arm64: dts: qcom: sc8280xp-crd: enable SDX55 modem
arm64: dts: qcom: sc8280xp-crd: enable NVMe SSD
arm64: dts: qcom: sc8280xp-crd: rename backlight and misc regulators
arm64: dts: qcom: sa8295p-adp: enable PCIe
arm64: dts: qcom: sc8280xp/sa8540p: add PCIe2-4 nodes
arm64: dts: qcom: add sdm670 and pixel 3a device trees
arm64: dts: qcom: sc7280: Add Google Herobrine WIFI SKU dts fragment
arm64: dts: qcom: sc7280: Mark all Qualcomm reference boards as LTE
arm64: dts: qcom: sm7225-fairphone-fp4: Enable SD card
...
Link: https://lore.kernel.org/r/20221124100650.1982448-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
New boards:
- Model A and blade baseboards for the SOQuartz (rk3568) SoM,
- Anberic RG351M, RG353V, RG353VS; Odroid Go Super, Advance gaming devices
- Odroid M1
- Theobroma px30 SoM with baseboard
- Rockchip's own rk3566 demo board
Some core support for per SoC specifics:
- crypto support for rk3399 and rk3328
- second I2S controller for rk3568
- Cache properties for follow the binding for rk3308 and rk3328
Bigger device support updates for:
- SOQuartz: PCIe2, video output, gpu, HDMI sound
- Rock 3A: eth regulator, eth clock input, Wifi+Bt, I2S, PCIe3
As well as some minor extensions for Rock960 (hdmi supplies),
rk3566-roc-pc (PCIe2), Rock 4C+ (thermal support), Pinephone Pro (Wifi+Bt)
* tag 'v6.2-rockchip-dts64-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: (51 commits)
arm64: dts: rockchip: update cache properties for rk3308 and rk3328
arm64: dts: rockchip: Add SOQuartz Model A baseboard
dt-bindings: arm: rockchip: Add SOQuartz Model A
arm64: dts: rockchip: Add SOQuartz blade board
dt-bindings: arm: rockchip: Add SOQuartz Blade
arm64: dts: rockchip: Add Anbernic RG351M
arm64: dts: rockchip: Add Odroid Go Super
arm64: dts: rockchip: Add Odroid Go Advance Black Edition
dt-bindings: arm: rockchip: Add more RK3326 devices
arm64: dts: rockchip: Move most of Odroid Go Advance DTS into a DTSI
arm64: dts: rockchip: Add support of regulator for ethernet node on Rock 3A SBC
arm64: dts: rockchip: Add support of external clock to ethernet node on Rock 3A SBC
arm64: dts: rockchip: Add HDMI supplies on Rock960
arm64: dts: rockchip: Add dts for rockchip rk3566 box demo board
dt-bindings: rockchip: Add Rockchip rk3566 box demo board
arm64: dts: rockchip: Enable PCIe 2 on SOQuartz CM4IO
arm64: dts: rockchip: Enable HDMI sound on SOQuartz
arm64: dts: rockchip: Enable video output and HDMI on SOQuartz
arm64: dts: rockchip: Enable GPU on SOQuartz CM4
arm64: dts: rockchip: enable pcie2 on rk3566-roc-pc
...
Link: https://lore.kernel.org/r/4716610.aeNJFYEL58@phil
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The node names should be generic and DT schema expects certain pattern:
altera/socfpga_stratix10_socdk.dtb: leds: 'hps0', 'hps1', 'hps2' do not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
For reasons that are unclear to this reader fpsimd_bind_state_to_cpu()
populates the struct fpsimd_last_state_struct that it uses to store the
active floating point state for KVM guests by passing an argument for
each member of the structure. As the richness of the architecture increases
this is resulting in a function with a rather large number of arguments
which isn't ideal.
Simplify the interface by using the struct directly as the single argument
for the function, renaming it as we lift the definition into the header.
This could be built on further to reduce the work we do adding storage for
new FP state in various places but for now it just simplifies this one
interface.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20221115094640.112848-9-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
The syscall ABI says that the SVE register state not shared with FPSIMD
may not be preserved on syscall, and this is the only mechanism we have
in the ABI to stop tracking the extra SVE state for a process. Currently
we do this unconditionally by means of disabling SVE for the process on
syscall, causing userspace to take a trap to EL1 if it uses SVE again.
These extra traps result in a noticeable overhead for using SVE instead
of FPSIMD in some workloads, especially for simple syscalls where we can
return directly to userspace and would not otherwise need to update the
floating point registers. Tests with fp-pidbench show an approximately
70% overhead on a range of implementations when SVE is in use - while
this is an extreme and entirely artificial benchmark it is clear that
there is some useful room for improvement here.
Now that we have the ability to track the decision about what to save
seprately to TIF_SVE we can improve things by leaving TIF_SVE enabled on
syscall but only saving the FPSIMD registers if we are in a syscall.
This means that if we need to restore the register state from memory
(eg, after a context switch or kernel mode NEON) we will drop TIF_SVE
and reenable traps for userspace but if we can just return to userspace
then traps will remain disabled.
Since our current implementation and hence ABI has the effect of zeroing
all the SVE register state not shared with FPSIMD on syscall we replace
the disabling of TIF_SVE with a flush of the non-shared register state,
this means that there is still some overhead for syscalls when SVE is in
use but it is very much reduced.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20221115094640.112848-8-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Now that we track the type of the stored register state separately to
what is active in the task, it is valid to have the FPSIMD register
state stored while in streaming mode. Remove the special case handling
for SME when setting FPSIMD register state.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20221115094640.112848-7-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Now that we are recording the type of floating point register state we
are saving when we write the register state out to memory we can use
that information when we load from memory to decide which format to
load, bringing TIF_SVE into line with what we saved rather than relying
on TIF_SVE to determine what to load.
The SME state details are already recorded directly in the saved
SVCR and handled based on the information there.
Since we are not changing any of the save paths there should be no
functional change from this patch, further patches will make use of this
to optimise and clarify the code.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20221115094640.112848-6-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Now that we are explicitly telling the host FP code which register state
it needs to save we can remove the manipulation of TIF_SVE from the KVM
code, simplifying it and allowing us to optimise our handling of normal
tasks. Remove the manipulation of TIF_SVE from KVM and instead rely on
to_save to ensure we save the correct data for it.
There should be no functional or performance impact from this change.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20221115094640.112848-5-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
In order to avoid needlessly saving and restoring the guest registers KVM
relies on the host FPSMID code to save the guest registers when we context
switch away from the guest. This is done by binding the KVM guest state to
the CPU on top of the task state that was originally there, then carefully
managing the TIF_SVE flag for the task to cause the host to save the full
SVE state when needed regardless of the needs of the host task. This works
well enough but isn't terribly direct about what is going on and makes it
much more complicated to try to optimise what we're doing with the SVE
register state.
Let's instead have KVM pass in the register state it wants saving when it
binds to the CPU. We introduce a new FP_STATE_CURRENT for use
during normal task binding to indicate that we should base our
decisions on the current task. This should not be used when
actually saving. Ideally we might want to use a separate enum for
the type to save but this enum and the enum values would then
need to be named which has problems with clarity and ambiguity.
In order to ease any future debugging that might be required this patch
does not actually update any of the decision making about what to save,
it merely starts tracking the new information and warns if the requested
state is not what we would otherwise have decided to save.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20221115094640.112848-4-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
When we save the state for the floating point registers this can be done
in the form visible through either the FPSIMD V registers or the SVE Z and
P registers. At present we track which format is currently used based on
TIF_SVE and the SME streaming mode state but particularly in the SVE case
this limits our options for optimising things, especially around syscalls.
Introduce a new enum which we place together with saved floating point
state in both thread_struct and the KVM guest state which explicitly
states which format is active and keep it up to date when we change it.
At present we do not use this state except to verify that it has the
expected value when loading the state, future patches will introduce
functional changes.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20221115094640.112848-3-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Since 8383741ab2e773a99 (KVM: arm64: Get rid of host SVE tracking/saving)
KVM has not tracked the host SVE state, relying on the fact that we
currently disable SVE whenever we perform a syscall. This may not be true
in future since performance optimisation may result in us keeping SVE
enabled in order to avoid needing to take access traps to reenable it.
Handle this by clearing TIF_SVE and converting the stored task state to
FPSIMD format when preparing to run the guest. This is done with a new
call fpsimd_kvm_prepare() to keep the direct state manipulation
functions internal to fpsimd.c.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20221115094640.112848-2-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
__armv8pmu_probe_pmu() returns if detected PMU is either not implemented or
implementation defined. Extracted ID_AA64DFR0_EL1_PMUVer value, when PMU is
not implemented is '0' which can be replaced with ID_AA64DFR0_EL1_PMUVer_NI
defined as '0b0000'.
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-perf-users@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20221128025449.39085-1-anshuman.khandual@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Certain VMMs such as crosvm have features (e.g. sandboxing) that depend
on being able to map guest memory as MAP_SHARED. The current restriction
on sharing MAP_SHARED pages with the guest is preventing the use of
those features with MTE. Now that the races between tasks concurrently
clearing tags on the same page have been fixed, remove this restriction.
Note that this is a relaxation of the ABI.
Signed-off-by: Peter Collingbourne <pcc@google.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20221104011041.290951-8-pcc@google.com
Previously we allowed creating a memslot containing a private mapping that
was not VM_MTE_ALLOWED, but would later reject KVM_RUN with -EFAULT. Now
we reject the memory region at memslot creation time.
Since this is a minor tweak to the ABI (a VMM that created one of
these memslots would fail later anyway), no VMM to my knowledge has
MTE support yet, and the hardware with the necessary features is not
generally available, we can probably make this ABI change at this point.
Signed-off-by: Peter Collingbourne <pcc@google.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20221104011041.290951-7-pcc@google.com
Initialising the tags and setting PG_mte_tagged flag for a page can race
between multiple set_pte_at() on shared pages or setting the stage 2 pte
via user_mem_abort(). Introduce a new PG_mte_lock flag as PG_arch_3 and
set it before attempting page initialisation. Given that PG_mte_tagged
is never cleared for a page, consider setting this flag to mean page
unlocked and wait on this bit with acquire semantics if the page is
locked:
- try_page_mte_tagging() - lock the page for tagging, return true if it
can be tagged, false if already tagged. No acquire semantics if it
returns true (PG_mte_tagged not set) as there is no serialisation with
a previous set_page_mte_tagged().
- set_page_mte_tagged() - set PG_mte_tagged with release semantics.
The two-bit locking is based on Peter Collingbourne's idea.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Peter Collingbourne <pcc@google.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Peter Collingbourne <pcc@google.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20221104011041.290951-6-pcc@google.com
Currently sanitise_mte_tags() checks if it's an online page before
attempting to sanitise the tags. Such detection should be done in the
caller via the VM_MTE_ALLOWED vma flag. Since kvm_set_spte_gfn() does
not have the vma, leave the page unmapped if not already tagged. Tag
initialisation will be done on a subsequent access fault in
user_mem_abort().
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
[pcc@google.com: fix the page initializer]
Signed-off-by: Peter Collingbourne <pcc@google.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Peter Collingbourne <pcc@google.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20221104011041.290951-4-pcc@google.com
Currently the PG_mte_tagged page flag mostly means the page contains
valid tags and it should be set after the tags have been cleared or
restored. However, in mte_sync_tags() it is set before setting the tags
to avoid, in theory, a race with concurrent mprotect(PROT_MTE) for
shared pages. However, a concurrent mprotect(PROT_MTE) with a copy on
write in another thread can cause the new page to have stale tags.
Similarly, tag reading via ptrace() can read stale tags if the
PG_mte_tagged flag is set before actually clearing/restoring the tags.
Fix the PG_mte_tagged semantics so that it is only set after the tags
have been cleared or restored. This is safe for swap restoring into a
MAP_SHARED or CoW page since the core code takes the page lock. Add two
functions to test and set the PG_mte_tagged flag with acquire and
release semantics. The downside is that concurrent mprotect(PROT_MTE) on
a MAP_SHARED page may cause tag loss. This is already the case for KVM
guests if a VMM changes the page protection while the guest triggers a
user_mem_abort().
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
[pcc@google.com: fix build with CONFIG_ARM64_MTE disabled]
Signed-off-by: Peter Collingbourne <pcc@google.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Peter Collingbourne <pcc@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20221104011041.290951-3-pcc@google.com
Commit 4beba9486abd ("mm: Add PG_arch_2 page flag") introduced a new
page flag for all 64-bit architectures. However, even if an architecture
is 64-bit, it may still have limited spare bits in the 'flags' member of
'struct page'. This may happen if an architecture enables SPARSEMEM
without SPARSEMEM_VMEMMAP as is the case with the newly added loongarch.
This architecture port needs 19 more bits for the sparsemem section
information and, while it is currently fine with PG_arch_2, adding any
more PG_arch_* flags will trigger build-time warnings.
Add a new CONFIG_ARCH_USES_PG_ARCH_X option which can be selected by
architectures that need more PG_arch_* flags beyond PG_arch_1. Select it
on arm64.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
[pcc@google.com: fix build with CONFIG_ARM64_MTE disabled]
Signed-off-by: Peter Collingbourne <pcc@google.com>
Reported-by: kernel test robot <lkp@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Steven Price <steven.price@arm.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20221104011041.290951-2-pcc@google.com
The DeviceTree Specification v0.3 specifies that the cache node
'compatible' and 'cache-level' properties are 'required'. Cf.
s3.8 Multi-level and Shared Cache Nodes
The 'cache-unified' property should be present if one of the
properties for unified cache is present ('cache-size', ...).
Update the Device Trees accordingly.
Acked-by: William Zhang <william.zhang@broadcom.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Link: https://lore.kernel.org/r/20221122163208.3810985-3-pierre.gondois@arm.com
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Userspace can play some dirty tricks on us by selecting a given
PMU version (such as PMUv3p5), restore a PMCR_EL0 value that
has PMCR_EL0.LP set, and then switch the PMU version to PMUv3p1,
for example. In this situation, we end-up with PMCR_EL0.LP being
set and spreading havoc in the PMU emulation.
This is specially hard as the first two step can be done on
one vcpu and the third step on another, meaning that we need
to sanitise *all* vcpus when the PMU version is changed.
In orer to avoid a pretty complicated locking situation,
defer the sanitisation of PMCR_EL0 to the point where the
vcpu is actually run for the first tine, using the existing
KVM_REQ_RELOAD_PMU request that calls into kvm_pmu_handle_pmcr().
There is still an obscure corner case where userspace could
do the above trick, and then save the VM without running it.
They would then observe an inconsistent state (PMUv3.1 + LP set),
but that state will be fixed on the first run anyway whenever
the guest gets restored on a host.
Reported-by: Reiji Watanabe <reijiw@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Resetting PMCR_EL0 is a pretty involved process that includes
poisoning some of the writable bits, just because we can.
It makes it hard to reason about about what gets configured,
and just resetting things to 0 seems like a much saner option.
Reduce reset_pmcr() to just preserving PMCR_EL0.N from the host,
and setting PMCR_EL0.LC if we don't support AArch32.
Signed-off-by: Marc Zyngier <maz@kernel.org>
kvm_host_pmu_init() returns when detected PMU is either not implemented, or
implementation defined. kvm_pmu_probe_armpmu() also has a similar situation.
Extracted ID_AA64DFR0_EL1_PMUVer value, when PMU is not implemented is '0',
which can be replaced with ID_AA64DFR0_EL1_PMUVer_NI defined as '0b0000'.
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-perf-users@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20221128135629.118346-1-anshuman.khandual@arm.com
The t600x CPU nodes are missing the cache hierarchy information. The
cache hierarchy on Arm can not be detected and needs to be described in
DT. The OS scheduler can make use of this information for scheduling
decisions.
The cache size information is based on various articles about the
processors. There's also an L3 system level cache (SLC). It's not
described here because SLCs typically have some MMIO interface which
would need to be described.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Hector Martin <marcan@marcan.st>
Add reserved memory and ARM firmware definitions for optee
memory region in Marvell Armada SoCs to avoid protected memory
access.
Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@bootlin.com>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
The DeviceTree Specification v0.3 specifies that the cache node
'compatible' and 'cache-level' properties are 'required'. Cf.
s3.8 Multi-level and Shared Cache Nodes
The recently added init_of_cache_level() function checks
these properties. Add them if missing.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
MCP7940MT-I/MNY RTC has connected interrupt line to GPIO2_5.
Fixes: 7109d817db2e ("arm64: dts: marvell: add DTS for Turris Mox")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
PCIe Slot Power Limit on Turris Mox is 10W.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
RPU subsystem can be configured in cluster-mode or split mode.
Also each r5 core has separate power domains.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Acked-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20221114233940.2096237-3-tanmay.shah@amd.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
There are no longer any users of the assembler macros for saving and
restoring DAIF so remove them to prevent further users being added, there
are C equivalents available.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20221123180209.634650-3-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
We really don't want to take an exception while replacing TTBR1 so we mask
DAIF during the actual update. Currently this is done in the assembly
function idmap_cpu_replace_ttbr1() but it could equally be done in the only
caller of that function, cpu_replace_ttbr1(). This simplifies the assembly
code slightly and means that when working with the code around masking DAIF
flags there is one less piece of assembly code which needs to be considered.
While we're at it add a comment which makes explicit why we are masking
DAIF in this code.
There should be no functional effect.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20221123180209.634650-2-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
If CONFIG_SWP_EMULATION is not set and
CONFIG_CP15_BARRIER_EMULATION is not set,
aarch64-linux-gnu complained about unused-function :
arch/arm64/kernel/armv8_deprecated.c:67:21: error: ‘aarch32_check_condition’ defined but not used [-Werror=unused-function]
static unsigned int aarch32_check_condition(u32 opcode, u32 psr)
^~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
To fix this warning, modify aarch32_check_condition() with __maybe_unused.
Fixes: 0c5f416219da ("arm64: armv8_deprecated: move aarch32 helper earlier")
Signed-off-by: Ren Zhijie <renzhijie2@huawei.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20221124022429.19024-1-renzhijie2@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
The build test robot pointer out that there's a build failure when:
CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS=y
CONFIG_DYNAMIC_FTRACE_WITH_ARGS=n
... due to some mismatched ifdeffery, some of which checks
CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS, and some of which checks
CONFIG_DYNAMIC_FTRACE_WITH_ARGS, leading to some missing definitions expected
by the core code when CONFIG_DYNAMIC_FTRACE=n and consequently
CONFIG_DYNAMIC_FTRACE_WITH_ARGS=n.
There's really not much point in supporting CONFIG_DYNAMIC_FTRACE=n (AKA
static ftrace). All supported toolchains allow us to implement
DYNAMIC_FTRACE, distributions all prefer DYNAMIC_FTRACE, and both
powerpc and s390 removed support for static ftrace in commits:
0c0c52306f4792a4 ("powerpc: Only support DYNAMIC_FTRACE not static")
5d6a0163494c78ad ("s390/ftrace: enforce DYNAMIC_FTRACE if FUNCTION_TRACER is selected")
... and according to Steven, static ftrace is only supported on x86 to
allow testing that the core code still functions in this configuration.
Given that, let's simplify matters by removing arm64's support for
static ftrace. This avoids the problem originally reported, and leaves
us with less code to maintain.
Fixes: 26299b3f6ba2 ("ftrace: arm64: move from REGS to ARGS")
Link: https://lore.kernel.org/r/202211212249.livTPi3Y-lkp@intel.com
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Link: https://lore.kernel.org/r/20221122163624.1225912-1-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
sm3_neon_transform() is called via indirect function calls. Therefore
it needs to use SYM_TYPED_FUNC_START instead of SYM_FUNC_START to cause
its type hash to be emitted when the kernel is built with
CONFIG_CFI_CLANG=y. Otherwise, the code crashes with a CFI failure (if
the compiler didn't happen to optimize out the indirect call).
Fixes: c50d32859e70 ("arm64: Add types to indirect called assembly functions")
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
