> > The race isn't the uart code, it's the driver model. > > > > Consider what happens when this happens: > > > > * Two pl011 devices get registered at the same time by two different > > threads. > > 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 :) > > That's where this problem should be fixed, if there is one, otherwise > this same issue would be there for any type of driver that calles into > the uart core, right? I did some more digging into this the problem goes beyond the uart and driver model code. Even if you serialize every bus and you serialize every bus against every other bus (which you can't do btw as we get recursive probes of one bus from a device probe of another) it's still racy. We have non bus registering paths for some drivers and those could be user triggered. An obvious example is 8250. If the 8250 driver is loaded on a platform where no device is autodetected (which is true on a few wackier PC laptops with touchscreens on an 8250) then you hae a race between say a PCMCIA card insertion of an 8250 and a user who creates the first 8250 device using setserial at the same moment. There are similar races between the various directly created devices on some of the serial ports and bus probed ones where the driver mixes bus probing with olde worlde straight forward hardcoding. 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
 |