* [PATCH iproute2-next 0/8] tc: gred: JSON-ify and support per-vq config
From: Jakub Kicinski @ 2018-11-19 23:03 UTC (permalink / raw)
To: dsahern, stephen; +Cc: oss-drivers, netdev, Jakub Kicinski
Hi!
This set brings GRED support up to date with recent kernel changes.
In particular the new netlink attributes for more fine-grained stats
and per-virtual queue flags.
To make GRED usable in modern deployments the patch set starts with
adding JSON output.
Jakub Kicinski (8):
tc: gred: remove unclear comment
json: add %hhu helpers
tc: move RED flag printing to helper
tc: gred: jsonify GRED output
tc: gred: separate out stats printing
tc: gred: use extended stats if available
tc: gred: support controlling RED flags
tc: gred: allow controlling and dumping per-DP RED flags
bash-completion/tc | 2 +-
include/json_print.h | 1 +
include/json_writer.h | 2 +
lib/json_print.c | 1 +
lib/json_writer.c | 11 ++
tc/q_choke.c | 3 +-
tc/q_gred.c | 250 +++++++++++++++++++++++++++++++++++-------
tc/q_red.c | 14 +--
tc/q_sfq.c | 3 +-
tc/tc_red.c | 20 ++++
tc/tc_red.h | 1 +
11 files changed, 254 insertions(+), 54 deletions(-)
--
2.17.1
^ permalink raw reply
* Re: hard-coded limit on unresolved multicast route cache in ipv4/ipmr.c causes slow, unreliable creation of multicast routes on busy networks
From: Hangbin Liu @ 2018-11-20 9:23 UTC (permalink / raw)
To: David Miller; +Cc: karn, kuznet, yoshfuji, netdev, linux-kernel
In-Reply-To: <20180721.220309.1193443933653884021.davem@davemloft.net>
Hi David,
On Sat, Jul 21, 2018 at 10:03:09PM -0700, David Miller wrote:
> Yeah that limit is bogus for several reasons.
...
>
> Therefore, it probably is safe and correct to remove this
> cache_resolve_queue_len altogether.
>
> Something like this:
>
> diff --git a/include/linux/mroute_base.h b/include/linux/mroute_base.h
> index d633f737b3c6..b166465d7c05 100644
> --- a/include/linux/mroute_base.h
> +++ b/include/linux/mroute_base.h
> @@ -234,7 +234,6 @@ struct mr_table_ops {
> * @mfc_hash: Hash table of all resolved routes for easy lookup
> * @mfc_cache_list: list of resovled routes for possible traversal
> * @maxvif: Identifier of highest value vif currently in use
> - * @cache_resolve_queue_len: current size of unresolved queue
> * @mroute_do_assert: Whether to inform userspace on wrong ingress
> * @mroute_do_pim: Whether to receive IGMP PIMv1
> * @mroute_reg_vif_num: PIM-device vif index
> @@ -251,7 +250,6 @@ struct mr_table {
> struct rhltable mfc_hash;
> struct list_head mfc_cache_list;
> int maxvif;
> - atomic_t cache_resolve_queue_len;
> bool mroute_do_assert;
> bool mroute_do_pim;
> int mroute_reg_vif_num;
> diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
> index 9f79b9803a16..c007cf9bfe82 100644
> --- a/net/ipv4/ipmr.c
> +++ b/net/ipv4/ipmr.c
> @@ -747,8 +747,6 @@ static void ipmr_destroy_unres(struct mr_table *mrt, struct mfc_cache *c)
> struct sk_buff *skb;
> struct nlmsgerr *e;
>
> - atomic_dec(&mrt->cache_resolve_queue_len);
> -
> while ((skb = skb_dequeue(&c->_c.mfc_un.unres.unresolved))) {
> if (ip_hdr(skb)->version == 0) {
> struct nlmsghdr *nlh = skb_pull(skb,
> @@ -1135,9 +1133,11 @@ static int ipmr_cache_unresolved(struct mr_table *mrt, vifi_t vifi,
> }
>
> if (!found) {
> + bool was_empty;
> +
> /* Create a new entry if allowable */
> - if (atomic_read(&mrt->cache_resolve_queue_len) >= 10 ||
> - (c = ipmr_cache_alloc_unres()) == NULL) {
> + c = ipmr_cache_alloc_unres();
> + if (!c) {
> spin_unlock_bh(&mfc_unres_lock);
>
> kfree_skb(skb);
> @@ -1163,11 +1163,11 @@ static int ipmr_cache_unresolved(struct mr_table *mrt, vifi_t vifi,
> return err;
> }
>
> - atomic_inc(&mrt->cache_resolve_queue_len);
> + was_empty = list_empty(&mrt->mfc_unres_queue);
> list_add(&c->_c.list, &mrt->mfc_unres_queue);
> mroute_netlink_event(mrt, c, RTM_NEWROUTE);
>
> - if (atomic_read(&mrt->cache_resolve_queue_len) == 1)
> + if (was_empty)
> mod_timer(&mrt->ipmr_expire_timer,
> c->_c.mfc_un.unres.expires);
In ipmr_expire_process() and ipmr_do_expire_process(), they start mod_timer
when !list_empty(&mrt->mfc_unres_queue), should here also be !was_empty?
BTW, do you have any plan to apply this patch in kernel?
Regards
Hangbin
> }
> @@ -1274,7 +1274,6 @@ static int ipmr_mfc_add(struct net *net, struct mr_table *mrt,
> if (uc->mfc_origin == c->mfc_origin &&
> uc->mfc_mcastgrp == c->mfc_mcastgrp) {
> list_del(&_uc->list);
> - atomic_dec(&mrt->cache_resolve_queue_len);
> found = true;
> break;
> }
> @@ -1322,7 +1321,7 @@ static void mroute_clean_tables(struct mr_table *mrt, bool all)
> mr_cache_put(c);
> }
>
> - if (atomic_read(&mrt->cache_resolve_queue_len) != 0) {
> + if (!list_empty(&mrt->mfc_unres_queue)) {
> spin_lock_bh(&mfc_unres_lock);
> list_for_each_entry_safe(c, tmp, &mrt->mfc_unres_queue, list) {
> list_del(&c->list);
> @@ -2648,9 +2647,19 @@ static int ipmr_rtm_route(struct sk_buff *skb, struct nlmsghdr *nlh,
> return ipmr_mfc_delete(tbl, &mfcc, parent);
> }
>
> +static int queue_count(struct mr_table *mrt)
> +{
> + struct list_head *pos;
> + int count = 0;
> +
> + list_for_each(pos, &mrt->mfc_unres_queue)
> + count++;
> + return count;
> +}
> +
> static bool ipmr_fill_table(struct mr_table *mrt, struct sk_buff *skb)
> {
> - u32 queue_len = atomic_read(&mrt->cache_resolve_queue_len);
> + u32 queue_len = queue_count(mrt);
>
> if (nla_put_u32(skb, IPMRA_TABLE_ID, mrt->id) ||
> nla_put_u32(skb, IPMRA_TABLE_CACHE_RES_QUEUE_LEN, queue_len) ||
> diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
> index 0d0f0053bb11..75e9c5a3e7ea 100644
> --- a/net/ipv6/ip6mr.c
> +++ b/net/ipv6/ip6mr.c
> @@ -759,8 +759,6 @@ static void ip6mr_destroy_unres(struct mr_table *mrt, struct mfc6_cache *c)
> struct net *net = read_pnet(&mrt->net);
> struct sk_buff *skb;
>
> - atomic_dec(&mrt->cache_resolve_queue_len);
> -
> while ((skb = skb_dequeue(&c->_c.mfc_un.unres.unresolved)) != NULL) {
> if (ipv6_hdr(skb)->version == 0) {
> struct nlmsghdr *nlh = skb_pull(skb,
> @@ -1139,8 +1137,8 @@ static int ip6mr_cache_unresolved(struct mr_table *mrt, mifi_t mifi,
> * Create a new entry if allowable
> */
>
> - if (atomic_read(&mrt->cache_resolve_queue_len) >= 10 ||
> - (c = ip6mr_cache_alloc_unres()) == NULL) {
> + c = ip6mr_cache_alloc_unres();
> + if (!c) {
> spin_unlock_bh(&mfc_unres_lock);
>
> kfree_skb(skb);
> @@ -1167,7 +1165,6 @@ static int ip6mr_cache_unresolved(struct mr_table *mrt, mifi_t mifi,
> return err;
> }
>
> - atomic_inc(&mrt->cache_resolve_queue_len);
> list_add(&c->_c.list, &mrt->mfc_unres_queue);
> mr6_netlink_event(mrt, c, RTM_NEWROUTE);
>
> @@ -1455,7 +1452,6 @@ static int ip6mr_mfc_add(struct net *net, struct mr_table *mrt,
> if (ipv6_addr_equal(&uc->mf6c_origin, &c->mf6c_origin) &&
> ipv6_addr_equal(&uc->mf6c_mcastgrp, &c->mf6c_mcastgrp)) {
> list_del(&_uc->list);
> - atomic_dec(&mrt->cache_resolve_queue_len);
> found = true;
> break;
> }
> @@ -1502,7 +1498,7 @@ static void mroute_clean_tables(struct mr_table *mrt, bool all)
> mr_cache_put(c);
> }
>
> - if (atomic_read(&mrt->cache_resolve_queue_len) != 0) {
> + if (!list_empty(&mrt->mfc_unres_queue)) {
> spin_lock_bh(&mfc_unres_lock);
> list_for_each_entry_safe(c, tmp, &mrt->mfc_unres_queue, list) {
> list_del(&c->list);
^ permalink raw reply
* [v4, PATCH 2/2] dt-binding: mediatek-dwmac: add binding document for MediaTek MT2712 DWMAC
From: Biao Huang @ 2018-11-20 9:21 UTC (permalink / raw)
To: davem, robh+dt
Cc: honghui.zhang, yt.shen, liguo.zhang, mark.rutland, nelson.chang,
matthias.bgg, biao.huang, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, joabreu, andrew
In-Reply-To: <1542705696-18507-1-git-send-email-biao.huang@mediatek.com>
The commit adds the device tree binding documentation for the MediaTek DWMAC
found on MediaTek MT2712.
Signed-off-by: Biao Huang <biao.huang@mediatek.com>
---
.../devicetree/bindings/net/mediatek-dwmac.txt | 78 ++++++++++++++++++++
1 file changed, 78 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/mediatek-dwmac.txt
diff --git a/Documentation/devicetree/bindings/net/mediatek-dwmac.txt b/Documentation/devicetree/bindings/net/mediatek-dwmac.txt
new file mode 100644
index 0000000..0f8a915
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/mediatek-dwmac.txt
@@ -0,0 +1,78 @@
+MediaTek DWMAC glue layer controller
+
+This file documents platform glue layer for stmmac.
+Please see stmmac.txt for the other unchanged properties.
+
+The device node has following properties.
+
+Required properties:
+- compatible: Should be "mediatek,mt2712-gmac" for MT2712 SoC
+- reg: Address and length of the register set for the device
+- interrupts: Should contain the MAC interrupts
+- interrupt-names: Should contain a list of interrupt names corresponding to
+ the interrupts in the interrupts property, if available.
+ Should be "macirq" for the main MAC IRQ
+- clocks: Must contain a phandle for each entry in clock-names.
+- clock-names: The name of the clock listed in the clocks property. These are
+ "axi", "apb", "mac_main", "ptp_ref" for MT2712 SoC
+- mac-address: See ethernet.txt in the same directory
+- phy-mode: See ethernet.txt in the same directory
+
+Optional properties:
+- mediatek,tx-delay: TX clock delay macro value. Range is 0~31. Default is 0.
+ It should be defined for rgmii/rgmii-rxid/mii interface.
+- mediatek,rx-delay: RX clock delay macro value. Range is 0~31. Default is 0.
+ It should be defined for rgmii/rgmii-txid/mii/rmii interface.
+- mediatek,fine-tune: boolean property, if present indicates that fine delay
+ is selected for rgmii interface.
+ If present, tx-delay/rx-delay is 170+/-50ps per stage.
+ Else tx-delay/rx-delay of coarse delay macro is 0.55+/-0.2ns per stage.
+ This property do not apply to non-rgmii PHYs.
+ Only coarse-tune delay is supported for mii/rmii PHYs.
+- mediatek,rmii-rxc: boolean property, if present indicates that the rmii
+ reference clock, which is from external PHYs, is connected to RXC pin
+ on MT2712 SoC.
+ Otherwise, is connected to TXC pin.
+- mediatek,txc-inverse: boolean property, if present indicates that
+ 1. tx clock will be inversed in mii/rgmii case,
+ 2. tx clock inside MAC will be inversed relative to reference clock
+ which is from external PHYs in rmii case, and it rarely happen.
+- mediatek,rxc-inverse: boolean property, if present indicates that
+ 1. rx clock will be inversed in mii/rgmii case.
+ 2. reference clock will be inversed when arrived at MAC in rmii case.
+- assigned-clocks: mac_main and ptp_ref clocks
+- assigned-clock-parents: parent clocks of the assigned clocks
+
+Example:
+ eth: ethernet@1101c000 {
+ compatible = "mediatek,mt2712-gmac";
+ reg = <0 0x1101c000 0 0x1300>;
+ interrupts = <GIC_SPI 237 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "macirq";
+ phy-mode ="rgmii-id";
+ mac-address = [00 55 7b b5 7d f7];
+ clock-names = "axi",
+ "apb",
+ "mac_main",
+ "ptp_ref",
+ "ptp_top";
+ clocks = <&pericfg CLK_PERI_GMAC>,
+ <&pericfg CLK_PERI_GMAC_PCLK>,
+ <&topckgen CLK_TOP_ETHER_125M_SEL>,
+ <&topckgen CLK_TOP_ETHER_50M_SEL>;
+ assigned-clocks = <&topckgen CLK_TOP_ETHER_125M_SEL>,
+ <&topckgen CLK_TOP_ETHER_50M_SEL>;
+ assigned-clock-parents = <&topckgen CLK_TOP_ETHERPLL_125M>,
+ <&topckgen CLK_TOP_APLL1_D3>;
+ mediatek,pericfg = <&pericfg>;
+ mediatek,tx-delay = <9>;
+ mediatek,rx-delay = <9>;
+ mediatek,fine-tune;
+ mediatek,rmii-rxc;
+ mediatek,txc-inverse;
+ mediatek,rxc-inverse;
+ snps,txpbl = <32>;
+ snps,rxpbl = <32>;
+ snps,reset-gpio = <&pio 87 GPIO_ACTIVE_LOW>;
+ snps,reset-active-low;
+ };
--
1.7.9.5
^ permalink raw reply related
* [v4, PATCH 0/2] add Ethernet driver support for mt2712
From: Biao Huang @ 2018-11-20 9:21 UTC (permalink / raw)
To: davem, robh+dt
Cc: honghui.zhang, yt.shen, liguo.zhang, mark.rutland, nelson.chang,
matthias.bgg, biao.huang, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, joabreu, andrew
Changes in v4:
modifications according to comments from Rob and Sean:
1. call clk_bulk api to simplify clk settings.
2. add prefix for mediatek specified properties
3. evolution to a more general driver
^ permalink raw reply
* Re: [PATCH 10/11] nvmet-tcp: add NVMe over TCP target driver
From: David Miller @ 2018-11-19 22:53 UTC (permalink / raw)
To: sagi; +Cc: sagi, linux-block, netdev, keith.busch, hch, linux-nvme
In-Reply-To: <21b60ffc-d9eb-2f2e-fa1a-891f7f8d5239@grimberg.me>
From: Sagi Grimberg <sagi@grimberg.me>
Date: Mon, 19 Nov 2018 13:26:12 -0800
> I would love you to look at skb_copy_and_hash_datagram_iter as these
> changes will require an ack from you.
My first impression is that we now have this kind of code pattern
in at least two main places and now this will be a third.
I know that nobody likes callbacks because of spectre, but all of
these cases could be done with something like:
int __skb_datagram_iter(const struct sk_buff *skb, int offset,
struct iov_iter *to, int len,
int (*cb)(void *, int, struct iov_iter *, void *),
void *data)
{
...
n = cb(skb->data + offset, copy, to, data);
...
}
You get the idea. Then we have one version of all the loops and
the different (copy, copy+csum, copy+hash) cases all can be
handled by __skb_datagram_iter() but just with a different 'cb'
and private 'data'.
^ permalink raw reply
* Re: [PATCH v3 3/5] phy: ocelot-serdes: convert to use eth phy mode and submode
From: Quentin Schulz @ 2018-11-20 9:18 UTC (permalink / raw)
To: Grygorii Strashko
Cc: David S. Miller, Kishon Vijay Abraham I, Antoine Tenart,
Russell King - ARM Linux, Maxime Chevallier, netdev, Sekhar Nori,
linux-kernel, linux-arm-kernel, Tony Lindgren, linux-amlogic,
linux-mediatek, Alexandre Belloni, Vivek Gautam, Maxime Ripard,
Chen-Yu Tsai, Carlo Caione, Chunfeng Yun, Matthias Brugger,
Manu Gautam <mgautam@
In-Reply-To: <20181120012424.11802-4-grygorii.strashko@ti.com>
[-- Attachment #1: Type: text/plain, Size: 3240 bytes --]
Hi Grygorii,
Thanks for the patch!
On Mon, Nov 19, 2018 at 07:24:22PM -0600, Grygorii Strashko wrote:
> Convert ocelot-serdes PHY driver to use recently introduced
> PHY_MODE_ETHERNET and phy_set_mode_ext().
>
> Cc: Quentin Schulz <quentin.schulz@bootlin.com>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: Quentin Schulz <quentin.schulz@bootlin.com>
Tested-by: Quentin Schulz <quentin.schulz@bootlin.com>
Tested on top of latest master branch of net-next
(e432abfb99e5642a7e7fcaa1c8cb0e80c8fcf58e) on a PCB120 with VSC8584 PHYs
(for reference if we ever find out there is a problem with this patch).
> diff --git a/drivers/phy/mscc/phy-ocelot-serdes.c b/drivers/phy/mscc/phy-ocelot-serdes.c
> index c61a9890..77c46f6 100644
> --- a/drivers/phy/mscc/phy-ocelot-serdes.c
> +++ b/drivers/phy/mscc/phy-ocelot-serdes.c
> @@ -11,6 +11,7 @@
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/of_platform.h>
> +#include <linux/phy.h>
> #include <linux/phy/phy.h>
> #include <linux/platform_device.h>
> #include <linux/regmap.h>
> @@ -104,20 +105,24 @@ struct serdes_mux {
> u8 idx;
> u8 port;
> enum phy_mode mode;
> + int submode;
> u32 mask;
> u32 mux;
> };
>
> -#define SERDES_MUX(_idx, _port, _mode, _mask, _mux) { \
> +#define SERDES_MUX(_idx, _port, _mode, _submode, _mask, _mux) { \
> .idx = _idx, \
> .port = _port, \
> .mode = _mode, \
> + .submode = _submode, \
> .mask = _mask, \
> .mux = _mux, \
> }
>
> -#define SERDES_MUX_SGMII(i, p, m, c) SERDES_MUX(i, p, PHY_MODE_SGMII, m, c)
> -#define SERDES_MUX_QSGMII(i, p, m, c) SERDES_MUX(i, p, PHY_MODE_QSGMII, m, c)
> +#define SERDES_MUX_SGMII(i, p, m, c) \
> + SERDES_MUX(i, p, PHY_MODE_ETHERNET, PHY_INTERFACE_MODE_SGMII, m, c)
> +#define SERDES_MUX_QSGMII(i, p, m, c) \
> + SERDES_MUX(i, p, PHY_MODE_ETHERNET, PHY_INTERFACE_MODE_QSGMII, m, c)
>
> static const struct serdes_mux ocelot_serdes_muxes[] = {
> SERDES_MUX_SGMII(SERDES1G(0), 0, 0, 0),
> @@ -154,7 +159,7 @@ static const struct serdes_mux ocelot_serdes_muxes[] = {
> SERDES_MUX_SGMII(SERDES6G(1), 8, 0, 0),
> SERDES_MUX_SGMII(SERDES6G(2), 10, HSIO_HW_CFG_PCIE_ENA |
> HSIO_HW_CFG_DEV2G5_10_MODE, 0),
> - SERDES_MUX(SERDES6G(2), 10, PHY_MODE_PCIE, HSIO_HW_CFG_PCIE_ENA,
> + SERDES_MUX(SERDES6G(2), 10, PHY_MODE_PCIE, 0, HSIO_HW_CFG_PCIE_ENA,
> HSIO_HW_CFG_PCIE_ENA),
> };
>
> @@ -164,12 +169,17 @@ static int serdes_set_mode(struct phy *phy, enum phy_mode mode, int submode)
> unsigned int i;
> int ret;
>
> + /* As of now only PHY_MODE_ETHERNET is supported */
> + if (mode != PHY_MODE_ETHERNET)
> + return -EOPNOTSUPP;
> +
> for (i = 0; i < ARRAY_SIZE(ocelot_serdes_muxes); i++) {
> if (macro->idx != ocelot_serdes_muxes[i].idx ||
> - mode != ocelot_serdes_muxes[i].mode)
> + mode != ocelot_serdes_muxes[i].mode ||
> + submode != ocelot_serdes_muxes[i].submode)
> continue;
We will most likely need to rework this to ignore the submode of the
PCIe muxing if the mode is PCIe but let´s figure this out when we add
support for PCIe muxing.
Thanks,
Quentin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH bpf-next v2] bpf: libbpf: retry map creation without the name
From: Stanislav Fomichev @ 2018-11-19 22:49 UTC (permalink / raw)
To: netdev, ast, daniel; +Cc: vladum, Stanislav Fomichev
In-Reply-To: <65863961-d443-0ce7-0659-659f1bf76463@iogearbox.net>
Since commit 88cda1c9da02 ("bpf: libbpf: Provide basic API support
to specify BPF obj name"), libbpf unconditionally sets bpf_attr->name
for maps. Pre v4.14 kernels don't know about map names and return an
error about unexpected non-zero data. Retry sys_bpf without a map
name to cover older kernels.
v2 changes:
* check for errno == EINVAL as suggested by Daniel Borkmann
Signed-off-by: Stanislav Fomichev <sdf@google.com>
---
tools/lib/bpf/bpf.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
index 03f9bcc4ef50..961e1b9fc592 100644
--- a/tools/lib/bpf/bpf.c
+++ b/tools/lib/bpf/bpf.c
@@ -69,6 +69,7 @@ int bpf_create_map_xattr(const struct bpf_create_map_attr *create_attr)
{
__u32 name_len = create_attr->name ? strlen(create_attr->name) : 0;
union bpf_attr attr;
+ int ret;
memset(&attr, '\0', sizeof(attr));
@@ -86,7 +87,15 @@ int bpf_create_map_xattr(const struct bpf_create_map_attr *create_attr)
attr.map_ifindex = create_attr->map_ifindex;
attr.inner_map_fd = create_attr->inner_map_fd;
- return sys_bpf(BPF_MAP_CREATE, &attr, sizeof(attr));
+ ret = sys_bpf(BPF_MAP_CREATE, &attr, sizeof(attr));
+ if (ret < 0 && errno == EINVAL && create_attr->name) {
+ /* Retry the same syscall, but without the name.
+ * Pre v4.14 kernels don't support map names.
+ */
+ memset(attr.map_name, 0, sizeof(attr.map_name));
+ return sys_bpf(BPF_MAP_CREATE, &attr, sizeof(attr));
+ }
+ return ret;
}
int bpf_create_map_node(enum bpf_map_type map_type, const char *name,
--
2.19.1.1215.g8438c0b245-goog
^ permalink raw reply related
* Re: [PATCH net] sctp: not increase stream's incnt before sending addstrm_in request
From: David Miller @ 2018-11-19 22:47 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman
In-Reply-To: <74669ed0fa48471de2b6b1ebb3580858e4fa7895.1542549589.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Sun, 18 Nov 2018 21:59:49 +0800
> Different from processing the addstrm_out request, The receiver handles
> an addstrm_in request by sending back an addstrm_out request to the
> sender who will increase its stream's in and incnt later.
>
> Now stream->incnt has been increased since it sent out the addstrm_in
> request in sctp_send_add_streams(), with the wrong stream->incnt will
> even cause crash when copying stream info from the old stream's in to
> the new one's in sctp_process_strreset_addstrm_out().
>
> This patch is to fix it by simply removing the stream->incnt change
> from sctp_send_add_streams().
>
> Fixes: 242bd2d519d7 ("sctp: implement sender-side procedures for Add Incoming/Outgoing Streams Request Parameter")
> Reported-by: Jianwen Ji <jiji@redhat.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next 01/18] net: skb_scrub_packet(): Scrub offload_fwd_mark
From: Petr Machata @ 2018-11-19 22:41 UTC (permalink / raw)
To: David Miller
Cc: Ido Schimmel, netdev@vger.kernel.org,
linux-kselftest@vger.kernel.org, shuah@kernel.org, Jiri Pirko,
roopa@cumulusnetworks.com, mlxsw
In-Reply-To: <20181119.110745.12820215456503449.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Ido Schimmel <idosch@mellanox.com>
> Date: Mon, 19 Nov 2018 16:11:07 +0000
>
>> From: Petr Machata <petrm@mellanox.com>
>>
>> When a packet is trapped and the corresponding SKB marked as
>> already-forwarded, it retains this marking even after it is forwarded
>> across veth links into another bridge. There, since it ingresses the
>> bridge over veth, which doesn't have offload_fwd_mark, it triggers a
>> warning in nbp_switchdev_frame_mark().
>>
>> Then nbp_switchdev_allowed_egress() decides not to allow egress from
>> this bridge through another veth, because the SKB is already marked, and
>> the mark (of 0) of course matches. Thus the packet is incorrectly
>> blocked.
>>
>> Solve by resetting offload_fwd_mark() in skb_scrub_packet(). That
>> function is called from tunnels and also from veth, and thus catches the
>> cases where traffic is forwarded between bridges and transformed in a
>> way that invalidates the marking.
>>
>> Signed-off-by: Petr Machata <petrm@mellanox.com>
>> Suggested-by: Ido Schimmel <idosch@mellanox.com>
>> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
>
> As a bug fix this seems relevant for 'net' instead of 'net-next'.
Sure, I'll send for net.
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: libbpf: retry map creation without the name
From: Daniel Borkmann @ 2018-11-19 22:36 UTC (permalink / raw)
To: Stanislav Fomichev, netdev, ast; +Cc: vladum
In-Reply-To: <20181119213509.16417-1-sdf@google.com>
On 11/19/2018 10:35 PM, Stanislav Fomichev wrote:
> Since commit 88cda1c9da02 ("bpf: libbpf: Provide basic API support
> to specify BPF obj name"), libbpf unconditionally sets bpf_attr->name
> for maps. Pre v4.14 kernels don't know about map names and return an
> error about unexpected non-zero data. Retry sys_bpf without a map
> name to cover older kernels.
Looks good, small nit below:
> Signed-off-by: Stanislav Fomichev <sdf@google.com>
> ---
> tools/lib/bpf/bpf.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
> index 03f9bcc4ef50..673175bc06ee 100644
> --- a/tools/lib/bpf/bpf.c
> +++ b/tools/lib/bpf/bpf.c
> @@ -69,6 +69,7 @@ int bpf_create_map_xattr(const struct bpf_create_map_attr *create_attr)
> {
> __u32 name_len = create_attr->name ? strlen(create_attr->name) : 0;
> union bpf_attr attr;
> + int ret;
>
> memset(&attr, '\0', sizeof(attr));
>
> @@ -86,7 +87,15 @@ int bpf_create_map_xattr(const struct bpf_create_map_attr *create_attr)
> attr.map_ifindex = create_attr->map_ifindex;
> attr.inner_map_fd = create_attr->inner_map_fd;
>
> - return sys_bpf(BPF_MAP_CREATE, &attr, sizeof(attr));
> + ret = sys_bpf(BPF_MAP_CREATE, &attr, sizeof(attr));
> + if (ret < 0 && create_attr->name) {
Could you also check errno being EINVAL here so that we do not try to
confuse it with an error coming from insufficient memlock which is
EPERM in that case.
> + /* Retry the same syscall, but without the name.
> + * Pre v4.14 kernels don't support map names.
> + */
> + memset(attr.map_name, 0, sizeof(attr.map_name));
> + return sys_bpf(BPF_MAP_CREATE, &attr, sizeof(attr));
> + }
> + return ret;
> }
>
> int bpf_create_map_node(enum bpf_map_type map_type, const char *name,
>
^ permalink raw reply
* Re: [PATCH net-next 0/8] net: hns3: Adds support of debugfs to HNS3 driver
From: Jakub Kicinski @ 2018-11-19 22:29 UTC (permalink / raw)
To: Salil Mehta
Cc: davem, yisen.zhuang, lipeng321, mehta.salil, netdev, linux-kernel,
linuxarm
In-Reply-To: <20181119211845.23168-1-salil.mehta@huawei.com>
On Mon, 19 Nov 2018 21:18:37 +0000, Salil Mehta wrote:
> This patchset adds support of debugfs to the HNS3 driver.
>
> Support has been added to query info related to below items:
> 1. Queue related
> 2. Flow Director
> 3. TC config
> 4. Transmit Module/Scheduler
> 5. QoS pause
> 6. QoS buffer
> 7. QoS prio map
Please provide a more informative cover letter.
From a short glance it looks like you add a single debugfs file, which
can be written to, and upon that write the driver will dump stuff into
kernel logs.
^ permalink raw reply
* Re: [PATCH mlx5-next 00/10] Collection of ODP fixes
From: Jason Gunthorpe @ 2018-11-19 22:25 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, RDMA mailing list, Artemy Kovalyov, Majd Dibbiny,
Moni Shoua, Saeed Mahameed, linux-netdev
In-Reply-To: <20181112204310.GI3695@mtr-leonro.mtl.com>
On Mon, Nov 12, 2018 at 01:43:15PM -0700, Leon Romanovsky wrote:
> On Thu, Nov 08, 2018 at 09:10:07PM +0200, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@mellanox.com>
> >
> > Hi,
> >
> > This is collection of fixes to mlx5_core and mlx5_ib ODP logic.
> > There are two main reasons why we decided to forward it to mlx5-next
> > and not to rdma-rc or net like our other fixes.
> >
> > 1. We have large number of patches exactly in that area that are ready
> > for submission and we don't want to create extra merge work for
> > maintainers due to that. Among those future series (already ready and
> > tested): internal change of mlx5_core pagefaults handling, moving ODP
> > code to RDMA, change in EQ mechanism, simplification and moving SRQ QP
> > to RDMA, extra fixes to mlx5_ib ODP and ODP SRQ support.
> >
> > 2. Most of those fixes are for old bugs and there is no rush to fix them
> > right now (in -rc1/-rc2).
> >
> > Thanks
> >
> > Moni Shoua (10):
> > net/mlx5: Release resource on error flow
> > net/mlx5: Add interface to hold and release core resources
> > net/mlx5: Enumerate page fault types
> > IB/mlx5: Lock QP during page fault handling
> > net/mlx5: Return success for PAGE_FAULT_RESUME in internal error state
> > net/mlx5: Use multi threaded workqueue for page fault handling
> > IB/mlx5: Improve ODP debugging messages
>
> Applied to mlx5-next
> b02394aa75e3 IB/mlx5: Improve ODP debugging messages
> 90290db7669b net/mlx5: Use multi threaded workqueue for page fault handling
> ef90c5e9757d net/mlx5: Return success for PAGE_FAULT_RESUME in internal error state
> 032080ab43ac IB/mlx5: Lock QP during page fault handling
> c99fefea2cc9 net/mlx5: Enumerate page fault types
> 27e95603f4df net/mlx5: Add interface to hold and release core resources
> 698114968a22 net/mlx5: Release resource on error flow
>
> > IB/mlx5: Avoid hangs due to a missing completion
> > IB/mlx5: Call PAGE_FAULT_RESUME command asynchronously
>
> Dropped to address feedback.
>
> > net/mlx5: Remove unused function
>
> Dropped, because it depends on dropped commit.
Okay, merged into for-next
Jason
^ permalink raw reply
* Realtek NIC uses over 1 Watt with no traffic
From: Paul Menzel @ 2018-11-20 8:40 UTC (permalink / raw)
To: Realtek linux nic maintainers; +Cc: David S. Miller, netdev, linux-kernel
Dear Linux folks,
Using Ubuntu 18.10, Linux 4.18.0-11-generic, PowerTOP 2.9 shows, the NIC
uses 1.77 Watts. A network cable is plugged in, but there is no real
traffic according to `iftop`. Only an email program is running.
$ lspci -nn -s 3:00.1
03:00.1 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168]
(rev 12)
Is that a measurement error, or does the NIC really need that much power?
> Der Akku meldet eine Entladungsrate von 10.2 W
> Der verbrauchte Strom ist: 0.00 J
> Grundsätzlich benötigte Energie wird auf 10.5 W geschätzt
>
> Energieschätz. Auslastung Gerätename
> 7.03 W 4,9% Display backlight
> 1.77 W 0,0 pkts/s Netzwerkschnittstelle: enp3s0f1(r8169)
Letting it run for a while, the value even grows to 3.5 Watts, but
closing and starting PowerTOP, it goes back to 1.7X Watts.
Kind regards,
Paul
^ permalink raw reply
* Re: Kernel 4.19 network performance - forwarding/routing normal users traffic
From: David Ahern @ 2018-11-19 21:59 UTC (permalink / raw)
To: Paweł Staszewski, Jesper Dangaard Brouer; +Cc: netdev, Yoel Caspersen
In-Reply-To: <d3631119-a5fc-b11d-fbad-9a57eeb80f7f@gmail.com>
On 11/9/18 5:06 PM, David Ahern wrote:
> On 11/9/18 9:21 AM, David Ahern wrote:
>>> Is there possible to add only counters from xdp for vlans ?
>>> This will help me in testing.
>> I will take a look today at adding counters that you can dump using
>> bpftool. It will be a temporary solution for this xdp program only.
>>
>
> Same tree, kernel-tables-wip-02 branch. Compile kernel and install.
> Compile samples as before.
new version:
https://github.com/dsahern/linux.git bpf/kernel-tables-wip-03
This one prototypes incrementing counters for VLAN devices (rx/tx,
packets and bytes). Counters for netdevices representing physical ports
should be managed by the NIC driver.
I will look at what can be done for packet captures (e.g., xdpdump and
https://github.com/facebookincubator/katran/tree/master/tools). Most
likely a project for next week.
^ permalink raw reply
* Re: linux-next: Signed-off-by missing for commit in the net tree
From: Xin Long @ 2018-11-20 8:25 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: davem, network dev, Linux-Next Mailing List, LKML
In-Reply-To: <20181120161546.1098b346@canb.auug.org.au>
On Tue, Nov 20, 2018 at 2:15 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Commit
>
> 69fec325a643 ("Revert "sctp: remove sctp_transport_pmtu_check"")
>
> is missing a Signed-off-by from its author.
Hi, Stephen, sorry about this.
David has reminded me, and I will be careful next time.
Do I need to do something for this one now?
Thanks.
^ permalink raw reply
* Re: netns_id in bpf_sk_lookup_{tcp,udp}
From: Joe Stringer @ 2018-11-19 21:59 UTC (permalink / raw)
To: Joe Stringer; +Cc: nicolas.dichtel, David Ahern, netdev, daniel
In-Reply-To: <CAOftzPidHn+hWsYY5UMRHaD35t_+bu6Amy2dZOS8DwGFFwNMkg@mail.gmail.com>
On Mon, 19 Nov 2018 at 12:54, Joe Stringer <joe@wand.net.nz> wrote:
>
> On Mon, 19 Nov 2018 at 12:29, Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> >
> > Le 19/11/2018 à 20:54, David Ahern a écrit :
> > > On 11/19/18 12:47 PM, Joe Stringer wrote:
> > >> On Mon, 19 Nov 2018 at 10:39, David Ahern <dsahern@gmail.com> wrote:
> > >>>
> > >>> On 11/19/18 11:36 AM, Joe Stringer wrote:
> > >>>> Hi David, thanks for pointing this out.
> > >>>>
> > >>>> This is more of an oversight through iterations, the runtime lookup
> > >>>> will fail to find a socket if the netns value is greater than the
> > >>>> range of a uint32 so I think it would actually make more sense to drop
> > >>>> the parameter size to u32 rather than u64 so that this would be
> > >>>> validated at load time rather than silently returning NULL because of
> > >>>> a bad parameter.
> > >>>
> > >>> ok. I was wondering if it was a u64 to handle nsid of 0 which as I
> > >>> understand it is a legal nsid. If you drop to u32, how do you know when
> > >>> nsid has been set?
> > >>
> > >> I was operating under the assumption that 0 represents the root netns
> > >> id, and cannot be assigned to another non-root netns.
> > >>
> > >> Looking at __peernet2id_alloc(), it seems to me like it attempts to
> > >> find a netns and if it cannot find one, returns 0, which then leads to
> > >> a scroll over the idr starting from 0 to INT_MAX to find a legitimate
> > >> id for the netns, so I think this is a fair assumption?
> > The NET_ID_ZERO trick is used to manage nsid 0 in net_eq_idr() (idr_for_each()
> > stops when the callback returns != 0).
> >
> > >>
> > >
> > > Maybe Nicolas can give a definitive answer; as I recall he added the
> > > NSID option. I have not had time to walk the code. But I do recall
> > > seeing an id of 0. e.g, on my dev box:
> > > $ ip netns
> > > vms (id: 0)
> > >
> > > And include/uapi/linux/net_namespace.h shows -1 as not assigned.
> > Yes, 0 is a valid value and can be assigned to any netns.
> > nsid are signed 32 bit values. Note that -1 (NETNSA_NSID_NOT_ASSIGNED) is used
> > by the kernel to express that the nsid is not assigned. It can also be used by
> > the user to let the kernel chooses a nsid.
> >
> > $ ip netns add foo
> > $ ip netns add bar
> > $ ip netns
> > bar
> > foo
> > $ ip netns set foo 0
> > $ ip netns set bar auto
> > $ ip netns
> > bar (id: 1)
> > foo (id: 0)
>
> OK, I'll fix this up then.
Here's what I have in mind:
@@ -2221,12 +2222,13 @@ union bpf_attr {
* **sizeof**\ (*tuple*\ **->ipv6**)
* Look for an IPv6 socket.
*
- * If the *netns* is zero, then the socket lookup table in the
- * netns associated with the *ctx* will be used. For the TC hooks,
- * this in the netns of the device in the skb. For socket hooks,
- * this in the netns of the socket. If *netns* is non-zero, then
- * it specifies the ID of the netns relative to the netns
- * associated with the *ctx*.
+ * If the *netns* is **BPF_F_SK_CURRENT_NS** or greater, then the
+ * socket lookup table in the netns associated with the *ctx* will
+ * will be used. For the TC hooks, this is the netns of the device
+ * in the skb. For socket hooks, this is the netns of the socket.
+ * If *netns* is less than **BPF_F_SK_CURRENT_NS**, then it
+ * specifies the ID of the netns relative to the netns associated
+ * with the *ctx*.
*
* All values for *flags* are reserved for future usage, and must
* be left at zero.
@@ -2409,6 +2411,9 @@ enum bpf_func_id {
/* BPF_FUNC_perf_event_output for sk_buff input context. */
#define BPF_F_CTXLEN_MASK (0xfffffULL << 32)
+/* BPF_FUNC_sk_lookup_tcp and BPF_FUNC_sk_lookup_udp flags. */
+#define BPF_F_SK_CURRENT_NS 0x80000000 /* For netns argument */
+
/* Mode for BPF_FUNC_skb_adjust_room helper. */
enum bpf_adj_room_mode {
BPF_ADJ_ROOM_NET,
Plus adjusting all of the internal types and the helper headers to use
u32. With the highest bit used to specify that the netns should be the
current netns, all other netns IDs should be available.
^ permalink raw reply
* [PATCH net] net/ibmnvic: Fix deadlock problem in reset
From: Juliet Kim @ 2018-11-19 21:59 UTC (permalink / raw)
To: netdev, linuxppc-dev; +Cc: julietk, tlfalcon, mwb, tyreld
This patch changes to use rtnl_lock only during a reset to avoid
deadlock that could occur when a thread operating close is holding
rtnl_lock and waiting for reset_lock acquired by another thread,
which is waiting for rtnl_lock in order to set the number of tx/rx
queues during a reset.
Also, we now setting the number of tx/rx queues during a soft reset
for failover or LPM events.
Signed-off-by: Juliet Kim <julietk@linux.vnet.ibm.com>
---
drivers/net/ethernet/ibm/ibmvnic.c | 59 +++++++++++++-----------------------
drivers/net/ethernet/ibm/ibmvnic.h | 2 +
2 files changed, 22 insertions(+), 39 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index 7893bef..4a5de59 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1103,20 +1103,15 @@ static int ibmvnic_open(struct net_device *netdev)
return 0;
}
- mutex_lock(&adapter->reset_lock);
-
if (adapter->state != VNIC_CLOSED) {
rc = ibmvnic_login(netdev);
- if (rc) {
- mutex_unlock(&adapter->reset_lock);
+ if (rc)
return rc;
- }
rc = init_resources(adapter);
if (rc) {
netdev_err(netdev, "failed to initialize resources\n");
release_resources(adapter);
- mutex_unlock(&adapter->reset_lock);
return rc;
}
}
@@ -1124,8 +1119,6 @@ static int ibmvnic_open(struct net_device *netdev)
rc = __ibmvnic_open(netdev);
netif_carrier_on(netdev);
- mutex_unlock(&adapter->reset_lock);
-
return rc;
}
@@ -1269,10 +1262,8 @@ static int ibmvnic_close(struct net_device *netdev)
return 0;
}
- mutex_lock(&adapter->reset_lock);
rc = __ibmvnic_close(netdev);
ibmvnic_cleanup(netdev);
- mutex_unlock(&adapter->reset_lock);
return rc;
}
@@ -1820,20 +1811,15 @@ static int do_reset(struct ibmvnic_adapter *adapter,
return rc;
} else if (adapter->req_rx_queues != old_num_rx_queues ||
adapter->req_tx_queues != old_num_tx_queues) {
- adapter->map_id = 1;
release_rx_pools(adapter);
release_tx_pools(adapter);
- rc = init_rx_pools(netdev);
- if (rc)
- return rc;
- rc = init_tx_pools(netdev);
- if (rc)
- return rc;
-
release_napi(adapter);
- rc = init_napi(adapter);
+ release_vpd_data(adapter);
+
+ rc = init_resources(adapter);
if (rc)
return rc;
+
} else {
rc = reset_tx_pools(adapter);
if (rc)
@@ -1917,17 +1903,8 @@ static int do_hard_reset(struct ibmvnic_adapter *adapter,
adapter->state = VNIC_PROBED;
return 0;
}
- /* netif_set_real_num_xx_queues needs to take rtnl lock here
- * unless wait_for_reset is set, in which case the rtnl lock
- * has already been taken before initializing the reset
- */
- if (!adapter->wait_for_reset) {
- rtnl_lock();
- rc = init_resources(adapter);
- rtnl_unlock();
- } else {
- rc = init_resources(adapter);
- }
+
+ rc = init_resources(adapter);
if (rc)
return rc;
@@ -1986,13 +1963,21 @@ static void __ibmvnic_reset(struct work_struct *work)
struct ibmvnic_rwi *rwi;
struct ibmvnic_adapter *adapter;
struct net_device *netdev;
+ bool we_lock_rtnl = false;
u32 reset_state;
int rc = 0;
adapter = container_of(work, struct ibmvnic_adapter, ibmvnic_reset);
netdev = adapter->netdev;
- mutex_lock(&adapter->reset_lock);
+ /* netif_set_real_num_xx_queues needs to take rtnl lock here
+ * unless wait_for_reset is set, in which case the rtnl lock
+ * has already been taken before initializing the reset
+ */
+ if (!adapter->wait_for_reset) {
+ rtnl_lock();
+ we_lock_rtnl = true;
+ }
reset_state = adapter->state;
rwi = get_next_rwi(adapter);
@@ -2020,12 +2005,11 @@ static void __ibmvnic_reset(struct work_struct *work)
if (rc) {
netdev_dbg(adapter->netdev, "Reset failed\n");
free_all_rwi(adapter);
- mutex_unlock(&adapter->reset_lock);
- return;
}
adapter->resetting = false;
- mutex_unlock(&adapter->reset_lock);
+ if (we_lock_rtnl)
+ rtnl_unlock();
}
static int ibmvnic_reset(struct ibmvnic_adapter *adapter,
@@ -4768,7 +4752,6 @@ static int ibmvnic_probe(struct vio_dev *dev, const struct vio_device_id *id)
INIT_WORK(&adapter->ibmvnic_reset, __ibmvnic_reset);
INIT_LIST_HEAD(&adapter->rwi_list);
- mutex_init(&adapter->reset_lock);
mutex_init(&adapter->rwi_lock);
adapter->resetting = false;
@@ -4840,8 +4823,8 @@ static int ibmvnic_remove(struct vio_dev *dev)
struct ibmvnic_adapter *adapter = netdev_priv(netdev);
adapter->state = VNIC_REMOVING;
- unregister_netdev(netdev);
- mutex_lock(&adapter->reset_lock);
+ rtnl_lock();
+ unregister_netdevice(netdev);
release_resources(adapter);
release_sub_crqs(adapter, 1);
@@ -4852,7 +4835,7 @@ static int ibmvnic_remove(struct vio_dev *dev)
adapter->state = VNIC_REMOVED;
- mutex_unlock(&adapter->reset_lock);
+ rtnl_unlock();
device_remove_file(&dev->dev, &dev_attr_failover);
free_netdev(netdev);
dev_set_drvdata(&dev->dev, NULL);
diff --git a/drivers/net/ethernet/ibm/ibmvnic.h b/drivers/net/ethernet/ibm/ibmvnic.h
index 18103b8..99c4f8d 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.h
+++ b/drivers/net/ethernet/ibm/ibmvnic.h
@@ -1075,7 +1075,7 @@ struct ibmvnic_adapter {
struct tasklet_struct tasklet;
enum vnic_state state;
enum ibmvnic_reset_reason reset_reason;
- struct mutex reset_lock, rwi_lock;
+ struct mutex rwi_lock;
struct list_head rwi_list;
struct work_struct ibmvnic_reset;
bool resetting;
^ permalink raw reply related
* Re
From: efn @ 2018-11-19 21:43 UTC (permalink / raw)
Hello
How are you? Am SARAH MONGAR. For an Export Business am, writing
to inform you, concerning business proposer in Agriculture raw
materials export supply to Germany. If you are good in Business kindly
write me on my mail I'D sarahmor1976@gmail.com
SARAH MONGAR
E-mail: sarahmor1976@gmail.com
Address: Ärztekammern
Postfach Germany
^ permalink raw reply
* Re: VETH & AF_PACKET problem
From: Willem de Bruijn @ 2018-11-19 21:51 UTC (permalink / raw)
To: Anand H. Krishnan; +Cc: Network Development
In-Reply-To: <CAF=yD-+gmtpc2gQOTv2_2_+WEsiozg0USV5P1rsyPs37rMXz2w@mail.gmail.com>
On Mon, Nov 19, 2018 at 12:54 PM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> On Mon, Nov 19, 2018 at 6:00 AM Anand H. Krishnan
> <anandhkrishnan@gmail.com> wrote:
> >
> > Hello,
> >
> > I tried the 4.19.2 kernel without success. You were probably right
> > that skb_orphan
> > is indeed called from somewhere in the receive path. I had an
> > instrumented kernel
> > and the following is what I see:
>
> Thanks for verifying.
>
> I was also able to reproduce it without veth by looping a packet
> to another packet socket that delays reading from the socket.
>
> A very preliminary patch is to mark the socket as zerocopy in
> tpacket_fill_skb to trigger skb_copy_ubufs whenever the
> packet gets cloned or enters the receive path:
>
> @@ -2462,6 +2462,9 @@ static int tpacket_fill_skb(struct packet_sock
> *po, struct sk_buff *skb,
> skb->tstamp = sockc->transmit_time;
> sock_tx_timestamp(&po->sk, sockc->tsflags, &skb_shinfo(skb)->tx_flags);
> skb_shinfo(skb)->destructor_arg = ph.raw;
> + skb_shinfo(skb)->tx_flags |= SKBTX_ZEROCOPY_FRAG;
>
> This requires at the least a fixup in skb_zcopy_clear to handle this
> special case and not call uarg->callback (because
> skb_shinfo(skb)->destructor_arg is of a different type for
> tpacket_snd). I'll share a patch to test when I have something
> more concrete.
These packets already call an skb destructor when the original skb is
released, tpacket_destruct_skb, to release the slot and record the
timestamp of original submission.
We cannot change that timestamp until all skbs are freed. And, we also
do not want two indirect function calls, one for tpacket on the original
skb and one for zcopy on the last skb clone.
Instead, disallow cloning and refcounted ubufs, similar to the
existing tun/tap zerocopy driver. Call skb_copy_ubufs when
cloning, looping into the receive path, ..
Mark these packets as being zerocopy pages (SKBTX_ZEROCOP_FRAG)
But, we cannot assign skb_shinfo(skb)->destructor_arg to hold a uarg,
because tpacket already uses that for tpacket_destruct_skb. We also do
not want or need the extra alloc/free. So introduce a zerocopy variant that
expects this field to not be dereferencable.
I did not find a cleaner way to do this so far than with pointer
tricks. Tentative
patch that fixes the issue in my test:
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index a2e8297a5b00..c500e3c86a12 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1334,6 +1334,22 @@ static inline void skb_zcopy_set(struct sk_buff
*skb, struct ubuf_info *uarg)
}
}
+static inline void skb_zcopy_set_nouarg(struct sk_buff *skb, void *val)
+{
+ skb_shinfo(skb)->destructor_arg = (void *)((uintptr_t) val | 0x1UL);
+ skb_shinfo(skb)->tx_flags |= SKBTX_ZEROCOPY_FRAG;
+}
+
+static inline bool skb_zcopy_is_nouarg(struct sk_buff *skb)
+{
+ return (uintptr_t) skb_shinfo(skb)->destructor_arg & 0x1UL;
+}
+
+static inline void * skb_zcopy_get_nouarg(struct sk_buff *skb)
+{
+ return (void *)((uintptr_t) skb_shinfo(skb)->destructor_arg & ~0x1UL);
+}
+
/* Release a reference on a zerocopy structure */
static inline void skb_zcopy_clear(struct sk_buff *skb, bool zerocopy)
{
@@ -1343,7 +1359,7 @@ static inline void skb_zcopy_clear(struct
sk_buff *skb, bool zerocopy)
if (uarg->callback == sock_zerocopy_callback) {
uarg->zerocopy = uarg->zerocopy && zerocopy;
sock_zerocopy_put(uarg);
- } else {
+ } else if (!skb_zcopy_is_nouarg(skb)) {
uarg->callback(uarg, zerocopy);
}
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index ec3095f13aae..a74650e98f42 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -2394,7 +2394,7 @@ static void tpacket_destruct_skb(struct sk_buff *skb)
void *ph;
__u32 ts;
- ph = skb_shinfo(skb)->destructor_arg;
+ ph = skb_zcopy_get_nouarg(skb);
packet_dec_pending(&po->tx_ring);
ts = __packet_set_timestamp(po, ph, skb);
@@ -2461,7 +2461,7 @@ static int tpacket_fill_skb(struct packet_sock
*po, struct sk_buff *skb,
skb->mark = po->sk.sk_mark;
skb->tstamp = sockc->transmit_time;
sock_tx_timestamp(&po->sk, sockc->tsflags, &skb_shinfo(skb)->tx_flags);
- skb_shinfo(skb)->destructor_arg = ph.raw;
+ skb_zcopy_set_nouarg(skb, ph.raw);
skb_reserve(skb, hlen);
skb_reset_network_header(skb);
^ permalink raw reply related
* RE: [PATCH net-next 12/12] qede: use ethtool_rx_flow_rule() to remove duplicated parser code
From: Chopra, Manish @ 2018-11-19 21:44 UTC (permalink / raw)
To: Pablo Neira Ayuso, netdev@vger.kernel.org
Cc: davem@davemloft.net, thomas.lendacky@amd.com,
f.fainelli@gmail.com, Elior, Ariel, michael.chan@broadcom.com,
santosh@chelsio.com, madalin.bucur@nxp.com,
yisen.zhuang@huawei.com, salil.mehta@huawei.com,
jeffrey.t.kirsher@intel.com, tariqt@mellanox.com,
saeedm@mellanox.com, jiri@mellanox.com, idosch@mellanox.com,
jakub.kicinski@netronome.com,
"peppe.cavallaro@st.com" <peppe.cav
In-Reply-To: <20181119001519.12124-13-pablo@netfilter.org>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> On
> Behalf Of Pablo Neira Ayuso
> Sent: Monday, November 19, 2018 5:45 AM
> To: netdev@vger.kernel.org
> Cc: davem@davemloft.net; thomas.lendacky@amd.com;
> f.fainelli@gmail.com; Elior, Ariel <Ariel.Elior@cavium.com>;
> michael.chan@broadcom.com; santosh@chelsio.com;
> madalin.bucur@nxp.com; yisen.zhuang@huawei.com;
> salil.mehta@huawei.com; jeffrey.t.kirsher@intel.com; tariqt@mellanox.com;
> saeedm@mellanox.com; jiri@mellanox.com; idosch@mellanox.com;
> jakub.kicinski@netronome.com; peppe.cavallaro@st.com;
> grygorii.strashko@ti.com; andrew@lunn.ch;
> vivien.didelot@savoirfairelinux.com; alexandre.torgue@st.com;
> joabreu@synopsys.com; linux-net-drivers@solarflare.com;
> ganeshgr@chelsio.com; ogerlitz@mellanox.com
> Subject: [PATCH net-next 12/12] qede: use ethtool_rx_flow_rule() to remove
> duplicated parser code
>
> External Email
>
> The qede driver supports for ethtool_rx_flow_spec and flower, both
> codebases look very similar.
>
> This patch uses the ethtool_rx_flow_rule() infrastructure to remove the
> duplicated ethtool_rx_flow_spec parser and consolidate ACL offload support
> around the flow_rule infrastructure.
>
> Furthermore, more code can be consolidated by merging
> qede_add_cls_rule() and qede_add_tc_flower_fltr(), these two functions
> also look very similar.
>
> This driver currently provides simple ACL support, such as 5-tuple matching,
> drop policy and queue to CPU.
>
> Drivers that support more features can benefit from this infrastructure to
> save even more redundant codebase.
>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
> ---
> Note that, after this patch, qede_add_cls_rule() and
> qede_add_tc_flower_fltr() can be also consolidated since their code is
> redundant.
>
> drivers/net/ethernet/qlogic/qede/qede_filter.c | 246 ++++++-------------------
> 1 file changed, 53 insertions(+), 193 deletions(-)
>
> diff --git a/drivers/net/ethernet/qlogic/qede/qede_filter.c
> b/drivers/net/ethernet/qlogic/qede/qede_filter.c
> index aca302c3261b..f82b26ba8f80 100644
> --- a/drivers/net/ethernet/qlogic/qede/qede_filter.c
> +++ b/drivers/net/ethernet/qlogic/qede/qede_filter.c
> @@ -1578,30 +1578,6 @@ static void qede_flow_build_ipv6_hdr(struct
> qede_arfs_tuple *t,
> ports[1] = t->dst_port;
> }
>
> -/* Validate fields which are set and not accepted by the driver */ -static int
> qede_flow_spec_validate_unused(struct qede_dev *edev,
> - struct ethtool_rx_flow_spec *fs)
> -{
> - if (fs->flow_type & FLOW_MAC_EXT) {
> - DP_INFO(edev, "Don't support MAC extensions\n");
> - return -EOPNOTSUPP;
> - }
> -
> - if ((fs->flow_type & FLOW_EXT) &&
> - (fs->h_ext.vlan_etype || fs->h_ext.vlan_tci)) {
> - DP_INFO(edev, "Don't support vlan-based classification\n");
> - return -EOPNOTSUPP;
> - }
> -
> - if ((fs->flow_type & FLOW_EXT) &&
> - (fs->h_ext.data[0] || fs->h_ext.data[1])) {
> - DP_INFO(edev, "Don't support user defined data\n");
> - return -EOPNOTSUPP;
> - }
> -
> - return 0;
> -}
> -
> static int qede_set_v4_tuple_to_profile(struct qede_dev *edev,
> struct qede_arfs_tuple *t) { @@ -1665,132 +1641,6
> @@ static int qede_set_v6_tuple_to_profile(struct qede_dev *edev,
> return 0;
> }
>
> -static int qede_flow_spec_to_tuple_ipv4_common(struct qede_dev *edev,
> - struct qede_arfs_tuple *t,
> - struct ethtool_rx_flow_spec *fs)
> -{
> - if ((fs->h_u.tcp_ip4_spec.ip4src &
> - fs->m_u.tcp_ip4_spec.ip4src) != fs->h_u.tcp_ip4_spec.ip4src) {
> - DP_INFO(edev, "Don't support IP-masks\n");
> - return -EOPNOTSUPP;
> - }
> -
> - if ((fs->h_u.tcp_ip4_spec.ip4dst &
> - fs->m_u.tcp_ip4_spec.ip4dst) != fs->h_u.tcp_ip4_spec.ip4dst) {
> - DP_INFO(edev, "Don't support IP-masks\n");
> - return -EOPNOTSUPP;
> - }
> -
> - if ((fs->h_u.tcp_ip4_spec.psrc &
> - fs->m_u.tcp_ip4_spec.psrc) != fs->h_u.tcp_ip4_spec.psrc) {
> - DP_INFO(edev, "Don't support port-masks\n");
> - return -EOPNOTSUPP;
> - }
> -
> - if ((fs->h_u.tcp_ip4_spec.pdst &
> - fs->m_u.tcp_ip4_spec.pdst) != fs->h_u.tcp_ip4_spec.pdst) {
> - DP_INFO(edev, "Don't support port-masks\n");
> - return -EOPNOTSUPP;
> - }
> -
> - if (fs->h_u.tcp_ip4_spec.tos) {
> - DP_INFO(edev, "Don't support tos\n");
> - return -EOPNOTSUPP;
> - }
> -
> - t->eth_proto = htons(ETH_P_IP);
> - t->src_ipv4 = fs->h_u.tcp_ip4_spec.ip4src;
> - t->dst_ipv4 = fs->h_u.tcp_ip4_spec.ip4dst;
> - t->src_port = fs->h_u.tcp_ip4_spec.psrc;
> - t->dst_port = fs->h_u.tcp_ip4_spec.pdst;
> -
> - return qede_set_v4_tuple_to_profile(edev, t);
> -}
> -
> -static int qede_flow_spec_to_tuple_tcpv4(struct qede_dev *edev,
> - struct qede_arfs_tuple *t,
> - struct ethtool_rx_flow_spec *fs)
> -{
> - t->ip_proto = IPPROTO_TCP;
> -
> - if (qede_flow_spec_to_tuple_ipv4_common(edev, t, fs))
> - return -EINVAL;
> -
> - return 0;
> -}
> -
> -static int qede_flow_spec_to_tuple_udpv4(struct qede_dev *edev,
> - struct qede_arfs_tuple *t,
> - struct ethtool_rx_flow_spec *fs)
> -{
> - t->ip_proto = IPPROTO_UDP;
> -
> - if (qede_flow_spec_to_tuple_ipv4_common(edev, t, fs))
> - return -EINVAL;
> -
> - return 0;
> -}
> -
> -static int qede_flow_spec_to_tuple_ipv6_common(struct qede_dev *edev,
> - struct qede_arfs_tuple *t,
> - struct ethtool_rx_flow_spec *fs)
> -{
> - struct in6_addr zero_addr;
> -
> - memset(&zero_addr, 0, sizeof(zero_addr));
> -
> - if ((fs->h_u.tcp_ip6_spec.psrc &
> - fs->m_u.tcp_ip6_spec.psrc) != fs->h_u.tcp_ip6_spec.psrc) {
> - DP_INFO(edev, "Don't support port-masks\n");
> - return -EOPNOTSUPP;
> - }
> -
> - if ((fs->h_u.tcp_ip6_spec.pdst &
> - fs->m_u.tcp_ip6_spec.pdst) != fs->h_u.tcp_ip6_spec.pdst) {
> - DP_INFO(edev, "Don't support port-masks\n");
> - return -EOPNOTSUPP;
> - }
> -
> - if (fs->h_u.tcp_ip6_spec.tclass) {
> - DP_INFO(edev, "Don't support tclass\n");
> - return -EOPNOTSUPP;
> - }
> -
> - t->eth_proto = htons(ETH_P_IPV6);
> - memcpy(&t->src_ipv6, &fs->h_u.tcp_ip6_spec.ip6src,
> - sizeof(struct in6_addr));
> - memcpy(&t->dst_ipv6, &fs->h_u.tcp_ip6_spec.ip6dst,
> - sizeof(struct in6_addr));
> - t->src_port = fs->h_u.tcp_ip6_spec.psrc;
> - t->dst_port = fs->h_u.tcp_ip6_spec.pdst;
> -
> - return qede_set_v6_tuple_to_profile(edev, t, &zero_addr);
> -}
> -
> -static int qede_flow_spec_to_tuple_tcpv6(struct qede_dev *edev,
> - struct qede_arfs_tuple *t,
> - struct ethtool_rx_flow_spec *fs)
> -{
> - t->ip_proto = IPPROTO_TCP;
> -
> - if (qede_flow_spec_to_tuple_ipv6_common(edev, t, fs))
> - return -EINVAL;
> -
> - return 0;
> -}
> -
> -static int qede_flow_spec_to_tuple_udpv6(struct qede_dev *edev,
> - struct qede_arfs_tuple *t,
> - struct ethtool_rx_flow_spec *fs)
> -{
> - t->ip_proto = IPPROTO_UDP;
> -
> - if (qede_flow_spec_to_tuple_ipv6_common(edev, t, fs))
> - return -EINVAL;
> -
> - return 0;
> -}
> -
> /* Must be called while qede lock is held */ static struct
> qede_arfs_fltr_node * qede_flow_find_fltr(struct qede_dev *edev, struct
> qede_arfs_tuple *t) @@ -1875,25 +1725,32 @@ static int
> qede_parse_actions(struct qede_dev *edev,
> struct flow_action *flow_action) {
> const struct flow_action_key *act;
> - int rc = -EINVAL, num_act = 0, i;
> - bool is_drop = false;
> + int i;
>
> if (!flow_action_has_keys(flow_action)) {
> - DP_NOTICE(edev, "No tc actions received\n");
> - return rc;
> + DP_NOTICE(edev, "No actions received\n");
> + return -EINVAL;
> }
>
> flow_action_for_each(i, act, flow_action) {
> - num_act++;
> + switch (act->id) {
> + case FLOW_ACTION_KEY_DROP:
> + break;
> + case FLOW_ACTION_KEY_QUEUE:
> + if (ethtool_get_flow_spec_ring_vf(act->queue_index))
> + break;
>
> - if (act->id == FLOW_ACTION_KEY_DROP)
> - is_drop = true;
> + if (act->queue_index >= QEDE_RSS_COUNT(edev)) {
> + DP_INFO(edev, "Queue out-of-bounds\n");
> + return -EINVAL;
> + }
> + break;
> + default:
> + return -EINVAL;
> + }
> }
>
> - if (num_act == 1 && is_drop)
> - return 0;
> -
> - return rc;
> + return 0;
> }
>
> static int
> @@ -2147,16 +2004,17 @@ int qede_add_tc_flower_fltr(struct qede_dev
> *edev, __be16 proto, }
>
> static int qede_flow_spec_validate(struct qede_dev *edev,
> - struct ethtool_rx_flow_spec *fs,
> - struct qede_arfs_tuple *t)
> + struct flow_action *flow_action,
> + struct qede_arfs_tuple *t,
> + __u32 location)
> {
> - if (fs->location >= QEDE_RFS_MAX_FLTR) {
> + if (location >= QEDE_RFS_MAX_FLTR) {
> DP_INFO(edev, "Location out-of-bounds\n");
> return -EINVAL;
> }
>
> /* Check location isn't already in use */
> - if (test_bit(fs->location, edev->arfs->arfs_fltr_bmap)) {
> + if (test_bit(location, edev->arfs->arfs_fltr_bmap)) {
> DP_INFO(edev, "Location already in use\n");
> return -EINVAL;
> }
> @@ -2170,46 +2028,53 @@ static int qede_flow_spec_validate(struct
> qede_dev *edev,
> return -EINVAL;
> }
>
> - /* If drop requested then no need to validate other data */
> - if (fs->ring_cookie == RX_CLS_FLOW_DISC)
> - return 0;
> -
> - if (ethtool_get_flow_spec_ring_vf(fs->ring_cookie))
> - return 0;
> -
> - if (fs->ring_cookie >= QEDE_RSS_COUNT(edev)) {
> - DP_INFO(edev, "Queue out-of-bounds\n");
> + if (qede_parse_actions(edev, flow_action))
> return -EINVAL;
> - }
>
> return 0;
> }
>
> -static int qede_flow_spec_to_tuple(struct qede_dev *edev,
> - struct qede_arfs_tuple *t,
> - struct ethtool_rx_flow_spec *fs)
> +static int qede_flow_spec_to_rule(struct qede_dev *edev,
> + struct qede_arfs_tuple *t,
> + struct ethtool_rx_flow_spec *fs)
> {
> - memset(t, 0, sizeof(*t));
> -
> - if (qede_flow_spec_validate_unused(edev, fs))
> - return -EOPNOTSUPP;
> + struct tc_cls_flower_offload f = {};
> + struct flow_rule *flow_rule;
> + __be16 proto;
> + int err = 0;
>
> switch ((fs->flow_type & ~FLOW_EXT)) {
> case TCP_V4_FLOW:
> - return qede_flow_spec_to_tuple_tcpv4(edev, t, fs);
> case UDP_V4_FLOW:
> - return qede_flow_spec_to_tuple_udpv4(edev, t, fs);
> + proto = htons(ETH_P_IP);
> + break;
> case TCP_V6_FLOW:
> - return qede_flow_spec_to_tuple_tcpv6(edev, t, fs);
> case UDP_V6_FLOW:
> - return qede_flow_spec_to_tuple_udpv6(edev, t, fs);
> + proto = htons(ETH_P_IPV6);
> + break;
> default:
> DP_VERBOSE(edev, NETIF_MSG_IFUP,
> "Can't support flow of type %08x\n", fs->flow_type);
> return -EOPNOTSUPP;
> }
>
> - return 0;
> + flow_rule = ethtool_rx_flow_rule(fs);
> + if (!flow_rule)
> + return -ENOMEM;
> +
> + f.rule = *flow_rule;
> +
> + if (qede_parse_flower_attr(edev, proto, &f, t)) {
> + err = -EINVAL;
> + goto err_out;
> + }
> +
> + /* Make sure location is valid and filter isn't already set */
> + err = qede_flow_spec_validate(edev, &f.rule.action, t,
> +fs->location);
> +err_out:
> + ethtool_rx_flow_rule_free(flow_rule);
> + return err;
> +
> }
>
> int qede_add_cls_rule(struct qede_dev *edev, struct ethtool_rxnfc *info)
> @@ -2227,12 +2092,7 @@ int qede_add_cls_rule(struct qede_dev *edev,
> struct ethtool_rxnfc *info)
> }
>
> /* Translate the flow specification into something fittign our DB */
> - rc = qede_flow_spec_to_tuple(edev, &t, fsp);
> - if (rc)
> - goto unlock;
> -
> - /* Make sure location is valid and filter isn't already set */
> - rc = qede_flow_spec_validate(edev, fsp, &t);
> + rc = qede_flow_spec_to_rule(edev, &t, fsp);
> if (rc)
> goto unlock;
>
> --
> 2.11.0
We will need some time to test these changes as it is changing this driver flows significantly.
Right now from the quick test of couple of ethtool commands below, which seems to be failing with this patch. They used to pass before this patch.
# ethtool -N eth0 flow-type tcp4 dst-port 5550 action -1
rmgr: Cannot insert RX class rule: Invalid argument
# dmesg -c
[12482.547161] [qede_parse_flower_attr:1930(eth0)]Invalid tc protocol request
It seem like ip_proto is not being set from below case, as flow_rule_match_key() seems to be returning false.
if (flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_BASIC)) {
struct flow_match_basic match;
flow_rule_match_basic(rule, &match);
ip_proto = match.key->ip_proto;
}
# ethtool -N eth0 flow-type tcp4 src-ip 192.168.40.200 dst-ip 192.168.50.200 src-port 6660 dst-port 5550 action -1
rmgr: Cannot insert RX class rule: Invalid argument
# dmesg -c
For this case, in function qede_tc_parse_ports() flow_rule_match_key() is returning false.
if (flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_PORTS)) {
struct flow_match_ports match;
--
--
}
Thanks.
^ permalink raw reply
* Re: [PATCH v2 1/3] Bluetooth: Add quirk for reading BD_ADDR from fwnode property
From: Matthias Kaehlcke @ 2018-11-19 21:44 UTC (permalink / raw)
To: Marcel Holtmann, Johan Hedberg, David S . Miller, Loic Poulain
Cc: linux-bluetooth, netdev, linux-kernel, Balakrishna Godavarthi,
Brian Norris, Dmitry Grinberg
In-Reply-To: <20181030004415.237101-2-mka@chromium.org>
Hi Marcel,
is this in line with what you suggested at
https://lore.kernel.org/patchwork/patch/992280/#1183789 ?
Thanks
Matthias
On Mon, Oct 29, 2018 at 05:44:13PM -0700, Matthias Kaehlcke wrote:
> Add HCI_QUIRK_USE_BDADDR_PROPERTY to allow controllers to retrieve
> the public Bluetooth address from the firmware node property
> 'local-bd-address'. If quirk is set and the property does not exist
> or is invalid the controller is marked as unconfigured.
>
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> Reviewed-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>
> ---
> Changes in v2:
> - added check for return value of ->setup()
> - only read BD_ADDR from the property if it isn't assigned yet. This
> is needed to support configuration from user space
> - refactored the branch of the new quirk to get rid of 'bd_addr_set'
> - added 'Reviewed-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>' tag
> ---
> include/net/bluetooth/hci.h | 12 ++++++++++
> net/bluetooth/hci_core.c | 45 +++++++++++++++++++++++++++++++++++++
> net/bluetooth/mgmt.c | 6 +++--
> 3 files changed, 61 insertions(+), 2 deletions(-)
>
> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> index c36dc1e20556..fbba43e9bef5 100644
> --- a/include/net/bluetooth/hci.h
> +++ b/include/net/bluetooth/hci.h
> @@ -158,6 +158,18 @@ enum {
> */
> HCI_QUIRK_INVALID_BDADDR,
>
> + /* When this quirk is set, the public Bluetooth address
> + * initially reported by HCI Read BD Address command
> + * is considered invalid. The public BD Address can be
> + * specified in the fwnode property 'local-bd-address'.
> + * If this property does not exist or is invalid controller
> + * configuration is required before this device can be used.
> + *
> + * This quirk can be set before hci_register_dev is called or
> + * during the hdev->setup vendor callback.
> + */
> + HCI_QUIRK_USE_BDADDR_PROPERTY,
> +
> /* When this quirk is set, the duplicate filtering during
> * scanning is based on Bluetooth devices addresses. To allow
> * RSSI based updates, restart scanning if needed.
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index 7352fe85674b..d4149005a661 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -30,6 +30,7 @@
> #include <linux/rfkill.h>
> #include <linux/debugfs.h>
> #include <linux/crypto.h>
> +#include <linux/property.h>
> #include <asm/unaligned.h>
>
> #include <net/bluetooth/bluetooth.h>
> @@ -1355,6 +1356,36 @@ int hci_inquiry(void __user *arg)
> return err;
> }
>
> +/**
> + * hci_dev_get_bd_addr_from_property - Get the Bluetooth Device Address
> + * (BD_ADDR) for a HCI device from
> + * a firmware node property.
> + * @hdev: The HCI device
> + *
> + * Search the firmware node for 'local-bd-address'.
> + *
> + * All-zero BD addresses are rejected, because those could be properties
> + * that exist in the firmware tables, but were not updated by the firmware. For
> + * example, the DTS could define 'local-bd-address', with zero BD addresses.
> + */
> +static int hci_dev_get_bd_addr_from_property(struct hci_dev *hdev)
> +{
> + struct fwnode_handle *fwnode = dev_fwnode(hdev->dev.parent);
> + bdaddr_t ba;
> + int ret;
> +
> + ret = fwnode_property_read_u8_array(fwnode, "local-bd-address",
> + (u8 *)&ba, sizeof(ba));
> + if (ret < 0)
> + return ret;
> + if (!bacmp(&ba, BDADDR_ANY))
> + return -ENODATA;
> +
> + hdev->public_addr = ba;
> +
> + return 0;
> +}
> +
> static int hci_dev_do_open(struct hci_dev *hdev)
> {
> int ret = 0;
> @@ -1422,6 +1453,20 @@ static int hci_dev_do_open(struct hci_dev *hdev)
> if (hdev->setup)
> ret = hdev->setup(hdev);
>
> + if (ret)
> + goto setup_failed;
> +
> + if (test_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks)) {
> + if (!bacmp(&hdev->public_addr, BDADDR_ANY))
> + hci_dev_get_bd_addr_from_property(hdev);
> +
> + if (!bacmp(&hdev->public_addr, BDADDR_ANY) ||
> + !hdev->set_bdaddr ||
> + hdev->set_bdaddr(hdev, &hdev->public_addr))
> + hci_dev_set_flag(hdev, HCI_UNCONFIGURED);
> + }
> +
> +setup_failed:
> /* The transport driver can set these quirks before
> * creating the HCI device or in its setup callback.
> *
> diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
> index ccce954f8146..fae84353d030 100644
> --- a/net/bluetooth/mgmt.c
> +++ b/net/bluetooth/mgmt.c
> @@ -551,7 +551,8 @@ static bool is_configured(struct hci_dev *hdev)
> !hci_dev_test_flag(hdev, HCI_EXT_CONFIGURED))
> return false;
>
> - if (test_bit(HCI_QUIRK_INVALID_BDADDR, &hdev->quirks) &&
> + if ((test_bit(HCI_QUIRK_INVALID_BDADDR, &hdev->quirks) ||
> + test_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks)) &&
> !bacmp(&hdev->public_addr, BDADDR_ANY))
> return false;
>
> @@ -566,7 +567,8 @@ static __le32 get_missing_options(struct hci_dev *hdev)
> !hci_dev_test_flag(hdev, HCI_EXT_CONFIGURED))
> options |= MGMT_OPTION_EXTERNAL_CONFIG;
>
> - if (test_bit(HCI_QUIRK_INVALID_BDADDR, &hdev->quirks) &&
> + if ((test_bit(HCI_QUIRK_INVALID_BDADDR, &hdev->quirks) ||
> + test_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks)) &&
> !bacmp(&hdev->public_addr, BDADDR_ANY))
> options |= MGMT_OPTION_PUBLIC_ADDRESS;
>
^ permalink raw reply
* [PATCH net-next 11/11] r8169: improve chip version identification
From: Heiner Kallweit @ 2018-11-19 21:41 UTC (permalink / raw)
To: David Miller, Realtek linux nic maintainers; +Cc: netdev@vger.kernel.org
In-Reply-To: <7484b166-100b-52b9-1539-22e9199a8a3a@gmail.com>
Only the upper 12 bits are used for chip identification, this helps
to reduce the size of array mac_info.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169.c | 119 +++++++++++++--------------
1 file changed, 59 insertions(+), 60 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 5e6bd1a5e..f5781285a 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -2026,92 +2026,91 @@ static void rtl8169_get_mac_version(struct rtl8169_private *tp,
* (RTL_R32(tp, TxConfig) & 0x700000) == 0x200000 ? 8101Eb : 8101Ec
*/
static const struct rtl_mac_info {
- u32 mask;
- u32 val;
- int mac_version;
+ u16 mask;
+ u16 val;
+ u16 mac_version;
} mac_info[] = {
/* 8168EP family. */
- { 0x7cf00000, 0x50200000, RTL_GIGA_MAC_VER_51 },
- { 0x7cf00000, 0x50100000, RTL_GIGA_MAC_VER_50 },
- { 0x7cf00000, 0x50000000, RTL_GIGA_MAC_VER_49 },
+ { 0x7cf, 0x502, RTL_GIGA_MAC_VER_51 },
+ { 0x7cf, 0x501, RTL_GIGA_MAC_VER_50 },
+ { 0x7cf, 0x500, RTL_GIGA_MAC_VER_49 },
/* 8168H family. */
- { 0x7cf00000, 0x54100000, RTL_GIGA_MAC_VER_46 },
- { 0x7cf00000, 0x54000000, RTL_GIGA_MAC_VER_45 },
+ { 0x7cf, 0x541, RTL_GIGA_MAC_VER_46 },
+ { 0x7cf, 0x540, RTL_GIGA_MAC_VER_45 },
/* 8168G family. */
- { 0x7cf00000, 0x5c800000, RTL_GIGA_MAC_VER_44 },
- { 0x7cf00000, 0x50900000, RTL_GIGA_MAC_VER_42 },
- { 0x7cf00000, 0x4c100000, RTL_GIGA_MAC_VER_41 },
- { 0x7cf00000, 0x4c000000, RTL_GIGA_MAC_VER_40 },
+ { 0x7cf, 0x5c8, RTL_GIGA_MAC_VER_44 },
+ { 0x7cf, 0x509, RTL_GIGA_MAC_VER_42 },
+ { 0x7cf, 0x4c1, RTL_GIGA_MAC_VER_41 },
+ { 0x7cf, 0x4c0, RTL_GIGA_MAC_VER_40 },
/* 8168F family. */
- { 0x7c800000, 0x48800000, RTL_GIGA_MAC_VER_38 },
- { 0x7cf00000, 0x48100000, RTL_GIGA_MAC_VER_36 },
- { 0x7cf00000, 0x48000000, RTL_GIGA_MAC_VER_35 },
+ { 0x7c8, 0x488, RTL_GIGA_MAC_VER_38 },
+ { 0x7cf, 0x481, RTL_GIGA_MAC_VER_36 },
+ { 0x7cf, 0x480, RTL_GIGA_MAC_VER_35 },
/* 8168E family. */
- { 0x7c800000, 0x2c800000, RTL_GIGA_MAC_VER_34 },
- { 0x7cf00000, 0x2c100000, RTL_GIGA_MAC_VER_32 },
- { 0x7c800000, 0x2c000000, RTL_GIGA_MAC_VER_33 },
+ { 0x7c8, 0x2c8, RTL_GIGA_MAC_VER_34 },
+ { 0x7cf, 0x2c1, RTL_GIGA_MAC_VER_32 },
+ { 0x7c8, 0x2c0, RTL_GIGA_MAC_VER_33 },
/* 8168D family. */
- { 0x7cf00000, 0x28100000, RTL_GIGA_MAC_VER_25 },
- { 0x7c800000, 0x28000000, RTL_GIGA_MAC_VER_26 },
+ { 0x7cf, 0x281, RTL_GIGA_MAC_VER_25 },
+ { 0x7c8, 0x280, RTL_GIGA_MAC_VER_26 },
/* 8168DP family. */
- { 0x7cf00000, 0x28800000, RTL_GIGA_MAC_VER_27 },
- { 0x7cf00000, 0x28a00000, RTL_GIGA_MAC_VER_28 },
- { 0x7cf00000, 0x28b00000, RTL_GIGA_MAC_VER_31 },
+ { 0x7cf, 0x288, RTL_GIGA_MAC_VER_27 },
+ { 0x7cf, 0x28a, RTL_GIGA_MAC_VER_28 },
+ { 0x7cf, 0x28b, RTL_GIGA_MAC_VER_31 },
/* 8168C family. */
- { 0x7cf00000, 0x3c900000, RTL_GIGA_MAC_VER_23 },
- { 0x7cf00000, 0x3c800000, RTL_GIGA_MAC_VER_18 },
- { 0x7c800000, 0x3c800000, RTL_GIGA_MAC_VER_24 },
- { 0x7cf00000, 0x3c000000, RTL_GIGA_MAC_VER_19 },
- { 0x7cf00000, 0x3c200000, RTL_GIGA_MAC_VER_20 },
- { 0x7cf00000, 0x3c300000, RTL_GIGA_MAC_VER_21 },
- { 0x7c800000, 0x3c000000, RTL_GIGA_MAC_VER_22 },
+ { 0x7cf, 0x3c9, RTL_GIGA_MAC_VER_23 },
+ { 0x7cf, 0x3c8, RTL_GIGA_MAC_VER_18 },
+ { 0x7c8, 0x3c8, RTL_GIGA_MAC_VER_24 },
+ { 0x7cf, 0x3c0, RTL_GIGA_MAC_VER_19 },
+ { 0x7cf, 0x3c2, RTL_GIGA_MAC_VER_20 },
+ { 0x7cf, 0x3c3, RTL_GIGA_MAC_VER_21 },
+ { 0x7c8, 0x3c0, RTL_GIGA_MAC_VER_22 },
/* 8168B family. */
- { 0x7cf00000, 0x38000000, RTL_GIGA_MAC_VER_12 },
- { 0x7c800000, 0x38000000, RTL_GIGA_MAC_VER_17 },
- { 0x7c800000, 0x30000000, RTL_GIGA_MAC_VER_11 },
+ { 0x7cf, 0x380, RTL_GIGA_MAC_VER_12 },
+ { 0x7c8, 0x380, RTL_GIGA_MAC_VER_17 },
+ { 0x7c8, 0x300, RTL_GIGA_MAC_VER_11 },
/* 8101 family. */
- { 0x7c800000, 0x44800000, RTL_GIGA_MAC_VER_39 },
- { 0x7c800000, 0x44000000, RTL_GIGA_MAC_VER_37 },
- { 0x7cf00000, 0x40900000, RTL_GIGA_MAC_VER_29 },
- { 0x7c800000, 0x40800000, RTL_GIGA_MAC_VER_30 },
- { 0x7cf00000, 0x34900000, RTL_GIGA_MAC_VER_08 },
- { 0x7cf00000, 0x24900000, RTL_GIGA_MAC_VER_08 },
- { 0x7cf00000, 0x34800000, RTL_GIGA_MAC_VER_07 },
- { 0x7cf00000, 0x24800000, RTL_GIGA_MAC_VER_07 },
- { 0x7cf00000, 0x34000000, RTL_GIGA_MAC_VER_13 },
- { 0x7cf00000, 0x34300000, RTL_GIGA_MAC_VER_10 },
- { 0x7cf00000, 0x34200000, RTL_GIGA_MAC_VER_16 },
- { 0x7c800000, 0x34800000, RTL_GIGA_MAC_VER_09 },
- { 0x7c800000, 0x24800000, RTL_GIGA_MAC_VER_09 },
- { 0x7c800000, 0x34000000, RTL_GIGA_MAC_VER_16 },
+ { 0x7c8, 0x448, RTL_GIGA_MAC_VER_39 },
+ { 0x7c8, 0x440, RTL_GIGA_MAC_VER_37 },
+ { 0x7cf, 0x409, RTL_GIGA_MAC_VER_29 },
+ { 0x7c8, 0x408, RTL_GIGA_MAC_VER_30 },
+ { 0x7cf, 0x349, RTL_GIGA_MAC_VER_08 },
+ { 0x7cf, 0x249, RTL_GIGA_MAC_VER_08 },
+ { 0x7cf, 0x348, RTL_GIGA_MAC_VER_07 },
+ { 0x7cf, 0x248, RTL_GIGA_MAC_VER_07 },
+ { 0x7cf, 0x340, RTL_GIGA_MAC_VER_13 },
+ { 0x7cf, 0x343, RTL_GIGA_MAC_VER_10 },
+ { 0x7cf, 0x342, RTL_GIGA_MAC_VER_16 },
+ { 0x7c8, 0x348, RTL_GIGA_MAC_VER_09 },
+ { 0x7c8, 0x248, RTL_GIGA_MAC_VER_09 },
+ { 0x7c8, 0x340, RTL_GIGA_MAC_VER_16 },
/* FIXME: where did these entries come from ? -- FR */
- { 0xfc800000, 0x38800000, RTL_GIGA_MAC_VER_15 },
- { 0xfc800000, 0x30800000, RTL_GIGA_MAC_VER_14 },
+ { 0xfc8, 0x388, RTL_GIGA_MAC_VER_15 },
+ { 0xfc8, 0x308, RTL_GIGA_MAC_VER_14 },
/* 8110 family. */
- { 0xfc800000, 0x98000000, RTL_GIGA_MAC_VER_06 },
- { 0xfc800000, 0x18000000, RTL_GIGA_MAC_VER_05 },
- { 0xfc800000, 0x10000000, RTL_GIGA_MAC_VER_04 },
- { 0xfc800000, 0x04000000, RTL_GIGA_MAC_VER_03 },
- { 0xfc800000, 0x00800000, RTL_GIGA_MAC_VER_02 },
- { 0xfc800000, 0x00000000, RTL_GIGA_MAC_VER_01 },
+ { 0xfc8, 0x980, RTL_GIGA_MAC_VER_06 },
+ { 0xfc8, 0x180, RTL_GIGA_MAC_VER_05 },
+ { 0xfc8, 0x100, RTL_GIGA_MAC_VER_04 },
+ { 0xfc8, 0x040, RTL_GIGA_MAC_VER_03 },
+ { 0xfc8, 0x008, RTL_GIGA_MAC_VER_02 },
+ { 0xfc8, 0x000, RTL_GIGA_MAC_VER_01 },
/* Catch-all */
- { 0x00000000, 0x00000000, RTL_GIGA_MAC_NONE }
+ { 0x000, 0x000, RTL_GIGA_MAC_NONE }
};
const struct rtl_mac_info *p = mac_info;
- u32 reg;
+ u16 reg = RTL_R32(tp, TxConfig) >> 20;
- reg = RTL_R32(tp, TxConfig);
while ((reg & p->mask) != p->val)
p++;
tp->mac_version = p->mac_version;
@@ -7392,9 +7391,9 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if (rc)
goto err_mdio_unregister;
- netif_info(tp, probe, dev, "%s, %pM, XID %08x, IRQ %d\n",
+ netif_info(tp, probe, dev, "%s, %pM, XID %03x, IRQ %d\n",
rtl_chip_infos[chipset].name, dev->dev_addr,
- (u32)(RTL_R32(tp, TxConfig) & 0xfcf0f8ff),
+ (RTL_R32(tp, TxConfig) >> 20) & 0xfcf,
pci_irq_vector(pdev, 0));
if (jumbo_max > JUMBO_1K)
--
2.19.1
^ permalink raw reply related
* [PATCH net-next 10/11] r8169: simplify ocp functions
From: Heiner Kallweit @ 2018-11-19 21:40 UTC (permalink / raw)
To: David Miller, Realtek linux nic maintainers; +Cc: netdev@vger.kernel.org
In-Reply-To: <7484b166-100b-52b9-1539-22e9199a8a3a@gmail.com>
rtl8168_oob_notify is used in rtl8168dp_driver_start and
rtl8168dp_driver_stop only, so we can rename it to r8168dp_oob_notify.
The same applies to condition rtl_ocp_read_cond which can be renamed
to rtl_dp_ocp_read_cond. This allows to simplify the code.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169.c | 68 +++++++---------------------
1 file changed, 17 insertions(+), 51 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index b5f9c3511..5e6bd1a5e 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1101,23 +1101,6 @@ static u32 r8168ep_ocp_read(struct rtl8169_private *tp, u8 mask, u16 reg)
return rtl_eri_read(tp, reg, ERIAR_OOB);
}
-static u32 ocp_read(struct rtl8169_private *tp, u8 mask, u16 reg)
-{
- switch (tp->mac_version) {
- case RTL_GIGA_MAC_VER_27:
- case RTL_GIGA_MAC_VER_28:
- case RTL_GIGA_MAC_VER_31:
- return r8168dp_ocp_read(tp, mask, reg);
- case RTL_GIGA_MAC_VER_49:
- case RTL_GIGA_MAC_VER_50:
- case RTL_GIGA_MAC_VER_51:
- return r8168ep_ocp_read(tp, mask, reg);
- default:
- BUG();
- return ~0;
- }
-}
-
static void r8168dp_ocp_write(struct rtl8169_private *tp, u8 mask, u16 reg,
u32 data)
{
@@ -1133,30 +1116,11 @@ static void r8168ep_ocp_write(struct rtl8169_private *tp, u8 mask, u16 reg,
data, ERIAR_OOB);
}
-static void ocp_write(struct rtl8169_private *tp, u8 mask, u16 reg, u32 data)
-{
- switch (tp->mac_version) {
- case RTL_GIGA_MAC_VER_27:
- case RTL_GIGA_MAC_VER_28:
- case RTL_GIGA_MAC_VER_31:
- r8168dp_ocp_write(tp, mask, reg, data);
- break;
- case RTL_GIGA_MAC_VER_49:
- case RTL_GIGA_MAC_VER_50:
- case RTL_GIGA_MAC_VER_51:
- r8168ep_ocp_write(tp, mask, reg, data);
- break;
- default:
- BUG();
- break;
- }
-}
-
-static void rtl8168_oob_notify(struct rtl8169_private *tp, u8 cmd)
+static void r8168dp_oob_notify(struct rtl8169_private *tp, u8 cmd)
{
rtl_eri_write(tp, 0xe8, ERIAR_MASK_0001, cmd, ERIAR_EXGMAC);
- ocp_write(tp, 0x1, 0x30, 0x00000001);
+ r8168dp_ocp_write(tp, 0x1, 0x30, 0x00000001);
}
#define OOB_CMD_RESET 0x00
@@ -1168,18 +1132,18 @@ static u16 rtl8168_get_ocp_reg(struct rtl8169_private *tp)
return (tp->mac_version == RTL_GIGA_MAC_VER_31) ? 0xb8 : 0x10;
}
-DECLARE_RTL_COND(rtl_ocp_read_cond)
+DECLARE_RTL_COND(rtl_dp_ocp_read_cond)
{
u16 reg;
reg = rtl8168_get_ocp_reg(tp);
- return ocp_read(tp, 0x0f, reg) & 0x00000800;
+ return r8168dp_ocp_read(tp, 0x0f, reg) & 0x00000800;
}
DECLARE_RTL_COND(rtl_ep_ocp_read_cond)
{
- return ocp_read(tp, 0x0f, 0x124) & 0x00000001;
+ return r8168ep_ocp_read(tp, 0x0f, 0x124) & 0x00000001;
}
DECLARE_RTL_COND(rtl_ocp_tx_cond)
@@ -1197,14 +1161,15 @@ static void rtl8168ep_stop_cmac(struct rtl8169_private *tp)
static void rtl8168dp_driver_start(struct rtl8169_private *tp)
{
- rtl8168_oob_notify(tp, OOB_CMD_DRIVER_START);
- rtl_msleep_loop_wait_high(tp, &rtl_ocp_read_cond, 10, 10);
+ r8168dp_oob_notify(tp, OOB_CMD_DRIVER_START);
+ rtl_msleep_loop_wait_high(tp, &rtl_dp_ocp_read_cond, 10, 10);
}
static void rtl8168ep_driver_start(struct rtl8169_private *tp)
{
- ocp_write(tp, 0x01, 0x180, OOB_CMD_DRIVER_START);
- ocp_write(tp, 0x01, 0x30, ocp_read(tp, 0x01, 0x30) | 0x01);
+ r8168ep_ocp_write(tp, 0x01, 0x180, OOB_CMD_DRIVER_START);
+ r8168ep_ocp_write(tp, 0x01, 0x30,
+ r8168ep_ocp_read(tp, 0x01, 0x30) | 0x01);
rtl_msleep_loop_wait_high(tp, &rtl_ep_ocp_read_cond, 10, 10);
}
@@ -1229,15 +1194,16 @@ static void rtl8168_driver_start(struct rtl8169_private *tp)
static void rtl8168dp_driver_stop(struct rtl8169_private *tp)
{
- rtl8168_oob_notify(tp, OOB_CMD_DRIVER_STOP);
- rtl_msleep_loop_wait_low(tp, &rtl_ocp_read_cond, 10, 10);
+ r8168dp_oob_notify(tp, OOB_CMD_DRIVER_STOP);
+ rtl_msleep_loop_wait_low(tp, &rtl_dp_ocp_read_cond, 10, 10);
}
static void rtl8168ep_driver_stop(struct rtl8169_private *tp)
{
rtl8168ep_stop_cmac(tp);
- ocp_write(tp, 0x01, 0x180, OOB_CMD_DRIVER_STOP);
- ocp_write(tp, 0x01, 0x30, ocp_read(tp, 0x01, 0x30) | 0x01);
+ r8168ep_ocp_write(tp, 0x01, 0x180, OOB_CMD_DRIVER_STOP);
+ r8168ep_ocp_write(tp, 0x01, 0x30,
+ r8168ep_ocp_read(tp, 0x01, 0x30) | 0x01);
rtl_msleep_loop_wait_low(tp, &rtl_ep_ocp_read_cond, 10, 10);
}
@@ -1264,12 +1230,12 @@ static bool r8168dp_check_dash(struct rtl8169_private *tp)
{
u16 reg = rtl8168_get_ocp_reg(tp);
- return !!(ocp_read(tp, 0x0f, reg) & 0x00008000);
+ return !!(r8168dp_ocp_read(tp, 0x0f, reg) & 0x00008000);
}
static bool r8168ep_check_dash(struct rtl8169_private *tp)
{
- return !!(ocp_read(tp, 0x0f, 0x128) & 0x00000001);
+ return !!(r8168ep_ocp_read(tp, 0x0f, 0x128) & 0x00000001);
}
static bool r8168_check_dash(struct rtl8169_private *tp)
--
2.19.1
^ permalink raw reply related
* [PATCH net-next 09/11] r8169: remove workaround for ancient gcc bug
From: Heiner Kallweit @ 2018-11-19 21:39 UTC (permalink / raw)
To: David Miller, Realtek linux nic maintainers; +Cc: netdev@vger.kernel.org
In-Reply-To: <7484b166-100b-52b9-1539-22e9199a8a3a@gmail.com>
The kernel can't be built any longer with this ancient GCC version.
Eventually it becomes clear what this statement actually does.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 6736b804c..b5f9c3511 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5903,9 +5903,9 @@ static int rtl8169_xmit_frags(struct rtl8169_private *tp, struct sk_buff *skb,
goto err_out;
}
- /* Anti gcc 2.95.3 bugware (sic) */
- status = opts[0] | len |
- (RingEnd * !((entry + 1) % NUM_TX_DESC));
+ status = opts[0] | len;
+ if (entry == NUM_TX_DESC - 1)
+ status |= RingEnd;
txd->opts1 = cpu_to_le32(status);
txd->opts2 = cpu_to_le32(opts[1]);
--
2.19.1
^ permalink raw reply related
* [PATCH net-next 08/11] r8169: remove manual padding in struct ring_info
From: Heiner Kallweit @ 2018-11-19 21:38 UTC (permalink / raw)
To: David Miller, Realtek linux nic maintainers; +Cc: netdev@vger.kernel.org
In-Reply-To: <7484b166-100b-52b9-1539-22e9199a8a3a@gmail.com>
The compiler takes care of alignment and padding, I see no need to
bother him with manual hints.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 3ffd9c18b..6736b804c 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -603,7 +603,6 @@ struct RxDesc {
struct ring_info {
struct sk_buff *skb;
u32 len;
- u8 __pad[sizeof(void *) - sizeof(u32)];
};
struct rtl8169_counters {
--
2.19.1
^ 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