Re: [PATCH] net: stmmac: Move debugfs init/exit to ->probe()/->remove()

[Thierry Reding]

On Tue, Nov 27, 2018 at 09:02:51AM +0000, Jose Abreu wrote:
> On 26-11-2018 15:34, Thierry Reding wrote:
> > On Fri, Nov 23, 2018 at 12:44:02PM +0000, Jose Abreu wrote:
> >> On 23-11-2018 12:21, Thierry Reding wrote:
> >>> From: Thierry Reding <treding@xxxxxxxxxx>
> >>>
> >>> Setting up and tearing down debugfs is current unbalanced, as seen by
> >>> this error during resume from suspend:
> >>>
> >>>     [  752.134067] dwc-eth-dwmac 2490000.ethernet eth0: ERROR failed to create debugfs directory
> >>>     [  752.134347] dwc-eth-dwmac 2490000.ethernet eth0: stmmac_hw_setup: failed debugFS registration
> >>>
> >>> The imbalance happens because the driver creates the debugfs hierarchy
> >>> when the device is opened and tears it down when the device is closed.
> >>> There's little gain in that, and it could be argued that it is even
> >>> surprising because it's not usually done for other devices. Fix the
> >>> imbalance by moving the debugfs creation and teardown to the driver's
> >>> ->probe() and ->remove() implementations instead.
> >>>
> >>> Signed-off-by: Thierry Reding <treding@xxxxxxxxxx>
> >>> ---
> >>>
> >> Did you test trying to dump "descriptors_status" file when
> >> interface is not open ? I think that's the main reason why this
> >> is not in probe ...
> > Indeed, that seems to cause a hang. Still, it doesn't sound like the
> > right things to repeatedly create and remove debugfs files just because
> > we can't provide the contents when the device is down.
> 
> Agree.
> 
> >
> > How about we return an empty file or an error code instead when the
> > interface is down?
> 
> I think an error code would be more suitable (ENODEV/EBUSY ?).
> Can you submit v2 ?

I submitted a v2 earlier but wanted to elaborate why I ended up going
with an empty file instead of an error code. None of the error codes
seem like a good fit. For example ENODEV might lead people to think that
somehow the device was removed, whereas EBUSY could be misinterpreted as
the device being busy and therefore being unable to dump the status of
the rings.

I was leaning towards EPERM in the end, but then thought that it also
was ambiguous because it could be interpreted as meaning the user lacked
the permissions to query the rings status.

So in the end, it occurred to me that reading the rings status for an
interface that was down wasn't really an error. It's just that there's
no ring structures to dump, so the most logical way to return that was
with success but an empty file.

Thierry

Attachment: signature.asc
Description: PGP signature