Message ID | 20230427221625.116050-1-opendmb@gmail.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp560437vqo; Thu, 27 Apr 2023 15:20:07 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5vriBqCfT8Kxv79LQfUwQ6yguk6EQ7KhBfgqI/PL7rcUbUp7NYYCDcAb0QhcDnpnHphUCl X-Received: by 2002:a17:902:8c91:b0:1a9:2b7f:a594 with SMTP id t17-20020a1709028c9100b001a92b7fa594mr2981661plo.29.1682634007104; Thu, 27 Apr 2023 15:20:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682634007; cv=none; d=google.com; s=arc-20160816; b=WcNe3A24BAImJvBVTtwzyxP8fRZ8PyKJh9IoTXq0FHqkbfDTpCAECAiYWinA1p08Zb gRav1sfJCocyLJ4TgNvYiq9VR5wxw3ejl/6wHYhBxatIvkeOw3K/AGaoYP/cghqgZ9Bs H59hmGV2er4jlmEIePk9Tx3v4bYNARAJICzIslFsn4vgm1PoLcTc8hvXRCGtW5gjMiCU 6OwsqnGqeJpzVOQLcaOMaTeYpASoxM+k/OFNSOQY3f1dcGkN1b2ie7mXWgE1uxgbRm7d MjXuuSh/0j+1mdSxq34+kg+zQassZP8AvjKDBKszw+Vtc8SbrU/VMwtJze9rXOrRAy0S j7Tw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=wgxbPMJ7xUQDEudjDb2tgUkteEVXo/Z62mLiKg0b33g=; b=Q5k8+9OmaVUCigS1zWJ3Aed32h+S4ehbgulkkN3ELy8hTrFK0871qC1i58Ts8INY83 YrvMV4aAtGJM4lnvozxPgOh/cmj8f5wythrgrTQTewQjJTkVORYb8KJTTpEUZbmiRwto lK5OalPgFI4cBNoMnBMm6gOsvlkti/ZeWR/frkUtxOQtPZ23vBYpkUauY49mzAor9dlO wEyIOlZbw1gXNKs3Lk6mD5zAU26f4+/KmQTNIM8AfjpibVueVcpr6L2yFPhxAb5AHF82 fLvRQChkvy4xdThpkCgIrUPbumuFtXpP/Cowzje7gZ590h2DX5y5OO41ikPFmmqoGBbI 8Buw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=Z5eao2yl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a6-20020a170902710600b001a6d872c860si18052317pll.163.2023.04.27.15.19.54; Thu, 27 Apr 2023 15:20:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=Z5eao2yl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344184AbjD0WSJ (ORCPT <rfc822;zxc52fgh@gmail.com> + 99 others); Thu, 27 Apr 2023 18:18:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40734 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229783AbjD0WSG (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 27 Apr 2023 18:18:06 -0400 Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E78FC30EE; Thu, 27 Apr 2023 15:18:01 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id 41be03b00d2f7-517c01edaaaso6686526a12.3; Thu, 27 Apr 2023 15:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682633881; x=1685225881; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=wgxbPMJ7xUQDEudjDb2tgUkteEVXo/Z62mLiKg0b33g=; b=Z5eao2yloeRGKjFH79FDobwF4GBZyz/El+hwcAktCg26P3OkFYrJ7nMe5ZQKD3tjVL 4NYP58f09Che6fBHQ+jJ3uCI56k+2WJvbSXb1sVp7bJkDb4EobiWttlTHa6zsSRipyol 07q/pm0WqBMYJIKszuGd6Cv7qK1/Y/h7ykBatvFSedb+ApiDXlrKZuUtXL4JtH9YbAHH PBbc9iPZIPjyhZGX66vB5MMYF1/da+kQTop1ldLiL9/9U5daQVz6GJI35qEFaiFebxCe XLkuroA89QMqM2vE2pjgSVnSO087ZoAq3jNsT+OY3XCRmXQ0ooaFg0KMQAq8n9bftrX7 ELgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682633881; x=1685225881; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wgxbPMJ7xUQDEudjDb2tgUkteEVXo/Z62mLiKg0b33g=; b=ROstWA5TkLtOOP/j03RqMruL9TxmCaysA3RPHPQaZoEv7Mlie3/1pUHVFmsVtx4XeZ yxTBIQWz+SbpiTD2a3AEQKDN9n36YjcT0tFnmr3CUBhjtN9159PxqpJtq3KSsDA7A9w3 SoaHWmuHOWfj+BwK78q1PxGYh44eYeQlV6mDjX1etOEIvfsxEGqp9SaATvKY/SJe/a+N Qg8qb09+gF3JYMheSbcBD1eKlDCmzgPX8NfH5lsWii64erxQGoyw+FvgEYp1b4HtjfOL aXgA2xPJcWuXk9xgweKMOLi3jLPcBMzchsN3ecK3KrNwfazu1oRvX6qoCX64LT5GqK8P KpEw== X-Gm-Message-State: AC+VfDyMtgDkkDGExL/1Z4S7LkMrEmljOKMg+jjRLOJ8k6pq0NsYuM7J 2d2XDKBSxrza9d1LZuA3NCQ= X-Received: by 2002:a17:902:f20b:b0:19f:3b86:4715 with SMTP id m11-20020a170902f20b00b0019f3b864715mr2916598plc.8.1682633881183; Thu, 27 Apr 2023 15:18:01 -0700 (PDT) Received: from stbirv-lnx-1.igp.broadcom.net ([192.19.223.252]) by smtp.gmail.com with ESMTPSA id w8-20020a1709027b8800b001a661000398sm12022783pll.103.2023.04.27.15.17.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Apr 2023 15:18:00 -0700 (PDT) From: Doug Berger <opendmb@gmail.com> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "Rafael J. Wysocki" <rafael@kernel.org>, Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>, Gergo Koteles <soyer@irl.hu>, Jonathan Cameron <Jonathan.Cameron@huawei.com>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Dan Williams <dan.j.williams@intel.com>, Hans de Goede <hdegoede@redhat.com>, Thomas Gleixner <tglx@linutronix.de>, Kees Cook <keescook@chromium.org>, Kishon Vijay Abraham I <kishon@ti.com>, Saravana Kannan <saravanak@google.com>, Florian Fainelli <f.fainelli@gmail.com>, linux-kernel@vger.kernel.org, linux-input@vger.kernel.org, Doug Berger <opendmb@gmail.com> Subject: [RFC PATCH 0/3] input: gpio-keys - fix pm ordering Date: Thu, 27 Apr 2023 15:16:22 -0700 Message-Id: <20230427221625.116050-1-opendmb@gmail.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1764369636896204560?= X-GMAIL-MSGID: =?utf-8?q?1764369636896204560?= |
Series |
input: gpio-keys - fix pm ordering
|
|
Message
Doug Berger
April 27, 2023, 10:16 p.m. UTC
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(+)
Comments
On Thu, Apr 27, 2023 at 3:18 PM Doug Berger <opendmb@gmail.com> wrote: > > 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. We really shouldn't be calling device_pm_move_to_tail() in drivers because device link uses device_pm_move_to_tail() for ordering too. And it becomes a "race" between device links and when the driver calls device_pm_move_to_tail() and I'm not sure we'll get the same ordering every time. > > 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. Can you give a summary of the issue on a real system? I took a look at the two commits you've referenced above and it's not clear what's still broken in the 6.3+ But I'd think that just teaching fw_devlink about some property should be sufficient. If you are facing a real issue, have you made sure you have fw_devlink=on (this is the default unless you turned it off in the commandline when it had issues in the past). -Saravana > > 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 >
On Mon, May 1, 2023 at 1:40 PM Saravana Kannan <saravanak@google.com> wrote: > > On Thu, Apr 27, 2023 at 3:18 PM Doug Berger <opendmb@gmail.com> wrote: > > > > 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. > > We really shouldn't be calling device_pm_move_to_tail() in drivers > because device link uses device_pm_move_to_tail() for ordering too. > And it becomes a "race" between device links and when the driver calls > device_pm_move_to_tail() and I'm not sure we'll get the same ordering > every time. > > > > > 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. > > Can you give a summary of the issue on a real system? I took a look at > the two commits you've referenced above and it's not clear what's > still broken in the 6.3+ > > But I'd think that just teaching fw_devlink about some property should > be sufficient. If you are facing a real issue, have you made sure you > have fw_devlink=on (this is the default unless you turned it off in > the commandline when it had issues in the past). > I took a closer look at how gpio-keys work and I can see why fw_devlink doesn't pick up the GPIO dependencies. It's because the gpio dependencies are listed under child "key-x" device nodes under the main "gpio-keys" device tree node. fw_devlink doesn't consider dependencies under child nodes as mandatory dependencies of the parent node. The main reason for this was because of how fw_devlink used to work. But I might be able to change fw_devlink to pick this up automatically. I need to think a bit more about this because in some cases, ignoring those dependencies is the right thing to do. Give me a few weeks to think through and experiment with this on my end. -Saravana
On 5/2/2023 7:18 PM, Saravana Kannan wrote: > On Mon, May 1, 2023 at 1:40 PM Saravana Kannan <saravanak@google.com> wrote: >> >> On Thu, Apr 27, 2023 at 3:18 PM Doug Berger <opendmb@gmail.com> wrote: >>> >>> 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. >> >> We really shouldn't be calling device_pm_move_to_tail() in drivers >> because device link uses device_pm_move_to_tail() for ordering too. >> And it becomes a "race" between device links and when the driver calls >> device_pm_move_to_tail() and I'm not sure we'll get the same ordering >> every time. >> >>> >>> 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. >> >> Can you give a summary of the issue on a real system? I took a look at >> the two commits you've referenced above and it's not clear what's >> still broken in the 6.3+ >> >> But I'd think that just teaching fw_devlink about some property should >> be sufficient. If you are facing a real issue, have you made sure you >> have fw_devlink=on (this is the default unless you turned it off in >> the commandline when it had issues in the past). >> > > I took a closer look at how gpio-keys work and I can see why > fw_devlink doesn't pick up the GPIO dependencies. It's because the > gpio dependencies are listed under child "key-x" device nodes under > the main "gpio-keys" device tree node. fw_devlink doesn't consider > dependencies under child nodes as mandatory dependencies of the parent > node. > > The main reason for this was because of how fw_devlink used to work. > But I might be able to change fw_devlink to pick this up > automatically. I need to think a bit more about this because in some > cases, ignoring those dependencies is the right thing to do. Give me a > few weeks to think through and experiment with this on my end. Thank you for taking a deeper look at gpio-keys, and for getting through the gobblety-gook description in my cover-letter ;). Yes, the dependencies of children are not automatically inherited by their parents and it is not clear to me whether or not that should change, but it definitely creates a problem for the sequencing of gpio-keys device callbacks. I initially prepared the second patch as a way to explicitly create device links specifically for the gpio-keys device from these child dependencies as a work around for the fw_devlinks being dropped. I don't really consider this a viable patch which is why I made it an RFC, but I hoped it would highlight the issue. However, the regression actually occurs in v4.18 and fw_devlink isn't introduced until v5.7 so it is desirable to think about solutions that could be backported to older versions. This is why I provided the first patch for discussion. Again, it is not a desirable solution just an illustration what could be easily backported to restore the gpio-keys behavior prior to commit 722e5f2b1eec ("driver core: Partially revert "driver core: correct device's shutdown order"") without affecting other devices. Thanks again for your willingness to take the time to think this through, Doug > > -Saravana
On Wed, May 3, 2023 at 3:21 PM Doug Berger <opendmb@gmail.com> wrote: > > On 5/2/2023 7:18 PM, Saravana Kannan wrote: > > On Mon, May 1, 2023 at 1:40 PM Saravana Kannan <saravanak@google.com> wrote: > >> > >> On Thu, Apr 27, 2023 at 3:18 PM Doug Berger <opendmb@gmail.com> wrote: > >>> > >>> 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. > >> > >> We really shouldn't be calling device_pm_move_to_tail() in drivers > >> because device link uses device_pm_move_to_tail() for ordering too. > >> And it becomes a "race" between device links and when the driver calls > >> device_pm_move_to_tail() and I'm not sure we'll get the same ordering > >> every time. > >> > >>> > >>> 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. > >> > >> Can you give a summary of the issue on a real system? I took a look at > >> the two commits you've referenced above and it's not clear what's > >> still broken in the 6.3+ > >> > >> But I'd think that just teaching fw_devlink about some property should > >> be sufficient. If you are facing a real issue, have you made sure you > >> have fw_devlink=on (this is the default unless you turned it off in > >> the commandline when it had issues in the past). > >> > > > > I took a closer look at how gpio-keys work and I can see why > > fw_devlink doesn't pick up the GPIO dependencies. It's because the > > gpio dependencies are listed under child "key-x" device nodes under > > the main "gpio-keys" device tree node. fw_devlink doesn't consider > > dependencies under child nodes as mandatory dependencies of the parent > > node. > > > > The main reason for this was because of how fw_devlink used to work. > > But I might be able to change fw_devlink to pick this up > > automatically. I need to think a bit more about this because in some > > cases, ignoring those dependencies is the right thing to do. Give me a > > few weeks to think through and experiment with this on my end. > Thank you for taking a deeper look at gpio-keys, and for getting through > the gobblety-gook description in my cover-letter ;). > > Yes, the dependencies of children are not automatically inherited by > their parents and it is not clear to me whether or not that should > change, but it definitely creates a problem for the sequencing of > gpio-keys device callbacks. > > I initially prepared the second patch as a way to explicitly create > device links specifically for the gpio-keys device from these child > dependencies as a work around for the fw_devlinks being dropped. I don't > really consider this a viable patch which is why I made it an RFC, but I > hoped it would highlight the issue. Thanks. It definitely made it easier for me to get to the root of the problem/omission. > However, the regression actually occurs in v4.18 and fw_devlink isn't > introduced until v5.7 so it is desirable to think about solutions that > could be backported to older versions. For older versions, if they have device link support, I'd recommend creating device links and letting that take care of it. Also, if you use the right GPIO APIs, at least on newer kernels Linus W was looking into creating device links automatically from the GPIO framework level. So maybe you can backport some variant of that into the older kernels and leave it to fw_devlink on the newer ones. -Saravana > This is why I provided the first > patch for discussion. Again, it is not a desirable solution just an > illustration what could be easily backported to restore the gpio-keys > behavior prior to commit 722e5f2b1eec ("driver core: Partially revert > "driver core: correct device's shutdown order"") without affecting other > devices. > > Thanks again for your willingness to take the time to think this through, > Doug > > > > > -Saravana >