Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754585AbbEMLxE (ORCPT <rfc822;w@1wt.eu>);
	Wed, 13 May 2015 07:53:04 -0400
Received: from mail.linuxfoundation.org ([140.211.169.12]:45379 "EHLO
	mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751459AbbEMLxA (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 13 May 2015 07:53:00 -0400
Date: Wed, 13 May 2015 04:52:59 -0700
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Cc: Matt Porter <mporter@konsulko.com>, Koen Kooi <koen@dominion.thruhere.net>,
        Robert Nelson <robertcnelson@gmail.com>,
        Rob Herring <robherring2@gmail.com>,
        Grant Likely <grant.likely@secretlab.ca>,
        Jonathan Corbet <corbet@lwn.net>,
        Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
        Guenter Roeck <linux@roeck-us.net>,
        Geert Uytterhoeven <geert+renesas@glider.be>,
        =?iso-8859-1?Q?Beno=EEt?= Cousso <bcousson@baylibre.com>,
        linux-api@vger.kernel.org, linux-doc@vger.kernel.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
        Pantelis Antoniou <panto@antoniou-consulting.com>
Subject: Re: [PATCH 4/5] doc: ABI: bone_capemgr sysfs API
Message-ID: <20150513115259.GA1021@kroah.com>
References: <1431503985-31853-1-git-send-email-pantelis.antoniou@konsulko.com>
 <1431503985-31853-5-git-send-email-pantelis.antoniou@konsulko.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1431503985-31853-5-git-send-email-pantelis.antoniou@konsulko.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 4050
Lines: 109

On Wed, May 13, 2015 at 10:59:44AM +0300, Pantelis Antoniou wrote:
> Document the beaglebone's capemgr sysfs API
> 
> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
> ---
>  .../testing/sysfs-devices-platform-bone_capemgr    | 63 ++++++++++++++++++++++
>  1 file changed, 63 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-devices-platform-bone_capemgr
> 
> diff --git a/Documentation/ABI/testing/sysfs-devices-platform-bone_capemgr b/Documentation/ABI/testing/sysfs-devices-platform-bone_capemgr
> new file mode 100644
> index 0000000..e2df613
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-devices-platform-bone_capemgr
> @@ -0,0 +1,63 @@
> +What:		/sys/devices/platform/bone_capemgr/slots
> +Date:		May 2015
> +KernelVersion:	4.0

I don't think that version is correct :)

> +Contact:	Pantelis Antoniou <pantelis.antoniou@konsulko.com>
> +Description:
> +		READ:
> +		  Describe the state of all the slots of the beaglebone capemgr.
> +		  Each line of the output describes a slot:

sysfs files are "one value per file", so a sysfs file that displays
multiple lines like this is not allowed at all, sorry.

Please either make it a debugfs file (if this is only for debugging, or
split it out into individual files, one per slot (hint, one per slot is
probably best.)

> +		  The slot format is as following:
> +		  <slot-id>: [P-][F-][O-][l-][L-][D-] \
> +			  <overlay-id> <board-name>,<version>,
> +			  <manufacturer>,<part-number>
> +
> +		Where the flags are:
> +		P: Slot has been probed
> +		F: Slot has failed probing (i.e. no EEPROM detected)
> +		O: Slot has been overridden by the user
> +		l: Slot is current loading
> +		L: Slot has completed loading and is ready
> +		D: Slot has been disabled
> +
> +		Example:
> +		0: P---L-  -1 BeagleBone RS232 CAPE,00A1,Beagleboardtoys,BB-BONE-SERL-03
> +		1: PF----  -1
> +		2: PF----  -1
> +		3: PF----  -1
> +
> +		WRITE:
> +		  Writing a string of the form <part-number>[:version] issues a request to
> +		  load a firmware blob containing an overlay. The name of the firmware blob
> +		  is <part-number>-[version|00A0].dtbo. This act is defined as a slot override.
> +
> +		  Writing a negative slot id removes the slot if it was an overridden one, or
> +		  unloads a slot that was probed.
> +
> +What:		/sys/devices/platform/bone_capemgr/baseboard/<eeprom-field>
> +Date:		May 2015
> +KernelVersion:	4.0
> +Contact:	Pantelis Antoniou <pantelis.antoniou@konsulko.com>
> +Description:	Contains the probed base board EEPROM field; one of:
> +		board-name		- board-name as stored in cape EEPROM
> +		dc-supplied		- whether the cape draws or supplies DC
> +		eeprom-format-revision	- EEPROM format rev, only 00A0 supported
> +		header			- header; should be 'aa 55 33 ee'

If it's always this value, why have the file?

> +		manufacturer		- manufacturer string
> +		part-number		- part-number of the cape
> +		serial-number		- serial number of the cape
> +		version			- version of the cape, i.e. 00A0
> +		number-of-pins		- displayed but ignored
> +		pin-usage		- displayed but ignored
> +		sys-5v			- displayed but ignored
> +		vdd-3v3exp		- displayed but ignored
> +		vdd-5v			- displayed but ignored

Are these all individual different files?

> +What:		/sys/devices/platform/bone_capemgr/slot-<n>/<eeprom-field>

No blank line?

> +Date:		May 2015
> +KernelVersion:	4.0
> +Contact:	Pantelis Antoniou <pantelis.antoniou@konsulko.com>
> +Description:	Contains the probed cape's EEPROM field; the field is one of:
> +		board-name		- baseboard name i.e. A335BNLT
> +		header			- header; should be 'aa 55 33 ee'
> +		revision		- baseboard revision
> +		serial-number		- baseboard serial number
> +		config-option		- displayed but ignored

Same here, are these all individual files?

thanks,

greg k-h
--
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/