This reverts commit 1e35f074399dece73d5df11847d4a0d7a6f49434.
Given that ERROR_RECOVERY calls into PORT_RESET for Hi-Zing
the CC pins, setting CC pins to default state during PORT_RESET
breaks error recovery.
4.5.2.2.2.1 ErrorRecovery State Requirements
The port shall not drive VBUS or VCONN, and shall present a
high-impedance to ground (above zOPEN) on its CC1 and CC2 pins.
Hi-Zing the CC pins is the inteded behavior for PORT_RESET.
CC pins are set to default state after tErrorRecovery in
PORT_RESET_WAIT_OFF.
4.5.2.2.2.2 Exiting From ErrorRecovery State
A Sink shall transition to Unattached.SNK after tErrorRecovery.
A Source shall transition to Unattached.SRC after tErrorRecovery.
Cc: [email protected]
Cc: Frank Wang <[email protected]>
Fixes: 1e35f074399d ("usb: typec: tcpm: fix cc role at port reset")
Signed-off-by: Badhri Jagan Sridharan <[email protected]>
---
drivers/usb/typec/tcpm/tcpm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
index 5945e3a2b0f7..9d410718eaf4 100644
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -4876,8 +4876,7 @@ static void run_state_machine(struct tcpm_port *port)
break;
case PORT_RESET:
tcpm_reset_port(port);
- tcpm_set_cc(port, tcpm_default_state(port) == SNK_UNATTACHED ?
- TYPEC_CC_RD : tcpm_rp_cc(port));
+ tcpm_set_cc(port, TYPEC_CC_OPEN);
tcpm_set_state(port, PORT_RESET_WAIT_OFF,
PD_T_ERROR_RECOVERY);
break;
base-commit: 933bb7b878ddd0f8c094db45551a7daddf806e00
--
2.43.0.429.g432eaa2c6b-goog
On 1/17/24 03:47, Badhri Jagan Sridharan wrote:
> This reverts commit 1e35f074399dece73d5df11847d4a0d7a6f49434.
>
> Given that ERROR_RECOVERY calls into PORT_RESET for Hi-Zing
> the CC pins, setting CC pins to default state during PORT_RESET
> breaks error recovery.
>
> 4.5.2.2.2.1 ErrorRecovery State Requirements
> The port shall not drive VBUS or VCONN, and shall present a
> high-impedance to ground (above zOPEN) on its CC1 and CC2 pins.
>
> Hi-Zing the CC pins is the inteded behavior for PORT_RESET.
intended
> CC pins are set to default state after tErrorRecovery in
> PORT_RESET_WAIT_OFF.
>
> 4.5.2.2.2.2 Exiting From ErrorRecovery State
> A Sink shall transition to Unattached.SNK after tErrorRecovery.
> A Source shall transition to Unattached.SRC after tErrorRecovery.
>
Makes sense to me.
Reviewed-by: Guenter Roeck <[email protected]>
> Cc: [email protected]
> Cc: Frank Wang <[email protected]>
> Fixes: 1e35f074399d ("usb: typec: tcpm: fix cc role at port reset")
> Signed-off-by: Badhri Jagan Sridharan <[email protected]>
> ---
> drivers/usb/typec/tcpm/tcpm.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index 5945e3a2b0f7..9d410718eaf4 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -4876,8 +4876,7 @@ static void run_state_machine(struct tcpm_port *port)
> break;
> case PORT_RESET:
> tcpm_reset_port(port);
> - tcpm_set_cc(port, tcpm_default_state(port) == SNK_UNATTACHED ?
> - TYPEC_CC_RD : tcpm_rp_cc(port));
> + tcpm_set_cc(port, TYPEC_CC_OPEN);
> tcpm_set_state(port, PORT_RESET_WAIT_OFF,
> PD_T_ERROR_RECOVERY);
> break;
>
> base-commit: 933bb7b878ddd0f8c094db45551a7daddf806e00
Hi,
On Wed, Jan 17, 2024 at 11:47:42AM +0000, Badhri Jagan Sridharan wrote:
> This reverts commit 1e35f074399dece73d5df11847d4a0d7a6f49434.
>
> Given that ERROR_RECOVERY calls into PORT_RESET for Hi-Zing
> the CC pins, setting CC pins to default state during PORT_RESET
> breaks error recovery.
>
> 4.5.2.2.2.1 ErrorRecovery State Requirements
> The port shall not drive VBUS or VCONN, and shall present a
> high-impedance to ground (above zOPEN) on its CC1 and CC2 pins.
>
> Hi-Zing the CC pins is the inteded behavior for PORT_RESET.
> CC pins are set to default state after tErrorRecovery in
> PORT_RESET_WAIT_OFF.
>
> 4.5.2.2.2.2 Exiting From ErrorRecovery State
> A Sink shall transition to Unattached.SNK after tErrorRecovery.
> A Source shall transition to Unattached.SRC after tErrorRecovery.
>
> Cc: [email protected]
> Cc: Frank Wang <[email protected]>
> Fixes: 1e35f074399d ("usb: typec: tcpm: fix cc role at port reset")
> Signed-off-by: Badhri Jagan Sridharan <[email protected]>
> ---
> drivers/usb/typec/tcpm/tcpm.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index 5945e3a2b0f7..9d410718eaf4 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -4876,8 +4876,7 @@ static void run_state_machine(struct tcpm_port *port)
> break;
> case PORT_RESET:
> tcpm_reset_port(port);
> - tcpm_set_cc(port, tcpm_default_state(port) == SNK_UNATTACHED ?
> - TYPEC_CC_RD : tcpm_rp_cc(port));
> + tcpm_set_cc(port, TYPEC_CC_OPEN);
> tcpm_set_state(port, PORT_RESET_WAIT_OFF,
> PD_T_ERROR_RECOVERY);
> break;
G?bor had some concerns with this in v1.
thanks,
--
heikki
On Wed, Jan 17, 2024 at 11:47:42AM +0000, Badhri Jagan Sridharan wrote:
> This reverts commit 1e35f074399dece73d5df11847d4a0d7a6f49434.
>
> Given that ERROR_RECOVERY calls into PORT_RESET for Hi-Zing
> the CC pins, setting CC pins to default state during PORT_RESET
> breaks error recovery.
Between -rc2 and -rc3 I started seeing boot issues in mainline on
rk3399-roc-pc running arm64 defconfig, a bisection identified this patch
as having broken things. The issues manifest as a hang while loading
modules from the initd, you can see a full boot log at:
https://lava.sirena.org.uk/scheduler/job/558789
which shows a bunch of video drivers loading at the end of the log but I
suspect that's not related the actual failure. A successful boot can be
seen here:
https://lava.sirena.org.uk/scheduler/job/559222
I do note that the board is powered by USB PD, I've got it connected to
a PD power supply which seems potentially relevant to the commit. The
board had been working for a long time, at least as far as boot to
initrd goes.
Full bisect log:
git bisect start
# status: waiting for both good and bad commits
# bad: [54be6c6c5ae8e0d93a6c4641cb7528eb0b6ba478] Linux 6.8-rc3
git bisect bad 54be6c6c5ae8e0d93a6c4641cb7528eb0b6ba478
# status: waiting for good commit(s), bad commit known
# good: [41bccc98fb7931d63d03f326a746ac4d429c1dd3] Linux 6.8-rc2
git bisect good 41bccc98fb7931d63d03f326a746ac4d429c1dd3
# good: [4f18d3fd2975c943be91522d86257806374881b9] Merge tag 'iommu-fixes-v6.8-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu
git bisect good 4f18d3fd2975c943be91522d86257806374881b9
# good: [6b89b6af459fdd6f2741d0c2e33c67af8193697e] Merge tag 'gfs2-v6.8-rc2-revert' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2
git bisect good 6b89b6af459fdd6f2741d0c2e33c67af8193697e
# good: [bdda52cc664caaf030fdaf51dd715ef5d1f14a26] Merge tag 'i2c-for-6.8-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
git bisect good bdda52cc664caaf030fdaf51dd715ef5d1f14a26
# bad: [0214960971939697f1499239398874cfc3a52d69] Merge tag 'tty-6.8-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
git bisect bad 0214960971939697f1499239398874cfc3a52d69
# bad: [3caf2b2ad7334ef35f55b95f3e1b138c6f77b368] usb: ulpi: Fix debugfs directory leak
git bisect bad 3caf2b2ad7334ef35f55b95f3e1b138c6f77b368
# good: [7c4650ded49e5b88929ecbbb631efb8b0838e811] xhci: handle isoc Babble and Buffer Overrun events properly
git bisect good 7c4650ded49e5b88929ecbbb631efb8b0838e811
# good: [cc509b6a47e7c8998d9e41c273191299d5d9d631] usb: chipidea: core: handle power lost in workqueue
git bisect good cc509b6a47e7c8998d9e41c273191299d5d9d631
# good: [b2d2d7ea0dd09802cf5a0545bf54d8ad8987d20c] usb: f_mass_storage: forbid async queue when shutdown happen
git bisect good b2d2d7ea0dd09802cf5a0545bf54d8ad8987d20c
# bad: [b717dfbf73e842d15174699fe2c6ee4fdde8aa1f] Revert "usb: typec: tcpm: fix cc role at port reset"
git bisect bad b717dfbf73e842d15174699fe2c6ee4fdde8aa1f
# good: [032178972f8e992b90f9794a13265fec8c8314b0] usb: gadget: pch_udc: fix an Excess kernel-doc warning
git bisect good 032178972f8e992b90f9794a13265fec8c8314b0
# first bad commit: [b717dfbf73e842d15174699fe2c6ee4fdde8aa1f] Revert "usb: typec: tcpm: fix cc role at port reset"
On 08.02.24 23:01, Mark Brown wrote:
> On Wed, Jan 17, 2024 at 11:47:42AM +0000, Badhri Jagan Sridharan wrote:
>> This reverts commit 1e35f074399dece73d5df11847d4a0d7a6f49434.
>>
>> Given that ERROR_RECOVERY calls into PORT_RESET for Hi-Zing
>> the CC pins, setting CC pins to default state during PORT_RESET
>> breaks error recovery.
>
> Between -rc2 and -rc3 I started seeing boot issues in mainline on
> rk3399-roc-pc running arm64 defconfig, a bisection identified this patch
> as having broken things. The issues manifest as a hang while loading
> modules from the initd, you can see a full boot log at:
Thanks for the report. To be sure the issue doesn't fall through the
cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
tracking bot:
#regzbot ^introduced b717dfbf73e842d15174699fe2c6ee4fdde8a
#regzbot title usb: typec: boot issues on rk3399-roc-pc due to revert
#regzbot ignore-activity
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
That page also explains what to do if mails like this annoy you.
That's exactly what I predicted would happen.
Mark Brown <[email protected]> ezt írta (időpont: 2024. febr. 8., Cs, 23:03):
>
> On Wed, Jan 17, 2024 at 11:47:42AM +0000, Badhri Jagan Sridharan wrote:
> > This reverts commit 1e35f074399dece73d5df11847d4a0d7a6f49434.
> >
> > Given that ERROR_RECOVERY calls into PORT_RESET for Hi-Zing
> > the CC pins, setting CC pins to default state during PORT_RESET
> > breaks error recovery.
>
> Between -rc2 and -rc3 I started seeing boot issues in mainline on
> rk3399-roc-pc running arm64 defconfig, a bisection identified this patch
> as having broken things. The issues manifest as a hang while loading
> modules from the initd, you can see a full boot log at:
>
> https://lava.sirena.org.uk/scheduler/job/558789
>
> which shows a bunch of video drivers loading at the end of the log but I
> suspect that's not related the actual failure. A successful boot can be
> seen here:
>
> https://lava.sirena.org.uk/scheduler/job/559222
>
> I do note that the board is powered by USB PD, I've got it connected to
> a PD power supply which seems potentially relevant to the commit. The
> board had been working for a long time, at least as far as boot to
> initrd goes.
>
> Full bisect log:
>
> git bisect start
> # status: waiting for both good and bad commits
> # bad: [54be6c6c5ae8e0d93a6c4641cb7528eb0b6ba478] Linux 6.8-rc3
> git bisect bad 54be6c6c5ae8e0d93a6c4641cb7528eb0b6ba478
> # status: waiting for good commit(s), bad commit known
> # good: [41bccc98fb7931d63d03f326a746ac4d429c1dd3] Linux 6.8-rc2
> git bisect good 41bccc98fb7931d63d03f326a746ac4d429c1dd3
> # good: [4f18d3fd2975c943be91522d86257806374881b9] Merge tag 'iommu-fixes-v6.8-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu
> git bisect good 4f18d3fd2975c943be91522d86257806374881b9
> # good: [6b89b6af459fdd6f2741d0c2e33c67af8193697e] Merge tag 'gfs2-v6.8-rc2-revert' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2
> git bisect good 6b89b6af459fdd6f2741d0c2e33c67af8193697e
> # good: [bdda52cc664caaf030fdaf51dd715ef5d1f14a26] Merge tag 'i2c-for-6.8-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
> git bisect good bdda52cc664caaf030fdaf51dd715ef5d1f14a26
> # bad: [0214960971939697f1499239398874cfc3a52d69] Merge tag 'tty-6.8-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
> git bisect bad 0214960971939697f1499239398874cfc3a52d69
> # bad: [3caf2b2ad7334ef35f55b95f3e1b138c6f77b368] usb: ulpi: Fix debugfs directory leak
> git bisect bad 3caf2b2ad7334ef35f55b95f3e1b138c6f77b368
> # good: [7c4650ded49e5b88929ecbbb631efb8b0838e811] xhci: handle isoc Babble and Buffer Overrun events properly
> git bisect good 7c4650ded49e5b88929ecbbb631efb8b0838e811
> # good: [cc509b6a47e7c8998d9e41c273191299d5d9d631] usb: chipidea: core: handle power lost in workqueue
> git bisect good cc509b6a47e7c8998d9e41c273191299d5d9d631
> # good: [b2d2d7ea0dd09802cf5a0545bf54d8ad8987d20c] usb: f_mass_storage: forbid async queue when shutdown happen
> git bisect good b2d2d7ea0dd09802cf5a0545bf54d8ad8987d20c
> # bad: [b717dfbf73e842d15174699fe2c6ee4fdde8aa1f] Revert "usb: typec: tcpm: fix cc role at port reset"
> git bisect bad b717dfbf73e842d15174699fe2c6ee4fdde8aa1f
> # good: [032178972f8e992b90f9794a13265fec8c8314b0] usb: gadget: pch_udc: fix an Excess kernel-doc warning
> git bisect good 032178972f8e992b90f9794a13265fec8c8314b0
> # first bad commit: [b717dfbf73e842d15174699fe2c6ee4fdde8aa1f] Revert "usb: typec: tcpm: fix cc role at port reset"
On 10.02.24 08:38, Linux regression tracking #adding (Thorsten Leemhuis)
wrote:
> On 08.02.24 23:01, Mark Brown wrote:
>> On Wed, Jan 17, 2024 at 11:47:42AM +0000, Badhri Jagan Sridharan wrote:
>>> This reverts commit 1e35f074399dece73d5df11847d4a0d7a6f49434.
>>>
>>> Given that ERROR_RECOVERY calls into PORT_RESET for Hi-Zing
>>> the CC pins, setting CC pins to default state during PORT_RESET
>>> breaks error recovery.
>>
>> Between -rc2 and -rc3 I started seeing boot issues in mainline on
>> rk3399-roc-pc running arm64 defconfig, a bisection identified this patch
>> as having broken things. The issues manifest as a hang while loading
>> modules from the initd, you can see a full boot log at:
>
> Thanks for the report. To be sure the issue doesn't fall through the
> cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
> tracking bot:
>
> #regzbot ^introduced b717dfbf73e842d15174699fe2c6ee4fdde8a
> #regzbot title usb: typec: boot issues on rk3399-roc-pc due to revert
> #regzbot ignore-activity
#regzbot monitor:
https://lore.kernel.org/all/[email protected]/
#regzbot fix: usb: typec: tpcm: Fix issues with power being removed
during reset
#regzbot ignore-activity
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
That page also explains what to do if mails like this annoy you.