How best to get over-current notification to user application?

[Arvid Brodin]

Hi,

What's the best way to get a notification in user space when an overcurrent
event occurs on a usb port? The idea is to let a user application notify the
user that something is wrong.

When a usb port is short-circuited (or otherwise over-loaded), a message like
this is sent to the system log:

hub 1-1:1.0: over-current change on port 3

So one solution would be to create a chain of pipes, running something like
'tail -f /var/log/messages | egrep "hub.*over-current change"' and read the
output from this in the program. Is there a better way (some kind of sysfs
interface for port power state, maybe)?

Thanks,
Arvid Brodin
Enea Services Stockholm AB
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Alan Stern]

Post by Arvid Brodin
Hi,
What's the best way to get a notification in user space when an overcurrent
event occurs on a usb port? The idea is to let a user application notify the
user that something is wrong.
When a usb port is short-circuited (or otherwise over-loaded), a message like
hub 1-1:1.0: over-current change on port 3
So one solution would be to create a chain of pipes, running something like
'tail -f /var/log/messages | egrep "hub.*over-current change"' and read the
output from this in the program. Is there a better way (some kind of sysfs
interface for port power state, maybe)?

The port status information is not exported to userspace in any way
other than the kernel log.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Oliver Neukum]

So one solution would be to create a chain of pipes, running somethin=

g like

'tail -f /var/log/messages | egrep "hub.*over-current change"' and re=

ad the

output from this in the program. Is there a better way (some kind of =

sysfs

interface for port power state, maybe)?

Eek. It seems to me that the cleanest solution would be to have
a charachter device per hub that allows such conditions to be polled
for.

Regards
Oliver
--=20
- - -=20
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6=
rffer, HRB 16746 (AG N=FCrnberg)=20
Maxfeldstra=DFe 5 =20
90409 N=FCrnberg=20
Germany=20
- - -=20
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Alan Stern]

Post by Oliver Neukum

Post by Arvid Brodin
So one solution would be to create a chain of pipes, running something like
'tail -f /var/log/messages | egrep "hub.*over-current change"' and read the
output from this in the program. Is there a better way (some kind of sysfs
interface for port power state, maybe)?

Eek. It seems to me that the cleanest solution would be to have
a charachter device per hub that allows such conditions to be polled
for.

There are plenty of error conditions that the kernel does not export to
userspace.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Juergen Beisert]

This post might be inappropriate. Click to display it.

[Alan Stern]

Post by Juergen Beisert
It seems the overcurrent case is an important event. So we really should think
about how to report it to userland in useful manner.

Post by Alan Stern
There are plenty of error conditions that the kernel does not export to
userspace.

Sure. But IMHO sometimes it would be really nice, to have a reliable API to
filter for some error conditions, than some ugly regular expressions for
kernel messages.

I'm not saying that these things shouldn't be reported. But the kernel
needs to have a standard, accepted way of doing this.

IMO, the two of you should start a discussion regarding this issue (how
to report important hardware or software events to userspace) on LKML.
When you do, please CC: linux-usb. Things to consider include:

The type of event (hardware failure, data structure corruption,
imminent data loss, imminent hardware destruction...).

Whether or not the user can do anything to fix the problem.

Whatever else you can think of.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Arvid Brodin]

Post by Juergen Beisert

Post by Arvid Brodin
What's the best way to get a notification in user space when an overcurrent
event occurs on a usb port? The idea is to let a user application notify
the user that something is wrong.

Long time ago (linux-2.6.36) we did this in one of our projects, to forward
this event to userland.
Date: Wed, 11 Aug 2010 14:18:04 +0200
Subject: [PATCH] Generate a uevent when an overcurrent event happens
This quick hack generates a 'uevent' to userland and adds the 'POWERFAIL=1'
environment variable for this report. Any userland program listening to the
'uevent' interface can filter for the presence of this environment variable
to distinguish this special 'uevent' from other 'add' or 'remove' events.
Current disadvantage: Due to the fact, the hub driver tries to enable the
port again immediately (it does not wait for user interaction) this powerfail
event gets reported twice: First time when it really happens and second time
when the external overcurrent detection device will be reset. The second
false positive report must be sorted out by the userland application.
---
drivers/usb/core/hub.c | 4 ++++
1 file changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 84c18971..c615292 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3372,9 +3372,13 @@ static void hub_events(void)
}
if (portchange & USB_PORT_STAT_C_OVERCURRENT) {
+ char event[] = "POWERFAIL=1";
+ char *envp[] = { event, NULL };
+
dev_err (hub_dev,
"over-current change on port %d\n",
i);
+ kobject_uevent_env(&hub->intfdev->kobj, KOBJ_CHANGE, envp);
clear_port_feature(hdev, i,
USB_PORT_FEAT_C_OVER_CURRENT);
hub_power_on(hub, true);

Thank you, this might be useful!