openslx-ng/ipxe.git/src/drivers, branch masterFork of ipxe; additional commands and featureshttps://git.openslx.org/openslx-ng/ipxe.git/atom/src/drivers?h=master2019-03-18T10:24:08+00:00[intel] Add PCI ID for I219-V and -LM 6 to 92019-03-18T10:24:08+00:00Christian Nilsson2019-02-14T21:21:55+00:00urn:sha1:ebf2eaf515e46abd43bc798e7e4ba77bfe529218
Signed-off-by: Christian Nilsson <nikize@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[init] Show startup and shutdown function names in debug messages2019-01-25T14:53:43+00:00Michael Brown2019-01-25T14:53:43+00:00urn:sha1:36a4c85f911c85f5ab183331ff74d125f9a9ed32
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[sfc] Add support for X25xx adapters2018-08-26T21:02:23+00:00Martin Habets2018-06-18T10:41:38+00:00urn:sha1:af1860711a3823202a4ddee0ddfb9814591f506c
The first adapters in this family are X2522-10, X2522-25, X2541 and
X2542.
These no longer use PCI BAR 0 for I/O, but use that for memory. In
other words, BAR 2 on SFN8xxx adapters now becomes BAR 0.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[intelxl] Add driver for Intel 40 Gigabit Ethernet NICs2018-07-17T11:14:43+00:00Michael Brown2018-07-08T15:41:12+00:00urn:sha1:d2063b7693e0e35db97b2264aa987eb6341ae779
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[ethernet] Use standard 1500 byte MTU unless explicitly overridden2018-07-17T11:14:43+00:00Michael Brown2018-07-17T11:01:30+00:00urn:sha1:b9d68b9de02cc474c8a713f1232ce69fefafe18e
Devices that support jumbo frames will currently default to the
largest possible MTU. This assumption is valid for virtual adapters
such as virtio-net, where the MTU must have been configured by a
system administrator, but is unsafe in the general case of a physical
adapter.
Default to the standard Ethernet MTU, unless explicitly overridden
either by the driver or via the ${netX/mtu} setting.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[intelx] Add support for Intel X552 NIC2018-07-07T19:05:25+00:00Steven Haber2018-05-10T23:12:32+00:00urn:sha1:97a3d37285ed367c8ee55fe51c3186be0aa8f320
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[icplus] Add driver for IC+ network card2018-04-20T14:26:09+00:00Sylvie Barlow2018-04-20T13:10:26+00:00urn:sha1:960d1e36b09803b291803ab336412f7d95349568
Signed-off-by: Sylvie Barlow <sylvie.c.barlow@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[mii] Add bit-bashing interface2018-04-20T14:24:33+00:00Sylvie Barlow2018-04-20T12:58:40+00:00urn:sha1:c239f0bff2496cefa5e9d3ef6b232f5d28a04d70
Signed-off-by: Sylvie Barlow <sylvie.c.barlow@gmail.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[mii] Add mii_find()2018-04-20T14:21:32+00:00Sylvie Barlow2018-04-20T12:37:20+00:00urn:sha1:7ed1dc98c325f5d5934fb9806307e0638735304a
Add the function mii_find() in order to locate the PHY address.
Signed-off-by: Sylvie Barlow <sylvie.c.barlow@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[mii] Separate concepts of MII interface and MII device2018-04-19T11:43:06+00:00Michael Brown2018-04-19T11:38:55+00:00urn:sha1:6804a8c89b8c31c3ef4e7e8ab03b82ebee41dd45
We currently have no generic concept of a PHY address, since all
existing implementations simply hardcode the PHY address within the
MII access methods.
A bit-bashing MII interface will need to be provided with an explicit
PHY address in order to generate the correct waveform. Allow for this
by separating out the concept of a MII device (i.e. a specific PHY
address attached to a particular MII interface).
Signed-off-by: Michael Brown <mcb30@ipxe.org>