All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olof Johansson <olof@lixom.net>
To: Jolly Shah <JOLLYS@xilinx.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	"ard.biesheuvel@linaro.org" <ard.biesheuvel@linaro.org>,
	Ingo Molnar <mingo@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"matt@codeblueprint.co.uk" <matt@codeblueprint.co.uk>,
	"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
	Kees Cook <keescook@chromium.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@codeaurora.org>,
	Michal Simek <michals@xilinx.com>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	linux-clk <linux-clk@vger.kernel.org>,
	Rajan Vaja <RAJANV@xilinx.com>,
	Linux ARM Mailing List <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	DTML <devicetree@vger.kernel.org>
Subject: Re: [PATCH v11 03/11] firmware: xilinx: Add zynqmp IOCTL API for device control
Date: Sun, 23 Sep 2018 14:10:59 +0100	[thread overview]
Message-ID: <CAOesGMgqjGEXzRPXFxUcSyTof_wgjErPhZ7wokdGEDY9SnCvdw@mail.gmail.com> (raw)
In-Reply-To: <CY1PR02MB2138254CC5B1C2B2D41AB725B8040@CY1PR02MB2138.namprd02.prod.outlook.com>

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 <JOLLYS@xilinx.com> wrote:
> Hi Sudeep and Olof,
>
> Clock driver from same patch set uses ioctl API along with other clock eemi 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 your suggestion so I can make required changes. For zynqmp, EEMI interface allows clock, reset, power etc management through firmware but apart from those there are some operations which needs secure access through firmware. Examples are accessing some storage registers for inter agent communication, configuring another agent(RPU) mode, setting PLL parameters, boot device configuration etc. Those operations are covered as ioctls as they are very platform specific. Do you suggest to handle them with individual EEMI APIs instead 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

WARNING: multiple messages have this Message-ID (diff)
From: Olof Johansson <olof@lixom.net>
To: Jolly Shah <JOLLYS@xilinx.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	"ard.biesheuvel@linaro.org" <ard.biesheuvel@linaro.org>,
	Ingo Molnar <mingo@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"matt@codeblueprint.co.uk" <matt@codeblueprint.co.uk>,
	"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
	Kees Cook <keescook@chromium.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@codeaurora.org>,
	Michal Simek <michals@xilinx.com>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	linux-clk <linux-clk@vger.kernel.org>,
	Rajan Vaja <RAJANV@xilinx.com>,
	Linux ARM Mailing List <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	DTML <devicetree@vger.k>
Subject: Re: [PATCH v11 03/11] firmware: xilinx: Add zynqmp IOCTL API for device control
Date: Sun, 23 Sep 2018 14:10:59 +0100	[thread overview]
Message-ID: <CAOesGMgqjGEXzRPXFxUcSyTof_wgjErPhZ7wokdGEDY9SnCvdw@mail.gmail.com> (raw)
In-Reply-To: <CY1PR02MB2138254CC5B1C2B2D41AB725B8040@CY1PR02MB2138.namprd02.prod.outlook.com>

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 <JOLLYS@xilinx.com> wrote:
> Hi Sudeep and Olof,
>
> Clock driver from same patch set uses ioctl API along with other clock eemi 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 your suggestion so I can make required changes. For zynqmp, EEMI interface allows clock, reset, power etc management through firmware but apart from those there are some operations which needs secure access through firmware. Examples are accessing some storage registers for inter agent communication, configuring another agent(RPU) mode, setting PLL parameters, boot device configuration etc. Those operations are covered as ioctls as they are very platform specific. Do you suggest to handle them with individual EEMI APIs instead 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

WARNING: multiple messages have this Message-ID (diff)
From: Olof Johansson <olof@lixom.net>
To: Jolly Shah <JOLLYS@xilinx.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	"ard.biesheuvel@linaro.org" <ard.biesheuvel@linaro.org>,
	Ingo Molnar <mingo@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"matt@codeblueprint.co.uk" <matt@codeblueprint.co.uk>,
	"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
	Kees Cook <keescook@chromium.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@codeaurora.org>,
	Michal Simek <michals@xilinx.com>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	linux-clk <linux-clk@vger.kernel.org>,
	Rajan Vaja <RAJANV@xilinx.com>,
	Linux ARM Mailing List <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	DTML <devicetree@vger.kernel.org>
Subject: Re: [PATCH v11 03/11] firmware: xilinx: Add zynqmp IOCTL API for device control
Date: Sun, 23 Sep 2018 14:10:59 +0100	[thread overview]
Message-ID: <CAOesGMgqjGEXzRPXFxUcSyTof_wgjErPhZ7wokdGEDY9SnCvdw@mail.gmail.com> (raw)
In-Reply-To: <CY1PR02MB2138254CC5B1C2B2D41AB725B8040@CY1PR02MB2138.namprd02.prod.outlook.com>

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 <JOLLYS@xilinx.com> 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

WARNING: multiple messages have this Message-ID (diff)
From: olof@lixom.net (Olof Johansson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v11 03/11] firmware: xilinx: Add zynqmp IOCTL API for device control
Date: Sun, 23 Sep 2018 14:10:59 +0100	[thread overview]
Message-ID: <CAOesGMgqjGEXzRPXFxUcSyTof_wgjErPhZ7wokdGEDY9SnCvdw@mail.gmail.com> (raw)
In-Reply-To: <CY1PR02MB2138254CC5B1C2B2D41AB725B8040@CY1PR02MB2138.namprd02.prod.outlook.com>

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 <JOLLYS@xilinx.com> wrote:
> Hi Sudeep and Olof,
>
> Clock driver from same patch set uses ioctl API along with other clock eemi 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 your suggestion so I can make required changes. For zynqmp, EEMI interface allows clock, reset, power etc management through firmware but apart from those there are some operations which needs secure access through firmware. Examples are accessing some storage registers for inter agent communication, configuring another agent(RPU) mode, setting PLL parameters, boot device configuration etc. Those operations are covered as ioctls as they are very platform specific. Do you suggest to handle them with individual EEMI APIs instead 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

  reply	other threads:[~2018-09-23 13:11 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-03 17:53 [PATCH v11 00/11] drivers: Introduce firmware dnd clock river for ZynqMP core Jolly Shah
2018-08-03 17:53 ` Jolly Shah
2018-08-03 17:53 ` Jolly Shah
2018-08-03 17:53 ` [PATCH v11 01/11] dt-bindings: firmware: Add bindings for ZynqMP firmware Jolly Shah
2018-08-03 17:53   ` Jolly Shah
2018-08-03 17:53   ` Jolly Shah
2018-08-03 17:53 ` [PATCH v11 02/11] firmware: xilinx: Add Zynqmp firmware driver Jolly Shah
2018-08-03 17:53   ` Jolly Shah
2018-08-03 17:53   ` Jolly Shah
2018-08-03 17:53 ` [PATCH v11 03/11] firmware: xilinx: Add zynqmp IOCTL API for device control Jolly Shah
2018-08-03 17:53   ` Jolly Shah
2018-08-03 17:53   ` Jolly Shah
2018-09-09  1:18   ` Olof Johansson
2018-09-09  1:18     ` Olof Johansson
2018-09-09 19:20     ` Moritz Fischer
2018-09-09 19:20       ` Moritz Fischer
2018-09-10 12:35       ` Michal Simek
2018-09-10 12:35         ` Michal Simek
2018-09-10 12:35         ` Michal Simek
2018-09-10  8:43     ` Sudeep Holla
2018-09-10  8:43       ` Sudeep Holla
2018-09-10 12:34     ` Michal Simek
2018-09-10 12:34       ` Michal Simek
2018-09-10 12:34       ` Michal Simek
2018-09-10 19:17     ` Jolly Shah
2018-09-10 19:17       ` Jolly Shah
2018-09-10 19:17       ` Jolly Shah
2018-09-10 19:17       ` Jolly Shah
2018-09-11 10:02       ` Sudeep Holla
2018-09-11 10:02         ` Sudeep Holla
2018-09-11 10:02         ` Sudeep Holla
2018-09-11 15:03       ` Olof Johansson
2018-09-11 15:03         ` Olof Johansson
2018-09-11 15:03         ` Olof Johansson
2018-09-11 15:03         ` Olof Johansson
2018-09-11 19:20         ` Jolly Shah
2018-09-11 19:20           ` Jolly Shah
2018-09-11 19:20           ` Jolly Shah
2018-09-11 19:20           ` Jolly Shah
2018-09-23 13:10           ` Olof Johansson [this message]
2018-09-23 13:10             ` Olof Johansson
2018-09-23 13:10             ` Olof Johansson
2018-09-23 13:10             ` Olof Johansson
2018-09-24 18:26             ` Jolly Shah
2018-09-24 18:26               ` Jolly Shah
2018-09-24 18:26               ` Jolly Shah
2018-09-24 18:26               ` Jolly Shah
2018-08-03 17:53 ` [PATCH v11 04/11] firmware: xilinx: Add query data API Jolly Shah
2018-08-03 17:53   ` Jolly Shah
2018-08-03 17:53   ` Jolly Shah
2018-08-03 17:53 ` [PATCH v11 05/11] firmware: xilinx: Add clock APIs Jolly Shah
2018-08-03 17:53   ` Jolly Shah
2018-08-03 17:53   ` Jolly Shah
2018-08-03 17:53 ` [PATCH v11 06/11] firmware: xilinx: Add debugfs interface Jolly Shah
2018-08-03 17:53   ` Jolly Shah
2018-08-03 17:53   ` Jolly Shah
2018-08-03 17:53 ` [PATCH v11 07/11] firmware: xilinx: Add debugfs for IOCTL API Jolly Shah
2018-08-03 17:53   ` Jolly Shah
2018-08-03 17:53   ` Jolly Shah
2018-08-03 17:53 ` [PATCH v11 08/11] firmware: xilinx: Add debugfs for query data API Jolly Shah
2018-08-03 17:53   ` Jolly Shah
2018-08-03 17:53   ` Jolly Shah
2018-09-09  1:15   ` Olof Johansson
2018-09-09  1:15     ` Olof Johansson
2018-09-10 19:19     ` Jolly Shah
2018-09-10 19:19       ` Jolly Shah
2018-09-10 19:19       ` Jolly Shah
2018-09-10 19:19       ` Jolly Shah
2018-08-03 17:53 ` [PATCH v11 09/11] dt-bindings: clock: Add bindings for ZynqMP clock driver Jolly Shah
2018-08-03 17:53   ` Jolly Shah
2018-08-03 17:53   ` Jolly Shah
2018-08-03 17:53 ` [PATCH v11 10/11] drivers: clk: Add " Jolly Shah
2018-08-03 17:53   ` Jolly Shah
2018-08-03 17:53   ` Jolly Shah
2018-08-03 17:53 ` [PATCH v11 11/11] firmware: xilinx: Replace init call with probe method Jolly Shah
2018-08-03 17:53   ` Jolly Shah
2018-08-03 17:53   ` Jolly Shah
2018-08-24 22:04 ` [PATCH v11 00/11] drivers: Introduce firmware dnd clock river for ZynqMP core Jolly Shah
2018-08-24 22:04   ` Jolly Shah
2018-08-24 22:04   ` Jolly Shah
2018-08-24 22:04   ` Jolly Shah

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAOesGMgqjGEXzRPXFxUcSyTof_wgjErPhZ7wokdGEDY9SnCvdw@mail.gmail.com \
    --to=olof@lixom.net \
    --cc=JOLLYS@xilinx.com \
    --cc=RAJANV@xilinx.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hkallweit1@gmail.com \
    --cc=keescook@chromium.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=matt@codeblueprint.co.uk \
    --cc=michals@xilinx.com \
    --cc=mingo@kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@codeaurora.org \
    --cc=sudeep.holla@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.