Hi Johan, >>> 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). that is indeed a problem. As much as I do not like it, maybe doing it like you did is the only way to handle this. Can you add a comment on why we are doing this and send an updated patch series. Regards Marcel -- 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
