Hi Quentin, I have updated the code on my github
https://github.com/vejmarie/u-boot/tree/w5500 I have adapted the code styling and used Lindent as well as checkpatch (which is still report Caml variable naming issue, but they are coming from the linux kernel and think they are acceptable as is). I also removed the need for the spi part of the driver and have a single driver now. The compatible of the driver has been updated to match the linux kernel one. I need to find a way to send the patch in TXT mode on the mailing list, if you believe that the code is getting closer to what the community wants. Thanks all for your support and help Jean-Marie From: Quentin Schulz <quentin.sch...@cherry.de> Date: Thursday, April 24, 2025 at 12:24 AM To: Verdun, Jean-Marie <ver...@hpe.com>, u-boot@lists.denx.de <u-boot@lists.denx.de> Subject: Re: Wiznet w5500 support Hi Jean-Marie, On 4/23/25 4:37 PM, Verdun, Jean-Marie wrote: > You don't often get email from ver...@hpe.com. Learn why this is > important<https://urldefense.com/v3/__https://aka.ms/LearnAboutSenderIdentification__;!!NpxR!hz74WGG4G5V34FTmrbznS-LtfW1l0miSAhdAtIT_mq-5h5B-jwZ6eOpoxIjI6NpERV_jKgmEdd-my7KAe0nv4qo$ > > > 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://urldefense.com/v3/__https://docs.u-boot.org/en/latest/develop/index.html__;!!NpxR!hz74WGG4G5V34FTmrbznS-LtfW1l0miSAhdAtIT_mq-5h5B-jwZ6eOpoxIjI6NpERV_jKgmEdd-my7KAe9r8huI$<https://urldefense.com/v3/__https:/docs.u-boot.org/en/latest/develop/index.html__;!!NpxR!hz74WGG4G5V34FTmrbznS-LtfW1l0miSAhdAtIT_mq-5h5B-jwZ6eOpoxIjI6NpERV_jKgmEdd-my7KAe9r8huI$> , 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
