[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1537813423.7736.46.camel@impinj.com>
Date: Mon, 24 Sep 2018 18:23:44 +0000
From: Trent Piepho <tpiepho@...inj.com>
To: "dianders@...omium.org" <dianders@...omium.org>,
"swboyd@...omium.org" <swboyd@...omium.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"robh+dt@...nel.org" <robh+dt@...nel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
"broonie@...nel.org" <broonie@...nel.org>,
"mark.rutland@....com" <mark.rutland@....com>,
"boris.brezillon@...tlin.com" <boris.brezillon@...tlin.com>,
"linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
"ryandcase@...omium.org" <ryandcase@...omium.org>,
"girishm@...eaurora.org" <girishm@...eaurora.org>
Subject: Re: [PATCH v2 1/2] dt-bindings: spi: Qualcomm Quad SPI(QSPI)
documentation
On Mon, 2018-09-24 at 10:13 -0700, Doug Anderson wrote:
> IIUC previous suggestions about just naming it based on the first SoC
> was due to the difficulty of coming up with a good generic name to
> give something. For instance you definitely wouldn't want to name it
> "qcom-qspi-sdm8xx" because you have no idea what future SoCs will be
> numbered.
And the hypothetical sdm899 might use a non-compatible device that uses
a different driver, and that really makes "qcom-qspi-sdm8xx" look dumb.
>
> In the case here calling it "qcom,qspi-v1" is better than that and if
> Rob gives the thumbs up then I won't object to it. In general though
> looking at other device tree bindings this doesn't seem like a thing
> commonly done. Perhaps if we decide it's useful here we should start
> suggesting it everywhere...
It would help if the programming model or IP core name or whatever this
is using was mentioned in the public reference manual for the SoC.
Then is a lot more clear that a number of different SoCs all have the
same quad spi controller inside them.
Usually it's not like that. The RMs just say, "it's got a SPI master
with these registers." What SoCs use the same IP module, which
different? When did they make a new version? The silicon vendors
don't tell you this. So any name we make up for the IP module likely
doesn't match reality.
Powered by blists - more mailing lists