* Re: [PATCH net-next v4 2/7] etf: Add skip_sock_check
From: Sergei Shtylyov @ 2019-06-20 8:16 UTC (permalink / raw)
To: Vedang Patel, netdev
Cc: jeffrey.t.kirsher, davem, jhs, xiyou.wangcong, jiri,
intel-wired-lan, vinicius.gomes, l, jakub.kicinski, m-karicheri2
In-Reply-To: <1560966016-28254-3-git-send-email-vedang.patel@intel.com>
On 19.06.2019 20:40, Vedang Patel wrote:
> Currently, etf expects a socket with SO_TXTIME option set for each packet
> it encounters. So, it will drop all other packets. But, in the future
> commits we are planning to add functionality which where tstamp value will
One of "which" and "where", not both. :-)
> be set by another qdisc. Also, some packets which are generated from within
> the kernel (e.g. ICMP packets) do not have any socket associated with them.
>
> So, this commit adds support for skip_sock_check. When this option is set,
> etf will skip checking for a socket and other associated options for all
> skbs.
>
> Signed-off-by: Vedang Patel <vedang.patel@intel.com>
[...]
MBR, Sergei
^ permalink raw reply
* selftests: bpf: test_libbpf.sh failed at file test_l4lb.o
From: Naresh Kamboju @ 2019-06-20 8:07 UTC (permalink / raw)
To: open list:KERNEL SELFTEST FRAMEWORK, bpf, Netdev, open list,
xdp-newbies
Cc: David S. Miller, Daniel Borkmann, Alexei Starovoitov, kafai,
Yonghong Song, john.fastabend, hawk, jakub.kicinski, Shuah Khan
selftests: bpf test_libbpf.sh failed running Linux -next kernel
20190618 and 20190619.
Here is the log from x86_64,
# selftests bpf test_libbpf.sh
bpf: test_libbpf.sh_ #
# [0] libbpf BTF is required, but is missing or corrupted.
libbpf: BTF_is #
# test_libbpf failed at file test_l4lb.o
failed: at_file #
# selftests test_libbpf [FAILED]
test_libbpf: [FAILED]_ #
[FAIL] 29 selftests bpf test_libbpf.sh
selftests: bpf_test_libbpf.sh [FAIL]
Full test log,
https://qa-reports.linaro.org/lkft/linux-next-oe/build/next-20190619/testrun/781777/log
Test results comparison,
https://qa-reports.linaro.org/lkft/linux-next-oe/tests/kselftest/bpf_test_libbpf.sh
Good linux -next tag: next-20190617
Bad linux -next tag: next-20190618
git branch master
git commit 1c6b40509daf5190b1fd2c758649f7df1da4827b
git repo
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
Best regards
Naresh Kamboju
^ permalink raw reply
* Re: network unstable on odroid-c1/meson8b.
From: Aymeric @ 2019-06-20 7:55 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: netdev, linux-amlogic, Martin Blumenstingl
In-Reply-To: <0df100ad-b331-43db-10a5-3257bd09938d@gmail.com>
Hi,
On 2019-06-20 00:14, Heiner Kallweit wrote:
> On 19.06.2019 22:18, Aymeric wrote:
>> Hello all,
>>
> Kernel 3.10 didn't have a dedicated RTL8211F PHY driver yet, therefore
> I assume the genphy driver was used. Do you have a line with
> "attached PHY driver" in dmesg output of the vendor kernel?
No.
Here is the full output of the dmesg from vendor kernel [¹].
I've also noticed something strange, it might be linked, but mac address
of the board is set to a random value when using mainline kernel and
I've to set it manually but not when using vendor kernel.
>
> The dedicated PHY driver takes care of the tx delay, if the genphy
> driver is used we have to rely on what uboot configured.
> But if we indeed had an issue with a misconfigured delay, I think
> the connection shouldn't be fine with just another link partner.
> Just to have it tested you could make rtl8211f_config_init() in
> drivers/net/phy/realtek.c a no-op (in current kernels).
>
I'm not an expert here, just adding a "return 0;" here[²] would be
enough?
> And you could compare at least the basic PHY registers 0x00 - 0x30
> with both kernel versions, e.g. with phytool.
>
They are not the same but I don't know what I'm looking for, so for
kernel 3.10 [³] and for kernel 5.1.12 [⁴].
Aymeric
[¹]:
https://paste.aplu.fr/?38ef95b44ebdbfc3#G666/YbhgU+O+tdC/2HaimUCigm8ZTB44qvQip/HJ5A=
[²]:
https://github.com/torvalds/linux/blob/241e39004581475b2802cd63c111fec43bb0123e/drivers/net/phy/realtek.c#L164
[³]:
https://paste.aplu.fr/?2dde1c32d5c68f4c#6xIa8MjTm6jpI6citEJAqFTLMMHDjFZRet/M00/EwjU=
[⁴]:
https://paste.aplu.fr/?32130e9bcb05dde7#N/xdnvb5GklcJtiOxMpTCm+9gsUliRwH8X3dcwSV+ng=
^ permalink raw reply
* Re: [PATCH v2 2/5] net: macb: add support for sgmii MAC-PHY interface
From: Russell King - ARM Linux admin @ 2019-06-20 7:46 UTC (permalink / raw)
To: Parshuram Raju Thombare
Cc: andrew@lunn.ch, nicolas.ferre@microchip.com, davem@davemloft.net,
f.fainelli@gmail.com, netdev@vger.kernel.org,
hkallweit1@gmail.com, linux-kernel@vger.kernel.org,
Rafal Ciepiela, Anil Joy Varughese, Piotr Sroka
In-Reply-To: <CO2PR07MB24693905766BD027DB972761C1E40@CO2PR07MB2469.namprd07.prod.outlook.com>
On Thu, Jun 20, 2019 at 05:56:32AM +0000, Parshuram Raju Thombare wrote:
> For in band mode, I see two places to config MAC speed
> and duplex mode, 1. mac_link_state 2. mac_link_up. In mac_link_up, though state
> read from mac_link_state is passed, it is only used for printing log and updating
> pl->cur_interface, so if configuring MAC speed/duplex mode in mac_link_up is correct,
> these parameters will need to read again from HW.
That is incorrect. Again, please read the phylink documentation.
There is even an article on how to convert drivers.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH net-next 1/3] net/sched: Introduce action ct
From: Paul Blakey @ 2019-06-20 7:32 UTC (permalink / raw)
To: Cong Wang, Marcelo Ricardo Leitner
Cc: Toke Høiland-Jørgensen, Jiri Pirko, Roi Dayan,
Yossi Kuperman, Oz Shlomo, netdev@vger.kernel.org, David Miller,
Aaron Conole, Zhike Wang, Rony Efraim, nst-kernel@redhat.com,
John Hurley, Simon Horman, Justin Pettit, Kevin Darbyshire-Bryant
In-Reply-To: <CAM_iQpWLrRKKr4v6sUWeFfaJDJe4tGHdCAfUttxV4oQim=-9Bw@mail.gmail.com>
On 6/18/2019 7:03 PM, Cong Wang wrote:
> On Fri, Jun 14, 2019 at 12:24 PM Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
>> On Fri, Jun 14, 2019 at 11:07:37AM -0700, Cong Wang wrote:
>>> On Tue, Jun 11, 2019 at 9:44 AM Marcelo Ricardo Leitner
>>> <marcelo.leitner@gmail.com> wrote:
>>>> I had suggested to let act_ct handle the above as well, as there is a
>>>> big chunk of code on both that is pretty similar. There is quite some
>>>> boilerplate for interfacing with conntrack which is duplicated.
>>> Why do you want to mix retrieving conntrack info with executing
>>> conntrack?
>> To save on the heavy boilerplate for interfacing with conntrack.
>>
>>> They are totally different things to me, act_ctinfo merely retrieves
>>> information from conntrack, while this one, act_ct, is supposed to
>>> move packets to conntrack.
>> Seems we have a different understanding for "move packets to
>> conntrack": conntrack will not consume the packets after this.
>> But after act_ct is executed, if not with the clear flag, skb will now
>> have the skb->_nfct entry available, on which flower then will be able
>> to match. So in essence, it is also fetching information from
>> conntrack.
> Interesting. Is it because cls_flower uses conntrack for flow dissection?
> What's the reason behind?
>
> Again, I am still not convinced to do L3 operations in L2, skb->_nfct
> belongs to conntrack which is L3, no matter the packet is consumed
> or not.
>
> Thanks.
I'm not sure what you mean, the reason behind what?
We use conntrack to track, mark the packet with conntrack info, and
execute nat, then we push the
headers back to continue processing the next action. This action will
probably be followed by
goto chain or reclassify and then cls_flower can be used to match on
conntrack state and metadata via the new flow dissector change.
^ permalink raw reply
* [PATCH] fjes: no need to check return value of debugfs_create functions
From: Greg Kroah-Hartman @ 2019-06-20 7:31 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Yangtao Li
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Yangtao Li <tiny.windzz@gmail.com>
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/fjes/fjes_debugfs.c | 15 ++-------------
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/net/fjes/fjes_debugfs.c b/drivers/net/fjes/fjes_debugfs.c
index 7fed88ea27a5..25599edb4ceb 100644
--- a/drivers/net/fjes/fjes_debugfs.c
+++ b/drivers/net/fjes/fjes_debugfs.c
@@ -67,20 +67,11 @@ DEFINE_SHOW_ATTRIBUTE(fjes_dbg_status);
void fjes_dbg_adapter_init(struct fjes_adapter *adapter)
{
const char *name = dev_name(&adapter->plat_dev->dev);
- struct dentry *pfile;
adapter->dbg_adapter = debugfs_create_dir(name, fjes_debug_root);
- if (!adapter->dbg_adapter) {
- dev_err(&adapter->plat_dev->dev,
- "debugfs entry for %s failed\n", name);
- return;
- }
- pfile = debugfs_create_file("status", 0444, adapter->dbg_adapter,
- adapter, &fjes_dbg_status_fops);
- if (!pfile)
- dev_err(&adapter->plat_dev->dev,
- "debugfs status for %s failed\n", name);
+ debugfs_create_file("status", 0444, adapter->dbg_adapter, adapter,
+ &fjes_dbg_status_fops);
}
void fjes_dbg_adapter_exit(struct fjes_adapter *adapter)
@@ -92,8 +83,6 @@ void fjes_dbg_adapter_exit(struct fjes_adapter *adapter)
void fjes_dbg_init(void)
{
fjes_debug_root = debugfs_create_dir(fjes_driver_name, NULL);
- if (!fjes_debug_root)
- pr_info("init of debugfs failed\n");
}
void fjes_dbg_exit(void)
--
2.22.0
^ permalink raw reply related
* Re: [PATCH] flow_dissector: Fix vlan header offset in __skb_flow_dissect
From: Jiri Pirko @ 2019-06-20 7:20 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: YueHaibing, davem, sdf, jianbol, jiri, mirq-linux, willemb,
linux-kernel, netdev
In-Reply-To: <20190619183938.GA19111@mini-arch>
Wed, Jun 19, 2019 at 08:39:38PM CEST, sdf@fomichev.me wrote:
>On 06/20, YueHaibing wrote:
>> We build vlan on top of bonding interface, which vlan offload
>> is off, bond mode is 802.3ad (LACP) and xmit_hash_policy is
>> BOND_XMIT_POLICY_ENCAP34.
>>
>> __skb_flow_dissect() fails to get information from protocol headers
>> encapsulated within vlan, because 'nhoff' is points to IP header,
>> so bond hashing is based on layer 2 info, which fails to distribute
>> packets across slaves.
>>
>> Fixes: d5709f7ab776 ("flow_dissector: For stripped vlan, get vlan info from skb->vlan_tci")
>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
>> ---
>> net/core/flow_dissector.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
>> index 415b95f..2a52abb 100644
>> --- a/net/core/flow_dissector.c
>> +++ b/net/core/flow_dissector.c
>> @@ -785,6 +785,9 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
>> skb && skb_vlan_tag_present(skb)) {
>> proto = skb->protocol;
>> } else {
>> + if (dissector_vlan == FLOW_DISSECTOR_KEY_MAX)
>> + nhoff -= sizeof(*vlan);
>> +
>Should we instead fix the place where the skb is allocated to properly
>pull vlan (skb_vlan_untag)? I'm not sure this particular place is
Yes.
>supposed to work with an skb. Having an skb with nhoff pointing to
>IP header but missing skb_vlan_tag_present() when with
>proto==ETH_P_8021xx seems weird.
>
>> vlan = __skb_header_pointer(skb, nhoff, sizeof(_vlan),
>> data, hlen, &_vlan);
>> if (!vlan) {
>> --
>> 2.7.0
>>
>>
^ permalink raw reply
* Re: [PATCH] mm: mempolicy: handle vma with unmovable pages mapped correctly in mbind
From: Vlastimil Babka @ 2019-06-20 7:18 UTC (permalink / raw)
To: Yang Shi, Michal Hocko
Cc: akpm, mgorman, linux-mm, linux-kernel, Eric Dumazet,
David S. Miller, netdev
In-Reply-To: <55eb2ea9-2c74-87b1-4568-b620c7913e17@linux.alibaba.com>
On 6/19/19 8:19 PM, Yang Shi wrote:
>>>> This is getting even more muddy TBH. Is there any reason that we
>>>> have to
>>>> handle this problem during the isolation phase rather the migration?
>>> I think it was already said that if pages can't be isolated, then
>>> migration phase won't process them, so they're just ignored.
>>
>> Yes，exactly.
>>
>>> However I think the patch is wrong to abort immediately when
>>> encountering such page that cannot be isolated (AFAICS). IMHO it should
>>> still try to migrate everything it can, and only then return -EIO.
>>
>> It is fine too. I don't see mbind semantics define how to handle such
>> case other than returning -EIO.
I think it does. There's:
If MPOL_MF_MOVE is specified in flags, then the kernel *will attempt to
move all the existing pages* ... If MPOL_MF_STRICT is also specified,
then the call fails with the error *EIO if some pages could not be moved*
Aborting immediately would be against the attempt to move all.
> By looking into the code, it looks not that easy as what I thought.
> do_mbind() would check the return value of queue_pages_range(), it just
> applies the policy and manipulates vmas as long as the return value is 0
> (success), then migrate pages on the list. We could put the movable
> pages on the list by not breaking immediately, but they will be ignored.
> If we migrate the pages regardless of the return value, it may break the
> policy since the policy will *not* be applied at all.
I think we just need to remember if there was at least one page that
failed isolation or migration, but keep working, and in the end return
EIO if there was such page(s). I don't think it breaks the policy. Once
pages are allocated in a mapping, changing the policy is a best effort
thing anyway.
>>
>>
>
^ permalink raw reply
* Re: [PATCH net-next 1/3] net/sched: Introduce action ct
From: Paul Blakey @ 2019-06-20 7:07 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: Jiri Pirko, Roi Dayan, Yossi Kuperman, Oz Shlomo,
netdev@vger.kernel.org, David Miller, Aaron Conole, Zhike Wang,
Rony Efraim, nst-kernel@redhat.com, John Hurley, Simon Horman,
Justin Pettit
In-Reply-To: <20190619183313.GA2746@localhost.localdomain>
On 6/19/2019 9:33 PM, Marcelo Ricardo Leitner wrote:
> On Tue, Jun 11, 2019 at 04:28:31PM +0300, Paul Blakey wrote:
> ...
>> +static int tcf_ct_fill_params_nat(struct tcf_ct_params *p,
>> + struct tc_ct *parm,
>> + struct nlattr **tb,
>> + struct netlink_ext_ack *extack)
>> +{
>> + struct nf_nat_range2 *range;
>> +
>> + if (!(p->ct_action & TCA_CT_ACT_NAT))
>> + return 0;
>> +
>> + if (!IS_ENABLED(CONFIG_NF_NAT)) {
>> + NL_SET_ERR_MSG_MOD(extack, "Netfilter nat isn't enabled in kernel");
>> + return -EOPNOTSUPP;
>> + }
>> +
>> + if (!(p->ct_action & (TCA_CT_ACT_NAT_SRC | TCA_CT_ACT_NAT_DST)))
>> + return 0;
>> +
>> + if ((p->ct_action & TCA_CT_ACT_NAT_SRC) &&
>> + (p->ct_action & TCA_CT_ACT_NAT_DST)) {
>> + NL_SET_ERR_MSG_MOD(extack, "dnat and snat can't be enabled at the same time");
>> + return -EOPNOTSUPP;
>> + }
>> +
>> + range = &p->range;
>> + if (tb[TCA_CT_NAT_IPV4_MIN]) {
>> + range->min_addr.ip =
>> + nla_get_in_addr(tb[TCA_CT_NAT_IPV4_MIN]);
>> + range->flags |= NF_NAT_RANGE_MAP_IPS;
>> + p->ipv4_range = true;
>> + }
>> + if (tb[TCA_CT_NAT_IPV4_MAX]) {
>> + range->max_addr.ip =
>> + nla_get_in_addr(tb[TCA_CT_NAT_IPV4_MAX]);
>> + range->flags |= NF_NAT_RANGE_MAP_IPS;
>> + p->ipv4_range = true;
>> + } else if (range->min_addr.ip) {
>> + range->max_addr.ip = range->min_addr.ip;
>> + }
>> +
>> + if (tb[TCA_CT_NAT_IPV6_MIN]) {
>> + range->min_addr.in6 =
>> + nla_get_in6_addr(tb[TCA_CT_NAT_IPV6_MIN]);
>> + range->flags |= NF_NAT_RANGE_MAP_IPS;
>> + p->ipv4_range = false;
>> + }
>> + if (tb[TCA_CT_NAT_IPV6_MAX]) {
>> + range->max_addr.in6 =
>> + nla_get_in6_addr(tb[TCA_CT_NAT_IPV6_MAX]);
>> + range->flags |= NF_NAT_RANGE_MAP_IPS;
>> + p->ipv4_range = false;
>> + } else if (memchr_inv(&range->min_addr.in6, 0,
>> + sizeof(range->min_addr.in6))) {
>> + range->max_addr.in6 = range->min_addr.in6;
> This will overwrite ipv4_max if it was used, as min/max_addr are
> unions.
> What about having the _MAX handling (for both ipv4/6) inside the
> if (.._MIN) { } block ?
Yes that what I planned on doing:
range = &p->range;
if (tb[TCA_CT_NAT_IPV4_MIN]) {
p->ipv4_range = true;
range->flags |= NF_NAT_RANGE_MAP_IPS;
range->min_addr.ip =
nla_get_in_addr(tb[TCA_CT_NAT_IPV4_MIN]);
range->max_addr.ip = tb[TCA_CT_NAT_IPV4_MAX] ?
nla_get_in_addr(tb[TCA_CT_NAT_IPV4_MAX]) :
range->min_addr.ip;
} else if (tb[TCA_CT_NAT_IPV6_MIN]) {
p->ipv4_range = false;
range->flags |= NF_NAT_RANGE_MAP_IPS;
range->min_addr.in6 =
nla_get_in6_addr(tb[TCA_CT_NAT_IPV6_MIN]);
range->max_addr.in6 = tb[TCA_CT_NAT_IPV6_MAX] ?
nla_get_in6_addr(tb[TCA_CT_NAT_IPV6_MAX]) :
range->min_addr.in6;
}
if (tb[TCA_CT_NAT_PORT_MIN]) {
range->flags |= NF_NAT_RANGE_PROTO_SPECIFIED;
range->min_proto.all =
nla_get_be16(tb[TCA_CT_NAT_PORT_MIN]);
range->max_proto.all = tb[TCA_CT_NAT_PORT_MAX]?
nla_get_be16(tb[TCA_CT_NAT_PORT_MAX]) :
range->min_proto.all;
>> + }
>> +
^ permalink raw reply
* [PATCH mlx5-next] net/mlx5: Convert mkey_table to XArray
From: Saeed Mahameed @ 2019-06-20 7:03 UTC (permalink / raw)
To: Saeed Mahameed, Leon Romanovsky
Cc: Jason Gunthorpe, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, Matthew Wilcox
From: Matthew Wilcox <willy@infradead.org>
The lock protecting the data structure does not need to be an rwlock. The
only read access to the lock is in an error path, and if that's limiting
your scalability, you have bigger performance problems.
Eliminate mlx5_mkey_table in favour of using the xarray directly.
reg_mr_callback must use GFP_ATOMIC for allocating XArray nodes as it may
be called in interrupt context.
This also fixes a minor bug where SRCU locking was being used on the radix
tree read side, when RCU was needed too.
Change-Id: Ifeedbbc8f2c856cc044094d03167aae9f9162400
Signed-off-by: Matthew Wilcox <willy@infradead.org>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/infiniband/hw/mlx5/cq.c | 8 +++---
drivers/infiniband/hw/mlx5/devx.c | 18 +++----------
drivers/infiniband/hw/mlx5/mr.c | 10 ++++----
drivers/infiniband/hw/mlx5/odp.c | 10 ++++----
drivers/net/ethernet/mellanox/mlx5/core/mr.c | 27 ++++++++------------
include/linux/mlx5/driver.h | 13 ++--------
include/linux/mlx5/qp.h | 5 ----
7 files changed, 31 insertions(+), 60 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/cq.c b/drivers/infiniband/hw/mlx5/cq.c
index 2e2e65f00257..0220736b073e 100644
--- a/drivers/infiniband/hw/mlx5/cq.c
+++ b/drivers/infiniband/hw/mlx5/cq.c
@@ -522,9 +522,9 @@ static int mlx5_poll_one(struct mlx5_ib_cq *cq,
case MLX5_CQE_SIG_ERR:
sig_err_cqe = (struct mlx5_sig_err_cqe *)cqe64;
- read_lock(&dev->mdev->priv.mkey_table.lock);
- mmkey = __mlx5_mr_lookup(dev->mdev,
- mlx5_base_mkey(be32_to_cpu(sig_err_cqe->mkey)));
+ xa_lock(&dev->mdev->priv.mkey_table);
+ mmkey = xa_load(&dev->mdev->priv.mkey_table,
+ mlx5_base_mkey(be32_to_cpu(sig_err_cqe->mkey)));
mr = to_mibmr(mmkey);
get_sig_err_item(sig_err_cqe, &mr->sig->err_item);
mr->sig->sig_err_exists = true;
@@ -537,7 +537,7 @@ static int mlx5_poll_one(struct mlx5_ib_cq *cq,
mr->sig->err_item.expected,
mr->sig->err_item.actual);
- read_unlock(&dev->mdev->priv.mkey_table.lock);
+ xa_unlock(&dev->mdev->priv.mkey_table);
goto repoll;
}
diff --git a/drivers/infiniband/hw/mlx5/devx.c b/drivers/infiniband/hw/mlx5/devx.c
index 80b42d069328..931f587dfb8f 100644
--- a/drivers/infiniband/hw/mlx5/devx.c
+++ b/drivers/infiniband/hw/mlx5/devx.c
@@ -1043,13 +1043,10 @@ static int devx_handle_mkey_indirect(struct devx_obj *obj,
struct mlx5_ib_dev *dev,
void *in, void *out)
{
- struct mlx5_mkey_table *table = &dev->mdev->priv.mkey_table;
struct mlx5_ib_devx_mr *devx_mr = &obj->devx_mr;
- unsigned long flags;
struct mlx5_core_mkey *mkey;
void *mkc;
u8 key;
- int err;
mkey = &devx_mr->mmkey;
mkc = MLX5_ADDR_OF(create_mkey_in, in, memory_key_mkey_entry);
@@ -1062,11 +1059,8 @@ static int devx_handle_mkey_indirect(struct devx_obj *obj,
mkey->pd = MLX5_GET(mkc, mkc, pd);
devx_mr->ndescs = MLX5_GET(mkc, mkc, translations_octword_size);
- write_lock_irqsave(&table->lock, flags);
- err = radix_tree_insert(&table->tree, mlx5_base_mkey(mkey->key),
- mkey);
- write_unlock_irqrestore(&table->lock, flags);
- return err;
+ return xa_err(xa_store(&dev->mdev->priv.mkey_table,
+ mlx5_base_mkey(mkey->key), mkey, GFP_KERNEL));
}
static int devx_handle_mkey_create(struct mlx5_ib_dev *dev,
@@ -1117,12 +1111,8 @@ static void devx_free_indirect_mkey(struct rcu_head *rcu)
*/
static void devx_cleanup_mkey(struct devx_obj *obj)
{
- struct mlx5_mkey_table *table = &obj->mdev->priv.mkey_table;
- unsigned long flags;
-
- write_lock_irqsave(&table->lock, flags);
- radix_tree_delete(&table->tree, mlx5_base_mkey(obj->devx_mr.mmkey.key));
- write_unlock_irqrestore(&table->lock, flags);
+ xa_erase(&obj->mdev->priv.mkey_table,
+ mlx5_base_mkey(obj->devx_mr.mmkey.key));
}
static int devx_obj_cleanup(struct ib_uobject *uobject,
diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c
index 5f09699fab98..83b452d977d4 100644
--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@ -130,7 +130,7 @@ static void reg_mr_callback(int status, struct mlx5_async_work *context)
struct mlx5_cache_ent *ent = &cache->ent[c];
u8 key;
unsigned long flags;
- struct mlx5_mkey_table *table = &dev->mdev->priv.mkey_table;
+ struct xarray *mkeys = &dev->mdev->priv.mkey_table;
int err;
spin_lock_irqsave(&ent->lock, flags);
@@ -158,12 +158,12 @@ static void reg_mr_callback(int status, struct mlx5_async_work *context)
ent->size++;
spin_unlock_irqrestore(&ent->lock, flags);
- write_lock_irqsave(&table->lock, flags);
- err = radix_tree_insert(&table->tree, mlx5_base_mkey(mr->mmkey.key),
- &mr->mmkey);
+ xa_lock_irqsave(mkeys, flags);
+ err = xa_err(__xa_store(mkeys, mlx5_base_mkey(mr->mmkey.key),
+ &mr->mmkey, GFP_ATOMIC));
+ xa_unlock_irqrestore(mkeys, flags);
if (err)
pr_err("Error inserting to mkey tree. 0x%x\n", -err);
- write_unlock_irqrestore(&table->lock, flags);
if (!completion_done(&ent->compl))
complete(&ent->compl);
diff --git a/drivers/infiniband/hw/mlx5/odp.c b/drivers/infiniband/hw/mlx5/odp.c
index 12ccee1eb047..c594489eb2d7 100644
--- a/drivers/infiniband/hw/mlx5/odp.c
+++ b/drivers/infiniband/hw/mlx5/odp.c
@@ -768,7 +768,7 @@ static int pagefault_single_data_segment(struct mlx5_ib_dev *dev,
bcnt -= *bytes_committed;
next_mr:
- mmkey = __mlx5_mr_lookup(dev->mdev, mlx5_base_mkey(key));
+ mmkey = xa_load(&dev->mdev->priv.mkey_table, mlx5_base_mkey(key));
if (!mkey_is_eq(mmkey, key)) {
mlx5_ib_dbg(dev, "failed to find mkey %x\n", key);
ret = -EFAULT;
@@ -1686,8 +1686,8 @@ static void num_pending_prefetch_dec(struct mlx5_ib_dev *dev,
struct mlx5_core_mkey *mmkey;
struct mlx5_ib_mr *mr;
- mmkey = __mlx5_mr_lookup(dev->mdev,
- mlx5_base_mkey(sg_list[i].lkey));
+ mmkey = xa_load(&dev->mdev->priv.mkey_table,
+ mlx5_base_mkey(sg_list[i].lkey));
mr = container_of(mmkey, struct mlx5_ib_mr, mmkey);
atomic_dec(&mr->num_pending_prefetch);
}
@@ -1706,8 +1706,8 @@ static bool num_pending_prefetch_inc(struct ib_pd *pd,
struct mlx5_core_mkey *mmkey;
struct mlx5_ib_mr *mr;
- mmkey = __mlx5_mr_lookup(dev->mdev,
- mlx5_base_mkey(sg_list[i].lkey));
+ mmkey = xa_load(&dev->mdev->priv.mkey_table,
+ mlx5_base_mkey(sg_list[i].lkey));
if (!mmkey || mmkey->key != sg_list[i].lkey) {
ret = false;
break;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/mr.c b/drivers/net/ethernet/mellanox/mlx5/core/mr.c
index ea744d8466ea..9231b39d18b2 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/mr.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/mr.c
@@ -38,15 +38,12 @@
void mlx5_init_mkey_table(struct mlx5_core_dev *dev)
{
- struct mlx5_mkey_table *table = &dev->priv.mkey_table;
-
- memset(table, 0, sizeof(*table));
- rwlock_init(&table->lock);
- INIT_RADIX_TREE(&table->tree, GFP_ATOMIC);
+ xa_init_flags(&dev->priv.mkey_table, XA_FLAGS_LOCK_IRQ);
}
void mlx5_cleanup_mkey_table(struct mlx5_core_dev *dev)
{
+ WARN_ON(!xa_empty(&dev->priv.mkey_table));
}
int mlx5_core_create_mkey_cb(struct mlx5_core_dev *dev,
@@ -56,8 +53,8 @@ int mlx5_core_create_mkey_cb(struct mlx5_core_dev *dev,
mlx5_async_cbk_t callback,
struct mlx5_async_work *context)
{
- struct mlx5_mkey_table *table = &dev->priv.mkey_table;
u32 lout[MLX5_ST_SZ_DW(create_mkey_out)] = {0};
+ struct xarray *mkeys = &dev->priv.mkey_table;
u32 mkey_index;
void *mkc;
int err;
@@ -88,12 +85,10 @@ int mlx5_core_create_mkey_cb(struct mlx5_core_dev *dev,
mlx5_core_dbg(dev, "out 0x%x, key 0x%x, mkey 0x%x\n",
mkey_index, key, mkey->key);
- /* connect to mkey tree */
- write_lock_irq(&table->lock);
- err = radix_tree_insert(&table->tree, mlx5_base_mkey(mkey->key), mkey);
- write_unlock_irq(&table->lock);
+ err = xa_err(xa_store_irq(mkeys, mlx5_base_mkey(mkey->key), mkey,
+ GFP_KERNEL));
if (err) {
- mlx5_core_warn(dev, "failed radix tree insert of mkey 0x%x, %d\n",
+ mlx5_core_warn(dev, "failed xarray insert of mkey 0x%x, %d\n",
mlx5_base_mkey(mkey->key), err);
mlx5_core_destroy_mkey(dev, mkey);
}
@@ -114,17 +109,17 @@ EXPORT_SYMBOL(mlx5_core_create_mkey);
int mlx5_core_destroy_mkey(struct mlx5_core_dev *dev,
struct mlx5_core_mkey *mkey)
{
- struct mlx5_mkey_table *table = &dev->priv.mkey_table;
u32 out[MLX5_ST_SZ_DW(destroy_mkey_out)] = {0};
u32 in[MLX5_ST_SZ_DW(destroy_mkey_in)] = {0};
+ struct xarray *mkeys = &dev->priv.mkey_table;
struct mlx5_core_mkey *deleted_mkey;
unsigned long flags;
- write_lock_irqsave(&table->lock, flags);
- deleted_mkey = radix_tree_delete(&table->tree, mlx5_base_mkey(mkey->key));
- write_unlock_irqrestore(&table->lock, flags);
+ xa_lock_irqsave(mkeys, flags);
+ deleted_mkey = __xa_erase(mkeys, mlx5_base_mkey(mkey->key));
+ xa_unlock_irqrestore(mkeys, flags);
if (!deleted_mkey) {
- mlx5_core_dbg(dev, "failed radix tree delete of mkey 0x%x\n",
+ mlx5_core_dbg(dev, "failed xarray delete of mkey 0x%x\n",
mlx5_base_mkey(mkey->key));
return -ENOENT;
}
diff --git a/include/linux/mlx5/driver.h b/include/linux/mlx5/driver.h
index d8ab633406c2..87f77ded78d4 100644
--- a/include/linux/mlx5/driver.h
+++ b/include/linux/mlx5/driver.h
@@ -41,7 +41,7 @@
#include <linux/semaphore.h>
#include <linux/slab.h>
#include <linux/vmalloc.h>
-#include <linux/radix-tree.h>
+#include <linux/xarray.h>
#include <linux/workqueue.h>
#include <linux/mempool.h>
#include <linux/interrupt.h>
@@ -452,13 +452,6 @@ struct mlx5_qp_table {
struct radix_tree_root tree;
};
-struct mlx5_mkey_table {
- /* protect radix tree
- */
- rwlock_t lock;
- struct radix_tree_root tree;
-};
-
struct mlx5_vf_context {
int enabled;
u64 port_guid;
@@ -546,9 +539,7 @@ struct mlx5_priv {
struct dentry *cmdif_debugfs;
/* end: qp staff */
- /* start: mkey staff */
- struct mlx5_mkey_table mkey_table;
- /* end: mkey staff */
+ struct xarray mkey_table;
/* start: alloc staff */
/* protect buffer alocation according to numa node */
diff --git a/include/linux/mlx5/qp.h b/include/linux/mlx5/qp.h
index 3ba4edbd17a6..d1f353c64797 100644
--- a/include/linux/mlx5/qp.h
+++ b/include/linux/mlx5/qp.h
@@ -551,11 +551,6 @@ static inline struct mlx5_core_qp *__mlx5_qp_lookup(struct mlx5_core_dev *dev, u
return radix_tree_lookup(&dev->priv.qp_table.tree, qpn);
}
-static inline struct mlx5_core_mkey *__mlx5_mr_lookup(struct mlx5_core_dev *dev, u32 key)
-{
- return radix_tree_lookup(&dev->priv.mkey_table.tree, key);
-}
-
int mlx5_core_create_dct(struct mlx5_core_dev *dev,
struct mlx5_core_dct *qp,
u32 *in, int inlen,
--
2.21.0
^ permalink raw reply related
* [PATCH bpf] samples/bpf: xdp_redirect, correctly get dummy program id
From: Prashant Bhole @ 2019-06-20 6:58 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann; +Cc: Prashant Bhole, netdev, bpf
When we terminate xdp_redirect, it ends up with following message:
"Program on iface OUT changed, not removing"
This results in dummy prog still attached to OUT interface.
It is because signal handler checks if the programs are the same that
we had attached. But while fetching dummy_prog_id, current code uses
prog_fd instead of dummy_prog_fd. This patch passes the correct fd.
Fixes: 3b7a8ec2dec3 ("samples/bpf: Check the prog id before exiting")
Signed-off-by: Prashant Bhole <prashantbhole.linux@gmail.com>
---
samples/bpf/xdp_redirect_user.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/samples/bpf/xdp_redirect_user.c b/samples/bpf/xdp_redirect_user.c
index e9054c0269ff..1299e0f61dad 100644
--- a/samples/bpf/xdp_redirect_user.c
+++ b/samples/bpf/xdp_redirect_user.c
@@ -197,7 +197,7 @@ int main(int argc, char **argv)
}
memset(&info, 0, sizeof(info));
- ret = bpf_obj_get_info_by_fd(prog_fd, &info, &info_len);
+ ret = bpf_obj_get_info_by_fd(dummy_prog_fd, &info, &info_len);
if (ret) {
printf("can't get prog info - %s\n", strerror(errno));
return ret;
--
2.20.1
^ permalink raw reply related
* skb_to_sgvec() casuses sg_pcopy_to_buffer() wrong
From: Hayes Wang @ 2019-06-20 6:17 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: palmer@sifive.com, axboe@kernel.dk, linux-kernel@vger.kernel.org,
nic_swsd
Use skb_to_sgvec() to set scatter list, and sometime we would get a
sg->offset which is more than PAGE_SIZE. Call sg_pcopy_to_buffer()
with this scatter list would get wrong data.
In sg_miter_get_next_page(), you would get wrong miter->__remaining,
when the sg->offset is more than PAGE_SIZE.
static bool sg_miter_get_next_page(struct sg_mapping_iter *miter)
{
if (!miter->__remaining) {
struct scatterlist *sg;
unsigned long pgoffset;
if (!__sg_page_iter_next(&miter->piter))
return false;
sg = miter->piter.sg;
pgoffset = miter->piter.sg_pgoffset;
miter->__offset = pgoffset ? 0 : sg->offset;
miter->__remaining = sg->offset + sg->length -
(pgoffset << PAGE_SHIFT) - miter->__offset;
miter->__remaining = min_t(unsigned long, miter->__remaining,
PAGE_SIZE - miter->__offset);
}
return true;
}
Best Regards,
Hayes
^ permalink raw reply
* RE: [PATCH v3 bpf-next 3/9] bpf: extend is_branch_taken to registers
From: John Fastabend @ 2019-06-20 6:01 UTC (permalink / raw)
To: Alexei Starovoitov, davem; +Cc: daniel, netdev, bpf, kernel-team
In-Reply-To: <20190615191225.2409862-4-ast@kernel.org>
Alexei Starovoitov wrote:
> This patch extends is_branch_taken() logic from JMP+K instructions
> to JMP+X instructions.
> Conditional branches are often done when src and dst registers
> contain known scalars. In such case the verifier can follow
> the branch that is going to be taken when program executes.
> That speeds up the verification and is essential feature to support
> bounded loops.
>
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> Acked-by: Andrii Nakryiko <andriin@fb.com>
> ---
Acked-by: John Fastabend <john.fastabend@gmail.com>
^ permalink raw reply
* RE: [PATCH v2 2/5] net: macb: add support for sgmii MAC-PHY interface
From: Parshuram Raju Thombare @ 2019-06-20 5:56 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: andrew@lunn.ch, nicolas.ferre@microchip.com, davem@davemloft.net,
f.fainelli@gmail.com, netdev@vger.kernel.org,
hkallweit1@gmail.com, linux-kernel@vger.kernel.org,
Rafal Ciepiela, Anil Joy Varughese, Piotr Sroka
In-Reply-To: <20190619123206.zvc7gzt4ewxby2y2@shell.armlinux.org.uk>
>From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
>
>On Wed, Jun 19, 2019 at 11:23:01AM +0000, Parshuram Raju Thombare wrote:
>
>> >From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
>
>> >
>
>> >On Wed, Jun 19, 2019 at 09:40:46AM +0100, Parshuram Thombare wrote:
>
>> >
>
>> >> This patch add support for SGMII interface) and
>
>> >
>
>> >> 2.5Gbps MAC in Cadence ethernet controller driver.
>
>>
>
>> >> switch (state->interface) {
>
>> >
>
>> >> + case PHY_INTERFACE_MODE_SGMII:
>
>> >
>
>> >> + if (bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE)
>
>> >
>
>> >> + phylink_set(mask, 2500baseT_Full);
>
>> >
>
>> >
>
>> >
>
>> >This doesn't look correct to me. SGMII as defined by Cisco only
>
>> >supports 1G, 100M and 10M speeds, not 2.5G.
>
>>
>
>> Cadence MAC support 2.5G SGMII by using higher clock frequency.
>
>
>
>Ok, so why not set 2.5GBASE-X too? Does the MAC handle auto-detecting
>
>the SGMII/BASE-X speed itself or does it need to be programmed? If it
>
>needs to be programmed, you need additional handling in the validate
>
>callback to deal with that.
No, currently MAC can't auto detect it, it need to be programmed.
But I think programming speed/duplex mode is already done for non in-band
modes in mac_config.
For in band mode, I see two places to config MAC speed
and duplex mode, 1. mac_link_state 2. mac_link_up. In mac_link_up, though state
read from mac_link_state is passed, it is only used for printing log and updating
pl->cur_interface, so if configuring MAC speed/duplex mode in mac_link_up is correct,
these parameters will need to read again from HW.
>> >> + case PHY_INTERFACE_MODE_2500BASEX:
>
>> >
>
>> >> + if (bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE)
>
>> >
>
>> >> + phylink_set(mask, 2500baseX_Full);
>
>> >
>
>> >> + /* fallthrough */
>
>> >
>
>> >> + case PHY_INTERFACE_MODE_1000BASEX:
>
>> >
>
>> >> + if (bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE)
>
>> >
>
>> >> + phylink_set(mask, 1000baseX_Full);
>
>> >
>
>> >> + break;
>
>> >
>
>> >
>
>> >
>
>> >Please see how other drivers which use phylink deal with the validate()
>
>> >format, and please read the phylink documentation:
>
>> >
>
>> > * Note that the PHY may be able to transform from one connection
>
>> > * technology to another, so, eg, don't clear 1000BaseX just
>
>> > * because the MAC is unable to BaseX mode. This is more about
>
>> > * clearing unsupported speeds and duplex settings.
>
>> >
>
>>
>
>> There are some configs used in this driver which limits MAC speed.
>
>> Above checks just to make sure this use case does not break.
>
>
>
>That's not what I'm saying.
>
>
>
>By way of example, you're offering 1000BASE-T just because the MAC
>
>connection supports it. However, the MAC doesn't _actually_ support
>
>1000BASE-T, it supports a connection to a PHY that _happens_ to
>
>convert the MAC connection to 1000BASE-T. It could equally well
>
>convert the MAC connection to 1000BASE-X.
>
>
>
>So, only setting 1000BASE-X when you have a PHY connection using
>
>1000BASE-X is fundamentally incorrect.
>
>
>
>For example, you could have a MAC <-> PHY link using standard 1.25Gbps
>
>SGMII, and the PHY offers 1000BASE-T _and_ 1000BASE-X connections on
>
>a first-link-up basis. An example of a PHY that does this are the
>
>Marvell 1G PHYs (eg, 88E151x).
>
>
>
>This point is detailed in the PHYLINK documentation, which I quoted
>
>above.
Ok, I will not clear 1000/2500BASE-T for PHY connection is just 1000/2500BASE-X
Also I will keep 1000/2500BASE-X link modes for SGMII/GMII modes.
>
>
>> >> @@ -506,18 +563,26 @@ static void gem_mac_config(struct phylink_config
>
>> >*pl_config, unsigned int mode,
>
>> >> switch (state->speed) {
>
>> >> + case SPEED_2500:
>
>> >> + gem_writel(bp, NCFGR, GEM_BIT(GBE) |
>
>> >> + gem_readl(bp, NCFGR));
>
>> >> }
>
>> >> - macb_or_gem_writel(bp, NCFGR, reg);
>
>> >>
>
>> >> bp->speed = state->speed;
>
>> >> bp->duplex = state->duplex;
>
>> >
>
>> >
>
>> >
>
>> >This is not going to work for 802.3z nor SGMII properly when in-band
>
>> >negotiation is used. We don't know ahead of time what the speed and
>
>> >duplex will be. Please see existing drivers for examples showing
>
>> >how mac_config() should be implemented (there's good reason why its
>
>> >laid out as it is in those drivers.)
>
>> >
>
>> Ok, Here I will configure MAC only for FIXED and PHY mode.
>
>
>
>As you are not the only one who has made this error, I'm considering
>
>splitting mac_config() into mac_config_fixed() and mac_config_inband()
>
>so that it's clearer what is required. Maybe even taking separate
>
>structures so that it's impossible to access members that should not
>
>be used.
>
For in band mode, I see two places to config MAC speed
and duplex mode - 1. mac_link_state 2. mac_link_up.
In mac_link_up, though state read from mac_link_state is passed,
it is only used for printing log and updating pl->cur_interface,
so if configuring MAC speed/duplex mode in mac_link_up is correct,
these parameters will need to read again from HW.
>
>--
>
>RMK's Patch system: https://urldefense.proofpoint.com/v2/url?u=https-
>3A__www.armlinux.org.uk_developer_patches_&d=DwIBAg&c=aUq983L2pue2F
>qKFoP6PGHMJQyoJ7kl3s3GZ-_haXqY&r=GTefrem3hiBCnsjCOqAuapQHRN8-
>rKC1FRbk0it-LDs&m=qYg0cUy9RXzvJcQIwLNjHCC8tbUg_-
>k2oqUIMDpStiA&s=xUkYplnpxrywxVfsk-J5c2Z6_K96ELTBkgC5g37OXTE&e=
>
>FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
>
>According to speedtest.net: 11.9Mbps down 500kbps up
Regards,
Parshuram Thombare
^ permalink raw reply
* RE: [PATCH v3 bpf-next 2/9] selftests/bpf: fix tests due to const spill/fill
From: John Fastabend @ 2019-06-20 5:40 UTC (permalink / raw)
To: Alexei Starovoitov, davem; +Cc: daniel, netdev, bpf, kernel-team
In-Reply-To: <20190615191225.2409862-3-ast@kernel.org>
Alexei Starovoitov wrote:
> fix tests that incorrectly assumed that the verifier
> cannot track constants through stack.
>
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> Acked-by: Andrii Nakryiko <andriin@fb.com>
> ---
> .../bpf/verifier/direct_packet_access.c | 3 +-
> .../bpf/verifier/helper_access_var_len.c | 28 ++++++++++---------
> 2 files changed, 17 insertions(+), 14 deletions(-)
>
Acked-by: John Fastabend <john.fastabend@gmail.com>
^ permalink raw reply
* selftests: bpf: test_align Test 4 unknown shift Failed to find match 7 R0=pkt(id=0,off=8,r=8,imm=0)
From: Naresh Kamboju @ 2019-06-20 5:25 UTC (permalink / raw)
To: Netdev, open list, Linux-Next Mailing List, bpf
Cc: David S. Miller, Daniel Borkmann, Alexei Starovoitov, kafai,
Yonghong Song
selftests: bpf: test_align failed running Linux -next kernel
5.2.0-rc5-next-20190619.
Here is the log from x86_64,
# selftests bpf test_align
bpf: test_align_ #
# Test 0 mov ... PASS
0: mov_... #
# Test 1 shift ... PASS
1: shift_... #
# Test 2 addsub ... PASS
2: addsub_... #
# Test 3 mul ... PASS
3: mul_... #
# Test 4 unknown shift ... Failed to find match 7 R0=pkt(id=0,off=8,r=8,imm=0)
4: unknown_shift #
# func#0 @0
@0: _ #
# 0 R1=ctx(id=0,off=0,imm=0) R10=fp0
R1=ctx(id=0,off=0,imm=0): R10=fp0_ #
# 0 (61) r2 = *(u32 *)(r1 +76)
(61): r2_= #
# 1 R1=ctx(id=0,off=0,imm=0) R2_w=pkt(id=0,off=0,r=0,imm=0) R10=fp0
R1=ctx(id=0,off=0,imm=0): R2_w=pkt(id=0,off=0,r=0,imm=0)_R10=fp0 #
# 1 (61) r3 = *(u32 *)(r1 +80)
(61): r3_= #
# 2 R1=ctx(id=0,off=0,imm=0) R2_w=pkt(id=0,off=0,r=0,imm=0)
R3_w=pkt_end(id=0,off=0,imm=0) R10=fp0
R1=ctx(id=0,off=0,imm=0):
R2_w=pkt(id=0,off=0,r=0,imm=0)_R3_w=pkt_end(id=0,off=0,imm=0) #
# 2 (bf) r0 = r2
(bf): r0_= #
...
# processed 22 insns (limit 1000000) max_states_per_insn 0
total_states 1 peak_states 1 mark_read 1
22: insns_(limit #
# FAIL
: _ #
# Results 6 pass 6 fail
6: pass_6 #
[FAIL] 7 selftests bpf test_align
selftests: bpf_test_align [FAIL]
Full test log,
https://qa-reports.linaro.org/lkft/linux-next-oe/build/next-20190619/testrun/781777/log
Test results comparison,
https://qa-reports.linaro.org/lkft/linux-next-oe/tests/kselftest/bpf_test_align
Good linux -next tag: next-20190618
Bad linux -next tag: next-20190619
git branch master
git commit c0e4c41afeef66d21dc5704f614624cecac806ac
git describe next-20190618
git repo
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
Best regards
Naresh Kamboju
^ permalink raw reply
* RE: [PATCH net-next v6 2/5] net: stmmac: introducing support for DWC xPCS logics
From: Ong, Boon Leong @ 2019-06-20 5:13 UTC (permalink / raw)
To: Jose Abreu, Florian Fainelli, David S. Miller, biao huang,
Andrew Lunn
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Giuseppe Cavallaro, Alexandre Torgue, Kweh, Hock Leong,
Maxime Coquelin, Russell King, Voon, Weifeng
In-Reply-To: <AF233D1473C1364ABD51D28909A1B1B75C12D381@pgsmsx114.gar.corp.intel.com>
>>From: Jose Abreu [mailto:Jose.Abreu@synopsys.com]
>>From: Florian Fainelli <f.fainelli@gmail.com>
>>
>>> +Russell,
>>>
>>> On 6/4/2019 11:58 AM, Voon Weifeng wrote:
>>> > From: Ong Boon Leong <boon.leong.ong@intel.com>
>>> >
>>> > xPCS is DWC Ethernet Physical Coding Sublayer that may be integrated
>>> > into a GbE controller that uses DWC EQoS MAC controller. An example of
>>> > HW configuration is shown below:-
>>> >
>>> > <-----------------GBE Controller---------->|<--External PHY chip-->
>>> >
>>> > +----------+ +----+ +---+ +--------------+
>>> > | EQoS | <-GMII->| DW |<-->|PHY| <-- SGMII --> | External GbE |
>>> > | MAC | |xPCS| |IF | | PHY Chip |
>>> > +----------+ +----+ +---+ +--------------+
>>> > ^ ^ ^
>>> > | | |
>>> > +---------------------MDIO-------------------------+
>>> >
>>> > xPCS is a Clause-45 MDIO Manageable Device (MMD) and we need a way
>>to
>>> > differentiate it from external PHY chip that is discovered over MDIO.
>>> > Therefore, xpcs_phy_addr is introduced in stmmac platform data
>>> > (plat_stmmacenet_data) for differentiating xPCS from 'phy_addr' that
>>> > belongs to external PHY.
>>>
>>> Assuming this DW xPCS can be found with designs other than STMMAC
>>would
>>> not it make sense to model this as some kind of PHY/MDIO bridge? A
>>> little bit like what drivers/net/phy/xilinx_gmii2rgmii.c tries to do?
>>
>>Yes, DW XPCS is a separate IP that can be sold without the MAC.
>
>Hi Florian, thanks for pointing out the PHY driver for GMII to RGMII converter
>implementation. It seems like community would like dwxpcs to take the
>converter phy driver direction.
>
>We would like to check with community what is the MAC controller that is
>using above PHY driver so that we can dig deeper into the PHY & MAC driver
>architecture. We would like to map the existing usage of dwxpcs.c in 3/5 of
>this series is architecturally ready for PHY driver framework or new APIs
>would need to be defined.
Just to cycle-back to this track, we are working towards getting the ACPI device
ID for this IP. Meanwhile, since the C45 MDIO patych is also needed by
Biao, we plan to line up the below patch for merge.
[PATCH net-next v6 1/5] net: stmmac: enable clause 45 mdio support
Is there any concern with this approach?
^ permalink raw reply
* Re: [PATCH v3 bpf-next 1/9] bpf: track spill/fill of constants
From: John Fastabend @ 2019-06-20 5:04 UTC (permalink / raw)
To: Alexei Starovoitov, John Fastabend
Cc: Alexei Starovoitov, davem, daniel, netdev, bpf, kernel-team
In-Reply-To: <20190620033538.4oou4mbck6xs64mj@ast-mbp.dhcp.thefacebook.com>
Alexei Starovoitov wrote:
> On Wed, Jun 19, 2019 at 05:24:32PM -0700, John Fastabend wrote:
> > Alexei Starovoitov wrote:
> > > Compilers often spill induction variables into the stack,
> > > hence it is necessary for the verifier to track scalar values
> > > of the registers through stack slots.
> > >
> > > Also few bpf programs were incorrectly rejected in the past,
> > > since the verifier was not able to track such constants while
> > > they were used to compute offsets into packet headers.
> > >
> > > Tracking constants through the stack significantly decreases
> > > the chances of state pruning, since two different constants
> > > are considered to be different by state equivalency.
> > > End result that cilium tests suffer serious degradation in the number
> > > of states processed and corresponding verification time increase.
> > >
> > > before after
> > > bpf_lb-DLB_L3.o 1838 6441
> > > bpf_lb-DLB_L4.o 3218 5908
> > > bpf_lb-DUNKNOWN.o 1064 1064
> > > bpf_lxc-DDROP_ALL.o 26935 93790
> > > bpf_lxc-DUNKNOWN.o 34439 123886
> > > bpf_netdev.o 9721 31413
> > > bpf_overlay.o 6184 18561
> > > bpf_lxc_jit.o 39389 359445
> > >
> > > After further debugging turned out that cillium progs are
> > > getting hurt by clang due to the same constant tracking issue.
> > > Newer clang generates better code by spilling less to the stack.
> > > Instead it keeps more constants in the registers which
> > > hurts state pruning since the verifier already tracks constants
> > > in the registers:
> > > old clang new clang
> > > (no spill/fill tracking introduced by this patch)
> > > bpf_lb-DLB_L3.o 1838 1923
> > > bpf_lb-DLB_L4.o 3218 3077
> > > bpf_lb-DUNKNOWN.o 1064 1062
> > > bpf_lxc-DDROP_ALL.o 26935 166729
> > > bpf_lxc-DUNKNOWN.o 34439 174607
> > ^^^^^^^^^^^^^^
> > Any idea what happened here? Going from 34439 -> 174607 on the new clang?
>
> As I was alluding in commit log newer clang is smarter and generates
> less spill/fill of constants.
> In particular older clang loads two constants into r8 and r9
> and immediately spills them into stack. Then fills later,
> does a bunch of unrelated code and calls into helper that
> has ARG_ANYTHING for that position. Then doing a bit more math
> on filled constants, spills them again and so on.
> Before this patch (that tracks spill/fill of constants into stack)
> pruning points were equivalent, but with the patch it sees the difference
> in registers and declares states not equivalent, though any constant
> is fine from safety standpoint.
> With new clang only r9 has this pattern of spill/fill.
> New clang manages to keep constant in r8 to be around without spill/fill.
> Existing verifier tracks constants so even without this patch
> the same pathalogical behavior is observed.
> The verifier need to walk a lot more instructions only because
> r8 has different constants.
>
Got it I'll try out latest clang.
> > > bpf_netdev.o 9721 8407
> > > bpf_overlay.o 6184 5420
> > > bpf_lcx_jit.o 39389 39389
> > >
> > > The final table is depressing:
> > > old clang old clang new clang new clang
> > > const spill/fill const spill/fill
> > > bpf_lb-DLB_L3.o 1838 6441 1923 8128
> > > bpf_lb-DLB_L4.o 3218 5908 3077 6707
> > > bpf_lb-DUNKNOWN.o 1064 1064 1062 1062
> > > bpf_lxc-DDROP_ALL.o 26935 93790 166729 380712
> > > bpf_lxc-DUNKNOWN.o 34439 123886 174607 440652
> > > bpf_netdev.o 9721 31413 8407 31904
> > > bpf_overlay.o 6184 18561 5420 23569
> > > bpf_lxc_jit.o 39389 359445 39389 359445
> > >
> > > Tracking constants in the registers hurts state pruning already.
> > > Adding tracking of constants through stack hurts pruning even more.
> > > The later patch address this general constant tracking issue
> > > with coarse/precise logic.
> > >
> > > Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> > > Acked-by: Andrii Nakryiko <andriin@fb.com>
> > > ---
> > > kernel/bpf/verifier.c | 90 +++++++++++++++++++++++++++++++------------
> > > 1 file changed, 65 insertions(+), 25 deletions(-)
> >
> > I know these are already in bpf-next sorry it took me awhile to get
> > time to review, but looks good to me. Thanks! We had something similar
> > in the earlier loop test branch from last year.
>
> It's not in bpf-next yet :)
oops was looking at the wrong branch on my side.
> Code reviews are appreciated at any time.
> Looks like we were just lucky with older clang.
> I haven't tracked which clang version became smarter.
> If you haven't seen this issue and haven't changed cilium C source
> to workaround that then there is chance you'll hit it as well.
> By "new clang" I meant version 9.0
I'll take a look at Cilium sources with version 9.0
> "old clang" is unknown. I just had cilium elf .o around that
> I kept using for testing without recompiling them.
> Just by chance I recompiled them to see annotated verifier line info
> messages with BTF and hit this interesting issue.
> See patch 9 backtracking logic that resolves this 'precision of scalar'
> issue for progs compiled with both new and old clangs.
>
working my way through the series now, but for this patch
Acked-by: John Fastabend <john.fastabend@gmail.com>
^ permalink raw reply
* Re: [PATCH][bpf] bpf: verifier: add break statement in switch
From: Alexei Starovoitov @ 2019-06-20 4:40 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song, Lawrence Brakmo, Andrii Nakryiko,
Network Development, bpf, LKML, Kees Cook
In-Reply-To: <20190619160207.GA26960@embeddedor>
On Wed, Jun 19, 2019 at 9:02 AM Gustavo A. R. Silva
<gustavo@embeddedor.com> wrote:
>
> Notice that in this case, it's much clearer to explicitly add a break
> rather than letting the code to fall through. It also avoid potential
> future fall-through warnings[1].
>
> This patch is part of the ongoing efforts to enable
> -Wimplicit-fallthrough.
>
> [1] https://lore.kernel.org/patchwork/patch/1087056/
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
this type of changes are not suitable for bpf tree.
Pls submit both as single patch to bpf-next
^ permalink raw reply
* Re: pull-request: bpf-next 2019-06-19
From: David Miller @ 2019-06-20 4:19 UTC (permalink / raw)
To: ast; +Cc: daniel, netdev, bpf, kernel-team
In-Reply-To: <20190620035726.3942971-1-ast@kernel.org>
From: Alexei Starovoitov <ast@kernel.org>
Date: Wed, 19 Jun 2019 20:57:26 -0700
> The following pull-request contains BPF updates for your *net-next* tree.
>
> The main changes are:
>
> 1) new SO_REUSEPORT_DETACH_BPF setsocktopt, from Martin.
>
> 2) BTF based map definition, from Andrii.
>
> 3) support bpf_map_lookup_elem for xskmap, from Jonathan.
>
> 4) bounded loops and scalar precision logic in the verifier, from Alexei.
>
> Please consider pulling these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH] net: fddi: skfp: remove generic PCI defines from skfbi.h
From: Puranjay Mohan @ 2019-06-20 4:17 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Shuah Khan, netdev, Linux Kernel Mailing List,
linux-kernel-mentees
In-Reply-To: <CAErSpo7-AjCAc8pGpTftd7U-W2kjp1jfbPzk3SOa=Bg5-d6W5w@mail.gmail.com>
On Wed, Jun 19, 2019 at 02:10:22PM -0500, Bjorn Helgaas wrote:
> On Wed, Jun 19, 2019 at 12:48 PM Puranjay Mohan <puranjay12@gmail.com> wrote:
> >
> > skfbi.h defines its own copies of PCI_COMMAND, PCI_STATUS, etc.
> > remove them in favor of the generic definitions in
> > include/uapi/linux/pci_regs.h
>
> 1) Since you're sending several related patches, send them as a
> "series" with a cover letter, e.g.,
>
> [PATCH v2 0/2] Use PCI generic definitions instead of private duplicates
> [PATCH v2 1/2] Include generic PCI definitions
> [PATCH v2 2/2] Remove unused private PCI definitions
>
> Patches 1/2 and 2/2 should be replies to the 0/2 cover letter. "git
> send-email" will do this for you if you figure out the right options.
>
> 2) Make sure all your subject lines match. One started with "Include"
> and the other with "remove". They should both be capitalized.
>
> 3) Start sentences with a capital letter, i.e., "Remove them" above.
>
> 4) This commit log needs to explicitly say that you're removing
> *unused* symbols. Since they're unused, you don't even need to refer
> to pci_regs.h.
>
> 5) "git grep PCI_ drivers/net/fddi/skfp" says there are many more
> unused PCI symbols than just the ones below. I would just remove them
> all at once.
>
> 6) Obviously you should compile this to make sure it builds. It must
> build cleanly after every patch, not just at the end. I assume you've
> done this already.
>
Yes, I build the driver after every change and I do it again before
sending the patch to be sure that it works.
> 7) Please cc: linux-pci@vger.kernel.org since you're making PCI-related changes.
>
sure.
> > Signed-off-by: Puranjay Mohan <puranjay12@gmail.com>
> > ---
> > drivers/net/fddi/skfp/h/skfbi.h | 23 -----------------------
> > 1 file changed, 23 deletions(-)
> >
> > diff --git a/drivers/net/fddi/skfp/h/skfbi.h b/drivers/net/fddi/skfp/h/skfbi.h
> > index 89557457b352..ed144a8e78d1 100644
> > --- a/drivers/net/fddi/skfp/h/skfbi.h
> > +++ b/drivers/net/fddi/skfp/h/skfbi.h
> > @@ -27,29 +27,6 @@
> > /*
> > * Configuration Space header
> > */
> > -#define PCI_VENDOR_ID 0x00 /* 16 bit Vendor ID */
> > -#define PCI_DEVICE_ID 0x02 /* 16 bit Device ID */
> > -#define PCI_COMMAND 0x04 /* 16 bit Command */
> > -#define PCI_STATUS 0x06 /* 16 bit Status */
> > -#define PCI_REV_ID 0x08 /* 8 bit Revision ID */
> > -#define PCI_CLASS_CODE 0x09 /* 24 bit Class Code */
> > -#define PCI_CACHE_LSZ 0x0c /* 8 bit Cache Line Size */
> > -#define PCI_LAT_TIM 0x0d /* 8 bit Latency Timer */
> > -#define PCI_HEADER_T 0x0e /* 8 bit Header Type */
> > -#define PCI_BIST 0x0f /* 8 bit Built-in selftest */
> > -#define PCI_BASE_1ST 0x10 /* 32 bit 1st Base address */
> > -#define PCI_BASE_2ND 0x14 /* 32 bit 2nd Base address */
> > -/* Byte 18..2b: Reserved */
> > -#define PCI_SUB_VID 0x2c /* 16 bit Subsystem Vendor ID */
> > -#define PCI_SUB_ID 0x2e /* 16 bit Subsystem ID */
> > -#define PCI_BASE_ROM 0x30 /* 32 bit Expansion ROM Base Address */
> > -/* Byte 34..33: Reserved */
> > -#define PCI_CAP_PTR 0x34 /* 8 bit (ML) Capabilities Ptr */
> > -/* Byte 35..3b: Reserved */
> > -#define PCI_IRQ_LINE 0x3c /* 8 bit Interrupt Line */
> > -#define PCI_IRQ_PIN 0x3d /* 8 bit Interrupt Pin */
> > -#define PCI_MIN_GNT 0x3e /* 8 bit Min_Gnt */
> > -#define PCI_MAX_LAT 0x3f /* 8 bit Max_Lat */
> > /* Device Dependent Region */
> > #define PCI_OUR_REG 0x40 /* 32 bit (DV) Our Register */
> > #define PCI_OUR_REG_1 0x40 /* 32 bit (ML) Our Register 1 */
> > --
> > 2.21.0
> >
Thanks for the feedback!
I will send the patch series soon.
Thanks
--Puranjay
^ permalink raw reply
* pull-request: bpf-next 2019-06-19
From: Alexei Starovoitov @ 2019-06-20 3:57 UTC (permalink / raw)
To: davem; +Cc: daniel, netdev, bpf, kernel-team
Hi David,
The following pull-request contains BPF updates for your *net-next* tree.
The main changes are:
1) new SO_REUSEPORT_DETACH_BPF setsocktopt, from Martin.
2) BTF based map definition, from Andrii.
3) support bpf_map_lookup_elem for xskmap, from Jonathan.
4) bounded loops and scalar precision logic in the verifier, from Alexei.
Please consider pulling these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
Thanks a lot!
----------------------------------------------------------------
The following changes since commit 0462eaacee493f7e2d87551a35d38be93ca723f8:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next (2019-05-31 21:21:18 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
for you to fetch changes up to 94079b64255fe40b9b53fd2e4081f68b9b14f54a:
Merge branch 'bpf-bounded-loops' (2019-06-19 02:22:53 +0200)
----------------------------------------------------------------
Alexei Starovoitov (10):
Merge branch 'xskmap-lookup'
bpf: track spill/fill of constants
selftests/bpf: fix tests due to const spill/fill
bpf: extend is_branch_taken to registers
bpf: introduce bounded loops
bpf: fix callees pruning callers
selftests/bpf: fix tests
selftests/bpf: add basic verifier tests for loops
selftests/bpf: add realistic loop tests
bpf: precise scalar_value tracking
Andrii Nakryiko (13):
selftests/bpf: fix constness of source arg for bpf helpers
libbpf: fix check for presence of associated BTF for map creation
libbpf: add common min/max macro to libbpf_internal.h
libbpf: extract BTF loading logic
libbpf: streamline ELF parsing error-handling
libbpf: refactor map initialization
libbpf: identify maps by section index in addition to offset
libbpf: split initialization and loading of BTF
libbpf: allow specifying map definitions using BTF
selftests/bpf: add test for BTF-defined maps
selftests/bpf: switch BPF_ANNOTATE_KV_PAIR tests to BTF-defined maps
selftests/bpf: convert tests w/ custom values to BTF-defined maps
libbpf: constify getter APIs
Colin Ian King (2):
bpf: hbm: fix spelling mistake "notifcations" -> "notificiations"
bpf: remove redundant assignment to err
Dan Carpenter (1):
selftests/bpf: signedness bug in enable_all_controllers()
Daniel Borkmann (3):
Merge branch 'bpf-libbpf-num-cpus'
Merge branch 'bpf-libbpf-btf-defined-maps'
Merge branch 'bpf-bounded-loops'
Daniel T. Lee (2):
samples: bpf: remove unnecessary include options in Makefile
samples: bpf: refactor header include path
Hechao Li (4):
selftests/bpf : clean up feature/ when make clean
bpf: add a new API libbpf_num_possible_cpus()
selftests/bpf: remove bpf_util.h from BPF C progs
bpf: use libbpf_num_possible_cpus internally
Jakub Kicinski (2):
samples: bpf: print a warning about headers_install
samples: bpf: don't run probes at the local make stage
Jonathan Lemon (4):
bpf: Allow bpf_map_lookup_elem() on an xskmap
bpf/tools: sync bpf.h
tools/bpf: Add bpf_map_lookup_elem selftest for xskmap
libbpf: remove qidconf and better support external bpf programs.
Martin KaFai Lau (3):
bpf: net: Add SO_DETACH_REUSEPORT_BPF
bpf: Sync asm-generic/socket.h to tools/
bpf: Add test for SO_REUSEPORT_DETACH_BPF
Prashant Bhole (1):
samples/bpf: fix include path in Makefile
Roman Gushchin (1):
bpf: allow CGROUP_SKB programs to use bpf_skb_cgroup_id() helper
Stanislav Fomichev (4):
bpf: export bpf_sock for BPF_PROG_TYPE_CGROUP_SOCK_ADDR prog type
bpf: export bpf_sock for BPF_PROG_TYPE_SOCK_OPS prog type
bpf/tools: sync bpf.h
selftests/bpf: convert socket_cookie test to sk storage
Valdis Kletnieks (1):
bpf: silence warning messages in core
YueHaibing (1):
bpf: Fix build error without CONFIG_INET
arch/alpha/include/uapi/asm/socket.h | 2 +
arch/mips/include/uapi/asm/socket.h | 2 +
arch/parisc/include/uapi/asm/socket.h | 2 +
arch/sparc/include/uapi/asm/socket.h | 2 +
include/linux/bpf.h | 25 +
include/linux/bpf_verifier.h | 69 +-
include/net/sock_reuseport.h | 2 +
include/net/xdp_sock.h | 4 +-
include/uapi/asm-generic/socket.h | 2 +
include/uapi/linux/bpf.h | 6 +
kernel/bpf/Makefile | 1 +
kernel/bpf/devmap.c | 2 +-
kernel/bpf/verifier.c | 793 ++++++++++++++++--
kernel/bpf/xskmap.c | 9 +-
net/core/filter.c | 86 ++
net/core/sock.c | 4 +
net/core/sock_reuseport.c | 24 +
samples/bpf/Makefile | 23 +-
samples/bpf/fds_example.c | 2 +-
samples/bpf/hbm.c | 6 +-
samples/bpf/ibumad_user.c | 2 +-
samples/bpf/sockex1_user.c | 2 +-
samples/bpf/sockex2_user.c | 2 +-
samples/bpf/xdp1_user.c | 4 +-
samples/bpf/xdp_adjust_tail_user.c | 4 +-
samples/bpf/xdp_fwd_user.c | 2 +-
samples/bpf/xdp_redirect_cpu_user.c | 2 +-
samples/bpf/xdp_redirect_map_user.c | 2 +-
samples/bpf/xdp_redirect_user.c | 2 +-
samples/bpf/xdp_router_ipv4_user.c | 2 +-
samples/bpf/xdp_rxq_info_user.c | 4 +-
samples/bpf/xdp_tx_iptunnel_user.c | 2 +-
samples/bpf/xdpsock_user.c | 4 +-
tools/bpf/bpftool/common.c | 53 +-
tools/include/uapi/asm-generic/socket.h | 147 ++++
tools/include/uapi/linux/bpf.h | 6 +
tools/lib/bpf/bpf.c | 7 +-
tools/lib/bpf/bpf_prog_linfo.c | 5 +-
tools/lib/bpf/btf.c | 3 -
tools/lib/bpf/btf.h | 1 +
tools/lib/bpf/btf_dump.c | 3 -
tools/lib/bpf/libbpf.c | 927 +++++++++++++++------
tools/lib/bpf/libbpf.h | 78 +-
tools/lib/bpf/libbpf.map | 1 +
tools/lib/bpf/libbpf_internal.h | 7 +
tools/lib/bpf/xsk.c | 103 +--
tools/testing/selftests/bpf/Makefile | 3 +-
tools/testing/selftests/bpf/bpf_endian.h | 1 +
tools/testing/selftests/bpf/bpf_helpers.h | 4 +-
tools/testing/selftests/bpf/bpf_util.h | 37 +-
tools/testing/selftests/bpf/cgroup_helpers.c | 2 +-
.../selftests/bpf/prog_tests/bpf_verif_scale.c | 67 +-
tools/testing/selftests/bpf/progs/bpf_flow.c | 18 +-
tools/testing/selftests/bpf/progs/loop1.c | 28 +
tools/testing/selftests/bpf/progs/loop2.c | 28 +
tools/testing/selftests/bpf/progs/loop3.c | 22 +
tools/testing/selftests/bpf/progs/netcnt_prog.c | 22 +-
tools/testing/selftests/bpf/progs/pyperf.h | 6 +-
tools/testing/selftests/bpf/progs/pyperf600.c | 9 +
.../selftests/bpf/progs/pyperf600_nounroll.c | 8 +
.../selftests/bpf/progs/socket_cookie_prog.c | 49 +-
.../selftests/bpf/progs/sockmap_parse_prog.c | 1 -
.../selftests/bpf/progs/sockmap_tcp_msg_prog.c | 2 +-
.../selftests/bpf/progs/sockmap_verdict_prog.c | 1 -
tools/testing/selftests/bpf/progs/strobemeta.c | 10 +
tools/testing/selftests/bpf/progs/strobemeta.h | 528 ++++++++++++
.../selftests/bpf/progs/strobemeta_nounroll1.c | 9 +
.../selftests/bpf/progs/strobemeta_nounroll2.c | 9 +
tools/testing/selftests/bpf/progs/test_btf_newkv.c | 73 ++
.../selftests/bpf/progs/test_get_stack_rawtp.c | 27 +-
.../testing/selftests/bpf/progs/test_global_data.c | 27 +-
tools/testing/selftests/bpf/progs/test_l4lb.c | 45 +-
.../selftests/bpf/progs/test_l4lb_noinline.c | 45 +-
tools/testing/selftests/bpf/progs/test_map_lock.c | 22 +-
tools/testing/selftests/bpf/progs/test_seg6_loop.c | 261 ++++++
.../bpf/progs/test_select_reuseport_kern.c | 45 +-
.../selftests/bpf/progs/test_send_signal_kern.c | 22 +-
.../selftests/bpf/progs/test_sock_fields_kern.c | 60 +-
tools/testing/selftests/bpf/progs/test_spin_lock.c | 33 +-
.../selftests/bpf/progs/test_stacktrace_build_id.c | 44 +-
.../selftests/bpf/progs/test_stacktrace_map.c | 40 +-
.../selftests/bpf/progs/test_sysctl_loop1.c | 71 ++
.../selftests/bpf/progs/test_sysctl_loop2.c | 72 ++
.../testing/selftests/bpf/progs/test_sysctl_prog.c | 5 +-
.../testing/selftests/bpf/progs/test_tcp_estats.c | 9 +-
.../testing/selftests/bpf/progs/test_tcpbpf_kern.c | 18 +-
.../selftests/bpf/progs/test_tcpnotify_kern.c | 18 +-
tools/testing/selftests/bpf/progs/test_xdp.c | 18 +-
tools/testing/selftests/bpf/progs/test_xdp_loop.c | 231 +++++
.../selftests/bpf/progs/test_xdp_noinline.c | 60 +-
tools/testing/selftests/bpf/test_btf.c | 10 +-
.../testing/selftests/bpf/test_select_reuseport.c | 54 ++
tools/testing/selftests/bpf/test_socket_cookie.c | 24 +-
tools/testing/selftests/bpf/test_verifier.c | 11 +-
tools/testing/selftests/bpf/verifier/calls.c | 22 +-
tools/testing/selftests/bpf/verifier/cfg.c | 11 +-
.../selftests/bpf/verifier/direct_packet_access.c | 3 +-
.../selftests/bpf/verifier/helper_access_var_len.c | 28 +-
tools/testing/selftests/bpf/verifier/loops1.c | 161 ++++
.../selftests/bpf/verifier/prevent_map_lookup.c | 15 -
tools/testing/selftests/bpf/verifier/sock.c | 18 +
101 files changed, 4048 insertions(+), 860 deletions(-)
create mode 100644 tools/include/uapi/asm-generic/socket.h
create mode 100644 tools/testing/selftests/bpf/progs/loop1.c
create mode 100644 tools/testing/selftests/bpf/progs/loop2.c
create mode 100644 tools/testing/selftests/bpf/progs/loop3.c
create mode 100644 tools/testing/selftests/bpf/progs/pyperf600.c
create mode 100644 tools/testing/selftests/bpf/progs/pyperf600_nounroll.c
create mode 100644 tools/testing/selftests/bpf/progs/strobemeta.c
create mode 100644 tools/testing/selftests/bpf/progs/strobemeta.h
create mode 100644 tools/testing/selftests/bpf/progs/strobemeta_nounroll1.c
create mode 100644 tools/testing/selftests/bpf/progs/strobemeta_nounroll2.c
create mode 100644 tools/testing/selftests/bpf/progs/test_btf_newkv.c
create mode 100644 tools/testing/selftests/bpf/progs/test_seg6_loop.c
create mode 100644 tools/testing/selftests/bpf/progs/test_sysctl_loop1.c
create mode 100644 tools/testing/selftests/bpf/progs/test_sysctl_loop2.c
create mode 100644 tools/testing/selftests/bpf/progs/test_xdp_loop.c
create mode 100644 tools/testing/selftests/bpf/verifier/loops1.c
^ permalink raw reply
* Re: [PATCH v2] perf cs-etm: Improve completeness for kernel address space
From: Leo Yan @ 2019-06-20 3:51 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Alexander Shishkin, Jiri Olsa,
Namhyung Kim, Mathieu Poirier, Suzuki K Poulose,
Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song, linux-kernel, linux-arm-kernel, netdev, bpf
Cc: Peter Zijlstra, coresight
In-Reply-To: <20190620005428.20883-1-leo.yan@linaro.org>
Hi all,
On Thu, Jun 20, 2019 at 08:54:28AM +0800, Leo Yan wrote:
[...]
> diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
> index 51dd00f65709..cf5906d667aa 100644
> --- a/tools/perf/Makefile.config
> +++ b/tools/perf/Makefile.config
> @@ -418,6 +418,26 @@ ifdef CORESIGHT
> endif
> LDFLAGS += $(LIBOPENCSD_LDFLAGS)
> EXTLIBS += $(OPENCSDLIBS)
> + ARM_PRE_START_SIZE := 0
> + ifeq ($(SRCARCH),arm64)
> + # Extract info from lds:
> + # . = ((((((((0xffffffffffffffff)) - (((1)) << (48)) + 1) + (0)) + (0x08000000))) + (0x08000000))) + 0x00080000;
> + # ARM_PRE_START_SIZE := (0x08000000 + 0x08000000 + 0x00080000)
> + ARM_PRE_START_SIZE := $(shell egrep ' \. \= \({8}0x[0-9a-fA-F]+\){2}' \
> + $(srctree)/arch/arm64/kernel/vmlinux.lds | \
> + sed -e 's/[(|)|.|=|+|<|;|-]//g' -e 's/ \+/ /g' -e 's/^[ \t]*//' | \
> + awk -F' ' '{print "("$$6 "+" $$7 "+" $$8")"}' 2>/dev/null)
> + endif
> + ifeq ($(SRCARCH),arm)
> + # Extract info from lds:
> + # . = ((0xC0000000)) + 0x00208000;
> + # ARM_PRE_START_SIZE := 0x00208000
> + ARM_PRE_START_SIZE := $(shell egrep ' \. \= \({2}0x[0-9a-fA-F]+\){2}' \
> + $(srctree)/arch/arm/kernel/vmlinux.lds | \
> + sed -e 's/[(|)|.|=|+|<|;|-]//g' -e 's/ \+/ /g' -e 's/^[ \t]*//' | \
> + awk -F' ' '{print "("$$2")"}' 2>/dev/null)
> + endif
> + CFLAGS += -DARM_PRE_START_SIZE="$(ARM_PRE_START_SIZE)"
I did testing for building perf with this patch, this patch is fragile
and easily introduce the building warning:
<command-line>: error: "ARM_PRE_START_SIZE" redefined [-Werror]
<command-line>: note: this is the location of the previous definition
To dismiss this error, I need to change the macro define as below:
+ CFLAGS += -DARM_PRE_START_SIZE=$(ARM_PRE_START_SIZE)
So I sent patch v3 to address this issue and please directly reivew
patch v3. Sorry for spamming.
Thanks,
Leo Yan
> $(call detected,CONFIG_LIBOPENCSD)
> ifdef CSTRACE_RAW
> CFLAGS += -DCS_DEBUG_RAW
> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> index 0c7776b51045..5fa0be3a3904 100644
> --- a/tools/perf/util/cs-etm.c
> +++ b/tools/perf/util/cs-etm.c
> @@ -613,10 +613,27 @@ static void cs_etm__free(struct perf_session *session)
> static u8 cs_etm__cpu_mode(struct cs_etm_queue *etmq, u64 address)
> {
> struct machine *machine;
> + u64 fixup_kernel_start = 0;
>
> machine = etmq->etm->machine;
>
> - if (address >= etmq->etm->kernel_start) {
> + /*
> + * Since arm and arm64 specify some memory regions prior to
> + * 'kernel_start', kernel addresses can be less than 'kernel_start'.
> + *
> + * For arm architecture, the 16MB virtual memory space prior to
> + * 'kernel_start' is allocated to device modules, a PMD table if
> + * CONFIG_HIGHMEM is enabled and a PGD table.
> + *
> + * For arm64 architecture, the root PGD table, device module memory
> + * region and BPF jit region are prior to 'kernel_start'.
> + *
> + * To reflect the complete kernel address space, compensate these
> + * pre-defined regions for kernel start address.
> + */
> + fixup_kernel_start = etmq->etm->kernel_start - ARM_PRE_START_SIZE;
> +
> + if (address >= fixup_kernel_start) {
> if (machine__is_host(machine))
> return PERF_RECORD_MISC_KERNEL;
> else
> --
> 2.17.1
>
^ permalink raw reply
* [PATCH v3] perf cs-etm: Improve completeness for kernel address space
From: Leo Yan @ 2019-06-20 3:44 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Alexander Shishkin, Jiri Olsa,
Namhyung Kim, Mathieu Poirier, Suzuki K Poulose,
Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song, linux-kernel, linux-arm-kernel, netdev, bpf
Cc: Leo Yan, Peter Zijlstra, coresight
Arm and arm64 architecture reserve some memory regions prior to the
symbol '_stext' and these memory regions later will be used by device
module and BPF jit. The current code misses to consider these memory
regions thus any address in the regions will be taken as user space
mode, but perf cannot find the corresponding dso with the wrong CPU
mode so we misses to generate samples for device module and BPF
related trace data.
This patch parse the link scripts to get the memory size prior to start
address and reduce this size from 'etmq->etm->kernel_start', then can
get a fixed up kernel start address which contain memory regions for
device module and BPF. Finally, cs_etm__cpu_mode() can return right
mode for these memory regions and perf can successfully generate
samples.
The reason for parsing the link scripts is Arm architecture changes text
offset dependent on different platforms, which define multiple text
offsets in $kernel/arch/arm/Makefile. This offset is decided when build
kernel and the final value is extended in the link script, so we can
extract the used value from the link script. We use the same way to
parse arm64 link script as well. If fail to find the link script, the
pre start memory size is assumed as zero, in this case it has no any
change caused with this patch.
Below is detailed info for testing this patch:
- Build LLVM/Clang 8.0 or later version;
- Configure perf with ~/.perfconfig:
root@debian:~# cat ~/.perfconfig
# this file is auto-generated.
[llvm]
clang-path = /mnt/build/llvm-build/build/install/bin/clang
kbuild-dir = /mnt/linux-kernel/linux-cs-dev/
clang-opt = "-g"
dump-obj = true
[trace]
show_zeros = yes
show_duration = no
no_inherit = yes
show_timestamp = no
show_arg_names = no
args_alignment = 40
show_prefix = yes
- Run 'perf trace' command with eBPF event:
root@debian:~# perf trace -e string \
-e $kernel/tools/perf/examples/bpf/augmented_raw_syscalls.c
- Read eBPF program memory mapping in kernel:
root@debian:~# echo 1 > /proc/sys/net/core/bpf_jit_kallsyms
root@debian:~# cat /proc/kallsyms | grep -E "bpf_prog_.+_sys_[enter|exit]"
ffff000000086a84 t bpf_prog_f173133dc38ccf87_sys_enter [bpf]
ffff000000088618 t bpf_prog_c1bd85c092d6e4aa_sys_exit [bpf]
- Launch any program which accesses file system frequently so can hit
the system calls trace flow with eBPF event;
- Capture CoreSight trace data with filtering eBPF program:
root@debian:~# perf record -e cs_etm/@20070000.etr/ \
--filter 'filter 0xffff000000086a84/0x800' -a sleep 5s
- Annotate for symbol 'bpf_prog_f173133dc38ccf87_sys_enter':
root@debian:~# perf report
Then select 'branches' samples and press 'a' to annotate symbol
'bpf_prog_f173133dc38ccf87_sys_enter', press 'P' to print to the
bpf_prog_f173133dc38ccf87_sys_enter.annotation file:
root@debian:~# cat bpf_prog_f173133dc38ccf87_sys_enter.annotation
bpf_prog_f173133dc38ccf87_sys_enter() bpf_prog_f173133dc38ccf87_sys_enter
Event: branches
Percent int sys_enter(struct syscall_enter_args *args)
stp x29, x30, [sp, #-16]!
int key = 0;
mov x29, sp
augmented_args = bpf_map_lookup_elem(&augmented_filename_map, &key);
stp x19, x20, [sp, #-16]!
augmented_args = bpf_map_lookup_elem(&augmented_filename_map, &key);
stp x21, x22, [sp, #-16]!
stp x25, x26, [sp, #-16]!
return bpf_get_current_pid_tgid();
mov x25, sp
return bpf_get_current_pid_tgid();
mov x26, #0x0 // #0
sub sp, sp, #0x10
return bpf_map_lookup_elem(pids, &pid) != NULL;
add x19, x0, #0x0
mov x0, #0x0 // #0
mov x10, #0xfffffffffffffff8 // #-8
if (pid_filter__has(&pids_filtered, getpid()))
str w0, [x25, x10]
probe_read(&augmented_args->args, sizeof(augmented_args->args), args);
add x1, x25, #0x0
probe_read(&augmented_args->args, sizeof(augmented_args->args), args);
mov x10, #0xfffffffffffffff8 // #-8
syscall = bpf_map_lookup_elem(&syscalls, &augmented_args->args.syscall_nr);
add x1, x1, x10
syscall = bpf_map_lookup_elem(&syscalls, &augmented_args->args.syscall_nr);
mov x0, #0xffff8009ffffffff // #-140694538682369
movk x0, #0x6698, lsl #16
movk x0, #0x3e00
mov x10, #0xffffffffffff1040 // #-61376
if (syscall == NULL || !syscall->enabled)
movk x10, #0x1023, lsl #16
if (syscall == NULL || !syscall->enabled)
movk x10, #0x0, lsl #32
loop_iter_first()
3.69 → blr bpf_prog_f173133dc38ccf87_sys_enter
loop_iter_first()
add x7, x0, #0x0
loop_iter_first()
add x20, x7, #0x0
int size = probe_read_str(&augmented_filename->value, filename_len, filename_arg);
mov x0, #0x1 // #1
[...]
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
Cc: coresight@lists.linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
tools/perf/Makefile.config | 22 ++++++++++++++++++++++
tools/perf/util/cs-etm.c | 19 ++++++++++++++++++-
2 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index 51dd00f65709..a58cd5a43a98 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -418,6 +418,28 @@ ifdef CORESIGHT
endif
LDFLAGS += $(LIBOPENCSD_LDFLAGS)
EXTLIBS += $(OPENCSDLIBS)
+ PRE_START_SIZE := 0
+ ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/kernel/vmlinux.lds),)
+ ifeq ($(SRCARCH),arm64)
+ # Extract info from lds:
+ # . = ((((((((0xffffffffffffffff)) - (((1)) << (48)) + 1) + (0)) + (0x08000000))) + (0x08000000))) + 0x00080000;
+ # PRE_START_SIZE := (0x08000000 + 0x08000000 + 0x00080000) = 0x10080000
+ PRE_START_SIZE := $(shell egrep ' \. \= \({8}0x[0-9a-fA-F]+\){2}' \
+ $(srctree)/arch/$(SRCARCH)/kernel/vmlinux.lds | \
+ sed -e 's/[(|)|.|=|+|<|;|-]//g' -e 's/ \+/ /g' -e 's/^[ \t]*//' | \
+ awk -F' ' '{printf "0x%x", $$6+$$7+$$8}' 2>/dev/null)
+ endif
+ ifeq ($(SRCARCH),arm)
+ # Extract info from lds:
+ # . = ((0xC0000000)) + 0x00208000;
+ # PRE_START_SIZE := 0x00208000
+ PRE_START_SIZE := $(shell egrep ' \. \= \({2}0x[0-9a-fA-F]+\){2}' \
+ $(srctree)/arch/$(SRCARCH)/kernel/vmlinux.lds | \
+ sed -e 's/[(|)|.|=|+|<|;|-]//g' -e 's/ \+/ /g' -e 's/^[ \t]*//' | \
+ awk -F' ' '{printf "0x%x", $$2}' 2>/dev/null)
+ endif
+ endif
+ CFLAGS += -DARM_PRE_START_SIZE=$(PRE_START_SIZE)
$(call detected,CONFIG_LIBOPENCSD)
ifdef CSTRACE_RAW
CFLAGS += -DCS_DEBUG_RAW
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 0c7776b51045..5fa0be3a3904 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -613,10 +613,27 @@ static void cs_etm__free(struct perf_session *session)
static u8 cs_etm__cpu_mode(struct cs_etm_queue *etmq, u64 address)
{
struct machine *machine;
+ u64 fixup_kernel_start = 0;
machine = etmq->etm->machine;
- if (address >= etmq->etm->kernel_start) {
+ /*
+ * Since arm and arm64 specify some memory regions prior to
+ * 'kernel_start', kernel addresses can be less than 'kernel_start'.
+ *
+ * For arm architecture, the 16MB virtual memory space prior to
+ * 'kernel_start' is allocated to device modules, a PMD table if
+ * CONFIG_HIGHMEM is enabled and a PGD table.
+ *
+ * For arm64 architecture, the root PGD table, device module memory
+ * region and BPF jit region are prior to 'kernel_start'.
+ *
+ * To reflect the complete kernel address space, compensate these
+ * pre-defined regions for kernel start address.
+ */
+ fixup_kernel_start = etmq->etm->kernel_start - ARM_PRE_START_SIZE;
+
+ if (address >= fixup_kernel_start) {
if (machine__is_host(machine))
return PERF_RECORD_MISC_KERNEL;
else
--
2.17.1
^ permalink raw reply related
* RE: [RFC net-next 1/5] net: stmmac: introduce IEEE 802.1Qbv configuration functionalities
From: Ong, Boon Leong @ 2019-06-20 3:37 UTC (permalink / raw)
To: Gomes, Vinicius, Voon, Weifeng, David S. Miller, Maxime Coquelin
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Jose Abreu,
Giuseppe Cavallaro, Andrew Lunn, Florian Fainelli,
Alexandre Torgue, Voon, Weifeng
In-Reply-To: <874l4lsaue.fsf@intel.com>
>-----Original Message-----
>From: Gomes, Vinicius
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dw_tsn_lib.c
>> @@ -0,0 +1,790 @@
>> +
>> +static struct tsn_hw_cap dw_tsn_hwcap;
>> +static bool dw_tsn_feat_en[TSN_FEAT_ID_MAX];
>> +static unsigned int dw_tsn_hwtunable[TSN_HWTUNA_MAX];
>> +static struct est_gc_config dw_est_gc_config;
>
>If it's at all possible to have more than one of these devices in a
>system, this should be moved to a per-device structure. That
>mac_device_info struct perhaps?
I do see value in scaling the code to more than one device there.
Thanks.
>> +void dwmac_tsn_init(void *ioaddr)
>
>Perhaps this should return an error if TSN is not supported. It may help
>simplify the initialization below.
Thanks for the input. It may not be apparent because this code does not
include Qbu detection yet. The thinking here is to avoid caller function
not need to handle and IP configuration difference, i.e. SoC-1 may have only
Qbv and SoC-2 have both.
>
>> +{
>> + unsigned int hwid = TSN_RD32(ioaddr + GMAC4_VERSION) &
>TSN_VER_MASK;
>> + unsigned int hw_cap2 = TSN_RD32(ioaddr + GMAC_HW_FEATURE2);
>> + unsigned int hw_cap3 = TSN_RD32(ioaddr + GMAC_HW_FEATURE3);
>> + struct tsn_hw_cap *cap = &dw_tsn_hwcap;
>> + unsigned int gcl_depth;
>> + unsigned int tils_max;
>> + unsigned int ti_wid;
>> +
>> + memset(cap, 0, sizeof(*cap));
>> +
>> + if (hwid < TSN_CORE_VER) {
>> + TSN_WARN_NA("IP v5.00 does not support TSN\n");
Perhaps, we just print info here instead of warning because SoC with EQoS v5
can be built without Qbv.
>> + return;
>> + }
>> +
>> + if (!(hw_cap3 & GMAC_HW_FEAT_ESTSEL)) {
>> + TSN_WARN_NA("EST NOT supported\n");
>> + cap->est_support = 0;
Same here.
>> +
>> + return;
>> + }
>> +
>> + gcl_depth = est_get_gcl_depth(hw_cap3);
>> + ti_wid = est_get_ti_width(hw_cap3);
>> +
>> + cap->ti_wid = ti_wid;
>> + cap->gcl_depth = gcl_depth;
>> +
>> + tils_max = (hw_cap3 & GMAC_HW_FEAT_ESTSEL ? 3 : 0);
>> + tils_max = (1 << tils_max) - 1;
>> + cap->tils_max = tils_max;
>> +
>> + cap->ext_max = EST_TIWID_TO_EXTMAX(ti_wid);
>> + cap->txqcnt = ((hw_cap2 & GMAC_HW_FEAT_TXQCNT) >> 6) + 1;
>> + cap->est_support = 1;
>> +
>> + TSN_INFO("EST: depth=%u, ti_wid=%u, tils_max=%u tqcnt=%u\n",
>> + gcl_depth, ti_wid, tils_max, cap->txqcnt);
>> +}
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h
>b/drivers/net/ethernet/stmicro/stmmac/hwif.h
>> index 2acfbc70e3c8..518a72805185 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
>> +++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
>> @@ -7,6 +7,7 @@
>>
>> #include <linux/netdevice.h>
>> #include <linux/stmmac.h>
>> +#include "dw_tsn_lib.h"
>>
>> #define stmmac_do_void_callback(__priv, __module, __cname, __arg0,
>__args...) \
>> ({ \
>> @@ -311,6 +312,31 @@ struct stmmac_ops {
>> bool loopback);
>> void (*pcs_rane)(void __iomem *ioaddr, bool restart);
>> void (*pcs_get_adv_lp)(void __iomem *ioaddr, struct rgmii_adv *adv);
>> + /* TSN functions */
>> + void (*tsn_init)(void __iomem *ioaddr);
>> + void (*get_tsn_hwcap)(struct tsn_hw_cap **tsn_hwcap);
>> + void (*set_est_gcb)(struct est_gc_entry *gcl,
>> + u32 bank);
>> + void (*set_tsn_feat)(enum tsn_feat_id featid, bool enable);
>> + int (*set_tsn_hwtunable)(void __iomem *ioaddr,
>> + enum tsn_hwtunable_id id,
>> + const unsigned int *data);
>> + int (*get_tsn_hwtunable)(enum tsn_hwtunable_id id,
>> + unsigned int *data);
>> + int (*get_est_bank)(void __iomem *ioaddr, u32 own);
>> + int (*set_est_gce)(void __iomem *ioaddr,
>> + struct est_gc_entry *gce, u32 row,
>> + u32 dbgb, u32 dbgm);
>> + int (*get_est_gcrr_llr)(void __iomem *ioaddr, u32 *gcl_len,
>> + u32 dbgb, u32 dbgm);
>> + int (*set_est_gcrr_llr)(void __iomem *ioaddr, u32 gcl_len,
>> + u32 dbgb, u32 dbgm);
>> + int (*set_est_gcrr_times)(void __iomem *ioaddr,
>> + struct est_gcrr *gcrr,
>> + u32 dbgb, u32 dbgm);
>> + int (*set_est_enable)(void __iomem *ioaddr, bool enable);
>> + int (*get_est_gcc)(void __iomem *ioaddr,
>> + struct est_gc_config **gcc, bool frmdrv);
>
>These functions do not seem to be consistent with the rest of the
>stmmac_ops: most of the operations already there receive an
>mac_device_info as first argument, which seem much less error prone than
>a void* ioaddr.
Thanks for the input. We will look into this together with mac_device_info
and adjust accordingly.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox