Received: by 10.223.185.116 with SMTP id b49csp5845321wrg; Wed, 7 Mar 2018 20:01:34 -0800 (PST) X-Google-Smtp-Source: AG47ELvfaWY6aN4V0lmf60yBgjiUKe1+UX+eJjwiH+NVdW5u0D0X5Z7GQyq/k2seKW/CfDmKRYWP X-Received: by 10.99.163.80 with SMTP id v16mr19991101pgn.19.1520481693895; Wed, 07 Mar 2018 20:01:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520481693; cv=none; d=google.com; s=arc-20160816; b=Mc+rMIcMKo8YC/j2ygFI2ZJytJxBmks/AdpLKQlnG3pElrct46csGMCsszhq39o5mP E+fL4eDDEOFOCEGJuL4tl9MELbLRV5CpSvzVDx5Qi6npyRrvkqoSztVnFZk8mkpzFsQH Qzg8C56BOHVLqDPvmZholP20e7dvBHkhj038mUbPaMkW9+aClmbR9MGpJboMt02w9Fax 1yaydg0rqlqpX9Gnqg8FkCgw3U6ZbX4rjuRTWFbJbOPsl2F/MHsvcKrme0EUHdBuuHND kO5HFWwnZDxZCi9HNjAdJR+GntrMOi1k8WtNxIKgiKu7NbBPULCHGx2ar49/FMYKKoN2 +b8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :dlp-reaction:dlp-version:dlp-product:content-language :accept-language:in-reply-to:references:message-id:date:thread-index :thread-topic:subject:cc:to:from:arc-authentication-results; bh=6ne8PTjbT1n+J7efcD2W7YlZcrVAWO/hux2f9DL1knU=; b=nPE6nVmhZhHH0vw5B4YATRUX03jMiCW/V+oJUg8zixJwpdOUtLb5d3vfbick8CEuyb xEVc+J9G8vz8d3KV/rEMFH3p07iFAgyGR2loZbqP6ALAOe0kqTg/9cGr3NTPa2gCApV5 C14mNs7/RiBebIYI4/c5js+cuLKX8WwqUyRmdqstpU3wfFBUDi45PdwYcVavQX9jvSXq mpFh1+OY1W24Pz+UOBSeCUh8lxQ3QpXda7iBFMLfD4pqaVL6i6zVXEyDIeIt4WsYyVeT LuVAD6Ka/OVCHxoCtKCpyFXxECgoWJiRFcgib9wyaCvY6PrDt57STqVf+awl5Yrwl1cn d47w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a188si12425437pgc.183.2018.03.07.20.01.18; Wed, 07 Mar 2018 20:01:33 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754834AbeCHEA1 convert rfc822-to-8bit (ORCPT + 99 others); Wed, 7 Mar 2018 23:00:27 -0500 Received: from mga09.intel.com ([134.134.136.24]:6637 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750761AbeCHEAZ (ORCPT ); Wed, 7 Mar 2018 23:00:25 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2018 20:00:24 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,438,1515484800"; d="scan'208";a="209743429" Received: from orsmsx107.amr.corp.intel.com ([10.22.240.5]) by fmsmga005.fm.intel.com with ESMTP; 07 Mar 2018 20:00:23 -0800 Received: from orsmsx161.amr.corp.intel.com (10.22.240.84) by ORSMSX107.amr.corp.intel.com (10.22.240.5) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 7 Mar 2018 20:00:23 -0800 Received: from orsmsx114.amr.corp.intel.com ([169.254.8.126]) by ORSMSX161.amr.corp.intel.com ([169.254.4.92]) with mapi id 14.03.0319.002; Wed, 7 Mar 2018 20:00:23 -0800 From: "Prakhya, Sai Praneeth" To: Mark Rutland CC: "linux-efi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Lee@lakrids.cambridge.arm.com" , Chun-Yi , Borislav Petkov , "Luck, Tony" , Will Deacon , "Hansen, Dave" , Bhupesh Sharma , "Neri, Ricardo" , "Shankar, Ravi V" , Matt Fleming , "Zijlstra, Peter" , Ard Biesheuvel , "Williams, Dan J" Subject: RE: [PATCH V2 2/3] efi: Introduce efi_rts_workqueue and some infrastructure to invoke all efi_runtime_services() Thread-Topic: [PATCH V2 2/3] efi: Introduce efi_rts_workqueue and some infrastructure to invoke all efi_runtime_services() Thread-Index: AQHTtNngYFyf2e7B30yWdA6aWmV0oqPDlMWAgAIjjCA= Date: Thu, 8 Mar 2018 04:00:22 +0000 Message-ID: References: <1520292190-5027-1-git-send-email-sai.praneeth.prakhya@intel.com> <1520292190-5027-3-git-send-email-sai.praneeth.prakhya@intel.com> <20180306111339.xjrugce553f2egzh@lakrids.cambridge.arm.com> In-Reply-To: <20180306111339.xjrugce553f2egzh@lakrids.cambridge.arm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzEwMmY5OTItYzMzZi00MWVjLThhNTktZDMyZmU3M2I2MzNiIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjIuNS4xOCIsIlRydXN0ZWRMYWJlbEhhc2giOiIxWkQwdVBLd0VyYUNNWnhcL3F6SHQxUEYrVHlEaGY1Y3llZmtTZFVLNk1WWFV0a3RtWHc0Wm4zUHc2XC9ROHhqS24ifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org -0800, Sai Praneeth Prakhya wrote: > > @@ -329,6 +331,19 @@ static int __init efisubsys_init(void) > > return 0; > > > > /* > > + * Since we process only one efi_runtime_service() at a time, an > > + * ordered workqueue (which creates only one execution context) > > + * should suffice all our needs. > > + */ > > + efi_rts_wq = alloc_ordered_workqueue("efi_rts_workqueue", 0); > > + if (!efi_rts_wq) { > > + pr_err("Failed to create efi_rts_workqueue, EFI runtime services > " > > + "disabled.\n"); > > + clear_bit(EFI_RUNTIME_SERVICES, &efi.flags); > > + return 0; > > + } > > I'm a little worried that something might sample this flag between it being set in > an early_initcall (arm_enable_runtime_services), and cleared in a subsys_initcall > here. > > However, nothing seems to do that so far, so maybe that's ok... > Thanks for raising this. I will take a look at initcalls. > [...] > > > +/* efi_runtime_service() function identifiers */ enum { > > + GET_TIME, > > + SET_TIME, > > + GET_WAKEUP_TIME, > > + SET_WAKEUP_TIME, > > + GET_VARIABLE, > > + GET_NEXT_VARIABLE, > > + SET_VARIABLE, > > + SET_VARIABLE_NONBLOCKING, > > + QUERY_VARIABLE_INFO, > > + QUERY_VARIABLE_INFO_NONBLOCKING, > > + GET_NEXT_HIGH_MONO_COUNT, > > + RESET_SYSTEM, > > + UPDATE_CAPSULE, > > + QUERY_CAPSULE_CAPS, > > +}; > > Can we please give this enum a name.... Sure! Added in V3. > > [...] > > > +/* > > + * efi_runtime_work: Details of EFI Runtime Service work > > + * @func: EFI Runtime Service function identifier > > + * @arg<1-5>: EFI Runtime Service function arguments > > + * @status: Status of executing EFI Runtime Service > > + */ > > +struct efi_runtime_work { > > + u8 func; > > ... and use it here rather than an opaque u8? I realise that means placing the > enum in . > Actually, with Miguel comments, I am considering making this struct static and moving it to runtime-wrappers.c, since "struct efi_runtime_work" isn't really being used anywhere except runtime-wrappers.c. Please see in V3. > > + void *arg1; > > + void *arg2; > > + void *arg3; > > + void *arg4; > > + void *arg5; > > + efi_status_t status; > > + struct work_struct work; > > +}; > > Thanks, > Mark.