There is no case in which the variable cmd_node->cmd_skb has no ->data,
and thus the variable host_cmd is guaranteed to be not NULL. Therefore,
the null-pointer check is redundant and can be dropped.
Reported-by: TOTE Robot <oslab@tsinghua.edu.cn>
Signed-off-by: Tuo Li <islituo@gmail.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210804020305.29812-1-islituo@gmail.com
Use goto labels on error path for probe functions. This makes code easier
to read. With this introduce also netdev_cleanup and call it where
necessary.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210806081229.721731-2-claudiu.beznea@microchip.com
Don't populate arrays the stack but instead make them static const. Replace
array channel_info with channel_all since it contains the same data as
channel_all. Makes object code smaller by 961 bytes.
Before:
text data bss dec hex filename
128147 44250 1024 173421 2a56d ../realtek/rtlwifi/rtl8192de/phy.o
After
text data bss dec hex filename
127122 44314 1024 172460 2a1ac ../realtek/rtlwifi/rtl8192de/phy.o
(gcc version 10.2.0)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210803144949.79433-2-colin.king@canonical.com
The variables rtstatus and place are being initialized with a values
that are never read, the initializations are redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210803144949.79433-1-colin.king@canonical.com
Return -ENODEV instead of success for unsupported devices.
Fixes: 54fdb318c1 ("rsi: add new device model for 9116")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210816183947.GA2119@kili
This code returns success if the kmemdup() fails, but obviously it
should return -ENOMEM instead.
Fixes: e5a1ecc97e ("rsi: add firmware loading for 9116 device")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210805103746.GA26417@kili
In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memcpy(), memmove(), and memset(), avoid
intentionally writing across neighboring fields.
Split memcpy() for each address range to help memcpy() correctly reason
about the bounds checking. Avoids the future warning:
In function 'fortify_memcpy_chk',
inlined from 'memcpy_toio' at ./include/asm-generic/io.h:1204:2,
inlined from 'ray_build_header.constprop' at drivers/net/wireless/ray_cs.c:984:3:
./include/linux/fortify-string.h:285:4: warning: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribute-warning]
285 | __write_overflow_field(p_size_field, size);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210819202825.3545692-4-keescook@chromium.org
In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memcpy(), memmove(), and memset(), avoid
intentionally writing across neighboring fields.
libipw_read_qos_param_element() copies a struct libipw_info_element
into a struct libipw_qos_information_element, but is actually wanting to
copy into the larger struct libipw_qos_parameter_info (the contents of
ac_params_record[] is later examined). Refactor the routine to perform
centralized checks, and copy the entire contents directly (since the id
and len members match the elementID and length members):
struct libipw_info_element {
u8 id;
u8 len;
u8 data[];
} __packed;
struct libipw_qos_information_element {
u8 elementID;
u8 length;
u8 qui[QOS_OUI_LEN];
u8 qui_type;
u8 qui_subtype;
u8 version;
u8 ac_info;
} __packed;
struct libipw_qos_parameter_info {
struct libipw_qos_information_element info_element;
u8 reserved;
struct libipw_qos_ac_parameter ac_params_record[QOS_QUEUE_NUM];
} __packed;
Cc: Stanislav Yakovlev <stas.yakovlev@gmail.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210819202825.3545692-2-keescook@chromium.org
Dynamic size calculations (especially multiplication) should not be
performed in memory allocator function arguments due to the risk of them
overflowing. This could lead to values wrapping around and a smaller
allocation being made than the caller was expecting. Using those
allocations could lead to linear overflows of heap memory and other
misbehaviors.
To avoid this scenario, use the struct_size helper.
Signed-off-by: Len Baker <len.baker@gmx.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210717142513.5411-1-len.baker@gmx.com
Add HW and SDIO ids for use with the SparkLan AP6275S
Add the firmware mapping structures for the BRCM43752 chipset.
The 43752 needs some things setup similar to the 43012 chipset.
The WATERMARK shows better performance when initialized to the 4373 value.
Signed-off-by: Angus Ainslie <angus@akkea.ca>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210812165218.2508258-2-angus@akkea.ca
This puts tasks submitted to the SDIO workqueue at the head of the queue
and runs them immediately. This gets higher RX throughput with the SDIO
bus.
This was originally submitted as [1]. The original author Wright Feng
reports
> throughput result with 43455(11ac) on 1 core 1.6 Ghz platform is
> Without WQ_HIGGPRI TX/RX: 293/301 (mbps)
> With WQ_HIGHPRI TX/RX: 293/321 (mbps)
I tested this with a 43364(11bgn) on a 1 core 800 MHz platform and got
Without WQ_HIGHPRI TX/RX: 16/19 (Mbits/sec)
With WQ_HIGHPRI TX/RX: 24/20 (MBits/sec)
[1] https://lore.kernel.org/linux-wireless/1584604406-15452-4-git-send-email-wright.feng@cypress.com/
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Arend van Spriel <aspriel@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210802170904.3116223-1-sean.anderson@seco.com
A separate firmware is needed for Broadcom 43430 revision 2. This
chip can be found in e.g. certain revisions of Ampak AP6212 wireless
IC. Original firmware file from IC vendor is named
'fw_bcm43436b0.bin', but brcmfmac and also btbcm drivers report chip
id 43430, so requested firmware file name is
'brcmfmac43430b0-sdio.bin' in line with other 43430 revisions.
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Mikhail Rudenko <mike.rudenko@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210804231308.576071-1-mike.rudenko@gmail.com
Historically the broadcom wifi chipsets always had enumeration
space containing all core information at same place. However, for
new chipsets the ASIC developers moved away from that given fact.
So we have to accommodate that it can differ per chipset.
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1627505434-9544-5-git-send-email-arend.vanspriel@broadcom.com
Newer firmware API require commands to use xtlv format. Add support
for that in the firmware interface layer.
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1627505434-9544-4-git-send-email-arend.vanspriel@broadcom.com
Some cores are getting a revision greater that 99 thus messing up
the column alignment in the list of cores. So adding a digit for
the core revision.
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1627505434-9544-3-git-send-email-arend.vanspriel@broadcom.com
The function brcmf_chip_tcm_rambase() returns 0 as invalid ram base
address. However, upcoming chips have ram base address starting at
zero so we have to find a more appropriate invalid value to return.
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1627505434-9544-2-git-send-email-arend.vanspriel@broadcom.com
The patch that would first try the board-specific firmware
had a bug because the fallback would not be called: the
asynchronous interface is used meaning request_firmware_nowait()
returns 0 immediately.
Harden the firmware loading like this:
- If we cannot build an alt_path (like if no board_type is
specified) just request the first firmware without any
suffix, like in the past.
- If the lookup of a board specific firmware fails, we get
a NULL fw in the async callback, so just try again without
the alt_path from a dedicated brcm_fw_request_done_alt_path
callback.
- Drop the unnecessary prototype of brcm_fw_request_done.
- Added MODULE_FIRMWARE match for per-board SDIO bins, making
userspace tools to pull all the relevant firmware files.
Fixes: 5ff013914c ("brcmfmac: firmware: Allow per-board firmware binaries")
Cc: Stefan Hansson <newbyte@disroot.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210808180510.8753-1-digetx@gmail.com
* BSS coloring support
* MEI commands for Intel platforms
* various fixes/cleanups
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEH1e1rEeCd0AIMq6MB8qZga/fl8QFAmEfiUEACgkQB8qZga/f
l8QnDRAAiLKYLSfxTCf73KT/cUFOXPAAPG8r23tpgb1h/GgXcTVSTccnBfDWZWnv
cX2YknF2hP3JU4SCjV28io+IvftlYp7gMua8yN6ekMQ31Dzw3kkVQbrNdF7sWglQ
XhLws8KrZ6UwFSxqjSg1cX2oAYb6AwkDy5z+1lX+PxBoH5duVlWzCYe3ohXnuZgR
8Y9iz1eIxCprt1aXSIHyyT96a7TTG552T+FjenZM2+wHDu4sXGJLWSSUkM6rXUQI
bXV1gon50VaqfmbAfusgmhSmmCfHqlx7P0sBKxdJ17WuuBf3FtGLQX07EzBU/0vD
t3jSv4x4tXWhnA+Lyxx89WT13pz89iPnI4OjpxaxE+4wTOeiGrTZcHNMMHrgyEcQ
f1PiEwwsTt5PM4y/e1rhdpm2Mrw3VxDOQ+A/vHPUzoLv7ewehGw8IGw6spocA+QL
1YB3g6tiVPEIbfczTY+qJy8E4MRh93toO3O2DywE+UXxC3OR8Eo/tFB+yREzCnnN
6jAMGrYYDONKSiU3x9NRlV5luqPmUa1Rwjv+dkg+g7jES1hAjZa+oKtPffDzzGOn
C8bsN8TEiMyHtmtgi5IZQTIS0/rqKVV+rgA0DHoTqRVzuInA1Pmrx0k4H6Vy7zGA
HahTJVPoO4VHWTtmztwkbONfEe0hR0OE/MGHgEqzdkbpIqVkMBw=
=q8bL
-----END PGP SIGNATURE-----
Merge tag 'mac80211-next-for-net-next-2021-08-20' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next
Johannes Berg says:
====================
Minor updates:
* BSS coloring support
* MEI commands for Intel platforms
* various fixes/cleanups
* tag 'mac80211-next-for-net-next-2021-08-20' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next:
cfg80211: fix BSS color notify trace enum confusion
mac80211: Fix insufficient headroom issue for AMSDU
mac80211: add support for BSS color change
nl80211: add support for BSS coloring
mac80211: Use flex-array for radiotap header bitmap
mac80211: radiotap: Use BIT() instead of shifts
mac80211: Remove unnecessary variable and label
mac80211: include <linux/rbtree.h>
mac80211: Fix monitor MTU limit so that A-MSDUs get through
mac80211: remove unnecessary NULL check in ieee80211_register_hw()
mac80211: Reject zero MAC address in sta_info_insert_check()
nl80211: vendor-cmd: add Intel vendor commands for iwlmei usage
====================
Link: https://lore.kernel.org/r/20210820105329.48674-1-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Nikolay Aleksandrov says:
====================
net: bridge: mcast: add support for port/vlan router control
This small set adds control over port/vlan mcast router config.
Initially I had added host vlan entry router control via vlan's global
options but that is really unnecessary and we can use a single per-vlan
option to control it both for port/vlan and host/vlan entries. Since
it's all still in net-next we can convert BRIDGE_VLANDB_GOPTS_MCAST_ROUTER
to BRIDGE_VLANDB_ENTRY_MCAST_ROUTER and use it for both. That makes much
more sense and is easier for user-space. Patch 01 prepares the port
router function to be used with port mcast context instead of port and
then patch 02 converts the global vlan mcast router option to per-vlan
mcast router option which directly gives us both host/vlan and port/vlan
mcast router control without any additional changes.
This way we get the following coherent syntax:
[ port/vlan mcast router]
$ bridge vlan set vid 100 dev ens20 mcast_router 2
[ bridge/vlan mcast router ]
$ bridge vlan set vid 100 dev bridge mcast_router 2
instead of:
$ bridge vlan set vid 100 dev bridge mcast_router 1 global
The mcast_router should not be regarded as a global option, it controls
the port/vlan and bridge/vlan mcast router behaviour.
This is the last set needed for the initial per-vlan mcast support.
Next patch-sets:
- iproute2 support
- selftests
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The per-vlan router option controls the port/vlan and host vlan entries'
mcast router config. The global option controlled only the host vlan
config, but that is unnecessary and incosistent as it's not really a
global vlan option, but rather bridge option to control host router
config, so convert BRIDGE_VLANDB_GOPTS_MCAST_ROUTER to
BRIDGE_VLANDB_ENTRY_MCAST_ROUTER which can be used to control both host
vlan and port vlan mcast router config.
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Change br_multicast_set_port_router to take port multicast context as
its first argument so we can later use it to control port/vlan mcast
router option.
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch ensures that mcam flows are allocated
before adding or destroying the flows.
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This silences the following coccinelle warning:
"WARNING: sum of probable bitmasks, consider |"
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: jing yangyang <jing.yangyang@zte.com.cn>
Signed-off-by: David S. Miller <davem@davemloft.net>
Alex Elder says:
====================
net: ipa: kill off ipa_clock_get()
This series replaces the remaining uses of ipa_clock_get() with
calls to pm_runtime_get_sync() instead. It replaces all calls to
ipa_clock_put() with calls to pm_runtime_put().
This completes the preparation for enabling automated suspend under
the control of the power management core code. The next patch (in
an upcoming series) enables that. Then the "ipa_clock" files and
symbols will switch to using an "ipa_power" naming convention instead.
Additional info
It is possible for pm_runtime_get_sync() to return an error. There
are really three cases, identified by return value:
- 1, meaning power was already active
- 0, meaning power was not previously active, but is now
- EACCES, meaning runtime PM is disabled
One additional case is EINVAL, meaning a previous suspend or resume
(or idle) call returned an error. But we have always assumed this
won't happen (we previously didn't even check for an error).
But because we use pm_runtime_force_suspend() to implement system
suspend, there's a chance we'd get an EACCES error (the first thing
that function does is disable runtime suspend). Individual patches
explain what happens in that case, but generally we just accept that
it could be an unlikely problem (occurring only at startup time).
Similarly, pm_runtime_put() could return an error. There too, we
ignore EINVAL, assuming the IPA suspend and resume operations won't
produce an error. EBUSY and EPERM are not applicable, EAGAIN is not
expected (and harmless). We should never get EACCES (runtime
suspend disabled), because pm_runtime_put() calls match prior
pm_runtime_get_sync() calls, and a system suspend will not be
started while a runtime suspend or resume is underway. In summary,
the value returned from pm_runtime_put() is not meaningful, so we
explicitly ignore it.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The only remaining user of the ipa_clock_{get,put}() interface is
ipa_isr_thread(). Replace calls to ipa_clock_get() there calling
pm_runtime_get_sync() instead. And call pm_runtime_put() there
rather than ipa_clock_put(). Warn if we ever get an error.
With that, we can get rid of ipa_clock_get() and ipa_clock_put().
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
When we open or close the modem network device we need to ensure the
hardware is powered. Replace the callers of ipa_clock_get() found
in ipa_open() and ipa_stop() with calls to pm_runtime_get_sync().
If an error is returned, simply return that error to the caller
(without any error or warning message). This could conceivably
occur if the function was called while the system was suspended,
but that really shouldn't happen. Replace corresponding calls to
ipa_clock_put() with pm_runtime_put() also.
If the modem crashes we also need to ensure the hardware is powered
to recover. If getting power returns an error there's not much we
can do, but at least report the error. (Ideally the remoteproc SSR
code would ensure the AP was not suspended when it sends the
notification, but that is not (yet) the case.)
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Replace the ipa_clock_get() call in ipa_uc_clock() when taking the
"proxy" clock reference for the microcontroller with a call to
pm_runtime_get_sync(). Replace calls of ipa_clock_put() for the
microcontroller with pm_runtime_put() calls instead.
There is a chance we get an error when taking the microcontroller
power reference. This is an unlikely scenario, where system suspend
is initiated just before we learn the modem is booting. For now
we'll just accept that this could occur, and report it if it does.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
If the "modem-init" Device Tree property is present for a platform,
the modem performs early IPA hardware initialization, and signals
this is complete with an "ipa-setup-ready" SMP2P interrupt. This
triggers a call to ipa_setup(), which requires the hardware to be
powered.
Replace the call to ipa_clock_get() in this case with a call to
pm_runtime_get_sync(). And replace the corresponding calls to
ipa_clock_put() with calls to pm_runtime_put() instead.
There is a chance we get an error when taking this power reference.
This is an unlikely scenario, where system suspend is initiated just
before the modem signals it has finished initializing the IPA
hardware. For now we'll just accept that this could occur, and
report it if it does.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
We need the hardware to be powered starting at the config stage of
initialization when the IPA driver probes. And we need it powered
when the driver is removed, at least until the deconfig stage has
completed.
Replace callers of ipa_clock_get() in ipa_probe() and ipa_exit(),
calling pm_runtime_get_sync() instead. Replace the corresponding
callers of ipa_clock_put(), calling pm_runtime_put() instead.
The only error we expect when getting power would occur when the
system is suspended. The ->probe and ->remove driver callbacks
won't be called when suspended, so issue a WARN() call if an error
is seen getting power.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jakub Kicinski pointed out a race condition in ipa_start_xmit() in a
recently-accepted series of patches:
https://lore.kernel.org/netdev/20210812195035.2816276-1-elder@linaro.org/
We are stopping the modem TX queue in that function if the power
state is not active. We restart the TX queue again once hardware
resume is complete.
TX path Power Management
------- ----------------
pm_runtime_get(); no power Start resume
Stop TX queue ...
pm_runtime_put() Resume complete
return NETDEV_TX_BUSY Start TX queue
pm_runtime_get()
Power present, transmit
pm_runtime_put() (auto-suspend)
The issue is that the power management (resume) activity and the
network transmit activity can occur concurrently, and there's a
chance the queue will be stopped *after* it has been started again.
TX path Power Management
------- ----------------
Resume underway
pm_runtime_get(); no power ...
Resume complete
Start TX queue
Stop TX queue <-- No more transmits after this
pm_runtime_put()
return NETDEV_TX_BUSY
We address this using a STARTED flag to indicate when the TX queue
has been started from the resume path, and a spinlock to make the
flag and queue updates happen atomically.
TX path Power Management
------- ----------------
Resume underway
pm_runtime_get(); no power Resume complete
start TX queue \
If STARTED flag is *not* set: > atomic
Stop TX queue set STARTED flag /
pm_runtime_put()
return NETDEV_TX_BUSY
A second flag is used to address a different race that involves
another path requesting power.
TX path Other path Power Management
------- ---------- ----------------
pm_runtime_get_sync() Resume
Start TX queue \ atomic
Set STARTED flag /
(do its thing)
pm_runtime_put()
(auto-suspend)
pm_runtime_get() Mark delayed resume
STARTED *is* set, so
do *not* stop TX queue <-- Queue should be stopped here
pm_runtime_put()
return NETDEV_TX_BUSY Suspend done, resume
Resume complete
pm_runtime_get()
Stop TX queue
(STARTED is *not* set) Start TX queue \ atomic
pm_runtime_put() Set STARTED flag /
return NETDEV_TX_BUSY
So a STOPPED flag is set in the transmit path when it has stopped
the TX queue, and this pair of operations is also protected by the
spinlock. The resume path only restarts the TX queue if the STOPPED
flag is set. This case isn't a major problem, but it avoids the
"non-trivial amount of useless work" done by the networking stack
when NETDEV_TX_BUSY is returned.
Fixes: 6b51f802d6 ("net: ipa: ensure hardware has power in ipa_start_xmit()")
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean says:
====================
Small ocelot VLAN improvements
This small series propagates some VLAN restrictions via netlink extack
and creates some helper functions instead of open-coding VLAN table
manipulations from multiple places.
This is split from the larger "DSA FDB isolation" series, hence the v2
tag:
https://patchwork.kernel.org/project/netdevbpf/cover/20210818120150.892647-1-vladimir.oltean@nxp.com/
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
This is a mostly cosmetic patch that creates some helpers for accessing
the VLAN table. These helpers are also a bit more careful in that they
do not modify the ocelot->vlan_mask unless the hardware operation
succeeded.
Not all callers check the return value (the init code doesn't), but anyway.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We need to transmit more restrictions in future patches, convert this
one to netlink extack.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We need to reject some more configurations in future patches, convert
the existing one to netlink extack.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean says:
====================
Ocelot phylink fixes
This series addresses a regression reported by Horatiu which introduced
by the ocelot conversion to phylink: there are broken device trees in
the wild, and the driver fails to probe the entire switch when a port
fails to probe, which it previously did not do.
Continue probing even when some ports fail to initialize properly.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The existing ocelot device trees, like ocelot_pcb123.dts for example,
have SERDES ports (ports 4 and higher) that do not have status = "disabled";
but on the other hand do not have a phy-handle or a fixed-link either.
So from the perspective of phylink, they have broken DT bindings.
Since the blamed commit, probing for the entire switch will fail when
such a device tree binding is encountered on a port. There used to be
this piece of code which skipped ports without a phy-handle:
phy_node = of_parse_phandle(portnp, "phy-handle", 0);
if (!phy_node)
continue;
but now it is gone.
Anyway, fixed-link setups are a thing which should work out of the box
with phylink, so it would not be in the best interest of the driver to
add that check back.
Instead, let's look at what other drivers do. Since commit 86f8b1c01a
("net: dsa: Do not make user port errors fatal"), DSA continues after a
switch port fails to register, and works only with the ports that
succeeded.
We can achieve the same behavior in ocelot by unregistering the devlink
port for ports where ocelot_port_phylink_create() failed (called via
ocelot_probe_port), and clear the bit in devlink_ports_registered for
that port. This will make the next iteration reconsider the port that
failed to probe as an unused port, and re-register a devlink port of
type UNUSED for it. No other cleanup should need to be performed, since
ocelot_probe_port() should be self-contained when it fails.
Fixes: e6e12df625 ("net: mscc: ocelot: convert to phylink")
Reported-and-tested-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There are cases where we would like to continue probing the switch even
if one port has failed to probe. When that happens, we need to
unregister a devlink_port of type DEVLINK_PORT_FLAVOUR_PHYSICAL and
re-register it of type DEVLINK_PORT_FLAVOUR_UNUSED.
This is fine, except when calling devlink_port_attrs_set on a structure
on which devlink_port_register has been previously called, there is a
WARN_ON in devlink_port_attrs_set that devlink_port->devlink must be
NULL.
So don't assume that the memory behind dlp is clean when calling
ocelot_port_devlink_init, just zero-initialize it.
Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean says:
====================
dpaa2-switch phylink fixes
This is fixing two regressions introduced by the recent conversion of
the dpaa2-switch driver to phylink.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently when probing returns an error, the netdev is freed but
phylink_disconnect is not called.
Create a common function between the unbind path and the error path,
call it the opposite of dpaa2_switch_probe_port: dpaa2_switch_remove_port,
and call it from both the unbind and the error path.
Fixes: 84cba72956 ("dpaa2-switch: integrate the MAC endpoint support")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There is an ASSERT_RTNL in phylink_disconnect_phy which triggers
whenever dpaa2_switch_port_disconnect_mac is called.
To follow the pattern established by dpaa2_eth_disconnect_mac, take the
rtnl_mutex every time we call dpaa2_switch_port_disconnect_mac.
Fixes: 84cba72956 ("dpaa2-switch: integrate the MAC endpoint support")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Gerhard Engleder says:
====================
Add Xilinx GMII2RGMII loopback support
The Xilinx GMII2RGMII driver overrides PHY driver functions in order to
configure the device according to the link speed of the PHY attached to
it. This is implemented for a normal link but not for loopback.
Andrew told me to use phy_loopback and this changes make phy_loopback
work in combination with Xilinx GMII2RGMII.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Configure speed if loopback is used. read_status is not called for
loopback.
Signed-off-by: Gerhard Engleder <gerhard@engleder-embedded.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
struct phy_device contains a pointer to the PHY driver and nearly
everywhere this pointer is used to access the PHY driver. Only
mdio_bus_phy_may_suspend() is still using to_phy_driver() instead of the
PHY driver pointer. Uniform PHY driver access by eliminating
to_phy_driver() use in mdio_bus_phy_may_suspend().
Only phy_bus_match() and phy_probe() are still using to_phy_driver(),
because PHY driver pointer is not available there.
Signed-off-by: Gerhard Engleder <gerhard@engleder-embedded.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
phy_read_status and various other PHY functions support PHY specific
overriding of driver functions by using a PHY specific pointer to the
PHY driver. Add support of PHY specific override to phy_loopback too.
Signed-off-by: Gerhard Engleder <gerhard@engleder-embedded.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Steen Hegelund says:
====================
Adding Frame DMA functionality to Sparx5
v2:
Removed an unused variable (proc_ctrl) from sparx5_fdma_start.
This add frame DMA functionality to the Sparx5 platform.
Until now the Sparx5 SwitchDev driver has been using register based
injection and extraction when sending frames to/from the host CPU.
With this series the Frame DMA functionality now added.
The Frame DMA is only used if the Frame DMA interrupt is configured in the
device tree; otherwise the existing register based injection and extraction
is used.
The Sparx5 has two ports that can be used for sending and receiving frames,
but there are 8 channels that can be configured: 6 for injection and 2 for
extraction.
The additional channels can be used for more advanced scenarios e.g. where
virtual cores are used, but currently the driver only uses port 0 and
channel 0 and 6 respectively.
DCB (data control block) structures are passed to the Frame DMA with
suitable information about frame start/end etc, as well as pointers to DB
(data blocks) buffers.
The Frame DMA engine can use interrupts to signal back when the frames have
been injected or extracted.
There is a limitation on the DB alignment also for injection: Block must
start on 16byte boundaries, and this is why the driver currently copies the
data to into separate buffers.
The Sparx5 switch core needs a IFH (Internal Frame Header) to pass
information from the port to the switch core, and this header is added
before injection and stripped after extraction.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
This adds the interrupt for the Sparx5 Frame DMA.
If this configuration is present the Sparx5 SwitchDev driver will use the
Frame DMA feature, and if not it will use register based injection and
extraction for sending and receiving frames to the CPU.
Signed-off-by: Steen Hegelund <steen.hegelund@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Tuo Li