Re: [PATCH 00/23] Subject: [PATCH net-next 00/23] net/hpe: add HPE Slingshot NIC drivers

[Doug Ledford]

On 11/4/26 7:04 AM, Jason Gunthorpe wrote:
> On Wed, Nov 04, 2026 at 03:48:58PM +0100, Andrew Lunn wrote:
> 
>> A bit of an aside. Do you have the complete history of the driver?
>> What did the first 10 patches do? When bringing up new hardware, you
>> start small and get a little piece working. 
> 
> If you are implementing a driver from a datasheet, sure.
> 
> However a device like this was almost certainly co-designed in a chip
> simulator along side the HW and by the time the HW was done they had a
> mostly complete driver ready to go. The actual baked chip probably
> never ran a driver like you are imagining.

Jason is correct here.  Something as complex as a Portals 4.0 API device
does not have 10 small patches to print "Hello world".  It can't.
They're too complex and there is too much setup just to get to "Hello
world".  And yes, we have both a chip simulator and a qemu simulator
where the testing happened.  Using those we already have Cassini3
software ready to go, but untested until our first hardware arrives.
That was obviously excluded from this submission.

>> I'm assuming you did something similar, small bits of code you could
>> somehow test. Those small bits of code, step by step development, are
>> generally easy to review.
> 
> When you are co-designing with a chip simulator things work
> differently, you'd focus on the more risky parts of the IP and do
> partial driver flows and so on to vet things out. Lots of carefully
> orchestrated shortcuts. Then you take that and assemble a complete
> driver to run more complete sim passes. As this progresses the HW is
> changing underneath and the SW is following along.
> 
> So it is completely understandable they ended up with a completed
> driver at the end of the process rather than a bunch of logical small
> steps.
> 
>> Generally, none. We just want a plain, boring netdev, which looks the
>> same as every other plain boring netdev in the kernel. OS 101, the OS
>> is there to abstract over the hardware so all hardware looks the same.
> 
> Yeah, this is a reasonable place to start. I also discourage any uAPI
> introduction into any new drivers. Start with the basics then we can
> talk about why it needs new uAPI point by point.

Yeah, I'd forgotten (in my 6-7 year break) that sysfs is uAPI.  I've got
it now, thanks for the reminder.

-- 
Doug Ledford <doug.ledford@xxxxxxx>
    GPG KeyID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature