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

bus: ti-sysc: Do not disable on suspend for no-idle

2020-07-22T07:34:07+00:00

[ Upstream commit a55de412228cc5a2b4bf8d2a09849898102633e2 ]

If we have "ti,no-idle" specified for a module we must not disable
the the module on suspend to keep things backwards compatible.

Fixes: 386cb76681ca ("bus: ti-sysc: Handle missed no-idle property in addition to no-idle-on-init")
Reported-by: Grygorii Strashko 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin

bus: ti-sysc: Fix sleeping function called from invalid context for RTC quirk

2020-07-22T07:34:07+00:00

[ Upstream commit afe6f1eeb08f85e57f0a02b71efb5a0839606aac ]

With CONFIG_DEBUG_ATOMIC_SLEEP enabled we can see the following with RTC probe:

BUG: sleeping function called from invalid context at drivers/bus/ti-sysc.c:1736
...
(sysc_quirk_rtc) from [] (sysc_write_sysconfig+0x1c/0x60)
(sysc_write_sysconfig) from [] (sysc_enable_module+0x11c/0x274)
(sysc_enable_module) from [] (sysc_probe+0xe9c/0x1380)
(sysc_probe) from [] (platform_drv_probe+0x48/0x98)

Fixes: e8639e1c986a ("bus: ti-sysc: Handle module unlock quirk needed for some RTC")
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin

bus: ti-sysc: Fix wakeirq sleeping function called from invalid context

2020-07-22T07:34:07+00:00

[ Upstream commit 9f9113925018d500a95df539014d9ff11ac2c02d ]

With CONFIG_DEBUG_ATOMIC_SLEEP enabled we can see the following with
wakeirqs and serial console idled:

BUG: sleeping function called from invalid context at drivers/bus/ti-sysc.c:242
...
(sysc_wait_softreset) from [] (sysc_enable_module+0x48/0x274)
(sysc_enable_module) from [] (sysc_runtime_resume+0x19c/0x1d8)
(sysc_runtime_resume) from [] (sysc_child_runtime_resume+0x58/0x84)
(sysc_child_runtime_resume) from [] (__rpm_callback+0x30/0x12c)
(__rpm_callback) from [] (rpm_callback+0x20/0x80)
(rpm_callback) from [] (rpm_resume+0x638/0x7fc)
(rpm_resume) from [] (__pm_runtime_resume+0x60/0x9c)
(__pm_runtime_resume) from [] (handle_threaded_wake_irq+0x24/0x60)
(handle_threaded_wake_irq) from [] (irq_thread_fn+0x1c/0x78)
(irq_thread_fn) from [] (irq_thread+0x140/0x26c)

We have __pm_runtime_resume() call the sysc_runtime_resume() with spinlock
held and interrupts disabled.

Fixes: d46f9fbec719 ("bus: ti-sysc: Use optional clocks on for enable and wait for softreset bit")
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin

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