Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752475AbcDRQVz (ORCPT ); Mon, 18 Apr 2016 12:21:55 -0400 Received: from down.free-electrons.com ([37.187.137.238]:55453 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751481AbcDRQVy (ORCPT ); Mon, 18 Apr 2016 12:21:54 -0400 Date: Mon, 18 Apr 2016 18:21:51 +0200 From: Alexandre Belloni To: Qianyu Gong Cc: "akinobu.mita@gmail.com" , Mingkai Hu , "rtc-linux@googlegroups.com" , "linux-kernel@vger.kernel.org" Subject: Re: rtc ds3232 call trace in kernel Message-ID: <20160418162151.GR25196@piout.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1439 Lines: 40 On 18/04/2016 at 06:15:40 +0000, Qianyu Gong wrote : > Hi Akinobu, > > I got an rtc call trace when booting 4.6 kernel on our board and I found it > was caused by this patch: > > commit fc1dcb0b39dbb10d3290f2fcd6e154670f699166 > Author: Akinobu Mita > Date: Mon Mar 7 00:27:53 2016 +0900 > > rtc: ds3232: use rtc->ops_lock to protect alarm operations > > ds3232->mutex is used to protect for alarm operations which > need to access status and control registers. > > But we can use rtc->ops_lock instead. rtc->ops_lock is held when most > of rtc_class_ops methods are called, so we only need to explicitly > acquire it from irq handler in order to protect form concurrent > accesses. > > Signed-off-by: Akinobu Mita > Signed-off-by: Alexandre Belloni > The problem is that rtc->ops_lock would be accessed in ds3232_irq() > without being initialized as rtc_device_register() is called too late. > > As I'm not familiar with rtc things, could I just revert the patch or you already > have a solution to this problem? Thanks in advance. > > Well, many RTC drivers actually suffer from that. I'm planning to change the infrastructure to handle this case better. Meanwhile, this is worth fixing. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com