On Wed, Jun 21, 2017 at 09:26:51AM +, David Laight wrote:
> From: Russell King - ARM Linux
> > Sent: 20 June 2017 22:16
> ..
> > Consider that at the moment, we define the 32-bit RTC representation to
> > start at a well known epoch. We _could_ decide that when it
On Wed, Jun 21, 2017 at 10:39:07AM +0200, Alexandre Belloni wrote:
> On 21/06/2017 at 09:51:52 +0200, Pavel Machek wrote:
> > If someone uses different threshold, well, there will be
> > confusion. But only for users that have their rtc set to the past,
> > which is quite unusual.
> >
>
> Or not,
On Wed, Jun 21, 2017 at 12:00:30AM +0200, Thomas Gleixner wrote:
> Yes, but there are still quite some issues to solve there:
>
> 1) How do you tell the system that it should apply the offset in the
> first place, i.e at boot time before NTP or any other mechanism can
> correct it
On Tue, Jun 20, 2017 at 11:35:20AM +0200, Benjamin Gaignard wrote:
> rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
> rely on 32bits variables and that will make rtc break in y2038/2016.
> Stop using those two functions to safer 64bits ones.
>
> Signed-off-by: Benjamin Gaignard
On Tue, Jun 20, 2017 at 05:07:46PM +0200, Benjamin Gaignard wrote:
> 2017-06-20 15:48 GMT+02:00 Alexandre Belloni
> :
> >> Yes, that's argument against changing rtc _drivers_ for hardware that
> >> can not do better than 32bit. For generic code (such as 44/51 sysfs,
> >> 51/51 suspend test), the ch
> CC: linux-arm-ker...@lists.infradead.org
>
> Acked-by: Linus Walleij
Naked-again-by: Russell King
Really, people need to stop re-posting the same patches that have
already been naked.
This patch fixes NOTHING.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patch
On Sun, Mar 26, 2017 at 10:41:54PM +0800, Leo Yan wrote:
> Convert to use devm_ioremap_resource() in probe function, otherwise it's
> missed to unremap this region if probe failed or rmmod module.
Again, wrong - just because there's nothing in the cleanup paths does
not mean it doesn't clean up.
On Sun, Mar 26, 2017 at 10:41:50PM +0800, Leo Yan wrote:
> Convert driver to use devm_*() APIs so rely on driver model core layer
> to manage resources. This eliminates error path boilerplate and makes
> code neat.
>
> This patch also fixes the memory leakage for 'kmi->io' when remove
> module.
N
On Mon, Feb 20, 2017 at 06:36:33PM +0100, Alexandre Belloni wrote:
> On 20/02/2017 at 18:06:11 +0100, Gregory CLEMENT wrote:
> > On ven., févr. 17 2017, Gregory CLEMENT
> > wrote:
> >
> > > The Armada 7K/8K SoCs use the same RTC IP than the Armada 38x. However
> > > the SOC integration differs
On Mon, Feb 20, 2017 at 05:27:39PM +, Russell King - ARM Linux wrote:
> No it is not. As I already pointed out, the interrupt for the 8040 is
> GIC_SPI 71 _not_ GIC_SPI 77 as you have it in this series.
>
> Both CP110's on Armada 8040 have a default mapping of ICU 7
On Mon, Feb 20, 2017 at 06:06:11PM +0100, Gregory CLEMENT wrote:
> I saw on IRC than Russell managed to have a more coherent date with this
> series on his 8040 based board. For the record, as the U-Boot on this
> board didn't provide a "date reset" command for the RTC located on CP
> slave, then R
On Thu, Feb 16, 2017 at 05:33:48PM +, Russell King - ARM Linux wrote:
> On Thu, Feb 16, 2017 at 04:31:33PM +0100, Gregory CLEMENT wrote:
> > The Armada 7K/8K SoCs use the same RTC IP than the Armada 38x. However
> > the SOC integration differs in 2 points:
> >
On Thu, Feb 16, 2017 at 04:31:33PM +0100, Gregory CLEMENT wrote:
> The Armada 7K/8K SoCs use the same RTC IP than the Armada 38x. However
> the SOC integration differs in 2 points:
> - MBUS bridge timing initialization
> - IRQ configuration at SoC level
>
> This patch set extends the dri
On Fri, Jan 13, 2017 at 04:32:53PM +0100, Arnd Bergmann wrote:
> -#define PWR_CR_DBP BIT(8)
> +#define PWR_CR_DBP (u32)BIT(8)
Shouldn't that have parens around it as it's no longer a simple expression.
--
RMK's Patch system: http://www.armlinux.org.uk/develope
, both marked
const. This allows the compiler to place them in read-only memory,
which is better than placing them in __ro_after_init.
Thanks to Bhumika Goyal for pointing out that
the structure was writable and submitting a patch to add
__ro_after_init.
Signed-off-by: Russell King
---
As the
On Wed, Jan 04, 2017 at 01:23:41PM +0100, Julia Lawall wrote:
> Basically, the strategy of the patch is that one may consider it
> preferable to duplicate the structure for the different alternatives,
> rather than use __ro_after_init. Perhaps if the structure were larger,
> then __ro_after_init w
On Wed, Jan 04, 2017 at 12:43:32PM +0100, Julia Lawall wrote:
> > The question was whether the point to the rtc_class_ops could be made
> > __ro_after_init. And Russell is right, it is pointed to by the ops
> > pointer in a struct rtc_device and that struct is dynamically allocated
> > in rtc_devic
On Tue, Jan 03, 2017 at 09:31:18PM +, Russell King - ARM Linux wrote:
> On Tue, Jan 03, 2017 at 01:18:29PM -0800, Kees Cook wrote:
> > On Mon, Jan 2, 2017 at 6:06 AM, Russell King - ARM Linux
> > wrote:
> > > On Mon, Dec 26, 2016 at 05:01:02PM +0530, Bhumika Goyal
On Tue, Jan 03, 2017 at 01:18:29PM -0800, Kees Cook wrote:
> On Mon, Jan 2, 2017 at 6:06 AM, Russell King - ARM Linux
> wrote:
> > On Mon, Dec 26, 2016 at 05:01:02PM +0530, Bhumika Goyal wrote:
> >> The object armada38x_rtc_ops of type rtc_class_ops structure is not
> &
On Mon, Dec 26, 2016 at 05:01:02PM +0530, Bhumika Goyal wrote:
> The object armada38x_rtc_ops of type rtc_class_ops structure is not
> modified after getting initialized by armada38x_rtc_probe. Apart from
> getting referenced in init it is also passed as an argument to the function
> devm_rtc_devic
On Thu, Dec 08, 2016 at 06:10:10PM +0100, Gregory CLEMENT wrote:
> The drivers are supposed to be portable, however there are few assumption
> done here about the unsigned long size. Make sure we use the accurate
> width for the variable.
>
> Signed-off-by: Gregory CLEMENT
> ---
> drivers/rtc/rt
On Thu, Dec 08, 2016 at 06:10:09PM +0100, Gregory CLEMENT wrote:
> It is one more step to remove the deprecated functions rtc_time_to_tm
> and rtc_tm_to_time.
I fail to see any advantage to this patch, or in fact the y2038 patch
merged into rtc.
Let's first look at the original rtc_time_to_tm():
On Thu, Dec 08, 2016 at 06:10:08PM +0100, Gregory CLEMENT wrote:
> From: Shaker Daibes
>
> According to FE-3124064:
> The device supports CPU write and read access to the RTC time register.
> However, due to this errata, read from RTC TIME register may fail.
>
> Workaround:
> General configurati
23 matches
Mail list logo
