Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 18 Apr 2022 19:30:53 +0530
From:   Manivannan Sadhasivam <mani@kernel.org>
To:     Jeffrey Hugo <quic_jhugo@quicinc.com>
Cc:     quic_hemantk@quicinc.com, quic_bbhatt@quicinc.com,
        mhi@lists.linux.dev, linux-arm-msm@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] bus: mhi: host: Add soc_reset sysfs
Message-ID: <20220418140053.GB161722@thinkpad>
References: <1649883619-17609-1-git-send-email-quic_jhugo@quicinc.com>
 <20220418054649.GB7431@thinkpad>
 <2c776c00-5742-516f-06e3-80db9f572cb4@quicinc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2c776c00-5742-516f-06e3-80db9f572cb4@quicinc.com>
Precedence: bulk

On Mon, Apr 18, 2022 at 07:45:06AM -0600, Jeffrey Hugo wrote:
> On 4/17/2022 11:46 PM, Manivannan Sadhasivam wrote:
> > On Wed, Apr 13, 2022 at 03:00:19PM -0600, Jeffrey Hugo wrote:
> > > From: Jeffrey Hugo <jhugo@codeaurora.org>
> > > 
> > > The MHI bus supports a standardized hardware reset, which is known as the
> > > "SoC Reset".  This reset is similar to the reset sysfs for PCI devices -
> > > a hardware mechanism to reset the state back to square one.
> > > 
> > > The MHI SoC Reset is described in the spec as a reset of last resort.  If
> > > some unrecoverable error has occurred where other resets have failed, SoC
> > > Reset is the "big hammer" that ungracefully resets the device.  This is
> > > effectivly the same as yanking the power on the device, and reapplying it.
> > > However, depending on the nature of the particular issue, the underlying
> > > transport link may remain active and configured.  If the link remains up,
> > > the device will flag a MHI system error early in the boot process after
> > > the reset is executed, which allows the MHI bus to process a fatal error
> > > event, and clean up appropiately.
> > > 
> > > While the SoC Reset is generally intended as a means of recovery when all
> > > else has failed, it can be useful in non-error scenarios.  For example,
> > > if the device loads firmware from the host filesystem, the device may need
> > > to be fully rebooted inorder to pick up the new firmware.  In this
> > > scenario, the system administrator may use the soc_reset sysfs to cause
> > > the device to pick up the new firmware that the admin placed on the
> > > filesystem.
> > > 
> > > Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org>
> > > Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
> > 
> > Do you need double signed-off because of change in domain?
> > 
> > Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> 
> That seems to be the convention that I see in the community.  As I
> understand it, the SoB is linked to the Developers Certificate of Origin.
> This version of the change is coming from "quic_jhugo@quicinc.com" and that
> entity needs to certify they can share the code under the Cert of Origin.
> 
> In theory, I could have avoided this by sending this version under the
> codeaurora address.  The problem is that the codeaurora domain no longer
> exists, so sending/receiving email from that id is not possible.
> 
> If I'm not understanding things correctly, please educate me.

IANAL, but since you are the sole developer (and with the same employer) I think
it is fine to change the DCO. Moreover, if codeaurora is used, it will get CCed
and will bounce.

But if you have a strong desire to keep the two tags, please let me know.

Thanks,
Mani