| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Update supported pci_device_id table to include the values for the G7+ ASIC
Device ID utilized by LPe37xxx and LPe38xxx series of adapters. The
default reporting string will be "LPe38000".
Link: https://lore.kernel.org/r/20210722221721.74388-2-jsmart2021@gmail.com
Co-developed-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Add the bypass register for the s2f_user0_clk.
Fixes: 80c6b7a0894f ("clk: socfpga: agilex: add clock driver for the Agilex platform")
Cc: stable@vger.kernel.org
Signed-off-by: Kris Chaplin <kris.chaplin@intel.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Link: https://lore.kernel.org/r/20210713144621.605140-3-dinguyen@kernel.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Correct the s2f_user0_mux clock representation.
Fixes: 80c6b7a0894f ("clk: socfpga: agilex: add clock driver for the Agilex platform")
Cc: stable@vger.kernel.org
Signed-off-by: Kris Chaplin <kris.chaplin@intel.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Link: https://lore.kernel.org/r/20210713144621.605140-2-dinguyen@kernel.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
The psi_ref_clk comes from the C2 node of the main_pll and periph_pll,
not the C3.
Fixes: 80c6b7a0894f ("clk: socfpga: agilex: add clock driver for the Agilex platform")
Cc: stable@vger.kernel.org
Signed-off-by: Kris Chaplin <kris.chaplin@intel.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Link: https://lore.kernel.org/r/20210713144621.605140-1-dinguyen@kernel.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
The clk-hi3559a driver uses functions from reset.c so it should
select RESET_HISI to avoid build errors.
Fixes these build errors:
aarch64-linux-ld: drivers/clk/hisilicon/clk-hi3559a.o: in function `hi3559av100_crg_remove':
clk-hi3559a.c:(.text+0x158): undefined reference to `hisi_reset_exit'
aarch64-linux-ld: drivers/clk/hisilicon/clk-hi3559a.o: in function `hi3559av100_crg_probe':
clk-hi3559a.c:(.text+0x1f4): undefined reference to `hisi_reset_init'
aarch64-linux-ld: clk-hi3559a.c:(.text+0x238): undefined reference to `hisi_reset_exit'
Fixes: 6c81966107dc ("clk: hisilicon: Add clock driver for hi3559A SoC")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kernel test robot <lkp@intel.com>
Cc: Dongjiu Geng <gengdongjiu@huawei.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: stable@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: Michael Turquette <mturquette@baylibre.com>
Link: https://lore.kernel.org/r/20210717043159.12566-1-rdunlap@infradead.org
Reviewed-by: Dongjiu Geng <gengdongjiu1@gmail.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Enabling the framebuffer leads to a system hang. Running, as a debug
hack, the store_pan() function in drivers/video/fbdev/core/fbsysfs.c
without taking the console_lock, allows to see the crash backtrace on
the serial line.
~ # echo 0 0 > /sys/class/graphics/fb0/pan
[ 9.719414] Unhandled exception: IPSR = 00000005 LR = fffffff1
[ 9.726937] CPU: 0 PID: 49 Comm: sh Not tainted 5.13.0-rc5 #9
[ 9.733008] Hardware name: STM32 (Device Tree Support)
[ 9.738296] PC is at clk_gate_is_enabled+0x0/0x28
[ 9.743426] LR is at stm32f4_pll_div_set_rate+0xf/0x38
[ 9.748857] pc : [<0011e4be>] lr : [<0011f9e3>] psr: 0100000b
[ 9.755373] sp : 00bc7be0 ip : 00000000 fp : 001f3ac4
[ 9.760812] r10: 002610d0 r9 : 01efe920 r8 : 00540560
[ 9.766269] r7 : 02e7ddb0 r6 : 0173eed8 r5 : 00000000 r4 : 004027c0
[ 9.773081] r3 : 0011e4bf r2 : 02e7ddb0 r1 : 0173eed8 r0 : 1d3267b8
[ 9.779911] xPSR: 0100000b
[ 9.782719] CPU: 0 PID: 49 Comm: sh Not tainted 5.13.0-rc5 #9
[ 9.788791] Hardware name: STM32 (Device Tree Support)
[ 9.794120] [<0000afa1>] (unwind_backtrace) from [<0000a33f>] (show_stack+0xb/0xc)
[ 9.802421] [<0000a33f>] (show_stack) from [<0000a8df>] (__invalid_entry+0x4b/0x4c)
The `pll_num' field in the post_div_data configuration contained a wrong
value which also referenced an uninitialized hardware clock when
clk_register_pll_div() was called.
Fixes: 517633ef630e ("clk: stm32f4: Add post divisor for I2S & SAI PLLs")
Signed-off-by: Dario Binacchi <dariobin@libero.it>
Reviewed-by: Gabriel Fernandez <gabriel.fernandez@st.com>
Link: https://lore.kernel.org/r/20210725160725.10788-1-dariobin@libero.it
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Sometimes kernel is trying to probe Fingerprint MCU (FPMCU) when it
hasn't initialized SPI yet. This can happen because FPMCU is restarted
during system boot and kernel can send message in short window
eg. between sysjump to RW and SPI initialization.
Cc: <stable@vger.kernel.org> # 4.4+
Signed-off-by: Patryk Duda <pdk@semihalf.com>
Link: https://lore.kernel.org/r/20210518140758.29318-1-pdk@semihalf.com
Signed-off-by: Benson Leung <bleung@chromium.org>
|
|
The fast path only updates cursor register what will not cause
any updates in the screen when using PSR2 selective fetch.
The only option that we have is to go through the slow patch that will
do full atomic commit, that will trigger the PSR2 selective fetch
compute and programing calls.
Without this patch is possible to see a mouse movement lag in Gnome
when PSR2 selective fetch is enabled.
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210717011227.204494-3-jose.souza@intel.com
|
|
Without this planes that were added by intel_psr2_sel_fetch_update()
that intersect with pipe damaged area will not
have skl_program_plane() and intel_psr2_program_plane_sel_fetch()
called, causing panel to not be properly updated.
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210717011227.204494-2-jose.souza@intel.com
|
|
The first time it's booted, the modem loads and starts the
IPA-resident microcontroller. Once the microcontroller has
completed its initialization, it notifies the AP it's "ready"
by sending an INIT_COMPLETED response message.
Until it receives that microcontroller message, the AP must ensure
the IPA core clock remains operational. Currently, a "proxy" clock
reference is taken in ipa_uc_config(), dropping it again once the
message is received.
However there could be a long delay between when ipa_config()
completes and when modem actually starts. And because the
microcontroller gets loaded by the modem, there's no need to
get the modem "proxy clock" until the first time it starts.
Create a new function ipa_uc_clock() which takes the "proxy" clock
reference for the microcontroller. Call it when we get remoteproc
SSR notification that the modem is about to start. Keep an
additional flag to record whether this proxy clock reference needs
to be dropped at shutdown time, and issue a warning if we get the
microcontroller message either before the clock reference is taken,
or after it has already been dropped.
Drop the nearby use of "hh" length modifiers, which are no longer
encouraged in the kernel.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Initializing up the IPA-resident microcontroller requires the IPA
clock, and sets up two IPA interrupt handlers, but this does not
require GSI access. The interrupt handlers also require the clock
to be enabled, and require the IPA memory regions to be configured,
but neither requires GSI access. As a result, the microcontroller
can be initialized during the "config" rather than "setup" phase of
IPA initialization.
Initialize the microcontroller in ipa_config() rather than
ipa_setup(), and rename the called function ipa_uc_config().
Do the inverse in ipa_deconfig() rather than ipa_teardown(),
and rename the function for that case ipa_uc_deconfig().
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Initialization of the IPA driver has several phases:
- "init" phase can be done without any access to IPA hardware
- "config" phase requires the IPA hardware to be clocked
- "setup" phase requires the GSI layer to be functional
Currently, initialization for the IPA interrupt handling code occurs
in the setup phase. It requires access to the IPA hardware but does
not need GSI, so it can be moved to the config phase instead.
Call the interrupt configuration function early in ipa_config()
rather than from ipa_setup(). Rename ipa_interrupt_setup() to be
ipa_interrupt_config(), and ipa_interrupt_teardown() to be
ipa_interupt_deconfig(), so their names properly indicate when
they get called.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
IPA-resident memory is one of the most primitive resources that
needs initialization, so call init_mem_config() early in
ipa_config().
This is in preparation for initializing the IPA-resident
microcontroller earlier.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The functions ipa_modem_setup() and ipa_modem_teardown() are trivial
wrappers that call ipa_qmi_setup() and ipa_qmi_teardown(). Just
call the QMI functions directly, and get rid of the wrappers.
Improve the documentation of what setting up QMI does.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The RMNet and IPA drivers both support inline checksum offload now.
So enable it for the TX and RX modem endoints for IPA version 4.5+.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Now that we return when bnxt_open() fails in bnxt_fw_reset_task(),
there is no need to check for 'rc' value again before invoking
bnxt_reenable_sriov().
Fixes: 3958b1da725a ("bnxt_en: fix error path of FW reset")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Somnath Kotur <somnath.kotur@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
I've added commented assertions to record certain properties that
can be assumed to hold in certain places in the IPA code. Convert
these into real WARN_ON() calls so the assertions are actually
checked, using the standard WARN_ON() mechanism.
Where errors can be returned, return an error if a warning is
triggered.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
There are only a few remaining spots that validate IPA code
conditional on whether a symbol is defined at compile time.
The checks are not expensive, so just build them always.
This completes the removal of all CONFIG_VALIDATE/CONFIG_VALIDATION
IPA code.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
All checks in ipa_table_validate_build() are computed at build time,
so build that unconditionally.
In ipa_table_valid() calls to ipa_table_valid_one() are missing the
IPA pointer parameter is missing in (a bug that shows up only when
IPA_VALIDATE is defined). Don't bother checking whether hashed
table memory regions are valid if hashed tables are not supported.
With those things fixed, have these table validation functions built
unconditionally (not dependent on IPA_VALIDATE).
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Stop supporting different sizes for hashed and non-hashed filter or
route tables. Add BUILD_BUG_ON() calls to verify the sizes of the
fields in the filter/route table initialization immediate command
are the same.
Add a check to ipa_cmd_table_valid() to ensure the size of the
memory region being checked fits within the immediate command field
that must hold it.
Remove two Boolean parameters used only for error reporting. This
actually fixes a bug that would only show up if IPA_VALIDATE were
defined. Define ipa_cmd_table_valid() unconditionally (no longer
dependent on IPA_VALIDATE).
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The main desire for having this feature in sja1105 is to support network
stack termination for traffic coming from a VLAN-aware bridge.
For sja1105, offloading the bridge data plane means sending packets
as-is, with the proper VLAN tag, to the chip. The chip will look up its
FDB and forward them to the correct destination port.
But we support bridge data plane offload even for VLAN-unaware bridges,
and the implementation there is different. In fact, VLAN-unaware
bridging is governed by tag_8021q, so it makes sense to have the
.bridge_fwd_offload_add() implementation fully within tag_8021q.
The key difference is that we only support 1 VLAN-aware bridge, but we
support multiple VLAN-unaware bridges. So we need to make sure that the
forwarding domain is not crossed by packets injected from the stack.
For this, we introduce the concept of a tag_8021q TX VLAN for bridge
forwarding offload. As opposed to the regular TX VLANs which contain
only 2 ports (the user port and the CPU port), a bridge data plane TX
VLAN is "multicast" (or "imprecise"): it contains all the ports that are
part of a certain bridge, and the hardware will select where the packet
goes within this "imprecise" forwarding domain.
Each VLAN-unaware bridge has its own "imprecise" TX VLAN, so we make use
of the unique "bridge_num" provided by DSA for the data plane offload.
We use the same 3 bits from the tag_8021q VLAN ID format to encode this
bridge number.
Note that these 3 bit positions have been used before for sub-VLANs in
best-effort VLAN filtering mode. The difference is that for best-effort,
the sub-VLANs were only valid on RX (and it was documented that the
sub-VLAN field needed to be transmitted as zero). Whereas for the bridge
data plane offload, these 3 bits are only valid on TX.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This is already common knowledge by now, but the sja1105 does not have
hardware support for DSA tagging for data plane packets, and tag_8021q
sets up a unique pvid per port, transmitted as VLAN-tagged towards the
CPU, for the source port to be decoded nonetheless.
When the port is part of a VLAN-aware bridge, the pvid committed to
hardware is taken from the bridge and not from tag_8021q, so we need to
work with that the best we can.
Configure the switches to send all packets to the CPU as VLAN-tagged
(even ones that were originally untagged on the wire) and make use of
dsa_untag_bridge_pvid() to get rid of it before we send those packets up
the network stack.
With the classified VLAN used by hardware known to the tagger, we first
peek at the VID in an attempt to figure out if the packet was received
from a VLAN-unaware port (standalone or under a VLAN-unaware bridge),
case in which we can continue to call dsa_8021q_rcv(). If that is not
the case, the packet probably came from a VLAN-aware bridge. So we call
the DSA helper that finds for us a "designated bridge port" - one that
is a member of the VLAN ID from the packet, and is in the proper STP
state - basically these are all checks performed by br_handle_frame() in
the software RX data path.
The bridge will accept the packet as valid even if the source port was
maybe wrong. So it will maybe learn the MAC SA of the packet on the
wrong port, and its software FDB will be out of sync with the hardware
FDB. So replies towards this same MAC DA will not work, because the
bridge will send towards a different netdev.
This is where the bridge data plane offload ("imprecise TX") added by
the next patch comes in handy. The software FDB is wrong, true, but the
hardware FDB isn't, and by offloading the bridge forwarding plane we
have a chance to right a wrong, and have the hardware look up the FDB
for us for the reply packet. So it all cancels out.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
With tag_sja1105.c's only ability being to perform an imprecise RX
procedure and identify whether a packet comes from a VLAN-aware bridge
or not, we have no way to determine whether a packet with VLAN ID 5
comes from, say, br0 or br1. Actually we could, but it would mean that
we need to restrict all VLANs from br0 to be different from all VLANs
from br1, and this includes the default_pvid, which makes a setup with 2
VLAN-aware bridges highly imprectical.
The fact of the matter is that this isn't even that big of a practical
limitation, since even with a single VLAN-aware bridge we can pretty
much enforce forwarding isolation based on the VLAN port membership.
So in the end, tell the user that they need to model their setup using a
single VLAN-aware bridge.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Now that best-effort VLAN filtering is gone and we are left with the
imprecise RX and imprecise TX based in VLAN-aware mode, where the tagger
just guesses the source port based on plausibility of the VLAN ID, 8021q
uppers installed on top of a standalone port, while other ports of that
switch are under a VLAN-aware bridge don't quite "just work".
In fact it could be possible to restrict the VLAN IDs used by the 8021q
uppers to not be shared with VLAN IDs used by that VLAN-aware bridge,
but then the tagger needs to be patched to search for 8021q uppers too,
not just for the "designated bridge port" which will be introduced in a
later patch.
I haven't given a possible implementation full thought, it seems maybe
possible but not worth the effort right now. The only certain thing is
that currently the tagger won't be able to figure out the source port
for these packets because they will come with the VLAN ID of the 8021q
upper and are no longer retagged to a tag_8021q sub-VLAN like the best
effort VLAN filtering code used to do. So just deny these for the
moment.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
With the best_effort_vlan_filtering mode now gone, the driver does not
have 3 operating modes anymore (VLAN-unaware, VLAN-aware and best effort),
but only 2.
The idea is that we will gain support for network stack I/O through a
VLAN-aware bridge, using the data plane offload framework (imprecise RX,
imprecise TX). So the VLAN-aware use case will be more functional.
But standalone ports that are part of the same switch when some other
ports are under a VLAN-aware bridge should work too. Termination on
those should work through the tag_8021q RX VLAN and TX VLAN.
This was not possible using the old logic, because:
- in VLAN-unaware mode, only the tag_8021q VLANs were committed to hw
- in VLAN-aware mode, only the bridge VLANs were committed to hw
- in best-effort VLAN mode, both the tag_8021q and bridge VLANs were
committed to hw
The strategy for the new VLAN-aware mode is to allow the bridge and the
tag_8021q VLANs to coexist in the VLAN table at the same time.
[ yes, we need to make sure that the bridge cannot install a tag_8021q
VLAN, but ]
This means that the save/restore logic introduced by commit ec5ae61076d0
("net: dsa: sja1105: save/restore VLANs using a delta commit method")
does not serve a purpose any longer. We can delete it and restore the
old code that simply adds a VLAN to the VLAN table and calls it a day.
Note that we keep the sja1105_commit_pvid() function from those days,
but adapt it slightly. Ports that are under a VLAN-aware bridge use the
bridge's pvid, ports that are standalone or under a VLAN-unaware bridge
use the tag_8021q pvid, for local termination or VLAN-unaware forwarding.
Now, when the vlan_filtering property is toggled for the bridge, the
pvid of the ports beneath it is the only thing that's changing, we no
longer delete some VLANs and restore others.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The pointer table is being re-assigned with a value that is never
read. The assignment is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
mlx5-updates-2021-07-24
This series aims to reduce coupling in mlx5e, particularly between RX
resources (TIRs, RQTs) and numerous code units that use them.
This refactoring is required for upcoming features, ADQ and TX lag
hashing.
The issue with the current code is that TIRs and RQTs are unmanaged,
different places all over the driver create, destroy, track and
configure them, often in an uncoordinated way. The responsibilities of
different units become vague, leading to a lot of hidden dependencies
between numerous units and tight coupling between them, which is prone
to bugs and hard to maintain.
The result of this refactoring is:
1. Creating a manager for RX resources, that controls their lifecycle
and provides a clear API, which restricts the set of actions that other
units can do.
2. Using object-oriented approach for TIRs, RQTs and RX resource
manager (struct mlx5e_rx_res).
3. Fixing a few bugs and misbehaviors found during the refactoring.
4. Reducing the amount of dependencies, removing hidden dependencies,
making them one-directional and organizing the code in clear abstraction
layers.
5. Explicitly exposing the remaining weird dependencies.
6. Simplifying and organizing code that creates and modifies TIRs and
RQTs.
Saeed Mahameed says:
====================
mlx5 updates 2021-07-24
This series provides some refactoring to mlx5e RX resource management,
it is required for upcoming ADQ and TX lag hashing features.
The first two patches in this series :
net/mlx5e: Prohibit inner indir TIRs in IPoIB
net/mlx5e: Block LRO if firmware asks for tunneled LRO
Were supposed to go to net, but due to dependency and timing they were
included here.
I would appreciate it if you'd apply them to net and mark for -stable.
For more information please see tag log below.
Please pull and let me know if there is any problem.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
linux-can-next-for-5.15-20210725
Marc Kleine-Budde says:
====================
pull-request: can-next 2021-07-25
this is a pull request of 46 patches for net-next/master.
The first 6 patches target the CAN J1939 protocol. One is from
gushengxian, fixing a grammatical error, 5 are by me fixing a checkpatch
warning, make use of the fallthrough pseudo-keyword, and use
consistent variable naming.
The next 3 patches target the rx-offload helper, are by me and improve
the performance and fix the local softirq work pending error, when
napi_schedule() is called from threaded IRQ context.
The next 3 patches are by Vincent Mailhol and me update the CAN
bittiming and transmitter delay compensation, the documentation for
the struct can_tdc is fixed, clear data_bittiming if FD mode is turned
off and a redundant check is removed.
Followed by 4 patches targeting the m_can driver. Faiz Abbas's patches
add support for CAN PHY via the generic phy subsystem. Yang Yingliang
converts the driver to use devm_platform_ioremap_resource_byname().
And a patch by me which removes the unused support for custom bit
timing.
Andy Shevchenko contributes 2 patches for the mcp251xfd driver to
prepare the driver for ACPI support. A patch by me adds support for
shared IRQ handlers.
Zhen Lei contributes 3 patches to convert the esd_usb2, janz-ican3 and
the at91_can driver to make use of the DEVICE_ATTR_RO/RW() macros.
The next 8 patches are by Peng Li and provide general cleanups for the
at91_can driver.
The next 7 patches target the peak driver. Frist 2 cleanup patches by
me for the peak_pci driver, followed by Stephane Grosjean' patch to
print the name and firmware version of the detected hardware. The
peak_usb driver gets a cleanup patch, loopback and one-shot mode and
an upgrading of the bus state change handling in Stephane Grosjean's
patches.
Vincent Mailhol provides 6 cleanup patches for the etas_es58x driver.
In the last 3 patches Angelo Dureghello add support for the mcf5441x
SoC to the flexcan driver.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Use clk_prepare_enable()/clk_disable_unprepare() in preparation for switch
to Common Clock Framework.
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210726140001.24820-5-nikita.shubin@maquefel.me
|
|
Add definition of the AUO B133HAN05.4 13.3" FHD panel and the
B140HAN06.4 14.0" FHD panel.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210726173300.432039-2-bjorn.andersson@linaro.org
|
|
The userspace program could pass any values to the driver through
ioctl() interface. If the driver doesn't check the value of 'pixclock',
it may cause divide error.
Fix this by checking whether 'pixclock' is zero first.
The following log reveals it:
[ 33.396850] divide error: 0000 [#1] PREEMPT SMP KASAN PTI
[ 33.396864] CPU: 5 PID: 11754 Comm: i740 Not tainted 5.14.0-rc2-00513-gac532c9bbcfb-dirty #222
[ 33.396883] RIP: 0010:riva_load_video_mode+0x417/0xf70
[ 33.396969] Call Trace:
[ 33.396973] ? debug_smp_processor_id+0x1c/0x20
[ 33.396984] ? tick_nohz_tick_stopped+0x1a/0x90
[ 33.396996] ? rivafb_copyarea+0x3c0/0x3c0
[ 33.397003] ? wake_up_klogd.part.0+0x99/0xd0
[ 33.397014] ? vprintk_emit+0x110/0x4b0
[ 33.397024] ? vprintk_default+0x26/0x30
[ 33.397033] ? vprintk+0x9c/0x1f0
[ 33.397041] ? printk+0xba/0xed
[ 33.397054] ? record_print_text.cold+0x16/0x16
[ 33.397063] ? __kasan_check_read+0x11/0x20
[ 33.397074] ? profile_tick+0xc0/0x100
[ 33.397084] ? __sanitizer_cov_trace_const_cmp4+0x24/0x80
[ 33.397094] ? riva_set_rop_solid+0x2a0/0x2a0
[ 33.397102] rivafb_set_par+0xbe/0x610
[ 33.397111] ? riva_set_rop_solid+0x2a0/0x2a0
[ 33.397119] fb_set_var+0x5bf/0xeb0
[ 33.397127] ? fb_blank+0x1a0/0x1a0
[ 33.397134] ? lock_acquire+0x1ef/0x530
[ 33.397143] ? lock_release+0x810/0x810
[ 33.397151] ? lock_is_held_type+0x100/0x140
[ 33.397159] ? ___might_sleep+0x1ee/0x2d0
[ 33.397170] ? __mutex_lock+0x620/0x1190
[ 33.397180] ? trace_hardirqs_on+0x6a/0x1c0
[ 33.397190] do_fb_ioctl+0x31e/0x700
Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1627293835-17441-4-git-send-email-zheyuma97@gmail.com
|
|
The userspace program could pass any values to the driver through
ioctl() interface. if the driver doesn't check the value of 'pixclock',
it may cause divide error because the value of 'lineclock' and
'frameclock' will be zero.
Fix this by checking whether 'pixclock' is zero in kyrofb_check_var().
The following log reveals it:
[ 103.073930] divide error: 0000 [#1] PREEMPT SMP KASAN PTI
[ 103.073942] CPU: 4 PID: 12483 Comm: syz-executor Not tainted 5.14.0-rc2-00478-g2734d6c1b1a0-dirty #118
[ 103.073959] RIP: 0010:kyrofb_set_par+0x316/0xc80
[ 103.074045] Call Trace:
[ 103.074048] ? ___might_sleep+0x1ee/0x2d0
[ 103.074060] ? kyrofb_ioctl+0x330/0x330
[ 103.074069] fb_set_var+0x5bf/0xeb0
[ 103.074078] ? fb_blank+0x1a0/0x1a0
[ 103.074085] ? lock_acquire+0x3bd/0x530
[ 103.074094] ? lock_release+0x810/0x810
[ 103.074103] ? ___might_sleep+0x1ee/0x2d0
[ 103.074114] ? __mutex_lock+0x620/0x1190
[ 103.074126] ? trace_hardirqs_on+0x6a/0x1c0
[ 103.074137] do_fb_ioctl+0x31e/0x700
[ 103.074144] ? fb_getput_cmap+0x280/0x280
[ 103.074152] ? rcu_read_lock_sched_held+0x11/0x80
[ 103.074162] ? rcu_read_lock_sched_held+0x11/0x80
[ 103.074171] ? __sanitizer_cov_trace_switch+0x67/0xf0
[ 103.074181] ? __sanitizer_cov_trace_const_cmp2+0x20/0x80
[ 103.074191] ? do_vfs_ioctl+0x14b/0x16c0
[ 103.074199] ? vfs_fileattr_set+0xb60/0xb60
[ 103.074207] ? rcu_read_lock_sched_held+0x11/0x80
[ 103.074216] ? lock_release+0x483/0x810
[ 103.074224] ? __fget_files+0x217/0x3d0
[ 103.074234] ? __fget_files+0x239/0x3d0
[ 103.074243] ? do_fb_ioctl+0x700/0x700
[ 103.074250] fb_ioctl+0xe6/0x130
Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1627293835-17441-3-git-send-email-zheyuma97@gmail.com
|
|
The userspace program could pass any values to the driver through
ioctl() interface. If the driver doesn't check the value of 'pixclock',
it may cause divide error.
Fix this by checking whether 'pixclock' is zero first.
The following log reveals it:
[ 43.861711] divide error: 0000 [#1] PREEMPT SMP KASAN PTI
[ 43.861737] CPU: 2 PID: 11764 Comm: i740 Not tainted 5.14.0-rc2-00513-gac532c9bbcfb-dirty #224
[ 43.861756] RIP: 0010:asiliantfb_check_var+0x4e/0x730
[ 43.861843] Call Trace:
[ 43.861848] ? asiliantfb_remove+0x190/0x190
[ 43.861858] fb_set_var+0x2e4/0xeb0
[ 43.861866] ? fb_blank+0x1a0/0x1a0
[ 43.861873] ? lock_acquire+0x1ef/0x530
[ 43.861884] ? lock_release+0x810/0x810
[ 43.861892] ? lock_is_held_type+0x100/0x140
[ 43.861903] ? ___might_sleep+0x1ee/0x2d0
[ 43.861914] ? __mutex_lock+0x620/0x1190
[ 43.861921] ? do_fb_ioctl+0x313/0x700
[ 43.861929] ? mutex_lock_io_nested+0xfa0/0xfa0
[ 43.861936] ? __this_cpu_preempt_check+0x1d/0x30
[ 43.861944] ? _raw_spin_unlock_irqrestore+0x46/0x60
[ 43.861952] ? lockdep_hardirqs_on+0x59/0x100
[ 43.861959] ? _raw_spin_unlock_irqrestore+0x46/0x60
[ 43.861967] ? trace_hardirqs_on+0x6a/0x1c0
[ 43.861978] do_fb_ioctl+0x31e/0x700
Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1627293835-17441-2-git-send-email-zheyuma97@gmail.com
|
|
The spi_imx->spi_bus_clk may be uninitialized and thus also zero in
mx51_ecspi_prepare_message(), which would lead to division by zero
in kernel. Since bitbang .setup_transfer callback which initializes
the spi_imx->spi_bus_clk is called after bitbang prepare_message
callback, iterate over all the transfers in spi_message, find the
one with lowest bus frequency, and use that bus frequency for the
delay calculation.
Note that it is not possible to move this CONFIGREG delay back into
the .setup_transfer callback, because that is invoked too late, after
the GPIO chipselects were already configured.
Fixes: 135cbd378eab ("spi: imx: mx51-ecspi: Reinstate low-speed CONFIGREG delay")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210726100102.5188-1-marex@denx.de
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The ASMedia ASM1062 SATA controller advertises Max_Payload_Size_Supported
of 512, but in fact it cannot handle incoming TLPs with payload size of
512.
We discovered this issue on PCIe controllers capable of MPS = 512 (Aardvark
and DesignWare), where the issue presents itself as an External Abort.
Bjorn Helgaas says:
Probably ASM1062 reports a Malformed TLP error when it receives a data
payload of 512 bytes, and Aardvark, DesignWare, etc convert this to an
arm64 External Abort. [1]
To avoid this problem, limit the ASM1062 Max Payload Size Supported to 256
bytes, so we set the Max Payload Size of devices that may send TLPs to the
ASM1062 to 256 or less.
[1] https://lore.kernel.org/linux-pci/20210601170907.GA1949035@bjorn-Precision-5520/
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212695
Link: https://lore.kernel.org/r/20210624171418.27194-2-kabel@kernel.org
Reported-by: Rötti <espressobinboardarmbiantempmailaddress@posteo.de>
Signed-off-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Krzysztof Wilczyński <kw@linux.com>
Reviewed-by: Pali Rohár <pali@kernel.org>
Cc: stable@vger.kernel.org
|
|
pci_device_add() calls HEADER fixups after pci_configure_device(), which
configures Max Payload Size.
Convert MPS-related fixups to EARLY fixups so pci_configure_mps() takes
them into account.
Fixes: 27d868b5e6cfa ("PCI: Set MPS to match upstream bridge")
Link: https://lore.kernel.org/r/20210624171418.27194-1-kabel@kernel.org
Signed-off-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org
|
|
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210618151657.65305-7-andriy.shevchenko@linux.intel.com
|
|
Switch to devm_bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210618151657.65305-6-andriy.shevchenko@linux.intel.com
|
|
Switch to devm_bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210618151657.65305-5-andriy.shevchenko@linux.intel.com
|
|
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210618151657.65305-4-andriy.shevchenko@linux.intel.com
|
|
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210618151657.65305-3-andriy.shevchenko@linux.intel.com
|
|
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210618151657.65305-2-andriy.shevchenko@linux.intel.com
|
|
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210618151657.65305-1-andriy.shevchenko@linux.intel.com
|
|
One of the previous commits introduced a dedicated object for a TIR.
kTLS code creates a TIR per connection using the low-level mlx5_core
API. This commit converts it to the new mlx5e_tir API.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
|
This commit moves the responsibility of keeping the RSS configuration
for different traffic types to en/rx_res.{c,h}, hiding the
implementation details behind the new getters, and abandons all usage of
struct mlx5e_tirc_config, which is no longer useful and superseded by
struct mlx5e_rss_params_traffic_type.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
|
Code related to TIR is now encapsulated into a dedicated object and put
into new files en/tir.{c,h}. All usages are converted.
The Builder pattern is used to initialize a TIR. It allows to create a
multitude of different configurations, turning on and off some specific
features in different combinations, without having long parameter lists,
initializers per usage and repeating code in initializers.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
Reviewed-by: Maor Dickman <maord@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
|
This commit introduces a new struct to store RSS hash parameters: hash
function and hash key. The existing usages are changed to use the new
struct.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
|
In order to drop a dependency to mdev and make the function more
universal, stop passing mdev to mlx5e_build_indir_tir_ctx_common() and
pass transport domain directly instead. It also prepares this function
to be used in other contexts that need a custom transport domain, such
as hairpin.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
|
In order to reduce the list of parameters and to define clearer
responsibility for mlx5e_build_indir_tir_ctx_common(), stop passing
lro_param and instead call mlx5e_build_tir_ctx_lro() directly where
needed.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
|
The functions that build TIR context for TIR create and modify commands
used to depend on struct mlx5e_priv and fetch some values directly from
different places. It increased coupling of code and the chance of weird
misbehavior due to hidden complex dependencies.
As the first step, this commit removes the priv parameter from these
functions. Instead, the necessary values are passed directly.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
James Smart
Dinh Nguyen
Randy Dunlap
Dario Binacchi
Patryk Duda
José Roberto de Souza
Alex Elder
Somnath Kotur
Vladimir Oltean
Colin Ian King
David S. Miller
Alexander Sverdlin
Bjorn Andersson
Zheyu Ma
Marek Vasut
Marek Behún
Andy Shevchenko
Maxim Mikityanskiy