From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759258AbdACN7m (ORCPT ); Tue, 3 Jan 2017 08:59:42 -0500 Received: from mga04.intel.com ([192.55.52.120]:51622 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756234AbdACN66 (ORCPT ); Tue, 3 Jan 2017 08:58:58 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,455,1477983600"; d="scan'208";a="1089349415" Message-ID: <1483451934.9552.205.camel@linux.intel.com> Subject: Re: [PATCH v2 2/6] staging: fbtft: do not override DMA coherent mask From: Andy Shevchenko To: Noralf =?ISO-8859-1?Q?Tr=F8nnes?= , Greg Kroah-Hartman , devel@driverdev.osuosl.org, Thomas Petazzoni , linux-kernel@vger.kernel.org Date: Tue, 03 Jan 2017 15:58:54 +0200 In-Reply-To: <1483440664.9552.202.camel@linux.intel.com> References: <20170102113534.127692-1-andriy.shevchenko@linux.intel.com> <20170102113534.127692-3-andriy.shevchenko@linux.intel.com> <1483440664.9552.202.camel@linux.intel.com> Organization: Intel Finland Oy Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2017-01-03 at 12:51 +0200, Andy Shevchenko wrote: > On Mon, 2017-01-02 at 19:14 +0100, Noralf Trønnes wrote: > > Den 02.01.2017 12:35, skrev Andy Shevchenko: > > > Usually it's not consumer's business to override resources passed > > > from > > > provider, in particularly DMA coherent mask. > > > --- a/drivers/staging/fbtft/fbtft-core.c > > > +++ b/drivers/staging/fbtft/fbtft-core.c > > > @@ -841,7 +841,6 @@ struct fb_info *fbtft_framebuffer_alloc(struct > > > fbtft_display *display, > > >    if (txbuflen > 0) { > > >   #ifdef CONFIG_HAS_DMA > > >    if (dma) { > > > - dev->coherent_dma_mask = ~0; > > > > Can we make this conditional like in of_dma_configure(): > > > >           if (!dev->coherent_dma_mask) > >                  dev->coherent_dma_mask = DMA_BIT_MASK(32); > > > > If not, I guess the mask has to be set before adding the spi device > > in > > fbtft_device.c to keep it from breaking. > > Good point. I will check this. So, I was too fast. Clearly an SPI slave device does not and *should not* know about DMA capabilities of SPI *host* controller. It's completely out of slave's business. The masks and other DMA properties only makes sense for the device which *actually does DMA*, and apparently SPI slaves do not suit that category (there are might be real SPI slaves with private DMA engines, though it's another story). Thus, the patch from my point of view should be kept in the same form. Regarding to the kbuild bot warning, would you like me to resend it fixed? Whatever the decision, I will wait for more comments and hopefully your tags. P.S. I dunno how it did work before, since DMA mask of slave device basically has no effect. Perhaps first argument to allocator should be NULL. That's only amendment I can see to this particular patch. -- Andy Shevchenko Intel Finland Oy