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 0871BC83001 for ; Tue, 28 Apr 2020 14:49:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E2EB221744 for ; Tue, 28 Apr 2020 14:49:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728110AbgD1Ot4 (ORCPT ); Tue, 28 Apr 2020 10:49:56 -0400 Received: from foss.arm.com ([217.140.110.172]:53152 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727930AbgD1Otz (ORCPT ); Tue, 28 Apr 2020 10:49:55 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4D0A331B; Tue, 28 Apr 2020 07:49:54 -0700 (PDT) Received: from [10.57.33.170] (unknown [10.57.33.170]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 92DCD3F305; Tue, 28 Apr 2020 07:49:50 -0700 (PDT) Subject: Re: [PATCH v3 02/16] mfd: mfd-core: Don't overwrite the dma_mask of the child device To: Andy Shevchenko Cc: Michael Walle , linux-gpio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hwmon@vger.kernel.org, linux-pwm@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Linus Walleij , Bartosz Golaszewski , Rob Herring , Jean Delvare , Guenter Roeck , Lee Jones , Thierry Reding , =?UTF-8?Q?Uwe_Kleine-K=c3=b6nig?= , Wim Van Sebroeck , Shawn Guo , Li Yang , Thomas Gleixner , Jason Cooper , Marc Zyngier , Mark Brown , Greg Kroah-Hartman References: <20200423174543.17161-1-michael@walle.cc> <20200423174543.17161-3-michael@walle.cc> <20200428124548.GS185537@smile.fi.intel.com> <3cd3705a-4f48-6a46-e869-3ee11dc17323@arm.com> <20200428142938.GX185537@smile.fi.intel.com> From: Robin Murphy Message-ID: <6ccad285-7b5f-3037-d4d5-ff4d9571b612@arm.com> Date: Tue, 28 Apr 2020 15:49:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200428142938.GX185537@smile.fi.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-hwmon-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-hwmon@vger.kernel.org On 2020-04-28 3:29 pm, Andy Shevchenko wrote: > On Tue, Apr 28, 2020 at 02:06:20PM +0100, Robin Murphy wrote: >> On 2020-04-28 1:45 pm, Andy Shevchenko wrote: >>> On Thu, Apr 23, 2020 at 07:45:29PM +0200, Michael Walle wrote: >>>> Commit cdfee5623290 ("driver core: initialize a default DMA mask for >>>> platform device") initialize the DMA of a platform device. But if the >>>> parent doesn't have a dma_mask set, for example if it's an I2C device, >>>> the dma_mask of the child platform device will be set to zero again. >>>> Which leads to many "DMA mask not set" warnings, if the MFD cell has the >>>> of_compatible property set. >>> >>> I'm wondering why parent doesn't have it. >> >> Because the parent isn't on a DMA-capable bus, and thus really shouldn't >> have a valid DMA configuration ever. > > Then how come a child is DMA capable? Because it's a platform device, and thanks to decades of legacy we have to assume that any platform devices *is* DMA capable. > MFD takes a physical device node as a > parent and creates one of several children with that device as a parent. DMA > mask is a property of the device which *does DMA*. Obviously a child is not > correct device for that. > > Where am I mistaken? In theory you're not, however in practice the driver model doesn't really give us a nice way to express the necessary subtle distinctions between this and other similar-looking but fundamentally different parent-child relationships - if it did, we probably wouldn't need the whole MFD layer in the first place. The logical ideal would be to create the children on the same bus as the parent, but as it is doing that would likely lead to the I2C/SPI/whatever bus code assuming they are first-class devices and open up a whole new world of problems. For better or worse, the platform bus is the dumping ground for random crap, so we just have to deal with all the abstraction breakage that leaks out of that. Robin. >>> I remember we have explicit patches in the past for buses such as PCI and AMBA >>> to set default DMA mask for all physical devices on the respective bus, of >>> course they can individually override it later. >>> >>> So, this seems to me a paper over the real issue (absence of default DMA mask >>> where it's needed) and devices should explicitly define it if they disagree >>> with default. >>> >>> If I'm wrong, you really need elaborate commit message much better. >> >> The problem here is that MFD children are created as platform devices >> (regardless of what their parent is) and assigned an of_node, at which point >> they look pretty much indistinguishable from SoC devices created by the >> of_platform code, that *do* have to be assumed to be DMA-capable to prevent >> ~90% of existing devicetrees from breaking. >> >> Of course the real fundamental issue is the platform bus itself, but it's >> way too late to fix that :( > > I don't think it's an issue, rather in model you are describing. Or I miss > something not so obvious. > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robin Murphy Subject: Re: [PATCH v3 02/16] mfd: mfd-core: Don't overwrite the dma_mask of the child device Date: Tue, 28 Apr 2020 15:49:49 +0100 Message-ID: <6ccad285-7b5f-3037-d4d5-ff4d9571b612@arm.com> References: <20200423174543.17161-1-michael@walle.cc> <20200423174543.17161-3-michael@walle.cc> <20200428124548.GS185537@smile.fi.intel.com> <3cd3705a-4f48-6a46-e869-3ee11dc17323@arm.com> <20200428142938.GX185537@smile.fi.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20200428142938.GX185537@smile.fi.intel.com> Content-Language: en-GB Sender: linux-hwmon-owner@vger.kernel.org To: Andy Shevchenko Cc: Michael Walle , linux-gpio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hwmon@vger.kernel.org, linux-pwm@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Linus Walleij , Bartosz Golaszewski , Rob Herring , Jean Delvare , Guenter Roeck , Lee Jones , Thierry Reding , =?UTF-8?Q?Uwe_Kleine-K=c3=b6nig?= , Wim Van Sebroeck , Shawn Guo , Li Yang , Thomas Gleixner , Jason Cooper List-Id: linux-pwm@vger.kernel.org On 2020-04-28 3:29 pm, Andy Shevchenko wrote: > On Tue, Apr 28, 2020 at 02:06:20PM +0100, Robin Murphy wrote: >> On 2020-04-28 1:45 pm, Andy Shevchenko wrote: >>> On Thu, Apr 23, 2020 at 07:45:29PM +0200, Michael Walle wrote: >>>> Commit cdfee5623290 ("driver core: initialize a default DMA mask for >>>> platform device") initialize the DMA of a platform device. But if the >>>> parent doesn't have a dma_mask set, for example if it's an I2C device, >>>> the dma_mask of the child platform device will be set to zero again. >>>> Which leads to many "DMA mask not set" warnings, if the MFD cell has the >>>> of_compatible property set. >>> >>> I'm wondering why parent doesn't have it. >> >> Because the parent isn't on a DMA-capable bus, and thus really shouldn't >> have a valid DMA configuration ever. > > Then how come a child is DMA capable? Because it's a platform device, and thanks to decades of legacy we have to assume that any platform devices *is* DMA capable. > MFD takes a physical device node as a > parent and creates one of several children with that device as a parent. DMA > mask is a property of the device which *does DMA*. Obviously a child is not > correct device for that. > > Where am I mistaken? In theory you're not, however in practice the driver model doesn't really give us a nice way to express the necessary subtle distinctions between this and other similar-looking but fundamentally different parent-child relationships - if it did, we probably wouldn't need the whole MFD layer in the first place. The logical ideal would be to create the children on the same bus as the parent, but as it is doing that would likely lead to the I2C/SPI/whatever bus code assuming they are first-class devices and open up a whole new world of problems. For better or worse, the platform bus is the dumping ground for random crap, so we just have to deal with all the abstraction breakage that leaks out of that. Robin. >>> I remember we have explicit patches in the past for buses such as PCI and AMBA >>> to set default DMA mask for all physical devices on the respective bus, of >>> course they can individually override it later. >>> >>> So, this seems to me a paper over the real issue (absence of default DMA mask >>> where it's needed) and devices should explicitly define it if they disagree >>> with default. >>> >>> If I'm wrong, you really need elaborate commit message much better. >> >> The problem here is that MFD children are created as platform devices >> (regardless of what their parent is) and assigned an of_node, at which point >> they look pretty much indistinguishable from SoC devices created by the >> of_platform code, that *do* have to be assumed to be DMA-capable to prevent >> ~90% of existing devicetrees from breaking. >> >> Of course the real fundamental issue is the platform bus itself, but it's >> way too late to fix that :( > > I don't think it's an issue, rather in model you are describing. Or I miss > something not so obvious. > 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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,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 0F227C83001 for ; Tue, 28 Apr 2020 14:52:49 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 C0695206C0 for ; Tue, 28 Apr 2020 14:52:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="KQErRCdM" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C0695206C0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=dvw7/qC+6tSnkf3UfF2wtUGJNSSAvH8kBb94xzzy89s=; b=KQErRCdM6eNCTvZgVEkOA4vm2 /v5j+NumUS9+4LUrakHYXMxd4uzxxbeTDILtaY/f9uuWlzose9Ix8IJMNhekp6LH07K0ICwQbn3qL IDclVgI/XbqXTjOXuwufCxyS0MuaVYrgtALW+Nd6jDz58sv9XwVQVzLEvZbD1rCTjpA0r1ALDpmPP MhxdDTlYWGKTXsb/q8XNnDkiESgi0oPzZjbFp1mnYMvaEB8rTQ2d1Mf6Qz3emszTRPzzY8bcD6hwf Td+9DD1zp2lp485ApKYv03jnChTXi5FQSfd0w6D+BSnGtBvg9zjFy5rHwrj5ZWOj6m7FWp3c52YTH t+6FoZfEg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jTRbI-0004AQ-LX; Tue, 28 Apr 2020 14:52:44 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jTRYY-0008Q1-WB for linux-arm-kernel@lists.infradead.org; Tue, 28 Apr 2020 14:49:59 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4D0A331B; Tue, 28 Apr 2020 07:49:54 -0700 (PDT) Received: from [10.57.33.170] (unknown [10.57.33.170]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 92DCD3F305; Tue, 28 Apr 2020 07:49:50 -0700 (PDT) Subject: Re: [PATCH v3 02/16] mfd: mfd-core: Don't overwrite the dma_mask of the child device To: Andy Shevchenko References: <20200423174543.17161-1-michael@walle.cc> <20200423174543.17161-3-michael@walle.cc> <20200428124548.GS185537@smile.fi.intel.com> <3cd3705a-4f48-6a46-e869-3ee11dc17323@arm.com> <20200428142938.GX185537@smile.fi.intel.com> From: Robin Murphy Message-ID: <6ccad285-7b5f-3037-d4d5-ff4d9571b612@arm.com> Date: Tue, 28 Apr 2020 15:49:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200428142938.GX185537@smile.fi.intel.com> Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200428_074955_414760_FBA10CF7 X-CRM114-Status: GOOD ( 20.33 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, Linus Walleij , Thierry Reding , Lee Jones , Jason Cooper , Marc Zyngier , Bartosz Golaszewski , =?UTF-8?Q?Uwe_Kleine-K=c3=b6nig?= , Guenter Roeck , linux-pwm@vger.kernel.org, Jean Delvare , linux-watchdog@vger.kernel.org, linux-gpio@vger.kernel.org, Rob Herring , Thomas Gleixner , Wim Van Sebroeck , linux-arm-kernel@lists.infradead.org, linux-hwmon@vger.kernel.org, Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Li Yang , Michael Walle , Mark Brown , Shawn Guo Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2020-04-28 3:29 pm, Andy Shevchenko wrote: > On Tue, Apr 28, 2020 at 02:06:20PM +0100, Robin Murphy wrote: >> On 2020-04-28 1:45 pm, Andy Shevchenko wrote: >>> On Thu, Apr 23, 2020 at 07:45:29PM +0200, Michael Walle wrote: >>>> Commit cdfee5623290 ("driver core: initialize a default DMA mask for >>>> platform device") initialize the DMA of a platform device. But if the >>>> parent doesn't have a dma_mask set, for example if it's an I2C device, >>>> the dma_mask of the child platform device will be set to zero again. >>>> Which leads to many "DMA mask not set" warnings, if the MFD cell has the >>>> of_compatible property set. >>> >>> I'm wondering why parent doesn't have it. >> >> Because the parent isn't on a DMA-capable bus, and thus really shouldn't >> have a valid DMA configuration ever. > > Then how come a child is DMA capable? Because it's a platform device, and thanks to decades of legacy we have to assume that any platform devices *is* DMA capable. > MFD takes a physical device node as a > parent and creates one of several children with that device as a parent. DMA > mask is a property of the device which *does DMA*. Obviously a child is not > correct device for that. > > Where am I mistaken? In theory you're not, however in practice the driver model doesn't really give us a nice way to express the necessary subtle distinctions between this and other similar-looking but fundamentally different parent-child relationships - if it did, we probably wouldn't need the whole MFD layer in the first place. The logical ideal would be to create the children on the same bus as the parent, but as it is doing that would likely lead to the I2C/SPI/whatever bus code assuming they are first-class devices and open up a whole new world of problems. For better or worse, the platform bus is the dumping ground for random crap, so we just have to deal with all the abstraction breakage that leaks out of that. Robin. >>> I remember we have explicit patches in the past for buses such as PCI and AMBA >>> to set default DMA mask for all physical devices on the respective bus, of >>> course they can individually override it later. >>> >>> So, this seems to me a paper over the real issue (absence of default DMA mask >>> where it's needed) and devices should explicitly define it if they disagree >>> with default. >>> >>> If I'm wrong, you really need elaborate commit message much better. >> >> The problem here is that MFD children are created as platform devices >> (regardless of what their parent is) and assigned an of_node, at which point >> they look pretty much indistinguishable from SoC devices created by the >> of_platform code, that *do* have to be assumed to be DMA-capable to prevent >> ~90% of existing devicetrees from breaking. >> >> Of course the real fundamental issue is the platform bus itself, but it's >> way too late to fix that :( > > I don't think it's an issue, rather in model you are describing. Or I miss > something not so obvious. > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel