On Thu, Nov 21, 2024 at 11:53 PM Dmitry Baryshkov
<dmitry.baryshkov@xxxxxxxxxx> wrote:
>
> On Wed, Nov 20, 2024 at 03:56:41PM +0100, Łukasz Bartosik wrote:
> > On Mon, Nov 18, 2024 at 6:58 PM Dmitry Baryshkov
> > <dmitry.baryshkov@xxxxxxxxxx> wrote:
> > >
> > > On Mon, Nov 04, 2024 at 03:42:52PM +0000, Łukasz Bartosik wrote:
> > > > OPM PPM LPM
> > > > | 1.send cmd | |
> > > > |-------------------------->| |
> > > > | |-- |
> > > > | | | 2.set busy bit in CCI |
> > > > | |<- |
> > > > | 3.notify the OPM | |
> > > > |<--------------------------| |
> > > > | | 4.send cmd to be executed |
> > > > | |-------------------------->|
> > > > | | |
> > > > | | 5.cmd completed |
> > > > | |<--------------------------|
> > > > | | |
> > > > | |-- |
> > > > | | | 6.set cmd completed |
> > > > | |<- bit in CCI |
> > > > | | |
> > > > | 7.handle notification | |
> > > > | from point 3, read CCI | |
> > > > |<--------------------------| |
> > > > | | |
> > > > | 8.notify the OPM | |
> > > > |<--------------------------| |
> > > > | | |
> > > >
> > > > When the PPM receives command from the OPM (p.1) it sets the busy bit
> > > > in the CCI (p.2), sends notification to the OPM (p.3) and forwards the
> > > > command to be executed by the LPM (p.4). When the PPM receives command
> > > > completion from the LPM (p.5) it sets command completion bit in the CCI
> > > > (p.6) and sends notification to the OPM (p.8). If command execution by
> > > > the LPM is fast enough then when the OPM starts handling the notification
> > > > from p.3 in p.7 and reads the CCI value it will see command completion bit
> > > > and will call complete(). Then complete() might be called again when the
> > > > OPM handles notification from p.8.
> > >
> > > I think the change is fine, but I'd like to understand, what code path
> > > causes the first read from the OPM side before the notification from
> > > the PPM?
> > >
> >
> > The read from the OPM in p.7 is a result of notification in p.3 but I agree
> > it is misleading since you pointed it out. I will reorder p.7 and p.8.
>
> Ack, thanks for the explanation. Do you think that it also might be
> beneficial to call reinit_completion() when sending the command? I think
> we discussed this change few months ago on the ML, but I failed to send
> the patch...
>
Dmitry sorry for delayed response.
IMHO it makes sense to clear completion in ucsi_sync_control_common()
with reinit_completion().
But I wonder whether with this change moving from test_bit ->
test_and_clear_bit do you still see a potential
scenario for a race ?
Thanks,
Lukasz
> >
> > Thanks,
> > Lukasz
> >
> > > >
> > > > This fix replaces test_bit() with test_and_clear_bit()
> > > > in ucsi_notify_common() in order to call complete() only
> > > > once per request.
> > > >
> > > > Fixes: 584e8df58942 ("usb: typec: ucsi: extract common code for command handling")
> > > > Cc: stable@xxxxxxxxxxxxxxx
> > > > Signed-off-by: Łukasz Bartosik <ukaszb@xxxxxxxxxxxx>
> > > > ---
> > > > drivers/usb/typec/ucsi/ucsi.c | 4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c
> > > > index e0f3925e401b..7a9b987ea80c 100644
> > > > --- a/drivers/usb/typec/ucsi/ucsi.c
> > > > +++ b/drivers/usb/typec/ucsi/ucsi.c
> > > > @@ -46,11 +46,11 @@ void ucsi_notify_common(struct ucsi *ucsi, u32 cci)
> > > > ucsi_connector_change(ucsi, UCSI_CCI_CONNECTOR(cci));
> > > >
> > > > if (cci & UCSI_CCI_ACK_COMPLETE &&
> > > > - test_bit(ACK_PENDING, &ucsi->flags))
> > > > + test_and_clear_bit(ACK_PENDING, &ucsi->flags))
> > > > complete(&ucsi->complete);
> > > >
> > > > if (cci & UCSI_CCI_COMMAND_COMPLETE &&
> > > > - test_bit(COMMAND_PENDING, &ucsi->flags))
> > > > + test_and_clear_bit(COMMAND_PENDING, &ucsi->flags))
> > > > complete(&ucsi->complete);
> > > > }
> > > > EXPORT_SYMBOL_GPL(ucsi_notify_common);
> > > > --
> > > > 2.47.0.199.ga7371fff76-goog
> > > >
> > >
> > > --
> > > With best wishes
> > > Dmitry
>
> --
> With best wishes
> Dmitry
