Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751276AbdHaJBJ (ORCPT ); Thu, 31 Aug 2017 05:01:09 -0400 Received: from mail-lf0-f44.google.com ([209.85.215.44]:33183 "EHLO mail-lf0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751080AbdHaJBG (ORCPT ); Thu, 31 Aug 2017 05:01:06 -0400 Subject: Re: [PATCH v6 1/2] platform: Add driver for RAVE Supervisory Processor To: Pavel Machek Cc: Andrey Smirnov , linux-kernel , Chris Healy , Lucas Stach , Lee Jones , Greg Kroah-Hartman , Jeff White References: <20170828163131.24815-1-andrew.smirnov@gmail.com> <20170828163131.24815-2-andrew.smirnov@gmail.com> <20170830105515.GA4926@amd> <20170830203817.GA15462@amd> <35163bfd-d34f-40af-2494-340b6fe92b03@cogentembedded.com> <20170831081820.GB9597@amd> From: Nikita Yushchenko Message-ID: <4eca3066-8194-6fae-fec5-498b94347a65@cogentembedded.com> Date: Thu, 31 Aug 2017 12:01:01 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170831081820.GB9597@amd> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1522 Lines: 37 >> I think that trying to make this generic is purely synthetic. This >> information is board-specific per it's nature, it comes from what board >> is designed for, different boards have quite different sets of possible >> reset reasons. What is needed is - pass this board-specific information >> to board-specific user space. >> >> What's proper API for that, if not a sysfs attribute? > > Please go through the thread. > > Sysfs attribute is okay, but: > > 1) it should probably be a string > > 2) it should certainly be superset of all the reasons > > 3) it should be in generic place, say /sys/power/reset_reason > > 4) it should be documented what each state means What I'm concerned here is that a requirement appears for kernel driver to keep and maintain knowledge of what all that codes mean. For me, it looks like information locality breakage. Information in question is application-specific, it definitely changes from board to board and probably will change for particular board over time. It's desirable to keep this information application-private, and have kernel only passed it from hardware to application, unmodified and uninterpreted. Requiring kernel driver to interpret application-specific information only increases complexity (i.e. any changes will have to be maintained in two places - in driver and in application). So question is - is there any proper API to communicate application-private information from hardware through kernel to userspace without any in-kernel interpretation?