Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp5789723ybx; Sun, 10 Nov 2019 21:43:57 -0800 (PST) X-Google-Smtp-Source: APXvYqz8twCwfeXzDKFU1J85sHRCO5QiAn98RT0BVHTutAR1YHZp50H6YQkSMzGCDg71x7Iq5jKz X-Received: by 2002:a17:906:27c5:: with SMTP id k5mr20444986ejc.173.1573451037219; Sun, 10 Nov 2019 21:43:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573451037; cv=none; d=google.com; s=arc-20160816; b=sN0wXHMD0MvcY2KUTST4+BZBJm9g/jPHwv1BnOErvGRXhm+xVDTzEa5N2h4ShDt/Pt gaiClCLE8OLN5kFTbk6etZv31eP/ObaOxA9C2Z/NYHbyu9YBjk13hGQbRbKiv1ktJcEa XzAo+8iPG0WDfYrNsebudwU/wHX4DtcnkcTeCs19Sj3jxbkDolF4w8fvlk5864w+WTM1 O6p/+H0XMg76PMsJytrZqOq8YIz4NS75bdFiVH3tHcqnGnPOd9B1kJK7V12B08YFicey HzQSbFWg62bTe3ZVsDnIisoA8OB/CrUFZrfVFd8kdP2rbEwVfcfTbUT/lxsIowlNi5kI rTVg== 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=EvC7x81klA3ke1PxIZVuM0Pu/J7aifIbSh0BIN7dTIs=; b=ZzoMZNgm5RuOWbp6YNZ81TNoU6XyqHQ9AIpiwu+MGT9hZWJrOTfLjWlokkZsKj+EQ6 ePlZLARAEsa0wHmSEsKjYosDAsG2ifR+ktwTzgrPyb6xuziX6C2R+JrhbLzlCAmMDRZC DQMBGNfmxCMqQlshI7pWybtO+3ETl00kwZ7o2n3pvjLGpKtgY89PWIpj8QjhcDdX+HWM 73xUfdvt3Rrkwl8Wgj1a+0OjMyTJf7nh17aFv6F6B/4rWoBJbE2B0bwT+M3cMlnzhqyh EAP3TcYj8TVSB7fw9btQgDeWBZYn2Nkdr/x44iXI5eEoe8HEvsbLmbI/0VXOAE04t0L7 aUMA== 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 1si12266136edv.82.2019.11.10.21.43.34; Sun, 10 Nov 2019 21:43:57 -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 S1726830AbfKKFmH (ORCPT + 99 others); Mon, 11 Nov 2019 00:42:07 -0500 Received: from mx2.suse.de ([195.135.220.15]:57618 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726164AbfKKFmH (ORCPT ); Mon, 11 Nov 2019 00:42:07 -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 2E3A4ACC0; Mon, 11 Nov 2019 05:42:06 +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" References: <20191103013645.9856-3-afaerber@suse.de> <20191111045609.7026-1-afaerber@suse.de> <20191111052741.GB3176397@kroah.com> From: =?UTF-8?Q?Andreas_F=c3=a4rber?= Organization: SUSE Software Solutions Germany GmbH Message-ID: <586fa37c-6292-aca4-fa7c-73064858afaf@suse.de> Date: Mon, 11 Nov 2019 06:42:05 +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: <20191111052741.GB3176397@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 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! 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. Thanks, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)