* [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released @ 2022-01-16 15:19 Rajaram Regupathy 2022-01-16 15:37 ` Stephan Brunner 2022-01-17 7:18 ` Greg KH 0 siblings, 2 replies; 13+ messages in thread From: Rajaram Regupathy @ 2022-01-16 15:19 UTC (permalink / raw) To: linux-usb Cc: heikki.krogerus, Benson Leung, Prashant Malani, jthies, saranya.gopal 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released 2022-01-16 15:19 [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released Rajaram Regupathy @ 2022-01-16 15:37 ` Stephan Brunner 2022-01-17 7:18 ` Greg KH 1 sibling, 0 replies; 13+ messages in thread From: Stephan Brunner @ 2022-01-16 15:37 UTC (permalink / raw) To: Rajaram Regupathy, linux-usb 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released 2022-01-16 15:19 [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released Rajaram Regupathy 2022-01-16 15:37 ` Stephan Brunner @ 2022-01-17 7:18 ` Greg KH 2022-01-17 14:37 ` Rajaram Regupathy 1 sibling, 1 reply; 13+ messages in thread From: Greg KH @ 2022-01-17 7:18 UTC (permalink / raw) To: Rajaram Regupathy Cc: linux-usb, heikki.krogerus, Benson Leung, Prashant Malani, jthies, saranya.gopal 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released 2022-01-17 7:18 ` Greg KH @ 2022-01-17 14:37 ` Rajaram Regupathy 2022-01-17 15:38 ` Greg KH 0 siblings, 1 reply; 13+ messages in thread From: Rajaram Regupathy @ 2022-01-17 14:37 UTC (permalink / raw) To: Greg KH Cc: linux-usb, heikki.krogerus, Benson Leung, Prashant Malani, jthies, saranya.gopal 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released 2022-01-17 14:37 ` Rajaram Regupathy @ 2022-01-17 15:38 ` Greg KH 2022-01-18 16:31 ` Rajaram Regupathy 0 siblings, 1 reply; 13+ messages in thread From: Greg KH @ 2022-01-17 15:38 UTC (permalink / raw) To: Rajaram Regupathy Cc: linux-usb, heikki.krogerus, Benson Leung, Prashant Malani, jthies, saranya.gopal 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released 2022-01-17 15:38 ` Greg KH @ 2022-01-18 16:31 ` Rajaram Regupathy 2022-01-18 18:33 ` Greg KH 0 siblings, 1 reply; 13+ messages in thread From: Rajaram Regupathy @ 2022-01-18 16:31 UTC (permalink / raw) To: Greg KH Cc: linux-usb, heikki.krogerus, Benson Leung, Prashant Malani, jthies, saranya.gopal 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released 2022-01-18 16:31 ` Rajaram Regupathy @ 2022-01-18 18:33 ` Greg KH 2022-01-18 19:16 ` Benson Leung 0 siblings, 1 reply; 13+ messages in thread From: Greg KH @ 2022-01-18 18:33 UTC (permalink / raw) To: Rajaram Regupathy Cc: linux-usb, heikki.krogerus, Benson Leung, Prashant Malani, jthies, saranya.gopal 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released 2022-01-18 18:33 ` Greg KH @ 2022-01-18 19:16 ` Benson Leung 2022-01-19 8:28 ` Greg KH 0 siblings, 1 reply; 13+ messages in thread From: Benson Leung @ 2022-01-18 19:16 UTC (permalink / raw) To: Greg KH Cc: Rajaram Regupathy, linux-usb, heikki.krogerus, Prashant Malani, jthies, saranya.gopal [-- 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 --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released 2022-01-18 19:16 ` Benson Leung @ 2022-01-19 8:28 ` Greg KH 2022-01-20 9:59 ` Rajaram Regupathy 0 siblings, 1 reply; 13+ messages in thread From: Greg KH @ 2022-01-19 8:28 UTC (permalink / raw) To: Benson Leung Cc: Rajaram Regupathy, linux-usb, heikki.krogerus, Prashant Malani, jthies, saranya.gopal 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released 2022-01-19 8:28 ` Greg KH @ 2022-01-20 9:59 ` Rajaram Regupathy 2022-01-20 11:50 ` Greg KH 0 siblings, 1 reply; 13+ messages in thread From: Rajaram Regupathy @ 2022-01-20 9:59 UTC (permalink / raw) To: Greg KH Cc: Benson Leung, linux-usb, heikki.krogerus, Prashant Malani, jthies, saranya.gopal 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released 2022-01-20 9:59 ` Rajaram Regupathy @ 2022-01-20 11:50 ` Greg KH 2022-01-26 16:09 ` Rajaram Regupathy 0 siblings, 1 reply; 13+ messages in thread From: Greg KH @ 2022-01-20 11:50 UTC (permalink / raw) To: Rajaram Regupathy Cc: Benson Leung, linux-usb, heikki.krogerus, Prashant Malani, jthies, saranya.gopal 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released 2022-01-20 11:50 ` Greg KH @ 2022-01-26 16:09 ` Rajaram Regupathy 2022-01-26 16:39 ` Greg KH 0 siblings, 1 reply; 13+ messages in thread From: Rajaram Regupathy @ 2022-01-26 16:09 UTC (permalink / raw) To: Greg KH Cc: Benson Leung, linux-usb, heikki.krogerus, Prashant Malani, jthies, saranya.gopal 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released 2022-01-26 16:09 ` Rajaram Regupathy @ 2022-01-26 16:39 ` Greg KH 0 siblings, 0 replies; 13+ messages in thread From: Greg KH @ 2022-01-26 16:39 UTC (permalink / raw) To: Rajaram Regupathy Cc: Benson Leung, linux-usb, heikki.krogerus, Prashant Malani, jthies, saranya.gopal 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2022-01-26 16:40 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-01-16 15:19 [ANNOUNCE] libtypec_0.1/lstypec_0.1 is released Rajaram Regupathy 2022-01-16 15:37 ` Stephan Brunner 2022-01-17 7:18 ` Greg KH 2022-01-17 14:37 ` Rajaram Regupathy 2022-01-17 15:38 ` Greg KH 2022-01-18 16:31 ` Rajaram Regupathy 2022-01-18 18:33 ` Greg KH 2022-01-18 19:16 ` Benson Leung 2022-01-19 8:28 ` Greg KH 2022-01-20 9:59 ` Rajaram Regupathy 2022-01-20 11:50 ` Greg KH 2022-01-26 16:09 ` Rajaram Regupathy 2022-01-26 16:39 ` Greg KH
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.