[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191210224803.GA3372@roeck-us.net>
Date: Tue, 10 Dec 2019 14:48:03 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Aaro Koskinen <aaro.koskinen@....fi>
Cc: devel@...verdev.osuosl.org,
Branden Bonaby <brandonbonaby94@...il.com>,
Florian Westphal <fw@...len.de>,
Paul Burton <paulburton@...nel.org>,
Giovanni Gherdovich <bobdc9664@...nam.cz>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
YueHaibing <yuehaibing@...wei.com>, linux-kernel@...r.kernel.org,
"Matthew Wilcox (Oracle)" <willy@...radead.org>,
Julia Lawall <julia.lawall@...6.fr>,
Sandro Volery <sandro@...ery.com>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Valery Ivanov <ivalery111@...il.com>,
Petr Štetiar <ynezz@...e.cz>,
"David S. Miller" <davem@...emloft.net>,
Dan Carpenter <dan.carpenter@...cle.com>,
Wambui Karuga <wambui.karugax@...il.com>
Subject: Re: [PATCH 1/2] staging: octeon: delete driver
On Tue, Dec 10, 2019 at 11:48:49PM +0200, Aaro Koskinen wrote:
> On Tue, Dec 10, 2019 at 12:15:15PM -0800, Guenter Roeck wrote:
> > On Tue, Dec 10, 2019 at 09:46:59PM +0200, Aaro Koskinen wrote:
> > > On Tue, Dec 10, 2019 at 01:01:20PM +0100, Greg Kroah-Hartman wrote:
> > > > I have no idea :(
> > >
> > > It's stated in the TODO file you are deleting (visible in your
> > > patch): "This driver is functional and supports Ethernet on
> > > OCTEON+/OCTEON2/OCTEON3 chips at least up to CN7030."
> > >
> > > This includes e.g. some D-Link routers and Uniquiti EdgeRouters. You
> > > can check from /proc/cpuinfo if you are running on this MIPS SoC.
> >
> > It also results in "mips:allmodconfig" build failures in mainline
> > and is for that reason being marked as BROKEN. Unfortunately,
> > misguided attempts to clean it up had the opposite effect.
>
> This was because of stubs hack added by someone - people who do not run
> or care about the hardware can now break it for others with their
> silly x86 "compile test"s.
>
Thast was the first breakage. The second was to replace typedefs with
structures without considering that those typedefs are still used
throughout the Cavium code, creating conflicts between "mystruct_t" and
"struct mystruct" in various API calls. It may well be that this
"improvement" was tested with x86_64:allmodconfig - if it was tested
in the first place. It was most definitely not tested with
cavium_octeon_defconfig, much less with real hardware.
Pretty much none of the changes made to the driver in the recent
past have improved it. On the contrary, it is getting worse. With no
one committed to get the driver out of staging, I don't think there
is a reasonable alternative to removing it. For my part I am for sure
not looking forward having to deal with it breaking over and over
again and having to spend time tracking down the breakage.
Guenter
Powered by blists - more mailing lists