* Re: setsockopt(IP_TOS) being privileged or distinct capability?
From: Rémi Denis-Courmont @ 2010-07-06 8:17 UTC (permalink / raw)
To: Philip Prindeville; +Cc: netdev
In-Reply-To: <4C2F7A55.5090700@redfish-solutions.com>
On Sat, 03 Jul 2010 11:58:45 -0600, Philip Prindeville
<philipp_subx@redfish-solutions.com> wrote:
> Does anyone else think that setsockopt(IP_TOS) should be a privileged
> operation, perhaps using CAP_NET_ADMIN, or maybe even adding separate
> granularity as CAP_NET_TOS?
That's a terribly idea.
Some applications do rely on this to set their TOS "correctly". If you
don't want unprivileged applications to be able to affect the queuing
policy, then don't use the TOS bits in your queuing policy - as simple as
that.
--
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis
^ permalink raw reply
* Re: [PATCH 05/11] isdn/gigaset: improve CAPI message debugging
From: Tilman Schmidt @ 2010-07-06 8:14 UTC (permalink / raw)
To: David Miller; +Cc: isdn, hjlipp, keil, i4ldeveloper, netdev, linux-kernel
In-Reply-To: <20100705.192356.52184135.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]
Am 2010-07-06 04:23 schrieb David Miller:
> From: Tilman Schmidt <tilman@imap.cc>
> Date: Tue, 6 Jul 2010 02:18:59 +0200 (CEST)
>
>> @@ -384,7 +388,7 @@ void gigaset_skb_sent(struct bc_state *bcs, struct sk_buff *dskb)
>>
>> /* don't send further B3 messages if disconnected */
>> if (bcs->apconnstate < APCONN_ACTIVE) {
>> - gig_dbg(DEBUG_LLDATA, "disconnected, discarding ack");
>> + gig_dbg(DEBUG_MCMD, "disconnected, discarding ack");
>> return;
>> }
>
> This is against something other than net-next-2.6 even with your
> other two ISDN patches applied, because all of these lines read
> "if (ap->connected ..."
>
> Please tell me what exactly these patches are against so that I
> can apply them to net-next-2.6 cleanly.
They are against mainline and apply cleanly to v2.6.35-rc3.
IOW, they go on top of the series you applied to net-2.6 on
Fri, 25 Jun 2010 21:31:28 -0700 (PDT).
Specifically, the last patch of that series,
> Subject: [PATCH 5/5] isdn/gigaset: correct CAPI connection state storage
makes the switch from ap->connected to bcs->apconnstate.
So if you'll postpone applying last night's series until
after your next merge of net-2.6 into net-next-2.6, it
should then apply cleanly.
Thanks,
Tilman
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
^ permalink raw reply
* Re: [PATCH 00/11] ISDN patches for 2.6.36
From: Tilman Schmidt @ 2010-07-06 7:47 UTC (permalink / raw)
To: David Miller; +Cc: isdn, hjlipp, keil, i4ldeveloper, netdev, linux-kernel
In-Reply-To: <20100705.185352.39176355.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 598 bytes --]
Am 2010-07-06 03:53 schrieb David Miller:
> From: Tilman Schmidt <tilman@imap.cc>
> Date: Tue, 6 Jul 2010 02:18:32 +0200 (CEST)
>
>> Karsten, David,
>>
>> following are a series of patches to the Gigaset driver I'd like
>> to see included in kernel release 2.6.36.
>
> Do they have any dependencies on the two patch set of fixes
> you just sent out for net-2.6?
None. They are completely independent.
I guess your question arose because I gave both series the same
title by mistake. The second one should have been called:
"*Gigaset* patches for 2.6.36".
Thanks,
Tilman
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
^ permalink raw reply
* [PATCH -net-2.6] ll_temac: Fix missing iounmaps
From: Denis Kirjanov @ 2010-07-06 7:44 UTC (permalink / raw)
To: davem; +Cc: john.linn, brian.hill, netdev
Fix missing iounmaps.
Signed-off-by: Denis Kirjanov <dkirjanov@kernel.org>
---
drivers/net/ll_temac_main.c | 18 +++++++++++++-----
1 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ll_temac_main.c b/drivers/net/ll_temac_main.c
index 52dcc84..6474c49 100644
--- a/drivers/net/ll_temac_main.c
+++ b/drivers/net/ll_temac_main.c
@@ -964,7 +964,7 @@ temac_of_probe(struct of_device *op, const struct of_device_id *match)
np = of_parse_phandle(op->dev.of_node, "llink-connected", 0);
if (!np) {
dev_err(&op->dev, "could not find DMA node\n");
- goto nodev;
+ goto err_iounmap;
}
/* Setup the DMA register accesses, could be DCR or memory mapped */
@@ -978,7 +978,7 @@ temac_of_probe(struct of_device *op, const struct of_device_id *match)
dev_dbg(&op->dev, "MEM base: %p\n", lp->sdma_regs);
} else {
dev_err(&op->dev, "unable to map DMA registers\n");
- goto nodev;
+ goto err_iounmap;
}
}
@@ -987,7 +987,7 @@ temac_of_probe(struct of_device *op, const struct of_device_id *match)
if ((lp->rx_irq == NO_IRQ) || (lp->tx_irq == NO_IRQ)) {
dev_err(&op->dev, "could not determine irqs\n");
rc = -ENOMEM;
- goto nodev;
+ goto err_iounmap_2;
}
of_node_put(np); /* Finished with the DMA node; drop the reference */
@@ -997,7 +997,7 @@ temac_of_probe(struct of_device *op, const struct of_device_id *match)
if ((!addr) || (size != 6)) {
dev_err(&op->dev, "could not find MAC address\n");
rc = -ENODEV;
- goto nodev;
+ goto err_iounmap_2;
}
temac_set_mac_address(ndev, (void *)addr);
@@ -1013,7 +1013,7 @@ temac_of_probe(struct of_device *op, const struct of_device_id *match)
rc = sysfs_create_group(&lp->dev->kobj, &temac_attr_group);
if (rc) {
dev_err(lp->dev, "Error creating sysfs files\n");
- goto nodev;
+ goto err_iounmap_2;
}
rc = register_netdev(lp->ndev);
@@ -1026,6 +1026,11 @@ temac_of_probe(struct of_device *op, const struct of_device_id *match)
err_register_ndev:
sysfs_remove_group(&lp->dev->kobj, &temac_attr_group);
+ err_iounmap_2:
+ if (lp->sdma_regs)
+ iounmap(lp->sdma_regs);
+ err_iounmap:
+ iounmap(lp->regs);
nodev:
free_netdev(ndev);
ndev = NULL;
@@ -1044,6 +1049,9 @@ static int __devexit temac_of_remove(struct of_device *op)
of_node_put(lp->phy_node);
lp->phy_node = NULL;
dev_set_drvdata(&op->dev, NULL);
+ iounmap(lp->regs);
+ if (lp->sdma_regs)
+ iounmap(lp->sdma_regs);
free_netdev(ndev);
return 0;
}
--
1.6.4.4
^ permalink raw reply related
* Re: Possible bug in net/ipv4/route.c?
From: Herbert Xu @ 2010-07-06 7:29 UTC (permalink / raw)
To: Guojun Jin
Cc: Stephen Hemminger, Sol Kavy, linux-kernel, Greg Ren, Murat Sezgin,
Sener Ilgen, David S. Miller, netdev
In-Reply-To: <CB2DD11991B27C4F99935E6229450D3203950BE5@STORK.scenix.com>
On Mon, Jul 05, 2010 at 11:06:30PM -0700, Guojun Jin wrote:
>
> Would you please point to where is the best place that CB should be cleared for this case?
>
> I also wonder why IP packet is routed through ARP queue for ICMP delievry.
I was hoping that you guys would figure this out :)
Anyway, this patch should fix the crash.
bridge: Clear IPCB before possible entry into IP stack
The bridge protocol lives dangerously by having incestuous relations
with the IP stack. In this instance an abomination has been created
where a bogus IPCB area from a bridged packet leads to a crash in
the IP stack because it's interpreted as IP options.
This patch papers over the problem by clearing the IPCB area in that
particular spot. To fix this properly we'd also need to parse any
IP options if present but I'm way too lazy for that.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index 4442099..8fb75f8 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -591,6 +591,9 @@ static unsigned int br_nf_pre_routing(unsigned int hook, struct sk_buff *skb,
pskb_trim_rcsum(skb, len);
+ /* BUG: Should really parse the IP options here. */
+ memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
+
nf_bridge_put(skb->nf_bridge);
if (!nf_bridge_alloc(skb))
return NF_DROP;
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* RE: [PATCH] bnx2x: add support for receive hashing
From: Vladislav Zolotarov @ 2010-07-06 7:16 UTC (permalink / raw)
To: Tom Herbert; +Cc: netdev@vger.kernel.org
In-Reply-To: <8628FE4E7912BF47A96AE7DD7BAC0AADDDE646FBFB@SJEXCHCCR02.corp.ad.broadcom.com>
Let me rephrase: the part of your patch below enables RSS flow in our FW even if there is only one HW queue and I wonder why?
To refresh:
1) FW won't provide Toeplitz hash on CQE if RSS is not enabled.
2) There can be one HW queue in only 2 cases:
- There is only one CPU in the system. In that case I wonder if u have anything to do with Toeplitz hash on the skb at all.
- User has explicitly requested 1 HW queue with module parameter (num_queues=1). In that case if u r going to use the RSS hash on the skb means that u r actually going to do SW RSS instead of HW RSS, which sounds strange to me.
So, Herbert, could u, pls., explain, what was your original idea about these code lines?
Thanks,
vlad
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
> Behalf Of Vladislav Zolotarov
> Sent: Sunday, July 04, 2010 7:36 PM
> To: Tom Herbert
> Cc: netdev@vger.kernel.org
> Subject: RE: [PATCH] bnx2x: add support for receive hashing
>
> Tom, could u, pls., explain what did u mean by taking the (RSS) flags
> configuration out of RSS "if"? To recall "if(is_multi(bp))" is true iff RSS
> is enabled.
>
> Thanks,
> vlad
>
> > @@ -5750,10 +5757,10 @@ static void bnx2x_init_internal_func(struct bnx2x
> > *bp)
> > u32 offset;
> > u16 max_agg_size;
> >
> > - if (is_multi(bp)) {
> > - tstorm_config.config_flags = MULTI_FLAGS(bp);
> > + tstorm_config.config_flags = RSS_FLAGS(bp);
> > +
> > + if (is_multi(bp))
> > tstorm_config.rss_result_mask = MULTI_MASK;
> > - }
> >
> > /* Enable TPA if needed */
> > if (bp->flags & TPA_ENABLE_FLAG)
>
>
> > -----Original Message-----
> > From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
> > Behalf Of Tom Herbert
> > Sent: Friday, April 23, 2010 8:54 AM
> > To: davem@davemloft.net; netdev@vger.kernel.org
> > Subject: [PATCH] bnx2x: add support for receive hashing
> >
> > Add support to bnx2x to extract Toeplitz hash out of the receive descriptor
> > for use in skb->rxhash.
> >
> > Signed-off-by: Tom Herbert <therbert@google.com>
> > ---
> > diff --git a/drivers/net/bnx2x.h b/drivers/net/bnx2x.h
> > index 0819530..8bd2368 100644
> > --- a/drivers/net/bnx2x.h
> > +++ b/drivers/net/bnx2x.h
> > @@ -1330,7 +1330,7 @@ static inline u32 reg_poll(struct bnx2x *bp, u32 reg,
> > u32 expected, int ms,
> > AEU_INPUTS_ATTN_BITS_MCP_LATCHED_UMP_TX_PARITY | \
> > AEU_INPUTS_ATTN_BITS_MCP_LATCHED_SCPAD_PARITY)
> >
> > -#define MULTI_FLAGS(bp) \
> > +#define RSS_FLAGS(bp) \
> > (TSTORM_ETH_FUNCTION_COMMON_CONFIG_RSS_IPV4_CAPABILITY | \
> > TSTORM_ETH_FUNCTION_COMMON_CONFIG_RSS_IPV4_TCP_CAPABILITY | \
> > TSTORM_ETH_FUNCTION_COMMON_CONFIG_RSS_IPV6_CAPABILITY | \
> > diff --git a/drivers/net/bnx2x_main.c b/drivers/net/bnx2x_main.c
> > index 0c6dba2..613f727 100644
> > --- a/drivers/net/bnx2x_main.c
> > +++ b/drivers/net/bnx2x_main.c
> > @@ -1582,7 +1582,7 @@ static int bnx2x_rx_int(struct bnx2x_fastpath *fp,
> int
> > budget)
> > struct sw_rx_bd *rx_buf = NULL;
> > struct sk_buff *skb;
> > union eth_rx_cqe *cqe;
> > - u8 cqe_fp_flags;
> > + u8 cqe_fp_flags, cqe_fp_status_flags;
> > u16 len, pad;
> >
> > comp_ring_cons = RCQ_BD(sw_comp_cons);
> > @@ -1598,6 +1598,7 @@ static int bnx2x_rx_int(struct bnx2x_fastpath *fp,
> int
> > budget)
> >
> > cqe = &fp->rx_comp_ring[comp_ring_cons];
> > cqe_fp_flags = cqe->fast_path_cqe.type_error_flags;
> > + cqe_fp_status_flags = cqe->fast_path_cqe.status_flags;
> >
> > DP(NETIF_MSG_RX_STATUS, "CQE type %x err %x status %x"
> > " queue %x vlan %x len %u\n", CQE_TYPE(cqe_fp_flags),
> > @@ -1727,6 +1728,12 @@ reuse_rx:
> >
> > skb->protocol = eth_type_trans(skb, bp->dev);
> >
> > + if ((bp->dev->features & ETH_FLAG_RXHASH) &&
> > + (cqe_fp_status_flags &
> > + ETH_FAST_PATH_RX_CQE_RSS_HASH_FLG))
> > + skb->rxhash = le32_to_cpu(
> > + cqe->fast_path_cqe.rss_hash_result);
> > +
> > skb->ip_summed = CHECKSUM_NONE;
> > if (bp->rx_csum) {
> > if (likely(BNX2X_RX_CSUM_OK(cqe)))
> > @@ -5750,10 +5757,10 @@ static void bnx2x_init_internal_func(struct bnx2x
> > *bp)
> > u32 offset;
> > u16 max_agg_size;
> >
> > - if (is_multi(bp)) {
> > - tstorm_config.config_flags = MULTI_FLAGS(bp);
> > + tstorm_config.config_flags = RSS_FLAGS(bp);
> > +
> > + if (is_multi(bp))
> > tstorm_config.rss_result_mask = MULTI_MASK;
> > - }
> >
> > /* Enable TPA if needed */
> > if (bp->flags & TPA_ENABLE_FLAG)
> > @@ -6629,10 +6636,8 @@ static int bnx2x_init_common(struct bnx2x *bp)
> > bnx2x_init_block(bp, PBF_BLOCK, COMMON_STAGE);
> >
> > REG_WR(bp, SRC_REG_SOFT_RST, 1);
> > - for (i = SRC_REG_KEYRSS0_0; i <= SRC_REG_KEYRSS1_9; i += 4) {
> > - REG_WR(bp, i, 0xc0cac01a);
> > - /* TODO: replace with something meaningful */
> > - }
> > + for (i = SRC_REG_KEYRSS0_0; i <= SRC_REG_KEYRSS1_9; i += 4)
> > + REG_WR(bp, i, random32());
> > bnx2x_init_block(bp, SRCH_BLOCK, COMMON_STAGE);
> > #ifdef BCM_CNIC
> > REG_WR(bp, SRC_REG_KEYSEARCH_0, 0x63285672);
> > @@ -11001,6 +11006,11 @@ static int bnx2x_set_flags(struct net_device *dev,
> > u32 data)
> > changed = 1;
> > }
> >
> > + if (data & ETH_FLAG_RXHASH)
> > + dev->features |= NETIF_F_RXHASH;
> > + else
> > + dev->features &= ~NETIF_F_RXHASH;
> > +
> > if (changed && netif_running(dev)) {
> > bnx2x_nic_unload(bp, UNLOAD_NORMAL);
> > rc = bnx2x_nic_load(bp, LOAD_NORMAL);
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] drivers/net: correct valid flag
From: David Miller @ 2010-07-06 5:16 UTC (permalink / raw)
To: julia; +Cc: netdev, linux-kernel, kernel-janitors
In-Reply-To: <Pine.LNX.4.64.1007060711320.30668@ask.diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Tue, 6 Jul 2010 07:11:45 +0200 (CEST)
> From: Julia Lawall <julia@diku.dk>
>
> Elsewhere in the "optimized" functions, the "2" constants are used.
> NV_TX_VALID and NV_TX2_VALID have the same value.
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
Since the two values are identical this doesn't fix a bug, so I've
applied this to net-next-2.6
Thanks!
^ permalink raw reply
* Re: [PATCH] drivers/net: correct valid flag
From: Julia Lawall @ 2010-07-06 5:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel, kernel-janitors
In-Reply-To: <20100705.180349.112607097.davem@davemloft.net>
From: Julia Lawall <julia@diku.dk>
Elsewhere in the "optimized" functions, the "2" constants are used.
NV_TX_VALID and NV_TX2_VALID have the same value.
Signed-off-by: Julia Lawall <julia@diku.dk>
---
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index 268ea4d..9ef6a9d 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -2468,7 +2468,7 @@ static int nv_tx_done_optimized(struct net_device *dev, int limit)
struct ring_desc_ex* orig_get_tx = np->get_tx.ex;
while ((np->get_tx.ex != np->put_tx.ex) &&
- !((flags = le32_to_cpu(np->get_tx.ex->flaglen)) & NV_TX_VALID) &&
+ !((flags = le32_to_cpu(np->get_tx.ex->flaglen)) & NV_TX2_VALID) &&
(tx_work < limit)) {
dprintk(KERN_DEBUG "%s: nv_tx_done_optimized: flags 0x%x.\n",
^ permalink raw reply related
* Re: [PATCH] drivers/net: correct valid flag
From: Julia Lawall @ 2010-07-06 5:07 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel, kernel-janitors
In-Reply-To: <20100705.180349.112607097.davem@davemloft.net>
On Mon, 5 Jul 2010, David Miller wrote:
> From: Julia Lawall <julia@diku.dk>
> Date: Mon, 5 Jul 2010 17:07:15 +0200 (CEST)
>
> > From: Julia Lawall <julia@diku.dk>
> >
> > Elsewhere in the "optimized" functions, the "2" constants are used.
> > NV_TX_VALID and NV_TX2_VALID have the same value.
> >
> > Signed-off-by: Julia Lawall <julia@diku.dk>
> >
> > ---
> > diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
> > index 268ea4d..870c18b 100644
> > --- a/drivers/net/forcedeth.c
> > +++ b/drivers/net/forcedeth.c
> > @@ -2468,7 +2468,8 @@ static int nv_tx_done_optimized(struct net_device *dev, int limit)
> > struct ring_desc_ex* orig_get_tx = np->get_tx.ex;
> >
> > while ((np->get_tx.ex != np->put_tx.ex) &&
> > - !((flags = le32_to_cpu(np->get_tx.ex->flaglen)) & NV_TX_VALID) &&
> > + !((flags = le32_to_cpu(np->get_tx.ex->flaglen)) & NV_TX2_VALID)
> > + &&
> > (tx_work < limit)) {
>
> Please don't put that "&&" on a line by itself. I don't care if leaving it
> on the previous line makes it exceed 80 columns, what you're doing here is
> infinitely less pleasant to read.
OK, I'll put it back.
julia
^ permalink raw reply
* [PATCH] net: sh_eth: add support for SH7757's ETHER
From: Yoshihiro Shimoda @ 2010-07-06 4:32 UTC (permalink / raw)
To: netdev; +Cc: SH-Linux
The SH7757 has 2 Fast Ethernet controller (ETHER) and 2 Gigabit Ethernet
Controller (GETHER). This patch supports 2 ETHER only.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
drivers/net/Kconfig | 5 ++-
drivers/net/sh_eth.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 55 insertions(+), 3 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index ce2fcdd..663f863 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -530,14 +530,15 @@ config SH_ETH
depends on SUPERH && \
(CPU_SUBTYPE_SH7710 || CPU_SUBTYPE_SH7712 || \
CPU_SUBTYPE_SH7763 || CPU_SUBTYPE_SH7619 || \
- CPU_SUBTYPE_SH7724)
+ CPU_SUBTYPE_SH7724 || CPU_SUBTYPE_SH7757)
select CRC32
select MII
select MDIO_BITBANG
select PHYLIB
help
Renesas SuperH Ethernet device driver.
- This driver support SH7710, SH7712, SH7763, SH7619, and SH7724.
+ This driver supporting CPUs are:
+ - SH7710, SH7712, SH7763, SH7619, SH7724, and SH7757.
config SUNLANCE
tristate "Sun LANCE support"
diff --git a/drivers/net/sh_eth.c b/drivers/net/sh_eth.c
index 501a55f..7ac814d 100644
--- a/drivers/net/sh_eth.c
+++ b/drivers/net/sh_eth.c
@@ -88,6 +88,55 @@ static struct sh_eth_cpu_data sh_eth_my_cpu_data = {
.rpadir = 1,
.rpadir_value = 0x00020000, /* NET_IP_ALIGN assumed to be 2 */
};
+#elif defined(CONFIG_CPU_SUBTYPE_SH7757)
+#define SH_ETH_RESET_DEFAULT 1
+static void sh_eth_set_duplex(struct net_device *ndev)
+{
+ struct sh_eth_private *mdp = netdev_priv(ndev);
+ u32 ioaddr = ndev->base_addr;
+
+ if (mdp->duplex) /* Full */
+ ctrl_outl(ctrl_inl(ioaddr + ECMR) | ECMR_DM, ioaddr + ECMR);
+ else /* Half */
+ ctrl_outl(ctrl_inl(ioaddr + ECMR) & ~ECMR_DM, ioaddr + ECMR);
+}
+
+static void sh_eth_set_rate(struct net_device *ndev)
+{
+ struct sh_eth_private *mdp = netdev_priv(ndev);
+ u32 ioaddr = ndev->base_addr;
+
+ switch (mdp->speed) {
+ case 10: /* 10BASE */
+ ctrl_outl(0, ioaddr + RTRATE);
+ break;
+ case 100:/* 100BASE */
+ ctrl_outl(1, ioaddr + RTRATE);
+ break;
+ default:
+ break;
+ }
+}
+
+/* SH7757 */
+static struct sh_eth_cpu_data sh_eth_my_cpu_data = {
+ .set_duplex = sh_eth_set_duplex,
+ .set_rate = sh_eth_set_rate,
+
+ .eesipr_value = DMAC_M_RFRMER | DMAC_M_ECI | 0x003fffff,
+ .rmcr_value = 0x00000001,
+
+ .tx_check = EESR_FTC | EESR_CND | EESR_DLC | EESR_CD | EESR_RTO,
+ .eesr_err_check = EESR_TWB | EESR_TABT | EESR_RABT | EESR_RDE |
+ EESR_RFRMER | EESR_TFE | EESR_TDE | EESR_ECI,
+ .tx_error_check = EESR_TWB | EESR_TABT | EESR_TDE | EESR_TFE,
+
+ .apr = 1,
+ .mpr = 1,
+ .tpauser = 1,
+ .hw_swap = 1,
+ .no_ade = 1,
+};
#elif defined(CONFIG_CPU_SUBTYPE_SH7763)
#define SH_ETH_HAS_TSU 1
@@ -1023,7 +1072,9 @@ static int sh_eth_open(struct net_device *ndev)
pm_runtime_get_sync(&mdp->pdev->dev);
ret = request_irq(ndev->irq, sh_eth_interrupt,
-#if defined(CONFIG_CPU_SUBTYPE_SH7763) || defined(CONFIG_CPU_SUBTYPE_SH7764)
+#if defined(CONFIG_CPU_SUBTYPE_SH7763) || \
+ defined(CONFIG_CPU_SUBTYPE_SH7764) || \
+ defined(CONFIG_CPU_SUBTYPE_SH7757)
IRQF_SHARED,
#else
0,
--
1.7.1
^ permalink raw reply related
* linux-next: build warning after merge of the net tree
From: Stephen Rothwell @ 2010-07-06 4:25 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Joe Perches, Greg Kroah-Hartman
[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]
Hi Dave,
After merging the net tree, today's linux-next build (powerpc
ppc64_defconfig) produced these warnings:
drivers/scsi/sym53c8xx_2/sym_hipd.c: In function 'sym_print_msg':
drivers/scsi/sym53c8xx_2/sym_hipd.c:78: warning: zero-length gnu_printf format string
drivers/scsi/constants.c: In function 'scsi_print_sense':
drivers/scsi/constants.c:1407: warning: zero-length gnu_printf format string
drivers/scsi/constants.c:1413: warning: zero-length gnu_printf format string
drivers/scsi/constants.c: In function 'scsi_print_result':
drivers/scsi/constants.c:1456: warning: zero-length gnu_printf format string
drivers/scsi/sd.c: In function 'sd_print_sense_hdr':
drivers/scsi/sd.c:2599: warning: zero-length gnu_printf format string
drivers/scsi/sd.c:2601: warning: zero-length gnu_printf format string
drivers/scsi/sd.c: In function 'sd_print_result':
drivers/scsi/sd.c:2607: warning: zero-length gnu_printf format string
(There may be more ...)
Introduced by commit 99bcf217183e02ebae46373896fba7f12d588001 ("device.h
drivers/base/core.c Convert dev_<level> logging macros to functions").
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Splice status
From: Eric Dumazet @ 2010-07-06 3:56 UTC (permalink / raw)
To: Changli Gao; +Cc: Jens Axboe, Ofer Heifetz, netdev@vger.kernel.org
In-Reply-To: <AANLkTim_eBmT-6HmkqG5d7k0jjrGKAFBjzqVCricTpgK@mail.gmail.com>
Le mardi 06 juillet 2010 à 10:01 +0800, Changli Gao a écrit :
> On Mon, Jul 5, 2010 at 8:50 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > Le lundi 05 juillet 2010 à 13:52 +0300, Ofer Heifetz a écrit :
> >> I am using Samba, so from my understanding of the source code, it
> > loops and performs splice(sock, pipe) and splice(pipe, fd). There is no
> > flush of any sort in between.
> >>
> >> When you say drain you mean to flush all data to pipe?
> >>
> >
> > Draining pipe before splice() call would only trigger the bug less
> > often.
>
> If we don't drain the pipe before calling splice(2), the data spliced
> from pipe maybe not be what we expect. Then data corruption occurs.
>
This is not true. A pipe is a pipe is a buffer. You dont need it to be
empty when using it. Nowhere in documentation its stated.
However, a single skb can fill a pipe, even if "its empty"
> >
> > splice(sock, pipe) can block if caller dont use appropriate "non
> > blocking pipe' splice() mode, even if pipe is empty before a splice()
> > call.
>
> I don't think it is expected. The code of sys_recvfile is much like
> the sendfile(2) implementation in kernel. If sys_recvfile may block
> without non_block flag, sendfile(2) may block too.
Then it would be a bug. You might fix it easily.
Using splice() correctly (ie, not blocking on sock->pipe) should work
too.
Again, you can block on splice(sock, pipe), iff you have a second thread
doing the opposite (pipe->file) in parallel to unblock you. But samba
recvfile algo is using a single thread.
>
> BTW: Samba can use sendfile(2) instead in sys_recvfile.
>
^ permalink raw reply
* Re: setsockopt(IP_TOS) being privileged or distinct capability?
From: David Miller @ 2010-07-06 3:13 UTC (permalink / raw)
To: philipp_subx; +Cc: hagen, alex, netdev
In-Reply-To: <4C329E15.2000601@redfish-solutions.com>
From: Philip Prindeville <philipp_subx@redfish-solutions.com>
Date: Mon, 05 Jul 2010 21:08:05 -0600
> Yes, most users have admin/privileged rights on their machines, but
> don't know enough to exploit that.
Even "stupid" users are a very slim, marginal, step away from making
use of it once they get shown with a HOWTO on some web site what is
possible with this if QoS is being abided by on their network.
Look, this discussion seems completely pointless. The behavior is
never changing, setting the TOS will always be non-privileged.
We cannot change the current behavior no matter what political or
other motivation we might have for doing so. It's been non-privileged
for more than 15 years, and we'd knowingly break applications with the
change.
And I don't even agree with the arguments being proposed for doing
this. Users can control their packets however they wish. The only
thing the ISP can do to prevent toying with the TOS bits is putting
logic into your little black box that hooks up to your cable/dsl line.
So this TOS being privileged proposal it's a "no go" from any angle as
far as I'm concerned.
^ permalink raw reply
* Re: [PATCH net-2.6] net: Fix definition of netif_vdbg() when VERBOSE_DEBUG is defined
From: David Miller @ 2010-07-06 3:08 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers, joe
In-Reply-To: <1278090524.2095.41.camel@achroite.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Fri, 02 Jul 2010 18:08:44 +0100
> netif_vdbg() was originally defined as entirely equivalent to
> netdev_vdbg(), but I assume that it was intended to take the same
> parameters as netif_dbg() etc. (Currently it is only used by the
> sfc driver, in which I worked on that assumption.)
>
> In commit a4ed89c I changed the definition used when VERBOSE_DEBUG is
> not defined, but I failed to notice that the definition used when
> VERBOSE_DEBUG is defined was also not as I expected. Change that to
> match netif_dbg() as well.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied to net-2.6, thanks.
^ permalink raw reply
* Re: setsockopt(IP_TOS) being privileged or distinct capability?
From: Philip Prindeville @ 2010-07-06 3:08 UTC (permalink / raw)
To: Hagen Paul Pfeifer; +Cc: Alexander Clouter, netdev
In-Reply-To: <20100706020734.GA2972@nuttenaction>
On 7/5/10 8:07 PM, Hagen Paul Pfeifer wrote:
> * Philip Prindeville | 2010-07-05 12:04:31 [-0600]:
>
>
>> I understand that. That's part of the reason that I've submitted
>> patches for APR, Apache, Thunderbird, Firefox, Proftpd, Curl, wget,
>> etc. There is pressure within certain technical groups to get ISP's
>> to voluntarily implement RFC-4594... that's the carrot. The stick
>> being FCC heavy-handed regulation of the ISP's if they don't.
>>
> Where is the _real_ advantage if setsockopt(IP_TOS) where a privileged
> operation? At the end the user/service is still required to set his service
> class, but this time with CAP_NET_ADMIN. Do you think that Service
> Providers/Transit Providers trust (and this is the critical aspect) customers
> based on some IP flags - this is extreme unlikely. 99% of users have
> effective CAP_NET_ADMIN capabilities - and you cannot stop using them.
>
QoS is expensive to implement, since it requires a lot more inspection
of the packet, multiple queues, bandwidth reservation, etc.
ISP's are going to look for an excuse not to implement it.
Having it be exploited by users is another arrow in their quill to not
implement it.
Yes, most users have admin/privileged rights on their machines, but
don't know enough to exploit that.
Whatever makes it harder to abusively exploit QoS seems like a good
idea. Harder. Not impossible.
"Stopping them" was never the objective.
> Service Providers/Transit Providers will trust customers who pays more and
> then they will accept their DIFFSERV suggestion signaled via IP DSCP. All
> other customers will be treated normal, with zeroed DSCP. It makes no sense
> for ISP's to shift the trust aspect to the customer side.
>
> HGN
>
>
>
Alas there's more to it than that: the movement is to make QoS be
ubiquitous for all SLA's of broadband.
I'd argue that it makes no sense for them not to trust it: SDP/RTP
packets are hard to identify as such without peaking into the
accompanying SIP conversation... which drives up the cost of their
required infrastructure to handle QoS even more.
Besides, if I deploy a new protocol that uses RTP or leverages QoS, I'd
have to wait for the ISP to update their network with knowledge of that
protocol in order to handle it properly... given the glacial pace that
at which ISP's certify and deploy software updates, configuration
changes, etc. I don't want to have to wait months or years for them to
play catch-up.
What's more, if I'm running SIP over TLS over TCP, they can't peek into
the stream anyway to figure out what UDP ports I'm using for SDP.
So I can sacrifice control, privacy, or timeliness... or they can simply
trust my QoS markings.
But what's the downside of their trusting my markings, anyway?
Let's say that I have 7mb/s DSL, and with that standard base profile
comes 240kb/s EF policing, 512kb/s AF4x, etc. Further let's suppose
that I exceed my SLA: they could either downgrade the excess to the next
lowest bin, or discard it... Hence I'm highly incentivized to remain
within my agreed SLA envelope.
^ permalink raw reply
* Re: [PATCH] net/ne: fix memory leak in ne_drv_probe()
From: David Miller @ 2010-07-06 3:08 UTC (permalink / raw)
To: segooon; +Cc: kernel-janitors, joe, anemo, netdev, linux-kernel
In-Reply-To: <1278170444-8170-1-git-send-email-segooon@gmail.com>
From: Kulikov Vasiliy <segooon@gmail.com>
Date: Sat, 3 Jul 2010 19:20:42 +0400
> net_device allocated with alloc_eip_netdev() must be freed.
>
> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: bridge br_multicast: BUG: unable to handle kernel NULL pointer dereference
From: David Miller @ 2010-07-06 3:07 UTC (permalink / raw)
To: herbert; +Cc: frank.arnold, shemminger, yoshfuji, netdev
In-Reply-To: <20100706005008.GA11699@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 6 Jul 2010 08:50:08 +0800
> On Tue, Jul 06, 2010 at 08:48:35AM +0800, Herbert Xu wrote:
>>
>> bridge: Restore NULL check in br_mdb_ip_get
>
> Resend with proper attribution.
>
> bridge: Restore NULL check in br_mdb_ip_get
>
> Somewhere along the line the NULL check in br_mdb_ip_get went
> AWOL, causing crashes when we receive an IGMP packet with no
> multicast table allocated.
It got removed by:
--------------------
commit 8ef2a9a59854994bace13b5c4f7edc2c8d4d124e
Author: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Sun Apr 18 12:42:07 2010 +0900
bridge br_multicast: Make functions less ipv4 dependent.
Introduce struct br_ip{} to store ip address and protocol
and make functions more generic so that we can support
both IPv4 and IPv6 with less pain.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
--------------------
> This patch restores it and ensures all br_mdb_*_get functions
> use it.
>
> Reported-by: Frank Arnold <frank.arnold@amd.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks.
^ permalink raw reply
* RE: Splice status
From: Ofer Heifetz @ 2010-07-06 2:36 UTC (permalink / raw)
To: Changli Gao, Eric Dumazet; +Cc: Jens Axboe, netdev@vger.kernel.org
In-Reply-To: <AANLkTim_eBmT-6HmkqG5d7k0jjrGKAFBjzqVCricTpgK@mail.gmail.com>
Regarding your remark of replacing sendfile with recvfile, I have two questions:
1) what will be used if both are enabled in smb.conf
2) from your experience, which is faster for reading files?
________________________________________
From: Changli Gao [xiaosuo@gmail.com]
Sent: Tuesday, July 06, 2010 5:01 AM
To: Eric Dumazet
Cc: Jens Axboe; Ofer Heifetz; netdev@vger.kernel.org
Subject: Re: Splice status
On Mon, Jul 5, 2010 at 8:50 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le lundi 05 juillet 2010 à 13:52 +0300, Ofer Heifetz a écrit :
>> I am using Samba, so from my understanding of the source code, it
> loops and performs splice(sock, pipe) and splice(pipe, fd). There is no
> flush of any sort in between.
>>
>> When you say drain you mean to flush all data to pipe?
>>
>
> Draining pipe before splice() call would only trigger the bug less
> often.
If we don't drain the pipe before calling splice(2), the data spliced
from pipe maybe not be what we expect. Then data corruption occurs.
>
> splice(sock, pipe) can block if caller dont use appropriate "non
> blocking pipe' splice() mode, even if pipe is empty before a splice()
> call.
I don't think it is expected. The code of sys_recvfile is much like
the sendfile(2) implementation in kernel. If sys_recvfile may block
without non_block flag, sendfile(2) may block too.
BTW: Samba can use sendfile(2) instead in sys_recvfile.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH 1/4] net: add driver hooks for time stamping.
From: David Miller @ 2010-07-06 2:39 UTC (permalink / raw)
To: richardcochran; +Cc: netdev
In-Reply-To: <20100705.190301.48512969.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Mon, 05 Jul 2010 19:03:01 -0700 (PDT)
> From: Richard Cochran <richardcochran@gmail.com>
> Date: Mon, 5 Jul 2010 07:31:07 +0200
>
>> This patch adds hooks for transmit and receive time stamps. The
>> transmit hook allows a software fallback for transmit time stamps,
>> for MACs lacking time stamping hardware. The receive hook does not yet
>> have any effect, but it prepares the way for hardware time stamping
>> in PHY devices. Using the hooks will still require adding two inline
>> function calls to each MAC driver.
>>
>> Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
>
> Applied.
Actually, this breaks the build.
There are drivers that never saw phylib.h included in them,
which use internal static functions named "phy_read()" and such
which match global interfaces defined in phylib.h
drivers/net/tulip/dmfe.c:334:12: error: conflicting types for 'phy_read'
include/linux/phy.h:437:19: note: previous definition of 'phy_read' was here
drivers/net/tulip/dmfe.c:335:13: error: conflicting types for 'phy_write'
include/linux/phy.h:452:19: note: previous definition of 'phy_write' was here
You're going to need to resolve this issue first, then make sure at a
minimum that an "allmodconfig" build fully passes with an
unconditional include of phylib.h in skbuff.h
I've reverted all of your patches.
^ permalink raw reply
* Re: [PATCH 1/2] Documentation/isdn: CAPI controller interface amendment
From: David Miller @ 2010-07-06 2:24 UTC (permalink / raw)
To: tilman; +Cc: isdn, hjlipp, keil, i4ldeveloper, netdev, linux-kernel
In-Reply-To: <20100705-patch-isdn-01.tilman@imap.cc>
From: Tilman Schmidt <tilman@imap.cc>
Date: Tue, 6 Jul 2010 02:18:22 +0200 (CEST)
> Mention that the CAPI controller methods load_firmware() and
> reset_ctr() are asynchronous, and should signal completion.
>
> Impact: documentation
> Signed-off-by: Tilman Schmidt <tilman@imap.cc>
Applied to net-next-2.6
Please stop using "Impact: " tags, I just edit them out when
I add your changes.
^ permalink raw reply
* Re: [PATCH 2/2] isdn: avoid calling tty_ldisc_flush() in atomic context
From: David Miller @ 2010-07-06 2:24 UTC (permalink / raw)
To: tilman; +Cc: isdn, hjlipp, keil, i4ldeveloper, netdev, linux-kernel, stable
In-Reply-To: <20100705-patch-isdn-02.tilman@imap.cc>
From: Tilman Schmidt <tilman@imap.cc>
Date: Tue, 6 Jul 2010 02:18:27 +0200 (CEST)
> Remove the call to tty_ldisc_flush() from the RESULT_NO_CARRIER
> branch of isdn_tty_modem_result(), as already proposed in commit
> 00409bb045887ec5e7b9e351bc080c38ab6bfd33.
> This avoids a "sleeping function called from invalid context" BUG
> when the hardware driver calls the statcallb() callback with
> command==ISDN_STAT_DHUP in atomic context, which in turn calls
> isdn_tty_modem_result(RESULT_NO_CARRIER, ~), and from there,
> tty_ldisc_flush() which may sleep.
>
> Impact: bugfix
> Signed-off-by: Tilman Schmidt <tilman@imap.cc>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH 05/11] isdn/gigaset: improve CAPI message debugging
From: David Miller @ 2010-07-06 2:23 UTC (permalink / raw)
To: tilman; +Cc: isdn, hjlipp, keil, i4ldeveloper, netdev, linux-kernel
In-Reply-To: <20100705-patch-gigaset-05.tilman@imap.cc>
From: Tilman Schmidt <tilman@imap.cc>
Date: Tue, 6 Jul 2010 02:18:59 +0200 (CEST)
> @@ -384,7 +388,7 @@ void gigaset_skb_sent(struct bc_state *bcs, struct sk_buff *dskb)
>
> /* don't send further B3 messages if disconnected */
> if (bcs->apconnstate < APCONN_ACTIVE) {
> - gig_dbg(DEBUG_LLDATA, "disconnected, discarding ack");
> + gig_dbg(DEBUG_MCMD, "disconnected, discarding ack");
> return;
> }
This is against something other than net-next-2.6 even with your
other two ISDN patches applied, because all of these lines read
"if (ap->connected ..."
Please tell me what exactly these patches are against so that I
can apply them to net-next-2.6 cleanly.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] ixgbe: use netif_<level> instead of netdev_<level>
From: David Miller @ 2010-07-06 2:09 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, joe, emil.s.tantilov
In-Reply-To: <20100702060508.17100.39352.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 01 Jul 2010 23:05:12 -0700
> From: Emil Tantilov <emil.s.tantilov@intel.com>
>
> This patch restores the ability to set msglvl through ethtool.
> The issue was introduced by:
> commit 849c45423c0c108e08d67644728cc9b0ed225fa1
>
> CC: Joe Perches <joe@perches.com>
>
> Reported-by: Joe Perches <joe@perches.com>
> Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] igb: drop support for UDP hashing w/ RSS
From: David Miller @ 2010-07-06 2:08 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, alexander.h.duyck
In-Reply-To: <20100702060056.16863.23072.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 01 Jul 2010 23:01:05 -0700
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This change removes UDP from the supported protocols for RSS hashing. The
> reason for removing this protocol is because IP fragmentation was causing a
> network flow to be broken into two streams, one for fragmented, and one for
> non-fragmented and this in turn was causing out-of-order issues.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipv4: use skb_dst_copy() in ip_copy_metadata()
From: David Miller @ 2010-07-06 2:08 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1278064102.2530.29.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 02 Jul 2010 11:48:22 +0200
> Avoid touching dst refcount in ip_fragment().
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ 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