linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ladislav Michl <ladis@linux-mips.org>
To: SF Markus Elfring <elfring@users.sourceforge.net>
Cc: linux-omap@vger.kernel.org, Lee Jones <lee.jones@linaro.org>,
	Tony Lindgren <tony@atomide.com>, Roger Quadros <rogerq@ti.com>,
	LKML <linux-kernel@vger.kernel.org>,
	kernel-janitors@vger.kernel.org
Subject: Re: mfd/omap-usb-tll: Allocate driver data at once in usbtll_omap_probe()
Date: Mon, 15 Jan 2018 20:23:03 +0100	[thread overview]
Message-ID: <20180115192303.GA31762@lenoch> (raw)
In-Reply-To: <8144f711-b4fd-730c-4e9f-780c42d5e68f@users.sourceforge.net>

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@users.sourceforge.net>

Feel free to propose anything else.

Best regards,
	ladis

  reply	other threads:[~2018-01-15 19:23 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-15 13:14 [PATCH 0/3] mfd/omap-usb-tll: Adjustments for usbtll_omap_probe() SF Markus Elfring
2018-01-15 13:15 ` [PATCH 1/3] mfd/omap-usb-tll: Delete two error messages for a failed memory allocation in usbtll_omap_probe() SF Markus Elfring
2018-01-15 13:41   ` Ladislav Michl
2018-01-15 15:34     ` Roger Quadros
2018-01-15 15:38     ` SF Markus Elfring
2018-01-15 16:05       ` Ladislav Michl
2018-01-15 16:21         ` [1/3] " SF Markus Elfring
2018-01-15 16:35           ` Ladislav Michl
2018-01-15 17:06             ` SF Markus Elfring
2018-01-15 17:41               ` Ladislav Michl
2018-01-15 18:12                 ` SF Markus Elfring
2018-01-15 18:30                   ` Ladislav Michl
2018-01-15 19:04                     ` mfd/omap-usb-tll: Allocate driver data at once " SF Markus Elfring
2018-01-15 19:23                       ` Ladislav Michl [this message]
2018-01-15 19:40                         ` SF Markus Elfring
2018-01-15 19:26                     ` SF Markus Elfring
2018-01-15 19:33                       ` Ladislav Michl
2018-01-15 13:16 ` [PATCH 2/3] mfd/omap-usb-tll: Improve a size determination " SF Markus Elfring
2018-01-22 15:50   ` Lee Jones
2018-01-15 13:17 ` [PATCH 3/3] mfd/omap-usb-tll: Return an error code only as a constant " SF Markus Elfring
2018-01-22 15:50   ` Lee Jones
2018-01-23 13:04     ` Lee Jones
2018-01-23 14:43       ` [3/3] " SF Markus Elfring
2018-01-23 15:04         ` Lee Jones
2018-01-23 17:13           ` Ladislav Michl
2018-01-24 15:16             ` Lee Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180115192303.GA31762@lenoch \
    --to=ladis@linux-mips.org \
    --cc=elfring@users.sourceforge.net \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=rogerq@ti.com \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).