On 06/04/2018 03:33 PM, Scott Branden wrote:For now, nobody needs it in the LTS.Â The OTP driver hasn't actively been used by applications.
I understand how ones gets to select an appropriate Fixes: tag, what I
On 18-06-04 02:33 PM, Florian Fainelli wrote:
On 06/04/2018 02:30 PM, Scott Branden wrote:The relationship is the fixes tag points was selected to the last tag
Hi Florian,By that token, any peripheral that is being added at some point in the
On 18-06-04 02:24 PM, Florian Fainelli wrote:
On 05/23/2018 01:17 PM, Scott Branden wrote:It fixes the issue that OTP is not active as it is missing the device
Add otp device node for Stingray SOC.Applied to devicetree-arm64/next with s/otp/OTP/ and removing the Fixes
Fixes: 2fa9e9e29ea2 ("arm64: dts: Add GPIO DT nodes for Stingray SOC")
Signed-off-by: Scott Branden <scott.branden@xxxxxxxxxxxx>
line since that is not a bug fix AFAICT.
lifetime of this DTS would qualify as a bugfix when it is in fact
I could not see the relationship between the commit being provided in
the "Fixes:" tag and OTP, am I missing something?
when the commit applies directly against (and is far enough back that it
covers any possible LTS kernels that would have needed it).
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
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 caseIf this is a true fix, I don't mind taking it as-is and keeping the
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.
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.