linux-kernel - Re: mfd/omap-usb-tll: Allocate driver data at once in usbtll_omap

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

Message-ID: <20180115192303.GA31762@lenoch>
Date:   Mon, 15 Jan 2018 20:23:03 +0100
From:   Ladislav Michl <ladis@...ux-mips.org>
To:     SF Markus Elfring <elfring@...rs.sourceforge.net>
Cc:     linux-omap@...r.kernel.org, Lee Jones <lee.jones@...aro.org>,
        Tony Lindgren <tony@...mide.com>,
        Roger Quadros <rogerq@...com>,
        LKML <linux-kernel@...r.kernel.org>,
        kernel-janitors@...r.kernel.org
Subject: Re: mfd/omap-usb-tll: Allocate driver data at once in
 usbtll_omap_probe()

On Mon, Jan 15, 2018 at 08:04:03PM +0100, SF Markus Elfring wrote:
> >> So I hope that your solution approach will be also fine.
> >> Will it supersede my proposal?
> > 
> > Who knows, perhaps it would be the best if you could judge yourself...
> 
> I am also curious on how other contributors will respond to
> your following update suggestion.
> 
> 
> > 8<--------
> > 
> > Subject: [PATCH] mfd/omap-usb-tll: Allocate driver data at once
> 
> Would it have been clearer to use this information as the subject
> for this reply already?
> 
> Are you fine with that this change approach was recorded in
> a possibly questionable format?
> https://patchwork.kernel.org/patch/10165193/

Sure. It does not seem anyone involved cares about patchwork.

> > Allocating memory to store clk array together with driver
> > data simplifies error unwinding and allows deleting memory
> > allocation failure message as there is now only single point
> > where allocation could fail.
> 
> * Will it matter to mention the previous software situation a bit
>   in such a commit description?
> 
> * Would you like to add a tag “link”?

Are you okay with this one?
https://lkml.org/lkml/2018/1/15/411

> * Are you going to “supersede” any more source code adjustments
>   around questionable error messages?

I'm going to handle it usual way:
- wait for feedback and modify accordingly
- collect tags
- resend as v2

Also, patch contains all your changes, so you should be credited
somehow - hence the need for v2 anyway.

What about:
[marcus: simplified error unwinding, error message removal]
Signed-off-by: Markus Elfring <elfring@...rs.sourceforge.net>

Feel free to propose anything else.

Best regards,
	ladis