Re: Bug#561309: firmware-linux-nonfree: needs firmware for module r8169 (/rtl8168d-{1, 2}.fw)

["Stefan Lippers-Hollmann" <s.L-H@gmx.de>]

Hi

On Saturday 19 December 2009, Ben Hutchings wrote:
> It seems RTL8168D version 1 (but not version 2) was previously supported
> without the need for this firmware update (rtl8168d-1.fw).  So perhaps
> the driver should carry on without it if it is missing.  Please try
> applying the following patch, which implements that behaviour.
[...]

This works for me, although it delays the system boot for 60s - waiting 
for the non-existing firmware file to appear. Maybe the module should 
additionally complain if the firmware couldn't be found or allow some other
method to avoid waiting for a non-existing firmware image?

$ dmesg | grep -i -e firmware -e eth0 -e 8169 -e 8168
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
r8169 0000:01:00.0: setting latency timer to 64
r8169 0000:01:00.0: irq 28 for MSI/MSI-X
eth0: RTL8168d/8111d at 0xf7c6e000, 00:1c:c0:ee:22:88, XID 081000c0 IRQ 28
r8169 0000:01:00.0: firmware: requesting rtl8168d-1.fw
r8169: eth0: link up
r8169: eth0: link up
eth0: no IPv6 routers present

[...]
> diff -u b/drivers/net/r8169.c b/drivers/net/r8169.c
> --- b/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
[...]
> @@ -1801,15 +1796,15 @@
>  	mdio_plus_minus(ioaddr, 0x02, 0x0100, 0x0600);
>  	mdio_plus_minus(ioaddr, 0x03, 0x0000, 0xe000);
>  
> -	rtl_phy_write_fw(ioaddr, fw);
> -
> -	release_firmware(fw);
> -	return 0;
> +	if (request_firmware(&fw, "rtl8168d-1.fw", &tp->pci_dev->dev) == 0) {
> +		rtl_phy_write_fw(ioaddr, fw);
> +		release_firmware(fw);
	} else {
		printk(KERN_INFO "%s: "
		       "Failed to load rtl8168d-1.fw.\n", dev->name);
> +	}
>  }
>  
>  MODULE_FIRMWARE("rtl8168d-1.fw");
>  
> -static int rtl8168d_2_hw_phy_config(struct rtl8169_private *tp)
> +static void rtl8168d_2_hw_phy_config(struct rtl8169_private *tp)
>  {
>  	static struct phy_reg phy_reg_init_0[] = {
>  		{ 0x1f, 0x0001 },
[...]
perhaps?

Would it be possible to provide some kind of firmware-cutter, to let the 
user generate the required firmwares from a vanilla kernel checkout on the 
target system, if needed (and if no copyright statement can be achieved)?

Regards
	Stefan Lippers-Hollmann