Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752066AbdDHXKA (ORCPT ); Sat, 8 Apr 2017 19:10:00 -0400 Received: from mail-lf0-f68.google.com ([209.85.215.68]:34758 "EHLO mail-lf0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751718AbdDHXJw (ORCPT ); Sat, 8 Apr 2017 19:09:52 -0400 Subject: USB Type-C Port Manager API concern To: Guenter Roeck References: <20170221142405.76299-1-heikki.krogerus@linux.intel.com> <20170221142405.76299-3-heikki.krogerus@linux.intel.com> <4b4bbffc-db02-3b54-04bc-e7de79b2d9ed@roeck-us.net> <07618170-d561-e7fe-08e0-91316c53d832@gmail.com> <20170303125940.GA6999@kuha.fi.intel.com> <6ddb2eac-03d5-127e-df1e-ad189968e6b2@gmail.com> <20170306131442.GC6999@kuha.fi.intel.com> <696552a7-c36a-1d73-9517-543907e9da39@gmail.com> <9b32fabf-3ff5-112f-4249-a7024f808b20@roeck-us.net> Cc: Heikki Krogerus , Greg KH , Felipe Balbi , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org From: Mats Karrman Message-ID: <4fe455d8-30d9-0c21-46aa-6d273cd24d50@gmail.com> Date: Sun, 9 Apr 2017 01:09:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9b32fabf-3ff5-112f-4249-a7024f808b20@roeck-us.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1481 Lines: 40 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