On 09/04/2013 02:35 AM, Lars Poeschel wrote: > On Wednesday 04 September 2013 11:29:47, Stephen Warren wrote: >> On 09/03/2013 06:35 AM, Linus Walleij wrote: >>> On Fri, Aug 30, 2013 at 9:53 PM, Stephen Warren <swarren@xxxxxxxxxxxxx> > wrote: >>>> I still haven't seen an answer to why we really care about this; how >>>> many times has code actually allocated the same GPIO/IRQ when it >>>> shouldn't, in a way that it wasn't detectable by some other mechanism, >>>> i.e. the feature just not working? Why are we even trying to solve this >>>> issue? I'm not totally convinced it even makes sense to try and solve it. >>> >>> We care about this because a number of OMAP boards are not >>> working properly when booted from device tree, and they have a hard >>> time figuring out a solution to the problem. Last try exploded. Now >>> they are looking to create a patch that will fix the actual problem. >> >> Is something missing from /proc/interrupts or /sys/kernel/debug/gpios? >> If so, let's just add it. > > That would require procfs to be mounted to /proc and even CONFIG_PROC_FS to be > compiled in. Drivers have to work without that requirement. > That would require CONFIG_DEBUG_FS to be set, right? Drivers have to work > without that. Drivers will/could work fine without those options enabled and filesystems mounted. Nothing in this patch series affects that, nor would not applying the patch series. However, you only need this patch series if there's some kind of problematic resource conflict and you want to debug it. If your system has a problem and you want to debug it, it seems entirely reasonable to make use of (require making use of) the debugging tools that are already part of the kernel. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
