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:	Thu, 25 Jun 2009 01:39:45 +0400
From:	Anton Vorontsov <cbouatmailru@...il.com>
To:	Andy Fleming <afleming@...escale.com>
Cc:	David Miller <davem@...emloft.net>,
	Kumar Gala <galak@...nel.crashing.org>,
	Li Yang <leoli@...escale.com>, linuxppc-dev@...abs.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH] gianfar: Fix half-duplex operation for non-MII/RMII
	interfaces

On Wed, Jun 24, 2009 at 04:25:06PM -0500, Andy Fleming wrote:
[...]
>>> My concern is that you will be detecting the GMII interface, and
>>> disallowing half-duplex, despite the fact that the interface is  
>>> actually
>>> running at 10 or 100 Mbit.
>>
>> Very interesting, though I'm not sure I'm completely following. :-)
>>
>> Are you saying that I should do this instead:
>>
>> 	if (!phydev->duplex &&
>> 			(phyi == PHY_INTERFACE_MODE_MII ||
>> 			 phyi == PHY_INTERFACE_MODE_RMII ||
>> 			 (phyi == PHY_INTERFACE_MODE_GMII &&
>> 			  phydev->speed < 1000)))
>> 		tempval &= ~MACCFG2_FULL_DUPLEX;
>> 	else
>> 		tempval |= MACCFG2_FULL_DUPLEX;
>>
>> i.e. we detected GMII interface initially, but it downgraded
>> to MII since speed is < 1000, thus we can set half-duplex in MAC?
>
> Yeah, I think that works out more correctly.

Cool, thanks.

Do you happen to know how gianfar iface auto-detection works in HW?
I mean, if we connect 100 Mbs link to the GMII PHY, then
gfar_get_interface() would return MII, correct?

If so, then I think I'll also have to change
	phy_interface_t phyi = phydev->interface;
to
	phy_interface_t phyi = gfar_get_interface(dev);
since phydev->interface may contain outdated information.

Or this can't happen?

> And I suspect that the  same is true for UCC

Yup. Much thanks for catching this!

-- 
Anton Vorontsov
email: cbouatmailru@...il.com
irc://irc.freenode.net/bd2
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ