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://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
