[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20230427221625.116050-1-opendmb@gmail.com>
Date: Thu, 27 Apr 2023 15:16:22 -0700
From: Doug Berger <opendmb@...il.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>,
Gergo Koteles <soyer@....hu>,
Jonathan Cameron <Jonathan.Cameron@...wei.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Dan Williams <dan.j.williams@...el.com>,
Hans de Goede <hdegoede@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Kees Cook <keescook@...omium.org>,
Kishon Vijay Abraham I <kishon@...com>,
Saravana Kannan <saravanak@...gle.com>,
Florian Fainelli <f.fainelli@...il.com>,
linux-kernel@...r.kernel.org, linux-input@...r.kernel.org,
Doug Berger <opendmb@...il.com>
Subject: [RFC PATCH 0/3] input: gpio-keys - fix pm ordering
Commit 52cdbdd49853 ("driver core: correct device's shutdown
order") allowed for proper sequencing of the gpio-keys device
shutdown callbacks by moving the device to the end of the
devices_kset list at probe which was delayed by child
dependencies.
However, commit 722e5f2b1eec ("driver core: Partially revert
"driver core: correct device's shutdown order"") removed this
portion of that commit causing a reversion in the gpio-keys
behavior which can prevent waking from shutdown.
This RFC is an attempt to find a better solution for properly
creating gpio-keys device links to ensure its suspend/resume and
shutdown services are invoked before those of its suppliers.
The first patch here is pretty brute force but simple and has
the advantage that it should be easily backportable to the
versions where the regression first occurred.
The second patch is perhaps better in spirit though still a bit
inelegant, but it can only be backported to versions of the
kernel that contain the commit in its 'Fixes:' tag. That isn't
really a valid 'Fixes:' tag since that commit did not cause the
regression, but it does represent how far the patch could be
backported.
Both commits shouldn't really exist in the same kernel so the
third patch reverts the first in an attempt to make that clear
(though it may be a source of confusion for some).
Hopefully someone with a better understanding of device links
will see a less intrusive way to automatically capture these
dependencies for parent device drivers that implement the
functions of child node devices.
Doug Berger (3):
input: gpio-keys - use device_pm_move_to_tail
input: gpio-keys - add device links of children
Revert "input: gpio-keys - use device_pm_move_to_tail"
drivers/input/keyboard/gpio_keys.c | 7 +++++++
1 file changed, 7 insertions(+)
--
2.34.1
Powered by blists - more mailing lists