* [PATCH] ks8851: suspend resume support
From: Arce, Abraham @ 2010-10-29 4:57 UTC (permalink / raw)
To: netdev@vger.kernel.org
Add suspend/resume support using default open/stop interface methods
to do hardware dependant operations.
On suspend, same low power state (soft power mode) will be kept, the
following blocks will be disabled:
- Internal PLL Clock
- Tx/Rx PHY
- MAC
- SPI Interface
Signed-off-by: Abraham Arce <x0066660@ti.com>
---
drivers/net/ks8851.c | 33 +++++++++++++++++++++++++++++++++
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ks8851.c b/drivers/net/ks8851.c
index 8a178bc..9d40e33 100644
--- a/drivers/net/ks8851.c
+++ b/drivers/net/ks8851.c
@@ -1570,6 +1570,37 @@ static int ks8851_read_selftest(struct ks8851_net *ks)
/* driver bus management functions */
+#ifdef CONFIG_PM
+static int ks8851_suspend(struct spi_device *spi, pm_message_t state)
+{
+ struct ks8851_net *ks = dev_get_drvdata(&spi->dev);
+ struct net_device *dev = ks->netdev;
+
+ if (netif_running(dev)) {
+ netif_device_detach(dev);
+ ks8851_net_stop(dev);
+ }
+
+ return 0;
+}
+
+static int ks8851_resume(struct spi_device *spi)
+{
+ struct ks8851_net *ks = dev_get_drvdata(&spi->dev);
+ struct net_device *dev = ks->netdev;
+
+ if (netif_running(dev)) {
+ ks8851_net_open(dev);
+ netif_device_attach(dev);
+ }
+
+ return 0;
+}
+#else
+#define ks8851_suspend NULL
+#define ks8851_resume NULL
+#endif
+
static int __devinit ks8851_probe(struct spi_device *spi)
{
struct net_device *ndev;
@@ -1710,6 +1741,8 @@ static struct spi_driver ks8851_driver = {
},
.probe = ks8851_probe,
.remove = __devexit_p(ks8851_remove),
+ .suspend = ks8851_suspend,
+ .resume = ks8851_resume,
};
static int __init ks8851_init(void)
--
1.5.4.3
^ permalink raw reply related
* Re: [PATCH 05/15] dec netdev: relocate DIGITAL based drivers to legacy
From: Maciej W. Rozycki @ 2010-10-29 5:46 UTC (permalink / raw)
To: David Miller; +Cc: paul.gortmaker, netdev
In-Reply-To: <alpine.LFD.2.00.1010290545270.25426@eddie.linux-mips.org>
On Fri, 29 Oct 2010, Maciej W. Rozycki wrote:
> > This is not about a specific bus technology, it's simply for
> > "really old stuff" so we can declutter the top-level of drivers/net
>
> Hmm, what's the difference between placing these drivers here or there
> and what's so particular about them that they cause clutter? I mean a
> mere high number of items does not cause a mess by itself -- the lack of
> order might.
I have given myself some food for thought and have come up with the
following proposal: how about simply classifying drivers according to the
physical layer they support or if multiple are, such as with the Ethernet
that is backwards compatible, the newest variation they do?
This would be no different to what we do wrt network protocols under
net/, so drivers would go to ethernet/, fasteth/, gbeth/, 10gbeth/, fddi/,
tokenring/, atm/, appletalk/, etc. (names up to debate if need be) as
applicable. This would scale well, avoid the need for arbitrary decisions
(is this piece legacy yet or not?) and automatically classify drivers as
more or less obsolescent too, as obviously none of the stuff under
ethernet/, fddi/ or tokenring/ can be reasonably recent unlike 10gbeth/.
Software stuff such as SLIP or PPP could go either into separate
subdirectories or grouped together under software/; I gather we have a few
such pieces only.
What do you think?
Maciej
^ permalink raw reply
* Re: [PATCH 05/15] dec netdev: relocate DIGITAL based drivers to legacy
From: David Miller @ 2010-10-29 5:47 UTC (permalink / raw)
To: macro; +Cc: paul.gortmaker, netdev
In-Reply-To: <alpine.LFD.2.00.1010290545270.25426@eddie.linux-mips.org>
From: "Maciej W. Rozycki" <macro@linux-mips.org>
Date: Fri, 29 Oct 2010 05:54:56 +0100 (BST)
> Hmm, what's the difference between placing these drivers here or there
> and what's so particular about them that they cause clutter? I mean a
> mere high number of items does not cause a mess by itself -- the lack of
> order might.
>
> Also -- if this change goes ahead -- when I add new TURBOchannel drivers,
> should they go straight to legacy/? It sounds odd to me to have a thing
> obsolete straight from the beginning.
This patch series started with a "0/15" introduction posting which
explains the intention and reasoning.
It might be easier for you to read it instead of asking me to repeat
it's contents :-)
^ permalink raw reply
* Re: [PATCH 05/15] dec netdev: relocate DIGITAL based drivers to legacy
From: Maciej W. Rozycki @ 2010-10-29 5:50 UTC (permalink / raw)
To: David Miller; +Cc: paul.gortmaker, netdev
In-Reply-To: <20101028.224703.112589527.davem@davemloft.net>
On Thu, 28 Oct 2010, David Miller wrote:
> This patch series started with a "0/15" introduction posting which
> explains the intention and reasoning.
Well, I didn't reach it (ENOBREAKFAST that has been fixed since ;) ), but
I sort of guessed it anyway and didn't like the arbitrary nature of
assigning drivers to legacy/.
> It might be easier for you to read it instead of asking me to repeat
> it's contents :-)
See my proposal that crossed with your e-mail. I think it fits the
purpose very well. :)
Maciej
^ permalink raw reply
* Re: [PATCH 05/15] dec netdev: relocate DIGITAL based drivers to legacy
From: David Miller @ 2010-10-29 5:53 UTC (permalink / raw)
To: macro; +Cc: paul.gortmaker, netdev
In-Reply-To: <alpine.LFD.2.00.1010290629450.25426@eddie.linux-mips.org>
From: "Maciej W. Rozycki" <macro@linux-mips.org>
Date: Fri, 29 Oct 2010 06:46:13 +0100 (BST)
> This would be no different to what we do wrt network protocols under
> net/, so drivers would go to ethernet/, fasteth/, gbeth/, 10gbeth/, fddi/,
> tokenring/, atm/, appletalk/, etc. (names up to debate if need be) as
> applicable. This would scale well, avoid the need for arbitrary decisions
> (is this piece legacy yet or not?) and automatically classify drivers as
> more or less obsolescent too, as obviously none of the stuff under
> ethernet/, fddi/ or tokenring/ can be reasonably recent unlike 10gbeth/.
Why are you so hung up about something being called legacy?
I would be proud to be labelled "legacy", as that means I've served a
purpose for a long time and some folks even want or need me to stick
around for a bit longer.
Legacy hardware is just old and the drivers for them are in a purely
"sustaining" state, that is all.
And using link layer technology to classify is really stupid since
many devices match multiple of the categories you've suggested.
I think the existing proposal is just fine.
^ permalink raw reply
* Re: [PATCH 05/15] dec netdev: relocate DIGITAL based drivers to legacy
From: David Miller @ 2010-10-29 5:53 UTC (permalink / raw)
To: macro; +Cc: paul.gortmaker, netdev
In-Reply-To: <alpine.LFD.2.00.1010290647270.25426@eddie.linux-mips.org>
From: "Maciej W. Rozycki" <macro@linux-mips.org>
Date: Fri, 29 Oct 2010 06:50:17 +0100 (BST)
> On Thu, 28 Oct 2010, David Miller wrote:
>
>> It might be easier for you to read it instead of asking me to repeat
>> it's contents :-)
>
> See my proposal that crossed with your e-mail. I think it fits the
> purpose very well. :)
No, it's foolish, see my reply.
^ permalink raw reply
* Re: [PATCH iproute2] Support 'mode' parameter when creating macvtap device
From: Arnd Bergmann @ 2010-10-29 6:27 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: Stephen Hemminger, Patrick McHardy, Michael S. Tsirkin, netdev,
kvm@vger.kernel.org l
In-Reply-To: <1288307440.30131.81.camel@sridhar.beaverton.ibm.com>
On Friday 29 October 2010, Sridhar Samudrala wrote:
> Add support for 'mode' parameter when creating a macvtap device.
> This allows a macvtap device to be created in bridge, private or
> the default vepa modes.
>
> Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH 05/15] dec netdev: relocate DIGITAL based drivers to legacy
From: Maciej W. Rozycki @ 2010-10-29 6:37 UTC (permalink / raw)
To: David Miller; +Cc: paul.gortmaker, netdev
In-Reply-To: <20101028.225356.39188490.davem@davemloft.net>
On Thu, 28 Oct 2010, David Miller wrote:
> > See my proposal that crossed with your e-mail. I think it fits the
> > purpose very well. :)
>
> No, it's foolish, see my reply.
Well, you are the maintainer, so it's your call. I disagree and I have
given what I believe is a reasonable justification, but that's about as
much as I can do -- I can't force it onto you. As I say my concern is
about the arbitrary assignment and not things being called "legacy" or
"best-ever", "pre-y2k", or whatever. And splitting a bunch of pieces of
software that are loosely related to one another into two bunches isn't
going to reduce clutter, but to spread it instead -- now you'll have
clutter in two places rather than just one, so I think the change is just
missing the point. Again, as the maintainer it's your right to disagree.
Thank you for the time you've taken to consider my comments nonetheless.
Maciej
^ permalink raw reply
* Re: [PATCH] net: Limit socket I/O iovec total length to INT_MAX.
From: Linus Torvalds @ 2010-10-29 6:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev, drosenberg, jon.maloy, allan.stephens
In-Reply-To: <20101028.112231.232747062.davem@davemloft.net>
Oh, btw, noticed another small detail..
I don't know if this matters, but the regular read/write routines
don't actually use INT_MAX as the limit, but instead a "maximally
page-aligned value that fits in an int":
#define MAX_RW_COUNT (INT_MAX & PAGE_CACHE_MASK)
because the code does _not_ want to turn a nice set of huge
page-aligned big writes into a write of an odd number (2GB-1).
This may not make much of a difference to networking - you guys are
already used to working with odd sizes like 1500 bytes of data payload
per packet etc. Most regular filesystems are much more sensitive to
things like block (and particularly page-cache sized) boundaries
because of the vagaries of disk and cache granularities. But MAX_INT
is a _really_ odd size, and things like csum_and_copy still tends to
want to get things at least word-aligned, no? And if nothing else, the
memory copies tend to be better with cacheline boundaries.
It would be sad if a 4GB aligned write turns into
- one 2GB-1 aligned write
- one pessimally unaligned 2G-1 write where every read from user
space is unaligned
- finally a single 2-byte write.
I suspect it would be better off using the same kind of (MAX_INT &
PAGE_CACHE_MASK) logic - that 4GB write would still get split into
three partial writes (and _lots_ of packets ;), but at least they'd
all be word-aligned.
Does it matter? I dunno. Once you do 2GB+ writes, these kinds of small
details may be totally hidden in all the noise.
Linus
On Thu, Oct 28, 2010 at 11:22 AM, David Miller <davem@davemloft.net> wrote:
>
> This helps protect us from overflow issues down in the
> individual protocol sendmsg/recvmsg handlers. Once
> we hit INT_MAX we truncate out the rest of the iovec
> by setting the iov_len members to zero.
>
> This works because:
>
> 1) For SOCK_STREAM and SOCK_SEQPACKET sockets, partial
> writes are allowed and the application will just continue
> with another write to send the rest of the data.
>
> 2) For datagram oriented sockets, where there must be a
> one-to-one correspondance between write() calls and
> packets on the wire, INT_MAX is going to be far larger
> than the packet size limit the protocol is going to
> check for and signal with -EMSGSIZE.
>
> Based upon a patch by Linus Torvalds.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
>
> Ok, this is the patch I am testing right now. It ought to
> plug the TIPC holes wrt. handling iovecs given by the
> user.
>
> I'll look at the recently discovered RDS crap next :-/
>
> include/linux/socket.h | 2 +-
> net/compat.c | 12 +++++++-----
> net/core/iovec.c | 19 +++++++++----------
> 3 files changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/include/linux/socket.h b/include/linux/socket.h
> index 5146b50..86b652f 100644
> --- a/include/linux/socket.h
> +++ b/include/linux/socket.h
> @@ -322,7 +322,7 @@ extern int csum_partial_copy_fromiovecend(unsigned char *kdata,
> int offset,
> unsigned int len, __wsum *csump);
>
> -extern long verify_iovec(struct msghdr *m, struct iovec *iov, struct sockaddr *address, int mode);
> +extern int verify_iovec(struct msghdr *m, struct iovec *iov, struct sockaddr *address, int mode);
> extern int memcpy_toiovec(struct iovec *v, unsigned char *kdata, int len);
> extern int memcpy_toiovecend(const struct iovec *v, unsigned char *kdata,
> int offset, int len);
> diff --git a/net/compat.c b/net/compat.c
> index 63d260e..71bfd8e 100644
> --- a/net/compat.c
> +++ b/net/compat.c
> @@ -34,17 +34,19 @@ static inline int iov_from_user_compat_to_kern(struct iovec *kiov,
> struct compat_iovec __user *uiov32,
> int niov)
> {
> - int tot_len = 0;
> + size_t tot_len = 0;
>
> while (niov > 0) {
> compat_uptr_t buf;
> compat_size_t len;
>
> if (get_user(len, &uiov32->iov_len) ||
> - get_user(buf, &uiov32->iov_base)) {
> - tot_len = -EFAULT;
> - break;
> - }
> + get_user(buf, &uiov32->iov_base))
> + return -EFAULT;
> +
> + if (len > INT_MAX - tot_len)
> + len = INT_MAX - tot_len;
> +
> tot_len += len;
> kiov->iov_base = compat_ptr(buf);
> kiov->iov_len = (__kernel_size_t) len;
> diff --git a/net/core/iovec.c b/net/core/iovec.c
> index 72aceb1..e7f5b29 100644
> --- a/net/core/iovec.c
> +++ b/net/core/iovec.c
> @@ -35,10 +35,10 @@
> * in any case.
> */
>
> -long verify_iovec(struct msghdr *m, struct iovec *iov, struct sockaddr *address, int mode)
> +int verify_iovec(struct msghdr *m, struct iovec *iov, struct sockaddr *address, int mode)
> {
> int size, ct;
> - long err;
> + size_t err;
>
> if (m->msg_namelen) {
> if (mode == VERIFY_READ) {
> @@ -62,14 +62,13 @@ long verify_iovec(struct msghdr *m, struct iovec *iov, struct sockaddr *address,
> err = 0;
>
> for (ct = 0; ct < m->msg_iovlen; ct++) {
> - err += iov[ct].iov_len;
> - /*
> - * Goal is not to verify user data, but to prevent returning
> - * negative value, which is interpreted as errno.
> - * Overflow is still possible, but it is harmless.
> - */
> - if (err < 0)
> - return -EMSGSIZE;
> + size_t len = iov[ct].iov_len;
> +
> + if (len > INT_MAX - err) {
> + len = INT_MAX - err;
> + iov[ct].iov_len = len;
> + }
> + err += len;
> }
>
> return err;
> --
> 1.7.3.2
>
>
^ permalink raw reply
* RE: [PATCH] cxgb4vf: fix crash due to manipulating queues before registration
From: Dimitrios Michailidis @ 2010-10-29 7:36 UTC (permalink / raw)
To: David Miller, Casey Leedom; +Cc: netdev
In-Reply-To: <20101028.132122.245402585.davem@davemloft.net>
> > Before commit "net: allocate tx queues in register_netdevice"
> > netif_tx_stop_all_queues and related functions could be used between
> > device allocation and registration but now only after registration.
> > cxgb4 has such a call before registration and crashes now. Move it
> > after register_netdev.
> >
> > Signed-off-by: Casey Leedom <leedom@chelsio.com>
>
> Why are you manipulating the queue at all here?
>
> The queue state is "don't care" at this point in time,
> and has no meaning until ->open() is invoked.
The reason for the call at its initial pre register_netdev location was
an attempt to make the queues have the same state at the time of each
open. Without it at the first open __QUEUE_STATE_XOFF is not set due to
0-initialization but at subsequent opens it is set because close stops
the queues. I agree however that this disparity is not functionally
significant. Further, I believe moving the call after register_netdev
is buggy as open can be called after registration and it can clash with
the queue stopping. It seems then that these netif_tx_stop_all_queues
calls have to go now.
^ permalink raw reply
* RE: About the Davicom PHY in drivers/net/phy in Linux kernel
From: macpaul @ 2010-10-29 7:46 UTC (permalink / raw)
To: joseph_chang, netdev; +Cc: afleming, jeff, f.rodo
Hi Joseph,
I just followed up your suggestion in previous mail, let me quote them here:
# quote
The recommend is changed to be as below:
err = phy_write(phydev, MII_BMCR, BMCR_RESET);
//err = phy_write(phydev, MII_BMCR, BMCR_ISOLATE);
err = phy_write(phydev, MII_DM9161_SCR, MII_DM9161_SCR_INIT);
err = phy_write(phydev, MII_DM9161_10BTCSR, MII_DM9161_10BTCSR_INIT);
// err = phy_write(phydev, MII_NWAYTEST, 0x10);
err = phy_write(phydev, MII_BMCR, BMCR_ANENABLE | BMCR_ANRESTART);
*Note: Added a PHY reset command.
# end quote
>
> * == > Would you tell us your:
> CPU = ?
SoC: Faraday A320 (arm920t) / Andes AG101 (NDS32)
> Linux Kernel version= ?
Linux: 2.6.32
> I will like to download the same source code from LXR.
> And can check more detail for you.
I've believed that you have download the source already. :-)
^ permalink raw reply
* Re: [PATCH] ixgbe: refactor ixgbe_alloc_queues()
From: Jeff Kirsher @ 2010-10-29 7:46 UTC (permalink / raw)
To: Eric Dumazet
Cc: Tantilov, Emil S, David Miller, Waskiewicz Jr, Peter P,
Brattain, Ross B, netdev
In-Reply-To: <1288323933.2711.43.camel@edumazet-laptop>
On Thu, Oct 28, 2010 at 20:45, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Note : compiled only patch, not tested.
>
> Thanks !
>
> [PATCH] ixgbe: refactor ixgbe_alloc_queues()
>
> I noticed ring variable was initialized before allocations, and that
> memory node management was a bit ugly. We also leak memory in case of
> ring allocations error.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> drivers/net/ixgbe/ixgbe_main.c | 69 ++++++++++++-------------------
> 1 file changed, 28 insertions(+), 41 deletions(-)
>
Thanks Eric. I will add this to my queue of patches.
--
Cheers,
Jeff
^ permalink raw reply
* Re: [RFC PATCH 1/1] vhost: TX used buffer guest signal accumulation
From: Michael S. Tsirkin @ 2010-10-29 8:03 UTC (permalink / raw)
To: Shirley Ma; +Cc: David Miller, netdev, kvm, linux-kernel
In-Reply-To: <1288294355.11251.20.camel@localhost.localdomain>
On Thu, Oct 28, 2010 at 12:32:35PM -0700, Shirley Ma wrote:
> On Thu, 2010-10-28 at 07:20 +0200, Michael S. Tsirkin wrote:
> > My concern is this can delay signalling for unlimited time.
> > Could you pls test this with guests that do not have
> > 2b5bbe3b8bee8b38bdc27dd9c0270829b6eb7eeb
> > b0c39dbdc204006ef3558a66716ff09797619778
> > that is 2.6.31 and older?
>
> The patch only induces delay signaling unlimited time when there is no
> TX packet to transmit. I thought TX signaling only noticing guest to
> release the used buffers, anything else beside this?
Right, that's it I think. For newer kernels we orphan the skb
on xmit so we don't care that much about completing them.
This does rely on an undocumented assumption about guest
behaviour though.
> I tested rhel5u5 guest (2.6.18 kernel), it works fine. I checked the two
> commits log, I don't think this patch could cause any issue w/o these
> two patches.
>
> Also I found a big TX regression for old guest and new guest. For old
> guest, I am able to get almost 11Gb/s for 2K message size, but for the
> new guest kernel, I can only get 3.5 Gb/s with the patch and same host.
> I will dig it why.
>
> thanks
> Shirley
^ permalink raw reply
* Re: [RFC PATCH 1/1] vhost: TX used buffer guest signal accumulation
From: Michael S. Tsirkin @ 2010-10-29 8:10 UTC (permalink / raw)
To: Shirley Ma; +Cc: David Miller, netdev, kvm, linux-kernel
In-Reply-To: <1288286062.11251.15.camel@localhost.localdomain>
On Thu, Oct 28, 2010 at 10:14:22AM -0700, Shirley Ma wrote:
>
> > Two ideas:
> > 1. How about writing out used, just delaying the signal?
> > This way we don't have to queue separately.
>
> This improves some performance, but not as good as delaying
> both used and signal. Since delaying used buffers combining
> multiple small copies to a large copy, which saves more CPU
> utilization and increased some BW.
Hmm. I don't yet understand. We are still doing copies into the per-vq
buffer, and the data copied is really small. Is it about cache line
bounces? Could you try figuring it out?
> > 2. How about flushing out queued stuff before we exit
> > the handle_tx loop? That would address most of
> > the spec issue.
>
> The performance is almost as same as the previous patch. I will resubmit
> the modified one, adding vhost_add_used_and_signal_n after handle_tx
> loop for processing pending queue.
>
> This patch was a part of modified macvtap zero copy which I haven't
> submitted yet. I found this helped vhost TX in general. This pending
> queue will be used by DMA done later, so I put it in vq instead of a
> local variable in handle_tx.
>
> Thanks
> Shirley
BTW why do we need another array? Isn't heads field exactly what we need
here?
^ permalink raw reply
* Re: [RFC PATCH 1/1] vhost: TX used buffer guest signal accumulation
From: Michael S. Tsirkin @ 2010-10-29 8:11 UTC (permalink / raw)
To: Shirley Ma; +Cc: Sridhar Samudrala, David Miller, netdev, kvm, linux-kernel
In-Reply-To: <1288302050.11251.26.camel@localhost.localdomain>
On Thu, Oct 28, 2010 at 02:40:50PM -0700, Shirley Ma wrote:
> On Thu, 2010-10-28 at 14:04 -0700, Sridhar Samudrala wrote:
> > It would be some change in virtio-net driver that may have improved
> > the
> > latency of small messages which in turn would have reduced the
> > bandwidth
> > as TCP could not accumulate and send large packets.
>
> I will check out any latency improvement patch in virtio_net. If that's
> the case, whether it is good to have some tunable parameter to benefit
> both BW and latency workload?
>
> Shirley
No, we need it to work well automatically somehow.
--
MST
^ permalink raw reply
* Re: [RFC PATCH 1/1] vhost: TX used buffer guest signal accumulation
From: Michael S. Tsirkin @ 2010-10-29 8:12 UTC (permalink / raw)
To: Shirley Ma; +Cc: David Miller, netdev, kvm, linux-kernel
In-Reply-To: <1288296835.11251.24.camel@localhost.localdomain>
On Thu, Oct 28, 2010 at 01:13:55PM -0700, Shirley Ma wrote:
> On Thu, 2010-10-28 at 12:32 -0700, Shirley Ma wrote:
> > Also I found a big TX regression for old guest and new guest. For old
> > guest, I am able to get almost 11Gb/s for 2K message size, but for the
> > new guest kernel, I can only get 3.5 Gb/s with the patch and same
> > host.
> > I will dig it why.
>
> The regression is from guest kernel, not from this patch. Tested 2.6.31
> kernel, it's performance is less than 2Gb/s for 2K message size already.
> I will resubmit the patch for review.
>
> I will start to test from 2.6.30 kernel to figure it when TX regression
> induced in virtio_net. Any suggestion which guest kernel I should test
> to figure out this regression?
>
> Thanks
> Shirley
git bisect 2.6.31 2.6.30
and go from here.
^ permalink raw reply
* Re: [PATCH] ixgbe: refactor ixgbe_alloc_queues()
From: Jeff Kirsher @ 2010-10-29 8:38 UTC (permalink / raw)
To: Eric Dumazet
Cc: Tantilov, Emil S, David Miller, Waskiewicz Jr, Peter P,
Brattain, Ross B, netdev
In-Reply-To: <1288323933.2711.43.camel@edumazet-laptop>
On Thu, Oct 28, 2010 at 20:45, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Note : compiled only patch, not tested.
>
> Thanks !
>
> [PATCH] ixgbe: refactor ixgbe_alloc_queues()
>
> I noticed ring variable was initialized before allocations, and that
> memory node management was a bit ugly. We also leak memory in case of
> ring allocations error.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> drivers/net/ixgbe/ixgbe_main.c | 69 ++++++++++++-------------------
> 1 file changed, 28 insertions(+), 41 deletions(-)
>
I noticed a typo when applying the patch and I fixed it in the patch
in my queue.
The following code:
> + while (rx)
> + kfree(adapter->tx_ring[--rx]);
> +
should be:
> + while (rx)
> + kfree(adapter->rx_ring[--rx]);
> +
--
Cheers,
Jeff
^ permalink raw reply
* Re: [PATCH] ixgbe: refactor ixgbe_alloc_queues()
From: Eric Dumazet @ 2010-10-29 8:48 UTC (permalink / raw)
To: Jeff Kirsher
Cc: Tantilov, Emil S, David Miller, Waskiewicz Jr, Peter P,
Brattain, Ross B, netdev
In-Reply-To: <AANLkTinKQccHsA++PG86h5x3smJx75EB05YnHq2tGM-R@mail.gmail.com>
Le vendredi 29 octobre 2010 à 01:38 -0700, Jeff Kirsher a écrit :
>
> I noticed a typo when applying the patch and I fixed it in the patch
> in my queue.
>
> The following code:
> > + while (rx)
> > + kfree(adapter->tx_ring[--rx]);
> > +
>
> should be:
> > + while (rx)
> > + kfree(adapter->rx_ring[--rx]);
> > +
>
Good catch, thanks !
^ permalink raw reply
* Re: business offer !
From: Matthew Clayton @ 2010-10-29 10:53 UTC (permalink / raw)
To: netdev
Dear Sir/ Madam,
I am a staff of Barclays Bank London. I am writing on behalf of my client
following an Opportunity in my office that will be of immense benefit to
my client and us.My client\'s bank account with us has been frozen due to
some diminutive investigation on my client. My client is a very rich man,
worth over $4 billion USD. We have agreed to give you a non-negotiable
10%, of the total money transferred. Now! all we need from you is to let us know if
you are interested before we give you more information.Please get in touch
with me urgently by E-mail: claytonmattew2@yahoo.com.hk
Best regards
Mr. Matthew.
^ permalink raw reply
* RE: [RFC net-next] caif: code cleanup
From: Sjur BRENDELAND @ 2010-10-29 9:36 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev@vger.kernel.org, Andre Carvalho DE MATOS
In-Reply-To: <20101019095553.0b413b80@nehalam>
Hi Stephen,
> Stephen Hemminger wrote:
> >
> > Cleanup of new CAIF code.
> > * make local functions static
> > * remove code that is never used
> > * expand get_caif_conf() since wrapper is no longer needed
> > * make args to comparison functions const
> > * rename connect_req_to_link_param to keep exported names
> > consistent
>
> Thank you for your patch.
> We'll try to test this sometime next week,
> and get back to you.
Sorry for taking so long to respond.
We have passed our tests on your RFC.
I'll ack this if you send a patch.
Regards,
Sjur
^ permalink raw reply
* Re: [PATCH 0/15] RFC: create drivers/net/legacy for ISA, EISA, MCA drivers
From: David Lamparter @ 2010-10-29 9:40 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev
In-Reply-To: <1288316896.1836.41.camel@Joe-Laptop>
On Thu, Oct 28, 2010 at 06:48:16PM -0700, Joe Perches wrote:
> On Thu, 2010-10-28 at 21:19 -0400, Paul Gortmaker wrote:
> > The initial target is things like ISA/EISA/MCA drivers, and with
> > that alone, we can get close to 90 files out of drivers/net.
> > Plus, by having a semi-defined description for legacy as being
> > "drivers more than 10 years old" we'll always have a destination
> > for drivers as they fall out of maintainership and use.
>
> I think legacy is "old and not sold or used much anymore".
>
> I believe you're not moving 3c59x as that's relatively
> still popular even though it's nearly 15 years old.
>
> Or maybe that was just an oversight...
The 3c59x driver also drives a few not-that-old 100MBit cards like
"3Com Corporation 3c905B 100BaseTX [Cyclone] [10b7:9055] (rev 64)"
and these are quite common still :)
-David
^ permalink raw reply
* Re: [PATCH] virtio_net: Fix queue full check
From: Rusty Russell @ 2010-10-29 9:47 UTC (permalink / raw)
To: Krishna Kumar; +Cc: davem, netdev
In-Reply-To: <20101028051036.25340.23442.sendpatchset@krkumar2.in.ibm.com>
On Thu, 28 Oct 2010 03:40:36 pm Krishna Kumar wrote:
> I get many queue full errors being wrongly reported when running
> parallel netperfs:
>
> Oct 17 10:22:40 localhost kernel: net eth0: Unexpected TX queue failure: -28
> Oct 17 10:28:22 localhost kernel: net eth0: Unexpected TX queue failure: -28
> Oct 17 10:35:58 localhost kernel: net eth0: Unexpected TX queue failure: -28
> Oct 17 10:41:06 localhost kernel: net eth0: Unexpected TX queue failure: -28
>
> I initially changed the check from -ENOMEM to -ENOSPC, but
> virtqueue_add_buf can return only -ENOSPC when it doesn't have
> space for new request. Patch removes redundant checks but
> displays the failure errno.
>
> Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
> ---
> drivers/net/virtio_net.c | 15 ++++-----------
> 1 file changed, 4 insertions(+), 11 deletions(-)
>
> diff -ruNp org/drivers/net/virtio_net.c new/drivers/net/virtio_net.c
> --- org/drivers/net/virtio_net.c 2010-10-11 10:20:02.000000000 +0530
> +++ new/drivers/net/virtio_net.c 2010-10-21 17:37:45.000000000 +0530
> @@ -570,17 +570,10 @@ static netdev_tx_t start_xmit(struct sk_
>
> /* This can happen with OOM and indirect buffers. */
> if (unlikely(capacity < 0)) {
> - if (net_ratelimit()) {
> - if (likely(capacity == -ENOMEM)) {
> - dev_warn(&dev->dev,
> - "TX queue failure: out of memory\n");
> - } else {
> - dev->stats.tx_fifo_errors++;
> - dev_warn(&dev->dev,
> - "Unexpected TX queue failure: %d\n",
> - capacity);
> - }
> - }
> + if (net_ratelimit())
> + dev_warn(&dev->dev,
> + "TX queue failure (%d): out of memory\n",
> + capacity);
Hold on... you were getting -ENOSPC, which shouldn't happen. What makes you
think it's out of memory?
Confused,
Rusty.
^ permalink raw reply
* Dear Recipient
From: druv_martindaleyahoolott2010 @ 2010-10-29 9:51 UTC (permalink / raw)
Dear Recipient
w e are pleased to inform you of the just concluded promotions
that was conducted on the 29th October in regards to the
UK award promo. in this view you are to collect the
sum of one million Dollars. grant number.
(CT-222-6747,FGN/P-900-56).
You are informed to send us this details
1) Full Names, 2) Full Addresss, 3) Sex, 4) Phone Number,
5) Occupation, 6) Nationality, 7) Age, 8) Country.
Announcer,
Sophia Buffor
------------------------------------------------------------
This email was sent from Netspace Webmail: http://www.netspace.net.au
^ permalink raw reply
* Re: [PATCH 0/15] RFC: create drivers/net/legacy for ISA, EISA, MCA drivers
From: Maciej W. Rozycki @ 2010-10-29 10:13 UTC (permalink / raw)
To: David Lamparter; +Cc: Joe Perches, netdev
In-Reply-To: <20101029094050.GA1835290@jupiter.n2.diac24.net>
On Fri, 29 Oct 2010, David Lamparter wrote:
> > > The initial target is things like ISA/EISA/MCA drivers, and with
> > > that alone, we can get close to 90 files out of drivers/net.
> > > Plus, by having a semi-defined description for legacy as being
> > > "drivers more than 10 years old" we'll always have a destination
> > > for drivers as they fall out of maintainership and use.
> >
> > I think legacy is "old and not sold or used much anymore".
> >
> > I believe you're not moving 3c59x as that's relatively
> > still popular even though it's nearly 15 years old.
> >
> > Or maybe that was just an oversight...
>
> The 3c59x driver also drives a few not-that-old 100MBit cards like
> "3Com Corporation 3c905B 100BaseTX [Cyclone] [10b7:9055] (rev 64)"
> and these are quite common still :)
What's the difference? -- that's a change of the name only you should be
proud of! ;)
I have seen plenty of these Vortex/Boomerang/Cyclone cards in various
configurations and still have a couple myself, but I fail to recall any
that would be less than 8 years old, which is about the age of my newest
FDDI stuff (updated by the manufacturer to universal PCI and HP-branded
because of the DEC/Compaq acquisition) which has been declared "obviously
obsolete", so why shouldn't this equipment be either? ;)
Maciej
^ permalink raw reply
* [RFC PATCH 1/2] Gemini: create platform device for ethernet in Raidsonic IB-4220B
From: Michał Mirosław @ 2010-10-29 10:23 UTC (permalink / raw)
To: Hans Ulli Kroll, Russell King, linux-arm-kernel, linux-kernel,
netdev
Cc: Paulius Zaleckas, Janos Laube
In-Reply-To: <cover.1288321597.git.mirq-linux@rere.qmqm.pl>
This is cherry-picked from:
git://git.berlios.de/gemini-board ib4220
Code by Paulius Zaleckas <paulius.zaleckas@gmail.com>
and Janos Laube <janos.dev@gmail.com>.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
arch/arm/mach-gemini/board-nas4220b.c | 53 ++++++++++++++++++++++++++++++
arch/arm/mach-gemini/common.h | 2 +
arch/arm/mach-gemini/devices.c | 52 +++++++++++++++++++++++++++++
arch/arm/mach-gemini/include/mach/gmac.h | 21 ++++++++++++
4 files changed, 128 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-gemini/include/mach/gmac.h
diff --git a/arch/arm/mach-gemini/board-nas4220b.c b/arch/arm/mach-gemini/board-nas4220b.c
index 2ba096d..ca6ec5a 100644
--- a/arch/arm/mach-gemini/board-nas4220b.c
+++ b/arch/arm/mach-gemini/board-nas4220b.c
@@ -26,6 +26,7 @@
#include <asm/mach/arch.h>
#include <asm/mach/time.h>
+#include <mach/gmac.h>
#include <mach/hardware.h>
#include <mach/global_reg.h>
@@ -91,13 +92,65 @@ static struct platform_device ib4220b_key_device = {
},
};
+static struct mdio_gpio_platform_data ib4220b_mdio = {
+ .mdc = 22,
+ .mdio = 21,
+ .phy_mask = ~(1 << 1),
+};
+
+static struct platform_device ib4220b_phy_device = {
+ .name = "mdio-gpio",
+ .id = 0,
+ .dev = {
+ .platform_data = &ib4220b_mdio,
+ },
+};
+
+static struct gemini_gmac_platform_data ib4220b_gmac_data = {
+ .bus_id[0] = "0:01",
+ .interface[0] = PHY_INTERFACE_MODE_RGMII,
+};
+
+static void __init gmac_ib4220b_init(void)
+{
+ unsigned int val;
+
+ val = __raw_readl(IO_ADDRESS(GEMINI_GLOBAL_BASE) +
+ GLOBAL_IO_DRIVING_CTRL);
+ val |= (0x3 << GMAC0_PADS_SHIFT) | (0x3 << GMAC1_PADS_SHIFT);
+ __raw_writel(val, IO_ADDRESS(GEMINI_GLOBAL_BASE) +
+ GLOBAL_IO_DRIVING_CTRL);
+
+ val = (0x0 << GMAC0_RXDV_SKEW_SHIFT) | (0xf << GMAC0_RXC_SKEW_SHIFT) |
+ (0x7 << GMAC0_TXEN_SKEW_SHIFT) | (0xa << GMAC0_TXC_SKEW_SHIFT) |
+ (0x0 << GMAC1_RXDV_SKEW_SHIFT) | (0xf << GMAC1_RXC_SKEW_SHIFT) |
+ (0x7 << GMAC1_TXEN_SKEW_SHIFT) | (0xa << GMAC1_TXC_SKEW_SHIFT);
+ __raw_writel(val, IO_ADDRESS(GEMINI_GLOBAL_BASE) +
+ GLOBAL_GMAC_CTRL_SKEW_CTRL);
+
+ __raw_writel(0x77777777, IO_ADDRESS(GEMINI_GLOBAL_BASE) +
+ GLOBAL_GMAC0_DATA_SKEW_CTRL);
+ __raw_writel(0x77777777, IO_ADDRESS(GEMINI_GLOBAL_BASE) +
+ GLOBAL_GMAC1_DATA_SKEW_CTRL);
+
+ val = __raw_readl(IO_ADDRESS(GEMINI_GLOBAL_BASE) +
+ GLOBAL_ARBITRATION1_CTRL) & ~BURST_LENGTH_MASK;
+ val |= (0x20 << BURST_LENGTH_SHIFT);
+ __raw_writel(val, IO_ADDRESS(GEMINI_GLOBAL_BASE) +
+ GLOBAL_ARBITRATION1_CTRL);
+}
+
static void __init ib4220b_init(void)
{
gemini_gpio_init();
+ gmac_ib4220b_init();
+
platform_register_uart();
platform_register_pflash(SZ_16M, NULL, 0);
platform_device_register(&ib4220b_led_device);
platform_device_register(&ib4220b_key_device);
+ platform_device_register(&ib4220b_phy_device);
+ platform_register_ethernet(&ib4220b_gmac_data);
}
MACHINE_START(NAS4220B, "Raidsonic NAS IB-4220-B")
diff --git a/arch/arm/mach-gemini/common.h b/arch/arm/mach-gemini/common.h
index 9392834..4eafed5 100644
--- a/arch/arm/mach-gemini/common.h
+++ b/arch/arm/mach-gemini/common.h
@@ -13,6 +13,7 @@
#define __GEMINI_COMMON_H__
struct mtd_partition;
+struct gemini_gmac_platform_data;
extern void gemini_map_io(void);
extern void gemini_init_irq(void);
@@ -21,6 +22,7 @@ extern void gemini_gpio_init(void);
/* Common platform devices registration functions */
extern int platform_register_uart(void);
+extern int platform_register_ethernet(struct gemini_gmac_platform_data *pdata);
extern int platform_register_pflash(unsigned int size,
struct mtd_partition *parts,
unsigned int nr_parts);
diff --git a/arch/arm/mach-gemini/devices.c b/arch/arm/mach-gemini/devices.c
index 6b52525..ead7ab1 100644
--- a/arch/arm/mach-gemini/devices.c
+++ b/arch/arm/mach-gemini/devices.c
@@ -17,6 +17,7 @@
#include <mach/irqs.h>
#include <mach/hardware.h>
#include <mach/global_reg.h>
+#include <mach/gmac.h>
static struct plat_serial8250_port serial_platform_data[] = {
{
@@ -45,6 +46,57 @@ int platform_register_uart(void)
return platform_device_register(&serial_device);
}
+
+static struct resource gmac_resources[] = {
+ {
+ .start = GEMINI_TOE_BASE,
+ .end = GEMINI_TOE_BASE + 0xffff,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = IRQ_GMAC0,
+ .end = IRQ_GMAC0,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = IRQ_GMAC1,
+ .end = IRQ_GMAC1,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 gmac_dmamask = 0xffffffffUL;
+
+static struct platform_device ethernet_device = {
+ .name = "gemini-gmac",
+ .id = 0,
+ .dev = {
+ .dma_mask = &gmac_dmamask,
+ .coherent_dma_mask = 0xffffffff,
+ },
+ .num_resources = ARRAY_SIZE(gmac_resources),
+ .resource = gmac_resources,
+};
+
+int __init platform_register_ethernet(struct gemini_gmac_platform_data *pdata)
+{
+ unsigned int reg = __raw_readl(IO_ADDRESS(GEMINI_GLOBAL_BASE) + GLOBAL_MISC_CTRL);
+
+ reg &= ~(GMAC_GMII | GMAC_1_ENABLE);
+
+ if (pdata->bus_id[1])
+ reg |= GMAC_1_ENABLE;
+ else if (pdata->interface[0] == PHY_INTERFACE_MODE_GMII)
+ reg |= GMAC_GMII;
+
+ __raw_writel(reg, IO_ADDRESS(GEMINI_GLOBAL_BASE) + GLOBAL_MISC_CTRL);
+
+ ethernet_device.dev.platform_data = pdata;
+
+ return platform_device_register(ðernet_device);
+}
+
+
static struct resource flash_resource = {
.start = GEMINI_FLASH_BASE,
.flags = IORESOURCE_MEM,
diff --git a/arch/arm/mach-gemini/include/mach/gmac.h b/arch/arm/mach-gemini/include/mach/gmac.h
new file mode 100644
index 0000000..c6eeacc
--- /dev/null
+++ b/arch/arm/mach-gemini/include/mach/gmac.h
@@ -0,0 +1,21 @@
+/*
+ * Gemini GMAC specific defines
+ *
+ * Copyright (C) 2008, Paulius Zaleckas <paulius.zaleckas@teltonika.lt>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#ifndef __MACH_GMAC_H__
+#define __MACH_GMAC_H__
+
+#include <linux/phy.h>
+
+struct gemini_gmac_platform_data {
+ char *bus_id[2]; /* NULL means that this port is not used */
+ phy_interface_t interface[2];
+};
+
+#endif /* __MACH_GMAC_H__ */
--
1.7.1
^ 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