From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from metis.whiteo.stw.pengutronix.de (metis.whiteo.stw.pengutronix.de [185.203.201.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F324A1CC88C for ; Tue, 19 Nov 2024 12:51:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.203.201.7 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732020702; cv=none; b=eM6u6CBoAB/U3oIwT3cA0s2K3Tj9bcslUJolAfAGBqwrE1QagDaDELsevQM/Oq8+B+s+5GcE8ijFe1C9W5HEvkbW6wNTKcLoDD2gVoERmek9t2sHXKkp0Vyk24CtyeKXlN64fzQKzQPIVBAMpBKFAFKiHWwdwX4Wx290hnXfLTQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732020702; c=relaxed/simple; bh=8+kO+hmaFU9f3uoEfpMUg23Td4M9jDSb8ePHUvCGZKk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Wp4p4+G2nCyqGPD/Q06o4joolHmRFlk4wUlwUsUz9KcpRSPhJjJYeijnP1gVtopgCWouGD4rxruginx9wnWq1e+uVoy7DcXSEwy22xNKKudpSmfOKnXrtTid6dyMlpoMHXEga/L9AiCLMS2dAQ6XZnjvO2x0Wvnk2otY/5DD0No= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de; spf=pass smtp.mailfrom=pengutronix.de; arc=none smtp.client-ip=185.203.201.7 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pengutronix.de Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tDNhc-0003uq-NH; Tue, 19 Nov 2024 13:51:32 +0100 Received: from pty.whiteo.stw.pengutronix.de ([2a0a:edc0:2:b01:1d::c5]) by drehscheibe.grey.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tDNhc-001ZKn-0G; Tue, 19 Nov 2024 13:51:32 +0100 Received: from mfe by pty.whiteo.stw.pengutronix.de with local (Exim 4.96) (envelope-from ) id 1tDNhb-003KVN-38; Tue, 19 Nov 2024 13:51:31 +0100 Date: Tue, 19 Nov 2024 13:51:31 +0100 From: Marco Felsch To: Sherry Sun Cc: Bough Chen , POPESCU Catalin , Amitkumar Karwar , Neeraj Sanjay Kale , "marcel@holtmann.org" , "luiz.dentz@gmail.com" , "robh@kernel.org" , "krzk+dt@kernel.org" , "conor+dt@kernel.org" , "p.zabel@pengutronix.de" , "linux-bluetooth@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , GEO-CHHER-bsp-development , Krzysztof Kozlowski , Shenwei Wang , Jun Li Subject: Re: [PATCH 1/2] dt-bindings: net: bluetooth: nxp: add support for supply and reset Message-ID: <20241119125131.pb5lkeryldsl7htq@pengutronix.de> References: <1b8864e5-0ec7-49c4-932a-89cfbaeacc9f@leica-geosystems.com> <20241028090028.x6rzopvpcdvgouqv@pengutronix.de> <20241028115150.fgvqaem36lwxwvjh@pengutronix.de> <20241028150048.qnqjxntns6quy7py@pengutronix.de> <20241118221759.wvrkvxeh4iop6jtt@pengutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2 X-SA-Exim-Mail-From: mfe@pengutronix.de X-SA-Exim-Scanned: No (on metis.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org On 24-11-19, Sherry Sun wrote: > > > -----Original Message----- > > From: Marco Felsch > > > > Hi, > > > > gentle ping on this discussion since I'm still convinced that this the correct > > approach to add the reset mechanism and handle the power. > > Hi Marco, > > Sorry for the late reply. After internal discussion, we still have > some confusion regarding this new feature. > This patch do improve the independent handling of wifi/BT, but with > the controlling granularity segmentation, many different wifi/BT use > cases need to be considered. Sure! > For the case -- WLAN (SDIO) not used + BT (UART) used: > > The ideal behavior of BT should be reset and the standalone BT FW > should be re-downloaded when unloading and re-loading the BT driver. To make it clear, I assumed that it's clear that independent (sub-)device handling require independent firmware (fw) files, which can be the case. NXP already supplies independent FW files for bt and wifi. We just need to ensure that the drivers are using these. That said the bt driver already checks if the fw has to be downloaded. > However, due to the regulator control and PDn reset control are bound > to the SDIO bus instead of the WLAN device, the SDIO bus may be ready > after kernel boot up. Right, but this is a separate discussion not belonging to these driver changes. Also it's the common chicken-egg issue. You need to power the bus and release the device-reset before you can check which device is connected and to check if there would be a proper driver. > Although the WLAN is not used(WLAN driver is not loaded and WLAN FW is > not downloaded), the corresponding regulator count and PDn reset count > are both incremented by 1 through MMC pwrseq. Then with the BT driver > remove & re-probe, the PDn reset cannot truly reset the BT chip due to > the count been +1 by MMC pwrseq. So the BT will not reset and BT FW > won't be re-downloaded when re-loading the BT driver, right? You're aware that the btnxpuart.c driver already has the support for an independent software based reset? Not sure what this sw-reset does, due to the lack of missing documentation, but this is the only option to over-come your above mentioned use-case. I have to ask, is this really a use-case for someone? Either your device supports both: WLAN and BT or only one of WLAN/BT. If it would be only BT or WLAN you just don't need the specify the other one within your devicetree. Furthermore, this patchset does not break any current use-case you/NXP has. You still can use the combined fw version and still can use the not so user friendly user-space dependency of: "wlan driver _must_ be loaded" before the "bt driver _can_ be loaded" by just not using the split power handling. For use-space which wants to use the split version because there is no such dependecy. Regards, Marco