* [PATCH] ipv6: Silence privacy extensions initialization
From: Romain Francoise @ 2011-01-17 17:59 UTC (permalink / raw)
To: David S. Miller
Cc: Alexey Kuznetsov, Pekka Savola (ipv6), James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev
When a network namespace is created (via CLONE_NEWNET), the loopback
interface is automatically added to the new namespace, triggering a
printk in ipv6_add_dev() if CONFIG_IPV6_PRIVACY is set.
This is problematic for applications which use CLONE_NEWNET as
part of a sandbox, like Chromium's suid sandbox or recent versions of
vsftpd. On a busy machine, it can lead to thousands of useless
"lo: Disabled Privacy Extensions" messages appearing in dmesg.
It's easy enough to check the status of privacy extensions via the
use_tempaddr sysctl, so just removing the printk seems like the most
sensible solution.
Signed-off-by: Romain Francoise <romain@orebokech.com>
---
net/ipv6/addrconf.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 5b189c9..24a1cf1 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -420,9 +420,6 @@ static struct inet6_dev * ipv6_add_dev(struct net_device *dev)
dev->type == ARPHRD_TUNNEL6 ||
dev->type == ARPHRD_SIT ||
dev->type == ARPHRD_NONE) {
- printk(KERN_INFO
- "%s: Disabled Privacy Extensions\n",
- dev->name);
ndev->cnf.use_tempaddr = -1;
} else {
in6_dev_hold(ndev);
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH] CHOKe flow scheduler (0.9)
From: Eric Dumazet @ 2011-01-17 17:54 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Patrick McHardy, David Miller, netdev
In-Reply-To: <20110117092532.7d5f5a5b@nehalam>
Le lundi 17 janvier 2011 à 09:25 -0800, Stephen Hemminger a écrit :
> I rolled in your changes. But there is one more change I want to make.
> The existing flow match based on hash is vulnerable to side-channel DoS attack.
> It is possible for a hostile flow to send packets that match the same
> hash value which would effectively kill a targeted flow.
>
> The solution is to match based on full source and destination, not hash value.
> Still coding that up.
I see, but you only want to make this full test if (!q->filter_list) ?
(or precisely only if skb_get_rxhash() was used to get the cookie )
^ permalink raw reply
* Re: [PATCH v2] net: add Faraday FTMAC100 10/100 Ethernet driver
From: Eric Dumazet @ 2011-01-17 17:29 UTC (permalink / raw)
To: Po-Yu Chuang; +Cc: netdev, linux-kernel, ratbert, bhutchings, joe, dilinger
In-Reply-To: <1295256060-2091-1-git-send-email-ratbert.chuang@gmail.com>
Le lundi 17 janvier 2011 à 17:21 +0800, Po-Yu Chuang a écrit :
> +static int ftmac100_rx_packet(struct ftmac100 *priv, int *processed)
> +{
> + struct net_device *netdev = priv->netdev;
> + struct ftmac100_rxdes *rxdes;
> + struct sk_buff *skb;
> + int length;
> + int copied = 0;
> + int done = 0;
> +
> + rxdes = ftmac100_rx_locate_first_segment(priv);
> + if (!rxdes)
> + return 0;
> +
> + length = ftmac100_rxdes_frame_length(rxdes);
> +
> + netdev->stats.rx_packets++;
> + netdev->stats.rx_bytes += length;
> +
> + if (unlikely(ftmac100_rx_packet_error(priv, rxdes))) {
> + ftmac100_rx_drop_packet(priv);
> + return 1;
> + }
> +
> + /* start processing */
> + skb = netdev_alloc_skb_ip_align(netdev, length);
> + if (unlikely(!skb)) {
> + if (net_ratelimit())
> + netdev_err(netdev, "rx skb alloc failed\n");
> +
> + ftmac100_rx_drop_packet(priv);
> + return 1;
> + }
> +
Please dont increase rx_packets/rx_bytes before the
netdev_alloc_skb_ip_align().
In case of mem allocation failure, it would be better not pretending we
handled a packet.
drivers/net/r8169.c for example does the rx_packets/rx_bytes only if
packet is delivered to upper stack.
^ permalink raw reply
* Re: [PATCH] CHOKe flow scheduler (0.9)
From: Stephen Hemminger @ 2011-01-17 17:25 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Patrick McHardy, David Miller, netdev
In-Reply-To: <1295077542.3977.20.camel@edumazet-laptop>
On Sat, 15 Jan 2011 08:45:42 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 14 janvier 2011 à 15:45 -0800, Stephen Hemminger a écrit :
> > CHOKe ("CHOose and Kill" or "CHOose and Keep") is an alternative
> > packet scheduler based on the Random Exponential Drop (RED) algorithm.
> >
> > The core idea is:
> > For every packet arrival:
> > Calculate Qave
> > if (Qave < minth)
> > Queue the new packet
> > else
> > Select randomly a packet from the queue
> > if (both packets from same flow)
> > then Drop both the packets
> > else if (Qave > maxth)
> > Drop packet
> > else
> > Admit packet with proability p (same as RED)
> >
> > See also:
> > Rong Pan, Balaji Prabhakar, Konstantinos Psounis, "CHOKe: a stateless active
> > queue management scheme for approximating fair bandwidth allocation",
> > Proceeding of INFOCOM'2000, March 2000.
> >
> > Help from:
> > Eric Dumazet <eric.dumazet@gmail.com>
> > Patrick McHardy <kaber@trash.net>
> >
> > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> >
> > ---
> > This version is based on net-next, and assumes Eric's patch for
> > corrected bstats is already applied.
> >
> > 0.9 incorporate patches from Patrick/Eric
> > rework the peek_random and drop code to simplify and fix bug where
> > random_N needs to called with full length (including holes).
>
> Nice catch, I now have more "matched" counts after my test :
>
> qdisc choke 11: parent 1:11 limit 130000b min 10833b max 32500b ewma 13 Plog 21 Scell_log 30
> Sent 93944198 bytes 170889 pkt (dropped 829140, overlimits 436686 requeues 0)
> rate 48bit 0pps backlog 0b 0p requeues 0
> marked 0 early 436686 pdrop 0 other 0 matched 196227
>
> You missed the qdisc_bstats_update() move from enqueue() to dequeue()
>
> And some minor CodingStyle / checkpatch.pl changes, here is my
> latest diff on top of 0.9
>
> I believe you can release v1 :)
>
> Thanks !
I rolled in your changes. But there is one more change I want to make.
The existing flow match based on hash is vulnerable to side-channel DoS attack.
It is possible for a hostile flow to send packets that match the same
hash value which would effectively kill a targeted flow.
The solution is to match based on full source and destination, not hash value.
Still coding that up.
--
^ permalink raw reply
* Re: [PATCH v2] net: add Faraday FTMAC100 10/100 Ethernet driver
From: Joe Perches @ 2011-01-17 17:19 UTC (permalink / raw)
To: Po-Yu Chuang
Cc: netdev, linux-kernel, ratbert, bhutchings, eric.dumazet, dilinger
In-Reply-To: <1295256060-2091-1-git-send-email-ratbert.chuang@gmail.com>
On Mon, 2011-01-17 at 17:21 +0800, Po-Yu Chuang wrote:
> From: Po-Yu Chuang <ratbert@faraday-tech.com>
> FTMAC100 Ethernet Media Access Controller supports 10/100 Mbps and
> MII. This driver has been working on some ARM/NDS32 SoC's including
> Faraday A320 and Andes AG101.
Hi again.
> Signed-off-by: Po-Yu Chuang <ratbert@faraday-tech.com>
> ---
> v2:
> always use NAPI
> do not use our own net_device_stats structure
> don't set trans_start and last_rx
> stats.rx_packets and stats.rx_bytes include dropped packets
> add missed netif_napi_del()
> initialize spinlocks in probe function
> remove rx_lock and hw_lock
> use netdev_[err/info/dbg] instead of dev_* ones
> use netdev_alloc_skb_ip_align()
> remove ftmac100_get_stats()
> use is_valid_ether_addr() instead of is_zero_ether_addr()
> add const to ftmac100_ethtool_ops and ftmac100_netdev_ops
> use net_ratelimit() instead of printk_ratelimit()
> no explicit inline
> use %pM to print MAC address
> add comment before wmb
> use napi poll() to handle all interrupts
This looks very clean, thanks for doing the rework.
Now the the really trivial...
> + * priveate data
private
> +static void ftmac100_enable_all_int(struct ftmac100 *priv)
> +{
> + unsigned int imr;
> +
> + imr = FTMAC100_INT_RPKT_FINISH | FTMAC100_INT_NORXBUF
> + | FTMAC100_INT_XPKT_OK | FTMAC100_INT_XPKT_LOST
> + | FTMAC100_INT_RPKT_LOST | FTMAC100_INT_AHB_ERR
> + | FTMAC100_INT_PHYSTS_CHG;
This could be a #define.
> + maccr = FTMAC100_MACCR_XMT_EN |
> + FTMAC100_MACCR_RCV_EN |
> + FTMAC100_MACCR_XDMA_EN |
> + FTMAC100_MACCR_RDMA_EN |
> + FTMAC100_MACCR_CRC_APD |
> + FTMAC100_MACCR_FULLDUP |
> + FTMAC100_MACCR_RX_RUNT |
> + FTMAC100_MACCR_RX_BROADPKT;
Here too.
> +static int ftmac100_rx_packet_error(struct ftmac100 *priv,
> + struct ftmac100_rxdes *rxdes)
[]
> + if (unlikely(ftmac100_rxdes_frame_too_long(rxdes))) {
> + if (net_ratelimit())
> + netdev_info(netdev, "rx frame too long\n");
> +
> + netdev->stats.rx_length_errors++;
> + error = 1;
> + }
> +
> + if (unlikely(ftmac100_rxdes_runt(rxdes))) {
else if ?
> +static int ftmac100_rx_packet(struct ftmac100 *priv, int *processed)
> +{
> + struct net_device *netdev = priv->netdev;
> + struct ftmac100_rxdes *rxdes;
> + struct sk_buff *skb;
> + int length;
> + int copied = 0;
> + int done = 0;
You could use bool/true/false here for copied and done
and all the other uses of an int for a logical bool.
> +static void ftmac100_txdes_set_dma_own(struct ftmac100_txdes *txdes)
> +{
> + /*
> + * Make sure dma own bit will not be set before any other
> + * descriptor fiels.
field/fields
> +static int ftmac100_mdio_read(struct net_device *netdev, int phy_id, int reg)
> +{
> + struct ftmac100 *priv = netdev_priv(netdev);
> + int phycr;
> + int i;
> +
> + phycr = FTMAC100_PHYCR_PHYAD(phy_id) |
> + FTMAC100_PHYCR_REGAD(reg) |
> + FTMAC100_PHYCR_MIIRD;
> +
> + iowrite32(phycr, priv->base + FTMAC100_OFFSET_PHYCR);
> + for (i = 0; i < 10; i++) {
> + phycr = ioread32(priv->base + FTMAC100_OFFSET_PHYCR);
> +
> + if ((phycr & FTMAC100_PHYCR_MIIRD) == 0)
> + return phycr & FTMAC100_PHYCR_MIIRDATA;
> +
> + usleep_range(100, 1000);
> + }
> +
> + netdev_err(netdev, "mdio read timed out\n");
> + return 0xffff;
0xffff is a rather odd return, perhaps a #define?
> +/******************************************************************************
> + * initialization / finalization
> + *****************************************************************************/
> +static int __init ftmac100_init(void)
> +{
> + printk(KERN_INFO "Loading " DRV_NAME ": version " DRV_VERSION " ...\n");
You could use
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
before any #include and
pr_info("Loading version " DRV_VERSION " ...\n");
One last comment on split long line indentation style
and long function declarations.
There's no required style so you can use what you are
most comfortable doing.
Most of drivers/net uses an alignment to open parenthesis
using maximal tabs and minimal necessary spaces instead of
an extra tabstop.
Like:
static int some_long_function(type var1, type var2...
type varN)
and
some_long_function(var1, var2, ...
varN);
not
static int some_long_function(type var1, type var2...
type varN)
and
some_long_function(var1, var2, ...
varN);
^ permalink raw reply
* [PATCHv2] USB CDC NCM: tx_fixup() race condition fix
From: Alexey Orishko @ 2011-01-17 17:07 UTC (permalink / raw)
To: linux-usb; +Cc: netdev, davem, gregkh, yauheni.kaliuta, Alexey Orishko
- tx_fixup() can be called from either timer callback or from xmit()
in usbnet, so spinlock is added to avoid concurrency-related problem.
- minor correction due to checkpatch warning for some line over 80
chars after previous patch was applied.
Signed-off-by: Alexey Orishko <alexey.orishko@stericsson.com>
---
drivers/net/usb/cdc_ncm.c | 19 ++++++++++++-------
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index d776c4a..04e8ce1 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -54,7 +54,7 @@
#include <linux/usb/usbnet.h>
#include <linux/usb/cdc.h>
-#define DRIVER_VERSION "30-Nov-2010"
+#define DRIVER_VERSION "17-Jan-2011"
/* CDC NCM subclass 3.2.1 */
#define USB_CDC_NCM_NDP16_LENGTH_MIN 0x10
@@ -868,15 +868,19 @@ static void cdc_ncm_tx_timeout(unsigned long arg)
if (ctx->tx_timer_pending != 0) {
ctx->tx_timer_pending--;
restart = 1;
- } else
+ } else {
restart = 0;
+ }
spin_unlock(&ctx->mtx);
- if (restart)
+ if (restart) {
+ spin_lock(&ctx->mtx);
cdc_ncm_tx_timeout_start(ctx);
- else if (ctx->netdev != NULL)
+ spin_unlock(&ctx->mtx);
+ } else if (ctx->netdev != NULL) {
usbnet_start_xmit(NULL, ctx->netdev);
+ }
}
static struct sk_buff *
@@ -900,7 +904,6 @@ cdc_ncm_tx_fixup(struct usbnet *dev, struct sk_buff *skb, gfp_t flags)
skb_out = cdc_ncm_fill_tx_frame(ctx, skb);
if (ctx->tx_curr_skb != NULL)
need_timer = 1;
- spin_unlock(&ctx->mtx);
/* Start timer, if there is a remaining skb */
if (need_timer)
@@ -908,6 +911,8 @@ cdc_ncm_tx_fixup(struct usbnet *dev, struct sk_buff *skb, gfp_t flags)
if (skb_out)
dev->net->stats.tx_packets += ctx->tx_curr_frame_num;
+
+ spin_unlock(&ctx->mtx);
return skb_out;
error:
@@ -1020,8 +1025,8 @@ static int cdc_ncm_rx_fixup(struct usbnet *dev, struct sk_buff *skb_in)
if (((offset + temp) > actlen) ||
(temp > CDC_NCM_MAX_DATAGRAM_SIZE) || (temp < ETH_HLEN)) {
pr_debug("invalid frame detected (ignored)"
- "offset[%u]=%u, length=%u, skb=%p\n",
- x, offset, temp, skb_in);
+ "offset[%u]=%u, length=%u, skb=%p\n",
+ x, offset, temp, skb_in);
if (!x)
goto error;
break;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] dummy: do not create a link (dummy0) at module init by default
From: Stephen Hemminger @ 2011-01-17 16:56 UTC (permalink / raw)
To: David Ward; +Cc: netdev
In-Reply-To: <1295225393-5779-1-git-send-email-david.ward@ll.mit.edu>
On Sun, 16 Jan 2011 19:49:53 -0500
David Ward <david.ward@ll.mit.edu> wrote:
> When the dummy network driver is initialized with no parameters, a link
> is automatically created (named 'dummy0'). This is inconsistent with
> other virtual network drivers such as veth, macvlan, and macvtap, which
> do not create a link upon initialization.
>
> This also causes confusing behavior when sending an RTM_NEWLINK message
> for a dummy link, because the kernel will load the dummy network driver
> first if it has not already been loaded. When that occurs, the result
> is that two new links are actually created (or if IFLA_IFNAME is set to
> 'dummy0', the error EEXIST is returned). The following iproute command
> demonstrates this behavior:
>
> ip link add [ name dummy0 ] type dummy
>
> With this change, users who still want to have a link created when the
> dummy network driver is loaded (instead of using iproute to create the
> link as shown above) just need to set the 'numdummies' parameter to 1:
>
> modprobe dummy numdummies=1
>
> Signed-off-by: David Ward <david.ward@ll.mit.edu>
I understand what you are trying to do, and it makes sense.
But because of the history behind this it can't change.
We can't change existing API and break user scripts.
The 'ip link' command support is new (in last couple of years), and
the module parameter has been around since early days.
If you want to load module without any devices just use:
modprobe dummy numdummies=0
--
^ permalink raw reply
* Re: [Patch] Kill off warning: ‘inline’ is not at beginning of declaration
From: Gustavo F. Padovan @ 2011-01-17 16:13 UTC (permalink / raw)
To: Jesper Juhl
Cc: alsa-devel, Mauro Carvalho Chehab, Takashi Iwai,
Frederic Weisbecker, H. Peter Anvin, Jaroslav Kysela, Jens Axboe,
Stephen Hemminger, Andi Kleen, Pekka Savola (ipv6), x86,
James Morris, Ingo Molnar, oprofile-list, Alexey Kuznetsov,
Mark Fasheh, Marcel Holtmann, John W. Linville, David Teigland,
Joel Becker, Thomas Gleixner, linux-edac, trivial,
Hideaki YOSHIFUJI, netdev, Greg
In-Reply-To: <alpine.LNX.2.00.1101170000270.13377@swampdragon.chaosbits.net>
* Jesper Juhl <jj@chaosbits.net> [2011-01-17 00:09:38 +0100]:
> Fix a bunch of
> warning: ‘inline’ is not at beginning of declaration
> messages when building a 'make allyesconfig' kernel with -Wextra.
>
> These warnings are trivial to kill, yet rather annoying when building with
> -Wextra.
> The more we can cut down on pointless crap like this the better (IMHO).
>
> A previous patch to do this for a 'allnoconfig' build has already been
> merged. This just takes the cleanup a little further.
>
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
> ---
> arch/x86/oprofile/op_model_p4.c | 2 +-
> drivers/bluetooth/btusb.c | 4 ++--
> drivers/cpuidle/sysfs.c | 2 +-
> drivers/edac/i7300_edac.c | 2 +-
> fs/ocfs2/dir.c | 2 +-
> kernel/trace/ring_buffer.c | 2 +-
> net/ipv6/inet6_hashtables.c | 2 +-
> net/mac80211/tx.c | 2 +-
> sound/pci/au88x0/au88x0.h | 4 ++--
> sound/pci/au88x0/au88x0_core.c | 4 ++--
> 10 files changed, 13 insertions(+), 13 deletions(-)
For drivers/bluetooth
Acked-by: Gustavo F. Padovan <padovan@profusion.mobi>
--
Gustavo F. Padovan
http://profusion.mobi
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
oprofile-list mailing list
oprofile-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oprofile-list
^ permalink raw reply
* Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX
From: Ben Hutchings @ 2011-01-17 16:00 UTC (permalink / raw)
To: Simon Arlott; +Cc: netdev, Linux Kernel Mailing List, jesse, Herbert Xu
In-Reply-To: <4D32FC1C.3010905@simon.arlott.org.uk>
On Sun, 2011-01-16 at 14:09 +0000, Simon Arlott wrote:
> [ 1.666706] forcedeth 0000:00:08.0: ifname eth0, PHY OUI 0x5043 @ 16, addr 00:e0:81:4d:2b:ec
> [ 1.666767] forcedeth 0000:00:08.0: highdma csum vlan pwrctl mgmt gbit lnktim msi desc-v3
>
> I have eth0 and eth0.3840 which works until I add eth0 to a bridge.
> While eth0 is in a bridge (the bridge device is up), eth0.3840 is unable
> to receive packets. Using tcpdump on eth0 shows the packets being
> received with a VLAN tag but they don't appear on eth0.3840. They appear
> with the VLAN tag on the bridge interface.
[...]
This means the behaviour is now consistent, whether or not hardware VLAN
tag stripping is enabled. (I previously pointed out the inconsistent
behaviour in <http://thread.gmane.org/gmane.linux.network/149864>.) I
would consider this an improvement.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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] USB CDC NCM: tx_fixup() race condition fix
From: Alexey ORISHKO @ 2011-01-17 15:04 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
gregkh-l3A5Bk7waGM@public.gmane.org,
yauheni.kaliuta-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org
In-Reply-To: <4D3458F7.5070209-hkdhdckH98+B+jHODAdFcQ@public.gmane.org>
> > - tx_fixup() call be called from either timer callback or from xmit()
>
> s/call/can/?
Yes :-)
>
> > in usbnet, so spinlock is added to avoid concurrency-related
> problem.
> > - minor correction due checkpatch warning for some line over 80 chars
>
> Due to?
yep
Sorry for typos...
Regards,
alexey
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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] USB CDC NCM: tx_fixup() race condition fix
From: Sergei Shtylyov @ 2011-01-17 14:57 UTC (permalink / raw)
To: Alexey Orishko
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, gregkh-l3A5Bk7waGM,
yauheni.kaliuta-xNZwKgViW5gAvxtiuMwx3w, Alexey Orishko
In-Reply-To: <1295271573-8890-1-git-send-email-alexey.orishko-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>
Hello.
Alexey Orishko wrote:
> - tx_fixup() call be called from either timer callback or from xmit()
s/call/can/?
> in usbnet, so spinlock is added to avoid concurrency-related problem.
> - minor correction due checkpatch warning for some line over 80 chars
Due to?
> after previous patch was applied.
> Signed-off-by: Alexey Orishko <alexey.orishko-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>
> ---
> drivers/net/usb/cdc_ncm.c | 13 ++++++++-----
> 1 files changed, 8 insertions(+), 5 deletions(-)
> diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
> index d776c4a..bf13fa6 100644
> --- a/drivers/net/usb/cdc_ncm.c
> +++ b/drivers/net/usb/cdc_ncm.c
> @@ -54,7 +54,7 @@
> #include <linux/usb/usbnet.h>
> #include <linux/usb/cdc.h>
>
> -#define DRIVER_VERSION "30-Nov-2010"
> +#define DRIVER_VERSION "17-Jan-2011"
>
> /* CDC NCM subclass 3.2.1 */
> #define USB_CDC_NCM_NDP16_LENGTH_MIN 0x10
> @@ -873,9 +873,11 @@ static void cdc_ncm_tx_timeout(unsigned long arg)
>
> spin_unlock(&ctx->mtx);
>
> - if (restart)
> + if (restart) {
> + spin_lock(&ctx->mtx);
> cdc_ncm_tx_timeout_start(ctx);
> - else if (ctx->netdev != NULL)
> + spin_unlock(&ctx->mtx);
> + } else if (ctx->netdev != NULL)
The 'else' branch should now also have {}, according to
Documentation/CodingStyle.
> usbnet_start_xmit(NULL, ctx->netdev);
> }
>
> @@ -1021,7 +1024,7 @@ static int cdc_ncm_rx_fixup(struct usbnet *dev, struct sk_buff *skb_in)
> (temp > CDC_NCM_MAX_DATAGRAM_SIZE) || (temp < ETH_HLEN)) {
> pr_debug("invalid frame detected (ignored)"
> "offset[%u]=%u, length=%u, skb=%p\n",
> - x, offset, temp, skb_in);
> + x, offset, temp, skb_in);
Would be good to align uniformly with the previous line...
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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: Merging SSB and HND/AI support
From: Jonas Gorski @ 2011-01-17 14:01 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Michael Büsch, linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <AANLkTinwGaqg8ahGWd3+_dfhrCNTQNOfO1E-EUepFJ+C-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 17 January 2011 14:54, Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
> If it's AMBA, can it be integrated with the existing code in drivers/amba/?
Hm, I once had a sentence about it there, I must have accidentally deleted it.
I tried finding similarities between Broadcom's code and ARM's AMBA
specification to better understand the code, but except some tiny ones
I couldn't find anything usable. Unfortunately I couldn't find
anything about Broadcom's AMBA implementation, except that it's "AMBA"
licensed from ARM.
Jonas
--
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] Kill off warning: ‘inline’ is not at beginning of declaration
From: John W. Linville @ 2011-01-17 13:55 UTC (permalink / raw)
To: Jesper Juhl
Cc: alsa-devel, Mauro Carvalho Chehab, Takashi Iwai,
Frederic Weisbecker, Gustavo F. Padovan, Jens Axboe,
Stephen Hemminger, Andi Kleen, H. Peter Anvin,
Pekka Savola (ipv6), Robert Richter, x86, James Morris,
Ingo Molnar, oprofile-list, Alexey Kuznetsov, Mark Fasheh,
Marcel Holtmann, David Teigland, Joel Becker, Thomas Gleixner,
linux-edac, trivial, Hideaki YOSHIFUJI, netdev, Greg
In-Reply-To: <alpine.LNX.2.00.1101170000270.13377@swampdragon.chaosbits.net>
On Mon, Jan 17, 2011 at 12:09:38AM +0100, Jesper Juhl wrote:
> Fix a bunch of
> warning: ‘inline’ is not at beginning of declaration
> messages when building a 'make allyesconfig' kernel with -Wextra.
>
> These warnings are trivial to kill, yet rather annoying when building with
> -Wextra.
> The more we can cut down on pointless crap like this the better (IMHO).
>
> A previous patch to do this for a 'allnoconfig' build has already been
> merged. This just takes the cleanup a little further.
>
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
> ---
> net/mac80211/tx.c | 2 +-
ack
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* Re: Merging SSB and HND/AI support
From: Geert Uytterhoeven @ 2011-01-17 13:54 UTC (permalink / raw)
To: Jonas Gorski
Cc: Michael Büsch, linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <AANLkTims0DPfG+u9qynuuj_-0WjUr1nAGLuFz3k706T--JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Jan 17, 2011 at 14:43, Jonas Gorski <jonas.gorski-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 17 January 2011 12:57, Michael Büsch <mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org> wrote:
>> Well... I don't really like the idea of running one driver and
>> subsystem implementation on completely distinct types of silicon.
>> We will end up with the same mess that broadcom ended up with in
>> their "SB" code (broadcom's SSB backplane implementation).
>> For example, in their code the driver calls pci_enable_device() and
>> related PCI functions, even if there is no PCI device at all. The calls
>> are magically re-routed to the actual SB backplane.
>> You'd have to do the same mess with SSB. Calling ssb_device_enable()
>> will mean "enable the SSB device", if the backplane is SSB, and will
>> mean "enable the HND/AI" device, if the backplane is HND/AI.
> P.S: Any suggestions for the name? Would be "ai" okay? Technically
> it's "AMBA Interconnect", but "amba" is already taken.
If it's AMBA, can it be integrated with the existing code in drivers/amba/?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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: Merging SSB and HND/AI support
From: Jonas Gorski @ 2011-01-17 13:43 UTC (permalink / raw)
To: Michael Büsch; +Cc: linux-mips, linux-wireless, netdev
In-Reply-To: <1295265468.24530.23.camel@maggie>
On 17 January 2011 12:57, Michael Büsch <mb@bu3sch.de> wrote:
> Well... I don't really like the idea of running one driver and
> subsystem implementation on completely distinct types of silicon.
> We will end up with the same mess that broadcom ended up with in
> their "SB" code (broadcom's SSB backplane implementation).
> For example, in their code the driver calls pci_enable_device() and
> related PCI functions, even if there is no PCI device at all. The calls
> are magically re-routed to the actual SB backplane.
> You'd have to do the same mess with SSB. Calling ssb_device_enable()
> will mean "enable the SSB device", if the backplane is SSB, and will
> mean "enable the HND/AI" device, if the backplane is HND/AI.
It didn't strike me as that bad, but I also didn't look at any PCI code.
> So I'm still in favor of doing a separate HND/AI bus implementation,
> even if
> that means duplicating a few lines of code.
Well, it means at least duplicating most of the chipcommon driver and
the mips core driver. But if you are fine with that, I see no problem
with having a separate driver for the AI bus.
> SSB doesn't search for SSB busses in the system, because there's no
> way to do so. The architecture (or the PCI/PCMCIA/SDIO device) registers
> the bus,
> if it detected an SSB device. So for the embedded case, it's hardcoded
> in the arch code. For the PCI case it simply depends on the PCI IDs.
> I don't see a problem here. Your arch code will already have to know
> what machine it is running on. So it will have to decide whether to
> register a SSB or HND/AI bus.
Okay. This is mostly for the embedded case, where it is possible to
create a single kernel that boots on both. The "detection" could also
be done through the cpu type (74k => register AI bus, else SSB bus)
instead of the chipid register of the common core.
>> Also I don't know
>> if it is a good idea to let arch-specific code depend on code in
>> staging.
>
> Sure. The code needs to be cleaned up and moved to the mainline kernel
> _anyway_. You don't get around this.
Yes, you are right.
So I guess the proposed course of action would be:
1. Make the HND/AI-Bus code from brcm80211 its own independent driver,
2. Re-add the non-wifi related code (chipcommon, mips, etc),
3. Clean up the code until it meets Linux' code style/quality,
4. Move it out of staging,
and finally
5. Add the required arch specific code to bcm47xx for the newer SoCs.
Jonas
P.S: Any suggestions for the name? Would be "ai" okay? Technically
it's "AMBA Interconnect", but "amba" is already taken.
^ permalink raw reply
* [PATCH] USB CDC NCM: tx_fixup() race condition fix
From: Alexey Orishko @ 2011-01-17 13:39 UTC (permalink / raw)
To: linux-usb-u79uwXL29TY76Z2rM5mHXA
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
gregkh-l3A5Bk7waGM, yauheni.kaliuta-xNZwKgViW5gAvxtiuMwx3w,
Alexey Orishko
- tx_fixup() call be called from either timer callback or from xmit()
in usbnet, so spinlock is added to avoid concurrency-related problem.
- minor correction due checkpatch warning for some line over 80 chars
after previous patch was applied.
Signed-off-by: Alexey Orishko <alexey.orishko-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>
---
drivers/net/usb/cdc_ncm.c | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index d776c4a..bf13fa6 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -54,7 +54,7 @@
#include <linux/usb/usbnet.h>
#include <linux/usb/cdc.h>
-#define DRIVER_VERSION "30-Nov-2010"
+#define DRIVER_VERSION "17-Jan-2011"
/* CDC NCM subclass 3.2.1 */
#define USB_CDC_NCM_NDP16_LENGTH_MIN 0x10
@@ -873,9 +873,11 @@ static void cdc_ncm_tx_timeout(unsigned long arg)
spin_unlock(&ctx->mtx);
- if (restart)
+ if (restart) {
+ spin_lock(&ctx->mtx);
cdc_ncm_tx_timeout_start(ctx);
- else if (ctx->netdev != NULL)
+ spin_unlock(&ctx->mtx);
+ } else if (ctx->netdev != NULL)
usbnet_start_xmit(NULL, ctx->netdev);
}
@@ -900,7 +902,6 @@ cdc_ncm_tx_fixup(struct usbnet *dev, struct sk_buff *skb, gfp_t flags)
skb_out = cdc_ncm_fill_tx_frame(ctx, skb);
if (ctx->tx_curr_skb != NULL)
need_timer = 1;
- spin_unlock(&ctx->mtx);
/* Start timer, if there is a remaining skb */
if (need_timer)
@@ -908,6 +909,8 @@ cdc_ncm_tx_fixup(struct usbnet *dev, struct sk_buff *skb, gfp_t flags)
if (skb_out)
dev->net->stats.tx_packets += ctx->tx_curr_frame_num;
+
+ spin_unlock(&ctx->mtx);
return skb_out;
error:
@@ -1021,7 +1024,7 @@ static int cdc_ncm_rx_fixup(struct usbnet *dev, struct sk_buff *skb_in)
(temp > CDC_NCM_MAX_DATAGRAM_SIZE) || (temp < ETH_HLEN)) {
pr_debug("invalid frame detected (ignored)"
"offset[%u]=%u, length=%u, skb=%p\n",
- x, offset, temp, skb_in);
+ x, offset, temp, skb_in);
if (!x)
goto error;
break;
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 related
* Re: rps testing questions
From: Ben Hutchings @ 2011-01-17 13:08 UTC (permalink / raw)
To: mi wake; +Cc: netdev
In-Reply-To: <AANLkTin1pC=auiFBt83YomdhVgUO8uSdvq=tPaDu0=3U@mail.gmail.com>
On Mon, 2011-01-17 at 17:43 +0800, mi wake wrote:
> I do a rps(Receive Packet Steering) testing on centos 5.5 with kernel 2.6.37.
> cpu: 8 core Intel.
> ethernet adapter: bnx2x
>
> Problem statement:
> enable rps with:
> echo "ff" > /sys/class/net/eth2/queues/rx-0/rps_cpus.
>
> running 1 instances of netperf TCP_RR: netperf -t TCP_RR -H 192.168.0.1 -c -C
> without rps: 9963.48(Trans Rate per sec)
> with rps: 9387.59(Trans Rate per sec)
>
> I do ab and tbench testing also find there is less tps with enable
> rps.but,there is more cpu using when with enable rps.when with enable
> rps ，softirqs is blanced on cpus.
>
> is there something wrong with my test？
In addition to what Eric said, check the interrupt moderation settings
(ethtool -c/-C options). One-way latency for a single request/response
test will be at least the interrupt moderation value.
I haven't tested RPS by itself (Solarflare NICs have plenty of hardware
queues) so I don't know whether it can improve latency. However, RFS
certainly does when there are many flows.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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 v3 00/16] make rpc_pipefs be mountable multiple time
From: Rob Landley @ 2011-01-17 12:30 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Trond Myklebust, J. Bruce Fields, Neil Brown, Pavel Emelyanov,
linux-nfs, David S. Miller, Al Viro, containers, netdev,
linux-kernel
In-Reply-To: <1295012954-7769-1-git-send-email-kas@openvz.org>
On 01/14/2011 07:48 AM, Kirill A. Shutemov wrote:
> Prepare nfs/sunrpc stack to use multiple instances of rpc_pipefs.
> Only for client for now.
Ok, Google is being really unhelpful here.
What is rpc_pipefs for? What uses it, and to do what exactly? Is it
used by nfs server code, or by the client code, or both? Is it a way
for userspace to talk to the kernel, or for the kernel to talk to
itself? Is it used at mount time, or during filesystem operation?
I'm interested in giving this patch series a much more thorough review,
but I can't figure out what the subsystem it's modifying actually _is_.
(Maybe this is something to do with filesystems/nfs/rpc-cache.txt?)
Rob
^ permalink raw reply
* Re: Merging SSB and HND/AI support
From: Michael Büsch @ 2011-01-17 12:00 UTC (permalink / raw)
To: Florian Fainelli
Cc: Jonas Gorski, linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <201101171220.52292.florian-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
On Mon, 2011-01-17 at 12:20 +0100, Florian Fainelli wrote:
> On Monday 17 January 2011 11:56:23 Michael Büsch wrote:
> > On Mon, 2011-01-17 at 11:46 +0100, Jonas Gorski wrote:
> > > Hello,
> > >
> > > I am currently looking into adding support for the newer Broadcom
> > > BCM47xx/53xx SoCs. They require having HND/AI support, which probably
> > > means merging the current SSB code and the HND/AI code from the
> > > brcm80211 driver. Is anyone already working on this?
> > >
> > > As far as I can see, there are two possibilities:
> > >
> > > a) Merge the HND/AI code into the current SSB code, or
> > >
> > > b) add the missing code for SoCs to brcm80211 and replace the SSB code
> > > with it.
> >
> > Why can't we keep those two platforms separated?
>
> That is also what I am wondering about. Considering that previous BCM47xx
> platforms use a MIPS4k core and newer one use MIPS74k or later, you would not
> be able to build a single kernel for both which takes advantages of compile-
> time optimizations targetting MIPS74k. If this ist not a big concern, then
> let's target a single kernel.
Ok, but it should be easily possible to compile both SSB and HND/AI
bus support into one kernel anyway. Nothing prevents drivers from having
an SSB and an HND/AI probe callback.
--
Greetings Michael.
--
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: Merging SSB and HND/AI support
From: Michael Büsch @ 2011-01-17 11:57 UTC (permalink / raw)
To: Jonas Gorski
Cc: linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <AANLkTikJcug7LUTgX_YDD4Z8ZBrdkAdLq8_Epa6TkA5f-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, 2011-01-17 at 12:21 +0100, Jonas Gorski wrote:
> On 17 January 2011 11:56, Michael Büsch <mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org> wrote:
> > On Mon, 2011-01-17 at 11:46 +0100, Jonas Gorski wrote:
> >> a) Merge the HND/AI code into the current SSB code, or
> >>
> >> b) add the missing code for SoCs to brcm80211 and replace the SSB code with it.
> >
> > Why can't we keep those two platforms separated?
> > Is there really a lot of shared code between SSB and HND/AI?
>
> Yes, as far as I understand the AI bus behaves mostly like a SSB bus
> except for places like enabling/disabling cores. E.g. the AI bus also
> has a common core, which has a bit for telling whether its a SSB or AI
> bus, and has the mostly the same registers as the SSB common cores (so
> most driver_chipcommon_* stuff also applies for the AI bus).
Well... I don't really like the idea of running one driver and
subsystem implementation on completely distinct types of silicon.
We will end up with the same mess that broadcom ended up with in
their "SB" code (broadcom's SSB backplane implementation).
For example, in their code the driver calls pci_enable_device() and
related PCI functions, even if there is no PCI device at all. The calls
are magically re-routed to the actual SB backplane.
You'd have to do the same mess with SSB. Calling ssb_device_enable()
will mean "enable the SSB device", if the backplane is SSB, and will
mean "enable the HND/AI" device, if the backplane is HND/AI.
So I'm still in favor of doing a separate HND/AI bus implementation,
even if
that means duplicating a few lines of code. I think that compared to the
workarounds and conditionals needed for getting SSB to run on HND/AI
hardware, it will be a net win.
> > So why do we need to replace or merge SSB in the first place? Can't
> > it co-exist with HND/AI?
>
> It probably can, but then the SSB code must be at least made AI aware
> so it doesn't try to attach itself if it finds one.
SSB doesn't search for SSB busses in the system, because there's no
way to do so. The architecture (or the PCI/PCMCIA/SDIO device) registers
the bus,
if it detected an SSB device. So for the embedded case, it's hardcoded
in the arch code. For the PCI case it simply depends on the PCI IDs.
I don't see a problem here. Your arch code will already have to know
what machine it is running on. So it will have to decide whether to
register a SSB or HND/AI bus.
It's like a platform_device. However, it doesn't use the platform_device
mechanism. There's no technical reason. It would be trivial to port the
SSB bus registration to use platform_device, however.
> Also I don't know
> if it is a good idea to let arch-specific code depend on code in
> staging.
Sure. The code needs to be cleaned up and moved to the mainline kernel
_anyway_. You don't get around this.
--
Greetings Michael.
--
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 v4 05/10] net/fec: add dual fec support for mx28
From: Shawn Guo @ 2011-01-17 11:52 UTC (permalink / raw)
To: Lothar Waßmann
Cc: Uwe Kleine-König, gerg, B32542, netdev, s.hauer, jamie,
baruch, w.sang, r64343, eric, bryan.wu, jamie, davem,
linux-arm-kernel
In-Reply-To: <19763.64214.220441.325208@ipc1.ka-ro>
Hi Lothar,
On Mon, Jan 17, 2011 at 09:16:22AM +0100, Lothar Waßmann wrote:
> Hi,
>
> Shawn Guo writes:
> > On Fri, Jan 14, 2011 at 08:52:23AM +0100, Uwe Kleine-König wrote:
> > > On Fri, Jan 14, 2011 at 01:48:40PM +0800, Shawn Guo wrote:
> > > > Hi Uwe,
> > > >
> > > > On Thu, Jan 13, 2011 at 03:48:05PM +0100, Uwe Kleine-König wrote:
> > > >
> > > > [...]
> > > >
> > > > > > +/* Controller is ENET-MAC */
> > > > > > +#define FEC_QUIRK_ENET_MAC (1 << 0)
> > > > > does this really qualify to be a quirk?
> > > > >
> > > > My understanding is that ENET-MAC is a type of "quirky" FEC
> > > > controller.
> > > >
> > > > > > +/* Controller needs driver to swap frame */
> > > > > > +#define FEC_QUIRK_SWAP_FRAME (1 << 1)
> > > > > IMHO this is a bit misnamed. FEC_QUIRK_NEEDS_BE_DATA or similar would
> > > > > be more accurate.
> > > > >
> > > > When your make this change, you may want to pick a better name for
> > > > function swap_buffer too.
> > > >
> > > > [...]
> > > >
> > > > > > +static void *swap_buffer(void *bufaddr, int len)
> > > > > > +{
> > > > > > + int i;
> > > > > > + unsigned int *buf = bufaddr;
> > > > > > +
> > > > > > + for (i = 0; i < (len + 3) / 4; i++, buf++)
> > > > > > + *buf = cpu_to_be32(*buf);
> > > > > if len isn't a multiple of 4 this accesses bytes behind len. Is this
> > > > > generally OK here? (E.g. because skbs always have a length that is a
> > > > > multiple of 4?)
> > > > The len may not be a multiple of 4. But I believe bufaddr is always
> > > > a buffer allocated in a length that is a multiple of 4, and the 1~3
> > > > bytes exceeding the len very likely has no data that matters. But
> > > > yes, it deserves a safer implementation.
> > > Did you test what happens if bufaddr isn't aligned? Does it work at all
> > > then?
> > >
> > I see many calls passing a len that is not a multiple of 4, but it
> > works good.
> >
> That does not prove anything, actually.
>
> Anyway "bufaddr isn't aligned" != "len is not a multiple of 4".
> Is there any guarantee that the function cannot be called with a
> non-aligned buffer address?
>
Oops, I misunderstood the comment. With bounce buffer alignment
handling removed, the driver stops working. But at least, mx28
fec driver can work with FEC_ALIGNMENT 0x3 and not necessarily with
0xf.
I hope this is what you intended to know.
--
Regards,
Shawn
^ permalink raw reply
* Re: Merging SSB and HND/AI support
From: Jonas Gorski @ 2011-01-17 11:21 UTC (permalink / raw)
To: Michael Büsch
Cc: linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1295261783.24530.3.camel@maggie>
On 17 January 2011 11:56, Michael Büsch <mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org> wrote:
> On Mon, 2011-01-17 at 11:46 +0100, Jonas Gorski wrote:
>> a) Merge the HND/AI code into the current SSB code, or
>>
>> b) add the missing code for SoCs to brcm80211 and replace the SSB code with it.
>
> Why can't we keep those two platforms separated?
> Is there really a lot of shared code between SSB and HND/AI?
Yes, as far as I understand the AI bus behaves mostly like a SSB bus
except for places like enabling/disabling cores. E.g. the AI bus also
has a common core, which has a bit for telling whether its a SSB or AI
bus, and has the mostly the same registers as the SSB common cores (so
most driver_chipcommon_* stuff also applies for the AI bus).
> It's true that there's currently a lot of device functionality built
> into ssb. Like pci bridge, mips core, extif, etc...
> If you take all that code out, you're probably not left with anything.
That's because most shared code isn't in brcm80211, but only found in
the SDKs for the SoCs.
> So why do we need to replace or merge SSB in the first place? Can't
> it co-exist with HND/AI?
It probably can, but then the SSB code must be at least made AI aware
so it doesn't try to attach itself if it finds one. Also I don't know
if it is a good idea to let arch-specific code depend on code in
staging.
Jonas
--
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: Merging SSB and HND/AI support
From: Florian Fainelli @ 2011-01-17 11:20 UTC (permalink / raw)
To: Michael Büsch
Cc: Jonas Gorski, linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1295261783.24530.3.camel@maggie>
On Monday 17 January 2011 11:56:23 Michael Büsch wrote:
> On Mon, 2011-01-17 at 11:46 +0100, Jonas Gorski wrote:
> > Hello,
> >
> > I am currently looking into adding support for the newer Broadcom
> > BCM47xx/53xx SoCs. They require having HND/AI support, which probably
> > means merging the current SSB code and the HND/AI code from the
> > brcm80211 driver. Is anyone already working on this?
> >
> > As far as I can see, there are two possibilities:
> >
> > a) Merge the HND/AI code into the current SSB code, or
> >
> > b) add the missing code for SoCs to brcm80211 and replace the SSB code
> > with it.
>
> Why can't we keep those two platforms separated?
That is also what I am wondering about. Considering that previous BCM47xx
platforms use a MIPS4k core and newer one use MIPS74k or later, you would not
be able to build a single kernel for both which takes advantages of compile-
time optimizations targetting MIPS74k. If this ist not a big concern, then
let's target a single kernel.
> Is there really a lot of shared code between SSB and HND/AI?
>
> It's true that there's currently a lot of device functionality built
> into ssb. Like pci bridge, mips core, extif, etc...
> If you take all that code out, you're probably not left with anything.
>
> So why do we need to replace or merge SSB in the first place? Can't
> it co-exist with HND/AI?
--
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: Merging SSB and HND/AI support
From: Michael Büsch @ 2011-01-17 11:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: Jonas Gorski, linux-mips, linux-wireless, netdev
In-Reply-To: <1295262781.3726.6.camel@jlt3.sipsolutions.net>
On Mon, 2011-01-17 at 12:13 +0100, Johannes Berg wrote:
> On Mon, 2011-01-17 at 11:56 +0100, Michael Büsch wrote:
>
> > > As far as I can see, there are two possibilities:
> > >
> > > a) Merge the HND/AI code into the current SSB code, or
> > >
> > > b) add the missing code for SoCs to brcm80211 and replace the SSB code with it.
> >
> > Why can't we keep those two platforms separated?
> > Is there really a lot of shared code between SSB and HND/AI?
>
> I don't think there's a lot of shared code, but I believe that you need
> b43 to be able to target cores on both? And b43 currently uses the SSB
> APIs only.
Yeah right. That's what I was thinking about, too. Just leave SSB alone
and add bus glues to b43 for HND/AI. There's almost no SSB specific code
in b43. So it should be easily possible to add another probe entry from
the (to be written or derived from brcm80211) HND/AI subsystem.
--
Greetings Michael.
^ permalink raw reply
* Re: Merging SSB and HND/AI support
From: Johannes Berg @ 2011-01-17 11:13 UTC (permalink / raw)
To: Michael Büsch
Cc: Jonas Gorski, linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1295261783.24530.3.camel@maggie>
On Mon, 2011-01-17 at 11:56 +0100, Michael Büsch wrote:
> > As far as I can see, there are two possibilities:
> >
> > a) Merge the HND/AI code into the current SSB code, or
> >
> > b) add the missing code for SoCs to brcm80211 and replace the SSB code with it.
>
> Why can't we keep those two platforms separated?
> Is there really a lot of shared code between SSB and HND/AI?
I don't think there's a lot of shared code, but I believe that you need
b43 to be able to target cores on both? And b43 currently uses the SSB
APIs only.
johannes
--
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
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