From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) (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 E7DF83998B7 for ; Mon, 22 Jun 2026 12:39:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782131984; cv=none; b=SjfJeBYbUcu281BlXTFovKAXoHuhLiISDGuEoPZNnZvGC3ihYo6ZyDr+gAITmOocqmtJQa8hqTndKMhepklCSqeBrDtLWL1xQBA30QXjz7XzETjbHcP44AE/3RLrBkDw7dY0rzPd+TIYuP5FWKv+MkPrszo/MTKqvujPAZcXHok= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782131984; c=relaxed/simple; bh=aTdC6XxwJCmig7rZo6QKDdxrqrz43rsMMKYh383XKk8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=MLhZz4Kue7uES3JiEH9pNdhwLwjvPDIXvHXqIS4T1NyzwlJgVN5u8Ti83Orx1aOuO+AXqLHb8FwD+CjOOk2pdG/2rhj3rE/5bByQjQQjxkurgF5rcMp7B9+yIvsO/zat46qK8DLk3TnYnju+rKOkSTu/EvhYGNiXDE868FQsFE8= 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=Rdq1ld9G; arc=none smtp.client-ip=209.85.214.178 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="Rdq1ld9G" Received: by mail-pl1-f178.google.com with SMTP id d9443c01a7336-2c6a97e1d1bso31399205ad.0 for ; Mon, 22 Jun 2026 05:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782131981; x=1782736781; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=MvpH79wYXLCKH+SAxAFSpANy3DyUm5vrrOm1VqMVj6s=; b=Rdq1ld9GUSShzNGwPpg20JtPkTmfeNb0AdQCYdNTOegeuO7OhTISQlijCjhAw8g1w+ 70A3efGRUHXYYgRk6oRUEH9wnk1HvhPyzMR8oFiuqm4NKhNWcZm9GfB300nQJmKhwcpZ pBHO5IIgpmGxm4JwbBrSs/RiZPpH4uLGRq0tiYnC0/vIBbjYfwo0vhIzBljshG3lYY+x Ri5l3bk1f/JHRFNbbZIetKrA0l4vNjl6HZPWA5tY5APVkmhSvCJsEFlSNvxpKlXQcF2h DYbf8PF7pH8XQwBvQ4ohuG3SHzkFTmBfMwJpajhsduv4bh63X7IPQ3ip9QtoTEYYX27O MmrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782131981; x=1782736781; h=content-transfer-encoding:in-reply-to:from:content-language :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; bh=MvpH79wYXLCKH+SAxAFSpANy3DyUm5vrrOm1VqMVj6s=; b=Ju+ppXWzbR5pkZt1tWMqSEelzTJBBN3aB9j9ZxYwaC2+s74ok5oe0PBpGvg1C3og0C kWZ86sKjq4HYiVjbJ2UYJU9auXC1e7cDZOjdunjHDhLtV798G7mqSHiRDIwb58m0ABGN DOOW01xZGBCb1+lcs4dILpgBKT2K+zQXFXcNXFKOmD0lBfHKjEjDmuVykNirG35r6rRZ Jbo/qxZyGBhgJ4LHKFe62n2rCk2RmAy4JQUSN/dU3l5D3zVdSj+o29PkD5gXRhAPpCVy lvAXDH00VO1kI4TXSUzHhLSBgxnMW4AGSxi+mhYj1S75G31/hsYjoei2piwmc4awMCI9 Msnw== X-Forwarded-Encrypted: i=1; AHgh+RpxB3rdGNz2XmWH+v+KX+7sM890Kfsy+5Ys4FXQd/FQvdpzBNhTf4mPK0bP7iH7jEROTEtPR6mXkINvhC8=@vger.kernel.org X-Gm-Message-State: AOJu0Yx/Opx28x2kjFqqucpH1nvZjTqiEeRxBRDw6UJvI7GZUFzkoUMI kDzvtET4FTyl+Xx4Hi0YYx2kui2jnxC1MjJngi1UkZpU2dLOOXv7jTp8 X-Gm-Gg: AfdE7clYWzitjZxMsQZXD1sbUh0LezPWqUyGVupqpqHwq71IEFO+lzKBWm9PcWvTT7C 1ZPNGx+3JQkqRBxe4dQxMfPlk7lsqFbeS1CGwwGcsGDj2atCJmI8lgrGijF+odZ5ySPAuvRtKle vkARLMqTLU7LCYML9wwP43ItH8+2A3Q1wT9VeayOYfOHyGBwOM2D2250A0SBOaa/5pbbI72tKvR YyZSHi1INJRrj0JCnglLi9Wqg35xlUThNG1PSewu7lKM42KiP1VJ4Icr5tKt2nR/tYRUrS3gnoV BxNbuYv6vIWdvGM8mJsRKVzMXysq9CHUyHbSSJ/ThT7N5M30Oo8upgphey4Tox9k+IIr2+If4Hk DX8Z97hZEIq/loVeFNT+Hv7X64MNaCS1x7bngLCo+gsNqlweZ17tvD4AYbqR+nNHWgRy4SyDbqW welALeJeGkTbn/dMeGN9ZSPy3iIinNkIBh8i181VElWpDw9RtI6AA4+A== X-Received: by 2002:a17:903:230c:b0:2c2:245a:336c with SMTP id d9443c01a7336-2c718f63a4dmr149446005ad.14.1782131981162; Mon, 22 Jun 2026 05:39:41 -0700 (PDT) Received: from ?IPV6:2a02:3038:288:e57:59d:91ae:1c45:fb41? ([2a02:3038:288:e57:59d:91ae:1c45:fb41]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2c7436d6c16sm80701995ad.23.2026.06.22.05.39.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Jun 2026 05:39:40 -0700 (PDT) Message-ID: <013aba24-c30c-44a8-8511-96278edb3f4a@gmail.com> Date: Mon, 22 Jun 2026 14:39:21 +0200 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 v3 1/2] dt-bindings: iio: dac: Add AD5529R To: Conor Dooley Cc: =?UTF-8?Q?Nuno_S=C3=A1?= , Jonathan Cameron , Rodrigo Alencar <455.rodrigo.alencar@gmail.com>, Janani Sunil , Lars-Peter Clausen , Michael Hennerich , David Lechner , =?UTF-8?Q?Nuno_S=C3=A1?= , Andy Shevchenko , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Philipp Zabel , Jonathan Corbet , Shuah Khan , linux-iio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Mark Brown References: <20260619-bunch-diocese-dd7805cc17ff@spud> <20260619-concierge-doozy-9c161533c369@spud> <20260621153330.79b6600c@jic23-huawei> <20260621-nutmeg-coauthor-715189372230@spud> <20260622102722.5900592f@jic23-huawei> <20260622-overbid-yonder-3fdfee9eda7a@spud> Content-Language: en-US From: Janani Sunil In-Reply-To: <20260622-overbid-yonder-3fdfee9eda7a@spud> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 6/22/26 14:14, Conor Dooley wrote: > On Mon, Jun 22, 2026 at 01:54:25PM +0200, Janani Sunil wrote: >>>>>> Why do you think the microchip devices won't work? Does the spi core >>>>>> reject multiple devices with the same chip select being registered or >>>>>> something like that? >>>>> Not sure how things work atm. But I'm fairly sure it used to be like >>>>> that. SPI would reject devices on the same controller and CS. Now that >>>>> we support more than one CS per controller, not sure how things work. >>>> We always supported more than one per CS per controller. I guess you mean >>>> per device. >>> Obviously :) >>>>> Janani, maybe you can give it a try? >>>> I think we'd need to get it to work with shared gpio proxy which maybe >>>> will just get set up under the hood. This used to be opt in, but seems >>>> that changed fairly recently so maybe some of us are working with out >>>> of date knowledge! I haven't played with it yet, so might not be >>>> that simple. >>>> >>> What I meant for Janani was basically testing two devices on the same CS >>> as in my pseudo DT. For the GPIO, you mean having a way to select >>> between devices on the same CS? >>> >>> For these devices the pin id numbers get's setted up as part of the spi message >>> so my assumption is that all of them will receive the message but only one acks it. >>> >>> - Nuno Sá >> Hi Everyone, >> >> I tested the case where there are two devices on the same CS. The SPI core does reject it at spi_dev_check_cs(): >> https://github.com/torvalds/linux/blob/master/drivers/spi/spi.c#L631 > > Can you try again, but delete that check and allow the code to continue? > Worth knowing if the problem is policy (which makes sense for 99.99% of > devices that cannot share a chip select) or actually not supported by > the spi core code. Hi Conor, The CS conflict check is only a part of the problem. Even after removing it, the second device fails at the sysfs layer. The device naming in spi_dev_set_name() produces spi{bus}.{cs}. Both devices register as spi0.0 here, making it a duplicate directory. - Janani Sunil