Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code
On Wed, Oct 14, 2009 at 7:00 PM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi Grant, On Tue, 06 Oct 2009 22:29:57 -0600 Grant Likely grant.lik...@secretlab.ca wrote: Well, I've got to start somewhere... So here goes. I've begun the work to merge and clean up the OF device tree handling code and this is my first set of patches. Not fully tested yet, but I'm getting them out to the lists so that I can start responding to comments and collecting acks. This first batch isn't anything exciting, just a merge of common code This all looks OK to me. One thing: I started in this as well some time ago and in my attempt I was hoping to avoid the ARCH ifdefs in linux/of.h by creating asm/of.h and moving the differing bits in there ... Thanks Stephen. At the moment I'm purposefully experimenting with doing arch #ifdefs in the hope that it will lead to obvious places where the code can be generalized even further. I'll see how it looks before I commit down that path though. In the mean time, I've pushed out the current series with acked-bys added to my git server. I think I'm ready for things to start going into linux-next. Since this is the first time I've asked for a tree to be added to linux-next, please let me know if you see anything troublesome or problematic. Here's the tree: The following changes since commit 4bdf0bb7d64cf672199519b3d808e2a82f5b59e9: Grant Likely (1): powerpc/5200: Update defconfigs are available in the git repository at: git://git.secretlab.ca/git/linux-2.6 next-devicetree Grant Likely (12): of: Rework linux/of.h and asm/prom.h include ordering of: merge phandle, ihandle and struct property of: merge struct device_node of: Move OF_IS_DYNAMIC and OF_MARK_DYNAMIC macros to of.h of: add common header for flattened device tree representation of: merge struct boot_param_header from Microblaze and PowerPC of: merge of_node_*_flag() and set_node_proc_entry() of: merge of_read_number() an of_read_ulong() of: merge of_node_get(), of_node_put() and of_find_all_nodes() of: merge of_*_flat_dt*() functions of: merge other miscellaneous prototypes of: merge of_find_all_nodes() implementations arch/microblaze/include/asm/prom.h | 135 + arch/microblaze/kernel/head.S |2 +- arch/microblaze/kernel/prom.c | 23 -- arch/powerpc/include/asm/prom.h| 147 +--- arch/powerpc/kernel/prom.c | 23 -- arch/sparc/include/asm/prom.h | 55 +- drivers/of/base.c | 26 ++- include/linux/of.h | 103 + include/linux/of_fdt.h | 86 + 9 files changed, 221 insertions(+), 379 deletions(-) create mode 100644 include/linux/of_fdt.h I'll send out the two patches I did just to show what I mean (these are from before microblaze was using the OF stuff). Got them, thanks. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code
Hi Grant, On Thu, 15 Oct 2009 11:06:15 -0600 Grant Likely grant.lik...@secretlab.ca wrote: In the mean time, I've pushed out the current series with acked-bys added to my git server. I think I'm ready for things to start going into linux-next. Since this is the first time I've asked for a tree to be added to linux-next, please let me know if you see anything troublesome or problematic. Here's the tree: The following changes since commit 4bdf0bb7d64cf672199519b3d808e2a82f5b59e9: Grant Likely (1): powerpc/5200: Update defconfigs Um, that commit is in no tree but yours ... are available in the git repository at: git://git.secretlab.ca/git/linux-2.6 next-devicetree I have added this for today, but note that it contains stuff that is not devicetree related. Trees in linux-next should be based on other trees in linux-next (almost always Linus' tree, but any other nonrebasing tree is fine). Thanks for adding your subsystem tree as a participant of linux-next. As you may know, this is not a judgment of your code. The purpose of linux-next is for integration testing and to lower the impact of conflicts between subsystems in the next merge window. You will need to ensure that the patches/commits in your tree/series have been: * submitted under GPL v2 (or later) and include the Contributor's Signed-off-by, * posted to the relevant mailing list, * reviewed by you (or another maintainer of your subsystem tree), * successfully unit tested, and * destined for the current or next Linux merge window. Basically, this should be just what you would send to Linus (or ask him to fetch). It is allowed to be rebased if you deem it necessary. -- Cheers, Stephen Rothwell s...@canb.auug.org.au Legal Stuff: By participating in linux-next, your subsystem tree contributions are public and will be included in the linux-next trees. You may be sent e-mail messages indicating errors or other issues when the patches/commits from your subsystem tree are merged and tested in linux-next. These messages may also be cross-posted to the linux-next mailing list, the linux-kernel mailing list, etc. The linux-next tree project and IBM (my employer) make no warranties regarding the linux-next project, the testing procedures, the results, the e-mails, etc. If you don't agree to these ground rules, let me know and I'll remove your tree from participation in linux-next. pgp83jaOzcXuA.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code
On Thu, Oct 15, 2009 at 5:38 PM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi Grant, On Thu, 15 Oct 2009 11:06:15 -0600 Grant Likely grant.lik...@secretlab.ca wrote: In the mean time, I've pushed out the current series with acked-bys added to my git server. I think I'm ready for things to start going into linux-next. Since this is the first time I've asked for a tree to be added to linux-next, please let me know if you see anything troublesome or problematic. Here's the tree: The following changes since commit 4bdf0bb7d64cf672199519b3d808e2a82f5b59e9: Grant Likely (1): powerpc/5200: Update defconfigs Um, that commit is in no tree but yours ... It should be in Ben's merge tree shortly, and Linus' shortly after that, but yeah that was lazy. It was the tree that I tested my commits on, and I should have either rebased or waited until it actually hit mainline. I just wanted to get the ball rolling before heading out the door for Japan. are available in the git repository at: git://git.secretlab.ca/git/linux-2.6 next-devicetree I have added this for today, but note that it contains stuff that is not devicetree related. Trees in linux-next should be based on other trees in linux-next (almost always Linus' tree, but any other nonrebasing tree is fine). Thanks. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code
Hi Grant, On Tue, 06 Oct 2009 22:29:57 -0600 Grant Likely grant.lik...@secretlab.ca wrote: Well, I've got to start somewhere... So here goes. I've begun the work to merge and clean up the OF device tree handling code and this is my first set of patches. Not fully tested yet, but I'm getting them out to the lists so that I can start responding to comments and collecting acks. This first batch isn't anything exciting, just a merge of common code This all looks OK to me. One thing: I started in this as well some time ago and in my attempt I was hoping to avoid the ARCH ifdefs in linux/of.h by creating asm/of.h and moving the differing bits in there ... I'll send out the two patches I did just to show what I mean (these are from before microblaze was using the OF stuff). -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgp93R619rcMl.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code
On Wed, 7 Oct 2009, David Miller wrote: From: Chris Newport c...@netunix.com Date: Thu, 8 Oct 2009 02:29:25 +0100 (BST) Sun4d has never had SMP support and Wrong. this is apparantly problematic due to Cray interlectual property causing a lack of bus documentation. XBUS documentation is not available, but we fully know how to program the SBUS interrupt controller and whatnot. It's all there in the sun4d interrupt and SMP support and it did work just fine at one point. Amusingly the SBUS interrupt stuff on sun4d is a very close sibling to the IMAP/ICLR scheme used on sun4u. The Sun4d SMP support exists, but is broken in 2.6. And the UP support is buggy. At least on my test-setup, the kernel is unable to load userland from scsi-drives. Dropping the sun4 32-bit SPARC is a bit counterproductive when considering the resent effort to unify sparc64 and sparc arch-branches ? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code
On Tuesday 06 October 2009 23:49:04 Grant Likely wrote: However, I've completely devoted to this work for at least the next two months, so there are plenty more patches to follow. Once I've got all the common code merged between Microblaze, PowerPC and Sparc I'll be fix the endian problems and making it easily usable by other architectures like ARM and MIPS. Lots of work to be done. Is there any news on getting QEMU to parse a device tree to figure out what hardware to emulate? (I.E. using the device tree code to let qemu provide configurable board emulations instead of hardwiring them in C code?) Also, what would be involved in getting x86 to (at least have the option to) use the device tree stuff? Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code
From: Grant Likely grant.lik...@secretlab.ca Date: Tue, 6 Oct 2009 22:49:04 -0600 Also, I'd like to take on responsibility for maintaining the cross- architecture device tree code. If there are no objections, I'll write a patch to add a device tree section to MAINTAINERS. Feel free. And also feel free to add my: Acked-by: David S. Miller da...@davemloft.net to your patches. Thanks! ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code
However, I've completely devoted to this work for at least the next two months, so there are plenty more patches to follow. Once I've \o/ Thanks, Grant! A seperate tree would be great. Patches look good to me: Acked-by: Wolfram Sang w.s...@pengutronix.de -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code
On Wed, Oct 7, 2009 at 1:09 AM, Rob Landley r...@landley.net wrote: On Tuesday 06 October 2009 23:49:04 Grant Likely wrote: However, I've completely devoted to this work for at least the next two months, so there are plenty more patches to follow. Once I've got all the common code merged between Microblaze, PowerPC and Sparc I'll be fix the endian problems and making it easily usable by other architectures like ARM and MIPS. Lots of work to be done. Is there any news on getting QEMU to parse a device tree to figure out what hardware to emulate? (I.E. using the device tree code to let qemu provide configurable board emulations instead of hardwiring them in C code?) Not that I have, but I expect that I will be hacking on QEMU as part of this work. Also, what would be involved in getting x86 to (at least have the option to) use the device tree stuff? It would be very easy once the endian issues are worked out since the device tree is just a data format to be parsed. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [microblaze-uclinux] Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code
Grant Likely wrote: On Wed, Oct 7, 2009 at 1:09 AM, Rob Landley r...@landley.net wrote: On Tuesday 06 October 2009 23:49:04 Grant Likely wrote: However, I've completely devoted to this work for at least the next two months, so there are plenty more patches to follow. Once I've got all the common code merged between Microblaze, PowerPC and Sparc I'll be fix the endian problems and making it easily usable by other architectures like ARM and MIPS. Lots of work to be done. Is there any news on getting QEMU to parse a device tree to figure out what hardware to emulate? (I.E. using the device tree code to let qemu provide configurable board emulations instead of hardwiring them in C code?) Not that I have, but I expect that I will be hacking on QEMU as part of this work. ok great. Just let us know - we will test it. Thanks, Michal Also, what would be involved in getting x86 to (at least have the option to) use the device tree stuff? It would be very easy once the endian issues are worked out since the device tree is just a data format to be parsed. g. -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code
On Wed, Oct 07, 2009 at 03:18:04PM +1000, Julian Calaby wrote: On Wed, Oct 7, 2009 at 14:49, Grant Likely grant.lik...@secretlab.ca wrote: On Tue, Oct 6, 2009 at 10:29 PM, Grant Likely grant.lik...@secretlab.ca wrote: So here goes. I've begun the work to merge and clean up the OF device tree handling code and this is my first set of patches. Not fully tested yet, but I'm getting them out to the lists so that I can start responding to comments and collecting acks. This first batch isn't anything exciting, just a merge of common code Good work, for what it's worth, this all looks good to me. However, I've completely devoted to this work for at least the next two months, so there are plenty more patches to follow. Once I've got all the common code merged between Microblaze, PowerPC and Sparc I'll be fix the endian problems and making it easily usable by other architectures like ARM and MIPS. Lots of work to be done. On the subject of merging code, I know that the SUN3 code in m68k uses a similar prom interface to the sparc32 code. (and I've also considered unifying that and ... well ... see above) Does anyone know if it has an OpenFirmware interface for it's devices? Is OF on SUN3 even remotely useful? Does Linux on SUN3 even work with modern kernels? Sun3 doesn't have OF, though I've got some dormant patches to add an OF emulation layer to make it easier to reuse Sparc drivers on Sun3... Never finished enough to submit, so it probably shouldn't affect anything you're doing here. As for recent kernels, I think 2.6.19 was the last sun3 I distributed patches for, so modern might be pushing it... -- Sam ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC PATCH 00/12] Merge common OpenFirmware device tree code
-Original Message- From: devicetree-discuss-bounces+stephen.neuendorffer=xilinx@lists.ozlabs. org [mailto:devicetree- discuss-bounces+stephen.neuendorffer=xilinx@lists.ozlabs.org] On Behalf Of David Miller Sent: Wednesday, October 07, 2009 12:27 AM To: grant.lik...@secretlab.ca Cc: s...@canb.auug.org.au; devicetree-disc...@lists.ozlabs.org; microblaze-ucli...@itee.uq.edu.au; sparcli...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org Subject: Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code From: Grant Likely grant.lik...@secretlab.ca Date: Tue, 6 Oct 2009 22:49:04 -0600 Also, I'd like to take on responsibility for maintaining the cross- architecture device tree code. If there are no objections, I'll write a patch to add a device tree section to MAINTAINERS. Feel free. And also feel free to add my: Acked-by: David S. Miller da...@davemloft.net to your patches. Thanks for doing this, Grant It's definitely needed. Acked-by: Stephen Neuendorffer stephen.neuendorf...@xilinx.com Steve 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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code
Sun3 doesn't have OF When I was first developing Open Boot for the SPARCstation-1, I was also simultaneously trying to do it for a Sun-3 system that was being built at the same time. It proved to be too much to do both jobs at the same time, especially in light of all the hardware debugging that is part of a new system bringup. So I gave up on Sun 3 and just focused on SS-1. That particular Sun-3 machine never sold very well, while the SS-1 was very popular. That was Sun's last 680x0 machine. Personally, I think that continuing to support Sun-3 in Linux is not useful in a practical sense. To the extent that supporting long-obsolete platforms and devices makes the job harder for current systems, it is actually harmful. Portability and generality is good in some theoretical rightness sense, but there are practical limits. Code can become so heavily layered that approaching it requires a huge commitment of effort to learn all the artificial layers. Sometimes you have to prune the dead branches so the living ones can get light and air. Taking this one step further, I don't see any real good reason to continue supporting Sun4 going forward. I got rid of my Sun4 systems long ago because it was just too hard to keep them working - after having used them long after most people had moved on. Dropping Sun3 and Sun4 eliminates all vestiges of the sunmon interface and also allows dropping support for OBP version 1, which only shipped on SS1-class machines - the first machines in the Sun4c subclass. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code
From: Chris Newport c...@netunix.com Date: Wed, 7 Oct 2009 21:54:34 +0100 (BST) Sun4c has also been broken for a long time and sun4d has never worked properly. Is it time to also prune these ?. That would leave only Sun4m in the 32bit kernel, which still works and has plenty of ongoing user interest. Chris don't over-exaggerate the state. The truth is that the whole sparc32 port is in a state of mild disrepair, and many of the issues apply to all the port rather than just one family of systems. I think someone suitably motivated could get most of the bugs sorted out. There is no reason to drop support for SS1 machines, we already fully build the software device tree and use all of the generic OF infrastructure in the Linux kernel on those systems. It is not a road block at all for the OF genericization work, if that's what you read into wmb's email. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code
On Wed, 7 Oct 2009, Mitch Bradley wrote: Taking this one step further, I don't see any real good reason to continue supporting Sun4 going forward. I got rid of my Sun4 systems long ago because it was just too hard to keep them working - after having used them long after most people had moved on. Dropping Sun3 and Sun4 eliminates all vestiges of the sunmon interface and also allows dropping support for OBP version 1, which only shipped on SS1-class machines - the first machines in the Sun4c subclass. Sun4c has also been broken for a long time and sun4d has never worked properly. Is it time to also prune these ?. That would leave only Sun4m in the 32bit kernel, which still works and has plenty of ongoing user interest. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code
On Wed, Oct 07, 2009 at 09:52:43AM -0400, Sam Creasey wrote: On Wed, Oct 07, 2009 at 03:18:04PM +1000, Julian Calaby wrote: On the subject of merging code, I know that the SUN3 code in m68k uses a similar prom interface to the sparc32 code. (and I've also considered unifying that and ... well ... see above) Does anyone know if it has an OpenFirmware interface for it's devices? Is OF on SUN3 even remotely useful? Does Linux on SUN3 even work with modern kernels? Sun3 doesn't have OF, though I've got some dormant patches to add an OF emulation layer to make it easier to reuse Sparc drivers on Sun3... Never finished enough to submit, so it probably shouldn't affect anything you're doing here. I was also looking at using the OF code on m68k, but for a different reason. My goal was to get macio_bus working so we can merge a few of the m68k Mac drivers into the ppc Mac drivers. The simplest way to do that seemed to be supporting OF since macio_dev is a wrapper for of_device. It was also a nice way to build up a table of all the onboard devices in memory. Hopefully it would enable better user-space device detection as well. I got the framework built against an older kernel, but it wasn't enough to be useful at that point. This set of patches could help quite a bit. Brad Boyer f...@allandria.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code
From: Chris Newport c...@netunix.com Date: Thu, 8 Oct 2009 02:29:25 +0100 (BST) Sun4d has never had SMP support and Wrong. this is apparantly problematic due to Cray interlectual property causing a lack of bus documentation. XBUS documentation is not available, but we fully know how to program the SBUS interrupt controller and whatnot. It's all there in the sun4d interrupt and SMP support and it did work just fine at one point. Amusingly the SBUS interrupt stuff on sun4d is a very close sibling to the IMAP/ICLR scheme used on sun4u. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code
On Tue, Oct 6, 2009 at 10:29 PM, Grant Likely grant.lik...@secretlab.ca wrote: Well, I've got to start somewhere... So here goes. I've begun the work to merge and clean up the OF device tree handling code and this is my first set of patches. Not fully tested yet, but I'm getting them out to the lists so that I can start responding to comments and collecting acks. This first batch isn't anything exciting, just a merge of common code Shoot most of what I wrote got trimmed accidentally. Here's the rest of the text: However, I've completely devoted to this work for at least the next two months, so there are plenty more patches to follow. Once I've got all the common code merged between Microblaze, PowerPC and Sparc I'll be fix the endian problems and making it easily usable by other architectures like ARM and MIPS. Lots of work to be done. As for merging this stuff, because the patches cross architecture boundaries, I've been thinking of publishing a new git tree for collecting device tree related changes and getting it added to the linux-next tree list. I'll commit changes to that tree once I get acks from each of the affected arch maintainers. Then, either Linus can pull my tree directly, or I could ask a more senior maintainer to pull into their tree before sending a pull request to Linus. Ben, David and Michal, how does that sound to you? Stephen, would you be willing to add my tree to the linux-next list? Also, I'd like to take on responsibility for maintaining the cross- architecture device tree code. If there are no objections, I'll write a patch to add a device tree section to MAINTAINERS. Cheers, g. --- Grant Likely (12): of: merge of_find_all_nodes() implementations of: merge other miscellaneous prototypes of: merge of_*_flat_dt*() functions of: merge of_node_get(), of_node_put() and of_find_all_nodes() of: merge of_read_number() an of_read_ulong() of: merge of_node_*_flag() and set_node_proc_entry() of: merge struct boot_param_header from Microblaze and PowerPC of: add common header for flattened device tree representation of: Move OF_IS_DYNAMIC and OF_MARK_DYNAMIC macros to of.h of: merge struct device_node of: merge phandle, ihandle and struct property of: Rework linux/of.h and asm/prom.h include ordering arch/microblaze/include/asm/prom.h | 135 + arch/microblaze/kernel/prom.c | 23 -- arch/powerpc/include/asm/prom.h | 147 arch/powerpc/kernel/prom.c | 23 -- arch/sparc/include/asm/prom.h | 55 - drivers/of/base.c | 26 ++ include/linux/of.h | 103 + include/linux/of_fdt.h | 87 + 8 files changed, 221 insertions(+), 378 deletions(-) create mode 100644 include/linux/of_fdt.h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code
On Wed, Oct 7, 2009 at 14:49, Grant Likely grant.lik...@secretlab.ca wrote: On Tue, Oct 6, 2009 at 10:29 PM, Grant Likely grant.lik...@secretlab.ca wrote: So here goes. I've begun the work to merge and clean up the OF device tree handling code and this is my first set of patches. Not fully tested yet, but I'm getting them out to the lists so that I can start responding to comments and collecting acks. This first batch isn't anything exciting, just a merge of common code Good work, for what it's worth, this all looks good to me. However, I've completely devoted to this work for at least the next two months, so there are plenty more patches to follow. Once I've got all the common code merged between Microblaze, PowerPC and Sparc I'll be fix the endian problems and making it easily usable by other architectures like ARM and MIPS. Lots of work to be done. On the subject of merging code, I know that the SUN3 code in m68k uses a similar prom interface to the sparc32 code. (and I've also considered unifying that and ... well ... see above) Does anyone know if it has an OpenFirmware interface for it's devices? Is OF on SUN3 even remotely useful? Does Linux on SUN3 even work with modern kernels? Another issue is that there is at least one driver in the kernel that depends on both PPC and OF to work around the differences in the implementations of OpenFirmware on Sparc and PowerPC. (I submitted a patch for it, but can't remember the driver's name) Whilst the driver's author assures me that the hardware will never go anywhere near Sparc, it can't hurt to drop the dependency on PPC for additional compile testing coverage - and because it's the Right Thing. (and the reduction of cheap hacks like this can't be bad either.) Other than that, good work, and keep going. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com .Plan: http://sites.google.com/site/juliancalaby/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
