linux-kernel - Re: [PATCH] usb: fotg210: fix OTG-only build

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACRpkdZBs0RTwnEjTu81ih0Pyar-e0mb-9-zo9rS6fB9OAHWog@mail.gmail.com>
Date:   Wed, 4 Jan 2023 01:14:03 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Daniel Palmer <daniel@...f.com>
Cc:     Arnd Bergmann <arnd@...nel.org>, Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: fotg210: fix OTG-only build

On Mon, Jan 2, 2023 at 7:10 AM Daniel Palmer <daniel@...f.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