> Focusing on checkpatch errors is a bit deceptive. It is > perfectly possible to be "checkpatch clean" yet the code > has lots of issues left. For example checkpatch cannot tell > that CSL_Strlen() can be replaced with strlen() from kernel.
-- CSL module is worked on. We will send this patch this week. Thank you, Best regards, Hari > -----Original Message----- > From: Riku Voipio [mailto:[EMAIL PROTECTED] > Sent: Monday, August 18, 2008 4:13 AM > To: Woodruff, Richard > Cc: Felipe Contreras; Tony Lindgren; Hiroshi DOYU; linux- > [EMAIL PROTECTED]; [EMAIL PROTECTED]; Kanigeri, Hari; Ramirez Luna, > Omar; Gupta, Ramesh; [EMAIL PROTECTED]; Pasam, Vijay > Subject: Re: [RFC] Port TI DSP BRIDGE for a new dedicated branch in linux- > omap > > On Fri, Aug 15, 2008 at 03:16:29PM -0500, Woodruff, Richard wrote: > > Checkpatch.pl is just a guide. Completely changing code for the tool > isn't probably a good idea. It might even get you severally flamed on LKML > :) The recent threads are informative (ok to read, bad to be in). > > > Incidentally, when I asked the person working these changes, they had > reported 0 functional errors had been fixed by the checkpatch changes. A > lot of the noise was typedef reduction. > > I don't think completly fair complaint. > > checkpatch.pl is only meant to check that patches comply to the kernel > Coding style. For a huge project such as Linux kernel, all code must > be written in uniform style. DSP bridge has probably been written > following TI's internal codingstyle documents, and as a first step > it needs to be converted to follow the Linux codingstyle. > > checkpatch not a static analysing tool, which would be > neccessary for uncovering functional errors. For that we have sparse, > and mainline kernel gets regularry checked with the coverity scanner. > > Focusing on checkpatch errors is a bit deceptive. It is > perfectly possible to be "checkpatch clean" yet the code > has lots of issues left. For example checkpatch cannot tell > that CSL_Strlen() can be replaced with strlen() from kernel. > > > > -- > "rm -rf" only sounds scary if you don't have backups -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
