* Re: [PATCH (net.git)] net: phy: rtl8211: fix interrupt on status link change
From: David Miller @ 2013-08-21 0:11 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1376894914-11174-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Mon, 19 Aug 2013 08:48:34 +0200
> This is to fix a problem in the rtl8211 where the driver
> wasn't properly enabled the interrupt on link change status.
> it has to enable the ineterrupt on the bit 10 in the register 18
> (INER).
>
> Reported-by: Sharma Bhupesh <B45370@freescale.com>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] sh_eth: remove 'register_type' field from 'struct sh_eth_plat_data'
From: David Miller @ 2013-08-21 0:05 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev, lethal, linux-sh
In-Reply-To: <201308180313.26607.sergei.shtylyov@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Sun, 18 Aug 2013 03:13:26 +0400
> Now that the 'register_type' field of the 'sh_eth' driver's platform data is not
> used by the driver anymore, it's time to remove it and its initializers from
> the SH platform code. Also move *enum* declaring values for this field from
> <linux/sh_eth.h> to the local driver's header file as they're only needed
> by the driver itself now...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] sh_eth: get register layout from 'struct sh_eth_cpu_data'
From: David Miller @ 2013-08-21 0:05 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev, linux-sh
In-Reply-To: <201308180311.28814.sergei.shtylyov@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Sun, 18 Aug 2013 03:11:28 +0400
> The register layout is a SoC characteristic, so it's wrong that it's stored
> in the otherwise board specific platform data. Add 'register_type' field to
> 'struct sh_eth_cpu_data', initialize it properly for each SoC, and read it
> from this structure instead of the platfrom data from now on...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] SolutionEngine7724: fix Ether support
From: David Miller @ 2013-08-21 0:05 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev, lethal, linux-sh
In-Reply-To: <201308180219.09528.sergei.shtylyov@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Sun, 18 Aug 2013 02:19:09 +0400
> The Ether platform data is behind the declaration of 'struct sh_eth_plat_data'
> as it's lacking the initializers for the 'register_type' and 'phy_interface'
> fields -- it means they'll be implicitly and wrongly set to SH_ETH_REG_GIGABIT
> and PHY_INTERFACE_MODE_NA. Initialize the fields explicitly and fix off-by-one
> error in the Ether memory resource end, while at it...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] SH7619: fix Ether support
From: David Miller @ 2013-08-21 0:05 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev, lethal, linux-sh
In-Reply-To: <201308180215.43063.sergei.shtylyov@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Sun, 18 Aug 2013 02:15:42 +0400
> The 'sh_eth' driver's probe will crash as the platform code is hopelessly behind
> the platform data -- it passes PHY ID instead of 'struct sh_eth_plat_data *'.
> Strangely, both commit d88a3ea6fa4c (SH7619 add ethernet controler support) that
> added the platform code and commit 71557a37adb5 ([netdrvr] sh_eth: Add SH7619
> support) were done in about the same time, yet the latter one added 'struct
> sh_eth_plat_data' and the platform code didn't ever get updated...
>
> Add the proper platform data and fix off-by-one memory resource end error, while
> at it...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Applied.
^ permalink raw reply
* Re: [PATCH (net.git) 1/2] stmmac: disable at run-time the EEE if not supported
From: David Miller @ 2013-08-21 0:04 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: peppe.cavallaro, netdev
In-Reply-To: <52126788.4060607@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Mon, 19 Aug 2013 22:44:24 +0400
>> @@ -2166,7 +2181,6 @@ static int stmmac_poll(struct napi_struct *napi,
>> int budget)
>> static void stmmac_tx_timeout(struct net_device *dev)
>> {
>> struct stmmac_priv *priv = netdev_priv(dev);
>> -
>> /* Clear Tx resources and restart transmitting again */
>
> Why? This seems unneeded change.
Agreed, not only was this code properly styled already, changing it
is totally unrelated to what this patch is supposed to be doing.
^ permalink raw reply
* Re: pull request net: 2013-08-17b
From: David Miller @ 2013-08-20 23:58 UTC (permalink / raw)
To: ordex; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <20130820.165649.385314778551035966.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 20 Aug 2013 16:56:49 -0700 (PDT)
> From: Antonio Quartulli <ordex@autistici.org>
> Date: Sat, 17 Aug 2013 13:04:44 +0200
>
>> git://git.open-mesh.org/linux-merge.git tags/batman-adv-fix-for-davem
> ...
>> Antonio Quartulli (1):
>> batman-adv: properly end seq_read session
>>
>> Linus Lüssing (1):
>> batman-adv: check return type of unicast packet preparations
>
> The change by Linus is not in that tree.
>
> When I pulled I only got the seq_rea fix.
Nevermind, in fact, I see that only Linus's unicast fix was in there,
which is what you intended.
Sorry for the false alarm.
^ permalink raw reply
* Re: pull request net: 2013-08-17b
From: David Miller @ 2013-08-20 23:56 UTC (permalink / raw)
To: ordex; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <1376737486-1863-1-git-send-email-ordex@autistici.org>
From: Antonio Quartulli <ordex@autistici.org>
Date: Sat, 17 Aug 2013 13:04:44 +0200
> git://git.open-mesh.org/linux-merge.git tags/batman-adv-fix-for-davem
...
> Antonio Quartulli (1):
> batman-adv: properly end seq_read session
>
> Linus Lüssing (1):
> batman-adv: check return type of unicast packet preparations
The change by Linus is not in that tree.
When I pulled I only got the seq_rea fix.
^ permalink raw reply
* Re: pull request net: 2013-08-17
From: David Miller @ 2013-08-20 23:55 UTC (permalink / raw)
To: ordex; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <1376735694-676-1-git-send-email-ordex@autistici.org>
From: Antonio Quartulli <ordex@autistici.org>
Date: Sat, 17 Aug 2013 12:34:53 +0200
> here you have another very small fix intended for net/linux-3.11.
> Tha patch properly closes a seq_read session by adding an invocation to
> skb_abort_seq_read().
>
> Please pull or let me know if there is any problem.
Pulled thanks.
> Also, when do you plan to merge net into net-next? I have a couple of changes
> for net-next which is better to apply after the merge.
I did one the other day. I'll probably do one the next time I merge
changes to Linus, say Thursday some time.
^ permalink raw reply
* Re: [PATCH] r8169: remember WOL preferences on driver load
From: David Miller @ 2013-08-20 23:48 UTC (permalink / raw)
To: romieu; +Cc: lekensteyn, netdev, nic_swsd, hayeswang
In-Reply-To: <20130820231201.GA31154@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Wed, 21 Aug 2013 01:12:01 +0200
> David Miller <davem@davemloft.net> :
> [...]
>> > Signed-off-by: Peter Wu <lekensteyn@gmail.com>
>>
>> Can I get some reviews and Ack's for this?
>
> It's more consistent with the {get / set}_wol parts of the driver and
> it's done in a way both Hayes and myself agreed on during the previous
> messages.
>
> So you can consider it:
>
> Acked-by: Francois Romieu <romieu@fr.zoreil.com>
Thanks, applied.
^ permalink raw reply
* Re: [PATCH] r8169: remember WOL preferences on driver load
From: Francois Romieu @ 2013-08-20 23:12 UTC (permalink / raw)
To: David Miller; +Cc: lekensteyn, netdev, nic_swsd, hayeswang
In-Reply-To: <20130820.151036.1067735437451172978.davem@davemloft.net>
David Miller <davem@davemloft.net> :
[...]
> > Signed-off-by: Peter Wu <lekensteyn@gmail.com>
>
> Can I get some reviews and Ack's for this?
It's more consistent with the {get / set}_wol parts of the driver and
it's done in a way both Hayes and myself agreed on during the previous
messages.
So you can consider it:
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
--
Ueimor
^ permalink raw reply
* Re: [PATCH 2/2] sh_eth: remove 'register_type' field from 'struct sh_eth_plat_data'
From: Sergei Shtylyov @ 2013-08-20 23:01 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: netdev, davem, lethal, linux-sh
In-Reply-To: <2784326.CAqkc6T846@avalon>
On 08/21/2013 02:50 AM, Laurent Pinchart wrote:
>>>>> Now that the 'register_type' field of the 'sh_eth' driver's platform
>>>>> data is not used by the driver anymore, it's time to remove it and its
>>>>> initializers from the SH platform code. Also move *enum* declaring
>>>>> values for this field from <linux/sh_eth.h> to the local driver's
>>>>> header file as they're only needed by the driver itself now...
>>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>> [...]
>>>>> /* Driver's parameters */
>>>>> #if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE)
>>>>> #define SH4_SKB_RX_ALIGN 32
>>>>>
>>>>> Index: net-next/include/linux/sh_eth.h
>>>>> ===================================================================
>>>>> --- net-next.orig/include/linux/sh_eth.h
>>>>> +++ net-next/include/linux/sh_eth.h
>>>>> @@ -5,17 +5,10 @@
>>>>>
>>>>> #include <linux/if_ether.h>
>>>>>
>>>>> enum {EDMAC_LITTLE_ENDIAN, EDMAC_BIG_ENDIAN};
>>>>>
>>>>> -enum {
>>>>> - SH_ETH_REG_GIGABIT,
>>>>> - SH_ETH_REG_FAST_RCAR,
>>>>> - SH_ETH_REG_FAST_SH4,
>>>>> - SH_ETH_REG_FAST_SH3_SH2
>>>>> -};
>>>>>
>>>>> struct sh_eth_plat_data {
>>>>>
>>>>> int phy;
>>>>> int edmac_endian;
>>>> Wouldn't it make sense to move the edmac_endian field to sh_eth_cpu_data
>>>> as well ?
>>> No, it depends on the SoC endianness which is determined by power-on pin
>>> strapping -- which is board specific.
> Does SoC endianness affect the ARM core endianness, the ethernet registers
> endianness, or both ?
Both, AFAIK.
> If it affects the ARM core endianness only, the kernel
> needs to be compiled in little-endian or big-endian mode anyway, and the
> sh_eth driver should use cpu_to_le32() unconditionally. If it affects both the
> ARM core and the ethernet controller there's not need to care about the
> endianness, as it will always be good.
No, it won't unless you're using __raw_{readl|writel}() accessors. The
driver doesn't do it. {readl|writel}() and io{read|write}32() that use them
always assume LE ordering of memory.
> We only need to care about it if it
> affects the ethernet controller registers only, which would seem weird to me.
Unfortunately, you are wrong.
>> BTW, I don't think the driver works correctly in the BE case since it uses
>> io{read|write}32() to access the registers and those functions assume LE
>> ordering on MMIO.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 2/2] sh_eth: remove 'register_type' field from 'struct sh_eth_plat_data'
From: Laurent Pinchart @ 2013-08-20 22:50 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev, davem, lethal, linux-sh
In-Reply-To: <5213E92D.7070004@cogentembedded.com>
Hi Sergei,
On Wednesday 21 August 2013 02:09:49 Sergei Shtylyov wrote:
> On 08/20/2013 06:27 PM, Sergei Shtylyov wrote:
> >>> Now that the 'register_type' field of the 'sh_eth' driver's platform
> >>> data is not used by the driver anymore, it's time to remove it and its
> >>> initializers from the SH platform code. Also move *enum* declaring
> >>> values for this field from <linux/sh_eth.h> to the local driver's
> >>> header file as they're only needed by the driver itself now...
> >>>
> >>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> [...]
>
> >>> /* Driver's parameters */
> >>> #if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE)
> >>> #define SH4_SKB_RX_ALIGN 32
> >>>
> >>> Index: net-next/include/linux/sh_eth.h
> >>> ===================================================================
> >>> --- net-next.orig/include/linux/sh_eth.h
> >>> +++ net-next/include/linux/sh_eth.h
> >>> @@ -5,17 +5,10 @@
> >>>
> >>> #include <linux/if_ether.h>
> >>>
> >>> enum {EDMAC_LITTLE_ENDIAN, EDMAC_BIG_ENDIAN};
> >>>
> >>> -enum {
> >>> - SH_ETH_REG_GIGABIT,
> >>> - SH_ETH_REG_FAST_RCAR,
> >>> - SH_ETH_REG_FAST_SH4,
> >>> - SH_ETH_REG_FAST_SH3_SH2
> >>> -};
> >>>
> >>> struct sh_eth_plat_data {
> >>>
> >>> int phy;
> >>> int edmac_endian;
> >>
> >> Wouldn't it make sense to move the edmac_endian field to sh_eth_cpu_data
> >> as well ?
> >>
> > No, it depends on the SoC endianness which is determined by power-on pin
> > strapping -- which is board specific.
Does SoC endianness affect the ARM core endianness, the ethernet registers
endianness, or both ? If it affects the ARM core endianness only, the kernel
needs to be compiled in little-endian or big-endian mode anyway, and the
sh_eth driver should use cpu_to_le32() unconditionally. If it affects both the
ARM core and the ethernet controller there's not need to care about the
endianness, as it will always be good. We only need to care about it if it
affects the ethernet controller registers only, which would seem weird to me.
> BTW, I don't think the driver works correctly in the BE case since it uses
> io{read|write}32() to access the registers and those functions assume LE
> ordering on MMIO.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] r8169: remember WOL preferences on driver load
From: David Miller @ 2013-08-20 22:10 UTC (permalink / raw)
To: lekensteyn; +Cc: netdev, nic_swsd, hayeswang, romieu
In-Reply-To: <1376730002-9235-1-git-send-email-lekensteyn@gmail.com>
From: Peter Wu <lekensteyn@gmail.com>
Date: Sat, 17 Aug 2013 11:00:02 +0200
> From: Peter Wu <lekensteyn@gmail.com>
>
> Do not clear Broadcast/Multicast/Unicast Wake Flag or LanWake in
> Config5. This is necessary to preserve WOL state when the driver is
> loaded. Although the r8168 vendor driver does not write Config5 (it has
> been commented out), Hayes Wang from Realtek said that masking bits like
> this is more sensible.
>
> Signed-off-by: Peter Wu <lekensteyn@gmail.com>
Can I get some reviews and Ack's for this?
Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] sh_eth: remove 'register_type' field from 'struct sh_eth_plat_data'
From: Sergei Shtylyov @ 2013-08-20 22:09 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: netdev, davem, lethal, linux-sh
In-Reply-To: <52137CD5.1040902@cogentembedded.com>
Hello.
On 08/20/2013 06:27 PM, Sergei Shtylyov wrote:
>>> Now that the 'register_type' field of the 'sh_eth' driver's platform data is
>>> not used by the driver anymore, it's time to remove it and its
>>> initializers from the SH platform code. Also move *enum* declaring values
>>> for this field from <linux/sh_eth.h> to the local driver's header file
>>> as they're only needed by the driver itself now...
>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
[...]
>>> /* Driver's parameters */
>>> #if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE)
>>> #define SH4_SKB_RX_ALIGN 32
>>> Index: net-next/include/linux/sh_eth.h
>>> ===================================================================
>>> --- net-next.orig/include/linux/sh_eth.h
>>> +++ net-next/include/linux/sh_eth.h
>>> @@ -5,17 +5,10 @@
>>> #include <linux/if_ether.h>
>>>
>>> enum {EDMAC_LITTLE_ENDIAN, EDMAC_BIG_ENDIAN};
>>> -enum {
>>> - SH_ETH_REG_GIGABIT,
>>> - SH_ETH_REG_FAST_RCAR,
>>> - SH_ETH_REG_FAST_SH4,
>>> - SH_ETH_REG_FAST_SH3_SH2
>>> -};
>>>
>>> struct sh_eth_plat_data {
>>> int phy;
>>> int edmac_endian;
>> Wouldn't it make sense to move the edmac_endian field to sh_eth_cpu_data as
>> well ?
> No, it depends on the SoC endianness which is determined by power-on pin
> strapping -- which is board specific.
BTW, I don't think the driver works correctly in the BE case since it uses
io{read|write}32() to access the registers and those functions assume LE
ordering on MMIO.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next] myri10ge: Add support for ndo_busy_poll
From: David Miller @ 2013-08-20 22:09 UTC (permalink / raw)
To: hykim; +Cc: netdev
In-Reply-To: <1376902939-21968-1-git-send-email-hykim@myri.com>
From: Hyong-Youb Kim <hykim@myri.com>
Date: Mon, 19 Aug 2013 02:02:19 -0700
> Add the ndo_busy_poll handler. Use skb_mark_napi_id to mark receive
> packets with the napi id. For each slice, use per-slice spinlock and
> state variable to ensure that only one handler processes receive
> pacekts.
>
> Locking, statistics counters, and the ndo_busy_poll handler follow
> those in the ixgbe driver. So, credit goes to that driver's authors.
>
> Signed-off-by: Hyong-Youb Kim <hykim@myri.com>
Applied, but this patch had a ton of trailing whitespace which I had
to fix up.
^ permalink raw reply
* Re: [patch -next] ipip: dereferencing an ERR_PTR in ip_tunnel_init_net()
From: David Miller @ 2013-08-20 22:08 UTC (permalink / raw)
To: dan.carpenter
Cc: nicolas.dichtel, kuznet, jmorris, yoshfuji, kaber, netdev,
kernel-janitors
In-Reply-To: <20130819070510.GE28591@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon, 19 Aug 2013 10:05:10 +0300
> We need to move the derefernce after the IS_ERR() check.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] ipv4: raise IP_MAX_MTU to theoretical limit
From: David Miller @ 2013-08-20 22:08 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, willemb, kuznet
In-Reply-To: <1376878087.4226.41.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 18 Aug 2013 19:08:07 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> As discussed last year [1], there is no compelling reason
> to limit IPv4 MTU to 0xFFF0, while real limit is 0xFFFF
>
> [1] : http://marc.info/?l=linux-netdev&m=135607247609434&w=2
>
> Willem raised this issue again because some of our internal
> regression tests broke after lo mtu being set to 65536.
>
> IP_MTU reports 0xFFF0, and the test attempts to send a RAW datagram of
> mtu + 1 bytes, expecting the send() to fail, but it does not.
>
> Alexey raised interesting points about TCP MSS, that should be addressed
> in follow-up patches in TCP stack if needed, as someone could also set
> an odd mtu anyway.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks for following through on this Eric.
^ permalink raw reply
* Re: [PATCH v2] vhost: Include linux/uio.h instead of linux/socket.h
From: David Miller @ 2013-08-20 22:08 UTC (permalink / raw)
To: asias; +Cc: netdev, virtualization, kvm, mst
In-Reply-To: <1376875399-21945-1-git-send-email-asias@redhat.com>
From: Asias He <asias@redhat.com>
Date: Mon, 19 Aug 2013 09:23:19 +0800
> memcpy_fromiovec is moved from net/core/iovec.c to lib/iovec.c.
> linux/uio.h provides the declaration for memcpy_fromiovec.
>
> Include linux/uio.h instead of inux/socket.h for it.
>
> Signed-off-by: Asias He <asias@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] tcp: trivial: Remove nocache argument from tcp_v4_send_synack
From: David Miller @ 2013-08-20 22:07 UTC (permalink / raw)
To: christoph.paasch; +Cc: netdev, eric.dumazet
In-Reply-To: <1376840078-6556-1-git-send-email-christoph.paasch@uclouvain.be>
From: Christoph Paasch <christoph.paasch@uclouvain.be>
Date: Sun, 18 Aug 2013 17:34:38 +0200
> The nocache-argument was used in tcp_v4_send_synack as an argument to
> inet_csk_route_req. However, since ba3f7f04ef2b (ipv4: Kill
> FLOWI_FLAG_RT_NOCACHE and associated code.) this is no more used.
>
> This patch removes the unsued argument from tcp_v4_send_synack.
>
> Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Applied.
^ permalink raw reply
* Re: [PATCH] pch_gbe: ethtool cannot change parameters when link is down
From: David Miller @ 2013-08-20 22:07 UTC (permalink / raw)
To: al; +Cc: netdev, linux-kernel
In-Reply-To: <1376819680-15359-1-git-send-email-al@alarsen.net>
From: Anders Larsen <al@alarsen.net>
Date: Sun, 18 Aug 2013 11:54:40 +0200
> When attempting to change e.g. the advertising mask when the link is down
> ecmd->speed is -1 causing mii_ethtool_sset() to bail out.
>
> This bug bit when connecting to a gigabit switch through a 4-pin (industrial)
> cable, since link negotiation would not complete (both endpoints claimed to
> be gigabit-capable, but this is not possible with only 4 pins).
> Any attempt to fix this by setting autonegation to not offer 1000Mbps
> failed as the setting would not be accepted while the link was still down...
>
> Set ecmd->speed to SPEED_1000 to satisfy mii_ethtool_sset()
> (the actual value of ecmd->speed doesn't matter as long as it is valid,
> since a re-negotation is forced afterwards).
>
> Signed-off-by: Anders Larsen <al@alarsen.net>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/2] ipv6: fix checkpatch errors in net/ipv6/addrconf.c
From: David Miller @ 2013-08-20 22:06 UTC (permalink / raw)
To: dingtianhong; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev
In-Reply-To: <520EDF83.7030806@huawei.com>
From: Ding Tianhong <dingtianhong@huawei.com>
Date: Sat, 17 Aug 2013 10:27:15 +0800
> ERROR: code indent should use tabs where possible: fix 2.
> ERROR: do not use assignment in if condition: fix 5.
>
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/2 ] ipv6: convert the uses of ADBG and remove the superfluous parentheses
From: David Miller @ 2013-08-20 22:06 UTC (permalink / raw)
To: dingtianhong; +Cc: kuznet, jmorris, yoshfuji, kaber, joe, netdev
In-Reply-To: <520EDF78.3010106@huawei.com>
From: Ding Tianhong <dingtianhong@huawei.com>
Date: Sat, 17 Aug 2013 10:27:04 +0800
> Just follow the Joe Perches's opinion, it is a better way to fix the
> style errors.
>
> Suggested-by: Joe Perches <joe@perches.com>
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH -next] vxlan: using kfree_rcu() to simplify the code
From: David Miller @ 2013-08-20 22:06 UTC (permalink / raw)
To: stephen; +Cc: weiyj.lk, pshelar, mike.rapoport, amwang, yongjun_wei, netdev
In-Reply-To: <20130816164544.628ae1df@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Fri, 16 Aug 2013 16:45:44 -0700
> On Sat, 17 Aug 2013 07:32:09 +0800
> Wei Yongjun <weiyj.lk@gmail.com> wrote:
>
>> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>>
>> The callback function of call_rcu() just calls a kfree(), so we
>> can use kfree_rcu() instead of call_rcu() + callback function.
>>
>> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
...
> Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Applied.
^ permalink raw reply
* Re: [PATCH v3] r8169: fix invalid register dump
From: David Miller @ 2013-08-20 22:02 UTC (permalink / raw)
To: lekensteyn; +Cc: romieu, bhutchings, netdev, nic_swsd
In-Reply-To: <1376833298-7321-1-git-send-email-lekensteyn@gmail.com>
From: Peter Wu <lekensteyn@gmail.com>
Date: Sun, 18 Aug 2013 15:41:38 +0200
> For some reason, my PCIe RTL8111E onboard NIC on a GA-Z68X-UD3H-B3
> motherboard reads as FFs when reading from MMIO with a block size
> larger than 7. Therefore change to reading blocks of four bytes.
>
> Ben Hutchings noted that the buffer is large enough to hold all
> registers, so now all registers are read. Since regs->len is not used
> anymore, drop the superfluous range check as well. (ethtool would
> already ensure that regs->len <= R8169_REGS_SIZE).
>
> Signed-off-by: Peter Wu <lekensteyn@gmail.com>
> ---
> Hi,
>
> This partly obsoletes "r8169,sis190: remove unnecessary length
> check"[1]. I do not have sis190 hardware, but since that is based on
> this r8169 driver, would it make sense to apply this patch to sis190
> too?
You're going to have to respin this since I applied the length
check removal patch already.
Thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox