netdev - Re: [PATCH] [9/11] pasemi_mac: clear out old errors on interface open

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 for Android: free password hash cracker in your pocket

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

Message-ID: <4703DC5C.2030602@pobox.com>
Date:	Wed, 03 Oct 2007 14:15:56 -0400
From:	Jeff Garzik <jgarzik@...ox.com>
To:	Olof Johansson <olof@...om.net>
CC:	netdev@...r.kernel.org, linuxppc-dev@...abs.org
Subject: Re: [PATCH] [9/11] pasemi_mac: clear out old errors on interface
 open

Olof Johansson wrote:
> On Wed, Oct 03, 2007 at 01:46:16PM -0400, Jeff Garzik wrote:
>> Olof Johansson wrote:
>>> pasemi_mac: clear out old errors on interface open
>>> Clear out any pending errors when an interface is brought up. Since the 
>>> bits
>>> are sticky, they might be from interface shutdown time after firmware has
>>> used it, etc.
>>> Signed-off-by: Olof Johansson <olof@...om.net>
>> In general, interface-open should completely reset and initialize the 
>> hardware.  does pasemi_mac not do that?
> 
> There's no explicit way to reset just one interface besides disabling it
> (which we do at close, and re-enable at open). It seems that some of
> the error bits are sticky across disable/enable, which is why this was
> needed. Also, they're RW1C, so writing 0 doesn't remove them (need to
> write 1 to clear).

OK just making sure, thanks.


> The only other dependency from firmware at this time is the setting of mac
> addresses, something that will be taken care of once we allow override of
> them via ethtool, since we'd need to program them from the driver then
> no matter what. Right now we assume that firmware has programmed it.

Standard procedure for this is

* upon module-load, obtain the MAC address from <whatever canonical source>
* upon interface-up, program dev->dev_addr[] into chip's RX filter (aka 
MAC address) registers

That permits the admin to override the MAC address via ifconfig. 
(ethtool doesn't support that, but you basically had the right idea)

	Jeff


-
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