From: hkallweit1@gmail.com (Heiner Kallweit)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/5] firmware: arm_scpi: pre-populate dvfs info in scpi_probe
Date: Tue, 3 Oct 2017 18:00:55 +0200 [thread overview]
Message-ID: <ffb9c571-edd3-7ea0-ecf6-f72c2ddd9fc1@gmail.com> (raw)
In-Reply-To: <0e5959a7-6826-1909-1509-f6627a9688ed@arm.com>
Am 03.10.2017 um 12:57 schrieb Sudeep Holla:
>
>
> On 02/10/17 23:07, Heiner Kallweit wrote:
>> Am 02.10.2017 um 13:17 schrieb Sudeep Holla:
>>>
>>>
>>> On 29/09/17 22:44, Heiner Kallweit wrote:
>>>> Pre-populating the dvfs info data in scpi_probe allows to make
>>>> all memory allocations device-managed. This helps to simplify
>>>> scpi_remove and eventually to get rid of scpi_remove completely.
>>>>
>>>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>
> [...]
>
>>> Does it make sense to continue to complete all MAX_DVFS_DOMAINS ?
>>> Just wondering if there will be any firmware that returns errors
>>> for few domains(e.g. not supported in initial versions of
>>> firmware). I don't want to stop probing due to that. Let me know
>>> what you think.
>>>
>> The (legacy) SCPI firmware on my system seems to ignore the domain
>> in CMD_GET_DVFS_INFO. It returns the same dvfs info independent of
>> the domain parameter. So indeed prepopulating may not be the best
>> idea.
>>
>
> I can't follow that. Does the behavior change probe time vs runtime ?
> I am fine with probe time populate, just that we can't stop or propagate
> any error as it fails to probe other dependent drivers which may work
> fine without DVFS(e.g. clocks, sensors and power domains)
>
>> Still we need to do something in the remove callback to deal with the
>> scenario you describe (error for few domains).
>
> devm_* APIs will take care of freeing DVFS domain info, so what else
> needs to be done ? I just noticed devm_kfree(NULL) can produce WARN_ON
> splat, is that what you are referring ?
>
>>
>> Remove does for (i = 0; i < MAX_DVFS_DOMAINS && info->dvfs[i]; i++) {
>> and therefore stops at the first unpopulated domain and doesn't free
>> the memory for further populated domains. I'll provide a patch for
>> it.
>>
>
> Does that mean you are re-introducing scpi_remove ? I kind of liked
> removing it.
>
Sorry for the confusion. Then I'll go with the original approach and
just make sure that errors whilst populating dvfs info are ignored.
next prev parent reply other threads:[~2017-10-03 16:00 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-29 21:25 [PATCH 0/5] firmware: arm_scpi: series with smaller improvements Heiner Kallweit
2017-09-29 21:43 ` [PATCH 1/5] firmware: arm_scpi: remove usage of drvdata and don't reset scpi_info to null Heiner Kallweit
2017-10-02 11:08 ` Sudeep Holla
2017-09-29 21:44 ` [PATCH 2/5] firmware: arm_scpi: remove two unneeded devm_kfree's in scpi_remove Heiner Kallweit
2017-09-29 21:44 ` [PATCH 3/5] firmware: arm_scpi: pre-populate dvfs info in scpi_probe Heiner Kallweit
2017-10-02 11:17 ` Sudeep Holla
2017-10-02 22:07 ` Heiner Kallweit
2017-10-03 10:57 ` Sudeep Holla
2017-10-03 16:00 ` Heiner Kallweit [this message]
2017-10-03 16:18 ` Sudeep Holla
2017-10-03 18:19 ` Heiner Kallweit
2017-10-04 10:10 ` Sudeep Holla
2017-10-04 18:50 ` Heiner Kallweit
2017-09-29 21:44 ` [PATCH 4/5] firmware: arm_scpi: make freeing mbox channels device-managed Heiner Kallweit
2017-10-02 11:20 ` Sudeep Holla
2017-09-29 21:44 ` [PATCH 5/5] firmware: arm_scpi: remove scpi_remove Heiner Kallweit
2017-10-02 11:25 ` [PATCH 0/5] firmware: arm_scpi: series with smaller improvements Sudeep Holla
2017-10-02 22:10 ` Heiner Kallweit
2017-10-03 10:16 ` Sudeep Holla
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=ffb9c571-edd3-7ea0-ecf6-f72c2ddd9fc1@gmail.com \
--to=hkallweit1@gmail.com \
--cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).