linux-kernel - Re: [PATCH 0/3] ChromeOS EC USB-C Connector Class

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 14 Nov 2019 17:24:32 +0200
From:   Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:     Jon Flatley <jflat@...omium.org>
Cc:     Benson Leung <bleung@...gle.com>, enric.balletbo@...labora.com,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Benson Leung <bleung@...omium.org>, groeck@...omium.org,
        sre@...nel.org, Prashant Malani <pmalani@...omium.org>
Subject: Re: [PATCH 0/3] ChromeOS EC USB-C Connector Class

Hi Jon,

On Wed, Nov 13, 2019 at 05:09:56PM -0800, Jon Flatley wrote:
> > I'll go over these tomorrow, but I have one question already. Can you
> > guys influence what goes to the ACPI tables?
> >
> > Ideally every Type-C connector is always described in its own ACPI
> > node (or DT node if DT is used). Otherwise getting the correct
> > capabilities and especially connections to other devices (like the
> > muxes) for every port may get difficult.
> 
> Hey Heikki, thank you for your quick response!
> 
> In general we do have control over the ACPI tables and over DT. The
> difference for ChromeOS is that the PD implementation and policy
> decisions are handled by the embedded controller. This includes
> alternate mode transitions and control over the muxes. I don't believe
> there is any information about port capabilities in ACPI or DT, that's
> all handled by the EC. With current EC firmware we are mostly limited
> to querying the EC for port capabilities and state. There may be some
> exceptions to this, such as with Rockchip platforms, but even then the
> EC is largely in control.

The capabilities here mean things like is the port: source, sink or
DRP; host, device or DRD; etc. So static information.

I do understand that the EC is in control of the Port Controller (or
PD controller), the muxes, the policy decisions and what have you, and
that is fine. My point is that the operating system should not have to
get also the hardware description from the EC. That part should always
come from ACPI tables or DT, even when the components are attached to
the EC instead of the host CPU. Otherwise we loose scalability for no
good reason.

Note. The device properties for the port capabilities are already
documented in kernel:
Documentation/devicetree/bindings/connector/usb-connector.txt (the
same properties work in ACPI as well).

> I think you raise a valid point, but such a change is probably out of
> scope for this implementation.

This implementation should already be made so that it works with a
properly prepared ACPI tables or DT. If there are already boards that
don't supply the nodes in ACPI tables for the ports, then software
nodes can be used with those, but all new boards really should have a
real firmware node represeting every Type-C port.

thanks,

-- 
heikki