From patchwork Fri Nov 30 23:21:52 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wang YanQing X-Patchwork-Id: 203078 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 431682C0082 for ; Sat, 1 Dec 2012 10:21:49 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756342Ab2K3XV3 (ORCPT ); Fri, 30 Nov 2012 18:21:29 -0500 Received: from mail-da0-f46.google.com ([209.85.210.46]:35376 "EHLO mail-da0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756326Ab2K3XV1 (ORCPT ); Fri, 30 Nov 2012 18:21:27 -0500 Received: by mail-da0-f46.google.com with SMTP id p5so419667dak.19 for ; Fri, 30 Nov 2012 15:21:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:mime-version :content-type:content-disposition:user-agent; bh=YNc6yFvWpulBula7+7FKqeatsizprkOVz5KBxid8LXc=; b=DpOpMcZXrB0W5AWxk71Golc7w24gmrYF6opovWkVyUDxnwVuvnzuflnlBkzYltBrE1 7PeoiN2rnILi0pYD/4fio+d3oMkVTmHKXEDXsacTUdAWHzEuZjuEBAu4dNFYAEN6FZlH GiQECxvDNwDEBYSCaFaxz7wdDuWSFs52CcDf3ZG4yKQLfVmNLSVbmN6477n1QfVV1/Yd q+OX/d+VVpbEN6lSZN2SoRoHNTwST/jUM3whYgwGUK4emF2ja5MFJBFF7KpiBxrv4q1q 9kO8Ah5e4NextUv6DneYC/A4WNcOpPFA5VmnhfZJze54tr8YcQwLuYqkJso8sm6nNTTN tAXQ== Received: by 10.68.203.198 with SMTP id ks6mr9727636pbc.35.1354317687168; Fri, 30 Nov 2012 15:21:27 -0800 (PST) Received: from udknight.localhost ([120.42.73.37]) by mx.google.com with ESMTPS id o11sm3727134pby.8.2012.11.30.15.21.23 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Nov 2012 15:21:26 -0800 (PST) Received: from udknight.localhost (udknight.localhost [127.0.0.1]) by udknight.localhost (8.14.4/8.14.4) with ESMTP id qAUNLsn0011425; Sat, 1 Dec 2012 07:21:54 +0800 Received: (from root@localhost) by udknight.localhost (8.14.4/8.14.4/Submit) id qAUNLqmR011419; Sat, 1 Dec 2012 07:21:52 +0800 Date: Sat, 1 Dec 2012 07:21:52 +0800 From: Wang YanQing To: nic_swsd@realtek.com Cc: romieu@fr.zoreil.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3]realtek:r8169: Bugfix or workaround for missing extended GigaMAC registers settings Message-ID: <20121130232152.GA10960@udknight> Mail-Followup-To: Wang YanQing , nic_swsd@realtek.com, romieu@fr.zoreil.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org I get a board with 8168e-vl(10ec:8168 with RTL_GIGA_MAC_VER_34), everything looks well first, I can use ifconfig to set ip, netmask, etc. And the rx/tx statistics show by ifconfig looks good when I ping another host or ping it from another host. But it don't work, I can't get ICMP REPLAY from both sides, although the RX/TX statistics seem good. After add some debug code, I found this NIC only accept ethernet broadcast package, it can't filter out the package send to its MAC address, but it works good for sending.So ifconfig show the RX/TX status means it can receive ARP package.(It don't know its MAC address, so below) I have try the driver provided by realtek's website, it have the same problem at the first time. BUT IT WORK AFTER I REBOOT with CRTL-ALT-DEL, the reason is that realtek's driver call rtl8168_rar_set in the .shutdown function register with pci_register_driver. Yes, the really reason to make it work is rtl8689_rar_set, this function set extended GigaMAC registers, so after reboot without lost the power, NIC keep the status before reboot. I haven't see any code to set GigaMAC registers in kernel when boot, so I guess BIOS or NIC's circuit make it, but of course one miss the extended GigaMAC registers in this problem. The probe code can get MAC address right, so MAC{0,4} must had been setted, but some guys forget the extended GigaMAC registers. This patch fix it. [ I don't known whether others' realtek's NIC with extended GigaMAC reigisters have the same problem, I meet it in 8168e-vl with RTL_GIGA_MAC_VER_34, so I make this patch just for it.] Changes: V1-V2: I follow Francois Romieu 's below opinion to make this patch oneline: I'd rather see the GigaMAC registers written through a call to rtl_rar_set when the mac address is read in rtl_init_one instead of duplicating most of rtl_rar_set in a quite different place. V2-V3: 1:Add conditon code to around this fix, because it make no sense for most NIC 2:Add comment in code Signed-off-by: Wang YanQing --- drivers/net/ethernet/realtek/r8169.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c index 927aa33..5d98296 100644 --- a/drivers/net/ethernet/realtek/r8169.c +++ b/drivers/net/ethernet/realtek/r8169.c @@ -6903,6 +6903,14 @@ rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) dev->dev_addr[i] = RTL_R8(MAC0 + i); memcpy(dev->perm_addr, dev->dev_addr, dev->addr_len); + /* + *This is a fix for BIOS forget to set + *extend GigaMAC registers + *Wang YanQing 12/1/2012 + */ + if (tp->mac_version == RTL_GIGA_MAC_VER_34) { + rtl_rar_set(tp, dev->dev_addr); + } SET_ETHTOOL_OPS(dev, &rtl8169_ethtool_ops); dev->watchdog_timeo = RTL8169_TX_TIMEOUT;