From: Sander Eikelenboom <linux@eikelenboom.it>
To: Peter Hurley <peter@hurleysoftware.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
"John W. Linville" <linville@tuxdriver.com>,
"David S. Miller" <davem@davemloft.net>,
Marcel Holtmann <marcel@holtmann.org>,
"Gustavo F. Padovan" <gustavo@padovan.org>,
"bluez mailin list (linux-bluetooth@vger.kernel.org)"
<linux-bluetooth@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [RC6 Bell Chime] [PATCH 00/24] rfcomm fixes
Date: Sat, 15 Mar 2014 14:51:46 +0100 [thread overview]
Message-ID: <164289036.20140315145146@eikelenboom.it> (raw)
In-Reply-To: <53225B87.1030904@hurleysoftware.com>
Friday, March 14, 2014, 2:29:43 AM, you wrote:
> Hi Sander,
> On 03/13/2014 08:49 PM, Sander Eikelenboom wrote:
>> <sarcasm on>
>> Is it just me .. or is this going at the speed of about a bluetooth connection ..
>> and probably missing the boot for 3.14 ? (for no good reason IMHO)
>> <sarcasm off>
>>
>> (it was not in John's nor Dave's last pull request, although it seems to be reverted in the bluetooth tree now .. i didn't
>> see any formal pull request from that .. to get it even *starting* to traverse all the trees up to Linus ... )
> Known bugs sometimes roll out into mainline release because the
> alternative can be worse.
> As I explained in the follow-up to my patch series, I would
> not have expected Marcel to pick up any of the fixes for 3.14.
> There are a lot of moving parts in usb + bluetooth + rfcomm + tty,
> and the unfortunate reality is that -next doesn't get as much
> testing as it should.
> The fault is mine because Gianluca let me know about the
> problems with the conversion to tty_port, but the holidays really
> interfered with my ability to put this work first, and I'm sorry
> for that.
> I know the breakage around RFCOMM is frustrating but I think the
> worst is behind us. After 3.15 gets some -rc testing, I will
> be happy to cherry-pick the critical fixes for -stable inclusion.
Ok but the breakage/regression was known since around the merge window.
I thought the "standard policy" when things cause new regression and are not fixable (too intrusive, too time consuming you
name the reason), was to revert .. (and possibly ASAP so the reverts also get some test coverage in mainline RC's).
That's also why i tested the revert ASAP to let you know that that worked .. at least for me.
But no big deal for mee .. the reverts are simple enough to be privately applied.
> Regards,
> Peter Hurley
next prev parent reply other threads:[~2014-03-15 13:51 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-10 1:59 Peter Hurley
2014-02-10 1:59 ` [PATCH 01/24] Revert "Bluetooth: Remove rfcomm_carrier_raised()" Peter Hurley
2014-02-10 1:59 ` [PATCH 02/24] Revert "Bluetooth: Always wait for a connection on RFCOMM open()" Peter Hurley
2014-02-10 1:59 ` [PATCH 03/24] Revert "Bluetooth: Move rfcomm_get_device() before rfcomm_dev_activate()" Peter Hurley
2014-02-10 1:59 ` [PATCH 04/24] tty: Fix ref counting for port krefs Peter Hurley
2014-02-13 18:36 ` Greg Kroah-Hartman
2014-02-10 1:59 ` [PATCH 05/24] Bluetooth: Fix racy acquire of rfcomm_dev reference Peter Hurley
2014-02-10 1:59 ` [PATCH 06/24] Bluetooth: Exclude released devices from RFCOMMGETDEVLIST ioctl Peter Hurley
2014-02-10 1:59 ` [PATCH 07/24] Bluetooth: Release rfcomm_dev only once Peter Hurley
2014-02-10 1:59 ` [PATCH 08/24] Bluetooth: Fix unreleased rfcomm_dev reference Peter Hurley
2014-02-10 1:59 ` [PATCH 09/24] Bluetooth: Fix RFCOMM tty teardown race Peter Hurley
2014-02-10 1:59 ` [PATCH 10/24] Bluetooth: Verify dlci not in use before rfcomm_dev create Peter Hurley
2014-02-10 1:59 ` [PATCH 11/24] Bluetooth: Simplify RFCOMM session state eval Peter Hurley
2014-02-10 1:59 ` [PATCH 12/24] Bluetooth: Refactor deferred setup test in rfcomm_dlc_close() Peter Hurley
2014-02-10 1:59 ` [PATCH 13/24] Bluetooth: Refactor dlc disconnect logic " Peter Hurley
2014-02-10 1:59 ` [PATCH 14/24] Bluetooth: Directly close dlc for not yet started RFCOMM session Peter Hurley
2014-02-10 1:59 ` [PATCH 15/24] Bluetooth: Fix unsafe RFCOMM device parenting Peter Hurley
2014-02-10 1:59 ` [PATCH 16/24] Bluetooth: Fix RFCOMM parent device for reused dlc Peter Hurley
2014-02-10 1:59 ` [PATCH 17/24] Bluetooth: Rename __rfcomm_dev_get() to __rfcomm_dev_lookup() Peter Hurley
2014-02-10 1:59 ` [PATCH 18/24] Bluetooth: Serialize RFCOMMCREATEDEV and RFCOMMRELEASEDEV ioctls Peter Hurley
2014-02-10 1:59 ` [PATCH 19/24] Bluetooth: Refactor rfcomm_dev_add() Peter Hurley
2014-02-10 1:59 ` [PATCH 20/24] Bluetooth: Cleanup RFCOMM device registration error handling Peter Hurley
2014-02-10 1:59 ` [PATCH 21/24] Bluetooth: Force -EIO from tty read/write if .activate() fails Peter Hurley
2014-02-10 1:59 ` [PATCH 22/24] Bluetooth: Don't fail RFCOMM tty writes Peter Hurley
2014-02-10 1:59 ` [PATCH 23/24] Bluetooth: Refactor write_room() calculation Peter Hurley
2014-02-10 1:59 ` [PATCH 24/24] Bluetooth: Fix " Peter Hurley
2014-02-10 22:09 ` [PATCH 00/24] rfcomm fixes Marcel Holtmann
2014-02-10 23:00 ` Peter Hurley
2014-02-12 22:58 ` Marcel Holtmann
2014-02-13 0:38 ` Peter Hurley
2014-02-13 21:48 ` Alexander Holler
2014-02-12 11:06 ` Sander Eikelenboom
2014-03-03 19:38 ` Sander Eikelenboom
2014-03-10 8:38 ` [RC6 Bell Chime] " Sander Eikelenboom
2014-03-10 15:08 ` John W. Linville
2014-03-11 15:14 ` [RC6 Bell Chime] " Marcel Holtmann
2014-03-14 0:49 ` Sander Eikelenboom
2014-03-14 1:28 ` Marcel Holtmann
2014-03-14 1:29 ` Peter Hurley
2014-03-15 13:51 ` Sander Eikelenboom [this message]
2014-03-15 17:53 ` Linus Torvalds
2014-03-15 20:45 ` Peter Hurley
2014-03-15 22:20 ` Sander Eikelenboom
2014-03-16 0:16 ` Linus Torvalds
2014-02-13 21:41 ` Alexander Holler
2014-02-14 21:45 ` Marcel Holtmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=164289036.20140315145146@eikelenboom.it \
--to=linux@eikelenboom.it \
--cc=davem@davemloft.net \
--cc=gustavo@padovan.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=marcel@holtmann.org \
--cc=peter@hurleysoftware.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®