From nobody Tue Feb 10 01:19:19 2026 Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) (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 B353B37F0E8 for ; Mon, 12 Jan 2026 17:46:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.41 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768240001; cv=none; b=U/QPgtsC7czxcUKq6qbiZR2YAlnZMXXXM1oxQHvDpge38NbBULj3xyhGIEZGLuPvvHFvYKuVw1+xsyhQV6yrCSU1ig0ZuQTcDjcKSS1u9GdOQxTcxOeZmoK0IOVP8V1ugtmGO/J9cesUYATezoacewfX9FRm0YofUIMwALhYmoI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768240001; c=relaxed/simple; bh=LUltyTseSHIB0eWsvKd5k7CM1sj/ygbKdi0CfX8XI5Y=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=jarg10FcenUj6r/XsevwZuI/te+YP9jLVW38mnOfPfzZJQKm8gAC0ry1Zs83oIsyzFlopSLvl5IQ2aRTUnSGKyHWlSCjXcsJ2ngsqbbg0hxmFAe5wre5+hh2Gw4DNWVZwsGYr7xOWyHKlB3He7iH2Kq61/m0EHLgl/4MzdBxCTo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com; spf=pass smtp.mailfrom=baylibre.com; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b=dB95nqva; arc=none smtp.client-ip=209.85.210.41 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="dB95nqva" Received: by mail-ot1-f41.google.com with SMTP id 46e09a7af769-7c76f65feb5so5424792a34.0 for ; Mon, 12 Jan 2026 09:46:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1768239991; x=1768844791; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=/xTAHRixVuqxs0O57y6EbN2F3QQoOxp90CtlWkeqDbM=; b=dB95nqvaCjTGoI0BsKN9h2DbqkvQ/5BNbnTrT1cMj4+ydCAfcl/Gu525iG7ZIMKKsU bkEsLEnt4UxCGjBYQEbBv/w6HBc/gaiGt3mWTQnsztvBkuFPf0fNfntQyJJP+jsBXeV6 5KkfrACbTIVT6TnaZlt3tLcQHfAMyPXQPF1AdSKSyDnLiiBKTfJZsEiWSY8zcN/MUV3L 432JWtTg5/24jHqdIx/OmtwgzNTHziYyrRsfcU9eAtA3DaxDp3ISW91QzdW2ibM0c5IY 8h+pml1Gy9kbEWmClcsNcssHwu6/Kph13bKP1b4fEiBHlIJofBKQ9kmYNEoeKZhCnJMP xGSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768239991; x=1768844791; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=/xTAHRixVuqxs0O57y6EbN2F3QQoOxp90CtlWkeqDbM=; b=oDjFqnXnEdqLVXKxvBFPJvBdoANJY1Do/7c7T13RGSdVO3fywAgNIgpCYHcKC3f+Yb DY+39cb+Z5sjoGT7/3asZxlc9t5DOZJvg+BOb2MkpfYHFL3rhQg4xGCF5IyCNzpA8MTS h3gKiTSHJHwC4KR/UqBS19TbOXqfhO+3/yhTv0lJc/NEbOgm58wr49ICcw4Ulmde1db4 IdM4mbJSy1eCA5kyGrilRE5nIGOu2cSnBiel6nkXoJWg2NDpzmOy/akxMgaXMd1kiFPv tw9zYItFMnuBp9kemc4EX8SsnwhmJQmyr7YWWZW4KVG1anBEvcdSZ6uelSzz5WeFjzIG raIA== X-Forwarded-Encrypted: i=1; AJvYcCUlAtJjSFmmnLBWCbTpc3tiq2z3pR6Yzhv74nyl95AwiLHMTQz1Ad+4uGJeayNU/z1BKT3HE4fcYnhNmLA=@vger.kernel.org X-Gm-Message-State: AOJu0Yym3qrYF4/oI+SUNIoX2TkGlBxOPizyiflJKyx8qWJXnrdUhUER g0a2iU235ihdDlxiSDcvbWcO7LRjS/CbaFAdM4L9iNjja4UB3WMv5uQ06E8Jv2PKg8o= X-Gm-Gg: AY/fxX69xA3wrxXBT8/qMtJ9HwsxcjoVkvFLs5dpkjpReDFkKJBMO2+pOF2HwTU/lf2 bpegQk9jQfeFj2HFDZjD/eY2gq91P0r2cegGR/VpaP2zQxhU9mXa8uXBZdYboHd8civPzTOmoF3 mIn/AJj43DRmG9CFOVDN4cyS6os+Ab8gvDqeAxyUs1sVQkb0pyuiG2jNglcaujiWHEuSNJKJ30i zKY/XarXjD/bXjHtBW0OwpE4taa4VzswdskKcRDouu4TrbpmHREm5bxdNa6kaPO0RDzIEPctUGa qxUvUzR/+lWtomrDYxD1uyvqhJD+4qJ4AZ6jxnQQ2UevJsX6p/xPRdb/Q/W0xv8oPtSnz8aFTrT wtmEjXQ7t+NFNjH+obTP3Sfus0v1xI9Tbn5MV8vB6qAhfkaaoOP0W4BYJqQQ4GUkH+pyxvja07E aVmvKigy+09IShoDM= X-Google-Smtp-Source: AGHT+IFwJxkYkRXklamjZLQ5Ezsu/RpFPePYADM5gAAE1rZrarULL0rlM1Pu+WCRABkUpZh6ZNR5fg== X-Received: by 2002:a4a:d597:0:b0:659:9a49:8f57 with SMTP id 006d021491bc7-65f54ef65b6mr6677190eaf.28.1768239991602; Mon, 12 Jan 2026 09:46:31 -0800 (PST) Received: from [127.0.1.1] ([2600:8803:e7e4:500:6b4b:49b3:cce5:b58f]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-3ffa4de40bfsm12126941fac.5.2026.01.12.09.46.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Jan 2026 09:46:31 -0800 (PST) From: David Lechner Date: Mon, 12 Jan 2026 11:45:21 -0600 Subject: [PATCH v5 3/9] spi: support controllers with multiple data lanes Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260112-spi-add-multi-bus-support-v5-3-295f4f09f6ba@baylibre.com> References: <20260112-spi-add-multi-bus-support-v5-0-295f4f09f6ba@baylibre.com> In-Reply-To: <20260112-spi-add-multi-bus-support-v5-0-295f4f09f6ba@baylibre.com> To: Mark Brown , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Marcelo Schmitt , Michael Hennerich , =?utf-8?q?Nuno_S=C3=A1?= , Jonathan Cameron , Andy Shevchenko Cc: Sean Anderson , linux-spi@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org, David Lechner X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=openpgp-sha256; l=9082; i=dlechner@baylibre.com; h=from:subject:message-id; bh=LUltyTseSHIB0eWsvKd5k7CM1sj/ygbKdi0CfX8XI5Y=; b=owGbwMvMwMV46IwC43/G/gOMp9WSGDJTjV1l9JhLK/eGrRFbFJJjvYZ7393Cos2swRerzq5Ud lg4SeN4J6MxCwMjF4OsmCLLG4mb85L4mq/NuZExA2YQKxPIFAYuTgGYSMYc9v8hk+fnVa55YD99 L++pnXFRncrNmWt2LNZNv8/FHvarY1vJ0SbFv1ODxfYrSNkF6LPPe+bNH+7hEips1Cm8KFXBata s88y/nrza2TtdUOM408E904I5pz84G3v18MYzoWsyXof1qhrkhDBp5oXu1y0N22GxyH6Nik6Gl8 93h6vZhZxM6yIeHcwujBW84dV0S7jn1BWrcx++HbyXwc8ctLB3cYZ03JZHCaEe/D4vYyU9ee/dz hO+ct3vVPU1v01HGv82M0aGhoWFthvzyjr0ms3e/6NuZaO/Ru+dv4FznJgczjnsufuopKnBRnaH cbqJvEN2W+e5le6iTWxTvgpZrm6evCPxqK4de8pJ+R2fAA== X-Developer-Key: i=dlechner@baylibre.com; a=openpgp; fpr=8A73D82A6A1F509907F373881F8AF88C82F77C03 Add support for SPI controllers with multiple physical SPI data lanes. (A data lane in this context means lines connected to a serializer, so a controller with two data lanes would have two serializers in a single controller). This is common in the type of controller that can be used with parallel flash memories, but can be used for general purpose SPI as well. To indicate support, a controller just needs to set ctlr->num_data_lanes to something greater than 1. Peripherals indicate which lane they are connected to via device tree (ACPI support can be added if needed). The spi-{tx,rx}-bus-width DT properties can now be arrays. The length of the array indicates the number of data lanes, and each element indicates the bus width of that lane. For now, we restrict all lanes to have the same bus width to keep things simple. Support for an optional controller lane mapping property is also implemented. Signed-off-by: David Lechner --- v5 changes: - Use of_property_read_variable_u32_array() for lane maps. v4 changes: - Update for changes in devicetree bindings. - Don't put new fields in the middle of CS fields. - Dropped acks since this was a significant rework. v3 changes: * Renamed "buses" to "lanes" to reflect devicetree property name change. This patch has been seen in a different series [1] by Sean before: [1]: https://lore.kernel.org/linux-spi/20250616220054.3968946-4-sean.anders= on@linux.dev/ Changes: * Use u8 array instead of bitfield so that the order of the mapping is preserved. (Now looks very much like chip select mapping.) * Added doc strings for added fields. * Tweaked the comments. --- drivers/spi/spi.c | 116 ++++++++++++++++++++++++++++++++++++++++++++= +++- include/linux/spi/spi.h | 22 +++++++++ 2 files changed, 136 insertions(+), 2 deletions(-) diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index e25df9990f82..5c3f9ba3f606 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -2370,7 +2370,53 @@ static int of_spi_parse_dt(struct spi_controller *ct= lr, struct spi_device *spi, spi->mode |=3D SPI_CS_HIGH; =20 /* Device DUAL/QUAD mode */ - if (!of_property_read_u32(nc, "spi-tx-bus-width", &value)) { + + rc =3D of_property_read_variable_u32_array(nc, "spi-tx-lane-map", + spi->tx_lane_map, 1, + ARRAY_SIZE(spi->tx_lane_map)); + if (rc =3D=3D -EINVAL) { + /* Default lane map */ + for (idx =3D 0; idx < ARRAY_SIZE(spi->tx_lane_map); idx++) + spi->tx_lane_map[idx] =3D idx; + } else if (rc < 0) { + dev_err(&ctlr->dev, + "failed to read spi-tx-lane-map property: %d\n", rc); + return rc; + } + + rc =3D of_property_count_u32_elems(nc, "spi-tx-bus-width"); + if (rc < 0 && rc !=3D -EINVAL) { + dev_err(&ctlr->dev, + "failed to read spi-tx-bus-width property: %d\n", rc); + return rc; + } + + if (rc =3D=3D -EINVAL) { + /* Default when property is not present. */ + spi->num_tx_lanes =3D 1; + } else { + u32 first_value; + + spi->num_tx_lanes =3D rc; + + for (idx =3D 0; idx < spi->num_tx_lanes; idx++) { + of_property_read_u32_index(nc, "spi-tx-bus-width", idx, + &value); + + /* + * For now, we only support all lanes having the same + * width so we can keep using the existing mode flags. + */ + if (!idx) + first_value =3D value; + else if (first_value !=3D value) { + dev_err(&ctlr->dev, + "spi-tx-bus-width has inconsistent values: first %d vs later %d\n", + first_value, value); + return -EINVAL; + } + } + switch (value) { case 0: spi->mode |=3D SPI_NO_TX; @@ -2394,7 +2440,62 @@ static int of_spi_parse_dt(struct spi_controller *ct= lr, struct spi_device *spi, } } =20 - if (!of_property_read_u32(nc, "spi-rx-bus-width", &value)) { + for (idx =3D 0; idx < spi->num_tx_lanes; idx++) { + if (spi->tx_lane_map[idx] >=3D spi->controller->num_data_lanes) { + dev_err(&ctlr->dev, + "spi-tx-lane-map has invalid value %d (num_data_lanes=3D%d)\n", + spi->tx_lane_map[idx], + spi->controller->num_data_lanes); + return -EINVAL; + } + } + + rc =3D of_property_read_variable_u32_array(nc, "spi-rx-lane-map", + spi->rx_lane_map, 1, + ARRAY_SIZE(spi->rx_lane_map)); + if (rc =3D=3D -EINVAL) { + /* Default lane map */ + for (idx =3D 0; idx < ARRAY_SIZE(spi->rx_lane_map); idx++) + spi->rx_lane_map[idx] =3D idx; + } else if (rc < 0) { + dev_err(&ctlr->dev, + "failed to read spi-rx-lane-map property: %d\n", rc); + return rc; + } + + rc =3D of_property_count_u32_elems(nc, "spi-rx-bus-width"); + if (rc < 0 && rc !=3D -EINVAL) { + dev_err(&ctlr->dev, + "failed to read spi-rx-bus-width property: %d\n", rc); + return rc; + } + + if (rc =3D=3D -EINVAL) { + /* Default when property is not present. */ + spi->num_rx_lanes =3D 1; + } else { + u32 first_value; + + spi->num_rx_lanes =3D rc; + + for (idx =3D 0; idx < spi->num_rx_lanes; idx++) { + of_property_read_u32_index(nc, "spi-rx-bus-width", idx, + &value); + + /* + * For now, we only support all lanes having the same + * width so we can keep using the existing mode flags. + */ + if (!idx) + first_value =3D value; + else if (first_value !=3D value) { + dev_err(&ctlr->dev, + "spi-rx-bus-width has inconsistent values: first %d vs later %d\n", + first_value, value); + return -EINVAL; + } + } + switch (value) { case 0: spi->mode |=3D SPI_NO_RX; @@ -2418,6 +2519,16 @@ static int of_spi_parse_dt(struct spi_controller *ct= lr, struct spi_device *spi, } } =20 + for (idx =3D 0; idx < spi->num_rx_lanes; idx++) { + if (spi->rx_lane_map[idx] >=3D spi->controller->num_data_lanes) { + dev_err(&ctlr->dev, + "spi-rx-lane-map has invalid value %d (num_data_lanes=3D%d)\n", + spi->rx_lane_map[idx], + spi->controller->num_data_lanes); + return -EINVAL; + } + } + if (spi_controller_is_target(ctlr)) { if (!of_node_name_eq(nc, "slave")) { dev_err(&ctlr->dev, "%pOF is not called 'slave'\n", @@ -3066,6 +3177,7 @@ struct spi_controller *__spi_alloc_controller(struct = device *dev, mutex_init(&ctlr->add_lock); ctlr->bus_num =3D -1; ctlr->num_chipselect =3D 1; + ctlr->num_data_lanes =3D 1; ctlr->target =3D target; if (IS_ENABLED(CONFIG_SPI_SLAVE) && target) ctlr->dev.class =3D &spi_target_class; diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index cb2c2df31089..7aff60ab257e 100644 --- a/include/linux/spi/spi.h +++ b/include/linux/spi/spi.h @@ -23,6 +23,9 @@ /* Max no. of CS supported per spi device */ #define SPI_DEVICE_CS_CNT_MAX 4 =20 +/* Max no. of data lanes supported per spi device */ +#define SPI_DEVICE_DATA_LANE_CNT_MAX 8 + struct dma_chan; struct software_node; struct ptp_system_timestamp; @@ -174,6 +177,10 @@ extern void spi_transfer_cs_change_delay_exec(struct s= pi_message *msg, * @cs_index_mask: Bit mask of the active chipselect(s) in the chipselect = array * @cs_gpiod: Array of GPIO descriptors of the corresponding chipselect li= nes * (optional, NULL when not using a GPIO line) + * @tx_lane_map: Map of peripheral lanes (index) to controller lanes (valu= e). + * @num_tx_lanes: Number of transmit lanes wired up. + * @rx_lane_map: Map of peripheral lanes (index) to controller lanes (valu= e). + * @num_rx_lanes: Number of receive lanes wired up. * * A @spi_device is used to interchange data between an SPI target device * (usually a discrete chip) and CPU memory. @@ -242,6 +249,12 @@ struct spi_device { =20 struct gpio_desc *cs_gpiod[SPI_DEVICE_CS_CNT_MAX]; /* Chip select gpio de= sc */ =20 + /* Multi-lane SPI controller support. */ + u32 tx_lane_map[SPI_DEVICE_DATA_LANE_CNT_MAX]; + u32 num_tx_lanes; + u32 rx_lane_map[SPI_DEVICE_DATA_LANE_CNT_MAX]; + u32 num_rx_lanes; + /* * Likely need more hooks for more protocol options affecting how * the controller talks to each chip, like: @@ -401,6 +414,7 @@ extern struct spi_device *spi_new_ancillary_device(stru= ct spi_device *spi, u8 ch * SPI targets, and are numbered from zero to num_chipselects. * each target has a chipselect signal, but it's common that not * every chipselect is connected to a target. + * @num_data_lanes: Number of data lanes supported by this controller. Def= ault is 1. * @dma_alignment: SPI controller constraint on DMA buffers alignment. * @mode_bits: flags understood by this controller driver * @buswidth_override_bits: flags to override for this controller driver @@ -576,6 +590,14 @@ struct spi_controller { */ u16 num_chipselect; =20 + /* + * Some specialized SPI controllers can have more than one physical + * data lane interface per controller (each having it's own serializer). + * This specifies the number of data lanes in that case. Other + * controllers do not need to set this (defaults to 1). + */ + u16 num_data_lanes; + /* Some SPI controllers pose alignment requirements on DMAable * buffers; let protocol drivers know about these requirements. */ --=20 2.43.0