On 3/12/2018 10:41 AM, Kalle Valo wrote:
> Arend Van Spriel <[email protected]> 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 <[email protected]>
>
> 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?
Regards,
Arend
Arend van Spriel <[email protected]> writes:
> On 3/12/2018 10:41 AM, Kalle Valo wrote:
>> Arend Van Spriel <[email protected]> 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 <[email protected]>
>>
>> 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.
--
Kalle Valo
On 3/13/2018 2:10 PM, Kalle Valo wrote:
> Arend van Spriel <[email protected]> writes:
>
>> On 3/12/2018 10:41 AM, Kalle Valo wrote:
>>> Arend Van Spriel <[email protected]> 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 <[email protected]>
>>>
>>> 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
Hi Arend,
>>>>> 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 <[email protected]>
>>>>
>>>> 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.
I can take the patch back out of bluetooth-next if needed. It is your call.
Regards
Marcel
On 3/13/2018 9:19 PM, Marcel Holtmann wrote:
> Hi Arend,
>
>>>>>> 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 <[email protected]>
>>>>>
>>>>> 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.
>
> I can take the patch back out of bluetooth-next if needed. It is your call.
Thanks, Marcel
Let's go for that. Please revert/remove the patch.
Regards,
Arend