Can someone Ack and queue a patch for RTC subsytem?

Can someone Ack and queue a patch for RTC subsytem?

[Arnaud Ebalard]

Hi,

I have a very simple driver (support for reading and setting the time)
for a RTC chip (Intersil ISL 12057) but cannot find anyone to get it
Acked and queued for v3.14. In v3.14, there should be at least three
users of the driver (ReadyNAS 102, 104 and 2120) if I meet -rc5 cutoff
for associated .dts changes.

I never heard of *listed* RTC maintainer during all the review process
on rtc-linux list (v0 sent in october); I dug the list archives and when
this previously happened, someone else (e.g. Andrew Morton) was kind
enough to handle the patches:

  http://www.spinics.net/lists/arm-kernel/msg292187.html

I wonder if someone (Andrew? Stephen? Jason?) would be kind enough to
take care of the v6 I just sent [1].

It has been:

  Reviewed-by: Guenter Roeck <linux@roeck-us.net>
  Reviewed-by: Mark Brown <brownie@linaro.org>

Cheers,

a+

[1]: http://patchwork.ozlabs.org/patch/303616/

Can someone Ack and queue a patch for RTC subsytem?

[Alessandro Zummo]

On Thu, 19 Dec 2013 17:34:09 +0100
arno at natisbad.org (Arnaud Ebalard) wrote:

> I never heard of *listed* RTC maintainer during all the review process
> on rtc-linux list (v0 sent in october); I dug the list archives and when
> this previously happened, someone else (e.g. Andrew Morton) was kind
> enough to handle the patches:

 Yes, Andrew usually pick those. I do not maintain a separate tree
 due to most RTCs being specifit to a subsytem.

> 
>   http://www.spinics.net/lists/arm-kernel/msg292187.html

 Regarding your patch, please do not add entries to /proc.
 Use sysfs if you need.

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

Can someone Ack and queue a patch for RTC subsytem?

[Arnaud Ebalard]

Hi,

Alessandro Zummo <a.zummo@towertech.it> writes:

> On Thu, 19 Dec 2013 17:34:09 +0100
> arno at natisbad.org (Arnaud Ebalard) wrote:
>
>> I never heard of *listed* RTC maintainer during all the review process
>> on rtc-linux list (v0 sent in october); I dug the list archives and when
>> this previously happened, someone else (e.g. Andrew Morton) was kind
>> enough to handle the patches:
>
>  Yes, Andrew usually pick those. 

I guess he should be put in the MAINTAINERS file then. Otherwise,
get_maintainer.pl script can not do its job correctly and people
end up thinking you should be the one handling those.


> I do not maintain a separate tree due to most RTCs being specifit to a
> subsytem. 

I do not understand: the chip is generic, i.e. this is not a RTC chip
specific to a given SoC (like rtc-mv.c is for instance). Can you be
more specific?


>>   http://www.spinics.net/lists/arm-kernel/msg292187.html
>
>  Regarding your patch, please do not add entries to /proc.
>  Use sysfs if you need.

Well, this is what is currently described in the documentation
(Documentation/rtc.txt), in drivers/rtc/rtc-test.c driver and what
many drivers do (AFAICT, 22/125).

Additionally, I only provide some additional info for an existing
file: the /proc entry is created by the drivers/rtc/class.c as
soon as someone selects CONFIG_RTC_INTF_PROC.

Do you want me to send a v7 w/ the .proc helper removed or leave
things as they are and Ack the patch as is?

Cheers,

a+

Can someone Ack and queue a patch for RTC subsytem?

[Alessandro Zummo]

On Thu, 19 Dec 2013 18:28:16 +0100
arno at natisbad.org (Arnaud Ebalard) wrote:

> >  Yes, Andrew usually pick those.   
>
> I guess he should be put in the MAINTAINERS file then. Otherwise,
> get_maintainer.pl script can not do its job correctly and people
> end up thinking you should be the one handling those.

 That makes sense, I'll leave the decision add his email to Andrew. 


> > I do not maintain a separate tree due to most RTCs being specifit to a
> > subsytem.   
> 
> I do not understand: the chip is generic, i.e. this is not a RTC chip
> specific to a given SoC (like rtc-mv.c is for instance). Can you be
> more specific?

 Yes, this chip is generic, but most aren't. Some of those who
 are generic, are strictly connected to a particular system/board, 
 and they end up in that system's tree. Most of the drivers
 are pretty small.
 

> >  Regarding your patch, please do not add entries to /proc.
> >  Use sysfs if you need.  
> 
> Well, this is what is currently described in the documentation
> (Documentation/rtc.txt), in drivers/rtc/rtc-test.c driver and what
> many drivers do (AFAICT, 22/125).

 This needs to be fixed as well. Documentation.txt does not suggest
 to add arbitrary values to the procfs. "many do" does not apply.


> Additionally, I only provide some additional info for an existing
> file: the /proc entry is created by the drivers/rtc/class.c as
> soon as someone selects CONFIG_RTC_INTF_PROC.

 I know, but that makes the procfs entry a mess. sysfs is the way,


> Do you want me to send a v7 w/ the .proc helper removed or leave
> things as they are and Ack the patch as is?

 Unless absolutely needed, I'd prefer if you can remove them
 or move to sysfs.

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

Can someone Ack and queue a patch for RTC subsytem?

[Jason Cooper]

On Thu, Dec 19, 2013 at 06:40:24PM +0100, Alessandro Zummo wrote:
> On Thu, 19 Dec 2013 18:28:16 +0100 arno at natisbad.org (Arnaud Ebalard) wrote:
> > At some point, Alessandro Zummo wrote:
...
> > > I do not maintain a separate tree due to most RTCs being specifit to a
> > > subsytem.   
> > 
> > I do not understand: the chip is generic, i.e. this is not a RTC chip
> > specific to a given SoC (like rtc-mv.c is for instance). Can you be
> > more specific?
> 
>  Yes, this chip is generic, but most aren't. Some of those who
>  are generic, are strictly connected to a particular system/board, 
>  and they end up in that system's tree. Most of the drivers
>  are pretty small.

That goes against the whole goal of the arm-soc devicetree conversion.
For the past several years, we've been moving drivers _out_ of arch/arm/
into the appropriate drivers/ area.  The goal of this was to unclutter
arch/arm/, and to more readily see and remove code duplication by
drivers.

thx,

Jason.

Can someone Ack and queue a patch for RTC subsytem?

[Alessandro Zummo]

On Thu, 19 Dec 2013 13:01:36 -0500
Jason Cooper <jason@lakedaemon.net> wrote:

> That goes against the whole goal of the arm-soc devicetree conversion.
> For the past several years, we've been moving drivers _out_ of arch/arm/
> into the appropriate drivers/ area.  The goal of this was to unclutter
> arch/arm/, and to more readily see and remove code duplication by
> drivers.

 I meant in drivers/rtc but using another tree. 

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

Can someone Ack and queue a patch for RTC subsytem?

[Arnaud Ebalard]

Hi,

Alessandro Zummo <a.zummo@towertech.it> writes:

>> Do you want me to send a v7 w/ the .proc helper removed or leave
>> things as they are and Ack the patch as is?
>
>  Unless absolutely needed, I'd prefer if you can remove them
>  or move to sysfs.

Well, my helper provides info on control and status registers flags
(just like rtc-isl1208.c does), which are useful mainly for debug I
guess. If this can help pushing things forward, I will send a v7 later
today w/ the .proc helper removed from the patch.

Cheers,

a+

Can someone Ack and queue a patch for RTC subsytem?

[Jason Cooper]

On Thu, Dec 19, 2013 at 07:05:49PM +0100, Arnaud Ebalard wrote:
> Hi,
> 
> Alessandro Zummo <a.zummo@towertech.it> writes:
> 
> >> Do you want me to send a v7 w/ the .proc helper removed or leave
> >> things as they are and Ack the patch as is?
> >
> >  Unless absolutely needed, I'd prefer if you can remove them
> >  or move to sysfs.
> 
> Well, my helper provides info on control and status registers flags
> (just like rtc-isl1208.c does), which are useful mainly for debug I
> guess. If this can help pushing things forward, I will send a v7 later
> today w/ the .proc helper removed from the patch.

Why not convert to debugfs?

thx,

Jason.

Can someone Ack and queue a patch for RTC subsytem?

[Guenter Roeck]

On Thu, Dec 19, 2013 at 01:09:40PM -0500, Jason Cooper wrote:
> On Thu, Dec 19, 2013 at 07:05:49PM +0100, Arnaud Ebalard wrote:
> > Hi,
> > 
> > Alessandro Zummo <a.zummo@towertech.it> writes:
> > 
> > >> Do you want me to send a v7 w/ the .proc helper removed or leave
> > >> things as they are and Ack the patch as is?
> > >
> > >  Unless absolutely needed, I'd prefer if you can remove them
> > >  or move to sysfs.
> > 
> > Well, my helper provides info on control and status registers flags
> > (just like rtc-isl1208.c does), which are useful mainly for debug I
> > guess. If this can help pushing things forward, I will send a v7 later
> > today w/ the .proc helper removed from the patch.
> 
> Why not convert to debugfs?
> 
Separate follow-on patch, maybe, to keep things going ?

Guenter

Can someone Ack and queue a patch for RTC subsytem?

[Jason Cooper]

On Thu, Dec 19, 2013 at 11:48:37AM -0800, Guenter Roeck wrote:
> On Thu, Dec 19, 2013 at 01:09:40PM -0500, Jason Cooper wrote:
> > On Thu, Dec 19, 2013 at 07:05:49PM +0100, Arnaud Ebalard wrote:
> > > Hi,
> > > 
> > > Alessandro Zummo <a.zummo@towertech.it> writes:
> > > 
> > > >> Do you want me to send a v7 w/ the .proc helper removed or leave
> > > >> things as they are and Ack the patch as is?
> > > >
> > > >  Unless absolutely needed, I'd prefer if you can remove them
> > > >  or move to sysfs.
> > > 
> > > Well, my helper provides info on control and status registers flags
> > > (just like rtc-isl1208.c does), which are useful mainly for debug I
> > > guess. If this can help pushing things forward, I will send a v7 later
> > > today w/ the .proc helper removed from the patch.
> > 
> > Why not convert to debugfs?
> > 
> Separate follow-on patch, maybe, to keep things going ?

Sure.

thx,

Jason.

Can someone Ack and queue a patch for RTC subsytem?

[Jason Cooper]

Arnaud,

On Thu, Dec 19, 2013 at 05:34:09PM +0100, Arnaud Ebalard wrote:
> I have a very simple driver (support for reading and setting the time)
> for a RTC chip (Intersil ISL 12057) but cannot find anyone to get it
> Acked and queued for v3.14. In v3.14, there should be at least three
> users of the driver (ReadyNAS 102, 104 and 2120) if I meet -rc5 cutoff
> for associated .dts changes.

The -rc5 cutoff isn't a hard line.  It's also mvebu-specific.  eg, We
need things _posted_ a week or so before arm-soc's cutoff of -rc6 so we
have time to get the pull request in.  If it needs to go through
mvebu/arm-soc, once it's posted, you're good.

The rtc driver shouldn't go through mvebu/arm-soc.  It should go through
the rtc maintainer's tree.

> I never heard of *listed* RTC maintainer during all the review process
> on rtc-linux list (v0 sent in october); I dug the list archives and when
> this previously happened, someone else (e.g. Andrew Morton) was kind
> enough to handle the patches:
> 
>   http://www.spinics.net/lists/arm-kernel/msg292187.html

Unfortunately, it doesn't look like Alessandro has been active for a
while and Andrew Morton has indeed been picking up the slack.  S-o-B's
confirm this.

I haven't worked with Andrew enough to know his workflow, but I imagine
he can take patches much closer to the merge window than we can.

> I wonder if someone (Andrew? Stephen? Jason?) would be kind enough to
> take care of the v6 I just sent [1].

I don't mind routing it though mvebu/arm-soc since the only consumers
are currently mvebu boards, but I'd like to hear from Andrew that this
is ok.

In the long term, should we seek out a co-maintainer for drivers/rtc?
Can anyone get a hold of Alessandro to get his opinion on this?

thx,

Jason.

> [1]: http://patchwork.ozlabs.org/patch/303616/

[rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?

[Alessandro Zummo]

On Thu, 19 Dec 2013 11:46:24 -0500
Jason Cooper <jason@lakedaemon.net> wrote:

> In the long term, should we seek out a co-maintainer for drivers/rtc?
> Can anyone get a hold of Alessandro to get his opinion on this?

 I'd surely appreciate if someone can take some time to give
 a look to the patches. Most of them go thru subsystem's tree and, as far as I
 can see, I saw very relevant comments and fixes in all those years.

 I'd love to devote more time to Linux but I'd need to find
 someone that hires me just to do that the whole day :)

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?

[Arnaud Ebalard]

Hi,

Alessandro Zummo <a.zummo@towertech.it> writes:

> On Thu, 19 Dec 2013 11:46:24 -0500
> Jason Cooper <jason@lakedaemon.net> wrote:
>
>> In the long term, should we seek out a co-maintainer for drivers/rtc?
>> Can anyone get a hold of Alessandro to get his opinion on this?
>
>  I'd surely appreciate if someone can take some time to give
>  a look to the patches. Most of them go thru subsystem's tree and, as
>  far as I can see, I saw very relevant comments and fixes in all those
>  years.

While I am at it, I wonder if you can give me some directions on the
following to add back alarm support to the ISL12057 on the specific
hardware I have.

All NETGEAR ReadyNAS 102, 104 and 2120 have an ISL 12057 RTC chip which
is used as main RTC clock but can also provide alarm. But the alarm
interrupt line of the chip is *not* connected to the SoC. It is
connected to some power component and can be used to wake up the NAS
when it is completely off and the alarm rings.

To me this kind of setup seems logical but it does not seem to be
directly supported by current RTC logic:

 - first, I cannot test an interrupt handler implementation I had
   written as the SoC will never receive any interrupt. This limits
   my ability to provide one to the driver.
 - what can/should be done in my .dts file to indicate that the
   device does not have any IRQ line connected (and hence no interrupt
   handler) to the SoC but still supports an alarm.

As a side note, the implementation I had was a working one on my
hardware (i.e. was able to wake up the device at a given time) but I had
to remove alarm code to get a basic driver accepted upstream.

To be honest, I tried and understand what RTC subsystem expects from
documentation and code w/o success. Any help appreciated on that topic.

Cheers,

a+

[rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?

[Mark Brown]

On Thu, Dec 19, 2013 at 11:17:44PM +0100, Arnaud Ebalard wrote:

> All NETGEAR ReadyNAS 102, 104 and 2120 have an ISL 12057 RTC chip which
> is used as main RTC clock but can also provide alarm. But the alarm
> interrupt line of the chip is *not* connected to the SoC. It is
> connected to some power component and can be used to wake up the NAS
> when it is completely off and the alarm rings.

Can the PMIC or whatever function as an interrupt controller and report
the interrupt on to the SoC?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131220/53c4ab39/attachment.sig>

[rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?

[Arnaud Ebalard]

Hi,

Mark Brown <broonie@kernel.org> writes:

> On Thu, Dec 19, 2013 at 11:17:44PM +0100, Arnaud Ebalard wrote:
>
>> All NETGEAR ReadyNAS 102, 104 and 2120 have an ISL 12057 RTC chip which
>> is used as main RTC clock but can also provide alarm. But the alarm
>> interrupt line of the chip is *not* connected to the SoC. It is
>> connected to some power component and can be used to wake up the NAS
>> when it is completely off and the alarm rings.
>
> Can the PMIC or whatever function as an interrupt controller and report
> the interrupt on to the SoC?

I do not even know to which specific component the irq line of the chip
is connected. You can take a look at [1] to see what's on the PCB; if
you have an idea about which one could be a good candidate (TPS65251?),
I can try and check with an ohmmeter which pin is connected to confirm
your guess. Then, I could look at the datasheet (if any) to see if it
can relay the interrupt to the SoC (if the component is supported by
Linux kernel).

But, except if we can do what you propose, there are two problems at
hand:

 1) I cannot currently test the IRQ handler my changes would bring
 because it is not connected to the SoC on my platforms

 2) even if I find a solution for 1), noone ever provided any directions
 on what should be required to make some program like rtc-test.c happy on
 my platforms (alarm support but no interrupt from the RTC). e.g. some 
 refinements like the one introduced by c9f5c7e7a84f1b7 (rtc: rtc-spear:
 Provide flag for no support of UIE mode). I guess it should be fairly
 simple for someone w/ good knowledge of the RTC subsystem to tell what
 is needed. I do not have that knowledge and the documentation does not
 help.

Regarding 1), I am starting to wonder if the best way out would not be
for me to connect the interrupt line of the ISL12057 to one of the GPIO
line currently connected to the LCD on my RN104 (after having
disconnected the LCD) and change the function of the associated MPP on
the SoC to make it an interrupt line. Could that work w/o additional
hardware modification? What are my chances of killing the board?

But this is pointless if I do not get any clear directions about 2).

Cheers,

a+

[1]: http://natisbad.org/NAS2/index.html#hw

[rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?

[Mark Brown]

On Fri, Dec 20, 2013 at 09:23:46PM +0100, Arnaud Ebalard wrote:

> I do not even know to which specific component the irq line of the chip
> is connected. You can take a look at [1] to see what's on the PCB; if
> you have an idea about which one could be a good candidate (TPS65251?),
> I can try and check with an ohmmeter which pin is connected to confirm
> your guess. Then, I could look at the datasheet (if any) to see if it
> can relay the interrupt to the SoC (if the component is supported by
> Linux kernel).

That's a PMIC which is what I'd expect if it's able to wake the device -
if it's anything like the other TI PMICs it ought to be able to act as
an interrupt controller.

Can someone Ack and queue a patch for RTC subsytem?

[Arnaud Ebalard]

Hi,

Jason Cooper <jason@lakedaemon.net> writes:

> On Thu, Dec 19, 2013 at 05:34:09PM +0100, Arnaud Ebalard wrote:
>> I have a very simple driver (support for reading and setting the time)
>> for a RTC chip (Intersil ISL 12057) but cannot find anyone to get it
>> Acked and queued for v3.14. In v3.14, there should be at least three
>> users of the driver (ReadyNAS 102, 104 and 2120) if I meet -rc5 cutoff
>> for associated .dts changes.
>
> The -rc5 cutoff isn't a hard line.  It's also mvebu-specific.  eg, We
> need things _posted_ a week or so before arm-soc's cutoff of -rc6 so we
> have time to get the pull request in.  If it needs to go through
> mvebu/arm-soc, once it's posted, you're good.

I understand. But I guess you will not (for valid reason) accept .dts
changes to reference a rtc driver that is not on good track towards
-next. This is the issue I try and solve.


>> I never heard of *listed* RTC maintainer during all the review process
>> on rtc-linux list (v0 sent in october); I dug the list archives and when
>> this previously happened, someone else (e.g. Andrew Morton) was kind
>> enough to handle the patches:
>> 
>>   http://www.spinics.net/lists/arm-kernel/msg292187.html
>
> Unfortunately, it doesn't look like Alessandro has been active for a
> while and Andrew Morton has indeed been picking up the slack.  S-o-B's
> confirm this.
>
> I haven't worked with Andrew enough to know his workflow, but I imagine
> he can take patches much closer to the merge window than we can.
>
>> I wonder if someone (Andrew? Stephen? Jason?) would be kind enough to
>> take care of the v6 I just sent [1].
>
> I don't mind routing it though mvebu/arm-soc since the only consumers
> are currently mvebu boards, but I'd like to hear from Andrew that this
> is ok.

I will do what you think is the best.

Cheers,

a+

Can someone Ack and queue a patch for RTC subsytem?

[Alessandro Zummo]

On Thu, 19 Dec 2013 18:46:18 +0100
arno at natisbad.org (Arnaud Ebalard) wrote:

> > I don't mind routing it though mvebu/arm-soc since the only consumers
> > are currently mvebu boards, but I'd like to hear from Andrew that this
> > is ok.  
> 
> I will do what you think is the best.

 If the only consumers are mvebu boards, I believe it is correct to
 route though that tree. imho.

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

Can someone Ack and queue a patch for RTC subsytem?

[Maxime Ripard]

Hi Alessandro,

On Thu, Dec 19, 2013 at 06:49:24PM +0100, Alessandro Zummo wrote:
> On Thu, 19 Dec 2013 18:46:18 +0100
> arno at natisbad.org (Arnaud Ebalard) wrote:
> 
> > > I don't mind routing it though mvebu/arm-soc since the only consumers
> > > are currently mvebu boards, but I'd like to hear from Andrew that this
> > > is ok.  
> > 
> > I will do what you think is the best.
> 
>  If the only consumers are mvebu boards, I believe it is correct to
>  route though that tree. imho.

We're pretty much in the same situation for the Allwinner RTC driver

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-November/211849.html

I'm fine with merging it through my tree, however, we still need some
reviews and an Acked-by from you.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131220/1d53aebe/attachment.sig>

Can someone Ack and queue a patch for RTC subsytem?

[Alessandro Zummo]

On Fri, 20 Dec 2013 10:03:04 +0100
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:

> We're pretty much in the same situation for the Allwinner RTC driver
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-November/211849.html
> 
> I'm fine with merging it through my tree, however, we still need some
> reviews and an Acked-by from you.


 Looking at it..

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

Can someone Ack and queue a patch for RTC subsytem?

[Jason Cooper]

On Thu, Dec 19, 2013 at 06:46:18PM +0100, Arnaud Ebalard wrote:
> Jason Cooper <jason@lakedaemon.net> writes:
> > On Thu, Dec 19, 2013 at 05:34:09PM +0100, Arnaud Ebalard wrote:
...
> >> I wonder if someone (Andrew? Stephen? Jason?) would be kind enough to
> >> take care of the v6 I just sent [1].
> >
> > I don't mind routing it though mvebu/arm-soc since the only consumers
> > are currently mvebu boards, but I'd like to hear from Andrew that this
> > is ok.
> 
> I will do what you think is the best.

It sounds like once you address Alessandro's concerns about /proc
entries, we should be able to take v7 through mvebu/arm-soc.

thx,

Jason.

Can someone Ack and queue a patch for RTC subsytem?

[Jason Cooper]

On Thu, Dec 19, 2013 at 06:46:18PM +0100, Arnaud Ebalard wrote:
> Hi,
> 
> Jason Cooper <jason@lakedaemon.net> writes:
> 
> > On Thu, Dec 19, 2013 at 05:34:09PM +0100, Arnaud Ebalard wrote:
> >> I have a very simple driver (support for reading and setting the time)
> >> for a RTC chip (Intersil ISL 12057) but cannot find anyone to get it
> >> Acked and queued for v3.14. In v3.14, there should be at least three
> >> users of the driver (ReadyNAS 102, 104 and 2120) if I meet -rc5 cutoff
> >> for associated .dts changes.
> >
> > The -rc5 cutoff isn't a hard line.  It's also mvebu-specific.  eg, We
> > need things _posted_ a week or so before arm-soc's cutoff of -rc6 so we
> > have time to get the pull request in.  If it needs to go through
> > mvebu/arm-soc, once it's posted, you're good.
> 
> I understand. But I guess you will not (for valid reason) accept .dts
> changes to reference a rtc driver that is not on good track towards
> -next. This is the issue I try and solve.

Just a subtle note here.  If the binding is stabilized, I don't mind
taking the dts changes.  However, if we have time, I prefer to wait for
the whole series to be hashed out.  You never know which resolutions
will end up revisiting the bindings you thought were good. :)

So, it's technically not a requirement for the whole driver to be
settled, but it is a good idea.

thx,

Jason.