Re: [PATCH for-4.16 2/3] drivers: change struct device_driver::coredump() return type to void

[Arend van Spriel]

On Fri, Mar 23, 2018 at 5:55 PM, Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> On Thu, Mar 15, 2018 at 10:55:24AM +0100, Arend van Spriel wrote:
>> Upon submitting a patch for mwifiex [1] it was discussed whether this
>> callback function could fail. To keep things simple there is no need
>> for the error code so the driver can do the task synchronous or not
>> without worries. Currently the device driver core already ignores the
>> return value so changing it to void.
>>
>> [1] https://patchwork.kernel.org/patch/10231933/
>>
>> Signed-off-by: Arend van Spriel <aspriel@xxxxxxxxx>
>> ---
>>  include/linux/device.h | 5 ++++-
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/linux/device.h b/include/linux/device.h
>> index b093405..f08c25b 100644
>> --- a/include/linux/device.h
>> +++ b/include/linux/device.h
>> @@ -256,6 +256,9 @@ enum probe_type {
>>   *           automatically.
>>   * @pm:              Power management operations of the device which matched
>>   *           this driver.
>> + * @coredump:        Called when sysfs entry is written to. The device driver
>> + *           is expected to call the dev_coredump API resulting in a
>> + *           uevent.
>>   * @p:               Driver core's private data, no one other than the driver
>>   *           core can touch this.
>>   *
>> @@ -287,7 +290,7 @@ struct device_driver {
>>       const struct attribute_group **groups;
>>
>>       const struct dev_pm_ops *pm;
>> -     int (*coredump) (struct device *dev);
>> +     void (*coredump) (struct device *dev);
>
> Isn't this going to cause build warnings now?  Are there no users of
> this callback function yet?

Hi Greg,

I submitted driver patches for the 4.17 kernel and from that
discussion we concluded it would be good to change to void return
type. So those driver patches were dropped. The caller of the callback
in drivers/base/dd.c does not use the return value so from that side
there is no issue. So my motivation for asking to consider this for
4.16 is so I can resubmit the driver patches for 4.17 if there is
still time before the merge window.

Regards,
Arend