On Thu, Nov 23, 2017 at 3:10 AM, Adam Thomson
<adam.thomson.opensou...@diasemi.com> wrote:
> On 16 November 2017 01:02, Badhri Jagan Sridharan wrote:
>
>> At present, TCPM code assumes that local device supports
>> variable/batt pdos and always selects the pdo with highest
bject position field.
This enables the Sink to indicate that it requires more current/power
than is being offered. If the Sink requires a different voltage this
will be indicated by its Sink Capabilities message.
Signed-off-by: Badhri Jagan Sridharan <bad...@google.com>
Acked-by: Heik
.
Errors in source/sink_caps of the local port will prevent
the port registration. Whereas, errors in source caps of partner
device would only log them.
Signed-off-by: Badhri Jagan Sridharan <bad...@google.com>
Acked-by: Heikki Krogerus <heikki.kroge...@linux.intel.com>
Reviewed-by: G
On Tue, Nov 14, 2017 at 9:05 AM, Guenter Roeck <li...@roeck-us.net> wrote:
> On Sun, Nov 12, 2017 at 04:23:17PM -0800, Badhri Jagan Sridharan wrote:
>> At present, TCPM code assumes that local device supports
>> variable/batt pdos and always selects the pdo with highest
>
bject position field.
This enables the Sink to indicate that it requires more current/power
than is being offered. If the Sink requires a different voltage this
will be indicated by its Sink Capabilities message.
Signed-off-by: Badhri Jagan Sridharan <bad...@google.com>
Acked-by: Heik
.
Errors in source/sink_caps of the local port will prevent
the port registration. Whereas, errors in source caps of partner
device would only log them.
Signed-off-by: Badhri Jagan Sridharan <bad...@google.com>
Acked-by: Heikki Krogerus <heikki.kroge...@linux.intel.com>
---
Change
On Tue, Nov 7, 2017 at 4:07 AM, Heikki Krogerus
<heikki.kroge...@linux.intel.com> wrote:
> On Sat, Nov 04, 2017 at 12:22:13PM -0700, Badhri Jagan Sridharan wrote:
>> At present, TCPM code assumes that local device supports
>> variable/batt pdos and always selects the pdo wit
Thanks Heikki !
I am making another version addressing your nits as well.
Guenter, Are you fine with the patch as well ?
Regards,
Badhri
On Tue, Nov 7, 2017 at 3:00 AM, Heikki Krogerus
<heikki.kroge...@linux.intel.com> wrote:
> On Sat, Nov 04, 2017 at 12:22:12PM -0700, Badhri Jagan
bject position field.
This enables the Sink to indicate that it requires more current/power
than is being offered. If the Sink requires a different voltage this
will be indicated by its Sink Capabilities message.
Signed-off-by: Badhri Jagan Sridharan <bad...@google.com>
---
Changelog since v1
.
Errors in source/sink_caps of the local port will prevent
the port registration. Whereas, errors in source caps of partner
device would only log them.
Signed-off-by: Badhri Jagan Sridharan <bad...@google.com>
---
hangelog since v1:
- rebased on top drivers/usb/typec/tcpm.c as suggested by
Please disregard v4. Going to send another version again.
On Sat, Nov 4, 2017 at 11:59 AM, Badhri Jagan Sridharan
<bad...@google.com> wrote:
> The source and sink caps should follow the following rules.
> This patch validates whether the src_caps/snk_caps adheres
> to it.
>
&g
Please disregard v4. Going to send another version again.
On Sat, Nov 4, 2017 at 11:59 AM, Badhri Jagan Sridharan
<bad...@google.com> wrote:
> At present, TCPM code assumes that local device supports
> variable/batt pdos and always selects the pdo with highest
> possible power w
.
Errors in source/sink_caps of the local port will prevent
the port registration. Whereas, errors in source caps of partner
device would only log them.
Signed-off-by: Badhri Jagan Sridharan <bad...@google.com>
---
Changelog since v1:
- rebased on top drivers/usb/typec/tcpm.c as suggested by
bject position field.
This enables the Sink to indicate that it requires more current/power
than is being offered. If the Sink requires a different voltage this
will be indicated by its Sink Capabilities message.
Signed-off-by: Badhri Jagan Sridharan <bad...@google.com>
---
Changelog since v1
requires more current/power
>> than is being offered. If the Sink requires a different voltage this
>> will be indicated by its Sink Capabilities message.
>>
>> Signed-off-by: Badhri Jagan Sridharan <bad...@google.com>
>> ---
>> Changelog since
bject position field.
This enables the Sink to indicate that it requires more current/power
than is being offered. If the Sink requires a different voltage this
will be indicated by its Sink Capabilities message.
Signed-off-by: Badhri Jagan Sridharan <bad...@google.com>
---
Changelog since v1
.
Errors in source/sink_caps of the local port will prevent
the port registration. Whereas, errors in source caps of partner
device would only log them.
Signed-off-by: Badhri Jagan Sridharan <bad...@google.com>
---
Changelog since v1:
- rebased on top drivers/usb/typec/tcpm.c as suggested by
bject position field.
This enables the Sink to indicate that it requires more current/power
than is being offered. If the Sink requires a different voltage this
will be indicated by its Sink Capabilities message.
Signed-off-by: Badhri Jagan Sridharan <bad...@google.com>
---
Changelog since v1
.
Errors in source/sink_caps of the local port will prevent
the port registration. Whereas, errors in source caps of partner
device would only log them.
Signed-off-by: Badhri Jagan Sridharan <bad...@google.com>
---
Changelog since v1:
- Rebased the patch on top of drivers/usb/type/tcpm.c
-
AM, Badhri Jagan Sridharan
<bad...@google.com> wrote:
> On Tue, Aug 15, 2017 at 6:36 AM, Heikki Krogerus
> <heikki.kroge...@linux.intel.com> wrote:
>> Hi,
>>
>> On Mon, Aug 14, 2017 at 11:57:15AM -0700, Badhri Jagan Sridharan wrote:
>>> Hi Heikki,
>&
On Tue, Aug 15, 2017 at 6:36 AM, Heikki Krogerus
<heikki.kroge...@linux.intel.com> wrote:
> Hi,
>
> On Mon, Aug 14, 2017 at 11:57:15AM -0700, Badhri Jagan Sridharan wrote:
>> Hi Heikki,
>>
>> While testing with different type-c phones available in the marke
Add super speed descriptors for f_midi.
Signed-off-by: Badhri Jagan Sridharan <bad...@google.com>
---
drivers/usb/gadget/function/f_midi.c | 42 +---
1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/function/f_midi.c
b/drive
Hi Heikki,
While testing with different type-c phones available in the market,
With some phones, I noticed that supports_usb_power_delivery
reports "no" eventhough an explicit pd contract has been
established. After spending sometime debugging, I noticed that
the root cause of this is that the
are good with the CL as well :)
Thanks,
Badhri.
On Mon, Jun 5, 2017 at 2:56 AM, Heikki Krogerus
<heikki.kroge...@linux.intel.com> wrote:
> Hi,
>
> Sorry for the late reply. I was unable to follow my email last week.
>
> On Tue, May 30, 2017 at 12:39:53PM -0700, Badhri Jagan Sridharan
Noticed that I accidentally dropped the ABI documentation for the new
port_type node during patchset revision.
Adding that back and resubmitting the patch.
Thanks,
Badhri.
On Mon, May 29, 2017 at 1:07 PM, Badhri Jagan Sridharan
<bad...@google.com> wrote:
> Thanks for all the review
I/testing/sysfs-class-typec
@@ -30,6 +30,21 @@ Description:
Valid values: source, sink
+What: /sys/class/typec//port_type
+Date: May 2017
+Contact: Badhri Jagan Sridharan <bad...@google.com>
+Description:
+ Indicates the type of the por
Thanks for all the reviews Guenter & Heikki.
Heikki, Is there anything else that I need to address in this patch ?
Or is the patch ready to be merged ?
Thanks,
Badhri
On Mon, May 29, 2017 at 12:56 PM, Badhri Jagan Sridharan
<bad...@google.com> wrote:
> User space applications in so
User space applications in some cases have the need to enforce a
specific port type(DFP/UFP/DRP). This change allows userspace to
attempt setting the desired port type. Low level drivers can
however reject the request if the specific port type is not supported.
Signed-off-by: Badhri Jagan
User space applications in some cases have the need to enforce a
specific port type(DFP/UFP/DRP). This change allows userspace to
attempt setting the desired port type. Low level drivers can
however reject the request if the specific port type is not supported.
Signed-off-by: Badhri Jagan
On Fri, May 26, 2017 at 10:43 PM, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
> On Fri, May 26, 2017 at 01:42:57PM -0700, Badhri Jagan Sridharan wrote:
>> User space applications in some cases have the need to enforce a
>> specific port type(DFP/UFP/DRP). This ch
Thanks Geunter for comments. Will fix them in my next patch.
On Fri, May 26, 2017 at 7:24 PM, Guenter Roeck <li...@roeck-us.net> wrote:
> On 05/26/2017 04:07 PM, Badhri Jagan Sridharan wrote:
>>
>> User space applications in some cases have the need to enforce a
>> spe
User space applications in some cases have the need to enforce a
specific port type(DFP/UFP/DRP). This change allows userspace to
attempt setting the desired port type. Low level drivers can
however reject the request if the specific port type is not supported.
Signed-off-by: Badhri Jagan
On Fri, May 26, 2017 at 11:31 AM, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
> On Fri, May 26, 2017 at 10:45:59AM -0700, Badhri Jagan Sridharan wrote:
>> User space applications in some cases have the need to enforce a
>> specific port type(DFP/UFP/DRP). This ch
User space applications in some cases have the need to enforce a
specific port type(DFP/UFP/DRP). This change allows userspace to
attempt setting the desired port type. Low level drivers can
however reject the request if the specific port type is not supported.
Signed-off-by: Badhri Jagan
On Fri, May 26, 2017 at 11:00 AM, Guenter Roeck <li...@roeck-us.net> wrote:
> On Fri, May 26, 2017 at 10:45:59AM -0700, Badhri Jagan Sridharan wrote:
>> User space applications in some cases have the need to enforce a
>> specific port type(DFP/UFP/DRP). This change allows us
User space applications in some cases have the need to enforce a
specific port type(DFP/UFP/DRP). This change allows userspace to
attempt setting the desired port type. Low level drivers can
however reject the request if the specific port type is not supported.
Signed-off-by: Badhri Jagan
On Thu, May 25, 2017 at 12:48 AM, Guenter Roeck <li...@roeck-us.net> wrote:
> On 05/24/2017 08:10 PM, Badhri Jagan Sridharan wrote:
>>
>> Thanks comments inline.
>>
>> On Tue, May 23, 2017 at 7:38 PM, Guenter Roeck <li...@roeck-us.net> wrote:
>>>
&g
Thanks comments inline.
On Tue, May 23, 2017 at 7:38 PM, Guenter Roeck <li...@roeck-us.net> wrote:
> On 05/23/2017 06:28 PM, Badhri Jagan Sridharan wrote:
>>
>> User space applications in some cases have the need to enforce a
>> specific port type(DFP/UFP/DRP). T
User space applications in some cases have the need to enforce a
specific port type(DFP/UFP/DRP). This change allows userspace to
attempt setting the desired port type. Low level drivers can
however reject the request if the specific port type is not supported.
Signed-off-by: Badhri Jagan
User space applications in some cases have the need to enforce a
specific port type(DFP/UFP/DRP). This change allows userspace to
attempt setting the desired port type. Low level drivers can
however reject the request if the specific port type is not supported.
Signed-off-by: Badhri Jagan
Not Sure whether my previous response was sent properly.
So re-sending.
On Thu, May 18, 2017 at 2:08 PM, Badhri Jagan Sridharan
<bad...@google.com> wrote:
> On Thu, May 18, 2017 at 9:51 AM, Guenter Roeck <li...@roeck-us.net> wrote:
>> On Thu, May 18, 2017 at 11:13:51AM +0200
;
>> > > Am Mittwoch, den 17.05.2017, 00:32 -0700 schrieb Badhri Jagan
>> > > Sridharan:
>> > >
>> > > Hi,
>> > >
>> > > >
>> > > > "Two independent set of mechanisms are defined to allow a USB Type-C
&
ck wrote:
> > > > On 05/17/2017 12:34 AM, Oliver Neukum wrote:
> > > > > Am Mittwoch, den 17.05.2017, 00:32 -0700 schrieb Badhri Jagan
> > > > > Sridharan:
> > > > >
> > > > > Hi,
> > > > >
> >
on-PD implementations,
power/data role swapping can optionally be dealt with as part of the initial
connection process."
Signed-off-by: Badhri Jagan Sridharan <bad...@google.com>
---
Documentation/ABI/testing/sysfs-class-typec | 7 +--
drivers/usb/typec/typec.c |
On Sat, Apr 22, 2017 at 2:23 AM, Rajaram R <rajaram.officem...@gmail.com> wrote:
> On Fri, Apr 21, 2017 at 10:13 PM, Guenter Roeck <li...@roeck-us.net> wrote:
>> On Fri, Apr 21, 2017 at 07:57:52PM +0530, Rajaram R wrote:
>>> On Fri, Apr 21, 2017 at 1:16 AM, B
them ?
Thanks for the support !!
Badhri.
On Thu, Apr 20, 2017 at 5:24 AM, Heikki Krogerus
<heikki.kroge...@linux.intel.com> wrote:
> On Wed, Apr 19, 2017 at 10:22:47AM -0700, Badhri Jagan Sridharan wrote:
>> On Wed, Apr 19, 2017 at 8:14 AM, Guenter Roeck <li...@roeck-us.net&g
On Wed, Apr 19, 2017 at 8:14 AM, Guenter Roeck <li...@roeck-us.net> wrote:
> On Wed, Apr 19, 2017 at 07:45:00AM -0700, Badhri Jagan Sridharan wrote:
>> On Wed, Apr 19, 2017 at 4:23 AM, Heikki Krogerus
>> <heikki.kroge...@linux.intel.com> wrote:
>> > Hi,
>>
On Wed, Apr 19, 2017 at 4:23 AM, Heikki Krogerus
<heikki.kroge...@linux.intel.com> wrote:
> Hi,
>
> On Tue, Apr 18, 2017 at 11:52:33AM -0700, Badhri Jagan Sridharan wrote:
>> Hi Heikki,
>>
>> I have a question regarding the preferred_role node.
>&
Hi Heikki,
I have a question regarding the preferred_role node.
+What: /sys/class/typec//preferred_role
+Date: March 2017
+Contact: Heikki Krogerus
+Description:
+ The user space can notify the driver about the preferred
> Yes, though I don't KOBJ_ADD separately with the partners and cables.
> That uevent is sent when the device for them is registered, so it's
> already there
Makes sense. Thanks Heikki.
Regards,
Badhri
On Wed, Nov 16, 2016 at 7:20 AM, Heikki Krogerus
wrote:
>
> IMHO the uevent is cheaper. User space cannot just poll without further
> infrastructure. A task needs to run to poll. A uevent can be handled
> through established infrastructure.
Thanks Oliver for stating this. This is exactly what I was facing.
> OK, I'll add KOBJ_CHANGE for those.
>
> So
Hi,
At present I am using the uevent in the userspace to infer
the Presence of a port on the remote end through the
appearance of usbc*-partner.
Userspace uses this info to decide on when to show a USB
notification on the screen and what should be the options
provided in the dialog.
I was
Hi all,
I do agree that udc-core's uevents can potentially be used here.
I will check the complete list of uevents sent by the udc-core's
usb_gadget_set_state function and see if the userspace is happy to work with it.
Now that Android is starting to use the configfs driver, it might be
much
Hi,
With the advent of USB PD over type-C connector, the data_roles and
the power_roles can be swapped independently. i.e. now the host for
the data need not have to be powering VBUS. Going through the phy
code(drivers/usb/phy/phy.c) makes me think that the phy layer assumes
that both the
/ERROR msg and
returning not the preferable approach ?
On 03/22/2015 12:43 AM, Peter Chen wrote:
On Fri, Mar 20, 2015 at 04:40:52PM -0700, Badhri Jagan Sridharan wrote:
Added a safety net to make sure that
composite_disconnect does not end up disconneting
a NULL device. Prevents NULL pointer
Added a safety net to make sure that
composite_disconnect does not end up disconneting
a NULL device. Prevents NULL pointer crash.
Signed-off-by: Badhri Jagan Sridharan bad...@google.com
---
drivers/usb/gadget/composite.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/usb
56 matches
Mail list logo