Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp115925ybc; Mon, 11 Nov 2019 21:36:59 -0800 (PST) X-Google-Smtp-Source: APXvYqzxe4eS8ozuzGphzWL/TJXtHsAi/3FR/jWbehVKT79bWiv7weTpOxQJ1s2qSYv8ThhHFSHz X-Received: by 2002:a17:906:70e:: with SMTP id y14mr26174530ejb.70.1573537019330; Mon, 11 Nov 2019 21:36:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573537019; cv=none; d=google.com; s=arc-20160816; b=yF4G3kC+JNEzUSNn4QRjnGq2kxUDGgUyPel3/JoLcLmY5/xy/Z8KRGWUXNr4yZFx4p JQt6a1DIMxnNDKtz9DEwFxuzrQ0O66zzbjyHyCG5v479RX33HKCApYlqf59o6YXZ/2JJ fzuPkcNERTp4zSjx1UqHmrtqpAs3HFUDI+x+oFNyWmSLAonYKdyc9hGfG3wxAe4vJqYw Tp0Szi46cUjEfcxnYAPiLPaaEJ+eDZaSFC4K3VEC8qb5vUSLm8Ai4Ybapj9T0twXZtAq Jny/OWz5GWIzunCxVU837Dqz9Q+4DaUXzsQBWzWWPzgOidzHVEDt+zjswQT1IkQctoYh J0Ig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=lBbqBPQoBekZt4Zcy+Su5NpmxZF6bk0DVrT0i/ST7ew=; b=zWGqeA//JGngefufkFMtP7Cdn0N9l3pAHzJHjikfCnxPZvC//I+IoLZaWeGQuFWKWn KHAkUNaZCZ5wEL0Z7xtY/nm7oJ/XSXBehu5EO20n+3XUDHglvuDmM0g0DBul3h8eOccH qtO971hjfzCC3L2iFSe7tcwV5wLv6OV7bq/uLMXjcqh5GeMYpM5OaW+cQ+WsAL0iNo53 F7uUnxF5fEk/PxOEQLpKrkii29UeMNqRYvMPE1Qyj42pbFFISjPVd6JEGZTxz4IVeK48 JXgOWASDjAxK9nep1aOvc+Yws1YXZSgDscZCW4jkHf5UxYw7w0DhYwaoifsWgz5s3SFB yU4w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=yREQL2uq; 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 um2si10788961ejb.64.2019.11.11.21.36.35; Mon, 11 Nov 2019 21:36:59 -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; dkim=pass header.i=@kernel.org header.s=default header.b=yREQL2uq; 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 S1726982AbfKLFc3 (ORCPT + 99 others); Tue, 12 Nov 2019 00:32:29 -0500 Received: from mail.kernel.org ([198.145.29.99]:60190 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725283AbfKLFc1 (ORCPT ); Tue, 12 Nov 2019 00:32:27 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B250821925; Tue, 12 Nov 2019 05:32:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1573536745; bh=lFiSF9q/Q/xxTvm6x//n2RwUraJ7FAvLWNteiLBYpBo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=yREQL2uqzE5jVpRoydpr3hHQWGThJUiK0JZ0VB764etqg9/02wKHrPZaJLYX+Pm6p AlK+yReNr0+3NWnc7NhV6aD73Jq2EurGGv0EiauCElNiJrq0zpTMJcddNjCDcS3bgJ F67bQ43FkabEisW2tm4HeqUGGioJo2M7CuyHC+jo= Date: Tue, 12 Nov 2019 06:23:47 +0100 From: Greg Kroah-Hartman To: Andreas =?iso-8859-1?Q?F=E4rber?= 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 Subject: Re: [PATCH] base: soc: Export soc_device_to_device() helper Message-ID: <20191112052347.GA1197504@kroah.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas F?rber wrote: > 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); First off, the driver should not be spitting out noise for when all goes well like this :) Anyway, just use the pdev pointer here, not the soc dev as that is NOT a pointer you have control over (as is evident by the fact that you need this call to try to get it.) I'll look at your other instances later when I've had my coffee... thanks, greg k-h