Hi Marcel, On Fri, Mar 01, 2013, Marcel Holtmann wrote: > > One possible solution I can think of is that we update the CoD or EIR > > value in hdev as soon as we create a HCI command to update the value, as > > opposed to updating the hdev value when the HCI command completes. This > > would allow us to have sensible checks on whether new HCI commands need > > to be queued or not. We'd then have to have some flag to indicate that > > there are pending EIR or CoD commands so that any of these mgmt commands > > don't return a direct cmd_complete just because it looks like everything > > is fine based on the CoD/EIR values in hdev. > > I see the dilemma now. Still not liking it that much. I wonder if we > should just force one command of each opcode present at all time. No > special handling for any of them. If you send the same opcode twice > before it returned, you get busy error. That still doesn't completely solve the issue since what we have is not just the same command conflicting against another pending instance of itself but several different commands conflicting against each other (since they all can cause changes to the CoD or EIR). Johan -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
