From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CABD2C3A589 for ; Thu, 15 Aug 2019 13:43:00 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 491AF206C1 for ; Thu, 15 Aug 2019 13:43:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 491AF206C1 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 468SM56PvRzDqBY for ; Thu, 15 Aug 2019 23:42:57 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lst.de (client-ip=213.95.11.211; helo=verein.lst.de; envelope-from=hch@lst.de; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=lst.de Received: from verein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 468SFk4jGXzDqsM for ; Thu, 15 Aug 2019 23:38:18 +1000 (AEST) 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 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) X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Gavin Li , Fabio Estevam , Christoph Hellwig , linux-arch@vger.kernel.org, Michal Simek , Maxime Chevallier , Alan Stern , NXP Linux Team , Mathias Nyman , Sascha Hauer , Minas Harutyunyan , Olav Kongas , Bin Liu , linux-arm-kernel@lists.infradead.org, Laurentiu Tudor , Geoff Levand , Shawn Guo , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Tony Prisk , iommu@lists.linux-foundation.org, Pengutronix Kernel Team , linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" 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.