Re: git: 28aaa58fa64e - main - fu740_pci_dw: Fix PERST delay and keep asserted for rest of reset sequence

On 6/2/24 14:15, Jessica Clarke wrote:
> On 2 Jun 2024, at 22:01, Colin Percival <cperciva@tarsnap.com> wrote:
>> On 6/2/24 13:43, Jessica Clarke wrote:
>>>      fu740_pci_dw: Fix PERST delay and keep asserted for rest of reset sequence
>>>           DELAY takes microseconds not milliseconds, so 100 was too low. Moreover,
>>>      when enabling hw.pci.clear_pcib, PCI emeration would still stop at one
>>>      of the first bridges, but by asserting PERST for the rest of the reset
>>>      sequence that appears to be reliably addressed.
>>
>> Does this need to be a DELAY as opposed to something asynchronous?  We try to
>> avoid lengthy DELAYs in the boot process.
> 
> It’s in the middle of device_attach, so you’d need to break it up into
> two stages. I don’t know if we have a good way of doing that for
> delays; I’ve seen other glue code drivers do things like this, but
> there may well be a better way, and if so I’m all ears.

I don't think there's any good mechanism for doing that, unfortunately.  Part
of the problem is that our device probing scheme is designed around the idea
that by the time you return from device_attach, you know if the device has
successfully attached; if you discover that the device is broken at a later
time it's too late to assign the unit number to a different device.

I remember talking to Warner about this a while back in the context of nvme,
but the problem of "the spec says we have to wait a long time and we don't
want to do that serially for every disk" was resolved by our driver learning
to be opportunistic and ask the disks if they were ready yet instead of simply
waiting the time stipulated by the spec.

Maybe something to consider when someone decides to write newnewbus. ;-)

> Though given
> you won’t have working PCI (so no USB nor NVMe) until this is done
> there’s probably not much more you can do during boot whilst you wait,
> so it may not be worth pursuing. Also, given the performance of the SoC
> in question, 100ms isn’t something you’d be close to noticing...

Fair enough, I wasn't sure what sort of hardware this was.  Sounds like we're
fine here; it just caught my eye so I thought I'd ask.

-- 
Colin Percival
FreeBSD Release Engineering Lead & EC2 platform maintainer
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid