Return-path: Received: from smtp.codeaurora.org ([198.145.29.96]:40574 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755600AbcEaHbQ (ORCPT ); Tue, 31 May 2016 03:31:16 -0400 From: Kalle Valo To: Sudip Mukherjee Cc: Stephen Rothwell , QCA ath9k Development , linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org, "netdev\@vger.kernel.org" , Miaoqing Pan Subject: ath9k gpio request References: <20160530132225.4d297678@canb.auug.org.au> <574C4851.9090201@gmail.com> Date: Tue, 31 May 2016 10:31:02 +0300 In-Reply-To: <574C4851.9090201@gmail.com> (Sudip Mukherjee's message of "Mon, 30 May 2016 19:34:01 +0530") Message-ID: <87fusy3cqx.fsf_-_@kamboji.qca.qualcomm.com> (sfid-20160531_093123_203614_D4052D83) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-wireless-owner@vger.kernel.org List-ID: (Changing subject to a more descriptive one, was "Re: linux-next: Tree for May 30") Sudip Mukherjee writes: > Hi All, > I have just built and booted with next-20160530 and my dmesg is full > of warnings from ath9k. Last kernel tested was v4.6 and there was no > problem with that. > > The traces are like: > Call Trace: > [] dump_stack+0x63/0x87 > [] __warn+0xd1/0xf0 > [] warn_slowpath_null+0x1d/0x20 > [] ath9k_hw_gpio_request+0x6f/0x320 [ath9k_hw] > [] ath9k_hw_reset+0xfe4/0x12e0 [ath9k_hw] > [] ath_reset_internal+0x104/0x1f0 [ath9k] > [] ath_reset+0x3d/0x60 [ath9k] > [] ath_chanctx_set_channel+0x1b6/0x300 [ath9k] > [] ath9k_config+0xc6/0x1f0 [ath9k] > [] ? mutex_lock+0x12/0x2f > [] ieee80211_hw_config+0x63/0x350 [mac80211] > [] ieee80211_scan_work+0x161/0x480 [mac80211] > [] process_one_work+0x153/0x3f0 > [] worker_thread+0x12b/0x4b0 > [] ? rescuer_thread+0x340/0x340 > [] kthread+0xc9/0xe0 > [] ret_from_fork+0x1f/0x40 > [] ? kthread_park+0x60/0x60 > ---[ end trace 27eb5094a52869ea ]--- > > Call Trace: > [] dump_stack+0x63/0x87 > [] __warn+0xd1/0xf0 > [] warn_slowpath_null+0x1d/0x20 > [] ath9k_hw_gpio_get+0x1a9/0x1b0 [ath9k_hw] > [] ath9k_rfkill_poll_state+0x34/0x60 [ath9k] > [] ieee80211_rfkill_poll+0x33/0x40 [mac80211] > [] cfg80211_rfkill_poll+0x2a/0xc0 [cfg80211] > [] rfkill_poll+0x24/0x50 > [] process_one_work+0x153/0x3f0 > [] worker_thread+0x12b/0x4b0 > [] ? rescuer_thread+0x340/0x340 > [] kthread+0xc9/0xe0 > [] ret_from_fork+0x1f/0x40 > [] ? kthread_park+0x60/0x60 > ---[ end trace 27eb5094a5286a3d ]--- The traces look incomplete to me, is there anything more before the "Call Trace:" line? Full unedited logs are usually the best. > If it is a known problem then great.. else i can debug and see what > the problem is. There are only few patches added for GPIO, so should > not be a problem to find out what is causing the error. I haven't seen this kind of report before. My first suspect is the commit below so adding Miaoqing. commit b2d70d4944c1789bc64376ad97a811f37e230c87 Author: Miaoqing Pan Date: Mon Mar 7 10:38:15 2016 +0800 ath9k: make GPIO API to support both of WMAC and SOC commit 61b559dea40e ("ath9k: add extra GPIO led support") added ath9k to support access SOC's GPIOs, but implemented in a separated API: ath9k_hw_request_gpio(). So this patch make the APIs more common, to support both of WMAC and SOC GPIOs. The new APIs as below, void ath9k_hw_gpio_request_in(); void ath9k_hw_gpio_request_out(); void ath9k_hw_gpio_free(); NOTE, the BSP of the SOC chips(AR9340, AR9531, AR9550, AR9561) should set the corresponding MUX registers correctly. Signed-off-by: Miaoqing Pan Signed-off-by: Kalle Valo -- Kalle Valo