linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: Vitaly Wool <vwool@ru.mvista.com>
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: [PATCH] adding ROM chips to device tree: respin
Date: Wed, 08 Nov 2006 01:40:30 +0300	[thread overview]
Message-ID: <45510B5E.9000104@ru.mvista.com> (raw)
In-Reply-To: <1162937920.2680.10.camel@barja>

Hello.

Vitaly Wool wrote:
>>    We don't have any actual registers (at least "physmap" doesn't know about 
>>them anyway) I think, just a memory range. What registers are you talking about?

> We do have registers there, in query mode. The CFI registers.

    Aren't they accessed thru the range we're giving to the mapping layer? 
What else do you need? Who cares about the exact offsets at the mapping level 
(or at the level of the bus)?

>>>Okay, probably we can go you way naming of_device by what it's
>>>compatible with. So that "physmap" compatible would be called
>>>"physmap-flash", "nand"-compatible would be called "nand-flash" etc.

>>    Actually, Generic Names spec tells to use the most generic user-parsable 
>>names, just like I used initally ("flash")...

>>>Does that work for you?

>>    No. Getting rid of "physmap" completely and using of_find_node_by_type() 
>>does. :-)

> That's effectively what I'm talking about. Find the device by type and
> register it with the name which depends on what it's compatible with.

    I stand enlightened. It have finally occured to me that this of_device 
stuff wasn't worth the effort of using it and moving the code into 
drivers/mtd/. This move doesn't buy you much -- you still have to walk the 
device tree stupidly in search for the "known" devices... unless you're making 
up the names for of_platform bus like this. And what for? Those names aren't 
used to select the correct driver anyway... Crap. :-(
    We could also try using "device_type" or "name" properties to name the 
of_device -- this name doesn't matter much anyway...

> Vitaly

WBR, Sergei

  reply	other threads:[~2006-11-07 22:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-07 11:19 [PATCH] adding ROM chips to device tree: respin Vitaly Wool
2006-11-07 15:27 ` Sergei Shtylyov
2006-11-07 21:17   ` Vitaly Wool
2006-11-07 21:25     ` Sergei Shtylyov
2006-11-07 21:44       ` Vitaly Wool
2006-11-07 21:52         ` Sergei Shtylyov
2006-11-07 22:18           ` Vitaly Wool
2006-11-07 22:40             ` Sergei Shtylyov [this message]
2006-11-08 14:27               ` Sergei Shtylyov
  -- strict thread matches above, loose matches on Subject: below --
2006-11-09 18:41 Vitaly Wool
2006-11-14 15:47 Vitaly Wool
2006-11-14 15:59 ` Sergei Shtylyov

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=45510B5E.9000104@ru.mvista.com \
    --to=sshtylyov@ru.mvista.com \
    --cc=linuxppc-embedded@ozlabs.org \
    --cc=vwool@ru.mvista.com \
    /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;
as well as URLs for NNTP newsgroup(s).