Add support for HiSource K0402WS-V3.0.

[TylerDurden-23]

As discussed in #86.

The magic number LED approach is taken from #44 and can be reused there.

[logicog]

Could you give PR #107 a try regarding the LED configuration? I see that the LED-pads are configured very differently, but the logical side, i.e. the led-sets and the led-ids could already be adapted. This then allows to assign different functions to the LEDs.

I will have to look into what to do about the LED-pads, which is the hardware configuration side, whereas the ledids/ledsets are the logic for the ASIC...

[logicog]

I had thought, that maybe the values for RTL837X_REG_LED_GLB_MUX_1, RTL837X_REG_LED_GLB_MUX_2... were just default values from your version of the SoC, because there is no way these can be configured using at least the GPL-dumped SDK. Now, looking into your dumped flash, I see a routine which sets meticulously one LED-pad after the other using the rtl8373_setAsicRegBits function. So this is for real. The next problem is, there is no documentation for these settings...

I will look how to set this up in machine.c.

[TylerDurden-23]

@logicog I tried the PR - and as expected it is not working correctly. I can only get 4 of the needed 12 needed LEDs working.

[logicog]

Did you add the correct numbers for the LED-pad values in a "magic" configuration routine, or are already the LED-sets wrong? In the discussion for PR #107 it seems we may configure just the LED-sets with the de-magiced setup, but keep unstructured values for the LED-pads. But I am also working on configuring those via a mapping table pad <-> LED.

[TylerDurden-23]

@logicog A "combined" approach seems to work - I can strip down the magic number function to:

	REG_SET(RTL837X_REG_LED_GLB_MUX_1, 0x08144040);
	REG_SET(RTL837X_REG_LED_GLB_MUX_2, 0x1037f309);
	REG_SET(RTL837X_REG_LED_GLB_MUX_3, 0x12454391);
	REG_SET(RTL837X_REG_LED_GLB_MUX_4, 0x19616555);
	REG_SET(RTL837X_REG_LED_GLB_MUX_5, 0x1c79d65a);
	REG_SET(RTL837X_REG_LED_GLB_MUX_6, 0x0002181d);

Plus run your new configuration, and I get a functional though not totally identical led signaling.

[logicog]

You should be able to replace even the REG_SET(RTL837X_REG_LED_GLB_MUX_1-6, xy); with the correct setting for you device:

.led_mux_custom = 1,
	.led_mux = { 0x00, 0x01, 0x...},

6 bits of the LED_GLB_MUX registers give one of the entries in the .led_mux list. You can get them by configuring these register using the magic numbers during boot, and then printing them out once via leds_dump() and then putting the printed out list into .led_mux. Then you no longer need the magic numbers. Possibly with the exception of RTL837X_REG_LED_GLB_ACTIVE.

[logicog]

@logicog A "combined" approach seems to work - I can strip down the magic number function to:

There is now a custom machine init function in the General LED setup PR. If you still need that, it should get you there.

[TylerDurden-23]

@logicog Currently it does not look like that is needed for the K0402WS.

[logicog]

@logicog Currently it does not look like that is needed for the K0402WS.

Perfect! Sounds like that both PRs are on the right way. For the PR #107 we will need to see whether the offered options are really all that is needed to support the LEDs of all the currently known devices, and there is that switch from @vDorst that still is resisting our efforts.

[logicog]

A comment on the merges from main into this PR. To get a clean PR, many people use the following strategy:
Create branch from main. Put the first commits inside. If new commits are done in "main", you do:

git fetch upstream
git rebase -i upstream/main # this adds your commits on top of the changes in "main"
git push -f remote main # this updates the existing PR

If you need to change a PR, you can do:

git add fixed_file.c
git commit -m fix
git rebase -i HEAD~<AS_MUCH_AS_YOU_NEED_TO_GO_BACK>
# use f instead of "pick" to update the previous commit
git push -f remote main # this updates the existing PR

This way your commits always sit on top of the current main, and only those are seen in the PR.

[TylerDurden-23]

This is ready for merge now.
Interestingly to get both LEDs for both SFP port working, I needed to set another bit in the RTL837X_REG_LED_GLB_IO_EN register.

[vDorst]

@TylerDurden-23 this PR looks good, one question: Could you also make some documentation about your device, like a PCB photo and a simple markdown file? See examples in the doc/devices.

[TylerDurden-23]

@vDorst The PCB photos are already committed.

[vDorst]

That is great, would you like to make a small/simple document about the device?

[TylerDurden-23]

@vDorst Added a small documentation.

[vDorst]

Thanks you very much!

[logicog]

I just see

	.is_sfp = {0, 0, 0, 1, 0, 0, 0, 0, 1},

this not correct, but I guess I prompted that due to me incorrectly naming that variable. The numbers may be 0, 1, 2, where 0 is not an SFP, 1 is the left SFP port and 2 is the right port. This associates a port with the respective SFP cage.

[TylerDurden-23]

@logicog
This happened during review, you could remove:
98f3f15

[logicog]

Sorry, I did not pay enough attention, there was a misunderstanding about the role of the variable. See also PR #122 . I don not think it is possible to just remove a commit. And probably it would not be good practice, as it is no longer traceable. Can you make a PR for this? Sorry for the additional work :-(

[TylerDurden-23]

@logicog I create a new PR.