* Re: [PATCH openvswitch] netlink: Implement & enable memory mapped netlink i/o
From: Thomas Graf @ 2013-11-27 22:51 UTC (permalink / raw)
To: Ben Pfaff
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
fleitner-H+wXaHxf7aLQT0dZR+AlfA
In-Reply-To: <20131125230253.GR1435-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
On 11/26/2013 12:02 AM, Ben Pfaff wrote:
> On Thu, Nov 21, 2013 at 07:16:54PM +0100, Thomas Graf wrote:
>> Based on the initial patch by Cong Wang posted a couple of months
>> ago.
>>
>> This is the user space counterpart needed for the kernel patch
>> '[PATCH net-next 3/8] openvswitch: Enable memory mapped Netlink i/o'
>>
>> Allows the kernel to construct Netlink messages on memory mapped
>> buffers and thus avoids copying. The functionality is enabled on
>> sockets used for unicast traffic.
>>
>> Further optimizations are possible by avoiding the copy into the
>> ofpbuf after reading.
>>
>> Cc: Cong Wang <xiyou.wangcong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Signed-off-by: Thomas Graf <tgraf-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>
> Does this depend on other patches or some specific Linux kernel
> headers? It doesn't build here on GCC (similar results with Clang):
Yes, it depends on a sufficiently recent <linux/netlink.h>. We can
either #ifdef the mmap code or we provide a local copy of
<linux/netlink.h> in include/linux. The code automatically falls back if
the kernel does not support NL MMAP so that seems superior.
What do you prefer?
^ permalink raw reply
* Re: [PATCH openvswitch] linux: Signal datapath that unaligned Netlink message can be received
From: Thomas Graf @ 2013-11-27 22:41 UTC (permalink / raw)
To: Jesse Gross; +Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, netdev
In-Reply-To: <CAEP_g=9Ax4A+eKZyUXhZhqFQ8Nyi5JeQzwyqJY=rVceKZHEHNw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 11/26/2013 12:41 AM, Jesse Gross wrote:
> On Thu, Nov 21, 2013 at 10:15 AM, Thomas Graf <tgraf-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> diff --git a/lib/dpif-linux.c b/lib/dpif-linux.c
>> index 1dcf321..5c952bc 100644
>> --- a/lib/dpif-linux.c
>> +++ b/lib/dpif-linux.c
>> @@ -232,6 +233,7 @@ dpif_linux_open(const struct dpif_class *class OVS_UNUSED, const char *name,
>> dp_request.cmd = OVS_DP_CMD_GET;
>> }
>> dp_request.name = name;
>> + dp_request.user_features |= OVS_DP_F_UNALIGNED;
>
> Should we restrict this to just OVS_DP_CMD_NEW?
I'm fine either way. We currently disregard user features in GET.
^ permalink raw reply
* Re: [PATCH net-next 7/8] openvswitch: Drop user features if old user space attempted to create datapath
From: Thomas Graf @ 2013-11-27 22:35 UTC (permalink / raw)
To: Jesse Gross
Cc: David Miller, dev@openvswitch.org, netdev, Daniel Borkmann,
ffusco, fleitner, Eric Dumazet, Ben Hutchings
In-Reply-To: <CAEP_g=8nADwqAJ81gtpJ-6v2XW4Se+OK1RPcEZ7mh-_PAwyo7g@mail.gmail.com>
On 11/25/13 at 03:40pm, Jesse Gross wrote:
> On Fri, Nov 22, 2013 at 8:56 AM, Thomas Graf <tgraf@suug.ch> wrote:
> > diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
> > index 07ef2c3..a6863e2 100644
> > --- a/include/uapi/linux/openvswitch.h
> > +++ b/include/uapi/linux/openvswitch.h
> > @@ -40,7 +40,15 @@ struct ovs_header {
> >
> > #define OVS_DATAPATH_FAMILY "ovs_datapath"
> > #define OVS_DATAPATH_MCGROUP "ovs_datapath"
> > -#define OVS_DATAPATH_VERSION 0x1
> > +
> > +/* V2:
> > + * - API users are expected to provide OVS_DP_ATTR_USER_FEATURES
> > + * with NLM_F_REPLACE when creating the datapath.
> > + */
> > +#define OVS_DATAPATH_VERSION 2
>
> I'm not sure that I understand this comment - I guess it means that
> there's no legacy path when using NLM_F_REPLACE?
It means that if the V2 caller does not provide user features the
existing user features are preserved upon NLM_F_REPLACE. V1 users
can't be aware and the user features are always reset.
^ permalink raw reply
* Re: [PATCH net-next 6/8] openvswitch: Allow update of dp with OVS_DP_CMD_NEW if NLM_F_REPLACE is set
From: Thomas Graf @ 2013-11-27 22:32 UTC (permalink / raw)
To: Jesse Gross
Cc: David Miller, dev@openvswitch.org, netdev, Daniel Borkmann,
ffusco, fleitner, Eric Dumazet, Ben Hutchings
In-Reply-To: <CAEP_g=8=dzm7NS5zx4-+wY+AXZLpym7JGQO9YTAgdTPm9v1mpQ@mail.gmail.com>
On 11/25/13 at 01:23pm, Jesse Gross wrote:
> On Fri, Nov 22, 2013 at 8:56 AM, Thomas Graf <tgraf@suug.ch> wrote:
> > diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
> > index 95d4424..3f1fb87 100644
> > --- a/net/openvswitch/datapath.c
> > +++ b/net/openvswitch/datapath.c
>
> I'm a little worried that this introduces some quirks to the interface. Such as:
>
> > @@ -1190,6 +1185,7 @@ static int ovs_dp_cmd_new(struct sk_buff *skb, struct genl_info *info)
> > struct vport *vport;
> > struct ovs_net *ovs_net;
> > int err, i;
> > + bool allocated = false;
> >
> > err = -EINVAL;
> > if (!a[OVS_DP_ATTR_NAME] || !a[OVS_DP_ATTR_UPCALL_PID])
>
> This requires that DP_CMD_SET supply an OVS_DP_ATTR_UPCALL_PID
> although I don't think that it's really necessary. In fact, we used to
> completely ignore that field on SET since it's really only useful on
> datapath creation and can otherwise be done more naturally through the
> vport interface.
It's a theoretical exercise since nobody is using OVS_DP_CMD_SET
but I agree, it should be optional in the update path. I'll update
the patch.
> > @@ -1197,11 +1193,26 @@ static int ovs_dp_cmd_new(struct sk_buff *skb, struct genl_info *info)
> >
> > ovs_lock();
> >
> > + dp = lookup_datapath(sock_net(skb->sk), info->userhdr, info->attrs);
> > + if (!IS_ERR(dp)) {
> > + if (info->nlhdr->nlmsg_flags & NLM_F_REPLACE)
> > + goto update;
>
> Conversely, this won't respect the UPCALL_PID field, which I would
> expect it to since I think NLM_F_REPLACE should be roughly equivalent
> to a delete and create. I believe that's the only field that is
> missing although it seems easy to have the same problem as others are
> added in the future.
It's up to us to define that.
What the patch proposes is what OVS has been doing already: Try to
find a datapath with matching name and reuse it. Otherwise create
a new data path. Disregard UPCALL_PID.
As you state above, the upcall pid can be modified through the vport
interface which in my opinion is the correct way to modify it if
needed.
I have no problem with adding upcall pid overwrite logic to the
NLM_F_REPLACE path but it _changes_ the existing semantics in
terms of "opening" a datapath.
^ permalink raw reply
* Re: [PATCH net] netem: fix loss generators
From: Hagen Paul Pfeifer @ 2013-11-27 21:28 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, stefano.salsano, netdev
In-Reply-To: <20131121175419.59059598@nehalam.linuxnetplumber.net>
[-- Attachment #1: Type: text/plain, Size: 787 bytes --]
* Stephen Hemminger | 2013-11-21 17:54:19 [-0800]:
>Patch from developers of the alternative loss models, downloaded from:
> http://netgroup.uniroma2.it/twiki/bin/view.cgi/Main/NetemCLG
>
>We found some bugs in our first implementation.
>A first set of bugs is in the function loss_4state:
> In the case 1 of the switch statement in the if conditions we
> need to add clg->a4 to clg->a1, according to the model.
> In the case 3 of the switch statement we need to delete "return
> true" if the condition leads us in the state 1, because the state 1 is
> a good state.
I already fixed the former bug[1]. I cc'ed stefano.salsano@uniroma2.it but did
not get any acked-by/tested-by. The second bug still exists.
Hagen
[1] http://www.spinics.net/lists/netdev/msg255165.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [patch] net: clamp ->msg_namelen instead of returning an error
From: Eric Dumazet @ 2013-11-27 21:27 UTC (permalink / raw)
To: Dan Carpenter; +Cc: David S. Miller, netdev, Eric Wong, Hannes Frederic Sowa
In-Reply-To: <20131127124021.GA2025@elgon.mountain>
On Wed, 2013-11-27 at 15:40 +0300, Dan Carpenter wrote:
> If kmsg->msg_namelen > sizeof(struct sockaddr_storage) then in the
> original code that would lead to memory corruption in the kernel if you
> had audit configured. If you didn't have audit configured it was
> harmless.
>
> There are some programs such as beta versions of Ruby which use too
> large of a buffer and returning an error code breaks them. We should
> clamp the ->msg_namelen value instead.
>
> Reported-by: Eric Wong <normalperson@yhbt.net>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: 1661bf364ae9 ("net: heap overflow in __audit_sockaddr()")
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [patch v2] net: heap overflow in __audit_sockaddr()
From: Hannes Frederic Sowa @ 2013-11-27 21:18 UTC (permalink / raw)
To: Linus Torvalds
Cc: Eric Wong, Dan Carpenter, David S. Miller, Network Development,
security@kernel.org, Jüri Aedla, # .39.x
In-Reply-To: <CA+55aFwP5NWG9doOqZRy7fBdUpwW-bDwEJxjMV0Yr3q3Y=30Fg@mail.gmail.com>
On Wed, Nov 27, 2013 at 12:24:41PM -0800, Linus Torvalds wrote:
> On Wed, Nov 27, 2013 at 3:51 AM, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
> >
> > We have to clamp msg_namelen to max sizeof(struct sockaddr_storage).
> > The sendmsg handler will check msg_namelen again and error out correctly if
> > the size of msg_name is too short.
>
> Yeah, clamping sounds like the right thing to do at least for
> receiving. For sending, you should say "we can't send packets that big
> due to memory constraints" (of, for the case of a sockaddr, "to an
> address this big"), but for receiving the size of the user space
> buffer is kind of irrelevant - if the user gives a bigger buffer than
> necessary, who cares? We just need to make sure that the kernel
> doesn't then allocate silly-big temporary buffers internally.
>
> There seems to be a patch floating around to clamp things already.
Data buffers are clamed fine already.
The sockaddr buffers are currently always 128 bytes (== sizeof(struct
sockaddr_storage)) in size and are allocated on the stack of the
recvmsg/sendmsg syscall handlers. We normally don't have high stack usage
on recvmsg calls but it could be worth trying to optimize that on sendmsg,
I agree. I have not seen a patch which tries to do so but maybe I haven't
looked far enough back in the mailing list archives.
Clamping on sending seems necessary to not break exisiting applications. I
guess those programs expect the kernel to know which namelen the
protocol expects and only use that part of the provided sockaddr
buffer (an example is the mentioned ruby bug in this thread which
seems to pass down the size of a union for all possile sockaddrs:
<https://bugs.ruby-lang.org/issues/9124#note-2>).
I recently noticed a some more subtile annoyance in that code:
We don't know the anticipated sockaddr size before calling the recvmsg
handler. Hence it is currently possible that we dequeue a packet from
the socket receiving queue and later error out and drop the packet because
the user provided a socket address buffer which is too small. IMHO we
should catch that before dequeueing the packet. Either we can export the
address size via the per-protocol-structures or we have to start passing the
user provided buffer sizes down the stack (currently all recvmsg handlers
expect to always have 128 bytes for storing addresses).
I'll look into this.
Greetings,
Hannes
^ permalink raw reply
* [PATCH 4/4] can: flexcan: use correct clock as base for bit rate calculation
From: Marc Kleine-Budde @ 2013-11-27 21:11 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel, Marc Kleine-Budde, linux-stable
In-Reply-To: <1385586695-11134-1-git-send-email-mkl@pengutronix.de>
The flexcan IP core uses the peripheral clock ("per") as basic clock for the
bit timing calculation. However the driver uses the the wrong clock ("ipg").
This leads to wrong bit rates if the rates on both clock are different.
This patch fixes the problem by using the correct clock for the bit rate
calculation.
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/flexcan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index ae08cf1..aaed97b 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -1020,13 +1020,13 @@ static int flexcan_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "no ipg clock defined\n");
return PTR_ERR(clk_ipg);
}
- clock_freq = clk_get_rate(clk_ipg);
clk_per = devm_clk_get(&pdev->dev, "per");
if (IS_ERR(clk_per)) {
dev_err(&pdev->dev, "no per clock defined\n");
return PTR_ERR(clk_per);
}
+ clock_freq = clk_get_rate(clk_per);
}
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
--
1.8.5.rc0
^ permalink raw reply related
* [PATCH 2/4] can: c_can: don't call pm_runtime_get_sync() from interrupt context
From: Marc Kleine-Budde @ 2013-11-27 21:11 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Marc Kleine-Budde, Andrew Glen,
linux-stable
In-Reply-To: <1385586695-11134-1-git-send-email-mkl@pengutronix.de>
The c_can driver contians a callpath (c_can_poll -> c_can_state_change ->
c_can_get_berr_counter) which may call pm_runtime_get_sync() from the IRQ
handler, which is not allowed and results in "BUG: scheduling while atomic".
This problem is fixed by introducing __c_can_get_berr_counter, which will not
call pm_runtime_get_sync().
Reported-by: Andrew Glen <AGlen@bepmarine.com>
Tested-by: Andrew Glen <AGlen@bepmarine.com>
Signed-off-by: Andrew Glen <AGlen@bepmarine.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/c_can/c_can.c | 21 +++++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index e3fc07c..e59c42b 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -712,22 +712,31 @@ static int c_can_set_mode(struct net_device *dev, enum can_mode mode)
return 0;
}
-static int c_can_get_berr_counter(const struct net_device *dev,
- struct can_berr_counter *bec)
+static int __c_can_get_berr_counter(const struct net_device *dev,
+ struct can_berr_counter *bec)
{
unsigned int reg_err_counter;
struct c_can_priv *priv = netdev_priv(dev);
- c_can_pm_runtime_get_sync(priv);
-
reg_err_counter = priv->read_reg(priv, C_CAN_ERR_CNT_REG);
bec->rxerr = (reg_err_counter & ERR_CNT_REC_MASK) >>
ERR_CNT_REC_SHIFT;
bec->txerr = reg_err_counter & ERR_CNT_TEC_MASK;
+ return 0;
+}
+
+static int c_can_get_berr_counter(const struct net_device *dev,
+ struct can_berr_counter *bec)
+{
+ struct c_can_priv *priv = netdev_priv(dev);
+ int err;
+
+ c_can_pm_runtime_get_sync(priv);
+ err = __c_can_get_berr_counter(dev, bec);
c_can_pm_runtime_put_sync(priv);
- return 0;
+ return err;
}
/*
@@ -872,7 +881,7 @@ static int c_can_handle_state_change(struct net_device *dev,
if (unlikely(!skb))
return 0;
- c_can_get_berr_counter(dev, &bec);
+ __c_can_get_berr_counter(dev, &bec);
reg_err_counter = priv->read_reg(priv, C_CAN_ERR_CNT_REG);
rx_err_passive = (reg_err_counter & ERR_CNT_RP_MASK) >>
ERR_CNT_RP_SHIFT;
--
1.8.5.rc0
^ permalink raw reply related
* [PATCH 1/4] can: sja1000: fix {pre,post}_irq() handling and IRQ handler return value
From: Marc Kleine-Budde @ 2013-11-27 21:11 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Oliver Hartkopp, linux-stable,
Marc Kleine-Budde
In-Reply-To: <1385586695-11134-1-git-send-email-mkl@pengutronix.de>
From: Oliver Hartkopp <socketcan@hartkopp.net>
This patch fixes the issue that the sja1000_interrupt() function may have
returned IRQ_NONE without processing the optional pre_irq() and post_irq()
function before. Further the irq processing counter 'n' is moved to the end of
the while statement to return correct IRQ_[NONE|HANDLED] values at error
conditions.
Reported-by: Wolfgang Grandegger <wg@grandegger.com>
Acked-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/sja1000/sja1000.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/net/can/sja1000/sja1000.c b/drivers/net/can/sja1000/sja1000.c
index 7164a99..f17c301 100644
--- a/drivers/net/can/sja1000/sja1000.c
+++ b/drivers/net/can/sja1000/sja1000.c
@@ -494,20 +494,20 @@ irqreturn_t sja1000_interrupt(int irq, void *dev_id)
uint8_t isrc, status;
int n = 0;
- /* Shared interrupts and IRQ off? */
- if (priv->read_reg(priv, SJA1000_IER) == IRQ_OFF)
- return IRQ_NONE;
-
if (priv->pre_irq)
priv->pre_irq(priv);
+ /* Shared interrupts and IRQ off? */
+ if (priv->read_reg(priv, SJA1000_IER) == IRQ_OFF)
+ goto out;
+
while ((isrc = priv->read_reg(priv, SJA1000_IR)) &&
(n < SJA1000_MAX_IRQ)) {
- n++;
+
status = priv->read_reg(priv, SJA1000_SR);
/* check for absent controller due to hw unplug */
if (status == 0xFF && sja1000_is_absent(priv))
- return IRQ_NONE;
+ goto out;
if (isrc & IRQ_WUI)
netdev_warn(dev, "wakeup interrupt\n");
@@ -535,7 +535,7 @@ irqreturn_t sja1000_interrupt(int irq, void *dev_id)
status = priv->read_reg(priv, SJA1000_SR);
/* check for absent controller */
if (status == 0xFF && sja1000_is_absent(priv))
- return IRQ_NONE;
+ goto out;
}
}
if (isrc & (IRQ_DOI | IRQ_EI | IRQ_BEI | IRQ_EPI | IRQ_ALI)) {
@@ -543,8 +543,9 @@ irqreturn_t sja1000_interrupt(int irq, void *dev_id)
if (sja1000_err(dev, isrc, status))
break;
}
+ n++;
}
-
+out:
if (priv->post_irq)
priv->post_irq(priv);
--
1.8.5.rc0
^ permalink raw reply related
* [PATCH 3/4] can: c_can: fix calculation of transmitted bytes on tx complete
From: Marc Kleine-Budde @ 2013-11-27 21:11 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel, Holger Bechtold, Marc Kleine-Budde
In-Reply-To: <1385586695-11134-1-git-send-email-mkl@pengutronix.de>
From: Holger Bechtold <Holger.Bechtold@gmx.net>
The number of bytes transmitted was not updated correctly, if several CAN
messages (with different length) were transmitted in one 'bunch'. Thus
programs like 'ifconfig' showed wrong transmit byte counts. Reason was, that
the message object whose DLC is to be read was not necessarily the active one
at the time when
priv->read_reg(priv, C_CAN_IFACE(MSGCTRL_REG, 0)) & IF_MCONT_DLC_MASK;
was executed.
Signed-off-by: Holger Bechtold <Holger.Bechtold@gmx.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/c_can/c_can.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index e59c42b..77061ee 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -763,6 +763,7 @@ static void c_can_do_tx(struct net_device *dev)
if (!(val & (1 << (msg_obj_no - 1)))) {
can_get_echo_skb(dev,
msg_obj_no - C_CAN_MSG_OBJ_TX_FIRST);
+ c_can_object_get(dev, 0, msg_obj_no, IF_COMM_ALL);
stats->tx_bytes += priv->read_reg(priv,
C_CAN_IFACE(MSGCTRL_REG, 0))
& IF_MCONT_DLC_MASK;
--
1.8.5.rc0
^ permalink raw reply related
* pull-request: can 2013-11-27
From: Marc Kleine-Budde @ 2013-11-27 21:11 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel
Hello David,
this is an extention of my pull request from 2013-11-25, it includes an
additional patch.
This series consists of a patch by Oliver Hartkopp which fixes some corner
cases in the interrupt handler of the sja1000 driver. Then there are two
patches for the c_can dirver. One by me, which fixes a runtime pm related
"scheduling while atomic" error and patch by Holger Bechtold that fixes the
calculation of the transmitted bytes.
The fourth patch (the additional one) is by me, it corrects the clock usage in
the flexcan driver.
regards,
Marc
---
The following changes since commit 2c7a9dc1641664173211c4ebc5db510a08684c46:
be2net: Avoid programming permenant MAC by BE3-R VFs (2013-11-23 15:11:07 -0800)
are available in the git repository at:
git://gitorious.org/linux-can/linux-can.git fixes-for-3.13-20131127
for you to fetch changes up to 1a3e5173f5e72cbf7f0c8927b33082e361c16d72:
can: flexcan: use correct clock as base for bit rate calculation (2013-11-26 15:39:47 +0100)
----------------------------------------------------------------
Holger Bechtold (1):
can: c_can: fix calculation of transmitted bytes on tx complete
Marc Kleine-Budde (2):
can: c_can: don't call pm_runtime_get_sync() from interrupt context
can: flexcan: use correct clock as base for bit rate calculation
Oliver Hartkopp (1):
can: sja1000: fix {pre,post}_irq() handling and IRQ handler return value
drivers/net/can/c_can/c_can.c | 22 ++++++++++++++++------
drivers/net/can/flexcan.c | 2 +-
drivers/net/can/sja1000/sja1000.c | 17 +++++++++--------
3 files changed, 26 insertions(+), 15 deletions(-)
^ permalink raw reply
* Re: r8169 Wake on Lan
From: Pablo Cholaky @ 2013-11-27 20:32 UTC (permalink / raw)
To: Anupama Reddy; +Cc: netdev
In-Reply-To: <CAOWq=SwL=+-rwEqOYH8qUCObzL9sABA1f+6=pgnvQf1wNis3gw@mail.gmail.com>
Anupama Reddy <bn.anupama@gmail.com>
>use the ethtool to disable the WOL option
Yes, I'm doing that, but a init script will not solve suspend to disk
or RAM auto-WOL problems, I need to "remember" it, I'm doing that
right now, but I don't think it's the best solution. Do you know
another option?
^ permalink raw reply
* Re: [patch v2] net: heap overflow in __audit_sockaddr()
From: Linus Torvalds @ 2013-11-27 20:24 UTC (permalink / raw)
To: Eric Wong, Dan Carpenter, David S. Miller, Network Development,
security@kernel.org, Jüri Aedla, # .39.x
In-Reply-To: <20131127115120.GC20630@order.stressinduktion.org>
On Wed, Nov 27, 2013 at 3:51 AM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
>
> We have to clamp msg_namelen to max sizeof(struct sockaddr_storage).
> The sendmsg handler will check msg_namelen again and error out correctly if
> the size of msg_name is too short.
Yeah, clamping sounds like the right thing to do at least for
receiving. For sending, you should say "we can't send packets that big
due to memory constraints" (of, for the case of a sockaddr, "to an
address this big"), but for receiving the size of the user space
buffer is kind of irrelevant - if the user gives a bigger buffer than
necessary, who cares? We just need to make sure that the kernel
doesn't then allocate silly-big temporary buffers internally.
There seems to be a patch floating around to clamp things already.
Linus
^ permalink raw reply
* Re: [patch] net: clamp ->msg_namelen instead of returning an error
From: Eric Wong @ 2013-11-27 19:42 UTC (permalink / raw)
To: Dan Carpenter; +Cc: David S. Miller, netdev, Hannes Frederic Sowa
In-Reply-To: <20131127124021.GA2025@elgon.mountain>
Dan Carpenter <dan.carpenter@oracle.com> wrote:
> If kmsg->msg_namelen > sizeof(struct sockaddr_storage) then in the
> original code that would lead to memory corruption in the kernel if you
> had audit configured. If you didn't have audit configured it was
> harmless.
>
> There are some programs such as beta versions of Ruby which use too
> large of a buffer and returning an error code breaks them. We should
> clamp the ->msg_namelen value instead.
>
> Reported-by: Eric Wong <normalperson@yhbt.net>
Thanks Dan, Ruby trunk r43886 works out-of-the-box with this fix.
Dave: please queue for stable, thanks
Tested-by: Eric Wong <normalperson@yhbt.net>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
^ permalink raw reply
* [PATCH v2] net: smc91x: Fix device tree based configuration so it's usable
From: Tony Lindgren @ 2013-11-27 18:56 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, devicetree, Nicolas Pitre, Mark Rutland
Commit 89ce376c6bdc (drivers/net: Use of_match_ptr() macro in smc91x.c)
added minimal device tree support to smc91x, but it's not working on
many platforms because of the lack of some key configuration bits.
Fix the issue by parsing the necessary configuration like the
smc911x driver is doing. As most smc91x users seem to use 16-bit
access, let's default to that if no reg-io-width is specified.
Cc: Nicolas Pitre <nico@fluxnic.net>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: netdev@vger.kernel.org
Cc: devicetree@vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
Device tree folks, any objection to using the reg-io-width property
as a mask here?
Looks like we can use reg-io-width as a mask too if needed, it seems
to play fine with combinations of 1 = 8-bit, 2 = 16-bit, 4 = 32-bit
and so on.
I would like to see this merged during the -rc cycle as this makes
my test devices behave the same way when booted in legacy platform
data mode compared to when booted with device tree.
--- a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
+++ b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
@@ -8,3 +8,7 @@ Required properties:
Optional properties:
- phy-device : phandle to Ethernet phy
- local-mac-address : Ethernet mac address to use
+- reg-io-width : Mask of sizes (in bytes) of the IO accesses that
+ are supported on the device. Valid value for SMSC LAN91c111 are
+ 1, 2 or 4. If it's omitted or invalid, the size would be 2 meaning
+ 16-bit access only.
--- a/drivers/net/ethernet/smsc/smc91x.c
+++ b/drivers/net/ethernet/smsc/smc91x.c
@@ -82,6 +82,7 @@ static const char version[] =
#include <linux/mii.h>
#include <linux/workqueue.h>
#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/netdevice.h>
#include <linux/etherdevice.h>
@@ -2184,6 +2185,15 @@ static void smc_release_datacs(struct platform_device *pdev, struct net_device *
}
}
+#if IS_BUILTIN(CONFIG_OF)
+static const struct of_device_id smc91x_match[] = {
+ { .compatible = "smsc,lan91c94", },
+ { .compatible = "smsc,lan91c111", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, smc91x_match);
+#endif
+
/*
* smc_init(void)
* Input parameters:
@@ -2198,6 +2208,8 @@ static void smc_release_datacs(struct platform_device *pdev, struct net_device *
static int smc_drv_probe(struct platform_device *pdev)
{
struct smc91x_platdata *pd = dev_get_platdata(&pdev->dev);
+ struct device_node *np = pdev->dev.of_node;
+ const struct of_device_id *match = NULL;
struct smc_local *lp;
struct net_device *ndev;
struct resource *res, *ires;
@@ -2217,11 +2229,33 @@ static int smc_drv_probe(struct platform_device *pdev)
*/
lp = netdev_priv(ndev);
+ lp->cfg.flags = 0;
if (pd) {
memcpy(&lp->cfg, pd, sizeof(lp->cfg));
lp->io_shift = SMC91X_IO_SHIFT(lp->cfg.flags);
- } else {
+ }
+
+#if IS_BUILTIN(CONFIG_OF)
+ match = of_match_device(of_match_ptr(smc91x_match), &pdev->dev);
+ if (match) {
+ u32 val;
+
+ /* Combination of IO widths supported, default to 16-bit */
+ if (!of_property_read_u32(np, "reg-io-width", &val)) {
+ if (val & 1)
+ lp->cfg.flags |= SMC91X_USE_8BIT;
+ if ((val == 0) || (val & 2))
+ lp->cfg.flags |= SMC91X_USE_16BIT;
+ if (val & 4)
+ lp->cfg.flags |= SMC91X_USE_32BIT;
+ } else {
+ lp->cfg.flags |= SMC91X_USE_16BIT;
+ }
+ }
+#endif
+
+ if (!pd && !match) {
lp->cfg.flags |= (SMC_CAN_USE_8BIT) ? SMC91X_USE_8BIT : 0;
lp->cfg.flags |= (SMC_CAN_USE_16BIT) ? SMC91X_USE_16BIT : 0;
lp->cfg.flags |= (SMC_CAN_USE_32BIT) ? SMC91X_USE_32BIT : 0;
@@ -2370,15 +2404,6 @@ static int smc_drv_resume(struct device *dev)
return 0;
}
-#ifdef CONFIG_OF
-static const struct of_device_id smc91x_match[] = {
- { .compatible = "smsc,lan91c94", },
- { .compatible = "smsc,lan91c111", },
- {},
-};
-MODULE_DEVICE_TABLE(of, smc91x_match);
-#endif
-
static struct dev_pm_ops smc_drv_pm_ops = {
.suspend = smc_drv_suspend,
.resume = smc_drv_resume,
^ permalink raw reply
* Re: [PATCH 5/5][v2] phylib: Add of_phy_attach
From: Florian Fainelli @ 2013-11-27 18:55 UTC (permalink / raw)
To: shh.xie
Cc: David Miller, jg1.han, mugunthanvnm, netdev,
linux-kernel@vger.kernel.org, emilian.medve, madalin.bucur
In-Reply-To: <1385459735-722-1-git-send-email-shh.xie@gmail.com>
2013/11/26 <shh.xie@gmail.com>:
> From: Andy Fleming <afleming@freescale.com>
>
> 10G PHYs don't currently support running the state machine, which
> is implicitly setup via of_phy_connect(). Therefore, it is necessary
> to implement an OF version of phy_attach(), which does everything
> except start the state machine.
>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> v2: no changes.
>
> drivers/of/of_mdio.c | 19 +++++++++++++++++++
> include/linux/of_mdio.h | 9 +++++++++
> 2 files changed, 28 insertions(+)
>
> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
> index d5a57a9..21076ac 100644
> --- a/drivers/of/of_mdio.c
> +++ b/drivers/of/of_mdio.c
> @@ -247,3 +247,22 @@ struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
> return IS_ERR(phy) ? NULL : phy;
> }
> EXPORT_SYMBOL(of_phy_connect_fixed_link);
> +
> +/**
> + * of_phy_attach - Attach to a PHY without starting the state machine
> + * @dev: pointer to net_device claiming the phy
> + * @phy_np: Node pointer for the PHY
> + * @flags: flags to pass to the PHY
> + * @iface: PHY data interface type
> + */
> +struct phy_device *of_phy_attach(struct net_device *dev,
> + struct device_node *phy_np, u32 flags, phy_interface_t iface)
> +{
> + struct phy_device *phy = of_phy_find_device(phy_np);
> +
> + if (!phy)
> + return NULL;
> +
> + return phy_attach_direct(dev, phy, flags, iface) ? NULL : phy;
> +}
> +EXPORT_SYMBOL(of_phy_attach);
> diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h
> index 8163107..108583a 100644
> --- a/include/linux/of_mdio.h
> +++ b/include/linux/of_mdio.h
> @@ -19,6 +19,9 @@ extern struct phy_device *of_phy_connect(struct net_device *dev,
> struct device_node *phy_np,
> void (*hndlr)(struct net_device *),
> u32 flags, phy_interface_t iface);
> +struct phy_device *of_phy_attach(struct net_device *dev,
> + struct device_node *phy_np, u32 flags,
> + phy_interface_t iface);
> extern struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
> void (*hndlr)(struct net_device *),
> phy_interface_t iface);
> @@ -44,6 +47,12 @@ static inline struct phy_device *of_phy_connect(struct net_device *dev,
> return NULL;
> }
>
> +static inline struct phy_device *of_phy_attach(struct net_device *dev,
> + struct device_node *phy_np, u32 flags, phy_interface_t iface)
> +{
> + return NULL;
> +}
> +
> static inline struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
> void (*hndlr)(struct net_device *),
> phy_interface_t iface)
> --
> 1.8.4.1
>
>
--
Florian
^ permalink raw reply
* Re: [PATCH 4/5] phylib: Support attaching to generic 10g driver
From: Florian Fainelli @ 2013-11-27 18:51 UTC (permalink / raw)
To: shh.xie
Cc: David Miller, jg1.han, mugunthanvnm, netdev,
linux-kernel@vger.kernel.org, Emilian.Medve, madalin.bucur
In-Reply-To: <1385459707-32467-1-git-send-email-shh.xie@gmail.com>
2013/11/26 <shh.xie@gmail.com>:
> From: Andy Fleming <afleming@freescale.com>
>
> phy_attach_direct() may now attach to a generic 10G driver. It can
> also be used exactly as phy_connect_direct(), which will be useful
> when using of_mdio, as phy_connect (and therefore of_phy_connect)
> start the PHY state machine, which is currently irrelevant for 10G
> PHYs.
>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> v2: align with the array genphy_driver.
>
> drivers/net/phy/phy_device.c | 22 ++++++++++------------
> include/linux/phy.h | 2 ++
> 2 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 96a5e03..a6b4ce0 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -61,9 +61,6 @@ extern void mdio_bus_exit(void);
> static LIST_HEAD(phy_fixup_list);
> static DEFINE_MUTEX(phy_fixup_lock);
>
> -static int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
> - u32 flags, phy_interface_t interface);
> -
> /*
> * Creates a new phy_fixup and adds it to the list
> * @bus_id: A string which matches phydev->dev.bus_id (or PHY_ANY_ID)
> @@ -521,12 +518,12 @@ int phy_init_hw(struct phy_device *phydev)
> *
> * Description: Called by drivers to attach to a particular PHY
> * device. The phy_device is found, and properly hooked up
> - * to the phy_driver. If no driver is attached, then the
> - * genphy_driver is used. The phy_device is given a ptr to
> + * to the phy_driver. If no driver is attached, then a
> + * generic driver is used. The phy_device is given a ptr to
> * the attaching device, and given a callback for link status
> * change. The phy_device is returned to the attaching driver.
> */
> -static int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
> +int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
> u32 flags, phy_interface_t interface)
> {
> struct device *d = &phydev->dev;
> @@ -535,12 +532,10 @@ static int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
> /* Assume that if there is no driver, that it doesn't
> * exist, and we should use the genphy driver. */
> if (NULL == d->driver) {
> - if (phydev->is_c45) {
> - pr_err("No driver for phy %x\n", phydev->phy_id);
> - return -ENODEV;
> - }
> -
> - d->driver = &genphy_driver[0].driver;
> + if (phydev->is_c45)
> + d->driver = &genphy_driver[1].driver;
> + else
> + d->driver = &genphy_driver[0].driver;
>
> err = d->driver->probe(d);
> if (err >= 0)
> @@ -573,6 +568,7 @@ static int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
>
> return err;
> }
> +EXPORT_SYMBOL(phy_attach_direct);
>
> /**
> * phy_attach - attach a network device to a particular PHY device
> @@ -623,6 +619,8 @@ void phy_detach(struct phy_device *phydev)
> * real driver could be loaded */
> if (phydev->dev.driver == &genphy_driver[0].driver)
> device_release_driver(&phydev->dev);
> + else if (phydev->dev.driver == &genphy_driver[1].driver)
> + device_release_driver(&phydev->dev);
> }
> EXPORT_SYMBOL(phy_detach);
>
> diff --git a/include/linux/phy.h b/include/linux/phy.h
> index 2606599..00abc35 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -575,6 +575,8 @@ int phy_init_hw(struct phy_device *phydev);
> struct phy_device * phy_attach(struct net_device *dev,
> const char *bus_id, phy_interface_t interface);
> struct phy_device *phy_find_first(struct mii_bus *bus);
> +int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
> + u32 flags, phy_interface_t interface);
> int phy_connect_direct(struct net_device *dev, struct phy_device *phydev,
> void (*handler)(struct net_device *),
> phy_interface_t interface);
> --
> 1.8.4.1
>
>
--
Florian
^ permalink raw reply
* Re: [PATCH 3/5][v2] phylib: Add generic 10G driver
From: Florian Fainelli @ 2013-11-27 18:47 UTC (permalink / raw)
To: shh.xie
Cc: David Miller, jg1.han, mugunthanvnm, netdev,
linux-kernel@vger.kernel.org, emilian.medve, madalin.bucur
In-Reply-To: <1385459675-30364-1-git-send-email-shh.xie@gmail.com>
Hello Shaohui,
2013/11/26 <shh.xie@gmail.com>:
> From: Andy Fleming <afleming@freescale.com>
>
> Very incomplete, but will allow for binding an ethernet controller
> to it.
>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
> ---
> v2: turn genphy_driver to an array, add generic 10g driver to it.
>
> drivers/net/phy/phy_device.c | 96 ++++++++++++++++++++++++++++++++++++++++----
> 1 file changed, 89 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index d6447b3..96a5e03 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -32,6 +32,7 @@
> #include <linux/module.h>
> #include <linux/mii.h>
> #include <linux/ethtool.h>
> +#include <linux/mdio.h>
> #include <linux/phy.h>
>
> #include <asm/io.h>
> @@ -53,7 +54,7 @@ static void phy_device_release(struct device *dev)
> kfree(to_phy_device(dev));
> }
>
> -static struct phy_driver genphy_driver;
> +static struct phy_driver genphy_driver[2];
Not sure if there are any advantage in using in array here versus two
separate genphy_driver instances, say:
struct phy_driver genphy_driver;
struct phy_driver gen10gphy_driver;
for instance.
If we go for the array, I'd like to use some constant for the array
indices. Right now we only support a generic 10/100/1000 PHY and now a
10G phy, but one day we might support a generic 40G or 100G PHY so the
array indices won't be as obvious as they are today.
> extern int mdio_bus_init(void);
> extern void mdio_bus_exit(void);
>
> @@ -539,7 +540,7 @@ static int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
> return -ENODEV;
> }
>
> - d->driver = &genphy_driver.driver;
> + d->driver = &genphy_driver[0].driver;
This is where using a constant for an index would become useful.
>
> err = d->driver->probe(d);
> if (err >= 0)
> @@ -620,7 +621,7 @@ void phy_detach(struct phy_device *phydev)
> * was using the generic driver), we unbind the device
> * from the generic driver so that there's a chance a
> * real driver could be loaded */
> - if (phydev->dev.driver == &genphy_driver.driver)
> + if (phydev->dev.driver == &genphy_driver[0].driver)
> device_release_driver(&phydev->dev);
> }
> EXPORT_SYMBOL(phy_detach);
> @@ -689,6 +690,12 @@ static int genphy_config_advert(struct phy_device *phydev)
> return changed;
> }
>
> +int gen10g_config_advert(struct phy_device *dev)
> +{
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_config_advert);
> +
> /**
> * genphy_setup_forced - configures/forces speed/duplex from @phydev
> * @phydev: target phy_device struct
> @@ -742,6 +749,11 @@ int genphy_restart_aneg(struct phy_device *phydev)
> }
> EXPORT_SYMBOL(genphy_restart_aneg);
>
> +int gen10g_restart_aneg(struct phy_device *phydev)
> +{
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_restart_aneg);
>
> /**
> * genphy_config_aneg - restart auto-negotiation or write BMCR
> @@ -784,6 +796,12 @@ int genphy_config_aneg(struct phy_device *phydev)
> }
> EXPORT_SYMBOL(genphy_config_aneg);
>
> +int gen10g_config_aneg(struct phy_device *phydev)
> +{
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_config_aneg);
> +
> /**
> * genphy_update_link - update link status in @phydev
> * @phydev: target phy_device struct
> @@ -913,6 +931,34 @@ int genphy_read_status(struct phy_device *phydev)
> }
> EXPORT_SYMBOL(genphy_read_status);
>
> +int gen10g_read_status(struct phy_device *phydev)
> +{
> + int devad, reg;
> + u32 mmd_mask = phydev->c45_ids.devices_in_package;
> +
> + phydev->link = 1;
> +
> + /* For now just lie and say it's 10G all the time */
> + phydev->speed = SPEED_10000;
> + phydev->duplex = DUPLEX_FULL;
> +
> + for (devad = 0; mmd_mask; devad++, mmd_mask = mmd_mask >> 1) {
> + if (!(mmd_mask & 1))
> + continue;
> +
> + /* Read twice because link state is latched and a
> + * read moves the current state into the register
> + */
> + phy_read_mmd(phydev, devad, MDIO_STAT1);
> + reg = phy_read_mmd(phydev, devad, MDIO_STAT1);
> + if (reg < 0 || !(reg & MDIO_STAT1_LSTATUS))
> + phydev->link = 0;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_read_status);
> +
> static int genphy_config_init(struct phy_device *phydev)
> {
> int val;
> @@ -959,6 +1005,16 @@ static int genphy_config_init(struct phy_device *phydev)
>
> return 0;
> }
> +
> +static int gen10g_config_init(struct phy_device *phydev)
> +{
> + /* Temporarily just say we support everything */
> + phydev->supported = SUPPORTED_10000baseT_Full;
> + phydev->advertising = SUPPORTED_10000baseT_Full;
> +
> + return 0;
> +}
> +
> int genphy_suspend(struct phy_device *phydev)
> {
> int value;
> @@ -974,6 +1030,12 @@ int genphy_suspend(struct phy_device *phydev)
> }
> EXPORT_SYMBOL(genphy_suspend);
>
> +int gen10g_suspend(struct phy_device *phydev)
> +{
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_suspend);
> +
> int genphy_resume(struct phy_device *phydev)
> {
> int value;
> @@ -989,6 +1051,12 @@ int genphy_resume(struct phy_device *phydev)
> }
> EXPORT_SYMBOL(genphy_resume);
>
> +int gen10g_resume(struct phy_device *phydev)
> +{
> + return 0;
> +}
> +EXPORT_SYMBOL(gen10g_resume);
> +
> /**
> * phy_probe - probe and init a PHY device
> * @dev: device to probe and init
> @@ -1116,7 +1184,8 @@ void phy_drivers_unregister(struct phy_driver *drv, int n)
> }
> EXPORT_SYMBOL(phy_drivers_unregister);
>
> -static struct phy_driver genphy_driver = {
> +static struct phy_driver genphy_driver[] = {
> +{
> .phy_id = 0xffffffff,
> .phy_id_mask = 0xffffffff,
> .name = "Generic PHY",
> @@ -1127,7 +1196,18 @@ static struct phy_driver genphy_driver = {
> .suspend = genphy_suspend,
> .resume = genphy_resume,
> .driver = {.owner= THIS_MODULE, },
> -};
> +}, {
> + .phy_id = 0xffffffff,
> + .phy_id_mask = 0xffffffff,
> + .name = "Generic 10G PHY",
> + .config_init = gen10g_config_init,
> + .features = 0,
> + .config_aneg = gen10g_config_aneg,
> + .read_status = gen10g_read_status,
> + .suspend = gen10g_suspend,
> + .resume = gen10g_resume,
> + .driver = {.owner = THIS_MODULE, },
> +} };
>
> static int __init phy_init(void)
> {
> @@ -1137,7 +1217,8 @@ static int __init phy_init(void)
> if (rc)
> return rc;
>
> - rc = phy_driver_register(&genphy_driver);
> + rc = phy_drivers_register(genphy_driver,
> + ARRAY_SIZE(genphy_driver));
> if (rc)
> mdio_bus_exit();
>
> @@ -1146,7 +1227,8 @@ static int __init phy_init(void)
>
> static void __exit phy_exit(void)
> {
> - phy_driver_unregister(&genphy_driver);
> + phy_drivers_unregister(genphy_driver,
> + ARRAY_SIZE(genphy_driver));
> mdio_bus_exit();
> }
>
> --
> 1.8.4.1
>
>
--
Florian
^ permalink raw reply
* Re: [PATCH 2/5][v2] phylib: introduce PHY_INTERFACE_MODE_XGMII for 10G PHY
From: Florian Fainelli @ 2013-11-27 18:41 UTC (permalink / raw)
To: shh.xie
Cc: David Miller, jg1.han, mugunthanvnm, netdev,
linux-kernel@vger.kernel.org, Emilian.Medve, madalin.bucur
In-Reply-To: <1385459573-29092-1-git-send-email-shh.xie@gmail.com>
2013/11/26 <shh.xie@gmail.com>:
> From: Shaohui Xie <Shaohui.Xie@freescale.com>
>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> v2: update of_net.c.
>
> drivers/of/of_net.c | 1 +
> include/linux/phy.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/of/of_net.c b/drivers/of/of_net.c
> index 8f9be2e..a208a45 100644
> --- a/drivers/of/of_net.c
> +++ b/drivers/of/of_net.c
> @@ -30,6 +30,7 @@ static const char *phy_modes[] = {
> [PHY_INTERFACE_MODE_RGMII_TXID] = "rgmii-txid",
> [PHY_INTERFACE_MODE_RTBI] = "rtbi",
> [PHY_INTERFACE_MODE_SMII] = "smii",
> + [PHY_INTERFACE_MODE_XGMII] = "xgmii",
> };
>
> /**
> diff --git a/include/linux/phy.h b/include/linux/phy.h
> index 2549b42..2606599 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -66,6 +66,7 @@ typedef enum {
> PHY_INTERFACE_MODE_RGMII_TXID,
> PHY_INTERFACE_MODE_RTBI,
> PHY_INTERFACE_MODE_SMII,
> + PHY_INTERFACE_MODE_XGMII,
> } phy_interface_t;
>
>
> --
> 1.8.4.1
>
>
--
Florian
^ permalink raw reply
* Re: [PATCH 1/8] net: smc91x: Fix device tree based configuration so it's usable
From: Tony Lindgren @ 2013-11-27 18:36 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org,
Nicolas Pitre, David S. Miller, netdev@vger.kernel.org,
devicetree@vger.kernel.org
In-Reply-To: <20131116151640.GJ10317@atomide.com>
* Tony Lindgren <tony@atomide.com> [131116 07:17]:
>
> Here's what I was thinking with the reg-io-width-mask. Anybody
> have comments on using reg-io-width vs reg-io-width-mask?
...
> --- a/drivers/net/ethernet/smsc/smc91x.c
> +++ b/drivers/net/ethernet/smsc/smc91x.c
> @@ -2222,11 +2234,31 @@ static int smc_drv_probe(struct platform_device *pdev)
> */
>
> lp = netdev_priv(ndev);
> + lp->cfg.flags = 0;
>
> if (pd) {
> memcpy(&lp->cfg, pd, sizeof(lp->cfg));
> lp->io_shift = SMC91X_IO_SHIFT(lp->cfg.flags);
> - } else {
> + }
> +
> +#if IS_BUILTIN(CONFIG_OF)
> + match = of_match_device(of_match_ptr(smc91x_match), &pdev->dev);
> + if (match) {
> + u32 val;
> +
> + of_property_read_u32(np, "reg-io-width", &val);
> + if (val == 0)
> + lp->cfg.flags |= SMC91X_USE_16BIT;
> + if (val & 1)
> + lp->cfg.flags |= SMC91X_USE_8BIT;
> + if (val & 2)
> + lp->cfg.flags |= SMC91X_USE_16BIT;
> + if (val & 4)
> + lp->cfg.flags |= SMC91X_USE_32BIT;
> + }
> +#endif
> +
> + if (!pd && !match) {
> lp->cfg.flags |= (SMC_CAN_USE_8BIT) ? SMC91X_USE_8BIT : 0;
> lp->cfg.flags |= (SMC_CAN_USE_16BIT) ? SMC91X_USE_16BIT : 0;
> lp->cfg.flags |= (SMC_CAN_USE_32BIT) ? SMC91X_USE_32BIT : 0;
Looks this patch is missing the check for the return value for
of_property_read_u32(), will repost this patch separately as the
others in this series are out of the way now.
Regards,
Tony
^ permalink raw reply
* Re: r8169 Wake on Lan
From: Pablo Cholaky @ 2013-11-27 18:32 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
In-Reply-To: <20131126235727.GA8466@electric-eye.fr.zoreil.com>
That's the logic:
- If I turn off my PC with WOL disabled using ethtool, WOL will be
disabled (normal off, suspend to disk and suspend to RAM).
- If I turn on my PC, WOL will always be turned on (including from
suspend to disk and suspend to RAM)
A problem with S states you think?
^ permalink raw reply
* Re: [Pv-drivers] [PATCH] net: vmxnet3: remove unnecessary pci_set_drvdata()
From: Dmitry Torokhov @ 2013-11-27 18:27 UTC (permalink / raw)
To: pv-drivers
Cc: Jingoo Han, 'David S. Miller', 'Aditya Sarwade',
netdev
In-Reply-To: <001701cee982$cd4cdd30$67e69790$%han@samsung.com>
On Monday, November 25, 2013 11:05:23 AM Jingoo Han wrote:
> The driver core clears the driver data to NULL after device_release
> or on probe failure. Thus, it is not needed to manually clear the
> device driver data to NULL.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Dmitry Torokhov <dtor@vmware.com>
> ---
> drivers/net/vmxnet3/vmxnet3_drv.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c
> b/drivers/net/vmxnet3/vmxnet3_drv.c index 7e2788c..a300a18 100644
> --- a/drivers/net/vmxnet3/vmxnet3_drv.c
> +++ b/drivers/net/vmxnet3/vmxnet3_drv.c
> @@ -3132,7 +3132,6 @@ err_alloc_queue_desc:
> err_alloc_shared:
> dma_unmap_single(&adapter->pdev->dev, adapter->adapter_pa,
> sizeof(struct vmxnet3_adapter), PCI_DMA_TODEVICE);
> - pci_set_drvdata(pdev, NULL);
> free_netdev(netdev);
> return err;
> }
^ permalink raw reply
* Re: Kernel Panic in IPv6 vxlan
From: Stephen Hemminger @ 2013-11-27 16:32 UTC (permalink / raw)
To: Ryan Whelan; +Cc: Fan Du, netdev, amwang
In-Reply-To: <CAM3m09SXK1VDv+0JAQfpxjO2G=pJZzVEPNz=WbmXPQAjhALhyA@mail.gmail.com>
On Wed, 27 Nov 2013 09:44:03 -0500
Ryan Whelan <rcwhelan@gmail.com> wrote:
> That isn't required with IPv4- if you don't specify an interface with
> IPv4, it looks like the system will route the multicast traffic via
> routing. Is this not an option with IPv6? I might be
> misunderstanding something?
>
> thanks
>
> On Wed, Nov 27, 2013 at 3:25 AM, Fan Du <fan.du@windriver.com> wrote:
> > Hallo,
> >
> >
> > On 2013年11月27日 05:41, Ryan Whelan wrote:
> >>
> >> I'm not sure if this is the right place to report this- please correct
> >> me if I'm mistaken.
> >>
> >> When creating a vxlan interface with an IPv6 multicast group but not
> >> specifying an underlying device, the kernel panics when the vxlan
> >> interface is brought up. This doesn't happen with an IPv4 multicast
> >> group. Linux 3.12.1 x86_64
> >>
> >> `ip link add vxlan0 type vxlan id 42 group ff0e::110`
> >
> >
> > You forgot to attach vxlan0 to a physical netdev ;) try:
> >
> > ip link add vxlan0 type vxlan id 42 group ff0e::110 dev ethX
> >
> > This will work anyway.
> >
> > --
> > 浮沉随浪只记今朝笑
> >
> > --fan fan
> --
Yes, this is a bug in the IPv6 implementation.
^ permalink raw reply
* [PATCH 2/2] virtio-net: make all RX paths handle erors consistently
From: Michael S. Tsirkin @ 2013-11-27 16:31 UTC (permalink / raw)
To: linux-kernel; +Cc: Michael Dalton, netdev, virtualization, Eric Dumazet
In-Reply-To: <1385569684-26595-1-git-send-email-mst@redhat.com>
receive mergeable now handles errors internally.
Do same for big and small packet paths, otherwise
the logic is too hard to follow.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
While I can't point at a bug this fixes, I'm not sure
there's no bug in the existing logic.
So not exactly a bug fix bug I think it's justified for net.
drivers/net/virtio_net.c | 53 +++++++++++++++++++++++++++++++++---------------
1 file changed, 37 insertions(+), 16 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 0e6ea69..97c6212 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -299,6 +299,35 @@ static struct sk_buff *page_to_skb(struct receive_queue *rq,
return skb;
}
+static struct sk_buff *receive_small(void *buf, unsigned int len)
+{
+ struct sk_buff * skb = buf;
+
+ len -= sizeof(struct virtio_net_hdr);
+ skb_trim(skb, len);
+
+ return skb;
+}
+
+static struct sk_buff *receive_big(struct net_device *dev,
+ struct receive_queue *rq,
+ void *buf,
+ unsigned int len)
+{
+ struct page *page = buf;
+ struct sk_buff *skb = page_to_skb(rq, page, 0, len, PAGE_SIZE);
+
+ if (unlikely(!skb))
+ goto err;
+
+ return skb;
+
+err:
+ dev->stats.rx_dropped++;
+ give_pages(rq, page);
+ return NULL;
+}
+
static struct sk_buff *receive_mergeable(struct net_device *dev,
struct receive_queue *rq,
void *buf,
@@ -407,23 +436,15 @@ static void receive_buf(struct receive_queue *rq, void *buf, unsigned int len)
return;
}
- if (!vi->mergeable_rx_bufs && !vi->big_packets) {
- skb = buf;
- len -= sizeof(struct virtio_net_hdr);
- skb_trim(skb, len);
- } else if (vi->mergeable_rx_bufs) {
+ if (vi->mergeable_rx_bufs)
skb = receive_mergeable(dev, rq, buf, len);
- if (unlikely(!skb))
- return;
- } else {
- page = buf;
- skb = page_to_skb(rq, page, 0, len, PAGE_SIZE);
- if (unlikely(!skb)) {
- dev->stats.rx_dropped++;
- give_pages(rq, page);
- return;
- }
- }
+ else if (vi->big_packets)
+ skb = receive_big(dev, rq, buf, len);
+ else
+ skb = receive_small(buf, len);
+
+ if (unlikely(!skb))
+ return;
hdr = skb_vnet_hdr(skb);
--
MST
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox