* Re: [PATCH] gianfar v3: implement nfc
From: David Miller @ 2011-06-17 3:31 UTC (permalink / raw)
To: sebastian.belden; +Cc: netdev, bhutchings, sebastian.poehn
In-Reply-To: <1308064750.13416.15.camel@DENEC1DT0191>
From: "Sebastian Pöhn" <sebastian.belden@googlemail.com>
Date: Tue, 14 Jun 2011 17:19:10 +0200
> + list_for_each_entry(comp, &priv->rx_list.list, list)
> + {
Please put the openning brace at the end of the previous line.
You did this in several locations of the patch.
^ permalink raw reply
* RE: [PATCH v2] net/r8169: update the new parser for the new firmware
From: hayeswang @ 2011-06-17 3:25 UTC (permalink / raw)
To: 'Francois Romieu'; +Cc: netdev, linux-kernel
In-Reply-To: <20110616225904.GA2064@electric-eye.fr.zoreil.com>
> -----Original Message-----
> From: Francois Romieu [mailto:romieu@fr.zoreil.com]
> Sent: Friday, June 17, 2011 6:59 AM
> To: Hayeswang
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2] net/r8169: update the new parser for
> the new firmware
>
> Hayes Wang <hayeswang@realtek.com> :
> > Update the parser for the new firmware which is embedded
> some information.
>
> I have modified several things :
> - s/u32/__le32/ in fw_info
> - fix unsigned (size_t) comparisons
> - more size checks before dereferencing fw_info
>
Thanks. They are fine.
> The new firmware format should be the same. The old
> r8168d-1.fw firmware proved usable when prefixed with :
>
> 0000000: 0000 0000 3031 0000 0000 0000 0000 0000 ....01..........
> 0000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0000020: 0000 0000 3000 0000 7501 0000 a000 0000 ....0...u.......
>
> I realized after testing that netif_err could be abused with
> non-string fw_info.version. :o/
>
Excuse me. I don't understand what you want to express. Do you mean the
situation of the old paser with the new firmware for checking the firmware? For
the normal situation, the old paser would not use the new firmware. And I put
zero in front of the new firmware to prevent the old paser from running it. That
is all I do.
If you don't mean that, I could promise the new firmware I release would contain
the valid string unless someone modifies it.
> Comments ?
>
Best Regards,
Hayes
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: Remove casts of void *
From: David Miller @ 2011-06-17 3:23 UTC (permalink / raw)
To: joe
Cc: netdev, kaber, sage, samuel, paul.moore, vladislav.yasevich, sri,
linux-kernel, ceph-devel, linux-decnet-user, linux-sctp
In-Reply-To: <d010144f11f9165670ac0c9e3559bf5e3191ff28.1308017857.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Mon, 13 Jun 2011 19:21:26 -0700
> Unnecessary casts of void * clutter the code.
>
> These are the remainder casts after several specific
> patches to remove netdev_priv and dev_priv.
>
> Done via coccinelle script:
>
> $ cat cast_void_pointer.cocci
> @@
> type T;
> T *pt;
> void *pv;
> @@
>
> - pt = (T *)pv;
> + pt = pv;
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: remove mm.h inclusion from netdevice.h
From: Stephen Rothwell @ 2011-06-17 3:19 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: davem, netdev, linux-kernel, fujita.tomonori, linux-arch
In-Reply-To: <20110616210134.GA18026@p183.telecom.by>
[-- Attachment #1: Type: text/plain, Size: 437 bytes --]
Hi Alexy,
On Fri, 17 Jun 2011 00:01:34 +0300 Alexey Dobriyan <adobriyan@gmail.com> wrote:
>
> Remove linux/mm.h inclusion from netdevice.h -- it's unused (I've checked manually).
Have you tried building this with STAGING enabled? The fallout for
STAGING from the removal of linux/interrupt.h is still not sorted out.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] IGMP snooping: set mrouters_only flag for IPv6 traffic properly
From: David Miller @ 2011-06-17 3:14 UTC (permalink / raw)
To: fernando; +Cc: herbert, shemminger, netdev, yoshfuji
In-Reply-To: <1308013618.3896.11.camel@nexus.oss.ntt.co.jp>
From: Fernando Luis Vázquez Cao <fernando@oss.ntt.co.jp>
Date: Tue, 14 Jun 2011 10:06:58 +0900
> Upon reception of a MGM report packet the kernel sets the mrouters_only flag
> in a skb that is a clone of the original skb, which means that the bridge
> loses track of MGM packets (cb buffers are tied to a specific skb and not
> shared) and it ends up forwading join requests to the bridge interface.
>
> This can cause unexpected membership timeouts and intermitent/permanent loss
> of connectivity as described in RFC 4541 [2.1.1. IGMP Forwarding Rules]:
>
> A snooping switch should forward IGMP Membership Reports only to
> those ports where multicast routers are attached.
> [...]
> Sending membership reports to other hosts can result, for IGMPv1
> and IGMPv2, in unintentionally preventing a host from joining a
> specific multicast group.
>
>
> Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] IGMP snooping: set mrouters_only flag for IPv4 traffic properly
From: David Miller @ 2011-06-17 3:14 UTC (permalink / raw)
To: fernando; +Cc: herbert, shemminger, netdev, kakuta.hayato
In-Reply-To: <1308013483.3896.9.camel@nexus.oss.ntt.co.jp>
From: Fernando Luis Vázquez Cao <fernando@oss.ntt.co.jp>
Date: Tue, 14 Jun 2011 10:04:43 +0900
> Upon reception of a IGMP/IGMPv2 membership report the kernel sets the
> mrouters_only flag in a skb that may be a clone of the original skb, which
> means that sometimes the bridge loses track of membership report packets (cb
> buffers are tied to a specific skb and not shared) and it ends up forwading
> join requests to the bridge interface.
>
> This can cause unexpected membership timeouts and intermitent/permanent loss
> of connectivity as described in RFC 4541 [2.1.1. IGMP Forwarding Rules]:
>
> A snooping switch should forward IGMP Membership Reports only to
> those ports where multicast routers are attached.
> [...]
> Sending membership reports to other hosts can result, for IGMPv1
> and IGMPv2, in unintentionally preventing a host from joining a
> specific multicast group.
>
>
> Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
> Tested-by: Hayato Kakuta <kakuta.hayato@oss.ntt.co.jp>
Applied.
^ permalink raw reply
* Re: [PATCH] sky2: avoid using uninitialized variable
From: David Miller @ 2011-06-17 3:10 UTC (permalink / raw)
To: shemminger; +Cc: gthelen, shemminger, netdev, linux-kernel
In-Reply-To: <20110614000230.4166a1ae@s6510.ftrdhcpuser.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Tue, 14 Jun 2011 00:02:30 -0400
> In my experience if phy reads once successfully, it is going
> to read every time. If there is a problem it only happens on
> the first access (powered off, bad timing, etc).
It also happens when the PHY can't get a response for a certain
register, for whatever reason, before internal hw timeouts trigger.
Please, check all MII accesses. That's what I do in every driver
I've written.
^ permalink raw reply
* Re: [PATCH] net: sh_eth: tidyup compile warrning
From: David Miller @ 2011-06-17 3:08 UTC (permalink / raw)
To: morimoto.kuninori; +Cc: netdev, yoshihiro.shimoda.uh
In-Reply-To: <w3p62oa6t8a.wl%kuninori.morimoto.gx@renesas.com>
From: Kuninori Morimoto <morimoto.kuninori@renesas.com>
Date: Mon, 13 Jun 2011 17:17:09 +0900
> This patch tidyup below warrning
>
> ${LINUX}/drivers/net/sh_eth.c:1773: warning:
> 'mdp' may be used uninitialized in this function
>
> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Signed-off-by: Kuninori Morimoto <morimoto.kuninori@renesas.com>
Please just move the mdp assignment right after alloc_netdev()
succeeds.
^ permalink raw reply
* Re: [PATCH] be2net: fix netdev_stats_update()
From: David Miller @ 2011-06-17 3:06 UTC (permalink / raw)
To: Sathya.Perla; +Cc: eric.dumazet, netdev
In-Reply-To: <3367B80B08154D42A3B2BC708B5D41F63F18593D4F@EXMAIL.ad.emulex.com>
From: <Sathya.Perla@Emulex.Com>
Date: Mon, 13 Jun 2011 00:09:38 -0700
> Dave, I would prefer to send a separate patch fixing the netdev
> stats issue after you apply this multiple TXQ patch. Are you OK with
> that?
Sure.
^ permalink raw reply
* Re: [PATCH net-next-2.6] be2net: support multiple TX queues
From: David Miller @ 2011-06-17 3:02 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <f67e2aac-b763-404d-8e45-5c5f52c56d18@exht1.ad.emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Mon, 13 Jun 2011 11:31:58 +0530
> This patch provides support for multiple TX queues.
>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] macvtap: remove wrong sock_put() in macvtap_put_queue()
From: David Miller @ 2011-06-17 2:58 UTC (permalink / raw)
To: jasowang; +Cc: arnd, netdev, linux-kernel
In-Reply-To: <1307934919-4189-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Mon, 13 Jun 2011 11:15:19 +0800
> The calling of sock_put() should be delayed after synchronize_rcu(),
> otherwise inconsist data may be seen during packets transmitting.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
You're leaking sockets now.
This function has to release the socket twice if there is
a non-NULL vlan assigned to the queue.
Now you're only doing it once in that situation.
Which probably fixes your crash, but adds a socket leak.
^ permalink raw reply
* (unknown),
From: Mr. Vincent Cheng @ 2011-06-17 2:18 UTC (permalink / raw)
Good Day,
I am Mr. Vincent Cheng Hoi Chuen, GBS, JP Chairman of the Hong Kong and
Shanghai Banking Corporation Limited.i have a business proposal of Twenty
Two million Five Hundred Thousand United State Dollars only for you to
transact with me from my bank to your country.
All confirmable documents to back up the claims will be made available to
you prior to your acceptance and as soon as I receive your return mail and
I will let you know what is required of you.
Your earliest response to this letter will be appreciated.
Best Regards,
Mr. Vincent Cheng
^ permalink raw reply
* Re: [PATCH] net/usb: Add Samsung Kalmia driver for Samsung GT-B3730
From: David Miller @ 2011-06-17 2:01 UTC (permalink / raw)
To: marius.kotsbak; +Cc: netdev, linux-usb, marius
In-Reply-To: <1307882102-31659-1-git-send-email-marius@kotsbak.com>
From: "Marius B. Kotsbak" <marius.kotsbak@gmail.com>
Date: Sun, 12 Jun 2011 14:35:02 +0200
> Introducing driver for the network port of Samsung Kalmia based USB LTE modems.
> It has also an ACM interface that previous patches associates with the "option"
> module. To access those interfaces, the modem must first be switched from modem
> mode using a tool like usb_modeswitch.
>
> As the proprietary protocol has been discovered by watching the MS Windows driver
> behavior, there might be errors in the protocol handling, but stable and fast
> connection has been established for hours with Norwegian operator NetCom that
> distributes this modem with their LTE/4G subscription.
>
> More and updated information about how to use this driver is available here:
>
> http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?t=465
> https://github.com/mkotsbak/Samsung-GT-B3730-linux-driver
>
> Signed-off-by: Marius B. Kotsbak <marius@kotsbak.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 00/20] netfilter: netfilter update
From: David Miller @ 2011-06-17 1:54 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel, netdev
In-Reply-To: <1308253640-29942-1-git-send-email-kaber@trash.net>
From: kaber@trash.net
Date: Thu, 16 Jun 2011 21:47:00 +0200
> Hi Dave,
>
> following is a netfilter update for nf-next-2.6.git, containing
>
> - IPVS cleanups from Hans
>
> - a big ipset update from Jozsef
>
> - support for more FTP PASV responses in the IPVS FTP helper, from Julian
>
>
> Please apply or pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-next-2.6.git master
Pulled, thanks!
^ permalink raw reply
* Re: [PATCH 0/8] netfilter: netfilter fixes for -rc1
From: David Miller @ 2011-06-17 1:43 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel, netdev
In-Reply-To: <1308253301-29894-1-git-send-email-kaber@trash.net>
From: kaber@trash.net
Date: Thu, 16 Jun 2011 21:41:35 +0200
> Please apply or pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git master
Pulled, thanks Patrick.
^ permalink raw reply
* [PATCH] iptables: document IPv6 TOS mangling bug in old Linux kernels
From: Fernando Luis Vázquez Cao @ 2011-06-17 1:14 UTC (permalink / raw)
To: Patrick McHardy, Jan Engelhardt
Cc: Maciej, Pablo Neira Aysuo, Netfilter Developer Mailing List,
Linux Networking Developer Mailing List
In-Reply-To: <1308273097.8612.1.camel@nexus.oss.ntt.co.jp>
In Linux kernels up to and including 2.6.38, with the exception of longterm
releases 2.6.32.42 (or later) and 2.6.33.15 (or later), there is a bug (*) whereby
IPv6 TOS mangling does not behave as documented and differs from the IPv4
version. The TOS mask indicates the bits one wants to zero out, so it needs to
be inverted before applying it to the original TOS field. However, the
aformentioned kernels forgo the inversion which breaks --set-tos and its
mnemonics.
(*) Fixed by upstream commit:
1ed2f73d90fb49bcf5704aee7e9084adb882bfc5 (netfilter: IPv6: fix DSCP mangle code)
Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
---
diff -urNp iptables-1.4.11.1-orig/extensions/libxt_TOS.man iptables-1.4.11.1/extensions/libxt_TOS.man
--- iptables-1.4.11.1-orig/extensions/libxt_TOS.man 2011-06-08 22:26:17.000000000 +0900
+++ iptables-1.4.11.1/extensions/libxt_TOS.man 2011-06-17 10:07:58.873127519 +0900
@@ -4,24 +4,33 @@ shares the same bits as DSCP and ECN. Th
\fBmangle\fP table.
.TP
\fB\-\-set\-tos\fP \fIvalue\fP[\fB/\fP\fImask\fP]
-Zeroes out the bits given by \fImask\fP and XORs \fIvalue\fP into the
-TOS/Priority field. If \fImask\fP is omitted, 0xFF is assumed.
+Zeroes out the bits given by \fImask\fP (see NOTE below) and XORs \fIvalue\fP
+into the TOS/Priority field. If \fImask\fP is omitted, 0xFF is assumed.
.TP
\fB\-\-set\-tos\fP \fIsymbol\fP
You can specify a symbolic name when using the TOS target for IPv4. It implies
-a mask of 0xFF. The list of recognized TOS names can be obtained by calling
-iptables with \fB\-j TOS \-h\fP.
+a mask of 0xFF (see NOTE below). The list of recognized TOS names can be
+obtained by calling iptables with \fB\-j TOS \-h\fP.
.PP
The following mnemonics are available:
.TP
\fB\-\-and\-tos\fP \fIbits\fP
Binary AND the TOS value with \fIbits\fP. (Mnemonic for \fB\-\-set\-tos
-0/\fP\fIinvbits\fP, where \fIinvbits\fP is the binary negation of \fIbits\fP.)
+0/\fP\fIinvbits\fP, where \fIinvbits\fP is the binary negation of \fIbits\fP.
+See NOTE below.)
.TP
\fB\-\-or\-tos\fP \fIbits\fP
Binary OR the TOS value with \fIbits\fP. (Mnemonic for \fB\-\-set\-tos\fP
-\fIbits\fP\fB/\fP\fIbits\fP.)
+\fIbits\fP\fB/\fP\fIbits\fP. See NOTE below.)
.TP
\fB\-\-xor\-tos\fP \fIbits\fP
Binary XOR the TOS value with \fIbits\fP. (Mnemonic for \fB\-\-set\-tos\fP
-\fIbits\fP\fB/0\fP.)
+\fIbits\fP\fB/0\fP. See NOTE below.)
+.PP
+NOTE: In Linux kernels up to and including 2.6.38, with the exception of
+longterm releases 2.6.32.42 (or later) and 2.6.33.15 (or later), there is a bug
+whereby IPv6 TOS mangling does not behave as documented and differs from the
+IPv4 version. The TOS mask indicates the bits one wants to zero out, so it needs
+to be inverted before applying it to the original TOS field. However, the
+aformentioned kernels forgo the inversion which breaks --set-tos and its
+mnemonics.
^ permalink raw reply
* Re: [PATCH] iptables: document IPv6 TOS mangling bug in old Linux kernels
From: Fernando Luis Vázquez Cao @ 2011-06-17 1:11 UTC (permalink / raw)
To: Patrick McHardy
Cc: Jan Engelhardt, Maciej, Pablo Neira Aysuo,
Netfilter Developer Mailing List,
Linux Networking Developer Mailing List
In-Reply-To: <4DFA1DFC.3000804@trash.net>
Hi Jan, Patrick,
On Thu, 2011-06-16 at 17:15 +0200, Patrick McHardy wrote:
> On 16.06.2011 17:06, Jan Engelhardt wrote:
> > I feel this should be listed in the TOS page, to avoid duplication.
>
> I agree with Jan, just the TOS man page seems fine.
I will be replying to this email with the update patch.
Thanks,
Fernando
^ permalink raw reply
* Re: [PATCH 05/14] SIWv2: User interface: siw_verbs.h, siw_verbs.c, siw_user.h, siw_ae.c
From: Andi Kleen @ 2011-06-17 0:14 UTC (permalink / raw)
To: Bernard Metzler
Cc: public-netdev-u79uwXL29TY76Z2rM5mHXA,
public-linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1308228127-22634-1-git-send-email-bmt@zurich.ibm.com>
Bernard Metzler <bmt-OA+xvbQnYDHMbYB6QlFGEg@public.gmane.org> writes:
> +
> +/*
> + * siw_async_ev()
> + *
> + * Report Asynchonous event to user.
> + */
> +void siw_async_ev(struct siw_qp *qp, struct siw_cq *cq,
> + enum ib_event_type etype)
> +{
> + static struct ib_event event;
Static? That looks scary, especially without a lock.
-Andi
--
ak@linux.intel.com -- Speaking for myself only
^ permalink raw reply
* RE: [RFC 2/2] ethtool: Add support for DMA Coalescing feature config to ethtool.
From: Ben Hutchings @ 2011-06-16 23:53 UTC (permalink / raw)
To: Wyborny, Carolyn; +Cc: netdev@vger.kernel.org
In-Reply-To: <EDC0E76513226749BFBC9C3FB031318F016C7DEB5B@orsmsx508.amr.corp.intel.com>
On Tue, 2011-06-14 at 13:19 -0700, Wyborny, Carolyn wrote:
[...]
> Ok, will send up update with the suggested changes and an
> implementation as an example. I have one, but will wait to synch it
> with the updated patch. Do you want another RFC or a regular patch
> submission?
That's really for you to decide.
Ben.
--
Ben Hutchings, Senior Software 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 net-next-2.6] net: rfs: enable RFS before first data packet is received
From: Ben Hutchings @ 2011-06-16 23:50 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Tom Herbert, David Miller, netdev, jamal
In-Reply-To: <1308104128.4578.10.camel@edumazet-laptop>
On Wed, 2011-06-15 at 04:15 +0200, Eric Dumazet wrote:
> First packet received on a passive tcp flow is not correctly RFS
> steered.
>
> One sock_rps_record_flow() call is missing in inet_accept()
>
> But before that, we also must record rxhash when child socket is setup.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Tom Herbert <therbert@google.com>
> CC: Ben Hutchings <bhutchings@solarflare.com>
> CC: Jamal Hadi Salim <hadi@cyberus.ca>
> ---
> Netconf2011 workshop ;)
>
> net/ipv4/af_inet.c | 1 +
> net/ipv4/tcp_ipv4.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index 83673d2..0600f0f 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -676,6 +676,7 @@ int inet_accept(struct socket *sock, struct socket *newsock, int flags)
>
> lock_sock(sk2);
>
> + sock_rps_record_flow(sk2);
> WARN_ON(!((1 << sk2->sk_state) &
> (TCPF_ESTABLISHED | TCPF_CLOSE_WAIT | TCPF_CLOSE)));
>
> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> index 617dee3..955b8e6 100644
> --- a/net/ipv4/tcp_ipv4.c
> +++ b/net/ipv4/tcp_ipv4.c
> @@ -1594,6 +1594,7 @@ int tcp_v4_do_rcv(struct sock *sk, struct sk_buff *skb)
> goto discard;
>
> if (nsk != sk) {
> + sock_rps_save_rxhash(nsk, skb->rxhash);
> if (tcp_child_process(sk, nsk, skb)) {
> rsk = nsk;
> goto reset;
>
I haven't tried this, but it looks reasonable to me.
What about IPv6? The logic in tcp_v6_do_rcv() looks very similar.
Ben.
--
Ben Hutchings, Senior Software 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 v2] net/r8169: update the new parser for the new firmware
From: Francois Romieu @ 2011-06-16 22:59 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, linux-kernel
In-Reply-To: <1308109531-31698-1-git-send-email-hayeswang@realtek.com>
Hayes Wang <hayeswang@realtek.com> :
> Update the parser for the new firmware which is embedded some information.
I have modified several things :
- s/u32/__le32/ in fw_info
- fix unsigned (size_t) comparisons
- more size checks before dereferencing fw_info
The new firmware format should be the same. The old r8168d-1.fw firmware
proved usable when prefixed with :
0000000: 0000 0000 3031 0000 0000 0000 0000 0000 ....01..........
0000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000020: 0000 0000 3000 0000 7501 0000 a000 0000 ....0...u.......
I realized after testing that netif_err could be abused with non-string
fw_info.version. :o/
Comments ?
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 7310824..5a0a7c3 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1741,21 +1741,82 @@ static void rtl_writephy_batch(struct rtl8169_private *tp,
#define PHY_DELAY_MS 0xe0000000
#define PHY_WRITE_ERI_WORD 0xf0000000
+struct fw_info {
+ u32 magic;
+ char version[32];
+ __le32 fw_start;
+ __le32 fw_len;
+ u8 chksum;
+} __packed;
+
+struct fw_phy_code {
+ __le32 *code;
+ size_t size;
+};
+
+#define FW_OPCODE_SIZE sizeof(typeof(*((struct fw_phy_code *)0)->code))
+
+static bool rtl_fw_format_ok(struct rtl8169_private *tp, struct net_device *dev,
+ const struct firmware *fw, struct fw_phy_code *pc)
+{
+ struct fw_info *fw_info = (struct fw_info *)fw->data;
+ bool rc = false;
+
+ if (fw->size < FW_OPCODE_SIZE)
+ goto out;
+
+ if (fw_info->magic == 0) {
+ size_t i, size, start;
+ u8 checksum = 0;
+
+ if (fw->size < sizeof(*fw_info))
+ goto out;
+
+ for (i = 0; i < fw->size; i++)
+ checksum += fw->data[i];
+ if (checksum != 0)
+ goto out;
+
+ start = le32_to_cpu(fw_info->fw_start);
+ if (start > fw->size)
+ goto out;
+
+ size = le32_to_cpu(fw_info->fw_len);
+ if (size > (fw->size - start) / FW_OPCODE_SIZE)
+ goto out;
+
+ netif_info(tp, probe, dev, "firmware: %s\n", fw_info->version);
+ pc->code = (__le32 *)(fw->data + start);
+ pc->size = size;
+ } else {
+ if (fw->size % FW_OPCODE_SIZE)
+ goto out;
+
+ netif_info(tp, probe, dev, "legacy firmware format detected\n");
+ pc->code = (__le32 *)fw->data;
+ pc->size = fw->size / FW_OPCODE_SIZE;
+ }
+
+ rc = true;
+out:
+ return rc;
+}
+
static void
rtl_phy_write_fw(struct rtl8169_private *tp, const struct firmware *fw)
{
- __le32 *phytable = (__le32 *)fw->data;
struct net_device *dev = tp->dev;
- size_t index, fw_size = fw->size / sizeof(*phytable);
+ struct fw_phy_code phytable;
u32 predata, count;
+ size_t i;
- if (fw->size % sizeof(*phytable)) {
- netif_err(tp, probe, dev, "odd sized firmware %zd\n", fw->size);
+ if (!rtl_fw_format_ok(tp, dev, fw, &phytable)) {
+ netif_err(tp, probe, dev, "invalid firwmare\n");
return;
}
- for (index = 0; index < fw_size; index++) {
- u32 action = le32_to_cpu(phytable[index]);
+ for (i = 0; i < phytable.size; i++) {
+ u32 action = le32_to_cpu(phytable.code[i]);
u32 regno = (action & 0x0fff0000) >> 16;
switch(action & 0xf0000000) {
@@ -1770,14 +1831,14 @@ rtl_phy_write_fw(struct rtl8169_private *tp, const struct firmware *fw)
break;
case PHY_BJMPN:
- if (regno > index) {
+ if (regno > i) {
netif_err(tp, probe, tp->dev,
"Out of range of firmware\n");
return;
}
break;
case PHY_READCOUNT_EQ_SKIP:
- if (index + 2 >= fw_size) {
+ if (i + 2 >= phytable.size) {
netif_err(tp, probe, tp->dev,
"Out of range of firmware\n");
return;
@@ -1786,7 +1847,7 @@ rtl_phy_write_fw(struct rtl8169_private *tp, const struct firmware *fw)
case PHY_COMP_EQ_SKIPN:
case PHY_COMP_NEQ_SKIPN:
case PHY_SKIPN:
- if (index + 1 + regno >= fw_size) {
+ if (i + 1 + regno >= phytable.size) {
netif_err(tp, probe, tp->dev,
"Out of range of firmware\n");
return;
@@ -1806,8 +1867,8 @@ rtl_phy_write_fw(struct rtl8169_private *tp, const struct firmware *fw)
predata = 0;
count = 0;
- for (index = 0; index < fw_size; ) {
- u32 action = le32_to_cpu(phytable[index]);
+ for (i = 0; i < phytable.size; ) {
+ u32 action = le32_to_cpu(phytable.code[i]);
u32 data = action & 0x0000ffff;
u32 regno = (action & 0x0fff0000) >> 16;
@@ -1818,54 +1879,54 @@ rtl_phy_write_fw(struct rtl8169_private *tp, const struct firmware *fw)
case PHY_READ:
predata = rtl_readphy(tp, regno);
count++;
- index++;
+ i++;
break;
case PHY_DATA_OR:
predata |= data;
- index++;
+ i++;
break;
case PHY_DATA_AND:
predata &= data;
- index++;
+ i++;
break;
case PHY_BJMPN:
- index -= regno;
+ i -= regno;
break;
case PHY_READ_EFUSE:
predata = rtl8168d_efuse_read(tp->mmio_addr, regno);
- index++;
+ i++;
break;
case PHY_CLEAR_READCOUNT:
count = 0;
- index++;
+ i++;
break;
case PHY_WRITE:
rtl_writephy(tp, regno, data);
- index++;
+ i++;
break;
case PHY_READCOUNT_EQ_SKIP:
- index += (count == data) ? 2 : 1;
+ i += (count == data) ? 2 : 1;
break;
case PHY_COMP_EQ_SKIPN:
if (predata == data)
- index += regno;
- index++;
+ i += regno;
+ i++;
break;
case PHY_COMP_NEQ_SKIPN:
if (predata != data)
- index += regno;
- index++;
+ i += regno;
+ i++;
break;
case PHY_WRITE_PREVIOUS:
rtl_writephy(tp, regno, predata);
- index++;
+ i++;
break;
case PHY_SKIPN:
- index += regno + 1;
+ i += regno + 1;
break;
case PHY_DELAY_MS:
mdelay(data);
- index++;
+ i++;
break;
case PHY_READ_MAC_BYTE:
^ permalink raw reply related
* Re: rionet: NULL pointer dereference
From: Jesper Juhl @ 2011-06-16 22:51 UTC (permalink / raw)
To: Connor Hansen; +Cc: linux-kernel, Matt Porter, netdev, David S. Miller
In-Reply-To: <BANLkTimwzbB9ZwbG3u=oRNAHSECioEJ3dQ@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1813 bytes --]
On Thu, 16 Jun 2011, Connor Hansen wrote:
> On Thu, Jun 16, 2011 at 3:06 PM, Jesper Juhl <jj@chaosbits.net> wrote:
> > Hi
> >
> > Just noticed that drivers/net/rionet.c::rionet_remove() can cause a NULL
> > deref when it calls unregister_netdev().
> > It initializes local variable 'ndev' to NULL and nothing changes this
> > before the call to unregister_netdev(ndev) - that functions then calls:
> > unregister_netdevice > unregister_netdevice_queue > list_move_tail >
> > __list_del_entry which dereferences the pointer (which, being NULL, will
> > end in tears).
>
> unregister_netdevice(struct net_device *dev)
> {
> unregister_netdevice_queue(dev, NULL);
> }
>
> so unregister_netdevice_queue is being called with NULL,NULL
>
> void unregister_netdevice_queue(struct net_device *dev, struct list_head *head)
> {
> ASSERT_RTNL();
>
> if (head) {
> list_move_tail(&dev->unreg_list, head);
> } else {
> rollback_registered(dev);
> /* Finish processing unregister after unlock */
> net_set_todo(dev);
> }
> }
>
> if head is null, which it is from the call, then we call
> rollback_registered, and not list_move_tail()
>
> the else calls rollback_registered(NULL) then net_set_todo(NULL)
>
> both of which dereference null when passed, so yes there is a null
> dereference, just not in the code branch you thought.
>
Ahh crap, you are right. Too much coffee and too late to be reading kernel
code is my only excuse ;-)
Thanks for taking the time to look and correct me.
In any case, there's still a problem that needs to be fixed.
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply
* RE: [Pv-drivers] [PATCH] vmxnet3: fix starving rx ring when alloc_skb fails
From: Bhavesh Davda @ 2011-06-16 22:56 UTC (permalink / raw)
To: Scott Goldman, netdev@vger.kernel.org, pv-drivers@vmware.com
In-Reply-To: <1308261747-17702-1-git-send-email-scottjg@vmware.com>
LGTM.
Signed-off-by: Bhavesh Davda <bhavesh@vmware.com>
> -----Original Message-----
> From: pv-drivers-bounces@vmware.com [mailto:pv-drivers-bounces@vmware.com] On
> Behalf Of Scott J. Goldman
> Sent: Thursday, June 16, 2011 3:02 PM
> To: netdev@vger.kernel.org; pv-drivers@vmware.com
> Subject: [Pv-drivers] [PATCH] vmxnet3: fix starving rx ring when alloc_skb
> fails
>
> if the rx ring is completely empty, then the device may never fire an rx
> interrupt. unfortunately, the rx interrupt is what triggers populating
> the rx ring with fresh buffers, so this will cause networking to lock
> up.
>
> this patch recycles the last skb that we were about to indicate up to
> the network stack (only if the rx ring is completely starved of skbs)
> so the ring will never be completely empty. If we fail to allocate a
> secondary page buffer, we just indicate a 0 length buffer to the device.
>
> Signed-off-by: Scott J. Goldman <scottjg@vmware.com>
> ---
> drivers/net/vmxnet3/vmxnet3_drv.c | 98 +++++++++++++++++++++++++-----------
> drivers/net/vmxnet3/vmxnet3_int.h | 5 +-
> 2 files changed, 70 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c
> b/drivers/net/vmxnet3/vmxnet3_drv.c
> index 33097ec..cfa9ff7 100644
> --- a/drivers/net/vmxnet3/vmxnet3_drv.c
> +++ b/drivers/net/vmxnet3/vmxnet3_drv.c
> @@ -558,6 +558,17 @@ vmxnet3_tq_cleanup_all(struct vmxnet3_adapter *adapter)
> vmxnet3_tq_cleanup(&adapter->tx_queue[i], adapter);
> }
>
> +static bool
> +vmxnet3_rq_empty(const struct vmxnet3_rx_queue *rq, u32 ring_idx)
> +{
> + const struct vmxnet3_cmd_ring *ring = &rq->rx_ring[ring_idx];
> + u32 i = ring->next2comp;
> + while (rq->buf_info[ring_idx][i].buf_type != VMXNET3_RX_BUF_SKB)
> + VMXNET3_INC_RING_IDX_ONLY(i, ring->size);
> +
> + return (i == ring->next2fill);
> +}
> +
> /*
> * starting from ring->next2fill, allocate rx buffers for the given ring
> * of the rx queue and update the rx desc. stop after @num_to_alloc
> buffers
> @@ -571,9 +582,12 @@ vmxnet3_rq_alloc_rx_buf(struct vmxnet3_rx_queue *rq, u32
> ring_idx,
> int num_allocated = 0;
> struct vmxnet3_rx_buf_info *rbi_base = rq->buf_info[ring_idx];
> struct vmxnet3_cmd_ring *ring = &rq->rx_ring[ring_idx];
> + struct vmxnet3_rx_ctx *ctx = &rq->rx_ctx;
> + bool alloc_skb_failed = false;
> u32 val;
> + u32 len;
>
> - while (num_allocated < num_to_alloc) {
> + while (num_allocated < num_to_alloc && !alloc_skb_failed) {
> struct vmxnet3_rx_buf_info *rbi;
> union Vmxnet3_GenericDesc *gd;
>
> @@ -586,7 +600,27 @@ vmxnet3_rq_alloc_rx_buf(struct vmxnet3_rx_queue *rq, u32
> ring_idx,
> NET_IP_ALIGN);
> if (unlikely(rbi->skb == NULL)) {
> rq->stats.rx_buf_alloc_failure++;
> - break;
> + alloc_skb_failed = true;
> + /*
> + * if allocation failed and ring is
> + * empty, we recycle the last skb we
> + * rx'ed so that we don't starve the
> + * rx ring
> + */
> + if (ctx->skb &&
> + vmxnet3_rq_empty(rq, ring_idx)) {
> + rbi->skb = ctx->skb;
> + ctx->skb = NULL;
> + skb_recycle_check(rbi->skb,
> + rbi->len +
> + NET_IP_ALIGN);
> + /*
> + * free any frags chained to
> + * the skb
> + */
> + __pskb_trim(rbi->skb, 0);
> + } else
> + break;
> }
> rbi->skb->dev = adapter->netdev;
>
> @@ -594,8 +628,10 @@ vmxnet3_rq_alloc_rx_buf(struct vmxnet3_rx_queue *rq, u32
> ring_idx,
> rbi->dma_addr = pci_map_single(adapter->pdev,
> rbi->skb->data, rbi->len,
> PCI_DMA_FROMDEVICE);
> + len = rbi->len;
> } else {
> /* rx buffer skipped by the device */
> + len = rbi->len;
> }
> val = VMXNET3_RXD_BTYPE_HEAD << VMXNET3_RXD_BTYPE_SHIFT;
> } else {
> @@ -606,13 +642,18 @@ vmxnet3_rq_alloc_rx_buf(struct vmxnet3_rx_queue *rq, u32
> ring_idx,
> rbi->page = alloc_page(GFP_ATOMIC);
> if (unlikely(rbi->page == NULL)) {
> rq->stats.rx_buf_alloc_failure++;
> - break;
> + len = 0;
> + } else {
> + rbi->dma_addr = pci_map_page(
> + adapter->pdev,
> + rbi->page, 0,
> + PAGE_SIZE,
> + PCI_DMA_FROMDEVICE);
> + len = rbi->len;
> }
> - rbi->dma_addr = pci_map_page(adapter->pdev,
> - rbi->page, 0, PAGE_SIZE,
> - PCI_DMA_FROMDEVICE);
> } else {
> /* rx buffers skipped by the device */
> + len = rbi->len;
> }
> val = VMXNET3_RXD_BTYPE_BODY << VMXNET3_RXD_BTYPE_SHIFT;
> }
> @@ -620,7 +661,7 @@ vmxnet3_rq_alloc_rx_buf(struct vmxnet3_rx_queue *rq, u32
> ring_idx,
> BUG_ON(rbi->dma_addr == 0);
> gd->rxd.addr = cpu_to_le64(rbi->dma_addr);
> gd->dword[2] = cpu_to_le32((ring->gen << VMXNET3_RXD_GEN_SHIFT)
> - | val | rbi->len);
> + | val | len);
>
> num_allocated++;
> vmxnet3_cmd_ring_adv_next2fill(ring);
> @@ -1148,7 +1189,6 @@ vmxnet3_rq_rx_complete(struct vmxnet3_rx_queue *rq,
> &rxComp);
> while (rcd->gen == rq->comp_ring.gen) {
> struct vmxnet3_rx_buf_info *rbi;
> - struct sk_buff *skb;
> int num_to_alloc;
> struct Vmxnet3_RxDesc *rxd;
> u32 idx, ring_idx;
> @@ -1168,7 +1208,7 @@ vmxnet3_rq_rx_complete(struct vmxnet3_rx_queue *rq,
> rbi = rq->buf_info[ring_idx] + idx;
>
> BUG_ON(rxd->addr != rbi->dma_addr ||
> - rxd->len != rbi->len);
> + (rxd->len != rbi->len && rbi->len != 0));
>
> if (unlikely(rcd->eop && rcd->err)) {
> vmxnet3_rx_error(rq, rcd, ctx, adapter);
> @@ -1198,8 +1238,7 @@ vmxnet3_rq_rx_complete(struct vmxnet3_rx_queue *rq,
> PCI_DMA_FROMDEVICE);
>
> skb_put(ctx->skb, rcd->len);
> - } else {
> - BUG_ON(ctx->skb == NULL);
> + } else if (ctx->skb) {
> /* non SOP buffer must be type 1 in most cases */
> if (rbi->buf_type == VMXNET3_RX_BUF_PAGE) {
> BUG_ON(rxd->btype != VMXNET3_RXD_BTYPE_BODY);
> @@ -1222,25 +1261,6 @@ vmxnet3_rq_rx_complete(struct vmxnet3_rx_queue *rq,
> }
> }
>
> - skb = ctx->skb;
> - if (rcd->eop) {
> - skb->len += skb->data_len;
> - skb->truesize += skb->data_len;
> -
> - vmxnet3_rx_csum(adapter, skb,
> - (union Vmxnet3_GenericDesc *)rcd);
> - skb->protocol = eth_type_trans(skb, adapter->netdev);
> -
> - if (unlikely(adapter->vlan_grp && rcd->ts)) {
> - vlan_hwaccel_receive_skb(skb,
> - adapter->vlan_grp, rcd->tci);
> - } else {
> - netif_receive_skb(skb);
> - }
> -
> - ctx->skb = NULL;
> - }
> -
> rcd_done:
> /* device may skip some rx descs */
> rq->rx_ring[ring_idx].next2comp = idx;
> @@ -1264,6 +1284,24 @@ rcd_done:
> }
> }
>
> + if (rcd->eop && ctx->skb) {
> + ctx->skb->len += ctx->skb->data_len;
> + ctx->skb->truesize += ctx->skb->data_len;
> +
> + vmxnet3_rx_csum(adapter, ctx->skb,
> + (union Vmxnet3_GenericDesc *)rcd);
> + ctx->skb->protocol = eth_type_trans(ctx->skb,
> + adapter->netdev);
> + if (unlikely(adapter->vlan_grp && rcd->ts)) {
> + vlan_hwaccel_receive_skb(ctx->skb,
> + adapter->vlan_grp,
> + rcd->tci);
> + } else {
> + netif_receive_skb(ctx->skb);
> + }
> + ctx->skb = NULL;
> + }
> +
> vmxnet3_comp_ring_adv_next2proc(&rq->comp_ring);
> vmxnet3_getRxComp(rcd,
> &rq->comp_ring.base[rq->comp_ring.next2proc].rcd, &rxComp);
> diff --git a/drivers/net/vmxnet3/vmxnet3_int.h
> b/drivers/net/vmxnet3/vmxnet3_int.h
> index 0e567c24..cb13ed7 100644
> --- a/drivers/net/vmxnet3/vmxnet3_int.h
> +++ b/drivers/net/vmxnet3/vmxnet3_int.h
> @@ -68,10 +68,10 @@
> /*
> * Version numbers
> */
> -#define VMXNET3_DRIVER_VERSION_STRING "1.1.9.0-k"
> +#define VMXNET3_DRIVER_VERSION_STRING "1.1.10.0-k"
>
> /* a 32-bit int, each byte encode a verion number in VMXNET3_DRIVER_VERSION
> */
> -#define VMXNET3_DRIVER_VERSION_NUM 0x01010900
> +#define VMXNET3_DRIVER_VERSION_NUM 0x01010A00
>
> #if defined(CONFIG_PCI_MSI)
> /* RSS only makes sense if MSI-X is supported. */
> @@ -255,7 +255,6 @@ struct vmxnet3_rx_buf_info {
>
> struct vmxnet3_rx_ctx {
> struct sk_buff *skb;
> - u32 sop_idx;
> };
>
> struct vmxnet3_rq_driver_stats {
> --
> 1.7.4.1
>
> _______________________________________________
> Pv-drivers mailing list
> Pv-drivers@vmware.com
> http://mailman2.vmware.com/mailman/listinfo/pv-drivers
^ permalink raw reply
* Re: rionet: NULL pointer dereference
From: Connor Hansen @ 2011-06-16 22:53 UTC (permalink / raw)
To: Jesper Juhl; +Cc: linux-kernel, Matt Porter, netdev, David S. Miller
In-Reply-To: <alpine.LNX.2.00.1106162359560.8140@swampdragon.chaosbits.net>
On Thu, Jun 16, 2011 at 3:06 PM, Jesper Juhl <jj@chaosbits.net> wrote:
> Hi
>
> Just noticed that drivers/net/rionet.c::rionet_remove() can cause a NULL
> deref when it calls unregister_netdev().
> It initializes local variable 'ndev' to NULL and nothing changes this
> before the call to unregister_netdev(ndev) - that functions then calls:
> unregister_netdevice > unregister_netdevice_queue > list_move_tail >
> __list_del_entry which dereferences the pointer (which, being NULL, will
> end in tears).
unregister_netdevice(struct net_device *dev)
{
unregister_netdevice_queue(dev, NULL);
}
so unregister_netdevice_queue is being called with NULL,NULL
void unregister_netdevice_queue(struct net_device *dev, struct list_head *head)
{
ASSERT_RTNL();
if (head) {
list_move_tail(&dev->unreg_list, head);
} else {
rollback_registered(dev);
/* Finish processing unregister after unlock */
net_set_todo(dev);
}
}
if head is null, which it is from the call, then we call
rollback_registered, and not list_move_tail()
the else calls rollback_registered(NULL) then net_set_todo(NULL)
both of which dereference null when passed, so yes there is a null
dereference, just not in the code branch you thought.
static void rollback_registered(struct net_device *dev)
{
LIST_HEAD(single);
list_add(&dev->unreg_list, &single); null dereference
rollback_registered_many(&single);
list_del(&single);
}
static void net_set_todo(struct net_device *dev)
{
list_add_tail(&dev->todo_list, &net_todo_list); null dereference
}
Connor
>
> I won't claim to know this code nor what the proper fix is; just thought
> i'd report it so someone else with more knowledge of this could perhaps
> come up with a fix.
>
> Have a nice day.
>
> --
> Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
> Don't top-post http://www.catb.org/jargon/html/T/top-post.html
> Plain text mails only, please.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* [PATCH] netdev: bfin_mac: fix memory leak when freeing dma descriptors
From: Mike Frysinger @ 2011-06-16 22:31 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: uclinux-dist-devel, Sonic Zhang
From: Sonic Zhang <sonic.zhang@analog.com>
The size of the desc array is not the size of the desc structure, so
when we try to free up things, we leak some parts.
Reported-by: Regis Dargent <rdargent@edevice.com>
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
drivers/net/bfin_mac.c | 20 ++++++++++----------
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/bfin_mac.c b/drivers/net/bfin_mac.c
index 68d45ba..6c019e1 100644
--- a/drivers/net/bfin_mac.c
+++ b/drivers/net/bfin_mac.c
@@ -52,13 +52,13 @@ MODULE_DESCRIPTION(DRV_DESC);
MODULE_ALIAS("platform:bfin_mac");
#if defined(CONFIG_BFIN_MAC_USE_L1)
-# define bfin_mac_alloc(dma_handle, size) l1_data_sram_zalloc(size)
-# define bfin_mac_free(dma_handle, ptr) l1_data_sram_free(ptr)
+# define bfin_mac_alloc(dma_handle, size, num) l1_data_sram_zalloc(size*num)
+# define bfin_mac_free(dma_handle, ptr, num) l1_data_sram_free(ptr)
#else
-# define bfin_mac_alloc(dma_handle, size) \
- dma_alloc_coherent(NULL, size, dma_handle, GFP_KERNEL)
-# define bfin_mac_free(dma_handle, ptr) \
- dma_free_coherent(NULL, sizeof(*ptr), ptr, dma_handle)
+# define bfin_mac_alloc(dma_handle, size, num) \
+ dma_alloc_coherent(NULL, size*num, dma_handle, GFP_KERNEL)
+# define bfin_mac_free(dma_handle, ptr, num) \
+ dma_free_coherent(NULL, sizeof(*ptr)*num, ptr, dma_handle)
#endif
#define PKT_BUF_SZ 1580
@@ -95,7 +95,7 @@ static void desc_list_free(void)
t = t->next;
}
}
- bfin_mac_free(dma_handle, tx_desc);
+ bfin_mac_free(dma_handle, tx_desc, CONFIG_BFIN_TX_DESC_NUM);
}
if (rx_desc) {
@@ -109,7 +109,7 @@ static void desc_list_free(void)
r = r->next;
}
}
- bfin_mac_free(dma_handle, rx_desc);
+ bfin_mac_free(dma_handle, rx_desc, CONFIG_BFIN_RX_DESC_NUM);
}
}
@@ -126,13 +126,13 @@ static int desc_list_init(void)
#endif
tx_desc = bfin_mac_alloc(&dma_handle,
- sizeof(struct net_dma_desc_tx) *
+ sizeof(struct net_dma_desc_tx),
CONFIG_BFIN_TX_DESC_NUM);
if (tx_desc == NULL)
goto init_error;
rx_desc = bfin_mac_alloc(&dma_handle,
- sizeof(struct net_dma_desc_rx) *
+ sizeof(struct net_dma_desc_rx),
CONFIG_BFIN_RX_DESC_NUM);
if (rx_desc == NULL)
goto init_error;
--
1.7.5.3
^ 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