NM10 gpio driver implementation

See the driver file header for implementation details.

Tested on an ST8 as follows
^^^^^^^^^^^^^^^^^^^^^^^^^^^

localhost ~ # cd /tmp
localhost tmp # scp <user@host>:<path>/nm10_gpio.ko .
localhost tmp # ls /sys/class/gpio/
export  unexport
localhost tmp # insmod nm10_gpio.ko 
localhost tmp # ls /sys/class/gpio/
export  gpiochip192  unexport
localhost tmp # i=0; while [ "$i" != "64" ]
> do
> gpio=$(expr $i \+ 192)
>  i=$(expr $i \+ 1)
>  echo $gpio > /sys/class/gpio/export
> done
localhost tmp # ls /sys/class/gpio/
export   gpio195  gpio199  gpio203  
gpio207  gpio211  gpio215  gpio219 
gpio223  gpio227  gpio231  gpio235 
gpio239  gpio243  gpio247  gpio251  
gpio255  gpio192  gpio196  gpio200 
gpio204  gpio208  gpio212  gpio216
gpio220  gpio224  gpio228  gpio232
gpio236  gpio240  gpio244  gpio248
gpio252  gpiochip192 gpio193  gpio197
gpio201  gpio205  gpio209  gpio213
gpio217  gpio221  gpio225  gpio229 
gpio233  gpio237  gpio241  gpio245
gpio249  gpio253  unexport gpio194
gpio198  gpio202  gpio206  gpio210
gpio214  gpio218  gpio222  gpio226
gpio230  gpio234  gpio238  gpio242
gpio246  gpio250  gpio254
localhost tmp # 
localhost tmp # gpiodump() {
> i=0; while [ "$i" != "64" ]
> do
>  gpio=$(expr $i \+ 192)
>  i=$(expr $i \+ 1)
>  cat /sys/class/gpio/gpio$gpio/value
> done | awk \
> '{ if (i == 8) {print ""; i = 0;} \
> printf " %s", $1; i = i + 1} \
> END { print "" }'
> }
localhost tmp # gpiodump
 1 1 0 1 0 1 1 0
 1 1 1 0 1 1 1 1
 0 0 0 0 0 0 1 0
 0 0 0 0 0 0 0 0
 0 1 1 0 1 0 1 1
 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0
##### Now, press and hold the recovery button
localhost tmp # gpiodump
 1 1 0 1 0 1 0 0
 1 1 1 0 1 1 1 1
 0 0 0 0 0 0 1 0
 0 0 0 0 0 0 0 0
 0 1 1 0 1 0 1 1
 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0
localhost tmp # 
# observe GPIO bit6 changed state from 1 to 0
localhost tmp # i=0; while [ "$i" != "64" ]
> do
> gpio=$(expr $i \+ 192)
>  i=$(expr $i \+ 1)
>  echo $gpio > /sys/class/gpio/unexport
> done
localhost tmp # ls /sys/class/gpio/
export  gpiochip192  unexport
localhost tmp # rmmod nm10_gpio.ko 
localhost tmp # ls /sys/class/gpio/
export  unexport
localhost tmp # dmesg | tail -3
[ 5476.917362] nm10_gpio version 0.04 built on May 26 2010 at 14:37:58
[ 5476.917390] gpiochip_find_base: found new base at 192
[ 5995.995601] nm10_gpio base 192 removed
localhost tmp #

[Randall Spangler, 2010-05-26 23:43:16]

http://codereview.chromium.org/2231003/diff/2001/3004
File drivers/gpio/nm10_gpio.c (right):

http://codereview.chromium.org/2231003/diff/2001/3004#newcode2
drivers/gpio/nm10_gpio.c:2: * Copyright (c) 2010, Google Inc.
The Chromium OS Authors

http://codereview.chromium.org/2231003/diff/2001/3004#newcode27
drivers/gpio/nm10_gpio.c:27: * strapped and/or configured by BIOS for is used by
the driver.
We should have the ability to change the bits' directions, so that we can ensure
that GPIOs we think are inputs are actually configured as inputs.  Otherwise, a
malicious program could set them as outputs, and we wouldn't be able to read the
true input value.

See Documentation/gpio.txt:

 151 It's generally a bad
 152 idea to rely on boot firmware to have set the direction correctly, since
 153 it probably wasn't validated to do more than boot Linux.  (Similarly,
 154 that board setup code probably needs to multiplex that pin as a GPIO,
 155 and configure pullups/pulldowns appropriately.)

http://codereview.chromium.org/2231003/diff/2001/3004#newcode298
drivers/gpio/nm10_gpio.c:298: MODULE_AUTHOR("Google Inc.");
"The Chromium OS Authors"?

[vb, 2010-05-27 00:10:29]

Randall, thank you for a quick review, please see my replies below.

http://codereview.chromium.org/2231003/diff/2001/3004
File drivers/gpio/nm10_gpio.c (right):

http://codereview.chromium.org/2231003/diff/2001/3004#newcode2
drivers/gpio/nm10_gpio.c:2: * Copyright (c) 2010, Google Inc.
On 2010/05/26 23:43:16, Randall Spangler wrote:
> The Chromium OS Authors

Done.

http://codereview.chromium.org/2231003/diff/2001/3004#newcode27
drivers/gpio/nm10_gpio.c:27: * strapped and/or configured by BIOS for is used by
the driver.
On 2010/05/26 23:43:16, Randall Spangler wrote:
> We should have the ability to change the bits' directions, so that we can
ensure
> that GPIOs we think are inputs are actually configured as inputs.  Otherwise,
a
> malicious program could set them as outputs, and we wouldn't be able to read
the
> true input value.
> 
> See Documentation/gpio.txt:
> 
>  151 It's generally a bad
>  152 idea to rely on boot firmware to have set the direction correctly, since
>  153 it probably wasn't validated to do more than boot Linux.  (Similarly,
>  154 that board setup code probably needs to multiplex that pin as a GPIO,
>  155 and configure pullups/pulldowns appropriately.)
> 

Well, frankly I have hard time subscribing to this: who knows better the actual
hardware platform than the boot loader?

If linux user is allowed to change GPIO assignments/directions, a
malicious/ignorant user can cause permanent damage turning inputs into outputs
and driving them to collide with the actual drivers, or render a system unusable
turning into a GPIO a pin assigned to some other function.

In any case this ability to change pin direction can be added easily by
introducing another callback function and is not essential for our testing at
this time.

May I suggest that I check this is as is and we add the ability to change pin
functions if/when required?

http://codereview.chromium.org/2231003/diff/2001/3004#newcode298
drivers/gpio/nm10_gpio.c:298: MODULE_AUTHOR("Google Inc.");
On 2010/05/26 23:43:16, Randall Spangler wrote:
> "The Chromium OS Authors"?

Done.

[Randall Spangler, 2010-05-27 00:46:55]

LGTM

(This can resolve the current NM10 GPIO bug; reference the new bug below in the
resolution, so we remember to come back to the set-direction issue)

http://codereview.chromium.org/2231003/diff/2001/3004
File drivers/gpio/nm10_gpio.c (right):

http://codereview.chromium.org/2231003/diff/2001/3004#newcode27
drivers/gpio/nm10_gpio.c:27: * strapped and/or configured by BIOS for is used by
the driver.
On 2010/05/27 00:10:30, vb wrote:
> On 2010/05/26 23:43:16, Randall Spangler wrote:
> > We should have the ability to change the bits' directions, so that we can
> ensure
> > that GPIOs we think are inputs are actually configured as inputs. 
Otherwise,
> a
> > malicious program could set them as outputs, and we wouldn't be able to read
> the
> > true input value.
> > 
> > See Documentation/gpio.txt:
> > 
> >  151 It's generally a bad
> >  152 idea to rely on boot firmware to have set the direction correctly,
since
> >  153 it probably wasn't validated to do more than boot Linux.  (Similarly,
> >  154 that board setup code probably needs to multiplex that pin as a GPIO,
> >  155 and configure pullups/pulldowns appropriately.)
> > 
> 
> Well, frankly I have hard time subscribing to this: who knows better the
actual
> hardware platform than the boot loader?
> 
> If linux user is allowed to change GPIO assignments/directions, a
> malicious/ignorant user can cause permanent damage turning inputs into outputs
> and driving them to collide with the actual drivers, or render a system
unusable
> turning into a GPIO a pin assigned to some other function.
> 
> In any case this ability to change pin direction can be added easily by
> introducing another callback function and is not essential for our testing at
> this time.
> 
> May I suggest that I check this is as is and we add the ability to change pin
> functions if/when required?
> 

Ok.  Please open a new Pri-2 bug to add set-direction functionality.  We'll need
that for fully supporting the debug port, which has bidirectional GPIOs with no
predefined function (so the BIOS/bootloader won't know what they're hooked to).