Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754505Ab3J3UCm (ORCPT ); Wed, 30 Oct 2013 16:02:42 -0400 Received: from mail-ob0-f170.google.com ([209.85.214.170]:44829 "EHLO mail-ob0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752343Ab3J3UCk (ORCPT ); Wed, 30 Oct 2013 16:02:40 -0400 MIME-Version: 1.0 In-Reply-To: <20131030082621.GA22787@ulmo.nvidia.com> References: <1383113571-13029-1-git-send-email-robherring2@gmail.com> <20131030082621.GA22787@ulmo.nvidia.com> Date: Wed, 30 Oct 2013 15:02:40 -0500 Message-ID: Subject: Re: [RFC PATCH 0/2] DT match helpers for initcalls and platform devices From: Rob Herring To: Thierry Reding Cc: "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , Grant Likely , Greg Kroah-Hartman , Rob Herring Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2020 Lines: 42 On Wed, Oct 30, 2013 at 3:26 AM, Thierry Reding wrote: > On Wed, Oct 30, 2013 at 01:12:49AM -0500, Rob Herring wrote: >> From: Rob Herring >> >> This series adds a couple of boilerplate helpers to match with DT for >> initcalls and platform device creation and probe. The goal here is to >> remove more platform code out of arch/arm and eventually the machine >> descriptors. > > I fear that this is a step backwards because it makes it easier for > people to do the wrong thing. We've been doing the same with interrupt > controllers and clocks. With those there's at least the argument that > they need to be available really early and therefore cannot use the > regular driver model. But for everything else, shouldn't we enforce > proper drivers to be written? You think both are a step backwards or just the initcall one? For initcalls, there are things which are not drivers, but just one time init. The example on highbank is highbank_pm_init. In some cases like cpuidle, they have been converted to platform drivers, but then we have platform code to create devices if we are on the relevant platform. There is not really a real device node that exists for some of these drivers and we need to create the device rather than the device getting created by scanning the buses in the DT. I think this is less error prone because we've had cases of unconditional initcalls which break multi-platform kernels. > Perhaps if you can point me to some examples I could get more context > why and where this would be useful. I'll push out a WIP branch later which has the above examples and removes the machine_desc struct for highbank. This all is more for arm64 which doesn't have or want to have a machine_desc. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/