[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAC4G8N7Agb6pVVv6x9_pMMxkB9HnCFiaaC6EJb4-MNzEPd0Uhw@mail.gmail.com>
Date: Thu, 23 Jul 2020 21:41:16 +0100
From: Miguel Borges de Freitas <miguelborgesdefreitas@...il.com>
To: Alexandre Belloni <alexandre.belloni@...tlin.com>
Cc: Rob Herring <robh@...nel.org>, a.zummo@...ertech.it,
baruch@...s.co.il, linux@...linux.org.uk, shawnguo@...nel.org,
s.hauer@...gutronix.de, kernel@...gutronix.de, festevam@...il.com,
linux-imx@....com, devicetree@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/3] dt-bindings: rtc: pcf8523: add DSM pm option for
battery switch-over
Hi Alexandre,
Having a way to dynamically change the configuration would definitely
be helpful in most cases. I decided to go with a DT property because
in the case this patch tries to solve (the cubox-i) there isn't simply
any other option - the default mode won't work due to the missing hw
components. So, I thought that by defining it as a DT property it
could somehow be locked to the hardware definition.
Keep me posted
Regards
PS: Sorry for the second message, forgot to disable html and the
message couldn't be delivered to all recipients.
Alexandre Belloni <alexandre.belloni@...tlin.com> escreveu no dia
quinta, 23/07/2020 à(s) 20:57:
>
> >
> > I'm all for common properties, but is this common across vendors?
> >
>
> This is but this shouldn't be a DT property as it has to be changed
> dynamically. I'm working on an ioctl interface to change this
> configuration.
>
>
> --
> Alexandre Belloni, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
Powered by blists - more mailing lists