powerpc: add scanning of ebc bus to of_platform
PATCH 1/1 powerpc: add scanning of ebc bus to of_platform
Subject: powerpc: add scanning of ebc bus to of_platform
This patch add scanning of ebc bus to of_platform, which is needed to recognize devices located on that bus.
Index: linux-2.6.19-rc6/arch/powerpc/kernel/of_platform.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
arch/powerpc/kernel/of_platform.c +1 -0
@@ -50,6 +50,7 @@ static struct of_device_id of_default_bu { .type =3D "plb5", }, { .type =3D "plb4", }, { .type =3D "opb", }, + { .type =3D "ebc", }, {}, };
=20
--=20
Mit freundlichen Gr=FCssen,
kind regards,
Christian Krafft
IBM Systems & Technology Group,=20
Linux Kernel Development
IT Specialist
Quoted 6 lines · Christian Krafft
Subject: powerpc: add scanning of ebc bus to
of_platformThis patch add scanning of ebc bus to
of_platform, which is needed to recognize devices located on that bus.Signed-off-by Christian Krafft <[email protected]>
I'd like other people opinions here... But I'm tempted to remove the "default" list of bus types here and have it always be passed by the platform... just in case.
If you guys prefer to keep it that way, then fine, patch is
Ben.
Quoted 3 lines
I'd like other people opinions here... But I'm tempted to remove the "default" list of bus types here and have it always be passed by the platform... just in case.
That's probably best -- no sense in registering devices on buses that the platform doesn't know how to drive!
Segher
Quoted 4 lines · Segher Boessenkool
Quoted 4 lines
I'd like other people opinions here... But I'm tempted to remove the "default" list of bus types here and have it always be passed by the platform... just in case.
I think for the flat device tree, we often have only type=soc, or compatible=soc anyway, and there is a limited number of internal bus types we want to probe on top of that for real OF implementations.
Quoted 2 lines
That's probably best -- no sense in registering devices on buses that the platform doesn't know how to drive!
But the platform doesn't need how to drive them, the device driver needs to. All the platform needs to know is the fact that it can deal with SOC devices that are automatically probed.
I'd much prefer to have the list in the same file that drives the devices in the first place. It's probably also good to register them as MODULE_DEVICE_TABLE(), for documentation purposes, even if the driver can't be built as a module yet.
Arnd <><
Quoted 5 lines
Quoted 2 lines
That's probably best -- no sense in registering devices on buses that the platform doesn't know how to drive!
But the platform doesn't need how to drive them, the device driver needs to.
No -- the platform needs to know how to do low-level bus operations (I/O reads, etc). For most memory-mapped buses this is pretty trivial, of course.
Maybe we're just disagreeing over the word "platform" here?
Segher
Quoted 8 lines · Arnd Bergmann
But the platform doesn't need how to drive them, the device driver needs to. All the platform needs to know is the fact that it can deal with SOC devices that are automatically probed.
I'd much prefer to have the list in the same file that drives the devices in the first place. It's probably also good to register them as
MODULE_DEVICE_TABLE(), for documentation purposes, even if the driver can't be built as a module yet.
So is that an ack or a nack for the patch? Sounds like a nack to me, but I'm not sure. :)
Paul.
Quoted 6 lines · Paul Mackerras
Quoted 4 lines · Arnd Bergmann
But the platform doesn't need how to drive them, the device driver needs to. All the platform needs to know is the fact that it can deal with SOC devices that are automatically probed.
Quoted 7 lines
Quoted 4 lines
I'd much prefer to have the list in the same file that drives the devices in the first place. It's probably also good to register them as
MODULE_DEVICE_TABLE(), for documentation purposes, even if the driver can't be built as a module yet.So is that an ack or a nack for the patch? Sounds like a nack to me, but I'm not sure. :)
Put it in for now.
Ben.
Quoted 6 lines · Benjamin Herrenschmidt
=20
Quoted 2 lines
an ack or a nack for the patch? =A0Sounds like a nack to me, but I'm not sure. :)
=20
Put it in for now.
=20
Yes, definitely. I was not objecting to Christian's patch anyway, but to Ben's idea of getting rid of that part of the code, which is a side-discussion.
Arnd <><