Add otp device node for Stingray SOC.
Fixes: 2fa9e9e29ea2 ("arm64: dts: Add GPIO DT nodes for Stingray SOC")
Signed-off-by: Scott Branden <[email protected]>
---
arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index 99aaff0..6013478 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -258,6 +258,13 @@
#include "stingray-clock.dtsi"
+ otp: otp@1c400 {
+ compatible = "brcm,ocotp-v2";
+ reg = <0x0001c400 0x68>;
+ brcm,ocotp-size = <2048>;
+ status = "okay";
+ };
+
gpio_crmu: gpio@24800 {
compatible = "brcm,iproc-gpio";
reg = <0x00024800 0x4c>;
--
2.5.0
On 05/23/2018 01:17 PM, Scott Branden wrote:
> Add otp device node for Stingray SOC.
>
> Fixes: 2fa9e9e29ea2 ("arm64: dts: Add GPIO DT nodes for Stingray SOC")
> Signed-off-by: Scott Branden <[email protected]>
Applied to devicetree-arm64/next with s/otp/OTP/ and removing the Fixes
line since that is not a bug fix AFAICT.
Thank you
--
Florian
Hi Florian,
On 18-06-04 02:24 PM, Florian Fainelli wrote:
> On 05/23/2018 01:17 PM, Scott Branden wrote:
>> Add otp device node for Stingray SOC.
>>
>> Fixes: 2fa9e9e29ea2 ("arm64: dts: Add GPIO DT nodes for Stingray SOC")
>> Signed-off-by: Scott Branden <[email protected]>
> Applied to devicetree-arm64/next with s/otp/OTP/ and removing the Fixes
> line since that is not a bug fix AFAICT.
It fixes the issue that OTP is not active as it is missing the device node?
>
> Thank you
On 06/04/2018 02:30 PM, Scott Branden wrote:
> Hi Florian,
>
>
> On 18-06-04 02:24 PM, Florian Fainelli wrote:
>> On 05/23/2018 01:17 PM, Scott Branden wrote:
>>> Add otp device node for Stingray SOC.
>>>
>>> Fixes: 2fa9e9e29ea2 ("arm64: dts: Add GPIO DT nodes for Stingray SOC")
>>> Signed-off-by: Scott Branden <[email protected]>
>> Applied to devicetree-arm64/next with s/otp/OTP/ and removing the Fixes
>> line since that is not a bug fix AFAICT.
> It fixes the issue that OTP is not active as it is missing the device node?
By that token, any peripheral that is being added at some point in the
lifetime of this DTS would qualify as a bugfix when it is in fact
feature/peripheral enabling.
I could not see the relationship between the commit being provided in
the "Fixes:" tag and OTP, am I missing something?
--
Florian
On 18-06-04 02:33 PM, Florian Fainelli wrote:
> On 06/04/2018 02:30 PM, Scott Branden wrote:
>> Hi Florian,
>>
>>
>> On 18-06-04 02:24 PM, Florian Fainelli wrote:
>>> On 05/23/2018 01:17 PM, Scott Branden wrote:
>>>> Add otp device node for Stingray SOC.
>>>>
>>>> Fixes: 2fa9e9e29ea2 ("arm64: dts: Add GPIO DT nodes for Stingray SOC")
>>>> Signed-off-by: Scott Branden <[email protected]>
>>> Applied to devicetree-arm64/next with s/otp/OTP/ and removing the Fixes
>>> line since that is not a bug fix AFAICT.
>> It fixes the issue that OTP is not active as it is missing the device node?
> By that token, any peripheral that is being added at some point in the
> lifetime of this DTS would qualify as a bugfix when it is in fact
> feature/peripheral enabling.
>
> I could not see the relationship between the commit being provided in
> the "Fixes:" tag and OTP, am I missing something?
The relationship is the fixes tag points was selected to the last tag
when the commit applies directly against (and is far enough back that it
covers any possible LTS kernels that would have needed it). In this case
I don't care too much about whether this is fixed in LTS or not. If
needed I'll send a request for the commit be ported to stable.
On 06/04/2018 03:33 PM, Scott Branden wrote:
>
>
> On 18-06-04 02:33 PM, Florian Fainelli wrote:
>> On 06/04/2018 02:30 PM, Scott Branden wrote:
>>> Hi Florian,
>>>
>>>
>>> On 18-06-04 02:24 PM, Florian Fainelli wrote:
>>>> On 05/23/2018 01:17 PM, Scott Branden wrote:
>>>>> Add otp device node for Stingray SOC.
>>>>>
>>>>> Fixes: 2fa9e9e29ea2 ("arm64: dts: Add GPIO DT nodes for Stingray SOC")
>>>>> Signed-off-by: Scott Branden <[email protected]>
>>>> Applied to devicetree-arm64/next with s/otp/OTP/ and removing the Fixes
>>>> line since that is not a bug fix AFAICT.
>>> It fixes the issue that OTP is not active as it is missing the device
>>> node?
>> By that token, any peripheral that is being added at some point in the
>> lifetime of this DTS would qualify as a bugfix when it is in fact
>> feature/peripheral enabling.
>>
>> I could not see the relationship between the commit being provided in
>> the "Fixes:" tag and OTP, am I missing something?
> The relationship is the fixes tag points was selected to the last tag
> when the commit applies directly against (and is far enough back that it
> covers any possible LTS kernels that would have needed it).
I understand how ones gets to select an appropriate Fixes: tag, what I
don't understand is the relationship between the two changes, like why
would a GPIO Device Tree node influence the OTP peripheral here when
there is no pinmux or GPIO phandle of some sort linking the two. Also,
since you guys were very trigger happy with Fixes: tag lately (referring
to the internal review of Srinath's changes) this one looked a lot like
that.
The only thing I am questioning here is treating that particular
changeset as a bugfix proper. Yes it is technically a fix in that,
without this changeset the OTP node is not there and that is
functionality you want, but it is not preventing the platform from not
booting for instance, or having an incorrect behavior for an established
behavior before, right?
> In this case
> I don't care too much about whether this is fixed in LTS or not. If
> needed I'll send a request for the commit be ported to stable.
If this is a true fix, I don't mind taking it as-is and keeping the
Fixes: tag, keep in mind the following:
I always treat bug fixes with a higher priority than features, and I
will do my best to queue up fixes (separate branches, all ending in
/fixes) and submit those at any time in the release cycle so they can
land in Linus' tree and in the -stable trees as fast as possible.
Don't bypass the maintainer if you can convince me this is a proper fix,
then I will just move that patch into the appropriate branch, and you
will get those stable backports automatically.
Thanks for reading me.
--
Florian
On 18-06-04 03:41 PM, Florian Fainelli wrote:
> On 06/04/2018 03:33 PM, Scott Branden wrote:
>>
>> On 18-06-04 02:33 PM, Florian Fainelli wrote:
>>> On 06/04/2018 02:30 PM, Scott Branden wrote:
>>>> Hi Florian,
>>>>
>>>>
>>>> On 18-06-04 02:24 PM, Florian Fainelli wrote:
>>>>> On 05/23/2018 01:17 PM, Scott Branden wrote:
>>>>>> Add otp device node for Stingray SOC.
>>>>>>
>>>>>> Fixes: 2fa9e9e29ea2 ("arm64: dts: Add GPIO DT nodes for Stingray SOC")
>>>>>> Signed-off-by: Scott Branden <[email protected]>
>>>>> Applied to devicetree-arm64/next with s/otp/OTP/ and removing the Fixes
>>>>> line since that is not a bug fix AFAICT.
>>>> It fixes the issue that OTP is not active as it is missing the device
>>>> node?
>>> By that token, any peripheral that is being added at some point in the
>>> lifetime of this DTS would qualify as a bugfix when it is in fact
>>> feature/peripheral enabling.
>>>
>>> I could not see the relationship between the commit being provided in
>>> the "Fixes:" tag and OTP, am I missing something?
>> The relationship is the fixes tag points was selected to the last tag
>> when the commit applies directly against (and is far enough back that it
>> covers any possible LTS kernels that would have needed it).
> I understand how ones gets to select an appropriate Fixes: tag, what I
> don't understand is the relationship between the two changes, like why
> would a GPIO Device Tree node influence the OTP peripheral here when
> there is no pinmux or GPIO phandle of some sort linking the two. Also,
> since you guys were very trigger happy with Fixes: tag lately (referring
> to the internal review of Srinath's changes) this one looked a lot like
> that.
>
> The only thing I am questioning here is treating that particular
> changeset as a bugfix proper. Yes it is technically a fix in that,
> without this changeset the OTP node is not there and that is
> functionality you want, but it is not preventing the platform from not
> booting for instance, or having an incorrect behavior for an established
> behavior before, right?
>
>> In this case
>> I don't care too much about whether this is fixed in LTS or not. If
>> needed I'll send a request for the commit be ported to stable.
> If this is a true fix, I don't mind taking it as-is and keeping the
> Fixes: tag, keep in mind the following:
>
> I always treat bug fixes with a higher priority than features, and I
> will do my best to queue up fixes (separate branches, all ending in
> /fixes) and submit those at any time in the release cycle so they can
> land in Linus' tree and in the -stable trees as fast as possible.
>
> Don't bypass the maintainer if you can convince me this is a proper fix,
> then I will just move that patch into the appropriate branch, and you
> will get those stable backports automatically.
For now, nobody needs it in the LTS. The OTP driver hasn't actively
been used by applications.
So not critical for backport right now. It's in now so OTP won't be a
problem going forward.
> Thanks for reading me.