[PATCH 2/2] isdn: i4l: move active-isdn drivers to staging
arnd at arndb.de
Fri Mar 4 16:32:00 UTC 2016
On Friday 04 March 2016 17:18:23 Paul Bolle wrote:
> [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".
Yes, I have the same thing. I didn't mention it here as it should
be completely non-controversial.
A third patch moves the capidrv source from drivers/isdn/capi/
into the i4l directory.
> > 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
My understanding is that it's not about the hardware, and that all
devices that people actually use with hisax should also with with
Instead, the only argument I've heard about keeping i4l and hisax
around (indefinitely) is that existing user space tools are written
for i4l and not ported to mISDN. They work fine with CAPI drivers
using capidrv.ko, but there is no i4l emulation on top of mISDN.
More information about the devel