Get rid of 'remove_new' relic from platform driver struct

The continual trickle of small conversion patches is grating on me, and
is really not helping. Just get rid of the 'remove_new' member
func

Get rid of 'remove_new' relic from platform driver struct

The continual trickle of small conversion patches is grating on me, and
is really not helping. Just get rid of the 'remove_new' member
function, which is just an alias for the plain 'remove', and had a
comment to that effect:

/*
* .remove_new() is a relic from a prototype conversion of .remove().
* New drivers are supposed to implement .remove(). Once all drivers are
* converted to not use .remove_new any more, it will be dropped.
*/

This was just a tree-wide 'sed' script that replaced '.remove_new' with
'.remove', with some care taken to turn a subsequent tab into two tabs
to make things line up.

I did do some minimal manual whitespace adjustment for places that used
spaces to line things up.

Then I just removed the old (sic) .remove_new member function, and this
is the end result. No more unnecessary conversion noise.

Signed-off-by: Linus Torvalds <[email protected]>

show more ...

PM / devfreq: mtk-cci: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to

PM / devfreq: mtk-cci: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Chanwoo Choi <[email protected]>

show more ...

PM / devfreq: mediatek: unlock on error in mtk_ccifreq_target()

Call mutex_unlock(&drv->reg_lock) before returning the error code.

Link: https://lore.kernel.org/all/1bada9b2-d276-4123-bfdf-03d16556

PM / devfreq: mediatek: unlock on error in mtk_ccifreq_target()

Call mutex_unlock(&drv->reg_lock) before returning the error code.

Link: https://lore.kernel.org/all/[email protected]/
Fixes: d2805601988f ("PM / devfreq: mediatek: protect oop in critical session")
Signed-off-by: Dan Carpenter <[email protected]>
Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
Signed-off-by: Chanwoo Choi <[email protected]>

show more ...

PM / devfreq: mediatek: protect oop in critical session

mtk_ccifreq_opp_notifier is reenter function when policy0 / policy6
change freq, so mutex_lock should protect all OPP event.

Link: https://lo

PM / devfreq: mediatek: protect oop in critical session

mtk_ccifreq_opp_notifier is reenter function when policy0 / policy6
change freq, so mutex_lock should protect all OPP event.

Link: https://lore.kernel.org/lkml/[email protected]/T/
Signed-off-by: Mark Tseng <[email protected]>
Signed-off-by: Chanwoo Choi <[email protected]>

show more ...

PM / devfreq: Explicitly include correct DT includes

The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of

PM / devfreq: Explicitly include correct DT includes

The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.

Signed-off-by: Rob Herring <[email protected]>
Signed-off-by: Chanwoo Choi <[email protected]>

show more ...

PM / devfreq: mtk-cci: Fix variable deferencing before NULL check

smatch warning:
drivers/devfreq/mtk-cci-devfreq.c:135 mtk_ccifreq_target()
warn: variable dereferenced before check 'drv' (see line

PM / devfreq: mtk-cci: Fix variable deferencing before NULL check

smatch warning:
drivers/devfreq/mtk-cci-devfreq.c:135 mtk_ccifreq_target()
warn: variable dereferenced before check 'drv' (see line 130)

This is based on static analysis only. Compilation tested.

Signed-off-by: Sukrut Bellary <[email protected]>
Signed-off-by: Chanwoo Choi <[email protected]>

show more ...

PM / devfreq: mtk-cci: Handle sram regulator probe deferral

If the regulator_get_optional() call for the SRAM regulator returns
a probe deferral, we must bail out and retry probing later: failing
to

PM / devfreq: mtk-cci: Handle sram regulator probe deferral

If the regulator_get_optional() call for the SRAM regulator returns
a probe deferral, we must bail out and retry probing later: failing
to do this will produce unstabilities on platforms requiring the
handling for this regulator.

Fixes: b615b00c42da ("PM / devfreq: mediatek: Introduce MediaTek CCI devfreq driver")
Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
Signed-off-by: Chanwoo Choi <[email protected]>

show more ...

PM / devfreq: mediatek: Introduce MediaTek CCI devfreq driver

We introduce a devfreq driver for the MediaTek Cache Coherent Interconnect
(CCI) used by some MediaTek SoCs.

In this driver, we use the

PM / devfreq: mediatek: Introduce MediaTek CCI devfreq driver

We introduce a devfreq driver for the MediaTek Cache Coherent Interconnect
(CCI) used by some MediaTek SoCs.

In this driver, we use the passive devfreq driver to get target frequencies
and adjust voltages accordingly. In MT8183 and MT8186, the MediaTek CCI
is supplied by the same regulators with the little core CPUs.

Signed-off-by: Jia-Wei Chang <[email protected]>
Signed-off-by: Johnson Wang <[email protected]>
Acked-by: Chanwoo Choi <[email protected]>
Tested-by: Kevin Hilman <[email protected]>
Signed-off-by: Chanwoo Choi <[email protected]>

show more ...