OMAP2+ hwmod fixes
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 3 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 3 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/3] OMAP2+ hwmod fixes
Hi Paul,
Quoted 22 lines · Rajendra
Hi Paul,
Quoted 17 lines
From: Paul Walmsley [mailto:paul at pwsan.com]
Sent: Wednesday, February 23, 2011 12:40 AMHi Rajendra
Quoted 9 lines · Rajendra Nayak
The original behavior of the iterators, to terminate upon encountering an error, seems fine to me. The only problem I faced was that they fail silently and go undetected, unless their user catches the return value and WARN's, which I found was not the case with most users, mainly those of
omap_hwmod_for_each_by_class.
I was thinking of keeping the behaviour of these iterators same for now and add WARN's in these iterators itself upon an error, so its seen even if the user fails to catch it.Quoted 3 lines
What's your opinion on adding the
pr_err()orWARN()into the code that the iterator calls for each hwmod? That code should know why something fails, so it should be able to provide a more detailed error message.
Quoted 6 lines
Of
Quoted 1 line
course, it is not as general a solution...
I agree, if the callback functions are written with proper errors or WARN's, they are the right place where most of the details' exist. So maybe we don't need these in the iterator's after all.
So to conclude, I will drop the #3 and just push #1 and #2.
#1 is fine with addition of the WARN.
#2 does return an error but does not print anything, but since each call (_init_main_clk, _init_interface_clks, _init_opt_clks) does report some pr_warn in case of error, this is fine.
Regards,
Benoit