| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
strcpy() performs no bounds checking on the destination buffer. This
could result in linear overflows beyond the end of the buffer, leading
to all kinds of misbehaviors. So, use memcpy() as a safe replacement.
This is a previous step in the path to remove the strcpy() function
entirely from the kernel.
Signed-off-by: Len Baker <len.baker@gmx.com>
Link: https://lore.kernel.org/r/20210808125012.4715-3-len.baker@gmx.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Opencode a copy of mrq_debug_read() in bpmp_debug_show() so that it
can use seq_write() directly instead of poking holes into the seq_file
abstractions using seq_get_buf().
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The FUSE clock should be enabled during suspend on Tegra124. Currently
clk driver enables it on all SoCs, but FUSE may require a higher core
voltage on Tegra30 while enabled. Move the quirk into the FUSE driver
and make it specific to Tegra124.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The Tegra FUSE belongs to the core power domain and we're going to enable
GENPD support for the core domain. Now FUSE device must be resumed using
runtime PM API in order to initialize the FUSE power state. Add runtime PM
support to the FUSE driver.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The fuse->clk must be cleared if FUSE driver fails to probe, otherwise
tegra_fuse_readl() will crash. It's unlikely to happen in practice,
nevertheless let's correct it for completeness.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Both PMC and cpuidle drivers are probed at the same init level and
cpuidle depends on the PMC suspend mode. Add new default suspend mode
that indicates whether PMC driver has been probed and reset the mode in
a case of deferred probe of the PMC driver.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Remove including <linux/version.h> that don't need it.
V1->V2: Split the patch in two
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Update the PRUSS schema file to include the dma-coherent property
that indicates the coherency of the IP. The PRUSS IPs on 66AK2G
SoCs do use this property.
The new added dma-coherent property is a required property _only_
for 66AK2G SoCs and is not required/applicable for other SoCs, so
the binding is backward compatible for other SoCs. This update is
being done before the corresponding dts nodes can be added for 66AK2G
SoCs.
Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
|
|
For the smartreflex device, we need to disable smartreflex on SoC idle,
and have been using pm_runtime_irq_safe() to do that. But we want to
remove the irq_safe usage as PM runtime takes a permanent usage count
on the parent device with it.
In order to remove the need for pm_runtime_irq_safe(), let's gate
the clock directly in the driver. This removes the need to call PM runtime
during idle, and allows us to switch to using CPU_PM in the following
patch.
Note that the smartreflex interconnect target module is configured for smart
idle, but the clock does not have autoidle capability, and needs to be gated
manually. If the clock supported autoidle, we would not need to even gate
the clock.
With this change, we can now remove the related quirk flags for ti-sysc
also.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
|
|
The K3 AM64x family of SoCs have a similar version of the PRU-ICSS (ICSSG)
processor subsystem present on K3 J721E and K3 AM65x SR2.0 SoCs. These SoCs
contain typically two ICSSG instances named ICSSG0 and ICSSG1. The two
ICSSGs are identical to each other for the most part with minor SoC
integration differences and capabilities. SGMII mode is not supported at
all on these SoCs (unlike specific instances on AM65x, J721E). The ICSSG1
also has limited pins connected on some sub-modules compared to ICSSG0.
There is no change in the Interrupt Controller w.r.t either of AM65x or
J721E SoCs. All other integration aspects are also very similar to the
existing SoCs.
The existing pruss platform driver has been updated to support these
similar ICSSG instances through a new AM64x specific compatible.
Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
|
|
The K3 AM64x SoCs also have the Gigabit Ethernet capable PRU-ICSS IP
that is present on existing K3 AM65x and J721E SoCs (ICSSG). The IP
is similar to the ones used on K3 J721E or AM65x SR2.0 SoCs.
Update the PRUSS bindings for these ICSSG instances.
Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
|
|
Use a WARN_ON() when SCMI stack is loaded to check the consistency of
configured SCMI transports instead of the current compile-time check
BUILD_BUG_ON() to avoid breaking bot-builds on random bad configs.
Bail-out early and noisy during SCMI stack initialization if no transport
was enabled in configuration since SCMI cannot work without at least one
enabled transport and such constraint cannot be enforced in Kconfig due to
circular dependency issues.
Link: https://lore.kernel.org/r/20210809092245.8730-1-cristian.marussi@arm.com
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
drivers/firmware/arm_scmi/virtio.c:225:40-45: WARNING: conversion to bool not needed here
Remove unneeded conversion to bool
Semantic patch information:
Relational and logical operators evaluate to bool,
explicit conversion is overly verbose and unneeded.
Generated by: scripts/coccinelle/misc/boolconv.cocci
Link: https://lore.kernel.org/r/20210807173127.GA43248@a24dbc127934
CC: Igor Skalkin <igor.skalkin@opensynergy.com>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: kernel test robot <lkp@intel.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
The UFOE (data compression engine) component needs to be enabled to have
the imgtec gpu driver working. If we don't enable it we see a black screen.
Looks like when we switched to use and array for setting the routing
registers in commit 440147639ac7 ("soc: mediatek: mmsys: Use an array for
setting the routing registers") we missed to add this component in the new
routing table, it was present before that commit, so fix it by adding
this component in the mt8173 routing table.
Fixes: 440147639ac7 ("soc: mediatek: mmsys: Use an array for setting the routing registers")
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Tested-by: Eizan Miyamoto <eizan@chromium.org>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210625062448.3462177-1-enric.balletbo@collabora.com
[mb: taking into account mask value]
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Add DSI mmsys connections for the MT8365 SoC.
Signed-off-by: Fabien Parent <fparent@baylibre.com>
Link: https://lore.kernel.org/r/20210519161847.3747352-3-fparent@baylibre.com
[mb: take the mask field into account]
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Mailbox channels for the base protocol are setup during probe.
There can be a scenario where probe fails to acquire the base
protocol due to a timeout leading to cleaning up of all device
managed memory including the scmi_mailbox structure setup during
mailbox_chan_setup function.
| arm-scmi soc:qcom,scmi: timed out in resp(caller: version_get+0x84/0x140)
| arm-scmi soc:qcom,scmi: unable to communicate with SCMI
| arm-scmi: probe of soc:qcom,scmi failed with error -110
Now when a message arrives at cpu slightly after the timeout, the mailbox
controller will try to call the rx_callback of the client and might end
up accessing freed memory.
| rx_callback+0x24/0x160
| mbox_chan_received_data+0x44/0x94
| __handle_irq_event_percpu+0xd4/0x240
This patch frees the mailbox channels setup during probe and adds some more
error handling in case the probe fails.
Link: https://lore.kernel.org/r/1628111999-21595-1-git-send-email-rishabhb@codeaurora.org
Tested-by: Cristian Marussi <cristian.marussi@arm.com>
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
This transport enables communications with an SCMI platform through virtio;
the SCMI platform will be represented by a virtio device.
Implement an SCMI virtio driver according to the virtio SCMI device spec
[1]. Virtio device id 32 has been reserved for the SCMI device [2].
The virtio transport has one Tx channel (virtio cmdq, A2P channel) and
at most one Rx channel (virtio eventq, P2A channel).
The following feature bit defined in [1] is not implemented:
VIRTIO_SCMI_F_SHARED_MEMORY.
The number of messages which can be pending simultaneously is restricted
according to the virtqueue capacity negotiated at probing time.
As soon as Rx channel message buffers are allocated or have been read
out by the arm-scmi driver, feed them back to the virtio device.
Since some virtio devices may not have the short response time exhibited
by SCMI platforms using other transports, set a generous response
timeout.
SCMI polling mode is not supported by this virtio transport since deemed
meaningless: polling mode operation is offered by the SCMI core to those
transports that could not provide a completion interrupt on the TX path,
which is never the case for virtio whose core callbacks can easily call
into core scmi_rx_callback upon messages reception.
[1] https://github.com/oasis-tcs/virtio-spec/blob/master/virtio-scmi.tex
[2] https://www.oasis-open.org/committees/ballot.php?id=3496
Link: https://lore.kernel.org/r/20210803131024.40280-16-cristian.marussi@arm.com
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Co-developed-by: Peter Hilber <peter.hilber@opensynergy.com>
Co-developed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Igor Skalkin <igor.skalkin@opensynergy.com>
[ Peter: Adapted patch for submission to upstream. ]
Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com>
[ Cristian: simplified driver logic, changed link_supplier and channel
available/setup logic, removed dummy callbacks ]
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Add a new opaque void *priv parameter to scmi_rx_callback which can be
optionally provided by the transport layer when invoking scmi_rx_callback
and that will be passed back to the transport layer in xfer->priv.
This can be used by transports that needs to keep track of their specific
data structures together with the valid xfers.
Link: https://lore.kernel.org/r/20210803131024.40280-15-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Document the properties for arm,scmi-virtio compatible nodes.
The backing virtio SCMI device is described in patch [1].
While doing that, make shmem property required only for pre-existing
mailbox and smc transports, since virtio-scmi does not need it.
[1] https://lists.oasis-open.org/archives/virtio-comment/202102/msg00018.html
Link: https://lore.kernel.org/r/20210803131024.40280-14-cristian.marussi@arm.com
Co-developed-by: Peter Hilber <peter.hilber@opensynergy.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Igor Skalkin <igor.skalkin@opensynergy.com>
[ Peter: Adapted patch for submission to upstream. ]
Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com>
[ Cristian: converted to yaml format, moved shmen required property. ]
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Some transports are also effectively registered with other kernel subsystem
in order to be properly probed and initialized; as a consequence such kind
of transports, and their related devices, might still not have been probed
and initialized at the time the main SCMI core driver is probed.
Add an optional .link_supplier() transport operation which can be used by
the core SCMI stack to dynamically check if the transport is ready and
dynamically link its device to the SCMI platform instance device.
Link: https://lore.kernel.org/r/20210803131024.40280-13-cristian.marussi@arm.com
Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com>
[ Cristian: reworded commit message ]
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Add abstractions for future transports using message passing, such as
virtio. Derive the abstractions from the shared memory abstractions.
Abstract the transport SDU through the opaque struct scmi_msg_payld.
Also enable the transport to determine all other required information
about the transport SDU.
Link: https://lore.kernel.org/r/20210803131024.40280-12-cristian.marussi@arm.com
Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com>
[ Cristian: Adapted to new SCMI Kconfig layout, updated Copyrights ]
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
The maximum number of simultaneously pending messages is a transport
specific quantity that is usually described statically in struct scmi_desc.
Some transports, though, can calculate such number only at run-time after
some initial transport specific setup and probing is completed; moreover
the resulting max message numbers could also be different between rx and
tx channels.
Add an optional get_max_msg() operation so that a transport can report more
accurate max message numbers for each channel type.
The value in scmi_desc.max_msg is still used as default when transport does
not provide any get_max_msg() method.
Link: https://lore.kernel.org/r/20210803131024.40280-11-cristian.marussi@arm.com
Co-developed-by: Peter Hilber <peter.hilber@opensynergy.com>
Co-developed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Igor Skalkin <igor.skalkin@opensynergy.com>
[ Peter: Adapted patch for submission to upstream. ]
Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com>
[ Cristian: refactored how get_max_msg() is used to minimize core changes ]
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Upcoming new SCMI transports won't need any kind of shared memory support.
Compile shmem.c only if a shmem based transport is selected.
Link: https://lore.kernel.org/r/20210803131024.40280-10-cristian.marussi@arm.com
Co-developed-by: Peter Hilber <peter.hilber@opensynergy.com>
Signed-off-by: Igor Skalkin <igor.skalkin@opensynergy.com>
[ Peter: Adapted patch for submission to upstream. ]
Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com>
[ Cristian: Adapted patch/commit_msg to new SCMI Kconfig layout ]
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Add configuration options to be able to select which SCMI transports have
to be compiled into the SCMI stack.
Mailbox and SMC are by default enabled if their related dependencies are
satisfied.
While doing that move all SCMI related config options in their own
dedicated submenu.
Link: https://lore.kernel.org/r/20210803131024.40280-9-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Add a check for the presence of .poll_done transport operation so that
transports that do not need to support polling mode have no need to provide
a dummy .poll_done callback either and polling mode can be disabled in the
SCMI core for that tranport.
Link: https://lore.kernel.org/r/20210803131024.40280-8-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Make transport operation .clear_channel optional since some transports
do not need it and so avoid to have them implement dummy callbacks.
Link: https://lore.kernel.org/r/20210803131024.40280-7-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Even though in case of asynchronous commands an SCMI platform is
constrained to emit the delayed response message only after the related
message response has been sent, the configured underlying transport could
still deliver such messages together or in inverted order, causing races
due to the concurrent or out-of-order access to the underlying xfer.
Introduce a mechanism to grant exclusive access to an xfer in order to
properly serialize concurrent accesses to the same xfer originating from
multiple correlated messages.
Add additional state information to xfer descriptors so as to be able to
identify out-of-order message deliveries and act accordingly:
- when a delayed response is expected but delivered before the related
response, the synchronous response is considered as successfully
received and the delayed response processing is carried on as usual.
- when/if the missing synchronous response is subsequently received, it
is discarded as not congruent with the current state of the xfer, or
simply, because the xfer has been already released and so, now, the
monotonically increasing sequence number carried by the late response
is stale.
Link: https://lore.kernel.org/r/20210803131024.40280-6-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Tokens are sequence numbers embedded in the each SCMI message header: they
are used to correlate commands with responses (and delayed responses), but
their usage and policy of selection is entirely up to the caller (usually
the OSPM agent), while they are completely opaque to the callee (i.e. SCMI
platform) which merely copies them back from the command into the response
message header.
This also means that the platform does not, can not and should not enforce
any kind of policy on received messages depending on the contained sequence
number: platform can perfectly handle concurrent requests carrying the same
identifiying token if that should happen.
Moreover the platform is not required to produce in-order responses to
agent requests, the only constraint in these regards is that in case of
an asynchronous message the delayed response must be sent after the
immediate response for the synchronous part of the command transaction.
Currenly the SCMI stack of the OSPM agent selects a token for the egressing
commands picking the lowest possible number which is not already in use by
an existing in-flight transaction, which means, in other words, that we
immediately reuse any token after its transaction has completed or it has
timed out: this policy indeed does simplify management and lookup of tokens
and associated xfers.
Under the above assumptions and constraints, since there is really no state
shared between the agent and the platform to let the platform know when a
token and its associated message has timed out, the current policy of early
reuse of tokens can easily lead to the situation in which a spurious or
late received response (or delayed_response), related to an old stale and
timed out transaction, can be wrongly associated to a newer valid in-flight
xfer that just happens to have reused the same token.
This misbehaviour on such late/spurious responses is more easily exposed on
those transports that naturally have an higher level of parallelism in
processing multiple concurrent in-flight messages.
This commit introduces a new policy of selection of tokens for the OSPM
agent: each new command transfer now gets the next available, monotonically
increasing token, until tokens are exhausted and the counter rolls over.
Such new policy mitigates the above issues with late/spurious responses
since the tokens are now reused as late as possible (when they roll back
ideally) and so it is much easier to identify such late/spurious responses
to stale timed out transactions: this also helps in simplifying the
specific transports implementation since stale transport messages can be
easily identified and discarded early on in the rx path without the need
to cross check their actual state with the core transport layer.
This mitigation is even more effective when, as is usually the case, the
maximum number of pending messages is capped by the platform to a much
lower number than the whole possible range of tokens values (2^10).
This internal policy change in the core SCMI transport layer is fully
transparent to the specific transports so it has not and should not have
any impact on the transports implementation.
Link: https://lore.kernel.org/r/20210803131024.40280-5-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Some SCMI transport could need to perform some transport specific setup
before they can be used by the SCMI core transport layer: typically this
early setup consists in registering with some other kernel subsystem.
Add the optional capability for a transport to provide a couple of init
and exit functions that are assured to be called early during the SCMI
core initialization phase, well before the SCMI core probing step.
[ Peter: Adapted RFC patch by Cristian for submission to upstream. ]
Link: https://lore.kernel.org/r/20210803131024.40280-4-cristian.marussi@arm.com
Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com>
[ Cristian: Fixed scmi_transports_exit point of invocation ]
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Being a while that we have SCMI trace events in the SCMI stack, remove
this debug helper and its call sites.
Link: https://lore.kernel.org/r/20210803131024.40280-3-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Add SCMI type handling to pack/unpack_scmi_header common helper functions.
Initialize hdr.type properly when initializing a command xfer.
Link: https://lore.kernel.org/r/20210803131024.40280-2-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
SOUT has many bits and need to be cleared before set new value.
Write only could do the clear, but for MOUT, it clears bits that
should not be cleared. So use a mask to reset only the needed bits.
this fixes HDMI issues on MT7623/BPI-R2 since 5.13
Fixes: 440147639ac7 ("soc: mediatek: mmsys: Use an array for setting the routing registers")
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Signed-off-by: CK Hu <ck.hu@mediatek.com>
Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Reviewed-by: Hsin-Yi Wang <hsinyi@chromium.org>
Link: https://lore.kernel.org/r/20210729070549.5514-1-linux@fw-web.de
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
This rewrites the IXP4xx CF (IDE) libata driver to use the
device tree exclusively to look up its resources:
- Probe exclusively from the device tree and look up all
resources from there.
- Allocate a local state container with devres and pass
this around in .private_data.
- Initialize with struct ata_port_info.
- Use the .set_piomode() callback instead of the much
wider .set_mode(), we only support PIO after all.
- Bump driver version number from 0.2 to 1.0 to reflect this
wider change.
- Get a handle on the expansion bus syscon regmap to alter
the timings on the chip select.
- Put in the more elaborate timing adjustment code for PIO0
to PIO4 in 8 and 16bit mode from the downstream OpenWrt
patch.
The board file initialization path and platform data include
is dropped because the board files will be deleted at the same
time as this patch is merged.
The platform data file is not deleted right now so as not to
conflict with the removal of board files.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
Len Baker
Christoph Hellwig
Dmitry Osipenko
Cai Huoqing
Suman Anna
Tony Lindgren
Cristian Marussi
kernel test robot
Enric Balletbo i Serra
Fabien Parent
Rishabh Bhatnagar
Igor Skalkin
Peter Hilber
CK Hu
Linus Walleij