Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20221215165728.2062984-1-arnd@kernel.org> <CACRpkda3V2Fv9aOxxcuQ5NKv3sWic9-skQU_z7=0S692h_WhnQ@mail.gmail.com>
 <CAFr9PXmVXqAX73VUzAt_M2yPN93in9Y_LHyYcEA1Dfj_m_4ZHA@mail.gmail.com>
In-Reply-To: <CAFr9PXmVXqAX73VUzAt_M2yPN93in9Y_LHyYcEA1Dfj_m_4ZHA@mail.gmail.com>
From:   Linus Walleij <linus.walleij@linaro.org>
Date:   Wed, 4 Jan 2023 01:14:03 +0100
Message-ID: <CACRpkdZBs0RTwnEjTu81ih0Pyar-e0mb-9-zo9rS6fB9OAHWog@mail.gmail.com>
Subject: Re: [PATCH] usb: fotg210: fix OTG-only build
To:     Daniel Palmer <daniel@0x0f.com>
Cc:     Arnd Bergmann <arnd@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Jan 2, 2023 at 7:10 AM Daniel Palmer <daniel@0x0f.com> wrote:

> Maybe a little unrelated to this patch but this IP is also used on the
> MStar/SigmaStar chips

I actually think Arnd Bergmann at one point sent me a device with
this line of chips in it. I suppose you will be upstreaming this
support?

> (albeit only the host (FUSBH200) part that used
> to have its own driver that got removed at some point...)

Sorry for reading this after sending out my latest changes, here:
https://lore.kernel.org/linux-usb/20230103-gemini-fotg210-usb-v1-0-f2670cb4a492@linaro.org/T/#t

The first patch in this series differentiates between
FOTG200 and FOTG210, do you mean to say there is
rather FUSBH200 as well? There is also FUSB220...
(Faraday used to have datasheets on their webpage
but I can't access them anymore.)

> For what it's worth I could not get this driver to function correctly
> with UVC cameras etc and was fed up with hacking it apart to try to
> get it to work when it's mostly a copy/paste of an old copy of the
> common EHCI driver.
> So I added some extra quirks to the common EHCI driver to allow it to
> run this IP too and deleted the custom driver in my tree (hence the
> conflicts..).
>
> I'm not sure how using the common EHCI driver works with the OTG part
> but if it's possible to make that work maybe my way is a better
> solution than trying to maintain this driver?

That's a good point, do you have a pointer to your EHCI
quirk patch so I can take a look?

Yours,
Linus Walleij