Hi Peter, >>> This patch series addresses a number of previously unknown issues >>> with the RFCOMM tty device implementation, in addition to >>> addressing the locking regression recently reported [1]. >>> >>> As Gianluca suggested and I agree, this series first reverts >>> 3 of the 4 patches of 3.14-rc1 for bluetooth/rfcomm/tty.c. >> >> so for 3.14 we should revert 3 patches. And then the other 21 are > > intended for 3.15 merge window. > > Yep, this is probably best. At least 3.13 & 3.14 will behave the > same wrt rfcomm. > >> I realize that we still have to deal with some breakage, but we > > do not want regressions and I clearly not going to take 24 patches > > for 3.14 at this point in time. > > Yeah, I wasn't expecting you to. > >> What I can do is take all 24 patches into bluetooth-next and let > > them sit for 1 week and have people test them. And then we go ahead > > with reverting 3 patches from 3.14. Does that make sense? > > Yep, that's fine with me. Thanks. we might also want to add some end-to-end test cases to rfcomm-tester that covers this behavior. 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
