From mboxrd@z Thu Jan 1 00:00:00 1970 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 shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 594C3C4332F for ; Thu, 20 Oct 2022 08:02:31 +0000 (UTC) Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.96) (envelope-from ) id 1olQVG-0004J5-01; Thu, 20 Oct 2022 04:02:10 -0400 Received: from wout4-smtp.messagingengine.com ([64.147.123.20]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1olQVB-0004Ir-2w for kernelnewbies@kernelnewbies.org; Thu, 20 Oct 2022 04:02:06 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 52B0A320079B; Thu, 20 Oct 2022 04:02:01 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 20 Oct 2022 04:02:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kroah.com; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; t=1666252920; x=1666339320; bh=kY5opGd7b7 BtrZOyr7Omim+Ryr9wYG0p53tFanrSyB8=; b=kTWHIkmRtkFv2/7vvaimCywUff 7/ppGnFbimmoKjTFaSGAUQm/RtI0UXBZfOf3VNKI+q9lM123LIkLE2PGNJbrqmNK 3qHJze7LOon3+ssOFAhg+dInvMb1MIm7XWw98hPHuUAue0HQCxtSXzFQdDukPOiS RoRVpaYNyxpWs0E6T7Exe8tWhkL0NEwKd6t++zKT2R5DkcozVaWJMRj4xZs7qRRW EUkZHJL+vV35e3SqeUxwsShBUtp3B8J4t9Hvum6FZM4LKngzIJxbvqFRHveQLdiY 8awv0hz4Rg0BYHo/zXZceMbMaZ341RuIw3t73W3y4CQZrFFKgoDeU+4R/Euw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1666252920; x=1666339320; bh=kY5opGd7b7BtrZOyr7Omim+Ryr9w YG0p53tFanrSyB8=; b=MOYo3xV5RcSjNwlO9O9fznsuZQrFg6Mvlk4zAQeKn22u ZUFhJmBxPkW/akyH6V8XEaU5imedjLzvMXCM5Aniq1+GLkGURkPzxQUVAVeH487+ Oit8c2LXFBHzkkuX0AopEkM/HB6HgleNXfVMdp2FPPoNi86jGQ8O6aQ41axyiiYJ Ru6SLpV9tZbVfXHWHE0i+Om2OFx8NmUTQUw0TsMSuKMBEwFIrFffBttmg0huS/Sz MKB6SdpUu1g/I+OxohYHLnla4MJSkVY3yhxp0Y7MquvhQtiVytUbvEK5trY9DzO3 BO7QIiYBEUyyjYyifqIloTTKXsAM2K5QSBl3oJFOyw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeelhedguddviecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefirhgv ghcumffjuceoghhrvghgsehkrhhorghhrdgtohhmqeenucggtffrrghtthgvrhhnpeehge dvvedvleejuefgtdduudfhkeeltdeihfevjeekjeeuhfdtueefhffgheekteenucevlhhu shhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehgrhgvgheskhhroh grhhdrtghomh X-ME-Proxy: Feedback-ID: i787e41f1:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 20 Oct 2022 04:02:00 -0400 (EDT) Date: Thu, 20 Oct 2022 10:01:57 +0200 From: Greg KH To: "Billie Alsup (balsup)" Subject: Re: Source code organization Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Cc: "kernelnewbies@kernelnewbies.org" X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kernelnewbies-bounces@kernelnewbies.org On Mon, Oct 17, 2022 at 06:00:40PM +0000, Billie Alsup (balsup) wrote: > I have a set of drivers that I would like to upstream. These are primarily > MFD style drivers supporting Cisco-8000 FPGAs. The devices can be > instantiated through multiple top level drivers, which provide the access > mechanism for the MFD driver. For example, an FPGA can be accessed via > PCI, or via i2c, or via SLPC, or via P2PM (a point-to-point interface). We > currently build these drivers out of tree, under a single directory drivers/cisco. > I note that existing drivers are spread out across the kernel tree, sometimes > by bus (pci, i2c), sometimes by function (gpio, net/mdio, spi), and sometimes > under the generic mfd. Yes, it's not always easy to find the common pattern, but usually it is: - is this a bus driver that allows bus access to this hardware (pci, gpio, i2c)? If so, add to drivers/pci|gpio|i2c - is this a userspace-facing driver that implements a user "class" of interactions (input, HID, block, etc.). If so, add to drivers/input|hid|block - is this something else? Then pick a place and submit a patch and people will tell you if you got it wrong :) > I would like to start the upstream review process for our drivers, but first want > to get recommendations on the source code layout. Is it permissible to keep > a top level directory such as drivers/cisco to organize our code? It is not only > the source code that is affected, but also provides a central place for Kconfig > entries. Our FPGAs have multiple logical blocks, each of which is handled by > a different MFD driver, e.g. i2c controllers, gpio controllers, spi controllers, mdio > controllers. There can be multiple instances of each block as well (so multiple > MFD devices are instantiated for each driver). And of course, there can be > multiple FPGAs in a system, each with different combinations of logical blocks. > > The drivers themselves are pretty specific to our FPGAs, thus it makes sense to > use Kconfig to select a hardware platform to automatically select the set of MFD > drivers (and top level bus drivers) that would apply. > > Would a source layout putting all the code under drivers/cisco be acceptable in > this case, or do I need to move things around and spread out the Kconfig entries > across directories? I note that a single drivers/cisco would simplify any related > modifications to MAINTAINERS as well. No, we do not have "vendor" directories like this, as that's almost always not what you want over time anyway. Just scatter your drivers around the tree based on the type and the subsystem interactions you need to have. But step back, why are you creating MFD devices anyway? Why not make "real" devices in your hardware representation as you control the FPGA and DT definitions, right? That would make things much easier if you put the devices on a discoverable bus then the drivers can be autoloaded as needed by the kernel when they are discovered. Do that, then you can put your fpga interface in drivers/fpga :) thanks, greg k-h _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies