Return-Path: Message-ID: <52F95A10.5010507@hurleysoftware.com> Date: Mon, 10 Feb 2014 18:00:32 -0500 From: Peter Hurley MIME-Version: 1.0 To: Marcel Holtmann CC: "Gustavo F. Padovan" , Johan Hedberg , Gianluca Anzolin , Alexander Holler , Andrey Vihrov , Sander Eikelenboom , "bluez mailin list (linux-bluetooth@vger.kernel.org)" , linux-kernel Subject: Re: [PATCH 00/24] rfcomm fixes References: <1391997564-1805-1-git-send-email-peter@hurleysoftware.com> <3E0F3723-029F-4B12-8D77-9790FDBD3227@holtmann.org> In-Reply-To: <3E0F3723-029F-4B12-8D77-9790FDBD3227@holtmann.org> Content-Type: text/plain; charset=UTF-8; format=flowed List-ID: Hi Marcel, On 02/10/2014 05:09 PM, Marcel Holtmann wrote: > 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. Regards, Peter Hurley