[PATCH v4 1/1] Initial support for Wiznet W5500

[Quentin Schulz]

Hi Jean-Marie,

On 5/19/25 11:05 AM, Verdun, Jean-Marie wrote:
>>> Fair enough. You could have the same ternary operator to better match
>>> what's in the kernel.
> 
>>> Can you also reuse the macros that are in the kernel already?
>>> W5500_SPI_BLOCK_SELECT, W5500_SPI_READ_CONTROL and
>>> W5500_SPI_WRITE_CONTROL seems to be of interest?
> 
> I will check it
> 
>>> If you do that, please also update the kernel code to use that :)
> 
> I have a new version of the driver code without the _spi_read* _spi_write* calls. I think for the u-boot version it will be ok as it shorten the source code.

Since you're already written the code, maybe it's fine to keep it? I 
assume the split in the kernel was done so that it would be easier to 
add support for other (future?) chips which would be able to operate on 
different buses than SPI? Though it seems that all their iEthernet 
product line only operate on SPI 
(https://docs.wiznet.io/Product/iEthernet)? There's typical interest in 
staying possibly as close as possible to Linux kernel drivers so that 
security fixes, bug fixes and improvements aren't too difficult to 
backport to U-Boot. But that's the maintainer's and contributor's 
decision to make :)

> What I loved to do first is perhaps to get the new patchset upstream in u-boot and then change the cmd[xx] logic to a structure in the linux kernel and u-boot ? Syncing both might be a little bit tricky. I also have some performance patches to look at with u-boot (udelay call with a value of 0 is slow and I know useless too)
> 

Typically what happens in open-source projects is that once the code is 
merged, the contributor disappears :) So there's usually reticence to 
merging code if there's some on-going discussion. Here, the struct for 
cmd change suggestion is not a blocker as it's mostly cosmetic anyway 
and it didn't prevent the code from being merged in the kernel (and it 
isn't a bug that we should fix in the kernel), so that's fine with me 
(I'm anyway not the maintainer so I wouldn't have the power to veto this 
:) ).

Cheers,
Quentin