From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 16EF345945; Mon, 4 Mar 2024 15:04:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709564674; cv=none; b=MyarseT0/NJWJ8Es/f4QhcWN2W3sptd667CvDPvHRXq7IruECMXRP3PMwBnssMFwlpilQ+wzaqQPg4Jts185f5SucGkgytyIVqt1ii62g/CmFdN5HG7JEM5dywpx0qA9/+/vYfzfJKmaIW3sEBapWM3k2lGxVmFARpC6514VQrw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709564674; c=relaxed/simple; bh=JQ0+zqW2caSPP+fUJhGdRNpSWxMzAFd26SsP97GqJ5M=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=mR1moOY0oYBeeXjlCVW+u9KRBSycn/7+bQijEVwIhHWLa+IUE5JlTSFIrgDS+1dIrxcdorg9hzfeS91qWVWusT++M+T1dhAlmO8KJ6SXBTjj5DNMY8Miagx25mE91Asv3/uW444ZYMSAiB5WV7YLku6uBA1lI6IbVoZSdx++HBA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KxfxPZyT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KxfxPZyT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6DC42C433F1; Mon, 4 Mar 2024 15:04:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709564673; bh=JQ0+zqW2caSPP+fUJhGdRNpSWxMzAFd26SsP97GqJ5M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KxfxPZyTJCmJ5mZxVgiJqCzXofUHAoQs7mRC4KDObSN4wZYzCp+or22QBaGGe5t9d pLbvJc3JLMFgeoU1w44VMTP8tAduMKv6D3daCt6OZvQd6ZtM5E/Z97noo5A7eDc0s2 W+ig+U1dUuuB06z3B0xWfblUl4Qt+mYQ4jEyGRB7YwL+af8wnuI87t37LKaJhjrGoW ub8JQUD6sglgIwv+HwJS9neFZqPR7gHY6wjCaYatMgn1yMmWuoNgu/qGBQDEDJSnwJ 1Wcb5mT3qEHKZKholtNHLHRLkFh6GvNDPtCqpZMBtwoYo84wi/8B185vMWK2kovBNR BuM6Fu1YvISvg== Date: Mon, 4 Mar 2024 20:34:17 +0530 From: Manivannan Sadhasivam To: Niklas Cassel Cc: Manivannan Sadhasivam , Jingoo Han , Gustavo Pimentel , Lorenzo Pieralisi , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Rob Herring , Bjorn Helgaas , Marek Vasut , Yoshihiro Shimoda , Thierry Reding , Jonathan Hunter , Kishon Vijay Abraham I , Vidya Sagar , Vignesh Raghavendra , Richard Zhu , Lucas Stach , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Minghuan Lian , Mingkai Hu , Roy Zang , Kunihiko Hayashi , Masami Hiramatsu , Kishon Vijay Abraham I , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-tegra@vger.kernel.org, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v8 03/10] PCI: dwc: ep: Introduce dw_pcie_ep_cleanup() API for drivers supporting PERST# Message-ID: <20240304150417.GK2647@thinkpad> References: <20240224-pci-dbi-rework-v8-0-64c7fd0cfe64@linaro.org> <20240224-pci-dbi-rework-v8-3-64c7fd0cfe64@linaro.org> <20240304081713.GH2647@thinkpad> Precedence: bulk X-Mailing-List: linux-arm-msm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, Mar 04, 2024 at 11:51:04AM +0100, Niklas Cassel wrote: > On Mon, Mar 04, 2024 at 01:47:13PM +0530, Manivannan Sadhasivam wrote: > > On Thu, Feb 29, 2024 at 01:40:29PM +0100, Niklas Cassel wrote: > > > On Sat, Feb 24, 2024 at 12:24:09PM +0530, Manivannan Sadhasivam wrote: > > > > > > Since e.g. qcom-ep.c does a reset_control_assert() during perst > > > assert/deassert, which should clear sticky registers, I think that > > > you should let dw_pcie_ep_cleanup() clean up the BARs using > > > dw_pcie_ep_clear_bar(). > > > > > > > As I mentioned earlier, it is the job of the EPF drivers to clear the BARs since > > they allocate them. I'm trying to reduce the implicit resetting wherever we > > could. > > > > The proper fix is to add the LINK_DOWN callback to EPF drivers and do cleanup. > > I'm planning to submit a series for that after this one. > > Currently, pci-epf-test allocates memory for the BARs in .bind(). > Likewise it frees the memory for the BARs in .unbind(). > > AFAICT, most iATU registers, and most BAR registers are sticky registers, > so they will not get reset on link down. > (The currently selected BAR size, in case of Resizable BAR is an exception.) > > That means that even on link down, we do not need to free the memory, > or change the iATU settings. (This applies to all drivers.) > > > > However, on PERST (for the drivers call dw_pcie_ep_cleanup()), they call > reset_control_assert(), so they will clear sticky registers, which means > that they need to at least re-write the iATU and BAR registers. > (I guess they could free + allocate the memory for the BARs again, > but I don't think that is strictly necessary.) > That is why I suggested that you call dw_pcie_ep_clear_bar() from > dw_pcie_ep_cleanup(). > Sorry, I keep assuming the flow w.r.t PERST# supported platforms :/ My bad! > > > If you free the memory for the BARs in link_down() (this callback exists > for many drivers, even drivers without a PERST handler), where are you > supposted to alloc the memory for the BARs again? > > Allocating them at link_up() is too late (because as soon as the link is > up, the host is allowed to enumerate the EP BARs.) The proper place is to > allocate them when receiving PERST, but not all drivers have a PERST handler. > > (My understanding is that 1) PERST assert 2) PERST deassert 3) link is up.) > > > > unbind() undos what was done in bind(), so shouldn't link_down() undo what was > done in link_up()? With that logic, if you move the alloc to .core_init(), > should we perhaps have a .core_deinit() callback for EPF drivers? > (I guess only drivers which perform a reset during PERST would call this.) > > But considering that free+alloc is not strictly needed, why not just keep > the allocation + free in .bind()/.unbind() ? > (To avoid the need to create a .core_deinit()), and let dw_pcie_ep_cleanup() > call dw_pcie_ep_clear_bar() ? > > I guess my point is that it seems a bit pointless for drivers that do not > clear sticky registers to free+alloc memory on link down, for no good > reason. (Memory might get fragmented over time, so it might not be possible > to perform a big allocation after the device has been running for a really > long time.) > > > > So I'm thinking that we either > 1) Keep the alloc/free in bind/unbind, and let dw_pcie_ep_cleanup() call > dw_pcie_ep_clear_bar(), > or > 2) Introduce a .deinit_core() callback which will free the BARs. > (Because I don't see how you will (re-)allocate memory for all drivers > if you free the memory in link_down().) > I think option 2 is the better solution. In my view, calling dw_pcie_ep_clear_bar() from EPC drivers is a layering violation since the allocation happens from EPF drivers. So clearing the BARs during the deinit() callback that gets called when PERST# assert happens is the way to go. - Mani -- மணிவண்ணன் சதாசிவம் 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 03825C5478C for ; Mon, 4 Mar 2024 15:05:20 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=KxfxPZyT; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4TpMSb2NX1z3vYV for ; Tue, 5 Mar 2024 02:05:19 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=KxfxPZyT; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=145.40.73.55; helo=sin.source.kernel.org; envelope-from=mani@kernel.org; receiver=lists.ozlabs.org) Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4TpMRn1xRWz3bs2 for ; Tue, 5 Mar 2024 02:04:37 +1100 (AEDT) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 532F1CE1387; Mon, 4 Mar 2024 15:04:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6DC42C433F1; Mon, 4 Mar 2024 15:04:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709564673; bh=JQ0+zqW2caSPP+fUJhGdRNpSWxMzAFd26SsP97GqJ5M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KxfxPZyTJCmJ5mZxVgiJqCzXofUHAoQs7mRC4KDObSN4wZYzCp+or22QBaGGe5t9d pLbvJc3JLMFgeoU1w44VMTP8tAduMKv6D3daCt6OZvQd6ZtM5E/Z97noo5A7eDc0s2 W+ig+U1dUuuB06z3B0xWfblUl4Qt+mYQ4jEyGRB7YwL+af8wnuI87t37LKaJhjrGoW ub8JQUD6sglgIwv+HwJS9neFZqPR7gHY6wjCaYatMgn1yMmWuoNgu/qGBQDEDJSnwJ 1Wcb5mT3qEHKZKholtNHLHRLkFh6GvNDPtCqpZMBtwoYo84wi/8B185vMWK2kovBNR BuM6Fu1YvISvg== Date: Mon, 4 Mar 2024 20:34:17 +0530 From: Manivannan Sadhasivam To: Niklas Cassel Subject: Re: [PATCH v8 03/10] PCI: dwc: ep: Introduce dw_pcie_ep_cleanup() API for drivers supporting PERST# Message-ID: <20240304150417.GK2647@thinkpad> References: <20240224-pci-dbi-rework-v8-0-64c7fd0cfe64@linaro.org> <20240224-pci-dbi-rework-v8-3-64c7fd0cfe64@linaro.org> <20240304081713.GH2647@thinkpad> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Vignesh Raghavendra , Kunihiko Hayashi , linux-pci@vger.kernel.org, Lorenzo Pieralisi , Minghuan Lian , Thierry Reding , Manivannan Sadhasivam , Kishon Vijay Abraham I , Fabio Estevam , Marek Vasut , Kishon Vijay Abraham I , Rob Herring , linux-tegra@vger.kernel.org, Jonathan Hunter , NXP Linux Team , Richard Zhu , linux-arm-msm@vger.kernel.org, Sascha Hauer , linuxppc-dev@lists.ozlabs.org, Bjorn Helgaas , linux-omap@vger.kernel.org, Mingkai Hu , linux-arm-kernel@lists.infradead.org, Roy Zang , Jingoo Han , Yo shihiro Shimoda , linux-kernel@vger.kernel.org, Vidya Sagar , linux-renesas-soc@vger.kernel.org, Masami Hiramatsu , Pengutronix Kernel Team , Gustavo Pimentel , Shawn Guo , Lucas Stach Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Mon, Mar 04, 2024 at 11:51:04AM +0100, Niklas Cassel wrote: > On Mon, Mar 04, 2024 at 01:47:13PM +0530, Manivannan Sadhasivam wrote: > > On Thu, Feb 29, 2024 at 01:40:29PM +0100, Niklas Cassel wrote: > > > On Sat, Feb 24, 2024 at 12:24:09PM +0530, Manivannan Sadhasivam wrote: > > > > > > Since e.g. qcom-ep.c does a reset_control_assert() during perst > > > assert/deassert, which should clear sticky registers, I think that > > > you should let dw_pcie_ep_cleanup() clean up the BARs using > > > dw_pcie_ep_clear_bar(). > > > > > > > As I mentioned earlier, it is the job of the EPF drivers to clear the BARs since > > they allocate them. I'm trying to reduce the implicit resetting wherever we > > could. > > > > The proper fix is to add the LINK_DOWN callback to EPF drivers and do cleanup. > > I'm planning to submit a series for that after this one. > > Currently, pci-epf-test allocates memory for the BARs in .bind(). > Likewise it frees the memory for the BARs in .unbind(). > > AFAICT, most iATU registers, and most BAR registers are sticky registers, > so they will not get reset on link down. > (The currently selected BAR size, in case of Resizable BAR is an exception.) > > That means that even on link down, we do not need to free the memory, > or change the iATU settings. (This applies to all drivers.) > > > > However, on PERST (for the drivers call dw_pcie_ep_cleanup()), they call > reset_control_assert(), so they will clear sticky registers, which means > that they need to at least re-write the iATU and BAR registers. > (I guess they could free + allocate the memory for the BARs again, > but I don't think that is strictly necessary.) > That is why I suggested that you call dw_pcie_ep_clear_bar() from > dw_pcie_ep_cleanup(). > Sorry, I keep assuming the flow w.r.t PERST# supported platforms :/ My bad! > > > If you free the memory for the BARs in link_down() (this callback exists > for many drivers, even drivers without a PERST handler), where are you > supposted to alloc the memory for the BARs again? > > Allocating them at link_up() is too late (because as soon as the link is > up, the host is allowed to enumerate the EP BARs.) The proper place is to > allocate them when receiving PERST, but not all drivers have a PERST handler. > > (My understanding is that 1) PERST assert 2) PERST deassert 3) link is up.) > > > > unbind() undos what was done in bind(), so shouldn't link_down() undo what was > done in link_up()? With that logic, if you move the alloc to .core_init(), > should we perhaps have a .core_deinit() callback for EPF drivers? > (I guess only drivers which perform a reset during PERST would call this.) > > But considering that free+alloc is not strictly needed, why not just keep > the allocation + free in .bind()/.unbind() ? > (To avoid the need to create a .core_deinit()), and let dw_pcie_ep_cleanup() > call dw_pcie_ep_clear_bar() ? > > I guess my point is that it seems a bit pointless for drivers that do not > clear sticky registers to free+alloc memory on link down, for no good > reason. (Memory might get fragmented over time, so it might not be possible > to perform a big allocation after the device has been running for a really > long time.) > > > > So I'm thinking that we either > 1) Keep the alloc/free in bind/unbind, and let dw_pcie_ep_cleanup() call > dw_pcie_ep_clear_bar(), > or > 2) Introduce a .deinit_core() callback which will free the BARs. > (Because I don't see how you will (re-)allocate memory for all drivers > if you free the memory in link_down().) > I think option 2 is the better solution. In my view, calling dw_pcie_ep_clear_bar() from EPC drivers is a layering violation since the allocation happens from EPF drivers. So clearing the BARs during the deinit() callback that gets called when PERST# assert happens is the way to go. - Mani -- மணிவண்ணன் சதாசிவம் 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A6CE0C48BF6 for ; Mon, 4 Mar 2024 15:04:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=jHSIOOiUaR08L4WBp+hBgjwBqz5k4gLP2Ae4Nhr5LTY=; b=SX9uwD1hdiq6se Pl3B6oGdLtebVd0QtcZUbJHsmYXDu02KYstox23TWzKSWk6GhW5+mhoUEf2r301rDS0StSBALkVxA oUHfY+Yp6xOl492GstTrdSH5MEP7iv6u9lT8S4D8Ol919WmZWi+NKGIG7oU7eNw6YajPhKts/b6mq fql48M2NzgHzAgLFzL8QfZacshhfM506UkhxNXUS9Kp3qFBHN+3fOvQiWE4Ovw7rcx9/OId8tDQ+N BFE1fm/g4P5m6l2KTaA8qPzhZlOVzoeIOy47n27WCQxR1JCoJblq2DrpZGmMDfbSIc1w0aQnsmMN8 c9mqcMQ4JMmfEsO1Xp2A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rh9rq-00000009TSk-3p93; Mon, 04 Mar 2024 15:04:38 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rh9ro-00000009TS2-2cX9 for linux-arm-kernel@lists.infradead.org; Mon, 04 Mar 2024 15:04:38 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 532F1CE1387; Mon, 4 Mar 2024 15:04:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6DC42C433F1; Mon, 4 Mar 2024 15:04:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709564673; bh=JQ0+zqW2caSPP+fUJhGdRNpSWxMzAFd26SsP97GqJ5M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KxfxPZyTJCmJ5mZxVgiJqCzXofUHAoQs7mRC4KDObSN4wZYzCp+or22QBaGGe5t9d pLbvJc3JLMFgeoU1w44VMTP8tAduMKv6D3daCt6OZvQd6ZtM5E/Z97noo5A7eDc0s2 W+ig+U1dUuuB06z3B0xWfblUl4Qt+mYQ4jEyGRB7YwL+af8wnuI87t37LKaJhjrGoW ub8JQUD6sglgIwv+HwJS9neFZqPR7gHY6wjCaYatMgn1yMmWuoNgu/qGBQDEDJSnwJ 1Wcb5mT3qEHKZKholtNHLHRLkFh6GvNDPtCqpZMBtwoYo84wi/8B185vMWK2kovBNR BuM6Fu1YvISvg== Date: Mon, 4 Mar 2024 20:34:17 +0530 From: Manivannan Sadhasivam To: Niklas Cassel Cc: Manivannan Sadhasivam , Jingoo Han , Gustavo Pimentel , Lorenzo Pieralisi , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Rob Herring , Bjorn Helgaas , Marek Vasut , Yoshihiro Shimoda , Thierry Reding , Jonathan Hunter , Kishon Vijay Abraham I , Vidya Sagar , Vignesh Raghavendra , Richard Zhu , Lucas Stach , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Minghuan Lian , Mingkai Hu , Roy Zang , Kunihiko Hayashi , Masami Hiramatsu , Kishon Vijay Abraham I , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-tegra@vger.kernel.org, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v8 03/10] PCI: dwc: ep: Introduce dw_pcie_ep_cleanup() API for drivers supporting PERST# Message-ID: <20240304150417.GK2647@thinkpad> References: <20240224-pci-dbi-rework-v8-0-64c7fd0cfe64@linaro.org> <20240224-pci-dbi-rework-v8-3-64c7fd0cfe64@linaro.org> <20240304081713.GH2647@thinkpad> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240304_070437_039979_3C8BFA3F X-CRM114-Status: GOOD ( 37.09 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gTW9uLCBNYXIgMDQsIDIwMjQgYXQgMTE6NTE6MDRBTSArMDEwMCwgTmlrbGFzIENhc3NlbCB3 cm90ZToKPiBPbiBNb24sIE1hciAwNCwgMjAyNCBhdCAwMTo0NzoxM1BNICswNTMwLCBNYW5pdmFu bmFuIFNhZGhhc2l2YW0gd3JvdGU6Cj4gPiBPbiBUaHUsIEZlYiAyOSwgMjAyNCBhdCAwMTo0MDoy OVBNICswMTAwLCBOaWtsYXMgQ2Fzc2VsIHdyb3RlOgo+ID4gPiBPbiBTYXQsIEZlYiAyNCwgMjAy NCBhdCAxMjoyNDowOVBNICswNTMwLCBNYW5pdmFubmFuIFNhZGhhc2l2YW0gd3JvdGU6Cj4gPiA+ IAo+ID4gPiBTaW5jZSBlLmcuIHFjb20tZXAuYyBkb2VzIGEgcmVzZXRfY29udHJvbF9hc3NlcnQo KSBkdXJpbmcgcGVyc3QKPiA+ID4gYXNzZXJ0L2RlYXNzZXJ0LCB3aGljaCBzaG91bGQgY2xlYXIg c3RpY2t5IHJlZ2lzdGVycywgSSB0aGluayB0aGF0Cj4gPiA+IHlvdSBzaG91bGQgbGV0IGR3X3Bj aWVfZXBfY2xlYW51cCgpIGNsZWFuIHVwIHRoZSBCQVJzIHVzaW5nCj4gPiA+IGR3X3BjaWVfZXBf Y2xlYXJfYmFyKCkuCj4gPiA+IAo+ID4gCj4gPiBBcyBJIG1lbnRpb25lZCBlYXJsaWVyLCBpdCBp cyB0aGUgam9iIG9mIHRoZSBFUEYgZHJpdmVycyB0byBjbGVhciB0aGUgQkFScyBzaW5jZQo+ID4g dGhleSBhbGxvY2F0ZSB0aGVtLiBJJ20gdHJ5aW5nIHRvIHJlZHVjZSB0aGUgaW1wbGljaXQgcmVz ZXR0aW5nIHdoZXJldmVyIHdlCj4gPiBjb3VsZC4KPiA+IAo+ID4gVGhlIHByb3BlciBmaXggaXMg dG8gYWRkIHRoZSBMSU5LX0RPV04gY2FsbGJhY2sgdG8gRVBGIGRyaXZlcnMgYW5kIGRvIGNsZWFu dXAuCj4gPiBJJ20gcGxhbm5pbmcgdG8gc3VibWl0IGEgc2VyaWVzIGZvciB0aGF0IGFmdGVyIHRo aXMgb25lLgo+IAo+IEN1cnJlbnRseSwgcGNpLWVwZi10ZXN0IGFsbG9jYXRlcyBtZW1vcnkgZm9y IHRoZSBCQVJzIGluIC5iaW5kKCkuCj4gTGlrZXdpc2UgaXQgZnJlZXMgdGhlIG1lbW9yeSBmb3Ig dGhlIEJBUnMgaW4gLnVuYmluZCgpLgo+IAo+IEFGQUlDVCwgbW9zdCBpQVRVIHJlZ2lzdGVycywg YW5kIG1vc3QgQkFSIHJlZ2lzdGVycyBhcmUgc3RpY2t5IHJlZ2lzdGVycywKPiBzbyB0aGV5IHdp bGwgbm90IGdldCByZXNldCBvbiBsaW5rIGRvd24uCj4gKFRoZSBjdXJyZW50bHkgc2VsZWN0ZWQg QkFSIHNpemUsIGluIGNhc2Ugb2YgUmVzaXphYmxlIEJBUiBpcyBhbiBleGNlcHRpb24uKQo+IAo+ IFRoYXQgbWVhbnMgdGhhdCBldmVuIG9uIGxpbmsgZG93biwgd2UgZG8gbm90IG5lZWQgdG8gZnJl ZSB0aGUgbWVtb3J5LAo+IG9yIGNoYW5nZSB0aGUgaUFUVSBzZXR0aW5ncy4gKFRoaXMgYXBwbGll cyB0byBhbGwgZHJpdmVycy4pCj4gCj4gCj4gCj4gSG93ZXZlciwgb24gUEVSU1QgKGZvciB0aGUg ZHJpdmVycyBjYWxsIGR3X3BjaWVfZXBfY2xlYW51cCgpKSwgdGhleSBjYWxsCj4gcmVzZXRfY29u dHJvbF9hc3NlcnQoKSwgc28gdGhleSB3aWxsIGNsZWFyIHN0aWNreSByZWdpc3RlcnMsIHdoaWNo IG1lYW5zCj4gdGhhdCB0aGV5IG5lZWQgdG8gYXQgbGVhc3QgcmUtd3JpdGUgdGhlIGlBVFUgYW5k IEJBUiByZWdpc3RlcnMuCj4gKEkgZ3Vlc3MgdGhleSBjb3VsZCBmcmVlICsgYWxsb2NhdGUgdGhl IG1lbW9yeSBmb3IgdGhlIEJBUnMgYWdhaW4sCj4gYnV0IEkgZG9uJ3QgdGhpbmsgdGhhdCBpcyBz dHJpY3RseSBuZWNlc3NhcnkuKQo+IFRoYXQgaXMgd2h5IEkgc3VnZ2VzdGVkIHRoYXQgeW91IGNh bGwgZHdfcGNpZV9lcF9jbGVhcl9iYXIoKSBmcm9tCj4gZHdfcGNpZV9lcF9jbGVhbnVwKCkuCj4g CgpTb3JyeSwgSSBrZWVwIGFzc3VtaW5nIHRoZSBmbG93IHcuci50IFBFUlNUIyBzdXBwb3J0ZWQg cGxhdGZvcm1zIDovCgpNeSBiYWQhCgo+IAo+IAo+IElmIHlvdSBmcmVlIHRoZSBtZW1vcnkgZm9y IHRoZSBCQVJzIGluIGxpbmtfZG93bigpICh0aGlzIGNhbGxiYWNrIGV4aXN0cwo+IGZvciBtYW55 IGRyaXZlcnMsIGV2ZW4gZHJpdmVycyB3aXRob3V0IGEgUEVSU1QgaGFuZGxlciksIHdoZXJlIGFy ZSB5b3UKPiBzdXBwb3N0ZWQgdG8gYWxsb2MgdGhlIG1lbW9yeSBmb3IgdGhlIEJBUnMgYWdhaW4/ Cj4gCj4gQWxsb2NhdGluZyB0aGVtIGF0IGxpbmtfdXAoKSBpcyB0b28gbGF0ZSAoYmVjYXVzZSBh cyBzb29uIGFzIHRoZSBsaW5rIGlzCj4gdXAsIHRoZSBob3N0IGlzIGFsbG93ZWQgdG8gZW51bWVy YXRlIHRoZSBFUCBCQVJzLikgVGhlIHByb3BlciBwbGFjZSBpcyB0bwo+IGFsbG9jYXRlIHRoZW0g d2hlbiByZWNlaXZpbmcgUEVSU1QsIGJ1dCBub3QgYWxsIGRyaXZlcnMgaGF2ZSBhIFBFUlNUIGhh bmRsZXIuCj4gCj4gKE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCAxKSBQRVJTVCBhc3NlcnQgMikg UEVSU1QgZGVhc3NlcnQgMykgbGluayBpcyB1cC4pCj4gCj4gCj4gCj4gdW5iaW5kKCkgdW5kb3Mg d2hhdCB3YXMgZG9uZSBpbiBiaW5kKCksIHNvIHNob3VsZG4ndCBsaW5rX2Rvd24oKSB1bmRvIHdo YXQgd2FzCj4gZG9uZSBpbiBsaW5rX3VwKCk/IFdpdGggdGhhdCBsb2dpYywgaWYgeW91IG1vdmUg dGhlIGFsbG9jIHRvIC5jb3JlX2luaXQoKSwKPiBzaG91bGQgd2UgcGVyaGFwcyBoYXZlIGEgLmNv cmVfZGVpbml0KCkgY2FsbGJhY2sgZm9yIEVQRiBkcml2ZXJzPwo+IChJIGd1ZXNzIG9ubHkgZHJp dmVycyB3aGljaCBwZXJmb3JtIGEgcmVzZXQgZHVyaW5nIFBFUlNUIHdvdWxkIGNhbGwgdGhpcy4p Cj4gCj4gQnV0IGNvbnNpZGVyaW5nIHRoYXQgZnJlZSthbGxvYyBpcyBub3Qgc3RyaWN0bHkgbmVl ZGVkLCB3aHkgbm90IGp1c3Qga2VlcAo+IHRoZSBhbGxvY2F0aW9uICsgZnJlZSBpbiAuYmluZCgp Ly51bmJpbmQoKSA/Cj4gKFRvIGF2b2lkIHRoZSBuZWVkIHRvIGNyZWF0ZSBhIC5jb3JlX2RlaW5p dCgpKSwgYW5kIGxldCBkd19wY2llX2VwX2NsZWFudXAoKQo+IGNhbGwgZHdfcGNpZV9lcF9jbGVh cl9iYXIoKSA/Cj4gCj4gSSBndWVzcyBteSBwb2ludCBpcyB0aGF0IGl0IHNlZW1zIGEgYml0IHBv aW50bGVzcyBmb3IgZHJpdmVycyB0aGF0IGRvIG5vdAo+IGNsZWFyIHN0aWNreSByZWdpc3RlcnMg dG8gZnJlZSthbGxvYyBtZW1vcnkgb24gbGluayBkb3duLCBmb3Igbm8gZ29vZAo+IHJlYXNvbi4g KE1lbW9yeSBtaWdodCBnZXQgZnJhZ21lbnRlZCBvdmVyIHRpbWUsIHNvIGl0IG1pZ2h0IG5vdCBi ZSBwb3NzaWJsZQo+IHRvIHBlcmZvcm0gYSBiaWcgYWxsb2NhdGlvbiBhZnRlciB0aGUgZGV2aWNl IGhhcyBiZWVuIHJ1bm5pbmcgZm9yIGEgcmVhbGx5Cj4gbG9uZyB0aW1lLikKPiAKPiAKPiAKPiBT byBJJ20gdGhpbmtpbmcgdGhhdCB3ZSBlaXRoZXIKPiAxKSBLZWVwIHRoZSBhbGxvYy9mcmVlIGlu IGJpbmQvdW5iaW5kLCBhbmQgbGV0IGR3X3BjaWVfZXBfY2xlYW51cCgpIGNhbGwKPiBkd19wY2ll X2VwX2NsZWFyX2JhcigpLAo+IG9yCj4gMikgSW50cm9kdWNlIGEgLmRlaW5pdF9jb3JlKCkgY2Fs bGJhY2sgd2hpY2ggd2lsbCBmcmVlIHRoZSBCQVJzLgo+IChCZWNhdXNlIEkgZG9uJ3Qgc2VlIGhv dyB5b3Ugd2lsbCAocmUtKWFsbG9jYXRlIG1lbW9yeSBmb3IgYWxsIGRyaXZlcnMKPiBpZiB5b3Ug ZnJlZSB0aGUgbWVtb3J5IGluIGxpbmtfZG93bigpLikKPiAKCkkgdGhpbmsgb3B0aW9uIDIgaXMg dGhlIGJldHRlciBzb2x1dGlvbi4gSW4gbXkgdmlldywgY2FsbGluZwpkd19wY2llX2VwX2NsZWFy X2JhcigpIGZyb20gRVBDIGRyaXZlcnMgaXMgYSBsYXllcmluZyB2aW9sYXRpb24gc2luY2UgdGhl CmFsbG9jYXRpb24gaGFwcGVucyBmcm9tIEVQRiBkcml2ZXJzLgoKU28gY2xlYXJpbmcgdGhlIEJB UnMgZHVyaW5nIHRoZSBkZWluaXQoKSBjYWxsYmFjayB0aGF0IGdldHMgY2FsbGVkIHdoZW4gUEVS U1QjCmFzc2VydCBoYXBwZW5zIGlzIHRoZSB3YXkgdG8gZ28uCgotIE1hbmkKCi0tIArgrq7grqPg rr/grrXgrqPgr43grqPgrqngr40g4K6a4K6k4K6+4K6a4K6/4K614K6u4K+NCgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1h aWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xp c3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2VybmVsCg==