linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: linuxppc-dev <Linuxppc-dev@ozlabs.org>,
	David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
Date: Thu, 14 Jun 2007 15:18:05 +0200	[thread overview]
Message-ID: <5f5cc841be768a8d34e7278a8d221b97@kernel.crashing.org> (raw)
In-Reply-To: <4671390D.1060606@ru.mvista.com>

>>> So, what you're suggesting is a subnode for each described partition?
>
>> I'm saying this is a reasonable way to describe the regions
>> of flash the firmware itself cares about.
>
>> This isn't anything new; it is done like this on some
>> Apple systems, for example.
>
>    First you're saying that nodes should correspont to *real* devices, 
> then it turns out that there have been precedents for the nodes 
> corresponding to completely virtual entities? ;-)

Every physical device should have its own node (there
_can_ be exceptions, but if you can help it at all...)

There can be virtual devices as well, although you don't
often need or want them.  There are a few pseudo-nodes
too, not representing _any_ device, physical or virtual.

>>> Seems an awfully verbose way of going about it,
>
>> Not verbose, but flexible, and in line with everything
>
>    Yes, I'd agree about more flexibility...

Good to hear :-)

>> else about the device tree.
>
>    How about your earlier arguments against the representation of 
> flashes?

What arguments, exactly?  Perhaps you're not understanding
exactly what I meant, or perhaps I changed my mind -- that
happens sometimes, after long discussions.  That is what
those discussions are for, even -- only after looking at
every detail, and discussing all those details with other
people, including non-experts on OF who can bring in valuable
concerns about use cases etc.; only then can a good device
binding be defined.  Sometimes also it should be concluded
there is not enough experience yet on how to do a certain
device binding; in such a case, the best course of action is
usually to _not_ define such a binding yet.

>>> and I don't see what
>>> it buys us over the partitions/partition-names pair of properties.
>
>> It is extensible.  It makes parsing trivial.  It
>
>    Excellent -- previously my arguments about more simplicity for 
> representing  flash itself were sent to /dev/null.

Do you like my proposed CFI binding?  I need a bit more
input on how to do a JEDEC flash binding still.  After
I've written it all up properly, I plan to send this to
the OF working group to turn it into a standard binding.

>> represents a flash partition in a way similar to how
>> a "whole" flash device is represented.
>
>    Except it's not a device. :-)

Yes, but in many aspects it can be treated as one.  And
it cannot be mistaken for one, either.


Segher

  reply	other threads:[~2007-06-14 13:18 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-01 23:20 [PATCH] powerpc: Create "rom" (MTD) device prpmc2800 Mark A. Greer
2007-06-02  8:46 ` Segher Boessenkool
2007-06-04 20:56 ` Mark A. Greer
2007-06-05 20:35   ` Sergei Shtylyov
2007-06-05 21:11     ` Mark A. Greer
2007-06-06 12:41       ` Sergei Shtylyov
2007-06-07 15:08         ` David Woodhouse
2007-06-06  2:39   ` David Gibson
2007-06-07 13:30     ` Segher Boessenkool
2007-06-12  4:42       ` David Gibson
2007-06-12 10:50         ` Segher Boessenkool
2007-06-13  6:12           ` David Gibson
2007-06-13  9:13             ` Segher Boessenkool
2007-06-13  9:19               ` David Gibson
2007-06-13  9:37                 ` Segher Boessenkool
2007-06-14  4:29                   ` David Gibson
2007-06-14  8:00                     ` Segher Boessenkool
2007-06-14 12:39                     ` Sergei Shtylyov
2007-06-14 13:20                       ` Segher Boessenkool
2007-06-14 12:48           ` Sergei Shtylyov
2007-06-14 13:18             ` Segher Boessenkool [this message]
2007-06-14 12:50         ` Sergei Shtylyov
2007-06-14 13:43           ` Segher Boessenkool
  -- strict thread matches above, loose matches on Subject: below --
2007-06-02  4:30 Milton Miller
2007-06-02  7:39 ` Benjamin Herrenschmidt
2007-06-03 16:10   ` Sergei Shtylyov
2007-06-03 17:36     ` Segher Boessenkool
2007-06-03 18:03       ` Sergei Shtylyov
2007-06-03 18:25         ` Segher Boessenkool
2007-06-03 18:36           ` Sergei Shtylyov
2007-06-03 18:46             ` Segher Boessenkool
2007-06-03 19:16               ` Sergei Shtylyov
2007-06-03 21:04         ` Benjamin Herrenschmidt
2007-06-04 12:34           ` Sergei Shtylyov
2007-06-04 14:37             ` Segher Boessenkool
2007-06-04 14:49               ` Sergei Shtylyov
2007-06-07 14:53           ` David Woodhouse
2007-06-07 15:49             ` Segher Boessenkool
2007-06-07 14:47         ` David Woodhouse
2007-06-07 15:32           ` Segher Boessenkool
2007-06-02  8:53 ` Segher Boessenkool
2007-06-03 16:22   ` Sergei Shtylyov
2007-06-03 17:40     ` Segher Boessenkool
2007-06-03 18:31       ` Sergei Shtylyov
2007-06-03 18:44         ` Segher Boessenkool
2007-06-03 19:13           ` Sergei Shtylyov
2007-06-03 19:56             ` Segher Boessenkool
2007-06-03 20:26               ` Sergei Shtylyov
2007-06-04  8:07                 ` Segher Boessenkool
2007-06-04 13:34                   ` Sergei Shtylyov
2007-06-07 15:00                 ` David Woodhouse
2007-06-07 15:55                   ` Segher Boessenkool
2007-06-07 16:05                     ` David Woodhouse
2007-06-07 16:46                       ` Segher Boessenkool
2007-06-12  4:44                     ` David Gibson
2007-06-12 10:53                       ` Segher Boessenkool
2007-06-13  3:16                         ` David Gibson
2007-06-13  5:05                           ` Segher Boessenkool
2007-06-13  6:11                             ` David Gibson
2007-06-13  9:10                               ` Segher Boessenkool
2007-06-15  4:12                                 ` David Gibson
2007-06-15 11:22                                   ` Segher Boessenkool
2007-06-15  4:14                     ` David Gibson
2007-06-15  8:42                       ` Segher Boessenkool
2007-06-15  8:47                         ` David Woodhouse
2007-06-15  8:59                           ` Segher Boessenkool
2007-06-03 21:12     ` Benjamin Herrenschmidt
2007-06-04  8:11       ` Segher Boessenkool
2007-06-04 13:16         ` Sergei Shtylyov
2007-06-04 12:41       ` Sergei Shtylyov
2007-06-04 14:49         ` Segher Boessenkool
2007-06-04 15:54           ` Sergei Shtylyov
2007-06-03 17:29 ` Sergei Shtylyov
2007-06-03 17:45   ` Segher Boessenkool
2007-06-03 18:18     ` Sergei Shtylyov
2007-06-03 18:43       ` Segher Boessenkool
2007-06-03 18:59         ` Sergei Shtylyov
2007-06-03 19:48           ` Segher Boessenkool
2007-06-03 20:10             ` Sergei Shtylyov
2007-06-04  8:02               ` Segher Boessenkool
2007-06-04 19:40 ` Mark A. Greer

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=5f5cc841be768a8d34e7278a8d221b97@kernel.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=Linuxppc-dev@ozlabs.org \
    --cc=david@gibson.dropbear.id.au \
    --cc=sshtylyov@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).