* Re: [PATCH v6 2/2] decrement static keys on real destroy time
From: Andrew Morton @ 2012-05-22 23:11 UTC (permalink / raw)
To: Glauber Costa, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
cgroups-u79uwXL29TY76Z2rM5mHXA, devel-GEFAQzZX7r8dnm+yROfE0A,
kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A,
netdev-u79uwXL29TY76Z2rM5mHXA, Tejun Heo, Li Zefan,
Johannes Weiner, Michal Hocko, David Miller, Joe Perches
In-Reply-To: <20120522154610.f2f9b78e.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
On Tue, 22 May 2012 15:46:10 -0700
Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
> > +static inline bool memcg_proto_active(struct cg_proto *cg_proto)
> > +{
> > + return cg_proto->flags & (1 << MEMCG_SOCK_ACTIVE);
> > +}
> > +
> > +static inline bool memcg_proto_activated(struct cg_proto *cg_proto)
> > +{
> > + return cg_proto->flags & (1 << MEMCG_SOCK_ACTIVATED);
> > +}
>
> Here, we're open-coding kinda-test_bit(). Why do that? These flags are
> modified with set_bit() and friends, so we should read them with the
> matching test_bit()?
>
> Also, these bool-returning functions will return values other than 0
> and 1. That probably works OK and I don't know what the C standards
> and implementations do about this. But it seems unclean and slightly
> risky to have a "bool" value of 32! Converting these functions to use
> test_bit() fixes this - test_bit() returns only 0 or 1.
>
> test_bit() is slightly more expensive than the above. If this is
> considered to be an issue then I guess we could continue to use this
> approach. But I do think a code comment is needed, explaining and
> justifying the unusual decision to bypass the bitops API. Also these
> functions should tell the truth and return an "int" type.
Joe corrected (and informed) me:
: 6.3.1.2p1:
:
: "When any scalar value is converted to _Bool, the result is 0
: if the value compares equal to 0; otherwise, the result is 1."
So the above functions will be given compiler-generated scalar-to-boolean
conversion.
test_bit() already does internal scalar-to-boolean conversion. The
compiler doesn't know that, so if we convert the above functions to use
test_bit(), we'll end up performing scalar-to-boolean-to-boolean
conversion, which is dumb.
I assume that a way of fixing this is to change test_bit() to return
bool type. That's a bit scary.
A less scary way would be to add a new
bool test_bit_bool(int nr, const unsigned long *addr);
which internally calls test_bit() but somehow avoids the
compiler-generated conversion of the test_bit() return value into a
bool. I haven't actually thought of a way of doing this ;)
^ permalink raw reply
* Re: [PATCH 1/3] ethtool: Split out printing of hex data
From: Ben Hutchings @ 2012-05-22 23:58 UTC (permalink / raw)
To: Stuart Hodgson; +Cc: netdev, Yaniv Rosner, David Miller, Eilon Greenstein
In-Reply-To: <4FB66390.2010704@solarflare.com>
On Fri, 2012-05-18 at 15:58 +0100, Stuart Hodgson wrote:
> Split out printing of hex data to common function from
> dump_regs and dump_eeprom. Ready for use by module
> eeprom dumping.
>
> Signed-off-by: Stuart Hodgson <smhodgson@solarflare.com>
> ---
> ethtool.c | 35 ++++++++++++++++++-----------------
> 1 files changed, 18 insertions(+), 17 deletions(-)
>
> diff --git a/ethtool.c b/ethtool.c
> index e80b38b..fdc21de 100644
> --- a/ethtool.c
> +++ b/ethtool.c
> @@ -787,6 +787,20 @@ static const struct {
> { "st_gmac", st_gmac_dump_regs },
> };
>
> +static void dump_hex(__u8 *data, int len, int offset)
> +{
> + int i;
> +
> + fprintf(stdout, "Offset\tValues\n");
> + fprintf(stdout, "--------\t-----");
> + for (i = 0; i < len; i++) {
> + if (i%16 == 0)
> + fprintf(stdout, "\n0x%04x:\t", i + offset);
> + fprintf(stdout, " %02x", data[i]);
> + }
The problem with this (inherited from dump_regs()) is that the columns
don't line up. So I've applied this but changed dump_hex() to look more
like the code removed from dump_eeprom().
Ben.
> + fprintf(stdout, "\n\n");
> +}
> +
> static int dump_regs(int gregs_dump_raw, int gregs_dump_hex,
> const char *gregs_dump_file,
> struct ethtool_drvinfo *info, struct ethtool_regs *regs)
> @@ -820,22 +834,14 @@ static int dump_regs(int gregs_dump_raw, int gregs_dump_hex,
> ETHTOOL_BUSINFO_LEN))
> return driver_list[i].func(info, regs);
>
> - fprintf(stdout, "Offset\tValues\n");
> - fprintf(stdout, "--------\t-----");
> - for (i = 0; i < regs->len; i++) {
> - if (i%16 == 0)
> - fprintf(stdout, "\n%03x:\t", i);
> - fprintf(stdout, " %02x", regs->data[i]);
> - }
> - fprintf(stdout, "\n\n");
> + dump_hex(regs->data, regs->len, 0);
> +
> return 0;
> }
>
> static int dump_eeprom(int geeprom_dump_raw, struct ethtool_drvinfo *info,
> struct ethtool_eeprom *ee)
> {
> - int i;
> -
> if (geeprom_dump_raw) {
> fwrite(ee->data, 1, ee->len, stdout);
> return 0;
> @@ -847,13 +853,8 @@ static int dump_eeprom(int geeprom_dump_raw, struct ethtool_drvinfo *info,
> return tg3_dump_eeprom(info, ee);
> }
>
> - fprintf(stdout, "Offset\t\tValues\n");
> - fprintf(stdout, "------\t\t------");
> - for (i = 0; i < ee->len; i++) {
> - if(!(i%16)) fprintf(stdout, "\n0x%04x\t\t", i + ee->offset);
> - fprintf(stdout, "%02x ", ee->data[i]);
> - }
> - fprintf(stdout, "\n");
> + dump_hex(ee->data, ee->len, ee->offset);
> +
> return 0;
> }
>
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH iproute2] tc_codel: Controlled Delay AQM
From: Dave Taht @ 2012-05-22 23:59 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Eric Dumazet, netdev, Dave Taht
In-Reply-To: <20120522141610.601f68ed@nehalam.linuxnetplumber.net>
I promised eric I'd write the two man pages.
I also promised myself a vacation. The last year has been a long hard
road. If someone
hasn't got to writing the man pages by the time I get back from lupin,
I'll write it.
On Tue, May 22, 2012 at 2:16 PM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
> On Fri, 11 May 2012 08:22:35 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> From: Eric Dumazet <edumazet@google.com>
>>
>> An implementation of CoDel AQM, from Kathleen Nichols and Van Jacobson.
>>
>> http://queue.acm.org/detail.cfm?id=2209336
>>
>> This AQM main input is no longer queue size in bytes or packets, but the
>> delay packets stay in (FIFO) queue.
>>
>> As we don't have infinite memory, we still can drop packets in enqueue()
>> in case of massive load, but mean of CoDel is to drop packets in
>> dequeue(), using a control law based on two simple parameters :
>>
>> target : target sojourn time (default 5ms)
>> interval : width of moving time window (default 100ms)
>>
>> Selected packets are dropped, unless ECN is enabled and packets can get
>> ECN mark instead.
>>
>> Usage: tc qdisc ... codel [ limit PACKETS ] [ target TIME ]
>> [ interval TIME ] [ ecn ]
>>
>> qdisc codel 10: parent 1:1 limit 2000p target 3.0ms interval 60.0ms ecn
>> Sent 13347099587 bytes 8815805 pkt (dropped 0, overlimits 0 requeues 0)
>> rate 202365Kbit 16708pps backlog 113550b 75p requeues 0
>> count 116 lastcount 98 ldelay 4.3ms dropping drop_next 816us
>> maxpacket 1514 ecn_mark 84399 drop_overlimit 0
>>
>> CoDel must be seen as a base module, and should be used keeping in mind
>> there is still a FIFO queue. So a typical setup will probably need a
>> hierarchy of several qdiscs and packet classifiers to be able to meet
>> whatever constraints a user might have.
>>
>> One possible example would be to use fq_codel, which combines Fair
>> Queueing and CoDel, in replacement of sfq / sfq_red.
>>
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> Signed-off-by: Dave Taht <dave.taht@bufferbloat.net>
>> ---
>> Notes :
>> 1) : Dave Taht will send a nice man-page for this stuff.
>> 2) : the TCA_NETEM_ECN bit is because of include/linux/pkt_sched.h sync
>> with net-next
>> (I'll send a separate patch for netem)
>>
>
> Applied. Used 3.5 sanitized header (not the one in your patch),
> and fixed whitespace error.
>
>
> Ok, where's the man page :-)
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
^ permalink raw reply
* Re: [PATCH 3/3] ethtool: Addition of -m option to dump module eeprom
From: Ben Hutchings @ 2012-05-23 0:01 UTC (permalink / raw)
To: Stuart Hodgson; +Cc: netdev, David Miller, Yaniv Rosner, Eilon Greenstein
In-Reply-To: <4FB663A5.3060107@solarflare.com>
On Fri, 2012-05-18 at 15:58 +0100, Stuart Hodgson wrote:
> The -m option now allows for retrieval of EEPROM
> information form a plug in module such as SFP+. This
> shows specific information about the type and
> capabilities of the module in use The format can be
> easily extended to support other modules types such as
> QSFP in future. Raw data dump is also supported.
[...]
Applied, thanks.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* NETDEV WATCHDOG: %s (%s): transmit queue %u timed out
From: George Spelvin @ 2012-05-23 1:03 UTC (permalink / raw)
To: netdev; +Cc: linux
After installing a 3.4 kernel, I got the following:
------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:256 dev_watchdog+0xe9/0x15c()
Hardware name: MS-7376
NETDEV WATCHDOG: inside (r8169): transmit queue 0 timed out
Pid: 0, comm: swapper/3 Not tainted 3.4.0-00017-g3df9c78 #152
Call Trace:
<IRQ> [<ffffffff81311aba>] ? dev_watchdog+0xe9/0x15c
[<ffffffff81024499>] ? warn_slowpath_common+0x71/0x85
[<ffffffff813119d1>] ? netif_tx_lock+0x7a/0x7a
[<ffffffff81024511>] ? warn_slowpath_fmt+0x45/0x4a
[<ffffffff813119be>] ? netif_tx_lock+0x67/0x7a
[<ffffffff81311aba>] ? dev_watchdog+0xe9/0x15c
[<ffffffff810345ab>] ? __queue_work+0x20a/0x20a
[<ffffffff8102c908>] ? run_timer_softirq+0x17e/0x20b
[<ffffffff81028889>] ? __do_softirq+0x80/0x102
[<ffffffff81404b8c>] ? call_softirq+0x1c/0x30
[<ffffffff81003044>] ? do_softirq+0x2c/0x60
[<ffffffff81028abc>] ? irq_exit+0x3a/0x91
[<ffffffff81002e91>] ? do_IRQ+0x81/0x97
[<ffffffff81403327>] ? common_interrupt+0x67/0x67
<EOI> [<ffffffff810079d8>] ? default_idle+0x1e/0x32
[<ffffffff81007afc>] ? amd_e400_idle+0xb7/0xd4
[<ffffffff810081a5>] ? cpu_idle+0x58/0x98
---[ end trace 7d5a7d21f604b0d8 ]---
r8169 0000:02:00.0: inside: link up
(The 17 local patches are to the PPS subsystem and nowhere near net net/
directory.)
The system is an AND Phenom X4 processor with 8G of ECC RAM, recently rebooted with
lspci -nn gives:
00:00.0 Host bridge [0600]: Advanced Micro Devices [AMD] nee ATI RD790 Northbridge only dual slot PCI-e_GFX and HT3 K8 part [1002:5956]
00:02.0 PCI bridge [0604]: Advanced Micro Devices [AMD] nee ATI RD790 PCI to PCI bridge (external gfx0 port A) [1002:5978]
00:05.0 PCI bridge [0604]: Advanced Micro Devices [AMD] nee ATI RD790 PCI to PCI bridge (PCI express gpp port B) [1002:597b]
00:09.0 PCI bridge [0604]: Advanced Micro Devices [AMD] nee ATI RD790 PCI to PCI bridge (PCI express gpp port E) [1002:597e]
00:12.0 SATA controller [0106]: Advanced Micro Devices [AMD] nee ATI SB600 Non-Raid-5 SATA [1002:4380]
00:13.0 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI0) [1002:4387]
00:13.1 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI1) [1002:4388]
00:13.2 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI2) [1002:4389]
00:13.3 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI3) [1002:438a]
00:13.4 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB600 USB (OHCI4) [1002:438b]
00:13.5 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB600 USB Controller (EHCI) [1002:4386]
00:14.0 SMBus [0c05]: Advanced Micro Devices [AMD] nee ATI SBx00 SMBus Controller [1002:4385] (rev 14)
00:14.1 IDE interface [0101]: Advanced Micro Devices [AMD] nee ATI SB600 IDE [1002:438c]
00:14.2 Audio device [0403]: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA) [1002:4383]
00:14.3 ISA bridge [0601]: Advanced Micro Devices [AMD] nee ATI SB600 PCI to LPC Bridge [1002:438d]
00:14.4 PCI bridge [0604]: Advanced Micro Devices [AMD] nee ATI SBx00 PCI to PCI Bridge [1002:4384]
00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] Family 10h Processor HyperTransport Configuration [1022:1200]
00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] Family 10h Processor Address Map [1022:1201]
00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] Family 10h Processor DRAM Controller [1022:1202]
00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] Family 10h Processor Miscellaneous Control [1022:1203]
00:18.4 Host bridge [0600]: Advanced Micro Devices [AMD] Family 10h Processor Link Control [1022:1204]
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI RV370 5B60 [Radeon X300 (PCIE)] [1002:5b60]
01:00.1 Display controller [0380]: Advanced Micro Devices [AMD] nee ATI RV370 [Radeon X300SE] [1002:5b70]
02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 01)
03:00.0 RAID bus controller [0104]: Promise Technology, Inc. PDC42819 [FastTrak TX2650/TX4650] [105a:3f20]
04:00.0 FireWire (IEEE 1394) [0c00]: VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller [1106:3044] (rev c0)
04:02.0 Serial controller [0700]: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 0 (Uart) [1415:9501]
04:02.1 Parallel controller [0701]: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 1 (parallel port) [1415:9513]
04:03.0 PCI bridge [0604]: Digital Equipment Corporation DECchip 21152 [1011:0024] (rev 03)
05:04.0 Ethernet controller [0200]: Digital Equipment Corporation DECchip 21142/43 [1011:0019] (rev 41)
05:05.0 Ethernet controller [0200]: Digital Equipment Corporation DECchip 21142/43 [1011:0019] (rev 41)
05:06.0 Ethernet controller [0200]: Digital Equipment Corporation DECchip 21142/43 [1011:0019] (rev 41)
05:07.0 Ethernet controller [0200]: Digital Equipment Corporation DECchip 21142/43 [1011:0019] (rev 41)
The Tulip 100baseT ports are used for external and DMZ ports, while the RTL8169 is the main "inside"
gigabit network port.
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:02:00.0: irq 40 for MSI/MSI-X
r8169 0000:02:00.0: eth4: RTL8168b/8111b at 0xffffc90000020000, 00:21:85:16:51:7f, XID 18000000 IRQ 40
r8169 0000:02:00.0: eth4: jumbo features [frames: 4080 bytes, tx checksumming: ko]
It doesn't seem to be causing serious problems, but I presume the warning is there because
someone would like to know about it.
^ permalink raw reply
* Re: NETDEV WATCHDOG: %s (%s): transmit queue %u timed out
From: Dave Jones @ 2012-05-23 1:26 UTC (permalink / raw)
To: George Spelvin; +Cc: netdev, Fedora Kernel Team
In-Reply-To: <20120523010334.5778.qmail@science.horizon.com>
On Tue, May 22, 2012 at 09:03:34PM -0400, George Spelvin wrote:
> After installing a 3.4 kernel, I got the following:
>
> ------------[ cut here ]------------
> WARNING: at net/sched/sch_generic.c:256 dev_watchdog+0xe9/0x15c()
> Hardware name: MS-7376
> NETDEV WATCHDOG: inside (r8169): transmit queue 0 timed out
> Pid: 0, comm: swapper/3 Not tainted 3.4.0-00017-g3df9c78 #152
> ..
> It doesn't seem to be causing serious problems, but I presume the warning is there because
> someone would like to know about it.
We seem to be seeing more and more of these (across a range of different NICs)
https://bugzilla.redhat.com/showdependencytree.cgi?id=702723&hide_resolved=1
has a bunch of duplicated bugs sorted into per-nic reports.
Dave
^ permalink raw reply
* Re: [RFC/PATCH] Bluetooth: prevent double l2cap_chan_destroy
From: Minho Ban @ 2012-05-23 1:39 UTC (permalink / raw)
To: Chanyeol Park
Cc: Gustavo Padovan, Marcel Holtmann, Johan Hedberg, David S. Miller,
linux-bluetooth, netdev, linux-kernel
In-Reply-To: <4FBB8544.3040408@samsung.com>
On 05/22/2012 09:23 PM, Chanyeol Park wrote:
> Hi
>
> On 2012년 05월 22일 11:50, Minho Ban wrote:
>> @@ -1343,10 +1343,10 @@ static void l2cap_conn_del(struct hci_conn *hcon, int err)
>> l2cap_chan_lock(chan);
>>
>> l2cap_chan_del(chan, err);
>> + chan->ops->close(chan->data);
>>
>> l2cap_chan_unlock(chan);
>>
>> - chan->ops->close(chan->data);
>> l2cap_chan_put(chan);
>> }
> I think this patch does not make sense Because inside chan->ops->close() "chan" could be freed in the l2cap_chan_destroy().
>
I agree, thanks for pointing out.
^ permalink raw reply
* Re: NETDEV WATCHDOG: %s (%s): transmit queue %u timed out
From: George Spelvin @ 2012-05-23 1:53 UTC (permalink / raw)
To: davej, linux; +Cc: kernel-team, netdev
In-Reply-To: <20120523012640.GB15255@redhat.com>
> We seem to be seeing more and more of these (across a range of different NICs)
> https://bugzilla.redhat.com/showdependencytree.cgi?id=702723&hide_resolved=1
> has a bunch of duplicated bugs sorted into per-nic reports.
Thank yoou for rhe response.
Unfortunately, the last reboot was on Feb. 26, and the kernel logs don't go back that far,
so I'm not sure if 3.3-rc5 reported this priblem or not.
^ permalink raw reply
* Re: [PATCH iproute2] tc_codel: Controlled Delay AQM
From: Vijay Subramanian @ 2012-05-23 2:05 UTC (permalink / raw)
To: Dave Taht; +Cc: Stephen Hemminger, Eric Dumazet, netdev, Dave Taht
In-Reply-To: <CAA93jw5oOz38UHsp2UODJcbn9uDz34RfPSNCE-qE-7BKoshLtA@mail.gmail.com>
On 22 May 2012 16:59, Dave Taht <dave.taht@gmail.com> wrote:
> I promised eric I'd write the two man pages.
>
> I also promised myself a vacation. The last year has been a long hard
> road. If someone
> hasn't got to writing the man pages by the time I get back from lupin,
> I'll write it.
>
Dave,
I can volunteer to write the man page. I have been looking at some of
the iproute2 code and the corresponding parts in the kernel and
writing the man page would be a good learning process I think. I will
try to come up with a version for you to review shortly.
Regards,
Vijay
^ permalink raw reply
* Re: [PATCH] if: restore token ring ARP type to header
From: Paul Gortmaker @ 2012-05-23 2:28 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20120522140105.284c28cd@nehalam.linuxnetplumber.net>
On Tue, May 22, 2012 at 5:01 PM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
> Recent removal of Token Ring breaks the build of iproute2.
>
> Even though Token Ring support is gone from the kernel, it is worth
> keeping the the definition of the TR ARP type to avoid breaking
> userspace programs that use this file.
Thanks Stephen, I was trying to force errors in kernel builds by
doing these kinds of define changes while doing my delete tests.
But I was not doing userspace builds, however....
Looking back at the changes I've made, the only thing similar that
I can see is the ipx.h changes:
diff --git a/include/linux/ipx.h b/include/linux/ipx.h
index 3d48014..8f02439 100644
--- a/include/linux/ipx.h
+++ b/include/linux/ipx.h
@@ -38,7 +38,7 @@ struct ipx_interface_definition {
#define IPX_FRAME_8022 2
#define IPX_FRAME_ETHERII 3
#define IPX_FRAME_8023 4
-#define IPX_FRAME_TR_8022 5 /* obsolete */
+/* obsolete token ring was 5 */
unsigned char ipx_special;
#define IPX_SPECIAL_NONE 0
#define IPX_PRIMARY 1
Please let me/netdev know if the above also happens to trigger any
sort of userspace fallout, and we'll fix it up ASAP.
Thanks,
Paul.
^ permalink raw reply related
* Re: [PATCH] if: restore token ring ARP type to header
From: Stephen Hemminger @ 2012-05-23 2:34 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: David Miller, netdev
In-Reply-To: <CAP=VYLqMGeFvy8O_zLi+sEP0t6p5M8f_x7d0g1XGkLHdVUVzUg@mail.gmail.com>
On Tue, 22 May 2012 22:28:28 -0400
Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
> On Tue, May 22, 2012 at 5:01 PM, Stephen Hemminger
> <shemminger@vyatta.com> wrote:
> > Recent removal of Token Ring breaks the build of iproute2.
> >
> > Even though Token Ring support is gone from the kernel, it is worth
> > keeping the the definition of the TR ARP type to avoid breaking
> > userspace programs that use this file.
>
> Thanks Stephen, I was trying to force errors in kernel builds by
> doing these kinds of define changes while doing my delete tests.
>
> But I was not doing userspace builds, however....
>
> Looking back at the changes I've made, the only thing similar that
> I can see is the ipx.h changes:
>
> diff --git a/include/linux/ipx.h b/include/linux/ipx.h
> index 3d48014..8f02439 100644
> --- a/include/linux/ipx.h
> +++ b/include/linux/ipx.h
> @@ -38,7 +38,7 @@ struct ipx_interface_definition {
> #define IPX_FRAME_8022 2
> #define IPX_FRAME_ETHERII 3
> #define IPX_FRAME_8023 4
> -#define IPX_FRAME_TR_8022 5 /* obsolete */
> +/* obsolete token ring was 5 */
> unsigned char ipx_special;
> #define IPX_SPECIAL_NONE 0
> #define IPX_PRIMARY 1
>
> Please let me/netdev know if the above also happens to trigger any
> sort of userspace fallout, and we'll fix it up ASAP.
>
> Thanks,
> Paul.
Assume any header processed as part of 'make headers_install' is
part of kernel API and must not get broken. Therefor ipx.h
must be fixed as well. Local debug stuff should not be committed
to upstream repository!
^ permalink raw reply
* Re: [PATCH] ipv4: fix the rcu race between free_fib_info and ip_route_output_slow
From: Yanmin Zhang @ 2012-05-23 3:02 UTC (permalink / raw)
To: David Miller; +Cc: kunx.jiang, netdev, linux-kernel
In-Reply-To: <20120522.151554.106838106733194160.davem@davemloft.net>
On Tue, 2012-05-22 at 15:15 -0400, David Miller wrote:
> From: "kun.jiang" <kunx.jiang@intel.com>
> Date: Tue, 22 May 2012 17:48:53 +0800
>
> > From: Yanmin Zhang <yanmin_zhang@linux.intel.com>
> >
> > We hit a kernel OOPS.
> ...
> > In function free_fib_info, we don't reset nexthop_nh->nh_dev to NULL before releasing
> > nh_dev. kfree_rcu(fi, rcu) would release the whole area.
> >
> > Signed-off-by: Yanmin Zhang <yanmin_zhang@linux.intel.com>
> > Signed-off-by: Kun Jiang <kunx.jiang@intel.com>
>
> This isn't a fix. You're keeping around a pointer to a completely
> released object, which is therefore illegal to dereference.
>
> That's why we must set it to NULL, to catch such illegal accesses.
Thanks for the comments. The network stack in kernel is complicated.
Questions:
1) Why does free_fib_info call call_rcu instead of releasing fi directly?
I assume other cpu might be accessing it. nexthop_nh->nh_dev is in fi.
If other cpu are accessing it, here resetting to NULL would cause other
cpu panic.
void free_fib_info(struct fib_info *fi)
{
if (fi->fib_dead == 0) {
pr_warn("Freeing alive fib_info %p\n", fi);
return;
}
change_nexthops(fi) {
if (nexthop_nh->nh_dev)
dev_put(nexthop_nh->nh_dev);
nexthop_nh->nh_dev = NULL;
} endfor_nexthops(fi);
fib_info_cnt--;
release_net(fi->fib_net);
call_rcu(&fi->rcu, free_fib_info_rcu); <=====rcu
}
2) dev_put is to decrease the counter and doesn't release nh_dev.
If 2) is incorrect, how about below solution? It delays the resetting
in rcu.
================
We hit a kernel OOPS.
<3>[23898.789643] BUG: sleeping function called from invalid context at
/data/buildbot/workdir/ics/hardware/intel/linux-2.6/arch/x86/mm/fault.c:1103
<3>[23898.862215] in_atomic(): 0, irqs_disabled(): 0, pid: 10526, name:
Thread-6683
<4>[23898.967805] HSU serial 0000:00:05.1: 0000:00:05.2:HSU serial prevented me
to suspend...
<4>[23899.258526] Pid: 10526, comm: Thread-6683 Tainted: G W
3.0.8-137685-ge7742f9 #1
<4>[23899.357404] HSU serial 0000:00:05.1: 0000:00:05.2:HSU serial prevented me
to suspend...
<4>[23899.904225] Call Trace:
<4>[23899.989209] [<c1227f50>] ? pgtable_bad+0x130/0x130
<4>[23900.000416] [<c1238c2a>] __might_sleep+0x10a/0x110
<4>[23900.007357] [<c1228021>] do_page_fault+0xd1/0x3c0
<4>[23900.013764] [<c18e9ba9>] ? restore_all+0xf/0xf
<4>[23900.024024] [<c17c007b>] ? napi_complete+0x8b/0x690
<4>[23900.029297] [<c1227f50>] ? pgtable_bad+0x130/0x130
<4>[23900.123739] [<c1227f50>] ? pgtable_bad+0x130/0x130
<4>[23900.128955] [<c18ea0c3>] error_code+0x5f/0x64
<4>[23900.133466] [<c1227f50>] ? pgtable_bad+0x130/0x130
<4>[23900.138450] [<c17f6298>] ? __ip_route_output_key+0x698/0x7c0
<4>[23900.144312] [<c17f5f8d>] ? __ip_route_output_key+0x38d/0x7c0
<4>[23900.150730] [<c17f63df>] ip_route_output_flow+0x1f/0x60
<4>[23900.156261] [<c181de58>] ip4_datagram_connect+0x188/0x2b0
<4>[23900.161960] [<c18e981f>] ? _raw_spin_unlock_bh+0x1f/0x30
<4>[23900.167834] [<c18298d6>] inet_dgram_connect+0x36/0x80
<4>[23900.173224] [<c14f9e88>] ? _copy_from_user+0x48/0x140
<4>[23900.178817] [<c17ab9da>] sys_connect+0x9a/0xd0
<4>[23900.183538] [<c132e93c>] ? alloc_file+0xdc/0x240
<4>[23900.189111] [<c123925d>] ? sub_preempt_count+0x3d/0x50
Function free_fib_info resets nexthop_nh->nh_dev to NULL before releasing
fi. Other cpu might be accessing fi. Fixing it by delaying the resetting.
Signed-off-by: Yanmin Zhang <yanmin_zhang@linux.intel.com>
Signed-off-by: Kun Jiang <kunx.jiang@intel.com>
---
net/ipv4/fib_semantics.c | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index 5063fa3..56d8a97 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -145,6 +145,14 @@ static void free_fib_info_rcu(struct rcu_head *head)
{
struct fib_info *fi = container_of(head, struct fib_info, rcu);
+ change_nexthops(fi) {
+ if (nexthop_nh->nh_dev)
+ dev_put(nexthop_nh->nh_dev);
+ nexthop_nh->nh_dev = NULL;
+ } endfor_nexthops(fi);
+
+ fib_info_cnt--;
+ release_net(fi->fib_net);
if (fi->fib_metrics != (u32 *) dst_default_metrics)
kfree(fi->fib_metrics);
kfree(fi);
@@ -156,13 +164,6 @@ void free_fib_info(struct fib_info *fi)
pr_warn("Freeing alive fib_info %p\n", fi);
return;
}
- change_nexthops(fi) {
- if (nexthop_nh->nh_dev)
- dev_put(nexthop_nh->nh_dev);
- nexthop_nh->nh_dev = NULL;
- } endfor_nexthops(fi);
- fib_info_cnt--;
- release_net(fi->fib_net);
call_rcu(&fi->rcu, free_fib_info_rcu);
}
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] ipv4: fix the rcu race between free_fib_info and ip_route_output_slow
From: David Miller @ 2012-05-23 3:23 UTC (permalink / raw)
To: yanmin_zhang; +Cc: kunx.jiang, netdev, linux-kernel
In-Reply-To: <1337742123.14538.175.camel@ymzhang.sh.intel.com>
From: Yanmin Zhang <yanmin_zhang@linux.intel.com>
Date: Wed, 23 May 2012 11:02:03 +0800
> 1) Why does free_fib_info call call_rcu instead of releasing fi directly?
> I assume other cpu might be accessing it. nexthop_nh->nh_dev is in fi.
> If other cpu are accessing it, here resetting to NULL would cause other
> cpu panic.
Because fib trie lookups are done with RCU locking, therefore we must
use RCU freeing to release the object.
What I was trying to impart to you is that removing the NULL
assignment is wrong and that an alternative fix is warranted (hint:
consider moving something into the RCU release).
^ permalink raw reply
* Re: [PATCH] ipv4: fix the rcu race between free_fib_info and ip_route_output_slow
From: Yanmin Zhang @ 2012-05-23 3:30 UTC (permalink / raw)
To: David Miller; +Cc: kunx.jiang, netdev, linux-kernel
In-Reply-To: <20120522.232310.911242148705021745.davem@davemloft.net>
On Tue, 2012-05-22 at 23:23 -0400, David Miller wrote:
> From: Yanmin Zhang <yanmin_zhang@linux.intel.com>
> Date: Wed, 23 May 2012 11:02:03 +0800
>
> > 1) Why does free_fib_info call call_rcu instead of releasing fi directly?
> > I assume other cpu might be accessing it. nexthop_nh->nh_dev is in fi.
> > If other cpu are accessing it, here resetting to NULL would cause other
> > cpu panic.
>
> Because fib trie lookups are done with RCU locking, therefore we must
> use RCU freeing to release the object.
>
> What I was trying to impart to you is that removing the NULL
> assignment is wrong and that an alternative fix is warranted (hint:
> consider moving something into the RCU release).
Thanks for the explanation.
How about the new patch posted in the end of previous reply? It does move the
the resetting to RCU release.
https://lkml.org/lkml/2012/5/22/558?
^ permalink raw reply
* Re: [PATCH] ipv4: fix the rcu race between free_fib_info and ip_route_output_slow
From: David Miller @ 2012-05-23 3:49 UTC (permalink / raw)
To: yanmin_zhang; +Cc: kunx.jiang, netdev, linux-kernel
In-Reply-To: <1337743841.14538.178.camel@ymzhang.sh.intel.com>
From: Yanmin Zhang <yanmin_zhang@linux.intel.com>
Date: Wed, 23 May 2012 11:30:41 +0800
> How about the new patch posted in the end of previous reply? It does move the
> the resetting to RCU release.
> https://lkml.org/lkml/2012/5/22/558?
If you test it and submit it formally I'll probably apply it.
^ permalink raw reply
* Re: [PATCH] ipv4: fix the rcu race between free_fib_info and ip_route_output_slow
From: Eric Dumazet @ 2012-05-23 4:37 UTC (permalink / raw)
To: David Miller; +Cc: yanmin_zhang, kunx.jiang, netdev, linux-kernel
In-Reply-To: <20120522.232310.911242148705021745.davem@davemloft.net>
On Tue, 2012-05-22 at 23:23 -0400, David Miller wrote:
> From: Yanmin Zhang <yanmin_zhang@linux.intel.com>
> Date: Wed, 23 May 2012 11:02:03 +0800
>
> > 1) Why does free_fib_info call call_rcu instead of releasing fi directly?
> > I assume other cpu might be accessing it. nexthop_nh->nh_dev is in fi.
> > If other cpu are accessing it, here resetting to NULL would cause other
> > cpu panic.
>
> Because fib trie lookups are done with RCU locking, therefore we must
> use RCU freeing to release the object.
>
> What I was trying to impart to you is that removing the NULL
> assignment is wrong and that an alternative fix is warranted (hint:
> consider moving something into the RCU release).
> --
Its more than that I'm afraid.
fi->fib_dev (aka fib_nh[0].nh_dev) need full RCU protection.
Also the "fib_info_cnt--;" must stay in free_fib_info() (so that it is
protected by RTNL)
^ permalink raw reply
* Re: [PATCH] ipv4: fix the rcu race between free_fib_info and ip_route_output_slow
From: Yanmin Zhang @ 2012-05-23 4:41 UTC (permalink / raw)
To: David Miller; +Cc: kunx.jiang, netdev, linux-kernel
In-Reply-To: <20120522.234920.1047532847473945281.davem@davemloft.net>
On Tue, 2012-05-22 at 23:49 -0400, David Miller wrote:
> From: Yanmin Zhang <yanmin_zhang@linux.intel.com>
> Date: Wed, 23 May 2012 11:30:41 +0800
>
> > How about the new patch posted in the end of previous reply? It does move the
> > the resetting to RCU release.
> > https://lkml.org/lkml/2012/5/22/558?
>
> If you test it and submit it formally I'll probably apply it.
We did test it. But it's hard to reproduce it. We hit it the issue
for a couple of times when running MTBF testing on Android smart phone.
Mostly, it happens after MTBF runs for more than 12 hours. To releasing
the product, MTBF testing should run for hundreds of hours. This bug
blocks it.
We would submit it formally and also run more testing.
Sorry for taking you too much time.
^ permalink raw reply
* Re: [PATCH] ipv4: fix the rcu race between free_fib_info and ip_route_output_slow
From: Yanmin Zhang @ 2012-05-23 4:54 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, kunx.jiang, netdev, linux-kernel
In-Reply-To: <1337747829.3361.1599.camel@edumazet-glaptop>
On Wed, 2012-05-23 at 06:37 +0200, Eric Dumazet wrote:
> On Tue, 2012-05-22 at 23:23 -0400, David Miller wrote:
> > From: Yanmin Zhang <yanmin_zhang@linux.intel.com>
> > Date: Wed, 23 May 2012 11:02:03 +0800
> >
> > > 1) Why does free_fib_info call call_rcu instead of releasing fi directly?
> > > I assume other cpu might be accessing it. nexthop_nh->nh_dev is in fi.
> > > If other cpu are accessing it, here resetting to NULL would cause other
> > > cpu panic.
> >
> > Because fib trie lookups are done with RCU locking, therefore we must
> > use RCU freeing to release the object.
> >
> > What I was trying to impart to you is that removing the NULL
> > assignment is wrong and that an alternative fix is warranted (hint:
> > consider moving something into the RCU release).
> > --
>
> Its more than that I'm afraid.
>
> fi->fib_dev (aka fib_nh[0].nh_dev) need full RCU protection.
The new patch posted at https://lkml.org/lkml/2012/5/22/558 does move the
resetting to RCU protection.
>
> Also the "fib_info_cnt--;" must stay in free_fib_info() (so that it is
> protected by RTNL)
We would move "fib_info_cnt--;" back to free_fib_info.
Thanks,
Yanmin
^ permalink raw reply
* Re: [PATCH] ipv4: fix the rcu race between free_fib_info and ip_route_output_slow
From: Eric Dumazet @ 2012-05-23 5:02 UTC (permalink / raw)
To: Yanmin Zhang; +Cc: David Miller, kunx.jiang, netdev, linux-kernel
In-Reply-To: <1337748897.14538.184.camel@ymzhang.sh.intel.com>
On Wed, 2012-05-23 at 12:54 +0800, Yanmin Zhang wrote:
> > fi->fib_dev (aka fib_nh[0].nh_dev) need full RCU protection.
> The new patch posted at https://lkml.org/lkml/2012/5/22/558 does move the
> resetting to RCU protection.
Its not enough.
We must take care that all users are in a RCU protected region.
They might be already, but a full check is needed.
For example
net/ipv4/fib_trie.c:2563: fi->fib_dev ? fi->fib_dev->name : "*"
looks to be safe (because already in a rcu_read_lock())
But its not.
Right thing would be to do :
struct net_device *ndev = rcu_dereference(fi->fib_dev)
...
ndev ? ndev->name : "*"
^ permalink raw reply
* Re: [PATCH] ipv4: fix the rcu race between free_fib_info and ip_route_output_slow
From: Eric Dumazet @ 2012-05-23 5:08 UTC (permalink / raw)
To: Yanmin Zhang; +Cc: David Miller, kunx.jiang, netdev, linux-kernel
In-Reply-To: <1337748069.14538.181.camel@ymzhang.sh.intel.com>
On Wed, 2012-05-23 at 12:41 +0800, Yanmin Zhang wrote:
> We did test it. But it's hard to reproduce it. We hit it the issue
> for a couple of times when running MTBF testing on Android smart phone.
> Mostly, it happens after MTBF runs for more than 12 hours. To releasing
> the product, MTBF testing should run for hundreds of hours. This bug
> blocks it.
>
I have an idea how to trigger this in my test machine.
> We would submit it formally and also run more testing.
>
> Sorry for taking you too much time.
Hey, you fix a bug, take your time and dont worry.
Thanks
^ permalink raw reply
* Re: [PATCH 2/3] drivers: net: ethernet: stmmac: fix failure in module test
From: Bob Liu @ 2012-05-23 5:09 UTC (permalink / raw)
To: Giuseppe CAVALLARO
Cc: davem, francesco.virlinzi, rayagond, sr, netdev,
uclinux-dist-devel
In-Reply-To: <4FBB8BBD.8010208@st.com>
Hi Peppe,
On Tue, May 22, 2012 at 8:51 PM, Giuseppe CAVALLARO
<peppe.cavallaro@st.com> wrote:
> On 5/22/2012 9:38 AM, Bob Liu wrote:
>> Module can't be compiled and installed in current Makefile.
>
> I've just seen that I can generate the stmmac.ko on ARM and also on x86
> with my configuration.
>
> Can you post here you build failure?
>
> In the meantime I'll test the module on ARM soon.
Yes, stmmac.ko can be generated, but stmmac_platform.c won't be built.
which cause net device can't be probed.
>
> peppe
>
>>
>> Signed-off-by: Bob Liu <lliubbo@gmail.com>
>> ---
>> drivers/net/ethernet/stmicro/stmmac/Makefile | 12 ++++++------
>> 1 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
>> index bc965ac..4b50922 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/Makefile
>> +++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
>> @@ -1,10 +1,10 @@
>> obj-$(CONFIG_STMMAC_ETH) += stmmac.o
>> -stmmac-$(CONFIG_STMMAC_TIMER) += stmmac_timer.o
>> -stmmac-$(CONFIG_STMMAC_RING) += ring_mode.o
>> -stmmac-$(CONFIG_STMMAC_CHAINED) += chain_mode.o
>> -stmmac-$(CONFIG_STMMAC_PLATFORM) += stmmac_platform.o
>> -stmmac-$(CONFIG_STMMAC_PCI) += stmmac_pci.o
>> +stmmac-$(CONFIG_STMMAC_TIMER:m=y) += stmmac_timer.o
>> +stmmac-$(CONFIG_STMMAC_RING:m=y) += ring_mode.o
>> +stmmac-$(CONFIG_STMMAC_CHAINED:m=y) += chain_mode.o
>> +stmmac-$(CONFIG_STMMAC_PLATFORM:m=y) += stmmac_platform.o
>> +stmmac-$(CONFIG_STMMAC_PCI:m=y) += stmmac_pci.o
>> stmmac-objs:= stmmac_main.o stmmac_ethtool.o stmmac_mdio.o \
>> dwmac_lib.o dwmac1000_core.o dwmac1000_dma.o \
>> dwmac100_core.o dwmac100_dma.o enh_desc.o norm_desc.o \
>> - mmc_core.o $(stmmac-y)
>> + mmc_core.o
>
--
Thanks,
--Bob
^ permalink raw reply
* [net-next 1/4] stmmac: modify and improve the bus_setup platform callback
From: Giuseppe CAVALLARO @ 2012-05-23 5:40 UTC (permalink / raw)
To: netdev; +Cc: Giuseppe Cavallaro
This patch modifies and improves the bus_setup callback now
by passing extra parameters that can help on more complex
platforms that require more custom settings.
The patch also updates the documentation.
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
Documentation/networking/stmmac.txt | 3 ++-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 19 +++++++++++++++----
include/linux/stmmac.h | 3 ++-
3 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/Documentation/networking/stmmac.txt b/Documentation/networking/stmmac.txt
index ab1e8d7..20c01bf 100644
--- a/Documentation/networking/stmmac.txt
+++ b/Documentation/networking/stmmac.txt
@@ -121,7 +121,7 @@ and detailed below as well:
int pmt;
int force_sf_dma_mode;
void (*fix_mac_speed)(void *priv, unsigned int speed);
- void (*bus_setup)(void __iomem *ioaddr);
+ void *(*bus_setup)(void __iomem *ioaddr, struct device *dev, void *d);
int (*init)(struct platform_device *pdev);
void (*exit)(struct platform_device *pdev);
void *bsp_priv;
@@ -156,6 +156,7 @@ Where:
o bus_setup: perform HW setup of the bus. For example, on some ST platforms
this field is used to configure the AMBA bridge to generate more
efficient STBus traffic.
+ o bus_data: saved custom data for custom bus setting.
o init/exit: callbacks used for calling a custom initialisation;
this is sometime necessary on some platforms (e.g. ST boxes)
where the HW needs to have set some PIO lines or system cfg
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 7096633..2fc5462 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -999,10 +999,6 @@ static int stmmac_open(struct net_device *dev)
/* Copy the MAC addr into the HW */
priv->hw->mac->set_umac_addr(priv->ioaddr, dev->dev_addr, 0);
- /* If required, perform hw setup of the bus. */
- if (priv->plat->bus_setup)
- priv->plat->bus_setup(priv->ioaddr);
-
/* Initialize the MAC Core */
priv->hw->mac->core_init(priv->ioaddr);
@@ -1949,6 +1945,15 @@ struct stmmac_priv *stmmac_dvr_probe(struct device *device,
goto error;
}
+ /* On some platforms, is is possible to perform some hw setup of the bus
+ * and this is done by calling the bus_setup (when implemented).
+ * Data from bus_setup can be saved in the patform structure to be
+ * restored when resume for example form standby.
+ */
+ if (priv->plat->bus_setup)
+ priv->plat->bus_data =
+ priv->plat->bus_setup(priv->ioaddr, priv->device,
+ priv->plat->bus_data);
return priv;
error:
@@ -2057,6 +2062,8 @@ int stmmac_resume(struct net_device *ndev)
priv->hw->dma->start_tx(priv->ioaddr);
priv->hw->dma->start_rx(priv->ioaddr);
+ priv->plat->bus_data = priv->plat->bus_setup(priv->ioaddr, priv->device,
+ priv->plat->bus_data);
#ifdef CONFIG_STMMAC_TIMER
if (likely(priv->tm->enable))
priv->tm->timer_start(tmrate);
@@ -2083,9 +2090,13 @@ int stmmac_freeze(struct net_device *ndev)
int stmmac_restore(struct net_device *ndev)
{
+ struct stmmac_priv *priv = netdev_priv(ndev);
+
if (!ndev || !netif_running(ndev))
return 0;
+ priv->plat->bus_data = priv->plat->bus_setup(priv->ioaddr, priv->device,
+ priv->plat->bus_data);
return stmmac_open(ndev);
}
#endif /* CONFIG_PM */
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index b69bdb1..cf03968 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -106,7 +106,8 @@ struct plat_stmmacenet_data {
int pmt;
int force_sf_dma_mode;
void (*fix_mac_speed)(void *priv, unsigned int speed);
- void (*bus_setup)(void __iomem *ioaddr);
+ void *(*bus_setup)(void __iomem *ioaddr, struct device *dev, void *d);
+ void *bus_data;
int (*init)(struct platform_device *pdev);
void (*exit)(struct platform_device *pdev);
void *custom_cfg;
--
1.7.4.4
^ permalink raw reply related
* [net-next 2/4] stmmac: remove two useless initialisation
From: Giuseppe CAVALLARO @ 2012-05-23 5:40 UTC (permalink / raw)
To: netdev; +Cc: Giuseppe Cavallaro
In-Reply-To: <1337751619-21941-1-git-send-email-peppe.cavallaro@st.com>
This patch removes two useful initialisation in the
stmmac_rx and stmmac_tx function.
In the former, count var was already reset and in the
stmmac_tx we only need to increment the dirty pointer
w/o setting the entry var.
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 2fc5462..b942ed4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -677,7 +677,7 @@ static void stmmac_tx(struct stmmac_priv *priv)
priv->hw->desc->release_tx_desc(p);
- entry = (++priv->dirty_tx) % txsize;
+ priv->dirty_tx++;
}
if (unlikely(netif_queue_stopped(priv->dev) &&
stmmac_tx_avail(priv) > STMMAC_TX_THRESH(priv))) {
@@ -1303,7 +1303,6 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit)
display_ring(priv->dma_rx, rxsize);
}
#endif
- count = 0;
while (!priv->hw->desc->get_rx_owner(p)) {
int status;
--
1.7.4.4
^ permalink raw reply related
* [net-next 3/4] stmmac: fix driver's doc when run kernel-doc script
From: Giuseppe CAVALLARO @ 2012-05-23 5:40 UTC (permalink / raw)
To: netdev; +Cc: Giuseppe Cavallaro
In-Reply-To: <1337751619-21941-1-git-send-email-peppe.cavallaro@st.com>
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index b942ed4..fd8bafc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -833,8 +833,9 @@ static u32 stmmac_get_synopsys_id(struct stmmac_priv *priv)
/**
* stmmac_selec_desc_mode
- * @dev : device pointer
- * Description: select the Enhanced/Alternate or Normal descriptors */
+ * @priv : private structure
+ * Description: select the Enhanced/Alternate or Normal descriptors
+ */
static void stmmac_selec_desc_mode(struct stmmac_priv *priv)
{
if (priv->plat->enh_desc) {
@@ -1856,6 +1857,8 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
/**
* stmmac_dvr_probe
* @device: device pointer
+ * @plat_dat: platform data pointer
+ * @addr: iobase memory address
* Description: this is the main probe function used to
* call the alloc_etherdev, allocate the priv structure.
*/
--
1.7.4.4
^ permalink raw reply related
* [net-next 4/4] stmmac: update driver's doc
From: Giuseppe CAVALLARO @ 2012-05-23 5:40 UTC (permalink / raw)
To: netdev; +Cc: Giuseppe Cavallaro
In-Reply-To: <1337751619-21941-1-git-send-email-peppe.cavallaro@st.com>
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
Documentation/networking/stmmac.txt | 47 ++++++++++++++++++++---------------
1 files changed, 27 insertions(+), 20 deletions(-)
diff --git a/Documentation/networking/stmmac.txt b/Documentation/networking/stmmac.txt
index 20c01bf..b71f960 100644
--- a/Documentation/networking/stmmac.txt
+++ b/Documentation/networking/stmmac.txt
@@ -10,8 +10,8 @@ Currently this network device driver is for all STM embedded MAC/GMAC
(i.e. 7xxx/5xxx SoCs), SPEAr (arm), Loongson1B (mips) and XLINX XC2V3000
FF1152AMT0221 D1215994A VIRTEX FPGA board.
-DWC Ether MAC 10/100/1000 Universal version 3.60a (and older) and DWC Ether MAC 10/100
-Universal version 4.0 have been used for developing this driver.
+DWC Ether MAC 10/100/1000 Universal version 3.60a (and older) and DWC Ether
+MAC 10/100 Universal version 4.0 have been used for developing this driver.
This driver supports both the platform bus and PCI.
@@ -54,27 +54,27 @@ net_device structure enabling the scatter/gather feature.
When one or more packets are received, an interrupt happens. The interrupts
are not queued so the driver has to scan all the descriptors in the ring during
the receive process.
-This is based on NAPI so the interrupt handler signals only if there is work to be
-done, and it exits.
+This is based on NAPI so the interrupt handler signals only if there is work
+to be done, and it exits.
Then the poll method will be scheduled at some future point.
The incoming packets are stored, by the DMA, in a list of pre-allocated socket
buffers in order to avoid the memcpy (Zero-copy).
4.3) Timer-Driver Interrupt
-Instead of having the device that asynchronously notifies the frame receptions, the
-driver configures a timer to generate an interrupt at regular intervals.
-Based on the granularity of the timer, the frames that are received by the device
-will experience different levels of latency. Some NICs have dedicated timer
-device to perform this task. STMMAC can use either the RTC device or the TMU
-channel 2 on STLinux platforms.
+Instead of having the device that asynchronously notifies the frame receptions,
+the driver configures a timer to generate an interrupt at regular intervals.
+Based on the granularity of the timer, the frames that are received by the
+device will experience different levels of latency. Some NICs have dedicated
+timer device to perform this task. STMMAC can use either the RTC device or the
+TMU channel 2 on STLinux platforms.
The timers frequency can be passed to the driver as parameter; when change it,
take care of both hardware capability and network stability/performance impact.
-Several performance tests on STM platforms showed this optimisation allows to spare
-the CPU while having the maximum throughput.
+Several performance tests on STM platforms showed this optimisation allows to
+spare the CPU while having the maximum throughput.
4.4) WOL
-Wake up on Lan feature through Magic and Unicast frames are supported for the GMAC
-core.
+Wake up on Lan feature through Magic and Unicast frames are supported for the
+GMAC core.
4.5) DMA descriptors
Driver handles both normal and enhanced descriptors. The latter has been only
@@ -106,7 +106,8 @@ Several driver's information can be passed through the platform
These are included in the include/linux/stmmac.h header file
and detailed below as well:
- struct plat_stmmacenet_data {
+struct plat_stmmacenet_data {
+ char *phy_bus_name;
int bus_id;
int phy_addr;
int interface;
@@ -122,21 +123,27 @@ and detailed below as well:
int force_sf_dma_mode;
void (*fix_mac_speed)(void *priv, unsigned int speed);
void *(*bus_setup)(void __iomem *ioaddr, struct device *dev, void *d);
+ void *bus_data;
int (*init)(struct platform_device *pdev);
void (*exit)(struct platform_device *pdev);
+ void *custom_cfg;
+ void *custom_data;
void *bsp_priv;
- };
+};
Where:
+ o phy_bus_name: phy bus name to attach to the stmmac.
o bus_id: bus identifier.
o phy_addr: the physical address can be passed from the platform.
If it is set to -1 the driver will automatically
detect it at run-time by probing all the 32 addresses.
o interface: PHY device's interface.
o mdio_bus_data: specific platform fields for the MDIO bus.
- o pbl: the Programmable Burst Length is maximum number of beats to
+ o dma_cfg: internal DMA parameters
+ o pbl: the Programmable Burst Length is maximum number of beats to
be transferred in one DMA transaction.
GMAC also enables the 4xPBL by default.
+ o fixed_burst/mixed_burst/burst_len
o clk_csr: fixed CSR Clock range selection.
o has_gmac: uses the GMAC core.
o enh_desc: if sets the MAC will use the enhanced descriptor structure.
@@ -161,8 +168,9 @@ Where:
this is sometime necessary on some platforms (e.g. ST boxes)
where the HW needs to have set some PIO lines or system cfg
registers.
- o custom_cfg: this is a custom configuration that can be passed while
- initialising the resources.
+ o custom_cfg/custom_data: this is a custom configuration that can be passed
+ while initialising the resources.
+ o bsp_priv: another private poiter.
For MDIO bus The we have:
@@ -181,7 +189,6 @@ Where:
o irqs: list of IRQs, one per PHY.
o probed_phy_irq: if irqs is NULL, use this for probed PHY.
-
For DMA engine we have the following internal fields that should be
tuned according to the HW capabilities.
--
1.7.4.4
^ permalink raw reply related
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