The PCIe IP (rev 1.9.0) on SM8250 SoC is similar to the one used on
SDM845. Hence the support is added reusing the members of ops_2_7_0.
The key difference between ops_2_7_0 and ops_1_9_0 is the config_sid
callback, which will be added in successive commit.
Link: https://lore.kernel.org/r/20201208121402.178011-3-mani@kernel.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Document the PCIe DT bindings for SM8250 SoC. The PCIe IP is similar to
the one used on SDM845, hence just add the compatible along with the
optional "atu" register region.
Link: https://lore.kernel.org/r/20201208121402.178011-2-mani@kernel.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Arm SMMU updates for 5.11, including support for the SMMU integrated
into the Adreno GPU as well as workarounds for the broken firmware
implementation in the DB845c SoC from Qualcomm.
* for-next/iommu/arm-smmu:
iommu: arm-smmu-impl: Add a space before open parenthesis
iommu: arm-smmu-impl: Use table to list QCOM implementations
iommu/arm-smmu: Move non-strict mode to use io_pgtable_domain_attr
iommu/arm-smmu: Add support for pagetable config domain attribute
iommu/io-pgtable-arm: Add support to use system cache
iommu/io-pgtable: Add a domain attribute for pagetable configuration
dt-bindings: arm-smmu: Add compatible string for Adreno GPU SMMU
iommu/arm-smmu: Add a way for implementations to influence SCTLR
iommu/arm-smmu-qcom: Add implementation for the adreno GPU SMMU
iommu/arm-smmu-v3: Assign boolean values to a bool variable
iommu/arm-smmu: Use new devm_krealloc()
iommu/arm-smmu-qcom: Implement S2CR quirk
iommu/arm-smmu-qcom: Read back stream mappings
iommu/arm-smmu: Allow implementation specific write_s2cr
You can get the Qt version by running "pkg-config --modversion Qt5Core"
or something, but this might be useful to get the runtime Qt version
more easily. Go to the menu "Help" -> "About", then you can see it.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Now that the Qt4 support was dropped, we can use the new connection
syntax supported by Qt5. It provides compile-time checking of the
validity of the connection.
Previously, the connection between signals and slots were checked
only run-time.
Commit d85de3399f ("kconfig: qconf: fix signal connection to invalid
slots") fixed wrong slots.
This change makes it possible to catch such mistakes easily.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Boris Kolpackov <boris@codesynthesis.com>
It is possible to keep this compatible with both Qt4 and Qt5, but it is
questionable if it is worth the efforts; it would require us to test
this on both of them, and prevent us from using new features in Qt5.
Qt5 was released in 2012, and now widely available.
Drop the Qt4 support.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The -Wnested-externs warning has become useless with gcc, since
this warns every time that BUILD_BUG_ON() or similar macros
are used.
With clang, the warning option does nothing to start with, so
just remove it entirely.
Suggested-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Change every shebang which does not need an argument to use /usr/bin/env.
This is needed as not every distro has everything under /usr/bin,
sometimes not even bash.
Signed-off-by: Finn Behrens <me@kloenk.de>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
There is a missing "return ret;" on this error path so we call
"da9121_check_device_type(i2c, chip);" which will end up dereferencing
"chip->regmap" and lead to an Oops.
Fixes: c860476b9e ("regulator: da9121: Add device variant regmaps")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Adam Ward <Adam.Ward.opensource@diasemi.com>
Link: https://lore.kernel.org/r/X85soGKnWAjPUA7a@mwanda
Signed-off-by: Mark Brown <broonie@kernel.org>
The cx2072x codec driver defines multiple DAIs with the same stream
name "Playback" and "Capture". Although the current code works more
or less as is as the secondary streams are never used, it still leads
the error message like:
debugfs: File 'Playback' in directory 'dapm' already present!
debugfs: File 'Capture' in directory 'dapm' already present!
Fix it by renaming the secondary streams to unique names.
Fixes: a497a43637 ("ASoC: Add support for Conexant CX2072X CODEC")
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20201208135154.9188-1-tiwai@suse.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver is initially designed for sound card using HDMI
interface on i.MX platform. There is internal HDMI IP or
external HDMI modules connect with SAI or AUD2HTX interface.
It supports both transmitter and receiver devices.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
Link: https://lore.kernel.org/r/1607251319-5821-2-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Imx-hdmi is a new added machine driver for supporting hdmi devices
on i.MX platforms. There is HDMI IP or external HDMI modules connect
with SAI or AUD2HTX interface.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/1607251319-5821-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The snd-soc-sst-acpi driver does not care about the id specified for
the SSP2-Codec DAI, but it does matter for the snd-sof-acpi driver;
and when it is not 0 then the snd-sof-acpi driver does not work.
Set the SSP2-Codec DAI id to 0, fixing the snd-sof-acpi driver not
working on devices using the cht_bsw_nau8824 machine-driver.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20201206122436.13553-3-hdegoede@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When using the snd-soc-sst-acpi driver then the compress-cpu-dai bits are
not used, the cht_bsw_nau8824 machine-driver is the only BYT/CHT driver
defining them.
When using the snd-sof-acpi driver then the presence of the
compress-cpu-dai bits breaks things because the sof topology file for
by/cht devices does not contain routing info for them.
Drop the compress-cpu-dai bits, fixing the snd-sof-acpi driver not
working on devices using the cht_bsw_nau8824 machine-driver.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20201206122436.13553-2-hdegoede@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 90a09178f3 ("dt-bindings: Add documentation for GV11B GPU")
added the GV11B GPU device-tree bindings information but incorrectly
added an additional 0 to the size of the addresses in the example.
Fixes: 90a09178f3 ("dt-bindings: Add documentation for GV11B GPU")
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://lore.kernel.org/r/20201124121842.1037035-1-jonathanh@nvidia.com
Signed-off-by: Rob Herring <robh@kernel.org>
Adds Foxconn Industrial Internet, who have submitted a BMC device tree.
Reviewed-by: Benjamin Fair <benjaminfair@google.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Link: https://lore.kernel.org/r/20201119073230.123888-1-joel@jms.id.au
Signed-off-by: Rob Herring <robh@kernel.org>
Although handling a mapping request with no permissions is a
trivial no-op, defer the early return until after the size/range
checks so that we are consistent with other mapping requests.
Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com>
Link: https://lore.kernel.org/r/20201207115758.9400-1-zhukeqian1@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
xt875 comes up with a iva voltage of 1375000 and android runs at this too. fix
maximum voltage to be consistent with this.
Signed-off-by: Carl Philipp Klemm <philipp@uvos.xyz>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Currently there is a null pointer check for hdmi_phy that implies it
may be null, however a dev_err messages dereferences this potential null
pointer. Avoid a null pointer dereference by only emitting the dev_err
message if hdmi_phy is non-null. It is a moot point if the error message
needs to be printed at all, but since this is a relatively new piece of
code it may be useful to keep the message in for the moment in case there
are unforseen errors that need to be reported.
Fixes: be28b6507c ("drm/mediatek: separate hdmi phy to different file")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Addresses-Coverity: ("Dereference after null check")
Link: https://lore.kernel.org/r/20201207150937.170435-1-colin.king@canonical.com
[vkoul: fix indent of return call]
Signed-off-by: Vinod Koul <vkoul@kernel.org>
This includes following Thunderbolt/USB4 changes for v5.11 merge window:
* DMA traffic test driver
* USB4 router NVM upgrade improvements
* USB4 router operations proxy implementation available in the recent
Intel Connection Manager firmwares
* Support for Intel Maple Ridge discrete Thunderbolt 4 controller
* A couple of cleanups and minor improvements.
-----BEGIN PGP SIGNATURE-----
iQJUBAABCgA+FiEEVTdhRGBbNzLrSUBaAP2fSd+ZWKAFAl/PagggHG1pa2Eud2Vz
dGVyYmVyZ0BsaW51eC5pbnRlbC5jb20ACgkQAP2fSd+ZWKD5DQ/+NFsABFQaf1P+
sU4HVOo9cwfvQCFCapfOsOjBsrkuLsjZPQdUqVdTzhrDzRM6uVQXHqWkcInNYxEs
D0o9f8yheYSPuZolHIIydkNZ7VjhXwhVp7FuF+6M3bIhtD9siuBUisCu7QtOjzpF
EAzBZcGHvKXkPmVAQKZS/P4WsgcZDv0/pODjeQawosgJAPOo5begZVBEYcpbOeCT
qvl1vEs+Fr5fcoFcY/58sJX932CcbbO5bZMSc01IIF94FQMsQJg3ATLdxkgc++2M
FnzcHEVQi7h8zwCmMT4deGwLJqvbyVy5SNo6GY4/Adhsf0HQzrvtWdESegoIooJK
dNWhSCuAFbXrFKGH4iBEUldigNXiCGiTwalmJ1+IIDccJQwkKC4GGU+9KEWBtYCn
OIvKkHUWPeeqNBzSeiMbFDXiK6QFe2VpNBg/iRUZwZwxibqgjgJE1rHbY098sPrL
yHRcrz6vih3wgpqZJTGdanIMk6F0MzaoHtj2egXbXaqyGf8dIdvnZJZN9gb5WDyu
ZT/ffh3XiNfBvFtsu9gosnn3m76TQ4jIb4lUesTOVZjHX2yNz3MabYet312lP4PO
qhxb1l2HGWuxnLLSxas6gzEv5arpx88ldSj6PaA86pBL/eezy59Bvn5hYrmCQ269
lVZQ19nC8y13VyCgbqcyTSpGxS+NXV0=
=+RXF
-----END PGP SIGNATURE-----
Merge tag 'thunderbolt-for-v5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-next
Mika writes:
thunderbolt: Changes for v5.11 merge window
This includes following Thunderbolt/USB4 changes for v5.11 merge window:
* DMA traffic test driver
* USB4 router NVM upgrade improvements
* USB4 router operations proxy implementation available in the recent
Intel Connection Manager firmwares
* Support for Intel Maple Ridge discrete Thunderbolt 4 controller
* A couple of cleanups and minor improvements.
* tag 'thunderbolt-for-v5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt: (22 commits)
thunderbolt: Add support for Intel Maple Ridge
thunderbolt: Add USB4 router operation proxy for firmware connection manager
thunderbolt: Move constants for USB4 router operations to tb_regs.h
thunderbolt: Add connection manager specific hooks for USB4 router operations
thunderbolt: Pass TX and RX data directly to usb4_switch_op()
thunderbolt: Pass metadata directly to usb4_switch_op()
thunderbolt: Perform USB4 router NVM upgrade in two phases
thunderbolt: Return -ENOTCONN when ERR_CONN is received
thunderbolt: Keep the parent runtime resumed for a while on device disconnect
thunderbolt: Log adapter numbers in decimal in path activation/deactivation
thunderbolt: Log which connection manager implementation is used
thunderbolt: Move max_boot_acl field to correct place in struct icm
MAINTAINERS: Add Isaac as maintainer of Thunderbolt DMA traffic test driver
thunderbolt: Add DMA traffic test driver
thunderbolt: Add support for end-to-end flow control
thunderbolt: Make it possible to allocate one directional DMA tunnel
thunderbolt: Create debugfs directory automatically for services
thunderbolt: Add functions for enabling and disabling lane bonding on XDomain
thunderbolt: Add link_speed and link_width to XDomain
thunderbolt: Create XDomain devices for loops back to the host
...
The driver uses devm_ioremap_resource() which will not be built if
CONFIG_HAS_IOMEM is not selected, so add depends on it to fix the build
failure on few archs
s390-linux-ld: drivers/phy/ingenic/phy-ingenic-usb.o: in function `ingenic_usb_phy_probe':
>> phy-ingenic-usb.c:(.text+0xb66): undefined reference to `devm_platform_ioremap_resource'
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/20201208045300.3637026-1-vkoul@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
When running concurrent iptables rules replacement with data, the per CPU
sequence count is checked after the assignment of the new information.
The sequence count is used to synchronize with the packet path without the
use of any explicit locking. If there are any packets in the packet path using
the table information, the sequence count is incremented to an odd value and
is incremented to an even after the packet process completion.
The new table value assignment is followed by a write memory barrier so every
CPU should see the latest value. If the packet path has started with the old
table information, the sequence counter will be odd and the iptables
replacement will wait till the sequence count is even prior to freeing the
old table info.
However, this assumes that the new table information assignment and the memory
barrier is actually executed prior to the counter check in the replacement
thread. If CPU decides to execute the assignment later as there is no user of
the table information prior to the sequence check, the packet path in another
CPU may use the old table information. The replacement thread would then free
the table information under it leading to a use after free in the packet
processing context-
Unable to handle kernel NULL pointer dereference at virtual
address 000000000000008e
pc : ip6t_do_table+0x5d0/0x89c
lr : ip6t_do_table+0x5b8/0x89c
ip6t_do_table+0x5d0/0x89c
ip6table_filter_hook+0x24/0x30
nf_hook_slow+0x84/0x120
ip6_input+0x74/0xe0
ip6_rcv_finish+0x7c/0x128
ipv6_rcv+0xac/0xe4
__netif_receive_skb+0x84/0x17c
process_backlog+0x15c/0x1b8
napi_poll+0x88/0x284
net_rx_action+0xbc/0x23c
__do_softirq+0x20c/0x48c
This could be fixed by forcing instruction order after the new table
information assignment or by switching to RCU for the synchronization.
Fixes: 80055dab5d ("netfilter: x_tables: make xt_replace_table wait until old rules are not used anymore")
Reported-by: Sean Tranchetti <stranche@codeaurora.org>
Reported-by: kernel test robot <lkp@intel.com>
Suggested-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
low_sleep_handler() can't restore the context from standard
stack because the stack can hardly be accessed with MMU OFF.
Store everything in a global storage area instead of storing
a pointer to the stack in that global storage area.
To avoid a complete churn of the function, still use r1 as
the pointer to the storage area during restore.
Fixes: cd08f109e2 ("powerpc/32s: Enable CONFIG_VMAP_STACK")
Reported-by: Giuseppe Sacco <giuseppe@sguazz.it>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Tested-by: Giuseppe Sacco <giuseppe@sguazz.it>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/e3e0d8042a3ba75cb4a9546c19c408b5b5b28994.1607404931.git.christophe.leroy@csgroup.eu
In pseries_devicetree_update(), with each call to ibm,update-nodes the
partition firmware communicates the node to be deleted or updated by
placing its phandle in the work buffer. Each of delete_dt_node(),
update_dt_node(), and add_dt_node() have duplicate lookups using the
phandle value and corresponding refcount management.
Move the lookup and of_node_put() into pseries_devicetree_update(),
and emit a warning on any failed lookups.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201207215200.1785968-29-nathanl@linux.ibm.com
The pseries hibernate code no longer calls into the original
join/suspend code in kernel/rtas.c, so pseries_prepare_late() and
related code don't accomplish anything now.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201207215200.1785968-27-nathanl@linux.ibm.com
The pseries hibernate code calls post_mobility_fixup() which is sort
of a dumping ground of fixups that need to run after resuming from
suspend regardless of whether suspend was a hibernation or a
migration. Calling post_mobility_fixup() from
pseries_suspend_enable_irqs() runs this code early in resume with
devices suspended and only one CPU up, while the much more commonly
used migration case runs these fixups in a more typical process
context.
Call post_mobility_fixup() after the suspend core returns a success
status to the hibernate sysfs store method and remove
pseries_suspend_enable_irqs().
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201207215200.1785968-26-nathanl@linux.ibm.com
Partitions with cache nodes in the device tree can encounter the
following warning on resume:
CPU 0 already accounted in PowerPC,POWER9@0(Data)
WARNING: CPU: 0 PID: 3177 at arch/powerpc/kernel/cacheinfo.c:197 cacheinfo_cpu_online+0x640/0x820
These calls to cacheinfo_cpu_offline/online have been redundant since
commit e610a466d1 ("powerpc/pseries/mobility: rebuild cacheinfo
hierarchy post-migration").
Fixes: e610a466d1 ("powerpc/pseries/mobility: rebuild cacheinfo hierarchy post-migration")
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201207215200.1785968-25-nathanl@linux.ibm.com
rtas_suspend_last_cpu() and related code perform a lot of work that
isn't relevant to the hibernation workflow. All other CPUs are offline
when called so there is no need to place them in H_JOIN or prod them
on resume, nor is there need for retries or operations on shared
state.
Call the rtas_ibm_suspend_me() wrapper function directly from
pseries_suspend_enter() instead of using rtas_suspend_last_cpu().
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201207215200.1785968-23-nathanl@linux.ibm.com
rtas_suspend_cpu() no longer has users; remove it and
__rtas_suspend_cpu() which now becomes unused as well.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201207215200.1785968-22-nathanl@linux.ibm.com
Since commit 48f6e7f6d9 ("powerpc/pseries: remove cede offline state
for CPUs"), ppc_md.suspend_disable_cpu() is no longer used and all
CPUs (save one) are placed into true offline state as opposed to
H_JOIN. So pseries_suspend_cpu() is effectively unused; remove it.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201207215200.1785968-20-nathanl@linux.ibm.com
There is no need for the stream id to be a file-global variable; pass
it from hibernate_store() to pseries_suspend_begin() for the
H_VASI_STATE call.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201207215200.1785968-19-nathanl@linux.ibm.com
There are three ways pseries_suspend_begin() can be reached:
1. When "mem" is written to /sys/power/state:
kobj_attr_store()
-> state_store()
-> pm_suspend()
-> suspend_devices_and_enter()
-> pseries_suspend_begin()
This never works because there is no way to supply a valid stream id
using this interface, and H_VASI_STATE is called with a stream id of
zero. So this call path is useless at best.
2. When a stream id is written to /sys/devices/system/power/hibernate.
pseries_suspend_begin() is polled directly from store_hibernate()
until the stream is in the "Suspending" state (i.e. the platform is
ready for the OS to suspend execution):
dev_attr_store()
-> store_hibernate()
-> pseries_suspend_begin()
3. When a stream id is written to /sys/devices/system/power/hibernate
(continued). After #2, pseries_suspend_begin() is called once again
from the pm core:
dev_attr_store()
-> store_hibernate()
-> pm_suspend()
-> suspend_devices_and_enter()
-> pseries_suspend_begin()
This is redundant because the VASI suspend state is already known to
be Suspending.
The begin() callback of platform_suspend_ops is optional, so we can
simply remove that assignment with no loss of function.
Fixes: 32d8ad4e62 ("powerpc/pseries: Partition hibernation support")
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201207215200.1785968-18-nathanl@linux.ibm.com
rtas_ibm_suspend_me_unsafe() is now unused; remove it and
rtas_percpu_suspend_me() which becomes unused as a result.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201207215200.1785968-17-nathanl@linux.ibm.com
sys_rtas() cannot call ibm,suspend-me directly in the same way it
handles other inputs. Instead it must dispatch the request to code
that can first perform the H_JOIN sequence before any call to
ibm,suspend-me can succeed. Over time kernel/rtas.c has accreted a fair
amount of platform-specific code to implement this.
Since a different, more robust implementation of the suspend sequence
is now in the pseries platform code, we want to dispatch the request
there.
Note that invoking ibm,suspend-me via the RTAS syscall is all but
deprecated; this change preserves ABI compatibility for old programs
while providing to them the benefit of the new partition suspend
implementation. This is a behavior change in that the kernel performs
the device tree update and firmware activation before returning, but
experimentation indicates this is tolerated fine by legacy user space.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201207215200.1785968-16-nathanl@linux.ibm.com
This is a mitigation for the relatively rare occurrence where a
virtual IOA can be in a transient state that prevents the
suspend/migration from succeeding, resulting in an error from
ibm,suspend-me.
If the join/suspend sequence returns an error, it is acceptable to
retry as long as the VASI suspend session state is still
"Suspending" (i.e. the platform is still waiting for the OS to
suspend).
Retry a few times on suspend failure while this condition holds,
progressively increasing the delay between attempts. We don't want to
retry indefinitey because firmware emits an error log event on each
unsuccessful attempt.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201207215200.1785968-15-nathanl@linux.ibm.com
If we're returning an error to user space, use H_VASI_SIGNAL to send a
cancellation request to the platform. This isn't strictly required but
it communicates that Linux will not attempt to complete the suspend,
which allows the various entities involved to promptly end the
operation in progress.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201207215200.1785968-14-nathanl@linux.ibm.com
The partition suspend sequence as specified in the platform
architecture requires that all active processor threads call
H_JOIN, which:
- suspends the calling thread until it is the target of
an H_PROD; or
- immediately returns H_CONTINUE, if the calling thread is the last to
call H_JOIN. This thread is expected to call ibm,suspend-me to
completely suspend the partition.
Upon returning from ibm,suspend-me the calling thread must wake all
others using H_PROD.
rtas_ibm_suspend_me_unsafe() uses on_each_cpu() to implement this
protocol, but because of its synchronizing nature this is susceptible
to deadlock versus users of stop_machine() or other callers of
on_each_cpu().
Not only is stop_machine() intended for use cases like this, it
handles error propagation and allows us to keep the data shared
between CPUs minimal: a single atomic counter which ensures exactly
one CPU will wake the others from their joined states.
Switch the migration code to use stop_machine() and a less complex
local implementation of the H_JOIN/ibm,suspend-me logic, which
carries additional benefits:
- more informative error reporting, appropriately ratelimited
- resets the lockup detector / watchdog on resume to prevent lockup
warnings when the OS has been suspended for a time exceeding the
threshold.
Fixes: 91dc182ca6 ("[PATCH] powerpc: special-case ibm,suspend-me RTAS call")
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201207215200.1785968-13-nathanl@linux.ibm.com
The behavior of rtas_ibm_suspend_me_unsafe() is to return -EAGAIN to
the caller until the specified VASI suspend session state makes the
transition from H_VASI_ENABLED to H_VASI_SUSPENDING. In the interest
of separating concerns to prepare for a new implementation of the
join/suspend sequence, extract VASI session polling logic into a
couple of local functions. Waiting for the session state to reach
H_VASI_SUSPENDING before calling rtas_ibm_suspend_me_unsafe() ensures
that we will never get an EAGAIN result necessitating a retry. No
user-visible change in behavior is intended.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201207215200.1785968-12-nathanl@linux.ibm.com
