Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 28 Jan 2022 12:12:38 +0100
From:   Oleksij Rempel <o.rempel@pengutronix.de>
To:     Greg KH <gregkh@linuxfoundation.org>
Cc:     Oliver Neukum <oneukum@suse.com>, netdev@vger.kernel.org,
        linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
        kernel@pengutronix.de, Jakub Kicinski <kuba@kernel.org>,
        "David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH net-next v1 1/1] usbnet: add devlink support
Message-ID: <YfPPpkGjL2vcv4oH@pengutronix.de>
References: <20220127110742.922752-1-o.rempel@pengutronix.de>
 <YfJ+ceEzvzMM1JsW@kroah.com>
 <20220127123152.GF9150@pengutronix.de>
 <YfKcqcq4Ii1qu2+8@kroah.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <YfKcqcq4Ii1qu2+8@kroah.com>
Precedence: bulk

On Thu, Jan 27, 2022 at 02:22:49PM +0100, Greg KH wrote:
> On Thu, Jan 27, 2022 at 01:31:52PM +0100, Oleksij Rempel wrote:
> > On Thu, Jan 27, 2022 at 12:13:53PM +0100, Greg KH wrote:
> > > On Thu, Jan 27, 2022 at 12:07:42PM +0100, Oleksij Rempel wrote:
> > > > The weakest link of usbnet devices is the USB cable.
> > > 
> > > The weakest link of any USB device is the cable, why is this somehow
> > > special to usbnet devices?
> > > 
> > > > Currently there is
> > > > no way to automatically detect cable related issues except of analyzing
> > > > kernel log, which would differ depending on the USB host controller.
> > > > 
> > > > The Ethernet packet counter could potentially show evidence of some USB
> > > > related issues, but can be Ethernet related problem as well.
> > > > 
> > > > To provide generic way to detect USB issues or HW issues on different
> > > > levels we need to make use of devlink.
> > > 
> > > Please make this generic to all USB devices, usbnet is not special here
> > > at all.
> > 
> > Ok. I'll need some help. What is the best place to attach devlink
> > registration in the USB subsystem and the places to attach health
> > reporters?
> 
> You tell us, you are the one that thinks this needs to be reported to
> userspace. What is only being reported in kernel logs that userspace
> somehow needs to see?  And what will userspace do with that information?

The user space should get an event in case there is a problem with the
USB transfers, i.e. the URB status is != 0.

The use space then can decide if the USB device needs to be reset, power
cycled and so on.

What about calling a to-be-written devlink function that reports the USB
status if the URB status is not 0:

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index d0f45600b669..a90134854f32 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1648,6 +1648,8 @@ static void __usb_hcd_giveback_urb(struct urb *urb)
 	usb_unanchor_urb(urb);
 	if (likely(status == 0))
 		usb_led_activity(USB_LED_EVENT_HOST);
+	else
+		devlink_report_usb_status(urb, status);
 
 	/* pass ownership to the completion handler */
 	urb->status = status;

Regards,
Oleksij & Marc
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |