Re: [RC6 Bell Chime] [PATCH 00/24] rfcomm fixes

Marcel Holtmann
2014-03-11T15:14:49Z

Hi John,

>> Since:
>> - 3.14-RC6 has been cut
>> - this regression is known and reported since the merge window
>> - the fix (revert of 3 patches) is known for over a month now
>> - but it's still not in mainline
>> - my polite ping request from last week seems to have provoked exactly 0 (zero) response.
>>
>> IT'S TIME TO CHIME SOME BELLS :-)
>>
>> Hope that WILL be heard somewhere ...
>>
>> --
>> Sander
>>
>> PS. on the informative side the 3 commits to be reverted are:
>>
>> f86772af6a0f643d3e13eb3f4f9213ae0c333ee4 Bluetooth: Remove rfcomm_carrier_raised()
>> 4a2fb3ecc7467c775b154813861f25a0ddc11aa0 Bluetooth: Always wait for a connection on RFCOMM open()
>> e228b63390536f5b737056059a9a04ea016b1abf Bluetooth: Move rfcomm_get_device() before rfcomm_dev_activate()
>
> Gustavo, should I be expecting a pull request?

you have all 3 reverts already in wireless-next as part of a larger RFCOMM change from Peter that we had to do to get this bug fixed. The whole series ended up as 24 patches and was way to late in the -rc stage. In addition we did not have enough exposure from people running that patch set. I did not wanted to end up in a ping-pong situation with apply + revert over and over again until we gave this some test exposure.

I think it is pretty safe to revert these 3 patches from 3.14-rc6 since they broke more than they actually fixed. However everybody has to be aware of that the real fix only comes in 3.15 since the change unfortunately is large. As far as we can tell, only users of RFCOMM TTY are affected. All RFCOMM socket users are fine.

So I do not know what the best way of getting these reverts merged. Gustavo has a tree ready for you to pull from. Or would it be better if they get cherry picked from wireless-next tree.

Regards

Marcel