| Message ID | 20180115183059.GA30039@lenoch (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
>> 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/ > 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 going to “supersede” any more source code adjustments around questionable error messages? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> dev_dbg(dev, > "USB TLL Rev : 0x%x not recognized, assuming %d channels\n", > - ver, tll->nch); > + ver, nch); > break; Does this format string need an other indentation when you touch this statement? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jan 15, 2018 at 08:26:00PM +0100, SF Markus Elfring wrote: > > dev_dbg(dev, > > "USB TLL Rev : 0x%x not recognized, assuming %d channels\n", > > - ver, tll->nch); > > + ver, nch); > > break; > > Does this format string need an other indentation when you touch this statement? Well, lets that the chance and make it shorter as well: default: - tll->nch = OMAP_TLL_CHANNEL_COUNT; - dev_dbg(dev, - "USB TLL Rev : 0x%x not recognized, assuming %d channels\n", - ver, tll->nch); + nch = OMAP_TLL_CHANNEL_COUNT; + dev_dbg(dev, "rev 0x%x not recognized, assuming %d channels\n", + ver, nch); break; Other proposals? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>> * Would you like to add a tag “link”? > > Are you okay with this one? > https://lkml.org/lkml/2018/1/15/411 Yes. > - resend as v2 I was unsure about your patch handling from the previous replies. > Also, patch contains all your changes, so you should be credited > somehow - hence the need for v2 anyway. Thanks. > What about: > [marcus: simplified error unwinding, error message removal] ^ I would prefer my name written as in the other places. Will this software development dialogue evolve in further constructive ways? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c index 44a5d66314c6..f327fe6d3292 100644 --- a/drivers/mfd/omap-usb-tll.c +++ b/drivers/mfd/omap-usb-tll.c @@ -108,9 +108,9 @@ (x) != OMAP_EHCI_PORT_MODE_PHY) struct usbtll_omap { - int nch; /* num. of channels */ - struct clk **ch_clk; - void __iomem *base; + void __iomem *base; + int nch; /* num. of channels */ + struct clk *ch_clk[0]; /* must be the last member */ }; /*-------------------------------------------------------------------------*/ @@ -216,53 +216,50 @@ static int usbtll_omap_probe(struct platform_device *pdev) struct device *dev = &pdev->dev; struct resource *res; struct usbtll_omap *tll; - int ret = 0; - int i, ver; + void __iomem *base; + int i, nch, ver; dev_dbg(dev, "starting TI HSUSB TLL Controller\n"); - tll = devm_kzalloc(dev, sizeof(struct usbtll_omap), GFP_KERNEL); - if (!tll) { - dev_err(dev, "Memory allocation failed\n"); - return -ENOMEM; - } - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - tll->base = devm_ioremap_resource(dev, res); - if (IS_ERR(tll->base)) - return PTR_ERR(tll->base); + base = devm_ioremap_resource(dev, res); + if (IS_ERR(base)) + return PTR_ERR(base); - platform_set_drvdata(pdev, tll); pm_runtime_enable(dev); pm_runtime_get_sync(dev); - ver = usbtll_read(tll->base, OMAP_USBTLL_REVISION); + ver = usbtll_read(base, OMAP_USBTLL_REVISION); switch (ver) { case OMAP_USBTLL_REV1: case OMAP_USBTLL_REV4: - tll->nch = OMAP_TLL_CHANNEL_COUNT; + nch = OMAP_TLL_CHANNEL_COUNT; break; case OMAP_USBTLL_REV2: case OMAP_USBTLL_REV3: - tll->nch = OMAP_REV2_TLL_CHANNEL_COUNT; + nch = OMAP_REV2_TLL_CHANNEL_COUNT; break; default: - tll->nch = OMAP_TLL_CHANNEL_COUNT; + nch = OMAP_TLL_CHANNEL_COUNT; dev_dbg(dev, "USB TLL Rev : 0x%x not recognized, assuming %d channels\n", - ver, tll->nch); + ver, nch); break; } - tll->ch_clk = devm_kzalloc(dev, sizeof(struct clk *) * tll->nch, - GFP_KERNEL); - if (!tll->ch_clk) { - ret = -ENOMEM; - dev_err(dev, "Couldn't allocate memory for channel clocks\n"); - goto err_clk_alloc; + tll = devm_kzalloc(dev, sizeof(*tll) + sizeof(tll->ch_clk[nch]), + GFP_KERNEL); + if (!tll) { + pm_runtime_put_sync(dev); + pm_runtime_disable(dev); + return -ENOMEM; } - for (i = 0; i < tll->nch; i++) { + tll->base = base; + tll->nch = nch; + platform_set_drvdata(pdev, tll); + + for (i = 0; i < nch; i++) { char clkname[] = "usb_tll_hs_usb_chx_clk"; snprintf(clkname, sizeof(clkname), @@ -282,12 +279,6 @@ static int usbtll_omap_probe(struct platform_device *pdev) spin_unlock(&tll_lock); return 0; - -err_clk_alloc: - pm_runtime_put_sync(dev); - pm_runtime_disable(dev); - - return ret; } /**