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;
Date:   Tue, 17 Apr 2018 06:00:40 -0700
From:   'Christoph Hellwig' <hch@infradead.org>
To:     Thomas Gleixner <tglx@linutronix.de>
Cc:     David Wang <davidwang@zhaoxin.com>,
        'Christoph Hellwig' <hch@infradead.org>, mingo@redhat.com,
        hpa@zytor.com, gregkh@linuxfoundation.org, x86@kernel.org,
        linux-kernel@vger.kernel.org, brucechang@via-alliance.com,
        cooperyan@zhaoxin.com, qiyuanwang@zhaoxin.com,
        benjaminpan@viatech.com, lukelin@viacpu.com, timguo@zhaoxin.com
Subject: Re: [PATCH] x86/dma-mapping: override via_no_dac for new VIA PCI
 bridges
Message-ID: <20180417130040.GA9426@infradead.org>
References: <000001d3d628$4e91a4c0$ebb4ee40$@zhaoxin.com>
 <alpine.DEB.2.21.1804171052440.1694@nanos.tec.linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.21.1804171052440.1694@nanos.tec.linutronix.de>
User-Agent: Mutt/1.9.2 (2017-12-15)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Apr 17, 2018 at 10:54:37AM +0200, Thomas Gleixner wrote:
> The question was rather to have a list of PCI IDs for those chipsets which
> have the problem and set the 'disable' flag only for those. That makes a lot
> more sense than making a list of new chips which disable the disable flag.

Agreed.

There are a few other things I'd like to do in this area while we're
at it (I'm happy to do the work, not trying to offload it to David
or Thomas):

 (1) make the nodac flag a per-device flag.  Set for every device
     under one of the affected VIA bridges, or for all PCI devices
     if the nodac command line option is used
 (2) move that flag into the common struct device (or the to be
     designed dma struct hanging off it in the future) and make that
     bit handled in common code as there is a common Xilinx host
     bridge with a 32-bit dma limitation
 (3) kill of the forcesac option, which was a strange performance
     tweak back in plain PCI days, which probably didn't even work
     as expected to start with.