public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: Mike Tipton <quic_mdtipton@quicinc.com>
To: Johan Hovold <johan@kernel.org>
Cc: Johan Hovold <johan+linaro@kernel.org>,
	Georgi Djakov <djakov@kernel.org>,
	Bjorn Andersson <andersson@kernel.org>,
	<linux-pm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	Konrad Dybcio <konrad.dybcio@linaro.org>,
	Odelu Kukatla <quic_okukatla@quicinc.com>
Subject: Re: [PATCH RESEND v2] interconnect: drop unused icc_get() interface
Date: Wed, 21 Jun 2023 07:10:07 -0700	[thread overview]
Message-ID: <ee483022-3f1d-3e79-bbdb-71c22c48c73b@quicinc.com> (raw)
In-Reply-To: <ZJK2Ki6--nLe8bK0@hovoldconsulting.com>

On 6/21/2023 1:34 AM, Johan Hovold wrote:
> On Tue, Jun 20, 2023 at 02:57:17PM -0700, Mike Tipton wrote:
>> On 5/23/2023 2:52 AM, Johan Hovold wrote:
>>> The icc_get() interface can be used to lookup an interconnect path based
>>> on global node ids. There has never been any users of this interface and
>>> all lookups are currently done from the devicetree.
>>>
>>> Remove the unused icc_get() interface.
>>>
>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
>>> Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
> 
>> We have downstream debug/test modules that removing icc_get() will
>> break. I'd like to get equivalent debug support in mainline, but until
>> then I'd prefer we not remove this.
> 
> I'm sure you've heard this before, but if it's not in mainline it does
> not count. We don't carry code upstream for the sole benefit of
> out-of-tree users.

Yeah, I understand that in general.

> 
>> I suspect having a mainline approach for voting paths from debugfs would
>> be useful to others as well. There are similar debugfs control
>> mechanisms in other frameworks already, e.g. clock.
>>
>> Instead of removing icc_get() immediately, can we wait for a future
>> patch series that adds debugfs as a consumer?
> 
> This function was merged over four years ago and has never been used in
> mainline and I doubt a user will suddenly show up in the near future if
> we were to keep it.

I guess I'm hoping if it's already been unused in mainline for four 
years, that we can keep it a little longer until the mainline debugfs 
user can be added.

We can prepare that series. Not entirely sure when it'll be ready, but 
can try to prioritize it.

> 
> I guess you can just carry one more patch out-of-tree until you can
> mainline a proper debugfs interface (which should probably not even use
> this function, as you mentioned yourself).
That's not really possible in this case. We're limited to our DLKMs 
running on top of the Android kernel. We can't modify the interconnect 
framework itself.

> 
> Johan

      reply	other threads:[~2023-06-21 14:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-23  9:52 [PATCH RESEND v2] interconnect: drop unused icc_get() interface Johan Hovold
2023-05-23 12:09 ` Bjorn Andersson
2023-06-20 21:57 ` Mike Tipton
2023-06-21  8:34   ` Johan Hovold
2023-06-21 14:10     ` Mike Tipton [this message]

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=ee483022-3f1d-3e79-bbdb-71c22c48c73b@quicinc.com \
    --to=quic_mdtipton@quicinc.com \
    --cc=andersson@kernel.org \
    --cc=djakov@kernel.org \
    --cc=johan+linaro@kernel.org \
    --cc=johan@kernel.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=quic_okukatla@quicinc.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