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@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx> 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
