* [PATCH] USB2NET : SR9800 : Use %zu to format size_t
From: Geert Uytterhoeven @ 2014-02-17 21:18 UTC (permalink / raw)
To: Liu Junliang, David S. Miller
Cc: linux-usb, netdev, linux-kernel, Geert Uytterhoeven
On 32-bit:
drivers/md/bcache/bset.c: In function ‘bch_dump_bset’:
drivers/md/bcache/bset.c:27: warning: format ‘%li’ expects type ‘long int’, but argument 3 has type ‘int’
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
drivers/net/usb/sr9800.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/sr9800.c b/drivers/net/usb/sr9800.c
index 4175eb9fdeca..801710883727 100644
--- a/drivers/net/usb/sr9800.c
+++ b/drivers/net/usb/sr9800.c
@@ -823,7 +823,7 @@ static int sr9800_bind(struct usbnet *dev, struct usb_interface *intf)
dev->rx_urb_size =
SR9800_BULKIN_SIZE[SR9800_MAX_BULKIN_2K].size;
}
- netdev_dbg(dev->net, "%s : setting rx_urb_size with : %ld\n", __func__,
+ netdev_dbg(dev->net, "%s : setting rx_urb_size with : %zu\n", __func__,
dev->rx_urb_size);
return 0;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] csum_partial_copy_from_user: clean up inconsistencies in implementations
From: David Miller @ 2014-02-17 21:21 UTC (permalink / raw)
To: mpatocka
Cc: netdev, linux-kernel, mcree, mattst88, mathieu.desnoyers,
jay.estabrook
In-Reply-To: <alpine.LRH.2.02.1402151044010.25662@file01.intranet.prod.int.rdu2.redhat.com>
From: Mikulas Patocka <mpatocka@redhat.com>
Date: Sat, 15 Feb 2014 10:49:54 -0500 (EST)
> Here I'm sending a patch for networking to clean up inconsistent
> implementations of csum_partial_copy_from_user in various architectures.
> This patch doesn't fix any bug, but the confusion in implementations
> caused a bug in the past. The patch should be queued for the kernel 3.15.
>
> Mikulas
Please do not add commentary to the main body text of a patch submission,
otherwise I have to edit it out.
The proper way to add commentary is to put it after the "---" delimiter
at the end of the commit message and before the actual patch.
> From: Mikulas Patocka <mpatocka@redhat.com>
>
> csum_partial_copy_from_user is called only from csum_and_copy_from_user in
> include/net/checksum.h. csum_and_copy_from_user verifies the userspace
> range with access_ok, so there is no need to repeat access_ok in the
> implementation of csum_partial_copy_from_user.
>
> Some architectures repeat the acces_ok check anyway, sometimes people were
> adding this check blindly (see patch
> 3ddc5b46a8e90f3c9251338b60191d0a804b0d92 that adds it for the alpha
> architecture) and that caused serious network breakage because in the
> alpha implementation, csum_partial_copy_from_user is also used when
> copying from kernel space (called from the function
> csum_partial_copy_nocheck) and that access_ok check broke it.
>
> There were follow-up patches to fix the alpha breakage
> (5cfe8f1ba5eebe6f4b6e5858cdb1a5be4f3272a6 and
> 0ef38d70d4118b2ce1a538d14357be5ff9dc2bbd), however these patches just add
> junk to the code - the best thing would be to not perform access_ok in
> csum_partial_copy_from_user in the first place.
>
> This patch reverts the access_ok part of
> 3ddc5b46a8e90f3c9251338b60191d0a804b0d92, reverts the patches
> 5cfe8f1ba5eebe6f4b6e5858cdb1a5be4f3272a6 and
> 0ef38d70d4118b2ce1a538d14357be5ff9dc2bbd completely, and drops the check
> for access_ok from other architectures that were performing the check.
>
> This patch also changes all the implementations of
> csum_partial_copy_from_user so that they don't zero the destination buffer
> on page fault - csum_and_copy_from_user is not zeroing the buffer when the
> access_ok fails, so it is pointless to zero the buffer in
> csum_partial_copy_from_user.
>
> The purpose of this patch is to make all the implementations of
> csum_partial_copy_from_user consistent, so that people will keep them
> consistent in the future.
>
> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
That is mainly a cleanup and entirely independent of fixing the Alpha
bug.
You should submit the Alpha bug fix through the usual arch channels
and get that into Linus's tree.
Then, after that fix propagates, you can do the access_ok() global
cleanup as a separate patch targetting net-next.
Thanks.
^ permalink raw reply
* Re: [PATCH] USB2NET : SR9800 : Use %zu to format size_t
From: David Miller @ 2014-02-17 21:21 UTC (permalink / raw)
To: geert; +Cc: liujunliang_ljl, linux-usb, netdev, linux-kernel
In-Reply-To: <1392671920-11489-1-git-send-email-geert@linux-m68k.org>
Already fixed in the net tree.
^ permalink raw reply
* Re: [PATCH net-next 2/3] net: phy: allow PHY drivers to implement their own software reset
From: David Miller @ 2014-02-17 21:23 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, Shaohui.Xie
In-Reply-To: <1392670366-31457-3-git-send-email-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 17 Feb 2014 12:52:45 -0800
> + if (phydev->drv->soft_reset(phydev))
> + ret = phydev->drv->soft_reset(phydev);
You're not testing if the method is NULL, you're actually invoking it.
^ permalink raw reply
* Re: [PATCHv2] irtty-sir.c: Do not set_termios() on irtty_close()
From: David Miller @ 2014-02-17 21:28 UTC (permalink / raw)
To: tommie; +Cc: samuel, netdev, linux-kernel
In-Reply-To: <5302750C.6080407@gannert.se>
From: Tommie Gannert <tommie@gannert.se>
Date: Mon, 17 Feb 2014 20:46:04 +0000
> From: Tommie Gannert <tommie@gannert.se>
>
> Issuing set_termios() from irtty_close() causes kernel Oops for
> unplugged usb-serial devices.
>
> Since no other tty_ldisc calls set_termios() on close and no tty driver
> seem to check if tty->device_data is NULL or not on entry to set_termios(),
> the only solution I can come up with is to remove the irtty_stop_receiver()
> call, which only updates termios.
>
> Signed-off-by: Tommie Gannert <tommie@gannert.se>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH 0/3] Drivers: net: hyperv: Cleanup the hyper-V networking code
From: David Miller @ 2014-02-17 21:32 UTC (permalink / raw)
To: kys; +Cc: netdev, linux-kernel, devel, olaf, apw, jasowang
In-Reply-To: <1392597483-13307-1-git-send-email-kys@microsoft.com>
From: "K. Y. Srinivasan" <kys@microsoft.com>
Date: Sun, 16 Feb 2014 16:38:03 -0800
> Get rid of some unnecessary code and some general cleanup.
>
> K. Y. Srinivasan (3):
> Drivers: net: hyperv: Get rid of the rndis_filter_packet structure
> Drivers: net: hyperv: Cleanup the receive path
> Drivers: net: hyperv: Cleanup the netvsc receive callback functio
Series applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] net: add init-regs for of_phy support
From: Sergei Shtylyov @ 2014-02-17 21:33 UTC (permalink / raw)
To: Florian Fainelli, Ben Dooks
Cc: netdev, devicetree@vger.kernel.org, Linux-sh list
In-Reply-To: <CAGVrzcYbw5xLj-gwcup5i0gBdKDDGdyy5wAaEBp7m2E7f2bytg@mail.gmail.com>
Hello.
On 02/17/2014 08:33 PM, Florian Fainelli wrote:
>> Add new init-regs field for of_phy nodes and make sure these
>> get applied when the phy is configured.
>> This allows any phy node in an fdt to initialise registers
>> that may not be set as standard by the driver at initialisation
>> time, such as LED controls.
>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>> ---
>> Documentation/devicetree/bindings/net/phy.txt | 12 ++++++
>> drivers/net/phy/phy_device.c | 59 ++++++++++++++++++++++++++-
>> 2 files changed, 70 insertions(+), 1 deletion(-)
>> diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
>> index 58307d0..48d8ded 100644
>> --- a/Documentation/devicetree/bindings/net/phy.txt
>> +++ b/Documentation/devicetree/bindings/net/phy.txt
>> @@ -20,6 +20,8 @@ Optional Properties:
>> assume clause 22. The compatible list may also contain other
>> elements.
>> - max-speed: Maximum PHY supported speed (10, 100, 1000...)
>> +- init-regs: Set of registers to modify at initialisation as a
>> + a set of <register set clear>
> Should be:
> "micrel,led-control-init-val" or something like that.
> first cell is the register address, according to the IEEE 802.3 clause 22
> second cell is the set bitmask to apply to the register address
> specified in the first cell
> third cell is the clear bitmask to apply to the register address
> specified in the second cell
> I would rather see this as a specific PHY node DT property for setting
> the LED control register, because this is totally non-standard and you
> are touching a proprietary register here.
Yes, I agree.
>> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
>> index 82514e7..6741cdb 100644
>> --- a/drivers/net/phy/phy_device.c
>> +++ b/drivers/net/phy/phy_device.c
[...]
>> @@ -532,6 +533,57 @@ static int phy_poll_reset(struct phy_device *phydev)
>> return 0;
>> }
>>
>> +#ifdef CONFIG_OF
>> +static int of_phy_configure(struct phy_device *phydev)
>> +{
>> + struct device *dev = &phydev->dev;
>> + struct device_node *of_node = dev->of_node;
>> + struct property *prop;
>> + const __be32 *ptr;
>> + u32 reg, set, clear;
>> + int len;
>> + int val;
> This does not belong in the generic PHY code unless we are very clear
> on what we want to do, and how to do it, which I do not think we are
> yet. What exactly is needed here:
> - fixing up some design mistake?
> - accounting for a specific board design?
Kind of both. This was invented to defy the necessity of having platform
fixup in the DT case (where there should be no board file to place it into).
I have already described that platform fixup necessary on the Renesas
Lager/Koelsch boards where the LED0 signat is connected to ETH_LINK signal on
the SoC and the PHY reset sets the LED control bits to default 0 which means
that LED0 will be LINK/ACTIVITY signal and thus blink on activity and cause
ETH_LINK to bounce off/on after each packet.
> In any case a PHY fixup would do the job for you.
Not in any case. In case of DT we have no place for it, so should invent
something involving DT.
WBR, Sergei
^ permalink raw reply
* [PATCH net-next v2 2/3] net: phy: allow PHY drivers to implement their own software reset
From: Florian Fainelli @ 2014-02-17 21:34 UTC (permalink / raw)
To: netdev; +Cc: davem, Shaohui.Xie, Florian Fainelli
In-Reply-To: <1392672844-1767-1-git-send-email-f.fainelli@gmail.com>
As pointed out by Shaohui, most 10G PHYs out there have a non-standard
compliant software reset sequence, eventually something much more
complex than just toggling the BMCR_RESET bit. Allow PHY driver to
implement their own soft_reset() callback to deal with that. If no
callback is provided, call into genphy_soft_reset() which makes sure the
existing behavior is kept intact.
Reported-by: Shaohui Xie <Shaohui.Xie@freescale.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Changes in v2:
- fix callback testing before actually invoking it
drivers/net/phy/phy_device.c | 16 ++++++++++++++--
include/linux/phy.h | 5 +++++
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 7c21b82..a70b604 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -535,12 +535,16 @@ static int phy_poll_reset(struct phy_device *phydev)
int phy_init_hw(struct phy_device *phydev)
{
- int ret;
+ int ret = 0;
if (!phydev->drv || !phydev->drv->config_init)
return 0;
- ret = genphy_soft_reset(phydev);
+ if (phydev->drv->soft_reset)
+ ret = phydev->drv->soft_reset(phydev);
+ else
+ ret = genphy_soft_reset(phydev);
+
if (ret < 0)
return ret;
@@ -1108,6 +1112,12 @@ static int genphy_config_init(struct phy_device *phydev)
return 0;
}
+static int gen10g_soft_reset(struct phy_device *phydev)
+{
+ /* Do nothing for now */
+ return 0;
+}
+
static int gen10g_config_init(struct phy_device *phydev)
{
/* Temporarily just say we support everything */
@@ -1282,6 +1292,7 @@ static struct phy_driver genphy_driver[] = {
.phy_id = 0xffffffff,
.phy_id_mask = 0xffffffff,
.name = "Generic PHY",
+ .soft_reset = genphy_soft_reset,
.config_init = genphy_config_init,
.features = 0,
.config_aneg = genphy_config_aneg,
@@ -1294,6 +1305,7 @@ static struct phy_driver genphy_driver[] = {
.phy_id = 0xffffffff,
.phy_id_mask = 0xffffffff,
.name = "Generic 10G PHY",
+ .soft_reset = gen10g_soft_reset,
.config_init = gen10g_config_init,
.features = 0,
.config_aneg = gen10g_config_aneg,
diff --git a/include/linux/phy.h b/include/linux/phy.h
index bffe0ec..24126c4 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -440,6 +440,11 @@ struct phy_driver {
u32 flags;
/*
+ * Called to issue a PHY software reset
+ */
+ int (*soft_reset)(struct phy_device *phydev);
+
+ /*
* Called to initialize the PHY,
* including after a reset
*/
--
1.8.3.2
^ permalink raw reply related
* [PATCH net-next v2 1/3] net: phy: move PHY software reset to genphy_soft_reset
From: Florian Fainelli @ 2014-02-17 21:34 UTC (permalink / raw)
To: netdev; +Cc: davem, Shaohui.Xie, Florian Fainelli
In-Reply-To: <1392672844-1767-1-git-send-email-f.fainelli@gmail.com>
As pointed out by Shaohui, this function is generic for 10/100/1000
PHYs, but 10G PHYs might have a slightly different reset sequence which
prevents most of them from using this function.
Move the BMCR_RESET based software resent sequence to
genphy_soft_reset() in preparation for allowing PHY drivers to implement
a soft_reset() callback.
Reported-by: Shaohui Xie <Shaohui.Xie@freescale.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Changes in v2:
- respin
drivers/net/phy/phy_device.c | 27 ++++++++++++++++++++++-----
include/linux/phy.h | 1 +
2 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index c2d778d..7c21b82 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -540,11 +540,7 @@ int phy_init_hw(struct phy_device *phydev)
if (!phydev->drv || !phydev->drv->config_init)
return 0;
- ret = phy_write(phydev, MII_BMCR, BMCR_RESET);
- if (ret < 0)
- return ret;
-
- ret = phy_poll_reset(phydev);
+ ret = genphy_soft_reset(phydev);
if (ret < 0)
return ret;
@@ -1045,6 +1041,27 @@ static int gen10g_read_status(struct phy_device *phydev)
return 0;
}
+/**
+ * genphy_soft_reset - software reset the PHY via BMCR_RESET bit
+ * @phydev: target phy_device struct
+ *
+ * Description: Perform a software PHY reset using the standard
+ * BMCR_RESET bit and poll for the reset bit to be cleared.
+ *
+ * Returns: 0 on success, < 0 on failure
+ */
+int genphy_soft_reset(struct phy_device *phydev)
+{
+ int ret;
+
+ ret = phy_write(phydev, MII_BMCR, BMCR_RESET);
+ if (ret < 0)
+ return ret;
+
+ return phy_poll_reset(phydev);
+}
+EXPORT_SYMBOL(genphy_soft_reset);
+
static int genphy_config_init(struct phy_device *phydev)
{
int val;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index f7fe546..bffe0ec 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -666,6 +666,7 @@ int genphy_update_link(struct phy_device *phydev);
int genphy_read_status(struct phy_device *phydev);
int genphy_suspend(struct phy_device *phydev);
int genphy_resume(struct phy_device *phydev);
+int genphy_soft_reset(struct phy_device *phydev);
void phy_driver_unregister(struct phy_driver *drv);
void phy_drivers_unregister(struct phy_driver *drv, int n);
int phy_driver_register(struct phy_driver *new_driver);
--
1.8.3.2
^ permalink raw reply related
* [PATCH net-next v2 0/3] net: phy: soft reset rework for 10G PHYs
From: Florian Fainelli @ 2014-02-17 21:34 UTC (permalink / raw)
To: netdev; +Cc: davem, Shaohui.Xie, Florian Fainelli
Hi David,
As reported by Shaohui, 10G PHYs may have a slightly more complex reset
sequence for which a BMCR_RESET software reset might not suffice. This
patchset offers a solution for those by allowing them to implement their
own soft_reset() callback. Finally there is an update to the PHY library
Documentation to cover for the newly added callbacks of the PHY driver
structure.
Thanks!
Changes in v2:
- fixed callback testing
- fixed typo in Documentation
Florian Fainelli (3):
net: phy: move PHY software reset to genphy_soft_reset
net: phy: allow PHY drivers to implement their own software reset
Documentation: networking: update phy.txt with recent changes
Documentation/networking/phy.txt | 9 +++++++++
drivers/net/phy/phy_device.c | 39 ++++++++++++++++++++++++++++++++++-----
include/linux/phy.h | 6 ++++++
3 files changed, 49 insertions(+), 5 deletions(-)
--
1.8.3.2
^ permalink raw reply
* [PATCH net-next v2 3/3] Documentation: networking: update phy.txt with recent changes
From: Florian Fainelli @ 2014-02-17 21:34 UTC (permalink / raw)
To: netdev; +Cc: davem, Shaohui.Xie, Florian Fainelli
In-Reply-To: <1392672844-1767-1-git-send-email-f.fainelli@gmail.com>
The PHY library was missing a bunch of newly added PHY driver callbacks
along with a smallish description of what they do, fix that.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Changes in v2:
- fix typo on the soft_reset description
Documentation/networking/phy.txt | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/networking/phy.txt b/Documentation/networking/phy.txt
index ebf2707..e602c6f 100644
--- a/Documentation/networking/phy.txt
+++ b/Documentation/networking/phy.txt
@@ -253,16 +253,25 @@ Writing a PHY driver
Each driver consists of a number of function pointers:
+ soft_reset: perform a PHY software reset
config_init: configures PHY into a sane state after a reset.
For instance, a Davicom PHY requires descrambling disabled.
probe: Allocate phy->priv, optionally refuse to bind.
PHY may not have been reset or had fixups run yet.
suspend/resume: power management
config_aneg: Changes the speed/duplex/negotiation settings
+ aneg_done: Determines the auto-negotiation result
read_status: Reads the current speed/duplex/negotiation settings
ack_interrupt: Clear a pending interrupt
+ did_interrupt: Checks if the PHY generated an interrupt
config_intr: Enable or disable interrupts
remove: Does any driver take-down
+ ts_info: Queries about the HW timestamping status
+ hwtstamp: Set the PHY HW timestamping configuration
+ rxtstamp: Requests a receive timestamp at the PHY level for a 'skb'
+ txtsamp: Requests a transmit timestamp at the PHY level for a 'skb'
+ set_wol: Enable Wake-on-LAN at the PHY level
+ get_wol: Get the Wake-on-LAN status at the PHY level
Of these, only config_aneg and read_status are required to be
assigned by the driver code. The rest are optional. Also, it is
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH net-next 2/3] net: phy: allow PHY drivers to implement their own software reset
From: Florian Fainelli @ 2014-02-17 21:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Shaohui Xie
In-Reply-To: <20140217.162343.325745613056866328.davem@davemloft.net>
2014-02-17 13:23 GMT-08:00 David Miller <davem@davemloft.net>:
> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Mon, 17 Feb 2014 12:52:45 -0800
>
>> + if (phydev->drv->soft_reset(phydev))
>> + ret = phydev->drv->soft_reset(phydev);
>
> You're not testing if the method is NULL, you're actually invoking it.
That, and there was a typo in the Documentation patch, all fixed now, thanks!
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 0/3] bonding: Fix RTNL: assertion failed at net/core/rtnetlink.c
From: David Miller @ 2014-02-17 21:36 UTC (permalink / raw)
To: dingtianhong
Cc: fubar, vfalico, andy, cwang, jiri, thomas, eric.dumazet, sfeldma,
netdev
In-Reply-To: <1392626151-23916-1-git-send-email-dingtianhong@huawei.com>
From: Ding Tianhong <dingtianhong@huawei.com>
Date: Mon, 17 Feb 2014 16:35:48 +0800
> The problem was introduced by the commit 1d3ee88ae0d
> (bonding: add netlink attributes to slave link dev).
> The bond_set_active_slave() and bond_set_backup_slave()
> will use rtmsg_ifinfo to send slave's states, so these
> two functions should be called in RTNL.
>
> In 802.3ad mode, acquiring RTNL for the __enable_port and
> __disable_port cases is difficult, as those calls generally
> already hold the state machine lock, and cannot unconditionally
> call rtnl_lock because either they already hold RTNL (for calls
> via bond_3ad_unbind_slave) or due to the potential for deadlock
> with bond_3ad_adapter_speed_changed, bond_3ad_adapter_duplex_changed,
> bond_3ad_link_change, or bond_3ad_update_lacp_rate. All four of
> those are called with RTNL held, and acquire the state machine lock
> second. The calling contexts for __enable_port and __disable_port
> already hold the state machine lock, and may or may not need RTNL.
>
> According to the Jay's opinion, I don't think it is a problem that
> the slave don't send notify message synchronously when the status
> changed, normally the state machine is running every 100 ms, send
> the notify message at the end of the state machine if the slave's
> state changed should be better.
I would like to ask you to combine these three changes into one
patch.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next v2 0/3] net: phy: soft reset rework for 10G PHYs
From: David Miller @ 2014-02-17 21:41 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, Shaohui.Xie
In-Reply-To: <1392672844-1767-1-git-send-email-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 17 Feb 2014 13:34:01 -0800
> Hi David,
>
> As reported by Shaohui, 10G PHYs may have a slightly more complex reset
> sequence for which a BMCR_RESET software reset might not suffice. This
> patchset offers a solution for those by allowing them to implement their
> own soft_reset() callback. Finally there is an update to the PHY library
> Documentation to cover for the newly added callbacks of the PHY driver
> structure.
>
> Thanks!
>
> Changes in v2:
> - fixed callback testing
> - fixed typo in Documentation
Much better, series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v3 0/10] ieee802154: support rf212 and extended mac features
From: David Miller @ 2014-02-17 21:45 UTC (permalink / raw)
To: phoebe.buckheister; +Cc: netdev, linux-zigbee-devel
In-Reply-To: <1392633255-26605-1-git-send-email-phoebe.buckheister@itwm.fraunhofer.de>
From: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
Date: Mon, 17 Feb 2014 11:34:05 +0100
> this patch set adds support for the RF212 radio chip to the existing
> at86rf230 driver and adds support for numerous features of the RF212
> chips to the ieee802154 stack. These features include CSMA parameter
> configuration, transmit power control, CCA parameter configuration, and
> automatic retransmission of frames. Netlink APIs are provided for all
> new options introduced in this set.
>
> Many features might also work for RF230, but since I have no such chips
> at my disposal, most new features are implemented only for RF212.
>
> Changes since v2:
> * Indentation
> Changes since v1:
> * CodingStyle compliance. Thanks Sergei Shtylyov
> * Add CSMA parameters to netlink phy list that were forgotten in v1
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] ipv4: fix counter in_slow_tot
From: David Miller @ 2014-02-17 21:55 UTC (permalink / raw)
To: duanj.fnst; +Cc: netdev
In-Reply-To: <5301B8FF.6030800@cn.fujitsu.com>
From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Date: Mon, 17 Feb 2014 15:23:43 +0800
> since commit 89aef8921bf("ipv4: Delete routing cache."), the counter
> in_slow_tot can't work correctly.
>
> The counter in_slow_tot increase by one when fib_lookup() return successfully
> in ip_route_input_slow(), but actually the dst struct maybe not be created and
> cached, so we can increase in_slow_tot after the dst struct is created.
>
> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] sch_netem: replace magic numbers with enumerate in get_loss_clg
From: David Miller @ 2014-02-17 21:56 UTC (permalink / raw)
To: yangyingliang; +Cc: netdev, stephen
In-Reply-To: <1392626901-15096-1-git-send-email-yangyingliang@huawei.com>
From: Yang Yingliang <yangyingliang@huawei.com>
Date: Mon, 17 Feb 2014 16:48:21 +0800
> Replace two magic numbers which intialize clgstate::state.
>
> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
> ---
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next 1/4] netlink: fix checkpatch errors space and "foo *bar"
From: David Miller @ 2014-02-17 21:57 UTC (permalink / raw)
To: wangyufen; +Cc: netdev
In-Reply-To: <1392627215-12804-1-git-send-email-wangyufen@huawei.com>
From: Wangyufen <wangyufen@huawei.com>
Date: Mon, 17 Feb 2014 16:53:32 +0800
> From: Wang Yufen <wangyufen@huawei.com>
>
> ERROR: spaces required and "(foo*)" should be "(foo *)"
>
> Signed-off-by: Wang Yufen <wangyufen@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/4] ipv6: fix checkpatch errors with brace and "foo *bar"
From: David Miller @ 2014-02-17 21:58 UTC (permalink / raw)
To: wangyufen; +Cc: netdev
In-Reply-To: <1392627215-12804-2-git-send-email-wangyufen@huawei.com>
From: Wangyufen <wangyufen@huawei.com>
Date: Mon, 17 Feb 2014 16:53:33 +0800
> From: Wang Yufen <wangyufen@huawei.com>
>
>
> Signed-off-by: Wang Yufen <wangyufen@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH 3/4] ipv6: fix checkpatch errors with space required or prohibited
From: David Miller @ 2014-02-17 21:58 UTC (permalink / raw)
To: wangyufen; +Cc: netdev
In-Reply-To: <1392627215-12804-3-git-send-email-wangyufen@huawei.com>
From: Wangyufen <wangyufen@huawei.com>
Date: Mon, 17 Feb 2014 16:53:34 +0800
> From: Wang Yufen <wangyufen@huawei.com>
>
>
> Signed-off-by: Wang Yufen <wangyufen@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH 4/4] ipv6:fix checkpatch errors with assignment in if condition
From: David Miller @ 2014-02-17 21:58 UTC (permalink / raw)
To: wangyufen; +Cc: netdev
In-Reply-To: <1392627215-12804-4-git-send-email-wangyufen@huawei.com>
From: Wangyufen <wangyufen@huawei.com>
Date: Mon, 17 Feb 2014 16:53:35 +0800
> From: Wang Yufen <wangyufen@huawei.com>
>
>
> Signed-off-by: Wang Yufen <wangyufen@huawei.com>
Applied.
^ permalink raw reply
* [PATCH -next] net: tcp: add mib counters to track zero window transitions
From: Florian Westphal @ 2014-02-17 21:57 UTC (permalink / raw)
To: netdev; +Cc: eric.dumazet, Florian Westphal
Three counters are added:
- one to track when we went from non-zero to zero window
- one to track the reverse
- one counter incremented when we want to announce zero window.
The latter is added because it can show cases where we want to close the
window but can't because we would shrink window.
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
Eric, is this what you had in mind?
I re-ran my 'slow-sender-with-reader-that-does-not-drain-socket'
scenario and, as expected, only TCPWANTZEROWINDOW increases.
Thanks,
Florian
include/uapi/linux/snmp.h | 3 +++
net/ipv4/proc.c | 3 +++
net/ipv4/tcp_output.c | 13 ++++++++++++-
3 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/snmp.h b/include/uapi/linux/snmp.h
index bbaba22..6404eed 100644
--- a/include/uapi/linux/snmp.h
+++ b/include/uapi/linux/snmp.h
@@ -259,6 +259,9 @@ enum
LINUX_MIB_TCPSPURIOUS_RTX_HOSTQUEUES, /* TCPSpuriousRtxHostQueues */
LINUX_MIB_BUSYPOLLRXPACKETS, /* BusyPollRxPackets */
LINUX_MIB_TCPAUTOCORKING, /* TCPAutoCorking */
+ LINUX_MIB_TCPFROMZEROWINDOWADV, /* TCPFromZeroWindowAdv */
+ LINUX_MIB_TCPTOZEROWINDOWADV, /* TCPToZeroWindowAdv */
+ LINUX_MIB_TCPWANTZEROWINDOW, /* TCPWantZeroWindow */
__LINUX_MIB_MAX
};
diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index a6c8a80..542d414 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -280,6 +280,9 @@ static const struct snmp_mib snmp4_net_list[] = {
SNMP_MIB_ITEM("TCPSpuriousRtxHostQueues", LINUX_MIB_TCPSPURIOUS_RTX_HOSTQUEUES),
SNMP_MIB_ITEM("BusyPollRxPackets", LINUX_MIB_BUSYPOLLRXPACKETS),
SNMP_MIB_ITEM("TCPAutoCorking", LINUX_MIB_TCPAUTOCORKING),
+ SNMP_MIB_ITEM("TCPFromZeroWindowAdv", LINUX_MIB_TCPFROMZEROWINDOWADV),
+ SNMP_MIB_ITEM("TCPToZeroWindowAdv", LINUX_MIB_TCPTOZEROWINDOWADV),
+ SNMP_MIB_ITEM("TCPWantZeroWindow", LINUX_MIB_TCPWANTZEROWINDOW),
SNMP_MIB_SENTINEL
};
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 48414fc..e8d6f14 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -269,6 +269,7 @@ EXPORT_SYMBOL(tcp_select_initial_window);
static u16 tcp_select_window(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
+ u32 old_win = tp->rcv_wnd;
u32 cur_win = tcp_receive_window(tp);
u32 new_win = __tcp_select_window(sk);
@@ -281,6 +282,9 @@ static u16 tcp_select_window(struct sock *sk)
*
* Relax Will Robinson.
*/
+ if (new_win == 0)
+ NET_INC_STATS_BH(sock_net(sk),
+ LINUX_MIB_TCPWANTZEROWINDOW);
new_win = ALIGN(cur_win, 1 << tp->rx_opt.rcv_wscale);
}
tp->rcv_wnd = new_win;
@@ -298,8 +302,15 @@ static u16 tcp_select_window(struct sock *sk)
new_win >>= tp->rx_opt.rcv_wscale;
/* If we advertise zero window, disable fast path. */
- if (new_win == 0)
+ if (new_win == 0) {
tp->pred_flags = 0;
+ if (old_win)
+ NET_INC_STATS_BH(sock_net(sk),
+ LINUX_MIB_TCPTOZEROWINDOWADV);
+ } else if (old_win == 0) {
+ NET_INC_STATS_BH(sock_net(sk),
+ LINUX_MIB_TCPFROMZEROWINDOWADV);
+ }
return new_win;
}
--
1.8.1.5
^ permalink raw reply related
* Re: [PATCH 1/1] net: i40evf: Remove duplicate include
From: David Miller @ 2014-02-17 22:02 UTC (permalink / raw)
To: sachin.kamat; +Cc: netdev, e1000-devel, jeffrey.t.kirsher
In-Reply-To: <1392631161-17135-1-git-send-email-sachin.kamat@linaro.org>
From: Sachin Kamat <sachin.kamat@linaro.org>
Date: Mon, 17 Feb 2014 15:29:21 +0530
> linux/sctp.h was included twice.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Applied to net-next, thank you.
^ permalink raw reply
* Re: [PATCH] net: add init-regs for of_phy support
From: Sergei Shtylyov @ 2014-02-17 22:08 UTC (permalink / raw)
To: Florian Fainelli
Cc: Ben Dooks, netdev, devicetree@vger.kernel.org, Linux-sh list,
David Miller, Mark Rutland
In-Reply-To: <CAGVrzcbZC3t0oexc5Aj-KyGj-qC8J9eYp8+rb8V-AqKtrSjyYw@mail.gmail.com>
On 02/17/2014 11:48 PM, Florian Fainelli wrote:
>>>> Add new init-regs field for of_phy nodes and make sure these
>>>> get applied when the phy is configured.
>>>> This allows any phy node in an fdt to initialise registers
>>>> that may not be set as standard by the driver at initialisation
>>>> time, such as LED controls.
>>>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
[...]
>>>> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
>>>> index 82514e7..6741cdb 100644
>>>> --- a/drivers/net/phy/phy_device.c
>>>> +++ b/drivers/net/phy/phy_device.c
>> [...]
>>>> @@ -532,6 +533,57 @@ static int phy_poll_reset(struct phy_device *phydev)
>>>> return 0;
>>>> }
>>>>
>>>> +#ifdef CONFIG_OF
>>>> +static int of_phy_configure(struct phy_device *phydev)
>>>> +{
>>>> + struct device *dev = &phydev->dev;
>>>> + struct device_node *of_node = dev->of_node;
>>>> + struct property *prop;
>>>> + const __be32 *ptr;
>>>> + u32 reg, set, clear;
>>>> + int len;
>>>> + int val;
>>> This does not belong in the generic PHY code unless we are very clear
>>> on what we want to do, and how to do it, which I do not think we are
>>> yet. What exactly is needed here:
>>> - fixing up some design mistake?
>>> - accounting for a specific board design?
>> Kind of both. This was invented to defy the necessity of having platform
>> fixup in the DT case (where there should be no board file to place it into).
>> I have already described that platform fixup necessary on the Renesas
>> Lager/Koelsch boards where the LED0 signat is connected to ETH_LINK signal
>> on the SoC and the PHY reset sets the LED control bits to default 0 which
>> means that LED0 will be LINK/ACTIVITY signal and thus blink on activity and
>> cause ETH_LINK to bounce off/on after each packet.
>>> In any case a PHY fixup would do the job for you.
>> Not in any case. In case of DT we have no place for it, so should invent
>> something involving DT.
> How is DT different than any machine probing mechanism here?
There supposed to be no board files. The purpose of DT is to get rid of
the board files, at least on ARM.
> The way to involve DT is to do the following:
> if (of_machine_is_compatible("renesas,foo-board-with-broken-micrel-phy"))
> phy_register_fixup(&foo_board_with_broken_micrel_phy);
Where are you suggesting to place such code? arch/arm/mach-shmobile/setup-*.c?
> If your machine compatible string does not allow you to uniquely
> identify your machine, this is a DT problem, as this should really be
> the case. If you do not want to add this code to wherever this is
> relevant in arch/arm/mach-shmobile/board-*.c,
There just should be no such file for DT case.
> neither is drivers/net/phy/phy_device.c this the place to add it.
Hey, I wasn't arguing with that! :-)
> Dealing with quirks applying to industry standard blocks is to update
> the relevant driver, based on information provided by the specifically
> affected systems. Failure to identify either of those correctly is a
> problem that must not lead to a generic "let's override PHY registers
> from DT" type of solution.
> As usual, mechanism vs policy applies even more when DT is involved.
Ah, so you're suggesting placing the fixup code in the driver itself?
That's a bit strange for the platform specific code, but would do I guess...
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next v5 09/10] Documentation: add Device tree bindings for Broadcom GENET
From: Sergei Shtylyov @ 2014-02-17 23:10 UTC (permalink / raw)
To: Florian Fainelli, netdev
Cc: davem, devicetree, cernekee, mark.rutland, romieu
In-Reply-To: <1392336531-28875-10-git-send-email-f.fainelli@gmail.com>
Hello.
On 02/14/2014 03:08 AM, Florian Fainelli wrote:
> This patch adds the Device Tree bindings for the Broadcom GENET Gigabit
> Ethernet controller. A bunch of examples are provided to illustrate the
> versatile aspect of the hardare.
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
[...]
Too bad I didn't read this patch before and now it has been already applied.
[...]
> diff --git a/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt b/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt
> new file mode 100644
> index 0000000..afd31f9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt
> @@ -0,0 +1,121 @@
> +* Broadcom BCM7xxx Ethernet Controller (GENET)
> +
> +Required properties:
> +- compatible: should contain one of "brcm,genet-v1", "brcm,genet-v2",
> + "brcm,genet-v3", "brcm,genet-v4".
> +- reg: address and length of the register set for the device
> +- interrupts: must be two cells, the first cell is the general purpose
> + interrupt line, while the second cell is the interrupt for the ring
> + RX and TX queues operating in ring mode
> +- phy-mode: String, operation mode of the PHY interface. Supported values are
> + "mii", "rgmii", "rgmii-txid", "rev-mii", "moca". Analogous to ePAPR
> + "phy-connection-type" values
> +- address-cells: should be 1
> +- size-cells: should be 1
The above two prop names should have # in front of them. Examples seem to
be correct. Some words about the downstream bus wouldn't hurt too.
[...]
> +Required child nodes:
> +
> +- mdio bus node: this node should always be present regarless of the PHY
> + configuration of the GENET instance
> +
> +MDIO bus node required properties:
> +
> +- compatible: should contain one of "brcm,genet-mdio-v1", "brcm,genet-mdio-v2"
> + "brcm,genet-mdio-v3", "brcm,genet-mdio-v4", the version has to match the
> + parent node compatible property (e.g: brcm,genet-v4 pairs with
> + brcm,genet-mdio-v4)
> +- reg: address and length relative to the parent node base register address
> +- address-cells: address cell for MDIO bus addressing, should be 1
> +- size-cells: size of the cells for MDIO bus addressing, should be 0
The above two props should have # in front of them as well. Examples seem
to be correct.
WBR, Sergei
^ 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