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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux