From: Matt Sealey <matt-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org>
To: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: Christian Rund
<Christian.Rund-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>,
devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org
Subject: Re: Reminder 1: Device Tree documentation discussion for Cell/B.E. binding DRAFT - see Digest Vol 6, Issue 1
Date: Tue, 30 Dec 2008 17:20:29 -0600 [thread overview]
Message-ID: <495AACBD.4080804@genesi-usa.com> (raw)
In-Reply-To: <fa686aa40812161408j3672ba5cs7d8526cd643b69de-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Grant Likely wrote:
> On Tue, Dec 16, 2008 at 7:03 AM, Christian Rund
>> "model" property
>> property name: Specifies model of node.
>> Encoded as with encode-string.
>> Default value is { "IBM,CBEA" }.
>
>> "ibm,dt-version" property
>
> I'm concerned about the usage model of this property. It is not
> common for driver to go looking for an additional version property
> when interpreting node data.
Then that sucks, because they SHOULD be checking the model property if
it is known that a device may have errata, quirks or other problems
which cannot be programmatically detected in other ways (for instance
via version registers in the chip itself).
> Are all drivers expected to test the value of this property?
I would expect that once the model or version property is filled by the
device tree compiler or by the OF implementation, people will get used
to it being there. When it comes time that it may need to be checked
for, then it already exists; nobody will have to update their firmwares,
or device trees, or program any flash chips, just update their kernel or
recompile a module and unload/load it to get the changes and/or fixes.
You never complained that we fill out the version of the firmware (and
the build-date integer) in the Pegasos or Efika device trees. And rather
than make any particular checks on them, code has been submitted which
makes blanket changes not dependant on version, but on the presence of
certain nodes (and also NOT on the lack of properties inside those
nodes, too, when creating new property data). I've always thought such
trashing of firmware data without proper checks is both intrusive and
also creates yet another moving target for software developers to take
heed of. It makes working with Linux far, far more frustrating from
board bring-up all the way up to end users installing a prebaked
distribution..
> What should they do when the major or minor values do not match?
I would expect that this is to be determined when the version number
becomes an actual, actionable item.
One might stop booting if the firmware version is too old, or initiate
some fixups (such as using a compiled-in ACPI table as is done on many
older PC motherboards). Certain VIA EPIA boards have lots of weird
behaviours and the BIOS vendor string plus a few other heuristics are
employed to make sure they are worked around.
--
Matt Sealey <matt-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org>
prev parent reply other threads:[~2008-12-30 23:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-16 14:03 Reminder 1: Device Tree documentation discussion for Cell/B.E. binding DRAFT - see Digest Vol 6, Issue 1 Christian Rund
[not found] ` <OF89278B7C.B7D060FF-ONC1257521.004C9E27-C1257521.004D3F55-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
2008-12-16 22:08 ` Grant Likely
[not found] ` <fa686aa40812161408j3672ba5cs7d8526cd643b69de-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-12-30 23:08 ` Matt Sealey
[not found] ` <495AA9FB.40902-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org>
2008-12-31 0:09 ` Mitch Bradley
2008-12-30 23:20 ` Matt Sealey [this message]
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=495AACBD.4080804@genesi-usa.com \
--to=matt-seeee4iedtaxzmuojsdvmq@public.gmane.org \
--cc=Christian.Rund-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org \
--cc=devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org \
--cc=grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.