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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 31CCDC433DB for ; Fri, 8 Jan 2021 12:48:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 004B223A03 for ; Fri, 8 Jan 2021 12:48:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726603AbhAHMse (ORCPT ); Fri, 8 Jan 2021 07:48:34 -0500 Received: from mga07.intel.com ([134.134.136.100]:25722 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725817AbhAHMsd (ORCPT ); Fri, 8 Jan 2021 07:48:33 -0500 IronPort-SDR: 7rXYtypWLyU+CMhOxs7E7l+6zLevPIPNkHFlLiBKlNld3PEZAQWP869Ri+IJoJdq1zkZywJNjx uhCsnE6OOxMw== X-IronPort-AV: E=McAfee;i="6000,8403,9857"; a="241663336" X-IronPort-AV: E=Sophos;i="5.79,330,1602572400"; d="scan'208";a="241663336" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jan 2021 04:46:46 -0800 IronPort-SDR: iUxLuetIJkCema+QppwQ5UbJ7vedM/uOpwgzaUKiClT9lYkFZbCteR7KzNsUjWZNR3ss3iTQpe KEdpsy2FTp3Q== X-IronPort-AV: E=Sophos;i="5.79,331,1602572400"; d="scan'208";a="463371415" Received: from lahna.fi.intel.com (HELO lahna) ([10.237.72.163]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jan 2021 04:46:45 -0800 Received: by lahna (sSMTP sendmail emulation); Fri, 08 Jan 2021 14:46:43 +0200 Date: Fri, 8 Jan 2021 14:46:43 +0200 From: Mika Westerberg To: Andy Shevchenko Cc: Andy Shevchenko , "open list:GPIO SUBSYSTEM" , Linus Walleij Subject: Re: [PATCH v1 4/4] pinctrl: intel: Convert capability list to features Message-ID: <20210108124643.GA968855@lahna.fi.intel.com> References: <20210107190200.41221-1-andriy.shevchenko@linux.intel.com> <20210107190200.41221-4-andriy.shevchenko@linux.intel.com> <20210108070722.GX968855@lahna.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Fri, Jan 08, 2021 at 02:31:23PM +0200, Andy Shevchenko wrote: > On Fri, Jan 8, 2021 at 2:22 PM Andy Shevchenko > wrote: > > On Fri, Jan 8, 2021 at 9:09 AM Mika Westerberg > > wrote: > > > On Thu, Jan 07, 2021 at 09:02:00PM +0200, Andy Shevchenko wrote: > > ... > > > I don't see how it could be achieved (offsets can be unordered). If > > there is such an issue it will mean a silicon bug. > > Specification says clearly that one register is a must and its value > defines the behaviour. > > "The first Capability List register is located at offset 0x004... and > contains a pointer/address to the next Capability List register. The > first Capability List register is no different than others... except > for its “Capability Identification” field is always 0. The total > number of Capability List registers... is 1 at the minimum (to > determine if there is any capability)." This is not the first time something like this is done wrong at silicon level. IMHO it is always good idea to avoid possible infinite loops especially in the kernel space. > So I prefer to stick with my original variant. OK.