All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Hunter <jonathanh@nvidia.com>
To: Aaron Kling <webgeek1234@gmail.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-tegra@vger.kernel.org
Subject: Re: [PATCH v4 2/2] cpufreq: tegra124: Allow building as a module
Date: Thu, 15 May 2025 07:41:54 +0100	[thread overview]
Message-ID: <bc0a4c75-df5b-4b4d-9c9e-a2c99d3f4f6e@nvidia.com> (raw)
In-Reply-To: <CALHNRZ-pu9HUzVyR3-U=XZKFFZPnn5-DNLWPqPx6CSoW0dHMrA@mail.gmail.com>


On 14/05/2025 17:43, Aaron Kling wrote:
> On Mon, May 12, 2025 at 11:26 PM Aaron Kling <webgeek1234@gmail.com> wrote:
>>
>> On Fri, May 9, 2025 at 8:38 AM Jon Hunter <jonathanh@nvidia.com> wrote:
>>>
>>>
>>>
>>> On 09/05/2025 01:04, Aaron Kling via B4 Relay wrote:
>>>> From: Aaron Kling <webgeek1234@gmail.com>
>>>>
>>>> This requires three changes:
>>>> * A soft dependency on cpufreq-dt as this driver only handles power
>>>>     management and cpufreq-dt does the real operations
>>>
>>> Hmmm .. how is this handled for other drivers using the cpufreq-dt
>>> driver? I see the imx driver has a dependency on this.
>>
>> A hard dependency would likely make more sense here. I can update this
>> in a new revision. When I first set the soft dependency, I wasn't
>> certain how the driver worked, so I was trying to be less intrusive.
> 
> I remember why I added this soft dep now. The kconfig already has a
> dependency on cpufreq_dt. However, this driver doesn't call any
> functions directly in that driver. It just builds a platform device
> struct for it, then registers it. This results in depmod not requiring
> cpufreq_dt for tegra124_cpufreq. So I added the softdep to work around
> that, so modprobing tegra124_cpufreq by itself functions properly. Is
> there a better way to make depmod map this as needed?

Yes and that is understood. I see a few drivers calling ...

  platform_device_register_simple("cpufreq-dt", -1, NULL, 0);

One option, and I don't know if this would be acceptable, would be to 
add a new wrapper function in the cpufreq-dt driver for the above that 
other drivers could call and that would create the dependency you need.

Jon

-- 
nvpublic


  reply	other threads:[~2025-05-15  6:42 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-09  0:04 [PATCH v4 0/2] Support building tegra124-cpufreq as a module Aaron Kling
2025-05-09  0:04 ` Aaron Kling via B4 Relay
2025-05-09  0:04 ` [PATCH v4 1/2] cpufreq: tegra124: Remove use of disable_cpufreq Aaron Kling
2025-05-09  0:04   ` Aaron Kling via B4 Relay
2025-05-09 11:04   ` Jon Hunter
2025-05-09 16:57     ` Aaron Kling
2025-05-14 16:26       ` Aaron Kling
2025-05-19 10:17     ` Viresh Kumar
2025-05-20  9:53       ` Jon Hunter
2025-05-20 10:02         ` Viresh Kumar
2025-05-28 17:29           ` Aaron Kling
2025-05-29  5:16             ` Viresh Kumar
2025-06-05 10:34           ` Jon Hunter
2025-06-05 10:51             ` Viresh Kumar
2025-06-30 18:43               ` Aaron Kling
2025-07-01  6:23                 ` Viresh Kumar
2025-05-09  0:04 ` [PATCH v4 2/2] cpufreq: tegra124: Allow building as a module Aaron Kling
2025-05-09  0:04   ` Aaron Kling via B4 Relay
2025-05-09 13:37   ` Jon Hunter
2025-05-13  4:26     ` Aaron Kling
2025-05-14 10:31       ` Jon Hunter
2025-05-14 16:43       ` Aaron Kling
2025-05-15  6:41         ` Jon Hunter [this message]
2025-05-19 10:37           ` Viresh Kumar
2025-05-20  9:57             ` Jon Hunter
2025-05-20 10:33               ` Viresh Kumar
2025-05-20 15:38                 ` Aaron Kling
2025-05-14 10:31   ` Jon Hunter
2025-05-14 16:30     ` Aaron Kling
2025-05-15  6:21       ` Jon Hunter
2025-05-19 10:26     ` Viresh Kumar
2025-05-20 10:03       ` Jon Hunter
2025-05-20 10:30         ` Viresh Kumar
2025-05-20 11:46           ` Jon Hunter

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=bc0a4c75-df5b-4b4d-9c9e-a2c99d3f4f6e@nvidia.com \
    --to=jonathanh@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=thierry.reding@gmail.com \
    --cc=viresh.kumar@linaro.org \
    --cc=webgeek1234@gmail.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.