Hi Luiz, > >> I guess you guys don't remember, but I tried to explain why the > >> priority has to be set even for RFCOMM, any frame sent by the kernel > >> with a timeout needs to be scheduled as soon as possible otherwise it > >> may timeout due to quote being consumed by other channels with higher > >> priority, so in this case if an A2DP stream in ongoing you will never > >> be able to complete a RFCOMM connection because there wont be enough > >> quote to schedule them before they timeout (usually 10 out 10 attempt > >> end up like that in my setup). > >> > >> Perhaps if we assign a dedicated queue/hci_chan per RFCOMM socket that > >> should get rid of this resetting sk_priority on every frame, but that > >> means not depending on socket API at all to pass frames from RFCOMM to > >> L2CAP, so we need an API to create L2CAP frames directly in RFCOMM > >> modules and queue them in its hci_chan. > > > > yes, we need exactly this. Not using the L2CAP socket and interfacing > > with L2CAP directly is a good idea. Same came up with A2MP as well. > > Right, so I will work on this next, but in the meantime I think we > should keep the current logic (it doesn't seems to cause any problem > although the locking is pretty bad) until we got a proper solution and > at least it is able to complete connections. the locking is broken with the move to workqueues. So feel free to figure out a locking that works, but right now it is screwed up. Be my guest to set a MAX_PRIO - 1 by default for RFCOMM and see how that works out. 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
