All of lore.kernel.org
 help / color / mirror / Atom feed
From: Valentine Barshak <vbarshak@ru.mvista.com>
To: Matt Sealey <matt@genesi-usa.com>
Cc: David Brownell <david-b@pacbell.net>,
	linux-usb-devel@lists.sourceforge.net, linuxppc-dev@ozlabs.org
Subject: Re: [linux-usb-devel] [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
Date: Thu, 25 Oct 2007 22:50:08 +0400	[thread overview]
Message-ID: <4720E560.8060206@ru.mvista.com> (raw)
In-Reply-To: <4720DA11.9030103@genesi-usa.com>

Matt Sealey wrote:
> Compatible property on /builtin@F0000000/usb@F0001000 is
> 
> ohci-bigendian
> ohci-be
> mpc5200-ohci
> mpc5200-usb
> 
> device_type is "usb", model is "mpc5200-ohci".
> 
> Although I worry about cluttering up the cleanup, it is probably just
> adding an "if property(big-endian) OR compatible(mpc5200-ohci)"
> to that small big-endian check there.
>

We should also keep "ohci-bigendian" and "ohci-be" in the match table.

> I am currently moving on the assumption that the "correct" device
> tree for the Efika (notwithstanding the above) would be
> 
> usb@F0001000 {
>     device-type = "usb-ohci"
>     compatible = "mpc5200-ohci,mpc5200-usb-ohci"

It should also have compatible "usb-ohci" entry as a more general one.
Others are for device-specific quirks:
compatible = "mpc5200-usb-ohci","usb-ohci"

>     big-endian
> }
> 
> Or some variation including all the relevant checked-for
> properties.
> 
> I don't like the old "ohci-bigendian" and "ohci-be" properties.
> Picking out "ohci-bigendian" and "ohci-be" was someone's drunken
> idea, I'm sure, so I am happy to let them die a horrible death
> and never rear up ever again.
:)
> 
> Using mpc5200-ohci out is by far the safest idea, although it
> leaves in a rather platform-specific fix, I prefer singling out that
> platform and potentially causing nasty looks towards the
> direction of Genesi/bplan, than having ohci-bigendian continue
> to exist for the sake of it :D

So, do you suggest to use "mpc5200-ohci" instead of "ohci-be" in the 
match table?

> 
> There is another solution; change the properties in the Linux
> device tree fixups, but I would loathe that solution as it adds
> yet another part of the kernel to track.
> 
> Unfortunately the current device tree is a complete, stupid mess,
> a result of a bunch of guys not looking at the problem, and I
> have said this before (rant mode :) - I think device_type,
> compatible should report the KIND of device it is, and the model
> property should be used to pick out the particular quirks of
> the chipset. We could have had a nice system where "usb" is paired
> with compatible "ohci", and model is "mpc5200". No dashes or
> spaces or 10 strings to compare..
> 
:)

Thanks,
Valentine.

  reply	other threads:[~2007-10-25 18:51 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-24 16:22 [PATCH 0/2] USB: Rework OHCI PPC OF driver to support new bindings Valentine Barshak
2007-10-24 16:34 ` [PATCH 1/2] USB: Rework OHCI PPC OF for " Valentine Barshak
2007-10-24 22:05   ` Matt Sealey
2007-10-25  1:50     ` [linux-usb-devel] " David Brownell
2007-10-25  2:41       ` Grant Likely
2007-10-25 11:48         ` Valentine Barshak
2007-10-25 14:21           ` Grant Likely
2007-10-25 17:11             ` Valentine Barshak
2007-10-25 18:14               ` Matt Sealey
2007-10-25 18:13                 ` Valentine Barshak
2007-10-25 18:10             ` Matt Sealey
2007-10-25 18:01           ` Matt Sealey
2007-10-25 18:50             ` Valentine Barshak [this message]
2007-10-25 22:02               ` Matt Sealey
2007-10-26 11:24                 ` Valentine Barshak
2007-10-26 12:13             ` Valentine Barshak
2007-11-01 11:19     ` tnt
2007-11-01 12:44       ` Valentine Barshak
2007-11-01 13:46       ` [linux-usb-devel] " Dale Farnsworth
2007-10-24 16:35 ` [PATCH 2/2] PowerPC: Update USB OHCI DTS entires " Valentine Barshak

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=4720E560.8060206@ru.mvista.com \
    --to=vbarshak@ru.mvista.com \
    --cc=david-b@pacbell.net \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=matt@genesi-usa.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.