| Age | Commit message (Collapse) | Author |
|---|
|
bpfilter_process_sockopt is a callback that gets called from
ip_setsockopt() and ip_getsockopt(). However, when CONFIG_INET is
disabled, it never gets called at all, and assigning a function to the
callback pointer results in a link failure:
net/bpfilter/bpfilter_kern.o: In function `__stop_umh':
bpfilter_kern.c:(.text.unlikely+0x3): undefined reference to `bpfilter_process_sockopt'
net/bpfilter/bpfilter_kern.o: In function `load_umh':
bpfilter_kern.c:(.init.text+0x73): undefined reference to `bpfilter_process_sockopt'
Since there is no caller in this configuration, I assume we can
simply make the assignment conditional.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
nospec quite reasonably asserts that it will never be used with an index
larger than unsigned long (that being the largest possibly index into an
C array). However, our ubi uses the convention of u64 for any large
integer, running afoul of the assertion on 32b. Reduce our index to an
unsigned long, checking for type overflow first.
drivers/gpu/drm/i915/i915_query.c: In function 'i915_query_ioctl':
include/linux/compiler.h:339:38: error: call to '__compiletime_assert_119' declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long)
Reported-by: kbuild-all@01.org
Fixes: 84b510e22da7 ("drm/i915/query: Protect tainted function pointer lookup")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180522121018.15199-1-chris@chris-wilson.co.uk
(cherry picked from commit a33b1dc8a732144e11cb4bf067d24ba51e6b8ab0)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
The highmem conversion caused a build error in some configurations:
drivers/mmc/host/mxcmmc.c: In function 'mxcmci_transfer_data':
drivers/mmc/host/mxcmmc.c:622:10: error: implicit declaration of function 'kmap_atomic'; did you mean 'in_atomic'? [-Werror=implicit-function-declaration]
This includes the correct header file.
Fixes: b189e7589f6d ("mmc: mxcmmc: handle highmem pages")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
The newly added runtime-pm functions cause a harmless warning
when CONFIG_PM is disabled:
drivers/mmc/host/sunxi-mmc.c:1452:12: error: 'sunxi_mmc_runtime_suspend' defined but not used [-Werror=unused-function]
static int sunxi_mmc_runtime_suspend(struct device *dev)
^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/mmc/host/sunxi-mmc.c:1435:12: error: 'sunxi_mmc_runtime_resume' defined but not used [-Werror=unused-function]
static int sunxi_mmc_runtime_resume(struct device *dev)
This marks them as __maybe_unused to shut up the warning.
Fixes: 9a8e1e8cc2c0 ("mmc: sunxi: Add runtime_pm support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
This drastically reduces the rate at which the MMC_SEND_STATUS cmd polls
for completion of the MMC Erase operation. The patch does this by adding
a backoff sleep that starts by sleeping for short intervals (128-256us),
and ramps up to sleeping for 32-64ms.
Even on very quickly completing erase operations, the loop iterates a few
times, so not too much extra latency is added to these commands.
For long running discard operarations, like a full-device secure discard,
this change drops the interrupt rates on my single-core NXP I.MX6UL from
45000/s to about 20/s, and greatly improves system responsiveness.
Signed-off-by: Martin Hicks <mort@bork.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Use kmap_atomic to map the scatterlist entry before using it.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
This change uses the appropriate _cansleep or non-sleeping API for
reading GPIO card detect state. This allows users with GPIOs that
never sleep to avoid a warning when certain quirks are present.
The sdhci controller has an SDHCI_QUIRK_NO_CARD_NO_RESET, which
indicates that a controller will not reset properly if no card is
inserted. With this quirk enabled, mmc_get_cd_gpio is called in
several places with a spinlock held and interrupts disabled.
gpiod_get_raw_value_cansleep is not happy with this situation,
and throws out a warning.
For boards that a) use controllers that have this quirk, and b) wire
card detect up to a GPIO that doesn't sleep, this is a spurious warning.
This change silences that warning, at the cost of pushing this problem
down to users that have sleeping GPIOs and controllers with this quirk.
Signed-off-by: Evan Green <evgreen@chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
I noticed below error msg with sdhci-pxav3 on some berlin platforms:
[.....] sdhci-pxav3 f7ab0000.sdhci failed to add host
It is due to getting related vmmc or vqmmc regulator returns
-EPROBE_DEFER. It doesn't matter at all but it's confusing.
>From another side, if driver probing fails and the error number isn't
-EPROBE_DEFER, the core will tell us something as below:
[.....] sdhci-pxav3: probe of f7ab0000.sdhci failed with error -EXX
So it's not necessary to emit error msg if sdhci_add_host() fails. And
some other sdhci host drivers also have this issue, let's fix them
together.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Add a new define for the sd default speed 25MHz case
Signed-off-by: Yinbo Zhu <yinbo.zhu@nxp.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Move the calls to ->prepare_hs400_tuning(), from mmc_retune() into
mmc_hs400_to_hs200(), as it better belongs there, rather than being generic
to all type of cards.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
|
|
Just a code refactoring to use the common helper for the all three
functions.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
This patch adds the mute LED control for HP Spectre x360 Kabylake
model. The mute LED is controlled via VREF bits on NID 0x1b, so we
need a new fixup function.
Note that this doesn't fix the other issues like the missing speaker
output on the machine. They will be addressed by later patches.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=189331
Signed-off-by: Tom Briden <tom@decompile.me.uk>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Currently, USB-audio driver allocates the PCM buffer via vmalloc(), as
this serves merely as an intermediate buffer that is copied to each
URB transfer buffer. This works well in general on x86, but on some
archs this may result in cache coherency issues when mmap is used.
OTOH, it works also on such arch unless mmap is used.
This patch is a step for mitigating the inconvenience; a new module
option "use_vmalloc" is provided so that user can choose to allocate
the DMA coherent buffer instead of the existing vmalloc buffer.
The drawback is that it'd be the standard dma_alloc_coherent() calls
and the system would require contiguous pages on non-x86 archs.
Note that it's a global option and not dynamically switchable since
the buffer is pre-allocated at the probe time. In theory, it's
possible to be switchable, but it'd be trickier and racier.
As default use_vmalloc option is set to true, so that the old behavior
is kept. For allowing the coherent mmap on ARM or MIPS, pass
use_vmalloc=0 option explicitly.
Reported-and-tested-by: Daniel Danzberger <daniel@dd-wrt.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Power-saving is causing a humming sound when active on the Intel
NUC5i7RY, add it to the blacklist.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199607
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
When there are 16 or more logical CPUs, we request for
`IWL_MAX_RX_HW_QUEUES` (16) IRQs only as we limit to that number of
IRQs, but later on we compare the number of IRQs returned to
nr_online_cpus+2 instead of max_irqs, the latter being what we
actually asked for. This ends up setting num_rx_queues to 17 which
causes lots of out-of-bounds array accesses later on.
Compare to max_irqs instead, and also add an assertion in case
num_rx_queues > IWM_MAX_RX_HW_QUEUES.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=199551
Fixes: 2e5d4a8f61dc ("iwlwifi: pcie: Add new configuration to enable MSIX")
Signed-off-by: Hao Wei Tee <angelsl@in04.sg>
Tested-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
This reverts commit fb47ada8dc3c30c8e7b415da155742b49536c61e.
In some situations when we set TXOP_BACKOFF, the probe frame is
not sent at all. What it worse then sending probe frame as part
of AMPDU and can degrade 11n performance to 11g rates.
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Remove and refactor some code in order to avoid having identical code
for different branches.
Notice that the logic has been there since 2014.
Addresses-Coverity-ID: 1426199 ("Identical code for different branches")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Active scan is not allowed on radar channel, instead
using passvie scan with more time.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
If firmware does not support embedded supplicant, then it in turn
will not support GT rekey offloading. If this is the case, then
driver must not advertise WOWLAN flags related to GTK rekey and
it must also skip sending the GT_REKEY_OFFLOAD_CFG command.
Signed-off-by: Shrenik Shikhare <shrenik@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Race condition is observed during rmmod of mwifiex_usb:
1. The rmmod thread will call mwifiex_usb_disconnect(), download
SHUTDOWN command and do wait_event_interruptible_timeout(),
waiting for response.
2. The main thread will handle the response and will do a
wake_up_interruptible(), unblocking rmmod thread.
3. On getting unblocked, rmmod thread will make rx_cmd.urb = NULL in
mwifiex_usb_free().
4. The main thread will try to resubmit rx_cmd.urb in
mwifiex_usb_submit_rx_urb(), which is NULL.
To fix, wait for main thread to complete before calling
mwifiex_usb_free().
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
This is a follow-up patch for commit 21c5c83ce833
("mwifiex: support sysfs initiated device coredump").
Let us avoid exporting mwifiex_send_cmd and instead use a utility
function mwifiex_fw_dump_event to achive the work.
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Trivial fix to spelling mistake in rsi_dbg message text
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
the wl pointer can be null In case only wlcore_sdio is probed while
no WiLink module is successfully probed, as in the case of mounting a
wl12xx module while using a device tree file configured with wl18xx
related settings.
In this case the system was crashing in wl1271_suspend() as platform
device data is not set.
Make sure wl the pointer is valid before using it.
Signed-off-by: Eyal Reizer <eyalr@ti.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
add pci_disable_device in error handling while init_atmel_card failed.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
In former patch, I enqueu all C2H commands and processed by a workqueue.
In case C2H_BT_INFO will issue a H2C command to set BT reg, and wait for
a C2H ack. But it is totally impossible that C2H workqueue waits for a
C2H command, so kernel log warn
rtlwifi: :<0> btmpinfo wait (req_num=0) timeout
Since the C2H ack command C2H_BT_MP can be safely processed in interrupt
context, add a fast command path to deal with the command.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
The format of C2H data is ID(1 byte) + Length(1 byte) + value, and it is
more readable to use macros to access C2H data.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
We use 'struct rtl_c2hcmd' to store C2H commands originally, and the code
is slightly complex to enqueue and dequeue and also wastes time to
allocate and memcpy data. Since C2H commands are asynchronous events,
they can be processed in work queue, so RX ISR enqueues C2H result in
removal of rtl_c2h_packet_handler().
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Similar to rx_command_packet, we can call rtl_c2h_content_parsing so the
hal_op isn't necessary.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Because the hal_op rx_command_packet does C2H handler if rx packet type
is C2H, and the handler have been moved to base.c so we can call the
handler directly.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Merge duplicate C2H handler and implement the handler in base.c.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
We're going to merge C2H handler into one, but one special case is to
handle RA_REPORT that implements in individual IC folder. So this commit
adds a hal_op for caller in common code.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
The caller of hal_op rx_command_packet will assert function pointer
before calling, so we can remove dummy functions safely.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
The IDs are defined by driver and map to the fw C2H IDs, but they aren't
used now result in removal.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Move C2H definition to wifi.h, because the definitions of 8192ee, 8723be
and 8821ae are the same.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Current chips use packet-based C2H commands whose IDs differ from old
ones, so this commit simply gives C2H_V0_ as prefix of command IDs.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Move duplicate definitions from def.h of ic folder to wifi.h
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
To use keep-alive mechanism in mac80211 stack, since driver supports
reporting accurate nullfunc frame tx ack now.
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
In order to realize the keep-alive mechanism in mac80211 stack, reporting
accurate tx ack status for nullfunc frame is added in this commit.
If current frame is nullfunc frame, we ask firmware to report by filling
TX report bit in TX descriptor. After this frame DMA done, TX interrupt is
triggered but TX status is unknown at this moment, so enqueue this skb
into tx_report->queue. Finally, C2H report will be received if the frame
is transmitted successfully or retried over, and then we report to mac80211
with IEEE80211_TX_STAT_ACK flag only if it's successful. Otherwise, if
failure or timeout (one second), we report to mac80211 without this flag.
Signed-off-by: Tzu-En Huang <tehuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
We can have pm_runtime_get_sync() return 1, and we can have
pm_runtime_put_sync() return -EBUSY. See rpm_suspend() and
rpm_resume() for more information.
Fix the issue by returning 0 from wl12xx_sdio_power_on() on success.
And use pm_runtime_put() instead of pm_runtime_put_sync() for
wl12xx_sdio_power_off(), then the MMC subsystem will idle the bus
when suitable.
Otherwise wlcore can sometimes get confused and may report bogus
errors and WLAN connection can fail.
Note that while wlcore checks the return value for wl1271_power_on(),
the return value is ignored for wl1271_power_off(). Let's fix them
both though to avoid further confusion in the future.
Fixes: 60f36637bbbd ("wlcore: sdio: allow pm to handle sdio power")
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
gcc-8 warns that pcm_instance->name is not necessarily terminated correctly
if the input is more than 80 characters long or lacks a termination byte
itself:
In function 'strncpy',
inlined from 'cfg_device' at sound/xen/xen_snd_front_cfg.c:399:3,
inlined from 'xen_snd_front_cfg_card' at sound/xen/xen_snd_front_cfg.c:509:9:
include/linux/string.h:254:9: error: '__builtin_strncpy' specified bound 80 equals destination size [-Werror=stringop-truncation]
return __builtin_strncpy(p, q, size);
Using strlcpy() instead of strncpy() makes this a bit safer.
Fixes: fd3b36045c2c ("ALSA: xen-front: Read sound driver configuration from Xen store")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
working-branch-for-4.18
Signed-off-by: Benson Leung <bleung@chromium.org>
|
|
Without CONFIG_INPUT, or with a modular input layer and built-in
tablet driver, we get a link error:
ERROR: "input_event" [drivers/platform/chrome/chromeos_tbmc.ko] undefined!
ERROR: "input_register_device" [drivers/platform/chrome/chromeos_tbmc.ko] undefined!
ERROR: "input_set_capability" [drivers/platform/chrome/chromeos_tbmc.ko] undefined!
ERROR: "devm_input_allocate_device" [drivers/platform/chrome/chromeos_tbmc.ko] undefined!
This adds the corresponding Kconfig dependency
Fixes: b418f74170d7 ("platform: chrome: Add Tablet Switch ACPI driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Benson Leung <bleung@chromium.org>
|
|
Salil Mehta says:
====================
Misc. bug fixes & some minor additions to HNS3 driver
This patch-set provides some bug fixes figured out during testing
and review. It also provides some additions due to running of the
existing code on the new revision of the HNS3 hardware.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
When register a RoCE client with hnae3vf device, it needs to judge
the device whether support RoCE vf function. Otherwise, it will
lead to calltrace when RoCE is not support vf function and remove
roce device.
The calltrace as follows:
[ 93.156614] Unable to handle kernel NULL pointer dereference at virtual address 00000015
<SNIP>
[ 93.278784] Call trace:
[ 93.278788] hnae3_match_n_instantiate+0x24/0xd8 [hnae3]
[ 93.278790] hnae3_register_client+0xcc/0x150 [hnae3]
[ 93.278801] hns_roce_hw_v2_init+0x18/0x1000 [hns_roce_hw_v2]
[ 93.278805] do_one_initcall+0x58/0x160
[ 93.278807] do_init_module+0x64/0x1d8
[ 93.278809] load_module+0x135c/0x15c8
[ 93.278811] SyS_finit_module+0x100/0x118
[ 93.278816] __sys_trace_return+0x0/0x4
[ 93.278827] Code: aa0003f5 12001c56 aa1e03e0 d503201f (b9402660)
Fixes: e2cb1dec9779 ("net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support")
Reported-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
Reported-by: Zhou Wang <wangzhou1@hisilicon.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Firmware now supports control of all leds. Existing HNS3 driver code
only supported led locate command over SFP Fibre ports. But now it
is also supported over copper port.
This patch removes existing not needed code for the led locate
command and updates the led control command between driver and
firmware.
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
In the previous implementation of led control for fibre port , parses the
port speed configuration, checks the link status and traffic status per
second, and updates the blink status of link led, traffic led and speed
led.
Now, the firmware takes responsibility to handle the led, the dirver just
needs to deal with locate command.
So the codes for link led, traffic led and speed led are useless now. This
patch removes these redundant codes.
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
When we down the port, some packets are left in TX/RX buffer. When we
up the port again, these old packets are forwarded to protocol stack
or are sent to internet. It will make some problem. TX/RX buffer should
be cleared when stopping port. This patch adds some function to ensure
the buffer is clean when port is started. We should clear the rings
when clients are being un-initialized as well.
Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC")
Signed-off-by: Fuyun Liang <liangfuyun1@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Our code will ensure that hns3_clear_tx_ring is not used to cleared
RX rings and hns3_clear_rx_ring is not used to cleared TX rings. So
the ring type check is unnecessary.
Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC")
Signed-off-by: Fuyun Liang <liangfuyun1@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
