From: Jonathan Cameron <jic23@jic23.retrosnub.co.uk>
To: Caleb Connolly <caleb.connolly@linaro.org>
Cc: Lars-Peter Clausen <lars@metafoo.de>,
Rob Herring <robh+dt@kernel.org>, Andy Gross <agross@kernel.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Lee Jones <lee.jones@linaro.org>,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
sumit.semwal@linaro.org, amit.pundir@linaro.org,
john.stultz@linaro.org
Subject: Re: [PATCH v3 1/7] mfd: qcom-spmi-pmic: expose the PMIC revid information to clients
Date: Sat, 15 Jan 2022 13:06:26 +0000 [thread overview]
Message-ID: <20220115130626.2c018335@jic23-huawei> (raw)
In-Reply-To: <53e76d68-3e47-f221-b5c4-5e29a958c5fc@linaro.org>
On Mon, 10 Jan 2022 11:46:39 +0000
Caleb Connolly <caleb.connolly@linaro.org> wrote:
> On 09/01/2022 16:57, Jonathan Cameron wrote:
> > On Thu, 6 Jan 2022 17:31:25 +0000
> > Caleb Connolly <caleb.connolly@linaro.org> wrote:
> >
> >> Some PMIC functions such as the RRADC need to be aware of the PMIC
> >> chip revision information to implement errata or otherwise adjust
> >> behaviour, export the PMIC information to enable this.
> >>
> >> This is specifically required to enable the RRADC to adjust
> >> coefficients based on which chip fab the PMIC was produced in,
> >> this can vary per unique device and therefore has to be read at
> >> runtime.
> >>
> >> Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
> > Hi Caleb,
> >
> > Some comments inline.
> Hi Jonathan,
>
> Thanks for the feedback, I had a question about one of your points below.
Miss read on my part.
> >>
> >> static const struct regmap_config spmi_regmap_config = {
> >> @@ -144,22 +122,38 @@ static const struct regmap_config spmi_regmap_config = {
> >> static int pmic_spmi_probe(struct spmi_device *sdev)
> >> {
> >> struct regmap *regmap;
> >> + struct qcom_spmi_pmic *pmic;
> >>
> >> regmap = devm_regmap_init_spmi_ext(sdev, &spmi_regmap_config);
> >> if (IS_ERR(regmap))
> >> return PTR_ERR(regmap);
> >>
> >> + pmic = devm_kzalloc(&sdev->dev, sizeof(*pmic), GFP_KERNEL);
> >> + if (!pmic)
> >> + return -ENOMEM;
> >
> > Within the code visible here, why can't this just be on the stack?
> I allocated on the heap beacuse the data has to be read by other drivers
> (it's handed over in spmi_device_set_drvdata() below). I don't have a
> whole lot of C experience so please forgive the potentially ignorant
> questions - is it ok to allocate on the stack if the object needs to
> have a lifetime longer than the function?
You are of course correct. I just missed the set_drvdata call when reading this
and thought it was just being used for the print! Oops.
next prev parent reply other threads:[~2022-01-15 13:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-06 17:31 [PATCH v3 0/7] iio: adc: introduce Qualcomm SPMI Round Robin ADC Caleb Connolly
2022-01-06 17:31 ` [PATCH v3 1/7] mfd: qcom-spmi-pmic: expose the PMIC revid information to clients Caleb Connolly
2022-01-09 16:57 ` Jonathan Cameron
2022-01-10 11:46 ` Caleb Connolly
2022-01-15 13:06 ` Jonathan Cameron [this message]
2022-01-10 18:41 ` Bjorn Andersson
2022-01-06 17:31 ` [PATCH v3 2/7] dt-bindings: iio: adc: document qcom-spmi-rradc Caleb Connolly
2022-01-06 17:31 ` [PATCH v3 3/7] iio: adc: qcom-spmi-rradc: introduce round robin adc Caleb Connolly
2022-01-09 17:29 ` Jonathan Cameron
2022-01-19 17:42 ` Caleb Connolly
2022-01-21 13:45 ` Jonathan Cameron
2022-01-06 17:31 ` [PATCH v3 4/7] arm64: dts: qcom: pmi8998: add rradc node Caleb Connolly
2022-01-06 17:31 ` [PATCH v3 5/7] arm64: dts: qcom: sdm845-oneplus: enable rradc Caleb Connolly
2022-01-06 17:31 ` [PATCH v3 6/7] arm64: dts: qcom: sdm845-db845c: " Caleb Connolly
2022-01-06 17:31 ` [PATCH v3 7/7] arm64: dts: qcom: sdm845-xiaomi-beryllium: enable RRADC Caleb Connolly
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=20220115130626.2c018335@jic23-huawei \
--to=jic23@jic23.retrosnub.co.uk \
--cc=agross@kernel.org \
--cc=amit.pundir@linaro.org \
--cc=bjorn.andersson@linaro.org \
--cc=caleb.connolly@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=john.stultz@linaro.org \
--cc=lars@metafoo.de \
--cc=lee.jones@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=sumit.semwal@linaro.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 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.