* Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
From: Jean Delvare @ 2008-07-01 16:29 UTC (permalink / raw)
To: Jon Smirl; +Cc: Linuxppc-dev, Paul Mackerras, i2c
In-Reply-To: <9e4733910807010812h30e49144v5b3012e6c156ecca@mail.gmail.com>
On Tue, 1 Jul 2008 11:12:58 -0400, Jon Smirl wrote:
> On 7/1/08, Jean Delvare <khali@linux-fr.org> wrote:
> > I'm fine with this patch. In particular, exporting i2c_bus_type is OK.
> > It was un-exported only because it had no user left, but it can be
> > exported again if needed.
>
> Another solution would be to move drivers/of/of_i2c into the i2c
> directory and make it part of i2c core on powerpc builds.
I don't think this is a good idea. Merging arch-specific code (or
half-arch-specific code in this case) into arch-neutral drivers ends up
being a pain to maintain. People will keep sending me patches for stuff
I don't know anything about and can't help with. Having of-specific
stuff in just one directory as is the case now sounds much better to
me. All it's missing is a MAINTAINERS entry.
--
Jean Delvare
^ permalink raw reply
* [PATCH] powerpc: legacy_serial: reg-offset & shift aren't used
From: John Linn @ 2008-07-01 16:31 UTC (permalink / raw)
To: linuxppc-dev, grant.likely, paulus, benh, dwg, jwboyer,
stephen.neuendorffer
Cc: John Linn
The legacy serial driver does not work with an 8250
type UART that uses reg-offset and reg-shift. This
change updates the driver so it doesn't find the UART
when those properties are present on the UART in the
device tree for soc devices.
Signed-off-by: John Linn <john.linn@xilinx.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/kernel/legacy_serial.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
index 61dd174..b43235f 100644
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -136,6 +136,11 @@ static int __init add_legacy_soc_port(struct device_node *np,
if (of_get_property(np, "clock-frequency", NULL) == NULL)
return -1;
+ /* if reg-shift and offset, don't try to use it */
+ if ((of_get_property(np, "reg-shift", NULL) != NULL) &&
+ (of_get_property(np, "reg-offset", NULL) != NULL))
+ return -1;
+
/* if rtas uses this device, don't try to use it as well */
if (of_get_property(np, "used-by-rtas", NULL) != NULL)
return -1;
--
1.5.2.1
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply related
* Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
From: Jean Delvare @ 2008-07-01 16:35 UTC (permalink / raw)
To: Jon Smirl; +Cc: Linuxppc-dev, Paul Mackerras, i2c
In-Reply-To: <9e4733910807010929k7088f97ekbadf854c949fbc64@mail.gmail.com>
On Tue, 1 Jul 2008 12:29:29 -0400, Jon Smirl wrote:
> On 7/1/08, Jean Delvare <khali@linux-fr.org> wrote:
> > Hi Jon,
> >
> >
> > On Mon, 30 Jun 2008 19:01:28 -0400, Jon Smirl wrote:
> > > Add the of_find_i2c_device_by_node function. This allows you to
> > > follow a reference in the device to an i2c device node and then
> > > locate the linux device instantiated by the device tree. Example
> > > use, an i2s codec controlled by i2c.
> > > ---
> > >
> > > drivers/i2c/i2c-core.c | 2 +-
> > > drivers/of/of_i2c.c | 37 ++++++++++++++++++++++++++-----------
> > > include/linux/i2c.h | 3 +++
> > > include/linux/of_i2c.h | 2 ++
> > > 4 files changed, 32 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> > > index d0175f4..e3abe1b 100644
> > > --- a/drivers/i2c/i2c-core.c
> > > +++ b/drivers/i2c/i2c-core.c
> > > @@ -208,7 +208,7 @@ static struct device_attribute i2c_dev_attrs[] = {
> > > { },
> > > };
> > >
> > > -static struct bus_type i2c_bus_type = {
> > > +struct bus_type i2c_bus_type = {
> > > .name = "i2c",
> > > .dev_attrs = i2c_dev_attrs,
> > > .match = i2c_device_match,
> >
> >
> > What if i2c-core is built as a module? Don't you need to export the
> > symbol then?
>
> Jean, can you re-export i2c_bus_type and then I'll drop that part from
> the patch? That way the patch won't hit multiple maintainers.
Just send me a patch doing just that and I will be glad to push early in
the 2.6.27 merge window.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH2/2] [POWERPC] CPM1: implement GPIO LIB API on CPM1 Freescale SoC.
From: Grant Likely @ 2008-07-01 16:36 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: Scott Wood, linuxppc-dev list
In-Reply-To: <486A4FFE.6020407@scram.de>
On Tue, Jul 01, 2008 at 05:40:46PM +0200, Jochen Friedrich wrote:
> Hi Grant,
>
> sorry for the late response on this one.
>
> > 2. You need to specifiy exact chip names in your compatible string.
> > "fsl,cpm1-pario-<bank>" is a made up thing.
>
> >> + for_each_compatible_node(np, NULL, "fsl,cpm1-pario-bank16")
> >> + cpm1_gpiochip_add16(np);
> >> +
> >> + for_each_compatible_node(np, NULL, "fsl,cpm1-pario-bank32b")
> >> + cpm1_gpiochip_add32(np);
> >> +
> >> + /* Port E uses CPM2 layout */
> >> + for_each_compatible_node(np, NULL, "fsl,cpm1-pario-bank32e")
> >> + cpm2_gpiochip_add32(np);
>
> What do you suggest here?
>
> All GPIO ports of CPM1/CPM2 are on the SoC, so the chip name is in fact the CPU itself
> (like fsl,mpc866-pario-bank16).
Right; so that is what I think you should call them. 'fsl,mpc866-*' instead
of 'fsl,cpm1-*'. If multiple mpc8xx parts have the cpm1 core, then
choose one of the parts for all the others to claim compatibility with.
Now, there is a possible exception here... *IF* 'fsl,cpm1' is a very
well defined ASIC logic block that is known to be identical or versioned
between the various 8xx parts, *THEN* it is probably okay to call it
fsl,cpm1 and my previous comment does not apply. But, I think it must
be documented in the device tree binding as to what it is and where to
get documentation for it. And you should still have the first
compatible value to be something like "fsl,mpc866-pario-bank16",
followed by the cpm ones.
This was recently discussed between Kim and Segher.
g.
^ permalink raw reply
* [PATCH] powerpc: boot: update for initrd with simpleImage
From: John Linn @ 2008-07-01 16:37 UTC (permalink / raw)
To: linuxppc-dev, grant.likely, jwboyer, paulus; +Cc: John Linn
This change to the makefile corrects the build of a
simpleImage with initrd.
Signed-off-by: John Linn <john.linn@xilinx>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/boot/Makefile | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 1cee2f9..095e04d 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -273,7 +273,8 @@ endif
initrd- := $(patsubst zImage%, zImage.initrd%, $(image-n) $(image-))
initrd-y := $(patsubst zImage%, zImage.initrd%, \
$(patsubst dtbImage%, dtbImage.initrd%, \
- $(patsubst treeImage%, treeImage.initrd%, $(image-y))))
+ $(patsubst simpleImage%, simpleImage.initrd%, \
+ $(patsubst treeImage%, treeImage.initrd%, $(image-y)))))
initrd-y := $(filter-out $(image-y), $(initrd-y))
targets += $(image-y) $(initrd-y)
--
1.5.2.1
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply related
* Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
From: Jon Smirl @ 2008-07-01 16:38 UTC (permalink / raw)
To: Jean Delvare; +Cc: Linuxppc-dev, Paul Mackerras, i2c
In-Reply-To: <20080701182949.12119d6e@hyperion.delvare>
On 7/1/08, Jean Delvare <khali@linux-fr.org> wrote:
> On Tue, 1 Jul 2008 11:12:58 -0400, Jon Smirl wrote:
> > On 7/1/08, Jean Delvare <khali@linux-fr.org> wrote:
> > > I'm fine with this patch. In particular, exporting i2c_bus_type is OK.
> > > It was un-exported only because it had no user left, but it can be
> > > exported again if needed.
> >
> > Another solution would be to move drivers/of/of_i2c into the i2c
> > directory and make it part of i2c core on powerpc builds.
>
>
> I don't think this is a good idea. Merging arch-specific code (or
> half-arch-specific code in this case) into arch-neutral drivers ends up
> being a pain to maintain. People will keep sending me patches for stuff
> I don't know anything about and can't help with. Having of-specific
> stuff in just one directory as is the case now sounds much better to
> me. All it's missing is a MAINTAINERS entry.
A side effect of this is that the small pieces of code in drivers/of
have to be compiled into stand alone modules and they may need access
to internal symbols from the subsystem. If they were directly linked
into the subsystems you wouldn't need to make the internal symbols
visible. Now the subsystems have to be careful about breaking the
in-kernel, external users of the symbols and we've made it possible
for out of tree drivers to get to internal structures.
>
> --
>
> Jean Delvare
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] powerpc: Xilinx: adding Xilinx 440 cpu support
From: John Linn @ 2008-07-01 16:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: John Linn
The following change updates the cputable to support the
440 processor in the Xilinx Virtex5 FXT FPGA.
Signed-off-by: John Linn <john.linn@xilinx.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/kernel/cputable.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index e44d553..ae3660b 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1410,6 +1410,16 @@ static struct cpu_spec __initdata cpu_specs[] = {
.machine_check = machine_check_440A,
.platform = "ppc440",
},
+ { /* 440 in Xilinx Virtex-5 FXT */
+ .pvr_mask = 0xfffffff0,
+ .pvr_value = 0x7ff21910,
+ .cpu_name = "440 in Virtex-5 FXT",
+ .cpu_features = CPU_FTRS_44X,
+ .cpu_user_features = COMMON_USER_BOOKE,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .platform = "ppc440",
+ },
{ /* 460EX */
.pvr_mask = 0xffff0002,
.pvr_value = 0x13020002,
--
1.5.2.1
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply related
* Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
From: Grant Likely @ 2008-07-01 16:43 UTC (permalink / raw)
To: Jon Smirl; +Cc: Jean Delvare, Linuxppc-dev, Paul Mackerras, i2c
In-Reply-To: <9e4733910807010812h30e49144v5b3012e6c156ecca@mail.gmail.com>
On Tue, Jul 01, 2008 at 11:12:58AM -0400, Jon Smirl wrote:
> On 7/1/08, Jean Delvare <khali@linux-fr.org> wrote:
> > I'm fine with this patch. In particular, exporting i2c_bus_type is OK.
> > It was un-exported only because it had no user left, but it can be
> > exported again if needed.
>
> Another solution would be to move drivers/of/of_i2c into the i2c
> directory and make it part of i2c core on powerpc builds.
My preference is for things like of_spi and of_i2c to go with the
related busses; I think it makes more sense to keep all the I2C stuff
together, but I've already lost that battle once.
g.
^ permalink raw reply
* Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
From: Jean Delvare @ 2008-07-01 16:44 UTC (permalink / raw)
To: Jon Smirl; +Cc: Linuxppc-dev, Paul Mackerras, i2c
In-Reply-To: <9e4733910807010938w67bab979tfba888641debe72f@mail.gmail.com>
On Tue, 1 Jul 2008 12:38:05 -0400, Jon Smirl wrote:
> On 7/1/08, Jean Delvare <khali@linux-fr.org> wrote:
> > On Tue, 1 Jul 2008 11:12:58 -0400, Jon Smirl wrote:
> > > On 7/1/08, Jean Delvare <khali@linux-fr.org> wrote:
> > > > I'm fine with this patch. In particular, exporting i2c_bus_type is OK.
> > > > It was un-exported only because it had no user left, but it can be
> > > > exported again if needed.
> > >
> > > Another solution would be to move drivers/of/of_i2c into the i2c
> > > directory and make it part of i2c core on powerpc builds.
> >
> > I don't think this is a good idea. Merging arch-specific code (or
> > half-arch-specific code in this case) into arch-neutral drivers ends up
> > being a pain to maintain. People will keep sending me patches for stuff
> > I don't know anything about and can't help with. Having of-specific
> > stuff in just one directory as is the case now sounds much better to
> > me. All it's missing is a MAINTAINERS entry.
>
> A side effect of this is that the small pieces of code in drivers/of
> have to be compiled into stand alone modules and they may need access
> to internal symbols from the subsystem. If they were directly linked
> into the subsystems you wouldn't need to make the internal symbols
> visible.
Do you think you'll need something else than i2c_bus_type? That I don't
consider an i2c-core internal. As I said, the lack of export was simply
due to a lack of user.
> Now the subsystems have to be careful about breaking the
> in-kernel, external users of the symbols
Same holds if the code is merged into i2c-core.
> and we've made it possible for out of tree drivers to get to internal
> structures.
Hopefully the namespaced exports which some kernel developers are
working on, will become a reality soon, to mitigate that kind of issue.
That being said...
As an upstream kernel developer / maintainer, I don't care about that.
If external modules make use of internals they shouldn't touch, and
later changes cause them to break, that's none of my business. I leave
this to distribution maintainers.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
From: Grant Likely @ 2008-07-01 16:45 UTC (permalink / raw)
To: Jean Delvare; +Cc: Linuxppc-dev, Paul Mackerras, i2c
In-Reply-To: <20080701182949.12119d6e@hyperion.delvare>
On Tue, Jul 01, 2008 at 06:29:49PM +0200, Jean Delvare wrote:
> On Tue, 1 Jul 2008 11:12:58 -0400, Jon Smirl wrote:
> > On 7/1/08, Jean Delvare <khali@linux-fr.org> wrote:
> > > I'm fine with this patch. In particular, exporting i2c_bus_type is OK.
> > > It was un-exported only because it had no user left, but it can be
> > > exported again if needed.
> >
> > Another solution would be to move drivers/of/of_i2c into the i2c
> > directory and make it part of i2c core on powerpc builds.
>
> I don't think this is a good idea. Merging arch-specific code (or
> half-arch-specific code in this case) into arch-neutral drivers ends up
> being a pain to maintain. People will keep sending me patches for stuff
> I don't know anything about and can't help with. Having of-specific
> stuff in just one directory as is the case now sounds much better to
> me. All it's missing is a MAINTAINERS entry.
But the other side of the coin is that each driver must have
driver-specific OF code to translate data in the device tree to data
usable by the driver. It doesn't make any sense to me for that stuff to
live anywhere other that with the driver that it supports.
g.
^ permalink raw reply
* RE: [PATCH] powerpc: legacy_serial: reg-offset & shift aren't used
From: Stephen Neuendorffer @ 2008-07-01 16:48 UTC (permalink / raw)
To: John Linn, linuxppc-dev, grant.likely, paulus, benh, dwg, jwboyer
In-Reply-To: <12149299143952-git-send-email-john.linn@xilinx.com>
> -----Original Message-----
> From: John Linn [mailto:john.linn@xilinx.com]
> Sent: Tuesday, July 01, 2008 9:32 AM
> To: linuxppc-dev@ozlabs.org; grant.likely@secretlab.ca;
paulus@samba.org; benh@kernel.crashing.org;
> dwg@au1.ibm.com; jwboyer@linux.vnet.ibm.com; Stephen Neuendorffer
> Cc: John Linn
> Subject: [PATCH] powerpc: legacy_serial: reg-offset & shift aren't
used
> =
> The legacy serial driver does not work with an 8250
> type UART that uses reg-offset and reg-shift. This
> change updates the driver so it doesn't find the UART
> when those properties are present on the UART in the
> device tree for soc devices.
> =
> Signed-off-by: John Linn <john.linn@xilinx.com>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> =
> arch/powerpc/kernel/legacy_serial.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
> =
> diff --git a/arch/powerpc/kernel/legacy_serial.c
b/arch/powerpc/kernel/legacy_serial.c
> index 61dd174..b43235f 100644
> --- a/arch/powerpc/kernel/legacy_serial.c
> +++ b/arch/powerpc/kernel/legacy_serial.c
> @@ -136,6 +136,11 @@ static int __init add_legacy_soc_port(struct
device_node *np,
> if (of_get_property(np, "clock-frequency", NULL) =3D=3D NULL)
> return -1;
> =
> + /* if reg-shift and offset, don't try to use it */
> + if ((of_get_property(np, "reg-shift", NULL) !=3D NULL) &&
> + (of_get_property(np, "reg-offset", NULL) !=3D NULL))
> + return -1;
Um, shouldn't this be || ?
> +
> /* if rtas uses this device, don't try to use it as well */
> if (of_get_property(np, "used-by-rtas", NULL) !=3D NULL)
> return -1;
> --
> 1.5.2.1
> =
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* RE: [PATCH] powerpc: legacy_serial: reg-offset & shift aren't used
From: John Linn @ 2008-07-01 16:52 UTC (permalink / raw)
To: Stephen Neuendorffer, linuxppc-dev, grant.likely, paulus, benh,
dwg, jwboyer
In-Reply-To: <977C41F842E66D4CB2E41332313B6150062A2DB4@XSJ-EXCHVS1.xlnx.xilinx.com>
It could be "||" but I didn't know if there were cases where that
wouldn't be true. I don't know that code that well so I was being
conservative and maybe shouldn't be. =
Our specific case works fine with "&&" since we have both in the device
tree. =
-- John
-----Original Message-----
From: Stephen Neuendorffer =
Sent: Tuesday, July 01, 2008 10:48 AM
To: John Linn; linuxppc-dev@ozlabs.org; grant.likely@secretlab.ca;
paulus@samba.org; benh@kernel.crashing.org; dwg@au1.ibm.com;
jwboyer@linux.vnet.ibm.com
Subject: RE: [PATCH] powerpc: legacy_serial: reg-offset & shift aren't
used
> -----Original Message-----
> From: John Linn [mailto:john.linn@xilinx.com]
> Sent: Tuesday, July 01, 2008 9:32 AM
> To: linuxppc-dev@ozlabs.org; grant.likely@secretlab.ca;
paulus@samba.org; benh@kernel.crashing.org;
> dwg@au1.ibm.com; jwboyer@linux.vnet.ibm.com; Stephen Neuendorffer
> Cc: John Linn
> Subject: [PATCH] powerpc: legacy_serial: reg-offset & shift aren't
used
> =
> The legacy serial driver does not work with an 8250
> type UART that uses reg-offset and reg-shift. This
> change updates the driver so it doesn't find the UART
> when those properties are present on the UART in the
> device tree for soc devices.
> =
> Signed-off-by: John Linn <john.linn@xilinx.com>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> =
> arch/powerpc/kernel/legacy_serial.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
> =
> diff --git a/arch/powerpc/kernel/legacy_serial.c
b/arch/powerpc/kernel/legacy_serial.c
> index 61dd174..b43235f 100644
> --- a/arch/powerpc/kernel/legacy_serial.c
> +++ b/arch/powerpc/kernel/legacy_serial.c
> @@ -136,6 +136,11 @@ static int __init add_legacy_soc_port(struct
device_node *np,
> if (of_get_property(np, "clock-frequency", NULL) =3D=3D NULL)
> return -1;
> =
> + /* if reg-shift and offset, don't try to use it */
> + if ((of_get_property(np, "reg-shift", NULL) !=3D NULL) &&
> + (of_get_property(np, "reg-offset", NULL) !=3D NULL))
> + return -1;
Um, shouldn't this be || ?
> +
> /* if rtas uses this device, don't try to use it as well */
> if (of_get_property(np, "used-by-rtas", NULL) !=3D NULL)
> return -1;
> --
> 1.5.2.1
> =
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
From: Jon Smirl @ 2008-07-01 17:00 UTC (permalink / raw)
To: Grant Likely; +Cc: Jean Delvare, Linuxppc-dev, Paul Mackerras, i2c
In-Reply-To: <20080701164329.GF6918@secretlab.ca>
On 7/1/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Tue, Jul 01, 2008 at 11:12:58AM -0400, Jon Smirl wrote:
> > On 7/1/08, Jean Delvare <khali@linux-fr.org> wrote:
> > > I'm fine with this patch. In particular, exporting i2c_bus_type is OK.
> > > It was un-exported only because it had no user left, but it can be
> > > exported again if needed.
> >
> > Another solution would be to move drivers/of/of_i2c into the i2c
> > directory and make it part of i2c core on powerpc builds.
>
>
> My preference is for things like of_spi and of_i2c to go with the
> related busses; I think it makes more sense to keep all the I2C stuff
> together, but I've already lost that battle once.
>
This is a similar problem to adding aliases to the i2c driver drivers
for the device tree names of the i2c devices. Instead we have code in
drivers/of/of_i2c.c that tries to guess the translation from device
tree to linux names. Adding aliases to the drivers would eliminate the
need for of_find_i2c_driver().
I've previously posted patches implementing device tree names in the
drivers that used ifdef to only instantiate on powerpc builds. For
example....
diff --git a/drivers/i2c/chips/tps65010.c b/drivers/i2c/chips/tps65010.c
index e07274d..9cd1770 100644
--- a/drivers/i2c/chips/tps65010.c
+++ b/drivers/i2c/chips/tps65010.c
@@ -571,6 +571,10 @@ static const struct i2c_device_id tps65010_id[] = {
{ "tps65011", TPS65011 },
{ "tps65012", TPS65012 },
{ "tps65013", TPS65013 },
+ OF_ID("ti,tps65010", TPS65010)
+ OF_ID("ti,tps65011", TPS65011)
+ OF_ID("ti,tps65012", TPS65012)
+ OF_ID("ti,tps65013", TPS65013)
{ },
};
MODULE_DEVICE_TABLE(i2c, tps65010_id);
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply related
* Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
From: Jean Delvare @ 2008-07-01 17:01 UTC (permalink / raw)
To: Grant Likely; +Cc: Linuxppc-dev, Paul Mackerras, i2c
In-Reply-To: <20080701164518.GG6918@secretlab.ca>
On Tue, 1 Jul 2008 10:45:18 -0600, Grant Likely wrote:
> On Tue, Jul 01, 2008 at 06:29:49PM +0200, Jean Delvare wrote:
> > On Tue, 1 Jul 2008 11:12:58 -0400, Jon Smirl wrote:
> > > On 7/1/08, Jean Delvare <khali@linux-fr.org> wrote:
> > > > I'm fine with this patch. In particular, exporting i2c_bus_type is OK.
> > > > It was un-exported only because it had no user left, but it can be
> > > > exported again if needed.
> > >
> > > Another solution would be to move drivers/of/of_i2c into the i2c
> > > directory and make it part of i2c core on powerpc builds.
> >
> > I don't think this is a good idea. Merging arch-specific code (or
> > half-arch-specific code in this case) into arch-neutral drivers ends up
> > being a pain to maintain. People will keep sending me patches for stuff
> > I don't know anything about and can't help with. Having of-specific
> > stuff in just one directory as is the case now sounds much better to
> > me. All it's missing is a MAINTAINERS entry.
>
> But the other side of the coin is that each driver must have
> driver-specific OF code to translate data in the device tree to data
> usable by the driver. It doesn't make any sense to me for that stuff to
> live anywhere other that with the driver that it supports.
This code is glue between OF and subsystems. As with any glue code, you
can argue forever on which side you want to push the code to. Both
answers are valid.
All I see on my personal side is that I don't have any system using OF
and no knowledge about it either, so I can't maintain of_i2c. So having
that file in drivers/of rather than drivers/i2c will make my life
easier for sure. While I'd guess that most (all?) OF-based systems have
an I2C bus, so whoever is responsible for drivers/of should be able to
maintain of_i2c.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH] powerpc: legacy_serial: reg-offset & shift aren't used
From: Grant Likely @ 2008-07-01 17:06 UTC (permalink / raw)
To: John Linn; +Cc: Stephen Neuendorffer, dwg, linuxppc-dev, paulus
In-Reply-To: <20080701165222.991255E0054@mail197-dub.bigfish.com>
On Tue, Jul 01, 2008 at 10:52:20AM -0600, John Linn wrote:
> It could be "||" but I didn't know if there were cases where that
> wouldn't be true. I don't know that code that well so I was being
> conservative and maybe shouldn't be.
No, Stephen is right. It should be ||
g.
^ permalink raw reply
* Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
From: Jon Smirl @ 2008-07-01 17:06 UTC (permalink / raw)
To: Jean Delvare; +Cc: Linuxppc-dev, Paul Mackerras, i2c
In-Reply-To: <20080701190151.76782bbd@hyperion.delvare>
On 7/1/08, Jean Delvare <khali@linux-fr.org> wrote:
> On Tue, 1 Jul 2008 10:45:18 -0600, Grant Likely wrote:
> > On Tue, Jul 01, 2008 at 06:29:49PM +0200, Jean Delvare wrote:
> > > On Tue, 1 Jul 2008 11:12:58 -0400, Jon Smirl wrote:
> > > > On 7/1/08, Jean Delvare <khali@linux-fr.org> wrote:
> > > > > I'm fine with this patch. In particular, exporting i2c_bus_type is OK.
> > > > > It was un-exported only because it had no user left, but it can be
> > > > > exported again if needed.
> > > >
> > > > Another solution would be to move drivers/of/of_i2c into the i2c
> > > > directory and make it part of i2c core on powerpc builds.
> > >
> > > I don't think this is a good idea. Merging arch-specific code (or
> > > half-arch-specific code in this case) into arch-neutral drivers ends up
> > > being a pain to maintain. People will keep sending me patches for stuff
> > > I don't know anything about and can't help with. Having of-specific
> > > stuff in just one directory as is the case now sounds much better to
> > > me. All it's missing is a MAINTAINERS entry.
> >
> > But the other side of the coin is that each driver must have
> > driver-specific OF code to translate data in the device tree to data
> > usable by the driver. It doesn't make any sense to me for that stuff to
> > live anywhere other that with the driver that it supports.
>
>
> This code is glue between OF and subsystems. As with any glue code, you
> can argue forever on which side you want to push the code to. Both
> answers are valid.
>
> All I see on my personal side is that I don't have any system using OF
> and no knowledge about it either, so I can't maintain of_i2c. So having
> that file in drivers/of rather than drivers/i2c will make my life
> easier for sure. While I'd guess that most (all?) OF-based systems have
> an I2C bus, so whoever is responsible for drivers/of should be able to
> maintain of_i2c.
We could modify the Makefile for i2c core to get the source out of
drivers/of and link it into i2c-core. That would remove the need to
export symbols.
Or you could move the file into the i2c directory and just put a note
on it that Grant is the maintainer.
>
> --
>
> Jean Delvare
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* RE: [PATCH] powerpc: legacy_serial: reg-offset & shift aren't used
From: John Linn @ 2008-07-01 17:07 UTC (permalink / raw)
To: Grant Likely; +Cc: Stephen Neuendorffer, dwg, linuxppc-dev, paulus
In-Reply-To: <20080701170628.GA10912@secretlab.ca>
I'll respin the patch and send again.
-- John
-----Original Message-----
From: Grant Likely [mailto:glikely@secretlab.ca] On Behalf Of Grant
Likely
Sent: Tuesday, July 01, 2008 11:06 AM
To: John Linn
Cc: Stephen Neuendorffer; linuxppc-dev@ozlabs.org; paulus@samba.org;
benh@kernel.crashing.org; dwg@au1.ibm.com; jwboyer@linux.vnet.ibm.com
Subject: Re: [PATCH] powerpc: legacy_serial: reg-offset & shift aren't
used
On Tue, Jul 01, 2008 at 10:52:20AM -0600, John Linn wrote:
> It could be "||" but I didn't know if there were cases where that
> wouldn't be true. I don't know that code that well so I was being
> conservative and maybe shouldn't be. =
No, Stephen is right. It should be ||
g.
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
From: Jean Delvare @ 2008-07-01 17:12 UTC (permalink / raw)
To: Jon Smirl; +Cc: Linuxppc-dev, Paul Mackerras, i2c
In-Reply-To: <9e4733910807011000t67e3abe5kb39302e911558dad@mail.gmail.com>
On Tue, 1 Jul 2008 13:00:08 -0400, Jon Smirl wrote:
> On 7/1/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> > My preference is for things like of_spi and of_i2c to go with the
> > related busses; I think it makes more sense to keep all the I2C stuff
> > together, but I've already lost that battle once.
>
> This is a similar problem to adding aliases to the i2c driver drivers
> for the device tree names of the i2c devices. Instead we have code in
> drivers/of/of_i2c.c that tries to guess the translation from device
> tree to linux names. Adding aliases to the drivers would eliminate the
> need for of_find_i2c_driver().
>
> I've previously posted patches implementing device tree names in the
> drivers that used ifdef to only instantiate on powerpc builds. For
> example....
>
> diff --git a/drivers/i2c/chips/tps65010.c b/drivers/i2c/chips/tps65010.c
> index e07274d..9cd1770 100644
> --- a/drivers/i2c/chips/tps65010.c
> +++ b/drivers/i2c/chips/tps65010.c
> @@ -571,6 +571,10 @@ static const struct i2c_device_id tps65010_id[] = {
> { "tps65011", TPS65011 },
> { "tps65012", TPS65012 },
> { "tps65013", TPS65013 },
> + OF_ID("ti,tps65010", TPS65010)
> + OF_ID("ti,tps65011", TPS65011)
> + OF_ID("ti,tps65012", TPS65012)
> + OF_ID("ti,tps65013", TPS65013)
> { },
> };
> MODULE_DEVICE_TABLE(i2c, tps65010_id);
Yeah, yeah, you've been asking for this for months already, but it's
just not going to happen, sorry. You want to abuse the standard Linux
alias mechanism for your personal (i.e. openfirmware) use, but that's
bad. Linux drivers shouldn't have to know whether they are used in
openfirmware trees and what device names are used there. And device
names as seen by user-space shouldn't vary depending on whether the
device comes from an openfirmware tree or not - otherwise all
user-space apps need to learn about both naming conversions.
Unsurprisingly, no other subsystem does what you propose.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
From: Jon Smirl @ 2008-07-01 17:27 UTC (permalink / raw)
To: Jean Delvare; +Cc: Linuxppc-dev, Paul Mackerras, i2c
In-Reply-To: <20080701191224.10ed2437@hyperion.delvare>
On 7/1/08, Jean Delvare <khali@linux-fr.org> wrote:
> On Tue, 1 Jul 2008 13:00:08 -0400, Jon Smirl wrote:
> > On 7/1/08, Grant Likely <grant.likely@secretlab.ca> wrote:
>
> > > My preference is for things like of_spi and of_i2c to go with the
> > > related busses; I think it makes more sense to keep all the I2C stuff
> > > together, but I've already lost that battle once.
> >
> > This is a similar problem to adding aliases to the i2c driver drivers
> > for the device tree names of the i2c devices. Instead we have code in
> > drivers/of/of_i2c.c that tries to guess the translation from device
> > tree to linux names. Adding aliases to the drivers would eliminate the
> > need for of_find_i2c_driver().
> >
> > I've previously posted patches implementing device tree names in the
> > drivers that used ifdef to only instantiate on powerpc builds. For
> > example....
> >
> > diff --git a/drivers/i2c/chips/tps65010.c b/drivers/i2c/chips/tps65010.c
> > index e07274d..9cd1770 100644
> > --- a/drivers/i2c/chips/tps65010.c
> > +++ b/drivers/i2c/chips/tps65010.c
> > @@ -571,6 +571,10 @@ static const struct i2c_device_id tps65010_id[] = {
> > { "tps65011", TPS65011 },
> > { "tps65012", TPS65012 },
> > { "tps65013", TPS65013 },
> > + OF_ID("ti,tps65010", TPS65010)
> > + OF_ID("ti,tps65011", TPS65011)
> > + OF_ID("ti,tps65012", TPS65012)
> > + OF_ID("ti,tps65013", TPS65013)
> > { },
> > };
> > MODULE_DEVICE_TABLE(i2c, tps65010_id);
>
>
> Yeah, yeah, you've been asking for this for months already, but it's
> just not going to happen, sorry. You want to abuse the standard Linux
> alias mechanism for your personal (i.e. openfirmware) use, but that's
> bad. Linux drivers shouldn't have to know whether they are used in
> openfirmware trees and what device names are used there. And device
> names as seen by user-space shouldn't vary depending on whether the
> device comes from an openfirmware tree or not - otherwise all
> user-space apps need to learn about both naming conversions.
>
> Unsurprisingly, no other subsystem does what you propose.
Then what are all of the PCI aliases doing?
The only difference is that you are recognizing the PCI group as a
naming authority and not recognizing the PowerPC device tree group.
But on the PowerPC platform that is our naming authority. That's why I
proposed adding the names on ifdefs so that they disappear on non
PowerPC platforms.
PS - adding an alias to a driver does not change the name of the
driver. My PCI e1000 module has about 100 aliases but it is always
e1000.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] [V2] powerpc: legacy_serial: reg-offset & shift aren't used
From: John Linn @ 2008-07-01 17:52 UTC (permalink / raw)
To: linuxppc-dev; +Cc: dwg, paulus, John Linn
The legacy serial driver does not work with an 8250
type UART that uses reg-offset and reg-shift. This
change updates the driver so it doesn't find the UART
when those properties are present on the UART in the
device tree for soc devices.
Signed-off-by: John Linn <john.linn@xilinx.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
---
V2
Corrected logic to use "||" rather than "&&".
arch/powerpc/kernel/legacy_serial.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
index 61dd174..cf37f5c 100644
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -136,6 +136,11 @@ static int __init add_legacy_soc_port(struct device_node *np,
if (of_get_property(np, "clock-frequency", NULL) == NULL)
return -1;
+ /* if reg-shift or offset, don't try to use it */
+ if ((of_get_property(np, "reg-shift", NULL) != NULL) ||
+ (of_get_property(np, "reg-offset", NULL) != NULL))
+ return -1;
+
/* if rtas uses this device, don't try to use it as well */
if (of_get_property(np, "used-by-rtas", NULL) != NULL)
return -1;
--
1.5.2.1
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply related
* Re: [PATCH] IB/ehca: Make device table externally visible
From: Roland Dreier @ 2008-07-01 17:55 UTC (permalink / raw)
To: Joachim Fenkes
Cc: LKML, OF-EWG, LinuxPPC-Dev, Christoph Raisch, OF-General,
Stefan Roscher
In-Reply-To: <200807011614.19670.fenkes@de.ibm.com>
thanks, applied
^ permalink raw reply
* [RFC/PATCH] powerpc/bootwrapper: Allow user to specify additional default targets
From: Grant Likely @ 2008-07-01 17:59 UTC (permalink / raw)
To: linuxppc-dev, john.linn
From: Grant Likely <grant.likely@secretlab.ca>
It is inconvenient to add additional default targets to the bootwrapper
Makefile for each new board supported which just needs a different dts
file. This change allows the defconfig to specify additional build
targets.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/Kconfig | 13 +++++++++++++
arch/powerpc/boot/Makefile | 3 +++
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 3934e26..f09f617 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -458,6 +458,19 @@ config CMDLINE
some command-line options at build time by entering them here. In
most cases you will need to specify the root device here.
+config EXTRA_TARGETS
+ string "Additional default image types"
+ help
+ List additional targets to be built by the bootwrapper here (separated
+ by spaces). This is useful for targets that depend of device tree
+ files in the .dts directory.
+
+ Targets in this list will be build as part of the default build
+ target, or when the user does a 'make zImage' or a
+ 'make zImage.initrd'.
+
+ If unsure, leave blank
+
if !44x || BROKEN
config ARCH_WANTS_FREEZER_CONTROL
def_bool y
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 1cee2f9..1e38237 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -270,6 +270,9 @@ ifeq ($(CONFIG_PPC32),y)
image-$(CONFIG_PPC_PMAC) += zImage.coff zImage.miboot
endif
+# Allow extra targets to be added to the defconfig
+image-y += $(subst ",,$(CONFIG_EXTRA_TARGETS))
+
initrd- := $(patsubst zImage%, zImage.initrd%, $(image-n) $(image-))
initrd-y := $(patsubst zImage%, zImage.initrd%, \
$(patsubst dtbImage%, dtbImage.initrd%, \
^ permalink raw reply related
* Re: [PATCH v2] Parameterize EMAC Multicast Match Handling
From: Grant Erickson @ 2008-07-01 18:13 UTC (permalink / raw)
To: Stefan Roese, benh; +Cc: linuxppc-dev
In-Reply-To: <200807010837.45282.sr@denx.de>
On 6/30/08 11:37 PM, Stefan Roese wrote:
> On Tuesday 01 July 2008, Benjamin Herrenschmidt wrote:
>>> Stefan and/or Ben:
>>>
>>> Any thoughts on this?
>>
>> I was hesitating a bit... do we really need to be -that- flexible ?
>>
>> That is, either that or use some new compatible entry to detect the new
>> reg layout and whack that as a feature bit instead ? The advantage
>> of the later is that we have the possibility of doing conditional
>> compile for kernels that support only a given processor or set of
>> processors (not that we have implemented much of it, but it just
>> becomes Kconfig mumbo jumbo and a little bit of defines in the .h
>> by turning the feature test into a compile-time 0 or 1.
>>
>> But this isn't a hot path and not a lot of code so maybe not worth
>> bothering... however, it does add 3 properties to the DT and I know
>> embedded people (especially Xilinx) are a bit concerned about the size
>> of the DT when they try to fit it in block RAM...
>
> Yes, this was my feeling too. Not the size of the dtb but more the increased
> complexity of the EMAC device node. I would prefer Ben's idea with this new
> compatible entry too.
In terms of the device tree expression, you would both favor something akin
to the following?
- compatible = "ibm,emac-405exr", "ibm,emac4";
+ compatible = "ibm,emac-405exr", "ibm,emac4", "ibm,emac4sync";
Regards,
Grant
^ permalink raw reply
* [patch] PS3: Quiet system bus match output
From: Geoff Levand @ 2008-07-01 18:17 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev@ozlabs.org
Reduce the output verbosity of ps3_system_bus_match().
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
Paul,
Please queue for 2.6.27.
-Geoff
arch/powerpc/platforms/ps3/system-bus.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
--- a/arch/powerpc/platforms/ps3/system-bus.c
+++ b/arch/powerpc/platforms/ps3/system-bus.c
@@ -349,9 +349,14 @@ static int ps3_system_bus_match(struct d
result = dev->match_id == drv->match_id;
- pr_info("%s:%d: dev=%u(%s), drv=%u(%s): %s\n", __func__, __LINE__,
- dev->match_id, dev->core.bus_id, drv->match_id, drv->core.name,
- (result ? "match" : "miss"));
+ if (result)
+ pr_info("%s:%d: dev=%u(%s), drv=%u(%s): match\n", __func__,
+ __LINE__, dev->match_id, dev->core.bus_id,
+ drv->match_id, drv->core.name);
+ else
+ pr_debug("%s:%d: dev=%u(%s), drv=%u(%s): miss\n", __func__,
+ __LINE__, dev->match_id, dev->core.bus_id,
+ drv->match_id, drv->core.name);
return result;
}
@@ -362,7 +367,7 @@ static int ps3_system_bus_probe(struct d
struct ps3_system_bus_driver *drv;
BUG_ON(!dev);
- pr_info(" -> %s:%d: %s\n", __func__, __LINE__, _dev->bus_id);
+ pr_debug(" -> %s:%d: %s\n", __func__, __LINE__, _dev->bus_id);
drv = ps3_system_bus_dev_to_system_bus_drv(dev);
BUG_ON(!drv);
@@ -370,10 +375,10 @@ static int ps3_system_bus_probe(struct d
if (drv->probe)
result = drv->probe(dev);
else
- pr_info("%s:%d: %s no probe method\n", __func__, __LINE__,
+ pr_debug("%s:%d: %s no probe method\n", __func__, __LINE__,
dev->core.bus_id);
- pr_info(" <- %s:%d: %s\n", __func__, __LINE__, dev->core.bus_id);
+ pr_debug(" <- %s:%d: %s\n", __func__, __LINE__, dev->core.bus_id);
return result;
}
@@ -384,7 +389,7 @@ static int ps3_system_bus_remove(struct
struct ps3_system_bus_driver *drv;
BUG_ON(!dev);
- pr_info(" -> %s:%d: %s\n", __func__, __LINE__, _dev->bus_id);
+ pr_debug(" -> %s:%d: %s\n", __func__, __LINE__, _dev->bus_id);
drv = ps3_system_bus_dev_to_system_bus_drv(dev);
BUG_ON(!drv);
@@ -395,7 +400,7 @@ static int ps3_system_bus_remove(struct
dev_dbg(&dev->core, "%s:%d %s: no remove method\n",
__func__, __LINE__, drv->core.name);
- pr_info(" <- %s:%d: %s\n", __func__, __LINE__, dev->core.bus_id);
+ pr_debug(" <- %s:%d: %s\n", __func__, __LINE__, dev->core.bus_id);
return result;
}
^ permalink raw reply
* Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
From: Jon Smirl @ 2008-07-01 18:18 UTC (permalink / raw)
To: Jean Delvare; +Cc: Linuxppc-dev, Paul Mackerras, i2c
In-Reply-To: <9e4733910807011027m5802cf76n3f68b8692ff6832f@mail.gmail.com>
On 7/1/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 7/1/08, Jean Delvare <khali@linux-fr.org> wrote:
>
> > On Tue, 1 Jul 2008 13:00:08 -0400, Jon Smirl wrote:
> > > On 7/1/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> >
> > > > My preference is for things like of_spi and of_i2c to go with the
> > > > related busses; I think it makes more sense to keep all the I2C stuff
> > > > together, but I've already lost that battle once.
> > >
> > > This is a similar problem to adding aliases to the i2c driver drivers
> > > for the device tree names of the i2c devices. Instead we have code in
> > > drivers/of/of_i2c.c that tries to guess the translation from device
> > > tree to linux names. Adding aliases to the drivers would eliminate the
> > > need for of_find_i2c_driver().
> > >
> > > I've previously posted patches implementing device tree names in the
> > > drivers that used ifdef to only instantiate on powerpc builds. For
> > > example....
> > >
> > > diff --git a/drivers/i2c/chips/tps65010.c b/drivers/i2c/chips/tps65010.c
> > > index e07274d..9cd1770 100644
> > > --- a/drivers/i2c/chips/tps65010.c
> > > +++ b/drivers/i2c/chips/tps65010.c
> > > @@ -571,6 +571,10 @@ static const struct i2c_device_id tps65010_id[] = {
> > > { "tps65011", TPS65011 },
> > > { "tps65012", TPS65012 },
> > > { "tps65013", TPS65013 },
> > > + OF_ID("ti,tps65010", TPS65010)
> > > + OF_ID("ti,tps65011", TPS65011)
> > > + OF_ID("ti,tps65012", TPS65012)
> > > + OF_ID("ti,tps65013", TPS65013)
> > > { },
> > > };
> > > MODULE_DEVICE_TABLE(i2c, tps65010_id);
> >
> >
> > Yeah, yeah, you've been asking for this for months already, but it's
> > just not going to happen, sorry. You want to abuse the standard Linux
> > alias mechanism for your personal (i.e. openfirmware) use, but that's
> > bad. Linux drivers shouldn't have to know whether they are used in
> > openfirmware trees and what device names are used there. And device
> > names as seen by user-space shouldn't vary depending on whether the
> > device comes from an openfirmware tree or not - otherwise all
> > user-space apps need to learn about both naming conversions.
> >
> > Unsurprisingly, no other subsystem does what you propose.
>
>
> Then what are all of the PCI aliases doing?
>
> The only difference is that you are recognizing the PCI group as a
> naming authority and not recognizing the PowerPC device tree group.
> But on the PowerPC platform that is our naming authority. That's why I
> proposed adding the names on ifdefs so that they disappear on non
> PowerPC platforms.
>
> PS - adding an alias to a driver does not change the name of the
> driver. My PCI e1000 module has about 100 aliases but it is always
> e1000.
Here's my e1000e sysfs entry:
jonsmirl@terra:/sys/bus/pci/devices/0000:00:19.0$ ls
broken_parity_status device local_cpus power resource2 uevent
bus driver modalias resource subsystem vendor
class enable msi_bus resource0 subsystem_device
config irq net:eth0 resource1 subsystem_vendor
jonsmirl@terra:/sys/bus/pci/devices/0000:00:19.0$ cat modalias
pci:v00008086d0000104Bsv00001028sd000001DBbc02sc00i00
>>>> This is the module alias that was used to load the driver.
jonsmirl@terra:/sys/bus/pci/devices/0000:00:19.0$ ls -l driver
lrwxrwxrwx 1 root root 0 2008-07-01 08:52 driver ->
../../../bus/pci/drivers/e1000e
>>>> The driver is always e1000e no matter which alias was used to load it. "e1000e" is controled by the name field of the driver structure. That's the publicly visible name for the driver.
>>>> Adding the OF aliases would change the modalias entry, not the driver name.
The i2c implementation is adding a field to a device entry that
contains the driver name. No other device drivers I could find do
this.
jonsmirl@terra:/sys/bus/i2c/devices/1-0050$ ls
bus driver eeprom modalias name power subsystem uevent
jonsmirl@terra:/sys/bus/i2c/devices/1-0050$ cat name
eeprom
jonsmirl@terra:/sys/bus/i2c/devices/1-0050$ ls -l driver
lrwxrwxrwx 1 root root 0 2008-07-01 14:05 driver ->
../../../../bus/i2c/drivers/eeprom
jonsmirl@terra:/sys/bus/i2c/devices/1-0050$ cat modalias
jonsmirl@terra:/sys/bus/i2c/devices/1-0050$
I believe the correct way to get the driver name from sysfs is to
follow the driver link. The name field is probably legacy. Other
drivers in the system don't have a name entry on the device node.
Is the user space i2c code looking at the modalias entry?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox