[ANNOUNCE] libtypec_0.1/lstypec_0.1 is released

[ANNOUNCE] libtypec_0.1/lstypec_0.1 is released

[Rajaram Regupathy]

HI

libtypec
++++++

USB-Type C and USB Power Delivery systems are with multiple
specification versions, platform designs and microcontroller vendors
for managing  data, power and display.

libtypec is aimed to provide a generic way for userspace System
Software on Linux, Android, Chrome OS or Other OSes to build developer
tools or
other management applications for USB-Type C and USB Power Delivery
class devices.

Features
======
- libtypec - get method for port and port-partner capabilities
-  utils/lstypec -  displaying information about USB typec class
devices in the system and the devices connected to them

Release:
=======

Binary : https://github.com/Rajaram-Regupathy/libtypec/releases/download/libtypec_v0.1/libtypec_0.1.tar.xz
Source : https://github.com/Rajaram-Regupathy/libtypec/archive/refs/tags/libtypec_v0.1.tar.gz

Re: [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released

[Stephan Brunner]

Hi,

where's the license? Can't find one.

-Stephan

Am Sunday, dem 16.01.2022 um 20:49 +0530 schrieb Rajaram Regupathy:
> HI
> 
> libtypec
> ++++++
> 
> USB-Type C and USB Power Delivery systems are with multiple
> specification versions, platform designs and microcontroller vendors
> for managing  data, power and display.
> 
> libtypec is aimed to provide a generic way for userspace System
> Software on Linux, Android, Chrome OS or Other OSes to build
> developer
> tools or
> other management applications for USB-Type C and USB Power Delivery
> class devices.
> 
> Features
> ======
> - libtypec - get method for port and port-partner capabilities
> -  utils/lstypec -  displaying information about USB typec class
> devices in the system and the devices connected to them
> 
> Release:
> =======
> 
> Binary :
> https://github.com/Rajaram-Regupathy/libtypec/releases/download/libtypec_v0.1/libtypec_0.1.tar.xz
> Source :
> https://github.com/Rajaram-Regupathy/libtypec/archive/refs/tags/libtypec_v0.1.tar.gz

Re: [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released

[Greg KH]

On Sun, Jan 16, 2022 at 08:49:47PM +0530, Rajaram Regupathy wrote:
> HI
> 
> libtypec
> ++++++
> 
> USB-Type C and USB Power Delivery systems are with multiple
> specification versions, platform designs and microcontroller vendors
> for managing  data, power and display.
> 
> libtypec is aimed to provide a generic way for userspace System
> Software on Linux, Android, Chrome OS or Other OSes to build developer
> tools or
> other management applications for USB-Type C and USB Power Delivery
> class devices.

Great, can we add this to the usbutils package, and `lsusb`?

> Features
> ======
> - libtypec - get method for port and port-partner capabilities
> -  utils/lstypec -  displaying information about USB typec class
> devices in the system and the devices connected to them
> 
> Release:
> =======
> 
> Binary : https://github.com/Rajaram-Regupathy/libtypec/releases/download/libtypec_v0.1/libtypec_0.1.tar.xz
> Source : https://github.com/Rajaram-Regupathy/libtypec/archive/refs/tags/libtypec_v0.1.tar.gz

Like was pointed out, there is no license listed for this code, so no
one can use it.

Also, it doesn't build for me:
	$ make
	 50%] Building C object CMakeFiles/lstypec.dir/lstypec.c.o
	100%] Linking C executable lstypec
	usr/bin/ld: /home/gregkh/tmp/libtypec/bin/liblibtypec.a(libtypec.c.o):(.bss+0x0): multiple definition of `__packed'; CMakeFiles/lstypec.dir/lstypec.c.o:(.bss+0x0): first defined here
	usr/bin/ld: /home/gregkh/tmp/libtypec/bin/liblibtypec.a(libtypec_sysfs_ops.c.o):(.bss+0x0): multiple definition of `__packed'; CMakeFiles/lstypec.dir/lstypec.c.o:(.bss+0x0): first defined here
	ollect2: error: ld returned 1 exit status
	ake[2]: *** [CMakeFiles/lstypec.dir/build.make:98: lstypec] Error 1
	ake[1]: *** [CMakeFiles/Makefile2:839: CMakeFiles/lstypec.dir/all] Error 2
	ake: *** [Makefile:121: all] Error 2

Why does this need to be a library at all?

thanks,

greg k-h

Re: [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released

[Rajaram Regupathy]

On Mon, Jan 17, 2022 at 12:48 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Sun, Jan 16, 2022 at 08:49:47PM +0530, Rajaram Regupathy wrote:
> > HI
> >
> > libtypec
> > ++++++
> >
> > USB-Type C and USB Power Delivery systems are with multiple
> > specification versions, platform designs and microcontroller vendors
> > for managing  data, power and display.
> >
> > libtypec is aimed to provide a generic way for userspace System
> > Software on Linux, Android, Chrome OS or Other OSes to build developer
> > tools or
> > other management applications for USB-Type C and USB Power Delivery
> > class devices.
>
> Great, can we add this to the usbutils package, and `lsusb`?
Thanks. Yes, the goal is to have it in usbutils package.  The thought
to have  lstypec outside lsusb is as follows :

"lsusb" displays USB device details based on the USB device's "descriptors'' .
lstypec is for displaying usb-c "port capability" and the usb-c
partner "port/plug capabilities' ' and
the information is agnostic to USB descriptor topology or USB bus.
Ex: usb-c power adapters or usb-c display dongle or a usb-c e-cable etc..

Open to hear your recommendations.

>
> > Features
> > ======
> > - libtypec - get method for port and port-partner capabilities
> > -  utils/lstypec -  displaying information about USB typec class
> > devices in the system and the devices connected to them
> >
> > Release:
> > =======
> >
> > Binary : https://github.com/Rajaram-Regupathy/libtypec/releases/download/libtypec_v0.1/libtypec_0.1.tar.xz
> > Source : https://github.com/Rajaram-Regupathy/libtypec/archive/refs/tags/libtypec_v0.1.tar.gz
>
> Like was pointed out, there is no license listed for this code, so no
> one can use it.
>
> Also, it doesn't build for me:

Could you please follow  the Readme steps..?

>         $ make
>          50%] Building C object CMakeFiles/lstypec.dir/lstypec.c.o
>         100%] Linking C executable lstypec
>         usr/bin/ld: /home/gregkh/tmp/libtypec/bin/liblibtypec.a(libtypec.c.o):(.bss+0x0): multiple definition of `__packed'; CMakeFiles/lstypec.dir/lstypec.c.o:(.bss+0x0): first defined here
>         usr/bin/ld: /home/gregkh/tmp/libtypec/bin/liblibtypec.a(libtypec_sysfs_ops.c.o):(.bss+0x0): multiple definition of `__packed'; CMakeFiles/lstypec.dir/lstypec.c.o:(.bss+0x0): first defined here
>         ollect2: error: ld returned 1 exit status
>         ake[2]: *** [CMakeFiles/lstypec.dir/build.make:98: lstypec] Error 1
>         ake[1]: *** [CMakeFiles/Makefile2:839: CMakeFiles/lstypec.dir/all] Error 2
>         ake: *** [Makefile:121: all] Error 2
>
> Why does this need to be a library at all?
>
> thanks,
>
> greg k-h

Re: [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released

[Greg KH]

On Mon, Jan 17, 2022 at 08:07:58PM +0530, Rajaram Regupathy wrote:
> On Mon, Jan 17, 2022 at 12:48 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Sun, Jan 16, 2022 at 08:49:47PM +0530, Rajaram Regupathy wrote:
> > > HI
> > >
> > > libtypec
> > > ++++++
> > >
> > > USB-Type C and USB Power Delivery systems are with multiple
> > > specification versions, platform designs and microcontroller vendors
> > > for managing  data, power and display.
> > >
> > > libtypec is aimed to provide a generic way for userspace System
> > > Software on Linux, Android, Chrome OS or Other OSes to build developer
> > > tools or
> > > other management applications for USB-Type C and USB Power Delivery
> > > class devices.
> >
> > Great, can we add this to the usbutils package, and `lsusb`?
> Thanks. Yes, the goal is to have it in usbutils package.  The thought
> to have  lstypec outside lsusb is as follows :
> 
> "lsusb" displays USB device details based on the USB device's "descriptors'' .
> lstypec is for displaying usb-c "port capability" and the usb-c
> partner "port/plug capabilities' ' and
> the information is agnostic to USB descriptor topology or USB bus.
> Ex: usb-c power adapters or usb-c display dongle or a usb-c e-cable etc..
> 
> Open to hear your recommendations.

It's fine to keep it as a separate program to type, or you can make it
an option for 'lsusb' to output "lsusb --ports" or something?

As your code is pretty tiny, and only reads from sysfs, it shouldn't be
hard to integrate.  But you do need to fix the license issue :)

> > > Features
> > > ======
> > > - libtypec - get method for port and port-partner capabilities
> > > -  utils/lstypec -  displaying information about USB typec class
> > > devices in the system and the devices connected to them
> > >
> > > Release:
> > > =======
> > >
> > > Binary : https://github.com/Rajaram-Regupathy/libtypec/releases/download/libtypec_v0.1/libtypec_0.1.tar.xz
> > > Source : https://github.com/Rajaram-Regupathy/libtypec/archive/refs/tags/libtypec_v0.1.tar.gz
> >
> > Like was pointed out, there is no license listed for this code, so no
> > one can use it.
> >
> > Also, it doesn't build for me:
> 
> Could you please follow  the Readme steps..?
> 
> >         $ make
> >          50%] Building C object CMakeFiles/lstypec.dir/lstypec.c.o
> >         100%] Linking C executable lstypec
> >         usr/bin/ld: /home/gregkh/tmp/libtypec/bin/liblibtypec.a(libtypec.c.o):(.bss+0x0): multiple definition of `__packed'; CMakeFiles/lstypec.dir/lstypec.c.o:(.bss+0x0): first defined here
> >         usr/bin/ld: /home/gregkh/tmp/libtypec/bin/liblibtypec.a(libtypec_sysfs_ops.c.o):(.bss+0x0): multiple definition of `__packed'; CMakeFiles/lstypec.dir/lstypec.c.o:(.bss+0x0): first defined here
> >         ollect2: error: ld returned 1 exit status
> >         ake[2]: *** [CMakeFiles/lstypec.dir/build.make:98: lstypec] Error 1
> >         ake[1]: *** [CMakeFiles/Makefile2:839: CMakeFiles/lstypec.dir/all] Error 2
> >         ake: *** [Makefile:121: all] Error 2

I did follow the readme steps, what did I miss?

If I delete the one instance of "__packed" from the project, it does
build for me.  Perhaps you need to make sure that is defined in your
compiler flags?

> > Why does this need to be a library at all?

Again, why does this have to be a library?

thanks,

greg k-h

Re: [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released

[Rajaram Regupathy]

On Mon, Jan 17, 2022 at 9:08 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Mon, Jan 17, 2022 at 08:07:58PM +0530, Rajaram Regupathy wrote:
> > On Mon, Jan 17, 2022 at 12:48 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Sun, Jan 16, 2022 at 08:49:47PM +0530, Rajaram Regupathy wrote:
> > > > HI
> > > >
> > > > libtypec
> > > > ++++++
> > > >
> > > > USB-Type C and USB Power Delivery systems are with multiple
> > > > specification versions, platform designs and microcontroller vendors
> > > > for managing  data, power and display.
> > > >
> > > > libtypec is aimed to provide a generic way for userspace System
> > > > Software on Linux, Android, Chrome OS or Other OSes to build developer
> > > > tools or
> > > > other management applications for USB-Type C and USB Power Delivery
> > > > class devices.
> > >
> > > Great, can we add this to the usbutils package, and `lsusb`?
> > Thanks. Yes, the goal is to have it in usbutils package.  The thought
> > to have  lstypec outside lsusb is as follows :
> >
> > "lsusb" displays USB device details based on the USB device's "descriptors'' .
> > lstypec is for displaying usb-c "port capability" and the usb-c
> > partner "port/plug capabilities' ' and
> > the information is agnostic to USB descriptor topology or USB bus.
> > Ex: usb-c power adapters or usb-c display dongle or a usb-c e-cable etc..
> >
> > Open to hear your recommendations.
>
> It's fine to keep it as a separate program to type, or you can make it
> an option for 'lsusb' to output "lsusb --ports" or something?
>
> As your code is pretty tiny, and only reads from sysfs, it shouldn't be
> hard to integrate.  But you do need to fix the license issue :)
>

Yes, I will add the license files separately and come back.

> > > > Features
> > > > ======
> > > > - libtypec - get method for port and port-partner capabilities
> > > > -  utils/lstypec -  displaying information about USB typec class
> > > > devices in the system and the devices connected to them
> > > >
> > > > Release:
> > > > =======
> > > >
> > > > Binary : https://github.com/Rajaram-Regupathy/libtypec/releases/download/libtypec_v0.1/libtypec_0.1.tar.xz
> > > > Source : https://github.com/Rajaram-Regupathy/libtypec/archive/refs/tags/libtypec_v0.1.tar.gz
> > >
> > > Like was pointed out, there is no license listed for this code, so no
> > > one can use it.
> > >
> > > Also, it doesn't build for me:
> >
> > Could you please follow  the Readme steps..?
> >
> > >         $ make
> > >          50%] Building C object CMakeFiles/lstypec.dir/lstypec.c.o
> > >         100%] Linking C executable lstypec
> > >         usr/bin/ld: /home/gregkh/tmp/libtypec/bin/liblibtypec.a(libtypec.c.o):(.bss+0x0): multiple definition of `__packed'; CMakeFiles/lstypec.dir/lstypec.c.o:(.bss+0x0): first defined here
> > >         usr/bin/ld: /home/gregkh/tmp/libtypec/bin/liblibtypec.a(libtypec_sysfs_ops.c.o):(.bss+0x0): multiple definition of `__packed'; CMakeFiles/lstypec.dir/lstypec.c.o:(.bss+0x0): first defined here
> > >         ollect2: error: ld returned 1 exit status
> > >         ake[2]: *** [CMakeFiles/lstypec.dir/build.make:98: lstypec] Error 1
> > >         ake[1]: *** [CMakeFiles/Makefile2:839: CMakeFiles/lstypec.dir/all] Error 2
> > >         ake: *** [Makefile:121: all] Error 2
>
> I did follow the readme steps, what did I miss?
>
> If I delete the one instance of "__packed" from the project, it does
> build for me.  Perhaps you need to make sure that is defined in your
> compiler flags?
>
I cloned and checked. Will double check and comeback

> > > Why does this need to be a library at all?
>
> Again, why does this have to be a library?
>
The aim of having a library is to abstract application(s) from OS,
platform, PD Controller or Embedded Controller protocols ambiguities
and provide common methods. The methods will be similar/closer to UCSI
standard.

> thanks,
>
> greg k-h

Re: [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released

[Greg KH]

On Tue, Jan 18, 2022 at 10:01:02PM +0530, Rajaram Regupathy wrote:
> On Mon, Jan 17, 2022 at 9:08 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Mon, Jan 17, 2022 at 08:07:58PM +0530, Rajaram Regupathy wrote:
> > > On Mon, Jan 17, 2022 at 12:48 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Sun, Jan 16, 2022 at 08:49:47PM +0530, Rajaram Regupathy wrote:
> > > > > HI
> > > > >
> > > > > libtypec
> > > > > ++++++
> > > > >
> > > > > USB-Type C and USB Power Delivery systems are with multiple
> > > > > specification versions, platform designs and microcontroller vendors
> > > > > for managing  data, power and display.
> > > > >
> > > > > libtypec is aimed to provide a generic way for userspace System
> > > > > Software on Linux, Android, Chrome OS or Other OSes to build developer
> > > > > tools or
> > > > > other management applications for USB-Type C and USB Power Delivery
> > > > > class devices.
> > > >
> > > > Great, can we add this to the usbutils package, and `lsusb`?
> > > Thanks. Yes, the goal is to have it in usbutils package.  The thought
> > > to have  lstypec outside lsusb is as follows :
> > >
> > > "lsusb" displays USB device details based on the USB device's "descriptors'' .
> > > lstypec is for displaying usb-c "port capability" and the usb-c
> > > partner "port/plug capabilities' ' and
> > > the information is agnostic to USB descriptor topology or USB bus.
> > > Ex: usb-c power adapters or usb-c display dongle or a usb-c e-cable etc..
> > >
> > > Open to hear your recommendations.
> >
> > It's fine to keep it as a separate program to type, or you can make it
> > an option for 'lsusb' to output "lsusb --ports" or something?
> >
> > As your code is pretty tiny, and only reads from sysfs, it shouldn't be
> > hard to integrate.  But you do need to fix the license issue :)
> >
> 
> Yes, I will add the license files separately and come back.
> 
> > > > > Features
> > > > > ======
> > > > > - libtypec - get method for port and port-partner capabilities
> > > > > -  utils/lstypec -  displaying information about USB typec class
> > > > > devices in the system and the devices connected to them
> > > > >
> > > > > Release:
> > > > > =======
> > > > >
> > > > > Binary : https://github.com/Rajaram-Regupathy/libtypec/releases/download/libtypec_v0.1/libtypec_0.1.tar.xz
> > > > > Source : https://github.com/Rajaram-Regupathy/libtypec/archive/refs/tags/libtypec_v0.1.tar.gz
> > > >
> > > > Like was pointed out, there is no license listed for this code, so no
> > > > one can use it.
> > > >
> > > > Also, it doesn't build for me:
> > >
> > > Could you please follow  the Readme steps..?
> > >
> > > >         $ make
> > > >          50%] Building C object CMakeFiles/lstypec.dir/lstypec.c.o
> > > >         100%] Linking C executable lstypec
> > > >         usr/bin/ld: /home/gregkh/tmp/libtypec/bin/liblibtypec.a(libtypec.c.o):(.bss+0x0): multiple definition of `__packed'; CMakeFiles/lstypec.dir/lstypec.c.o:(.bss+0x0): first defined here
> > > >         usr/bin/ld: /home/gregkh/tmp/libtypec/bin/liblibtypec.a(libtypec_sysfs_ops.c.o):(.bss+0x0): multiple definition of `__packed'; CMakeFiles/lstypec.dir/lstypec.c.o:(.bss+0x0): first defined here
> > > >         ollect2: error: ld returned 1 exit status
> > > >         ake[2]: *** [CMakeFiles/lstypec.dir/build.make:98: lstypec] Error 1
> > > >         ake[1]: *** [CMakeFiles/Makefile2:839: CMakeFiles/lstypec.dir/all] Error 2
> > > >         ake: *** [Makefile:121: all] Error 2
> >
> > I did follow the readme steps, what did I miss?
> >
> > If I delete the one instance of "__packed" from the project, it does
> > build for me.  Perhaps you need to make sure that is defined in your
> > compiler flags?
> >
> I cloned and checked. Will double check and comeback
> 
> > > > Why does this need to be a library at all?
> >
> > Again, why does this have to be a library?
> >
> The aim of having a library is to abstract application(s) from OS,
> platform, PD Controller or Embedded Controller protocols ambiguities
> and provide common methods. The methods will be similar/closer to UCSI
> standard.

What methods are needed by an operating system that your library is
going to provide?  How will it be done in a unified way that the current
user/kernel api isn't providing already today?

thanks,

greg k-h

Re: [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released

[Benson Leung]

[-- Attachment #1: Type: text/plain, Size: 2558 bytes --]

Hi Greg,

On Tue, Jan 18, 2022 at 07:33:39PM +0100, Greg KH wrote:
> On Tue, Jan 18, 2022 at 10:01:02PM +0530, Rajaram Regupathy wrote:
> > > Again, why does this have to be a library?
> > >
> > The aim of having a library is to abstract application(s) from OS,
> > platform, PD Controller or Embedded Controller protocols ambiguities
> > and provide common methods. The methods will be similar/closer to UCSI
> > standard.
> 
> What methods are needed by an operating system that your library is
> going to provide?  How will it be done in a unified way that the current
> user/kernel api isn't providing already today?
> 

A unified libtypec would be useful because the USB Type-C and USB PD
specifications are evolving, and continue to change. Spec changes affect the
decoding of the objects that are exposed by the connector class (the existing
API), and we are at a point where if we left it as-is, you'd have multiple
userspace implementations that would have to independently be updated and
fixed every time there's a new USB PD spec revision or version update.

Just as a concrete example, Jameson (jthies@google.com), who works on my team,
recently put together a little helper utility to decode the typec connector
class in order to print it to our feedback report collector. This was all
done before libtypec:

https://chromium.googlesource.com/chromiumos/platform2/+/749621a6288cc5e80b31a9e6050437a419209fb9/debugd/src/helpers/typec_connector_class_helper.cc

A problem we ran into almost immediately was that the utility was based on
the most recent USB PD specification documents (USB PD R2.0 and USB PD R3.1),
and had definitions on how to decode PD 2.0 and PD 3.1 objects that it would
read from the typec connector class, however, it was missing definitions for
USB PD R3.0 (a spec revision which is not obvious how to find in USB-IF's
document archive).

So, we added it: https://chromium.googlesource.com/chromiumos/platform2/+/eb1efefc187feab1182a7680f42fcec6bb14c618

Now, every other hypothetical type-c connector class user application or daemon
could potentially make this mistake, and would have to duplicate the work
to fix it.

If we had libtypec, it would be the unified place to make such a change, and
we'd reduce the burden of new typec apps from having to do all this decode
in the future.

Thanks,
Benson



> thanks,
> 
> greg k-h

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
bleung@google.com
Chromium OS Project
bleung@chromium.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released

[Greg KH]

On Tue, Jan 18, 2022 at 11:16:28AM -0800, Benson Leung wrote:
> Hi Greg,
> 
> On Tue, Jan 18, 2022 at 07:33:39PM +0100, Greg KH wrote:
> > On Tue, Jan 18, 2022 at 10:01:02PM +0530, Rajaram Regupathy wrote:
> > > > Again, why does this have to be a library?
> > > >
> > > The aim of having a library is to abstract application(s) from OS,
> > > platform, PD Controller or Embedded Controller protocols ambiguities
> > > and provide common methods. The methods will be similar/closer to UCSI
> > > standard.
> > 
> > What methods are needed by an operating system that your library is
> > going to provide?  How will it be done in a unified way that the current
> > user/kernel api isn't providing already today?
> > 
> 
> A unified libtypec would be useful because the USB Type-C and USB PD
> specifications are evolving, and continue to change. Spec changes affect the
> decoding of the objects that are exposed by the connector class (the existing
> API), and we are at a point where if we left it as-is, you'd have multiple
> userspace implementations that would have to independently be updated and
> fixed every time there's a new USB PD spec revision or version update.
> 
> Just as a concrete example, Jameson (jthies@google.com), who works on my team,
> recently put together a little helper utility to decode the typec connector
> class in order to print it to our feedback report collector. This was all
> done before libtypec:
> 
> https://chromium.googlesource.com/chromiumos/platform2/+/749621a6288cc5e80b31a9e6050437a419209fb9/debugd/src/helpers/typec_connector_class_helper.cc
> 
> A problem we ran into almost immediately was that the utility was based on
> the most recent USB PD specification documents (USB PD R2.0 and USB PD R3.1),
> and had definitions on how to decode PD 2.0 and PD 3.1 objects that it would
> read from the typec connector class, however, it was missing definitions for
> USB PD R3.0 (a spec revision which is not obvious how to find in USB-IF's
> document archive).
> 
> So, we added it: https://chromium.googlesource.com/chromiumos/platform2/+/eb1efefc187feab1182a7680f42fcec6bb14c618
> 
> Now, every other hypothetical type-c connector class user application or daemon
> could potentially make this mistake, and would have to duplicate the work
> to fix it.
> 
> If we had libtypec, it would be the unified place to make such a change, and
> we'd reduce the burden of new typec apps from having to do all this decode
> in the future.

Ok, that's fine, but please work to create a library that can handle
such changes in non-breaking ways.  The first version of this library
does not look like it would do that at all as it is exporting way too
many things in a "public" interface.

thanks,

greg k-h

Re: [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released

[Rajaram Regupathy]

On Wed, Jan 19, 2022 at 1:58 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, Jan 18, 2022 at 11:16:28AM -0800, Benson Leung wrote:
> > Hi Greg,
> >
> > On Tue, Jan 18, 2022 at 07:33:39PM +0100, Greg KH wrote:
> > > On Tue, Jan 18, 2022 at 10:01:02PM +0530, Rajaram Regupathy wrote:
> > > > > Again, why does this have to be a library?
> > > > >
> > > > The aim of having a library is to abstract application(s) from OS,
> > > > platform, PD Controller or Embedded Controller protocols ambiguities
> > > > and provide common methods. The methods will be similar/closer to UCSI
> > > > standard.
> > >
> > > What methods are needed by an operating system that your library is
> > > going to provide?  How will it be done in a unified way that the current
> > > user/kernel api isn't providing already today?
> > >
> >
> > A unified libtypec would be useful because the USB Type-C and USB PD
> > specifications are evolving, and continue to change. Spec changes affect the
> > decoding of the objects that are exposed by the connector class (the existing
> > API), and we are at a point where if we left it as-is, you'd have multiple
> > userspace implementations that would have to independently be updated and
> > fixed every time there's a new USB PD spec revision or version update.
> >
> > Just as a concrete example, Jameson (jthies@google.com), who works on my team,
> > recently put together a little helper utility to decode the typec connector
> > class in order to print it to our feedback report collector. This was all
> > done before libtypec:
> >
> > https://chromium.googlesource.com/chromiumos/platform2/+/749621a6288cc5e80b31a9e6050437a419209fb9/debugd/src/helpers/typec_connector_class_helper.cc
> >
> > A problem we ran into almost immediately was that the utility was based on
> > the most recent USB PD specification documents (USB PD R2.0 and USB PD R3.1),
> > and had definitions on how to decode PD 2.0 and PD 3.1 objects that it would
> > read from the typec connector class, however, it was missing definitions for
> > USB PD R3.0 (a spec revision which is not obvious how to find in USB-IF's
> > document archive).
> >
> > So, we added it: https://chromium.googlesource.com/chromiumos/platform2/+/eb1efefc187feab1182a7680f42fcec6bb14c618
> >
> > Now, every other hypothetical type-c connector class user application or daemon
> > could potentially make this mistake, and would have to duplicate the work
> > to fix it.
> >
> > If we had libtypec, it would be the unified place to make such a change, and
> > we'd reduce the burden of new typec apps from having to do all this decode
> > in the future.
>
> Ok, that's fine, but please work to create a library that can handle
> such changes in non-breaking ways.  The first version of this library
> does not look like it would do that at all as it is exporting way too
> many things in a "public" interface.

- Fixed compile error caused due to new version of compiler
- Fixed license details.

The library provides interfaces very similar/same as the UCSI standard
from USB.org.
Additionally the library uses what is available in the existing
framework and  acts as a wrapper between
lower layers and the applications and not a self reliant entity.
Could you please help better understand your concern ?

>n
> thanks,
>
> greg k-h

Re: [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released

[Greg KH]

On Thu, Jan 20, 2022 at 03:29:38PM +0530, Rajaram Regupathy wrote:
> On Wed, Jan 19, 2022 at 1:58 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, Jan 18, 2022 at 11:16:28AM -0800, Benson Leung wrote:
> > > Hi Greg,
> > >
> > > On Tue, Jan 18, 2022 at 07:33:39PM +0100, Greg KH wrote:
> > > > On Tue, Jan 18, 2022 at 10:01:02PM +0530, Rajaram Regupathy wrote:
> > > > > > Again, why does this have to be a library?
> > > > > >
> > > > > The aim of having a library is to abstract application(s) from OS,
> > > > > platform, PD Controller or Embedded Controller protocols ambiguities
> > > > > and provide common methods. The methods will be similar/closer to UCSI
> > > > > standard.
> > > >
> > > > What methods are needed by an operating system that your library is
> > > > going to provide?  How will it be done in a unified way that the current
> > > > user/kernel api isn't providing already today?
> > > >
> > >
> > > A unified libtypec would be useful because the USB Type-C and USB PD
> > > specifications are evolving, and continue to change. Spec changes affect the
> > > decoding of the objects that are exposed by the connector class (the existing
> > > API), and we are at a point where if we left it as-is, you'd have multiple
> > > userspace implementations that would have to independently be updated and
> > > fixed every time there's a new USB PD spec revision or version update.
> > >
> > > Just as a concrete example, Jameson (jthies@google.com), who works on my team,
> > > recently put together a little helper utility to decode the typec connector
> > > class in order to print it to our feedback report collector. This was all
> > > done before libtypec:
> > >
> > > https://chromium.googlesource.com/chromiumos/platform2/+/749621a6288cc5e80b31a9e6050437a419209fb9/debugd/src/helpers/typec_connector_class_helper.cc
> > >
> > > A problem we ran into almost immediately was that the utility was based on
> > > the most recent USB PD specification documents (USB PD R2.0 and USB PD R3.1),
> > > and had definitions on how to decode PD 2.0 and PD 3.1 objects that it would
> > > read from the typec connector class, however, it was missing definitions for
> > > USB PD R3.0 (a spec revision which is not obvious how to find in USB-IF's
> > > document archive).
> > >
> > > So, we added it: https://chromium.googlesource.com/chromiumos/platform2/+/eb1efefc187feab1182a7680f42fcec6bb14c618
> > >
> > > Now, every other hypothetical type-c connector class user application or daemon
> > > could potentially make this mistake, and would have to duplicate the work
> > > to fix it.
> > >
> > > If we had libtypec, it would be the unified place to make such a change, and
> > > we'd reduce the burden of new typec apps from having to do all this decode
> > > in the future.
> >
> > Ok, that's fine, but please work to create a library that can handle
> > such changes in non-breaking ways.  The first version of this library
> > does not look like it would do that at all as it is exporting way too
> > many things in a "public" interface.
> 
> - Fixed compile error caused due to new version of compiler
> - Fixed license details.

The license details are still quite vague.  Please try to put proper
SPDX license identifiers on the individual files so that they are not
vague at all.  What you have here will prevent people from being able to
use this code until it is cleaned up, sorry.

> The library provides interfaces very similar/same as the UCSI standard
> from USB.org.

What do you mean by this?  Exposing raw device structures?  Or something
else?

> Additionally the library uses what is available in the existing
> framework and  acts as a wrapper between
> lower layers and the applications and not a self reliant entity.
> Could you please help better understand your concern ?

How can this be used?

How about adding support for this with lsusb as an example to show how
it might be incorporated.  Or better yet, what about adding this to
libusb so that all platforms will work.  That is, if this is even
relevant for userspace USB access, which I still can't figure out if it
is or not...

Anyway, the license stuff should be fixed up first.  If you have an
employer, please work with them to get this right as they all have legal
training for this type of thing.  If you do not have an employer, I
recommend taking the free LF online course that helps to describe
licenses and copyrights and how to use them.

thanks,

greg k-h

Re: [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released

[Rajaram Regupathy]

On Thu, Jan 20, 2022 at 5:20 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Thu, Jan 20, 2022 at 03:29:38PM +0530, Rajaram Regupathy wrote:
> > On Wed, Jan 19, 2022 at 1:58 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Tue, Jan 18, 2022 at 11:16:28AM -0800, Benson Leung wrote:
> > > > Hi Greg,
> > > >
> > > > On Tue, Jan 18, 2022 at 07:33:39PM +0100, Greg KH wrote:
> > > > > On Tue, Jan 18, 2022 at 10:01:02PM +0530, Rajaram Regupathy wrote:
> > > > > > > Again, why does this have to be a library?
> > > > > > >
> > > > > > The aim of having a library is to abstract application(s) from OS,
> > > > > > platform, PD Controller or Embedded Controller protocols ambiguities
> > > > > > and provide common methods. The methods will be similar/closer to UCSI
> > > > > > standard.
> > > > >
> > > > > What methods are needed by an operating system that your library is
> > > > > going to provide?  How will it be done in a unified way that the current
> > > > > user/kernel api isn't providing already today?
> > > > >
> > > >
> > > > A unified libtypec would be useful because the USB Type-C and USB PD
> > > > specifications are evolving, and continue to change. Spec changes affect the
> > > > decoding of the objects that are exposed by the connector class (the existing
> > > > API), and we are at a point where if we left it as-is, you'd have multiple
> > > > userspace implementations that would have to independently be updated and
> > > > fixed every time there's a new USB PD spec revision or version update.
> > > >
> > > > Just as a concrete example, Jameson (jthies@google.com), who works on my team,
> > > > recently put together a little helper utility to decode the typec connector
> > > > class in order to print it to our feedback report collector. This was all
> > > > done before libtypec:
> > > >
> > > > https://chromium.googlesource.com/chromiumos/platform2/+/749621a6288cc5e80b31a9e6050437a419209fb9/debugd/src/helpers/typec_connector_class_helper.cc
> > > >
> > > > A problem we ran into almost immediately was that the utility was based on
> > > > the most recent USB PD specification documents (USB PD R2.0 and USB PD R3.1),
> > > > and had definitions on how to decode PD 2.0 and PD 3.1 objects that it would
> > > > read from the typec connector class, however, it was missing definitions for
> > > > USB PD R3.0 (a spec revision which is not obvious how to find in USB-IF's
> > > > document archive).
> > > >
> > > > So, we added it: https://chromium.googlesource.com/chromiumos/platform2/+/eb1efefc187feab1182a7680f42fcec6bb14c618
> > > >
> > > > Now, every other hypothetical type-c connector class user application or daemon
> > > > could potentially make this mistake, and would have to duplicate the work
> > > > to fix it.
> > > >
> > > > If we had libtypec, it would be the unified place to make such a change, and
> > > > we'd reduce the burden of new typec apps from having to do all this decode
> > > > in the future.
> > >
> > > Ok, that's fine, but please work to create a library that can handle
> > > such changes in non-breaking ways.  The first version of this library
> > > does not look like it would do that at all as it is exporting way too
> > > many things in a "public" interface.
> >
> > - Fixed compile error caused due to new version of compiler
> > - Fixed license details.
>
> The license details are still quite vague.  Please try to put proper
> SPDX license identifiers on the individual files so that they are not
> vague at all.  What you have here will prevent people from being able to
> use this code until it is cleaned up, sorry.

I have updated license details. It is aligned and made compatible with
similar usb frameworks.

>
> > The library provides interfaces very similar/same as the UCSI standard
> > from USB.org.
>
> What do you mean by this?  Exposing raw device structures?  Or something
> else?

No raw device. library reconstructs "data" from interfaces provided by
the platforms and makes it available in a standard(UCSI) way to
applications.

I definitely agree and will keep in mind  your guidance of not
exporting way too many things in a "public" interface.

>
> > Additionally the library uses what is available in the existing
> > framework and  acts as a wrapper between
> > lower layers and the applications and not a self reliant entity.
> > Could you please help better understand your concern ?
>
> How can this be used?

Few possible usages :

1) Informational utilities like lstype
2) Analyzing Utilities - With usb-c products in different versions,
vendors and e-cables usb-c port may not work as intended. this utility
shall check
usb-c port's operation and report/notify.
3) Test Utilities - Test tools similar to UCSIControl.exe
4) Policy Managers: like
https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/typecd/README.md
etc..
>
> How about adding support for this with lsusb as an example to show how
> it might be incorporated.  Or better yet, what about adding this to
> libusb so that all platforms will work.  That is, if this is even
> relevant for userspace USB access, which I still can't figure out if it
> is or not...

IMHO, I believe usb-c is not usb and hence integrating usb-c
operations with usb utilities or libraries is not a modular approach.
(usbcore vs typec).

Having said that  if it would be good to integrate lstypec with lsusb
as you recommended, would be happy to push patches to lsusb

>
> Anyway, the license stuff should be fixed up first.  If you have an
> employer, please work with them to get this right as they all have legal
> training for this type of thing.  If you do not have an employer, I
> recommend taking the free LF online course that helps to describe
> licenses and copyrights and how to use them.
>
> thanks,
>
> greg k-h

Re: [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released

[Greg KH]

On Wed, Jan 26, 2022 at 09:39:17PM +0530, Rajaram Regupathy wrote:
> On Thu, Jan 20, 2022 at 5:20 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Thu, Jan 20, 2022 at 03:29:38PM +0530, Rajaram Regupathy wrote:
> > > On Wed, Jan 19, 2022 at 1:58 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Tue, Jan 18, 2022 at 11:16:28AM -0800, Benson Leung wrote:
> > > > > Hi Greg,
> > > > >
> > > > > On Tue, Jan 18, 2022 at 07:33:39PM +0100, Greg KH wrote:
> > > > > > On Tue, Jan 18, 2022 at 10:01:02PM +0530, Rajaram Regupathy wrote:
> > > > > > > > Again, why does this have to be a library?
> > > > > > > >
> > > > > > > The aim of having a library is to abstract application(s) from OS,
> > > > > > > platform, PD Controller or Embedded Controller protocols ambiguities
> > > > > > > and provide common methods. The methods will be similar/closer to UCSI
> > > > > > > standard.
> > > > > >
> > > > > > What methods are needed by an operating system that your library is
> > > > > > going to provide?  How will it be done in a unified way that the current
> > > > > > user/kernel api isn't providing already today?
> > > > > >
> > > > >
> > > > > A unified libtypec would be useful because the USB Type-C and USB PD
> > > > > specifications are evolving, and continue to change. Spec changes affect the
> > > > > decoding of the objects that are exposed by the connector class (the existing
> > > > > API), and we are at a point where if we left it as-is, you'd have multiple
> > > > > userspace implementations that would have to independently be updated and
> > > > > fixed every time there's a new USB PD spec revision or version update.
> > > > >
> > > > > Just as a concrete example, Jameson (jthies@google.com), who works on my team,
> > > > > recently put together a little helper utility to decode the typec connector
> > > > > class in order to print it to our feedback report collector. This was all
> > > > > done before libtypec:
> > > > >
> > > > > https://chromium.googlesource.com/chromiumos/platform2/+/749621a6288cc5e80b31a9e6050437a419209fb9/debugd/src/helpers/typec_connector_class_helper.cc
> > > > >
> > > > > A problem we ran into almost immediately was that the utility was based on
> > > > > the most recent USB PD specification documents (USB PD R2.0 and USB PD R3.1),
> > > > > and had definitions on how to decode PD 2.0 and PD 3.1 objects that it would
> > > > > read from the typec connector class, however, it was missing definitions for
> > > > > USB PD R3.0 (a spec revision which is not obvious how to find in USB-IF's
> > > > > document archive).
> > > > >
> > > > > So, we added it: https://chromium.googlesource.com/chromiumos/platform2/+/eb1efefc187feab1182a7680f42fcec6bb14c618
> > > > >
> > > > > Now, every other hypothetical type-c connector class user application or daemon
> > > > > could potentially make this mistake, and would have to duplicate the work
> > > > > to fix it.
> > > > >
> > > > > If we had libtypec, it would be the unified place to make such a change, and
> > > > > we'd reduce the burden of new typec apps from having to do all this decode
> > > > > in the future.
> > > >
> > > > Ok, that's fine, but please work to create a library that can handle
> > > > such changes in non-breaking ways.  The first version of this library
> > > > does not look like it would do that at all as it is exporting way too
> > > > many things in a "public" interface.
> > >
> > > - Fixed compile error caused due to new version of compiler
> > > - Fixed license details.
> >
> > The license details are still quite vague.  Please try to put proper
> > SPDX license identifiers on the individual files so that they are not
> > vague at all.  What you have here will prevent people from being able to
> > use this code until it is cleaned up, sorry.
> 
> I have updated license details. It is aligned and made compatible with
> similar usb frameworks.

Nice, so the library is GPLv2?

You might want to download the 'reuse' tool and run 'reuse lint' on your
repo.  The license file name is a bit odd and doesn't parse well, but I
understand what you mean here :)

Also note, that GPLv2 is NOT a good license for a library, but hey, it's
your code, not mine.

> > > Additionally the library uses what is available in the existing
> > > framework and  acts as a wrapper between
> > > lower layers and the applications and not a self reliant entity.
> > > Could you please help better understand your concern ?
> >
> > How can this be used?
> 
> Few possible usages :
> 
> 1) Informational utilities like lstype
> 2) Analyzing Utilities - With usb-c products in different versions,
> vendors and e-cables usb-c port may not work as intended. this utility
> shall check
> usb-c port's operation and report/notify.
> 3) Test Utilities - Test tools similar to UCSIControl.exe
> 4) Policy Managers: like
> https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/typecd/README.md
> etc..
> >
> > How about adding support for this with lsusb as an example to show how
> > it might be incorporated.  Or better yet, what about adding this to
> > libusb so that all platforms will work.  That is, if this is even
> > relevant for userspace USB access, which I still can't figure out if it
> > is or not...
> 
> IMHO, I believe usb-c is not usb and hence integrating usb-c
> operations with usb utilities or libraries is not a modular approach.
> (usbcore vs typec).

Parts of USB-C is USB :)

> Having said that  if it would be good to integrate lstypec with lsusb
> as you recommended, would be happy to push patches to lsusb

Maybe parts of the output of lstypec would be good to have in lsusb, I
don't know.  Take a look at see what you think.

thanks,

greg k-h