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 08B08C43217 for ; Sat, 23 Apr 2022 23:33:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234407AbiDWXgr (ORCPT ); Sat, 23 Apr 2022 19:36:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34892 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231690AbiDWXgq (ORCPT ); Sat, 23 Apr 2022 19:36:46 -0400 Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id AF34A16FAFE; Sat, 23 Apr 2022 16:33:46 -0700 (PDT) Received: by angie.orcam.me.uk (Postfix, from userid 500) id AD45492009C; Sun, 24 Apr 2022 01:33:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 9D31992009B; Sun, 24 Apr 2022 00:33:44 +0100 (BST) Date: Sun, 24 Apr 2022 00:33:44 +0100 (BST) From: "Maciej W. Rozycki" To: Thomas Bogendoerfer cc: "Jason A. Donenfeld" , LKML , Linux Crypto Mailing List , Thomas Gleixner , Arnd Bergmann , Theodore Ts'o , Dominik Brodowski , Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Paul Walmsley , Palmer Dabbelt , Albert Ou , "David S . Miller" , Richard Weinberger , Anton Ivanov , Johannes Berg , Ingo Molnar , Borislav Petkov , Dave Hansen , "H . Peter Anvin" , Chris Zankel , Max Filippov , John Stultz , Stephen Boyd , Dinh Nguyen , linux-arm-kernel , linux-m68k , "open list:BROADCOM NVRAM DRIVER" , linux-riscv , sparclinux@vger.kernel.org, linux-um@lists.infradead.org, X86 ML , linux-xtensa@linux-xtensa.org Subject: Re: [PATCH v4 04/11] mips: use fallback for random_get_entropy() instead of zero In-Reply-To: <20220418071005.GA4075@alpha.franken.de> Message-ID: References: <20220413115411.21489-1-Jason@zx2c4.com> <20220413115411.21489-5-Jason@zx2c4.com> <20220413122546.GA11860@alpha.franken.de> <20220418071005.GA4075@alpha.franken.de> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Mon, 18 Apr 2022, Thomas Bogendoerfer wrote: > > Also the systems I have in mind and that lack a counter in the chipset > > actually can make use of the buggy CP0 timer, because it's only when CP0 > > timer interrupts are used that the erratum matters, but they use a DS1287 > > RTC interrupt instead unconditionally as the clock event (see the comment > > at the bottom of arch/mips/dec/time.c). But this has not been factored in > > with `can_use_mips_counter' (should it just check for `mips_hpt_frequency' > > being zero perhaps, meaning the timer interrupt not being used?). > > > > Thomas, do you happen to know if any of the SGI systems that we support > > had buggy early R4k chips? > > IP22 has probably seen all buggy MIPS chips produced, so yes I even own > Indy/Indigo2 CPU boards with early R4k chips. Do they actually use the CP0 timer as a clock event device? Do they have an alternative high-precision timer available? In the course of verifying this change I have noticed my DECstation 5000/260, which has a high-precision timer in the chipset available as a clock source device, does register the CP0 timer as a clock source device regardless. Upon a closer inspection I have noticed that the CP0 timer interrupt is non-functional in this machine, which I have then confirmed as a valid CPU hardware configuration via the TimIntDis/TimerIntDis (the R4k CPU manual is inconsistent in naming here) boot-mode bit. It allows IP7 to be used as an external interrupt source instead. I used not to be aware of the presence of this boot-mode bit. I find this arrangement odd, because IP7 used to be wired internally as the FPU interrupt with the 5000/240's CPU module, so it's not usable as an external interrupt anyway with this system's mainboard. That means however that this machine (and possibly the 5000/150 as well, but I'll have to verify that once I get at the KN04 CPU module I have in a drawer at my other place) can use the CP0 timer as a clock source device unconditionally. I think this discovery asks for code optimisation, which I'll try to cook up sometime. I don't expect the IP22 to have a similar arrangement with the CP0 timer interrupt given that the CPU was an in-house design at SGI, but who knows? Do you? Maciej 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 E6C84C433EF for ; Sat, 23 Apr 2022 23:34:23 +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:MIME-Version:References:Message-ID: In-Reply-To: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=z//4svl72BgE4bpulZOVog6PSr5qgfMqIPcr3lTt45E=; b=uWYjPEmsGJaqBJ 5RHWGU5/Z2nT9NaXeQGsctpiL3PXluHHnkudWUtfePxbj1NwIJvLJ6ytgABx2vmJdBiizBkYwa265 yLzBhFlbar41R2LYhNfkJOpeK67zSI1B8mVoAreJwcRsUxiMT9qbuyBglEXbucITd7oDoIx3T/lpw GiTO7GIMl3RO2/0J/JAhntoBtp8F2wDu8nio4g1ayZ1aEdgg7gPTCfayoyAzXfEeHhS7uRafgK4rS a9tho4rnymqh8GHako+XkwhX+aGCqsnQco0uLBlczi2fkZt7duPtt+he4XHfkw2tjUcF9gA7xvdG/ Y0w72da/wuelFJVS770w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1niPGQ-005J9c-8V; Sat, 23 Apr 2022 23:34:06 +0000 Received: from angie.orcam.me.uk ([2001:4190:8020::34]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1niPGD-005J4U-VB; Sat, 23 Apr 2022 23:33:55 +0000 Received: by angie.orcam.me.uk (Postfix, from userid 500) id AD45492009C; Sun, 24 Apr 2022 01:33:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 9D31992009B; Sun, 24 Apr 2022 00:33:44 +0100 (BST) Date: Sun, 24 Apr 2022 00:33:44 +0100 (BST) From: "Maciej W. Rozycki" To: Thomas Bogendoerfer cc: "Jason A. Donenfeld" , LKML , Linux Crypto Mailing List , Thomas Gleixner , Arnd Bergmann , Theodore Ts'o , Dominik Brodowski , Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Paul Walmsley , Palmer Dabbelt , Albert Ou , "David S . Miller" , Richard Weinberger , Anton Ivanov , Johannes Berg , Ingo Molnar , Borislav Petkov , Dave Hansen , "H . Peter Anvin" , Chris Zankel , Max Filippov , John Stultz , Stephen Boyd , Dinh Nguyen , linux-arm-kernel , linux-m68k , "open list:BROADCOM NVRAM DRIVER" , linux-riscv , sparclinux@vger.kernel.org, linux-um@lists.infradead.org, X86 ML , linux-xtensa@linux-xtensa.org Subject: Re: [PATCH v4 04/11] mips: use fallback for random_get_entropy() instead of zero In-Reply-To: <20220418071005.GA4075@alpha.franken.de> Message-ID: References: <20220413115411.21489-1-Jason@zx2c4.com> <20220413115411.21489-5-Jason@zx2c4.com> <20220413122546.GA11860@alpha.franken.de> <20220418071005.GA4075@alpha.franken.de> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220423_163354_212759_28EAC165 X-CRM114-Status: GOOD ( 21.57 ) X-BeenThere: linux-riscv@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="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Mon, 18 Apr 2022, Thomas Bogendoerfer wrote: > > Also the systems I have in mind and that lack a counter in the chipset > > actually can make use of the buggy CP0 timer, because it's only when CP0 > > timer interrupts are used that the erratum matters, but they use a DS1287 > > RTC interrupt instead unconditionally as the clock event (see the comment > > at the bottom of arch/mips/dec/time.c). But this has not been factored in > > with `can_use_mips_counter' (should it just check for `mips_hpt_frequency' > > being zero perhaps, meaning the timer interrupt not being used?). > > > > Thomas, do you happen to know if any of the SGI systems that we support > > had buggy early R4k chips? > > IP22 has probably seen all buggy MIPS chips produced, so yes I even own > Indy/Indigo2 CPU boards with early R4k chips. Do they actually use the CP0 timer as a clock event device? Do they have an alternative high-precision timer available? In the course of verifying this change I have noticed my DECstation 5000/260, which has a high-precision timer in the chipset available as a clock source device, does register the CP0 timer as a clock source device regardless. Upon a closer inspection I have noticed that the CP0 timer interrupt is non-functional in this machine, which I have then confirmed as a valid CPU hardware configuration via the TimIntDis/TimerIntDis (the R4k CPU manual is inconsistent in naming here) boot-mode bit. It allows IP7 to be used as an external interrupt source instead. I used not to be aware of the presence of this boot-mode bit. I find this arrangement odd, because IP7 used to be wired internally as the FPU interrupt with the 5000/240's CPU module, so it's not usable as an external interrupt anyway with this system's mainboard. That means however that this machine (and possibly the 5000/150 as well, but I'll have to verify that once I get at the KN04 CPU module I have in a drawer at my other place) can use the CP0 timer as a clock source device unconditionally. I think this discovery asks for code optimisation, which I'll try to cook up sometime. I don't expect the IP22 to have a similar arrangement with the CP0 timer interrupt given that the CPU was an in-house design at SGI, but who knows? Do you? Maciej _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv 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 0945DC433F5 for ; Sat, 23 Apr 2022 23:35:15 +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:MIME-Version:References:Message-ID: In-Reply-To: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=L1SSnNSwLZpYIICff1Gcbrb1dZ+du8G+OgVJnrb3XeU=; b=pjtd8jPWG+bCad rkT13NH/XtYPnAKk8b5uahHDV6vzVTZDSWNqF6suMnUUqFR9cKT0NS4DsGC8WPl4pj7zMP21rBwY4 YQkxflAcUSlbvXLCbumNjsxCBdvh4DqWSl+ctqEreD2TeamRKEYRWwJYczW9iGerP9PFvnE6m7/m5 WKPzNFj8lrfWu6NVnHMc24YO6EhyfIH317axMPK1erM2FK9pWP4hkK6EI5XSmJsYlfDZQcTrx/JzL JJdNhR6jilEm8ErYmSy8ak/Q+/XNEHzqKxiNYawzbNBvUXESxQSQ+DagpXHiQOQp39W+9QdYCQHWN xuARfuS37AUsWonSOjLA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1niPGI-005J6k-1s; Sat, 23 Apr 2022 23:33:58 +0000 Received: from angie.orcam.me.uk ([2001:4190:8020::34]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1niPGD-005J4U-VB; Sat, 23 Apr 2022 23:33:55 +0000 Received: by angie.orcam.me.uk (Postfix, from userid 500) id AD45492009C; Sun, 24 Apr 2022 01:33:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 9D31992009B; Sun, 24 Apr 2022 00:33:44 +0100 (BST) Date: Sun, 24 Apr 2022 00:33:44 +0100 (BST) From: "Maciej W. Rozycki" To: Thomas Bogendoerfer cc: "Jason A. Donenfeld" , LKML , Linux Crypto Mailing List , Thomas Gleixner , Arnd Bergmann , Theodore Ts'o , Dominik Brodowski , Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Paul Walmsley , Palmer Dabbelt , Albert Ou , "David S . Miller" , Richard Weinberger , Anton Ivanov , Johannes Berg , Ingo Molnar , Borislav Petkov , Dave Hansen , "H . Peter Anvin" , Chris Zankel , Max Filippov , John Stultz , Stephen Boyd , Dinh Nguyen , linux-arm-kernel , linux-m68k , "open list:BROADCOM NVRAM DRIVER" , linux-riscv , sparclinux@vger.kernel.org, linux-um@lists.infradead.org, X86 ML , linux-xtensa@linux-xtensa.org Subject: Re: [PATCH v4 04/11] mips: use fallback for random_get_entropy() instead of zero In-Reply-To: <20220418071005.GA4075@alpha.franken.de> Message-ID: References: <20220413115411.21489-1-Jason@zx2c4.com> <20220413115411.21489-5-Jason@zx2c4.com> <20220413122546.GA11860@alpha.franken.de> <20220418071005.GA4075@alpha.franken.de> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220423_163354_212759_28EAC165 X-CRM114-Status: GOOD ( 21.57 ) 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="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, 18 Apr 2022, Thomas Bogendoerfer wrote: > > Also the systems I have in mind and that lack a counter in the chipset > > actually can make use of the buggy CP0 timer, because it's only when CP0 > > timer interrupts are used that the erratum matters, but they use a DS1287 > > RTC interrupt instead unconditionally as the clock event (see the comment > > at the bottom of arch/mips/dec/time.c). But this has not been factored in > > with `can_use_mips_counter' (should it just check for `mips_hpt_frequency' > > being zero perhaps, meaning the timer interrupt not being used?). > > > > Thomas, do you happen to know if any of the SGI systems that we support > > had buggy early R4k chips? > > IP22 has probably seen all buggy MIPS chips produced, so yes I even own > Indy/Indigo2 CPU boards with early R4k chips. Do they actually use the CP0 timer as a clock event device? Do they have an alternative high-precision timer available? In the course of verifying this change I have noticed my DECstation 5000/260, which has a high-precision timer in the chipset available as a clock source device, does register the CP0 timer as a clock source device regardless. Upon a closer inspection I have noticed that the CP0 timer interrupt is non-functional in this machine, which I have then confirmed as a valid CPU hardware configuration via the TimIntDis/TimerIntDis (the R4k CPU manual is inconsistent in naming here) boot-mode bit. It allows IP7 to be used as an external interrupt source instead. I used not to be aware of the presence of this boot-mode bit. I find this arrangement odd, because IP7 used to be wired internally as the FPU interrupt with the 5000/240's CPU module, so it's not usable as an external interrupt anyway with this system's mainboard. That means however that this machine (and possibly the 5000/150 as well, but I'll have to verify that once I get at the KN04 CPU module I have in a drawer at my other place) can use the CP0 timer as a clock source device unconditionally. I think this discovery asks for code optimisation, which I'll try to cook up sometime. I don't expect the IP22 to have a similar arrangement with the CP0 timer interrupt given that the CPU was an in-house design at SGI, but who knows? Do you? Maciej _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel