* Re: [PATCH net-next 2/2] mlx5: fix type mismatch
From: Arnd Bergmann @ 2019-09-10 19:51 UTC (permalink / raw)
To: Saeed Mahameed
Cc: dledford@redhat.com, davem@davemloft.net, jgg@ziepe.ca,
leon@kernel.org, linux-rdma@vger.kernel.org, Yishai Hadas,
Mark Bloch, linux-kernel@vger.kernel.org, Erez Shitrit,
netdev@vger.kernel.org, Alex Vesker, Ariel Levkovich,
Nathan Chancellor
In-Reply-To: <8311cb643690d3e80dddd5d4f2f6a7d923b9fbbc.camel@mellanox.com>
On Tue, Sep 10, 2019 at 7:56 PM Saeed Mahameed <saeedm@mellanox.com> wrote:
>
> On Mon, 2019-09-09 at 21:50 +0200, Arnd Bergmann wrote:
> > In mlx5, pointers to 'phys_addr_t' and 'u64' are mixed since the
> > addition
> > of the pool memory allocator, leading to incorrect behavior on 32-bit
> > architectures and this compiler warning:
> >
> > drivers/net/ethernet/mellanox/mlx5/core/steering/dr_icm_pool.c:121:8:
> > error: incompatible pointer types passing 'u64 *' (aka 'unsigned long
> > long *') to parameter of type 'phys_addr_t *' (aka 'unsigned int *')
> > [-Werror,-Wincompatible-pointer-types]
> > &icm_mr->dm.addr, &icm_mr-
> > >dm.obj_id);
> > ^~~~~~~~~~~~~~~~
> > include/linux/mlx5/driver.h:1092:39: note: passing argument to
> > parameter 'addr' here
> > u64 length, u16 uid, phys_addr_t *addr, u32
> > *obj_id);
> >
> > Change the code to use 'u64' consistently in place of 'phys_addr_t'
> > to
> > fix this. The alternative of using phys_addr_t more would require a
> > larger
> > rework.
> >
> > Fixes: 29cf8febd185 ("net/mlx5: DR, ICM pool memory allocator")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Hi Arnd,
>
> Nathan Chancellor Already submitted a patch to fix this and it is more
> minimal:
> https://patchwork.ozlabs.org/patch/1158177/
>
> I would like to use that patch if it is ok with you..
Yes, please do. I think I had tried something like that
initially and concluded it wasn't quite right before I went
into a different direction with my patch.
Looking at the two versions now, I also prefer Nathan's,
and I just confirmed that it fixes all the randconfig failures
I ran into.
Arnd
^ permalink raw reply
* Re: [PATCH net 1/2] sctp: remove redundant assignment when call sctp_get_port_local
From: Dan Carpenter @ 2019-09-10 19:22 UTC (permalink / raw)
To: Mao Wenan
Cc: vyasevich, nhorman, marcelo.leitner, davem, linux-sctp, netdev,
linux-kernel, kernel-janitors
In-Reply-To: <20190910185710.GF15977@kadam>
On Tue, Sep 10, 2019 at 09:57:10PM +0300, Dan Carpenter wrote:
> On Tue, Sep 10, 2019 at 03:13:42PM +0800, Mao Wenan wrote:
> > There are more parentheses in if clause when call sctp_get_port_local
> > in sctp_do_bind, and redundant assignment to 'ret'. This patch is to
> > do cleanup.
> >
> > Signed-off-by: Mao Wenan <maowenan@huawei.com>
> > ---
> > net/sctp/socket.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> > index 9d1f83b10c0a..766b68b55ebe 100644
> > --- a/net/sctp/socket.c
> > +++ b/net/sctp/socket.c
> > @@ -399,9 +399,8 @@ static int sctp_do_bind(struct sock *sk, union sctp_addr *addr, int len)
> > * detection.
> > */
> > addr->v4.sin_port = htons(snum);
> > - if ((ret = sctp_get_port_local(sk, addr))) {
> > + if (sctp_get_port_local(sk, addr))
> > return -EADDRINUSE;
>
> sctp_get_port_local() returns a long which is either 0,1 or a pointer
> casted to long. It's not documented what it means and neither of the
> callers use the return since commit 62208f12451f ("net: sctp: simplify
> sctp_get_port").
Actually it was commit 4e54064e0a13 ("sctp: Allow only 1 listening
socket with SO_REUSEADDR") from 11 years ago. That patch fixed a bug,
because before the code assumed that a pointer casted to an int was the
same as a pointer casted to a long.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH net-next 03/11] net: aquantia: add basic ptp_clock callbacks
From: Andrew Lunn @ 2019-09-10 19:20 UTC (permalink / raw)
To: Igor Russkikh
Cc: netdev@vger.kernel.org, richardcochran@gmail.com,
davem@davemloft.net, Egor Pomozov, Sergey Samoilenko,
Dmitry Bezrukov
In-Reply-To: <8868449ec5508f498131ee141399149bf801ea94.1568034880.git.igor.russkikh@aquantia.com>
> +static s64 ptp_clk_offset;
> +static void hw_atl_b0_get_ptp_ts(struct aq_hw_s *self, u64 *stamp)
> +{
> + u64 ns;
> +
> + hw_atl_pcs_ptp_clock_read_enable(self, 1);
> + hw_atl_pcs_ptp_clock_read_enable(self, 0);
> + ns = (get_ptp_ts_val_u64(self, 0) +
> + (get_ptp_ts_val_u64(self, 1) << 16)) * 1000000000llu +
> + (get_ptp_ts_val_u64(self, 3) +
> + (get_ptp_ts_val_u64(self, 4) << 16));
> +
> + *stamp = ns + ptp_clk_offset;
> +}
> +
> +static void hw_atl_b0_adj_params_get(u64 freq, s64 adj, u32 *ns, u32 *fns)
> +{
> + /* For accuracy, the digit is extended */
> + s64 divisor = 0, base_ns = ((adj + 1000000000ll) * 1000000000ll) / freq;
> + u32 nsi_frac = 0, nsi = base_ns / 1000000000ll;
> +
> + if (base_ns != nsi * 1000000000ll) {
> + divisor = 1000000000000000000ll /
> + (base_ns - nsi * 1000000000ll);
> + nsi_frac = 0x100000000ll * 1000000000ll / divisor;
> + }
> +
> + *ns = nsi;
> + *fns = nsi_frac;
> +}
> +
> +static int hw_atl_b0_adj_sys_clock(struct aq_hw_s *self, s64 delta)
> +{
> + ptp_clk_offset += delta;
> +
> + return 0;
> +}
Does this work when i have a box with 42 NICs in it? Does not each NIC
need its own clock offset? Just seeing code like this causes alarm
bells. So if it is correct, i would expect some sort of comment to
prevent those alarm bells.
Andrew
> +
> +static int hw_atl_b0_set_sys_clock(struct aq_hw_s *self, u64 time, u64 ts)
> +{
> + s64 delta = time - (ptp_clk_offset + ts);
> +
> + return hw_atl_b0_adj_sys_clock(self, delta);
> +}
> +
> +static int hw_atl_b0_adj_clock_freq(struct aq_hw_s *self, s32 ppb)
> +{
> + struct hw_fw_request_iface fwreq;
> + size_t size;
> +
> + memset(&fwreq, 0, sizeof(fwreq));
> +
> + fwreq.msg_id = HW_AQ_FW_REQUEST_PTP_ADJ_FREQ;
> + hw_atl_b0_adj_params_get(AQ_HW_MAC_COUNTER_HZ, ppb,
> + &fwreq.ptp_adj_freq.ns_mac,
> + &fwreq.ptp_adj_freq.fns_mac);
> + hw_atl_b0_adj_params_get(AQ_HW_PHY_COUNTER_HZ, ppb,
> + &fwreq.ptp_adj_freq.ns_phy,
> + &fwreq.ptp_adj_freq.fns_phy);
> + hw_atl_b0_mac_adj_param_calc(&fwreq.ptp_adj_freq,
> + AQ_HW_PHY_COUNTER_HZ,
> + AQ_HW_MAC_COUNTER_HZ);
> +
> + size = sizeof(fwreq.msg_id) + sizeof(fwreq.ptp_adj_freq);
> + return self->aq_fw_ops->send_fw_request(self, &fwreq, size);
> +}
> +
> static int hw_atl_b0_hw_fl3l4_clear(struct aq_hw_s *self,
> struct aq_rx_filter_l3l4 *data)
> {
> @@ -1164,6 +1256,12 @@ const struct aq_hw_ops hw_atl_ops_b0 = {
> .hw_get_regs = hw_atl_utils_hw_get_regs,
> .hw_get_hw_stats = hw_atl_utils_get_hw_stats,
> .hw_get_fw_version = hw_atl_utils_get_fw_version,
> - .hw_set_offload = hw_atl_b0_hw_offload_set,
> +
> + .hw_get_ptp_ts = hw_atl_b0_get_ptp_ts,
> + .hw_adj_sys_clock = hw_atl_b0_adj_sys_clock,
> + .hw_set_sys_clock = hw_atl_b0_set_sys_clock,
> + .hw_adj_clock_freq = hw_atl_b0_adj_clock_freq,
> +
> + .hw_set_offload = hw_atl_b0_hw_offload_set,
> .hw_set_fc = hw_atl_b0_set_fc,
> };
> diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh.c b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh.c
> index 1149812ae463..25e7261f6a44 100644
> --- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh.c
> +++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh.c
> @@ -1,7 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0-only
> /*
> * aQuantia Corporation Network Driver
> - * Copyright (C) 2014-2017 aQuantia Corporation. All rights reserved
> + * Copyright (C) 2014-2019 aQuantia Corporation. All rights reserved
> */
>
> /* File hw_atl_llh.c: Definitions of bitfield and register access functions for
> @@ -1513,6 +1513,20 @@ void hw_atl_reg_glb_cpu_scratch_scp_set(struct aq_hw_s *aq_hw,
> glb_cpu_scratch_scp);
> }
>
> +void hw_atl_pcs_ptp_clock_read_enable(struct aq_hw_s *aq_hw,
> + u32 ptp_clock_read_enable)
> +{
> + aq_hw_write_reg_bit(aq_hw, HW_ATL_PCS_PTP_CLOCK_READ_ENABLE_ADR,
> + HW_ATL_PCS_PTP_CLOCK_READ_ENABLE_MSK,
> + HW_ATL_PCS_PTP_CLOCK_READ_ENABLE_SHIFT,
> + ptp_clock_read_enable);
> +}
> +
> +u32 hw_atl_pcs_ptp_clock_get(struct aq_hw_s *aq_hw, u32 index)
> +{
> + return aq_hw_read_reg(aq_hw, HW_ATL_PCS_PTP_TS_VAL_ADDR(index));
> +}
> +
> void hw_atl_mcp_up_force_intr_set(struct aq_hw_s *aq_hw, u32 up_force_intr)
> {
> aq_hw_write_reg_bit(aq_hw, HW_ATL_MCP_UP_FORCE_INTERRUPT_ADR,
> diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh.h b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh.h
> index 0c37abbabca5..a62693e51a6b 100644
> --- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh.h
> +++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh.h
> @@ -1,7 +1,7 @@
> /* SPDX-License-Identifier: GPL-2.0-only */
> /*
> * aQuantia Corporation Network Driver
> - * Copyright (C) 2014-2017 aQuantia Corporation. All rights reserved
> + * Copyright (C) 2014-2019 aQuantia Corporation. All rights reserved
> */
>
> /* File hw_atl_llh.h: Declarations of bitfield and register access functions for
> @@ -712,6 +712,12 @@ void hw_atl_msm_reg_wr_strobe_set(struct aq_hw_s *aq_hw, u32 reg_wr_strobe);
> /* set pci register reset disable */
> void hw_atl_pci_pci_reg_res_dis_set(struct aq_hw_s *aq_hw, u32 pci_reg_res_dis);
>
> +/* pcs */
> +void hw_atl_pcs_ptp_clock_read_enable(struct aq_hw_s *aq_hw,
> + u32 ptp_clock_read_enable);
> +
> +u32 hw_atl_pcs_ptp_clock_get(struct aq_hw_s *aq_hw, u32 index);
> +
> /* set uP Force Interrupt */
> void hw_atl_mcp_up_force_intr_set(struct aq_hw_s *aq_hw, u32 up_force_intr);
>
> diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh_internal.h b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh_internal.h
> index c3febcdfa92e..7716e0fc22b5 100644
> --- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh_internal.h
> +++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh_internal.h
> @@ -1,7 +1,7 @@
> /* SPDX-License-Identifier: GPL-2.0-only */
> /*
> * aQuantia Corporation Network Driver
> - * Copyright (C) 2014-2017 aQuantia Corporation. All rights reserved
> + * Copyright (C) 2014-2019 aQuantia Corporation. All rights reserved
> */
>
> /* File hw_atl_llh_internal.h: Preprocessor definitions
> @@ -2421,6 +2421,22 @@
> /* default value of bitfield register write strobe */
> #define HW_ATL_MSM_REG_WR_STROBE_DEFAULT 0x0
>
> +/* register address for bitfield PTP Digital Clock Read Enable */
> +#define HW_ATL_PCS_PTP_CLOCK_READ_ENABLE_ADR 0x00004628
> +/* bitmask for bitfield PTP Digital Clock Read Enable */
> +#define HW_ATL_PCS_PTP_CLOCK_READ_ENABLE_MSK 0x00000010
> +/* inverted bitmask for bitfield PTP Digital Clock Read Enable */
> +#define HW_ATL_PCS_PTP_CLOCK_READ_ENABLE_MSKN 0xFFFFFFEF
> +/* lower bit position of bitfield PTP Digital Clock Read Enable */
> +#define HW_ATL_PCS_PTP_CLOCK_READ_ENABLE_SHIFT 4
> +/* width of bitfield PTP Digital Clock Read Enable */
> +#define HW_ATL_PCS_PTP_CLOCK_READ_ENABLE_WIDTH 1
> +/* default value of bitfield PTP Digital Clock Read Enable */
> +#define HW_ATL_PCS_PTP_CLOCK_READ_ENABLE_DEFAULT 0x0
> +
> +/* register address for ptp counter reading */
> +#define HW_ATL_PCS_PTP_TS_VAL_ADDR(index) (0x00004900 + (index) * 0x4)
> +
> /* mif soft reset bitfield definitions
> * preprocessor definitions for the bitfield "soft reset".
> * port="pif_glb_res_i"
> diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
> index 32512539ae86..6fc5640065bd 100644
> --- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
> +++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
> @@ -327,8 +327,7 @@ int hw_atl_utils_fw_downld_dwords(struct aq_hw_s *self, u32 a,
> return err;
> }
>
> -static int hw_atl_utils_fw_upload_dwords(struct aq_hw_s *self, u32 a, u32 *p,
> - u32 cnt)
> +int hw_atl_utils_fw_upload_dwords(struct aq_hw_s *self, u32 a, u32 *p, u32 cnt)
> {
> u32 val;
> int err = 0;
> @@ -964,4 +963,6 @@ const struct aq_fw_ops aq_fw_1x_ops = {
> .set_eee_rate = NULL,
> .get_eee_rate = NULL,
> .set_flow_control = NULL,
> + .send_fw_request = NULL,
> + .enable_ptp = NULL,
> };
> diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.h b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.h
> index 766e02c7fd4e..f2eb94f298e2 100644
> --- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.h
> +++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.h
> @@ -279,6 +279,34 @@ struct __packed offload_info {
> u8 buf[0];
> };
>
> +/* Mailbox FW Request interface */
> +struct __packed hw_fw_request_ptp_adj_freq {
> + u32 ns_mac;
> + u32 fns_mac;
> + u32 ns_phy;
> + u32 fns_phy;
> + u32 mac_ns_adj;
> + u32 mac_fns_adj;
> +};
> +
> +struct __packed hw_fw_request_ptp_adj_clock {
> + u32 ns;
> + u32 sec;
> + int sign;
> +};
> +
> +#define HW_AQ_FW_REQUEST_PTP_ADJ_FREQ 0x12
> +#define HW_AQ_FW_REQUEST_PTP_ADJ_CLOCK 0x13
> +
> +struct __packed hw_fw_request_iface {
> + u32 msg_id;
> + union {
> + /* PTP FW Request */
> + struct hw_fw_request_ptp_adj_freq ptp_adj_freq;
> + struct hw_fw_request_ptp_adj_clock ptp_adj_clock;
> + };
> +};
> +
> enum hw_atl_rx_action_with_traffic {
> HW_ATL_RX_DISCARD,
> HW_ATL_RX_HOST,
> @@ -561,6 +589,8 @@ struct aq_stats_s *hw_atl_utils_get_hw_stats(struct aq_hw_s *self);
> int hw_atl_utils_fw_downld_dwords(struct aq_hw_s *self, u32 a,
> u32 *p, u32 cnt);
>
> +int hw_atl_utils_fw_upload_dwords(struct aq_hw_s *self, u32 a, u32 *p, u32 cnt);
> +
> int hw_atl_utils_fw_set_wol(struct aq_hw_s *self, bool wol_enabled, u8 *mac);
>
> int hw_atl_utils_fw_rpc_call(struct aq_hw_s *self, unsigned int rpc_size);
> diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c
> index da726489e3c8..8b9824b1dc5e 100644
> --- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c
> +++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c
> @@ -1,7 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0-only
> /*
> * aQuantia Corporation Network Driver
> - * Copyright (C) 2014-2017 aQuantia Corporation. All rights reserved
> + * Copyright (C) 2014-2019 aQuantia Corporation. All rights reserved
> */
>
> /* File hw_atl_utils_fw2x.c: Definition of firmware 2.x functions for
> @@ -17,14 +17,17 @@
> #include "hw_atl_utils.h"
> #include "hw_atl_llh.h"
>
> -#define HW_ATL_FW2X_MPI_RPC_ADDR 0x334
> +#define HW_ATL_FW2X_MPI_RPC_ADDR 0x334
>
> -#define HW_ATL_FW2X_MPI_MBOX_ADDR 0x360
> -#define HW_ATL_FW2X_MPI_EFUSE_ADDR 0x364
> -#define HW_ATL_FW2X_MPI_CONTROL_ADDR 0x368
> -#define HW_ATL_FW2X_MPI_CONTROL2_ADDR 0x36C
> -#define HW_ATL_FW2X_MPI_STATE_ADDR 0x370
> -#define HW_ATL_FW2X_MPI_STATE2_ADDR 0x374
> +#define HW_ATL_FW2X_MPI_MBOX_ADDR 0x360
> +#define HW_ATL_FW2X_MPI_EFUSE_ADDR 0x364
> +#define HW_ATL_FW2X_MPI_CONTROL_ADDR 0x368
> +#define HW_ATL_FW2X_MPI_CONTROL2_ADDR 0x36C
> +#define HW_ATL_FW2X_MPI_STATE_ADDR 0x370
> +#define HW_ATL_FW2X_MPI_STATE2_ADDR 0x374
> +
> +#define HW_ATL_FW3X_EXT_CONTROL_ADDR 0x378
> +#define HW_ATL_FW3X_EXT_STATE_ADDR 0x37c
>
> #define HW_ATL_FW2X_CAP_PAUSE BIT(CAPS_HI_PAUSE)
> #define HW_ATL_FW2X_CAP_ASYM_PAUSE BIT(CAPS_HI_ASYMMETRIC_PAUSE)
> @@ -444,6 +447,54 @@ static int aq_fw2x_set_power(struct aq_hw_s *self, unsigned int power_state,
> return err;
> }
>
> +static int aq_fw2x_send_fw_request(struct aq_hw_s *self,
> + const struct hw_fw_request_iface *fw_req,
> + size_t size)
> +{
> + u32 ctrl2, orig_ctrl2;
> + u32 dword_cnt;
> + int err = 0;
> + u32 val;
> +
> + /* Write data to drvIface Mailbox */
> + dword_cnt = size / sizeof(u32);
> + if (size % sizeof(u32))
> + dword_cnt++;
> + err = hw_atl_utils_fw_upload_dwords(self, aq_fw2x_rpc_get(self),
> + (void *)fw_req, dword_cnt);
> + if (err < 0)
> + goto err_exit;
> +
> + /* Toggle statistics bit for FW to update */
> + ctrl2 = aq_hw_read_reg(self, HW_ATL_FW2X_MPI_CONTROL2_ADDR);
> + orig_ctrl2 = ctrl2 & BIT(CAPS_HI_FW_REQUEST);
> + ctrl2 = ctrl2 ^ BIT(CAPS_HI_FW_REQUEST);
> + aq_hw_write_reg(self, HW_ATL_FW2X_MPI_CONTROL2_ADDR, ctrl2);
> +
> + /* Wait FW to report back */
> + err = readx_poll_timeout_atomic(aq_fw2x_state2_get, self, val,
> + orig_ctrl2 != (val &
> + BIT(CAPS_HI_FW_REQUEST)),
> + 1U, 10000U);
> +
> +err_exit:
> + return err;
> +}
> +
> +static void aq_fw3x_enable_ptp(struct aq_hw_s *self, int enable)
> +{
> + u32 ptp_opts = aq_hw_read_reg(self, HW_ATL_FW3X_EXT_STATE_ADDR);
> + u32 all_ptp_features = BIT(CAPS_EX_PHY_PTP_EN) |
> + BIT(CAPS_EX_PTP_GPIO_EN);
> +
> + if (enable)
> + ptp_opts |= all_ptp_features;
> + else
> + ptp_opts &= ~all_ptp_features;
> +
> + aq_hw_write_reg(self, HW_ATL_FW3X_EXT_CONTROL_ADDR, ptp_opts);
> +}
> +
> static int aq_fw2x_set_eee_rate(struct aq_hw_s *self, u32 speed)
> {
> u32 mpi_opts = aq_hw_read_reg(self, HW_ATL_FW2X_MPI_CONTROL2_ADDR);
> @@ -534,19 +585,21 @@ static u32 aq_fw2x_state2_get(struct aq_hw_s *self)
> }
>
> const struct aq_fw_ops aq_fw_2x_ops = {
> - .init = aq_fw2x_init,
> - .deinit = aq_fw2x_deinit,
> - .reset = NULL,
> - .renegotiate = aq_fw2x_renegotiate,
> - .get_mac_permanent = aq_fw2x_get_mac_permanent,
> - .set_link_speed = aq_fw2x_set_link_speed,
> - .set_state = aq_fw2x_set_state,
> + .init = aq_fw2x_init,
> + .deinit = aq_fw2x_deinit,
> + .reset = NULL,
> + .renegotiate = aq_fw2x_renegotiate,
> + .get_mac_permanent = aq_fw2x_get_mac_permanent,
> + .set_link_speed = aq_fw2x_set_link_speed,
> + .set_state = aq_fw2x_set_state,
> .update_link_status = aq_fw2x_update_link_status,
> - .update_stats = aq_fw2x_update_stats,
> - .get_phy_temp = aq_fw2x_get_phy_temp,
> - .set_power = aq_fw2x_set_power,
> - .set_eee_rate = aq_fw2x_set_eee_rate,
> - .get_eee_rate = aq_fw2x_get_eee_rate,
> - .set_flow_control = aq_fw2x_set_flow_control,
> - .get_flow_control = aq_fw2x_get_flow_control
> + .update_stats = aq_fw2x_update_stats,
> + .get_phy_temp = aq_fw2x_get_phy_temp,
> + .set_power = aq_fw2x_set_power,
> + .set_eee_rate = aq_fw2x_set_eee_rate,
> + .get_eee_rate = aq_fw2x_get_eee_rate,
> + .set_flow_control = aq_fw2x_set_flow_control,
> + .get_flow_control = aq_fw2x_get_flow_control,
> + .send_fw_request = aq_fw2x_send_fw_request,
> + .enable_ptp = aq_fw3x_enable_ptp,
> };
> --
> 2.17.1
>
^ permalink raw reply
* Re: INFO: rcu detected stall in br_handle_frame
From: Cong Wang @ 2019-09-10 19:20 UTC (permalink / raw)
To: syzbot
Cc: David Miller, Jamal Hadi Salim, Jiri Pirko, LKML,
Linux Kernel Network Developers, syzkaller-bugs
In-Reply-To: <000000000000bcb83d059237c30a@google.com>
#syz fix: sch_hhf: ensure quantum and hhf_non_hh_weight are non-zero
^ permalink raw reply
* Re: INFO: rcu detected stall in addrconf_dad_work
From: Cong Wang @ 2019-09-10 19:20 UTC (permalink / raw)
To: syzbot
Cc: David Miller, Jamal Hadi Salim, Jiri Pirko, LKML,
Linux Kernel Network Developers, syzkaller-bugs
In-Reply-To: <000000000000c1391b059237c3a6@google.com>
#syz fix: sch_hhf: ensure quantum and hhf_non_hh_weight are non-zero
^ permalink raw reply
* INFO: rcu detected stall in br_handle_frame
From: syzbot @ 2019-09-10 19:18 UTC (permalink / raw)
To: davem, jhs, jiri, linux-kernel, netdev, syzkaller-bugs,
xiyou.wangcong
Hello,
syzbot found the following crash on:
HEAD commit: 3b47fd5c Merge tag 'nfs-for-5.3-4' of git://git.linux-nfs...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12983001600000
kernel config: https://syzkaller.appspot.com/x/.config?x=b89bb446a3faaba4
dashboard link: https://syzkaller.appspot.com/bug?extid=2addc1f058bd021b0a40
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17d8afae600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1253d1fa600000
Bisection is inconclusive: the bug happens on the oldest tested release.
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=109dcfc6600000
console output: https://syzkaller.appspot.com/x/log.txt?x=149dcfc6600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2addc1f058bd021b0a40@syzkaller.appspotmail.com
rcu: INFO: rcu_preempt self-detected stall on CPU
rcu: 0-...!: (10500 ticks this GP) idle=c4e/1/0x4000000000000002
softirq=10445/10445 fqs=0
(t=10500 jiffies g=10669 q=248)
rcu: rcu_preempt kthread starved for 10500 jiffies! g10669 f0x0
RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0
rcu: RCU grace-period kthread stack dump:
rcu_preempt I29392 10 2 0x80004000
Call Trace:
context_switch kernel/sched/core.c:3254 [inline]
__schedule+0x755/0x1580 kernel/sched/core.c:3880
schedule+0xd9/0x260 kernel/sched/core.c:3947
schedule_timeout+0x486/0xc50 kernel/time/timer.c:1807
rcu_gp_fqs_loop kernel/rcu/tree.c:1611 [inline]
rcu_gp_kthread+0x9b2/0x18c0 kernel/rcu/tree.c:1768
kthread+0x361/0x430 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
NMI backtrace for cpu 0
CPU: 0 PID: 9 Comm: ksoftirqd/0 Not tainted 5.3.0-rc7+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
nmi_cpu_backtrace.cold+0x70/0xb2 lib/nmi_backtrace.c:101
nmi_trigger_cpumask_backtrace+0x23b/0x28b lib/nmi_backtrace.c:62
arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
trigger_single_cpu_backtrace include/linux/nmi.h:164 [inline]
rcu_dump_cpu_stacks+0x183/0x1cf kernel/rcu/tree_stall.h:254
print_cpu_stall kernel/rcu/tree_stall.h:455 [inline]
check_cpu_stall kernel/rcu/tree_stall.h:529 [inline]
rcu_pending kernel/rcu/tree.c:2736 [inline]
rcu_sched_clock_irq.cold+0x4dd/0xc13 kernel/rcu/tree.c:2183
update_process_times+0x32/0x80 kernel/time/timer.c:1639
tick_sched_handle+0xa2/0x190 kernel/time/tick-sched.c:167
tick_sched_timer+0x53/0x140 kernel/time/tick-sched.c:1296
__run_hrtimer kernel/time/hrtimer.c:1389 [inline]
__hrtimer_run_queues+0x364/0xe40 kernel/time/hrtimer.c:1451
hrtimer_interrupt+0x314/0x770 kernel/time/hrtimer.c:1509
local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1106 [inline]
smp_apic_timer_interrupt+0x160/0x610 arch/x86/kernel/apic/apic.c:1131
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:830
</IRQ>
RIP: 0010:write_comp_data+0x68/0x70 kernel/kcov.c:147
Code: 00 00 4e 8d 14 dd 28 00 00 00 4d 39 d0 72 1b 49 83 c1 01 4a 89 7c 10
e0 4a 89 74 10 e8 4a 89 54 10 f0 4a 89 4c d8 20 4c 89 08 <c3> 0f 1f 80 00
00 00 00 55 40 0f b6 d6 40 0f b6 f7 31 ff 48 89 e5
RSP: 0018:ffff8880a98be990 EFLAGS: 00000206 ORIG_RAX: ffffffffffffff13
RAX: 0000000000000301 RBX: ffff88808c6eb0b8 RCX: ffffffff85c64b39
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000005
RBP: ffff8880a98be998 R08: ffff8880a98b2240 R09: 0000000000000000
R10: fffffbfff134af8f R11: ffff8880a98b2240 R12: dffffc0000000000
R13: ffff88808c6eadc0 R14: ffff88808c6eb150 R15: 0000000000000000
hhf_dequeue+0xb9/0xa20 net/sched/sch_hhf.c:434
dequeue_skb net/sched/sch_generic.c:258 [inline]
qdisc_restart net/sched/sch_generic.c:361 [inline]
__qdisc_run+0x1e7/0x19d0 net/sched/sch_generic.c:379
__dev_xmit_skb net/core/dev.c:3533 [inline]
__dev_queue_xmit+0x16f1/0x3650 net/core/dev.c:3838
dev_queue_xmit+0x18/0x20 net/core/dev.c:3902
br_dev_queue_push_xmit+0x3f3/0x5c0 net/bridge/br_forward.c:52
br_nf_dev_queue_xmit+0x34e/0x1470 net/bridge/br_netfilter_hooks.c:796
NF_HOOK include/linux/netfilter.h:305 [inline]
NF_HOOK include/linux/netfilter.h:299 [inline]
br_nf_post_routing+0x1502/0x1d30 net/bridge/br_netfilter_hooks.c:844
nf_hook_entry_hookfn include/linux/netfilter.h:135 [inline]
nf_hook_slow+0xbc/0x1e0 net/netfilter/core.c:512
nf_hook include/linux/netfilter.h:260 [inline]
NF_HOOK include/linux/netfilter.h:303 [inline]
br_forward_finish+0x215/0x400 net/bridge/br_forward.c:65
br_nf_hook_thresh+0x2e9/0x370 net/bridge/br_netfilter_hooks.c:1015
br_nf_forward_finish+0x66c/0xa90 net/bridge/br_netfilter_hooks.c:560
NF_HOOK include/linux/netfilter.h:305 [inline]
NF_HOOK include/linux/netfilter.h:299 [inline]
br_nf_forward_ip net/bridge/br_netfilter_hooks.c:630 [inline]
br_nf_forward_ip+0xc74/0x21e0 net/bridge/br_netfilter_hooks.c:571
nf_hook_entry_hookfn include/linux/netfilter.h:135 [inline]
nf_hook_slow+0xbc/0x1e0 net/netfilter/core.c:512
nf_hook include/linux/netfilter.h:260 [inline]
NF_HOOK include/linux/netfilter.h:303 [inline]
__br_forward+0x393/0xb00 net/bridge/br_forward.c:109
deliver_clone+0x61/0xc0 net/bridge/br_forward.c:125
br_flood+0x325/0x3d0 net/bridge/br_forward.c:232
br_handle_frame_finish+0xb46/0x1670 net/bridge/br_input.c:162
br_nf_hook_thresh+0x2e9/0x370 net/bridge/br_netfilter_hooks.c:1015
br_nf_pre_routing_finish_ipv6+0x6fb/0xd80
net/bridge/br_netfilter_ipv6.c:206
NF_HOOK include/linux/netfilter.h:305 [inline]
br_nf_pre_routing_ipv6+0x456/0x832 net/bridge/br_netfilter_ipv6.c:236
br_nf_pre_routing+0x1743/0x2355 net/bridge/br_netfilter_hooks.c:501
nf_hook_entry_hookfn include/linux/netfilter.h:135 [inline]
nf_hook_bridge_pre net/bridge/br_input.c:223 [inline]
br_handle_frame+0x806/0x133e net/bridge/br_input.c:348
__netif_receive_skb_core+0xfc1/0x3060 net/core/dev.c:4905
__netif_receive_skb_one_core+0xa8/0x1a0 net/core/dev.c:5002
__netif_receive_skb+0x2c/0x1d0 net/core/dev.c:5118
process_backlog+0x206/0x750 net/core/dev.c:5929
napi_poll net/core/dev.c:6352 [inline]
net_rx_action+0x4d6/0x1030 net/core/dev.c:6418
__do_softirq+0x262/0x98c kernel/softirq.c:292
run_ksoftirqd kernel/softirq.c:603 [inline]
run_ksoftirqd+0x8e/0x110 kernel/softirq.c:595
smpboot_thread_fn+0x6a3/0xa40 kernel/smpboot.c:165
kthread+0x361/0x430 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* INFO: rcu detected stall in addrconf_dad_work
From: syzbot @ 2019-09-10 19:18 UTC (permalink / raw)
To: davem, jhs, jiri, linux-kernel, netdev, syzkaller-bugs,
xiyou.wangcong
Hello,
syzbot found the following crash on:
HEAD commit: 3b47fd5c Merge tag 'nfs-for-5.3-4' of git://git.linux-nfs...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=126c0f51600000
kernel config: https://syzkaller.appspot.com/x/.config?x=b89bb446a3faaba4
dashboard link: https://syzkaller.appspot.com/bug?extid=0055e43d6f67fb9b8ba1
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1500264e600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16d7a46e600000
Bisection is inconclusive: the bug happens on the oldest tested release.
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=160261e1600000
console output: https://syzkaller.appspot.com/x/log.txt?x=110261e1600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+0055e43d6f67fb9b8ba1@syzkaller.appspotmail.com
rcu: INFO: rcu_preempt self-detected stall on CPU
rcu: 1-...!: (10499 ticks this GP) idle=e02/1/0x4000000000000002
softirq=9705/9705 fqs=4
(t=10500 jiffies g=9309 q=84)
rcu: rcu_preempt kthread starved for 10492 jiffies! g9309 f0x0
RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0
rcu: RCU grace-period kthread stack dump:
rcu_preempt R running task 29112 10 2 0x80004000
Call Trace:
context_switch kernel/sched/core.c:3254 [inline]
__schedule+0x755/0x1580 kernel/sched/core.c:3880
schedule+0xd9/0x260 kernel/sched/core.c:3947
schedule_timeout+0x486/0xc50 kernel/time/timer.c:1807
rcu_gp_fqs_loop kernel/rcu/tree.c:1611 [inline]
rcu_gp_kthread+0x9b2/0x18c0 kernel/rcu/tree.c:1768
kthread+0x361/0x430 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
NMI backtrace for cpu 1
CPU: 1 PID: 3027 Comm: kworker/1:2 Not tainted 5.3.0-rc7+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: ipv6_addrconf addrconf_dad_work
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
nmi_cpu_backtrace.cold+0x70/0xb2 lib/nmi_backtrace.c:101
nmi_trigger_cpumask_backtrace+0x23b/0x28b lib/nmi_backtrace.c:62
arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
trigger_single_cpu_backtrace include/linux/nmi.h:164 [inline]
rcu_dump_cpu_stacks+0x183/0x1cf kernel/rcu/tree_stall.h:254
print_cpu_stall kernel/rcu/tree_stall.h:455 [inline]
check_cpu_stall kernel/rcu/tree_stall.h:529 [inline]
rcu_pending kernel/rcu/tree.c:2736 [inline]
rcu_sched_clock_irq.cold+0x4dd/0xc13 kernel/rcu/tree.c:2183
update_process_times+0x32/0x80 kernel/time/timer.c:1639
tick_sched_handle+0xa2/0x190 kernel/time/tick-sched.c:167
tick_sched_timer+0x53/0x140 kernel/time/tick-sched.c:1296
__run_hrtimer kernel/time/hrtimer.c:1389 [inline]
__hrtimer_run_queues+0x364/0xe40 kernel/time/hrtimer.c:1451
hrtimer_interrupt+0x314/0x770 kernel/time/hrtimer.c:1509
local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1106 [inline]
smp_apic_timer_interrupt+0x160/0x610 arch/x86/kernel/apic/apic.c:1131
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:830
</IRQ>
RIP: 0010:__list_del_entry_valid+0x4b/0xf5 lib/list_debug.c:45
Code: 54 80 3c 02 00 0f 85 a1 00 00 00 4c 89 f2 4d 8b 66 08 48 b8 00 00 00
00 00 fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 9d 00 00 00 <48> b8 00 01 00
00 00 00 ad de 4d 8b 2e 49 39 c5 0f 84 e1 00 00 00
RSP: 0018:ffff88809ff26d30 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
RAX: dffffc0000000000 RBX: ffff88808c560778 RCX: ffffffff85c64b39
RDX: 1ffff110118ac0ef RSI: ffffffff85c65006 RDI: ffff88808c560780
RBP: ffff88809ff26d48 R08: ffff88809ff08300 R09: 0000000000000000
R10: fffffbfff134af8f R11: ffff88809ff08300 R12: ffff88808c560810
R13: ffff88808c560480 R14: ffff88808c560778 R15: 0000000000000000
__list_del_entry include/linux/list.h:131 [inline]
list_move_tail include/linux/list.h:213 [inline]
hhf_dequeue+0x5c5/0xa20 net/sched/sch_hhf.c:439
dequeue_skb net/sched/sch_generic.c:258 [inline]
qdisc_restart net/sched/sch_generic.c:361 [inline]
__qdisc_run+0x1e7/0x19d0 net/sched/sch_generic.c:379
__dev_xmit_skb net/core/dev.c:3533 [inline]
__dev_queue_xmit+0x16f1/0x3650 net/core/dev.c:3838
dev_queue_xmit+0x18/0x20 net/core/dev.c:3902
br_dev_queue_push_xmit+0x3f3/0x5c0 net/bridge/br_forward.c:52
NF_HOOK include/linux/netfilter.h:305 [inline]
NF_HOOK include/linux/netfilter.h:299 [inline]
br_forward_finish+0xfa/0x400 net/bridge/br_forward.c:65
NF_HOOK include/linux/netfilter.h:305 [inline]
NF_HOOK include/linux/netfilter.h:299 [inline]
__br_forward+0x641/0xb00 net/bridge/br_forward.c:109
deliver_clone+0x61/0xc0 net/bridge/br_forward.c:125
maybe_deliver+0x2c7/0x390 net/bridge/br_forward.c:181
br_flood+0x13a/0x3d0 net/bridge/br_forward.c:223
br_dev_xmit+0x98c/0x15a0 net/bridge/br_device.c:100
__netdev_start_xmit include/linux/netdevice.h:4406 [inline]
netdev_start_xmit include/linux/netdevice.h:4420 [inline]
xmit_one net/core/dev.c:3280 [inline]
dev_hard_start_xmit+0x1a3/0x9c0 net/core/dev.c:3296
__dev_queue_xmit+0x2b15/0x3650 net/core/dev.c:3869
dev_queue_xmit+0x18/0x20 net/core/dev.c:3902
neigh_resolve_output net/core/neighbour.c:1490 [inline]
neigh_resolve_output+0x5a5/0x970 net/core/neighbour.c:1470
neigh_output include/net/neighbour.h:511 [inline]
ip6_finish_output2+0x1034/0x2520 net/ipv6/ip6_output.c:116
__ip6_finish_output+0x444/0xa50 net/ipv6/ip6_output.c:142
ip6_finish_output+0x38/0x1f0 net/ipv6/ip6_output.c:152
NF_HOOK_COND include/linux/netfilter.h:294 [inline]
ip6_output+0x235/0x7c0 net/ipv6/ip6_output.c:175
dst_output include/net/dst.h:436 [inline]
NF_HOOK include/linux/netfilter.h:305 [inline]
ndisc_send_skb+0xf29/0x1450 net/ipv6/ndisc.c:504
ndisc_send_ns+0x3a9/0x850 net/ipv6/ndisc.c:646
addrconf_dad_work+0xb88/0x1150 net/ipv6/addrconf.c:4120
process_one_work+0x9af/0x1740 kernel/workqueue.c:2269
worker_thread+0x98/0xe40 kernel/workqueue.c:2415
kthread+0x361/0x430 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH] net/mlx5: reduce stack usage in FW tracer
From: Saeed Mahameed @ 2019-09-10 19:13 UTC (permalink / raw)
To: David.Laight@ACULAB.COM, arnd@arndb.de
Cc: cai@lca.pw, linux-rdma@vger.kernel.org, davem@davemloft.net,
Moshe Shemesh, Feras Daoud, linux-kernel@vger.kernel.org,
Eran Ben Elisha, netdev@vger.kernel.org, leon@kernel.org,
Erez Shitrit
In-Reply-To: <d50f78334e64476bad033862035c734c@AcuMS.aculab.com>
On Tue, 2019-09-10 at 15:38 +0000, David Laight wrote:
> From: Arnd Bergmann
> > Sent: 10 September 2019 09:15
> ...
> > > I am not sure how this would work, since the format parameters
> > > can
> > > changes depending on the FW string and the specific traces.
> >
> > Ah, so the format string comes from the firmware? I didn't look
> > at the code in enough detail to understand why it's done like this,
> > only enough to notice that it's rather unusual.
>
> If the format string comes from the firmware you really shouldn't
> pass it to any standard printf function.
> You must ensure that it doesn't contain any format effectors
> that might dereference parameters.
> (The code might try to do that.)
>
> Given that 'pointer' format effectors can't be used, the firmware
> must also supply the relevant integer ones?
> This should mean that all the processing is deferrable until the
> trace record is read.
>
Point taken, i will discuss this with the team next week, since i am
traveling this week. and we will provide a proper solution. for now,
off the top of my head, FW strings and parameters are well defined and
very simple, many of the problems here do not apply, but will verify.
> 'noinline' just papers over the cracks.
> Especially since vasprintf() is likely to use a lot of stack.
Right i also tend to agree with noinline as a temporary solution until
we address all the points provided here.
>
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes,
> MK1 1PT, UK
> Registration No: 1397386 (Wales)
^ permalink raw reply
* syzbot report in rsi_91x_usb.c
From: Julia Lawall @ 2019-09-10 19:11 UTC (permalink / raw)
To: amitkarwar, siva8118
Cc: syzkaller-bugs, kvalo, davem, linux-wireless, netdev,
linux-kernel
Hello,
I spent some time looking at:
https://syzkaller.appspot.com/bug?id=c1b6aa968706d9380dcdb98a9f2c338071cc938c
which does not yet report that it has been fixed.
The problem seems to be in rsi_probe in
drivers/net/wireless/rsi/rsi_91x_usb.c. This ends with the following
code:
status = rsi_rx_urb_submit(adapter, WLAN_EP);
if (status)
goto err1;
if (adapter->priv->coex_mode > 1) {
status = rsi_rx_urb_submit(adapter, BT_EP);
if (status)
goto err1;
}
return 0;
err1:
rsi_deinit_usb_interface(adapter);
err:
rsi_91x_deinit(adapter);
The problem seems to be that the first call to rsi_rx_urb_submit succeeds,
submitting an urb, and then theh second one fails. Both share adapter,
which is used in rsi_rx_done_handler, invoked later as the callback
provided with usb_submit_urb. But adapter, and in particular its rsi_dev
field, are freed by the rsi_91x_deinit call due to the failure of the
second call to rsi_rx_urb_submit.
How should this be fixed?
thanks,
julia
^ permalink raw reply
* Re: [PATCH net-next 01/11] net: aquantia: PTP skeleton declarations and callbacks
From: Andrew Lunn @ 2019-09-10 19:10 UTC (permalink / raw)
To: Igor Russkikh
Cc: netdev@vger.kernel.org, richardcochran@gmail.com,
davem@davemloft.net, Egor Pomozov, Sergey Samoilenko,
Dmitry Bezrukov
In-Reply-To: <cf60b1d3d797d0666a4828fcf5e521e0bd73f8d4.1568034880.git.igor.russkikh@aquantia.com>
On Mon, Sep 09, 2019 at 01:38:38PM +0000, Igor Russkikh wrote:
> From: Dmitry Bezrukov <dmitry.bezrukov@aquantia.com>
Hi Igor, et al.
> @@ -331,6 +332,10 @@ int aq_nic_init(struct aq_nic_s *self)
> self->aq_vecs > i; ++i, aq_vec = self->aq_vec[i])
> aq_vec_init(aq_vec, self->aq_hw_ops, self->aq_hw);
> +int aq_ptp_init(struct aq_nic_s *aq_nic, unsigned int idx_vec)
> +{
> + struct hw_atl_utils_mbox mbox;
> + struct ptp_clock *clock;
> + struct aq_ptp_s *self;
I find the use of self in this code quite confusing. It does not
appear to have a clear meaning. It can be a aq_ring_s, aq_nic_c,
aq_hw_s, aq_vec_s.
Looking at this code i always have to figure out what self is. Could
you not just use struct aq_ptp_s aq_ptp consistently in the code?
> + int err = 0;
> +
> + hw_atl_utils_mpi_read_stats(aq_nic->aq_hw, &mbox);
> +
> + if (!(mbox.info.caps_ex & BIT(CAPS_EX_PHY_PTP_EN))) {
> + aq_nic->aq_ptp = NULL;
> + return 0;
> + }
> +
> + self = kzalloc(sizeof(*self), GFP_KERNEL);
Using devm_kzalloc() will make your clean up easier.
> +void aq_ptp_free(struct aq_nic_s *aq_nic)
> +{
> + struct aq_ptp_s *self = aq_nic->aq_ptp;
> +
> + if (!self)
> + return;
> +
> + kfree(self);
kfree() is happy to take a NULL pointer. But this could all go away
with devm_kzalloc().
Andrew
^ permalink raw reply
* [PATCH 2/3] rtlwifi: rtl8192cu: replace _rtl92c_evm_db_to_percentage with generic version
From: Michael Straube @ 2019-09-10 19:04 UTC (permalink / raw)
To: kvalo; +Cc: pkshih, davem, linux-wireless, netdev, linux-kernel,
Michael Straube
In-Reply-To: <20190910190422.63378-1-straube.linux@gmail.com>
Function _rtl92c_evm_db_to_percentage is functionally identical
to the generic version rtl_evm_db_to_percentage, so remove
_rtl92c_evm_db_to_percentage and use the generic version instead.
Signed-off-by: Michael Straube <straube.linux@gmail.com>
---
.../wireless/realtek/rtlwifi/rtl8192cu/mac.c | 18 +-----------------
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c
index c8daad1e749f..cec19b32c7e2 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c
@@ -577,22 +577,6 @@ static u8 _rtl92c_query_rxpwrpercentage(s8 antpower)
return 100 + antpower;
}
-static u8 _rtl92c_evm_db_to_percentage(s8 value)
-{
- s8 ret_val;
-
- ret_val = value;
- if (ret_val >= 0)
- ret_val = 0;
- if (ret_val <= -33)
- ret_val = -33;
- ret_val = 0 - ret_val;
- ret_val *= 3;
- if (ret_val == 99)
- ret_val = 100;
- return ret_val;
-}
-
static long _rtl92c_signal_scale_mapping(struct ieee80211_hw *hw,
long currsig)
{
@@ -743,7 +727,7 @@ static void _rtl92c_query_rxphystatus(struct ieee80211_hw *hw,
else
max_spatial_stream = 1;
for (i = 0; i < max_spatial_stream; i++) {
- evm = _rtl92c_evm_db_to_percentage(p_drvinfo->rxevm[i]);
+ evm = rtl_evm_db_to_percentage(p_drvinfo->rxevm[i]);
if (packet_match_bssid) {
if (i == 0)
pstats->signalquality =
--
2.23.0
^ permalink raw reply related
* [PATCH 1/3] rtlwifi: rtl8192ce: replace _rtl92c_evm_db_to_percentage with generic version
From: Michael Straube @ 2019-09-10 19:04 UTC (permalink / raw)
To: kvalo; +Cc: pkshih, davem, linux-wireless, netdev, linux-kernel,
Michael Straube
In-Reply-To: <20190910190422.63378-1-straube.linux@gmail.com>
Function _rtl92c_evm_db_to_percentage is functionally identical
to the generic version rtl_evm_db_to_percentage, so remove
_rtl92c_evm_db_to_percentage and use the generic version instead.
Signed-off-by: Michael Straube <straube.linux@gmail.com>
---
.../wireless/realtek/rtlwifi/rtl8192ce/trx.c | 23 +------------------
1 file changed, 1 insertion(+), 22 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/trx.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/trx.c
index 123dbf0903a1..fc9a3aae047f 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/trx.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/trx.c
@@ -33,27 +33,6 @@ static u8 _rtl92c_query_rxpwrpercentage(s8 antpower)
return 100 + antpower;
}
-static u8 _rtl92c_evm_db_to_percentage(s8 value)
-{
- s8 ret_val;
-
- ret_val = value;
-
- if (ret_val >= 0)
- ret_val = 0;
-
- if (ret_val <= -33)
- ret_val = -33;
-
- ret_val = 0 - ret_val;
- ret_val *= 3;
-
- if (ret_val == 99)
- ret_val = 100;
-
- return ret_val;
-}
-
static long _rtl92ce_signal_scale_mapping(struct ieee80211_hw *hw,
long currsig)
{
@@ -243,7 +222,7 @@ static void _rtl92ce_query_rxphystatus(struct ieee80211_hw *hw,
max_spatial_stream = 1;
for (i = 0; i < max_spatial_stream; i++) {
- evm = _rtl92c_evm_db_to_percentage(p_drvinfo->rxevm[i]);
+ evm = rtl_evm_db_to_percentage(p_drvinfo->rxevm[i]);
if (packet_match_bssid) {
/* Fill value in RFD, Get the first
--
2.23.0
^ permalink raw reply related
* [PATCH 3/3] rtlwifi: rtl8192de: replace _rtl92d_evm_db_to_percentage with generic version
From: Michael Straube @ 2019-09-10 19:04 UTC (permalink / raw)
To: kvalo; +Cc: pkshih, davem, linux-wireless, netdev, linux-kernel,
Michael Straube
In-Reply-To: <20190910190422.63378-1-straube.linux@gmail.com>
Function _rtl92d_evm_db_to_percentage is functionally identical
to the generic version rtl_evm_db_to_percentage, so remove
_rtl92d_evm_db_to_percentage and use the generic version instead.
Signed-off-by: Michael Straube <straube.linux@gmail.com>
---
.../wireless/realtek/rtlwifi/rtl8192de/trx.c | 18 ++----------------
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.c
index d162884a9e00..2494e1f118f8 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.c
@@ -4,6 +4,7 @@
#include "../wifi.h"
#include "../pci.h"
#include "../base.h"
+#include "../stats.h"
#include "reg.h"
#include "def.h"
#include "phy.h"
@@ -32,21 +33,6 @@ static u8 _rtl92d_query_rxpwrpercentage(s8 antpower)
return 100 + antpower;
}
-static u8 _rtl92d_evm_db_to_percentage(s8 value)
-{
- s8 ret_val = value;
-
- if (ret_val >= 0)
- ret_val = 0;
- if (ret_val <= -33)
- ret_val = -33;
- ret_val = 0 - ret_val;
- ret_val *= 3;
- if (ret_val == 99)
- ret_val = 100;
- return ret_val;
-}
-
static long _rtl92de_translate_todbm(struct ieee80211_hw *hw,
u8 signal_strength_index)
{
@@ -215,7 +201,7 @@ static void _rtl92de_query_rxphystatus(struct ieee80211_hw *hw,
else
max_spatial_stream = 1;
for (i = 0; i < max_spatial_stream; i++) {
- evm = _rtl92d_evm_db_to_percentage(p_drvinfo->rxevm[i]);
+ evm = rtl_evm_db_to_percentage(p_drvinfo->rxevm[i]);
if (packet_match_bssid) {
if (i == 0)
pstats->signalquality =
--
2.23.0
^ permalink raw reply related
* [PATCH 0/3] rtlwifi: use generic rtl_evm_db_to_percentage
From: Michael Straube @ 2019-09-10 19:04 UTC (permalink / raw)
To: kvalo; +Cc: pkshih, davem, linux-wireless, netdev, linux-kernel,
Michael Straube
Functions _rtl92{c,d}_evm_db_to_percentage are functionally identical
to the generic version rtl_evm_db_to percentage. This series converts
rtl8192ce, rtl8192cu and rtl8192de to use the generic version.
Michael Straube (3):
rtlwifi: rtl8192ce: replace _rtl92c_evm_db_to_percentage with generic
version
rtlwifi: rtl8192cu: replace _rtl92c_evm_db_to_percentage with generic
version
rtlwifi: rtl8192de: replace _rtl92d_evm_db_to_percentage with generic
version
.../wireless/realtek/rtlwifi/rtl8192ce/trx.c | 23 +------------------
.../wireless/realtek/rtlwifi/rtl8192cu/mac.c | 18 +--------------
.../wireless/realtek/rtlwifi/rtl8192de/trx.c | 18 ++-------------
3 files changed, 4 insertions(+), 55 deletions(-)
--
2.23.0
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] net: stmmac: Support enhanced addressing mode for DWMAC 4.10
From: Florian Fainelli @ 2019-09-10 19:01 UTC (permalink / raw)
To: Jose Abreu, Thierry Reding
Cc: David S . Miller, Giuseppe Cavallaro, Alexandre Torgue,
Jon Hunter, Bitan Biswas, netdev@vger.kernel.org,
linux-tegra@vger.kernel.org
In-Reply-To: <BN8PR12MB3266F021DFC2C61CDEC83418D3B60@BN8PR12MB3266.namprd12.prod.outlook.com>
On 9/10/19 1:35 AM, Jose Abreu wrote:
> From: Thierry Reding <thierry.reding@gmail.com>
> Date: Sep/09/2019, 20:13:29 (UTC+00:00)
>
>> On Mon, Sep 09, 2019 at 04:05:52PM +0000, Jose Abreu wrote:
>>> From: Thierry Reding <thierry.reding@gmail.com>
>>> Date: Sep/09/2019, 16:25:46 (UTC+00:00)
>>>
>>>> @@ -79,6 +79,10 @@ static void dwmac4_dma_init_rx_chan(void __iomem *ioaddr,
>>>> value = value | (rxpbl << DMA_BUS_MODE_RPBL_SHIFT);
>>>> writel(value, ioaddr + DMA_CHAN_RX_CONTROL(chan));
>>>>
>>>> + if (dma_cfg->eame)
>>>
>>> There is no need for this check. If EAME is not enabled then upper 32
>>> bits will be zero.
>>
>> The idea here was to potentially guard against this register not being
>> available on some revisions. Having the check here would avoid access to
>> the register if the device doesn't support enhanced addressing.
>
> I see your point but I don't think there will be any problems unless you
> have some strange system that doesn't handle the write accesses to
> unimplemented features properly ...
Is not it then just safer to not do the write to a register that you do
not know how the implementation is going to respond to with one of a
target abort, timeout, decoding error, just dead lock?
Also, would it make sense to consider adding an #ifdef
CONFIG_PHYS_ADDR_T_64BIT plus the conditional check so that you can be
slightly more optimal in the hot-path here?
--
Florian
^ permalink raw reply
* Re: [PATCH net 1/2] sctp: remove redundant assignment when call sctp_get_port_local
From: Dan Carpenter @ 2019-09-10 18:57 UTC (permalink / raw)
To: Mao Wenan
Cc: vyasevich, nhorman, marcelo.leitner, davem, linux-sctp, netdev,
linux-kernel, kernel-janitors
In-Reply-To: <20190910071343.18808-2-maowenan@huawei.com>
On Tue, Sep 10, 2019 at 03:13:42PM +0800, Mao Wenan wrote:
> There are more parentheses in if clause when call sctp_get_port_local
> in sctp_do_bind, and redundant assignment to 'ret'. This patch is to
> do cleanup.
>
> Signed-off-by: Mao Wenan <maowenan@huawei.com>
> ---
> net/sctp/socket.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index 9d1f83b10c0a..766b68b55ebe 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -399,9 +399,8 @@ static int sctp_do_bind(struct sock *sk, union sctp_addr *addr, int len)
> * detection.
> */
> addr->v4.sin_port = htons(snum);
> - if ((ret = sctp_get_port_local(sk, addr))) {
> + if (sctp_get_port_local(sk, addr))
> return -EADDRINUSE;
sctp_get_port_local() returns a long which is either 0,1 or a pointer
casted to long. It's not documented what it means and neither of the
callers use the return since commit 62208f12451f ("net: sctp: simplify
sctp_get_port").
Probably it should just return a bool?
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: dsa: microchip: remove NET_DSA_TAG_KSZ_COMMON
From: Andrew Lunn @ 2019-09-10 18:37 UTC (permalink / raw)
To: George McCollister
Cc: netdev, Woojung Huh, Florian Fainelli, Tristram Ha,
David S. Miller, Marek Vasut, linux-kernel
In-Reply-To: <20190910131836.114058-4-george.mccollister@gmail.com>
On Tue, Sep 10, 2019 at 08:18:36AM -0500, George McCollister wrote:
> Remove the superfluous NET_DSA_TAG_KSZ_COMMON and just use the existing
> NET_DSA_TAG_KSZ. Update the description to mention the three switch
> families it supports. No functional change.
>
> Signed-off-by: George McCollister <george.mccollister@gmail.com>
> Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] net: dsa: microchip: add ksz9567 to ksz9477 driver
From: Florian Fainelli @ 2019-09-10 18:35 UTC (permalink / raw)
To: George McCollister, netdev
Cc: Woojung Huh, Andrew Lunn, Tristram Ha, David S. Miller,
Marek Vasut, linux-kernel
In-Reply-To: <20190910131836.114058-3-george.mccollister@gmail.com>
On 9/10/19 6:18 AM, George McCollister wrote:
> Add support for the KSZ9567 7-Port Gigabit Ethernet Switch to the
> ksz9477 driver. The KSZ9567 supports both SPI and I2C. Oddly the
> ksz9567 is already in the device tree binding documentation.
>
> Signed-off-by: George McCollister <george.mccollister@gmail.com>
> Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: dsa: microchip: remove NET_DSA_TAG_KSZ_COMMON
From: Florian Fainelli @ 2019-09-10 18:35 UTC (permalink / raw)
To: George McCollister, netdev
Cc: Woojung Huh, Andrew Lunn, Tristram Ha, David S. Miller,
Marek Vasut, linux-kernel
In-Reply-To: <20190910131836.114058-4-george.mccollister@gmail.com>
On 9/10/19 6:18 AM, George McCollister wrote:
> Remove the superfluous NET_DSA_TAG_KSZ_COMMON and just use the existing
> NET_DSA_TAG_KSZ. Update the description to mention the three switch
> families it supports. No functional change.
>
> Signed-off-by: George McCollister <george.mccollister@gmail.com>
> Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] net: dsa: microchip: add ksz9567 to ksz9477 driver
From: Andrew Lunn @ 2019-09-10 18:30 UTC (permalink / raw)
To: George McCollister
Cc: netdev, Woojung Huh, Florian Fainelli, Tristram Ha,
David S. Miller, Marek Vasut, linux-kernel
In-Reply-To: <20190910131836.114058-3-george.mccollister@gmail.com>
On Tue, Sep 10, 2019 at 08:18:35AM -0500, George McCollister wrote:
> Add support for the KSZ9567 7-Port Gigabit Ethernet Switch to the
> ksz9477 driver. The KSZ9567 supports both SPI and I2C. Oddly the
> ksz9567 is already in the device tree binding documentation.
>
> Signed-off-by: George McCollister <george.mccollister@gmail.com>
> Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH 1/7] net/dsa: configure autoneg for CPU port
From: Florian Fainelli @ 2019-09-10 18:29 UTC (permalink / raw)
To: Andrew Lunn, Robert Beckett; +Cc: netdev, Vivien Didelot, David S. Miller
In-Reply-To: <20190910182635.GA9761@lunn.ch>
On 9/10/19 11:26 AM, Andrew Lunn wrote:
> On Tue, Sep 10, 2019 at 04:41:47PM +0100, Robert Beckett wrote:
>> This enables us to negoatiate pause frame transmission to prioritise
>> packet delivery over throughput.
>
> I don't think we can unconditionally enable this. It is a big
> behaviour change, and it is likely to break running systems. It has
> affects on QoS, packet prioritisation, etc.
>
> I think there needs to be a configuration knob. But unfortunately, i
> don't know of a good place to put this knob. The switch CPU port is
> not visible in any way.
Broadcast storm suppression is to be solved at ingress, not on the CPU
port, once this lands on the CPU port, it's game over already.
--
Florian
^ permalink raw reply
* Re: [PATCH 1/7] net/dsa: configure autoneg for CPU port
From: Andrew Lunn @ 2019-09-10 18:26 UTC (permalink / raw)
To: Robert Beckett; +Cc: netdev, Vivien Didelot, Florian Fainelli, David S. Miller
In-Reply-To: <20190910154238.9155-2-bob.beckett@collabora.com>
On Tue, Sep 10, 2019 at 04:41:47PM +0100, Robert Beckett wrote:
> This enables us to negoatiate pause frame transmission to prioritise
> packet delivery over throughput.
I don't think we can unconditionally enable this. It is a big
behaviour change, and it is likely to break running systems. It has
affects on QoS, packet prioritisation, etc.
I think there needs to be a configuration knob. But unfortunately, i
don't know of a good place to put this knob. The switch CPU port is
not visible in any way.
Andrew
^ permalink raw reply
* Re: [PATCH] net/mlx5: Declare 'rt' as corresponding enum type
From: Saeed Mahameed @ 2019-09-10 17:59 UTC (permalink / raw)
To: austindh.kim@gmail.com, leon@kernel.org
Cc: linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org,
Mark Bloch, davem@davemloft.net, netdev@vger.kernel.org,
Alex Vesker, Erez Shitrit
In-Reply-To: <20190910092731.GA173476@LGEARND20B15>
On Tue, 2019-09-10 at 18:27 +0900, Austin Kim wrote:
> When building kernel with clang, we can observe below warning
> message:
>
> drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c:1080:9:
> warning: implicit conversion from enumeration type 'enum
> mlx5_reformat_ctx_type'
> to different enumeration type 'enum mlx5dr_action_type' [- Wenum-
> conversion]
> rt = MLX5_REFORMAT_TYPE_L2_TO_L2_TUNNEL;
> ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c:1082:9:
> warning: implicit conversion from enumeration type 'enum
> mlx5_reformat_ctx_type'
> to different enumeration type 'enum mlx5dr_action_type' [- Wenum-
> conversion]
> rt = MLX5_REFORMAT_TYPE_L2_TO_L3_TUNNEL;
> ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c:1084:51:
> warning: implicit conversion from enumeration type 'enum
> mlx5dr_action_type'
> to different enumeration type 'enum mlx5_reformat_ctx_type'
> [- Wenum-conversion]
> ret = mlx5dr_cmd_create_reformat_ctx(dmn->mdev, rt, data_sz,
> data,
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^~
>
> Declare 'rt' as corresponding enum mlx5_reformat_ctx_type type.
>
> Signed-off-by: Austin Kim <austindh.kim@gmail.com>
Hi Austin, Thanks for the patch:
We already have a similar patch queued for submission.
https://patchwork.ozlabs.org/patch/1158175/
> ---
> drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
> a/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c
> b/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c
> index a02f87f..7d81a77 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c
> @@ -1074,7 +1074,7 @@ dr_action_create_reformat_action(struct
> mlx5dr_domain *dmn,
> case DR_ACTION_TYP_L2_TO_TNL_L2:
> case DR_ACTION_TYP_L2_TO_TNL_L3:
> {
> - enum mlx5dr_action_type rt;
> + enum mlx5_reformat_ctx_type rt;
>
> if (action->action_type == DR_ACTION_TYP_L2_TO_TNL_L2)
> rt = MLX5_REFORMAT_TYPE_L2_TO_L2_TUNNEL;
^ permalink raw reply
* Re: [PATCH net-next 2/2] mlx5: fix type mismatch
From: Saeed Mahameed @ 2019-09-10 17:56 UTC (permalink / raw)
To: dledford@redhat.com, davem@davemloft.net, jgg@ziepe.ca,
arnd@arndb.de, leon@kernel.org
Cc: linux-rdma@vger.kernel.org, Yishai Hadas, Mark Bloch,
linux-kernel@vger.kernel.org, Erez Shitrit,
netdev@vger.kernel.org, Alex Vesker, Ariel Levkovich
In-Reply-To: <20190909195024.3268499-2-arnd@arndb.de>
On Mon, 2019-09-09 at 21:50 +0200, Arnd Bergmann wrote:
> In mlx5, pointers to 'phys_addr_t' and 'u64' are mixed since the
> addition
> of the pool memory allocator, leading to incorrect behavior on 32-bit
> architectures and this compiler warning:
>
> drivers/net/ethernet/mellanox/mlx5/core/steering/dr_icm_pool.c:121:8:
> error: incompatible pointer types passing 'u64 *' (aka 'unsigned long
> long *') to parameter of type 'phys_addr_t *' (aka 'unsigned int *')
> [-Werror,-Wincompatible-pointer-types]
> &icm_mr->dm.addr, &icm_mr-
> >dm.obj_id);
> ^~~~~~~~~~~~~~~~
> include/linux/mlx5/driver.h:1092:39: note: passing argument to
> parameter 'addr' here
> u64 length, u16 uid, phys_addr_t *addr, u32
> *obj_id);
>
> Change the code to use 'u64' consistently in place of 'phys_addr_t'
> to
> fix this. The alternative of using phys_addr_t more would require a
> larger
> rework.
>
> Fixes: 29cf8febd185 ("net/mlx5: DR, ICM pool memory allocator")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Hi Arnd,
Nathan Chancellor Already submitted a patch to fix this and it is more
minimal:
https://patchwork.ozlabs.org/patch/1158177/
I would like to use that patch if it is ok with you..
> ---
> drivers/infiniband/hw/mlx5/cmd.c | 4 ++--
> drivers/infiniband/hw/mlx5/cmd.h | 4 ++--
> drivers/infiniband/hw/mlx5/mlx5_ib.h | 2 +-
> drivers/net/ethernet/mellanox/mlx5/core/lib/dm.c | 4 ++--
> include/linux/mlx5/driver.h | 4 ++--
> 5 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/infiniband/hw/mlx5/cmd.c
> b/drivers/infiniband/hw/mlx5/cmd.c
> index 4937947400cd..fbcad70ef6dc 100644
> --- a/drivers/infiniband/hw/mlx5/cmd.c
> +++ b/drivers/infiniband/hw/mlx5/cmd.c
> @@ -82,7 +82,7 @@ int mlx5_cmd_modify_cong_params(struct
> mlx5_core_dev *dev,
> return mlx5_cmd_exec(dev, in, in_size, out, sizeof(out));
> }
>
> -int mlx5_cmd_alloc_memic(struct mlx5_dm *dm, phys_addr_t *addr,
> +int mlx5_cmd_alloc_memic(struct mlx5_dm *dm, u64 *addr,
> u64 length, u32 alignment)
> {
> struct mlx5_core_dev *dev = dm->dev;
> @@ -157,7 +157,7 @@ int mlx5_cmd_alloc_memic(struct mlx5_dm *dm,
> phys_addr_t *addr,
> return -ENOMEM;
> }
>
> -int mlx5_cmd_dealloc_memic(struct mlx5_dm *dm, phys_addr_t addr, u64
> length)
> +int mlx5_cmd_dealloc_memic(struct mlx5_dm *dm, u64 addr, u64 length)
> {
> struct mlx5_core_dev *dev = dm->dev;
> u64 hw_start_addr = MLX5_CAP64_DEV_MEM(dev,
> memic_bar_start_addr);
> diff --git a/drivers/infiniband/hw/mlx5/cmd.h
> b/drivers/infiniband/hw/mlx5/cmd.h
> index 169cab4915e3..2ea7a45a6abb 100644
> --- a/drivers/infiniband/hw/mlx5/cmd.h
> +++ b/drivers/infiniband/hw/mlx5/cmd.h
> @@ -44,9 +44,9 @@ int mlx5_cmd_query_cong_params(struct mlx5_core_dev
> *dev, int cong_point,
> int mlx5_cmd_query_ext_ppcnt_counters(struct mlx5_core_dev *dev,
> void *out);
> int mlx5_cmd_modify_cong_params(struct mlx5_core_dev *mdev,
> void *in, int in_size);
> -int mlx5_cmd_alloc_memic(struct mlx5_dm *dm, phys_addr_t *addr,
> +int mlx5_cmd_alloc_memic(struct mlx5_dm *dm, u64 *addr,
> u64 length, u32 alignment);
> -int mlx5_cmd_dealloc_memic(struct mlx5_dm *dm, phys_addr_t addr, u64
> length);
> +int mlx5_cmd_dealloc_memic(struct mlx5_dm *dm, u64 addr, u64
> length);
> void mlx5_cmd_dealloc_pd(struct mlx5_core_dev *dev, u32 pdn, u16
> uid);
> void mlx5_cmd_destroy_tir(struct mlx5_core_dev *dev, u32 tirn, u16
> uid);
> void mlx5_cmd_destroy_tis(struct mlx5_core_dev *dev, u32 tisn, u16
> uid);
> diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h
> b/drivers/infiniband/hw/mlx5/mlx5_ib.h
> index 2ceaef3ea3fb..476d4447f901 100644
> --- a/drivers/infiniband/hw/mlx5/mlx5_ib.h
> +++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h
> @@ -561,7 +561,7 @@ enum mlx5_ib_mtt_access_flags {
>
> struct mlx5_ib_dm {
> struct ib_dm ibdm;
> - phys_addr_t dev_addr;
> + u64 dev_addr;
> u32 type;
> size_t size;
> union {
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lib/dm.c
> b/drivers/net/ethernet/mellanox/mlx5/core/lib/dm.c
> index e065c2f68f5a..ad4d7484fa63 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/lib/dm.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/lib/dm.c
> @@ -90,7 +90,7 @@ void mlx5_dm_cleanup(struct mlx5_core_dev *dev)
> }
>
> int mlx5_dm_sw_icm_alloc(struct mlx5_core_dev *dev, enum
> mlx5_sw_icm_type type,
> - u64 length, u16 uid, phys_addr_t *addr, u32
> *obj_id)
> + u64 length, u16 uid, u64 *addr, u32 *obj_id)
> {
> u32 num_blocks = DIV_ROUND_UP_ULL(length,
> MLX5_SW_ICM_BLOCK_SIZE(dev));
> u32 out[MLX5_ST_SZ_DW(general_obj_out_cmd_hdr)] = {};
> @@ -175,7 +175,7 @@ int mlx5_dm_sw_icm_alloc(struct mlx5_core_dev
> *dev, enum mlx5_sw_icm_type type,
> EXPORT_SYMBOL_GPL(mlx5_dm_sw_icm_alloc);
>
> int mlx5_dm_sw_icm_dealloc(struct mlx5_core_dev *dev, enum
> mlx5_sw_icm_type type,
> - u64 length, u16 uid, phys_addr_t addr, u32
> obj_id)
> + u64 length, u16 uid, u64 addr, u32 obj_id)
> {
> u32 num_blocks = DIV_ROUND_UP_ULL(length,
> MLX5_SW_ICM_BLOCK_SIZE(dev));
> u32 out[MLX5_ST_SZ_DW(general_obj_out_cmd_hdr)] = {};
> diff --git a/include/linux/mlx5/driver.h
> b/include/linux/mlx5/driver.h
> index 3e80f03a387f..e07f9daf7d42 100644
> --- a/include/linux/mlx5/driver.h
> +++ b/include/linux/mlx5/driver.h
> @@ -1089,9 +1089,9 @@ int mlx5_lag_query_cong_counters(struct
> mlx5_core_dev *dev,
> struct mlx5_uars_page *mlx5_get_uars_page(struct mlx5_core_dev
> *mdev);
> void mlx5_put_uars_page(struct mlx5_core_dev *mdev, struct
> mlx5_uars_page *up);
> int mlx5_dm_sw_icm_alloc(struct mlx5_core_dev *dev, enum
> mlx5_sw_icm_type type,
> - u64 length, u16 uid, phys_addr_t *addr, u32
> *obj_id);
> + u64 length, u16 uid, u64 *addr, u32 *obj_id);
> int mlx5_dm_sw_icm_dealloc(struct mlx5_core_dev *dev, enum
> mlx5_sw_icm_type type,
> - u64 length, u16 uid, phys_addr_t addr, u32
> obj_id);
> + u64 length, u16 uid, u64 addr, u32 obj_id);
>
> #ifdef CONFIG_MLX5_CORE_IPOIB
> struct net_device *mlx5_rdma_netdev_alloc(struct mlx5_core_dev
> *mdev,
^ permalink raw reply
* Re: Default qdisc not correctly initialized with custom MTU
From: Holger Hoffstätte @ 2019-09-10 17:45 UTC (permalink / raw)
To: Cong Wang; +Cc: Netdev
In-Reply-To: <CAM_iQpUO3vedg+XOcMb8s6hE=+hdvjPJp9DitjHZE6oNtDVkVQ@mail.gmail.com>
On 9/10/19 6:56 PM, Cong Wang wrote:
> It is _not_ created when sysctl is configured, it is either created via tc
> command, or implicitly created by kernel when you bring up eth0.
> sysctl only tells kernel what to create by default, but never commits it.
Ok, thank you - that's good to know, because it means there is something
wrong with how my interface is initially brought up. And indeed I found
the problem: my startup scripts apparently bring up the interface twice -
once to "pre-start" (load/verify modules etc.) and then again after
applying mtu/route/etc. settings. Obviously without MTU bringing up the
interface will pull in the default qdisc in the interface's default config,
and that's what I saw after boot. Weird but what can I say.
Anyway, thanks for trying to help. :)
Holger
^ 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