All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Sealey <matt@genesi-usa.com>
To: avorontsov@ru.mvista.com
Cc: Scott Wood <scottwood@freescale.com>,
	linuxppc-dev@ozlabs.org,
	Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Subject: Re: [PATCH] powerpc: Remove device_type = "rtc" properties in .dts files
Date: Wed, 22 Oct 2008 14:09:01 -0500	[thread overview]
Message-ID: <48FF7A4D.4000506@genesi-usa.com> (raw)
In-Reply-To: <20081022185913.GA1828@oksana.dev.rtsoft.ru>



Anton Vorontsov wrote:
> On Wed, Oct 22, 2008 at 01:40:50PM -0500, Matt Sealey wrote:
> 
> I think I got it. ;-) You think that I'm not aware of that we _can_
> use the device_type for matching the nodes. Well, I'm aware of it,
> sure we can. ;-)

I'm sure you are aware, I am just a little jumpy regarding 
this as the whole ePAPR-is-official thing and the direction 
Linux is taking with regards to redefining part of the device 
tree specs, that this could have been something a little more 
serious :)

> But we don't use it for the rtc nodes, and we don't want to encourage
> the usage for the flat trees. And that's the point of this patch.

Would it not be prudent to, while not actively encouraging it, 
at least mention device_type in any specifications as a legacy 
item (for real Open Firmware only) and for if a device should 
be in the tree as a generic, IEEE 1275-style device (i.e. 
there would be a set of well-defined client interface methods 
for it in a real OF)?

My basic concerns are for input/output as reported by /chosen 
- in case it is important exactly what is being used, there is 
at least one out-of-driver code snippet which checks if stdin 
and stdout are of type "serial" (or "failsafe") and 
auto-directs console to that - it would be nice to keep this 
clean and not dump a million serial-device-compatibles in 
another list here if someone wants to automatically choose 
between console output on the DIU or PSC for MPC5121e/MPC8610 
for example, or wants to restrict the amount of fancy stuff it 
does on a terminal if it's a slow serial device, or perhaps 
even automatically invoke netconsole if it's set to "network"?

I know U-Boot doesn't have the intelligence to output to 
anything but a serial port these days on those devices, but as 
they say, there is no fate but what we make .. we should make 
sure it doesn't turn up that code is never suggested or 
attempted because supporting it in Linux would be too big a 
jump or too messy a patch :)

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

  reply	other threads:[~2008-10-22 19:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-21 18:58 [PATCH] powerpc: Remove device_type = "rtc" properties in .dts files Anton Vorontsov
2008-10-21 19:37 ` Grant Likely
2008-10-22  0:04 ` David Gibson
2008-10-22 13:38 ` Matt Sealey
2008-10-22 13:50   ` Anton Vorontsov
2008-10-22 18:40     ` Matt Sealey
2008-10-22 18:59       ` Anton Vorontsov
2008-10-22 19:09         ` Matt Sealey [this message]
2008-10-22 19:28           ` Anton Vorontsov
     [not found] <C3C48FF2CBB.7060605@genesi-usa.com>
2008-10-22 20:38 ` Milton Miller

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=48FF7A4D.4000506@genesi-usa.com \
    --to=matt@genesi-usa.com \
    --cc=avorontsov@ru.mvista.com \
    --cc=g.liakhovetski@gmx.de \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=scottwood@freescale.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 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.