linux-kernel - Re: [PATCH v2 2/2] pinctrl: qcom: sc7180: Add new qup functions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAD=FV=VHaFYsqt+3-jgJo8JWKxfRvgR_D-qP5e=TGq8h_f43EA@mail.gmail.com>
Date:   Wed, 11 Dec 2019 10:04:01 -0800
From:   Doug Anderson <dianders@...omium.org>
To:     Rajendra Nayak <rnayak@...eaurora.org>
Cc:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        LinusW <linus.walleij@...aro.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Stephen Boyd <swboyd@...omium.org>
Subject: Re: [PATCH v2 2/2] pinctrl: qcom: sc7180: Add new qup functions

Hi,

On Tue, Dec 10, 2019 at 11:07 PM Rajendra Nayak <rnayak@...eaurora.org> wrote:
>
> On 12/11/2019 12:08 PM, Bjorn Andersson wrote:
> > On Tue 10 Dec 21:24 PST 2019, Rajendra Nayak wrote:
> >
> >> on sc7180 we have cases where multiple functions from the same
> >> qup instance share the same pin. This is true for qup02/04/11 and qup13.
> >> Add new function names to distinguish which qup function to use.
> >>
> >> The device tree files for this platform haven't landed in mainline yet,
> >> so there aren't any users upstream who should break with this change
> >> in function names, however, anyone using the devicetree files that were
> >> posted on the lists and using these specific function names will need
> >> to update their changes.
> >
> > I don't think this paragraph adds value to the git log, but the patch
> > looks good.
>
> Right, I should have mentioned that bit after the --- so its not in the
> changelog :/
>
> Linus, do you want me to resend with that paragraph moved below --- ?

Personally I find this type of info useful even in the changelog
itself.  Without it someone inspecting this change would wonder why it
was OK to change the device tree bindings without an attempt at
backward compatibility.  I suppose they could always go back to the
mailing list and track down the history, but why is it bad to be in
the changelog?

In any case, if everyone hates it in the change log I won't stand in
the way, so regardless of which way folks go on that:

Reviewed-by: Douglas Anderson <dianders@...omium.org>