lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 23 Dec 2016 17:57:57 -0600 From: Suman Anna <s-anna@...com> To: Sarangdhar Joshi <spjoshi@...eaurora.org>, Ohad Ben-Cohen <ohad@...ery.com>, Bjorn Andersson <bjorn.andersson@...aro.org>, Santosh Shilimkar <ssantosh@...nel.org> CC: <linux-remoteproc@...r.kernel.org>, <linux-kernel@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>, <linux-arm-msm@...r.kernel.org>, Stephen Boyd <sboyd@...eaurora.org>, Trilok Soni <tsoni@...eaurora.org>, Dave Gerlach <d-gerlach@...com> Subject: Re: [PATCH 1/2] soc: ti: Use remoteproc auto_boot feature On 12/23/2016 11:05 AM, Suman Anna wrote: > Hi Sarang, > >>> >>> On 12/15/2016 06:03 PM, Sarangdhar Joshi wrote: >>>> The function wkup_m3_rproc_boot_thread waits for asynchronous >>>> firmware loading to complete successfully before calling >>>> rproc_boot(). The same can be achieved by just setting >>>> rproc->auto_boot flag. Change this. As a result this change >>>> removes wkup_m3_rproc_boot_thread and moves m3_ipc->sync_complete >>>> initialization to the wkup_m3_ipc_probe(). >>>> >>>> Other than the current usage, the firmware_loading_complete is >>>> only used in rproc_del() where it's no longer needed. This >>>> change is in preparation for removing firmware_loading_complete >>>> completely. >>> >>> Based on the comments so far, I am assuming that you are dropping this >>> series. >> >> No, may not be dropping this. Will try to handle it differently in >> rproc_del() (probably by making use of some state flag). >>> >>> In any case, this series did break our PM stack. We definitely don't >>> want to auto-boot the wkup_m3_rproc device, that responsibility will >>> need to stay with the wkup_m3_ipc driver. >> >> Which scenario did it break? Booting up rproc device before >> wkup_m3_ipc_probe() causes issues? > > Yes, our state machine requires the wkup_m3_ipc driver to control the > boot of the wkup_m3 remoteproc. The wkup_m3 is not a typical remoteproc, > it is our PM master and is responsible for putting the host processor > into suspend and waking it up in system suspend/cpuidle paths. > The remoteproc infrastructure is only used for load/boot, but the Linux > PM state machine and communication is all controlled by the wkup_m3_ipc > driver. > >> >> Nevertheless, I think Bjorn's suggestion of just dropping the call to >> wait_for_completion() and keeping kthread looks good, also because of >> the fact that rproc_boot() anyways calls request_firmware() and no >> longer needed to wait on asynchronous loading of firmware. > > Yeah, I will have to test this, but looking at current code, this should > mostly be ok because of the remoteproc core changes w.r.t resource table > parsing. Tested with just the wait_for_completion() removed and it works fine. I can send a patch for the same if you prefer me to send it. regards Suman > > regards > Suman > -- > To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in > the body of a message to majordomo@...r.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Powered by blists - more mailing lists