Wiznet w5500 support

[Quentin Schulz]

Hi Jean-Marie,

On 4/23/25 4:37 PM, Verdun, Jean-Marie wrote:
> You don't often get email from verdun at hpe.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
> Hi Quentin,
> 
> I was looking for example like the one in pmic. I will refactor my code to take it into consideration. That is my first driver that I submit to u-boot.
> 
> The linux kernel has a spi side
> 
> https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/wiznet/w5100-spi.c
> 

Yeah, it's just to support the SPI way of accessing the registers for 
the w5100 driver which seems to be "normally" MMIO.

The non -spi driver is still sufficient for MMIO IPs (Intellectual 
Property), likely the ones in an SoC/MCU and accessible via simple 
writel/readl to an address. You can see that because the driver has a 
platform_driver struct which is usually for drivers outside of the 
well-known busses like I2C, SPI, etc..

The -spi driver is registering an spi_driver struct, which is for 
devices on an SPI bus. It does call w5100_probe() from the non-spi 
driver after setting the w5100_ops and a few other things properly.

> And the device tree setup is a little bit confusing. Roughly you call the net driver from a DTS node which is a spi slave, and the net driver is probing the spi side which is not attached to any DTS node. I tried to do the same approach with u-boot but did 

Why is not attached to any DTS node? There's an of_device_id table in 
the spi driver, so it'll match against those compatibles wherever 
required and probe a device for w5100_spi_driver.

Can you provide us with an attempt you made at doing the DTS without the 
phandles? Maybe there's some misunderstanding somewhere on how to do 
this (or a mistake in the driver, there doesn't seem to be upstream DT 
users of that driver :/).

struggle a lot at doing it, as it seems that u-boot needs to have a 
device tree node attached to each driver to get it activated.
> 
> I will try to get as close as the linux kernel do.
> 
> The good news is that it seems that I do not have any push back to get that feature onboarded inside u-boot.
> 

 From us, there's seldom push back when it comes to individual drivers, 
same for the kernel. It's usually only when changing the core, subsystem 
or APIs that things take more time, discussions and compromises.

> The code I wrote is really a quick and dirty implementation as to run a demo next week to the OCP Summit in Dublin. I will now make it compliant with code styling and everything needed to get it accepted. I will just need your help, patience and resilience to guide me.
> 
> For the moment the only code check, I am doing is through the compiler which doesn’t report any warning. I will add other code checks from the linux kernel moving forward
> 

Please have a look at 
https://docs.u-boot.org/en/latest/develop/index.html, I'm sure there's 
going to be something of interest to you there. Specifically coding 
style and sending patches? Note that U-Boot also supports sending 
patches via b4, 
https://b4.docs.kernel.org/en/latest/contributor/overview.html.

Please consider updating the binding in the kernel tree to a YAML one so 
that both projects benefit from it :)

Cheers,
Quentin