[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <deeefaf8-2ac9-cee0-eed4-687e36ac6f10@quicinc.com>
Date: Fri, 1 Sep 2023 13:29:03 -0700
From: Trilok Soni <quic_tsoni@...cinc.com>
To: Luca Weiss <luca.weiss@...rphone.com>,
Doug Anderson <dianders@...omium.org>
CC: <cros-qcom-dts-watchers@...omium.org>,
Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
Linus Walleij <linus.walleij@...aro.org>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Viresh Kumar <viresh.kumar@...aro.org>,
<~postmarketos/upstreaming@...ts.sr.ht>,
<phone-devel@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-gpio@...r.kernel.org>, <linux-pm@...r.kernel.org>
Subject: Re: [PATCH 02/11] nvmem: qfprom: Mark core clk as optional
On 8/30/2023 7:43 AM, Luca Weiss wrote:
> On Wed Aug 30, 2023 at 4:30 PM CEST, Doug Anderson wrote:
>> Hi,
>>
>> On Wed, Aug 30, 2023 at 2:58 AM Luca Weiss <luca.weiss@...rphone.com> wrote:
>>>
>>> On some platforms like sc7280 on non-ChromeOS devices the core clock
>>> cannot be touched by Linux so we cannot provide it. Mark it as optional
>>> as accessing qfprom works without it.
>>>
>>> Signed-off-by: Luca Weiss <luca.weiss@...rphone.com>
>>> ---
>>> drivers/nvmem/qfprom.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> Are you actually testing burning fuses from the OS, or are you just
>> using the nvmem in "read-only" mode? From comments in the bindings, if
>> you're trying to burn the fuses then the clock is required. If things
>> are in read-only mode then the clock isn't required.
>
> Hi Doug,
>
> I definitely don't plan on burning any fuses on this phone. Not even
> sure that's allowed by the TZ / boot stack.
>
>>
>> When I compare to the driver, it seems like the driver assumes that if
>> more than one memory region is provided then you must be supporting
>> burning fuses. The bindings agree that having 4 memory regions
>> specified means that the nvmem supports burning and 1 memory region
>> specified means read-only. The extra 3 memory regions in the nvmem are
>> all about fuse burning, I believe.
>>
>> 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 would prefer to re-use the sc7280 DT as well. Thank you for your patches. We plan to use your patches for platform on the same part.
--
---Trilok Soni
Powered by blists - more mailing lists