Hi Josh, >>>>>> This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5. >>>>> >>>>> NAK. We allocated a static minor for this. >>>> >>>> Johan mentioned that. Commit b075dd40c95d11c2c8690f6c4d6232fc, >>>> correct? >> >> I am sorry Marcel, I only looked at the Linus tree, not at bluetooth or >> bluetooth-next. This commit should indeed fix the problem. Disregard my >> patch. >> >>> Why isn't that headed into 3.14 right now, and CC'd to >>>> stable? Currently you have a somewhat broken driver in 3.13 and >>>> 3.14-rcX that seems to have a pretty clear fix. >>> >>> somewhat broken? kmod prints this as an error, but it is not a regression in user functionality. The driver works just as before. The error message can be ignored. >> >> It's a regression in my sanity, since numerous users blame all kernel >> bugs on this error message and I am tired of explaining the situation >> (problem + error message == problem found *sigh*). I only sent this >> patch since I hadn't found the correct fix. > > Exactly. > >>> So if anybody feels strongly that the static device node assignment should be put into -stable, then I am fine with it. However I do not see this as passing requirement for a -stable fix since it is really not affecting anyone (minus the misleading message from kmod). >> >> Since b075dd4 will end up in the Linus tree eventually, I have no >> trouble backporting it myself. > > I don't have any difficulty doing that either, but if it was in stable > every distro getting bugs about it wouldn't have to carry the fix on > their own. the patch is currently in wireless-next and will eventually end up in net-next. Maybe it is better to have it cherry picked once it reaches net-next. 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
