Re: [PATCH v2] bus: mhi: host: Add soc_reset sysfs

From: Jeffrey Hugo <quic_jhugo@quicinc.com>
To: Manivannan Sadhasivam <mani@kernel.org>
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
Date: Mon, 18 Apr 2022 07:45:06 -0600	[thread overview]
Message-ID: <2c776c00-5742-516f-06e3-80db9f572cb4@quicinc.com> (raw)
In-Reply-To: <20220418054649.GB7431@thinkpad>

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.