[patch] ehci-ppc-of: problems in unwind
The iounmap(ehci-ohci_hcctrl_reg); should be the first thing we do because the ioremap() was the last thing we did. Also if we hit any of the goto statements in the original code then it would have led to a NULL dereference of ehci. This bug was introduced in: 796bcae7361c USB: powerpc: Workaround for the PPC440EPX USBH_23 errata [take 3] I modified the few lines in front a little so that my code didn't obscure the return success code path. Signed-off-by: Dan Carpenter erro...@gmail.com --- I don't have a cross compile environment set up so I haven't compiled this code. Sorry for that. diff --git a/drivers/usb/host/ehci-ppc-of.c b/drivers/usb/host/ehci-ppc-of.c index 335ee69..ba52be4 100644 --- a/drivers/usb/host/ehci-ppc-of.c +++ b/drivers/usb/host/ehci-ppc-of.c @@ -192,17 +192,19 @@ ehci_hcd_ppc_of_probe(struct platform_device *op, const struct of_device_id *mat } rv = usb_add_hcd(hcd, irq, 0); - if (rv == 0) - return 0; + if (rv) + goto err_ehci; + + return 0; +err_ehci: + if (ehci-has_amcc_usb23) + iounmap(ehci-ohci_hcctrl_reg); iounmap(hcd-regs); err_ioremap: irq_dispose_mapping(irq); err_irq: release_mem_region(hcd-rsrc_start, hcd-rsrc_len); - - if (ehci-has_amcc_usb23) - iounmap(ehci-ohci_hcctrl_reg); err_rmr: usb_put_hcd(hcd); ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: olpc ofw question
On Wed, 11 Aug 2010 15:53:44 -1000 Mitch Bradley w...@firmworks.com wrote: [...] The proc_of.c code that I wrote in Dec 2006 uses the package-to-path method mentioned above, getting the n...@addr representation (package-to-path returns the full path, but you can easily extract just the tail component with strrchr(path, '/')) Thanks for the tip. I changed the code: - dp-name = pdt_get_one_property(node, name); +// dp-name = pdt_get_one_property(node, name); + dp-name = pdt_get_fullname(node); Where pdt_get_fullname() runs package-to-path and returns strrchr(buf, '/')+1; /proc/device-tree looks much better. Here's the diff now between /ofw and /proc/device-tree: http://dev.queued.net/~dilinger/dt2.diff Now I'm wondering a few things; 1) I'm setting node-name to the full node name now (including the @ suffix). Is there any reason why this might be incorrect (ie, that I should only be using the @ suffix in node-full_name)? It looks fine to me, but it's worth asking... 2) At a later point, it's probably worth looking into changing the sparc code to use this as well. Is there a reason why the sparc code doesn't shouldn't use this (ie, old firmware bugs)? 3) I get the following during proc population: [0.126687] device-tree: Duplicate name in /, renamed to dropin-fs#1 Looking at the diff, I see -/dropin-fs/.node -000 ` 222 206 377 -004 -/dropin-fs/.node -000 ` 222 206 377 Is this a bug in my version of OFW? ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: olpc ofw question
Andres Salomon wrote: On Wed, 11 Aug 2010 15:53:44 -1000 Mitch Bradley w...@firmworks.com wrote: [...] The proc_of.c code that I wrote in Dec 2006 uses the package-to-path method mentioned above, getting the n...@addr representation (package-to-path returns the full path, but you can easily extract just the tail component with strrchr(path, '/')) Thanks for the tip. I changed the code: - dp-name = pdt_get_one_property(node, name); +// dp-name = pdt_get_one_property(node, name); + dp-name = pdt_get_fullname(node); Where pdt_get_fullname() runs package-to-path and returns strrchr(buf, '/')+1; /proc/device-tree looks much better. Here's the diff now between /ofw and /proc/device-tree: http://dev.queued.net/~dilinger/dt2.diff Now I'm wondering a few things; 1) I'm setting node-name to the full node name now (including the @ suffix). Is there any reason why this might be incorrect (ie, that I should only be using the @ suffix in node-full_name)? It looks fine to me, but it's worth asking... 2) At a later point, it's probably worth looking into changing the sparc code to use this as well. Is there a reason why the sparc code doesn't shouldn't use this (ie, old firmware bugs)? package-to-path first appeared in OBP 3, i.e. the major version that conformed to the IEEE 1275 standard. OBP 1.x and OBP 2.x had a different (less portable and somewhat less functional) client interface ABI called romvec. If I remember correctly, OBP 3 first appeared on Sun 5 - UltraSPARC - systems. OBP 1 and 2 were on Sun 4c and related machines. I think it has been about 15 years since the last OBP 2.x system was released. There may still be a few working machines from that generation, but if so, they are of more historic interest than economic value. I ditched my last one something like 10 years ago. 3) I get the following during proc population: [0.126687] device-tree: Duplicate name in /, renamed to dropin-fs#1 Looking at the diff, I see -/dropin-fs/.node -000 ` 222 206 377 -004 -/dropin-fs/.node -000 ` 222 206 377 Is this a bug in my version of OFW? Yes. I just fixed it. Thanks for noticing it. Fortunately, it is innocuous. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
