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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E13FBC38A02 for ; Mon, 31 Oct 2022 08:46:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229945AbiJaIqf (ORCPT ); Mon, 31 Oct 2022 04:46:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34732 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229475AbiJaIqe (ORCPT ); Mon, 31 Oct 2022 04:46:34 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D8148B0F for ; Mon, 31 Oct 2022 01:46:33 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 64D5CB81189 for ; Mon, 31 Oct 2022 08:46:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8961EC433D6; Mon, 31 Oct 2022 08:46:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1667205990; bh=CQnvT/64qalh+dfsTFZ1is5YyXfiHf+XDAMhOUOk+SY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=H4wWcHjTqn44oFfZptvhUFjoCZdC01pzV2ykeg3FV6aFrac6PScYbnPu6kEENBbPz 1AkySNJDTLamK/ZUE2sJcK6mZFSx6eBPDX55/AeE1Wj4NtJH6kHEnTflFaXdty/dfc TGF8nY6QS42XUQTuBdVybUotBss2OtT6S2808HOy/Xkvq79NYBzXJye0cv0roA0OwA R+4pXje+Z7H0owKcMY0mmk4FeBvoJOGeI46YHee+/FztR9K55daHL4OfpGMuqZU6b1 Irjth0vD53c9BvsKw9aNkSzxkmQUxlkhIRwUTVjgX6NNdqu1urfggmsBpwM6zLi+td E2/99PizDruIA== Date: Mon, 31 Oct 2022 08:46:25 +0000 From: Lee Jones To: "Russell King (Oracle)" Cc: Hector Martin , 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 Subject: Re: [PATCH 4/6] platform/apple: Add new Apple Mac SMC driver Message-ID: References: <45ed0a37-60ac-3a06-92d1-6b30e18261ff@marcan.st> <8f30a490-f970-6605-20cb-c2256daab9de@marcan.st> <82088b05-2a0d-69cc-ba2c-d61c74c9d855@marcan.st> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Fri, 28 Oct 2022, Russell King (Oracle) wrote: > On Mon, Sep 12, 2022 at 11:55:14AM +0100, Lee Jones wrote: > > > I'm guessing this series is now dead, and Hector needs to re-spin the > > > patch set according to your views. I'm guessing this is going to take > > > a major re-work of the patch series. > > > > > > I suspect my attempt and trying to get this upstream has made things > > > more complicated, because I doubt Hector has updated his patch set > > > with the review comments that have been made so far... so this is > > > now quite a mess. I think, once this is sorted, the entire series > > > will need to be re-reviewed entirely afresh. > > > > I have no insight into what Hector is doing, or plans to do. > > It seems there's no plans by Hector to address this, so it comes down > to me. > > So, guessing what you're after, would something like the following > work for you? I don't see *any* point in creating more yet more > platform devices unless we're on a mission to maximise wasted memory > resources (which this split will already be doing by creating two > small modules instead of one.) > > Obviously, this is not an official patch yet, it's just to find out > what code structure you are looking for. > > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > index 78c6d9d99c3f..8d4c0508a2c8 100644 > --- a/drivers/mfd/Makefile > +++ b/drivers/mfd/Makefile > @@ -18,6 +18,8 @@ obj-$(CONFIG_MFD_ENE_KB3930) += ene-kb3930.o > obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o > obj-$(CONFIG_MFD_GATEWORKS_GSC) += gateworks-gsc.o > > +obj-$(CONFIG_APPLE_SMC) += apple-smc.o > + > obj-$(CONFIG_HTC_PASIC3) += htc-pasic3.o > obj-$(CONFIG_HTC_I2CPLD) += htc-i2cpld.o > > diff --git a/drivers/mfd/apple-smc.c b/drivers/mfd/apple-smc.c > new file mode 100644 > index 000000000000..bc59d1c5e13d > --- /dev/null > +++ b/drivers/mfd/apple-smc.c > @@ -0,0 +1,38 @@ > +#include > +#include > + > +static const struct mfd_cell apple_smc_devs[] = { > + { > + .name = "macsmc-gpio", > + .of_compatible = "apple,smc-gpio", > + }, > + { > + .name = "macsmc-hid", > + }, > + { > + .name = "macsmc-power", > + }, > + { > + .name = "macsmc-reboot", > + }, > + { > + .name = "macsmc-rtc", > + }, > +}; > + > +int apple_smc_mfd_probe(struct device *dev) > +{ > + return mfd_add_devices(dev, -1, apple_smc_devs, > + ARRAY_SIZE(apple_smc_devs), NULL, 0, NULL); > +} > +EXPORT_SYMBOL(apple_smc_mfd_probe); > + > +void apple_smc_mfd_remove(struct device *dev) > +{ > + mfd_remove_devices(dev); > +} > +EXPORT_SYMBOL(apple_smc_mfd_remove); > + > +MODULE_AUTHOR("Hector Martin "); > +MODULE_LICENSE("Dual MIT/GPL"); > +MODULE_DESCRIPTION("Apple SMC MFD core"); Conceptually interesting, not seen this one before, but clearly a hack, no? Pretty sure all of the other cores in MFD are represented by a Platform Device. Why not implement the inverse? The Apple SMC is clearly an MFD, in Linux terms, so why not move the Platform Device into here, fetch all of the global resources, register the sub-devices, then call into the rtkit implementation in drivers/platform? -- Lee Jones [李琼斯]