David Ahern [Wed, 24 Apr 2019 01:06:30 +0000 (18:06 -0700)]
ipv6: fib6_rule_action_alt needs to return -EAGAIN
fib rule actions should return -EAGAIN for the rules to continue to the
next one. A recent change overwrote err with the lookup always returning
0 (future change will make it more like IPv4) which means the rules
stopped at the first (e.g., local table lookup only). Catch and reset err
to -EAGAIN.
Fixes: effda4dd97e87 ("ipv6: Pass fib6_result to fib lookups") Signed-off-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Tao Ren [Wed, 24 Apr 2019 01:43:32 +0000 (01:43 +0000)]
net/ncsi: handle overflow when incrementing mac address
Previously BMC's MAC address is calculated by simply adding 1 to the
last byte of network controller's MAC address, and it produces incorrect
result when network controller's MAC address ends with 0xFF.
The problem can be fixed by calling eth_addr_inc() function to increment
MAC address; besides, the MAC address is also validated before assigning
to BMC.
Fixes: cb10c7c0dfd9 ("net/ncsi: Add NCSI Broadcom OEM command") Signed-off-by: Tao Ren <taoren@fb.com> Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Samuel Mendoza-Jonas <sam@mendozajonas.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Merge tag 'drm-fixes-2019-04-24' of git://anongit.freedesktop.org/drm/drm
Pull drm regression fixes from Dave Airlie:
"We interrupt your regularly scheduled drm fixes for a regression
special.
The first is for a fix in i915 that had unexpected side effects
fallout in the userspace X.org modesetting driver where X would no
longer start. I got tired of the nitpicking and issued a large hammer
on it. The X.org driver is buggy, but blackscreen regressions are
worse.
The second was an oversight that myself and Gerd should have noticed
better, Gerd is trying to fix this properly, but the regression is too
large to leave, even if the original behaviour is bad in some cases,
it's clearly bad to break a bunch of working use cases.
I'll likely have a regular fixes pull later, but I really wanted to
highlight these"
* tag 'drm-fixes-2019-04-24' of git://anongit.freedesktop.org/drm/drm:
Revert "drm/virtio: drop prime import/export callbacks"
Revert "drm/i915/fbdev: Actually configure untiled displays"
David Ahern [Tue, 23 Apr 2019 23:03:29 +0000 (16:03 -0700)]
mlxsw: spectrum_router: Prevent ipv6 gateway with v4 route via replace and append
mlxsw currently does not support v6 gateways with v4 routes. Commit 19a9d136f198 ("ipv4: Flag fib_info with a fib_nh using IPv6 gateway")
prevents a route from being added, but nothing stops the replace or
append. Add a catch for them too.
$ ip ro add 172.16.2.0/24 via 10.99.1.2
$ ip ro replace 172.16.2.0/24 via inet6 fe80::202:ff:fe00:b dev swp1s0
Error: mlxsw_spectrum: IPv6 gateway with IPv4 route is not supported.
$ ip ro append 172.16.2.0/24 via inet6 fe80::202:ff:fe00:b dev swp1s0
Error: mlxsw_spectrum: IPv6 gateway with IPv4 route is not supported.
Signed-off-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 24 Apr 2019 02:52:33 +0000 (19:52 -0700)]
Merge branch 'Taprio-qdisc-fixes'
Andre Guedes says:
====================
Taprio qdisc fixes
I'm re-sending this series, now with the "net-next" prefix in the subject.
The only change from the previous version is in patch 3. As suggested by Cong
Wang, it removes the !entry check within should_restart_cycle() since it is
already checked by the caller. As a side effect, that function becomes a dummy
wrapper on list_is_last() so we simply remove it and call list_is_last()
instead.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Andre Guedes [Tue, 23 Apr 2019 19:44:24 +0000 (12:44 -0700)]
net: sched: taprio: Fix taprio_dequeue()
In case we don't have 'guard' or 'budget' to transmit the skb, we should
continue traversing the qdisc list since the remaining guard/budget
might be enough to transmit a skb from other children qdiscs.
Fixes: 5a781ccbd19e (“tc: Add support for configuring the taprio scheduler”) Signed-off-by: Andre Guedes <andre.guedes@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Andre Guedes [Tue, 23 Apr 2019 19:44:23 +0000 (12:44 -0700)]
net: sched: taprio: Fix taprio_peek()
While traversing taprio's children qdisc list, if the gate is closed for
a given traffic class, we should continue traversing the list since the
remaining qdiscs may have skb ready for transmission.
This patch also takes this opportunity and changes the function to use
the TAPRIO_ALL_GATES_OPEN macro instead of the magic number '-1'.
Fixes: 5a781ccbd19e (“tc: Add support for configuring the taprio scheduler”) Signed-off-by: Andre Guedes <andre.guedes@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Andre Guedes [Tue, 23 Apr 2019 19:44:22 +0000 (12:44 -0700)]
net: sched: taprio: Remove should_restart_cycle()
The 'entry' argument from should_restart_cycle() cannot be NULL since it
is already checked by the caller so the WARN_ON() within should_
restart_cycle() could be removed. By doing that, that function becomes
a dummy wrapper on list_is_last() so this patch simply gets rid of it
and call list_is_last() within advance_sched() instead.
Signed-off-by: Andre Guedes <andre.guedes@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
This patch does a code refactoring to taprio_get_start_time() function
to improve readability and report error properly.
If 'base' time is later than 'now', the start time is equal to 'base'
and taprio_get_start_time() is done. That's the natural case so we move
that code to the beginning of the function. Also, if 'cycle' calculation
is zero, something went really wrong with taprio and we should log that
internal error properly.
Signed-off-by: Andre Guedes <andre.guedes@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
This patch removes a pointless variable assigment in taprio_change().
The 'err' variable is not used from this assignment to the next one so
this patch removes it.
Signed-off-by: Andre Guedes <andre.guedes@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David Ahern [Tue, 23 Apr 2019 15:48:09 +0000 (08:48 -0700)]
net: Change nhc_flags to unsigned char
nhc_flags holds the RTNH_F flags for a given nexthop (fib{6}_nh).
All of the RTNH_F_ flags fit in an unsigned char, and since the API to
userspace (rtnh_flags and lower byte of rtm_flags) is 1 byte it can not
grow. Make nhc_flags in fib_nh_common an unsigned char and shrink the
size of the struct by 8, from 56 to 48 bytes.
Update the flags arguments for up netdevice events and fib_nexthop_info
which determines the RTNH_F flags to return on a dump/event. The RTNH_F
flags are passed in the lower byte of rtm_flags which is an unsigned int
so use a temp variable for the flags to fib_nexthop_info and combine
with rtm_flags in the caller.
Signed-off-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David Ahern [Tue, 23 Apr 2019 15:23:41 +0000 (08:23 -0700)]
lwtunnel: Pass encap and encap type attributes to lwtunnel_fill_encap
Currently, lwtunnel_fill_encap hardcodes the encap and encap type
attributes as RTA_ENCAP and RTA_ENCAP_TYPE, respectively. The nexthop
objects want to re-use this code but the encap attributes passed to
userspace as NHA_ENCAP and NHA_ENCAP_TYPE. Since that is the only
difference, change lwtunnel_fill_encap to take the attribute type as
an input.
Signed-off-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
net: socionext: replace napi_alloc_frag with the netdev variant on init
The netdev variant is usable on any context since it disables interrupts.
The napi variant of the call should only be used within softirq context.
Replace napi_alloc_frag on driver init with the correct netdev_alloc_frag
call
Changes since v1:
- Adjusted commit message
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Jassi Brar <jaswinder.singh@linaro.org> Fixes: 4acb20b46214 ("net: socionext: different approach on DMA") Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Simon Horman [Tue, 23 Apr 2019 13:01:53 +0000 (15:01 +0200)]
ravb: Avoid unsupported internal delay mode for R-Car E3/D3
According to the R-Car Gen3 Hardware Manual Rev 1.50 of Nov 30, 2018, the
TX clock internal delay mode isn't supported on R-Car E3 (r8a77990) or D3
(r8a77995). And by extension it is also not supported by RZ/G2E (r9a774c0).
This matches all ES versions of the affected SoCs as it is
not clear if this problem will be resolved in newer chips.
This can be revisited, as necessary.
This patch does not error-out if PHY_INTERFACE_MODE_RGMII_ID or
PHY_INTERFACE_MODE_RGMII_TXID are used on SoCs where TX clock delay
mode is not supported as there is a risk of introducing a regression
when used in conjunction with older DT blobs present in the field.
Rather, a warning is logged in such cases.
Based on work by Kazuya Mizuguchi.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Stephen Rothwell [Tue, 23 Apr 2019 07:25:24 +0000 (17:25 +1000)]
net: fix sparc64 compilation of sock_gettstamp
net/core/sock.c: In function 'sock_gettstamp':
net/core/sock.c:3007:23: error: expected '}' before ';' token
.tv_sec = ts.tv_sec;
^
net/core/sock.c:3011:4: error: expected ')' before 'return'
return -EFAULT;
^~~~~~
net/core/sock.c:3013:2: error: expected expression before '}' token
}
^
Fixes: c7cbdbf29f48 ("net: rework SIOCGSTAMP ioctl handling") Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
Pointers should be printed with %p or %px rather than
cast to (u_long) and printed with %lx.
Change %lx to %p to print the pointer.
Change %lx to %pad to print the dma_addr_t.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Pointers should be printed with %p or %px rather than
cast to (u_long) type and printed with %lX.
As the function seems to be for debug purpose.
Change %lX to %px to print the pointer value.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Dave Airlie [Wed, 24 Apr 2019 00:52:20 +0000 (10:52 +1000)]
Revert "drm/virtio: drop prime import/export callbacks"
This patch does more harm than good, as it breaks both Xwayland and
gnome-shell with X11.
Xwayland requires DRI3 & DRI3 requires PRIME.
X11 crash for obscure double-free reason which are hard to debug
(starting X11 by hand doesn't trigger the crash).
I don't see an apparent problem implementing those stub prime
functions, they may return an error at run-time, and it seems to be
handled fine by GNOME at least.
This brings back the original problem, but it's better than regressions.]
Fixes: b318e3ff7ca065d6b107e424c85a63d7a6798a ("drm/virtio: drop prime import/export callbacks") Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
This commit is documented to break userspace X.org modesetting driver in certain configurations.
The X.org modesetting userspace driver is broken. No fixes are available yet. In order for this patch to be applied it either needs a config option or a workaround developed.
This has been reported a few times, saying it's a userspace problem is clearly against the regression rules.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109806 Signed-off-by: Dave Airlie <airlied@redhat.com> Cc: <stable@vger.kernel.org> # v3.19+
Eric Dumazet [Tue, 23 Apr 2019 01:35:03 +0000 (18:35 -0700)]
ipv6: convert fib6_ref to refcount_t
We suspect some issues involving fib6_ref 0 -> 1 transitions might
cause strange syzbot reports.
Lets convert fib6_ref to refcount_t to catch them earlier.
Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Wei Wang <weiwan@google.com> Acked-by: Wei Wang <weiwan@google.com> Reviewed-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Tue, 23 Apr 2019 01:35:02 +0000 (18:35 -0700)]
ipv6: broadly use fib6_info_hold() helper
Instead of using atomic_inc(), prefer fib6_info_hold()
so that upcoming refcount_t conversion is simpler.
Only fib6_info_alloc() is using atomic_set() since we
just allocated a new object.
Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Wei Wang <weiwan@google.com> Acked-by: Wei Wang <weiwan@google.com> Reviewed-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Tue, 23 Apr 2019 01:35:01 +0000 (18:35 -0700)]
ipv6: fib6_info_destroy_rcu() cleanup
We do not need to clear f6i->rt6i_exception_bucket right before
freeing f6i.
Note that f6i->rt6i_exception_bucket is properly protected by
f6i->exception_bucket_flushed being set to one in rt6_flush_exceptions()
under the protection of rt6_exception_lock.
Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Wei Wang <weiwan@google.com> Acked-by: Wei Wang <weiwan@google.com> Reviewed-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 24 Apr 2019 00:03:40 +0000 (17:03 -0700)]
Merge tag 'mlx5-updates-2019-04-22' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux
Saeed Mahameed says:
====================
mlx5-updates-2019-04-22
This series includes updates to mlx5e driver RX data path and some
significant XDP RX/TX improvements to overcome/mitigate HW and PCIE
bottlenecks.
From Tariq:
1) Some Enhancements in rq->flags
2) Stabilize RX packet rate (on Striding RQ) with
multiple outstanding UMR posts
In this patch, we add support for multiple outstanding UMR posts,
to allow faster gap closure between consuming MPWQEs and reposting
them back into the WQ.
Performance test:
As expected, huge improvement in large-scale (48 cores).
xdp_redirect_map, 64B UDP multi-stream.
Redirect from ConnectX-5 100Gbps to ConnectX-6 100Gbps.
CPU: Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz.
Before: Unstable, 7 to 30 Mpps
After: Stable, at 70.5 Mpps
From Shay:
3) XDP, Inline small packets into the TX MPWQE in XDP xmit flow
Upon high packet rate with multiple CPUs TX workloads, much of the HCA's
resources are spent on prefetching TX descriptors, thus affecting
transmission rates.
This patch comes to mitigate this problem by moving some workload to the
CPU and reducing the HW data prefetch overhead for small packets (<= 256B).
When forwarding packets with XDP, a packet that is smaller
than a certain size (set to ~256 bytes) would be sent inline within
its WQE TX descrptor (mem-copied), when the hardware tx queue is congested
beyond a pre-defined water-mark.
Performance:
Tested packet rate for UDP 64Byte multi-stream
over two dual port ConnectX-5 100Gbps NICs.
CPU: Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz
* Tested with hyper-threading disabled
XDP_TX:
| | before | after | |
| 24 rings | 51Mpps | 116Mpps | +126% |
| 1 ring | 12Mpps | 12Mpps | same |
XDP_REDIRECT:
** Below is the transmit rate, not the redirection rate
which might be larger, and is not affected by this patch.
| | before | after | |
| 32 rings | 64Mpps | 92Mpps | +43% |
| 1 ring | 6.4Mpps | 6.4Mpps | same |
As we can see, feature significantly improves scaling, without
hurting single ring performance.
From Maxim:
4) Some trivial refactoring and code improvements prior to a larger series
to support AF_XDP.
====================
Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Merge tag 'nfsd-5.1-1' of git://linux-nfs.org/~bfields/linux
Pull nfsd bugfixes from Bruce Fields:
"Fix miscellaneous nfsd bugs, in NFSv4.1 callbacks, NFSv4.1
lock-notification callbacks, NFSv3 readdir encoding, and the
cache/upcall code"
* tag 'nfsd-5.1-1' of git://linux-nfs.org/~bfields/linux:
nfsd: wake blocked file lock waiters before sending callback
nfsd: wake waiters blocked on file_lock before deleting it
nfsd: Don't release the callback slot unless it was actually held
nfsd/nfsd3_proc_readdir: fix buffer count and page pointers
sunrpc: don't mark uninitialised items as VALID.
Merge tag 'syscalls-5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic
Pull syscall numbering updates from Arnd Bergmann:
"arch: add pidfd and io_uring syscalls everywhere
This comes a bit late, but should be in 5.1 anyway: we want the newly
added system calls to be synchronized across all architectures in the
release.
I hope that in the future, any newly added system calls can be added
to all architectures at the same time, and tested there while they are
in linux-next, avoiding dependencies between the architecture
maintainer trees and the tree that contains the new system call"
* tag 'syscalls-5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic:
arch: add pidfd and io_uring syscalls everywhere
Bluetooth: hci_qca: Fix crash with non-serdev devices
qca_set_baudrate() calls serdev_device_wait_until_sent() assuming that
the HCI is always associated with a serdev device. This isn't true for
ROME controllers instantiated through ldisc, where the call causes a
crash due to a NULL pointer dereferentiation. Only call the function
when we have a serdev device. The timeout for ROME devices at the end
of qca_set_baudrate() is long enough to be reasonably sure that the
command was sent.
net/mlx5e: Take HW interrupt trigger into a function
mlx5e_trigger_irq posts a NOP to the ICO SQ just to trigger an IRQ and
enter the NAPI poll on the right CPU according to the affinity. Use it
in mlx5e_activate_rq.
mlx5e_mpwqe_get_log_rq_size calculates the number of WQEs (N) based on
the requested number of frames in the RQ (F) and the number of packets
per WQE (P). It ensures that N is not less than the minimum number of
WQEs in an RQ (N_min). Arithmetically, it means that F / P >= N_min
should be true. This function deals with logarithms, so it should check
that log(F) - log(P) >= log(N_min). However, if F < P, this expression
will cause an unsigned underflow. Check log(F) >= log(P) + log(N_min)
instead.
If the channels fail to reopen after setting an XDP program, return the
error code instead of 0. A proper fix is still needed, as now any error
while reopening the channels brings the interface down. This patch only
adds error reporting.
Shay Agroskin [Thu, 14 Mar 2019 12:54:07 +0000 (14:54 +0200)]
net/mlx5e: XDP, Inline small packets into the TX MPWQE in XDP xmit flow
Upon high packet rate with multiple CPUs TX workloads, much of the HCA's
resources are spent on prefetching TX descriptors, thus affecting
transmission rates.
This patch comes to mitigate this problem by moving some workload to the
CPU and reducing the HW data prefetch overhead for small packets (<= 256B).
When forwarding packets with XDP, a packet that is smaller
than a certain size (set to ~256 bytes) would be sent inline within
its WQE TX descrptor (mem-copied), when the hardware tx queue is congested
beyond a pre-defined water-mark.
This is added to better utilize the HW resources (which now makes
one less packet data prefetch) and allow better scalability, on the
account of CPU usage (which now 'memcpy's the packet into the WQE).
To load balance between HW and CPU and get max packet rate, we use
watermarks to detect how much the HW is congested and move the work
loads back and forth between HW and CPU.
Performance:
Tested packet rate for UDP 64Byte multi-stream
over two dual port ConnectX-5 100Gbps NICs.
CPU: Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz
* Tested with hyper-threading disabled
XDP_TX:
| | before | after | |
| 24 rings | 51Mpps | 116Mpps | +126% |
| 1 ring | 12Mpps | 12Mpps | same |
XDP_REDIRECT:
** Below is the transmit rate, not the redirection rate
which might be larger, and is not affected by this patch.
| | before | after | |
| 32 rings | 64Mpps | 92Mpps | +43% |
| 1 ring | 6.4Mpps | 6.4Mpps | same |
As we can see, feature significantly improves scaling, without
hurting single ring performance.
Tariq Toukan [Wed, 27 Feb 2019 10:06:08 +0000 (12:06 +0200)]
net/mlx5e: RX, Support multiple outstanding UMR posts
The buffers mapping of the Multi-Packet WQEs (of Striding RQ)
is done via UMR posts, one UMR WQE per an RX MPWQE.
A single MPWQE is capable of serving many incoming packets,
usually larger than the budget of a single napi cycle.
Hence, posting a single UMR WQE per napi cycle (and handling its
completion in the next cycle) works fine in many common cases,
but not always.
When an XDP program is loaded, every MPWQE is capable of serving less
packets, to satisfy the packet-per-page requirement.
Thus, for the same number of packets more MPWQEs (and UMR posts)
are needed (twice as much for the default MTU), giving less latency
room for the UMR completions.
In this patch, we add support for multiple outstanding UMR posts,
to allow faster gap closure between consuming MPWQEs and reposting
them back into the WQ.
For better SW and HW locality, we combine the UMR posts in bulks of
(at least) two.
This is expected to improve packet rate in high CPU scale.
Performance test:
As expected, huge improvement in large-scale (48 cores).
xdp_redirect_map, 64B UDP multi-stream.
Redirect from ConnectX-5 100Gbps to ConnectX-6 100Gbps.
CPU: Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz.
Before: Unstable, 7 to 30 Mpps
After: Stable, at 70.5 Mpps
====================
net: phy: mscc: Improvements to VSC8514 PHY driver.
The VSC8514 PHY is a 4-ports PHY that is 10/100/1000BASE-T, 100BASE-FX,
1000BASE-X, can communicate with the MAC via QSGMII.
The MAC interface protocol for each port within QSGMII can
be either 1000BASE-X or SGMII, if the QSGMII MAC that the VSC8514 is
connecting to supports this functionality.
VSC8514 also supports SGMII MAC-side autonegotiation on each individual
port, downshifting, can set the blinking pattern of each of its 4 LEDs,
SyncE, 1000BASE-T Ring Resiliency as well as HP Auto-MDIX detection.
This patch series adds support for 10BASE-T, 100BASE-TX, and
1000BASE-T, QSGMII link with the MAC, downshifting, HP Auto-MDIX
detection and blinking pattern for its 4 LEDs.
The GPIO register bank is a set of registers that are common to all
PHYs in the package. So any modification in any register of this bank
affects all PHYs of the package.
If the PHYs haven't been reset before booting the Linux kernel and were
configured to use interrupts for e.g. link status updates, it is
required to clear the interrupts mask register of all PHYs before being
able to use interrupts with any PHY. The first PHY of the package that
will be init will take care of clearing all PHYs interrupts mask
registers. Thus, we need to keep track of the init sequence in the
package, if it's already been done or if it's to be done.
Most of the init sequence of a PHY of the package is common to all PHYs
in the package, thus we use the SMI broadcast feature which enables us
to propagate a write in one register of one PHY to all PHYs in the same
package.
This patch series adds support for VSC8514 in Microsemi driver(mscc.c)
and removes support from Vitesse driver(vitesse.c).
v8
- mscc: Added appropriate code using phy_modify() in vsc8514_config_init().
v7
- mscc: Handled return values in vsc8514_config_init().
v6
- mscc: Added proper return value in vsc85xx_csr_ctrl_phy_read().
- mscc: Replaced __mdiobus_write and__mdiobus_read with __phy_write and __phy_read resp.
- mscc: Replaced register addresses in 8514_config_init() with proper constants.
v5
- mscc: Added return error statements for few function calls.
- mscc: Added comments in vsc85xx_csr_ctrl_phy_read() and vsc85xx_csr_ctrl_phy_write()
v4
- mscc: Removed features settings
- mscc: Removed aneg_done settings.
v3
- mscc: Used BIT(x) for PHY_MCB_S6G_WRITE and PHY_MCB_S6G_READ
instead of hex.
- mscc: Replaced magic numbers with proper constants.
- mscc: Handled delays and timeouts at appropriate points.
- mscc: Added comments/explanation where requested.
v2
- mscc: Sorted variable declarations in reverse christmas tree order.
v1
- Added 0/2 file.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The VSC8514 PHY is a 4-ports PHY that is 10/100/1000BASE-T, 100BASE-FX,
1000BASE-X, can communicate with the MAC via QSGMII.
The MAC interface protocol for each port within QSGMII can
be either 1000BASE-X or SGMII, if the QSGMII MAC that the VSC8514 is
connecting to supports this functionality.
VSC8514 also supports SGMII MAC-side autonegotiation on each individual
port, downshifting, can set the blinking pattern of each of its 4 LEDs,
SyncE, 1000BASE-T Ring Resiliency as well as HP Auto-MDIX detection.
This adds support for 10BASE-T, 100BASE-TX, and 1000BASE-T,
QSGMII link with the MAC, downshifting, HP Auto-MDIX detection
and blinking pattern for its 4 LEDs.
The GPIO register bank is a set of registers that are common to all PHYs
in the package. So any modification in any register of this bank affects
all PHYs of the package.
If the PHYs haven't been reset before booting the Linux kernel and were
configured to use interrupts for e.g. link status updates, it is
required to clear the interrupts mask register of all PHYs before being
able to use interrupts with any PHY. The first PHY of the package that
will be init will take care of clearing all PHYs interrupts mask
registers. Thus, we need to keep track of the init sequence in the
package, if it's already been done or if it's to be done.
Most of the init sequence of a PHY of the package is common to all PHYs
in the package, thus we use the SMI broadcast feature which enables us
to propagate a write in one register of one PHY to all PHYs in the same
package.
Signed-off-by: Kavya Sree Kotagiri <kavyasree.kotagiri@microchip.com> Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com> Co-developed-by: Quentin Schulz <quentin.schulz@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Daniel Gomez [Mon, 22 Apr 2019 19:08:04 +0000 (21:08 +0200)]
spi: ST ST95HF NFC: declare missing of table
Add missing <of_device_id> table for SPI driver relying on SPI
device match since compatible is in a DT binding or in a DTS.
Before this patch:
modinfo drivers/nfc/st95hf/st95hf.ko | grep alias
alias: spi:st95hf
After this patch:
modinfo drivers/nfc/st95hf/st95hf.ko | grep alias
alias: spi:st95hf
alias: of:N*T*Cst,st95hfC*
alias: of:N*T*Cst,st95hf
Reported-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Daniel Gomez <dagmcr@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Daniel Gomez [Mon, 22 Apr 2019 19:08:03 +0000 (21:08 +0200)]
spi: Micrel eth switch: declare missing of table
Add missing <of_device_id> table for SPI driver relying on SPI
device match since compatible is in a DT binding or in a DTS.
Before this patch:
modinfo drivers/net/phy/spi_ks8995.ko | grep alias
alias: spi:ksz8795
alias: spi:ksz8864
alias: spi:ks8995
After this patch:
modinfo drivers/net/phy/spi_ks8995.ko | grep alias
alias: spi:ksz8795
alias: spi:ksz8864
alias: spi:ks8995
alias: of:N*T*Cmicrel,ksz8795C*
alias: of:N*T*Cmicrel,ksz8795
alias: of:N*T*Cmicrel,ksz8864C*
alias: of:N*T*Cmicrel,ksz8864
alias: of:N*T*Cmicrel,ks8995C*
alias: of:N*T*Cmicrel,ks8995
Reported-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Daniel Gomez <dagmcr@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
net: phy: marvell: add new default led configure for m88e151x
The default m88e151x LED configuration is 0x1177, used LED[0]
for 1000M link, LED[1] for 100M link, and LED[2] for active.
But for some boards, which use LED[0] for link, and LED[1] for
active, prefer to be 0x1040. To be compatible with this case,
this patch defines a new dev_flag, and set it before connect
phy in HNS3 driver. When phy initializing, using the new
LED configuration if this dev_flag is set.
Signed-off-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
Bluetooth: hci_bcm: Fix empty regulator supplies for Intel Macs
The code path for Macs goes through bcm_apple_get_resources(), which
skips over the code that sets up the regulator supplies. As a result,
the call to regulator_bulk_enable() / regulator_bulk_disable() results
in a NULL pointer dereference.
This was reported on the kernel.org Bugzilla, bug 202963.
Unbreak Broadcom Bluetooth support on Intel Macs by checking if the
supplies were set up before enabling or disabling them.
The same does not need to be done for the clocks, as the common clock
framework API checks for NULL pointers.
Fixes: 75d11676dccb ("Bluetooth: hci_bcm: Add support for regulator supplies") Cc: <stable@vger.kernel.org> # 5.0.x Signed-off-by: Chen-Yu Tsai <wens@csie.org> Tested-by: Imre Kaloz <kaloz@openwrt.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Fix incorrect pointer arithmatic in ext_adv_report_evt
In ext_adv_report_event rssi comes before data (not after data as
in legacy adv_report_evt) so "+ 1" is not required in the ptr arithmatic
to point to next report.
Dan Carpenter [Wed, 3 Apr 2019 05:34:16 +0000 (08:34 +0300)]
6lowpan: Off by one handling ->nexthdr
NEXTHDR_MAX is 255. What happens here is that we take a u8 value
"hdr->nexthdr" from the network and then look it up in
lowpan_nexthdr_nhcs[]. The problem is that if hdr->nexthdr is 0xff then
we read one element beyond the end of the array so the array needs to
be one element larger.
Fixes: 92aa7c65d295 ("6lowpan: add generic nhc layer interface") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com> Acked-by: Alexander Aring <aring@mojatatu.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: btbcm: Add default address for BCM43341B
The BCM43341B has the default MAC address 43:34:1B:00:1F:AC if none
is given. This address was found when enabling Bluetooth on multiple
Intel Edison modules. It also contains the sequence 43341B, the name
the chip identifies itself as. Using the same BD_ADDR is problematic
when having multiple Intel Edison modules in each others range.
The default address also has the LAA (locally administered address)
bit set which prevents a BNEP device from being created, needed for
BT tethering.
Add this to the list of black listed default MAC addresses and let
the user configure a valid one using f.i.
`btmgmt -i hci0 public-addr xx:xx:xx:xx:xx:xx`
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Ferry Toth <ftoth@exalondelft.nl> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Young Xiao [Fri, 12 Apr 2019 07:24:30 +0000 (15:24 +0800)]
Bluetooth: hidp: fix buffer overflow
Struct ca is copied from userspace. It is not checked whether the "name"
field is NULL terminated, which allows local users to obtain potentially
sensitive information from kernel stack memory, via a HIDPCONNADD command.
This vulnerability is similar to CVE-2011-1079.
Signed-off-by: Young Xiao <YangX92@hotmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org
Tamás Szűcs [Sun, 14 Apr 2019 18:38:14 +0000 (20:38 +0200)]
Bluetooth: btmrvl: add support for SD8987 chipset
This patch adds support for Marvell 88W8987 chipset with SDIO interface.
Register offsets and supported feature flags are updated. The corresponding
firmware image file shall be "mrvl/sd8987_uapsta.bin".
Signed-off-by: Tamás Szűcs <tszucs@protonmail.ch> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Sean Wang [Thu, 18 Apr 2019 09:08:02 +0000 (17:08 +0800)]
Bluetooth: btmtksdio: Add runtime PM support to SDIO based Bluetooth
Add runtime PM support to btmtksdio. With this way, there will be the
benefit of the device entering the more power saving state once it is
been a while data traffic is idle.
Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Sean Wang [Tue, 5 Mar 2019 00:14:25 +0000 (08:14 +0800)]
Bluetooth: mediatek: Fixed incorrect type in assignment
Fixed warning: incorrect type in assignment reported by kbuild test robot.
The detailed warning is shown as below.
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
All warnings (new ones prefixed by >>):
btmtkuart.c:671:18: sparse: warning: incorrect type in assignment
(different base types)
btmtkuart.c:671:18: sparse: expected unsigned int [usertype] baudrate
btmtkuart.c:671:18: sparse: got restricted __le32 [usertype]
sparse warnings: (new ones prefixed by >>)
btmtkuart.c:671:18: sparse: warning: incorrect type in assignment
(different base types)
btmtkuart.c:671:18: sparse: expected unsigned int [usertype] baudrate
btmtkuart.c:671:18: sparse: got restricted __le32 [usertype]
vim +671 drivers/bluetooth/btmtkuart.c
659
660 static int btmtkuart_change_baudrate(struct hci_dev *hdev)
661 {
662 struct btmtkuart_dev *bdev = hci_get_drvdata(hdev);
663 struct btmtk_hci_wmt_params wmt_params;
664 u32 baudrate;
665 u8 param;
666 int err;
667
668 /* Indicate the device to enter the probe state the host is
669 * ready to change a new baudrate.
670 */
> 671 baudrate = cpu_to_le32(bdev->desired_speed);
672 wmt_params.op = MTK_WMT_HIF;
Fixes: 22eaf6c9946a ("Bluetooth: mediatek: add support for MediaTek MT7663U and MT7668U UART devices") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Sean Wang [Mon, 18 Mar 2019 20:58:33 +0000 (04:58 +0800)]
Bluetooth: btmtksdio: fix uninitialized symbol errors in btmtksdio_rx_packet
Fixed all the below warnings. They would probably cause the following
error handling path would use the uninitialized value and then produce
unexpected behavior.
drivers/bluetooth/btmtksdio.c:470:2: warning: ‘old_len’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
print_hex_dump(KERN_ERR, "err sdio rx: ", DUMP_PREFIX_NONE, 4, 1,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
old_data, old_len, true);
~~~~~~~~~~~~~~~~~~~~~~~~
drivers/bluetooth/btmtksdio.c:376:15: note: ‘old_len’ was declared here
unsigned int old_len;
^~~~~~~
drivers/bluetooth/btmtksdio.c:470:2: warning: ‘old_data’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
print_hex_dump(KERN_ERR, "err sdio rx: ", DUMP_PREFIX_NONE, 4, 1,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
old_data, old_len, true);
~~~~~~~~~~~~~~~~~~~~~~~~
drivers/bluetooth/btmtksdio.c:375:17: note: ‘old_data’ was declared here
unsigned char *old_data;
^~~~~~~~
v2: Remove old_len and old_data because the error path for sdio_readsb also
seems wrong. And change the prefix from "mediatek" to "btmtksdio".
Fixes: d74eef2834b5 ("Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devices") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Reported-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Sean Wang [Wed, 13 Mar 2019 21:02:00 +0000 (05:02 +0800)]
Bluetooth: btsdio: Use module_sdio_driver helper
Macro module_sdio_driver is used for drivers whose init and exit paths
only register and unregister to SDIO API. So remove boilerplate code to
make code simpler by using module_sdio_driver.
Signed-off-by: Sean Wang <sean.wang@mediatek.com> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Sean Wang [Wed, 13 Mar 2019 21:01:59 +0000 (05:01 +0800)]
Bluetooth: mediatek: Use module_sdio_driver helper
Macro module_sdio_driver is used for drivers whose init and exit paths
only register and unregister to SDIO API. So remove boilerplate code to
make code simpler by using module_sdio_driver.
Suggested-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Sean Wang [Wed, 13 Mar 2019 21:01:58 +0000 (05:01 +0800)]
mmc: sdio: Add helper macro for sdio_driver boilerplate
This patch introduces the module_sdio_driver macro which is a convenience
macro for SDIO driver modules similar to module_usb_driver. It is intended
to be used by drivers which init/exit section does nothing but register/
unregister the SDIO driver. By using this macro it is possible to eliminate
a few lines of boilerplate code per SDIO driver.
Suggested-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
l2cap_le_flowctl_init was reseting the tx_credits which works only for
outgoing connection since that set the tx_credits on the response, for
incoming connections that was not the case which leaves the channel
without any credits causing it to be suspended.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org # 4.20+
Bluetooth: hci_qca: Add helper function to get the chip family
Many functions obtain a 'struct qca_serdev' only to read the btsoc_type
field. Add a helper function that encapsulates this.
This also fixes crashes observed on platforms with ROME controllers
that are instantiated through ldisc and not as serdev clients. The
crashes are caused by NULL pointer dereferentiations, which stem from
the driver's assumption that a QCA HCI device is always associated with
a serdev device.
Fixes: fa9ad876b8e0 ("Bluetooth: hci_qca: Add support for Qualcomm Bluetooth chip wcn3990") Reported-by: Balakrishna Godavarthi <bgodavar@codeaurora.org> Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Sean Wang [Fri, 8 Mar 2019 01:15:44 +0000 (09:15 +0800)]
Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devices
This adds the support of enabling MT7663S and MT7668S SDIO-based
Bluetooth function.
There are quite many differences between MT766[3,8]S and standard
Bluetooth SDIO devices such as Type-A and Type-B devices. For example,
MT766[3,8]S have its own SDIO registers layout, definition, SDIO packet
format, and the specific flow should be programmed on them to complete
the device initialization and low power control and so on.
Currently, there are many independent programming sequences from the
transport which are exactly the same as the ones in btusb.c about MediaTek
support [1] and btmtkuart.c. We can try to split the transport independent
Bluetooth setups on the advance, place them into the common files and allow
varous transport drivers to reuse them in the future.
Sean Wang [Fri, 8 Mar 2019 01:15:43 +0000 (09:15 +0800)]
mmc: add SDIO identifiers for MediaTek Bluetooth devices
The SDIO identifier for MediaTek Bluetooth devices were defined in the
MediaTek Bluetooth driver. Moving the definitions in MMC header file
seems common sense.
Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
All we do is write the length/status and address bits to a DMA
descriptor only to write its contents into on-chip registers right
after, eliminate this unnecessary step.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
bridge: Fix possible use-after-free when deleting bridge port
When a bridge port is being deleted, do not dereference it later in
br_vlan_port_event() as it can result in a use-after-free [1] if the RCU
callback was executed before invoking the function.
[ 130.146195] Freed by task 0:
[ 130.149421] __kasan_slab_free+0x125/0x170
[ 130.154016] kfree+0xf3/0x310
[ 130.157349] kobject_put+0x1a8/0x4c0
[ 130.161363] rcu_core+0x859/0x19b0
[ 130.165175] __do_softirq+0x250/0xa26
[ 130.170956] The buggy address belongs to the object at ffff8881e4aa1ae8
which belongs to the cache kmalloc-1k of size 1024
[ 130.184972] The buggy address is located 0 bytes inside of
1024-byte region [ffff8881e4aa1ae8, ffff8881e4aa1ee8)
Fixes: 9c0ec2e7182a ("bridge: support binding vlan dev link state to vlan member bridge ports") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Cc: Mike Manning <mmanning@vyatta.att-mail.com> Acked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Acked-by: Mike Manning <mmanning@vyatta.att-mail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
r8152: sync sa_family with the media type of network device
Without this patch the socket address family sporadically gets wrong
value ends up the dev_set_mac_address() fails to set the desired MAC
address.
Fixes: 25766271e42f ("r8152: Refresh MAC address during USBDEVFS_RESET") Signed-off-by: Crag.Wang <crag.wang@dell.com> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-By: Mario Limonciello <mario.limonciello@dell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
This patchset includes two improvements with regards to shared buffer
configuration in mlxsw.
The first part of this patchset forbids the user from performing illegal
shared buffer configuration that can result in unnecessary packet loss.
In order to better communicate these configuration failures to the user,
extack is propagated from devlink towards drivers. This is done in
patches #1-#8.
The second part of the patchset deals with the shared buffer
configuration of the CPU port. When a packet is trapped by the device,
it is sent across the PCI bus to the attached host CPU. From the
device's perspective, it is as if the packet is transmitted through the
CPU port.
While testing traffic directed at the CPU it became apparent that for
certain packet sizes and certain burst sizes, the current shared buffer
configuration of the CPU port is inadequate and results in packet drops.
The configuration is adjusted by patches #9-#14 that create two new pools
- ingress & egress - which are dedicated for CPU traffic.
====================
Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
mlxsw: spectrum_buffers: Adjust CPU port shared buffer egress quotas
Switch the CPU port to use the new dedicated egress pool instead the
previously used egress pool which was shared with normal front panel
ports.
Add per-port quotas for the amount of traffic that can be buffered for
the CPU port and also adjust the per-{port, TC} quotas.
Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
mlxsw: spectrum_buffers: Allow skipping ingress port quota configuration
The CPU port is used to transmit traffic that is trapped to the host
CPU. It is therefore irrelevant to define ingress quota for it.
Add a 'skip_ingress' argument to the function tasked with configuring
per-port quotas, so that ingress quotas could be skipped in case the
passed local port is the CPU port.
Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
mlxsw: spectrum_buffers: Split business logic from mlxsw_sp_port_sb_pms_init()
The function is used to set the per-port shared buffer quotas.
Currently, these quotas are only set for front panel ports, but a
subsequent patch will configure these quotas for the CPU port as well.
The configuration required for the CPU port is a bit different than that
of the front panel ports, so split the business logic into a separate
function which will be called with different parameters for the CPU
port.
No functional changes intended.
Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
mlxsw: spectrum_buffers: Use new CPU ingress pool for control packets
Use the new ingress pool that was added in the previous patch for
control packets (e.g., STP, LACP) that are trapped to the CPU.
The previous management pool is no longer necessary and therefore its
size is set to 0.
The maximum quota for traffic towards the CPU is increased to 50% of the
free space in the new ingress pool and therefore the reserved space is
reduced by half, to 10KB - in both the shared and headroom buffer. This
allows for more efficient utilization of the shared buffer as reserved
space cannot be used for other purposes.
Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
mlxsw: spectrum_buffers: Add pools for CPU traffic
Packets that are trapped to the CPU are transmitted through the CPU port
to the attached host. The CPU port is therefore like any other port and
needs to have shared buffer configuration.
The maximum quotas configured for the CPU are provided using dynamic
threshold and cannot be changed by the user. In order to make sure that
these thresholds are always valid, the configuration of the threshold
type of these pools is forbidden.
Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
mlxsw: spectrum_buffers: Remove assumption about pool order
The code currently assumes that ingress pools have lower indices than
egress pools. This makes it impossible to add more ingress pools
without breaking user configuration that relies on a certain pool index
to correspond to an egress pool.
Remove such assumptions from the code, so that more ingress pools could
be added by subsequent patches.
Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Commit e83c045e53d7 ("mlxsw: spectrum_buffers: Configure MC pool")
configured the threshold of the multicast TCs as infinite so that the
admission of multicast packets is only depended on per-switch priority
threshold.
Forbid the user from changing the thresholds of these multicast TCs and
their binding to a different pool.
Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
mlxsw: spectrum_buffers: Forbid changing threshold type of first egress pool
Multicast packets have three egress quotas:
* Per egress port
* Per egress port and traffic class
* Per switch priority
The limits on the switch priority are not exposed to the user and
specified as dynamic threshold on the first egress pool.
Forbid changing the threshold type of the first egress pool so that
these limits are always valid.
Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
mlxsw: spectrum_buffers: Forbid configuration of multicast pool
Commit e83c045e53d7 ("mlxsw: spectrum_buffers: Configure MC pool") added
a dedicated pool for multicast traffic. The pool is visible to the user
so that it would be possible to monitor its occupancy, but its
configuration should be forbidden in order to maintain its intended
operation.
Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
mlxsw: spectrum_buffers: Add ability to veto TC's configuration
Subsequent patches are going to need to veto changes in certain TCs'
binding and threshold configurations.
Add fields to the TC's struct that indicate if the TC can be bound to a
different pool and whether its threshold can change and enforce that.
Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
mlxsw: spectrum_buffers: Add ability to veto pool's configuration
Subsequent patches are going to need to veto changes in certain pools'
size and / or threshold type (mode).
Add two fields to the pool's struct that indicate if either of these
attributes is allowed to change and enforce that.
Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
mlxsw: spectrum_buffers: Use defines for pool indices
The pool indices are currently hard coded throughout the code, which
makes the code hard to follow and extend.
Overcome this by using defines for the pool indices.
Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
mlxsw: spectrum_buffers: Add extack messages for invalid configurations
Add extack messages to better communicate invalid configuration to the
user.
Example:
# devlink sb pool set pci/0000:01:00.0 pool 0 size 104857600 thtype dynamic
Error: mlxsw_spectrum: Exceeded shared buffer size.
devlink answers: Invalid argument
Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
net: devlink: Add extack to shared buffer operations
Add extack to shared buffer set operations, so that meaningful error
messages could be propagated to the user.
Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Cc: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
net: stmmac: move stmmac_check_ether_addr() to driver probe
stmmac_check_ether_addr() checks the MAC address and assigns one in
driver open(). In many cases when we create slave netdevice, the dev
addr is inherited from master but the master dev addr maybe NULL at
that time, so move this call to driver probe so that address is
always valid.
Signed-off-by: Xiaofei Shen <xiaofeis@codeaurora.org> Tested-by: Xiaofei Shen <xiaofeis@codeaurora.org> Signed-off-by: Sneh Shah <snehshah@codeaurora.org> Signed-off-by: Vinod Koul <vkoul@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
====================
clean up needless use of module infrastructure
People can embed modular includes and modular exit functions into code
that never use any of it, and they won't get any errors or warnings.
Using modular infrastructure in non-modules might seem harmless, but some
of the downfalls this leads to are:
(1) it is easy to accidentally write unused module_exit removal code
(2) it can be misleading when reading the source, thinking a driver can
be modular when the Makefile and/or Kconfig prohibit it
(3) an unused include of the module.h header file will in turn
include nearly everything else; adding a lot to CPP overhead.
(4) it gets copied/replicated into other drivers and spreads quickly.
As a data point for #3 above, an empty C file that just includes the
module.h header generates over 750kB of CPP output. Repeating the same
experiment with init.h and the result is less than 12kB; with export.h
it is only about 1/2kB; with both it still is less than 12kB. One driver
in this series gets the module.h ---> init.h+export.h conversion.
Worse, are headers in include/linux that in turn include <linux/module.h>
as they can impact a whole fleet of drivers, or a whole subsystem, so
special care should be used in order to avoid that. Such headers should
only include what they need to be stand-alone; they should not be trying
to anticipate the various header needs of their possible end users.
In this series, four include/linux headers have module.h removed from
them because they don't strictly need it. Then three chunks of net
related code have modular infrastructure that isn't used, removed.
There are no runtime changes, so the biggest risk is a genuine consumer
of module.h content relying on implicitly getting it from one of the
include/linux instances removed here - thus resulting in a build fail.
With that in mind, allmodconfig build testing was done on x86-64, arm64,
x86-32, arm. powerpc, and mips on linux-next (and hence net-next).
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Paul Gortmaker [Sun, 21 Apr 2019 03:29:48 +0000 (23:29 -0400)]
net: strparser: make it explicitly non-modular
The Kconfig currently controlling compilation of this code is:
net/strparser/Kconfig:config STREAM_PARSER
net/strparser/Kconfig: def_bool n
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.
Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit. For
clarity, we change the fcn name mod_init to dev_init at the same time.
We replace module.h with init.h and export.h ; the latter since this
file exports some syms.
Cc: "David S. Miller" <davem@davemloft.net> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Martin KaFai Lau <kafai@fb.com> Cc: Song Liu <songliubraving@fb.com> Cc: Yonghong Song <yhs@fb.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Paul Gortmaker [Sun, 21 Apr 2019 03:29:47 +0000 (23:29 -0400)]
net: bpfilter: dont use module_init in non-modular code
The Kconfig controlling this code is:
bpfilter/Kconfig:menuconfig BPFILTER
bpfilter/Kconfig: bool "BPF based packet filtering framework (BPFILTER)"
Since it isn't a module, we shouldn't use module_init(). Instead we
use device_initcall() - which is exactly what module_init() defaults
to for non-modular code/builds.
We don't remove <linux/module.h> from the includes since this file does
a request_module() and hence is a valid user of that header file, even
though it is not modular itself.
Cc: "David S. Miller" <davem@davemloft.net> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
...meaning that it currently is not being built as a module by anyone,
as module support was discontinued in 2014.
We delete the MODULE_LICENSE tag since all that information is already
contained at the top of the file in the comments.
We don't delete module.h from the includes since it was no longer there
to begin with.
Cc: "David S. Miller" <davem@davemloft.net> Cc: Tejun Heo <tj@kernel.org> Cc: "Rosen, Rami" <rami.rosen@intel.com> Cc: Daniel Wagner <daniel.wagner@bmw-carit.de> Cc: netdev@vger.kernel.org Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Paul Gortmaker [Sun, 21 Apr 2019 03:29:45 +0000 (23:29 -0400)]
net: tc_act: drop include of module.h from tc_ife.h
Ideally, header files under include/linux shouldn't be adding
includes of other headers, in anticipation of their consumers,
but just the headers needed for the header itself to pass
parsing with CPP.
The module.h is particularly bad in this sense, as it itself does
include a whole bunch of other headers, due to the complexity of
module support.
Since tc_ife.h is not going into a module struct looking for
specific fields, we can just let it know that module is a struct,
just like about 60 other include/linux headers already do.
Cc: Jamal Hadi Salim <jhs@mojatatu.com> Cc: Cong Wang <xiyou.wangcong@gmail.com> Cc: Jiri Pirko <jiri@resnulli.us> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Paul Gortmaker [Sun, 21 Apr 2019 03:29:44 +0000 (23:29 -0400)]
net: fib: drop include of module.h from fib_notifier.h
Ideally, header files under include/linux shouldn't be adding
includes of other headers, in anticipation of their consumers,
but just the headers needed for the header itself to pass
parsing with CPP.
The module.h is particularly bad in this sense, as it itself does
include a whole bunch of other headers, due to the complexity of
module support.
Since fib_notifier.h is not going into a module struct looking for
specific fields, we can just let it know that module is a struct,
just like about 60 other include/linux headers already do.
Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Paul Gortmaker [Sun, 21 Apr 2019 03:29:43 +0000 (23:29 -0400)]
net: ife: drop include of module.h from net/ife.h
Ideally, header files under include/linux shouldn't be adding
includes of other headers, in anticipation of their consumers,
but just the headers needed for the header itself to pass
parsing with CPP.
The module.h is particularly bad in this sense, as it itself does
include a whole bunch of other headers, due to the complexity of
module support.
There doesn't appear to be anything in net/ife.h that is module
related, and build coverage doesn't appear to show any other
files/drivers relying implicitly on getting it from here.
So it appears we are simply free to just remove it in this case.
Cc: Yotam Gigi <yotam.gi@gmail.com> Cc: Jamal Hadi Salim <jhs@mojatatu.com> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Paul Gortmaker [Sun, 21 Apr 2019 03:29:42 +0000 (23:29 -0400)]
net: psample: drop include of module.h from psample.h
Ideally, header files under include/linux shouldn't be adding
includes of other headers, in anticipation of their consumers,
but just the headers needed for the header itself to pass
parsing with CPP.
The module.h is particularly bad in this sense, as it itself does
include a whole bunch of other headers, due to the complexity of
module support.
There doesn't appear to be anything in psample.h that is module
related, and build coverage doesn't appear to show any other
files/drivers relying implicitly on getting it from here.
So it appears we are simply free to just remove it in this case.
Cc: Yotam Gigi <yotam.gi@gmail.com> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
projects / linux.git / log