From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9EDFC3FD122 for ; Tue, 14 Jul 2026 08:35:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784018146; cv=none; b=Ov60w9HpRq4ycFPnhmF0qSzAoio6j43qJfJVxYQ3RKFfVVVXAx6/YwaHFnFn0t9ZKhXpcnED4Ojn7jiyPfrLG20eGljxDxv0mAciUPdKi9WYpG+Vqi5P9jM01xGPBdLBKZ9bbnut0UwDbr14TekdmoCSNJ44NaZ6uyXZ0g8eYOI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784018146; c=relaxed/simple; bh=NxY3IEzBUQWhhn//m/oJS8ynj77rccs7GmYDWdMsC/w=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=rmz7/8H79vl52ZKh8JBxUFCBVlZg4I7FJTOoiyII75t/gdTMlcO/AmPx+PNvcSHFXqx4Riid50O8B7+50tCV0wFfwWTVsE1lDFH48N4RxOcsEIXl5kFlE0J7pZdGU1Dr8/X3kl+4Ixg8bRfCrlAzWiyZk7TzyCOx0M1pHfIgUdw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=KwF8N9Jv; arc=none smtp.client-ip=209.85.214.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="KwF8N9Jv" Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-2cea3004256so37144165ad.0 for ; Tue, 14 Jul 2026 01:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784018138; x=1784622938; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=997t2oDEbZst/e30RzuUFOMAIgJy7wVKg2mw9L5gqmI=; b=KwF8N9JvWHKkyVVR+ZPSVmL/Z/DqRsoW9cjTcqdvh5tLL0jzSL5ivh76tgBnN4wGcD vFx2ZYSq7h6lDgEnwD/UBLtcoyZG7R23tw9NVFZwEIr1AppEKvUL7m6TYnuqG8XU7qfi Bnzvp8N5O1N7UnL5yJkLLkeAHRHqjWo1SYOjTVkp3y8AhzgFOcWdccJJkd6A3JGwQKW5 ZOjp8hzBY9qulUm5aGfcE75nyBLk7iGcgtZBIzjunhChxUD63tT8GDPdf1UR8L5aGCzN 0gXf0X30SexchzkVC5p6NwDTj33QbO8+KfKzPa2dQ0h8+k7/tOUqA/1GoMr22UMgVseQ z2Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784018138; x=1784622938; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=997t2oDEbZst/e30RzuUFOMAIgJy7wVKg2mw9L5gqmI=; b=DqFEaa0Og+9TuAQjOta6jZd/+a1CBMCr3wdYU/Ic/qvARfJQEQPMx9tCpcLljgp1+U Q/qg8UN/ACMKcIZHV5NliuzgOVmWuHgqBPYxzIUFKjE+CzfRS/oaU2N1FdRqn229RdGU Fs5UDjShcwj0QfynWAzxlOILT4763n+24UWOKDytSlV1nfKge8tnvZMyFDm0MFyYqc0b qK8BEIrG701k8RXNarK7MA9DT2ik2PmsQ56xNVgp8FDG+pSU78lUeMTvC/wloy7EYqpM ZHIAPwp2uJ9hvel1aqbP8ziNguzkH76Nfcw3oHgEC0S8R8msfkJDtxWVaqMYZLYN73Sq r0PA== X-Forwarded-Encrypted: i=1; AHgh+RofC8zIVyrpRay4VElYACuv6LP8TIKj73rY0gK5vbp72sQy+MropJ8jbw+/X1VmUFg0ChTeEureqdpHHcs=@vger.kernel.org X-Gm-Message-State: AOJu0YxMe9uLgOlW5/ikxNG5nCOCYZV4u6G6lLl9AtMFbkDo5dJAB1A6 04XbYPzmQVVhzX1zzAkMwgBPIsT+B0W1OIkxFEkR1nqx9agXSzXC4Qs7 X-Gm-Gg: AfdE7cmz2eW43wwnow5/EhNywT2/hkVQ/RKwU09BkWQ37jNAC38pmCLnPZUEzPKxgMn yzBr5bvg1By98GmyX5mcMq1fPu7kSHdza1HG4Ox3Pm9l0lt4YTHuaQUI8qnWmoxKu9CQkff8j5S baj3Ud0vII1BAusPCgbc48/zOsXzRp9G55gYbargH+pCR2iaUnoxtJBGZp/Oeai9ow0Y4r9zuLU qs72Cs8NdZiuVSQcgOem3+2wHdAHBGUItTWJxeYsKnmf+PbKevTqx3/9w//H6c1bIOO3ujmziHF MWg6ACqOQQtIqIyNptTqcEJY8vQv7yl8g/y14a0ymWPxGW49rUa9+pmQsjnYyRvp2P/oRY8xFcZ wTfud5xnnofaHq9wK/10nDqtiIgkS7cQZn057I6H4vukCgwvEJUBogOPG2v4JLnKd7VThRtMmNs XfwweYBqQEX9xyMsg1rQ== X-Received: by 2002:a17:903:1c7:b0:2ce:ceef:6632 with SMTP id d9443c01a7336-2cef143bb16mr17673375ad.26.1784018138448; Tue, 14 Jul 2026 01:35:38 -0700 (PDT) Received: from [198.18.0.1] ([188.253.118.67]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ccc9d1ea74sm112691955ad.41.2026.07.14.01.35.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Jul 2026 01:35:37 -0700 (PDT) Message-ID: <48f0b6d7-6cf8-4f61-aee7-927660f063b6@gmail.com> Date: Tue, 14 Jul 2026 16:35:28 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] soundwire: stream: validate slave port against DisCo port bitmap To: Pierre-Louis Bossart , Vinod Koul , Bard Liao Cc: linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260713071544.35722-1-kunjinkao.jp@gmail.com> From: Eric Wu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit > Smart, good idea. I would recommend adding the first sentence as code comments, I had to look up the code to figure out what it did. I'll add a short comment explaining that the generic range check does not verify whether the Slave exposes the port for the requested direction. > That's a problem in general, maybe push this patch first through the Intel/SOF CI to check that some SoundWire platforms are tested? I'll run the updated patch through the Intel/SOF CI before posting v2. > That comment is a tad misleading. > > In the real world, all drivers ignore DisCo properties provided by platform firmware, and hard-code the values, e.g. > > prop->source_ports = 0x14; /* BITMAP: 00010100 */ > prop->sink_ports = 0x8; /* BITMAP: 00001000 */ > > Those properties are really not optional at all, what's optional is that they are blindly read from firmware. Agreed. Describing source_ports and sink_ports as optional is inaccurate.So I'll rework the comment. > This test is a bit odd, there could be cases where only source_ports are defined so you would try to check for a sink_port in sdw_get_slave_dpn_prop() > It probably works in the end but maybe you could check s_rt->direction with source/sink port first? I'll select the relevant bitmap based on the stream direction first and reject a zero bitmap for that direction.