From: Jeffrey Hugo <[email protected]>
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 <[email protected]>
Signed-off-by: Jeffrey Hugo <[email protected]>
---
v2:
Rebase
Documentation/ABI/stable/sysfs-bus-mhi | 11 +++++++++++
drivers/bus/mhi/host/init.c | 14 ++++++++++++++
2 files changed, 25 insertions(+)
diff --git a/Documentation/ABI/stable/sysfs-bus-mhi b/Documentation/ABI/stable/sysfs-bus-mhi
index ecfe766..306f63e 100644
--- a/Documentation/ABI/stable/sysfs-bus-mhi
+++ b/Documentation/ABI/stable/sysfs-bus-mhi
@@ -19,3 +19,14 @@ Description: The file holds the OEM PK Hash value of the endpoint device
read without having the device power on at least once, the file
will read all 0's.
Users: Any userspace application or clients interested in device info.
+
+What: /sys/bus/mhi/devices/.../soc_reset
+Date: April 2022
+KernelVersion: 5.19
+Contact: [email protected]
+Description: Initiates a SoC reset on the MHI controller. A SoC reset is
+ a reset of last resort, and will require a complete re-init.
+ This can be useful as a method of recovery if the device is
+ non-responsive, or as a means of loading new firmware as a
+ system administration task.
+
diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c
index 04c409b..e12b210 100644
--- a/drivers/bus/mhi/host/init.c
+++ b/drivers/bus/mhi/host/init.c
@@ -108,9 +108,23 @@ static ssize_t oem_pk_hash_show(struct device *dev,
}
static DEVICE_ATTR_RO(oem_pk_hash);
+static ssize_t soc_reset_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf,
+ size_t count)
+{
+ struct mhi_device *mhi_dev = to_mhi_device(dev);
+ struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
+
+ mhi_soc_reset(mhi_cntrl);
+ return count;
+}
+static DEVICE_ATTR_WO(soc_reset);
+
static struct attribute *mhi_dev_attrs[] = {
&dev_attr_serial_number.attr,
&dev_attr_oem_pk_hash.attr,
+ &dev_attr_soc_reset.attr,
NULL,
};
ATTRIBUTE_GROUPS(mhi_dev);
--
2.7.4
On Wed, Apr 13, 2022 at 03:00:19PM -0600, Jeffrey Hugo wrote:
> From: Jeffrey Hugo <[email protected]>
>
> 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 <[email protected]>
> Signed-off-by: Jeffrey Hugo <[email protected]>
Do you need double signed-off because of change in domain?
Reviewed-by: Manivannan Sadhasivam <[email protected]>
Thanks,
Mani
> ---
>
> v2:
> Rebase
>
> Documentation/ABI/stable/sysfs-bus-mhi | 11 +++++++++++
> drivers/bus/mhi/host/init.c | 14 ++++++++++++++
> 2 files changed, 25 insertions(+)
>
> diff --git a/Documentation/ABI/stable/sysfs-bus-mhi b/Documentation/ABI/stable/sysfs-bus-mhi
> index ecfe766..306f63e 100644
> --- a/Documentation/ABI/stable/sysfs-bus-mhi
> +++ b/Documentation/ABI/stable/sysfs-bus-mhi
> @@ -19,3 +19,14 @@ Description: The file holds the OEM PK Hash value of the endpoint device
> read without having the device power on at least once, the file
> will read all 0's.
> Users: Any userspace application or clients interested in device info.
> +
> +What: /sys/bus/mhi/devices/.../soc_reset
> +Date: April 2022
> +KernelVersion: 5.19
> +Contact: [email protected]
> +Description: Initiates a SoC reset on the MHI controller. A SoC reset is
> + a reset of last resort, and will require a complete re-init.
> + This can be useful as a method of recovery if the device is
> + non-responsive, or as a means of loading new firmware as a
> + system administration task.
> +
> diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c
> index 04c409b..e12b210 100644
> --- a/drivers/bus/mhi/host/init.c
> +++ b/drivers/bus/mhi/host/init.c
> @@ -108,9 +108,23 @@ static ssize_t oem_pk_hash_show(struct device *dev,
> }
> static DEVICE_ATTR_RO(oem_pk_hash);
>
> +static ssize_t soc_reset_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf,
> + size_t count)
> +{
> + struct mhi_device *mhi_dev = to_mhi_device(dev);
> + struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
> +
> + mhi_soc_reset(mhi_cntrl);
> + return count;
> +}
> +static DEVICE_ATTR_WO(soc_reset);
> +
> static struct attribute *mhi_dev_attrs[] = {
> &dev_attr_serial_number.attr,
> &dev_attr_oem_pk_hash.attr,
> + &dev_attr_soc_reset.attr,
> NULL,
> };
> ATTRIBUTE_GROUPS(mhi_dev);
> --
> 2.7.4
>
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 <[email protected]>
> > >
> > > 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 <[email protected]>
> > > Signed-off-by: Jeffrey Hugo <[email protected]>
> >
> > Do you need double signed-off because of change in domain?
> >
> > Reviewed-by: Manivannan Sadhasivam <[email protected]>
>
> 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 "[email protected]" 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
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 <[email protected]>
>>
>> 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 <[email protected]>
>> Signed-off-by: Jeffrey Hugo <[email protected]>
>
> Do you need double signed-off because of change in domain?
>
> Reviewed-by: Manivannan Sadhasivam <[email protected]>
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
"[email protected]" 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.