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

On 6/2/24 14:45, Warner Losh wrote:
> On Sun, Jun 2, 2024, 3:37 PM Colin Percival <cperciva@tarsnap.com 
> <mailto:cperciva@tarsnap.com>> wrote:
>     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.
> 
> This is false. We assign unit in probe, and once assigned you don't want to 
> reassign it.

Ah, I misremembered.  It's a while since I was thinking about these details.

>     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.
> 
> If there's no status register to read, you can't do much. And in an SoC 
> there's only going to be one. So between yhe two, i don't see much benefit to 
> be had. And even if we could do this wait asynchronously, there is nothing 
> else to do in parallel.

I suppose it's unlikely that an SoC would have two PCI buses...

>     Maybe something to consider when someone decides to write newnewbus. ;-)
> 
> Parallel discovery is something we've talked about, but there's a number of 
> logistical issues to sort out first.

Yep, definitely nontrivial.

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