Re: [1/3] mfd/omap-usb-tll: Delete two error messages for a failed memory allocation in usbtll_omap_probe()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>>> @@ -258,7 +256,6 @@ static int usbtll_omap_probe(struct platform_device *pdev)
>>>>  						GFP_KERNEL);
>>>>  	if (!tll->ch_clk) {
>>>>  		ret = -ENOMEM;
>>>> -		dev_err(dev, "Couldn't allocate memory for channel clocks\n");
>>>
>>> I'd either leave this one, just to know which allocation failed or better use
>>> something like this …
>>
>> Are you aware on the structure for a Linux allocation failure report?
> 
> Just created one (not OMAP and not this driver, but that does not matter now):

Thanks for your example.


> ---[ end trace 3c79eadf2363e939 ]---
> max9867: probe of 1-0018 failed with error -12
> 
> driver was instructed to alloc insane number of bytes using devm_kzalloc in
> max9867_i2c_probe.
> Now, if probe function calls devm_kzalloc two times and one of them fails,
> you cannot easily say which one without looking at assembly listing.

Will this situation change with any other implementation for such backtraces?


> Or did I misunderstand your question?

No. - It seems that we have found a “common wavelength”.

Would it become acceptable to move the mentioned memory allocation into
an additional function implementation so that you could see a difference
from the function call stack dump already?

Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux