From: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Cc: Andrew Lunn <andrew@lunn.ch>, Thomas Petazzoni <thomas.petazzoni@free-electrons.com>, Jason Cooper <jason@lakedaemon.net>, Nobuhiro Iwamatsu <iwamatsu@nigauri.org>, linux-pm@vger.kernel.org, Lior Amsalem <alior@marvell.com>, Gregory Clement <gregory.clement@free-electrons.com>, Zhang Rui <rui.zhang@intel.com>, Florian Fainelli <florian@openwrt.org>, linux-arm-kernel@lists.infradead.org, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Subject: Re: [PATCH 00/16] Marvell EBU thermal sensor consolidation Date: Fri, 22 Mar 2013 11:23:31 -0300 [thread overview] Message-ID: <20130322142330.GA31661@localhost> (raw) In-Reply-To: <20130321173251.GA3070@obsidianresearch.com> On Thu, Mar 21, 2013 at 11:32:51AM -0600, Jason Gunthorpe wrote: > On Thu, Mar 21, 2013 at 07:45:01AM +0100, Andrew Lunn wrote: > > > In the end, i decided it was simpler and cleaner to just have separate > > drivers. This is something which we should think about and discuss. > > When I looked through the merge'd driver I thought the shared code > really had little to do with Marvell, it was mostly boilerplate that > would be common to any memory mapped temperature sensor - so maybe the > drivers should be kept apart and the boiler plate could be factored? > > thermal_platform_mmio_init(pdev,&ops); > > Where ops has the is_valid, init_sensor, get_sensor functions > > Or something? > Mmm... I'm not entirely sure. It might make sense if we could have thermal drivers for mor SoC than just Marvell's. Is it judicious to have a thermal-mmio based on Marvell-only devices? > ... > > BTW, Ezequiel your driver is probably a bit smaller if you do > > struct mvebu_ops { > /* Initialize the sensor (optional) */ > void (*init_sensor)(struct mvebu_thermal_priv *); > > /* Test for a valid sensor value (optional) */ > bool (*is_valid)(struct mvebu_thermal_priv *); > }; > > static const struct mvebu_ops kirkwood_ops = {..}; > > static const struct of_device_id mvebu_thermal_id_table[] = { > { > .compatible = "marvell,kirkwood-thermal", > .data = &kirkwood_ops, > }, > > And drop the switch statement and the MVEBU_THERMAL_SOC_* constants.. > Yes, this sounds like a very good idea. I'll try it and see what happens. Thanks, -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com
WARNING: multiple messages have this Message-ID (diff)
From: ezequiel.garcia@free-electrons.com (Ezequiel Garcia) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 00/16] Marvell EBU thermal sensor consolidation Date: Fri, 22 Mar 2013 11:23:31 -0300 [thread overview] Message-ID: <20130322142330.GA31661@localhost> (raw) In-Reply-To: <20130321173251.GA3070@obsidianresearch.com> On Thu, Mar 21, 2013 at 11:32:51AM -0600, Jason Gunthorpe wrote: > On Thu, Mar 21, 2013 at 07:45:01AM +0100, Andrew Lunn wrote: > > > In the end, i decided it was simpler and cleaner to just have separate > > drivers. This is something which we should think about and discuss. > > When I looked through the merge'd driver I thought the shared code > really had little to do with Marvell, it was mostly boilerplate that > would be common to any memory mapped temperature sensor - so maybe the > drivers should be kept apart and the boiler plate could be factored? > > thermal_platform_mmio_init(pdev,&ops); > > Where ops has the is_valid, init_sensor, get_sensor functions > > Or something? > Mmm... I'm not entirely sure. It might make sense if we could have thermal drivers for mor SoC than just Marvell's. Is it judicious to have a thermal-mmio based on Marvell-only devices? > ... > > BTW, Ezequiel your driver is probably a bit smaller if you do > > struct mvebu_ops { > /* Initialize the sensor (optional) */ > void (*init_sensor)(struct mvebu_thermal_priv *); > > /* Test for a valid sensor value (optional) */ > bool (*is_valid)(struct mvebu_thermal_priv *); > }; > > static const struct mvebu_ops kirkwood_ops = {..}; > > static const struct of_device_id mvebu_thermal_id_table[] = { > { > .compatible = "marvell,kirkwood-thermal", > .data = &kirkwood_ops, > }, > > And drop the switch statement and the MVEBU_THERMAL_SOC_* constants.. > Yes, this sounds like a very good idea. I'll try it and see what happens. Thanks, -- Ezequiel Garc?a, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com
next prev parent reply other threads:[~2013-03-22 14:23 UTC|newest] Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-03-20 22:36 [PATCH 00/16] Marvell EBU thermal sensor consolidation Ezequiel Garcia 2013-03-20 22:36 ` Ezequiel Garcia 2013-03-20 22:36 ` [PATCH 01/16] thermal: Rename driver 'kirkwood' -> 'mvebu' Ezequiel Garcia 2013-03-20 22:36 ` Ezequiel Garcia 2013-03-20 22:36 ` [PATCH 02/16] thermal: mvebu: Rename symbols " Ezequiel Garcia 2013-03-20 22:36 ` Ezequiel Garcia 2013-03-20 22:36 ` [PATCH 03/16] thermal: mvebu: Move MODULE_DEVICE_TABLE upwards Ezequiel Garcia 2013-03-20 22:36 ` Ezequiel Garcia 2013-03-20 22:36 ` [PATCH 04/16] thermal: mvebu: Remove unneeded variable initialization Ezequiel Garcia 2013-03-20 22:36 ` Ezequiel Garcia 2013-03-20 22:36 ` [PATCH 05/16] thermal: mvebu: Fix valid check for thermal register Ezequiel Garcia 2013-03-20 22:36 ` Ezequiel Garcia 2013-03-21 14:35 ` Jason Cooper 2013-03-21 14:35 ` Jason Cooper 2013-03-21 15:16 ` Ezequiel Garcia 2013-03-21 15:16 ` Ezequiel Garcia 2013-03-21 15:24 ` Jason Cooper 2013-03-21 15:24 ` Jason Cooper 2013-03-21 19:57 ` Ezequiel Garcia 2013-03-21 19:57 ` Ezequiel Garcia 2013-03-21 20:06 ` Jason Cooper 2013-03-21 20:06 ` Jason Cooper 2013-03-20 22:36 ` [PATCH 06/16] thermal: mvebu: Convert to devm_ioremap_resource() Ezequiel Garcia 2013-03-20 22:36 ` Ezequiel Garcia 2013-03-21 6:10 ` Andrew Lunn 2013-03-21 6:10 ` Andrew Lunn 2013-03-21 9:43 ` Ezequiel Garcia 2013-03-21 9:43 ` Ezequiel Garcia 2013-03-21 10:08 ` Andrew Lunn 2013-03-21 10:08 ` Andrew Lunn 2013-03-21 14:04 ` Sergei Shtylyov 2013-03-21 14:04 ` Sergei Shtylyov 2013-03-21 15:17 ` Ezequiel Garcia 2013-03-21 15:17 ` Ezequiel Garcia 2013-03-21 19:17 ` Russell King - ARM Linux 2013-03-21 19:17 ` Russell King - ARM Linux 2013-03-21 20:21 ` Ezequiel Garcia 2013-03-21 20:21 ` Ezequiel Garcia 2013-03-20 22:36 ` [PATCH 07/16] thermal: mvebu: Fix license declaration Ezequiel Garcia 2013-03-20 22:36 ` Ezequiel Garcia 2013-03-20 22:36 ` [PATCH 08/16] thermal: mvebu: Fix temperature output formula for kirkwood Ezequiel Garcia 2013-03-20 22:36 ` Ezequiel Garcia 2013-03-21 14:41 ` Jason Cooper 2013-03-21 14:41 ` Jason Cooper 2013-03-21 19:20 ` Russell King - ARM Linux 2013-03-21 19:20 ` Russell King - ARM Linux 2013-03-21 20:38 ` Ezequiel Garcia 2013-03-21 20:38 ` Ezequiel Garcia 2013-03-20 22:36 ` [PATCH 09/16] thermal: mvebu: Rename kirkwood definitions to mvebu Ezequiel Garcia 2013-03-20 22:36 ` Ezequiel Garcia 2013-03-20 22:36 ` [PATCH 10/16] thermal: mvebu: Add infrastructure to support more multiple SoC variants Ezequiel Garcia 2013-03-20 22:36 ` Ezequiel Garcia 2013-03-20 22:36 ` [PATCH 11/16] thermal: mvebu: Add support for Armada XP thermal sensor Ezequiel Garcia 2013-03-20 22:36 ` Ezequiel Garcia 2013-03-20 22:36 ` [PATCH 12/16] thermal: mvebu: Add support for Armada 370 " Ezequiel Garcia 2013-03-20 22:36 ` Ezequiel Garcia 2013-03-20 22:36 ` [PATCH 13/16] thermal: mvebu: Add support for Marvell Dove SoC family Ezequiel Garcia 2013-03-20 22:36 ` Ezequiel Garcia 2013-03-21 6:23 ` Andrew Lunn 2013-03-21 6:23 ` Andrew Lunn 2013-03-21 6:26 ` Andrew Lunn 2013-03-21 6:26 ` Andrew Lunn 2013-03-20 22:36 ` [PATCH 14/16] ARM: mvebu: Add thermal support to Armada XP device tree Ezequiel Garcia 2013-03-20 22:36 ` Ezequiel Garcia 2013-03-20 22:36 ` [PATCH 15/16] ARM: mvebu: Add thermal support to Armada 370 " Ezequiel Garcia 2013-03-20 22:36 ` Ezequiel Garcia 2013-03-21 14:03 ` Sergei Shtylyov 2013-03-21 14:03 ` Sergei Shtylyov 2013-03-21 15:18 ` Ezequiel Garcia 2013-03-21 15:18 ` Ezequiel Garcia 2013-03-20 22:36 ` [PATCH 16/16] ARM: configs: Update mvebu, dove and kirkwood defconfigs for thermal Ezequiel Garcia 2013-03-20 22:36 ` Ezequiel Garcia 2013-03-21 6:45 ` [PATCH 00/16] Marvell EBU thermal sensor consolidation Andrew Lunn 2013-03-21 6:45 ` Andrew Lunn 2013-03-21 9:42 ` Ezequiel Garcia 2013-03-21 9:42 ` Ezequiel Garcia 2013-03-21 12:35 ` Ezequiel Garcia 2013-03-21 12:35 ` Ezequiel Garcia 2013-03-21 13:36 ` Andrew Lunn 2013-03-21 13:36 ` Andrew Lunn 2013-03-21 17:32 ` Jason Gunthorpe 2013-03-21 17:32 ` Jason Gunthorpe 2013-03-22 14:23 ` Ezequiel Garcia [this message] 2013-03-22 14:23 ` Ezequiel Garcia 2013-03-21 12:26 ` Ezequiel Garcia 2013-03-21 12:26 ` Ezequiel Garcia
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=20130322142330.GA31661@localhost \ --to=ezequiel.garcia@free-electrons.com \ --cc=alior@marvell.com \ --cc=andrew@lunn.ch \ --cc=florian@openwrt.org \ --cc=gregory.clement@free-electrons.com \ --cc=iwamatsu@nigauri.org \ --cc=jason@lakedaemon.net \ --cc=jgunthorpe@obsidianresearch.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-pm@vger.kernel.org \ --cc=rui.zhang@intel.com \ --cc=sebastian.hesselbarth@gmail.com \ --cc=thomas.petazzoni@free-electrons.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.