All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pankaj Dubey <pankaj.dubey@samsung.com>
To: 'Arnd Bergmann' <arnd@arndb.de>, linux-arm-kernel@lists.infradead.org
Cc: 'Lee Jones' <lee.jones@linaro.org>,
	kgene.kim@samsung.com, linux@arm.linux.org.uk,
	naushad@samsung.com, 'Tomasz Figa' <t.figa@samsung.com>,
	linux-kernel@vger.kernel.org, joshi@samsung.com,
	vikas.sajjan@samsung.com, linux-samsung-soc@vger.kernel.org,
	broonie@kernel.org, thomas.ab@samsung.com, chow.kim@samsung.com
Subject: RE: [PATCH] mfd: syscon: Decouple syscon interface from syscon devices
Date: Tue, 02 Sep 2014 14:02:48 +0530	[thread overview]
Message-ID: <001401cfc688$85c07bf0$914173d0$@samsung.com> (raw)
In-Reply-To: <3109076.4UMHArqVbl@wuerfel>



> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@arndb.de]
> Sent: Tuesday, September 02, 2014 1:45 PM
> To: linux-arm-kernel@lists.infradead.org
> Cc: Lee Jones; kgene.kim@samsung.com; linux@arm.linux.org.uk;
> naushad@samsung.com; Pankaj Dubey; Tomasz Figa;
linux-kernel@vger.kernel.org;
> joshi@samsung.com; vikas.sajjan@samsung.com; linux-samsung-
> soc@vger.kernel.org; broonie@kernel.org; thomas.ab@samsung.com;
> chow.kim@samsung.com
> Subject: Re: [PATCH] mfd: syscon: Decouple syscon interface from syscon
devices
> 
> On Tuesday 02 September 2014 09:05:16 Lee Jones wrote:
> > On Mon, 01 Sep 2014, Arnd Bergmann wrote:
> >
> > > On Monday 01 September 2014 17:04:26 Lee Jones wrote:
> > > > On Mon, 01 Sep 2014, Arnd Bergmann wrote:
> > > > > Maybe I'm misreading the patch, but I don't see how it creates a
> > > > > migration path. What I want to end up with is infrastructure
> > > > > that lets anybody call syscon_regmap_lookup_by_pdevname or
> > > > > syscon_regmap_lookup_by_compatible (if they really need to)
> > > > > without needing the platform_driver for syscon. That should not
> > > > > require any form of compatibility layer because to the driver
> > > > > using it there is no API change.
> > > >
> > > > Somehow I think the likelyhood is that I am misreading the patch.
> > > >
> > > > I thought that before this patch drivers we had to register a
> > > > syscon device to bind to this driver, which was fine for the first
> > > > use-cases of syscon as it wasn't required too early during boot.
> > > > However, now there are use-cases where systems require access to
> > > > syscon registers eariler in boot we require a means to obtain
> > > > access prior to device probing.  I thought this patch not only
> > > > provides that possibilty, but also leaves in the ability to register
direct from
> DT.
> > >
> > > Right, it does provide the ability to have syscon before devices are
> > > registered, I missed that part.
> > >
> > > > > In contrast, this patch introduces a new
> > > > > of_syscon_{un,}register() interface that would get removed after
> > > > > the the above has been implemented, causing extra churn for any
> > > > > driver that also wants to provide a regmap-like interface.
> > > >
> > > > When will we ever not have to register syscon?
> > >
> > > The idea is that we implicitly register the syscon block when
> > > someone calls syscon_regmap_lookup_by_compatible or
> > > syscon_regmap_lookup_by_phandle and then return a reference to that
> > > new syscon. When another driver looks up the same device node, we
> > > just pass a reference to the existing syscon.
> >
> > Doesn't sound too unreasonable.  So how about instead of exporting
> > these new of_syscon_{un,}register() calls, we make them static and
> > call them from syscon_regmap_lookup_by_{phandle,compatible}?
> 
> Yes, that would be a good start. We should think about whether we want to
remove
> the existing DT probing at the same time, since it becomes unused, and we
might
> want to move the code to drivers/base/regmap_*.c at some point.
> 


OK, I am working on these two parts. Once code is in proper form and tested
on
our setup I will post here.

Thanks,
Pankaj

> 	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: pankaj.dubey@samsung.com (Pankaj Dubey)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] mfd: syscon: Decouple syscon interface from syscon devices
Date: Tue, 02 Sep 2014 14:02:48 +0530	[thread overview]
Message-ID: <001401cfc688$85c07bf0$914173d0$@samsung.com> (raw)
In-Reply-To: <3109076.4UMHArqVbl@wuerfel>



> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Tuesday, September 02, 2014 1:45 PM
> To: linux-arm-kernel at lists.infradead.org
> Cc: Lee Jones; kgene.kim at samsung.com; linux at arm.linux.org.uk;
> naushad at samsung.com; Pankaj Dubey; Tomasz Figa;
linux-kernel at vger.kernel.org;
> joshi at samsung.com; vikas.sajjan at samsung.com; linux-samsung-
> soc at vger.kernel.org; broonie at kernel.org; thomas.ab at samsung.com;
> chow.kim at samsung.com
> Subject: Re: [PATCH] mfd: syscon: Decouple syscon interface from syscon
devices
> 
> On Tuesday 02 September 2014 09:05:16 Lee Jones wrote:
> > On Mon, 01 Sep 2014, Arnd Bergmann wrote:
> >
> > > On Monday 01 September 2014 17:04:26 Lee Jones wrote:
> > > > On Mon, 01 Sep 2014, Arnd Bergmann wrote:
> > > > > Maybe I'm misreading the patch, but I don't see how it creates a
> > > > > migration path. What I want to end up with is infrastructure
> > > > > that lets anybody call syscon_regmap_lookup_by_pdevname or
> > > > > syscon_regmap_lookup_by_compatible (if they really need to)
> > > > > without needing the platform_driver for syscon. That should not
> > > > > require any form of compatibility layer because to the driver
> > > > > using it there is no API change.
> > > >
> > > > Somehow I think the likelyhood is that I am misreading the patch.
> > > >
> > > > I thought that before this patch drivers we had to register a
> > > > syscon device to bind to this driver, which was fine for the first
> > > > use-cases of syscon as it wasn't required too early during boot.
> > > > However, now there are use-cases where systems require access to
> > > > syscon registers eariler in boot we require a means to obtain
> > > > access prior to device probing.  I thought this patch not only
> > > > provides that possibilty, but also leaves in the ability to register
direct from
> DT.
> > >
> > > Right, it does provide the ability to have syscon before devices are
> > > registered, I missed that part.
> > >
> > > > > In contrast, this patch introduces a new
> > > > > of_syscon_{un,}register() interface that would get removed after
> > > > > the the above has been implemented, causing extra churn for any
> > > > > driver that also wants to provide a regmap-like interface.
> > > >
> > > > When will we ever not have to register syscon?
> > >
> > > The idea is that we implicitly register the syscon block when
> > > someone calls syscon_regmap_lookup_by_compatible or
> > > syscon_regmap_lookup_by_phandle and then return a reference to that
> > > new syscon. When another driver looks up the same device node, we
> > > just pass a reference to the existing syscon.
> >
> > Doesn't sound too unreasonable.  So how about instead of exporting
> > these new of_syscon_{un,}register() calls, we make them static and
> > call them from syscon_regmap_lookup_by_{phandle,compatible}?
> 
> Yes, that would be a good start. We should think about whether we want to
remove
> the existing DT probing at the same time, since it becomes unused, and we
might
> want to move the code to drivers/base/regmap_*.c at some point.
> 


OK, I am working on these two parts. Once code is in proper form and tested
on
our setup I will post here.

Thanks,
Pankaj

> 	Arnd

  reply	other threads:[~2014-09-02  8:30 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-22  8:09 [PATCH] mfd: syscon: Decouple syscon interface from syscon devices Pankaj Dubey
2014-08-22  8:09 ` Pankaj Dubey
2014-09-01  4:28 ` Pankaj Dubey
2014-09-01  4:28   ` Pankaj Dubey
2014-09-01  7:49 ` Lee Jones
2014-09-01  7:49   ` Lee Jones
2014-09-01 10:37   ` Arnd Bergmann
2014-09-01 10:37     ` Arnd Bergmann
2014-09-01 11:25     ` Lee Jones
2014-09-01 11:25       ` Lee Jones
2014-09-01 14:24       ` Arnd Bergmann
2014-09-01 14:24         ` Arnd Bergmann
2014-09-01 16:04         ` Lee Jones
2014-09-01 16:04           ` Lee Jones
2014-09-01 17:05           ` Arnd Bergmann
2014-09-01 17:05             ` Arnd Bergmann
2014-09-02  8:05             ` Lee Jones
2014-09-02  8:05               ` Lee Jones
2014-09-02  8:14               ` Arnd Bergmann
2014-09-02  8:14                 ` Arnd Bergmann
2014-09-02  8:32                 ` Pankaj Dubey [this message]
2014-09-02  8:32                   ` Pankaj Dubey
2014-09-02  8:34                 ` Lee Jones
2014-09-02  8:34                   ` Lee Jones
2014-09-01 11:35     ` Pankaj Dubey
2014-09-01 11:35       ` Pankaj Dubey
2014-09-01 14:18       ` Arnd Bergmann
2014-09-01 14:18         ` Arnd Bergmann

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='001401cfc688$85c07bf0$914173d0$@samsung.com' \
    --to=pankaj.dubey@samsung.com \
    --cc=arnd@arndb.de \
    --cc=broonie@kernel.org \
    --cc=chow.kim@samsung.com \
    --cc=joshi@samsung.com \
    --cc=kgene.kim@samsung.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=naushad@samsung.com \
    --cc=t.figa@samsung.com \
    --cc=thomas.ab@samsung.com \
    --cc=vikas.sajjan@samsung.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: 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.