Re: [PATCH -next 1/1] firmware: arm_scmi: Fix possible deadlock in shmem_tx_prepare()

[YaxiongTian <iambestgod@outlook.com>]

Hi Cristian

    There may be a problem with my qq email client,   I don't see my 
mail in the

communityI had to switch outlook email.Forgive me if you've received 
multiple emails.

 >Problem is anyway, as you said, you'll have to pick this timeout from the
 >related transport scmi_desc (even if as of now the max_rx_timeout for
 >all existent shared mem transport is the same..) and this means anyway
 >adding more complexity to the chain of calls to just to print a warn of
 >some kind in a rare error-situation from which you cannot recover anyway.

   Yes,it has add more complexity about Monitorring this time.For system
stability,the safest thing to do is to abort the transmission.But this will
lose performance due to more complexity in such unusual situation.

 >Due to other unrelated discussions, I was starting to think about
 >exposing some debug-only (Kconfig dependent) SCMI stats like timeouts, 
errors,
 >unpexpected/OoO/late_replies in order to ease the debug and monitoring
 >of the health of a running SCMI stack: maybe this could be a place where
 >to flag this FW issues without changing the spinloop above (or
 >to add the kind of timeout you mentioned but only when some sort of
 >CONFIG_SCMI_DEBUG is enabled...)...still to fully think it through, 
though.

   I think it should active report warn or err rather than user queries the
information manually.(i.e fs_debug way).Becasue in system startup\S1\S3\S4,
user can not queries this flag in Fw,they need get stuck message 
immediately.


Thanks,
Tian


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel