On Tuesday 12 February 2013, Paul Mundt wrote:
> > While I do get the point... I chatted with Grant about it and
> > I want to talk to some toolchain people about this to see if
> > pointers containing potential error codes can somehow be
> > "flagged" by the compiler so we can enforce error
On Tue, Feb 12, 2013 at 01:29:10PM +0100, Linus Walleij wrote:
> On Mon, Feb 11, 2013 at 6:39 PM, Stephen Warren wrote:
> > On 02/11/2013 07:09 AM, Linus Walleij wrote:
>
> >> However if you take this all the way to the descriptor API
> >> it will make the consumer (driver) API for GPIO
On Mon, Feb 11, 2013 at 6:39 PM, Stephen Warren wrote:
> On 02/11/2013 07:09 AM, Linus Walleij wrote:
>> However if you take this all the way to the descriptor API
>> it will make the consumer (driver) API for GPIO descriptors deviate
>> from what is today used for clocks, regulators and pins.
On Mon, Feb 11, 2013 at 6:39 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/11/2013 07:09 AM, Linus Walleij wrote:
However if you take this all the way to the descriptor API
it will make the consumer (driver) API for GPIO descriptors deviate
from what is today used for clocks,
On Tue, Feb 12, 2013 at 01:29:10PM +0100, Linus Walleij wrote:
On Mon, Feb 11, 2013 at 6:39 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/11/2013 07:09 AM, Linus Walleij wrote:
However if you take this all the way to the descriptor API
it will make the consumer (driver) API for
On Tuesday 12 February 2013, Paul Mundt wrote:
While I do get the point... I chatted with Grant about it and
I want to talk to some toolchain people about this to see if
pointers containing potential error codes can somehow be
flagged by the compiler so we can enforce error checking on
On 02/11/2013 07:09 AM, Linus Walleij wrote:
> On Sat, Feb 9, 2013 at 10:17 AM, Grant Likely
> wrote:
>
>> The ERR_PTR()/IS_ERR() is a horrible pattern for code
>> readability because it breaks the expectations that programmers have for
>> what is and is not a bad pointer. There are decades of
On Mon, Feb 11, 2013 at 03:09:21PM +0100, Linus Walleij wrote:
> On Sat, Feb 9, 2013 at 10:17 AM, Grant Likely
> wrote:
>
> > The ERR_PTR()/IS_ERR() is a horrible pattern for code
> > readability because it breaks the expectations that programmers have for
> > what is and is not a bad pointer.
On Sat, Feb 9, 2013 at 10:17 AM, Grant Likely wrote:
> The ERR_PTR()/IS_ERR() is a horrible pattern for code
> readability because it breaks the expectations that programmers have for
> what is and is not a bad pointer. There are decades of history where the
> test for a bad pointer is 'if
On Sat, Feb 9, 2013 at 10:17 AM, Grant Likely grant.lik...@secretlab.ca wrote:
The ERR_PTR()/IS_ERR() is a horrible pattern for code
readability because it breaks the expectations that programmers have for
what is and is not a bad pointer. There are decades of history where the
test for a bad
On Mon, Feb 11, 2013 at 03:09:21PM +0100, Linus Walleij wrote:
On Sat, Feb 9, 2013 at 10:17 AM, Grant Likely grant.lik...@secretlab.ca
wrote:
The ERR_PTR()/IS_ERR() is a horrible pattern for code
readability because it breaks the expectations that programmers have for
what is and is not
On 02/11/2013 07:09 AM, Linus Walleij wrote:
On Sat, Feb 9, 2013 at 10:17 AM, Grant Likely grant.lik...@secretlab.ca
wrote:
The ERR_PTR()/IS_ERR() is a horrible pattern for code
readability because it breaks the expectations that programmers have for
what is and is not a bad pointer. There
On Sat, Feb 9, 2013 at 10:24 PM, Grant Likely wrote:
> On Sun, 3 Feb 2013 01:29:29 +0900, Alexandre Courbot
> wrote:
>> Make sure gpiolib works internally with descriptors and (chip, offset)
>> pairs instead of using the global integer namespace. This prepares the
>> ground for the removal of
On Sat, Feb 9, 2013 at 10:11 PM, Grant Likely wrote:
> I've been thinking about the adding of a new API to supplant the old,
> and I'm wondering if we're going about this the wrong way around; at
> least for the public api. We've moved to a model where device drivers
> are really supposed to
On Sun, 3 Feb 2013 01:29:29 +0900, Alexandre Courbot
wrote:
> Make sure gpiolib works internally with descriptors and (chip, offset)
> pairs instead of using the global integer namespace. This prepares the
> ground for the removal of the global gpio_desc[] array and the
> introduction of the
On Sun, 3 Feb 2013 01:29:29 +0900, Alexandre Courbot
wrote:
> Make sure gpiolib works internally with descriptors and (chip, offset)
> pairs instead of using the global integer namespace. This prepares the
> ground for the removal of the global gpio_desc[] array and the
> introduction of the
On Thu, 7 Feb 2013 15:57:32 +0900, Alexandre Courbot
wrote:
> On Wed, Feb 6, 2013 at 2:53 AM, Linus Walleij
> wrote:
> > On Sat, Feb 2, 2013 at 5:29 PM, Alexandre Courbot
> > wrote:
> >> +/**
> >> + * Convert a GPIO number to its descriptor
> >> + */
> >> +static struct gpio_desc
On Thu, 7 Feb 2013 15:57:32 +0900, Alexandre Courbot acour...@nvidia.com
wrote:
On Wed, Feb 6, 2013 at 2:53 AM, Linus Walleij linus.wall...@linaro.org
wrote:
On Sat, Feb 2, 2013 at 5:29 PM, Alexandre Courbot acour...@nvidia.com
wrote:
+/**
+ * Convert a GPIO number to its descriptor
On Sun, 3 Feb 2013 01:29:29 +0900, Alexandre Courbot acour...@nvidia.com
wrote:
Make sure gpiolib works internally with descriptors and (chip, offset)
pairs instead of using the global integer namespace. This prepares the
ground for the removal of the global gpio_desc[] array and the
On Sun, 3 Feb 2013 01:29:29 +0900, Alexandre Courbot acour...@nvidia.com
wrote:
Make sure gpiolib works internally with descriptors and (chip, offset)
pairs instead of using the global integer namespace. This prepares the
ground for the removal of the global gpio_desc[] array and the
On Sat, Feb 9, 2013 at 10:11 PM, Grant Likely grant.lik...@secretlab.ca wrote:
I've been thinking about the adding of a new API to supplant the old,
and I'm wondering if we're going about this the wrong way around; at
least for the public api. We've moved to a model where device drivers
are
On Sat, Feb 9, 2013 at 10:24 PM, Grant Likely grant.lik...@secretlab.ca wrote:
On Sun, 3 Feb 2013 01:29:29 +0900, Alexandre Courbot acour...@nvidia.com
wrote:
Make sure gpiolib works internally with descriptors and (chip, offset)
pairs instead of using the global integer namespace. This
On Wed, Feb 6, 2013 at 2:53 AM, Linus Walleij wrote:
> On Sat, Feb 2, 2013 at 5:29 PM, Alexandre Courbot wrote:
>
>> Make sure gpiolib works internally with descriptors and (chip, offset)
>> pairs instead of using the global integer namespace. This prepares the
>
> Its a numberspace not a
On Wed, Feb 6, 2013 at 2:53 AM, Linus Walleij linus.wall...@linaro.org wrote:
On Sat, Feb 2, 2013 at 5:29 PM, Alexandre Courbot acour...@nvidia.com wrote:
Make sure gpiolib works internally with descriptors and (chip, offset)
pairs instead of using the global integer namespace. This prepares
On Sat, Feb 2, 2013 at 5:29 PM, Alexandre Courbot wrote:
> Make sure gpiolib works internally with descriptors and (chip, offset)
> pairs instead of using the global integer namespace. This prepares the
Its a numberspace not a namespace right?
> ground for the removal of the global gpio_desc[]
On Sat, Feb 2, 2013 at 5:29 PM, Alexandre Courbot acour...@nvidia.com wrote:
Make sure gpiolib works internally with descriptors and (chip, offset)
pairs instead of using the global integer namespace. This prepares the
Its a numberspace not a namespace right?
ground for the removal of the
Make sure gpiolib works internally with descriptors and (chip, offset)
pairs instead of using the global integer namespace. This prepares the
ground for the removal of the global gpio_desc[] array and the
introduction of the descriptor-based GPIO API.
Signed-off-by: Alexandre Courbot
---
Make sure gpiolib works internally with descriptors and (chip, offset)
pairs instead of using the global integer namespace. This prepares the
ground for the removal of the global gpio_desc[] array and the
introduction of the descriptor-based GPIO API.
Signed-off-by: Alexandre Courbot
28 matches
Mail list logo
