Date:   Mon, 9 Nov 2020 12:24:34 +0100
From:   Hans de Goede <hdegoede@...hat.com>
To:     Doug Anderson <dianders@...omium.org>
Cc:     Jiri Kosina <jkosina@...e.cz>,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        "open list:HID CORE LAYER" <linux-input@...r.kernel.org>,
        Stephen Boyd <swboyd@...omium.org>,
        Andrea Borgia <andrea@...gia.bo.it>,
        Kai-Heng Feng <kai.heng.feng@...onical.com>,
        Rob Herring <robh+dt@...nel.org>,
        Aaron Ma <aaron.ma@...onical.com>,
        Jiri Kosina <jikos@...nel.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Pavel Balan <admin@...ma.net>,
        Xiaofei Tan <tanxiaofei@...wei.com>,
        You-Sheng Yang <vicamo.yang@...onical.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 1/4] HID: i2c-hid: Reorganize so ACPI and OF are
 subclasses

Hi,

On 11/4/20 5:06 PM, Doug Anderson wrote:
> Hi,
> 
> On Wed, Nov 4, 2020 at 4:07 AM Hans de Goede <hdegoede@...hat.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.

Ok, if Benjamin decides to keep things this way, can you consider
renaming i2chid_subclass_data to i2chid_ops ?

It just feels weird to have a struct with subclass in the name
embedded inside as a member in another struct, usualy the kobject model
works by having the the parent/base-class struct embedded inside
the subclass data struct.

This also avoids the need for a callback_priv_data pointer to the ops,
as the ops get a pointer to the baseclass data struct as argument and
you can then use container_of to get your own subclassdata struct
since that encapsulates (contains) the baseclass struct.

Note the dropping of the callback_priv_data pointer only works if you
do move the entire struct to the header.



> 
> 
>>> @@ -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()"?

I have no real preference here either way.

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

This sorta depends on if the regulators for the HID device are part of the
PMIC or not. If they are part of the PMIC then on shutdown they will
typically be turned off by the PMIC. But if they are separate they may
stay enabled on shutdown.

Anyways I again have no real preference here...

Regards,

Hans






> 
> 
>>> 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@...il.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@...il.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
> 

Powered by blists - more mailing lists