Thread (14 messages) 14 messages, 4 authors, 2020-11-09

Re: [PATCH v4 1/4] HID: i2c-hid: Reorganize so ACPI and OF are subclasses

From: Doug Anderson <dianders@chromium.org>
Date: 2020-11-04 16:13:04
Also in: lkml

Hi,

On Wed, Nov 4, 2020 at 4:07 AM Hans de Goede [off-list ref] wrote:
quoted
+#include "i2c-hid.h"
+
+struct i2c_hid_acpi {
+     struct i2chid_subclass_data subclass;
This feels a bit weird, we are the subclass so typically we would
be embedding a base_class data struct here ...

(more remarks below, note just my 2 cents you may want to wait
for feedback from others).
quoted
+     struct i2c_client *client;
You pass this to i2c_hid_core_probe which then stores it own
copy, why not just store it in the subclass (or even better
baseclass) data struct ?
My goal was to avoid moving the big structure to the header file.
Without doing that, I think you need something more like the setup I
have.  I'll wait for Benjamin to comment on whether he'd prefer
something like what I have here or if I should move the structure.

quoted
@@ -156,10 +152,10 @@ struct i2c_hid {

      wait_queue_head_t       wait;           /* For waiting the interrupt */

-     struct i2c_hid_platform_data pdata;
-
      bool                    irq_wake_enabled;
      struct mutex            reset_lock;
+
+     struct i2chid_subclass_data *subclass;
 };
Personally, I would do things a bit differently here:

1. Just add the

        int (*power_up_device)(struct i2chid_subclass_data *subclass);
        void (*power_down_device)(struct i2chid_subclass_data *subclass);

members which you put in the subclass struct here.

2. Move the declaration of this complete struct to drivers/hid/i2c-hid/i2c-hid.h
and use this as the base-class which I described before (and store the client
pointer here).

3. And then kzalloc both this baseclass struct + the subclass-data
(only the bool "power_fixed" in the ACPI case) in one go in the subclass code
replacing 2 kzallocs (+ error checking with one, simplifying the code and
reducing memory fragmentation (by a tiny sliver).
Sure, I'll do that if Benjamin likes moving the structure to the header.

About the power_*_device callbacks, I wonder if it would not be more consistent
to also have a shutdown callback and make i2c_driver.shutdown point to
a (modified) i2c_hid_core_shutdown() function.
Personally this doesn't seem cleaner to me, but I'm happy to do it if
folks like it better.  Coming up with a name for the callback would be
a bit awkward, which is a sign that this isn't quite ideal?  For the
power_up()/power_down() those are sane concepts to abstract out.  Here
we'd be abstracting out "subclass_shutdown_tail()" or something?
...and if a subclass needs something at the head of shutdown, we'd
need to add a "subclass_shutdown_head()"?

You may also want to consider pointing that shutdown callback to the power_off
function in the of case (in a separate commit as that is a behavioral change).
I don't think this is the point of shutdown, but I could be corrected.
Shutdown isn't really supposed to be the same as driver remove or
anything.  IIUC the main point of shutdown is to support kexec and the
goal is to quiesce DMA transactions.  Turning off power has never been
a requirement that I was aware of.  We don't want to jam too much
stuff in shutdown or else "shutdown" becomes as slow as boot for no
good reason, right?

quoted
diff --git a/drivers/hid/i2c-hid/i2c-hid-of.c b/drivers/hid/i2c-hid/i2c-hid-of.c
new file mode 100644
index 000000000000..e1838cdef0aa
--- /dev/null
+++ b/drivers/hid/i2c-hid/i2c-hid-of.c
@@ -0,0 +1,149 @@
+/*
+ * HID over I2C Open Firmware Subclass
+ *
+ * Copyright (c) 2012 Benjamin Tissoires <benjamin.tissoires@gmail.com>
+ * Copyright (c) 2012 Ecole Nationale de l'Aviation Civile, France
+ * Copyright (c) 2012 Red Hat, Inc
<snip>
quoted
+MODULE_DESCRIPTION("HID over I2C OF driver");
+MODULE_AUTHOR("Benjamin Tissoires [off-list ref]");
In case Benjamin misses this during his own review: I'm not sure if he
will want to be set as AUTHOR of this, given that part of the plan is
for someone else to be the primary point of contact for the of bits.
I can stick myself in as the author if needed.  I'll wait for
Benjamin's feedback here.


-Doug
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help