From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752390AbcFTF6X (ORCPT ); Mon, 20 Jun 2016 01:58:23 -0400 Received: from regular1.263xmail.com ([211.150.99.139]:36539 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751084AbcFTF6P (ORCPT ); Mon, 20 Jun 2016 01:58:15 -0400 X-263anti-spam: KSV:0; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-KSVirus-check: 0 X-ABS-CHECKED: 4 X-ADDR-CHECKED: 0 X-RL-SENDER: zyw@rock-chips.com X-FST-TO: linux-arm-kernel@lists.infradead.org X-SENDER-IP: 103.29.142.67 X-LOGIN-NAME: zyw@rock-chips.com X-UNIQUE-TAG: X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Subject: Re: [v2 PATCH 2/4] phy: Add USB Type-C PHY driver for rk3399 To: Guenter Roeck References: <1465810789-22303-1-git-send-email-zyw@rock-chips.com> <1465810789-22303-3-git-send-email-zyw@rock-chips.com> Cc: Douglas Anderson , Tomasz Figa , =?UTF-8?Q?Heiko_St=c3=bcbner?= , yzq@rock-chips.com, Guenter Roeck , linux-rockchip@lists.infradead.org, Kever Yang , Kishon Vijay Abraham I , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org From: Chris Zhong Message-ID: <576785BC.4070904@rock-chips.com> Date: Mon, 20 Jun 2016 13:57:16 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Guenter On 06/18/2016 11:45 PM, Guenter Roeck wrote: > Hi Chris, > > On Mon, Jun 13, 2016 at 2:39 AM, Chris Zhong wrote: >> Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB >> Type-C PHY is designed to support the USB3 and DP applications. The >> PHY basically has two main components: USB3 and DisplyPort. USB3 >> operates in SuperSpeed mode and the DP can operate at RBR, HBR and >> HBR2 data rates. >> > I started integrating the driver with our code. > Doing so, I realized a problem in the way you are using extcon. > > [ ... ] > >> + >> +static int tcphy_pd_event(struct notifier_block *nb, >> + unsigned long event, void *priv) >> +{ >> + struct rockchip_typec_phy *tcphy; >> + struct extcon_dev *edev = priv; >> + int value = edev->state; >> + int mode; >> + u8 is_plugged, dfp; >> + >> + tcphy = container_of(nb, struct rockchip_typec_phy, event_nb); >> + >> + is_plugged = GET_PLUGGED(value); >> + tcphy->flip = GET_FLIP(value); >> + dfp = GET_DFP(value); >> + tcphy->map = GET_PIN_MAP(value); >> + > I don't think it is a good idea to use the extcon 'state' field like > this. I don't even think it is possible. > > The state is supposed to be a bit mask, each bit indicating if a > specific connector (or functionality) on the cable is attached. The > extcon notifier code walks through this bit mask and determines based > on changed bits if the notifier should be called. So the notifier in > this case would only be called if bit 1 (EXTCON_USB) of 'state' has > changed, but not if one of the other bits has changed. One would have > to define 32 "virtual" cables, one for each bit, for this to work, and > then you would have to register a notifier for each of the bits. That > would not really make sense. > > Of course, that makes using the extcon notifier quite useless for our > purpose, since we need the callback not only if a cable has been > attached or deattached, but also if some secondary state changes. I > don't really know myself how to solve the problem; I'll need to think > about it some more. Maybe we can add a callback into the type-c > infrastructure code and somehow tie into that code, but I don't know > yet if that is feasible either. > > Guenter > > Yes, currently, we can get the notification only when bit 0 change. So the phy driver can know plug/unplug event. if we need more trigger, how about set the BIT 0 for changed flag. state = extcon_get_cable_state state = ~state | is_plugged | flip | dfp | map extcon_set_state(state)