Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932372Ab2JJPOj (ORCPT ); Wed, 10 Oct 2012 11:14:39 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:49455 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932264Ab2JJPOi (ORCPT ); Wed, 10 Oct 2012 11:14:38 -0400 MIME-Version: 1.0 In-Reply-To: <1349866585-24883-1-git-send-email-dp@opensource.wolfsonmicro.com> References: <1349866585-24883-1-git-send-email-dp@opensource.wolfsonmicro.com> Date: Wed, 10 Oct 2012 23:14:36 +0800 Message-ID: Subject: Re: [PATCH 0/2] Expose firmware paths via procfs From: Ming Lei To: Dimitris Papastamos Cc: linux-kernel@vger.kernel.org, Greg Kroah-Hartman 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: 1114 Lines: 31 On Wed, Oct 10, 2012 at 6:56 PM, Dimitris Papastamos wrote: > Hi all, sorry missed the relevant CCs before. This patch set > adds support for exposing the firmware paths via procfs. I've added > an entry named /proc/fw_path which is a whitespace separated list > of firmware paths. Looks the paths are hard-coded in udev and mdev, which don't export these paths to users , so I am wondering if users are interested in the information. But it is surely better to document the default search paths. Do you have some good use case about retrieving the info at runtime? > > Once I have some time I hope to also send out a patch that allows > the user to dynamically configure these paths. IMO, kernel parameter should be an appropriate way to configure the path, and the way of /proc or /sys may be a bit late. Thanks, -- Ming Lei -- 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/