From: Oliver Neukum <oneukum@suse.com>
To: Raul E Rangel <rrangel@chromium.org>, linux-usb@vger.kernel.org
Cc: Miquel Raynal <miquel.raynal@bootlin.com>,
djkurtz@chromium.org, Dmitry Torokhov <dtor@chromium.org>,
groeck@chromium.org,
"Gustavo A. R. Silva" <gustavo@embeddedor.com>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
Johan Hovold <johan@kernel.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Mathias Nyman <mathias.nyman@linux.intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Alan Stern <stern@rowland.harvard.edu>,
Roger Quadros <rogerq@ti.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] usb/hcd: Send a uevent signaling that the host controller has died
Date: Thu, 11 Apr 2019 08:35:55 +0200 [thread overview]
Message-ID: <1554964555.21725.14.camel@suse.com> (raw)
In-Reply-To: <20190410203520.248158-1-rrangel@chromium.org>
On Mi, 2019-04-10 at 14:35 -0600, Raul E Rangel wrote:
> This change will send a CHANGE event to udev with the DEAD environment
> variable set when the HC dies. I chose this instead of any of the other
> udev events because it's representing a state change in the host
> controller. The only other event that might have fit was OFFLINE, but
> that seems to be used for hot-removal.
>
> By notifying user space the appropriate policies can be applied.
> e.g.,
> * Collect error logs.
> * Notify the user that USB is no longer functional.
> * Perform a graceful reboot.
Could you please make sure this type of event is shared with other
subsystems whose devices can "die"?
It looks to me like SCSI offline should for example create the
same event. This kind of thing needs to be documented.
Regards
Oliver
prev parent reply other threads:[~2019-04-11 8:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-10 20:35 [PATCH] usb/hcd: Send a uevent signaling that the host controller has died Raul E Rangel
2019-04-10 20:54 ` Alan Stern
2019-04-11 6:35 ` Oliver Neukum [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1554964555.21725.14.camel@suse.com \
--to=oneukum@suse.com \
--cc=bigeasy@linutronix.de \
--cc=djkurtz@chromium.org \
--cc=dtor@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=groeck@chromium.org \
--cc=gustavo@embeddedor.com \
--cc=johan@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=martin.blumenstingl@googlemail.com \
--cc=mathias.nyman@linux.intel.com \
--cc=miquel.raynal@bootlin.com \
--cc=rogerq@ti.com \
--cc=rrangel@chromium.org \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).