On Wed, Jan 31, 2024 at 05:22:26PM +, Matt Coster wrote:
> On 25/01/2024 18:44, Daniel Vetter wrote:
> > On Tue, Jan 23, 2024 at 01:04:24PM +, Matt Coster wrote:
> >> From: Donald Robson
> >>
> >> When the kernel driver 'loses' the device, for instance if the firmware
> >> stops communicat
On 25/01/2024 18:44, Daniel Vetter wrote:
> On Tue, Jan 23, 2024 at 01:04:24PM +, Matt Coster wrote:
>> From: Donald Robson
>>
>> When the kernel driver 'loses' the device, for instance if the firmware
>> stops communicating, the driver calls drm_dev_unplug(). This is
>> currently done inside
On Tue, Jan 23, 2024 at 01:04:24PM +, Matt Coster wrote:
> From: Donald Robson
>
> When the kernel driver 'loses' the device, for instance if the firmware
> stops communicating, the driver calls drm_dev_unplug(). This is
> currently done inside the drm_dev_enter() critical section, which isn'
From: Donald Robson
When the kernel driver 'loses' the device, for instance if the firmware
stops communicating, the driver calls drm_dev_unplug(). This is
currently done inside the drm_dev_enter() critical section, which isn't
permitted. In addition, the bool that marks the device as lost is not