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 checki
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 descripto
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 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 h
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. T
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 (!ptr)
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 t
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 tread
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 des
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 des
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 *gpio_to_des
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 namespa
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[]
13 matches
Mail list logo