All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Andi Shyti <andi.shyti@kernel.org>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Jan Dabros <jsd@semihalf.com>, Raag Jadav <raag.jadav@intel.com>,
	linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/6] i2c: designware: Combine some of the common functions
Date: Mon, 19 Jan 2026 15:18:34 +0200	[thread overview]
Message-ID: <aW4vKo0kROZaPsMp@kuha> (raw)
In-Reply-To: <aVPeQmagzL-QEbIV@kuha>

Tue, Dec 30, 2025 at 04:14:32PM +0200, Heikki Krogerus kirjoitti:
> Hi Andy,
> 
> > > -	snprintf(adap->name, sizeof(adap->name),
> > > -		 "Synopsys DesignWare I2C Slave adapter");
> > 
> > This patch changes the user visible strings (via `i2cdetect`) or module names
> > in case we want to find it by name (note, we already have such precedents for
> > other adapters). Currently we have three variants if I not miss anything:
> > Generic for master (as in this change), Generic for slave, and AMD platform
> > driver case. If you think this is okay change, then just drop the AMD case
> > as well, and hence remove the no more needed conditional. Otherwise I would
> > somehow group this naming in one place, if possible.
> 
> The only thing that this will change is, it removes the common
> slave/target only description, because after this that setup is no
> longer possible - master mode is now always supported. So this is the
> correct thing to do.
> 
> I don't think the user space should ever rely on a description like
> this except possibly with some customised/non-common systems that the
> user space really has to handle in some specific way, but if something
> really did rely on this common "target only" description, it could
> have only used it to determine that it basically can't use the device
> for anything as it's slave/target only - so basically to use it to
> check the functionality (same as i2cdetect -F). But as said, this is
> no longer a problem.
> 
> As for the AMD case, if I understood what you are proposing, I
> disagree with you. The glue drivers should always be allowed to assign
> the name (these would be the "non-common" systems that the user space
> may actually need to know about). I'm also against grouping the
> naming. The glue drivers must handle the platform specifics including
> the naming if needed, not the core.

Ping.

-- 
heikki

  reply	other threads:[~2026-01-19 13:19 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-18 15:14 [PATCH v2 0/6] i2c: designware: Enable mode swapping Heikki Krogerus
2025-12-18 15:15 ` [PATCH v2 1/6] i2c: designware: Remove useless driver specific option for I2C target Heikki Krogerus
2025-12-18 15:15 ` [PATCH v2 2/6] i2c: designware: Remove unnecessary function exports Heikki Krogerus
2025-12-18 15:15 ` [PATCH v2 3/6] i2c: designware: Combine some of the common functions Heikki Krogerus
2025-12-27 15:52   ` Andy Shevchenko
2025-12-30 14:14     ` Heikki Krogerus
2026-01-19 13:18       ` Heikki Krogerus [this message]
2026-01-19 13:44         ` Andy Shevchenko
2026-01-19 13:49           ` Heikki Krogerus
2025-12-18 15:15 ` [PATCH v2 4/6] i2c: designware: Combine the init functions Heikki Krogerus
2025-12-27 15:53   ` Andy Shevchenko
2025-12-18 15:15 ` [PATCH v2 5/6] i2c: designware: Enable mode swapping Heikki Krogerus
2025-12-18 15:15 ` [PATCH v2 6/6] i2c: designware: Remove an unnecessary condition Heikki Krogerus
2025-12-27 15:32   ` Andy Shevchenko
2025-12-19  7:43 ` [PATCH v2 0/6] i2c: designware: Enable mode swapping Mika Westerberg
2025-12-27 20:17 ` Andi Shyti

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=aW4vKo0kROZaPsMp@kuha \
    --to=heikki.krogerus@linux.intel.com \
    --cc=andi.shyti@kernel.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=jsd@semihalf.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=raag.jadav@intel.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.