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@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxx), 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
