From: Konrad Dybcio <konrad.dybcio@linaro.org>
To: Doug Anderson <dianders@chromium.org>,
Luca Weiss <luca.weiss@fairphone.com>
Cc: cros-qcom-dts-watchers@chromium.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>,
Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
Linus Walleij <linus.walleij@linaro.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
~postmarketos/upstreaming@lists.sr.ht,
phone-devel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-pm@vger.kernel.org
Subject: Re: [PATCH 02/11] nvmem: qfprom: Mark core clk as optional
Date: Sat, 2 Sep 2023 13:28:19 +0200 [thread overview]
Message-ID: <c11abae5-f8d8-468d-a651-ecbbbec9e9e6@linaro.org> (raw)
In-Reply-To: <CAD=FV=UG-dFg7wZsn6n=pkejie0fr+G0q3CguNspGYxoC2ZBLw@mail.gmail.com>
On 1.09.2023 17:08, Doug Anderson wrote:
> Hi,
>
> On Fri, Sep 1, 2023 at 7:54 AM Luca Weiss <luca.weiss@fairphone.com> wrote:
>>
>>>>> So maybe the right fix here is to just change your dts to specify one
>>>>> memory region?
>>>>
>>>> I got feedback from Konrad that this here would be the preferred
>>>> approach compared to having a different dts for ChromeOS vs non-ChromeOS
>>>> devices. I don't feel strongly to either, for me it's also okay to
>>>> remove the extra memory regions and only have the main one used on
>>>> regular qcom devices.
>>>>
>>>> Let me know what you think.
>>>
>>> I don't hate the idea of leaving the extra memory regions in the dts.
>>> They do describe the hardware, after all, even if the main OS can't
>>> actually access those memory regions. ...though the same could also be
>>> said about the clock you've removed. Said another way: if you want to
>>> fully describe the hardware then the dts should have the extra memory
>>> regions and the clock. If you are OK w/ just describing the hardware
>>> in the way that the OS has access to then the dts should not have the
>>> extra memory regions and not have the clock. Does that sound right?
>>
>> Not sure which of those memory regions are actually accessible on this
>> board, but honestly I don't even want to try accessing it. Blowing fuses
>> is not my wish there ;)
>>
>> On downstream the node is just described like the following:
>>
>> qfprom: qfprom@780000 {
>> compatible = "qcom,qfprom";
>> reg = <0x780000 0x7000>;
>> ...
>> };
>>
>> So we have 0x780000 - 0x786fff here.
>>
>> In sc7280.dtsi we have the following:
>>
>> qfprom: efuse@784000 {
>> compatible = "qcom,sc7280-qfprom", "qcom,qfprom";
>> reg = <0 0x00784000 0 0xa20>,
>> <0 0x00780000 0 0xa20>,
>> <0 0x00782000 0 0x120>,
>> <0 0x00786000 0 0x1fff>;
>> ...
>> };
>>
>> So I guess this:
>> * 0x780000 - 0x780a1f
>> * 0x782000 - 0x78211f
>> * 0x784000 - 0x784a1f
>> * 0x786000 - 0x787ffe
>>
>> So at least the last memory region seems to be partially out of range
>> according to downstream.
>
> From the other discussion, it sounds as if you _can_ leave the clock
> in the device tree and then use "clk_get_optional" here. IMO then, the
> right answer is to use "clk_get_optional" but then also modify the
> check below so that instead of:
>
> /* Only enable writing if we have SoC data. */
> if (priv->soc_data)
> econfig.reg_write = qfprom_reg_write;
>
> It is:
>
> /* Only enable writing if we have SoC data and a valid clock */
> if (priv->soc_data && priv->secclk)
> econfig.reg_write = qfprom_reg_write;
>
>
> Does that work for you?
>
>
>> So after reading all of this I tried running this commmand on the phone
>> and the phone reboots into 900e mode.
>>
>> $ cat /sys/devices/platform/soc@0/784000.efuse/qfprom0/nvmem
>>
>> I guess normally this should work? So if I interpret this correctly, the
>> Linux driver thinks it can access more than it can/should. But also
>> should probably try this command on another chipset to see if it works
>> on any really?
>
> Presumably your firmware needs a different "sc7280_qfprom_keepout". If
> that's true then I guess you'll have to undergo negotiations with the
> DT bindings folks and the nvmem maintainer to figure out how to
> specify that your firmware protects different things than the ChromeOS
> firmware?
Luca, if you feel like wasting some time, you can probably bruteforce
this.
I assume this keepout thing could be expanded in a generic way and
made into a dt property.
Other than that, I think it'd be fine to skip that for now, as it
sounds like it's functional so long as you don't intentionally access
forbidden regs.
Konrad
next prev parent reply other threads:[~2023-09-02 11:28 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-30 9:58 [PATCH 00/11] Initial support for the Fairphone 5 smartphone Luca Weiss
2023-08-30 9:58 ` [PATCH 01/11] arm64: dts: qcom: sc7280: Mark some nodes as 'reserved' Luca Weiss
2023-08-30 10:08 ` Konrad Dybcio
2023-08-30 10:35 ` Luca Weiss
2023-08-30 10:45 ` Konrad Dybcio
2023-08-30 9:58 ` [PATCH 02/11] nvmem: qfprom: Mark core clk as optional Luca Weiss
2023-08-30 10:03 ` Krzysztof Kozlowski
2023-08-30 14:30 ` Doug Anderson
2023-08-30 14:43 ` Luca Weiss
2023-08-30 14:57 ` Doug Anderson
2023-09-01 14:54 ` Luca Weiss
2023-09-01 15:08 ` Doug Anderson
2023-09-02 11:28 ` Konrad Dybcio [this message]
2023-09-04 8:14 ` Luca Weiss
2023-09-01 20:29 ` Trilok Soni
2023-08-30 9:58 ` [PATCH 03/11] arm64: dts: qcom: sc7280: Move qfprom clock to chrome-common Luca Weiss
2023-08-30 10:09 ` Konrad Dybcio
2023-08-31 11:28 ` Luca Weiss
2023-08-30 9:58 ` [PATCH 04/11] arm64: dts: qcom: pm7250b: make SID configurable Luca Weiss
2023-08-30 10:06 ` Krzysztof Kozlowski
2023-08-31 10:12 ` Luca Weiss
2023-08-31 11:33 ` Dmitry Baryshkov
2023-08-31 11:54 ` Krzysztof Kozlowski
2023-08-31 12:27 ` Dmitry Baryshkov
2023-09-05 8:30 ` Luca Weiss
2023-09-11 8:34 ` Luca Weiss
2023-09-11 9:44 ` Krzysztof Kozlowski
2023-09-11 9:59 ` Luca Weiss
2023-09-11 11:15 ` Krzysztof Kozlowski
2023-09-11 11:22 ` Konrad Dybcio
2023-08-31 12:32 ` Luca Weiss
2023-08-30 9:58 ` [PATCH 05/11] arm64: dts: qcom: pm8350c: Add flash led node Luca Weiss
2023-08-30 9:58 ` [PATCH 06/11] dt-bindings: pinctrl: qcom,sc7280: Allow gpio-reserved-ranges Luca Weiss
2023-08-30 10:08 ` Krzysztof Kozlowski
2023-08-30 11:47 ` Linus Walleij
2023-08-30 9:58 ` [PATCH 07/11] dt-bindings: arm: qcom,ids: Add SoC ID for QCM6490 Luca Weiss
2023-08-30 10:08 ` Krzysztof Kozlowski
2023-08-30 10:16 ` Konrad Dybcio
2023-08-30 9:58 ` [PATCH 08/11] soc: qcom: socinfo: " Luca Weiss
2023-08-30 10:09 ` Krzysztof Kozlowski
2023-08-30 9:58 ` [PATCH 09/11] cpufreq: Add QCM6490 to cpufreq-dt-platdev blocklist Luca Weiss
2023-08-30 10:10 ` Krzysztof Kozlowski
2023-08-31 5:01 ` Viresh Kumar
2023-08-30 9:58 ` [PATCH 10/11] dt-bindings: arm: qcom: Add QCM6490 Fairphone 5 Luca Weiss
2023-08-30 10:13 ` Krzysztof Kozlowski
2023-08-30 9:58 ` [PATCH 11/11] arm64: dts: qcom: qcm6490: Add device-tree for " Luca Weiss
2023-08-30 10:17 ` Krzysztof Kozlowski
2023-08-30 10:45 ` Konrad Dybcio
2023-09-01 14:27 ` Luca Weiss
2023-09-02 11:45 ` Konrad Dybcio
2023-09-04 8:19 ` Luca Weiss
2023-09-14 16:04 ` (subset) [PATCH 00/11] Initial support for the Fairphone 5 smartphone Bjorn Andersson
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=c11abae5-f8d8-468d-a651-ecbbbec9e9e6@linaro.org \
--to=konrad.dybcio@linaro.org \
--cc=agross@kernel.org \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=cros-qcom-dts-watchers@chromium.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=luca.weiss@fairphone.com \
--cc=phone-devel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=robh+dt@kernel.org \
--cc=srinivas.kandagatla@linaro.org \
--cc=viresh.kumar@linaro.org \
--cc=~postmarketos/upstreaming@lists.sr.ht \
/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).