[Cleanup] Remove leftovers of former BOARDFAMILY rk322x (now integrated into the rockchip family)

[ColorfulRhino]

Description

rk322x has long been integrated into the rockchip family in this PR: #6092
Remove some leftovers in the repo, like the old kernel patch folders which are not in use anymore.

@paolosabatino You may have a look at the hardware-optimization script. The tweaks for rk322x do not apply since the BOARDFAMILY does not exist anymore. If you'd like to rather integrate those optimizations in some other way (e.g. integrate them into the rockchip hardware optimizations), feel free to change it :)
Also, please double check if packages/bsp/rk322x/50-rkvdec.rules is not used anymore. At least I could not find any reference when doing a search.

GitHub issue reference: #6821
Jira reference number AR-2392

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules

[paolosabatino]

Thanks for the cleanup. Actually you're right about the hardware optimization script - I should fix it - but the kernel archives were left for "archive" purposes, as long as the general rule is to keep the old LTS kernel patches around to let people bring the thing back if they need.

I don't remember if there is a similar case in other families, but from my point of view they can be purged as well: if someone needs the old things, she can leverage the git history to move back in time. (I also keep a branch in my private fork for that purpose too)

Eventually, the only "leftover" that I would ask you to keep is the hardware optimization thing, I will fix it asap (perhaps tomorrow, this has been a busy week with daily job...) or fix it by yourself if you feel confident, thanks!

[ColorfulRhino]

Thanks for the cleanup. Actually you're right about the hardware optimization script - I should fix it - but the kernel archives were left for "archive" purposes, as long as the general rule is to keep the old LTS kernel patches around to let people bring the thing back if they need.

I'm just curious, was there ever a need to bring back an old kernel? I can see the case for some ancient legacy systems that need to be kept on a certain kernel version for some strange out-of-date or hard to maintain software.
But for "normal" use, the latest kernel should usually be better, shouldn't it? 😄

I don't remember if there is a similar case in other families, but from my point of view they can be purged as well: if someone needs the old things, she can leverage the git history to move back in time. (I also keep a branch in my private fork for that purpose too)

Yes, with Git it won't be lost and can easily be restored if someone wants to :) They will find this PR with an easy GitHub search.

Eventually, the only "leftover" that I would ask you to keep is the hardware optimization thing, I will fix it asap (perhaps tomorrow, this has been a busy week with daily job...) or fix it by yourself if you feel confident, thanks!

Sure no worries! I can try to work it out :) This is why I asked you specifically.

[ColorfulRhino]

@paolosabatino please have a look at the new change and if the removal of the 4.4 kernel stuff in the optimizer is appropriate :)

[paolosabatino]

First of all, thanks a lot!
At first sight, it looks sane to me. I'll be able to make a bit of testing on a live thing tomorrow, but in the meantime feel free to merge!

I'm just curious, was there ever a need to bring back an old kernel? I can see the case for some ancient legacy systems that need to be kept on a certain kernel version for some strange out-of-date or hard to maintain software.

Actually I'm not aware of any case, but I guess it is more probable that their use would be private by single persons necessities rather than for general.

[ColorfulRhino]

First of all, thanks a lot!

Thanks!

At first sight, it looks sane to me. I'll be able to make a bit of testing on a live thing tomorrow, but in the meantime feel free to merge!

Sure, feel free to test whenever you got time. It's not a rush to merge, this is just a little part of a bigger thing: #6820

I'm just curious, was there ever a need to bring back an old kernel? I can see the case for some ancient legacy systems that need to be kept on a certain kernel version for some strange out-of-date or hard to maintain software.

Actually I'm not aware of any case, but I guess it is more probable that their use would be private by single persons necessities rather than for general.

Ah yes. I see your point. But I guess if someone needs it for their private thing, they can always use it e.g. in their userpatches folder or in their fork. I have lots of customizations for my local repo as well 😄
If needed, Git can always bring stuff back, simply by doing a git checkout on an older commit. So I think we should be fine, in favor of a cleaner repository :)