From: "Gero Schwäricke" <gero.schwaericke@sevenlab.de>
To: "Brigham Campbell" <me@brighamcampbell.com>,
"Jean Delvare" <jdelvare@suse.de>, <linux-i2c@vger.kernel.org>
Cc: "Wolfram Sang" <wsa+renesas@sang-engineering.com>
Subject: Re: [PATCH v4 1/2] i2c-tools: Allow passing device file paths
Date: Fri, 17 Jul 2026 15:00:53 +0200 [thread overview]
Message-ID: <DK0V64S4JWAS.3PNF8V2ZQEDPY@sevenlab.de> (raw)
In-Reply-To: <DK02UVSWWGTN.2M4XXGFINRT1V@brighamcampbell.com>
Hi Brigham,
On Thu Jul 16, 2026 at 4:49 PM CEST, Brigham Campbell wrote:
> I agree that `open_i2c_dev_path()` should be inlined, but I don't think
> it would be a good idea to remove its `fprintf()` altogether. How about
> something like the following, which would make the error messages more
> orthogonal?
>
> if (errno != ENOENT) {
> fprintf(stderr, "Error: Could not open file "
> "`%s': %s\n", i2cbus_arg, strerror(errno));
> if (errno == EACCES)
> fprintf(stderr, "Run as root?\n");
> return file;
> }
>
> fprintf(stderr, "Error: `%s' is not a bus number, name, or device file "
> "path!\n", i2cbus_arg);
>
> If the i2cbus_arg parameter didn't appear to be a file (ENOENT), it will
> print an error indicating that all three methods failed. If it did
> appear to be a file but couldn't open the file for whatever reason, it
> will print the error along with a suggestion to run as root if it's a
> permissions issue. This behavior reflects the behavior of
> `open_i2c_dev_by_nr()`.
I'm unsure about this: Yes, this reflects the behavior of
`open_i2c_dev_by_nr()`, but we only call that after we have validated
that the input is indeed an adapter number. With the path we don't do
that, we just try to open the input as a path. We know it's not a valid
integer, and not a valid adapter name, but it may still not be a path,
maybe it's a mistyped adapter name.
To that I'm not sure we can conclude that `errno != ENOENT` means it is
indeed a path.
Looking at libgpiod (`gpiod_chip_open_lookup()`), they solved that by
assuming that all paths must start with `/dev/`. Unsure if we want to go
that route as well. It would definitely simplify things and I think for
the sake of progress that whould be fine. Thoughts?
Best,
Gero
--
sevenlab engineering GmbH <https://sevenlab.de>
serious engineering.
Geschäftsführer: Christian J. Pereira
Amtsgericht Köln, HRB 121730
Anschrift: Hansaring 20, 50670 Köln
next prev parent reply other threads:[~2026-07-17 13:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-06 4:27 [PATCH v4 0/2] i2c-tools: Make tools accept bus path Brigham Campbell
2026-07-06 4:27 ` [PATCH v4 1/2] i2c-tools: Allow passing device file paths Brigham Campbell
2026-07-09 12:18 ` Wolfram Sang
2026-07-09 12:40 ` Gero Schwäricke
2026-07-11 19:24 ` Wolfram Sang
2026-07-13 9:23 ` Gero Schwäricke
2026-07-13 15:06 ` Wolfram Sang
2026-07-14 9:30 ` Gero Schwäricke
2026-07-14 10:13 ` Wolfram Sang
2026-07-16 14:49 ` Brigham Campbell
2026-07-17 13:00 ` Gero Schwäricke [this message]
2026-07-19 22:22 ` Brigham Campbell
2026-07-13 9:37 ` Gero Schwäricke
2026-07-13 15:38 ` Brigham Campbell
2026-07-14 9:42 ` Gero Schwäricke
2026-07-16 14:17 ` Brigham Campbell
2026-07-06 4:27 ` [PATCH v4 2/2] i2c-tools: Document device paths as I2CBUS arg Brigham Campbell
2026-07-11 19:43 ` Wolfram Sang
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=DK0V64S4JWAS.3PNF8V2ZQEDPY@sevenlab.de \
--to=gero.schwaericke@sevenlab.de \
--cc=jdelvare@suse.de \
--cc=linux-i2c@vger.kernel.org \
--cc=me@brighamcampbell.com \
--cc=wsa+renesas@sang-engineering.com \
/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