On Fri, 2017-12-08 at 14:22 +0200, Kalle Valo wrote: > Luca Coelho <luca@xxxxxxxxx> writes: > > > On Wed, 2017-11-29 at 12:23 +0200, Kalle Valo wrote: > > > > > But no wonder I called gnus-article-fill-cited-article, the > > > commit > > > log is just weirdly wrapped. Are you using outlook or how do you > > > get > > > it so ugly? :) > > > > Heh! I don't think it's wrapped weirdly, it's just that the > > paragraphs > > don't have spaces between them, right? ;) > > Sorry, don't get what you mean with missing spaces. To me (and > patchwork[1] and git[2] seem to agree) the word wrapping is just > broken > for this commit log, and I have seen it also with other iwlwifi > commits. > For example, there are just two words in the second line "two paths." That depends on how many characters per line you want to include. "two paths." is the last part of the first paragraph, I guess Sari's editor is wrapping somewhere at <70 chars per line. Then that is accentuated a bit by the lack of an empty line between paragraphs. But with those lines added, besides being a bit narrow, it would look quite clear: -----8<----- When getting HW rfkill we get stop_device being called from two paths. One path is the IRQ calling stop device, and updating op mode and stack. As a result, cfg80211 is running rfkill sync work that shuts down all devices (second path). In the second path, we eventually get to iwl_mvm_stop_device which calls iwl_fw_dump_conf_clear->iwl_fw_dbg_stop_recording, that access periphery registers. The device may be stopped at this point from the first path, which will result with a failure to access those registers. Simply checking for the trans status is insufficient, since the race will still exist, only minimized. Instead, move the stop from iwl_fw_dump_conf_clear (which is getting called only from stop path) to the transport stop device function, where the access is always safe. This has the added value, of actually stopping dbgc before stopping device even when the stop is initiated from the transport. ----->8----- Does it make sense? I've already told Sari about your preference and I'll make sure the next patches will look cleaner. I can fix this patch if you want, but is it worth remaking my pull-request just for this? -- Cheers, Luca.
