openslx-ng/ipxe.git/src/drivers, branch v1.20.1

[snp] Set EFI_SIMPLE_NETWORK_RECEIVE_MULTICAST bit as per UEFI spec

2019-12-16T10:46:04+00:00

According to UEFI specification 2.8 p 24.1 we must set the EFI_SIMPLE_NETWORK_RECEIVE_MULTICAST bit in the "Disable" mask, when "ResetMCastFilter" is TRUE. Signed-off-by: Ignat Korchagin Split-by: Michael Brown Signed-off-by: Michael Brown

[snp] Try promiscuous multicast receive filter if the regular one fails

2019-12-16T10:42:09+00:00

Currently, if the SNP driver for whatever reason fails to enable receive filters for multicast frames, it falls back to enabling just unicast and broadcast filters. This breaks some IPv6 functionality as the network card does not respond to neighbour solicitation requests. Some cards refuse to enable EFI_SIMPLE_NETWORK_RECEIVE_MULTICAST, but do support enabling EFI_SIMPLE_NETWORK_RECEIVE_PROMISCUOUS_MULTICAST, so try it before falling back to just unicast+broadcast. Signed-off-by: Ignat Korchagin Split-by: Michael Brown Signed-off-by: Michael Brown

[lan78xx] Always enable automatic speed and duplex detection

2019-09-29T19:59:22+00:00

On devices with no EEPROM or OTP, the MAC_CR register defaults to not using automatic link speed detection, with the result that no packets are successfully sent or received. Fix by always enabling automatic speed and duplex detection, since iPXE provides no mechanism for manual configuration of either link speed or duplex. Signed-off-by: Michael Brown

[efi] Do not attempt EFI_USB_IO_PROTOCOL transfers during shutdown

2019-09-15T09:40:23+00:00

On at least some platforms (observed with a Raspberry Pi), any attempt to perform USB transfers via EFI_USB_IO_PROTOCOL during EFI shutdown will lock up the system. This is quite probably due to the already documented failure of all EFI timers when ExitBootServices() is called: see e.g. commit 5cf5ffea2 "[efi] Work around temporal anomaly encountered during ExitBootServices()". Work around this problem by refusing to poll endpoints if shutdown is in progress, and by immediately failing any attempts to enqueue new transfers. Signed-off-by: Michael Brown

[efi] Report failed control transfers as expected by the USB core

2019-09-15T09:25:46+00:00

The USB core reuses the I/O buffer space occupied by the USB setup packet to hold the completion status for message transfers, assuming that the message() method will always strip the setup packet before returning. This assumption is correct for all of the hardware controller drivers (XHCI, EHCI, and UHCI), since these drivers are able to enqueue the transfer as a separate action from waiting for the transfer to complete. The EFI_USB_IO_PROTOCOL does not allow us to separate actions in this way: there is only a single blocking method that both enqueues and waits for completion. Our usbio driver therefore currently defers stripping the setup packet until the control endpoint is polled. This causes a bug if a message transfer is enqueued but never polled and is subsequently cancelled, since the cancellation will be reported with the I/O buffer still containing the setup packet. This breaks the assumption that the setup packet has been stripped, and triggers an assertion failure in usb_control_complete(). Fix by always stripping the setup packet in usbio_endpoint_message(), and adjusting usbio_control_poll() to match. Signed-off-by: Michael Brown

[golan] Fix address-of-pointer bug for multicast attach/detach

2019-08-17T16:51:18+00:00

Signed-off-by: Michael Brown

[smscusb] Fetch MAC from device tree for Raspberry Pi Model B+

2019-07-19T18:15:33+00:00

Signed-off-by: Michael Brown

[smsc95xx] Fetch MAC from device tree for Raspberry Pi

2019-07-19T16:44:27+00:00

Signed-off-by: Michael Brown

[golan] Add various new PCI device IDs

2019-05-02T10:00:18+00:00

Signed-off-by: Mohammed Signed-off-by: Michael Brown

[intelxl] Add driver for Intel 40 Gigabit Ethernet NIC virtual functions

2019-04-27T19:26:18+00:00

Signed-off-by: Michael Brown