Base address of CE ring is defined as u32, currently this works
because coherent DMA mask configured as 32 bit:
#define ATH11K_PCI_COHERENT_DMA_MASK 32
However this mask could be changed once firmware bugs are fixed
to fully support 36 bit DMA addressing. So to protect against any
future changes to the DMA mask, change the type of the fields that
are dependent upon it.
This is found during code review. Compile tested only.
Fixes: d5c65159f2 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://msgid.link/20240524021558.34452-1-quic_bqiang@quicinc.com
Currently when ath12k QMI logging is enabled, messages such as the
following can be logged:
ath12k_pci 0000:03:00.0: devmem [0] start ox113000 size 20480
Replace ox% with 0x% to get a proper hex address prefix:
ath12k_pci 0000:03:00.0: devmem [0] start 0x113000 size 20480
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://msgid.link/20240523-ox-v1-1-112ae7350059@quicinc.com
This PR fixes two unaddressed review comments for the HMAC encryption
patch set. They are cosmetic but we are better off, if such unnecessary
glitches do not exist in the release.
The priority part of this PR is enabling the HMAC encryption by default
only on x86-64 because that is the only sufficiently tested arch.
Finally, there is a bug fix for SPI transfer buffer allocation, which
did not take into account the SPI header size.
BR, Jarkko
-----BEGIN PGP SIGNATURE-----
iJYEABYKAD4WIQRE6pSOnaBC00OEHEIaerohdGur0gUCZlWxXCAcamFya2tvLnNh
a2tpbmVuQGxpbnV4LmludGVsLmNvbQAKCRAaerohdGur0vnzAQDTWJu9wf+fnvQR
vJmVJWWkuQfJkXvg2CjjbjrXmd0y+QD6A4zCe0BWxfHiSseduiQ8cdGcdsqjd+zR
nHPPtdvmHgA=
=dHg0
-----END PGP SIGNATURE-----
Merge tag 'tpmdd-next-6.10-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd
Pull tpm fixes from Jarkko Sakkinen:
"This fixes two unaddressed review comments for the HMAC encryption
patch set. They are cosmetic but we are better off, if such
unnecessary glitches do not exist in the release.
The important part is enabling the HMAC encryption by default only on
x86-64 because that is the only sufficiently tested arch.
Finally, there is a bug fix for SPI transfer buffer allocation, which
did not take into account the SPI header size"
* tag 'tpmdd-next-6.10-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd:
tpm: Enable TCG_TPM2_HMAC by default only for X86_64
tpm: Rename TPM2_OA_TMPL to TPM2_OA_NULL_KEY and make it local
tpm: Open code tpm_buf_parameters()
tpm_tis_spi: Account for SPI header when allocating TPM SPI xfer buffer
There are two MQS instances on the i.MX95 platform.
The definition of bit positions in the control register are
different. In order to support these MQS modules, define
two compatible strings to distinguish them.
Define different soc data according to compatible strings
On i.MX95 one instance in nect-mix is supported by this
commit, another instance in always-on-mix is not supported,
which depends on System Manager function readiness.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://msgid.link/r/1716347305-18457-3-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There are two MQS instances on the i.MX95 platform.
The definition of bit positions in the control register are
different. In order to support these MQS modules, define
two compatible strings to distinguish them.
As one instance is in the always-on domain, another is in the
net controller domain, so the compatible strings are
"fsl,imx95-aonmix-mqs", "fsl,imx95-netcmix-mqs".
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://msgid.link/r/1716347305-18457-2-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
- uprobes: prevent mutex_lock() under rcu_read_lock(). Recent changes moves
uprobe_cpu_buffer preparation which involves mutex_lock(), under
__uprobe_trace_func() which is called inside rcu_read_lock(). Fix it
by moving uprobe_cpu_buffer preparation outside of __uprobe_trace_func().
- kprobe-events: Fix to handle the error case of btf_find_struct_member().
-----BEGIN PGP SIGNATURE-----
iQFPBAABCgA5FiEEh7BulGwFlgAOi5DV2/sHvwUrPxsFAmZUglsbHG1hc2FtaS5o
aXJhbWF0c3VAZ21haWwuY29tAAoJENv7B78FKz8bg/gH/3Y3dhxj8Wv16Wb8U4kA
DpYjXplo1y28Kp+hAgGF+T3PTR8KGxD60PuzeKVR7yUL5pLpTWrl1RUPGVwE2NTT
Hmat5TlHLWZYjkO2ySYiyeYgcdVh9gXcO77zMmhUHR7FvMy/1Krr+t7NYbvH5LXj
VWq6xKIVZi2o1e7DbMgBdR7T8O3Iz/JWmAWgZUiIiP9YX1cGsZkleadZaAl3Y6Oh
L0/FAwh/vNtR7gAadLA8OVZW9QBu+WF978VucgErNHMCgvEouxgtQDbsluE+PVhD
+aEcvELCG+3ZLDlwCmfSOX2+7jzy9FKbzjnEVQXIpYWjF3Ii0W5ZSFMQVK+ZeBGN
9vQ=
=Kwsv
-----END PGP SIGNATURE-----
Merge tag 'probes-fixes-v6.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
Pull probes fixes from Masami Hiramatsu:
- uprobes: prevent mutex_lock() under rcu_read_lock().
Recent changes moved uprobe_cpu_buffer preparation which involves
mutex_lock(), under __uprobe_trace_func() which is called inside
rcu_read_lock().
Fix it by moving uprobe_cpu_buffer preparation outside of
__uprobe_trace_func()
- kprobe-events: handle the error case of btf_find_struct_member()
* tag 'probes-fixes-v6.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
tracing/probes: fix error check in parse_btf_field()
uprobes: prevent mutex_lock() under rcu_read_lock()
Per PCIe r6.0, sec 5.2, a Link Down event can happen under any of the
following circumstances:
1. Fundamental/Hot reset
2. Link disable transmission by upstream component
3. Moving from L2/L3 to L0
When the event happens, the EPC driver capable of detecting it may pass the
notification to the EPF driver through link_down() callback in 'struct
pci_epc_event_ops'.
While the PCIe spec has not defined the actual behavior of the endpoint
when the Link Down event happens, we may assume that at least the ongoing
transactions need to be stopped as the link won't be active, so
cancel the command handler work in the callback implementation
pci_epf_test_link_down(). The work will be started again in
pci_epf_test_link_up() once the link comes back again.
Link: https://lore.kernel.org/linux-pci/20240430-pci-epf-rework-v4-10-22832d0d456f@linaro.org
Tested-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
[bhelgaas: update spec citation]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
In nvmet_sq_destroy we capture sq->ctrl early and if it is non-NULL we
know that a ctrl was allocated (in the admin connect request handler)
and we need to release pending AERs, clear ctrl->sqs and sq->ctrl
(for nvme-loop primarily), and drop the final reference on the ctrl.
However, a small window is possible where nvmet_sq_destroy starts (as
a result of the client giving up and disconnecting) concurrently with
the nvme admin connect cmd (which may be in an early stage). But *before*
kill_and_confirm of sq->ref (i.e. the admin connect managed to get an sq
live reference). In this case, sq->ctrl was allocated however after it was
captured in a local variable in nvmet_sq_destroy.
This prevented the final reference drop on the ctrl.
Solve this by re-capturing the sq->ctrl after all inflight request has
completed, where for sure sq->ctrl reference is final, and move forward
based on that.
This issue was observed in an environment with many hosts connecting
multiple ctrls simoutanuosly, creating a delay in allocating a ctrl
leading up to this race window.
Reported-by: Alex Turin <alex@vastdata.com>
Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Keith Busch <kbusch@kernel.org>
The nvme pci driver synchronizes with all the namespace queues during a
reset to ensure that there's no pending timeout work.
Meanwhile the timeout work potentially iterates those same namespaces to
freeze their queues.
Each of those namespace iterations use the same read lock. If a write
lock should somehow get between the synchronize and freeze steps, then
forward progress is deadlocked.
We had been relying on the nvme controller state machine to ensure the
reset work wouldn't conflict with timeout work. That guarantee may be a
bit fragile to rely on, so iterate the namespace lists without taking
potentially circular locks, as reported by lockdep.
Link: https://lore.kernel.org/all/20220930001943.zdbvolc3gkekfmcv@shindev/
Reported-by: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Tested-by: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Enable power gating for all units and sub-pipes that
are disabled by default.
v2: change the init function name
use symmetric calls for enable/disable pg
re-pharase commit message (Rodrigo)
modify the sub-pipe power gating condition
v3: set hysteresis value for render and media
when GuC PC is disabled
skip CPG for PVC (Vinay)
v4: rebase
Signed-off-by: Riana Tauro <riana.tauro@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> #v2
Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240524070916.143022-3-riana.tauro@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
It fixes the following warnings when
the kernel documentation is generated:
./include/drm/display/drm_dp_helper.h:126:
warning: Function parameter or struct member
'mode' not described in 'drm_dp_as_sdp'
./include/drm/display/drm_dp_helper.h:126:
warning: Excess struct member 'operation_mode'
description in 'drm_dp_as_sdp'
Signed-off-by: MarileneGarcia <marilene.agarcia@gmail.com>
Fixes: 0bbb8f594e ("drm/dp: Add Adaptive Sync SDP logging")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Closes: https://lore.kernel.org/r/20240405141640.09b0bdbf@canb.auug.org.au
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240519031027.433751-1-marilene.agarcia@gmail.com
Tegra194 and Tegra234 PCIe EP controllers have 64K alignment restriction
for the inbound ATU. Set the endpoint inbound ATU alignment to 64kB in the
Tegra194 PCIe driver.
Fixes: c57247f940 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194")
Suggested-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Link: https://lore.kernel.org/linux-pci/20240508092207.337063-1-jonathanh@nvidia.com
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Avoid large backtrace, it is sufficient to warn the user that there has
been a link problem. Either the link has failed and the system is in need
of maintenance, or the link continues to work and user has been informed.
The message from the warning can be looked up in the sources.
This makes an actual link issue less verbose.
First of all, this controller has a limitation in that the controller
driver has to assist the hardware with transition to L1 link state by
writing L1IATN to PMCTRL register, the L1 and L0 link state switching
is not fully automatic on this controller.
In case of an ASMedia ASM1062 PCIe SATA controller which does not support
ASPM, on entry to suspend or during platform pm_test, the SATA controller
enters D3hot state and the link enters L1 state. If the SATA controller
wakes up before rcar_pcie_wakeup() was called and returns to D0, the link
returns to L0 before the controller driver even started its transition to
L1 link state. At this point, the SATA controller did send an PM_ENTER_L1
DLLP to the PCIe controller and the PCIe controller received it, and the
PCIe controller did set PMSR PMEL1RX bit.
Once rcar_pcie_wakeup() is called, if the link is already back in L0 state
and PMEL1RX bit is set, the controller driver has no way to determine if
it should perform the link transition to L1 state, or treat the link as if
it is in L0 state. Currently the driver attempts to perform the transition
to L1 link state unconditionally, which in this specific case fails with a
PMSR L1FAEG poll timeout, however the link still works as it is already
back in L0 state.
Reduce this warning verbosity. In case the link is really broken, the
rcar_pcie_config_access() would fail, otherwise it will succeed and any
system with this controller and ASM1062 can suspend without generating
a backtrace.
Fixes: 84b5761462 ("PCI: rcar: Finish transition to L1 state in rcar_pcie_config_access()")
Link: https://lore.kernel.org/linux-pci/20240511235513.77301-1-marek.vasut+renesas@mailbox.org
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Add the PCIE_RESET_CONFIG_DEVICE_WAIT_MS macro to define the minimum
waiting time between exit from a conventional reset and sending the
first configuration request to the device.
As described in PCIe r6.0, sec 6.6.1 <Conventional Reset>, there are two
different use cases of the value:
- "With a Downstream Port that does not support Link speeds greater
than 5.0 GT/s, software must wait a minimum of 100 ms following exit
from a Conventional Reset before sending a Configuration Request to
the device immediately below that Port."
- "With a Downstream Port that supports Link speeds greater than
5.0 GT/s, software must wait a minimum of 100 ms after Link training
completes before sending a Configuration Request to the device
immediately below that Port."
[kwilczynski: commit log]
Link: https://lore.kernel.org/linux-pci/20240328091835.14797-21-minda.chen@starfivetech.com
Signed-off-by: Kevin Xie <kevin.xie@starfivetech.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Mason Huo <mason.huo@starfivetech.com>
plda_pcie_setup_iomems() needs the bridge->windows list from struct
pci_host_bridge and is currently used only by pcie-microchip-host.c. This
driver uses pci_host_common_probe(), which sets a pci_host_bridge as the
drvdata, so plda_pcie_setup_iomems() used platform_get_drvdata() to find
the pci_host_bridge.
But we also want to use plda_pcie_setup_iomems() in the new pcie-starfive.c
driver, which does not use pci_host_common_probe() and will have struct
starfive_jh7110_pcie as its drvdata, so pass the pci_host_bridge directly
to plda_pcie_setup_iomems() so it doesn't need platform_get_drvdata() to
find it.
Link: https://lore.kernel.org/linux-pci/20240328091835.14797-9-minda.chen@starfivetech.com
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
[bhelgaas: commit log, reorder to where this is needed]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Add PLDA host plda_pcie_host_init()/plda_pcie_host_deinit() and map bus
function so vendors can use it to init PLDA PCIe host core.
Link: https://lore.kernel.org/linux-pci/20240328091835.14797-19-minda.chen@starfivetech.com
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Mason Huo <mason.huo@starfivetech.com>
PLDA DMA interrupts are not all implemented, and the non-implemented
interrupts should be masked. Add a bitmap field to mask the non-implemented
interrupts.
Link: https://lore.kernel.org/linux-pci/20240328091835.14797-18-minda.chen@starfivetech.com
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
As PLDA DT binding doc (Documentation/devicetree/bindings/pci/
plda,xpressrich3-axi-common.yaml) showed, PLDA PCIe contains an interrupt
controller.
PolarFire implements its own PCIe interrupts, additional to the regular
PCIe interrupts, due to lack of an MSI controller, so the interrupt to
event number mapping is different to the PLDA regular interrupts,
necessitating a custom get_events() implementation.
Microchip PolarFire PCIe additional interrupts (defined in
drivers/pci/controller/plda/pcie-microchip-host.c):
EVENT_PCIE_L2_EXIT
EVENT_PCIE_HOTRST_EXIT
EVENT_PCIE_DLUP_EXIT
EVENT_SEC_TX_RAM_SEC_ERR
EVENT_SEC_RX_RAM_SEC_ERR
...
plda_get_events() adds interrupt register to PLDA event num mapping codes.
All the PLDA interrupts can be seen in new added graph.
[kwilczynski: commit log]
Link: https://lore.kernel.org/linux-pci/20240328091835.14797-15-minda.chen@starfivetech.com
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
The INTx and MSI interrupt event num is different across platforms, so
add two event num fields in struct plda_event.
Link: https://lore.kernel.org/linux-pci/20240328091835.14797-14-minda.chen@starfivetech.com
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
As the PLDA DT binding doc (Documentation/devicetree/bindings/pci/
plda,xpressrich3-axi-common.yaml) shows, the PLDA IP contains an interrupt
controller. Microchip PolarFire add some interrupts based on PLDA interrupt
controller.
The Microchip PolarFire PCIe additional interrupts (defined in
drivers/pci/controller/plda/pcie-microchip-host.c):
EVENT_PCIE_L2_EXIT
EVENT_PCIE_HOTRST_EXIT
EVENT_PCIE_DLUP_EXIT
EVENT_SEC_TX_RAM_SEC_ERR
EVENT_SEC_RX_RAM_SEC_ERR
...
Both event_cause[] and mc_event_handler() contain additional interrupt
symbol names; these can not be re-used. Add a new plda_event_handler()
function, which implements PLDA interrupt defalt handler, and add a
request_event_irq() callback function for Microchip PolarFire additional
interrupts.
[kwilczynski, bhelgaas: commit log]
Link: https://lore.kernel.org/linux-pci/20240328091835.14797-13-minda.chen@starfivetech.com
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
The number of events is different across platforms. In order to share
interrupt processing code, add a variable that defines the number of
events so that it can be set per-platform instead of hardcoding it.
Link: https://lore.kernel.org/linux-pci/20240328091835.14797-12-minda.chen@starfivetech.com
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Rename mc_* to plda_* for IRQ functions and related IRQ domain ops data
instances.
MSI, INTx interrupt code and IRQ init code can all be re-used.
Link: https://lore.kernel.org/linux-pci/20240328091835.14797-11-minda.chen@starfivetech.com
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Move plda_pcie_setup_window() and plda_pcie_setup_iomems() to
pcie-plda-host.c so they can be shared by all PLDA-based drivers.
Link: https://lore.kernel.org/linux-pci/20240328091835.14797-10-minda.chen@starfivetech.com
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Rename mc_pcie_setup_window() to plda_pcie_setup_window() and
mc_pcie_setup_windows() to plda_pcie_setup_iomems() so they can be shared
by all PLDA-based drivers.
Link: https://lore.kernel.org/linux-pci/20240328091835.14797-8-minda.chen@starfivetech.com
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Move the PLDA generic data structures to a header file so they can be
re-used by all PLDA-based drivers.
[kwilczynski: commit log]
Link: https://lore.kernel.org/linux-pci/20240328091835.14797-7-minda.chen@starfivetech.com
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Rename struct mc_msi to plda_msi and move most of struct mc_pcie to a new
struct plda_pcie_rp so they can be shared by all PLDA-based drivers.
The axi_base_addr field remains in struct mc_pcie since it's
Microchip-specific data.
The event interrupt code is still using struct mc_pcie because the event
interrupt code can not be re-used.
[kwilczynski: commit log]
Link: https://lore.kernel.org/linux-pci/20240328091835.14797-6-minda.chen@starfivetech.com
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Bridge address base is common PLDA field, add this to struct mc_pcie first.
INTx and MSI interrupt code will be changed to common code, so get the
bridge base address from port->bridge_addr instead of axi_base_addr.
The axi_base_addr is Microchip-specific data.
Link: https://lore.kernel.org/linux-pci/20240328091835.14797-5-minda.chen@starfivetech.com
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
If IORESOURCE_MEM is not provided in Device Tree due to
any error, resource_list_first_type() will return NULL and
pci_parse_request_of_pci_ranges() will just emit a warning.
This will cause a NULL pointer dereference. Fix this bug by adding NULL
return check.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 0f71c60ffd ("PCI: dwc: Remove storing of PCI resources")
Link: https://lore.kernel.org/linux-pci/20240505061517.11527-1-amishin@t-argos.ru
Suggested-by: Bjorn Helgaas <helgaas@kernel.org>
Suggested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
After 6ab15b5e70 ("PCI: dwc: keystone: Convert .scan_bus() callback to
use add_bus"), ks_pcie_v3_65_add_bus() enabled BAR 0 for both v3.65a and
v4.90a devices. On the AM654x SoC, which uses v4.90a, enabling BAR 0
causes Completion Timeouts when setting up MSI-X. These timeouts delay
boot of the AM654x by about 45 seconds.
Move the BAR 0 initialization to ks_pcie_msi_host_init(), which is only
used for v3.65a devices, and remove ks_pcie_v3_65_add_bus().
[bhelgaas: commit log]
Fixes: 6ab15b5e70 ("PCI: dwc: keystone: Convert .scan_bus() callback to use add_bus")
Link: https://lore.kernel.org/linux-pci/20240328085041.2916899-3-s-vadapalli@ti.com
Suggested-by: Bjorn Helgaas <helgaas@kernel.org>
Suggested-by: Niklas Cassel <cassel@kernel.org>
Suggested-by: Serge Semin <fancer.lancer@gmail.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Relocate ks_pcie_set_dbi_mode() and ks_pcie_clear_dbi_mode() to avoid
forward declaration in a subsequent patch. No functional change intended.
Link: https://lore.kernel.org/linux-pci/20240328085041.2916899-2-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: Bjorn Helgaas <bhelgaas@google.com>
The of_gpio.h legacy API is going to be removed. In preparation for that,
convert the driver to the agnostic API.
[kwilczynski: commit log]
Link: https://lore.kernel.org/linux-pci/20240506142142.4042810-5-andriy.shevchenko@linux.intel.com
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
The of_gpio.h API is deprecated and subject to removal. The driver doesn't
use it, so simply remove the unused header.
[kwilczynski: commit log]
Link: https://lore.kernel.org/linux-pci/20240506142142.4042810-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
The of_gpio.h API is deprecated and subject to removal. The driver doesn't
use it, so simply remove the unused header.
[kwilczynski: commit log]
Link: https://lore.kernel.org/linux-pci/20240506142142.4042810-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
There is no need to hardcode the clock info in the driver as driver can
rely on the devicetree to supply the clocks required for the functioning
of the peripheral.
Thus, remove the static clock info and obtain the platform supplied
clocks. All the clocks supplied are obtained and enabled using the
devm_clk_bulk_get_all_enable() API.
[kwilczynski: commit log]
Link: https://lore.kernel.org/linux-pci/20240220084046.23786-3-shradha.t@samsung.com
Signed-off-by: Shradha Todi <shradha.t@samsung.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
The function pointer declaration for the cpu_addr_fixup() callback uses
"cpu_addr" as parameter name.
Likewise, the argument that is supplied to the function pointer when the
function is actually called is "cpu_addr".
Rename the dra7xx_pcie_cpu_addr_fixup() function parameter name to match
reality.
[kwilczynski: commit log]
Link: https://lore.kernel.org/linux-pci/20240430071054.248008-3-cassel@kernel.org
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Add missing cache information to the Allwinner A64 SoC dtsi, to allow
the userspace, which includes lscpu(1) that uses the virtual files provided
by the kernel under the /sys/devices/system/cpu directory, to display the
proper A64 cache information.
While there, use a more self-descriptive label for the L2 cache node, which
also makes it more consistent with other SoC dtsi files.
The cache parameters for the A64 dtsi were obtained and partially derived
by hand from the cache size and layout specifications found in the following
datasheets and technical reference manuals:
- Allwinner A64 datasheet, version 1.1
- ARM Cortex-A53 revision r0p3 TRM, version E
For future reference, here's a brief summary of the documentation:
- All caches employ the 64-byte cache line length
- Each Cortex-A53 core has 32 KB of L1 2-way, set-associative instruction
cache and 32 KB of L1 4-way, set-associative data cache
- The entire SoC has 512 KB of unified L2 16-way, set-associative cache
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Link: https://lore.kernel.org/r/6a772756c2c677dbdaaab4a2c71a358d8e4b27e9.1714304058.git.dsimic@manjaro.org
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Add missing cache information to the Allwinner H6 SoC dtsi, to allow
the userspace, which includes lscpu(1) that uses the virtual files provided
by the kernel under the /sys/devices/system/cpu directory, to display the
proper H6 cache information.
Adding the cache information to the H6 SoC dtsi also makes the following
warning message in the kernel log go away:
cacheinfo: Unable to detect cache hierarchy for CPU 0
The cache parameters for the H6 dtsi were obtained and partially derived
by hand from the cache size and layout specifications found in the following
datasheets and technical reference manuals:
- Allwinner H6 V200 datasheet, version 1.1
- ARM Cortex-A53 revision r0p3 TRM, version E
For future reference, here's a brief summary of the documentation:
- All caches employ the 64-byte cache line length
- Each Cortex-A53 core has 32 KB of L1 2-way, set-associative instruction
cache and 32 KB of L1 4-way, set-associative data cache
- The entire SoC has 512 KB of unified L2 16-way, set-associative cache
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Link: https://lore.kernel.org/r/49abb93000078c692c48c0a65ff677893909361a.1714304071.git.dsimic@manjaro.org
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Add a DT node for the Allwinner H616 LRADC describing the base address,
interrupt, reset and clock gates.
Signed-off-by: James McGregor <jamcgregor@protonmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Škrabec <jernej.skrabec@gmail.com>
Link: https://lore.kernel.org/r/20240426092924.15489-3-jamcgregor@protonmail.com
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
