[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1457108303.2651.112.camel@tiscali.nl>
Date: Fri, 04 Mar 2016 17:18:23 +0100
From: Paul Bolle <pebolle@...cali.nl>
To: Arnd Bergmann <arnd@...db.de>
Cc: Tilman Schmidt <tilman@...p.cc>,
Christoph Biedl <linux-kernel.bfrz@...chmal.in-ulm.de>,
linux-arm-kernel@...ts.infradead.org, isdn@...ux-pingi.de,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
devel@...verdev.osuosl.org, linux-doc@...r.kernel.org,
netdev@...r.kernel.org, Jonathan Corbet <corbet@....net>,
linux-kernel@...r.kernel.org,
"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging
[Added Tilman and Christoph.]
On vr, 2016-03-04 at 16:24 +0100, Arnd Bergmann wrote:
> I actually did more patches that I ended up not submitting:
>
> * move hisax to staging
> * remove i4l support from gigaset
For the record: I have no reason to object a patch that does that. (I'm
not aware anyone complained when gigaset switched its default from i4l
to capi. By now all relevant distributions should use our capi driver.)
> * move i4l core to staging
On a local tree I have two (draft) patches that do some related
preliminary work:
- isdnhdlc: move into separate directory
- mISDN: NETJet: stop selecting ISDN_I4L
These trivial patches untangle mISDN and i4l. Perhaps you did something
similar in your "move i4l core to staging".
> while I initially thought that i4l as a whole is not just unmaintained
> but also more or less unused, patch 19cebbcb04c8 ("isdn: Partially
> revert debug format string usage clean up") came in that indicated
> that
> there are still users that even send patches for hisax, and that
> made me doubt whether we could consider it obsolete enough.
See also commit 3460baa62068 ("PCI: Fix minimum allocation address
overwrite").
> Any thoughts on this? If you like, I can send those too.
For my part I'm surprised that anyone is still using it. But apparently
the hardware that required commit 19cebbcb04c8 and 3460baa62068 (which
I'm unfamiliar with) is still operational. And since there never has
been, as far as I know, a global i4l to capi migration nor a global i4l
(and capi) to mISDN migration it might be that some people are stuck on
i4l drivers for their hardware. Perhaps that explains Cristoph's
commits.
> My main motivation was to not have to fix up the ippp implementation
> when I move the compat ioctl handler from fs/compat_ioctl.c
> into drivers/net/ppp/ppp_generic.c, but I guess I can do that
> anyway as it seems that i4l never worked properly in compat mode.
Paul Bolle
Powered by blists - more mailing lists