[PATCH v7 2/3] Bluetooth: btusb: Add out-of-band wakeup support

[Rajat Jain]

Some onboard BT chips (e.g. Marvell 8997) contain a wakeup pin that
can be connected to a gpio on the CPU side, and can be used to wakeup
the host out-of-band. This can be useful in situations where the
in-band wakeup is not possible or not preferable (e.g. the in-band
wakeup may require the USB host controller to remain active, and
hence consuming more system power during system sleep).

The oob gpio interrupt to be used for wakeup on the CPU side, is
read from the device tree node, (using standard interrupt descriptors).
A devcie tree binding document is also added for the driver. The
compatible string is in compliance with
Documentation/devicetree/bindings/usb/usb-device.txt

Signed-off-by: Rajat Jain 
Reviewed-by: Brian Norris 
Acked-by: Rob Herring 
---
v7: Change the BTUSB_OOB_WAKE_DISABLED flag to BTUSB_OOB_WAKE_ENABLED
v6: Remove the newlines in error statements ("\n")
v5: Move the call to pm_wakeup_event() to the begining of irq handler.
v4: Move the set_bit(BTUSB_OOB_WAKE_DISABLED,..) call to the beginning of
btusb_config_oob_wake()
v3: Add Brian's "Reviewed-by"
v2: * Use interrupt-names ("wakeup") instead of assuming first interrupt.
* Leave it on device tree to specify IRQ flags (level /edge triggered)
* Mark the device as non wakeable on exit.

 Documentation/devicetree/bindings/net/btusb.txt | 40 
 drivers/bluetooth/btusb.c   | 85 +
 2 files changed, 125 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/btusb.txt

diff --git a/Documentation/devicetree/bindings/net/btusb.txt 
b/Documentation/devicetree/bindings/net/btusb.txt
new file mode 100644
index ..2c0355c85972
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/btusb.txt
@@ -0,0 +1,40 @@
+Generic Bluetooth controller over USB (btusb driver)
+---
+
+Required properties:
+
+  - compatible : should comply with the format "usbVID,PID" specified in
+Documentation/devicetree/bindings/usb/usb-device.txt
+At the time of writing, the only OF supported devices
+(more may be added later) are:
+
+ "usb1286,204e" (Marvell 8997)
+
+Optional properties:
+
+  - interrupt-parent: phandle of the parent interrupt controller
+  - interrupt-names: (see below)
+  - interrupts : The interrupt specified by the name "wakeup" is the interrupt
+that shall be used for out-of-band wake-on-bt. Driver will
+request this interrupt for wakeup. During system suspend, the
+irq will be enabled so that the bluetooth chip can wakeup host
+platform out of band. During system resume, the irq will be
+disabled to make sure unnecessary interrupt is not received.
+
+Example:
+
+Following example uses irq pin number 3 of gpio0 for out of band wake-on-bt:
+
+_host1_ehci {
+status = "okay";
+#address-cells = <1>;
+#size-cells = <0>;
+
+mvl_bt1: bt@1 {
+   compatible = "usb1286,204e";
+   reg = <1>;
+   interrupt-parent = <>;
+   interrupt-name = "wakeup";
+   interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+};
+};
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index ce22cefceed1..fa2231a36b98 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -24,6 +24,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 #include 
@@ -369,6 +371,7 @@ static const struct usb_device_id blacklist_table[] = {
 #define BTUSB_BOOTING  9
 #define BTUSB_RESET_RESUME 10
 #define BTUSB_DIAG_RUNNING 11
+#define BTUSB_OOB_WAKE_ENABLED 12
 
 struct btusb_data {
struct hci_dev   *hdev;
@@ -416,6 +419,8 @@ struct btusb_data {
int (*recv_bulk)(struct btusb_data *data, void *buffer, int count);
 
int (*setup_on_usb)(struct hci_dev *hdev);
+
+   int oob_wake_irq;   /* irq for out-of-band wake-on-bt */
 };
 
 static inline void btusb_free_frags(struct btusb_data *data)
@@ -2728,6 +2733,66 @@ static int btusb_bcm_set_diag(struct hci_dev *hdev, bool 
enable)
 }
 #endif
 
+#ifdef CONFIG_PM
+static irqreturn_t btusb_oob_wake_handler(int irq, void *priv)
+{
+   struct btusb_data *data = priv;
+
+   pm_wakeup_event(>udev->dev, 0);
+
+   /* Disable only if not already disabled (keep it balanced) */
+   if (test_and_clear_bit(BTUSB_OOB_WAKE_ENABLED, >flags)) {
+   disable_irq_nosync(irq);
+   disable_irq_wake(irq);
+   }
+   return IRQ_HANDLED;
+}
+
+static const struct of_device_id btusb_match_table[] = {
+   { .compatible = "usb1286,204e" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, btusb_match_table);
+
+/* Use an oob wakeup pin? */
+static int btusb_config_oob_wake(struct hci_dev *hdev)
+{
+   struct btusb_data *data = hci_get_drvdata(hdev);
+   struct device *dev = 

[PATCH v7 3/3] Bluetooth: btusb: Configure Marvell to use one of the pins for oob wakeup

[Rajat Jain]

The Marvell devices may have many gpio pins, and hence for wakeup
on these out-of-band pins, the chip needs to be told which pin is
to be used for wakeup, using an hci command.

Thus, we read the pin number etc from the device tree node and send
a command to the chip.

Signed-off-by: Rajat Jain 
Reviewed-by: Brian Norris 
Acked-by: Rob Herring 
---
v7: Same as v6
v6: same as v5
v5: same as v5
v4: same as v3
v3: * remove the Marvell specific id table and check
* Add reference to marvell-bt-8xxx.txt in btusb.txt
* Add "Reviewed-by" and "Acked-by"
v2: Fix the binding document to specify to use "wakeup" interrupt-name

 Documentation/devicetree/bindings/net/btusb.txt|  3 ++
 .../{marvell-bt-sd8xxx.txt => marvell-bt-8xxx.txt} | 46 +++
 drivers/bluetooth/btusb.c  | 51 ++
 3 files changed, 92 insertions(+), 8 deletions(-)
 rename Documentation/devicetree/bindings/net/{marvell-bt-sd8xxx.txt => 
marvell-bt-8xxx.txt} (50%)

diff --git a/Documentation/devicetree/bindings/net/btusb.txt 
b/Documentation/devicetree/bindings/net/btusb.txt
index 2c0355c85972..01fa2d4188d4 100644
--- a/Documentation/devicetree/bindings/net/btusb.txt
+++ b/Documentation/devicetree/bindings/net/btusb.txt
@@ -10,6 +10,9 @@ Required properties:
 
  "usb1286,204e" (Marvell 8997)
 
+Also, vendors that use btusb may have device additional properties, e.g:
+Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
+
 Optional properties:
 
   - interrupt-parent: phandle of the parent interrupt controller
diff --git a/Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt 
b/Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
similarity index 50%
rename from Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt
rename to Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
index 6a9a63cb0543..9be1059ff03f 100644
--- a/Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt
+++ b/Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
@@ -1,16 +1,21 @@
-Marvell 8897/8997 (sd8897/sd8997) bluetooth SDIO devices
+Marvell 8897/8997 (sd8897/sd8997) bluetooth devices (SDIO or USB based)
 --
+The 8997 devices supports multiple interfaces. When used on SDIO interfaces,
+the btmrvl driver is used and when used on USB interface, the btusb driver is
+used.
 
 Required properties:
 
   - compatible : should be one of the following:
-   * "marvell,sd8897-bt"
-   * "marvell,sd8997-bt"
+   * "marvell,sd8897-bt" (for SDIO)
+   * "marvell,sd8997-bt" (for SDIO)
+   * "usb1286,204e"  (for USB)
 
 Optional properties:
 
   - marvell,cal-data: Calibration data downloaded to the device during
  initialization. This is an array of 28 values(u8).
+ This is only applicable to SDIO devices.
 
   - marvell,wakeup-pin: It represents wakeup pin number of the bluetooth chip.
firmware will use the pin to wakeup host system (u16).
@@ -18,10 +23,15 @@ Optional properties:
  platform. The value will be configured to firmware. This
  is needed to work chip's sleep feature as expected (u16).
   - interrupt-parent: phandle of the parent interrupt controller
-  - interrupts : interrupt pin number to the cpu. Driver will request an irq 
based
-on this interrupt number. During system suspend, the irq will 
be
-enabled so that the bluetooth chip can wakeup host platform 
under
-certain condition. During system resume, the irq will be 
disabled
+  - interrupt-names: Used only for USB based devices (See below)
+  - interrupts : specifies the interrupt pin number to the cpu. For SDIO, the
+driver will use the first interrupt specified in the interrupt
+array. For USB based devices, the driver will use the interrupt
+named "wakeup" from the interrupt-names and interrupt arrays.
+The driver will request an irq based on this interrupt number.
+During system suspend, the irq will be enabled so that the
+bluetooth chip can wakeup host platform under certain
+conditions. During system resume, the irq will be disabled
 to make sure unnecessary interrupt is not received.
 
 Example:
@@ -29,7 +39,9 @@ Example:
 IRQ pin 119 is used as system wakeup source interrupt.
 wakeup pin 13 and gap 100ms are configured so that firmware can wakeup host
 using this device side pin and wakeup latency.
-calibration data is also available in below example.
+
+Example for SDIO device follows (calibration data is also available in
+below example).
 
  {
status = "okay";
@@ -54,3 +66,21 @@ calibration data is also available in below example.
marvell,wakeup-gap-ms = /bits/ 16 <0x64>;
};
 };
+
+Example for 

Re: net: suspicious RCU usage in nf_hook

[Cong Wang]

On Wed, Feb 1, 2017 at 1:16 PM, Eric Dumazet  wrote:
> On Wed, 2017-02-01 at 12:51 -0800, Cong Wang wrote:
>> On Tue, Jan 31, 2017 at 7:44 AM, Eric Dumazet  wrote:
>> > On Mon, 2017-01-30 at 22:19 -0800, Cong Wang wrote:
>> >
>> >>
>> >> The context is process context (TX path before hitting qdisc), and
>> >> BH is not disabled, so in_interrupt() doesn't catch it. Hmm, this
>> >> makes me thinking maybe we really need to disable BH in this
>> >> case for nf_hook()? But it is called in RX path too, and BH is
>> >> already disabled there.
>> >
>> > ipt_do_table() and similar netfilter entry points disable BH.
>> >
>> > Maybe it is done too late.
>>
>> I think we need a fix like the following one for minimum impact.
>>
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 727b6fd..eee7d63 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -1720,12 +1720,10 @@ EXPORT_SYMBOL(net_enable_timestamp);
>>  void net_disable_timestamp(void)
>>  {
>>  #ifdef HAVE_JUMP_LABEL
>> -   if (in_interrupt()) {
>> -   atomic_inc(_needed_deferred);
>> -   return;
>> -   }
>> -#endif
>> +   atomic_inc(_needed_deferred);
>> +#else
>> static_key_slow_dec(_needed);
>> +#endif
>>  }
>>  EXPORT_SYMBOL(net_disable_timestamp);
>
> This would permanently leave the kernel in the netstamp_needed state.
>
> I would prefer the patch using a process context to perform the
> cleanup ? Note there is a race window, but probably not a big deal.

Not sure if it is better. The difference is caught up in net_enable_timestamp(),
which is called setsockopt() path and sk_clone() path, so we could be
in netstamp_needed state for a long time too until user-space exercises
these paths.

I am feeling we probably need to get rid of netstamp_needed_deferred,
and simply defer the whole static_key_slow_dec(), like the attached patch
(compile only).

What do you think?
diff --git a/net/core/dev.c b/net/core/dev.c
index 727b6fd..0ef1734 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1694,38 +1694,28 @@ EXPORT_SYMBOL_GPL(net_dec_egress_queue);
 #endif
 
 static struct static_key netstamp_needed __read_mostly;
-#ifdef HAVE_JUMP_LABEL
-/* We are not allowed to call static_key_slow_dec() from irq context
- * If net_disable_timestamp() is called from irq context, defer the
- * static_key_slow_dec() calls.
- */
-static atomic_t netstamp_needed_deferred;
-#endif
 
-void net_enable_timestamp(void)
+static void netstamp_clear(struct work_struct *work)
 {
-#ifdef HAVE_JUMP_LABEL
-   int deferred = atomic_xchg(_needed_deferred, 0);
+   static_key_slow_dec(_needed);
+}
 
-   if (deferred) {
-   while (--deferred)
-   static_key_slow_dec(_needed);
-   return;
-   }
-#endif
+static DECLARE_WORK(netstamp_work, netstamp_clear);
+
+void net_enable_timestamp(void)
+{
+   flush_work(_work);
static_key_slow_inc(_needed);
 }
 EXPORT_SYMBOL(net_enable_timestamp);
 
 void net_disable_timestamp(void)
 {
-#ifdef HAVE_JUMP_LABEL
-   if (in_interrupt()) {
-   atomic_inc(_needed_deferred);
-   return;
-   }
-#endif
-   static_key_slow_dec(_needed);
+   /* We are not allowed to call static_key_slow_dec() from irq context
+* If net_disable_timestamp() is called from irq context, defer the
+* static_key_slow_dec() calls.
+*/
+   schedule_work(_work);
 }
 EXPORT_SYMBOL(net_disable_timestamp);
 

Re: [PATCH] xen-netfront: Delete rx_refill_timer in xennet_disconnect_backend()

[Boris Ostrovsky]

On 01/31/2017 12:47 PM, Boris Ostrovsky wrote:
> On 01/30/2017 02:31 PM, Boris Ostrovsky wrote:
>> On 01/30/2017 02:06 PM, Eric Dumazet wrote:
>>> On Mon, 2017-01-30 at 13:23 -0500, Boris Ostrovsky wrote:
>>>
 We do netif_carrier_off() first thing in xennet_disconnect_backend() and
 the only place where the timer is rearmed is xennet_alloc_rx_buffers(),
 which is guarded by netif_carrier_ok() check.
>>> Oh well, testing netif_carrier_ok() in packet processing fast path looks
>>> unusual and a waste of cpu cycles. I've never seen that pattern before.
>>>
>>> If one day, we remove this netif_carrier_ok() test during a cleanup,
>>> then the race window will open again.
>> I don't know much about napi but I wonder whether I can indeed disable
>> it in xennet_disconnect_backend(). I don't see how anything can happen
>> after disconnect since it unmaps the rings. And then napi is re-enabled
>> during reconnection in xennet_create_queues(). In which case am not sure
>> there is any need for xennet_destroy_queues() as everything there could
>> be folded into xennet_disconnect_backend().
> While this does work, there was a reason why napi_disable() was not
> called in xennet_disconnect_backend() and it is explained in commit
> ce58725fec6e --- napi_disable() may sleep and that's why it is called in
> xennet_destroy_queues().
>
> OTOH, there is a napi_synchronize() call in xennet_destroy_queues().
> Will destroying the timer after it guarantee that all preceding RX have
> been completed? RX interrupt is disabled prior to napi_synchronize() so
> presumably nothing new can be received.


I could not convince myself that napi_synchronize() is sufficient here
(mostly because I am not familiar with napi flow). At the same time I
would rather not make changes in anticipation of possible disappearance
of netif_carrier_ok() in the future so I'd like this patch to go in as is.

Unless there are other problems with the patch or if Eric (or others)
feel strongly about usage of netif_carrier_ok() here.


-boris

[PATCH net-next] net: phy: marvell: Add support for 88e1545 PHY

[Andrew Lunn]

The 88e1545 PHYs are discrete Marvell PHYs, found in a quad package on
the zii-devel-b board. Add support for it to the Marvell PHY driver.

Signed-off-by: Andrew Lunn 
---

NOTE: To apply cleanly, the "Work around missing PHY product ID in mv88e6390"
patches need to be applied first.

drivers/net/phy/marvell.c   | 21 +
 include/linux/marvell_phy.h |  1 +
 2 files changed, 22 insertions(+)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 1a0ac48cbc50..f9d0fa315a47 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -2123,6 +2123,26 @@ static struct phy_driver marvell_drivers[] = {
.get_stats = marvell_get_stats,
},
{
+   .phy_id = MARVELL_PHY_ID_88E1545,
+   .phy_id_mask = MARVELL_PHY_ID_MASK,
+   .name = "Marvell 88E1545",
+   .probe = m88e1510_probe,
+   .remove = _remove,
+   .features = PHY_GBIT_FEATURES,
+   .flags = PHY_HAS_INTERRUPT,
+   .config_init = _config_init,
+   .config_aneg = _config_aneg,
+   .read_status = _read_status,
+   .ack_interrupt = _ack_interrupt,
+   .config_intr = _config_intr,
+   .did_interrupt = _did_interrupt,
+   .resume = _resume,
+   .suspend = _suspend,
+   .get_sset_count = marvell_get_sset_count,
+   .get_strings = marvell_get_strings,
+   .get_stats = marvell_get_stats,
+   },
+   {
.phy_id = MARVELL_PHY_ID_88E3016,
.phy_id_mask = MARVELL_PHY_ID_MASK,
.name = "Marvell 88E3016",
@@ -2178,6 +2198,7 @@ static struct mdio_device_id __maybe_unused marvell_tbl[] 
= {
{ MARVELL_PHY_ID_88E1116R, MARVELL_PHY_ID_MASK },
{ MARVELL_PHY_ID_88E1510, MARVELL_PHY_ID_MASK },
{ MARVELL_PHY_ID_88E1540, MARVELL_PHY_ID_MASK },
+   { MARVELL_PHY_ID_88E1545, MARVELL_PHY_ID_MASK },
{ MARVELL_PHY_ID_88E3016, MARVELL_PHY_ID_MASK },
{ MARVELL_PHY_ID_88E6390, MARVELL_PHY_ID_MASK },
{ }
diff --git a/include/linux/marvell_phy.h b/include/linux/marvell_phy.h
index 3d616d7f65bf..4055cf8cc978 100644
--- a/include/linux/marvell_phy.h
+++ b/include/linux/marvell_phy.h
@@ -17,6 +17,7 @@
 #define MARVELL_PHY_ID_88E1116R0x01410e40
 #define MARVELL_PHY_ID_88E1510 0x01410dd0
 #define MARVELL_PHY_ID_88E1540 0x01410eb0
+#define MARVELL_PHY_ID_88E1545 0x01410ea0
 #define MARVELL_PHY_ID_88E3016 0x01410e60
 
 /* The MV88e6390 Ethernet switch contains embedded PHYs. These PHYs do
-- 
2.11.0

[PATCHv2 net-next 0/2] MV88E6390 fixes

[Andrew Lunn]

Two patches, which have been posted before. Fix simple issues in the
mv88e6390 support. These don't need to go to stable, since the
mv88e6390 support in stable is insufficient to be usable.

To apply cleanly, these patches rely on "net: dsa: mv88e6xxx:
Workaround missing PHY".

v2: Added Reviewed-by.
Removed a redundant "the"

Andrew Lunn (2):
  net: dsa: mv88e6xxx: Fix ATU age timer for MV88E6390
  net: dsa: mv88e6xxx: Fix typ0 when configuring 2.5Gbps

 drivers/net/dsa/mv88e6xxx/chip.c | 12 ++--
 drivers/net/dsa/mv88e6xxx/port.c |  2 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

-- 
2.11.0

Re: [net-next 1/8] net/mlx5: Fixed static checker warnings

[Or Gerlitz]

On Wed, Feb 1, 2017 at 7:22 PM, David Miller  wrote:

[..]

> You're propagating values into a u32 field, which you are explicitly
> performing 32-bit endianness conversions upon.

> Just use "u32" for a local variable and get rid of all of these casts.

ok, will do that

[PATCH iproute2] ss: print tcpi_rcv_mss

[Eric Dumazet]

From: Eric Dumazet 

tcpi_rcv_mss tcp info field was not yet reported by ss.

While adding GRO support to packetdrill, I found this was useful.

Signed-off-by: Eric Dumazet 
---
 misc/ss.c |4 
 1 file changed, 4 insertions(+)

diff --git a/misc/ss.c b/misc/ss.c
index 4454bd1..6e4f84a 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -707,6 +707,7 @@ struct tcpstat {
int snd_wscale;
int rcv_wscale;
int mss;
+   int rcv_mss;
unsigned intcwnd;
unsigned intlastsnd;
unsigned intlastrcv;
@@ -1872,6 +1873,8 @@ static void tcp_stats_print(struct tcpstat *s)
 
if (s->mss)
printf(" mss:%d", s->mss);
+   if (s->rcv_mss)
+   printf(" rcvmss:%d", s->rcv_mss);
if (s->cwnd)
printf(" cwnd:%u", s->cwnd);
if (s->ssthresh)
@@ -2189,6 +2192,7 @@ static void tcp_show_info(const struct nlmsghdr *nlh, 
struct inet_diag_msg *r,
s.rttvar = (double)info->tcpi_rttvar / 1000;
s.ato= (double)info->tcpi_ato / 1000;
s.mss= info->tcpi_snd_mss;
+   s.rcv_mss= info->tcpi_rcv_mss;
s.rcv_space  = info->tcpi_rcv_space;
s.rcv_rtt= (double)info->tcpi_rcv_rtt / 1000;
s.lastsnd= info->tcpi_last_data_sent;

Re: [PATCH] net: phy: dp83867: Port mirroring support in the DP83867 TI's PHY driver

[Lukasz Majewski]

Hi Andrew,

> > We would need a tri-state device tree properly:
> > 
> > 1. Not defined - do nothing
> > 2. Defined as 0 -> explicitly disable port mirroring
> > 3. Defined as 1 -> explicitly enable port mirriring
> > 
> > The "net-phy-lane-swap" only fulfills points 1 and 3 above.
> > 
> > In my use case I do need point 2.
> 
> Looking at the datasheet, PORT_MIRROR_EN defaults to 0. So it seems
> reasonable to unconditionally set it to 0 when the PHY driver
> loads. Any device which needs a value of 1 can set "net-phy-lane-swap"

Unconditionally setting this field to 0 (as we expect the reset default
setting) seems to me like a good solution. 

However, I was not sure if such approach is acceptable by the community.

> 
>Andrew




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de

Re: [PATCHv3 net-next 5/7] net: add confirm_neigh method to dst_ops

[Julian Anastasov]

Hello,

On Wed, 1 Feb 2017, Steffen Klassert wrote:

> On Tue, Jan 31, 2017 at 11:57:05PM +0200, Julian Anastasov wrote:
> >  
> > +static void xfrm_confirm_neigh(const struct dst_entry *dst, const void 
> > *daddr)
> > +{
> > +   const struct dst_entry *path = dst->path;
> > +
> > +   if (path == dst) {
> 
> I think path can not be equal to dst here, otherwise we would
> have an infinite recursion.

Yep, I know that, this place remained unfinished.

> > +   dst->ops->confirm_neigh(dst, daddr);
> > +   } else {
> > +   /* daddr can be from different family and we need the
> > +* tunnel address. How to get it?
> > +*/
> 
> This is only called on a xfrm_dst, so you should have dst->xfrm set.
> You can get the daddr of this transform with:
> 
> xfrm_address_t *daddr = >id.daddr;

I hope so but see below...

> > +   path->ops->confirm_neigh(path, NULL);
> 
> I think here it is better to go through the whole chain
> of transformations with
> 
> child->ops->confirm_neigh(path, daddr);

It may sounds good. But only dst->path->ops->confirm_neigh
points to real IPv4/IPv6 function. And also, I guess, the
family can change while walking the chain, so we should be
careful while providing the original daddr (which comes from
sendmsg). I had the idea to walk all xforms to get the latest
tunnel address but this can be slow. Something like this?:

static void xfrm_confirm_neigh(const struct dst_entry *dst, const void 
*daddr)
{
const struct dst_entry *path = dst->path;

/* By default, daddr is from sendmsg() if we have no tunnels */
for (;dst != path; dst = dst->child) {
const struct xfrm_state *xfrm = dst->xfrm;

/* Use address from last tunnel */
if (xfrm->props.mode != XFRM_MODE_TRANSPORT)
daddr = >id.daddr;
}
path->ops->confirm_neigh(path, daddr);
}

This should work as long as path and last tunnel are
from same family. Also, after checking xfrm_dst_lookup() I'm not
sure using just >id.daddr is enough. Should we consider
more places for daddr value?

> >  int xfrm_policy_register_afinfo(struct xfrm_policy_afinfo *afinfo)
> >  {
> > int err = 0;
> > @@ -2882,6 +2896,8 @@ int xfrm_policy_register_afinfo(struct 
> > xfrm_policy_afinfo *afinfo)
> > dst_ops->link_failure = xfrm_link_failure;
> > if (likely(dst_ops->neigh_lookup == NULL))
> > dst_ops->neigh_lookup = xfrm_neigh_lookup;
> > +   if (likely(!dst_ops->confirm_neigh))
> > +   dst_ops->confirm_neigh = xfrm_confirm_neigh;
> 
> We also have address family depended dst_ops, look for
> xfrm4_dst_ops_template/xfrm6_dst_ops_template.

For now I installed common handler, just like
xfrm_neigh_lookup. BTW this function has problem from
commit f894cbf847c9, it looks like dst is wrongly provided,
first arg should be dst->path.

But as dst_ops contains the family, I think, we can know
what kind of daddr is provided initially (dst->ops->family).
So far, the above logic does not need to compare the families.
But as I don't know the code well, I'm not sure, my assumptions are:

- transports do not change the family
- tunnels may change the family
- last tunnel gets dst0->path route from its family

Regards

--
Julian Anastasov 

Re: [PATCH] net: phy: dp83867: Port mirroring support in the DP83867 TI's PHY driver

[Andrew Lunn]

> We would need a tri-state device tree properly:
> 
> 1. Not defined - do nothing
> 2. Defined as 0 -> explicitly disable port mirroring
> 3. Defined as 1 -> explicitly enable port mirriring
> 
> The "net-phy-lane-swap" only fulfills points 1 and 3 above.
> 
> In my use case I do need point 2.

Looking at the datasheet, PORT_MIRROR_EN defaults to 0. So it seems
reasonable to unconditionally set it to 0 when the PHY driver
loads. Any device which needs a value of 1 can set "net-phy-lane-swap"

   Andrew

[PATCH] wcn36xx: Implement cancel_hw_scan

[Bjorn Andersson]

In the even that the wcn36xx interface is brought down while a hw_scan
is active we must abort and wait for the ongoing scan to signal
completion to mac80211.

Reported-by: Mart Raudsepp 
Fixes: 886039036c20 ("wcn36xx: Implement firmware assisted scan")
Signed-off-by: Bjorn Andersson 
---
 drivers/net/wireless/ath/wcn36xx/main.c| 25 -
 drivers/net/wireless/ath/wcn36xx/wcn36xx.h |  1 +
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/wcn36xx/main.c 
b/drivers/net/wireless/ath/wcn36xx/main.c
index a24edf33be93..bb7110f7fc86 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -574,6 +574,7 @@ static void wcn36xx_hw_scan_worker(struct work_struct *work)
struct cfg80211_scan_request *req = wcn->scan_req;
u8 channels[WCN36XX_HAL_PNO_MAX_NETW_CHANNELS_EX];
struct cfg80211_scan_info scan_info = {};
+   bool aborted = false;
int i;
 
wcn36xx_dbg(WCN36XX_DBG_MAC, "mac80211 scan %d channels worker\n", 
req->n_channels);
@@ -585,6 +586,13 @@ static void wcn36xx_hw_scan_worker(struct work_struct 
*work)
 
wcn36xx_smd_init_scan(wcn, HAL_SYS_MODE_SCAN);
for (i = 0; i < req->n_channels; i++) {
+   mutex_lock(>scan_lock);
+   aborted = wcn->scan_aborted;
+   mutex_unlock(>scan_lock);
+
+   if (aborted)
+   break;
+
wcn->scan_freq = req->channels[i]->center_freq;
wcn->scan_band = req->channels[i]->band;
 
@@ -596,7 +604,7 @@ static void wcn36xx_hw_scan_worker(struct work_struct *work)
}
wcn36xx_smd_finish_scan(wcn, HAL_SYS_MODE_SCAN);
 
-   scan_info.aborted = false;
+   scan_info.aborted = aborted;
ieee80211_scan_completed(wcn->hw, _info);
 
mutex_lock(>scan_lock);
@@ -615,6 +623,8 @@ static int wcn36xx_hw_scan(struct ieee80211_hw *hw,
mutex_unlock(>scan_lock);
return -EBUSY;
}
+
+   wcn->scan_aborted = false;
wcn->scan_req = _req->req;
mutex_unlock(>scan_lock);
 
@@ -623,6 +633,18 @@ static int wcn36xx_hw_scan(struct ieee80211_hw *hw,
return 0;
 }
 
+static void wcn36xx_cancel_hw_scan(struct ieee80211_hw *hw,
+  struct ieee80211_vif *vif)
+{
+   struct wcn36xx *wcn = hw->priv;
+
+   mutex_lock(>scan_lock);
+   wcn->scan_aborted = true;
+   mutex_unlock(>scan_lock);
+
+   cancel_work_sync(>scan_work);
+}
+
 static void wcn36xx_update_allowed_rates(struct ieee80211_sta *sta,
 enum nl80211_band band)
 {
@@ -1034,6 +1056,7 @@ static const struct ieee80211_ops wcn36xx_ops = {
.tx = wcn36xx_tx,
.set_key= wcn36xx_set_key,
.hw_scan= wcn36xx_hw_scan,
+   .cancel_hw_scan = wcn36xx_cancel_hw_scan,
.bss_info_changed   = wcn36xx_bss_info_changed,
.set_rts_threshold  = wcn36xx_set_rts_threshold,
.sta_add= wcn36xx_sta_add,
diff --git a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h 
b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
index 571e9f76da7e..b52b4da9a967 100644
--- a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
+++ b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
@@ -220,6 +220,7 @@ struct wcn36xx {
int scan_freq;
int scan_band;
struct mutexscan_lock;
+   boolscan_aborted;
 
/* DXE channels */
struct wcn36xx_dxe_ch   dxe_tx_l_ch;/* TX low */
-- 
2.11.0

Re: net: suspicious RCU usage in nf_hook

[Eric Dumazet]

On Wed, 2017-02-01 at 15:48 -0800, Eric Dumazet wrote:
> On Wed, Feb 1, 2017 at 3:29 PM, Cong Wang  wrote:
> 
> > Not sure if it is better. The difference is caught up in 
> > net_enable_timestamp(),
> > which is called setsockopt() path and sk_clone() path, so we could be
> > in netstamp_needed state for a long time too until user-space exercises
> > these paths.
> >
> > I am feeling we probably need to get rid of netstamp_needed_deferred,
> > and simply defer the whole static_key_slow_dec(), like the attached patch
> > (compile only).
> >
> > What do you think?
> 
> I think we need to keep the atomic.
> 
> If two cpus call net_disable_timestamp() roughly at the same time, the
> work will be scheduled once.

Updated patch (but not tested yet)

diff --git a/net/core/dev.c b/net/core/dev.c
index 
7f218e095361520d11c243d650e053321ea7274f..29101c98399f40b6b8e42c31a255d8f1fb6bd7a1
 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1695,24 +1695,19 @@ EXPORT_SYMBOL_GPL(net_dec_egress_queue);
 
 static struct static_key netstamp_needed __read_mostly;
 #ifdef HAVE_JUMP_LABEL
-/* We are not allowed to call static_key_slow_dec() from irq context
- * If net_disable_timestamp() is called from irq context, defer the
- * static_key_slow_dec() calls.
- */
 static atomic_t netstamp_needed_deferred;
-#endif
-
-void net_enable_timestamp(void)
+static void netstamp_clear(struct work_struct *work)
 {
-#ifdef HAVE_JUMP_LABEL
int deferred = atomic_xchg(_needed_deferred, 0);
 
-   if (deferred) {
-   while (--deferred)
-   static_key_slow_dec(_needed);
-   return;
-   }
+   while (deferred--)
+   static_key_slow_dec(_needed);
+}
+static DECLARE_WORK(netstamp_work, netstamp_clear);
 #endif
+
+void net_enable_timestamp(void)
+{
static_key_slow_inc(_needed);
 }
 EXPORT_SYMBOL(net_enable_timestamp);
@@ -1720,12 +1715,12 @@ EXPORT_SYMBOL(net_enable_timestamp);
 void net_disable_timestamp(void)
 {
 #ifdef HAVE_JUMP_LABEL
-   if (in_interrupt()) {
-   atomic_inc(_needed_deferred);
-   return;
-   }
-#endif
+   /* net_disable_timestamp() can be called from non process context */
+   atomic_inc(_needed_deferred);
+   schedule_work(_work);
+#else
static_key_slow_dec(_needed);
+#endif
 }
 EXPORT_SYMBOL(net_disable_timestamp);
 

Re: [PATCH] net: phy: dp83867: Port mirroring support in the DP83867 TI's PHY driver

[Florian Fainelli]

On 02/01/2017 01:05 PM, Lukasz Majewski wrote:
> Dear All,
> 
> Thanks for prompt reply.
> 
>> On 02/01/2017 09:16 AM, Andrew Lunn wrote:
>>> On Wed, Feb 01, 2017 at 03:43:35PM +0100, Lukasz Majewski wrote:
 This patch adds support for enabling or disabling the port
 mirroring feature of the DP83867 TI's PHY device.

 One use case is when bootstrap configuration enables this feature
 (because of e.g. LED wiring) so then one needs to disable it in
 software (u-boot/Linux).
>>>
>>> Hi Lukasz
>>>
>>> How does this differ from "enet-phy-lane-swap"?
>>
>> Same here, I am confused about what port mirroring could be meaning
>> here
> 
> The "net-phy-lane-swap" when defined indicates that the "lane swap"
> needs to be enabled. This is a simple bool variable. In my case it
> would mean: "please enable port mirroring -> write 1 to CFG4 register's
> PORT_MIRROR_EN field"
> 
> My use case is unfortunately different:
> 
> - Due to HW design - during the bootstrap PHY phase - the PHY enables
>   "port mirroring", which is incorrect. 
> 
> Then, in SW I do need to explicitly disable port mirroring (write 0 to
> PORT_MIRROR_EN field in CFG4 register). 

You did not really explain whether port mirroring meant the same thing
as swapping the PHY lanes or not, but based on your paragraph later on,
it does sound like this is the case.

What a poorly chosen name though... in Ethernet world, port mirroring
means the ability to capture traffic from a vector of ports and copying
it verbatim (or sampled) towards a capture port, aka the mirror port...

> 
> 
>> and if we can find a better way to describe what is being added.
>> Thanks!
> 
> We would need a tri-state device tree properly:
> 
> 1. Not defined - do nothing
> 2. Defined as 0 -> explicitly disable port mirroring
> 3. Defined as 1 -> explicitly enable port mirriring
> 
> The "net-phy-lane-swap" only fulfills points 1 and 3 above.
> 
> In my use case I do need point 2.

You can define another boolean property:

net-phy-lane-no-swap?

-- 
Florian

Re: net: suspicious RCU usage in nf_hook

[Eric Dumazet]

On Wed, 2017-02-01 at 13:16 -0800, Eric Dumazet wrote:

> This would permanently leave the kernel in the netstamp_needed state.
> 
> I would prefer the patch using a process context to perform the
> cleanup ? Note there is a race window, but probably not a big deal.
> 
>  net/core/dev.c |   30 ++
>  1 file changed, 10 insertions(+), 20 deletions(-)

Patch is not complete (for the HAVE_JUMP_LABEL=n case)

Would you like to author/submit it ?

Thanks.

Re: net: suspicious RCU usage in nf_hook

[Eric Dumazet]

On Wed, Feb 1, 2017 at 3:29 PM, Cong Wang  wrote:

> Not sure if it is better. The difference is caught up in 
> net_enable_timestamp(),
> which is called setsockopt() path and sk_clone() path, so we could be
> in netstamp_needed state for a long time too until user-space exercises
> these paths.
>
> I am feeling we probably need to get rid of netstamp_needed_deferred,
> and simply defer the whole static_key_slow_dec(), like the attached patch
> (compile only).
>
> What do you think?

I think we need to keep the atomic.

If two cpus call net_disable_timestamp() roughly at the same time, the
work will be scheduled once.

Re: [PATCH] xen-netfront: Delete rx_refill_timer in xennet_disconnect_backend()

[Eric Dumazet]

On Wed, 2017-02-01 at 18:29 -0500, Boris Ostrovsky wrote:

> 
> I could not convince myself that napi_synchronize() is sufficient here
> (mostly because I am not familiar with napi flow). At the same time I
> would rather not make changes in anticipation of possible disappearance
> of netif_carrier_ok() in the future so I'd like this patch to go in as is.
> 
> Unless there are other problems with the patch or if Eric (or others)
> feel strongly about usage of netif_carrier_ok() here.
> 

No strong feelings from me.
We probably have more serious issues to fix anyway.

Re: [PATCH 1/2] net: ethernet: bgmac: init sequence bug

[Zac Schroff]

How about BCMA_IOCTL_PRESERVE_ACROSS_INIT?

On Wed, Feb 1, 2017 at 6:06 PM, Rafał Miłecki  wrote:
> On 02/01/2017 11:39 PM, Jon Mason wrote:
>>
>> From: Zac Schroff 
>>
>> Fix a bug in the 'bgmac' driver init sequence that blind writes for init
>> sequence where it should preserve most bits other than the ones it is
>> deliberately manipulating.
>>
>> Signed-off-by: Zac Schroff 
>> Signed-off-by: Jon Mason 
>> Fixes: f6a95a24957 ("net: ethernet: bgmac: Add platform device support")
>> ---
>>  drivers/net/ethernet/broadcom/bgmac-platform.c | 10 +++---
>>  include/linux/bcma/bcma_regs.h |  1 +
>>  2 files changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/broadcom/bgmac-platform.c
>> b/drivers/net/ethernet/broadcom/bgmac-platform.c
>> index 6f736c1..9bbe05c 100644
>> --- a/drivers/net/ethernet/broadcom/bgmac-platform.c
>> +++ b/drivers/net/ethernet/broadcom/bgmac-platform.c
>> @@ -61,15 +61,19 @@ static bool platform_bgmac_clk_enabled(struct bgmac
>> *bgmac)
>>
>>  static void platform_bgmac_clk_enable(struct bgmac *bgmac, u32 flags)
>>  {
>> -   bgmac_idm_write(bgmac, BCMA_IOCTL,
>> -   (BCMA_IOCTL_CLK | BCMA_IOCTL_FGC | flags));
>> +   u32 regval;
>> +
>> +   /* Some bits of BCMA_IOCTL set by HW/ATF & should not change */
>> +   regval = bgmac_idm_read(bgmac, BCMA_IOCTL) &
>> BCMA_IOCTL_DO_NOT_MODIFY;
>> +   regval |= ((flags & (~BCMA_IOCTL_DO_NOT_MODIFY)) |
>> BCMA_IOCTL_CLK);
>
>
> You don't need these braces around whole calculation.
> This should work the same:
> (flags & (~BCMA_IOCTL_DO_NOT_MODIFY)) | BCMA_IOCTL_CLK
>
>
>> +   bgmac_idm_write(bgmac, BCMA_IOCTL, regval | BCMA_IOCTL_FGC);
>> bgmac_idm_read(bgmac, BCMA_IOCTL);
>>
>> bgmac_idm_write(bgmac, BCMA_RESET_CTL, 0);
>> bgmac_idm_read(bgmac, BCMA_RESET_CTL);
>> udelay(1);
>>
>> -   bgmac_idm_write(bgmac, BCMA_IOCTL, (BCMA_IOCTL_CLK | flags));
>> +   bgmac_idm_write(bgmac, BCMA_IOCTL, regval);
>> bgmac_idm_read(bgmac, BCMA_IOCTL);
>> udelay(1);
>>  }
>> diff --git a/include/linux/bcma/bcma_regs.h
>> b/include/linux/bcma/bcma_regs.h
>> index 9986f82..41d7404 100644
>> --- a/include/linux/bcma/bcma_regs.h
>> +++ b/include/linux/bcma/bcma_regs.h
>> @@ -31,6 +31,7 @@
>>  #define  BCMA_IOCTL_CORE_BITS  0x3FFC
>>  #define  BCMA_IOCTL_PME_EN 0x4000
>>  #define  BCMA_IOCTL_BIST_EN0x8000
>> +#define  BCMA_IOCTL_DO_NOT_MODIFY  0x7F80
>
>
> This sounds like a pretty bad name.
>
> Take a look at brcmsmac and SICF_*:
> http://lxr.free-electrons.com/source/drivers/net/wireless/broadcom/brcm80211/brcmsmac/d11.h?v=4.9#L1737
>
> Or b43 and B43_BCMA_IOCTL_*:
> http://lxr.free-electrons.com/source/drivers/net/wireless/broadcom/b43/b43.h?v=4.9#L494
>
> Both drives modify bits you marked as DO_NOT_MODIFY and they are OK.

Re: [PATCH v2 2/4] net: phy: Initialize mdio clock at probe function

[Florian Fainelli]

On 01/17/2017 08:14 AM, Yendapally Reddy Dhananjaya Reddy wrote:
> Initialize mdio clock divisor in probe function. The ext bus
> bit available in the same register will be used by mdio mux
> to enable external mdio.
> 
> Signed-off-by: Yendapally Reddy Dhananjaya Reddy 
> 

David, this patch should go through your tree (but we forgot to CC you),
patch in patchwork is here:

http://patchwork.ozlabs.org/patch/716281/

Thanks!

> ---
>  drivers/net/phy/mdio-bcm-iproc.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/phy/mdio-bcm-iproc.c 
> b/drivers/net/phy/mdio-bcm-iproc.c
> index c0b4e65..46fe1ae 100644
> --- a/drivers/net/phy/mdio-bcm-iproc.c
> +++ b/drivers/net/phy/mdio-bcm-iproc.c
> @@ -81,8 +81,6 @@ static int iproc_mdio_read(struct mii_bus *bus, int phy_id, 
> int reg)
>   if (rc)
>   return rc;
>  
> - iproc_mdio_config_clk(priv->base);
> -
>   /* Prepare the read operation */
>   cmd = (MII_DATA_TA_VAL << MII_DATA_TA_SHIFT) |
>   (reg << MII_DATA_RA_SHIFT) |
> @@ -112,8 +110,6 @@ static int iproc_mdio_write(struct mii_bus *bus, int 
> phy_id,
>   if (rc)
>   return rc;
>  
> - iproc_mdio_config_clk(priv->base);
> -
>   /* Prepare the write operation */
>   cmd = (MII_DATA_TA_VAL << MII_DATA_TA_SHIFT) |
>   (reg << MII_DATA_RA_SHIFT) |
> @@ -163,6 +159,8 @@ static int iproc_mdio_probe(struct platform_device *pdev)
>   bus->read = iproc_mdio_read;
>   bus->write = iproc_mdio_write;
>  
> + iproc_mdio_config_clk(priv->base);
> +
>   rc = of_mdiobus_register(bus, pdev->dev.of_node);
>   if (rc) {
>   dev_err(>dev, "MDIO bus registration failed\n");
> 


-- 
Florian

[PATCH 1/2] net: ethernet: bgmac: init sequence bug

[Jon Mason]

From: Zac Schroff 

Fix a bug in the 'bgmac' driver init sequence that blind writes for init
sequence where it should preserve most bits other than the ones it is
deliberately manipulating.

Signed-off-by: Zac Schroff 
Signed-off-by: Jon Mason 
Fixes: f6a95a24957 ("net: ethernet: bgmac: Add platform device support")
---
 drivers/net/ethernet/broadcom/bgmac-platform.c | 10 +++---
 include/linux/bcma/bcma_regs.h |  1 +
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bgmac-platform.c 
b/drivers/net/ethernet/broadcom/bgmac-platform.c
index 6f736c1..9bbe05c 100644
--- a/drivers/net/ethernet/broadcom/bgmac-platform.c
+++ b/drivers/net/ethernet/broadcom/bgmac-platform.c
@@ -61,15 +61,19 @@ static bool platform_bgmac_clk_enabled(struct bgmac *bgmac)
 
 static void platform_bgmac_clk_enable(struct bgmac *bgmac, u32 flags)
 {
-   bgmac_idm_write(bgmac, BCMA_IOCTL,
-   (BCMA_IOCTL_CLK | BCMA_IOCTL_FGC | flags));
+   u32 regval;
+
+   /* Some bits of BCMA_IOCTL set by HW/ATF & should not change */
+   regval = bgmac_idm_read(bgmac, BCMA_IOCTL) & BCMA_IOCTL_DO_NOT_MODIFY;
+   regval |= ((flags & (~BCMA_IOCTL_DO_NOT_MODIFY)) | BCMA_IOCTL_CLK);
+   bgmac_idm_write(bgmac, BCMA_IOCTL, regval | BCMA_IOCTL_FGC);
bgmac_idm_read(bgmac, BCMA_IOCTL);
 
bgmac_idm_write(bgmac, BCMA_RESET_CTL, 0);
bgmac_idm_read(bgmac, BCMA_RESET_CTL);
udelay(1);
 
-   bgmac_idm_write(bgmac, BCMA_IOCTL, (BCMA_IOCTL_CLK | flags));
+   bgmac_idm_write(bgmac, BCMA_IOCTL, regval);
bgmac_idm_read(bgmac, BCMA_IOCTL);
udelay(1);
 }
diff --git a/include/linux/bcma/bcma_regs.h b/include/linux/bcma/bcma_regs.h
index 9986f82..41d7404 100644
--- a/include/linux/bcma/bcma_regs.h
+++ b/include/linux/bcma/bcma_regs.h
@@ -31,6 +31,7 @@
 #define  BCMA_IOCTL_CORE_BITS  0x3FFC
 #define  BCMA_IOCTL_PME_EN 0x4000
 #define  BCMA_IOCTL_BIST_EN0x8000
+#define  BCMA_IOCTL_DO_NOT_MODIFY  0x7F80
 #define BCMA_IOST  0x0500 /* IO status */
 #define  BCMA_IOST_CORE_BITS   0x0FFF
 #define  BCMA_IOST_DMA64   0x1000
-- 
2.7.4

[PATCH 2/2] net: ethernet: bgmac: mac address change bug

[Jon Mason]

From: Hari Vyas 

ndo_set_mac_address() passes struct sockaddr * as 2nd parameter to
bgmac_set_mac_address() but code assumed u8 *.  This caused two bytes
chopping and the wrong mac address was configured.

Signed-off-by: Hari Vyas 
Signed-off-by: Jon Mason 
Fixes: 4e209001b86 ("bgmac: write mac address to hardware in 
ndo_set_mac_address")
---
 drivers/net/ethernet/broadcom/bgmac.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/broadcom/bgmac.c 
b/drivers/net/ethernet/broadcom/bgmac.c
index 0e066dc6..ea24072 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -1222,11 +1222,15 @@ static int bgmac_set_mac_address(struct net_device 
*net_dev, void *addr)
 {
struct bgmac *bgmac = netdev_priv(net_dev);
int ret;
+   struct sockaddr *sa = addr;
 
ret = eth_prepare_mac_addr_change(net_dev, addr);
if (ret < 0)
return ret;
-   bgmac_write_mac_address(bgmac, (u8 *)addr);
+
+   ether_addr_copy(bgmac->mac_addr, sa->sa_data);
+   bgmac_write_mac_address(bgmac, bgmac->mac_addr);
+
eth_commit_mac_addr_change(net_dev, addr);
return 0;
 }
-- 
2.7.4

[PATCH 0/2] net: ethernet: bgmac: bug fixes

[Jon Mason]

Bug fixes for bgmac driver

Hari Vyas (1):
  net: ethernet: bgmac: mac address change bug

Zac Schroff (1):
  net: ethernet: bgmac: init sequence bug

 drivers/net/ethernet/broadcom/bgmac-platform.c | 10 +++---
 drivers/net/ethernet/broadcom/bgmac.c  |  6 +-
 include/linux/bcma/bcma_regs.h |  1 +
 3 files changed, 13 insertions(+), 4 deletions(-)

-- 
2.7.4

[PATCH v7 1/3] Bluetooth: btusb: Use an error label for error paths

[Rajat Jain]

Use a label to remove the repetetive cleanup, for error cases.

Signed-off-by: Rajat Jain 
Reviewed-by: Brian Norris 
---
v7: same as v6
v6: same as v5
v5: same as v4
v4: same as v3
v3: Added Brian's "Reviewed-by"
v2: same as v1

 drivers/bluetooth/btusb.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 2f633df9f4e6..ce22cefceed1 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2991,18 +2991,15 @@ static int btusb_probe(struct usb_interface *intf,
err = usb_set_interface(data->udev, 0, 0);
if (err < 0) {
BT_ERR("failed to set interface 0, alt 0 %d", err);
-   hci_free_dev(hdev);
-   return err;
+   goto out_free_dev;
}
}
 
if (data->isoc) {
err = usb_driver_claim_interface(_driver,
 data->isoc, data);
-   if (err < 0) {
-   hci_free_dev(hdev);
-   return err;
-   }
+   if (err < 0)
+   goto out_free_dev;
}
 
 #ifdef CONFIG_BT_HCIBTUSB_BCM
@@ -3016,14 +3013,16 @@ static int btusb_probe(struct usb_interface *intf,
 #endif
 
err = hci_register_dev(hdev);
-   if (err < 0) {
-   hci_free_dev(hdev);
-   return err;
-   }
+   if (err < 0)
+   goto out_free_dev;
 
usb_set_intfdata(intf, data);
 
return 0;
+
+out_free_dev:
+   hci_free_dev(hdev);
+   return err;
 }
 
 static void btusb_disconnect(struct usb_interface *intf)
-- 
2.11.0.483.g087da7b7c-goog

Re: [PATCH 1/2] net: ethernet: bgmac: init sequence bug

[Rafał Miłecki]

On 02/01/2017 11:39 PM, Jon Mason wrote:

From: Zac Schroff 

Fix a bug in the 'bgmac' driver init sequence that blind writes for init
sequence where it should preserve most bits other than the ones it is
deliberately manipulating.

Signed-off-by: Zac Schroff 
Signed-off-by: Jon Mason 
Fixes: f6a95a24957 ("net: ethernet: bgmac: Add platform device support")
---
 drivers/net/ethernet/broadcom/bgmac-platform.c | 10 +++---
 include/linux/bcma/bcma_regs.h |  1 +
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bgmac-platform.c 
b/drivers/net/ethernet/broadcom/bgmac-platform.c
index 6f736c1..9bbe05c 100644
--- a/drivers/net/ethernet/broadcom/bgmac-platform.c
+++ b/drivers/net/ethernet/broadcom/bgmac-platform.c
@@ -61,15 +61,19 @@ static bool platform_bgmac_clk_enabled(struct bgmac *bgmac)

 static void platform_bgmac_clk_enable(struct bgmac *bgmac, u32 flags)
 {
-   bgmac_idm_write(bgmac, BCMA_IOCTL,
-   (BCMA_IOCTL_CLK | BCMA_IOCTL_FGC | flags));
+   u32 regval;
+
+   /* Some bits of BCMA_IOCTL set by HW/ATF & should not change */
+   regval = bgmac_idm_read(bgmac, BCMA_IOCTL) & BCMA_IOCTL_DO_NOT_MODIFY;
+   regval |= ((flags & (~BCMA_IOCTL_DO_NOT_MODIFY)) | BCMA_IOCTL_CLK);


You don't need these braces around whole calculation.
This should work the same:
(flags & (~BCMA_IOCTL_DO_NOT_MODIFY)) | BCMA_IOCTL_CLK



+   bgmac_idm_write(bgmac, BCMA_IOCTL, regval | BCMA_IOCTL_FGC);
bgmac_idm_read(bgmac, BCMA_IOCTL);

bgmac_idm_write(bgmac, BCMA_RESET_CTL, 0);
bgmac_idm_read(bgmac, BCMA_RESET_CTL);
udelay(1);

-   bgmac_idm_write(bgmac, BCMA_IOCTL, (BCMA_IOCTL_CLK | flags));
+   bgmac_idm_write(bgmac, BCMA_IOCTL, regval);
bgmac_idm_read(bgmac, BCMA_IOCTL);
udelay(1);
 }
diff --git a/include/linux/bcma/bcma_regs.h b/include/linux/bcma/bcma_regs.h
index 9986f82..41d7404 100644
--- a/include/linux/bcma/bcma_regs.h
+++ b/include/linux/bcma/bcma_regs.h
@@ -31,6 +31,7 @@
 #define  BCMA_IOCTL_CORE_BITS  0x3FFC
 #define  BCMA_IOCTL_PME_EN 0x4000
 #define  BCMA_IOCTL_BIST_EN0x8000
+#define  BCMA_IOCTL_DO_NOT_MODIFY  0x7F80


This sounds like a pretty bad name.

Take a look at brcmsmac and SICF_*:
http://lxr.free-electrons.com/source/drivers/net/wireless/broadcom/brcm80211/brcmsmac/d11.h?v=4.9#L1737

Or b43 and B43_BCMA_IOCTL_*:
http://lxr.free-electrons.com/source/drivers/net/wireless/broadcom/b43/b43.h?v=4.9#L494

Both drives modify bits you marked as DO_NOT_MODIFY and they are OK.

Re: [PATCH net-next] loopback: clear pfmemalloc on outgoing skb's

[Eric Dumazet]

On Wed, 2017-02-01 at 16:04 -0500, Josef Bacik wrote:
> I was seeing random disconnects while testing NBD over loopback.  This turned
> out to be because NBD sets pfmemalloc on it's socket, however the receiving 
> side
> is a user space application so does not have pfmemalloc set on its socket.  
> This
> means that sk_filter_trim_cap will simply drop this packet, under the 
> assumption
> that the other side will simply retransmit.  Well we do retransmit, and then 
> the
> packet is just dropped again for the same reason.  To keep this from happening
> simply clear skb->pfmemalloc on transmit so that we don't drop the packet on 
> the
> receive side.
> 
> Signed-off-by: Josef Bacik 
> ---
>  drivers/net/loopback.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
> index 1e05b7c..13c9126 100644
> --- a/drivers/net/loopback.c
> +++ b/drivers/net/loopback.c
> @@ -81,6 +81,13 @@ static netdev_tx_t loopback_xmit(struct sk_buff *skb,
>*/
>   skb_dst_force(skb);
>  
> + /* If our transmitter was a pfmemalloc socket we need to clear
> +  * pfmemalloc here, otherwise the receiving socket may not be
> +  * pfmemalloc, and if this is a tcp packet then it'll get dropped and
> +  * all traffic will halt.
> +  */
> + skb->pfmemalloc = false;
> +

I am not sure this is a proper fix.

Presumably if the socket was able to store packets in its write queue,
fact that it sends it to loopback or an Ethernet link should not matter.

Only in RX path the pfmemalloc thing is really important.

So I would rather not set skb->pfmemalloc for skbs allocated for the
write queue, and more exactly the fast clone.

This would actually speed up the stack a bit.

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 
734c71468b013838516cfe8c744dcd0e797a6e2b..f91b81340dc5be80e0c26f9835d9192f35b75ad7
 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -271,7 +271,7 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t 
gfp_mask,
atomic_set(>fclone_ref, 1);
 
fclones->skb2.fclone = SKB_FCLONE_CLONE;
-   fclones->skb2.pfmemalloc = pfmemalloc;
+   fclones->skb2.pfmemalloc = 0;
}
 out:
return skb;

[PATCHv2 net-next 1/2] net: dsa: mv88e6xxx: Fix ATU age timer for MV88E6390

[Andrew Lunn]

The MV88E6390 family uses a different ATU age timer coefficient.
Fix the info structures.

Signed-off-by: Andrew Lunn 
Reviewed-by: Vivien Didelot 
---
v2: Remove redundant "the".
Add Reviewed-by
---
 drivers/net/dsa/mv88e6xxx/chip.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 29190303ace0..22ce57256d34 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -4011,7 +4011,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.port_base_addr = 0x0,
.global1_addr = 0x1b,
.tag_protocol = DSA_TAG_PROTO_DSA,
-   .age_time_coeff = 15000,
+   .age_time_coeff = 3750,
.g1_irqs = 9,
.flags = MV88E6XXX_FLAGS_FAMILY_6390,
.ops = _ops,
@@ -4025,7 +4025,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.num_ports = 11,/* 10 + Z80 */
.port_base_addr = 0x0,
.global1_addr = 0x1b,
-   .age_time_coeff = 15000,
+   .age_time_coeff = 3750,
.g1_irqs = 9,
.tag_protocol = DSA_TAG_PROTO_DSA,
.flags = MV88E6XXX_FLAGS_FAMILY_6390,
@@ -4040,7 +4040,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.num_ports = 11,/* 10 + Z80 */
.port_base_addr = 0x0,
.global1_addr = 0x1b,
-   .age_time_coeff = 15000,
+   .age_time_coeff = 3750,
.g1_irqs = 9,
.tag_protocol = DSA_TAG_PROTO_DSA,
.flags = MV88E6XXX_FLAGS_FAMILY_6390,
@@ -4070,7 +4070,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.num_ports = 11,/* 10 + Z80 */
.port_base_addr = 0x0,
.global1_addr = 0x1b,
-   .age_time_coeff = 15000,
+   .age_time_coeff = 3750,
.g1_irqs = 9,
.tag_protocol = DSA_TAG_PROTO_DSA,
.flags = MV88E6XXX_FLAGS_FAMILY_6390,
@@ -4187,7 +4187,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.num_ports = 11,/* 10 + Z80 */
.port_base_addr = 0x0,
.global1_addr = 0x1b,
-   .age_time_coeff = 15000,
+   .age_time_coeff = 3750,
.g1_irqs = 9,
.tag_protocol = DSA_TAG_PROTO_DSA,
.flags = MV88E6XXX_FLAGS_FAMILY_6390,
@@ -4201,7 +4201,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.num_ports = 11,/* 10 + Z80 */
.port_base_addr = 0x0,
.global1_addr = 0x1b,
-   .age_time_coeff = 15000,
+   .age_time_coeff = 3750,
.g1_irqs = 9,
.tag_protocol = DSA_TAG_PROTO_DSA,
.flags = MV88E6XXX_FLAGS_FAMILY_6390,
-- 
2.11.0

[PATCHv2 net-next 2/2] net: dsa: mv88e6xxx: Fix typ0 when configuring 2.5Gbps

[Andrew Lunn]

In order to enable 2.5Gbps mode, we need the base speed of 10G, plus
the Alt bit setting. Fix a typ0 that used 1Gb base speed.

Signed-off-by: Andrew Lunn 
Reviewed-by: Vivien Didelot 
---
v2: Add Reviewed-by
---
 drivers/net/dsa/mv88e6xxx/port.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/dsa/mv88e6xxx/port.c b/drivers/net/dsa/mv88e6xxx/port.c
index 0db7fa0373ae..d380a93b092c 100644
--- a/drivers/net/dsa/mv88e6xxx/port.c
+++ b/drivers/net/dsa/mv88e6xxx/port.c
@@ -193,7 +193,7 @@ static int mv88e6xxx_port_set_speed(struct mv88e6xxx_chip 
*chip, int port,
ctrl = PORT_PCS_CTRL_SPEED_1000;
break;
case 2500:
-   ctrl = PORT_PCS_CTRL_SPEED_1000 | PORT_PCS_CTRL_ALTSPEED;
+   ctrl = PORT_PCS_CTRL_SPEED_1 | PORT_PCS_CTRL_ALTSPEED;
break;
case 1:
/* all bits set, fall through... */
-- 
2.11.0

Re: [PATCH] net: phy: dp83867: Port mirroring support in the DP83867 TI's PHY driver

[Andrew Lunn]

> What a poorly chosen name though... in Ethernet world, port mirroring
> means the ability to capture traffic from a vector of ports and copying
> it verbatim (or sampled) towards a capture port, aka the mirror port...

Ack. We should avoid "port mirroring" in what ever patch we decide upon.

 Andrew

Re: net: suspicious RCU usage in nf_hook

[Eric Dumazet]

On Wed, 2017-02-01 at 12:51 -0800, Cong Wang wrote:
> On Tue, Jan 31, 2017 at 7:44 AM, Eric Dumazet  wrote:
> > On Mon, 2017-01-30 at 22:19 -0800, Cong Wang wrote:
> >
> >>
> >> The context is process context (TX path before hitting qdisc), and
> >> BH is not disabled, so in_interrupt() doesn't catch it. Hmm, this
> >> makes me thinking maybe we really need to disable BH in this
> >> case for nf_hook()? But it is called in RX path too, and BH is
> >> already disabled there.
> >
> > ipt_do_table() and similar netfilter entry points disable BH.
> >
> > Maybe it is done too late.
> 
> I think we need a fix like the following one for minimum impact.
> 
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 727b6fd..eee7d63 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1720,12 +1720,10 @@ EXPORT_SYMBOL(net_enable_timestamp);
>  void net_disable_timestamp(void)
>  {
>  #ifdef HAVE_JUMP_LABEL
> -   if (in_interrupt()) {
> -   atomic_inc(_needed_deferred);
> -   return;
> -   }
> -#endif
> +   atomic_inc(_needed_deferred);
> +#else
> static_key_slow_dec(_needed);
> +#endif
>  }
>  EXPORT_SYMBOL(net_disable_timestamp);

This would permanently leave the kernel in the netstamp_needed state.

I would prefer the patch using a process context to perform the
cleanup ? Note there is a race window, but probably not a big deal.

 net/core/dev.c |   30 ++
 1 file changed, 10 insertions(+), 20 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index 
7f218e095361520d11c243d650e053321ea7274f..1cae681b6cfd1cf2c9bee7072eb8af9cf79cced8
 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1695,37 +1695,27 @@ EXPORT_SYMBOL_GPL(net_dec_egress_queue);
 
 static struct static_key netstamp_needed __read_mostly;
 #ifdef HAVE_JUMP_LABEL
-/* We are not allowed to call static_key_slow_dec() from irq context
- * If net_disable_timestamp() is called from irq context, defer the
- * static_key_slow_dec() calls.
- */
 static atomic_t netstamp_needed_deferred;
-#endif
-
-void net_enable_timestamp(void)
+static void netstamp_clear(struct work_struct *work)
 {
-#ifdef HAVE_JUMP_LABEL
int deferred = atomic_xchg(_needed_deferred, 0);
 
-   if (deferred) {
-   while (--deferred)
-   static_key_slow_dec(_needed);
-   return;
-   }
+   while (deferred--)
+   static_key_slow_dec(_needed);
+}
+static DECLARE_WORK(netstamp_work, netstamp_clear);
 #endif
+
+void net_enable_timestamp(void)
+{
static_key_slow_inc(_needed);
 }
 EXPORT_SYMBOL(net_enable_timestamp);
 
 void net_disable_timestamp(void)
 {
-#ifdef HAVE_JUMP_LABEL
-   if (in_interrupt()) {
-   atomic_inc(_needed_deferred);
-   return;
-   }
-#endif
-   static_key_slow_dec(_needed);
+   atomic_inc(_needed_deferred);
+   schedule_work(_work);
 }
 EXPORT_SYMBOL(net_disable_timestamp);
 

Re: [PATCH net-next] loopback: clear pfmemalloc on outgoing skb's

[Eric Dumazet]

On Wed, 2017-02-01 at 15:38 -0800, Eric Dumazet wrote:
> On Wed, 2017-02-01 at 16:04 -0500, Josef Bacik wrote:
> > I was seeing random disconnects while testing NBD over loopback.  This 
> > turned
> > out to be because NBD sets pfmemalloc on it's socket, however the receiving 
> > side
> > is a user space application so does not have pfmemalloc set on its socket.  
> > This
> > means that sk_filter_trim_cap will simply drop this packet, under the 
> > assumption
> > that the other side will simply retransmit.  Well we do retransmit, and 
> > then the
> > packet is just dropped again for the same reason.  To keep this from 
> > happening
> > simply clear skb->pfmemalloc on transmit so that we don't drop the packet 
> > on the
> > receive side.
> > 
> > Signed-off-by: Josef Bacik 
> > ---
> >  drivers/net/loopback.c | 7 +++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
> > index 1e05b7c..13c9126 100644
> > --- a/drivers/net/loopback.c
> > +++ b/drivers/net/loopback.c
> > @@ -81,6 +81,13 @@ static netdev_tx_t loopback_xmit(struct sk_buff *skb,
> >  */
> > skb_dst_force(skb);
> >  
> > +   /* If our transmitter was a pfmemalloc socket we need to clear
> > +* pfmemalloc here, otherwise the receiving socket may not be
> > +* pfmemalloc, and if this is a tcp packet then it'll get dropped and
> > +* all traffic will halt.
> > +*/
> > +   skb->pfmemalloc = false;
> > +
> 
> I am not sure this is a proper fix.
> 
> Presumably if the socket was able to store packets in its write queue,
> fact that it sends it to loopback or an Ethernet link should not matter.
> 
> Only in RX path the pfmemalloc thing is really important.
> 
> So I would rather not set skb->pfmemalloc for skbs allocated for the
> write queue, and more exactly the fast clone.
> 
> This would actually speed up the stack a bit.
> 
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 
> 734c71468b013838516cfe8c744dcd0e797a6e2b..f91b81340dc5be80e0c26f9835d9192f35b75ad7
>  100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -271,7 +271,7 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t 
> gfp_mask,
> atomic_set(>fclone_ref, 1);
>  
> fclones->skb2.fclone = SKB_FCLONE_CLONE;
> -   fclones->skb2.pfmemalloc = pfmemalloc;
> +   fclones->skb2.pfmemalloc = 0;


It turns out this part was not needed in current kernel, because
__copy_skb_header() will copy pfmemalloc, since it is included in the
headers_start/headers_end section of skb.

So this patch is not solving your issue.

[PATCH v2] net: stmmac: Fix wrong message in stmmac_probe_config_dt

[Heiner Kallweit]

Most likely a copy & paste error in referenced commit.
Restore the debug message to what it was before.

Fixes: f573c0b9c4e0 ("stmmac: move stmmac_clk, pclk, clk_ptp_ref and stmmac_rst 
to platform structure")
Signed-off-by: Heiner Kallweit 
---
v2:
- Don't remove the wrong comment but replace it with what
  was there before the referenced commit.
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 460f94f5..4963ccdb 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -371,7 +371,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, const 
char **mac)
} else {
clk_prepare_enable(plat->clk_ptp_ref);
plat->clk_ptp_rate = clk_get_rate(plat->clk_ptp_ref);
-   dev_info(>dev, "No reset control found\n");
+   dev_dbg(>dev, "PTP rate %d\n", plat->clk_ptp_rate);
}
 
plat->stmmac_rst = devm_reset_control_get(>dev,
-- 
2.11.0

Re: [PATCH] net: stmmac: Remove wrong message in stmmac_probe_config_dt

[Phil Reid]

On 2/02/2017 05:05, Heiner Kallweit wrote:

I can only imagine that this message ended up there by a copy & paste
mistake. The same message appears correctly a few lines later, but
here it doesn't make sense.

Signed-off-by: Heiner Kallweit 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 460f94f5..5edf23dc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -371,7 +371,6 @@ stmmac_probe_config_dt(struct platform_device *pdev, const 
char **mac)
} else {
clk_prepare_enable(plat->clk_ptp_ref);
plat->clk_ptp_rate = clk_get_rate(plat->clk_ptp_ref);
-   dev_info(>dev, "No reset control found\n");
}

plat->stmmac_rst = devm_reset_control_get(>dev,



It was originally:
netdev_dbg(priv->dev, "PTP rate %d\n", priv->clk_ptp_rate);
Before it got moved in:
commit f573c0b9c4e02691cf87736bd0824fd37ec02e65
stmmac: move stmmac_clk, pclk, clk_ptp_ref and stmmac_rst to platform structure

--
Regards
Phil Reid

Re: [PATCH net] net: phy: Fix lack of reference count on PHY driver

[Florian Fainelli]

On 02/01/2017 11:10 AM, Russell King - ARM Linux wrote:
> On Wed, Feb 01, 2017 at 01:59:38PM -0500, David Miller wrote:
>> From: Florian Fainelli 
>> Date: Wed, 1 Feb 2017 10:55:46 -0800
>>
>>> You are right, but there is still a fundamental problem IMHO in that you
>>> should not be able to rmmod a PHY driver as long as a network device is
>>> attached to the PHY, and if the PHY driver is attached from several
>>> different network devices, they should all have a way to prevent a PHY
>>> driver rmmod, each of them incrementing the driver refcount, which is
>>> what the patche from Maowan does here.
>>
>> It briefly occurred to me that we might want to be able to disconnect
>> PHYs to allow an unload using notifiers, the same way that when you
>> take a netdevice down we emit notifiers so that all of the references
>> to the netdevice can release themselves.
>>
>> I have no idea how well that would work, or whether it is valuable or
>> not.  But it is another way to handle this.
>>
>> But that is a longer-term thing even if we want to go that way, and
>> thus grabbing the proper refs is the right things to do for now.
> 
> It's something I'm effectively already doing as part of my phylink
> project for SFP support, since you can hot-unplug a copper SFP
> module, and the PHY on the copper SFP module will be gone.  phylink,
> however, sits between the network driver and phylib, which isn't
> ideal.

So, for the "net" tree what should we do? I don't really think that we
should be able to let the PHY state machine run without a PHY driver
bound to the device, at best nothing happens, at worse, we just crash
and burn without further chance of recovering.
-- 
Florian

[PATCH net-next] cxgb4: Fix uld_send() for ctrl pkts

[Ganesh Goudar]

From: Arjun V 

Without any uld being loaded, uld_txq_info[] will be NULL. uld_send()
is also used for sending control work requests(for eg: setting filter)
that dont require any ulds to be loaded. Hence move uld_txq_info[]
assignment after ctrl_xmit().

Also added a NULL check for uld_txq_info[].

Fixes: 94cdb8bb993a (cxgb4: Add support for dynamic allocation
   of resources for ULD).
Signed-off-by: Arjun V 
Signed-off-by: Casey Leedom 
Signed-off-by: Ganesh Goudar 
---
 drivers/net/ethernet/chelsio/cxgb4/sge.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c 
b/drivers/net/ethernet/chelsio/cxgb4/sge.c
index 0fe04b4..09653ae 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
@@ -1774,15 +1774,20 @@ static inline int uld_send(struct adapter *adap, struct 
sk_buff *skb,
struct sge_uld_txq *txq;
unsigned int idx = skb_txq(skb);
 
-   txq_info = adap->sge.uld_txq_info[tx_uld_type];
-   txq = _info->uldtxq[idx];
-
if (unlikely(is_ctrl_pkt(skb))) {
/* Single ctrl queue is a requirement for LE workaround path */
if (adap->tids.nsftids)
idx = 0;
return ctrl_xmit(>sge.ctrlq[idx], skb);
}
+
+   txq_info = adap->sge.uld_txq_info[tx_uld_type];
+   if (unlikely(!txq_info)) {
+   WARN_ON(true);
+   return NET_XMIT_DROP;
+   }
+
+   txq = _info->uldtxq[idx];
return ofld_xmit(txq, skb);
 }
 
-- 
2.1.0

Re: [PATCH] net: phy: dp83867: Port mirroring support in the DP83867 TI's PHY driver

[Andrew Lunn]

On Wed, Feb 01, 2017 at 11:13:23PM +0100, Lukasz Majewski wrote:
> Hi Andrew,
> 
> > > We would need a tri-state device tree properly:
> > > 
> > > 1. Not defined - do nothing
> > > 2. Defined as 0 -> explicitly disable port mirroring
> > > 3. Defined as 1 -> explicitly enable port mirriring
> > > 
> > > The "net-phy-lane-swap" only fulfills points 1 and 3 above.
> > > 
> > > In my use case I do need point 2.
> > 
> > Looking at the datasheet, PORT_MIRROR_EN defaults to 0. So it seems
> > reasonable to unconditionally set it to 0 when the PHY driver
> > loads. Any device which needs a value of 1 can set "net-phy-lane-swap"
> 
> Unconditionally setting this field to 0 (as we expect the reset default
> setting) seems to me like a good solution. 
> 
> However, I was not sure if such approach is acceptable by the community.

So the issue here is, are there boards with bootloaders which set this
"lane swap" bit, and rely on Linux not changing it, because the
hardware design has such a swap?

It seems the bootloader you are using does this. But in your case, it
does it wrongly. I'm guessing you have a vendor bootloader? And no
easy access to the sources? Otherwise you would of fixed the
bootloader. So can we assume there are vendor designed boards which
require the swap? Do they run a mainline kernel? Or only the vendor
kernel?

If we know of mainline boards which are going to break, we should not
do this.

If however we do decide to reset it to default value, i think it would
be good to implement net-phy-lane-swap as well, so giving people an
easier path towards mainline.

   Andrew

Re: [PATCH net-next] net: phy: marvell: Add support for 88e1545 PHY

[Florian Fainelli]

On 02/01/2017 03:35 PM, Andrew Lunn wrote:
> The 88e1545 PHYs are discrete Marvell PHYs, found in a quad package on
> the zii-devel-b board. Add support for it to the Marvell PHY driver.
> 
> Signed-off-by: Andrew Lunn 

Reviewed-by: Florian Fainelli 
-- 
Florian

[PATCH net-next] net: ipv4: remove fib_lookup.h from devinet.c include list

[David Ahern]

nothing in devinet.c relies on fib_lookup.h; remove it from the includes

Signed-off-by: David Ahern 
---
 net/ipv4/devinet.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 4cd2ee8857d2..5d367b7ff542 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -65,8 +65,6 @@
 #include 
 #include 
 
-#include "fib_lookup.h"
-
 static struct ipv4_devconf ipv4_devconf = {
.data = {
[IPV4_DEVCONF_ACCEPT_REDIRECTS - 1] = 1,
-- 
2.1.4

Re: [PATCH net] net: phy: Fix lack of reference count on PHY driver

[Florian Fainelli]

On 02/01/2017 02:51 AM, Russell King - ARM Linux wrote:
> It looks to me as if that's the only case where this can happen, so maybe
> the above needs to be:
> 
> if (phydev->drv && phydev->drv->link_change_notify)
> phydev->drv->link_change_notify(phydev);
> 
> Also, I'd suggest making sure that the workqueue is flushed in
> phy_remove() after setting phydev->drv to NULL to ensure that the
> workqueue isn't running while the phy driver is being unbound, which
> should also make module removal safe(r).  I haven't fully analysed
> that though.

I suspect nobody has actually ever tested that, because it's pretty
badly broken at the moment... working on it.
-- 
Florian

Re: [PATCH 1/2] Documentation: devicetree: change the mediatek ethernet compatible string

[James Liao]

On Wed, 2017-01-25 at 09:20 +0100, John Crispin wrote:
> When the binding was defined, I was not aware that mt2701 was an earlier
> version of the SoC. For sake of consistency, the ethernet driver should
> use mt2701 inside the compat string as this is the earliest SoC with the
> ethernet core.
> 
> The ethernet driver is currently of no real use until we finish and
> upstream the DSA driver. There are no users of this binding yet. It should
> be safe to fix this now before it is too late and we need to provide
> backward compatibility for the mt7623-eth compat string.
> 
> Reported-by: Sean Wang 
> Signed-off-by: John Crispin 

Acked-by: James Liao 

> ---
>  Documentation/devicetree/bindings/net/mediatek-net.txt |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt 
> b/Documentation/devicetree/bindings/net/mediatek-net.txt
> index c010faf..c7194e8 100644
> --- a/Documentation/devicetree/bindings/net/mediatek-net.txt
> +++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
> @@ -7,7 +7,7 @@ have dual GMAC each represented by a child node..
>  * Ethernet controller node
>  
>  Required properties:
> -- compatible: Should be "mediatek,mt7623-eth"
> +- compatible: Should be "mediatek,mt2701-eth"
>  - reg: Address and length of the register set for the device
>  - interrupts: Should contain the three frame engines interrupts in numeric
>   order. These are fe_int0, fe_int1 and fe_int2.

Re: [PATCH 2/2] net-next: ethernet: mediatek: change the compatible string

[James Liao]

On Wed, 2017-01-25 at 09:20 +0100, John Crispin wrote:
> When the binding was defined, I was not aware that mt2701 was an earlier
> version of the SoC. For sake of consistency, the ethernet driver should
> use mt2701 inside the compat string as this is the earliest SoC with the
> ethernet core.
> 
> The ethernet driver is currently of no real use until we finish and
> upstream the DSA driver. There are no users of this binding yet. It should
> be safe to fix this now before it is too late and we need to provide
> backward compatibility for the mt7623-eth compat string.
> 
> Reported-by: Sean Wang 
> Signed-off-by: John Crispin 

Acked-by: James Liao 

> ---
>  drivers/net/ethernet/mediatek/mtk_eth_soc.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
> b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index 25ae0c5..9e75768 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -2515,7 +2515,7 @@ static int mtk_remove(struct platform_device *pdev)
>  }
>  
>  const struct of_device_id of_mtk_match[] = {
> - { .compatible = "mediatek,mt7623-eth" },
> + { .compatible = "mediatek,mt2701-eth" },
>   {},
>  };
>  MODULE_DEVICE_TABLE(of, of_mtk_match);

Re: [PATCH net-next v2 0/5] bridge: per vlan dst_metadata support

[Roopa Prabhu]

On 2/1/17, 8:04 PM, Stephen Hemminger wrote:
> On Wed, 01 Feb 2017 20:02:35 -0800
> Roopa Prabhu  wrote:
>
>> On 2/1/17, 5:59 PM, David Ahern wrote:
>>> On 2/1/17 6:23 PM, Alexei Starovoitov wrote:  
 On Tue, Jan 31, 2017 at 10:59:50PM -0800, Roopa Prabhu wrote:  
> 
> This provides the required vxlan bridging function but poses a
> scalability problem with using a separate vxlan netdev for each vni.  
 if I remember correctly this issue was the main reason David Ahern
 put netdev on diet. Sounds like no more fun at netconf ;)
  
>>> oh, it still needs a diet ...  
>>  Even if the netdev went on diet, a netdev per vni for vxlan deployments is 
>> just too much overhead.
>>
>>
> But the intent was VNI == VLAN tag and there are cases where you need per VNI 
> rules.
what rules are these ?
> Having them all smashed into one netdev seems like a step in the wrong 
> direction.
only thing that a vxlan netdev per vni carries is a separate fdb table per vni 
with mac as the key. The natural progression from one fdb table per vni to a 
single fdb table for all vni's is to support a fdb table with   as 
the key. So, unclear why it is a step in the wrong direction. This is exactly 
how the vlan filtering bridge fdb table is built also ...with  as 
the key.

And, note that a single vxlan netdev is already deployed in COLLECT_METADATA 
mode. This series, just makes the fdb
available to the single vxlan netdev in COLLECT_METADATA mode. No change to the 
normal default mode of one vxlan netdev per vni.

Re: [PATCH net-next v2 0/5] bridge: per vlan dst_metadata support

[Stephen Hemminger]

On Wed, 01 Feb 2017 21:58:25 -0800
Roopa Prabhu  wrote:

> On 2/1/17, 5:23 PM, Alexei Starovoitov wrote:
> > On Tue, Jan 31, 2017 at 10:59:50PM -0800, Roopa Prabhu wrote:
> >  
> 
> [snip]
> 
> >> Solution in this patch series:
> >> The Goal is to use a single vxlan device to carry all vnis similar
> >> to the vxlan collect metadata mode but additionally allowing the bridge
> >> and vxlan driver to carry all the forwarding information and also learn.
> >> This implementation uses the existing dst_metadata infrastructure to map
> >> vlan to a tunnel id.  
> > ovs and/or bpf can do the same already, but sounds like the main reason is
> > to keep it integrated with bridge fdb to leverage your offload of bridge
> > fdb into hw asic, right?  
> 
> correct. We already use the bridge driver for vlan filtering and offloading. 
> Having vlan to tunnel map
> elsewhere is not feasible. It is also more than the hw offload asic case, we 
> have routing protocols like bgp looking at bridge driver
> l2 forwarding database for ethernet vpns 
> (https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-07)
> and they need a single place to look at bridge fdb table, vxlan fdb table, 
> vlan and tunnel info. Also, Bgp might not be the only
> protocol needing this info...we support other controllers too. Hence this 
> info cannot be in a bpf or
> live outside the bridge driver.
> 
> We today have the vlan info, bridge fdb table, vxlan remote dst fdb table. 
> the missing peice is the vlan to vxlan-id mapping
> which this series provides (Well, to be correct, this series helps with 
> scaling this mapping.
> Today we use a vxlan netdev per vlan which does not scale well). And this is 
> a very common configuration in
> data center switches that provide vxlan bridging gateway function.
> [Google for 'vlan to vxlan mapping' should give a couple hits. I did not want 
> to paste a link
> to any specific vendor guide here...but found a generic blog --> 
> http://www.definethecloud.net/vxlan-deep-dive/]
> 
> > If so, I guess, the extra complexity can be justified.
> > The question is how do you program hw ? Is there really 1 to 1 mapping
> > in the asics too? Or is it more flexible ?  
> yes, it is 1-1 mapping in asics too (might be variations on different chips 
> but
> this kind of function is supported by most asics).
> 
> > I think most swith asics can do other tunnels too,
> > so can this vlan->vxlan 1 to 1 be generalized to cover different
> > types of tunnels that can be configured on the switch?  
> 
> 
> yes, it can be. Hence i have kept the tunnel info netlink attribute generic. 
> similar to how LWT provides
> various encaps at the L3 routing layer, this can provide such function at the 
> L2 bridge layer. But, to keep it relatively lite I use the
> already existing dst_metadata infra to bridge vlan to vxlan (Which is already 
> done in the case of vxlan collect metadata mode.
> I simply extend it to cover the bridge case).
> 
> thanks,

I wonder if this is a case for a new driver (with same subset of bridge API). 
You probably
don't want all the baggage of STP, netfilter, VLAN filtering, etc when doing 
VXLAN VNI bridging.

Re: [net-next ovs clone action 3/3] openvswitch: kernel datapath clone action

[Pravin Shelar]

On Tue, Jan 31, 2017 at 8:47 AM, Andy Zhou  wrote:
> Add 'clone' kernel datapath support. In case the actions within clone
> do not modify the current flow, the actions are executed without
> making a copy of current key before execution. This analysis is
> done once per flow installation.
>
> On the other hand, in case the actions within clone may modify
> current flow key, a key has to be copied. In case the percpu
> 'flow_keys' is available for the next 'exec_actions_level', the clone
> actions will be executed without using the deferred fifo. Otherwise,
> deferred fifo is used this clone action.
>

I think we can use sample action to clone packet and apply
optimization to sample action. That will allow greater use of existing
action without additional complexity.

Thanks,
Pravin.

[PATCH net-next] net: add LINUX_MIB_PFMEMALLOCDROP counter

[Eric Dumazet]

From: Eric Dumazet 

Debugging issues caused by pfmemalloc is often tedious.

Add a new SNMP counter to more easily diagnose these problems.

Signed-off-by: Eric Dumazet 
Cc: Josef Bacik 
---
 include/uapi/linux/snmp.h |1 +
 net/core/filter.c |5 +++--
 net/ipv4/proc.c   |1 +
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/include/uapi/linux/snmp.h b/include/uapi/linux/snmp.h
index 
e7a31f8306903f53bc5881ae4c271f85cad2e361..3b2bed7ca9a4d92c5671e614f2bc598668805f75
 100644
--- a/include/uapi/linux/snmp.h
+++ b/include/uapi/linux/snmp.h
@@ -240,6 +240,7 @@ enum
LINUX_MIB_SACKMERGED,
LINUX_MIB_SACKSHIFTFALLBACK,
LINUX_MIB_TCPBACKLOGDROP,
+   LINUX_MIB_PFMEMALLOCDROP,
LINUX_MIB_TCPMINTTLDROP, /* RFC 5082 */
LINUX_MIB_TCPDEFERACCEPTDROP,
LINUX_MIB_IPRPFILTER, /* IP Reverse Path Filter (rp_filter) */
diff --git a/net/core/filter.c b/net/core/filter.c
index 
1e00737e3bc370bc6c1afaf602439c81208ea3ac..0b753cbb2536763de53d266c9b9126d63942d7e5
 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -76,9 +76,10 @@ int sk_filter_trim_cap(struct sock *sk, struct sk_buff *skb, 
unsigned int cap)
 * allow SOCK_MEMALLOC sockets to use it as this socket is
 * helping free memory
 */
-   if (skb_pfmemalloc(skb) && !sock_flag(sk, SOCK_MEMALLOC))
+   if (skb_pfmemalloc(skb) && !sock_flag(sk, SOCK_MEMALLOC)) {
+   NET_INC_STATS(sock_net(sk), LINUX_MIB_PFMEMALLOCDROP);
return -ENOMEM;
-
+   }
err = BPF_CGROUP_RUN_PROG_INET_INGRESS(sk, skb);
if (err)
return err;
diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index 
a9deeb90dd36e0a8f94596b4f563ad63925344cf..69cf49e8356d0184f774840c9dc96560f2ae2f2b
 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -262,6 +262,7 @@ static const struct snmp_mib snmp4_net_list[] = {
SNMP_MIB_ITEM("TCPSackMerged", LINUX_MIB_SACKMERGED),
SNMP_MIB_ITEM("TCPSackShiftFallback", LINUX_MIB_SACKSHIFTFALLBACK),
SNMP_MIB_ITEM("TCPBacklogDrop", LINUX_MIB_TCPBACKLOGDROP),
+   SNMP_MIB_ITEM("PFMemallocDrop", LINUX_MIB_PFMEMALLOCDROP),
SNMP_MIB_ITEM("TCPMinTTLDrop", LINUX_MIB_TCPMINTTLDROP),
SNMP_MIB_ITEM("TCPDeferAcceptDrop", LINUX_MIB_TCPDEFERACCEPTDROP),
SNMP_MIB_ITEM("IPReversePathFilter", LINUX_MIB_IPRPFILTER),

linux-next: manual merge of the net-next tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  net/sched/cls_matchall.c

between commit:

  fd62d9f5c575 ("net/sched: matchall: Fix configuration race")

from Linus' tree and commit:

  ec2507d2a306 ("net/sched: cls_matchall: Fix error path")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc net/sched/cls_matchall.c
index b12bc2abea93,fcecf5aac666..
--- a/net/sched/cls_matchall.c
+++ b/net/sched/cls_matchall.c
@@@ -118,19 -141,24 +118,24 @@@ static int mall_set_parms(struct net *n
struct tcf_exts e;
int err;
  
-   tcf_exts_init(, TCA_MATCHALL_ACT, 0);
+   err = tcf_exts_init(, TCA_MATCHALL_ACT, 0);
+   if (err)
+   return err;
err = tcf_exts_validate(net, tp, tb, est, , ovr);
if (err < 0)
-   return err;
+   goto errout;
  
if (tb[TCA_MATCHALL_CLASSID]) {
 -  f->res.classid = nla_get_u32(tb[TCA_MATCHALL_CLASSID]);
 -  tcf_bind_filter(tp, >res, base);
 +  head->res.classid = nla_get_u32(tb[TCA_MATCHALL_CLASSID]);
 +  tcf_bind_filter(tp, >res, base);
}
  
 -  tcf_exts_change(tp, >exts, );
 +  tcf_exts_change(tp, >exts, );
  
return 0;
+ errout:
+   tcf_exts_destroy();
+   return err;
  }
  
  static int mall_change(struct net *net, struct sk_buff *in_skb,
@@@ -162,39 -194,43 +167,44 @@@
return -EINVAL;
}
  
 -  f = kzalloc(sizeof(*f), GFP_KERNEL);
 -  if (!f)
 +  new = kzalloc(sizeof(*new), GFP_KERNEL);
 +  if (!new)
return -ENOBUFS;
  
-   tcf_exts_init(>exts, TCA_MATCHALL_ACT, 0);
 -  err = tcf_exts_init(>exts, TCA_MATCHALL_ACT, 0);
++  err = tcf_exts_init(>exts, TCA_MATCHALL_ACT, 0);
+   if (err)
+   goto err_exts_init;
  
if (!handle)
handle = 1;
 -  f->handle = handle;
 -  f->flags = flags;
 +  new->handle = handle;
 +  new->flags = flags;
  
 -  err = mall_set_parms(net, tp, f, base, tb, tca[TCA_RATE], ovr);
 +  err = mall_set_parms(net, tp, new, base, tb, tca[TCA_RATE], ovr);
if (err)
-   goto errout;
+   goto err_set_parms;
  
if (tc_should_offload(dev, tp, flags)) {
 -  err = mall_replace_hw_filter(tp, f, (unsigned long) f);
 +  err = mall_replace_hw_filter(tp, new, (unsigned long) new);
if (err) {
if (tc_skip_sw(flags))
-   goto errout;
+   goto err_replace_hw_filter;
else
err = 0;
}
}
  
 -  *arg = (unsigned long) f;
 -  rcu_assign_pointer(head->filter, f);
 -
 +  *arg = (unsigned long) head;
 +  rcu_assign_pointer(tp->root, new);
 +  if (head)
 +  call_rcu(>rcu, mall_destroy_rcu);
return 0;
  
- errout:
+ err_replace_hw_filter:
+ err_set_parms:
 -  tcf_exts_destroy(>exts);
++  tcf_exts_destroy(>exts);
+ err_exts_init:
 -  kfree(f);
 +  kfree(new);
return err;
  }
  

Re: [PATCH net-next v2 0/5] bridge: per vlan dst_metadata support

[David Ahern]

On 2/1/17 6:23 PM, Alexei Starovoitov wrote:
> On Tue, Jan 31, 2017 at 10:59:50PM -0800, Roopa Prabhu wrote:
>> 
>> This provides the required vxlan bridging function but poses a
>> scalability problem with using a separate vxlan netdev for each vni.
> if I remember correctly this issue was the main reason David Ahern
> put netdev on diet. Sounds like no more fun at netconf ;)
> 

oh, it still needs a diet ...

Re: [net-next ovs clone action 3/3] openvswitch: kernel datapath clone action

[Andy Zhou]

On Wed, Feb 1, 2017 at 6:30 PM, Pravin Shelar  wrote:
> On Tue, Jan 31, 2017 at 8:47 AM, Andy Zhou  wrote:
>> Add 'clone' kernel datapath support. In case the actions within clone
>> do not modify the current flow, the actions are executed without
>> making a copy of current key before execution. This analysis is
>> done once per flow installation.
>>
>> On the other hand, in case the actions within clone may modify
>> current flow key, a key has to be copied. In case the percpu
>> 'flow_keys' is available for the next 'exec_actions_level', the clone
>> actions will be executed without using the deferred fifo. Otherwise,
>> deferred fifo is used this clone action.
>>
>
> I think we can use sample action to clone packet and apply
> optimization to sample action. That will allow greater use of existing
> action without additional complexity.
>
O.K. I will rework the patch series to apply the optimizations to the sample
action.  Thanks for the review and comment.

Re: [PATCH net-next v2 0/5] bridge: per vlan dst_metadata support

[Roopa Prabhu]

On 2/1/17, 5:59 PM, David Ahern wrote:
> On 2/1/17 6:23 PM, Alexei Starovoitov wrote:
>> On Tue, Jan 31, 2017 at 10:59:50PM -0800, Roopa Prabhu wrote:
>>> 
>>> This provides the required vxlan bridging function but poses a
>>> scalability problem with using a separate vxlan netdev for each vni.
>> if I remember correctly this issue was the main reason David Ahern
>> put netdev on diet. Sounds like no more fun at netconf ;)
>>
> oh, it still needs a diet ...
 Even if the netdev went on diet, a netdev per vni for vxlan deployments is 
just too much overhead.

Re: [PATCH] net: stmmac: Remove wrong message in stmmac_probe_config_dt

[Heiner Kallweit]

Am 02.02.2017 um 03:20 schrieb Phil Reid:
> On 2/02/2017 05:05, Heiner Kallweit wrote:
>> I can only imagine that this message ended up there by a copy & paste
>> mistake. The same message appears correctly a few lines later, but
>> here it doesn't make sense.
>>
>> Signed-off-by: Heiner Kallweit 
>> ---
>>  drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c 
>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
>> index 460f94f5..5edf23dc 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
>> @@ -371,7 +371,6 @@ stmmac_probe_config_dt(struct platform_device *pdev, 
>> const char **mac)
>>  } else {
>>  clk_prepare_enable(plat->clk_ptp_ref);
>>  plat->clk_ptp_rate = clk_get_rate(plat->clk_ptp_ref);
>> -dev_info(>dev, "No reset control found\n");
>>  }
>>
>>  plat->stmmac_rst = devm_reset_control_get(>dev,
>>
> 
> It was originally:
> netdev_dbg(priv->dev, "PTP rate %d\n", priv->clk_ptp_rate);
> Before it got moved in:
> commit f573c0b9c4e02691cf87736bd0824fd37ec02e65
> stmmac: move stmmac_clk, pclk, clk_ptp_ref and stmmac_rst to platform 
> structure
> 
Thanks for the hint, I'll send a v2 to restore the original message.

Re: [PATCH net-next v2 0/5] bridge: per vlan dst_metadata support

[Alexei Starovoitov]

On Tue, Jan 31, 2017 at 10:59:50PM -0800, Roopa Prabhu wrote:
> 
> This provides the required vxlan bridging function but poses a
> scalability problem with using a separate vxlan netdev for each vni.

if I remember correctly this issue was the main reason David Ahern
put netdev on diet. Sounds like no more fun at netconf ;)

> Solution in this patch series:
> The Goal is to use a single vxlan device to carry all vnis similar
> to the vxlan collect metadata mode but additionally allowing the bridge
> and vxlan driver to carry all the forwarding information and also learn.
> This implementation uses the existing dst_metadata infrastructure to map
> vlan to a tunnel id.

ovs and/or bpf can do the same already, but sounds like the main reason is
to keep it integrated with bridge fdb to leverage your offload of bridge
fdb into hw asic, right?
If so, I guess, the extra complexity can be justified.
The question is how do you program hw ? Is there really 1 to 1 mapping
in the asics too? Or is it more flexible ?
I think most swith asics can do other tunnels too,
so can this vlan->vxlan 1 to 1 be generalized to cover different
types of tunnels that can be configured on the switch?

[PATCH net-next] net: remove useless pfmemalloc setting

[Eric Dumazet]

From: Eric Dumazet 

When __alloc_skb() allocates an skb from fast clone cache,
setting pfmemalloc on the clone is not needed.

Clone will be properly initialized later at skb_clone() time,
including pfmemalloc field, as it is included in the
headers_start/headers_end section which is fully copied.

Signed-off-by: Eric Dumazet 
---
 net/core/skbuff.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 
26c1344cc23e31d4248d23fc007bcab4b034c5c9..4f8f2a1a66b5a36705e8f9966f7abd751932dcc6
 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -271,7 +271,6 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t 
gfp_mask,
atomic_set(>fclone_ref, 1);
 
fclones->skb2.fclone = SKB_FCLONE_CLONE;
-   fclones->skb2.pfmemalloc = pfmemalloc;
}
 out:
return skb;

Re: [PATCH net-next v2 0/5] bridge: per vlan dst_metadata support

[Stephen Hemminger]

On Wed, 01 Feb 2017 20:02:35 -0800
Roopa Prabhu  wrote:

> On 2/1/17, 5:59 PM, David Ahern wrote:
> > On 2/1/17 6:23 PM, Alexei Starovoitov wrote:  
> >> On Tue, Jan 31, 2017 at 10:59:50PM -0800, Roopa Prabhu wrote:  
> >>> 
> >>> This provides the required vxlan bridging function but poses a
> >>> scalability problem with using a separate vxlan netdev for each vni.  
> >> if I remember correctly this issue was the main reason David Ahern
> >> put netdev on diet. Sounds like no more fun at netconf ;)
> >>  
> > oh, it still needs a diet ...  
>  Even if the netdev went on diet, a netdev per vni for vxlan deployments is 
> just too much overhead.
> 
> 

But the intent was VNI == VLAN tag and there are cases where you need per VNI 
rules.
Having them all smashed into one netdev seems like a step in the wrong 
direction.

Re: [PATCH net-next v2 0/5] bridge: per vlan dst_metadata support

[Roopa Prabhu]

On 2/1/17, 5:23 PM, Alexei Starovoitov wrote:
> On Tue, Jan 31, 2017 at 10:59:50PM -0800, Roopa Prabhu wrote:
>

[snip]

>> Solution in this patch series:
>> The Goal is to use a single vxlan device to carry all vnis similar
>> to the vxlan collect metadata mode but additionally allowing the bridge
>> and vxlan driver to carry all the forwarding information and also learn.
>> This implementation uses the existing dst_metadata infrastructure to map
>> vlan to a tunnel id.
> ovs and/or bpf can do the same already, but sounds like the main reason is
> to keep it integrated with bridge fdb to leverage your offload of bridge
> fdb into hw asic, right?

correct. We already use the bridge driver for vlan filtering and offloading. 
Having vlan to tunnel map
elsewhere is not feasible. It is also more than the hw offload asic case, we 
have routing protocols like bgp looking at bridge driver
l2 forwarding database for ethernet vpns 
(https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-07)
and they need a single place to look at bridge fdb table, vxlan fdb table, vlan 
and tunnel info. Also, Bgp might not be the only
protocol needing this info...we support other controllers too. Hence this info 
cannot be in a bpf or
live outside the bridge driver.

We today have the vlan info, bridge fdb table, vxlan remote dst fdb table. the 
missing peice is the vlan to vxlan-id mapping
which this series provides (Well, to be correct, this series helps with scaling 
this mapping.
Today we use a vxlan netdev per vlan which does not scale well). And this is a 
very common configuration in
data center switches that provide vxlan bridging gateway function.
[Google for 'vlan to vxlan mapping' should give a couple hits. I did not want 
to paste a link
to any specific vendor guide here...but found a generic blog --> 
http://www.definethecloud.net/vxlan-deep-dive/]

> If so, I guess, the extra complexity can be justified.
> The question is how do you program hw ? Is there really 1 to 1 mapping
> in the asics too? Or is it more flexible ?
yes, it is 1-1 mapping in asics too (might be variations on different chips but
this kind of function is supported by most asics).

> I think most swith asics can do other tunnels too,
> so can this vlan->vxlan 1 to 1 be generalized to cover different
> types of tunnels that can be configured on the switch?


yes, it can be. Hence i have kept the tunnel info netlink attribute generic. 
similar to how LWT provides
various encaps at the L3 routing layer, this can provide such function at the 
L2 bridge layer. But, to keep it relatively lite I use the
already existing dst_metadata infra to bridge vlan to vxlan (Which is already 
done in the case of vxlan collect metadata mode.
I simply extend it to cover the bridge case).

thanks,

Re: [PATCH net-next] loopback: clear pfmemalloc on outgoing skb's

[Eric Dumazet]

On Wed, 2017-02-01 at 15:38 -0800, Eric Dumazet wrote:

> I am not sure this is a proper fix.
> 
> Presumably if the socket was able to store packets in its write queue,
> fact that it sends it to loopback or an Ethernet link should not matter.
> 
> Only in RX path the pfmemalloc thing is really important.
> 
> So I would rather not set skb->pfmemalloc for skbs allocated for the
> write queue, and more exactly the fast clone.

Also note that any looped packet would have the problem : veth, macvlan,
ipvlan, ...

Re: [PATCH v2 3/4] phy: Add USB3 PHY support for Broadcom NSP SoC

[Rafał Miłecki]

[Resending with fixed/complete Cc-s]

On Tue, 17 Jan 2017 11:14:29 -0500, Yendapally Reddy Dhananjaya Reddy 
 wrote:> This patch adds support for Broadcom 
NSP USB3 PHY
>
> Signed-off-by: Yendapally Reddy Dhananjaya Reddy 


Seriously?! I really dislike what you did there.

NACK.

You are aware this block is common for both: Northstar and Northstar Plus and
we already have phy-bcm-ns-usb3.c! In fact Jon told me to rewrite my initial
driver to make is possible to reuse it on NSP and I did that!

This is old comment from Jon:

In 30 March 2016 at 23:31, Jon Mason  wrote:
> On Mon, Mar 28, 2016 at 9:46 PM, Florian Fainelli 
> wrote:
>>
>> CC: bcm-kernel-feedback-list, Jon
>
>
> This is a common IP block with NSP.  I believe with some minor changes it
> can support both.  Please allow me 1-2 days to look at these in more detail
> and see if I can get these patches working on NSP.

Please start using existing code instead of inventing everything from the
scratch internally at Broadcom. You did the same thing with (Q)SPI driver.


This driver duplicates phy-bcm-ns-usb3.c and should have not been accepted. I
strongly suggest *reverting* it and adjusting existing driver if needed.

[patch net-next] sfc: a couple off by one bugs

[Dan Carpenter]

These checks are off by one.  These are just sanity checks and we don't
ever pass invalid values for "encap_type" so it's harmless.

Fixes: 9b4108012517 ("sfc: insert catch-all filters for encapsulated traffic")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/net/ethernet/sfc/ef10.c b/drivers/net/ethernet/sfc/ef10.c
index 8bec9383d754..dec0c8083ff3 100644
--- a/drivers/net/ethernet/sfc/ef10.c
+++ b/drivers/net/ethernet/sfc/ef10.c
@@ -5080,7 +5080,7 @@ static int efx_ef10_filter_insert_def(struct efx_nic *efx,
 
/* quick bounds check (BCAST result impossible) */
BUILD_BUG_ON(EFX_EF10_BCAST != 0);
-   if (encap_type > ARRAY_SIZE(map) || map[encap_type] == 0) {
+   if (encap_type >= ARRAY_SIZE(map) || map[encap_type] == 0) {
WARN_ON(1);
return -EINVAL;
}
@@ -5134,7 +5134,7 @@ static int efx_ef10_filter_insert_def(struct efx_nic *efx,
 
/* quick bounds check (BCAST result impossible) */
BUILD_BUG_ON(EFX_EF10_BCAST != 0);
-   if (encap_type > ARRAY_SIZE(map) || map[encap_type] == 0) {
+   if (encap_type >= ARRAY_SIZE(map) || map[encap_type] == 0) {
WARN_ON(1);
return -EINVAL;
}

Re: [PATCH net] net: phy: Fix lack of reference count on PHY driver

[Russell King - ARM Linux]

On Tue, Jan 31, 2017 at 06:46:43PM -0800, Florian Fainelli wrote:
> From: Mao Wenan 
> 
> There is currently no reference count being held on the PHY driver,
> which makes it possible to remove the PHY driver module while the PHY
> state machine is running and polling the PHY. This could cause crashes
> similar to this one to show up:

Does this really solve the problem?  What if you use sysfs to unbind the
driver but without removing the module?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH V2 2/2] qedf: Add QLogic FastLinQ offload FCoE driver framework.

[Hannes Reinecke]

On 01/31/2017 06:08 PM, Chad Dupuis wrote:


On Mon, 30 Jan 2017, 10:34am -, Hannes Reinecke wrote:


On 01/25/2017 09:33 PM, Dupuis, Chad wrote:

From: "Dupuis, Chad" 


[ .. ]

+   if (opcode == ELS_LS_RJT) {
+   rjt = fc_frame_payload_get(fp, sizeof(*rjt));
+   QEDF_INFO(&(qedf->dbg_ctx), QEDF_LOG_ELS,
+   "Received LS_RJT for REC: er_reason=0x%x, "
+   "er_explan=0x%x.\n", rjt->er_reason, rjt->er_explan);
+   /*
+* The following response(s) mean that we need to reissue the
+* request on another exchange.  We need to do this without
+* informing the upper layers lest it cause an application
+* error.
+*/
+   if ((rjt->er_reason == ELS_RJT_LOGIC ||
+   rjt->er_reason == ELS_RJT_UNAB) &&
+   rjt->er_explan == ELS_EXPL_OXID_RXID) {
+   QEDF_INFO(&(qedf->dbg_ctx), QEDF_LOG_ELS,
+   "Handle CMD LOST case.\n");
+   qedf_requeue_io_req(orig_io_req);
+   }


Care to explain this?
I found requeing within the driver without notifying the upper layers
deeply troubling.
I've came across this (or a similar issue) during implementing
FCoE over virtio; there it turned out to be an issue with the target not
handling frames in the correct order.
So it looks you are attempting to solve the problem of a REC being sent
for a command which is not know at the target.
Meaning it's either lost in the fabric, hasn't been seen by the target
(yet), or having already been processed by the target.

The above code would only solve the second problem; however, that would
indicate a command ordering issue as the REC would have arrived at the
target _before_ the originating command.
So doing a resend would only help for _that_ specific case, not for the
others.
And it's not quite clear why resending with a different OXID would help
here; typically it's the _RXID_ which isn't found ...


The problem I've observed is that If I return an error to the SCSI layer
it propogates up to the st driver and the test application would fail
since st would fail the I/O.  As the comment explains we do this on
another exchange internally in the driver so as not to cause the tape
backup application/test to fail.

bnx2fc behaves like this IIRC.


Ah, yes.
I've had this discussion with James Smart, too.
When a command abort fails with 'Invalid OXID/RXID' we should be 
retrying the command with a different set of IDs, as the original

need to quarantined.
(Which, incidentaily, you don't do, right? You cannot re-use that 
particular exchange until you either got a response for it or you reset 
the exchange manager. If you don't you run into the risk of getting an 
invalid completion if for some reason the command _does_ return 
eventually...)


Even though I'd rather like to have it resolved in libfc or even the 
SCSI midlayer itself, it's not something which should hold off the 
entire submission.




[ .. ]

+static void qedf_fcoe_process_vlan_resp(struct qedf_ctx *qedf,
+   struct sk_buff *skb)
+{
+   struct fip_header *fiph;
+   struct fip_desc *desc;
+   u16 vid = 0;
+   ssize_t rlen;
+   size_t dlen;
+
+   fiph = (struct fip_header *)(((void *)skb->data) + 2 * ETH_ALEN + 2);
+
+   rlen = ntohs(fiph->fip_dl_len) * 4;
+   desc = (struct fip_desc *)(fiph + 1);
+   while (rlen > 0) {
+   dlen = desc->fip_dlen * FIP_BPW;
+   switch (desc->fip_dtype) {
+   case FIP_DT_VLAN:
+   vid = ntohs(((struct fip_vlan_desc *)desc)->fd_vlan);
+   break;
+   }
+   desc = (struct fip_desc *)((char *)desc + dlen);
+   rlen -= dlen;
+   }
+
+   QEDF_INFO(&(qedf->dbg_ctx), QEDF_LOG_DISC, "VLAN response, "
+  "vid=0x%x.\n", vid);
+
+   if (vid > 0 && qedf->vlan_id != vid) {
+   qedf_set_vlan_id(qedf, vid);
+
+   /* Inform waiter that it's ok to call fcoe_ctlr_link up() */
+   complete(>fipvlan_compl);
+   }
+}
+

As mentioned, this will fail for HP VirtualConnect, which return a vid
of '0', indicating that the FCoE link should run on the interface itself.
And this is actually a valid response, I would think that you should be
calling complete() for any response ...


In testing I would get responses that would seem to contain VID 0 but then
subsequent responses contain the valid VID.  If I try to go with a VID of
0 FIP discovery would fail.  It could be possible that there's a bug in
the code that parses the FIP VLAN response but I'll like to leave this in
for now and it can be removed once I figure where the issue may be.


Okay.

Cheers,

Hannes
--
Dr. Hannes Reinecke   zSeries & Storage
h...@suse.de  +49 911 74053 688

Re: [PATCH net-next 1/3] trace: add variant without spacing in trace_print_hex_seq

[Daniel Borkmann]

On 01/30/2017 09:44 PM, Steven Rostedt wrote:

On Wed, 25 Jan 2017 02:28:16 +0100
Daniel Borkmann  wrote:


For upcoming tracepoint support for BPF, we want to dump the program's
tag. Format should be similar to __print_hex(), but without spacing.
Add a __print_hex_str() variant for exactly that purpose that reuses
trace_print_hex_seq().

Signed-off-by: Daniel Borkmann 
Cc: Steven Rostedt 
Cc: Arnaldo Carvalho de Melo 
---
  include/linux/trace_events.h | 3 ++-
  include/trace/trace_events.h | 8 +++-
  kernel/trace/trace_output.c  | 7 ---
  3 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
index be00761..cfa475a 100644
--- a/include/linux/trace_events.h
+++ b/include/linux/trace_events.h
@@ -33,7 +33,8 @@ const char *trace_print_bitmask_seq(struct trace_seq *p, void 
*bitmask_ptr,
unsigned int bitmask_size);

  const char *trace_print_hex_seq(struct trace_seq *p,
-   const unsigned char *buf, int len);
+   const unsigned char *buf, int len,
+   bool spacing);


Hmm, "spacing" doesn't really mean much. What about the invert of it,
and have "concatenate"?


Sure, I'm fine with that.


  const char *trace_print_array_seq(struct trace_seq *p,
   const void *buf, int count,
diff --git a/include/trace/trace_events.h b/include/trace/trace_events.h
index 467e12f..9f68462 100644
--- a/include/trace/trace_events.h
+++ b/include/trace/trace_events.h
@@ -297,7 +297,12 @@
  #endif

  #undef __print_hex
-#define __print_hex(buf, buf_len) trace_print_hex_seq(p, buf, buf_len)
+#define __print_hex(buf, buf_len)  \
+   trace_print_hex_seq(p, buf, buf_len, true)
+
+#undef __print_hex_str
+#define __print_hex_str(buf, buf_len)  \
+   trace_print_hex_seq(p, buf, buf_len, false)

  #undef __print_array
  #define __print_array(array, count, el_size)  \
@@ -711,6 +716,7 @@
  #undef __print_flags
  #undef __print_symbolic
  #undef __print_hex
+#undef __print_hex_str
  #undef __get_dynamic_array
  #undef __get_dynamic_array_len
  #undef __get_str
diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
index 5d33a73..30a144b1 100644
--- a/kernel/trace/trace_output.c
+++ b/kernel/trace/trace_output.c
@@ -163,14 +163,15 @@ enum print_line_t trace_print_printk_msg_only(struct 
trace_iterator *iter)
  EXPORT_SYMBOL_GPL(trace_print_bitmask_seq);


With the addition of this boolean parameter, this function shold
probably have a kernel doc header, that can explain the parameters.


Yeah, I can add that. Since the patch got already applied, I will send
a follow-up for adding the kdoc and for changing the bool logic/name as
concatenate.

Thanks for your review!
Daniel

Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data

[Pali Rohár]

On Tuesday 31 January 2017 07:59:18 Tony Lindgren wrote:
> * Kalle Valo  [170130 22:36]:
> > Tony Lindgren  writes:
> > 
> > > * Pavel Machek  [170127 11:41]:
> > >> On Fri 2017-01-27 17:23:07, Kalle Valo wrote:
> > >> > Pali Rohár  writes:
> > >> > 
> > >> > > On Friday 27 January 2017 14:26:22 Kalle Valo wrote:
> > >> > >> Pali Rohár  writes:
> > >> > >> 
> > >> > >> > 2) It was already tested that example NVS data can be used for 
> > >> > >> > N900 e.g.
> > >> > >> > for SSH connection. If real correct data are not available it is 
> > >> > >> > better
> > >> > >> > to use at least those example (and probably log warning message) 
> > >> > >> > so user
> > >> > >> > can connect via SSH and start investigating where is problem.
> > >> > >> 
> > >> > >> I disagree. Allowing default calibration data to be used can be
> > >> > >> unnoticed by user and left her wondering why wifi works so badly.
> > >> > >
> > >> > > So there are only two options:
> > >> > >
> > >> > > 1) Disallow it and so these users will have non-working wifi.
> > >> > >
> > >> > > 2) Allow those data to be used as fallback mechanism.
> > >> > >
> > >> > > And personally I'm against 1) because it will break wifi support for
> > >> > > *all* Nokia N900 devices right now.
> > >> > 
> > >> > All two of them? :)
> > >> 
> > >> Umm. You clearly want a flock of angry penguins at your doorsteps :-).
> > >
> > > Well this silly issue of symlinking and renaming nvs files in a standard
> > > Linux distro was also hitting me on various devices with wl12xx/wl18xx
> > > trying to use the same rootfs.
> > >
> > > Why don't we just set a custom compatible property for n900 that then
> > > picks up some other nvs file instead of the default?
> > 
> > Please don't. An ugly kernel workaround in kernel because of user space
> > problems is a bad idea. wl1251 should just ask for NVS file from user
> > space, it shouldn't care if it's a "default" file or something else.
> > That's a user space policy decision.
> 
> Grr I keep forgetting it needs to be for each device manufactured so
> yeah that won't work.
> 
> The names of standard distro files are hardcoded into the kernel
> driver so it's also a kernel problem though :p
> 
> How about a custom devices tree property saying "needs-custom-firmware"?

How does it help request_firmware() call which automatically loads
firmware file from VFS (if is available)?

> Something that would prevent anything being loaded until user space
> loads the firmware. It could also be set in the driver automatically
> based on the compatible flag if we always want it enabled. And we could
> have some cmdline option to ignore it. Or the other way around whatever
> makes sense.

So you just want to kernel automatically prevent loading firmware file
(based on flag which driver can set). That is similar approach as mine.

> > Why can't you do something like this:
> > 
> > * rename the NVS file linux-firmware to wl1251-nvs.bin.example
> 
> As that name is hardcoded in the kernel and that file is provided by
> all standard distros, let's assume we just have to deal with that ABI
> forever.

Yes.

> > * before distro updates linux-firmware create yours own deb/rpm/whatever
> >   package "wl1251-firmware" which installs your flavor of nvs file (or
> >   the user fallback helper if more dynamic functionality is preferred)
> 
> And that won't work when using the same file system on other machines.
> 
> Think NFSroot for example. At least I'm using the same NFSroot across
> about 15 different machines including one n900 macro board with smc91x
> Ethernet.

Exactly problem which we already discussed in previous emails. You
cannot serve one file (loaded by direct request_firmware) when your
rootfs is readonly, e.g. comes via NFS shared for more devices...

-- 
Pali Rohár
pali.ro...@gmail.com

pull-request: wireless-drivers-next 2017-02-01

[Kalle Valo]

Hi Dave,

here's a pull request to 4.11, more details in the signed tag below.

I forgot to mention in the tag that this includes one small change to
include/linux/soc/qcom/smem_state.h which was acked by Andy Gross in
commit 6c0b2e833f14. It was needed to fix a build problem with wcn36xx
using the SMD interface.

Please let me know if you have any problems.

Kalle

The following changes since commit a505e58252715bbc18a0ee1abae23615fe2586db:

  packet: pdiag_put_ring() should return TX_RING info for TPACKET_V3 
(2017-01-10 21:02:42 -0500)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
tags/wireless-drivers-next-for-davem-2017-02-01

for you to fetch changes up to 7243a1af37a4dc9225004546d9d0756c529ad3ce:

  Merge ath-next from 
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2017-01-31 
09:50:50 +0200)


wireless-drivers-next patches for 4.11

It's nice to see rt2x00 development has becoming active, for example
adding support for a new chip version. Also wcn36xx has been converted
to use the recently merged QCOM_SMD subsystem. Otherwise new features
and fixes it lots of drivers.

Major changes:

iwlwifi

* some more work in preparation for A000 family support
* add support for radiotap timestamps
* some work on our firmware debugging capabilities

wcn36xx

* convert to a proper QCOM_SMD driver (from the platform_driver interface)

ath10k

* VHT160 support
* dump Copy Engine registers during firmware crash
* search board file extension from SMBIOS

wil6210

* add disable_ap_sme module parameter

rt2x00

* support RT3352 with external PA
* support for RT3352 with 20MHz crystal
* add support for RT5350 WiSoC

brcmfmac

* add support for BCM43455 sdio device

rtl8xxxu

* add support for D-Link DWA-131 rev E1, TP-Link TL-WN822N v4 and others


Amitkumar Karwar (3):
  mwifiex: use module_*_driver helper macros
  mwifiex: mwifiex_unmap_pci_memory() handling for sleep confirm
  mwifiex: use pci_dma_sync_single* APIs

Arend Van Spriel (4):
  brcmfmac: provide a value for struct wowlan_support::max_nd_match_sets
  brcmfmac: fix handling firmware results for wowl netdetect
  brcmfmac: allow wowlan support to be per device
  brcmfmac: add .update_connect_params() callback

Arnd Bergmann (1):
  mwifiex: fix uninitialized variable access in pcie_remove

Axel Köllhofer (2):
  rtl8xxxu: Add USB ID for D-Link DWA-131 rev E1 (rtl8192eu)
  rtl8xxxu: Add additional USB IDs for rtl8192eu devices

Bhumika Goyal (1):
  wil6210: constify cfg80211_ops structures

Bjorn Andersson (5):
  soc: qcom: smem_state: Fix include for ERR_PTR()
  wcn36xx: Transition driver to SMD client
  wcn36xx: Implement firmware assisted scan
  wcn36xx: Implement print_reg indication
  wcn36xx: Don't use the destroyed hal_mutex

Brian Norris (5):
  mwifiex: debugfs: Fix (sometimes) off-by-1 SSID print
  mwifiex: pcie: use posted write to wake up firmware
  mwifiex: pcie: don't loop/retry interrupt status checks
  mwifiex: pcie: read FROMDEVICE DMA-able memory with READ_ONCE()
  mwifiex: don't complain about 'unknown event id: 0x63'

Christian Lamparter (2):
  ath10k: add accounting for the extended peer statistics
  ath9k: move RELAY and DEBUG_FS to ATH9K[_HTC]_DEBUGFS

Colin Ian King (1):
  ath9k: fix spelling mistake: "meaurement" -> "measurement"

Daniel Golle (2):
  rt2x00: rt2800lib: support for for RT3352 with external PA
  rt2x00: rt2800lib: add support for RT3352 with 20MHz crystal

Dedy Lansky (2):
  wil6210: add disable_ap_sme module parameter
  wil6210: support new WMI-only FW capability

Erik Stromdahl (2):
  ath10k: htc: removal of unused struct members
  ath10k: htc: simplified credit distribution

Felix Fietkau (2):
  ath5k: drop bogus warning on drv_set_key with unsupported cipher
  rt2x00: rt2800lib: fix rf id for RT3352

Ganapathi Bhat (1):
  mwifiex: move pcie_work and related variables inside card

Gavin Li (1):
  brcmfmac: fix incorrect event channel deduction

Guy Mishol (1):
  wlcore: print the sdio buffer after reading it

Hamad Kadmany (1):
  wil6210: protect against false interrupt during reset sequence

Jes Sorensen (3):
  rtl8xxxu: Mark 8192eu device 0x0bda:0x818b as tested
  rtl8xxxu: Add another 8192eu device to the USB list
  rtl8xxxu: Update author/maintainer contact info

Johannes Berg (5):
  iwlwifi: mvm: expose device timestamp in radiotap
  iwlwifi: mvm: accept arbitrary memory dump TLVs
  iwlwifi: mvm: make iwl_dump_prph() void
  iwlwifi: allow memory debug TLV to specify the memory type
  iwlwifi: mvm: properly check for transport data in dump

Jürg Billeter (1):
  iwlwifi: fix MODULE_FIRMWARE for 6030

Kalle Valo (3):
  

Re: [PATCH 4.10-rc3 03/13] net: macb: fix build errors when linux/phy*.h is removed from net/dsa.h

[Nicolas Ferre]

Le 31/01/2017 à 20:18, Russell King a écrit :
> drivers/net/ethernet/cadence/macb.h:862:33: sparse: expected ; at end of 
> declaration
> drivers/net/ethernet/cadence/macb.h:862:33: sparse: Expected } at end of 
> struct-union-enum-specifier
> drivers/net/ethernet/cadence/macb.h:862:33: sparse: got phy_interface
> drivers/net/ethernet/cadence/macb.h:877:1: sparse: Expected ; at the end of 
> type declaration
> drivers/net/ethernet/cadence/macb.h:877:1: sparse: got }
> In file included from drivers/net/ethernet/cadence/macb_pci.c:29:0:
> drivers/net/ethernet/cadence/macb.h:862:2: error: unknown type name 
> 'phy_interface_t'
>  phy_interface_t  phy_interface;
>  ^~~
> 
> Add linux/phy.h to macb.h
> 
> Signed-off-by: Russell King 

Acked-by: Nicolas Ferre 

> ---
>  drivers/net/ethernet/cadence/macb.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/net/ethernet/cadence/macb.h 
> b/drivers/net/ethernet/cadence/macb.h
> index d67adad67be1..383da8cf5f6d 100644
> --- a/drivers/net/ethernet/cadence/macb.h
> +++ b/drivers/net/ethernet/cadence/macb.h
> @@ -10,6 +10,8 @@
>  #ifndef _MACB_H
>  #define _MACB_H
>  
> +#include 
> +
>  #define MACB_GREGS_NBR 16
>  #define MACB_GREGS_VERSION 2
>  #define MACB_MAX_QUEUES 8
> 


-- 
Nicolas Ferre

Re: [PATCH net-next] net: phy: Add LED mode driver for Microsemi PHYs.

[Raju Lakkaraju]

Hi Andrew,

Thank you for review and valuable comments.

On Tue, Jan 31, 2017 at 02:30:09PM +0100, Andrew Lunn wrote:
> EXTERNAL EMAIL
> 
> 
> On Tue, Jan 31, 2017 at 11:16:01AM +0530, Raju Lakkaraju wrote:
> > From: Raju Lakkaraju 
> >
> > LED Mode:
> > Microsemi PHY support 2 LEDs (LED[0] and LED[1]) to display different
> > status information that can be selected by setting LED mode.
> >
> > LED Mode parameter (vddmac, led-0-mode) and (vddmac, led-1-mode) get
> > from Device Tree.
> 
> Hi Raju
> 
> How is vddmac an LED mode parameter?
> 

Typo. I will correct.
It should be "vsc8531, led-0-mode".

> > Signed-off-by: Raju Lakkaraju 
> > ---
> >  .../devicetree/bindings/net/mscc-phy-vsc8531.txt   | 39 
> >  drivers/net/phy/mscc.c | 72 
> > ++
> >  2 files changed, 111 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt 
> > b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
> > index bdefefc6..1abf4b6 100644
> > --- a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
> > +++ b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
> > @@ -27,6 +27,12 @@ Optional properties:
> > 'vddmac'.
> > Default value is 0%.
> > Ref: Table:1 - Edge rate change (below).
> > +- vsc8531,led-0-mode : LED mode. Specify how the LED[0] should behave.
> > +   Allowed values is listed in the 'PHY LED Mode' -
> > +   Table 2 (below).  Default value is 1.
> > +- vsc8531,led-1-mode : LED mode. Specify how the LED[1] should behave.
> > +   Allowed values is listed in the 'PHY LED Mode' -
> > +   Table 2 (below).  Default value is 2.
> >
> >  Table: 1 - Edge rate change
> >  |
> > @@ -54,10 +60,43 @@ Table: 1 - Edge rate change
> >  | (slowest)  |
> >  |---|
> >
> > +Table: 2 - PHY LED Mode
> > +|---|
> > +| LINK_ACTIVITY  | 0 |
> > +|---|
> > +| LINK_1000_ACTIVITY | 1 |
> > +|---|
> > +| LINK_100_ACTIVITY  | 2 |
> > +|---|
> > +| LINK_10_ACTIVITY   | 3 |
> > +|---|
> > +| LINK_100_1000_ACTIVITY | 4 |
> > +|---|
> > +| LINK_10_1000_ACTIVITY  | 5 |
> > +|---|
> > +| LINK_10_100_ACTIVITY   | 6 |
> > +|---|
> > +| DUPLEX_COLLISION   | 8 |
> > +|---|
> > +| COLLISION  | 9 |
> > +|---|
> > +| ACTIVITY   | 10|
> > +|---|
> > +| AUTONEG_FAULT  | 12|
> > +|---|
> > +| SERIAL_MODE| 13|
> > +|---|
> > +| FORCE_LED_OFF  | 14|
> > +|---|
> > +| FORCE_LED_ON   | 15|
> > +|---|
> > +
> >  Example:
> >
> >  vsc8531_0: ethernet-phy@0 {
> >  compatible = "ethernet-phy-id0007.0570";
> >  vsc8531,vddmac   = <3300>;
> >  vsc8531,edge-slowdown= <7>;
> > +vsc8531,led-0-mode   = <1>;
> > +vsc8531,led-1-mode   = <2>;
> 
> Numbers like this are pretty unreadable. I would suggest adding a header file 
> in
> include/dt-bindings/net/
> 

Accpeted. I will create new header file for DT Macros.

> > +static int vsc85xx_led_cntl_set(struct phy_device *phydev,
> > + u8 led_num,
> > + u8 mode)
> > +{
> > + int rc;
> > + u16 reg_val;
> > +
> > + mutex_lock(>lock);
> > + reg_val = phy_read(phydev, MSCC_PHY_LED_MODE_SEL);
> > + if (led_num) {
> > + reg_val &= ~LED_1_MODE_SEL_MASK;
> > + reg_val |= (((u16)mode << LED_1_MODE_SEL_POS) &
> > + LED_1_MODE_SEL_MASK);
> > + } else {
> > + reg_val |= ((u16)mode & LED_0_MODE_SEL_MASK);
> > + }
> 
> The asymmetry here makes me think this is wrong.
> 

Yes. You are correct.
I 

Re: [PATCH 4.10-rc3 07/13] net: mvneta: fix build errors when linux/phy*.h is removed from net/dsa.h

[Thomas Petazzoni]

Hello,

On Tue, 31 Jan 2017 19:18:59 +, Russell King wrote:
> drivers/net/ethernet/marvell/mvneta.c:2694:26: error: storage size of 
> 'status' isn't known
> drivers/net/ethernet/marvell/mvneta.c:2695:26: error: storage size of 
> 'changed' isn't known
> drivers/net/ethernet/marvell/mvneta.c:2695:9: error: variable 'changed' has 
> initializer but incomplete type
> drivers/net/ethernet/marvell/mvneta.c:2709:2: error: implicit declaration of 
> function 'fixed_phy_update_state' [-Werror=implicit-function-declaration]
> 
> Add linux/phy_fixed.h to mvneta.c
> 
> Signed-off-by: Russell King 

Acked-by: Thomas Petazzoni 
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

routing policy based on u32 classifier

[pupi...@libero.it]

Hello everyone,

Kindly I would like to ask if there is a way to do routing
policy based on u32 classifier without fwmark/netfilter.
I have read doc/tc-filters and doc/actions/actions-general
from iproute2-4.9.0 package but I am not able to find any
actions doing this kind of job: the only way is to mark
packets with netfilter.

Any response are welcome

TIA

Marco

pull request (net-next): ipsec-next 2017-02-01

[Steffen Klassert]

1) Some typo fixes, from Alexander Alemayhu.

2) Don't acquire state lock in get_mtu functions.
   The only rece against a dead state does not matter.
   From Florian Westphal.

3) Remove xfrm4_state_fini, it is unused for more than
   10 years. From Florian Westphal.

4) Various rcu usage improvements. From Florian Westphal.

5) Properly handle crypto arrors in ah4/ah6.
   From Gilad Ben-Yossef.

6) Try to avoid skb linearization in esp4 and esp6.

7) The esp trailer is now set up in different places,
   add a helper for this.

8) With the upcomming usage of gro_cells in IPsec,
   a gro merged skb can have a secpath. Drop it
   before freeing or reusing the skb.

9) Add a xfrm dummy network device for napi. With
   this we can use gro_cells from within xfrm,
   it allows IPsec GRO without impact on the generic
   networking code.

Please pull or let me know if there are problems.

Thanks!

The following changes since commit 0a0a8d6b0e88d947d7ab3198b325e31f677bebc2:

  net: fealnx: use new api ethtool_{get|set}_link_ksettings (2017-01-02 
16:59:10 -0500)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git master

for you to fetch changes up to 1995876a06bcf6f9f7d7b699bdbf387831679771:

  xfrm: Add a dummy network device for napi. (2017-01-30 06:45:43 +0100)


Alexander Alemayhu (1):
  xfrm: trivial typos

Florian Westphal (7):
  xfrm: state: do not acquire lock in get_mtu helpers
  xfrm: remove unused function
  xfrm: avoid rcu sparse warning
  xfrm: remove xfrm_state_put_afinfo
  xfrm: add and use xfrm_state_afinfo_get_rcu
  xfrm: state: simplify rcu_read_unlock handling in two spots
  xfrm: fix possible null deref in xfrm_init_tempstate

Gilad Ben-Yossef (2):
  IPsec: do not ignore crypto err in ah4 input
  IPsec: do not ignore crypto err in ah6 input

Steffen Klassert (5):
  esp4: Avoid skb_cow_data whenever possible
  esp6: Avoid skb_cow_data whenever possible
  esp: Introduce a helper to setup the trailer
  net: Drop secpath on free after gro merge.
  xfrm: Add a dummy network device for napi.

 include/net/xfrm.h |   4 +-
 net/core/dev.c |   2 +
 net/ipv4/ah4.c |   3 +
 net/ipv4/esp4.c| 332 ++---
 net/ipv4/xfrm4_state.c |   8 --
 net/ipv6/ah6.c |   3 +
 net/ipv6/esp6.c| 318 --
 net/xfrm/xfrm_input.c  |  12 +-
 net/xfrm/xfrm_output.c |   8 +-
 net/xfrm/xfrm_policy.c |   2 +-
 net/xfrm/xfrm_state.c  |  86 ++---
 11 files changed, 578 insertions(+), 200 deletions(-)

[PATCH 04/15] xfrm: avoid rcu sparse warning

[Steffen Klassert]

From: Florian Westphal 

xfrm/xfrm_state.c:1973:21: error: incompatible types in comparison expression 
(different address spaces)

Harmless, but lets fix it to reduce the noise.

While at it, get rid of unneeded NULL check, its never hit:

net/ipv4/xfrm4_state.c: xfrm_state_register_afinfo(_state_afinfo);
net/ipv6/xfrm6_state.c: return xfrm_state_register_afinfo(_state_afinfo);
net/ipv6/xfrm6_state.c: xfrm_state_unregister_afinfo(_state_afinfo);

... are the only callsites.

Signed-off-by: Florian Westphal 
Signed-off-by: Steffen Klassert 
---
 net/xfrm/xfrm_state.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 6b3366f..57e9578 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -1932,10 +1932,10 @@ int xfrm_unregister_km(struct xfrm_mgr *km)
 int xfrm_state_register_afinfo(struct xfrm_state_afinfo *afinfo)
 {
int err = 0;
-   if (unlikely(afinfo == NULL))
-   return -EINVAL;
-   if (unlikely(afinfo->family >= NPROTO))
+
+   if (WARN_ON(afinfo->family >= NPROTO))
return -EAFNOSUPPORT;
+
spin_lock_bh(_state_afinfo_lock);
if (unlikely(xfrm_state_afinfo[afinfo->family] != NULL))
err = -EEXIST;
@@ -1948,14 +1948,14 @@ int xfrm_state_register_afinfo(struct xfrm_state_afinfo 
*afinfo)
 
 int xfrm_state_unregister_afinfo(struct xfrm_state_afinfo *afinfo)
 {
-   int err = 0;
-   if (unlikely(afinfo == NULL))
-   return -EINVAL;
-   if (unlikely(afinfo->family >= NPROTO))
+   int err = 0, family = afinfo->family;
+
+   if (WARN_ON(family >= NPROTO))
return -EAFNOSUPPORT;
+
spin_lock_bh(_state_afinfo_lock);
if (likely(xfrm_state_afinfo[afinfo->family] != NULL)) {
-   if (unlikely(xfrm_state_afinfo[afinfo->family] != afinfo))
+   if (rcu_access_pointer(xfrm_state_afinfo[family]) != afinfo)
err = -EINVAL;
else
RCU_INIT_POINTER(xfrm_state_afinfo[afinfo->family], 
NULL);
-- 
1.9.1

[PATCH 11/15] esp4: Avoid skb_cow_data whenever possible

[Steffen Klassert]

This patch tries to avoid skb_cow_data on esp4.

On the encrypt side we add the IPsec tailbits
to the linear part of the buffer if there is
space on it. If there is no space on the linear
part, we add a page fragment with the tailbits to
the buffer and use separate src and dst scatterlists.

On the decrypt side, we leave the buffer as it is
if it is not cloned.

With this, we can avoid a linearization of the buffer
in most of the cases.

Joint work with:
Sowmini Varadhan 
Ilan Tayari 

Signed-off-by: Sowmini Varadhan 
Signed-off-by: Ilan Tayari 
Signed-off-by: Steffen Klassert 
---
 include/net/xfrm.h |   2 +
 net/ipv4/esp4.c| 338 +
 2 files changed, 266 insertions(+), 74 deletions(-)

diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index c52197c..d9a81dc 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -213,6 +213,8 @@ struct xfrm_state {
/* Last used time */
unsigned long   lastused;
 
+   struct page_frag xfrag;
+
/* Reference to data common to all the instances of this
 * transformer. */
const struct xfrm_type  *type;
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index 20fb25e..9e8d971 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -18,6 +18,8 @@
 #include 
 #include 
 
+#include 
+
 struct esp_skb_cb {
struct xfrm_skb_cb xfrm;
void *tmp;
@@ -92,11 +94,40 @@ static inline struct scatterlist *esp_req_sg(struct 
crypto_aead *aead,
 __alignof__(struct scatterlist));
 }
 
+static void esp_ssg_unref(struct xfrm_state *x, void *tmp)
+{
+   struct esp_output_extra *extra = esp_tmp_extra(tmp);
+   struct crypto_aead *aead = x->data;
+   int extralen = 0;
+   u8 *iv;
+   struct aead_request *req;
+   struct scatterlist *sg;
+
+   if (x->props.flags & XFRM_STATE_ESN)
+   extralen += sizeof(*extra);
+
+   extra = esp_tmp_extra(tmp);
+   iv = esp_tmp_iv(aead, tmp, extralen);
+   req = esp_tmp_req(aead, iv);
+
+   /* Unref skb_frag_pages in the src scatterlist if necessary.
+* Skip the first sg which comes from skb->data.
+*/
+   if (req->src != req->dst)
+   for (sg = sg_next(req->src); sg; sg = sg_next(sg))
+   put_page(sg_page(sg));
+}
+
 static void esp_output_done(struct crypto_async_request *base, int err)
 {
struct sk_buff *skb = base->data;
+   void *tmp;
+   struct dst_entry *dst = skb_dst(skb);
+   struct xfrm_state *x = dst->xfrm;
 
-   kfree(ESP_SKB_CB(skb)->tmp);
+   tmp = ESP_SKB_CB(skb)->tmp;
+   esp_ssg_unref(x, tmp);
+   kfree(tmp);
xfrm_output_resume(skb, err);
 }
 
@@ -120,6 +151,29 @@ static void esp_output_restore_header(struct sk_buff *skb)
sizeof(__be32));
 }
 
+static struct ip_esp_hdr *esp_output_set_extra(struct sk_buff *skb,
+  struct ip_esp_hdr *esph,
+  struct esp_output_extra *extra)
+{
+   struct xfrm_state *x = skb_dst(skb)->xfrm;
+
+   /* For ESN we move the header forward by 4 bytes to
+* accomodate the high bits.  We will move it back after
+* encryption.
+*/
+   if ((x->props.flags & XFRM_STATE_ESN)) {
+   extra->esphoff = (unsigned char *)esph -
+skb_transport_header(skb);
+   esph = (struct ip_esp_hdr *)((unsigned char *)esph - 4);
+   extra->seqhi = esph->spi;
+   esph->seq_no = htonl(XFRM_SKB_CB(skb)->seq.output.hi);
+   }
+
+   esph->spi = x->id.spi;
+
+   return esph;
+}
+
 static void esp_output_done_esn(struct crypto_async_request *base, int err)
 {
struct sk_buff *skb = base->data;
@@ -130,16 +184,18 @@ static void esp_output_done_esn(struct 
crypto_async_request *base, int err)
 
 static int esp_output(struct xfrm_state *x, struct sk_buff *skb)
 {
-   int err;
struct esp_output_extra *extra;
+   int err = -ENOMEM;
struct ip_esp_hdr *esph;
struct crypto_aead *aead;
struct aead_request *req;
-   struct scatterlist *sg;
+   struct scatterlist *sg, *dsg;
struct sk_buff *trailer;
+   struct page *page;
void *tmp;
u8 *iv;
u8 *tail;
+   u8 *vaddr;
int blksize;
int clen;
int alen;
@@ -149,7 +205,9 @@ static int esp_output(struct xfrm_state *x, struct sk_buff 
*skb)
int nfrags;
int assoclen;
int extralen;
+   int tailen;
__be64 seqno;
+   __u8 proto = *skb_mac_header(skb);
 
/* skb is pure payload to encrypt */
 
@@ -169,12 +227,7 @@ static int esp_output(struct xfrm_state *x, struct sk_buff 
*skb)
blksize = 

[PATCH 06/15] xfrm: add and use xfrm_state_afinfo_get_rcu

[Steffen Klassert]

From: Florian Westphal 

xfrm_init_tempstate is always called from within rcu read side section.
We can thus use a simpler function that doesn't call rcu_read_lock
again.

While at it, also make xfrm_init_tempstate return value void, the
return value was never tested.

A followup patch will replace remaining callers of xfrm_state_get_afinfo
with xfrm_state_afinfo_get_rcu variant and then remove the 'old'
get_afinfo interface.

Signed-off-by: Florian Westphal 
Signed-off-by: Steffen Klassert 
---
 include/net/xfrm.h|  1 +
 net/xfrm/xfrm_state.c | 25 +++--
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 957d0cc..c52197c 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -343,6 +343,7 @@ struct xfrm_state_afinfo {
 int xfrm_state_register_afinfo(struct xfrm_state_afinfo *afinfo);
 int xfrm_state_unregister_afinfo(struct xfrm_state_afinfo *afinfo);
 struct xfrm_state_afinfo *xfrm_state_get_afinfo(unsigned int family);
+struct xfrm_state_afinfo *xfrm_state_afinfo_get_rcu(unsigned int family);
 
 struct xfrm_input_afinfo {
unsigned intfamily;
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 7830844..b5dad89 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -639,26 +639,23 @@ void xfrm_sad_getinfo(struct net *net, struct 
xfrmk_sadinfo *si)
 }
 EXPORT_SYMBOL(xfrm_sad_getinfo);
 
-static int
+static void
 xfrm_init_tempstate(struct xfrm_state *x, const struct flowi *fl,
const struct xfrm_tmpl *tmpl,
const xfrm_address_t *daddr, const xfrm_address_t *saddr,
unsigned short family)
 {
-   struct xfrm_state_afinfo *afinfo = xfrm_state_get_afinfo(family);
-   if (!afinfo)
-   return -1;
-   afinfo->init_tempsel(>sel, fl);
+   struct xfrm_state_afinfo *afinfo = xfrm_state_afinfo_get_rcu(family);
+
+   if (afinfo)
+   afinfo->init_tempsel(>sel, fl);
 
if (family != tmpl->encap_family) {
-   rcu_read_unlock();
-   afinfo = xfrm_state_get_afinfo(tmpl->encap_family);
+   afinfo = xfrm_state_afinfo_get_rcu(tmpl->encap_family);
if (!afinfo)
-   return -1;
+   return;
}
afinfo->init_temprop(x, tmpl, daddr, saddr);
-   rcu_read_unlock();
-   return 0;
 }
 
 static struct xfrm_state *__xfrm_state_lookup(struct net *net, u32 mark,
@@ -1966,6 +1963,14 @@ int xfrm_state_unregister_afinfo(struct 
xfrm_state_afinfo *afinfo)
 }
 EXPORT_SYMBOL(xfrm_state_unregister_afinfo);
 
+struct xfrm_state_afinfo *xfrm_state_afinfo_get_rcu(unsigned int family)
+{
+   if (unlikely(family >= NPROTO))
+   return NULL;
+
+   return rcu_dereference(xfrm_state_afinfo[family]);
+}
+
 struct xfrm_state_afinfo *xfrm_state_get_afinfo(unsigned int family)
 {
struct xfrm_state_afinfo *afinfo;
-- 
1.9.1

[PATCH 01/15] xfrm: trivial typos

[Steffen Klassert]

From: Alexander Alemayhu 

o s/descentant/descendant
o s/workarbound/workaround

Signed-off-by: Alexander Alemayhu 
Signed-off-by: Steffen Klassert 
---
 net/xfrm/xfrm_policy.c | 2 +-
 net/xfrm/xfrm_state.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 177e208..99ad1af2 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -330,7 +330,7 @@ void xfrm_policy_destroy(struct xfrm_policy *policy)
 }
 EXPORT_SYMBOL(xfrm_policy_destroy);
 
-/* Rule must be locked. Release descentant resources, announce
+/* Rule must be locked. Release descendant resources, announce
  * entry dead. The rule must be unlinked from lists to the moment.
  */
 
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 64e3c82..c5cf4d6 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -409,7 +409,7 @@ static enum hrtimer_restart xfrm_timer_handler(struct 
hrtimer *me)
if (x->xflags & XFRM_SOFT_EXPIRE) {
/* enter hard expire without soft expire first?!
 * setting a new date could trigger this.
-* workarbound: fix x->curflt.add_time by below:
+* workaround: fix x->curflt.add_time by below:
 */
x->curlft.add_time = now - x->saved_tmo - 1;
tmo = x->lft.hard_add_expires_seconds - 
x->saved_tmo;
-- 
1.9.1

[PATCH 05/15] xfrm: remove xfrm_state_put_afinfo

[Steffen Klassert]

From: Florian Westphal 

commit 44abdc3047aecafc141dfbaf1ed
("xfrm: replace rwlock on xfrm_state_afinfo with rcu") made
xfrm_state_put_afinfo equivalent to rcu_read_unlock.

Use spatch to replace it with direct calls to rcu_read_unlock:

@@
struct xfrm_state_afinfo *a;
@@

-  xfrm_state_put_afinfo(a);
+  rcu_read_unlock();

old:
 textdata bss dec hex filename
22570  72 424   230665a1a xfrm_state.o
 1612   0   01612 64c xfrm_output.o
new:
22554  72 424   230505a0a xfrm_state.o
 1596   0   01596 63c xfrm_output.o

Signed-off-by: Florian Westphal 
Signed-off-by: Steffen Klassert 
---
 include/net/xfrm.h |  1 -
 net/xfrm/xfrm_output.c |  8 +++-
 net/xfrm/xfrm_state.c  | 31 +--
 3 files changed, 16 insertions(+), 24 deletions(-)

diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 31947b9..957d0cc 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -343,7 +343,6 @@ struct xfrm_state_afinfo {
 int xfrm_state_register_afinfo(struct xfrm_state_afinfo *afinfo);
 int xfrm_state_unregister_afinfo(struct xfrm_state_afinfo *afinfo);
 struct xfrm_state_afinfo *xfrm_state_get_afinfo(unsigned int family);
-void xfrm_state_put_afinfo(struct xfrm_state_afinfo *afinfo);
 
 struct xfrm_input_afinfo {
unsigned intfamily;
diff --git a/net/xfrm/xfrm_output.c b/net/xfrm/xfrm_output.c
index 637387b..8ba29fe 100644
--- a/net/xfrm/xfrm_output.c
+++ b/net/xfrm/xfrm_output.c
@@ -246,10 +246,8 @@ void xfrm_local_error(struct sk_buff *skb, int mtu)
return;
 
afinfo = xfrm_state_get_afinfo(proto);
-   if (!afinfo)
-   return;
-
-   afinfo->local_error(skb, mtu);
-   xfrm_state_put_afinfo(afinfo);
+   if (afinfo)
+   afinfo->local_error(skb, mtu);
+   rcu_read_unlock();
 }
 EXPORT_SYMBOL_GPL(xfrm_local_error);
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 57e9578..7830844 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -192,7 +192,7 @@ int xfrm_register_type(const struct xfrm_type *type, 
unsigned short family)
else
err = -EEXIST;
spin_unlock_bh(_type_lock);
-   xfrm_state_put_afinfo(afinfo);
+   rcu_read_unlock();
return err;
 }
 EXPORT_SYMBOL(xfrm_register_type);
@@ -213,7 +213,7 @@ int xfrm_unregister_type(const struct xfrm_type *type, 
unsigned short family)
else
typemap[type->proto] = NULL;
spin_unlock_bh(_type_lock);
-   xfrm_state_put_afinfo(afinfo);
+   rcu_read_unlock();
return err;
 }
 EXPORT_SYMBOL(xfrm_unregister_type);
@@ -235,13 +235,13 @@ static const struct xfrm_type *xfrm_get_type(u8 proto, 
unsigned short family)
if (unlikely(type && !try_module_get(type->owner)))
type = NULL;
if (!type && !modload_attempted) {
-   xfrm_state_put_afinfo(afinfo);
+   rcu_read_unlock();
request_module("xfrm-type-%d-%d", family, proto);
modload_attempted = 1;
goto retry;
}
 
-   xfrm_state_put_afinfo(afinfo);
+   rcu_read_unlock();
return type;
 }
 
@@ -280,7 +280,7 @@ int xfrm_register_mode(struct xfrm_mode *mode, int family)
 
 out:
spin_unlock_bh(_mode_lock);
-   xfrm_state_put_afinfo(afinfo);
+   rcu_read_unlock();
return err;
 }
 EXPORT_SYMBOL(xfrm_register_mode);
@@ -308,7 +308,7 @@ int xfrm_unregister_mode(struct xfrm_mode *mode, int family)
}
 
spin_unlock_bh(_mode_lock);
-   xfrm_state_put_afinfo(afinfo);
+   rcu_read_unlock();
return err;
 }
 EXPORT_SYMBOL(xfrm_unregister_mode);
@@ -331,13 +331,13 @@ static struct xfrm_mode *xfrm_get_mode(unsigned int 
encap, int family)
if (unlikely(mode && !try_module_get(mode->owner)))
mode = NULL;
if (!mode && !modload_attempted) {
-   xfrm_state_put_afinfo(afinfo);
+   rcu_read_unlock();
request_module("xfrm-mode-%d-%d", family, encap);
modload_attempted = 1;
goto retry;
}
 
-   xfrm_state_put_afinfo(afinfo);
+   rcu_read_unlock();
return mode;
 }
 
@@ -651,13 +651,13 @@ void xfrm_sad_getinfo(struct net *net, struct 
xfrmk_sadinfo *si)
afinfo->init_tempsel(>sel, fl);
 
if (family != tmpl->encap_family) {
-   xfrm_state_put_afinfo(afinfo);
+   rcu_read_unlock();
afinfo = xfrm_state_get_afinfo(tmpl->encap_family);
if (!afinfo)
return -1;
}
afinfo->init_temprop(x, tmpl, daddr, saddr);
-   xfrm_state_put_afinfo(afinfo);
+   rcu_read_unlock();
return 0;
 }
 
@@ -1474,7 +1474,7 @@ struct xfrm_state *
if (afinfo->tmpl_sort)
err = 

[PATCH 12/15] esp6: Avoid skb_cow_data whenever possible

[Steffen Klassert]

This patch tries to avoid skb_cow_data on esp6.

On the encrypt side we add the IPsec tailbits
to the linear part of the buffer if there is
space on it. If there is no space on the linear
part, we add a page fragment with the tailbits to
the buffer and use separate src and dst scatterlists.

On the decrypt side, we leave the buffer as it is
if it is not cloned.

With this, we can avoid a linearization of the buffer
in most of the cases.

Joint work with:
Sowmini Varadhan 
Ilan Tayari 

Signed-off-by: Sowmini Varadhan 
Signed-off-by: Ilan Tayari 
Signed-off-by: Steffen Klassert 
---
 net/ipv6/esp6.c | 302 +---
 1 file changed, 246 insertions(+), 56 deletions(-)

diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
index cbcdd5d..a428ac6 100644
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@ -44,6 +44,8 @@
 #include 
 #include 
 
+#include 
+
 struct esp_skb_cb {
struct xfrm_skb_cb xfrm;
void *tmp;
@@ -114,11 +116,40 @@ static inline struct scatterlist *esp_req_sg(struct 
crypto_aead *aead,
 __alignof__(struct scatterlist));
 }
 
+static void esp_ssg_unref(struct xfrm_state *x, void *tmp)
+{
+   __be32 *seqhi;
+   struct crypto_aead *aead = x->data;
+   int seqhilen = 0;
+   u8 *iv;
+   struct aead_request *req;
+   struct scatterlist *sg;
+
+   if (x->props.flags & XFRM_STATE_ESN)
+   seqhilen += sizeof(__be32);
+
+   seqhi = esp_tmp_seqhi(tmp);
+   iv = esp_tmp_iv(aead, tmp, seqhilen);
+   req = esp_tmp_req(aead, iv);
+
+   /* Unref skb_frag_pages in the src scatterlist if necessary.
+* Skip the first sg which comes from skb->data.
+*/
+   if (req->src != req->dst)
+   for (sg = sg_next(req->src); sg; sg = sg_next(sg))
+   put_page(sg_page(sg));
+}
+
 static void esp_output_done(struct crypto_async_request *base, int err)
 {
struct sk_buff *skb = base->data;
+   void *tmp;
+   struct dst_entry *dst = skb_dst(skb);
+   struct xfrm_state *x = dst->xfrm;
 
-   kfree(ESP_SKB_CB(skb)->tmp);
+   tmp = ESP_SKB_CB(skb)->tmp;
+   esp_ssg_unref(x, tmp);
+   kfree(tmp);
xfrm_output_resume(skb, err);
 }
 
@@ -138,6 +169,27 @@ static void esp_output_restore_header(struct sk_buff *skb)
esp_restore_header(skb, skb_transport_offset(skb) - sizeof(__be32));
 }
 
+static struct ip_esp_hdr *esp_output_set_esn(struct sk_buff *skb,
+struct ip_esp_hdr *esph,
+__be32 *seqhi)
+{
+   struct xfrm_state *x = skb_dst(skb)->xfrm;
+
+   /* For ESN we move the header forward by 4 bytes to
+* accomodate the high bits.  We will move it back after
+* encryption.
+*/
+   if ((x->props.flags & XFRM_STATE_ESN)) {
+   esph = (void *)(skb_transport_header(skb) - sizeof(__be32));
+   *seqhi = esph->spi;
+   esph->seq_no = htonl(XFRM_SKB_CB(skb)->seq.output.hi);
+   }
+
+   esph->spi = x->id.spi;
+
+   return esph;
+}
+
 static void esp_output_done_esn(struct crypto_async_request *base, int err)
 {
struct sk_buff *skb = base->data;
@@ -152,8 +204,9 @@ static int esp6_output(struct xfrm_state *x, struct sk_buff 
*skb)
struct ip_esp_hdr *esph;
struct crypto_aead *aead;
struct aead_request *req;
-   struct scatterlist *sg;
+   struct scatterlist *sg, *dsg;
struct sk_buff *trailer;
+   struct page *page;
void *tmp;
int blksize;
int clen;
@@ -164,10 +217,13 @@ static int esp6_output(struct xfrm_state *x, struct 
sk_buff *skb)
int nfrags;
int assoclen;
int seqhilen;
+   int tailen;
u8 *iv;
u8 *tail;
+   u8 *vaddr;
__be32 *seqhi;
__be64 seqno;
+   __u8 proto = *skb_mac_header(skb);
 
/* skb is pure payload to encrypt */
aead = x->data;
@@ -186,11 +242,7 @@ static int esp6_output(struct xfrm_state *x, struct 
sk_buff *skb)
blksize = ALIGN(crypto_aead_blocksize(aead), 4);
clen = ALIGN(skb->len + 2 + tfclen, blksize);
plen = clen - skb->len - tfclen;
-
-   err = skb_cow_data(skb, tfclen + plen + alen, );
-   if (err < 0)
-   goto error;
-   nfrags = err;
+   tailen = tfclen + plen + alen;
 
assoclen = sizeof(*esph);
seqhilen = 0;
@@ -200,19 +252,130 @@ static int esp6_output(struct xfrm_state *x, struct 
sk_buff *skb)
assoclen += seqhilen;
}
 
-   tmp = esp_alloc_tmp(aead, nfrags, seqhilen);
-   if (!tmp) {
-   err = -ENOMEM;
-   goto error;
+   *skb_mac_header(skb) = IPPROTO_ESP;
+   esph = ip_esp_hdr(skb);
+
+   if 

[PATCH 09/15] IPsec: do not ignore crypto err in ah4 input

[Steffen Klassert]

From: Gilad Ben-Yossef 

ah4 input processing uses the asynchronous hash crypto API which
supplies an error code as part of the operation completion but
the error code was being ignored.

Treat a crypto API error indication as a verification failure.

While a crypto API reported error would almost certainly result
in a memcpy of the digest failing anyway and thus the security
risk seems minor, performing a memory compare on what might be
uninitialized memory is wrong.

Signed-off-by: Gilad Ben-Yossef 
Signed-off-by: Steffen Klassert 
---
 net/ipv4/ah4.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/ipv4/ah4.c b/net/ipv4/ah4.c
index f2a7102..22377c8 100644
--- a/net/ipv4/ah4.c
+++ b/net/ipv4/ah4.c
@@ -270,6 +270,9 @@ static void ah_input_done(struct crypto_async_request 
*base, int err)
int ihl = ip_hdrlen(skb);
int ah_hlen = (ah->hdrlen + 2) << 2;
 
+   if (err)
+   goto out;
+
work_iph = AH_SKB_CB(skb)->tmp;
auth_data = ah_tmp_auth(work_iph, ihl);
icv = ah_tmp_icv(ahp->ahash, auth_data, ahp->icv_trunc_len);
-- 
1.9.1

[PATCH 07/15] xfrm: state: simplify rcu_read_unlock handling in two spots

[Steffen Klassert]

From: Florian Westphal 

Instead of:
  if (foo) {
  unlock();
  return bar();
   }
   unlock();
do:
   unlock();
   if (foo)
   return bar();

This is ok because rcu protected structure is only dereferenced before
the conditional.

Signed-off-by: Florian Westphal 
Signed-off-by: Steffen Klassert 
---
 net/xfrm/xfrm_state.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index b5dad89..a62097e 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -231,17 +231,18 @@ static const struct xfrm_type *xfrm_get_type(u8 proto, 
unsigned short family)
return NULL;
typemap = afinfo->type_map;
 
-   type = typemap[proto];
+   type = READ_ONCE(typemap[proto]);
if (unlikely(type && !try_module_get(type->owner)))
type = NULL;
+
+   rcu_read_unlock();
+
if (!type && !modload_attempted) {
-   rcu_read_unlock();
request_module("xfrm-type-%d-%d", family, proto);
modload_attempted = 1;
goto retry;
}
 
-   rcu_read_unlock();
return type;
 }
 
@@ -327,17 +328,17 @@ static struct xfrm_mode *xfrm_get_mode(unsigned int 
encap, int family)
if (unlikely(afinfo == NULL))
return NULL;
 
-   mode = afinfo->mode_map[encap];
+   mode = READ_ONCE(afinfo->mode_map[encap]);
if (unlikely(mode && !try_module_get(mode->owner)))
mode = NULL;
+
+   rcu_read_unlock();
if (!mode && !modload_attempted) {
-   rcu_read_unlock();
request_module("xfrm-mode-%d-%d", family, encap);
modload_attempted = 1;
goto retry;
}
 
-   rcu_read_unlock();
return mode;
 }
 
-- 
1.9.1

[PATCH 08/15] xfrm: fix possible null deref in xfrm_init_tempstate

[Steffen Klassert]

From: Florian Westphal 

Dan reports following smatch warning:
 net/xfrm/xfrm_state.c:659
 error: we previously assumed 'afinfo' could be null (see line 651)

 649  struct xfrm_state_afinfo *afinfo = xfrm_state_afinfo_get_rcu(family);
 651  if (afinfo)
...
 658  }
 659  afinfo->init_temprop(x, tmpl, daddr, saddr);

I am resonably sure afinfo cannot be NULL here.

xfrm_state4.c and state6.c are both part of ipv4/ipv6 (depends on
CONFIG_XFRM, a boolean) but even if ipv6 is a module state6.c can't
be removed (ipv6 lacks module_exit so it cannot be removed).

The only callers for xfrm6_fini that leads to state backend unregister
are error unwinding paths that can be called during ipv6 init function.

So after ipv6 module is loaded successfully the state backend cannot go
away anymore.

The family value from policy lookup path is taken from dst_entry, so
that should always be AF_INET(6).

However, since this silences the warning and avoids readers of this
code wondering about possible null deref it seems preferrable to
be defensive and just add the old check back.

Fixes: 711059b9752ad0 ("xfrm: add and use xfrm_state_afinfo_get_rcu")
Reported-by: Dan Carpenter 
Signed-off-by: Florian Westphal 
Signed-off-by: Steffen Klassert 
---
 net/xfrm/xfrm_state.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index a62097e..5a597db 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -648,8 +648,10 @@ void xfrm_sad_getinfo(struct net *net, struct 
xfrmk_sadinfo *si)
 {
struct xfrm_state_afinfo *afinfo = xfrm_state_afinfo_get_rcu(family);
 
-   if (afinfo)
-   afinfo->init_tempsel(>sel, fl);
+   if (!afinfo)
+   return;
+
+   afinfo->init_tempsel(>sel, fl);
 
if (family != tmpl->encap_family) {
afinfo = xfrm_state_afinfo_get_rcu(tmpl->encap_family);
-- 
1.9.1

[PATCH 10/15] IPsec: do not ignore crypto err in ah6 input

[Steffen Klassert]

From: Gilad Ben-Yossef 

ah6 input processing uses the asynchronous hash crypto API which
supplies an error code as part of the operation completion but
the error code was being ignored.

Treat a crypto API error indication as a verification failure.

While a crypto API reported error would almost certainly result
in a memcpy of the digest failing anyway and thus the security
risk seems minor, performing a memory compare on what might be
uninitialized memory is wrong.

Signed-off-by: Gilad Ben-Yossef 
Signed-off-by: Steffen Klassert 
---
 net/ipv6/ah6.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/ipv6/ah6.c b/net/ipv6/ah6.c
index 189eb10..dda6035 100644
--- a/net/ipv6/ah6.c
+++ b/net/ipv6/ah6.c
@@ -474,6 +474,9 @@ static void ah6_input_done(struct crypto_async_request 
*base, int err)
int hdr_len = skb_network_header_len(skb);
int ah_hlen = (ah->hdrlen + 2) << 2;
 
+   if (err)
+   goto out;
+
work_iph = AH_SKB_CB(skb)->tmp;
auth_data = ah_tmp_auth(work_iph, hdr_len);
icv = ah_tmp_icv(ahp->ahash, auth_data, ahp->icv_trunc_len);
-- 
1.9.1

[PATCH 02/15] xfrm: state: do not acquire lock in get_mtu helpers

[Steffen Klassert]

From: Florian Westphal 

Once flow cache gets removed the mtu initialisation happens for every skb
that gets an xfrm attached, so this lock starts to show up in perf.

It is not obvious why this lock is required -- the caller holds
reference on the state struct, type->destructor is only called from the
state gc worker (all state structs on gc list must have refcount 0).

xfrm_init_state already has been called (else private data accessed
by type->get_mtu() would not be set up).

So just remove the lock -- the race on the state (DEAD?) doesn't
matter (could change right after dropping the lock too).

Signed-off-by: Florian Westphal 
Signed-off-by: Steffen Klassert 
---
 net/xfrm/xfrm_state.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index c5cf4d6..6b3366f 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -2000,16 +2000,13 @@ void xfrm_state_delete_tunnel(struct xfrm_state *x)
 
 int xfrm_state_mtu(struct xfrm_state *x, int mtu)
 {
-   int res;
+   const struct xfrm_type *type = READ_ONCE(x->type);
 
-   spin_lock_bh(>lock);
if (x->km.state == XFRM_STATE_VALID &&
-   x->type && x->type->get_mtu)
-   res = x->type->get_mtu(x, mtu);
-   else
-   res = mtu - x->props.header_len;
-   spin_unlock_bh(>lock);
-   return res;
+   type && type->get_mtu)
+   return type->get_mtu(x, mtu);
+
+   return mtu - x->props.header_len;
 }
 
 int __xfrm_init_state(struct xfrm_state *x, bool init_replay)
-- 
1.9.1

[PATCH 14/15] net: Drop secpath on free after gro merge.

[Steffen Klassert]

With a followup patch, a gro merged skb can have a secpath.
So drop it before freeing or reusing the skb.

Signed-off-by: Steffen Klassert 
---
 net/core/dev.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/core/dev.c b/net/core/dev.c
index 56818f7..ef3a969 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4623,6 +4623,7 @@ static gro_result_t napi_skb_finish(gro_result_t ret, 
struct sk_buff *skb)
case GRO_MERGED_FREE:
if (NAPI_GRO_CB(skb)->free == NAPI_GRO_FREE_STOLEN_HEAD) {
skb_dst_drop(skb);
+   secpath_reset(skb);
kmem_cache_free(skbuff_head_cache, skb);
} else {
__kfree_skb(skb);
@@ -4663,6 +4664,7 @@ static void napi_reuse_skb(struct napi_struct *napi, 
struct sk_buff *skb)
skb->encapsulation = 0;
skb_shinfo(skb)->gso_type = 0;
skb->truesize = SKB_TRUESIZE(skb_end_offset(skb));
+   secpath_reset(skb);
 
napi->skb = skb;
 }
-- 
1.9.1

[PATCH 13/15] esp: Introduce a helper to setup the trailer

[Steffen Klassert]

We need to setup the trailer in two different cases,
so add a helper to avoid code duplication.

Signed-off-by: Steffen Klassert 
---
 net/ipv4/esp4.c | 44 +++-
 net/ipv6/esp6.c | 44 +++-
 2 files changed, 38 insertions(+), 50 deletions(-)

diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index 9e8d971..b1e2444 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -182,6 +182,22 @@ static void esp_output_done_esn(struct 
crypto_async_request *base, int err)
esp_output_done(base, err);
 }
 
+static void esp_output_fill_trailer(u8 *tail, int tfclen, int plen, __u8 proto)
+{
+   /* Fill padding... */
+   if (tfclen) {
+   memset(tail, 0, tfclen);
+   tail += tfclen;
+   }
+   do {
+   int i;
+   for (i = 0; i < plen - 2; i++)
+   tail[i] = i + 1;
+   } while (0);
+   tail[plen - 2] = plen - 2;
+   tail[plen - 1] = proto;
+}
+
 static int esp_output(struct xfrm_state *x, struct sk_buff *skb)
 {
struct esp_output_extra *extra;
@@ -304,18 +320,7 @@ static int esp_output(struct xfrm_state *x, struct sk_buff 
*skb)
 
tail = vaddr + pfrag->offset;
 
-   /* Fill padding... */
-   if (tfclen) {
-   memset(tail, 0, tfclen);
-   tail += tfclen;
-   }
-   do {
-   int i;
-   for (i = 0; i < plen - 2; i++)
-   tail[i] = i + 1;
-   } while (0);
-   tail[plen - 2] = plen - 2;
-   tail[plen - 1] = proto;
+   esp_output_fill_trailer(tail, tfclen, plen, proto);
 
kunmap_atomic(vaddr);
 
@@ -395,20 +400,9 @@ static int esp_output(struct xfrm_state *x, struct sk_buff 
*skb)
esph = ip_esp_hdr(skb);
 
 skip_cow:
-   /* Fill padding... */
-   if (tfclen) {
-   memset(tail, 0, tfclen);
-   tail += tfclen;
-   }
-   do {
-   int i;
-   for (i = 0; i < plen - 2; i++)
-   tail[i] = i + 1;
-   } while (0);
-   tail[plen - 2] = plen - 2;
-   tail[plen - 1] = proto;
-   pskb_put(skb, trailer, clen - skb->len + alen);
+   esp_output_fill_trailer(tail, tfclen, plen, proto);
 
+   pskb_put(skb, trailer, clen - skb->len + alen);
skb_push(skb, -skb_network_offset(skb));
esph->seq_no = htonl(XFRM_SKB_CB(skb)->seq.output.low);
esph->spi = x->id.spi;
diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
index a428ac6..ff54faa 100644
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@ -198,6 +198,22 @@ static void esp_output_done_esn(struct 
crypto_async_request *base, int err)
esp_output_done(base, err);
 }
 
+static void esp_output_fill_trailer(u8 *tail, int tfclen, int plen, __u8 proto)
+{
+   /* Fill padding... */
+   if (tfclen) {
+   memset(tail, 0, tfclen);
+   tail += tfclen;
+   }
+   do {
+   int i;
+   for (i = 0; i < plen - 2; i++)
+   tail[i] = i + 1;
+   } while (0);
+   tail[plen - 2] = plen - 2;
+   tail[plen - 1] = proto;
+}
+
 static int esp6_output(struct xfrm_state *x, struct sk_buff *skb)
 {
int err;
@@ -284,18 +300,7 @@ static int esp6_output(struct xfrm_state *x, struct 
sk_buff *skb)
 
tail = vaddr + pfrag->offset;
 
-   /* Fill padding... */
-   if (tfclen) {
-   memset(tail, 0, tfclen);
-   tail += tfclen;
-   }
-   do {
-   int i;
-   for (i = 0; i < plen - 2; i++)
-   tail[i] = i + 1;
-   } while (0);
-   tail[plen - 2] = plen - 2;
-   tail[plen - 1] = proto;
+   esp_output_fill_trailer(tail, tfclen, plen, proto);
 
kunmap_atomic(vaddr);
 
@@ -375,20 +380,9 @@ static int esp6_output(struct xfrm_state *x, struct 
sk_buff *skb)
esph = ip_esp_hdr(skb);
 
 skip_cow:
-   /* Fill padding... */
-   if (tfclen) {
-   memset(tail, 0, tfclen);
-   tail += tfclen;
-   }
-   do {
-   int i;
-   for (i = 0; i < plen - 2; i++)
-   tail[i] = i + 1;
-   } while (0);
-   tail[plen - 2] = plen - 2;
-   tail[plen - 1] = proto;
-   pskb_put(skb, trailer, clen - skb->len + alen);
+   esp_output_fill_trailer(tail, tfclen, plen, proto);
 
+   pskb_put(skb, trailer, clen - 

[PATCH 03/15] xfrm: remove unused function

[Steffen Klassert]

From: Florian Westphal 

Has been ifdef'd out for more than 10 years, remove it.

Signed-off-by: Florian Westphal 
Signed-off-by: Steffen Klassert 
---
 net/ipv4/xfrm4_state.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/net/ipv4/xfrm4_state.c b/net/ipv4/xfrm4_state.c
index 542074c..d6660a8 100644
--- a/net/ipv4/xfrm4_state.c
+++ b/net/ipv4/xfrm4_state.c
@@ -90,11 +90,3 @@ void __init xfrm4_state_init(void)
 {
xfrm_state_register_afinfo(_state_afinfo);
 }
-
-#if 0
-void __exit xfrm4_state_fini(void)
-{
-   xfrm_state_unregister_afinfo(_state_afinfo);
-}
-#endif  /*  0  */
-
-- 
1.9.1

[PATCH 15/15] xfrm: Add a dummy network device for napi.

[Steffen Klassert]

This patch adds a dummy network device so that we can
use gro_cells for IPsec GRO. With this, we handle IPsec
GRO with no impact on the generic networking code.

Signed-off-by: Steffen Klassert 
---
 net/xfrm/xfrm_input.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index 6e3f025..3213fe8 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -21,6 +21,9 @@
 static DEFINE_SPINLOCK(xfrm_input_afinfo_lock);
 static struct xfrm_input_afinfo __rcu *xfrm_input_afinfo[NPROTO];
 
+static struct gro_cells gro_cells;
+static struct net_device xfrm_napi_dev;
+
 int xfrm_input_register_afinfo(struct xfrm_input_afinfo *afinfo)
 {
int err = 0;
@@ -371,7 +374,7 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 
spi, int encap_type)
 
if (decaps) {
skb_dst_drop(skb);
-   netif_rx(skb);
+   gro_cells_receive(_cells, skb);
return 0;
} else {
return x->inner_mode->afinfo->transport_finish(skb, async);
@@ -394,6 +397,13 @@ int xfrm_input_resume(struct sk_buff *skb, int nexthdr)
 
 void __init xfrm_input_init(void)
 {
+   int err;
+
+   init_dummy_netdev(_napi_dev);
+   err = gro_cells_init(_cells, _napi_dev);
+   if (err)
+   gro_cells.cells = NULL;
+
secpath_cachep = kmem_cache_create("secpath_cache",
   sizeof(struct sec_path),
   0, SLAB_HWCACHE_ALIGN|SLAB_PANIC,
-- 
1.9.1

[patch net-next] ethernet: aquantia: fix dma_mapping_error test

[Dan Carpenter]

dma_mapping_error() returns 1 if there is an error and 0 if not.

Fixes: 018423e90bee ("net: ethernet: aquantia: Add ring support code")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_ring.c 
b/drivers/net/ethernet/aquantia/atlantic/aq_ring.c
index 817c145520c8..dea9e9bbb8e7 100644
--- a/drivers/net/ethernet/aquantia/atlantic/aq_ring.c
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_ring.c
@@ -298,9 +298,10 @@ int aq_ring_rx_fill(struct aq_ring_s *self)
buff->page, 0,
AQ_CFG_RX_FRAME_MAX, DMA_FROM_DEVICE);
 
-   err = dma_mapping_error(aq_nic_get_dev(self->aq_nic), buff->pa);
-   if (err < 0)
+   if (dma_mapping_error(aq_nic_get_dev(self->aq_nic), buff->pa)) {
+   err = -ENOMEM;
goto err_exit;
+   }
 
buff = NULL;
}

Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data

[Michal Kazior]

On 1 February 2017 at 09:33, Pali Rohár  wrote:
> On Tuesday 31 January 2017 07:59:18 Tony Lindgren wrote:
>> * Kalle Valo  [170130 22:36]:
[...]
>> > * before distro updates linux-firmware create yours own deb/rpm/whatever
>> >   package "wl1251-firmware" which installs your flavor of nvs file (or
>> >   the user fallback helper if more dynamic functionality is preferred)
>>
>> And that won't work when using the same file system on other machines.
>>
>> Think NFSroot for example. At least I'm using the same NFSroot across
>> about 15 different machines including one n900 macro board with smc91x
>> Ethernet.
>
> Exactly problem which we already discussed in previous emails. You
> cannot serve one file (loaded by direct request_firmware) when your
> rootfs is readonly, e.g. comes via NFS shared for more devices...

You can extract the nvs blob, put it in tmpfs and bind-mount (or
symlink) it to /lib/firmware/ via modprobe install hook (or init
scripts).


Michał

Re: [PATCH 4.10-rc3 05/13] net: bgmac: fix build errors when linux/phy*.h is removed from net/dsa.h

[Rafał Miłecki]

On 01/31/2017 08:18 PM, Russell King wrote:

drivers/net/ethernet/broadcom/bgmac.c:1015:17: error: dereferencing pointer to 
incomplete type 'struct mii_bus'
drivers/net/ethernet/broadcom/bgmac.c:1185:2: error: implicit declaration of 
function 'phy_start' [-Werror=implicit-function-declaration]
drivers/net/ethernet/broadcom/bgmac.c:1198:2: error: implicit declaration of 
function 'phy_stop' [-Werror=implicit-function-declaration]
drivers/net/ethernet/broadcom/bgmac.c:1239:9: error: implicit declaration of 
function 'phy_mii_ioctl' [-Werror=implicit-function-declaration]
drivers/net/ethernet/broadcom/bgmac.c:1389:28: error: 
'phy_ethtool_get_link_ksettings' undeclared here (not in a function)
drivers/net/ethernet/broadcom/bgmac.c:1390:28: error: 
'phy_ethtool_set_link_ksettings' undeclared here (not in a function)
drivers/net/ethernet/broadcom/bgmac.c:1403:13: error: dereferencing pointer to 
incomplete type 'struct phy_device'
drivers/net/ethernet/broadcom/bgmac.c:1417:3: error: implicit declaration of 
function 'phy_print_status' [-Werror=implicit-function-declaration]
drivers/net/ethernet/broadcom/bgmac.c:1424:26: error: storage size of 
'fphy_status' isn't known
drivers/net/ethernet/broadcom/bgmac.c:1424:9: error: variable 'fphy_status' has 
initializer but incomplete type
drivers/net/ethernet/broadcom/bgmac.c:1425:11: warning: excess elements in 
struct initializer
drivers/net/ethernet/broadcom/bgmac.c:1425:3: error: unknown field 'link' 
specified in initializer
drivers/net/ethernet/broadcom/bgmac.c:1426:12: note: in expansion of macro 
'SPEED_1000'
drivers/net/ethernet/broadcom/bgmac.c:1426:3: error: unknown field 'speed' 
specified in initializer
drivers/net/ethernet/broadcom/bgmac.c:1427:13: note: in expansion of macro 
'DUPLEX_FULL'
drivers/net/ethernet/broadcom/bgmac.c:1427:3: error: unknown field 'duplex' 
specified in initializer
drivers/net/ethernet/broadcom/bgmac.c:1432:12: error: implicit declaration of 
function 'fixed_phy_register' [-Werror=implicit-function-declaration]
drivers/net/ethernet/broadcom/bgmac.c:1432:31: error: 'PHY_POLL' undeclared 
(first use in this function)
drivers/net/ethernet/broadcom/bgmac.c:1438:8: error: implicit declaration of 
function 'phy_connect_direct' [-Werror=implicit-function-declaration]
drivers/net/ethernet/broadcom/bgmac.c:1439:6: error: 'PHY_INTERFACE_MODE_MII' 
undeclared (first use in this function)
drivers/net/ethernet/broadcom/bgmac.c:1521:2: error: implicit declaration of 
function 'phy_disconnect' [-Werror=implicit-function-declaration]
drivers/net/ethernet/broadcom/bgmac.c:1541:15: error: expected declaration 
specifiers or '...' before string constant

Add linux/phy.h to bgmac.c

Signed-off-by: Russell King 


Acked-by: Rafał Miłecki 

[patch] ipv6: pointer math error in ip6_tnl_parse_tlv_enc_lim()

[Dan Carpenter]

Casting is a high precedence operation but "off" and "i" are in terms of
bytes so we need to have some parenthesis here.

Fixes: fbfa743a9d2a ("ipv6: fix ip6_tnl_parse_tlv_enc_lim()")
Signed-off-by: Dan Carpenter 

diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index ff8ee06491c3..75fac933c209 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -441,7 +441,7 @@ __u16 ip6_tnl_parse_tlv_enc_lim(struct sk_buff *skb, __u8 
*raw)
if (i + sizeof(*tel) > optlen)
break;
 
-   tel = (struct ipv6_tlv_tnl_enc_lim *) skb->data 
+ off + i;
+   tel = (struct ipv6_tlv_tnl_enc_lim *)(skb->data 
+ off + i);
/* return index of option if found and valid */
if (tel->type == IPV6_TLV_TNL_ENCAP_LIMIT &&
tel->length == 1)

Re: [PATCH net-next 00/10] bnxt_en: Add XDP support.

[Andy Gospodarek]

On Tue, Jan 31, 2017 at 10:22:12PM -0800, Alexei Starovoitov wrote:
> On Tue, Jan 31, 2017 at 9:33 PM, Andy Gospodarek  wrote:
> > On Tue, Jan 31, 2017 at 10:36 AM, Andy Gospodarek  
> > wrote:
> >> On Mon, Jan 30, 2017 at 08:47:47PM -0800, Alexei Starovoitov wrote:
> >>> On Mon, Jan 30, 2017 at 08:49:25PM -0500, Michael Chan wrote:
> >>> > The first 8 patches refactor the code (rx/tx code paths and ring logic)
> >>> > and add the basic infrastructure to support XDP.  The 9th patch adds
> >>> > basic ndo_xdp to support XDP_DROP and XDP_PASS only.  The 10th patch
> >>> > completes the series with XDP_TX.
> >>>
> >>> Looks great.
> >>> Could you please share performance numbers ?
> >>
> >> I'll post some later today.
> >
> > I finally got my system moved around to what I'd hoped would be the
> > right spot in my lab, but the system used for generating the traffic
> > was only able to send 6Mpps with pktgen, so it was not a great test.
> >
> > My receiving system with i7-6700 CPU @ 3.40GHz seemed to have no issue
> > handling this 6Mpps load -- mpstat showed only one core was ~25%
> > utilitzed with all of that servicing softirqs.  The rest of the cores
> > were 100% idle.
> >
> > I'm going to search for other traffic generation tools/systems to make
> > sure I can get at least line-rate for the 10GbE cards I was using.
> 
> hmm. last time I tried pktgen on bnx2x it was easily doing 14Mpps with burst 
> on.
> Have you been using samples/pktgen/pktgen_sample03_burst_single_flow.sh ?

Yes I was.  I saw that Brenden has used it to produce some benchmarks, so
that is what I was using as well.

> Waiting for this set to land to start benchmarking on bnxt.
> So having a baseline will certainly help :)

I was hoping to get a better baseline, too.  These results do not seem
to approach the limit of what can be done with XDP on this hardware.
I'm going to try and move some more gear around get to get something
better setup.

Re: [PATCH v2 net-next] net: phy: Add LED mode driver for Microsemi PHYs.

[Andrew Lunn]

On Wed, Feb 01, 2017 at 06:23:46PM +0530, Raju Lakkaraju wrote:
> From: Raju Lakkaraju 
> 
> LED Mode:
> Microsemi PHY support 2 LEDs (LED[0] and LED[1]) to display different
> status information that can be selected by setting LED mode.
> 
> LED Mode parameter (vsc8531, led-0-mode) and (vsc8531, led-1-mode) get
> from Device Tree.
> 
> Signed-off-by: Raju Lakkaraju 
> ---
>  .../devicetree/bindings/net/mscc-phy-vsc8531.txt   | 10 +++
>  drivers/net/phy/mscc.c | 85 
> +-
>  include/dt-bindings/net/mscc-phy-vsc8531.h | 29 
>  3 files changed, 123 insertions(+), 1 deletion(-)
>  create mode 100644 include/dt-bindings/net/mscc-phy-vsc8531.h
> 
> diff --git a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt 
> b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
> index bdefefc6..bb7450c 100644
> --- a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
> +++ b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
> @@ -27,6 +27,14 @@ Optional properties:
> 'vddmac'.
> Default value is 0%.
> Ref: Table:1 - Edge rate change (below).
> +- vsc8531,led-0-mode : LED mode. Specify how the LED[0] should behave.
> +   Allowed values are define in
> +   "include/dt-bindings/net/mscc-phy-vsc8531.h".
> +   Default value is 1.

1 is not very useful. What does it mean? How about:

Default value is LINK_1000_ACTIVITY (1) 
   

> +- vsc8531,led-1-mode : LED mode. Specify how the LED[1] should behave.
> +   Allowed values are define in
> +   "include/dt-bindings/net/mscc-phy-vsc8531.h".
> +   Default value is 2.
>  
>  Table: 1 - Edge rate change
>  |
> @@ -60,4 +68,6 @@ Example:
>  compatible = "ethernet-phy-id0007.0570";
>  vsc8531,vddmac   = <3300>;
>  vsc8531,edge-slowdown= <7>;
> +vsc8531,led-0-mode   = ;
> +vsc8531,led-1-mode   = ;
>  };
> diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c
> index e03ead8..f0cb7cc 100644
> --- a/drivers/net/phy/mscc.c
> +++ b/drivers/net/phy/mscc.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  enum rgmii_rx_clock_delay {
>   RGMII_RX_CLK_DELAY_0_2_NS = 0,
> @@ -52,6 +53,11 @@ enum rgmii_rx_clock_delay {
>  #define MSCC_PHY_DEV_AUX_CNTL  28
>  #define HP_AUTO_MDIX_X_OVER_IND_MASK   0x2000
>  
> +#define MSCC_PHY_LED_MODE_SEL  29
> +#define LED_1_MODE_SEL_MASK0x00F0
> +#define LED_0_MODE_SEL_MASK0x000F
> +#define LED_1_MODE_SEL_POS 4
> +
>  #define MSCC_EXT_PAGE_ACCESS   31
>  #define MSCC_PHY_PAGE_STANDARD 0x /* Standard registers 
> */
>  #define MSCC_PHY_PAGE_EXTENDED 0x0001 /* Extended registers 
> */
> @@ -99,6 +105,8 @@ enum rgmii_rx_clock_delay {
>  
>  struct vsc8531_private {
>   int rate_magic;
> + u8 led_0_mode;
> + u8 led_1_mode;
>  };
>  
>  #ifdef CONFIG_OF_MDIO
> @@ -123,6 +131,29 @@ static int vsc85xx_phy_page_set(struct phy_device 
> *phydev, u8 page)
>   return rc;
>  }
>  
> +static int vsc85xx_led_cntl_set(struct phy_device *phydev,
> + u8 led_num,
> + u8 mode)
> +{
> + int rc;
> + u16 reg_val;
> +
> + mutex_lock(>lock);
> + reg_val = phy_read(phydev, MSCC_PHY_LED_MODE_SEL);
> + if (led_num) {
> + reg_val &= ~LED_1_MODE_SEL_MASK;
> + reg_val |= (((u16)mode << LED_1_MODE_SEL_POS) &
> + LED_1_MODE_SEL_MASK);
> + } else {
> + reg_val &= ~LED_0_MODE_SEL_MASK;
> + reg_val |= ((u16)mode & LED_0_MODE_SEL_MASK);
> + }
> + rc = phy_write(phydev, MSCC_PHY_LED_MODE_SEL, reg_val);
> + mutex_unlock(>lock);
> +
> + return rc;
> +}
> +
>  static int vsc85xx_mdix_get(struct phy_device *phydev, u8 *mdix)
>  {
>   u16 reg_val;
> @@ -370,11 +401,43 @@ static int vsc85xx_edge_rate_magic_get(struct 
> phy_device *phydev)
>  
>   return -EINVAL;
>  }
> +
> +static int vsc85xx_dt_led_mode_get(struct phy_device *phydev,
> +char *led,
> +u8 default_mode)
> +{
> + struct device *dev = >mdio.dev;
> + struct device_node *of_node = dev->of_node;
> + u8 led_mode;
> + int rc;
> +
> + if (!of_node)
> + return -ENODEV;
> +
> + rc = of_property_read_u8(of_node, led, _mode);
> + if ((rc == 0) &&
> + ((led_mode > 15) || (led_mode == 7) || (led_mode == 11))) {
> + phydev_err(phydev, 

RE: [net-next 2/8] net/mlx5: Configure cache line size for start and end padding

[David Laight]

From: Saeed Mahameed
> Sent: 31 January 2017 20:59
> From: Daniel Jurgens 
> 
> There is a hardware feature that will pad the start or end of a DMA to
> be cache line aligned to avoid RMWs on the last cache line. The default
> cache line size setting for this feature is 64B. This change configures
> the hardware to use 128B alignment on systems with 128B cache lines.

What guarantees that the extra bytes are actually inside the receive skb's
head and tail room?

David

Re: [PATCH v1 net-next] net: phy: Add LED mode driver for Microsemi PHYs.

[kbuild test robot]

Hi Raju,

[auto build test ERROR on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Raju-Lakkaraju/net-phy-Add-LED-mode-driver-for-Microsemi-PHYs/20170201-185922
config: x86_64-randconfig-x001-201705 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/net/phy/mscc.c: In function 'vsc85xx_probe':
>> drivers/net/phy/mscc.c:645:13: error: implicit declaration of function 
>> 'vsc85xx_dt_led_mode_get' [-Werror=implicit-function-declaration]
 led_mode = vsc85xx_dt_led_mode_get(phydev, "vsc8531,led-0-mode",
^~~
   At top level:
   drivers/net/phy/mscc.c:435:12: warning: 'vsc85xx_led_mode_get' defined but 
not used [-Wunused-function]
static int vsc85xx_led_mode_get(struct phy_device *phydev,
   ^~~~
   cc1: some warnings being treated as errors

vim +/vsc85xx_dt_led_mode_get +645 drivers/net/phy/mscc.c

   639  
   640  phydev->priv = vsc8531;
   641  
   642  vsc8531->rate_magic = rate_magic;
   643  
   644  /* LED[0] and LED[1] mode */
 > 645  led_mode = vsc85xx_dt_led_mode_get(phydev, "vsc8531,led-0-mode",
   646 LINK_1000_ACTIVITY);
   647  if (led_mode < 0)
   648  return led_mode;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH v2 net-next 0/3] Extract IFE logic to module

[Yotam Gigi]

Extract ife logic from the tc_ife action into an independent module, and
make the tc_ife action use it. This way, the ife encapsulation can be used
by other modules other than tc_ife action.

v1->v2:
Fix duplicate symbol error by introducing a new patch that makes the
original symbol static.

The symbol ife_tlv_meta_extract is exported in act_ife, though not being
used by any other module. As the symbol is being moved to the new ife
module, introducing the new module creates duplicate symbol. To fix it,
add a new patch (1/3) that makes the ife_tlv_meta_extract symbol static in
act_ife, thus the symbol does not collide.

Yotam Gigi (3):
  net/sched: act_ife: Unexport ife_tlv_meta_encode
  net: Introduce ife encapsulation module
  net/sched: act_ife: Change to use ife module

 MAINTAINERS|   7 ++
 include/net/ife.h  |  51 +
 include/net/tc_act/tc_ife.h|   3 -
 include/uapi/linux/Kbuild  |   1 +
 include/uapi/linux/ife.h   |  18 +
 include/uapi/linux/tc_act/tc_ife.h |  10 +--
 net/Kconfig|   1 +
 net/Makefile   |   1 +
 net/ife/Kconfig|  16 +
 net/ife/Makefile   |   5 ++
 net/ife/ife.c  | 142 +
 net/sched/Kconfig  |   1 +
 net/sched/act_ife.c| 110 +---
 13 files changed, 276 insertions(+), 90 deletions(-)
 create mode 100644 include/net/ife.h
 create mode 100644 include/uapi/linux/ife.h
 create mode 100644 net/ife/Kconfig
 create mode 100644 net/ife/Makefile
 create mode 100644 net/ife/ife.c

-- 
2.4.11

[PATCH 3/3] net/sched: act_ife: Change to use ife module

[Yotam Gigi]

Use the encode/decode functionality from the ife module instead of using
implementation inside the act_ife.

Reviewed-by: Jiri Pirko 
Signed-off-by: Yotam Gigi 
---
 include/net/tc_act/tc_ife.h|   1 -
 include/uapi/linux/tc_act/tc_ife.h |  10 +---
 net/sched/Kconfig  |   1 +
 net/sched/act_ife.c| 110 +++--
 4 files changed, 34 insertions(+), 88 deletions(-)

diff --git a/include/net/tc_act/tc_ife.h b/include/net/tc_act/tc_ife.h
index f37e751..30ba459 100644
--- a/include/net/tc_act/tc_ife.h
+++ b/include/net/tc_act/tc_ife.h
@@ -6,7 +6,6 @@
 #include 
 #include 
 
-#define IFE_METAHDRLEN 2
 struct tcf_ife_info {
struct tc_action common;
u8 eth_dst[ETH_ALEN];
diff --git a/include/uapi/linux/tc_act/tc_ife.h 
b/include/uapi/linux/tc_act/tc_ife.h
index cd18360..7c28178 100644
--- a/include/uapi/linux/tc_act/tc_ife.h
+++ b/include/uapi/linux/tc_act/tc_ife.h
@@ -3,6 +3,7 @@
 
 #include 
 #include 
+#include 
 
 #define TCA_ACT_IFE 25
 /* Flag bits for now just encoding/decoding; mutually exclusive */
@@ -28,13 +29,4 @@ enum {
 };
 #define TCA_IFE_MAX (__TCA_IFE_MAX - 1)
 
-#define IFE_META_SKBMARK 1
-#define IFE_META_HASHID 2
-#defineIFE_META_PRIO 3
-#defineIFE_META_QMAP 4
-#defineIFE_META_TCINDEX 5
-/*Can be overridden at runtime by module option*/
-#define__IFE_META_MAX 6
-#define IFE_META_MAX (__IFE_META_MAX - 1)
-
 #endif
diff --git a/net/sched/Kconfig b/net/sched/Kconfig
index 72cfa3a..403790c 100644
--- a/net/sched/Kconfig
+++ b/net/sched/Kconfig
@@ -776,6 +776,7 @@ config NET_ACT_SKBMOD
 config NET_ACT_IFE
 tristate "Inter-FE action based on IETF ForCES InterFE LFB"
 depends on NET_CLS_ACT
+select NET_IFE
 ---help---
  Say Y here to allow for sourcing and terminating metadata
  For details refer to netdev01 paper:
diff --git a/net/sched/act_ife.c b/net/sched/act_ife.c
index 70148c1..71e7ff22 100644
--- a/net/sched/act_ife.c
+++ b/net/sched/act_ife.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define IFE_TAB_MASK 15
 
@@ -46,23 +47,6 @@ static const struct nla_policy ife_policy[TCA_IFE_MAX + 1] = 
{
[TCA_IFE_TYPE] = { .type = NLA_U16},
 };
 
-/* Caller takes care of presenting data in network order
-*/
-static int ife_tlv_meta_encode(void *skbdata, u16 attrtype, u16 dlen,
-  const void *dval)
-{
-   u32 *tlv = (u32 *)(skbdata);
-   u16 totlen = nla_total_size(dlen);  /*alignment + hdr */
-   char *dptr = (char *)tlv + NLA_HDRLEN;
-   u32 htlv = attrtype << 16 | (dlen + NLA_HDRLEN);
-
-   *tlv = htonl(htlv);
-   memset(dptr, 0, totlen - NLA_HDRLEN);
-   memcpy(dptr, dval, dlen);
-
-   return totlen;
-}
-
 int ife_encode_meta_u16(u16 metaval, void *skbdata, struct tcf_meta_info *mi)
 {
u16 edata = 0;
@@ -637,69 +621,59 @@ int find_decode_metaid(struct sk_buff *skb, struct 
tcf_ife_info *ife,
return 0;
 }
 
-struct ifeheadr {
-   __be16 metalen;
-   u8 tlv_data[];
-};
-
-struct meta_tlvhdr {
-   __be16 type;
-   __be16 len;
-};
-
 static int tcf_ife_decode(struct sk_buff *skb, const struct tc_action *a,
  struct tcf_result *res)
 {
struct tcf_ife_info *ife = to_ife(a);
int action = ife->tcf_action;
-   struct ifeheadr *ifehdr = (struct ifeheadr *)skb->data;
-   int ifehdrln = (int)ifehdr->metalen;
-   struct meta_tlvhdr *tlv = (struct meta_tlvhdr *)(ifehdr->tlv_data);
+   u8 *ifehdr_end;
+   u8 *tlv_data;
+   u16 metalen;
 
spin_lock(>tcf_lock);
bstats_update(>tcf_bstats, skb);
tcf_lastuse_update(>tcf_tm);
spin_unlock(>tcf_lock);
 
-   ifehdrln = ntohs(ifehdrln);
-   if (unlikely(!pskb_may_pull(skb, ifehdrln))) {
+   if (skb_at_tc_ingress(skb))
+   skb_push(skb, skb->dev->hard_header_len);
+
+   tlv_data = ife_decode(skb, );
+   if (unlikely(!tlv_data)) {
spin_lock(>tcf_lock);
ife->tcf_qstats.drops++;
spin_unlock(>tcf_lock);
return TC_ACT_SHOT;
}
 
-   skb_set_mac_header(skb, ifehdrln);
-   __skb_pull(skb, ifehdrln);
-   skb->protocol = eth_type_trans(skb, skb->dev);
-   ifehdrln -= IFE_METAHDRLEN;
-
-   while (ifehdrln > 0) {
-   u8 *tlvdata = (u8 *)tlv;
-   u16 mtype = tlv->type;
-   u16 mlen = tlv->len;
-   u16 alen;
+   ifehdr_end = tlv_data + metalen;
+   for (; tlv_data < ifehdr_end; tlv_data = ife_tlv_meta_next(tlv_data)) {
+   u8 *curr_data;
+   u16 mtype;
+   u16 dlen;
 
-   mtype = ntohs(mtype);
-   mlen = ntohs(mlen);
-   alen = NLA_ALIGN(mlen);
+   curr_data = ife_tlv_meta_decode(tlv_data, , , NULL);
 
-  

[PATCH 1/3] net/sched: act_ife: Unexport ife_tlv_meta_encode

[Yotam Gigi]

As the function ife_tlv_meta_encode is not used by any other module,
unexport it and make it static for the act_ife module.

Signed-off-by: Yotam Gigi 
---
 include/net/tc_act/tc_ife.h | 2 --
 net/sched/act_ife.c | 4 ++--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/include/net/tc_act/tc_ife.h b/include/net/tc_act/tc_ife.h
index 9fd2bea0..f37e751 100644
--- a/include/net/tc_act/tc_ife.h
+++ b/include/net/tc_act/tc_ife.h
@@ -45,8 +45,6 @@ struct tcf_meta_ops {
 
 int ife_get_meta_u32(struct sk_buff *skb, struct tcf_meta_info *mi);
 int ife_get_meta_u16(struct sk_buff *skb, struct tcf_meta_info *mi);
-int ife_tlv_meta_encode(void *skbdata, u16 attrtype, u16 dlen,
-   const void *dval);
 int ife_alloc_meta_u32(struct tcf_meta_info *mi, void *metaval, gfp_t gfp);
 int ife_alloc_meta_u16(struct tcf_meta_info *mi, void *metaval, gfp_t gfp);
 int ife_check_meta_u32(u32 metaval, struct tcf_meta_info *mi);
diff --git a/net/sched/act_ife.c b/net/sched/act_ife.c
index 921fb20..70148c1 100644
--- a/net/sched/act_ife.c
+++ b/net/sched/act_ife.c
@@ -48,7 +48,8 @@ static const struct nla_policy ife_policy[TCA_IFE_MAX + 1] = {
 
 /* Caller takes care of presenting data in network order
 */
-int ife_tlv_meta_encode(void *skbdata, u16 attrtype, u16 dlen, const void 
*dval)
+static int ife_tlv_meta_encode(void *skbdata, u16 attrtype, u16 dlen,
+  const void *dval)
 {
u32 *tlv = (u32 *)(skbdata);
u16 totlen = nla_total_size(dlen);  /*alignment + hdr */
@@ -61,7 +62,6 @@ int ife_tlv_meta_encode(void *skbdata, u16 attrtype, u16 
dlen, const void *dval)
 
return totlen;
 }
-EXPORT_SYMBOL_GPL(ife_tlv_meta_encode);
 
 int ife_encode_meta_u16(u16 metaval, void *skbdata, struct tcf_meta_info *mi)
 {
-- 
2.4.11

[PATCH 2/3] net: Introduce ife encapsulation module

[Yotam Gigi]

This module is responsible for the ife encapsulation protocol
encode/decode logics. That module can:
 - ife_encode: encode skb and reserve space for the ife meta header
 - ife_decode: decode skb and extract the meta header size
 - ife_tlv_meta_encode - encodes one tlv entry into the reserved ife
   header space.
 - ife_tlv_meta_decode - decodes one tlv entry from the packet
 - ife_tlv_meta_next - advance to the next tlv

Reviewed-by: Jiri Pirko 
Signed-off-by: Yotam Gigi 
---
 MAINTAINERS   |   7 +++
 include/net/ife.h |  51 +
 include/uapi/linux/Kbuild |   1 +
 include/uapi/linux/ife.h  |  18 ++
 net/Kconfig   |   1 +
 net/Makefile  |   1 +
 net/ife/Kconfig   |  16 ++
 net/ife/Makefile  |   5 ++
 net/ife/ife.c | 142 ++
 9 files changed, 242 insertions(+)
 create mode 100644 include/net/ife.h
 create mode 100644 include/uapi/linux/ife.h
 create mode 100644 net/ife/Kconfig
 create mode 100644 net/ife/Makefile
 create mode 100644 net/ife/ife.c

diff --git a/MAINTAINERS b/MAINTAINERS
index cc106f7..3017257 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6250,6 +6250,13 @@ F:   include/net/cfg802154.h
 F: include/net/ieee802154_netdev.h
 F: Documentation/networking/ieee802154.txt
 
+IFE PROTOCOL
+M: Yotam Gigi 
+M: Jamal Hadi Salim 
+F: net/ife
+F: include/net/ife.h
+F: include/uapi/linux/ife.h
+
 IGORPLUG-USB IR RECEIVER
 M: Sean Young 
 L: linux-me...@vger.kernel.org
diff --git a/include/net/ife.h b/include/net/ife.h
new file mode 100644
index 000..2d87d68
--- /dev/null
+++ b/include/net/ife.h
@@ -0,0 +1,51 @@
+#ifndef __NET_IFE_H
+#define __NET_IFE_H
+
+#include 
+#include 
+#include 
+#include 
+
+#if IS_ENABLED(CONFIG_NET_IFE)
+
+void *ife_encode(struct sk_buff *skb, u16 metalen);
+void *ife_decode(struct sk_buff *skb, u16 *metalen);
+
+void *ife_tlv_meta_decode(void *skbdata, u16 *attrtype, u16 *dlen, u16 
*totlen);
+int ife_tlv_meta_encode(void *skbdata, u16 attrtype, u16 dlen,
+   const void *dval);
+
+void *ife_tlv_meta_next(void *skbdata);
+
+#else
+
+static inline void *ife_encode(struct sk_buff *skb, u16 metalen)
+{
+   return NULL;
+}
+
+static inline void *ife_decode(struct sk_buff *skb, u16 *metalen)
+{
+   return NULL;
+}
+
+static inline void *ife_tlv_meta_decode(void *skbdata, u16 *attrtype, u16 
*dlen,
+   u16 *totlen)
+{
+   return NULL;
+}
+
+static inline int ife_tlv_meta_encode(void *skbdata, u16 attrtype, u16 dlen,
+   const void *dval)
+{
+   return 0;
+}
+
+static inline void *ife_tlv_meta_next(void *skbdata)
+{
+   return NULL;
+}
+
+#endif
+
+#endif /* __NET_IFE_H */
diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
index 486e050..a2e9072 100644
--- a/include/uapi/linux/Kbuild
+++ b/include/uapi/linux/Kbuild
@@ -195,6 +195,7 @@ header-y += if_tun.h
 header-y += if_tunnel.h
 header-y += if_vlan.h
 header-y += if_x25.h
+header-y += ife.h
 header-y += igmp.h
 header-y += ila.h
 header-y += in6.h
diff --git a/include/uapi/linux/ife.h b/include/uapi/linux/ife.h
new file mode 100644
index 000..2954da3
--- /dev/null
+++ b/include/uapi/linux/ife.h
@@ -0,0 +1,18 @@
+#ifndef __UAPI_IFE_H
+#define __UAPI_IFE_H
+
+#define IFE_METAHDRLEN 2
+
+enum {
+   IFE_META_SKBMARK = 1,
+   IFE_META_HASHID,
+   IFE_META_PRIO,
+   IFE_META_QMAP,
+   IFE_META_TCINDEX,
+   __IFE_META_MAX
+};
+
+/*Can be overridden at runtime by module option*/
+#define IFE_META_MAX (__IFE_META_MAX - 1)
+
+#endif
diff --git a/net/Kconfig b/net/Kconfig
index ce4aee6..2f2842d 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -391,6 +391,7 @@ source "net/caif/Kconfig"
 source "net/ceph/Kconfig"
 source "net/nfc/Kconfig"
 source "net/psample/Kconfig"
+source "net/ife/Kconfig"
 
 config LWTUNNEL
bool "Network light weight tunnels"
diff --git a/net/Makefile b/net/Makefile
index 7d41de4..9b68155 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_CEPH_LIB)+= ceph/
 obj-$(CONFIG_BATMAN_ADV)   += batman-adv/
 obj-$(CONFIG_NFC)  += nfc/
 obj-$(CONFIG_PSAMPLE)  += psample/
+obj-$(CONFIG_NET_IFE)  += ife/
 obj-$(CONFIG_OPENVSWITCH)  += openvswitch/
 obj-$(CONFIG_VSOCKETS) += vmw_vsock/
 obj-$(CONFIG_MPLS) += mpls/
diff --git a/net/ife/Kconfig b/net/ife/Kconfig
new file mode 100644
index 000..31e48b6
--- /dev/null
+++ b/net/ife/Kconfig
@@ -0,0 +1,16 @@
+#
+# IFE subsystem configuration
+#
+
+menuconfig NET_IFE
+   depends on NET
+tristate "Inter-FE based on IETF ForCES InterFE LFB"
+   default n
+   help
+ Say Y here to add support of IFE encapsulation protocol
+ For details refer to netdev01 paper:

RE: [net-next 1/8] net/mlx5: Fixed static checker warnings

[David Laight]

From: Saeed Mahameed
> Sent: 31 January 2017 20:59
> From: Or Gerlitz 
> 
> For some reason, sparse doesn't like using an expression of type (!x)
> with a bitwise | and &.  In order to mitigate that, we use a local
> variable.
> 
> Since getting a typeof(bitfield) is incorrect, we cast such cases.
...
> + MLX5_SET(fte_match_set_lyr_2_4, headers_c, first_prio, 
> (u8)mask->vlan_priority);

Ugg nasty casts...
...
>  #define MLX5_SET(typ, p, fld, v) do { \
> + typeof(v) _v = v; \
..

Why not just 'unsigned int _v = v;

David

[PATCH v2 net-next] net: phy: Add LED mode driver for Microsemi PHYs.

[Raju Lakkaraju]

From: Raju Lakkaraju 

LED Mode:
Microsemi PHY support 2 LEDs (LED[0] and LED[1]) to display different
status information that can be selected by setting LED mode.

LED Mode parameter (vsc8531, led-0-mode) and (vsc8531, led-1-mode) get
from Device Tree.

Signed-off-by: Raju Lakkaraju 
---
 .../devicetree/bindings/net/mscc-phy-vsc8531.txt   | 10 +++
 drivers/net/phy/mscc.c | 85 +-
 include/dt-bindings/net/mscc-phy-vsc8531.h | 29 
 3 files changed, 123 insertions(+), 1 deletion(-)
 create mode 100644 include/dt-bindings/net/mscc-phy-vsc8531.h

diff --git a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt 
b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
index bdefefc6..bb7450c 100644
--- a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
+++ b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
@@ -27,6 +27,14 @@ Optional properties:
  'vddmac'.
  Default value is 0%.
  Ref: Table:1 - Edge rate change (below).
+- vsc8531,led-0-mode   : LED mode. Specify how the LED[0] should behave.
+ Allowed values are define in
+ "include/dt-bindings/net/mscc-phy-vsc8531.h".
+ Default value is 1.
+- vsc8531,led-1-mode   : LED mode. Specify how the LED[1] should behave.
+ Allowed values are define in
+ "include/dt-bindings/net/mscc-phy-vsc8531.h".
+ Default value is 2.
 
 Table: 1 - Edge rate change
 |
@@ -60,4 +68,6 @@ Example:
 compatible = "ethernet-phy-id0007.0570";
 vsc8531,vddmac = <3300>;
 vsc8531,edge-slowdown  = <7>;
+vsc8531,led-0-mode = ;
+vsc8531,led-1-mode = ;
 };
diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c
index e03ead8..f0cb7cc 100644
--- a/drivers/net/phy/mscc.c
+++ b/drivers/net/phy/mscc.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 enum rgmii_rx_clock_delay {
RGMII_RX_CLK_DELAY_0_2_NS = 0,
@@ -52,6 +53,11 @@ enum rgmii_rx_clock_delay {
 #define MSCC_PHY_DEV_AUX_CNTL28
 #define HP_AUTO_MDIX_X_OVER_IND_MASK 0x2000
 
+#define MSCC_PHY_LED_MODE_SEL29
+#define LED_1_MODE_SEL_MASK  0x00F0
+#define LED_0_MODE_SEL_MASK  0x000F
+#define LED_1_MODE_SEL_POS   4
+
 #define MSCC_EXT_PAGE_ACCESS 31
 #define MSCC_PHY_PAGE_STANDARD   0x /* Standard registers */
 #define MSCC_PHY_PAGE_EXTENDED   0x0001 /* Extended registers */
@@ -99,6 +105,8 @@ enum rgmii_rx_clock_delay {
 
 struct vsc8531_private {
int rate_magic;
+   u8 led_0_mode;
+   u8 led_1_mode;
 };
 
 #ifdef CONFIG_OF_MDIO
@@ -123,6 +131,29 @@ static int vsc85xx_phy_page_set(struct phy_device *phydev, 
u8 page)
return rc;
 }
 
+static int vsc85xx_led_cntl_set(struct phy_device *phydev,
+   u8 led_num,
+   u8 mode)
+{
+   int rc;
+   u16 reg_val;
+
+   mutex_lock(>lock);
+   reg_val = phy_read(phydev, MSCC_PHY_LED_MODE_SEL);
+   if (led_num) {
+   reg_val &= ~LED_1_MODE_SEL_MASK;
+   reg_val |= (((u16)mode << LED_1_MODE_SEL_POS) &
+   LED_1_MODE_SEL_MASK);
+   } else {
+   reg_val &= ~LED_0_MODE_SEL_MASK;
+   reg_val |= ((u16)mode & LED_0_MODE_SEL_MASK);
+   }
+   rc = phy_write(phydev, MSCC_PHY_LED_MODE_SEL, reg_val);
+   mutex_unlock(>lock);
+
+   return rc;
+}
+
 static int vsc85xx_mdix_get(struct phy_device *phydev, u8 *mdix)
 {
u16 reg_val;
@@ -370,11 +401,43 @@ static int vsc85xx_edge_rate_magic_get(struct phy_device 
*phydev)
 
return -EINVAL;
 }
+
+static int vsc85xx_dt_led_mode_get(struct phy_device *phydev,
+  char *led,
+  u8 default_mode)
+{
+   struct device *dev = >mdio.dev;
+   struct device_node *of_node = dev->of_node;
+   u8 led_mode;
+   int rc;
+
+   if (!of_node)
+   return -ENODEV;
+
+   rc = of_property_read_u8(of_node, led, _mode);
+   if ((rc == 0) &&
+   ((led_mode > 15) || (led_mode == 7) || (led_mode == 11))) {
+   phydev_err(phydev, "DT %s invalid\n", led);
+   return -EINVAL;
+   } else if (rc == -EINVAL) {
+   return default_mode;
+   }
+
+   return led_mode;
+}
+
 #else
 static int vsc85xx_edge_rate_magic_get(struct phy_device *phydev)
 {
return 0;
 }
+
+static int vsc85xx_dt_led_mode_get(struct phy_device *phydev,
+  char *led,
+

Fwd: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit

[Shubham Bansal]

Resending because of Formatting problems.

Hi Kees & Daniel,

On Tue, Jan 31, 2017 at 09:44:56AM -0800, Kees Cook wrote:
> >> > 1.) Currently, as eBPF uses 64 bit registers, I am mapping 64 bit eBPF
> >> > registers with 32 bit arm registers which looks wrong to me. Do anybody
> >> > have some idea about how to map eBPF->arm 32 bit registers ?
> >>
> >> I was going to say "look at the x86 32-bit implementation." ... But
> >> there isn't one. :( I'm going to guess that there isn't a very good
> >> answer here. I assume you'll have to build some kind of stack scratch
> >> space to load/save.
> >
> >
> > Now I see why nobody has implemented eBPF JIT for the 32 bit systems. I
> > think its very difficult to implement it without any complications and
> > errors.
>
> Yeah, that does seem to make it much more difficult.

I was thinking of first implementing only instructions with 32 bit
register operands. It will hugely decrease the surface area of eBPF
instructions that I have to cover for the first patch.

So, What I am thinking is something like this :

- bpf_mov r0(64),r1(64) will be JITed like this :
  - ar1(32) <- r1(64). Convert/Mask 64 bit ebpf register(r1) value into 32
bit and store it in arm register(ar1).
  - Do MOV ar0(32),ar1(32) as an ARM instruction.
  - ar0(32) -> r0(64). Zero Extend the ar0 32 bit register value
and store it in 64 bit ebpf register r0.

- Similarly, For all BPF_ALU class instructions.
  - For BPF_ADD, I will mask the addition result to 32 bit only.
I am not sure, Overflow might be a problem.
  - For BPF_SUB, I will mask the subtraction result to 32 bit only.
I am not sure, Underflow might be problem.
  - For BPF_MUL, similar to BPF_ADD. Overflow Problem ?
  - For BPF_DIV, 32 bit masking should be fine, I guess.
  - For BPF_OR, BPF_AND, BPF_XOR, BPF_LSH, BPF_RSH, BPF_MOD 32 bit
masking should be fine.
  - For BPF_NEG and BPF_ARSH, might be a problem because of the sign bit.
  - For BPF_END, 32 bit masking should work fine.
Let me know if any of the above point is wrong or need your suggestion.

- Although, for ALU instructions, there is a big problem of register
  flag manipulations. Generally, architecture's ABI takes care of this
  part but as we are doing 64 bit Instructions emulation(kind of) on 32
  bit machine, it needs to be done manually. Does that sound correct ?

- I am not JITing BPF_ALU64 class instructions as of now. As we have to
  take care of atomic instructions and race conditions with these
  instruction which looks complicated to me as of now. Will try to figure out
  this part and implement it later. Currently, I will just let it be
  interpreted by the ebpf interpreter.

- For BPF_JMP class, I am assuming that, although eBPF is 64 bit ABI,
  the address pointers on 32 bit arch like arm will be of 32 bit only.
  So, for BPF_JMP, masking the 64 bit destination address to 32 bit
  should do the trick and no address will be corrupted in this way. Am I
  correct to assume this ?
  Also, I need to check for address getting out of the allowed memory
  range.

- For BPF_LD, BPF_LDX, BPF_ST and BPF_STX class instructions, I am
  assuming the same thing as above - All addresses and pointers are 32
  bit - which can be taken care just by maksing the eBPF register
  values. Does that sound correct ?
  Also, I need to check for the address overflow, address getting out
  of the allowed memory range and things like that.

> > Do you have any code references for me to take a look? Otherwise, I think
> > its not possible for me to implement it without using any reference.
>
> I don't know anything else, no.

I think, I will give it a try. Otherwise, my last 1 month which I used
to read about eBPF, eBPF linux code and arm32 ABI would be a complete
waste.

> >>
> >>
> >> > 2.) Also, is my current mapping good enough to make the JIT fast enough
> >> > ?
> >> > because as you might know, eBPF JIT mostly depends on 1-to-1 mapping of
> >> > its instructions with native instructions.
> >>
> >> I don't know -- it might be tricky with needing to deal with 64-bit
> >> registers. But if you can make it faster than the non-JIT, it should
> >> be a win. :) Yay assembly.

Well, As I mentioned above about my thinking towards the implementation,
I am not sure it would be faster than non-JIT or even correct for that matter.
It might be but I don't think I have enough knowledge to benchmark the
implementation as of now.


-Shubham Bansal

[PATCH v1 net-next] net: phy: Add LED mode driver for Microsemi

[Raju Lakkaraju]

From: Raju Lakkaraju 

LED Mode:
Microsemi PHY support 2 LEDs (LED[0] and LED[1]) to display different
status information that can be selected by setting LED mode.

LED Mode parameter (vsc8531, led-0-mode) and (vsc8531, led-1-mode) get from
Device Tree.

Tested on Beaglebone Black with VSC 8531 PHY.

Change set:
v0:
- Initial version of LED driver for Microsemi PHYs.
v1:
- Update all review comments given by Andrew.
- Add new header file "mscc-phy-vsc8531.h" to define DT macros.
- Add error/range check for DT LED mode input

Signed-off-by: Raju Lakkaraju 

Raju Lakkaraju (1):
  net: phy: Add LED mode driver for Microsemi PHYs.

 .../devicetree/bindings/net/mscc-phy-vsc8531.txt   | 10 +++
 drivers/net/phy/mscc.c | 85 +-
 include/dt-bindings/net/mscc-phy-vsc8531.h | 29 
 3 files changed, 123 insertions(+), 1 deletion(-)
 create mode 100644 include/dt-bindings/net/mscc-phy-vsc8531.h

-- 
2.7.4

[PATCH v1 net-next] net: phy: Add LED mode driver for Microsemi PHYs.

[Raju Lakkaraju]

From: Raju Lakkaraju 

LED Mode:
Microsemi PHY support 2 LEDs (LED[0] and LED[1]) to display different
status information that can be selected by setting LED mode.

LED Mode parameter (vsc8531, led-0-mode) and (vsc8531, led-1-mode) get
from Device Tree.

Signed-off-by: Raju Lakkaraju 
---
 .../devicetree/bindings/net/mscc-phy-vsc8531.txt   | 10 +++
 drivers/net/phy/mscc.c | 85 +-
 include/dt-bindings/net/mscc-phy-vsc8531.h | 29 
 3 files changed, 123 insertions(+), 1 deletion(-)
 create mode 100644 include/dt-bindings/net/mscc-phy-vsc8531.h

diff --git a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt 
b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
index bdefefc6..bb7450c 100644
--- a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
+++ b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
@@ -27,6 +27,14 @@ Optional properties:
  'vddmac'.
  Default value is 0%.
  Ref: Table:1 - Edge rate change (below).
+- vsc8531,led-0-mode   : LED mode. Specify how the LED[0] should behave.
+ Allowed values are define in
+ "include/dt-bindings/net/mscc-phy-vsc8531.h".
+ Default value is 1.
+- vsc8531,led-1-mode   : LED mode. Specify how the LED[1] should behave.
+ Allowed values are define in
+ "include/dt-bindings/net/mscc-phy-vsc8531.h".
+ Default value is 2.
 
 Table: 1 - Edge rate change
 |
@@ -60,4 +68,6 @@ Example:
 compatible = "ethernet-phy-id0007.0570";
 vsc8531,vddmac = <3300>;
 vsc8531,edge-slowdown  = <7>;
+vsc8531,led-0-mode = ;
+vsc8531,led-1-mode = ;
 };
diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c
index e03ead8..3d2f3be 100644
--- a/drivers/net/phy/mscc.c
+++ b/drivers/net/phy/mscc.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 enum rgmii_rx_clock_delay {
RGMII_RX_CLK_DELAY_0_2_NS = 0,
@@ -52,6 +53,11 @@ enum rgmii_rx_clock_delay {
 #define MSCC_PHY_DEV_AUX_CNTL28
 #define HP_AUTO_MDIX_X_OVER_IND_MASK 0x2000
 
+#define MSCC_PHY_LED_MODE_SEL29
+#define LED_1_MODE_SEL_MASK  0x00F0
+#define LED_0_MODE_SEL_MASK  0x000F
+#define LED_1_MODE_SEL_POS   4
+
 #define MSCC_EXT_PAGE_ACCESS 31
 #define MSCC_PHY_PAGE_STANDARD   0x /* Standard registers */
 #define MSCC_PHY_PAGE_EXTENDED   0x0001 /* Extended registers */
@@ -99,6 +105,8 @@ enum rgmii_rx_clock_delay {
 
 struct vsc8531_private {
int rate_magic;
+   u8 led_0_mode;
+   u8 led_1_mode;
 };
 
 #ifdef CONFIG_OF_MDIO
@@ -123,6 +131,29 @@ static int vsc85xx_phy_page_set(struct phy_device *phydev, 
u8 page)
return rc;
 }
 
+static int vsc85xx_led_cntl_set(struct phy_device *phydev,
+   u8 led_num,
+   u8 mode)
+{
+   int rc;
+   u16 reg_val;
+
+   mutex_lock(>lock);
+   reg_val = phy_read(phydev, MSCC_PHY_LED_MODE_SEL);
+   if (led_num) {
+   reg_val &= ~LED_1_MODE_SEL_MASK;
+   reg_val |= (((u16)mode << LED_1_MODE_SEL_POS) &
+   LED_1_MODE_SEL_MASK);
+   } else {
+   reg_val &= ~LED_0_MODE_SEL_MASK;
+   reg_val |= ((u16)mode & LED_0_MODE_SEL_MASK);
+   }
+   rc = phy_write(phydev, MSCC_PHY_LED_MODE_SEL, reg_val);
+   mutex_unlock(>lock);
+
+   return rc;
+}
+
 static int vsc85xx_mdix_get(struct phy_device *phydev, u8 *mdix)
 {
u16 reg_val;
@@ -370,11 +401,43 @@ static int vsc85xx_edge_rate_magic_get(struct phy_device 
*phydev)
 
return -EINVAL;
 }
+
+static int vsc85xx_dt_led_mode_get(struct phy_device *phydev,
+  char *led,
+  u8 default_mode)
+{
+   struct device *dev = >mdio.dev;
+   struct device_node *of_node = dev->of_node;
+   u8 led_mode;
+   int rc;
+
+   if (!of_node)
+   return -ENODEV;
+
+   rc = of_property_read_u8(of_node, led, _mode);
+   if ((rc == 0) &&
+   ((led_mode > 15) || (led_mode == 7) || (led_mode == 11))) {
+   phydev_err(phydev, "DT %s invalid\n", led);
+   return -EINVAL;
+   } else if (rc == -EINVAL) {
+   return default_mode;
+   }
+
+   return led_mode;
+}
+
 #else
 static int vsc85xx_edge_rate_magic_get(struct phy_device *phydev)
 {
return 0;
 }
+
+static int vsc85xx_led_mode_get(struct phy_device *phydev,
+   char *dt_str,
+   

Re: [PATCH net] net: phy: Fix lack of reference count on PHY driver

[Russell King - ARM Linux]

On Wed, Feb 01, 2017 at 10:22:08AM +, Russell King - ARM Linux wrote:
> On Tue, Jan 31, 2017 at 06:46:43PM -0800, Florian Fainelli wrote:
> > From: Mao Wenan 
> > 
> > There is currently no reference count being held on the PHY driver,
> > which makes it possible to remove the PHY driver module while the PHY
> > state machine is running and polling the PHY. This could cause crashes
> > similar to this one to show up:
> 
> Does this really solve the problem?  What if you use sysfs to unbind the
> driver but without removing the module?

I think that's a problem, and the patch is just solving a symptom of
it.

If a phy driver is unbound from a device, phy_remove() will be called.
This will set the state to PHY_DOWN (under the mutex) before calling
the driver's remove function (if any), and finally setting phydev->drv
to NULL.

If phy_state_machine() is called after that point, then:

void phy_state_machine(struct work_struct *work)
{
...
if (phydev->drv->link_change_notify)
phydev->drv->link_change_notify(phydev);

which happens unconditionally, causes a NULL pointer dereference, which
is probably the same NULL pointer dereference given in Mao Wenan's patch
description.

It looks to me as if that's the only case where this can happen, so maybe
the above needs to be:

if (phydev->drv && phydev->drv->link_change_notify)
phydev->drv->link_change_notify(phydev);

Also, I'd suggest making sure that the workqueue is flushed in
phy_remove() after setting phydev->drv to NULL to ensure that the
workqueue isn't running while the phy driver is being unbound, which
should also make module removal safe(r).  I haven't fully analysed
that though.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Bitte kontaktieren Sie mich für weitere Details!

[Miss Marbell]

Sehr geehrte Damen und Herren,

Ich brauche Ihre Unterstützung in Ihrem Land zu verlagern und zu 
investieren.Ich bitte Sie um Hilfe, weil ich nicht das Wissen über
Geschäft und die Regeln, die Ihr Land für eine sichere Investition führen.

Werden Sie versprechen, mit mir aufrichtig zu sein?

Bitte kontaktieren Sie mich für weitere Details!

Mit freundlichen Grüßen,
Fräulein Marbell.