From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8C491EB8FAD for ; Wed, 6 Sep 2023 07:58:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232256AbjIFH6s (ORCPT ); Wed, 6 Sep 2023 03:58:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38308 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230070AbjIFH6s (ORCPT ); Wed, 6 Sep 2023 03:58:48 -0400 Received: from muru.com (muru.com [72.249.23.125]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 176F61AB; Wed, 6 Sep 2023 00:58:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 32ACC8050; Wed, 6 Sep 2023 07:58:43 +0000 (UTC) Date: Wed, 6 Sep 2023 10:58:41 +0300 From: Tony Lindgren To: Adam Ford Cc: Linux-OMAP , stable Subject: Re: AM3517 Timer busy regression on 6.1.y branch Message-ID: <20230906075841.GB11676@atomide.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org Hi, * Adam Ford [230905 15:02]: > Tony et al > , > I am trying to run the 6.1.y branch on an AM3517-EVM. > > There are two GPT that throw an error: > > ti-sysc: probe of 48318000.target-module failed with error -16 > ti-sysc: probe of 49032000.target-module failed with error -16 These two timers are in use as clocksource and clockevent reserved by timer-ti-dm-systimer. > I did some minor investigation and found sysc_check_active_timer() is > returning the busy condition. > > I tracked this back a bit further and found that if I revert commit > a12315d6d270 ("bus: ti-sysc: Make omap3 gpt12 quirk handling SoC > specific"), this error condition goes away. > > It almost looks to me like sysc_check_active_timer is defaulting to > -EBUSY when the SoC is not 3430, but the sysc_soc_match[] doesn't > appear to match to AM3517. > > I think the proper solution is to treat the AM35* as 3430. Do you > agree with that approach? > > If so, I'll submit a patch with a fixes tag. I am also wondering how > far back I should mark the fixes tag. Yes am3517 is very similar to 3430. Sounds like the patch would be needed also against the current kernels, right? Regards, Tony