From: Paul Bolle <pebolle@tiscali.nl>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Tilman Schmidt <tilman@imap.cc>,
Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>,
linux-arm-kernel@lists.infradead.org, isdn@linux-pingi.de,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
devel@driverdev.osuosl.org, linux-doc@vger.kernel.org,
netdev@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
linux-kernel@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging
Date: Fri, 04 Mar 2016 17:18:23 +0100 [thread overview]
Message-ID: <1457108303.2651.112.camel@tiscali.nl> (raw)
In-Reply-To: <1659125.tHp8H942OG@wuerfel>
[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
WARNING: multiple messages have this Message-ID (diff)
From: pebolle@tiscali.nl (Paul Bolle)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging
Date: Fri, 04 Mar 2016 17:18:23 +0100 [thread overview]
Message-ID: <1457108303.2651.112.camel@tiscali.nl> (raw)
In-Reply-To: <1659125.tHp8H942OG@wuerfel>
[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
next prev parent reply other threads:[~2016-03-04 16:18 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-02 19:06 [PATCH 1/2] isdn: icn: remove a #warning Arnd Bergmann
2016-03-02 19:06 ` Arnd Bergmann
2016-03-02 19:06 ` [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging Arnd Bergmann
2016-03-02 19:06 ` Arnd Bergmann
2016-03-03 8:30 ` isdn
2016-03-03 8:30 ` isdn at linux-pingi.de
2016-03-04 15:24 ` Arnd Bergmann
2016-03-04 15:24 ` Arnd Bergmann
2016-03-04 16:18 ` Paul Bolle [this message]
2016-03-04 16:18 ` Paul Bolle
2016-03-04 16:32 ` Arnd Bergmann
2016-03-04 16:32 ` Arnd Bergmann
2016-03-07 8:33 ` Paul Bolle
2016-03-07 8:33 ` Paul Bolle
2016-03-05 13:08 ` Tilman Schmidt
2016-03-05 13:08 ` Tilman Schmidt
2016-03-07 8:48 ` Paul Bolle
2016-03-07 8:48 ` Paul Bolle
2016-03-09 22:10 ` Tilman Schmidt
2016-03-09 22:10 ` Tilman Schmidt
2016-03-10 10:53 ` isdn
2016-03-10 10:53 ` isdn at linux-pingi.de
2016-03-10 10:53 ` isdn
2016-03-10 12:58 ` Paul Bolle
2016-03-10 12:58 ` Paul Bolle
2016-03-10 16:41 ` isdn
2016-03-10 16:41 ` isdn at linux-pingi.de
2016-03-10 16:41 ` isdn
2016-03-11 20:04 ` Tilman Schmidt
2016-03-11 20:04 ` Tilman Schmidt
2016-03-11 20:04 ` Tilman Schmidt
2016-03-04 18:18 ` isdn
2016-03-04 18:18 ` isdn at linux-pingi.de
2016-03-04 21:00 ` Arnd Bergmann
2016-03-04 21:00 ` Arnd Bergmann
2016-03-07 6:57 ` Holger Schurig
2016-03-07 6:57 ` Holger Schurig
2016-03-19 10:27 ` Tilman Schmidt
2016-03-19 10:27 ` Tilman Schmidt
2016-03-19 10:27 ` Tilman Schmidt
2016-03-03 22:22 ` David Miller
2016-03-03 22:22 ` David Miller
2016-03-03 22:33 ` Greg KH
2016-03-03 22:33 ` Greg KH
2016-03-03 22:33 ` Greg KH
2016-03-05 3:19 ` kbuild test robot
2016-03-05 3:19 ` kbuild test robot
2017-01-03 15:24 ` Greg Kroah-Hartman
2017-01-03 15:24 ` Greg Kroah-Hartman
2017-01-03 15:24 ` Greg Kroah-Hartman
2017-01-03 21:19 ` Arnd Bergmann
2017-01-03 21:19 ` Arnd Bergmann
2017-01-03 21:54 ` Paul Bolle
2017-01-03 21:54 ` Paul Bolle
2017-01-03 22:25 ` Arnd Bergmann
2017-01-03 22:25 ` Arnd Bergmann
2017-01-03 22:57 ` Paul Bolle
2017-01-03 22:57 ` Paul Bolle
2017-01-03 23:03 ` Arnd Bergmann
2017-01-03 23:03 ` Arnd Bergmann
2017-01-03 23:03 ` Arnd Bergmann
2017-01-05 21:19 ` Greg Kroah-Hartman
2017-01-05 21:19 ` Greg Kroah-Hartman
2017-01-05 21:19 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1457108303.2651.112.camel@tiscali.nl \
--to=pebolle@tiscali.nl \
--cc=arnd@arndb.de \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=isdn@linux-pingi.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel.bfrz@manchmal.in-ulm.de \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=tilman@imap.cc \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.