According to the PMC Type C Subsystem (TCSS) Mux programming guide rev
0.6, the PMC HPD request LVL bit field is bit 5.
Fix the definition here to match the programming guide.
Since this bit field is changing, explicitly define a field for the
HPD_HIGH mode data bit.
Signed-off-by: Prashant
According to the PMC Type C Subsystem (TCSS) Mux programming guide rev
0.6, the PMC HPD request LVL bit field is bit 4.
Fix the definition here to match the programming guide.
Since this bit field is changing, explicitly define a field for the
HPD_HIGH mode data bit.
Signed-off-by: Prashant
Hi Lars,
Thanks for reviewing the patch.
On Mon, May 11, 2020 at 1:49 AM Lars Melin wrote:
>
> On 5/11/2020 04:39, Prashant Malani wrote:
> > According to the PMC Type C Subsystem (TCSS) Mux programming guide rev
> > 0.6, the PMC HPD request LVL bit field is bit 4.
> >
According to the PMC Type C Subsystem (TCSS) Mux programming guide rev
0.6, the PMC HPD request LVL bit field is bit 4.
Fix the definition here to match the programming guide.
Since this bit field is changing, explicitly define a field for the
HPD_HIGH mode data bit.
Signed-off-by: Prashant
Hi Rajat,
On Tue, Jun 02, 2020 at 04:26:02PM -0700, Rajat Jain wrote:
> Currently, an external malicious PCI device can masquerade the VID:PID
> of faulty gfx devices, and thus apply iommu quirks to effectively
> disable the IOMMU restrictions for itself.
>
> Thus we need to ensure that the devic
(Trimming text)
On Wed, Jun 03, 2020 at 12:23:48AM +, Rajat Jain wrote:
> On Tue, Jun 2, 2020 at 4:49 PM Prashant Malani wrote:
> >
> > Hi Rajat,
>
> Hi Prashant, thanks for taking a look.
>
> >
> > On Tue, Jun 02, 2020 at 04:26:02PM -0700, Rajat Jain wr
Hi,
On Thu, May 28, 2020 at 04:36:07AM -0700, Prashant Malani wrote:
> 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:
Hi,
On Thu, May 28, 2020 at 04:36:10AM -0700, Prashant Malani wrote:
> Handle Chrome EC mux events to configure on-board muxes correctly while
> entering DP alternate mode. Since we don't surface SVID and VDO
> information regarding the DP alternate mode, configure the Type C
> mu
an initial RFC patch, for comments and feedback
about the approach. Depending on feedback, we can refine this approach
and modify the bindings file.
Thanks,
Prashant Malani (1):
usb: dwc3: of-simple: Add extcon support
drivers/usb/dwc3/dwc3-of-simple.c | 149 +-
1
ned-off-by: Prashant Malani
---
drivers/usb/dwc3/dwc3-of-simple.c | 149 +-
1 file changed, 146 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-of-simple.c
b/drivers/usb/dwc3/dwc3-of-simple.c
index e64754be47b4..28bde27cd1f9 100644
--- a/drivers/usb/dw
Hi folks,
On Tue, May 12, 2020 at 04:41:54PM +0300, Heikki Krogerus wrote:
> Hi guys,
>
> On Mon, May 11, 2020 at 01:46:35PM -0700, Prashant Malani wrote:
> > Hi Rob,
> >
> > Thank you for reviewing the patch. Kindly see my comments inline:
> >
> > On Mon
Hi Heikki,
On Tue, May 12, 2020 at 12:19 PM Prashant Malani wrote:
>
> Hi Heikki,
>
> On Tue, May 12, 2020 at 05:22:51PM +0300, Heikki Krogerus wrote:
> > Hi Prashant,
> >
> > On Mon, May 11, 2020 at 10:57:19AM -0700, Prashant Malani wrote:
> > > Hi Heikk
cros_ec_get_sensor_count() such that the legacy LPC interface is tried
on all error values, not just when msg->result != EC_RESULT_SUCCESS.
Signed-off-by: Prashant Malani
---
drivers/platform/chrome/cros_ec_proto.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/driv
Since cros_ec_cmd_xfer_status() now returns Linux error codes and all
other files use that command, remove the now-unused function
cros_ec_cmd_xfer().
Signed-off-by: Prashant Malani
---
drivers/platform/chrome/cros_ec_proto.c | 44 +++--
1 file changed, 11 insertions(+), 33
Hi Rajmohan,
On Mon, Aug 24, 2020 at 10:19:27PM +, Mani, Rajmohan wrote:
> Hi Prashant,
>
> Thanks for the quick review.
>
> > > +
> > > + if (!iom || !iom->dev || !iom->regbar)
> >
> > Do we need to check for !iom->dev and !iom->regbar?
>
> It's a good practice to have sanity checks on po
Hi Heikki,
Thanks a lot for reviewing the patch!
On Wed, Oct 28, 2020 at 03:16:33PM +0200, Heikki Krogerus wrote:
> > +
> > + /* Copy the remaining identity VDOs till a maximum of 6. */
> > + for (i = 3; i < sop_disc->identity_count && i < VDO_MAX_OBJECTS; i++)
> > + port->p_identit
This series adds support to retrieve Type C PD(Power Delivery) Discovery
information from the Chrome OS EC, and register this information with
the Type C connector class framework.
There are also a couple of patches which fix minor bugs with the
existing cros-ec-typec driver.
Prashant Malani (7
: Prashant Malani
---
drivers/platform/chrome/cros_ec_typec.c | 136
1 file changed, 68 insertions(+), 68 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_typec.c
b/drivers/platform/chrome/cros_ec_typec.c
index 31be31161350..49083e21317d 100644
--- a/drivers/platform
feature flag, which is used to
determine whether these commands are supported by the EC.
[1]:
https://chromium.googlesource.com/chromiumos/platform/ec/+/refs/heads/master/include/ec_commands.h
Signed-off-by: Prashant Malani
---
.../linux/platform_data/cros_ec_commands.h| 155
cros_typec_remove_partner() if there is a
valid registered partner pointer.
Signed-off-by: Prashant Malani
---
drivers/platform/chrome/cros_ec_typec.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/chrome/cros_ec_typec.c
b/drivers/platform/chrome/cros_ec_typec.c
Use the discovery data from the Chrome EC to register parter altmodes
with the Type C Connector Class framework. Also introduce a node
struct to keep track of the list of registered alt modes.
Cc: Heikki Krogerus
Signed-off-by: Prashant Malani
---
drivers/platform/chrome/cros_ec_typec.c | 79
Use EC_CMD_TYPE_DISCOVERY to retrieve and store the discovery data for
the port partner. With that data, update the PD Identity VDO values for
the partner, which were earlier not initialized.
Cc: Heikki Krogerus
Signed-off-by: Prashant Malani
---
drivers/platform/chrome/cros_ec_typec.c | 60
.
Also check the EC_FEATURE_TYPEC_CMD feature flag at probe, and only call
the new TYPEC_STATUS command if the feature flag is supported.
Signed-off-by: Prashant Malani
---
drivers/platform/chrome/cros_ec_typec.c | 52 +
1 file changed, 52 insertions(+)
diff --git a
The partner identity struct isn't reset when a partner is removed,
meaning a subsequent partner can inherit an old partner's identity VDOs
before discovery is complete. So, clear that struct when a partner
removal is detected.
Signed-off-by: Prashant Malani
---
drivers/platf
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 a sysfs attribute to expose these to userspace.
Cc: Benson Leung
Cc: Heikki Krogerus
Signed-off-by: Prashant Malani
---
drivers/usb
ot apply to linux/master]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
>
> url:
> https://github.com/0day-ci/linux/c
Hi Greg,
Thanks for taking a look.
On Wed, Oct 21, 2020 at 10:30 PM Greg KH wrote:
>
> On Wed, Oct 21, 2020 at 02:18:02PM -0700, Prashant Malani wrote:
> > A PD-capable device can return up to 3 Product Type VDOs as part of its
> > DiscoverIdentity Response (USB PD Spec, Re
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 a sysfs attribute to expose these to userspace.
Cc: Benson Leung
Cc: Heikki Krogerus
Signed-off-by: Prashant Malani
---
NOTE: I didn&#
Thanks for reviewing the patch, Greg.
On Wed, Oct 21, 2020 at 11:56 PM Greg KH wrote:
>
> On Wed, Oct 21, 2020 at 11:15:54PM -0700, Prashant Malani wrote:
> >
> > diff --git a/Documentation/ABI/testing/sysfs-class-typec
> > b/Documentation/ABI/testing/sysfs-class-type
Hi Greg,
On Thu, Oct 22, 2020 at 12:17 AM Greg KH wrote:
>
> > > > +What:
> > > > /sys/class/typec/-partner/identity/product_type_vdo
> > > > +Date:October 2020
> > > > +Contact: Prashant Malani
> >
Hi Heikki,
Thanks for your feedback.
On Thu, Oct 22, 2020 at 5:43 AM Heikki Krogerus
wrote:
>
> On Thu, Oct 22, 2020 at 12:25:07AM -0700, Prashant Malani wrote:
> > Hi Greg,
> >
> > On Thu, Oct 22, 2020 at 12:17 AM Greg KH wrote:
> > >
> > > Giv
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
---
Patch first introduced in v3.
Documentation/ABI/testing/sysfs-class
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
---
Changes in v3
On Thu, Oct 22, 2020 at 12:13 AM Prashant Malani wrote:
>
> Thanks for reviewing the patch, Greg.
>
> On Wed, Oct 21, 2020 at 11:56 PM Greg KH wrote:
> >
> > >
> > > +What:
> > > /sys/class/typec/-cable/identity/product_type
Hi Heikki,
Thank you for reviewing the patch!
On Wed, Oct 28, 2020 at 03:17:32PM +0200, Heikki Krogerus wrote:
> Hi,
>
> On Wed, Oct 21, 2020 at 01:53:16PM -0700, Prashant Malani wrote:
> > +static void cros_typec_unregister_altmodes(struct cros_typec_data *typec,
&
: Prashant Malani
---
Changes in v2:
- No changes.
drivers/platform/chrome/cros_ec_typec.c | 136
1 file changed, 68 insertions(+), 68 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_typec.c
b/drivers/platform/chrome/cros_ec_typec.c
index 31be31161350
cros_typec_remove_partner() if there is a
valid registered partner pointer.
Signed-off-by: Prashant Malani
---
Changes in v2:
- No changes.
drivers/platform/chrome/cros_ec_typec.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/chrome/cros_ec_typec.c
b/drivers
The partner identity struct isn't reset when a partner is removed,
meaning a subsequent partner can inherit an old partner's identity VDOs
before discovery is complete. So, clear that struct when a partner
removal is detected.
Signed-off-by: Prashant Malani
---
Changes in v2:
-
://lore.kernel.org/lkml/20201021205317.708008-1-pmal...@chromium.org/
Changes in v2:
- Added missing static to function definition.
- Changes alt mode list traversal based on review comments.
- Rebased series on top of chrome-platform-5.11.
Prashant Malani (7):
platform/chrome: cros_ec_typec: Relocate
Use the discovery data from the Chrome EC to register parter altmodes
with the Type C Connector Class framework. Also introduce a node
struct to keep track of the list of registered alt modes.
Cc: Heikki Krogerus
Signed-off-by: Prashant Malani
---
Changes in v2:
- Changed list traversal during
feature flag, which is used to
determine whether these commands are supported by the EC.
[1]:
https://chromium.googlesource.com/chromiumos/platform/ec/+/refs/heads/master/include/ec_commands.h
Signed-off-by: Prashant Malani
---
Changes in v2:
- No changes.
.../linux/platform_data
.
Also check the EC_FEATURE_TYPEC_CMD feature flag at probe, and only call
the new TYPEC_STATUS command if the feature flag is supported.
Reported-by: kernel test robot
Signed-off-by: Prashant Malani
---
Changes in v2:
- Added missing 'static' keyword for cros_typec_cmds_supported()
Use EC_CMD_TYPE_DISCOVERY to retrieve and store the discovery data for
the port partner. With that data, update the PD Identity VDO values for
the partner, which were earlier not initialized.
Cc: Heikki Krogerus
Signed-off-by: Prashant Malani
---
Changes in v2:
- No changes
drivers/platform
Hi Rajmohan,
On Fri, Aug 21, 2020 at 09:05:06PM -0700, Rajmohan Mani wrote:
> Input Output Manager (IOM) is part of the Tiger Lake SoC that
> configures the Type-C Sub System (TCSS). IOM is a micro controller
> that handles Type-C topology, configuration and PM functions of
> various Type-C device
Hi,
On Fri, Jul 03, 2020 at 11:17:03AM +0300, Heikki Krogerus wrote:
> +static int cros_typec_enable_usb4(struct cros_typec_data *typec,
> + int port_num,
> + struct ec_response_usb_pd_control_v2 *pd_ctrl)
> +{
> + struct cros_typec_p
set to none.
Cc: Benson Leung
Cc: Heikki Krogerus
Cc: Rajmohan Mani
Fixes: f3c1c41ebc67 ("usb: typec: intel_pmc_mux: Add support for USB4")
Signed-off-by: Prashant Malani
---
drivers/usb/typec/mux/intel_pmc_mux.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drive
s the attribute value is -1.
We re-use the partner attribute for number_of_alternate_modes since the
usage and name is similar, and update the corresponding *_show() command
to support both partner and plugs.
Signed-off-by: Prashant Malani
---
Documentation/ABI/testing/sysfs-class-typec | 9 +
typec_plug_set_num_altmodes().
Signed-off-by: Prashant Malani
---
drivers/platform/chrome/cros_ec_typec.c | 50 -
1 file changed, 40 insertions(+), 10 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_typec.c
b/drivers/platform/chrome/cros_ec_typec.c
index
In order to register cable alternate modes, we need to first register a
plug object. Use the Type C connector class framework to register a SOP'
plug for this purpose.
Since a cable and plug go hand in hand, we can handle the registration
and removal together.
Signed-off-by: Prashant M
um.org/
[3]: https://lore.kernel.org/lkml/20201106184104.939284-1-pmal...@chromium.org/
[4]: https://lore.kernel.org/lkml/20201110061535.2163599-1-pmal...@chromium.org/
Prashant Malani (3):
usb: typec: Add plug num_altmodes sysfs attr
platform/chrome: cros_ec_typec: Register SOP' cable plug
Hi Heikki,
On Tue, Nov 10, 2020 at 01:54:53PM +0200, Heikki Krogerus wrote:
> On Fri, Oct 23, 2020 at 02:43:28PM -0700, Prashant Malani wrote:
>
> I've now come to the conclusion that this is not the correct approach.
> Instead, the whole identity, all six VDOs, should be supp
Hi Pi-Hsun,
I haven't gone through the code, but did have a high-level comment
(kindly see inline)
On Thu, Nov 12, 2020 at 02:40:40PM +0800, Pi-Hsun Shih wrote:
> When output 2 lanes DP data, anx7625 can output to either TX1/RX1 or
> TX2/RX2. In typical usage, these two TX/RX pairs corresponds to
On Thu, Nov 12, 2020 at 05:07:05PM +0800, Pi-Hsun Shih wrote:
> Hi Prashant,
>
> Please see inline reply as below.
>
> On Thu, Nov 12, 2020 at 4:59 PM Prashant Malani wrote:
> >
> > Hi Pi-Hsun,
> >
> > I haven't gone through the code, but did have
Hi Heikki,
On Thu, Nov 12, 2020 at 4:43 AM Heikki Krogerus
wrote:
>
> On Wed, Nov 11, 2020 at 06:40:55PM -0800, Prashant Malani wrote:
> > Hi Heikki,
> >
> > On Tue, Nov 10, 2020 at 01:54:53PM +0200, Heikki Krogerus wrote:
> > > On Fri, Oct 23, 2020 at 02:43:
Change the disc_done flag, which indicates whether PD discovery is
complete, to sop_disc_done instead, since we will process SOP and SOP'
discovery data separately.
Signed-off-by: Prashant Malani
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Heikki Krogerus
---
Changes in v3:
- Re-arr
s://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git/log/?h=for-next
Prashant Malani (11):
usb: pd: Add captive Type C cable type
usb: typec: Add number of altmodes partner attr
usb: typec: Add plug num_altmodes sysfs attr
platform/chrome: cros_ec_typec: Make disc_done flag partner
alue is -1.
Cc: Benson Leung
Cc: Heikki Krogerus
Signed-off-by: Prashant Malani
Reviewed-by: Heikki Krogerus
---
Changes in v3:
- Re-arranged patch order and combined it with related series of
patches.
- Added Reviewed-by tags
Changes in v2:
- Added ABI/testing documentation entry for a
Use the PD VDO Type C cable plug type macro to retrieve and store the
cable plug type in the cable descriptor.
Cc: Heikki Krogerus
Cc: Greg Kroah-Hartman
Signed-off-by: Prashant Malani
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Heikki Krogerus
---
Changes in v3:
- Re-arranged patch order
When the Chrome Embedded Controller notifies the driver that SOP'
discovery is complete, retrieve the PD discovery data and register a
cable object with the Type C connector class framework.
Cc: Heikki Krogerus
Signed-off-by: Prashant Malani
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: H
Factor out the PD identity parsing code into a separate function. This
way it can be re-used for Cable PD identity parsing in future patches.
No functional changes are introduced by this patch.
Signed-off-by: Prashant Malani
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Heikki Krogerus
s the attribute value is -1.
We re-use the partner attribute for number_of_alternate_modes since the
usage and name is similar, and update the corresponding *_show() command
to support both partner and plugs.
Signed-off-by: Prashant Malani
---
Changes in v3:
- Re-arranged patch order and combined
Set the number of altmodes available for a registered partner using the
Type C connector class framework routine.
Cc: Heikki Krogerus
Signed-off-by: Prashant Malani
Reviewed-by: Heikki Krogerus
---
Changes in v3:
- Re-arranged patch order and combined it with related series of
patches
Rename the sop_disc data struct which is used to store PD discovery data
to the more generic name of disc_data. It can then be re-used to store
and process cable discovery data.
Signed-off-by: Prashant Malani
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Heikki Krogerus
---
Changes in v3:
- Re
able connector type, when provided
the cable VDO.
Cc: Heikki Krogerus
Signed-off-by: Prashant Malani
Reviewed-by: Benson Leung
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Heikki Krogerus
---
Changes in v3:
- Re-arranged patch order and combined it with related series of
patches.
- Added Re
In order to register cable alternate modes, we need to first register a
plug object. Use the Type C connector class framework to register a SOP'
plug for this purpose.
Since a cable and plug go hand in hand, we can handle the registration
and removal together.
Signed-off-by: Prashant M
typec_plug_set_num_altmodes().
Signed-off-by: Prashant Malani
---
Changes in v3:
- Re-arranged patch order and combined it with related series of
patches.
No version v2.
drivers/platform/chrome/cros_ec_typec.c | 50 -
1 file changed, 40 insertions(+), 10 deletions
Hi Greg,
On Fri, Nov 13, 2020 at 6:13 AM Greg KH wrote:
>
> On Wed, Nov 11, 2020 at 05:23:25PM -0800, Prashant Malani wrote:
> > This patch series add plug registration support to the cros-ec-typec
> > driver. It also adds support for registering alternate modes for the
&
Hi All,
Was wondering if there were any comments on v3 of this series?
Best regards,
-Prashant
On Fri, Oct 23, 2020 at 02:43:28PM -0700, Prashant Malani wrote:
> A PD-capable device can return up to 3 Product Type VDOs as part of its
> DiscoverIdentity Response (USB PD Spec, Rev 3.0, V
plug field, and then use
the added macro to add the corresponding field of the Type C cable
descriptor in the cros-ec-typec driver.
Prashant Malani (6):
platform/chrome: cros_ec_typec: Make disc_done flag partner-only
platform/chrome: cros_ec_typec: Factor out PD identity parsing
platform
Change the disc_done flag, which indicates whether PD discovery is
complete, to sop_disc_done instead, since we will process SOP and SOP'
discovery data separately.
Signed-off-by: Prashant Malani
---
drivers/platform/chrome/cros_ec_typec.c | 19 +++
1 file changed, 7 inser
When the Chrome Embedded Controller notifies the driver that SOP'
discovery is complete, retrieve the PD discovery data and register a
cable object with the Type C connector class framework.
Cc: Heikki Krogerus
Signed-off-by: Prashant Malani
---
drivers/platform/chrome/cros_ec_typec.c
Factor out the PD identity parsing code into a separate function. This
way it can be re-used for Cable PD identity parsing in future patches.
No functional changes are introduced by this patch.
Signed-off-by: Prashant Malani
---
drivers/platform/chrome/cros_ec_typec.c | 35
Rename the sop_disc data struct which is used to store PD discovery data
to the more generic name of disc_data. It can then be re-used to store
and process cable discovery data.
Signed-off-by: Prashant Malani
---
drivers/platform/chrome/cros_ec_typec.c | 10 +-
1 file changed, 5
Use the PD VDO Type C cable plug type macro to retrieve and store the
cable plug type in the cable descriptor.
Cc: Heikki Krogerus
Cc: Greg Kroah-Hartman
Signed-off-by: Prashant Malani
---
drivers/platform/chrome/cros_ec_typec.c | 21 -
1 file changed, 20 insertions(+), 1
able connector type, when provided
the cable VDO.
Cc: Heikki Krogerus
Signed-off-by: Prashant Malani
---
include/linux/usb/pd_vdo.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/usb/pd_vdo.h b/include/linux/usb/pd_vdo.h
index 68bdc4e2f5a9..8c5cb5830754 100644
to a driver abort.
Modify the mux configuration handling to not return an error when an
unrecognized mux flag combination is encountered. Concordantly, make the
ensuing print a debug level print so as to not pollute the kernel logs.
Cc: Keith Short
Signed-off-by: Prashant Malani
---
drivers/pla
Set the number of altmodes available for a registered partner using the
Type C connector class framework routine.
Cc: Heikki Krogerus
Signed-off-by: Prashant Malani
---
Changes in v2:
- Patch introduced for the first time in v2.
drivers/platform/chrome/cros_ec_typec.c | 8
1 file
alue is -1.
Cc: Benson Leung
Cc: Heikki Krogerus
Signed-off-by: Prashant Malani
---
Changes in v2:
- Added ABI/testing documentation entry for added sysfs file.
- Changed name of the sysfs file to "number_of_alternate_modes" based on
review comments.
- Added is_visible() logic s
Hi Greg,
Thanks for looking at the patch.
On Fri, Nov 06, 2020 at 08:20:59AM +0100, Greg Kroah-Hartman wrote:
> On Thu, Nov 05, 2020 at 05:28:03PM -0800, Prashant Malani wrote:
> > Use the PD VDO Type C cable plug type macro to retrieve and store the
> > cable plug type in the c
Hi Greg,
On Fri, Nov 06, 2020 at 10:33:02AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Nov 06, 2020 at 12:59:07AM -0800, Prashant Malani wrote:
> > Hi Greg,
> >
> > Did you not receive these?
>
> Ah, I got 1, 2, and 5, and now 6. That's confusing, think about
Change the disc_done flag, which indicates whether PD discovery is
complete, to sop_disc_done instead, since we will process SOP and SOP'
discovery data separately.
Signed-off-by: Prashant Malani
---
Changes in v2:
- No changes.
drivers/platform/chrome/cros_ec_typec.c
Rename the sop_disc data struct which is used to store PD discovery data
to the more generic name of disc_data. It can then be re-used to store
and process cable discovery data.
Signed-off-by: Prashant Malani
---
Changes in v2:
- No changes.
drivers/platform/chrome/cros_ec_typec.c | 10
variable uint32_t to u32 in patch 6/6.
Prashant Malani (6):
platform/chrome: cros_ec_typec: Make disc_done flag partner-only
platform/chrome: cros_ec_typec: Factor out PD identity parsing
platform/chrome: cros_ec_typec: Rename discovery struct
platform/chrome: cros_ec_typec: Register cable
usb
When the Chrome Embedded Controller notifies the driver that SOP'
discovery is complete, retrieve the PD discovery data and register a
cable object with the Type C connector class framework.
Cc: Heikki Krogerus
Signed-off-by: Prashant Malani
---
Changes in v2:
- No changes.
drivers/pla
Use the PD VDO Type C cable plug type macro to retrieve and store the
cable plug type in the cable descriptor.
Cc: Heikki Krogerus
Cc: Greg Kroah-Hartman
Signed-off-by: Prashant Malani
---
Changes in v2:
- Changed local variable from uint32_to u32.
drivers/platform/chrome/cros_ec_typec.c
Factor out the PD identity parsing code into a separate function. This
way it can be re-used for Cable PD identity parsing in future patches.
No functional changes are introduced by this patch.
Signed-off-by: Prashant Malani
---
Changes in v2:
- No changes.
drivers/platform/chrome
able connector type, when provided
the cable VDO.
Cc: Heikki Krogerus
Signed-off-by: Prashant Malani
---
Changes in v2:
- No changes.
include/linux/usb/pd_vdo.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/usb/pd_vdo.h b/include/linux/usb/pd_vdo.h
inde
Signed-off-by: Prashant Malani
---
drivers/platform/chrome/cros_ec_typec.c | 83 +
1 file changed, 42 insertions(+), 41 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_typec.c
b/drivers/platform/chrome/cros_ec_typec.c
index 0c041b79cbba..43e7cf367a07 100644
---
Hi Rob,
Just checking in again to see if you have any thoughts about the
proposal outlined in previous emails in this thread.
Best regards,
On Fri, Jul 10, 2020 at 1:51 AM Prashant Malani wrote:
>
> Hi Rob,
>
> Thought I'd check in again to see if you've had a chance to l
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
> UFP.
nit: DFP
>
> Fixes: 7e7def15fa4b ("platform/chrome: cros_ec_typec: Add USB mux control")
> Signed-off-by: Azhar Shaik
ror codes to report
> a more meaningful error to the caller to aid debugging.
>
> Cc: Yu-Hsuan Hsu
> Cc: Prashant Malani
> Signed-off-by: Guenter Roeck
> ---
> drivers/platform/chrome/cros_ec_proto.c | 37 +++--
> 1 file changed, 29 insertions(+),
On Mon, Jul 6, 2020 at 12:41 PM Guenter Roeck wrote:
>
> On Mon, Jul 06, 2020 at 11:52:30AM -0700, Prashant Malani wrote:
> > Hi Guenter,
> >
> > On Sat, Jul 04, 2020 at 07:26:07AM -0700, Guenter Roeck wrote:
> > > The EC reports a variety of error codes.
Hi Heikki,
On Fri, Jul 03, 2020 at 11:17:03AM +0300, Heikki Krogerus wrote:
> With USB4 mode the mux driver needs the Enter_USB Data
> Object (EUDO) that was used when the USB mode was entered.
> Though the object is not available in the driver, it is
> possible to construct it from the informatio
On Mon, Jul 6, 2020 at 2:38 PM Guenter Roeck wrote:
>
> On 7/6/20 1:07 PM, Prashant Malani wrote:
> > On Mon, Jul 6, 2020 at 12:41 PM Guenter Roeck wrote:
> >>
> >> On Mon, Jul 06, 2020 at 11:52:30AM -0700, Prashant Malani wrote:
> >>> Hi Guenter,
>
On Wed, Jul 22, 2020 at 8:27 AM Enric Balletbo i Serra
wrote:
>
> Hi Prashant,
>
> On 21/7/20 21:55, Prashant Malani wrote:
> > Hey Enric, Benson,
> >
> > Just wondering if you've had a chance to review this patch.
> >
>
> It's on my rad
Hey Enric, Benson,
Just wondering if you've had a chance to review this patch.
Best regards,
-Prashant
On Fri, Jul 10, 2020 at 12:40 PM Prashant Malani wrote:
>
> From: Heikki Krogerus
>
> With USB4 mode the mux driver needs the Enter_USB Data
> Object (EUDO) that was us
e this thread is now nearly 3 months
old, it would be nice to arrive at a decision.
Best regards,
On Mon, Jun 29, 2020 at 1:41 PM Prashant Malani wrote:
>
> Hi Rob,
>
> Just following up on this. Would the below example align better with
> OF graph requirements?
>
> Example
: Prashant Malani
---
This patch depends on latest usb-next from Greg KH, this commit in
particular:
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next&id=ad8db94d6813dc659bd4de0531a8a1150559eafb
Changes in v2:
- Removed EUDO bits for cable current and tunne
Thanks Enric,
On Mon, Sep 7, 2020 at 3:48 AM Enric Balletbo i Serra
wrote:
>
> Hi Prashant,
>
> Thank you for your patch.
>
> On 3/9/20 11:54, Prashant Malani wrote:
> > Since all the other call-sites of cros_ec_cmd_xfer() have been converted
> > to use cros_ec_cmd
registered with the connector class framework.
This value is set to "-1" initially, which is an invalid value,
signifying that a valid number of alt modes haven't been set for the
partner.
Signed-off-by: Prashant Malani
Cc: Benson Leung
---
drivers/usb/typ
101 - 200 of 225 matches
Mail list logo
