Re: [PATCH]realtek:r8169: Bugfix or workaround for missing extended GigaMAC registers settings

Wang YanQing : [...] > 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 its MAC > address, so

Re: [PATCH 1/5] r8169: Remove firmware code

Hayes Wang : > Some codes are belong to binary codes and should be removed. Ok (almost). -- Ueimor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/5] r8169: Modify the method for setting firmware

Hayes Wang : > Remove useless action PHY_READ_EFUSE, and define the new action > PHY_MDIO_CHG. > > PHY_MDIO_CHG is used to modify the mdio operation. By the way, the > firmware could support setting mac ocp. > [...] > diff --git a/drivers/net/ethernet/realtek/r8169.c > b/drivers/net/ethernet/re

Re: [PATCH 4/5] r8169: Update the RTL8111G parameters

Hayes Wang : > - replace rtl8168g-1.fw with rtl8168g-2.fw which support new method. > - fix PHY power down is useless. > - disable rx early which causes the rx abnormal. > - fix the conflict between jumbo frame and flow control. > > Signed-off-by: Hayes Wang It seems ok. -- Ueimor -- To unsub

Re: [PATCH 5/5] r8169: fix could not dump registers

Hayes Wang : > For new version of Fedora and Ubuntu, we see all 0xff when dumping > the hw regs through ethtool. Using a loop to read registers could > fix it. /me wonders... Will I be wrong if I reformulate so as to outline the role of 4 bytes aligned accesses when walking the registers area ?

Re: [PATCH 1/5] r8169: Remove firmware code

David Miller : [...] > Francois please review this series, thanks. It does not seem wrong but I'll give it a try before sending a pull request. -- Ueimor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordo

Re: [3.8-rc] regression: NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out

Jörg Otte : [...] > To Summarize: Two net-regressions where introduced in v3.8 (driver r8169): > > 1) NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out > was introduced by commit > e0c075577965d1c01b30038d38bf637b027a1df3 > ("r8169: enable ALDPS for power saving") Hayes Wang authored it

Re: [GIT] Networking

- 1 file changed, 19 insertions(+), 67 deletions(-) Shortlog Francois Romieu (2): Revert "r8169: enable ALDPS for power saving". Revert "r8169: enable internal ASPM and clock request settings". Patch - diff --git a/drivers/net/ethernet/realtek/

Re: [PATCH v2] r8169: fix auto speed down issue

Hayes Wang : > It would cause no link after suspending or shutdowning when the > nic changes the speed to 10M and connects to a link partner which > forces the speed to 100M. > > Check the link partner ability to determine which speed to set. > > Signed-off-by: Hayes Wang

Re: [PATCH v2 net-next 6/8] r8169: add a new chip for RTL8111G

Hayes Wang : > Add a new chip for RTL8111G series. It does not need any of the workarounds in patch #5, right ? -- Ueimor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.o

Re: [PATCH net-next 5/7] r8169: add a new chip for RTL8111G

hayeswang : > Francois Romieu [mailto:rom...@fr.zoreil.com] [...] > > There is close to zero added value for this stuff in the kernel. > > You may as well move it completely into the firmware. > > Do you mean all of the phy settings ? I have checked these settings with >

Re: [PATCH v2 net-next 6/8] r8169: add a new chip for RTL8111G

hayeswang : [...] > Excuse me, I don't sure what is your question. Do you mean if the patch > "[PATCH v2 net-next 5/8] r8169: Update the RTL8111G parameters" is necessary > before the current patch? According to the settings from our hw engineers, > some settings of the new chip are the same with

Re: [PATCH v2 net-next 1/8] r8169: Remove firmware code

David Miller : [...] > I see there is still some discussion about dependencies between > patch #5 and #6, is that resolved? Yes. > If so, should I just apply this series as-is ? Yes. - the series is imho -stable unfriendly: whoever wants to figure what should be fed into a -stable branch wil

Re: [PATCH] NET/PHY: Eliminate the algorithm of forced ethernet speed reduction

Kirill Kapranov : > NET/PHY: Eliminate the forced speed reduction algorithm. > In case of the fixed speed set up for NIC > (e.g. ethtool -s eth0 autoneg off speed 100 duplex full) > with ethernet cable plugged off, mentioned algorithm > slows down NIC speed, so the further "hooking up" gives > no

Re: kernel 3.2.27 on arm: WARNING: at mm/page_alloc.c:2109 __alloc_pages_nodemask+0x1d4/0x68c()

David Madore : [...] > I imagine it being somehow related to the fact that it operates a > network bridge (I imagine this because I have another identical > machine with exactly the same kernel and a very similar config but not > running a bridge, and the warning never pops up). Could it not be a

Re: kernel 3.2.27 on arm: WARNING: at mm/page_alloc.c:2109 __alloc_pages_nodemask+0x1d4/0x68c()

David Madore : [...] > [ 268.976317] ieee80211 phy0: failed to reallocate TX buffer > [ 716.880515] ieee80211 phy0: failed to reallocate TX buffer > [ 1160.877677] ieee80211 phy0: failed to reallocate TX buffer > > Could they be related? Yes. This is a pskb_expand_head failure from net/mac8021

Re: [PATCH v3] net: add new QCA alx ethernet driver

cj...@qca.qualcomm.com : [...] > diff --git a/drivers/net/ethernet/atheros/alx/alx.h > b/drivers/net/ethernet/atheros/alx/alx.h > new file mode 100644 > index 000..2b4ecc1 > --- /dev/null > +++ b/drivers/net/ethernet/atheros/alx/alx.h [...] > +#define ALX_VLAN_TO_TAG(_vlan, _tag) \ > + do

Re: kernel 3.2.27 on arm: WARNING: at mm/page_alloc.c:2109 __alloc_pages_nodemask+0x1d4/0x68c()

Hugh Dickins : > [ Cc'ing original mail to netdev as the problem may be recognized there ] [...] > Francois is right that a GFP_ATOMIC allocation from pskb_expand_head() > is failing, which can easily happen, and cause your "failed to reallocate > TX buffer" errors; but it's well worth looking up

Re: [git patches] net driver fixes

Sam Ravnborg <[EMAIL PROTECTED]> : [...] > > -static struct pci_device_id sis190_pci_tbl[] __devinitdata = { > > +static struct pci_device_id sis190_pci_tbl[] = { > > { PCI_DEVICE(PCI_VENDOR_ID_SI, 0x0190), 0, 0, 0 }, > > { PCI_DEVICE(PCI_VENDOR_ID_SI, 0x0191), 0, 0, 1 }, > > { 0, }, >

Re: [PATCH] sis190: fix compile error section type conflict

your s-o-b to it ? Subject: [PATCH] sis190: fix section type conflict The driver already contains __devinitdata which is not const. Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]> Signed-off-by: Francois Romieu <[EMAIL PROTECTED]> Cc: Michael D. Setzer II <[EMAIL PROTECTED]> Cc:

Re: [PATCH 2/20 V2] drivers/net/ethernet/natsemi/natsemi.c: fix error return code

but returns non negative value, > making it difficult for a caller function to notice the error. Ok. natsemi_probe1() forgets to return a negative status code in one of its failure paths. [...] > Signed-off-by: Peter Senna Tschudin Acked-by: Francois Romieu -- Ueimor -- To unsubscr

Re: [PATCH net-next 1/2] r8169: enable ALDPS for power saving

hayeswang : [...] > The flag is determined if the firmware is loaded. It doesn't mean to enable > ALDPS. Besides ALDPS, the firmware includes the other features about power > saving, performance, hw behavior, and so on. Thus, I think it is the extended > feature. Any suggestion? RTL_FEATURE_FW_L

Re: [PATCH v2 net-next 1/2] r8169: enable ALDPS for power saving

Hayes Wang : > Enable ALDPS function to save power when link down. Note that the > feature should be set after the other PHY settings. And the firmware > is necessary. Don't enable it without loading the firmware. > > Signed-off-by: Hayes Wang [...] Please see my just sent answer in yesterday's

Re: [PATCH v2 net-next 2/2] r8169: update the settings for RTL8111G

Hayes Wang : > Update the parameters of RTL8111G I am Jack's Broken Heart. :o/ In a not too distant future somebody may try to figure if things should be fed into one of the numerous -stable trees. He will appreciate figuring from the comment if this commit is supposed to fix anything or if it's

Re: [PATCH net-next 1/2] r8169: enable ALDPS for power saving

hayeswang : > Francois Romieu [mailto:rom...@fr.zoreil.com] > [...] > > It would be nice to state these things in the commit message, namely: > > - ALDPS should never be enabled for the RTL8105e > > - none of the firmware-free chipsets support ALDPS > > -

Re: [PATCH v3 net-next] r8169: enable ALDPS for power saving

er do the > RTL8168d/8111d. > > For 8136 series, make sure the ALDPS is disabled before loading the > firmware. For 8168 series, the ALDPS would be disabled automatically > when loading firmware. You must not disable it directly. > > Signed-off-by: Hayes Wang Acked-by: Francois

Re: [PATCH net-next] r8169: enable internal ASPM and clock request settings

Hayes Wang : > The following chips need to enable internal settings to let ASPM > and clock request work. No objection, you know better than me. [...] > @@ -5145,7 +5146,10 @@ static void rtl_hw_start_8168g_1(struct > rtl8169_private *tp) > > RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb); >

Re: [PATCH v2] r8169: Fix WoL on RTL8168d/8111d.

Cyril Brulebois : > This regression was spotted between Debian squeeze and Debian wheezy > kernels (respectively based on 2.6.32 and 3.2). More info about > Wake-on-LAN issues with Realtek's 816x chipsets can be found in the > following thread: http://marc.info/?t=13207921944 David, please ap

Re: [PATCH v2 net-next] r8169: enable internal ASPM and clock request settings

David Miller : [...] > Francois? Please apply. Thanks. -- Ueimor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://ww

Re: [2/3][PATCH][v2] TDM Framework

sand...@freescale.com : [...] > The main functions of this Framework are: > - provides interface to TDM clients to access TDM functionalities. > - provides standard interface for TDM drivers to hook with the framework. > - handles various data handling stuff and buffer management. > > In futur

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

Thanasis : > on 09/21/2012 02:20 AM Francois Romieu wrote the following: [...] > > Thanasis, can you narrow down a bit the failing revision ? > > Sure, let me know how to do it please. A rough kernel estimate had been enough. Nevermind. You will find a hopefully not too quick

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

Thanasis : [...] > Hmm, think I got it ... Here is what I put there: > > ifconfig eth0 192.168.0.19 up ; ping -c 3 192.168.0.1 If it fails with the r8169 driver included in the 3.5 tree, that's what you can use, yes (you may add a second ping with -q -f -l and more packets to wrap the descriptor

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

Thanasis : > So far, ping has failed *only* at this iteration of the make loop: Ok. Without the usual netdev watchdog message I presume ? [...] > Now, after 74 iterations, it looks as if the loop is stuck at the following: > > HEAD is now at 1ce4b16 r8169: spinlock redux. > make -C /lib/module

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

Thanasis : > on 09/21/2012 11:29 PM Francois Romieu wrote the following: [...] > What message? What do you mean "the usual netdev watchdog message"? No, this one (see your 3.5.4 kernel log): [ 23.712058] WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x121/0x1a3(

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

Thanasis : > Attached the whole log so far. > (the process looks stuck anyway for more than 30 min at the same point) You don't need to wait that long. I have updated git://violet.fr.zoreil.com/romieu/r8169 with a '3.2.r8169.backport' branch. You can remove your existing r8169 git tree, clone t

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

Thanasis : [...] > I don't know what's wrong, but I am getting those errors. > Are you sure about the git tree? Yes. Replace 'git rev-list --all' with 'git rev-list --branches'. It should show something like: $ git rev-list --branches a65a9b5d9c4569228909e36bb6e20d33fe208950 35417352eeec6fcfcb92

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

Thanasis : [...] > Ping failed in the following step: > > HEAD is now at 3c6ad46 r8169: move rtl_set_rx_mode before its > rtl_hw_start callers. *spleen* It's a genuine code move without any real change. Imho it's more a matter of sleeping a few seconds for the link to settle after the device is

Re: [PATCH] r8169: Fix WoL on RTL8168d/8111d.

Cyril Brulebois : > This regression was spotted between Debian squeeze and Debian wheezy > kernels (respectively based on 2.6.32 and 3.2). The fix was inspired > by , using > RTL_GIGA_MAC_VER_{25,26} for the RTL8168d/8111d chipset. If someone ex

Re: [PATCH] r8169: Fix WoL on RTL8168d/8111d.

Cyril Brulebois : [...] > Thanks. Should I re-send with that as reference, or will you amend the > patch once you're done with your testing? It would be nice to resend, directly to netdev and davem. Shutdown Wol behaved as expected with 3.7-rc3 for both cards: unicast WoL failed without the patc

Re: [BUG] Regression in 2fdac010 drivers/net/ethernet/via/via-velocity.c: update napi implementation

Julia Lawall : [...] > There has already been a discussion about this, and a patch has already > been proposed. It has to do with lock managament. I will look for the > email. The underlying problem has to do with disabled irq. netif_receive_skb assumes irq to be enabled. Current via-velocity

Re: [PATCH net-next] r8169: add a new chip for RTL8411

David Miller : [...] > Francois, please review. The style is consistent with the driver. The commit message may state that this 8411 chipset does not require any special action in rtl_link_chg_patch (whence differing from the previous "F" 8411). Most of the code shared by rtl_hw_start_8168g_2 a

Re: [REGRESSION][BISECTED] skge: add dma_mapping check

Igor Gnatenko : > Since 136d8f377e1575463b47840bc5f1b22d94bf8f63 commit we have kernel > panic on: > 01:05.0 Ethernet controller [0200]: Marvell Technology Group Ltd. > > Screen: https://www.dropbox.com/s/mu3t3wxpxbn4ou5/IMAG0507.jpg > > RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1008323

Re: [PATCH] stable_kernel_rules.txt: Exclude networking from stable rules

Joe Perches : [...] > diff --git a/Documentation/stable_kernel_rules.txt > b/Documentation/stable_kernel_rules.txt > index b0714d8..a2d6da0 100644 > --- a/Documentation/stable_kernel_rules.txt > +++ b/Documentation/stable_kernel_rules.txt > @@ -29,6 +29,11 @@ Rules on what kind of patches are acc

Re: [PATCH] stable_kernel_rules.txt: Exclude networking from stable rules

Joe Perches : [...] > David selects them regardless. > > from Documentation/networking/netdev-FAQ.txt: I don't believe that those who read Documentation/stable_kernel_rules.txt will magically read networking/netdev-FAQ.txt as well nor figure that while they should not mark the patches stables (s

Re: [PATCH] USB2NET : SR9700 : One Chip USB 1.1 USB2NET SR9700 Device Driver Support

- use all columns - the driver uses both 'netdev' and 'net'. Let's use 'netdev' ('net' is shorter but it tastes of network namespaces) - don't dereference dev->net when there is a local netdev at hand - use some existing #define (please check those) - skb_set_tail_pointer to avoid compiler cast w

Re: [PATCH] USB2NET : SR9700 : One Chip USB 1.1 USB2NET SR9700 Device Driver Support

Liu, please check those. --- drivers/net/usb/sr9700.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/net/usb/sr9700.c b/drivers/net/usb/sr9700.c index 3f05b35..3ae3caf 100644 --- a/drivers/net/usb/sr9700.c +++ b/drivers/net/usb/sr9700.c @@ -99,8 +99,9 @@ static i

Re: [PATCH] USB2NET : SR9700 : One Chip USB 1.1 USB2NET SR9700 Device Driver Support

Keep it small though literate. --- drivers/net/usb/sr9700.c | 30 -- 1 file changed, 12 insertions(+), 18 deletions(-) diff --git a/drivers/net/usb/sr9700.c b/drivers/net/usb/sr9700.c index f7f46e6..3f05b35 100644 --- a/drivers/net/usb/sr9700.c +++ b/drivers/net/usb/s

Re: network stopped with a kernel error

Roberto Spadim : [...] > ethtool show eth2 and eth1 as up and running and eth2 as fibre but > it's a TP board?! It happens with old model r8169 boards that go south during netdev whatchdog recovery handler. Please send the XID line included in dmesg output at startup. > i'm considering eth2 a b

Re: [PATCH v3]realtek:r8169: Bugfix or workaround for missing extended GigaMAC registers settings

Wang YanQing : [...] > @@ -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 > +

Re: [PATCH net-next 1/2] r8169: enable ALDPS for power saving

Hayes Wang : > Enable ALDPS function to save power when link down. Note that the > feature should be set after the other PHY settings. And the firmware > is necessary. Don't enable it without loading the firmware. > > Signed-off-by: Hayes Wang > --- > drivers/net/ethernet/realtek/r8169.c | 46

Re: [3.0.y, 3.2.y, 3.4.y] Re: [PATCH v2] r8169: Fix WoL on RTL8168d/8111d.

Jonathan Nieder : [...] > This has been applied as commit b00e69dee4cc in mainline; thanks! > > Fran??ois and David, would this be a candidate for inclusion in > 3.0- and newer stable kernels? - 3.0.51 b00e69dee4ccbb3a19989e3d4f1385bc2e3406cd aee77e4accbeb2c86b1d294cd84fec4a12dde3bd - 3.4.1

Re: [PATCH 1/1] r8169: Removed unused macros from r8169.c

Dayanidhi Sreenivasan : [...] I have fixed the conflict with the driver in net-next due to removal of the SafeMtu #define and pushed the result in branch davem-next.r8169 at git://violet.fr.zoreil.com/romieu/linux Next time you send a patch, please specify the branch it should apply to and check

Re: [3.8-rc] regression: NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out

Jörg Otte : [...] > It's a regression, it never happend before 3.8-rc. Please check that 'dmesg | grep XID' exhibits a 8168evl. I'll showe and dig it. It's epidemic. -- Ueimor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.

Re: [3.8-rc] regression: NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out

Jörg Otte : [...] > jojo@ahorn:~$ dmesg | grep XID > [1.808847] r8169 :02:00.0 eth0: RTL8168evl/8111evl at > 0xc9054000, 5c:9a:d8:69:2b:39, XID 0c900800 IRQ 42 Can you check if things improve with v3.8-rc2 after removing : 1. 9ecb9aabaf634677c77af467f4e3028b09d7bcda r8169: wo

Re: 3.7.0 does not detect Realtek network card automatically

Björn Christoph : [...] > Not sure what to do here. It's an Ubuntu kernel - should I take the > one from the kernel GIT, compile it and activate some debugging or > something to assist? You should try to reproduce the problem with the kernel included r8169 driver and report any problem with it to

Re: [PATCH v3] ethernet/arc/arc_emac - Add new driver

Andy Shevchenko : [...] > I just realize you are using circular buffer here. What about to use > them with linux' native framework? Documentation/circular-buffers.txt It's almost unused in drivers/net. I won't mind if it stays this way. -- Ueimor -- To unsubscribe from this list: send the line

Re: [PATCH v3] ethernet/arc/arc_emac - Add new driver

Alexey Brodkin : [...] > diff --git a/drivers/net/ethernet/arc/arc_emac.h > b/drivers/net/ethernet/arc/arc_emac.h > new file mode 100644 > index 000..6691db2 > --- /dev/null > +++ b/drivers/net/ethernet/arc/arc_emac.h [...] > +struct arc_emac_priv { > + struct net_device_stats stats; > +

Re: [PATCH v3] ethernet/arc/arc_emac - Add new driver

Alexey Brodkin : > On 06/14/2013 02:20 AM, Francois Romieu wrote: [...] > >> +struct arc_emac_priv { > >> + struct net_device_stats stats; > >> + unsigned int clock_frequency; > >> + unsigned int max_speed; > >> + > >> + /* Pointers to

Re: [PATCH v3] ethernet/arc/arc_emac - Add new driver

Alexey Brodkin : [...] > If my comment doesn't make sense to you or I misunderstood your message > could you please add more clarifications for your idea? Sorry, I temporarily forgot it was the descriptor ring itself. :o/ It would make sense to qualify the descriptor members as __{le/be}32 then

Re: hanging, and possible exploit/ddos from LAN for RTL and other cards (watchdog netdev)

opensou...@tigusoft.pl : [...] > Thanks for helping to debug and find this problem: tigusoft.pl , #grsecurity > , > Arach , Admin2501 , R.Freeman > > > We await any instructions how to debug this further. Please send the XID of Realtek devices you own ('dmesg | grep XID'). r8169 support leve

Re: [ 104/136 ] r8169: fix 8168evl frame padding.

Steven Rostedt : [...] > I'm working on 3.6.11.5. Has the fix for the regression been pulled into > mainline yet, and if so, what's the commit SHA1? It's in mainline as b423e9ae49d78ea3f53b131c8d5a6087aed16fd6 but davem has not sent it into -stable yet. -- Ueimor -- To unsubscribe from this lis

Re: hanging, and possible exploit/ddos from LAN for RTL and other cards (watchdog netdev)

opensou...@tigusoft.pl : > On Sunday 16 June 2013 18:39:21 Francois Romieu wrote: > > Thank you for feedback. We provide XID, IRQ and additional info below. Executive summary: 1. affected Realtek nics are 8168evl (XID 0c900800) and an old PCI (XID 1800) 2. failing marvell nic r

Re: [PATCH v2] ethernet/arc/arc_emac - Add new driver

Alexey Brodkin : [...] > diff --git a/drivers/net/ethernet/arc/arc_emac_main.c > b/drivers/net/ethernet/arc/arc_emac_main.c > new file mode 100644 > index 000..f098a27 > --- /dev/null > +++ b/drivers/net/ethernet/arc/arc_emac_main.c > @@ -0,0 +1,956 @@ > +/* > + * Copyright (C) 2004, 2007-201

Re: [PATCH v2] ethernet/arc/arc_emac - Add new driver

Alexey Brodkin : > On 06/08/2013 12:33 AM, Francois Romieu wrote: > > Alexey Brodkin : [...] > As replied to Joe I just want to name people contributed in this driver. > What is a appropriate way to do it? A polite way could be to see with contributors if it's ok for them

Re: [PATCH net-next v2 1/3] net/usb/r8152: support aggregation

Hayes Wang : [...] > diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c > index 11c51f2..abb0b9f 100644 > --- a/drivers/net/usb/r8152.c > +++ b/drivers/net/usb/r8152.c [...] > @@ -315,13 +318,34 @@ struct tx_desc { > u32 opts2; > }; > > +struct rx_agg { > + struct list_hea

Re: [PATCH net-next v2 1/3] net/usb/r8152: support aggregation

hayeswang : > Francois Romieu [mailto:rom...@fr.zoreil.com] [...] > > The forward declaration is not needed. > > The r8152_submit_rx() need the declaration of read_bulk_callback(), and the > read_bulk_callback() need the declaration of r8152_submit_rx(), too. It likes > a

Re: Kernel summit 2013: Call for Hobbyists

Theodore Ts'o : [...] > To apply, please send a proposal outlining what you do, what you'd bring > to the kernel summit An umbrella to start with. :o) While the (highly variable amount of) kernel work I do is intellectually rewarding at times, it's not exactly the kind of cool or important thing

Re: [PATCHv2] net: cpsw: Add support for wake-on-lan for cpsw

ujhely...@gmail.com : [...] > Some phy's can be configured to enable wake on lan (e.g. at803x or marvell > 88E1318S). > There is no way how to enable wol on CPSW with such connected phys. This patch > adds this support. It is provided by calling the phy's related code. > > Tested on board with a

Re: [PATCH-SR9700] Merge USB 1.1 Ethernet Adapter SR9700 Device Driver into the Linux Kernel

liujunliang_ljl : [...] > We want to merge SR9700 device driver into the Linux Kernel. The following > is the Linux 3.10.7 version patch for SR9700, Please give us the assessment > and support. Welcome. Go ahead. [...] > diff --git a/drivers/net/usb/sr9700.c b/drivers/net/usb/sr9700.c > new file

Re: Networking problem with 3.11-rc6+

Chris Clayton : [...] > [0.207094] acpi PNP0A08:00: ACPI _OSC support notification failed, > disabling PCIe ASPM > [0.207155] acpi PNP0A08:00: Unable to request _OSC control (_OSC support > mask: 0x08) [...] > [5.311191] r8169 :07:00.0: can't disable ASPM; OS doesn't have ASPM >

Re: [ATTEND] oops.kernel.org prospect

Anton Arapov : [...] > Oh well,... I didn't have a time for this right now, nor project is > not exactly in the state I'm willing to show (mostly webui) I have sorted the r8169 oopses by kernel revision to start with the most recent kernels. I don't get why the r8169 driver appears in the "Cause

Re: Re: [PATCH-SR9700] Merge USB 1.1 Ethernet Adapter SR9700 DeviceDriver into the Linux Kernel

if (sr_skb) { if (!sr_skb) return 0; > + sr_skb->len = len; > + sr_skb->data = skb->data + 3; > + sr_skb->tail = skb->data + len; > + sr_skb->

Re: [PATCH 1/1] net/velocity: add poll controller function for velocity nic

Amit Uttamchandani : > Add poll controller function for velocity nic. Thanks. You did not state if it was tested. Was it ? -- Ueimor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://v

Re: question about netif_rx

Julia Lawall : > To my limited understanding, in a NAPI polling function, one should use > netif_receive_skb, rather than netif_rx. Nit: or napi_gro_receive (+ napi_gro_flush with __napi_complete) when the device offers some checksum offloading features. > However, the via-velocity driver defin

Re: question about netif_rx

Julia Lawall : > François Romieu : [...] > > Can you send a netif_receive_skb replacement patch for it ? > > Just to be sure, I just replace netif_rx by netif_receive_skb, nothing > else? Yes. It should imho be fine with a comment incluing your analysis and a few words about the current state o

Re: question about netif_rx

David Shwatrz : [...] > what is the current state of checksum offloading support has to do > with it ? maybe you meant current state of NAPI support ? netif_receive_skb vs napi_gro_receive choice. -- Ueimor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body o

Re: question about netif_rx

(no top-post nor lazy quote please) David Shwatrz : [...] > In the napi_gro_receive() we check that the device supports > NETIF_F_GRO, but I don't see that we inspect checksum or that > NETIF_F_GRO is depends on checksum. napi_gro_receive is irrelevant. Let aside tunnel, the real work happens in

Re: r8169 on 3.8.13, 3.9.2, 3.10-rc1, was Re: [ 00/73] 3.8.13-stable review

Ken Moffat : [...] > Cc'ing to netdev because I don't think this has had a response, and A patch has been sent to netdev a few hours ago. It needs more work, especially testing (hint, hint) as I don't have a proven test case yet. Please note: - if you don't use a 8168evl (check your dmesg for t

Re: AMD Vi error and lost networking with r8169

David R : > I'm been seeing some problems with my new ish AMD motherboard/processor > combo and networking (r8169). I see the following page fault :- > > Apr 7 12:25:14 david kernel: [156421.436545] AMD-Vi: Event logged > [IO_PAGE_FAULT device=02:00.0 domain=0x0015 address=0x3000 > f

Re: [GIT] Networking

Linus Torvalds : [...] > Any ideas? 1a9646497b163a8b9da5e70008d809dc91b32855 ("r8169: adjust the flow of hw_start"), eee3786f7d3134e3edc54c1134511d520dd74285 ("r8169: Modify the method for setting firmware") and 0427d0152eb3c2c2712afa427dd593c68fc09299 ("r8169: Remove firmware code") may play a r

Re: net: phy: realtek: add rtl8201f driver

Jongsung Kim : > This patch adds the minimal driver to manage the > Realtek RTL8201F 10/100Mbps Transceivers. Your patch contains both "remove unused #define" and "support new hardware" parts. I am not sure that the former is adequate for submission until net-next opens. > diff --git a/drivers/n

Re: VIA velocity network driver

Tony Prisk : > I would like to add support to this driver for platform devices as > found on VIA's APC8750 board. At the moment, I have a standalone > platform version that works fine, but wanted to ask a few questions > before sending a patch to merge this code into one driver. > > The current d

Re: [PATCHv3 3/3] net: velocity: Add platform device support to VIA velocity driver

Tony Prisk : [...] > +static int velocity_remove(void *pdev, enum velocity_bus_type bustype) > +{ > + struct net_device *netdev; > + struct velocity_info *vptr; > + int pci = (bustype == BUS_PCI) ? 1 : 0; > + > + if (pci) > + netdev = pci_get_drvdata(pdev); > + else

Re: [ 104/136 ] r8169: fix 8168evl frame padding.

Steven Rostedt : > 3.6.11.4 stable review patch. > If anyone has any objections, please let me know. You should postpone it until the fix for a regression it induces when user enable Tx checksumming is merged. -- Ueimor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel"

Re: [PATCHv8 3/3] net: velocity: Add platform device support to VIA velocity driver

Tony Prisk : [...] > diff --git a/drivers/net/ethernet/via/via-velocity.c > b/drivers/net/ethernet/via/via-velocity.c > index 5996cee..d8d5bc5 100644 > --- a/drivers/net/ethernet/via/via-velocity.c > +++ b/drivers/net/ethernet/via/via-velocity.c [...] > @@ -84,6 +88,16 @@ > static int velocity_n

Re: [PATCH 1/5] drivers: net: usb: rtl8150: bug fixing and cleanup

Petko Manolov : > From: Petko Manolov > > Moving constant and structure definitions out of rtl8150.c; What's the point ? [...] > --- > drivers/net/usb/rtl8150.c | 121 +-- > 1 file changed, 2 insertions(+), 119 deletions(-) > > diff --git a/drivers/net/usb/rt

Re: [PATCH 3/5] drivers: net: usb: rtl8150: bug fixing and cleanup

Petko Manolov : [...] > diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c > index 7d1897b..fd4bc2a 100644 > --- a/drivers/net/usb/rtl8150.c > +++ b/drivers/net/usb/rtl8150.c [...] > static void rx_fixup(unsigned long data) > { > struct rtl8150 *dev = (struct rtl8150 *)data

Re: [PATCH 4/5] drivers: net: usb: rtl8150: bug fixing and cleanup

Petko Manolov : [...] > static int set_registers(rtl8150_t * dev, u16 indx, u16 size, void *data) > { > - return usb_control_msg(dev->udev, usb_sndctrlpipe(dev->udev, 0), > -RTL8150_REQ_SET_REGS, RTL8150_REQT_WRITE, > -indx, 0, data, si

Re: [PATCH 5/5] drivers: net: usb: rtl8150: bug fixing and cleanup

Petko Manolov : [...] > @@ -681,16 +681,15 @@ static int rtl8150_ioctl(struct net_device *netdev, > struct ifreq *rq, int cmd) > } > > static const struct net_device_ops rtl8150_netdev_ops = { > - .ndo_open = rtl8150_open, > - .ndo_stop = rtl8150_close, > -

Re: [PATCH 0/5] drivers: net: usb: rtl8150: bug fixing and code cleanup

Petko Manolov : [...] > This patch series adds rtl8150.h, which contains structure and constant > definitons formerly found in rtl8150.c, removes socket buffer > pre-allocated pool and uses dynamically allocated memory for the > asynchronous URB requests, thus avoids clobbering the previously s

Re: [PATCH 1/5] drivers: net: usb: rtl8150: bug fixing and cleanup

Petko Manolov : > On Sat, 18 May 2013, Francois Romieu wrote: > > > From: Petko Manolov [...] > > > Moving constant and structure definitions out of rtl8150.c; > > > > What's the point ? > > The general logic of having .h files applies. Which

Re: [PATCH 4/5] drivers: net: usb: rtl8150: bug fixing and cleanup

Petko Manolov : [...] > > > + usb_fill_control_urb(async_urb, dev->udev, > > > + usb_sndctrlpipe(dev->udev, 0), (void *) &req->dr, > > > > Useless void * cast. > > Wrong. The compiler actually moans quite a lot: > > /usr/src/git/rtl8150/rtl8150.c: In function ?async_set_re

Re: [Patch v2] skbuff: Hide GFP_ATOMIC page allocation failures for dropped packets

atom...@redhat.com : [...] > Failed GFP_ATOMIC allocations by the network stack result in dropped > packets, which will be received on a subsequent retransmit, and an > unnecessary, noisy warning with a kernel backtrace. > > These warnings are harmless, but they still cause users to panic and > f

Re: r8169 auto speed down issue

hayeswang : [...] > Do you have any suggestion about this? Your description suggests that testing against the link partner ability to work at 10M instead of testing for tp->link_ok could be good enough. Does it make sense ? -- Ueimor -- To unsubscribe from this list: send the line "unsubscribe

Re: r8169 auto speed down issue

hayeswang : > Francois Romieu [mailto:rom...@fr.zoreil.com] > [...] > > Your description suggests that testing against the link > > partner ability to work at 10M instead of testing for ^^ -> "and" > > tp->link_

Re: r8169 auto speed down issue

hayeswang : [...] > Sorry for my unclear descriptor. I just think a case that the nic suspends or > shutdowns without cable plugging. Then, the cable is plugged again. If the nic > speed down to 10M and the link partner force 100M, the issue appears again. If > the nic doesn't speed down for norma

Re: [PATCH] r8169: fix auto speed down issue

Hayes Wang : [...] > diff --git a/drivers/net/ethernet/realtek/r8169.c > b/drivers/net/ethernet/realtek/r8169.c > index 28fb50a..a9eedf7 100644 > --- a/drivers/net/ethernet/realtek/r8169.c > +++ b/drivers/net/ethernet/realtek/r8169.c > @@ -3818,6 +3818,21 @@ static void rtl_init_mdio_ops(struct r

Re: [PATCH net-next 2/7] r8169: Update PHY settings of RTL8111G

Hayes Wang : > - Replace the current settings with rtl_writephy and rtl_readphy. > For the hardware, the settings are same with previous ones. This > make the setting method like the previous chips. > - Add new PHY settings. Would you mind spliting it in two ? On closer inspection the settin

Re: [PATCH net-next 5/7] r8169: add a new chip for RTL8111G

Hayes Wang : [...] > diff --git a/drivers/net/ethernet/realtek/r8169.c > b/drivers/net/ethernet/realtek/r8169.c > index 0211836..8d41508 100644 > --- a/drivers/net/ethernet/realtek/r8169.c > +++ b/drivers/net/ethernet/realtek/r8169.c [...] > +static void rtl8168g_2_hw_phy_config(struct rtl8169_pr

Re: [PATCH net-next 6/7] r8169: add a new chip for RTL8106E

Hayes Wang : [...] > - move rtl_set_rx_tx_desc_registers to avoid the tx/rx are enabled > before setting desc registers. This is a wholesale change for the 810x family. Please explain why issuing rtl_set_rx_tx_desc_registers before writing ChipCmd is not enough and feed it through a standalone

  1   2   3   4   5   >