From patchwork Sat Sep 8 07:59:01 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lukas Wunner X-Patchwork-Id: 10592913 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id B3233921 for ; Sat, 8 Sep 2018 08:05:06 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A607E2B1EE for ; Sat, 8 Sep 2018 08:05:06 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9A2292B1F5; Sat, 8 Sep 2018 08:05:06 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id F39252B1EE for ; Sat, 8 Sep 2018 08:05:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726394AbeIHMt4 (ORCPT ); Sat, 8 Sep 2018 08:49:56 -0400 Received: from bmailout3.hostsharing.net ([176.9.242.62]:58571 "EHLO bmailout3.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726315AbeIHMt4 (ORCPT ); Sat, 8 Sep 2018 08:49:56 -0400 Received: from h08.hostsharing.net (h08.hostsharing.net [83.223.95.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.hostsharing.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by bmailout3.hostsharing.net (Postfix) with ESMTPS id 7F9C9100AFDEC; Sat, 8 Sep 2018 10:05:02 +0200 (CEST) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 38A1F54F8B1; Sat, 8 Sep 2018 10:05:02 +0200 (CEST) Message-Id: <25396c1290e120913d44d0b9e4b83f1e4fefcc7c.1536341821.git.lukas@wunner.de> In-Reply-To: References: From: Lukas Wunner Date: Sat, 8 Sep 2018 09:59:01 +0200 Subject: [PATCH v2 8/8] PCI: hotplug: Document TODOs To: Bjorn Helgaas , linux-pci@vger.kernel.org Cc: Sinan Kaya , Mika Westerberg , Keith Busch Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP While refactoring the PCI hotplug core's API, I noticed a significant amount of technical debt in some of the hotplug drivers. Document the issues that caught my eye for starters. I do not have hardware at my disposal that utilizes the listed drivers and I think that's a prerequisite to work on them to ensure that no regressions sneak in. But some of this hardware is so old that it may be hard to come by. Obviously, it is fine to support old hardware, but the drivers need to be maintained. If noone steps up, perhaps we should consider sunsetting a few drivers by moving them to staging. Based on my findings, ibmphp would be the first candidate. I've found it fairly difficult to apply my API refactorings to it and have listed some obvious bugs in the driver. cpqphp is also in need of a modernization and would be a second candidate for relegation to staging. shpchp was introduced in the same commit as pciehp but hasn't benefited from the same amount of refactoring due to the decline of conventional PCI's relevance. Yet hardware supporting it may be more prevalent than for the proprietary hotplug methods. Per Documentation/process/2.Process.rst, "a TODO file should be present" for drivers in staging. The file introduced by the present commit may serve as a basis for this. Signed-off-by: Lukas Wunner Cc: Greg Kroah-Hartman Cc: Scott Murray Cc: Dan Zink Cc: Prarit Bhargava --- drivers/pci/hotplug/TODO | 74 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 drivers/pci/hotplug/TODO diff --git a/drivers/pci/hotplug/TODO b/drivers/pci/hotplug/TODO new file mode 100644 index 000000000000..a32070be5adf --- /dev/null +++ b/drivers/pci/hotplug/TODO @@ -0,0 +1,74 @@ +Contributions are solicited in particular to remedy the following issues: + +cpcihp: + +* There are no implementations of the ->hardware_test, ->get_power and + ->set_power callbacks in struct cpci_hp_controller_ops. Why were they + introduced? Can they be removed from the struct? + +cpqphp: + +* The driver spawns a kthread cpqhp_event_thread() which is woken by the + hardirq handler cpqhp_ctrl_intr(). Convert this to threaded IRQ handling. + The kthread is also woken from the timer pushbutton_helper_thread(), + convert it to call irq_wake_thread(). Use pciehp as a template. + +* A large portion of cpqphp_ctrl.c and cpqphp_pci.c concerns resource + management. Doesn't this duplicate functionality in the core? + +ibmphp: + +* Implementations of hotplug_slot_ops callbacks such as get_adapter_present() + in ibmphp_core.c create a copy of the struct slot on the stack, then perform + the actual operation on that copy. Determine if this overhead is necessary, + delete it if not. The functions also perform a NULL pointer check on the + struct hotplug_slot, this seems superfluous. + +* Several functions access the pci_slot member in struct hotplug_slot even + though pci_hotplug.h declares it private. See get_max_bus_speed() for an + example. Either the pci_slot member should no longer be declared private + or ibmphp should store a pointer to its bus in struct slot. Probably the + former. + +* The functions get_max_adapter_speed() and get_bus_name() are commented out. + Can they be deleted? There are also forward declarations at the top of + ibmphp_core.c as well as pointers in ibmphp_hotplug_slot_ops, likewise + commented out. + +* ibmphp_init_devno() takes a struct slot **, it could instead take a + struct slot *. + +* The return value of pci_hp_register() is not checked. + +* iounmap(io_mem) is called in the error path of ebda_rsrc_controller() + and once more in the error path of its caller ibmphp_access_ebda(). + +* The various slot data structures are difficult to follow and need to be + simplified. A lot of functions are too large and too complex, they need + to be broken up into smaller, manageable pieces. Negative examples are + ebda_rsrc_controller() and configure_bridge(). + +* A large portion of ibmphp_res.c and ibmphp_pci.c concerns resource + management. Doesn't this duplicate functionality in the core? + +sgi_hotplug: + +* Several functions access the pci_slot member in struct hotplug_slot even + though pci_hotplug.h declares it private. See sn_hp_destroy() for an + example. Either the pci_slot member should no longer be declared private + or sgi_hotplug should store a pointer to it in struct slot. Probably the + former. + +shpchp: + +* There is only a single implementation of struct hpc_ops. Can the struct be + removed and its functions invoked directly? This has already been done in + pciehp with commit 82a9e79ef132 ("PCI: pciehp: remove hpc_ops"). Clarify + if there was a specific reason not to apply the same change to shpchp. + +* The ->get_mode1_ECC_cap callback in shpchp_hpc_ops is never invoked. + Why was it introduced? Can it be removed? + +* The hardirq handler shpc_isr() queues events on a workqueue. It can be + simplified by converting it to threaded IRQ handling. Use pciehp as a + template.