linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: monstr@monstr.eu (Michal Simek)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC] mfd: syscon: Decouple syscon interface from syscon devices
Date: Thu, 19 Jun 2014 02:06:20 +0200	[thread overview]
Message-ID: <53A2297C.106@monstr.eu> (raw)
In-Reply-To: <5537724.LlmJ2hxcKn@wuerfel>

Hi,

On 06/18/2014 02:57 PM, Arnd Bergmann wrote:
> On Tuesday 17 June 2014 23:26:22 Tomasz Figa wrote:
>> On 17.06.2014 17:42, Arnd Bergmann wrote:
>>> This seems like a reasonable way of solving the problem, but I think
>>> there is an even better one that we have about in the past: if we
>>> promote syscon from a platform driver into a a drivers/base/ helper
>>> that is independent of the platform device matching, we can use
>>> call syscon_regmap_lookup_* for any device node, whether it's already
>>> bound to a driver or not, which do what you need. It would also make
>>> it easier to call the syscon code before the platform_device
>>> infrastructure gets initialized, which is something a number of
>>> people have asked for, e.g. for using regmap to do SMP bringup
>>> or for clock registration.
>>
>> Basically, unless I'm missing your point, this is what my patch does,
>> except that I don't move it to drivers/base/ and the registration
>> function I added require a pointer to struct device. Indeed, decoupling
>> it further from the driver model, by adding of_syscon_register() should
>> be useful for early users.
> 
> I believe the part you are missing is that with the approach I suggested,
> there would be no registration function at all. You can easily do the
> lookup from the client drivers using the DT data structures, with no
> need for the device at all. The only exception today is the clps711x
> platform using syscon_regmap_lookup_by_pdevname(), but that should be
> solved in 3.17 when clps711x becomes DT-only.

I agree with Arnd. This patch is doing the part of what we wanted to do with it.
It means create a list of registered devices.
But you are working with struct device which you can't use in early phase
which is the feature we wanted to use. But currently we have workaround
in the kernel and clk subsystem is not able to work with regmap anyway.

Moving to proper location is just the last step.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140619/fb7b5507/attachment.sig>

  reply	other threads:[~2014-06-19  0:06 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-10  6:56 [PATCH v4 00/11] ARM: Exynos: PMU cleanup and refactoring for using DT Pankaj Dubey
2014-05-10  6:56 ` [PATCH v4 01/11] ARM: EXYNOS: Make exynos machine_ops as static Pankaj Dubey
2014-06-10 11:43   ` Tomasz Figa
2014-05-10  6:56 ` [PATCH v4 02/11] ARM: EXYNOS: Move cpufreq and cpuidle device registration to init_machine Pankaj Dubey
2014-06-10 11:46   ` Tomasz Figa
2014-06-17  3:48     ` Pankaj Dubey
2014-05-10  6:56 ` [PATCH v4 03/11] ARM: EXYNOS: Move SYSREG definition into sys-reg specific file Pankaj Dubey
2014-05-10  6:56 ` [PATCH v4 04/11] ARM: EXYNOS: Remove file path from comment section Pankaj Dubey
2014-05-10  6:56 ` [PATCH v4 05/11] ARM: EXYNOS: Remove regs-pmu.h header dependency from pm_domain Pankaj Dubey
2014-05-10  6:56 ` [PATCH v4 06/11] ARM: EXYNOS: Add support for mapping PMU base address via DT Pankaj Dubey
2014-06-10 17:10   ` Tomasz Figa
2014-06-17  6:43     ` Pankaj Dubey
2014-06-17 15:26       ` Tomasz Figa
2014-06-17 15:32         ` [PATCH RFC] mfd: syscon: Decouple syscon interface from syscon devices Tomasz Figa
2014-06-17 15:42           ` Arnd Bergmann
2014-06-17 21:26             ` Tomasz Figa
2014-06-18  8:26               ` Lee Jones
2014-06-24 11:03                 ` Pankaj Dubey
2014-06-18 12:57               ` Arnd Bergmann
2014-06-19  0:06                 ` Michal Simek [this message]
2014-07-28  4:15                 ` Pankaj Dubey
2014-05-10  6:56 ` [PATCH v4 07/11] ARM: EXYNOS: Remove "linux/bug.h" from pmu.c Pankaj Dubey
2014-05-10  6:56 ` [PATCH v4 08/11] ARM: EXYNOS: Refactored code for using PMU address via DT Pankaj Dubey
2014-06-17 16:02   ` Tomasz Figa
2014-05-10  6:56 ` [PATCH v4 09/11] ARM: EXYNOS: Move "mach/map.h" inclusion from regs-pmu.h to platsmp.c Pankaj Dubey
2014-06-17 16:04   ` Tomasz Figa
2014-05-10  6:56 ` [PATCH v4 10/11] ARM: EXYNOS: Add platform driver support for Exynos PMU Pankaj Dubey
2014-06-17 17:12   ` Tomasz Figa
2014-06-24 11:28     ` Pankaj Dubey
2014-06-25  0:11       ` Tomasz Figa
2014-06-25  4:30         ` Pankaj Dubey
2014-05-10  6:56 ` [PATCH v4 11/11] ARM: EXYNOS: Move PMU specific definitions from common.h Pankaj Dubey
2014-05-27 11:26 ` [PATCH v4 00/11] ARM: Exynos: PMU cleanup and refactoring for using DT Vikas Sajjan
2014-05-30 11:58   ` Tomasz Figa

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=53A2297C.106@monstr.eu \
    --to=monstr@monstr.eu \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).