| Message ID | 1649883619-17609-1-git-send-email-quic_jhugo@quicinc.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2] bus: mhi: host: Add soc_reset sysfs | expand |
On 4/13/2022 2:00 PM, 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> > --- Reviewed-by: Bhaumik Bhatt <quic_bbhatt@quicinc.com> > 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: mhi@lists.linux.dev > +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);
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> 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: mhi@lists.linux.dev > +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 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.
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
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: mhi@lists.linux.dev +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);