Led config for Horaco ZX-SG4T2 and Optfocus OFS-XF2GT4

[daniel-dona]

Register values taken from the original firmware, tested on the hardware and work as expected.

What's the plan for managing different hardware versions? Some board definition?

[vDorst]

@daniel-dona thank you contribution.
Replacing the current led_config() is not ideal.
Currently we lacking of a infrastructure to set the hardware id/board/features.
The problem is that we currently don't know how many variants we can expect.
Maybe a enum is enough for this but I am not sure or hardware_flags variable.
But I think we have to solve this soon to make it easier to add more features/hardware support.

[logicog]

Maybe for now you could introduce a define in rtl837x_common.h with a board name (say MACHINE_HORACO_ZX_SG4T2) and then compile the led functions accordingly, plus set e.g. the number of SFP ports. There is no need to solve the issue with the boards at this point once and for all. Maybe introduce a define with MACHINE_DEFAULT_4C_2SFP (C for copper) or MACHINE_DEFAULT_8C_1SFP so that the other devices are still supported. This is how it is done in OpenWRT, just that they have a build system that creates all the images at once.

[vDorst]

I am fine with the hardware defines.

[TylerDurden-23]

I tried this PR with the HiSource K0402WS-V3.0 - and the LEDs are working properly with this config.

#86

[diijkstra]

Maybe for now you could introduce a define in rtl837x_common.h with a board name (say MACHINE_HORACO_ZX_SG4T2) and then compile the led functions accordingly, plus set e.g. the number of SFP ports. There is no need to solve the issue with the boards at this point once and for all. Maybe introduce a define with MACHINE_DEFAULT_4C_2SFP (C for copper) or MACHINE_DEFAULT_8C_1SFP so that the other devices are still supported. This is how it is done in OpenWRT, just that they have a build system that creates all the images at once.

I think that is currently the easiest way - at least we will have all the configs in one place, it can be refactored later. How about generic macro MACHINE and just check if any machine is defined around default LED config?

[logicog]

I think that is currently the easiest way - at least we will have all the configs in one place, it can be refactored later. How about generic macro MACHINE and just check if any machine is defined around default LED config?

My previous comment was before the introduction of the machine.h file with the MACHINE defines and machine.c with the respective configuration structures. So one can now re-use these macro definitions for the LEDs, but in addition it would be really cool to have the LED definitions, or if that does not work, the LED setup in the machine.c file, based on the MACHINE macro being defined. Also, the macro definition in machine.h is not really ideal, as it makes building for the different devices difficult (the file is in git, so git will unnecessarily track that you are compiling for a different machine). The better solution as suggested by @vDorst would be to give the machine as a define to make.

[diijkstra]

Crap, missed the dates! Somehow I though this is new attempt! Sorry!