linux-stable.git/drivers/phy/ti, branch v6.6.78

phy: ti: tusb1210: Resolve charger-det crash if charger psy is unregistered

2024-05-02T14:32:49+00:00

[ Upstream commit bf6e4ee5c43690e4c5a8a057bbcd4ff986bed052 ]

The power_supply frame-work is not really designed for there to be
long living in kernel references to power_supply devices.

Specifically unregistering a power_supply while some other code has
a reference to it triggers a WARN in power_supply_unregister():

	WARN_ON(atomic_dec_return(&psy->use_cnt));

Folllowed by the power_supply still getting removed and the
backing data freed anyway, leaving the tusb1210 charger-detect code
with a dangling reference, resulting in a crash the next time
tusb1210_get_online() is called.

Fix this by only holding the reference in tusb1210_get_online()
freeing it at the end of the function. Note this still leaves
a theoretical race window, but it avoids the issue when manually
rmmod-ing the charger chip driver during development.

Fixes: 48969a5623ed ("phy: ti: tusb1210: Add charger detection")
Signed-off-by: Hans de Goede 
Link: https://lore.kernel.org/r/20240406140821.18624-1-hdegoede@redhat.com
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP

2024-02-16T18:10:42+00:00

[ Upstream commit 7104ba0f1958adb250319e68a15eff89ec4fd36d ]

If the external phy working together with phy-omap-usb2 does not implement
send_srp(), we may still attempt to call it. This can happen on an idle
Ethernet gadget triggering a wakeup for example:

configfs-gadget.g1 gadget.0: ECM Suspend
configfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup
...
Unable to handle kernel NULL pointer dereference at virtual address
00000000 when execute
...
PC is at 0x0
LR is at musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc]
...
musb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core]
usb_gadget_wakeup [udc_core] from eth_start_xmit+0x3b0/0x3d4 [u_ether]
eth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24c
dev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4
sch_direct_xmit from __dev_queue_xmit+0x334/0xd88
__dev_queue_xmit from arp_solicit+0xf0/0x268
arp_solicit from neigh_probe+0x54/0x7c
neigh_probe from __neigh_event_send+0x22c/0x47c
__neigh_event_send from neigh_resolve_output+0x14c/0x1c0
neigh_resolve_output from ip_finish_output2+0x1c8/0x628
ip_finish_output2 from ip_send_skb+0x40/0xd8
ip_send_skb from udp_send_skb+0x124/0x340
udp_send_skb from udp_sendmsg+0x780/0x984
udp_sendmsg from __sys_sendto+0xd8/0x158
__sys_sendto from ret_fast_syscall+0x0/0x58

Let's fix the issue by checking for send_srp() and set_vbus() before
calling them. For USB peripheral only cases these both could be NULL.

Fixes: 657b306a7bdf ("usb: phy: add a new driver for omap usb2 phy")
Signed-off-by: Tony Lindgren 
Link: https://lore.kernel.org/r/20240128120556.8848-1-tony@atomide.com
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

phy: ti: gmii-sel: Fix register offset when parent is not a syscon node

2024-01-10T16:16:56+00:00

[ Upstream commit 0f40d5099cd6d828fd7de6227d3eabe86016724c ]

When the node for this phy selector is a child node of a syscon node then the
property 'reg' is used as an offset into the parent regmap. When the node
is standalone and gets its own regmap this offset is pre-applied. So we need
to track which method was used to get the regmap and not apply the offset
in the standalone case.

Fixes: 1fdfa7cccd35 ("phy: ti: gmii-sel: Allow parent to not be syscon node")
Signed-off-by: Andrew Davis 
Reviewed-by: Roger Quadros 
Link: https://lore.kernel.org/r/20231025143302.1265633-1-afd@ti.com
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

phy: Explicitly include correct DT includes

2023-07-17T06:22:56+00:00

The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.

Signed-off-by: Rob Herring 
Acked-by: Marc Kleine-Budde  # for drivers/phy/phy-can-transceiver.c
Acked-by: Heiko Stuebner 
Acked-by: Sergio Paracuellos 
Link: https://lore.kernel.org/r/20230714174841.4061919-1-robh@kernel.org
Signed-off-by: Vinod Koul

phy: ti: gmii-sel: Allow parent to not be syscon node

2023-07-14T12:54:31+00:00

If the parent node is not a syscon type, then fallback and check
if we can get a regmap from our own node. This no longer forces
us to make the parent of this node a syscon node when that might
not be appropriate.

Signed-off-by: Andrew Davis 
Reviewed-by: Roger Quadros 
Reviewed-by: Siddharth Vadapalli 
Link: https://lore.kernel.org/r/20230713200957.134480-1-afd@ti.com
Signed-off-by: Vinod Koul

Merge tag 'phy-for-6.5_v2' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy

2023-07-06T04:38:13+00:00

Pull phy updates from Vinod Koul:
 "New Support:
   - Debugfs support for phy core and mediatek driver
   - Hisilicon inno-usb2-phy driver supporting Hi3798MV100
   - Qualcomm SGMII SerDes PHY driver, SM6115 & QCM2290 QMP-USB support,
     SA8775P USB PHY & USB3 UNI support, QUSB2 support for IPQ9574,
     IPQ9574 USB3 PHY

  UpdatesL
   - Sparx5 serdes phy power optimzation
   - cadence salvo usb properties and updates and torrent DP with PCIe &
     USB support
   - Yaml conversion for Broadcom kona USB bindings and MXS USB binding"

* tag 'phy-for-6.5_v2' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy: (67 commits)
  dt-bindings: phy: brcm,brcmstb-usb-phy: Fix error in "compatible" conditional schema
  dt-bindings: phy: mixel,mipi-dsi-phy: Remove assigned-clock* properties
  dt-bindings: phy: intel,combo-phy: restrict node name suffixes
  dt-bindings: phy: qcom,usb-hs-phy: Add compatible
  phy: tegra: xusb: check return value of devm_kzalloc()
  phy: qcom: qmp-combo: fix Display Port PHY configuration for SM8550
  phy: qcom: add the SGMII SerDes PHY driver
  dt-bindings: phy: describe the Qualcomm SGMII PHY
  phy: qualcomm: fix indentation in Makefile
  phy: usb: suppress OC condition for 7439b2
  phy: usb: Turn off phy when port is in suspend
  phy: tegra: xusb: Clear the driver reference in usb-phy dev
  dt-bindings: phy: mxs-usb-phy: add imx8ulp and imx8qm compatible
  dt-bindings: phy: mxs-usb-phy: convert to DT schema format
  dt-bindings: phy: qcom,qmp-usb: fix bindings error
  dt-bindings: phy: qcom,qmp-ufs: fix the sc8180x regs
  dt-bindings: phy: qcom,qmp-pcie: fix the sc8180x regs
  phy: mediatek: tphy: add debugfs files
  phy: core: add debugfs files
  phy: fsl-imx8mp-usb: add support for phy tuning
  ...

phy: ti: j721e-wiz: Add a determine_rate hook

2023-06-09T01:39:32+00:00

The TI J721e Wiz clock implements a mux with a set_parent
hook, but doesn't provide a determine_rate implementation.

This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to clk_set_rate(), with
determine_rate() figuring out which parent is the best suited for a
given rate.

The other trigger would be a call to clk_set_parent(), but it's far less
used, and it doesn't look like there's any obvious user for that clock.

So, the set_parent hook is effectively unused, possibly because of an
oversight. However, it could also be an explicit decision by the
original author to avoid any reparenting but through an explicit call to
clk_set_parent().

The latter case would be equivalent to setting the flag
CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook
to __clk_mux_determine_rate(). Indeed, if no determine_rate
implementation is provided, clk_round_rate() (through
clk_core_round_rate_nolock()) will call itself on the parent if
CLK_SET_RATE_PARENT is set, and will not change the clock rate
otherwise.

And if it was an oversight, then we are at least explicit about our
behavior now and it can be further refined down the line.

Since the CLK_SET_RATE_NO_REPARENT flag was already set though, it seems
unlikely.

Cc: Kishon Vijay Abraham I 
Cc: Vinod Koul 
Cc: linux-phy@lists.infradead.org
Signed-off-by: Maxime Ripard 
Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-44-971d5077e7d2@cerno.tech
Signed-off-by: Stephen Boyd

phy: ti: am654-serdes: Add a determine_rate hook

2023-06-09T01:39:31+00:00

The TI AM654 SerDes clock implements a mux with a set_parent
hook, but doesn't provide a determine_rate implementation.

This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to clk_set_rate(), with
determine_rate() figuring out which parent is the best suited for a
given rate.

The other trigger would be a call to clk_set_parent(), but it's far less
used, and it doesn't look like there's any obvious user for that clock.

So, the set_parent hook is effectively unused, possibly because of an
oversight. However, it could also be an explicit decision by the
original author to avoid any reparenting but through an explicit call to
clk_set_parent().

The latter case would be equivalent to setting the flag
CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook
to __clk_mux_determine_rate(). Indeed, if no determine_rate
implementation is provided, clk_round_rate() (through
clk_core_round_rate_nolock()) will call itself on the parent if
CLK_SET_RATE_PARENT is set, and will not change the clock rate
otherwise.

And if it was an oversight, then we are at least explicit about our
behavior now and it can be further refined down the line.

Since the CLK_SET_RATE_NO_REPARENT flag was already set though, it seems
unlikely.

Cc: Kishon Vijay Abraham I 
Cc: Vinod Koul 
Cc: linux-phy@lists.infradead.org
Signed-off-by: Maxime Ripard 
Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-43-971d5077e7d2@cerno.tech
Signed-off-by: Stephen Boyd

phy: ti: gmii-sel: Enable USXGMII mode for J784S4

2023-05-16T14:31:44+00:00

TI's J784S4 SoC supports USXGMII mode with the CPSW9G instance's MAC
ports 1 and 2. Add USXGMII mode to the extra_modes member of J784S4's
SoC data.

Signed-off-by: Siddharth Vadapalli 
Reviewed-by: Roger Quadros 
Link: https://lore.kernel.org/r/20230331062521.529005-3-s-vadapalli@ti.com
Signed-off-by: Vinod Koul

phy: ti: gmii-sel: Add support for CPSW9G GMII SEL in J784S4

2023-05-16T14:31:43+00:00

Each of the CPSW9G ports in TI's J784S4 SoC support modes such as QSGMII.

Add a new compatible for it and allow the usage of "ti,qsgmii-main-ports"
property for J784S4.

Signed-off-by: Siddharth Vadapalli 
Reviewed-by: Roger Quadros 
Link: https://lore.kernel.org/r/20230331062521.529005-2-s-vadapalli@ti.com
Signed-off-by: Vinod Koul