We already have dummy-codec, dummy-platform.
But its issues are
1) we don't have dummy-cpu,
2) we can't select it via DeviceTree
3) It do nothing
Sometimes we want to have Dummy Sound Component for debugging,
for testing, for learning Framework behavior, etc, etc...
This patch adds Test-Component driver for it.
User can select CPU Component by using "test-cpu" compatible,
and can select Codec Component by using "test-codec" compatible.
It doesn't support Platform so far, but is easy to add.
We can verbose print to know its progress if user selected
xxx-verbose compatible driver.
for example,
test-cpu : silent Component, silent DAI
test-cpu-verbose-component : verbose Component, silent DAI
test-cpu-verbose-dai : silent Component, verbose DAI
test-cpu-verbose : verbose Component, verbose DAI
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/877dein8rx.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch adds test-component sound device YAML bindings.
It can be used for Sound Test/Debug.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/878ryyn8s4.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Referring to the note under USBH reset and clocks chapter of RM0436,
"In order to access USBH_OHCI registers it is necessary to activate the USB
clocks by enabling the PLL controlled by USBPHYC" (ck_usbo_48m).
The point is, when USBPHYC PLL is not enabled, OHCI register access
freezes the resume from STANDBY. It is the case when dual USBH is enabled,
instead of OTG + single USBH.
When OTG is probed, as ck_usbo_48m is USBO clock parent, then USBPHYC PLL
is enabled and OHCI register access is OK.
This patch adds ck_usbo_48m (provided by USBPHYC PLL) as clock of USBH
OHCI, thus USBPHYC PLL will be enabled and OHCI register access will be OK.
Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
The STM32 SAI subblocks registers offsets are in the range
0x0004 (SAIx_CR1) to 0x0020 (SAIx_DR).
The corresponding range length is 0x20 instead of 0x1c.
Change reg property accordingly.
Fixes: 5afd65c3a0 ("ARM: dts: stm32: add sai support on stm32mp157c")
Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
STUSB1600 IRQ (Alert pin) is active low (open drain). Interrupts may get
lost currently, so fix the IRQ type.
Fixes: 83686162c0 ("ARM: dts: stm32: add STUSB1600 Type-C using I2C4 on stm32mp15xx-dkx")
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
The Seeed Odyssey-STM32MP157C board has a 20-pin DVP camera output. The
DCMI pins used on this output are defined in the pin state definition
&pinctrl/dcmi-1, AKA &dcmi_pins_b (added in mainline commit
02814a4152). Set these pins as the default
pinctrl of the DCMI peripheral in the board device tree.
The pins are not used for any other purpose, so it seems safe to assume
most users will not need to override (delete) what this patch provides.
status defaults to "disabled", so the peripheral will not be
unnecessarily started. And the users who actually intend to make use of
a camera on the DVP port will have this little part of the configuration
ready.
Signed-off-by: Grzegorz Szymaszek <gszymaszek@short.pl>
Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
The SPI NOR is a bit further away from the SoC on DHCOR than on DHCOM,
which causes additional signal delay. At 108 MHz, this delay triggers
a sporadic issue where the first bit of RX data is not received by the
QSPI controller.
There are two options of addressing this problem, either by using the
DLYB block to compensate the extra delay, or by reducing the QSPI bus
clock frequency. The former requires calibration and that is overly
complex, so opt for the second option.
Fixes: 76045bc457 ("ARM: dts: stm32: Add QSPI NOR on AV96")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Cc: linux-stm32@st-md-mailman.stormreply.com
To: linux-arm-kernel@lists.infradead.org
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Add support of stm32mp135f discovery board (part number: STM32MP135F-DK).
It embeds a STM32MP135F SOC with 512 MB of DDR3.
Several connections are available on this board:
4*USB2.0, 1*USB2.0 typeC DRD, SDcard, 2*RJ45, HDMI, Combo Wifi/BT, ...
Only SD card, uart4 (console) and watchdog IPs are enabled in this commit.
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
These both functions are only used by the remoteproc_virtio.
There is no reason to expose them in the API.
Move the functions in remoteproc_virtio.c
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20211001101234.4247-4-arnaud.pouliquen@foss.st.com
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210920090522.23784-10-wsa+renesas@sang-engineering.com
In this function, devm_platform_ioremap_resource_byname() should be
suitable to simplify code.
Signed-off-by: zhaoxiao <long870912@gmail.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210906071147.9095-1-long870912@gmail.com
If 'copy_dma_range_map() fails, the memory allocated for 'rvdev' will leak.
Move the 'copy_dma_range_map()' call after the device registration so
that 'rproc_rvdev_release()' can be called to free some resources.
Also, branch to the error handling path if 'copy_dma_range_map()' instead
of a direct return to avoid some other leaks.
Fixes: e0d072782c ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Jim Quinlan <james.quinlan@broadcom.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/e6d0dad6620da4fdf847faa903f79b735d35f262.1630755377.git.christophe.jaillet@wanadoo.fr
Go through the code base and use ice_for_each_* macros. While at it,
introduce ice_for_each_xdp_txq() macro that can be used for looping over
xdp_rings array.
Commit is not introducing any new functionality.
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Under rare circumstances there might be a situation where a requirement
of having XDP Tx queue per CPU could not be fulfilled and some of the Tx
resources have to be shared between CPUs. This yields a need for placing
accesses to xdp_ring inside a critical section protected by spinlock.
These accesses happen to be in the hot path, so let's introduce the
static branch that will be triggered from the control plane when driver
could not provide Tx queue dedicated for XDP on each CPU.
Currently, the design that has been picked is to allow any number of XDP
Tx queues that is at least half of a count of CPUs that platform has.
For lower number driver will bail out with a response to user that there
were not enough Tx resources that would allow configuring XDP. The
sharing of rings is signalled via static branch enablement which in turn
indicates that lock for xdp_ring accesses needs to be taken in hot path.
Approach based on static branch has no impact on performance of a
non-fallback path. One thing that is needed to be mentioned is a fact
that the static branch will act as a global driver switch, meaning that
if one PF got out of Tx resources, then other PFs that ice driver is
servicing will suffer. However, given the fact that HW that ice driver
is handling has 1024 Tx queues per each PF, this is currently an
unlikely scenario.
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Tested-by: George Kuruvinakunnel <george.kuruvinakunnel@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Optimize Tx descriptor cleaning for XDP. Current approach doesn't
really scale and chokes when multiple flows are handled.
Introduce two ring fields, @next_dd and @next_rs that will keep track of
descriptor that should be looked at when the need for cleaning arise and
the descriptor that should have the RS bit set, respectively.
Note that at this point the threshold is a constant (32), but it is
something that we could make configurable.
First thing is to get away from setting RS bit on each descriptor. Let's
do this only once NTU is higher than the currently @next_rs value. In
such case, grab the tx_desc[next_rs], set the RS bit in descriptor and
advance the @next_rs by a 32.
Second thing is to clean the Tx ring only when there are less than 32
free entries. For that case, look up the tx_desc[next_dd] for a DD bit.
This bit is written back by HW to let the driver know that xmit was
successful. It will happen only for those descriptors that had RS bit
set. Clean only 32 descriptors and advance the DD bit.
Actual cleaning routine is moved from ice_napi_poll() down to the
ice_xmit_xdp_ring(). It is safe to do so as XDP ring will not get any
SKBs in there that would rely on interrupts for the cleaning. Nice side
effect is that for rare case of Tx fallback path (that next patch is
going to introduce) we don't have to trigger the SW irq to clean the
ring.
With those two concepts, ring is kept at being almost full, but it is
guaranteed that driver will be able to produce Tx descriptors.
This approach seems to work out well even though the Tx descriptors are
produced in one-by-one manner. Test was conducted with the ice HW
bombarded with packets from HW generator, configured to generate 30
flows.
Xdp2 sample yields the following results:
<snip>
proto 17: 79973066 pkt/s
proto 17: 80018911 pkt/s
proto 17: 80004654 pkt/s
proto 17: 79992395 pkt/s
proto 17: 79975162 pkt/s
proto 17: 79955054 pkt/s
proto 17: 79869168 pkt/s
proto 17: 79823947 pkt/s
proto 17: 79636971 pkt/s
</snip>
As that sample reports the Rx'ed frames, let's look at sar output.
It says that what we Rx'ed we do actually Tx, no noticeable drops.
Average: IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
Average: ens4f1 79842324.00 79842310.40 4678261.17 4678260.38 0.00 0.00 0.00 38.32
with tx_busy staying calm.
When compared to a state before:
Average: IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
Average: ens4f1 90919711.60 42233822.60 5327326.85 2474638.04 0.00 0.00 0.00 43.64
it can be observed that the amount of txpck/s is almost doubled, meaning
that the performance is improved by around 90%. All of this due to the
drops in the driver, previously the tx_busy stat was bumped at a 7mpps
rate.
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Tested-by: George Kuruvinakunnel <george.kuruvinakunnel@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
With rings being split, it is now convenient to introduce a pointer to
XDP ring within the Rx ring. For XDP_TX workloads this means that
xdp_rings array access will be skipped, which was executed per each
processed frame.
Also, read the XDP prog once per NAPI and if prog is present, set up the
local xdp_ring pointer. Reading prog a single time was discussed in [1]
with some concern raised by Toke around dispatcher handling and having
the need for going through the RCU grace period in the ndo_bpf driver
callback, but ice currently is torning down NAPI instances regardless of
the prog presence on VSI.
Although the pointer to XDP ring introduced to Rx ring makes things a
lot slimmer/simpler, I still feel that single prog read per NAPI
lifetime is beneficial.
Further patch that will introduce the fallback path will also get a
profit from that as xdp_ring pointer will be set during the XDP rings
setup.
[1]: https://lore.kernel.org/bpf/87k0oseo6e.fsf@toke.dk/
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Tested-by: George Kuruvinakunnel <george.kuruvinakunnel@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
xdp_frame is not needed for XDP_TX data path in ice driver case.
For this data path cleaning of sent descriptor will not happen anywhere
outside of the driver, which means that carrying the information about
the underlying memory model via xdp_frame will not be used. Therefore,
this conversion can be simply dropped, which would relieve CPU a bit.
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Tested-by: George Kuruvinakunnel <george.kuruvinakunnel@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
There has been a long lasting issue of improper xdp_rings indexing for
XDP_TX and XDP_REDIRECT actions. Given that currently rx_ring->q_index
is mixed with smp_processor_id(), there could be a situation where Tx
descriptors are produced onto XDP Tx ring, but tail is never bumped -
for example pin a particular queue id to non-matching IRQ line.
Address this problem by ignoring the user ring count setting and always
initialize the xdp_rings array to be of num_possible_cpus() size. Then,
always use the smp_processor_id() as an index to xdp_rings array. This
provides serialization as at given time only a single softirq can run on
a particular CPU.
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Tested-by: George Kuruvinakunnel <george.kuruvinakunnel@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
While it was convenient to have a generic ring structure that served
both Tx and Rx sides, next commits are going to introduce several
Tx-specific fields, so in order to avoid hurting the Rx side, let's
pull out the Tx ring onto new ice_tx_ring and ice_rx_ring structs.
Rx ring could be handled by the old ice_ring which would reduce the code
churn within this patch, but this would make things asymmetric.
Make the union out of the ring container within ice_q_vector so that it
is possible to iterate over newly introduced ice_tx_ring.
Remove the @size as it's only accessed from control path and it can be
calculated pretty easily.
Change definitions of ice_update_ring_stats and
ice_fetch_u64_stats_per_ring so that they are ring agnostic and can be
used for both Rx and Tx rings.
Sizes of Rx and Tx ring structs are 256 and 192 bytes, respectively. In
Rx ring xdp_rxq_info occupies its own cacheline, so it's the major
difference now.
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Currently ice_container_type is scoped only for ice_ethtool.c. Next
commit that will split the ice_ring struct onto Rx/Tx specific ring
structs is going to also modify the type of linked list of rings that is
within ice_ring_container. Therefore, the functions that are taking the
ice_ring_container as an input argument will need to be aware of a ring
type that will be looked up.
Embed ice_container_type within ice_ring_container and initialize it
properly when allocating the q_vectors.
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
This field is dead and driver is not making any use of it. Simply remove
it.
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
- fix module autoloading on gpio-74x164 after a revert of OF modaliases
- fix problems with the bias setting in gpio-pca953x
- fix a use-after-free bug in gpio-mockup by using software nodes
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEFp3rbAvDxGAT0sefEacuoBRx13IFAmFpdQUACgkQEacuoBRx
13JpLRAAuf/8qGqPzdU6zvzU8lXMRKEibjAdG65tk4eOsZhcmydhYVZ2TktycUK2
4MZE0oNClmSZlB2hm/UT/94h5LXRqsAxD+IC66siZB7keK00KV5TdR+JSAMlKt1F
fzAIf4RWgc2Nfqy+Xp5JJaPr8fiM1S6/LjNJJCdbPERWI4pC7x0CamnooatGf4N8
mM7MIrUVll1OKvpSYAiqE4SgGr2WcxbM3334ZniBk++YowA0nT7GBwC9Yzoc0jzR
9njv6U2H1WOpeNWpwOYYjnyHIRClfPcyzi0KmetrQjQYa+rzavAQZ/TmM5eQn+D3
K+7Wbo5I4/YRBuNBGLnW1W1DTSJRk5+x3bkfvSgYxU59r1P/UNhJpqg8WB0t5XRw
ILELPzugJkj77mSQyjBzmj7NsqgMd3B8YY8VUneB/cAHyeTqouqVRvpbr1Y1WTTv
J2Pwwtz2Sg0FENVVI1hy+L9IuLaf1Yt7WQBabYCLdgz0aOLte3h8HyPLsJef1UL5
VG8e1hKbNwfuWXVVLHcykNi61MKM0sSH4BwiaHWsOBDrE+tO6dzDz3kCEOoF7+FI
nzx1gT6HqeUf43rXu9AJd6+nGd+RlwoGSlioBWXtfFoenKr8OcmvEEK0h+BE7O56
NenCKlCXqDas1xiZM2xTixdyhHccZPDncAx5F34FYs3ixk7yGsQ=
=dOer
-----END PGP SIGNATURE-----
Merge tag 'gpio-fixes-for-v5.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull gpio fixes from Bartosz Golaszewski:
- fix module autoloading on gpio-74x164 after a revert of OF modaliases
- fix problems with the bias setting in gpio-pca953x
- fix a use-after-free bug in gpio-mockup by using software nodes
* tag 'gpio-fixes-for-v5.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
gpio: mockup: Convert to use software nodes
gpio: pca953x: Improve bias setting
gpio: 74x164: Add SPI device ID table
A few small fixes for v5.15, mostly driver specific but there's one in
the core which fixes a deadlock when adding devices on spi-mux that's
triggered because spi-mux is a SPI device which is itself a SPI
controller and so can instantiate devices when registered. We were
using a global lock to protect against reusing chip selects but they're
a per controller thing so moving the lock per controller resolves that.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmFpaEoACgkQJNaLcl1U
h9Buawf/QpqpYKY+/ZiU3VG1iYYB3zE/KNsBVGPwDHIwLWX5NRxtGupERqoHgqaR
e2Omo459vLdfShXSEuur5Co95q8nbgBxzbFYf/5/fPVmCQipWqAZ6AjJj60fpAP3
qVlXYvYrxUDfGywCkMQjLN3o+dcDxaGVG6+u1vvEnbdMt96lVbOKj2meaFpQ1jbj
faY5GR/+5ZzhvzpxY3/FV6dlwvEdMRon0k6pFLis0YvxyOvQZffRdvAI4KxiFVP9
bAIPRGyn8tbppXlVJBBncRy/aSIxijauk3xGuPmRoy7CZaVZMwlfcPJ18NGixAVG
B9f08ADBY7gAiEiJDCYX0u4ZaAOq+w==
=U/5f
-----END PGP SIGNATURE-----
Merge tag 'spi-fix-v5.15-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A few small fixes.
Mostly driver specific but there's one in the core which fixes a
deadlock when adding devices on spi-mux that's triggered because
spi-mux is a SPI device which is itself a SPI controller and so can
instantiate devices when registered.
We were using a global lock to protect against reusing chip selects
but they're a per controller thing so moving the lock per controller
resolves that"
* tag 'spi-fix-v5.15-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi-mux: Fix false-positive lockdep splats
spi: Fix deadlock when adding SPI controllers on SPI buses
spi: bcm-qspi: clear MSPI spifie interrupt during probe
spi: spi-nxp-fspi: don't depend on a specific node name erratum workaround
spi: mediatek: skip delays if they are 0
spi: atmel: Fix PDC transfer setup bug
spi: spidev: Add SPI ID table
spi: Use 'flash' node name instead of 'spi-flash' in example
Just a trivial fix to the MAINTAINERS file for an update missed during
conversion of the DT bindings to YAML format.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmFpaKIACgkQJNaLcl1U
h9CELAf/dc15I7uk2CVZ2G+60kyL0aW8AJkpUVdBBQ/BFT2feLAEIUJUO4/zE8nt
gxT9BP+IkB++j8qqfGLJ15e8mINDRA35OWyscdr/oy9rg/5ZCBBO55AGSACn5Ege
bNSXQoQw6ZUE/X/es6voecLCJjSw76pqI3NMfq6m5961Xw79vRPXPPypnlS+atDm
OSjesPtVLls/LbHowFfAeifrS0Ck8S3T/4Wha/XxoCNOPYh4yaNsuR/AMsYw5EN5
U1hobI5uU10P7u/CmUbACrbp20sS0KYXC1YzJNldDjxqCPPH/RoiskrxTyx7tPtB
F1Zs5aY/HGiyPnRuDaoHzYdcrEI8+Q==
=GYqF
-----END PGP SIGNATURE-----
Merge tag 'regulator-fix-v5.15-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fix from Mark Brown:
"Just a trivial fix to the MAINTAINERS file for an update missed during
conversion of the DT bindings to YAML format"
* tag 'regulator-fix-v5.15-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
MAINTAINERS: rectify entry for SY8106A REGULATOR DRIVER
smb2_validate_credit_charge() accesses fields in the SMB2 PDU body,
but until smb2_calc_size() is called the PDU has not yet been verified
to be large enough to access the PDU dynamic part length field.
Acked-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Ralph Boehme <slow@samba.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
Add buffer validation for smb direct.
Acked-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Hyunchul Lee <hyc.lee@gmail.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
ksmbd limit read/write/trans buffer size not to exceed maximum 8MB.
And set the minimum value of max response buffer size to 64KB.
Windows client doesn't send session setup request if ksmbd set max
trans/read/write size lower than 64KB in smb2 negotiate.
It means windows allow at least 64 KB or more about this value.
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
* Qcom: Update code word value for raw reads (QPIC v2+)
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEE9HuaYnbmDhq/XIDIJWrqGEe9VoQFAmFpVGEACgkQJWrqGEe9
VoR5IggAj5dtbvVx89icuQp1yfBebZJXQGVvd06E1Btk36nic538SHnEkc3heiUZ
ySxBiN8mKI/0wgOK3PBxRoSU9XNAl32W4AmG2nQzhfgL1AL0bCKlaOVuf305ts58
SGECfEawVNbMZKH/WFwsHQBMH+d+B8oMiWgK7h694OCWQxnQSTBYKCGEB9Dzqjjd
8l0oQBTgPGOFrb3p0P+GRFbSFy+wLPIQpU9hm1HoXQxZk7K6fSkPqjTYP8FUI8Nc
bAaQTM7Y2rA2GyandlhUnEkQICu1P1MEVxh9viNYyPKb9Lu85F7mpDa8kCPxq3LS
67X9gJO+PIzvW0wy6zsSWTWC8giaGg==
=gtld
-----END PGP SIGNATURE-----
Merge tag 'mtd/fixes-for-5.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
Pull mtd fix from Miquel Raynal:
"Raw NAND controller driver fix:
- Qcom: Update code word value for raw reads (QPIC v2+)"
* tag 'mtd/fixes-for-5.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux:
mtd: rawnand: qcom: Update code word value for raw read
core:
- clamp fbdev size
- edid cap blocks read to avoid out of bounds
panel:
- fix missing crc32 dependency
msm:
- Fix a new crash on dev file close if the dev file was opened when
GPU is not loaded (such as missing fw in initrd)
- Switch to single drm_sched_entity per priority level per drm_file
to unbreak multi-context userspace
- Serialize GMU access to fix GMU OOB errors
- Various error path fixes
- A couple integer overflow fixes
- Fix mdp5 cursor plane WARNs
i915:
- Fix ACPI object leak
- Fix context leak in user proto-context creation
- Fix missing i915_sw_fence_fini call
hyperv:
- hide hw pointer
nouveau:
- fix engine selection bit
r128:
- fix UML build
rcar-du:
- unconncted LVDS regression fix
mediatek:
- revert CMDQ refinement patches
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEEKbZHaGwW9KfbeusDHTzWXnEhr4FAmFpDcIACgkQDHTzWXnE
hr4p4A/+KAuKSB1WxV3EuGZWB18Tr04L5cfZW7m/Fy0UKKDnfLoPIlYqyM2Y4aMM
yjG6E7jjOGVK7nKFy9tUOB1DLf8me0tV1ZhWn4/+E7cuhJAC7gBeD1AGnF4jphoI
yZ23k2wXkFWI/6VVeZUnbjhJDeHcgYcUTqzs9IKdjcnSVx50eVsOu67c8z4uHPP6
KZYZjYIe9nuKXcTaiZSLcAyZ3j0kuzCgBBgeOpGNROC/fGoi7BsoFObgVJCUeeSD
1BK/DdpFxJz79SSldayNQc7IXt9Eu3Vic5lq6/EZjYmY/4sBZpORRRZ6Ky28X+1L
GSBWoCC106L2VSZdaAkOurNpqoJox2O7aivHubBigOKXfAmGsjSF6zTY24xsNaCm
TCZ1Y6B+d5kdoxYn0j94oye5v5z9Pi/HhOOja8/ETR6/0/uHmdCXko/s0rOlYDTH
GKzvbi0tKUZOon3mkEXdZWRcDE523q/4x46qfH/wTA5zmgwbo9Xc8HqWTuwOV9tr
N+Huq9oFVhcq8i9RsOQh09vImpen4Dam6dxiCA9GqD8MBH5TL5yarDWW9x3Rq8uX
4YP3J0IqEjl8ytsj1wsrmWYfM4PEbwQLrLW3Ks3SPXa4+mwv8wVTJ2PQkiuzGdCK
yaUAbYsQ6DoEOpfliIft5vL1igMFcdP8pq8fUiwmOwmKp01zFhQ=
=Ey1r
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-2021-10-15-1' of git://anongit.freedesktop.org/drm/drm
Pull drm fixes from Dave Airlie:
"It has a few scattered msm and i915 fixes, a few core fixes and a
mediatek feature revert.
I've had to pick a bunch of patches into this, as the drm-misc-fixes
tree had a bunch of vc4 patches I wasn't comfortable with sending to
you at least as part of this, they were delayed due to your reverts.
If it's really useful as fixes I'll do a separate pull.
Summary:
Core:
- clamp fbdev size
- edid cap blocks read to avoid out of bounds
panel:
- fix missing crc32 dependency
msm:
- Fix a new crash on dev file close if the dev file was opened when
GPU is not loaded (such as missing fw in initrd)
- Switch to single drm_sched_entity per priority level per drm_file
to unbreak multi-context userspace
- Serialize GMU access to fix GMU OOB errors
- Various error path fixes
- A couple integer overflow fixes
- Fix mdp5 cursor plane WARNs
i915:
- Fix ACPI object leak
- Fix context leak in user proto-context creation
- Fix missing i915_sw_fence_fini call
hyperv:
- hide hw pointer
nouveau:
- fix engine selection bit
r128:
- fix UML build
rcar-du:
- unconncted LVDS regression fix
mediatek:
- revert CMDQ refinement patches"
* tag 'drm-fixes-2021-10-15-1' of git://anongit.freedesktop.org/drm/drm: (34 commits)
drm/panel: olimex-lcd-olinuxino: select CRC32
drm/r128: fix build for UML
drm/nouveau/fifo: Reinstate the correct engine bit programming
drm/hyperv: Fix double mouse pointers
drm/fbdev: Clamp fbdev surface size if too large
drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read
drm/i915: Free the returned object of acpi_evaluate_dsm()
drm/i915: Fix bug in user proto-context creation that leaked contexts
drm: rcar-du: Don't create encoder for unconnected LVDS outputs
drm/msm/dsi: fix off by one in dsi_bus_clk_enable error handling
drm/msm/dsi: Fix an error code in msm_dsi_modeset_init()
drm/msm/dsi: dsi_phy_14nm: Take ready-bit into account in poll_for_ready
drm/msm/dsi/phy: fix clock names in 28nm_8960 phy
drm/msm/dpu: Fix address of SM8150 PINGPONG5 IRQ register
drm/msm: Do not run snapshot on non-DPU devices
drm/msm/a3xx: fix error handling in a3xx_gpu_init()
drm/msm/a4xx: fix error handling in a4xx_gpu_init()
drm/msm: Fix null pointer dereference on pointer edp
drm/msm/mdp5: fix cursor-related warnings
drm/msm: Avoid potential overflow in timeout_to_jiffies()
...
Use the samsung common clk driver to initialize the apollo and atlas
clocks. This removes their custom init functions and uses the
samsung_cmu_register_one() instead.
Signed-off-by: Will McVicker <willmcvicker@google.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Link: https://lore.kernel.org/r/20211014195347.3635601-3-willmcvicker@google.com
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Adds 'struct samsung_cpu_clock' and corresponding CPU clock registration
function to the samsung common clk driver. This allows samsung clock
drivers to register their CPU clocks with the samsung_cmu_register_one()
API.
Currently the exynos5433 apollo and atlas clks have their own custom
init functions to handle registering their CPU clocks. With this patch
we can drop their custom CLK_OF_DECLARE functions and directly call
samsung_cmu_register_one().
Signed-off-by: Will McVicker <willmcvicker@google.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Link: https://lore.kernel.org/r/20211014195347.3635601-2-willmcvicker@google.com
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
some memory leaks and panic. Also many minor fixes.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEh0DEKNP0I9IjwfWEqbAzH4MkB7YFAmFoMFQACgkQqbAzH4Mk
B7bTtQ/+KiF48deefbEEExjfT8Mm76+JE0XkdCPT0bXkhVNpqhRLSOQBR2hg5A81
7SSFHNbSMzXxiXdh2KfcXbBmwdJtcH1N9tjwffC3zhMkCTcDKnmDczz/lo4rHd0g
zZ3rPBP9yPCZGxo3W804XRYOeqLclrGJPI3kWQen+Rln/cZIzJMaHRUkVI22OYwj
e0dSdtabFDxJbdewz9xcvycHrPpVlrZUsuib/ZHFu2XGtgKalccgfvwBy5cOrTVh
N1WSBGcoy0xQGRGLP0o2hN62N2Md7/+UwWjXY+Wz4i+4gmziGvGuk8Y5uiSLu7lS
EG12xlrUtwouf4QaeleQZLT9Ym5YU3EALtKpZxAQi6Rm4A8Z6EMNUq0WBHJcNP/u
MRJlfK7jC25GnIFQjZtU+eMX8BT8MgMeSriv9FIY86T3ijedfxxEbb/cMvUGm2Hn
3hoQelLCUkLSqTyMeZiAv507AJv5MjfMrSJ9r9f36OxDer3w84VCVcxDtyGH++CR
fbRNjHvz7gYG5L5qwsFgfxSC/z+hyUXi01RalbosojsRyvg/f1p+yMxvQ57DrltY
IfHrMGcd9FlUiijBGFvyWQoMAl/pb6EIym2IMxr9X+aXgPJiG/BhWLbmzU4MYUUP
1PwIOpN2vhtU2Z3bVzbecxfy/TWjBhKBYe9jW1AH8KSSvLZExjk=
=QUnM
-----END PGP SIGNATURE-----
Merge tag 'ntfs3_for_5.15' of git://github.com/Paragon-Software-Group/linux-ntfs3
Pull ntfs3 fixes from Konstantin Komarov:
"Use the new api for mounting as requested by Christoph.
Also fixed:
- some memory leaks and panic
- xfstests (tested on x86_64) generic/016 generic/021 generic/022
generic/041 generic/274 generic/423
- some typos, wrong returned error codes, dead code, etc"
* tag 'ntfs3_for_5.15' of git://github.com/Paragon-Software-Group/linux-ntfs3: (70 commits)
fs/ntfs3: Check for NULL pointers in ni_try_remove_attr_list
fs/ntfs3: Refactor ntfs_read_mft
fs/ntfs3: Refactor ni_parse_reparse
fs/ntfs3: Refactor ntfs_create_inode
fs/ntfs3: Refactor ntfs_readlink_hlp
fs/ntfs3: Rework ntfs_utf16_to_nls
fs/ntfs3: Fix memory leak if fill_super failed
fs/ntfs3: Keep prealloc for all types of files
fs/ntfs3: Remove unnecessary functions
fs/ntfs3: Forbid FALLOC_FL_PUNCH_HOLE for normal files
fs/ntfs3: Refactoring of ntfs_set_ea
fs/ntfs3: Remove locked argument in ntfs_set_ea
fs/ntfs3: Use available posix_acl_release instead of ntfs_posix_acl_release
fs/ntfs3: Check for NULL if ATTR_EA_INFO is incorrect
fs/ntfs3: Refactoring of ntfs_init_from_boot
fs/ntfs3: Reject mount if boot's cluster size < media sector size
fs/ntfs3: Refactoring lock in ntfs_init_acl
fs/ntfs3: Change posix_acl_equiv_mode to posix_acl_update_mode
fs/ntfs3: Pass flags to ntfs_set_ea in ntfs_set_acl_ex
fs/ntfs3: Refactor ntfs_get_acl_ex for better readability
...
We call idle_kvm_start_guest() from power7_offline() if the thread has
been requested to enter KVM. We pass it the SRR1 value that was returned
from power7_idle_insn() which tells us what sort of wakeup we're
processing.
Depending on the SRR1 value we pass in, the KVM code might enter the
guest, or it might return to us to do some host action if the wakeup
requires it.
If idle_kvm_start_guest() is able to handle the wakeup, and enter the
guest it is supposed to indicate that by returning a zero SRR1 value to
us.
That was the behaviour prior to commit 10d91611f4 ("powerpc/64s:
Reimplement book3s idle code in C"), however in that commit the
handling of SRR1 was reworked, and the zeroing behaviour was lost.
Returning from idle_kvm_start_guest() without zeroing the SRR1 value can
confuse the host offline code, causing the guest to crash and other
weirdness.
Fixes: 10d91611f4 ("powerpc/64s: Reimplement book3s idle code in C")
Cc: stable@vger.kernel.org # v5.2+
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20211015133929.832061-2-mpe@ellerman.id.au
In commit 10d91611f4 ("powerpc/64s: Reimplement book3s idle code in
C") kvm_start_guest() became idle_kvm_start_guest(). The old code
allocated a stack frame on the emergency stack, but didn't use the
frame to store anything, and also didn't store anything in its caller's
frame.
idle_kvm_start_guest() on the other hand is written more like a normal C
function, it creates a frame on entry, and also stores CR/LR into its
callers frame (per the ABI). The problem is that there is no caller
frame on the emergency stack.
The emergency stack for a given CPU is allocated with:
paca_ptrs[i]->emergency_sp = alloc_stack(limit, i) + THREAD_SIZE;
So emergency_sp actually points to the first address above the emergency
stack allocation for a given CPU, we must not store above it without
first decrementing it to create a frame. This is different to the
regular kernel stack, paca->kstack, which is initialised to point at an
initial frame that is ready to use.
idle_kvm_start_guest() stores the backchain, CR and LR all of which
write outside the allocation for the emergency stack. It then creates a
stack frame and saves the non-volatile registers. Unfortunately the
frame it creates is not large enough to fit the non-volatiles, and so
the saving of the non-volatile registers also writes outside the
emergency stack allocation.
The end result is that we corrupt whatever is at 0-24 bytes, and 112-248
bytes above the emergency stack allocation.
In practice this has gone unnoticed because the memory immediately above
the emergency stack happens to be used for other stack allocations,
either another CPUs mc_emergency_sp or an IRQ stack. See the order of
calls to irqstack_early_init() and emergency_stack_init().
The low addresses of another stack are the top of that stack, and so are
only used if that stack is under extreme pressue, which essentially
never happens in practice - and if it did there's a high likelyhood we'd
crash due to that stack overflowing.
Still, we shouldn't be corrupting someone else's stack, and it is purely
luck that we aren't corrupting something else.
To fix it we save CR/LR into the caller's frame using the existing r1 on
entry, we then create a SWITCH_FRAME_SIZE frame (which has space for
pt_regs) on the emergency stack with the backchain pointing to the
existing stack, and then finally we switch to the new frame on the
emergency stack.
Fixes: 10d91611f4 ("powerpc/64s: Reimplement book3s idle code in C")
Cc: stable@vger.kernel.org # v5.2+
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20211015133929.832061-1-mpe@ellerman.id.au
When device_register() return failed, program will goto out_kfree_type
to release 'cdev->device' by put_device(). That will call thermal_release()
to free 'cdev'. But the follow-up processes access 'cdev' continually.
That trggers the UAF bug.
====================================================================
BUG: KASAN: use-after-free in __thermal_cooling_device_register+0x75b/0xa90
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
dump_stack_lvl+0xe2/0x152
print_address_description.constprop.0+0x21/0x140
? __thermal_cooling_device_register+0x75b/0xa90
kasan_report.cold+0x7f/0x11b
? __thermal_cooling_device_register+0x75b/0xa90
__thermal_cooling_device_register+0x75b/0xa90
? memset+0x20/0x40
? __sanitizer_cov_trace_pc+0x1d/0x50
? __devres_alloc_node+0x130/0x180
devm_thermal_of_cooling_device_register+0x67/0xf0
max6650_probe.cold+0x557/0x6aa
......
Freed by task 258:
kasan_save_stack+0x1b/0x40
kasan_set_track+0x1c/0x30
kasan_set_free_info+0x20/0x30
__kasan_slab_free+0x109/0x140
kfree+0x117/0x4c0
thermal_release+0xa0/0x110
device_release+0xa7/0x240
kobject_put+0x1ce/0x540
put_device+0x20/0x30
__thermal_cooling_device_register+0x731/0xa90
devm_thermal_of_cooling_device_register+0x67/0xf0
max6650_probe.cold+0x557/0x6aa [max6650]
Do not use 'cdev' again after put_device() to fix the problem like doing
in thermal_zone_device_register().
[dlezcano]: as requested by Rafael, change the affectation into two statements.
Fixes: 5848376181 ("thermal/drivers/core: Use a char pointer for the cooling device name")
Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/20211015024504.947520-1-william.xuanziyang@huawei.com
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
This is the initial implementation adding only basic clocks like UART,
MMC, I2C and corresponding parent clocks. Design is influenced by
Exynos5433 clock driver.
Bus clock is enabled by default (in probe function) for all CMUs except
CMU_TOP, the reasoning is as follows. By default if bus clock has no
users its "enable count" value is 0. It might be actually running if
it's already enabled in bootloader, but then in some cases it can be
disabled by mistake. For example, such case was observed when
dw_mci_probe() enabled the bus clock, then failed to do something and
disabled that bus clock on error path. After that, even the attempt to
read the 'clk_summary' file in DebugFS freezed forever, as CMU bus clock
ended up being disabled and it wasn't possible to access CMU registers
anymore.
To avoid such cases, CMU driver must increment the ref count for that
bus clock by running clk_prepare_enable(). There is already existing
'.clk_name' field in struct samsung_cmu_info, exactly for that reason.
It was added in commit 523d3de41f ("clk: samsung: exynos5433: Add
support for runtime PM"), with next mentioning in commit message:
> Also for each CMU there is one special parent clock, which has to be
> enabled all the time when any access to CMU registers is being done.
But that clock is actually only enabled in Exynos5433 clock driver right
now. So the same code is added to exynos850_cmu_probe() function,
As was described above, it might be helpful not only for PM reasons, but
also to prevent possible erroneous clock gating on error paths.
Another way to workaround that issue would be to use CLOCK_IS_CRITICAL
flag for corresponding gate clocks. But that might be not very good
design decision, as we might still want to disable that bus clock, e.g.
on PM suspend.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Link: https://lore.kernel.org/r/20211008154352.19519-6-semen.protsenko@linaro.org
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Leonard Crestez says:
====================
tcp: md5: Fix overlap between vrf and non-vrf keys
With net.ipv4.tcp_l3mdev_accept=1 it is possible for a listen socket to
accept connection from the same client address in different VRFs. It is
also possible to set different MD5 keys for these clients which differ only
in the tcpm_l3index field.
This appears to work when distinguishing between different VRFs but not
between non-VRF and VRF connections. In particular:
* tcp_md5_do_lookup_exact will match a non-vrf key against a vrf key. This
means that adding a key with l3index != 0 after a key with l3index == 0
will cause the earlier key to be deleted. Both keys can be present if the
non-vrf key is added later.
* _tcp_md5_do_lookup can match a non-vrf key before a vrf key. This casues
failures if the passwords differ.
This can be fixed by making tcp_md5_do_lookup_exact perform an actual exact
comparison on l3index and by making __tcp_md5_do_lookup perfer vrf-bound
keys above other considerations like prefixlen.
The fact that keys with l3index==0 affect VRF connections is usually not
desirable, VRFs are meant to be completely independent. This behavior needs
to preserved for backwards compatibility. Also, applications can just bind
listen sockets to VRF and never specify TCP_MD5SIG_FLAG_IFINDEX at all.
So far the combination of TCP_MD5SIG_FLAG_IFINDEX with tcpm_ifindex == 0
was an error, accept this to mean "key only applies to default VRF". This
is what applications using VRFs for traffic separation want.
This also contains tests for the second part. It does not contain tests for
overlapping keys, that would require more changes in nettest to add
multiple keys. These scenarios are also covered by my tests for TCP-AO,
especially around this area:
https://github.com/cdleonard/tcp-authopt-test/blob/main/tcp_authopt_test/test_vrf_bind.py
Changes since V2:
* Rename --do-bind-key-ifindex to --force-bind-key-ifindex
* Fix referencing TCP_MD5SIG_FLAG_IFINDEX as TCP_MD5SIG_IFINDEX
Link to v2: https://lore.kernel.org/netdev/cover.1634107317.git.cdleonard@gmail.com/
Changes since V1:
* Accept (TCP_MD5SIG_IFINDEX with tcpm_ifindex == 0)
* Add flags for explicitly including or excluding TCP_MD5SIG_FLAG_IFINDEX
to nettest
* Add few more tests in fcnal-test.sh.
Link to v1: https://lore.kernel.org/netdev/3d8387d499f053dba5cd9184c0f7b8445c4470c6.1633542093.git.cdleonard@gmail.com/
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Test that applications binding listening sockets to VRFs without
specifying TCP_MD5SIG_FLAG_IFINDEX will work as expected. This would
be broken if __tcp_md5_do_lookup always made a strict comparison on
l3index. See this email:
https://lore.kernel.org/netdev/209548b5-27d2-2059-f2e9-2148f5a0291b@gmail.com/
Applications using tcp_l3mdev_accept=1 and a single global socket (not
bound to any interface) also should have a way to specify keys that are
only for the default VRF, this is done by --force-bind-key-ifindex
without otherwise binding to a device.
Signed-off-by: Leonard Crestez <cdleonard@gmail.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
These options allow explicit control over the TCP_MD5SIG_FLAG_IFINDEX
flag instead of always setting it based on binding to an interface.
Do this by converting to getopt_long because nettest has too many
single-character flags already and getopt_long is widely used in
selftests.
Signed-off-by: Leonard Crestez <cdleonard@gmail.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Multiple VRFs are generally meant to be "separate" but right now md5
keys for the default VRF also affect connections inside VRFs if the IP
addresses happen to overlap.
So far the combination of TCP_MD5SIG_FLAG_IFINDEX with tcpm_ifindex == 0
was an error, accept this to mean "key only applies to default VRF".
This is what applications using VRFs for traffic separation want.
Signed-off-by: Leonard Crestez <cdleonard@gmail.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
With net.ipv4.tcp_l3mdev_accept=1 it is possible for a listen socket to
accept connection from the same client address in different VRFs. It is
also possible to set different MD5 keys for these clients which differ
only in the tcpm_l3index field.
This appears to work when distinguishing between different VRFs but not
between non-VRF and VRF connections. In particular:
* tcp_md5_do_lookup_exact will match a non-vrf key against a vrf key.
This means that adding a key with l3index != 0 after a key with l3index
== 0 will cause the earlier key to be deleted. Both keys can be present
if the non-vrf key is added later.
* _tcp_md5_do_lookup can match a non-vrf key before a vrf key. This
casues failures if the passwords differ.
Fix this by making tcp_md5_do_lookup_exact perform an actual exact
comparison on l3index and by making __tcp_md5_do_lookup perfer
vrf-bound keys above other considerations like prefixlen.
Fixes: dea53bb80e ("tcp: Add l3index to tcp_md5sig_key and md5 functions")
Signed-off-by: Leonard Crestez <cdleonard@gmail.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix the following build/link error by adding a dependency on the CRC32
routines:
ld: drivers/net/usb/lan78xx.o: in function `lan78xx_set_multicast':
lan78xx.c:(.text+0x48cf): undefined reference to `crc32_le'
The actual use of crc32_le() comes indirectly through ether_crc().
Fixes: 55d7de9de6 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ioana Ciornei says:
====================
dpaa2-eth: add support for IRQ coalescing
This patch set adds support for interrupts coalescing in dpaa2-eth.
The first patches add support for the hardware level configuration of
the IRQ coalescing in the dpio driver, while the ones that touch the
dpaa2-eth driver are responsible for the ethtool user interraction.
With the adaptive IRQ coalescing in place and enabled we have observed
the following changes in interrupt rates on one A72 core @2.2GHz
(LX2160A) while running a Rx TCP flow. The TCP stream is sent on a
10Gbit link and the only cpu that does Rx is fully utilized.
IRQ rate (irqs / sec)
before: 4.59 Gbits/sec 24k
after: 5.67 Gbits/sec 1.3k
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Add support for adaptive interrupt coalescing to the dpaa2-eth driver.
First of all, ETHTOOL_COALESCE_USE_ADAPTIVE_RX is defined as a supported
coalesce parameter and the requested state is configured through the
dpio APIs added in the previous patch.
Besides the ethtool API interaction, we keep track of how many bytes and
frames are dequeued per CDAN (Channel Data Availability Notification)
and update the Net DIM instance through the dpaa2_io_update_net_dim()
API.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Use the generic dynamic interrupt moderation (dim) framework to
implement adaptive interrupt coalescing on Rx. With the per-packet
interrupt scheme, a high interrupt rate has been noted for moderate
traffic flows leading to high CPU utilization.
The dpio driver exports new functions to enable/disable adaptive IRQ
coalescing on a DPIO object, to query the state or to update Net DIM
with a new set of bytes and frames dequeued.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
