All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Jean Delvare <jdelvare@suse.de>
Cc: Wolfram Sang <wsa@the-dreams.de>,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	Andrew Duggan <aduggan@synaptics.com>,
	linux-kernel@vger.kernel.org, linux-input@vger.kernel.org
Subject: Re: [PATCH 1/8] i2c: export i2c_client_type structure
Date: Wed, 15 Mar 2017 16:50:50 -0700	[thread overview]
Message-ID: <20170315235050.GB7126@dtor-ws> (raw)
In-Reply-To: <20170313145045.427cad3e@endymion>

Hi Jean,

On Mon, Mar 13, 2017 at 02:50:45PM +0100, Jean Delvare wrote:
> Hi Dmitry,
> 
> On Fri, 10 Mar 2017 00:12:46 +0100, Wolfram Sang wrote:
> > On Thu, Mar 09, 2017 at 02:16:37PM -0800, Dmitry Torokhov wrote:
> > > i2c bus has 2 different types of device belonging to the same bus and
> > > bus notifiers use device type to distinguish between adapters and clients.
> 
> Out of curiosity, is this something unusual, or other bus types do the
> same?

I think I2C is somewhat special because of compounding of multiple
factors:

1. It uses several device types (clients and adapters) on the same bus.
It is not unique in this way, many buses do that (w1 for example), but
others do not (spi).

2. We are starting using i2c bus notifiers more and more because x86
platform is shitty at describing i2c devices. Even if device is
described in ACPI, there is high chance that description is incomplete,
and if it is "complete", then it is quite likely wrong. Or they may not
be described in ACPI at all and require vendor drivers on Windows to
activate and operate (as with these SMBus companions to PS/2 devices).
Thankfully SPI is not as popular on X86, or we'd have the same mess
there.

So we create bunch of notifiers and try to "fix" stuff, but we need to
verify that we are dealing with the right device type. We already have
to_verified_client() and to_verified_adapter(), and i2c_adapter_type was
already exported, so in cases where I need to work with both adapters
and clients I wanted to export i2c_client_type as well. So if we ever
add a 3rd type we do not have to go back and adjust existing code. I
think it looks makes code easier to read if you test for equality to
client if you want clients.

> 
> > > Previously we only had i2c_adapter_type exported, which made code wanting
> > > to work with i2c_client devices test for type not equal to adapter type.
> > > This unfortunately is not safe if we ever add another type to the bus,
> > > so let's export i2c_client_type as well.
> > > 
> > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > > ---
> > > 
> > > Wolfram, this is the patch I was talking about in the other mail.
> > 
> > I see. From a glimpse, I am fine with the patch. I'll add Jean Delvare
> > to CC, though, in case I missed some detail he still knows. Furthermore,
> > while I agree that testing for "not adapter" when one means "is client"
> > is not nice, is there a bigger benefit than being correct in your queue?
> 
> No objection from me.
> 
> Reviewed-by: Jean Delvare <jdelvare@suse.de>

Thanks!

> 
> > > 
> > >  drivers/i2c/i2c-core.c | 4 ++--
> > >  include/linux/i2c.h    | 1 +
> > >  2 files changed, 3 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> > > index 34a5115484dd..446e341e9508 100644
> > > --- a/drivers/i2c/i2c-core.c
> > > +++ b/drivers/i2c/i2c-core.c
> > > @@ -74,7 +74,6 @@
> > >  static DEFINE_MUTEX(core_lock);
> > >  static DEFINE_IDR(i2c_adapter_idr);
> > >  
> > > -static struct device_type i2c_client_type;
> > >  static int i2c_detect(struct i2c_adapter *adapter, struct i2c_driver *driver);
> > >  
> > >  static struct static_key i2c_trace_msg = STATIC_KEY_INIT_FALSE;
> > > @@ -1096,11 +1095,12 @@ struct bus_type i2c_bus_type = {
> > >  };
> > >  EXPORT_SYMBOL_GPL(i2c_bus_type);
> > >  
> > > -static struct device_type i2c_client_type = {
> > > +struct device_type i2c_client_type = {
> > >  	.groups		= i2c_dev_groups,
> > >  	.uevent		= i2c_device_uevent,
> > >  	.release	= i2c_client_dev_release,
> > >  };
> > > +EXPORT_SYMBOL_GPL(i2c_client_type);
> > >  
> > >  
> > >  /**
> > > diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> > > index 2cc3988d127b..89ca5e56b433 100644
> > > --- a/include/linux/i2c.h
> > > +++ b/include/linux/i2c.h
> > > @@ -37,6 +37,7 @@
> > >  
> > >  extern struct bus_type i2c_bus_type;
> > >  extern struct device_type i2c_adapter_type;
> > > +extern struct device_type i2c_client_type;
> > >  
> > >  /* --- General options ------------------------------------------------	*/
> > >  
> > > -- 
> > > 2.12.0.246.ga2ecc84866-goog
> > > 
> 
> 
> -- 
> Jean Delvare
> SUSE L3 Support

-- 
Dmitry

  reply	other threads:[~2017-03-15 23:51 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-09 22:16 [PATCH 0/8] PS Dmitry Torokhov
2017-03-09 22:16 ` [PATCH 1/8] i2c: export i2c_client_type structure Dmitry Torokhov
2017-03-09 23:12   ` Wolfram Sang
2017-03-09 23:46     ` Dmitry Torokhov
2017-03-09 23:51       ` Dmitry Torokhov
2017-03-13 13:50     ` Jean Delvare
2017-03-15 23:50       ` Dmitry Torokhov [this message]
2017-04-01 16:06   ` Wolfram Sang
2017-04-01 16:43     ` Dmitry Torokhov
2017-03-09 22:16 ` [PATCH 2/8] Input: serio - add fast reconnect option Dmitry Torokhov
2017-03-09 22:16 ` [PATCH 3/8] Input: psmouse - implement " Dmitry Torokhov
2017-03-09 22:16 ` [PATCH 4/8] Input: psmouse - store pointer to current protocol Dmitry Torokhov
2017-03-09 22:16 ` [PATCH 5/8] Input: psmouse - introduce notion of SMBus companions Dmitry Torokhov
2017-03-09 22:16 ` [PATCH 6/8] Input: psmouse - add support for " Dmitry Torokhov
2017-03-11 15:13   ` kbuild test robot
2017-03-09 22:16 ` [PATCH 7/8] Input: synaptics - split device info into a separate structure Dmitry Torokhov
2017-03-09 22:16 ` [PATCH 8/8] Input: synaptics - add support for Intertouch devices Dmitry Torokhov
2017-03-09 23:53 ` [PATCH 6/8] Input: psmouse - add support for SMBus companions Dmitry Torokhov
2017-03-10 17:55   ` Benjamin Tissoires
2017-03-10 18:16     ` Dmitry Torokhov
2017-03-10 15:57 ` [PATCH 0/8] PS Benjamin Tissoires
2017-03-10 17:52   ` Dmitry Torokhov
2017-03-10 18:04     ` Benjamin Tissoires
2017-03-10 18:10       ` Dmitry Torokhov
2017-03-10 20:25         ` Dmitry Torokhov
2017-03-10 18:56     ` Andrew Duggan
2017-03-10 18:56       ` Andrew Duggan
2017-03-10 20:12       ` Dmitry Torokhov
2017-03-10 20:31         ` Andrew Duggan
2017-03-10 20:31           ` Andrew Duggan

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=20170315235050.GB7126@dtor-ws \
    --to=dmitry.torokhov@gmail.com \
    --cc=aduggan@synaptics.com \
    --cc=benjamin.tissoires@redhat.com \
    --cc=jdelvare@suse.de \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wsa@the-dreams.de \
    /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.