Hello Andy,
Thanks a lot for your feedback.
On 06/19/2018 09:55 PM, Andy Shevchenko wrote:
> On Tue, Jun 19, 2018 at 10:53 PM, Andy Shevchenko
> <andy.shevche...@gmail.com> wrote:
>> On Tue, Jun 19, 2018 at 9:33 PM, Javier Martinez Canillas
>> <javi...@redhat.com> wrote:
>>> For debugging purposes it may be useful to know what are the devices whose
>>> probe function was deferred. Add a debugfs entry showing that information.
>
>>> +static int deferred_devs_open(struct inode *inode, struct file *file)
>>> +{
>>> + return single_open(file, deferred_devs_show, inode->i_private);
>>> +}
>>> +
>>> +static const struct file_operations deferred_devs_fops = {
>>> + .owner = THIS_MODULE,
>>> + .open = deferred_devs_open,
>>> + .read = seq_read,
>>> + .llseek = seq_lseek,
>>> + .release = single_release,
>>> +};
>>
>> Isn't this DEFINE_SHOW_ATTRIBUTE() ?
>
Indeed.
> Besides that, you are summoning Greg's dark side :-)
> See below.
>
>>> + if (IS_ENABLED(CONFIG_DEBUG_FS)) {
>>> + deferred_devices = debugfs_create_file("deferred_devices",
>>> + 0444, NULL, NULL,
>>> + &deferred_devs_fops);
>
>>> + if (!deferred_devices)
>>> + return -ENOMEM;
>
> This must not prevent the execution. So, the check introduces actually
> a regression.
>
Fair enough, I'll fix these an re-spin the patch.
>>> + }
>
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
