On Fri, Mar 03, 2023 at 02:33:49PM +0800, lihuisong (C) wrote: > Sorry for my resend. Because I found that my last reply email is not in the > thread of this patch. I guess it may be send failed. > > 在 2023/3/2 22:02, Sudeep Holla 写道: > > No. I meant a comment saying it is not need since only one transfer can occur > > at a time and mailbox takes care of locking. So chan_in_use can be accessed > > without a lock. > Got it. Agreed. Thanks > > > For types no need this flag, it is always hard to understand and redundant > > > design. > > But does it matter ? You can even support shared interrupt for type 1&2. > BTW, type 1 subspaces do not support a level triggered platform interrupt as > no method is provided to clear the interrupt. Agreed but there is no harm using the flag, you can add a comment that it is useful only if shared interrupts are supported. That will imply it is dummy for type 1. I am avoiding too many type unnecessary checks especially in IRQ handler. > > They support level interrupt, so we can add them too. I understand you can > > test only type 3, but this driver caters for all and the code must be generic > > as much as possible. I don't see any point in check for type 3 only. Only > I understand what you do. > But type 2 also supports the communication flow from OSPM to Platfrom. > In this case, this flag will get in the way of type 2. > How ? > Whether the interrupt belongs to a type2 channel is only determined by > the status field in Generic Communications Channel Shared Memory Region, > which is done in rx_callback of PCC client. Agreed, but do you see any issue using the flag even if it acts as dummy ? -- Regards, Sudeep
