linux-stable.git/drivers/bus, branch v5.7.7

bus: ti-sysc: Fix uninitialized framedonetv_irq

2020-06-30T19:35:59+00:00

[ Upstream commit 085bc0e576a4bf53b67a917c54908f299a2fb949 ]

We are currently only setting the framedonetv_irq disabled for the SoCs
that don't have it. But we are never setting it enabled for the SoCs that
have it. Let's initialized it to true by default.

Fixes: 7324a7a0d5e2 ("bus: ti-sysc: Implement display subsystem reset quirk")
Cc: Laurent Pinchart 
Cc: Tomi Valkeinen 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin

bus: ti-sysc: Ignore clockactivity unless specified as a quirk

2020-06-30T19:35:59+00:00

[ Upstream commit 08b91dd6e547467fad61a7c201ff71080d7ad65a ]

We must ignore the clockactivity bit for most modules and not set it
unless specified for the module with SYSC_QUIRK_USE_CLOCKACT. Otherwise
the interface clock can be automatically gated constantly causing
unexpected performance issues.

Fixes: ae9ae12e9daa ("bus: ti-sysc: Handle clockactivity for enable and disable")
Cc: Laurent Pinchart 
Cc: Tomi Valkeinen 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin

bus: ti-sysc: Use optional clocks on for enable and wait for softreset bit

2020-06-30T19:35:59+00:00

[ Upstream commit d46f9fbec71997420e4fb83c04d9affdf423f879 ]

Some modules reset automatically when idled, and when re-enabled, we must
wait for the automatic OCP softreset to complete. And if optional clocks
are configured, we need to keep the clocks on while waiting for the reset
to complete.

Let's fix the issue by moving the OCP softreset code to a separate
function sysc_wait_softreset(), and call it also from sysc_enable_module()
with the optional clocks enabled.

This is based on what we're already doing for legacy platform data booting
in _enable_sysc().

Fixes: 7324a7a0d5e2 ("bus: ti-sysc: Implement display subsystem reset quirk")
Reported-by: Faiz Abbas 
Cc: Laurent Pinchart 
Cc: Tomi Valkeinen 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin

bus: ti-sysc: Flush posted write on enable and disable

2020-06-30T19:35:59+00:00

[ Upstream commit 5ce8aee81be6c8bc19051d7c7b0d3cbb7ac5fc3f ]

Looks like we're missing flush of posted write after module enable and
disable. I've seen occasional errors accessing various modules, and it
is suspected that the lack of posted writes can also cause random reboots.

The errors we can see are similar to the one below from spi for example:

44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Read): Data Access
in User mode during Functional access
...
mcspi_wait_for_reg_bit
omap2_mcspi_transfer_one
spi_transfer_one_message
...

We also want to also flush posted write for disable. The clkctrl clock
disable happens after module disable, and we don't want to have the
module potentially stay active while we're trying to disable the clock.

Fixes: d59b60564cbf ("bus: ti-sysc: Add generic enable/disable functions")
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin

bus: mhi: core: Read transfer length from an event properly

2020-06-24T15:48:53+00:00

[ Upstream commit ee75cedf82d832561af8ba8380aeffd00a9eea77 ]

When MHI Driver receives an EOT event, it reads xfer_len from the
event in the last TRE. The value is under control of the MHI device
and never validated by Host MHI driver. The value should never be
larger than the real size of the buffer but a malicious device can
set the value 0xFFFF as maximum. This causes driver to memory
overflow (both read or write). Fix this issue by reading minimum of
transfer length from event and the buffer length provided.

Signed-off-by: Hemant Kumar 
Signed-off-by: Bhaumik Bhatt 
Reviewed-by: Jeffrey Hugo 
Reviewed-by: Manivannan Sadhasivam 
Signed-off-by: Manivannan Sadhasivam 
Link: https://lore.kernel.org/r/20200521170249.21795-5-manivannan.sadhasivam@linaro.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

bus: mhi: core: Fix some error return code

2020-05-15T14:32:20+00:00

Fix to return negative error code from the error handling case
instead of 0 in mhi_init_dev_ctxt() and mhi_driver_probe().

Fixes: 3000f85b8f47 ("bus: mhi: core: Add support for basic PM operations")
Reported-by: Hulk Robot 
Signed-off-by: Wei Yongjun 
Reviewed-by: Manivannan Sadhasivam 
Link: https://lore.kernel.org/r/20200509075654.175002-1-weiyongjun1@huawei.com
Signed-off-by: Greg Kroah-Hartman

bus: mhi: core: Fix channel device name conflict

2020-05-05T14:59:54+00:00

When multiple instances of the same MHI product are present in a system,
we can see a splat from mhi_create_devices() - "sysfs: cannot create
duplicate filename".

This is because the device names assigned to the MHI channel devices are
non-unique.  They consist of the channel's name, and the channel's pipe
id.  For identical products, each instance is going to have the same
set of channel (both in name and pipe id).

To fix this, we prepend the device name of the parent device that the
MHI channels belong to.  Since different instances of the same product
should have unique device names, this makes the MHI channel devices for
each product also unique.

Additionally, remove the pipe id from the MHI channel device name.  This
is an internal detail to the MHI product that provides little value, and
imposes too much device specific internal details to userspace.  It is
expected that channel with a specific name (ie "SAHARA") has a specific
client, and it does not matter what pipe id that channel is enumerated on.
The pipe id is an internal detail between the MHI bus, and the hardware.
The client is not expected to make decisions based on the pipe id, and to
do so would require the client to have intimate knowledge of the hardware,
which is inappropiate as it may violate the layering provided by the MHI
bus.  The limitation of doing this is that each product may only have one
instance of a channel by a unique name.  This limitation is appropriate
given the usecases of MHI channels.

Signed-off-by: Jeffrey Hugo 
Reviewed-by: Hemant Kumar 
Reviewed-by: Manivannan Sadhasivam 
Signed-off-by: Manivannan Sadhasivam 
Link: https://lore.kernel.org/r/20200430190555.32741-7-manivannan.sadhasivam@linaro.org
Signed-off-by: Greg Kroah-Hartman

bus: mhi: core: Offload register accesses to the controller

2020-05-05T14:58:35+00:00

When reading or writing MHI registers, the core assumes that the physical
link is a memory mapped PCI link.  This assumption may not hold for all
MHI devices.  The controller knows what is the physical link (ie PCI, I2C,
SPI, etc), and therefore knows the proper methods to access that link.
The controller can also handle link specific error scenarios, such as
reading -1 when the PCI link went down.

Therefore, it is appropriate that the MHI core requests the controller to
make register accesses on behalf of the core, which abstracts the core
from link specifics, and end up removing an unnecessary assumption.

Signed-off-by: Jeffrey Hugo 
Reviewed-by: Hemant Kumar 
Reviewed-by: Manivannan Sadhasivam 
Signed-off-by: Manivannan Sadhasivam 
Link: https://lore.kernel.org/r/20200430190555.32741-5-manivannan.sadhasivam@linaro.org
Signed-off-by: Greg Kroah-Hartman

bus: mhi: core: Remove link_status() callback

2020-05-05T14:58:35+00:00

If the MHI core detects invalid data due to a PCI read, it calls into
the controller via link_status() to double check that the link is infact
down.  All in all, this is pretty pointless, and racy.  There are no good
reasons for this, and only drawbacks.

Its pointless because chances are, the controller is going to do the same
thing to determine if the link is down - attempt a PCI access and compare
the result.  This does not make the link status decision any smarter.

Its racy because its possible that the link was down at the time of the
MHI core access, but then recovered before the controller access.  In this
case, the controller will indicate the link is not down, and the MHI core
will precede to use a bad value as the MHI core does not attempt to retry
the access.

Retrying the access in the MHI core is a bad idea because again, it is
racy - what if the link is down again?  Furthermore, there may be some
higher level state associated with the link status, that is now invalid
because the link went down.

The only reason why the MHI core could see "invalid" data when doing a PCI
access, that is actually valid, is if the register actually contained the
PCI spec defined sentinel for an invalid access.  In this case, it is
arguable that the MHI implementation broken, and should be fixed, not
worked around.

Therefore, remove the link_status() callback before anyone attempts to
implement it.

Signed-off-by: Jeffrey Hugo 
Reviewed-by: Manivannan Sadhasivam 
Reviewed-by: Hemant Kumar 
Signed-off-by: Manivannan Sadhasivam 
Link: https://lore.kernel.org/r/20200430190555.32741-4-manivannan.sadhasivam@linaro.org
Signed-off-by: Greg Kroah-Hartman

bus: mhi: core: Make sure to powerdown if mhi_sync_power_up fails

2020-05-05T14:58:35+00:00

Powerdown is necessary if mhi_sync_power_up fails due to a timeout, to
clean up the resources.  Otherwise a BUG could be triggered when
attempting to clean up MSIs because the IRQ is still active from a
request_irq().

Signed-off-by: Jeffrey Hugo 
Reviewed-by: Hemant Kumar 
Reviewed-by: Manivannan Sadhasivam 
Signed-off-by: Manivannan Sadhasivam 
Link: https://lore.kernel.org/r/20200430190555.32741-3-manivannan.sadhasivam@linaro.org
Signed-off-by: Greg Kroah-Hartman