Hi all,
I'm trying to make FCC ethernet work with my board, based on an MPC8275
processor. I'm using kernel 2.6.22.1
I have the following problems:
1) When mdiobus_register() called from mii-bitbang.c (fs_enet_mdio_probe()
function) attemps to do a device_register for the mdio bus, it actually
registers the device with a bus_id in the form [0|1|...]:<phy_addr>, that
is the first part a simple integer. This, of course, happens because
fs_enet_of_init() (fsl_soc.c) does a
platform_device_register_simple("fsl-bb-mdio", i, NULL, 0); with i being
the first part of the bus, starting from 0. Unfortunately, when
fs_init_phy() (fs_enet_main.c) calls phy_connect() and therefore
phy_attach() (phy_device.c), the latter attempts to find the device in the
mdio bus, but it searches using the bus_id registered in the net_device
struct, which is in the form of <resource address>:<phy_addr>, eg.
f0000000:0, and therefore it fails... I don't know if I am doing something
wrong here, so any hint would be greatly appreciated.
2) Since there are two ethernet@<address> nodes in my device tree,
fs_of_enet_init() calls platform_device_register_simple("fsl-bb-mdio",...)
twice, therefore creating two mdio busses, 0 and 1, each having the same
two devices. For example, if I have two PHYs with addresses 1 and 5, I
will get two mdio busses and 4 devices, 0:1, 0:5, 1:1 and 1:5. Well, this
doesn't sound right to me, although I am not sure if this is a fatal
issue. Any comments?
3) Also, if I don't want to enter the phy interrupt in the device tree
(there is not one or I want to use PHY_POLL), what should I do? dtc seems
to not allow -1 as a value in the reg property.
thank you in advance for your responses
Alex
From: Scott Wood <hidden> Date: 2007-07-25 16:23:25
On Wed, Jul 25, 2007 at 05:22:40PM +0300, Alexandros Kostopoulos wrote:
1) When mdiobus_register() called from mii-bitbang.c (fs_enet_mdio_probe()
function) attemps to do a device_register for the mdio bus, it actually
registers the device with a bus_id in the form [0|1|...]:<phy_addr>, that
is the first part a simple integer. This, of course, happens because
fs_enet_of_init() (fsl_soc.c) does a
platform_device_register_simple("fsl-bb-mdio", i, NULL, 0); with i being
the first part of the bus, starting from 0. Unfortunately, when
fs_init_phy() (fs_enet_main.c) calls phy_connect() and therefore
phy_attach() (phy_device.c), the latter attempts to find the device in the
mdio bus, but it searches using the bus_id registered in the net_device
struct, which is in the form of <resource address>:<phy_addr>, eg.
f0000000:0, and therefore it fails... I don't know if I am doing something
wrong here, so any hint would be greatly appreciated.
The code is broken. Try applying the set of 61 patches I posted a week
or so ago (you'll need to apply them to Paul's tree from around the same
time, not the current tree).
2) Since there are two ethernet@<address> nodes in my device tree,
fs_of_enet_init() calls platform_device_register_simple("fsl-bb-mdio",...)
twice, therefore creating two mdio busses, 0 and 1, each having the same
two devices. For example, if I have two PHYs with addresses 1 and 5, I
will get two mdio busses and 4 devices, 0:1, 0:5, 1:1 and 1:5. Well, this
doesn't sound right to me, although I am not sure if this is a fatal
issue. Any comments?
It's not right -- my patchset gets rid of all of this mess.
3) Also, if I don't want to enter the phy interrupt in the device tree
(there is not one or I want to use PHY_POLL), what should I do? dtc seems
to not allow -1 as a value in the reg property.
Hello Scott,
Thanks for your response. I'm trying to apply your patches to vanilla
2.6.22.1 kernel, but unfortunately some patches fail, namely:
patching file arch/powerpc/boot/dts/mpc8272ads.dts
Hunk #1 FAILED at 10.
patching file arch/powerpc/boot/Makefile
Hunk #1 FAILED at 44.
patching file arch/powerpc/boot/Makefile
Hunk #1 FAILED at 48.
patching file arch/powerpc/platforms/Kconfig
Hunk #1 FAILED at 19.
and others, and also some patches appear to be already applied.
Maybe I'm patching the wrong kernel version?
thanks
Alex
On Wed, 25 Jul 2007 19:23:05 +0300, Scott Wood [off-list ref]
wrote:
On Wed, Jul 25, 2007 at 05:22:40PM +0300, Alexandros Kostopoulos wrote:
quoted
1) When mdiobus_register() called from mii-bitbang.c
(fs_enet_mdio_probe()
function) attemps to do a device_register for the mdio bus, it actually
registers the device with a bus_id in the form [0|1|...]:<phy_addr>,
that
is the first part a simple integer. This, of course, happens because
fs_enet_of_init() (fsl_soc.c) does a
platform_device_register_simple("fsl-bb-mdio", i, NULL, 0); with i
being
the first part of the bus, starting from 0. Unfortunately, when
fs_init_phy() (fs_enet_main.c) calls phy_connect() and therefore
phy_attach() (phy_device.c), the latter attempts to find the device in
the
mdio bus, but it searches using the bus_id registered in the net_device
struct, which is in the form of <resource address>:<phy_addr>, eg.
f0000000:0, and therefore it fails... I don't know if I am doing
something
wrong here, so any hint would be greatly appreciated.
The code is broken. Try applying the set of 61 patches I posted a week
or so ago (you'll need to apply them to Paul's tree from around the same
time, not the current tree).
quoted
2) Since there are two ethernet@<address> nodes in my device tree,
fs_of_enet_init() calls
platform_device_register_simple("fsl-bb-mdio",...)
twice, therefore creating two mdio busses, 0 and 1, each having the same
two devices. For example, if I have two PHYs with addresses 1 and 5, I
will get two mdio busses and 4 devices, 0:1, 0:5, 1:1 and 1:5. Well,
this
doesn't sound right to me, although I am not sure if this is a fatal
issue. Any comments?
It's not right -- my patchset gets rid of all of this mess.
quoted
3) Also, if I don't want to enter the phy interrupt in the device tree
(there is not one or I want to use PHY_POLL), what should I do? dtc
seems
to not allow -1 as a value in the reg property.
Oops! I've just noticed in your previous mail that I need to apply the
patches to Paul's tree...Sorry 'bout that... my mistake
alex
On Thu, 26 Jul 2007 13:42:46 +0300, Alexandros Kostopoulos
[off-list ref] wrote:
Hello Scott,
Thanks for your response. I'm trying to apply your patches to vanilla
2.6.22.1 kernel, but unfortunately some patches fail, namely:
patching file arch/powerpc/boot/dts/mpc8272ads.dts
Hunk #1 FAILED at 10.
patching file arch/powerpc/boot/Makefile
Hunk #1 FAILED at 44.
patching file arch/powerpc/boot/Makefile
Hunk #1 FAILED at 48.
patching file arch/powerpc/platforms/Kconfig
Hunk #1 FAILED at 19.
and others, and also some patches appear to be already applied.
Maybe I'm patching the wrong kernel version?
thanks
Alex
On Wed, 25 Jul 2007 19:23:05 +0300, Scott Wood [off-list ref]
wrote:
quoted
On Wed, Jul 25, 2007 at 05:22:40PM +0300, Alexandros Kostopoulos wrote:
quoted
1) When mdiobus_register() called from mii-bitbang.c
(fs_enet_mdio_probe()
function) attemps to do a device_register for the mdio bus, it actually
registers the device with a bus_id in the form [0|1|...]:<phy_addr>,
that
is the first part a simple integer. This, of course, happens because
fs_enet_of_init() (fsl_soc.c) does a
platform_device_register_simple("fsl-bb-mdio", i, NULL, 0); with i
being
the first part of the bus, starting from 0. Unfortunately, when
fs_init_phy() (fs_enet_main.c) calls phy_connect() and therefore
phy_attach() (phy_device.c), the latter attempts to find the device in
the
mdio bus, but it searches using the bus_id registered in the net_device
struct, which is in the form of <resource address>:<phy_addr>, eg.
f0000000:0, and therefore it fails... I don't know if I am doing
something
wrong here, so any hint would be greatly appreciated.
The code is broken. Try applying the set of 61 patches I posted a week
or so ago (you'll need to apply them to Paul's tree from around the same
time, not the current tree).
quoted
2) Since there are two ethernet@<address> nodes in my device tree,
fs_of_enet_init() calls
platform_device_register_simple("fsl-bb-mdio",...)
twice, therefore creating two mdio busses, 0 and 1, each having the
same
two devices. For example, if I have two PHYs with addresses 1 and 5, I
will get two mdio busses and 4 devices, 0:1, 0:5, 1:1 and 1:5. Well,
this
doesn't sound right to me, although I am not sure if this is a fatal
issue. Any comments?
It's not right -- my patchset gets rid of all of this mess.
quoted
3) Also, if I don't want to enter the phy interrupt in the device tree
(there is not one or I want to use PHY_POLL), what should I do? dtc
seems
to not allow -1 as a value in the reg property.
Well, I've downloaded the latest git from Paul's tree, and some patches
still fail (and the mpc8272_ads config doesn't compile). Must I get some
other revision of the tree (if yes, how's that done in git - my first time
with it )
thanks
alex
On Thu, 26 Jul 2007 14:24:01 +0300, Alexandros Kostopoulos
[off-list ref] wrote:
Oops! I've just noticed in your previous mail that I need to apply the
patches to Paul's tree...Sorry 'bout that... my mistake
alex
On Thu, 26 Jul 2007 13:42:46 +0300, Alexandros Kostopoulos
[off-list ref] wrote:
quoted
Hello Scott,
Thanks for your response. I'm trying to apply your patches to vanilla
2.6.22.1 kernel, but unfortunately some patches fail, namely:
patching file arch/powerpc/boot/dts/mpc8272ads.dts
Hunk #1 FAILED at 10.
patching file arch/powerpc/boot/Makefile
Hunk #1 FAILED at 44.
patching file arch/powerpc/boot/Makefile
Hunk #1 FAILED at 48.
patching file arch/powerpc/platforms/Kconfig
Hunk #1 FAILED at 19.
and others, and also some patches appear to be already applied.
Maybe I'm patching the wrong kernel version?
thanks
Alex
On Wed, 25 Jul 2007 19:23:05 +0300, Scott Wood
[off-list ref] wrote:
quoted
On Wed, Jul 25, 2007 at 05:22:40PM +0300, Alexandros Kostopoulos wrote:
quoted
1) When mdiobus_register() called from mii-bitbang.c
(fs_enet_mdio_probe()
function) attemps to do a device_register for the mdio bus, it
actually
registers the device with a bus_id in the form [0|1|...]:<phy_addr>,
that
is the first part a simple integer. This, of course, happens because
fs_enet_of_init() (fsl_soc.c) does a
platform_device_register_simple("fsl-bb-mdio", i, NULL, 0); with i
being
the first part of the bus, starting from 0. Unfortunately, when
fs_init_phy() (fs_enet_main.c) calls phy_connect() and therefore
phy_attach() (phy_device.c), the latter attempts to find the device
in the
mdio bus, but it searches using the bus_id registered in the
net_device
struct, which is in the form of <resource address>:<phy_addr>, eg.
f0000000:0, and therefore it fails... I don't know if I am doing
something
wrong here, so any hint would be greatly appreciated.
The code is broken. Try applying the set of 61 patches I posted a week
or so ago (you'll need to apply them to Paul's tree from around the
same
time, not the current tree).
quoted
2) Since there are two ethernet@<address> nodes in my device tree,
fs_of_enet_init() calls
platform_device_register_simple("fsl-bb-mdio",...)
twice, therefore creating two mdio busses, 0 and 1, each having the
same
two devices. For example, if I have two PHYs with addresses 1 and 5, I
will get two mdio busses and 4 devices, 0:1, 0:5, 1:1 and 1:5. Well,
this
doesn't sound right to me, although I am not sure if this is a fatal
issue. Any comments?
It's not right -- my patchset gets rid of all of this mess.
quoted
3) Also, if I don't want to enter the phy interrupt in the device tree
(there is not one or I want to use PHY_POLL), what should I do? dtc
seems
to not allow -1 as a value in the reg property.
From: Scott Wood <hidden> Date: 2007-07-26 15:29:53
Alexandros Kostopoulos wrote:
Well, I've downloaded the latest git from Paul's tree, and some patches
still fail (and the mpc8272_ads config doesn't compile). Must I get
some other revision of the tree (if yes, how's that done in git - my
first time with it )
They don't apply on top of Paul's current tree -- they apply to his tree
as of the time the patchset was posted. I should have a revised
patchset in a week or two (the delay mainly being to add and test a
couple new boards).
-Scott