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
