Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp2194461ybl; Thu, 15 Aug 2019 08:01:30 -0700 (PDT) X-Google-Smtp-Source: APXvYqzZ5WR6LNhpxWxMRJfyNVUjpiBlJjSHVqu+5jqVtYcWxq7bH9sQ2QEhmrIUq25mRJLh1QNN X-Received: by 2002:a17:90a:1c17:: with SMTP id s23mr2649971pjs.108.1565881289799; Thu, 15 Aug 2019 08:01:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565881289; cv=none; d=google.com; s=arc-20160816; b=Tu6dXwFW1NVvJ/hC8vw2481mqGEduiooKCwCW7hbg4siIsYLcYJ8pKutQm851eSLxW grV09WejJxIt5oECBBpNAm/Xg07ZJnMbxOiVIqaxcVM06Kj6V6gnR1mO1u0PsyGFIKBn pJJMCFEEALQHrSOjwlsKcRlWFRr/d89YvbdowydjW31cOvwXw1Sfefh2pjjeVha/hnDO 3P4iozOKa6TxsRrT1RTJyOhXhy7jNJxqhr2CDTq8L3wwRPfJu3rycZfH+AMa66FyPaNt HvovnS5w31mPkB44vfruF17sAWmI8PmUg3zqzgsIHSMeuUoXhyTLxLpqnxVyMcDouI6A GC6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=q2214Hu+K3GRJSnvc42GaAuSIUo3k+FR37n+BV7Uzsw=; b=H37oFpBGHdxMCsm0z7kQxAKwN88arqgR4RLebzFGCMdCZrchDqQfIQM82uuIxKQoiz V8xtKSiCw8Ec+4FzSARImSV4KfhUAx2xIoH3bts8hDhSDLgoVVd/Ugy9ytdzq2giEZq4 TTmuE6vMazbDTgbzujhbmuLIlWloO5W0ox2e/poPQmYO8nx3TxaYoCgDaf4UeD8zvORO wAyZ2uUvr2iwSgEC9CPAwDAii3YwBsB+vq1hH/TumzhtNDNO7ZJVw1nrWoOq2wgLopXL zWxt/wQhRfdIhSgVcNT71uEG3hG71sOEqIQn05hgI92bg08CQOMhN7W3fsSPabNcR6OM c9nw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y19si2113170pll.326.2019.08.15.08.01.12; Thu, 15 Aug 2019 08:01:29 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732362AbfHONiS (ORCPT + 99 others); Thu, 15 Aug 2019 09:38:18 -0400 Received: from verein.lst.de ([213.95.11.211]:46797 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732324AbfHONiR (ORCPT ); Thu, 15 Aug 2019 09:38:17 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 8BF0568AFE; Thu, 15 Aug 2019 15:38:12 +0200 (CEST) Date: Thu, 15 Aug 2019 15:38:12 +0200 From: Christoph Hellwig To: Greg Kroah-Hartman Cc: Christoph Hellwig , Maxime Chevallier , Gavin Li , Laurentiu Tudor , Minas Harutyunyan , Alan Stern , Geoff Levand , Michal Simek , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Olav Kongas , Tony Prisk , Mathias Nyman , Bin Liu , linux-arm-kernel@lists.infradead.org, linux-usb@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, iommu@lists.linux-foundation.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 6/6] driver core: initialize a default DMA mask for platform device Message-ID: <20190815133812.GF12036@lst.de> References: <20190811080520.21712-1-hch@lst.de> <20190811080520.21712-7-hch@lst.de> <20190815130325.GB17065@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190815130325.GB17065@kroah.com> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 15, 2019 at 03:03:25PM +0200, Greg Kroah-Hartman wrote: > > --- a/include/linux/platform_device.h > > +++ b/include/linux/platform_device.h > > @@ -24,6 +24,7 @@ struct platform_device { > > int id; > > bool id_auto; > > struct device dev; > > + u64 dma_mask; > > Why is the dma_mask in 'struct device' which is part of this structure, > not sufficient here? Shouldn't the "platform" be setting that up > correctly already in the "archdata" type callback? Becaus the dma_mask in struct device is a pointer that needs to point to something, and this is the best space we can allocate for 'something'. m68k and powerpc currently do something roughly equivalent at the moment, while everyone else just has horrible, horrible hacks. As mentioned in the changelog the intent of this patch is that we treat platform devices like any other bus, where the bus allocates the space for the dma_mask. The long term plan is to eventually kill that weird pointer indirection that doesn't help anyone, but for that we need to sort out the basics first.