linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/5] PM / devfreq: Don't take lock in devfreq_add_device
@ 2019-11-13 23:21 Leonard Crestez
  2019-11-13 23:21 ` [PATCH 1/5] PM / devfreq: Don't fail devfreq_dev_release if not in list Leonard Crestez
                   ` (4 more replies)
  0 siblings, 5 replies; 10+ messages in thread
From: Leonard Crestez @ 2019-11-13 23:21 UTC (permalink / raw)
  To: Chanwoo Choi, MyungJoo Ham
  Cc: Kyungmin Park, Rafael J. Wysocki, Matthias Kaehlcke,
	Artur Świgoń,
	Georgi Djakov, Viresh Kumar, linux-pm, linux-arm-kernel,
	linux-imx

Right now the devfreq_add_device takes devfreq->lock as soon as the device is
allocated, this is awkward and unnecessary. In general an object should be
initialized in isolation and only be made available to the system when it's in
a consistent state.

Locking the device during initialization causes problems (lockdep warnings)
when interacting with other subsystems that also use heavy locking. There are
also a few fields (such as trans_table) which are initialized after
device_register even through they're readable from sysfs, these are now
allocated earlier.

This was spawned by the attempt to add dev_pm_qos support. I split this series
here because it might benefit from separate discussion.

Notifiers from pm_qos are executed under a single global dev_pm_qos_mtx and
need to take devfreq->lock, this means that in order to prevent possible
deadlocks all initialization of dev_pm_qos must be performed outside the
devfreq->lock.

PM QoS requests from sysfs should be initialized before the device is
registered (because they're touched from sysfs) but all of that is currently
done with devfreq->lock held!

This series makes some tricky changes but the end results is easier to
understand and maintain. For example it removes a scary unlock/lock pair
around set_freq_table, maybe this also caused problems in the past?

Alternative solutions exist: all PM QoS setup could be done after device_add
just like governor setup and the min/max_freq_store could return an error if
the qos request is not yet properly initialized.

It might even be possible to modify dev_pm_qos to call notifiers without
holding internal locks? That is generally a good idea for all notifiers.

Changes since split from PM_QOS:
* Add a patch which moves devm from devfreq->dev->parent to devfreq->dev.
See: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=196443

Leonard Crestez (5):
  PM / devfreq: Don't fail devfreq_dev_release if not in list
  PM / devfreq: Split device_register usage
  PM / devfreq: Move more initialization before registration
  PM / devfreq: Don't use devm on parent device
  PM / devfreq: Don't take lock in devfreq_add_device

 drivers/devfreq/devfreq.c | 41 ++++++++++++---------------------------
 1 file changed, 12 insertions(+), 29 deletions(-)

-- 
2.17.1


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2019-12-02  4:56 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-13 23:21 [PATCH 0/5] PM / devfreq: Don't take lock in devfreq_add_device Leonard Crestez
2019-11-13 23:21 ` [PATCH 1/5] PM / devfreq: Don't fail devfreq_dev_release if not in list Leonard Crestez
2019-12-02  1:07   ` Chanwoo Choi
2019-11-13 23:21 ` [PATCH 2/5] PM / devfreq: Split device_register usage Leonard Crestez
2019-12-02  1:08   ` Chanwoo Choi
2019-12-02  4:45     ` Leonard Crestez
2019-12-02  5:02       ` Chanwoo Choi
2019-11-13 23:21 ` [PATCH 3/5] PM / devfreq: Move more initialization before registration Leonard Crestez
2019-11-13 23:21 ` [PATCH 4/5] PM / devfreq: Don't use devm on parent device Leonard Crestez
2019-11-13 23:21 ` [PATCH 5/5] PM / devfreq: Don't take lock in devfreq_add_device Leonard Crestez

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).