Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758128AbdCUTtn (ORCPT ); Tue, 21 Mar 2017 15:49:43 -0400 Received: from mail-ot0-f179.google.com ([74.125.82.179]:35157 "EHLO mail-ot0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758004AbdCUTti (ORCPT ); Tue, 21 Mar 2017 15:49:38 -0400 MIME-Version: 1.0 In-Reply-To: <67481a9f-f7b5-4ec0-22cc-f6e019dc131e@caviumnetworks.com> References: <20170310132507.32025-1-jglauber@cavium.com> <20170310132507.32025-5-jglauber@cavium.com> <6dc8a2a3-ca79-745a-c716-2188319b9378@caviumnetworks.com> <67481a9f-f7b5-4ec0-22cc-f6e019dc131e@caviumnetworks.com> From: Arnd Bergmann Date: Tue, 21 Mar 2017 20:49:36 +0100 X-Google-Sender-Auth: oyDBwDLp3zV6RdQhXe_TdMrycvU Message-ID: Subject: Re: [PATCH v12 4/9] mmc: cavium: Work-around hardware bug on cn6xxx and cnf7xxx To: David Daney Cc: Ulf Hansson , Jan Glauber , "linux-mmc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Steven J . Hill" , David Daney Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1430 Lines: 38 On Tue, Mar 21, 2017 at 4:19 PM, David Daney wrote: > On 03/21/2017 01:58 AM, Arnd Bergmann wrote: >> >> On Mon, Mar 20, 2017 at 9:45 PM, David Daney >> wrote: >>> >>> On 03/17/2017 07:13 AM, Ulf Hansson wrote: >>>> >>>> My point is really that we should avoid exporting SoC specific APIs >>>> which shall be called from drivers. This is old fashion. >>> >>> >>> >>> Some people find it objectionable to see 1-off architecture specific >>> in-line >>> asm in a driver file, but I agree that putting it as close to the user as >>> possible makes sense. >> >> >> The proper solution might be to create an architecture independent >> interface >> for it, what it is that the function does. Can you explain what the >> purpose >> of locking/unlocking the cache line for MMC is? Is this something that >> could be done more generally in the dma_map_ops implementation? > > > It is a 1-off erratum workaround that is only needed on fewer than five > models/revisions of a mips64 based SoC family. As such, creating a general > purpose, architecture independent, framework is clearly not the proper > approach. If this is just for maintaining coherency of the DMA operation inbetween, then there is already a generic API for that, which the driver calls. Adding the workaround into octeon_dma_map_sg() would be a way to abstract the platform erratum from the driver. Arnd