When enable initcall_debug together with higher debug level below.
CONFIG_CONSOLE_LOGLEVEL_DEFAULT=9
CONFIG_CONSOLE_LOGLEVEL_QUIET=9
CONFIG_MESSAGE_LOGLEVEL_DEFAULT=7
The initialization of i.MX8MP PCIe PHY might be timeout failed randomly.
To fix this issue, adjust the sequence of the resets refer to the power
up sequence listed below.
i.MX8MP PCIe PHY power up sequence:
/---------------------------------------------
1.8v supply ---------/
/---------------------------------------------------
0.8v supply ---/
---\ /--------------------------------------------------
X REFCLK Valid
Reference Clock ---/ \--------------------------------------------------
-------------------------------------------
|
i_init_restn --------------
------------------------------------
|
i_cmn_rstn ---------------------
-------------------------------
|
o_pll_lock_done --------------------------
Logs:
imx6q-pcie 33800000.pcie: host bridge /soc@0/pcie@33800000 ranges:
imx6q-pcie 33800000.pcie: IO 0x001ff80000..0x001ff8ffff -> 0x0000000000
imx6q-pcie 33800000.pcie: MEM 0x0018000000..0x001fefffff -> 0x0018000000
probe of clk_imx8mp_audiomix.reset.0 returned 0 after 1052 usecs
probe of 30e20000.clock-controller returned 0 after 32971 usecs
phy phy-32f00000.pcie-phy.4: phy poweron failed --> -110
probe of 30e10000.dma-controller returned 0 after 10235 usecs
imx6q-pcie 33800000.pcie: waiting for PHY ready timeout!
dwhdmi-imx 32fd8000.hdmi: Detected HDMI TX controller v2.13a with HDCP (samsung_dw_hdmi_phy2)
imx6q-pcie 33800000.pcie: probe with driver imx6q-pcie failed with error -110
Fixes: dce9edff16 ("phy: freescale: imx8m-pcie: Add i.MX8MP PCIe PHY support")
Cc: stable@vger.kernel.org
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
v2 changes:
- Rebase to latest fixes branch of linux-phy git repo.
- Richard's environment have problem and can't sent out patch. So I help
post this fix patch.
Link: https://lore.kernel.org/r/20241021155241.943665-1-Frank.Li@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Ensure CONFIG_PHY_ROCKCHIP_SAMSUNG_HDPTX depends on CONFIG_COMMON_CLK to
fix the following link errors when compile testing some random kernel
configurations:
m68k-linux-ld: drivers/phy/rockchip/phy-rockchip-samsung-hdptx.o: in function `rk_hdptx_phy_clk_register':
drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c:1031:(.text+0x470): undefined reference to `__clk_get_name'
m68k-linux-ld: drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c:1036:(.text+0x4ba): undefined reference to `devm_clk_hw_register'
m68k-linux-ld: drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c:1040:(.text+0x4d2): undefined reference to `of_clk_hw_simple_get'
m68k-linux-ld: drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c:1040:(.text+0x4da): undefined reference to `devm_of_clk_add_hw_provider'
Fixes: c4b09c5620 ("phy: phy-rockchip-samsung-hdptx: Add clock provider support")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202409180305.53PXymZn-lkp@intel.com/
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240923-sam-hdptx-link-fix-v1-1-8d10d7456305@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Commit b64a85fb8f ("phy: ti: phy-j721e-wiz.c: Add usxgmii support in
wiz driver") added support for USXGMII mode. In doing so, P0_REFCLK_SEL
was set to "pcs_mac_clk_divx1_ln_0" (0x3) and P0_STANDARD_MODE was set to
LANE_MODE_GEN1, which results in a data rate of 5.15625 Gbps. However,
since the USXGMII mode can support up to 10.3125 Gbps data rate, the
aforementioned fields should be set to "pcs_mac_clk_divx0_ln_0" (0x2) and
LANE_MODE_GEN2 respectively. The signal corresponding to the USXGMII lane
of the SERDES has been measured as 5 Gbps without the change and 10 Gbps
with the change. Hence, fix the configuration accordingly to support
USXGMII up to 10G.
Fixes: b64a85fb8f ("phy: ti: phy-j721e-wiz.c: Add usxgmii support in wiz driver")
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20241012053937.3596885-1-s-vadapalli@ti.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Commit 44aff8e310 ("phy: qcom-qmp-combo: clean up probe
initialisation") removed most users of the platform device driver data,
but mistakenly also removed the initialisation despite the data still
being used in the runtime PM callbacks.
The initialisation was soon after restored by commit 83a0bbe39b ("phy:
qcom-qmp-combo: add support for updated sc8280xp binding") but now
happens slightly later during probe. This should not cause any trouble
currently as runtime PM needs to be enabled manually through sysfs and
the platform device would not be suspended before the PHY has been
registered anyway.
Move the driver data initialisation to avoid a NULL-pointer dereference
on runtime suspend if runtime PM is ever enabled by default in this
driver.
Fixes: 44aff8e310 ("phy: qcom-qmp-combo: clean up probe initialisation")
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20240911115253.10920-5-johan+linaro@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Commit 413db06c05 ("phy: qcom-qmp-usb: clean up probe initialisation")
removed most users of the platform device driver data from the
qcom-qmp-usb driver, but mistakenly also removed the initialisation
despite the data still being used in the runtime PM callbacks. This bug
was later reproduced when the driver was copied to create the qmp-usbc
driver.
Restore the driver data initialisation at probe to avoid a NULL-pointer
dereference on runtime suspend.
Apparently no one uses runtime PM, which currently needs to be enabled
manually through sysfs, with these drivers.
Fixes: 19281571a4 ("phy: qcom: qmp-usb: split USB-C PHY driver")
Cc: stable@vger.kernel.org # 6.9
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20240911115253.10920-4-johan+linaro@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Commit 413db06c05 ("phy: qcom-qmp-usb: clean up probe initialisation")
removed most users of the platform device driver data from the
qcom-qmp-usb driver, but mistakenly also removed the initialisation
despite the data still being used in the runtime PM callbacks. This bug
was later reproduced when the driver was copied to create the
qmp-usb-legacy driver.
Restore the driver data initialisation at probe to avoid a NULL-pointer
dereference on runtime suspend.
Apparently no one uses runtime PM, which currently needs to be enabled
manually through sysfs, with these drivers.
Fixes: e464a3180a ("phy: qcom-qmp-usb: split off the legacy USB+dp_com support")
Cc: stable@vger.kernel.org # 6.6
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20240911115253.10920-3-johan+linaro@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Commit 413db06c05 ("phy: qcom-qmp-usb: clean up probe initialisation")
removed most users of the platform device driver data, but mistakenly
also removed the initialisation despite the data still being used in the
runtime PM callbacks.
Restore the driver data initialisation at probe to avoid a NULL-pointer
dereference on runtime suspend.
Apparently no one uses runtime PM, which currently needs to be enabled
manually through sysfs, with this driver.
Fixes: 413db06c05 ("phy: qcom-qmp-usb: clean up probe initialisation")
Cc: stable@vger.kernel.org # 6.2
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20240911115253.10920-2-johan+linaro@kernel.org
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>
Pull phy updates from Vinod Koul:
"New hw support:
- Rcar usb2 support for RZ/G3S SoC
- Nuvoton MA35 SoC USB 2.0 PHY driver
Removed:
- obsolete qcom,usb-8x16-phy bindings
Updates:
- 4 lane PCIe support for Qualcomm X1E80100
- Constify structure in subsystem update
- Subsystem simplification with scoped for each OF child loop update
- Yaml conversion for Qualcomm sata phy, Hiilicon hi3798cv200-combphy
bindings"
* tag 'phy-for-6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy: (40 commits)
phy: renesas: rcar-gen3-usb2: Add support for the RZ/G3S SoC
dt-bindings: phy: renesas,usb2-phy: Document RZ/G3S phy bindings
phy: renesas: rcar-gen3-usb2: Add support to initialize the bus
phy: ti: j721e-wiz: Simplify with scoped for each OF child loop
phy: ti: j721e-wiz: Drop OF node reference earlier for simpler code
phy: ti: gmii-sel: Simplify with dev_err_probe()
phy: ti: am654-serdes: Use scoped device node handling to simplify error paths
phy: qcom: qmp-pcie-msm8996: Simplify with scoped for each OF child loop
phy: mediatek: xsphy: Simplify with scoped for each OF child loop
phy: mediatek: tphy: Simplify with scoped for each OF child loop
phy: hisilicon: usb2: Simplify with scoped for each OF child loop
phy: cadence: sierra: Simplify with scoped for each OF child loop
phy: broadcom: brcm-sata: Simplify with scoped for each OF child loop
phy: broadcom: bcm-cygnus-pcie: Simplify with scoped for each OF child loop
phy: nuvoton: add new driver for the Nuvoton MA35 SoC USB 2.0 PHY
dt-bindings: phy: nuvoton,ma35-usb2-phy: add new bindings
phy: qcom: qmp-pcie: Configure all tables on port B PHY
phy: airoha: adjust initialization delay in airoha_pcie_phy_init()
dt-bindings: phy: socionext,uniphier: add top-level constraints
phy: qcom: qmp-pcie: Add Gen4 4-lanes mode for X1E80100
...
Pull power supply and reset updates from Sebastian Reichel:
"Power-supply core:
- introduce power_supply_show_enum_with_available() helper
- change usb_types from an array into a bitmask
- fix early usage of power_supply_property_is_writeable() resulting
in sysfs files not being writable
- fix missing temp1_max_alarm attribute in power-supply's hwmon
devices
Drivers:
- max1720x: expose nvmem device
- brcmstb: cleanup driver to use latest APIs
- max77693: expose input and charging current limit
- max17042_battery: fix state of charge reading for devices without
current sensing
- axp20x_battery: add AXP717 support
- axp20x_battery: fix min/max voltage properties
- axp20x_usb_power: add AXP717 support
- axp20x_usb_power: add DT based input current limit
Documentation updates
Misc minor cleanups and fixes"
* tag 'for-v6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: (38 commits)
power: supply: hwmon: Fix missing temp1_max_alarm attribute
power: supply: Drop use_cnt check from power_supply_property_is_writeable()
power: supply: ab8500: Constify struct kobj_type
power: supply: max1720x: fix a double free on error in probe()
power: supply: axp20x_battery: add support for AXP717
power: supply: axp20x_usb_power: Add support for AXP717
dt-bindings: power: supply: axp20x: Add AXP717 compatible
dt-bindings: power: supply: axp20x: Add AXP717 compatible
power: supply: axp20x_usb_power: Fix spelling mistake "reqested" -> "requested"
power: supply: Change usb_types from an array into a bitmask
power: supply: sysfs: Move power_supply_show_enum_with_available() up
power: supply: sysfs: Add power_supply_show_enum_with_available() helper
power: supply: rt9467-charger: Remove "usb_type" property write support
power: supply: ucs1002: Adjust ucs1002_set_usb_type() to accept string values
power: supply: "usb_type" property may be written to
power: supply: max1720x: add read support for nvmem
mfd: axp20x: Add ADC, BAT, and USB cells for AXP717
power: supply: core: constify psy_tzd_ops
power: reset: brcmstb: Do not go into infinite loop if reset fails
power: reset: brcmstb: Use devm_register_sys_off_handler()
...
The bit_types array just hold a list of valid enum power_supply_usb_type
values which map to 0 - 9. This can easily be represented as a bitmap.
This reduces the size of struct power_supply_desc and further reduces
the data section size by drivers no longer needing to store the array.
This also unifies how usb_types are handled with charge_behaviours,
which allows power_supply_show_usb_type() to be removed.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20240831142039.28830-7-hdegoede@redhat.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The Renesas RZ/G3S need to initialize the USB BUS before transferring data
due to hardware limitation. As the register that need to be touched for
this is in the address space of the USB PHY, and the UBS PHY need to be
initialized before any other USB drivers handling data transfer, add
support to initialize the USB BUS.
As the USB PHY is probed before any other USB drivers that enables
clocks and de-assert the reset signals and the BUS initialization is done
in the probe phase, we need to add code to de-assert reset signal and
runtime resume the device (which enables its clocks) before accessing
the registers.
As the reset signals are not required by the USB PHY driver for the other
USB PHY hardware variants, the reset signals and runtime PM was handled
only in the function that initialize the USB BUS.
The PHY initialization was done right after runtime PM enable to have
all in place when the PHYs are registered.
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Link: https://lore.kernel.org/r/20240822152801.602318-11-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
On a few Kria KR260 Robotics Starter Kit the PS-GEM SGMII linkup is not
happening after the resume. This is because serdes registers are reset
when FPD is off (in suspend state) and needs to be reprogrammed in the
resume path with the same default initialization as done in the first
stage bootloader psu_init routine.
To address the failure introduce a set of serdes registers to be saved in
the suspend path and then restore it on resume.
Fixes: 4a33bea003 ("phy: zynqmp: Add PHY driver for the Xilinx ZynqMP Gigabit Transceiver")
Signed-off-by: Piyush Mehta <piyush.mehta@amd.com>
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Link: https://lore.kernel.org/r/1722837547-2578381-1-git-send-email-radhey.shyam.pandey@amd.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The HDMI PHY PLL can be used as an alternative dclk source to RK3588 SoC
CRU. It provides more accurate clock rates required by VOP2 to improve
existing support for display modes handling, which is known to be
problematic when dealing with non-integer refresh rates, among others.
It is worth noting this only works for HDMI 2.0 or below, e.g. cannot be
used to support HDMI 2.1 4K@120Hz mode.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20240620-rk3588-hdmiphy-clkprov-v2-4-6a2d2164e508@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
When a new PHY is created via [devm_]phy_create(), the runtime PM for it
is not enabled unless the parent device (which creates the PHY) has its
own runtime PM already enabled.
Move the call to devm_pm_runtime_enable() before devm_phy_create() to
enable runtime PM at PHY core level.
With this change the ->power_on() and ->power_off() callbacks do not
require explicit runtime PM management anymore, since the PHY core
handles that via phy_pm_runtime_{get,put}_sync() when phy_power_on() and
phy_power_off() are invoked.
Hence drop the now unnecessary calls to pm_runtime_resume_and_get() and
pm_runtime_put() helpers.
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20240620-rk3588-hdmiphy-clkprov-v2-2-6a2d2164e508@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The Torrent SERDES can support at most two different protocols (PHY types).
This only mandates that the device-tree sub-nodes used to represent the
configuration should describe links with at-most two different protocols.
The existing implementation however imposes an artificial constraint that
allows only two links (device-tree sub-nodes). As long as at-most two
protocols are chosen, using more than two links to describe them in an
alternating configuration is still a valid configuration of the Torrent
SERDES.
A 3-Link 2-Protocol configuration of the 4-Lane SERDES can be:
Lane 0 => Protocol 1 => Link 1
Lane 1 => Protocol 1 => Link 1
Lane 2 => Protocol 2 => Link 2
Lane 3 => Protocol 1 => Link 3
A 4-Link 2-Protocol configuration of the 4-Lane SERDES can be:
Lane 0 => Protocol 1 => Link 1
Lane 1 => Protocol 2 => Link 2
Lane 2 => Protocol 1 => Link 3
Lane 3 => Protocol 2 => Link 4
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240805092607.143869-1-s-vadapalli@ti.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
According to the CN9100_MPP_information document, CP_SRD4 (comphy 4)
supports 2500 BASE-X and 5000 BASE-R for ETH_PORT1. I was able to test
that 2500 BASE-X is indeed supported. Unfortunately, our HW does not
support 5000 BASE-R, but I assume from the document that it does, so I
set the muxing there too to 0x1.
Signed-off-by: Stefan Eichenberger <eichest@gmail.com>
Link: https://lore.kernel.org/r/20240711131612.98952-1-eichest@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
These register prints are useful to validate the init sequence against the
Qcom internal documentation and also to share with the Qcom hw engineers to
debug issues related to PHY.
Sample debug prints:
qcom-qmp-pcie-phy 1c0e000.phy: Writing Reg: QSERDES_V5_COM_SYSCLK_EN_SEL Offset: 0x0094 Val: 0xd9
qcom-qmp-pcie-phy 1c0e000.phy: Writing Reg: QSERDES_V5_COM_HSCLK_SEL Offset: 0x0158 Val: 0x11
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20240731152548.102987-1-manivannan.sadhasivam@linaro.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
'cdns_sierra_pll_mux_table' is not modified in this driver.
And it is only used as a "const u32 *".
Constifying this structure moves some data to a read-only section, so
increase overall security.
On a x86_64, with allmodconfig:
Before:
======
text data bss dec hex filename
60937 3894 16 64847 fd4f drivers/phy/cadence/phy-cadence-sierra.o
After:
=====
text data bss dec hex filename
60897 3878 16 64791 fd17 drivers/phy/cadence/phy-cadence-sierra.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/43d881d52e3c1632ad197d4c2c18b6c481a13b24.1720723132.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Vinod Koul <vkoul@kernel.org>
'struct cdns_sierra_vals' is not modified in this driver.
Constifying this structure moves some data to a read-only section, so
increase overall security.
On a x86_64, with allmodconfig:
Before:
======
text data bss dec hex filename
60521 4310 16 64847 fd4f drivers/phy/cadence/phy-cadence-sierra.o
After:
=====
text data bss dec hex filename
60937 3894 16 64847 fd4f drivers/phy/cadence/phy-cadence-sierra.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/0ccfd259fdf40475c89cfb22a64c6388e7c646b4.1720723132.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Vinod Koul <vkoul@kernel.org>
'struct cdns_reg_pairs' is not modified in this driver.
Constifying this structure moves some data to a read-only section, so
increase overall security.
On a x86_64, with allmodconfig:
Before:
======
text data bss dec hex filename
60489 4342 16 64847 fd4f drivers/phy/cadence/phy-cadence-sierra.o
After:
=====
text data bss dec hex filename
60521 4310 16 64847 fd4f drivers/phy/cadence/phy-cadence-sierra.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/c57ee8206ebba8c222d7d954335654384072b9ac.1720723132.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Vinod Koul <vkoul@kernel.org>
'cdns_torrent_refclk_driver_mux_table' is not modified in this driver.
And it is only used as a "const u32 *".
Constifying this structure moves some data to a read-only section, so
increase overall security.
On a x86_64, with allmodconfig:
Before:
======
text data bss dec hex filename
93578 4798 16 98392 18058 drivers/phy/cadence/phy-cadence-torrent.o
After:
=====
text data bss dec hex filename
93606 4790 16 98412 1806c drivers/phy/cadence/phy-cadence-torrent.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/34e23ceb6b7b7eb730ee8deee21d231b504dc65f.1720718240.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Vinod Koul <vkoul@kernel.org>
'struct cdns_torrent_vals' is not modified in this driver.
Constifying this structure moves some data to a read-only section, so
increase overall security.
On a x86_64, with allmodconfig:
Before:
======
text data bss dec hex filename
92234 6078 16 98328 18018 drivers/phy/cadence/phy-cadence-torrent.o
After:
=====
text data bss dec hex filename
93578 4798 16 98392 18058 drivers/phy/cadence/phy-cadence-torrent.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/d9d135ee9b806726766a1bc5e1404267939aa637.1720718240.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Vinod Koul <vkoul@kernel.org>
'struct cdns_torrent_vals_entry' is not modified in this driver.
Constifying this structure moves some data to a read-only section, so
increase overall security.
On a x86_64, with allmodconfig:
Before:
======
text data bss dec hex filename
85130 13214 16 98360 18038 drivers/phy/cadence/phy-cadence-torrent.o
After:
=====
text data bss dec hex filename
92234 6078 16 98328 18018 drivers/phy/cadence/phy-cadence-torrent.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/dcc4e539999a840b3fd8f40fd8fd7523390232ac.1720718240.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Vinod Koul <vkoul@kernel.org>
