create a common poe module #127
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In preparation of moving shared code into its own library module, merge the PoE driver packages into one. The AS4610 driver depends on the SERIAL_DEV_BUS code, so guard its compilation against that. Detect the PoE device path at run time based on the running onl_platform. Signed-off-by: Jonas Gorski <[email protected]>
Move MCU opcodes to a shared header file to reduce code duplication. Signed-off-by: Jonas Gorski <[email protected]>
Create a shared library module with a common send function to allow sharing more code between both PoE modules. Signed-off-by: Jonas Gorski <[email protected]>
Make use of the newly added common message code, and replace the send function with a simplified version. Signed-off-by: Jonas Gorski <[email protected]>
Make use of the newly added common message code, and replace the send function with a simplified version. Signed-off-by: Jonas Gorski <[email protected]>
The mutex is needed by both implementations, so move it to the common struct. Signed-off-by: Jonas Gorski <[email protected]>
Both implementations need to keep track of ports, so replace the indivdual port structs with a shared one in the common code. Signed-off-by: Jonas Gorski <[email protected]>
Now that the common struct contains all required information, we can create shared debugfs code in the common module. Signed-off-by: Jonas Gorski <[email protected]>
Instead of having our own copy, use the shared module's debugfs code. Signed-off-by: Jonas Gorski <[email protected]>
Instead of having our own copy, use the shared module's debugfs code. Signed-off-by: Jonas Gorski <[email protected]>
Create a generic init function to handle initializing the common struct and allocating and initializing the port list based on the chip's reported amount of ports. Signed-off-by: Jonas Gorski <[email protected]>
Make use of the generic init function instead of doing all the stuff ourselves. Signed-off-by: Jonas Gorski <[email protected]>
For as4610 we need to check the stored MCU's port map config, so add an optional callback to do allow doing that. Signed-off-by: Jonas Gorski <[email protected]>
Make use of the generic init code and move the port map check/init into the newly added config_check call back. Since this code is called before the port array is initialized, directly use the device tree data for initializing the port map instead of populating the ports. Signed-off-by: Jonas Gorski <[email protected]>
Add helper functions for sending multi port commands that can target up to four ports, with the assumption to set the same value for all. Signed-off-by: Jonas Gorski <[email protected]>
Let the generic code initialze ports to their default setup, and drop the appriate code from the machine specific modules. While at it, drop the "support" for enabling them by default. We never enabled it, and it is safer it we let the userspace enable them, instead of potentially powering up a device just to disable it a few second later when userspace applies a configuration that disables a port. Signed-off-by: Jonas Gorski <[email protected]>
Signed-off-by: Jonas Gorski <[email protected]>
Call the common remove on exit to disable the ports. Signed-off-by: Jonas Gorski <[email protected]>
Call the common remove on exit to disable the ports. Signed-off-by: Jonas Gorski <[email protected]>
Add a callback for globabally toggling power to ports. In theory this should be provided through a regulator, but this would require rewriting the CPLD drivers. So for now use the non-standard approach. Signed-off-by: Jonas Gorski <[email protected]>
Add a callback for toggling the power bit on the CPLD, and drop toggling it from the as4610 driver. Signed-off-by: Jonas Gorski <[email protected]>
Add a callback for toggling the power bit on the CPLD, and drop toggling it from the as4630-54pe driver. Signed-off-by: Jonas Gorski <[email protected]>
Now that the common code does the full (de-)initialization, we can also let it take care of creating and removing the debugfs. Signed-off-by: Jonas Gorski <[email protected]>
Add support for setting the guardband and lower limits based on the provided PSU rating from the machine drivers. Signed-off-by: Jonas Gorski <[email protected]>
Let the common code take care of initializing the guardbands based on the newly added code. Signed-off-by: Jonas Gorski <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently there is a lot of code duplication between the as4610 and as4630 PoE modules.
Reduce code duplication by creating a common library module that will contain the common code, while abstracting out any bus/platform specific code in callbacks.
The original modules still remain, but all they do is provide the appropriate callbacks, then use the common library. The poe script is adapted to handle the correct path based on the machine being run on.
This makes future improvements and bug fixes much less costly, ass only one file needs to be updated, and not two. This also makes it impossible to only fix/update one of the two modules.
Future possible improvements: