From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Stephen Boyd <swboyd@chromium.org>
Cc: Jiri Kosina <jikos@kernel.org>,
Benjamin Tissoires <benjamin.tissoires@redhat.com>,
linux-kernel@vger.kernel.org, patches@lists.linux.dev,
linux-input@vger.kernel.org
Subject: Re: [PATCH] HID: google: Don't use devm for hid_hw_stop()
Date: Fri, 5 May 2023 17:06:07 -0700 [thread overview]
Message-ID: <ZFWZ785FRHDii/+5@google.com> (raw)
In-Reply-To: <20230505232417.1377393-1-swboyd@chromium.org>
On Fri, May 05, 2023 at 04:24:16PM -0700, Stephen Boyd wrote:
>
...
> Unfortunately, the hid google hammer driver hand rolls a devm function
> to call hid_hw_stop() when the driver is unbound and implements an
> hid_driver::remove() function. The driver core doesn't call the devm
> release functions until _after_ the bus unbinds the driver, so the order
> of operations is like this:
Excellent analysis, but the problem is not limited to the hammer driver
(potentially) and shalt be dealt with appropriately, at the HID bus
level.
Actually, it is not even limited to HID, but exists in most buses with
non-trivial ->remove() implementation. For example I fixed similar issue
in I2C in 5b5475826c52 ("i2c: ensure timely release of driver-allocated
resources"). I tried fixing it in SPI but Mark has some objections, and
wanted to fix it in the driver core, so I was thinking about it and then
dropped the ball. At this time I do not think fixing it at driver core
makes logic any clearer, so I think we just need to fix a handful of
buses.
Anyway, I'll CC you on an alternative patch.
Thanks.
--
Dmitry
next prev parent reply other threads:[~2023-05-06 0:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-05 23:24 [PATCH] HID: google: Don't use devm for hid_hw_stop() Stephen Boyd
2023-05-06 0:06 ` Dmitry Torokhov [this message]
2023-05-10 18:51 ` Stephen Boyd
2023-05-10 20:24 ` Dmitry Torokhov
2023-05-10 20:50 ` Stephen Boyd
2023-05-11 0:25 ` Dmitry Torokhov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZFWZ785FRHDii/+5@google.com \
--to=dmitry.torokhov@gmail.com \
--cc=benjamin.tissoires@redhat.com \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@lists.linux.dev \
--cc=swboyd@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox