[PATCH EDACv16 1/2] edac: Change internal representation to work with layers
Mauro Carvalho Chehab
mchehab at redhat.com
Mon Apr 30 00:25:50 EST 2012
Em 28-04-2012 05:52, Borislav Petkov escreveu:
> On Fri, Apr 27, 2012 at 01:07:38PM -0300, Mauro Carvalho Chehab wrote:
>> Yes. This is a common issue at the EDAC core: on several places, it calls the
>> edac debug macros (DEBUGF0...DEBUGF4) passing a __func__ as an argument, while
>> the debug macros already handles that. I suspect that, in the past, the __func__
>> were not at the macros, but some patch added it there, and forgot to fix the
>> occurrences of its call.
>
> The patch that added it is d357cbb445208 and you reviewed it.
And you wrote the patch that caused it.
>
>> This is something that needs to be reviewed at the entire EDAC core (and likely
>> at the drivers).
>
> Looks like a job for a newbie to get her/his feet wet with kernel work.
>
>> I opted to not touch on this at the existing debug logic, as I think that the
>> better is to address all those issues on one separate patch, after fixing the
>> EDAC core bugs.
>
> No,
>
> you simply need to remove the __func__ argument in your newly added debug call:
>
> debugf2("%s: %d: dimm%zd (%d:%d:%d): row %d, chan %d\n", __func__,
> i, (dimm - mci->dimms),
> pos[0], pos[1], pos[2], row, chn);
>
> And while you're at it, remove the rest of the __func__ arguments from
> your newly added debugfX calls.
A single patch fixing this everywhere at drivers/edac is better and clearer than adding
an unrelated fix on this patch. This is already complex enough to add more unrelated
things there.
Also, a simple perl/coccinelle script can replace all such __func__ occurrences
on one shot.
Regards,
Mauro
More information about the Linuxppc-dev
mailing list