From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752919AbdJaLsA (ORCPT <rfc822;w@1wt.eu>);
        Tue, 31 Oct 2017 07:48:00 -0400
Received: from mail-io0-f173.google.com ([209.85.223.173]:52696 "EHLO
        mail-io0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751969AbdJaLr6 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 31 Oct 2017 07:47:58 -0400
X-Google-Smtp-Source: ABhQp+QC5RUlukSme3WmzykcSI7EopimZtMbH2i039bn/i9W6CfDm1IWBKqLR8Tidne9v6bSwZJ5e8LNhph58b5PC5Q=
MIME-Version: 1.0
In-Reply-To: <20171031113718.qoc4jjycq7jehba4@sirena.co.uk>
References: <bf9fd59f32f5c093598d5078d681967626ee9fd0.1509425993.git.baolin.wang@linaro.org>
 <20171031103830.qdtudo2uwsc2ssp3@sirena.co.uk> <CAMz4kuK3C3KOAQ9oUPnV7CWisKLPf5ktP9+a+fmPMLk+ZDkRpA@mail.gmail.com>
 <20171031113718.qoc4jjycq7jehba4@sirena.co.uk>
From: Baolin Wang <baolin.wang@linaro.org>
Date: Tue, 31 Oct 2017 19:47:57 +0800
Message-ID: <CAMz4kuK2WR+Ckb+f0Lt+S2s9rmnf+YQeAP1-bv2huxVpPOB=9w@mail.gmail.com>
Subject: Re: [PATCH 1/2] regmap: Add hardware spinlock support
To: Mark Brown <broonie@kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>, Lee Jones <lee.jones@linaro.org>,
        Arnd Bergmann <arnd@arndb.de>, LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 31 October 2017 at 19:37, Mark Brown <broonie@kernel.org> wrote:
> On Tue, Oct 31, 2017 at 07:31:57PM +0800, Baolin Wang wrote:
>> On 31 October 2017 at 18:38, Mark Brown <broonie@kernel.org> wrote:
>
>> > Given that we have no error handling path on the locks should we be
>> > supporting timeout mode at all?  Otherwise we should probably add a
>> > set of error handling paths whenever we take the lock...
>
>> It will be more helpful to use the timeout to try more times to get
>> the hwlock, and we usually do not use hwspin_trylock_xxx(), so we can
>> remove hwspin_trylock_xxx() support and set timeout as MAX value as
>> default to avoid adding 'hwlock_timeout' config,
>> is this OK for you?
>
> I *think* so - but let's see the code.  It might make sense to do two
> patches, one with the base hwspinlock support then another adding the
> timeout functionality.  That way if there's any problem we can still
> merge the non-timeout code and there's less to review next time.

What I mean is we only introduce the timeout functions, since we do
not want to get the hwlocks failed to avoid error handling path:

static void regmap_lock_hwlock(void *__map)
{
    struct regmap *map = __map;

    hwspin_lock_timeout(map->hwlock, ~0U);
}

static void regmap_lock_hwlock_irq(void *__map)
{
    struct regmap *map = __map;

    hwspin_lock_timeout_irq(map->hwlock, ~0U);
}

static void regmap_lock_hwlock_irqsave(void *__map)
{
    struct regmap *map = __map;

    hwspin_lock_timeout_irqsave(map->hwlock, ~0U, &map->spinlock_flags);
}

-- 
Baolin.wang
Best Regards