* Re: Null pointer dereference in nl80211_set_reg
From: Ben Hutchings @ 2013-08-22 16:04 UTC (permalink / raw)
To: udo; +Cc: Linux Kernel Mailing List, Linux Network Mailing List
In-Reply-To: <20130822174121.18441b7f@x220>
On Thu, 2013-08-22 at 17:41 +0200, Udo Steinberg wrote:
> Hi all,
>
> I'm running Linux 3.10.7 and have encountered the following NULL pointer
> dereference. So far it has only occurred once, so I cannot reproduce the
> circumstances that cause the problem.
>
> Please keep me on CC: as I'm not subscribed to LKML.
[...]
Probably fixed by:
commit c319d50bfcf678c2857038276d9fab3c6646f3bf
Author: Johannes Berg <johannes.berg@intel.com>
Date: Tue Jul 30 22:34:28 2013 +0200
nl80211: fix another nl80211_fam.attrbuf race
which went into 3.10.8.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 1/2] net/cadence/macb: add support for dt phy definition
From: boris brezillon @ 2013-08-22 16:00 UTC (permalink / raw)
To: Florian Fainelli
Cc: Boris BREZILLON, Nicolas Ferre, Rob Herring, Pawel Moll,
Mark Rutland, Stephen Warren, Ian Campbell, Russell King, netdev,
linux-kernel, linux-arm-kernel, devicetree
In-Reply-To: <1377187048-21944-1-git-send-email-b.brezillon@overkiz.com>
Hello Florian,
On 22/08/2013 17:57, Boris BREZILLON wrote:
> The macb driver only handle PHY description through platform_data
> (macb_platform_data).
> Thus, when using dt you cannot define phy properties like phy address or
> phy irq pin.
>
> This patch makes use of the of_mdiobus_register to add support for
> phy device definition using dt.
> A fallback to the autoscan procedure is added in case there is no phy
> devices defined in dt.
>
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
> ---
> drivers/net/ethernet/cadence/macb.c | 41 +++++++++++++++++++++++++++++------
> 1 file changed, 34 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
> index e866608..fe06ab0 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -27,6 +27,7 @@
> #include <linux/phy.h>
> #include <linux/of.h>
> #include <linux/of_device.h>
> +#include <linux/of_mdio.h>
> #include <linux/of_net.h>
> #include <linux/pinctrl/consumer.h>
>
> @@ -314,6 +315,7 @@ static int macb_mii_probe(struct net_device *dev)
> int macb_mii_init(struct macb *bp)
> {
> struct macb_platform_data *pdata;
> + struct device_node *np;
> int err = -ENXIO, i;
>
> /* Enable management port */
> @@ -335,21 +337,46 @@ int macb_mii_init(struct macb *bp)
> bp->mii_bus->parent = &bp->dev->dev;
> pdata = bp->pdev->dev.platform_data;
>
> - if (pdata)
> - bp->mii_bus->phy_mask = pdata->phy_mask;
> -
> bp->mii_bus->irq = kmalloc(sizeof(int)*PHY_MAX_ADDR, GFP_KERNEL);
> if (!bp->mii_bus->irq) {
> err = -ENOMEM;
> goto err_out_free_mdiobus;
> }
>
> - for (i = 0; i < PHY_MAX_ADDR; i++)
> - bp->mii_bus->irq[i] = PHY_POLL;
> -
> dev_set_drvdata(&bp->dev->dev, bp->mii_bus);
>
> - if (mdiobus_register(bp->mii_bus))
> + np = bp->pdev->dev.of_node;
> + if (np) {
> + /* try dt phy registration */
> + err = of_mdiobus_register(bp->mii_bus, np);
> +
> + /* fallback to standard phy registration if no phy were
> + found during dt phy registration */
> + if (!err && !phy_find_first(bp->mii_bus)) {
> + for (i = 0; i < PHY_MAX_ADDR; i++) {
> + struct phy_device *phydev;
> +
> + phydev = mdiobus_scan(bp->mii_bus, i);
> + if (IS_ERR(phydev)) {
> + err = PTR_ERR(phydev);
> + break;
> + }
> + }
> +
This is were I need the mdiobus_full_scan function.
> + if (err)
> + goto err_out_unregister_bus;
> + }
> + } else {
> + for (i = 0; i < PHY_MAX_ADDR; i++)
> + bp->mii_bus->irq[i] = PHY_POLL;
> +
> + if (pdata)
> + bp->mii_bus->phy_mask = pdata->phy_mask;
> +
> + err = mdiobus_register(bp->mii_bus);
> + }
> +
> + if (err)
> goto err_out_free_mdio_irq;
>
> if (macb_mii_probe(bp->dev) != 0) {
^ permalink raw reply
* [PATCH 2/2] ARM: at91/dt: define phy available on sama5d3 mother board
From: Boris BREZILLON @ 2013-08-22 15:58 UTC (permalink / raw)
To: Nicolas Ferre, Rob Herring, Pawel Moll, Mark Rutland,
Stephen Warren, Ian Campbell, Russell King, Florian Fainelli
Cc: netdev, linux-kernel, linux-arm-kernel, devicetree,
Boris BREZILLON
In-Reply-To: <1377186980-21902-1-git-send-email-b.brezillon@overkiz.com>
This patch describe the phy used on atmel sama5d3 mother board:
- phy address
- phy interrupt pin
Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
---
arch/arm/boot/dts/sama5d3xmb.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sama5d3xmb.dtsi b/arch/arm/boot/dts/sama5d3xmb.dtsi
index 8a9e05d..e9521d5 100644
--- a/arch/arm/boot/dts/sama5d3xmb.dtsi
+++ b/arch/arm/boot/dts/sama5d3xmb.dtsi
@@ -81,6 +81,14 @@
macb1: ethernet@f802c000 {
phy-mode = "rmii";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy0: ethernet-phy@0 {
+ interrupt-parent = <&pioE>;
+ interrupts = <30 IRQ_TYPE_EDGE_FALLING>;
+ reg = <1>;
+ };
};
pinctrl@fffff200 {
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] net/cadence/macb: add support for dt phy definition
From: Boris BREZILLON @ 2013-08-22 15:57 UTC (permalink / raw)
To: Nicolas Ferre, Rob Herring, Pawel Moll, Mark Rutland,
Stephen Warren, Ian Campbell, Russell King, Florian Fainelli
Cc: netdev, linux-kernel, linux-arm-kernel, devicetree,
Boris BREZILLON
In-Reply-To: <1377186980-21902-1-git-send-email-b.brezillon@overkiz.com>
The macb driver only handle PHY description through platform_data
(macb_platform_data).
Thus, when using dt you cannot define phy properties like phy address or
phy irq pin.
This patch makes use of the of_mdiobus_register to add support for
phy device definition using dt.
A fallback to the autoscan procedure is added in case there is no phy
devices defined in dt.
Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
---
drivers/net/ethernet/cadence/macb.c | 41 +++++++++++++++++++++++++++++------
1 file changed, 34 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index e866608..fe06ab0 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -27,6 +27,7 @@
#include <linux/phy.h>
#include <linux/of.h>
#include <linux/of_device.h>
+#include <linux/of_mdio.h>
#include <linux/of_net.h>
#include <linux/pinctrl/consumer.h>
@@ -314,6 +315,7 @@ static int macb_mii_probe(struct net_device *dev)
int macb_mii_init(struct macb *bp)
{
struct macb_platform_data *pdata;
+ struct device_node *np;
int err = -ENXIO, i;
/* Enable management port */
@@ -335,21 +337,46 @@ int macb_mii_init(struct macb *bp)
bp->mii_bus->parent = &bp->dev->dev;
pdata = bp->pdev->dev.platform_data;
- if (pdata)
- bp->mii_bus->phy_mask = pdata->phy_mask;
-
bp->mii_bus->irq = kmalloc(sizeof(int)*PHY_MAX_ADDR, GFP_KERNEL);
if (!bp->mii_bus->irq) {
err = -ENOMEM;
goto err_out_free_mdiobus;
}
- for (i = 0; i < PHY_MAX_ADDR; i++)
- bp->mii_bus->irq[i] = PHY_POLL;
-
dev_set_drvdata(&bp->dev->dev, bp->mii_bus);
- if (mdiobus_register(bp->mii_bus))
+ np = bp->pdev->dev.of_node;
+ if (np) {
+ /* try dt phy registration */
+ err = of_mdiobus_register(bp->mii_bus, np);
+
+ /* fallback to standard phy registration if no phy were
+ found during dt phy registration */
+ if (!err && !phy_find_first(bp->mii_bus)) {
+ for (i = 0; i < PHY_MAX_ADDR; i++) {
+ struct phy_device *phydev;
+
+ phydev = mdiobus_scan(bp->mii_bus, i);
+ if (IS_ERR(phydev)) {
+ err = PTR_ERR(phydev);
+ break;
+ }
+ }
+
+ if (err)
+ goto err_out_unregister_bus;
+ }
+ } else {
+ for (i = 0; i < PHY_MAX_ADDR; i++)
+ bp->mii_bus->irq[i] = PHY_POLL;
+
+ if (pdata)
+ bp->mii_bus->phy_mask = pdata->phy_mask;
+
+ err = mdiobus_register(bp->mii_bus);
+ }
+
+ if (err)
goto err_out_free_mdio_irq;
if (macb_mii_probe(bp->dev) != 0) {
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/2] net/cadence/macb: add support for dt phy definition
From: Boris BREZILLON @ 2013-08-22 15:56 UTC (permalink / raw)
To: Nicolas Ferre, Rob Herring, Pawel Moll, Mark Rutland,
Stephen Warren, Ian Campbell, Russell King, Florian Fainelli
Cc: netdev, linux-kernel, linux-arm-kernel, devicetree,
Boris BREZILLON
Hello,
This patch series adds support for ethernet phy definition using device
tree.
This may help in moving some at91 boards to dt (some of them define an
interrupt pin).
Tested on samad31ek.
Best Regards,
Boris
Boris BREZILLON (2):
net/cadence/macb: add support for dt phy definition
ARM: at91/dt: define phy available on sama5d3 mother board
arch/arm/boot/dts/sama5d3xmb.dtsi | 8 +++++++
drivers/net/ethernet/cadence/macb.c | 41 +++++++++++++++++++++++++++++------
2 files changed, 42 insertions(+), 7 deletions(-)
--
1.7.9.5
^ permalink raw reply
* Null pointer dereference in nl80211_set_reg
From: Udo Steinberg @ 2013-08-22 15:41 UTC (permalink / raw)
To: Linux Kernel Mailing List, Linux Network Mailing List
[-- Attachment #1: Type: text/plain, Size: 3580 bytes --]
Hi all,
I'm running Linux 3.10.7 and have encountered the following NULL pointer
dereference. So far it has only occurred once, so I cannot reproduce the
circumstances that cause the problem.
Please keep me on CC: as I'm not subscribed to LKML.
Cheers,
Udo
cfg80211: Calling CRDA for country: DE
cfg80211: Regulatory domain changed to country: DE
cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
cfg80211: (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
cfg80211: (5150000 KHz - 5350000 KHz @ 40000 KHz), (N/A, 2000 mBm)
cfg80211: (5470000 KHz - 5725000 KHz @ 40000 KHz), (N/A, 2698 mBm)
wlan0: Limiting TX power to 18 (20 - 2) dBm as advertised by 00:24:6c:2b:18:22
wlan0: authenticate with 00:24:6c:2b:17:32
wlan0: send auth to 00:24:6c:2b:17:32 (try 1/3)
cfg80211: Calling CRDA to update world regulatory domain
wlan0: authenticated
wlan0: waiting for beacon from 00:24:6c:2b:17:32
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<ffffffff8140d989>] nl80211_set_reg+0xcc/0x1ff
PGD 20177e067 PUD 2127c6067 PMD 0
Oops: 0000 [#1] PREEMPT SMP
CPU: 2 PID: 2465 Comm: crda Not tainted 3.10.7 #1
Hardware name: LENOVO 4290W4H/4290W4H, BIOS 8DET69WW (1.39 ) 07/18/2013
task: ffff880214ecd040 ti: ffff880212764000 task.ti: ffff880212764000
RIP: 0010:[<ffffffff8140d989>] [<ffffffff8140d989>] nl80211_set_reg+0xcc/0x1ff
RSP: 0018:ffff880212765ab8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff880214f8f6c0 RCX: 0000000000000000
RDX: ffff88021d002348 RSI: 0000000000000012 RDI: 0000000000000000
RBP: ffff880214f8f6c0 R08: ffff880214f8f6c0 R09: ffff880214413014
R10: 0001000800000034 R11: 0002000800000180 R12: 0000000000000000
R13: ffff880212765b28 R14: ffff880214413014 R15: ffff880214413000
FS: 00007fa95007b740(0000) GS:ffff88021e280000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000001f649f000 CR4: 00000000000407e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Stack:
0000000000000000 ffff88021441301c 0000000000000108 ffff880215560000
00000000000000b4 ffffffff811945d7 ffffffff8167ca80 ffffffff8185b6c0
ffffffff8185ab58 ffff880215560000 ffff880214eb9ec0 0000000000000004
Call Trace:
[<ffffffff811945d7>] ? nla_parse+0x8b/0xb4
[<ffffffff813beda3>] ? genl_rcv_msg+0x1be/0x230
[<ffffffff813bebe5>] ? genl_unlock_all+0x11/0x11
[<ffffffff813bea1e>] ? netlink_rcv_skb+0x40/0x89
[<ffffffff8139ec22>] ? __kmalloc_reserve.isra.31+0x1e/0x56
[<ffffffff813beb9e>] ? genl_rcv+0x1f/0x2c
[<ffffffff813bd960>] ? netlink_unicast+0xe5/0x16b
[<ffffffff813bdf7a>] ? netlink_sendmsg+0x275/0x2b6
[<ffffffff81399926>] ? sock_sendmsg+0x6d/0x80
[<ffffffff81087ece>] ? __alloc_pages_nodemask+0xe9/0x773
[<ffffffff810829b5>] ? find_get_page+0x6b/0x73
[<ffffffff81399ab6>] ? ___sys_sendmsg+0x17d/0x1f4
[<ffffffff8109b90f>] ? handle_pte_fault+0x125/0x687
[<ffffffff81020585>] ? __do_page_fault+0x2cd/0x3b9
[<ffffffff8100a3b7>] ? syscall_trace_leave+0xe0/0xe9
[<ffffffff8139aa60>] ? __sys_sendmsg+0x39/0x5a
[<ffffffff8145bf89>] ? tracesys+0xd0/0xd5
Code: 8a 46 04 88 43 14 41 8a 46 05 88 43 15 e8 4b b5 ff ff 84 c0 74 04 44 88 63 16 49 8b 45 20 48 89 dd 45 31 e4 48 8b 80 10 01 00 00 <44> 0f b7 30 4c 8d 68 04 41 83 ee 04 41 83 fe 03 0f 8e c1 00 00
RIP [<ffffffff8140d989>] nl80211_set_reg+0xcc/0x1ff
RSP <ffff880212765ab8>
CR2: 0000000000000000
---[ end trace 2ba935cb5e4d0137 ]---
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] phylib: mdio: handle register/unregister/register sequence
From: boris brezillon @ 2013-08-22 15:38 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: David S. Miller, Mark Brown, Nick Bowler, Grant Likely, netdev,
linux-kernel, linux-arm-kernel
In-Reply-To: <20130822152757.GA23163@kroah.com>
On 22/08/2013 17:27, Greg Kroah-Hartman wrote:
> On Thu, Aug 22, 2013 at 02:33:56PM +0200, Boris BREZILLON wrote:
>> Hello,
>>
>> This patch is a proposal to support the register/unregister/register
>> sequence on a given mdio bus.
>>
>> I use the register/unregister/register sequence to add a fallback when the
>> of_mdiobus_register (this function calls mdiobus_register with phy_mask
>> set to ~0) does not register any phy device (because the device tree does
>> not define any phy).
>> In this case I call mdiobus_unregister and then call mdiobus_register with
>> a phy_mask set to 0 to trigger a full mdio bus scan.
>>
>> I'm not sure this is the right way to do it (this is why I added RFC in the
>> subject).
>>
>> Could someone help me figuring out what I should use to implement my fallback ?
>>
>> 1) use the register/unregister/register sequence
> That will not work. Well, you might think it would work, but then
> things randomly start breaking later on. Try it with the
> KOBJECT_DELAYED_DESTROY build option in linux-next, and watch things go
> "boom" :)
>
> The rule is, you should never register a kobject/struct device that you
> have previously unregistered before, as you really don't know if
> unregistering has finished or not.
Thanks for your answer.
>
> sorry,
>
> greg k-h
^ permalink raw reply
* Re: [RFC] phy: micrel: Convert micrel PHY driver to use OF
From: Dinh Nguyen @ 2013-08-22 15:30 UTC (permalink / raw)
To: Sascha Hauer
Cc: Olof Johansson, dinh.linux, netdev, Richard Cochran,
Linus Walleij, Felipe Balbi, David S. Miller, Giuseppe Cavallaro,
Rob Herring, devicetree
In-Reply-To: <20130822063448.GS31036@pengutronix.de>
On Thu, 2013-08-22 at 08:34 +0200, Sascha Hauer wrote:
> On Wed, Aug 21, 2013 at 10:13:47PM -0700, Olof Johansson wrote:
> > (adding devicetree@vger.kernel.org)
> >
> >
> > On Tue, Aug 13, 2013 at 11:42:36AM -0500, dinguyen@altera.com wrote:
> > > ---
> > > Hello,
> > >
> > > I would like to solicit comments on the need to convert the ethernet PHY
> > > drivers to use OF/device trees? For the platform that I'm interested in,
> > > SOCFPGA, it is using the stmicro ethernet driver. It has a Micrel PHY
> > > on the board. The only way that I know of how to change the skew settings
> > > for the phy is through a board level initialization.
> > >
> > > One of the ARM maintainers suggested that perhaps refactoring the ethernet
> > > driver to use device tree would be nice. But that would not help me with
> > > configuring the PHY settings.
> > >
> > > So a little investigation led me to believe that refactoring the /net/phy
> > > drivers into a device tree implementation would help greatly. I was thinking
> > > it could be done like the pinctrl or some of the usb/phy driver.
> > >
> > > Since I am only familiar with the ARM SoC space, I want to make sure that
> > > this idea is right approach. I can start with the micrel PHY driver
> > > first, as that is the only HW I have access to.
> >
> > Hi,
> >
> > Sorry for the slow reply here.
> >
> > I don't think this is quite the right approach.
> >
> > What you want to do is to make the phy devices register based on device tree
> > contents, which also means removing the run function, or rather moving it to
> > a generic run function in the phy subsystem that acts based on device tree
> > contents instead of a hard-coded per-board run function.
> >
> > It sounds like defining that binding might end up getting complicated.
> > I suggest you consider recruiting some of the more seasoned devicetree folks on
> > this endeavor.
> >
> > It's possible that you'll mostly have per-vendor/phy type properties to tune
> > the various settings, but it's also likely that you will have some generic and
> > shared (optional) properties such as gpios for resetting, or regulators for
> > powering, the phy.
>
> This patch recently was merged:
>
> http://patchwork.ozlabs.org/patch/268661/
>
> It solves exactly the same problem of specifying the skew settings.
Thanks for the information. This is great stuff!
Dinh
>
> Sascha
>
^ permalink raw reply
* Re: [RFC PATCH] phylib: mdio: handle register/unregister/register sequence
From: Greg Kroah-Hartman @ 2013-08-22 15:27 UTC (permalink / raw)
To: Boris BREZILLON
Cc: David S. Miller, Mark Brown, Nick Bowler, Grant Likely, netdev,
linux-kernel, linux-arm-kernel
In-Reply-To: <1377174836-10569-1-git-send-email-b.brezillon@overkiz.com>
On Thu, Aug 22, 2013 at 02:33:56PM +0200, Boris BREZILLON wrote:
> Hello,
>
> This patch is a proposal to support the register/unregister/register
> sequence on a given mdio bus.
>
> I use the register/unregister/register sequence to add a fallback when the
> of_mdiobus_register (this function calls mdiobus_register with phy_mask
> set to ~0) does not register any phy device (because the device tree does
> not define any phy).
> In this case I call mdiobus_unregister and then call mdiobus_register with
> a phy_mask set to 0 to trigger a full mdio bus scan.
>
> I'm not sure this is the right way to do it (this is why I added RFC in the
> subject).
>
> Could someone help me figuring out what I should use to implement my fallback ?
>
> 1) use the register/unregister/register sequence
That will not work. Well, you might think it would work, but then
things randomly start breaking later on. Try it with the
KOBJECT_DELAYED_DESTROY build option in linux-next, and watch things go
"boom" :)
The rule is, you should never register a kobject/struct device that you
have previously unregistered before, as you really don't know if
unregistering has finished or not.
sorry,
greg k-h
^ permalink raw reply
* Re: [PATCH net-next] net: sctp_probe: simplify code by using %pISc format specifier
From: Neil Horman @ 2013-08-22 15:26 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, netdev, linux-sctp
In-Reply-To: <1377184370-13721-1-git-send-email-dborkman@redhat.com>
On Thu, Aug 22, 2013 at 05:12:50PM +0200, Daniel Borkmann wrote:
> We can simply use the %pISc format specifier that was recently added
> and thus remove some code that distinguishes between IPv4 and IPv6.
>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> ---
> net/sctp/probe.c | 9 ++-------
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/net/sctp/probe.c b/net/sctp/probe.c
> index e62c225..cd72ae5 100644
> --- a/net/sctp/probe.c
> +++ b/net/sctp/probe.c
> @@ -155,13 +155,8 @@ static sctp_disposition_t jsctp_sf_eat_sack(struct net *net,
> if (sp == asoc->peer.primary_path)
> printl("*");
>
> - if (sp->ipaddr.sa.sa_family == AF_INET)
> - printl("%pI4 ", &sp->ipaddr.v4.sin_addr);
> - else
> - printl("%pI6 ", &sp->ipaddr.v6.sin6_addr);
> -
> - printl("%2u %8u %8u %8u %8u %8u ",
> - sp->state, sp->cwnd, sp->ssthresh,
> + printl("%pISc %2u %8u %8u %8u %8u %8u ",
> + &sp->ipaddr, sp->state, sp->cwnd, sp->ssthresh,
> sp->flight_size, sp->partial_bytes_acked,
> sp->pathmtu);
> }
> --
> 1.7.11.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* [PATCH net-next] net: sctp_probe: simplify code by using %pISc format specifier
From: Daniel Borkmann @ 2013-08-22 15:12 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-sctp
We can simply use the %pISc format specifier that was recently added
and thus remove some code that distinguishes between IPv4 and IPv6.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
---
net/sctp/probe.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/net/sctp/probe.c b/net/sctp/probe.c
index e62c225..cd72ae5 100644
--- a/net/sctp/probe.c
+++ b/net/sctp/probe.c
@@ -155,13 +155,8 @@ static sctp_disposition_t jsctp_sf_eat_sack(struct net *net,
if (sp == asoc->peer.primary_path)
printl("*");
- if (sp->ipaddr.sa.sa_family == AF_INET)
- printl("%pI4 ", &sp->ipaddr.v4.sin_addr);
- else
- printl("%pI6 ", &sp->ipaddr.v6.sin6_addr);
-
- printl("%2u %8u %8u %8u %8u %8u ",
- sp->state, sp->cwnd, sp->ssthresh,
+ printl("%pISc %2u %8u %8u %8u %8u %8u ",
+ &sp->ipaddr, sp->state, sp->cwnd, sp->ssthresh,
sp->flight_size, sp->partial_bytes_acked,
sp->pathmtu);
}
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH net] skge: dma_sync the whole receive buffer
From: poma @ 2013-08-22 14:46 UTC (permalink / raw)
To: Greg KH; +Cc: Stephen Hemminger, David Miller, netdev, Linus Torvalds
In-Reply-To: <20130822040041.GA4821@kroah.com>
Then out spake brave Horatius,
The Captain of the Gate:
"To every man upon this earth
Death cometh soon or late.
And how can man die better
Than facing fearful odds,
For the ashes of his fathers,
And the temples of his Gods."
poma
^ permalink raw reply
* Re: [PATCH 3/4] e1000e: Calculate the desc_len based on adapter type
From: Wei Yang @ 2013-08-22 14:26 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: e1000-devel@lists.sourceforge.net, netdev
In-Reply-To: <CAL3LdT4K03_4sWWFuTer0TU4nY_sqbSyjK6ETxF14kijZzmkgQ@mail.gmail.com>
Jeff,
Thanks for letting me know this.
Setting MTU is not tested, maybe this patch introduce some problem in this
case. Sorry for breaking your driver :-(
On Thu, Aug 22, 2013 at 03:57:24AM -0700, Jeff Kirsher wrote:
>Validation ran into issues with this patch and because we could not apply patch
>4 in this series without patch 3, I have had to drop patch 3 & 4 from my
>queue.
>
>Here is what validation had to say about this patch...
>
>Aaron Brown wrote:
>This patch introduces a call trace when the interface is up and then the mtu is
>set over 1500, or if the mtu is set above 1500 when the interface is down,
>the call trace appears when the interface is brought up. The trace is captured
>to demsg and /var/log/messages:
>---------------------------------------------------
>17:14:52 u1307 kernel: Call Trace:
>17:14:52 u1307 kernel: [<ffffffff813ffaeb>] dump_stack+0x19/0x1e
>17:14:52 u1307 kernel: [<ffffffff8104ae80>] __might_sleep+0xe2/0xe4
>17:14:52 u1307 kernel: [<ffffffff81400e63>] down_read+0x1f/0x31
>17:14:52 u1307 kernel: [<ffffffff8102c1b7>] exit_mm+0x3a/0x164
>17:14:52 u1307 kernel: [<ffffffff8102da09>] do_exit+0x1ef/0x2f7
>17:14:52 u1307 kernel: [<ffffffff81403bce>] oops_end+0x8f/0x94
>17:14:52 u1307 kernel: [<ffffffff81020ca5>] no_context+0x1a4/0x1b3
>17:14:52 u1307 kernel: [<ffffffff81020e6c>] __bad_area_nosemaphore+0x1b8/0x1d8
>17:14:52 u1307 kernel: [<ffffffff81020e9a>] bad_area_nosemaphore+0xe/0x10
>17:14:52 u1307 kernel: [<ffffffff81405a69>] __do_page_fault+0x44f/0x48e
>17:14:52 u1307 kernel: [<ffffffff81004494>] ? print_context_stack+0xa2/0xbe
>17:14:52 u1307 kernel: [<ffffffff81003488>] ? dump_trace+0x282/0x2aa
>17:14:52 u1307 kernel: [<ffffffff81402bf0>] ? _raw_spin_unlock_irqrestore+0x1d/
>0x3a
>17:14:52 u1307 kernel: [<ffffffff81405ab1>] do_page_fault+0x9/0xb
>17:14:52 u1307 kernel: [<ffffffff814031e2>] page_fault+0x22/0x30
>17:14:52 u1307 kernel: [<ffffffffa00238ef>] ? e1000_alloc_rx_buffers_ps+0x1d9/
>0x421 [e1000e]
>17:14:52 u1307 kernel: [<ffffffffa00238a3>] ? e1000_alloc_rx_buffers_ps+0x18d/
>0x421 [e1000e]
>17:14:52 u1307 kernel: [<ffffffffa0022bd6>] e1000_configure+0xe7/0xf0 [e1000e]
>17:14:52 u1307 kernel: [<ffffffffa0022bee>] e1000e_up+0xf/0xe7 [e1000e]
>17:14:52 u1307 kernel: [<ffffffffa00282da>] e1000_change_mtu+0x142/0x162
>[e1000e]
>17:14:52 u1307 kernel: [<ffffffff8135a98b>] dev_set_mtu+0x3f/0x5e
>17:14:52 u1307 kernel: [<ffffffff81369280>] dev_ifsioc+0xec/0x329
>17:14:52 u1307 kernel: [<ffffffff81369a24>] dev_ioctl+0x309/0x3bd
>17:14:52 u1307 kernel: [<ffffffff81348035>] sock_ioctl+0x21e/0x22b
>17:14:52 u1307 kernel: [<ffffffff810ce1b4>] do_vfs_ioctl+0x28e/0x2aa
>17:14:52 u1307 kernel: [<ffffffff810ce217>] SyS_ioctl+0x47/0x69
>17:14:52 u1307 kernel: [<ffffffff81407b12>] system_call_fastpath+0x16/0x1b
>17:14:52 u1307 kernel: ------------[ cut here ]------------
>17:14:52 u1307 kernel: WARNING: at kernel/softirq.c:160
>local_bh_enable_ip+0x3c/0x9a()
>17:14:52 u1307 kernel: Modules linked in: bridge stp llc nfsd lockd exportfs
>sunrpc e1000e ptp pps_core
>17:14:52 u1307 kernel: CPU: 6 PID: 5289 Comm: ifconfig Tainted: G D
>3.10.0-rc1_net-next_e1000e_2850dce_regress-11638-gb471f26 #5
>17:14:52 u1307 kernel: Hardware name: Supermicro X9SCL/X9SCM/X9SCL/X9SCM, BIOS
>2.0b 09/17/2012
>17:14:52 u1307 kernel: ffffffff816e7023 ffff880222b2b808 ffffffff813ffaeb
>ffff880222b2b848
>17:14:52 u1307 kernel: ffffffff810287e6 ffffffff81a25188 0000000000000000
>ffff880221f91bc0
>17:14:52 u1307 kernel: ffff880221f91dd8 ffff880221f91f70 0000000000000000
>ffff880222b2b858
>-------------------------------------------------------------------------------
>
>The system remains up but unstable, attempts to access the network interface
>causes a hang, attempts to login to a new session on the console sometimes
>hang.
>This is happening with all adapters I've tried so far, 82579, 82578, 82574,
>ich10, ich9...
>
>
>On Mon, May 20, 2013 at 1:15 AM, Wei Yang <weiyang@linux.vnet.ibm.com> wrote:
> desc_len represents the size of descriptor in rx_ring. There are two
> kinds of
> rx descriptors, e1000_rx_desc_packet_split(32 byte) and
> e1000_rx_desc_extended(16 byte). Different adapter will use different
> rx
> descriptors.
>
> When allocating the dma space for this descriptor in current
> implementation,
> the code ignore the descriptor type and take it as
> e1000_rx_desc_packet_split
> in any case. This behavior will not effect the function, but will
> require
> double size of dma space.
>
> This patch will calculate the desc_len based on the adapter type.
>
> Tested on T420, which use e1000_rx_desc_extended and works fine.
>
> Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
> ---
> Â drivers/net/ethernet/intel/e1000e/netdev.c | Â Â 7 ++++++-
> Â 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/
> net/ethernet/intel/e1000e/netdev.c
> index 5cb8321..a2e8a53 100644
> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> @@ -2364,7 +2364,12 @@ int e1000e_setup_rx_resources(struct
> e1000_ring *rx_ring)
> Â Â Â Â Â Â Â Â Â Â Â Â goto err_pages;
> Â Â Â Â }
>
> - Â Â Â desc_len = sizeof(union e1000_rx_desc_packet_split);
> + Â Â Â if (adapter->rx_ps_pages) {
> + Â Â Â Â Â Â Â /* this is a 32 byte descriptor */
> + Â Â Â Â Â Â Â desc_len = sizeof(union
> e1000_rx_desc_packet_split);
> + Â Â Â } else {
> + Â Â Â Â Â Â Â desc_len = sizeof(union
> e1000_rx_desc_extended);
> + Â Â Â }
>
> Â Â Â Â /* Round up to nearest 4K */
> Â Â Â Â rx_ring->size = rx_ring->count * desc_len;
> --
> 1.7.5.4
>
> --
> 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
>
>
>
>--
>Cheers,
>Jeff
--
Richard Yang
Help you, Help me
^ permalink raw reply
* RE: [PATCH] net: fec: fix build warning of used uninitialized variable
From: Li Frank-B20596 @ 2013-08-22 14:15 UTC (permalink / raw)
To: Duan Fugang-B38611, Zhou Luwei-B45643, davem@davemloft.net
Cc: netdev@vger.kernel.org, shawn.guo@linaro.org,
bhutchings@solarflare.com, Estevam Fabio-R49496,
stephen@networkplumber.org
In-Reply-To: <1377165637-8116-1-git-send-email-B38611@freescale.com>
> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> b/drivers/net/ethernet/freescale/fec_main.c
> index 77ea0db..4ea1555 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -835,7 +835,7 @@ fec_enet_rx(struct net_device *ndev, int budget)
> int pkt_received = 0;
> struct bufdesc_ex *ebdp = NULL;
> bool vlan_packet_rcvd = false;
> - u16 vlan_tag;
> + u16 vlan_tag = 0;
>
> #ifdef CONFIG_M532x
> flush_cache_all();
Acked
> --
> 1.7.1
^ permalink raw reply
* RE: [PATCH] net: fec: fix the error to get the previous BD entry
From: Li Frank-B20596 @ 2013-08-22 14:14 UTC (permalink / raw)
To: Duan Fugang-B38611, Zhou Luwei-B45643, davem@davemloft.net
Cc: netdev@vger.kernel.org, shawn.guo@linaro.org,
bhutchings@solarflare.com, Estevam Fabio-R49496,
stephen@networkplumber.org
In-Reply-To: <1377168036-8359-1-git-send-email-B38611@freescale.com>
>
> - bdp_pre = fec_enet_get_prevdesc(bdp, fep->bufdesc_ex);
> + if (bdp == fep->tx_bd_base)
> + bdp_pre = bdp + TX_RING_SIZE - 1;
You need consider both extended BD format and legacy format.
The size of BD is difference, you can NOT directly you bdp+TX_RING_SIZE -1
Best regards
Frank Li
> + else
> + bdp_pre = fec_enet_get_prevdesc(bdp, fep->bufdesc_ex);
> if ((id_entry->driver_data & FEC_QUIRK_ERR006358) &&
> !(bdp_pre->cbd_sc & BD_ENET_TX_READY)) {
> fep->delay_work.trig_tx = true;
> --
> 1.7.1
^ permalink raw reply
* Re: ipvsadm: One-packet scheduling with UDP service is unstable
From: Julian Anastasov @ 2013-08-22 14:14 UTC (permalink / raw)
To: Drunkard Zhang
Cc: Wensong Zhang, Simon Horman, Pablo Neira Ayuso, Patrick McHardy,
Jozsef Kadlecsik, David S. Miller, netdev, lvs-devel,
netfilter-devel, netfilter, coreteam, linux-kernel
In-Reply-To: <CAJiejCSdfBKC3c1dqya55R5T0VBCTm3qaM6nL-CY+H0o5hbwoA@mail.gmail.com>
Hello,
On Thu, 22 Aug 2013, Drunkard Zhang wrote:
> 2013/8/22 Julian Anastasov <ja@ssi.bg>:
> >
> > No kernel options should be related to OPS. I assume
> > you are not using the SH scheduler. Make sure the OPS mode
> > is properly applied to the virtual service, check for "ops"
> > in the configuration:
> >
> > cat /proc/net/ip_vs
>
> Still no lucky here, ops is set in running config, but it's not like
> that in real world.
>
> vs3 ~ # cat /proc/net/ip_vs
> IP Virtual Server version 1.2.1 (size=1024)
> Prot LocalAddress:Port Scheduler Flags
> -> RemoteAddress:Port Forward Weight ActiveConn InActConn
> UDP 96A46478:0202 wrr ops
> -> 96A46450:0202 Route 25 0 1
The OPS connections are accounted in InActConn
for a very short period, they live up to 1 jiffie, eg. 10ms.
Also, WRR should be reliable for OPS while other
schedulers (eg. *LC) are not suitable.
> And the traffic routed to each realserver didn't following weight I
> set, it's routed pretty much one to one. I got 17 udp sources sending
> to 16 different realservers, the others are bonding to another VIP.
>
> Prot LocalAddress:Port CPS InPPS OutPPS InBPS OutBPS
> -> RemoteAddress:Port
> UDP x.x.x.120:514 0 67622 0 12339373 0
> -> x.x.x.65:514 0 29 0 2895 0
> -> x.x.x.66:514 0 225 0 21850 0
Do you see the same problem with ipvsadm -Ln --stats ?
ipvsadm -Z may be needed to zero the stats after restoring all
rules. "Conns" counter in stats should be according to WRR
weights, it shows the scheduler decisions.
In your rates listing CPS 0 is confusing, even for OPS.
Is it from the new ipvsadm?
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* RE: [PATCH] net: fec: add the initial to set the physical mac address
From: Li Frank-B20596 @ 2013-08-22 14:07 UTC (permalink / raw)
To: Duan Fugang-B38611, Zhou Luwei-B45643, davem@davemloft.net
Cc: netdev@vger.kernel.org, shawn.guo@linaro.org,
bhutchings@solarflare.com, Estevam Fabio-R49496,
stephen@networkplumber.org
In-Reply-To: <1377170269-8988-1-git-send-email-B38611@freescale.com>
I remember community have patch to set random mac if there are not validate mac address
-----Original Message-----
From: Duan Fugang-B38611
Sent: Thursday, August 22, 2013 6:18 AM
To: Li Frank-B20596; Zhou Luwei-B45643; davem@davemloft.net
Cc: netdev@vger.kernel.org; shawn.guo@linaro.org; bhutchings@solarflare.com; Estevam Fabio-R49496; stephen@networkplumber.org
Subject: [PATCH] net: fec: add the initial to set the physical mac address
For imx6slx evk platform, the fec driver cannot work since there have no valid mac address set in physical mac registers.
For imx serial platform, fec/enet IPs both need the physical MAC address initial, otherwise it cannot work.
After acquiring the valid MAC address from devices tree/pfuse/ kernel command line/random mac address, and then set it to the physical MAC address registers.
Signed-off-by: Fugang Duan <B38611@freescale.com>
---
drivers/net/ethernet/freescale/fec_main.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 4349a9e..9b5e08c 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1867,10 +1867,12 @@ fec_set_mac_address(struct net_device *ndev, void *p)
struct fec_enet_private *fep = netdev_priv(ndev);
struct sockaddr *addr = p;
- if (!is_valid_ether_addr(addr->sa_data))
- return -EADDRNOTAVAIL;
+ if (p) {
+ if (!is_valid_ether_addr(addr->sa_data))
+ return -EADDRNOTAVAIL;
- memcpy(ndev->dev_addr, addr->sa_data, ndev->addr_len);
+ memcpy(ndev->dev_addr, addr->sa_data, ndev->addr_len);
+ }
writel(ndev->dev_addr[3] | (ndev->dev_addr[2] << 8) |
(ndev->dev_addr[1] << 16) | (ndev->dev_addr[0] << 24), @@ -1969,6 +1971,7 @@ static int fec_enet_init(struct net_device *ndev)
/* Get the Ethernet address */
fec_get_mac(ndev);
+ fec_set_mac_address(ndev, NULL);
/* Set receive and transmit descriptor base. */
fep->rx_bd_base = cbd_base;
--
1.7.1
^ permalink raw reply related
* Re: Problematic commits in the ipsec tree
From: Hannes Frederic Sowa @ 2013-08-22 13:53 UTC (permalink / raw)
To: Steffen Klassert; +Cc: David Miller, netdev
In-Reply-To: <20130822104724.GD26773@secunet.com>
On Thu, Aug 22, 2013 at 12:47:24PM +0200, Steffen Klassert wrote:
> Hannes,
>
> I have two problematic commits from you in the ipsec tree. The first one is:
>
> commit 0ea9d5e3e (xfrm: introduce helper for safe determination of mtu)
>
> This breakes pmtu discovery for IPv4 because now we use the device mtu
> instead of the reduced IPsec mtu in xfrm4_tunnel_check_size() if a IPv4
> socket is at the skb.
I am currently testing this following patch. It should restore old behavior
for ipv4 sockets.
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index ac5b025..65d3529 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -1730,8 +1730,6 @@ static inline int xfrm_skb_dst_mtu(struct sk_buff *skb)
if (sk && skb->protocol == htons(ETH_P_IPV6))
return ip6_skb_dst_mtu(skb);
- else if (sk && skb->protocol == htons(ETH_P_IP))
- return ip_skb_dst_mtu(skb);
return dst_mtu(skb_dst(skb));
}
Actually I would like to extend this check so that we only take the
dst_mtu(dst->path) in case of IP_PMTUDISC_PROBE. But that would be a
patch for ipsec-next. I was not sure if we always dispatch to xfrm_mtu
in this code-path.
>
> The second is:
>
> commit 844d48746 (xfrm: choose protocol family by skb protocol)
>
> This breaks pmtu discovery for IPv6 too because skb->protocol can be null
> in __xfrm6_output().
I am currently checking if there are side-effects if we set skb->protocol in
raw sockets. This should solve this problem. Btw. this is also the case for
IPv4.
Hope to have tested patches later today.
Thanks,
Hannes
^ permalink raw reply related
* Re: [RFC PATCH] phylib: mdio: handle register/unregister/register sequence
From: boris brezillon @ 2013-08-22 13:24 UTC (permalink / raw)
To: Florian Fainelli
Cc: David S. Miller, Mark Brown, Nick Bowler, Greg Kroah-Hartman,
Grant Likely, netdev, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAGVrzcYTudGg-NH+REL3vDe6a5s6bkXRQH1-PFFs-HNEnJ-rTw@mail.gmail.com>
On 22/08/2013 15:15, Florian Fainelli wrote:
> 2013/8/22 boris brezillon <b.brezillon@overkiz.com>:
>> Hello Florian,
>>
>> Thanks for your answer.
>>
>>
>> On 22/08/2013 14:43, Florian Fainelli wrote:
>>> Hello Boris,
>>>
>>> 2013/8/22 Boris BREZILLON <b.brezillon@overkiz.com>:
>>>> Hello,
>>>>
>>>> This patch is a proposal to support the register/unregister/register
>>>> sequence on a given mdio bus.
>>>>
>>>> I use the register/unregister/register sequence to add a fallback when
>>>> the
>>>> of_mdiobus_register (this function calls mdiobus_register with phy_mask
>>>> set to ~0) does not register any phy device (because the device tree does
>>>> not define any phy).
>>>> In this case I call mdiobus_unregister and then call mdiobus_register
>>>> with
>>>> a phy_mask set to 0 to trigger a full mdio bus scan.
>>>>
>>>> I'm not sure this is the right way to do it (this is why I added RFC in
>>>> the
>>>> subject).
>>>>
>>>> Could someone help me figuring out what I should use to implement my
>>>> fallback ?
>>>>
>>>> 1) use the register/unregister/register sequence
>>>> 2) reimplement the "for (i = 0; i < PHY_MAX_ADDR; i++)" mdiobus_scan loop
>>> I think solution 2 is nicer, in that case, would it be enough in your
>>> case to export a function called mdiobus_scan()? You could call at a
>>> time you know PHY devices have a chance of having been probed?
>> mdiobus_scan is already exported:
>> struct phy_device *mdiobus_scan(struct mii_bus *bus, int addr);
>>
>> This function scans the presence of a phy device at a given address.
>>
>> What I need is a loop which scan all the possible address on the given
>> mdio bus:
>>
>> struct phy_device *mdiobus_full_scan(struct mii_bus *bus)
>> {
>> int i;
>> for (i = 0; i < PHY_MAX_ADDR; i++) {
>> if ((bus->phy_mask & (1 << i)) == 0) {
>> struct phy_device *phydev;
>>
>> phydev = mdiobus_scan(bus, i);
>> if (IS_ERR(phydev)) {
>> err = PTR_ERR(phydev);
>> goto error;
>> }
>> }
>> }
>> return 0;
>>
>> error:
>> while (--i >= 0) {
>>
>> if (bus->phy_map[i])
>> device_unregister(&bus->phy_map[i]->dev);
>> }
>> }
>> EXPORT_SYMBOL(mdiobus_full_scan);
>>
>> Since I am the only one who need this kind of functionnality right now, I'm
>> not sure
>> this is a good idea to export a new function.
> A possible other use case for this full-scan is when you do not detect
> a PHY connected to your MDIO bus, and that you did not register a
> fixed PHY early enough for it to have been scanned by the fixed MDIO
> bus emulation. In that case the driver may:
>
> - scan hardware MDIO bus
> - do not find any PHY, register a fixed PHY
> - trigger a fixed MDIO bus full-rescan
> - attach to the discovered fixed PHY
>
> this is something currently done by the TI CPMAC driver in
> drivers/net/ethernet/ti/cpmac.c (altough fixed_phy_add() is called
> from platform code).
>
Okay, then we should consider this option.
>> This behaviour may be implemented in the of_mdiobus_register function:
>> when no dt phy node are found in the mdio bus dt node, we could launch a
>> full
>> scan.
>>
>> What do you think ?
> There is an existing kind of "autoscan" feature in
> drivers/of/of_mdio.c, starting with the second foreach_child_node()
> loop, so maybe that specific part could be exported and would achieve
> what you are looking for? It relies on the Ethernet PHY nodes to be
> attached to the MDIO bus node, but I assume this is what ultimately
> happens in your case as well?
The second foreach_child_node loop only registers the dt phy nodes
which does not define any reg property (automatic address asssignement ?).
Indeed, what I need is a fallback when the device tree does not define
any phy
device (for old device tree backward compatibility).
^ permalink raw reply
* Re: question about drivers/net/ethernet/sgi
From: Ralf Baechle @ 2013-08-22 13:16 UTC (permalink / raw)
To: Julia Lawall; +Cc: linux-mips, netdev
In-Reply-To: <alpine.DEB.2.02.1308131742100.2263@hadrien>
On Tue, Aug 13, 2013 at 05:43:32PM +0200, Julia Lawall wrote:
> The files in drivers/net/ethernet/sgi (meth.c and ioc3-eth.c) both use
> alloc_skb. Is there a reason why they do not use netdev_alloc_skb, like
> most other ethernet drivers?
netdev_alloc_skb is such newfangled (2.6.19) interface - and both of these
drivers date back to the 2.3 days. So the answer is, nobody bothered so
far.
Ralf
^ permalink raw reply
* Re: [RFC PATCH] phylib: mdio: handle register/unregister/register sequence
From: Florian Fainelli @ 2013-08-22 13:15 UTC (permalink / raw)
To: boris brezillon
Cc: David S. Miller, Mark Brown, Nick Bowler, Greg Kroah-Hartman,
Grant Likely, netdev, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <52160CAC.3040603@overkiz.com>
2013/8/22 boris brezillon <b.brezillon@overkiz.com>:
> Hello Florian,
>
> Thanks for your answer.
>
>
> On 22/08/2013 14:43, Florian Fainelli wrote:
>>
>> Hello Boris,
>>
>> 2013/8/22 Boris BREZILLON <b.brezillon@overkiz.com>:
>>>
>>> Hello,
>>>
>>> This patch is a proposal to support the register/unregister/register
>>> sequence on a given mdio bus.
>>>
>>> I use the register/unregister/register sequence to add a fallback when
>>> the
>>> of_mdiobus_register (this function calls mdiobus_register with phy_mask
>>> set to ~0) does not register any phy device (because the device tree does
>>> not define any phy).
>>> In this case I call mdiobus_unregister and then call mdiobus_register
>>> with
>>> a phy_mask set to 0 to trigger a full mdio bus scan.
>>>
>>> I'm not sure this is the right way to do it (this is why I added RFC in
>>> the
>>> subject).
>>>
>>> Could someone help me figuring out what I should use to implement my
>>> fallback ?
>>>
>>> 1) use the register/unregister/register sequence
>>> 2) reimplement the "for (i = 0; i < PHY_MAX_ADDR; i++)" mdiobus_scan loop
>>
>> I think solution 2 is nicer, in that case, would it be enough in your
>> case to export a function called mdiobus_scan()? You could call at a
>> time you know PHY devices have a chance of having been probed?
>
> mdiobus_scan is already exported:
> struct phy_device *mdiobus_scan(struct mii_bus *bus, int addr);
>
> This function scans the presence of a phy device at a given address.
>
> What I need is a loop which scan all the possible address on the given
> mdio bus:
>
> struct phy_device *mdiobus_full_scan(struct mii_bus *bus)
> {
> int i;
> for (i = 0; i < PHY_MAX_ADDR; i++) {
> if ((bus->phy_mask & (1 << i)) == 0) {
> struct phy_device *phydev;
>
> phydev = mdiobus_scan(bus, i);
> if (IS_ERR(phydev)) {
> err = PTR_ERR(phydev);
> goto error;
> }
> }
> }
> return 0;
>
> error:
> while (--i >= 0) {
>
> if (bus->phy_map[i])
> device_unregister(&bus->phy_map[i]->dev);
> }
> }
> EXPORT_SYMBOL(mdiobus_full_scan);
>
> Since I am the only one who need this kind of functionnality right now, I'm
> not sure
> this is a good idea to export a new function.
A possible other use case for this full-scan is when you do not detect
a PHY connected to your MDIO bus, and that you did not register a
fixed PHY early enough for it to have been scanned by the fixed MDIO
bus emulation. In that case the driver may:
- scan hardware MDIO bus
- do not find any PHY, register a fixed PHY
- trigger a fixed MDIO bus full-rescan
- attach to the discovered fixed PHY
this is something currently done by the TI CPMAC driver in
drivers/net/ethernet/ti/cpmac.c (altough fixed_phy_add() is called
from platform code).
>
> This behaviour may be implemented in the of_mdiobus_register function:
> when no dt phy node are found in the mdio bus dt node, we could launch a
> full
> scan.
>
> What do you think ?
There is an existing kind of "autoscan" feature in
drivers/of/of_mdio.c, starting with the second foreach_child_node()
loop, so maybe that specific part could be exported and would achieve
what you are looking for? It relies on the Ethernet PHY nodes to be
attached to the MDIO bus node, but I assume this is what ultimately
happens in your case as well?
--
Florian
^ permalink raw reply
* Re: [RFC PATCH] phylib: mdio: handle register/unregister/register sequence
From: boris brezillon @ 2013-08-22 13:14 UTC (permalink / raw)
To: Boris BREZILLON
Cc: Nick Bowler, Greg Kroah-Hartman, linux-kernel, Grant Likely,
Mark Brown, netdev, David S. Miller, linux-arm-kernel
In-Reply-To: <1377174836-10569-1-git-send-email-b.brezillon@overkiz.com>
On 22/08/2013 14:33, Boris BREZILLON wrote:
> Hello,
>
> This patch is a proposal to support the register/unregister/register
> sequence on a given mdio bus.
I forgot to ask, if this limitation was made on purpose ?
In other terms: no one should ever try to register, unregister and
register again
a given mii_bus structure.
>
> I use the register/unregister/register sequence to add a fallback when the
> of_mdiobus_register (this function calls mdiobus_register with phy_mask
> set to ~0) does not register any phy device (because the device tree does
> not define any phy).
> In this case I call mdiobus_unregister and then call mdiobus_register with
> a phy_mask set to 0 to trigger a full mdio bus scan.
>
> I'm not sure this is the right way to do it (this is why I added RFC in the
> subject).
>
> Could someone help me figuring out what I should use to implement my fallback ?
>
> 1) use the register/unregister/register sequence
> 2) reimplement the "for (i = 0; i < PHY_MAX_ADDR; i++)" mdiobus_scan loop
>
> Thanks.
>
> Best Regards,
> Boris
>
> Boris BREZILLON (1):
> phylib: mdio: handle register/unregister/register sequence
>
> drivers/net/phy/mdio_bus.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
^ permalink raw reply
* [PATCH net-next 32/32] sfc: Update and improve kernel-doc for efx_mcdi_state & efx_mcdi_iface
From: Ben Hutchings @ 2013-08-22 13:10 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
In-Reply-To: <1377175392.1703.5.camel@bwh-desktop.uk.level5networks.com>
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/ethernet/sfc/mcdi.h | 20 +++++++++-----------
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/sfc/mcdi.h b/drivers/net/ethernet/sfc/mcdi.h
index 0cb0d5a..69586e0 100644
--- a/drivers/net/ethernet/sfc/mcdi.h
+++ b/drivers/net/ethernet/sfc/mcdi.h
@@ -11,14 +11,14 @@
#define EFX_MCDI_H
/**
- * enum efx_mcdi_state
+ * enum efx_mcdi_state - MCDI request handling state
* @MCDI_STATE_QUIESCENT: No pending MCDI requests. If the caller holds the
- * mcdi_lock then they are able to move to MCDI_STATE_RUNNING
+ * mcdi @iface_lock then they are able to move to %MCDI_STATE_RUNNING
* @MCDI_STATE_RUNNING: There is an MCDI request pending. Only the thread that
* moved into this state is allowed to move out of it.
* @MCDI_STATE_COMPLETED: An MCDI request has completed, but the owning thread
* has not yet consumed the result. For all other threads, equivalent to
- * MCDI_STATE_RUNNING.
+ * %MCDI_STATE_RUNNING.
*/
enum efx_mcdi_state {
MCDI_STATE_QUIESCENT,
@@ -32,25 +32,23 @@ enum efx_mcdi_mode {
};
/**
- * struct efx_mcdi_iface
- * @state: Interface state. Waited for by mcdi_wq.
- * @wq: Wait queue for threads waiting for state != STATE_RUNNING
- * @iface_lock: Protects @credits, @seqno, @resprc, @resplen
+ * struct efx_mcdi_iface - MCDI protocol context
+ * @state: Request handling state. Waited for by @wq.
* @mode: Poll for mcdi completion, or wait for an mcdi_event.
- * Serialised by @lock
+ * @wq: Wait queue for threads waiting for @state != %MCDI_STATE_RUNNING
+ * @iface_lock: Serialises access to all the following fields
* @seqno: The next sequence number to use for mcdi requests.
- * Serialised by @lock
* @credits: Number of spurious MCDI completion events allowed before we
- * trigger a fatal error. Protected by @lock
+ * trigger a fatal error
* @resprc: Response error/success code (Linux numbering)
* @resp_hdr_len: Response header length
* @resp_data_len: Response data (SDU or error) length
*/
struct efx_mcdi_iface {
atomic_t state;
+ enum efx_mcdi_mode mode;
wait_queue_head_t wq;
spinlock_t iface_lock;
- enum efx_mcdi_mode mode;
unsigned int credits;
unsigned int seqno;
int resprc;
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* Re: [patch net-next v6 4/4] igb/igbvf: implement ndo_get_phys_port_id
From: Jiri Pirko @ 2013-08-22 13:10 UTC (permalink / raw)
To: Jeff Kirsher
Cc: aaron.f.brown, netdev, davem, stephen, Narendra_K, bhutchings,
or.gerlitz, carolyn.wyborny, gregory.v.rose, vyasevic, amwang,
johannes
In-Reply-To: <1377167950.3939.57.camel@jtkirshe-mobl>
Thu, Aug 22, 2013 at 12:39:10PM CEST, jeffrey.t.kirsher@intel.com wrote:
>On Mon, 2013-07-29 at 18:16 +0200, Jiri Pirko wrote:
>> igb driver generated random number which will identify physical port.
>> This id is available via ndo_get_phys_port_id directly on igb netdev.
>> Also, id is passed to igbvf using mailbox. After that, it is available
>> via
>> ndo_get_phys_port_id on igbvf netdev as well.
>>
>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>> ---
>> drivers/net/ethernet/intel/igb/e1000_mbx.h | 1 +
>> drivers/net/ethernet/intel/igb/igb.h | 3 +++
>> drivers/net/ethernet/intel/igb/igb_main.c | 37
>> ++++++++++++++++++++++++++++-
>> drivers/net/ethernet/intel/igbvf/igbvf.h | 4 ++++
>> drivers/net/ethernet/intel/igbvf/mbx.h | 1 +
>> drivers/net/ethernet/intel/igbvf/netdev.c | 38
>> ++++++++++++++++++++++++++++++
>> drivers/net/ethernet/intel/igbvf/vf.c | 34
>> ++++++++++++++++++++++++++
>> drivers/net/ethernet/intel/igbvf/vf.h | 1 +
>> 8 files changed, 118 insertions(+), 1 deletion(-)
>
>Jiri-
>
>Validation ran into a couple of issues with this patch. Here is what
>Aaron found when testing this patch...
Interesting. So since igbvf_refresh_ppid() is called from igbvf_reset()
and igbvf_probe(), I believed that is enough. Looks like perm_addr
getting works in similar way. Can you please check if perm_addr is set
correctly in the same time reading phys_port_id gives -EOPNOTSUPP?
>
>Aaron Brown wrote:
>I think I have to fail this, it seems to have an issue with
>initialization. When I first create a vf via sysfs the pys_port_id file
>is created along with the other sysfs files for the vf, however an
>attempt to cat out the value returns " Operation not supported". At
>this point the vf is still down, if I bring it up (or simply unload /
>reload the igbvf driver) I can then cat the file successfully and the vf
>interface phys_port_id matches the phys_port_id of the pf. This is
>testing from bare metal, a console session showing this behavior
>follows:
>
>u1304:[0]/sys> find . -iname phys_port_id
>./devices/pci0000:00/0000:00:01.0/0000:07:00.0/net/eth0/phys_port_id
>./devices/pci0000:00/0000:00:01.0/0000:07:00.1/net/eth1/phys_port_id
>./devices/virtual/net/sit0/phys_port_id
>./devices/virtual/net/lo/phys_port_id
>u1304:[0]/sys> cat devices/pci0000:00/0000:00:01.0/0000:07:00.0/net/eth0/phys_port_id
>5ece9fbd9cd51546982e15c1f2c11e25
>u1304:[0]/sys>
>
>So far so good, now make a few vfs and check for new phys_port_id sysfs files.
>
>u1304:[0]/sys> find . -iname sriov_numvfs
>./devices/pci0000:00/0000:00:01.0/0000:07:00.0/sriov_numvfs
>./devices/pci0000:00/0000:00:01.0/0000:07:00.1/sriov_numvfs
>u1304:[0]/sys> echo 2 > devices/pci0000:00/0000:00:01.0/0000:07:00.0/sriov_numvfs
>u1304:[0]/sys> find . -iname phys_port_id ./devices/pci0000:00/0000:00:01.0/0000:07:00.0/net/eth0/phys_port_id
>./devices/pci0000:00/0000:00:01.0/0000:07:00.1/net/eth1/phys_port_id
>./devices/pci0000:00/0000:00:01.0/0000:07:10.0/net/eth2/phys_port_id
>./devices/pci0000:00/0000:00:01.0/0000:07:10.2/net/eth3/phys_port_id
>./devices/virtual/net/sit0/phys_port_id
>./devices/virtual/net/lo/phys_port_id
>u1304:[0]/sys>
>
>The first vf is eth2, attempt to cat out it's phys_port_id
>
>u1304:[0]/sys> cat ./devices/pci0000:00/0000:00:01.0/0000:07:10.0/net/eth2/phys_port_id
>cat: ./devices/pci0000:00/0000:00:01.0/0000:07:10.0/net/eth2/phys_port_id: Operation not supported
>u1304:[0]/sys>
>
>But, if I bring the interface up (or unload / load the igbvf driver) I then am able to cat the phys_port_id of the vf and it matches the phys_port_id of the physical interface.
>
>u1304:[0]/sys> ifconfig eth2 u1304-2
>u1304:[0]/sys> cat ./devices/pci0000:00/0000:00:01.0/0000:07:10.0/net/eth2/phys_port_id
>5ece9fbd9cd51546982e15c1f2c11e25
>u1304:[0]/sys>
^ permalink raw reply
* [PATCH net-next 31/32] sfc: Fix race in completion handling
From: Ben Hutchings @ 2013-08-22 13:10 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
In-Reply-To: <1377175392.1703.5.camel@bwh-desktop.uk.level5networks.com>
When we poll for MCDI request completion, we don't hold the interface
lock while setting the response fields in struct efx_mcdi_iface.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/ethernet/sfc/mcdi.c | 25 ++++++++++---------------
1 file changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/sfc/mcdi.c b/drivers/net/ethernet/sfc/mcdi.c
index 2c5ee89..1c8bf81 100644
--- a/drivers/net/ethernet/sfc/mcdi.c
+++ b/drivers/net/ethernet/sfc/mcdi.c
@@ -112,16 +112,6 @@ static void efx_mcdi_copyin(struct efx_nic *efx, unsigned cmd,
efx->type->mcdi_request(efx, hdr, hdr_len, inbuf, inlen);
}
-static void
-efx_mcdi_copyout(struct efx_nic *efx, efx_dword_t *outbuf, size_t outlen)
-{
- struct efx_mcdi_iface *mcdi = efx_mcdi(efx);
-
- BUG_ON(atomic_read(&mcdi->state) == MCDI_STATE_QUIESCENT);
-
- efx->type->mcdi_read_response(efx, outbuf, mcdi->resp_hdr_len, outlen);
-}
-
static int efx_mcdi_errno(unsigned int mcdi_err)
{
switch (mcdi_err) {
@@ -200,9 +190,11 @@ static int efx_mcdi_poll(struct efx_nic *efx)
/* Check for a reboot atomically with respect to efx_mcdi_copyout() */
rc = efx_mcdi_poll_reboot(efx);
if (rc) {
+ spin_lock_bh(&mcdi->iface_lock);
mcdi->resprc = rc;
mcdi->resp_hdr_len = 0;
mcdi->resp_data_len = 0;
+ spin_unlock_bh(&mcdi->iface_lock);
return 0;
}
@@ -231,7 +223,9 @@ static int efx_mcdi_poll(struct efx_nic *efx)
return -ETIMEDOUT;
}
+ spin_lock_bh(&mcdi->iface_lock);
efx_mcdi_read_response_header(efx);
+ spin_unlock_bh(&mcdi->iface_lock);
/* Return rc=0 like wait_event_timeout() */
return 0;
@@ -419,7 +413,7 @@ int efx_mcdi_rpc_finish(struct efx_nic *efx, unsigned cmd, size_t inlen,
"MC command 0x%x inlen %d mode %d timed out\n",
cmd, (int)inlen, mcdi->mode);
} else {
- size_t resplen;
+ size_t hdr_len, data_len;
/* At the very least we need a memory barrier here to ensure
* we pick up changes from efx_mcdi_ev_cpl(). Protect against
@@ -427,16 +421,17 @@ int efx_mcdi_rpc_finish(struct efx_nic *efx, unsigned cmd, size_t inlen,
* acquiring the iface_lock. */
spin_lock_bh(&mcdi->iface_lock);
rc = mcdi->resprc;
- resplen = mcdi->resp_data_len;
+ hdr_len = mcdi->resp_hdr_len;
+ data_len = mcdi->resp_data_len;
spin_unlock_bh(&mcdi->iface_lock);
BUG_ON(rc > 0);
if (rc == 0) {
- efx_mcdi_copyout(efx, outbuf,
- min(outlen, mcdi->resp_data_len));
+ efx->type->mcdi_read_response(efx, outbuf, hdr_len,
+ min(outlen, data_len));
if (outlen_actual != NULL)
- *outlen_actual = resplen;
+ *outlen_actual = data_len;
} else if (cmd == MC_CMD_REBOOT && rc == -EIO)
; /* Don't reset if MC_CMD_REBOOT returns EIO */
else if (rc == -EIO || rc == -EINTR) {
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply 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