From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) (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 74E0013AED for ; Sun, 7 Jan 2024 23:03:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=baylibre.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b="IvP3RIHx" Received: by mail-lj1-f180.google.com with SMTP id 38308e7fff4ca-2cd46e7ae8fso9365771fa.1 for ; Sun, 07 Jan 2024 15:03:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1704668587; x=1705273387; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=NUyJMmMauN0ROH+iLyigz7sdMZl69TBxoZLyZcJhrlY=; b=IvP3RIHxqwHWGaeXXYuNkZgD+2FVmtn9/hjapkI5IcF46v1pr6l4qRpVOBDc3mT3MA SE1+csR5OffPJJ265LwNQaytgh5MxbvjcVvX38CwizLBUzu5C9K1rUTJhsexnP67AthJ Xh+TaUewVTD5pI6FyWDDTkBVTSjj+l2bZGY1h7XlHjhHwgHHpLvj/3MoVCVv3EmKCXpr 2N3mCyF3FQxi84wwRJEueX5gDtVSpnTdeCiTx9dnmlGKE37Rz3RGuAmoZ5DM+iZV5Z8e Ac7p5OkvPOws3LoucHwBlw2CFGqVEiFNavIjfH+Sj4qkhmXoXt/JZrvL8oybNEPG3sAF co8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704668587; x=1705273387; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=NUyJMmMauN0ROH+iLyigz7sdMZl69TBxoZLyZcJhrlY=; b=LPrQpH0L/3vPzuEnOdzGGgUPJDyGitIn5rXm7XK8VFlTLpNhc/ZW8o1bmByDVvxJQV Dw3v1IiRUlkv2rdNVhDyBpjcAl1LI7+oxybf6xcgipPNL+UI8zoPF2b1HSLZ6Q4ST5x6 dY/gejMvKalWEPT3gATCJq1ZFl65rZORNL7Cg1uRVva7oA4A0cwWxVeYQqcuQhxMF+Jc kJm4nP0hTm4A69BwF2/CABADh4uLsuXRWnKlTrIwW8UEcXlDIhcBofTa4l+etqZReKrb c6jKF2CG4wJxuzP0cxTfMJo8a9l7BZ28Yr6YBCzqokpv7qucyiYdcjV7buBzBogFoHDa 8zDQ== X-Gm-Message-State: AOJu0YwK2UX3G6FVRacONtDeQdsGsz7gBCBsDlnhsym8QFgxRGMDUj5e TLo7mq1Amq3tlLJLX2G7k41XmbARvpFw9gObHuj6BwTaFBLjWg== X-Google-Smtp-Source: AGHT+IHoja2EIV1WYLymw+3UxRqHYksIv6dVgMukAHkD5wcpYIp2E8pb1gj69ZiXnSThS/LchOcP1Xj7/PYUHgQCUyA= X-Received: by 2002:a05:651c:3de:b0:2cc:5945:4e22 with SMTP id f30-20020a05651c03de00b002cc59454e22mr476364ljp.85.1704668587219; Sun, 07 Jan 2024 15:03:07 -0800 (PST) Precedence: bulk X-Mailing-List: linux-spi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20231215-ad7380-mainline-v3-0-7a11ebf642b9@baylibre.com> <20231215-ad7380-mainline-v3-1-7a11ebf642b9@baylibre.com> <20240107164356.3e8df266@jic23-huawei> In-Reply-To: From: David Lechner Date: Sun, 7 Jan 2024 17:02:56 -0600 Message-ID: Subject: Re: [PATCH v3 1/3] dt-bindings: spi: add spi-rx-bus-channels peripheral property To: Mark Brown Cc: Jonathan Cameron , linux-iio@vger.kernel.org, linux-spi@vger.kernel.org, devicetree@vger.kernel.org, Rob Herring , Krzysztof Kozlowski , Conor Dooley , Michael Hennerich , =?UTF-8?B?TnVubyBTw6E=?= , Liam Girdwood , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jan 7, 2024 at 3:27=E2=80=AFPM Mark Brown wrot= e: > > On Sun, Jan 07, 2024 at 04:43:56PM +0000, Jonathan Cameron wrote: > > David Lechner wrote: > > > > This adds a new spi-rx-bus-channels property to the generic spi > > > peripheral property bindings. This property is used to describe > > > devices that have parallel data output channels. > > > > This property is different from spi-rx-bus-width in that the latter > > > means that we are reading multiple bits of a single word at one time > > > while the former means that we are reading single bits of multiple wo= rds > > > at the same time. > > > Mark, could you take a look at this SPI binding change when you have ti= me? > > Please submit patches using subject lines reflecting the style for the > subsystem, this makes it easier for people to identify relevant patches. > Look at what existing commits in the area you're changing are doing and > make sure your subject lines visually resemble what they're doing. > There's no need to resubmit to fix this alone. Are you saying that `spi: dt-bindings:` should be preferred over `dt-bindings: spi:`? I thought I was doing it right since I was following the guidelines of [1] which says: > The preferred subject prefix for binding patches is: > "dt-bindings: : ..." [1]: https://www.kernel.org/doc/html//v6.7/devicetree/bindings/submitting-p= atches.html > > > I don't want to apply it without your view on whether this makes sense > > from a general SPI point of view as we all hate maintaining bindings > > if they turn out to not be sufficiently future looking etc and we need > > to deprecate them in favour of something else. > > This makes no sense to me without a corresponding change in the SPI core > and possibly controller support, though I guess you could do data > manging to rewrite from a normal parallel SPI to this for a pure > software implementation. I also see nothing in the driver that even > attempts to parse this so I can't see how it could possibly work. We currently don't have a controller that supports this. This is just an attempt to make a complete binding for a peripheral according to [2] which says: > DO attempt to make bindings complete even if a driver doesn't support som= e features [2]: https://www.kernel.org/doc/html//v6.7/devicetree/bindings/writing-bind= ings.html So, will DT maintainers accept an incomplete binding for the peripheral? Or will you reconsider this without SPI core support if I can explain it better? It doesn't seem like a reasonable request to expect us to spend time developing software that we don't need at this time just to get a complete DT binding accepted for a feature that isn't being used. In the SPI core, I would expect this property to correspond to new flags `SPI_RX_2_CH`, `SPI_RX_4_CH`, `SPI_RX_8_CH` and it would have checks similar to other flags to make sure controller supports the flag if the peripheral requires it. Likewise, struct spi_transfer would probably need a rx_n_ch field similar to rx_nbits to specify if individual xfers use the feature. But beyond that, yes I agree it would be difficult to say how it should work without implementing it on actual hardware.