Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp4373650imm; Mon, 18 Jun 2018 13:54:51 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLuMG8oMNqL/rxYGGcBBYfK/jomH4NOdzDxk/NHcH3+DxJRxErCoB3gPl/Gh5oWBl7tGdyd X-Received: by 2002:a63:107:: with SMTP id 7-v6mr12193018pgb.289.1529355291611; Mon, 18 Jun 2018 13:54:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529355291; cv=none; d=google.com; s=arc-20160816; b=YI/Xfei8FWblTG+pletYG+au8ry7DLhcSihSrXua5bWxwQc70EvXIaVYumRUD9hV8F e8VnjQs5JMUfwkvqKqyMlr+/uxVKs2G/YORN+GUcxffP7fD1tYPHFecf9ElrT5qeM9eP eqLRhHG+KnjYIVNYBL0V0SLmHigCeqXNX6XXTGsZN11kGu8YGFH0+w/96Eoo+1JURA8e wnUm4x28mzO9j92PF4xorDv5kcAOWhZJ5EyPgjbEoXabrDUM68M+YE4sV6lfBRvSD2Dz FFpyjQ5VB9+fO7FcbSbhXEkNg49WnvE37RLM3Lin/w3GqNeT4mv0JAZHCosu/yhgjCeN 0IDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=Y9pM/Wyw8WtAfW454AQnDmn1yh0JtPQgpp948bnw8s0=; b=0HsfIlzLZwHrc0I2ZUL5tpCL99rOUWDpY7Tfwm7QsjPD+/kaa0sMl+i6rIm9tChlSu Tv3gHarUz0piiO3nUu5pAG1ym92/1TsIlKCt37z7ASk1i/oAzczSH+GOM9KtUd8g16TE UAMCzWQVN6iNqUEUVrq4X0Ycvz+nou0LG+UOVatAtmrsjYGQrKI3xPLKpmm+FnxmmlzH KDrWHWCaFDH93Io+9Y3soRfqL/s5n+6fcm2adWV03wByGh8+OzSWvYOz6F4QFOsDFkzk Vps3N02U/7jQ6d3Dz1kRZ/NPLmJ2s+xKp4wBeZ1su0wK0e8j/SL2YgF8GC6XO4zB/MZY ENJw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=cV+SAWwT; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u13-v6si17606002plm.99.2018.06.18.13.54.37; Mon, 18 Jun 2018 13:54:51 -0700 (PDT) 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=cV+SAWwT; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936900AbeFRUxn (ORCPT + 99 others); Mon, 18 Jun 2018 16:53:43 -0400 Received: from mail.kernel.org ([198.145.29.99]:56034 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935090AbeFRUxl (ORCPT ); Mon, 18 Jun 2018 16:53:41 -0400 Received: from mail-io0-f180.google.com (mail-io0-f180.google.com [209.85.223.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C8BA820863; Mon, 18 Jun 2018 20:53:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1529355220; bh=Y9pM/Wyw8WtAfW454AQnDmn1yh0JtPQgpp948bnw8s0=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=cV+SAWwTtGL8huvBeHdTCjHmyjpgeRhnMNwe3wazO1boia+wsTLKddgZ78LCyGilf BWd/qkf5sU4PwjFkluCKEGpavZXzsZ0dc59jZ18q172M3x4pswdsLR6zooGyLJkUFv 6xsSvW1j2sQi5htbvuZiVvCnwlLlgjR2KLrjF8K0= Received: by mail-io0-f180.google.com with SMTP id u4-v6so18123478iof.2; Mon, 18 Jun 2018 13:53:40 -0700 (PDT) X-Gm-Message-State: APt69E1Q7E/zaI0dgIEMi9CH5YKkg45HQZJM+sYkFCqjOLML3p5M9YFM ZzWUX3WW/LUc5jnxeXI6iELil8F+BTnOOxBF0A== X-Received: by 2002:a5e:9407:: with SMTP id q7-v6mr11805031ioj.268.1529355220201; Mon, 18 Jun 2018 13:53:40 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:6403:0:0:0:0:0 with HTTP; Mon, 18 Jun 2018 13:53:19 -0700 (PDT) In-Reply-To: <20180618200848.GA32482@centauri.lan> References: <20180614111138.8923-1-niklas.cassel@linaro.org> <20180614111138.8923-6-niklas.cassel@linaro.org> <20180618110642.GA6928@sirena.org.uk> <20180618123932.GA28476@centauri.lan> <20180618200848.GA32482@centauri.lan> From: Rob Herring Date: Mon, 18 Jun 2018 14:53:19 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 5/7] ASoC: qdsp6: Add depends on OF To: Niklas Cassel , Srinivas Kandagatla Cc: Mark Brown , Frank Rowand , Andy Gross , Patrick Lai , Banajit Goswami , Liam Girdwood , Jaroslav Kysela , Takashi Iwai , linux-arm-msm , Linux-ALSA , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 18, 2018 at 2:08 PM, Niklas Cassel wrote: > On Mon, Jun 18, 2018 at 08:48:32AM -0600, Rob Herring wrote: >> On Mon, Jun 18, 2018 at 6:39 AM, Niklas Cassel wrote: >> > On Mon, Jun 18, 2018 at 12:06:42PM +0100, Mark Brown wrote: >> >> On Thu, Jun 14, 2018 at 01:11:36PM +0200, Niklas Cassel wrote: >> >> > of_platform_device_destroy is only defined when building >> >> > with CONFIG_OF=y. Add a depends on OF. >> >> >> >> Is it sensible that of_platform_device_destroy() is only defined when >> >> building with CONFIG_OF=y? >> > >> > I'm redirecting that question to the device tree maintainers. >> > >> > There are a few of_* functions in include/linux/of_platform.h >> > that are only defined when CONFIG_OF=y: >> > >> > of_platform_device_create() >> > of_platform_device_destroy() >> > of_platform_bus_probe() >> > of_device_alloc() >> > >> > Rob, Frank, do you want me to create static inline dummy versions of these? >> >> No, because generally you should not be using these functions >> directly. Yes, there are some users, but if you look at the tree, >> there are few or isolated (PowerPC) users. Using >> of_platform_populate/of_platform_depopulate is preferred. > > of_platform_device_destroy() is also used by sound/soc/qcom/qdsp6/* > which is why I suggested this patch: > https://marc.info/?l=alsa-devel&m=152932497413567 > that adds "depends on OF" for SND_SOC_QDSP6 in sound/soc/qcom/Kconfig. > > Or do you think that a better solution would be to modify > sound/soc/qcom/qdsp6/* so that it instead uses > of_platform_populate()/of_platform_depopulate()? Yes, that is preferred. However, that won't work here because the child nodes don't have compatible strings. Maybe we should add them as this all just went in. That would also allow DT based module autoloading to work (which I don't think would currently). Really, as is, of_platform_device_create isn't needed here and you could just use platform_device_register_simple instead. The child driver would have to get the DT node pointer from the parent device instead. But if you want to add empty functions for just of_platform_device_{create,destroy}, I guess that is fine. Rob