On Tue, Jan 04, 2011 at 12:27:18PM -0800, Greg KH wrote:
quoted text
> On Tue, Jan 04, 2011 at 05:51:06PM +0100, Wolfram Sang wrote:
> > Here is a small series generating a lot of warnings, especially in board
> > bringup-files. Still, I think it is worthwhile to be strict about checking
> > return values of gpio-configuration-functions. My suggestion to keep the noise
> > a bit lower is to put it into linux-next for one cycle and then merge it for
> > 2.6.39? That should give people some time to fix the issues in time. Looking
> > forward to comments.
> 
> It's ok to add this type of thing, but please, go through and fix the
> warnings at the same time.  Otherwise it's a bit rude to force others to
> fix their code for something that you did.

Yeah, I understand. I was a "victim" of the patch causing all those "key not in
.data" messages back then. So, I actually did start a coccinelle-script fixing
the issues. I examined one sub-directory using a CPU/SoC I know relatively
well. I had to learn that even then, it is pretty hard to determine what
exactly to do if gpio_request() fails. For example, an unavailable GPIO being
the write-protect-pin for SD-cards might be simply ignored, maybe a warning
printed and the card will be rw by default. Another GPIO might be a chip-select
of a device I have never heard of before. It might be crucial and board_init
should fail if it cannot be requested. Or not. Things get worse for
architectures I never used before. This is why I think it is really better to
let people do the fixups who have/understand the hardware in question.
Otherwise the fixups could indeed be more harmful than helpful.

If this is still too rude for your taste, then what about a mechanism similar
to DEBUG_SECTION_MISMATCH?

Kind regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |