From patchwork Wed Feb 17 16:00:15 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 584208 Return-Path: X-Original-To: incoming-imx@patchwork.ozlabs.org Delivered-To: patchwork-incoming-imx@bilbo.ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id DEB7D14018C for ; Thu, 18 Feb 2016 03:03:16 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1aW4X7-0006VX-4O; Wed, 17 Feb 2016 16:00:53 +0000 Received: from mout.kundenserver.de ([212.227.126.187]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1aW4X1-0006QZ-Dz for linux-arm-kernel@lists.infradead.org; Wed, 17 Feb 2016 16:00:51 +0000 Received: from wuerfel.localnet ([78.42.132.4]) by mrelayeu.kundenserver.de (mreue001) with ESMTPSA (Nemesis) id 0MbXng-1aDRkE41Dw-00Imn2; Wed, 17 Feb 2016 17:00:19 +0100 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 1/7] usb: gadget: pxa25x_udc: move register definitions from arch Date: Wed, 17 Feb 2016 17:00:15 +0100 Message-ID: <16402463.pdHgaqhrJe@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <87oabfgys4.fsf@ti.com> References: <1453997722-3489596-1-git-send-email-arnd@arndb.de> <1453997843-3489728-1-git-send-email-arnd@arndb.de> <87oabfgys4.fsf@ti.com> MIME-Version: 1.0 X-Provags-ID: V03:K0:ze3d0JOhrERIC3VbHZzII6QvV9w6N5OsaCEJnRXB0fMKo1BXyiX G/KQcPVSqQ5NmiyGjT5BY6BUqxi+ADvfQ13PnyvfmGNuMAW109s4F5FpsQmsPTyC7aJn3/N woTpzYZwpbPYpexjRk5oZKo2LDyJyyF3j/y978Co73mlmnQOjbHvkGezZ7jwTO7kDKEuJ1M ztrp5w8ttt+QXgk453wyg== X-UI-Out-Filterresults: notjunk:1; V01:K0:8+69jxevUCU=:hQD6vn9gIhoT388Gzxsg/o FqtjrHckMK0raHXAo6VHlh5ypiRKbnPJp25LdEHmb51hm9kw02KxciZfe5ZnhD1l6WD6xXRXQ KBznFOfv+PYRkCBj+Wk1Y7biwNqnYLSzrLkhYPIXqJgsM1wXa+Puh2FfwQPO72jakrBCy2Qga 3bBmwm0N+MfQuaFucsuiXZAg+e4X36SY3P9aNxXNH/GLA9CamISI9GnUsC0mK1CiW/rfdmTfD N8I6TtSFhD/L8I9HqRbW1jR/LDr4DFCiwtM0fSiJra9RBK+ETirb4MICVhxECFmLg2ZQBB6EG jsYIYd7dApFTlZGwFgqkwC8FzbCsrsMusgz8Wpoc/bYFKGsQPbCDPfY2pYC8gHL311WM085Xv MIAg+EwcYLwFwbX/tdRPtjRshIzFHg8XEWFbdorzlXUjvpKDYuRWc3T/hNElvdy39Qr6eta4B GvZJPbmq0trWuWCgDyWaGccopFFqA+lTJFM67JiJJMvSGaUt2jdICsUy2NJB7nwYBc10bs3nK 1FP00/eG2ZVdKHOHF4/xFaauTTfU/TIj5bb/25aowZdnRF3rtkiOgW5wD9RrQ8CHHZUBEx5du i/sWM1r/OAPsvKRq0SiO/U47TdjnFe66rIlYFkoRCTtuih7nLMmE8PnfS99iWhL7ozHjZtsxX fmnrk4E1T/AGJYDB3T3Evo2HaLv/7rTrhJlPR5h5p/YGNzM2dPlvNUtpoBBThQzHURfxPHBZB TMtPy990E7WSgdTf X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160217_080047_869318_F114477F X-CRM114-Status: GOOD ( 29.67 ) X-Spam-Score: -1.9 (-) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-1.9 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [212.227.126.187 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [212.227.126.187 listed in wl.mailspike.net] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Felipe Balbi , Russell King , Greg Kroah-Hartman , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Haojian Zhuang , Krzysztof Halasa , Felipe Balbi , Imre Kaloz , Robert Jarzmik , Daniel Mack Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org List-Id: linux-imx-kernel.lists.patchwork.ozlabs.org On Wednesday 17 February 2016 17:08:27 Felipe Balbi wrote: > > Hi, > > Arnd Bergmann writes: > > ixp4xx and pxa25x both use this driver and provide a slightly > > different set of register definitions for it. Aside from that, > > the definition in the ixp4xx-regs.h header conflicts with the > > on in the pxa27x device driver when compile-testing that: > > > > In file included from ../drivers/usb/gadget/udc/pxa27x_udc.c:37:0: > > ../drivers/usb/gadget/udc/pxa27x_udc.h:26:0: warning: "UDCCR" redefined > > #define UDCCR 0x0000 /* UDC Control Register */ > > ^ > > In file included from ../arch/arm/mach-ixp4xx/include/mach/hardware.h:27:0, > > from ../arch/arm/mach-ixp4xx/include/mach/io.h:18, > > from ../arch/arm/include/asm/io.h:194, > > from ../include/linux/io.h:25, > > from ../include/linux/irq.h:24, > > from ../drivers/usb/gadget/udc/pxa27x_udc.c:23: > > ../arch/arm/mach-ixp4xx/include/mach/ixp4xx-regs.h:415:0: note: this is the location of the previous definition > > #define UDCCR IXP4XX_USB_REG(IXP4XX_USB_BASE_VIRT+0x0000) > > > > This addresses both issues by moving all the definitions into the > > pxa25x_udc driver itself. It turns out the only difference between > > them was 'UDCCS_IO_ROF', and that could well be a mistake when it > > was incorrectly copied from pxa25x to ixp4xx. > > > > Signed-off-by: Arnd Bergmann > > FYI, this series now sits in my testing/next. If you could just check > that I didn't mess anything up, I'd be glad. > Thank you for merging this and my other patches! After the latest discussion with Krzysztof, I think it would be good to include the patch below, either on top or folded into the last patch of the series (whichever fits your workflow). Arnd 8<---- From 3feea5e42eae444e122f3ad51fef9e08d758fc27 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Wed, 17 Feb 2016 16:51:40 +0100 Subject: [PATCH] usb: gadget: pxa25x_udc: document endianess better MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When I wrote the cleanup patch series, it was not clear how exactly big-endian mode works on ixp4xx, and whether the driver was doing this correctly. After discussing with Krzysztof Hałasa, this has been clarified, so I can update the comment let pxa25x big-endian (which we don't support) work the same way as ixp4xx. Signed-off-by: Arnd Bergmann diff --git a/drivers/usb/gadget/udc/pxa25x_udc.c b/drivers/usb/gadget/udc/pxa25x_udc.c index ca7abdc0eca9..33b7fb84f4fb 100644 --- a/drivers/usb/gadget/udc/pxa25x_udc.c +++ b/drivers/usb/gadget/udc/pxa25x_udc.c @@ -289,14 +289,14 @@ static void pullup_on(void) mach->udc_command(PXA2XX_UDC_CMD_CONNECT); } -#if defined(CONFIG_ARCH_IXP4XX) && defined(CONFIG_CPU_BIG_ENDIAN) +#if defined(CONFIG_CPU_BIG_ENDIAN) /* - * not sure if this is the correct behavior on ixp4xx in both - * bit-endian and little-endian modes, but it's what the driver - * has always done using direct pointer dereferences: - * We assume that there is a byteswap done in hardware at the - * MMIO register that matches what the CPU setting is, so we - * never swap in software. + * IXP4xx has its buses wired up in a way that relies on never doing any + * byte swaps, independent of whether it runs in big-endian or little-endian + * mode, as explained by Krzysztof Hałasa. + * + * We only support pxa25x in little-endian mode, but it is very likely + * that it works the same way. */ static inline void udc_set_reg(struct pxa25x_udc *dev, u32 reg, u32 val) {