Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp3629906ybx; Sat, 9 Nov 2019 00:53:27 -0800 (PST) X-Google-Smtp-Source: APXvYqx0NiK23Q9nAiiBo0FjGhpCcjw3A9gGL/fd6EQ44WO1gQ/xMiN2nlg2t0VL7eGmJBvceZDw X-Received: by 2002:a50:8859:: with SMTP id c25mr14980437edc.253.1573289607298; Sat, 09 Nov 2019 00:53:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573289607; cv=none; d=google.com; s=arc-20160816; b=i7dFAo78j8DvBRtOzwZi6V/fLTlojumpMF5NZKTLat7DVmMBTylffnWMihji4NNs8C i4qEKbPQsMZQTQ9syF73zcBj+XzklVg0IVCVlfu9KvDIargv4SIgDFjBZvfO0CkQ3ra+ oIdkDgg1mLjBmL6xPv+dDH8die5oGyKMz8GjHggoIlvunqmLa8fExDC7KLvp1+3k6V2o vMEqDhvoTNej0VQKoZ09H6qOwL05Mepjbs+j0ucHIGgcmup7l+RwTkP4mU9WwpSsgtUI /utl0uxQ8R+D7sd6bzCX3G/RyxSM4Kl5N1fxuDgQKLIcqt6YDQ5J+SXLfrifYtSUDSmk MJZg== 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-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=k/AGbZI8vymCulmVvf9RFwZ8iHdKShvnNRHh9gLbR0g=; b=nXBNfd4BcDeUxeTu+oDQ95DO7pu3Y4uBHFcA1vjOZhF/gGjWd5HqVO9ic1No+u7Zgn o9kwc873cMDK65CoJ+VGcygsFAJeeSVN+Lx3LCWb/WFoRdgDw2nAJTjUQHbYPDoIdEVC DA4wTE1BFZLO1966XpCVjVJTDzUMC25yaT51a/c7+eyD64KNcT4xh0/F573kKKNO5mcm uS9mYc6e1vV2SiGk1Arq7XijsuqCNEa9aAlMgklyiND072WcCohDo5iW0aDDchd4shKI jlucegVC/9KWtRWOP6Ejqgd8NQZIXWb/VGtBYe4U21MUKVNVIzEOMj9IWOeYWP8RcCnV WlQw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=eLmg39An; 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 f37si6097967ede.11.2019.11.09.00.52.51; Sat, 09 Nov 2019 00:53:27 -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=eLmg39An; 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 S1726327AbfKIIs1 (ORCPT + 99 others); Sat, 9 Nov 2019 03:48:27 -0500 Received: from mail.kernel.org ([198.145.29.99]:48166 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726136AbfKIIs1 (ORCPT ); Sat, 9 Nov 2019 03:48: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 E864B214E0; Sat, 9 Nov 2019 08:48:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1573289304; bh=hukStfid93ctuxGqEwFn19+/1igLGrz5ibX+4aGbB/0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=eLmg39AnE82EYdKpJ7Cvwfr0MacRpiG7/jJH8I+XjxMrSf+HAY+LM1L5Y5MDr4/3S /jwd5MN3FBl8GxMhGvmsrjfojBBgJggS3eozdPHTy5Le0IgFQ/YltJDatirFOWbudC zW0hcYe5sdhm/kazyHpRons/39aMJ6DMUXlotJjA= Date: Sat, 9 Nov 2019 09:48:20 +0100 From: Greg Kroah-Hartman To: Bjorn Andersson Cc: Georgi Djakov , Linux PM list , "linux-kernel@vger.kernel.org" , Viresh Kumar Subject: Re: [GIT PULL] interconnect changes for 5.5 Message-ID: <20191109084820.GC1289838@kroah.com> References: <5123bf54-5d62-fc5c-8838-17bc34487d83@linaro.org> <20191107142111.GB109902@kroah.com> <0cb5a6a6-399f-99e3-dc41-50114eea4025@linaro.org> <20191108103917.GB683302@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 Fri, Nov 08, 2019 at 05:36:46PM -0800, Bjorn Andersson wrote: > On Fri, Nov 8, 2019 at 2:39 AM Greg Kroah-Hartman > wrote: > > > > On Thu, Nov 07, 2019 at 05:42:13PM +0200, Georgi Djakov wrote: > > > Hi Greg, > > > > > > On 11/7/19 16:21, Greg Kroah-Hartman wrote: > > > > On Thu, Nov 07, 2019 at 02:46:53PM +0200, Georgi Djakov wrote: > > > >> Hi Greg, > > > >> > > > >> This is a pull request with interconnect patches for the 5.5 merge window. > > > >> All patches have been for a while in linux-next without reported issues. The > > > >> details are in the signed tag. Please consider pulling into char-misc-next. > > > > > > > > I don't know about > > > > 0003-interconnect-Disallow-interconnect-core-to-be-built-.patch here. > > > > Shouldn't you just fix up the dependancies of subsystems that rely on > > > > this? We are moving more and more to kernels that "just work" with > > > > everything as modules, even on arm64 systems. So forbiding the > > > > interconnect code from being able to be built as a module does not feel > > > > good to me at all. > > > > > > Thank you for commenting on this! The initial idea was to keep everything as > > > modular as possible. The reasons behind this change is that other core > > > frameworks like cpufreq (and possibly others) want to call the interconnect > > > APIs. Some of these frameworks are built-in only and it would be easier to > > > handle dependencies if interconnect core built-in too. Now each user that > > > can be built-in has to specify in Kconfig that it depends on INTERCONNECT || > > > !INTERCONNECT. > > > > That's fine, when those subsystems start to use those apis, that > > dependency needs to be added. Nothing new here, and you forcing it to > > either be "on or off" isn't going to change that. Let's do it correctly > > please. > > > > Please no! > > Making our frameworks tristate means that we can no longer rely on > include file stubs (as framework=m, client=y will fail), so every > single client must add the "depends on framework || framework=n" - in > contrast to nothing the framework itself is bool. What's wrong with a single "depends on framework"? If your code relies on this framework, you should depend on it, right? Include file stubs feels odd for a core functionality, if you can live without that functionality, then sure, don't depend on it and all should be just fine. thanks, greg k-h