[PATCH v2] rtc: snvs: add Freescale rtc-snvs driver

On Wed, Jul 11, 2012 at 08:50:31PM -0500, Kim Phillips wrote:

On Wed, 11 Jul 2012 10:57:55 +0800
Shawn Guo [off-list ref] wrote:

quoted

On Tue, Jul 10, 2012 at 07:02:21PM -0500, Kim Phillips wrote:

quoted

how, without the "simple-bus" addition to the sec_mon compatibles
list in the imx6 device tree (which isn't present in this patch)?

This patch does not present anything about sec_mon node.

it makes a change to its definition in the device tree documentation.

quoted

 It's all about sec_mon_rtc_lp node.

the change is that the sec_mon node now includes the sec_mon_rtc_lp
node, and they are related, just as in h/w.

I'm primarily talking about drivers/rtc/rtc-snvs.c.  There is no change
required on drivers/rtc/rtc-snvs.c whether the device is created by
a sec_mon driver or "simple-bus" approach.

quoted

The driver itself does not know if the
rtc_lp node is a subnode of sec_mon node at all.

I understand that, but as it stands (and AFAICT), this patch by
itself doesn't enable the driver to be probed on _any_ platform,
including ARM.

It's never a thing that RTC driver should care.  As long as the driver
is verified to be functional, it's platform's call to enable the device
or not on particular board/system.

quoted

Can you please tell me what exact change you expect me to make on
drivers/rtc/rtc-snvs.c?  The patch merely adds a lp-rtc driver and
should not include any platform specific changes (dts, etc.)  The
driver and dts changes are two orthogonal parts, and should go via
RTC tree and ARCH tree separately.

That's odd; I would expect all enabling changes to either be
included in the same patch, or at least in the same patchseries, and
one subsystem maintainer ack the other.  If ARM-related patch
processes differ somehow, then so be it.

I don't think it's an ARM-related process.  The process you mentioned
is only used for particular case where a series touches multiple
subsystems while the whole series has to go via one tree in order to
maintain "git bisect".  Since there is no bisect for a new driver to
maintain at all, it should just follow the general process, having
patches go via respective subsystem tree to minimize the merge conflicts
when different trees get merged together.

-- 
Regards,
Shawn