The old binding variant (the one covering whole DMU block) was
deprecated 3 years ago. Linux kernel was warning when using it for
similar amount of time.
There aren't any known Northstar devices with bootloader providing DT to
operating system. Actually OpenWrt seems to be the only project using
this binding and it always appends DTB to kernel. It has switched to the
non-deprecated binding years ago.
Given there is close to zero chance this breaks anyone's setup it should
more than safe to drop this binding variant after 3 years.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20240913044557.28315-1-zajec5@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
After commit 0edb555a65 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platform drivers.
Convert all platform drivers below drivers/phy/ to use .remove(), with
the eventual goal to drop struct platform_driver::remove_new(). As
.remove() and .remove_new() have the same prototypes, conversion is done
by just changing the structure member name in the driver initializer.
While touching these files, make indention of the struct initializer
consistent in several files.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/20241009065307.504930-2-u.kleine-koenig@baylibre.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Currently, if the clock values cannot be set to the exact rate,
the round_rate and set_rate functions use the closest value found in
the look-up-table. In preparation of removing values from the LUT
that can be calculated evenly with the integer calculator, it's
necessary to ensure to check both the look-up-table and the integer
divider clock values to get the closest values to the requested
value. It does this by measuring the difference between the
requested clock value and the closest value in both integer divider
calucator and the fractional clock look-up-table.
Which ever has the smallest difference between them is returned as
the closest rate.
Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
Tested-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Link: https://lore.kernel.org/r/20240914112816.520224-5-aford173@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
There is currently a look-up table for a variety of resolutions.
Since the phy has the ability to dynamically calculate the values
necessary to use the intger divider which should allow more
resolutions without having to update the look-up-table.
If the lookup table cannot find an exact match, fall back to the
dynamic calculator of the integer divider.
Previously, the value of P was hard-coded to 1, this required an
update to the phy_pll_cfg table to add in the extra value into the
table, so if the value of P is calculated to be something else
by the PMS calculator, the calculated_phy_pll_cfg structure
can be used instead without having to keep track of which method
was used.
Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
Tested-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Link: https://lore.kernel.org/r/20240914112816.520224-4-aford173@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Currently driver supports only x4 lane based functionality using tx/rx and
tx2/rx2 pair of register sets. To support 8 lane functionality with PCIe3,
PCIe3 related QMP PHY provides additional programming which are available
as txz and rxz based register set. Hence add txz and rxz based registers
usage and programming sequences.
As soon as software programs the txz and rxz based register set, hardware
shall "broadcast" the same settings to the tx/rx pair of registers for all
the 8 lanes, which saves the effort of software programming them one by
one.
There might be some tx and/or rx registers on some lanes need minor tweaks,
program them after programming the txz and rxz reigster set.
In addition, x1e80100 uses QMP PHY ver 6.30 for PCIe Gen4 x8, hence add
two new header files to reflect the new register offsets.
Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Konrad Dybcio <konradybcio@kernel.org>
Link: https://lore.kernel.org/r/20241017030412.265000-5-quic_qianyu@quicinc.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Addition of the COMBOPHY driver found on STM32MP25 platforms
This single lane PHY is shared (exclusive) between the USB3 and PCIE
controllers.
Supports 5Gbit/s for PCIE gen2 or 2.5Gbit/s for PCIE gen1.
Supports wakeup-source capability to wakeup system using remote-wakeup
capable USB device
Signed-off-by: Christian Bruel <christian.bruel@foss.st.com>
Link: https://lore.kernel.org/r/20240930170847.948779-3-christian.bruel@foss.st.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Document the bindings for STM32 COMBOPHY interface, used to support
the PCIe and USB3 stm32mp25 drivers.
Following entries can be used to tune caracterisation parameters
- st,output-micro-ohms and st,output-vswing-microvolt bindings entries
to tune the impedance and voltage swing using discrete simulation results
- st,rx-equalizer register to set the internal rx equalizer filter value.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Christian Bruel <christian.bruel@foss.st.com>
Link: https://lore.kernel.org/r/20240930170847.948779-2-christian.bruel@foss.st.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
CP11x UTMI PHY supports swapping D+/D- signals via digital control
register 1.
Add support for the "swap-dx-lanes" device-tree property, which lists
the port-ids that should swap D+ and D-.
The property is evaluated in probe and applied before power-on
during mvebu_cp110_utmi_port_setup.
Signed-off-by: Josua Mayer <josua@solid-run.com>
Link: https://lore.kernel.org/r/20241002-mvebu-utmi-phy-v4-1-83783dc89b9d@solid-run.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The Broadcom USB PHY driver contains a lookup table
(`reg_bits_map_tables`) to resolve register bitmaps unique to certain
versions of the USB PHY as found in various Broadcom chip families.
Historically, this table was just kept carefully in sync with the
"selector" enum every time the latter changed to ensure consistency.
However, a recent commit [1] introduced two new enumerators but did not
adjust the array for BCM4908, thus breaking the xHCI controller (and
boot process) on this platform and revealing the fragility of this
approach.
Since these arrays are a little sparse (many elements are zero) and the
position of the array elements is significant only insofar as they agree
with the enumerators, designated initializers are a better fit than
positional initializers here. Convert this table accordingly.
[1] 4536fe9640 ("phy: usb: suppress OC condition for 7439b2")
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Reviewed-by: Justin Chen <justin.chen@broadcom.com>
Link: https://lore.kernel.org/r/20241004034131.1363813-3-CFSworks@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The Broadcom USB PHY driver contains a lookup table
(`reg_bits_map_tables`) to resolve register bitmaps unique to certain
versions of the USB PHY as found in various Broadcom chip families. A
recent commit (see 'fixes' tag) introduced two new elements to each chip
family in this table -- except for one: BCM4908. This resulted in the
xHCI controller not being initialized correctly, causing a panic on
boot.
The next patch will update this table to use designated initializers in
order to prevent this from happening again. For now, just add back the
missing array elements to resolve the regression.
Fixes: 4536fe9640 ("phy: usb: suppress OC condition for 7439b2")
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Reviewed-by: Justin Chen <justin.chen@broadcom.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://lore.kernel.org/r/20241004034131.1363813-2-CFSworks@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
