| Message ID | aa138aa9-d8c9-c6e3-7071-9fc642e7b248@users.sourceforge.net (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Sat, 2017-12-16 at 19:43 +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfring@users.sourceforge.net> > Date: Sat, 16 Dec 2017 19:32:02 +0100 > > Omit an extra message for a memory allocation failure in these functions. Because??? Fix your commit message. Say _WHY_ should this be applied. Otherwise, just stop sending these patches.
>> Omit an extra message for a memory allocation failure in these functions. > > Because??? > > Fix your commit message. > > Say _WHY_ should this be applied. I am still waiting for possibilities to improve also the corresponding reference documentation somehow as you know it already. Regards, Markus
On Sat, 16 Dec 2017, SF Markus Elfring wrote: > >> Omit an extra message for a memory allocation failure in these functions. > > > > Because??? > > > > Fix your commit message. > > > > Say _WHY_ should this be applied. > > I am still waiting for possibilities to improve also the corresponding > reference documentation somehow as you know it already. If you require someone else to update the documentation to be able to explain why the patch is useful, then it would seem that you do not know why the patch is useful, and thus should not submit it. julia > > Regards, > Markus > -- > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
On Sat, 2017-12-16 at 21:30 +0100, SF Markus Elfring wrote: > > > Omit an extra message for a memory allocation failure in these functions. > > > > Because??? > > > > Fix your commit message. > > > > Say _WHY_ should this be applied. > > I am still waiting for possibilities to improve also the corresponding > reference documentation somehow as you know it already. Don't submit any more patches until you do have this resolved.
>> I am still waiting for possibilities to improve also the corresponding >> reference documentation somehow as you know it already. > > If you require someone else to update the documentation to be able to > explain why the patch is useful, My approach is to refer to the Linux allocation failure report. > then it would seem that you do not know why the patch is useful, > and thus should not submit it. We tried to clarify other explanation approaches a few times. But it seems that we are stuck with specific software aspects. How would you like to see remaining open issues to be resolved there anyhow? Regards, Markus
>> I am still waiting for possibilities to improve also the corresponding >> reference documentation somehow as you know it already. > > Don't submit any more patches until you do have this resolved. I imagine that some contributors will need to work better together for this task. It seems that I did not get any more constructive answers for my questions in this direction so far. Regards, Markus
Hi, On Sat, Dec 16, 2017 at 09:47:34PM +0100, SF Markus Elfring wrote: > >> I am still waiting for possibilities to improve also the corresponding > >> reference documentation somehow as you know it already. > > > > If you require someone else to update the documentation to be able to > > explain why the patch is useful, > > My approach is to refer to the Linux allocation failure report. > > > > then it would seem that you do not know why the patch is useful, > > and thus should not submit it. > > We tried to clarify other explanation approaches a few times. > > But it seems that we are stuck with specific software aspects. > How would you like to see remaining open issues to be resolved > there anyhow? FYI: I will drop this and (without any further notice) all future patches from you, that do no follow the documented process in Documentation/process/. -- Sebastian
>> But it seems that we are stuck with specific software aspects. >> How would you like to see remaining open issues to be resolved >> there anyhow? > > FYI: I will drop this and (without any further notice) all future > patches from you, that do no follow the documented process in > Documentation/process/. Which details do you find that do not fit to this development specification so far? Are there any update suggestions left over which you could eventually accept? Regards, Markus
diff --git a/drivers/power/supply/tps65090-charger.c b/drivers/power/supply/tps65090-charger.c index 1b4b5e09538e..43c44d2eaeca 100644 --- a/drivers/power/supply/tps65090-charger.c +++ b/drivers/power/supply/tps65090-charger.c @@ -202,10 +202,8 @@ static struct tps65090_platform_data * unsigned int prop; pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL); - if (!pdata) { - dev_err(&pdev->dev, "Memory alloc for tps65090_pdata failed\n"); + if (!pdata) return NULL; - } prop = of_property_read_bool(np, "ti,enable-low-current-chrg"); pdata->enable_low_current_chrg = prop; @@ -257,10 +255,8 @@ static int tps65090_charger_probe(struct platform_device *pdev) } cdata = devm_kzalloc(&pdev->dev, sizeof(*cdata), GFP_KERNEL); - if (!cdata) { - dev_err(&pdev->dev, "failed to allocate memory status\n"); + if (!cdata) return -ENOMEM; - } platform_set_drvdata(pdev, cdata);