summaryrefslogtreecommitdiff
path: root/arch/sparc64/kernel/of_device.c
AgeCommit message (Collapse)Author
2008-07-21sparc64: fix up bus_id changes in sparc core codeGreg Kroah-Hartman
This converts all instances of bus_id in the sparc core kernel to use either dev_set_name(), or dev_name() depending on the need. This is done in anticipation of removing the bus_id field from struct driver. Cc: Kay Sievers <kay.sievers@vrfy.org> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-26sparc64: Do not ignore 'pmu' device ranges.David S. Miller
I must have disabled this due to other bugs which were fixed over time. And this is needed in order for child devices of "pmu" to get proper resource values. Signed-off-by: David S. Miller <davem@davemloft.net>
2008-04-23[SPARC64]: NUMA device infrastructure.David S. Miller
Record and propagate NUMA information for devices. Signed-off-by: David S. Miller <davem@davemloft.net>
2008-02-09[SPARC]: Remove of_platform_device_createStephen Rothwell
There are no callers of this on the Sparc platforms. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-10-17[SPARC/64]: Consolidate of_register_driverStephen Rothwell
Also of_unregister_driver. These will be shortly also used by the PowerPC code. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-10-13[SPARC/64]: Prepare to remove of_platform_driver name.Stephen Rothwell
The name field of of_platform_driver is just copied into the included device_driver. By not overriding an already initialised device_driver name, we can convert the drivers over time to stop using the of_platform_driver name. Also we were not copying the owner field from of_platform_driver, so do the same with it. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-07-20[SPARC]: Make sure dev_archdata is filled in for all devices.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-07-20Create drivers/of/platform.cStephen Rothwell
and populate it with the common parts from PowerPC and Sparc[64]. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Acked-by: Paul Mackerras <paulus@samba.org> Acked-by: David S. Miller <davem@davemloft.net>
2007-07-20[SPARC/64] Rename some functions like PowerPCStephen Rothwell
This is to make the of merge easier. Also rename of_bus_type. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Acked-by: David S. Miller <davem@davemloft.net>
2007-07-20Begin to consolidate of_device.cStephen Rothwell
This moves all the common parts for the Sparc, Sparc64 and PowerPC of_device.c files into drivers/of/device.c. Apart from the simple move, Sparc gains of_match_node() and a call to of_node_put in of_release_dev(). PowerPC gains better recovery if device_create_file() fails in of_device_register(). Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Acked-by: Paul Mackerras <paulus@samba.org> Acked-by: David S. Miller <davem@davemloft.net>
2007-06-07[SPARC64]: Handle PCI bridges without 'ranges' property.David S. Miller
This fixes the IDE controller not showing up on Netra-T1 systems. Just like Simba bridges, some PCI bridges can lack the 'ranges' OBP property. So we handle this similarly to the existing Simba code: 1) In of_device register address resolving, we push the translation to the parent. 2) In PCI device scanning, we interrogate the PCI config space registers of the PCI bus device in order to resolve the resources, just like the generic Linux PCI probing code does. With much help and testing from Fabio, who also reported the initial problem. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Fabio Massimo Di Nitto <fabbione@ubuntu.com>
2007-05-13[SPARC64]: Be more resiliant with PCI I/O space regs.David S. Miller
If we miss on the ranges, just toss the translation up to the parent instead of failing. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-05-11[SPARC64]: Spelling fixes.Simon Arlott
Spelling fixes in arch/sparc64/. Signed-off-by: Simon Arlott <simon@fire.lp0.eu> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-26[SPARC64]: Fix PCI rework to adhere to of_get_property() const return.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-26[SPARC64]: Kill pbm->pci_first_slot.David S. Miller
Set but never used. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-26[SPARC64]: Fix sabre pci controllers with new probing scheme.David S. Miller
The SIMBA APB bridge is strange, it is a PCI bridge but it lacks some standard OF properties, in particular it lacks a 'ranges' property. What you have to do is read the IO and MEM range registers in the APB bridge to determine the ranges handled by each bridge. So fill in the bus resources by doing that. Since we now handle this quirk in the generic PCI and OF device probing layers, we can flat out eliminate all of that code from the sabre pci controller driver. In fact we can thus eliminate completely another quirk of the sabre driver. It tried to make the two APB bridges look like PBMs but that makes zero sense now (and it's questionable whether it ever made sense). So now just use pbm_A and probe the whole PCI hierarchy using that as the root. This simplification allows many future cleanups to occur. Also, I've found yet another quirk that needs to be worked around while testing this. You can't use the 'class-code' OF firmware property, especially for IDE controllers. We have to read the value out of PCI config space or else we'll see the value the device was showing before it was programmed into native mode. I'm starting to think it might be wise to just read all of the values out of PCI config space instead of using the OF properties. :-/ Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-26[SPARC64]: constify of_get_property return: arch/sparc64Stephen Rothwell
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-03-02[SPARC]: Handle unresolvable resources better in of_device.cDavid S. Miller
Just leave them as zero if we couldn't calculate it. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-03-02[SPARC]: Fix bus handling in build_device_resources().David S. Miller
We mistakedly modify 'bus' in the innermost loop. What should happen is that at each register index iteration, we start with the same 'bus'. So preserve it's value at the top level, and use a loop local variable 'dbus' for iteration. This bug causes registers other than the first to be decoded improperly. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-02-27[SPARC64]: Fix PCI interrupts on E450 et al.David S. Miller
When the PCI controller OBP node lacks an interrupt-map and interrupt-map-mask property, we need to form the INO by hand. The PCI swizzle logic was not doing that properly. This was a regression added by the of_device code. Signed-off-by: David S. Miller <davem@davemloft.net>
2006-12-31[SPARC64]: Fix of_iounmap() region release.David S. Miller
We need to pass in the resource otherwise we cannot release the region properly. We must know whether it is an I/O or MEM resource. Spotted by Eric Brower. Signed-off-by: David S. Miller <davem@davemloft.net>
2006-12-10[SPARC64]: Replace kmalloc+memset with kzallocYan Burman
Replace kmalloc+memset with kzalloc Signed-off-by: Yan Burman <burman.yan@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2006-10-27[SPARC]: Fix bus_id[] string overflow.David S. Miller
dp->path_component_name can be larger than ->bus_id[] so use a different naming scheme for this stuff. Noticed by Jurij Smakov. Signed-off-by: David S. Miller <davem@davemloft.net>
2006-10-25[SPARC64]: Fix central/FHC bus handling on Ex000 systems.David S. Miller
1) probe_other_fhcs() wants to see only non-central FHC busses, so skip FHCs that don't sit off the root 2) Like SBUS, FHC can lack the appropriate address and size cell count properties, so add an of_busses[] entry and handlers for that. 3) Central FHC irq translator probing was buggy. We were trying to use dp->child in irq_trans_init but that linkage is not setup at this point. So instead, pass in the parent of "dp" and look for the child "fhc" with parent "central". Thanks to the tireless assistence of Ben Collins in tracking down these problems and testing out these fixes. Signed-off-by: David S. Miller <davem@davemloft.net>
2006-10-19[SPARC64]: Fix of_ioremap().David S. Miller
Use request_mem_region() if IORESOURCE_MEM. Signed-off-by: David S. Miller <davem@davemloft.net>
2006-10-09[SPARC64]: Fix of_device bus_id settings.David S. Miller
They have to be unique system-wide, so use "NAME@NODE" as the string pattern of the non-root nodes. Thanks to Andrew Morton for fixing the error value checking in bus_add_device() which made this problem finally noticable. Signed-off-by: David S. Miller <davem@davemloft.net>
2006-10-04Remove all inclusions of <linux/config.h>Dave Jones
kbuild explicitly includes this at build time. Signed-off-by: Dave Jones <davej@redhat.com>
2006-07-21[SPARC64]: Fix more of_device layer IRQ bugs, and correct PROMREG_MAX.David S. Miller
Sabre and Psycho PCI controllers can have partial interrupt-map properties, meaning that on-board devices don't match up to any entries. Instead, they are fully specified from the beginning and we should pass them directly to the IRQ translator as-is. Also, fill in the necessary translator slots for the "graphics" and "expansion UPA" interrupts on Sabre, Psycho, and SYSIO SBUS. Increase PROMREG_MAX to 24, as seen on SUNW,ffb devices. Finally, prevent accidentally writing past the end of the of_device struct resource[] and irqs[] arrays. Spit out a log message when we ignore some entries because there are too many of them. Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13[SPARC]: Fix OF register translations under sub-PCI busses.David S. Miller
There is an implicit assumption in the code that ranges will translate to something that can fit in 2 32-bit cells, or a 64-bit value. For certain kinds of things below PCI this isn't necessarily true. Here is what the relevant OF device hierarchy looks like for one of the serial controllers on an Ultra5: Node 0xf005f1e0 ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000 01000000.00000000.00000000.000001fe.02000000.00000000.01000000 02000000.00000000.00000000.000001ff.00000000.00000001.00000000 03000000.00000000.00000000.000001ff.00000000.00000001.00000000 device_type: 'pci' model: 'SUNW,sabre' Node 0xf005f9d4 device_type: 'pci' model: 'SUNW,simba' Node 0xf0060d24 ranges: 00000010.00000000 82010810.00000000.f0000000 01000000 00000014.00000000 82010814.00000000.f1000000 00800000 name: 'ebus' Node 0xf0062dac reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8 device_type: 'serial' name: 'su' So the correct translation here is: 1) Match "su" register to second ranges entry of 'ebus', which translates into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which gives us "82010814.00000000.f13083f8". 2) Pass-through "SUNW,simba" since it lacks ranges property 3) Match "82010814.00000000.f13083f8" to third ranges property of PCI controller node 'SUNW,sabre', and we arrive at the final physical MMIO address of "0x1fff13083f8". Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell value, and we couldn't perform a pass-thru on it either. It was easiest to just stop splitting the ranges application operation between two methods, ->map and ->translate, and just let ->map do all the work. That way it would work purely on 32-bit cell arrays instead of having to "return" some value like a u64. It's still not %100 correct because the out-of-range check is still done using the 64 least significant bits of the range and address. But it does work for all the cases I've thrown at it so far. Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-13[SPARC64]: of_device_register() error checking fixAndrew Morton
device_create_file() can fail. This causes the sparc64 compile to fail when my fanatical __must_check patch is applied, due to -Werror. [ Added necessary identical fix for sparc32. -DaveM] Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2006-06-30[SPARC64]: Mask out top 8-bits in physical address when building resources.David S. Miller
These top 8-bits are supposed to be ignored in the ranges and top-level reg properties on this platform. Signed-off-by: David S. Miller <davem@davemloft.net>
2006-06-29[SPARC64]: of_device layer IRQ resolutionDavid S. Miller
Do IRQ determination generically by parsing the PROM properties, and using IRQ controller drivers for final resolution. One immediate positive effect is that all of the IRQ frobbing in the EBUS, ISA, and PCI controller layers has been eliminated. We just look up the of_device and use the properly computed value. The PCI controller irq_build() routines are gone and no longer used. Unfortunately sbus_build_irq() has to remain as there is a direct reference to this in the sunzilog driver. That can be killed off once the sparc32 side of this is written and the sunzilog driver is transformed into an "of" bus driver. Signed-off-by: David S. Miller <davem@davemloft.net>
2006-06-29[SPARC]: Add of_io{remap,unmap}().David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-06-29[SPARC]: Beginnings of generic of_device framework.David S. Miller
The idea is to fully construct the device register and interrupt values into these of_device objects, and convert all of SBUS, EBUS, ISA drivers to use this new stuff. Much ideas and code taken from Ben H.'s powerpc work. Signed-off-by: David S. Miller <davem@davemloft.net>
2006-06-25[SPARC]: Export x_bus_type to modules.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-06-23[SPARC64]: Add of_device layer and make ebus/isa use it.David S. Miller
Sparcspkr and power drivers are converted, to make sure it works. Eventually the SBUS device layer will use this as a sub-class. I really cannot cut loose on that bit until sparc32 is given the same infrastructure. Signed-off-by: David S. Miller <davem@davemloft.net>