On 09 April 2019 15:41, Hans de Goede wrote:
> Hi,
>
> On 09-04-19 15:06, Heikki Krogerus wrote:
> > On Tue, Apr 09, 2019 at 04:02:30PM +0300, Heikki Krogerus wrote:
> >> +Hans
> >>
> >> On Mon, Apr 08, 2019 at 10:17:35PM +0800, Kyle Tso wrote:
> >>> On Fri, Apr 5, 2019 at 9:42 PM Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
> >>>>
> >>>> On 4/4/19 7:13 AM, Heikki Krogerus wrote:
> >>>>> Hi,
> >>>>>
> >>>>> On Fri, Mar 22, 2019 at 08:17:45PM +0800, Kyle Tso wrote:
> >>>>>> This patch provides the implementation of Collision Avoidance
> >>>>>> introduced in PD3.0. The start of each Atomic Message Sequence
> >>>>>> (AMS) initiated by the port will be denied if the current AMS is
> >>>>>> not interruptible. The Source port will set the CC to SinkTxNG if
> >>>>>> it is going to initiate an AMS, and SinkTxOk otherwise.
> >>>>>> Meanwhile, any AMS initiated by a Sink port will be denied in
> >>>>>> TCPM if the port partner (Source) sets SinkTxNG except for HARD_RESET
> and SOFT_RESET.
> >>>>>
> >>>>> I tested this with my GDBWin which has fusb302. When I plug-in
> >>>>> DisplayPort adapter, the partner device never gets registered, and
> >>>>> I see steady flow of warnings from fusb302:
> >>>>>
> >>>>
> >>>> FWIW, I made multiple attempts to review the patch. Each time I get
> >>>> stuck after a while and notice that I don't understand what is going on.
> >>>>
> >>>> Maybe the state machine needs a complete overhaul. It seems to have
> >>>> reached a point where it is getting too complex to understand what is going
> on.
> >>>>
> >>>>> [ 693.391176] Vconn is on during toggle start [ 693.391250]
> >>>>> WARNING: CPU: 2 PID: 30 at drivers/usb/typec/tcpm/fusb302.c:562
> >>>>> fusb302_set_toggling+0x129/0x130 [fusb302] [ 693.400293] Modules
> linked in: intel_xhci_usb_role_switch fusb302 tcpm roles pi3usb30532 i915 typec
> intel_gtt intel_cht_int33fe
> >>>>> [ 693.406309] CPU: 2 PID: 30 Comm: kworker/u8:1 Tainted: G W
> 5.1.0-rc3-heikki+ #17
> >>>>> [ 693.408434] cht_wcove_pwrsrc cht_wcove_pwrsrc: Could not detect
> >>>>> charger type [ 693.412278] Hardware name: Default string Default
> >>>>> string/Default string, BIOS 5.11 05/25/2017 [ 693.412283]
> >>>>> Workqueue: i2c-fusb302 tcpm_state_machine_work [tcpm] [
> >>>>> 693.424256] RIP: 0010:fusb302_set_toggling+0x129/0x130 [fusb302] [
> >>>>> 693.427234] Code: 89 df e8 da ef ff ff 85 c0 78 c6 c6 83 b0 01 00
> >>>>> 00 00 eb b7 b9 02 00 00 00 e9 48 ff ff ff 48 c7 c7 20 e8 21 a0 e8
> >>>>> 8e 0c e4 e0 <0f> 0b e9 58 ff ff ff 41 55 4c 8d 6f e8 41 54 41 89
> >>>>> f4 55 53 48 8d [ 693.436204] RSP: 0000:ffffc9000076bd90 EFLAGS:
> >>>>> 00010286 [ 693.439174] RAX: 0000000000000000 RBX:
> >>>>> ffff888178080028 RCX: 0000000000000000 [ 693.442157] RDX:
> >>>>> 000000000000001f RSI: ffffffff8259051f RDI: ffffffff8259091f [
> >>>>> 693.445130] RBP: 0000000000000003 R08: ffffffff82590500 R09:
> >>>>> 00000000000202c0 [ 693.448100] R10: 0000010cb24a3d18 R11:
> >>>>> 000000000000001e R12: ffff8881780801b0 [ 693.451086] R13:
> ffffffffa021e4e5 R14: 0000000000000003 R15: ffff888178080040 [ 693.454060] FS:
> 0000000000000000(0000) GS:ffff88817bb00000(0000) knlGS:0000000000000000 [
> 693.460009] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 693.462984] CR2:
> 00000000f7fb74a0 CR3: 000000000200d000 CR4: 00000000001006e0 [ 693.465969]
> Call Trace:
> >>>>> [ 693.468937] tcpm_set_cc+0xb9/0x170 [fusb302] [ 693.471894]
> >>>>> tcpm_ams_start+0x1b8/0x2a0 [tcpm]
> >>>>
> >>>> tcpm_ams_start() sets TYPEC_CC_RP_1_5 unconditionally, no matter
> >>>> what. This causes the fusb302 code to start toggling. As such, it
> >>>> may well attempt to start toggling in the wrong state.
> >>>>
> >>>> Guenter
> >>>>
> >>>
> >>> I read the fusb302 spec but failed to find the statement that says
> >>> it should "set toggling" when CC switches among default/medium/high.
> >>>
> >>> quot from fusb302 spec:
> >>> "The FUSB302 allows the host software to change the charging current
> >>> capabilities of the port through the HOST_CUR control bits. If the
> >>> HOST_CUR bits are changed prior to attach, the FUSB302 automatically
> >>> indicates the programmed current capability when a device is attached.
> >>> If the current capabilities are changed after a device is attached,
> >>> the FUSB302 immediately changes the CC line to the programmed
> >>> capability."
> >>>
> >>> Is it possible to skip fusb302_set_toggling() @ line#658 if
> >>> tcpm_set_cc() is called in order to switch the cc among
> >>> default/medium/high of Rp ?
> >
> > Hans, you introduced that in commit daf81d0137a9c ("usb: typec:
> > fusb302: Refactor / simplify tcpm_set_cc()"), so could you take a look
> > at this.
>
> I do not believe that that commit introduces the fusb302_set_toggling() as the
> subject of the commit says it just refactors things, the set_toggling call was
> introduced by:
>
> commit ea3b4d5523bc8("usb: typec: fusb302: Resolve fixed power role contract
> setup")
>
> Before that:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/u
> sb/typec/tcpm/fusb302.c?id=40326e857c57a0095d3f9d72c14cb13aef4ca564
>
> tcpm_set_cc actually turned toggling off in all cases.
>
> I've no doubt that Adam was seeing a real problem, but I've doubted if this was
> the right fix before. I even had it reverted in my tree for a while, but since in my
> use-cases so far it has not caused any problems I've not looked into it further.
>From my recollection, that was the only way to generate the necessary event from
fusb302 to indicate a connection, when the device was in a fixed role state
(i.e. only source or only sink). Without it the driver doesn't work in these
scenarios as there's no TOGDONE event generated by fusb302, so no eventual call
to 'tcpm_cc_change()' to tell TCPM that something has happened and move on the
state machine. Not all devices will be DRP so we have to account for this.
>
> In the mean time the code has changed quite a bit though, so making
> tcpm_set_cc() behave as it did before, see:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/u
> sb/typec/tcpm/fusb302.c?id=40326e857c57a0095d3f9d72c14cb13aef4ca564
>
> Will require writing something from scratch based on the new code which
> mimicks the behaviour of the old code; and then we also need to fix Adam's
> problem on top.
>
> Regards,
>
> Hans
