linux-kernel - Re: [PATCH 0/2] Annotate gpio-configuration with __must

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110104212916.GA14436@pengutronix.de>
Date:	Tue, 4 Jan 2011 22:29:16 +0100
From:	Wolfram Sang <w.sang@...gutronix.de>
To:	Greg KH <gregkh@...e.de>
Cc:	linux-kernel@...r.kernel.org,
	David Brownell <dbrownell@...rs.sourceforge.net>
Subject: Re: [PATCH 0/2] Annotate gpio-configuration with __must_check

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.

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/  |

Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)