<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/bus, branch v4.19.166</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>bus: fsl-mc: fix error return code in fsl_mc_object_allocate()</title>
<updated>2020-12-30T10:26:02+00:00</updated>
<author>
<name>Zhang Changzhong</name>
<email>zhangchangzhong@huawei.com</email>
</author>
<published>2020-12-04T08:02:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c9144c551fb0b5ecc89e5a728bda90e03345efde'/>
<id>c9144c551fb0b5ecc89e5a728bda90e03345efde</id>
<content type='text'>
[ Upstream commit 3d70fb03711c37bc64e8e9aea5830f498835f6bf ]

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.

Fixes: 197f4d6a4a00 ("staging: fsl-mc: fsl-mc object allocator driver")
Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Acked-by: Laurentiu Tudor &lt;laurentiu.tudor@nxp.com&gt;
Signed-off-by: Zhang Changzhong &lt;zhangchangzhong@huawei.com&gt;
Link: https://lore.kernel.org/r/1607068967-31991-1-git-send-email-zhangchangzhong@huawei.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 3d70fb03711c37bc64e8e9aea5830f498835f6bf ]

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.

Fixes: 197f4d6a4a00 ("staging: fsl-mc: fsl-mc object allocator driver")
Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Acked-by: Laurentiu Tudor &lt;laurentiu.tudor@nxp.com&gt;
Signed-off-by: Zhang Changzhong &lt;zhangchangzhong@huawei.com&gt;
Link: https://lore.kernel.org/r/1607068967-31991-1-git-send-email-zhangchangzhong@huawei.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mips: cdmm: fix use-after-free in mips_cdmm_bus_discover</title>
<updated>2020-12-30T10:25:57+00:00</updated>
<author>
<name>Qinglang Miao</name>
<email>miaoqinglang@huawei.com</email>
</author>
<published>2020-11-20T07:48:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=84f341fa31faf4233a283d46fe4f6dc9b3026539'/>
<id>84f341fa31faf4233a283d46fe4f6dc9b3026539</id>
<content type='text'>
[ Upstream commit f0e82242b16826077a2775eacfe201d803bb7a22 ]

kfree(dev) has been called inside put_device so anther
kfree would cause a use-after-free bug/

Fixes: 8286ae03308c ("MIPS: Add CDMM bus support")
Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: Qinglang Miao &lt;miaoqinglang@huawei.com&gt;
Acked-by: Serge Semin &lt;fancer.lancer@gmail.com&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit f0e82242b16826077a2775eacfe201d803bb7a22 ]

kfree(dev) has been called inside put_device so anther
kfree would cause a use-after-free bug/

Fixes: 8286ae03308c ("MIPS: Add CDMM bus support")
Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: Qinglang Miao &lt;miaoqinglang@huawei.com&gt;
Acked-by: Serge Semin &lt;fancer.lancer@gmail.com&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bus/fsl_mc: Do not rely on caller to provide non NULL mc_io</title>
<updated>2020-11-05T10:08:43+00:00</updated>
<author>
<name>Diana Craciun</name>
<email>diana.craciun@oss.nxp.com</email>
</author>
<published>2020-09-29T08:54:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9c95724b7d1ce6714b0e918bfef6781bbb32096a'/>
<id>9c95724b7d1ce6714b0e918bfef6781bbb32096a</id>
<content type='text'>
[ Upstream commit 5026cf605143e764e1785bbf9158559d17f8d260 ]

Before destroying the mc_io, check first that it was
allocated.

Reviewed-by: Laurentiu Tudor &lt;laurentiu.tudor@nxp.com&gt;
Acked-by: Laurentiu Tudor &lt;laurentiu.tudor@nxp.com&gt;
Signed-off-by: Diana Craciun &lt;diana.craciun@oss.nxp.com&gt;
Link: https://lore.kernel.org/r/20200929085441.17448-11-diana.craciun@oss.nxp.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 5026cf605143e764e1785bbf9158559d17f8d260 ]

Before destroying the mc_io, check first that it was
allocated.

Reviewed-by: Laurentiu Tudor &lt;laurentiu.tudor@nxp.com&gt;
Acked-by: Laurentiu Tudor &lt;laurentiu.tudor@nxp.com&gt;
Signed-off-by: Diana Craciun &lt;diana.craciun@oss.nxp.com&gt;
Link: https://lore.kernel.org/r/20200929085441.17448-11-diana.craciun@oss.nxp.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bus: hisi_lpc: Fixup IO ports addresses to avoid use-after-free in host removal</title>
<updated>2020-10-01T11:14:35+00:00</updated>
<author>
<name>John Garry</name>
<email>john.garry@huawei.com</email>
</author>
<published>2020-01-16T18:48:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4ba1aee12640a5528aee4484ef876eb15f10cb49'/>
<id>4ba1aee12640a5528aee4484ef876eb15f10cb49</id>
<content type='text'>
[ Upstream commit a6dd255bdd7d00bbdbf78ba00bde9fc64f86c3a7 ]

Some released ACPI FW for Huawei boards describes incorrect the port IO
address range for child devices, in that it tells us the IO port max range
is 0x3fff for each child device, which is not correct. The address range
should be [e4:e8) or similar. With this incorrect upper range, the child
device IO port resources overlap.

As such, the kernel thinks that the LPC host serial device is a child of
the IPMI device:

root@(none)$ more /proc/ioports
[...]
00ffc0e3-00ffffff : hisi-lpc-ipmi.0.auto
  00ffc0e3-00ffc0e3 : ipmi_si
  00ffc0e4-00ffc0e4 : ipmi_si
  00ffc0e5-00ffc0e5 : ipmi_si
  00ffc2f7-00ffffff : serial8250.1.auto
    00ffc2f7-00ffc2fe : serial
root@(none)$

They should both be siblings. Note that these are logical PIO addresses,
which have a direct mapping from the FW IO port ranges.

This shows up as a real issue when we enable CONFIG_KASAN and
CONFIG_DEBUG_TEST_DRIVER_REMOVE - we see use-after-free warnings in the
host removal path:

==================================================================
BUG: KASAN: use-after-free in release_resource+0x38/0xc8
Read of size 8 at addr ffff0026accdbc38 by task swapper/0/1

CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.5.0-rc6-00001-g68e186e77b5c-dirty #1593
Hardware name: Huawei Taishan 2180 /D03, BIOS Hisilicon D03 IT20 Nemo 2.0 RC0 03/30/2018
Call trace:
dump_backtrace+0x0/0x290
show_stack+0x14/0x20
dump_stack+0xf0/0x14c
print_address_description.isra.9+0x6c/0x3b8
__kasan_report+0x12c/0x23c
kasan_report+0xc/0x18
__asan_load8+0x94/0xb8
release_resource+0x38/0xc8
platform_device_del.part.10+0x80/0xe0
platform_device_unregister+0x20/0x38
hisi_lpc_acpi_remove_subdev+0x10/0x20
device_for_each_child+0xc8/0x128
hisi_lpc_acpi_remove+0x4c/0xa8
hisi_lpc_remove+0xbc/0xc0
platform_drv_remove+0x3c/0x68
really_probe+0x174/0x548
driver_probe_device+0x7c/0x148
device_driver_attach+0x94/0xa0
__driver_attach+0xa4/0x110
bus_for_each_dev+0xe8/0x158
driver_attach+0x30/0x40
bus_add_driver+0x234/0x2f0
driver_register+0xbc/0x1d0
__platform_driver_register+0x7c/0x88
hisi_lpc_driver_init+0x18/0x20
do_one_initcall+0xb4/0x258
kernel_init_freeable+0x248/0x2c0
kernel_init+0x10/0x118
ret_from_fork+0x10/0x1c

...

The issue here is that the kernel created an incorrect parent-child
resource dependency between two devices, and references the false parent
node when deleting the second child device, when it had been deleted
already.

Fix up the child device resources from FW to create proper IO port
resource relationships for broken FW.

With this, the IO port layout looks more healthy:

root@(none)$ more /proc/ioports
[...]
00ffc0e3-00ffc0e7 : hisi-lpc-ipmi.0.auto
  00ffc0e3-00ffc0e3 : ipmi_si
  00ffc0e4-00ffc0e4 : ipmi_si
  00ffc0e5-00ffc0e5 : ipmi_si
00ffc2f7-00ffc2ff : serial8250.1.auto
  00ffc2f7-00ffc2fe : serial

Signed-off-by: John Garry &lt;john.garry@huawei.com&gt;
Signed-off-by: Wei Xu &lt;xuwei5@hisilicon.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit a6dd255bdd7d00bbdbf78ba00bde9fc64f86c3a7 ]

Some released ACPI FW for Huawei boards describes incorrect the port IO
address range for child devices, in that it tells us the IO port max range
is 0x3fff for each child device, which is not correct. The address range
should be [e4:e8) or similar. With this incorrect upper range, the child
device IO port resources overlap.

As such, the kernel thinks that the LPC host serial device is a child of
the IPMI device:

root@(none)$ more /proc/ioports
[...]
00ffc0e3-00ffffff : hisi-lpc-ipmi.0.auto
  00ffc0e3-00ffc0e3 : ipmi_si
  00ffc0e4-00ffc0e4 : ipmi_si
  00ffc0e5-00ffc0e5 : ipmi_si
  00ffc2f7-00ffffff : serial8250.1.auto
    00ffc2f7-00ffc2fe : serial
root@(none)$

They should both be siblings. Note that these are logical PIO addresses,
which have a direct mapping from the FW IO port ranges.

This shows up as a real issue when we enable CONFIG_KASAN and
CONFIG_DEBUG_TEST_DRIVER_REMOVE - we see use-after-free warnings in the
host removal path:

==================================================================
BUG: KASAN: use-after-free in release_resource+0x38/0xc8
Read of size 8 at addr ffff0026accdbc38 by task swapper/0/1

CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.5.0-rc6-00001-g68e186e77b5c-dirty #1593
Hardware name: Huawei Taishan 2180 /D03, BIOS Hisilicon D03 IT20 Nemo 2.0 RC0 03/30/2018
Call trace:
dump_backtrace+0x0/0x290
show_stack+0x14/0x20
dump_stack+0xf0/0x14c
print_address_description.isra.9+0x6c/0x3b8
__kasan_report+0x12c/0x23c
kasan_report+0xc/0x18
__asan_load8+0x94/0xb8
release_resource+0x38/0xc8
platform_device_del.part.10+0x80/0xe0
platform_device_unregister+0x20/0x38
hisi_lpc_acpi_remove_subdev+0x10/0x20
device_for_each_child+0xc8/0x128
hisi_lpc_acpi_remove+0x4c/0xa8
hisi_lpc_remove+0xbc/0xc0
platform_drv_remove+0x3c/0x68
really_probe+0x174/0x548
driver_probe_device+0x7c/0x148
device_driver_attach+0x94/0xa0
__driver_attach+0xa4/0x110
bus_for_each_dev+0xe8/0x158
driver_attach+0x30/0x40
bus_add_driver+0x234/0x2f0
driver_register+0xbc/0x1d0
__platform_driver_register+0x7c/0x88
hisi_lpc_driver_init+0x18/0x20
do_one_initcall+0xb4/0x258
kernel_init_freeable+0x248/0x2c0
kernel_init+0x10/0x118
ret_from_fork+0x10/0x1c

...

The issue here is that the kernel created an incorrect parent-child
resource dependency between two devices, and references the false parent
node when deleting the second child device, when it had been deleted
already.

Fix up the child device resources from FW to create proper IO port
resource relationships for broken FW.

With this, the IO port layout looks more healthy:

root@(none)$ more /proc/ioports
[...]
00ffc0e3-00ffc0e7 : hisi-lpc-ipmi.0.auto
  00ffc0e3-00ffc0e3 : ipmi_si
  00ffc0e4-00ffc0e4 : ipmi_si
  00ffc0e5-00ffc0e5 : ipmi_si
00ffc2f7-00ffc2ff : serial8250.1.auto
  00ffc2f7-00ffc2fe : serial

Signed-off-by: John Garry &lt;john.garry@huawei.com&gt;
Signed-off-by: Wei Xu &lt;xuwei5@hisilicon.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bus: sunxi-rsb: Return correct data when mixing 16-bit and 8-bit reads</title>
<updated>2020-04-17T08:48:37+00:00</updated>
<author>
<name>Ondrej Jirman</name>
<email>megous@megous.com</email>
</author>
<published>2020-02-21T20:27:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f615ab435e2d2850fb4b6d87ce247eb380496753'/>
<id>f615ab435e2d2850fb4b6d87ce247eb380496753</id>
<content type='text'>
[ Upstream commit a43ab30dcd4a1abcdd0d2461bf1cf7c0817f6cd3 ]

When doing a 16-bit read that returns data in the MSB byte, the
RSB_DATA register will keep the MSB byte unchanged when doing
the following 8-bit read. sunxi_rsb_read() will then return
a result that contains high byte from 16-bit read mixed with
the 8-bit result.

The consequence is that after this happens the PMIC's regmap will
look like this: (0x33 is the high byte from the 16-bit read)

% cat /sys/kernel/debug/regmap/sunxi-rsb-3a3/registers
00: 33
01: 33
02: 33
03: 33
04: 33
05: 33
06: 33
07: 33
08: 33
09: 33
0a: 33
0b: 33
0c: 33
0d: 33
0e: 33
[snip]

Fix this by masking the result of the read with the correct mask
based on the size of the read. There are no 16-bit users in the
mainline kernel, so this doesn't need to get into the stable tree.

Signed-off-by: Ondrej Jirman &lt;megous@megous.com&gt;
Acked-by: Chen-Yu Tsai &lt;wens@csie.org&gt;
Signed-off-by: Maxime Ripard &lt;maxime@cerno.tech&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit a43ab30dcd4a1abcdd0d2461bf1cf7c0817f6cd3 ]

When doing a 16-bit read that returns data in the MSB byte, the
RSB_DATA register will keep the MSB byte unchanged when doing
the following 8-bit read. sunxi_rsb_read() will then return
a result that contains high byte from 16-bit read mixed with
the 8-bit result.

The consequence is that after this happens the PMIC's regmap will
look like this: (0x33 is the high byte from the 16-bit read)

% cat /sys/kernel/debug/regmap/sunxi-rsb-3a3/registers
00: 33
01: 33
02: 33
03: 33
04: 33
05: 33
06: 33
07: 33
08: 33
09: 33
0a: 33
0b: 33
0c: 33
0d: 33
0e: 33
[snip]

Fix this by masking the result of the read with the correct mask
based on the size of the read. There are no 16-bit users in the
mainline kernel, so this doesn't need to get into the stable tree.

Signed-off-by: Ondrej Jirman &lt;megous@megous.com&gt;
Acked-by: Chen-Yu Tsai &lt;wens@csie.org&gt;
Signed-off-by: Maxime Ripard &lt;maxime@cerno.tech&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bus: ti-sysc: Fix sysc_unprepare() when no clocks have been allocated</title>
<updated>2020-01-27T13:50:36+00:00</updated>
<author>
<name>Tony Lindgren</name>
<email>tony@atomide.com</email>
</author>
<published>2019-03-21T18:00:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2fe6d9c113f52b8eda42dd65eeeac6ee424c765e'/>
<id>2fe6d9c113f52b8eda42dd65eeeac6ee424c765e</id>
<content type='text'>
[ Upstream commit aaa29bb01cc4bf5a87dbdb219efba3b09f259d8e ]

If we return early before ddata-&gt;clocks have been allocated we will get a
NULL pointer dereference in sysc_unprepare(). Let's fix this by returning
early when no clocks are allocated.

Fixes: 0eecc636e5a2 ("bus: ti-sysc: Add minimal TI sysc interconnect target driver")
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit aaa29bb01cc4bf5a87dbdb219efba3b09f259d8e ]

If we return early before ddata-&gt;clocks have been allocated we will get a
NULL pointer dereference in sysc_unprepare(). Let's fix this by returning
early when no clocks are allocated.

Fixes: 0eecc636e5a2 ("bus: ti-sysc: Add minimal TI sysc interconnect target driver")
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bus: ti-sysc: Fix timer handling with drop pm_runtime_irq_safe()</title>
<updated>2020-01-27T13:50:16+00:00</updated>
<author>
<name>Tony Lindgren</name>
<email>tony@atomide.com</email>
</author>
<published>2019-01-22T17:03:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=558c47fb668e7b2604ac22284b74a3df84f37b7f'/>
<id>558c47fb668e7b2604ac22284b74a3df84f37b7f</id>
<content type='text'>
[ Upstream commit 9bd34c63f5536c490c152833c77fa47f59aeade3 ]

Commit 84badc5ec5fc ("ARM: dts: omap4: Move l4 child devices to probe
them with ti-sysc") started producing a warning for pwm-omap-dmtimer:

WARNING: CPU: 0 PID: 77 at drivers/bus/omap_l3_noc.c:147
l3_interrupt_handler+0x2f8/0x388
44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4PER2 (Idle):
Data Access in Supervisor mode during Functional access
...
__pm_runtime_idle
omap_dm_timer_disable
pwm_omap_dmtimer_start
pwm_omap_dmtimer_enable
pwm_apply_state
pwm_vibrator_start
pwm_vibrator_play_work

This is because the timer that pwm-omap-dmtimer is using is now being
probed with ti-sysc interconnect target module instead of omap_device
and the ti-sysc quirk for SYSC_QUIRK_LEGACY_IDLE is not fully
compatible with what omap_device has been doing.

We could fix this by reverting the timer changes and have the timer
probe again with omap_device. Or we could add more quirk handling to
ti-sysc driver. But as these options don't work nicely as longer term
solutions, let's just make timers probe with ti-sysc without any
quirks.

To do this, all we need to do is remove quirks for timers for ti-sysc,
and drop the bogus pm_runtime_irq_safe() flag for timer-ti-dm.

We should not use pm_runtime_irq_safe() anyways for drivers as it will
take a permanent use count on the parent device blocking the parent
devices from idling and has been forcing ti-sysc driver to use a
quirk flag.

Note that we will move the timer data to DEBUG section later on in
clean-up patches.

Fixes: 84badc5ec5fc ("ARM: dts: omap4: Move l4 child devices to probe them with ti-sysc")
Cc: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Cc: Bartosz Golaszewski &lt;bgolaszewski@baylibre.com&gt;
Cc: Daniel Lezcano &lt;daniel.lezcano@linaro.org&gt;
Cc: H. Nikolaus Schaller &lt;hns@goldelico.com&gt;
Cc: Keerthy &lt;j-keerthy@ti.com&gt;
Cc: Ladislav Michl &lt;ladis@linux-mips.org&gt;
Cc: Pavel Machek &lt;pavel@ucw.cz&gt;
Cc: Sebastian Reichel &lt;sre@kernel.org&gt;
Cc: Tero Kristo &lt;t-kristo@ti.com&gt;
Cc: Thierry Reding &lt;thierry.reding@gmail.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Reported-by: H. Nikolaus Schaller &lt;hns@goldelico.com&gt;
Tested-By: Andreas Kemnade &lt;andreas@kemnade.info&gt;
Tested-By: H. Nikolaus Schaller &lt;hns@goldelico.com&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 9bd34c63f5536c490c152833c77fa47f59aeade3 ]

Commit 84badc5ec5fc ("ARM: dts: omap4: Move l4 child devices to probe
them with ti-sysc") started producing a warning for pwm-omap-dmtimer:

WARNING: CPU: 0 PID: 77 at drivers/bus/omap_l3_noc.c:147
l3_interrupt_handler+0x2f8/0x388
44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4PER2 (Idle):
Data Access in Supervisor mode during Functional access
...
__pm_runtime_idle
omap_dm_timer_disable
pwm_omap_dmtimer_start
pwm_omap_dmtimer_enable
pwm_apply_state
pwm_vibrator_start
pwm_vibrator_play_work

This is because the timer that pwm-omap-dmtimer is using is now being
probed with ti-sysc interconnect target module instead of omap_device
and the ti-sysc quirk for SYSC_QUIRK_LEGACY_IDLE is not fully
compatible with what omap_device has been doing.

We could fix this by reverting the timer changes and have the timer
probe again with omap_device. Or we could add more quirk handling to
ti-sysc driver. But as these options don't work nicely as longer term
solutions, let's just make timers probe with ti-sysc without any
quirks.

To do this, all we need to do is remove quirks for timers for ti-sysc,
and drop the bogus pm_runtime_irq_safe() flag for timer-ti-dm.

We should not use pm_runtime_irq_safe() anyways for drivers as it will
take a permanent use count on the parent device blocking the parent
devices from idling and has been forcing ti-sysc driver to use a
quirk flag.

Note that we will move the timer data to DEBUG section later on in
clean-up patches.

Fixes: 84badc5ec5fc ("ARM: dts: omap4: Move l4 child devices to probe them with ti-sysc")
Cc: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Cc: Bartosz Golaszewski &lt;bgolaszewski@baylibre.com&gt;
Cc: Daniel Lezcano &lt;daniel.lezcano@linaro.org&gt;
Cc: H. Nikolaus Schaller &lt;hns@goldelico.com&gt;
Cc: Keerthy &lt;j-keerthy@ti.com&gt;
Cc: Ladislav Michl &lt;ladis@linux-mips.org&gt;
Cc: Pavel Machek &lt;pavel@ucw.cz&gt;
Cc: Sebastian Reichel &lt;sre@kernel.org&gt;
Cc: Tero Kristo &lt;t-kristo@ti.com&gt;
Cc: Thierry Reding &lt;thierry.reding@gmail.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Reported-by: H. Nikolaus Schaller &lt;hns@goldelico.com&gt;
Tested-By: Andreas Kemnade &lt;andreas@kemnade.info&gt;
Tested-By: H. Nikolaus Schaller &lt;hns@goldelico.com&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bus: ti-sysc: Add mcasp optional clocks flag</title>
<updated>2020-01-27T13:50:02+00:00</updated>
<author>
<name>Tony Lindgren</name>
<email>tony@atomide.com</email>
</author>
<published>2018-11-15T22:46:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fa3302ef721f6daa80baac04bcd30110391e82e5'/>
<id>fa3302ef721f6daa80baac04bcd30110391e82e5</id>
<content type='text'>
[ Upstream commit 2c63a833e4500b341a62bf97e67488909ae12086 ]

We have OPT_CLKS_NEEDED in legacy platform data, but it's missing
from the ti-sysc driver for device tree based configuration.

In order to pass OPT_CLKS_NEEDED quirk flag we need to update omap4 module
data and add a new compatible for dra7 as the module layout is different
from sysc_regbits_omap4_mcasp.

Fixes: 70a65240efb1 ("bus: ti-sysc: Add register bits for interconnect
target modules")
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Rob Herring &lt;robh+dt@kernel.org&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 2c63a833e4500b341a62bf97e67488909ae12086 ]

We have OPT_CLKS_NEEDED in legacy platform data, but it's missing
from the ti-sysc driver for device tree based configuration.

In order to pass OPT_CLKS_NEEDED quirk flag we need to update omap4 module
data and add a new compatible for dra7 as the module layout is different
from sysc_regbits_omap4_mcasp.

Fixes: 70a65240efb1 ("bus: ti-sysc: Add register bits for interconnect
target modules")
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Rob Herring &lt;robh+dt@kernel.org&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bus: ti-sysc: Fix getting optional clocks in clock_roles</title>
<updated>2019-12-13T07:51:23+00:00</updated>
<author>
<name>Tony Lindgren</name>
<email>tony@atomide.com</email>
</author>
<published>2018-11-15T22:46:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=65930054756acfbacddf6f80bd55a6f23a8937f6'/>
<id>65930054756acfbacddf6f80bd55a6f23a8937f6</id>
<content type='text'>
[ Upstream commit 7b4f8ac2f1acdff3c0cce23d8c3b86434a6e768a ]

We can have holes in clock_roles with interface clock missing for
example. Currently getting an optional clock will fail if there are
only a functional clock and an optional clock.

Fixes: 09dfe5810762 ("bus: ti-sysc: Add handling for clkctrl opt clocks")
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 7b4f8ac2f1acdff3c0cce23d8c3b86434a6e768a ]

We can have holes in clock_roles with interface clock missing for
example. Currently getting an optional clock will fail if there are
only a functional clock and an optional clock.

Fixes: 09dfe5810762 ("bus: ti-sysc: Add handling for clkctrl opt clocks")
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bus: ti-sysc: Check for no-reset and no-idle flags at the child level</title>
<updated>2019-12-05T08:20:00+00:00</updated>
<author>
<name>Tony Lindgren</name>
<email>tony@atomide.com</email>
</author>
<published>2018-12-10T22:11:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=08d8ab9615c522a432a92523ed16a00d77b14d5d'/>
<id>08d8ab9615c522a432a92523ed16a00d77b14d5d</id>
<content type='text'>
[ Upstream commit 4014c08ba39476a18af546186da625a6833a1529 ]

With ti-sysc, we need to now have the device tree properties for
ti,no-reset-on-init and ti,no-idle-on-init at the module level instead
of the child device level.

Let's check for these properties at the child device level to enable
quirks, and warn about moving the properties to the module level.

Otherwise am335x-evm based boards tagging gpio1 with ti,no-reset-on-init
will have their DDR power disabled if wired up in such a tricky way.

Note that this should not be an issue for earlier kernels as we don't
rely on this until the dts files have been updated to probe with ti-sysc
interconnect target driver.

Cc: Peter Ujfalusi &lt;peter.ujfalusi@ti.com&gt;
Reported-by: Peter Ujfalusi &lt;peter.ujfalusi@ti.com&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 4014c08ba39476a18af546186da625a6833a1529 ]

With ti-sysc, we need to now have the device tree properties for
ti,no-reset-on-init and ti,no-idle-on-init at the module level instead
of the child device level.

Let's check for these properties at the child device level to enable
quirks, and warn about moving the properties to the module level.

Otherwise am335x-evm based boards tagging gpio1 with ti,no-reset-on-init
will have their DDR power disabled if wired up in such a tricky way.

Note that this should not be an issue for earlier kernels as we don't
rely on this until the dts files have been updated to probe with ti-sysc
interconnect target driver.

Cc: Peter Ujfalusi &lt;peter.ujfalusi@ti.com&gt;
Reported-by: Peter Ujfalusi &lt;peter.ujfalusi@ti.com&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
