| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 25 Jun 2024 11:46:55 -0500
From: Andrew Davis <afd@...com>
To: Jan Kiszka <jan.kiszka@...mens.com>, Nishanth Menon <nm@...com>,
Vignesh
Raghavendra <vigneshr@...com>,
Tero Kristo <kristo@...nel.org>, Rob Herring
<robh+dt@...nel.org>,
Krzysztof Kozlowski
<krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>
CC: <linux-arm-kernel@...ts.infradead.org>, <devicetree@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] arm64: dts: ti: k3-am65: Move SerDes mux nodes under
the control node
On 6/24/24 12:13 AM, Jan Kiszka wrote:
> On 15.06.24 09:35, Jan Kiszka wrote:
>> On 14.06.24 18:19, Andrew Davis wrote:
>>> On 6/14/24 2:44 AM, Jan Kiszka wrote:
>>>> On 26.03.24 19:56, Andrew Davis wrote:
>>>>> These SerDes lane select muxes use bits from the same register as
>>>>> the SerDes clock select mux. Make the lane select mux a child
>>>>> of the SerDes control node.
>>>>>
>>>>> This removes one more requirement on scm-conf being a syscon node
>>>>> which will later be converted to fix a couple DTS check warnings.
>>>>>
>>>>> Signed-off-by: Andrew Davis <afd@...com>
>>>>> ---
>>>>> arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 21 +++++++++++++--------
>>>>> 1 file changed, 13 insertions(+), 8 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>>>>> b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>>>>> index 738c5c4acbcd2..5ce67e6a33600 100644
>>>>> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>>>>> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>>>>> @@ -66,7 +66,7 @@ serdes0: serdes@...000 {
>>>>> assigned-clock-parents = <&k3_clks 153 8>, <&k3_clks 153 4>;
>>>>> ti,serdes-clk = <&serdes0_clk>;
>>>>> #clock-cells = <1>;
>>>>> - mux-controls = <&serdes_mux 0>;
>>>>> + mux-controls = <&serdes0_mux 0>;
>>>>> };
>>>>> serdes1: serdes@...000 {
>>>>> @@ -81,7 +81,7 @@ serdes1: serdes@...000 {
>>>>> assigned-clock-parents = <&k3_clks 154 9>, <&k3_clks 154 5>;
>>>>> ti,serdes-clk = <&serdes1_clk>;
>>>>> #clock-cells = <1>;
>>>>> - mux-controls = <&serdes_mux 1>;
>>>>> + mux-controls = <&serdes1_mux 0>;
>>>>> };
>>>>> main_uart0: serial@...0000 {
>>>>> @@ -485,18 +485,23 @@ scm_conf: scm-conf@...000 {
>>>>> serdes0_clk: clock@...0 {
>>>>> compatible = "ti,am654-serdes-ctrl", "syscon";
>>>>> reg = <0x4080 0x4>;
>>>>> +
>>>>> + serdes0_mux: mux-controller {
>>>>> + compatible = "mmio-mux";
>>>>> + #mux-control-cells = <1>;
>>>>> + mux-reg-masks = <0x0 0x3>; /* lane select */
>>>>> + };
>>>>> };
>>>>> serdes1_clk: clock@...0 {
>>>>> compatible = "ti,am654-serdes-ctrl", "syscon";
>>>>> reg = <0x4090 0x4>;
>>>>> - };
>>>>> - serdes_mux: mux-controller {
>>>>> - compatible = "mmio-mux";
>>>>> - #mux-control-cells = <1>;
>>>>> - mux-reg-masks = <0x4080 0x3>, /* SERDES0 lane select */
>>>>> - <0x4090 0x3>; /* SERDES1 lane select */
>>>>> + serdes1_mux: mux-controller {
>>>>> + compatible = "mmio-mux";
>>>>> + #mux-control-cells = <1>;
>>>>> + mux-reg-masks = <0x0 0x3>; /* lane select */
>>>>> + };
>>>>> };
>>>>> dss_oldi_io_ctrl: dss-oldi-io-ctrl@...0 {
>>>>
>>>> This change breaks serdes setup on the IOT2050 SM (k3-am6548-iot2050-
>>>> advanced-sm.dts), possibly on more of our devices as well:
>>>>
>>>> platform 5500000.pcie: deferred probe pending: platform: supplier
>>>> 900000.serdes not ready
>>>> platform 900000.serdes: deferred probe pending: (reason unknown)
>>>>
>>>> And PCI remains unavailable. Digging a bit into it, it seems the change
>>>> is causing a circular consumer/provider dependency between serdes0 and
>>>> serdes1:
>>>>
>>>> root@...2050-debian:~# ls -l /sys/bus/platform/devices/900000.serdes/
>>>> total 0
>>>> lrwxrwxrwx 1 root root 0 Jun 14 07:10
>>>> consumer:platform:5500000.pcie ->
>>>> ../../../virtual/devlink/platform:900000.serdes--platform:5500000.pcie
>>>> lrwxrwxrwx 1 root root 0 Jun 14 07:10
>>>> consumer:platform:910000.serdes ->
>>>> ../../../virtual/devlink/platform:900000.serdes--platform:910000.serdes
>>>> -rw-r--r-- 1 root root 4096 Jun 14 07:10 driver_override
>>>> -r--r--r-- 1 root root 4096 Jun 14 07:10 modalias
>>>> lrwxrwxrwx 1 root root 0 Jun 14 07:10 of_node ->
>>>> ../../../../firmware/devicetree/base/bus@...000/serdes@...000
>>>> drwxr-xr-x 2 root root 0 Jun 14 07:10 power
>>>> lrwxrwxrwx 1 root root 0 Jun 14 07:00 subsystem ->
>>>> ../../../../bus/platform
>>>> lrwxrwxrwx 1 root root 0 Jun 14 07:10
>>>> supplier:platform:44083000.system-controller:clock-controller ->
>>>> ../../../virtual/devlink/platform:44083000.system-controller:clock-controller--platform:900000.serdes
>>>> lrwxrwxrwx 1 root root 0 Jun 14 07:10
>>>> supplier:platform:44083000.system-controller:power-controller ->
>>>> ../../../virtual/devlink/platform:44083000.system-controller:power-controller--platform:900000.serdes
>>>> lrwxrwxrwx 1 root root 0 Jun 14 07:10
>>>> supplier:platform:910000.serdes ->
>>>> ../../../virtual/devlink/platform:910000.serdes--platform:900000.serdes
>>>> -rw-r--r-- 1 root root 4096 Jun 14 07:00 uevent
>>>> -r--r--r-- 1 root root 4096 Jun 14 07:10 waiting_for_supplier
>>>> root@...2050-debian:~# ls -l /sys/bus/platform/devices/910000.serdes/
>>>> total 0
>>>> lrwxrwxrwx 1 root root 0 Jun 14 07:14
>>>> consumer:platform:900000.serdes ->
>>>> ../../../virtual/devlink/platform:910000.serdes--platform:900000.serdes
>>>> -rw-r--r-- 1 root root 4096 Jun 14 07:14 driver_override
>>>> -r--r--r-- 1 root root 4096 Jun 14 07:14 modalias
>>>> lrwxrwxrwx 1 root root 0 Jun 14 07:14 of_node ->
>>>> ../../../../firmware/devicetree/base/bus@...000/serdes@...000
>>>> drwxr-xr-x 2 root root 0 Jun 14 07:14 power
>>>> lrwxrwxrwx 1 root root 0 Jun 14 07:00 subsystem ->
>>>> ../../../../bus/platform
>>>> lrwxrwxrwx 1 root root 0 Jun 14 07:14
>>>> supplier:platform:44083000.system-controller:clock-controller ->
>>>> ../../../virtual/devlink/platform:44083000.system-controller:clock-controller--platform:910000.serdes
>>>> lrwxrwxrwx 1 root root 0 Jun 14 07:14
>>>> supplier:platform:44083000.system-controller:power-controller ->
>>>> ../../../virtual/devlink/platform:44083000.system-controller:power-controller--platform:910000.serdes
>>>> lrwxrwxrwx 1 root root 0 Jun 14 07:14
>>>> supplier:platform:900000.serdes ->
>>>> ../../../virtual/devlink/platform:900000.serdes--platform:910000.serdes
>>>> -rw-r--r-- 1 root root 4096 Jun 14 07:00 uevent
>>>> -r--r--r-- 1 root root 4096 Jun 14 07:14 waiting_for_supplier
>>>>
>>>> Note that we normally disable serdes1 on this device as it was not
>>>> required so far. Enabling the node does not solve the issue, though:
>>>>
>>>> platform 5500000.pcie: deferred probe pending: platform: supplier
>>>> 900000.serdes not ready
>>>> platform 900000.serdes: deferred probe pending: (reason unknown)
>>>> platform 910000.serdes: deferred probe pending: (reason unknown)
>>>>
>>>
>>> Thanks for the report, I think I know the issue and can
>>> send the fix here in a bit. In the mean time, could you
>>> see if the following fixes the issue (this isn't fully
>>> correct and will cause a new DTB check warning, but will
>>> let me verify the issue):
>>>
>>> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>>> b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>>> index 1af3dedde1f67..06ed74197f893 100644
>>> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>>> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>>> @@ -478,7 +478,7 @@ scm_conf: scm-conf@...000 {
>>> ranges = <0x0 0x0 0x00100000 0x1c000>;
>>>
>>> serdes0_clk: clock@...0 {
>>> - compatible = "ti,am654-serdes-ctrl", "syscon";
>>> + compatible = "ti,am654-serdes-ctrl", "syscon",
>>> "simple-mfd";
>>> reg = <0x4080 0x4>;
>>>
>>> serdes0_mux: mux-controller {
>>> @@ -489,7 +489,7 @@ serdes0_mux: mux-controller {
>>> };
>>>
>>> serdes1_clk: clock@...0 {
>>> - compatible = "ti,am654-serdes-ctrl", "syscon";
>>> + compatible = "ti,am654-serdes-ctrl", "syscon",
>>> "simple-mfd";
>>> reg = <0x4090 0x4>;
>>>
>>> serdes1_mux: mux-controller {
>>>
>>
>> Yes, this works.
>>
>
> Did I miss the real fix, or is it still under development?
I was on travel last week, just sent the fix now with you on CC.
Andrew
>
> Jan
>
Powered by blists - more mailing lists