All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 6/7] ARM: mackerel: support booting with or without DT
Date: Mon, 17 Dec 2012 16:50:13 +0000	[thread overview]
Message-ID: <Pine.LNX.4.64.1212171743380.24007@axis700.grange> (raw)
In-Reply-To: <20121217163852.C57FD3E0BDD@localhost>

Hi Grant

On Mon, 17 Dec 2012, Grant Likely wrote:

> On Sun, 16 Dec 2012 22:36:56 +0100 (CET), Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote:
> > Hi Grant
> > 
> > On Sun, 16 Dec 2012, Grant Likely wrote:
> > 
> > > On Fri, 14 Dec 2012 17:45:30 +0100, Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote:
> > > > This patch adds dynamic switching to booting either with or without DT.
> > > > So far only a part of the board initialisation can be done via DT. Devices,
> > > > that still need platform data are kept that way. Devices, that can be
> > > > initialised from DT will not be supplied from the platform data, if a DT
> > > > image is detected.
> > > > 
> > > > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> > > > ---
> > > >  
> > > > +static int mackerel_i2c_bus_notify(struct notifier_block *nb,
> > > > +				   unsigned long action, void *data)
> > > > +{
> > > > +	struct device *dev = data;
> > > > +
> > > > +	if (action != BUS_NOTIFY_ADD_DEVICE ||
> > > > +	    strcmp(dev_name(dev->parent), "fff20000.i2c"))
> > > > +		return NOTIFY_DONE;
> > > > +
> > > > +	i2c_new_device(to_i2c_adapter(dev), &i2c0_devices[1]);
> > > > +
> > > > +	return NOTIFY_OK;
> > > > +}
> > > > +
> > > > +static struct notifier_block mackerel_i2c_notifier = {
> > > > +	.notifier_call = mackerel_i2c_bus_notify,
> > > > +};
> > > 
> > > This looks dodgy. It appears that the purpose of this hook is to create
> > > the tca6408-keys device because it has some platform data. However,
> > > this hook will try to create the device every time BUS_NOTIFY_ADD_DEVICE
> > > happens on the fff20000.i2c bus *including* when the tca6408-keys device
> > > gets added.
> > 
> > I think, this is only called once, when the i2c adapter device is added in 
> > i2c_register_adapter(). I2C client devices have these adapter devices as 
> > their parents, and those devices have "i2c-%d" as their names. Since all 
> > client devices get destroyed when the adapter is unbound, the above should 
> > be safe.
> 
> Take another look. The way the bus notifiers work is they get called 
> once for every device registered with the given bus type. That means 
> i2c_client objects, not i3c

I did, and I also tested. Both I2C clients and I2C adapters are placed on 
the i2c_bus_type. So, yes, you're right, the above notifier will be called 
upon registration of each adapter and client. But, the string comparison 
in the "if" above will only match for the I2C adapter, so, no recursion.

Thanks
Guennadi

> > > The correct approach when you need to add specific platform data is to
> > > still put the device into the device tree and make the notifier look for
> > > that specific device. Then the platform data pointer can be attached at
> > > BUS_NOTIFY_ADD_DEVICE time.
> > > 
> > > However, it doesn't look like you need a notifier at all. From what I
> > > can see the tca6408-keys device does have platform data, but it is all
> > > simple (no callback pointers). You should instead encode the platform
> > > data into device tree properties and extract them from the driver.
> > 
> > Yes, this is the ultimate goal. But the purpose of this patch series is to 
> > move whatever devices are possible right _now_ to DT. Ultimately all of 
> > them should be migrated. So, yes, we could try to begin with tca6408, 
> > because the above hack is certainly the ugliest one in this series, but in 
> > principle this is just one of several devices, that we have to keep in 
> > platform data for now and aim at removing these temporary hacks as soon as 
> > respective drivers implement sufficient DT support.
> > 
> > Thanks
> > Guennadi
> > ---
> > Guennadi Liakhovetski, Ph.D.
> > Freelance Open-Source Software Developer
> > http://www.open-technology.de/
> 
> -- 
> Grant Likely, B.Sc, P.Eng.
> Secret Lab Technologies, Ltd.
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

WARNING: multiple messages have this Message-ID (diff)
From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: linux-sh@vger.kernel.org, devicetree-discuss@lists.ozlabs.org,
	Simon Horman <horms@verge.net.au>,
	Magnus Damm <magnus.damm@gmail.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 6/7] ARM: mackerel: support booting with or without DT
Date: Mon, 17 Dec 2012 17:50:13 +0100 (CET)	[thread overview]
Message-ID: <Pine.LNX.4.64.1212171743380.24007@axis700.grange> (raw)
In-Reply-To: <20121217163852.C57FD3E0BDD@localhost>

Hi Grant

On Mon, 17 Dec 2012, Grant Likely wrote:

> On Sun, 16 Dec 2012 22:36:56 +0100 (CET), Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote:
> > Hi Grant
> > 
> > On Sun, 16 Dec 2012, Grant Likely wrote:
> > 
> > > On Fri, 14 Dec 2012 17:45:30 +0100, Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote:
> > > > This patch adds dynamic switching to booting either with or without DT.
> > > > So far only a part of the board initialisation can be done via DT. Devices,
> > > > that still need platform data are kept that way. Devices, that can be
> > > > initialised from DT will not be supplied from the platform data, if a DT
> > > > image is detected.
> > > > 
> > > > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> > > > ---
> > > >  
> > > > +static int mackerel_i2c_bus_notify(struct notifier_block *nb,
> > > > +				   unsigned long action, void *data)
> > > > +{
> > > > +	struct device *dev = data;
> > > > +
> > > > +	if (action != BUS_NOTIFY_ADD_DEVICE ||
> > > > +	    strcmp(dev_name(dev->parent), "fff20000.i2c"))
> > > > +		return NOTIFY_DONE;
> > > > +
> > > > +	i2c_new_device(to_i2c_adapter(dev), &i2c0_devices[1]);
> > > > +
> > > > +	return NOTIFY_OK;
> > > > +}
> > > > +
> > > > +static struct notifier_block mackerel_i2c_notifier = {
> > > > +	.notifier_call = mackerel_i2c_bus_notify,
> > > > +};
> > > 
> > > This looks dodgy. It appears that the purpose of this hook is to create
> > > the tca6408-keys device because it has some platform data. However,
> > > this hook will try to create the device every time BUS_NOTIFY_ADD_DEVICE
> > > happens on the fff20000.i2c bus *including* when the tca6408-keys device
> > > gets added.
> > 
> > I think, this is only called once, when the i2c adapter device is added in 
> > i2c_register_adapter(). I2C client devices have these adapter devices as 
> > their parents, and those devices have "i2c-%d" as their names. Since all 
> > client devices get destroyed when the adapter is unbound, the above should 
> > be safe.
> 
> Take another look. The way the bus notifiers work is they get called 
> once for every device registered with the given bus type. That means 
> i2c_client objects, not i3c

I did, and I also tested. Both I2C clients and I2C adapters are placed on 
the i2c_bus_type. So, yes, you're right, the above notifier will be called 
upon registration of each adapter and client. But, the string comparison 
in the "if" above will only match for the I2C adapter, so, no recursion.

Thanks
Guennadi

> > > The correct approach when you need to add specific platform data is to
> > > still put the device into the device tree and make the notifier look for
> > > that specific device. Then the platform data pointer can be attached at
> > > BUS_NOTIFY_ADD_DEVICE time.
> > > 
> > > However, it doesn't look like you need a notifier at all. From what I
> > > can see the tca6408-keys device does have platform data, but it is all
> > > simple (no callback pointers). You should instead encode the platform
> > > data into device tree properties and extract them from the driver.
> > 
> > Yes, this is the ultimate goal. But the purpose of this patch series is to 
> > move whatever devices are possible right _now_ to DT. Ultimately all of 
> > them should be migrated. So, yes, we could try to begin with tca6408, 
> > because the above hack is certainly the ugliest one in this series, but in 
> > principle this is just one of several devices, that we have to keep in 
> > platform data for now and aim at removing these temporary hacks as soon as 
> > respective drivers implement sufficient DT support.
> > 
> > Thanks
> > Guennadi
> > ---
> > Guennadi Liakhovetski, Ph.D.
> > Freelance Open-Source Software Developer
> > http://www.open-technology.de/
> 
> -- 
> Grant Likely, B.Sc, P.Eng.
> Secret Lab Technologies, Ltd.
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

WARNING: multiple messages have this Message-ID (diff)
From: g.liakhovetski@gmx.de (Guennadi Liakhovetski)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 6/7] ARM: mackerel: support booting with or without DT
Date: Mon, 17 Dec 2012 17:50:13 +0100 (CET)	[thread overview]
Message-ID: <Pine.LNX.4.64.1212171743380.24007@axis700.grange> (raw)
In-Reply-To: <20121217163852.C57FD3E0BDD@localhost>

Hi Grant

On Mon, 17 Dec 2012, Grant Likely wrote:

> On Sun, 16 Dec 2012 22:36:56 +0100 (CET), Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote:
> > Hi Grant
> > 
> > On Sun, 16 Dec 2012, Grant Likely wrote:
> > 
> > > On Fri, 14 Dec 2012 17:45:30 +0100, Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote:
> > > > This patch adds dynamic switching to booting either with or without DT.
> > > > So far only a part of the board initialisation can be done via DT. Devices,
> > > > that still need platform data are kept that way. Devices, that can be
> > > > initialised from DT will not be supplied from the platform data, if a DT
> > > > image is detected.
> > > > 
> > > > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> > > > ---
> > > >  
> > > > +static int mackerel_i2c_bus_notify(struct notifier_block *nb,
> > > > +				   unsigned long action, void *data)
> > > > +{
> > > > +	struct device *dev = data;
> > > > +
> > > > +	if (action != BUS_NOTIFY_ADD_DEVICE ||
> > > > +	    strcmp(dev_name(dev->parent), "fff20000.i2c"))
> > > > +		return NOTIFY_DONE;
> > > > +
> > > > +	i2c_new_device(to_i2c_adapter(dev), &i2c0_devices[1]);
> > > > +
> > > > +	return NOTIFY_OK;
> > > > +}
> > > > +
> > > > +static struct notifier_block mackerel_i2c_notifier = {
> > > > +	.notifier_call = mackerel_i2c_bus_notify,
> > > > +};
> > > 
> > > This looks dodgy. It appears that the purpose of this hook is to create
> > > the tca6408-keys device because it has some platform data. However,
> > > this hook will try to create the device every time BUS_NOTIFY_ADD_DEVICE
> > > happens on the fff20000.i2c bus *including* when the tca6408-keys device
> > > gets added.
> > 
> > I think, this is only called once, when the i2c adapter device is added in 
> > i2c_register_adapter(). I2C client devices have these adapter devices as 
> > their parents, and those devices have "i2c-%d" as their names. Since all 
> > client devices get destroyed when the adapter is unbound, the above should 
> > be safe.
> 
> Take another look. The way the bus notifiers work is they get called 
> once for every device registered with the given bus type. That means 
> i2c_client objects, not i3c

I did, and I also tested. Both I2C clients and I2C adapters are placed on 
the i2c_bus_type. So, yes, you're right, the above notifier will be called 
upon registration of each adapter and client. But, the string comparison 
in the "if" above will only match for the I2C adapter, so, no recursion.

Thanks
Guennadi

> > > The correct approach when you need to add specific platform data is to
> > > still put the device into the device tree and make the notifier look for
> > > that specific device. Then the platform data pointer can be attached at
> > > BUS_NOTIFY_ADD_DEVICE time.
> > > 
> > > However, it doesn't look like you need a notifier at all. From what I
> > > can see the tca6408-keys device does have platform data, but it is all
> > > simple (no callback pointers). You should instead encode the platform
> > > data into device tree properties and extract them from the driver.
> > 
> > Yes, this is the ultimate goal. But the purpose of this patch series is to 
> > move whatever devices are possible right _now_ to DT. Ultimately all of 
> > them should be migrated. So, yes, we could try to begin with tca6408, 
> > because the above hack is certainly the ugliest one in this series, but in 
> > principle this is just one of several devices, that we have to keep in 
> > platform data for now and aim at removing these temporary hacks as soon as 
> > respective drivers implement sufficient DT support.
> > 
> > Thanks
> > Guennadi
> > ---
> > Guennadi Liakhovetski, Ph.D.
> > Freelance Open-Source Software Developer
> > http://www.open-technology.de/
> 
> -- 
> Grant Likely, B.Sc, P.Eng.
> Secret Lab Technologies, Ltd.
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

  reply	other threads:[~2012-12-17 16:50 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-14 16:45 [PATCH 0/7] ARM: mackerel: extended DT support Guennadi Liakhovetski
2012-12-14 16:45 ` Guennadi Liakhovetski
2012-12-14 16:45 ` Guennadi Liakhovetski
2012-12-14 16:45 ` [PATCH 1/7] ARM: sh7372: add missing "#interrupt-cells" properties Guennadi Liakhovetski
2012-12-14 16:45   ` Guennadi Liakhovetski
2012-12-14 16:45   ` Guennadi Liakhovetski
2012-12-15  9:05   ` Simon Horman
2012-12-15  9:05     ` Simon Horman
2012-12-15  9:05     ` Simon Horman
2012-12-14 16:45 ` [PATCH 2/7] ARM: mackerel: include the correct .dtsi file Guennadi Liakhovetski
2012-12-14 16:45   ` Guennadi Liakhovetski
2012-12-14 16:45   ` Guennadi Liakhovetski
2012-12-15  8:37   ` Simon Horman
2012-12-15  8:37     ` Simon Horman
2012-12-15  8:37     ` Simon Horman
2012-12-14 16:45 ` [PATCH 3/7] ARM: sh7372: support mixed DT and board code interrupt controller init Guennadi Liakhovetski
2012-12-14 16:45   ` Guennadi Liakhovetski
2012-12-14 16:45   ` Guennadi Liakhovetski
2012-12-15  7:52   ` Simon Horman
2012-12-15  7:52     ` Simon Horman
2012-12-15  7:52     ` Simon Horman
2012-12-17  8:02     ` Guennadi Liakhovetski
2012-12-17  8:02       ` Guennadi Liakhovetski
2012-12-17  8:02       ` Guennadi Liakhovetski
2012-12-14 16:45 ` [PATCH 4/7] ARM: sh7372: add clock lookup entries for DT-based devices Guennadi Liakhovetski
2012-12-14 16:45   ` Guennadi Liakhovetski
2012-12-14 16:45   ` Guennadi Liakhovetski
2012-12-15  7:29   ` Grant Likely
2012-12-15  7:29     ` Grant Likely
2012-12-15  7:29     ` Grant Likely
2012-12-15  8:36   ` Simon Horman
2012-12-15  8:36     ` Simon Horman
2012-12-15  8:36     ` Simon Horman
2012-12-14 16:45 ` [PATCH 5/7] ARM: sh7372: allow boards supporting booting with or without DT Guennadi Liakhovetski
2012-12-14 16:45   ` Guennadi Liakhovetski
2012-12-14 16:45   ` Guennadi Liakhovetski
2012-12-15  8:05   ` Simon Horman
2012-12-15  8:05     ` Simon Horman
2012-12-15  8:05     ` Simon Horman
2012-12-17  8:07     ` Guennadi Liakhovetski
2012-12-17  8:07       ` Guennadi Liakhovetski
2012-12-17  8:07       ` Guennadi Liakhovetski
2012-12-14 16:45 ` [PATCH 6/7] ARM: mackerel: support " Guennadi Liakhovetski
2012-12-14 16:45   ` Guennadi Liakhovetski
2012-12-14 16:45   ` Guennadi Liakhovetski
2012-12-15  8:29   ` Simon Horman
2012-12-15  8:29     ` Simon Horman
2012-12-15  8:29     ` Simon Horman
2012-12-15 19:02     ` Guennadi Liakhovetski
2012-12-15 19:02       ` Guennadi Liakhovetski
2012-12-15 19:02       ` Guennadi Liakhovetski
2012-12-16  0:33       ` Simon Horman
2012-12-16  0:33         ` Simon Horman
2012-12-16  0:33         ` Simon Horman
2012-12-16 20:46   ` Grant Likely
2012-12-16 20:46     ` Grant Likely
2012-12-16 20:46     ` Grant Likely
2012-12-16 21:36     ` Guennadi Liakhovetski
2012-12-16 21:36       ` Guennadi Liakhovetski
2012-12-16 21:36       ` Guennadi Liakhovetski
2012-12-17 16:38       ` Grant Likely
2012-12-17 16:38         ` Grant Likely
2012-12-17 16:38         ` Grant Likely
2012-12-17 16:50         ` Guennadi Liakhovetski [this message]
2012-12-17 16:50           ` Guennadi Liakhovetski
2012-12-17 16:50           ` Guennadi Liakhovetski
2012-12-17 16:54       ` Grant Likely
2012-12-17 16:54         ` Grant Likely
2012-12-17 16:54         ` Grant Likely
2012-12-17 12:40   ` [PATCH v2 " Guennadi Liakhovetski
2012-12-17 12:40     ` Guennadi Liakhovetski
2012-12-17 12:40     ` Guennadi Liakhovetski
2012-12-17 17:00     ` Grant Likely
2012-12-17 17:00       ` Grant Likely
2012-12-17 17:00       ` Grant Likely
2012-12-14 16:45 ` [PATCH 7/7] ARM: mackerel: add more devices to DT Guennadi Liakhovetski
2012-12-14 16:45   ` Guennadi Liakhovetski
2012-12-14 16:45   ` Guennadi Liakhovetski

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=Pine.LNX.4.64.1212171743380.24007@axis700.grange \
    --to=g.liakhovetski@gmx.de \
    --cc=linux-arm-kernel@lists.infradead.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 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.