From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTP id C218C96D for ; Mon, 5 May 2014 16:52:25 +0000 (UTC) Received: from mail.free-electrons.com (top.free-electrons.com [176.31.233.9]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 284C71FD46 for ; Mon, 5 May 2014 16:52:25 +0000 (UTC) Date: Mon, 5 May 2014 18:41:51 +0200 From: Thomas Petazzoni To: Jason Cooper Message-ID: <20140505184151.67a53dcc@skate> In-Reply-To: <20140505160237.GP28159@titan.lakedaemon.net> References: <20140504111436.GC15180@arm.com> <20140504171807.GA4418@quad.lixom.net> <1753987.hbb65qFWcl@vostro.rjw.lan> <1399279435.20388.36.camel@pasglop> <20140505160237.GP28159@titan.lakedaemon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "dvhart@dvhart.com" , Benjamin Herrenschmidt , ksummit-discuss@lists.linuxfoundation.org, Greg Kroah-Hartman , "Rafael J. Wysocki" , Sebastian Hesselbarth , Ezequiel Garcia Subject: Re: [Ksummit-discuss] [TECH TOPIC] Driver model/resources, ACPI, DT, etc (sigh) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Dear Jason Cooper, On Mon, 5 May 2014 12:02:37 -0400, Jason Cooper wrote: > > On the flip side, DT entirely lacks any sort of infrastructure for > > quirks other than match table data, and it handles various quirks > > inline mostly. It's not so much of a problem now as much of PPC is > > pretty stable and ARM is still a newcomer to DT, but I worry that we > > have an impending problem as ARM DTs start to mature. So what is the > > direction we want to go with quirks which can't be self-contained > > within drivers? > > regrettably, soc code. We (mvebu) have the good fortune to be > integrating mainline support for brand new SoCs from Marvell, as they > ship. Unfortunately, this means that the free-electron's guys > (contracted by Marvell to mainline the code) are having to work with > pre-release SoCs (Z1 stepping). On the other hand, Rob was asking about "quirks which can't be self-contained within drivers". And the two quirks below: > static void __init mvebu_dt_init(void) > { > if (of_machine_is_compatible("plathome,openblocks-ax3-4")) > i2c_quirk(); > if (of_machine_is_compatible("marvell,a375-db")) > thermal_quirk(); could perfectly be fine be self-contained into the respective device drivers. Actually, for the I2C quirk, it was even the original implementation that my colleague Gregory Clement proposed. But this approach was rejected, and we were asked to replace that by the current approach: a quirk in the mach-mvebu SoC code that changes the compatible string. I continue to have the feeling that the strategy we have been asked to use is going against the principle of having less stuff in mach- directories. Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com