> Don't populate various tables on the stack but make them static const.
> Makes the object code smaller by nearly 200 bytes:
>
> Before:
>text data bss dec hex filename
> 113468 11200 0 124668 1e6fc bnx2x_ethtool.o
>
> After:
>text data
> > Looks like commit f663dd9aaf9e ("net: core: explicitly select a txq
> > before doing l2 forwarding") has removed the need for this dedicated
> > xmit function [it even explicitly states so in its commit log message]
> > but it hasn't removed the definition of the ndo.
> >
> > Signed-off-by: Yuv
> A stray semicolon was introduced by bbfcd1e8e1677b (qed*: Set rdma
> generic functions prefix), remove it.
Hi Mark,
Thanks, but I've already sent the same
http://marc.info/?l=linux-netdev&m=149802281509733&w=2
Thanks,
Yuval
This one was a too-early send. Please ignore [sorry].
> I'm still not happy at all.
> You failed the address the specific thing I asked to be fixed.
> In patch #4, the rename, you just say in your commit message
> that you are "renaming".
> But in the qedr/main.c part of the change, you are _REMOVING_
> the include.
> And I said that can't be right
> Hi Michal,
>
> [auto build test ERROR on net-next/master]
>
> url:https://github.com/0day-ci/linux/commits/Yuval-Mintz/qed-RDMA-
> and-infrastructure-for-iWARP/20170616-043925
> config: i386-randconfig-x076-06120530 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> r
>In file included from drivers/net//ethernet/qlogic/qede/qede.h:43:0,
> from drivers/net//ethernet/qlogic/qede/qede_ptp.h:38,
> from drivers/net//ethernet/qlogic/qede/qede_fp.c:43:
> >> include/linux/qed/qede_rdma.h:57:12: warning: 'struct pci_dev' declar
> From: Pablo Cascón
>
> Add general use per-vNIC mailbox area and use it for VLAN filtering support.
> Initially proto is hardcoded to 802.1q.
>
...
> +static int
> +nfp_net_vlan_rx_add_vid(struct net_device *netdev, __be16 proto, u16
> +vid) {
> + struct nfp_net *nn = netdev_priv(netdev);
> The p_l2_info->pp_qid_usage[] array has "p_l2_info->queues" elements so
> the > here should be a >= or we write beyond the end of the array.
>
> Fixes: bbe3f233ec5e ("qed: Assign a unique per-queue index to queue-cid")
> Signed-off-by: Dan Carpenter
While it's a theoretical fix [as check is de
> > > +static void hns3_nic_net_down(struct net_device *ndev) {
> > > + struct hns3_nic_priv *priv = netdev_priv(ndev);
> > > + struct hnae3_ae_ops *ops;
> > > + int i;
> > > +
> > > + netif_tx_stop_all_queues(ndev);
> > > + netif_carrier_off(ndev);
> > > + netif_tx_disable(ndev);
> > > +
> > > + o
> This adds the support of the debugfs interface to the driver for debugging
> purposes.
> +const struct hclge_support_cmd support_cmd[] = {
> + {"send cmd", 8, hclge_dbg_send,
> + "opcode flag data0 data1 data2 data3 data4 data5"},
> + {"help", 4, hclge_dbg_usage, "no option
> +static void hns3_nic_net_down(struct net_device *ndev) {
> + struct hns3_nic_priv *priv = netdev_priv(ndev);
> + struct hnae3_ae_ops *ops;
> + int i;
> +
> + netif_tx_stop_all_queues(ndev);
> + netif_carrier_off(ndev);
> + netif_tx_disable(ndev);
> +
> + ops = priv->a
> When CONFIG_QED_SRIOV is disabled, we get a build error:
>
> drivers/net/ethernet/qlogic/qed/qed_int.c: In function 'qed_int_sb_init':
> drivers/net/ethernet/qlogic/qed/qed_int.c:1499:4: error: implicit declaration
> of function 'qed_vf_set_sb_info'; did you mean 'qed_mcp_get_resc_info'? [-
> We
> -Original Message-
> From: David Laight [mailto:david.lai...@aculab.com]
> Sent: Friday, June 09, 2017 10:28 AM
> To: 'David Miller' ; Mintz, Yuval
>
> Cc: netdev@vger.kernel.org; linux-r...@vger.kernel.org; Kalderon, Michal
>
> Subject: RE: [P
> > +struct qed_ll2_tx_pkt_info {
> > + u8 num_of_bds;
> > + u16 vlan;
> > + u8 bd_flags;
> > + u16 l4_hdr_offset_w;/* from start of packet */
> > + enum qed_ll2_tx_dest tx_dest;
> > + enum qed_ll2_roce_flavor_type qed_roce_flavor;
> > + dma_addr_t first_frag;
> > + u16 first_fr
> >> >> >> >What were your plans with pre-netdev config?
> >> >> >>
> >> >> >> We need to pass come initial resource division. Generally the
> >> >> >> consensus is to have these options exposed through devlink, let
> >> >> >> the user configure them all and then to have a trigger that
> >> >> >> w
> >> >> >What were your plans with pre-netdev config?
> >> >>
> >> >> We need to pass come initial resource division. Generally the
> >> >> consensus is to have these options exposed through devlink, let
> >> >> the user configure them all and then to have a trigger that would
> >> >> cause driver
> When freeing VF's DMA mappings, an already NULLed pointer was checked
> again due to an apparent copy&paste error. Consequently, the pf2vf bulletin
> DMA mapping was not freed.
>
> Signed-off-by: Michal Schmidt
Thanks Michal.
Acked-by: Yuval Mintz
> >> >What were your plans with pre-netdev config?
> >>
> >> We need to pass come initial resource division. Generally the
> >> consensus is to have these options exposed through devlink, let the
> >> user configure them all and then to have a trigger that would cause
> >> driver re-orchestration
> + pktsize = be16_to_cpu(port_rpl.u.info.mtu);
> + /* subtract ethhdr size and 4 bytes crc since, f/w appends it */
> + pktsize = pktsize - sizeof(struct ethhdr) - 4;
> + /* subtract ipv4 hdr size, tcp hdr size to get typical IPv4 MSS size */
> + pktsize = pktsize - sizeof(stru
> The driver may sleep in interrupt handling, and the function call path is:
> qed_int_sp_dpc (tasklet_init indicates it handles interrupt)
> qed_int_attentions
> qed_mcp_handle_events
> qed_mcp_handle_link_change
> qed_link_update
> qed_fill_link
> qed_mcp
> While looking into Coverity ID 1362293 I ran into the following piece of code
> at drivers/net/ethernet/qlogic/qed/qed_sriov.c:3863:
>
> 3863static int
> 3864qed_iov_configure_min_tx_rate(struct qed_dev *cdev, int vfid, u32 rate)
> 3865{
> 3866struct qed_vf_info *vf;
> 3867u8 vpo
> - bnxt_db_write(bp, txr->tx_doorbell, DB_KEY_TX | prod);
> + if (!skb->xmit_more)
> + bnxt_db_write(bp, txr->tx_doorbell, DB_KEY_TX | prod);
DQL can prevent you from getting the xmit_more marked SKB,
so you should probably also check for netif_xmit_stopped().
> pf->limit_vfs = nfp_rtsym_read_le(pf->cpp, "nfd_vf_cfg_max_vfs",
> &err);
> if (!err)
> - return;
> + return pci_sriov_set_totalvfs(pf->pdev, pf->limit_vfs);
While you're at it, If you're going to enforce the limit at the PCI level,
shouldn't you retire 'limit
> Patches 6-8 add the "ethtool -f" and the boot-time firmware upgrade
> on
> >> the
> mlxsw spectrum driver.
> >>> When we tried using `ethtool -E' for qed we got burned for trying to
> >>> use
> >> the magic
> >>> value [1]. When we suggested extending it to allow some private data
> >> Patches 6-8 add the "ethtool -f" and the boot-time firmware upgrade on
> the
> >> mlxsw spectrum driver.
> > When we tried using `ethtool -E' for qed we got burned for trying to use
> the magic
> > value [1]. When we suggested extending it to allow some private data
> indications,
> > Ben clai
> Add support for device firmware flash on mlxsw spectrum. The firmware files
> are expected to be in the Mellanox Firmware Archive version 2 (MFA2)
> format.
>
> The firmware flash can be triggered via "ethtool -f" or on driver
> initialization
> time if the device firmware version does not meet
> > - #1, #2 and #9 correct small missing ethtool functionality.
> > - #3, #6 and #8 correct minor issues in driver, but those are either
> >print-related or unexposed in existing code.
> > - #4 adds proper support to TLB mode bonding.
> > - #10 is meant to improve performance on varying c
> >> Please.
> >>
> >> This is exactly the problem when such a terse commit message, or lack of
> >> any
> >> message at all as is the case here, occurs.
> >>
> >> I have no idea what removing this method assignment has to do with fixing
> >> sparse warnings.
> >
> > It's currently defined twic
> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Monday, May 22, 2017 7:38 PM
> To: Mintz, Yuval
> Cc: netdev@vger.kernel.org; Chopra, Manish
> Subject: Re: [PATCH net-next 01/11] qede: Fix sparse warnings
>
> From: Yuval Mintz
> >> This pushes qed [and as result, all qed* drivers] into using 8.20.0.0
> >> firmware. The changes are mostly contained in qed with minor changes
> >> to qedi due to some HSI changes.
> >>
> >> Content-wise, the firmware contains fixes to various issues exposed
> >> since the release of the prev
> > Looking at my alternatives for solving this, I can't see any 'good'
> > options - it seems mightily unorthodox to modify net_device_ops, I.e.,
> > add/remove an NDO function-pointer based on some device property, and
> > having multiple ops declared for the sake of a single feature seems
> > un
Code-reading a bit, and I'm not sure of the exact definition of said bit;
Couldn't really deduce from the comment "N-tuple filters supported"
what falls under its jurisdiction and failed to find any other documentation.
I understand RFS acceleration is going to be disabled for an interface
when th
> PFs and VFs share the same structure of NDOs today, and the VFs explicitly
> fails the ndo_xdp() callback stating it doesn't support XDP.
>
> This results in lots of:
>
> [qede_xdp:1032(enp131s2)]VFs don't support XDP
> [ cut here ]
> WARNING: CPU: 4 PID: 1426 at n
> There is inline function to test if carrier present, so it makes open-coded
> solution redundant.
>
> Signed-off-by: Leon Romanovsky
Thanks Leon.
Acked-by: Yuval Mintz
> > For the most part - I'm almost all in favor of this change.
> > But just to make it clear - the actual fix could have been a one-liner,
> > right?
> > The rest are style changes.
> Correct. Having the correct length in the memset is a sufficient fix for the
> warning,
> but it felt wrong to
> register, which went subtly wrong due to the wrong size in a memset():
>
> ethernet/qlogic/qed/qed_init_fw_funcs.c: In function
> 'qed_set_rfs_mode_disable':
> ethernet/qlogic/qed/qed_init_fw_funcs.c:993:3: error: '*((void
> *)&ramline+4)' is used uninitialized in this function [-Werror=uninitia
> From: Andy Shevchenko
>
> Use scnprintf() when printing version instead of custom open coded variants.
>
> Signed-off-by: Andy Shevchenko
Hi Andy this seems correct.
Was there a cover-letter for your series? I've failed to find it.
[I was mostly interested in your motivation for this kind of
> My static checker complains that we're holding a mutex on this error path.
> Let's goto exit instead of returning directly.
>
> Fixes: b0bccb69eba3 ("qed: Change locking scheme for VF channel")
> Signed-off-by: Dan Carpenter
> ---
> Yuval, could you review this one a bit carefully and also chec
> sizeof() when applied to a pointer typed expression gives the size of the
> pointer, not that of the pointed data.
>
> Signed-off-by: Wei Yongjun
Thanks!
Acked-by: Yuval Mintz
I'd also mention that -
Fixes: b5a9ee7cf3be ("qed: Revise QM configuration")
> > I surely wouldn't want to write a million lines of code just to
> > provide such a detailed abstraction.
>
> So now the argument has gone from "it's not possible" to "it's going to be a
> HUGE amount of code."
Nothing here's is strictly impossible - you can always create a simulated HW
model
> > the HW pipeline itself can't be abstracted in this case.
>
> I've heard that argument before, and I'm glad Jiri didn't drink the koolaide
> and instead wrote dpipe.
Perhaps "can't" was the wrong term to use, but I still believe there's an
inherent problem with applying the dpipe approach here
> > I agree this surely isn't *our* convention, but for scsi using
> > debugfs [or sysfs] is a common practice for debug purposes.
> >
> > Also, our HW debug capabilities are highly-customable, and I want to
> > have the ability to configure those on the fly [E.g., dynamically
> > configuring vari
> >> > Dump some internal state about VFs through debugfs. This provides
> >> > information not available with 'ip link show'.
> >>
> >> such as?
> >>
> >> donnwantobethedebugfspolice, but still, in the 2-3 times we tried to
> >> push debugfs to MLNX NIC drivers, Dave disallowed that, and lately
>
> > Dump some internal state about VFs through debugfs. This provides
> > information not available with 'ip link show'.
>
> such as?
>
> donnwantobethedebugfspolice, but still, in the 2-3 times we tried to push
> debugfs to MLNX NIC drivers, Dave disallowed that, and lately the switch
> team eve
> > qed_dcbnl_get_dcbx() API uses kmalloc in GFT_KERNEL mode. The API gets
> > invoked in the interrupt context by qed_dcbnl_getdcbx callback. Need
> > to invoke this kmalloc in atomic mode.
> >
> > Signed-off-by: Sudarsana Reddy Kalluru
> > Signed-off-by: Yuval Mintz
> > ---
> > drivers/net/eth
> We've got the number of longs, yes, but we should multiply by
> sizeof(long) to get the number of bytes needed.
>
> Fixes: e4917d46a653 ("qede: Add aRFS support")
> Signed-off-by: Dan Carpenter
Thanks Dan.
Acked-by: Yuval Mintz
> There seems to be a missing break on the OOO_LB_TC case, pq_id is being
> assigned and then re-assigned on the fall through default case and that
> seems suspect.
>
> Detected by CoverityScan, CID#1424402 ("Missing break in switch")
>
> Fixes: b5a9ee7cf3be1 ("qed: Revise QM cofiguration")
>
>
> Trival fix, rename HW_INTERRUT_ASSERT_SET_* to
> HW_INTERRUPT_ASSERT_SET_*
>
> Signed-off-by: Colin Ian King
Thanks. Don't know if it's needed but still:
Acked-by: Yuval Mintz
> > + /* Timers is a special case -> we don't count how many cids require
>
> S/is/are/. CIDs?
What's implicitly meant here is the 'Timer[s] HW block'.
I understand it creates an odd looking English sentence, though.
Assuming there'll be a V2 for this we'd revise the comment;
Otherwise we'
> > 2. The IRQ name can only be specified at the time it is requested.
> > It cannot be changed after that.
Is there any inherent difficulty in adding that capability?
I.e., to rename the IRQ's action & kthread.
It would allow drivers to re-name their IRQ names upon NETDEV_CHANGENAME
> Dave,
>
> Please consider applying these to 'net'.
Apparently I failed adding you on E-mail, sending this only to netdev.
Does that suffice for your needs or do you need a re-send?
> > We can't just require a new firmware version in the driver, as users
> > most likely won't have it by the time they install the new kernel. So
> > you'll have to support the old firmware version as well.
>
> Why not? That has been the paradigm forever.
>
> The new firmware version is already
> We can't just require a new firmware version in the driver, as users most
> likely won't have it by the time they install the new kernel. So you'll have
> to
> support the old firmware version as well.
Why not? That has been the paradigm forever.
The new firmware version is already available
> It is too late to check for the limit of the number of VF multicast addresses
> after they have already been copied to the req->multicast[] array, possibly
> overflowing it.
>
> Do the check before copying.
>
> Checking early also avoids having to (and forgetting to) unlock vf2pf_mutex.
>
> Wh
> On failure to configure a VF MAC/VLAN filter we should not attempt to
> rollback filters that we failed to configure with -EEXIST.
Is this theoretical or did you actually manage to hit it?
If so, did it involve non-linux VFs?
Asking as linux VFs don't actually send multiple vlan/umac configurat
> @@ -883,6 +883,15 @@ int bnx2x_vfpf_set_mcast(struct net_device *dev)
> /* Get Rx mode requested */
> DP(NETIF_MSG_IFUP, "dev->flags = %x\n", dev->flags);
>
> + /* We support PFVF_MAX_MULTICAST_PER_VF mcast addresses tops
> */
> + if (netdev_mc_count(dev) > PFVF_MAX_MULTICAST
> Hello,
> here are fixes for a crash with PTP, a crash in setting of VF multicast
> addresses, and non-working VLAN filters configuration from the VF side.
>
> Michal Schmidt (7):
> bnx2x: prevent crash when accessing PTP with interface down
> bnx2x: lower verbosity of VF stats debug messages
> It is possible to crash the kernel by accessing a PTP device while its
> associated bnx2x interface is down. Before the interface is brought up, the
> timecounter is not initialized, so accessing it results in NULL dereference.
>
> Fix it by checking if the interface is up.
>
> Use -ENETDOWN as
> > Hi Dave,
> >
> > The 3 first patches here are a repost of
> > ("qed: RoCE infrastructure fixes"). The fourth is an additional
> > RoCE-related infrastructure fix, and the latter contain various fixes
> > to qed/qede.
> >
> > Notice patch #10 will create a conflict when net and net-next would b
> +static void nfp_pcie_sriov_read_nfd_limit(struct nfp_pf *pf)
> +{
> + int err;
> +
> + pf->limit_vfs = nfp_rtsym_read_le(pf->cpp, "nfd_vf_cfg_max_vfs",
> &err);
> + if (!err)
> + return;
> +
> + pf->limit_vfs = ~0;
> + /* Allow any setting for backwards compatibil
> > +/* Read Phy Hardware Clock */
> > +static int qed_ptp_hw_read_cc(struct qed_dev *cdev, u64 *phc_cycles)
> > +{
> > + struct qed_hwfn *p_hwfn = QED_LEADING_HWFN(cdev);
> > + struct qed_ptt *p_ptt = p_hwfn->p_ptp_ptt;
> > + u32 temp = 0;
> > +
> > + temp = qed_rd(p_hwfn, p_ptt, NIG_REG_T
> > > +void qede_ptp_tx_ts(struct qede_dev *edev, struct sk_buff *skb) {
> > > + struct qede_ptp *ptp;
> > > +
> > > + ptp = edev->ptp;
> > > + if (!ptp)
> > > + return;
> > > +
> > > + if (unlikely(!(edev->flags & QEDE_TX_TIMESTAMPING_EN))) {
> > > + DP_NOTICE(edev,
> > > +
> > +void qede_ptp_tx_ts(struct qede_dev *edev, struct sk_buff *skb) {
> > + struct qede_ptp *ptp;
> > +
> > + ptp = edev->ptp;
> > + if (!ptp)
> > + return;
> > +
> > + if (unlikely(!(edev->flags & QEDE_TX_TIMESTAMPING_EN))) {
> > + DP_NOTICE(edev,
> > +
> > This patch series adds required changes for qed/qede drivers for
> > supporting the IEEE Precision Time Protocol (PTP).
> >
> > Dave,
> > Please consider applying this series to "net-next".
> Please fix the problems reported by the kbuild robot.
> Thanks.
Fixing those are trivial [simply se
> > +static int qed_ptp_hw_adjfreq(struct qed_dev *cdev, s32 ppb) {
> > + struct qed_hwfn *p_hwfn = QED_LEADING_HWFN(cdev);
> > + struct qed_ptt *p_ptt = p_hwfn->p_ptp_ptt;
> > + int drift_dir, best_val, best_period;
> > + s64 period, dif, dif2;
> > + u32 drift_ctr_cfg = 0;
> > + s64 be
> On Sun, Feb 12, 2017 at 03:07:34PM +0000, Mintz, Yuval wrote:
> > Your algorithm ignores the HW limitation. Consider (ppb == 1):
> > your logic would output N == 7, *M == 70,
> >Which has perfect accuracy [N / *M is 1 / 10^9].
> > But the solution for
&g
> The original would return val == 1, period == 6249; While this does have
> some error [val / (period * 16 + 8) is slightly bigger than 1 / 10^9, error at
> 18[?] digit after dot], it's the best we can configure for the HW.
Correction. That's actually not *the best* we could configure -
due
> > Your suggestion seems to:
> > a. Assume that the required period should be in ns, not in
> > 16*ns units.
> > b. mishandles the +8/-8 in the calculation.
> > c. Doesn't seem to consider the upper bound on period.
>
> Duh, you would have to convert the result into the proper form fo
> The '+8' is not some sort of rounding correction, but rather part of the
> required configuration.
Just to clarify [since it's bit a meaningless otherwise] -
this +8 is a HW-bug workaround.
> On Sat, Feb 11, 2017 at 09:58:10AM +0100, Richard Cochran wrote:
> > If I am not mistaken, then you can skip the cases val==2 and val==3,
> > because they are equivalent to val==4 and 6.
>
> I took a stab at this, and you can see the result, below. My version has
> lower average error than your
> +/**
> + * struct ethtool_fecparam - Ethernet forward error correction(fec)
> +parameters
> + * @cmd: Command number = %ETHTOOL_GFECPARAM or
> %ETHTOOL_SFECPARAM
> + * @active_fec: FEC mode which is active on porte
> + * @fec: Bitmask of supported/configured FEC modes
> + * @rsvd: Reserved for fu
> + * Fields:
> + *
> + * priority - priority for insertion into set. The set is ordered lowest to
> + * highest priority.
> + * is_bpf - indicates that the hook is a BPF program (priv refers to a
> + * bpf_prog structure. This allows calling the BPF program directly
> + * from xdp_run wi
> On Mon, Feb 06, 2017 at 10:41:44AM +0000, Mintz, Yuval wrote:
> > Richard - we're planning on sending v4 with the existing algorithm
> > [but without iterating on 'val == 0']; If you have any suggestion for
> > improving this, please share it.
>
> S
> > > + for (val = 0; val <= 7; val++) {
> > > + period1 = div_s64(val * 10, ppb);
> > > + period1 -= 8;
> > > + period1 >>= 4;
> > > + if (period1 < 1)
> > > + period1 = 1;
> > > +
> +config BNXT_XDP
> + bool "Xpress Data Path (XDP) driver support"
> + default n
> + depends on BNXT && BPF
> + ---help---
> + Say Y here if you want to enable XDP in the driver to support
> + eBPF programs in the fast path.
> +
Wasn't it recently discussed that per-fe
> > + for (val = 0; val <= 7; val++) {
> > + period1 = div_s64(val * 10, ppb);
> > + period1 -= 8;
> > + period1 >>= 4;
> > + if (period1 < 1)
> > + period1 = 1;
> > +
> > I feel like I'm missing something. Again.
> > I thought the reasonable rate of rate-adjustment is once a second,
> > which doesn't make it 'hot' in any way.
> > In which scenario would we frequently encounter this configuration?
>
> The Sync message rate is not 1 per second, but rather the int
> > > How many different implementations of 'ops->adjfreq' are there?
> > > If there is only one you don't need an indirect call.
> >
> > There's only one implementation. But qed publishes its functions to
> > qede [and other modules] by structs of operations and not by exporting
> > symbols direct
> From: Sudarsana Reddy Kalluru
>
> The patch adds the required qed interfaces for configuring/reading the PTP
> clock on the adapter.
>
> Reviewed-by: Richard Cochran
This Reviewd-by Tag is incorrect; Should have been a CC.
Sorry about that.
> Signed-off-by: Sudarsana Reddy Kalluru
> Signed
> How many different implementations of 'ops->adjfreq' are there?
> If there is only one you don't need an indirect call.
There's only one implementation. But qed publishes its functions to
qede [and other modules] by structs of operations and not by
exporting symbols directly, and I don't see a r
> > I might have gotten it all wrong, but I was under the assumption that time-
> > stamped packets are periodic, and that the interval between two isn't
> > going to be so small.
> That is an incorrect assumption. Consider the Delay_Req packets
> arriving on a port in the MASTER state.
Right; I
> > That's part of the driver structuring - qed is responsible for
> > accessing HW so it implements api functions for accessing PTP-related
> > configuration, while qede is responsible for the network interface and
> > thus is the one to register the clock and implements its API.
>
> But there is
> > We could - but what difference would it make?
>
> It would reduce the chance of missing the next time stamp.
I might have gotten it all wrong, but I was under the assumption that time-
stamped packets are periodic, and that the interval between two isn't
going to be so small.
Is so, how does
> > +static int qede_ptp_adjfreq(struct ptp_clock_info *info, s32 ppb) {
> > + struct qede_ptp *ptp = container_of(info, struct qede_ptp,
> clock_info);
> > + struct qede_dev *edev = ptp->edev;
> > + int rc;
> > +
> > + __qede_lock(edev);
> > + if (edev->state == QEDE_STATE_OPEN) {
> > +
> > +/* Read Rx timestamp */
> > +static int qed_ptp_hw_read_rx_ts(struct qed_dev *cdev, u64
> > +*timestamp) {
> > + struct qed_hwfn *p_hwfn = QED_LEADING_HWFN(cdev);
> > + struct qed_ptt *p_ptt = p_hwfn->p_ptp_ptt;
> > + u32 val;
> > +
> > + *timestamp = 0;
> > + val = qed_rd(p_hwfn, p_
> Can we please, PLEASE put the PHC maintainer onto CC when posting new
> PHC drivers?
Sorry about that.
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> As I don't have the hardware, I'd be very pleased if someone may test this
> patch.
>
> Signed-off-by: Philippe Reynes
>From the little testing I've did, things look fine. Thanks.
> 968,23 +968,19 @@ static int qed_ll2_start_ooo(struct qed_dev *cdev, {
> struct qed_hwfn *hwfn = QED_LEADING_HWFN(cdev);
> u8 *handle = &hwfn->pf_params.iscsi_pf_params.ll2_ooo_queue_id;
> - struct qed_ll2_info *ll2_info;
> + struct qed_ll2_conn ll2_info;
A bit confusing to
> > On Sun, Jan 15, 2017 at 11:38:30PM -0500, David Miller wrote:
> >>
> >> Please do not ever submit two patches which have the same exact
> >> commit header line, as these two patches do.
> >>
> >> When someone looks into the shortlog of GIT history all they will see
> >> is "qed: Replace memset
> > +struct fcoe_tstorm_fcoe_task_st_ctx_read_write {
> > + union fcoe_cleanup_addr_exp_ro_union
> cleanup_addr_exp_ro_union;
> > + __le16 flags;
> > +#define
> FCOE_TSTORM_FCOE_TASK_ST_CTX_READ_WRITE_RX_SGL_MODE_MASK
> 0x7
> > +#define
> FCOE_TSTORM_FCOE_TASK_ST_CTX_READ_WRITE_RX_SGL_MODE_SHIF
+ if (key) {
> + WARN_ON_ONCE(bnx2x_get_rxfh_key_size(dev) !=
> T_ETH_RSS_KEY * 4);
> + bnx2x_get_rss_key(&bp->rss_conf_obj, key);
> + }
This doesn’t work VFs [the PF has the RSS configuration object in their
case; They don't have it], which is fine as 'key' shoul
> From: Colin Ian King
>
> A qed_spq_entry entry is allocated by qed_sp_init_request but is not kfree'd
> if an error occurs, causing a memory leak. Fix this by returning the
> previously
> allocated spq entry and also setting *pp_ent to NULL to be safe.
>
> Thanks to Yuval Mintz for suggestion
> commit 17bedab27231 ("bpf: xdp: Allow head adjustment in XDP prog")
> added a new XDP helper to prepend and remove data from a frame.
> Make virtio_net reject programs making use of this helper until proper
> support is added.
>
> Signed-off-by: Jakub Kicinski
Is that how it goes until we'll a
> From: Colin Ian King
>
> A qed_spq_entry entry is allocated by qed_sp_init_request but is not kfree'd
> if an error occurs, causing a memory leak. Fix this by kfree'ing it and also
> setting *pp_ent to NULL to be safe.
>
> Found with static analysis by CoverityScan, CIDs 1389468-1389470
>
> S
> if (config_hash) {
> /* RSS keys */
> - netdev_rss_key_fill(params.rss_key, T_ETH_RSS_KEY * 4);
> + netdev_rss_key_fill(&rss_obj->rss_key, T_ETH_RSS_KEY * 4);
> __set_bit(BNX2X_RSS_SET_SRCH, ¶ms.rss_flags);
> }
Those are still param
> From: Pan Bian
>
> When calling dma_mapping_error(), the value of return variable rc is 0.
> And when the call returns an unexpected value, rc is not set to a negative
> errno. Thus, it will return 0 on the error path, and its callers cannot detect
> the bug. This patch fixes the bug, assigning
> Since offset is zero, it's not necessary to use set function. Reset
> function is straightforward, and will remove the unnecessary add
> operation in set function.
Thanks.
Acked-by: Yuval Mintz
[For #2 for bnx2x as well]
> > You also need to wrap this under rcu_read_lock() (at least I haven't seen
> > it in your patches) for same reasons as stated in 326fe02d1ed6
> > ("net/mlx4_en:
> > protect ring->xdp_prog with rcu_read_lock"), as otherwise xdp_prog could
> > disappear underneath you. mlx4 and nfp does it correc
> > + if (act == XDP_PASS)
> > + return true;
> > +
> > + /* Count number of packets not to be passed to stack */
> > + rxq->xdp_no_pass++;
> > +
> > + switch (act) {
> > + default:
> > + bpf_warn_invalid_xdp_action(act);
> XDP_TX is a vali
1 - 100 of 141 matches
Mail list logo
