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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham 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 EDA4FC04ABB for ; Tue, 11 Sep 2018 10:02:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AA8AE20866 for ; Tue, 11 Sep 2018 10:02:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AA8AE20866 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726876AbeIKPBA (ORCPT ); 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sudeep Holla Subject: Re: [PATCH v11 03/11] firmware: xilinx: Add zynqmp IOCTL API for device control Date: Tue, 11 Sep 2018 11:02:13 +0100 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 Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org 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 List-Id: devicetree@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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: sudeep.holla@arm.com (Sudeep Holla) Date: Tue, 11 Sep 2018 11:02:13 +0100 Subject: [PATCH v11 03/11] firmware: xilinx: Add zynqmp IOCTL API for device control In-Reply-To: References: <1533318808-10781-1-git-send-email-jollys@xilinx.com> <1533318808-10781-4-git-send-email-jollys@xilinx.com> Message-ID: <20180911100213.GA29599@e107155-lin> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.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