From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (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 0C4A131CA4E for ; Sun, 29 Mar 2026 15:39:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774798770; cv=none; b=ACXxz1NgYo8fJ4ZQa2/24mespqa6F3XqV5TCXtLActhtiHmawmiRXrk6r6JHw9t5vyKbPzh2ad0ES0uDCE4r9ndp2RoTv7njoMnrz64YnagqlQzQQSEaL2Zo9jyJFM/eDejI40bNCuqzs1AmdrM7fQjmJwH9LS5mlniE2OX2l78= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774798770; c=relaxed/simple; bh=f9bkPCnJFcQvISuOfBSlCQeraHO1cZrdldqjBgV+GK4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=K9WFp/sdIpaRJwRF+v8F53VV8hbSi78DoAiWlMZVbOEF1vj0LEM9Mofh+qGHjWRaFMFgJ/N5PtxR/GT+JyPV3yT2nFPzmMHMxabLY0iGyC6Ot3oJiBHDb09PQVDLHZzI/xGH7m7oI8xDk53HQCJGvU1iRI2CGsQz5ppeXrTnKmE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=mind.be; spf=pass smtp.mailfrom=essensium.com; dkim=pass (2048-bit key) header.d=mind.be header.i=@mind.be header.b=iIihNvWK; arc=none smtp.client-ip=209.85.128.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=mind.be Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=essensium.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mind.be header.i=@mind.be header.b="iIihNvWK" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-486b96760easo40428975e9.2 for ; Sun, 29 Mar 2026 08:39:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mind.be; s=google; t=1774798767; x=1775403567; 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=ggrAygJOKHK/5r5umOLbpC4E8qoXEWKCBm/VmuvUDWo=; b=iIihNvWKvxtgAO/8fCZ6bJGTdSDdHzqhXAltCWP7PRbO9hvEjvkHSLBitSlxV4baZZ swMcpL0r/68t8d1VXw6ICXgO0ljul5aE/MkC52mBYDezv1sXKdn2LC8pg8ZUhM7r5rMy wmshrb3D4cTjtm0FYBIkgrYUYgo2jQK9jkpcmqkTMc/v5rOmZwpEP1Ro6N7CINqJogjW NK2TPAI6Pv6FPVincg9i+5mE9W/kRoKoma9g5XqJJZIqgabrqZ4jcplbX8UJz6pJLPLg Xb8U14z8RXvPppV72lo2vmXTQzODlKAfQGowDdMpRJS0DliEIBKnhoUm00lLOZmHGa12 /G1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774798767; x=1775403567; 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=ggrAygJOKHK/5r5umOLbpC4E8qoXEWKCBm/VmuvUDWo=; b=SFy+zp2wO3mY4BuGqP2r/Bp3J8LH9Sdosrq1Jf5kZYX64UyOL5Vwoe/MtqGhPhzDzl GiRv8j7Y7GENAj76HHeMLv6qJfvhgTUNK6lfEqTVrWIvceWNZeJZ/nX8CVuRygn1F4VE 6G3SXlxeRbV4/3FWsFXIjEYep0pwnnsviFI2b4+13T/R6tvVO7PvGz5omA5aRZ4BhiMe 7eEWlv8vvNbToXrqA5yFXdCWzyhOGL/fht1KwKsnyaW8Qr5FpyJd+snBmnsqkP6JloXo tfK8GcorDTfizIqKhILxdv6evX4nJenY3OpZTLDhLx2TovkdRrrfRhl3u4y0Roib22kS zwuw== X-Forwarded-Encrypted: i=1; AJvYcCXFcpDFd9lcqDob6iz18Wl4vw9+tZHT6PXLepsndL3FBvuEyKa9FbezItUZ98CulmSLsEn3H51pEFtiTDY=@vger.kernel.org X-Gm-Message-State: AOJu0YzH3qfGDIFMZXS8KhvG0DEM5HczJFjMM2/XDAsQ0QjAzsIEsuIx 18AzwR4YY7gCKGaKOop6dtomVqYWBWVwJfdj7qZ/ZOiDk1/+kO4x4W/VIePM/Vsf4K4= X-Gm-Gg: ATEYQzyoPRttAZlGobpaspcrv9S31NT4YaT/owsIoecmB8Q2Y/+67t+F8eGSHc9rjox cGcPgplbpmPI/tk9/U8Z4Qmi6QJeIof/XSFYa++ArmzeZyoZBtXVkBiZuKJuETJxObHDKK9J8vu EVRE7VfdJyII30HYezAVIznyliFqWN4oY7Eo1y0OrLSggTgEZo2Tluox2AGy2NCt3c9myapxsOl boAjLZ0MI57AEDvcQqlpWfggBnwDTq6Y9pMUgD6aYplkMuD/O0QBHm/tY50DfZaE/MsYdjucnCe GGkDNOldszPr/5zHYvDUx15i2gxtfJlC43ovCGfdeOyO13coPDFFCF2Mvb/aFWp0S5JSgWm0lXE K1DdQtA1sqfzVNlapSmk0FV8N1okQtuH5ycqCQi5CQnPaJD1VVIv9Nm/NqE34TEZmUxQ4TMZ/SY fdeEGKReNhQyjDL7bqh+iegspLIA/M6tD9vyuyJPHdCJcg6AjWpVhbpjjZ9+kMtVOGrnuUvfNyo 02jnNJqEg== X-Received: by 2002:a05:600c:1d02:b0:485:4eaf:eb53 with SMTP id 5b1f17b1804b1-48727ec77b5mr172082365e9.19.1774798767119; Sun, 29 Mar 2026 08:39:27 -0700 (PDT) Received: from ?IPV6:2a02:578:85c6:1101:1ab9:445:1169:11e3? ([2a02:578:85c6:1101:1ab9:445:1169:11e3]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43cf21e3602sm12681746f8f.4.2026.03.29.08.39.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 29 Mar 2026 08:39:26 -0700 (PDT) Message-ID: <3a9dc8f9-0588-44ee-97ba-3a248d4f65dd@mind.be> Date: Sun, 29 Mar 2026 17:39:25 +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 1/2 v2] spi: add SPI_MOSI_IDLE_LOW support from device tree To: Marcelo Schmitt Cc: broonie@kernel.org, linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260329125725.2984756-1-charles-antoine.couret@mind.be> Content-Language: fr-FR, en-US From: Couret Charles-Antoine In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Le 29/03/26 à 16:25, Marcelo Schmitt a écrit : > Hello Charles-Antoine, > > On 03/29, charles-antoine.couret@mind.be wrote: >> From: Charles-Antoine Couret >> >> This flag was introduced but was not added as device tree property which is >> limiting the possibility to use this flag on real devices. > I'm not seeing why a device tree property is needed for SPI idle modes. For > idling high, the configuration is requested through spi_setup(). It should > work in similar way for idling low. See spi-summary.rst. If believe a dt > property is needed despite the spi_setup() interface, can you elaborate on why? Hi Marcelo, You're right that for a compliant SPI device, this devicetree option is not really relevant and this must be in the driver itself. However, I think the purpose of this mode is itself not designed for compliant SPI devices. It's not unusual to use Linux SPI subsystem for devices which are not fully compliant with SPI in embedded context and where both options (idle low or idle high) can make sense based on hardware design around the device or the feature that you want. So having this property in device tree is documenting the hardware then giving more flexibility. For example we used that to communicate with TI DAC161P997 device, where "IDLE low" setting can be used to detect when the device is really powered or not. But this is an optional setting, this option does not affect the rest of the driver. I can understand this is a corner case and you don't want to support it at all, I thought this can be interesting to provide it anyway. If you want to reject it, I understand. Thank you for the feedback and have a nice day. Regards,