* [PATCH 19/22] dt/bindings: add micrel,rmii_ref_clk_sel_25_mhz to eth-phy binding
From: Johan Hovold @ 2014-11-11 17:37 UTC (permalink / raw)
To: Florian Fainelli
Cc: David S. Miller, linux-kernel, netdev, Johan Hovold, devicetree
In-Reply-To: <1415727460-20417-1-git-send-email-johan@kernel.org>
Add "micrel,rmii_ref_clk_sel_25_mhz" to Micrel ethernet PHY binding
documentation.
Cc: devicetree@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
---
Documentation/devicetree/bindings/net/micrel.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/micrel.txt b/Documentation/devicetree/bindings/net/micrel.txt
index a1bab5eaae02..9b08dd6551dd 100644
--- a/Documentation/devicetree/bindings/net/micrel.txt
+++ b/Documentation/devicetree/bindings/net/micrel.txt
@@ -19,6 +19,11 @@ Optional properties:
See the respective PHY datasheet for the mode values.
+ - micrel,rmii_ref_clk_sel_25_mhz: rmii_ref_clk_sel bit selects 25 MHz mode
+
+ Whether 25 MHz (rather than 50 Mhz) clock mode is selected
+ when the rmii_ref_clk_sel bit is set.
+
- clocks, clock-names: contains clocks according to the common clock bindings.
supported clocks:
--
2.0.4
^ permalink raw reply related
* [PATCH 20/22] net: phy: micrel: refactor interrupt config
From: Johan Hovold @ 2014-11-11 17:37 UTC (permalink / raw)
To: Florian Fainelli; +Cc: David S. Miller, linux-kernel, netdev, Johan Hovold
In-Reply-To: <1415727460-20417-1-git-send-email-johan@kernel.org>
Add generic interrupt-config callback and store interrupt-level bitmask
in type data for PHY types not using bit 9.
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/net/phy/micrel.c | 71 ++++++++++++++++++++----------------------------
1 file changed, 29 insertions(+), 42 deletions(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 591190384497..743d5b52d8db 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -55,8 +55,6 @@
#define MII_KSZPHY_CTRL MII_KSZPHY_CTRL_2
/* bitmap of PHY register to set interrupt mode */
#define KSZPHY_CTRL_INT_ACTIVE_HIGH BIT(9)
-#define KSZ9021_CTRL_INT_ACTIVE_HIGH BIT(14)
-#define KS8737_CTRL_INT_ACTIVE_HIGH BIT(14)
#define KSZPHY_RMII_REF_CLK_SEL BIT(7)
/* Write/read to/from extended registers */
@@ -75,6 +73,7 @@
struct kszphy_type {
u32 led_mode_reg;
+ u16 interrupt_level_mask;
bool has_broadcast_disable;
bool has_rmii_ref_clk_sel;
};
@@ -105,6 +104,14 @@ static const struct kszphy_type ksz8081_type = {
.has_rmii_ref_clk_sel = true,
};
+static const struct kszphy_type ks8737_type = {
+ .interrupt_level_mask = BIT(14),
+};
+
+static const struct kszphy_type ksz9021_type = {
+ .interrupt_level_mask = BIT(14),
+};
+
static int kszphy_extended_write(struct phy_device *phydev,
u32 regnum, u16 val)
{
@@ -129,54 +136,31 @@ static int kszphy_ack_interrupt(struct phy_device *phydev)
return (rc < 0) ? rc : 0;
}
-static int kszphy_set_interrupt(struct phy_device *phydev)
-{
- int temp;
- temp = (PHY_INTERRUPT_ENABLED == phydev->interrupts) ?
- KSZPHY_INTCS_ALL : 0;
- return phy_write(phydev, MII_KSZPHY_INTCS, temp);
-}
-
static int kszphy_config_intr(struct phy_device *phydev)
{
- int temp, rc;
-
- /* set the interrupt pin active low */
- temp = phy_read(phydev, MII_KSZPHY_CTRL);
- if (temp < 0)
- return temp;
- temp &= ~KSZPHY_CTRL_INT_ACTIVE_HIGH;
- phy_write(phydev, MII_KSZPHY_CTRL, temp);
- rc = kszphy_set_interrupt(phydev);
- return rc < 0 ? rc : 0;
-}
+ const struct kszphy_type *type = phydev->drv->driver_data;
+ int temp;
+ u16 mask;
-static int ksz9021_config_intr(struct phy_device *phydev)
-{
- int temp, rc;
+ if (type && type->interrupt_level_mask)
+ mask = type->interrupt_level_mask;
+ else
+ mask = KSZPHY_CTRL_INT_ACTIVE_HIGH;
/* set the interrupt pin active low */
temp = phy_read(phydev, MII_KSZPHY_CTRL);
if (temp < 0)
return temp;
- temp &= ~KSZ9021_CTRL_INT_ACTIVE_HIGH;
+ temp &= ~mask;
phy_write(phydev, MII_KSZPHY_CTRL, temp);
- rc = kszphy_set_interrupt(phydev);
- return rc < 0 ? rc : 0;
-}
-static int ks8737_config_intr(struct phy_device *phydev)
-{
- int temp, rc;
+ /* enable / disable interrupts */
+ if (phydev->interrupts == PHY_INTERRUPT_ENABLED)
+ temp = KSZPHY_INTCS_ALL;
+ else
+ temp = 0;
- /* set the interrupt pin active low */
- temp = phy_read(phydev, MII_KSZPHY_CTRL);
- if (temp < 0)
- return temp;
- temp &= ~KS8737_CTRL_INT_ACTIVE_HIGH;
- phy_write(phydev, MII_KSZPHY_CTRL, temp);
- rc = kszphy_set_interrupt(phydev);
- return rc < 0 ? rc : 0;
+ return phy_write(phydev, MII_KSZPHY_INTCS, temp);
}
static int kszphy_rmii_clk_sel(struct phy_device *phydev, bool val)
@@ -581,11 +565,12 @@ static struct phy_driver ksphy_driver[] = {
.name = "Micrel KS8737",
.features = (PHY_BASIC_FEATURES | SUPPORTED_Pause),
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
+ .driver_data = &ks8737_type,
.config_init = kszphy_config_init,
.config_aneg = genphy_config_aneg,
.read_status = genphy_read_status,
.ack_interrupt = kszphy_ack_interrupt,
- .config_intr = ks8737_config_intr,
+ .config_intr = kszphy_config_intr,
.suspend = genphy_suspend,
.resume = genphy_resume,
.driver = { .owner = THIS_MODULE,},
@@ -726,11 +711,12 @@ static struct phy_driver ksphy_driver[] = {
.name = "Micrel KSZ9021 Gigabit PHY",
.features = (PHY_GBIT_FEATURES | SUPPORTED_Pause),
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
+ .driver_data = &ksz9021_type,
.config_init = ksz9021_config_init,
.config_aneg = genphy_config_aneg,
.read_status = genphy_read_status,
.ack_interrupt = kszphy_ack_interrupt,
- .config_intr = ksz9021_config_intr,
+ .config_intr = kszphy_config_intr,
.suspend = genphy_suspend,
.resume = genphy_resume,
.read_mmd_indirect = ksz9021_rd_mmd_phyreg,
@@ -742,11 +728,12 @@ static struct phy_driver ksphy_driver[] = {
.name = "Micrel KSZ9031 Gigabit PHY",
.features = (PHY_GBIT_FEATURES | SUPPORTED_Pause),
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
+ .driver_data = &ksz9021_type,
.config_init = ksz9031_config_init,
.config_aneg = genphy_config_aneg,
.read_status = genphy_read_status,
.ack_interrupt = kszphy_ack_interrupt,
- .config_intr = ksz9021_config_intr,
+ .config_intr = kszphy_config_intr,
.suspend = genphy_suspend,
.resume = genphy_resume,
.driver = { .owner = THIS_MODULE, },
--
2.0.4
^ permalink raw reply related
* Re: [patch net-next v2 08/10] bridge: add API to notify bridge driver of learned FBD on offloaded device
From: Scott Feldman @ 2014-11-11 17:38 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Jiri Pirko, Netdev, David S. Miller, nhorman, Andy Gospodarek,
Thomas Graf, dborkman, ogerlitz, jesse, pshelar, azhou, ben,
stephen, Kirsher, Jeffrey T, vyasevic, Cong Wang,
Fastabend, John R, Eric Dumazet, Jamal Hadi Salim,
Florian Fainelli, John Linville, jasowang, ebiederm,
Nicolas Dichtel, ryazanov.s.a, buytenh, Aviad Raveh, nbd,
Alexei Starovoitov <alexei.staro
In-Reply-To: <54621B77.4050109@cumulusnetworks.com>
On Tue, Nov 11, 2014 at 4:21 AM, Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
> On 11/9/14, 2:51 AM, Jiri Pirko wrote:
>>
>> From: Scott Feldman <sfeldma@gmail.com>
>>
>> When the swdev device learns a new mac/vlan on a port, it sends some async
>> notification to the driver and the driver installs an FDB in the device.
>> To give a holistic system view, the learned mac/vlan should be reflected
>> in the bridge's FBD table, so the user, using normal iproute2 cmds, can
>> view
>> what is currently learned by the device. This API on the bridge driver
>> gives
>> a way for the swdev driver to install an FBD entry in the bridge FBD
>> table.
>> (And remove one).
>>
>> This is equivalent to the device running these cmds:
>>
>> bridge fdb [add|del] <mac> dev <dev> vid <vlan id> master
>>
>> This patch needs some extra eyeballs for review, in paricular around the
>> locking and contexts.
>
>
> scott/jiri, love that you have handled this case!, This will be useful.
> But, quick question, Cant this also be done using the same ndo_op that is
> done to add the static fdb..?
Maybe. I think I tried sending netlink msg from swdev driver to
bridge driver, but wasn't able to make it to work. I'm not sure if
it's possible to do that, in general, send netlink kernel-to-kernel.
The other option is to synthesize a netlink msg with needed attrs and
call ndo in bridge directly. That feels a little yucky to me.
^ permalink raw reply
* [PATCH 10/22] net: phy: micrel: refactor led-mode error handling
From: Johan Hovold @ 2014-11-11 17:37 UTC (permalink / raw)
To: Florian Fainelli; +Cc: David S. Miller, linux-kernel, netdev, Johan Hovold
In-Reply-To: <1415727460-20417-1-git-send-email-johan@kernel.org>
Refactor led-mode error handling.
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/net/phy/micrel.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 1b3985cdc64c..ec9ce35e934b 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -179,14 +179,19 @@ static int kszphy_setup_led(struct phy_device *phydev,
}
temp = phy_read(phydev, reg);
- if (temp < 0)
- return temp;
+ if (temp < 0) {
+ rc = temp;
+ goto out;
+ }
temp &= ~(3 << shift);
temp |= val << shift;
rc = phy_write(phydev, reg, temp);
+out:
+ if (rc < 0)
+ dev_err(&phydev->dev, "failed to set led mode\n");
- return rc < 0 ? rc : 0;
+ return rc;
}
/* Disable PHY address 0 as the broadcast address, so that it can be used as a
@@ -223,9 +228,7 @@ static int ksz8021_config_init(struct phy_device *phydev)
{
int rc;
- rc = kszphy_setup_led(phydev, 0x1f, 4);
- if (rc)
- dev_err(&phydev->dev, "failed to set led mode\n");
+ kszphy_setup_led(phydev, 0x1f, 4);
rc = ksz_config_flags(phydev);
if (rc < 0)
@@ -240,9 +243,7 @@ static int ks8051_config_init(struct phy_device *phydev)
{
int rc;
- rc = kszphy_setup_led(phydev, 0x1f, 4);
- if (rc)
- dev_err(&phydev->dev, "failed to set led mode\n");
+ kszphy_setup_led(phydev, 0x1f, 4);
rc = ksz_config_flags(phydev);
return rc < 0 ? rc : 0;
--
2.0.4
^ permalink raw reply related
* [RFC 22/22] net: phy: micrel: use generic config_init for KSZ8021/KSZ8031
From: Johan Hovold @ 2014-11-11 17:37 UTC (permalink / raw)
To: Florian Fainelli
Cc: David S. Miller, linux-kernel, netdev, Johan Hovold,
Bruno Thomsen
In-Reply-To: <1415727460-20417-1-git-send-email-johan@kernel.org>
Use generic config_init callback also for KSZ8021 and KSZ8031.
This has been avoided this far due to commit a95a18afe4c8 ("phy/micrel:
KSZ8031RNL RMII clock reconfiguration bug"), which claims that the PHY
becomes unresponsive if the broadcast disable flag is set before
configuring the clock mode.
Disabling the broadcast address in generally the first think you want to
do, and if PHY 0 is probed first, this will disable the broadcast
address for all (Micrel) PHYs on the bus and prevent unnecessary
reconfigurations. Note that if parallel probing is ever allowed, this
will be a requirement.
Cc: Bruno Thomsen <bth@kamstrup.dk>
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/net/phy/micrel.c | 18 +++---------------
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 3b89548e6063..bbd1c9ea0cbf 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -88,6 +88,7 @@ struct kszphy_priv {
static const struct kszphy_type ksz8021_type = {
.led_mode_reg = MII_KSZPHY_CTRL_2,
+ .has_broadcast_disable = true,
.has_rmii_ref_clk_sel = true,
};
@@ -258,19 +259,6 @@ static int kszphy_config_init(struct phy_device *phydev)
return 0;
}
-static int ksz8021_config_init(struct phy_device *phydev)
-{
- int rc;
-
- rc = kszphy_config_init(phydev);
- if (rc)
- return rc;
-
- rc = kszphy_broadcast_disable(phydev);
-
- return rc < 0 ? rc : 0;
-}
-
static int ksz9021_load_values_from_of(struct phy_device *phydev,
struct device_node *of_node, u16 reg,
char *field1, char *field2,
@@ -584,7 +572,7 @@ static struct phy_driver ksphy_driver[] = {
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.driver_data = &ksz8021_type,
.probe = kszphy_probe,
- .config_init = ksz8021_config_init,
+ .config_init = kszphy_config_init,
.config_aneg = genphy_config_aneg,
.read_status = genphy_read_status,
.ack_interrupt = kszphy_ack_interrupt,
@@ -601,7 +589,7 @@ static struct phy_driver ksphy_driver[] = {
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.driver_data = &ksz8021_type,
.probe = kszphy_probe,
- .config_init = ksz8021_config_init,
+ .config_init = kszphy_config_init,
.config_aneg = genphy_config_aneg,
.read_status = genphy_read_status,
.ack_interrupt = kszphy_ack_interrupt,
--
2.0.4
^ permalink raw reply related
* Tracking errors in netdevice (and other?) notifiers
From: Rafał Miłecki @ 2014-11-11 17:39 UTC (permalink / raw)
To: Network Development
Hi,
During development of wireless driver I got this poor meaning error:
# ifconfig wlan0_1 up
ifconfig: SIOCSIFFLAGS: Device or resource busy
I've quickly tracked it down to the __dev_open [0]. Then it became worse.
In my case call_netdevice_notifiers returned 32785 which was
translated by notifier_to_errno to the -16 (-EBUSY).
Unfortunately I couldn't track call_netdevice_notifiers. It iterates
over a chain (list) of nameless notifiers (struct notifier_block). I
didn't have a chance to e.g. print a name of notifier that returned an
error.
Is there some trick to do that? To track notifiers and find a code
responsible for the chain error?
In my case it wasn't too hard, because there are only few places in
the kernel registering for NETDEV_PRE_UP. So I checked all of them and
found the guilty one. But I still would like to know if there is some
smart way.
[0] http://lxr.free-electrons.com/source/net/core/dev.c?v=3.17#L1268
--
Rafał
^ permalink raw reply
* [PATCH 21/22] net: phy: micrel: add copyright entry
From: Johan Hovold @ 2014-11-11 17:37 UTC (permalink / raw)
To: Florian Fainelli; +Cc: David S. Miller, linux-kernel, netdev, Johan Hovold
In-Reply-To: <1415727460-20417-1-git-send-email-johan@kernel.org>
Add myself to the list of copyright holders.
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/net/phy/micrel.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 743d5b52d8db..3b89548e6063 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -6,6 +6,7 @@
* Author: David J. Choi
*
* Copyright (c) 2010-2013 Micrel, Inc.
+ * Copyright (c) 2014 Johan Hovold <johan@kernel.org>
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
--
2.0.4
^ permalink raw reply related
* Re: [net-next PATCH v3 4/5] fm10k/igb/ixgbe: Replace __skb_alloc_page with dev_alloc_page
From: David Miller @ 2014-11-11 17:48 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: alexander.h.duyck, netdev, linux-usb, leedom, hariprasad,
donald.c.skidmore, oliver, balbi, matthew.vick, mgorman
In-Reply-To: <1415726904.2466.170.camel@jtkirshe-mobl>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 11 Nov 2014 09:28:24 -0800
> On Tue, 2014-11-11 at 09:26 -0800, Alexander Duyck wrote:
>> The Intel drivers were pretty much just using the plain vanilla GFP
>> flags
>> in their calls to __skb_alloc_page so this change makes it so that
>> they use
>> dev_alloc_page which just uses GFP_ATOMIC for the gfp_flags value.
>>
>> Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>> Cc: Matthew Vick <matthew.vick@intel.com>
>> Cc: Don Skidmore <donald.c.skidmore@intel.com>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
>> ---
>> drivers/net/ethernet/intel/fm10k/fm10k_main.c | 2 +-
>> drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
>> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 +--
>> 3 files changed, 3 insertions(+), 4 deletions(-)
>
> Thanks Alex, I will add the patch to my queue.
I think this entire series will need to go via my tree, because the
conversions are all required for patch #5 which removes the replaced
interface altogether.
^ permalink raw reply
* Re: [PATCH 00/22] net: phy: refactoring and Micrel features
From: David Miller @ 2014-11-11 17:49 UTC (permalink / raw)
To: johan; +Cc: f.fainelli, linux-kernel, netdev, bth
In-Reply-To: <1415727460-20417-1-git-send-email-johan@kernel.org>
22 patches is just too much, sorry.
Please reduce this down to something closer to ~10 or so patches.
If necessary you can do two series, submit the first 10 and then
when that's reviewed and accepted submit the second set.
Thanks.
^ permalink raw reply
* Re: [net-next PATCH v3 4/5] fm10k/igb/ixgbe: Replace __skb_alloc_page with dev_alloc_page
From: Jeff Kirsher @ 2014-11-11 17:56 UTC (permalink / raw)
To: David Miller
Cc: alexander.h.duyck-H+wXaHxf7aLQT0dZR+AlfA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
leedom-ut6Up61K2wZBDgjK7y7TUQ, hariprasad-ut6Up61K2wZBDgjK7y7TUQ,
donald.c.skidmore-ral2JQCrhuEAvxtiuMwx3w,
oliver-GvhC2dPhHPQdnm+yROfE0A, balbi-l0cyMroinI0,
matthew.vick-ral2JQCrhuEAvxtiuMwx3w, mgorman-l3A5Bk7waGM
In-Reply-To: <20141111.124826.2036471212277751765.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1631 bytes --]
On Tue, 2014-11-11 at 12:48 -0500, David Miller wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Date: Tue, 11 Nov 2014 09:28:24 -0800
>
> > On Tue, 2014-11-11 at 09:26 -0800, Alexander Duyck wrote:
> >> The Intel drivers were pretty much just using the plain vanilla GFP
> >> flags
> >> in their calls to __skb_alloc_page so this change makes it so that
> >> they use
> >> dev_alloc_page which just uses GFP_ATOMIC for the gfp_flags value.
> >>
> >> Cc: Jeff Kirsher <jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> >> Cc: Matthew Vick <matthew.vick-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> >> Cc: Don Skidmore <donald.c.skidmore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> >> Signed-off-by: Alexander Duyck <alexander.h.duyck-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >> ---
> >> drivers/net/ethernet/intel/fm10k/fm10k_main.c | 2 +-
> >> drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
> >> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 +--
> >> 3 files changed, 3 insertions(+), 4 deletions(-)
> >
> > Thanks Alex, I will add the patch to my queue.
>
> I think this entire series will need to go via my tree, because the
> conversions are all required for patch #5 which removes the replaced
> interface altogether.
That is fine Dave, I think I mentioned that during Alex's v1 of the
series. I was just letting Alex know that we were going to test his
changes, but feel free to pull the entire series.
I will give you my ACK
Acked-by: Jeff Kirsher <jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 19/22] dt/bindings: add micrel,rmii_ref_clk_sel_25_mhz to eth-phy binding
From: Mark Rutland @ 2014-11-11 17:57 UTC (permalink / raw)
To: Johan Hovold
Cc: Florian Fainelli, David S. Miller, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <1415727460-20417-20-git-send-email-johan@kernel.org>
On Tue, Nov 11, 2014 at 05:37:37PM +0000, Johan Hovold wrote:
> Add "micrel,rmii_ref_clk_sel_25_mhz" to Micrel ethernet PHY binding
> documentation.
>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---
> Documentation/devicetree/bindings/net/micrel.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/micrel.txt b/Documentation/devicetree/bindings/net/micrel.txt
> index a1bab5eaae02..9b08dd6551dd 100644
> --- a/Documentation/devicetree/bindings/net/micrel.txt
> +++ b/Documentation/devicetree/bindings/net/micrel.txt
> @@ -19,6 +19,11 @@ Optional properties:
>
> See the respective PHY datasheet for the mode values.
>
> + - micrel,rmii_ref_clk_sel_25_mhz: rmii_ref_clk_sel bit selects 25 MHz mode
> +
> + Whether 25 MHz (rather than 50 Mhz) clock mode is selected
> + when the rmii_ref_clk_sel bit is set.
s/_/-/ in property names please.
That said, I don't follow the meaning. Does this cause the kernel to do
something different, or is is simply that a 25MHz ref clock is wired up?
Surely that should be described via the common clock bindings? Or if
internal through a clock-frequency property?
Mark.
^ permalink raw reply
* Re: [net-next PATCH v3 4/5] fm10k/igb/ixgbe: Replace __skb_alloc_page with dev_alloc_page
From: David Miller @ 2014-11-11 17:57 UTC (permalink / raw)
To: jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w
Cc: alexander.h.duyck-H+wXaHxf7aLQT0dZR+AlfA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
leedom-ut6Up61K2wZBDgjK7y7TUQ, hariprasad-ut6Up61K2wZBDgjK7y7TUQ,
donald.c.skidmore-ral2JQCrhuEAvxtiuMwx3w,
oliver-GvhC2dPhHPQdnm+yROfE0A, balbi-l0cyMroinI0,
matthew.vick-ral2JQCrhuEAvxtiuMwx3w, mgorman-l3A5Bk7waGM
In-Reply-To: <1415728594.2466.173.camel@jtkirshe-mobl>
From: Jeff Kirsher <jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date: Tue, 11 Nov 2014 09:56:34 -0800
> On Tue, 2014-11-11 at 12:48 -0500, David Miller wrote:
>> I think this entire series will need to go via my tree, because the
>> conversions are all required for patch #5 which removes the replaced
>> interface altogether.
>
> That is fine Dave, I think I mentioned that during Alex's v1 of the
> series. I was just letting Alex know that we were going to test his
> changes, but feel free to pull the entire series.
>
> I will give you my ACK
>
> Acked-by: Jeff Kirsher <jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Great, thanks for the clarification.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] brcmfmac: unlink URB when request timed out
From: Arend van Spriel @ 2014-11-11 18:00 UTC (permalink / raw)
To: Mathy Vanhoef, brudley-dY08KVG/lbpWk0Htik3J/w,
frankyl-dY08KVG/lbpWk0Htik3J/w, meuleman-dY08KVG/lbpWk0Htik3J/w,
linville-2XuSBdqkA4R54TAoqtyWWQ, pieterpg-dY08KVG/lbpWk0Htik3J/w,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
brcm80211-dev-list-dY08KVG/lbpWk0Htik3J/w,
netdev-u79uwXL29TY76Z2rM5mHXA, Oliver Neukum
In-Reply-To: <546248FD.8020209-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 11-11-14 18:35, Mathy Vanhoef wrote:
> Using usb_kill_urb() instead of usb_unlink_urb() seems to work without any problems.
Ok, as usb_kill_urb() assures the completion handler is called there is
no need to check the ctl_completed flag, ie. my patch. Go ahead and
resubmit your patch replacing usb_unlink_urb() by usb_kill_urb().
Do you mean you end up with a working usb device providing a wireless
interface? Or does probe still fail, but you do not get a crash.
Regards,
Arend
> On 11/11/2014 06:05 AM, Arend van Spriel wrote:
>> On 10-11-14 17:08, Mathy Vanhoef wrote:
>>> On 11/10/2014 06:18 AM, Arend van Spriel wrote:
>>>> On 09-11-14 19:10, Mathy Vanhoef wrote:
>>>>> From: Mathy Vanhoef <vanhoefm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>>>
>>>>> Unlink the submitted URB in brcmf_usb_dl_cmd if the request timed out. This
>>>>> assures the URB is never submitted twice, preventing a driver crash.
>>>>
>>>> Hi Mathy,
>>>>
>>>> What driver crash are you referring to? The log only shows the WARNING
>>>> ending in a USB disconnect but no actual crash. Does your patch get the
>>>> driver running properly or does it only avoid the warning.
>>>
>>> Hi Arend,
>>>
>>> It shows a warning, after which the device doesn't work (but the computer is
>>> still usable). But I've noticed that when *unplugging* the USB cable the OS may
>>> freeze. This doesn't always happen though, sometimes unplugging works OK. The
>>> patch both avoids the warning, and gets the device/driver running properly
>>> (unplugging also works OK).
>>>
>>>>
>>>> With that said, it seems there is some need for improvement, but I also
>>>> notice you are running this on a virtual machine so could that affect
>>>> the timeout to kick in before completion. Could you try to increase the
>>>> timeout. Still when a timeout occurs this needs to be handled properly.
>>>> Could you also try the following patch?
>>>
>>> I did a few additional tests:
>>>
>>> 1. When increasing IOCTL_RESP_TIMEOUT to 20000 (ten times the normal value) the
>>> timeout and warning still occur. Device/driver doesn't work.
>>> 2. When increasing BRCMF_USB_RESET_GETVER_SPINWAIT to 1000 (ten timers the
>>> normal value) everything works. Device/driver works.
>>
>> This means the ctl_urb completes on your system within 3sec, but not
>> within 2.1sec. After discussing this with my colleague, we think you
>> should use usb_kill_urb() instead of usb_unlink_urb() as it assures the
>> completion handler is called. Could you retest that and let us know.
>>
>> Regards,
>> Arend
>>
>>> 3. Quick test using backports-3.18-rc1-1 (aka unpatched driver) on a non-
>>> virtualized Linux install: In that case everything worked fine. So the bug
>>> may only be triggered in a virtualized environment / VMWare.
>>> 4. When applying your patch, the driver stops early during initialization of
>>> the device. I included a WARN_ONCE before returning EINVAL and got the
>>> output below.
>>>
>>> Kind regards,
>>> Mathy
>>> ---
>>> [ 220.955647] usb 1-1: new high-speed USB device number 3 using ehci-pci
>>> [ 221.487797] usb 1-1: New USB device found, idVendor=043e, idProduct=3004
>>> [ 221.487802] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
>>> [ 221.487804] usb 1-1: Product: Remote Download Wireless Adapter
>>> [ 221.487806] usb 1-1: Manufacturer: Broadcom
>>> [ 221.487808] usb 1-1: SerialNumber: 000000000001
>>> [ 221.490472] brcmfmac: brcmf_usb_probe Enter 0x043e:0x3004
>>> [ 221.490476] brcmfmac: brcmf_usb_probe Broadcom high speed USB WLAN interface detected
>>> [ 221.490477] brcmfmac: brcmf_usb_probe_cb Enter
>>> [ 221.490480] brcmfmac: brcmf_usb_attach Enter
>>> [ 221.490494] brcmfmac: brcmf_usb_dlneeded Enter
>>> [ 221.490495] ------------[ cut here ]------------
>>> [ 221.490503] WARNING: CPU: 0 PID: 100 at drivers/net/wireless/brcm80211/brcmfmac/usb.c:716 brcmf_usb_dl_cmd+0x75/0x1a0 [brcmfmac]()
>>> [ 221.490505] EINVAL devinfo=c0044000 ctl_rub=ef898380 completed=0
>>> [ 221.490506] Modules linked in: brcmfmac brcmutil vmw_pvscsi pcnet32 mptspi mptscsih mptbase
>>> [ 221.490514] CPU: 0 PID: 100 Comm: kworker/0:1 Not tainted 3.18.0-rc3-wl+ #2
>>> [ 221.490515] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
>>> [ 221.490528] Workqueue: usb_hub_wq hub_event
>>> [ 221.490530] 00000000 00000000 eecffb58 c1711f4a eecffb98 eecffb88 c103edaf f11cbc58
>>> [ 221.490534] eecffbb4 00000064 f11cbc84 000002cc f11c1595 f11c1595 c0044000 ffffffea
>>> [ 221.490537] ef726000 eecffba0 c103ee4e 00000009 eecffb98 f11cbc58 eecffbb4 eecffbd0
>>> [ 221.490541] Call Trace:
>>> [ 221.490550] [<c1711f4a>] dump_stack+0x41/0x52
>>> [ 221.490558] [<c103edaf>] warn_slowpath_common+0x7f/0xa0
>>> [ 221.490563] [<f11c1595>] ? brcmf_usb_dl_cmd+0x75/0x1a0 [brcmfmac]
>>> [ 221.490567] [<f11c1595>] ? brcmf_usb_dl_cmd+0x75/0x1a0 [brcmfmac]
>>> [ 221.490570] [<c103ee4e>] warn_slowpath_fmt+0x2e/0x30
>>> [ 221.490575] [<f11c1595>] brcmf_usb_dl_cmd+0x75/0x1a0 [brcmfmac]
>>> [ 221.490580] [<f11c2cd8>] brcmf_usb_probe+0x3c8/0x640 [brcmfmac]
>>> [ 221.490583] [<c1717d53>] ? mutex_lock+0x13/0x32
>>> [ 221.490586] [<c1493ae3>] usb_probe_interface+0xa3/0x180
>>> [ 221.490590] [<c13f5690>] ? __driver_attach+0x90/0x90
>>> [ 221.490592] [<c13f546e>] driver_probe_device+0x5e/0x1f0
>>> [ 221.490595] [<c13f5690>] ? __driver_attach+0x90/0x90
>>> [ 221.490597] [<c13f56c9>] __device_attach+0x39/0x50
>>> [ 221.490600] [<c13f3d84>] bus_for_each_drv+0x34/0x70
>>> [ 221.490602] [<c13f53db>] device_attach+0x7b/0x90
>>> [ 221.490604] [<c13f5690>] ? __driver_attach+0x90/0x90
>>> [ 221.490607] [<c13f4b8f>] bus_probe_device+0x6f/0x90
>>> [ 221.490609] [<c13f3256>] device_add+0x426/0x520
>>> [ 221.490611] [<c1491503>] ? usb_control_msg+0xb3/0xd0
>>> [ 221.490614] [<c1717d53>] ? mutex_lock+0x13/0x32
>>> [ 221.490627] [<c14922f8>] usb_set_configuration+0x3f8/0x700
>>> [ 221.490630] [<c13f5690>] ? __driver_attach+0x90/0x90
>>> [ 221.490633] [<c149ac7b>] generic_probe+0x2b/0x90
>>> [ 221.490637] [<c1188bc0>] ? sysfs_create_link+0x20/0x40
>>> [ 221.490639] [<c1492bec>] usb_probe_device+0xc/0x10
>>> [ 221.490641] [<c13f546e>] driver_probe_device+0x5e/0x1f0
>>> [ 221.490644] [<c13f5690>] ? __driver_attach+0x90/0x90
>>> [ 221.490646] [<c13f56c9>] __device_attach+0x39/0x50
>>> [ 221.490649] [<c13f3d84>] bus_for_each_drv+0x34/0x70
>>> [ 221.490651] [<c13f53db>] device_attach+0x7b/0x90
>>> [ 221.490653] [<c13f5690>] ? __driver_attach+0x90/0x90
>>> [ 221.490656] [<c13f4b8f>] bus_probe_device+0x6f/0x90
>>> [ 221.490658] [<c13f3256>] device_add+0x426/0x520
>>> [ 221.490661] [<c148aa2e>] ? usb_new_device+0x16e/0x3a0
>>> [ 221.490663] [<c148aad7>] usb_new_device+0x217/0x3a0
>>> [ 221.490666] [<c148bff7>] hub_event+0xa17/0xda0
>>> [ 221.490668] [<c1716918>] ? __schedule+0x2f8/0x710
>>> [ 221.490672] [<c105127c>] ? pwq_dec_nr_in_flight+0x3c/0x90
>>> [ 221.490674] [<c10513ee>] process_one_work+0x11e/0x360
>>> [ 221.490677] [<c1051750>] worker_thread+0xf0/0x3c0
>>> [ 221.490680] [<c106e14a>] ? __wake_up_locked+0x1a/0x20
>>> [ 221.490682] [<c1051660>] ? process_scheduled_works+0x30/0x30
>>> [ 221.490685] [<c1055b56>] kthread+0x96/0xb0
>>> [ 221.490687] [<c1050000>] ? put_unbound_pool+0x110/0x170
>>> [ 221.490691] [<c1719c81>] ret_from_kernel_thread+0x21/0x30
>>> [ 221.490693] [<c1055ac0>] ? kthread_worker_fn+0x110/0x110
>>> [ 221.490695] ---[ end trace 9befd914693f3083 ]---
>>> [ 221.490697] brcmfmac: brcmf_usb_dlneeded chip 57005 rev 0xf11cfcec
>>> [ 221.490699] brcmfmac: brcmf_fw_get_firmwares enter: dev=1-1
>>>
>>> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/usb.c b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
>>> index 5265aa7..15b1aa7 100644
>>> --- a/drivers/net/wireless/brcm80211/brcmfmac/usb.c
>>> +++ b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
>>> @@ -709,8 +709,13 @@ static int brcmf_usb_dl_cmd(struct brcmf_usbdev_info *devinfo, u8 cmd,
>>> char *tmpbuf;
>>> u16 size;
>>>
>>> - if ((!devinfo) || (devinfo->ctl_urb == NULL))
>>> + if (!devinfo || !devinfo->ctl_urb || !devinfo->ctl_completed) {
>>> + WARN_ONCE(1, "EINVAL devinfo=%p ctl_rub=%p completed=%d\n",
>>> + devinfo,
>>> + devinfo ? devinfo->ctl_urb : NULL,
>>> + devinfo ? devinfo->ctl_completed : -1);
>>> return -EINVAL;
>>> + }
>>>
>>> tmpbuf = kmalloc(buflen, GFP_ATOMIC);
>>> if (!tmpbuf)
>>>
>>>
>>>>
>>>> Regards,
>>>> Arend
>>>> ---
>>>> drivers/net/wireless/brcm80211/brcmfmac/usb.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/usb.c
>>>> b/drivers/net/wireles
>>>> index dc13591..786c40b 100644
>>>> --- a/drivers/net/wireless/brcm80211/brcmfmac/usb.c
>>>> +++ b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
>>>> @@ -640,7 +640,7 @@ static int brcmf_usb_dl_cmd(struct brcmf_usbdev_info
>>>> *devinf
>>>> char *tmpbuf;
>>>> u16 size;
>>>>
>>>> - if ((!devinfo) || (devinfo->ctl_urb == NULL))
>>>> + if (!devinfo || !devinfo->ctl_urb || !devinfo->ctl_completed)
>>>> return -EINVAL;
>>>>
>>>> tmpbuf = kmalloc(buflen, GFP_ATOMIC);
>>>>
>>>>> Signed-off-by: Mathy Vanhoef <vanhoefm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>>> ---
>>>>> Currently brcmfmac may crash when a USB device is attached (tested with a LG
>>>>> TWFM-B003D). In particular it fails on the second call to brcmf_usb_dl_cmd in
>>>>> the while loop of brcmf_usb_resetcfg. The problem is that an URB is being
>>>>> submitted twice:
>>>>>
>>>>> [ 169.861800] brcmfmac: brcmf_usb_dl_writeimage Enter, fw f14db000, len 348160
>>>>> [ 171.787791] brcmfmac: brcmf_usb_dl_writeimage Exit, err=0
>>>>> [ 171.787797] brcmfmac: brcmf_usb_dlstart Exit, err=0
>>>>> [ 171.787799] brcmfmac: brcmf_usb_dlrun Enter
>>>>> [ 171.791794] brcmfmac: brcmf_usb_resetcfg Enter
>>>>> [ 173.988072] ------------[ cut here ]------------
>>>>> [ 173.988083] WARNING: CPU: 0 PID: 369 at drivers/usb/core/urb.c:339 usb_submit_urb+0x4e6/0x500()
>>>>> [ 173.988085] URB eaf45f00 submitted while active
>>>>> [ 173.988086] Modules linked in: brcmfmac brcmutil vmw_pvscsi pcnet32 mptspi mptscsih mptbase
>>>>> [ 173.988100] CPU: 0 PID: 369 Comm: kworker/0:2 Not tainted 3.18.0-rc3-wl #1
>>>>> [ 173.988102] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
>>>>> [ 173.988106] Workqueue: events request_firmware_work_func
>>>>> [ 173.988108] 00000000 00000000 ee747db8 c1711f4a ee747df8 ee747de8 c103edaf c18d1e10
>>>>> [ 173.988112] ee747e14 00000171 c18a8b29 00000153 c1490556 c1490556 eaf45f00 eafdc660
>>>>> [ 173.988115] f14b8fa0 ee747e00 c103ee4e 00000009 ee747df8 c18d1e10 ee747e14 ee747e50
>>>>> [ 173.988119] Call Trace:
>>>>> [ 173.988129] [<c1711f4a>] dump_stack+0x41/0x52
>>>>> [ 173.988136] [<c103edaf>] warn_slowpath_common+0x7f/0xa0
>>>>> [ 173.988139] [<c1490556>] ? usb_submit_urb+0x4e6/0x500
>>>>> [ 173.988141] [<c1490556>] ? usb_submit_urb+0x4e6/0x500
>>>>> [ 173.988147] [<f14b8fa0>] ? brcmf_usb_ioctl_resp_wake+0x40/0x40 [brcmfmac]
>>>>> [ 173.988150] [<c103ee4e>] warn_slowpath_fmt+0x2e/0x30
>>>>> [ 173.988152] [<c1490556>] usb_submit_urb+0x4e6/0x500
>>>>> [ 173.988156] [<c1123de1>] ? __kmalloc+0x21/0x140
>>>>> [ 173.988161] [<f14b91c3>] ? brcmf_usb_dl_cmd+0x33/0x120 [brcmfmac]
>>>>> [ 173.988166] [<f14b9243>] brcmf_usb_dl_cmd+0xb3/0x120 [brcmfmac]
>>>>> [ 173.988170] [<f14ba6c4>] brcmf_usb_probe_phase2+0x4e4/0x640 [brcmfmac]
>>>>> [ 173.988176] [<f14b4900>] brcmf_fw_request_code_done+0xd0/0xf0 [brcmfmac]
>>>>> [ 173.988178] [<c1400876>] request_firmware_work_func+0x26/0x50
>>>>> [ 173.988182] [<c10513ee>] process_one_work+0x11e/0x360
>>>>> [ 173.988184] [<c1051750>] worker_thread+0xf0/0x3c0
>>>>> [ 173.988205] [<c106e14a>] ? __wake_up_locked+0x1a/0x20
>>>>> [ 173.988208] [<c1051660>] ? process_scheduled_works+0x30/0x30
>>>>> [ 173.988211] [<c1055b56>] kthread+0x96/0xb0
>>>>> [ 173.988214] [<c1719c81>] ret_from_kernel_thread+0x21/0x30
>>>>> [ 173.988217] [<c1055ac0>] ? kthread_worker_fn+0x110/0x110
>>>>> [ 173.988219] ---[ end trace 0c88bf46801de083 ]---
>>>>> [ 173.988221] brcmf_usb_dl_cmd: usb_submit_urb failed -16
>>>>> [ 173.988396] brcmfmac: brcmf_usb_probe_phase2 failed: dev=1-1, err=-19
>>>>> [ 173.989503] brcmfmac: brcmf_usb_disconnect Enter
>>>>>
>>>>> This patch fixes the brcmf_usb_dl_cmd function to prevent an URB from being
>>>>> submitted twice. Tested using a LG TWFM-B003D, which now works properly.
>>>>>
>>>>>
>>>>> drivers/net/wireless/brcm80211/brcmfmac/usb.c | 6 ++++--
>>>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/usb.c b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
>>>>> index 5265aa7..1bc7858 100644
>>>>> --- a/drivers/net/wireless/brcm80211/brcmfmac/usb.c
>>>>> +++ b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
>>>>> @@ -738,10 +738,12 @@ static int brcmf_usb_dl_cmd(struct brcmf_usbdev_info *devinfo, u8 cmd,
>>>>> goto finalize;
>>>>> }
>>>>>
>>>>> - if (!brcmf_usb_ioctl_resp_wait(devinfo))
>>>>> + if (!brcmf_usb_ioctl_resp_wait(devinfo)) {
>>>>> + usb_unlink_urb(devinfo->ctl_urb);
>>>>> ret = -ETIMEDOUT;
>>>>> - else
>>>>> + } else {
>>>>> memcpy(buffer, tmpbuf, buflen);
>>>>> + }
>>>>>
>>>>> finalize:
>>>>> kfree(tmpbuf);
>>>>>
>>>>
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 00/22] net: phy: refactoring and Micrel features
From: Johan Hovold @ 2014-11-11 18:00 UTC (permalink / raw)
To: David Miller; +Cc: johan, f.fainelli, linux-kernel, netdev, bth
In-Reply-To: <20141111.124936.272547351489598665.davem@davemloft.net>
On Tue, Nov 11, 2014 at 12:49:36PM -0500, David Miller wrote:
> 22 patches is just too much, sorry.
>
> Please reduce this down to something closer to ~10 or so patches.
>
> If necessary you can do two series, submit the first 10 and then
> when that's reviewed and accepted submit the second set.
No problem. The three driver-registration patches are really
self-contained and could be reviewed and applied separately, and then I
split the remaining ones where I add the device-type abstraction, that
is:
Series 1:
net: phy: add module_phy_driver macro
net: phy: replace phy_driver_register calls
net: phy: replace phy_drivers_register calls
Series 2:
dt/bindings: fix documentation of ethernet-phy compatible property
net: phy: micrel: fix config_intr error handling
net: phy: micrel: use BIT macro
net: phy: micrel: refactor broadcast disable
net: phy: micrel: disable broadcast for KSZ8081/KSZ8091
net: phy: micrel: add led-mode sanity check
net: phy: micrel: refactor led-mode error handling
net: phy: micrel: clean up led-mode setup
net: phy: micrel: enable led-mode for KSZ8081/KSZ8091
Series 3 (submitted after review of Series 2):
net: phy: add static data field to struct phy_driver
net: phy: micrel: add device-type abstraction
net: phy: micrel: parse of nodes at probe
net: phy: micrel: add has-broadcast-disable flag to type data
net: phy: micrel: add generic rmii-ref-clk-sel support
net: phy: micrel: add support for rmii_ref_clk_sel to KSZ8081/KSZ8091
dt/bindings: add micrel,rmii_ref_clk_sel_25_mhz to eth-phy binding
net: phy: micrel: refactor interrupt config
net: phy: micrel: add copyright entry
net: phy: micrel: use generic config_init for KSZ8021/KSZ8031
Thanks,
Johan
^ permalink raw reply
* Re: [PATCH 00/22] net: phy: refactoring and Micrel features
From: Florian Fainelli @ 2014-11-11 18:01 UTC (permalink / raw)
To: Johan Hovold, David Miller; +Cc: linux-kernel, netdev, bth
In-Reply-To: <20141111180024.GG29789@localhost>
On 11/11/2014 10:00 AM, Johan Hovold wrote:
> On Tue, Nov 11, 2014 at 12:49:36PM -0500, David Miller wrote:
>> 22 patches is just too much, sorry.
>>
>> Please reduce this down to something closer to ~10 or so patches.
>>
>> If necessary you can do two series, submit the first 10 and then
>> when that's reviewed and accepted submit the second set.
>
> No problem. The three driver-registration patches are really
> self-contained and could be reviewed and applied separately, and then I
> split the remaining ones where I add the device-type abstraction, that
> is:
Sounds like a reasonable plan to me. Thanks!
>
> Series 1:
> net: phy: add module_phy_driver macro
> net: phy: replace phy_driver_register calls
> net: phy: replace phy_drivers_register calls
>
> Series 2:
> dt/bindings: fix documentation of ethernet-phy compatible property
> net: phy: micrel: fix config_intr error handling
> net: phy: micrel: use BIT macro
> net: phy: micrel: refactor broadcast disable
> net: phy: micrel: disable broadcast for KSZ8081/KSZ8091
> net: phy: micrel: add led-mode sanity check
> net: phy: micrel: refactor led-mode error handling
> net: phy: micrel: clean up led-mode setup
> net: phy: micrel: enable led-mode for KSZ8081/KSZ8091
>
> Series 3 (submitted after review of Series 2):
> net: phy: add static data field to struct phy_driver
> net: phy: micrel: add device-type abstraction
> net: phy: micrel: parse of nodes at probe
> net: phy: micrel: add has-broadcast-disable flag to type data
> net: phy: micrel: add generic rmii-ref-clk-sel support
> net: phy: micrel: add support for rmii_ref_clk_sel to KSZ8081/KSZ8091
> dt/bindings: add micrel,rmii_ref_clk_sel_25_mhz to eth-phy binding
> net: phy: micrel: refactor interrupt config
> net: phy: micrel: add copyright entry
> net: phy: micrel: use generic config_init for KSZ8021/KSZ8031
>
> Thanks,
> Johan
>
^ permalink raw reply
* Re: question about ethtool bits?
From: Ben Hutchings @ 2014-11-11 18:12 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: netdev
In-Reply-To: <20141110124718.00004efc@unknown>
[-- Attachment #1: Type: text/plain, Size: 941 bytes --]
On Mon, 2014-11-10 at 12:47 -0800, Jesse Brandeburg wrote:
> Ben et al,
>
> So, I was just looking at adding some more types/speeds to
> ethtool.h and noticed we are about out of bits in ecmd->advertising
> (and others), which are declared u32.
>
> We currently have room for one more type (bit 31) and then all 32 bits
> will be full.
Right, I've been seeing this coming for a while.
[...]
> There are two u32's reserved at the end of ethtool_cmd.
>
> Suggestions?
Any extension needs to be applied to all of advertising, supported and
lp_advertising. So we could take 6 of the 8 reserved bytes and extend
them all by 16 bits.
Whoever does this should add getter/setter functions, as has been done
with the extension of speed.
Ben.
--
Ben Hutchings
Experience is directly proportional to the value of equipment destroyed.
- Carolyn Scheppner
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [PATCH 19/22] dt/bindings: add micrel,rmii_ref_clk_sel_25_mhz to eth-phy binding
From: Johan Hovold @ 2014-11-11 18:18 UTC (permalink / raw)
To: Mark Rutland
Cc: Johan Hovold, Florian Fainelli, David S. Miller,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20141111175741.GF25295@leverpostej>
On Tue, Nov 11, 2014 at 05:57:42PM +0000, Mark Rutland wrote:
> On Tue, Nov 11, 2014 at 05:37:37PM +0000, Johan Hovold wrote:
> > Add "micrel,rmii_ref_clk_sel_25_mhz" to Micrel ethernet PHY binding
> > documentation.
> >
> > Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Signed-off-by: Johan Hovold <johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > ---
> > Documentation/devicetree/bindings/net/micrel.txt | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/net/micrel.txt b/Documentation/devicetree/bindings/net/micrel.txt
> > index a1bab5eaae02..9b08dd6551dd 100644
> > --- a/Documentation/devicetree/bindings/net/micrel.txt
> > +++ b/Documentation/devicetree/bindings/net/micrel.txt
> > @@ -19,6 +19,11 @@ Optional properties:
> >
> > See the respective PHY datasheet for the mode values.
> >
> > + - micrel,rmii_ref_clk_sel_25_mhz: rmii_ref_clk_sel bit selects 25 MHz mode
> > +
> > + Whether 25 MHz (rather than 50 Mhz) clock mode is selected
> > + when the rmii_ref_clk_sel bit is set.
>
> s/_/-/ in property names please.
Ouch, copied from variable name, sorry.
> That said, I don't follow the meaning. Does this cause the kernel to do
> something different, or is is simply that a 25MHz ref clock is wired up?
Yes, the driver currently sets this configuration bit based on a common
clock binding.
However, it turns out the meaning of the bit is reversed on some PHY
variants. On most PHYs 50 MHz mode is selected by setting this bit,
whereas on the PHYs that need this new property, setting it selects 25
MHz mode instead.
> Surely that should be described via the common clock bindings? Or if
> internal through a clock-frequency property?
The driver currently selects the mode using the common clock bindings,
but this new property is needed to properly handle those PHY variants on
which the clock configuration bit has the reverse meaning.
Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 net-next 0/2] net: SO_INCOMING_CPU support
From: David Miller @ 2014-11-11 18:18 UTC (permalink / raw)
To: edumazet; +Cc: netdev, ncardwell, willemb, ycai
In-Reply-To: <1415714068-21028-1-git-send-email-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Tue, 11 Nov 2014 05:54:26 -0800
> SO_INCOMING_CPU socket option (read by getsockopt()) provides
> an alternative to RPS/RFS for high performance servers using
> multi queues NIC.
>
> TCP should use sk_mark_napi_id() for established sockets only.
Series applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH V3 net-next 0/2] mlx4: Add CHECKSUM_COMPLETE support
From: David Miller @ 2014-11-11 18:23 UTC (permalink / raw)
To: ogerlitz; +Cc: netdev, matanb, amirv, saeedm, shanim, idos
In-Reply-To: <1415533913-7012-1-git-send-email-ogerlitz@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Sun, 9 Nov 2014 13:51:51 +0200
> These patches from Shani, Matan and myself add support for
> CHECKSUM_COMPLETE reporting on non TCP/UDP packets such as
> GRE and ICMP. I'd like to deeply thank Jerry Chu for his
> innovation and support in that effort.
>
> Based on the feedback from Eric and Ido Shamay, in V2 we dropped
> the patch which removed the calls to napi_gro_frags() and added
> a patch which makes the RX code to go through that path
> regardless of the checksum status.
Series applied, thanks Or.
^ permalink raw reply
* Re: [PATCH net] net/mlx4_en: Advertize encapsulation offloads features only when VXLAN tunnel is set
From: David Miller @ 2014-11-11 18:25 UTC (permalink / raw)
To: ogerlitz; +Cc: netdev, fw, amirv, saeedm
In-Reply-To: <1415535939-30681-1-git-send-email-ogerlitz@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Sun, 9 Nov 2014 14:25:39 +0200
> Currenly we only support Large-Send and TX checksum offloads for
> encapsulated traffic of type VXLAN. We must make sure to advertize
> these offloads up to the stack only when VXLAN tunnel is set.
>
> Failing to do so, would mislead the the networking stack to assume
> that the driver can offload the internal TX checksum for GRE packets
> and other buggy schemes.
>
> Reported-by: Florian Westphal <fw@strlen.de>
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Applied, thanks.
^ permalink raw reply
* [net] ixgbe: phy: fix uninitialized status in ixgbe_setup_phy_link_tnx
From: Jeff Kirsher @ 2014-11-11 18:22 UTC (permalink / raw)
To: davem; +Cc: Daniel Borkmann, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
From: Daniel Borkmann <dborkman@redhat.com>
Status variable is never initialized, can carry an arbitrary value
on the stack and thus may let the function fail.
Fixes: e90dd2645664 ("ixgbe: Make return values more direct")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Acked-by: Emil Tantilov <emil.s.tantilov@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c
index d47b19f..28b81ae0 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c
@@ -635,7 +635,6 @@ s32 ixgbe_check_phy_link_tnx(struct ixgbe_hw *hw, ixgbe_link_speed *speed,
**/
s32 ixgbe_setup_phy_link_tnx(struct ixgbe_hw *hw)
{
- s32 status;
u16 autoneg_reg = IXGBE_MII_AUTONEG_REG;
bool autoneg = false;
ixgbe_link_speed speed;
@@ -700,8 +699,7 @@ s32 ixgbe_setup_phy_link_tnx(struct ixgbe_hw *hw)
hw->phy.ops.write_reg(hw, MDIO_CTRL1,
MDIO_MMD_AN, autoneg_reg);
-
- return status;
+ return 0;
}
/**
--
1.9.3
^ permalink raw reply related
* Re: [RFC PATCH net-next] net: Convert LIMIT_NETDEBUG to net_dbg_ratelimited
From: David Miller @ 2014-11-11 18:30 UTC (permalink / raw)
To: joe; +Cc: netdev, linux-kernel, courmisch
In-Reply-To: <1415560642.23530.43.camel@perches.com>
From: Joe Perches <joe@perches.com>
Date: Sun, 09 Nov 2014 11:17:22 -0800
> Use the more common dynamic_debug capable net_dbg_ratelimited
> and remove the LIMIT_NETDEBUG macro.
>
> This may have some negative impact on messages that were
> emitted at KERN_INFO that are not not enabled at all unless
> DEBUG is defined or dynamic_debug is enabled. Even so,
> these messages are now _not_ emitted by default.
>
> This eliminates the use of the net_msg_warn sysctl
> "/proc/sys/net/core/warnings".
>
> All messages are still ratelimited.
>
> Some KERN_LEVEL uses are changed to KERN_DEBUG.
>
> Miscellanea:
>
> o Update the sysctl documentation
> o Remove the embedded uses of pr_fmt
> o Coalesce format fragments
> o Realign arguments
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
>
> Let me know if you want this consolidate patch broken up
> into multiple patches or any of the messages and the
> macro kept.
No objections, please respin with the variable moved and the EXPORT_SYMBOL
removed.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] dsa: Use netdev_<level> instead of printk
From: David Miller @ 2014-11-11 18:31 UTC (permalink / raw)
To: joe; +Cc: netdev, linux-kernel, f.fainelli
In-Reply-To: <1415579566.23530.47.camel@perches.com>
From: Joe Perches <joe@perches.com>
Date: Sun, 09 Nov 2014 16:32:46 -0800
> Neaten and standardize the logging output.
>
> Other miscellanea:
>
> o Use pr_notice_once instead of a guard flag.
> o Convert existing pr_<level> uses too.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied, thanks Joe.
^ permalink raw reply
* Re: [GIT net-next] Open vSwitch
From: David Miller @ 2014-11-11 18:34 UTC (permalink / raw)
To: pshelar; +Cc: netdev
In-Reply-To: <1415591939-1535-1-git-send-email-pshelar@nicira.com>
From: Pravin B Shelar <pshelar@nicira.com>
Date: Sun, 9 Nov 2014 19:58:59 -0800
> Following batch of patches brings feature parity between upstream
> ovs and out of tree ovs module.
>
> Two features are added, first adds support to export egress
> tunnel information for a packet. This is used to improve
> visibility in network traffic. Second feature allows userspace
> vswitchd process to probe ovs module features. Other patches
> are optimization and code cleanup.
Pulled, thanks Pravin.
^ permalink raw reply
* Re: [PATCH v2] VNIC: Adding support for Cavium ThunderX network controller
From: David Miller @ 2014-11-11 18:39 UTC (permalink / raw)
To: rric
Cc: stephen, sassmann, linux-kernel, linux-arm-kernel, netdev,
sgoutham, rrichter
In-Reply-To: <1415596445-10061-1-git-send-email-rric@kernel.org>
From: Robert Richter <rric@kernel.org>
Date: Sun, 9 Nov 2014 21:14:05 -0800
> +config NET_VENDOR_CAVIUM
...
> +config THUNDER_NIC_PF
...
> +config THUNDER_NIC_VF
...
> +config THUNDER_NIC_BGX
These config options seem excessive, if not confusing. What would a
distribution be expected to enable? Everything?
> +# Don't change the order, NICPF driver is dependent on BGX driver init
> +obj-$(CONFIG_THUNDER_NIC_BGX) += thunder_bgx.o
> +obj-$(CONFIG_THUNDER_NIC_PF) += nicpf.o
> +obj-$(CONFIG_THUNDER_NIC_VF) += nicvf.o
Nothing ensures ordering if these things are built all modular.
Such ordering dependencies need to be resolved in another way.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox