On Mon Nov 13, 2023 at 4:37 PM CET, Kalle Valo wrote:
> "Luca Weiss" writes:
>
> > On Fri Oct 27, 2023 at 10:25 AM CEST, Kalle Valo wrote:
> >
> >> Luca Weiss writes:
> >>
> >> > If we already have gotten the rproc_handle (meaning the "qcom,rproc"
> >> > property is defined in the devicetree), it
Luca Weiss wrote:
> If we already have gotten the rproc_handle (meaning the "qcom,rproc"
> property is defined in the devicetree), it's a valid state that the
> remoteproc module hasn't probed yet so we should defer probing instead
> of just failing to probe.
>
> This resolves a race condition w
"Luca Weiss" writes:
> On Fri Oct 27, 2023 at 10:25 AM CEST, Kalle Valo wrote:
>
>> Luca Weiss writes:
>>
>> > If we already have gotten the rproc_handle (meaning the "qcom,rproc"
>> > property is defined in the devicetree), it's a valid state that the
>> > remoteproc module hasn't probed yet so
On Fri Oct 27, 2023 at 10:25 AM CEST, Kalle Valo wrote:
> Luca Weiss writes:
>
> > If we already have gotten the rproc_handle (meaning the "qcom,rproc"
> > property is defined in the devicetree), it's a valid state that the
> > remoteproc module hasn't probed yet so we should defer probing instead
Luca Weiss writes:
> If we already have gotten the rproc_handle (meaning the "qcom,rproc"
> property is defined in the devicetree), it's a valid state that the
> remoteproc module hasn't probed yet so we should defer probing instead
> of just failing to probe.
>
> This resolves a race condition w
If we already have gotten the rproc_handle (meaning the "qcom,rproc"
property is defined in the devicetree), it's a valid state that the
remoteproc module hasn't probed yet so we should defer probing instead
of just failing to probe.
This resolves a race condition when the ath11k driver probes and
6 matches
Mail list logo
