This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Mon May 20 05:39:19 2024 >From mailfetcher Thu Aug 17 19:05:12 2023 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pi4 X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 Authentication-Results: pi4.bmw12.nl; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: pi4.bmw12.nl; dkim=pass (Good 2048 bit rsa-sha256 signature) header.d=kernel.org header.a=rsa-sha256 Authentication-Results: pi4.bmw12.nl; spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org (client-ip=2620:137:e000::1:20; helo=out1.vger.email; envelope-from=linux-kernel-owner@vger.kernel.org; receiver=) Received: from secure.jasper.es [188.166.10.231] by 1dc7d414a5be with IMAP (fetchmail-6.3.26) for (single-drop); Thu, 17 Aug 2023 19:05:12 +0200 (CEST) Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by pi4.bmw12.nl (Postfix) with ESMTP id 497913F054 for ; Thu, 17 Aug 2023 19:05:10 +0200 (CEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353816AbjHQREi (ORCPT ); Thu, 17 Aug 2023 13:04:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47084 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1353815AbjHQREW (ORCPT ); Thu, 17 Aug 2023 1 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 944A630C2; Thu, 17 Aug 2023 10:04:20 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.sourc Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4FA81C433C7; Thu, 17 Aug 2023 17:04:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1692291859; bh=IUsc1dlDugnr6ByC8ySX3bNJAeDpRdUJA6/XtcW0ZB4=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=r3Z+lRPlDnQqU2+3I3DThI66ZNzutA3ShL/STD5dNv27ogS7aOGEk Date: Thu, 17 Aug 2023 12:04:17 -0500 From: Bjorn Helgaas To: Achal Verma Cc: Vignesh Raghavendra , Tom Joseph , Lorenzo Pieralisi , Krzysztof Wilczy_ski , Rob Herring , Bjorn Helgaas Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20230817120823.1158766-3-a-verma1@ti.com> Precedence: bulk List-Id: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 17, 2023 at 05:38:23PM +0530, Achal Verma wrote: > pci-j721e driver can be build as a in-built kernel driver only, which is > not required as it is not used during boot time in most cases. > This change add support to build pci-j721e as a kernel loadable module. >=20 > J721e PCIe controller can work in both host mode and end-point mode. > In order to enable host mode driver and endpoint driver to be built > independently either as built-in or kernel module, the pcie-j721e.c driver > is refactored into following components: >=20 > 1) pci-j721e-host.c: Driver used when PCIe controller has to be > initialized in host mode. >=20 > 2) pci-j721e-ep.c: Driver used when PCIe controller has to be > initialized in endpoint mode. >=20 > 3) pci-j721e.c: contains common code required in both modes. Sounds like at least two commits (I'm not sure what the best order would be): 1) Split into separate host mode and endpoint mode drivers 2) Make both drivers tristate It looks like you implement both module loading and removal. Do we now think removal of these modules is safe? IIRC there used to be a question related to irq_desc lifetimes, e.g., there's some discussion here: https://lore.kernel.org/linux-pci/87k085xekg.wl-maz@kernel.org/ The ability to *load* drivers as modules is definitely useful. The ability to *remove* them is useful for developers but not really useful for users. But I guess j721e_pcie_remove() already exists, so maybe you're not changing anything as far as irq_desc lifetimes=06 Since you're splitting into new files, maybe this is an opportunity to fix my naming mistake of suggesting a "pci-" prefix instead of "pcie-"? Bjorn > config PCI_J721E_HOST > - bool "TI J721E PCIe controller (host mode)" > + tristate "TI J721E PCIe controller (host mode)" > depends on OF > select PCIE_CADENCE_HOST > select PCI_J721E > @@ -56,7 +56,7 @@ config PCI_J721E_HOST > core. > =20 > config PCI_J721E_EP > - bool "TI J721E PCIe controller (endpoint mode)" > + tristate "TI J721E PCIe controller (endpoint mode)" > depends on OF > depends on PCI_ENDPOINT > select PCIE_CADENCE_EP > +static struct platform_driver j721e_pcie_ep_driver =3D { > + .probe =3D j721e_pcie_probe, > + .remove_new =3D j721e_pcie_remove, > + .driver =3D { > + .name =3D "j721e-pcie-ep", > + .of_match_table =3D of_j721e_pcie_ep_match, > + .suppress_bind_attrs =3D true, > + }, > +}; > +static struct platform_driver j721e_pcie_host_driver =3D { > + .probe =3D j721e_pcie_probe, > + .remove_new =3D j721e_pcie_remove, > + .driver =3D { > + .name =3D "j721e-pcie-host", > + .of_match_table =3D of_j721e_pcie_host_match, > + .suppress_bind_attrs =3D true, > + }, > +};