* Re: Bug w/ (policy) routing
From: Olivier Brunel @ 2017-01-02 17:05 UTC (permalink / raw)
To: David Ahern; +Cc: netdev
In-Reply-To: <c59bcb99-39d1-3b47-7787-dd4d805eb4f6@cumulusnetworks.com>
On Mon, 2 Jan 2017 09:48:12 -0700
David Ahern <dsa@cumulusnetworks.com> wrote:
> On 1/1/17 12:52 PM, Olivier Brunel wrote:
> > Indeed, if I first delete the rule for lookup local and recreate it
> > w/ higher prio than my "lookup 50", then no more issue.
>
> After the unshare or when creating a new network namespace, bringing
> the lo device up will create the local table and the rest of the
> commands will work properly. ie., instead of moving the local rule
> you can run:
Indeed, and that's a much better solution for me, since I bring lo up
anyways, I might as well do it first. Thank you.
> unshare -n bash
>
> ip li set lo up
> ip rule add table 50 prio 50
> ip link add test type veth peer name test2
> ...
>
> -----
>
> Alex:
>
> The order of commands is influencing whether the unmerge succeeds or
> not which is wrong. I took a quick look and I don't see a simple
> solution to this. Effectively:
>
> Adding a rule before bringing up any interface does not unmerge the
> tables: $ unshare -n bash
> $ ip rule add table 50 prio 50
> $ ip li set lo up
>
> In fib_unmerge(), fib_new_table(net, RT_TABLE_LOCAL) returns null.
>
>
> Where the reverse order works:
> $ unshare -n bash
> $ ip li set lo up
> $ ip rule add table 50 prio 50
>
> David
^ permalink raw reply
* Re: Bug w/ (policy) routing
From: David Ahern @ 2017-01-02 16:48 UTC (permalink / raw)
To: Olivier Brunel; +Cc: netdev, Alexander Duyck
In-Reply-To: <20170101205238.426803f4@jjacky.com>
On 1/1/17 12:52 PM, Olivier Brunel wrote:
> Indeed, if I first delete the rule for lookup local and recreate it
> w/ higher prio than my "lookup 50", then no more issue.
After the unshare or when creating a new network namespace, bringing the lo device up will create the local table and the rest of the commands will work properly. ie., instead of moving the local rule you can run:
unshare -n bash
ip li set lo up
ip rule add table 50 prio 50
ip link add test type veth peer name test2
...
-----
Alex:
The order of commands is influencing whether the unmerge succeeds or not which is wrong. I took a quick look and I don't see a simple solution to this. Effectively:
Adding a rule before bringing up any interface does not unmerge the tables:
$ unshare -n bash
$ ip rule add table 50 prio 50
$ ip li set lo up
In fib_unmerge(), fib_new_table(net, RT_TABLE_LOCAL) returns null.
Where the reverse order works:
$ unshare -n bash
$ ip li set lo up
$ ip rule add table 50 prio 50
David
^ permalink raw reply
* [PATCH] net: emulex: benet: use new api ethtool_{get|set}_link_ksettings
From: Philippe Reynes @ 2017-01-02 16:42 UTC (permalink / raw)
To: sathya.perla, ajit.khaparde, sriharsha.basavapatna, somnath.kotur,
davem
Cc: netdev, linux-kernel, Philippe Reynes
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.
Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
---
drivers/net/ethernet/emulex/benet/be_ethtool.c | 73 +++++++++++-------------
1 files changed, 34 insertions(+), 39 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_ethtool.c b/drivers/net/ethernet/emulex/benet/be_ethtool.c
index 0a48a31..7d1819c 100644
--- a/drivers/net/ethernet/emulex/benet/be_ethtool.c
+++ b/drivers/net/ethernet/emulex/benet/be_ethtool.c
@@ -606,7 +606,8 @@ bool be_pause_supported(struct be_adapter *adapter)
false : true;
}
-static int be_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
+static int be_get_link_ksettings(struct net_device *netdev,
+ struct ethtool_link_ksettings *cmd)
{
struct be_adapter *adapter = netdev_priv(netdev);
u8 link_status;
@@ -614,13 +615,14 @@ static int be_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
int status;
u32 auto_speeds;
u32 fixed_speeds;
+ u32 supported = 0, advertising = 0;
if (adapter->phy.link_speed < 0) {
status = be_cmd_link_status_query(adapter, &link_speed,
&link_status, 0);
if (!status)
be_link_status_update(adapter, link_status);
- ethtool_cmd_speed_set(ecmd, link_speed);
+ cmd->base.speed = link_speed;
status = be_cmd_get_phy_info(adapter);
if (!status) {
@@ -629,58 +631,51 @@ static int be_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
be_cmd_query_cable_type(adapter);
- ecmd->supported =
+ supported =
convert_to_et_setting(adapter,
auto_speeds |
fixed_speeds);
- ecmd->advertising =
+ advertising =
convert_to_et_setting(adapter, auto_speeds);
- ecmd->port = be_get_port_type(adapter);
+ cmd->base.port = be_get_port_type(adapter);
if (adapter->phy.auto_speeds_supported) {
- ecmd->supported |= SUPPORTED_Autoneg;
- ecmd->autoneg = AUTONEG_ENABLE;
- ecmd->advertising |= ADVERTISED_Autoneg;
+ supported |= SUPPORTED_Autoneg;
+ cmd->base.autoneg = AUTONEG_ENABLE;
+ advertising |= ADVERTISED_Autoneg;
}
- ecmd->supported |= SUPPORTED_Pause;
+ supported |= SUPPORTED_Pause;
if (be_pause_supported(adapter))
- ecmd->advertising |= ADVERTISED_Pause;
-
- switch (adapter->phy.interface_type) {
- case PHY_TYPE_KR_10GB:
- case PHY_TYPE_KX4_10GB:
- ecmd->transceiver = XCVR_INTERNAL;
- break;
- default:
- ecmd->transceiver = XCVR_EXTERNAL;
- break;
- }
+ advertising |= ADVERTISED_Pause;
} else {
- ecmd->port = PORT_OTHER;
- ecmd->autoneg = AUTONEG_DISABLE;
- ecmd->transceiver = XCVR_DUMMY1;
+ cmd->base.port = PORT_OTHER;
+ cmd->base.autoneg = AUTONEG_DISABLE;
}
/* Save for future use */
- adapter->phy.link_speed = ethtool_cmd_speed(ecmd);
- adapter->phy.port_type = ecmd->port;
- adapter->phy.transceiver = ecmd->transceiver;
- adapter->phy.autoneg = ecmd->autoneg;
- adapter->phy.advertising = ecmd->advertising;
- adapter->phy.supported = ecmd->supported;
+ adapter->phy.link_speed = cmd->base.speed;
+ adapter->phy.port_type = cmd->base.port;
+ adapter->phy.autoneg = cmd->base.autoneg;
+ adapter->phy.advertising = advertising;
+ adapter->phy.supported = supported;
} else {
- ethtool_cmd_speed_set(ecmd, adapter->phy.link_speed);
- ecmd->port = adapter->phy.port_type;
- ecmd->transceiver = adapter->phy.transceiver;
- ecmd->autoneg = adapter->phy.autoneg;
- ecmd->advertising = adapter->phy.advertising;
- ecmd->supported = adapter->phy.supported;
+ cmd->base.speed = adapter->phy.link_speed;
+ cmd->base.port = adapter->phy.port_type;
+ cmd->base.autoneg = adapter->phy.autoneg;
+ advertising = adapter->phy.advertising;
+ supported = adapter->phy.supported;
}
- ecmd->duplex = netif_carrier_ok(netdev) ? DUPLEX_FULL : DUPLEX_UNKNOWN;
- ecmd->phy_address = adapter->port_num;
+ cmd->base.duplex = netif_carrier_ok(netdev) ?
+ DUPLEX_FULL : DUPLEX_UNKNOWN;
+ cmd->base.phy_address = adapter->port_num;
+
+ ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.supported,
+ supported);
+ ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.advertising,
+ advertising);
return 0;
}
@@ -1399,7 +1394,6 @@ static int be_set_priv_flags(struct net_device *netdev, u32 flags)
}
const struct ethtool_ops be_ethtool_ops = {
- .get_settings = be_get_settings,
.get_drvinfo = be_get_drvinfo,
.get_wol = be_get_wol,
.set_wol = be_set_wol,
@@ -1433,5 +1427,6 @@ static int be_set_priv_flags(struct net_device *netdev, u32 flags)
.get_channels = be_get_channels,
.set_channels = be_set_channels,
.get_module_info = be_get_module_info,
- .get_module_eeprom = be_get_module_eeprom
+ .get_module_eeprom = be_get_module_eeprom,
+ .get_link_ksettings = be_get_link_ksettings,
};
--
1.7.4.4
^ permalink raw reply related
* Re: [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM.
From: Richard Cochran @ 2017-01-02 16:13 UTC (permalink / raw)
To: Nicolas Ferre
Cc: Rafal Ozieblo, Andrei Pistirica, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, davem@davemloft.net,
harinikatakamlinux@gmail.com, harini.katakam@xilinx.com,
punnaia@xilinx.com, michals@xilinx.com, anirudh@xilinx.com,
boris.brezillon@free-electrons.com,
alexandre.belloni@free-electrons.com, tbultel@pixelsurmer.com
In-Reply-To: <0717c63b-2e29-9ad1-7f01-39817980933f@atmel.com>
On Mon, Jan 02, 2017 at 03:47:07PM +0100, Nicolas Ferre wrote:
> Le 02/01/2017 à 12:31, Richard Cochran a écrit :
> > This Cadence IP core is a complete disaster.
>
> Well, it evolved and propose several options to different SoC
> integrators. This is not something unusual...
> I suspect as well that some other network adapters have the same
> weakness concerning PTP timestamp in single register as the early
> revisions of this IP.
It appears that this core can neither latch the time on read or write,
or even latch time stamps. I have worked with many different PTP HW
implementations, even early ones like on the ixp4xx, and it is no
exaggeration to say that this one is uniquely broken.
> I suspect that Rafal tend to jump too quickly to the latest IP revisions
> and add more options to this series: let's not try to pour too much
> things into this code right now.
Why can't you check the IP version in the driver?
And is it really true that the registers don't latch the time stamps,
as Rafal said? If so, then we cannot accept the non-descriptor driver
version, since it cannot possibly work correctly.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH net-next rfc 0/6] convert tc_verd to integer bitfields
From: Jamal Hadi Salim @ 2017-01-02 16:09 UTC (permalink / raw)
To: Willem de Bruijn, netdev
Cc: davem, fw, dborkman, alexei.starovoitov, Willem de Bruijn,
Roman Mashak, Hannes Frederic Sowa, Shmulik Ladkani
In-Reply-To: <1482952410-50003-1-git-send-email-willemdebruijn.kernel@gmail.com>
And a happy new year netdev.
No objections to new year resolution of slimming the skb.
But: i am still concerned about the recursion that getting rid of
some of these bits could embolden. i.e my suggestion was infact to
restore some of those bits taken away by Florian after the ingress
redirect patches from Shmulik.
The possibilities are: egress->egress, egress->ingress,
ingress->egress, ingress->ingress. The suggestion was
xmit_recursion with some skb magic would suffice.
Hannes promised around last netdevconf that he has a scheme to solve
it without using any extra skb state.
cheers,
jamal
On 16-12-28 02:13 PM, Willem de Bruijn wrote:
> From: Willem de Bruijn <willemb@google.com>
>
> The skb tc_verd field takes up two bytes but uses far fewer bits.
> Convert the remaining use cases to bitfields that fit in existing
> holes (depending on config options) and potentially save the two
> bytes in struct sk_buff.
>
> This patchset is based on an earlier set by Florian Westphal and its
> discussion (http://www.spinics.net/lists/netdev/msg329181.html).
>
> Patches 1 and 2 are low hanging fruit: removing the last traces of
> data that are no longer stored in tc_verd.
>
> Patches 3 and 4 convert tc_verd to individual bitfields (5 bits).
>
> Patch 5 reduces TC_AT to a single bitfield,
> as AT_STACK is not valid here (unlike in the case of TC_FROM).
>
> Patch 6 changes TC_FROM to two bitfields with clearly defined purpose.
>
> It may be possible to reduce storage further after this initial round.
> If tc_skip_classify is set only by IFB, testing skb_iif may suffice.
> The L2 header pushing/popping logic can perhaps be shared with
> AF_PACKET, which currently not pkt_type for the same purpose.
>
> Tested ingress mirred + netem + ifb:
>
> ip link set dev ifb0 up
> tc qdisc add dev eth0 ingress
> tc filter add dev eth0 parent ffff: \
> u32 match ip dport 8000 0xffff \
> action mirred egress redirect dev ifb0
> tc qdisc add dev ifb0 root netem delay 1000ms
> nc -u -l 8000 &
> ssh $otherhost nc -u $host 8000
>
> Tested egress mirred:
>
> ip link add veth1 type veth peer name veth2
> ip link set dev veth1 up
> ip link set dev veth2 up
> tcpdump -n -i veth2 udp and dst port 8000 &
>
> tc qdisc add dev eth0 root handle 1: prio
> tc filter add dev eth0 parent 1:0 \
> u32 match ip dport 8000 0xffff \
> action mirred egress redirect dev veth1
> tc qdisc add dev veth1 root netem delay 1000ms
> nc -u $otherhost 8000
>
> Willem de Bruijn (6):
> net-tc: remove unused tc_verd fields
> net-tc: make MAX_RECLASSIFY_LOOP local
> net-tc: extract skip classify bit from tc_verd
> net-tc: convert tc_verd to integer bitfields
> net-tc: convert tc_at to tc_at_ingress
> net-tc: convert tc_from to tc_from_ingress and tc_redirected
>
> drivers/net/ifb.c | 16 ++++-------
> drivers/staging/octeon/ethernet-tx.c | 5 ++--
> include/linux/skbuff.h | 15 ++++++----
> include/net/sch_generic.h | 20 ++++++++++++-
> include/uapi/linux/pkt_cls.h | 55 ------------------------------------
> net/core/dev.c | 20 ++++---------
> net/core/pktgen.c | 4 +--
> net/core/skbuff.c | 3 --
> net/sched/act_api.c | 8 ++----
> net/sched/act_ife.c | 7 ++---
> net/sched/act_mirred.c | 21 +++++++-------
> net/sched/sch_api.c | 4 ++-
> net/sched/sch_netem.c | 2 +-
> 13 files changed, 64 insertions(+), 116 deletions(-)
>
^ permalink raw reply
* Re: [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM.
From: Richard Cochran @ 2017-01-02 16:03 UTC (permalink / raw)
To: Harini Katakam
Cc: Rafal Ozieblo, Andrei Pistirica, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, davem@davemloft.net,
nicolas.ferre@atmel.com, harini.katakam@xilinx.com,
punnaia@xilinx.com, michals@xilinx.com, anirudh@xilinx.com,
boris.brezillon@free-electrons.com,
alexandre.belloni@free-electrons.com, tbultel@pixelsurmer.com
In-Reply-To: <CAFcVECLg-hXvfgwRW-fxi+N0k=7pTaEMhS5EMXV9_OO+xGRUqA@mail.gmail.com>
On Mon, Jan 02, 2017 at 05:13:34PM +0530, Harini Katakam wrote:
> From the revision history of Cadence spec, all versions starting
> r1p02 have ability to include timestamp in descriptors.
So why not add code to read the version, hm?
> For previous versions the event register is the only option.
And is it true that the regsiters do not latch the time stamp?
If so, then the IP core is more than useless.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH] rfkill: remove rfkill-regulator
From: Johannes Berg @ 2017-01-02 15:03 UTC (permalink / raw)
To: linux-wireless
Cc: netdev, Guiming Zhuo, Antonio Ospite, Paul Cercueil, Rob Herring,
Maarten ter Huurne
In-Reply-To: <20170102150157.26745-1-johannes@sipsolutions.net>
On Mon, 2017-01-02 at 16:01 +0100, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> There are no users of this ("vrfkill") in the tree, so it's just
> dead code - remove it.
>
> This also isn't really how rfkill is supposed to be used - it's
> intended as a signalling mechanism to/from the device, which the
> driver (and partially cfg80211) will handle - having a separate
> rfkill instance for a regulator is confusing, the driver should
> use the regulator instead to turn off the device when requested.
OTOH, the rfkill-gpio is essentially the same thing, and it *does* get
used - by ACPI even, to control a GPS chip. And I'm not even sure that
there's a clear place to put this since there probably aren't any GPS
drivers?
johannes
^ permalink raw reply
* Re: [PATCH net 0/3] net: stmmac: dwmac-oxnas: fix leaks and simplify pm
From: Neil Armstrong @ 2017-01-02 15:03 UTC (permalink / raw)
To: Johan Hovold, David S. Miller
Cc: Giuseppe Cavallaro, Alexandre Torgue, netdev, linux-oxnas,
linux-kernel
In-Reply-To: <20170102115604.32482-1-johan@kernel.org>
On 01/02/2017 12:56 PM, Johan Hovold wrote:
> These patches fixes of-node and fixed-phydev leaks in the recently added
> dwmac-oxnas driver, and ultimately switches over to using the generic pm
> implementation as the required callbacks are now in place.
>
> Note that this series has only been compile tested.
>
> Johan
>
>
> Johan Hovold (3):
> net: stmmac: dwmac-oxnas: fix of-node leak
> net: stmmac: dwmac-oxnas: fix fixed-link-phydev leaks
> net: stmmac: dwmac-oxnas: use generic pm implementation
>
> drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c | 89 +++++++++--------------
> 1 file changed, 33 insertions(+), 56 deletions(-)
>
Hi Johan,
This series looks good, I will (hopefully) send a Tested-by in the next few days.
Thanks,
Neil
^ permalink raw reply
* [PATCH] rfkill: remove rfkill-regulator
From: Johannes Berg @ 2017-01-02 15:01 UTC (permalink / raw)
To: linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Guiming Zhuo, Antonio Ospite,
Paul Cercueil, Rob Herring, Maarten ter Huurne, Johannes Berg
From: Johannes Berg <johannes.berg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
There are no users of this ("vrfkill") in the tree, so it's just
dead code - remove it.
This also isn't really how rfkill is supposed to be used - it's
intended as a signalling mechanism to/from the device, which the
driver (and partially cfg80211) will handle - having a separate
rfkill instance for a regulator is confusing, the driver should
use the regulator instead to turn off the device when requested.
Signed-off-by: Johannes Berg <johannes.berg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
include/linux/rfkill-regulator.h | 48 ------------
net/rfkill/Kconfig | 11 ---
net/rfkill/Makefile | 1 -
net/rfkill/rfkill-regulator.c | 154 ---------------------------------------
4 files changed, 214 deletions(-)
delete mode 100644 include/linux/rfkill-regulator.h
delete mode 100644 net/rfkill/rfkill-regulator.c
diff --git a/include/linux/rfkill-regulator.h b/include/linux/rfkill-regulator.h
deleted file mode 100644
index aca36bc83315..000000000000
--- a/include/linux/rfkill-regulator.h
+++ /dev/null
@@ -1,48 +0,0 @@
-/*
- * rfkill-regulator.c - Regulator consumer driver for rfkill
- *
- * Copyright (C) 2009 Guiming Zhuo <gmzhuo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
- * Copyright (C) 2011 Antonio Ospite <ospite-aNJ+ML1ZbiP93QAQaVx+gl6hYfS7NtTn@public.gmane.org>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- */
-
-#ifndef __LINUX_RFKILL_REGULATOR_H
-#define __LINUX_RFKILL_REGULATOR_H
-
-/*
- * Use "vrfkill" as supply id when declaring the regulator consumer:
- *
- * static struct regulator_consumer_supply pcap_regulator_V6_consumers [] = {
- * { .dev_name = "rfkill-regulator.0", .supply = "vrfkill" },
- * };
- *
- * If you have several regulator driven rfkill, you can append a numerical id to
- * .dev_name as done above, and use the same id when declaring the platform
- * device:
- *
- * static struct rfkill_regulator_platform_data ezx_rfkill_bt_data = {
- * .name = "ezx-bluetooth",
- * .type = RFKILL_TYPE_BLUETOOTH,
- * };
- *
- * static struct platform_device a910_rfkill = {
- * .name = "rfkill-regulator",
- * .id = 0,
- * .dev = {
- * .platform_data = &ezx_rfkill_bt_data,
- * },
- * };
- */
-
-#include <linux/rfkill.h>
-
-struct rfkill_regulator_platform_data {
- char *name; /* the name for the rfkill switch */
- enum rfkill_type type; /* the type as specified in rfkill.h */
-};
-
-#endif /* __LINUX_RFKILL_REGULATOR_H */
diff --git a/net/rfkill/Kconfig b/net/rfkill/Kconfig
index 868f1ad0415a..060600b03fad 100644
--- a/net/rfkill/Kconfig
+++ b/net/rfkill/Kconfig
@@ -23,17 +23,6 @@ config RFKILL_INPUT
depends on INPUT = y || RFKILL = INPUT
default y if !EXPERT
-config RFKILL_REGULATOR
- tristate "Generic rfkill regulator driver"
- depends on RFKILL || !RFKILL
- depends on REGULATOR
- help
- This options enable controlling radio transmitters connected to
- voltage regulator using the regulator framework.
-
- To compile this driver as a module, choose M here: the module will
- be called rfkill-regulator.
-
config RFKILL_GPIO
tristate "GPIO RFKILL driver"
depends on RFKILL
diff --git a/net/rfkill/Makefile b/net/rfkill/Makefile
index 311768783f4a..87a80aded0b3 100644
--- a/net/rfkill/Makefile
+++ b/net/rfkill/Makefile
@@ -5,5 +5,4 @@
rfkill-y += core.o
rfkill-$(CONFIG_RFKILL_INPUT) += input.o
obj-$(CONFIG_RFKILL) += rfkill.o
-obj-$(CONFIG_RFKILL_REGULATOR) += rfkill-regulator.o
obj-$(CONFIG_RFKILL_GPIO) += rfkill-gpio.o
diff --git a/net/rfkill/rfkill-regulator.c b/net/rfkill/rfkill-regulator.c
deleted file mode 100644
index 50cd26a48e87..000000000000
--- a/net/rfkill/rfkill-regulator.c
+++ /dev/null
@@ -1,154 +0,0 @@
-/*
- * rfkill-regulator.c - Regulator consumer driver for rfkill
- *
- * Copyright (C) 2009 Guiming Zhuo <gmzhuo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
- * Copyright (C) 2011 Antonio Ospite <ospite-aNJ+ML1ZbiP93QAQaVx+gl6hYfS7NtTn@public.gmane.org>
- *
- * Implementation inspired by leds-regulator driver.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- */
-
-#include <linux/module.h>
-#include <linux/err.h>
-#include <linux/slab.h>
-#include <linux/platform_device.h>
-#include <linux/regulator/consumer.h>
-#include <linux/rfkill.h>
-#include <linux/rfkill-regulator.h>
-
-struct rfkill_regulator_data {
- struct rfkill *rf_kill;
- bool reg_enabled;
-
- struct regulator *vcc;
-};
-
-static int rfkill_regulator_set_block(void *data, bool blocked)
-{
- struct rfkill_regulator_data *rfkill_data = data;
- int ret = 0;
-
- pr_debug("%s: blocked: %d\n", __func__, blocked);
-
- if (blocked) {
- if (rfkill_data->reg_enabled) {
- regulator_disable(rfkill_data->vcc);
- rfkill_data->reg_enabled = false;
- }
- } else {
- if (!rfkill_data->reg_enabled) {
- ret = regulator_enable(rfkill_data->vcc);
- if (!ret)
- rfkill_data->reg_enabled = true;
- }
- }
-
- pr_debug("%s: regulator_is_enabled after set_block: %d\n", __func__,
- regulator_is_enabled(rfkill_data->vcc));
-
- return ret;
-}
-
-static struct rfkill_ops rfkill_regulator_ops = {
- .set_block = rfkill_regulator_set_block,
-};
-
-static int rfkill_regulator_probe(struct platform_device *pdev)
-{
- struct rfkill_regulator_platform_data *pdata = pdev->dev.platform_data;
- struct rfkill_regulator_data *rfkill_data;
- struct regulator *vcc;
- struct rfkill *rf_kill;
- int ret = 0;
-
- if (pdata == NULL) {
- dev_err(&pdev->dev, "no platform data\n");
- return -ENODEV;
- }
-
- if (pdata->name == NULL || pdata->type == 0) {
- dev_err(&pdev->dev, "invalid name or type in platform data\n");
- return -EINVAL;
- }
-
- vcc = regulator_get_exclusive(&pdev->dev, "vrfkill");
- if (IS_ERR(vcc)) {
- dev_err(&pdev->dev, "Cannot get vcc for %s\n", pdata->name);
- ret = PTR_ERR(vcc);
- goto out;
- }
-
- rfkill_data = kzalloc(sizeof(*rfkill_data), GFP_KERNEL);
- if (rfkill_data == NULL) {
- ret = -ENOMEM;
- goto err_data_alloc;
- }
-
- rf_kill = rfkill_alloc(pdata->name, &pdev->dev,
- pdata->type,
- &rfkill_regulator_ops, rfkill_data);
- if (rf_kill == NULL) {
- ret = -ENOMEM;
- goto err_rfkill_alloc;
- }
-
- if (regulator_is_enabled(vcc)) {
- dev_dbg(&pdev->dev, "Regulator already enabled\n");
- rfkill_data->reg_enabled = true;
- }
- rfkill_data->vcc = vcc;
- rfkill_data->rf_kill = rf_kill;
-
- ret = rfkill_register(rf_kill);
- if (ret) {
- dev_err(&pdev->dev, "Cannot register rfkill device\n");
- goto err_rfkill_register;
- }
-
- platform_set_drvdata(pdev, rfkill_data);
- dev_info(&pdev->dev, "%s initialized\n", pdata->name);
-
- return 0;
-
-err_rfkill_register:
- rfkill_destroy(rf_kill);
-err_rfkill_alloc:
- kfree(rfkill_data);
-err_data_alloc:
- regulator_put(vcc);
-out:
- return ret;
-}
-
-static int rfkill_regulator_remove(struct platform_device *pdev)
-{
- struct rfkill_regulator_data *rfkill_data = platform_get_drvdata(pdev);
- struct rfkill *rf_kill = rfkill_data->rf_kill;
-
- rfkill_unregister(rf_kill);
- rfkill_destroy(rf_kill);
- regulator_put(rfkill_data->vcc);
- kfree(rfkill_data);
-
- return 0;
-}
-
-static struct platform_driver rfkill_regulator_driver = {
- .probe = rfkill_regulator_probe,
- .remove = rfkill_regulator_remove,
- .driver = {
- .name = "rfkill-regulator",
- },
-};
-
-module_platform_driver(rfkill_regulator_driver);
^ permalink raw reply related
* Re: [PATCH net-next] net/sched: cls_flower: Add user specified data
From: Jamal Hadi Salim @ 2017-01-02 14:59 UTC (permalink / raw)
To: Paul Blakey, David S. Miller, netdev
Cc: Jiri Pirko, Hadar Hen Zion, Or Gerlitz, Roi Dayan, Roman Mashak
In-Reply-To: <1483362833-52114-1-git-send-email-paulb@mellanox.com>
We have been using a cookie as well for actions (which we have been
using but have been too lazy to submit so far). I am going to port
it over to the newer kernels and post it.
In our case that is intended to be opaque to the kernel i.e kernel
never inteprets it; in that case it is similar to the kernel
FIB protocol field.
In your case - could this cookie have been a class/flowid
(a 32 bit)?
And would it not make more sense for it the cookie to be
generic to all classifiers? i.e why is it specific to flower?
cheers,
jamal
On 17-01-02 08:13 AM, Paul Blakey wrote:
> This is to support saving extra data that might be helpful on retrieval.
> First use case is upcoming openvswitch flow offloads, extra data will
> include UFID and port mappings for each added flow.
>
> Signed-off-by: Paul Blakey <paulb@mellanox.com>
> Reviewed-by: Roi Dayan <roid@mellanox.com>
> Acked-by: Jiri Pirko <jiri@mellanox.com>
> ---
> include/uapi/linux/pkt_cls.h | 3 +++
> net/sched/cls_flower.c | 22 +++++++++++++++++++++-
> 2 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
> index cb4bcdc..ca9bbe3 100644
> --- a/include/uapi/linux/pkt_cls.h
> +++ b/include/uapi/linux/pkt_cls.h
> @@ -471,10 +471,13 @@ enum {
> TCA_FLOWER_KEY_ICMPV6_TYPE, /* u8 */
> TCA_FLOWER_KEY_ICMPV6_TYPE_MASK,/* u8 */
>
> + TCA_FLOWER_COOKIE, /* binary */
> +
> __TCA_FLOWER_MAX,
> };
>
> #define TCA_FLOWER_MAX (__TCA_FLOWER_MAX - 1)
> +#define FLOWER_MAX_COOKIE_SIZE 128
>
> enum {
> TCA_FLOWER_KEY_FLAGS_IS_FRAGMENT = (1 << 0),
> diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
> index 333f8e2..e2f5b25 100644
> --- a/net/sched/cls_flower.c
> +++ b/net/sched/cls_flower.c
> @@ -85,6 +85,8 @@ struct cls_fl_filter {
> struct rcu_head rcu;
> struct tc_to_netdev tc;
> struct net_device *hw_dev;
> + size_t cookie_len;
> + long cookie[0];
> };
>
> static unsigned short int fl_mask_range(const struct fl_flow_mask *mask)
> @@ -794,6 +796,9 @@ static int fl_change(struct net *net, struct sk_buff *in_skb,
> struct cls_fl_filter *fnew;
> struct nlattr *tb[TCA_FLOWER_MAX + 1];
> struct fl_flow_mask mask = {};
> + const struct nlattr *attr;
> + size_t cookie_len = 0;
> + void *cookie;
> int err;
>
> if (!tca[TCA_OPTIONS])
> @@ -806,10 +811,22 @@ static int fl_change(struct net *net, struct sk_buff *in_skb,
> if (fold && handle && fold->handle != handle)
> return -EINVAL;
>
> - fnew = kzalloc(sizeof(*fnew), GFP_KERNEL);
> + if (tb[TCA_FLOWER_COOKIE]) {
> + attr = tb[TCA_FLOWER_COOKIE];
> + cookie_len = nla_len(attr);
> + cookie = nla_data(attr);
> + if (cookie_len > FLOWER_MAX_COOKIE_SIZE)
> + return -EINVAL;
> + }
> +
> + fnew = kzalloc(sizeof(*fnew) + cookie_len, GFP_KERNEL);
> if (!fnew)
> return -ENOBUFS;
>
> + fnew->cookie_len = cookie_len;
> + if (cookie_len)
> + memcpy(fnew->cookie, cookie, cookie_len);
> +
> err = tcf_exts_init(&fnew->exts, TCA_FLOWER_ACT, 0);
> if (err < 0)
> goto errout;
> @@ -1151,6 +1168,9 @@ static int fl_dump(struct net *net, struct tcf_proto *tp, unsigned long fh,
>
> nla_put_u32(skb, TCA_FLOWER_FLAGS, f->flags);
>
> + if (f->cookie_len)
> + nla_put(skb, TCA_FLOWER_COOKIE, f->cookie_len, f->cookie);
> +
> if (tcf_exts_dump(skb, &f->exts))
> goto nla_put_failure;
>
>
^ permalink raw reply
* Re: [PATCH 1/2] Documentation: devicetree: Add bindings info for rfkill-regulator
From: Johannes Berg @ 2017-01-02 14:57 UTC (permalink / raw)
To: Rob Herring, Paul Cercueil
Cc: David S . Miller, Mark Rutland, netdev, devicetree, linux-kernel,
linux-wireless, Maarten ter Huurne
In-Reply-To: <20161109182612.i4rnsdxulk5ghemz@rob-hp-laptop>
> My understanding is it is generally felt that using the regulator
> enable GPIO commonly found on WiFi chips for rfkill is an abuse of
> rfkill as it is more that just an RF disable. From a DT standpoint,
> this seems like creating a binding for what a Linux driver wants.
> Instead, I think this should be either a GPIO or GPIO regulator and
> the driver for the WiFi chip should decide whether or not to register
> that as an rfkill driver.
Sadly, there are two ways to use rfkill right now:
1) the more common, and correct, way of having rfkill be a control tied
to a specific wireless interface (wifi, BT, FM, GPS, NFC, ...), to both
report the hardware button state that might be tied to it, and to
control - centrally - the software state.
2) the platform way, which some ACPI based platforms do, which register
an rfkill instance, which often allows controlling in software the
hardware line that then toggles the hardware rfkill on the WiFi NIC.
It's not clear to me what this patch is trying to achieve. It seems a
bit like something else entirely, which would be using it to toggle the
power for a wifi device? I agree that doesn't seem appropriate, and
instead the driver could bind to the regulator and disable it when wifi
gets disabled (by rfkill or simply by taking all interfaces down.)
In fact, given that there are no in-tree users, I'm tempted to remove
the rfkill-regulator entirely. Thoughts?
johannes
^ permalink raw reply
* Re: [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM.
From: Nicolas Ferre @ 2017-01-02 14:47 UTC (permalink / raw)
To: Richard Cochran, Rafal Ozieblo
Cc: Andrei Pistirica, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, davem@davemloft.net,
harinikatakamlinux@gmail.com, harini.katakam@xilinx.com,
punnaia@xilinx.com, michals@xilinx.com, anirudh@xilinx.com,
boris.brezillon@free-electrons.com,
alexandre.belloni@free-electrons.com, tbultel@pixelsurmer.com
In-Reply-To: <20170102113155.GA16373@localhost.localdomain>
Le 02/01/2017 à 12:31, Richard Cochran a écrit :
> On Mon, Jan 02, 2017 at 09:36:10AM +0000, Rafal Ozieblo wrote:
>> According Cadence Hardware team:
>> "It is just that some customers prefer to have the time in the descriptors as that is provided per frame.
>> The registers are simply overwritten when a new event frame is transmitted/received and so software could miss it."
>> The question is are you sure that you read timestamp for current frame? (not for the next frame).
>
> AFAICT, having the time stamp in the descriptor is not universally
> supported. Looking at the Xilinx Zynq 7000 TRM, I can't find any
> mention of this.
This is why I proposed to address options incrementally: without
timestamp support in descriptor (this patch series), then adding this
feature in another patch series.
Rafal, this is why Andrei noted that the case covered by this series is
not adapted to GEM-GXL and doesn't address the "timestamp in descriptor"
case.
> This Cadence IP core is a complete disaster.
Well, it evolved and propose several options to different SoC
integrators. This is not something unusual...
I suspect as well that some other network adapters have the same
weakness concerning PTP timestamp in single register as the early
revisions of this IP.
> Unless someone can tell us how this IP works in all of its
> incarnations, this series is going nowhere.
We're already as v4 (thanks to your fruitful contributions BTW) for this
series and will try to add features for other IP options & revisions
incrementally.
I suspect that Rafal tend to jump too quickly to the latest IP revisions
and add more options to this series: let's not try to pour too much
things into this code right now.
FYI, Andrei will be back online next week.
Regards,
--
Nicolas Ferre
^ permalink raw reply
* pull-request: mac80211 2017-01-02
From: Johannes Berg @ 2017-01-02 14:39 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
Happy New Year :-)
Even though I was out for around two weeks, only a single fix came in,
I guess everyone else was also out. But if people were out, then they
won't be sending fixes soon again I suppose, and if they weren't out
they haven't sent more fixes, so I decided to send this one to you now.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit eb7903bb83cc1db31a9124d4cc8a1bddebe26e33:
Merge branch 'l2tp-socket-lookup-fixes' (2017-01-01 22:07:25 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2017-01-02
for you to fetch changes up to 35f432a03e41d3bf08c51ede917f94e2288fbe8c:
mac80211: initialize fast-xmit 'info' later (2017-01-02 11:28:25 +0100)
----------------------------------------------------------------
A single fix to avoid loading an skb->cb pointer too early.
----------------------------------------------------------------
Johannes Berg (1):
mac80211: initialize fast-xmit 'info' later
net/mac80211/tx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
^ permalink raw reply
* ATENCIÓN;
From: administrador @ 2017-01-02 13:56 UTC (permalink / raw)
To: Recipients
ATENCIÓN;
Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de correo electrónico. Para revalidar su buzón de correo, envíe la siguiente información a continuación:
nombre:
Nombre de usuario:
contraseña:
Confirmar contraseña:
E-mail:
teléfono:
Si usted no puede revalidar su buzón, el buzón se deshabilitará!
Disculpa las molestias.
Código de verificación: es: 006524
Correo Soporte Técnico © 2016
¡gracias
Sistemas administrador
^ permalink raw reply
* Re: [PATCH net-next 22/27] sctp: add rfc6525 section 5.2.4
From: Xin Long @ 2017-01-02 13:43 UTC (permalink / raw)
To: David Miller
Cc: kbuild test robot, kbuild-all, network dev, linux-sctp,
Marcelo Ricardo Leitner, Neil Horman
In-Reply-To: <20170101.113213.663892510185061837.davem@davemloft.net>
On Mon, Jan 2, 2017 at 12:32 AM, David Miller <davem@davemloft.net> wrote:
> From: Xin Long <lucien.xin@gmail.com>
> Date: Sun, 1 Jan 2017 21:26:47 +0800
>
>> As only when the result is not performed, initial_tsn variables is
>> uninitialized, peer side would ignore this value, so here is also
>> safe.
>
> It doesn't matter if it is "safe" or not, you must fix all of the
> warnings reported by kbuild before your patches will be considered
> for applying.
will fix it in next post. thanks
^ permalink raw reply
* Re: [PATCH net-next 00/27] sctp: implement rfc6525 sctp stream reconf
From: Xin Long @ 2017-01-02 13:42 UTC (permalink / raw)
To: David Miller
Cc: network dev, linux-sctp, Marcelo Ricardo Leitner, Neil Horman
In-Reply-To: <20170101.113028.1917890848811412528.davem@davemloft.net>
On Mon, Jan 2, 2017 at 12:30 AM, David Miller <davem@davemloft.net> wrote:
>
> I'm sorry but this is way too many patches to submit at one time.
>
> Split your series into smaller, more reasonably sized, groups
> of changes.
okay, will split and repost
^ permalink raw reply
* [PATCH - resubmit] igmp: Make igmp group member RFC 3376 compliant
From: Michal Tesar @ 2017-01-02 13:38 UTC (permalink / raw)
To: davem; +Cc: haliu, kuznet, jmorris, kaber, netdev
5.2. Action on Reception of a Query
When a system receives a Query, it does not respond immediately.
Instead, it delays its response by a random amount of time, bounded
by the Max Resp Time value derived from the Max Resp Code in the
received Query message. A system may receive a variety of Queries on
different interfaces and of different kinds (e.g., General Queries,
Group-Specific Queries, and Group-and-Source-Specific Queries), each
of which may require its own delayed response.
Before scheduling a response to a Query, the system must first
consider previously scheduled pending responses and in many cases
schedule a combined response. Therefore, the system must be able to
maintain the following state:
o A timer per interface for scheduling responses to General Queries.
o A per-group and interface timer for scheduling responses to Group-
Specific and Group-and-Source-Specific Queries.
o A per-group and interface list of sources to be reported in the
response to a Group-and-Source-Specific Query.
When a new Query with the Router-Alert option arrives on an
interface, provided the system has state to report, a delay for a
response is randomly selected in the range (0, [Max Resp Time]) where
Max Resp Time is derived from Max Resp Code in the received Query
message. The following rules are then used to determine if a Report
needs to be scheduled and the type of Report to schedule. The rules
are considered in order and only the first matching rule is applied.
1. If there is a pending response to a previous General Query
scheduled sooner than the selected delay, no additional response
needs to be scheduled.
2. If the received Query is a General Query, the interface timer is
used to schedule a response to the General Query after the
selected delay. Any previously pending response to a General
Query is canceled.
--8<--
Currently the timer is rearmed with new random expiration time for
every incoming query regardless of possibly already pending report.
Which is not aligned with the above RFE.
It also might happen that higher rate of incoming queries can
postpone the report after the expiration time of the first query
causing group membership loss.
Now the per interface general query timer is rearmed only
when there is no pending report already scheduled on that interface or
the newly selected expiration time is before the already pending
scheduled report.
Signed-off-by: Michal Tesar <mtesar@redhat.com>
---
net/ipv4/igmp.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 606cc3e..5fc3fd4 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -219,9 +219,14 @@ static void igmp_start_timer(struct ip_mc_list *im, int max_delay)
static void igmp_gq_start_timer(struct in_device *in_dev)
{
int tv = prandom_u32() % in_dev->mr_maxdelay;
+ unsigned long exp = jiffies + tv + 2;
+
+ if (in_dev->mr_gq_running &&
+ time_after_eq(exp, (in_dev->mr_gq_timer).expires))
+ return;
in_dev->mr_gq_running = 1;
- if (!mod_timer(&in_dev->mr_gq_timer, jiffies+tv+2))
+ if (!mod_timer(&in_dev->mr_gq_timer, exp))
in_dev_hold(in_dev);
}
--
2.5.5
^ permalink raw reply related
* pull-request: wireless-drivers-next 2017-01-02
From: Kalle Valo @ 2017-01-02 13:20 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
first pull request for 4.11. The tree is based on 4.9 but that shouldn't
be a problem, at least my test pull to net-next worked ok. I'll fast
forward my trees after you have pulled this.
Please let me know if you have any problems.
Kalle
The following changes since commit adc176c5472214971d77c1a61c83db9b01e9cdc7:
ipv6 addrconf: Implemented enhanced DAD (RFC7527) (2016-12-03 23:21:37 -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-01-02
for you to fetch changes up to e16e558e83ed848f5dac3931dc7549d7a3090f7e:
rtlwifi: fix spelling mistake: "encrypiton" -> "encryption" (2017-01-01 20:54:33 +0200)
----------------------------------------------------------------
wireless-drivers-next patches for 4.11
The most notable change here is the inclusion of airtime fairness
scheduling to ath9k. It prevents slow clients from hogging all the
airtime and unfairly slowing down faster clients.
Otherwise smaller changes and cleanup.
Major changes:
ath9k
* cleanup eeprom endian handling
* add airtime fairness scheduling
ath10k
* fix issues for new QCA9377 firmware version
* support dev_coredump() for firmware crash dump
* enable channel 169 on 5 GHz band
----------------------------------------------------------------
Alexey Khoroshilov (1):
adm80211: add checks for dma mapping errors
Amitkumar Karwar (3):
mwifiex: sdio: fix use after free issue for save_adapter
mwifiex: change width of MAC control variable
mwifiex: Enable dynamic bandwidth signalling
Andrew Lutomirski (1):
orinoco: Use shash instead of ahash for MIC calculations
Arun Khandavalli (1):
ath10k: support dev_coredump for crash dump
Bartosz Markowski (5):
ath10k: fix IRAM banks number for QCA9377
ath10k: override CE5 config for QCA9377
ath10k: decrease num of peers support
ath10k: set CTS protection VDEV param only if VDEV is up
ath10k: add debug trace to rts/cts set function
Bhumika Goyal (1):
libertas: constify cfg80211_ops structures
Christian Lamparter (1):
ath10k: fix potential memory leak in ath10k_wmi_tlv_op_pull_fw_stats()
Colin Ian King (4):
rtlwifi: fix spelling mistake: "contry" -> "country"
brcmfmac: fix spelling mistakes on "Ivalid"
wlcore: fix spelling mistake in wl1271_warning
rtlwifi: fix spelling mistake: "encrypiton" -> "encryption"
Dan Carpenter (2):
mwifiex: clean up some messy indenting
adm80211: return an error if adm8211_alloc_rings() fails
Johannes Berg (1):
iwlegacy: make il3945_mac_ops __ro_after_init
Kalle Valo (1):
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Larry Finger (14):
rtlwifi: Replace local debug macro RT_ASSERT
rtlwifi: Remove RT_TRACE messages that use DBG_EMERG
rtlwifi: rtl8821ae: Remove all instances of DBG_EMERG
rtlwifi: rtl8723be: Remove all instances of DBG_EMERG
rtlwifi: rtl8723ae: Remove all instances of DBG_EMERG
rtlwifi: rtl8192ee: Remove all instances of DBG_EMERG
rtlwifi: rtl8723-common: Remove all instances of DBG_EMERG
rtlwifi: rtl8192se: Remove all instances of DBG_EMERG
rtlwifi: rtl8192de: Remove all instances of DBG_EMERG
rtlwifi: rtl8192cu: Remove all instances of DBG_EMERG
rtlwifi: rtl8192ce: Remove all instances of DBG_EMERG
rtlwifi: rtl8192c-common: Remove all instances of DBG_EMERG
rtlwifi: rtl8188ee: Remove all instances of DBG_EMERG
rtlwifi: Remove some redundant code
Martin Blumenstingl (7):
ath9k: Add a #define for the EEPROM "eepmisc" endianness bit
ath9k: indicate that the AR9003 EEPROM template values are little endian
ath9k: Add an eeprom_ops callback for retrieving the eepmisc value
ath9k: replace eeprom_param EEP_MINOR_REV with get_eeprom_rev
ath9k: consistently use get_eeprom_rev(ah)
ath9k: Make the EEPROM swapping check use the eepmisc register
ath9k: define all EEPROM fields in Little Endian format
Mohammed Shafi Shajakhan (3):
ath10k: Avoid potential page alloc BUG_ON in tx free path
ath10k: Remove passing unused argument for ath10k_mac_tx
ath10k: enable advertising support for channel 169, 5Ghz
Ping-Ke Shih (1):
rtlwifi: Fix alignment issues
Ryan Hsu (3):
ath10k: fix incorrect txpower set by P2P_DEVICE interface
ath10k: recal the txpower when removing interface
ath10k: ignore configuring the incorrect board_id
Stanislaw Gruszka (11):
rt2800: make rx ampdu_factor depend on number of rx chains
rt2800: don't set ht parameters for non-aggregated frames
rt2800: set minimum MPDU and PSDU lengths to sane values
rt2800: set MAX_PSDU len according to remote STAs capabilities
rt2800: rename adjust_freq_offset function
rt2800: warn if doing VCO recalibration for unknow RF chip
rt2800: perform VCO recalibration for RF5592 chip
rt2x00: merge agc and vco works with link tuner
rt2800: replace mdelay by usleep on vco calibration.
rt2800: replace msleep() with usleep_range() on channel switch
rt2x00: add mutex to synchronize config and link tuner
Toke Høiland-Jørgensen (2):
ath9k: Introduce airtime fairness scheduling between stations
ath9k: Turn ath_txq_lock/unlock() into static inlines.
drivers/net/wireless/admtek/adm8211.c | 27 ++-
drivers/net/wireless/ath/ath10k/core.c | 11 +-
drivers/net/wireless/ath/ath10k/core.h | 2 +-
drivers/net/wireless/ath/ath10k/debug.c | 43 ++++-
drivers/net/wireless/ath/ath10k/debug.h | 8 +
drivers/net/wireless/ath/ath10k/htt_tx.c | 2 +
drivers/net/wireless/ath/ath10k/hw.h | 2 +-
drivers/net/wireless/ath/ath10k/mac.c | 73 ++++++--
drivers/net/wireless/ath/ath10k/pci.c | 4 +-
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 12 +-
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9002_hw.c | 6 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 21 ++-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 4 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 36 +++-
drivers/net/wireless/ath/ath9k/channel.c | 14 +-
drivers/net/wireless/ath/ath9k/debug.c | 3 +
drivers/net/wireless/ath/ath9k/debug.h | 13 ++
drivers/net/wireless/ath/ath9k/debug_sta.c | 54 ++++++
drivers/net/wireless/ath/ath9k/eeprom.c | 42 +++--
drivers/net/wireless/ath/ath9k/eeprom.h | 85 +++++----
drivers/net/wireless/ath/ath9k/eeprom_4k.c | 137 ++++++--------
drivers/net/wireless/ath/ath9k/eeprom_9287.c | 129 ++++++-------
drivers/net/wireless/ath/ath9k/eeprom_def.c | 163 ++++++++---------
drivers/net/wireless/ath/ath9k/init.c | 2 +
drivers/net/wireless/ath/ath9k/main.c | 6 +-
drivers/net/wireless/ath/ath9k/recv.c | 65 +++++++
drivers/net/wireless/ath/ath9k/xmit.c | 192 +++++++++++++-------
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 4 +-
drivers/net/wireless/intel/iwlegacy/3945-mac.c | 20 +-
drivers/net/wireless/intersil/orinoco/mic.c | 44 +++--
drivers/net/wireless/intersil/orinoco/mic.h | 3 +-
drivers/net/wireless/intersil/orinoco/orinoco.h | 4 +-
drivers/net/wireless/marvell/libertas/cfg.c | 2 +-
drivers/net/wireless/marvell/mwifiex/fw.h | 19 +-
drivers/net/wireless/marvell/mwifiex/init.c | 3 +-
drivers/net/wireless/marvell/mwifiex/main.h | 2 +-
drivers/net/wireless/marvell/mwifiex/sdio.c | 6 +
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 8 +-
drivers/net/wireless/ralink/rt2x00/rt2800.h | 2 +
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 79 ++++++--
drivers/net/wireless/ralink/rt2x00/rt2800lib.h | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2x00.h | 6 +-
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 7 +-
drivers/net/wireless/ralink/rt2x00/rt2x00lib.h | 31 +---
drivers/net/wireless/ralink/rt2x00/rt2x00link.c | 132 ++++----------
drivers/net/wireless/ralink/rt2x00/rt2x00mac.c | 8 +-
drivers/net/wireless/ralink/rt2x00/rt2x00queue.c | 12 +-
drivers/net/wireless/realtek/rtlwifi/base.c | 15 +-
drivers/net/wireless/realtek/rtlwifi/cam.c | 14 +-
drivers/net/wireless/realtek/rtlwifi/core.c | 31 ++--
drivers/net/wireless/realtek/rtlwifi/debug.h | 16 +-
drivers/net/wireless/realtek/rtlwifi/efuse.c | 3 +-
drivers/net/wireless/realtek/rtlwifi/pci.c | 48 ++---
drivers/net/wireless/realtek/rtlwifi/ps.c | 3 +-
drivers/net/wireless/realtek/rtlwifi/rc.c | 3 +-
drivers/net/wireless/realtek/rtlwifi/regd.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/fw.c | 44 ++---
.../net/wireless/realtek/rtlwifi/rtl8188ee/hw.c | 33 ++--
.../net/wireless/realtek/rtlwifi/rtl8188ee/phy.c | 35 ++--
.../net/wireless/realtek/rtlwifi/rtl8188ee/rf.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/sw.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/trx.c | 8 +-
.../wireless/realtek/rtlwifi/rtl8192c/fw_common.c | 46 ++---
.../wireless/realtek/rtlwifi/rtl8192c/phy_common.c | 28 +--
.../net/wireless/realtek/rtlwifi/rtl8192ce/hw.c | 39 ++--
.../net/wireless/realtek/rtlwifi/rtl8192ce/led.c | 7 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/phy.c | 15 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/rf.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/sw.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/trx.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/hw.c | 35 ++--
.../net/wireless/realtek/rtlwifi/rtl8192cu/led.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/mac.c | 12 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/phy.c | 15 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/rf.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/sw.c | 5 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/trx.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/fw.c | 34 ++--
.../net/wireless/realtek/rtlwifi/rtl8192de/hw.c | 35 ++--
.../net/wireless/realtek/rtlwifi/rtl8192de/led.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/phy.c | 45 +++--
.../net/wireless/realtek/rtlwifi/rtl8192de/rf.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/sw.c | 10 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/trx.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/fw.c | 40 +---
.../net/wireless/realtek/rtlwifi/rtl8192ee/hw.c | 15 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/phy.c | 39 ++--
.../net/wireless/realtek/rtlwifi/rtl8192ee/rf.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/sw.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/trx.c | 15 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/fw.c | 46 ++---
.../net/wireless/realtek/rtlwifi/rtl8192se/hw.c | 43 ++---
.../net/wireless/realtek/rtlwifi/rtl8192se/led.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/phy.c | 45 ++---
.../net/wireless/realtek/rtlwifi/rtl8192se/rf.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/sw.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/trx.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/fw.c | 15 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 21 +--
.../net/wireless/realtek/rtlwifi/rtl8723ae/led.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/phy.c | 31 ++--
.../net/wireless/realtek/rtlwifi/rtl8723ae/rf.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/sw.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/trx.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/fw.c | 15 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 18 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/led.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/phy.c | 33 ++--
.../net/wireless/realtek/rtlwifi/rtl8723be/rf.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/sw.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/trx.c | 14 +-
.../realtek/rtlwifi/rtl8723com/fw_common.c | 26 +--
.../realtek/rtlwifi/rtl8723com/phy_common.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/dm.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/fw.c | 28 +--
.../net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 33 ++--
.../net/wireless/realtek/rtlwifi/rtl8821ae/phy.c | 54 +++---
.../net/wireless/realtek/rtlwifi/rtl8821ae/rf.c | 5 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/sw.c | 14 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/trx.c | 20 +-
drivers/net/wireless/realtek/rtlwifi/usb.c | 48 ++---
drivers/net/wireless/ti/wlcore/debugfs.c | 2 +-
123 files changed, 1487 insertions(+), 1421 deletions(-)
^ permalink raw reply
* [PATCH net-next] net/sched: cls_flower: Add user specified data
From: Paul Blakey @ 2017-01-02 13:13 UTC (permalink / raw)
To: David S. Miller, netdev
Cc: Jiri Pirko, Hadar Hen Zion, Or Gerlitz, Roi Dayan, Paul Blakey
This is to support saving extra data that might be helpful on retrieval.
First use case is upcoming openvswitch flow offloads, extra data will
include UFID and port mappings for each added flow.
Signed-off-by: Paul Blakey <paulb@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
---
include/uapi/linux/pkt_cls.h | 3 +++
net/sched/cls_flower.c | 22 +++++++++++++++++++++-
2 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
index cb4bcdc..ca9bbe3 100644
--- a/include/uapi/linux/pkt_cls.h
+++ b/include/uapi/linux/pkt_cls.h
@@ -471,10 +471,13 @@ enum {
TCA_FLOWER_KEY_ICMPV6_TYPE, /* u8 */
TCA_FLOWER_KEY_ICMPV6_TYPE_MASK,/* u8 */
+ TCA_FLOWER_COOKIE, /* binary */
+
__TCA_FLOWER_MAX,
};
#define TCA_FLOWER_MAX (__TCA_FLOWER_MAX - 1)
+#define FLOWER_MAX_COOKIE_SIZE 128
enum {
TCA_FLOWER_KEY_FLAGS_IS_FRAGMENT = (1 << 0),
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index 333f8e2..e2f5b25 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -85,6 +85,8 @@ struct cls_fl_filter {
struct rcu_head rcu;
struct tc_to_netdev tc;
struct net_device *hw_dev;
+ size_t cookie_len;
+ long cookie[0];
};
static unsigned short int fl_mask_range(const struct fl_flow_mask *mask)
@@ -794,6 +796,9 @@ static int fl_change(struct net *net, struct sk_buff *in_skb,
struct cls_fl_filter *fnew;
struct nlattr *tb[TCA_FLOWER_MAX + 1];
struct fl_flow_mask mask = {};
+ const struct nlattr *attr;
+ size_t cookie_len = 0;
+ void *cookie;
int err;
if (!tca[TCA_OPTIONS])
@@ -806,10 +811,22 @@ static int fl_change(struct net *net, struct sk_buff *in_skb,
if (fold && handle && fold->handle != handle)
return -EINVAL;
- fnew = kzalloc(sizeof(*fnew), GFP_KERNEL);
+ if (tb[TCA_FLOWER_COOKIE]) {
+ attr = tb[TCA_FLOWER_COOKIE];
+ cookie_len = nla_len(attr);
+ cookie = nla_data(attr);
+ if (cookie_len > FLOWER_MAX_COOKIE_SIZE)
+ return -EINVAL;
+ }
+
+ fnew = kzalloc(sizeof(*fnew) + cookie_len, GFP_KERNEL);
if (!fnew)
return -ENOBUFS;
+ fnew->cookie_len = cookie_len;
+ if (cookie_len)
+ memcpy(fnew->cookie, cookie, cookie_len);
+
err = tcf_exts_init(&fnew->exts, TCA_FLOWER_ACT, 0);
if (err < 0)
goto errout;
@@ -1151,6 +1168,9 @@ static int fl_dump(struct net *net, struct tcf_proto *tp, unsigned long fh,
nla_put_u32(skb, TCA_FLOWER_FLAGS, f->flags);
+ if (f->cookie_len)
+ nla_put(skb, TCA_FLOWER_COOKIE, f->cookie_len, f->cookie);
+
if (tcf_exts_dump(skb, &f->exts))
goto nla_put_failure;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v3] rfkill: Add rfkill-any LED trigger
From: Johannes Berg @ 2017-01-02 12:52 UTC (permalink / raw)
To: Michał Kępień, David S . Miller
Cc: Михаил Кринкин,
linux-wireless, netdev, linux-kernel
In-Reply-To: <1483359705.21014.0.camel@sipsolutions.net>
On Mon, 2017-01-02 at 13:21 +0100, Johannes Berg wrote:
> > I'm not super happy with this conditional locking - can't we
> > instead
> > defer the necessary work to a workqueue, or so, for purposes of the
> > LED?
>
> Actually, since you can sleep in here, and do various other things
> like scheduling etc. this can't even be correct as is - one thread
> might be in the probe and another might also attempt to do some
> operations that require the lock but now don't take it.
Additionally, this doesn't address the "can be called in any context"
part, only the "even from within rfkill callbacks" part. It's clearly
still not safe to call this from any context that is not allowed to
sleep, for example.
johannes
^ permalink raw reply
* [PATCH v3] net: macb: Updated resource allocation function calls to new version of API.
From: Bartosz Folta @ 2017-01-02 12:41 UTC (permalink / raw)
To: Nicolas Ferre, David S. Miller, Niklas Cassel, Alexandre Torgue,
Satanand Burla, Raghu Vatsavayi, Simon Horman,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Cc: Bartosz Folta, Rafal Ozieblo
In-Reply-To: <1483360206-27699-1-git-send-email-bfolta@cadence.com>
Changed function calls of resource allocation to new API. Changed way
of setting DMA mask. Removed unnecessary sanity check.
This patch is sent in regard to recently applied patch
Commit 83a77e9ec4150ee4acc635638f7dedd9da523a26
net: macb: Added PCI wrapper for Platform Driver.
Signed-off-by: Bartosz Folta <bfolta@cadence.com>
---
Changed in v3:
Commit message.
---
Changed in v2:
Size of DMA mask is set based on value held by PCI device.
---
drivers/net/ethernet/cadence/macb_pci.c | 27 ++++++++++-----------------
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb_pci.c b/drivers/net/ethernet/cadence/macb_pci.c
index 92be2cd..9906fda 100644
--- a/drivers/net/ethernet/cadence/macb_pci.c
+++ b/drivers/net/ethernet/cadence/macb_pci.c
@@ -1,5 +1,5 @@
/**
- * macb_pci.c - Cadence GEM PCI wrapper.
+ * Cadence GEM PCI wrapper.
*
* Copyright (C) 2016 Cadence Design Systems - http://www.cadence.com
*
@@ -45,32 +45,27 @@ static int macb_probe(struct pci_dev *pdev, const struct pci_device_id *id)
struct macb_platform_data plat_data;
struct resource res[2];
- /* sanity check */
- if (!id)
- return -EINVAL;
-
/* enable pci device */
- err = pci_enable_device(pdev);
+ err = pcim_enable_device(pdev);
if (err < 0) {
- dev_err(&pdev->dev, "Enabling PCI device has failed: 0x%04X",
- err);
- return -EACCES;
+ dev_err(&pdev->dev, "Enabling PCI device has failed: %d", err);
+ return err;
}
pci_set_master(pdev);
/* set up resources */
memset(res, 0x00, sizeof(struct resource) * ARRAY_SIZE(res));
- res[0].start = pdev->resource[0].start;
- res[0].end = pdev->resource[0].end;
+ res[0].start = pci_resource_start(pdev, 0);
+ res[0].end = pci_resource_end(pdev, 0);
res[0].name = PCI_DRIVER_NAME;
res[0].flags = IORESOURCE_MEM;
- res[1].start = pdev->irq;
+ res[1].start = pci_irq_vector(pdev, 0);
res[1].name = PCI_DRIVER_NAME;
res[1].flags = IORESOURCE_IRQ;
- dev_info(&pdev->dev, "EMAC physical base addr = 0x%p\n",
- (void *)(uintptr_t)pci_resource_start(pdev, 0));
+ dev_info(&pdev->dev, "EMAC physical base addr: %pa\n",
+ &res[0].start);
/* set up macb platform data */
memset(&plat_data, 0, sizeof(plat_data));
@@ -100,7 +95,7 @@ static int macb_probe(struct pci_dev *pdev, const struct pci_device_id *id)
plat_info.num_res = ARRAY_SIZE(res);
plat_info.data = &plat_data;
plat_info.size_data = sizeof(plat_data);
- plat_info.dma_mask = DMA_BIT_MASK(32);
+ plat_info.dma_mask = pdev->dma_mask;
/* register platform device */
plat_dev = platform_device_register_full(&plat_info);
@@ -120,7 +115,6 @@ static int macb_probe(struct pci_dev *pdev, const struct pci_device_id *id)
clk_unregister(plat_data.pclk);
err_pclk_register:
- pci_disable_device(pdev);
return err;
}
@@ -130,7 +124,6 @@ static void macb_remove(struct pci_dev *pdev)
struct macb_platform_data *plat_data = dev_get_platdata(&plat_dev->dev);
platform_device_unregister(plat_dev);
- pci_disable_device(pdev);
clk_unregister(plat_data->pclk);
clk_unregister(plat_data->hclk);
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v3] rfkill: Add rfkill-any LED trigger
From: Johannes Berg @ 2017-01-02 12:21 UTC (permalink / raw)
To: Michał Kępień, David S . Miller
Cc: Михаил Кринкин,
linux-wireless, netdev, linux-kernel
In-Reply-To: <1483355533.4596.11.camel@sipsolutions.net>
> I'm not super happy with this conditional locking - can't we instead
> defer the necessary work to a workqueue, or so, for purposes of the
> LED?
Actually, since you can sleep in here, and do various other things like
scheduling etc. this can't even be correct as is - one thread might be
in the probe and another might also attempt to do some operations that
require the lock but now don't take it.
johannes
^ permalink raw reply
* [PATCH net 3/3] net: stmmac: dwmac-oxnas: use generic pm implementation
From: Johan Hovold @ 2017-01-02 11:56 UTC (permalink / raw)
To: David S. Miller
Cc: Giuseppe Cavallaro, Alexandre Torgue, Neil Armstrong, netdev,
linux-oxnas, linux-kernel, Johan Hovold
In-Reply-To: <20170102115604.32482-1-johan@kernel.org>
Now that we have an exit callback in place, add init as well and get rid
of the custom PM callbacks in favour of the generic ones.
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c | 38 +++--------------------
1 file changed, 5 insertions(+), 33 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
index 3efd110613df..3dc7d279f805 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
@@ -60,8 +60,9 @@ struct oxnas_dwmac {
struct regmap *regmap;
};
-static int oxnas_dwmac_init(struct oxnas_dwmac *dwmac)
+static int oxnas_dwmac_init(struct platform_device *pdev, void *priv)
{
+ struct oxnas_dwmac *dwmac = priv;
unsigned int value;
int ret;
@@ -135,6 +136,7 @@ static int oxnas_dwmac_probe(struct platform_device *pdev)
dwmac->dev = &pdev->dev;
plat_dat->bsp_priv = dwmac;
+ plat_dat->init = oxnas_dwmac_init;
plat_dat->exit = oxnas_dwmac_exit;
dwmac->regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
@@ -151,7 +153,7 @@ static int oxnas_dwmac_probe(struct platform_device *pdev)
goto err_remove_config_dt;
}
- ret = oxnas_dwmac_init(dwmac);
+ ret = oxnas_dwmac_init(pdev, plat_dat->bsp_priv);
if (ret)
goto err_remove_config_dt;
@@ -170,36 +172,6 @@ static int oxnas_dwmac_probe(struct platform_device *pdev)
return ret;
}
-#ifdef CONFIG_PM_SLEEP
-static int oxnas_dwmac_suspend(struct device *dev)
-{
- struct oxnas_dwmac *dwmac = get_stmmac_bsp_priv(dev);
- int ret;
-
- ret = stmmac_suspend(dev);
- clk_disable_unprepare(dwmac->clk);
-
- return ret;
-}
-
-static int oxnas_dwmac_resume(struct device *dev)
-{
- struct oxnas_dwmac *dwmac = get_stmmac_bsp_priv(dev);
- int ret;
-
- ret = oxnas_dwmac_init(dwmac);
- if (ret)
- return ret;
-
- ret = stmmac_resume(dev);
-
- return ret;
-}
-#endif /* CONFIG_PM_SLEEP */
-
-static SIMPLE_DEV_PM_OPS(oxnas_dwmac_pm_ops,
- oxnas_dwmac_suspend, oxnas_dwmac_resume);
-
static const struct of_device_id oxnas_dwmac_match[] = {
{ .compatible = "oxsemi,ox820-dwmac" },
{ }
@@ -211,7 +183,7 @@ static struct platform_driver oxnas_dwmac_driver = {
.remove = stmmac_pltfr_remove,
.driver = {
.name = "oxnas-dwmac",
- .pm = &oxnas_dwmac_pm_ops,
+ .pm = &stmmac_pltfr_pm_ops,
.of_match_table = oxnas_dwmac_match,
},
};
--
2.10.2
^ permalink raw reply related
* [PATCH net 1/3] net: stmmac: dwmac-oxnas: fix of-node leak
From: Johan Hovold @ 2017-01-02 11:56 UTC (permalink / raw)
To: David S. Miller
Cc: Giuseppe Cavallaro, Alexandre Torgue, Neil Armstrong, netdev,
linux-oxnas, linux-kernel, Johan Hovold
In-Reply-To: <20170102115604.32482-1-johan@kernel.org>
Use the syscon lookup-by-phandle helper so that the reference taken by
of_parse_phandle() is released when done with the node.
Fixes: 5ed7414062e7 ("net: stmmac: Add OXNAS Glue Driver")
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
index c35597586121..fcc237e0aae1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
@@ -109,16 +109,9 @@ static int oxnas_dwmac_probe(struct platform_device *pdev)
{
struct plat_stmmacenet_data *plat_dat;
struct stmmac_resources stmmac_res;
- struct device_node *sysctrl;
struct oxnas_dwmac *dwmac;
int ret;
- sysctrl = of_parse_phandle(pdev->dev.of_node, "oxsemi,sys-ctrl", 0);
- if (!sysctrl) {
- dev_err(&pdev->dev, "failed to get sys-ctrl node\n");
- return -EINVAL;
- }
-
ret = stmmac_get_platform_resources(pdev, &stmmac_res);
if (ret)
return ret;
@@ -134,7 +127,8 @@ static int oxnas_dwmac_probe(struct platform_device *pdev)
dwmac->dev = &pdev->dev;
plat_dat->bsp_priv = dwmac;
- dwmac->regmap = syscon_node_to_regmap(sysctrl);
+ dwmac->regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
+ "oxsemi,sys-ctrl");
if (IS_ERR(dwmac->regmap)) {
dev_err(&pdev->dev, "failed to have sysctrl regmap\n");
return PTR_ERR(dwmac->regmap);
--
2.10.2
^ permalink raw reply related
* [PATCH net 2/3] net: stmmac: dwmac-oxnas: fix fixed-link-phydev leaks
From: Johan Hovold @ 2017-01-02 11:56 UTC (permalink / raw)
To: David S. Miller
Cc: Giuseppe Cavallaro, Alexandre Torgue, Neil Armstrong, netdev,
linux-oxnas, linux-kernel, Johan Hovold
In-Reply-To: <20170102115604.32482-1-johan@kernel.org>
Make sure to deregister and free any fixed-link phy registered during
probe on probe errors and on driver unbind by calling the new glue
helper function.
For driver unbind, use the generic stmmac-platform remove implementation
and add an exit callback to disable the clock.
Fixes: 5ed7414062e7 ("net: stmmac: Add OXNAS Glue Driver")
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c | 41 ++++++++++++++---------
1 file changed, 26 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
index fcc237e0aae1..3efd110613df 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
@@ -105,6 +105,13 @@ static int oxnas_dwmac_init(struct oxnas_dwmac *dwmac)
return 0;
}
+static void oxnas_dwmac_exit(struct platform_device *pdev, void *priv)
+{
+ struct oxnas_dwmac *dwmac = priv;
+
+ clk_disable_unprepare(dwmac->clk);
+}
+
static int oxnas_dwmac_probe(struct platform_device *pdev)
{
struct plat_stmmacenet_data *plat_dat;
@@ -121,40 +128,44 @@ static int oxnas_dwmac_probe(struct platform_device *pdev)
return PTR_ERR(plat_dat);
dwmac = devm_kzalloc(&pdev->dev, sizeof(*dwmac), GFP_KERNEL);
- if (!dwmac)
- return -ENOMEM;
+ if (!dwmac) {
+ ret = -ENOMEM;
+ goto err_remove_config_dt;
+ }
dwmac->dev = &pdev->dev;
plat_dat->bsp_priv = dwmac;
+ plat_dat->exit = oxnas_dwmac_exit;
dwmac->regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
"oxsemi,sys-ctrl");
if (IS_ERR(dwmac->regmap)) {
dev_err(&pdev->dev, "failed to have sysctrl regmap\n");
- return PTR_ERR(dwmac->regmap);
+ ret = PTR_ERR(dwmac->regmap);
+ goto err_remove_config_dt;
}
dwmac->clk = devm_clk_get(&pdev->dev, "gmac");
- if (IS_ERR(dwmac->clk))
- return PTR_ERR(dwmac->clk);
+ if (IS_ERR(dwmac->clk)) {
+ ret = PTR_ERR(dwmac->clk);
+ goto err_remove_config_dt;
+ }
ret = oxnas_dwmac_init(dwmac);
if (ret)
- return ret;
+ goto err_remove_config_dt;
ret = stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
if (ret)
- clk_disable_unprepare(dwmac->clk);
+ goto err_dwmac_exit;
- return ret;
-}
-static int oxnas_dwmac_remove(struct platform_device *pdev)
-{
- struct oxnas_dwmac *dwmac = get_stmmac_bsp_priv(&pdev->dev);
- int ret = stmmac_dvr_remove(&pdev->dev);
+ return 0;
- clk_disable_unprepare(dwmac->clk);
+err_dwmac_exit:
+ oxnas_dwmac_exit(pdev, plat_dat->bsp_priv);
+err_remove_config_dt:
+ stmmac_remove_config_dt(pdev, plat_dat);
return ret;
}
@@ -197,7 +208,7 @@ MODULE_DEVICE_TABLE(of, oxnas_dwmac_match);
static struct platform_driver oxnas_dwmac_driver = {
.probe = oxnas_dwmac_probe,
- .remove = oxnas_dwmac_remove,
+ .remove = stmmac_pltfr_remove,
.driver = {
.name = "oxnas-dwmac",
.pm = &oxnas_dwmac_pm_ops,
--
2.10.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox