From: Stephan Gerhold <stephan.gerhold@linaro.org>
To: Andi Shyti <andi.shyti@kernel.org>
Cc: Wolfram Sang <wsa@kernel.org>, Andy Gross <agross@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
linux-arm-msm@vger.kernel.org, linux-i2c@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Konrad Dybcio <konradybcio@kernel.org>
Subject: Re: [PATCH 3/3] i2c: qup: Vote for interconnect bandwidth to DRAM
Date: Thu, 20 Feb 2025 10:47:49 +0100 [thread overview]
Message-ID: <Z7b6ReQdDtAUn5GP@linaro.org> (raw)
In-Reply-To: <sc54ro4pwg5j2lqelsryx7cdw6ipcdp4gfk3ce5sxsvk3s7wzp@wup2pgdzmxtl>
On Wed, Feb 19, 2025 at 08:30:35PM +0100, Andi Shyti wrote:
> On Wed, Feb 19, 2025 at 11:40:16AM +0100, Stephan Gerhold wrote:
> > On Wed, Feb 19, 2025 at 12:02:06AM +0100, Andi Shyti wrote:
> > >
> > > sorry for the very late reply here. Just one question.
> > >
> >
> > Thanks for bringing the patch back up after such a long time. I've been
> > meaning to resend it, but never found the time to do so... :-)
>
> We have a long list of forgotten patches that belong to the far
> past. I'm trying to revive them.
>
Thanks, this is much appreciated!
> [...]
> > > > @@ -1745,6 +1775,11 @@ static int qup_i2c_probe(struct platform_device *pdev)
> > > > goto fail_dma;
> > > > }
> > > > qup->is_dma = true;
> > > > +
> > > > + qup->icc_path = devm_of_icc_get(&pdev->dev, NULL);
> > > > + if (IS_ERR(qup->icc_path))
> > > > + return dev_err_probe(&pdev->dev, PTR_ERR(qup->icc_path),
> > > > + "failed to get interconnect path\n");
> > >
> > > Can we live without it if it fails?
> > >
> >
> > of_icc_get() returns NULL if the interconnect API is disabled, or if
> > "interconnects" is not defined in the device tree, so this is already
> > handled. If "interconnects" is enabled and defined, I think we shouldn't
> > ignore errors. Therefore, this should work as intended.
>
> yes, because qup_i2c_vote_bw() checks inside for NULL values.
>
> My idea was that:
>
> if (IS_ERR(...)) {
> dev_warn(...)
> qup->icc_path = NULL;
> }
>
> and let things work. Anyway, if you want to keep it this way,
> fine with me, I don't have a strong opinion, rather than a
> preference to keep going.
I would prefer to keep it the way it is. It's okay to omit the
"interconnects" in the DT (either for old device trees, or because you
don't define the "dmas" either). But if they are defined, we should not
be ignoring errors. -EPROBE_DEFER definitely needs to be handled, but
even for -EINVAL or similar it would be better to make it obvious in my
opinion.
None of the existing users should be affected, since no one defines
"interconnects" at the moment.
Thanks,
Stephan
next prev parent reply other threads:[~2025-02-20 9:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-28 9:48 [PATCH 0/3] i2c: qup: Allow scaling power domains and interconnect Stephan Gerhold
2023-11-28 9:48 ` [PATCH 1/3] dt-bindings: i2c: qcom,i2c-qup: Document power-domains Stephan Gerhold
2023-11-28 17:50 ` Rob Herring
2023-11-28 9:48 ` [PATCH 2/3] dt-bindings: i2c: qup: Document interconnects Stephan Gerhold
2023-11-28 17:51 ` Rob Herring
2023-11-28 9:48 ` [PATCH 3/3] i2c: qup: Vote for interconnect bandwidth to DRAM Stephan Gerhold
2023-11-28 19:17 ` Andi Shyti
2025-02-18 23:02 ` Andi Shyti
2025-02-18 23:13 ` Andi Shyti
2025-02-19 7:00 ` Krzysztof Kozlowski
2025-02-19 19:36 ` Andi Shyti
2025-02-19 10:40 ` Stephan Gerhold
2025-02-19 19:30 ` Andi Shyti
2025-02-20 9:47 ` Stephan Gerhold [this message]
2025-02-25 13:25 ` Konrad Dybcio
2025-02-26 22:11 ` [PATCH 0/3] i2c: qup: Allow scaling power domains and interconnect Andi Shyti
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=Z7b6ReQdDtAUn5GP@linaro.org \
--to=stephan.gerhold@linaro.org \
--cc=agross@kernel.org \
--cc=andersson@kernel.org \
--cc=andi.shyti@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=konradybcio@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=wsa@kernel.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).