Messages in this thread | | | Date | Thu, 21 Mar 2024 20:22:05 +0100 | From | Andrew Lunn <> | Subject | Re: [EXTERNAL] Re: [PATCH v2 0/5] Fix prestera driver fail to probe twice |
| |
> Originally, the pain point for Kory was the rmmod + insmod re-probing failure, > Which is only fixed by the first two commits, so I see little point in submitting 3-5 alone, > Without fixing Kory's problem.
I thought Kory's problem was actually EPROBE_DEFER? The resources needed for the PoE are not available, so probing the switch needs to happen again later, when PoE can get the resources it needs.
But if that is going to take 30 seconds, i'm not sure we can call EPROBE_DEFER solved.
The later patches are pretty simple, don't need discussion, so could be merged. However, i think we need to explore different possible solutions for firmware {re}loading.
> The problem is not with the hardware, but with the existing firmware code on the > Firmware cpu, most probably secure-boot protected, which lacks the ABIs to report to > The kernel what is loaded, what version, what state, etc.
Can you at least tell if it is running firmware?
Can you explain the boot in a bit more detail. Are you saying it could be running an old firmware when the driver first loads? So you need to hit it with a reset in order to load the firmware for /lib/firmware, which might be newer than what it is already running?
That would imply the device has FLASH and has a copy of firmware in it? And if that is true, i think that also implies you have no way to upgrade the image in FLASH? Otherwise you would implement "devlink flash" to allow it to be upgraded. You then would not need to load the firmware on driver probe....
Andrew
| |