From: Oleksii Moisieiev <Oleksii_Moisieiev@epam.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: "sudeep.holla@arm.com" <sudeep.holla@arm.com>,
Cristian Marussi <cristian.marussi@arm.com>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>
Subject: Re: [PATCH v3 3/4] pinctrl: Implementation of the generic scmi-pinctrl driver
Date: Thu, 20 Jul 2023 18:03:40 +0000 [thread overview]
Message-ID: <87o7k6h344.fsf@epam.com> (raw)
In-Reply-To: <CAHp75Vf+H_wnhT=2w=A9M7wFeOkf_m1M1gmL9vd8WHNid7+YBg@mail.gmail.com>
Hi Andy,
Andy Shevchenko <andy.shevchenko@gmail.com> writes:
> On Thu, Jul 20, 2023 at 4:40 PM Oleksii Moisieiev
> <Oleksii_Moisieiev@epam.com> wrote:
>> andy.shevchenko@gmail.com writes:
>> > Tue, Jun 06, 2023 at 04:22:28PM +0000, Oleksii Moisieiev kirjoitti:
>
> ...
>
>> >> + devm_kfree(pmx->dev, pmx->functions[selector].groups);
>> >
>> > Red Flag. Please, elaborate.
>>
>> Thank you for the review.
>> I did some research regarding this and now I'm confused. Could you
>> please explain to me why it's a red flag?
>> IIUC devm_alloc/free functions are the calls to the resource-managed
>> alloc/free command, which is bound to the device.
>> pinctrl-scmi driver does devm_pinctrl_register_and_init which does
>> devres_alloc and doesn't open devres_group like
>> scmi_alloc_init_protocol_instance (thanks to Cristian detailed
>> explanation).
>>
>> As was mentioned in Documentation/driver-api/driver-model/devres.rst:
>>
>> ```
>> No matter what, all devres entries are released on driver detach. On
>> release, the associated release function is invoked and then the
>> devres entry is freed.
>> ```
>
> Precisely. So, why do you intervene in this?
>
>> Also there is devm_pinctrl_get call listed in the managed interfaces.
>>
>> My understanding is that all resources, bound to the particular device
>> will be freed on driver detach.
>>
>> Also I found some examples of using devm_alloc/free like from dt_node_to_map
>> call in pinctrl-simple.c driver.
>>
>> I agree that I need to implement .remove callback with proper cleanup,
>> but why can't I use devm_* here?
>
> You can use devm_*(), but what's the point if you call release
> yourself? That's quite a red flag usually shows a bigger issue
> (misunderstanding of the objects lifetimes and their interaction).
>
The idea was to follow the way of how pinctrl subsystem manages
resources. It assumes that functions, groups and pins should be
registered using helper functions
pinmux_generic_add_function, pinmux_generic_remove_function,
pinconf_generic_add_group, pinconf_generic_remove_group, etc. Which has
data as the input parameter and should be freed on pinctrl_unregister
call. So pins, groups and functions should live until pinctrl_unregister
is called (from remove callback or from devm_pinctrl_dev_release)
Unfortunately, I can't use this helpers because pins, funcs and groups should
have selector which is understandable by SCMI.
pinctrl_scmi_get_function_groups returns pointer to the allocated
resources to the caller, so I'm allocating managed resources to be sure
that they should be freed on detach.
devm_kfree is called only if scmi_get_group_name call was failed while
converting group_ids to group_names. I count that as a lack of memory,
so I clean allocated groups to give caller a chance to free additional
memory and repeat the call.
So IMHO devm_* fits here good. What do you think?
Sorry for being annoying but I'm trying to understand...
--
Thanks,
Oleksii
WARNING: multiple messages have this Message-ID (diff)
From: Oleksii Moisieiev <Oleksii_Moisieiev@epam.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: "sudeep.holla@arm.com" <sudeep.holla@arm.com>,
Cristian Marussi <cristian.marussi@arm.com>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>
Subject: Re: [PATCH v3 3/4] pinctrl: Implementation of the generic scmi-pinctrl driver
Date: Thu, 20 Jul 2023 18:03:40 +0000 [thread overview]
Message-ID: <87o7k6h344.fsf@epam.com> (raw)
In-Reply-To: <CAHp75Vf+H_wnhT=2w=A9M7wFeOkf_m1M1gmL9vd8WHNid7+YBg@mail.gmail.com>
Hi Andy,
Andy Shevchenko <andy.shevchenko@gmail.com> writes:
> On Thu, Jul 20, 2023 at 4:40 PM Oleksii Moisieiev
> <Oleksii_Moisieiev@epam.com> wrote:
>> andy.shevchenko@gmail.com writes:
>> > Tue, Jun 06, 2023 at 04:22:28PM +0000, Oleksii Moisieiev kirjoitti:
>
> ...
>
>> >> + devm_kfree(pmx->dev, pmx->functions[selector].groups);
>> >
>> > Red Flag. Please, elaborate.
>>
>> Thank you for the review.
>> I did some research regarding this and now I'm confused. Could you
>> please explain to me why it's a red flag?
>> IIUC devm_alloc/free functions are the calls to the resource-managed
>> alloc/free command, which is bound to the device.
>> pinctrl-scmi driver does devm_pinctrl_register_and_init which does
>> devres_alloc and doesn't open devres_group like
>> scmi_alloc_init_protocol_instance (thanks to Cristian detailed
>> explanation).
>>
>> As was mentioned in Documentation/driver-api/driver-model/devres.rst:
>>
>> ```
>> No matter what, all devres entries are released on driver detach. On
>> release, the associated release function is invoked and then the
>> devres entry is freed.
>> ```
>
> Precisely. So, why do you intervene in this?
>
>> Also there is devm_pinctrl_get call listed in the managed interfaces.
>>
>> My understanding is that all resources, bound to the particular device
>> will be freed on driver detach.
>>
>> Also I found some examples of using devm_alloc/free like from dt_node_to_map
>> call in pinctrl-simple.c driver.
>>
>> I agree that I need to implement .remove callback with proper cleanup,
>> but why can't I use devm_* here?
>
> You can use devm_*(), but what's the point if you call release
> yourself? That's quite a red flag usually shows a bigger issue
> (misunderstanding of the objects lifetimes and their interaction).
>
The idea was to follow the way of how pinctrl subsystem manages
resources. It assumes that functions, groups and pins should be
registered using helper functions
pinmux_generic_add_function, pinmux_generic_remove_function,
pinconf_generic_add_group, pinconf_generic_remove_group, etc. Which has
data as the input parameter and should be freed on pinctrl_unregister
call. So pins, groups and functions should live until pinctrl_unregister
is called (from remove callback or from devm_pinctrl_dev_release)
Unfortunately, I can't use this helpers because pins, funcs and groups should
have selector which is understandable by SCMI.
pinctrl_scmi_get_function_groups returns pointer to the allocated
resources to the caller, so I'm allocating managed resources to be sure
that they should be freed on detach.
devm_kfree is called only if scmi_get_group_name call was failed while
converting group_ids to group_names. I count that as a lack of memory,
so I clean allocated groups to give caller a chance to free additional
memory and repeat the call.
So IMHO devm_* fits here good. What do you think?
Sorry for being annoying but I'm trying to understand...
--
Thanks,
Oleksii
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-07-20 18:04 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-06 16:22 [PATCH v3 0/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support Oleksii Moisieiev
2023-06-06 16:22 ` Oleksii Moisieiev
2023-06-06 16:22 ` [PATCH v3 2/4] " Oleksii Moisieiev
2023-06-06 16:22 ` Oleksii Moisieiev
2023-06-07 7:10 ` andy.shevchenko
2023-06-07 7:10 ` andy.shevchenko
2023-06-30 16:02 ` Cristian Marussi
2023-06-30 16:02 ` Cristian Marussi
2023-07-03 21:27 ` andy.shevchenko
2023-07-03 21:27 ` andy.shevchenko
2023-07-06 10:55 ` Cristian Marussi
2023-07-06 10:55 ` Cristian Marussi
2023-07-06 14:49 ` Oleksii Moisieiev
2023-07-06 14:49 ` Oleksii Moisieiev
2023-07-03 10:16 ` Cristian Marussi
2023-07-03 10:16 ` Cristian Marussi
2023-07-06 14:09 ` Oleksii Moisieiev
2023-07-06 14:09 ` Oleksii Moisieiev
2023-07-06 14:42 ` Cristian Marussi
2023-07-06 14:42 ` Cristian Marussi
2023-07-06 15:06 ` Oleksii Moisieiev
2023-07-06 15:06 ` Oleksii Moisieiev
2023-06-06 16:22 ` [PATCH v3 1/4] firmware: arm_scmi: Add optional flags to extended names helper Oleksii Moisieiev
2023-06-06 16:22 ` Oleksii Moisieiev
2023-06-07 6:33 ` andy.shevchenko
2023-06-07 6:33 ` andy.shevchenko
2023-06-30 11:33 ` Cristian Marussi
2023-06-30 11:33 ` Cristian Marussi
2023-06-06 16:22 ` [PATCH v3 4/4] dt-bindings: firmware: arm,scmi: Add support for pinctrl protocol Oleksii Moisieiev
2023-06-06 16:22 ` Oleksii Moisieiev
2023-06-09 7:35 ` Linus Walleij
2023-06-09 7:35 ` Linus Walleij
2023-06-14 22:36 ` Rob Herring
2023-06-14 22:36 ` Rob Herring
2023-06-06 16:22 ` [PATCH v3 3/4] pinctrl: Implementation of the generic scmi-pinctrl driver Oleksii Moisieiev
2023-06-06 16:22 ` Oleksii Moisieiev
2023-06-07 7:26 ` andy.shevchenko
2023-06-07 7:26 ` andy.shevchenko
2023-07-20 13:40 ` Oleksii Moisieiev
2023-07-20 13:40 ` Oleksii Moisieiev
2023-07-20 16:11 ` Andy Shevchenko
2023-07-20 16:11 ` Andy Shevchenko
2023-07-20 18:03 ` Oleksii Moisieiev [this message]
2023-07-20 18:03 ` Oleksii Moisieiev
2023-07-03 10:49 ` Cristian Marussi
2023-07-03 10:49 ` Cristian Marussi
2023-06-30 10:38 ` [PATCH v3 0/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support Cristian Marussi
2023-06-30 10:38 ` Cristian Marussi
2023-07-03 12:58 ` Oleksii Moisieiev
2023-07-03 12:58 ` Oleksii Moisieiev
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=87o7k6h344.fsf@epam.com \
--to=oleksii_moisieiev@epam.com \
--cc=andy.shevchenko@gmail.com \
--cc=conor+dt@kernel.org \
--cc=cristian.marussi@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=sudeep.holla@arm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.