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.
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.
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
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
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
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
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
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) =
> 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
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
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
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.
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,
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
14 matches
Mail list logo