The commit 2e2113c8a64f ("interconnect: qcom: rpm: Handle interface
clocks") has added the is_on flag to the qcom_icc_provider, but failed
to actually utilize it. Drop the flag.

Fixes: 2e2113c8a64f ("interconnect: qcom: rpm: Handle interface clocks")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
 drivers/interconnect/qcom/icc-rpm.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/interconnect/qcom/icc-rpm.h b/drivers/interconnect/qcom/icc-rpm.h
index f4883d43eae4..3366531f66fc 100644
--- a/drivers/interconnect/qcom/icc-rpm.h
+++ b/drivers/interconnect/qcom/icc-rpm.h
@@ -51,7 +51,6 @@ struct rpm_clk_resource {
  * @bus_clk: a pointer to a HLOS-owned bus clock
  * @intf_clks: a clk_bulk_data array of interface clocks
  * @keep_alive: whether to always keep a minimum vote on the bus clocks
- * @is_on: whether the bus is powered on
  */
 struct qcom_icc_provider {
 	struct icc_provider provider;
@@ -66,7 +65,6 @@ struct qcom_icc_provider {
 	struct clk *bus_clk;
 	struct clk_bulk_data *intf_clks;
 	bool keep_alive;
-	bool is_on;
 };
 
 /**

-- 
2.47.3

On 3/23/26 2:17 AM, Dmitry Baryshkov wrote:
> The commit 2e2113c8a64f ("interconnect: qcom: rpm: Handle interface
> clocks") has added the is_on flag to the qcom_icc_provider, but failed
> to actually utilize it. Drop the flag.
> 
> Fixes: 2e2113c8a64f ("interconnect: qcom: rpm: Handle interface clocks")
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
>  drivers/interconnect/qcom/icc-rpm.h | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/interconnect/qcom/icc-rpm.h b/drivers/interconnect/qcom/icc-rpm.h
> index f4883d43eae4..3366531f66fc 100644
> --- a/drivers/interconnect/qcom/icc-rpm.h
> +++ b/drivers/interconnect/qcom/icc-rpm.h
> @@ -51,7 +51,6 @@ struct rpm_clk_resource {
>   * @bus_clk: a pointer to a HLOS-owned bus clock
>   * @intf_clks: a clk_bulk_data array of interface clocks
>   * @keep_alive: whether to always keep a minimum vote on the bus clocks
> - * @is_on: whether the bus is powered on
>   */
>  struct qcom_icc_provider {
>  	struct icc_provider provider;
> @@ -66,7 +65,6 @@ struct qcom_icc_provider {
>  	struct clk *bus_clk;
>  	struct clk_bulk_data *intf_clks;
>  	bool keep_alive;
> -	bool is_on;

Hm, looks like the clock vote is kept all the way from .probe()
to .remove(). I wonder if that's really what should happen..

That's what drivers/interconnect/qcom/holi.c does on msm-5.10

Maybe "iface clocks" are only needed to execute a ->set() on a node?

Konrad

On Mon, Mar 23, 2026 at 11:26:47AM +0100, Konrad Dybcio wrote:
> On 3/23/26 2:17 AM, Dmitry Baryshkov wrote:
> > The commit 2e2113c8a64f ("interconnect: qcom: rpm: Handle interface
> > clocks") has added the is_on flag to the qcom_icc_provider, but failed
> > to actually utilize it. Drop the flag.
> > 
> > Fixes: 2e2113c8a64f ("interconnect: qcom: rpm: Handle interface clocks")
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > ---
> >  drivers/interconnect/qcom/icc-rpm.h | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/drivers/interconnect/qcom/icc-rpm.h b/drivers/interconnect/qcom/icc-rpm.h
> > index f4883d43eae4..3366531f66fc 100644
> > --- a/drivers/interconnect/qcom/icc-rpm.h
> > +++ b/drivers/interconnect/qcom/icc-rpm.h
> > @@ -51,7 +51,6 @@ struct rpm_clk_resource {
> >   * @bus_clk: a pointer to a HLOS-owned bus clock
> >   * @intf_clks: a clk_bulk_data array of interface clocks
> >   * @keep_alive: whether to always keep a minimum vote on the bus clocks
> > - * @is_on: whether the bus is powered on
> >   */
> >  struct qcom_icc_provider {
> >  	struct icc_provider provider;
> > @@ -66,7 +65,6 @@ struct qcom_icc_provider {
> >  	struct clk *bus_clk;
> >  	struct clk_bulk_data *intf_clks;
> >  	bool keep_alive;
> > -	bool is_on;
> 
> Hm, looks like the clock vote is kept all the way from .probe()
> to .remove(). I wonder if that's really what should happen..

Well, it's probably up to you to decide. I've a bit lost my way in the
vendor's adhoc / bus / etc. code.

> 
> That's what drivers/interconnect/qcom/holi.c does on msm-5.10
> 
> Maybe "iface clocks" are only needed to execute a ->set() on a node?

Hmm, I don't know. AXI clocks seems to describe the clocking between the
NoC and a particular device. So maybe it's required for as long as there
is something using the NoC.

-- 
With best wishes
Dmitry

On 3/24/26 12:12 AM, Dmitry Baryshkov wrote:
> On Mon, Mar 23, 2026 at 11:26:47AM +0100, Konrad Dybcio wrote:
>> On 3/23/26 2:17 AM, Dmitry Baryshkov wrote:
>>> The commit 2e2113c8a64f ("interconnect: qcom: rpm: Handle interface
>>> clocks") has added the is_on flag to the qcom_icc_provider, but failed
>>> to actually utilize it. Drop the flag.
>>>
>>> Fixes: 2e2113c8a64f ("interconnect: qcom: rpm: Handle interface clocks")
>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>> ---
>>>  drivers/interconnect/qcom/icc-rpm.h | 2 --
>>>  1 file changed, 2 deletions(-)
>>>
>>> diff --git a/drivers/interconnect/qcom/icc-rpm.h b/drivers/interconnect/qcom/icc-rpm.h
>>> index f4883d43eae4..3366531f66fc 100644
>>> --- a/drivers/interconnect/qcom/icc-rpm.h
>>> +++ b/drivers/interconnect/qcom/icc-rpm.h
>>> @@ -51,7 +51,6 @@ struct rpm_clk_resource {
>>>   * @bus_clk: a pointer to a HLOS-owned bus clock
>>>   * @intf_clks: a clk_bulk_data array of interface clocks
>>>   * @keep_alive: whether to always keep a minimum vote on the bus clocks
>>> - * @is_on: whether the bus is powered on
>>>   */
>>>  struct qcom_icc_provider {
>>>  	struct icc_provider provider;
>>> @@ -66,7 +65,6 @@ struct qcom_icc_provider {
>>>  	struct clk *bus_clk;
>>>  	struct clk_bulk_data *intf_clks;
>>>  	bool keep_alive;
>>> -	bool is_on;
>>
>> Hm, looks like the clock vote is kept all the way from .probe()
>> to .remove(). I wonder if that's really what should happen..
> 
> Well, it's probably up to you to decide. I've a bit lost my way in the
> vendor's adhoc / bus / etc. code.
> 
>>
>> That's what drivers/interconnect/qcom/holi.c does on msm-5.10
>>
>> Maybe "iface clocks" are only needed to execute a ->set() on a node?
> 
> Hmm, I don't know. AXI clocks seems to describe the clocking between the
> NoC and a particular device. So maybe it's required for as long as there
> is something using the NoC.

I'll keep this on my infinite todolist

Konrad