linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@secretlab.ca>
To: Michael Guntsche <mike@it-loops.com>,
	linuxppc-dev <linuxppc-dev@ozlabs.org>
Subject: Re: PHY not found after migration of gianfar driver to an of_platform_driver
Date: Wed, 4 Mar 2009 08:57:59 -0700	[thread overview]
Message-ID: <fa686aa40903040757n3992fec4jb6f3b75396af2958@mail.gmail.com> (raw)
In-Reply-To: <68DDAAA9-42AF-4E9C-907C-7D3269816184@it-loops.com>

I'm posting this back on the mailing list.  You're not being dense and
there are good questions here which others might elaborate more on.

On Tue, Mar 3, 2009 at 2:56 PM, Michael Guntsche <mike@it-loops.com> wrote:
> The routeboard is already providing a device-tree albeit not a very good
> one, otherwise the board would not boot in the first please if I just use=
 a
> plain kernel

I need more information here.  What do you mean when you say "plain
kernel".  What file from the build process do you use, and how do you
boot it?

> without an embedded tree. I need to fix this device tree since the new
> gianfar network code is expecting
>
> tbi-handle =3D <&tbi1>;
>
> Entries in the ethernet nodes to find the PHY devices. I do not know if y=
ou
> looked at the source of rbppc.c in detail. There is already code in there=
 to
> init the PCI bus
> since the tree is missing data for this.

I don't see a file named rbppc.c in the current kernel tree.

> * Why can't I just add those missing values in the setup-arch section of =
the
> code?

You might be able to use of_attach_node() & prom_add_property() to
modify the tree, but I've never done it myself.  Give it a try and
tell me if it works.  :-)

> =A0They are needed to init the NICs correctly so I can fix this here befo=
re
> the driver is loaded

Another option is to add a workaround to the driver.  This isn't
ideal, but driver authors aren't supposed to break device tree
bindings either.  Drivers are supposed to remain backwards compatible
with older device trees (either by patching the device tree or with
explicit workarounds).  Downside is that this type of change may be
harder to get merged.  And it's just plain not very pretty.

> * How could I add those information?
> =A0Can't I just do something similar to platforms/iseries/vio.c
> =A0(add_string_property and do_device_node)?

Maybe.  I don't know why those functions are tucked away in vio.c
instead of being common code.  If you go that approach, refactor the
functions you use to be shared.

> This wold have the benefit of getting the rest of the data from the board
> and just patch it with the needed values.

This is definitely preferred to wholesale replacement of the available tree=
.

g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

  parent reply	other threads:[~2009-03-04 15:58 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-26 19:15 PHY not found after migration of gianfar driver to an of_platform_driver Michael Guntsche
2009-02-26 23:38 ` Michael Guntsche
2009-02-27 18:39   ` Michael Guntsche
2009-02-28 13:41     ` Michael Guntsche
2009-02-28 15:03 ` Grant Likely
     [not found]   ` <3B1D47A2-329E-491E-B3AC-E76C1CE1762D@it-loops.com>
     [not found]     ` <fa686aa40903011353t464b1df3obd553132e5bc2570@mail.gmail.com>
     [not found]       ` <CD026D29-687D-4078-960E-108CC94C30E4@it-loops.com>
2009-03-02  1:15         ` Grant Likely
2009-03-02 11:58           ` Michael Guntsche
2009-03-02 15:08             ` Grant Likely
2009-03-03  7:35               ` Michael Guntsche
2009-03-03  9:49                 ` Michael Guntsche
2009-03-03 15:23                   ` Grant Likely
     [not found]                     ` <7AC161D8-83A8-4330-A2CF-3120F15D9038@it-loops.com>
     [not found]                       ` <fa686aa40903031310o4e0c0b2bnba0544012b0fb8bc@mail.gmail.com>
     [not found]                         ` <68DDAAA9-42AF-4E9C-907C-7D3269816184@it-loops.com>
2009-03-04 15:57                           ` Grant Likely [this message]
2009-03-04 16:47                             ` Michael Guntsche
2009-03-05  7:41                             ` Michael Guntsche
2009-03-05 15:08                               ` Grant Likely
2009-03-08 12:18 ` Wolfgang Ocker

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=fa686aa40903040757n3992fec4jb6f3b75396af2958@mail.gmail.com \
    --to=grant.likely@secretlab.ca \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mike@it-loops.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).