linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  reply	other threads:[~2023-07-20 18:04 UTC|newest]

Thread overview: 25+ 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 ` [PATCH v3 1/4] firmware: arm_scmi: Add optional flags to extended names helper Oleksii Moisieiev
2023-06-07  6:33   ` andy.shevchenko
2023-06-30 11:33   ` Cristian Marussi
2023-06-06 16:22 ` [PATCH v3 2/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support Oleksii Moisieiev
2023-06-07  7:10   ` andy.shevchenko
2023-06-30 16:02     ` Cristian Marussi
2023-07-03 21:27       ` andy.shevchenko
2023-07-06 10:55         ` Cristian Marussi
2023-07-06 14:49     ` Oleksii Moisieiev
2023-07-03 10:16   ` Cristian Marussi
2023-07-06 14:09     ` Oleksii Moisieiev
2023-07-06 14:42       ` Cristian Marussi
2023-07-06 15:06         ` Oleksii Moisieiev
2023-06-06 16:22 ` [PATCH v3 3/4] pinctrl: Implementation of the generic scmi-pinctrl driver Oleksii Moisieiev
2023-06-07  7:26   ` andy.shevchenko
2023-07-20 13:40     ` Oleksii Moisieiev
2023-07-20 16:11       ` Andy Shevchenko
2023-07-20 18:03         ` Oleksii Moisieiev [this message]
2023-07-03 10:49   ` 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-09  7:35   ` Linus Walleij
2023-06-14 22:36   ` Rob Herring
2023-06-30 10:38 ` [PATCH v3 0/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support Cristian Marussi
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).