Removing full paths from DT full_name
Subsystems (8)
Rob Herring
maintainerv2 cover Removing full paths from DT full_name
This series is the last steps to remove storing the full path for every DT node. Instead, we can create full path strings dynamically as needed with printf %pOF specifiers (commit ce4fecf1fe15). There are a number of remaining direct users of full_name after this series. I don't believe there should be any functional impact for those users with the change to only the node name (+unit-address). The majority are for struct resource.name. This should only affect /proc/iomem display.
Michael, Please apply patches 1-3 for 4.14. Patches 4 and 5 are intended for 4.15. Testing of those in particular would be helpful.
Rob
Rob Herring (5):
powerpc: Convert to using %pOF instead of full_name
powerpc: pseries: vio: match parent nodes with of_find_node_by_path
powerpc: pseries: remove dlpar_attach_node dependency on full path
powerpc: pseries: only store the device node basename in full_name of/fdt: only store the device node basename in full_name
arch/powerpc/kernel/btext.c | 2 +- arch/powerpc/kernel/cacheinfo.c | 34 ++++--- arch/powerpc/kernel/io-workarounds.c | 4 +- arch/powerpc/kernel/isa-bridge.c | 32 +++---- arch/powerpc/kernel/legacy_serial.c | 12 +-- arch/powerpc/kernel/of_platform.c | 2 +- arch/powerpc/kernel/pci-common.c | 15 ++- arch/powerpc/kernel/pci_32.c | 4 +- arch/powerpc/kernel/pci_64.c | 4 +- arch/powerpc/kernel/pci_of_scan.c | 24 ++--- arch/powerpc/kernel/setup-common.c | 2 +- arch/powerpc/platforms/4xx/cpm.c | 8 +- arch/powerpc/platforms/4xx/gpio.c | 3 +- arch/powerpc/platforms/4xx/msi.c | 3 +- arch/powerpc/platforms/4xx/pci.c | 116 ++++++++++------------- arch/powerpc/platforms/4xx/soc.c | 5 +- arch/powerpc/platforms/4xx/uic.c | 14 +-- arch/powerpc/platforms/512x/mpc512x_shared.c | 12 +-- arch/powerpc/platforms/52xx/efika.c | 8 +- arch/powerpc/platforms/52xx/media5200.c | 2 +- arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 4 +- arch/powerpc/platforms/52xx/mpc52xx_pci.c | 8 +- arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 3 +- arch/powerpc/platforms/83xx/mpc832x_rdb.c | 2 +- arch/powerpc/platforms/85xx/p1022_ds.c | 8 +- arch/powerpc/platforms/85xx/xes_mpc85xx.c | 4 +- arch/powerpc/platforms/amigaone/setup.c | 6 +- arch/powerpc/platforms/cell/axon_msi.c | 36 +++---- arch/powerpc/platforms/cell/interrupt.c | 4 +- arch/powerpc/platforms/cell/iommu.c | 24 ++--- arch/powerpc/platforms/cell/ras.c | 4 +- arch/powerpc/platforms/cell/spider-pci.c | 4 +- arch/powerpc/platforms/cell/spider-pic.c | 4 +- arch/powerpc/platforms/cell/spu_manage.c | 26 ++--- arch/powerpc/platforms/chrp/pci.c | 18 ++-- arch/powerpc/platforms/embedded6xx/linkstation.c | 6 +- arch/powerpc/platforms/embedded6xx/mvme5100.c | 2 +- arch/powerpc/platforms/embedded6xx/storcenter.c | 2 +- arch/powerpc/platforms/maple/pci.c | 10 +- arch/powerpc/platforms/pasemi/pci.c | 2 +- arch/powerpc/platforms/powermac/feature.c | 14 +-- arch/powerpc/platforms/powermac/low_i2c.c | 50 +++++----- arch/powerpc/platforms/powermac/pci.c | 6 +- arch/powerpc/platforms/powermac/pfunc_base.c | 24 ++--- arch/powerpc/platforms/powermac/pfunc_core.c | 6 +- arch/powerpc/platforms/powermac/pic.c | 8 +- arch/powerpc/platforms/powermac/setup.c | 2 +- arch/powerpc/platforms/powernv/opal-async.c | 4 +- arch/powerpc/platforms/powernv/opal-xscom.c | 8 +- arch/powerpc/platforms/powernv/pci-ioda.c | 15 ++- arch/powerpc/platforms/powernv/rng.c | 6 +- arch/powerpc/platforms/pseries/dlpar.c | 39 ++------ arch/powerpc/platforms/pseries/event_sources.c | 6 +- arch/powerpc/platforms/pseries/hotplug-cpu.c | 6 +- arch/powerpc/platforms/pseries/ibmebus.c | 5 +- arch/powerpc/platforms/pseries/iommu.c | 58 ++++++------ arch/powerpc/platforms/pseries/mobility.c | 2 +- arch/powerpc/platforms/pseries/msi.c | 12 +-- arch/powerpc/platforms/pseries/pci_dlpar.c | 2 +- arch/powerpc/platforms/pseries/pseries.h | 2 +- arch/powerpc/platforms/pseries/reconfig.c | 2 +- arch/powerpc/platforms/pseries/vio.c | 10 +- arch/powerpc/sysdev/axonram.c | 4 +- arch/powerpc/sysdev/dcr.c | 4 +- arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 12 +-- arch/powerpc/sysdev/fsl_gtm.c | 14 +-- arch/powerpc/sysdev/fsl_msi.c | 16 ++-- arch/powerpc/sysdev/fsl_pci.c | 47 +++++---- arch/powerpc/sysdev/fsl_rio.c | 36 +++---- arch/powerpc/sysdev/fsl_rmu.c | 12 +-- arch/powerpc/sysdev/mpic.c | 4 +- arch/powerpc/sysdev/mpic_msgr.c | 2 +- arch/powerpc/sysdev/mpic_msi.c | 2 +- arch/powerpc/sysdev/mpic_timer.c | 19 ++-- arch/powerpc/sysdev/msi_bitmap.c | 4 +- arch/powerpc/sysdev/mv64x60_dev.c | 20 ++-- arch/powerpc/sysdev/mv64x60_pci.c | 4 +- arch/powerpc/sysdev/of_rtc.c | 12 +-- arch/powerpc/sysdev/scom.c | 5 +- arch/powerpc/sysdev/simple_gpio.c | 3 +- arch/powerpc/sysdev/tsi108_pci.c | 4 +- arch/powerpc/sysdev/xive/native.c | 2 +- drivers/of/fdt.c | 69 +++----------- 83 files changed, 487 insertions(+), 578 deletions(-)
Signature · 6 lines
2.11.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Rob Herring
maintainerPATCH v2 1/5 powerpc: Convert to using %pOF instead of full_name
Now that we have a custom printf format specifier, convert users of full_name to use %pOF instead. This is preparation to remove storing of the full path string for each node.
---
v2:
- drop spurious vio.c vio_register_device_node() change
arch/powerpc/kernel/btext.c | 2 +- arch/powerpc/kernel/cacheinfo.c | 34 ++++--- arch/powerpc/kernel/io-workarounds.c | 4 +- arch/powerpc/kernel/isa-bridge.c | 32 +++---- arch/powerpc/kernel/legacy_serial.c | 12 +-- arch/powerpc/kernel/of_platform.c | 2 +- arch/powerpc/kernel/pci-common.c | 15 ++- arch/powerpc/kernel/pci_32.c | 4 +- arch/powerpc/kernel/pci_64.c | 4 +- arch/powerpc/kernel/pci_of_scan.c | 24 ++--- arch/powerpc/kernel/setup-common.c | 2 +- arch/powerpc/platforms/4xx/cpm.c | 8 +- arch/powerpc/platforms/4xx/gpio.c | 3 +- arch/powerpc/platforms/4xx/msi.c | 3 +- arch/powerpc/platforms/4xx/pci.c | 116 ++++++++++------------- arch/powerpc/platforms/4xx/soc.c | 5 +- arch/powerpc/platforms/4xx/uic.c | 14 +-- arch/powerpc/platforms/512x/mpc512x_shared.c | 12 +-- arch/powerpc/platforms/52xx/efika.c | 8 +- arch/powerpc/platforms/52xx/media5200.c | 2 +- arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 4 +- arch/powerpc/platforms/52xx/mpc52xx_pci.c | 8 +- arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 3 +- arch/powerpc/platforms/83xx/mpc832x_rdb.c | 2 +- arch/powerpc/platforms/85xx/p1022_ds.c | 8 +- arch/powerpc/platforms/85xx/xes_mpc85xx.c | 4 +- arch/powerpc/platforms/amigaone/setup.c | 6 +- arch/powerpc/platforms/cell/axon_msi.c | 36 +++---- arch/powerpc/platforms/cell/interrupt.c | 4 +- arch/powerpc/platforms/cell/iommu.c | 24 ++--- arch/powerpc/platforms/cell/ras.c | 4 +- arch/powerpc/platforms/cell/spider-pci.c | 4 +- arch/powerpc/platforms/cell/spider-pic.c | 4 +- arch/powerpc/platforms/cell/spu_manage.c | 26 ++--- arch/powerpc/platforms/chrp/pci.c | 18 ++-- arch/powerpc/platforms/embedded6xx/linkstation.c | 6 +- arch/powerpc/platforms/embedded6xx/mvme5100.c | 2 +- arch/powerpc/platforms/embedded6xx/storcenter.c | 2 +- arch/powerpc/platforms/maple/pci.c | 10 +- arch/powerpc/platforms/pasemi/pci.c | 2 +- arch/powerpc/platforms/powermac/feature.c | 14 +-- arch/powerpc/platforms/powermac/low_i2c.c | 50 +++++----- arch/powerpc/platforms/powermac/pci.c | 6 +- arch/powerpc/platforms/powermac/pfunc_base.c | 24 ++--- arch/powerpc/platforms/powermac/pfunc_core.c | 6 +- arch/powerpc/platforms/powermac/pic.c | 8 +- arch/powerpc/platforms/powermac/setup.c | 2 +- arch/powerpc/platforms/powernv/opal-async.c | 4 +- arch/powerpc/platforms/powernv/opal-xscom.c | 8 +- arch/powerpc/platforms/powernv/pci-ioda.c | 15 ++- arch/powerpc/platforms/powernv/rng.c | 6 +- arch/powerpc/platforms/pseries/dlpar.c | 3 +- arch/powerpc/platforms/pseries/event_sources.c | 6 +- arch/powerpc/platforms/pseries/hotplug-cpu.c | 4 +- arch/powerpc/platforms/pseries/ibmebus.c | 5 +- arch/powerpc/platforms/pseries/iommu.c | 58 ++++++------ arch/powerpc/platforms/pseries/msi.c | 12 +-- arch/powerpc/platforms/pseries/pci_dlpar.c | 2 +- arch/powerpc/platforms/pseries/vio.c | 6 +- arch/powerpc/sysdev/axonram.c | 4 +- arch/powerpc/sysdev/dcr.c | 4 +- arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 12 +-- arch/powerpc/sysdev/fsl_gtm.c | 14 +-- arch/powerpc/sysdev/fsl_msi.c | 16 ++-- arch/powerpc/sysdev/fsl_pci.c | 47 +++++---- arch/powerpc/sysdev/fsl_rio.c | 36 +++---- arch/powerpc/sysdev/fsl_rmu.c | 12 +-- arch/powerpc/sysdev/mpic.c | 4 +- arch/powerpc/sysdev/mpic_msgr.c | 2 +- arch/powerpc/sysdev/mpic_msi.c | 2 +- arch/powerpc/sysdev/mpic_timer.c | 19 ++-- arch/powerpc/sysdev/msi_bitmap.c | 4 +- arch/powerpc/sysdev/mv64x60_dev.c | 20 ++-- arch/powerpc/sysdev/mv64x60_pci.c | 4 +- arch/powerpc/sysdev/of_rtc.c | 12 +-- arch/powerpc/sysdev/scom.c | 5 +- arch/powerpc/sysdev/simple_gpio.c | 3 +- arch/powerpc/sysdev/tsi108_pci.c | 4 +- arch/powerpc/sysdev/xive/native.c | 2 +- 79 files changed, 461 insertions(+), 487 deletions(-)
arch/powerpc/kernel/btext.c +1 -1
@@ -253,7 +253,7 @@ int __init btext_find_display(int allow_nonstdout)for_each_node_by_type (np,"display" ) {if (of_get_property (np,"linux,opened" ,NULL )) { -printk ("trying %s ...\n" , np->full_name); +printk ("trying %pOF ...\n" , np); rc =btext_initialize (np);printk ("result: %d\n" , rc); }
arch/powerpc/kernel/cacheinfo.c +16 -18
@@ -167,10 +167,10 @@ static void release_cache_debugcheck(struct cache *cache)list_for_each_entry (iter, &cache_list, list)WARN_ONCE (iter->next_local == cache, -"cache for %s(%s) refers to cache for %s(%s)\n" , - iter->ofnode->full_name, +"cache for %pOF(%s) refers to cache for %pOF(%s)\n" , + iter->ofnode,cache_type_string (iter), - cache->ofnode->full_name, + cache->ofnode,cache_type_string (cache)); }
@@ -179,8 +179,8 @@ static void release_cache(struct cache *cache)if (!cache)return ; -pr_debug ("freeing L%d %s cache for %s\n" , cache->level, -cache_type_string (cache), cache->ofnode->full_name); +pr_debug ("freeing L%d %s cache for %pOF\n" , cache->level, +cache_type_string (cache), cache->ofnode);release_cache_debugcheck (cache);list_del (&cache->list);
@@ -194,8 +194,8 @@ static void cache_cpu_set(struct cache *cache, int cpu)while (next) {WARN_ONCE (cpumask_test_cpu (cpu, &next->shared_cpu_map), -"CPU %i already accounted in %s(%s)\n" , - cpu, next->ofnode->full_name, +"CPU %i already accounted in %pOF(%s)\n" , + cpu, next->ofnode,cache_type_string (next));cpumask_set_cpu (cpu, &next->shared_cpu_map); next = next->next_local;
@@ -355,7 +355,7 @@ static int cache_is_unified_d(const struct device_node *np)*/ static struct cache *cache_do_one_devnode_unified (struct device_node *node,int level) { -pr_debug ("creating L%d ucache for %s\n" , level, node->full_name); +pr_debug ("creating L%d ucache for %pOF\n" , level, node);return new_cache (cache_is_unified_d (node), level, node); }
@@ -365,8 +365,8 @@ static struct cache *cache_do_one_devnode_split(struct device_node *node, {struct cache *dcache, *icache; -pr_debug ("creating L%d dcache and icache for %s\n" , level, - node->full_name); +pr_debug ("creating L%d dcache and icache for %pOF\n" , level, + node); dcache =new_cache (CACHE_TYPE_DATA , level, node); icache =new_cache (CACHE_TYPE_INSTRUCTION , level, node);
@@ -679,7 +679,6 @@ static struct kobj_type cache_index_type = {static void cacheinfo_create_index_opt_attrs (struct cache_index_dir *dir) { -const char *cache_name;const char *cache_type;struct cache *cache;char *buf;
@@ -690,7 +689,6 @@ static void cacheinfo_create_index_opt_attrs(struct cache_index_dir *dir)return ; cache = dir->cache; - cache_name = cache->ofnode->full_name; cache_type =cache_type_string (cache);/* We don't want to create an attribute that can't provide a
@@ -707,14 +705,14 @@ static void cacheinfo_create_index_opt_attrs(struct cache_index_dir *dir) rc = attr->show (&dir->kobj, attr, buf);if (rc <=0 ) {pr_debug ("not creating %s attribute for " -"%s(%s) (rc = %zd)\n" , - attr->attr.name, cache_name, +"%pOF(%s) (rc = %zd)\n" , + attr->attr.name, cache->ofnode, cache_type, rc);continue ; }if (sysfs_create_file (&dir->kobj, &attr->attr)) -pr_debug ("could not create %s attribute for %s(%s)\n" , - attr->attr.name, cache_name, cache_type); +pr_debug ("could not create %s attribute for %pOF(%s)\n" , + attr->attr.name, cache->ofnode, cache_type); }kfree (buf);
@@ -831,8 +829,8 @@ static void cache_cpu_clear(struct cache *cache, int cpu)struct cache *next = cache->next_local;WARN_ONCE (!cpumask_test_cpu (cpu, &cache->shared_cpu_map), -"CPU %i not accounted in %s(%s)\n" , - cpu, cache->ofnode->full_name, +"CPU %i not accounted in %pOF(%s)\n" , + cpu, cache->ofnode,cache_type_string (cache));cpumask_clear_cpu (cpu, &cache->shared_cpu_map);
arch/powerpc/kernel/io-workarounds.c +2 -2
@@ -192,7 +192,7 @@ void iowa_register_bus(struct pci_controller *phb, struct ppc_pci_io *ops,if (iowa_bus_count >=IOWA_MAX_BUS ) {pr_err ("IOWA:Too many pci bridges, " -"workarounds disabled for %s\n" , np->full_name); +"workarounds disabled for %pOF\n" , np);return ; }
@@ -207,6 +207,6 @@ void iowa_register_bus(struct pci_controller *phb, struct ppc_pci_io *ops, iowa_bus_count++; -pr_debug ("IOWA:[%d]Add bus, %s.\n" , iowa_bus_count-1 , np->full_name); +pr_debug ("IOWA:[%d]Add bus, %pOF.\n" , iowa_bus_count-1 , np); }
arch/powerpc/kernel/isa-bridge.c +16 -16
@@ -164,7 +164,7 @@ void __init isa_bridge_find_early(struct pci_controller *hose)/* Set the global ISA io base to indicate we have an ISA bridge */ isa_io_base =ISA_IO_BASE ; -pr_debug ("ISA bridge (early) is %s\n" , np->full_name); +pr_debug ("ISA bridge (early) is %pOF\n" , np); }/**
@@ -187,15 +187,15 @@ void __init isa_bridge_init_non_pci(struct device_node *np) pna =of_n_addr_cells (np);if (of_property_read_u32 (np,"#address-cells" , &na) ||of_property_read_u32 (np,"#size-cells" , &ns)) { -pr_warn ("ISA: Non-PCI bridge %s is missing address format\n" , - np->full_name); +pr_warn ("ISA: Non-PCI bridge %pOF is missing address format\n" , + np);return ; }/* Check it's a supported address format */ if (na !=2 || ns !=1 ) { -pr_warn ("ISA: Non-PCI bridge %s has unsupported address format\n" , - np->full_name); +pr_warn ("ISA: Non-PCI bridge %pOF has unsupported address format\n" , + np);return ; } rs = na + ns + pna;
@@ -203,8 +203,8 @@ void __init isa_bridge_init_non_pci(struct device_node *np)/* Grab the ranges property */ ranges =of_get_property (np,"ranges" , &rlen);if (ranges ==NULL || rlen < rs) { -pr_warn ("ISA: Non-PCI bridge %s has absent or invalid ranges\n" , - np->full_name); +pr_warn ("ISA: Non-PCI bridge %pOF has absent or invalid ranges\n" , + np);return ; }
@@ -220,8 +220,8 @@ void __init isa_bridge_init_non_pci(struct device_node *np)/* Got something ? */ if (!size || !pbasep) { -pr_warn ("ISA: Non-PCI bridge %s has no usable IO range\n" , - np->full_name); +pr_warn ("ISA: Non-PCI bridge %pOF has no usable IO range\n" , + np);return ; }
@@ -233,15 +233,15 @@ void __init isa_bridge_init_non_pci(struct device_node *np)/* Map pbase */ pbase =of_translate_address (np, pbasep);if (pbase ==OF_BAD_ADDR ) { -pr_warn ("ISA: Non-PCI bridge %s failed to translate IO base\n" , - np->full_name); +pr_warn ("ISA: Non-PCI bridge %pOF failed to translate IO base\n" , + np);return ; }/* We need page alignment */ if ((cbase & ~PAGE_MASK ) || (pbase & ~PAGE_MASK )) { -pr_warn ("ISA: Non-PCI bridge %s has non aligned IO range\n" , - np->full_name); +pr_warn ("ISA: Non-PCI bridge %pOF has non aligned IO range\n" , + np);return ; }
@@ -255,7 +255,7 @@ void __init isa_bridge_init_non_pci(struct device_node *np)__ioremap_at (pbase, (void *)ISA_IO_BASE , size,pgprot_val (pgprot_noncached (__pgprot (0 )))); -pr_debug ("ISA: Non-PCI bridge is %s\n" , np->full_name); +pr_debug ("ISA: Non-PCI bridge is %pOF\n" , np); }/**
@@ -277,8 +277,8 @@ static void isa_bridge_find_late(struct pci_dev *pdev,/* Set the global ISA io base to indicate we have an ISA bridge */ isa_io_base =ISA_IO_BASE ; -pr_debug ("ISA bridge (late) is %s on %s\n" , - devnode->full_name,pci_name (pdev)); +pr_debug ("ISA bridge (late) is %pOF on %s\n" , + devnode,pci_name (pdev)); }/**
arch/powerpc/kernel/legacy_serial.c +6 -6
@@ -147,8 +147,8 @@ static int __init add_legacy_port(struct device_node *np, int want_index, legacy_serial_ports[index].serial_out = tsi_serial_out; } -printk (KERN_DEBUG "Found legacy serial port %d for %s\n" , - index, np->full_name); +printk (KERN_DEBUG "Found legacy serial port %d for %pOF\n" , + index, np); printk(KERN_DEBUG " %s=%llx, taddr=%llx, irq=%lx, clk=%d, speed=%d\n", (iotype == UPIO_PORT) ? "port" : "mem", (unsigned long long)base, (unsigned long long)taddr, irq,
@@ -207,7 +207,7 @@ static int __init add_legacy_isa_port(struct device_node *np,int index =-1 ;u64 taddr; -DBG (" -> add_legacy_isa_port(%s)\n" , np->full_name); +DBG (" -> add_legacy_isa_port(%pOF)\n" , np);/* Get the ISA port number */ reg =of_get_property (np,"reg" ,NULL );
@@ -256,7 +256,7 @@ static int __init add_legacy_pci_port(struct device_node *np,unsigned int flags;int iotype, index =-1 , lindex =0 ; -DBG (" -> add_legacy_pci_port(%s)\n" , np->full_name); +DBG (" -> add_legacy_pci_port(%pOF)\n" , np);/* We only support ports that have a clock frequency properly * encoded in the device-tree (that is have an fcode). Anything
@@ -374,7 +374,7 @@ void __init find_legacy_serial_ports(void)if (path !=NULL ) { stdout =of_find_node_by_path (path);if (stdout) -DBG ("stdout is %s\n" , stdout->full_name); +DBG ("stdout is %pOF\n" , stdout); }else {DBG (" no linux,stdout-path !\n" ); }
@@ -603,7 +603,7 @@ static int __init check_legacy_serial_console(void)DBG (" can't find stdout package %s !\n" , name);return -ENODEV ; } -DBG ("stdout is %s\n" , prom_stdout->full_name); +DBG ("stdout is %pOF\n" , prom_stdout); name =of_get_property (prom_stdout,"name" ,NULL );if (!name) {
arch/powerpc/kernel/of_platform.c +1 -1
@@ -45,7 +45,7 @@ static int of_pci_phb_probe(struct platform_device *dev)if (ppc_md.pci_setup_phb ==NULL )return -ENODEV ; -pr_info ("Setting up PCI bus %s\n" , dev->dev.of_node->full_name); +pr_info ("Setting up PCI bus %pOF\n" , dev->dev.of_node);/* Alloc and setup PHB data structure */ phb =pcibios_alloc_controller (dev->dev.of_node);
arch/powerpc/kernel/pci-common.c +7 -8
@@ -373,9 +373,8 @@ static int pci_read_irq_line(struct pci_dev *pci_dev)if (virq)irq_set_irq_type (virq,IRQ_TYPE_LEVEL_LOW ); }else { -pr_debug (" Got one, spec %d cells (0x%08x 0x%08x...) on %s\n" , - oirq.args_count, oirq.args[0 ], oirq.args[1 ], -of_node_full_name (oirq.np)); +pr_debug (" Got one, spec %d cells (0x%08x 0x%08x...) on %pOF\n" , + oirq.args_count, oirq.args[0 ], oirq.args[1 ], oirq.np); virq =irq_create_of_mapping (&oirq); }
@@ -741,8 +740,8 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,struct of_pci_range range;struct of_pci_range_parser parser; -printk (KERN_INFO "PCI host bridge %s %s ranges:\n" , - dev->full_name, primary ?"(primary)" :"" ); +printk (KERN_INFO "PCI host bridge %pOF %s ranges:\n" , + dev, primary ?"(primary)" :"" );/* Check for ranges property */ if (of_pci_range_parser_init (&parser, dev))
@@ -1556,8 +1555,8 @@ static void pcibios_setup_phb_resources(struct pci_controller *hose,if (!res->flags) {pr_debug ("PCI: I/O resource not set for host" -" bridge %s (domain %d)\n" , - hose->dn->full_name, hose->global_number); +" bridge %pOF (domain %d)\n" , + hose->dn, hose->global_number); }else { offset =pcibios_io_space_offset (hose);
@@ -1668,7 +1667,7 @@ void pcibios_scan_phb(struct pci_controller *hose)struct device_node *node = hose->dn;int mode; -pr_debug ("PCI: Scanning PHB %s\n" ,of_node_full_name (node)); +pr_debug ("PCI: Scanning PHB %pOF\n" , node);/* Get some IO space for the new PHB */ pcibios_setup_phb_io_space (hose);
arch/powerpc/kernel/pci_32.c +2 -2
@@ -79,8 +79,8 @@ make_one_node_map(struct device_node* node, u8 pci_bus)return ; bus_range =of_get_property (node,"bus-range" , &len);if (bus_range ==NULL || len <2 *sizeof (int )) { -printk (KERN_WARNING "Can't get bus-range for %s, " -"assuming it starts at 0\n" , node->full_name); +printk (KERN_WARNING "Can't get bus-range for %pOF, " +"assuming it starts at 0\n" , node); pci_to_OF_bus_map[pci_bus] =0 ; }else pci_to_OF_bus_map[pci_bus] = bus_range[0 ];
arch/powerpc/kernel/pci_64.c +2 -2
@@ -111,7 +111,7 @@ int pcibios_unmap_io_space(struct pci_bus *bus)if (hose->io_base_alloc ==NULL )return 0 ; -pr_debug ("IO unmapping for PHB %s\n" , hose->dn->full_name); +pr_debug ("IO unmapping for PHB %pOF\n" , hose->dn);pr_debug (" alloc=0x%p\n" , hose->io_base_alloc);/* This is a PHB, we fully unmap the IO area */
@@ -151,7 +151,7 @@ static int pcibios_map_phb_io_space(struct pci_controller *hose) hose->io_base_virt = (void __iomem *)(area->addr + hose->io_base_phys - phys_page); -pr_debug ("IO mapping for PHB %s\n" , hose->dn->full_name); +pr_debug ("IO mapping for PHB %pOF\n" , hose->dn);pr_debug (" phys=0x%016llx, virt=0x%p (alloc=0x%p)\n" , hose->io_base_phys, hose->io_base_virt, hose->io_base_alloc); pr_debug(" size=0x%016llx (alloc=0x%016lx)\n",
arch/powerpc/kernel/pci_of_scan.c +12 -12
@@ -211,19 +211,19 @@ void of_scan_pci_bridge(struct pci_dev *dev)unsigned int flags;u64 size; -pr_debug ("of_scan_pci_bridge(%s)\n" , node->full_name); +pr_debug ("of_scan_pci_bridge(%pOF)\n" , node);/* parse bus-range property */ busrange =of_get_property (node,"bus-range" , &len);if (busrange ==NULL || len !=8 ) { -printk (KERN_DEBUG "Can't get bus-range for PCI-PCI bridge %s\n" , - node->full_name); +printk (KERN_DEBUG "Can't get bus-range for PCI-PCI bridge %pOF\n" , + node);return ; } ranges =of_get_property (node,"ranges" , &len);if (ranges ==NULL ) { -printk (KERN_DEBUG "Can't get ranges for PCI-PCI bridge %s\n" , - node->full_name); +printk (KERN_DEBUG "Can't get ranges for PCI-PCI bridge %pOF\n" , + node);return ; }
@@ -233,8 +233,8 @@ void of_scan_pci_bridge(struct pci_dev *dev) bus =pci_add_new_bus (dev->bus, dev,of_read_number (busrange,1 ));if (!bus) { -printk (KERN_ERR "Failed to create pci bus for %s\n" , - node->full_name); +printk (KERN_ERR "Failed to create pci bus for %pOF\n" , + node);return ; } }
@@ -262,13 +262,13 @@ void of_scan_pci_bridge(struct pci_dev *dev) res = bus->resource[0 ];if (res->flags) {printk (KERN_ERR "PCI: ignoring extra I/O range" -" for bridge %s\n" , node->full_name); +" for bridge %pOF\n" , node);continue ; } }else {if (i >=PCI_NUM_RESOURCES -PCI_BRIDGE_RESOURCES ) {printk (KERN_ERR "PCI: too many memory ranges" -" for bridge %s\n" , node->full_name); +" for bridge %pOF\n" , node);continue ; } res = bus->resource[i];
@@ -307,7 +307,7 @@ static struct pci_dev *of_scan_pci_dev(struct pci_bus *bus,struct eeh_dev *edev =pdn_to_eeh_dev (PCI_DN (dn));#endif -pr_debug (" * %s\n" , dn->full_name); +pr_debug (" * %pOF\n" , dn);if (!of_device_is_available (dn))return NULL ;
@@ -350,8 +350,8 @@ static void __of_scan_bus(struct device_node *node, struct pci_bus *bus,struct device_node *child;struct pci_dev *dev; -pr_debug ("of_scan_bus(%s) bus no %d...\n" , - node->full_name, bus->number); +pr_debug ("of_scan_bus(%pOF) bus no %d...\n" , + node, bus->number);/* Scan direct children */ for_each_child_of_node (node, child) {
arch/powerpc/kernel/setup-common.c +1 -1
@@ -481,7 +481,7 @@ void __init smp_setup_cpu_maps(void)__be32 cpu_be;int j, len; -DBG (" * %s...\n" , dn->full_name); +DBG (" * %pOF...\n" , dn); intserv =of_get_property (dn,"ibm,ppc-interrupt-server#s" , &len);
arch/powerpc/platforms/4xx/cpm.c +4 -4
@@ -278,8 +278,8 @@ static int __init cpm_init(void) dcr_len =dcr_resource_len (np,0 );if (dcr_base ==0 || dcr_len ==0 ) { -printk (KERN_ERR "cpm: could not parse dcr property for %s\n" , - np->full_name); +printk (KERN_ERR "cpm: could not parse dcr property for %pOF\n" , + np); ret = -EINVAL ; goto node_put; }
@@ -287,8 +287,8 @@ static int __init cpm_init(void) cpm.dcr_host =dcr_map (np, dcr_base, dcr_len);if (!DCR_MAP_OK (cpm.dcr_host)) { -printk (KERN_ERR "cpm: failed to map dcr property for %s\n" , - np->full_name); +printk (KERN_ERR "cpm: failed to map dcr property for %pOF\n" , + np); ret = -EINVAL ; goto node_put; }
arch/powerpc/platforms/4xx/gpio.c +1 -2
@@ -198,8 +198,7 @@ static int __init ppc4xx_add_gpiochips(void) goto err;continue ; err: -pr_err ("%s: registration failed with status %d\n" , - np->full_name, ret); +pr_err ("%pOF: registration failed with status %d\n" , np, ret);kfree (ppc4xx_gc);/* try others anyway */ }
arch/powerpc/platforms/4xx/msi.c +1 -2
@@ -233,8 +233,7 @@ static int ppc4xx_msi_probe(struct platform_device *dev)/* Get MSI ranges */ err =of_address_to_resource (dev->dev.of_node,0 , &res);if (err) { -dev_err (&dev->dev,"%s resource error!\n" , - dev->dev.of_node->full_name); +dev_err (&dev->dev,"%pOF resource error!\n" , dev->dev.of_node); goto error_out; }
arch/powerpc/platforms/4xx/pci.c +52 -64
310 lines not on this page · raw message
arch/powerpc/platforms/4xx/soc.c +2 -3
@@ -90,7 +90,7 @@ static int __init ppc4xx_l2c_probe(void)/* Get l2 cache size */ prop =of_get_property (np,"cache-size" ,NULL );if (prop ==NULL ) { -printk (KERN_ERR "%s: Can't get cache-size!\n" , np->full_name); +printk (KERN_ERR "%pOF: Can't get cache-size!\n" , np);of_node_put (np);return -ENODEV ; }
@@ -99,8 +99,7 @@ static int __init ppc4xx_l2c_probe(void)/* Map DCRs */ dcrreg =of_get_property (np,"dcr-reg" , &len);if (!dcrreg || (len !=4 *sizeof (u32))) { -printk (KERN_ERR "%s: Can't get DCR register base !" , - np->full_name); +printk (KERN_ERR "%pOF: Can't get DCR register base !" , np);of_node_put (np);return -ENODEV ; }
arch/powerpc/platforms/4xx/uic.c +7 -7
@@ -243,16 +243,16 @@ static struct uic * __init uic_init_one(struct device_node *node)raw_spin_lock_init (&uic->lock); indexp =of_get_property (node,"cell-index" , &len);if (!indexp || (len !=sizeof (u32))) { -printk (KERN_ERR "uic: Device node %s has missing or invalid " -"cell-index property\n" , node->full_name); +printk (KERN_ERR "uic: Device node %pOF has missing or invalid " +"cell-index property\n" , node);return NULL ; } uic->index = *indexp; dcrreg =of_get_property (node,"dcr-reg" , &len);if (!dcrreg || (len !=2 *sizeof (u32))) { -printk (KERN_ERR "uic: Device node %s has missing or invalid " -"dcr-reg property\n" , node->full_name); +printk (KERN_ERR "uic: Device node %pOF has missing or invalid " +"dcr-reg property\n" , node);return NULL ; } uic->dcrbase = *dcrreg;
@@ -292,7 +292,7 @@ void __init uic_init_tree(void)* top-level interrupt controller */ primary_uic =uic_init_one (np);if (!primary_uic) -panic ("Unable to initialize primary UIC %s\n" , np->full_name); +panic ("Unable to initialize primary UIC %pOF\n" , np);irq_set_default_host (primary_uic->irqhost);of_node_put (np);
@@ -306,8 +306,8 @@ void __init uic_init_tree(void) uic =uic_init_one (np);if (! uic) -panic ("Unable to initialize a secondary UIC %s\n" , - np->full_name); +panic ("Unable to initialize a secondary UIC %pOF\n" , + np); cascade_virq =irq_of_parse_and_map (np,0 );
arch/powerpc/platforms/512x/mpc512x_shared.c +6 -6
@@ -387,8 +387,8 @@ static unsigned int __init get_fifo_size(struct device_node *np,if (fp)return *fp; -pr_warning ("no %s property in %s node, defaulting to %d\n" , - prop_name, np->full_name,DEFAULT_FIFO_SIZE ); +pr_warning ("no %s property in %pOF node, defaulting to %d\n" , + prop_name, np,DEFAULT_FIFO_SIZE );return DEFAULT_FIFO_SIZE ; }
@@ -426,15 +426,15 @@ static void __init mpc512x_psc_fifo_init(void) psc =of_iomap (np,0 );if (!psc) { -pr_err ("%s: Can't map %s device\n" , - __func__, np->full_name); +pr_err ("%s: Can't map %pOF device\n" , + __func__, np);continue ; }/* FIFO space is 4KiB, check if requested size is available */ if ((fifobase + tx_fifo_size + rx_fifo_size) >0x1000 ) { -pr_err ("%s: no fifo space available for %s\n" , - __func__, np->full_name); +pr_err ("%s: no fifo space available for %pOF\n" , + __func__, np);iounmap (psc);/* * chances are that another device requests less
arch/powerpc/platforms/52xx/efika.c +4 -4
@@ -99,7 +99,7 @@ static void __init efika_pcisetup(void) bus_range =of_get_property (pcictrl,"bus-range" , &len);if (bus_range ==NULL || len <2 *sizeof (int )) { printk(KERN_WARNING EFIKA_PLATFORM_NAME - ": Can't get bus-range for %s\n", pcictrl->full_name); + ": Can't get bus-range for %pOF\n", pcictrl); goto out_put; }
@@ -109,14 +109,14 @@ static void __init efika_pcisetup(void)else printk(KERN_INFO EFIKA_PLATFORM_NAME ": PCI buses %d..%d", bus_range[0 ], bus_range[1 ]); -printk (" controlled by %s\n" , pcictrl->full_name); +printk (" controlled by %pOF\n" , pcictrl);printk ("\n" ); hose =pcibios_alloc_controller (pcictrl);if (!hose) { printk(KERN_WARNING EFIKA_PLATFORM_NAME -": Can't allocate PCI controller structure for %s\n" , - pcictrl->full_name); +": Can't allocate PCI controller structure for %pOF\n" , + pcictrl); goto out_put; }
arch/powerpc/platforms/52xx/media5200.c +1 -1
@@ -156,7 +156,7 @@ static void __init media5200_init_irq(void) fpga_np =of_find_compatible_node (NULL ,NULL ,"fsl,media5200-fpga" );if (!fpga_np) goto out; -pr_debug ("%s: found fpga node: %s\n" , __func__, fpga_np->full_name); +pr_debug ("%s: found fpga node: %pOF\n" , __func__, fpga_np); media5200_irq.regs =of_iomap (fpga_np,0 );if (!media5200_irq.regs)
arch/powerpc/platforms/52xx/mpc52xx_gpt.c +2 -2
@@ -226,7 +226,7 @@ static int mpc52xx_gpt_irq_xlate(struct irq_domain *h, struct device_node *ct,dev_dbg (gpt->dev,"%s: flags=%i\n" , __func__, intspec[0 ]);if ((intsize <1 ) || (intspec[0 ] >3 )) { -dev_err (gpt->dev,"bad irq specifier in %s\n" , ct->full_name); +dev_err (gpt->dev,"bad irq specifier in %pOF\n" , ct);return -EINVAL ; }
@@ -331,7 +331,7 @@ mpc52xx_gpt_gpio_setup(struct mpc52xx_gpt_priv *gpt, struct device_node *node)if (!of_find_property (node,"gpio-controller" ,NULL ))return ; - gpt->gc.label =kstrdup (node->full_name,GFP_KERNEL ); + gpt->gc.label =kasprintf (GFP_KERNEL ,"%pOF" , node);if (!gpt->gc.label) {dev_err (gpt->dev,"out of memory\n" );return ;
arch/powerpc/platforms/52xx/mpc52xx_pci.c +4 -4
@@ -369,19 +369,19 @@ mpc52xx_add_bridge(struct device_node *node)const int *bus_range;struct resource rsrc; -pr_debug ("Adding MPC52xx PCI host bridge %s\n" , node->full_name); +pr_debug ("Adding MPC52xx PCI host bridge %pOF\n" , node);pci_add_flags (PCI_REASSIGN_ALL_BUS );if (of_address_to_resource (node,0 , &rsrc) !=0 ) { -printk (KERN_ERR "Can't get %s resources\n" , node->full_name); +printk (KERN_ERR "Can't get %pOF resources\n" , node);return -EINVAL ; } bus_range =of_get_property (node,"bus-range" , &len);if (bus_range ==NULL || len <2 *sizeof (int )) { -printk (KERN_WARNING "Can't get %s bus-range, assume bus 0\n" , - node->full_name); +printk (KERN_WARNING "Can't get %pOF bus-range, assume bus 0\n" , + node); bus_range =NULL ; }
arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c +2 -1
@@ -128,7 +128,7 @@ static int mcu_gpiochip_add(struct mcu *mcu)return -ENODEV ; gc->owner =THIS_MODULE ; - gc->label = np->full_name; + gc->label =kasprintf (GFP_KERNEL ,"%pOF" , np); gc->can_sleep =1 ; gc->ngpio =MCU_NUM_GPIO ; gc->base =-1 ;
@@ -141,6 +141,7 @@ static int mcu_gpiochip_add(struct mcu *mcu)static int mcu_gpiochip_remove (struct mcu *mcu) { +kfree (mcu->gc.label);gpiochip_remove (&mcu->gc);return 0 ; }
arch/powerpc/platforms/83xx/mpc832x_rdb.c +1 -1
@@ -113,7 +113,7 @@ static int __init of_fsl_spi_probe(char *type, char *compatible, u32 sysclk, unreg:platform_device_del (pdev); err: -pr_err ("%s: registration failed\n" , np->full_name); +pr_err ("%pOF: registration failed\n" , np); next: i++; }
arch/powerpc/platforms/85xx/p1022_ds.c +4 -4
@@ -508,8 +508,8 @@ static void __init p1022_ds_setup_arch(void)* allocate one static local variable for each * call to this function. */ -pr_info ("p1022ds: disabling %s node" , - np2->full_name); +pr_info ("p1022ds: disabling %pOF node" , + np2);of_update_property (np2, &nor_status);of_node_put (np2); }
@@ -524,8 +524,8 @@ static void __init p1022_ds_setup_arch(void) .length = sizeof("disabled"), }; -pr_info ("p1022ds: disabling %s node" , - np2->full_name); +pr_info ("p1022ds: disabling %pOF node" , + np2);of_update_property (np2, &nand_status);of_node_put (np2); }
arch/powerpc/platforms/85xx/xes_mpc85xx.c +2 -2
@@ -100,8 +100,8 @@ static void xes_mpc85xx_fixups(void) err =of_address_to_resource (np,0 , &r[0 ]);if (err) {printk (KERN_WARNING "xes_mpc85xx: Could not get " -"resource for device tree node '%s'" , - np->full_name); +"resource for device tree node '%pOF'" , + np);continue ; }
arch/powerpc/platforms/amigaone/setup.c +3 -3
@@ -40,7 +40,7 @@ static int __init amigaone_add_bridge(struct device_node *dev)const int *bus_range;struct pci_controller *hose; -printk (KERN_INFO "Adding PCI host bridge %s\n" , dev->full_name); +printk (KERN_INFO "Adding PCI host bridge %pOF\n" , dev); cfg_addr =of_get_address (dev,0 ,NULL ,NULL ); cfg_data =of_get_address (dev,1 ,NULL ,NULL );
@@ -49,8 +49,8 @@ static int __init amigaone_add_bridge(struct device_node *dev) bus_range =of_get_property (dev,"bus-range" , &len);if ((bus_range ==NULL ) || (len <2 *sizeof (int ))) -printk (KERN_WARNING "Can't get bus-range for %s, assume" -" bus 0\n" , dev->full_name); +printk (KERN_WARNING "Can't get bus-range for %pOF, assume" +" bus 0\n" , dev); hose =pcibios_alloc_controller (dev);if (hose ==NULL )
arch/powerpc/platforms/cell/axon_msi.c +18 -18
@@ -187,8 +187,8 @@ static struct axon_msic *find_msi_translator(struct pci_dev *dev) irq_domain =irq_find_host (dn);if (!irq_domain) { -dev_dbg (&dev->dev,"axon_msi: no irq_domain found for node %s\n" , - dn->full_name); +dev_dbg (&dev->dev,"axon_msi: no irq_domain found for node %pOF\n" , + dn); goto out_error; }
@@ -326,8 +326,8 @@ static void axon_msi_shutdown(struct platform_device *device)struct axon_msic *msic =dev_get_drvdata (&device->dev);u32 tmp; -pr_devel ("axon_msi: disabling %s\n" , -irq_domain_get_of_node (msic->irq_domain)->full_name); +pr_devel ("axon_msi: disabling %pOF\n" , +irq_domain_get_of_node (msic->irq_domain)); tmp =dcr_read (msic->dcr_host,MSIC_CTRL_REG ); tmp &= ~MSIC_CTRL_ENABLE & ~MSIC_CTRL_IRQ_ENABLE ;msic_dcr_write (msic,MSIC_CTRL_REG , tmp);
@@ -340,12 +340,12 @@ static int axon_msi_probe(struct platform_device *device)unsigned int virq;int dcr_base, dcr_len; -pr_devel ("axon_msi: setting up dn %s\n" , dn->full_name); +pr_devel ("axon_msi: setting up dn %pOF\n" , dn); msic =kzalloc (sizeof (struct axon_msic ),GFP_KERNEL );if (!msic) { -printk (KERN_ERR "axon_msi: couldn't allocate msic for %s\n" , - dn->full_name); +printk (KERN_ERR "axon_msi: couldn't allocate msic for %pOF\n" , + dn); goto out; }
@@ -354,30 +354,30 @@ static int axon_msi_probe(struct platform_device *device)if (dcr_base ==0 || dcr_len ==0 ) {printk (KERN_ERR -"axon_msi: couldn't parse dcr properties on %s\n" , - dn->full_name); +"axon_msi: couldn't parse dcr properties on %pOF\n" , + dn); goto out_free_msic; } msic->dcr_host =dcr_map (dn, dcr_base, dcr_len);if (!DCR_MAP_OK (msic->dcr_host)) { -printk (KERN_ERR "axon_msi: dcr_map failed for %s\n" , - dn->full_name); +printk (KERN_ERR "axon_msi: dcr_map failed for %pOF\n" , + dn); goto out_free_msic; } msic->fifo_virt =dma_alloc_coherent (&device->dev,MSIC_FIFO_SIZE_BYTES , &msic->fifo_phys,GFP_KERNEL );if (!msic->fifo_virt) { -printk (KERN_ERR "axon_msi: couldn't allocate fifo for %s\n" , - dn->full_name); +printk (KERN_ERR "axon_msi: couldn't allocate fifo for %pOF\n" , + dn); goto out_free_msic; } virq =irq_of_parse_and_map (dn,0 );if (!virq) { -printk (KERN_ERR "axon_msi: irq parse and map failed for %s\n" , - dn->full_name); +printk (KERN_ERR "axon_msi: irq parse and map failed for %pOF\n" , + dn); goto out_free_fifo; }memset (msic->fifo_virt,0xff ,MSIC_FIFO_SIZE_BYTES );
@@ -385,8 +385,8 @@ static int axon_msi_probe(struct platform_device *device)/* We rely on being able to stash a virq in a u16, so limit irqs to < 65536 */ msic->irq_domain =irq_domain_add_nomap (dn,65536 , &msic_host_ops, msic);if (!msic->irq_domain) { -printk (KERN_ERR "axon_msi: couldn't allocate irq_domain for %s\n" , - dn->full_name); +printk (KERN_ERR "axon_msi: couldn't allocate irq_domain for %pOF\n" , + dn); goto out_free_fifo; }
@@ -412,7 +412,7 @@ static int axon_msi_probe(struct platform_device *device)axon_msi_debug_setup (dn, msic); -printk (KERN_DEBUG "axon_msi: setup MSIC on %s\n" , dn->full_name); +printk (KERN_DEBUG "axon_msi: setup MSIC on %pOF\n" , dn);return 0 ;
arch/powerpc/platforms/cell/interrupt.c +2 -2
@@ -303,8 +303,8 @@ static void __init init_one_iic(unsigned int hw_cpu, unsigned long addr, iic->node =of_node_get (node);out_be64 (&iic->regs->prio,0 ); -printk (KERN_INFO "IIC for CPU %d target id 0x%x : %s\n" , - hw_cpu, iic->target_id, node->full_name); +printk (KERN_INFO "IIC for CPU %d target id 0x%x : %pOF\n" , + hw_cpu, iic->target_id, node); }static int __init setup_iic (void )
arch/powerpc/platforms/cell/iommu.c +12 -12
@@ -278,8 +278,8 @@ static int cell_iommu_find_ioc(int nid, unsigned long *base)if (of_node_to_nid (np) != nid)continue ;if (of_address_to_resource (np,0 , &r)) { -printk (KERN_ERR "iommu: can't get address for %s\n" , - np->full_name); +printk (KERN_ERR "iommu: can't get address for %pOF\n" , + np);continue ; } *base = r.start;
@@ -458,8 +458,8 @@ static inline u32 cell_iommu_get_ioid(struct device_node *np) ioid =of_get_property (np,"ioid" ,NULL );if (ioid ==NULL ) { -printk (KERN_WARNING "iommu: missing ioid for %s using 0\n" , - np->full_name); +printk (KERN_WARNING "iommu: missing ioid for %pOF using 0\n" , + np);return 0 ; }
@@ -559,8 +559,8 @@ static struct iommu_table *cell_get_iommu_table(struct device *dev)*/ iommu =cell_iommu_for_node (dev_to_node (dev));if (iommu ==NULL ||list_empty (&iommu->windows)) { -dev_err (dev,"iommu: missing iommu for %s (node %d)\n" , -of_node_full_name (dev->of_node),dev_to_node (dev)); +dev_err (dev,"iommu: missing iommu for %pOF (node %d)\n" , + dev->of_node,dev_to_node (dev));return NULL ; } window = list_entry(iommu->windows.next, struct iommu_window, list);
@@ -720,12 +720,12 @@ static struct cbe_iommu * __init cell_iommu_alloc(struct device_node *np)/* Get node ID */ nid =of_node_to_nid (np);if (nid <0 ) { -printk (KERN_ERR "iommu: failed to get node for %s\n" , - np->full_name); +printk (KERN_ERR "iommu: failed to get node for %pOF\n" , + np);return NULL ; } -pr_debug ("iommu: setting up iommu for node %d (%s)\n" , - nid, np->full_name); +pr_debug ("iommu: setting up iommu for node %d (%pOF)\n" , + nid, np);/* XXX todo: If we can have multiple windows on the same IOMMU, which * isn't the case today, we probably want here to check whether the
@@ -736,8 +736,8 @@ static struct cbe_iommu * __init cell_iommu_alloc(struct device_node *np)*/ if (cbe_nr_iommus >=NR_IOMMUS ) { -printk (KERN_ERR "iommu: too many IOMMUs detected ! (%s)\n" , - np->full_name); +printk (KERN_ERR "iommu: too many IOMMUs detected ! (%pOF)\n" , + np);return NULL ; }
arch/powerpc/platforms/cell/ras.c +2 -2
@@ -196,8 +196,8 @@ static int __init cbe_ptcal_enable(void)for_each_node_by_type (np,"cpu" ) {const u32 *nid =of_get_property (np,"node-id" ,NULL );if (!nid) { -printk (KERN_ERR "%s: node %s is missing node-id?\n" , - __func__, np->full_name); +printk (KERN_ERR "%s: node %pOF is missing node-id?\n" , + __func__, np);continue ; }cbe_ptcal_enable_on_node (*nid, order);
arch/powerpc/platforms/cell/spider-pci.c +2 -2
@@ -130,8 +130,8 @@ int __init spiderpci_iowa_init(struct iowa_bus *bus, void *data)struct resource r;unsigned long offset = (unsigned long )data; -pr_debug ("SPIDERPCI-IOWA:Bus initialize for spider(%s)\n" , - np->full_name); +pr_debug ("SPIDERPCI-IOWA:Bus initialize for spider(%pOF)\n" , + np); priv =kzalloc (sizeof (struct spiderpci_iowa_private ),GFP_KERNEL );if (!priv) {
arch/powerpc/platforms/cell/spider-pic.c +2 -2
@@ -323,8 +323,8 @@ static void __init spider_init_one(struct device_node *of_node, int chip,irq_set_handler_data (virq, pic);irq_set_chained_handler (virq, spider_irq_cascade); -printk (KERN_INFO "spider_pic: node %d, addr: 0x%lx %s\n" , - pic->node_id, addr, of_node->full_name); +printk (KERN_INFO "spider_pic: node %d, addr: 0x%lx %pOF\n" , + pic->node_id, addr, of_node);/* Enable the interrupt detection enable bit. Do this last! */ out_be32 (pic->regs +TIR_DEN ,in_be32 (pic->regs +TIR_DEN ) |0x1 );
arch/powerpc/platforms/cell/spu_manage.c +13 -13
@@ -191,8 +191,8 @@ static int __init spu_map_interrupts(struct spu *spu, struct device_node *np) goto err; } ret = -EINVAL ; -pr_debug (" irq %d no 0x%x on %s\n" , i, oirq.args[0 ], - oirq.np->full_name); +pr_debug (" irq %d no 0x%x on %pOF\n" , i, oirq.args[0 ], + oirq.np); spu->irqs[i] =irq_create_of_mapping (&oirq);if (!spu->irqs[i]) {pr_debug ("spu_new: failed to map it !\n" );
@@ -243,32 +243,32 @@ static int __init spu_map_device(struct spu *spu) ret =spu_map_resource (spu,0 , (void __iomem **)&spu->local_store, &spu->local_store_phys);if (ret) { -pr_debug ("spu_new: failed to map %s resource 0\n" , - np->full_name); +pr_debug ("spu_new: failed to map %pOF resource 0\n" , + np); goto out; } ret =spu_map_resource (spu,1 , (void __iomem **)&spu->problem, &spu->problem_phys);if (ret) { -pr_debug ("spu_new: failed to map %s resource 1\n" , - np->full_name); +pr_debug ("spu_new: failed to map %pOF resource 1\n" , + np); goto out_unmap; } ret =spu_map_resource (spu,2 , (void __iomem **)&spu->priv2,NULL );if (ret) { -pr_debug ("spu_new: failed to map %s resource 2\n" , - np->full_name); +pr_debug ("spu_new: failed to map %pOF resource 2\n" , + np); goto out_unmap; }if (!firmware_has_feature (FW_FEATURE_LPAR )) ret =spu_map_resource (spu,3 , (void __iomem **)&spu->priv1,NULL );if (ret) { -pr_debug ("spu_new: failed to map %s resource 3\n" , - np->full_name); +pr_debug ("spu_new: failed to map %pOF resource 3\n" , + np); goto out_unmap; } -pr_debug ("spu_new: %s maps:\n" , np->full_name); +pr_debug ("spu_new: %pOF maps:\n" , np);pr_debug (" local store : 0x%016lx -> 0x%p\n" , spu->local_store_phys, spu->local_store); pr_debug(" problem state : 0x%016lx -> 0x%p\n",
@@ -316,8 +316,8 @@ static int __init of_create_spu(struct spu *spu, void *data) spu->node =of_node_to_nid (spe);if (spu->node >=MAX_NUMNODES ) { -printk (KERN_WARNING "SPE %s on node %d ignored," -" node number too big\n" , spe->full_name, spu->node); +printk (KERN_WARNING "SPE %pOF on node %d ignored," +" node number too big\n" , spe, spu->node);printk (KERN_WARNING "Check if CONFIG_NUMA is enabled.\n" ); ret = -ENODEV ; goto out;
arch/powerpc/platforms/chrp/pci.c +9 -9
@@ -235,14 +235,14 @@ chrp_find_bridges(void) ++index;/* The GG2 bridge on the LongTrail doesn't have an address */ if (of_address_to_resource (dev,0 , &r) && !is_longtrail) { -printk (KERN_WARNING "Can't use %s: no address\n" , - dev->full_name); +printk (KERN_WARNING "Can't use %pOF: no address\n" , + dev);continue ; } bus_range =of_get_property (dev,"bus-range" , &len);if (bus_range ==NULL || len <2 *sizeof (int )) { -printk (KERN_WARNING "Can't get bus-range for %s\n" , - dev->full_name); +printk (KERN_WARNING "Can't get bus-range for %pOF\n" , + dev);continue ; }if (bus_range[1 ] == bus_range[0 ])
@@ -250,15 +250,15 @@ chrp_find_bridges(void)else printk (KERN_INFO "PCI buses %d..%d" , bus_range[0 ], bus_range[1 ]); -printk (" controlled by %s" , dev->full_name); +printk (" controlled by %pOF" , dev);if (!is_longtrail)printk (" at %llx" , (unsigned long long )r.start);printk ("\n" ); hose =pcibios_alloc_controller (dev);if (!hose) { -printk ("Can't allocate PCI controller structure for %s\n" , - dev->full_name); +printk ("Can't allocate PCI controller structure for %pOF\n" , + dev);continue ; } hose->first_busno = hose->self_busno = bus_range[0 ];
@@ -297,8 +297,8 @@ chrp_find_bridges(void) } } }else { -printk ("No methods for %s (model %s), using RTAS\n" , - dev->full_name, model); +printk ("No methods for %pOF (model %s), using RTAS\n" , + dev, model); hose->ops = &rtas_pci_ops; }
arch/powerpc/platforms/embedded6xx/linkstation.c +3 -3
@@ -41,12 +41,12 @@ static int __init linkstation_add_bridge(struct device_node *dev)struct pci_controller *hose;const int *bus_range; -printk ("Adding PCI host bridge %s\n" , dev->full_name); +printk ("Adding PCI host bridge %pOF\n" , dev); bus_range =of_get_property (dev,"bus-range" , &len);if (bus_range ==NULL || len <2 *sizeof (int )) -printk (KERN_WARNING "Can't get bus-range for %s, assume" -" bus 0\n" , dev->full_name); +printk (KERN_WARNING "Can't get bus-range for %pOF, assume" +" bus 0\n" , dev); hose =pcibios_alloc_controller (dev);if (hose ==NULL )
arch/powerpc/platforms/embedded6xx/mvme5100.c +1 -1
@@ -115,7 +115,7 @@ static int __init mvme5100_add_bridge(struct device_node *dev)struct pci_controller *hose;unsigned short devid; -pr_info ("Adding PCI host bridge %s\n" , dev->full_name); +pr_info ("Adding PCI host bridge %pOF\n" , dev); bus_range =of_get_property (dev,"bus-range" , &len);
arch/powerpc/platforms/embedded6xx/storcenter.c +1 -1
@@ -44,7 +44,7 @@ static int __init storcenter_add_bridge(struct device_node *dev)struct pci_controller *hose;const int *bus_range; -printk ("Adding PCI host bridge %s\n" , dev->full_name); +printk ("Adding PCI host bridge %pOF\n" , dev); hose =pcibios_alloc_controller (dev);if (hose ==NULL )
arch/powerpc/platforms/maple/pci.c +5 -5
@@ -73,8 +73,8 @@ static void __init fixup_bus_range(struct device_node *bridge)/* Lookup the "bus-range" property for the hose */ prop =of_find_property (bridge,"bus-range" , &len);if (prop ==NULL || prop->value ==NULL || len <2 *sizeof (int )) { -printk (KERN_WARNING "Can't get bus-range for %s\n" , - bridge->full_name); +printk (KERN_WARNING "Can't get bus-range for %pOF\n" , + bridge);return ; } bus_range = prop->value;
@@ -498,12 +498,12 @@ static int __init maple_add_bridge(struct device_node *dev)const int *bus_range;int primary =1 ; -DBG ("Adding PCI host bridge %s\n" , dev->full_name); +DBG ("Adding PCI host bridge %pOF\n" , dev); bus_range =of_get_property (dev,"bus-range" , &len);if (bus_range ==NULL || len <2 *sizeof (int )) { -printk (KERN_WARNING "Can't get bus-range for %s, assume bus 0\n" , - dev->full_name); +printk (KERN_WARNING "Can't get bus-range for %pOF, assume bus 0\n" , + dev); } hose =pcibios_alloc_controller (dev);
arch/powerpc/platforms/pasemi/pci.c +1 -1
@@ -193,7 +193,7 @@ static int __init pas_add_bridge(struct device_node *dev) {struct pci_controller *hose; -pr_debug ("Adding PCI host bridge %s\n" , dev->full_name); +pr_debug ("Adding PCI host bridge %pOF\n" , dev); hose =pcibios_alloc_controller (dev);if (!hose)
arch/powerpc/platforms/powermac/feature.c +7 -7
@@ -2658,25 +2658,25 @@ static void __init probe_one_macio(const char *name, const char *compat, int typif (i >=MAX_MACIO_CHIPS ) {printk (KERN_ERR "pmac_feature: Please increase MAX_MACIO_CHIPS !\n" ); -printk (KERN_ERR "pmac_feature: %s skipped\n" , node->full_name); +printk (KERN_ERR "pmac_feature: %pOF skipped\n" , node);return ; } addrp =of_get_pci_address (node,0 , &size,NULL );if (addrp ==NULL ) { -printk (KERN_ERR "pmac_feature: %s: can't find base !\n" , - node->full_name); +printk (KERN_ERR "pmac_feature: %pOF: can't find base !\n" , + node);return ; } addr =of_translate_address (node, addrp);if (addr ==0 ) { -printk (KERN_ERR "pmac_feature: %s, can't translate base !\n" , - node->full_name); +printk (KERN_ERR "pmac_feature: %pOF, can't translate base !\n" , + node);return ; } base =ioremap (addr, (unsigned long )size);if (!base) { -printk (KERN_ERR "pmac_feature: %s, can't map mac-io chip !\n" , - node->full_name); +printk (KERN_ERR "pmac_feature: %pOF, can't map mac-io chip !\n" , + node);return ; }if (type == macio_keylargo || type == macio_keylargo2) {
arch/powerpc/platforms/powermac/low_i2c.c +25 -25
139 lines not on this page · raw message
arch/powerpc/platforms/powermac/pci.c +3 -3
@@ -783,7 +783,7 @@ static int __init pmac_add_bridge(struct device_node *dev)const int *bus_range;int primary =1 , has_address =0 ; -DBG ("Adding PCI host bridge %s\n" , dev->full_name); +DBG ("Adding PCI host bridge %pOF\n" , dev);/* Fetch host bridge registers address */ has_address = (of_address_to_resource (dev,0 , &rsrc) ==0 );
@@ -791,8 +791,8 @@ static int __init pmac_add_bridge(struct device_node *dev)/* Get bus range if any */ bus_range =of_get_property (dev,"bus-range" , &len);if (bus_range ==NULL || len <2 *sizeof (int )) { -printk (KERN_WARNING "Can't get bus-range for %s, assume" -" bus 0\n" , dev->full_name); +printk (KERN_WARNING "Can't get bus-range for %pOF, assume" +" bus 0\n" , dev); } hose =pcibios_alloc_controller (dev);
arch/powerpc/platforms/powermac/pfunc_base.c +12 -12
@@ -54,8 +54,8 @@ static int macio_do_gpio_write(PMF_STD_ARGS, u8 value, u8 mask)raw_spin_lock_irqsave (&feature_lock, flags); tmp =readb (addr); tmp = (tmp & ~mask) | (value & mask); -DBG ("Do write 0x%02x to GPIO %s (%p)\n" , - tmp, func->node->full_name, addr); +DBG ("Do write 0x%02x to GPIO %pOF (%p)\n" , + tmp, func->node, addr);writeb (tmp, addr);raw_spin_unlock_irqrestore (&feature_lock, flags);
@@ -107,8 +107,8 @@ static void macio_gpio_init_one(struct macio_chip *macio)if (gparent ==NULL )return ; -DBG ("Installing GPIO functions for macio %s\n" , - macio->of_node->full_name); +DBG ("Installing GPIO functions for macio %pOF\n" , + macio->of_node);/* * Ok, got one, we dont need anything special to track them down, so
@@ -129,8 +129,8 @@ static void macio_gpio_init_one(struct macio_chip *macio)pmf_register_driver (gp, &macio_gpio_handlers, (void *)offset); } -DBG ("Calling initial GPIO functions for macio %s\n" , - macio->of_node->full_name); +DBG ("Calling initial GPIO functions for macio %pOF\n" , + macio->of_node);/* And now we run all the init ones */ for (gp =NULL ; (gp =of_get_next_child (gparent, gp)) !=NULL ;)
@@ -267,8 +267,8 @@ static struct pmf_handlers macio_mmio_handlers = {static void macio_mmio_init_one (struct macio_chip *macio) { -DBG ("Installing MMIO functions for macio %s\n" , - macio->of_node->full_name); +DBG ("Installing MMIO functions for macio %pOF\n" , + macio->of_node);pmf_register_driver (macio->of_node, &macio_mmio_handlers, macio); }
@@ -298,8 +298,8 @@ static void uninorth_install_pfunc(void) {struct device_node *np; -DBG ("Installing functions for UniN %s\n" , - uninorth_node->full_name); +DBG ("Installing functions for UniN %pOF\n" , + uninorth_node);/* * Install handlers for the bridge itself
@@ -317,8 +317,8 @@ static void uninorth_install_pfunc(void)break ; }if (unin_hwclock) { -DBG ("Installing functions for UniN clock %s\n" , - unin_hwclock->full_name); +DBG ("Installing functions for UniN clock %pOF\n" , + unin_hwclock);pmf_register_driver (unin_hwclock, &unin_mmio_handlers,NULL );pmf_do_functions (unin_hwclock,NULL ,0 ,PMF_FLAGS_ON_INIT ,NULL );
arch/powerpc/platforms/powermac/pfunc_core.c +3 -3
@@ -708,7 +708,7 @@ int pmf_register_driver(struct device_node *np,if (handlers ==NULL )return -EINVAL ; -DBG ("pmf: registering driver for node %s\n" , np->full_name); +DBG ("pmf: registering driver for node %pOF\n" , np);spin_lock_irqsave (&pmf_lock, flags); dev =pmf_find_device (np);
@@ -781,7 +781,7 @@ void pmf_unregister_driver(struct device_node *np)struct pmf_device *dev;unsigned long flags; -DBG ("pmf: unregistering driver for node %s\n" , np->full_name); +DBG ("pmf: unregistering driver for node %pOF\n" , np);spin_lock_irqsave (&pmf_lock, flags); dev =pmf_find_device (np);
@@ -940,7 +940,7 @@ int pmf_call_one(struct pmf_function *func, struct pmf_args *args)void *instdata =NULL ;int rc =0 ; -DBG (" ** pmf_call_one(%s/%s) **\n" , dev->node->full_name, func->name); +DBG (" ** pmf_call_one(%pOF/%s) **\n" , dev->node, func->name);if (dev->handlers->begin) instdata = dev->handlers->begin (func, args);
arch/powerpc/platforms/powermac/pic.c +4 -4
@@ -364,8 +364,8 @@ static void __init pmac_pic_probe_oldstyle(void) (addr +0x10 );of_node_put (master); -printk (KERN_INFO "irq: Found primary Apple PIC %s for %d irqs\n" , - master->full_name, max_real_irqs); +printk (KERN_INFO "irq: Found primary Apple PIC %pOF for %d irqs\n" , + master, max_real_irqs);/* Map interrupts of cascaded controller */ if (slave && !of_address_to_resource (slave,0 , &r)) {
@@ -378,8 +378,8 @@ static void __init pmac_pic_probe_oldstyle(void) (addr +0x10 ); pmac_irq_cascade =irq_of_parse_and_map (slave,0 ); -printk (KERN_INFO "irq: Found slave Apple PIC %s for %d irqs" -" cascade: %d\n" , slave->full_name, +printk (KERN_INFO "irq: Found slave Apple PIC %pOF for %d irqs" +" cascade: %d\n" , slave, max_irqs - max_real_irqs, pmac_irq_cascade); }of_node_put (slave);
arch/powerpc/platforms/powermac/setup.c +1 -1
@@ -556,7 +556,7 @@ static int __init check_pmac_serial_console(void)pr_debug (" can't find stdout package %s !\n" , name);return -ENODEV ; } -pr_debug ("stdout is %s\n" , prom_stdout->full_name); +pr_debug ("stdout is %pOF\n" , prom_stdout); name =of_get_property (prom_stdout,"name" ,NULL );if (!name) {
arch/powerpc/platforms/powernv/opal-async.c +2 -2
@@ -171,8 +171,8 @@ int __init opal_async_comp_init(void) async =of_get_property (opal_node,"opal-msg-async-num" ,NULL );if (!async) { -pr_err ("%s: %s has no opal-msg-async-num\n" , - __func__, opal_node->full_name); +pr_err ("%s: %pOF has no opal-msg-async-num\n" , + __func__, opal_node); err = -ENOENT ; goto out_opal_node; }
arch/powerpc/platforms/powernv/opal-xscom.c +4 -4
@@ -36,14 +36,14 @@ static scom_map_t opal_scom_map(struct device_node *dev, u64 reg, u64 count)const __be32 *gcid;if (!of_get_property (dev,"scom-controller" ,NULL )) { -pr_err ("%s: device %s is not a SCOM controller\n" , - __func__, dev->full_name); +pr_err ("%s: device %pOF is not a SCOM controller\n" , + __func__, dev);return SCOM_MAP_INVALID ; } gcid =of_get_property (dev,"ibm,chip-id" ,NULL );if (!gcid) { -pr_err ("%s: device %s has no ibm,chip-id\n" , - __func__, dev->full_name); +pr_err ("%s: device %pOF has no ibm,chip-id\n" , + __func__, dev);return SCOM_MAP_INVALID ; } m =kmalloc (sizeof (struct opal_scom_map ),GFP_KERNEL );
arch/powerpc/platforms/powernv/pci-ioda.c +7 -8
@@ -444,8 +444,8 @@ static void __init pnv_ioda_parse_m64_window(struct pnv_phb *phb) r =of_get_property (dn,"ibm,opal-m64-window" ,NULL );if (!r) { -pr_info (" No <ibm,opal-m64-window> on %s\n" , - dn->full_name); +pr_info (" No <ibm,opal-m64-window> on %pOF\n" , + dn);return ; }
@@ -3796,8 +3796,7 @@ static void __init pnv_pci_init_ioda_phb(struct device_node *np,if (!of_device_is_available (np))return ; -pr_info ("Initializing %s PHB (%s)\n" , - pnv_phb_names[ioda_type],of_node_full_name (np)); +pr_info ("Initializing %s PHB (%pOF)\n" , pnv_phb_names[ioda_type], np); prop64 =of_get_property (np,"ibm,opal-phbid" ,NULL );if (!prop64) {
@@ -3812,8 +3811,8 @@ static void __init pnv_pci_init_ioda_phb(struct device_node *np,/* Allocate PCI controller */ phb->hose = hose =pcibios_alloc_controller (np);if (!phb->hose) { -pr_err (" Can't allocate PCI controller for %s\n" , - np->full_name); +pr_err (" Can't allocate PCI controller for %pOF\n" , + np);memblock_free (__pa (phb),sizeof (struct pnv_phb ));return ; }
@@ -3824,7 +3823,7 @@ static void __init pnv_pci_init_ioda_phb(struct device_node *np, hose->first_busno =be32_to_cpu (prop32[0 ]); hose->last_busno =be32_to_cpu (prop32[1 ]); }else { -pr_warn (" Broken <bus-range> on %s\n" , np->full_name); +pr_warn (" Broken <bus-range> on %pOF\n" , np); hose->first_busno =0 ; hose->last_busno =0xff ; }
@@ -4045,7 +4044,7 @@ void __init pnv_pci_init_ioda_hub(struct device_node *np)const __be64 *prop64;u64 hub_id; -pr_info ("Probing IODA IO-Hub %s\n" , np->full_name); +pr_info ("Probing IODA IO-Hub %pOF\n" , np); prop64 =of_get_property (np,"ibm,opal-hubid" ,NULL );if (!prop64) {
arch/powerpc/platforms/powernv/rng.c +3 -3
@@ -125,7 +125,7 @@ static __init void rng_init_per_cpu(struct powernv_rng *rng, chip_id =of_get_ibm_chip_id (dn);if (chip_id ==-1 ) -pr_warn ("No ibm,chip-id found for %s.\n" , dn->full_name); +pr_warn ("No ibm,chip-id found for %pOF.\n" , dn);for_each_possible_cpu (cpu) { if (per_cpu(powernv_rng, cpu) == NULL ||
@@ -178,8 +178,8 @@ static __init int rng_init(void)for_each_compatible_node (dn,NULL ,"ibm,power-rng" ) { rc =rng_create (dn);if (rc) { -pr_err ("Failed creating rng for %s (%d).\n" , - dn->full_name, rc); +pr_err ("Failed creating rng for %pOF (%d).\n" , + dn, rc);continue ; }
arch/powerpc/platforms/pseries/dlpar.c +1 -2
@@ -264,8 +264,7 @@ int dlpar_attach_node(struct device_node *dn) rc =of_attach_node (dn);if (rc) { -printk (KERN_ERR "Failed to add device node %s\n" , - dn->full_name); +printk (KERN_ERR "Failed to add device node %pOF\n" , dn);return rc; }
arch/powerpc/platforms/pseries/event_sources.c +3 -3
@@ -36,8 +36,8 @@ void request_event_sources_irqs(struct device_node *np, virqs[count] =irq_create_of_mapping (&oirq);if (!virqs[count]) {pr_err ("event-sources: Unable to allocate " -"interrupt number for %s\n" , - np->full_name); +"interrupt number for %pOF\n" , + np);WARN_ON (1 ); }else { count++;
@@ -48,7 +48,7 @@ void request_event_sources_irqs(struct device_node *np,for (i =0 ; i < count; i++) {if (request_irq (virqs[i], handler,0 , name,NULL )) {pr_err ("event-sources: Unable to request interrupt " -"%d for %s\n" , virqs[i], np->full_name); +"%d for %pOF\n" , virqs[i], np);WARN_ON (1 );return ; }
arch/powerpc/platforms/pseries/hotplug-cpu.c +2 -2
@@ -264,8 +264,8 @@ static int pseries_add_processor(struct device_node *np)/* If we get here, it most likely means that NR_CPUS is * less than the partition's max processors setting. */ -printk (KERN_ERR "Cannot add cpu %s; this system configuration" -" supports %d logical cpus.\n" , np->full_name, +printk (KERN_ERR "Cannot add cpu %pOF; this system configuration" +" supports %d logical cpus.\n" , np,num_possible_cpus ()); goto out_unlock; }
arch/powerpc/platforms/pseries/ibmebus.c +2 -3
@@ -150,8 +150,7 @@ static const struct dma_map_ops ibmebus_dma_ops = {static int ibmebus_match_path (struct device *dev,void *data) {struct device_node *dn =to_platform_device (dev)->dev.of_node; -return (dn->full_name && - (strcasecmp ((char *)data, dn->full_name) ==0 )); +return (of_find_node_by_path (data) == dn); }static int ibmebus_match_node (struct device *dev,void *data)
@@ -395,7 +394,7 @@ static ssize_t devspec_show(struct device *dev,struct platform_device *ofdev; ofdev =to_platform_device (dev); -return sprintf (buf,"%s\n" , ofdev->dev.of_node->full_name); +return sprintf (buf,"%pOF\n" , ofdev->dev.of_node); }static DEVICE_ATTR_RO (devspec);
arch/powerpc/platforms/pseries/iommu.c +29 -29
143 lines not on this page · raw message
arch/powerpc/platforms/pseries/msi.c +6 -6
@@ -144,7 +144,7 @@ static int check_req(struct pci_dev *pdev, int nvec, char *prop_name) p =of_get_property (dn, prop_name,NULL );if (!p) { -pr_debug ("rtas_msi: No %s on %s\n" , prop_name, dn->full_name); +pr_debug ("rtas_msi: No %s on %pOF\n" , prop_name, dn);return -ENOENT ; }
@@ -182,8 +182,8 @@ static struct device_node *find_pe_total_msi(struct pci_dev *dev, int *total)while (dn) { p =of_get_property (dn,"ibm,pe-total-#msi" ,NULL );if (p) { -pr_debug ("rtas_msi: found prop on dn %s\n" , - dn->full_name); +pr_debug ("rtas_msi: found prop on dn %pOF\n" , + dn); *total =be32_to_cpup (p);return dn; }
@@ -222,7 +222,7 @@ static struct device_node *find_pe_dn(struct pci_dev *dev, int *total)/* Hardcode of 8 for old firmwares */ *total =8 ; -pr_debug ("rtas_msi: using PE dn %s\n" , dn->full_name); +pr_debug ("rtas_msi: using PE dn %pOF\n" , dn);return dn; }
@@ -242,7 +242,7 @@ static void *count_non_bridge_devices(struct device_node *dn, void *data)const __be32 *p;u32 class; -pr_debug ("rtas_msi: counting %s\n" , dn->full_name); +pr_debug ("rtas_msi: counting %pOF\n" , dn); p =of_get_property (dn,"class-code" ,NULL ); class = p ?be32_to_cpup (p) :0 ;
@@ -300,7 +300,7 @@ static int msi_quota_for_device(struct pci_dev *dev, int request) goto out; } -pr_debug ("rtas_msi: found PE %s\n" , pe_dn->full_name); +pr_debug ("rtas_msi: found PE %pOF\n" , pe_dn);memset (&counts,0 ,sizeof (struct msi_counts ));
arch/powerpc/platforms/pseries/pci_dlpar.c +1 -1
@@ -38,7 +38,7 @@ struct pci_controller *init_phb_dynamic(struct device_node *dn) {struct pci_controller *phb; -pr_debug ("PCI: Initializing new hotplug PHB %s\n" , dn->full_name); +pr_debug ("PCI: Initializing new hotplug PHB %pOF\n" , dn); phb =pcibios_alloc_controller (dn);if (!phb)
arch/powerpc/platforms/pseries/vio.c +3 -3
@@ -1362,9 +1362,9 @@ struct vio_dev *vio_register_device_node(struct device_node *of_node)else if (!strcmp (parent_node->full_name,"/vdevice" )) family =VDEVICE ;else { -pr_warn ("%s: parent(%s) of %s not recognized.\n" , +pr_warn ("%s: parent(%pOF) of %s not recognized.\n" , __func__, - parent_node->full_name, + parent_node, of_node_name);of_node_put (parent_node);return NULL ;
@@ -1555,7 +1555,7 @@ static ssize_t devspec_show(struct device *dev, {struct device_node *of_node = dev->of_node; -return sprintf (buf,"%s\n" ,of_node_full_name (of_node)); +return sprintf (buf,"%pOF\n" , of_node); }static DEVICE_ATTR_RO (devspec);
arch/powerpc/sysdev/axonram.c +2 -2
@@ -188,8 +188,8 @@ static int axon_ram_probe(struct platform_device *device) axon_ram_bank_id++; -dev_info (&device->dev,"Found memory controller on %s\n" , - device->dev.of_node->full_name); +dev_info (&device->dev,"Found memory controller on %pOF\n" , + device->dev.of_node); bank =kzalloc (sizeof (struct axon_ram_bank ),GFP_KERNEL );if (bank ==NULL ) {
arch/powerpc/sysdev/dcr.c +2 -2
@@ -195,8 +195,8 @@ dcr_host_mmio_t dcr_map_mmio(struct device_node *dev,dcr_host_mmio_t ret = { .token =NULL , .stride =0 , .base = dcr_n };u64 addr; -pr_debug ("dcr_map(%s, 0x%x, 0x%x)\n" , - dev->full_name, dcr_n, dcr_c); +pr_debug ("dcr_map(%pOF, 0x%x, 0x%x)\n" , + dev, dcr_n, dcr_c); addr =of_translate_dcr_address (dev, dcr_n, &ret.stride); pr_debug("translates to addr: 0x%llx, stride: 0x%x\n",
arch/powerpc/sysdev/fsl_85xx_cache_sram.c +6 -6
@@ -101,8 +101,8 @@ int __init instantiate_cache_sram(struct platform_device *dev,if (!request_mem_region (cache_sram->base_phys, cache_sram->size,"fsl_85xx_cache_sram" )) { -dev_err (&dev->dev,"%s: request memory failed\n" , - dev->dev.of_node->full_name); +dev_err (&dev->dev,"%pOF: request memory failed\n" , + dev->dev.of_node); ret = -ENXIO ; goto out_free; }
@@ -110,16 +110,16 @@ int __init instantiate_cache_sram(struct platform_device *dev, cache_sram->base_virt =ioremap_prot (cache_sram->base_phys, cache_sram->size, _PAGE_COHERENT |PAGE_KERNEL );if (!cache_sram->base_virt) { -dev_err (&dev->dev,"%s: ioremap_prot failed\n" , - dev->dev.of_node->full_name); +dev_err (&dev->dev,"%pOF: ioremap_prot failed\n" , + dev->dev.of_node); ret = -ENOMEM ; goto out_release; } cache_sram->rh =rh_create (sizeof (unsigned int ));if (IS_ERR (cache_sram->rh)) { -dev_err (&dev->dev,"%s: Unable to create remote heap\n" , - dev->dev.of_node->full_name); +dev_err (&dev->dev,"%pOF: Unable to create remote heap\n" , + dev->dev.of_node); ret =PTR_ERR (cache_sram->rh); goto out_unmap; }
arch/powerpc/sysdev/fsl_gtm.c +7 -7
@@ -388,8 +388,8 @@ static int __init fsl_gtm_init(void) gtm =kzalloc (sizeof (*gtm),GFP_KERNEL );if (!gtm) { -pr_err ("%s: unable to allocate memory\n" , - np->full_name); +pr_err ("%pOF: unable to allocate memory\n" , + np);continue ; }
@@ -397,7 +397,7 @@ static int __init fsl_gtm_init(void) clock =of_get_property (np,"clock-frequency" , &size);if (!clock || size !=sizeof (*clock)) { -pr_err ("%s: no clock-frequency\n" , np->full_name); +pr_err ("%pOF: no clock-frequency\n" , np); goto err; } gtm->clock = *clock;
@@ -407,8 +407,8 @@ static int __init fsl_gtm_init(void) irq =irq_of_parse_and_map (np, i);if (!irq) { -pr_err ("%s: not enough interrupts specified\n" , - np->full_name); +pr_err ("%pOF: not enough interrupts specified\n" , + np); goto err; } gtm->timers[i].irq = irq;
@@ -417,8 +417,8 @@ static int __init fsl_gtm_init(void) gtm->regs =of_iomap (np,0 );if (!gtm->regs) { -pr_err ("%s: unable to iomap registers\n" , - np->full_name); +pr_err ("%pOF: unable to iomap registers\n" , + np); goto err; }
arch/powerpc/sysdev/fsl_msi.c +8 -8
@@ -214,8 +214,8 @@ static int fsl_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type) phandle = np->phandle; else {dev_err (&pdev->dev, -"node %s has an invalid fsl,msi phandle %u\n" , - hose->dn->full_name, np->phandle); +"node %pOF has an invalid fsl,msi phandle %u\n" , + hose->dn, np->phandle);return -EINVAL ; } }
@@ -438,16 +438,16 @@ static int fsl_of_msi_probe(struct platform_device *dev)if ((features->fsl_pic_ip &FSL_PIC_IP_MASK ) !=FSL_PIC_IP_VMPIC ) { err =of_address_to_resource (dev->dev.of_node,0 , &res);if (err) { -dev_err (&dev->dev,"invalid resource for node %s\n" , - dev->dev.of_node->full_name); +dev_err (&dev->dev,"invalid resource for node %pOF\n" , + dev->dev.of_node); goto error_out; } msi->msi_regs =ioremap (res.start,resource_size (&res));if (!msi->msi_regs) { err = -ENOMEM ; -dev_err (&dev->dev,"could not map node %s\n" , - dev->dev.of_node->full_name); +dev_err (&dev->dev,"could not map node %pOF\n" , + dev->dev.of_node); goto error_out; } msi->msiir_offset =
@@ -522,8 +522,8 @@ static int fsl_of_msi_probe(struct platform_device *dev)for (irq_index =0 , i =0 ; i < len / (2 *sizeof (u32)); i++) {if (p[i *2 ] %IRQS_PER_MSI_REG || p[i *2 +1 ] %IRQS_PER_MSI_REG ) { -pr_warn ("%s: %s: msi available range of %u at %u is not IRQ-aligned\n" , - __func__, dev->dev.of_node->full_name, +pr_warn ("%s: %pOF: msi available range of %u at %u is not IRQ-aligned\n" , + __func__, dev->dev.of_node, p[i *2 +1 ], p[i *2 ]); err = -EINVAL ; goto error_out;
arch/powerpc/sysdev/fsl_pci.c +23 -24
132 lines not on this page · raw message
arch/powerpc/sysdev/fsl_rio.c +18 -18
@@ -450,12 +450,12 @@ int fsl_rio_setup(struct platform_device *dev) rc =of_address_to_resource (dev->dev.of_node,0 , ®s);if (rc) { -dev_err (&dev->dev,"Can't get %s property 'reg'\n" , - dev->dev.of_node->full_name); +dev_err (&dev->dev,"Can't get %pOF property 'reg'\n" , + dev->dev.of_node);return -EFAULT ; } -dev_info (&dev->dev,"Of-device full name %s\n" , - dev->dev.of_node->full_name); +dev_info (&dev->dev,"Of-device full name %pOF\n" , + dev->dev.of_node);dev_info (&dev->dev,"Regs: %pR\n" , ®s); rio_regs_win =ioremap (regs.start,resource_size (®s));
@@ -494,8 +494,8 @@ int fsl_rio_setup(struct platform_device *dev) } rc =of_address_to_resource (rmu_node,0 , &rmu_regs);if (rc) { -dev_err (&dev->dev,"Can't get %s property 'reg'\n" , - rmu_node->full_name); +dev_err (&dev->dev,"Can't get %pOF property 'reg'\n" , + rmu_node); goto err_rmu; } rmu_regs_win =ioremap (rmu_regs.start,resource_size (&rmu_regs));
@@ -529,8 +529,8 @@ int fsl_rio_setup(struct platform_device *dev) aw =of_n_addr_cells (np); dt_range =of_get_property (np,"reg" , &rlen);if (!dt_range) { -pr_err ("%s: unable to find 'reg' property\n" , - np->full_name); +pr_err ("%pOF: unable to find 'reg' property\n" , + np); rc = -ENOMEM ; goto err_pw; }
@@ -557,8 +557,8 @@ int fsl_rio_setup(struct platform_device *dev) aw =of_n_addr_cells (np); dt_range =of_get_property (np,"reg" , &rlen);if (!dt_range) { -pr_err ("%s: unable to find 'reg' property\n" , - np->full_name); +pr_err ("%pOF: unable to find 'reg' property\n" , + np); rc = -ENOMEM ; goto err; }
@@ -569,15 +569,15 @@ int fsl_rio_setup(struct platform_device *dev)for_each_child_of_node (dev->dev.of_node, np) { port_index =of_get_property (np,"cell-index" ,NULL );if (!port_index) { -dev_err (&dev->dev,"Can't get %s property 'cell-index'\n" , - np->full_name); +dev_err (&dev->dev,"Can't get %pOF property 'cell-index'\n" , + np);continue ; } dt_range =of_get_property (np,"ranges" , &rlen);if (!dt_range) { -dev_err (&dev->dev,"Can't get %s property 'ranges'\n" , - np->full_name); +dev_err (&dev->dev,"Can't get %pOF property 'ranges'\n" , + np);continue ; }
@@ -598,8 +598,8 @@ int fsl_rio_setup(struct platform_device *dev) range_start =of_read_number (dt_range + aw, paw); range_size =of_read_number (dt_range + aw + paw, sw); -dev_info (&dev->dev,"%s: LAW start 0x%016llx, size 0x%016llx.\n" , - np->full_name, range_start, range_size); +dev_info (&dev->dev,"%pOF: LAW start 0x%016llx, size 0x%016llx.\n" , + np, range_start, range_size); port =kzalloc (sizeof (struct rio_mport ),GFP_KERNEL );if (!port)
@@ -757,8 +757,8 @@ int fsl_rio_setup(struct platform_device *dev)*/ static int fsl_of_rio_rpn_probe (struct platform_device *dev) { -printk (KERN_INFO "Setting up RapidIO peer-to-peer network %s\n" , - dev->dev.of_node->full_name); +printk (KERN_INFO "Setting up RapidIO peer-to-peer network %pOF\n" , + dev->dev.of_node);return fsl_rio_setup (dev); };
arch/powerpc/sysdev/fsl_rmu.c +6 -6
@@ -1074,8 +1074,8 @@ int fsl_rio_setup_rmu(struct rio_mport *mport, struct device_node *node) priv = mport->priv;if (!node) { -dev_warn (priv->dev,"Can't get %s property 'fsl,rmu'\n" , - priv->dev->of_node->full_name); +dev_warn (priv->dev,"Can't get %pOF property 'fsl,rmu'\n" , + priv->dev->of_node);return -EINVAL ; }
@@ -1086,8 +1086,8 @@ int fsl_rio_setup_rmu(struct rio_mport *mport, struct device_node *node) aw =of_n_addr_cells (node); msg_addr =of_get_property (node,"reg" , &mlen);if (!msg_addr) { -pr_err ("%s: unable to find 'reg' property of message-unit\n" , - node->full_name); +pr_err ("%pOF: unable to find 'reg' property of message-unit\n" , + node);kfree (rmu);return -ENOMEM ; }
@@ -1098,8 +1098,8 @@ int fsl_rio_setup_rmu(struct rio_mport *mport, struct device_node *node) rmu->txirq =irq_of_parse_and_map (node,0 ); rmu->rxirq =irq_of_parse_and_map (node,1 ); -printk (KERN_INFO "%s: txirq: %d, rxirq %d\n" , - node->full_name, rmu->txirq, rmu->rxirq); +printk (KERN_INFO "%pOF: txirq: %d, rxirq %d\n" , + node, rmu->txirq, rmu->rxirq); priv->rmm_handle = rmu;
arch/powerpc/sysdev/mpic.c +2 -2
@@ -1650,8 +1650,8 @@ void __init mpic_init(struct mpic *mpic)if (mpic->flags &MPIC_SECONDARY ) {int virq =irq_of_parse_and_map (mpic->node,0 );if (virq) { -printk (KERN_INFO "%s: hooking up to IRQ %d\n" , - mpic->node->full_name, virq); +printk (KERN_INFO "%pOF: hooking up to IRQ %d\n" , + mpic->node, virq);irq_set_handler_data (virq, mpic);irq_set_chained_handler (virq, &mpic_cascade); }
arch/powerpc/sysdev/mpic_msgr.c +1 -1
@@ -192,7 +192,7 @@ static int mpic_msgr_probe(struct platform_device *dev)return -ENOMEM ; } } -dev_info (&dev->dev,"Of-device full name %s\n" , np->full_name); +dev_info (&dev->dev,"Of-device full name %pOF\n" , np);/* IO map the message register block. */ of_address_to_resource (np,0 , &rsrc);
arch/powerpc/sysdev/mpic_msi.c +1 -1
@@ -60,7 +60,7 @@ static int mpic_msi_reserve_u3_hwirqs(struct mpic *mpic) np =NULL ;while ((np =of_find_all_nodes (np))) { -pr_debug ("mpic: mapping hwirqs for %s\n" , np->full_name); +pr_debug ("mpic: mapping hwirqs for %pOF\n" , np); index =0 ;while (of_irq_parse_one (np, index++, &oirq) ==0 ) {
arch/powerpc/sysdev/mpic_timer.c +7 -12
@@ -466,8 +466,7 @@ static int timer_group_get_irq(struct device_node *np, p =of_get_property (np,"fsl,available-ranges" , &len);if (p && len % (2 *sizeof (u32)) !=0 ) { -pr_err ("%s: malformed available-ranges property.\n" , - np->full_name); +pr_err ("%pOF: malformed available-ranges property.\n" , np);return -EINVAL ; }
@@ -484,8 +483,7 @@ static int timer_group_get_irq(struct device_node *np,for (j =0 ; j < count; j++) { irq =irq_of_parse_and_map (np, irq_index);if (!irq) { -pr_err ("%s: irq parse and map failed.\n" , - np->full_name); +pr_err ("%pOF: irq parse and map failed.\n" , np);return -EINVAL ; }
@@ -508,8 +506,7 @@ static void timer_group_init(struct device_node *np) priv =kzalloc (sizeof (struct timer_group_priv ),GFP_KERNEL );if (!priv) { -pr_err ("%s: cannot allocate memory for group.\n" , - np->full_name); +pr_err ("%pOF: cannot allocate memory for group.\n" , np);return ; }
@@ -518,29 +515,27 @@ static void timer_group_init(struct device_node *np) priv->regs =of_iomap (np, i++);if (!priv->regs) { -pr_err ("%s: cannot ioremap timer register address.\n" , - np->full_name); +pr_err ("%pOF: cannot ioremap timer register address.\n" , np); goto out; }if (priv->flags &FSL_GLOBAL_TIMER ) { priv->group_tcr =of_iomap (np, i++);if (!priv->group_tcr) { -pr_err ("%s: cannot ioremap tcr address.\n" , - np->full_name); +pr_err ("%pOF: cannot ioremap tcr address.\n" , np); goto out; } } ret =timer_group_get_freq (np, priv);if (ret <0 ) { -pr_err ("%s: cannot get timer frequency.\n" , np->full_name); +pr_err ("%pOF: cannot get timer frequency.\n" , np); goto out; } ret =timer_group_get_irq (np, priv);if (ret <0 ) { -pr_err ("%s: cannot get timer irqs.\n" , np->full_name); +pr_err ("%pOF: cannot get timer irqs.\n" , np); goto out; }
arch/powerpc/sysdev/msi_bitmap.c +2 -2
@@ -86,13 +86,13 @@ int msi_bitmap_reserve_dt_hwirqs(struct msi_bitmap *bmp) p =of_get_property (bmp->of_node,"msi-available-ranges" , &len);if (!p) {pr_debug ("msi_bitmap: no msi-available-ranges property " \ -"found on %s\n" , bmp->of_node->full_name); +"found on %pOF\n" , bmp->of_node);return 1 ; }if (len % (2 *sizeof (u32)) !=0 ) {printk (KERN_WARNING "msi_bitmap: Malformed msi-available-ranges" -" property on %s\n" , bmp->of_node->full_name); +" property on %pOF\n" , bmp->of_node);return -EINVAL ; }
arch/powerpc/sysdev/mv64x60_dev.c +10 -10
@@ -452,8 +452,8 @@ static int __init mv64x60_device_setup(void) err =mv64x60_mpsc_device_setup (np, id++);if (err)printk (KERN_ERR "Failed to initialize MV64x60 " -"serial device %s: error %d.\n" , - np->full_name, err); +"serial device %pOF: error %d.\n" , + np, err); } id =0 ;
@@ -463,8 +463,8 @@ static int __init mv64x60_device_setup(void)if (IS_ERR (pdev)) { err =PTR_ERR (pdev);printk (KERN_ERR "Failed to initialize MV64x60 " -"network block %s: error %d.\n" , - np->full_name, err); +"network block %pOF: error %d.\n" , + np, err);continue ; }for_each_child_of_node (np, np2) {
@@ -474,9 +474,9 @@ static int __init mv64x60_device_setup(void) err =mv64x60_eth_device_setup (np2, id2++, pdev);if (err)printk (KERN_ERR "Failed to initialize " -"MV64x60 network device %s: " +"MV64x60 network device %pOF: " "error %d.\n" , - np2->full_name, err); + np2, err); } }
@@ -485,8 +485,8 @@ static int __init mv64x60_device_setup(void) err =mv64x60_i2c_device_setup (np, id++);if (err)printk (KERN_ERR "Failed to initialize MV64x60 I2C " -"bus %s: error %d.\n" , - np->full_name, err); +"bus %pOF: error %d.\n" , + np, err); }/* support up to one watchdog timer */
@@ -494,8 +494,8 @@ static int __init mv64x60_device_setup(void)if (np) {if ((err =mv64x60_wdt_device_setup (np, id)))printk (KERN_ERR "Failed to initialize MV64x60 " -"Watchdog %s: error %d.\n" , - np->full_name, err); +"Watchdog %pOF: error %d.\n" , + np, err);of_node_put (np); }
arch/powerpc/sysdev/mv64x60_pci.c +2 -2
@@ -136,8 +136,8 @@ static int __init mv64x60_add_bridge(struct device_node *dev)/* Get bus range if any */ bus_range =of_get_property (dev,"bus-range" , &len);if (bus_range ==NULL || len <2 *sizeof (int )) -printk (KERN_WARNING "Can't get bus-range for %s, assume" -" bus 0\n" , dev->full_name); +printk (KERN_WARNING "Can't get bus-range for %pOF, assume" +" bus 0\n" , dev); hose =pcibios_alloc_controller (dev);if (!hose)
arch/powerpc/sysdev/of_rtc.c +6 -6
@@ -38,21 +38,21 @@ void __init of_instantiate_rtc(void) res =kmalloc (sizeof (*res),GFP_KERNEL );if (!res) {printk (KERN_ERR "OF RTC: Out of memory " -"allocating resource structure for %s\n" , - node->full_name); +"allocating resource structure for %pOF\n" , + node);continue ; } err =of_address_to_resource (node,0 , res);if (err) {printk (KERN_ERR "OF RTC: Error " -"translating resources for %s\n" , - node->full_name); +"translating resources for %pOF\n" , + node);continue ; } -printk (KERN_INFO "OF_RTC: %s is a %s @ 0x%llx-0x%llx\n" , - node->full_name, plat_name, +printk (KERN_INFO "OF_RTC: %pOF is a %s @ 0x%llx-0x%llx\n" , + node, plat_name, (unsigned long long )res->start, (unsigned long long )res->end);platform_device_register_simple (plat_name,-1 , res,1 );
arch/powerpc/sysdev/scom.c +3 -2
@@ -194,12 +194,13 @@ static int scom_debug_init_one(struct dentry *root, struct device_node *dn, ent->dn =of_node_get (dn);snprintf (ent->name,16 ,"%08x" , i); - ent->path.data = (void *) dn->full_name; - ent->path.size =strlen (dn->full_name); + ent->path.data = (void *)kasprintf (GFP_KERNEL ,"%pOF" , dn); + ent->path.size =strlen ((char *)ent->path.data); dir =debugfs_create_dir (ent->name, root);if (!dir) {of_node_put (dn); +kfree (ent->path.data);kfree (ent);return -1 ; }
arch/powerpc/sysdev/simple_gpio.c +1 -2
@@ -142,7 +142,6 @@ void __init simple_gpiochip_init(const char *compatible) }continue ; err: -pr_err ("%s: registration failed, status %d\n" , - np->full_name, ret); +pr_err ("%pOF: registration failed, status %d\n" , np, ret); } }
arch/powerpc/sysdev/tsi108_pci.c +2 -2
@@ -213,8 +213,8 @@ int __init tsi108_setup_pci(struct device_node *dev, u32 cfg_phys, int primary)/* Get bus range if any */ bus_range =of_get_property (dev,"bus-range" , &len);if (bus_range ==NULL || len <2 *sizeof (int )) { -printk (KERN_WARNING "Can't get bus-range for %s, assume" -" bus 0\n" , dev->full_name); +printk (KERN_WARNING "Can't get bus-range for %pOF, assume" +" bus 0\n" , dev); } hose =pcibios_alloc_controller (dev);
arch/powerpc/sysdev/xive/native.c +1 -1
@@ -551,7 +551,7 @@ bool __init xive_native_init(void)pr_devel ("not found !\n" );return false; } -pr_devel ("Found %s\n" , np->full_name); +pr_devel ("Found %pOF\n" , np);/* Resource 1 is HV window */ if (of_address_to_resource (np,1 , &r)) {
Signature · 1 line
2.11.0
Michael Ellerman
AppliedRe: [v2,1/5] powerpc: Convert to using %pOF instead of full_name
Quoted 4 lines · Rob Herring
Now that we have a custom printf format specifier, convert users of
full_nameto use %pOF instead. This is preparation to remove storing of the full path string for each node.
Quoted 10 lines
Signed-off-by Rob Herring <[email protected]>Cc Benjamin Herrenschmidt <[email protected]>Cc Paul Mackerras <[email protected]>Cc Michael Ellerman <mpe-Gsx/[email protected]>Cc Anatolij Gustschin <[email protected]>Cc Scott Wood <[email protected]>Cc Kumar Gala <[email protected]>Cc Arnd Bergmann <[email protected]>Cc linuxppc-dev-uLR06cmDAlY/[email protected]Reviewed-by Tyrel Datwyler <[email protected]>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/b7c670d673d1186e9a6aafaad36aac
I forgot to add in the change log I took the chance to reformat some of the affected printks, hopefully that doesn't muck you up when you're merging/rebasing on top of this.
cheers
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Rob Herring
maintainerPATCH v2 2/5 powerpc: pseries: vio: match parent nodes with of_find_node_by_path
In reply to Rob HerringIn preparation to remove the full path from device_node.full_name, use of_find_node_by_path instead of open coding with strcmp.
---
v2:
- rebased to linux-next and removed spurious change fro patch 1.
arch/powerpc/platforms/pseries/vio.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/powerpc/platforms/pseries/vio.c +2 -2
@@ -1357,9 +1357,9 @@ struct vio_dev *vio_register_device_node(struct device_node *of_node)*/ parent_node =of_get_parent (of_node);if (parent_node) { -if (!strcmp (parent_node->full_name,"/ibm,platform-facilities" )) +if (parent_node ==of_find_node_by_path ("/ibm,platform-facilities" )) family =PFO ; -else if (!strcmp (parent_node->full_name,"/vdevice" )) +else if (parent_node ==of_find_node_by_path ("/vdevice" )) family =VDEVICE ;else { pr_warn("%s: parent(%pOF) of %s not recognized.\n",
Signature · 1 line
2.11.0
Michael Ellerman
reviewerRe: [PATCH v2 2/5] powerpc: pseries: vio: match parent nodes with of_find_node_by_path
Quoted 20 lines · Rob Herring
In preparation to remove the full path from device_node.full_name, use
of_find_node_by_pathinstead of open coding with strcmp.Signed-off-by Rob Herring <[email protected]>Cc Benjamin Herrenschmidt <[email protected]>Cc Paul Mackerras <[email protected]>Cc Michael Ellerman <mpe-Gsx/[email protected]>Cc linuxppc-dev-uLR06cmDAlY/[email protected]---
v2:
- rebased to linux-next and removed spurious change fro patch 1.arch/powerpc/platforms/pseries/vio.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)arch/powerpc/platforms/pseries/vio.c +0
-0
arch/powerpc/platforms/pseries/vio.c struct vio_dev *vio_register_device_node(struct device_node *of_node) · line 1363
Quoted 9 lines
arch/powerpc/platforms/pseries/vio.c +2
-2@@ -1357,9 +1357,9 @@ struct vio_dev *vio_register_device_node(struct device_node *of_node)*/ parent_node =of_get_parent (of_node);if (parent_node) { -if (!strcmp (parent_node->full_name,"/ibm,platform-facilities" )) +if (parent_node ==of_find_node_by_path ("/ibm,platform-facilities" )) family =PFO ; -else if (!strcmp (parent_node->full_name,"/vdevice" )) +else if (parent_node ==of_find_node_by_path ("/vdevice" )) family =VDEVICE ;
This leaks references to the looked up nodes.
Both these nodes are defined in PAPR (our hypervisor spec), and both of them must have a device_type, either "ibm,platform-facilities" or "vdevice".
Looking at the commit that added the code I don't see any particular reason it used the comparison against full_name, rather than using the device_type.
So I'm inclined to do this instead:
arch/powerpc/platforms/pseries/vio.c +2 -2
@@ -1357,9 +1357,9 @@ struct vio_dev *vio_register_device_node(struct device_node *of_node)*/ parent_node =of_get_parent (of_node);if (parent_node) { -if (!strcmp (parent_node->full_name,"/ibm,platform-facilities" )) +if (!strcmp (parent_node->type,"ibm,platform-facilities" )) family =PFO ; -else if (!strcmp (parent_node->full_name,"/vdevice" )) +else if (!strcmp (parent_node->type,"vdevice" )) family =VDEVICE ;else { pr_warn("%s: parent(%s) of %s not recognized.\n",
I've checked both Qemu and kvmtool add the device_type, and I'm fairly confident that PowerVM does too. Anyway I'll test it on all the machines I can find.
cheers
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Rob Herring
maintainerRe: [PATCH v2 2/5] powerpc: pseries: vio: match parent nodes with of_find_node_by_path
Quoted 62 lines · Michael Ellerman
Quoted 20 lines · Rob Herring
In preparation to remove the full path from device_node.full_name, use
of_find_node_by_pathinstead of open coding with strcmp.Signed-off-by Rob Herring <[email protected]>Cc Benjamin Herrenschmidt <[email protected]>Cc Paul Mackerras <[email protected]>Cc Michael Ellerman <mpe-Gsx/[email protected]>Cc linuxppc-dev-uLR06cmDAlY/[email protected]---
v2:
- rebased to linux-next and removed spurious change fro patch 1.arch/powerpc/platforms/pseries/vio.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)arch/powerpc/platforms/pseries/vio.c +0
-0arch/powerpc/platforms/pseries/vio.c struct vio_dev *vio_register_device_node(struct device_node *of_node) · line 1363
Quoted 9 lines
arch/powerpc/platforms/pseries/vio.c +2
-2@@ -1357,9 +1357,9 @@ struct vio_dev *vio_register_device_node(struct device_node *of_node)*/ parent_node =of_get_parent (of_node);if (parent_node) { -if (!strcmp (parent_node->full_name,"/ibm,platform-facilities" )) +if (parent_node ==of_find_node_by_path ("/ibm,platform-facilities" )) family =PFO ; -else if (!strcmp (parent_node->full_name,"/vdevice" )) +else if (parent_node ==of_find_node_by_path ("/vdevice" )) family =VDEVICE ;This leaks references to the looked up nodes.
Both these nodes are defined in PAPR (our hypervisor spec), and both of them must have a
device_type, either "ibm,platform-facilities" or "vdevice".Looking at the commit that added the code I don't see any particular reason it used the comparison against
full_name, rather than using thedevice_type.So I'm inclined to do this instead:
arch/powerpc/platforms/pseries/vio.c +2
-2@@ -1357,9 +1357,9 @@ struct vio_dev *vio_register_device_node(struct device_node *of_node)*/ parent_node =of_get_parent (of_node);if (parent_node) { -if (!strcmp (parent_node->full_name,"/ibm,platform-facilities" )) +if (!strcmp (parent_node->type,"ibm,platform-facilities" )) family =PFO ; -else if (!strcmp (parent_node->full_name,"/vdevice" )) +else if (!strcmp (parent_node->type,"vdevice" )) family =VDEVICE ;else { pr_warn("%s: parent(%s) of %s not recognized.\n",
Quoted 3 lines
I've checked both Qemu and kvmtool add the
device_type, and I'm fairly confident that PowerVM does too. Anyway I'll test it on all the machines I can find.
Okay, do you want me to respin the patch or will you update it with the above change?
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Michael Ellerman
reviewerRe: [PATCH v2 2/5] powerpc: pseries: vio: match parent nodes with of_find_node_by_path
Quoted 63 lines · Rob Herring
Quoted 62 lines · Michael Ellerman
Quoted 20 lines · Rob Herring
In preparation to remove the full path from device_node.full_name, use
of_find_node_by_pathinstead of open coding with strcmp.Signed-off-by Rob Herring <[email protected]>Cc Benjamin Herrenschmidt <[email protected]>Cc Paul Mackerras <[email protected]>Cc Michael Ellerman <mpe-Gsx/[email protected]>Cc linuxppc-dev-uLR06cmDAlY/[email protected]---
v2:
- rebased to linux-next and removed spurious change fro patch 1.arch/powerpc/platforms/pseries/vio.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)arch/powerpc/platforms/pseries/vio.c +0
-0arch/powerpc/platforms/pseries/vio.c struct vio_dev *vio_register_device_node(struct device_node *of_node) · line 1363
Quoted 9 lines
arch/powerpc/platforms/pseries/vio.c +2
-2@@ -1357,9 +1357,9 @@ struct vio_dev *vio_register_device_node(struct device_node *of_node)*/ parent_node =of_get_parent (of_node);if (parent_node) { -if (!strcmp (parent_node->full_name,"/ibm,platform-facilities" )) +if (parent_node ==of_find_node_by_path ("/ibm,platform-facilities" )) family =PFO ; -else if (!strcmp (parent_node->full_name,"/vdevice" )) +else if (parent_node ==of_find_node_by_path ("/vdevice" )) family =VDEVICE ;This leaks references to the looked up nodes.
Both these nodes are defined in PAPR (our hypervisor spec), and both of them must have a
device_type, either "ibm,platform-facilities" or "vdevice".Looking at the commit that added the code I don't see any particular reason it used the comparison against
full_name, rather than using thedevice_type.So I'm inclined to do this instead:
arch/powerpc/platforms/pseries/vio.c +2
-2@@ -1357,9 +1357,9 @@ struct vio_dev *vio_register_device_node(struct device_node *of_node)*/ parent_node =of_get_parent (of_node);if (parent_node) { -if (!strcmp (parent_node->full_name,"/ibm,platform-facilities" )) +if (!strcmp (parent_node->type,"ibm,platform-facilities" )) family =PFO ; -else if (!strcmp (parent_node->full_name,"/vdevice" )) +else if (!strcmp (parent_node->type,"vdevice" )) family =VDEVICE ;else { pr_warn("%s: parent(%s) of %s not recognized.\n",
Quoted 5 lines
Quoted 3 lines
I've checked both Qemu and kvmtool add the
device_type, and I'm fairly confident that PowerVM does too. Anyway I'll test it on all the machines I can find.Okay, do you want me to respin the patch or will you update it with
I merged it. Should be in next today.
cheers
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Rob Herring
maintainerPATCH v2 3/5 powerpc: pseries: remove dlpar_attach_node dependency on full path
In reply to Rob HerringIn preparation to stop storing the full node path in full_name, remove the dependency on full_name from dlpar_attach_node(). Callers of dlpar_attach_node() already have the parent device_node, so just pass the parent node into dlpar_attach_node instead of the path. This avoids doing a lookup of the parent node by the path.
---
v2:
- rebased to linux-next
arch/powerpc/platforms/pseries/dlpar.c | 6 ++---- arch/powerpc/platforms/pseries/hotplug-cpu.c | 2 +- arch/powerpc/platforms/pseries/mobility.c | 2 +- arch/powerpc/platforms/pseries/pseries.h | 2 +- 4 files changed, 5 insertions(+), 7 deletions(-)
arch/powerpc/platforms/pseries/dlpar.c +2 -4
@@ -254,13 +254,11 @@ struct device_node *dlpar_configure_connector(__be32 drc_index,return first_dn; } -int dlpar_attach_node (struct device_node *dn) +int dlpar_attach_node (struct device_node *dn,struct device_node *parent) {int rc; - dn->parent =pseries_of_derive_parent (dn->full_name); -if (IS_ERR (dn->parent)) -return PTR_ERR (dn->parent); + dn->parent = parent; rc =of_attach_node (dn);if (rc) {
arch/powerpc/platforms/pseries/hotplug-cpu.c +1 -1
@@ -463,7 +463,7 @@ static ssize_t dlpar_cpu_add(u32 drc_index)return -EINVAL ; } - rc =dlpar_attach_node (dn); + rc =dlpar_attach_node (dn, parent);if (rc) { saved_rc = rc; pr_warn("Failed to attach node %s, rc: %d, drc index: %x\n",
arch/powerpc/platforms/pseries/mobility.c +1 -1
@@ -229,7 +229,7 @@ static int add_dt_node(__be32 parent_phandle, __be32 drc_index)if (!dn)return -ENOENT ; - rc =dlpar_attach_node (dn); + rc =dlpar_attach_node (dn, parent_dn);if (rc)dlpar_free_cc_nodes (dn);
arch/powerpc/platforms/pseries/pseries.h +1 -1
@@ -46,7 +46,7 @@ extern void dlpar_free_cc_nodes(struct device_node *);extern void dlpar_free_cc_property (struct property *);extern struct device_node *dlpar_configure_connector (__be32 ,struct device_node *); -extern int dlpar_attach_node (struct device_node *); +extern int dlpar_attach_node (struct device_node *,struct device_node *);extern int dlpar_detach_node (struct device_node *);extern int dlpar_acquire_drc (u32 drc_index);extern int dlpar_release_drc (u32 drc_index);
Signature · 1 line
2.11.0
Michael Ellerman
AppliedRe: [v2, 3/5] powerpc: pseries: remove dlpar_attach_node dependency on full path
Quoted 11 lines · Rob Herring
In preparation to stop storing the full node path in
full_name, remove the dependency onfull_namefromdlpar_attach_node(). Callers ofdlpar_attach_node()already have the parentdevice_node, so just pass the parent node intodlpar_attach_nodeinstead of the path. This avoids doing a lookup of the parent node by the path.Signed-off-by Rob Herring <[email protected]>Cc Benjamin Herrenschmidt <[email protected]>Cc Paul Mackerras <[email protected]>Cc Michael Ellerman <[email protected]>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/215ee763f8cb9a2912d411f96f6f67
cheers
Rob Herring
maintainerPATCH v2 4/5 powerpc: pseries: only store the device node basename in full_name
In reply to Rob HerringWith dependencies on full_name containing the entire device node path removed, stop storing the full_name in nodes created by dlpar_configure_connector() and pSeries_reconfig_add_node().
---
v2:
- Rework dlpar_parse_cc_node() to a single allocation and strcpy instead of kasprintf
arch/powerpc/platforms/pseries/dlpar.c | 30 +++++++----------------------- arch/powerpc/platforms/pseries/reconfig.c | 2 +- 2 files changed, 8 insertions(+), 24 deletions(-)
arch/powerpc/platforms/pseries/dlpar.c +7 -23
@@ -75,28 +75,17 @@ static struct property *dlpar_parse_cc_property(struct cc_workarea *ccwa)return prop; } -static struct device_node *dlpar_parse_cc_node (struct cc_workarea *ccwa, -const char *path) +static struct device_node *(dlpar_parse_cc_node)(struct cc_workarea *ccwa) {struct device_node *dn; -char *name; - -/* If parent node path is "/" advance path to NULL terminator to -* prevent double leading slashs in full_name. -*/ -if (!path[1 ]) - path++; +const char *name = (const char *)ccwa +be32_to_cpu (ccwa->name_offset); - dn =kzalloc (sizeof (*dn),GFP_KERNEL ); + dn =kzalloc (sizeof (*dn) +strlen (name) +1 ,GFP_KERNEL );if (!dn)return NULL ; - name = (char *)ccwa +be32_to_cpu (ccwa->name_offset); - dn->full_name =kasprintf (GFP_KERNEL ,"%s/%s" , path, name); -if (!dn->full_name) { -kfree (dn); -return NULL ; - } + dn->full_name = (char *)(dn +1 ); +strcpy ((char *)dn->full_name, name);of_node_set_flag (dn,OF_DYNAMIC );of_node_init (dn);
@@ -148,7 +137,6 @@ struct device_node *dlpar_configure_connector(__be32 drc_index,struct property *last_property =NULL ;struct cc_workarea *ccwa;char *data_buf; -const char *parent_path = parent->full_name;int cc_token;int rc =-1 ;
@@ -182,7 +170,7 @@ struct device_node *dlpar_configure_connector(__be32 drc_index,break ;case NEXT_SIBLING : - dn =dlpar_parse_cc_node (ccwa, parent_path); + dn =dlpar_parse_cc_node (ccwa);if (!dn) goto cc_error;
@@ -192,10 +180,7 @@ struct device_node *dlpar_configure_connector(__be32 drc_index,break ;case NEXT_CHILD : -if (first_dn) - parent_path = last_dn->full_name; - - dn =dlpar_parse_cc_node (ccwa, parent_path); + dn =dlpar_parse_cc_node (ccwa);if (!dn) goto cc_error;
@@ -226,7 +211,6 @@ struct device_node *dlpar_configure_connector(__be32 drc_index,case PREV_PARENT : last_dn = last_dn->parent; - parent_path = last_dn->parent->full_name;break ;case CALL_AGAIN :
arch/powerpc/platforms/pseries/reconfig.c +1 -1
@@ -33,7 +33,7 @@ static int pSeries_reconfig_add_node(const char *path, struct property *proplistif (!np) goto out_err; - np->full_name =kstrdup (path,GFP_KERNEL ); + np->full_name =kstrdup (kbasename (path),GFP_KERNEL );if (!np->full_name) goto out_err;
Signature · 1 line
2.11.0
Michael Ellerman
reviewerRe: [PATCH v2 4/5] powerpc: pseries: only store the device node basename in full_name
Hi Rob,
Unfortunately this one has a bug, which only showed up after some stress testing.
Quoted 43 lines · Rob Herring
With dependencies on
full_namecontaining the entire device node path removed, stop storing thefull_namein nodes created bydlpar_configure_connector()andpSeries_reconfig_add_node().Signed-off-by Rob Herring <[email protected]>Cc Benjamin Herrenschmidt <[email protected]>Cc Paul Mackerras <[email protected]>Cc Michael Ellerman <[email protected]>---
v2:
- Reworkdlpar_parse_cc_node()to a single allocation and strcpy instead of kasprintfarch/powerpc/platforms/pseries/dlpar.c | 30 +++++++----------------------- arch/powerpc/platforms/pseries/reconfig.c | 2 +- 2 files changed, 8 insertions(+), 24 deletions(-)arch/powerpc/platforms/pseries/dlpar.c +3
-10@@ -75,28 +75,17 @@ static struct property *dlpar_parse_cc_property(struct cc_workarea *ccwa)return prop; } -static struct device_node *dlpar_parse_cc_node (struct cc_workarea *ccwa, -const char *path) +static struct device_node *(dlpar_parse_cc_node)(struct cc_workarea *ccwa) {struct device_node *dn; -char *name; - -/* If parent node path is "/" advance path to NULL terminator to -* prevent double leading slashs in full_name. -*/ -if (!path[1 ]) - path++; +const char *name = (const char *)ccwa +be32_to_cpu (ccwa->name_offset); - dn =kzalloc (sizeof (*dn),GFP_KERNEL ); + dn =kzalloc (sizeof (*dn) +strlen (name) +1 ,GFP_KERNEL );if (!dn)
arch/powerpc/platforms/pseries/dlpar.c static struct property *dlpar_parse_cc_property(struct cc_workarea *ccwa) · line 88
Quoted 10 lines
arch/powerpc/platforms/pseries/dlpar.c +2
-6return NULL ; - name = (char *)ccwa +be32_to_cpu (ccwa->name_offset); - dn->full_name =kasprintf (GFP_KERNEL ,"%s/%s" , path, name); -if (!dn->full_name) { -kfree (dn); -return NULL ; - } + dn->full_name = (char *)(dn +1 ); +strcpy ((char *)dn->full_name, name);
Allocating the full_name on the tail of the struct this way breaks the call to kfree(node->full_name) in of_node_release().
eg:
[ 322.543581] Freeing node->full_name c0000007f4ed4090 [ 322.543583] ============================================================================= [ 322.543586] BUG kmalloc-192 (Tainted: G B ): Invalid object pointer 0xc0000007f4ed4090 [ 322.543588] -----------------------------------------------------------------------------
[ 322.543592] INFO: Slab 0xf000000001fd3b40 objects=292 used=72 fp=0xc0000007f4ed41a8 flags=0x13ffff800000101 [ 322.543595] CPU: 40 PID: 5 Comm: kworker/u192:0 Tainted: G B 4.14.0-rc2-gcc-6.3.1-next-20170929-dirty #429 [ 322.543600] Workqueue: pseries hotplug workque pseries_hp_work_fn [ 322.543602] Call Trace: [ 322.543605] [c0000003f769f660] [c000000000a6b710] dump_stack+0xb0/0xf0 (unreliable) [ 322.543609] [c0000003f769f6a0] [c00000000032cd5c] slab_err+0x9c/0xc0 [ 322.543612] [c0000003f769f790] [c00000000033440c] free_debug_processing+0x19c/0x490 [ 322.543615] [c0000003f769f860] [c0000000003349fc] __slab_free+0x2fc/0x4b0 [ 322.543619] [c0000003f769f960] [c0000000008f2484] of_node_release+0xe4/0x1a0 [ 322.543622] [c0000003f769fa00] [c000000000a71c04] kobject_put+0xd4/0x160 [ 322.543625] [c0000003f769fa80] [c0000000008f10c4] of_node_put+0x34/0x50 [ 322.543628] [c0000003f769fab0] [c0000000000c0248] dlpar_cpu_remove_by_index+0x108/0x130 [ 322.543631] [c0000003f769fb40] [c0000000000c166c] dlpar_cpu+0x27c/0x510 [ 322.543634] [c0000003f769fbf0] [c0000000000bb2d0] handle_dlpar_errorlog+0xc0/0x160 [ 322.543638] [c0000003f769fc60] [c0000000000bb3ac] pseries_hp_work_fn+0x3c/0xa0 [ 322.543641] [c0000003f769fc90] [c00000000012200c] process_one_work+0x2bc/0x560 [ 322.543645] [c0000003f769fd20] [c000000000122348] worker_thread+0x98/0x5d0 [ 322.543648] [c0000003f769fdc0] [c00000000012b4e4] kthread+0x164/0x1b0 [ 322.543651] [c0000003f769fe30] [c00000000000bae0] ret_from_kernel_thread+0x5c/0x7c
The obvious fix is just to allocate it separately as before, eg ~=:
arch/powerpc/platforms/pseries/dlpar.c +7 -2
@@ -80,11 +80,16 @@ static struct device_node *dlpar_parse_cc_node(struct cc_workarea *ccwa)struct device_node *dn;const char *name = (const char *)ccwa +be32_to_cpu (ccwa->name_offset); - dn =kzalloc (sizeof (*dn) +strlen (name) +1 ,GFP_KERNEL ); + dn =kzalloc (sizeof (*dn),GFP_KERNEL );if (!dn)return NULL ; - dn->full_name = (char *)(dn +1 ); + dn->full_name =kzalloc (strlen (name) +1 ,GFP_KERNEL ); +if (!dn->full_name) { +kfree (dn); +return NULL ; + } +strcpy ((char *)dn->full_name, name);of_node_set_flag (dn,OF_DYNAMIC );
cheers
Rob Herring
maintainerRe: [PATCH v2 4/5] powerpc: pseries: only store the device node basename in full_name
Quoted 92 lines · Michael Ellerman
Hi Rob,
Unfortunately this one has a bug, which only showed up after some stress testing.
Quoted 43 lines · Rob Herring
With dependencies on
full_namecontaining the entire device node path removed, stop storing thefull_namein nodes created bydlpar_configure_connector()andpSeries_reconfig_add_node().Signed-off-by Rob Herring <[email protected]>Cc Benjamin Herrenschmidt <[email protected]>Cc Paul Mackerras <[email protected]>Cc Michael Ellerman <[email protected]>---
v2:
- Reworkdlpar_parse_cc_node()to a single allocation and strcpy instead of kasprintfarch/powerpc/platforms/pseries/dlpar.c | 30 +++++++----------------------- arch/powerpc/platforms/pseries/reconfig.c | 2 +- 2 files changed, 8 insertions(+), 24 deletions(-)arch/powerpc/platforms/pseries/dlpar.c +3
-10@@ -75,28 +75,17 @@ static struct property *dlpar_parse_cc_property(struct cc_workarea *ccwa)return prop; } -static struct device_node *dlpar_parse_cc_node (struct cc_workarea *ccwa, -const char *path) +static struct device_node *(dlpar_parse_cc_node)(struct cc_workarea *ccwa) {struct device_node *dn; -char *name; - -/* If parent node path is "/" advance path to NULL terminator to -* prevent double leading slashs in full_name. -*/ -if (!path[1 ]) - path++; +const char *name = (const char *)ccwa +be32_to_cpu (ccwa->name_offset); - dn =kzalloc (sizeof (*dn),GFP_KERNEL ); + dn =kzalloc (sizeof (*dn) +strlen (name) +1 ,GFP_KERNEL );if (!dn)arch/powerpc/platforms/pseries/dlpar.c static struct property *dlpar_parse_cc_property(struct cc_workarea *ccwa) · line 88
Quoted 10 lines
arch/powerpc/platforms/pseries/dlpar.c +2
-6return NULL ; - name = (char *)ccwa +be32_to_cpu (ccwa->name_offset); - dn->full_name =kasprintf (GFP_KERNEL ,"%s/%s" , path, name); -if (!dn->full_name) { -kfree (dn); -return NULL ; - } + dn->full_name = (char *)(dn +1 ); +strcpy ((char *)dn->full_name, name);Allocating the
full_nameon the tail of the struct this way breaks the call tokfree(node->full_name)inof_node_release().eg:
[ 322.543581] Freeing node->full_name c0000007f4ed4090 [ 322.543583] ============================================================================= [ 322.543586] BUG kmalloc-192 (Tainted: G B ): Invalid object pointer 0xc0000007f4ed4090 [ 322.543588] -----------------------------------------------------------------------------[ 322.543592] INFO: Slab 0xf000000001fd3b40 objects=292 used=72 fp=0xc0000007f4ed41a8 flags=0x13ffff800000101 [ 322.543595] CPU: 40 PID: 5 Comm: kworker/u192:0 Tainted: G B 4.14.0-rc2-gcc-6.3.1-next-20170929-dirty #429 [ 322.543600] Workqueue: pseries hotplug workque pseries_hp_work_fn [ 322.543602] Call Trace: [ 322.543605] [c0000003f769f660] [c000000000a6b710] dump_stack+0xb0/0xf0 (unreliable) [ 322.543609] [c0000003f769f6a0] [c00000000032cd5c] slab_err+0x9c/0xc0 [ 322.543612] [c0000003f769f790] [c00000000033440c] free_debug_processing+0x19c/0x490 [ 322.543615] [c0000003f769f860] [c0000000003349fc] __slab_free+0x2fc/0x4b0 [ 322.543619] [c0000003f769f960] [c0000000008f2484] of_node_release+0xe4/0x1a0 [ 322.543622] [c0000003f769fa00] [c000000000a71c04] kobject_put+0xd4/0x160 [ 322.543625] [c0000003f769fa80] [c0000000008f10c4] of_node_put+0x34/0x50 [ 322.543628] [c0000003f769fab0] [c0000000000c0248] dlpar_cpu_remove_by_index+0x108/0x130 [ 322.543631] [c0000003f769fb40] [c0000000000c166c] dlpar_cpu+0x27c/0x510 [ 322.543634] [c0000003f769fbf0] [c0000000000bb2d0] handle_dlpar_errorlog+0xc0/0x160 [ 322.543638] [c0000003f769fc60] [c0000000000bb3ac] pseries_hp_work_fn+0x3c/0xa0 [ 322.543641] [c0000003f769fc90] [c00000000012200c] process_one_work+0x2bc/0x560 [ 322.543645] [c0000003f769fd20] [c000000000122348] worker_thread+0x98/0x5d0 [ 322.543648] [c0000003f769fdc0] [c00000000012b4e4] kthread+0x164/0x1b0 [ 322.543651] [c0000003f769fe30] [c00000000000bae0] ret_from_kernel_thread+0x5c/0x7c
Quoted 1 line
The obvious fix is just to allocate it separately as before, eg ~=:
Yes, I'll go back to doing 2 allocs like v1, but using kstrdup as was also pointed out.
Rob
Michael Ellerman
reviewerRe: [PATCH v2 4/5] powerpc: pseries: only store the device node basename in full_name
Quoted 1 line · Rob Herring
On Tue, Oct 3, 2017 at 4:26 AM, Michael Ellerman <mpe-Gsx/[email protected]> wrote:
...
Quoted 5 lines
Quoted 2 lines
The obvious fix is just to allocate it separately as before, eg ~=:
Yes, I'll go back to doing 2 allocs like v1, but using kstrdup as was also pointed out.
Yeah that would be better still I guess.
cheers
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Rob Herring
maintainerPATCH v2 5/5 of/fdt: only store the device node basename in full_name
In reply to Rob HerringWith dependencies on a statically allocated full path name converted to use %pOF format specifier, we can store just the basename of node, and the unflattening of the FDT can be simplified.
This commit will affect the remaining users of full_name. After analyzing these users, the remaining cases should only change some print messages. The main users of full_name are providing a name for struct resource. The resource names shouldn't be important other than providing /proc/iomem names.
We no longer distinguish between pre and post 0x10 dtb formats as either a full path or basename will work. However, less than 0x10 formats have been broken since the conversion to use libfdt (and no one has cared). The conversion of the unflattening code to be non-recursive also broke pre 0x10 formats as the populate_node function would return 0 in that case.
---
v2:
- rebase to linux-next
drivers/of/fdt.c | 69 +++++++++----------------------------------------------- 1 file changed, 11 insertions(+), 58 deletions(-)
drivers/of/fdt.c +11 -58
@@ -266,74 +266,32 @@ static void populate_properties(const void *blob, *pprev =NULL ; } -static unsigned int populate_node (const void *blob, -int offset, -void **mem, -struct device_node *dad, -unsigned int fpsize, -struct device_node **pnp, -bool dryrun) +static bool populate_node (const void *blob, +int offset, +void **mem, +struct device_node *dad, +struct device_node **pnp, +bool dryrun) {struct device_node *np;const char *pathp;unsigned int l, allocl; -int new_format =0 ; pathp =fdt_get_name (blob, offset, &l);if (!pathp) { *pnp =NULL ; -return 0 ; +return false; } allocl = ++l; -/* version 0x10 has a more compact unit name here instead of the full -* path. we accumulate the full path size using "fpsize", we'll rebuild -* it later. We detect this because the first character of the name is -* not '/'. -*/ -if ((*pathp) !='/' ) { - new_format =1 ; -if (fpsize ==0 ) { -/* root node: special case. fpsize accounts for path -* plus terminating zero. root node only has '/', so -* fpsize should be 2, but we want to avoid the first -* level nodes to have two '/' so we use fpsize 1 here -*/ - fpsize =1 ; - allocl =2 ; - l =1 ; - pathp ="" ; - }else { -/* account for '/' and path size minus terminal 0 -* already in 'l' -*/ - fpsize += l; - allocl = fpsize; - } - } - np =unflatten_dt_alloc (mem,sizeof (struct device_node ) + allocl, __alignof__(struct device_node ));if (!dryrun) {char *fn;of_node_init (np); np->full_name = fn = ((char *)np) +sizeof (*np); -if (new_format) { -/* rebuild full path for new format */ -if (dad && dad->parent) { -strcpy (fn, dad->full_name); -#ifdef DEBUG -if ((strlen (fn) + l +1 ) != allocl) { -pr_debug ("%s: p: %d, l: %d, a: %d\n" , - pathp, (int )strlen (fn), - l, allocl); - } -#endif - fn +=strlen (fn); - } - *(fn++) ='/' ; - } +memcpy (fn, pathp, l);if (dad !=NULL ) {
@@ -355,7 +313,7 @@ static unsigned int populate_node(const void *blob, } *pnp = np; -return fpsize; +return true; }static void reverse_nodes (struct device_node *parent)
@@ -399,7 +357,6 @@ static int unflatten_dt_nodes(const void *blob,struct device_node *root;int offset =0 , depth =0 , initial_depth =0 ;#define FDT_MAX_DEPTH 64 -unsigned int fpsizes[FDT_MAX_DEPTH ];struct device_node *nps[FDT_MAX_DEPTH ];void *base = mem;bool dryrun = !base;
@@ -418,7 +375,6 @@ static int unflatten_dt_nodes(const void *blob, depth = initial_depth =1 ; root = dad; - fpsizes[depth] = dad ?strlen (of_node_full_name (dad)) :0 ; nps[depth] = dad; for (offset = 0;
@@ -427,11 +383,8 @@ static int unflatten_dt_nodes(const void *blob,if (WARN_ON_ONCE (depth >=FDT_MAX_DEPTH ))continue ; - fpsizes[depth+1 ] =populate_node (blob, offset, &mem, - nps[depth], - fpsizes[depth], - &nps[depth+1 ], dryrun); -if (!fpsizes[depth+1 ]) +if (!populate_node (blob, offset, &mem, nps[depth], + &nps[depth+1 ], dryrun))return mem - base;if (!dryrun && nodepp && !*nodepp)
Signature · 1 line
2.11.0
Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name
On Mon, Aug 21, 2017 at 10:16 AM, Rob Herring <[email protected]> wrote:
Hi Rob,
Quoted 17 lines
With dependencies on a statically allocated full path name converted to use %pOF format specifier, we can store just the basename of node, and the unflattening of the FDT can be simplified.
This commit will affect the remaining users of
full_name. After analyzing these users, the remaining cases should only change some print messages. The main users offull_nameare providing a name for struct resource. The resource names shouldn't be important other than providing/proc/iomemnames.We no longer distinguish between pre and post
0x10dtb formats as either a full path or basename will work. However, less than0x10formats have been broken since the conversion to use libfdt (and no one has cared). The conversion of the unflattening code to be non-recursive also broke pre0x10formats as thepopulate_nodefunction would return 0 in that case.
Quoted 7 lines
Signed-off-by Rob Herring <[email protected]>---
v2:
- rebase to linux-nextdrivers/of/fdt.c | 69 +++++++++----------------------------------------------- 1 file changed, 11 insertions(+), 58 deletions(-)
I've just updated to the latest next branch and am finding problems
applying overlays. Reverting this commit alleviates things. The
errors I get are:
[ 88.498704] OF: overlay: Failed to apply prop @/__symbols__/clk_0 [ 88.513447] OF: overlay: apply failed '/__symbols__' [ 88.518423] create_overlay: Failed to create overlay (err=-12)
My branch also includes Pantelis' patch that turns on symbols [1].
Alan
[1] https://github.com/pantoniou/linux-beagle-track-mainline/commit/486c87d450f2895a766c6097328d0c6538ec7a31
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Rob Herring
maintainerRe: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name
Quoted 29 lines · Alan Tull
On Mon, Aug 21, 2017 at 10:16 AM, Rob Herring <[email protected]> wrote:
Hi Rob,
Quoted 17 lines
With dependencies on a statically allocated full path name converted to use %pOF format specifier, we can store just the basename of node, and the unflattening of the FDT can be simplified.
This commit will affect the remaining users of
full_name. After analyzing these users, the remaining cases should only change some print messages. The main users offull_nameare providing a name for struct resource. The resource names shouldn't be important other than providing/proc/iomemnames.We no longer distinguish between pre and post
0x10dtb formats as either a full path or basename will work. However, less than0x10formats have been broken since the conversion to use libfdt (and no one has cared). The conversion of the unflattening code to be non-recursive also broke pre0x10formats as thepopulate_nodefunction would return 0 in that case.Quoted 7 lines
Signed-off-by Rob Herring <[email protected]>---
v2:
- rebase to linux-nextdrivers/of/fdt.c | 69 +++++++++----------------------------------------------- 1 file changed, 11 insertions(+), 58 deletions(-)
Quoted 7 lines
I've just updated to the latest next branch and am finding problems
applying overlays. Reverting this commit alleviates things. The
errors I get are:[ 88.498704] OF: overlay: Failed to apply prop @/__symbols__/clk_0 [ 88.513447] OF: overlay: apply failed '/__symbols__' [ 88.518423] create_overlay: Failed to create overlay (err=-12)
Frank's series with overlay updates should fix this.
Rob
Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name
Quoted 34 lines · Rob Herring
Quoted 33 lines · Alan Tull
On Mon, Aug 21, 2017 at 10:16 AM, Rob Herring <[email protected]> wrote:
Hi Rob,
Quoted 17 lines
With dependencies on a statically allocated full path name converted to use %pOF format specifier, we can store just the basename of node, and the unflattening of the FDT can be simplified.
This commit will affect the remaining users of
full_name. After analyzing these users, the remaining cases should only change some print messages. The main users offull_nameare providing a name for struct resource. The resource names shouldn't be important other than providing/proc/iomemnames.We no longer distinguish between pre and post
0x10dtb formats as either a full path or basename will work. However, less than0x10formats have been broken since the conversion to use libfdt (and no one has cared). The conversion of the unflattening code to be non-recursive also broke pre0x10formats as thepopulate_nodefunction would return 0 in that case.Quoted 7 lines
Signed-off-by Rob Herring <[email protected]>---
v2:
- rebase to linux-nextdrivers/of/fdt.c | 69 +++++++++----------------------------------------------- 1 file changed, 11 insertions(+), 58 deletions(-)I've just updated to the latest next branch and am finding problems
applying overlays. Reverting this commit alleviates things. The
errors I get are:
Quoted 5 lines
Quoted 3 lines
[ 88.498704] OF: overlay: Failed to apply prop @/__symbols__/clk_0 [ 88.513447] OF: overlay: apply failed '/__symbols__' [ 88.518423] create_overlay: Failed to create overlay (err=-12)Frank's series with overlay updates should fix this.
Yes, it does:
[PATCH v3 11/12] of: overlay: remove a dependency on device node full_name
-Frank
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name
Quoted 39 lines · Frank Rowand
Quoted 38 lines · Rob Herring
Quoted 36 lines · Alan Tull
On Mon, Aug 21, 2017 at 10:16 AM, Rob Herring <[email protected]> wrote:
Hi Rob,
Quoted 17 lines
With dependencies on a statically allocated full path name converted to use %pOF format specifier, we can store just the basename of node, and the unflattening of the FDT can be simplified.
This commit will affect the remaining users of
full_name. After analyzing these users, the remaining cases should only change some print messages. The main users offull_nameare providing a name for struct resource. The resource names shouldn't be important other than providing/proc/iomemnames.We no longer distinguish between pre and post
0x10dtb formats as either a full path or basename will work. However, less than0x10formats have been broken since the conversion to use libfdt (and no one has cared). The conversion of the unflattening code to be non-recursive also broke pre0x10formats as thepopulate_nodefunction would return 0 in that case.Quoted 7 lines
Signed-off-by Rob Herring <[email protected]>---
v2:
- rebase to linux-nextdrivers/of/fdt.c | 69 +++++++++----------------------------------------------- 1 file changed, 11 insertions(+), 58 deletions(-)I've just updated to the latest next branch and am finding problems
applying overlays. Reverting this commit alleviates things. The
errors I get are:[ 88.498704] OF: overlay: Failed to apply prop @/__symbols__/clk_0 [ 88.513447] OF: overlay: apply failed '/__symbols__' [ 88.518423] create_overlay: Failed to create overlay (err=-12)
Quoted 5 lines
Quoted 1 line
Frank's series with overlay updates should fix this.
Yes, it does:
[PATCH v3 11/12] of: overlay: remove a dependency on device node
full_name
Thanks for the fast response. I fetched the dt/next branch to test this but there are sufficient changes that Pantelis' "OF: DT-Overlay configfs interface (v7)" is broken now. I've been adding that downstream since 4.4. We're using it as an interface for applying overlays to program FPGAs. If we fix it again, is there any chance that can go upstream now?
Alan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Rob Herring
maintainerRe: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name
Quoted 44 lines · Alan Tull
Quoted 43 lines · Frank Rowand
Quoted 34 lines · Rob Herring
Quoted 33 lines · Alan Tull
On Mon, Aug 21, 2017 at 10:16 AM, Rob Herring <[email protected]> wrote:
Hi Rob,
Quoted 17 lines
With dependencies on a statically allocated full path name converted to use %pOF format specifier, we can store just the basename of node, and the unflattening of the FDT can be simplified.
This commit will affect the remaining users of
full_name. After analyzing these users, the remaining cases should only change some print messages. The main users offull_nameare providing a name for struct resource. The resource names shouldn't be important other than providing/proc/iomemnames.We no longer distinguish between pre and post
0x10dtb formats as either a full path or basename will work. However, less than0x10formats have been broken since the conversion to use libfdt (and no one has cared). The conversion of the unflattening code to be non-recursive also broke pre0x10formats as thepopulate_nodefunction would return 0 in that case.Quoted 7 lines
Signed-off-by Rob Herring <[email protected]>---
v2:
- rebase to linux-nextdrivers/of/fdt.c | 69 +++++++++----------------------------------------------- 1 file changed, 11 insertions(+), 58 deletions(-)I've just updated to the latest next branch and am finding problems
applying overlays. Reverting this commit alleviates things. The
errors I get are:Quoted 5 lines
Quoted 3 lines
[ 88.498704] OF: overlay: Failed to apply prop @/__symbols__/clk_0 [ 88.513447] OF: overlay: apply failed '/__symbols__' [ 88.518423] create_overlay: Failed to create overlay (err=-12)Frank's series with overlay updates should fix this.
Yes, it does:
Quoted 8 lines
Quoted 1 line
[PATCH v3 11/12] of: overlay: remove a dependency on device node
full_nameThanks for the fast response. I fetched the dt/next branch to test this but there are sufficient changes that Pantelis' "OF: DT-Overlay configfs interface (v7)" is broken now. I've been adding that downstream since 4.4. We're using it as an interface for applying overlays to program FPGAs. If we fix it again, is there any chance that can go upstream now?
With a drive-by posting once every few years, no.
The issue remains that the kernel is not really setup to deal with any random property or node to be changed at any point in run-time. I think there needs to be some restrictions around what the overlays can touch. We can't have it be wide open and then lock things down later and break users. One example of what you could do is you can only add sub-trees to whitelisted nodes. That's probably acceptable for your usecase.
Rob
Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name
Quoted 47 lines · Rob Herring
Quoted 46 lines · Alan Tull
Quoted 44 lines · Frank Rowand
Quoted 34 lines · Rob Herring
Quoted 33 lines · Alan Tull
On Mon, Aug 21, 2017 at 10:16 AM, Rob Herring <[email protected]> wrote:
Hi Rob,
Quoted 17 lines
With dependencies on a statically allocated full path name converted to use %pOF format specifier, we can store just the basename of node, and the unflattening of the FDT can be simplified.
This commit will affect the remaining users of
full_name. After analyzing these users, the remaining cases should only change some print messages. The main users offull_nameare providing a name for struct resource. The resource names shouldn't be important other than providing/proc/iomemnames.We no longer distinguish between pre and post
0x10dtb formats as either a full path or basename will work. However, less than0x10formats have been broken since the conversion to use libfdt (and no one has cared). The conversion of the unflattening code to be non-recursive also broke pre0x10formats as thepopulate_nodefunction would return 0 in that case.Quoted 7 lines
Signed-off-by Rob Herring <[email protected]>---
v2:
- rebase to linux-nextdrivers/of/fdt.c | 69 +++++++++----------------------------------------------- 1 file changed, 11 insertions(+), 58 deletions(-)I've just updated to the latest next branch and am finding problems
applying overlays. Reverting this commit alleviates things. The
errors I get are:Quoted 5 lines
Quoted 3 lines
[ 88.498704] OF: overlay: Failed to apply prop @/__symbols__/clk_0 [ 88.513447] OF: overlay: apply failed '/__symbols__' [ 88.518423] create_overlay: Failed to create overlay (err=-12)Frank's series with overlay updates should fix this.
Yes, it does:
[PATCH v3 11/12] of: overlay: remove a dependency on device node
full_name
Quoted 9 lines
Quoted 6 lines
Thanks for the fast response. I fetched the dt/next branch to test this but there are sufficient changes that Pantelis' "OF: DT-Overlay configfs interface (v7)" is broken now. I've been adding that downstream since 4.4. We're using it as an interface for applying overlays to program FPGAs. If we fix it again, is there any chance that can go upstream now?
With a drive-by posting once every few years, no.
I take offense to that. There's nothing changed in the patch for years. Reposting the same patch without changes would achieve nothing.
Quoted 8 lines
The issue remains that the kernel is not really setup to deal with any random property or node to be changed at any point in run-time. I think there needs to be some restrictions around what the overlays can touch. We can't have it be wide open and then lock things down later and break users. One example of what you could do is you can only add sub-trees to whitelisted nodes. That's probably acceptable for your usecase.
Defining what can and what cannot be changed is not as trivial as a list of white-listed nodes.
In some cases there is a whole node hierarchy being inserted (like in a FPGA). In others, it's merely changing a status property to "okay" and a few device parameters.
The real issue is that the kernel has no way to verify that a given device tree, either at boot time or at overlay application time, is correct.
When the tree is wrong at boot-time you'll hang (if you're lucky). If the tree is wrong at run-time you'll get some into some unidentified funky state.
Finally what is, and what is not 'correct' is not for the kernel to decide arbitrarily, it's a matter of policy, different for each use-case.
Quoted 1 line
Rob
Regards
-- Pantelis
Rob Herring
maintainerRe: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name
Quoted 55 lines · Pantelis Antoniou
Quoted 54 lines · Rob Herring
Quoted 52 lines · Alan Tull
Quoted 39 lines · Frank Rowand
Quoted 38 lines · Rob Herring
Quoted 36 lines · Alan Tull
On Mon, Aug 21, 2017 at 10:16 AM, Rob Herring <[email protected]> wrote:
Hi Rob,
Quoted 17 lines
With dependencies on a statically allocated full path name converted to use %pOF format specifier, we can store just the basename of node, and the unflattening of the FDT can be simplified.
This commit will affect the remaining users of
full_name. After analyzing these users, the remaining cases should only change some print messages. The main users offull_nameare providing a name for struct resource. The resource names shouldn't be important other than providing/proc/iomemnames.We no longer distinguish between pre and post
0x10dtb formats as either a full path or basename will work. However, less than0x10formats have been broken since the conversion to use libfdt (and no one has cared). The conversion of the unflattening code to be non-recursive also broke pre0x10formats as thepopulate_nodefunction would return 0 in that case.Quoted 7 lines
Signed-off-by Rob Herring <[email protected]>---
v2:
- rebase to linux-nextdrivers/of/fdt.c | 69 +++++++++----------------------------------------------- 1 file changed, 11 insertions(+), 58 deletions(-)I've just updated to the latest next branch and am finding problems
applying overlays. Reverting this commit alleviates things. The
errors I get are:[ 88.498704] OF: overlay: Failed to apply prop @/__symbols__/clk_0 [ 88.513447] OF: overlay: apply failed '/__symbols__' [ 88.518423] create_overlay: Failed to create overlay (err=-12)Quoted 5 lines
Quoted 1 line
Frank's series with overlay updates should fix this.
Yes, it does:
[PATCH v3 11/12] of: overlay: remove a dependency on device node
full_nameThanks for the fast response. I fetched the dt/next branch to test this but there are sufficient changes that Pantelis' "OF: DT-Overlay configfs interface (v7)" is broken now. I've been adding that downstream since 4.4. We're using it as an interface for applying overlays to program FPGAs. If we fix it again, is there any chance that can go upstream now?
Quoted 5 lines
Quoted 2 lines
With a drive-by posting once every few years, no.
I take offense to that. There's nothing changed in the patch for years. Reposting the same patch without changes would achieve nothing.
Are you still expecting review comments on it or something? Furthermore, If something is posted infrequently, then I'm not inclined to comment or care if the next posting is going to be after I forget what I previously said (which is not very long).
I'm just saying, don't expect to forward port, post and it will be accepted. Below is minimally one of the issues that needs to be addressed.
Quoted 11 lines
Quoted 8 lines
The issue remains that the kernel is not really setup to deal with any random property or node to be changed at any point in run-time. I think there needs to be some restrictions around what the overlays can touch. We can't have it be wide open and then lock things down later and break users. One example of what you could do is you can only add sub-trees to whitelisted nodes. That's probably acceptable for your usecase.
Defining what can and what cannot be changed is not as trivial as a list of white-listed nodes.
No, but we have to start somewhere and we are not starting with any change allowed anywhere at anytime. If that is what people want, then they are going to get to maintain that out of tree.
Quoted 2 lines
In some cases there is a whole node hierarchy being inserted (like in a FPGA).
Yes, so you'd have a target fpga region. That sounds fine to me. Maybe its not a static whitelist, but drivers have to register target nodes/paths.
Quoted 2 lines
In others, it's merely changing a status property to "okay" and a few device parameters.
That seems fine too. Disabled nodes could be allowed. But what if you add/change properties on a node that is not disabled? Once a node is enabled, who is responsible for registering the device?
What about changing a node from enabled to disabled? The kernel would need to handle that or not allow it.
Quoted 7 lines
The real issue is that the kernel has no way to verify that a given device tree, either at boot time or at overlay application time, is correct.
When the tree is wrong at boot-time you'll hang (if you're lucky). If the tree is wrong at run-time you'll get some into some unidentified funky state.
Or have some security hole or a mechanism for userspace to crash the system.
Quoted 3 lines
Finally what is, and what is not 'correct' is not for the kernel to decide arbitrarily, it's a matter of policy, different for each use-case.
It is if the kernel will break doing so.
Rob
Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name
Quoted 63 lines · Rob Herring
Quoted 55 lines · Pantelis Antoniou
Quoted 54 lines · Rob Herring
Quoted 52 lines · Alan Tull
Quoted 39 lines · Frank Rowand
Quoted 38 lines · Rob Herring
Quoted 36 lines · Alan Tull
On Mon, Aug 21, 2017 at 10:16 AM, Rob Herring <[email protected]> wrote:
Hi Rob,
Quoted 17 lines
With dependencies on a statically allocated full path name converted to use %pOF format specifier, we can store just the basename of node, and the unflattening of the FDT can be simplified.
This commit will affect the remaining users of
full_name. After analyzing these users, the remaining cases should only change some print messages. The main users offull_nameare providing a name for struct resource. The resource names shouldn't be important other than providing/proc/iomemnames.We no longer distinguish between pre and post
0x10dtb formats as either a full path or basename will work. However, less than0x10formats have been broken since the conversion to use libfdt (and no one has cared). The conversion of the unflattening code to be non-recursive also broke pre0x10formats as thepopulate_nodefunction would return 0 in that case.Quoted 7 lines
Signed-off-by Rob Herring <[email protected]>---
v2:
- rebase to linux-nextdrivers/of/fdt.c | 69 +++++++++----------------------------------------------- 1 file changed, 11 insertions(+), 58 deletions(-)I've just updated to the latest next branch and am finding problems
applying overlays. Reverting this commit alleviates things. The
errors I get are:[ 88.498704] OF: overlay: Failed to apply prop @/__symbols__/clk_0 [ 88.513447] OF: overlay: apply failed '/__symbols__' [ 88.518423] create_overlay: Failed to create overlay (err=-12)Quoted 5 lines
Quoted 1 line
Frank's series with overlay updates should fix this.
Yes, it does:
[PATCH v3 11/12] of: overlay: remove a dependency on device node
full_nameThanks for the fast response. I fetched the dt/next branch to test this but there are sufficient changes that Pantelis' "OF: DT-Overlay configfs interface (v7)" is broken now. I've been adding that downstream since 4.4. We're using it as an interface for applying overlays to program FPGAs. If we fix it again, is there any chance that can go upstream now?
Quoted 5 lines
Quoted 2 lines
With a drive-by posting once every few years, no.
I take offense to that. There's nothing changed in the patch for years. Reposting the same patch without changes would achieve nothing.
Quoted 16 lines
Are you still expecting review comments on it or something? Furthermore, If something is posted infrequently, then I'm not inclined to comment or care if the next posting is going to be after I forget what I previously said (which is not very long).
I'm just saying, don't expect to forward port, post and it will be accepted. Below is minimally one of the issues that needs to be addressed.
Quoted 5 lines
Quoted 5 lines
The issue remains that the kernel is not really setup to deal with any random property or node to be changed at any point in run-time. I think there needs to be some restrictions around what the overlays can touch. We can't have it be wide open and then lock things down later and break users.
That paragraph is key to any discussion of accepting code to apply overlays. Solving that issue has been stated to be a gating factor for such code from the beginning of overlay development.
Quoted 47 lines
Quoted 7 lines
Quoted 4 lines
One example of what you could do is you can only add sub-trees to whitelisted nodes. That's probably acceptable for your usecase.
Defining what can and what cannot be changed is not as trivial as a list of white-listed nodes.
No, but we have to start somewhere and we are not starting with any change allowed anywhere at anytime. If that is what people want, then they are going to get to maintain that out of tree.
Quoted 2 lines
In some cases there is a whole node hierarchy being inserted (like in a FPGA).
Yes, so you'd have a target fpga region. That sounds fine to me. Maybe its not a static whitelist, but drivers have to register target nodes/paths.
Quoted 2 lines
In others, it's merely changing a status property to "okay" and a few device parameters.
That seems fine too. Disabled nodes could be allowed. But what if you add/change properties on a node that is not disabled? Once a node is enabled, who is responsible for registering the device?
What about changing a node from enabled to disabled? The kernel would need to handle that or not allow it.
Quoted 7 lines
The real issue is that the kernel has no way to verify that a given device tree, either at boot time or at overlay application time, is correct.
When the tree is wrong at boot-time you'll hang (if you're lucky). If the tree is wrong at run-time you'll get some into some unidentified funky state.
Or have some security hole or a mechanism for userspace to crash the system.
Quoted 3 lines
Finally what is, and what is not 'correct' is not for the kernel to decide arbitrarily, it's a matter of policy, different for each use-case.
It is if the kernel will break doing so.
Rob
Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name
Hi Frank,
Quoted 83 lines · Frank Rowand
Quoted 63 lines · Rob Herring
Quoted 55 lines · Pantelis Antoniou
Quoted 54 lines · Rob Herring
Quoted 52 lines · Alan Tull
Quoted 39 lines · Frank Rowand
Quoted 38 lines · Rob Herring
Quoted 36 lines · Alan Tull
On Mon, Aug 21, 2017 at 10:16 AM, Rob Herring <[email protected]> wrote:
Hi Rob,
Quoted 17 lines
With dependencies on a statically allocated full path name converted to use %pOF format specifier, we can store just the basename of node, and the unflattening of the FDT can be simplified.
This commit will affect the remaining users of
full_name. After analyzing these users, the remaining cases should only change some print messages. The main users offull_nameare providing a name for struct resource. The resource names shouldn't be important other than providing/proc/iomemnames.We no longer distinguish between pre and post
0x10dtb formats as either a full path or basename will work. However, less than0x10formats have been broken since the conversion to use libfdt (and no one has cared). The conversion of the unflattening code to be non-recursive also broke pre0x10formats as thepopulate_nodefunction would return 0 in that case.Quoted 7 lines
Signed-off-by Rob Herring <[email protected]>---
v2:
- rebase to linux-next
drivers/of/fdt.c| 69 +++++++++-----------------------------------------------1 file changed, 11 insertions(+), 58 deletions(-)I've just updated to the latest next branch and am finding problems
applying overlays. Reverting this commit alleviates things. The
errors I get are:[ 88.498704] OF: overlay: Failed to apply prop @/__symbols__/clk_0 [ 88.513447] OF: overlay: apply failed '/__symbols__' [ 88.518423] create_overlay: Failed to create overlay (err=-12)Quoted 5 lines
Quoted 1 line
Frank's series with overlay updates should fix this.
Yes, it does:
[PATCH v3 11/12] of: overlay: remove a dependency on device node
full_nameThanks for the fast response. I fetched the dt/next branch to test this but there are sufficient changes that Pantelis' "OF: DT-Overlay configfs interface (v7)" is broken now. I've been adding that downstream since 4.4. We're using it as an interface for applying overlays to program FPGAs. If we fix it again, is there any chance that can go upstream now?
Quoted 5 lines
Quoted 2 lines
With a drive-by posting once every few years, no.
I take offense to that. There's nothing changed in the patch for years. Reposting the same patch without changes would achieve nothing.
Quoted 16 lines
Are you still expecting review comments on it or something? Furthermore, If something is posted infrequently, then I'm not inclined to comment or care if the next posting is going to be after I forget what I previously said (which is not very long).
I'm just saying, don't expect to forward port, post and it will be accepted. Below is minimally one of the issues that needs to be addressed.
Quoted 5 lines
Quoted 5 lines
The issue remains that the kernel is not really setup to deal with any random property or node to be changed at any point in run-time. I think there needs to be some restrictions around what the overlays can touch. We can't have it be wide open and then lock things down later and break users.
Quoted 4 lines
That paragraph is key to any discussion of accepting code to apply overlays. Solving that issue has been stated to be a gating factor for such code from the beginning of overlay development.
Overlays are not only used only for cases where you have external expansion boards, or FPGAs where every change is contained under a few designated nodes, so that’s why I’m pushing for a in-kernel validator that’s more flexible than a single whitelist.
An eBPF validator would handle a whitelist trivially easy, and would be flexible enough for any other more complicated use case.
Quoted 40 lines
Quoted 40 lines
Quoted 8 lines
Quoted 5 lines
One example of what you could do is you can only add sub-trees to whitelisted nodes. That's probably acceptable for your usecase.
Defining what can and what cannot be changed is not as trivial as a list of white-listed nodes.
No, but we have to start somewhere and we are not starting with any change allowed anywhere at anytime. If that is what people want, then they are going to get to maintain that out of tree.
Quoted 2 lines
In some cases there is a whole node hierarchy being inserted (like in a FPGA).
Yes, so you'd have a target fpga region. That sounds fine to me. Maybe its not a static whitelist, but drivers have to register target nodes/paths.
Quoted 2 lines
In others, it's merely changing a status property to "okay" and a few device parameters.
That seems fine too. Disabled nodes could be allowed. But what if you add/change properties on a node that is not disabled? Once a node is enabled, who is responsible for registering the device?
What about changing a node from enabled to disabled? The kernel would need to handle that or not allow it.
Quoted 7 lines
The real issue is that the kernel has no way to verify that a given device tree, either at boot time or at overlay application time, is correct.
When the tree is wrong at boot-time you'll hang (if you're lucky). If the tree is wrong at run-time you'll get some into some unidentified funky state.
Or have some security hole or a mechanism for userspace to crash the system.
Quoted 9 lines
Quoted 8 lines
Quoted 3 lines
Finally what is, and what is not 'correct' is not for the kernel to decide arbitrarily, it's a matter of policy, different for each use-case.
It is if the kernel will break doing so.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name
In reply to Rob HerringHi Rob,
Quoted 83 lines · Rob Herring
Quoted 55 lines · Pantelis Antoniou
Quoted 54 lines · Rob Herring
Quoted 52 lines · Alan Tull
Quoted 39 lines · Frank Rowand
Quoted 38 lines · Rob Herring
Quoted 36 lines · Alan Tull
On Mon, Aug 21, 2017 at 10:16 AM, Rob Herring <[email protected]> wrote:
Hi Rob,
Quoted 17 lines
With dependencies on a statically allocated full path name converted to use %pOF format specifier, we can store just the basename of node, and the unflattening of the FDT can be simplified.
This commit will affect the remaining users of
full_name. After analyzing these users, the remaining cases should only change some print messages. The main users offull_nameare providing a name for struct resource. The resource names shouldn't be important other than providing/proc/iomemnames.We no longer distinguish between pre and post
0x10dtb formats as either a full path or basename will work. However, less than0x10formats have been broken since the conversion to use libfdt (and no one has cared). The conversion of the unflattening code to be non-recursive also broke pre0x10formats as thepopulate_nodefunction would return 0 in that case.Quoted 7 lines
Signed-off-by Rob Herring <[email protected]>---
v2:
- rebase to linux-next
drivers/of/fdt.c| 69 +++++++++-----------------------------------------------1 file changed, 11 insertions(+), 58 deletions(-)I've just updated to the latest next branch and am finding problems
applying overlays. Reverting this commit alleviates things. The
errors I get are:[ 88.498704] OF: overlay: Failed to apply prop @/__symbols__/clk_0 [ 88.513447] OF: overlay: apply failed '/__symbols__' [ 88.518423] create_overlay: Failed to create overlay (err=-12)Quoted 5 lines
Quoted 1 line
Frank's series with overlay updates should fix this.
Yes, it does:
[PATCH v3 11/12] of: overlay: remove a dependency on device node
full_nameThanks for the fast response. I fetched the dt/next branch to test this but there are sufficient changes that Pantelis' "OF: DT-Overlay configfs interface (v7)" is broken now. I've been adding that downstream since 4.4. We're using it as an interface for applying overlays to program FPGAs. If we fix it again, is there any chance that can go upstream now?
Quoted 5 lines
Quoted 2 lines
With a drive-by posting once every few years, no.
I take offense to that. There's nothing changed in the patch for years. Reposting the same patch without changes would achieve nothing.
Are you still expecting review comments on it or something? Furthermore, If something is posted infrequently, then I'm not inclined to comment or care if the next posting is going to be after I forget what I previously said (which is not very long).
I'm just saying, don't expect to forward port, post and it will be accepted. Below is minimally one of the issues that needs to be addressed.
Quoted 9 lines
Quoted 8 lines
The issue remains that the kernel is not really setup to deal with any random property or node to be changed at any point in run-time. I think there needs to be some restrictions around what the overlays can touch. We can't have it be wide open and then lock things down later and break users. One example of what you could do is you can only add sub-trees to whitelisted nodes. That's probably acceptable for your usecase.
Quoted 7 lines
Quoted 2 lines
Defining what can and what cannot be changed is not as trivial as a list of white-listed nodes.
No, but we have to start somewhere and we are not starting with any change allowed anywhere at anytime. If that is what people want, then they are going to get to maintain that out of tree.
I am still not sold on this ‘dangerous’ idea. No-one is crazy enough to suggest overlays to be loadable by an unprivileged user. It’s exactly the same ‘danger’ as loading a kernel module, while is sure capable of much greater mischief.
Quoted 10 lines
Quoted 2 lines
In some cases there is a whole node hierarchy being inserted (like in a FPGA).
Yes, so you'd have a target fpga region. That sounds fine to me. Maybe its not a static whitelist, but drivers have to register target nodes/paths.
Quoted 2 lines
In others, it's merely changing a status property to "okay" and a few device parameters.
Quoted 7 lines
That seems fine too. Disabled nodes could be allowed. But what if you add/change properties on a node that is not disabled? Once a node is enabled, who is responsible for registering the device?
What about changing a node from enabled to disabled? The kernel would need to handle that or not allow it.
So it seems a simple whitelist won’t cut it. We’re already talking about special casing for this or that property.
My argument is that this kind of validation is not part of the core-device tree, but instead is a policy decision different for each board.
Quoted 10 lines
Quoted 7 lines
The real issue is that the kernel has no way to verify that a given device tree, either at boot time or at overlay application time, is correct.
When the tree is wrong at boot-time you'll hang (if you're lucky). If the tree is wrong at run-time you'll get some into some unidentified funky state.
Or have some security hole or a mechanism for userspace to crash the system.
User-space as in regular users should never have enough privileges to apply an overlay, same as in loading a kernel module.
Quoted 6 lines
Quoted 3 lines
Finally what is, and what is not 'correct' is not for the kernel to decide arbitrarily, it's a matter of policy, different for each use-case.
It is if the kernel will break doing so.
I still haven’t seen a real example of the kernel breaking.
I have seen a lot of cases where the kernel is crashing due to the device removal path being broken, but those are kernel bugs to fix, not something to use to hold back functionality that people want to use.
Quoted 1 line
Rob
Regards
— Pantelis
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Moritz Fischer
maintainerRe: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name
Quoted 93 lines · Pantelis Antoniou
Hi Rob,
Quoted 83 lines · Rob Herring
Quoted 55 lines · Pantelis Antoniou
Quoted 54 lines · Rob Herring
Quoted 52 lines · Alan Tull
Quoted 39 lines · Frank Rowand
Quoted 38 lines · Rob Herring
Quoted 36 lines · Alan Tull
On Mon, Aug 21, 2017 at 10:16 AM, Rob Herring <[email protected]> wrote:
Hi Rob,
Quoted 17 lines
With dependencies on a statically allocated full path name converted to use %pOF format specifier, we can store just the basename of node, and the unflattening of the FDT can be simplified.
This commit will affect the remaining users of
full_name. After analyzing these users, the remaining cases should only change some print messages. The main users offull_nameare providing a name for struct resource. The resource names shouldn't be important other than providing/proc/iomemnames.We no longer distinguish between pre and post
0x10dtb formats as either a full path or basename will work. However, less than0x10formats have been broken since the conversion to use libfdt (and no one has cared). The conversion of the unflattening code to be non-recursive also broke pre0x10formats as thepopulate_nodefunction would return 0 in that case.Quoted 7 lines
Signed-off-by Rob Herring <[email protected]>---
v2:
- rebase to linux-next
drivers/of/fdt.c| 69 +++++++++-----------------------------------------------1 file changed, 11 insertions(+), 58 deletions(-)I've just updated to the latest next branch and am finding problems
applying overlays. Reverting this commit alleviates things. The
errors I get are:[ 88.498704] OF: overlay: Failed to apply prop @/__symbols__/clk_0 [ 88.513447] OF: overlay: apply failed '/__symbols__' [ 88.518423] create_overlay: Failed to create overlay (err=-12)Quoted 5 lines
Quoted 1 line
Frank's series with overlay updates should fix this.
Yes, it does:
[PATCH v3 11/12] of: overlay: remove a dependency on device node
full_nameThanks for the fast response. I fetched the dt/next branch to test this but there are sufficient changes that Pantelis' "OF: DT-Overlay configfs interface (v7)" is broken now. I've been adding that downstream since 4.4. We're using it as an interface for applying overlays to program FPGAs. If we fix it again, is there any chance that can go upstream now?
Quoted 5 lines
Quoted 2 lines
With a drive-by posting once every few years, no.
I take offense to that. There's nothing changed in the patch for years. Reposting the same patch without changes would achieve nothing.
Are you still expecting review comments on it or something? Furthermore, If something is posted infrequently, then I'm not inclined to comment or care if the next posting is going to be after I forget what I previously said (which is not very long).
I'm just saying, don't expect to forward port, post and it will be accepted. Below is minimally one of the issues that needs to be addressed.
Quoted 9 lines
Quoted 8 lines
The issue remains that the kernel is not really setup to deal with any random property or node to be changed at any point in run-time. I think there needs to be some restrictions around what the overlays can touch. We can't have it be wide open and then lock things down later and break users. One example of what you could do is you can only add sub-trees to whitelisted nodes. That's probably acceptable for your usecase.
Quoted 7 lines
Quoted 2 lines
Defining what can and what cannot be changed is not as trivial as a list of white-listed nodes.
No, but we have to start somewhere and we are not starting with any change allowed anywhere at anytime. If that is what people want, then they are going to get to maintain that out of tree.
Quoted 4 lines
I am still not sold on this ‘dangerous’ idea. No-one is crazy enough to suggest overlays to be loadable by an unprivileged user. It’s exactly the same ‘danger’ as loading a kernel module, while is sure capable of much greater mischief.
Agreed.
Quoted 43 lines
Quoted 11 lines
Quoted 3 lines
In some cases there is a whole node hierarchy being inserted (like in a FPGA).
Yes, so you'd have a target fpga region. That sounds fine to me. Maybe its not a static whitelist, but drivers have to register target nodes/paths.
Quoted 2 lines
In others, it's merely changing a status property to "okay" and a few device parameters.
Quoted 7 lines
That seems fine too. Disabled nodes could be allowed. But what if you add/change properties on a node that is not disabled? Once a node is enabled, who is responsible for registering the device?
What about changing a node from enabled to disabled? The kernel would need to handle that or not allow it.
So it seems a simple whitelist won’t cut it. We’re already talking about special casing for this or that property.
My argument is that this kind of validation is not part of the core-device tree, but instead is a policy decision different for each board.
Quoted 10 lines
Quoted 7 lines
The real issue is that the kernel has no way to verify that a given device tree, either at boot time or at overlay application time, is correct.
When the tree is wrong at boot-time you'll hang (if you're lucky). If the tree is wrong at run-time you'll get some into some unidentified funky state.
Or have some security hole or a mechanism for userspace to crash the system.
User-space as in regular users should never have enough privileges to apply an overlay, same as in loading a kernel module.
Quoted 4 lines
Quoted 3 lines
Finally what is, and what is not 'correct' is not for the kernel to decide arbitrarily, it's a matter of policy, different for each use-case.
Quoted 8 lines
Quoted 2 lines
It is if the kernel will break doing so.
I still haven’t seen a real example of the kernel breaking.
I have seen a lot of cases where the kernel is crashing due to the device removal path being broken, but those are kernel bugs to fix, not something to use to hold back functionality that people want to use.
We also have plenty of code that is just not aware of overlays, and assumes certain parts of the tree to stay static.
I ran into that issue when I tried to add thermal zones via an overlay, I've been investigating how to fix the thermal framework to work with overlays since then and have some partially working code. Currently the thermal framework parses the thermal-zones node at boot, and assumes this stays static. This breaks with overlays.
I agree we eventually need to fix the parts that break when we use overlays.
Quoted 11 lines
Quoted 2 lines
Rob
Regards
— Pantelis
--
To unsubscribe from this list: send the line "unsubscribe linux-fpga" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Cheers,
Moritz
Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name
On 10/19/17 13:06, Moritz Fischer wrote:
< snip >
Quoted 2 lines
We also have plenty of code that is just not aware of overlays, and assumes certain parts of the tree to stay static.
I would state that somewhat differently. :-) There is very little code that is aware of overlays, and most code assumes the device tree does not change after early boot.
This is one of the areas where the creation of overlays needs to be done with care.
Quoted 8 lines
I ran into that issue when I tried to add thermal zones via an overlay, I've been investigating how to fix the thermal framework to work with overlays since then and have some partially working code. Currently the thermal framework parses the thermal-zones node at boot, and assumes this stays static. This breaks with overlays.
I agree we eventually need to fix the parts that break when we use overlays.
Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name
Hi Frank,
Quoted 9 lines · Frank Rowand
On 10/19/17 13:06, Moritz Fischer wrote:
< snip >
Quoted 2 lines
We also have plenty of code that is just not aware of overlays, and assumes certain parts of the tree to stay static.
Quoted 7 lines
I would state that somewhat differently. :-) There is very little code that is aware of overlays, and most code assumes the device tree does not change after early boot.
This is one of the areas where the creation of overlays needs to be done with care.
Correct. But this is not breaking the kernel.
In general we have the following case where we load overlays (at least well formed overlays that are not doing stupid things).
1. Activation of a new device. Usually this works since is something that’s normally done at boot.
2. Deactivation of a device. This might break because the removal paths of platform device especially are not well tested (or never executed for that matter).
3. Modification of properties in an already activated device. If the device driver has not installed a device tree modification hook (as in almost 99% of the devices) it will do absolutely nothing, since the device tree is parsed only at probe time. I can argue that for these cases we could have a catch-all hook that displays a message that nothing happened.
4. Modification of some part of the tree that’s not part of a device driver, perhaps the aliases or chosen node. This may potentially be harmful or harmless depending on what has been modified. For instance modifying an already existing alias might cause internal inconsistency about device naming, while adding a new aliases should be harmless. This is a matter of policy per board, whether to allow or not.
Are there other cases that are potentially more harmful?
Quoted 10 lines
Quoted 9 lines
I ran into that issue when I tried to add thermal zones via an overlay, I've been investigating how to fix the thermal framework to work with overlays since then and have some partially working code. Currently the thermal framework parses the thermal-zones node at boot, and assumes this stays static. This breaks with overlays.
I agree we eventually need to fix the parts that break when we use overlays.
Regards
— Pantelis
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Rob Herring
maintainerRe: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name
Quoted 19 lines · Pantelis Antoniou
Hi Frank,
Quoted 9 lines · Frank Rowand
On 10/19/17 13:06, Moritz Fischer wrote:
< snip >
Quoted 2 lines
We also have plenty of code that is just not aware of overlays, and assumes certain parts of the tree to stay static.
Quoted 7 lines
I would state that somewhat differently. :-) There is very little code that is aware of overlays, and most code assumes the device tree does not change after early boot.
This is one of the areas where the creation of overlays needs to be done with care.
Quoted 7 lines
Correct. But this is not breaking the kernel.
In general we have the following case where we load overlays (at least well formed overlays that are not doing stupid things).
1. Activation of a new device. Usually this works since is something that’s normally done at boot.
Depends where in the tree it is.
Quoted 3 lines
2. Deactivation of a device. This might break because the removal paths of platform device especially are not well tested (or never executed for that matter).
It's more than just the removal path of a driver. What if you try to remove a node that's a dependency of others. Generally, hot unplug of GPIOs, clocks, interrupt controllers, etc. don't work.
Plus we already have a way to disable devices. Unbind the driver.
Quoted 5 lines
3. Modification of properties in an already activated device. If the device driver has not installed a device tree modification hook (as in almost 99% of the devices) it will do absolutely nothing, since the device tree is parsed only at probe time. I can argue that for these cases we could have a catch-all hook that displays a message that nothing happened.
We don't know if a driver has kept pointers to property values or not. That's why we don't ever delete properties. If we are modifying or removing a property, then we just add new ones. A rogue program repeatedly modifying a property and allocating memory might be a cause for concern.
Quoted 23 lines
4. Modification of some part of the tree that’s not part of a device driver, perhaps the aliases or chosen node. This may potentially be harmful or harmless depending on what has been modified. For instance modifying an already existing alias might cause internal inconsistency about device naming, while adding a new aliases should be harmless. This is a matter of policy per board, whether to allow or not.
Are there other cases that are potentially more harmful?
Quoted 10 lines
Quoted 9 lines
I ran into that issue when I tried to add thermal zones via an overlay, I've been investigating how to fix the thermal framework to work with overlays since then and have some partially working code. Currently the thermal framework parses the thermal-zones node at boot, and assumes this stays static. This breaks with overlays.
I agree we eventually need to fix the parts that break when we use overlays.
Regards
— Pantelis
Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name
In reply to Pantelis AntoniouQuoted 55 lines · Pantelis Antoniou
Quoted 54 lines · Rob Herring
Quoted 52 lines · Alan Tull
Quoted 39 lines · Frank Rowand
Quoted 38 lines · Rob Herring
Quoted 36 lines · Alan Tull
On Mon, Aug 21, 2017 at 10:16 AM, Rob Herring <[email protected]> wrote:
Hi Rob,
Quoted 17 lines
With dependencies on a statically allocated full path name converted to use %pOF format specifier, we can store just the basename of node, and the unflattening of the FDT can be simplified.
This commit will affect the remaining users of
full_name. After analyzing these users, the remaining cases should only change some print messages. The main users offull_nameare providing a name for struct resource. The resource names shouldn't be important other than providing/proc/iomemnames.We no longer distinguish between pre and post
0x10dtb formats as either a full path or basename will work. However, less than0x10formats have been broken since the conversion to use libfdt (and no one has cared). The conversion of the unflattening code to be non-recursive also broke pre0x10formats as thepopulate_nodefunction would return 0 in that case.Quoted 7 lines
Signed-off-by Rob Herring <[email protected]>---
v2:
- rebase to linux-nextdrivers/of/fdt.c | 69 +++++++++----------------------------------------------- 1 file changed, 11 insertions(+), 58 deletions(-)I've just updated to the latest next branch and am finding problems
applying overlays. Reverting this commit alleviates things. The
errors I get are:[ 88.498704] OF: overlay: Failed to apply prop @/__symbols__/clk_0 [ 88.513447] OF: overlay: apply failed '/__symbols__' [ 88.518423] create_overlay: Failed to create overlay (err=-12)Quoted 5 lines
Quoted 1 line
Frank's series with overlay updates should fix this.
Yes, it does:
[PATCH v3 11/12] of: overlay: remove a dependency on device node
full_nameThanks for the fast response. I fetched the dt/next branch to test this but there are sufficient changes that Pantelis' "OF: DT-Overlay configfs interface (v7)" is broken now. I've been adding that downstream since 4.4. We're using it as an interface for applying overlays to program FPGAs. If we fix it again, is there any chance that can go upstream now?
Quoted 7 lines
Quoted 2 lines
With a drive-by posting once every few years, no.
I take offense to that. There's nothing changed in the patch for years. Reposting the same patch without changes would achieve nothing.
Quoted 2 lines
The issue remains that the kernel is not really setup to deal with any random property or node to be changed at any point in run-time.
Yeah, I'm not super surprised :) I have some whitelist ideas below.
Quoted 6 lines
Quoted 6 lines
I
think there needs to be some restrictions around what the overlays can touch. We can't have it be wide open and then lock things down later and break users. One example of what you could do is you can only add sub-trees to whitelisted nodes. That's probably acceptable for your usecase.
I can take a look at making OF_OVERLAY_PRE_APPLY and OF_OVERLAY_PRE_REMOVE notifiers mandatory if that's interesting. The behavior would be: If an overlay is applied, there's got to be some
handler in the kernel that verifies that it is acceptable. In my
case, the handler for FPGA regions would look at the overlay and see it only added stuff under a FPGA region.
And we would change the default to be: if there is no handler, reject the overlay.
Quoted 7 lines
Quoted 1 line
Defining what can and what cannot be changed is not as trivial as a list of white-listed nodes.
In some cases there is a whole node hierarchy being inserted (like in a FPGA).
For FPGA, the insertion points are always FPGA regions.
Quoted 15 lines
In others, it's merely changing a status property to "okay" and a few device parameters.
The real issue is that the kernel has no way to verify that a given device tree, either at boot time or at overlay application time, is correct.
When the tree is wrong at boot-time you'll hang (if you're lucky). If the tree is wrong at run-time you'll get some into some unidentified funky state.
Finally what is, and what is not 'correct' is not for the kernel to decide arbitrarily, it's a matter of policy, different for each use-case.
Quoted 5 lines
Quoted 1 line
Rob
Regards
-- Pantelis
Alan Tull
Quoted 2 lines
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name
Quoted 81 lines · Alan Tull
Quoted 55 lines · Pantelis Antoniou
Quoted 54 lines · Rob Herring
Quoted 52 lines · Alan Tull
Quoted 39 lines · Frank Rowand
Quoted 38 lines · Rob Herring
Quoted 36 lines · Alan Tull
On Mon, Aug 21, 2017 at 10:16 AM, Rob Herring <[email protected]> wrote:
Hi Rob,
Quoted 17 lines
With dependencies on a statically allocated full path name converted to use %pOF format specifier, we can store just the basename of node, and the unflattening of the FDT can be simplified.
This commit will affect the remaining users of
full_name. After analyzing these users, the remaining cases should only change some print messages. The main users offull_nameare providing a name for struct resource. The resource names shouldn't be important other than providing/proc/iomemnames.We no longer distinguish between pre and post
0x10dtb formats as either a full path or basename will work. However, less than0x10formats have been broken since the conversion to use libfdt (and no one has cared). The conversion of the unflattening code to be non-recursive also broke pre0x10formats as thepopulate_nodefunction would return 0 in that case.Quoted 7 lines
Signed-off-by Rob Herring <[email protected]>---
v2:
- rebase to linux-nextdrivers/of/fdt.c | 69 +++++++++----------------------------------------------- 1 file changed, 11 insertions(+), 58 deletions(-)I've just updated to the latest next branch and am finding problems
applying overlays. Reverting this commit alleviates things. The
errors I get are:[ 88.498704] OF: overlay: Failed to apply prop @/__symbols__/clk_0 [ 88.513447] OF: overlay: apply failed '/__symbols__' [ 88.518423] create_overlay: Failed to create overlay (err=-12)Quoted 5 lines
Quoted 1 line
Frank's series with overlay updates should fix this.
Yes, it does:
[PATCH v3 11/12] of: overlay: remove a dependency on device node
full_nameThanks for the fast response. I fetched the dt/next branch to test this but there are sufficient changes that Pantelis' "OF: DT-Overlay configfs interface (v7)" is broken now. I've been adding that downstream since 4.4. We're using it as an interface for applying overlays to program FPGAs. If we fix it again, is there any chance that can go upstream now?
Quoted 7 lines
Quoted 2 lines
With a drive-by posting once every few years, no.
I take offense to that. There's nothing changed in the patch for years. Reposting the same patch without changes would achieve nothing.
Quoted 2 lines
The issue remains that the kernel is not really setup to deal with any random property or node to be changed at any point in run-time.
Yeah, I'm not super surprised :) I have some whitelist ideas below.
Quoted 6 lines
Quoted 6 lines
I
think there needs to be some restrictions around what the overlays can touch. We can't have it be wide open and then lock things down later and break users. One example of what you could do is you can only add sub-trees to whitelisted nodes. That's probably acceptable for your usecase.I can take a look at making
OF_OVERLAY_PRE_APPLYandOF_OVERLAY_PRE_REMOVEnotifiers mandatory if that's interesting. The behavior would be: If an overlay is applied, there's got to be some
handler in the kernel that verifies that it is acceptable. In my
case, the handler for FPGA regions would look at the overlay and see it only added stuff under a FPGA region.
Quoted 2 lines
And we would change the default to be: if there is no handler, reject the overlay.
I think the responsibility belongs to the device tree core code. It should be centralized and consistent.
In the fpga case, I think the connector paradigm should be adequate. The connector describes what is available to the fpga and provides access to those things. The fpga overlay does not reach outside the connector to touch anything else in the device tree.
Quoted 23 lines
Quoted 5 lines
Defining what can and what cannot be changed is not as trivial as a list of white-listed nodes.
In some cases there is a whole node hierarchy being inserted (like in a FPGA).
For FPGA, the insertion points are always FPGA regions.
Quoted 15 lines
In others, it's merely changing a status property to "okay" and a few device parameters.
The real issue is that the kernel has no way to verify that a given device tree, either at boot time or at overlay application time, is correct.
When the tree is wrong at boot-time you'll hang (if you're lucky). If the tree is wrong at run-time you'll get some into some unidentified funky state.
Finally what is, and what is not 'correct' is not for the kernel to decide arbitrarily, it's a matter of policy, different for each use-case.
Quoted 11 lines
Quoted 5 lines
Quoted 1 line
Rob
Regards
-- Pantelis
Alan Tull
Quoted 2 lines
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name
In reply to Rob HerringHi Rob,
Quoted 9 lines · Rob Herring
With dependencies on a statically allocated full path name converted to use %pOF format specifier, we can store just the basename of node, and the unflattening of the FDT can be simplified.
This commit will affect the remaining users of
full_name. After analyzing these users, the remaining cases should only change some print messages. The main users offull_nameare providing a name for struct resource. The resource names shouldn't be important other than providing/proc/iomemnames.
I guess the plan is to get rid in a subsequent step of all calls to kbasename() on a full name, which is now futile?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Rob Herring
maintainerRe: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name
Quoted 7 lines · Geert Uytterhoeven
Hi Rob,
Quoted 4 lines · Rob Herring
With dependencies on a statically allocated full path name converted to use %pOF format specifier, we can store just the basename of node, and the unflattening of the FDT can be simplified.
Quoted 8 lines
Quoted 5 lines
This commit will affect the remaining users of
full_name. After analyzing these users, the remaining cases should only change some print messages. The main users offull_nameare providing a name for struct resource. The resource names shouldn't be important other than providing/proc/iomemnames.I guess the plan is to get rid in a subsequent step of all calls to
kbasename()on a full name, which is now futile?
No. Sparc (PDT) is still the full path and I don't plan to change that.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html