Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp3845675imm; Tue, 11 Sep 2018 03:04:30 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZYQ2eclKg+G9bkQmGXZHEnqH8WZBDDOrrSQOGPlHDQH9Rt9BJvD1srRDcsqUGirPLTAsYL X-Received: by 2002:a62:6b49:: with SMTP id g70-v6mr28590957pfc.91.1536660270337; Tue, 11 Sep 2018 03:04:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536660270; cv=none; d=google.com; s=arc-20160816; b=TkF7KyPzpKY9Z0DGcE+fBbqMl39ys3n9JzD2L/3+S6HqA5cvWbb0auI37n6ckEsa3H hqMRpxy79XMTg+WHM6tFCCFfQpuCY9XeNHfzHC3/1hsH5afhUEevHKyIJKeQmwhsw/Ps fgY2UeX2845zV/3L+kK2I/dhgPT67Luu0IrW1KjMB+wTN8u3vzRNzDSnhNnZ9T7hKsMD nSTuUW3uVXwayNWsxqplh832n/aJi5HoM8+WRFlx0V+IF1TmUQH9tBupxGjBVhY2m8Mx I2nsoUbYBBnr1zCcQK94QoR6z+FrU8pEjBIr0Lf4Mb4nl3LPDAeito6Qq3yIZiJ2NNqH JwIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=ePrTnjK+yODxrYKG6e6I2+7ou/a+ykTrZkdZ42gRcoE=; b=SoLKl3lihDVNP48AeB8zNLHO7VPiwP2oFkBSOgHNAOh8bHzKDr0yg5279HIItNvq8H YFblkXNayxkTJyabMdw/LvPSJUUnJnzqfuiizCoOIfjUpYfOCKA2ydK6F0zE84UDtx55 hebfT71H815MfBGr3zlTSLnQjhKVAOBESom7N1UusT5rybQXIfgIteeRlWCurtqfn2gX xt3GdWFskAHEX4UfQrtiSNJQOfCVoPU/gkcK+hCEP3sZgw/faPelaWpvUpIFj6RfXlx1 9Kc+UNw9jnMgzFMPWBkUYaNSJZX7mdLuASDu4jv9pv3WH9cr66H4smXmUn1GVvAO1EmD AM2A== 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 k1-v6si19011973pld.424.2018.09.11.03.03.43; Tue, 11 Sep 2018 03:04:30 -0700 (PDT) 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 S1726840AbeIKPBA (ORCPT + 99 others); Tue, 11 Sep 2018 11:01:00 -0400 Received: from foss.arm.com ([217.140.101.70]:40928 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726612AbeIKPBA (ORCPT ); Tue, 11 Sep 2018 11:01:00 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9A97518A; Tue, 11 Sep 2018 03:02:25 -0700 (PDT) Received: from e107155-lin (e107155-lin.emea.arm.com [10.4.12.116]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 61AC83F557; Tue, 11 Sep 2018 03:02:22 -0700 (PDT) Date: Tue, 11 Sep 2018 11:02:13 +0100 From: Sudeep Holla To: Jolly Shah Cc: Olof Johansson , "ard.biesheuvel@linaro.org" , Ingo Molnar , Greg Kroah-Hartman , "matt@codeblueprint.co.uk" , "hkallweit1@gmail.com" , Kees Cook , Dmitry Torokhov , Michael Turquette , Stephen Boyd , Michal Simek , Rob Herring , Mark Rutland , linux-clk , Rajan Vaja , Linux ARM Mailing List , Linux Kernel Mailing List , Sudeep Holla , DTML Subject: Re: [PATCH v11 03/11] firmware: xilinx: Add zynqmp IOCTL API for device control Message-ID: <20180911100213.GA29599@e107155-lin> References: <1533318808-10781-1-git-send-email-jollys@xilinx.com> <1533318808-10781-4-git-send-email-jollys@xilinx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 10, 2018 at 07:17:45PM +0000, Jolly Shah wrote: > Hi All, > > Adding more clarification on top of what Michal said: > Here ioctl is not a system ioctl and just a eemi API like other interface > APIs. It cannot be called from userspace. I get that these are not system ioctl and you keep assuming that the issue raised here is related to that. *NO*, the main issue is the way this so called EEMI ioctl interface is exposing the users low level accessors without much abstraction. IMO, it defeats the idea of having EEMI interface altogether. There's abstraction but the level is not right. Anyways, this gets worse with read/write debugfs interface you want to add. > Only Linux drivers can use this > API for defined ioctl operations. This API is meant for any platform > specific operations which needs to be managed by firmware. Firmware will > always validate the request for action being performed. > Debugfs interface is just for debugging during development. We can remove > debugfs support for ioctl API if you suggest. Yes please. I did suggest to remove them long back. You did only for the clock module but retained it in the core EEMI ioctl. But if you remove the debugfs, do you have any users of these ioctl in the series ? I couldn't find one, but if that's the case, drop this patch. I see only valid users for clock APIs in this series. -- Regards, Sudeep