On Sun, 2022-06-05 at 20:50 +0200, Andrew Lunn wrote:
On Thu, Jun 02, 2022 at 06:01:08PM +0000, Joakim Tjernlund wrote:
On Thu, 2022-06-02 at 10:52 -0700, Jakub Kicinski wrote:
On Thu, 2 Jun 2022 17:15:13 +0000 Joakim Tjernlund wrote:
What is "our HW", what kernel driver does it use and why can't the kernel driver take care of making sure the device is not accessed when it'd crash the system?
It is a custom asic with some homegrown controller. The full config path is too complex for kernel too know and depends on user input.
We have a long standing tradition of not caring about user space drivers in netdev land. I see no reason to merge this patch upstream.
This is not a user space driver. View it as a eth controller with a dum PHY which cannot convey link status. The kernel driver then needs help with managing carrier.
Please post the MAC driver then. We don't really like changes to the kernel without a user. You MAC driver would be such a user.
That driver is far from kernel proper/upstream worthy ..
Could you also tell us more about the PHY. What capabilities does it have? I assume it is not C22 compatible. Does it at least have some sort of indicator of link? What might make sense is to use the
There is no PHY really, from kernels POV it is just a DMA engine and all the setup needed to setup the full path is in US.
fixed-link code. You can provide a callback which gives the actual link status up/down. And the fixed-link driver looks like a real PHY, so the MAC driver does not need to do anything special.
The fixed PHY has the same problem as it uses the same sysfs I/F. I am just asking that the sysfs carrier I/F should be writeable and readable when I/F is DOWN. Now one cannot even read carrier status when I/F is down.
Andrew