Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751880AbdHaIKr (ORCPT ); Thu, 31 Aug 2017 04:10:47 -0400 Received: from mail-lf0-f47.google.com ([209.85.215.47]:37678 "EHLO mail-lf0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751759AbdHaIKj (ORCPT ); Thu, 31 Aug 2017 04:10:39 -0400 Subject: Re: [PATCH v6 1/2] platform: Add driver for RAVE Supervisory Processor To: Pavel Machek , Andrey Smirnov Cc: 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> From: Nikita Yushchenko Message-ID: <35163bfd-d34f-40af-2494-340b6fe92b03@cogentembedded.com> Date: Thu, 31 Aug 2017 11:10:35 +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: <20170830203817.GA15462@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: 1282 Lines: 33 30.08.2017 23:38, Pavel Machek wrote: > Hi! > >>>> + * 9 -> Illegal Trap >>>> + * 10 -> Unknown >>>> + * 11 -> Crew Panel Requested >>> >>> Anyway... If you move management chip to .. I don't know, i2c, the >>> path would change. Also it would be different path on N900. Userland >>> should not have to deal with this. >>> >>> And... this should really be string, as the list will need to grow on >>> different hardware. >> >> I think we have a misunderstanding, with this part of the patch set I >> am not trying to propose a generic ABI that would be useful for any >> other driver but this one. Hence the lack of concern for different > > Yes, but sorry, that's no-go. Kernel should hide differences between > different machiens, and it should be rather easy in this case. There is an interest to have reset reason exported on other ZII hardware as well. 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?