* Re: [PATCH RFC net-next] ipv6: avoid high order memory allocations for /proc/net/ipv6_route
From: Hannes Frederic Sowa @ 2013-08-22 3:16 UTC (permalink / raw)
To: netdev, yoshfuji
In-Reply-To: <20130821175024.GA14419@order.stressinduktion.org>
On Wed, Aug 21, 2013 at 07:50:24PM +0200, Hannes Frederic Sowa wrote:
> I created this patch in a hurry while trying to get the rt6i_flags of
> the routing entries on a system with lots of routes (I later cleaned it
> up a bit).
>
> The current approach for dumping routes over netlink is to redump a tree
> as soon as the serialnumber on the nodes changes. Is this behavior more
> preferable as to just ignore the routes for that moment? I am in favour
> of not restarting the dump on /proc/net/ipv6_route.
Ok, I hit the same panics as Patrick once did
while some more stress testing this change
(http://permalink.gmane.org/gmane.linux.network/151391).
As I read this up, this was also the reason the serial checks where
introduced. It also tries to skip visited notes, so please void my
question above.
The reason is a disconnected fib6_node in FWS_U state trying to walk
up. I'll investigate if we can fix this up in the walker post-cleanup on
fib6_repair_tree/fib6_del_route (then we could also remove the serial
number checks on inet6_dump_fib) or I will make the appropriate serial
changes to this patch, too.
> +int ipv6_route_open(struct inode *inode, struct file *file)
> +{
> + return seq_open_net(inode, file, &ipv6_route_seq_ops,
> + sizeof(struct fib6_walker_t));
> +}
> +
sizeof(struct ipv6_route_iter) here, of course. :(
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH net] skge: dma_sync the whole receive buffer
From: poma @ 2013-08-22 3:30 UTC (permalink / raw)
To: Greg KH; +Cc: Stephen Hemminger, David Miller, netdev, Linus Torvalds
In-Reply-To: <20130822004023.GA26938@kroah.com>
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
^ permalink raw reply
* Re: [RFC 0/2] Account for duplicate ACKs with invalid SACK-blocks
From: David Miller @ 2013-08-22 3:32 UTC (permalink / raw)
To: christoph.paasch
Cc: eric.dumazet, netdev, kernel, bugfood-ml, benjamin.hesmans
In-Reply-To: <1376940568-16512-1-git-send-email-christoph.paasch@uclouvain.be>
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.
^ permalink raw reply
* 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
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