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