[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170112174142.GA23954@kroah.com>
Date: Thu, 12 Jan 2017 18:41:42 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Rob Herring <robh@...nel.org>
Cc: Ben Hutchings <ben.hutchings@...ethink.co.uk>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Mark Brown <broonie@...nel.org>,
Tomeu Vizoso <tomeu.vizoso@...labora.com>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Thierry Reding <thierry.reding@...il.com>
Subject: Re: sysfs deferred_probe attribute
On Thu, Jan 12, 2017 at 11:27:01AM -0600, Rob Herring wrote:
> I just noticed that we have a new device attribute 'deferred_probe'
> added in 4.10 with this commit:
>
> commit 6751667a29d6fd64afb9ce30567ad616b68ed789
> Author: Ben Hutchings <ben.hutchings@...ethink.co.uk>
> Date: Tue Aug 16 14:34:18 2016 +0100
>
> driver core: Add deferred_probe attribute to devices in sysfs
>
> It is sometimes useful to know that a device is on the deferred probe
> list rather than, say, not having a driver available. Expose this
> information to user-space.
>
> Signed-off-by: Ben Hutchings <ben.hutchings@...ethink.co.uk>
> Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
>
>
> It seems like a bad idea to add an ABI for an internal kernel feature.
> When/if we replace deferred probe with something better based on
> functional dependencies are we going to keep this attr around? Or
> remove it and assume no userspace uses it? Perhaps it should be hidden
> behind CONFIG_DEBUG or just make a debugfs file that lists the
> deferred list. Then you wouldn't have to hunt for what got deferred.
Ah, debugfs would be nice, I'd much prefer that. I don't know how Ben
is using this, but I think that would make more sense to me.
thanks,
greg k-h
Powered by blists - more mailing lists