From: Stephen Boyd <swboyd@chromium.org> To: schowdhu@codeaurora.org Cc: Andy Gross <agross@kernel.org>, Bjorn Andersson <bjorn.andersson@linaro.org>, Rob Herring <robh+dt@kernel.org>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>, Sibi Sankar <sibis@codeaurora.org>, Rajendra Nayak <rnayak@codeaurora.org>, vkoul@kernel.org Subject: Re: [PATCH V2 3/5] DCC: Added the sysfs entries for DCC(Data Capture and Compare) driver Date: Thu, 01 Apr 2021 18:10:31 -0700 [thread overview] Message-ID: <161732583102.2260335.10112716468679763483@swboyd.mtv.corp.google.com> (raw) In-Reply-To: <56a657ebc4b843575037e3ba9ec9cb9a@codeaurora.org> Quoting schowdhu@codeaurora.org (2021-04-01 08:42:50) > On 2021-03-30 01:39, Stephen Boyd wrote: > > Quoting Souradeep Chowdhury (2021-03-25 01:02:34) > >> The DCC is a DMA engine designed to store register values either in > >> case of a system crash or in case of software triggers manually done > >> by the user.Using DCC hardware and the sysfs interface of the driver > >> the user can exploit various functionalities of DCC.The user can > >> specify > >> the register addresses,the values of which is stored by DCC in it's > >> dedicated SRAM.The register addresses can be used either to read from, > >> write to,first read and store value and then write or to loop.All > >> these > >> options can be exploited using the sysfs interface given to the user. > >> Following are the sysfs interfaces exposed in DCC driver which are > >> documented > >> 1)trigger > >> 2)config > >> 3)config_write > >> 4)config_reset > >> 5)enable > >> 6)rd_mod_wr > >> 7)loop > >> > >> Signed-off-by: Souradeep Chowdhury <schowdhu@codeaurora.org> > >> --- > >> Documentation/ABI/testing/sysfs-driver-dcc | 114 > >> +++++++++++++++++++++++++++++ > > > > Please combine this with the driver patch. > > Ack > > > > >> 1 file changed, 114 insertions(+) > >> create mode 100644 Documentation/ABI/testing/sysfs-driver-dcc > > > > Perhaps this should be an ioctl interface instead of a sysfs interface? > > The reasons for choosing sysfs over ioctl is as follows Cool, please add these details to the commit text. > > > i) As can be seen from the sysfs attribute descriptions, most of it does > basic hardware manipulations like dcc_enable, dcc_disable, config reset > etc. As a result sysfs is preferred over ioctl as we just need to enter > a 0 or 1 > signal in such cases. > > ii) Existing similar debug hardwares are there for which drivers have > been written using sysfs interface. One such example is the > coresight-etm-trace driver. Following is the link for reference > > https://www.kernel.org/doc/html/latest/trace/coresight/coresight-etm4x-reference.html I wasn't deeply involved but I recall that the whole coresight sysfs interface was disliked and it mostly got rewritten to go through the perf tool instead. Pointing to the coresight sysfs API is not the best approach here. Maybe a closer analog would be the watchdog subsystem, which is ioctl based and uses a character device like /dev/watchdog. Watchdogs are simple debug features that reboot the system when everything goes wrong. This looks like a hardware block that can be used to gather information when the watchdog fires. Reading the doc closer it is quite frightening that a device like this can let you read registers in the hardware on-demand and even store values of registers over time. This is like /dev/mem on steroids. This needs to be highly restricted as it sounds like it could be used to snoop on security keys that are set in the hardware or secrets stored in memory. Is the hardware restricted at all in what it can read?
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <swboyd@chromium.org> To: schowdhu@codeaurora.org Cc: Andy Gross <agross@kernel.org>, Bjorn Andersson <bjorn.andersson@linaro.org>, Rob Herring <robh+dt@kernel.org>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>, Sibi Sankar <sibis@codeaurora.org>, Rajendra Nayak <rnayak@codeaurora.org>, vkoul@kernel.org Subject: Re: [PATCH V2 3/5] DCC: Added the sysfs entries for DCC(Data Capture and Compare) driver Date: Thu, 01 Apr 2021 18:10:31 -0700 [thread overview] Message-ID: <161732583102.2260335.10112716468679763483@swboyd.mtv.corp.google.com> (raw) In-Reply-To: <56a657ebc4b843575037e3ba9ec9cb9a@codeaurora.org> Quoting schowdhu@codeaurora.org (2021-04-01 08:42:50) > On 2021-03-30 01:39, Stephen Boyd wrote: > > Quoting Souradeep Chowdhury (2021-03-25 01:02:34) > >> The DCC is a DMA engine designed to store register values either in > >> case of a system crash or in case of software triggers manually done > >> by the user.Using DCC hardware and the sysfs interface of the driver > >> the user can exploit various functionalities of DCC.The user can > >> specify > >> the register addresses,the values of which is stored by DCC in it's > >> dedicated SRAM.The register addresses can be used either to read from, > >> write to,first read and store value and then write or to loop.All > >> these > >> options can be exploited using the sysfs interface given to the user. > >> Following are the sysfs interfaces exposed in DCC driver which are > >> documented > >> 1)trigger > >> 2)config > >> 3)config_write > >> 4)config_reset > >> 5)enable > >> 6)rd_mod_wr > >> 7)loop > >> > >> Signed-off-by: Souradeep Chowdhury <schowdhu@codeaurora.org> > >> --- > >> Documentation/ABI/testing/sysfs-driver-dcc | 114 > >> +++++++++++++++++++++++++++++ > > > > Please combine this with the driver patch. > > Ack > > > > >> 1 file changed, 114 insertions(+) > >> create mode 100644 Documentation/ABI/testing/sysfs-driver-dcc > > > > Perhaps this should be an ioctl interface instead of a sysfs interface? > > The reasons for choosing sysfs over ioctl is as follows Cool, please add these details to the commit text. > > > i) As can be seen from the sysfs attribute descriptions, most of it does > basic hardware manipulations like dcc_enable, dcc_disable, config reset > etc. As a result sysfs is preferred over ioctl as we just need to enter > a 0 or 1 > signal in such cases. > > ii) Existing similar debug hardwares are there for which drivers have > been written using sysfs interface. One such example is the > coresight-etm-trace driver. Following is the link for reference > > https://www.kernel.org/doc/html/latest/trace/coresight/coresight-etm4x-reference.html I wasn't deeply involved but I recall that the whole coresight sysfs interface was disliked and it mostly got rewritten to go through the perf tool instead. Pointing to the coresight sysfs API is not the best approach here. Maybe a closer analog would be the watchdog subsystem, which is ioctl based and uses a character device like /dev/watchdog. Watchdogs are simple debug features that reboot the system when everything goes wrong. This looks like a hardware block that can be used to gather information when the watchdog fires. Reading the doc closer it is quite frightening that a device like this can let you read registers in the hardware on-demand and even store values of registers over time. This is like /dev/mem on steroids. This needs to be highly restricted as it sounds like it could be used to snoop on security keys that are set in the hardware or secrets stored in memory. Is the hardware restricted at all in what it can read? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-04-02 1:10 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-25 8:02 [PATCH V2 0/5] Add driver support for Data Capture and Compare Engine(DCC) for SM8150 Souradeep Chowdhury 2021-03-29 7:49 ` [Resend PATCH V3 " Souradeep Chowdhury 2021-03-29 6:32 ` [PATCH " Souradeep Chowdhury 2021-03-25 8:02 ` [PATCH V2 1/5] dt-bindings: Added the yaml bindings for DCC Souradeep Chowdhury 2021-03-27 17:49 ` Rob Herring 2021-03-27 17:49 ` Rob Herring 2021-03-29 19:34 ` Stephen Boyd 2021-03-29 19:34 ` Stephen Boyd 2021-04-01 8:22 ` schowdhu 2021-03-25 8:02 ` [PATCH V2 2/5] soc: qcom: dcc: Add driver support for Data Capture and Compare unit(DCC) Souradeep Chowdhury 2021-03-29 20:05 ` Stephen Boyd 2021-03-29 20:05 ` Stephen Boyd 2021-04-01 14:04 ` schowdhu 2021-04-02 0:50 ` Stephen Boyd 2021-04-02 0:50 ` Stephen Boyd 2021-04-07 15:35 ` schowdhu 2021-03-25 8:02 ` [PATCH V2 3/5] DCC: Added the sysfs entries for DCC(Data Capture and Compare) driver Souradeep Chowdhury 2021-03-29 20:09 ` Stephen Boyd 2021-03-29 20:09 ` Stephen Boyd 2021-04-01 15:42 ` schowdhu 2021-04-02 1:10 ` Stephen Boyd [this message] 2021-04-02 1:10 ` Stephen Boyd 2021-03-25 8:02 ` [PATCH V2 4/5] MAINTAINERS: Add the entry for DCC(Data Capture and Compare) driver support Souradeep Chowdhury 2021-03-25 8:02 ` [PATCH V2 5/5] arm64: dts: qcom: sm8150: Add Data Capture and Compare(DCC) support node Souradeep Chowdhury 2021-03-26 22:08 ` kernel test robot 2021-03-26 22:08 ` kernel test robot 2021-03-26 22:08 ` kernel test robot [not found] ` <cover.1616997837.git.schowdhu@codeaurora.org> 2021-03-29 6:32 ` [PATCH V3 1/5] dt-bindings: Added the yaml bindings for DCC Souradeep Chowdhury 2021-03-29 7:57 ` schowdhu 2021-03-29 6:32 ` [PATCH V3 2/5] soc: qcom: dcc: Add driver support for Data Capture and Compare unit(DCC) Souradeep Chowdhury 2021-03-29 6:32 ` [PATCH V3 3/5] DCC: Added the sysfs entries for DCC(Data Capture and Compare) driver Souradeep Chowdhury 2021-03-29 6:32 ` [PATCH V3 4/5] MAINTAINERS: Add the entry for DCC(Data Capture and Compare) driver support Souradeep Chowdhury 2021-03-29 6:32 ` [PATCH V3 5/5] arm64: dts: qcom: sm8150: Add Data Capture and Compare(DCC) support node Souradeep Chowdhury [not found] ` <cover.1617001131.git.schowdhu@codeaurora.org> 2021-03-29 7:49 ` [Resend PATCH V3 1/5] dt-bindings: Added the yaml bindings for DCC Souradeep Chowdhury 2021-03-29 7:49 ` [Resend PATCH V3 2/5] soc: qcom: dcc: Add driver support for Data Capture and Compare unit(DCC) Souradeep Chowdhury 2021-03-29 7:49 ` [Resend PATCH V3 3/5] DCC: Added the sysfs entries for DCC(Data Capture and Compare) driver Souradeep Chowdhury 2021-03-29 7:49 ` [Resend PATCH V3 4/5] MAINTAINERS:Add the entry for DCC(Data Capture and Compare) driver support Souradeep Chowdhury 2021-03-29 7:49 ` [Resend PATCH V3 5/5] arm64: dts: qcom: sm8150: Add Data Capture and Compare(DCC) support node Souradeep Chowdhury
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=161732583102.2260335.10112716468679763483@swboyd.mtv.corp.google.com \ --to=swboyd@chromium.org \ --cc=agross@kernel.org \ --cc=bjorn.andersson@linaro.org \ --cc=devicetree@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=rnayak@codeaurora.org \ --cc=robh+dt@kernel.org \ --cc=saiprakash.ranjan@codeaurora.org \ --cc=schowdhu@codeaurora.org \ --cc=sibis@codeaurora.org \ --cc=vkoul@kernel.org \ /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: linkBe 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.