* Re: [PATCH net-next 2/2] r8169: remove duplicated RTL8169s PHY initialization steps
From: David Miller @ 2018-09-20 6:06 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <b9bb7396-b2e5-6df5-cb0f-6cee29860491@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Wed, 19 Sep 2018 22:02:11 +0200
> Setting register 0x82 to value 01 is done a few lines before for all
> chip versions <= 06 anyway. And setting PHY register 0x0b to value 00
> is done at the end of rtl8169s_hw_phy_config() already. So we can
> remove this.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/2] r8169: simplify RTL8169 PHY initialization
From: David Miller @ 2018-09-20 6:06 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <35548e5c-2421-04b6-b6d7-335c1b7fb62d@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Wed, 19 Sep 2018 22:00:24 +0200
> PCI_LATENCY_TIMER is ignored on PCIe, therefore we have to do this
> for the PCI chips (version <= 06) only. Also we can move setting
> PCI_CACHE_LINE_SIZE.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] mpls: allow routes on ip6gre devices
From: David Miller @ 2018-09-20 6:05 UTC (permalink / raw)
To: saifhhasan; +Cc: netdev, calvinowens, has
In-Reply-To: <CAKqLStYErR+mk7n1i9vZAJ6Du_VSsyu7mQ2XiSsdzFJCryPm0g@mail.gmail.com>
From: Saif Hasan <saifhhasan@gmail.com>
Date: Wed, 19 Sep 2018 12:59:24 -0700
> @@ -1533,10 +1533,11 @@ static int mpls_dev_notify(struct
> notifier_block *this, unsigned long event,
> unsigned int flags;
>
> if (event == NETDEV_REGISTER) {
> - /* For now just support Ethernet, IPGRE, SIT and IPIP devices */
> + /* For now just support Ethernet, IPGRE, IP6GRE, SIT and IPIP devices */
> if (dev->type == ARPHRD_ETHER ||
Your email client has corrupted this patch, please fix.
^ permalink raw reply
* Re: [PATCH] net: toshiba: remove a redundant local variable 'index_specified'
From: zhong jiang @ 2018-09-20 11:34 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: davem, benh, paulus, mpe, netdev, linux-kernel
In-Reply-To: <17fba403-b5be-a406-bb25-4a0c2c4f27ca@cogentembedded.com>
On 2018/9/20 18:23, Sergei Shtylyov wrote:
> On 9/20/2018 4:56 AM, zhong jiang wrote:
>
>> The local variable 'index_specified' is never used after being assigned.
>> hence it should be redundant adn can be removed.
>
> s/adn/and/.
>
Spelling mistake. Thanks, checkpatch.pl can not find this. :-[ . I will be appreaciated
that David help me correct that.
Sincerely,
zhong jiang
>> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
> [...]
>
> MBR, Sergei
>
>
>
^ permalink raw reply
* Re: [PATCH bpf-next 2/3] bpf: emit RECORD_MMAP events for bpf prog load/unload
From: Song Liu @ 2018-09-20 5:48 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Alexei Starovoitov, David S . Miller, daniel@iogearbox.net,
peterz@infradead.org, acme@kernel.org, netdev@vger.kernel.org,
Kernel Team
In-Reply-To: <bb8f3eaf-df68-3861-a6a3-9f9a49cab877@fb.com>
> On Sep 19, 2018, at 5:59 PM, Alexei Starovoitov <ast@fb.com> wrote:
>
> On 9/19/18 4:44 PM, Song Liu wrote:
>>
>>
>>> On Sep 19, 2018, at 3:39 PM, Alexei Starovoitov <ast@kernel.org> wrote:
>>>
>>> use perf_event_mmap_bpf_prog() helper to notify user space
>>> about JITed bpf programs.
>>> Use RECORD_MMAP perf event to tell user space where JITed bpf program was loaded.
>>> Use empty program name as unload indication.
>>>
>>> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
>>> ---
>>> kernel/bpf/core.c | 22 ++++++++++++++++++++--
>>> 1 file changed, 20 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
>>> index 3f5bf1af0826..ddf11fdafd36 100644
>>> --- a/kernel/bpf/core.c
>>> +++ b/kernel/bpf/core.c
>>> @@ -384,7 +384,7 @@ bpf_get_prog_addr_region(const struct bpf_prog *prog,
>>> *symbol_end = addr + hdr->pages * PAGE_SIZE;
>>> }
>>>
>>> -static void bpf_get_prog_name(const struct bpf_prog *prog, char *sym)
>>> +static char *bpf_get_prog_name(const struct bpf_prog *prog, char *sym)
>>> {
>>> const char *end = sym + KSYM_NAME_LEN;
>>>
>>> @@ -402,9 +402,10 @@ static void bpf_get_prog_name(const struct bpf_prog *prog, char *sym)
>>> sym += snprintf(sym, KSYM_NAME_LEN, "bpf_prog_");
>>> sym = bin2hex(sym, prog->tag, sizeof(prog->tag));
>>> if (prog->aux->name[0])
>>> - snprintf(sym, (size_t)(end - sym), "_%s", prog->aux->name);
>>> + sym += snprintf(sym, (size_t)(end - sym), "_%s", prog->aux->name);
>>> else
>>> *sym = 0;
>>> + return sym;
>>> }
>>>
>>> static __always_inline unsigned long
>>> @@ -480,23 +481,40 @@ static bool bpf_prog_kallsyms_verify_off(const struct bpf_prog *fp)
>>>
>>> void bpf_prog_kallsyms_add(struct bpf_prog *fp)
>>> {
>>> + unsigned long symbol_start, symbol_end;
>>> + char buf[KSYM_NAME_LEN], *sym;
>>> +
>>> if (!bpf_prog_kallsyms_candidate(fp) ||
>>> !capable(CAP_SYS_ADMIN))
>>> return;
>>>
>>> + bpf_get_prog_addr_region(fp, &symbol_start, &symbol_end);
>>> + sym = bpf_get_prog_name(fp, buf);
>>> + sym++; /* sym - buf is the length of the name including trailing 0 */
>>> + while (!IS_ALIGNED(sym - buf, sizeof(u64)))
>>> + *sym++ = 0;
>>
>> nit: This logic feels a little weird to me. How about we wrap the extra logic
>> in a separate function:
>>
>> size_t bpf_get_prog_name_u64_aligned(const struct bpf_prog fp, char *buf)
>
> probably bpf_get_prog_name_u64_padded() ?
> would be cleaner indeed.
bpf_get_prog_name_u64_padded does sound better.
> Will send v2 once Peter and Arnaldo provide their feedback.
>
> Thanks for reviewing!
^ permalink raw reply
* Re: [EXT] [PATCH net] net: mvneta: fix the Rx desc buffer DMA unmapping
From: Antoine Tenart @ 2018-09-20 11:20 UTC (permalink / raw)
To: Yelena Krivosheev
Cc: Antoine Tenart, davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, thomas.petazzoni@bootlin.com,
maxime.chevallier@bootlin.com, gregory.clement@bootlin.com,
miquel.raynal@bootlin.com, Nadav Haklai, Stefan Chulski,
Yan Markman, mw@semihalf.com
In-Reply-To: <5ab58500e78549618b597fdc2e54356a@IL-EXCH01.marvell.com>
Hi Yelena,
On Thu, Sep 20, 2018 at 10:14:56AM +0000, Yelena Krivosheev wrote:
>
> Please, check and fix all cases of dma_unmap_single() usage.
> See mvneta_rxq_drop_pkts()
> ...
> if (!data || !(rx_desc->buf_phys_addr))
> continue;
> dma_unmap_single(pp->dev->dev.parent, rx_desc->buf_phys_addr,
> MVNETA_RX_BUF_SIZE(pp->pkt_size), DMA_FROM_DEVICE);
> __free_page(data);
> ...
I had a look at the one reported by CONFIG_DMA_API_DEBUG, and at DMA
unmapping calls using PAGE_SIZE. As you pointed out there might be
others parts, thanks!
Antoine
--
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [RFC bpf-next 4/4] tools/bpf: handle EOPNOTSUPP when map lookup is failed
From: Prashant Bhole @ 2018-09-20 5:04 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Alexei Starovoitov, Daniel Borkmann, Quentin Monnet,
David S . Miller, netdev
In-Reply-To: <20180919082954.50a827a0@cakuba.netronome.com>
On 9/20/2018 12:29 AM, Jakub Kicinski wrote:
> On Wed, 19 Sep 2018 16:51:43 +0900, Prashant Bhole wrote:
>> Let's add a check for EOPNOTSUPP error when map lookup is failed.
>> Also in case map doesn't support lookup, the output of map dump is
>> changed from "can't lookup element" to "lookup not supported for
>> this map".
>>
>> Patch adds function print_entry_error() function to print the error
>> value.
>>
>> Following example dumps a map which does not support lookup.
>>
>> Output before:
>> root# bpftool map -jp dump id 40
>> [
>> "key": ["0x0a","0x00","0x00","0x00"
>> ],
>> "value": {
>> "error": "can\'t lookup element"
>> },
>> "key": ["0x0b","0x00","0x00","0x00"
>> ],
>> "value": {
>> "error": "can\'t lookup element"
>> }
>> ]
>>
>> root# bpftool map dump id 40
>> can't lookup element with key:
>> 0a 00 00 00
>> can't lookup element with key:
>> 0b 00 00 00
>> Found 0 elements
>>
>> Output after changes:
>> root# bpftool map dump -jp id 45
>> [
>> "key": ["0x0a","0x00","0x00","0x00"
>> ],
>> "value": {
>> "error": "lookup not supported for this map"
>> },
>> "key": ["0x0b","0x00","0x00","0x00"
>> ],
>> "value": {
>> "error": "lookup not supported for this map"
>> }
>> ]
>>
>> root# bpftool map dump id 45
>> key:
>> 0a 00 00 00
>> value:
>> lookup not supported for this map
>> key:
>> 0b 00 00 00
>> value:
>> lookup not supported for this map
>> Found 0 elements
>
> Nice improvement, thanks for the changes! I wonder what your thoughts
> would be on just printing some form of "lookup not supported for this
> map" only once? It seems slightly like repeated information - if
> lookup is not supported for one key it likely won't be for other keys
> too, so we could shorten the output. Would that make sense?
>
>> Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
>> ---
>> tools/bpf/bpftool/main.h | 5 +++++
>> tools/bpf/bpftool/map.c | 35 ++++++++++++++++++++++++++++++-----
>> 2 files changed, 35 insertions(+), 5 deletions(-)
>>
>> diff --git a/tools/bpf/bpftool/main.h b/tools/bpf/bpftool/main.h
>> index 40492cdc4e53..1a8c683f949b 100644
>> --- a/tools/bpf/bpftool/main.h
>> +++ b/tools/bpf/bpftool/main.h
>> @@ -46,6 +46,11 @@
>>
>> #include "json_writer.h"
>>
>> +#define ERR_CANNOT_LOOKUP \
>> + "can't lookup element"
>> +#define ERR_LOOKUP_NOT_SUPPORTED \
>> + "lookup not supported for this map"
>
> Do we need these? Are we going to reused them in more parts of the
> code?
These are used only once. These can be used in do_lookup(). Currently
do_lookup() prints strerror(errno) when lookup is failed. Shall I change
that do_lookup() output?
-Prashant
^ permalink raw reply
* Re: [PATCH rdma-next 00/24] Extend DEVX functionality
From: Leon Romanovsky @ 2018-09-20 5:01 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, RDMA mailing list, Yishai Hadas, Saeed Mahameed,
linux-netdev
In-Reply-To: <20180919181701.GP11367@ziepe.ca>
[-- Attachment #1: Type: text/plain, Size: 4743 bytes --]
On Wed, Sep 19, 2018 at 12:17:01PM -0600, Jason Gunthorpe wrote:
> On Mon, Sep 17, 2018 at 02:03:53PM +0300, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@mellanox.com>
> >
> > From Yishai,
> >
> > This series comes to enable the DEVX functionality in some wider scope,
> > specifically,
> > - It enables using kernel objects that were created by the verbs
> > API in the DEVX flow.
> > - It enables white list commands without DEVX user context.
> > - It enables the IB link layer under CAP_NET_RAW capabilities.
> > - It exposes the PRM handles for RAW QP (i.e. TIRN, TISN, RQN, SQN)
> > to be used later on directly by the DEVX interface.
> >
> > In General,
> > Each object that is created/destroyed/modified via verbs will be stamped
> > with a UID based on its user context. This is already done for DEVX objects
> > commands.
> >
> > This will enable the firmware to enforce the usage of kernel objects
> > from the DEVX flow by validating that the same UID is used and the resources are
> > really related to the same user.
> >
> > For example in case a CQ was created with verbs it will be stamped with
> > UID and once will be pointed by a DEVX create QP command the firmware will
> > validate that the input CQN really belongs to the UID which issues the create QP
> > command.
> >
> > As of the above, all the PRM objects (except of the public ones which
> > are managed by the kernel e.g. FLOW, etc.) will have a UID upon their
> > create/modify/destroy commands. The detection of UMEM / physical
> > addressed in the relevant commands will be done by firmware according to a 'umem
> > valid bit' as the UID may be used in both cases.
> >
> > The series also enables white list commands which don't require a
> > specific DEVX context, instead of this a device UID is used so that
> > the firmware will mask un-privileged functionality. The IB link layer
> > is also enabled once CAP_NET_RAW permission exists.
> >
> > To enable using the RAW QP underlay objects (e.g. TIRN, RQN, etc.) later
> > on by DEVX commands the UHW output for this case was extended to return this
> > data when a DEVX context is used.
> >
> > Thanks
> >
> > Leon Romanovsky (1):
> > net/mlx5: Update mlx5_ifc with DEVX UID bits
> >
> > Yishai Hadas (24):
> > net/mlx5: Set uid as part of CQ commands
> > net/mlx5: Set uid as part of QP commands
> > net/mlx5: Set uid as part of RQ commands
> > net/mlx5: Set uid as part of SQ commands
> > net/mlx5: Set uid as part of SRQ commands
> > net/mlx5: Set uid as part of DCT commands
> > IB/mlx5: Set uid as part of CQ creation
> > IB/mlx5: Set uid as part of QP creation
> > IB/mlx5: Set uid as part of RQ commands
> > IB/mlx5: Set uid as part of SQ commands
> > IB/mlx5: Set uid as part of TIR commands
> > IB/mlx5: Set uid as part of TIS commands
> > IB/mlx5: Set uid as part of RQT commands
> > IB/mlx5: Set uid as part of PD commands
> > IB/mlx5: Set uid as part of TD commands
> > IB/mlx5: Set uid as part of SRQ commands
> > IB/mlx5: Set uid as part of DCT commands
> > IB/mlx5: Set uid as part of XRCD commands
> > IB/mlx5: Set uid as part of MCG commands
>
> This is really too many patches.. They are small and not too hard to
> review, but it is well beyond the guideline.
>
> And I'm not totally happy with the extensive use of ucontext in the IB
> portions, it is problematic looking into the future, and uboject is
> really not supposed to be used in the drivers.
>
> The driver needs to store the uid in the PD (copied from the ucontext
> that created it) and use that in all the dependent places, not use
> pd->uobject->ucontext->devx_uid or some other convoluted way to get
> to it.
>
> The ucontext variable should only be used when creating the PD, CQ and
> devx objects.
>
> This detail becomes quite important, for instance, if we get to the
> 'shared pd' that has been talked about at conference. In this case
> when the 'receiver' of the 'shared pd' creates a child object, like a
> MR, the MR must be stamped with the devx_uid of the PD (ie the
> originating context's devx_uid), not the dev_uid of its local ufile!
>
> If we do that, then the series can be split, so long as pd->devx_uid ==
> 0 until the entire series is applied. uid tagging is an all-or-nothing
> thing, as partial tagging will break verbs. So breaking it up also
> makes it more bi-section safe.
There is very simple reason why this series was sent as one piece. The
basic requirement that the code posted will be as one feature, from the
beginning till the end, easy to follow, cherry-pick, proper ordering
and less errors.
However if you want to see three series posted immediately one after
another and have two of them with dead code, I'll do it.
Thanks
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH net 0/3] qed: Fix series for multi-function mode implementation.
From: Sudarsana Reddy Kalluru @ 2018-09-20 4:59 UTC (permalink / raw)
To: davem; +Cc: netdev, Michal.Kalderon, Tomer.Tayar, Sudarsana Reddy Kalluru
From: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
The patch series addresses few issues in the switch dependent multi-function modes.
Please consider applying it to 'net' tree.
Sudarsana Reddy Kalluru (3):
qed: Fix populating the invalid stag value in multi function mode.
qed: Do not add VLAN 0 tag to untagged frames in multi-function mode.
qed: Add missing device config for RoCE EDPM in UFP mode.
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 45 ++++++++++++++++----------
drivers/net/ethernet/qlogic/qed/qed_dcbx.h | 1 +
drivers/net/ethernet/qlogic/qed/qed_dev.c | 15 ++++++++-
drivers/net/ethernet/qlogic/qed/qed_hsi.h | 4 +++
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 24 +++++++++++---
drivers/net/ethernet/qlogic/qed/qed_reg_addr.h | 6 ++++
6 files changed, 73 insertions(+), 22 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH net 3/3] qed: Add missing device config for RoCE EDPM in UFP mode.
From: Sudarsana Reddy Kalluru @ 2018-09-20 4:59 UTC (permalink / raw)
To: davem; +Cc: netdev, Michal.Kalderon, Tomer.Tayar
In-Reply-To: <20180920045912.28437-1-sudarsana.kalluru@cavium.com>
This patch adds support to configure the DORQ to use vlan-id/priority for
roce EDPM.
Fixes: cac6f691 ("qed: Add support for Unified Fabric Port")
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Tomer Tayar <Tomer.Tayar@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 40 ++++++++++++++------------
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 24 +++++++++++++---
drivers/net/ethernet/qlogic/qed/qed_reg_addr.h | 6 ++++
3 files changed, 48 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
index d53f33c..f5459de 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
@@ -190,11 +190,8 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
static void
qed_dcbx_set_params(struct qed_dcbx_results *p_data,
- struct qed_hwfn *p_hwfn,
- struct qed_hw_info *p_info,
- bool enable,
- u8 prio,
- u8 tc,
+ struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
+ bool enable, u8 prio, u8 tc,
enum dcbx_protocol_type type,
enum qed_pci_personality personality)
{
@@ -213,18 +210,24 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
p_data->arr[type].dont_add_vlan0 = true;
/* QM reconf data */
- if (p_info->personality == personality)
- qed_hw_info_set_offload_tc(p_info, tc);
+ if (p_hwfn->hw_info.personality == personality)
+ qed_hw_info_set_offload_tc(&p_hwfn->hw_info, tc);
+
+ /* Configure dcbx vlan priority in doorbell block for roce EDPM */
+ if (test_bit(QED_MF_UFP_SPECIFIC, &p_hwfn->cdev->mf_bits) &&
+ type == DCBX_PROTOCOL_ROCE) {
+ qed_wr(p_hwfn, p_ptt, DORQ_REG_TAG1_OVRD_MODE, 1);
+ qed_wr(p_hwfn, p_ptt, DORQ_REG_PF_PCP_BB_K2, prio << 1);
+ }
}
/* Update app protocol data and hw_info fields with the TLV info */
static void
qed_dcbx_update_app_info(struct qed_dcbx_results *p_data,
- struct qed_hwfn *p_hwfn,
- bool enable,
- u8 prio, u8 tc, enum dcbx_protocol_type type)
+ struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
+ bool enable, u8 prio, u8 tc,
+ enum dcbx_protocol_type type)
{
- struct qed_hw_info *p_info = &p_hwfn->hw_info;
enum qed_pci_personality personality;
enum dcbx_protocol_type id;
int i;
@@ -237,7 +240,7 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
personality = qed_dcbx_app_update[i].personality;
- qed_dcbx_set_params(p_data, p_hwfn, p_info, enable,
+ qed_dcbx_set_params(p_data, p_hwfn, p_ptt, enable,
prio, tc, type, personality);
}
}
@@ -271,7 +274,7 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
* reconfiguring QM. Get protocol specific data for PF update ramrod command.
*/
static int
-qed_dcbx_process_tlv(struct qed_hwfn *p_hwfn,
+qed_dcbx_process_tlv(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
struct qed_dcbx_results *p_data,
struct dcbx_app_priority_entry *p_tbl,
u32 pri_tc_tbl, int count, u8 dcbx_version)
@@ -315,7 +318,7 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
enable = true;
}
- qed_dcbx_update_app_info(p_data, p_hwfn, enable,
+ qed_dcbx_update_app_info(p_data, p_hwfn, p_ptt, enable,
priority, tc, type);
}
}
@@ -337,7 +340,7 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
continue;
enable = (type == DCBX_PROTOCOL_ETH) ? false : !!dcbx_version;
- qed_dcbx_update_app_info(p_data, p_hwfn, enable,
+ qed_dcbx_update_app_info(p_data, p_hwfn, p_ptt, enable,
priority, tc, type);
}
@@ -347,7 +350,8 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
/* Parse app TLV's to update TC information in hw_info structure for
* reconfiguring QM. Get protocol specific data for PF update ramrod command.
*/
-static int qed_dcbx_process_mib_info(struct qed_hwfn *p_hwfn)
+static int
+qed_dcbx_process_mib_info(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
{
struct dcbx_app_priority_feature *p_app;
struct dcbx_app_priority_entry *p_tbl;
@@ -371,7 +375,7 @@ static int qed_dcbx_process_mib_info(struct qed_hwfn *p_hwfn)
p_info = &p_hwfn->hw_info;
num_entries = QED_MFW_GET_FIELD(p_app->flags, DCBX_APP_NUM_ENTRIES);
- rc = qed_dcbx_process_tlv(p_hwfn, &data, p_tbl, pri_tc_tbl,
+ rc = qed_dcbx_process_tlv(p_hwfn, p_ptt, &data, p_tbl, pri_tc_tbl,
num_entries, dcbx_version);
if (rc)
return rc;
@@ -897,7 +901,7 @@ static void qed_dcbx_aen(struct qed_hwfn *hwfn, u32 mib_type)
return rc;
if (type == QED_DCBX_OPERATIONAL_MIB) {
- rc = qed_dcbx_process_mib_info(p_hwfn);
+ rc = qed_dcbx_process_mib_info(p_hwfn, p_ptt);
if (!rc) {
/* reconfigure tcs of QM queues according
* to negotiation results
diff --git a/drivers/net/ethernet/qlogic/qed/qed_mcp.c b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
index 5d37ec7..58c7eb9 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_mcp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
@@ -1581,13 +1581,29 @@ static void qed_mcp_update_stag(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
p_hwfn->mcp_info->func_info.ovlan = (u16)shmem_info.ovlan_stag &
FUNC_MF_CFG_OV_STAG_MASK;
p_hwfn->hw_info.ovlan = p_hwfn->mcp_info->func_info.ovlan;
- if ((p_hwfn->hw_info.hw_mode & BIT(MODE_MF_SD)) &&
- (p_hwfn->hw_info.ovlan != QED_MCP_VLAN_UNSET)) {
- qed_wr(p_hwfn, p_ptt,
- NIG_REG_LLH_FUNC_TAG_VALUE, p_hwfn->hw_info.ovlan);
+ if (test_bit(QED_MF_OVLAN_CLSS, &p_hwfn->cdev->mf_bits)) {
+ if (p_hwfn->hw_info.ovlan != QED_MCP_VLAN_UNSET) {
+ qed_wr(p_hwfn, p_ptt, NIG_REG_LLH_FUNC_TAG_VALUE,
+ p_hwfn->hw_info.ovlan);
+ qed_wr(p_hwfn, p_ptt, NIG_REG_LLH_FUNC_TAG_EN, 1);
+
+ /* Configure DB to add external vlan to EDPM packets */
+ qed_wr(p_hwfn, p_ptt, DORQ_REG_TAG1_OVRD_MODE, 1);
+ qed_wr(p_hwfn, p_ptt, DORQ_REG_PF_EXT_VID_BB_K2,
+ p_hwfn->hw_info.ovlan);
+ } else {
+ qed_wr(p_hwfn, p_ptt, NIG_REG_LLH_FUNC_TAG_EN, 0);
+ qed_wr(p_hwfn, p_ptt, NIG_REG_LLH_FUNC_TAG_VALUE, 0);
+ qed_wr(p_hwfn, p_ptt, DORQ_REG_TAG1_OVRD_MODE, 0);
+ qed_wr(p_hwfn, p_ptt, DORQ_REG_PF_EXT_VID_BB_K2, 0);
+ }
+
qed_sp_pf_update_stag(p_hwfn);
}
+ DP_VERBOSE(p_hwfn, QED_MSG_SP, "ovlan = %d hw_mode = 0x%x\n",
+ p_hwfn->mcp_info->func_info.ovlan, p_hwfn->hw_info.hw_mode);
+
/* Acknowledge the MFW */
qed_mcp_cmd(p_hwfn, p_ptt, DRV_MSG_CODE_S_TAG_UPDATE_ACK, 0,
&resp, ¶m);
diff --git a/drivers/net/ethernet/qlogic/qed/qed_reg_addr.h b/drivers/net/ethernet/qlogic/qed/qed_reg_addr.h
index f736f70..2440970 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_reg_addr.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_reg_addr.h
@@ -216,6 +216,12 @@
0x00c000UL
#define DORQ_REG_IFEN \
0x100040UL
+#define DORQ_REG_TAG1_OVRD_MODE \
+ 0x1008b4UL
+#define DORQ_REG_PF_PCP_BB_K2 \
+ 0x1008c4UL
+#define DORQ_REG_PF_EXT_VID_BB_K2 \
+ 0x1008c8UL
#define DORQ_REG_DB_DROP_REASON \
0x100a2cUL
#define DORQ_REG_DB_DROP_DETAILS \
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 2/3] qed: Do not add VLAN 0 tag to untagged frames in multi-function mode.
From: Sudarsana Reddy Kalluru @ 2018-09-20 4:59 UTC (permalink / raw)
To: davem; +Cc: netdev, Michal.Kalderon, Tomer.Tayar
In-Reply-To: <20180920045912.28437-1-sudarsana.kalluru@cavium.com>
In certain multi-function switch dependent modes, firmware adds vlan tag 0
to the untagged frames. This leads to double tagging for the traffic
if the dcbx is enabled, which is not the desired behavior. To avoid this,
driver needs to set "dcb_dont_add_vlan0" flag.
Fixes: cac6f691 ("qed: Add support for Unified Fabric Port")
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Tomer Tayar <Tomer.Tayar@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 9 ++++++++-
drivers/net/ethernet/qlogic/qed/qed_dcbx.h | 1 +
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
index 6bb76e6..d53f33c 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
@@ -190,6 +190,7 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
static void
qed_dcbx_set_params(struct qed_dcbx_results *p_data,
+ struct qed_hwfn *p_hwfn,
struct qed_hw_info *p_info,
bool enable,
u8 prio,
@@ -206,6 +207,11 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
else
p_data->arr[type].update = DONT_UPDATE_DCB_DSCP;
+ /* Do not add vlan tag 0 when DCB is enabled and port in UFP/OV mode */
+ if ((test_bit(QED_MF_8021Q_TAGGING, &p_hwfn->cdev->mf_bits) ||
+ test_bit(QED_MF_8021AD_TAGGING, &p_hwfn->cdev->mf_bits)))
+ p_data->arr[type].dont_add_vlan0 = true;
+
/* QM reconf data */
if (p_info->personality == personality)
qed_hw_info_set_offload_tc(p_info, tc);
@@ -231,7 +237,7 @@ static bool qed_dcbx_roce_v2_tlv(u32 app_info_bitmap, u16 proto_id, bool ieee)
personality = qed_dcbx_app_update[i].personality;
- qed_dcbx_set_params(p_data, p_info, enable,
+ qed_dcbx_set_params(p_data, p_hwfn, p_info, enable,
prio, tc, type, personality);
}
}
@@ -954,6 +960,7 @@ static void qed_dcbx_update_protocol_data(struct protocol_dcb_data *p_data,
p_data->dcb_enable_flag = p_src->arr[type].enable;
p_data->dcb_priority = p_src->arr[type].priority;
p_data->dcb_tc = p_src->arr[type].tc;
+ p_data->dcb_dont_add_vlan0 = p_src->arr[type].dont_add_vlan0;
}
/* Set pf update ramrod command params */
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dcbx.h b/drivers/net/ethernet/qlogic/qed/qed_dcbx.h
index a4d688c..01f253e 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dcbx.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_dcbx.h
@@ -55,6 +55,7 @@ struct qed_dcbx_app_data {
u8 update; /* Update indication */
u8 priority; /* Priority */
u8 tc; /* Traffic Class */
+ bool dont_add_vlan0; /* Do not insert a vlan tag with id 0 */
};
#define QED_DCBX_VERSION_DISABLED 0
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 1/3] qed: Fix populating the invalid stag value in multi function mode.
From: Sudarsana Reddy Kalluru @ 2018-09-20 4:59 UTC (permalink / raw)
To: davem; +Cc: netdev, Michal.Kalderon, Tomer.Tayar
In-Reply-To: <20180920045912.28437-1-sudarsana.kalluru@cavium.com>
In multi-function mode, driver receives the stag value (outer vlan)
for a PF from management FW (MFW). If the stag value is negotiated prior to
the driver load, then the stag is not notified to the driver and hence
driver will have the invalid stag value.
The fix is to request the MFW for STAG value during the driver load time.
Fixes: cac6f691 ("qed: Add support for Unified Fabric Port")
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Tomer Tayar <Tomer.Tayar@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_dev.c | 15 ++++++++++++++-
drivers/net/ethernet/qlogic/qed/qed_hsi.h | 4 ++++
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dev.c b/drivers/net/ethernet/qlogic/qed/qed_dev.c
index 016ca8a..97f073f 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dev.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c
@@ -1706,7 +1706,7 @@ static int qed_vf_start(struct qed_hwfn *p_hwfn,
int qed_hw_init(struct qed_dev *cdev, struct qed_hw_init_params *p_params)
{
struct qed_load_req_params load_req_params;
- u32 load_code, param, drv_mb_param;
+ u32 load_code, resp, param, drv_mb_param;
bool b_default_mtu = true;
struct qed_hwfn *p_hwfn;
int rc = 0, mfw_rc, i;
@@ -1852,6 +1852,19 @@ int qed_hw_init(struct qed_dev *cdev, struct qed_hw_init_params *p_params)
if (IS_PF(cdev)) {
p_hwfn = QED_LEADING_HWFN(cdev);
+
+ /* Get pre-negotiated values for stag, bandwidth etc. */
+ DP_VERBOSE(p_hwfn,
+ QED_MSG_SPQ,
+ "Sending GET_OEM_UPDATES command to trigger stag/bandwidth attention handling\n");
+ drv_mb_param = 1 << DRV_MB_PARAM_DUMMY_OEM_UPDATES_OFFSET;
+ rc = qed_mcp_cmd(p_hwfn, p_hwfn->p_main_ptt,
+ DRV_MSG_CODE_GET_OEM_UPDATES,
+ drv_mb_param, &resp, ¶m);
+ if (rc)
+ DP_NOTICE(p_hwfn,
+ "Failed to send GET_OEM_UPDATES attention request\n");
+
drv_mb_param = STORM_FW_VERSION;
rc = qed_mcp_cmd(p_hwfn, p_hwfn->p_main_ptt,
DRV_MSG_CODE_OV_UPDATE_STORM_FW_VER,
diff --git a/drivers/net/ethernet/qlogic/qed/qed_hsi.h b/drivers/net/ethernet/qlogic/qed/qed_hsi.h
index 8faceb6..9b3ef00e 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_hsi.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_hsi.h
@@ -12414,6 +12414,7 @@ struct public_drv_mb {
#define DRV_MSG_SET_RESOURCE_VALUE_MSG 0x35000000
#define DRV_MSG_CODE_OV_UPDATE_WOL 0x38000000
#define DRV_MSG_CODE_OV_UPDATE_ESWITCH_MODE 0x39000000
+#define DRV_MSG_CODE_GET_OEM_UPDATES 0x41000000
#define DRV_MSG_CODE_BW_UPDATE_ACK 0x32000000
#define DRV_MSG_CODE_NIG_DRAIN 0x30000000
@@ -12541,6 +12542,9 @@ struct public_drv_mb {
#define DRV_MB_PARAM_ESWITCH_MODE_VEB 0x1
#define DRV_MB_PARAM_ESWITCH_MODE_VEPA 0x2
+#define DRV_MB_PARAM_DUMMY_OEM_UPDATES_MASK 0x1
+#define DRV_MB_PARAM_DUMMY_OEM_UPDATES_OFFSET 0
+
#define DRV_MB_PARAM_SET_LED_MODE_OPER 0x0
#define DRV_MB_PARAM_SET_LED_MODE_ON 0x1
#define DRV_MB_PARAM_SET_LED_MODE_OFF 0x2
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 00/21] SMMU enablement for NXP LS1043A and LS1046A
From: Laurentiu Tudor @ 2018-09-20 10:38 UTC (permalink / raw)
To: Robin Murphy, devicetree@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: Madalin-cristian Bucur, Roy Pledge, Leo Li, shawnguo@kernel.org,
davem@davemloft.net
In-Reply-To: <39211e7a-034b-cdca-f182-1b6f6e5fbc53@arm.com>
On 19.09.2018 17:37, Robin Murphy wrote:
> On 19/09/18 15:18, Laurentiu Tudor wrote:
>> Hi Robin,
>>
>> On 19.09.2018 16:25, Robin Murphy wrote:
>>> Hi Laurentiu,
>>>
>>> On 19/09/18 13:35, laurentiu.tudor@nxp.com wrote:
>>>> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>>>>
>>>> This patch series adds SMMU support for NXP LS1043A and LS1046A chips
>>>> and consists mostly in important driver fixes and the required device
>>>> tree updates. It touches several subsystems and consists of three main
>>>> parts:
>>>> - changes in soc/drivers/fsl/qbman drivers adding iommu mapping of
>>>> reserved memory areas, fixes and defered probe support
>>>> - changes in drivers/net/ethernet/freescale/dpaa_eth drivers
>>>> consisting in misc dma mapping related fixes and probe ordering
>>>> - addition of the actual arm smmu device tree node together with
>>>> various adjustments to the device trees
>>>>
>>>> Performance impact
>>>>
>>>> Running iperf benchmarks in a back-to-back setup (both sides
>>>> having smmu enabled) on a 10GBps port show an important
>>>> networking performance degradation of around %40 (9.48Gbps
>>>> linerate vs 5.45Gbps). If you need performance but without
>>>> SMMU support you can use "iommu.passthrough=1" to disable
>>>> SMMU.
>>>>
>>>> USB issue and workaround
>>>>
>>>> There's a problem with the usb controllers in these chips
>>>> generating smaller, 40-bit wide dma addresses instead of the
>>>> 48-bit
>>>> supported at the smmu input. So you end up in a situation
>>>> where the
>>>> smmu is mapped with 48-bit address translations, but the device
>>>> generates transactions with clipped 40-bit addresses, thus smmu
>>>> context faults are triggered. I encountered a similar
>>>> situation for
>>>> mmc that I managed to fix in software [1] however for USB I
>>>> did not
>>>> find a proper place in the code to add a similar fix. The only
>>>> workaround I found was to add this kernel parameter which
>>>> limits the
>>>> usb dma to 32-bit size: "xhci-hcd.quirks=0x800000".
>>>> This workaround if far from ideal, so any suggestions for a code
>>>> based workaround in this area would be greatly appreciated.
>>>
>>> If you have a nominally-64-bit device with a
>>> narrower-than-the-main-interconnect link in front of it, that should
>>> already be fixed in 4.19-rc by bus_dma_mask picking up DT dma-ranges,
>>> provided the interconnect hierarchy can be described appropriately (or
>>> at least massaged sufficiently to satisfy the binding), e.g.:
>>>
>>> / {
>>> ...
>>>
>>> soc {
>>> ranges;
>>> dma-ranges = <0 0 10000 0>;
>>>
>>> dev_48bit { ... };
>>>
>>> periph_bus {
>>> ranges;
>>> dma-ranges = <0 0 100 0>;
>>>
>>> dev_40bit { ... };
>>> };
>>> };
>>> };
>>>
>>> and if that fails to work as expected (except for PCI hosts where
>>> handling dma-ranges properly still needs sorting out), please do let us
>>> know ;)
>>>
>>
>> Just to confirm, Is this [1] the change I was supposed to test?
>
> Not quite - dma-ranges is only valid for nodes representing a bus, so
> putting it directly in the USB device nodes doesn't work (FWIW that's
> why PCI is broken, because the parser doesn't expect the
> bus-as-leaf-node case). That's teh point of that intermediate simple-bus
> node represented by "periph_bus" in my example (sorry, I should have put
> compatibles in to make it clearer) - often that's actually true to life
> (i.e. "soc" is something like a CCI and "periph_bus" is something like
> an AXI NIC gluing a bunch of lower-bandwidth DMA masters to one of the
> CCI ports) but at worst it's just a necessary evil to make the binding
> happy (if it literally only represents the point-to-point link between
> the device master port and interconnect slave port).
>
Quick update: so I adjusted to device tree according to your example and
it works so now I can get rid of that nasty kernel arg based workaround,
yey! :-)
Thanks a lot, that was really helpful.
---
Best Regards, Laurentiu
^ permalink raw reply
* Re: [PATCH mlx5-next 02/25] net/mlx5: Set uid as part of QP commands
From: Leon Romanovsky @ 2018-09-20 4:51 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, RDMA mailing list, Yishai Hadas, Saeed Mahameed,
linux-netdev
In-Reply-To: <20180919172731.GM11367@ziepe.ca>
[-- Attachment #1: Type: text/plain, Size: 3618 bytes --]
On Wed, Sep 19, 2018 at 11:27:31AM -0600, Jason Gunthorpe wrote:
> On Mon, Sep 17, 2018 at 02:03:55PM +0300, Leon Romanovsky wrote:
> > From: Yishai Hadas <yishaih@mellanox.com>
> >
> > Set uid as part of QP commands so that the firmware can manage the
> > QP object in a secured way.
> >
> > That will enable using a QP that was created by verbs application to
> > be used by the DEVX flow in case the uid is equal.
> >
> > Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
> > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> > drivers/net/ethernet/mellanox/mlx5/core/qp.c | 45 +++++++++++++++++-----------
> > include/linux/mlx5/mlx5_ifc.h | 22 +++++++-------
> > include/linux/mlx5/qp.h | 1 +
> > 3 files changed, 39 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/qp.c b/drivers/net/ethernet/mellanox/mlx5/core/qp.c
> > index 4ca07bfb6b14..04f72a1cdbcc 100644
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/qp.c
> > @@ -240,6 +240,7 @@ int mlx5_core_create_qp(struct mlx5_core_dev *dev,
> > if (err)
> > return err;
> >
> > + qp->uid = MLX5_GET(create_qp_in, in, uid);
> > qp->qpn = MLX5_GET(create_qp_out, out, qpn);
> > mlx5_core_dbg(dev, "qpn = 0x%x\n", qp->qpn);
> >
> > @@ -261,6 +262,7 @@ int mlx5_core_create_qp(struct mlx5_core_dev *dev,
> > memset(dout, 0, sizeof(dout));
> > MLX5_SET(destroy_qp_in, din, opcode, MLX5_CMD_OP_DESTROY_QP);
> > MLX5_SET(destroy_qp_in, din, qpn, qp->qpn);
> > + MLX5_SET(destroy_qp_in, din, uid, qp->uid);
> > mlx5_cmd_exec(dev, din, sizeof(din), dout, sizeof(dout));
> > return err;
> > }
> > @@ -320,6 +322,7 @@ int mlx5_core_destroy_qp(struct mlx5_core_dev *dev,
> >
> > MLX5_SET(destroy_qp_in, in, opcode, MLX5_CMD_OP_DESTROY_QP);
> > MLX5_SET(destroy_qp_in, in, qpn, qp->qpn);
> > + MLX5_SET(destroy_qp_in, in, uid, qp->uid);
> > err = mlx5_cmd_exec(dev, in, sizeof(in), out, sizeof(out));
> > if (err)
> > return err;
> > @@ -373,7 +376,7 @@ static void mbox_free(struct mbox_info *mbox)
> >
> > static int modify_qp_mbox_alloc(struct mlx5_core_dev *dev, u16 opcode, int qpn,
> > u32 opt_param_mask, void *qpc,
> > - struct mbox_info *mbox)
> > + struct mbox_info *mbox, u16 uid)
> > {
> > mbox->out = NULL;
> > mbox->in = NULL;
> > @@ -381,26 +384,32 @@ static int modify_qp_mbox_alloc(struct mlx5_core_dev *dev, u16 opcode, int qpn,
> > #define MBOX_ALLOC(mbox, typ) \
> > mbox_alloc(mbox, MLX5_ST_SZ_BYTES(typ##_in), MLX5_ST_SZ_BYTES(typ##_out))
> >
> > -#define MOD_QP_IN_SET(typ, in, _opcode, _qpn) \
> > - MLX5_SET(typ##_in, in, opcode, _opcode); \
> > - MLX5_SET(typ##_in, in, qpn, _qpn)
> > -
> > -#define MOD_QP_IN_SET_QPC(typ, in, _opcode, _qpn, _opt_p, _qpc) \
> > - MOD_QP_IN_SET(typ, in, _opcode, _qpn); \
> > - MLX5_SET(typ##_in, in, opt_param_mask, _opt_p); \
> > - memcpy(MLX5_ADDR_OF(typ##_in, in, qpc), _qpc, MLX5_ST_SZ_BYTES(qpc))
> > +#define MOD_QP_IN_SET(typ, in, _opcode, _qpn, _uid) \
> > + do { \
> > + MLX5_SET(typ##_in, in, opcode, _opcode); \
> > + MLX5_SET(typ##_in, in, qpn, _qpn); \
> > + MLX5_SET(typ##_in, in, uid, _uid); \
> > + } while (0)
> > +
> > +#define MOD_QP_IN_SET_QPC(typ, in, _opcode, _qpn, _opt_p, _qpc, _uid) \
> > + do { \
> > + MOD_QP_IN_SET(typ, in, _opcode, _qpn, _uid); \
> > + MLX5_SET(typ##_in, in, opt_param_mask, _opt_p); \
> > + memcpy(MLX5_ADDR_OF(typ##_in, in, qpc), \
> > + _qpc, MLX5_ST_SZ_BYTES(qpc)); \
> > + } while (0)
>
> These should get touched by clang-format to follow the usual
> formatting for macros..
Thanks, we will do.
>
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH mlx5-next 07/25] net/mlx5: Update mlx5_ifc with DEVX UID bits
From: Leon Romanovsky @ 2018-09-20 4:51 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, RDMA mailing list, Yishai Hadas, Saeed Mahameed,
linux-netdev
In-Reply-To: <20180919173147.GO11367@ziepe.ca>
[-- Attachment #1: Type: text/plain, Size: 880 bytes --]
On Wed, Sep 19, 2018 at 11:31:47AM -0600, Jason Gunthorpe wrote:
> On Mon, Sep 17, 2018 at 02:04:00PM +0300, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@mellanox.com>
> >
> > Add DEVX information to WQ, SRQ, CQ, TRI, TIS, QP,
> > RQ, XRCD, PD, MKEY and MCG.
> >
> > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> > ---
> > include/linux/mlx5/mlx5_ifc.h | 67 +++++++++++++++++++++++++++----------------
> > 1 file changed, 43 insertions(+), 24 deletions(-)
>
> It is weird that we sometimes have these IFC bundle updates and
> sometimes the IFC is inlined in the patch..
>
> Why not just do one big IFC only patch with everything the series
> needs?
Nothing fancy, this "ifc change" came from my need to put all mlx5-next
related code in separate patches from IB and those definitions were
sprinkled in all following IB-specific patches.
Thanks
>
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH bpf-next 2/2] xsk: fix bug when trying to use both copy and zero-copy on one queue id
From: Y Song @ 2018-09-20 4:47 UTC (permalink / raw)
To: Magnus Karlsson
Cc: magnus.karlsson, Björn Töpel, Alexei Starovoitov,
Daniel Borkmann, netdev
In-Reply-To: <CAJ8uoz0VjFUqbRRPAO_Gqqz8+APwYNqbpz6eCv2PiXYd9Lf66Q@mail.gmail.com>
On Wed, Sep 19, 2018 at 12:15 AM Magnus Karlsson
<magnus.karlsson@gmail.com> wrote:
>
> On Tue, Sep 18, 2018 at 7:23 PM Y Song <ys114321@gmail.com> wrote:
> >
> > On Tue, Sep 18, 2018 at 3:13 AM Magnus Karlsson
> > <magnus.karlsson@intel.com> wrote:
> > >
> > > Previously, the xsk code did not record which umem was bound to a
> > > specific queue id. This was not required if all drivers were zero-copy
> > > enabled as this had to be recorded in the driver anyway. So if a user
> > > tried to bind two umems to the same queue, the driver would say
> > > no. But if copy-mode was first enabled and then zero-copy mode (or the
> > > reverse order), we mistakenly enabled both of them on the same umem
> > > leading to buggy behavior. The main culprit for this is that we did
> > > not store the association of umem to queue id in the copy case and
> > > only relied on the driver reporting this. As this relation was not
> > > stored in the driver for copy mode (it does not rely on the AF_XDP
> > > NDOs), this obviously could not work.
> > >
> > > This patch fixes the problem by always recording the umem to queue id
> > > relationship in the netdev_queue and netdev_rx_queue structs. This way
> > > we always know what kind of umem has been bound to a queue id and can
> > > act appropriately at bind time.
> > >
> > > Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
> > > ---
> > > net/xdp/xdp_umem.c | 87 +++++++++++++++++++++++++++++++++++++++++++-----------
> > > net/xdp/xdp_umem.h | 2 +-
> > > 2 files changed, 71 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
> > > index b3b632c..12300b5 100644
> > > --- a/net/xdp/xdp_umem.c
> > > +++ b/net/xdp/xdp_umem.c
> > > @@ -42,6 +42,41 @@ void xdp_del_sk_umem(struct xdp_umem *umem, struct xdp_sock *xs)
> > > }
> > > }
> > >
> > > +/* The umem is stored both in the _rx struct and the _tx struct as we do
> > > + * not know if the device has more tx queues than rx, or the opposite.
> > > + * This might also change during run time.
> > > + */
> > > +static void xdp_reg_umem_at_qid(struct net_device *dev, struct xdp_umem *umem,
> > > + u16 queue_id)
> > > +{
> > > + if (queue_id < dev->real_num_rx_queues)
> > > + dev->_rx[queue_id].umem = umem;
> > > + if (queue_id < dev->real_num_tx_queues)
> > > + dev->_tx[queue_id].umem = umem;
> > > +}
> > > +
> > > +static struct xdp_umem *xdp_get_umem_from_qid(struct net_device *dev,
> > > + u16 queue_id)
> > > +{
> > > + if (queue_id < dev->real_num_rx_queues)
> > > + return dev->_rx[queue_id].umem;
> > > + if (queue_id < dev->real_num_tx_queues)
> > > + return dev->_tx[queue_id].umem;
> > > +
> > > + return NULL;
> > > +}
> > > +
> > > +static void xdp_clear_umem_at_qid(struct net_device *dev, u16 queue_id)
> > > +{
> > > + /* Zero out the entry independent on how many queues are configured
> > > + * at this point in time, as it might be used in the future.
> > > + */
> > > + if (queue_id < dev->num_rx_queues)
> > > + dev->_rx[queue_id].umem = NULL;
> > > + if (queue_id < dev->num_tx_queues)
> > > + dev->_tx[queue_id].umem = NULL;
> > > +}
> > > +
> >
> > I am sure whether the following scenario can happen or not.
> > Could you clarify?
> > 1. suppose initially we have num_rx_queues = num_tx_queues = 10
> > xdp_reg_umem_at_qid() set umem1 to queue_id = 8
> > 2. num_tx_queues is changed to 5
>
> You probably mean real_num_tx_queues here. This is the current number
> of queues configured via e.g. ethtool. num_tx_queues will not change
> unless you change device (or device driver).
I am actually not really familiar with this area of
code. Your explanation definitely helps my understanding.
>
> > 3. xdp_clear_umem_at_qid() is called for queue_id = 8,
> > and dev->_rx[8].umum = 0.
>
> At this point both _rx[8].umem and _tx[8].umem are set to NULL as the
> test is against num_[rx|tx]_queues which is the max allowed for the
> device, not the current allocated one which is real_num_tx_queues.
> With this in mind, the scenario below will not happen. Do you agree?
I agree. If num_{rx,tx}_queues are not changed, than clear should set
both with NULL and the step 4/5 won't happen any more.
>
> > 4. xdp_reg_umem_at_qid() is called gain to set for queue_id = 8
> > dev->_rx[8].umem = umem2
> > 5. num_tx_queues is changed to 10
> > Now dev->_rx[8].umem != dev->_tx[8].umem, is this possible and is it
> > a problem?
> >
> > > int xdp_umem_query(struct net_device *dev, u16 queue_id)
> > > {
> > > struct netdev_bpf bpf;
> > > @@ -58,11 +93,11 @@ int xdp_umem_query(struct net_device *dev, u16 queue_id)
> > > }
> > >
> > > int xdp_umem_assign_dev(struct xdp_umem *umem, struct net_device *dev,
> > > - u32 queue_id, u16 flags)
> > > + u16 queue_id, u16 flags)
> > > {
> > > bool force_zc, force_copy;
> > > struct netdev_bpf bpf;
> > > - int err;
> > > + int err = 0;
> > >
> > > force_zc = flags & XDP_ZEROCOPY;
> > > force_copy = flags & XDP_COPY;
> > > @@ -70,18 +105,28 @@ int xdp_umem_assign_dev(struct xdp_umem *umem, struct net_device *dev,
> > > if (force_zc && force_copy)
> > > return -EINVAL;
> > >
> > > + rtnl_lock();
> > > + if (xdp_get_umem_from_qid(dev, queue_id)) {
> > > + err = -EBUSY;
> > > + goto rtnl_unlock;
> > > + }
> > > +
> > > + xdp_reg_umem_at_qid(dev, umem, queue_id);
> > > + umem->dev = dev;
> > > + umem->queue_id = queue_id;
> > > if (force_copy)
> > > - return 0;
> > > + /* For copy-mode, we are done. */
> > > + goto rtnl_unlock;
> > >
> > > - if (!dev->netdev_ops->ndo_bpf || !dev->netdev_ops->ndo_xsk_async_xmit)
> > > - return force_zc ? -EOPNOTSUPP : 0; /* fail or fallback */
> > > + if (!dev->netdev_ops->ndo_bpf ||
> > > + !dev->netdev_ops->ndo_xsk_async_xmit) {
> > > + err = -EOPNOTSUPP;
> > > + goto err_unreg_umem;
> > > + }
> > >
> > > - rtnl_lock();
> > > err = xdp_umem_query(dev, queue_id);
> > > - if (err) {
> > > - err = err < 0 ? -EOPNOTSUPP : -EBUSY;
> > > - goto err_rtnl_unlock;
> > > - }
> > > + if (err)
> > > + goto err_unreg_umem;
> > >
> > > bpf.command = XDP_SETUP_XSK_UMEM;
> > > bpf.xsk.umem = umem;
> > > @@ -89,18 +134,20 @@ int xdp_umem_assign_dev(struct xdp_umem *umem, struct net_device *dev,
> > >
> > > err = dev->netdev_ops->ndo_bpf(dev, &bpf);
> > > if (err)
> > > - goto err_rtnl_unlock;
> > > + goto err_unreg_umem;
> > > rtnl_unlock();
> > >
> > > dev_hold(dev);
> > > - umem->dev = dev;
> > > - umem->queue_id = queue_id;
> > > umem->zc = true;
> > > return 0;
> > >
> > > -err_rtnl_unlock:
> > > +err_unreg_umem:
> > > + xdp_clear_umem_at_qid(dev, queue_id);
> >
> > You did not clear umem->dev and umem->queue_id,is a problem here?
> > For example in xdp_umem_clear_dev(), umem->dev is checked.
>
> As the umem might be shared, I cannot clear these variables as they
> are used by another socket when it is shared.
>
> The umem->dev check in xdp_umem_clear_dev() is for sockets that are
> killed when only half-ways set up. In that case, umem->dev might still
> be NULL.
Make sense.
>
> > > + if (!force_zc)
> > > + err = 0; /* fallback to copy mode */
> > > +rtnl_unlock:
> > > rtnl_unlock();
> > > - return force_zc ? err : 0; /* fail or fallback */
> > > + return err;
> > > }
> > >
> > > static void xdp_umem_clear_dev(struct xdp_umem *umem)
> > > @@ -108,7 +155,7 @@ static void xdp_umem_clear_dev(struct xdp_umem *umem)
> > > struct netdev_bpf bpf;
> > > int err;
> > >
> > > - if (umem->dev) {
> > > + if (umem->zc) {
> > > bpf.command = XDP_SETUP_XSK_UMEM;
> > > bpf.xsk.umem = NULL;
> > > bpf.xsk.queue_id = umem->queue_id;
> > > @@ -121,7 +168,13 @@ static void xdp_umem_clear_dev(struct xdp_umem *umem)
> > > WARN(1, "failed to disable umem!\n");
> > >
> > > dev_put(umem->dev);
> > > - umem->dev = NULL;
> > > + umem->zc = false;
> > > + }
> > > +
> > > + if (umem->dev) {
> > > + rtnl_lock();
> > > + xdp_clear_umem_at_qid(umem->dev, umem->queue_id);
> > > + rtnl_unlock();
> >
> > Previously, umem->dev is reset to NULL. Now, it is left as is. I
> > assume it is not possible
> > that this function xdp_umem_clear_dev() is called again for this umem, right?
>
> This function will only be called once for each umem / queue_id pair.
> We only allow one such binding with this patch. This is what was
> broken with the original code.
Thanks for explanation.
>
> Thanks Song for your review. I appreciate that you take a look at my code.
>
> /Magnus
>
> > > }
> > > }
> > >
> > > diff --git a/net/xdp/xdp_umem.h b/net/xdp/xdp_umem.h
> > > index c8be1ad..2760322 100644
> > > --- a/net/xdp/xdp_umem.h
> > > +++ b/net/xdp/xdp_umem.h
> > > @@ -9,7 +9,7 @@
> > > #include <net/xdp_sock.h>
> > >
> > > int xdp_umem_assign_dev(struct xdp_umem *umem, struct net_device *dev,
> > > - u32 queue_id, u16 flags);
> > > + u16 queue_id, u16 flags);
> > > bool xdp_umem_validate_queues(struct xdp_umem *umem);
> > > void xdp_get_umem(struct xdp_umem *umem);
> > > void xdp_put_umem(struct xdp_umem *umem);
> > > --
> > > 2.7.4
> > >
^ permalink raw reply
* Re: [PATCH net-next v3 1/2] netlink: ipv4 igmp join notifications
From: David Ahern @ 2018-09-20 4:47 UTC (permalink / raw)
To: pruddy, Roopa Prabhu
Cc: netdev, Jiří Pírko, Stephen Hemminger,
Nikolay Aleksandrov
In-Reply-To: <a7629503af0aa345d65b1651586f906dc7259484.camel@vyatta.att-mail.com>
On 9/18/18 6:12 AM, Patrick Ruddy wrote:
>
> I've hit a small snag with adding the new groups. The number of defined
> groups currently sits at 31 so I can only add one before hitting the
I believe you have no more available. RTNLGRP_* has been defined from 0
(RTNLGRP_NONE) to 31 (RTNLGRP_IPV6_MROUTE_R) which covers the u32 range.
> limit defined by the 32 bit groups bitmask in socakddr_nl. I can use 1
> group for both v4 and v6 notifications which seems like the sensible
> options since the AF is carried separately, but it breaks the precedent
> where there are separate IPV4 and IPV6 groups for IFADDR.
>
> I have the combined group patches ready and can share them if that's
> the preference.
>
> Has there been any previous discussion about extending the number of
> availabel groups?
>
I have not tried it, but from a prior code review I believe you have you
use setsockopt to add groups > 31.
^ permalink raw reply
* Re: [PATCH] net: toshiba: remove a redundant local variable 'index_specified'
From: Sergei Shtylyov @ 2018-09-20 10:23 UTC (permalink / raw)
To: zhong jiang, davem; +Cc: benh, paulus, mpe, netdev, linux-kernel
In-Reply-To: <1537408565-22315-1-git-send-email-zhongjiang@huawei.com>
On 9/20/2018 4:56 AM, zhong jiang wrote:
> The local variable 'index_specified' is never used after being assigned.
> hence it should be redundant adn can be removed.
s/adn/and/.
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH RFT net-next 0/2] net: phy: Eliminate unnecessary soft
From: Chris Healy @ 2018-09-20 4:39 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, David S. Miller, Andrew Lunn, Felix Fietkau,
harini.katakam, afleming, Anatolij Gustschin, Arnd Bergmann,
asmirnov, avi.kp.137, avorontsov, baijiaju1990, benh,
charles-antoine.couret, clemens.gruber, Colin King, cyril,
david.thomson, ddaney, dongsheng.wang, David Woodhouse, eha,
houjingj, jeff, Jingju.Hou, Jisheng.Zhang, johan, Kapil.Juneja,
kim.phillips
In-Reply-To: <20180919013505.11347-1-f.fainelli@gmail.com>
> This patch series eliminates unnecessary software resets of the PHY.
> This should hopefully not break anybody's hardware; but I would
> appreciate testing to make sure this is is the case.
Tested-by: Chris Healy <cphealy@gmail.com>
Tested with Marvell 88E6161 and Marvell 88E6352 switches (which use
Marvell PHY driver.)
^ permalink raw reply
* RE: [EXT] [PATCH net] net: mvneta: fix the Rx desc buffer DMA unmapping
From: Yelena Krivosheev @ 2018-09-20 10:14 UTC (permalink / raw)
To: Antoine Tenart, davem@davemloft.net
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
thomas.petazzoni@bootlin.com, maxime.chevallier@bootlin.com,
gregory.clement@bootlin.com, miquel.raynal@bootlin.com,
Nadav Haklai, Stefan Chulski, Yan Markman, mw@semihalf.com
In-Reply-To: <20180919132906.26868-1-antoine.tenart@bootlin.com>
Hi Antoine.
Good point.
Please, check and fix all cases of dma_unmap_single() usage.
See mvneta_rxq_drop_pkts()
...
if (!data || !(rx_desc->buf_phys_addr))
continue;
dma_unmap_single(pp->dev->dev.parent, rx_desc->buf_phys_addr,
MVNETA_RX_BUF_SIZE(pp->pkt_size), DMA_FROM_DEVICE);
__free_page(data);
...
Thanks.
Yelena
-----Original Message-----
From: Antoine Tenart [mailto:antoine.tenart@bootlin.com]
Sent: Wednesday, September 19, 2018 4:29 PM
To: davem@davemloft.net; Yelena Krivosheev <yelena@marvell.com>
Cc: Antoine Tenart <antoine.tenart@bootlin.com>; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; thomas.petazzoni@bootlin.com; maxime.chevallier@bootlin.com; gregory.clement@bootlin.com; miquel.raynal@bootlin.com; Nadav Haklai <nadavh@marvell.com>; Stefan Chulski <stefanc@marvell.com>; Yan Markman <ymarkman@marvell.com>; mw@semihalf.com
Subject: [EXT] [PATCH net] net: mvneta: fix the Rx desc buffer DMA unmapping
External Email
----------------------------------------------------------------------
With CONFIG_DMA_API_DEBUG enabled we now get a warning when using the mvneta driver:
mvneta d0030000.ethernet: DMA-API: device driver frees DMA memory with
wrong function [device address=0x000000001165b000] [size=4096 bytes]
[mapped as page] [unmapped as single]
This is because when using the s/w buffer management, the Rx descriptor buffer is mapped with dma_map_page but unmapped with dma_unmap_single.
This patch fixes this by using the right unmapping function.
Fixes: 562e2f467e71 ("net: mvneta: Improve the buffer allocation method for SWBM")
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
drivers/net/ethernet/marvell/mvneta.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index bc80a678abc3..2db9708f2e24 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -2008,8 +2008,8 @@ static int mvneta_rx_swbm(struct napi_struct *napi,
skb_add_rx_frag(rxq->skb, frag_num, page,
frag_offset, frag_size,
PAGE_SIZE);
- dma_unmap_single(dev->dev.parent, phys_addr,
- PAGE_SIZE, DMA_FROM_DEVICE);
+ dma_unmap_page(dev->dev.parent, phys_addr,
+ PAGE_SIZE, DMA_FROM_DEVICE);
rxq->left_size -= frag_size;
}
} else {
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v7 4/4] gpiolib: Implement fast processing path in get/set array
From: Marek Szyprowski @ 2018-09-20 10:11 UTC (permalink / raw)
To: Janusz Krzysztofik, Linus Walleij
Cc: Jonathan Corbet, Miguel Ojeda Sandonis, Peter Korsgaard,
Peter Rosin, Ulf Hansson, Andrew Lunn, Florian Fainelli,
David S. Miller, Dominik Brodowski, Greg Kroah-Hartman,
Kishon Vijay Abraham I, Lars-Peter Clausen, Michael Hennerich,
Jonathan Cameron, Hartmut Knaack, Peter Meerwald-Stadler,
Jiri Slaby, Willy Tarreau, Geert Uytterhoeven
In-Reply-To: <20180902120144.6855-5-jmkrzyszt@gmail.com>
Hi All,
On 2018-09-02 14:01, Janusz Krzysztofik wrote:
> Certain GPIO descriptor arrays returned by gpio_get_array() may contain
> information on direct mapping of array members to pins of a single GPIO
> chip in hardware order. In such cases, bitmaps of values can be passed
> directly from/to the chip's .get/set_multiple() callbacks without
> wasting time on iterations.
>
> Add respective code to gpiod_get/set_array_bitmap_complex() functions.
> Pins not applicable for fast path are processed as before, skipping
> over the 'fast' ones.
>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
I've just noticed that this patch landed in today's linux-next. Sadly it
breaks booting of Exynos5250-based Samsung Snow Chromebook (ARM 32bit,
device-tree source arch/arm/boot/dts/exynos5250-snow.dts).
Booting hangs after detecting MMC cards. Reverting this patch fixes the
boot. I will try later to add some debugs and investigate it further what
really happens when booting hangs.
> ---
> Documentation/driver-api/gpio/board.rst | 15 ++++++
> Documentation/driver-api/gpio/consumer.rst | 8 +++
> drivers/gpio/gpiolib.c | 87 ++++++++++++++++++++++++++++--
> 3 files changed, 105 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/driver-api/gpio/board.rst b/Documentation/driver-api/gpio/board.rst
> index 2c112553df84..c66821e033c2 100644
> --- a/Documentation/driver-api/gpio/board.rst
> +++ b/Documentation/driver-api/gpio/board.rst
> @@ -193,3 +193,18 @@ And the table can be added to the board code as follows::
>
> The line will be hogged as soon as the gpiochip is created or - in case the
> chip was created earlier - when the hog table is registered.
> +
> +Arrays of pins
> +--------------
> +In addition to requesting pins belonging to a function one by one, a device may
> +also request an array of pins assigned to the function. The way those pins are
> +mapped to the device determines if the array qualifies for fast bitmap
> +processing. If yes, a bitmap is passed over get/set array functions directly
> +between a caller and a respective .get/set_multiple() callback of a GPIO chip.
> +
> +In order to qualify for fast bitmap processing, the pin mapping must meet the
> +following requirements:
> +- it must belong to the same chip as other 'fast' pins of the function,
> +- its index within the function must match its hardware number within the chip.
> +
> +Open drain and open source pins are excluded from fast bitmap output processing.
> diff --git a/Documentation/driver-api/gpio/consumer.rst b/Documentation/driver-api/gpio/consumer.rst
> index 0afd95a12b10..cf992e5ab976 100644
> --- a/Documentation/driver-api/gpio/consumer.rst
> +++ b/Documentation/driver-api/gpio/consumer.rst
> @@ -388,6 +388,14 @@ array_info should be set to NULL.
> Note that for optimal performance GPIOs belonging to the same chip should be
> contiguous within the array of descriptors.
>
> +Still better performance may be achieved if array indexes of the descriptors
> +match hardware pin numbers of a single chip. If an array passed to a get/set
> +array function matches the one obtained from gpiod_get_array() and array_info
> +associated with the array is also passed, the function may take a fast bitmap
> +processing path, passing the value_bitmap argument directly to the respective
> +.get/set_multiple() callback of the chip. That allows for utilization of GPIO
> +banks as data I/O ports without much loss of performance.
> +
> The return value of gpiod_get_array_value() and its variants is 0 on success
> or negative on error. Note the difference to gpiod_get_value(), which returns
> 0 or 1 on success to convey the GPIO value. With the array functions, the GPIO
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index cef6ee31fe05..b9d083fb13ee 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -2789,7 +2789,36 @@ int gpiod_get_array_value_complex(bool raw, bool can_sleep,
> struct gpio_array *array_info,
> unsigned long *value_bitmap)
> {
> - int i = 0;
> + int err, i = 0;
> +
> + /*
> + * Validate array_info against desc_array and its size.
> + * It should immediately follow desc_array if both
> + * have been obtained from the same gpiod_get_array() call.
> + */
> + if (array_info && array_info->desc == desc_array &&
> + array_size <= array_info->size &&
> + (void *)array_info == desc_array + array_info->size) {
> + if (!can_sleep)
> + WARN_ON(array_info->chip->can_sleep);
> +
> + err = gpio_chip_get_multiple(array_info->chip,
> + array_info->get_mask,
> + value_bitmap);
> + if (err)
> + return err;
> +
> + if (!raw && !bitmap_empty(array_info->invert_mask, array_size))
> + bitmap_xor(value_bitmap, value_bitmap,
> + array_info->invert_mask, array_size);
> +
> + if (bitmap_full(array_info->get_mask, array_size))
> + return 0;
> +
> + i = find_first_zero_bit(array_info->get_mask, array_size);
> + } else {
> + array_info = NULL;
> + }
>
> while (i < array_size) {
> struct gpio_chip *chip = desc_array[i]->gdev->chip;
> @@ -2820,7 +2849,12 @@ int gpiod_get_array_value_complex(bool raw, bool can_sleep,
> int hwgpio = gpio_chip_hwgpio(desc);
>
> __set_bit(hwgpio, mask);
> - i++;
> +
> + if (array_info)
> + find_next_zero_bit(array_info->get_mask,
> + array_size, i);
> + else
> + i++;
> } while ((i < array_size) &&
> (desc_array[i]->gdev->chip == chip));
>
> @@ -2831,7 +2865,7 @@ int gpiod_get_array_value_complex(bool raw, bool can_sleep,
> return ret;
> }
>
> - for (j = first; j < i; j++) {
> + for (j = first; j < i; ) {
> const struct gpio_desc *desc = desc_array[j];
> int hwgpio = gpio_chip_hwgpio(desc);
> int value = test_bit(hwgpio, bits);
> @@ -2840,6 +2874,11 @@ int gpiod_get_array_value_complex(bool raw, bool can_sleep,
> value = !value;
> __assign_bit(j, value_bitmap, value);
> trace_gpio_value(desc_to_gpio(desc), 1, value);
> +
> + if (array_info)
> + find_next_zero_bit(array_info->get_mask, i, j);
> + else
> + j++;
> }
>
> if (mask != fastpath)
> @@ -3041,6 +3080,32 @@ int gpiod_set_array_value_complex(bool raw, bool can_sleep,
> {
> int i = 0;
>
> + /*
> + * Validate array_info against desc_array and its size.
> + * It should immediately follow desc_array if both
> + * have been obtained from the same gpiod_get_array() call.
> + */
> + if (array_info && array_info->desc == desc_array &&
> + array_size <= array_info->size &&
> + (void *)array_info == desc_array + array_info->size) {
> + if (!can_sleep)
> + WARN_ON(array_info->chip->can_sleep);
> +
> + if (!raw && !bitmap_empty(array_info->invert_mask, array_size))
> + bitmap_xor(value_bitmap, value_bitmap,
> + array_info->invert_mask, array_size);
> +
> + gpio_chip_set_multiple(array_info->chip, array_info->set_mask,
> + value_bitmap);
> +
> + if (bitmap_full(array_info->set_mask, array_size))
> + return 0;
> +
> + i = find_first_zero_bit(array_info->set_mask, array_size);
> + } else {
> + array_info = NULL;
> + }
> +
> while (i < array_size) {
> struct gpio_chip *chip = desc_array[i]->gdev->chip;
> unsigned long fastpath[2 * BITS_TO_LONGS(FASTPATH_NGPIO)];
> @@ -3068,7 +3133,14 @@ int gpiod_set_array_value_complex(bool raw, bool can_sleep,
> int hwgpio = gpio_chip_hwgpio(desc);
> int value = test_bit(i, value_bitmap);
>
> - if (!raw && test_bit(FLAG_ACTIVE_LOW, &desc->flags))
> + /*
> + * Pins applicable for fast input but not for
> + * fast output processing may have been already
> + * inverted inside the fast path, skip them.
> + */
> + if (!raw && !(array_info &&
> + test_bit(i, array_info->invert_mask)) &&
> + test_bit(FLAG_ACTIVE_LOW, &desc->flags))
> value = !value;
> trace_gpio_value(desc_to_gpio(desc), 0, value);
> /*
> @@ -3087,7 +3159,12 @@ int gpiod_set_array_value_complex(bool raw, bool can_sleep,
> __clear_bit(hwgpio, bits);
> count++;
> }
> - i++;
> +
> + if (array_info)
> + find_next_zero_bit(array_info->set_mask,
> + array_size, i);
> + else
> + i++;
> } while ((i < array_size) &&
> (desc_array[i]->gdev->chip == chip));
> /* push collected bits to outputs */
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH net] net: mscc: fix the frame extraction into the skb
From: Antoine Tenart @ 2018-09-20 10:08 UTC (permalink / raw)
To: davem
Cc: Antoine Tenart, netdev, linux-kernel, thomas.petazzoni,
alexandre.belloni, quentin.schulz, allan.nielsen
When extracting frames from the Ocelot switch, the frame check sequence
(FCS) is present at the end of the data extracted. The FCS was put into
the sk buffer which introduced some issues (as length related ones), as
the FCS shouldn't be part of an Rx sk buffer.
This patch fixes the Ocelot switch extraction behaviour by discarding
the FCS.
Fixes: a556c76adc05 ("net: mscc: Add initial Ocelot switch support")
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
Hi all,
Once this patch will be accepted and net merged into net-next, I'll
probably send another patch to fill skb->csum with the FCS based on
NETIF_F_RXFCS.
Thanks!
Antoine
drivers/net/ethernet/mscc/ocelot_board.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/mscc/ocelot_board.c b/drivers/net/ethernet/mscc/ocelot_board.c
index 26bb3b18f3be..3cdf63e35b53 100644
--- a/drivers/net/ethernet/mscc/ocelot_board.c
+++ b/drivers/net/ethernet/mscc/ocelot_board.c
@@ -91,7 +91,7 @@ static irqreturn_t ocelot_xtr_irq_handler(int irq, void *arg)
struct sk_buff *skb;
struct net_device *dev;
u32 *buf;
- int sz, len;
+ int sz, len, buf_len;
u32 ifh[4];
u32 val;
struct frame_info info;
@@ -116,14 +116,20 @@ static irqreturn_t ocelot_xtr_irq_handler(int irq, void *arg)
err = -ENOMEM;
break;
}
- buf = (u32 *)skb_put(skb, info.len);
+ buf_len = info.len - ETH_FCS_LEN;
+ buf = (u32 *)skb_put(skb, buf_len);
len = 0;
do {
sz = ocelot_rx_frame_word(ocelot, grp, false, &val);
*buf++ = val;
len += sz;
- } while ((sz == 4) && (len < info.len));
+ } while (len < buf_len);
+
+ /* Read the FCS and discard it */
+ sz = ocelot_rx_frame_word(ocelot, grp, false, &val);
+ /* Update the statistics if part of the FCS was read before */
+ len -= ETH_FCS_LEN - sz;
if (sz < 0) {
err = sz;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net] net: mvneta: fix the Rx desc buffer DMA unmapping
From: David Miller @ 2018-09-20 4:25 UTC (permalink / raw)
To: antoine.tenart
Cc: yelena, netdev, linux-kernel, thomas.petazzoni, maxime.chevallier,
gregory.clement, miquel.raynal, nadavh, stefanc, ymarkman, mw
In-Reply-To: <20180919132906.26868-1-antoine.tenart@bootlin.com>
From: Antoine Tenart <antoine.tenart@bootlin.com>
Date: Wed, 19 Sep 2018 15:29:06 +0200
> With CONFIG_DMA_API_DEBUG enabled we now get a warning when using the
> mvneta driver:
>
> mvneta d0030000.ethernet: DMA-API: device driver frees DMA memory with
> wrong function [device address=0x000000001165b000] [size=4096 bytes]
> [mapped as page] [unmapped as single]
>
> This is because when using the s/w buffer management, the Rx descriptor
> buffer is mapped with dma_map_page but unmapped with dma_unmap_single.
> This patch fixes this by using the right unmapping function.
>
> Fixes: 562e2f467e71 ("net: mvneta: Improve the buffer allocation method for SWBM")
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] ip6_tunnel: be careful when accessing the inner header
From: David Miller @ 2018-09-20 4:25 UTC (permalink / raw)
To: pabeni; +Cc: netdev, glider
In-Reply-To: <78ef06b7731007ff16b00962c58f36f87d689d65.1537362057.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Wed, 19 Sep 2018 15:02:07 +0200
> the ip6 tunnel xmit ndo assumes that the processed skb always
> contains an ip[v6] header, but syzbot has found a way to send
> frames that fall short of this assumption, leading to the following splat:
...
> This change addresses the issue adding the needed check before
> accessing the inner header.
>
> The ipv4 side of the issue is apparently there since the ipv4 over ipv6
> initial support, and the ipv6 side predates git history.
>
> Fixes: c4d3efafcc93 ("[IPV6] IP6TUNNEL: Add support to IPv4 over IPv6 tunnel.")
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Reported-by: syzbot+3fde91d4d394747d6db4@syzkaller.appspotmail.com
> Tested-by: Alexander Potapenko <glider@google.com>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: Allow the l3mdev to be a loopback
From: David Miller @ 2018-09-20 4:23 UTC (permalink / raw)
To: dsahern; +Cc: mmanning, netdev, rshearma
In-Reply-To: <bd5d267a-f419-4735-bdf1-eee2a1f7135d@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Wed, 19 Sep 2018 10:19:05 -0700
> On 9/19/18 5:56 AM, Mike Manning wrote:
>> From: Robert Shearman <rshearma@vyatta.att-mail.com>
>>
>> There is no way currently for an IPv6 client connect using a loopback
>> address in a VRF, whereas for IPv4 the loopback address can be added:
>>
>> $ sudo ip addr add dev vrfred 127.0.0.1/8
>> $ sudo ip -6 addr add ::1/128 dev vrfred
>> RTNETLINK answers: Cannot assign requested address
>>
>> So allow ::1 to be configured on an L3 master device. In order for
>> this to be usable ip_route_output_flags needs to not consider ::1 to
>> be a link scope address (since oif == l3mdev and so it would be
>> dropped), and ipv6_rcv needs to consider the l3mdev to be a loopback
>> device so that it doesn't drop the packets.
>>
>> Signed-off-by: Robert Shearman <rshearma@vyatta.att-mail.com>
>> Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
>> ---
>> net/ipv6/addrconf.c | 1 +
>> net/ipv6/ip6_input.c | 3 ++-
>> net/ipv6/route.c | 3 ++-
>> 3 files changed, 5 insertions(+), 2 deletions(-)
>>
>
> Reviewed-by: David Ahern <dsahern@gmail.com>
>
> Been on my to-do list for a while. Thanks for the patch. This resolves,
> for example, a harmless error message from the 'host' command from
> bind9-host-9.10.3 which probes for dscp support via the loopback
> address. e.g.,
>
> $ host www.google.com
> ../../../../lib/isc/unix/net.c:581: sendmsg() failed: Network is unreachable
Applied, thanks everyone.
^ 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