linux-kernel - USB Type-C Port Manager API concern

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:   Sun, 9 Apr 2017 01:09:57 +0200
From:   Mats Karrman <mats.dev.list@...il.com>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Felipe Balbi <felipe.balbi@...ux.intel.com>,
        linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: USB Type-C Port Manager API concern

Hi Guenter,

 From a previous thread:

On 03/08/2017 02:38 AM, Guenter Roeck wrote:
> On 03/07/2017 02:30 PM, Mats Karrman wrote:
> [ ... ]
>
>>
>> I'm still struggling to catch up on what you guys have been up to 
>> during the
>> last year or so :-) and came across some patches of Guenter from last 
>> October:
>>
>> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1243527.html
>>
>> What happened to them? Has there been any progress since then?
>>
>
> Updates to keep in sync with API changes, bug fixes, and minor 
> improvements,
> for the most part. I can post a current version if there is interest.
> The latest version is also available from
> https://chromium-review.googlesource.com/#/c/389917/

I'm working on a tcpi driver and have some concern about the tcpm api.
The tcpm_register_port() is typically called from the probe function of
tcpi driver where the tcpm_port reference returned is stored in the
driver private data. The problem I ran into is that tcpm_register_port()
calls back to the not yet fully initialized tcpi driver, causing null-
pointer dereferences. This could of course be solved by extra logic in
the tcpi driver but I think it would be more elegant if the registration
of a port could be free of premature callbacks. E.g. it could be required
that the tcpi driver probe called tcpm_tcpc_reset() once it's done
initializing or the necessary data could be supplied in the call to
tcpm_register_port().
What do you think?

BR,
Mats