From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from layka.disroot.org (layka.disroot.org [178.21.23.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 871AF23E325 for ; Fri, 15 May 2026 19:47:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=178.21.23.139 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778874476; cv=none; b=perGQCbmOZyVzAUgnP0PxhqtGRiQfq7lqMlD7zjDnc7cJnUkveA9g9CoRwC2xDl/TEwxzi8Pv3KT34Cb0uRooAfcnEKcsLPzf47xs/93kWykYqJr03m+XY7A3UD8vf2SxeIvJpK9j4Qbgnq9t/l+Xe1T1toDIgNsVj92m+qyUNY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778874476; c=relaxed/simple; bh=irOph9m8I+C8UggSn9QrWD5Z7zwtopnkqKQBjjoJw48=; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:Content-Type; b=OwCK6m1HG1w7xWHS9nTuYMWT+PL0+lSzTT2HZe0WDjLO0ZflTjAbyEHj5kQ8f2qUqPbVLP1q4bTQOfL1rFfGfYAtYj6ishrc8eSU94JdJAe+77HUUAb9aMFdtXFBzvB8lA041JpQqqzi2ldcSUqfknw4TdqdnVlxxq+Jicjt8tQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=disroot.org; spf=pass smtp.mailfrom=disroot.org; dkim=pass (2048-bit key) header.d=disroot.org header.i=@disroot.org header.b=axGYBffu; arc=none smtp.client-ip=178.21.23.139 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=disroot.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=disroot.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=disroot.org header.i=@disroot.org header.b="axGYBffu" Received: from mail01.disroot.lan (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id 1FFA125F0B; Fri, 15 May 2026 21:47:44 +0200 (CEST) X-Virus-Scanned: SPAM Filter at disroot.org Received: from layka.disroot.org ([127.0.0.1]) by localhost (disroot.org [127.0.0.1]) (amavis, port 10024) with ESMTP id WhmNiCG5A4Bg; Fri, 15 May 2026 21:47:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1778874463; bh=irOph9m8I+C8UggSn9QrWD5Z7zwtopnkqKQBjjoJw48=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=axGYBffunzuXCrK76xqMnX4M2iXQPQ4vWCLKcDJwkCC3BbuJgKjG3lt8QId3LH64A +/9jmQGFHZ2xmCd+EZx+8t0l/Gp/9WAIMjk3jq6ELtvBwAmkvwUE5xno05K0GF09EP MSskGNB7rCcLSsUIylGJBKtqYBvDV9jH0OuHBYAhQk5xB4weEJAi7y0BUgcG4VK6ru sztljipnoWpESCFoWG0u/1g2Kf/cQaHS8oHLfih+0z7g8yjIE58ZVFheg5nCOvh+6b DBisWamOtA+yiuWiWnVx6WDsp8ovWuYjlXA/XfiQxa0/qozOCw8kWQcApzw5Rmv3id 6jnGIOgblZs5g== Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Date: Fri, 15 May 2026 19:47:43 +0000 From: Rustam Adilov To: markus.stockhausen@gmx.de Cc: 'Chris Packham' , 'Daniel Lezcano' , 'Thomas Gleixner' , linux-kernel@vger.kernel.org Subject: Re: AW: AW: AW: [PATCH] clocksource: rtl-otto: Change driver to use __raw reads and writes In-Reply-To: <016d01dce49a$36b7bd60$a4273820$@gmx.de> References: <20260511131520.98420-1-adilov@disroot.org> <4536f1b3a66411a36ca0d01538003fd4@disroot.org> <021301dce3e3$4a530b70$def92250$@gmx.de> <007b01dce48e$dbebb9a0$93c32ce0$@gmx.de> <1282957d0625682218b277f0f92f5d7f@disroot.org> <016d01dce49a$36b7bd60$a4273820$@gmx.de> Message-ID: X-Sender: adilov@disroot.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On 2026-05-15 18:39, markus.stockhausen@gmx.de wrote: >> Von: Rustam Adilov >> Gesendet: Freitag, 15. Mai 2026 20:21 >> An: markus.stockhausen@gmx.de >> Betreff: Re: AW: AW: [PATCH] clocksource: rtl-otto: Change driver to use > __raw reads and writes >> >> On 2026-05-15 17:18, markus.stockhausen@gmx.de wrote: >> >> Von: Rustam Adilov >> >> Gesendet: Freitag, 15. Mai 2026 16:33 >> >> An: markus.stockhausen@gmx.de >> >> Betreff: Re: AW: [PATCH] clocksource: rtl-otto: Change driver to use > __raw >> > reads and writes >> >> ... >> >> > IIRC the current functions use memory barriers while the >> >> > new ones do not. Timers are critical and cost me a lot >> >> > of time in the past [1]. We nearly lost support for several >> >> > devices last year. So I like to have at least some stability >> >> > confirmation from downstream. >> >> >> >> As far as i can see, if you untangle the the BUILDIO_MEM(l, u32) in [1] >> >> you should see they do have barriers as denoted by barrier argument > being >> > set. >> >> So that means, in MIPS, both readl/writel are the same as their __raw >> > variants. >> >> And both ioread32/iowrite32 are using readl/writel under the hood so... >> > >> > Hi, >> > >> > will the __relaxed functions serve your IO_SWAP scenario too? >> > >> > Markus >> >> Not really because the readl_relaxed and readl appear to be both mapped to > ioswabl >> which changes behavior as per IO_SWAP config [1]. > > My two cents regarding the real issue behind this discussion. > I'm still convinced that CONFIG_SWAP_IO_SPACE is not the > right way to get an USB driver working. Rewriting every other > driver around that just feels wrong. I mean, it is either this or hacking up the general usb reads and writes functions with this atrociousness: static inline unsigned int ehci_readl(const struct ehci_hcd *ehci, __u32 __iomem *regs) { +#if defined(CONFIG_RTK_MIPS_SOC) + return (le32_to_cpu((*(volatile unsigned long *)(regs)))); +#else #ifdef CONFIG_USB_EHCI_BIG_ENDIAN_MMIO return ehci_big_endian_mmio(ehci) ? readl_be(regs) : @@ -746,6 +749,7 @@ #else return readl(regs); #endif +#endif } static inline void ehci_writel(const struct ehci_hcd *ehci, const unsigned int val, __u32 __iomem *regs) { +#if defined(CONFIG_RTK_MIPS_SOC) + ((*(volatile unsigned long *)(regs))=cpu_to_le32(val)); +#else #ifdef CONFIG_USB_EHCI_BIG_ENDIAN_MMIO ehci_big_endian_mmio(ehci) ? writel_be(val, regs) : @@ -773,6 +780,7 @@ else writel(val, regs); #endif +#endif } And i don't think anyone upstream is gonna be okay with it. Obviously that's straight from Realtek code and we can slightly improve it but the underlying issue is still gonna be there. With all that, I believe CONFIG_SWAP_IO_SPACE is a good long term solution to this endian mess and multiple big endian MIPS SoCs use it too like Lantiq and Broadcom. The happy side effect is rewriting existing drivers, which i'll call as a good thing personally. > Coming back to this. If it produces the same assembler code > for the big endian Realtek Otto platform then I'm ok with this. > I expect an immediate downstream backport if it gets > accepted upstream. > > Markus Best, Rustam