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>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ