From: Hans de Goede <hdegoede@redhat.com>
To: Benjamin Tissoires <benjamin.tissoires@redhat.com>,
Stephen Boyd <swboyd@chromium.org>
Cc: Jiri Kosina <jikos@kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
"open list:HID CORE LAYER" <linux-input@vger.kernel.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Dmitry Torokhov <dtor@chromium.org>,
Doug Anderson <dianders@chromium.org>
Subject: Re: [PATCH v3 1/2] HID: i2c-hid: Use devm to allocate i2c_hid struct
Date: Fri, 22 Jun 2018 11:13:07 +0200 [thread overview]
Message-ID: <095738e5-eb31-905b-b496-0d78489e253d@redhat.com> (raw)
In-Reply-To: <CAO-hwJJxSHqwEcypc-PVSDUoOSM4OHcOP18QJpoxq6OqKcbq-w@mail.gmail.com>
Hi,
On 22-06-18 09:16, Benjamin Tissoires wrote:
> On Fri, Jun 22, 2018 at 4:27 AM, Stephen Boyd <swboyd@chromium.org> wrote:
>> Use devm here to save some lines and prepare for bulk regulator usage in
>> this driver. Otherwise, when we devm bulk get regulators we'll free the
>> containing i2c_hid structure and try to put regulator pointers from
>> freed memory.
>>
>> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>> Cc: Hans de Goede <hdegoede@redhat.com>
>> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>> Cc: Dmitry Torokhov <dtor@chromium.org>
>> Cc: Doug Anderson <dianders@chromium.org>
>> Signed-off-by: Stephen Boyd <swboyd@chromium.org>
>> ---
>> drivers/hid/i2c-hid/i2c-hid.c | 9 +++------
>> 1 file changed, 3 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
>> index c1652bb7bd15..c7d6738dc524 100644
>> --- a/drivers/hid/i2c-hid/i2c-hid.c
>> +++ b/drivers/hid/i2c-hid/i2c-hid.c
>> @@ -1002,18 +1002,18 @@ static int i2c_hid_probe(struct i2c_client *client,
>> return client->irq;
>> }
>>
>> - ihid = kzalloc(sizeof(struct i2c_hid), GFP_KERNEL);
>> + ihid = devm_kzalloc(&client->dev, sizeof(*ihid), GFP_KERNEL);
>
> IIRC, I never made the switch towards devm for i2c_hid because at the
> time there was a "all or nothing" rule regarding devm.
I'm not aware of any such rule. Sure ideally everything should use
devm, because it makes life just so much easier. But I've seen mixed
use in plenty of cases.
With that said converting fully to devm is not necessarily a bad
idea.
Regards,
Hans
> But given that the regulator already has a devm inside, I think we are
> screwed here and we should probably try to devm-ize the module.
>
> I seem to remember that someone posted a devm version of
> hid_allocate_device/hid-add_device, but I don't think this ever went
> upstream (because no use).
>
> Otherwise, for the series:
> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>
> Cheers,
> Benjamin
>
>
>
>> if (!ihid)
>> return -ENOMEM;
>>
>> if (client->dev.of_node) {
>> ret = i2c_hid_of_probe(client, &ihid->pdata);
>> if (ret)
>> - goto err;
>> + return ret;
>> } else if (!platform_data) {
>> ret = i2c_hid_acpi_pdata(client, &ihid->pdata);
>> if (ret)
>> - goto err;
>> + return ret;
>> } else {
>> ihid->pdata = *platform_data;
>> }
>> @@ -1126,7 +1126,6 @@ static int i2c_hid_probe(struct i2c_client *client,
>>
>> err:
>> i2c_hid_free_buffers(ihid);
>> - kfree(ihid);
>> return ret;
>> }
>>
>> @@ -1150,8 +1149,6 @@ static int i2c_hid_remove(struct i2c_client *client)
>>
>> regulator_disable(ihid->pdata.supply);
>>
>> - kfree(ihid);
>> -
>> return 0;
>> }
>>
>> --
>> Sent by a computer through tubes
>>
next prev parent reply other threads:[~2018-06-22 9:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-22 2:27 [PATCH v3 0/2] Add another regulator to i2c-hid Stephen Boyd
2018-06-22 2:27 ` [PATCH v3 1/2] HID: i2c-hid: Use devm to allocate i2c_hid struct Stephen Boyd
2018-06-22 7:16 ` Benjamin Tissoires
2018-06-22 9:13 ` Hans de Goede [this message]
2018-06-22 22:39 ` Dmitry Torokhov
2018-06-22 2:27 ` [PATCH v3 2/2] HID: i2c-hid: Add vddl regulator control Stephen Boyd
2018-06-25 13:14 ` [PATCH v3 0/2] Add another regulator to i2c-hid Jiri Kosina
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=095738e5-eb31-905b-b496-0d78489e253d@redhat.com \
--to=hdegoede@redhat.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=benjamin.tissoires@redhat.com \
--cc=dianders@chromium.org \
--cc=dtor@chromium.org \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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
all inboxes | Powered by JetHome®