public inbox for linux-i2c@vger.kernel.org
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali@kernel.org>
To: Hans de Goede <hdegoede@redhat.com>
Cc: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Andy Shevchenko" <andy@kernel.org>,
	"Paul Menzel" <pmenzel@molgen.mpg.de>,
	"Wolfram Sang" <wsa@kernel.org>,
	eric.piel@tremplin-utc.net, "Marius Hoch" <mail@mariushoch.de>,
	Dell.Client.Kernel@dell.com,
	"Kai Heng Feng" <kai.heng.feng@canonical.com>,
	platform-driver-x86@vger.kernel.org,
	"Jean Delvare" <jdelvare@suse.com>,
	"Andi Shyti" <andi.shyti@kernel.org>,
	linux-i2c@vger.kernel.org
Subject: Re: [PATCH v3 2/6] i2c: i801: Use a different adapter-name for IDF adapters
Date: Sat, 22 Jun 2024 16:08:40 +0200	[thread overview]
Message-ID: <20240622140840.n5733l4ere26gnra@pali> (raw)
In-Reply-To: <8c45cc19-2164-46ea-a388-de23885c3323@redhat.com>

On Saturday 22 June 2024 15:56:03 Hans de Goede wrote:
> Hi,
> 
> On 6/22/24 2:46 PM, Pali Rohár wrote:
> > On Friday 21 June 2024 14:24:57 Hans de Goede wrote:
> >> On chipsets with a second 'Integrated Device Function' SMBus controller use
> >> a different adapter-name for the second IDF adapter.
> >>
> >> This allows platform glue code which is looking for the primary i801
> >> adapter to manually instantiate i2c_clients on to differentiate
> >> between the 2.
> >>
> >> This allows such code to find the primary i801 adapter by name, without
> >> needing to duplicate the PCI-ids to feature-flags mapping from i2c-i801.c.
> >>
> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> >> ---
> >>  drivers/i2c/busses/i2c-i801.c | 9 +++++++--
> >>  1 file changed, 7 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
> >> index d2d2a6dbe29f..5ac5bbd60d45 100644
> >> --- a/drivers/i2c/busses/i2c-i801.c
> >> +++ b/drivers/i2c/busses/i2c-i801.c
> >> @@ -1760,8 +1760,13 @@ static int i801_probe(struct pci_dev *dev, const struct pci_device_id *id)
> >>  
> >>  	i801_add_tco(priv);
> >>  
> >> -	snprintf(priv->adapter.name, sizeof(priv->adapter.name),
> >> -		"SMBus I801 adapter at %04lx", priv->smba);
> >> +	if (priv->features & FEATURE_IDF)
> >> +		snprintf(priv->adapter.name, sizeof(priv->adapter.name),
> >> +			"SMBus I801 IDF adapter at %04lx", priv->smba);
> >> +	else
> >> +		snprintf(priv->adapter.name, sizeof(priv->adapter.name),
> >> +			"SMBus I801 adapter at %04lx", priv->smba);
> >> +
> > 
> > User visible name is identifier for user / human.
> > 
> > If somebody is going to read this code in next 10 years then can ask
> > question why to have different name for IDF FEATURE and not also for
> > other features? And can come to conclusion to unify all names to be
> > same (why not? it is user identifier).
> 
> That is a good point, I'll add a comment about this for the next
> version.
> 
> > Depending on user names between different kernel subsystem is fragile,
> > specially for future as rename can happen.
> 
> Relying no devices names to find devices is standard practice. E.g.
> this is how 99% of the platform drivers bind to platform devices
> by the driver and the device having the same name.

But here it is adapter name which is more likely description, not the
device name which is used for binding.

> > If you are depending on FEATURE_IDF flag then check for the flag
> > directly, and not hiding the flag by serializing it into the user
> > visible name (char[] variable) and then de-serializing it in different
> > kernel subsystem. If the flag is not exported yet then export it via
> > some function or other API.
> 
> Exporting this through some new function is non trivial and adds
> extra dependencies between modules, causing issues when one is builtin
> and the other is build as a module.

Access to "struct i801_priv *" is not possible? For example via
dev_get_drvdata() on "struct device *" which you have in
smo8800_find_i801()?

Because if it is possible then you can create an inline function in some
shared header file which access this flag. Not perfect (as accessing
private data is not the best thing) but can avoid dependences between
modules.

> The name check OTOH allows the modules to be less tightly coupled
> and there is plenty of precedence for using a name check here.
> 
> Regards,
> 
> Hans
> 
> 
> 
> >>  	err = i2c_add_adapter(&priv->adapter);
> >>  	if (err) {
> >>  		platform_device_unregister(priv->tco_pdev);
> >> -- 
> >> 2.45.1
> >>
> > 
> 

  reply	other threads:[~2024-06-22 14:08 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-21 12:24 [PATCH v3 0/6] i2c-i801 / dell-smo8800: Move instantiation of lis3lv02d i2c_client from i2c-i801 to dell-smo8800 Hans de Goede
2024-06-21 12:24 ` [PATCH v3 1/6] i2c: core: Setup i2c_adapter runtime-pm before calling device_add() Hans de Goede
2024-06-21 15:08   ` Andy Shevchenko
2024-06-21 12:24 ` [PATCH v3 2/6] i2c: i801: Use a different adapter-name for IDF adapters Hans de Goede
2024-06-21 15:13   ` Andy Shevchenko
2024-06-22 12:46   ` Pali Rohár
2024-06-22 13:56     ` Hans de Goede
2024-06-22 14:08       ` Pali Rohár [this message]
2024-06-22 14:14         ` Hans de Goede
2024-06-22 14:23           ` Pali Rohár
2024-06-22 14:29             ` Hans de Goede
2024-06-22 15:07               ` Pali Rohár
2024-06-23 13:58                 ` Hans de Goede
2024-06-21 12:24 ` [PATCH v3 3/6] platform/x86: dell-smo8800: Move instantiation of lis3lv02d i2c_client from i2c-i801 to dell-smo8800 Hans de Goede
2024-06-21 15:24   ` Andy Shevchenko
2024-06-22 13:59     ` Hans de Goede
2024-06-22 13:16   ` Pali Rohár
2024-06-22 14:06     ` Hans de Goede
2024-06-22 14:20       ` Pali Rohár
2024-06-22 14:26         ` Hans de Goede
2024-06-22 15:12           ` Pali Rohár
2024-06-22 16:35             ` Pali Rohár
2024-06-23 13:56               ` Hans de Goede
2024-06-23 14:09                 ` Hans de Goede
2024-06-22 22:36           ` Andy Shevchenko
2024-06-22 22:41             ` Pali Rohár
2024-06-22 16:26         ` Pali Rohár
2024-06-23 13:46           ` Hans de Goede
2024-06-22 16:43         ` Pali Rohár
2024-06-22 22:43           ` Andy Shevchenko
2024-06-22 22:50             ` Pali Rohár
2024-06-22 22:53               ` Andy Shevchenko
2024-06-23 14:00           ` Hans de Goede
2024-06-22 15:35   ` Pali Rohár
2024-06-23 13:45     ` Hans de Goede
2024-06-23 14:30   ` Pali Rohár
2024-06-21 12:24 ` [PATCH v3 4/6] platform/x86: dell-smo8800: Allow lis3lv02d i2c_client instantiation without IRQ Hans de Goede
2024-06-21 15:30   ` Andy Shevchenko
2024-06-22 13:20   ` Pali Rohár
2024-06-22 14:07     ` Hans de Goede
2024-06-22 15:14       ` Pali Rohár
2024-06-21 12:25 ` [PATCH v3 5/6] platform/x86: dell-smo8800: Add a couple more models to dell_lis3lv02d_devices[] Hans de Goede
2024-06-21 12:25 ` [PATCH v3 6/6] platform/x86: dell-smo8800: Add support for probing for the accelerometer i2c address Hans de Goede
2024-06-21 15:37   ` Andy Shevchenko
2024-06-22 13:32   ` Pali Rohár
2024-06-22 14:21     ` Hans de Goede
2024-06-22 14:50       ` Pali Rohár
2024-06-22 22:50         ` Andy Shevchenko

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=20240622140840.n5733l4ere26gnra@pali \
    --to=pali@kernel.org \
    --cc=Dell.Client.Kernel@dell.com \
    --cc=andi.shyti@kernel.org \
    --cc=andy@kernel.org \
    --cc=eric.piel@tremplin-utc.net \
    --cc=hdegoede@redhat.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=jdelvare@suse.com \
    --cc=kai.heng.feng@canonical.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=mail@mariushoch.de \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=pmenzel@molgen.mpg.de \
    --cc=wsa@kernel.org \
    /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