From: sashiko-bot@kernel.org
To: "Ross Cawston" <ross@r-sc.ca>
Cc: devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: i2c: add GPIO buses sharing one SCL line
Date: Sun, 18 Oct 2026 19:56:04 +0000 [thread overview]
Message-ID: <sashiko-outbox-176354@kernel.org> (raw)
In-Reply-To: <20261018194315.945-2-ross@r-sc.ca>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dt-bindings: i2c: redundant i2c-gpio-shared-scl binding duplicates i2c-gpio
--
commit ee80c5111c8336e97eace1faedb4188f4c454089
Author: Ross Cawston <ross@r-sc.ca>
dt-bindings: i2c: add GPIO buses sharing one SCL line
This commit adds a Device Tree binding for bit-banged I2C buses that share
a single SCL GPIO line across child bus nodes, each with its own SDA GPIO
line.
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-gpio-shared-scl.yaml b/Documentation/devicetree/bindings/i2c/i2c-gpio-shared-scl.yaml
> new file mode 100644
> index 0000000000000..e725120973ad2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-gpio-shared-scl.yaml
> @@ -0,0 +1,94 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/i2c/i2c-gpio-shared-scl.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Bit-banged I2C buses sharing one SCL line
> +
> +maintainers:
> + - Ross Cawston <ross@r-sc.ca>
> +
> +description: |
> + Several I2C buses bit-banged on GPIOs, with one SCL line common to all of
> + them and one SDA line per bus. Each child node is a separate I2C bus.
> + Transfers are serialized, so only one bus clocks SCL at a time.
> +
> +properties:
> + compatible:
> + const: i2c-gpio-shared-scl
> +
> + scl-gpios:
> + description: The shared SCL line, usually open drain.
> + maxItems: 1
> +
> + i2c-gpio,delay-us:
> + description: Half the clock period in microseconds, as for i2c-gpio.
> + default: 5
> +
> + i2c-gpio,timeout-ms:
> + description: Clock stretching timeout in milliseconds, as for i2c-gpio.
> + default: 100
> +
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> +patternProperties:
> + "^i2c@[0-9a-f]+$":
> + $ref: /schemas/i2c/i2c-controller.yaml#
> + unevaluatedProperties: false
> +
> + properties:
> + reg:
> + description: Index of the bus, for naming only.
> + maxItems: 1
> +
> + sda-gpios:
> + description: The SDA line of this bus, usually open drain.
> + maxItems: 1
> +
> + required:
> + - reg
> + - sda-gpios
[Severity: Medium]
Is a separate i2c-gpio-shared-scl binding needed here? The existing
i2c-gpio binding in Documentation/devicetree/bindings/i2c/i2c-gpio.yaml and
the driver in drivers/i2c/busses/i2c-gpio.c already support multiple buses
sharing a single SCL GPIO line (added in commit 645c3d7d07fa ("i2c:
i2c-gpio: Enhance driver for buses with shared SCL") for Realtek switches).
In drivers/i2c/busses/i2c-gpio.c, i2c_gpio_create_scl() and
i2c_gpio_lookup_scl() match the scl-gpios phandle and specifier cells across
standard i2c-gpio nodes:
drivers/i2c/busses/i2c-gpio.c:i2c_gpio_create_scl() {
if (fwnode) {
ret = fwnode_property_get_reference_args(fwnode, "scl-gpios",
"#gpio-cells", 0, 0, &args);
if (ret)
/* try the ancient way */
ret = fwnode_property_get_reference_args(fwnode, "gpios",
"#gpio-cells", 0, 1, &args);
if (!ret) {
if (args.nargs >= 1)
sharable = true;
else
fwnode_handle_put(args.fwnode);
}
}
}
That existing mechanism refcounts the shared struct gpio_desc and serializes
transfers across all adapters sharing the SCL line via i2c_gpio_lock_ops and
scl->lock, while preserving standard per-bus i2c-gpio properties (such as
per-bus i2c-gpio,delay-us, i2c-gpio,timeout-ms, i2c-gpio,sda-output-only,
and i2c-gpio,scl-output-only).
Also, defining a virtual parent container node and child reg properties
described as "Index of the bus, for naming only" runs counter to
Documentation/devicetree/bindings/writing-bindings.rst regarding driver-only
container nodes and arbitrary software instance indices. Could standard
i2c-gpio nodes referencing the same scl-gpios phandle be used instead?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261018194315.945-1-ross@r-sc.ca?part=1
next prev parent reply other threads:[~2026-10-18 19:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-18 19:43 [PATCH 0/2] i2c: add GPIO buses sharing one SCL line Ross Cawston
2026-10-18 19:43 ` [PATCH 1/2] dt-bindings: " Ross Cawston
2026-10-18 19:56 ` sashiko-bot [this message]
2026-10-18 19:43 ` [PATCH 2/2] i2c: add driver for " Ross Cawston
2026-10-18 20:04 ` sashiko-bot
2026-10-19 6:59 ` Uwe Kleine-König
2026-10-18 21:20 ` [PATCH 0/2] i2c: add " Ross Cawston
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-176354@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=robh@kernel.org \
--cc=ross@r-sc.ca \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox