linux-kernel - Re: [PATCH 3/4] usb: remove OMAP USB Device Controller and OHCI support for OMAP1/2 chips

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: <Y7/YiMPIDN0Cf5Ky@atomide.com>
Date:   Thu, 12 Jan 2023 11:53:12 +0200
From:   Tony Lindgren <tony@...mide.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Lukas Bulwahn <lukas.bulwahn@...il.com>,
        Aaro Koskinen <aaro.koskinen@....fi>,
        Janusz Krzysztofik <jmkrzyszt@...il.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        linux-arm-kernel@...ts.infradead.org,
        Linux-OMAP <linux-omap@...r.kernel.org>,
        linux-usb@...r.kernel.org, linux-samsung-soc@...r.kernel.org,
        kernel-janitors@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/4] usb: remove OMAP USB Device Controller and OHCI
 support for OMAP1/2 chips

* Arnd Bergmann <arnd@...db.de> [230112 09:03]:
> On Thu, Jan 12, 2023, at 09:37, Lukas Bulwahn wrote:
> > Commit 0fee2eac5c2b ("usb: phy: remove phy-isp1301-omap driver") removes
> > the Philips ISP1301 with OMAP OTG driver and its corresponding config
> > ISP1301_OMAP. The drivers, OMAP USB Device Controller and OHCI support for
> > OMAP1/2 chips, with corresponding configs, USB_OMAP and USB_OHCI_HCD_OMAP1,
> > need this removed driver (see "depends on ISP1301_OMAP") to build.
> >
> > Remove those two drivers.
> >
> > With the config USB_OMAP removed in this commit, remove some further code
> > in the omap-dma header and mach-omap1 architecture code.
> >
> > Signed-off-by: Lukas Bulwahn <lukas.bulwahn@...il.com>
> 
> This would be a great cleanup because of the simplications of the
> omap-dma code. I had previously looked at it and concluded that
> the driver is still in use though, and I think my mistake was
> just in the Kconfig part of this patch:

It sure would be nice to drop the old custom dma api in omap-dma.c
while keeping the dma.c in arch/arm/mach-omap1.

Regards,

Tony