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