mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@secretlab.ca>
To: David Miller <davem@davemloft.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] uartlite: Fix build on sparc.
Date: Wed, 3 Mar 2010 11:52:59 -0700	[thread overview]
Message-ID: <fa686aa41003031052p59fdd7d9vee6c56b20a90930f@mail.gmail.com> (raw)
In-Reply-To: <20100303.084811.228955847.davem@davemloft.net>

On Wed, Mar 3, 2010 at 9:48 AM, David Miller <davem@davemloft.net> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
> Date: Wed, 3 Mar 2010 09:40:14 -0700
>
>> On Wed, Mar 3, 2010 at 9:04 AM, David Miller <davem@davemloft.net> wrote:
>>> From: Grant Likely <grant.likely@secretlab.ca>
>>> Date: Wed, 3 Mar 2010 08:51:27 -0700
>>>
>>>> Or if you prefer, I could expedite my patch that moves
>>>> of_address_to_resource() into common code (it's currently in my test
>>>> branch).  I wasn't planning to merge it until 2.6.35, but it is pretty
>>>> low risk so I'd be comfortable merging it now.
>>>
>>> I prefer if you deal with it this way.
>>
>> Hmmm... on second look my patch depends on a bunch of other stuff that
>> doesn't work with sparc yet.  grumble.  Sorry, this isn't going to
>> work yet.  I'll have to block out the uartlite driver instead.  In the
>> mean time I'll change the Kconfig to omit uartlite on sparc.
>
> BTW, while looking at this I can provide something similar to the
> of_address_to_resource() interface on sparc but it would need
> to provide the of_device pointer not the device_node one.
>
> I precompute all of the IRQs and I/O addresses of OF nodes and stick
> them into of_device->resource[] and of_device->irq[].
>
> So if I have the of_device pointer I can just:
>
>        memset(res, op->resource[n], sizeof(*res));
>
> as my implementation.

Cool.

I'm actually hoping to do much the same with the other OF
architectures, so hopefully of_address_to_resource() will become only
used in arch code when talking to hardware before the devices are
registered.

I also need to look at merging the bus address translation code.  It
looks like sparc and ppc are using variations on the same codebase,
but they seem to have diverged quite a lot.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

  reply	other threads:[~2010-03-03 18:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-03 10:50 David Miller
2010-03-03 15:51 ` Grant Likely
2010-03-03 16:04   ` David Miller
2010-03-03 16:40     ` Grant Likely
2010-03-03 16:44       ` Grant Likely
2010-03-03 16:48       ` David Miller
2010-03-03 18:52         ` Grant Likely [this message]
2010-03-03 18:55 ` Grant Likely
2010-03-04  2:50   ` Greg KH
2010-03-04  4:34   ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fa686aa41003031052p59fdd7d9vee6c56b20a90930f@mail.gmail.com \
    --to=grant.likely@secretlab.ca \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®