Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <9d405506-3083-3827-990b-ff2151bf6024@quicinc.com>
Date:   Wed, 10 May 2023 16:30:38 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.6.2
Subject: Re: [PATCH v1 2/2] drm/msm/dp: add mutex to protect internal_hpd
 against race condition between different threads
Content-Language: en-US
To:     Kuogee Hsieh <quic_khsieh@quicinc.com>,
        Stephen Boyd <swboyd@chromium.org>, <agross@kernel.org>,
        <airlied@gmail.com>, <andersson@kernel.org>, <daniel@ffwll.ch>,
        <dianders@chromium.org>, <dmitry.baryshkov@linaro.org>,
        <dri-devel@lists.freedesktop.org>, <robdclark@gmail.com>,
        <sean@poorly.run>, <vkoul@kernel.org>
CC:     <quic_jesszhan@quicinc.com>, <quic_sbillaka@quicinc.com>,
        <marijn.suijten@somainline.org>, <freedreno@lists.freedesktop.org>,
        <linux-arm-msm@vger.kernel.org>, <linux-kernel@vger.kernel.org>
References: <1683750665-8764-1-git-send-email-quic_khsieh@quicinc.com>
 <1683750665-8764-3-git-send-email-quic_khsieh@quicinc.com>
 <CAE-0n532y=ARQ_+urEA_b3zUn+gKTu1fgK_siHNt3CpbLB9PZg@mail.gmail.com>
 <74ae5514-2b04-9363-902e-cb4d7cbe1128@quicinc.com>
 <6721cc2c-6988-948c-65d6-f50edb925ded@quicinc.com>
From:   Abhinav Kumar <quic_abhinavk@quicinc.com>
In-Reply-To: <6721cc2c-6988-948c-65d6-f50edb925ded@quicinc.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

Hi Stephen

On 5/10/2023 4:19 PM, Kuogee Hsieh wrote:
> internal_hpd is referenced at both plug and unplug handle.
> 
> The majority purpose of  mutext is try to serialize internal_hpd between 
> dp_bridge_hpd_disable() and either plug or unplug handle.
> 
> 
> On 5/10/2023 4:11 PM, Abhinav Kumar wrote:
>>
>>
>> On 5/10/2023 3:46 PM, Stephen Boyd wrote:
>>> Quoting Kuogee Hsieh (2023-05-10 13:31:05)
>>>> Intrenal_hpd is referenced by event thread but set by drm bridge 
>>>> callback
>>>> context. Add mutex to protect internal_hpd to avoid conflicts between
>>>> threads.
>>>>
>>>> Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com>
>>>> ---
>>>
>>> This patch looks completely unnecessary. How can dp_bridge_hpd_enable()
>>> be called at the same time that dp_bridge_hpd_disable() is called or
>>> dp_bridge_hpd_notify() is called? Isn't there locking or ordering at a
>>> higher layer?
>>
>> Ack. We can drop this patch because we are protected by 
>> bridge->hpd_mutex in drm_bridge_hpd_enable() / drm_bridge_hpd_disable 
>> () and drm_bridge_hpd_notify().

I understood now, so what kuogee is referring to is that this 
event_mutex protection is to not protect those 3 calls from each other 
(since they are already protected as we saw above) but because 
dp_hpd_plug_handle/dp_hpd_unplug_handle still uses 
dp_display.internal_hpd to re-enable the hot-plug interrupt, this is 
making sure that flow is protected as well.