linux-kernel - Re: [PATCH v2 0/7] clk: Declare mux tables as const u32[]

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>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20220312023337.62A25C340E9@smtp.kernel.org>
Date:   Fri, 11 Mar 2022 18:33:35 -0800
From:   Stephen Boyd <sboyd@...nel.org>
To:     Jonathan Neuschäfer <j.neuschaefer@....net>
Cc:     Jonathan Neuschäfer <j.neuschaefer@....net>,
        linux-clk@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/7] clk: Declare mux tables as const u32[]

Quoting Jonathan Neuschäfer (2022-02-26 04:40:19)
> On Fri, Feb 25, 2022 at 05:00:31PM -0800, Stephen Boyd wrote:
> > Quoting Jonathan Neuschäfer (2022-02-05 02:36:06)
> > > I noticed that the 'table' parameter to clk_register_mux_table is never
> > > used for modifying the table elements, and so it can be declared const.
> > > 
> > > In version 2 I'm addressing two warnings in the clk-lpc18xx-cgu driver
> > > that I previously missed.
> > 
> > The format of these patches deeply confused my scripts that use git
> > interpret-trailer. I fixed it now, hopefully it keeps working. In the
> > future, please don't add more triple dash '---' sections to the patch.
> > It looks like those extra sections for the changelog messed everything
> > up. Or there's a new bug in interpret-trailers.  Either way,
> > interpret-trailers was adding tags after the entire patch contents
> > because I think it looks for the last triple dash instead of the first
> > triple dash. Not sure why it's done that way. I resorted to
> > reconstructing the patch after splitting it with mailinfo.
> 
> Hmm, sorry about that.
> 
> I've used this format for a while, because it conveniently lets me
> keep my remarks in a git commit (rather than a patch file), until I use
> git format-patch to generate the final patch file.
> 
> I'm not very familiar with git interpret-trailers, but git 2.34.1
> doesn't seem to get confused on my patches (or I didn't pass the right
> options to cause it to happen).
> 

It's possible it's a git bug. No worries!