From: Casey Tunturi <casey@samaritansolutions.net>

During my investigations, and some rather incessant cross-checking of
blueline's SLIMbus path, I found that Qualcomm's downstream driver
packs the first DEF_ACT_CHAN byte differently from mainline. Bits [7:5]
hold the data format; bits [4:0] hold the five-bit client number.

I changed ours to match. It made no immediate difference on my own
hardware: blueline's current values produce 0x0f either way. The
downstream layout is correct and should help devices that use upper
logical-address bits or a non-zero data format.

Fixes: 52490169cddf ("slimbus: ngd: add stream support")
Cc: stable@vger.kernel.org
Signed-off-by: Casey Tunturi <casey@samaritansolutions.net>
---
 drivers/slimbus/qcom-ngd-ctrl.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/slimbus/qcom-ngd-ctrl.c b/drivers/slimbus/qcom-ngd-ctrl.c
index 3071e46d0..14192380d 100644
--- a/drivers/slimbus/qcom-ngd-ctrl.c
+++ b/drivers/slimbus/qcom-ngd-ctrl.c
@@ -1018,7 +1018,8 @@ static int qcom_slim_ngd_enable_stream(struct slim_stream_runtime *rt)
 		if (txn.msg->num_bytes == 0) {
 			int exp = 0, coef = 0;
 
-			wbuf[txn.msg->num_bytes++] = sdev->laddr;
+			wbuf[txn.msg->num_bytes++] =
+				(port->ch.data_fmt << 5) | (sdev->laddr & 0x1f);
 			wbuf[txn.msg->num_bytes] = rt->bps >> 2 |
 						   (port->ch.aux_fmt << 6);
 

---
base-commit: 55f2ea9ff83cc27a85526b14bc9b32f96a08d6ec
change-id: 20260807-slimbus-def-act-chan-b70e4fb7abb1

Best regards,
--  
Casey Tunturi <casey@samaritansolutions.net>

On 8/8/26 2:35 AM, Casey Tunturi via B4 Relay wrote:
> From: Casey Tunturi <casey@samaritansolutions.net>
> 
> During my investigations, and some rather incessant cross-checking of
> blueline's SLIMbus path, I found that Qualcomm's downstream driver
> packs the first DEF_ACT_CHAN byte differently from mainline. Bits [7:5]
> hold the data format; bits [4:0] hold the five-bit client number.
> 
> I changed ours to match. It made no immediate difference on my own
> hardware: blueline's current values produce 0x0f either way. The
> downstream layout is correct and should help devices that use upper
> logical-address bits or a non-zero data format.
> 
> Fixes: 52490169cddf ("slimbus: ngd: add stream support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Casey Tunturi <casey@samaritansolutions.net>
> ---

The semantics match, I don't know what side effects that may uncover

Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

On 8/18/26 1:50 PM, Konrad Dybcio wrote:
> On 8/8/26 2:35 AM, Casey Tunturi via B4 Relay wrote:
>> From: Casey Tunturi <casey@samaritansolutions.net>
>>
>> During my investigations, and some rather incessant cross-checking of
>> blueline's SLIMbus path, I found that Qualcomm's downstream driver
>> packs the first DEF_ACT_CHAN byte differently from mainline. Bits [7:5]
>> hold the data format; bits [4:0] hold the five-bit client number.
>>
>> I changed ours to match. It made no immediate difference on my own
>> hardware: blueline's current values produce 0x0f either way. The
>> downstream layout is correct and should help devices that use upper
>> logical-address bits or a non-zero data format.
>>
>> Fixes: 52490169cddf ("slimbus: ngd: add stream support")
>> Cc: stable@vger.kernel.org

there is no regression

We already set this in(stream.c) define_channel_content for each port
after enabling the channel.

--srini
>> Signed-off-by: Casey Tunturi <casey@samaritansolutions.net>
>> ---
> 
> The semantics match, I don't know what side effects that may uncover>
> Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> 
> Konrad