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. Thanks, Benson > thanks, > > greg k-h -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. bleung@xxxxxxxxxx Chromium OS Project bleung@xxxxxxxxxxxx
Attachment:
signature.asc
Description: PGP signature
