From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1755425AbbHDKIo (ORCPT <rfc822;w@1wt.eu>);
	Tue, 4 Aug 2015 06:08:44 -0400
Received: from lb1-smtp-cloud3.xs4all.net ([194.109.24.22]:45362 "EHLO
	lb1-smtp-cloud3.xs4all.net" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1753529AbbHDKIn (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 4 Aug 2015 06:08:43 -0400
Message-ID: <1438682920.8734.61.camel@tiscali.nl>
Subject: Re: [PATCH 15/27] regulator: fan53555: Export I2C module alias
 information
From: Paul Bolle <pebolle@tiscali.nl>
To: Javier Martinez Canillas <javier@osg.samsung.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>, Mark Brown <broonie@kernel.org>,
        linux-kernel@vger.kernel.org
Date: Tue, 04 Aug 2015 12:08:40 +0200
In-Reply-To: <55BF7ADF.3070801@osg.samsung.com>
References: <1438273132-20926-1-git-send-email-javier@osg.samsung.com>
	 <1438273132-20926-16-git-send-email-javier@osg.samsung.com>
	 <1438602218.3726.45.camel@tiscali.nl> <55BF7ADF.3070801@osg.samsung.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.16.4 (3.16.4-2.fc22) 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Javier,

On ma, 2015-08-03 at 16:29 +0200, Javier Martinez Canillas wrote:
> On 08/03/2015 01:43 PM, Paul Bolle wrote:
> > On do, 2015-07-30 at 18:18 +0200, Javier Martinez Canillas wrote:

> I2C is a little special in that it uses the id_table again to match
> in i2c_device_probe() and pass a i2c_device_id to the I2C driver's probe
> function. That is what I meant by matching but maybe I could had been more
> precise.

(So is what I2C currently does comparable to what, say, USB does (ie,
using usb_device_id for the match and also passing it to the driver's
probe function) or is it more complicated?)

> > But I'm guessing that parsing a device tree blob that contains
> > strings like
> >     compatible = "silergy,syr828"
> > 
> > would add strings like
> >     MODALIAS=of:N[...]T[...]Csilergy,syr828
>
> That would be the correct behavior and is what the RFC patch #27 does.
>  
> > to the related uevents. (Likewise for the two other aliases.) Doesn't
> > that happen here?
>
> No, that is exactly the problem.

Which also explains how these
   MODULE_DEVICE_TABLE(of, ...);

lines, which have no effect for the drivers at hand, added to my confusion.

> Take a look to i2c_device_uevent() [0],
> it just does:
> 
> add_uevent_var(env, "MODALIAS=%s%s", I2C_MODULE_PREFIX, client->name))
> 
> So if you have a i2c_device_id table but no 
> MODULE_DEVICE_TABLE(i2c,...),
> then module autoload won't work.

Thanks for taking the time to explain all this to me.


Paul Bolle