On 3/13/2018 2:10 PM, Kalle Valo wrote:
Arend van Spriel <arend.vanspr...@broadcom.com> writes:

On 3/12/2018 10:41 AM, Kalle Valo wrote:
Arend Van Spriel <arend.vanspr...@broadcom.com> wrote:

Since commit 3c47d19ff4dc ("drivers: base: add coredump driver ops")
it is possible to initiate a device coredump from user-space. This
patch adds support for it adding the .coredump() driver callback.
As there is no longer a need to initiate it through debugfs remove
that code.

Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>

Based on the discussion I assume this is ok to take to w-d-next. If that's not
the case, please let me know ASAP.

It is up to the mwifiex maintainers to decide, I guess. The ABI
documentation need to be revised and change the callback to void
return type. I am not sure what the best approach is. 1) apply this
and fix return type later, or 2) fix return type and resubmit this.
What is your opinion?

I guess the callback change will go through Greg's tree? Then I suspect
it's easier that you submit the callback change to Greg first and wait
for it to trickle down to wireless-drivers-next (after the next merge
window) and then I can apply the driver patches. Otherwise there might
be a conflict between my and Greg's tree.

That was my assessment, but unfortunately Marcel already applied the btmrvl patch before I could reply. So how do I move from here? Option 1) revert brmrvl and fix callback return type, or 2) apply mwifiex patch and fix callback return type later for both drivers.

Regards,
Arend

Reply via email to