From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 31703C77B75 for ; Fri, 21 Apr 2023 09:49:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Content-ID:In-Reply-To: References:Message-ID:Date:Subject:CC:To:From:Reply-To:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=oFtREC7EUjj9+1tLIw4IwHui3AFfbkKL3fWh2XRLN2E=; b=QdWhlAtFl0WF1d 7YR49memg3sT1JrkkOxpgglBCXPXjop5B7lLPlC6qgN0rwTSQZyT93oGBZtp0ocQHyYGlIZSZ2+An 4drLXT7MgcAg56ir48sK4M7gmo+hNyHxfVvDEfoLoRvxsth1jTWBo0sZFmiY3lzg7AEBLKkHJTGW1 OSR9QtNQxHbeROvOn/4CT3Cs4hMiIVq3JGxkv/HxNs73nyy428gtmLjI3lNb6XTABNJBPLn1nz87M WmXSCf5Z/w5+X798ZIc+sH3QVjFTkSiGfMnYGbS0Z4SjWaKLTrgLCr1b61jacd4r5hq/4ttB30T/z aFX2Lb+UDGbVfXX4KdpQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1ppnNn-00AMrh-1Z; Fri, 21 Apr 2023 09:48:47 +0000 Received: from mx0a-0039f301.pphosted.com ([148.163.133.242]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1ppnNk-00AMq1-0V for linux-arm-kernel@lists.infradead.org; Fri, 21 Apr 2023 09:48:46 +0000 Received: from pps.filterd (m0174678.ppops.net [127.0.0.1]) by mx0a-0039f301.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 33L5eYFv029819; Fri, 21 Apr 2023 09:48:37 GMT Received: from eur03-am7-obe.outbound.protection.outlook.com (mail-am7eur03lp2241.outbound.protection.outlook.com [104.47.51.241]) by mx0a-0039f301.pphosted.com (PPS) with ESMTPS id 3q372hk25f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Apr 2023 09:48:36 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ntn8QKuAPQ5Oui/7JpQneoWGcdMMeLKKpdI28ydQTzfrrxl33wkZssA77mgkJrjKVJCsP97aDNZpp+MRNtYkhCaNrvnrQGyuQvDmfpUxvnJWd6y3Wr1fFJDMEvjGtcjs1aOK0Ewjzqb5OtUy1RL6M+jPPd/NGvueRD7zM/4LODanJVaSKs5NwcdQNefyEbZhUbpkL4yluHVDF/SQt7Elkvy6mLs97g+sQAtUetO9NyfZFkedDnZLcIiulZImtE1MHua3F0j7rHxY/5O866aUFkCXCJ4jBoK4uurLzCg/ATHaJSRqAXKQBYIc/5Hexn7vm4Oxk/gtNo8NQAKcDMo+LQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hRUdWle3uZJKACLO507pfGesvAHYup8lLZXZ6FTCKMU=; b=kYgg7ClO3pVGGv8IVXedSXQVPbZI0eLR39WGQK/gVsm8MvoidvyVutwmpcpa4wwksA2hunrrXHRetwWRqBtlLKDYEKSfgnG6rMsAUO/9iNggsSDW5WHqkJftSU7RVTgVxs9NbxeaA6PjzYKh05mwvfYvgAqCUgE7wl8T0WYrV6gL0NDbeZ9VVD3l7OXEsFnH6Sd7Wo3ziNBjLA1YcB3rkQisEdk8m/OQfKXtCo91w7OFvZEgCAyxgvQ07ZvgZJZpjHIVPtlthhVvKhHJamjTmLIttb/XKUNz0KXnjGZDUdSiQzS2W5Vu//dfieW8uxzeYvpEl5z+b5XsPafzcx3Qcg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hRUdWle3uZJKACLO507pfGesvAHYup8lLZXZ6FTCKMU=; b=G8ANqfL5PSfCPOCxX7DRZWUQN4ynU1oKUyoC5trupGAd9+pGS8eNBbvjFr+rmWn6LOkKogH5Lm53ZI62wvcoY07ijx1duitnJtqsOY7+9KkuH3KCzlQZyfSzuMlcif5373PD/9fii6lBPNBWASu/mveYQL2Z62xoVXWiRp48rE5xjti5rjVmbyFJGom97yKKGsAiGSy5BMbbvdS7egbIqZz+looceB/zdfEPdNiXHIL+XP7z555gW8FBdMjaQgbDKSwkmWkGqlTI/gOJSzVBmOcrRHy8+44qkD1Tt+4pGXwTKk55DMfB0p0zdmrOiZcsffqXeAHuLSVwKSmvZO/CMA== Received: from PA4PR03MB7136.eurprd03.prod.outlook.com (2603:10a6:102:ea::23) by PAXPR03MB7634.eurprd03.prod.outlook.com (2603:10a6:102:1dc::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6298.50; Fri, 21 Apr 2023 09:48:33 +0000 Received: from PA4PR03MB7136.eurprd03.prod.outlook.com ([fe80::bcf5:cd14:fd35:1300]) by PA4PR03MB7136.eurprd03.prod.outlook.com ([fe80::bcf5:cd14:fd35:1300%9]) with mapi id 15.20.6298.045; Fri, 21 Apr 2023 09:48:33 +0000 From: Oleksii Moisieiev To: Cristian Marussi CC: Peng Fan , "sudeep.holla@arm.com" , Linus Walleij , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-gpio@vger.kernel.org" , "michal.simek@amd.com" , "vincent.guittot@linaro.org" , "souvik.chakravarty@arm.com" Subject: Re: [RFC v1 1/2] scmi: Introduce pinctrl SCMI protocol driver Thread-Topic: [RFC v1 1/2] scmi: Introduce pinctrl SCMI protocol driver Thread-Index: AQHZaTpLwL07BD9460y7/F64OnMs/q8oQvCAgAaar4CABqnaAIAADdAAgAAFIAA= Date: Fri, 21 Apr 2023 09:48:33 +0000 Message-ID: <3041c92c-385a-00cd-87cd-d8b906dcd84c@epam.com> References: <54119b2cb43e29f69c5858a5320d3a58f23fed21.1680793130.git.oleksii_moisieiev@epam.com> <6dc456ff-7fc6-3b73-3727-dd048e9a9629@oss.nxp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PA4PR03MB7136:EE_|PAXPR03MB7634:EE_ x-ms-office365-filtering-correlation-id: 78c85d16-f359-437a-4def-08db424d9242 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3NeBpX3ogho/gdCM1wq/UyMqbDfi9TNSiogSBi5a1CvHkFv6Uo4PpfnE5vK5O8IBH4GwYpDGhlish4ChKFgncG2ZSHvaycXaHTNdCEfbXJJ6ErhWflzvQlUE6AGcQLMDs4XqyALsQz23Id/4nnBs7NdiP5NjiLECEVQQc9HfezNIhFWWmPAe+w32UO5Uau5A1NlOzye+wVFcb6Egc+lBhh0wpJvfp3xvqJCoIBE1nJl8iTVMvYPrVGy9xCU5vIutHFypKTCtYCBgV3rjr29tkPv687l2/G0jQsZpililMiWIKmes+PhGHByzh6rhD8ysoeKhoicnnB8xs0CQ1268DRN9t4aUjTXZ9y3IlZuM5TBqvc+83oNmU9xL/Sg2lTyxDV9IuCsrPuI1RxZFVtocP+YPMLYfUaaBp83jGe8WKiLvNKDPT6vF6BClG1xGsTGOqz7omY0zr3apMmxr2W7XT7R5dB0gJwIyF9p/0noWSNptnkXLI/ld9kfBF3gqMT5Fw9eepNj2DD/9Kns+LASHD1AYsA41RUZlcdpAYxXECHgCynRFTvSakd/9Uui2jIKdWZa3K37b/2rM6p8imwUKQAjwixf2H32FEnRX/N0Nl052CrosQo/u6DJZpDgiq+PR7Iok7DQLRl8qdlIpiL92mA== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PA4PR03MB7136.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230028)(4636009)(346002)(39860400002)(376002)(396003)(366004)(136003)(451199021)(2616005)(83380400001)(36756003)(31686004)(186003)(966005)(6486002)(54906003)(478600001)(71200400001)(91956017)(66556008)(76116006)(66946007)(38100700002)(66476007)(66446008)(64756008)(8676002)(5660300002)(8936002)(122000001)(41300700001)(6916009)(4326008)(316002)(38070700005)(7416002)(6506007)(6512007)(53546011)(2906002)(26005)(31696002)(86362001)(45980500001);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?enNEa0MrbVBTUW02eDlwZE9BaU1QVTJ3ejNrRTFJbXZKMHZMaXZvRHVyWlh6?= =?utf-8?B?eXBvVkJTWTcrZHcxL3huUkdFcFkzeUFGYkpRWTd4VnZ1WEJjSHV5cmUwdVh0?= =?utf-8?B?U3c5a1c5aEZrWWhzOHZSK2FWU3htN3VOWWlINVNzaEV3VzROa21WbGUzTDdS?= =?utf-8?B?ZkhtNkMxQWo0YW9JTGJWdk9QMllzd2JNbFVTeVk5RGxmaEN5RXA3VnBvRGsx?= =?utf-8?B?bGtmZGJGb3RkbWQvajVmWm4xcnYvWXQ4TlNaSnppMEE5QVRWQ2xnTnppNXNK?= =?utf-8?B?SXBiOXdic2FUdmIyOU94WHM1RmNmMmNjcU16RkVyclNWV1NENnMyRHhCdGo5?= =?utf-8?B?Yk5KS2Z4V2xhU203NHZvemk0bEdYbGNEY3htejVINE52M0Fub1lnQlpMaVhz?= =?utf-8?B?RGhRcmdiVXpxRGdLa3VwWGYxTE1WQUVWZDZUc2Z6eEtIbUhsNXdKeXR5ZHZ2?= =?utf-8?B?MWJqczhLSmE1VzBlQmI2VUdTTnFDcXhQYmNmTjhiaWV2cGRpY3NtTW1peVlq?= =?utf-8?B?Q0hDdjk3dnVuWDhwRlBNaFA5bkkxRWRBRnhJQkVDVVJlMHIzRWZNSHVNeFEx?= =?utf-8?B?Z0NwNW5KSGlDWk05OWZ6RHhJRFBHdFpOcU9sSHFMR3E3RW5DTGJvbG1iMEZL?= =?utf-8?B?T2hjWE1qeTJvRGo1MmZ6TWNiRXJ3THIramRNVytZeUFrTlZQcnlTQkh1MU9K?= =?utf-8?B?d0s4c2FwVVBnSmMwVGo3MFFYbkZmTXFVaG9ORHFhMDc5SnhHbEJRN0owVlRQ?= =?utf-8?B?elI4NzNFN3Q5bVBmN3dlOEVBTHZIdFFsMEtJM2k1ck13YTBpQjhEaGRzVDZl?= =?utf-8?B?aGYvQnFaanlXK3NMditxQ0pDb0I0SFZ6Yzh5Y2Y4RGtIVUtGeXJJWlhRbnJy?= =?utf-8?B?RnJQTnV5N2ZqRFlDbWFEaEE4bjdBVVYrM1BDTzE3TnhaY2ZOcEtwQ2pEdHZD?= =?utf-8?B?Z1hKTEd0dGY4c1R4M2kyZW9tejBQeDBwbDkvYnZjYUFjMm9IQnpXUGljQ2pv?= =?utf-8?B?RndlYjZJUkFRUXRsbkJCZDRycGVzcTlKT3ZzU3NuTkRPM0ZMWm0rcUpzeG1l?= =?utf-8?B?aHNqdFVQaXRBZlltaFRqOWU0a2VBUjJOM3RsdVpuRmdpaDhBdWk4RG52VFNJ?= =?utf-8?B?VnFTYVpqYXB6S0NvakZNSDdqR2ptZWlyT1JiQzIzNFdQK2ZVS3lXNXFCT3Rr?= =?utf-8?B?azBhaG92bVc1a1k0REc0ZXQ5RWdpRjRqb3ZkZnZHZFpxdW90TWU4c1UxVEoy?= =?utf-8?B?dzNyM01WUjNxVWdYamZEanhIMGdtVDE1OWF0QWo5RG95Ri9yaDFUSEJQcEdv?= =?utf-8?B?Qm9MSFgvN002SlB2SlUzV3I3b2FTeFBsOVFuZ25FSTBxT1FyR0FWTUtDZzRI?= =?utf-8?B?dzh3RW5RVEZ2NE4xQ0ZySDlabzAxNngrRHdHZXoxbTJaUlh4VGZEd3k1VCtK?= =?utf-8?B?a2I2RzhaRnlKS0pHMFZDTjBUYXduNnlVZzhxVy9sSFdyMVU0SGRrZWJtOW02?= =?utf-8?B?T0RGYm9RbHNIdWFSRTM4clc0MC92K0pzQ2VsL1k5a0Vkd2xjMjNCVFRrTVJK?= =?utf-8?B?eW04Q2oxK2xrSGRkaUFRdUFKeEV3bGlhMVBWTWJMMGxyT0U5NEE3UUMwREI5?= =?utf-8?B?S2ZpOVJZa2hCT0U5MlROYlhQa0d3MURreTVUV3VFSTBta05oK0JiQXMwbzBx?= =?utf-8?B?SVM0VmNpdFY3dm1RdUZmOXIwamVwcXNxM090YTFmVkhHMy9NQjZybGFjMWgz?= =?utf-8?B?dmJFUVAzUlJucUpvaXhZaU5MUUo3Z0s0bWduQysyTnRHZUFibFl2SUNpRktZ?= =?utf-8?B?Y0x0L2pMcnJZeXc4OXRhYVNTeUV5VG8vcTNpOWxBYjZrNXJSdjFVbHJzRnlm?= =?utf-8?B?bEwzOFlhWFlNRXFmYUpkcFd2Z1Vwc1J6SnNaSU9OVlZ6Q3F1cUhELy9oY0Vi?= =?utf-8?B?MTVDVTVWZ0Ezb2F4VFlXUnU4eFRYS3JkcDZWUmhDSm5QeHNSbVgyTWtzTXN6?= =?utf-8?B?SzRnaGthRzl2NWRSNEVraFkxbEpiMDZuQ3gzKzE5Y3pTVnd6VUw5KzFxM2pZ?= =?utf-8?B?MDFDR1hqNkR2dVova0Z4TDRJNFhneTlvT2llMVJVSVlFT0RmV2hnMk9HQ28w?= =?utf-8?B?d3AyRXJCMEFLZUJUNU1hNnlTd0N1Y0JFd1c0UTNqRlpuUFU3Q0JyVGxmRnlQ?= =?utf-8?B?RWc9PQ==?= Content-ID: MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PA4PR03MB7136.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 78c85d16-f359-437a-4def-08db424d9242 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2023 09:48:33.6510 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: UbXGJf550/LeA9HxQylanTglRbdti4zcoBvRMsjhYopBANUKadT690STH89twwb7lLwvwdAe44vBwNWc5e4yQsyZmeIky4Gbj3z93xHqF9w= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR03MB7634 X-Proofpoint-GUID: Q_iSlBG6ZMWfZVJwvXppncn1pqCIstsK X-Proofpoint-ORIG-GUID: Q_iSlBG6ZMWfZVJwvXppncn1pqCIstsK X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-04-21_03,2023-04-20_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 priorityscore=1501 impostorscore=0 phishscore=0 adultscore=0 mlxlogscore=648 malwarescore=0 clxscore=1015 spamscore=0 lowpriorityscore=0 suspectscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000 definitions=main-2304210084 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230421_024844_418229_BE661B33 X-CRM114-Status: GOOD ( 34.33 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Cristian, On 21.04.23 12:30, Cristian Marussi wrote: > On Fri, Apr 21, 2023 at 08:40:47AM +0000, Oleksii Moisieiev wrote: >> Hi Peng Fan, >> >> On 17.04.23 05:55, Peng Fan wrote: >>> >>> On 4/13/2023 6:04 AM, Cristian Marussi wrote: >>>> On Fri, Apr 07, 2023 at 10:18:27AM +0000, Oleksii Moisieiev wrote: >>>>> Implementation of the SCMI client driver, which implements >>>>> PINCTRL_PROTOCOL. This protocol has ID 19 and is described >>>>> in the latest DEN0056 document. >>>> Hi, >>>> >>>>> This protocol is part of the feature that was designed to >>>>> separate the pinctrl subsystem from the SCP firmware. >>>>> The idea is to separate communication of the pin control >>>>> subsystem with the hardware to SCP firmware >>>>> (or a similar system, such as ATF), which provides an interface >>>>> to give the OS ability to control the hardware through SCMI protocol. >>>>> This is a generic driver that implements SCMI protocol, >>>>> independent of the platform type. >>>>> >>>>> DEN0056 document: >>>>> https://urldefense.com/v3/__https://developer.arm.com/documentation/den0056/latest__;!!GF_29dbcQIUBPA!y2hR3PEGGxiPjVeXBcgGyV03DPDhzgUKR0uHvsTpiafKgBar8Egc6oOOs-IkFIquhSf-qBzltqEMyzRZHq8eC4g$ >>>>> [developer[.]arm[.]com] >>>>> >>>> No need to specify all of this in the commit message, just a note that >>>> you are adding a new SCMIv3.2 Pincontrol protocol, highlighting anything >>>> that has been left out in this patch (if any) will be enough. >>> Is it possible to extend the spec to support multilple uint32_t for PIN >>> CONFIG SET? >>> >>> With only one uint32_t could not satisfy i.MX requirement. >>> >>> Thanks, >>> Peng. >>> >> IIUC you are expecting to have an ability to set some kind of array of >> uint32_t config values to some specific ConfigType? >> >> I'm not sure if it's supported by pintctrl subsystem right now. I was >> unable to find an example in the existing device-tree pinctrl bindings. >> This makes me think that this kind of binding is OEM specific. >> >> Maybe it can be implemented by adding new IDs to OEM specific range >> (192-255) which is reserved for OEM specific units (See Table 23 of >> DEN0056E). >> > If I understood correctly the aim of Peng multi-valued request, I think > that even if Linux does not support using this kind of multiple valued > requests (as of now), if it is useful or required by some of the possibly > supported hardware, it should be described and allowed by the specification > and supported by the core SCMI protocol support at least, while the pinctrl > SCMI driver can ignore this and keep using a one-sized array protocol_ops > call internally (since it cannot do any different anyway as of now) > > IOW I dont think we should model too strictly the SCMI spec against only > what the Linux pinctrl subsystem support today, since Linux it is just > really only one of the possible SCMI agents and Linux implementation itself > can possibly change: it is better to model the spec on the HW requirements > or the possible usage patterns across all the possibly participating agents. > > As an example, for similar reasons, when the SCMI Voltage protocol was added > to the spec, at the very last minute, a change was made to the spec to allow > for negative voltages, even though the Linux regulator subsystem was not > and still is not supporting at all negative voltages as of now; so basically > the SCMI voltage protocol API now exposes a per-domain flag (negative_volts_allowed), > that allows any kind of voltage domain to be enumerated and handled at the SCMI > spec and core layer but that also allows any SCMI driver user, like the SCMI > Regulator driver, to decide on his own if negative voltages domains can be > supported: indeed the scmi-regulator driver just skips the initialization of > any voltage domain that is found to be describing negative voltages. > > Here is a bit different, it is more of an optimization in the call path > than an HW difference, but I would follow the same approach: with the > SCMI spec and the core SCMI stack (the protocol) that supports a multi-uint32 > call as a general case, if useful for some scenarios, and instead the SCMI > pinctrl driver that just ignores this possibility and keep using a single-value > array anyway....then, it will be up to the guys leveraging this multi-valued > call to come up with a way to use it on their systems, possibly maybe contributing > back to upstream any needed modification if general enough > (not sure about the details of how this multi-vals operation should be...we'll have > to discuss that about the spec all together I think.) > > In any case, I would definitely NOT relegate such possibility to vendor space, > since it is something generic and, especially being just (as it seems to me) an > optimization on the call path at the end, it will just lead to uneeded duplication > of functionalities in the vendor implementation of stuff that it is already > very slightly differently supported by the standard. > > ...just my opinion anyway, I'll happily let other guys in this thread discuss and > decide about this :P > > Thanks, > Cristian That sounds reasonable for me, although I can't imagine the use case of multi-valued config values (most likely this is the problem of my imagination). So I'd appreciate if Peng Fan could provide us with some examples. From my standpoint - ConfigTypes are meant to be simple value because they are mostly related to the electronic properties. But I agree that protocol should be platform-agnostic. It will be great if Peng Fan could provide some examples, so we can think about the best solution. Best regards, Oleksii _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel