From patchwork Sat Mar 5 13:08:39 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tilman Schmidt X-Patchwork-Id: 592371 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id CA7B71401CD for ; Sun, 6 Mar 2016 00:09:09 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=imap.cc header.i=@imap.cc header.b=rp36oMRT; dkim=pass (1024-bit key; unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.b=Cw0xut3X; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752378AbcCENI4 (ORCPT ); Sat, 5 Mar 2016 08:08:56 -0500 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:35359 "EHLO out5-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750884AbcCENIw (ORCPT ); Sat, 5 Mar 2016 08:08:52 -0500 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 2747820543 for ; Sat, 5 Mar 2016 08:08:51 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Sat, 05 Mar 2016 08:08:51 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=imap.cc; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=AXecx OYHTt87s0dGIoXPWdx4sj8=; b=rp36oMRT3sEUJg/Phmp62fonBbLS2ilmX+Jzu +oEhyfTKU1NlJr9UnQq3w5tv0u5UToc1Rcy8F/gjSPs6O+Y8nXMZyp+Sky4R/wJn OYVsg+YPRcbOxRtN5a4ZJN2oAiAGNssFaqCnf6+cqRQD+HIXFyP0otOmPyfYZtFa sRDkkU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=AXecxOYHTt87s0dGIoXPWdx4sj8=; b=Cw0xu t3XOWonyV2pGuEIkgo2gCYkFP4Y9s3b5nptsC/B4CEKChb9vMRS1dpRTiBdNI1pO 1NgYa3MjVAnxlSa/Y877gxOvkkD2TQtLd2/prF/eRjCLwH6DBcXvJnf26hGyyRdm YJYvuLTSaDYP710hSXRxveGoE2gYjM7dq21qFo= X-Sasl-enc: i111vfSKKsQl9Jb/Qb4/P8h6OpiuNxrVDH4xwSt/j6P5 1457183330 Received: from [192.168.59.124] (p508da3c5.dip0.t-ipconnect.de [80.141.163.197]) by mail.messagingengine.com (Postfix) with ESMTPA id BAB2DC00012; Sat, 5 Mar 2016 08:08:47 -0500 (EST) Subject: Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging To: Paul Bolle , Arnd Bergmann References: <1456945629-1793533-1-git-send-email-arnd@arndb.de> <1456945629-1793533-2-git-send-email-arnd@arndb.de> <56D7F62E.6050502@linux-pingi.de> <1659125.tHp8H942OG@wuerfel> <1457108303.2651.112.camel@tiscali.nl> Cc: Christoph Biedl , linux-arm-kernel@lists.infradead.org, isdn@linux-pingi.de, Greg Kroah-Hartman , devel@driverdev.osuosl.org, linux-doc@vger.kernel.org, netdev@vger.kernel.org, Jonathan Corbet , linux-kernel@vger.kernel.org, "David S. Miller" From: Tilman Schmidt Message-ID: <56DADA57.9010200@imap.cc> Date: Sat, 5 Mar 2016 14:08:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <1457108303.2651.112.camel@tiscali.nl> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Am 04.03.2016 um 17:18 schrieb Paul Bolle: > [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.) No objection from me either. When the Gigaset driver is built for CAPI it can still be used from i4l applications via capidrv with no loss of functionality. That was a primary goal of the CAPI port. >> * move i4l core to staging That's a different story. Removing i4l support will actually remove a userspace visible feature. > 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. That would be a good thing regardless of any decision on the future of the i4l userspace interface. > 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. The trouble is that mISDN never cared about migration or backward compatibility. So while users of i4l applications have no problem with i4l drivers being ported to CAPI and dropping native i4l support, they do have a problem with drivers making that move to mISDN. That is the situation of the hisax driver today. mISDN started as a project to migrate hisax to CAPI but regrettably dropped that goal in favor of a newly invented API leaving old i4l based applications behind. As a consequence, owners of HiSAX type adapters are in fact stuck with the old hisax driver if they want to continue using i4l userspace tools. In my opinion, i4l, capidrv and hisax need to stay in the supported part for the time being as they are still actively used. Native i4l support can and should be dropped for hardware with CAPI drivers (ie. gigaset) but not for hardware with only mISDN drivers (ie. hisax). And finally, ISDN_CAPI_CAPIDRV should be enabled automatically if both ISDN_I4L and ISDN_CAPI are enabled, ie. something like: Jm2c, Tilman --- a/drivers/isdn/capi/Kconfig +++ b/drivers/isdn/capi/Kconfig @@ -27,8 +27,8 @@ config ISDN_CAPI_MIDDLEWARE your ISP, say Y here. config ISDN_CAPI_CAPIDRV - tristate "CAPI2.0 capidrv interface support" - depends on ISDN_I4L + tristate + default ISDN_I4L help This option provides the glue code to hook up CAPI driven cards to the legacy isdn4linux link layer. If you have a card which is