Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp3947524ybc; Tue, 26 Nov 2019 01:05:42 -0800 (PST) X-Google-Smtp-Source: APXvYqym3Shc+1V1ZJ13Mxtxxo3iXv3K+9CMpYK9b0vbQjrfp0bVU+ObkTOzMv+WmPRy6IXL8HZq X-Received: by 2002:a17:907:2054:: with SMTP id pg20mr1312399ejb.194.1574759141927; Tue, 26 Nov 2019 01:05:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574759141; cv=none; d=google.com; s=arc-20160816; b=e9EKwxY5+vR59JIRr3seqg0KCTjIMWFGfpRr7MnRrrF9wd6dnQxCV4UAtHM5KIPv2T MOzBNbvHL98X+OIIGY3aFOxPXlBemMrD29gZIyFwUbGVDKJV/sCPqGfqcuImOovDM66+ Uy22mVOlzk+hBCfKi2Dn+V9LqMi2LnY0oxhS3JaAnxyHMfVFmHWTbEkYQetnwMnl88t0 /fkCxazcMsA7O0tMdSZlOCwr+A69ZR5Ps4j8Zxm82DnuFw0MDdo1rqAk7LNpI9vy1RIr uCno5DimtPpbpCDUE5KT4w+V0wGCP9L/IsMbgjtZb0daigdB0QbMQPKnR5h5ktHLg66S yLtA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=t3siywQMic4+3G/dPDeE17s5VtxexJ2M1JK1S3ouM4A=; b=VPYXyKGtAFcU1UeeCYojJ8aK7Hswx49vnUcI2c93orprJywspOSuxppvqlttVohg2+ 4gMno894v5D0MNeao03mTdb4eRZOCE/eI3D5969219IBjHSVYZYtkM+KJ3l6FVGjKIky nHEjgnQHmy1ba9T9VICuY3JoXPVttBBbdiAm6uu8ActTeIsbOSJL73KdWKaf0LscQESr snSh004pzx45M7NwaPpdBo87odpSP//q4CYE1kQHvTVc4qLcURoKNFAO+WgX8/D42miB lZgp+aVjP7nxpDc1QeXLNlpUBzyMUIPnC9fSbN/0DpM6smGeNSS9z4fGLbIfXcub584+ FHEA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@antmicro.com header.s=google header.b="ZjtgOV/p"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h52si7772134edb.77.2019.11.26.01.05.18; Tue, 26 Nov 2019 01:05:41 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@antmicro.com header.s=google header.b="ZjtgOV/p"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727379AbfKZJCc (ORCPT + 99 others); Tue, 26 Nov 2019 04:02:32 -0500 Received: from mail-il1-f193.google.com ([209.85.166.193]:38089 "EHLO mail-il1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727028AbfKZJCb (ORCPT ); Tue, 26 Nov 2019 04:02:31 -0500 Received: by mail-il1-f193.google.com with SMTP id u17so16942012ilq.5 for ; Tue, 26 Nov 2019 01:02:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=antmicro.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=t3siywQMic4+3G/dPDeE17s5VtxexJ2M1JK1S3ouM4A=; b=ZjtgOV/pr8z2qVPm7aKOTj8vneLya3QFAGjk+lNJj/QRunSEptXSIUv964TfpaXgRB F3OKkiaNaSAD62pS0zHb9Avv1FbKH8LTbkug33+fFZwVSPcIVSdPG2OaYPJFu6GUkPs5 HoFCyAmD5YbmF23GK7W1JsY6CkqiKro/Yg565+jxX4ce1wygC+VMaUuGF6dJtlaxI4Ym sNzF1zkjllRTjDM+OqPE2rH++4EddtYqGSSZV4suxjs7Ed8/0bKxHOkaSpDWp3HMBmY5 SkPvXeknRMoR9EGxWpz6IMr/+rKYOyJpDqQC4eL5FSrnbZKGvVFqx9l0IZDWAjuVtzsh 3xLg== 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:content-transfer-encoding; bh=t3siywQMic4+3G/dPDeE17s5VtxexJ2M1JK1S3ouM4A=; b=MFrBgapIPj/GyqgFX7O76QnycwUUnn7UAdqYxeagOealIru/yYUFBBFGq9V5HeaxxE igfiyg28xO5L8aI5Q3pHuAuDFRMdkMpgIGKERW4vYodQnup/wbxP/FkzjvXhRMNVKjC1 EAsC4w97ttgJMtvLDCSmGaJopRZef6rxJIWzAFi11g0miM+Tzyba4mbZPIQLSrI65zfy aZYKiog0ZJPGIcrwqSJlWc6DLR7bvd2zyEDYQW99SHkoqXWoehtgZkF1+ktjqLKDS4w4 VWwg5sA8pFeA52UalqyJVdgV4pMwaQYSxx0uWRB9tio4R887PIFCxzx5fmWh6QHhutBT tfmw== X-Gm-Message-State: APjAAAUdH+PvrMkw66bdxjhIZW72xTj+Ewu+1bOUXZ6Pi4qqmb2mfd3l Nxd1ANuX3FEpoFmx/Kk62PAO10oXPwWgx90OF8wfsQ== X-Received: by 2002:a05:6e02:4d2:: with SMTP id f18mr37130431ils.270.1574758949256; Tue, 26 Nov 2019 01:02:29 -0800 (PST) MIME-Version: 1.0 References: <20191023114634.13657-0-mholenko@antmicro.com> <20191023114634.13657-2-mholenko@antmicro.com> <20191120192648.GA3087498@kroah.com> In-Reply-To: <20191120192648.GA3087498@kroah.com> From: Mateusz Holenko Date: Tue, 26 Nov 2019 10:02:18 +0100 Message-ID: Subject: Re: [PATCH v2 2/4] litex: add common LiteX header To: Greg Kroah-Hartman Cc: Rob Herring , Mark Rutland , Jiri Slaby , devicetree@vger.kernel.org, "open list:SERIAL DRIVERS" , Stafford Horne , Karol Gugala , Mauro Carvalho Chehab , "David S. Miller" , "Paul E. McKenney" , Filip Kokosinski , Joel Stanley , Jonathan Cameron , Maxime Ripard , Shawn Guo , Heiko Stuebner , Sam Ravnborg , Icenowy Zheng , Laurent Pinchart , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org =C5=9Br., 20 lis 2019 o 20:26 Greg Kroah-Hartman napisa=C5=82(a): > > On Wed, Oct 23, 2019 at 11:47:04AM +0200, Mateusz Holenko wrote: > > +#ifdef __LITTLE_ENDIAN > > +# define LITEX_READ_REG(addr) ioread32(addr) > > +# define LITEX_READ_REG_OFF(addr, off) ioread32(addr + off) > > +# define LITEX_WRITE_REG(val, addr) iowrite32(val, addr) > > +# define LITEX_WRITE_REG_OFF(val, addr, off) iowrite32(val, addr + o= ff) > > +#else > > +# define LITEX_READ_REG(addr) ioread32be(addr) > > +# define LITEX_READ_REG_OFF(addr, off) ioread32be(addr + off) > > +# define LITEX_WRITE_REG(val, addr) iowrite32be(val, addr) > > +# define LITEX_WRITE_REG_OFF(val, addr, off) iowrite32be(val, addr += off) > > +#endif > > I just noticed this. > > Ick, this is not good. You will run into problems in the future with > this, I can guarantee it. What about systems where the CPU is one > endian and the hardware in the other? It will happen trust us. As mentioned in the previous comment, LiteX CSRs are guaranteed to be always little-endian - this includes configurations with both big-endian and little-endian CPUs. The aim of including the ifdef section was exactly to target situation where endianness is different for CPU and devices. As such this approach *should* work. > Make these real functions (inline is nice) and pass in the pointer to > the device so you can test for it and call the correct function based on > the cpu/hardware type. > > And what about bitfields? What endian are they for your > system/hardware? > > Almost no kernel code should EVER be testing __LITTLE_ENDIAN, don't add > to it as it is not a good idea. If I understand correctly, you suggest to replace compile-time ifdefing with probing the endianness in the runtime (by reading some register that should return a known value, say 1, and testing how bits are arranged). This is a good idea, as it protects against breaking an always-little-endian property of LiteX CSRs in the future. I'll include this in the next version of the patchset. > thanks, > > greg k-h Thanks for your comments! --=20 Mateusz Holenko Antmicro Ltd | www.antmicro.com Roosevelta 22, 60-829 Poznan, Poland