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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 310EEC433FE for ; Sat, 29 Oct 2022 06:42:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Subject:From:References:Cc: To:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=mgRhRHsMu+Qjm+/L1vMfqB3Bu0b6P8jePT0h7MSuUdc=; b=gasR7uR2vQYEt6 3/ZbdrfFYyI3vKkW6BPKW356l4YEvKgwqcq6Dm7dSZIhD1mHO+ZsbXZhPNfs90RJ/ZOBZ89KyhL55 gtKskEJ6gfQGbhUgpJmev7Zr4tgKOFuyO1HSXPcg02yNuI3sQXuOeoeJ8Rs1LWK1NYZ1u7MzP30WU yJOOaIfOsw4jN8N541y90lTctFWyWT85DNujk/eq22UxIGBjZ1di1XHIcnjZprXIYtIB47lt/JoHt nKFPmo899obElUOoKBFQWiPf3wyKyQEkSg2pbGi2+Z/ffjB5T4q87WkCSSKsYhcqj+/7uktaXJchN 6g/gA3cCMath4phCvamw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oofWo-004o21-KX; Sat, 29 Oct 2022 06:41:10 +0000 Received: from marcansoft.com ([212.63.210.85] helo=mail.marcansoft.com) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oofWj-004o0t-P1 for linux-arm-kernel@lists.infradead.org; Sat, 29 Oct 2022 06:41:09 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: marcan@marcan.st) by mail.marcansoft.com (Postfix) with ESMTPSA id E27B741DF4; Sat, 29 Oct 2022 06:41:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=marcan.st; s=default; t=1667025663; bh=zlfvaMlEW16tIV2PekMKgjqEmWJ18+KM0ANi+HZI96k=; h=Date:To:Cc:References:From:Subject:In-Reply-To; b=HxJPvwJu3anhirunpWjfBafxsoO8X0r0hrTElmLT5CY9r8YUT1LAehxQZzXVPi4Nh cqTasVdNr/706wGpvMsfsTAmCBzASckxStbaNX6/T8wsgtLQxVkfVXEJZimdmgvcSm XHNQhv81qnuzdSNbbfsN1m/xdtQvhZfbS3H2PxV8H0bfzGhQ0Oe/yTSZgH0NGOcQ5J KN2uHcmu/KqL5bSnpoAA1Q6r1h1sgegK9DVFLO2sUMovubqC8dcVsT5xm8gPez9+53 ax1qa7peFW904UimPyXpgrkF1b7zy6VhADYqOmONTNVWK0w9yV7VX0BVtLxPvbE8NI qHGAE8M3egLkw== Message-ID: Date: Sat, 29 Oct 2022 15:40:58 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Content-Language: en-US To: Lee Jones Cc: Russell King , Arnd Bergmann , Linus Walleij , Alyssa Rosenzweig , asahi@lists.linux.dev, Bartosz Golaszewski , linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org, Sven Peter References: <45ed0a37-60ac-3a06-92d1-6b30e18261ff@marcan.st> <8f30a490-f970-6605-20cb-c2256daab9de@marcan.st> <82088b05-2a0d-69cc-ba2c-d61c74c9d855@marcan.st> From: Hector Martin Subject: Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221028_234105_989372_ED7A1A66 X-CRM114-Status: GOOD ( 13.56 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 09/09/2022 16.50, Lee Jones wrote: >> What's the point of just having effectively an array of mfd_cell and >> wrappers to call into the mfd core in the drivers/mfd/ tree and the >> rest of the driver elsewhere? > > They should be separate drivers, with MFD registering the Platform. Why? What purpose does this serve? I'm still confused. There's one parent device, which provides services to the child devices. There isn't one parent device which wraps a platform service which is used by children. This makes no sense. The platform device is the root, if it exposes MFD services, then it has to be in that direction, not the other way around. Look at how this patch series is architected. There is smc_core.c, which implements SMC helpers and wrappers on top of a generic backend, and registers with the MFD subsystem. And then there is smc_rtkit.c which is the actual platform implementation on top of the RTKit framework, and is the actual platform device entry point. A priori, the only thing that makes sense to me right now would be to move smc_core.c into drivers/mfd, and leave smc_rtkit.c in platform. That way the mfd registration would be in drivers/mfd (as would be the services offered to sub-drivers), but the actual backend implementation would be in platform/ (and there would eventually be others, e.g. at least two more for x86 systems). That does mean that the driver entry point will be in platform/, with mfd/smc_core.c serving as effectively library code to plumb in the mfd stuff into one of several possible platform devices. Would that work for you? - Hector _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel