From: Abdel Alkuor <alkuor@gmail.com>
To: Jai Luthra <j-luthra@ti.com>,
Javier Carrasco <javier.carrasco@wolfvision.net>
Cc: Abdel Alkuor <abdelalkuor@geotab.com>,
rogerq@kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
vigneshr@ti.com, d-gole@ti.com, nm@ti.com
Subject: Re: [PATCH v2 0/4] usb: typec: tipd: add patch update support for tps6598x
Date: Fri, 5 Jan 2024 11:40:05 -0500 [thread overview]
Message-ID: <ZZgw5SNZiG4VlhZD@abdel> (raw)
In-Reply-To: <4erwnvyyammnsdihwpvqcmm4v4fcyxozltocklsbnbfdhacoye@le7x2giuxrwv>
On Fri, Jan 05, 2024 at 03:40:54PM +0530, Jai Luthra wrote:
Hi Jai and Jvaier,
> > My biggest concern is that we are sending GAID for the tps25750 under
> > the same circumstances. Could we not have the same problem with that
> > device? We would be resetting the PD controller and the SoC would stop
> > getting power as well, right? Or is there anything device-specific that
> > would avoid that?
> >
>
> Yes I would guess same problem can happen depending on probe order of
> the remote-endpoint node, but I don't see any upstream platform using
> ti,tps25750 compatible, so I have no way to confirm.
>
> Maybe Abdel can comment on how it works, as he added the GAID reset for
> tps25750.
>
Ops, that's an oversight from my side. In our case, fwnode_usb_role_switch_get()
returns NULL but if it does return -EPROBE_DEFER, we will end up with
the same issue you're seeing.
The purpose of the reset is to remove any applied patch so we don't
leave USB-C PD controller in some kind of operable state when the device
fails to be probed. GO2P command forces PD controller to retrun to PTCH
mode but unfortunately that doesn't work in all cases unless ADCINx pins
configurations are set in "NegotiateHighVoltage" option, so I opted into
using the hard reset instead regardless of ADCINx configurations.
> > > If you have a better architecture in mind that can reset only when PTCH
> > > has been applied and not for other probe defers, feel free to send it on
> > > top of it.
> > >
> >
> > I added the cold reset to have the same behavior upon probe failures for
> > both devices, given that they use the same command. But if that can
> > cause problems, let's leave the reset alone...
> >
I think in this case, we might want to apply the patch as the last
thing in the probe or check for EPROBE_DEFER before issuing a hard
reset.
Also, I think if the patch is being applied using EEPROM, I don't
believe we need to issue a hard reset ever as the patch would be applied
automatically after that.
Thanks,
Abdel
prev parent reply other threads:[~2024-01-05 16:40 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-14 16:29 [PATCH v2 0/4] usb: typec: tipd: add patch update support for tps6598x Javier Carrasco
2023-12-14 16:29 ` [PATCH v2 1/4] usb: typec: tipd: add init and reset functions to tipd_data Javier Carrasco
2023-12-19 11:46 ` Heikki Krogerus
2024-01-04 16:14 ` Roger Quadros
2024-01-04 16:39 ` Javier Carrasco
2023-12-14 16:29 ` [PATCH v2 2/4] usb: typec: tipd: add function to request firmware Javier Carrasco
2023-12-19 11:50 ` Heikki Krogerus
2023-12-14 16:29 ` [PATCH v2 3/4] usb: typec: tipd: declare in_data in as const in exec_cmd functions Javier Carrasco
2023-12-19 11:51 ` Heikki Krogerus
2023-12-14 16:29 ` [PATCH v2 4/4] usb: typec: tipd: add patch update support for tps6598x Javier Carrasco
2023-12-19 13:24 ` Heikki Krogerus
2024-01-04 14:20 ` [PATCH v2 0/4] " Jai Luthra
2024-01-04 15:47 ` Jai Luthra
2024-01-04 16:15 ` Roger Quadros
2024-01-04 16:36 ` Javier Carrasco
2024-01-04 17:08 ` Roger Quadros
2024-01-04 17:15 ` Javier Carrasco
2024-01-04 18:52 ` Dhruva Gole
2024-01-04 20:15 ` Javier Carrasco
2024-01-05 7:57 ` Roger Quadros
2024-01-04 16:25 ` Javier Carrasco
2024-01-05 8:12 ` Jai Luthra
2024-01-05 9:49 ` Javier Carrasco
2024-01-05 10:10 ` Jai Luthra
2024-01-05 16:40 ` Abdel Alkuor [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZZgw5SNZiG4VlhZD@abdel \
--to=alkuor@gmail.com \
--cc=abdelalkuor@geotab.com \
--cc=d-gole@ti.com \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=j-luthra@ti.com \
--cc=javier.carrasco@wolfvision.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=nm@ti.com \
--cc=rogerq@kernel.org \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).