From: Grant Likely
Date: Fri, 30 Nov 2012 09:35:20 +
> On non-sparc I've actually been moving in the direction of resolving
> resources at .probe time to make it easier to handle deferred probing.
> So if, for example, a device irq line is routed to a GPIO instead of the
> core interrupt cont
On Fri, Nov 30, 2012 at 9:40 AM, Thierry Reding
wrote:
> On Fri, Nov 30, 2012 at 09:35:20AM +, Grant Likely wrote:
>> On Wed, 07 Nov 2012 02:34:19 -0500 (EST), David Miller
>> wrote:
>> > From: Thierry Reding
>> > Date: Wed, 7 Nov 2012 07:52:58 +0100
>> >
>> > > It seems like OF_ADDRESS wou
On Fri, Nov 30, 2012 at 09:35:20AM +, Grant Likely wrote:
> On Wed, 07 Nov 2012 02:34:19 -0500 (EST), David Miller
> wrote:
> > From: Thierry Reding
> > Date: Wed, 7 Nov 2012 07:52:58 +0100
> >
> > > It seems like OF_ADDRESS would be trickier. A comment around line 60 in
> > > drivers/of/pl
On Wed, 07 Nov 2012 02:34:19 -0500 (EST), David Miller
wrote:
> From: Thierry Reding
> Date: Wed, 7 Nov 2012 07:52:58 +0100
>
> > It seems like OF_ADDRESS would be trickier. A comment around line 60 in
> > drivers/of/platform.c says that SPARC doesn't need functions defined in
> > the enclosing
From: Thierry Reding
Date: Wed, 7 Nov 2012 07:52:58 +0100
> It seems like OF_ADDRESS would be trickier. A comment around line 60 in
> drivers/of/platform.c says that SPARC doesn't need functions defined in
> the enclosing #ifdef CONFIG_OF_ADDRESS block. I'm not sure it would be
> acceptable to re
On Tue, Nov 06, 2012 at 06:40:58PM -0500, David Miller wrote:
> From: Thierry Reding
> Date: Mon, 5 Nov 2012 10:53:15 +0100
>
> > Are you aware of any reasons why this conflict would still be necessary?
>
> No reason that I can see, I'll push something like the patch below
> via the sparc tree.
From: Thierry Reding
Date: Mon, 5 Nov 2012 10:53:15 +0100
> Are you aware of any reasons why this conflict would still be necessary?
No reason that I can see, I'll push something like the patch below
via the sparc tree.
> This is not only the case for OF_GPIO but likely also for OF_SPI,
> OF_I2
[resending with David's correct email address]
Hi David,
There have been a number of reports that Linux kernel builds fail on
SPARC because it doesn't support OF_GPIO, which provides the of_node
field of the struct gpio_chip.
One of the drivers I wrote (gpio-adnp) accesses this unconditionally b
Hi David,
There have been a number of reports that Linux kernel builds fail on
SPARC because it doesn't support OF_GPIO, which provides the of_node
field of the struct gpio_chip.
One of the drivers I wrote (gpio-adnp) accesses this unconditionally but
only depends on OF and not OF_GPIO, so it fai
9 matches
Mail list logo
