On Fri, 23 Sep 2022 14:22:18 -0700
Matt Ranostay [off-list ref] wrote:

On Fri, Sep 23, 2022 at 12:03 AM Benjamin Tissoires
[off-list ref] wrote:

quoted

On Fri, Sep 23, 2022 at 1:45 AM Matt Ranostay
[off-list ref] wrote:  

quoted

On Wed, Sep 21, 2022 at 10:57 AM Matt Ranostay
[off-list ref] wrote:  

quoted

On Wed, Sep 21, 2022 at 1:05 AM Benjamin Tissoires
[off-list ref] wrote:  

quoted

[foreword: please keep Jiri and myself (the HID maintainers) CC-ed to
the series, as you will need ack from us and we don't necessarily monitor
every single message on linux-input]

On Sep 20 2022, Matt Ranostay wrote:  

quoted

Switch from i2c_add_adapter() to resource managed devm_i2c_add_adapter()
for matching rest of driver initialization, and more concise code.

Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
---
 drivers/hid/hid-mcp2221.c | 45 +++++++++++++++++----------------------
 1 file changed, 19 insertions(+), 26 deletions(-)

diff --git a/drivers/hid/hid-mcp2221.c b/drivers/hid/hid-mcp2221.c
index de52e9f7bb8c..7ba63bcd66de 100644
--- a/drivers/hid/hid-mcp2221.c
+++ b/drivers/hid/hid-mcp2221.c

@@ -824,6 +824,14 @@ static int mcp2221_raw_event(struct hid_device *hdev,
      return 1;
 }

+static void mcp2221_hid_remove(void *ptr)
+{
+     struct hid_device *hdev = ptr;
+
+     hid_hw_close(hdev);
+     hid_hw_stop(hdev);  

By default, if you remove the .remove() callback, hid_hw_stop() will get
automatically called by hid-core.c. So we are now calling it twice,
which, in a way is not a big deal but it might be an issue in the long
run.

Generally speaking, in the HID subsystem, that situation doesn't happen
a lot because hid_hw_start() is usually the last command of probe, and
we don't need to open the device in the driver itself.

Here, I guess as soon as you add the i2c adapter, you might want to have
the communication channels ready, and thus you need to have it open
*before* i2c_add_adapter.

I would suggest the following if you want to keep the devm release of
stop and close: please put a big fat warning before mcp2221_hid_remove()
explaining that this is called in devm management, *and* add a function
that would just return 0 as the .remove() callback with another big fat
warning explaining that we don't want hid-core.c to call hid_hw_stop()
because we are doing it ourself through devres.
 

Yeah maybe best to keep the non-devres if it isn't going to affect how the last
change in this series is trying to implement with iio.

I'll wait for Jonathan to chime in on this thread.

Not my subsystem, so I'm happy if others have to take the headaches that
mixing and matching causes :)  Personally I'd rather not!
Whilst devm_ brings it's own issues (the plumbers session on this was as
ever fun) the particular fun set of bugs that turn up because of mixing
it in probe() with manual removal in remove() was one where I've never
heard a good argument against using devm_ until the first thing in probe() where
you decide not to then not using devm_ calls after that. I have seen
a handful of cases where a different order was needed, but far more bugs
and / or difficult to reason out flows as a result of mixing them up.

Obviously straight forward allocations are fine as freeing them late doesn't
matter. Registration / consumer requests not so much.

Jonathan