From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754230AbcBEPLL (ORCPT ); Fri, 5 Feb 2016 10:11:11 -0500 Received: from mout.kundenserver.de ([217.72.192.75]:58257 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751076AbcBEPLI (ORCPT ); Fri, 5 Feb 2016 10:11:08 -0500 From: Arnd Bergmann To: Zubair Lutfullah Kakakhel Cc: Aleksey Makarov , tj@kernel.org, hdegoede@redhat.com, david.daney@cavium.com, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org Subject: Re: [PATCH v7] SATA: OCTEON: support SATA on OCTEON platform Date: Fri, 05 Feb 2016 16:10:40 +0100 Message-ID: <4427989.vm6oM7UICv@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <56B376CE.9010600@imgtec.com> References: <1454520915-27948-1-git-send-email-Zubair.Kakakhel@imgtec.com> <56B342FF.1090709@caviumnetworks.com> <56B376CE.9010600@imgtec.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:eDsTjmS9xsVGylJQzdQt07wgcRauYzYOdlPEHXp1wXnrMS2Ps3a EsxeEm1Rtw7qdaq5YA0ejqEEYcrevFhcMa3yW5IgP6hgJ8CE9Ju3qmggC2uC6zfKgSGrfxH R8wN7HKKjzV3/1glUAbLnoc7fgQlkYj+mKEIG+R8xjf1k7RhiCcuPxoNmBcC71FaILrrRx1 KOh9r9Qt8+BfrfJi85pJQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:rNJN1nH6/Po=:bBjw1lg/vKV+dzGtDx47lx JuV6olg42sLRel9fPUnrkQffklltiq8uCjWq8Um20Z2V4CezPs/QyaaMEU8lxbCFFgsO6j+yA SbeYIkhO2X1ao5OYpasVYSTSqNMeETh52sB16iX1V/uT4jA36fUs6gy3RhWzEq3NKFnMeVYj9 J8NPmytb3nrLMWxZ2usiV/6Cg2ZJlzglcuZKerQNpVuC1IzekXi/Rb1Pbnly2IFR1s29IgCak SZJTnjbDLTdGd0kaimoS1v7gV8Phm8GWtw+LfjUoc4elIATi99QyX4wJfyUakHCqY9ZGYdHHU sDIJXkofAUppORSXG+NbuHlMupAcBVpqvkjQFac9/AkpwdrBiFd7e8uil9KPcvFv9GH8NxgsY Fvb5RcXC8NkuQqBfS46u/qzB+AASCpX6LJfBnTu1vNqB6VSqB9+MkDbGmuMw6/uA5ofhE5t0j r7yxN8CM4tREkJBANz6adtHxHgsnWAjuvOgwFscoh2O/8RCEstKIgiRjYacSPMSYecjadpbVQ z0kqxKLqMGwbtq8GVwlm/G3jcqYboCnrBnsqGBGZ68bvvI7dv4dS983oJunpmh+RK89fUwXvA sqS2rq4YnD55osl29IttSTpgFwxbnF/WBkywFd+gEWoDPm2K9EQYwIHiwJEgesW1rTrTqd+sL SQMKLi8ZDQhyLIwkC2YXuSoN8UR5byhmtTST5gdLtSKL7RLLDBUOYRNNdm8LPaZooMFDXViBc R9otdjAHD7NkMVaE Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 04 February 2016 16:05:34 Zubair Lutfullah Kakakhel wrote: > Thank-you for the review. > > On 04/02/16 12:24, Aleksey Makarov wrote: > > > > Hi Zubair, > > > >> + void __iomem *base; > > > > [..] > > > >> + cfg = cvmx_read_csr((uint64_t)base + CVMX_SATA_UCTL_SHIM_CFG); > > > > sparse will complain here. See Documentation/sparse.txt > > Yes. sparse says > > ... > CHECK drivers/ata/sata_octeon.c > drivers/ata/sata_octeon.c:50:30: warning: cast removes address space of expression > drivers/ata/sata_octeon.c:65:25: warning: cast removes address space of expression > ... > > Use of (__force uint64_t) removes the sparse warning. But it was > frowned upon by arnd. > > He suggested a wrapper helper in asm/octeon/cvmx.h which handles iomem > addresses and __force behind the scenes rather than in the driver. Obviously I was not suggesting to remove the __force without fixing the address space mismatch first. > static inline void cvmx_write_csr_resource(void __iomem *csr_addr, uint64_t val) > { > cvmx_write_csr((__force uint64_t)csr_addr, val) > } > > Alternatives? Or should I resend with the above wrapper? Maybe just name it cvmx_writeq()? This is close enough to the normal writeq, except it does not serialize against DMA or spinlocks as writeq does, and it assumes that the device is the same endianess as the CPU, whereas writeq assumes that devices are fixed-endian. Arnd