Message ID | 20230516110038.2413224-6-schnelle@linux.ibm.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp359788vqo; Tue, 16 May 2023 04:44:03 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4LIGOaD7iKmvBPrIK9orIXhyHbqxfi4mqLtgtIWrik+Lx+GWtcxQkuVPxtgzCMo4zT9uvi X-Received: by 2002:a05:6a20:9153:b0:101:3600:6aa5 with SMTP id x19-20020a056a20915300b0010136006aa5mr29548516pzc.3.1684237442643; Tue, 16 May 2023 04:44:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684237442; cv=none; d=google.com; s=arc-20160816; b=U8xDhfWE4zDr+VKY2YlINqwAPJniA4ddjstAgf+u2qeGmI19aovze1G7+H1DITVAdQ BfCn1BpPkZ/W6kBRfdITsy9Etc3ONtt8Qu3tvGKkKe1SE12iBUEYBlcIyhyGp6tnyz2b ngBADVmjA8DHYGslxkMgXFHR4ZSamwQOwBnVGZdoVPGVAJJB+ooJPIml6OhD6kkAWdPI jXWjhx2gNICnmBVZB9ynx9OpK9Nyxwp9ASPBJAlQdwIjdjw2UL7tC8P+OdgRDzm8Tk+i Q3FxQQMhxJ+LhYHNgxg+SoZJODFcaAAKlNLeD31pFNk0eSfrxPChSXr0SUON2WwEFoPw eq6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=g0ju0G5ljSQcFY9TtrqbUkpQaLS3HXWrWpg5v298c98=; b=MwvQNWEzOJjn56dAIIsqe5u5uoo0kYCiUhAZqmxB7Nnsi5jMTSzE5ZnX5JGFkOVryQ nDzEEqTjswOXWQbZhqrafywQkdxlOAXxeX86skseI9DqL/PDq20Ok+PJf0p27nolshD3 Csc6med+V86B6avKJPNNwOxVmD6u9+KuDIFzLo9x6yffjEMw7ki0XIbWkznbdJO8g5Fa Et11iIAA2mTMIwQAO2aUUeTJBfgqilW/sbRkTV81VwtrlIf9xkUtZ1YdCvu4WenBzsl+ jFAi+uDrAEMTibJ0b2j7GHRYiPRx4N2DgtEd+PV2siX83qCX5FgM3oZRvLBN1QtEtrw4 9n8g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=NB9OOEL8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=ibm.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x5-20020a654145000000b0051a8a22a42dsi9672067pgp.268.2023.05.16.04.43.49; Tue, 16 May 2023 04:44:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=NB9OOEL8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232452AbjEPLBP (ORCPT <rfc822;peekingduck44@gmail.com> + 99 others); Tue, 16 May 2023 07:01:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52670 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232147AbjEPLBF (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 16 May 2023 07:01:05 -0400 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C401F271E; Tue, 16 May 2023 04:01:03 -0700 (PDT) Received: from pps.filterd (m0353722.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 34GAjD5X030933; Tue, 16 May 2023 11:00:49 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding; s=pp1; bh=g0ju0G5ljSQcFY9TtrqbUkpQaLS3HXWrWpg5v298c98=; b=NB9OOEL8EoUaFMgbvnmpC0VdJ5PGFbIzGoawOvm/M0DZhB03CO0SP0UVFqncjvo/+VTT 7TIymBZYdN6vk9KucMs7FMTcgs64CcHcNQX0FZ+L6yuGxbp14BqJBBYYplDryWy0k3XN jsukUZm3b6328GYAIRkly0Hu9SmqPTNPih3smhiVAn2BdCEGQlg99rIWYwvh2KoqcGNo O9aPR8L6uHXIAAmv6/J2tDqlOlyw/iA4tNFlYlvAEKKl8uDIKdAJpquudC6BLTYix1Np bVbAOxyrQtpxi/MdEXjTsKGAHf/xxfl2XrplZKG9f/irlAHF2fPbyStWDgHovfga7X1b RA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3qm8bn0dua-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 May 2023 11:00:48 +0000 Received: from m0353722.ppops.net (m0353722.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 34GAkJGq001407; Tue, 16 May 2023 11:00:48 GMT Received: from ppma03ams.nl.ibm.com (62.31.33a9.ip4.static.sl-reverse.com [169.51.49.98]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3qm8bn0dt7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 May 2023 11:00:48 +0000 Received: from pps.filterd (ppma03ams.nl.ibm.com [127.0.0.1]) by ppma03ams.nl.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 34G5XBP3004842; Tue, 16 May 2023 11:00:46 GMT Received: from smtprelay07.fra02v.mail.ibm.com ([9.218.2.229]) by ppma03ams.nl.ibm.com (PPS) with ESMTPS id 3qj264sjvc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 May 2023 11:00:46 +0000 Received: from smtpav04.fra02v.mail.ibm.com (smtpav04.fra02v.mail.ibm.com [10.20.54.103]) by smtprelay07.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 34GB0h5335258648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 16 May 2023 11:00:43 GMT Received: from smtpav04.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C9FA62004F; Tue, 16 May 2023 11:00:43 +0000 (GMT) Received: from smtpav04.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6B12220040; Tue, 16 May 2023 11:00:43 +0000 (GMT) Received: from tuxmaker.boeblingen.de.ibm.com (unknown [9.152.85.9]) by smtpav04.fra02v.mail.ibm.com (Postfix) with ESMTP; Tue, 16 May 2023 11:00:43 +0000 (GMT) From: Niklas Schnelle <schnelle@linux.ibm.com> To: Arnd Bergmann <arnd@arndb.de>, William Breathitt Gray <william.gray@linaro.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Bjorn Helgaas <bhelgaas@google.com>, =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= <u.kleine-koenig@pengutronix.de>, Mauro Carvalho Chehab <mchehab@kernel.org>, Alan Stern <stern@rowland.harvard.edu>, "Rafael J. Wysocki" <rafael@kernel.org>, Geert Uytterhoeven <geert@linux-m68k.org>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-pci@vger.kernel.org, Arnd Bergmann <arnd@kernel.org>, linux-iio@vger.kernel.org Subject: [PATCH v4 05/41] counter: add HAS_IOPORT dependencies Date: Tue, 16 May 2023 13:00:01 +0200 Message-Id: <20230516110038.2413224-6-schnelle@linux.ibm.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230516110038.2413224-1-schnelle@linux.ibm.com> References: <20230516110038.2413224-1-schnelle@linux.ibm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: QJRLOc8_rHg0SmXXxM_2xlN7o5l25m5T X-Proofpoint-ORIG-GUID: UruyIM3AnuCGMs1Ap5IVTz2b0GNYDxFo X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-05-16_04,2023-05-16_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 lowpriorityscore=0 mlxlogscore=999 impostorscore=0 mlxscore=0 phishscore=0 suspectscore=0 spamscore=0 malwarescore=0 clxscore=1015 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2304280000 definitions=main-2305160089 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1766050960592468660?= X-GMAIL-MSGID: =?utf-8?q?1766050960592468660?= |
Series |
treewide: Remove I/O port accessors for HAS_IOPORT=n
|
|
Commit Message
Niklas Schnelle
May 16, 2023, 11 a.m. UTC
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends not being declared. We thus need to add HAS_IOPORT as dependency for those drivers using them. Co-developed-by: Arnd Bergmann <arnd@kernel.org> Signed-off-by: Arnd Bergmann <arnd@kernel.org> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> --- Note: The HAS_IOPORT Kconfig option was added in v6.4-rc1 so per-subsystem patches may be applied independently drivers/counter/Kconfig | 1 + 1 file changed, 1 insertion(+)
Comments
On Tue, May 16, 2023 at 01:00:01PM +0200, Niklas Schnelle wrote: > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends > not being declared. We thus need to add HAS_IOPORT as dependency for > those drivers using them. > > Co-developed-by: Arnd Bergmann <arnd@kernel.org> > Signed-off-by: Arnd Bergmann <arnd@kernel.org> > Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Hi Niklas, The change itself is fine, but please update the description to reflect that this is adding a depends on HAS_IOPORT_MAP rather than HAS_IOPORT, along with the reason why it's needed (i.e. devm_ioport_map() is used). Thanks, William Breathitt Gray > --- > Note: The HAS_IOPORT Kconfig option was added in v6.4-rc1 so > per-subsystem patches may be applied independently > > drivers/counter/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/counter/Kconfig b/drivers/counter/Kconfig > index 4228be917038..e65a2bf178b8 100644 > --- a/drivers/counter/Kconfig > +++ b/drivers/counter/Kconfig > @@ -15,6 +15,7 @@ if COUNTER > config 104_QUAD_8 > tristate "ACCES 104-QUAD-8 driver" > depends on (PC104 && X86) || COMPILE_TEST > + depends on HAS_IOPORT_MAP > select ISA_BUS_API > help > Say yes here to build support for the ACCES 104-QUAD-8 quadrature > -- > 2.39.2 >
On Thu, 2023-05-18 at 21:26 -0400, William Breathitt Gray wrote: > On Tue, May 16, 2023 at 01:00:01PM +0200, Niklas Schnelle wrote: > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends > > not being declared. We thus need to add HAS_IOPORT as dependency for > > those drivers using them. > > > > Co-developed-by: Arnd Bergmann <arnd@kernel.org> > > Signed-off-by: Arnd Bergmann <arnd@kernel.org> > > Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> > > Hi Niklas, > > The change itself is fine, but please update the description to reflect > that this is adding a depends on HAS_IOPORT_MAP rather than HAS_IOPORT, > along with the reason why it's needed (i.e. devm_ioport_map() is used). > > Thanks, > > William Breathitt Gray > > Right, this clearly needs adjustment. I went with the following commit message for v5: "counter: add HAS_IOPORT_MAP dependency The 104_QUAD_8 counter driver uses devm_ioport_map() without depending on HAS_IOPORT_MAP. This causes compilation to fail on platforms such as s390 which do not support I/O port mapping. Add the missing HAS_IOPORT_MAP dependency to fix this." Thanks, Niklas
On Fri, 2023-05-19 at 15:17 +0200, Niklas Schnelle wrote: > On Thu, 2023-05-18 at 21:26 -0400, William Breathitt Gray wrote: > > On Tue, May 16, 2023 at 01:00:01PM +0200, Niklas Schnelle wrote: > > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends > > > not being declared. We thus need to add HAS_IOPORT as dependency for > > > those drivers using them. > > > > > > Co-developed-by: Arnd Bergmann <arnd@kernel.org> > > > Signed-off-by: Arnd Bergmann <arnd@kernel.org> > > > Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> > > > > Hi Niklas, > > > > The change itself is fine, but please update the description to reflect > > that this is adding a depends on HAS_IOPORT_MAP rather than HAS_IOPORT, > > along with the reason why it's needed (i.e. devm_ioport_map() is used). > > > > Thanks, > > > > William Breathitt Gray > > > > > > Right, this clearly needs adjustment. I went with the following commit > message for v5: > > "counter: add HAS_IOPORT_MAP dependency > > The 104_QUAD_8 counter driver uses devm_ioport_map() without depending > on HAS_IOPORT_MAP. This causes compilation to fail on platforms such as > s390 which do not support I/O port mapping. Add the missing > HAS_IOPORT_MAP dependency to fix this." > Just noticed this isn't entirely correct. As devm_ioport_map() has an empty stub for HAS_IOPORT_MAP=n this doesn't lead to a compile error it just doesn't work. Will reword to "This causes the driver to not be useable on platforms ..."
On Fri, 2023-05-19 at 15:38 +0200, Niklas Schnelle wrote: > On Fri, 2023-05-19 at 15:17 +0200, Niklas Schnelle wrote: > > On Thu, 2023-05-18 at 21:26 -0400, William Breathitt Gray wrote: > > > On Tue, May 16, 2023 at 01:00:01PM +0200, Niklas Schnelle wrote: > > > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends > > > > not being declared. We thus need to add HAS_IOPORT as dependency for > > > > those drivers using them. > > > > > > > > Co-developed-by: Arnd Bergmann <arnd@kernel.org> > > > > Signed-off-by: Arnd Bergmann <arnd@kernel.org> > > > > Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> > > > > > > Hi Niklas, > > > > > > The change itself is fine, but please update the description to reflect > > > that this is adding a depends on HAS_IOPORT_MAP rather than HAS_IOPORT, > > > along with the reason why it's needed (i.e. devm_ioport_map() is used). > > > > > > Thanks, > > > > > > William Breathitt Gray > > > > > > > > > > Right, this clearly needs adjustment. I went with the following commit > > message for v5: > > > > "counter: add HAS_IOPORT_MAP dependency > > > > The 104_QUAD_8 counter driver uses devm_ioport_map() without depending > > on HAS_IOPORT_MAP. This causes compilation to fail on platforms such as > > s390 which do not support I/O port mapping. Add the missing > > HAS_IOPORT_MAP dependency to fix this." > > > > Just noticed this isn't entirely correct. As devm_ioport_map() has an > empty stub for HAS_IOPORT_MAP=n this doesn't lead to a compile error it > just doesn't work. Will reword to "This causes the driver to not be > useable on platforms ..." s/useable/usable/
On Fri, May 19, 2023 at 03:39:57PM +0200, Niklas Schnelle wrote: > On Fri, 2023-05-19 at 15:38 +0200, Niklas Schnelle wrote: > > On Fri, 2023-05-19 at 15:17 +0200, Niklas Schnelle wrote: > > > On Thu, 2023-05-18 at 21:26 -0400, William Breathitt Gray wrote: > > > > On Tue, May 16, 2023 at 01:00:01PM +0200, Niklas Schnelle wrote: > > > > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends > > > > > not being declared. We thus need to add HAS_IOPORT as dependency for > > > > > those drivers using them. > > > > > > > > > > Co-developed-by: Arnd Bergmann <arnd@kernel.org> > > > > > Signed-off-by: Arnd Bergmann <arnd@kernel.org> > > > > > Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> > > > > > > > > Hi Niklas, > > > > > > > > The change itself is fine, but please update the description to reflect > > > > that this is adding a depends on HAS_IOPORT_MAP rather than HAS_IOPORT, > > > > along with the reason why it's needed (i.e. devm_ioport_map() is used). > > > > > > > > Thanks, > > > > > > > > William Breathitt Gray > > > > > > > > > > > > > > Right, this clearly needs adjustment. I went with the following commit > > > message for v5: > > > > > > "counter: add HAS_IOPORT_MAP dependency > > > > > > The 104_QUAD_8 counter driver uses devm_ioport_map() without depending > > > on HAS_IOPORT_MAP. This causes compilation to fail on platforms such as > > > s390 which do not support I/O port mapping. Add the missing > > > HAS_IOPORT_MAP dependency to fix this." > > > > > > > Just noticed this isn't entirely correct. As devm_ioport_map() has an > > empty stub for HAS_IOPORT_MAP=n this doesn't lead to a compile error it > > just doesn't work. Will reword to "This causes the driver to not be > > useable on platforms ..." > > s/useable/usable/ 104_QUAD_8 has an explicit dependency on PC104 and X86, so I don't think it would ever be used outside of x86 platforms. Does it still make sense to have the HAS_IOPORT_MAP dependency in this case? William Breathitt Gray
On Fri, 2023-05-19 at 10:21 -0400, William Breathitt Gray wrote: > On Fri, May 19, 2023 at 03:39:57PM +0200, Niklas Schnelle wrote: > > On Fri, 2023-05-19 at 15:38 +0200, Niklas Schnelle wrote: > > > On Fri, 2023-05-19 at 15:17 +0200, Niklas Schnelle wrote: > > > > On Thu, 2023-05-18 at 21:26 -0400, William Breathitt Gray wrote: > > > > > On Tue, May 16, 2023 at 01:00:01PM +0200, Niklas Schnelle wrote: > > > > > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends > > > > > > not being declared. We thus need to add HAS_IOPORT as dependency for > > > > > > those drivers using them. > > > > > > > > > > > > Co-developed-by: Arnd Bergmann <arnd@kernel.org> > > > > > > Signed-off-by: Arnd Bergmann <arnd@kernel.org> > > > > > > Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> > > > > > > > > > > Hi Niklas, > > > > > > > > > > The change itself is fine, but please update the description to reflect > > > > > that this is adding a depends on HAS_IOPORT_MAP rather than HAS_IOPORT, > > > > > along with the reason why it's needed (i.e. devm_ioport_map() is used). > > > > > > > > > > Thanks, > > > > > > > > > > William Breathitt Gray > > > > > > > > > > > > > > > > > > Right, this clearly needs adjustment. I went with the following commit > > > > message for v5: > > > > > > > > "counter: add HAS_IOPORT_MAP dependency > > > > > > > > The 104_QUAD_8 counter driver uses devm_ioport_map() without depending > > > > on HAS_IOPORT_MAP. This causes compilation to fail on platforms such as > > > > s390 which do not support I/O port mapping. Add the missing > > > > HAS_IOPORT_MAP dependency to fix this." > > > > > > > > > > Just noticed this isn't entirely correct. As devm_ioport_map() has an > > > empty stub for HAS_IOPORT_MAP=n this doesn't lead to a compile error it > > > just doesn't work. Will reword to "This causes the driver to not be > > > useable on platforms ..." > > > > s/useable/usable/ > > 104_QUAD_8 has an explicit dependency on PC104 and X86, so I don't think > it would ever be used outside of x86 platforms. Does it still make sense > to have the HAS_IOPORT_MAP dependency in this case? > > William Breathitt Gray Well, yes and no, you're right that it doesn't really cause compile issues despite the "|| COMPILE_TEST" albeit the code could never work. Still, I'd add the dependency. At the very least it serves as documentation and maybe in the future someone will want to remove those empty stubs for HAS_IOPORT_MAP=n. Thanks Niklas
On Mon, May 22, 2023 at 12:42:15PM +0200, Niklas Schnelle wrote: > On Fri, 2023-05-19 at 10:21 -0400, William Breathitt Gray wrote: > > On Fri, May 19, 2023 at 03:39:57PM +0200, Niklas Schnelle wrote: > > > On Fri, 2023-05-19 at 15:38 +0200, Niklas Schnelle wrote: > > > > On Fri, 2023-05-19 at 15:17 +0200, Niklas Schnelle wrote: > > > > > On Thu, 2023-05-18 at 21:26 -0400, William Breathitt Gray wrote: > > > > > > On Tue, May 16, 2023 at 01:00:01PM +0200, Niklas Schnelle wrote: > > > > > > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends > > > > > > > not being declared. We thus need to add HAS_IOPORT as dependency for > > > > > > > those drivers using them. > > > > > > > > > > > > > > Co-developed-by: Arnd Bergmann <arnd@kernel.org> > > > > > > > Signed-off-by: Arnd Bergmann <arnd@kernel.org> > > > > > > > Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> > > > > > > > > > > > > Hi Niklas, > > > > > > > > > > > > The change itself is fine, but please update the description to reflect > > > > > > that this is adding a depends on HAS_IOPORT_MAP rather than HAS_IOPORT, > > > > > > along with the reason why it's needed (i.e. devm_ioport_map() is used). > > > > > > > > > > > > Thanks, > > > > > > > > > > > > William Breathitt Gray > > > > > > > > > > > > > > > > > > > > > > Right, this clearly needs adjustment. I went with the following commit > > > > > message for v5: > > > > > > > > > > "counter: add HAS_IOPORT_MAP dependency > > > > > > > > > > The 104_QUAD_8 counter driver uses devm_ioport_map() without depending > > > > > on HAS_IOPORT_MAP. This causes compilation to fail on platforms such as > > > > > s390 which do not support I/O port mapping. Add the missing > > > > > HAS_IOPORT_MAP dependency to fix this." > > > > > > > > > > > > > Just noticed this isn't entirely correct. As devm_ioport_map() has an > > > > empty stub for HAS_IOPORT_MAP=n this doesn't lead to a compile error it > > > > just doesn't work. Will reword to "This causes the driver to not be > > > > useable on platforms ..." > > > > > > s/useable/usable/ > > > > 104_QUAD_8 has an explicit dependency on PC104 and X86, so I don't think > > it would ever be used outside of x86 platforms. Does it still make sense > > to have the HAS_IOPORT_MAP dependency in this case? > > > > William Breathitt Gray > > Well, yes and no, you're right that it doesn't really cause compile > issues despite the "|| COMPILE_TEST" albeit the code could never work. > Still, I'd add the dependency. At the very least it serves as > documentation and maybe in the future someone will want to remove those > empty stubs for HAS_IOPORT_MAP=n. > > Thanks > Niklas Sure, that reasoning makes sense to me too, so let's go with the explicit depends afterall. By the way, I noticed two other modules that call devm_ioport_map() but seem to be missing the HAS_IOPORT_MAP depends lines: the drivers/iio/addac/stx104.c and drivers/iio/dac/cio-dac.c drivers. Do these need respective patches as well? As an aside, I haven't been following the previous patchsets closely so forgive me if this has already been discussed in another thread: why doesn't X86 automatically select HAS_IOPORT? Are there x86 platforms that do not support ioport? William Breathitt Gray
diff --git a/drivers/counter/Kconfig b/drivers/counter/Kconfig index 4228be917038..e65a2bf178b8 100644 --- a/drivers/counter/Kconfig +++ b/drivers/counter/Kconfig @@ -15,6 +15,7 @@ if COUNTER config 104_QUAD_8 tristate "ACCES 104-QUAD-8 driver" depends on (PC104 && X86) || COMPILE_TEST + depends on HAS_IOPORT_MAP select ISA_BUS_API help Say yes here to build support for the ACCES 104-QUAD-8 quadrature