From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3BD05C432C3 for ; Fri, 15 Nov 2019 00:23:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 125DE2070E for ; Fri, 15 Nov 2019 00:23:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="GjufNMLb" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727229AbfKOAXP (ORCPT ); Thu, 14 Nov 2019 19:23:15 -0500 Received: from mail-oi1-f193.google.com ([209.85.167.193]:44766 "EHLO mail-oi1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726852AbfKOAXP (ORCPT ); Thu, 14 Nov 2019 19:23:15 -0500 Received: by mail-oi1-f193.google.com with SMTP id s71so7044610oih.11 for ; Thu, 14 Nov 2019 16:23:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RsrGyoqQOYTH2PPKiYL70RKRI4in0yNtJQIpGh3K26A=; b=GjufNMLb+2YWJLijLeqWGOvXAVzz4XsHL1I40V3nObyb3FekAhPvoAXapmoM3+HXQl 4lXuWj5kAUZ8DShtZYDijjP4NLhLGvDJ4jZFRJmu+Lg5XQCKQj1vhFU5DfAoKfnVAxxP mkT/Lo7o3ATgV4w+prTyisBFmjzSxW1Z6Gnx47cfQqYV9BZdEIWIYZsD6Q0b8YBQsUe4 a9j8xUqQXkmBtiLEwHAKNuPsGCarYjqGuqxsN3zKm2uuv9/2p/MK0I1+wKKGz0Hc/vPJ Swi3A+ww7I1gjZiAi87V35E+2V8ah7vDTvMDRrBc70t63sUFVwVUfl+KUh5nVHImZ/ww nvKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RsrGyoqQOYTH2PPKiYL70RKRI4in0yNtJQIpGh3K26A=; b=pzkwPdxSmu6Ee6njTKjATxgUfz7dF8p6oZ1fLhLp0V72SS4XIQdfv7/2oAKdkxVehH +bi+8aehQ9n+1E285KNzID2v22mh6qIJ/4hWVT2pqusHhTi1EekJHEagQ9VH2aJDCCWj 9RQbu3suwTdkhhdJmWtwSBG5y2O4PxJr1sXo7+3ktVnXccLlmGNeJf2mnqy7gBxVocog 307rKLbrMAYA2LnlI4AXCYeUYsktdEguTHM+/WXzVJdiG5MHsDoYpNJ2LnlKGHf1Bb3Q T82LAXOj58cj8JY83aiSj+E5zN4oH0RETw0NtlRDgdpttvoFp9ky6vGph/lYkqy6VErH 9KgA== X-Gm-Message-State: APjAAAUr/YB3QRUEWYAA3UWY9IUJWLsNkzfN5/MDuMv6VE/5sn+t3W21 yGraqFdjbB+JNYJf6w5uuAx4Le4DMAha4D1RCx8xGw== X-Google-Smtp-Source: APXvYqxfcWlpb80bfV9/wf4du5Ri0OHkQNIq7dTOGMorsiq+ISYV3iyGYJ5gy6j6vXuX0krZDW5k5bg9mqAlmEdJMVY= X-Received: by 2002:aca:c3cf:: with SMTP id t198mr5965693oif.10.1573777393028; Thu, 14 Nov 2019 16:23:13 -0800 (PST) MIME-Version: 1.0 References: <20191002231617.3670-1-john.stultz@linaro.org> <648e2943-42f5-e07d-5bb4-f6fd8b38b726@redhat.com> <7877d69b-b17c-d4a4-9806-3dca98fc9e26@redhat.com> <7ea7824f-abc2-4cf6-720a-3668b6286781@redhat.com> <5965292c-4837-5f3b-816e-287174c909ff@redhat.com> <2d98ea33-e128-6b38-8c16-c6339cb27fd1@redhat.com> In-Reply-To: <2d98ea33-e128-6b38-8c16-c6339cb27fd1@redhat.com> From: John Stultz Date: Thu, 14 Nov 2019 16:23:02 -0800 Message-ID: Subject: Re: [RFC][PATCH 2/3] usb: roles: Add usb role switch notifier. To: Hans de Goede Cc: lkml , Yu Chen , Greg Kroah-Hartman , Rob Herring , Mark Rutland , Heikki Krogerus , Suzuki K Poulose , Chunfeng Yun , Felipe Balbi , Andy Shevchenko , Jun Li , Valentin Schneider , Linux USB List , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" Content-Type: text/plain; charset="UTF-8" Sender: linux-usb-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org On Thu, Nov 14, 2019 at 2:11 AM Hans de Goede wrote: > On 22-10-2019 07:58, John Stultz wrote: > > I'm fine to > > continue digging and working on this approach, but I also don't want > > to have to pollute the core code too much for this oddball hardware > > (esp since doing the vbus control in the role-switch intermediary does > > work ok - or at least better then this approach so far). > > Given the special nature of the hardware I'm fine with the OTG intermediary > approach here. IMHO it is fine to just stick with that and to not spend > too much time on this. Ok. That was what I was leaning towards as well. Thanks again for all the review and feedback here! I really appreciate it! -john