Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp2272472ybc; Wed, 20 Nov 2019 11:29:05 -0800 (PST) X-Google-Smtp-Source: APXvYqzrEl+mreHUvkH/6Wn5lkWJGEquw53LetysPnsjYqODSlhyGqrSs4EJW0WPmPZc0d/Ccqta X-Received: by 2002:a17:906:12d3:: with SMTP id l19mr7022453ejb.165.1574278145164; Wed, 20 Nov 2019 11:29:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574278145; cv=none; d=google.com; s=arc-20160816; b=QeDBoIjC6mVLSIqWrSPkbg56VRc9AI7hSOJESS6Uwo+iLoOeyB/byswyau+T0GIYsu OHz0cDhi6V6muPq1iL1ZmbnbNPRIoNHbjrv2FF8VLay/g6ADZIBmmrrmVaJxU9b4nmur 0iyJs8GyB7GR4p8U/szorJgpNiaIOMJrNqyqhPiSHxKUrjs6kMI+3llzYMstGoRzB4tU Y+1tVGvI8k2MPrFEI+cNV+SJOkKB7SDCjKkRXfyaZXzP42srOzA24fccbaSS28NjcNi3 mIQRpu3tc7M9q3PTGQvdHIkMgxUv1Dpq3lFGirhNGxteuxDEpYGzj86XHeVCnVpzx830 mI6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=xYMLiHvWOA3BYxzbX8cHJYdby4R7vnO6dKVgxvflcKk=; b=O64RAxn/sqcw5kbbP+cX8w//hq0DGK6eh0TdISV9ofyvZCG7gG4Rz/hO52pwmg/S8m 92E84H/pDIaAMYE36UJQBvnG8aHF5m+RoRKM9+RdFa66agHKfbF3nbJDaqTLah0DRBug zgz1DhRiunlI7r56OS5N2oQgAqUz32zNSqkpRizN82/QtOZfjxq4oIc7qZjGeWkeC2tg /q2FAy38CZwKepPcyyF4Ee4+dH20bGBVJ10KA4ZPkuW/JVtneTGwUJoRQwqOKYYTCCAq A5bJezVhwGMiNu4xFIETuY2KD5v21q12/P+FEZJ9P/l4FV5G6iuuVoNnSYdVEQ+h3avu ZEbw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=qKUolow4; 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 dd5si57732ejb.179.2019.11.20.11.28.39; Wed, 20 Nov 2019 11:29:05 -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=@kernel.org header.s=default header.b=qKUolow4; 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 S1727684AbfKTT0v (ORCPT + 99 others); Wed, 20 Nov 2019 14:26:51 -0500 Received: from mail.kernel.org ([198.145.29.99]:59934 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727582AbfKTT0v (ORCPT ); Wed, 20 Nov 2019 14:26:51 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EF3FC20715; Wed, 20 Nov 2019 19:26:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1574278010; bh=888qcNglt2aTTLwRLbfmkuf5RTUPH/vN/mvNViLPEiU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=qKUolow49rTYCuaqW/HzuQAs4Vg7WSbifWby4JjUoi0Or7N8DDNZkdmk4g9956COv CpjE0MSqZK+GWUnI7iPlhI2DF+XaKdOsDIGdK7+T1+WcFtaiAaAVF0qi87dhpTvrWg dz9CzAS+fK97+U2w6Gn5+TV720gK0+C77qDyjKqk= Date: Wed, 20 Nov 2019 20:26:48 +0100 From: Greg Kroah-Hartman To: Mateusz Holenko Cc: Rob Herring , Mark Rutland , Jiri Slaby , devicetree@vger.kernel.org, linux-serial@vger.kernel.org, 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 Subject: Re: [PATCH v2 2/4] litex: add common LiteX header Message-ID: <20191120192648.GA3087498@kroah.com> References: <20191023114634.13657-0-mholenko@antmicro.com> <20191023114634.13657-2-mholenko@antmicro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191023114634.13657-2-mholenko@antmicro.com> User-Agent: Mutt/1.12.2 (2019-09-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 + off) > +#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. 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. thanks, greg k-h