Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752792AbcD1PAA (ORCPT ); Thu, 28 Apr 2016 11:00:00 -0400 Received: from mout.kundenserver.de ([212.227.126.131]:56854 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752561AbcD1O76 (ORCPT ); Thu, 28 Apr 2016 10:59:58 -0400 From: Arnd Bergmann To: Mark Brown Cc: Sagar Dharia , gregkh@linuxfoundation.org, bp@suse.de, poeschel@lemonage.de, treding@nvidia.com, gong.chen@linux.intel.com, andreas.noever@gmail.com, alan@linux.intel.com, mathieu.poirier@linaro.org, daniel@ffwll.ch, jkosina@suse.cz, sharon.dvir1@mail.huji.ac.il, joe@perches.com, davem@davemloft.net, james.hogan@imgtec.com, michael.opdenacker@free-electrons.com, daniel.thompson@linaro.org, robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com, ijc+devicetree@hellion.org.uk, galak@codeaurora.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, kheitke@audience.com, mlocke@codeaurora.org, agross@codeaurora.org, sheetal.tigadoli@gmail.com, linux-arm-msm@vger.kernel.org Subject: Re: [PATCH V5 1/6] SLIMbus: Device management on SLIMbus Date: Thu, 28 Apr 2016 16:59:02 +0200 Message-ID: <5047442.UXEhPc2Isi@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20160428143801.GO3217@sirena.org.uk> References: <1461801489-16254-1-git-send-email-sdharia@codeaurora.org> <7478716.z4vdp0mVTA@wuerfel> <20160428143801.GO3217@sirena.org.uk> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:IxWMmpL7fNLPezHIIQaYC61RTkHtFTBCM46NDenQzWX9aneeAjB G272zZShgYS/k7jodC6Il1g0I09ki6VYKtEQv56pZvzY//CcuglNf/g5qWibib4vZ+lL8ef UAZyNsYkSDWOOS7LHwGaZfs1fY0/vcOQHJsNYcFI3GxK33nXalbyRjUmGjUynJm4uV2zNSc cittYCgZ+tB2wDkZ5x1aQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:L1z4+ZX+kvU=:G+vZxJMFY+N0KDLjQubfwq k/aHX6dzqJ0fM8VgNKEzUQrYDIRfC2ihFD8U40Zbh+ziNbRaFeX7ogzKhqm7evgc+m0gu4Ihg IVnuYv1/lniekqU6UchHjGIlv8xzOTY2oRJrDijBUXgmvpl7Z9BQXOp0Bgi2GFawCzF8l2Jyx ZFM0Wo33kAT/B9lR303QTXxT56EUR/cwfXqXP+bxoDTAi/zP5mK7zePd8P0xhg9oiRuFoPe1m e3PPRNL22mtv3Lib4rJ4ERcJDKgcZFuUbFFunOsx8Ku3dXoQ42OUBB3O3dlsgpaLbRaOL9Gn8 IKtorhKxdctxiPjyBawTh9SgK4iEp3xgqqtFmPnXY10gnKC4EuEJSbDzdVTa/flfUiS7t0azk vWt10YS/n+HQ4OZUlb2s29xS9AV5/LRHaxpG7pS08lT7lc9RM9WvZmOmLUWgyBy3aVSv+6cz4 MIat+yqDXpHaYHeqKxRau6pigQWfO8/Mdx1413DixTx/985kiySV1x5iln6Rgk8ho+BTzyefC WgGU79INFph9xx4NEEg17fH6CFn4u1Ga9NzZPMDwphMw474kOlPnz8Q4iabOtSkbQWdGeb6lP ww08K0piC5F7A0S8389x0n9K4VTMYVxVgltnFDaOoE0k3XCXuEPm+nwjFN1WlMLVTIzRT1bIJ ZhWLusvroDZigZc0e+BCGeohYpOFz6QV1m+BGAtMekUvY5sMx0/7wucCuHBvLHDtWzQrhZ8qz sZ42XB1xQsM1mcW8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1538 Lines: 31 On Thursday 28 April 2016 15:38:01 Mark Brown wrote: > On Thu, Apr 28, 2016 at 02:33:41PM +0200, Arnd Bergmann wrote: > > On Thursday 28 April 2016 12:53:37 Mark Brown wrote: > > I don't foresee mobile phones with ACPI using this subsystem, but even > > if we got them, it would be a horrible idea to use hardcoded board > > specific tables in a platform file, and we should insist that whatever > > firmware is present has a way to describe the slimbus devices. > > Right, in this particular case I don't think it makes a huge difference > but what you were talking about was "ancient pre-DT times" rather than > something specific to this particular case. That's definitely a thing > that people keep thinking and it's good to push back on it since we do > have non-DT cases to worry about (some architectures, other firmwares, > things like PCI cards with other components on them and so on). Ok, I see what you mean. It turns out I made the exact same comment on the first review five years ago (phrased more nicely back then): http://thread.gmane.org/gmane.linux.documentation/3192/focus=3193 My comment this time was for the particular driver, but I'd still also maintain that a new subsystem in general should not start out by addressing the needs of traditional board files. I don't think we have merge new platform support on any architecture that would need this in the past years and stuff like spi_board_info and i2c_board_info is only really used on really old machines (but not going away any time soon either). Arnd