Jason Xing wrote:
> On Wed, Apr 14, 2021 at 12:27 AM Jesse Brandeburg
> wrote:
> >
> > kerneljasonx...@gmail.com wrote:
> >
> > > From: Jason Xing
> >
> > Hi Jason,
> >
> > Sorry, I missed this on the first time: Added intel-wired-la
se+0xed/0x120
> [2160294.719365] rtnl_newlink+0x73b/0x860
>
> Fixes: 41c445ff0f48 ("i40e: main driver core")
> Co-developed-by: Shujin Li
> Signed-off-by: Shujin Li
> Signed-off-by: Jason Xing
Reviewed-by: Jesse Brandeburg
@Jakub/@DaveM - feel free to apply this directly.
Nitesh Narayan Lal wrote:
> > The original issue as seen, was that if you rmmod/insmod a driver
> > *without* irqbalance running, the default irq mask is -1, which means
> > any CPU. The older kernels (this issue was patched in 2014) used to use
> > that affinity mask, but the value programmed int
kerneljasonx...@gmail.com wrote:
> From: Jason Xing
Hi Jason,
Sorry, I missed this on the first time: Added intel-wired-lan,
please include on any future submissions for Intel drivers.
get-maintainers script might help here?
>
> Fix this panic by adding more rules to calculate the value of @r
kerneljasonx...@gmail.com wrote:
> From: Jason Xing
>
> Re: [PATCH] i40e: fix the panic when running bpf in xdpdrv mode
Please use netdev style subject lines when patching net kernel to
indicate which kernel tree this is targeted at, "net" or "net-next"
[PATCH net v2] i40e: ...
> Fix this by a
Bhaskar Chowdhury wrote:
>
> s/Reprogam/Reprogram/
>
> Signed-off-by: Bhaskar Chowdhury
Reviewed-by: Jesse Brandeburg
issue in patch 2
>
Thanks Alex, I had a look over the whole thing and it looks good to me.
Reviewed-by: Jesse Brandeburg
ned-off-by: Alexander Duyck
Thanks!
Acked-by: Jesse Brandeburg
Jakub Kicinski wrote:
> > > I personally think that the overuse of flags in Intel drivers brings
> > > nothing but trouble. At which point does it make sense to just add a
> > > lock / semaphore here rather than open code all this with no clear
> > > semantics? No code seems to just test the __IAVF
Jakub Kicinski wrote:
> On Wed, 10 Mar 2021 17:35:17 -0800 Alexander Duyck wrote:
> > From: Alexander Duyck
> > +/**
> > + * ethtool_gsprintf - Write formatted string to ethtool string data
> > + * @data: Pointer to start of string to update
> > + * @fmt: Format of string to write
> > + *
> > + *
Alexander Duyck wrote:
> From: Alexander Duyck
>
> Update the Intel drivers to make use of ethtool_gsprintf. The general idea
> is to reduce code size and overhead by replacing the repeated pattern of
> string printf statements and ETH_STRING_LEN counter increments.
>
> Signed-off-by: Alexander
Jakub Kicinski wrote:
> On Mon, 8 Mar 2021 16:28:58 -0800 Jesse Brandeburg wrote:
> > Hello,
> >
> > We plan to refactor the iavf module and would appreciate community and
> > maintainer feedback on our plans. We want to do this to realize the
> > usefuln
Leon Romanovsky wrote:
> > 3) Plan is to make the "new" iavf driver the default iavf once
> >extensive regression testing can be completed.
> > a. Current proposal is to make CONFIG_IAVF have a sub-option
> >CONFIG_IAVF_V2 that lets the user adopt the new code,
> >without c
Hello,
We plan to refactor the iavf module and would appreciate community and
maintainer feedback on our plans. We want to do this to realize the
usefulness of the common code module for multiple drivers. This
proposal aims to avoid disrupting current users.
The steps we plan are something like
Jesper for the report of the issue.
For the series:
Reviewed-by: Jesse Brandeburg
spinics.net/lists/netdev/msg490554.html
Thanks for the patch! I'd like someone on our team to double check
things are working still on some of the stock Intel boards, but the code
changes look fine.
Reviewed-by: Jesse Brandeburg
. Fix this by renaming the
> duplicate guard in the igb driver.
>
> Fixes: 9d5c824399de ("igb: PCI-Express 82575 Gigabit Ethernet driver")
> Signed-off-by: Tom Seewald
Change is simple and makes sense.
Reviewed-by: Jesse Brandeburg
igned-off-by: Vladimir Oltean
Reviewed-by: Jesse Brandeburg
ot;net: stmmac: Add support for CBS QDISC")
> Suggested-by: Gomes, Vinicius
> Signed-off-by: Mohammad Athari Bin Ismail
> Signed-off-by: Song, Yoong Siang
Reviewed-by: Jesse Brandeburg
NB: I thought I'd have a close look at this since I thought I
understand NAPI pretty well, but using NAPI to transmit frames as well
as with a usb device has got me pretty confused. Also, I suspect that
you didn't try compiling this against the net-next kernel.
I'm stopping my review only partiall
Geetha sowjanya wrote:
> v2-v3
> Reposting as a single thread.
FYI, it didn't work, suggest you try adding the git-send-email option
(via git-config)
sendemail.thread=true
sendemail.chainreplyto=false
And you can test locally by using first using git send-email to export
to mbox and checking fo
>
> Suggested-by: David Rientjes
> Suggested-by: Jakub Kicinski
> Cc: John Hubbard
> Signed-off-by: Alexander Lobakin
I don't know why it was missed in the series update, but:
Reviewed-by: Jesse Brandeburg
comment for frag_list
> v4: no change
> v5: reword/fix commit subject
>
Acked-by: Jesse Brandeburg
Zheng Yongjun wrote:
> When kzalloc failed, should return ENOMEM rather than ENOBUFS.
All these patches have the same subject and description, couldn't they
just be part of a single series with a good cover letter?
I'm not saying make them a single patch, because that is bad for
bisection, but h
n sending like [PATCH net-next]
otherwise, for net-next:
Reviewed-by: Jesse Brandeburg
uot;hv_netvsc: Add validation for untrusted Hyper-V
> values")
Reviewed-by: Jesse Brandeburg
gainst 0")
> Fixes: 04987ca1b9b6 ("net: hns3: add debugfs support for tm nodes, priority
> and qset info")
> Signed-off-by: Colin Ian King
Reviewed-by: Jesse Brandeburg
Loic Poulain wrote:
> When device side MTU is larger than host side MTU, the packets
> (typically rmnet packets) are split over multiple MHI transfers.
> In that case, fragments must be re-aggregated to recover the packet
> before forwarding to upper layer.
>
> A fragmented packet result in -EOVE
Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in a netdev_warn message. Fix it.
>
> Signed-off-by: Colin Ian King
Trivial patch, looks fine!
Reviewed-by: Jesse Brandeburg
Sebastian Andrzej Siewior wrote:
> Patch #2 fixes an issue in which del_timer_sync() and tasklet_kill() is
> invoked from the interrupt handler. This is probably a rare error case
> since it disables interrupts / the card in that case.
> Patch #1 converts a worker to use a threaded interrupt which
0 duplex full autoneg on
>
> Signed-off-by: Christina Jacob
> Signed-off-by: Sunil Goutham
> Signed-off-by: Hariprasad Kelam
Reviewed-by: Jesse Brandeburg
e frame use: No
> Advertised auto-negotiation: No
> Advertised FEC modes: None
>
> ethtool lbk0
> Settings for lbk0:
> Speed: 10Mb/s
> Duplex: Full
>
> Signed-off-by: Christina Jacob
> Signed-off-by: Sunil Goutham
> Signed-
gt; Signed-off-by: Sunil Goutham
> Signed-off-by: Hariprasad Kelam
Reviewed-by: Jesse Brandeburg
adds mailbox handler set_link_mode, fw_data_get to
> configure and read these parameters.
>
> Signed-off-by: Christina Jacob
> Signed-off-by: Sunil Goutham
> Signed-off-by: Hariprasad Kelam
Reviewed-by: Jesse Brandeburg
CMD_GET_PHY_FEC_STATS, also add CGX_CMD_PRBS and
> CGX_CMD_DISPLAY_EYE to enum cgx_cmd_id so that Linux's enum list is in sync
> with firmware's enum list.
>
> Signed-off-by: Felix Manlunas
> Signed-off-by: Christina Jacob
> Signed-off-by: Sunil Kovvuri Goutham
>
- ethtool --show-fec eth0
>
> Signed-off-by: Christina Jacob
> Signed-off-by: Sunil Goutham
> Signed-off-by: Hariprasad Kelam
Reviewed-by: Jesse Brandeburg
Signed-off-by: Sunil Goutham
> Signed-off-by: Hariprasad Kelam
Reviewed-by: Jesse Brandeburg
he previous posting of v3 that it looked good.
Reviewed-by: Jesse Brandeburg
first argument of
> skb_propagate_pfmemalloc().
> In Page Pool core code, it can be simply inlined instead.
> Most of the callers from NIC drivers were just doppelgangers of
> the same condition tests. Derive them into a new common function
> do deduplicate the code.
This is a useful cleanup! Thanks.
Fo
ellanox/mlx5/core/en_rx.c | 7 +--
> include/linux/skbuff.h| 15 +++
> 11 files changed, 27 insertions(+), 83 deletions(-)
For the patch, and esp. for the Intel drivers:
Reviewed-by: Jesse Brandeburg
to call napi_gro_frags() if prior
> napi_get_frags() has failed.
>
> Note that I have left the gro_dropped variable. I leave to ice
> maintainers the decision to further remove it from ethtool -S results.
>
> Signed-off-by: Eric Dumazet
> Cc: Jesse Brandeburg
Acked-by: Jess
Eric Dumazet wrote:
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -6071,6 +6071,7 @@ static gro_result_t napi_skb_finish(struct
> > napi_struct *napi,
> > break;
> >
> > case GRO_DROP:
> > + atomic_long_inc(&skb->dev->rx_dropped);
> >
Shannon Nelson wrote:
> On 1/6/21 1:55 PM, Jesse Brandeburg wrote:
> > When drivers call the various receive upcalls to receive an skb
> > to the stack, sometimes that stack can drop the packet. The good
> > news is that the return code is given to all the drivers of
> &
The driver was counting GRO drops but now that the stack
does it with the previous patch, the driver can drop
all the logic. The driver keeps the dev_dbg message in order
to do optional detailed tracing.
This mostly undoes commit a8fffd7ae9a5 ("ice: add useful statistics").
Signed-off
the same, just scoped too small.
Jesse Brandeburg (2):
net: core: count drops from GRO
ice: remove GRO drop accounting
drivers/net/ethernet/intel/ice/ice.h | 1 -
drivers/net/ethernet/intel/ice/ice_ethtool.c | 1 -
drivers/net/ethernet/intel/ice/ice_main.c | 4 +---
drivers/net
y existing statistic
update for NET_RX_DROP events for the two GRO_DROP locations, and
increment the dev->rx_dropped associated with the skb.
Signed-off-by: Jesse Brandeburg
Cc: Eric Dumazet
Cc: Jamal Hadi Salim
---
net/core/dev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/core/dev
Xiaohui Zhang wrote:
> From: Zhang Xiaohui
>
> If the hardware receives an oversized packet with too many rx fragments,
> skb_shinfo(skb)->frags can overflow and corrupt memory of adjacent pages.
> This becomes especially visible if it corrupts the freelist pointer of
> a slab page.
As I replie
Xiaohui Zhang wrote:
> From: Zhang Xiaohui
>
> If the hardware receives an oversized packet with too many rx fragments,
> skb_shinfo(skb)->frags can overflow and corrupt memory of adjacent pages.
> This becomes especially visible if it corrupts the freelist pointer of
> a slab page.
>
> Signed-
Alexander Duyck wrote:
> > > I'm not sure this logic is correct. Can the flow director rules
> > > handle
> > > a field that is removed? Last I knew it couldn't. If that is the case
> > > you should be using ACL for any case in which a full mask is not
> > > provided. So in your tests below you co
h needs more discussion.
> V3 - fix a typo error in #1 reported by Jakub Kicinski.
> rewrite #9 commit log.
> remove #11 from this series.
> V2 - reorder #2 & #3 to fix compiler error.
> fix some checkpatch warnings in #10 & #11.
For the series:
Reviewed-by: Jesse Brandeburg
s for fixing these warnings!
Reviewed-by: Jesse Brandeburg
places which made use of this implicit include.
>
> Acked-by: Johannes Berg
> Signed-off-by: Jakub Kicinski
Reviewed-by: Jesse Brandeburg
Moshe Shemesh wrote:
> From: Vladyslav Tarasiuk
>
> CMIS 4.0 document describes a universal EEPROM memory layout, which is
> used for some modules such as DSFP, OSFP and QSFP-DD modules. In order
> to distinguish them in userspace from existing standards, add
> corresponding values.
>
> CMIS 4.
+--
> 1 file changed, 35 insertions(+), 20 deletions(-)
>
For the series:
Reviewed-by: Jesse Brandeburg
Zhang Changzhong wrote:
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
>
> Fixes: b66c7bc1cd4d ("iavf: Refactor init state machine")
> Reported-by: Hulk Robot
> Signed-off-by: Zhang Changzhong
Christian Langrock wrote:
Please fix your subject, remove the word 'Subject: '
> Xfrm_dev_offload_ok() is called with the unencrypted SKB. So in case of
> interfamily ipsec traffic (IPv4-in-IPv6 and IPv6 in IPv4) the check
> assumes the wrong family of the skb (IP family of the state).
> With thi
fixes it!
> >
> > You can add a:
> > Tested-by: Ian Kumlien
>
> Will do, thanks!
>
> Tony, should I apply directly to net?
Thank you Kuba!
Seems like a pretty straight forward bug-fix. I recommend
you apply it directly.
Acked-by: Jesse Brandeburg
Vladimir Oltean wrote:
> On Fri, Oct 16, 2020 at 02:36:25PM -0700, Jesse Brandeburg wrote:
> > > Signed-off-by: zhudi
> >
> > Kernel documentation says for you to use your real name, please do so,
> > unless you're a rock star and have officially changed your
Jakub Kicinski wrote:
> On Fri, 16 Oct 2020 14:23:48 -0700 Jesse Brandeburg wrote:
> > > These are tested to be the latest as part of the tools/lib/bpf build.
> >
> > But you didn't mention why you're making these changes, and you're
> > removing a
Hi Jeff,
Jeff Dike wrote:
Your subject should indicate net or net-next as the tree, please see:
https://www.kernel.org/doc/html/latest/networking/netdev-FAQ.html
> Commit 58956317c8de guarantees arp table entries a five-second lifetime. We
> have some apps which make heavy use of multicast,
there is any horrible side effect of using synchronize_rcu_expedited(),
but FWIW:
Reviewed-by: Jesse Brandeburg
>
> Tested with fib_nexthops.sh which includes torture tests that prompted
> the initial change:
>
> # ./fib_nexthops.sh
> ...
> Tests passed: 134
> Tests
zhudi wrote:
> "ip addr show" command execute error when we have a physical
> network card with number of VFs larger than 247.
Oh man, this bug has been hurting us forever and I've tried to fix it
several times without much luck, so thanks for working on it!
CC: David Ahern
As he's mentioned t
Grygorii Strashko wrote:
> Hi
>
> This series adds multi-port support in mac-only mode (multi MAC mode) to TI
> AM65x CPSW driver in preparation for enabling support for multi-port devices,
> like Main CPSW0 on K3 J721E SoC or future CPSW3g on K3 AM64x SoC.
For the series
Rev
Hi Ian,
Ian Rogers wrote:
> These are tested to be the latest as part of the tools/lib/bpf build.
But you didn't mention why you're making these changes, and you're
removing a lot of comments without explaining why/where there might be
a replacement or why the comments are useless. I now see tha
ff-by: Subbaraya Sundeep
> Signed-off-by: Sunil Goutham
> Signed-off-by: Rakesh Babu
LGTM
Reviewed-by: Jesse Brandeburg
From: Jesse Brandeburg
kernel-doc script as used by W=1, is confused by the macro
usage inside the header describing the efx_ptp_data struct.
drivers/net/ethernet/sfc/ptp.c:345: warning: Function parameter or member
'MC_CMD_PTP_IN_TRANSMIT_LENMAX' not described in 'efx_ptp_da
From: Jesse Brandeburg
The W=1 builds showed a few files exporting functions
(non-static) that were not prototyped. What actually happened is
that there were prototypes, but the include file was forgotten in
the implementation file.
Add the include file and remove the warnings.
Fixed Warnings
From: Jesse Brandeburg
A couple of drivers had a "generic documentation" section that
would trigger a "can't understand" message from W=1 compiles.
Fix by using correct DOC: tags in the generic sections.
Fixed Warnings:
drivers/net/ethernet/arc/emac_arc.c:4: info: S
From: Jesse Brandeburg
As part of the W=1 compliation series, these lines all created
warnings about unused variables that were assigned a value. Most
of them are from register reads, but some are just picking up
a return value from a function and never doing anything with it.
Fixed warnings
From: Jesse Brandeburg
The Goal: move to W=1 being default for drivers/net/ethernet, and
then use automation to catch more code issues (warnings) being
introduced.
The status: Getting much closer but not quite done for all
architectures.
After applying the patches below, the drivers/net
From: Jesse Brandeburg
Remove variables that were storing a return value from a register
read or other read, where the return value wasn't used. Those
conversions to remove the lvalue of the assignment should be safe
because the readl memory mapped reads are marked volatile and
should n
From: Jesse Brandeburg
This takes care of all of the trivial W=1 fixes in the Intel
Ethernet drivers, which allows developers and maintainers to
build more of the networking tree with more complete warning
checks.
There are three classes of kdoc warnings fixed:
- cannot understand function
From: Jesse Brandeburg
As part of the W=1 series for ethernet, these drivers were
discovered to be using kdoc style comments but were not actually
doing kdoc. The kernel uses kdoc style when documenting code, not
doxygen or other styles.
Fixed Warnings:
drivers/net/ethernet/amazon/ena/ena_com.c
From: Jesse Brandeburg
While fixing the W=1 builds, this warning came up because the
developers used a very tricky way to get structures initialized
to a non-zero value, but this causes GCC to warn about an
override. In this case the override was intentional, so just
disable the warning for this
ue, right? I'm sure ixgbe and ice both have this problem
too, you should fix them as well, at a minimum, and probably other
vendors drivers:
$ rg -c --stats num_online_cpus drivers/net/ethernet
...
50 files contained matches
for this patch i40e
Acked-by: Jesse Brandeburg
Nitesh Narayan Lal wrote:
> Introduce a new API num_housekeeping_cpus(), that can be used to retrieve
> the number of housekeeping CPUs by reading an atomic variable
> __num_housekeeping_cpus. This variable is set from housekeeping_setup().
>
> This API is introduced for the purpose of drivers th
Jakub Kicinski wrote:
> struct ethtool_fecparam carries bitmasks not bit numbers.
> We want to return 1 (NONE), not 0.
>
> Fixes: 0d0870938337 ("nfp: implement ethtool FEC mode settings")
> Signed-off-by: Jakub Kicinski
Good catch!
Reviewed-by: Jesse Brandeburg
Saeed Mahameed wrote:
> On Mon, 2020-09-14 at 18:44 -0700, Jesse Brandeburg wrote:
> > While fixing the W=1 builds, this warning came up because the
> > developers used a very tricky way to get structures initialized
> > to a non-zero value, but this causes GCC to warn abou
David Miller wrote:
> Jesse, in all of these patches, I want to see the warning you are
> fixing in the commit message.
>
> Especially for the sh_eth.c one because I have no idea what the
> compiler is actually warning about just by reading your commit
> message and patch on it's own.
Ok, I'll re
Saeed Mahameed wrote:
> Reviewed-by: Saeed Mahameed
Thanks! In all fairness, Jakub reviewed this in v1 too but I made enough
changes in v2 that I felt I had to drop the previous review ACKs.
> Hi Jesse,
> What was the criteria to select which drivers to enable in your .config
> ?
As Jakub said
results
in disabling the warning for compiles on GCC versions after 8.
NOTE: the __diag_ignore macro currently only accepts a second
argument of 8 (version 8)
Signed-off-by: Jesse Brandeburg
---
drivers/net/ethernet/renesas/sh_eth.c | 10 ++
1 file changed, 10 insertions(+)
diff
or debug scenario.
Only compile tested with W=1.
Signed-off-by: Jesse Brandeburg
---
v2: addressed some comments and got rid of a few kdoc changes that snuck
into this version.
---
drivers/net/ethernet/brocade/bna/bnad.c | 7 ++--
.../ethernet/cavium/liquidio/octeon_device.c | 9
to use a
variable after it's assignment.
Inspired by Lee Jones' series of wireless work to do the same.
Compile tested only.
Signed-off-by: Jesse Brandeburg
---
drivers/net/ethernet/intel/e100.c | 2 +-
drivers/net/ethernet/intel/e1000/e1000_hw.c | 8 +--
drivers/ne
ut an lvalue (I suspect a very
long time ago this wasn't guaranteed as it is today).
These changes are part of a separate patch to make it easier to review.
Signed-off-by: Jesse Brandeburg
---
drivers/net/ethernet/intel/e100.c | 6 +-
drivers/net/ethernet/intel/e1000/e1000_
As part of the W=1 series for ethernet, these drivers were discovered to
be using kdoc style comments but were not actually doing kdoc. The kernel
uses kdoc style when documenting code, not doxygen or other styles.
Signed-off-by: Jesse Brandeburg
---
drivers/net/ethernet/amazon/ena/ena_com.c
The W=1 builds showed a few files exporting functions
(non-static) that were not prototyped. What actually happened is
that there were prototypes, but the include file was forgotten in
the implementation file.
Add the include file and remove the warnings.
Signed-off-by: Jesse Brandeburg
A couple of drivers had a "generic documentation" section that
would trigger a "can't understand" message from W=1 compiles.
Fix by using correct DOC: tags.
Signed-off-by: Jesse Brandeburg
---
drivers/net/ethernet/arc/emac_arc.c | 2 +-
drivers/net/ethernet/cad
- re-split the Intel patches into functional and kdoc only
- split out the sfc changes that generated discussion to
a single patch.
Jesse Brandeburg (10):
i40e: prepare flash string in a simpler way
intel-ethernet: clean up W=1 warnings in kdoc
intel: handle unused a
makes sure the buffer is terminated
cleanly.
I didn't mark this with a fixes tag as there is no apparent bug since
the existing code would limit the input data + path to be the right
size, but it does fix the W=1 warning.
Signed-off-by: Jesse Brandeburg
---
drivers/net/ethernet/intel
scussion on the list, break this patch out to
a separate one, and fix the issue through a creative
macro declaration.
Signed-off-by: Jesse Brandeburg
Cc: Edward Cree
---
drivers/net/ethernet/sfc/mcdi.h | 1 +
drivers/net/ethernet/sfc/ptp.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
Li RongQing wrote:
> when changes the rx/tx ring to 4096, kzalloc may fail due to
> a temporary shortage on slab entries.
>
> so using kvmalloc to allocate this memory as there is no need
> that this memory area is physical continuously.
>
> and using __GFP_RETRY_MAYFAIL to allocate from kmalloc
Li RongQing wrote:
> when changes the rx/tx ring to 4096, rx/tx_bi needs an order
> 5 pages, and allocation maybe fail due to memory fragmentation
> so switch to kvzalloc
Hi Li,
Thanks for your patches, but I think you're solving a problem that isn't
a problem (besides that the warning is being p
ggested-by: Arkadiusz Zema
> Suggested-by: Daniel Borkmann
Patch seems to make sense to me, better matches the expectations/path
of the stack.
Reviewed-by: Jesse Brandeburg
Edward Cree wrote:
> On 11/09/2020 23:26, Jakub Kicinski wrote:
> > #declare _MCDI_BUF_LEN(_len) DIV_ROUND_UP(_len, 4)
> >
> > efx_dword_t txbuf[_MCDI_BUF_LEN(MC_CMD_PTP_IN_TRANSMIT_LENMAX)];
> >
> > Would that work?
> That could work, yes. Though, probably lose the leading underscore
> in
Vinicius Costa Gomes wrote:
> > diff --git a/drivers/net/ethernet/intel/e1000/e1000_hw.c
> > b/drivers/net/ethernet/intel/e1000/e1000_hw.c
> > index 4e7a0810eaeb..2120dacfd55c 100644
> > --- a/drivers/net/ethernet/intel/e1000/e1000_hw.c
> > +++ b/drivers/net/ethernet/intel/e1000/e1000_hw.c
> > @
Edward Cree wrote:
> On 11/09/2020 02:23, Jesse Brandeburg wrote:
> > + * @MC_CMD_PTP_IN_TRANSMIT_LENMAX: hack to get W=1 to compile
> I think I'd rather have a bogus warning than bogus kerneldocto suppress it;
> please drop this line (and encourage toolchain folks to figu
Jakub Kicinski wrote:
> Yeah, maybe you need COMPILE_TEST? (full list of the warnings triggered
> by the last patch at the end of the email)
Ah, good idea, I checked and I have that set, however, I understand
what's going on now.
> > but I'd like to target the actual job you're running and use
Jakub Kicinski wrote:
> On Thu, 10 Sep 2020 18:23:26 -0700 Jesse Brandeburg wrote:
> > Some of these patches are already sent to Intel Wired Lan, but the rest
> > of the series titled drivers/net/ethernet affects other drivers, not
> > just Intel, but they depend on the f
Inspired by Lee Jones, this eliminates the remaining W=1 warnings in
ixgbe.
Signed-off-by: Jesse Brandeburg
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 ++-
drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 8
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a
Inspired by Lee Jones, this eliminates the remaining W=1 warnings
in iavf.
Signed-off-by: Jesse Brandeburg
---
drivers/net/ethernet/intel/iavf/iavf_main.c | 24 ++---
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c
b
1 - 100 of 399 matches
Mail list logo
