Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759973AbdCVQLl (ORCPT ); Wed, 22 Mar 2017 12:11:41 -0400 Received: from mx0a-00010702.pphosted.com ([148.163.156.75]:43873 "EHLO mx0b-00010702.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1758611AbdCVQLc (ORCPT ); Wed, 22 Mar 2017 12:11:32 -0400 Date: Wed, 22 Mar 2017 11:11:16 -0500 From: Julia Cartwright To: William Breathitt Gray CC: Linus Walleij , Alexandre Courbot , , , Subject: Re: [PATCH v2 7/9] gpio: 104-idi-48: make use of raw_spinlock variants Message-ID: <20170322161116.GI10423@jcartwri.amer.corp.natinst.com> References: <20170322124414.GA22323@sophia> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20170322124414.GA22323@sophia> User-Agent: Mutt/1.8.0 (2017-02-23) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-22_13:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703220141 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-22_13:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=30 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=30 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703220141 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1206 Lines: 28 On Wed, Mar 22, 2017 at 08:44:14AM -0400, William Breathitt Gray wrote: > On Tue, Mar 21, 2017 at 05:43:07PM -0500, Julia Cartwright wrote: > >The 104-idi-48 gpio driver currently implements an irq_chip for handling > >interrupts; due to how irq_chip handling is done, it's necessary for the > >irq_chip methods to be invoked from hardirq context, even on a a > >real-time kernel. Because the spinlock_t type becomes a "sleeping" > >spinlock w/ RT kernels, it is not suitable to be used with irq_chips. > > > >A quick audit of the operations under the lock reveal that they do only > >minimal, bounded work, and are therefore safe to do under a raw spinlock. > > > >Signed-off-by: Julia Cartwright > > Hi Julia, > > This driver also uses a second spinlock_t, called ack_lock, to prevent > reentrance into the idi_48_irq_handler function. Should ack_lock also be > implemented as a raw_spinlock_t? I saw this lock, and I don't even understand it's purpose. However, I think I convinced myself that it's harmless. Why? It's only ever acquired in a handler registered with request_irq(), which, on RT, is invoked in a context which can sleep. Thanks for taking a closer look! Julia