> > How? What two different busses will see this same device? The amba bus > > code should prevent that from happening, right? If not, there's bigger > > problems in that bus code :) > > Where is that requirement documented? It isn't documented. No one > implements any kind of locking at the bus level to prevent this, not > PCI, nor platform devices. We don't want bus locking. There are lots of busses that can be parallel probed and in some cases its expensive not to do so. We may well need to do much more parallel probing in PCI bus in future and we may be parallel probing multiple bus types at once. The uart_register hack is simply broken. Nobody can stop you merging it Greg but in the long term its the wrong approach. We've identified a correct working approach which is to simply add a CONFIG entry to the ARM tree and a few ifdefs to the problem drivers to make the "problem" (in fact a complete fictional non-problem) go away and to get rid of the mess over time completely as the drivers are set dynamic and it turns out that all the userspace happens to already handle this just fine. Far better than botchfixes to uart registration code that will haunt us for years. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |