07:32 <mriesch> broonie: thing is that hardware engineers aren't famous for fulfilling expectations...

07:33 <mriesch> for instance, the Ethernet phy voltages aren't always on in our hardware

07:34 <mriesch> so i guess i would need to tell the phy/mac driver not to turn those off at shutdown

07:38 <mriesch> (for wake on LAN)

08:24 <arnd> ardb: as far as I know, mach-lpc32xx is the only supported armv5 with vfp, but it's often used as softfloat because users are not even aware of it being an option, or because they use a binary distro that doesn't have armv5+vfp as a target

08:25 <ardb> arnd: ok so that explains why the CPU_FEROCEON doesn't break anything else in multi_v5

08:25 <ardb> but once you combine v5 and v6, this needs to be fixed

08:26 <arnd> yes, of course. And I expect a number of other bugs like this, where we decided at some point that some combination of features can never happen

08:27 <ardb> 85d6943af50537d3aec58b967ffbd3fec88453e9

08:27 <mvaittin> mriesch: I would expect that the regulators powering the ethernet phy should then have the always-on set. That should be enough to prevent the consumers being able to shut down the regulator.

08:28 <mvaittin> As far as I know the shutdown may not be controlled by consumers in a level of individual regulators though

08:29 <mvaittin> Eg, it may be the shutdown is requested from the PMIC as a 'state transition' - which sets all the power rails to predefined shutdown state.

08:29 <mvaittin> in which case the consumers like phy driver may not have a word on the power state

08:30 <mvaittin> Also, in those cases the always-on is also likely to be ignored

08:30 <mvaittin> but this all probably depends on the PMIC you have

08:34 <arnd> ardb: interesting, I wasn't aware that we support VFP on feroceon-type codes at all. I see it was introduced in e50d64097b6e ("[ARM] Marvell Feroceon CPU core support") but that just explains that the CPU core has the option, though I don't see any reference to a SoC that has it

08:36 <ardb> arnd: the fact that it required a quirk suggests that someone built it

08:37 <ardb> but whether it ever existed in the field, I have no clue

08:37 <arnd> Documentation/arm/marvell.rst has a little more information, explaining that which CPUID values are the ones that can have it. Apparently the later Mohawk/PJ1 no longer had the option but only offered optional iWMMXt that was used only in mach-mmp

08:39 <ardb> iow, we can probably just ignore it

08:40 <ardb> that quirks breaks other VFP implementations rather badly, so perhaps we should just drop the quirk?

08:40 <ardb> doesn

08:40 <ardb> 't seem worth it to make CPU_FEROCEON non-multi-compatible

08:40 <arnd> The #ifdef still has to be addressed, because CPU_FEROCEON + CPU_V6 is exactly the configuration that a Debian kernel for Orion5X+RaspberryPi would use

08:41 <ardb> but Orion5X has no VFP, right?

08:41 <arnd> That was my understanding so far, but I also didn't think that VFP was even an option

08:42 <ardb> so the quirk has to #ifdef on some other kconfig symbol, and that one should prevent it from being in a combined image

08:42 <arnd> There are a couple of Marvell/Feroceon platforms that we never supported upstream, and at least one (mach-loki) that we removed while I was around

08:45 <arnd> Ok, so I was the one who added the information about VFP in the marvell.rst file, meaning I either found a reference on the web at the time, or I made a mistake and just listed VFP for anything that lacks iWMMXt

08:48 <arnd> CPU_FEROCEON_OLD_ID is in a similar category

09:07 <arnd> https://web.archive.org/web/20111110081125/http://www.marvell.com/embedded-processors/discovery-innovation/assets/FS_MV76100_78100_78200_OpenSource.pdf lists the 88FR571-vd core in mv78xx0 has having a "Single-precision and double-precision IEEE compliant FPU", which is presumably VFP

09:08 <arnd> The same document for kirkwood does not list an FPU

09:10 <arnd> If the '-vd' suffix means VFP, dual-issue, then later Orion5x would also have VFP

09:17 <arnd> https://forum.qnap.com/viewtopic.php?t=6309&start=30 has /proc/cpuinfo from "old" 5182 and "new" 5281 variants of Orion5X, confirming that the "new" ones have VFP

09:25 <ardb> ok so it would be nice if we could deal with this in a multi v5/v6 kernel as well

09:35 <mriesch> mvaittin: ah ok, i wasn't sure whether regulator-always-on; would have this effect. in this case i can focus on what the pmic does

09:38 <arnd> ardb: it might be easier to just disallow VFP support on those. I checked every supported machine with the affected SoCs now, and found that there are none with DT support and only three remaining board files in linux-6.3, after I just removed the five unused ones

09:39 <arnd> terastation_pro2, ts409 and buffalow-wxl are the remaining ones.

09:40 <ardb> arnd: VFP detection uses undef trapping, so we'd have to add an explicit platform type check

09:49 <mvaittin> mriesch: I think the regulator core should prevent consumers from disabling always-on regulators.

09:52 <arnd> ardb: I'll ask on #miraheze-bufalonas if anyone is actually still using one the three machines with new kernels (I guess yes) and if they have ever used the FPU (I guess no). Fairly sure nobody else is doing it. We had one person asking about debian on another orion5x this year, but they ended up installing an Debian oldoldstable because of memory limitations

09:58 <ardb> arnd: so without the quirk, VFP on Feroceon doesn't work quite as expected (it keeps restarting the same instruction until it is interrupted for another reason) but at least it doesn't corrupt the data

10:01 <arnd> ok, good to know. So the question then is how much effort we would spend on turning an endless loop into a SIGILL

10:01 <arnd> ardb: is there a way to hard-disable the VFP in cpu_feroceon_proc_init() through some register?

10:02 <ardb> good question

10:02 <ardb> ah yes here is

10:02 <ardb> just call vfp_disable

11:08 <broonie> mriesch: Right, if the PHY is supposed to be wake on LAN then powering it off seems like a driver bug.

11:11 <broonie> always-on would fix it.

11:12 <broonie> But the driver probably shouldn't be doing that at all.

12:18 <arnd> ardb: 1000001101000 on #miraheze-bufalonas confirmed that they are still using two of the three machines, as well as providing debian images for them, but they don't mind having the FPU disabled as nobody is using it with Debian armel

12:38 <ardb> arnd: armhf, right?

12:39 <ardb> ok so we could either rip it out right away, or wait until the v5/v6 thing materializes

12:42 <arnd> Clearly they are not using armhf as it's a v5. I meant they are not using any code on armel that was compiled with -march=armv5te+fp -mfloat-abi=soft-fp, which I think would work right now if they tried.

12:44 <ardb> ah yes, probably