Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp6637465ybx; Mon, 11 Nov 2019 12:12:35 -0800 (PST) X-Google-Smtp-Source: APXvYqw1j0xwlqQvlOTkza6yuRyNcOeVmG4TRodnpqXEjr6f13zCm3LDn1POJCmApa7rVS8GIWMU X-Received: by 2002:a17:906:e297:: with SMTP id gg23mr24928711ejb.41.1573503155047; Mon, 11 Nov 2019 12:12:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573503155; cv=none; d=google.com; s=arc-20160816; b=NuFhL4orUPY1vOb/MehA/KPuMjfZ53g0AkWDGAXH5ar1mpUamkrkizDk9ypRuHJoxh peSdJUBVHvJ0SmDPZrL+Bpw4mxV8aFF7f/WwZHcXaJNTx5Tg1i6jacd5LVkzKnWElV0Q RMO5TwoY/XXIMdM2kjxN2zpx4NLRGO7JRIyvNFEauvxjZf6AMPM/PCZjxd8EMfmYnKty hiBnCJBmss4WtvrrPiLr0Uaxbzvuwe8x+u1fTeSjhA7Yqm0Z1kVWS4DErJ7qcs4pMRq6 vAQxD/Z3NOpud+4JOtwFt0ZEiueRwjFdGzB4dAYqIODVOrXL7ZlaLyNOvyjIlznyJUv6 MOTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject; bh=y+jubr0ewAzKuW97VnPpexXWgOF+f9d8FMmfQwKFcWM=; b=ROLUPuhhYDpHcsQM5BXl/Ko2EkMsN4Bmi2Qj6qNRESEZmMKBjjL4MRs4zk50sQnJ39 se51/vv7HA2+pbimiIRSCt7wtJGDTfer3iKYL6OSazA0LDw6UYhV+wKelB0Kgzjy46Bj fdJg1H0MzA1YQHqVhNG96qiocKxmxKoST4VXWltxUoTrdDA1sTA7Q6JEoBLtgzsTNPZT DxCMGm7Nw/5jOlll1V1u6FDcwEDbaDn8fZBlV3jQiH9S0kHMBjY11IUinWU/QqmUQHFZ MMTcgdEupt0HIQW2Q/Vt8kJw2fv/ZGq5cX2Zn7qoqxQAAnzxJJAUjvO9jkpheSRzj6z2 Hf7A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k21si9606246ejc.148.2019.11.11.12.12.10; Mon, 11 Nov 2019 12:12:35 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727486AbfKKUKt (ORCPT + 99 others); Mon, 11 Nov 2019 15:10:49 -0500 Received: from mx2.suse.de ([195.135.220.15]:51594 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726954AbfKKUKt (ORCPT ); Mon, 11 Nov 2019 15:10:49 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 74AD0B381; Mon, 11 Nov 2019 20:10:45 +0000 (UTC) Subject: Re: [PATCH] base: soc: Export soc_device_to_device() helper To: Greg Kroah-Hartman Cc: linux-realtek-soc@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Lee Jones , Bjorn Andersson , Geert Uytterhoeven , "Rafael J. Wysocki" , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Hartley Sweeten , Alexander Sverdlin , Tony Lindgren , linux-omap@vger.kernel.org, Michal Simek , Kevin Hilman , linux-amlogic@lists.infradead.org, Thierry Reding , Jonathan Hunter , "linux-tegra@vger.kernel.org" , Linus Walleij References: <20191103013645.9856-3-afaerber@suse.de> <20191111045609.7026-1-afaerber@suse.de> <20191111052741.GB3176397@kroah.com> <586fa37c-6292-aca4-fa7c-73064858afaf@suse.de> <20191111064040.GA3502217@kroah.com> From: =?UTF-8?Q?Andreas_F=c3=a4rber?= Organization: SUSE Software Solutions Germany GmbH Message-ID: Date: Mon, 11 Nov 2019 21:10:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: <20191111064040.GA3502217@kroah.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: > On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: >> Hi Greg, >> >> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: >>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: >>>> Use of soc_device_to_device() in driver modules causes a build failure. >>>> Given that the helper is nicely documented in include/linux/sys_soc.h, >>>> let's export it as GPL symbol. >>> >>> I thought we were fixing the soc drivers to not need this. What >>> happened to that effort? I thought I had patches in my tree (or >>> someone's tree) that did some of this work already, such that this >>> symbol isn't needed anymore. >> >> I do still see this function used in next-20191108 in drivers/soc/. >> >> I'll be happy to adjust my RFC driver if someone points me to how! > > Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs > entries") for how you can just use the default attributes for the soc to > create the needed sysfs files, instead of having to do it "by hand" > which is racy and incorrect. Unrelated. >> Given the current struct layout, a type cast might work (but ugly). >> Or if we stay with my current RFC driver design, we could use the >> platform_device instead of the soc_device (which would clutter the >> screen more than "soc soc0:") or resort to pr_info() w/o device. > > Ick, no, don't cast blindly. What do you need the pointer for? Is this > for in-tree code? No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ As I indicated above, I used it for a dev_info(), which I can easily avoid by using pr_info() instead: diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c index e5078c6731fd..f9380e831659 100644 --- a/drivers/soc/realtek/chip.c +++ b/drivers/soc/realtek/chip.c @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) platform_set_drvdata(pdev, soc_dev); - dev_info(soc_device_to_device(soc_dev), - "%s %s (0x%08x) rev %s (0x%08x) detected\n", + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, soc_dev_attr->revision, chip_rev); But as I said, there is still in-tree code using this helper: arch/arm/mach-ep93xx/core.c: return soc_device_to_device(soc_dev); Returned from ep93xx_init_soc(), which is passed through by ep93xx_init_devices(): arch/arm/mach-ep93xx/adssphere.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/edb93xx.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/gesbc9312.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/micro9.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/simone.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/snappercl15.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/ts72xx.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/ts72xx.c: ep93xx_init_devices(); arch/arm/mach-ep93xx/vision_ep9307.c: ep93xx_init_devices(); Return value unused everywhere. arch/arm/mach-imx/cpu.c: return soc_device_to_device(soc_dev); Used as return value of imx_soc_device_init(): arch/arm/mach-imx/mach-imx6q.c: parent = imx_soc_device_init(); arch/arm/mach-imx/mach-imx6sl.c: parent = imx_soc_device_init(); arch/arm/mach-imx/mach-imx6sx.c: parent = imx_soc_device_init(); arch/arm/mach-imx/mach-imx6ul.c: parent = imx_soc_device_init(); These do a NULL check and pass it to of_platform_default_populate(). arch/arm/mach-imx/mach-imx7d.c: parent = imx_soc_device_init(); This one only does a NULL check. arch/arm/mach-imx/mach-imx7ulp.c: of_platform_default_populate(NULL, NULL, imx_soc_device_init()); Speaks for itself. arch/arm/mach-mxs/mach-mxs.c: parent = soc_device_to_device(soc_dev); Passed to of_platform_default_populate(). arch/arm/mach-omap2/id.c: parent = soc_device_to_device(soc_dev); Used for device_create_file(). arch/arm/mach-zynq/common.c: parent = soc_device_to_device(soc_dev); Passed to of_platform_default_populate(). drivers/soc/amlogic/meson-gx-socinfo.c: dev = soc_device_to_device(soc_dev); Used for dev_info(). CONFIG_MESON_GX_SOCINFO is bool, thus not affected. drivers/soc/amlogic/meson-mx-socinfo.c: dev_info(soc_device_to_device(soc_dev), "Amlogic %s %s detected\n", Speaks for itself. CONFIG_MESON_MX_SOCINFO is bool, thus not affected. drivers/soc/tegra/fuse/fuse-tegra.c: return soc_device_to_device(dev); Returned from tegra_soc_device_register(). For arm64 NULL-checked only, but also used for arm in arch/arm/mach-tegra/tegra.c:tegra_dt_init(), which passes it to of_platform_default_populate(). drivers/soc/ux500/ux500-soc-id.c: parent = soc_device_to_device(soc_dev); Used for device_create_file(). drivers/soc/versatile/soc-integrator.c: dev = soc_device_to_device(soc_dev); Used for device_create_file(). drivers/soc/versatile/soc-realview.c: device_create_file(soc_device_to_device(soc_dev), &realview_manf_attr); drivers/soc/versatile/soc-realview.c: device_create_file(soc_device_to_device(soc_dev), &realview_board_attr); drivers/soc/versatile/soc-realview.c: device_create_file(soc_device_to_device(soc_dev), &realview_arch_attr); drivers/soc/versatile/soc-realview.c: device_create_file(soc_device_to_device(soc_dev), &realview_build_attr); Speaks for itself. So, not counting my unmerged Realtek driver, * we have two cases of struct device being used for dev_info(), which could be cleaned up with device-less pr_info(), I could post a patch, * frequent usage in arm/mach-* for of_platform_default_populate(), this seems most difficult to replace if we neither want to cast nor expose the struct, * some simply unused, which could be refactored to return void, and * some for device_create_file(), which could probably be avoided with custom_attr_group. It also raises the question of whether new arm platforms such as RTD1195 (mach-realtek) should attempt to use of_platform_default_populate() with the soc_device somehow, or if not, whether those platforms should be refactored to consistently no longer do so? I believe in the Broken Window Theory, i.e. fixing what we can before mistakes get copied and propagate further in code; but here I don't see a perspective for getting rid of soc_device_to_device() completely to prevent new usages, nor can I test all of those platforms myself. Has a cleanup based on custom_attr_group been attempted already and is waiting on patches to get reviewed and merged through maintainer trees, or do we need to prepare new cleanup patches here? A search for "soc_device_to_device" on LAKML Patchwork shows only this patch of mine. Thanks, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)