linux-kernel - Re: [PATCH 1/2] cs5535-gpio: add AMD CS5535/CS5536 GPIO driver support

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: <200907011532.34677.david-b@pacbell.net>
Date:	Wed, 1 Jul 2009 15:32:34 -0700
From:	David Brownell <david-b@...bell.net>
To:	Andres Salomon <dilinger@...labora.co.uk>, Tobias_Mueller@...m.info
Cc:	akpm@...ux-foundation.org, Randy Dunlap <randy.dunlap@...cle.com>,
	deepak@...top.org, Takashi Iwai <tiwai@...e.de>,
	linux-kernel@...r.kernel.org, linux-geode@...ts.infradead.org,
	jordan@...micpenguin.net, cjb@...top.org
Subject: Re: [PATCH 1/2] cs5535-gpio: add AMD CS5535/CS5536 GPIO driver   support

On Thursday 11 June 2009, Andres Salomon wrote:
> 
> > I mentioned this in an ealier mail too. When I request the GPIO from
> > userspace the direction file always contains "in", so I thought
> > this is the standard direction after resetting as I should be in a
> > defined state after requesting. But I didn't found anything
> > about this in GPIO lib documentation, so I would be fine to change
> > this if there is any common default behavoir.
> 
> To be honest, I'd have to play around with it a bit before I
> knew whether it actually breaks anything or not. I'm not sure if
> it would break anything on OLPC, and I don't have any other geode
> machines that do anything interesting w/ GPIOs.
> 
> Maybe David can clear up whether this behavior is correct from the
> userspace GPIO usage standpoint..

Correct-but-annoying ... and maybe worth changing.  The
direction *displayed* may not reflect the actual hardware
until after that GPIO signal is initialized.  Boot firmware
may well have set the direction; Linux shouldn't change it
without explicit instructions to do so.

The issue is that when it first comes up, nobody has tod
Linux that direction ... so instead of defining an "unknown"
state, that code applies a heuristic.  In gpiochip_add():

                for (id = base; id < base + chip->ngpio; id++) {
                        gpio_desc[id].chip = chip;

                        /* REVISIT:  most hardware initializes GPIOs as
                         * inputs (often with pullups enabled) so power
                         * usage is minimized.  Linux code should set the
                         * gpio direction first thing; but until it does,
                         * we may expose the wrong direction in sysfs.
                         */
                        gpio_desc[id].flags = !chip->direction_input
                                ? (1 << FLAG_IS_OUT)
                                : 0;
                }

Now, as far as heuristics go that one seems to cover most
of the common cases.  But like all heuristics, the result
produced may be wrong.

So it would be nice to remove the heuristic.  The best
way would be to add a new method to query gpio direction.
Then that when it's available, instead of the heuristic.

- Dave

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