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

[Doug Anderson <dianders@chromium.org>]

Hi,

On Wed, Nov 4, 2020 at 4:07 AM Hans de Goede <hdegoede@redhat.com> wrote:
>
> > +#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).
>
> > +     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.


> > @@ -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?


> > 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>
>
> > +MODULE_DESCRIPTION("HID over I2C OF driver");
> > +MODULE_AUTHOR("Benjamin Tissoires <benjamin.tissoires@gmail.com>");
>
> 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