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 X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B7482C43219 for ; Mon, 29 Apr 2019 08:40:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8F87A20449 for ; Mon, 29 Apr 2019 08:40:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727639AbfD2Ik1 (ORCPT ); Mon, 29 Apr 2019 04:40:27 -0400 Received: from mail-qt1-f196.google.com ([209.85.160.196]:41169 "EHLO mail-qt1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727517AbfD2Ik0 (ORCPT ); Mon, 29 Apr 2019 04:40:26 -0400 Received: by mail-qt1-f196.google.com with SMTP id f25so10978744qtc.8; Mon, 29 Apr 2019 01:40:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=McogBfYDV3Ytu+dV7R32KJwSJJ1XrnJDMfoUioWThxA=; b=YEqJlCUwTpXDC1HAlklzo6VgDk1lcqFK2SC139X4zndZxGAkNe6z15B7Cz9U0d9QMg JmEIu73kI+W84H6ZFCNcJf8I5dZDFZ9wbhChsAXH09iknFRk5cAPI7Gzv25RGvBrd5fe Rz6zSBk5s5XR9rANx0r9MpixGU0hjPYoTiGt1IlSA7VWL6SMgM6sX4iPtMjE9sZ7oWm6 SkA9HMeGS3woQP5TvOr88m7BdbA14bILETpDfTngh433ZXnkx9+4ZototVp2VF5GE+uX rpdlCu2+hw8qK700g+OzadnhSg3IcZtAJHFmkkfiHvh5OEF4WCLQdce7kyS6lim8GEC9 kIOA== X-Gm-Message-State: APjAAAUxZWRyoOvbSyzNmAKqBzc70X+hsq9VvlneVkofaCN2lzxky2ax sE73YJVxpHGyzjcbwjxwsR3BH5P1llkd9oOGp8s= X-Google-Smtp-Source: APXvYqy0qLDMGSSqH3nj57ey+AvszqFYHOFXVVhW2mH427HKjx3QYaKkmXOTcDEDB7WHI65a5MLQSkmkFnWfoqMWqVA= X-Received: by 2002:a0c:89c8:: with SMTP id 8mr8486749qvs.149.1556527225298; Mon, 29 Apr 2019 01:40:25 -0700 (PDT) MIME-Version: 1.0 References: <20190427153222.GA9613@jerusalem> <20190427202150.GB9613@jerusalem> <50f49e95-95f3-4fdb-bcf6-6165382a5168@linux-m68k.org> In-Reply-To: <50f49e95-95f3-4fdb-bcf6-6165382a5168@linux-m68k.org> From: Arnd Bergmann Date: Mon, 29 Apr 2019 10:40:09 +0200 Message-ID: Subject: Re: endianness swapped To: Greg Ungerer Cc: Geert Uytterhoeven , Angelo Dureghello , Logan Gunthorpe , Thomas Gleixner , Kate Stewart , Philippe Ombredanne , Greg KH , "Linux/m68k" , Linux-Arch , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 29, 2019 at 9:04 AM Greg Ungerer wrote: > On 29/4/19 4:44 am, Arnd Bergmann wrote: > > Is there a complete list of coldfire on-chip device drivers? > > > > Looking at some of the drivers: > > > > - drivers/i2c/busses/i2c-imx.c uses only 8-bit accesses and works either way, > > same for drivers/tty/serial/mcf.c > > - drivers/spi/spi-coldfire-qspi.c is apparently coldfire-only and could use > > ioread32be for a portable to do big-endian register access. > > - edma-common has a wrapper to support both big-endian and little-endian > > configurations in the same kernel image, but the mcf interrupt handler > > is hardcoded to the (normally) little-endian ioread32 function. > > - drivers/net/ethernet/freescale/fec_main.c is shared between coldfire > > and i.MX (but not mpc52xx), and is hardcoded to readl/writel, and > > would need the same trick as edma to make it portable. > > That matches up with what we list out in arch/m68k/coldfire/devices.c. > I can't think of any other drivers. Ok > There is a lot of use readl/writel and friends in the architecture > specific code too, in arch/m68k/coldfire. At first I used __raw_readl/ > __raw_writel to always get native endianess. But quote a few uses of > readl/writel have crept in over the years. I generally recommend avoiding the __raw_ accessors altogether except for very special cases (e.g. copying from device memory into main RAM in fixed-size units). On most architectures these days, MMIO registers require additional properties that are provided by readl() but not __raw_readl(), in particular atomicity and ordering against other memory accesses and spinlocks. Presumably m68k is similar to i386 here in that the __raw_ version already provides all those guarantees due to the way the architecture is defined. What tends to work best in cases like this is to have a bus specific wrapper around readl/ioread32/ioread32be that does exactly what is needed for the bus that a device is on. As we concluded earlier, it's easy enough to define coldfire specific ioread32be etc that do what we want here, but it also sounds like it would not be hard to change arch/m68k/coldfire/*.c, drivers/net/ethernet/freescale/fec* and drivers/dma/*edma*.c to use big-endian accessors, and then make coldfire use the generic readl/writel and ioread32be/iowrite32be. Arnd