kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-15 19:56:03 +00:00
Code Issues Releases Packages Activity
linux/drivers/net/ipa/ipa_cmd.c

648 lines
21 KiB
Raw Normal View History

soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: include some standard header files Some IPA header files use types defined in <linux/types.h>, but do not include that file: - In "ipa_mem.h", the ipa_mem structure has u16 and u32 fields - In "ipa_power.h", ipa_power_retention() takes a bool argument, and ipa_core_clock_rate() returns u32 - In "ipa_version.h", ipa_version_supported() returns bool Include it in these files to satisfy their dependencies. The ipa_qmi structure (defined in "ipa_qmi.h") contains a work structure, so include <linux/workqueue.h> in there. All of the data and register definition files, as well as "reg.h", use the ARRAY_SIZE() macro. Include <linux/array_size.h> everywhere it's used. Similarly, all register definition files (and a few others) use the GENMASK() macro, so include <linux/bits.h> to ensure it's defined where used. BIT() becomes available by including this file also. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-04-16 18:10:12 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: sort all includes Establish the rule that header files are always included in sorted (POSIX local) order. Standard and private headers are separated by a blank line. Similarly, sort all forward-declarations for structures. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-04-16 18:10:18 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: sort all includes Establish the rule that header files are always included in sorted (POSIX local) order. Standard and private headers are separated by a blank line. Similarly, sort all forward-declarations for structures. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-04-16 18:10:18 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: sort all includes Establish the rule that header files are always included in sorted (POSIX local) order. Standard and private headers are separated by a blank line. Similarly, sort all forward-declarations for structures. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-04-16 18:10:18 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: sort all includes Establish the rule that header files are always included in sorted (POSIX local) order. Standard and private headers are separated by a blank line. Similarly, sort all forward-declarations for structures. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-04-16 18:10:18 -05:00
net: ipa: include "ipa_interrupt.h" where needed The IPA structure contains an ipa_interrupt structure pointer, and that structure is declared in "ipa.h". There is no need to include "ipa_interrupt.h" in that header file. Instead, include "ipa_interrupt.h" in the three source files (in addition to "ipa_main.c") that actually use the functions that are declared there. Similarly, three files use symbols defined in "ipa_reg.h" but do not include that file; include it. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-04-16 18:10:14 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: kill gsi_trans_commit_wait_timeout() Since the beginning gsi_trans_commit_wait_timeout() has existed to provide a way to allow waiting a limited time for a transaction to complete. But that function has never been used. In fact, there is no use for this function, because a transaction committed to hardware should *always* complete. The only reason it might not complete is if there were a hardware failure, or perhaps a system configuration error. Furthermore, if a timeout ever did occur, the IPA hardware would be in an indeterminate state, from which there is no recovery. It would require some sort of complete IPA reset, and would require the participation of the modem, and at this time there is no such sequence defined. So get rid of the definition of gsi_trans_commit_wait_timeout(), and update a few comments accordingly. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-05-21 19:32:18 -05:00
net: ipa: update comments This patch just updates comments throughout the IPA code. Transaction state is now tracked using indexes into an array rather than linked lists, and a few comments refer to the "old way" of doing things. The description of how transactions are used was changed to refer to "operations" rather than "commands", to (hopefully) remove a possible ambiguity. IPA register offsets and fields are now handled differently as well, and the register documentation is updated to better describe the code. A few minor updates to comments were made (e.g., adding a missing word, fixing a typo or punctuation, etc.). Finally, the local macro atomic_dec_not_zero() is no longer used, so it is deleted. Signed-off-by: Alex Elder <elder@linaro.org> Link: https://lore.kernel.org/r/20220930224527.3503404-1-elder@linaro.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-30 17:45:27 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: define enumerated types consistently Consistently define numeric values for enumerated type members using hexidecimal (rather than decimal) format values. Align the values assigned in the same column in each file. Only assign values where they really matter, for example don't assign IPA_ENDPOINT_AP_MODEM_TX the value 0. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-16 17:38:01 -06:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: reduce IPA version assumptions Modify conditional tests throughout the IPA code so they do not assume that IPA v3.5.1 is the oldest version supported. Also remove assumptions that IPA v4.5 is the newest version of IPA supported. Augment versions in comments with "+", to be clearer that the comment applies to a version and subsequent versions. (E.g., "present for IPA v4.2+" instead of just "present for v4.2".) Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-24 08:15:23 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: reduce IPA version assumptions Modify conditional tests throughout the IPA code so they do not assume that IPA v3.5.1 is the oldest version supported. Also remove assumptions that IPA v4.5 is the newest version of IPA supported. Augment versions in comments with "+", to be clearer that the comment applies to a version and subsequent versions. (E.g., "present for IPA v4.2+" instead of just "present for v4.2".) Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-24 08:15:23 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: reduce IPA version assumptions Modify conditional tests throughout the IPA code so they do not assume that IPA v3.5.1 is the oldest version supported. Also remove assumptions that IPA v4.5 is the newest version of IPA supported. Augment versions in comments with "+", to be clearer that the comment applies to a version and subsequent versions. (E.g., "present for IPA v4.2+" instead of just "present for v4.2".) Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-24 08:15:23 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: reduce IPA version assumptions Modify conditional tests throughout the IPA code so they do not assume that IPA v3.5.1 is the oldest version supported. Also remove assumptions that IPA v4.5 is the newest version of IPA supported. Augment versions in comments with "+", to be clearer that the comment applies to a version and subsequent versions. (E.g., "present for IPA v4.2+" instead of just "present for v4.2".) Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-24 08:15:23 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: reduce IPA version assumptions Modify conditional tests throughout the IPA code so they do not assume that IPA v3.5.1 is the oldest version supported. Also remove assumptions that IPA v4.5 is the newest version of IPA supported. Augment versions in comments with "+", to be clearer that the comment applies to a version and subsequent versions. (E.g., "present for IPA v4.2+" instead of just "present for v4.2".) Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-24 08:15:23 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: extend endpoints in packet init command The IP_PACKET_INIT immediate command defines the destination endpoint to which a packet should be sent. Prior to IPA v5.0, a 5 bit field in that command represents the endpoint, but starting with IPA v5.0, the field is extended to 8 bits to support more than 32 endpoints. Signed-off-by: Alex Elder <elder@linaro.org> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-30 15:01:52 -06:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: extend endpoints in packet init command The IP_PACKET_INIT immediate command defines the destination endpoint to which a packet should be sent. Prior to IPA v5.0, a 5 bit field in that command represents the endpoint, but starting with IPA v5.0, the field is extended to 8 bits to support more than 32 endpoints. Signed-off-by: Alex Elder <elder@linaro.org> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-30 15:01:52 -06:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: reduce IPA version assumptions Modify conditional tests throughout the IPA code so they do not assume that IPA v3.5.1 is the oldest version supported. Also remove assumptions that IPA v4.5 is the newest version of IPA supported. Augment versions in comments with "+", to be clearer that the comment applies to a version and subsequent versions. (E.g., "present for IPA v4.2+" instead of just "present for v4.2".) Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-24 08:15:23 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: determine route table size from memory region Currently we assume that any routing table contains a fixed number of entries. The number of entries in a routing table can actually vary, depending only on the size of the IPA-local memory region used to hold the table. Stop assuming that a routing table has exactly 15 entries. Instead, determine the number of entries in a routing table by dividing its memory region size by the size of an entry. The number of entries is computed early, when ipa_table_mem_valid() is called by ipa_table_init(). Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-10-25 14:51:41 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: fix ipa_cmd_table_valid() Stop supporting different sizes for hashed and non-hashed filter or route tables. Add BUILD_BUG_ON() calls to verify the sizes of the fields in the filter/route table initialization immediate command are the same. Add a check to ipa_cmd_table_valid() to ensure the size of the memory region being checked fits within the immediate command field that must hold it. Remove two Boolean parameters used only for error reporting. This actually fixes a bug that would only show up if IPA_VALIDATE were defined. Define ipa_cmd_table_valid() unconditionally (no longer dependent on IPA_VALIDATE). Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-26 12:40:07 -05:00
net: ipa: use WARN_ON() rather than assertions I've added commented assertions to record certain properties that can be assumed to hold in certain places in the IPA code. Convert these into real WARN_ON() calls so the assertions are actually checked, using the standard WARN_ON() mechanism. Where errors can be returned, return an error if a warning is triggered. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-26 12:40:10 -05:00
net: ipa: support more endpoints Increase the number of endpoints supported by the driver to 36, which IPA v5.0 supports. This makes it impossible to check at build time whether the supported number is too big to fit within the (5-bit) PACKET_INIT destination endpoint field. Instead, convert the build time check to compare against what fits in 8 bits. Add a check in ipa_endpoint_config() to also ensure the hardware reports an endpoint count that's in the expected range. Just open-code 32 as the limit (the PACKET_INIT field mask is not available where we'd want to use it). Signed-off-by: Alex Elder <elder@linaro.org> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-30 15:01:51 -06:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: verify table sizes fit in commands early We currently verify the table size and offset fit in the immediate command fields that must encode them in ipa_table_valid_one(). We can now make this check earlier, in ipa_table_mem_valid(). The non-hashed IPv4 filter and route tables will always exist, and their sizes will match the IPv6 tables, as well as the hashed tables (if supported). So it's sufficient to verify the offset and size of the IPv4 non-hashed tables fit into these fields. Rename the function ipa_cmd_table_init_valid(), to reinforce that it is the TABLE_INIT immediate command fields we're checking. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-10-21 14:13:37 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: fix ipa_cmd_table_valid() Stop supporting different sizes for hashed and non-hashed filter or route tables. Add BUILD_BUG_ON() calls to verify the sizes of the fields in the filter/route table initialization immediate command are the same. Add a check to ipa_cmd_table_valid() to ensure the size of the memory region being checked fits within the immediate command field that must hold it. Remove two Boolean parameters used only for error reporting. This actually fixes a bug that would only show up if IPA_VALIDATE were defined. Define ipa_cmd_table_valid() unconditionally (no longer dependent on IPA_VALIDATE). Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-26 12:40:07 -05:00
net: ipa: don't save the platform device The IPA platform device is now only used as the structure containing the IPA device structure. Replace the platform device pointer with a pointer to the device structure. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-03-01 11:02:42 -06:00
net: ipa: determine route table size from memory region Currently we assume that any routing table contains a fixed number of entries. The number of entries in a routing table can actually vary, depending only on the size of the IPA-local memory region used to hold the table. Stop assuming that a routing table has exactly 15 entries. Instead, determine the number of entries in a routing table by dividing its memory region size by the size of an entry. The number of entries is computed early, when ipa_table_mem_valid() is called by ipa_table_init(). Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-10-25 14:51:41 -05:00
net: ipa: determine filter table size from memory region Currently we assume that any filter table contains a fixed number of entries. Like routing tables, the number of entries in a filter table is limited only by the size of the IPA-local memory region used to hold the table. Stop assuming that a filter table has exactly 14 entries. Instead, determine the number of entries in a routing table by dividing its memory region size by the size of an entry. (Note that the first "entry" in a filter table contains an endpoint bitmap.) Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-10-25 14:51:43 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: fix ipa_cmd_table_valid() Stop supporting different sizes for hashed and non-hashed filter or route tables. Add BUILD_BUG_ON() calls to verify the sizes of the fields in the filter/route table initialization immediate command are the same. Add a check to ipa_cmd_table_valid() to ensure the size of the memory region being checked fits within the immediate command field that must hold it. Remove two Boolean parameters used only for error reporting. This actually fixes a bug that would only show up if IPA_VALIDATE were defined. Define ipa_cmd_table_valid() unconditionally (no longer dependent on IPA_VALIDATE). Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-26 12:40:07 -05:00
net: ipa: determine route table size from memory region Currently we assume that any routing table contains a fixed number of entries. The number of entries in a routing table can actually vary, depending only on the size of the IPA-local memory region used to hold the table. Stop assuming that a routing table has exactly 15 entries. Instead, determine the number of entries in a routing table by dividing its memory region size by the size of an entry. The number of entries is computed early, when ipa_table_mem_valid() is called by ipa_table_init(). Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-10-25 14:51:41 -05:00
net: ipa: fix ipa_cmd_table_valid() Stop supporting different sizes for hashed and non-hashed filter or route tables. Add BUILD_BUG_ON() calls to verify the sizes of the fields in the filter/route table initialization immediate command are the same. Add a check to ipa_cmd_table_valid() to ensure the size of the memory region being checked fits within the immediate command field that must hold it. Remove two Boolean parameters used only for error reporting. This actually fixes a bug that would only show up if IPA_VALIDATE were defined. Define ipa_cmd_table_valid() unconditionally (no longer dependent on IPA_VALIDATE). Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-26 12:40:07 -05:00
net: ipa: determine route table size from memory region Currently we assume that any routing table contains a fixed number of entries. The number of entries in a routing table can actually vary, depending only on the size of the IPA-local memory region used to hold the table. Stop assuming that a routing table has exactly 15 entries. Instead, determine the number of entries in a routing table by dividing its memory region size by the size of an entry. The number of entries is computed early, when ipa_table_mem_valid() is called by ipa_table_init(). Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-10-25 14:51:41 -05:00
net: ipa: fix ipa_cmd_table_valid() Stop supporting different sizes for hashed and non-hashed filter or route tables. Add BUILD_BUG_ON() calls to verify the sizes of the fields in the filter/route table initialization immediate command are the same. Add a check to ipa_cmd_table_valid() to ensure the size of the memory region being checked fits within the immediate command field that must hold it. Remove two Boolean parameters used only for error reporting. This actually fixes a bug that would only show up if IPA_VALIDATE were defined. Define ipa_cmd_table_valid() unconditionally (no longer dependent on IPA_VALIDATE). Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-26 12:40:07 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: fix ipa_cmd_table_valid() Stop supporting different sizes for hashed and non-hashed filter or route tables. Add BUILD_BUG_ON() calls to verify the sizes of the fields in the filter/route table initialization immediate command are the same. Add a check to ipa_cmd_table_valid() to ensure the size of the memory region being checked fits within the immediate command field that must hold it. Remove two Boolean parameters used only for error reporting. This actually fixes a bug that would only show up if IPA_VALIDATE were defined. Define ipa_cmd_table_valid() unconditionally (no longer dependent on IPA_VALIDATE). Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-26 12:40:07 -05:00
net: ipa: fix init header command validation We use ipa_cmd_header_valid() to ensure certain values we will program into hardware are within range, well in advance of when we actually program them. This way we avoid having to check for errors when we actually program the hardware. Unfortunately the dev_err() call for a bad offset value does not supply the arguments to match the format specifiers properly. Fix this. There was also supposed to be a check to ensure the size to be programmed fits in the field that holds it. Add this missing check. Rearrange the way we ensure the header table fits in overall IPA memory range. Finally, update ipa_cmd_table_valid() so the format of messages printed for errors matches what's done in ipa_cmd_header_valid(). Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-20 09:17:28 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: introduce ipa_cmd_init() Currently, ipa_cmd_data_valid() is called by ipa_mem_config(). Nothing it does requires access to hardware though, so it can be done during the init phase of IPA driver startup. Create a new function ipa_cmd_init(), whose purpose is to do early initialization related to IPA immediate commands. It will call the build-time validation function, then will make the two calls made previously by ipa_cmd_data_valid(). This make ipa_cmd_data_valid() unnecessary, so get rid of it. Rename ipa_cmd_header_valid() to be ipa_cmd_header_init_local_valid(), so its name is clearer about which IPA immediate command it is associated with. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-10-21 14:13:38 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: don't save the platform device The IPA platform device is now only used as the structure containing the IPA device structure. Replace the platform device pointer with a pointer to the device structure. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-03-01 11:02:42 -06:00
net: ipa: clean up header memory validation Do some general cleanup in ipa_cmd_header_valid(): - Delay assigning the mem variable until just before it's used. - Assign the maximum offset and size values together. - Improve comments explaining the single range of memory being made up of a modem portion and an AP portion. - Record the offset of the combined range in a local variable. - Do the initial size assignment right after assigning the offset. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-10 14:23:02 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: clean up header memory validation Do some general cleanup in ipa_cmd_header_valid(): - Delay assigning the mem variable until just before it's used. - Assign the maximum offset and size values together. - Improve comments explaining the single range of memory being made up of a modem portion and an AP portion. - Record the offset of the combined range in a local variable. - Do the initial size assignment right after assigning the offset. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-10 14:23:02 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: clean up header memory validation Do some general cleanup in ipa_cmd_header_valid(): - Delay assigning the mem variable until just before it's used. - Assign the maximum offset and size values together. - Improve comments explaining the single range of memory being made up of a modem portion and an AP portion. - Record the offset of the combined range in a local variable. - Do the initial size assignment right after assigning the offset. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-10 14:23:02 -05:00
net: ipa: fix init header command validation We use ipa_cmd_header_valid() to ensure certain values we will program into hardware are within range, well in advance of when we actually program them. This way we avoid having to check for errors when we actually program the hardware. Unfortunately the dev_err() call for a bad offset value does not supply the arguments to match the format specifiers properly. Fix this. There was also supposed to be a check to ensure the size to be programmed fits in the field that holds it. Add this missing check. Rearrange the way we ensure the header table fits in overall IPA memory range. Finally, update ipa_cmd_table_valid() so the format of messages printed for errors matches what's done in ipa_cmd_header_valid(). Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-20 09:17:28 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: clean up header memory validation Do some general cleanup in ipa_cmd_header_valid(): - Delay assigning the mem variable until just before it's used. - Assign the maximum offset and size values together. - Improve comments explaining the single range of memory being made up of a modem portion and an AP portion. - Record the offset of the combined range in a local variable. - Do the initial size assignment right after assigning the offset. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-10 14:23:02 -05:00
net: ipa: introduce ipa_mem_find() Introduce a new function that abstracts finding information about a region in IPA-local memory, given its memory region ID. For now it simply uses the region ID as an index into the IPA memory array. If the region is not defined, ipa_mem_find() returns a null pointer. Update all code that accesses the ipa->mem[] array directly to use ipa_mem_find() instead. The return value must be checked for null when optional memory regions are sought. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-10 14:23:07 -05:00
net: ipa: clean up header memory validation Do some general cleanup in ipa_cmd_header_valid(): - Delay assigning the mem variable until just before it's used. - Assign the maximum offset and size values together. - Improve comments explaining the single range of memory being made up of a modem portion and an AP portion. - Record the offset of the combined range in a local variable. - Do the initial size assignment right after assigning the offset. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-10 14:23:02 -05:00
net: ipa: fix init header command validation We use ipa_cmd_header_valid() to ensure certain values we will program into hardware are within range, well in advance of when we actually program them. This way we avoid having to check for errors when we actually program the hardware. Unfortunately the dev_err() call for a bad offset value does not supply the arguments to match the format specifiers properly. Fix this. There was also supposed to be a check to ensure the size to be programmed fits in the field that holds it. Add this missing check. Rearrange the way we ensure the header table fits in overall IPA memory range. Finally, update ipa_cmd_table_valid() so the format of messages printed for errors matches what's done in ipa_cmd_header_valid(). Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-20 09:17:28 -05:00
net: ipa: clean up header memory validation Do some general cleanup in ipa_cmd_header_valid(): - Delay assigning the mem variable until just before it's used. - Assign the maximum offset and size values together. - Improve comments explaining the single range of memory being made up of a modem portion and an AP portion. - Record the offset of the combined range in a local variable. - Do the initial size assignment right after assigning the offset. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-10 14:23:02 -05:00
net: ipa: fix init header command validation We use ipa_cmd_header_valid() to ensure certain values we will program into hardware are within range, well in advance of when we actually program them. This way we avoid having to check for errors when we actually program the hardware. Unfortunately the dev_err() call for a bad offset value does not supply the arguments to match the format specifiers properly. Fix this. There was also supposed to be a check to ensure the size to be programmed fits in the field that holds it. Add this missing check. Rearrange the way we ensure the header table fits in overall IPA memory range. Finally, update ipa_cmd_table_valid() so the format of messages printed for errors matches what's done in ipa_cmd_header_valid(). Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-20 09:17:28 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: introduce ipa_mem_find() Introduce a new function that abstracts finding information about a region in IPA-local memory, given its memory region ID. For now it simply uses the region ID as an index into the IPA memory array. If the region is not defined, ipa_mem_find() returns a null pointer. Update all code that accesses the ipa->mem[] array directly to use ipa_mem_find() instead. The return value must be checked for null when optional memory regions are sought. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-10 14:23:07 -05:00
net: ipa: fix init header command validation We use ipa_cmd_header_valid() to ensure certain values we will program into hardware are within range, well in advance of when we actually program them. This way we avoid having to check for errors when we actually program the hardware. Unfortunately the dev_err() call for a bad offset value does not supply the arguments to match the format specifiers properly. Fix this. There was also supposed to be a check to ensure the size to be programmed fits in the field that holds it. Add this missing check. Rearrange the way we ensure the header table fits in overall IPA memory range. Finally, update ipa_cmd_table_valid() so the format of messages printed for errors matches what's done in ipa_cmd_header_valid(). Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-20 09:17:28 -05:00
net: ipa: clean up header memory validation Do some general cleanup in ipa_cmd_header_valid(): - Delay assigning the mem variable until just before it's used. - Assign the maximum offset and size values together. - Improve comments explaining the single range of memory being made up of a modem portion and an AP portion. - Record the offset of the combined range in a local variable. - Do the initial size assignment right after assigning the offset. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-10 14:23:02 -05:00
net: ipa: fix init header command validation We use ipa_cmd_header_valid() to ensure certain values we will program into hardware are within range, well in advance of when we actually program them. This way we avoid having to check for errors when we actually program the hardware. Unfortunately the dev_err() call for a bad offset value does not supply the arguments to match the format specifiers properly. Fix this. There was also supposed to be a check to ensure the size to be programmed fits in the field that holds it. Add this missing check. Rearrange the way we ensure the header table fits in overall IPA memory range. Finally, update ipa_cmd_table_valid() so the format of messages printed for errors matches what's done in ipa_cmd_header_valid(). Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-20 09:17:28 -05:00
net: ipa: clean up header memory validation Do some general cleanup in ipa_cmd_header_valid(): - Delay assigning the mem variable until just before it's used. - Assign the maximum offset and size values together. - Improve comments explaining the single range of memory being made up of a modem portion and an AP portion. - Record the offset of the combined range in a local variable. - Do the initial size assignment right after assigning the offset. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-10 14:23:02 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: don't save the platform device The IPA platform device is now only used as the structure containing the IPA device structure. Replace the platform device pointer with a pointer to the device structure. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-03-01 11:02:42 -06:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: reduce IPA version assumptions Modify conditional tests throughout the IPA code so they do not assume that IPA v3.5.1 is the oldest version supported. Also remove assumptions that IPA v4.5 is the newest version of IPA supported. Augment versions in comments with "+", to be clearer that the comment applies to a version and subsequent versions. (E.g., "present for IPA v4.2+" instead of just "present for v4.2".) Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-24 08:15:23 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: reduce IPA version assumptions Modify conditional tests throughout the IPA code so they do not assume that IPA v3.5.1 is the oldest version supported. Also remove assumptions that IPA v4.5 is the newest version of IPA supported. Augment versions in comments with "+", to be clearer that the comment applies to a version and subsequent versions. (E.g., "present for IPA v4.2+" instead of just "present for v4.2".) Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-24 08:15:23 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: fix register write command validation In ipa_cmd_register_write_valid() we verify that values we will supply to a REGISTER_WRITE IPA immediate command will fit in the fields that need to hold them. This patch fixes some issues in that function and ipa_cmd_register_write_offset_valid(). The dev_err() call in ipa_cmd_register_write_offset_valid() has some printf format errors: - The name of the register (corresponding to the string format specifier) was not supplied. - The IPA base offset and offset need to be supplied separately to match the other format specifiers. Also make the ~0 constant used there to compute the maximum supported offset value explicitly unsigned. There are two other issues in ipa_cmd_register_write_valid(): - There's no need to check the hash flush register for platforms (like IPA v4.2) that do not support hashed tables - The highest possible endpoint number, whose status register offset is computed, is COUNT - 1, not COUNT. Fix these problems, and add some additional commentary. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 08:34:00 -06:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: fix register write command validation In ipa_cmd_register_write_valid() we verify that values we will supply to a REGISTER_WRITE IPA immediate command will fit in the fields that need to hold them. This patch fixes some issues in that function and ipa_cmd_register_write_offset_valid(). The dev_err() call in ipa_cmd_register_write_offset_valid() has some printf format errors: - The name of the register (corresponding to the string format specifier) was not supplied. - The IPA base offset and offset need to be supplied separately to match the other format specifiers. Also make the ~0 constant used there to compute the maximum supported offset value explicitly unsigned. There are two other issues in ipa_cmd_register_write_valid(): - There's no need to check the hash flush register for platforms (like IPA v4.2) that do not support hashed tables - The highest possible endpoint number, whose status register offset is computed, is COUNT - 1, not COUNT. Fix these problems, and add some additional commentary. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 08:34:00 -06:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: fix register write command validation In ipa_cmd_register_write_valid() we verify that values we will supply to a REGISTER_WRITE IPA immediate command will fit in the fields that need to hold them. This patch fixes some issues in that function and ipa_cmd_register_write_offset_valid(). The dev_err() call in ipa_cmd_register_write_offset_valid() has some printf format errors: - The name of the register (corresponding to the string format specifier) was not supplied. - The IPA base offset and offset need to be supplied separately to match the other format specifiers. Also make the ~0 constant used there to compute the maximum supported offset value explicitly unsigned. There are two other issues in ipa_cmd_register_write_valid(): - There's no need to check the hash flush register for platforms (like IPA v4.2) that do not support hashed tables - The highest possible endpoint number, whose status register offset is computed, is COUNT - 1, not COUNT. Fix these problems, and add some additional commentary. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 08:34:00 -06:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: start generalizing "ipa_reg" IPA register definitions have evolved with each new version. The changes required to support more than 32 endpoints in IPA v5.0 made it best to define a unified mechanism for defining registers and their fields. GSI register definitions, meanwhile, have remained fairly stable. And even as the total number of IPA endpoints goes beyond 32, the number of GSI channels on a given EE that underly endpoints still remains 32 or less. Despite that, GSI v3.0 (which is used with IPA v5.0) extends the number of channels (and events) it supports to be about 256, and as a result, many GSI register definitions must change significantly. To address this, we'll use the same "ipa_reg" mechanism to define the GSI registers. As a first step in generalizing the "ipa_reg" to also support GSI registers, isolate the definitions of the "ipa_reg" and "ipa_regs" structure types (and some supporting macros) into a new header file, and remove the "ipa_" and "IPA_" from symbol names. Separate the IPA register ID validity checking from the generic check that a register ID is in range. Aside from that, this is intended to have no functional effect on the code. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-02-08 14:56:51 -06:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: fix register write command validation In ipa_cmd_register_write_valid() we verify that values we will supply to a REGISTER_WRITE IPA immediate command will fit in the fields that need to hold them. This patch fixes some issues in that function and ipa_cmd_register_write_offset_valid(). The dev_err() call in ipa_cmd_register_write_offset_valid() has some printf format errors: - The name of the register (corresponding to the string format specifier) was not supplied. - The IPA base offset and offset need to be supplied separately to match the other format specifiers. Also make the ~0 constant used there to compute the maximum supported offset value explicitly unsigned. There are two other issues in ipa_cmd_register_write_valid(): - There's no need to check the hash flush register for platforms (like IPA v4.2) that do not support hashed tables - The highest possible endpoint number, whose status register offset is computed, is COUNT - 1, not COUNT. Fix these problems, and add some additional commentary. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 08:34:00 -06:00
net: ipa: introduce ipa_table_hash_support() Introduce a new function to abstract the knowledge of whether hashed routing and filter tables are supported for a given IPA instance. IPA v4.2 is the only one that doesn't support hashed tables (now and for the foreseeable future), but the name of the helper function is better for explaining what's going on. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 08:34:01 -06:00
net: ipa: update table cache flushing Update the code that causes filter and router table caches to be flushed so that it supports IPA versions 5.0+. It adds a comment in ipa_hardware_config_hashing() that explains that cacheing does not need to be enabled, just as before, because it's enabled by default. (For the record, the FILT_ROUT_CACHE_CFG register would have been used if we wanted to explicitly enable these.) Signed-off-by: Alex Elder <elder@linaro.org> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-30 15:01:54 -06:00
net: ipa: generalize register offset functions Rename ipa_reg_offset() to be reg_offset() and move its definition to "reg.h". Rename ipa_reg_n_offset() to be reg_n_offset() also. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-02-08 14:56:52 -06:00
net: ipa: fix register write command validation In ipa_cmd_register_write_valid() we verify that values we will supply to a REGISTER_WRITE IPA immediate command will fit in the fields that need to hold them. This patch fixes some issues in that function and ipa_cmd_register_write_offset_valid(). The dev_err() call in ipa_cmd_register_write_offset_valid() has some printf format errors: - The name of the register (corresponding to the string format specifier) was not supplied. - The IPA base offset and offset need to be supplied separately to match the other format specifiers. Also make the ~0 constant used there to compute the maximum supported offset value explicitly unsigned. There are two other issues in ipa_cmd_register_write_valid(): - There's no need to check the hash flush register for platforms (like IPA v4.2) that do not support hashed tables - The highest possible endpoint number, whose status register offset is computed, is COUNT - 1, not COUNT. Fix these problems, and add some additional commentary. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 08:34:00 -06:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: fix register write command validation In ipa_cmd_register_write_valid() we verify that values we will supply to a REGISTER_WRITE IPA immediate command will fit in the fields that need to hold them. This patch fixes some issues in that function and ipa_cmd_register_write_offset_valid(). The dev_err() call in ipa_cmd_register_write_offset_valid() has some printf format errors: - The name of the register (corresponding to the string format specifier) was not supplied. - The IPA base offset and offset need to be supplied separately to match the other format specifiers. Also make the ~0 constant used there to compute the maximum supported offset value explicitly unsigned. There are two other issues in ipa_cmd_register_write_valid(): - There's no need to check the hash flush register for platforms (like IPA v4.2) that do not support hashed tables - The highest possible endpoint number, whose status register offset is computed, is COUNT - 1, not COUNT. Fix these problems, and add some additional commentary. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12 08:34:00 -06:00
net: ipa: introduce ipa_reg() Create a new function that returns a register descriptor given its ID. Change ipa_reg_offset() and ipa_reg_n_offset() so they take a register descriptor argument rather than an IPA pointer and register ID. Have them accept null pointers (and return an invalid 0 offset), to avoid the need for excessive error checking. (A warning is issued whenever ipa_reg() returns 0). Call ipa_reg() or ipa_reg_n() to look up information about the register before calls to ipa_reg_offset() and ipa_reg_n_offset(). Delay looking up offsets until they're needed to read or write registers. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-26 17:09:21 -05:00
net: ipa: generalize register offset functions Rename ipa_reg_offset() to be reg_offset() and move its definition to "reg.h". Rename ipa_reg_n_offset() to be reg_n_offset() also. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-02-08 14:56:52 -06:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: rename channel->tlv_count Each GSI channel has a TLV FIFO of a certain size, specified in the configuration data for an AP channel. That size dictates the maximum number of TREs that are allowed in a single transaction. The only way that value is used after initialization is as a limit on the number of TREs in a transaction; calling it "tlv_count" isn't helpful, and in fact gsi_channel_trans_tre_max() exists to sort of abstract it. Instead, rename the channel->tlv_count field trans_tre_max, and get rid of the helper function. Update a couple of comments as well. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-06-10 10:46:11 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: remove command info pool The ipa_cmd_info structure now contains only one field, and it's an enumerated type whose values all fit in 8 bits. Currently we'll never use more than 8 TREs in a command transaction, and we can represent that number of command opcodes in the same space as a 64 bit pointer to an ipa_cmd_info structure. Define IPA_COMMAND_TRANS_TRE_MAX as the maximum number of TREs that can be in a command transaction. Replace the info pointer in a transaction with a fixed-size array named cmd_opcode[] of that many bytes. Store the opcode in this array when adding a command TRE to a transaction, as was done previously for the info array. This makes the ipa_cmd_info unused, so get rid of it. When committing an immediate command transaction, use the channel's Boolean command flag to determine whether to fill in the opcode, which will be taken (as before) from the array in the transaction. This makes the command info pool unnecessary, so get rid of it. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-05-21 19:32:22 -05:00
net: ipa: rename channel->tlv_count Each GSI channel has a TLV FIFO of a certain size, specified in the configuration data for an AP channel. That size dictates the maximum number of TREs that are allowed in a single transaction. The only way that value is used after initialization is as a limit on the number of TREs in a transaction; calling it "tlv_count" isn't helpful, and in fact gsi_channel_trans_tre_max() exists to sort of abstract it. Instead, rename the channel->tlv_count field trans_tre_max, and get rid of the helper function. Update a couple of comments as well. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-06-10 10:46:11 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: remove command direction argument We no longer use the direction argument for gsi_trans_cmd_add(), so get rid of it in its definition, and in its seven callers. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-05-21 19:32:21 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: remove command direction argument We no longer use the direction argument for gsi_trans_cmd_add(), so get rid of it in its definition, and in its seven callers. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-05-21 19:32:21 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: reduce IPA version assumptions Modify conditional tests throughout the IPA code so they do not assume that IPA v3.5.1 is the oldest version supported. Also remove assumptions that IPA v4.5 is the newest version of IPA supported. Augment versions in comments with "+", to be clearer that the comment applies to a version and subsequent versions. (E.g., "present for IPA v4.2+" instead of just "present for v4.2".) Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-24 08:15:23 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: remove command direction argument We no longer use the direction argument for gsi_trans_cmd_add(), so get rid of it in its definition, and in its seven callers. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-05-21 19:32:21 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: extend endpoints in packet init command The IP_PACKET_INIT immediate command defines the destination endpoint to which a packet should be sent. Prior to IPA v5.0, a 5 bit field in that command represents the endpoint, but starting with IPA v5.0, the field is extended to 8 bits to support more than 32 endpoints. Signed-off-by: Alex Elder <elder@linaro.org> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-30 15:01:52 -06:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: remove command direction argument We no longer use the direction argument for gsi_trans_cmd_add(), so get rid of it in its definition, and in its seven callers. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-05-21 19:32:21 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: use WARN_ON() rather than assertions I've added commented assertions to record certain properties that can be assumed to hold in certain places in the IPA code. Convert these into real WARN_ON() calls so the assertions are actually checked, using the standard WARN_ON() mechanism. Where errors can be returned, return an error if a warning is triggered. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-26 12:40:10 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: remove command direction argument We no longer use the direction argument for gsi_trans_cmd_add(), so get rid of it in its definition, and in its seven callers. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-05-21 19:32:21 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: don't pass tag value to ipa_cmd_ip_tag_status_add() We only send a tagged packet from the AP->command TX endpoint when we're clearing the hardware pipeline. And when we receive the tagged packet we don't care what the actual tag value is. Stop passing a tag value to ipa_cmd_ip_tag_status_add(), and just encode 0 as the tag sent. Fix the function that encodes the tag so it uses the proper byte ordering. Signed-off-by: Alex Elder <elder@linaro.org> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-26 12:57:02 -06:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: don't pass tag value to ipa_cmd_ip_tag_status_add() We only send a tagged packet from the AP->command TX endpoint when we're clearing the hardware pipeline. And when we receive the tagged packet we don't care what the actual tag value is. Stop passing a tag value to ipa_cmd_ip_tag_status_add(), and just encode 0 as the tag sent. Fix the function that encodes the tag so it uses the proper byte ordering. Signed-off-by: Alex Elder <elder@linaro.org> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-26 12:57:02 -06:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: remove command direction argument We no longer use the direction argument for gsi_trans_cmd_add(), so get rid of it in its definition, and in its seven callers. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-05-21 19:32:21 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: don't pass size to ipa_cmd_transfer_add() The only time we transfer data (rather than issuing a command) out of the AP->command TX endpoint is when we're clearing the hardware pipeline. All that's needed is a "small" data buffer, and its contents aren't even important. For convenience, we just transfer a command structure in this case (it's already mapped for DMA). The TRE is added to a transaction using ipa_cmd_ip_tag_status_add(), but we ignore the size value provided to that function. So just get rid of the size argument. Signed-off-by: Alex Elder <elder@linaro.org> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-26 12:57:03 -06:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: remove command direction argument We no longer use the direction argument for gsi_trans_cmd_add(), so get rid of it in its definition, and in its seven callers. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-05-21 19:32:21 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: rename "tag status" symbols There is a set of functions and symbols related to performing "tag_process" immediate commands to clear the IPA pipeline. The name is related to one of the commands issued when doing this, but it doesn't really convey the overall purpose of taking this action. The purpose is to take some steps to "clear out" the hardware pipeline, and to wait until that process completes, to ensure the IPA hardware is in a well-defined state. Rename these symbols to use "pipeline_clear" in their names instead. Add some comments to explain a bit more about what's going on. Signed-off-by: Alex Elder <elder@linaro.org> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-26 12:56:58 -06:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: use tag process on modem crash One part of recovering from a modem crash is performing a "tag sequence" of several IPA immediate commands, to clear the hardware pipeline. The sequence ends with a data transfer request on the command endpoint (which is not otherwise done). Unfortunately, attempting to do the data transfer led to a hang, so that request plus two other commands were commented out. The previous commit fixes the bug that was causing that hang. And with that bug fixed we can properly issue the tag sequence when the modem crashes, to return the hardware to a known state. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-07 14:14:04 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: signal when tag transfer completes There are times, such as when the modem crashes, when we issue commands to clear the IPA hardware pipeline. These commands include a data transfer command that delivers a small packet directly to the default (AP<-LAN RX) endpoint. The places that do this wait for the transactions that contain these commands to complete, but the pipeline can't be assumed clear until the sent packet has been *received*. The small transfer will be delivered with a status structure, and that status will indicate its tag is valid. This is the only place we send a tagged packet, so we use the tag to determine when the pipeline clear packet has arrived. Add a completion to the IPA structure to to be used to signal the receipt of a pipeline clear packet. Create a new function ipa_cmd_pipeline_clear_wait() that will wait for that completion. Reinitialize the completion whenever pipeline clear commands are added to a transaction. Extend ipa_endpoint_status_tag() to check whether a packet whose status contains a valid tag was sent from the AP->command TX endpoint, and if so, signal the new IPA completion. Have all callers of ipa_cmd_pipeline_clear_add() wait for the pipeline clear indication after the transaction that clears the pipeline has completed. Signed-off-by: Alex Elder <elder@linaro.org> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-26 12:57:01 -06:00
net: ipa: rename "tag status" symbols There is a set of functions and symbols related to performing "tag_process" immediate commands to clear the IPA pipeline. The name is related to one of the commands issued when doing this, but it doesn't really convey the overall purpose of taking this action. The purpose is to take some steps to "clear out" the hardware pipeline, and to wait until that process completes, to ensure the IPA hardware is in a well-defined state. Rename these symbols to use "pipeline_clear" in their names instead. Add some comments to explain a bit more about what's going on. Signed-off-by: Alex Elder <elder@linaro.org> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-26 12:56:58 -06:00
net: ipa: use tag process on modem crash One part of recovering from a modem crash is performing a "tag sequence" of several IPA immediate commands, to clear the hardware pipeline. The sequence ends with a data transfer request on the command endpoint (which is not otherwise done). Unfortunately, attempting to do the data transfer led to a hang, so that request plus two other commands were commented out. The previous commit fixes the bug that was causing that hang. And with that bug fixed we can properly issue the tag sequence when the modem crashes, to return the hardware to a known state. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-07 14:14:04 -05:00
net: ipa: rename "tag status" symbols There is a set of functions and symbols related to performing "tag_process" immediate commands to clear the IPA pipeline. The name is related to one of the commands issued when doing this, but it doesn't really convey the overall purpose of taking this action. The purpose is to take some steps to "clear out" the hardware pipeline, and to wait until that process completes, to ensure the IPA hardware is in a well-defined state. Rename these symbols to use "pipeline_clear" in their names instead. Add some comments to explain a bit more about what's going on. Signed-off-by: Alex Elder <elder@linaro.org> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-26 12:56:58 -06:00
net: ipa: don't pass tag value to ipa_cmd_ip_tag_status_add() We only send a tagged packet from the AP->command TX endpoint when we're clearing the hardware pipeline. And when we receive the tagged packet we don't care what the actual tag value is. Stop passing a tag value to ipa_cmd_ip_tag_status_add(), and just encode 0 as the tag sent. Fix the function that encodes the tag so it uses the proper byte ordering. Signed-off-by: Alex Elder <elder@linaro.org> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-26 12:57:02 -06:00
net: ipa: rename "tag status" symbols There is a set of functions and symbols related to performing "tag_process" immediate commands to clear the IPA pipeline. The name is related to one of the commands issued when doing this, but it doesn't really convey the overall purpose of taking this action. The purpose is to take some steps to "clear out" the hardware pipeline, and to wait until that process completes, to ensure the IPA hardware is in a well-defined state. Rename these symbols to use "pipeline_clear" in their names instead. Add some comments to explain a bit more about what's going on. Signed-off-by: Alex Elder <elder@linaro.org> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-26 12:56:58 -06:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: don't pass tag value to ipa_cmd_ip_tag_status_add() We only send a tagged packet from the AP->command TX endpoint when we're clearing the hardware pipeline. And when we receive the tagged packet we don't care what the actual tag value is. Stop passing a tag value to ipa_cmd_ip_tag_status_add(), and just encode 0 as the tag sent. Fix the function that encodes the tag so it uses the proper byte ordering. Signed-off-by: Alex Elder <elder@linaro.org> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-26 12:57:02 -06:00
net: ipa: don't pass size to ipa_cmd_transfer_add() The only time we transfer data (rather than issuing a command) out of the AP->command TX endpoint is when we're clearing the hardware pipeline. All that's needed is a "small" data buffer, and its contents aren't even important. For convenience, we just transfer a command structure in this case (it's already mapped for DMA). The TRE is added to a transaction using ipa_cmd_ip_tag_status_add(), but we ignore the size value provided to that function. So just get rid of the size argument. Signed-off-by: Alex Elder <elder@linaro.org> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-26 12:57:03 -06:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: rename "tag status" symbols There is a set of functions and symbols related to performing "tag_process" immediate commands to clear the IPA pipeline. The name is related to one of the commands issued when doing this, but it doesn't really convey the overall purpose of taking this action. The purpose is to take some steps to "clear out" the hardware pipeline, and to wait until that process completes, to ensure the IPA hardware is in a well-defined state. Rename these symbols to use "pipeline_clear" in their names instead. Add some comments to explain a bit more about what's going on. Signed-off-by: Alex Elder <elder@linaro.org> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-26 12:56:58 -06:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: signal when tag transfer completes There are times, such as when the modem crashes, when we issue commands to clear the IPA hardware pipeline. These commands include a data transfer command that delivers a small packet directly to the default (AP<-LAN RX) endpoint. The places that do this wait for the transactions that contain these commands to complete, but the pipeline can't be assumed clear until the sent packet has been *received*. The small transfer will be delivered with a status structure, and that status will indicate its tag is valid. This is the only place we send a tagged packet, so we use the tag to determine when the pipeline clear packet has arrived. Add a completion to the IPA structure to to be used to signal the receipt of a pipeline clear packet. Create a new function ipa_cmd_pipeline_clear_wait() that will wait for that completion. Reinitialize the completion whenever pipeline clear commands are added to a transaction. Extend ipa_endpoint_status_tag() to check whether a packet whose status contains a valid tag was sent from the AP->command TX endpoint, and if so, signal the new IPA completion. Have all callers of ipa_cmd_pipeline_clear_add() wait for the pipeline clear indication after the transaction that clears the pipeline has completed. Signed-off-by: Alex Elder <elder@linaro.org> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-26 12:57:01 -06:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: remove command info pool The ipa_cmd_info structure now contains only one field, and it's an enumerated type whose values all fit in 8 bits. Currently we'll never use more than 8 TREs in a command transaction, and we can represent that number of command opcodes in the same space as a 64 bit pointer to an ipa_cmd_info structure. Define IPA_COMMAND_TRANS_TRE_MAX as the maximum number of TREs that can be in a command transaction. Replace the info pointer in a transaction with a fixed-size array named cmd_opcode[] of that many bytes. Store the opcode in this array when adding a command TRE to a transaction, as was done previously for the info array. This makes the ipa_cmd_info unused, so get rid of it. When committing an immediate command transaction, use the channel's Boolean command flag to determine whether to fill in the opcode, which will be taken (as before) from the array in the transaction. This makes the command info pool unnecessary, so get rid of it. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-05-21 19:32:22 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: remove command info pool The ipa_cmd_info structure now contains only one field, and it's an enumerated type whose values all fit in 8 bits. Currently we'll never use more than 8 TREs in a command transaction, and we can represent that number of command opcodes in the same space as a 64 bit pointer to an ipa_cmd_info structure. Define IPA_COMMAND_TRANS_TRE_MAX as the maximum number of TREs that can be in a command transaction. Replace the info pointer in a transaction with a fixed-size array named cmd_opcode[] of that many bytes. Store the opcode in this array when adding a command TRE to a transaction, as was done previously for the info array. This makes the ipa_cmd_info unused, so get rid of it. When committing an immediate command transaction, use the channel's Boolean command flag to determine whether to fill in the opcode, which will be taken (as before) from the array in the transaction. This makes the command info pool unnecessary, so get rid of it. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-05-21 19:32:22 -05:00
soc: qcom: ipa: immediate commands One TX endpoint (per EE) is used for issuing immediate commands to the IPA. These commands request activites beyond simple data transfers to be done by the IPA hardware. For example, the IPA is able to manage routing packets among endpoints, and immediate commands are used to configure tables used for that routing. Immediate commands are built on top of GSI transactions. They are different from normal transfers (in that they use a special endpoint, and their "payload" is interpreted differently), so separate functions are used to issue immediate command transactions. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05 22:28:26 -06:00
net: ipa: introduce ipa_cmd_init() Currently, ipa_cmd_data_valid() is called by ipa_mem_config(). Nothing it does requires access to hardware though, so it can be done during the init phase of IPA driver startup. Create a new function ipa_cmd_init(), whose purpose is to do early initialization related to IPA immediate commands. It will call the build-time validation function, then will make the two calls made previously by ipa_cmd_data_valid(). This make ipa_cmd_data_valid() unnecessary, so get rid of it. Rename ipa_cmd_header_valid() to be ipa_cmd_header_init_local_valid(), so its name is clearer about which IPA immediate command it is associated with. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-10-21 14:13:38 -05:00