Bug#564628: [PATCH] net/r8169: Correct the ram code for RTL8111D(L)
On Tue, 30 Nov 2010 00:33:34 +0100 Francois Romieu rom...@fr.zoreil.com wrote: hayeswang hayesw...@realtek.com : Excuse me, I have some questions about the firmware patch. 1. I should convert the data into the binary files (.bin). Is it right? You may do it. Fwiw I have cooked something for it in the attached patch #9 this WE. Feel free to take bits from it. I will not do more changes while you work on it. 2. Where should I update the firmware files? Is the path the linux-2.6/firmware? ! This directory is only here to contain firmware images extracted from old ! device drivers which predate the common use of request_firmware(). It is fine for the existing code. However, according to linux-2.6/firmeware/README.AddingFirmware, I should update they to another repository: git://git.kernel.org/pub/scm/linux/kernel/git/dwmw2/linux-firmware.git /me scratches head. Assuming Realtek does not intend to stand this code / data as GPLable, yes. It will help people staying clear from non-free code, it will help packaging something useful and it will remove some cruft from the code. So everybody will end happy. Especially after an aspirin. The plan is to do away with linux-2.6/firmware entirely. Distributions are shipping the firmware from linux-firmware, not the kernel files. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564628: [PATCH] net/r8169: Correct the ram code for RTL8111D(L)
Hi Romieu, Let me explain that not all of the phy settings are the ram code (or firmware). Some of them are the initialization sequence. Only the Low pass filter DLY_CAP fine tune from uC is the firmware. And there is no firmware before RTL8111D. That is, except 8111DP, the chips which have firmware are 8111d, 8111e,and 8105 now. Now, I would modify my patch according to the example from Ben. And I would update the firmware and licence to linux-firmware. Thanks for everybody who help and answer to me. Best Regards, Hayes -Original Message- From: Stephen Hemminger [mailto:shemmin...@vyatta.com] Sent: Tuesday, November 30, 2010 8:14 AM To: Francois Romieu Cc: Hayeswang; 'Ben Hutchings'; net...@vger.kernel.org; linux-ker...@vger.kernel.org; 'David Miller'; 564...@bugs.debian.org Subject: Re: [PATCH] net/r8169: Correct the ram code for RTL8111D(L) On Tue, 30 Nov 2010 00:33:34 +0100 Francois Romieu rom...@fr.zoreil.com wrote: hayeswang hayesw...@realtek.com : Excuse me, I have some questions about the firmware patch. 1. I should convert the data into the binary files (.bin). Is it right? You may do it. Fwiw I have cooked something for it in the attached patch #9 this WE. Feel free to take bits from it. I will not do more changes while you work on it. 2. Where should I update the firmware files? Is the path the linux-2.6/firmware? ! This directory is only here to contain firmware images extracted from old ! device drivers which predate the common use of request_firmware(). It is fine for the existing code. However, according to linux-2.6/firmeware/README.AddingFirmware, I should update they to another repository: git://git.kernel.org/pub/scm/linux/kernel/git/dwmw2/linux-firmware.g it /me scratches head. Assuming Realtek does not intend to stand this code / data as GPLable, yes. It will help people staying clear from non-free code, it will help packaging something useful and it will remove some cruft from the code. So everybody will end happy. Especially after an aspirin. The plan is to do away with linux-2.6/firmware entirely. Distributions are shipping the firmware from linux-firmware, not the kernel files. --Please consider the environment before printing this e-mail. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564628: [PATCH] net/r8169: Correct the ram code for RTL8111D(L)
Excuse me, I have some questions about the firmware patch. 1. I should convert the data into the binary files (.bin). Is it right? 2. Where should I update the firmware files? Is the path the linux-2.6/firmeware? However, according to linux-2.6/firmeware/README.AddingFirmware, I should update they to another repository: git://git.kernel.org/pub/scm/linux/kernel/git/dwmw2/linux-firmware.git Then, how the firmware merge with kernel-2.6? Or, where could I find the firmware in the kernel-2.6 repository? Best Regards, Hayes -Original Message- From: Ben Hutchings [mailto:b...@debian.org] Sent: Saturday, November 27, 2010 7:12 AM To: Francois Romieu; Hayeswang Cc: net...@vger.kernel.org; linux-ker...@vger.kernel.org; David Miller; 564...@bugs.debian.org Subject: Re: [PATCH] net/r8169: Correct the ram code for RTL8111D(L) On Fri, 2010-11-26 at 23:49 +0100, Francois Romieu wrote: Ben Hutchings b...@debian.org : On Fri, 2010-11-26 at 19:54 +0800, Hayes Wang wrote: Correct the binary code (Low pass filter DLY_CAP fine tune from uC). The incorrect ram code would make the nic working abnormally. [...] I'm glad you finally acknowledge that this is code rather than simple register initialisation. I am not sure that Hayes is a native english speaker. I am glad to see him posting here. Right. Hayes, by 'you' I meant Realtek, not you personally. If my reply seemed aggressive, I apologise. [...] Below are the changes Debian currently applies in preparation for proper licencing of the firmware. Do you have some scripts to convert the data at hand ? [...] No, it's easy enough to convert a single array by copying it into a C file that dumps it to stdout (assuming the file's byte order is defined to match your own machine). It might be worth adding some sort of header with a version and checksum. Your choice, really. Ben. -- Ben Hutchings, Debian Developer and kernel team member -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564628: [PATCH] net/r8169: Correct the ram code for RTL8111D(L)
On Fri, 2010-11-26 at 19:54 +0800, Hayes Wang wrote:
Correct the binary code (Low pass filter DLY_CAP fine tune from uC).
The incorrect ram code would make the nic working abnormally.
[...]
I'm glad you finally acknowledge that this is code rather than simple
register initialisation.
Please can you put the microcontroller firmware under a suitable
licence, if you are not intending to release its source code. The GPL
is not suitable as it requires distributions to provide the source code;
that makes the firmware strictly undistributable at present.
An example licence for binary-only redistribution is:
Copyright date company
Permission is hereby granted for the distribution of this firmware
data in hexadecimal or equivalent format, provided this copyright
notice is accompanying it.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/r8169.c | 141
+--
1 files changed, 113 insertions(+), 28 deletions(-)
mode change 100644 = 100755 drivers/net/r8169.c
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
old mode 100644
new mode 100755
[...]
Also, please don't add execute permission to source files.
Below are the changes Debian currently applies in preparation for proper
licencing of the firmware.
Ben.
---
Subject: [PATCH] r8169: remove firmware for RTL8169D PHY
The recently added support for RTL8169D chips included some machine
code without accompanying source code. Replace this with use of the
firmware loader.
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
drivers/net/r8169.c | 717 ---
1 files changed, 44 insertions(+), 673 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 7d33ef4..bfc251a 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -24,6 +24,7 @@
#include linux/init.h
#include linux/dma-mapping.h
#include linux/pm_runtime.h
+#include linux/firmware.h
#include asm/system.h
#include asm/io.h
@@ -1383,6 +1384,23 @@ static void rtl_phy_write(void __iomem *ioaddr, const
struct phy_reg *regs, int
}
}
+struct phy_reg_le {
+ __le16 reg;
+ __le16 val;
+};
+
+static void rtl_phy_write_fw(void __iomem *ioaddr, const struct firmware *fw)
+{
+ const struct phy_reg_le *regs = (const struct phy_reg_le *)fw-data;
+ size_t len = fw-size / sizeof(*regs);
+
+ while (len-- 0) {
+ mdio_write(ioaddr, le16_to_cpu(regs-reg),
+ le16_to_cpu(regs-val));
+ regs++;
+ }
+}
+
static void rtl8169s_hw_phy_config(void __iomem *ioaddr)
{
static const struct phy_reg phy_reg_init[] = {
@@ -1715,7 +1733,7 @@ static void rtl8168c_4_hw_phy_config(void __iomem *ioaddr)
rtl8168c_3_hw_phy_config(ioaddr);
}
-static void rtl8168d_1_hw_phy_config(void __iomem *ioaddr)
+static void rtl8168d_1_hw_phy_config(struct rtl8169_private *tp)
{
static const struct phy_reg phy_reg_init_0[] = {
{ 0x1f, 0x0001 },
@@ -1743,361 +1761,8 @@ static void rtl8168d_1_hw_phy_config(void __iomem
*ioaddr)
{ 0x05, 0x8332 },
{ 0x06, 0x5561 }
};
- static const struct phy_reg phy_reg_init_2[] = {
- { 0x1f, 0x0005 },
- { 0x05, 0xffc2 },
- { 0x1f, 0x0005 },
- { 0x05, 0x8000 },
- { 0x06, 0xf8f9 },
- { 0x06, 0xfaef },
- { 0x06, 0x59ee },
- { 0x06, 0xf8ea },
- { 0x06, 0x00ee },
- { 0x06, 0xf8eb },
- { 0x06, 0x00e0 },
- { 0x06, 0xf87c },
- { 0x06, 0xe1f8 },
- { 0x06, 0x7d59 },
- { 0x06, 0x0fef },
- { 0x06, 0x0139 },
- { 0x06, 0x029e },
- { 0x06, 0x06ef },
- { 0x06, 0x1039 },
- { 0x06, 0x089f },
- { 0x06, 0x2aee },
- { 0x06, 0xf8ea },
- { 0x06, 0x00ee },
- { 0x06, 0xf8eb },
- { 0x06, 0x01e0 },
- { 0x06, 0xf87c },
- { 0x06, 0xe1f8 },
- { 0x06, 0x7d58 },
- { 0x06, 0x409e },
- { 0x06, 0x0f39 },
- { 0x06, 0x46aa },
- { 0x06, 0x0bbf },
- { 0x06, 0x8290 },
- { 0x06, 0xd682 },
- { 0x06, 0x9802 },
- { 0x06, 0x014f },
- { 0x06, 0xae09 },
- { 0x06, 0xbf82 },
- { 0x06, 0x98d6 },
- { 0x06, 0x82a0 },
- { 0x06, 0x0201 },
- { 0x06, 0x4fef },
- { 0x06, 0x95fe },
- { 0x06, 0xfdfc },
- { 0x06, 0x05f8 },
- { 0x06, 0xf9fa },
- { 0x06, 0xeef8 },
- { 0x06, 0xea00 },
- { 0x06, 0xeef8 },
- { 0x06, 0xeb00 },
-
Bug#564628: [PATCH] net/r8169: Correct the ram code for RTL8111D(L)
Ben Hutchings b...@debian.org : On Fri, 2010-11-26 at 19:54 +0800, Hayes Wang wrote: Correct the binary code (Low pass filter DLY_CAP fine tune from uC). The incorrect ram code would make the nic working abnormally. [...] I'm glad you finally acknowledge that this is code rather than simple register initialisation. I am not sure that Hayes is a native english speaker. I am glad to see him posting here. [...] Below are the changes Debian currently applies in preparation for proper licencing of the firmware. Do you have some scripts to convert the data at hand ? I would welcome a clear statement regarding the status of the binary thing (code ? data ?) but even without one *now*, I'd like to see it separated from the main code : the driver sucks and things will go worse with support code for the 8168e. Is there anybody objecting to it ? I will buy anything be it firmware API or plain .h. -- Ueimor -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564628: [PATCH] net/r8169: Correct the ram code for RTL8111D(L)
On Fri, 2010-11-26 at 23:49 +0100, Francois Romieu wrote: Ben Hutchings b...@debian.org : On Fri, 2010-11-26 at 19:54 +0800, Hayes Wang wrote: Correct the binary code (Low pass filter DLY_CAP fine tune from uC). The incorrect ram code would make the nic working abnormally. [...] I'm glad you finally acknowledge that this is code rather than simple register initialisation. I am not sure that Hayes is a native english speaker. I am glad to see him posting here. Right. Hayes, by 'you' I meant Realtek, not you personally. If my reply seemed aggressive, I apologise. [...] Below are the changes Debian currently applies in preparation for proper licencing of the firmware. Do you have some scripts to convert the data at hand ? [...] No, it's easy enough to convert a single array by copying it into a C file that dumps it to stdout (assuming the file's byte order is defined to match your own machine). It might be worth adding some sort of header with a version and checksum. Your choice, really. Ben. -- Ben Hutchings, Debian Developer and kernel team member signature.asc Description: This is a digitally signed message part
