Hi Luiz, [I'm subscribed only to lf_driver_backport] On Tue, Mar 20, 2012 at 9:50 AM, Luis R. Rodriguez <mcgrof@xxxxxxxxxxxxx> wrote: > On Tue, Mar 20, 2012 at 5:07 AM, Johannes Berg > <johannes@xxxxxxxxxxxxxxxx> wrote: >> On Mon, 2012-03-19 at 20:26 -0700, Luis R. Rodriguez wrote: >>> From: "Luis R. Rodriguez" <mcgrof@xxxxxxxxxxxxx> >>> >>> Best we can do is just tell the users of we are WORK_BUSY_PENDING >>> for older kernels. The ckmake log: >> >> [...] >> >>> + * Test whether @work is currently pending or running. There is no >>> + * synchronization around this function and the test result is >>> + * unreliable and only useful as advisory hints or for debugging. >>> + * Especially for reentrant wqs, the pending state might hide the >>> + * running state. >> >> What's this needed for? It seems if it's used only for hints/debugging >> we should not need the function, or possibly simply return some >> pointless combination like -1? > > net/bluetooth/hci_core.c:1701: if (work_busy(&hdev->le_scan)) Did you consider making this change bluetooth specific (e.g. under patches/16-bluetooth.patch with LINUX_VERSION_CODE check) so that work_pending() is used on this location for older kernels? Or are there other users for work_busy() besides bluetooth? I talked with the author of this code (CC'd) and he said it should be safe to make this replacement. Another change I made sometime ago (specifically to bluetooth code) for it to build with older kenels (2.6.32 in my case), was to change this line in net/bluetooth/hci_core.c: queue_work(system_long_wq, &hdev->le_scan); to: schedule_work(&hdev->le_scan); Again, I checked with the original author and we believe it is okay to do this (I also lightly tested these changes). Hope that helps. Best Regards, -- Anderson Lizardo Instituto Nokia de Tecnologia - INdT Manaus - Brazil -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
