| Message ID | 57fd4501-4f13-37ee-d7f0-cda8b369bba6@solarflare.com |
|---|---|
| Headers | show |
| Series | sfc: clean up some W=1 build warnings | expand |
On Fri, 28 Aug 2020 18:48:25 +0100 Edward Cree wrote: > A collection of minor fixes to issues flagged up by W=1. > After this series, the only remaining warnings in the sfc driver are > some 'member missing in kerneldoc' warnings from ptp.c. > Tested by building on x86_64 and running 'ethtool -p' on an EF10 NIC; > there was no error, but I couldn't observe the actual LED as I'm > working remotely. LGTM, although borderline net if you ask me. Reviewed-by: Jakub Kicinski <kuba@kernel.org> > [ Incidentally, ethtool_phys_id()'s behaviour on an error return > looks strange — if I'm reading it right, it will break out of the > inner loop but not the outer one, and eventually return the rc > from the last run of the inner loop. Is this intended? ] I think you're right. Care to fix?
From: Edward Cree <ecree@solarflare.com> Date: Fri, 28 Aug 2020 18:48:25 +0100 > A collection of minor fixes to issues flagged up by W=1. > After this series, the only remaining warnings in the sfc driver are > some 'member missing in kerneldoc' warnings from ptp.c. > Tested by building on x86_64 and running 'ethtool -p' on an EF10 NIC; > there was no error, but I couldn't observe the actual LED as I'm > working remotely. > > [ Incidentally, ethtool_phys_id()'s behaviour on an error return > looks strange ― if I'm reading it right, it will break out of the > inner loop but not the outer one, and eventually return the rc > from the last run of the inner loop. Is this intended? ] Series applied, thanks.
A collection of minor fixes to issues flagged up by W=1. After this series, the only remaining warnings in the sfc driver are some 'member missing in kerneldoc' warnings from ptp.c. Tested by building on x86_64 and running 'ethtool -p' on an EF10 NIC; there was no error, but I couldn't observe the actual LED as I'm working remotely. [ Incidentally, ethtool_phys_id()'s behaviour on an error return looks strange — if I'm reading it right, it will break out of the inner loop but not the outer one, and eventually return the rc from the last run of the inner loop. Is this intended? ] Edward Cree (4): sfc: fix W=1 warnings in efx_farch_handle_rx_not_ok sfc: fix unused-but-set-variable warning in efx_farch_filter_remove_safe sfc: fix kernel-doc on struct efx_loopback_state sfc: return errors from efx_mcdi_set_id_led, and de-indirect drivers/net/ethernet/sfc/ef10.c | 2 -- drivers/net/ethernet/sfc/ethtool.c | 3 +-- drivers/net/ethernet/sfc/farch.c | 9 ++------- drivers/net/ethernet/sfc/mcdi.c | 6 ++---- drivers/net/ethernet/sfc/mcdi.h | 2 +- drivers/net/ethernet/sfc/net_driver.h | 2 -- drivers/net/ethernet/sfc/selftest.c | 2 +- drivers/net/ethernet/sfc/siena.c | 1 - 8 files changed, 7 insertions(+), 20 deletions(-)