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

  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).