is there still any need PPC checking for "chosen@0"?
given that there are no .dts files in the current kernel code base
that define the node name "/chosen@0" instead of the proper "/chosen",
is there any need for arch/powerpc/boot/oflib.c to still make this
test:
chosen = of_finddevice("/chosen");
if (chosen == (phandle) -1) {
chosen = of_finddevice("/chosen@0"); <--- this
if (chosen == (phandle) -1) {
printf("no chosen\n");
return 0;
}
}
are there still PPC machines that require the recognition of
"/chosen@0"?
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
Re: [PATCH] devicetree: Remove remaining references/tests for "chosen@0"
On Tue, 5 Sep 2017, Rob Herring wrote: > On Sun, Sep 3, 2017 at 5:43 AM, Robert P. J. Day <rpj...@crashcourse.ca> > wrote: > > On Sun, 3 Sep 2017, Benjamin Herrenschmidt wrote: > > > >> On Sat, 2017-09-02 at 04:43 -0400, Robert P. J. Day wrote: > >> > Since, according to a recent devicetree ML posting by Rob Herring, > >> > the node "/chosen@0" is most likely for real Open Firmware and > >> > does not apply to DTSpec, remove all remaining tests and > >> > references for that node, of which there are very few left: > >> > >> Technically that would break Open Firmware systems where the node is > >> really called chosen@0 > >> > >> Now I'm not sure such a thing actually exist however. > >> > >> My collection of DTs don't seem to have one, except in the ancient > >> html variants that were extracted by the pengionppc folks for the > >> original PowerMac 8600 but I wonder if that's a bug in the > >> extraction script since they also have @0 on /packages etc... > > > > obviously, this isn't a priority issue, i was just working off a > > comment by rob herring that "chosen@0" is not defined by the current > > DTSpec 0.1, so it seemed appropriate to toss it. if there's a reason > > to hang onto it, that's fine with me. > > > > however, given the diff stat of the change to remove every single > > reference to that node name in the current kernel source: > > > > arch/microblaze/kernel/prom.c | 3 +-- > > arch/mips/generic/yamon-dt.c | 4 > > arch/powerpc/boot/oflib.c | 7 ++- > > drivers/of/base.c | 2 -- > > drivers/of/fdt.c | 5 + > > 5 files changed, 4 insertions(+), 17 deletions(-) > > > > it seems inconsistent that three architectures would be testing for > > that node, but none of the rest. consistency suggests that every > > architecture should take it into account, or none should. > > I generally agree and have moved various things from arch to > drivers/of/ to ensure that. But for legacy things, we have to allow > for exceptions. I agree with Ben and think that microblaze (they > generally just copied PPC), MIPS, and the FDT code in drivers/of/ can > be changed. i'm not quite sure what people have agreed on, so i'll just leave it in the hands of others here to submit patches for what they think is appropriate. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: [PATCH] devicetree: Remove remaining references/tests for "chosen@0"
On Sun, 3 Sep 2017, Benjamin Herrenschmidt wrote: > On Sat, 2017-09-02 at 04:43 -0400, Robert P. J. Day wrote: > > Since, according to a recent devicetree ML posting by Rob Herring, > > the node "/chosen@0" is most likely for real Open Firmware and > > does not apply to DTSpec, remove all remaining tests and > > references for that node, of which there are very few left: > > Technically that would break Open Firmware systems where the node is > really called chosen@0 > > Now I'm not sure such a thing actually exist however. > > My collection of DTs don't seem to have one, except in the ancient > html variants that were extracted by the pengionppc folks for the > original PowerMac 8600 but I wonder if that's a bug in the > extraction script since they also have @0 on /packages etc... obviously, this isn't a priority issue, i was just working off a comment by rob herring that "chosen@0" is not defined by the current DTSpec 0.1, so it seemed appropriate to toss it. if there's a reason to hang onto it, that's fine with me. however, given the diff stat of the change to remove every single reference to that node name in the current kernel source: arch/microblaze/kernel/prom.c | 3 +-- arch/mips/generic/yamon-dt.c | 4 arch/powerpc/boot/oflib.c | 7 ++- drivers/of/base.c | 2 -- drivers/of/fdt.c | 5 + 5 files changed, 4 insertions(+), 17 deletions(-) it seems inconsistent that three architectures would be testing for that node, but none of the rest. consistency suggests that every architecture should take it into account, or none should. anyway, not a big deal, i'm fine with any decision. rday -- ============ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
[PATCH] devicetree: Remove remaining references/tests for "chosen@0"
Since, according to a recent devicetree ML posting by Rob Herring,
the node "/chosen@0" is most likely for real Open Firmware and does
not apply to DTSpec, remove all remaining tests and references for
that node, of which there are very few left:
arch/microblaze/kernel/prom.c | 3 +--
arch/mips/generic/yamon-dt.c | 4
arch/powerpc/boot/oflib.c | 7 ++-
drivers/of/base.c | 2 --
drivers/of/fdt.c | 5 +
5 files changed, 4 insertions(+), 17 deletions(-)
This should be innocuous as, in all of the three arch/ files above,
there is a test for "chosen" immediately before the test for
"chosen@0", so nothing should change.
Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca>
---
if this patch is premature, then just ignore it, thanks.
diff --git a/arch/microblaze/kernel/prom.c b/arch/microblaze/kernel/prom.c
index 68f0999..c81bfd7 100644
--- a/arch/microblaze/kernel/prom.c
+++ b/arch/microblaze/kernel/prom.c
@@ -53,8 +53,7 @@ static int __init early_init_dt_scan_chosen_serial(unsigned
long node,
pr_debug("%s: depth: %d, uname: %s\n", __func__, depth, uname);
- if (depth == 1 && (strcmp(uname, "chosen") == 0 ||
- strcmp(uname, "chosen@0") == 0)) {
+ if (depth == 1 && (strcmp(uname, "chosen") == 0)) {
p = of_get_flat_dt_prop(node, "linux,stdout-path", );
if (p != NULL && l > 0)
stdout = p; /* store pointer to stdout-path */
diff --git a/arch/mips/generic/yamon-dt.c b/arch/mips/generic/yamon-dt.c
index 6077bca..3a241b2 100644
--- a/arch/mips/generic/yamon-dt.c
+++ b/arch/mips/generic/yamon-dt.c
@@ -28,8 +28,6 @@ __init int yamon_dt_append_cmdline(void *fdt)
/* find or add chosen node */
chosen_off = fdt_path_offset(fdt, "/chosen");
if (chosen_off == -FDT_ERR_NOTFOUND)
- chosen_off = fdt_path_offset(fdt, "/chosen@0");
- if (chosen_off == -FDT_ERR_NOTFOUND)
chosen_off = fdt_add_subnode(fdt, 0, "chosen");
if (chosen_off < 0) {
pr_err("Unable to find or add DT chosen node: %d\n",
@@ -221,8 +219,6 @@ __init int yamon_dt_serial_config(void *fdt)
/* find or add chosen node */
chosen_off = fdt_path_offset(fdt, "/chosen");
if (chosen_off == -FDT_ERR_NOTFOUND)
- chosen_off = fdt_path_offset(fdt, "/chosen@0");
- if (chosen_off == -FDT_ERR_NOTFOUND)
chosen_off = fdt_add_subnode(fdt, 0, "chosen");
if (chosen_off < 0) {
pr_err("Unable to find or add DT chosen node: %d\n",
diff --git a/arch/powerpc/boot/oflib.c b/arch/powerpc/boot/oflib.c
index 46c98a4..a01471f 100644
--- a/arch/powerpc/boot/oflib.c
+++ b/arch/powerpc/boot/oflib.c
@@ -131,11 +131,8 @@ static int check_of_version(void)
return 0;
chosen = of_finddevice("/chosen");
if (chosen == (phandle) -1) {
- chosen = of_finddevice("/chosen@0");
- if (chosen == (phandle) -1) {
- printf("no chosen\n");
- return 0;
- }
+ printf("no chosen\n");
+ return 0;
}
if (of_getprop(chosen, "mmu", _mmu, sizeof(chosen_mmu)) <= 0) {
printf("no mmu\n");
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 686628d..e0f636d 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1659,8 +1659,6 @@ void of_alias_scan(void * (*dt_alloc)(u64 size, u64
align))
of_aliases = of_find_node_by_path("/aliases");
of_chosen = of_find_node_by_path("/chosen");
- if (of_chosen == NULL)
- of_chosen = of_find_node_by_path("/chosen@0");
if (of_chosen) {
/* linux,stdout-path and /aliases/stdout are for legacy
compatibility */
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index ce30c9a..0b0a709 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -980,8 +980,6 @@ int __init early_init_dt_scan_chosen_stdout(void)
offset = fdt_path_offset(fdt, "/chosen");
if (offset < 0)
- offset = fdt_path_offset(fdt, "/chosen@0");
- if (offset < 0)
return -ENOENT;
p = fdt_getprop(fdt, offset, "stdout-path", );
@@ -1117,8 +1115,7 @@ int __init early_init_dt_scan_chosen(unsigned long node,
const char *uname,
pr_debug("search \"chosen\", depth: %d, uname: %s\n", depth, uname);
- if (depth != 1 || !data ||
- (strcmp(uname, "chosen") != 0 && strcmp(uname, "chosen@0") != 0))
+ if (depth != 1 || !d
[PATCH] arch/powerpc: Standardize DTS status assignments from "ok" to "okay"
While the current kernel drivers/of/ code allows developers to be
sloppy and use a DTS status value of "ok", the current DTSpec 0.1
makes it clear that the proper spelling is "okay", so fix the small
number of PowerPC .dts files that do this.
Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca>
---
diff --git a/arch/powerpc/boot/dts/akebono.dts
b/arch/powerpc/boot/dts/akebono.dts
index e61d5dc..660ee21 100644
--- a/arch/powerpc/boot/dts/akebono.dts
+++ b/arch/powerpc/boot/dts/akebono.dts
@@ -40,7 +40,7 @@
d-cache-size = <32768>;
dcr-controller;
dcr-access-method = "native";
- status = "ok";
+ status = "okay";
};
cpu@1 {
device_type = "cpu";
diff --git a/arch/powerpc/boot/dts/bluestone.dts
b/arch/powerpc/boot/dts/bluestone.dts
index b0b26d8..64eaf7e 100644
--- a/arch/powerpc/boot/dts/bluestone.dts
+++ b/arch/powerpc/boot/dts/bluestone.dts
@@ -109,7 +109,7 @@
OCM: ocm@40004 {
compatible = "ibm,ocm";
- status = "ok";
+ status = "okay";
cell-index = <1>;
/* configured in U-Boot */
reg = <4 0x0004 0x8000>; /* 32K */
diff --git a/arch/powerpc/boot/dts/currituck.dts
b/arch/powerpc/boot/dts/currituck.dts
index 4191e18..093c4bc 100644
--- a/arch/powerpc/boot/dts/currituck.dts
+++ b/arch/powerpc/boot/dts/currituck.dts
@@ -39,7 +39,7 @@
d-cache-size = <32768>;
dcr-controller;
dcr-access-method = "native";
- status = "ok";
+ status = "okay";
};
cpu@1 {
device_type = "cpu";
diff --git a/arch/powerpc/boot/dts/iss4xx-mpic.dts
b/arch/powerpc/boot/dts/iss4xx-mpic.dts
index 23e9d9b..9804ada 100644
--- a/arch/powerpc/boot/dts/iss4xx-mpic.dts
+++ b/arch/powerpc/boot/dts/iss4xx-mpic.dts
@@ -43,7 +43,7 @@
d-cache-size = <32768>;
dcr-controller;
dcr-access-method = "native";
- status = "ok";
+ status = "okay";
};
cpu@1 {
device_type = "cpu";
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
how can i see the *actual* bus and brg frequencies on running system?
i asked about this a while ago, didn't see any response, and i'm still curious ... i have an MPC8360 system, ported u-boot to it, and in the dts file i got from someone, the bus and brg frequencies were set to lower values than they should have been, but we left them there and, once the system was up, i tried to check what the *actual* frequencies were being used. i checked under both /proc/device-tree, and way down under /sys, and both showed lower frequencies, but one of the embedded guys wrote a utility to read the actual PPC register that contained the bus frequency, and assured us it was running at 533MHz, which is what we wanted all along. so dts stuff aside, is there a simple user space way to display the frequencies that are actually being used on the system? because it appears that what's under both /proc and /sys are showing only what is set in the device tree blob passed to the kernel, but that's not where the kernel is getting the final value from. rday p.s. we got the BSP for this board from elsewhere, so it's possible that during kernel boot, the kernel has been patched to ignore what it sees in the DTB, and gets the value from somewhere unique to this BSP. but still, if that's the case, should it not still be possible to view the frequency that was finally set and used on the running system? -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0213/1529] Fix typo
On Mon, 23 May 2016, Russell Currey wrote: > On Sat, 2016-05-21 at 14:03 +0200, Andrea Gelmini wrote: > > Signed-off-by: Andrea Gelmini <andrea.gelm...@gelma.net> > > --- > > This entire comment needs to be rewritten as it's incredibly confusing, but > alas > > Acked-by: Russell Currey <rus...@russell.cc> > > > arch/powerpc/include/asm/eeh.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h > > index fb9f376..7d34f3d 100644 > > --- a/arch/powerpc/include/asm/eeh.h > > +++ b/arch/powerpc/include/asm/eeh.h > > @@ -57,7 +57,7 @@ struct pci_dn; > > /* > > * The struct is used to trace PE related EEH functionality. > > * In theory, there will have one instance of the struct to "there will have one instance"? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0218/1529] Fix typo
really? you're going to submit 1,529 individual typo fixes? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
for muram in DTS file, why change #address-cells from <1> to <2>?
currently working on a project involving MPC8360 board, and was
handed a patch to the system .dts file that contained the following
snippet for the muram node:
muram@1 {
- #address-cells = <1>;
+ #address-cells = <2>;
#size-cells = <1>;
compatible = "fsl,qe-muram", "fsl,cpm-muram";
- ranges = <0 0x1 0xc000>;
+ ranges = <0 0 0x1 0xc000>;
data-only@0 {
compatible =
"fsl,qe-muram-data","fsl,cpm-muram-data";
- reg = <0 0xc000>;
+ reg = <0 0x4000 0x4000>, <0 0x9400 0x1c00>;
};
};
i'm not a .dts file expert, but i'm baffled by the change in the
value of #address-cells. how does that make any sense? it seems to me
that that kind of change is a *really* fundamental change in the
specification of the underlying architecture.
can someone explain what that might mean? thanks.
rday
--
====
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
on a MPC8360 system, how can i read the *actual* bus frequencies?
bit of a conundrum here ... we have a legacy MPC8360 system here, on which we installed linux built with wind river linux 8. we obviously want to push the various bus frequencies to their max for best performance, and the device tree that was being used for this system assigned rather slow speeds (266MHz) for the various buses. i wasn't sure how to view the bus frequencies that were *actually* being used. first, i thought that anything you found under /proc/devicetree simply showed the device tree values as they were passed to the kernel, so i wasn't going to trust those. also, i thought that anything under /sys would show the genuine frequency values and, after searching, i found various PPC bus frequencies under /sys/firmware/..., but they *also* showed fairly slow speeds. finally, someone wrote a program that read directly from the system registers: tempVal = *M83XX_SPMR(vxCCSBARGet()); lbcm = M83XX_SPMR_LBCM_VAL(tempVal); ddrcm = M83XX_SPMR_DDRCM_VAL(tempVal); spmf = M83XX_SPMR_SPMF_VAL(tempVal); clkDiv = M83XX_SPMR_CLKID_VAL(tempVal); corePll = M83XX_SPMR_COREPLL_VAL(tempVal); cepdf = M83XX_SPMR_CEPDF_VAL(tempVal); cepmf = M83XX_SPMR_CEPMF_VAL(tempVal); which, surprisingly, showed what appears to be the maximum allowable bus frequencies; for example Enter mcd command -> sysGetCoreSpeed value = 52800 = 0x1fca0340 so i'm willing to believe that the system really is running at max speed, but is there no easier way to see the bus frequencies that are actually in use, rather than having to dig into the system registers? why would the values under /sys not reflect the actual bus frequencies, and not (as it appears) just the ones passed to the kernel which were obviously not used? rday -- ==== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
followup: kernel manipulation of {bus,brg}-frequency for MPC8360?
followup to earlier post and WARNING -- my ppc dev box is suddenly
off the net so i'm doing all this from memory. le *sigh*.
again in context of porting linux (4.1 kernel, using v2015.10 uboot)
to MPC8360 target, a couple of questions.
first, while in this case u-boot might be modifying some of the
values in the DTB before passing it to the kernel, is it true that the
contents of the /proc/devicetree directory on the running linux system
represent the DTB as it was passed from u-boot, or after it was
possibly modified by the PPC kernel boot code? (clearly, this isn't
exclusively a PPC issue -- it's a more general device tree issue.)
second (and more involved) question, i noticed pretty quickly that
the two frequency values i was interested in were visible under /sys
... from memory, /sys/firmware(?).../ and so on. i also noticed they
were stored in internal format so i needed to run them through
"hexdump" to get their values, no problem.
i'm assuming *those* values for {bus,brg}-frequency visible under
/sys *are* the final values, after possible processing by the kernel
boot code. in my case (MPC8360), which ppc boot files are responsible
for checking the values passed in the DTB and possibly adjusting them
early in the boot process?
not looking for extensive explanation, i already see what look like
potentially relevant files under arch/powerpc:
* sysdev/fsl_soc.c
* sysdev/qe_lib/qe.c
* boot/devtree.c
am i at least looking in the right place? thanks.
rday
p.s. if there is something online that addresses the values of
bus-frequency and brg-frequency that's relevant, by all means, let me
know. i'm just perusing the kernel doc file
Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe.txt
--
========
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
MPC8360, quicc engine, bus-frequency and brg-frequency
currently working on a project porting linux (4.1 kernel right now)
to MPC8360-based target board and, recently, was handed the following
patch to apply to that board's DTS file:
@@ -168,8 +168,8 @@
compatible = "fsl,qe", "simple-bus";
ranges = <0 0xf010 0x0010>;
reg = <0xf010 0x480>;
- brg-frequency = <0>;
- bus-frequency = <0xFBC5200>; // 264Mhz
+ brg-frequency = <19800>;
+ bus-frequency = <39600>;
fsl,qe-num-riscs = <2>;
fsl,qe-num-snums = <28>;
to get the result:
qe@f010 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "qe";
compatible = "fsl,qe", "simple-bus";
ranges = <0 0xf010 0x0010>;
reg = <0xf010 0x480>;
brg-frequency = <19800>; <-
bus-frequency = <39600>; <-
fsl,qe-num-riscs = <2>;
fsl,qe-num-snums = <28>;
but there was no explanation that came with the patch and i'm trying
to guess the rationale.
first, regarding brg-frequency, if i examine the collection of PPC
.dts files in the kernel source right now, i see this:
$ grep -r brg-frequency *
fsl/mpc8568si-post.dtsi:brg-frequency = <0>;
fsl/mpc8569si-post.dtsi:brg-frequency = <0>;
kmeter1.dts:brg-frequency = <0>;/* Filled in by U-Boot
*/
mpc832x_mds.dts:brg-frequency = <0>;
mpc832x_rdb.dts:brg-frequency = <0>;
mpc836x_mds.dts:brg-frequency = <0>;
mpc836x_rdk.dts:brg-frequency = <0>;
mpc866ads.dts: brg-frequency = <0>;
p1021mds.dts: brg-frequency = <0>;
p1021rdb-pc_32b.dts:brg-frequency = <0>;
p1021rdb-pc_36b.dts:brg-frequency = <0>;
p1025rdb_32b.dts: brg-frequency = <0>;
p1025twr.dts: brg-frequency = <0>;
tqm8xx.dts: brg-frequency = <0>;
$
so, based on the above, no one else is setting brg-frequency, and
kmeter1.dts even makes it clear that that value is filled in by
u-boot, so what is even a *possible* rationale for setting it
explicitly rather than letting u-boot look after it?
as for bus-frequency, another sweeping grep exposes this in
mpc836x.dts:
... snip ...
cpus {
#address-cells = <1>;
#size-cells = <0>;
PowerPC,8360@0 {
device_type = "cpu";
reg = <0x0>;
d-cache-line-size = <32>; // 32 bytes
i-cache-line-size = <32>; // 32 bytes
d-cache-size = <32768>; // L1, 32K
i-cache-size = <32768>; // L1, 32K
timebase-frequency = <6600>;
bus-frequency = <26400>;
... snip ...
qe@e010 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "qe";
compatible = "fsl,qe";
ranges = <0x0 0xe010 0x0010>;
reg = <0xe010 0x480>;
brg-frequency = <0>;
bus-frequency = <39600>;
fsl,qe-num-riscs = <2>;
fsl,qe-num-snums = <28>;
... snip ...
where i can see that the system (?) bus is set to 264MHz, but the QE
bus is set to 396MHz. i'm in no way an authority on PowerPC -- this
looks like someone accidentally set the QE bus speed originally to a
valid value for the system bus, and just realized that, oops, it
should have been 396MHz all along.
anyway, to recap, just trying to understand what this patch under
"qe@f010" might mean:
- brg-frequency = <0>;
- bus-frequency = <0xFBC5200>; // 264Mhz
+ brg-frequency = <19800>;
+ bus-frequency = <39600>;
thank you kindly.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] ADB: Replace __WAITQUEUE_INITIALIZER with more standard DECLARE_WAITQUEUE.
Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca --- just FYI, that invocation of __WAITQUEUE_INITIALIER() is the only one in the entire current source tree so it seems a bit out of place. not tested, but there *should* be no functional change. diff --git a/drivers/macintosh/adb.c b/drivers/macintosh/adb.c index b026896..04a5049 100644 --- a/drivers/macintosh/adb.c +++ b/drivers/macintosh/adb.c @@ -697,7 +697,7 @@ static ssize_t adb_read(struct file *file, char __user *buf, int ret = 0; struct adbdev_state *state = file-private_data; struct adb_request *req; - wait_queue_t wait = __WAITQUEUE_INITIALIZER(wait,current); + DECLARE_WAITQUEUE(wait,current); unsigned long flags; if (count 2) rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux kernel reference to non-existent CONFIG_FSL_85XX_CACHE_SRAM
the current kernel source tree contains a Makefile reference to the above Kconfig variable that doesn't appear to be defined anywhere. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] POWERPC: Remove redundant initialization of bsr dev_t declaration.
Remove the unnecessary initialization of dev_t bsr_dev since it's
subsequently used in an alloc_chrdev_region() call which uses that
variable in an output-only fashion.
Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca
---
*Not* compile tested since I don't have a PPC toolchain, but the
logic here should be fairly obvious. The current code isn't wrong,
just misleading.
diff --git a/drivers/char/bsr.c b/drivers/char/bsr.c
index a4a6c2f..cf39bc0 100644
--- a/drivers/char/bsr.c
+++ b/drivers/char/bsr.c
@@ -295,7 +295,7 @@ static int bsr_create_devs(struct device_node *bn)
static int __init bsr_init(void)
{
struct device_node *np;
- dev_t bsr_dev = MKDEV(bsr_major, 0);
+ dev_t bsr_dev;
int ret = -ENODEV;
int result;
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] POWERPC: Simplify param.h by including asm-generic/param.h
Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca --- diff --git a/arch/powerpc/include/asm/param.h b/arch/powerpc/include/asm/param.h index 094f63d..965d454 100644 --- a/arch/powerpc/include/asm/param.h +++ b/arch/powerpc/include/asm/param.h @@ -1,22 +1 @@ -#ifndef _ASM_POWERPC_PARAM_H -#define _ASM_POWERPC_PARAM_H - -#ifdef __KERNEL__ -#define HZ CONFIG_HZ /* internal kernel timer frequency */ -#define USER_HZ100 /* for user interfaces in ticks */ -#define CLOCKS_PER_SEC (USER_HZ) /* frequency at which times() counts */ -#endif /* __KERNEL__ */ - -#ifndef HZ -#define HZ 100 -#endif - -#define EXEC_PAGESIZE 4096 - -#ifndef NOGROUP -#define NOGROUP(-1) -#endif - -#define MAXHOSTNAMELEN 64 /* max length of hostname */ - -#endif /* _ASM_POWERPC_PARAM_H */ +#include asm-generic/param.h rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
invalid Kconfig select for MPC5121_ADS_CPLD
arch/powerpc/platforms/512x/Kconfig: select MPC5121_ADS_CPLD no such config directive anywhere. rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Annoying Kernel Pedantry. Web page: http://crashcourse.ca Linked In: http://www.linkedin.com/in/rpjday Twitter: http://twitter.com/rpjday ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
where to simplify code using is_power_of_2() function
just an observation that you can aesthetically simplify some ppc
code using the boolean is_power_of_2() routine from
include/linux/log2.h if you were so inclined:
arch/powerpc/sysdev/ppc4xx_pci.c:171: if ((size (size - 1)) != 0 ||
arch/powerpc/mm/ppc_mmu_32.c:216: if (n_hpteg (n_hpteg - 1)) {
arch/powerpc/boot/cuboot-pq2.c:176: if (mem-size[1] (mem-size[1] - 1))
arch/powerpc/boot/cuboot-pq2.c:178: if (io-size[1] (io-size[1] - 1))
arch/powerpc/lib/rheap.c:258: if ((alignment (alignment - 1)) != 0)
arch/powerpc/lib/rheap.c:307: if ((alignment (alignment - 1)) != 0)
arch/powerpc/lib/rheap.c:450: if (size = 0 || (alignment (alignment - 1))
!= 0)
rday
--
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Annoying Kernel Pedantry.
Web page: http://crashcourse.ca
Linked In: http://www.linkedin.com/in/rpjday
Twitter: http://twitter.com/rpjday
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Delete completed ppc removal task from feature removal file.
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] --- unless this is in someone's tree already. diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index c239554..17cab3c 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -205,19 +205,6 @@ Who: Tejun Heo [EMAIL PROTECTED] --- -What: The arch/ppc and include/asm-ppc directories -When: Jun 2008 -Why: The arch/powerpc tree is the merged architecture for ppc32 and ppc64 - platforms. Currently there are efforts underway to port the remaining - arch/ppc platforms to the merged tree. New submissions to the arch/ppc - tree have been frozen with the 2.6.22 kernel release and that tree will - remain in bug-fix only mode until its scheduled removal. Platforms - that are not ported by June 2008 will be removed due to the lack of an - interested maintainer. -Who: linuxppc-dev@ozlabs.org - - What: i386/x86_64 bzImage symlinks When: April 2010 Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] POWERPC: Remove ioctl.h content picked up from asm-generic/ioctl.h.
Now that asm-generic/ioctl.h allows overriding of the most commonly changed macros, take advantage of that. Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] --- i *think* this results in an equivalent ioctl.h file, but feel free to check it carefully, and tweak if necessary. diff --git a/include/asm-powerpc/ioctl.h b/include/asm-powerpc/ioctl.h index 8eb9984..57d6830 100644 --- a/include/asm-powerpc/ioctl.h +++ b/include/asm-powerpc/ioctl.h @@ -1,69 +1,13 @@ #ifndef _ASM_POWERPC_IOCTL_H #define _ASM_POWERPC_IOCTL_H - -/* - * this was copied from the alpha as it's a bit cleaner there. - * -- Cort - */ - -#define _IOC_NRBITS8 -#define _IOC_TYPEBITS 8 #define _IOC_SIZEBITS 13 #define _IOC_DIRBITS 3 -#define _IOC_NRMASK((1 _IOC_NRBITS)-1) -#define _IOC_TYPEMASK ((1 _IOC_TYPEBITS)-1) -#define _IOC_SIZEMASK ((1 _IOC_SIZEBITS)-1) -#define _IOC_DIRMASK ((1 _IOC_DIRBITS)-1) - -#define _IOC_NRSHIFT 0 -#define _IOC_TYPESHIFT (_IOC_NRSHIFT+_IOC_NRBITS) -#define _IOC_SIZESHIFT (_IOC_TYPESHIFT+_IOC_TYPEBITS) -#define _IOC_DIRSHIFT (_IOC_SIZESHIFT+_IOC_SIZEBITS) - -/* - * Direction bits _IOC_NONE could be 0, but OSF/1 gives it a bit. - * And this turns out useful to catch old ioctl numbers in header - * files for us. - */ #define _IOC_NONE 1U #define _IOC_READ 2U #define _IOC_WRITE 4U -#define _IOC(dir,type,nr,size) \ - (((dir) _IOC_DIRSHIFT) | \ -((type) _IOC_TYPESHIFT) | \ -((nr)_IOC_NRSHIFT) | \ -((size) _IOC_SIZESHIFT)) - -/* provoke compile error for invalid uses of size argument */ -extern unsigned int __invalid_size_argument_for_IOC; -#define _IOC_TYPECHECK(t) \ - ((sizeof(t) == sizeof(t[1]) \ - sizeof(t) (1 _IOC_SIZEBITS)) ? \ - sizeof(t) : __invalid_size_argument_for_IOC) - -/* used to create numbers */ -#define _IO(type,nr) _IOC(_IOC_NONE,(type),(nr),0) -#define _IOR(type,nr,size) _IOC(_IOC_READ,(type),(nr),(_IOC_TYPECHECK(size))) -#define _IOW(type,nr,size) _IOC(_IOC_WRITE,(type),(nr),(_IOC_TYPECHECK(size))) -#define _IOWR(type,nr,size) _IOC(_IOC_READ|_IOC_WRITE,(type),(nr),(_IOC_TYPECHECK(size))) -#define _IOR_BAD(type,nr,size) _IOC(_IOC_READ,(type),(nr),sizeof(size)) -#define _IOW_BAD(type,nr,size) _IOC(_IOC_WRITE,(type),(nr),sizeof(size)) -#define _IOWR_BAD(type,nr,size) _IOC(_IOC_READ|_IOC_WRITE,(type),(nr),sizeof(size)) - -/* used to decode them.. */ -#define _IOC_DIR(nr) (((nr) _IOC_DIRSHIFT) _IOC_DIRMASK) -#define _IOC_TYPE(nr) (((nr) _IOC_TYPESHIFT) _IOC_TYPEMASK) -#define _IOC_NR(nr)(((nr) _IOC_NRSHIFT) _IOC_NRMASK) -#define _IOC_SIZE(nr) (((nr) _IOC_SIZESHIFT) _IOC_SIZEMASK) - -/* various drivers, such as the pcmcia stuff, need these... */ -#define IOC_IN (_IOC_WRITE _IOC_DIRSHIFT) -#define IOC_OUT(_IOC_READ _IOC_DIRSHIFT) -#define IOC_INOUT ((_IOC_WRITE|_IOC_READ) _IOC_DIRSHIFT) -#define IOCSIZE_MASK (_IOC_SIZEMASK _IOC_SIZESHIFT) -#define IOCSIZE_SHIFT (_IOC_SIZESHIFT) +#include asm-generic/ioctl.h #endif /* _ASM_POWERPC_IOCTL_H */ Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] POWERPC: Move a.out.h to header-y since it doesn't check __KERNEL__.
Since a.out.h doesn't check the value of __KERNEL__, there's no point in unifdef'ing it. Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] --- diff --git a/include/asm-powerpc/Kbuild b/include/asm-powerpc/Kbuild index 5f640e5..7381916 100644 --- a/include/asm-powerpc/Kbuild +++ b/include/asm-powerpc/Kbuild @@ -1,5 +1,6 @@ include include/asm-generic/Kbuild.asm +header-y += a.out.h header-y += auxvec.h header-y += ioctls.h header-y += mman.h @@ -23,7 +24,6 @@ header-y += sigcontext.h header-y += statfs.h header-y += ps3fb.h -unifdef-y += a.out.h unifdef-y += asm-compat.h unifdef-y += bootx.h unifdef-y += byteorder.h Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] PPC: Use newer, non-deprecated __SPIN_LOCK_UNLOCKED macro.
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
---
diff --git a/arch/ppc/syslib/mpc52xx_setup.c b/arch/ppc/syslib/mpc52xx_setup.c
index 9f504fc..ab0cf4c 100644
--- a/arch/ppc/syslib/mpc52xx_setup.c
+++ b/arch/ppc/syslib/mpc52xx_setup.c
@@ -279,7 +279,7 @@ int mpc52xx_match_psc_function(int psc_idx, const char
*func)
int mpc52xx_set_psc_clkdiv(int psc_id, int clkdiv)
{
- static spinlock_t lock = SPIN_LOCK_UNLOCKED;
+ static DEFINE_SPINLOCK(lock);
struct mpc52xx_cdm __iomem *cdm;
unsigned long flags;
u16 mclken_div;
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
make ARCH=ppc defconfig fails looking for common_defconfig
(AIUI, the entire ppc/ architecture is going away, yes? which means i probably shouldn't care about any errors within. is that correct? even so, build errors should probably still be avoided for now.) $ make ARCH=ppc defconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/docproc HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/kxgettext.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/lex.zconf.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf *** Default configuration is based on 'common_defconfig' *** *** Can't find default configuration arch/ppc/configs/common_defconfig! *** make[1]: *** [defconfig] Error 1 make: *** [defconfig] Error 2 rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
extra-aflags-y??
something about this doesn't look right: $ grep -rw extra-aflags-y * arch/ppc/boot/simple/Makefile:EXTRA_AFLAGS := $(extra-aflags-y) $ AFAIK, there is no supported extra-aflags-y variable. and EXTRA_AFLAGS is deprecated in favour of asflags-y anyway, no? rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Kconfig selects non-existent IBM_NEW_EMAC_ZMII
just FYI, from arch/powerpc/platforms/4xx/Kconfig: ... config 440GP bool select IBM_NEW_EMAC_ZMII ... there is no such Kconfig variable IBM_NEW_EMAC_ZMII. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] PPC: Remove redundant reference to non-existent CONFIG_BOOTIMG.
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] --- there is, AFAICT, no BOOTIMG Kconfig variable. not to mention that there is no such include/linux/bootimg.h header file. arch/ppc/platforms/ev64360.c |3 --- arch/ppc/platforms/katana.c |3 --- 2 files changed, 6 deletions(-) diff --git a/arch/ppc/platforms/ev64360.c b/arch/ppc/platforms/ev64360.c index f8baf05..6765676 100644 --- a/arch/ppc/platforms/ev64360.c +++ b/arch/ppc/platforms/ev64360.c @@ -23,9 +23,6 @@ #include linux/mtd/physmap.h #include linux/mv643xx.h #include linux/platform_device.h -#ifdef CONFIG_BOOTIMG -#include linux/bootimg.h -#endif #include asm/page.h #include asm/time.h #include asm/smp.h diff --git a/arch/ppc/platforms/katana.c b/arch/ppc/platforms/katana.c index c289e9f..52f63e6 100644 --- a/arch/ppc/platforms/katana.c +++ b/arch/ppc/platforms/katana.c @@ -27,9 +27,6 @@ #include linux/mtd/physmap.h #include linux/mv643xx.h #include linux/platform_device.h -#ifdef CONFIG_BOOTIMG -#include linux/bootimg.h -#endif #include asm/io.h #include asm/unistd.h #include asm/page.h -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] POWERPC: Correct misspelled config variable in arch/powerpc/Kconfig.
On Tue, 17 Jul 2007, Paul Mackerras wrote: Robert P. J. Day writes: -config CONFIG_CHECK_CACHE_COHERENCY +config CHECK_CACHE_COHERENCY Please also fix the occurrence in arch/powerpc/platforms/embedded6xx/Kconfig. ah, i completely missed that one. i'll resubmit the patch shortly. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] POWERPC: Fix misspelled CONFIG_CHECK_CACHE_COHERENCY Kconfig option.
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] --- arch/powerpc/configs/prpmc2800_defconfig |2 +- arch/powerpc/platforms/Kconfig.cputype |2 +- arch/powerpc/platforms/embedded6xx/Kconfig |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/configs/prpmc2800_defconfig b/arch/powerpc/configs/prpmc2800_defconfig index fb504a7..858f865 100644 --- a/arch/powerpc/configs/prpmc2800_defconfig +++ b/arch/powerpc/configs/prpmc2800_defconfig @@ -48,7 +48,7 @@ CONFIG_PPC_STD_MMU_32=y # CONFIG_PPC_MM_SLICES is not set # CONFIG_SMP is not set CONFIG_NOT_COHERENT_CACHE=y -CONFIG_CONFIG_CHECK_CACHE_COHERENCY=y +CONFIG_CHECK_CACHE_COHERENCY=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype index b8b5fde..e4b2aee 100644 --- a/arch/powerpc/platforms/Kconfig.cputype +++ b/arch/powerpc/platforms/Kconfig.cputype @@ -215,7 +215,7 @@ config NOT_COHERENT_CACHE depends on 4xx || 8xx || E200 default y -config CONFIG_CHECK_CACHE_COHERENCY +config CHECK_CACHE_COHERENCY bool endmenu diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig b/arch/powerpc/platforms/embedded6xx/Kconfig index bec7726..2d12f77 100644 --- a/arch/powerpc/platforms/embedded6xx/Kconfig +++ b/arch/powerpc/platforms/embedded6xx/Kconfig @@ -59,7 +59,7 @@ config MPC10X_BRIDGE config MV64X60 bool select PPC_INDIRECT_PCI - select CONFIG_CHECK_CACHE_COHERENCY + select CHECK_CACHE_COHERENCY config MPC10X_OPENPIC bool -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch] use __attribute__ in asm-powerpc
On Mon, 16 Jul 2007, Geert Uytterhoeven wrote:
On Sat, 14 Jul 2007, Mike Frysinger wrote:
Pretty much everyone uses __attribute__ or attribute, no one
uses __attribute. This patch tweaks the three places in asm-powerpc where
this comes up. While only asm-powerpc/types.h is interesting (for
userspace),
I did asm-powerpc/processor.h as well for consistency.
Signed-off-by: Mike Frysinger [EMAIL PROTECTED]
---
diff --git a/include/asm-powerpc/processor.h
b/include/asm-powerpc/processor.h
index d947b16..2ce6ea6 100644
--- a/include/asm-powerpc/processor.h
+++ b/include/asm-powerpc/processor.h
@@ -153,9 +153,9 @@ struct thread_struct {
unsigned long dabr; /* Data address breakpoint register */
#ifdef CONFIG_ALTIVEC
/* Complete AltiVec register set */
- vector128 vr[32] __attribute((aligned(16)));
+ vector128 vr[32] __attribute__((aligned(16)));
If the code is not exported to userspace (and thus not subject to
different compilers), I think the preferred form is plain
`attribute'.
compiler-gcc.h also defines the common form of the shortcut:
#define __aligned(x)__attribute__((aligned(x)))
rday
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
possibly dead CONFIG-related content in arch/ppc
CONFIG_SERIAL_MANY_PORTS 1 include/asm-ppc/pc_serial.h:22:#ifdef CONFIG_SERIAL_MANY_PORTS == SMP_750 == arch/ppc/mm/tlb.c:92:#ifdef CONFIG_SMP_750 arch/powerpc/mm/tlb_32.c:92:#ifdef CONFIG_SMP_750 == UART0_TTYS2 == arch/ppc/platforms/4xx/ibmstb4.h:108:#if defined(CONFIG_UART0_TTYS2) arch/ppc/platforms/4xx/ibmstbx25.h:125:#if defined(CONFIG_UART0_TTYS2) rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
