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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 E9934C433ED for ; Thu, 29 Apr 2021 06:41:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AC67E61447 for ; Thu, 29 Apr 2021 06:41:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231343AbhD2Gmo (ORCPT ); Thu, 29 Apr 2021 02:42:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49422 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230193AbhD2Gmn (ORCPT ); Thu, 29 Apr 2021 02:42:43 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6BAF1C06138B; Wed, 28 Apr 2021 23:41:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=eectPFpfXLXiECozRv565wMzMoLfV81R/OySRcsjIx4=; b=uwuYZy6an6Yzrtggc09lLu7dx/ P7MoqcJRxJWnckM11s38h5AIFZ/xy9t2z7FSvqMe8jYQZ0qQa7fCl/W1IQiSXbKQoV/z+2Qz8EnuN ABHiL6eAqLUMBCFaF4VBrCLgjnCd4CquwthzqQbGRxGM3xkulwS75BVpVBUFO+a3vJwZMqckDC4nv ZvxQqk3jUkbBmgm0VGFpd2pBuhYR03g+I4g5v2FV2r67B3gKj2bxTM+JFneIQfPZk9bGS6jSI8nQ9 HHFu5VGYvymMmnvvXidLWXh5Y2TqKxgFqFu5dpJWTCCllyR7JO3/LV22uGXSvMpFwOy0A6g2w0RmU AGENQd5Q==; Received: from hch by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lc0MP-009ILi-Rb; Thu, 29 Apr 2021 06:41:19 +0000 Date: Thu, 29 Apr 2021 07:41:17 +0100 From: Christoph Hellwig To: Peter Geis Cc: Shawn Lin , Simon Xue , Bjorn Helgaas , Lorenzo Pieralisi , linux-pci@vger.kernel.org, "open list:ARM/Rockchip SoC..." , devicetree@vger.kernel.org, Rob Herring , Johan Jonker , Heiko Stuebner Subject: Re: [PATCH v7] PCI: rockchip: Add Rockchip RK356X host controller driver Message-ID: <20210429064117.GA2214470@infradead.org> References: <20210414070325.924789-1-xxm@rock-chips.com> <5af0f6f8-bc29-f50e-ca14-94049b7d17ed@rock-chips.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Wed, Apr 28, 2021 at 09:42:37PM -0400, Peter Geis wrote: > I have functional MSI support, some devices do not support MSIs > however and need legacy INTx. > I'd like to point out that the downstream patch does not actually work > on downstream. > The GFP_DMA32 flag is discarded by the slab allocator, this breaks MSI > allocation when the PCIe driver probes. > I hacked together my own version which works but would definitely not > be accepted for submission. Seriously folks. Never, ever use GFP_DMA or GFP_DMA32 in actual driver code. They fundamentally don't do what you want. Devices as a rule of thumb do care about DMA addressability, not CPU addressability, so they must use the DMA API to allocate the memory, and the dma mask to control addressability. 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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 CDC38C433ED for ; Thu, 29 Apr 2021 06:41:34 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 48CFA613CE for ; Thu, 29 Apr 2021 06:41:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 48CFA613CE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=7r8A/RkKjKbW/CE0jhaQMpbI8FHqsC2szxnSbACLRV8=; b=G+62bLUk1yJAAAq5/a6Gz760P 7ozIBYeyq9gwWAhrQ4NEhDO+A7rmzN/Uiy+sNUexLZTsCdGjKElDkFNetrNVYNBUj1/xFa/VekDr8 b/lSM/Ymh6ThTuB+xtQeg6ZJvHB8sDxGgD0rKYDppY+lJd1QyItj1gxbjYI3YwFO0cHk/1olI+wQg JWsrP2cCBUgseNBFSa6GnPrnFgyCj+NTA4RNihzmPlpcYMGt0HH0GNUxASR2i0+JK/g7kjOdN3b8y uuhrTQ4HgUlfnIH7XNqW75yhRVjxtUro42gxQGht2GpMaw959S26BO1QSSxGXMlKlAKvsv0KcLsyV NcQI5sbJA==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lc0Mb-005612-IA; Thu, 29 Apr 2021 06:41:29 +0000 Received: from casper.infradead.org ([2001:8b0:10b:1236::1]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lc0MZ-00560p-8a for linux-rockchip@desiato.infradead.org; Thu, 29 Apr 2021 06:41:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=eectPFpfXLXiECozRv565wMzMoLfV81R/OySRcsjIx4=; b=uwuYZy6an6Yzrtggc09lLu7dx/ P7MoqcJRxJWnckM11s38h5AIFZ/xy9t2z7FSvqMe8jYQZ0qQa7fCl/W1IQiSXbKQoV/z+2Qz8EnuN ABHiL6eAqLUMBCFaF4VBrCLgjnCd4CquwthzqQbGRxGM3xkulwS75BVpVBUFO+a3vJwZMqckDC4nv ZvxQqk3jUkbBmgm0VGFpd2pBuhYR03g+I4g5v2FV2r67B3gKj2bxTM+JFneIQfPZk9bGS6jSI8nQ9 HHFu5VGYvymMmnvvXidLWXh5Y2TqKxgFqFu5dpJWTCCllyR7JO3/LV22uGXSvMpFwOy0A6g2w0RmU AGENQd5Q==; Received: from hch by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lc0MP-009ILi-Rb; Thu, 29 Apr 2021 06:41:19 +0000 Date: Thu, 29 Apr 2021 07:41:17 +0100 From: Christoph Hellwig To: Peter Geis Cc: Shawn Lin , Simon Xue , Bjorn Helgaas , Lorenzo Pieralisi , linux-pci@vger.kernel.org, "open list:ARM/Rockchip SoC..." , devicetree@vger.kernel.org, Rob Herring , Johan Jonker , Heiko Stuebner Subject: Re: [PATCH v7] PCI: rockchip: Add Rockchip RK356X host controller driver Message-ID: <20210429064117.GA2214470@infradead.org> References: <20210414070325.924789-1-xxm@rock-chips.com> <5af0f6f8-bc29-f50e-ca14-94049b7d17ed@rock-chips.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org On Wed, Apr 28, 2021 at 09:42:37PM -0400, Peter Geis wrote: > I have functional MSI support, some devices do not support MSIs > however and need legacy INTx. > I'd like to point out that the downstream patch does not actually work > on downstream. > The GFP_DMA32 flag is discarded by the slab allocator, this breaks MSI > allocation when the PCIe driver probes. > I hacked together my own version which works but would definitely not > be accepted for submission. Seriously folks. Never, ever use GFP_DMA or GFP_DMA32 in actual driver code. They fundamentally don't do what you want. Devices as a rule of thumb do care about DMA addressability, not CPU addressability, so they must use the DMA API to allocate the memory, and the dma mask to control addressability. _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip