* Re: [PATCH 02/11] Removing dead {AR,WAVE}LAN
From: David Miller @ 2010-07-14 19:17 UTC (permalink / raw)
To: siccegge; +Cc: netdev, linux-kernel, vamos-dev
In-Reply-To: <3da4fcf94d2364af32c44a8442b756c8b525f6fc.1279110894.git.siccegge@cs.fau.de>
From: Christoph Egger <siccegge@cs.fau.de>
Date: Wed, 14 Jul 2010 14:39:52 +0200
> {AR,WAVE}LAN doesn't exist in Kconfig, therefore removing all
> references for it from the source code.
>
> Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
Applied to net-next-2.6
^ permalink raw reply
* Re: Raise initial congestion window size / speedup slow start?
From: Stephen Hemminger @ 2010-07-14 19:10 UTC (permalink / raw)
To: Ed W; +Cc: David Miller, davidsen, linux-kernel, netdev
In-Reply-To: <4C3E0684.5060409@wildgooses.com>
On Wed, 14 Jul 2010 19:48:36 +0100
Ed W <lists@wildgooses.com> wrote:
> On 14/07/2010 19:15, David Miller wrote:
> > From: Bill Davidsen<davidsen@tmr.com>
> > Date: Wed, 14 Jul 2010 11:21:15 -0400
> >
> >
> >> You may have to go into /proc/sys/net/core and crank up the
> >> rmem_* settings, depending on your distribution.
> >>
> > You should never, ever, have to touch the various networking sysctl
> > values to get good performance in any normal setup. If you do, it's a
> > bug, report it so we can fix it.
> >
>
> Just checking the basics here because I don't think this is a bug so
> much as a, less common installation that differs from the "normal" case.
>
> - When we create a tcp connection we always start with tcp slow start
> - This sets the congestion window to effectively 4 packets?
> - This applies in both directions?
> - Remote sender responds to my hypothetical http request with the first
> 4 packets of data
> - We need to wait one RTT for the ack to come back and now we can send
> the next 8 packets,
> - Wait for the next ack and at 16 packets we are now moving at a
> sensible fraction of the bandwidth delay product?
>
> So just to be clear:
> - We don't seem to have any user-space tuning knobs to influence this
> right now?
> - In this age of short attention spans, a couple of extra seconds
> between clicking something and it responding is worth optimising (IMHO)
> - I think I need to take this to netdev, but anyone else with any ideas
> happy to hear them?
>
> Thanks
>
> Ed W
TCP slow start is required by the RFC. It is there to prevent a TCP congestion
collapse. The HTTP problem is exacerbated by things beyond the user's control:
1. stupid server software that dribbles out data and doesn't used the full
payload of the packets
2. web pages with data from multiple sources (ads especially), each of which
requires a new connection
3. pages with huge graphics.
Most of this is because of sites that haven't figured out that somebody on a phone
across the globl might not have the same RTT and bandwidth that the developer on a
local network that created them. Changing the initial cwnd isn't going to fix it.
^ permalink raw reply
* Re: Raise initial congestion window size / speedup slow start?
From: Ed W @ 2010-07-14 18:48 UTC (permalink / raw)
To: David Miller; +Cc: davidsen, linux-kernel, netdev
In-Reply-To: <20100714.111553.104052157.davem@davemloft.net>
On 14/07/2010 19:15, David Miller wrote:
> From: Bill Davidsen<davidsen@tmr.com>
> Date: Wed, 14 Jul 2010 11:21:15 -0400
>
>
>> You may have to go into /proc/sys/net/core and crank up the
>> rmem_* settings, depending on your distribution.
>>
> You should never, ever, have to touch the various networking sysctl
> values to get good performance in any normal setup. If you do, it's a
> bug, report it so we can fix it.
>
Just checking the basics here because I don't think this is a bug so
much as a, less common installation that differs from the "normal" case.
- When we create a tcp connection we always start with tcp slow start
- This sets the congestion window to effectively 4 packets?
- This applies in both directions?
- Remote sender responds to my hypothetical http request with the first
4 packets of data
- We need to wait one RTT for the ack to come back and now we can send
the next 8 packets,
- Wait for the next ack and at 16 packets we are now moving at a
sensible fraction of the bandwidth delay product?
So just to be clear:
- We don't seem to have any user-space tuning knobs to influence this
right now?
- In this age of short attention spans, a couple of extra seconds
between clicking something and it responding is worth optimising (IMHO)
- I think I need to take this to netdev, but anyone else with any ideas
happy to hear them?
Thanks
Ed W
^ permalink raw reply
* Re: [RFC PATCH]: Fix a warning in the niu driver
From: Prarit Bhargava @ 2010-07-14 18:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100714.112800.189702548.davem@davemloft.net>
On 07/14/2010 02:28 PM, David Miller wrote:
> From: Prarit Bhargava <prarit@redhat.com>
> Date: Wed, 14 Jul 2010 09:18:31 -0400
>
>
>> Dave, would it be acceptable if I then wrapped link in
>> uninitialized_var() to get rid of the warning I'm trying to resolve? It
>> seems that your patch then checks for a valid page value so it should be
>> okay.
>>
> If the patch I posted doesn't fix your warning, the compiler is broken.
>
>
Oops -- my bad. I think I fat fingered something. Your patch
absolutely fixes the warning. Thanks Dave.
P.
^ permalink raw reply
* Re: [RFC PATCH]: Fix a warning in the niu driver
From: David Miller @ 2010-07-14 18:28 UTC (permalink / raw)
To: prarit; +Cc: netdev
In-Reply-To: <4C3DB927.2060106@redhat.com>
From: Prarit Bhargava <prarit@redhat.com>
Date: Wed, 14 Jul 2010 09:18:31 -0400
> Dave, would it be acceptable if I then wrapped link in
> uninitialized_var() to get rid of the warning I'm trying to resolve? It
> seems that your patch then checks for a valid page value so it should be
> okay.
If the patch I posted doesn't fix your warning, the compiler is broken.
Any code path that would not initialize the variable, hits the BUG()
therefore making return from the function completely unreachable,
therefore the uses of the initialized variable are completely unreachable.
I'm not adding workarounds for compiler warning bugs. They aren't real
bugs, and such efforts tend to _add_ bugs to the tree rather than fix
real problems.
^ permalink raw reply
* Re: Raise initial congestion window size / speedup slow start?
From: David Miller @ 2010-07-14 18:15 UTC (permalink / raw)
To: davidsen; +Cc: lists, linux-kernel, netdev
In-Reply-To: <4C3DD5EB.9070908@tmr.com>
From: Bill Davidsen <davidsen@tmr.com>
Date: Wed, 14 Jul 2010 11:21:15 -0400
> You may have to go into /proc/sys/net/core and crank up the
> rmem_* settings, depending on your distribution.
You should never, ever, have to touch the various networking sysctl
values to get good performance in any normal setup. If you do, it's a
bug, report it so we can fix it.
I cringe every time someone says to do this, so please do me a favor
and don't spread this further. :-)
For one thing, TCP dynamically adjusts the socket buffer sizes based
upon the behavior of traffic on the connection.
And the TCP memory limit sysctls (not the core socket ones) are sized
based upon available memory. They are there to protect you from
situations such as having so much memory dedicated to socket buffers
that there is none left to do other things effectively. It's a
protective limit, rather than a setting meant to increase or improve
performance. So like the others, leave these alone too.
^ permalink raw reply
* [PATCH 06/11] tulip: formatting of pointers in printk()
From: Kulikov Vasiliy @ 2010-07-14 18:03 UTC (permalink / raw)
To: kernel-janitors
Cc: Grant Grundler, Kyle McMartin, David S. Miller, Joe Perches,
Jiri Pirko, Stephen Hemminger, Eric Dumazet, netdev, linux-kernel
Use %p instead of %08x in printk().
Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
---
drivers/net/tulip/winbond-840.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tulip/winbond-840.c b/drivers/net/tulip/winbond-840.c
index 608b279..66d41cf 100644
--- a/drivers/net/tulip/winbond-840.c
+++ b/drivers/net/tulip/winbond-840.c
@@ -1514,12 +1514,12 @@ static int netdev_close(struct net_device *dev)
if (debug > 2) {
int i;
- printk(KERN_DEBUG" Tx ring at %08x:\n", (int)np->tx_ring);
+ printk(KERN_DEBUG" Tx ring at %p:\n", np->tx_ring);
for (i = 0; i < TX_RING_SIZE; i++)
printk(KERN_DEBUG " #%d desc. %04x %04x %08x\n",
i, np->tx_ring[i].length,
np->tx_ring[i].status, np->tx_ring[i].buffer1);
- printk(KERN_DEBUG " Rx ring %08x:\n", (int)np->rx_ring);
+ printk(KERN_DEBUG " Rx ring %p:\n", np->rx_ring);
for (i = 0; i < RX_RING_SIZE; i++) {
printk(KERN_DEBUG " #%d desc. %04x %04x %08x\n",
i, np->rx_ring[i].length,
--
1.7.0.4
^ permalink raw reply related
* Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3
From: Jeremy Fitzhardinge @ 2010-07-14 18:03 UTC (permalink / raw)
To: David Miller
Cc: pthakkar, pv-drivers, greg, linux-kernel, virtualization, hch,
netdev, shemminger
In-Reply-To: <20100714.105423.226778756.davem@davemloft.net>
On 07/14/2010 10:54 AM, David Miller wrote:
> And doing what you're doing is foolish on so many levels. One more
> duplication of code, one more place for unnecessary bugs to live, one
> more place that might need optimizations and thus require duplication
> of even more work people have done over the years.
>
Not to mention calling a function "MoveMemory" when it doesn't do a
memmove is just cruel.
J
^ permalink raw reply
* [PATCH 05/11] tulip: formatting of pointers in printk()
From: Kulikov Vasiliy @ 2010-07-14 18:02 UTC (permalink / raw)
To: kernel-janitors
Cc: Grant Grundler, Kyle McMartin, David S. Miller, Joe Perches,
Jiri Pirko, Ben Hutchings, Grant Likely, netdev, linux-kernel,
devicetree-discuss
Use %p instead of %08x in printk().
Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
---
drivers/net/tulip/tulip_core.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c
index 03e96b9..14e5312 100644
--- a/drivers/net/tulip/tulip_core.c
+++ b/drivers/net/tulip/tulip_core.c
@@ -596,10 +596,10 @@ static void tulip_tx_timeout(struct net_device *dev)
pr_cont(" %02x", buf[j]);
pr_cont(" j=%d\n", j);
}
- printk(KERN_DEBUG " Rx ring %08x: ", (int)tp->rx_ring);
+ printk(KERN_DEBUG " Rx ring %p: ", tp->rx_ring);
for (i = 0; i < RX_RING_SIZE; i++)
pr_cont(" %08x", (unsigned int)tp->rx_ring[i].status);
- printk(KERN_DEBUG " Tx ring %08x: ", (int)tp->tx_ring);
+ printk(KERN_DEBUG " Tx ring %p: ", tp->tx_ring);
for (i = 0; i < TX_RING_SIZE; i++)
pr_cont(" %08x", (unsigned int)tp->tx_ring[i].status);
pr_cont("\n");
--
1.7.0.4
^ permalink raw reply related
* Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3
From: David Miller @ 2010-07-14 17:54 UTC (permalink / raw)
To: pthakkar
Cc: greg, sbhatewara, hch, shemminger, pv-drivers, netdev,
linux-kernel, virtualization
In-Reply-To: <F1354E79A137A24CBA60059AA65CB1B802A34EEB67@EXCH-MBX-2.vmware.com>
From: Pankaj Thakkar <pthakkar@vmware.com>
Date: Wed, 14 Jul 2010 10:18:22 -0700
> The plugin is guest agnostic and hence we did not want to rely on
> any kernel provided functions.
While I disagree entirely with this kind of approach, even that
doesn't justify what you're doing here.
memcpy() and memset() are on a much more fundamental ground than
"kernel provided functions". They had better be available no matter
where you build this thing.
And doing what you're doing is foolish on so many levels. One more
duplication of code, one more place for unnecessary bugs to live, one
more place that might need optimizations and thus require duplication
of even more work people have done over the years.
^ permalink raw reply
* Re: [PATCHv3 NEXT 0/5]qlcnic: aer state
From: David Miller @ 2010-07-14 17:31 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman
In-Reply-To: <1279089215-23231-1-git-send-email-amit.salecha@qlogic.com>
From: amit.salecha@qlogic.com
Date: Tue, 13 Jul 2010 23:33:30 -0700
> I was in under impression that using space after tab is illegal.
What's undesirable is using spaces instead of tabs for fresh
code-block lines like:
foo();
Also, it is undesirable to have spaces mixed into the middle of a
sequence of tab characters. The spaces, when used to align expression
continuation lines or lists of function arguments, should be at the
end.
So in cases like:
if (foo &&
bar)
The second line should be a tab character, then the spaces to make
the alignment happen.
^ permalink raw reply
* Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3
From: Shreyas Bhatewara @ 2010-07-14 17:19 UTC (permalink / raw)
To: Greg KH
Cc: Christoph Hellwig, Stephen Hemminger, Pankaj Thakkar,
pv-drivers@vmware.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org
In-Reply-To: <20100714094952.GA16209@kroah.com>
On Wed, 14 Jul 2010, Greg KH wrote:
> On Mon, Jul 12, 2010 at 08:06:28PM -0700, Shreyas Bhatewara wrote:
> > drivers/net/vmxnet3/vmxnet3_drv.c | 1845
> > +++++++++++++++++++--------------
>
> Your patch is line-wrapped and can not be applied :(
>
> Care to fix your email client?
>
> One thing just jumped out at me when glancing at this:
>
> > +static INLINE void
> > +MoveMemory(void *dst,
> > + void *src,
> > + size_t length)
> > +{
> > + size_t i;
> > + for (i = 0; i < length; ++i)
> > + ((u8 *)dst)[i] = ((u8 *)src)[i];
> > +}
> > +
> > +static INLINE void
> > +ZeroMemory(void *memory,
> > + size_t length)
> > +{
> > + size_t i;
> > + for (i = 0; i < length; ++i)
> > + ((u8 *)memory)[i] = 0;
> > +}
>
> Is there some reason that our in-kernel functions that do this type of
> logic are not working for you to require you to reimplement this?
>
> thanks,
>
> greg k-h
>
Greg,
Thanks for pointing out. I will fix both these issues and repost the patch.
->Shreyas
^ permalink raw reply
* RE: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3
From: Pankaj Thakkar @ 2010-07-14 17:18 UTC (permalink / raw)
To: Greg KH, Shreyas Bhatewara
Cc: pv-drivers@vmware.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, Christoph Hellwig,
Stephen Hemminger
In-Reply-To: <20100714094952.GA16209@kroah.com>
The plugin is guest agnostic and hence we did not want to rely on any kernel provided functions. The plugin uses only the interface provided by the shell. The assumption is that since the plugin is really simple and straight forward (all the control/init complexity lies in the PF driver in the hypervisor) we should be able to get by for most of the things and for things like memcpy/memset the plugin can write simple functions like this.
-p
________________________________________
From: Greg KH [greg@kroah.com]
Sent: Wednesday, July 14, 2010 2:49 AM
To: Shreyas Bhatewara
Cc: Christoph Hellwig; Stephen Hemminger; Pankaj Thakkar; pv-drivers@vmware.com; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; virtualization@lists.linux-foundation.org
Subject: Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3
Is there some reason that our in-kernel functions that do this type of
logic are not working for you to require you to reimplement this?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] netfilter: xtables: userspace notification target
From: Pablo Neira Ayuso @ 2010-07-14 16:34 UTC (permalink / raw)
To: Luciano Coelho
Cc: ext Patrick McHardy, Changli Gao, Samuel Ortiz, David S. Miller,
netdev@vger.kernel.org, netfilter-devel@vger.kernel.org
In-Reply-To: <1279110169.20985.41.camel@chilepepper>
Hi Luciano,
On 14/07/10 14:22, Luciano Coelho wrote:
> On Wed, 2010-07-14 at 13:48 +0200, ext Patrick McHardy wrote:
>> If you're using connection tracking, you can use conntrack marks
>> to avoid sending more than a single message:
>>
>> iptables ... -m connmark --mark 0x1/0x1 -j RETURN
>> iptables ... -j NFLOG ...
>> iptables ... -j CONNMARK --set-mark 0x1/0x1
>
> Cool, thanks.
>
> It seems that there are lots of possibilities to get this to work, but
> this is starting to get quite complex. I would still prefer having the
> NFNOTIF module included, since we would be able to do what we want in a
> very simple way. It's also probably much more efficient that using
> several rules, which would increase the CPU usage considerably (in our
> device we are already reaching the limit of a reasonable CPU resource
> usage with high throughput WLAN connections).
>
> While I agree that it is possible to achieve the NFNOTIF functionality
> with existing modules, I still think there is a "niche" for such module,
> because it is very simple, has a very clear purpose and would make the
> ruleset simpler and more efficient.
>
> Does this make any sense?
I don't think that the NFNOTIF infrastructure fulfill the policy for
inclusion. It seems to me like something quite specific for your needs.
It is simple, yes, but we already have this feature into the kernel. I
don't think that this will reduce CPU usage considerably with regards to
the NFLOG way.
I would still prefer adding the once-per-matching notification feature
to NFLOG than these extra lines in the kernel, Patrick?
^ permalink raw reply
* RE: Splice status
From: Ofer Heifetz @ 2010-07-14 15:08 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Changli Gao, Jens Axboe, netdev@vger.kernel.org
In-Reply-To: <1279030308.2634.349.camel@edumazet-laptop>
Hi,
The strange thing happens when I configure it to use 256K using fcntl, I see that it uses splice with 1460 bytes, I tried making it smaller but no change.
Any clue why I get smaller pipe though trying to resize it to 256K?
BTW I changed the kernel to 2.6.35_rc5.
-Ofer
-----Original Message-----
From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
Sent: Tuesday, July 13, 2010 5:12 PM
To: Ofer Heifetz
Cc: Changli Gao; Jens Axboe; netdev@vger.kernel.org
Subject: RE: Splice status
Le mardi 13 juillet 2010 à 14:41 +0300, Ofer Heifetz a écrit :
> Hi,
>
> I wanted to let you know that I have been testing Samba splice on Marvell 6282 SoC on 2.6.35_rc3 and noticed that it gave worst performance than not using it and also noticed that on re-writing file the iowait is high.
>
> iometer using 2G file (file is created before test)
>
> Splice write cpu% iow%
> -----------------------
> No 58 98 0
> Yes 14 100 48
>
> iozone using 2G file (file created during test)
>
> Splice write cpu% iow% re-write cpu% iow%
> -------------------------------------------
> No 35 85 4 58.2 70 0
> Yes 33 85 4 15.7 100 58
>
> Any clue why splice introduces a high iowait?
> I noticed samba uses up to 16K per splice syscall, changing the samba to try more did not help, so I guess it is a kernel limitation.
>
splice(socket -> pipe) provides partial buffers (depending on the MTU)
With typical MTU=1500 and tcp timestamps, each network frame contains
1448 bytes of payload, partially filling one page (of 4096 bytes)
When doing the splice(pipe -> file), kernel has to coalesce partial
data, but amount of written data per syscall() is small (about 20
Kbytes)
Without splice(), the write() syscall provides more data, and vfs
overhead is smaller as buffer size is a power of two.
Samba uses a 128 KBytes TRANSFER_BUF_SIZE in its default_sys_recvfile()
implementation, it easily outperforms splice() implementation.
You could try extending pipe size (fcntl(fd, F_SETPIPE_SZ, 256)), maybe
it will be a bit better. (and ask 256*4096 bytes to splice())
I tried this and got about 256Kbytes per splice() call...
# perf report
# Events: 13K
#
# Overhead Command Shared Object Symbol
# ........ .............. ................. ......
#
8.69% splice-fromnet [kernel.kallsyms] [k] memcpy
3.82% splice-fromnet [kernel.kallsyms] [k] kunmap_atomic
3.51% splice-fromnet [kernel.kallsyms] [k] __block_prepare_write
2.79% splice-fromnet [kernel.kallsyms] [k] __skb_splice_bits
2.58% splice-fromnet [kernel.kallsyms] [k] ext3_mark_iloc_dirty
2.45% splice-fromnet [kernel.kallsyms] [k] do_get_write_access
2.04% splice-fromnet [kernel.kallsyms] [k] __find_get_block
1.89% splice-fromnet [kernel.kallsyms] [k] _raw_spin_lock
1.83% splice-fromnet [kernel.kallsyms] [k] journal_add_journal_head
1.46% splice-fromnet [bnx2x] [k] bnx2x_rx_int
1.46% splice-fromnet [kernel.kallsyms] [k] kfree
1.42% splice-fromnet [kernel.kallsyms] [k] journal_put_journal_head
1.29% splice-fromnet [kernel.kallsyms] [k] __ext3_get_inode_loc
1.26% splice-fromnet [kernel.kallsyms] [k] journal_dirty_metadata
1.25% splice-fromnet [kernel.kallsyms] [k] page_address
1.20% splice-fromnet [kernel.kallsyms] [k] journal_cancel_revoke
1.15% splice-fromnet [kernel.kallsyms] [k] tcp_read_sock
1.09% splice-fromnet [kernel.kallsyms] [k] unlock_buffer
1.09% splice-fromnet [kernel.kallsyms] [k] pipe_to_file
1.05% splice-fromnet [kernel.kallsyms] [k] radix_tree_lookup_element
1.04% splice-fromnet [kernel.kallsyms] [k] kmap_atomic_prot
1.04% splice-fromnet [kernel.kallsyms] [k] kmem_cache_free
1.03% splice-fromnet [kernel.kallsyms] [k] kmem_cache_alloc
1.01% splice-fromnet [bnx2x] [k] bnx2x_poll
^ permalink raw reply
* Re: [PATCH 01/11] Removing dead RT2800PCI_SOC
From: Felix Fietkau @ 2010-07-14 14:44 UTC (permalink / raw)
To: John W. Linville
Cc: Ivo Van Doorn, Christoph Egger, Gertjan van Wingerde,
Bartlomiej Zolnierkiewicz, Helmut Schaa,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
users-poMEt7QlJxcwIE2E9O76wjtx2kNaKg5H,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
vamos-dev-DSeRVwK2yFR7NQr57o4jwX20dTPRyWU8FLXUG6abMr4,
Luis Correia
In-Reply-To: <20100714131527.GB2352-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
On 2010-07-14 3:15 PM, John W. Linville wrote:
> On Wed, Jul 14, 2010 at 02:52:14PM +0200, Ivo Van Doorn wrote:
>> On Wed, Jul 14, 2010 at 2:46 PM, Luis Correia <luis.f.correia-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > On Wed, Jul 14, 2010 at 13:39, Christoph Egger <siccegge-n+aIp8eCc/CzQB+pC5nmwQ@public.gmane.org> wrote:
>> >> While RT2800PCI_SOC exists in Kconfig, it depends on either
>> >> RALINK_RT288X or RALINK_RT305X which are both not available in Kconfig
>> >> so all Code depending on that can't ever be selected and, if there's
>> >> no plan to add these options, should be cleaned up
>> >>
>> >> Signed-off-by: Christoph Egger <siccegge-n+aIp8eCc/CzQB+pC5nmwQ@public.gmane.org>
>> >
>> > NAK,
>> >
>> > this is not dead code, it is needed for the Ralink System-on-Chip
>> > Platform devices.
>> >
>> > While I can't fix Kconfig errors and the current KConfig file may be
>> > wrong, this code cannot and will not be deleted.
>>
>> When the config option was introduced, the config options RALINK_RT288X and
>> RALINK_RT305X were supposed to be merged as well soon after by somebody (Felix?)
>>
>> But since testing is done on SoC boards by Helmut and Felix, I assume the code
>> isn't dead but actually in use.
>
> Perhaps Helmut and Felix can send us the missing code?
The missing code is a MIPS platform port, which is currently being
maintained in OpenWrt, but is not ready for upstream submission yet.
I'm not working on this code at the moment, but I think it will be
submitted once it's ready.
- Felix
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 01/11] Removing dead RT2800PCI_SOC
From: Bartlomiej Zolnierkiewicz @ 2010-07-14 14:14 UTC (permalink / raw)
To: Ivo Van Doorn
Cc: Egger, Gertjan van Wingerde, John W. Linville, Felix Fietkau,
Helmut Schaa, linux-wireless, users, netdev, linux-kernel,
vamos-dev, Luis Correia
In-Reply-To: <AANLkTikCeDys9e1EnE9GdiJtDRcbqW3gzvsmjzvB_yDs@mail.gmail.com>
On Wednesday 14 July 2010 02:52:14 pm Ivo Van Doorn wrote:
> On Wed, Jul 14, 2010 at 2:46 PM, Luis Correia <luis.f.correia@gmail.com> wrote:
> > On Wed, Jul 14, 2010 at 13:39, Christoph Egger <siccegge@cs.fau.de> wrote:
> >> While RT2800PCI_SOC exists in Kconfig, it depends on either
> >> RALINK_RT288X or RALINK_RT305X which are both not available in Kconfig
> >> so all Code depending on that can't ever be selected and, if there's
> >> no plan to add these options, should be cleaned up
> >>
> >> Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
> >
> > NAK,
> >
> > this is not dead code, it is needed for the Ralink System-on-Chip
> > Platform devices.
> >
> > While I can't fix Kconfig errors and the current KConfig file may be
> > wrong, this code cannot and will not be deleted.
>
> When the config option was introduced, the config options RALINK_RT288X and
> RALINK_RT305X were supposed to be merged as well soon after by somebody (Felix?)
>
> But since testing is done on SoC boards by Helmut and Felix, I assume the code
> isn't dead but actually in use.
>
> Ivo
I fully agree with Luis and Ivo that the proposed patch is invalid and
shouldn't be applied (the "code cannot and will not be deleted" anyway)..
[ Under "The New Normal" rules the code doesn't even have to work to be
merged and/or stay in the kernel so 9 months of code not being used by
any real user doesn't matter a tiny bit.. ]
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* [PATCH 5/5] Remove REDWOOD_5 and REDWOOD_6 config options and conditional code
From: Christian Dietrich @ 2010-07-14 14:05 UTC (permalink / raw)
To: Josh Boyer, Matt Porter, Benjamin Herrenschmidt, Paul Mackerras,
Solomon
Cc: vamos-dev
In-Reply-To: <c3c850bed3f5714f1efcfad24ad4f8bfcb6b5b54.1279116162.git.qy03fugy@stud.informatik.uni-erlangen.de>
The config options for REDWOOD_[56] were commented out in the powerpc
Kconfig. The ifdefs referencing this options therefore are dead and all
references to this can be removed (Also dependencies in other KConfig
files).
Signed-off-by: Christian Dietrich <qy03fugy@stud.informatik.uni-erlangen.de>
---
arch/powerpc/platforms/40x/Kconfig | 16 -------------
drivers/mtd/maps/Kconfig | 2 +-
drivers/mtd/maps/redwood.c | 43 ------------------------------------
drivers/net/Kconfig | 2 +-
4 files changed, 2 insertions(+), 61 deletions(-)
diff --git a/arch/powerpc/platforms/40x/Kconfig b/arch/powerpc/platforms/40x/Kconfig
index ec64264..b721764 100644
--- a/arch/powerpc/platforms/40x/Kconfig
+++ b/arch/powerpc/platforms/40x/Kconfig
@@ -71,22 +71,6 @@ config MAKALU
help
This option enables support for the AMCC PPC405EX board.
-#config REDWOOD_5
-# bool "Redwood-5"
-# depends on 40x
-# default n
-# select STB03xxx
-# help
-# This option enables support for the IBM STB04 evaluation board.
-
-#config REDWOOD_6
-# bool "Redwood-6"
-# depends on 40x
-# default n
-# select STB03xxx
-# help
-# This option enables support for the IBM STBx25xx evaluation board.
-
#config SYCAMORE
# bool "Sycamore"
# depends on 40x
diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
index f22bc9f..b5ebb72 100644
--- a/drivers/mtd/maps/Kconfig
+++ b/drivers/mtd/maps/Kconfig
@@ -321,7 +321,7 @@ config MTD_CFI_FLAGADM
config MTD_REDWOOD
tristate "CFI Flash devices mapped on IBM Redwood"
- depends on MTD_CFI && ( REDWOOD_4 || REDWOOD_5 || REDWOOD_6 )
+ depends on MTD_CFI && REDWOOD_4
help
This enables access routines for the flash chips on the IBM
Redwood board. If you have one of these boards and would like to
diff --git a/drivers/mtd/maps/redwood.c b/drivers/mtd/maps/redwood.c
index 933c0b6..d2c9db0 100644
--- a/drivers/mtd/maps/redwood.c
+++ b/drivers/mtd/maps/redwood.c
@@ -22,8 +22,6 @@
#include <asm/io.h>
-#if !defined (CONFIG_REDWOOD_6)
-
#define WINDOW_ADDR 0xffc00000
#define WINDOW_SIZE 0x00400000
@@ -69,47 +67,6 @@ static struct mtd_partition redwood_flash_partitions[] = {
}
};
-#else /* CONFIG_REDWOOD_6 */
-/* FIXME: the window is bigger - armin */
-#define WINDOW_ADDR 0xff800000
-#define WINDOW_SIZE 0x00800000
-
-#define RW_PART0_OF 0
-#define RW_PART0_SZ 0x400000 /* 4 MiB data */
-#define RW_PART1_OF RW_PART0_OF + RW_PART0_SZ
-#define RW_PART1_SZ 0x10000 /* 64K VPD */
-#define RW_PART2_OF RW_PART1_OF + RW_PART1_SZ
-#define RW_PART2_SZ 0x400000 - (0x10000 + 0x20000)
-#define RW_PART3_OF RW_PART2_OF + RW_PART2_SZ
-#define RW_PART3_SZ 0x20000
-
-static struct mtd_partition redwood_flash_partitions[] = {
- {
- .name = "Redwood filesystem",
- .offset = RW_PART0_OF,
- .size = RW_PART0_SZ
- },
- {
- .name = "Redwood OpenBIOS Vital Product Data",
- .offset = RW_PART1_OF,
- .size = RW_PART1_SZ,
- .mask_flags = MTD_WRITEABLE /* force read-only */
- },
- {
- .name = "Redwood kernel",
- .offset = RW_PART2_OF,
- .size = RW_PART2_SZ
- },
- {
- .name = "Redwood OpenBIOS",
- .offset = RW_PART3_OF,
- .size = RW_PART3_SZ,
- .mask_flags = MTD_WRITEABLE /* force read-only */
- }
-};
-
-#endif /* CONFIG_REDWOOD_6 */
-
struct map_info redwood_flash_map = {
.name = "IBM Redwood",
.size = WINDOW_SIZE,
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index ce2fcdd..313d306 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -913,7 +913,7 @@ config SMC91X
tristate "SMC 91C9x/91C1xxx support"
select CRC32
select MII
- depends on ARM || REDWOOD_5 || REDWOOD_6 || M32R || SUPERH || \
+ depends on ARM || M32R || SUPERH || \
MIPS || BLACKFIN || MN10300 || COLDFIRE
help
This is a driver for SMC's 91x series of Ethernet chipsets,
--
1.7.0.4
^ permalink raw reply related
* Re: [RFC PATCH]: Fix a warning in the niu driver
From: Prarit Bhargava @ 2010-07-14 13:18 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100707.170820.146356362.davem@davemloft.net>
> Your patch would corrupt the list state, since we'd leave
> pages in the rx page hash which have only externally references
> and thus will be freed up.
>
>
Ah ... I totally missed that. Thanks for clarifying that Dave.
> Just BUG() if the loop terminates without finding a page.
>
> --------------------
> niu: BUG on inability to find page in rx page hashes.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> diff --git a/drivers/net/niu.c b/drivers/net/niu.c
> index 3d523cb..5d36531 100644
> --- a/drivers/net/niu.c
> +++ b/drivers/net/niu.c
> @@ -3330,10 +3330,12 @@ static struct page *niu_find_rxpage(struct rx_ring_info *rp, u64 addr,
> for (; (p = *pp) != NULL; pp = (struct page **) &p->mapping) {
> if (p->index == addr) {
> *link = pp;
> - break;
> + goto found;
> }
> }
> + BUG();
>
> +found:
> return p;
> }
>
Dave, would it be acceptable if I then wrapped link in
uninitialized_var() to get rid of the warning I'm trying to resolve? It
seems that your patch then checks for a valid page value so it should be
okay.
P.
^ permalink raw reply
* Re: [PATCH 01/11] Removing dead RT2800PCI_SOC
From: John W. Linville @ 2010-07-14 13:15 UTC (permalink / raw)
To: Ivo Van Doorn
Cc: Christoph Egger, Gertjan van Wingerde, Bartlomiej Zolnierkiewicz,
Felix Fietkau, Helmut Schaa,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
users-poMEt7QlJxcwIE2E9O76wjtx2kNaKg5H,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
vamos-dev-DSeRVwK2yFR7NQr57o4jwX20dTPRyWU8FLXUG6abMr4,
Luis Correia
In-Reply-To: <AANLkTikCeDys9e1EnE9GdiJtDRcbqW3gzvsmjzvB_yDs-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Jul 14, 2010 at 02:52:14PM +0200, Ivo Van Doorn wrote:
> On Wed, Jul 14, 2010 at 2:46 PM, Luis Correia <luis.f.correia-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Wed, Jul 14, 2010 at 13:39, Christoph Egger <siccegge-n+aIp8eCc/CzQB+pC5nmwQ@public.gmane.org> wrote:
> >> While RT2800PCI_SOC exists in Kconfig, it depends on either
> >> RALINK_RT288X or RALINK_RT305X which are both not available in Kconfig
> >> so all Code depending on that can't ever be selected and, if there's
> >> no plan to add these options, should be cleaned up
> >>
> >> Signed-off-by: Christoph Egger <siccegge-n+aIp8eCc/CzQB+pC5nmwQ@public.gmane.org>
> >
> > NAK,
> >
> > this is not dead code, it is needed for the Ralink System-on-Chip
> > Platform devices.
> >
> > While I can't fix Kconfig errors and the current KConfig file may be
> > wrong, this code cannot and will not be deleted.
>
> When the config option was introduced, the config options RALINK_RT288X and
> RALINK_RT305X were supposed to be merged as well soon after by somebody (Felix?)
>
> But since testing is done on SoC boards by Helmut and Felix, I assume the code
> isn't dead but actually in use.
Perhaps Helmut and Felix can send us the missing code?
John
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 01/11] Removing dead RT2800PCI_SOC
From: Ivo Van Doorn @ 2010-07-14 12:52 UTC (permalink / raw)
To: Christoph Egger
Cc: Gertjan van Wingerde, John W. Linville, Bartlomiej Zolnierkiewicz,
Felix Fietkau, Helmut Schaa, linux-wireless, users, netdev,
linux-kernel, vamos-dev, Luis Correia
In-Reply-To: <AANLkTinO32CIe0HBTXjP_bcAz0nMEw6wvcZwcob1fX3r@mail.gmail.com>
On Wed, Jul 14, 2010 at 2:46 PM, Luis Correia <luis.f.correia@gmail.com> wrote:
> On Wed, Jul 14, 2010 at 13:39, Christoph Egger <siccegge@cs.fau.de> wrote:
>> While RT2800PCI_SOC exists in Kconfig, it depends on either
>> RALINK_RT288X or RALINK_RT305X which are both not available in Kconfig
>> so all Code depending on that can't ever be selected and, if there's
>> no plan to add these options, should be cleaned up
>>
>> Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
>
> NAK,
>
> this is not dead code, it is needed for the Ralink System-on-Chip
> Platform devices.
>
> While I can't fix Kconfig errors and the current KConfig file may be
> wrong, this code cannot and will not be deleted.
When the config option was introduced, the config options RALINK_RT288X and
RALINK_RT305X were supposed to be merged as well soon after by somebody (Felix?)
But since testing is done on SoC boards by Helmut and Felix, I assume the code
isn't dead but actually in use.
Ivo
^ permalink raw reply
* Re: [PATCH 11/11] Removing dead REDWOOD_{5,6}
From: Nicolas Pitre @ 2010-07-14 12:48 UTC (permalink / raw)
To: Christoph Egger
Cc: David S. Miller, Tony Lindgren, Daniel Walker, Alessandro Rubini,
netdev, linux-kernel, vamos-dev
In-Reply-To: <adba61f63f4439ac17f2e428429f01ae5e65ab15.1279110895.git.siccegge@cs.fau.de>
On Wed, 14 Jul 2010, Christoph Egger wrote:
> REDWOOD_{5,6} doesn't exist in Kconfig, therefore removing all
> references for it from the source code.
>
> Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
> ---
> drivers/net/smc91x.h | 37 -------------------------------------
> 1 files changed, 0 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h
> index 8d2772c..ee74791 100644
> --- a/drivers/net/smc91x.h
> +++ b/drivers/net/smc91x.h
> @@ -83,43 +83,6 @@ static inline void SMC_outw(u16 val, void __iomem *ioaddr, int reg)
> }
> }
>
> -#elif defined(CONFIG_REDWOOD_5) || defined(CONFIG_REDWOOD_6)
> -
> -/* We can only do 16-bit reads and writes in the static memory space. */
> -#define SMC_CAN_USE_8BIT 0
> -#define SMC_CAN_USE_16BIT 1
> -#define SMC_CAN_USE_32BIT 0
> -#define SMC_NOWAIT 1
> -
> -#define SMC_IO_SHIFT 0
> -
> -#define SMC_inw(a, r) in_be16((volatile u16 *)((a) + (r)))
> -#define SMC_outw(v, a, r) out_be16((volatile u16 *)((a) + (r)), v)
> -#define SMC_insw(a, r, p, l) \
> - do { \
> - unsigned long __port = (a) + (r); \
> - u16 *__p = (u16 *)(p); \
> - int __l = (l); \
> - insw(__port, __p, __l); \
> - while (__l > 0) { \
> - *__p = swab16(*__p); \
> - __p++; \
> - __l--; \
> - } \
> - } while (0)
> -#define SMC_outsw(a, r, p, l) \
> - do { \
> - unsigned long __port = (a) + (r); \
> - u16 *__p = (u16 *)(p); \
> - int __l = (l); \
> - while (__l > 0) { \
> - /* Believe it or not, the swab isn't needed. */ \
> - outw( /* swab16 */ (*__p++), __port); \
> - __l--; \
> - } \
> - } while (0)
> -#define SMC_IRQ_FLAGS (0)
> -
> #elif defined(CONFIG_SA1100_PLEB)
> /* We can only do 16-bit reads and writes in the static memory space. */
> #define SMC_CAN_USE_8BIT 1
> --
> 1.7.0.4
>
> --
> 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
* Re: [PATCH 01/11] Removing dead RT2800PCI_SOC
From: Luis Correia @ 2010-07-14 12:46 UTC (permalink / raw)
To: Christoph Egger
Cc: Ivo van Doorn, Gertjan van Wingerde, John W. Linville,
Bartlomiej Zolnierkiewicz, Felix Fietkau, Helmut Schaa,
linux-wireless, users, netdev, linux-kernel, vamos-dev
In-Reply-To: <29013fb6eab9e95e95d61df894797d2455dfa10c.1279110894.git.siccegge@cs.fau.de>
On Wed, Jul 14, 2010 at 13:39, Christoph Egger <siccegge@cs.fau.de> wrote:
> While RT2800PCI_SOC exists in Kconfig, it depends on either
> RALINK_RT288X or RALINK_RT305X which are both not available in Kconfig
> so all Code depending on that can't ever be selected and, if there's
> no plan to add these options, should be cleaned up
>
> Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
NAK,
this is not dead code, it is needed for the Ralink System-on-Chip
Platform devices.
While I can't fix Kconfig errors and the current KConfig file may be
wrong, this code cannot and will not be deleted.
Luis Correia
rt2x00 project admin
> ---
> drivers/net/wireless/rt2x00/Kconfig | 5 ----
> drivers/net/wireless/rt2x00/rt2800pci.c | 39 -------------------------------
> 2 files changed, 0 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/Kconfig b/drivers/net/wireless/rt2x00/Kconfig
> index eea1ef2..d59195a 100644
> --- a/drivers/net/wireless/rt2x00/Kconfig
> +++ b/drivers/net/wireless/rt2x00/Kconfig
> @@ -58,11 +58,6 @@ config RT2800PCI_PCI
> depends on PCI
> default y
>
> -config RT2800PCI_SOC
> - boolean
> - depends on RALINK_RT288X || RALINK_RT305X
> - default y
> -
> config RT2800PCI
> tristate "Ralink rt28xx/rt30xx/rt35xx (PCI/PCIe/PCMCIA) support (EXPERIMENTAL)"
> depends on (RT2800PCI_PCI || RT2800PCI_SOC) && EXPERIMENTAL
> diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x00/rt2800pci.c
> index b2f2327..1445038 100644
> --- a/drivers/net/wireless/rt2x00/rt2800pci.c
> +++ b/drivers/net/wireless/rt2x00/rt2800pci.c
> @@ -85,18 +85,9 @@ static void rt2800pci_mcu_status(struct rt2x00_dev *rt2x00dev, const u8 token)
> rt2800_register_write(rt2x00dev, H2M_MAILBOX_CID, ~0);
> }
>
> -#ifdef CONFIG_RT2800PCI_SOC
> -static void rt2800pci_read_eeprom_soc(struct rt2x00_dev *rt2x00dev)
> -{
> - u32 *base_addr = (u32 *) KSEG1ADDR(0x1F040000); /* XXX for RT3052 */
> -
> - memcpy_fromio(rt2x00dev->eeprom, base_addr, EEPROM_SIZE);
> -}
> -#else
> static inline void rt2800pci_read_eeprom_soc(struct rt2x00_dev *rt2x00dev)
> {
> }
> -#endif /* CONFIG_RT2800PCI_SOC */
>
> #ifdef CONFIG_RT2800PCI_PCI
> static void rt2800pci_eepromregister_read(struct eeprom_93cx6 *eeprom)
> @@ -1160,25 +1151,6 @@ MODULE_DEVICE_TABLE(pci, rt2800pci_device_table);
> #endif /* CONFIG_RT2800PCI_PCI */
> MODULE_LICENSE("GPL");
>
> -#ifdef CONFIG_RT2800PCI_SOC
> -static int rt2800soc_probe(struct platform_device *pdev)
> -{
> - return rt2x00soc_probe(pdev, &rt2800pci_ops);
> -}
> -
> -static struct platform_driver rt2800soc_driver = {
> - .driver = {
> - .name = "rt2800_wmac",
> - .owner = THIS_MODULE,
> - .mod_name = KBUILD_MODNAME,
> - },
> - .probe = rt2800soc_probe,
> - .remove = __devexit_p(rt2x00soc_remove),
> - .suspend = rt2x00soc_suspend,
> - .resume = rt2x00soc_resume,
> -};
> -#endif /* CONFIG_RT2800PCI_SOC */
> -
> #ifdef CONFIG_RT2800PCI_PCI
> static struct pci_driver rt2800pci_driver = {
> .name = KBUILD_MODNAME,
> @@ -1194,17 +1166,9 @@ static int __init rt2800pci_init(void)
> {
> int ret = 0;
>
> -#ifdef CONFIG_RT2800PCI_SOC
> - ret = platform_driver_register(&rt2800soc_driver);
> - if (ret)
> - return ret;
> -#endif
> #ifdef CONFIG_RT2800PCI_PCI
> ret = pci_register_driver(&rt2800pci_driver);
> if (ret) {
> -#ifdef CONFIG_RT2800PCI_SOC
> - platform_driver_unregister(&rt2800soc_driver);
> -#endif
> return ret;
> }
> #endif
> @@ -1217,9 +1181,6 @@ static void __exit rt2800pci_exit(void)
> #ifdef CONFIG_RT2800PCI_PCI
> pci_unregister_driver(&rt2800pci_driver);
> #endif
> -#ifdef CONFIG_RT2800PCI_SOC
> - platform_driver_unregister(&rt2800soc_driver);
> -#endif
> }
>
> module_init(rt2800pci_init);
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 11/11] Removing dead REDWOOD_{5,6}
From: Christoph Egger @ 2010-07-14 12:41 UTC (permalink / raw)
To: Nicolas Pitre, David S. Miller, Tony Lindgren, Daniel Walker,
Alessandro Rubini
Cc: vamos-dev
In-Reply-To: <cover.1279110894.git.siccegge@cs.fau.de>
REDWOOD_{5,6} doesn't exist in Kconfig, therefore removing all
references for it from the source code.
Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
---
drivers/net/smc91x.h | 37 -------------------------------------
1 files changed, 0 insertions(+), 37 deletions(-)
diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h
index 8d2772c..ee74791 100644
--- a/drivers/net/smc91x.h
+++ b/drivers/net/smc91x.h
@@ -83,43 +83,6 @@ static inline void SMC_outw(u16 val, void __iomem *ioaddr, int reg)
}
}
-#elif defined(CONFIG_REDWOOD_5) || defined(CONFIG_REDWOOD_6)
-
-/* We can only do 16-bit reads and writes in the static memory space. */
-#define SMC_CAN_USE_8BIT 0
-#define SMC_CAN_USE_16BIT 1
-#define SMC_CAN_USE_32BIT 0
-#define SMC_NOWAIT 1
-
-#define SMC_IO_SHIFT 0
-
-#define SMC_inw(a, r) in_be16((volatile u16 *)((a) + (r)))
-#define SMC_outw(v, a, r) out_be16((volatile u16 *)((a) + (r)), v)
-#define SMC_insw(a, r, p, l) \
- do { \
- unsigned long __port = (a) + (r); \
- u16 *__p = (u16 *)(p); \
- int __l = (l); \
- insw(__port, __p, __l); \
- while (__l > 0) { \
- *__p = swab16(*__p); \
- __p++; \
- __l--; \
- } \
- } while (0)
-#define SMC_outsw(a, r, p, l) \
- do { \
- unsigned long __port = (a) + (r); \
- u16 *__p = (u16 *)(p); \
- int __l = (l); \
- while (__l > 0) { \
- /* Believe it or not, the swab isn't needed. */ \
- outw( /* swab16 */ (*__p++), __port); \
- __l--; \
- } \
- } while (0)
-#define SMC_IRQ_FLAGS (0)
-
#elif defined(CONFIG_SA1100_PLEB)
/* We can only do 16-bit reads and writes in the static memory space. */
#define SMC_CAN_USE_8BIT 1
--
1.7.0.4
^ permalink raw reply related
* [PATCH 10/11] Removing dead NETWINDER_{T,R}X_DMA_PROBLEMS
From: Christoph Egger @ 2010-07-14 12:41 UTC (permalink / raw)
To: Samuel Ortiz, David S. Miller, Andrew Morton, Roel Kluin,
Stephen Hemminger <shemminger
Cc: vamos-dev
In-Reply-To: <cover.1279110894.git.siccegge@cs.fau.de>
NETWINDER_{T,R}X_DMA_PROBLEMS doesn't exist in Kconfig, therefore
removing all references for it from the source code.
Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
---
drivers/net/irda/w83977af_ir.c | 33 ++++-----------------------------
1 files changed, 4 insertions(+), 29 deletions(-)
diff --git a/drivers/net/irda/w83977af_ir.c b/drivers/net/irda/w83977af_ir.c
index 1f9c3f0..05c6d79 100644
--- a/drivers/net/irda/w83977af_ir.c
+++ b/drivers/net/irda/w83977af_ir.c
@@ -61,10 +61,6 @@
#include "w83977af.h"
#include "w83977af_ir.h"
-#ifdef CONFIG_ARCH_NETWINDER /* Adjust to NetWinder differences */
-#undef CONFIG_NETWINDER_TX_DMA_PROBLEMS /* Not needed */
-#define CONFIG_NETWINDER_RX_DMA_PROBLEMS /* Must have this one! */
-#endif
#define CONFIG_USE_W977_PNP /* Currently needed */
#define PIO_MAX_SPEED 115200
@@ -565,11 +561,7 @@ static netdev_tx_t w83977af_hard_xmit(struct sk_buff *skb,
static void w83977af_dma_write(struct w83977af_ir *self, int iobase)
{
__u8 set;
-#ifdef CONFIG_NETWINDER_TX_DMA_PROBLEMS
- unsigned long flags;
- __u8 hcr;
-#endif
- IRDA_DEBUG(4, "%s(), len=%d\n", __func__ , self->tx_buff.len);
+ IRDA_DEBUG(4, "%s(), len=%d\n", __func__ , self->tx_buff.len);
/* Save current set */
set = inb(iobase+SSR);
@@ -581,30 +573,13 @@ static void w83977af_dma_write(struct w83977af_ir *self, int iobase)
/* Choose transmit DMA channel */
switch_bank(iobase, SET2);
outb(ADCR1_D_CHSW|/*ADCR1_DMA_F|*/ADCR1_ADV_SL, iobase+ADCR1);
-#ifdef CONFIG_NETWINDER_TX_DMA_PROBLEMS
- spin_lock_irqsave(&self->lock, flags);
-
- disable_dma(self->io.dma);
- clear_dma_ff(self->io.dma);
- set_dma_mode(self->io.dma, DMA_MODE_READ);
- set_dma_addr(self->io.dma, self->tx_buff_dma);
- set_dma_count(self->io.dma, self->tx_buff.len);
-#else
irda_setup_dma(self->io.dma, self->tx_buff_dma, self->tx_buff.len,
DMA_MODE_WRITE);
-#endif
self->io.direction = IO_XMIT;
/* Enable DMA */
switch_bank(iobase, SET0);
-#ifdef CONFIG_NETWINDER_TX_DMA_PROBLEMS
- hcr = inb(iobase+HCR);
- outb(hcr | HCR_EN_DMA, iobase+HCR);
- enable_dma(self->io.dma);
- spin_unlock_irqrestore(&self->lock, flags);
-#else
outb(inb(iobase+HCR) | HCR_EN_DMA | HCR_TX_WT, iobase+HCR);
-#endif
/* Restore set register */
outb(set, iobase+SSR);
@@ -713,7 +688,7 @@ static int w83977af_dma_receive(struct w83977af_ir *self)
{
int iobase;
__u8 set;
-#ifdef CONFIG_NETWINDER_RX_DMA_PROBLEMS
+#ifdef CONFIG_ARCH_NETWINDER
unsigned long flags;
__u8 hcr;
#endif
@@ -738,7 +713,7 @@ static int w83977af_dma_receive(struct w83977af_ir *self)
self->io.direction = IO_RECV;
self->rx_buff.data = self->rx_buff.head;
-#ifdef CONFIG_NETWINDER_RX_DMA_PROBLEMS
+#ifdef CONFIG_ARCH_NETWINDER
spin_lock_irqsave(&self->lock, flags);
disable_dma(self->io.dma);
@@ -761,7 +736,7 @@ static int w83977af_dma_receive(struct w83977af_ir *self)
/* Enable DMA */
switch_bank(iobase, SET0);
-#ifdef CONFIG_NETWINDER_RX_DMA_PROBLEMS
+#ifdef CONFIG_ARCH_NETWINDER
hcr = inb(iobase+HCR);
outb(hcr | HCR_EN_DMA, iobase+HCR);
enable_dma(self->io.dma);
--
1.7.0.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