linux.git/include/linux/soc/qcom/apr.h, branch v7.2

Replace by more specific (headers)

2026-07-03T05:38:16+00:00

 is included in a many files:

	$ git grep '' ef0c9f75a195 | wc -l
	1598

; some of them are widely used headers. To stop mixing up different and
unrelated driver( type)s let the subsystem headers only use the subset
of the recently split  that are relevant for
them.

The fallout (I hope) is addressed in the previous commits that handle
sources relying on e.g.  pulling in the full legacy header
and thus providing pci_device_id.

Acked-by: Danilo Krummrich 
Acked-by: Takashi Sakamoto 
Link: https://patch.msgid.link/199fe46b624ba07fb9bd3e0cd6ff13757932cb5f.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub)

ASoC: qcom: Constify GPR packet being send over GPR interface

2026-04-06T14:40:30+00:00

gpr_send_pkt() and pkt_router_send_svc_pkt() only send the GPR packet
they receive, without any need to actually modify it, so mark the
pointer to GPR packet as pointer to const for code safety and code
self-documentation.  Several users of this interface can follow up and
also operate on pointer to const.

Acked-by: Mathieu Poirier 
Acked-by: Mark Brown 
Signed-off-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/r/20260317-rpmsg-send-const-v3-4-4d7fd27f037f@oss.qualcomm.com
Signed-off-by: Bjorn Andersson

ASoC: qcom: Constify GPR callback response data

2025-12-19T21:29:30+00:00

GPR bus driver calls each GPR client callback with pointer to the GPR
response packet.  The callbacks are not suppose to modify that response
packet, so make it a pointer to const to document that expectation
explicitly.

Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Srinivas Kandagatla 
Link: https://patch.msgid.link/20251130-asoc-apr-const-v1-3-d0833f3ed423@oss.qualcomm.com
Signed-off-by: Mark Brown

soc: qcom: apr: Use typedef for GPR callback member

2025-12-19T21:29:29+00:00

There is already a typedef for GPR callback used in 'struct
pkt_router_svc', so use it also in 'struct apr_driver', because it is
the same type - one is assigned to another in apr_device_probe().

Signed-off-by: Krzysztof Kozlowski 
Acked-by: Bjorn Andersson 
Reviewed-by: Srinivas Kandagatla 
Link: https://patch.msgid.link/20251130-asoc-apr-const-v1-2-d0833f3ed423@oss.qualcomm.com
Signed-off-by: Mark Brown

ASoC: qcom: Constify APR callback response data

2025-12-19T21:29:28+00:00

APR bus driver calls each APR client callback with pointer to the APR
response packet.  The callbacks are not suppose to modify that response
packet, so make it a pointer to const to document that expectation
explicitly.

Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Srinivas Kandagatla 
Link: https://patch.msgid.link/20251130-asoc-apr-const-v1-1-d0833f3ed423@oss.qualcomm.com
Signed-off-by: Mark Brown

driver core: have match() callback in struct bus_type take a const *

2024-07-03T13:16:54+00:00

In the match() callback, the struct device_driver * should not be
changed, so change the function callback to be a const *.  This is one
step of many towards making the driver core safe to have struct
device_driver in read-only memory.

Because the match() callback is in all busses, all busses are modified
to handle this properly.  This does entail switching some container_of()
calls to container_of_const() to properly handle the constant *.

For some busses, like PCI and USB and HV, the const * is cast away in
the match callback as those busses do want to modify those structures at
this point in time (they have a local lock in the driver structure.)
That will have to be changed in the future if they wish to have their
struct device * in read-only-memory.

Cc: Rafael J. Wysocki 
Reviewed-by: Alex Elder 
Acked-by: Sumit Garg 
Link: https://lore.kernel.org/r/2024070136-wrongdoer-busily-01e8@gregkh
Signed-off-by: Greg Kroah-Hartman

soc: qcom: apr: make aprbus const

2024-02-14T05:38:03+00:00

Since commit d492cc2573a0 ("driver core: device.h: make struct
bus_type a const *"), the driver core can properly handle constant
struct bus_type, move the aprbus variable to be a constant
structure as well, placing it into read-only memory which can not be
modified at runtime.

Cc: Greg Kroah-Hartman 
Suggested-by: Greg Kroah-Hartman 
Signed-off-by: "Ricardo B. Marliere" 
Reviewed-by: Greg Kroah-Hartman 
Link: https://lore.kernel.org/r/20240213-bus_cleanup-apr-v1-1-50c824eec06d@marliere.net
Signed-off-by: Bjorn Andersson

soc: qcom: apr: make remove callback of apr driver void returned

2023-01-06T17:50:13+00:00

Since commit fc7a6209d571 ("bus: Make remove callback return void")
forces bus_type::remove be void-returned, it doesn't make much sense
for any bus based driver implementing remove callbalk to return
non-void to its caller.

As such, change the remove function for apr bus based drivers to
return void.

Signed-off-by: Dawei Li 
Signed-off-by: Bjorn Andersson 
Link: https://lore.kernel.org/r/TYCP286MB23232B7968D34DB8323B0F16CAFB9@TYCP286MB2323.JPNP286.PROD.OUTLOOK.COM

soc: qcom: apr: Add GPR support

2021-09-28T03:10:07+00:00

Qualcomm Generic Packet router aka GPR is the IPC mechanism found
in AudioReach next generation signal processing framework to perform
command and response messages between various processors.

GPR has concepts of static and dynamic port, all static services like
APM (Audio Processing Manager), PRM (Proxy resource manager) have
fixed port numbers where as dynamic services like graphs have dynamic
port numbers which are allocated at runtime. All GPR packet messages
will have source and destination domain and port along with opcode
and payload.

Signed-off-by: Srinivas Kandagatla 
Reviewed-by: Pierre-Louis Bossart 
Signed-off-by: Bjorn Andersson 
Link: https://lore.kernel.org/r/20210927135559.738-6-srinivas.kandagatla@linaro.org

soc: qcom: apr: make code more reuseable

2021-09-28T03:10:07+00:00

APR and other packet routers like GPR are pretty much same and
interact with other drivers in similar way.

Ex: GPR ports can be considered as APR services, only difference
is they are allocated dynamically.

Other difference is packet layout, which should not matter
with the apis abstracted. Apart from this the rest of the
functionality is pretty much identical across APR and GPR.

Make the apr code more reusable by abstracting it service level,
rather than device level so that we do not need to write
new drivers for other new packet routers like GPR.

This patch is in preparation to add GPR support to this driver.

Signed-off-by: Srinivas Kandagatla 
Reviewed-by: Pierre-Louis Bossart 
Signed-off-by: Bjorn Andersson 
Link: https://lore.kernel.org/r/20210927135559.738-4-srinivas.kandagatla@linaro.org