>> 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. 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) >> The benefit of using dev_dbg is when you're having multiple devices from >> the same driver, then you can identify from which one the message is >> being printed. You could have two Wiznet W5500 for example, how do you >> know which one's printing which message? I am going to switch to dev_dbg. I will send the new patchset on Wednesday, as I liked to test it on real hardware before doing so.
