* Re: [net-next.git] stmmac: remove useless csum flag
From: David Miller @ 2013-08-22 3:38 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev, sonic.zhang
In-Reply-To: <1377069074-4488-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Wed, 21 Aug 2013 09:11:14 +0200
> This patch removes the no_csum_insertion private parameter that is not used anymore
> and, also, the "likely" annotation from the condition that is not in a critical path.
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Cc: Sonic Zhang <sonic.zhang@analog.com>
Applied, thanks.
^ permalink raw reply
* Re: [RFC PATCH] bridge: inherit slave devices needed_headroom
From: David Miller @ 2013-08-22 3:41 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, stephen, eric.dumazet, vyasevic
In-Reply-To: <1376990505-15708-1-git-send-email-f.fainelli@gmail.com>
From: "Florian Fainelli" <f.fainelli@gmail.com>
Date: Tue, 20 Aug 2013 10:21:45 +0100
> Some slave devices may have set a dev->needed_headroom value which is
> different than the default one, most likely in order to prepend a
> hardware descriptor in front of the Ethernet frame to send. Whenever a
> new slave is added to a bridge, ensure that we update the
> needed_headroom value accordingly to account for the slave
> needed_headroom value.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
This looks fine to me, but I'd like to see either Eric, Stephen, or
Vlad review this before I apply it.
^ permalink raw reply
* Re: [PATCH V3] ipv6: handle Redirect ICMP Message with no Redirected Header option
From: David Miller @ 2013-08-22 3:44 UTC (permalink / raw)
To: duanj.fnst; +Cc: hannes, netdev
In-Reply-To: <521468C4.5020700@cn.fujitsu.com>
From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Date: Wed, 21 Aug 2013 15:14:12 +0800
> +void ip6_redirect_no_header(struct sk_buff *skb, struct net *net, int oif,
> + u32 mark)
...
> +EXPORT_SYMBOL_GPL(ip6_redirect_no_header);
I don't think you need to export this to modules, this is in route.c and
the only user is in ndisc.c, both of which are linked together.
Please resubmit this with the symbol export removed, thanks.
^ permalink raw reply
* Re: pull-request: can-next 2013-08-21
From: David Miller @ 2013-08-22 3:47 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can, kernel
In-Reply-To: <52146F7F.6010001@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Wed, 21 Aug 2013 09:42:55 +0200
> this pull-request for net-next consists of a series by Alexander
> Shiyan, he cleans up the mcp251x driver. As the first patch touches
> arch/arm/mach-pxa, it's acked by Haojian Zhuang.
Pulled, thanks Marc.
^ permalink raw reply
* Re: [PATCH 1/2] hso: Earlier catch of error condition
From: David Miller @ 2013-08-22 3:48 UTC (permalink / raw)
To: gregkh; +Cc: daniel, j.dumon, linux-usb, netdev, linux-kernel
In-Reply-To: <20130821162507.GD14364@kroah.com>
From: Greg KH <gregkh@linuxfoundation.org>
Date: Wed, 21 Aug 2013 09:25:07 -0700
> On Wed, Aug 21, 2013 at 01:43:07AM -0700, Daniel Gimpelevich wrote:
>> There is no need to get an interface specification if we know it's the
>> wrong one.
>>
>> Signed-off-by: Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>
>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] hso: Fix stack corruption on some architectures
From: David Miller @ 2013-08-22 3:48 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
Cc: daniel-R/FLGEdV95bo9U+Z1CfBt0SU0eOFXohjCypLqA8HKkk,
j.dumon-x9gZzRpC1QbQT0dZR+AlfA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20130821162447.GC14364-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
From: Greg KH <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
Date: Wed, 21 Aug 2013 09:24:47 -0700
> On Wed, Aug 21, 2013 at 01:43:19AM -0700, Daniel Gimpelevich wrote:
>> As Sergei Shtylyov explained in the #mipslinux IRC channel:
>> [Mon 2013-08-19 12:28:21 PM PDT] <headless> guys, are you sure it's not "DMA off stack" case?
>> [Mon 2013-08-19 12:28:35 PM PDT] <headless> it's a known stack corruptor on non-coherent arches
>> [Mon 2013-08-19 12:31:48 PM PDT] <DonkeyHotei> headless: for usb/ehci?
>> [Mon 2013-08-19 12:34:11 PM PDT] <DonkeyHotei> headless: explain
>> [Mon 2013-08-19 12:35:38 PM PDT] <headless> usb_control_msg() (or other such func) should not use buffer on stack. DMA from/to stack is prohibited
>> [Mon 2013-08-19 12:35:58 PM PDT] <headless> and EHCI uses DMA on control xfers (as well as all the others)
>>
>> Signed-off-by: Daniel Gimpelevich <daniel-R/FLGEdV95bo9U+Z1CfBt0SU0eOFXohjCypLqA8HKkk@public.gmane.org>
>
> Acked-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
Applied.
--
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] net: irda: pxaficp_ir: use platform_set_drvdata()
From: David Miller @ 2013-08-22 3:51 UTC (permalink / raw)
To: libo.chen; +Cc: samuel, netdev, linux-kernel, lizefan
In-Reply-To: <1377080111-11348-1-git-send-email-libo.chen@huawei.com>
From: Libo Chen <libo.chen@huawei.com>
Date: Wed, 21 Aug 2013 18:15:11 +0800
> Use the wrapper functions for getting and setting the driver data using
> platform_device instead of using deva_set_drvdata() with &pdev->dev,
> so we can directly pass a struct platform_device.
>
> Signed-off-by: Libo Chen <libo.chen@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: phy: mdio-octeon: use platform_set_drvdata()
From: David Miller @ 2013-08-22 3:51 UTC (permalink / raw)
To: libo.chen
Cc: grant.likely, rob.herring, david.daney, wfp5p, gregkh,
sachin.kamat, netdev, linux-kernel, lizefan
In-Reply-To: <1377080115-58636-1-git-send-email-libo.chen@huawei.com>
From: Libo Chen <libo.chen@huawei.com>
Date: Wed, 21 Aug 2013 18:15:15 +0800
> Use the wrapper functions for getting and setting the driver data using
> platform_device instead of using dev_set_drvdata() with &pdev->dev,
> so we can directly pass a struct platform_device.
>
> Signed-off-by: Libo Chen <libo.chen@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] tcp: increase throughput when reordering is high
From: Eric Dumazet @ 2013-08-22 3:52 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: davem, ncardwell, edumazet, netdev
In-Reply-To: <1377131363-31341-1-git-send-email-ycheng@google.com>
On Wed, 2013-08-21 at 17:29 -0700, Yuchung Cheng wrote:
> The stack currently detects reordering and avoid spurious
> retransmission very well. However the throughput is sub-optimal under
> high reordering because cwnd is increased only if the data is deliverd
> in order. I.e., FLAG_DATA_ACKED check in tcp_ack(). The more packet
> are reordered the worse the throughput is.
>
> Therefore when reordering is proven high, cwnd should advance whenever
> the data is delivered regardless of its ordering. If reordering is low,
> conservatively advance cwnd only on ordered deliveries in Open state,
> and retain cwnd in Disordered state (RFC5681).
>
> Using netperf on a qdisc setup of 20Mbps BW and random RTT from 45ms
> to 55ms (for reordering effect). This change increases TCP throughput
> by 20 - 25% to near bottleneck BW.
>
> A special case is the stretched ACK with new SACK and/or ECE mark.
> For example, a receiver may receive an out of order or ECN packet with
> unacked data buffered because of LRO or delayed ACK. The principle on
> such an ACK is to advance cwnd on the cummulative acked part first,
> then reduce cwnd in tcp_fastretrans_alert().
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> ---
> net/ipv4/tcp_input.c | 32 ++++++++++++++++++++------------
> 1 file changed, 20 insertions(+), 12 deletions(-)
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* [PATCH 1/2] genl: Fix genl dumpit() locking.
From: Pravin B Shelar @ 2013-08-22 3:58 UTC (permalink / raw)
To: netdev; +Cc: Pravin B Shelar, Jesse Gross, Johannes Berg
In case of genl-family with parallel ops off, dumpif() callback
is expected to run under genl_lock, But commit def3117493eafd9df
(genl: Allow concurrent genl callbacks.) changed this behaviour
where only first dumpit() op was called under genl-lock.
For subsequent dump, only nlk->cb_lock was taken.
Following patch fixes it by defining locked dumpit() and done()
callback which takes care of genl-locking.
CC: Jesse Gross <jesse@nicira.com>
CC: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
---
net/netlink/genetlink.c | 46 +++++++++++++++++++++++++++++++++++++++++-----
1 files changed, 41 insertions(+), 5 deletions(-)
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index f85f8a2..3669039 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -544,6 +544,28 @@ void *genlmsg_put(struct sk_buff *skb, u32 portid, u32 seq,
}
EXPORT_SYMBOL(genlmsg_put);
+static int genl_lock_dumpit(struct sk_buff *skb, struct netlink_callback *cb)
+{
+ struct genl_ops *ops = cb->data;
+ int rc;
+
+ genl_lock();
+ rc = ops->dumpit(skb, cb);
+ genl_unlock();
+ return rc;
+}
+
+static int genl_lock_done(struct netlink_callback *cb)
+{
+ struct genl_ops *ops = cb->data;
+ int rc;
+
+ genl_lock();
+ rc = ops->done(cb);
+ genl_unlock();
+ return rc;
+}
+
static int genl_family_rcv_msg(struct genl_family *family,
struct sk_buff *skb,
struct nlmsghdr *nlh)
@@ -572,15 +594,29 @@ static int genl_family_rcv_msg(struct genl_family *family,
return -EPERM;
if ((nlh->nlmsg_flags & NLM_F_DUMP) == NLM_F_DUMP) {
- struct netlink_dump_control c = {
- .dump = ops->dumpit,
- .done = ops->done,
- };
+ struct netlink_dump_control c;
+ int rc;
if (ops->dumpit == NULL)
return -EOPNOTSUPP;
- return netlink_dump_start(net->genl_sock, skb, nlh, &c);
+ memset(&c, 0, sizeof(c));
+ if (!family->parallel_ops) {
+ genl_unlock();
+ c.data = ops;
+ c.dump = genl_lock_dumpit;
+ if (ops->done)
+ c.done = genl_lock_done;
+ } else {
+ c.dump = ops->dumpit;
+ c.done = ops->done;
+ }
+
+ rc = netlink_dump_start(net->genl_sock, skb, nlh, &c);
+ if (!family->parallel_ops)
+ genl_lock();
+ return rc;
+
}
if (ops->doit == NULL)
--
1.7.1
^ permalink raw reply related
* [PATCH 2/2] genl: Hold reference on correct module while netlink-dump.
From: Pravin B Shelar @ 2013-08-22 3:58 UTC (permalink / raw)
To: netdev; +Cc: Pravin B Shelar, Jesse Gross, Johannes Berg
netlink dump operations take module as parameter to hold
reference for entire netlink dump duration.
Currently it holds ref only on genl module which is not correct
when we use ops registered to genl from another module.
Following patch adds module pointer to genl_ops so that netlink
can hold ref count on it.
CC: Jesse Gross <jesse@nicira.com>
CC: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
---
include/net/genetlink.h | 21 ++++++++++++++++++---
net/netlink/genetlink.c | 39 ++++++++++++++++++++++++---------------
2 files changed, 42 insertions(+), 18 deletions(-)
diff --git a/include/net/genetlink.h b/include/net/genetlink.h
index 93024a4..7f57b2c 100644
--- a/include/net/genetlink.h
+++ b/include/net/genetlink.h
@@ -119,13 +119,28 @@ struct genl_ops {
struct netlink_callback *cb);
int (*done)(struct netlink_callback *cb);
struct list_head ops_list;
+ struct module *module;
};
extern int genl_register_family(struct genl_family *family);
-extern int genl_register_family_with_ops(struct genl_family *family,
- struct genl_ops *ops, size_t n_ops);
+
+extern int __genl_register_family_with_ops(struct genl_family *family,
+ struct genl_ops *ops, size_t n_ops, struct module *module);
+
+static inline int genl_register_family_with_ops(struct genl_family *family,
+ struct genl_ops *ops, size_t n_ops)
+{
+ return __genl_register_family_with_ops(family, ops, n_ops, THIS_MODULE);
+}
+
extern int genl_unregister_family(struct genl_family *family);
-extern int genl_register_ops(struct genl_family *, struct genl_ops *ops);
+extern int __genl_register_ops(struct genl_family *f, struct genl_ops *ops,
+ struct module *module);
+static inline int genl_register_ops(struct genl_family *f, struct genl_ops *ops)
+{
+ return __genl_register_ops(f, ops, THIS_MODULE);
+}
+
extern int genl_unregister_ops(struct genl_family *, struct genl_ops *ops);
extern int genl_register_mc_group(struct genl_family *family,
struct genl_multicast_group *grp);
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index 3669039..23430c7 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -284,7 +284,7 @@ static void genl_unregister_mc_groups(struct genl_family *family)
}
/**
- * genl_register_ops - register generic netlink operations
+ * __genl_register_ops - register generic netlink operations
* @family: generic netlink family
* @ops: operations to be registered
*
@@ -298,7 +298,8 @@ static void genl_unregister_mc_groups(struct genl_family *family)
*
* Returns 0 on success or a negative error code.
*/
-int genl_register_ops(struct genl_family *family, struct genl_ops *ops)
+int __genl_register_ops(struct genl_family *family, struct genl_ops *ops,
+ struct module *module)
{
int err = -EINVAL;
@@ -317,6 +318,7 @@ int genl_register_ops(struct genl_family *family, struct genl_ops *ops)
if (ops->policy)
ops->flags |= GENL_CMD_CAP_HASPOL;
+ ops->module = module;
genl_lock_all();
list_add_tail(&ops->ops_list, &family->ops_list);
genl_unlock_all();
@@ -326,7 +328,7 @@ int genl_register_ops(struct genl_family *family, struct genl_ops *ops)
errout:
return err;
}
-EXPORT_SYMBOL(genl_register_ops);
+EXPORT_SYMBOL(__genl_register_ops);
/**
* genl_unregister_ops - unregister generic netlink operations
@@ -433,7 +435,7 @@ errout:
EXPORT_SYMBOL(genl_register_family);
/**
- * genl_register_family_with_ops - register a generic netlink family
+ * __genl_register_family_with_ops - register a generic netlink family
* @family: generic netlink family
* @ops: operations to be registered
* @n_ops: number of elements to register
@@ -457,8 +459,8 @@ EXPORT_SYMBOL(genl_register_family);
*
* Return 0 on success or a negative error code.
*/
-int genl_register_family_with_ops(struct genl_family *family,
- struct genl_ops *ops, size_t n_ops)
+int __genl_register_family_with_ops(struct genl_family *family,
+ struct genl_ops *ops, size_t n_ops, struct module *module)
{
int err, i;
@@ -467,7 +469,7 @@ int genl_register_family_with_ops(struct genl_family *family,
return err;
for (i = 0; i < n_ops; ++i, ++ops) {
- err = genl_register_ops(family, ops);
+ err = __genl_register_ops(family, ops, module);
if (err)
goto err_out;
}
@@ -476,7 +478,7 @@ err_out:
genl_unregister_family(family);
return err;
}
-EXPORT_SYMBOL(genl_register_family_with_ops);
+EXPORT_SYMBOL(__genl_register_family_with_ops);
/**
* genl_unregister_family - unregister generic netlink family
@@ -558,11 +560,14 @@ static int genl_lock_dumpit(struct sk_buff *skb, struct netlink_callback *cb)
static int genl_lock_done(struct netlink_callback *cb)
{
struct genl_ops *ops = cb->data;
- int rc;
+ int rc = 0;
- genl_lock();
- rc = ops->done(cb);
- genl_unlock();
+ if (ops->done) {
+ genl_lock();
+ rc = ops->done(cb);
+ genl_unlock();
+ }
+ module_put(ops->module);
return rc;
}
@@ -605,14 +610,18 @@ static int genl_family_rcv_msg(struct genl_family *family,
genl_unlock();
c.data = ops;
c.dump = genl_lock_dumpit;
- if (ops->done)
- c.done = genl_lock_done;
+ c.done = genl_lock_done;
+ c.module = THIS_MODULE;
+
+ if (!try_module_get(ops->module))
+ return -EPROTONOSUPPORT;
} else {
c.dump = ops->dumpit;
c.done = ops->done;
+ c.module = ops->module;
}
- rc = netlink_dump_start(net->genl_sock, skb, nlh, &c);
+ rc = __netlink_dump_start(net->genl_sock, skb, nlh, &c);
if (!family->parallel_ops)
genl_lock();
return rc;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net] skge: dma_sync the whole receive buffer
From: Greg KH @ 2013-08-22 4:00 UTC (permalink / raw)
To: poma; +Cc: Stephen Hemminger, David Miller, netdev, Linus Torvalds
In-Reply-To: <521585C9.3040809@gmail.com>
On Thu, Aug 22, 2013 at 05:30:17AM +0200, poma wrote:
> On 22.08.2013 02:40, Greg KH wrote:
> > On Wed, Aug 21, 2013 at 06:04:11PM +0200, poma wrote:
> >> Signor Greg you are supposed to be very resourceful guy, especially in
> >> matters concerning the hardware, so please if you can set aside your
> >> valuable time and help us finally resolve this issue.
> >
> > Please take it up with Stephen, it's his driver, not mine.
> >
> > greg k-h
> >
>
> I guess I wrongly assumed that developers help each other when they get
> stuck. Isn't it obvious that Steph and Dave already decided to ship the
> broken module in da birthday kernel.
No, it's not obvious at all. If it's broken for you, please work with
them, not against them by trying to go around their back to someone
else. I have nothing to do with networking drivers, that's Stephen and
David's area of the kernel, so there's nothing I can even do here,
sorry.
greg k-h
^ permalink raw reply
* [PATCH V4] ipv6: handle Redirect ICMP Message with no Redirected Header option
From: Duan Jiong @ 2013-08-22 4:07 UTC (permalink / raw)
To: davem; +Cc: duanj.fnst, hannes, netdev
From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
rfc 4861 says the Redirected Header option is optional, so
the kernel should not drop the Redirect Message that has no
Redirected Header option. In this patch, the function
ip6_redirect_no_header() is introduced to deal with that
condition.
Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
---
Changes for v4:
1. Remove symbol export
include/net/ip6_route.h | 2 ++
net/ipv6/ndisc.c | 4 +++-
net/ipv6/route.c | 21 +++++++++++++++++++++
3 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
index 260f83f..f667248 100644
--- a/include/net/ip6_route.h
+++ b/include/net/ip6_route.h
@@ -135,6 +135,8 @@ extern void ip6_update_pmtu(struct sk_buff *skb, struct net *net, __be32 mtu,
extern void ip6_sk_update_pmtu(struct sk_buff *skb, struct sock *sk,
__be32 mtu);
extern void ip6_redirect(struct sk_buff *skb, struct net *net, int oif, u32 mark);
+extern void ip6_redirect_no_header(struct sk_buff *skb, struct net *net, int oif,
+ u32 mark);
extern void ip6_sk_redirect(struct sk_buff *skb, struct sock *sk);
struct netlink_callback;
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 79aa965..04d31c2 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1369,8 +1369,10 @@ static void ndisc_redirect_rcv(struct sk_buff *skb)
if (!ndisc_parse_options(msg->opt, ndoptlen, &ndopts))
return;
- if (!ndopts.nd_opts_rh)
+ if (!ndopts.nd_opts_rh) {
+ ip6_redirect_no_header(skb, dev_net(skb->dev), 0, 0);
return;
+ }
hdr = (u8 *)ndopts.nd_opts_rh;
hdr += 8;
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index b70f897..8d9a93e 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1178,6 +1178,27 @@ void ip6_redirect(struct sk_buff *skb, struct net *net, int oif, u32 mark)
}
EXPORT_SYMBOL_GPL(ip6_redirect);
+void ip6_redirect_no_header(struct sk_buff *skb, struct net *net, int oif,
+ u32 mark)
+{
+ const struct ipv6hdr *iph = ipv6_hdr(skb);
+ const struct rd_msg *msg = (struct rd_msg *)icmp6_hdr(skb);
+ struct dst_entry *dst;
+ struct flowi6 fl6;
+
+ memset(&fl6, 0, sizeof(fl6));
+ fl6.flowi6_oif = oif;
+ fl6.flowi6_mark = mark;
+ fl6.flowi6_flags = 0;
+ fl6.daddr = msg->dest;
+ fl6.saddr = iph->daddr;
+
+ dst = ip6_route_output(net, NULL, &fl6);
+ if (!dst->error)
+ rt6_do_redirect(dst, NULL, skb);
+ dst_release(dst);
+}
+
void ip6_sk_redirect(struct sk_buff *skb, struct sock *sk)
{
ip6_redirect(skb, sock_net(sk), sk->sk_bound_dev_if, sk->sk_mark);
--
1.7.3.1
^ permalink raw reply related
* Re: [PATCH net] skge: dma_sync the whole receive buffer
From: Stephen Hemminger @ 2013-08-22 4:08 UTC (permalink / raw)
To: poma; +Cc: Greg KH, David Miller, netdev, Linus Torvalds
In-Reply-To: <521585C9.3040809@gmail.com>
On Thu, 22 Aug 2013 05:30:17 +0200
poma <pomidorabelisima@gmail.com> wrote:
> On 22.08.2013 02:40, Greg KH wrote:
> > On Wed, Aug 21, 2013 at 06:04:11PM +0200, poma wrote:
> >> Signor Greg you are supposed to be very resourceful guy, especially in
> >> matters concerning the hardware, so please if you can set aside your
> >> valuable time and help us finally resolve this issue.
> >
> > Please take it up with Stephen, it's his driver, not mine.
> >
> > greg k-h
> >
>
> I guess I wrongly assumed that developers help each other when they get
> stuck. Isn't it obvious that Steph and Dave already decided to ship the
> broken module in da birthday kernel. What can I do in the first place,
> as a simple user. That's why I asked you to help.
> However thank you for the answer.
>
>
> poma
>
>
If you have the patience and time, it would be useful to bisect the problem.
It may not just be in skge.c but a side effect of other config changes.
^ permalink raw reply
* [PATCH net] ipv4: expose IPV4_DEVCONF
From: Stephen Hemminger @ 2013-08-22 4:09 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Eric W. Biederman, Thomas Graf
IP sends device configuration (see inet_fill_link_af) as an array
in the netlink information, but the indices in that array are not
exposed to userspace through any current santized header file.
It was available back in 2.6.32 (in /usr/include/linux/sysctl.h)
but was broken by:
commit 02291680ffba92e5b5865bc0c5e7d1f3056b80ec
Author: Eric W. Biederman <ebiederm@xmission.com>
Date: Sun Feb 14 03:25:51 2010 +0000
net ipv4: Decouple ipv4 interface parameters from binary sysctl numbers
Eric was solving the sysctl problem but then the indices were re-exposed
by a later addition of devconf support for IPV4
commit 9f0f7272ac9506f4c8c05cc597b7e376b0b9f3e4
Author: Thomas Graf <tgraf@infradead.org>
Date: Tue Nov 16 04:32:48 2010 +0000
ipv4: AF_INET link address family
Putting them in /usr/include/linux/ip.h seemed the logical match
for the DEVCONF_ definitions for IPV6 in /usr/include/linux/ip6.h
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
include/linux/inetdevice.h | 34 +---------------------------------
include/uapi/linux/ip.h | 34 ++++++++++++++++++++++++++++++++++
2 files changed, 35 insertions(+), 33 deletions(-)
--- a/include/linux/inetdevice.h 2013-07-13 10:20:25.563762299 -0700
+++ b/include/linux/inetdevice.h 2013-08-21 18:42:43.201856345 -0700
@@ -5,45 +5,13 @@
#include <linux/bitmap.h>
#include <linux/if.h>
+#include <linux/ip.h>
#include <linux/netdevice.h>
#include <linux/rcupdate.h>
#include <linux/timer.h>
#include <linux/sysctl.h>
#include <linux/rtnetlink.h>
-enum
-{
- IPV4_DEVCONF_FORWARDING=1,
- IPV4_DEVCONF_MC_FORWARDING,
- IPV4_DEVCONF_PROXY_ARP,
- IPV4_DEVCONF_ACCEPT_REDIRECTS,
- IPV4_DEVCONF_SECURE_REDIRECTS,
- IPV4_DEVCONF_SEND_REDIRECTS,
- IPV4_DEVCONF_SHARED_MEDIA,
- IPV4_DEVCONF_RP_FILTER,
- IPV4_DEVCONF_ACCEPT_SOURCE_ROUTE,
- IPV4_DEVCONF_BOOTP_RELAY,
- IPV4_DEVCONF_LOG_MARTIANS,
- IPV4_DEVCONF_TAG,
- IPV4_DEVCONF_ARPFILTER,
- IPV4_DEVCONF_MEDIUM_ID,
- IPV4_DEVCONF_NOXFRM,
- IPV4_DEVCONF_NOPOLICY,
- IPV4_DEVCONF_FORCE_IGMP_VERSION,
- IPV4_DEVCONF_ARP_ANNOUNCE,
- IPV4_DEVCONF_ARP_IGNORE,
- IPV4_DEVCONF_PROMOTE_SECONDARIES,
- IPV4_DEVCONF_ARP_ACCEPT,
- IPV4_DEVCONF_ARP_NOTIFY,
- IPV4_DEVCONF_ACCEPT_LOCAL,
- IPV4_DEVCONF_SRC_VMARK,
- IPV4_DEVCONF_PROXY_ARP_PVLAN,
- IPV4_DEVCONF_ROUTE_LOCALNET,
- __IPV4_DEVCONF_MAX
-};
-
-#define IPV4_DEVCONF_MAX (__IPV4_DEVCONF_MAX - 1)
-
struct ipv4_devconf {
void *sysctl;
int data[IPV4_DEVCONF_MAX];
--- a/include/uapi/linux/ip.h 2013-06-11 09:50:21.386921137 -0700
+++ b/include/uapi/linux/ip.h 2013-08-21 18:35:29.175788302 -0700
@@ -133,4 +133,38 @@ struct ip_beet_phdr {
__u8 reserved;
};
+/* index values for the variables in ipv4_devconf */
+enum
+{
+ IPV4_DEVCONF_FORWARDING=1,
+ IPV4_DEVCONF_MC_FORWARDING,
+ IPV4_DEVCONF_PROXY_ARP,
+ IPV4_DEVCONF_ACCEPT_REDIRECTS,
+ IPV4_DEVCONF_SECURE_REDIRECTS,
+ IPV4_DEVCONF_SEND_REDIRECTS,
+ IPV4_DEVCONF_SHARED_MEDIA,
+ IPV4_DEVCONF_RP_FILTER,
+ IPV4_DEVCONF_ACCEPT_SOURCE_ROUTE,
+ IPV4_DEVCONF_BOOTP_RELAY,
+ IPV4_DEVCONF_LOG_MARTIANS,
+ IPV4_DEVCONF_TAG,
+ IPV4_DEVCONF_ARPFILTER,
+ IPV4_DEVCONF_MEDIUM_ID,
+ IPV4_DEVCONF_NOXFRM,
+ IPV4_DEVCONF_NOPOLICY,
+ IPV4_DEVCONF_FORCE_IGMP_VERSION,
+ IPV4_DEVCONF_ARP_ANNOUNCE,
+ IPV4_DEVCONF_ARP_IGNORE,
+ IPV4_DEVCONF_PROMOTE_SECONDARIES,
+ IPV4_DEVCONF_ARP_ACCEPT,
+ IPV4_DEVCONF_ARP_NOTIFY,
+ IPV4_DEVCONF_ACCEPT_LOCAL,
+ IPV4_DEVCONF_SRC_VMARK,
+ IPV4_DEVCONF_PROXY_ARP_PVLAN,
+ IPV4_DEVCONF_ROUTE_LOCALNET,
+ __IPV4_DEVCONF_MAX
+};
+
+#define IPV4_DEVCONF_MAX (__IPV4_DEVCONF_MAX - 1)
+
#endif /* _UAPI_LINUX_IP_H */
^ permalink raw reply
* Re: [RFC 0/2] Account for duplicate ACKs with invalid SACK-blocks
From: Corey Hickey @ 2013-08-22 4:15 UTC (permalink / raw)
To: David Miller
Cc: christoph.paasch, eric.dumazet, netdev, kernel, benjamin.hesmans
In-Reply-To: <20130821.203201.369023440348094508.davem@davemloft.net>
On 2013-08-21 20:32, David Miller wrote:
> From: Christoph Paasch <christoph.paasch@uclouvain.be>
> Date: Mon, 19 Aug 2013 21:29:26 +0200
>
>> There exist sequence-number rewriting middleboxes, who do not modify the
>> sequence-number in the SACK-blocks.
>
> These are bugs that the vendor's should fix, not something we should
> cater to at all.
>
> I'm not applying patches like these, and I've rejected similar
> workarounds in the past 18 years, so this position is strong and
> consistent.
>
> Sorry.
That's not terrible for me; we'll most likely be turning off SEQ
randomization on the FWSM, when we have time to make sure it doesn't
break anything (which it shouldn't).
-Corey
^ permalink raw reply
* Re: [PATCH 1/2] Revert "genetlink: fix family dump race"
From: Pravin Shelar @ 2013-08-22 4:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, Thomas Graf, Johannes Berg
In-Reply-To: <1377094083-8122-2-git-send-email-johannes@sipsolutions.net>
On Wed, Aug 21, 2013 at 7:08 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
>
> From: Johannes Berg <johannes.berg@intel.com>
>
> This reverts commit 58ad436fcf49810aa006016107f494c9ac9013db.
>
> It turns out that the change introduced a potential deadlock
> by causing a locking dependency with netlink's cb_mutex. I
> can't seem to find a way to resolve this without doing major
> changes to the locking, so revert this.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
>
> ---
> net/netlink/genetlink.c | 7 -------
> 1 file changed, 7 deletions(-)
>
> diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
> index f85f8a2..512718a 100644
> --- a/net/netlink/genetlink.c
> +++ b/net/netlink/genetlink.c
> @@ -789,10 +789,6 @@ static int ctrl_dumpfamily(struct sk_buff *skb, struct netlink_callback *cb)
> struct net *net = sock_net(skb->sk);
> int chains_to_skip = cb->args[0];
> int fams_to_skip = cb->args[1];
> - bool need_locking = chains_to_skip || fams_to_skip;
> -
> - if (need_locking)
> - genl_lock();
>
> for (i = chains_to_skip; i < GENL_FAM_TAB_SIZE; i++) {
> n = 0;
> @@ -814,9 +810,6 @@ errout:
> cb->args[0] = i;
> cb->args[1] = n;
>
> - if (need_locking)
> - genl_unlock();
> -
> return skb->len;
> }
>
> --
> 1.8.4.rc2
>
> --
> 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 2/2] genetlink: convert family dump code to use RCU
From: Pravin Shelar @ 2013-08-22 4:32 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, Thomas Graf, Johannes Berg
In-Reply-To: <1377094083-8122-3-git-send-email-johannes@sipsolutions.net>
On Wed, Aug 21, 2013 at 7:08 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> In my previous commit 58ad436fcf49810aa006016107f494c9ac9013db
> ("genetlink: fix family dump race") I attempted to solve an
> issue in generic netlink that could lead to crashes, but it
> turns out that this introduced a possibility for deadlock. As
> I haven't found a way to actually add locking without causing
> that, convert the family, family ops/mcast group lists all to
> use RCU, so the family dump code can simply use RCU protection
> instead of locking.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
I send out a fix which fixes genl locking for dump operation and it
might fix this issue, Can you try this?
http://marc.info/?l=linux-netdev&m=137714389705485&w=2
> ---
> net/netlink/genetlink.c | 25 ++++++++++++++++---------
> 1 file changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
> index 512718a..2027964 100644
> --- a/net/netlink/genetlink.c
> +++ b/net/netlink/genetlink.c
> @@ -222,7 +222,7 @@ int genl_register_mc_group(struct genl_family *family,
>
> grp->id = id;
> set_bit(id, mc_groups);
> - list_add_tail(&grp->list, &family->mcast_groups);
> + list_add_tail_rcu(&grp->list, &family->mcast_groups);
> grp->family = family;
>
> genl_ctrl_event(CTRL_CMD_NEWMCAST_GRP, grp);
> @@ -246,7 +246,7 @@ static void __genl_unregister_mc_group(struct genl_family *family,
> netlink_table_ungrab();
>
> clear_bit(grp->id, mc_groups);
> - list_del(&grp->list);
> + list_del_rcu(&grp->list);
> genl_ctrl_event(CTRL_CMD_DELMCAST_GRP, grp);
> grp->id = 0;
> grp->family = NULL;
> @@ -272,6 +272,7 @@ void genl_unregister_mc_group(struct genl_family *family,
> genl_lock_all();
> __genl_unregister_mc_group(family, grp);
> genl_unlock_all();
> + synchronize_rcu();
> }
> EXPORT_SYMBOL(genl_unregister_mc_group);
>
> @@ -281,6 +282,7 @@ static void genl_unregister_mc_groups(struct genl_family *family)
>
> list_for_each_entry_safe(grp, tmp, &family->mcast_groups, list)
> __genl_unregister_mc_group(family, grp);
> + synchronize_rcu();
> }
>
> /**
> @@ -318,7 +320,7 @@ int genl_register_ops(struct genl_family *family, struct genl_ops *ops)
> ops->flags |= GENL_CMD_CAP_HASPOL;
>
> genl_lock_all();
> - list_add_tail(&ops->ops_list, &family->ops_list);
> + list_add_tail_rcu(&ops->ops_list, &family->ops_list);
> genl_unlock_all();
>
> genl_ctrl_event(CTRL_CMD_NEWOPS, ops);
> @@ -351,9 +353,10 @@ int genl_unregister_ops(struct genl_family *family, struct genl_ops *ops)
> genl_lock_all();
> list_for_each_entry(rc, &family->ops_list, ops_list) {
> if (rc == ops) {
> - list_del(&ops->ops_list);
> + list_del_rcu(&ops->ops_list);
> genl_unlock_all();
> genl_ctrl_event(CTRL_CMD_DELOPS, ops);
> + synchronize_rcu();
> return 0;
> }
> }
> @@ -418,7 +421,7 @@ int genl_register_family(struct genl_family *family)
> } else
> family->attrbuf = NULL;
>
> - list_add_tail(&family->family_list, genl_family_chain(family->id));
> + list_add_tail_rcu(&family->family_list, genl_family_chain(family->id));
> genl_unlock_all();
>
> genl_ctrl_event(CTRL_CMD_NEWFAMILY, family);
> @@ -498,7 +501,8 @@ int genl_unregister_family(struct genl_family *family)
> if (family->id != rc->id || strcmp(rc->name, family->name))
> continue;
>
> - list_del(&rc->family_list);
> + list_del_rcu(&rc->family_list);
> + synchronize_rcu();
> INIT_LIST_HEAD(&family->ops_list);
> genl_unlock_all();
>
> @@ -692,7 +696,7 @@ static int ctrl_fill_info(struct genl_family *family, u32 portid, u32 seq,
> if (nla_ops == NULL)
> goto nla_put_failure;
>
> - list_for_each_entry(ops, &family->ops_list, ops_list) {
> + list_for_each_entry_rcu(ops, &family->ops_list, ops_list) {
> struct nlattr *nest;
>
> nest = nla_nest_start(skb, idx++);
> @@ -718,7 +722,7 @@ static int ctrl_fill_info(struct genl_family *family, u32 portid, u32 seq,
> if (nla_grps == NULL)
> goto nla_put_failure;
>
> - list_for_each_entry(grp, &family->mcast_groups, list) {
> + list_for_each_entry_rcu(grp, &family->mcast_groups, list) {
> struct nlattr *nest;
>
> nest = nla_nest_start(skb, idx++);
> @@ -790,9 +794,10 @@ static int ctrl_dumpfamily(struct sk_buff *skb, struct netlink_callback *cb)
> int chains_to_skip = cb->args[0];
> int fams_to_skip = cb->args[1];
>
> + rcu_read_lock();
> for (i = chains_to_skip; i < GENL_FAM_TAB_SIZE; i++) {
> n = 0;
> - list_for_each_entry(rt, genl_family_chain(i), family_list) {
> + list_for_each_entry_rcu(rt, genl_family_chain(i), family_list) {
> if (!rt->netnsok && !net_eq(net, &init_net))
> continue;
> if (++n < fams_to_skip)
> @@ -807,6 +812,8 @@ static int ctrl_dumpfamily(struct sk_buff *skb, struct netlink_callback *cb)
> }
>
> errout:
> + rcu_read_unlock();
> +
> cb->args[0] = i;
> cb->args[1] = n;
>
> --
> 1.8.4.rc2
>
> --
> 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 net-next v3 0/9] net: introduce generic type and helpers for IP address
From: Cong Wang @ 2013-08-22 4:53 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20130820.231159.2092592990953992941.davem@davemloft.net>
On Tue, 2013-08-20 at 23:11 -0700, David Miller wrote:
>
> That's why all these places use a different data structure! They have
> different needs. Can you see that?
>
No problem, then let's drop this patchset.
And I will continue to duplicate the code in my VXLAN patchset.
Thanks.
^ permalink raw reply
* Re: [RFC PATCH] bridge: inherit slave devices needed_headroom
From: Stephen Hemminger @ 2013-08-22 4:58 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, eric.dumazet, vyasevic, davem
In-Reply-To: <1376990505-15708-1-git-send-email-f.fainelli@gmail.com>
On Tue, 20 Aug 2013 10:21:45 +0100
"Florian Fainelli" <f.fainelli@gmail.com> wrote:
> Some slave devices may have set a dev->needed_headroom value which is
> different than the default one, most likely in order to prepend a
> hardware descriptor in front of the Ethernet frame to send. Whenever a
> new slave is added to a bridge, ensure that we update the
> needed_headroom value accordingly to account for the slave
> needed_headroom value.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> net/bridge/br_if.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
> index aa6c9a8..c41d5fb 100644
> --- a/net/bridge/br_if.c
> +++ b/net/bridge/br_if.c
> @@ -383,6 +383,9 @@ int br_add_if(struct net_bridge *br, struct net_device *dev)
>
> netdev_update_features(br->dev);
>
> + if (br->dev->needed_headroom < dev->needed_headroom)
> + br->dev->needed_headroom = dev->needed_headroom;
> +
> spin_lock_bh(&br->lock);
> changed_addr = br_stp_recalculate_bridge_id(br);
>
I am okay with this but it only helps locally generated traffic
which is the minority on most bridge devices. It does nothing for the case
where one port needs more headroom than the packet received on the
other port. That is why a device has to always work when it receives
a packet with less headroom, usually by copying.
^ permalink raw reply
* Re: [Patch net-next v3 9/9] selinux: use generic union inet_addr
From: Cong Wang @ 2013-08-22 5:03 UTC (permalink / raw)
To: Casey Schaufler
Cc: David Miller, netdev, james.l.morris, sds, eparis, pmoore,
linux-kernel, linux-security-module
In-Reply-To: <52137CFF.70601@schaufler-ca.com>
On Tue, 2013-08-20 at 07:28 -0700, Casey Schaufler wrote:
>
> I do use and enjoy all of these implementations! Thank you
> for the fine implementations. In the end, if you're maintaining
> the code it's your call. I question change that does not have
> an obvious purpose because statistically every 10th change has
> a bug.
Sure, feel free to add more.
And please reject all new code >=10 changes in the future too... I give
up, you win. :-)
^ permalink raw reply
* Re: [RFC] phy: micrel: Convert micrel PHY driver to use OF
From: Olof Johansson @ 2013-08-22 5:13 UTC (permalink / raw)
To: dinguyen
Cc: dinh.linux, netdev, Richard Cochran, Linus Walleij, Felipe Balbi,
David S. Miller, Giuseppe Cavallaro, Rob Herring, devicetree
In-Reply-To: <1376412156-3899-1-git-send-email-dinguyen@altera.com>
(adding devicetree@vger.kernel.org)
On Tue, Aug 13, 2013 at 11:42:36AM -0500, dinguyen@altera.com wrote:
> From: Dinh Nguyen <dinguyen@altera.com>
>
> Convert the Micrel PHY driver to use OF. This initial patch is only
> the beginning of an idea to convert the PHY driver to device tree.
>
> Signed-of-by: Dinh Nguyen <dinguyen@altera.com>
> Cc: netdev@vger.kernel.org
> Cc: Richard Cochran <richardcochran@gmail.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Felipe Balbi <balbi@ti.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Rob Herring <rob.herring@calxeda.com>
>
> ---
> Hello,
>
> I would like to solicit comments on the need to convert the ethernet PHY
> drivers to use OF/device trees? For the platform that I'm interested in,
> SOCFPGA, it is using the stmicro ethernet driver. It has a Micrel PHY
> on the board. The only way that I know of how to change the skew settings
> for the phy is through a board level initialization.
>
> One of the ARM maintainers suggested that perhaps refactoring the ethernet
> driver to use device tree would be nice. But that would not help me with
> configuring the PHY settings.
>
> So a little investigation led me to believe that refactoring the /net/phy
> drivers into a device tree implementation would help greatly. I was thinking
> it could be done like the pinctrl or some of the usb/phy driver.
>
> Since I am only familiar with the ARM SoC space, I want to make sure that
> this idea is right approach. I can start with the micrel PHY driver
> first, as that is the only HW I have access to.
Hi,
Sorry for the slow reply here.
I don't think this is quite the right approach.
What you want to do is to make the phy devices register based on device tree
contents, which also means removing the run function, or rather moving it to
a generic run function in the phy subsystem that acts based on device tree
contents instead of a hard-coded per-board run function.
It sounds like defining that binding might end up getting complicated.
I suggest you consider recruiting some of the more seasoned devicetree folks on
this endeavor.
It's possible that you'll mostly have per-vendor/phy type properties to tune
the various settings, but it's also likely that you will have some generic and
shared (optional) properties such as gpios for resetting, or regulators for
powering, the phy.
-Olof
^ permalink raw reply
* Re: Fwd: RFC 6980 on Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery
From: Loganaden Velvindron @ 2013-08-22 5:39 UTC (permalink / raw)
To: Loganaden Velvindron, Fernando Gont, netdev
In-Reply-To: <CAOp4FwTPuY9H=w_A7vdwiJv3RqKLWnf+Nk=q8xaa9sN6+g4j1g@mail.gmail.com>
On Mon, Aug 19, 2013 at 12:52 AM, Loganaden Velvindron
<loganaden@gmail.com> wrote:
> On Thu, Aug 15, 2013 at 2:25 PM, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
>>
>> On Thu, Aug 15, 2013 at 02:14:46PM +0400, Loganaden Velvindron wrote:
>> > I'm not sure if you got my previous mails, but I'd like to know a
>> > couple of things:
>>
>> Ah, you asked me off-list. So, for a wider audience, I copy & paste my answers
>> from the just answered mail. ;)
>>
>> > 1) How can I test this diff ?
>>
>> Actually, nothing should change at all.
>>
>> Myself, I used scapy to construct some packets and send it to a system
>> with the patched kernel and had some printks sprinkeled in the source
>> while watching tcpdump.
>>
>> > 2) It's developed against which git brach ? linux-next ?
>>
>> Yes, I targeted linux-next. But it should apply to older kernels
>> without too much fuzz as well.
>>
>
> I've tested with linux-next.
>
>> > 3) What will/could break with this diff in a production environment ?
>>
>> RA messages could get fragmented if a speaker puts lots of options in it. I
>> hope all RA speakers already spread the options over multiple RAs, but I don't
>> know. In case the RA is fragmented it will now be dropped silently.
>>
>
> My IPv6 gateway machine runs OpenBSD, and so far, no issues with it.
> I'm going to test
> it at work in a couple of hours and report back.
Works fine @ work with cisco routers.
>
>
>> Thanks,
>>
>> Hannes
>>
>
>
>
> --
> This message is strictly personal and the opinions expressed do not
> represent those of my employers, either past or present.
--
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.
^ permalink raw reply
* Re: [PATCH 7/8] net: davinci_mdio: remove unnecessary dev_set_drvdata()
From: Prabhakar Lad @ 2013-08-22 5:53 UTC (permalink / raw)
To: Libo Chen; +Cc: David S. Miller, Mugunthan V N, bigeasy, netdev, LKML, Li Zefan
In-Reply-To: <1377068561-15744-1-git-send-email-libo.chen@huawei.com>
Hi Libo,
Thanks for the patch.
On Wed, Aug 21, 2013 at 12:32 PM, Libo Chen <libo.chen@huawei.com> wrote:
> Unnecessary dev_set_drvdata() is removed, because the driver core
> clears the driver data to NULL after device_release or on probe failure.
>
> Signed-off-by: Libo Chen <libo.chen@huawei.com>
Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Regards,
--Prabhakar Lad
^ permalink raw reply
* Re: [RFC] phy: micrel: Convert micrel PHY driver to use OF
From: Sascha Hauer @ 2013-08-22 6:34 UTC (permalink / raw)
To: Olof Johansson
Cc: dinguyen, dinh.linux, netdev, Richard Cochran, Linus Walleij,
Felipe Balbi, David S. Miller, Giuseppe Cavallaro, Rob Herring,
devicetree
In-Reply-To: <20130822051347.GD5151@quad.lixom.net>
On Wed, Aug 21, 2013 at 10:13:47PM -0700, Olof Johansson wrote:
> (adding devicetree@vger.kernel.org)
>
>
> On Tue, Aug 13, 2013 at 11:42:36AM -0500, dinguyen@altera.com wrote:
> > ---
> > Hello,
> >
> > I would like to solicit comments on the need to convert the ethernet PHY
> > drivers to use OF/device trees? For the platform that I'm interested in,
> > SOCFPGA, it is using the stmicro ethernet driver. It has a Micrel PHY
> > on the board. The only way that I know of how to change the skew settings
> > for the phy is through a board level initialization.
> >
> > One of the ARM maintainers suggested that perhaps refactoring the ethernet
> > driver to use device tree would be nice. But that would not help me with
> > configuring the PHY settings.
> >
> > So a little investigation led me to believe that refactoring the /net/phy
> > drivers into a device tree implementation would help greatly. I was thinking
> > it could be done like the pinctrl or some of the usb/phy driver.
> >
> > Since I am only familiar with the ARM SoC space, I want to make sure that
> > this idea is right approach. I can start with the micrel PHY driver
> > first, as that is the only HW I have access to.
>
> Hi,
>
> Sorry for the slow reply here.
>
> I don't think this is quite the right approach.
>
> What you want to do is to make the phy devices register based on device tree
> contents, which also means removing the run function, or rather moving it to
> a generic run function in the phy subsystem that acts based on device tree
> contents instead of a hard-coded per-board run function.
>
> It sounds like defining that binding might end up getting complicated.
> I suggest you consider recruiting some of the more seasoned devicetree folks on
> this endeavor.
>
> It's possible that you'll mostly have per-vendor/phy type properties to tune
> the various settings, but it's also likely that you will have some generic and
> shared (optional) properties such as gpios for resetting, or regulators for
> powering, the phy.
This patch recently was merged:
http://patchwork.ozlabs.org/patch/268661/
It solves exactly the same problem of specifying the skew settings.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ 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