Stash the currently reported port role in the port struct and add a
check for that too while determining whether to re-configure on-board
Type C switches (this deals with cases like role swaps where the mux
flags don't change, but the port role does).
Signed-off-by: Prashant Malani
Suggest
Hi Enric,
On Tue, Apr 20, 2021 at 3:00 AM Enric Balletbo i Serra
wrote:
>
> Hi Prashant,
>
> On 16/4/21 20:27, Prashant Malani wrote:
> > Update the EC command header to include the new event bit. This bit
> > is included in the latest version of the Chrome EC headers[1]
Update the EC command header to include the new event bit. This bit
is included in the latest version of the Chrome EC headers[1].
[1]
https://chromium.googlesource.com/chromiumos/platform/ec/+/refs/heads/main/include/ec_commands.h
Signed-off-by: Prashant Malani
---
Changes in v3:
- Remove
The Chrome Embedded Controller (EC) generates a hard reset type C event
when a USB Power Delivery (PD) hard reset is encountered. Handle this
event by unregistering the partner and cable on the associated port and
clearing the event flag.
Cc: Benson Leung
Signed-off-by: Prashant Malani
When a PD notifier event arrives, a new work event won't be enqueued if
the current one hasn't completed. This could lead to dropped events.
So, flush any pending work before scheduling the new instance.
Signed-off-by: Prashant Malani
---
drivers/platform/chrome/cros_ec_typec.c | 1
returning.
Signed-off-by: Prashant Malani
---
drivers/platform/chrome/cros_ec_typec.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_typec.c
b/drivers/platform/chrome/cros_ec_typec.c
index e724a5eaef1c..91b8fc1fd7f3 100644
--- a/drivers
Signed-off-by: Prashant Malani
---
.../linux/platform_data/cros_ec_commands.h| 26 +++
1 file changed, 26 insertions(+)
diff --git a/include/linux/platform_data/cros_ec_commands.h
b/include/linux/platform_data/cros_ec_commands.h
index d3c40220b281..a95dc22a5463 100644
--- a
Clear USB Type C discovery events from the Chrome EC once they've been
successfully handled.
Signed-off-by: Prashant Malani
---
drivers/platform/chrome/cros_ec_typec.c | 28 +++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/c
On Tue, Feb 2, 2021 at 5:49 PM Prashant Malani wrote:
>
> This command is used to communicate with the Chrome Embedded Controller
> (EC) regarding USB Type C events and state.
>
> These header updates are included in the latest Chrome OS EC headers [1]
>
> [1]
> https://c
Signed-off-by: Prashant Malani
---
Changes in v2:
- Fixed new line errors.
.../linux/platform_data/cros_ec_commands.h| 26 +++
1 file changed, 26 insertions(+)
diff --git a/include/linux/platform_data/cros_ec_commands.h
b/include/linux/platform_data/cros_ec_commands.h
index
Clear USB Type C discovery events from the Chrome EC once they've been
successfully handled.
Signed-off-by: Prashant Malani
---
Changes in v2:
- No changes.
drivers/platform/chrome/cros_ec_typec.c | 28 +++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --
; registering the cable.
>
> Signed-off-by: Benson Leung
Reviewed-by: Prashant Malani
> ---
> drivers/platform/chrome/cros_ec_typec.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/platform/chrome/cros_ec_typec.c
> b/drivers/platf
On Thu, Jan 28, 2021 at 10:14 PM Benson Leung wrote:
>
> Status provides sop_revision. Process it, and set it using the new
> setter in the typec class.
>
> Signed-off-by: Benson Leung
Reviewed-by: Prashant Malani
> ---
> drivers/platform/chrome/cros_ec_typec.c | 14 +++
her as
> source or sink.
>
> Signed-off-by: Benson Leung
Reviewed-by: Prashant Malani
> ---
> drivers/platform/chrome/cros_ec_typec.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/platform/chrome/cros_ec_typec.c
> b/drivers/platform/chrome/cros_
Thanks Benson,
On Wed, Feb 3, 2021 at 11:18 PM Benson Leung wrote:
>
> Hi Prashant,
>
> On Tue, 2 Feb 2021 18:15:37 -0800, Prashant Malani wrote:
> > This command is used to communicate with the Chrome Embedded Controller
> > (EC) regarding USB Type C events and sta
possible.
But otherwise LGTM, so:
Reviewed-by: Prashant Malani
On Fri, Feb 5, 2021 at 12:05 PM Prashant Malani wrote:
>
> Hi Raj,
>
> On Fri, Feb 5, 2021 at 11:52 AM Rajmohan Mani wrote:
> >
> > There are certain scenarios, where a disconnect event might
> > occur on a Type-C port with no port partners. This is required
o allow for mux configuration of Type-C ports, to enable
> retimer communication.
>
> Signed-off-by: Rajmohan Mani
Reviewed-by: Prashant Malani
> ---
> drivers/platform/chrome/cros_ec_typec.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/platform/chrom
.
Signed-off-by: Prashant Malani
Acked-by: Benson Leung
---
Changes in v3:
- Fixed Acked-by tag typo.
Changes in v2:
- Added more text to the switch descriptions, explaining their purpose,
and relation to the Type C connector class framework.
.../bindings/chrome/google,cros-ec-typec.yaml
Register Type C mux and switch handles, when provided via firmware
bindings. These will allow the cros-ec-typec driver, and also alternate
mode drivers to configure connected Muxes correctly, according to PD
information retrieved from the Chrome OS EC.
Signed-off-by: Prashant Malani
Reviewed-by
Hi Rob,
On Mon, May 18, 2020 at 12:17:04AM -0700, Prashant Malani wrote:
> Add properties for mode, orientation and USB data role switches for
> Type C connectors. When available, these will allow the Type C connector
> class port driver to configure the various switches according
f UFP and
> USB_ROLE_DEVICE in case of DFP. Correct this by sending correct enum
> values as USB_ROLE_DEVICE in case of UFP and USB_ROLE_HOST in case of
> DFP.
>
> Fixes: 7e7def15fa4b ("platform/chrome: cros_ec_typec: Add USB mux control")
>
> Signed-off-by: Azhar Shaikh
> C
>
> Signed-off-by: Azhar Shaikh
> Suggested-by: Prashant Malani
> ---
> drivers/platform/chrome/cros_ec_typec.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/platform/chrome/cros_ec_typec.c
> b/drivers/platform/chro
On Thu, Jul 30, 2020 at 11:02:28PM +, Shaikh, Azhar wrote:
> Hi Prashant,
>
> >
> > Please add the list of changes in each version after the "---" line.
>
> I have added those in the cover letter.
> >
It is good practice to add these to the individual change too, so that
the reader doesn'
On Thu, Jul 30, 2020 at 11:14:39PM +, Shaikh, Azhar wrote:
>
>
> > -Original Message-
> > From: Prashant Malani
> > Sent: Thursday, July 30, 2020 4:05 PM
> > To: Shaikh, Azhar
> > Cc: ble...@chromium.org; enric.balle...@collabora.com;
&
Hey Azhar,
On Thu, Jul 30, 2020 at 11:06:12PM +, Shaikh, Azhar wrote:
> Hi Prashant,
> >
> > Since this was the last switch being configured, please maintain the same
> > order and add this at the end of the function, after the if-else if block.
> >
>
> Please correct if my understanding is
f those various properties (which is handled by the TCPM in
the Chrome OS EC), and not any ordering for setting switches etc.
That said, I'm not opposed to the re-ordering, so:
Reviewed-by: Prashant Malani
> ---
> Changes in v4:
> - No change
>
> Changes in v3:
Hi Azhar,
On Wed, Aug 5, 2020 at 12:22 PM Shaikh, Azhar wrote:
>
> Hi Prashant,
>
> > Is this documented anywhere? Kindly provide the links to that if so. I
> > wasn't
> > aware of any ordering requirements (but I may be missing something).
>
> The configuration of the connector should always h
Hi,
On Wed, Aug 05, 2020 at 08:28:22PM +, Shaikh, Azhar wrote:
> Hi Prashant,
>
> > >
> > > Hi Prashant,
> > >
> > > > Is this documented anywhere? Kindly provide the links to that if so.
> > > > I wasn't aware of any ordering requirements (but I may be missing
> > something).
> > >
> > > The
Hi Heikki,
On Thu, Aug 6, 2020 at 4:39 AM Heikki Krogerus
wrote:
>
> On Wed, Aug 05, 2020 at 12:37:14PM -0700, Prashant Malani wrote:
> > Hi Azhar,
> >
> >
> > On Wed, Aug 5, 2020 at 12:22 PM Shaikh, Azhar
> > wrote:
> > >
> > > Hi Prash
Add the Type C class for plug alternate mode devices which are being
registered by the Type C connector class. This ensures that udev events
get generated when the plug alt modes are registered.
Signed-off-by: Prashant Malani
Cc: Heikki Krogerus
---
Changes in v2:
- Changed code to set the
ec.
> Rename cros_typec_cmds_supported() to cros_typec_feature_supported().
>
> Signed-off-by: Utkarsh Patel
Reviewed-by: Prashant Malani
Thanks,
-Prashant
orm/ec/+/refs/heads/master/include/ec_commands.h
>
> Signed-off-by: Utkarsh Patel
I'm not sure what the maintainers' preference is for the header (same
patch or separate patch). FWIW:
Reviewed-by: Prashant Malani
Thanks,
-Prashant
Hi Heikki,
Thanks a lot for looking at the patch.
On Tue, Dec 8, 2020 at 1:37 AM Heikki Krogerus
wrote:
>
> On Wed, Dec 02, 2020 at 07:08:47PM -0800, Prashant Malani wrote:
> > Add the Type C bus for plug alternate modes which are being
> > registered via the Type C con
In a couple of call sites, we use the same pattern of checking for a
partner or cable device before attempting to remove it. Simplify this by
moving those checks into the remove functions.
Cc: Benson Leung
Signed-off-by: Prashant Malani
---
drivers/platform/chrome/cros_ec_typec.c | 20
Hi Enric,
Thanks for taking a look.
On Thu, Apr 15, 2021 at 10:39 PM Enric Balletbo Serra
wrote:
>
> Hi Prashant,
>
> Thank you for your patch.
>
> Missatge de Prashant Malani del dia dj., 15
> d’abr. 2021 a les 4:15:
> >
> > The Chrome Embedded Controller (
Update the EC command header to include the new event bit. This bit
is included in the latest version of the Chrome EC headers[1].
[1]
https://chromium.googlesource.com/chromiumos/platform/ec/+/refs/heads/main/include/ec_commands.h
Change-Id: I52a36e725d945665814d4e59ddd1e76a3692db9f
---
v2 is t
The Chrome Embedded Controller (EC) generates a hard reset type C event
when a USB Power Delivery (PD) hard reset is encountered. Handle this
event by unregistering the partner and cable on the associated port and
clearing the event flag.
Cc: Benson Leung
Signed-off-by: Prashant Malani
bit. This bit
is included in the latest version of the Chrome EC headers[1].
[1]
https://chromium.googlesource.com/chromiumos/platform/ec/+/refs/heads/main/include/ec_commands.h
Cc: Benson Leung
Signed-off-by: Prashant Malani
---
drivers/platform/chrome/cros_ec_typec.c| 13
Hi Heikki,
On Tue, Nov 17, 2020 at 02:41:43PM +0200, Heikki Krogerus wrote:
> On Mon, Nov 16, 2020 at 12:11:42PM -0800, Prashant Malani wrote:
> > Add a field to the typec_plug struct to record the number of available
> > altmodes as well as the corresponding sysfs attribute to
Hi Utkarsh,
On Fri, Nov 13, 2020 at 12:25:01PM -0800, Utkarsh Patel wrote:
> Configure Thunderbolt3/USB4 cable generation value by filing Thunderbolt 3
> cable discover mode VDO to support rounded and non-rounded Thunderbolt3/
> USB4 cables.
> While we are here use Thunderbolt 3 cable discover mod
Including Heikki, who I forgot to add in the original patch email.
On Thu, Nov 05, 2020 at 06:03:05PM -0800, Prashant Malani wrote:
> On occasion, the Chrome Embedded Controller (EC) can send a mux
> configuration which doesn't map to a particular data mode. For instance,
> de
Hi Utkarsh,
On Fri, Nov 13, 2020 at 12:25:00PM -0800, Utkarsh Patel wrote:
> USB4 also uses same cable properties as Thunderbolt 3 so use Thunderbolt 3
> cable discover mode VDO to fill details such as active cable plug link
> training and cable rounded support.
>
> Suggested-by: Heikki Krogerus
On Tue, Nov 17, 2020 at 1:16 PM Prashant Malani wrote:
>
> Hi Utkarsh,
>
> On Fri, Nov 13, 2020 at 12:25:00PM -0800, Utkarsh Patel wrote:
> > USB4 also uses same cable properties as Thunderbolt 3 so use Thunderbolt 3
> > cable discover mode VDO to fill details such a
On Tue, Nov 17, 2020 at 10:19 AM Prashant Malani wrote:
>
> Hi Utkarsh,
>
> On Fri, Nov 13, 2020 at 12:25:01PM -0800, Utkarsh Patel wrote:
> > Configure Thunderbolt3/USB4 cable generation value by filing Thunderbolt 3
> > cable discover mode VDO to support rounded and
Hi Heikki,
Thanks for developing these patches :)
On Wed, Nov 18, 2020 at 06:00:56PM +0300, Heikki Krogerus wrote:
> Hi Prashant,
>
> The original discussion [1].
>
> This proposal is in practice a compromise. I came to the conclusion
> that we probable should expose the product type separately
lowing peripherals:
- Thunderbolt 3 active cable.
- Thunderbolt 3 passive cable.
- Dell WD19TB dock.
- Type C DisplayPort enabled monitor (which advertises as AMA).
For the above, the product_type seems to be getting parsed and displayed
correctly, so FWIW:
Tested-by: Prashant Malani
> ---
&
Hi Greg,
On Wed, Nov 18, 2020 at 01:16:49PM +0100, Greg KH wrote:
> On Wed, Nov 18, 2020 at 12:59:59PM +0100, Greg KH wrote:
> > On Mon, Nov 16, 2020 at 12:11:36PM -0800, Prashant Malani wrote:
> > > This patch series adds support for the following bits of functionality,
> &
Hi Heikki,
On Wed, Dec 9, 2020 at 8:14 AM Heikki Krogerus
wrote:
>
> On Tue, Dec 08, 2020 at 03:45:19PM -0800, Prashant Malani wrote:
> > Hi Heikki,
> >
> > Thanks a lot for looking at the patch.
> >
> > On Tue, Dec 8, 2020 at 1:37 AM Heikki Krogerus
> >
Hi Heikki,
On Wed, Dec 9, 2020 at 9:15 AM Heikki Krogerus
wrote:
>
> Hi Prashant,
>
> On Wed, Dec 09, 2020 at 08:22:52AM -0800, Prashant Malani wrote:
> > Hi Heikki,
> >
> > On Wed, Dec 9, 2020 at 8:14 AM Heikki Krogerus
> > wrote:
> > >
> > &
On Wed, Dec 9, 2020 at 2:59 PM Prashant Malani wrote:
>
> Hi Heikki,
>
> On Wed, Dec 9, 2020 at 9:15 AM Heikki Krogerus
> wrote:
> >
> > Hi Prashant,
> >
> > On Wed, Dec 09, 2020 at 08:22:52AM -0800, Prashant Malani wrote:
> > > Hi Heikki,
&
Hi Utkarsh,
On Wed, Nov 18, 2020 at 10:32:09PM -0800, Utkarsh Patel wrote:
> Configure Thunderbolt 3 cable generation value by filling Thunderbolt 3
> cable discover mode VDO to support rounded Thunderbolt 3 cables.
> While we are here use Thunderbolt 3 cable discover mode VDO to fill active
> cab
Hi Heikki,
On Thu, Nov 19, 2020 at 01:05:06PM +0200, Heikki Krogerus wrote:
> On Wed, Nov 18, 2020 at 10:53:50AM -0800, Prashant Malani wrote:
> > > +What:/sys/class/typec/-cable/product_type
> > > +Date:December 2020
> > > +Contact: Heikk
Hi Utkarsh,
On Thu, Nov 19, 2020 at 6:32 PM Patel, Utkarsh H
wrote:
>
> Hi Prashant,
>
> > -Original Message-
> > From: Prashant Malani
> > Sent: Thursday, November 19, 2020 12:09 AM
> > To: Patel, Utkarsh H
> > Cc: linux-kernel@vge
:
drivers/usb/typec/class.c:632: warning: Excess function parameter
'num_alt_modes' description in 'typec_partner_set_num_altmodes'
Fixes: a0ccdc4a77a1 ("usb: typec: Add number of altmodes partner attr")
Signed-off-by: Prashant Malani
---
drivers/usb/typec/class.c | 2 +
Hi Stephen,
On Fri, Nov 20, 2020 at 04:15:06PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the usb tree, today's linux-next build (htmldocs) produced
> this warning:
>
> drivers/usb/typec/class.c:632: warning: Excess function parameter
> 'num_alt_modes' description in 'typec_part
On Fri, Nov 20, 2020 at 10:05:14AM +0200, Heikki Krogerus wrote:
> On Wed, Nov 18, 2020 at 10:32:08PM -0800, Utkarsh Patel wrote:
> > When Thunderbolt 3 cable is being used to create USB4 connection, use
> > Thunderbolt 3 discover mode VDO to fill details such as active cable plug
> > link training
On Fri, Nov 20, 2020 at 09:41:21AM +0100, Greg KH wrote:
> On Thu, Nov 19, 2020 at 10:35:22PM -0800, Prashant Malani wrote:
> > The commit to introduce the num_altmodes attribute for partner had an
> > error where one of the parameters was named differently in the comment
>
On Fri, Nov 20, 2020 at 01:22:18PM +0200, Heikki Krogerus wrote:
> On Thu, Nov 19, 2020 at 12:09:06AM -0800, Prashant Malani wrote:
> > Hi Utkarsh,
> >
> > On Wed, Nov 18, 2020 at 10:32:09PM -0800, Utkarsh Patel wrote:
> > > Configure Thunderbolt 3 cable generation
On Fri, Nov 20, 2020 at 4:07 AM Prashant Malani wrote:
>
> On Fri, Nov 20, 2020 at 01:22:18PM +0200, Heikki Krogerus wrote:
> > On Thu, Nov 19, 2020 at 12:09:06AM -0800, Prashant Malani wrote:
> > > Hi Utkarsh,
> > >
> > > On Wed, Nov 18, 2020 a
Friendly ping. If there are not other reservations, can we pick this
patch? It doesn't depend on any other patch series.
Thanks,
On Thu, Nov 19, 2020 at 11:32 PM Heikki Krogerus
wrote:
>
> On Thu, Nov 05, 2020 at 06:03:05PM -0800, Prashant Malani wrote:
> > On occasion, th
Both partner and cable have identity VDOs. These are listed separately
in the Documentation/ABI/testing/sysfs-class-typec. Factor these out
into a common location to avoid the duplication.
Signed-off-by: Prashant Malani
Acked-by: Heikki Krogerus
---
Changes in v4:
- Rebased on top of the usb
A PD-capable device can return up to 3 Product Type VDOs as part of its
DiscoverIdentity Response (USB PD Spec, Rev 3.0, Version 2.0, Section
6.4.4.3.1). Add sysfs attributes to expose these to userspace.
Cc: Benson Leung
Cc: Heikki Krogerus
Signed-off-by: Prashant Malani
Reviewed-by: Heikki
Hi Heikki,
On Tue, Nov 24, 2020 at 5:23 AM Heikki Krogerus
wrote:
>
> On Fri, Oct 23, 2020 at 02:43:26PM -0700, Prashant Malani wrote:
> > Both partner and cable have identity VDOs. These are listed separately
> > in the Documentation/ABI/testing/sysfs-class-typec. Factor th
Hi,
On Tue, Nov 24, 2020 at 12:10:31PM -0800, Prashant Malani wrote:
> Both partner and cable have identity VDOs. These are listed separately
> in the Documentation/ABI/testing/sysfs-class-typec. Factor these out
> into a common location to avoid the duplication.
>
> Signed-o
A PD-capable device can return up to 3 Product Type VDOs as part of its
DiscoverIdentity Response (USB PD Spec, Rev 3.0, Version 2.0, Section
6.4.4.3.1). Add sysfs attributes to expose these to userspace.
Cc: Benson Leung
Cc: Heikki Krogerus
Signed-off-by: Prashant Malani
Reviewed-by: Heikki
Both partner and cable have identity VDOs. These are listed separately
in the Documentation/ABI/testing/sysfs-class-typec. Factor these out
into a common location to avoid the duplication.
Signed-off-by: Prashant Malani
Acked-by: Heikki Krogerus
---
Changes in v5:
- Corrected the email address
Hi Heikki,
On Tue, Nov 24, 2020 at 11:53 PM Heikki Krogerus
wrote:
>
> On Wed, Nov 25, 2020 at 09:46:06AM +0200, Heikki Krogerus wrote:
> > On Tue, Nov 24, 2020 at 12:32:35PM -0800, Prashant Malani wrote:
> > > Hi,
> > >
> > > On Tue, Nov 24, 2020 at
ff-by: Prashant Malani
---
This patch should be applied on top of the series[1] which adds support
for cable & plugs to cros-ec-typec.
[1]
https://lore.kernel.org/linux-usb/20201116201150.2919178-1-pmal...@chromium.org/
drivers/platform/chrome/cros_ec_typec.c | 5 ++---
1 file changed, 2 inserti
mode devices to alternate mode drivers.
Update the Type C bus documentation to mention that there
are alternate mode devices for plugs as well.
Signed-off-by: Prashant Malani
Cc: Heikki Krogerus
---
Documentation/driver-api/usb/typec_bus.rst | 6 +++---
drivers/usb/typec/class.c
Generate a change uevent when the "number_of_alternate_modes" sysfs file
for partners and plugs is updated by a port driver.
Cc: Heikki Krogerus
Cc: Benson Leung
Signed-off-by: Prashant Malani
---
drivers/usb/typec/class.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/d
Hi Greg,
Thanks for taking a look at the patch.
On Thu, Jan 7, 2021 at 1:16 AM Greg KH wrote:
>
> On Wed, Jan 06, 2021 at 07:49:04PM -0800, Prashant Malani wrote:
> > Generate a change uevent when the "number_of_alternate_modes" sysfs file
> > for partners and plugs
Hi Enric,
On Thu, Apr 30, 2020 at 8:26 AM Enric Balletbo i Serra
wrote:
>
> Hi Prashant,
>
> On 30/4/20 2:43, Prashant Malani wrote:
> > On Wed, Apr 29, 2020 at 5:38 PM Daniil Lunev wrote:
> >>
> >> [to make it appear on the mailing list as I didn't rea
: cannot register EC,
> fallback to spidev
> [8.767017] cros_ec_lpcs GOOG0004:00: Chrome EC device registered
> [8.807537] cros-usbpd-notify-acpi GOOG0003:00: Couldn't get Chrome
> EC device pointer.
> ...
>
> On Fri, May 1, 2020 at 2:17 AM Prashant Malani wrote:
> &
bit is correctly handled while issuing the Alternate
Mode request.
Signed-off-by: Prashant Malani
Fixes: 6701adfa9693 ("usb: typec: driver for Intel PMC mux control")
---
drivers/usb/typec/mux/intel_pmc_mux.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb
) should also be set. Ensure the bit is correctly handled
while issuing the Alternate Mode request.
Signed-off-by: Prashant Malani
Fixes: 6701adfa9693 ("usb: typec: driver for Intel PMC mux control")
---
Changes in v2:
- Clarified the commit message to mention the proper field names.
d
Sorry, didn't compose the Commit message quite right, have sent out v2.
Thanks,
On Tue, Apr 28, 2020 at 10:34 PM Prashant Malani wrote:
>
> According to the PMC Type C Subsystem (TCSS) Mux programming guide rev
> 0.6, when a device is transitioning to DP Alternate Mode state, if
Hi Enric,
Thanks for your review. Kindly see inline:
On Wed, Apr 29, 2020 at 3:22 PM Enric Balletbo i Serra
wrote:
>
> Hi Prashant,
>
> Thank you for your patch.
>
> On 23/4/20 0:22, Prashant Malani wrote:
> > Register Type C mux and switch handles, when provided v
On Wed, Apr 29, 2020 at 5:38 PM Daniil Lunev wrote:
>
> [to make it appear on the mailing list as I didn't realize I was in
> hypertext sending mode]
>
> On Thu, Apr 30, 2020 at 10:11 AM Daniil Lunev wrote:
> >
> > Hi Enric.
> > I encountered the issue on a Hatch device when trying running 5.4 ke
Hi Rob,
On Wed, Jun 10, 2020 at 9:53 AM Rob Herring wrote:
>
> On Wed, Jun 10, 2020 at 9:34 AM Heikki Krogerus
> wrote:
> >
> > On Tue, Jun 09, 2020 at 04:57:40PM -0700, Prashant Malani wrote:
> > > Hi Rob,
> > >
> > > Thanks again for the co
switch" devices.
Best regards,
On Fri, Jun 12, 2020 at 10:34 AM Prashant Malani wrote:
>
> Hi Rob,
>
> Thanks as always for your help in reviewing this proposal!
>
> Kindly see inline
>
> (Trimming text);
> On Thu, Jun 11, 2020 at 02:00:47PM -0600, Rob Herring wrot
Hi Guenter,
Thanks for the comments.
On Mon, Jun 29, 2020 at 2:05 PM Guenter Roeck wrote:
>
> On Mon, Jun 29, 2020 at 9:38 AM Prashant Malani wrote:
> >
> > Use a work queue to call the port update routines, instead of doing it
> > directly in the PD notifier callback.
Hi Guenter,
Thanks for reviewing the patch.
On Mon, Jun 29, 2020 at 9:25 AM Guenter Roeck wrote:
>
> On Mon, Jun 29, 2020 at 9:13 AM Prashant Malani wrote:
> >
> > Define basic suspend resume functions for cros-ec-typec. On suspend, we
> > simply ensure that any pen
Use a work queue to call the port update routines, instead of doing it
directly in the PD notifier callback. This will prevent other drivers
with PD notifier callbacks from being blocked on the port update routine
completing.
Signed-off-by: Prashant Malani
---
Changes in v4:
- Removed extra
Define basic suspend resume functions for cros-ec-typec. On suspend, we
simply ensure that any pending port update work is completed, and on
resume, we re-poll the port state to account for any
changes/disconnections that might have occurred during suspend.
Signed-off-by: Prashant Malani
Define basic suspend resume functions for cros-ec-typec. On suspend, we
simply ensure that any pending port update work is completed, and on
resume, we re-poll the port state to account for any
changes/disconnections that might have occurred during suspend.
Signed-off-by: Prashant Malani
Hi Enric,
Thanks for reviewing the patch.
On Mon, Jun 29, 2020 at 3:51 AM Enric Balletbo i Serra
wrote:
>
> Hi Prashant,
>
> Thank you for the patch.
>
> On 27/6/20 6:58, Prashant Malani wrote:
> > Define basic suspend resume functions for cros-ec-typec. On suspend, w
On Mon, Jun 29, 2020 at 2:18 PM Guenter Roeck wrote:
>
> On Mon, Jun 29, 2020 at 2:13 PM Prashant Malani wrote:
> >
> > Use a work queue to call the port update routines, instead of doing it
> > directly in the PD notifier callback. This will prevent other drivers
> &
Hi Heikki,
On Wed, Jun 24, 2020 at 12:20:40PM +0300, Heikki Krogerus wrote:
> On Wed, Jun 24, 2020 at 12:15:20PM +0300, Heikki Krogerus wrote:
> > On Wed, Jun 24, 2020 at 01:09:24AM -0700, Prashant Malani wrote:
> > > Add mux control support for Thunderbolt
Thanks Enric!
On Thu, Jun 25, 2020 at 4:56 AM Enric Balletbo i Serra
wrote:
>
> Hi Prashant,
>
> On 28/5/20 13:36, Prashant Malani wrote:
> > This series adds mux control support for USB and DP alternate modes on
> > devices using the cros-ec-typec driver with Type C swi
Hi Heikki and Rob,
(trimming text):
On Mon, Jun 15, 2020 at 04:22:07PM +0300, Heikki Krogerus wrote:
> On Fri, Jun 12, 2020 at 10:34:06AM -0700, Prashant Malani wrote:
> > Hi Rob,
> > > Yes, but let's stop calling it a mux. It's a "USB Type C signal r
properties to
devicetree bindings in a conformant way.
Thanks everyone,
-Prashant,
[1]:
https://lore.kernel.org/lkml/CAL_Jsq+ORkzHchpD0qsH97zDJzXGj3jWy8=orxsvhnqd4kr...@mail.gmail.com/T/#t
[2]: https://lkml.org/lkml/2020/5/19/1219
(Trimming text);
On Tue, May 19, 2020 at 02:46:02PM -0700, Prashant
Hi Rob,
Thanks as always for your help in reviewing this proposal!
Kindly see inline
(Trimming text);
On Thu, Jun 11, 2020 at 02:00:47PM -0600, Rob Herring wrote:
> On Wed, Jun 10, 2020 at 11:49 AM Prashant Malani wrote:
> >
> > Hi Rob,
> >
> > On Wed, Jun 10,
rest add the aforementioned functionality.
This series depends on the following patch :
https://lkml.org/lkml/2020/5/19/1219
[1] :
https://chromium.googlesource.com/chromiumos/platform/ec/+/refs/heads/master/include/ec_commands.h
Prashant Malani (4):
platform/chrome: cros_ec: Update mux state
Sync the EC_CMD_USB_PD_MUX_INFO mux state bit fields with the Chrome EC
code base. The newly added bit fields will be used for cros-ec-typec mux
control.
Signed-off-by: Prashant Malani
---
include/linux/platform_data/cros_ec_commands.h | 14 +-
1 file changed, 9 insertions(+), 5
version number
from cmd_ver to pd_ctrl_ver, which more accurately reflects what is
being stored.
Also, slightly change the logic for calling
cros_typec_set_port_params_*(). Now, v0 is called when pd_ctrl_ver is 0,
and v1 is called otherwise.
Signed-off-by: Prashant Malani
---
drivers/platform
Add support to configure various Type C switches appropriately using the
Type C connector class API, when the Chrome OS EC informs the AP that
the USB operating mode has been entered.
Signed-off-by: Prashant Malani
---
drivers/platform/chrome/cros_ec_typec.c | 100 +++-
1
ectly surfaced to the driver, we can register the DP
alternate mode driver and let it handle the mux configuration.
Also, modify the struct_typec_state state management to account for the
addition of DP alternate mode.
Signed-off-by: Prashant Malani
---
drivers/platform/chrome/cros_ec_typec.c
Hi Rob,
Would you prefer these switches to be defined in the
usb-connector.yaml bindings file?
If there are no other concerns, I can push a fresh version of the
patch with the properties defined in usb-connector.yaml.
Thanks,
On Tue, May 19, 2020 at 2:46 PM Prashant Malani wrote:
>
&g
Hi Rob,
Thanks for reviewing the patch! Kindly see inline:
On Fri, May 29, 2020 at 2:55 PM Rob Herring wrote:
>
> > > " Reference to a DT node for the USB Type C Multiplexer controlling the
> > > data lines routing for this connector. This switch is assumed registered
> > > with the Type C conne
1 - 100 of 225 matches
Mail list logo
