Am 21.03.2014 09:28, schrieb Linus Walleij:
On Tue, Mar 18, 2014 at 10:45 AM, Alexander Holler wrote:
But I don't need any rush here, I'm just unable to understand why the -rc
phase isn't used for bug fixing as I believe that's what this phase is for.
Right now it is mostly a practical issue
On Tue, Mar 18, 2014 at 10:45 AM, Alexander Holler wrote:
> But I don't need any rush here, I'm just unable to understand why the -rc
> phase isn't used for bug fixing as I believe that's what this phase is for.
Right now it is mostly a practical issue to me, as I applied the patch to
the devel
Hi Alexander,
On Tuesday 18 March 2014 03:15 PM, Alexander Holler wrote:
> Am 18.03.2014 09:37, schrieb Sekhar Nori:
>
>> It is safe - at the least it does not break anything that is already
>> working. I guess the decision to put it into -rc depends on whether you
>> consider out of tree dtbs to
Am 18.03.2014 09:37, schrieb Sekhar Nori:
It is safe - at the least it does not break anything that is already
working. I guess the decision to put it into -rc depends on whether you
consider out of tree dtbs to be a valid usecase for the kernel.
That's all DT is about, getting rid of the nece
On Monday 17 March 2014 07:35 PM, Linus Walleij wrote:
> On Mon, Mar 17, 2014 at 2:29 PM, Sekhar Nori wrote:
>
>> One thing to note is that this driver is used by keystone too and all
>> its users are DT-only. Although I do not see any in-kernel DT GPIO users
>> even there.
>>
>> I can confirm th
On Mon, Mar 17, 2014 at 3:11 PM, Alexander Holler wrote:
> Thanks, maybe someone could add a
>
> Cc:
OK if it goes in as fix I'll add this.
> to get the fix back into 3.14 if it has go through -next.
It's already in linux-next.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the
On 03/17/2014 03:29 PM, Sekhar Nori wrote:
> On Friday 14 March 2014 04:32 PM, Linus Walleij wrote:
>> On Fri, Mar 14, 2014 at 11:08 AM, Alexander Holler
>> wrote:
>>> Am 11.03.2014 11:15, schrieb Linus Walleij:
On Wed, Mar 5, 2014 at 12:21 PM, Alexander Holler
wrote:
> The d
Am 17.03.2014 14:29, schrieb Sekhar Nori:
One thing to note is that this driver is used by keystone too and all
its users are DT-only. Although I do not see any in-kernel DT GPIO users
even there.
Common gpio users are, as always, gpio-keys and gpio-leds. Doesn't have
one of the keystone boar
On Mon, Mar 17, 2014 at 2:29 PM, Sekhar Nori wrote:
> One thing to note is that this driver is used by keystone too and all
> its users are DT-only. Although I do not see any in-kernel DT GPIO users
> even there.
>
> I can confirm the patch does not break my gpiolib based test module
> (test with
On Friday 14 March 2014 04:32 PM, Linus Walleij wrote:
> On Fri, Mar 14, 2014 at 11:08 AM, Alexander Holler
> wrote:
>> Am 11.03.2014 11:15, schrieb Linus Walleij:
>>> On Wed, Mar 5, 2014 at 12:21 PM, Alexander Holler
>>> wrote:
>>>
The driver missed an of_xlate function to translate gpio
Am 14.03.2014 20:52, schrieb Linus Walleij:
So a few Tested-by's from the people using this driver would for
example convince me that it is solving a real problem for them
and it needs to go into fixes.
2001: a space odyssey is fast action movie compared with the movie
kernel bug fixing. And
On Fri, Mar 14, 2014 at 7:33 PM, Alexander Holler wrote:
> Am 14.03.2014 14:54, schrieb Linus Walleij:
>
>> On Fri, Mar 14, 2014 at 1:38 PM, Alexander Holler
>> wrote:
>>
In that case it is hardly a fix that we need to rush out to the entire
world.
>>>
>>>
>>> And I thought the reason f
Am 14.03.2014 14:54, schrieb Linus Walleij:
On Fri, Mar 14, 2014 at 1:38 PM, Alexander Holler wrote:
In that case it is hardly a fix that we need to rush out to the entire
world.
And I thought the reason for -rc is actually to fix bugs. But I never
understood the magical ways and timings pat
On Fri, Mar 14, 2014 at 1:38 PM, Alexander Holler wrote:
>> In that case it is hardly a fix that we need to rush out to the entire
>> world.
>
> And I thought the reason for -rc is actually to fix bugs. But I never
> understood the magical ways and timings patches make their way into
> mainline.
Am 14.03.2014 12:02, schrieb Linus Walleij:
On Fri, Mar 14, 2014 at 11:08 AM, Alexander Holler wrote:
Am 11.03.2014 11:15, schrieb Linus Walleij:
On Wed, Mar 5, 2014 at 12:21 PM, Alexander Holler wrote:
The driver missed an of_xlate function to translate gpio numbers
as found in the DT to t
On Fri, Mar 14, 2014 at 11:08 AM, Alexander Holler wrote:
> Am 11.03.2014 11:15, schrieb Linus Walleij:
>> On Wed, Mar 5, 2014 at 12:21 PM, Alexander Holler
>> wrote:
>>
>>> The driver missed an of_xlate function to translate gpio numbers
>>> as found in the DT to the correct chip and number.
>>
Am 11.03.2014 11:15, schrieb Linus Walleij:
> On Wed, Mar 5, 2014 at 12:21 PM, Alexander Holler
> wrote:
>
>> The driver missed an of_xlate function to translate gpio numbers
>> as found in the DT to the correct chip and number.
>>
>> While there I've set #gpio_cells to a fixed value of 2.
>>
>>
On Wed, Mar 5, 2014 at 12:21 PM, Alexander Holler wrote:
> The driver missed an of_xlate function to translate gpio numbers
> as found in the DT to the correct chip and number.
>
> While there I've set #gpio_cells to a fixed value of 2.
>
> I've used gpio-pxa.c as template for those changes and t
Hi Alexander,
On 03/05/2014 01:21 PM, Alexander Holler wrote:
The driver missed an of_xlate function to translate gpio numbers
as found in the DT to the correct chip and number.
While there I've set #gpio_cells to a fixed value of 2.
I've used gpio-pxa.c as template for those changes and teste
The driver missed an of_xlate function to translate gpio numbers
as found in the DT to the correct chip and number.
While there I've set #gpio_cells to a fixed value of 2.
I've used gpio-pxa.c as template for those changes and tested my changes
successfully on a da850 board using entries for gpio
20 matches
Mail list logo