From: Markus Elfring <[email protected]>
Date: Tue, 16 Jan 2018 17:30:23 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <[email protected]>
---
drivers/mfd/viperboard.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/mfd/viperboard.c b/drivers/mfd/viperboard.c
index e6b3c70aeb22..e9f61262d583 100644
--- a/drivers/mfd/viperboard.c
+++ b/drivers/mfd/viperboard.c
@@ -59,10 +59,8 @@ static int vprbrd_probe(struct usb_interface *interface,
/* allocate memory for our device state and initialize it */
vb = kzalloc(sizeof(*vb), GFP_KERNEL);
- if (vb == NULL) {
- dev_err(&interface->dev, "Out of memory\n");
+ if (!vb)
return -ENOMEM;
- }
mutex_init(&vb->lock);
--
2.15.1
On Tue, 16 Jan 2018, SF Markus Elfring wrote:
> From: Markus Elfring <[email protected]>
Markus,
Can you please fix-up all of the patches I've NACKed and collect them
up with all the other MFD patches you currently have on the list and
send them as a single set please?
Reviewing them one after another, is taking a lot of time and causing
my a great deal of pain.
I am marking all of your other MFD submissions as 'read and reviewed'
and will not be processing any more until the are all contained in a
single, threaded set.
Thank you!
--
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
On Tue, 23 Jan 2018, Lee Jones wrote:
> On Tue, 16 Jan 2018, SF Markus Elfring wrote:
> > From: Markus Elfring <[email protected]>
>
> Markus,
>
> Can you please fix-up all of the patches I've NACKed and collect them
> up with all the other MFD patches you currently have on the list and
> send them as a single set please?
>
> Reviewing them one after another, is taking a lot of time and causing
> my a great deal of pain.
>
> I am marking all of your other MFD submissions as 'read and reviewed'
> and will not be processing any more until the are all contained in a
> single, threaded set.
>
> Thank you!
Also, could you change the subject lines, so they match that expected
by the subsystem. You can check what that is by doing:
`git log --oneline -- <subsystem>`
In MFD case it's:
"mfd: <driver>: <Succinct headline starting with a capital letter>"
--
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
>> Can you please fix-up all of the patches I've NACKed and collect them
>> up with all the other MFD patches you currently have on the list and
>> send them as a single set please?
>>
>> Reviewing them one after another, is taking a lot of time and causing
>> my a great deal of pain.
There will be review efforts needed as usual. They might be more noticeable
in this case just because I sent some update suggestions also for software
modules from the directory “drivers/mfd”.
>> I am marking all of your other MFD submissions as 'read and reviewed'
>> and will not be processing any more until the are all contained in a
>> single, threaded set.
>>
>> Thank you!
>
> Also, could you change the subject lines, so they match that expected
> by the subsystem.
Do you request a resent for almost all changes from this patch series here?
Regards,
Markus
On Tue, 23 Jan 2018, SF Markus Elfring wrote:
> >> Can you please fix-up all of the patches I've NACKed and collect them
> >> up with all the other MFD patches you currently have on the list and
> >> send them as a single set please?
> >>
> >> Reviewing them one after another, is taking a lot of time and causing
> >> my a great deal of pain.
>
> There will be review efforts needed as usual. They might be more noticeable
> in this case just because I sent some update suggestions also for software
> modules from the directory “drivers/mfd”.
"It's not you, it's me!"
My preferred mailer (Mutt) re-orders replied-to mails by putting them
to the top of my Inbox. At which point I have to re-navigate down to
the next patch to review. This is fine for most submissions, but you
have fired ~30, mostly individual patches at me. Most of which could
realistically be squashed into ~5 patches (if I was feeling mean).
The choice is yours though, either squash them into patches dealing
with the same type of fix-up or merely send all of the un-applied
patches again as a single set, so I can deal with them in a sane
manner.
> >> I am marking all of your other MFD submissions as 'read and reviewed'
> >> and will not be processing any more until the are all contained in a
> >> single, threaded set.
> >>
> >> Thank you!
> >
> > Also, could you change the subject lines, so they match that expected
> > by the subsystem.
>
> Do you request a resent for almost all changes from this patch series here?
I'm not sure I can decipher this.
I'd like you to do the following please:
- Pull all un-applied MFD patches into a single branch based on Mainline
- Add any Reviewed-by/Acked-by's you've received
- Fix the subject lines on all of the patches 's///: /'
- Resubmit as one single threaded patch-set
--
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
> My preferred mailer (Mutt) re-orders replied-to mails by putting them
> to the top of my Inbox. At which point I have to re-navigate down to
> the next patch to review.
How much does this tool influence the amount of update suggestions
which you could handle easily and safely?
> This is fine for most submissions, but you have fired ~30,
> mostly individual patches at me.
This number could be appropriate. I tried to contribute hundreds
of change possibilities for various software components.
> I'd like you to do the following please:
It will take a while until you might get the next chance to take
another look at these subsequent patches.
Regards,
Markus
On Tue, 23 Jan 2018, SF Markus Elfring wrote:
> > My preferred mailer (Mutt) re-orders replied-to mails by putting them
> > to the top of my Inbox. At which point I have to re-navigate down to
> > the next patch to review.
>
> How much does this tool influence the amount of update suggestions
> which you could handle easily and safely?
In the 5 years I've been doing this, this is the first time someone
has submitted in such a way as to cause an issue.
> > This is fine for most submissions, but you have fired ~30,
> > mostly individual patches at me.
>
> This number could be appropriate. I tried to contribute hundreds
> of change possibilities for various software components.
Moving forward, my advice to you would be to collect grouped patches
on a number of topic branches, then send them out in batches, perhaps
every couple of weeks.
Sending ~30 patches individually, spaced over a few hours/days, is
actually not a good system. It is in fact quite inappropriate and a
pain to manage. I for one find many (to be fair, very trivial)
patches scatter-gunned throughout my inbox to be rather inconvenient.
What I should do really is ask you to take all similar (remove error
message, don't use sizeof(struct X), remove '== NULL') changes and
squash them into single patches. However, I realise that you might
want the "upstream creds", so I won't do that -- but not at the
expense of my time/effort.
The two choices are to squash or to create a set.
> > I'd like you to do the following please:
>
> It will take a while until you might get the next chance to take
> another look at these subsequent patches.
I'm not in a hurry.
--
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
> What I should do really is ask you to take all similar (remove error
> message, don't use sizeof(struct X), remove '== NULL') changes and
> squash them into single patches.
I would try such an approach more often if I would get also more
promising indications of corresponding change acceptance besides
other software development “surprises”.
> However, I realise that you might want the "upstream creds",
> so I won't do that
I find this view interesting somehow.
> -- but not at the expense of my time/effort.
>
> The two choices are to squash or to create a set.
This information triggers recurring difficulties around differences
in the preferred patch granularity.
Regards,
Markus