From: "wsa@the-dreams.de" <wsa@the-dreams.de>
To: Peter Rosin <peda@axentia.se>
Cc: Vadim Pasternak <vadimp@nvidia.com>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>
Subject: Re: [Re-send: PATCH i2c-next 5/6] i2c: mux: mlxcpld: Extend driver to support word address space devices
Date: Tue, 12 Jan 2021 11:11:44 +0100 [thread overview]
Message-ID: <20210112101144.GA973@kunai> (raw)
In-Reply-To: <5860104a-f922-068d-18ca-32b69c7970f7@axentia.se>
[-- Attachment #1: Type: text/plain, Size: 578 bytes --]
> Wolfram, is there a better way to get something stable for user space to
> interact with? Is there maybe a way to do this with aliases or something?
> Setting up an ad-hoc scheme for forcing the adapter IDs feels a bit outdated.
Yeah, it feels rightfully outdated IMO. Bringing such policy into the
kernel is frowned upon. I think the proper way is a udev rule to act on
the newly created I2C adapter. This even could provide a really stable
symlink for userspace to consume. The above scheme is only stable per
"block" but inside the block, there is still randomness. Or?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2021-01-12 10:12 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-18 14:44 [Re-send: PATCH i2c-next 0/6] i2c: mux: mlxcpld: Extend driver functionality and update licenses Vadim Pasternak
2020-11-18 14:44 ` [Re-send: PATCH i2c-next 1/6] i2c: mux: mlxcpld: Update module license Vadim Pasternak
2020-11-18 14:44 ` [Re-send: PATCH i2c-next 2/6] platform/x86: " Vadim Pasternak
2020-11-18 14:44 ` [Re-send: PATCH i2c-next 3/6] i2c: mux: mlxcpld: Move header file out of x86 realm Vadim Pasternak
2020-11-18 14:44 ` [Re-send: PATCH i2c-next 4/6] i2c: mux: mlxcpld: Convert driver to platform driver Vadim Pasternak
2021-01-07 7:52 ` Peter Rosin
2020-11-18 14:44 ` [Re-send: PATCH i2c-next 5/6] i2c: mux: mlxcpld: Extend driver to support word address space devices Vadim Pasternak
2021-01-07 10:03 ` Peter Rosin
2021-01-07 20:43 ` Vadim Pasternak
2021-01-08 8:02 ` Peter Rosin
2021-01-11 18:11 ` Vadim Pasternak
2021-01-11 21:22 ` Peter Rosin
2021-01-11 23:24 ` Vadim Pasternak
2021-01-12 9:35 ` Peter Rosin
2021-01-12 10:11 ` wsa [this message]
2021-01-14 7:49 ` Peter Rosin
2021-01-14 18:43 ` Vadim Pasternak
2021-01-14 21:10 ` Peter Rosin
2021-01-14 21:13 ` Vadim Pasternak
2020-11-18 14:44 ` [Re-send: PATCH i2c-next 6/6] i2c: mux: mlxcpld: Extend supported mux number Vadim Pasternak
2021-01-07 10:10 ` Peter Rosin
2021-01-05 10:27 ` [Re-send: PATCH i2c-next 0/6] i2c: mux: mlxcpld: Extend driver functionality and update licenses Wolfram Sang
-- strict thread matches above, loose matches on Subject: below --
2020-11-18 13:49 Vadim Pasternak
2020-11-18 13:49 ` [Re-send: PATCH i2c-next 5/6] i2c: mux: mlxcpld: Extend driver to support word address space devices Vadim Pasternak
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=20210112101144.GA973@kunai \
--to=wsa@the-dreams.de \
--cc=linux-i2c@vger.kernel.org \
--cc=peda@axentia.se \
--cc=vadimp@nvidia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.