<feed xmlns='http://www.w3.org/2005/Atom'>
<title>src/sys/dev/alc, branch release/8.1.0</title>
<subtitle>FreeBSD source tree</subtitle>
<id>https://cgit-dev.freebsd.org/src/atom?h=release%2F8.1.0</id>
<link rel='self' href='https://cgit-dev.freebsd.org/src/atom?h=release%2F8.1.0'/>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src/'/>
<updated>2010-04-26T18:02:12Z</updated>
<entry>
<title>MFC r206876:</title>
<updated>2010-04-26T18:02:12Z</updated>
<author>
<name>Pyun YongHyeon</name>
<email>yongari@FreeBSD.org</email>
</author>
<published>2010-04-26T18:02:12Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src/commit/?id=ed0af45af3e0c82120c0d0054e93cb61849a6074'/>
<id>urn:sha1:ed0af45af3e0c82120c0d0054e93cb61849a6074</id>
<content type='text'>
  With r206844, CSUM_TCP is also set for CSUM_TSO case. Modify
  drivers to take into account for the change. Basically CSUM_TSO
  should be checked before checking CSUM_TCP.
</content>
</entry>
<entry>
<title>MFC r204228,204230:</title>
<updated>2010-03-23T19:41:43Z</updated>
<author>
<name>Pyun YongHyeon</name>
<email>yongari@FreeBSD.org</email>
</author>
<published>2010-03-23T19:41:43Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src/commit/?id=061d3abfa8a3a4f955e7458556a08fdd6e28e5f5'/>
<id>urn:sha1:061d3abfa8a3a4f955e7458556a08fdd6e28e5f5</id>
<content type='text'>
r204228:
  Add TSO support on VLANs. Also make sure to update TSO capability
  whenever jumbo frame is configured.
  While I'm here remove unnecessary check of VLAN hardware checksum
  offloading. vlan(4) already takes care of this.

r204230:
  Remove Tx mbuf parsing code for VLAN in TSO path. Controller does
  not support TSO over VLAN if VLAN hardware tagging is disabled so
  there is no need to check VLAN here.
</content>
</entry>
<entry>
<title>MFC 197627.</title>
<updated>2009-11-29T19:29:11Z</updated>
<author>
<name>Pyun YongHyeon</name>
<email>yongari@FreeBSD.org</email>
</author>
<published>2009-11-29T19:29:11Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src/commit/?id=4a288ceae972d693d12e4c741ec2128d34191a8c'/>
<id>urn:sha1:4a288ceae972d693d12e4c741ec2128d34191a8c</id>
<content type='text'>
  Fix multicast handling. All Atheros controllers use big-endian form
  in computing multicast hash.

  PR:	kern/139137
</content>
</entry>
<entry>
<title>MFC 197600.</title>
<updated>2009-11-29T19:25:15Z</updated>
<author>
<name>Pyun YongHyeon</name>
<email>yongari@FreeBSD.org</email>
</author>
<published>2009-11-29T19:25:15Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src/commit/?id=621838143bd7f4b6fbf8da683e313a4d95dd69a8'/>
<id>urn:sha1:621838143bd7f4b6fbf8da683e313a4d95dd69a8</id>
<content type='text'>
  For AR8132 fast ethernet controller, do not report 1000baseT
  capability to mii(4). Even though AR8132 uses the same model/
  revision number of F1 gigabit PHY, the PHY has no ability to
  establish 1000baseT link. I have no idea why Atheros use the same
  device/model id for this PHY.
  With this change atphy(4) does not report 1000baseT media
  capability and manual 1000baseT configuration is also disabled
  which is more desirable behavior for 10/100Mbps PHY.
</content>
</entry>
<entry>
<title>MFC r196517:</title>
<updated>2009-08-28T18:01:37Z</updated>
<author>
<name>Pyun YongHyeon</name>
<email>yongari@FreeBSD.org</email>
</author>
<published>2009-08-28T18:01:37Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src/commit/?id=180e7945c70b5a7d6d29559026c7c675a01ff138'/>
<id>urn:sha1:180e7945c70b5a7d6d29559026c7c675a01ff138</id>
<content type='text'>
  Don't try to power down PHY when alc(4) failed to map the device.
  This fixes system crash when mapping alc(4) device failed in device
  attach.

  Reported by:	Jim &lt; stapleton.41 &lt;&gt; gmail DOT com &gt;
Approved by:	re (kib)
</content>
</entry>
<entry>
<title>Free allocated Rx ring dma memory/tags.</title>
<updated>2009-07-31T09:57:42Z</updated>
<author>
<name>Kevin Lo</name>
<email>kevlo@FreeBSD.org</email>
</author>
<published>2009-07-31T09:57:42Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src/commit/?id=6ece67d83f287ae88f473bad995ee9f7a0c38ae9'/>
<id>urn:sha1:6ece67d83f287ae88f473bad995ee9f7a0c38ae9</id>
<content type='text'>
Reviewed by: yongari@
Approved by: re (kib)
</content>
</entry>
<entry>
<title>Use if_maddr_rlock()/if_maddr_runlock() rather than IF_ADDR_LOCK()/</title>
<updated>2009-06-26T11:45:06Z</updated>
<author>
<name>Robert Watson</name>
<email>rwatson@FreeBSD.org</email>
</author>
<published>2009-06-26T11:45:06Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src/commit/?id=eb956cd041f956275522092d6ba66671356ff84f'/>
<id>urn:sha1:eb956cd041f956275522092d6ba66671356ff84f</id>
<content type='text'>
IF_ADDR_UNLOCK() across network device drivers when accessing the
per-interface multicast address list, if_multiaddrs.  This will
allow us to change the locking strategy without affecting our driver
programming interface or binary interface.

For two wireless drivers, remove unnecessary locking, since they
don't actually access the multicast address list.

Approved by:	re (kib)
MFC after:	6 weeks
</content>
</entry>
<entry>
<title>Add alc(4), a driver for Atheros AR8131/AR8132 PCIe ethernet</title>
<updated>2009-06-10T02:07:58Z</updated>
<author>
<name>Pyun YongHyeon</name>
<email>yongari@FreeBSD.org</email>
</author>
<published>2009-06-10T02:07:58Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src/commit/?id=d68875eb7ef724ab00ea64abe44a9a0f15ae7484'/>
<id>urn:sha1:d68875eb7ef724ab00ea64abe44a9a0f15ae7484</id>
<content type='text'>
controller. These controllers are also known as L1C(AR8131) and
L2C(AR8132) respectively. These controllers resembles the first
generation controller L1 but usage of different descriptor format
and new register mappings over L1 register space requires a new
driver. There are a couple of registers I still don't understand
but the driver seems to have no critical issues for performance and
stability. Currently alc(4) supports the following hardware
features.
  o MSI
  o TCP Segmentation offload
  o Hardware VLAN tag insertion/stripping
  o Tx/Rx interrupt moderation
  o Hardware statistics counters(dev.alc.%d.stats)
  o Jumbo frame
  o WOL
AR8131/AR8132 also supports Tx checksum offloading but I disabled
it due to stability issues. I'm not sure this comes from broken
sample boards or hardware bugs. If you know your controller works
without problems you can still enable it. The controller has a
silicon bug for Rx checksum offloading, so the feature was not
implemented.
I'd like to say big thanks to Atheros. Atheros kindly sent sample
boards to me and answered several questions I had.

HW donated by:	Atheros Communications, Inc.
</content>
</entry>
</feed>
