On Wednesday 11 March 2009 22:08:43 Luis R. Rodriguez wrote: > On Wed, Mar 11, 2009 at 10:30 AM, Johannes Berg > <johannes@xxxxxxxxxxxxxxxx> wrote: > > On Wed, 2009-03-11 at 10:20 -0700, Luis R. Rodriguez wrote: > > > >> > Hmm. I really don't understand this at all. Most operations won't be > >> > single writes and reads, and if you need multiple like a write+read for > >> > indirect register accesses then I'm sure you need to serialise them > >> > against each other in some other way too, no? > >> > >> The issue is not serializing against separate routines calling some > >> reads or writes, this serialization prevents the PCI hardware FIFO > >> queue from getting more than two requests as otherwise the hardware > >> poops out. But as you can see this is only an issue with PCI devices, > >> not PCI express devices. > > > > Well yes, but if you ever do multi-read/write operations then you need > > to synchronise at a higher level anyway -- hence I don't quite > > understand why this is necessary at all. > > Agreed as the PCI FIFO issue should be visible on even UP boxes too. I > was trying to find out out exactly why in an SMP system this would > occur and it seems the only thing that would cause this is two > separate threads reading/writing. I did review this but I was unable > to find a specific synchronization issue. Technically the most obvious > case is where we handle the beacon tasklet on one CPU and then the > RX/TX tasklet (this is done in just one tasklet) in another but we > don't handle the beaconing tasklet in STA mode and this issue is seen > immediately upon association as a STA. I've been unable to locate that > source of possible synchronization issue. If you get an idea let me > know. maybe it's down to the simple fact that most mainboard nowadays queue up pci writes? what happends when you always read the register after it was updated? > Your point about the simplicity of the code by always doing the > locking makes sense and its difficult to decide whether or not we want > that without doing elaborate tests and analysis. Only reason to > consider this carefully is that we will in fact be changing the > behavior of each read/write. > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
