Re: [patch 2.6.20-rc1 1/6] GPIO core

2007-01-02 Thread Pavel Machek
Hi! > > > Should it instead say that's an (obviously unchecked) error? > > > > Saying it is an error would be okay by me. (Or "Behaviour of these calls for > > GPIOs that can't be safely accessed without sleeping is undefined."). > > See the appended doc patch ... better? Yes, thanks.

Re: [patch 2.6.20-rc1 1/6] GPIO core

2007-01-02 Thread Pavel Machek
Hi! Should it instead say that's an (obviously unchecked) error? Saying it is an error would be okay by me. (Or Behaviour of these calls for GPIOs that can't be safely accessed without sleeping is undefined.). See the appended doc patch ... better? Yes, thanks.

Re: [patch 2.6.20-rc1 1/6] GPIO core

2007-01-01 Thread David Brownell
On Monday 01 January 2007 12:55 pm, Pavel Machek wrote: > > Think of it as "cookies represented by integers" if you like. > > typedef int gpio_t would hurt, and would serve as a useful > documentation hint. Yes, I agree that such needless obfuscation hurts. ;) Plus, such a typedef would

Re: [patch 2.6.20-rc1 1/6] GPIO core

2007-01-01 Thread Pavel Machek
Hi! > > Well. when you see (something) = gpio_number + 5 ... you most likely > > have an error. > > One could surely apply that argument to hundreds of places throughout > the kernel ... that doesn't make it a good one. One of the downfalls > of many "object oriented programming" efforts was

Re: [patch 2.6.20-rc1 1/6] GPIO core

2007-01-01 Thread Pavel Machek
Hi! Well. when you see (something) = gpio_number + 5 ... you most likely have an error. One could surely apply that argument to hundreds of places throughout the kernel ... that doesn't make it a good one. One of the downfalls of many object oriented programming efforts was this same

Re: [patch 2.6.20-rc1 1/6] GPIO core

2007-01-01 Thread David Brownell
On Monday 01 January 2007 12:55 pm, Pavel Machek wrote: Think of it as cookies represented by integers if you like. typedef int gpio_t would hurt, and would serve as a useful documentation hint. Yes, I agree that such needless obfuscation hurts. ;) Plus, such a typedef would disagree

Re: [patch 2.6.20-rc1 1/6] GPIO core

2006-12-29 Thread David Brownell
On Thursday 28 December 2006 4:27 pm, Pavel Machek wrote: > > > > > +GPIOs are identified by unsigned integers in the range 0..MAX_INT > > > > > > Perhaps these should not be integers, then? > > > > Thing is, the platforms **DO** identify them as integers. > > ... > > Well. when you see

Re: [patch 2.6.20-rc1 1/6] GPIO core

2006-12-29 Thread David Brownell
On Thursday 28 December 2006 4:27 pm, Pavel Machek wrote: +GPIOs are identified by unsigned integers in the range 0..MAX_INT Perhaps these should not be integers, then? Thing is, the platforms **DO** identify them as integers. ... Well. when you see (something) =

Re: [patch 2.6.20-rc1 1/6] GPIO core

2006-12-28 Thread Pavel Machek
> Good afternoon. :) Good after-midnight :-). > > > +Identifying GPIOs > > > +- > > > +GPIOs are identified by unsigned integers in the range 0..MAX_INT. That > > > +reserves "negative" numbers for other purposes like marking signals as > > > +"not available on this board", or

Re: [patch 2.6.20-rc1 1/6] GPIO core

2006-12-28 Thread David Brownell
On Wednesday 27 December 2006 9:49 am, Pavel Machek wrote: > Hi! Good afternoon. :) > > +Identifying GPIOs > > +- > > +GPIOs are identified by unsigned integers in the range 0..MAX_INT. That > > +reserves "negative" numbers for other purposes like marking signals as > > +"not

Re: [patch 2.6.20-rc1 1/6] GPIO core

2006-12-28 Thread Pavel Machek
Hi! > +Identifying GPIOs > +- > +GPIOs are identified by unsigned integers in the range 0..MAX_INT. That > +reserves "negative" numbers for other purposes like marking signals as > +"not available on this board", or indicating faults. > + > +Platforms define how they use those

Re: [patch 2.6.20-rc1 1/6] GPIO core

2006-12-28 Thread Pavel Machek
Good afternoon. :) Good after-midnight :-). +Identifying GPIOs +- +GPIOs are identified by unsigned integers in the range 0..MAX_INT. That +reserves negative numbers for other purposes like marking signals as +not available on this board, or indicating faults.

Re: [patch 2.6.20-rc1 1/6] GPIO core

2006-12-28 Thread Pavel Machek
Hi! +Identifying GPIOs +- +GPIOs are identified by unsigned integers in the range 0..MAX_INT. That +reserves negative numbers for other purposes like marking signals as +not available on this board, or indicating faults. + +Platforms define how they use those integers,

Re: [patch 2.6.20-rc1 1/6] GPIO core

2006-12-28 Thread David Brownell
On Wednesday 27 December 2006 9:49 am, Pavel Machek wrote: Hi! Good afternoon. :) +Identifying GPIOs +- +GPIOs are identified by unsigned integers in the range 0..MAX_INT. That +reserves negative numbers for other purposes like marking signals as +not available on

[patch 2.6.20-rc1 1/6] GPIO core

2006-12-20 Thread David Brownell
This defines a simple and minimalist programming interface for GPIO APIs: - Documentation/gpio.txt ... describes things (read it) - include/asm-arm/gpio.h ... defines the ARM hook, which just punts to for any implementation - include/asm-generic/gpio.h ... implement "can sleep"

[patch 2.6.20-rc1 1/6] GPIO core

2006-12-20 Thread David Brownell
This defines a simple and minimalist programming interface for GPIO APIs: - Documentation/gpio.txt ... describes things (read it) - include/asm-arm/gpio.h ... defines the ARM hook, which just punts to asm/arch/gpio.h for any implementation - include/asm-generic/gpio.h ... implement