@jow i hope i'm not tagging the wrong person....
I can't understand the way swconfig handle port change?
Does it use a pool method? Does it use an interrupt and check the status based on that? I can't really understand and find anything about it. I hope you can help me as i'm trying to reduce the various call to check port status for the dsa driver.
Well DSA uses phylink for that kind of stuff, not? Anyway, with swconfig I'm not sure but I believe there was polling involved.
yes but the phy state is checked with polling... i can't understand as i checked at times the phy access and with swconfig we had some access only at the start but they then stopped.... so i wonder if other type of source were used...
Also i can't really understand why oem doesn't use the switch interrupt... it would be so useful and handy... (aka possibility to not use expensive polling mode)
I actually wouldnt be surprised if the interrupt pin is actually connected on most of the boards but simply not defined in the DTS.
I mean QCA are not the ones to waste CPU cycles on polling the ports instead.
This is way too common on a lot of boards I worked recently, they used Marvell switches but its the same thing.
Its just almost impossible knowing which pin it is without schematics.
1 Like
that would confirm my fear... the interrupt is actually connected but nobody pool that.... do we have a list of the total interrupt available? switch interrupt are fully configurable so i wonder if we can find it by chance... that would massively improve port status perf
we have the switch pin... it's described in the datasheet. but no way to get the router schematics... also i can't find any source in the original source
If the polling is not so frequent to know the ports status, I think the driver programmer has chosen an easier way. It depends so on the cost of polling.
Indeed, an interrupt handler would be more efficient, but the handler would have to throw an event to the Operation System and that should depend on which OS or even which version of said OS.
Oh, remember my young age dealing with spurious interrupts.
In this case, Linux and more precisely networking subsystems already have the generic solution for handling interrupts so it's really dead simple if you can provide it with an interrupt source which is usually just a GPIO controller as almost all relatively modern SoC-s have interrupt-based GPIO-s.
Yeah, exactly. I was actually thinking of instrumenting something in this direction. One board I worked with I just did GPIO keys for all available SoC pins and then toggled e.g. switches and stuff to figure out which pin is which. I guess, most interrupts from some secondary chips could somehow be triggered in software as well. Or those chip's interrupt pins might even be reconfigurable as a GPIO. It's just quite some effort to figure this all out. But if no stock device tree is available resp. they hard coded any such in proprietary user space then it might be pretty much the only way to ever figure that thing out.
That wont really work with figuring out the INT pin of the external switch.
They are active LOW and have a pull-up of course, and its not reconfigurable at least on QCA8337.
Only way would be to scope the pin on the switch and then go setting GPIOs to LOW on the SoC
Sure, but why should that not work? If I have active-low GPIO keys on all SoC GPIOs and now e.g. plug in an Ethernet cable so the switch triggers an interrupt towards the SoC. That should work, not?
Crazy idea register tons of interrupt for the switch and check who is triggered
Set the switch to send interrupt on port change for example
It can work?
Yes, exactly my thinking.
I mean I suppose it can work, but you are gonna have a lot of false positives as there are GPIO pins usually connected to all kinds of stuff that is not described in DTS/Not used.
Also, you have to catch it somehow as I don't think that kernel monitors the IRQ-s for GPIO pins unless they are the interrupt source somewhere. (Maybe there is some kind of a debug mode)
Probing the INT pin on the switch seems nearly impossible due to the pitch.
Also, interrupts need to be enabled on the switch as they are disabled by default.
We have documentation for the switch so we can sets all the correct values... When I have time I will try to assign all the unused interrupt to the switch and sets the switch on something very specific...
By default is disabled so the idea is to set it to something specific... Like port change and check if some interrupt stats makes sense.
It's easy to enable them, that's not the hard part.
Also, don't equate them to PHY interrupts, those are only part of the things that the switch can throw the interrupt for.
I will check my Asrock G10 to see what reference design its based on and then I can take a look at schematics for the reference design, maybe the used the same pin
The idea is to set the interrupt only to that so we know the correct one if this ""brute force"" way works
(The idea is having nothing connected at the start. Check interrupts at zero, attach an ethrnet port and check the interrupts stats)
I understand, simply enable the link state change in PHY interrupt enable register, then enable PHY interrupts in the switch interrupt register.
But the trick is that the kernel only cares about IRQ-s that have consumers, its not gonna waste resources for handling others, so you cant just see interrupts from all GPIO pins
Mod the switch driver to register as a consumer?
But you only consume one IRQ of the GPIO controller, not all of them so you will see only the one you requested
Register multiple one? Anyway it would be a miracle if there is some reference in the reference design