[U-Boot-Users] Imminent u-boot-fdt pull request
Dear all,
Please review the u-boot-fdt changes. I intend to request Wolfgang pull the pending changes soon. All of the changes (except the last trivial patch "For fdt_find_node_by_path(), handle the root path properly.") have been previously published to the list.
The following changes are pending:
libfdt: Conditionally compile based on CONFIG_OF_LIBFDT http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-fdt.git;a=commit;h=6b495962ba7b2b43904a87265e182faed033582c
Improve error messages, more informative. http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-fdt.git;a=commit;h=5a4c80ceaf8ff29a169b9a76065a7023fbfda5b9
Minor code clean up. http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-fdt.git;a=commit;h=1959d478d18434ae12d725b4ace1bc86e63b5ad9
Improve fdt move length handling. http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-fdt.git;a=commit;h=4b034226a31a78f2fd619ae09c0e34c7c04348c3
Fix bugs in the CONFIG_OF_LIBFDT http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-fdt.git;a=commit;h=3c3652ec50a13711c844222389cd207d52517a00
Reorganize and fix problems (returns) in the bootm command. http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-fdt.git;a=commit;h=7450dcd7c3040f7d523a4153f90ca649527f804e
FDT command improvements. http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-fdt.git;a=commit;h=f2d8680ac9760072e5ca9e0f021c757aa3a67535
Fix cmd_fdt line lengths, refactor code. http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-fdt.git;a=commit;h=792f0989bf90961ba2644ccc718cf09d338706b8
Replace fdt_node_offset() with fdt_find_node_by_path(). http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-fdt.git;a=commit;h=5e136a1a853f7c9567e428320422da6b2b91c640
Add fdt_find_node_by_type() and fdt_find_compatible_node() to LIBFDT http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-fdt.git;a=commit;h=efe49ab24e87857a0bd2961c8269b5006e3af93a
For fdt_find_node_by_path(), handle the root path properly. http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-fdt.git;a=commit;h=cd87336beaca12aa8cb6a72bf19d4c5d0f9cfd3b
Best regards, gvb
On Tue, 22 May 2007 00:06:06 -0400 Jerry Van Baren gvb.uboot@gmail.com wrote:
Dear all,
Please review the u-boot-fdt changes. I intend to request Wolfgang pull the pending changes soon. All of the changes (except the last trivial
I have properties being placed at the wrong level, timebase- and bus-frequencies not being updated, there are multiple copies of the code, and, it is hard to read - I saw a line length of 139!
Please work on your CodingStyle. I haven't finished debugging here.
Kim
Kim Phillips wrote:
On Tue, 22 May 2007 00:06:06 -0400 Jerry Van Baren gvb.uboot@gmail.com wrote:
Dear all,
Please review the u-boot-fdt changes. I intend to request Wolfgang pull the pending changes soon. All of the changes (except the last trivial
I have properties being placed at the wrong level, timebase- and bus-frequencies not being updated, there are multiple copies of the code, and, it is hard to read - I saw a line length of 139!
Could you be more specific, please? Preferably by adding comments to the patch. And are these problems related to the patch?
Thanks,
Wolfgang.
On Fri, 25 May 2007 11:27:47 +0200 Wolfgang Grandegger wg@grandegger.com wrote:
Kim Phillips wrote:
On Tue, 22 May 2007 00:06:06 -0400 Jerry Van Baren gvb.uboot@gmail.com wrote:
Dear all,
Please review the u-boot-fdt changes. I intend to request Wolfgang pull the pending changes soon. All of the changes (except the last trivial
I have properties being placed at the wrong level, timebase- and bus-frequencies not being updated, there are multiple copies of the code, and, it is hard to read - I saw a line length of 139!
Could you be more specific, please? Preferably by adding comments to the
sorry, my comments were not specific, it's because the nature of the problem as I see it is general, and I decided to send a quick note to save Wolfgang from them ;)
patch. And are these problems related to the patch?
This is current top-of-fdt-tree behaviour:
=> fdt addr $fdtaddr => fdt chosen => fdt print /cpus cpus { clock-frequency=<1f78a400>; // should be one level down #address-cells=<00000001>; #size-cells=<00000000>; PowerPC,8360@0 { device_type="cpu"; reg=<00000000>; d-cache-line-size=<00000020>; i-cache-line-size=<00000020>; d-cache-size=<00008000>; i-cache-size=<00008000>; timebase-frequency=<00000000>; // not updated bus-frequency=<00000000>; // not updated clock-frequency=<00000000>; // not updated, see above 32-bit; }; };
I wouldn't call this quality material.
I'll post (specific) patches once I get a kernel booting, unless someone beats me to it.
Kim
Kim Phillips wrote:
On Fri, 25 May 2007 11:27:47 +0200 Wolfgang Grandegger wg@grandegger.com wrote:
Kim Phillips wrote:
On Tue, 22 May 2007 00:06:06 -0400 Jerry Van Baren gvb.uboot@gmail.com wrote:
Dear all,
Please review the u-boot-fdt changes. I intend to request Wolfgang pull the pending changes soon. All of the changes (except the last trivial
I have properties being placed at the wrong level, timebase- and bus-frequencies not being updated, there are multiple copies of the code, and, it is hard to read - I saw a line length of 139!
Could you be more specific, please? Preferably by adding comments to the
sorry, my comments were not specific, it's because the nature of the problem as I see it is general, and I decided to send a quick note to save Wolfgang from them ;)
patch. And are these problems related to the patch?
This is current top-of-fdt-tree behaviour:
=> fdt addr $fdtaddr => fdt chosen => fdt print /cpus cpus { clock-frequency=<1f78a400>; // should be one level down #address-cells=<00000001>; #size-cells=<00000000>; PowerPC,8360@0 { device_type="cpu"; reg=<00000000>; d-cache-line-size=<00000020>; i-cache-line-size=<00000020>; d-cache-size=<00008000>; i-cache-size=<00008000>; timebase-frequency=<00000000>; // not updated bus-frequency=<00000000>; // not updated clock-frequency=<00000000>; // not updated, see above 32-bit; }; };
I wouldn't call this quality material.
I'll post (specific) patches once I get a kernel booting, unless someone beats me to it.
Kim
Hi Kim,
FWIIW, that is in the (infamous) common/fdt_support.c. It was adapted from ft_build.c. It looks like I lost a OF_CPU in the constructed string when I was adapting.
Original code: p = ft_get_prop(blob, "/cpus/" OF_CPU "/clock-frequency", &len);
Comments: 1) It looks like you are missing the OF_CPU definition, or I'm not pulling in the right .h file
2) Some of the code is in fdt_support.c fdt_chosen(). The stuff messing with CPU-specific values does NOT belong in fdt_chosen(), it should go in cpu/mpc83xx/cpu.c
3) /cpu/PowerPC,8360@0/bus-frequency is properly set in cpu/mpc83xx/cpu.c ft_cpu_setup(). The table of nodes and properties correctly has "/cpus/" OF_CPU, "bus-frequency", which seems to indicate that I don't have the right header pulled in to define OF_CPU. The defines from point #2
Screwed up code in fdt_chosen()
#ifdef OF_TBCLK nodeoffset = fdt_find_node_by_path (fdt, "/cpus/" OF_CPU "/timebase-frequency"); if (nodeoffset >= 0) { clock = cpu_to_be32(OF_TBCLK); err = fdt_setprop(fdt, nodeoffset, "clock-frequency", &clock, 4);
The code in question is in
On Fri, 25 May 2007 12:56:13 -0400 Jerry Van Baren gerald.vanbaren@smiths-aerospace.com wrote:
FWIIW, that is in the (infamous) common/fdt_support.c. It was adapted from ft_build.c. It looks like I lost a OF_CPU in the constructed string when I was adapting.
Original code: p = ft_get_prop(blob, "/cpus/" OF_CPU "/clock-frequency", &len);
Comments:
- It looks like you are missing the OF_CPU definition, or I'm not
pulling in the right .h file
I didn't do anything; as I said before, this is your u-boot-fdt.git top-of-tree.
- Some of the code is in fdt_support.c fdt_chosen(). The stuff messing
with CPU-specific values does NOT belong in fdt_chosen(), it should go in cpu/mpc83xx/cpu.c
not sure about that; why replicate code in the cpu/*/cpu.c files? Can't fdt_chosen() update a property only if it exists? i.e., the cpu dependency would be implied by the device tree, the best place for it IMO.
- /cpu/PowerPC,8360@0/bus-frequency is properly set in
cpu/mpc83xx/cpu.c ft_cpu_setup(). The table of nodes and properties correctly has "/cpus/" OF_CPU, "bus-frequency", which seems to indicate that I don't have the right header pulled in to define OF_CPU. The defines from point #2
precisely.
Screwed up code in fdt_chosen()
#ifdef OF_TBCLK nodeoffset = fdt_find_node_by_path (fdt, "/cpus/" OF_CPU "/timebase-frequency"); if (nodeoffset >= 0) { clock = cpu_to_be32(OF_TBCLK); err = fdt_setprop(fdt, nodeoffset, "clock-frequency", &clock, 4);
noticed that sloppiness.
The code in question is in
that is the question.
please do not ask Wolfgang to pull patches to files in mpc83xx and related directories (cpu.c, board configs, etc.) from your tree; they should go through the mpc83xx tree from now on.
Kim
Kim Phillips wrote:
On Fri, 25 May 2007 12:56:13 -0400 Jerry Van Baren gerald.vanbaren@smiths-aerospace.com wrote:
[snip]
please do not ask Wolfgang to pull patches to files in mpc83xx and related directories (cpu.c, board configs, etc.) from your tree; they should go through the mpc83xx tree from now on.
Kim
In retrospect, that was impolite and I apologize for the crossover. :-(
The 83xx changes were necessary to make the bootm using libfdt work (I have a 8360 board). If I don't push the necessary changes through u-boot-fdt, u-boot-fdt will be impossible to use until you add the necessary changes in the 83xx repo (and possibly vice versa). In addition, Wolfgang would have to coordinate his pulls into the main repo or it would break.
The cross coupling is unfortunate, but we have to have one example of a CPU/board and libfdt coupled in order to test the libfdt changes.
I would prefer to fix the problems noted (which really are not as bad as they look IMHO) to make one CPU+board+libfdt example work and push those changes to Wolfgang via the u-boot-fdt repo. If you are opposed to this, I can back out the 83xx changes and push just libfdt stuff to Wolfgang and supply you with the set of 83xx patches which you can push through your repo, but it will tough for others to use/test since they will get only half a picture from each repo.
Best regards, gvb
On Fri, 25 May 2007 13:33:49 -0400 Jerry Van Baren gerald.vanbaren@smiths-aerospace.com wrote:
Kim Phillips wrote:
On Fri, 25 May 2007 12:56:13 -0400 Jerry Van Baren gerald.vanbaren@smiths-aerospace.com wrote:
[snip]
please do not ask Wolfgang to pull patches to files in mpc83xx and related directories (cpu.c, board configs, etc.) from your tree; they should go through the mpc83xx tree from now on.
Kim
In retrospect, that was impolite and I apologize for the crossover. :-(
The 83xx changes were necessary to make the bootm using libfdt work (I have a 8360 board). If I don't push the necessary changes through u-boot-fdt, u-boot-fdt will be impossible to use until you add the necessary changes in the 83xx repo (and possibly vice versa). In addition, Wolfgang would have to coordinate his pulls into the main repo or it would break.
The cross coupling is unfortunate, but we have to have one example of a CPU/board and libfdt coupled in order to test the libfdt changes.
I would prefer to fix the problems noted (which really are not as bad as they look IMHO) to make one CPU+board+libfdt example work and push those changes to Wolfgang via the u-boot-fdt repo. If you are opposed to this, I can back out the 83xx changes and push just libfdt stuff to Wolfgang and supply you with the set of 83xx patches which you can push through your repo, but it will tough for others to use/test since they will get only half a picture from each repo.
nothing would have broken if LIBFDT were not turned on by default.
the only reason nothing seemed broken in the first place was the coincidence that the board you developed on is one of a handful of boards with valid (non-zero) default -frequency values in its dts (in Linux).
anyone can just as easily pull the mpc83xx git tree on top of the fdt tree, or vice-versa, as clone Wolfgang's stable or testing tree. Wolfgang doesn't ever have to do anything except respond to our pull requests. You and I can coordinate pull requests if you think it's necessary (I don't think it will be in the long term).
I don't see any reason why any mpc83xx specific patches should bypass the mpc83xx tree, and any libfdt specific patches bypass the fdt tree, for that matter. If you want, you can put your mpc83xx specific patches on a mpc83xx branch on your tree, and ask me to pull from your tree, after having posted the patches on u-boot-users, if you think it's more convenient.
Let's concentrate on getting things fixed; I'm not going to post a patch to turn off LIBFDT on the MPC8360EMDS unless Wolfgang informs me of an imminent release or something. In fact, the reason this came about was because I'm adding a new board, and I thought it be good if it used libfdt. I like libfdt, but it needs to work, be readable, and be easy to use.
btw, I'll try to be more prompt with my testing in the future; please be more thorough with yours.
Thanks,
Kim
Kim Phillips wrote:
On Fri, 25 May 2007 13:33:49 -0400 Jerry Van Baren gerald.vanbaren@smiths-aerospace.com wrote:
Kim Phillips wrote:
On Fri, 25 May 2007 12:56:13 -0400 Jerry Van Baren gerald.vanbaren@smiths-aerospace.com wrote:
[snip]
please do not ask Wolfgang to pull patches to files in mpc83xx and related directories (cpu.c, board configs, etc.) from your tree; they should go through the mpc83xx tree from now on.
Kim
In retrospect, that was impolite and I apologize for the crossover. :-(
The 83xx changes were necessary to make the bootm using libfdt work (I have a 8360 board). If I don't push the necessary changes through u-boot-fdt, u-boot-fdt will be impossible to use until you add the necessary changes in the 83xx repo (and possibly vice versa). In addition, Wolfgang would have to coordinate his pulls into the main repo or it would break.
The cross coupling is unfortunate, but we have to have one example of a CPU/board and libfdt coupled in order to test the libfdt changes.
I would prefer to fix the problems noted (which really are not as bad as they look IMHO) to make one CPU+board+libfdt example work and push those changes to Wolfgang via the u-boot-fdt repo. If you are opposed to this, I can back out the 83xx changes and push just libfdt stuff to Wolfgang and supply you with the set of 83xx patches which you can push through your repo, but it will tough for others to use/test since they will get only half a picture from each repo.
nothing would have broken if LIBFDT were not turned on by default.
Yup, I screwed that up in my first pull request to Wolfgang. :-/
the only reason nothing seemed broken in the first place was the coincidence that the board you developed on is one of a handful of boards with valid (non-zero) default -frequency values in its dts (in Linux).
anyone can just as easily pull the mpc83xx git tree on top of the fdt tree, or vice-versa, as clone Wolfgang's stable or testing tree. Wolfgang doesn't ever have to do anything except respond to our pull requests. You and I can coordinate pull requests if you think it's necessary (I don't think it will be in the long term).
I agree with this in the long term. I screwed up enabling LIBFDT by default and got carried away making bootm work... but those are excuses.
I don't see any reason why any mpc83xx specific patches should bypass the mpc83xx tree, and any libfdt specific patches bypass the fdt tree, for that matter. If you want, you can put your mpc83xx specific patches on a mpc83xx branch on your tree, and ask me to pull from your tree, after having posted the patches on u-boot-users, if you think it's more convenient.
Let's concentrate on getting things fixed; I'm not going to post a patch to turn off LIBFDT on the MPC8360EMDS unless Wolfgang informs me of an imminent release or something. In fact, the reason this came about was because I'm adding a new board, and I thought it be good if it used libfdt. I like libfdt, but it needs to work, be readable, and be easy to use.
Just quibbling, I consider libfdt/* and cmd_fdt.c to be good quality. The cmd_bootm.c and associated code (fdt_chosen(), fdt_env(), fdt_bd_t(), ft_cpu_setup(), and ft_pci_setup()) is what is rough.
Part of that is my inattention to detail (hacking without understanding the code first), part of that is my lack of "big picture" understanding of what the blob contents /should/ look like, and part of that is my small sample size (one) that just happens to work. :-(
btw, I'll try to be more prompt with my testing in the future; please be more thorough with yours.
Fair enough.
Thanks, Kim
Thanks in turn, gvb
Jerry Van Baren wrote:
FWIIW, that is in the (infamous) common/fdt_support.c. It was adapted from ft_build.c. It looks like I lost a OF_CPU in the constructed string when I was adapting.
Original code: p = ft_get_prop(blob, "/cpus/" OF_CPU "/clock-frequency", &len);
Comments:
- It looks like you are missing the OF_CPU definition, or I'm not
pulling in the right .h file
What about doing a search for device_type = "cpu", rather than looking for a specific CPU name? The Linux bootwrapper does it this way. It also has the benefit of working when there's more than one CPU.
-Scott
"Global" u-boot variables, defined by setenv commands may be seen from code using getenv() function and may be also set from code via setenv() function.
Do similar functions exist for HUSH local variables?
Thanks,
Leonid.
In message 406A31B117F2734987636D6CCC93EE3C01887495@ehost011-3.exch011.intermedia.net you wrote:
"Global" u-boot variables, defined by setenv commands may be seen from code using getenv() function and may be also set from code via setenv() function.
Do similar functions exist for HUSH local variables?
Only in the scope of the hush code itself.
Best regards,
Wolfgang Denk
Scott Wood wrote:
Jerry Van Baren wrote:
FWIIW, that is in the (infamous) common/fdt_support.c. It was adapted from ft_build.c. It looks like I lost a OF_CPU in the constructed string when I was adapting.
Original code: p = ft_get_prop(blob, "/cpus/" OF_CPU "/clock-frequency", &len);
Comments:
- It looks like you are missing the OF_CPU definition, or I'm not
pulling in the right .h file
What about doing a search for device_type = "cpu", rather than looking for a specific CPU name? The Linux bootwrapper does it this way. It also has the benefit of working when there's more than one CPU.
-Scott
I deeply regret the confusion I caused by pushing the "Send" when I meant to push "Write" to start a new, unrelated, message. My updated re-send, as you probably have figured out by now, is more coherent.
OF_CPU is defined in the board-specific header file, e.g. configs/MPC8360EMDS.h, pulled in by config.h. Since I am missing the #include <config.h> in the two files being discussed, OF_CPU is undefined and the string concatenation trick makes it silently disappear.
Best regards, gvb
Jerry Van Baren wrote:
What about doing a search for device_type = "cpu", rather than looking for a specific CPU name? The Linux bootwrapper does it this way. It also has the benefit of working when there's more than one CPU.
-Scott
I deeply regret the confusion I caused by pushing the "Send" when I meant to push "Write" to start a new, unrelated, message. My updated re-send, as you probably have figured out by now, is more coherent.
OF_CPU is defined in the board-specific header file, e.g. configs/MPC8360EMDS.h, pulled in by config.h. Since I am missing the #include <config.h> in the two files being discussed, OF_CPU is undefined and the string concatenation trick makes it silently disappear.
Sure... I was just suggesting a more robust method, that doesn't rely on the board config file to define the CPU name.
-Scott
Scott Wood wrote:
Jerry Van Baren wrote:
What about doing a search for device_type = "cpu", rather than looking for a specific CPU name? The Linux bootwrapper does it this way. It also has the benefit of working when there's more than one CPU.
-Scott
I deeply regret the confusion I caused by pushing the "Send" when I meant to push "Write" to start a new, unrelated, message. My updated re-send, as you probably have figured out by now, is more coherent.
OF_CPU is defined in the board-specific header file, e.g. configs/MPC8360EMDS.h, pulled in by config.h. Since I am missing the #include <config.h> in the two files being discussed, OF_CPU is undefined and the string concatenation trick makes it silently disappear.
Sure... I was just suggesting a more robust method, that doesn't rely on the board config file to define the CPU name.
-Scott
Ah, now I follow. That is worth considering. That would make some assumptions too, just different ones.
Of the top of my head... * All CPUs are clocked the same (unlikely to be a problem) * That the CPU actually _needs_ the fixups (currently they all get the fixup so it isn't currently a problem)
As long as it works for the bootwrapper, it would work for u-boot. The two are imperfect subsets of each other, however.
Thanks, gvb
Kim Phillips wrote:
On Fri, 25 May 2007 11:27:47 +0200 Wolfgang Grandegger wg@grandegger.com wrote:
Kim Phillips wrote:
On Tue, 22 May 2007 00:06:06 -0400 Jerry Van Baren gvb.uboot@gmail.com wrote:
Dear all,
Please review the u-boot-fdt changes. I intend to request Wolfgang pull the pending changes soon. All of the changes (except the last trivial
I have properties being placed at the wrong level, timebase- and bus-frequencies not being updated, there are multiple copies of the code, and, it is hard to read - I saw a line length of 139!
Could you be more specific, please? Preferably by adding comments to the
sorry, my comments were not specific, it's because the nature of the problem as I see it is general, and I decided to send a quick note to save Wolfgang from them ;)
patch. And are these problems related to the patch?
This is current top-of-fdt-tree behaviour:
=> fdt addr $fdtaddr => fdt chosen => fdt print /cpus cpus { clock-frequency=<1f78a400>; // should be one level down #address-cells=<00000001>; #size-cells=<00000000>; PowerPC,8360@0 { device_type="cpu"; reg=<00000000>; d-cache-line-size=<00000020>; i-cache-line-size=<00000020>; d-cache-size=<00008000>; i-cache-size=<00008000>; timebase-frequency=<00000000>; // not updated bus-frequency=<00000000>; // not updated clock-frequency=<00000000>; // not updated, see above 32-bit; }; };
I wouldn't call this quality material.
I'll post (specific) patches once I get a kernel booting, unless someone beats me to it.
Kim
(Aaargh, hit the wrong button. Sorry for the line noise.)
Hi Kim,
FWIIW, that is in the (infamous) common/fdt_support.c. It was adapted from ft_build.c. It looks like I lost a OF_CPU in the constructed string when I was adapting.
Original code: p = ft_get_prop(blob, "/cpus/" OF_CPU "/clock-frequency", &len);
Comments: 1) Hmm, the OF_CPU definition comes from include/config.h and I'm not pulling it in. Grrrrr.
2) Some of the code is in fdt_support.c fdt_chosen(). The stuff messing with CPU-specific values does NOT belong in fdt_chosen(), it should go in cpu/mpc83xx/cpu.c
3) /cpu/PowerPC,8360@0/bus-frequency is properly set in cpu/mpc83xx/cpu.c ft_cpu_setup(). The table of nodes and properties correctly has "/cpus/" OF_CPU, "bus-frequency", Ooops, another config.h missing. Double grrrrr. Also, the CPU-specific fixups from fdt_chosen() (point #2) should be moved here.
I'll clean this up unless someone beats me to it. :-/
Best regards, gvb
Kim Phillips wrote:
On Tue, 22 May 2007 00:06:06 -0400 Jerry Van Baren gvb.uboot@gmail.com wrote:
Dear all,
Please review the u-boot-fdt changes. I intend to request Wolfgang pull the pending changes soon. All of the changes (except the last trivial
I have properties being placed at the wrong level, timebase- and bus-frequencies not being updated, there are multiple copies of the code, and, it is hard to read - I saw a line length of 139!
Please work on your CodingStyle. I haven't finished debugging here.
Kim
Hi Kim,
Thanks for the feedback, I'll check things. Pointers to files (and lines) would be helpful. :-/
WRT line lengths, Wolfgang dinged me on them so I created a cleanup patch. As a result, one patch has line length violations and a later patch fixes them. This may be related to your line length and multiple copy comment.
Thanks, gvb
On Fri, 25 May 2007 07:54:47 -0400 Jerry Van Baren gerald.vanbaren@smiths-aerospace.com wrote:
Thanks for the feedback, I'll check things. Pointers to files (and lines) would be helpful. :-/
WRT line lengths, Wolfgang dinged me on them so I created a cleanup patch. As a result, one patch has line length violations and a later patch fixes them. This may be related to your line length and multiple copy comment.
Thanks, gvb
$ wc -L common/fdt_support.c 139 common/fdt_support.c
introduced by:
commit 792f0989bf90961ba2644ccc718cf09d338706b8 Author: Gerald Van Baren vanbaren@cideas.com Date: Wed May 16 22:39:59 2007 -0400
Fix cmd_fdt line lengths, refactor code.
Break lines that were greater than 80 characters in length. Move the fdt print and property parsing code to separate static functions to reduce coding clutter in the fdt_cmd handling body.
Signed-off-by: Gerald Van Baren vanbaren@cideas.com
Kim
Kim Phillips wrote:
On Fri, 25 May 2007 07:54:47 -0400 Jerry Van Baren gerald.vanbaren@smiths-aerospace.com wrote:
Thanks for the feedback, I'll check things. Pointers to files (and lines) would be helpful. :-/
WRT line lengths, Wolfgang dinged me on them so I created a cleanup patch. As a result, one patch has line length violations and a later patch fixes them. This may be related to your line length and multiple copy comment.
Thanks, gvb
$ wc -L common/fdt_support.c 139 common/fdt_support.c
introduced by:
commit 792f0989bf90961ba2644ccc718cf09d338706b8 Author: Gerald Van Baren vanbaren@cideas.com Date: Wed May 16 22:39:59 2007 -0400
Fix cmd_fdt line lengths, refactor code. Break lines that were greater than 80 characters in length. Move the fdt print and property parsing code to separate static functions to reduce coding clutter in the fdt_cmd handling body. Signed-off-by: Gerald Van Baren <vanbaren@cideas.com>Kim
Hmm, looks like I did a half-a$$ job there. Looking at the patch, I only cleaned up cmd_fdt and missed cleaning up the long lines in fdt_+support.c.
Sorry for the sloppiness, I'll fix that.
Best regards, gvb
participants (7)
-
Jerry Van Baren -
Jerry Van Baren -
Kim Phillips -
Leonid -
Scott Wood -
Wolfgang Denk -
Wolfgang Grandegger