Re: [PATCH 0/2] Annotate gpio-configuration with __must_check

[Greg KH]

On Tue, Jan 04, 2011 at 10:29:16PM +0100, Wolfram Sang wrote:
> On Tue, Jan 04, 2011 at 12:27:18PM -0800, Greg KH wrote:
> > 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.

Sure, they could be more harmful, but at least try.  Make the patches
up, submit them to the maintainers, and if they are wrong, they will be
the best to fix it up properly.

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

No, that's still annoying :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/