BugLink: https://bugs.launchpad.net/bugs/2072591
In Tegra PCIe RP <-> Tegra EP case, PCIe AER surprise down error and PCIe
EDMA deinit calls are causing deadlock in the host. Following is the
sequence which resulted in deadlock.
- EP is down, so PRSNT# signal is deasserted.
- RP received PRSNT deassert interrupt.
- RP driver is removing endpoint device. As part of clean up dev->mutex
is acquired.
- tegra_pcie_edma_deinit() is waiting(synchronize_irq()) for any existing
EDMA interrupt handler to return.
synchronize_irq+0x84/0xc0
tegra_pcie_edma_deinit+0x1b0/0x360
endpoints_core_deinit+0x2f8/0x9b0 [nvscic2c_pcie_epc]
pci_device_remove+0x48/0xf0
device_release_driver_internal+0x11c/0x1f0
device_release_driver+0x28/0x40
pci_stop_bus_device+0x84/0xe0
pci_stop_bus_device+0x3c/0xe0
pci_stop_root_bus+0x4c/0x80
dw_pcie_host_deinit+0x2c/0x100
tegra_pcie_deinit_controller+0x34/0x70
tegra_pcie_prsnt_irq+0x5c/0x120
irq_thread_fn+0x30
- At the same time, RP received surprise down AER error.
- AER handler is also trying to acquire same dev->mutex_lock.
- However, EDMA & AER share same irq line. At step-4, synchronize_irq()
stuck waiting for AER handler to return causing a dead lock.
__rt_mutex_slowlock+0xc4/0x150
rt_mutex_slowlock_locked+0xac/0x250
rt_mutex_slowlock+0x84/0xe0
__rt_mutex_lock_state+0x60/0x90
_mutex_lock_blk_flush+0x54/0x80
_mutex_lock+0x24/0x30
report_error_detected+0x30/0x120
report_frozen_detected+0x2c/0x40
pci_walk_bus+0x68/0xc0
pcie_do_recovery+0x14c/0x1d0
aer_process_err_devices+0xec/0x110
aer_isr+0x154/0x1d0
irq_thread_fn+0x30/0xa0
irq_thread+0x150/0x260
kthread+0x17c/0x1a0
ret_from_fork+0x10/0x18
http://nvbugs/3540800
Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Tested-by: Abhilash G <abhilashg@nvidia.com>
Reviewed-by: Abhilash G <abhilashg@nvidia.com>
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Acked-by: Jacob Martin <jacob.martin@canonical.com>
Acked-by: Noah Wager <noah.wager@canonical.com>
Signed-off-by: Noah Wager <noah.wager@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2072591
When Tegra234 is operating in the endpoint mode with L1.2 enabled, PCIe
link goes down during L1.2 exit. This is because Tegra234 is powering up
UPHY PLL immediately without making sure that the REFCLK is stable.
This is causing UPHY PLL to not lock to the correct frequency and leading
to link going down. There is no hardware fix for this, hence do not
advertise the L1.2 capability in the endpoint mode.
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Reviewed-by: Nagarjuna Kristam <nkristam@nvidia.com>
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
Tested-by: Nagarjuna Kristam <nkristam@nvidia.com>
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Acked-by: Jacob Martin <jacob.martin@canonical.com>
Acked-by: Noah Wager <noah.wager@canonical.com>
Signed-off-by: Noah Wager <noah.wager@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2072591
On surprise down, LTSSM state transits from L0 -> Recovery.RcvrLock ->
Recovery.RcvrSpeed -> Gen1 Recovery.RcvrLock -> Detect. Recovery.RcvrLock
and Recovery.RcvrSpeed transit times are 24 msec and 48 msec respectively.
So, the total time taken to transit from L0 to detect state is ~96 msec.
Hence, increase the poll time to 120 msec.
Disable the LTSSM state after it transits to detect to avoid LTSSM
toggling between polling and detect states.
tegra_pcie_dw_pme_turnoff() function is called in non-atomic context
only, so use the non-atomic poll function.
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Reviewed-by: Nagarjuna Kristam <nkristam@nvidia.com>
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
Tested-by: Nagarjuna Kristam <nkristam@nvidia.com>
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Acked-by: Jacob Martin <jacob.martin@canonical.com>
Acked-by: Noah Wager <noah.wager@canonical.com>
Signed-off-by: Noah Wager <noah.wager@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2072591
As per PCIe CEM spec rev 4.0 ver 1.0 sec 2.3, the PCIe endpoint device
should be in D3 state to assert wake# pin. This takes precedence over PCI
Express Base r4.0 v1.0 September 27-2017, 5.2 Link State Power Management
which states that the device can be put into D0 state before taking the
link to L2 state. So, to enable the wake functionality for endpoints, do
not force the devices to D0 state before taking the link to L2 state.
There is no functional issue with the endpoints where the link doesn't go
into L2 state (the reason why the earlier change was made in the first
place) as the root port proceeds with the usual flow post PME timeout.
Fixes: 56e15a238d ("PCI: tegra: Add Tegra194 PCIe support")
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Reviewed-by: Nagarjuna Kristam <nkristam@nvidia.com>
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
Tested-by: Nagarjuna Kristam <nkristam@nvidia.com>
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Acked-by: Jacob Martin <jacob.martin@canonical.com>
Acked-by: Noah Wager <noah.wager@canonical.com>
Signed-off-by: Noah Wager <noah.wager@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2072591
Currently, the default setting is that CLKREQ signal of a Root Port
is internally overridden to '0' to enable REFCLK to flow out to the slot.
It is observed that one of the PCIe switches (case in point Broadcom PCIe
Gen4 switch) is propagating the CLKREQ signal of the root port to the
downstream side of the switch and expecting the endpoints to pull it low
so that it (PCIe switch) can give out the REFCLK although the Switch as
such doesn't support CLK-PM or ASPM-L1SS. So, as a workaround, this patch
drives the CLKREQ of the Root Port itself low to avoid link up issues
between PCIe switch downstream port and endpoints. This is not a wrong
thing to do after all the CLKREQ is anyway being overridden to '0'
internally and now it is just that the same is being propagated outside
also.
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
Reviewed-by: Nagarjuna Kristam <nkristam@nvidia.com>
Tested-by: Nagarjuna Kristam <nkristam@nvidia.com>
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Acked-by: Jacob Martin <jacob.martin@canonical.com>
Acked-by: Noah Wager <noah.wager@canonical.com>
Signed-off-by: Noah Wager <noah.wager@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2114239
commit 3708acbd5f169ebafe1faa519cb28adc56295546 upstream.
In commit 4284c88fff ("PCI: designware-ep: Allow pci_epc_set_bar() update
inbound map address") set_bar() was modified to support dynamically
changing the backing physical address of a BAR that was already configured.
This means that set_bar() can be called twice, without ever calling
clear_bar() (as calling clear_bar() would clear the BAR's PCI address
assigned by the host).
This can only be done if the new BAR size/flags does not differ from the
existing BAR configuration. Add these missing checks.
If we allow set_bar() to set e.g. a new BAR size that differs from the
existing BAR size, the new address translation range will be smaller than
the BAR size already determined by the host, which would mean that a read
past the new BAR size would pass the iATU untranslated, which could allow
the host to read memory not belonging to the new struct pci_epf_bar.
While at it, add comments which clarifies the support for dynamically
changing the physical address of a BAR. (Which was also missing.)
Fixes: 4284c88fff ("PCI: designware-ep: Allow pci_epc_set_bar() update inbound map address")
Link: https://lore.kernel.org/r/20241213143301.4158431-10-cassel@kernel.org
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Noah Wager <noah.wager@canonical.com>
Signed-off-by: Mehmet Basaran <mehmet.basaran@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2114239
commit 33a6938e0c3373f2d11f92d098f337668cd64fdd upstream.
The "DesignWare Cores PCI Express Controller Register Descriptions,
Version 4.60a", section "1.21.70 IATU_LWR_TARGET_ADDR_OFF_INBOUND_i",
fields LWR_TARGET_RW and LWR_TARGET_HW both state that:
"Field size depends on log2(BAR_MASK+1) in BAR match mode."
I.e. only the upper bits are writable, and the number of writable bits is
dependent on the configured BAR_MASK.
If we do not write the BAR_MASK before writing the iATU registers, we are
relying the reset value of the BAR_MASK being larger than the requested
BAR size (which is supplied in the struct pci_epf_bar which is passed to
pci_epc_set_bar()). The reset value of the BAR_MASK is SoC dependent.
Thus, if the struct pci_epf_bar requests a BAR size that is larger than the
reset value of the BAR_MASK, the iATU will try to write to read-only bits,
which will cause the iATU to end up redirecting to a physical address that
is different from the address that was intended.
Thus, we should always write the iATU registers after writing the BAR_MASK.
Fixes: f8aed6ec62 ("PCI: dwc: designware: Add EP mode support")
Link: https://lore.kernel.org/r/20241213143301.4158431-9-cassel@kernel.org
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Noah Wager <noah.wager@canonical.com>
Signed-off-by: Mehmet Basaran <mehmet.basaran@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2111953
[ Upstream commit 1390a33b3d04fdf6ba4e3e7082107a12027fc188 ]
On Microchip PolarFire SoC the PCIe Root Port can be behind one of three
general purpose Fabric Interface Controller (FIC) buses that encapsulates
an AXI-S bus. Depending on which FIC(s) the Root Port is connected through
to CPU space, and what address translation is done by that FIC, the Root
Port driver's inbound address translation may vary.
For all current supported designs and all future expected designs, inbound
address translation done by a FIC on PolarFire SoC varies depending on
whether PolarFire SoC is operating in coherent DMA mode or noncoherent DMA
mode.
The setup of the outbound address translation tables in the Root Port
driver only needs to handle these two cases.
Setup the inbound address translation tables to one of two address
translations, depending on whether the Root Port is being used with
coherent DMA or noncoherent DMA.
Link: https://lore.kernel.org/r/20241011140043.1250030-3-daire.mcnamara@microchip.com
Fixes: 6f15a9c9f9 ("PCI: microchip: Add Microchip PolarFire PCIe controller driver")
Signed-off-by: Daire McNamara <daire.mcnamara@microchip.com>
[bhelgaas: adapt for ac7f53b7e728 ("PCI: microchip: Add support for using
either Root Port 1 or 2")]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[diewald: remove pcie_setup_inbound_address_translation() since it is
neither used nor exported to avoid build warning]
Signed-off-by: Manuel Diewald <manuel.diewald@canonical.com>
Signed-off-by: Mehmet Basaran <mehmet.basaran@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2111953
[ Upstream commit ac7f53b7e7283fee35ad12de8359f20989a47eb5 ]
The PCI host controller on PolarFire SoC has multiple Root Port instances,
each with their own bridge and ctrl address spaces. The original binding
has an "apb" register region, and it is expected to be set to the base
address of the Root Complex register space. Some defines in the Linux
driver were used to compute the addresses of the bridge and ctrl address
ranges corresponding to Root Port instance 1. Some customers want to use
Root Port instance 2 however, which requires changing the defines in the
driver, which is clearly not a portable solution.
The binding has been changed from a single register region to a pair,
corresponding to the bridge and ctrl regions respectively, so modify the
driver to read these regions directly from the devicetree rather than
compute them from the base address of the abp region.
To maintain backwards compatibility with the existing binding, the driver
retains code to handle the "abp" reg and computes the base address of the
bridge and ctrl regions using the defines if it is present. reg-names has
always been a required property, so this is safe to do.
Link: https://lore.kernel.org/r/20241107-surrender-brisket-287d563a5de1@spud
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
[bhelgaas: Capitalize PCIe spec terms]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Stable-dep-of: 1390a33b3d04 ("PCI: microchip: Set inbound address translation for coherent or non-coherent mode")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Manuel Diewald <manuel.diewald@canonical.com>
Signed-off-by: Mehmet Basaran <mehmet.basaran@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2111953
[ Upstream commit 2d2da5a4c1b4509f6f7e5a8db015cd420144beb4 ]
The rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region()
macro to request a needed resource. A string variable that lives on the
stack is then used to store a dynamically computed resource name, which
is then passed on as one of the macro arguments. This can lead to
undefined behavior.
Depending on the current contents of the memory, the manifestations of
errors may vary. One possible output may be as follows:
$ cat /proc/iomem
30000000-37ffffff :
38000000-3fffffff :
Sometimes, garbage may appear after the colon.
In very rare cases, if no NULL-terminator is found in memory, the system
might crash because the string iterator will overrun which can lead to
access of unmapped memory above the stack.
Thus, fix this by replacing outbound_name with the name of the previously
requested resource. With the changes applied, the output will be as
follows:
$ cat /proc/iomem
30000000-37ffffff : memory2
38000000-3fffffff : memory3
Fixes: 2a6d0d63d9 ("PCI: rcar: Add endpoint mode support")
Link: https://lore.kernel.org/r/tencent_DBDCC19D60F361119E76919ADAB25EC13C06@qq.com
Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: King Dix <kingdix10@qq.com>
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
CVE-2025-21804
Signed-off-by: Manuel Diewald <manuel.diewald@canonical.com>
Signed-off-by: Mehmet Basaran <mehmet.basaran@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2102266
[ Upstream commit f24c9bfcd423e2b2bb0d198456412f614ec2030a ]
The vmd driver creates a "domain" symlink in sysfs for each VMD bridge.
Previously this symlink was created after pci_bus_add_devices() added
devices below the VMD bridge and emitted udev events to announce them to
userspace.
This led to a race between userspace consumers of the udev events and the
kernel creation of the symlink. One such consumer is mdadm, which
assembles block devices into a RAID array, and for devices below a VMD
bridge, mdadm depends on the "domain" symlink.
If mdadm loses the race, it may be unable to assemble a RAID array, which
may cause a boot failure or other issues, with complaints like this:
(udev-worker)[2149]: nvme1n1: '/sbin/mdadm -I /dev/nvme1n1'(err) 'mdadm: Unable to get real path for '/sys/bus/pci/drivers/vmd/0000:c7:00.5/domain/device''
(udev-worker)[2149]: nvme1n1: '/sbin/mdadm -I /dev/nvme1n1'(err) 'mdadm: /dev/nvme1n1 is not attached to Intel(R) RAID controller.'
(udev-worker)[2149]: nvme1n1: '/sbin/mdadm -I /dev/nvme1n1'(err) 'mdadm: No OROM/EFI properties for /dev/nvme1n1'
(udev-worker)[2149]: nvme1n1: '/sbin/mdadm -I /dev/nvme1n1'(err) 'mdadm: no RAID superblock on /dev/nvme1n1.'
(udev-worker)[2149]: nvme1n1: Process '/sbin/mdadm -I /dev/nvme1n1' failed with exit code 1.
This symptom prevents the OS from booting successfully.
After a NVMe disk is probed/added by the nvme driver, udevd invokes mdadm
to detect if there is a mdraid associated with this NVMe disk, and mdadm
determines if a NVMe device is connected to a particular VMD domain by
checking the "domain" symlink. For example:
Thread A Thread B Thread mdadm
vmd_enable_domain
pci_bus_add_devices
__driver_probe_device
...
work_on_cpu
schedule_work_on
: wakeup Thread B
nvme_probe
: wakeup scan_work
to scan nvme disk
and add nvme disk
then wakeup udevd
: udevd executes
mdadm command
flush_work main
: wait for nvme_probe done ...
__driver_probe_device find_driver_devices
: probe next nvme device : 1) Detect domain symlink
... 2) Find domain symlink
... from vmd sysfs
... 3) Domain symlink not
... created yet; failed
sysfs_create_link
: create domain symlink
Create the VMD "domain" symlink before invoking pci_bus_add_devices() to
avoid this race.
Suggested-by: Adrian Huang <ahuang12@lenovo.com>
Link: https://lore.kernel.org/linux-pci/20240605124844.24293-1-sjiwei@163.com
Signed-off-by: Jiwei Sun <sunjw10@lenovo.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Nirmal Patel <nirmal.patel@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[koichiroden: note that due to the Ubuntu SAUCE (which did not reach upstream):
e2b1afd8f9 ("UBUNTU: SAUCE: PCI: vmd: guard device addition and removal"),
sysfs_create_link() now added into the critical section]
Signed-off-by: Koichiro Den <koichiro.den@canonical.com>
Signed-off-by: Mehmet Basaran <mehmet.basaran@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2101915
commit 64f093c4d99d797b68b407a9d8767aadc3e3ea7a upstream.
The Rockchip PCIe endpoint controller handles PCIe transfers addresses
by masking the lower bits of the programmed PCI address and using the
same number of lower bits masked from the CPU address space used for the
mapping. For a PCI mapping of <size> bytes starting from <pci_addr>,
the number of bits masked is the number of address bits changing in the
address range [pci_addr..pci_addr + size - 1].
However, rockchip_pcie_prog_ep_ob_atu() calculates num_pass_bits only
using the size of the mapping, resulting in an incorrect number of mask
bits depending on the value of the PCI address to map.
Fix this by introducing the helper function
rockchip_pcie_ep_ob_atu_num_bits() to correctly calculate the number of
mask bits to use to program the address translation unit. The number of
mask bits is calculated depending on both the PCI address and size of
the mapping, and clamped between 8 and 20 using the macros
ROCKCHIP_PCIE_AT_MIN_NUM_BITS and ROCKCHIP_PCIE_AT_MAX_NUM_BITS. As
defined in the Rockchip RK3399 TRM V1.3 Part2, Sections 17.5.5.1.1 and
17.6.8.2.1, this clamping is necessary because:
1) The lower 8 bits of the PCI address to be mapped by the outbound
region are ignored. So a minimum of 8 address bits are needed and
imply that the PCI address must be aligned to 256.
2) The outbound memory regions are 1MB in size. So while we can specify
up to 63-bits for the PCI address (num_bits filed uses bits 0 to 5 of
the outbound address region 0 register), we must limit the number of
valid address bits to 20 to match the memory window maximum size (1
<< 20 = 1MB).
Fixes: cf590b0783 ("PCI: rockchip: Add EP driver for Rockchip PCIe controller")
Link: https://lore.kernel.org/r/20241017015849.190271-2-dlemoal@kernel.org
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Koichiro Den <koichiro.den@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2101915
commit 5a938ed9481b0c06cb97aec45e722a80568256fd upstream.
commit 23284ad677 ("PCI: keystone: Add support for PCIe EP in AM654x
Platforms") introduced configuring "enum dw_pcie_device_mode" as part of
device data ("struct ks_pcie_of_data"). However it failed to set the
mode for "ti,keystone-pcie" compatible.
Since the mode defaults to "DW_PCIE_UNKNOWN_TYPE", the following error
message is displayed for the v3.65a controller:
"INVALID device type 0"
Despite the driver probing successfully, the controller may not be
functional in the Root Complex mode of operation.
So, set the mode as Root Complex for "ti,keystone-pcie" compatible to
fix this.
Fixes: 23284ad677 ("PCI: keystone: Add support for PCIe EP in AM654x Platforms")
Link: https://lore.kernel.org/r/20240524105714.191642-2-s-vadapalli@ti.com
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
[kwilczynski: commit log, added tag for stable releases]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Koichiro Den <koichiro.den@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2101915
[ Upstream commit 22a9120479a40a56c13c5e473a0100fad2e017c0 ]
According to Section 2.2 of the PCI Express Card Electromechanical
Specification (Revision 5.1), in order to ensure that the power and the
reference clock are stable, PERST# has to be deasserted after a delay of
100 milliseconds (TPVPERL).
Currently, it is being assumed that the power is already stable, which
is not necessarily true.
Hence, change the delay to PCIE_T_PVPERL_MS to guarantee that power and
reference clock are stable.
Fixes: f3e25911a4 ("PCI: j721e: Add TI J721E PCIe driver")
Fixes: f96b69713733 ("PCI: j721e: Use T_PERST_CLK_US macro")
Link: https://lore.kernel.org/r/20241104074420.1862932-1-s-vadapalli@ti.com
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Koichiro Den <koichiro.den@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Vidya Sagar
Nagarjuna Kristam
Manikanta Maddireddy
Niklas Cassel
Daire McNamara
Conor Dooley
Richard Zhu
King Dix
Jiwei Sun
Jian-Hong Pan
Nirmal Patel
devi priya
Damien Le Moal
Kishon Vijay Abraham I
Siddharth Vadapalli
Théo Lebrun
Thomas Richard