Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200720112401.4620-2-miguelborgesdefreitas@gmail.com>
 <20200723174905.GA596242@bogus> <20200723195755.GV3428@piout.net>
 <20200727094553.GH1551@shell.armlinux.org.uk> <20200727144938.GC239143@piout.net>
 <20200727152439.GK1551@shell.armlinux.org.uk> <20200727154104.GE239143@piout.net>
 <20200727154335.GL1551@shell.armlinux.org.uk> <CABdtJHuVaTa5T0-KdQ-wZQrmFQ6HO3FvgnTgSo3aOi+=SPzDZA@mail.gmail.com>
 <20200727161632.GF239143@piout.net> <20200727173051.GM1551@shell.armlinux.org.uk>
In-Reply-To: <20200727173051.GM1551@shell.armlinux.org.uk>
From:   Miguel Borges de Freitas <miguelborgesdefreitas@gmail.com>
Date:   Mon, 27 Jul 2020 22:13:42 +0100
Message-ID: <CAC4G8N5zUVc0YvT9mCP4BfeQD+KOAo6Rbswo8zqUh_mULa=Xsg@mail.gmail.com>
Subject: Re: [PATCH v2 1/3] dt-bindings: rtc: pcf8523: add DSM pm option for
 battery switch-over
To:     Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc:     Alexandre Belloni <alexandre.belloni@bootlin.com>,
        Jon Nettleton <jon@solid-run.com>,
        Rob Herring <robh@kernel.org>, a.zummo@towertech.it,
        Baruch Siach <baruch@tkos.co.il>,
        Shawn Guo <shawnguo@kernel.org>,
        Sascha Hauer <s.hauer@pengutronix.de>,
        Sascha Hauer <kernel@pengutronix.de>,
        Fabio Estevam <festevam@gmail.com>,
        NXP Linux Team <linux-imx@nxp.com>,
        devicetree <devicetree@vger.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Russell King - ARM Linux admin <linux@armlinux.org.uk> escreveu no dia
segunda, 27/07/2020 =C3=A0(s) 18:30:
>
> On Mon, Jul 27, 2020 at 06:16:32PM +0200, Alexandre Belloni wrote:
> > On 27/07/2020 17:55:50+0200, Jon Nettleton wrote:
> > > > So, can we please have that discussion, it is pertinent to this pat=
ch.
> > > >
> > >
> > > Thinking about this some more, I believe whether or not an IOCTL
> > > interface is in the works or needed is irrelevant.  This patch
> > > describes the hardware and how it is designed and the topic of
> > > discussion is if we need a simple boolean state, or if we need
> > > something that could be used to support dynamic configuration in the
> > > future.  I would rather make this decision now rather than keep
> > > tacking on boolean config options, or revisit a bunch of device-tree
> > > changes.

For what it's worth I also tend to agree.
The patchset, regardless of the property name (that I admit might be
misleading), is intended at enforcing a mode that the RTC/driver
should use by default. This mode is strongly related to the hardware
definition/implementation and its capabilities. While I understand the
need for the IOCTL interface to solve issues exactly like the
aforementioned factory example, I fail to see how it can be of any
help to solve the problem at hand - as it won't likely configure the
driver to use a different default mode depending on the board. The
IOCTL interface might also allow the userspace to change this property
back to the default mode (000) and end up breaking the RTC operation,
but I guess that's the cost of configurability and, in the end, the
user's responsibility.
Any pointers on how to proceed are appreciated.

Regards,

Miguel