Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1531595imm; Sun, 23 Sep 2018 06:11:43 -0700 (PDT) X-Google-Smtp-Source: ACcGV617icRubjhmewpyW9uNs8Xl7eRdhzRm6XL96no5tAQj2ilwiZKO1/CyTkbst9c7wKwUPsk1 X-Received: by 2002:a63:f309:: with SMTP id l9-v6mr5692131pgh.369.1537708302935; Sun, 23 Sep 2018 06:11:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537708302; cv=none; d=google.com; s=arc-20160816; b=oGyxZT3DTSN4Ev8XcYWJ6IssYIbUvvCULREhr2poH0W7OR+JIUyDQ3ozp22hduuGtN tmO7vrK8OQCSDVPW3AFNz7TwsNI4WJjmTFq8z41Y42tZqSBYoNTjakoih+VsG0yfhLtS zyYKuqk/bUHsYzxgMP0p/9sXHFp8+B3+kuO64EjTQ79qSrGE2jhpfRwPiZ6CPNyB0Gxc 6flu63oYvxvhwqwNfZFrYtrQODqLntKmBDRBfpCb67/V5As4idYF25SOCuLzQGUsxTzy EFT6JLE3NvXCc9vTH4LsF95ApqtJZb+4Ebknu3nyxKjhXUkIcV5UwBNWws0Fbr3Vlgc9 v5iw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:references:in-reply-to:mime-version :dkim-signature; bh=IZamlx9F5Ps6sZz0zQO1d1QgBXUlrJZ+Le8kcZWXf6c=; b=bK+J0qwVsqFLla34zmwbOKxpThubrrMSrtAjgtgNaNGV3FdvnFpXyShi15jrK/P+Vl Oo5oYQgovPV9MZ1Lbp0br5Dyo8bL0u24nLQarXam2sRxD/jVFQtlCry0JgBnZfQIKXXm 7dfUTQLXWnUMiCOZ3Xl/ICZrG1zyRhXiJbqOdGDGV7pwCAFG/Yaf3EB7Th5nLT242Ley xzIPtxAJMEfxYW+oVl6zOTqKBdJgJtw3x7B2OseG6+GTaFzysfpcaiBcSXYGmQiaVqT3 9zQBMmtfQ5IS+Wg/SAFcmOE9rE9xhSgQgjQw4KHjrjdUYgd4ngb8jotcDmK9HIesTOsU zjYQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lixom-net.20150623.gappssmtp.com header.s=20150623 header.b=DylMqUVC; 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 t9-v6si34649514pfj.338.2018.09.23.06.11.27; Sun, 23 Sep 2018 06:11:42 -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; dkim=pass header.i=@lixom-net.20150623.gappssmtp.com header.s=20150623 header.b=DylMqUVC; 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 S1726225AbeIWTI3 (ORCPT + 99 others); Sun, 23 Sep 2018 15:08:29 -0400 Received: from mail-lj1-f194.google.com ([209.85.208.194]:42674 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726158AbeIWTI2 (ORCPT ); Sun, 23 Sep 2018 15:08:28 -0400 Received: by mail-lj1-f194.google.com with SMTP id m7-v6so909832ljc.9 for ; Sun, 23 Sep 2018 06:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lixom-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=IZamlx9F5Ps6sZz0zQO1d1QgBXUlrJZ+Le8kcZWXf6c=; b=DylMqUVCRR8YWe4is1/xokCuQegtoSk4GAiyF/E6r1xw8Noda708Xs2071vdbK12N4 6+rm3ZMu9SCqU57P5GLR97TXEmuZhvPRPut6O3Wt6YUFx5ZeTN2v2mn06e/KB9LC4XeS Wc5vfLOMDV1H2fFgFLUyObim7T641r89bcBdVZ1rM984Z1zLOmrQbN3IJbsU9QDhzIlg jZUWwr4CPNfatoL4q2X7Oo+mf615uJ2pNFAzAOSRi4LI10sEMMYZObvNI6oShzDtg7B2 cA4Qf2K0sPmg9QhUmIyrBd+hxzcZjJBfbc4+/hRcQ+8bd4DQCPm6vtcQe8fP4rpZNw5u E5Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=IZamlx9F5Ps6sZz0zQO1d1QgBXUlrJZ+Le8kcZWXf6c=; b=pieaM4UfI9cBsq27RN7zmuyNr8m/FCWGKRZ98xa4yPtamvWJ+9BZvb1jhrYIXyWFfA WXD9o8wo0R64IoEOhYttRbUb6IYN1I+15fN1hZHXEvW9+eoAUTAUAGAOz/NKxlxYU95Z VG4bCjqyZMPHaLBiaVDZ0OSwsEx29GLdzAhXG+wPsfwf/dzYffA7LwHdR2idTVMb9cMv 0ql8DgFXmCGfKr4k1QT7+JHFd/NiLs/t5blcFibRe7UawGHR+28SosTvwOi5TG2ggnHn J3myFZOqXhoN6bummUNQizHSRwRYKPeZjuO+4TfNAqfMMw98kO2kG8OSKzGuk+k0D7S5 EHPw== X-Gm-Message-State: ABuFfoh4iYNeM/G4v4fRqJoyB2vGkks9YYfUOurJcaRi7jS2lt27QIvG VMM+O+hwFgRAPDpnNX+ozHDWByOgZW1jOkPBO+980w== X-Received: by 2002:a2e:5cb:: with SMTP id 194-v6mr4785632ljf.130.1537708261006; Sun, 23 Sep 2018 06:11:01 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:eac3:0:0:0:0:0 with HTTP; Sun, 23 Sep 2018 06:10:59 -0700 (PDT) X-Originating-IP: [85.30.9.151] In-Reply-To: References: <1533318808-10781-1-git-send-email-jollys@xilinx.com> <1533318808-10781-4-git-send-email-jollys@xilinx.com> From: Olof Johansson Date: Sun, 23 Sep 2018 14:10:59 +0100 Message-ID: Subject: Re: [PATCH v11 03/11] firmware: xilinx: Add zynqmp IOCTL API for device control To: Jolly Shah Cc: Sudeep Holla , "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 , DTML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Apologies for the slow responses here, I meant to follow up on this sooner. On Tue, Sep 11, 2018 at 8:20 PM, Jolly Shah wrote: > Hi Sudeep and Olof, > > Clock driver from same patch set uses ioctl API along with other clock ee= mi APIs. As clock patches' final review is pending by Stephen, Michal only = created pull request for rest of the patches and that doesn't require ioctl= api. I will remove it and submit new patch set. > > For future patches which requires ioctl api, would like to understand you= r suggestion so I can make required changes. For zynqmp, EEMI interface all= ows clock, reset, power etc management through firmware but apart from thos= e there are some operations which needs secure access through firmware. Exa= mples are accessing some storage registers for inter agent communication, c= onfiguring another agent(RPU) mode, setting PLL parameters, boot device con= figuration etc. Those operations are covered as ioctls as they are very pla= tform specific. Do you suggest to handle them with individual EEMI APIs ins= tead of ioctl API? I'm personally less worried about whether the calls are through an ioctl API or an EEMI one, but if it is through ioctl, I'd prefer if it wasn't wide-open pass-through. I.e. that the ioctls you actually use are documented, and only those who are whitelisted are passed through (and not in general exported to userspace). Does that make sense? -Olof