From patchwork Wed Apr 23 14:05:08 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Grant Likely X-Patchwork-Id: 28895 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-ig0-f200.google.com (mail-ig0-f200.google.com [209.85.213.200]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id 87B1220534 for ; Wed, 23 Apr 2014 14:05:46 +0000 (UTC) Received: by mail-ig0-f200.google.com with SMTP id l13sf3444381iga.3 for ; Wed, 23 Apr 2014 07:05:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:delivered-to:from:subject:to:cc :in-reply-to:references:date:message-id:sender:precedence:list-id :x-original-sender:x-original-authentication-results:mailing-list :list-post:list-help:list-archive:list-unsubscribe; bh=E7qXhhLY/C0UDnJvdG1X7BqVfgaO73K11ZgFg0+PhFA=; b=RmMGGFxRUMkJhanLX5o7pbejTUhUp0WM1C4wFhtGO5dMCKQUQX4F5WF2nGl824A47U zqSU+lc/2eyd0bnroyzbT+XuEhjrgelfWVTyMvXI0n2GAgoSwalpGg1QwKmn5awSO181 0P5pN1wkXrqPzl9nx/sU8F8b4JjZJ2D38V2IKoM8idHFCfRu2bdau6XUTG7EUR8OM0sf TYxyiEjP6TJFqUpWzmKfAY0skQq3JU7JMGLL8lICWxzVtnoJ2KjloNXuHA+RpY9WDpoi i4+73HzirBfWhE4tTceOURgrotxUo08+6ot05VhC9PZrd7HROvufkc7FjYcf0Sr2y6Yo JQdQ== X-Gm-Message-State: ALoCoQnrkO5BkP9XJ2xydbp4d4MzA8hU8uYyZhtPHWhvc579a3G1xCZSMQ32/d/0lXT1pOHy2K+Q X-Received: by 10.182.128.166 with SMTP id np6mr10601748obb.16.1398261945975; Wed, 23 Apr 2014 07:05:45 -0700 (PDT) MIME-Version: 1.0 X-BeenThere: patchwork-forward@linaro.org Received: by 10.140.92.48 with SMTP id a45ls631284qge.72.gmail; Wed, 23 Apr 2014 07:05:45 -0700 (PDT) X-Received: by 10.58.23.6 with SMTP id i6mr45002077vef.12.1398261945804; Wed, 23 Apr 2014 07:05:45 -0700 (PDT) Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) by mx.google.com with ESMTPS id w19si181022vcf.167.2014.04.23.07.05.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Apr 2014 07:05:45 -0700 (PDT) Received-SPF: none (google.com: patch+caf_=patchwork-forward=linaro.org@linaro.org does not designate permitted sender hosts) client-ip=209.85.128.174; Received: by mail-ve0-f174.google.com with SMTP id oz11so1152277veb.19 for ; Wed, 23 Apr 2014 07:05:45 -0700 (PDT) X-Received: by 10.58.216.163 with SMTP id or3mr82110vec.80.1398261945707; Wed, 23 Apr 2014 07:05:45 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.220.221.72 with SMTP id ib8csp106582vcb; Wed, 23 Apr 2014 07:05:45 -0700 (PDT) X-Received: by 10.42.120.15 with SMTP id d15mr44724992icr.35.1398261944537; Wed, 23 Apr 2014 07:05:44 -0700 (PDT) Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id hi3si679424pac.369.2014.04.23.07.05.43; Wed, 23 Apr 2014 07:05:43 -0700 (PDT) Received-SPF: none (google.com: linux-kernel-owner@vger.kernel.org does not designate permitted sender hosts) client-ip=209.132.180.67; Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932078AbaDWOFa (ORCPT + 27 others); Wed, 23 Apr 2014 10:05:30 -0400 Received: from mail-ee0-f42.google.com ([74.125.83.42]:45571 "EHLO mail-ee0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753193AbaDWOFV (ORCPT ); Wed, 23 Apr 2014 10:05:21 -0400 Received: by mail-ee0-f42.google.com with SMTP id d17so831729eek.1 for ; Wed, 23 Apr 2014 07:05:20 -0700 (PDT) X-Received: by 10.14.184.66 with SMTP id r42mr17129229eem.84.1398261920301; Wed, 23 Apr 2014 07:05:20 -0700 (PDT) Received: from trevor.secretlab.ca (host31-50-108-136.range31-50.btcentralplus.com. [31.50.108.136]) by mx.google.com with ESMTPSA id cb5sm6586766eeb.18.2014.04.23.07.05.18 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Apr 2014 07:05:18 -0700 (PDT) Received: by trevor.secretlab.ca (Postfix, from userid 1000) id 2575AC408D2; Wed, 23 Apr 2014 16:05:08 +0200 (CEST) From: Grant Likely Subject: Re: [RFC] driver-core: Remove dummy 'platform_bus' To: Rob Herring Cc: "linux-kernel@vger.kernel.org" , Greg Kroah-Hartman , Kay Sievers In-Reply-To: References: <1353509071-8658-1-git-send-email-grant.likely@secretlab.ca> Date: Wed, 23 Apr 2014 15:05:08 +0100 Message-Id: <20140423140508.2575AC408D2@trevor.secretlab.ca> Sender: linux-kernel-owner@vger.kernel.org Precedence: list List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: grant.likely@linaro.org X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: patch+caf_=patchwork-forward=linaro.org@linaro.org does not designate permitted sender hosts) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , On Mon, 21 Apr 2014 16:05:29 -0500, Rob Herring wrote: > On Wed, Nov 21, 2012 at 8:44 AM, Grant Likely wrote: > > The "platform_bus" (note: not platform_bus_type) only exists as an empty > > directory to put platform devices into. However, it really doesn't make > > sense to segregate all the platform devices into a sub directory when > > typically they are memory mapped devices that doen't go through any > > particular bus. Particularly on embedded type platforms the platform_bus > > directory doesn't add anything. > > > > However, this will probably just end up breaking some userspace that > > depends on the /sys/devices/platform/ path to be present (no matter how > > much we protest that userspace must not depend on paths in sysfs). So > > while I'm seriously proposing this change, it may just be unacceptable > > ABI breakage > > An old thread, but was there ever a conclusion to this? We now have a > mixture of using platform_bus as the parent or not on various ARM > platforms. We kind of concluded in the opposite direction. Instead of removing the /sys/device/platform directory, the drivers/of code should be changed to use it. The following patch is sufficient to have the same effect. It doesn't unify the OF and non-OF paths of platform device addition, but it gets them closer. I've been nervous about applying it because I'm concerned about userspace breakage, but maybe it just needs to be merged and we can quirk out systems that break. --- -- 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/ diff --git a/drivers/of/platform.c b/drivers/of/platform.c index 404d1daebefa..40a85b85c932 100644 --- a/drivers/of/platform.c +++ b/drivers/of/platform.c @@ -175,7 +175,7 @@ struct platform_device *of_device_alloc(struct device_node *np, #if defined(CONFIG_MICROBLAZE) dev->dev.dma_mask = &dev->archdata.dma_mask; #endif - dev->dev.parent = parent; + dev->dev.parent = parent ? parent : &platform_bus; if (bus_id) dev_set_name(&dev->dev, "%s", bus_id);