netdev - [PATCH] atm : fix /sys/devices/virtual/atm/X/carrier(ATM_PHY_SIG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 13 Feb 2010 22:56:33 +0100
From:	Philippe De Muyter <phdm@...qel.be>
To:	chas@....nrl.navy.mil, netdev@...r.kernel.org
Subject: [PATCH] atm : fix
	/sys/devices/virtual/atm/X/carrier(ATM_PHY_SIG_UNKNOWN)

When trying to design udev rules to automate usage of cxacru usb atm (adsl)
modem, I have discovered that /sys/devices/virtual/atm/cxacru0/carrier had the
value '1' while actually carrier was not yet established and real carrier
state was not yet known to linux.  I propose to fix that by using '?' as the
/sys/devices/virtual/atm/cxacru0/carrier value when carrier state is not yet
known to linux.  Any other value except '1' would also be OK for me.

--
Currently, just after the interface creation,
/sys/devices/virtual/atm/cxacru0/carrier gives wrong info (carrier = 1),
while actually carrier is unknown.  Fix that.

Signed-off-by: Philippe De Muyter <phdm@...qel.be>

--- a/net/atm/atm_sysfs.c	2010-02-13 22:54:04.598847195 +0100
+++ b/net/atm/atm_sysfs.c	2010-02-13 19:13:45.395308531 +0100
@@ -63,9 +63,9 @@ static ssize_t show_carrier(struct devic
 	char *pos = buf;
 	struct atm_dev *adev = to_atm_dev(cdev);
 
-	pos += sprintf(pos, "%d\n",
-		       adev->signal ==
-		       adev->signal == ATM_PHY_SIG_LOST ? 0 : 1);
+	pos += sprintf(pos, "%c\n",
+		       adev->signal == ATM_PHY_SIG_FOUND ? '1' :
+		       adev->signal == ATM_PHY_SIG_LOST ? '0' : '?');
 
 	return pos - buf;
 }
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html