On Fri, 2017-12-08 at 14:22 +0200, Kalle Valo wrote:

Luca Coelho [off-list ref] writes:

quoted

On Wed, 2017-11-29 at 12:23 +0200, Kalle Valo wrote:

quoted

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.