From: Grant Likely <grant.likely@secretlab.ca> To: Russell King - ARM Linux <linux@arm.linux.org.uk> Cc: Kevin Hilman <khilman@ti.com>, linux-omap@vger.kernel.org, Paul Walmsley <paul@pwsan.com>, "G. Manjunath Kondaiah" <manjugk@ti.com>, devicetree-discuss@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org Subject: Re: [RFC/PATCH 7/7] WIP: HACK/RFC: omap_device: begin to decouple platform_device from omap_device Date: Sat, 30 Jul 2011 20:58:07 -0600 [thread overview] Message-ID: <20110731025807.GA24334@ponder.secretlab.ca> (raw) In-Reply-To: <20110730120332.GA15539@n2100.arm.linux.org.uk> On Sat, Jul 30, 2011 at 01:03:32PM +0100, Russell King - ARM Linux wrote: > On Thu, Jul 21, 2011 at 04:52:18PM -0700, Kevin Hilman wrote: > > Rather than embedding a struct platform_device inside a struct > > omap_device, decouple them, leaving only a pointer to the > > platform_device inside the omap_device. > > > > This patch uses devres to allocate and attach the omap_device to the > > struct device, so finding an omap_device from a struct device means > > using devres_find(), and the to_omap_device() helper function was > > modified accordingly. > > > > RFC/Hack alert: > > > > Currently the driver core (drivers/base/dd.c) doesn't expect any > > devres resources to exist before the driver's ->probe() is called. In > > this patch, I just comment out the warning, but we'll need to > > understand why that limitation exists, and if it's a real limitation. > > A first glance suggests that it's not really needed. If this is a > > true limitation, we'll need to find some way other than devres to > > attach an omap_device to a struct device. > > > > On OMAP, we will need an omap_device attached to a struct device > > before probe because device HW may be disabled in probe and drivers > > are expected to use runtime PM in ->probe() to activate the hardware > > before access. Because the runtime PM API calls use omap_device (via > > our PM domain layer), we need omap_device attached to a > > platform_device before probe. > > This feels really wrong to overload devres with this. devres purpose is > to provide the device's _drivers_ with a way to allocate and free resources > in such a way to avoid leaks on .remove or probe failure. So I think that > overloading it with something that has a different lifetime is completely > wrong. I disagree; extending devres to also handle device lifetime scoped resources makes perfect sense. It is a clean extension, and struct device is really getting rather huge. I certainly prefer re-scoping devres to adding more elements to struct device. > We could add a new member to struct dev_archdata or pdev_archdata to carry > a pointer to this data, which I think would be a far cleaner (and saner) > way to deal with this. In much the same way as we already have an of_node > member in struct device. Since this is just for omap_device, which by definition is arm-only, I don't have any strong objection to using pdev_archdata. If it was cross-architecture, then I'd argue strongly for the devres approach. g.
WARNING: multiple messages have this Message-ID (diff)
From: grant.likely@secretlab.ca (Grant Likely) To: linux-arm-kernel@lists.infradead.org Subject: [RFC/PATCH 7/7] WIP: HACK/RFC: omap_device: begin to decouple platform_device from omap_device Date: Sat, 30 Jul 2011 20:58:07 -0600 [thread overview] Message-ID: <20110731025807.GA24334@ponder.secretlab.ca> (raw) In-Reply-To: <20110730120332.GA15539@n2100.arm.linux.org.uk> On Sat, Jul 30, 2011 at 01:03:32PM +0100, Russell King - ARM Linux wrote: > On Thu, Jul 21, 2011 at 04:52:18PM -0700, Kevin Hilman wrote: > > Rather than embedding a struct platform_device inside a struct > > omap_device, decouple them, leaving only a pointer to the > > platform_device inside the omap_device. > > > > This patch uses devres to allocate and attach the omap_device to the > > struct device, so finding an omap_device from a struct device means > > using devres_find(), and the to_omap_device() helper function was > > modified accordingly. > > > > RFC/Hack alert: > > > > Currently the driver core (drivers/base/dd.c) doesn't expect any > > devres resources to exist before the driver's ->probe() is called. In > > this patch, I just comment out the warning, but we'll need to > > understand why that limitation exists, and if it's a real limitation. > > A first glance suggests that it's not really needed. If this is a > > true limitation, we'll need to find some way other than devres to > > attach an omap_device to a struct device. > > > > On OMAP, we will need an omap_device attached to a struct device > > before probe because device HW may be disabled in probe and drivers > > are expected to use runtime PM in ->probe() to activate the hardware > > before access. Because the runtime PM API calls use omap_device (via > > our PM domain layer), we need omap_device attached to a > > platform_device before probe. > > This feels really wrong to overload devres with this. devres purpose is > to provide the device's _drivers_ with a way to allocate and free resources > in such a way to avoid leaks on .remove or probe failure. So I think that > overloading it with something that has a different lifetime is completely > wrong. I disagree; extending devres to also handle device lifetime scoped resources makes perfect sense. It is a clean extension, and struct device is really getting rather huge. I certainly prefer re-scoping devres to adding more elements to struct device. > We could add a new member to struct dev_archdata or pdev_archdata to carry > a pointer to this data, which I think would be a far cleaner (and saner) > way to deal with this. In much the same way as we already have an of_node > member in struct device. Since this is just for omap_device, which by definition is arm-only, I don't have any strong objection to using pdev_archdata. If it was cross-architecture, then I'd argue strongly for the devres approach. g.
next prev parent reply other threads:[~2011-07-31 2:58 UTC|newest] Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-07-21 23:52 [RFC/PATCH 0/7] decouple platform_device from omap_device Kevin Hilman 2011-07-21 23:52 ` Kevin Hilman 2011-07-21 23:52 ` [PATCH] OMAP: omap_device: replace _find_by_pdev() with to_omap_device() Kevin Hilman 2011-07-21 23:52 ` Kevin Hilman 2011-07-22 8:53 ` Felipe Balbi 2011-07-22 8:53 ` Felipe Balbi 2011-07-21 23:52 ` [RFC/PATCH 1/7] OMAP: omap_device: replace debug/warning/error prints with dev_* macros Kevin Hilman 2011-07-21 23:52 ` Kevin Hilman 2011-07-21 23:52 ` [RFC/PATCH 2/7] OMAP3: beagle: don't touch omap_device internals Kevin Hilman 2011-07-21 23:52 ` Kevin Hilman 2011-07-22 8:57 ` Felipe Balbi 2011-07-22 8:57 ` Felipe Balbi 2011-07-28 5:53 ` Nishanth Menon 2011-07-28 5:53 ` Nishanth Menon 2011-07-28 10:10 ` Russell King - ARM Linux 2011-07-28 10:10 ` Russell King - ARM Linux 2011-07-28 12:57 ` Cousson, Benoit 2011-07-28 12:57 ` Cousson, Benoit 2011-07-28 12:59 ` Felipe Balbi 2011-07-28 12:59 ` Felipe Balbi 2011-07-28 13:31 ` Menon, Nishanth 2011-07-28 13:31 ` Menon, Nishanth 2011-07-29 13:49 ` Nishanth Menon 2011-07-29 13:49 ` Nishanth Menon 2011-07-29 14:05 ` Felipe Balbi 2011-07-29 14:05 ` Felipe Balbi 2011-07-29 23:07 ` Menon, Nishanth 2011-07-29 23:07 ` Menon, Nishanth 2011-08-01 8:52 ` Felipe Balbi 2011-08-01 8:52 ` Felipe Balbi 2011-07-28 8:36 ` Jean Pihet 2011-07-28 8:36 ` Jean Pihet 2011-07-28 8:40 ` Jean Pihet 2011-07-28 8:40 ` Jean Pihet 2011-07-21 23:52 ` [RFC/PATCH 3/7] OMAP: McBSP: use existing macros for converting between devices Kevin Hilman 2011-07-21 23:52 ` Kevin Hilman 2011-07-22 8:58 ` Felipe Balbi 2011-07-22 8:58 ` Felipe Balbi 2011-07-22 12:32 ` Sergei Shtylyov 2011-07-22 12:32 ` Sergei Shtylyov 2011-07-22 20:19 ` Kevin Hilman 2011-07-22 20:19 ` Kevin Hilman 2011-07-21 23:52 ` [RFC/PATCH 4/7] OMAP: omap_device: remove internal functions from omap_device.h Kevin Hilman 2011-07-21 23:52 ` Kevin Hilman 2011-07-21 23:52 ` [RFC/PATCH 5/7] OMAP: omap_device: when building return platform_device instead of omap_device Kevin Hilman 2011-07-21 23:52 ` Kevin Hilman 2011-07-21 23:52 ` [RFC/PATCH 6/7] OMAP: omap_device: device register functions now take platform_device pointer Kevin Hilman 2011-07-21 23:52 ` Kevin Hilman 2011-07-22 6:16 ` Grant Likely 2011-07-22 6:16 ` Grant Likely 2011-07-21 23:52 ` [RFC/PATCH 7/7] WIP: HACK/RFC: omap_device: begin to decouple platform_device from omap_device Kevin Hilman 2011-07-21 23:52 ` Kevin Hilman 2011-07-22 2:20 ` Grant Likely 2011-07-22 2:20 ` Grant Likely 2011-07-30 12:03 ` Russell King - ARM Linux 2011-07-30 12:03 ` Russell King - ARM Linux 2011-07-31 2:58 ` Grant Likely [this message] 2011-07-31 2:58 ` Grant Likely 2011-07-31 15:05 ` Russell King - ARM Linux 2011-07-31 15:05 ` Russell King - ARM Linux 2011-08-01 15:42 ` Kevin Hilman 2011-08-01 15:42 ` Kevin Hilman 2011-08-01 15:44 ` Grant Likely 2011-08-01 15:44 ` Grant Likely 2011-08-01 18:50 ` Felipe Balbi 2011-08-01 18:50 ` Felipe Balbi 2011-08-01 20:07 ` Russell King - ARM Linux 2011-08-01 20:07 ` Russell King - ARM Linux 2011-08-01 22:11 ` Kevin Hilman 2011-08-01 22:11 ` Kevin Hilman 2011-08-01 22:55 ` Felipe Balbi 2011-08-01 22:55 ` Felipe Balbi 2011-08-01 23:09 ` Russell King - ARM Linux 2011-08-01 23:09 ` Russell King - ARM Linux 2011-08-02 0:00 ` Grant Likely 2011-08-02 0:00 ` Grant Likely 2011-07-27 14:04 ` [RFC/PATCH 0/7] " G, Manjunath Kondaiah 2011-07-27 14:04 ` G, Manjunath Kondaiah 2011-07-27 21:45 ` Hilman, Kevin 2011-07-27 21:45 ` Hilman, Kevin 2011-07-28 4:50 ` G, Manjunath Kondaiah 2011-07-28 4:50 ` G, Manjunath Kondaiah 2011-07-29 23:59 ` Kevin Hilman 2011-07-29 23:59 ` Kevin Hilman
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=20110731025807.GA24334@ponder.secretlab.ca \ --to=grant.likely@secretlab.ca \ --cc=devicetree-discuss@lists.ozlabs.org \ --cc=khilman@ti.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-omap@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=manjugk@ti.com \ --cc=paul@pwsan.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: linkBe 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.