Enable XS-Phy on Bananapi R4 for pcie2.
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20250422132438.15735-9-linux@fw-web.de
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
First usb and third pcie controller on mt7988 need a xs-phy to work
properly.
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20250422132438.15735-8-linux@fw-web.de
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Sinovoip has released other variants of Bananapi-R4 board.
The known changes affecting only the LAN SFP+ slot which is replaced
by a 2.5G phy with optional PoE.
Just move the common parts to a new dtsi and keep differences (only
i2c for lan-sfp) in dts.
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogiaocchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20250422132438.15735-3-linux@fw-web.de
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Add new compatible for Bananapi R4 with 2.5G phy.
Base board is compatible with existing BPI-R4 only 1 SFP is replaced
by RJ45 port and use mt7988 internal phy.
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20250422132438.15735-2-linux@fw-web.de
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
After having factored out the provider part from mdio_bus.c, we can
make the mdio consumer / device layer a separate module. This also
allows to remove Kconfig symbol MDIO_DEVICE.
The module init / exit functions from mdio_bus.c no longer have to be
called from phy_device.c. The link order defined in
drivers/net/phy/Makefile ensures that init / exit functions are called
in the right order.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://patch.msgid.link/dba6b156-5748-44ce-b5e2-e8dc2fcee5a7@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
This adds a match entry for using all the amps on a CDB35L63-CB2 board
without the CS42L43 codec. Configuration is:
SDW3: 1x CS35L63 (OUT1)
SDW1: 1x CS35L63 (OUT2)
Speaker playback and amp feedback are aggregated.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Link: https://patch.msgid.link/20250516152107.210994-3-sbinding@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use the previously parsed DisCo information from ACPI to create the DAI
drivers required to connect an SDCA Function into an ASoC soundcard.
Create DAI driver structures and populate the supported sample rates
and sample widths into them based on the Input/Output Terminal and any
attach Clock Source entities. More complex relationships with channels
etc. will be added later as constraints as part of the DAI startup.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20250516131011.221310-8-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use the previously parsed DisCo information from ACPI to create the
ALSA controls required by an SDCA Function. This maps all User and
Application level SDCA Controls to ALSA controls. Typically controls
marked with those access levels are just volumes and mutes.
SDCA defines volume controls as an integer in 1/256ths of a dB and
then provides a mechanism to specify what values are valid (range
templates). Currently only a simple case of a single linear volume
range with a power of 2 step size is supported. This allows the code
to expose the volume control using a simple shift. This will need
expanded in the future, to support more complex ranges and probably
also some additional control types but this should be sufficient to
for a first pass.
For non-dataport terminal widgets also add a pin switch to allow
that endpoint to be turned on/off.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20250516131011.221310-7-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use the previously parsed DisCo information from ACPI to create DAPM
widgets and routes representing a SDCA Function. For the most part SDCA
maps well to the DAPM abstractions.
The primary point of interest is the SDCA Power Domain Entities
(PDEs), which actually control the power status of the device. Whilst
these PDEs are the primary widgets the other parts of the SDCA graph
are added to maintain a consistency with the hardware abstract,
and allow routing to take effect. As for the PDEs themselves the
code currently only handle PS0 and PS3 (basically on and off),
the two intermediate power states are not commonly used and don't
map well to ASoC/DAPM.
Other minor points of slightly complexity include, the Group Entities
(GEs) these set the value of several other controls, typically
Selector Units (SUs) for enabling a cetain jack configuration. Multiple
SUs being controlled by a GE are easily modelled creating a single
control and sharing it among the controlled muxes.
SDCA also has a slight habit of having fully connected paths, relying
more on activating the PDEs to enable functionality. This doesn't
map quite so perfectly to DAPM which considers the path a reason to
power the PDE. Whilst in the current specification Mixer Units are
defined as fixed-function, in DAPM we create a virtual control for
each input (which defaults to connected). This allows paths to be
connected/disconnected, providing a more ASoC style approach to
managing the power. PIN_SWITCHs will also be added for non-dataport
terminal entities in a later patch along with the other ALSA controls,
providing greater flexibility in power management.
A top level helper sdca_asoc_populate_component() is exported that
counts and allocates everything, however, the intermediate counting and
population functions are also exported. This will allow end drivers to
do allocation and add custom handling, which is probably fairly likely
for the early SDCA devices.
Clock muxes are currently not fully supported, so some future work will
also be required there.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20250516131011.221310-6-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The core currently supports pin switches for source/sink widgets, but
only at the card level. SDCA components specify the fabric at the
level of the individual components, to support this add helpers to
allow component level pin switches.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20250516131011.221310-5-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Move the allocation of the PDE delays array until after the size has
been adjusted, this saves an additional division and simplifies the
code slightly.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20250516131011.221310-4-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no need to include MODULE_LICENSE() and MODULE_DESCRIPTION() in
sdca_regmap.c as this file is part of a larger module that already
defines these.
Fixes: e3f7caf74b ("ASoC: SDCA: Add generic regmap SDCA helpers")
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20250516131011.221310-3-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
A few, quite rare, WMI attributes have names that are not compatible with
filenames, e.g. "Intel VT for Directed I/O (VT-d)".
For these cases the '/' gets replaced with '\' for display, but doesn't
get switched again when doing the WMI access.
Fix this by keeping the original attribute name and using that for sending
commands to the BIOS
Fixes: a40cd7ef22 ("platform/x86: think-lmi: Add WMI interface support on Lenovo platforms")
Signed-off-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Link: https://lore.kernel.org/r/20250520005027.3840705-1-mpearson-lenovo@squebb.ca
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Merge series from Geert Uytterhoeven <geert+renesas@glider.be>:
This patch series (A) improves single transfer sizes in the MSIOF
driver, using two methods:
- By increasing the assumed FIFO sizes, impacting both PIO and DMA
transfers,
- By using two groups, impacting DMA transfers,
and (B) lets the recently-introduced MSIOF I2S drive reuse the SPI
driver's register definitions. All of this is covered with a thick
sauce of fixes for (harmless) bugs, cleanups, and refactorings.
Note that the driver uses the limitations as specified in the hardware
documentation. For discovering the actual FIFO sizes, I wrote some
crude test code that can be found at [2].
This is based on spi/for-next and sound-asoc/for-next, and has been
tested on a variery of R-Car SoCs.
[1] https://lore.kernel.org/cover.1746180072.git.geert+renesas@glider.be
[2] https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/log/?h=topic/msiof-fifo
Merge series from Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>:
This patchset adds support for sound card on Qualcomm QCS9100 and
QCS9075 boards.
If either REGMAP_IRQ or REGMAP_MDIO are set then REGMAP is also set.
This then enables the selecting of IRQ_DOMAIN or MDIO_BUS from REGMAP
based on the above two symbols respectively. This makes it very easy
to end up with "circular dependencies".
Instead select the IRQ_DOMAIN or MDIO_BUS from the symbols that make
use of them. This is almost equivalent to before but makes it less
likely to end up with false circular dependency detections.
Signed-off-by: Andrew Davis <afd@ti.com>
Reported-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Closes: https://lore.kernel.org/r/bfe991fa-f54c-4d58-b2e0-34c4e4eb48f4@linaro.org/
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20250516141722.13772-1-afd@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The function sdm845_slim_snd_hw_params() calls the functuion
snd_soc_dai_set_channel_map() but does not check its return
value. A proper implementation can be found in msm_snd_hw_params().
Add error handling for snd_soc_dai_set_channel_map(). If the
function fails and it is not a unsupported error, return the
error code immediately.
Fixes: 5caf64c633 ("ASoC: qcom: sdm845: add support to DB845c and Lenovo Yoga")
Cc: stable@vger.kernel.org # v5.6
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://patch.msgid.link/20250519075739.1458-1-vulab@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Add an useful info when failed to get irq/wakeirq due to -EPROBE_DEFER.
Before:
[ 15.737361] i2c 2-0050: deferred probe pending: (reason unknown)
After:
[ 15.816295] i2c 2-0050: deferred probe pending: tcpci: can't get irq
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
Reviewed-by: Carlos Song <carlos.song@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Currently, it is possible that LPM is enabled while calling the set_lpm()
callback.
The current code performs a SET FEATURES command to disable DIPM if
policy < ATA_LPM_MED_POWER_WITH_DIPM, this means that it will currently
disable DIPM for policies:
ATA_LPM_UNKNOWN, ATA_LPM_MAX_POWER, ATA_LPM_MED_POWER
(but not for policy ATA_LPM_MED_POWER_WITH_DIPM).
The code called after calling the set_lpm() callback will later perform
a SET FEATURES command to enable DIPM, if
policy >= ATA_LPM_MED_POWER_WITH_DIPM.
As we can see DIPM will not be disabled before calling set_lpm() if the LPM
policy is: ATA_LPM_MED_POWER_WITH_DIPM, ATA_LPM_MIN_POWER_WITH_PARTIAL,
or ATA_LPM_MIN_POWER.
Make sure that we always disable DIPM before calling the set_lpm()
callback. This is because the set_lpm() callback is the function (for AHCI)
that sets the proper bits in PxSCTL.IPM, reflecting the support of the HBA.
PxSCTL.IPM controls the LPM states that the device is allowed to enter.
If the device tries to enter a state disabled by PxSCTL.IPM, the host will
NAK the transition.
If we do not disable DIPM before modifying PxSCTL.IPM, it is possible that
DIPM will try (and will be allowed to) enter a LPM state that the HBA does
not support (since we have not yet written PxSCTL.IPM, the HBA wasn't able
to NAK the transition).
While at it, remove the guard of host support for DIPM around the disabling
of DIPM. While it makes sense to take host support for DIPM into account
when enabling DIPM, it makes zero sense to take host support into account
when disabling DIPM.
If the host does not support DIPM, that is an even bigger reason why DIPM
should be disabled on the device side.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Rename the no_dipm variable to host_has_dipm, by inverting the
expression, and and also having a clearer name.
No functional change.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Rename the hipm and dipm variables to have a clearer name.
Also fold in the usage of no_dipm, as that is required in order to give
the dipm variable a more descriptive name.
No functional change.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
link->lpm_policy is initialized to ATA_LPM_UNKNOWN in ata_eh_reset().
ata_eh_set_lpm() is then only called if
link->lpm_policy != ap->target_lpm_policy (after reset)
and then only if link->lpm_policy > ATA_LPM_MAX_POWER (before
revalidation).
This means that ata_eh_set_lpm() is currently never called with
policy == ATA_LPM_UNKNOWN.
Add a WARN_ON_ONCE so that it is more obvious from reading the code that
this function is never called with policy == ATA_LPM_UNKNOWN.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
The comments describing which LPM policies that has DIPM enabled predates
the introduction of the LPM policies ATA_LPM_MIN_POWER_WITH_PARTIAL and
ATA_LPM_MED_POWER_WITH_DIPM. Update the DIPM comments to reflect reality.
Also remove the sentence that claims that "Order device and link
configurations such that the host always allows DIPM requests."
This comment is written before 24e0e61db3 ("ata: libata: disallow
dev-initiated LPM transitions to unsupported states").
Even though the set_lpm() call is done before enabling DIPM, the host will
not always allow DIPM requests. For all LPM polcies where DIPM is enabled,
only DIPM requests to LPM states that are supported by the HBA will be
allowed.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Due to a problem in the iTBT DP-in adapter's firmware the sink on a TBT
link may get disconnected inadvertently if the SINK_COUNT_ESI and the
DP_LINK_SERVICE_IRQ_VECTOR_ESI0 registers are read in a single AUX
transaction. Work around the issue by reading these registers in
separate transactions.
The issue affects MTL+ platforms and will be fixed in the DP-in adapter
firmware, however releasing that firmware fix may take some time and is
not guaranteed to be available for all systems. Based on this apply the
workaround on affected platforms.
See HSD #13013007775.
v2: Cc'ing Mika Westerberg.
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13760
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14147
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250519133417.1469181-1-imre.deak@intel.com
Rename intel_update_active_dpll to intel_dpll_update_active in an
effort to have function names which are exported to start with
filenames they are exported from.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-15-suraj.kandpal@intel.com
Rename intel_compute_dpll to intel_dpll_compute in an
effort to make sure all function names that are exported have
the filename at start.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-14-suraj.kandpal@intel.com
Rename intel_<release/reserve>_dpll to
intel_dpll_<release/reserve> in an effort to keep names of
exported functions start with the filename.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-13-suraj.kandpal@intel.com
Rename intel_reference_dpll_crtc to intel_dpll_crtc_get in an
effort to have all the exported functions have the name start
with file name.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-12-suraj.kandpal@intel.com
Rename intel_unreference_dpll_crtc to intel_dpll_crtc_put
in an effort to keep names of exported functions start with the filename.
--v2
-Make the new name more sensible [Jani]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-11-suraj.kandpal@intel.com
Rename intel_[enable/disable]_dpll to intel_dpll_[enable/disable]
in an effort to make sure all functions that are exported
start with the filename.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-10-suraj.kandpal@intel.com
Rename crtc_get_shared_dpll to take into the individual PLL framework
which came in at DISPLAY_VER >= 14.
Also having shared dpll stuff also in intel_dpll.c is just confusing.
--v2
-Change naming to dpll_global to keep consistency with rest of the
naming
--v3
-Just use intel_dpll [Jani]
--v4
-Modify commit message [Jani]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-9-suraj.kandpal@intel.com
Rename functions to move away from using shared dpll in the dpll
framework as much as possible since dpll may not always be shared.
--v2
-Use intel_dpll_global instead of global_dpll [Jani]
--v3
-Just use intel_dpll [Jani]
--v4
-Drop the global from comments [Jani]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-8-suraj.kandpal@intel.com
Rename intel_shared_dpll to intel_dpll to represent both
shared and individual dplls. Since from MTL each PHY has it's
own PLL making the shared PLL naming a little outdated. In an
effort to make this framework accepting of future changes this
needs to be done.
--v2
-Use intel_dpll_global to make sure names start with the filename
[Jani/Ville]
-Explain the need of this rename [Jani]
--v3
-Just keep it intel_dpll [Jani]
--v4
-Fix comment [Jani]
-Use just num_dpll and dplls [Jani]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-7-suraj.kandpal@intel.com
Rename intel_shared_dpll_funcs to intel_dpll_funcs
since it needs to represent both shared and individual
dplls.
--v2
-Change intel_global_dpll to intel_dpll_global to be more
in line with the naming standard where the name should
start with the file name [Jani]
--v3
-Drop shared and global altogether [Jani]
--v4
-Keep declarations sorted [Jani]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-6-suraj.kandpal@intel.com
Rename the macro for_each_shared_dpll to for_each_dpll since
this loop will not necessarily be used for only shared
dpll in future.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-5-suraj.kandpal@intel.com
Rename intel_shared_dpll_state to just intel_dpll_state since it may
not necessarily store share dpll state info specially since
DISPLAY_VER >= 14 PLL's are not shared.
Also change the name of variables which may have been associated as
a shared_dpll.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-4-suraj.kandpal@intel.com
Rename intel_dpll_funcs to intel_dpll_global_funcs so that later
on intel_shared_dpll_funcs can be renamed to intel_dpll_funcs.
This is done to move away from the shared naming convention since
starting MTL dpll's are not shared among PHYs.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-3-suraj.kandpal@intel.com
Rename intel_dpll to intel_dpll_global so that intel_shared_dpll
can be renamed to intel_dpll in an effort to move away from the shared
naming convention.
Also intel_dpll according to it's comment tracks global dpll rather
than individual hence making more sense this gets changed.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-2-suraj.kandpal@intel.com
pci/iomap.c still contains warnings about those functions not behaving
in a managed manner if pcim_enable_device() was called. Since all hybrid
behavior that users could know about has been removed by now, those
explicit warnings are no longer necessary.
Remove the hybrid-devres usage warnings from the kernel-doc.
Signed-off-by: Philipp Stanner <phasta@kernel.org>
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Link: https://lore.kernel.org/r/20250519112959.25487-8-phasta@kernel.org
When the demangling of the hybrid devres functions within PCI was
implemented, it was necessary to implement several PCI functions a
second time to avoid cyclic calls, since the hybrid functions in pci.c
call the managed functions in devres.c, which in turn can be directly
used outside of PCI and needed request infrastructure, too.
Therefore, __pcim_request_region_range(), __pci_release_region_range()
and wrappers around them were implemented.
The hybrid nature has recently been removed from all functions in pci.c.
Therefore, the functions in devres.c can now directly use their
counterparts in pci.c without causing a call-cycle.
Remove __pcim_request_region_range(), __pcim_request_region_range() and
the wrappers. Use the corresponding request functions from pci.c in
devres.c
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Link: https://lore.kernel.org/r/20250519112959.25487-7-phasta@kernel.org
pcim_request_region_exclusive(), the only user in PCI devres that needed
exclusive region requests, has been removed.
All features related to exclusive requests can, therefore, be removed,
too. Remove them.
Signed-off-by: Philipp Stanner <phasta@kernel.org>
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20250519112959.25487-6-phasta@kernel.org
Add a MAINTAINERS entry as part of integration of the EcoNet MIPS platform.
Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Add DTS files in support of EcoNet platform, including SmartFiber XP8421-B,
a low cost commercially available board based on EN751221.
Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Add "smartfiber" vendor prefix for manufactorer of EcoNet based boards.
Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
