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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 44B1BC352A3 for ; Tue, 11 Feb 2020 15:48:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1AFF520656 for ; Tue, 11 Feb 2020 15:48:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730025AbgBKPsp (ORCPT ); Tue, 11 Feb 2020 10:48:45 -0500 Received: from mga07.intel.com ([134.134.136.100]:44082 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728288AbgBKPsp (ORCPT ); Tue, 11 Feb 2020 10:48:45 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Feb 2020 07:48:44 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,428,1574150400"; d="scan'208";a="431992911" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by fmsmga005.fm.intel.com with ESMTP; 11 Feb 2020 07:48:40 -0800 Received: from andy by smile with local (Exim 4.93) (envelope-from ) id 1j1XmD-000lsn-HK; Tue, 11 Feb 2020 17:48:41 +0200 Date: Tue, 11 Feb 2020 17:48:41 +0200 From: Andy Shevchenko To: Mika Westerberg Cc: Darren Hart , Lee Jones , Greg Kroah-Hartman , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H . Peter Anvin" , x86@kernel.org, Zha Qipeng , "David E . Box" , Guenter Roeck , Heikki Krogerus , Wim Van Sebroeck , platform-driver-x86@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 03/18] platform/x86: intel_scu_ipc: Introduce new SCU IPC API Message-ID: <20200211154841.GF10400@smile.fi.intel.com> References: <20200211132603.73509-1-mika.westerberg@linux.intel.com> <20200211132603.73509-4-mika.westerberg@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200211132603.73509-4-mika.westerberg@linux.intel.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 11, 2020 at 04:25:48PM +0300, Mika Westerberg wrote: > The current SCU IPC API has been operating on a single instance and > there has been no way to pin the providing module in place when the SCU > IPC is in use. > > This implements a new API that takes the SCU IPC instance as first > parameter (NULL means the single instance is being used). The SCU IPC > instance can be retrieved by calling new function > intel_scu_ipc_dev_get() that take care of pinning the providing module > in place as long as intel_scu_ipc_dev_put() is not called. > > The old API and constants that are still being used are left there to > support existing users that cannot be converted easily but they are put > to a separate header that is subject to be removed eventually. > Subsequent patches will convert most of the users over to the new API. I'm thinking now if it would be better to do this in two steps, i.e. split out legacy header first and then introduce new API? -- With Best Regards, Andy Shevchenko