From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756784AbcDGQdp (ORCPT ); Thu, 7 Apr 2016 12:33:45 -0400 Received: from hauke-m.de ([5.39.93.123]:38090 "EHLO hauke-m.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751440AbcDGQdn (ORCPT ); Thu, 7 Apr 2016 12:33:43 -0400 Subject: Re: [PATCH] phy: bcm-ns-usb2: new driver for USB 2.0 PHY on Northstar To: Jon Mason , =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= References: <1459260114-10853-1-git-send-email-zajec5@gmail.com> Cc: Kishon Vijay Abraham I , linux-kernel@vger.kernel.org, Felix Fietkau , Florian Fainelli , linux-usb@vger.kernel.org, ">" From: Hauke Mehrtens Message-ID: <57068BE3.8090102@hauke-m.de> Date: Thu, 7 Apr 2016 18:33:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/05/2016 09:34 PM, Jon Mason wrote: > > > On Wed, Mar 30, 2016 at 5:32 PM, Jon Mason > wrote: > > On Tue, Mar 29, 2016 at 10:01 AM, Rafał Miłecki > wrote: > > Northstar is a family of SoCs used in home routers. They have > USB 2.0 > and 3.0 controllers with PHYs that need to be properly initialized. > This driver provides PHY init support in a generic way and can > be bound > with an EHCI controller driver. > > > Like the USB3 patch you just submitted for NS, this is a common IP > block with NSP. I believe with some minor changes it can support > both. Please allow me 1-2 days to look at these in more detail and > see if I can get these patches working on NSP. > > Thanks, > Jon > > > After some internal discussion, I don't think this is going to work. > This IP block is common for NS, NSP, and a few others. So binding it to > BMCA is going to prevent us from being able to use it on any other > platforms. However, a non-BMCA driver would still be usable by NS. So, > I think that is a superior solution. > > We are currently in the process of getting a Phy driver out which would > cover all the iProc SoCs. I think it is 1-2 weeks away from being > submitted. So, I think to go forward we should use that one for NS. > However, that does not bridge the gap until it is accepted. > > So, I think we have 2 options. > 1. Wait for BCM to submit the iProc phy driver > 2. Push this now, and remove it after the iProc phy driver is accepted. > > Thoughts? > > Thanks, > Jon > Hi Jon, As far as I see this does not have any build time dependency to bcma, it only uses some header from bcma. Does this not build and run on your devices without bcma? Hauke