From: Doug Anderson <dianders@chromium.org>
To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: "Ravi Kumar Bokka (Temp)" <rbokka@codeaurora.org>,
Rob Herring <robh+dt@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
Rajendra Nayak <rnayak@codeaurora.org>,
Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>,
dhavalp@codeaurora.org, mturney@codeaurora.org,
sparate@codeaurora.org, c_rbokka@codeaurora.org,
mkurumel@codeaurora.org
Subject: Re: [RFC v1 2/3] drivers: nvmem: Add driver for QTI qfprom-efuse support
Date: Thu, 21 May 2020 08:10:35 -0700 [thread overview]
Message-ID: <CAD=FV=W+UES1f3reMhvPPUho5FbaZXdU-2jkRaPcbBEzDWT+WQ@mail.gmail.com> (raw)
In-Reply-To: <99f07eaa-d072-f391-098e-e6f7a50a1960@linaro.org>
Hi,
On Thu, May 21, 2020 at 8:01 AM Srinivas Kandagatla
<srinivas.kandagatla@linaro.org> wrote:
>
> On 20/05/2020 23:48, Doug Anderson wrote:
> >> Is this only applicable for corrected address space?
> > I guess I was proposing a two dts-node / two drive approach here.
> >
> > dts node #1:just covers the memory range for accessing the FEC-corrected data
> > driver #1: read-only and reads the FEC-corrected data
> >
> > dts node #2: covers the memory range that's_not_ the FEC-corrected
> > memory range.
> > driver #2: read-write. reading reads uncorrected data
> >
> > Does that seem sane?
>
> I see your point but it does not make sense to have two node for same thing.
OK, so that sounds as if we want to go with the proposal where we
"deprecate the old driver and/or bindings and say that there really
should just be one node and one driver".
Would this be acceptable to you?
1. Officially mark the old bindings as deprecated.
2. Leave the old driver there to support the old deprecated bindings,
at least until everyone can be transferred over. There seem to be
quite a few existing users of "qcom,qfprom" and we're supposed to make
an attempt at keeping the old device trees working, at least for a
little while. Once everyone is transferred over we could decide to
delete the old driver.
3. We will have a totally new driver here.
4. A given device tree will _not_ be allowed to have both
"qcom,qfprom" specified and "qcom,SOC-qfprom" specified. ...and by
"qcom,SOC-qfprom" I mean that SOC should be replaced by the SoC name,
so "qcom,sc7180-qfprom" or "qcom,sdm845-qfprom". So once you switch
to the new node it replaces the old node.
> Isn't the raw address space reads used to for blowing and checking the
> fuses if they are blown correctly or not and software usage of these
> fuses should only be done from correct address space?
>
> the read interface to user should be always from corrected address space
> and write interface should be to raw address space.
Great. That sounds right to me. Presumably the driver could add some
sort of "debugfs" access to read the raw address space if needed.
-Doug
next prev parent reply other threads:[~2020-05-21 15:10 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-12 18:17 [RFC v1 0/3] Add QTI QFPROM-Efuse driver support Ravi Kumar Bokka
2020-05-12 18:17 ` [RFC v1 1/3] dt-bindings: nvmem: Add devicetree bindings for qfprom-efuse Ravi Kumar Bokka
2020-05-12 22:36 ` Rob Herring
2020-05-12 23:03 ` Doug Anderson
2020-05-12 18:17 ` [RFC v1 2/3] drivers: nvmem: Add driver for QTI qfprom-efuse support Ravi Kumar Bokka
2020-05-12 19:20 ` Randy Dunlap
2020-05-12 23:02 ` Doug Anderson
2020-05-13 13:20 ` Srinivas Kandagatla
2020-05-14 12:26 ` Ravi Kumar Bokka (Temp)
2020-05-14 18:21 ` Doug Anderson
2020-05-17 14:57 ` Ravi Kumar Bokka (Temp)
2020-05-18 10:33 ` Ravi Kumar Bokka (Temp)
2020-05-15 11:09 ` Srinivas Kandagatla
2020-05-18 10:39 ` Ravi Kumar Bokka (Temp)
2020-05-18 10:44 ` Srinivas Kandagatla
2020-05-18 18:31 ` Doug Anderson
2020-05-20 14:35 ` Srinivas Kandagatla
2020-05-20 22:48 ` Doug Anderson
2020-05-21 15:00 ` Srinivas Kandagatla
2020-05-21 15:10 ` Doug Anderson [this message]
2020-05-21 15:55 ` Srinivas Kandagatla
2020-05-21 21:28 ` Doug Anderson
2020-05-22 11:18 ` Srinivas Kandagatla
2020-05-26 22:31 ` Doug Anderson
2020-06-01 9:24 ` Srinivas Kandagatla
2020-06-01 18:08 ` Doug Anderson
2020-06-02 10:56 ` Srinivas Kandagatla
2020-05-16 14:22 ` kbuild test robot
2020-05-16 14:22 ` [RFC PATCH] drivers: nvmem: addr_in_qfprom_range() can be static kbuild test robot
2020-05-12 18:18 ` [RFC v1 3/3] arm64: dts: qcom: sc7180: Add qfprom-efuse Ravi Kumar Bokka
2020-05-12 23:03 ` [RFC v1 0/3] Add QTI QFPROM-Efuse driver support Doug Anderson
[not found] ` <fb7f601f-388f-8a77-bb22-e1398f90326f@codeaurora.org>
2020-05-14 18:21 ` Doug Anderson
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='CAD=FV=W+UES1f3reMhvPPUho5FbaZXdU-2jkRaPcbBEzDWT+WQ@mail.gmail.com' \
--to=dianders@chromium.org \
--cc=c_rbokka@codeaurora.org \
--cc=devicetree@vger.kernel.org \
--cc=dhavalp@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mkurumel@codeaurora.org \
--cc=mturney@codeaurora.org \
--cc=rbokka@codeaurora.org \
--cc=rnayak@codeaurora.org \
--cc=robh+dt@kernel.org \
--cc=saiprakash.ranjan@codeaurora.org \
--cc=sparate@codeaurora.org \
--cc=srinivas.kandagatla@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.