From patchwork Sat Feb 12 17:30:48 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Maciej W. Rozycki" X-Patchwork-Id: 542385 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D8B44C433EF for ; Sat, 12 Feb 2022 17:30:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230185AbiBLRay (ORCPT ); Sat, 12 Feb 2022 12:30:54 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:45612 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229971AbiBLRax (ORCPT ); Sat, 12 Feb 2022 12:30:53 -0500 Received: from angie.orcam.me.uk (angie.orcam.me.uk [IPv6:2001:4190:8020::34]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 26D33240A4; Sat, 12 Feb 2022 09:30:49 -0800 (PST) Received: by angie.orcam.me.uk (Postfix, from userid 500) id 501A592009C; Sat, 12 Feb 2022 18:30:48 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 4616092009B; Sat, 12 Feb 2022 17:30:48 +0000 (GMT) Date: Sat, 12 Feb 2022 17:30:48 +0000 (GMT) From: "Maciej W. Rozycki" To: Greg Kroah-Hartman , Jiri Slaby cc: Andy Shevchenko , linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 0/2] serial: 8250: Correct basic issues with the PCI blacklist Message-ID: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-serial@vger.kernel.org Hi, This v2 of the patch series adds missing filler member initialisers for blacklist entries using the PCI_DEVICE rather than PCI_VDEVICE macro that cause "initializer element is not computable at load time" compilation errors in some configurations, which have escaped my verification. An upside is I have noticed PARPORT_SERIAL (or indeed PARPORT_PC) is not selectable with numerous PCI platforms like RISC-V meaning that PC-style PCI parallel port hardware cannot be used with them even though there's no reason for that. The only PCI platforms that actually cannot make use of such hardware are those newer PCIe systems that have no support for I/O cycles in the host bridge with the only actual specimen known to me being the POWER9 PHB4 device, so we ought to enable PARPORT_PC/PARPORT_SERIAL support for PCI systems in the general case. I'll post a fix separately. The original cover letter continues. In the course of investigating whether support code for OxSemi PCIe UARTs could be factored out from the common 8250 PCI UART driver, which has been previously requested by Andy (cc-ed), I have noticed that the Kconfig help text for several device-specific UART drivers previously factored out is incorrect in that it claims that those dedicated drivers are required for extra features of the respective devices, while actually the blacklist entries within the common driver make them require those dedicated drivers even for standard features, as the common driver now refuses to handle them. Also it may be unclear for the user from a specific PCI device ID of an affected PCI UART device which dedicated driver has to be configured in to handle it, so make the blacklist entries include that information to be printed if a device is encountered that cannot be handled because its dedicated driver has been excluded from configuration while the common driver refuses to handle it. See the respective change descriptions for further details. Please apply. Maciej