Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp121894pxb; Wed, 20 Jan 2021 02:51:27 -0800 (PST) X-Google-Smtp-Source: ABdhPJyEqN8Zq9MNUAVRzIuhqi7xunVDwNv1fYY5uuhbxoR8EX+hKOE34jvINYONiUq5I5+Esedn X-Received: by 2002:a17:906:2743:: with SMTP id a3mr5965731ejd.378.1611139887751; Wed, 20 Jan 2021 02:51:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611139887; cv=none; d=google.com; s=arc-20160816; b=Cj6J0Np7kjSqxGY0LQNYRRx+qonOArdbb5svgBNoWGid4WV0Rac/wP3LpVLHfNUHe+ WxsFwByuqk+uQ5lyN2zNxtYyGHbgzKmA1ICumF8AWZVTrXuv/QoAuUER4yGqq2r/kWsu aRlPvb5GQV0aSAQmEkYfezyiGCg7NLINHay0iNDzjhSiI2ayDOXYn5ClBt9HkwLgKufm q8ZO/qpvJZ5SBqXAyKQ8PF4CB6H0+0Pd6J5XQ6RYebEA8a6zfLMhIBeYVrWOzkMxQ0x4 OxbBSw8LbsFq3njpp8wjYGu7iDc8Thn7GmtmOt3OOSHWaWlJ86ozSlUbGyntVDAFy52c ozLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=Yo/48ruDH77ObKqel524FXQ0YODRZACkl5fGRtnXUUs=; b=BAcRDarYH5fTOvdm0FoVnKQXQaszenbrey5k14TJk4g46hY7zFrYe2f6pUXpxylYNl s4QO5+p1wNdUEg+VboL90MCpQ0YytBFopU4rmps6aHJeSDkI6NuGm4L4oDqy0kaUqkX/ DzZ+2s9bdVkrVn2s2PwClItuB4oeYXtVp17H7HARwnoOepJYYTvGOMS+k4kjO/6S5Ztp rYpeKfUYx6N3o6/3k11LDKg+JdsN/W3bALEqWUMQX7ax8kYs6RJtZt3QQu5uxtJvhitC ZLCOOqT8Ck6fbRnruu379jGFhb344hoZZAMmQx3E3ESaoLMtthGQ63Y6+kr8zYLoi6ZK tmLA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n16si688179edt.539.2021.01.20.02.51.03; Wed, 20 Jan 2021 02:51:27 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730474AbhATKNk (ORCPT + 99 others); Wed, 20 Jan 2021 05:13:40 -0500 Received: from mail-oi1-f176.google.com ([209.85.167.176]:38465 "EHLO mail-oi1-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729520AbhATJM1 (ORCPT ); Wed, 20 Jan 2021 04:12:27 -0500 Received: by mail-oi1-f176.google.com with SMTP id n186so16424648oia.5; Wed, 20 Jan 2021 01:12:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Yo/48ruDH77ObKqel524FXQ0YODRZACkl5fGRtnXUUs=; b=tVd6g2k/IFF21tWPMYSv8qLPHkThdLEK8hr5J4rJI8lUnKbQ39NBjO8faItsR7MG2M kzrKWG0XdKDiRfKY2aF+pg4ZX9FDTMD+TOzcHrvtj2t9ittYdgtSsv8AgDEcvQ/f/gTL tU2jr7VWjqz09mVTQmwdhCVC1GkfOfL4iuxqjo60av5TcG54ebmZvhZuGSsfYkWgfaXW JFEqTNrk6PtsX3dynCuh97WFksRgA/wua5nzQpDKgp0wbfkkFLl1DkIXb0YDvM41pms5 Q4Z9s/fyMXEDK15TdQ7PbhaVUs5m6CWJBKFaPGSVOsgXtLK1CIDWawWSMrf3JOsevgmc Iz6g== X-Gm-Message-State: AOAM531VmNOr7vCGmxnxAPJQ7S8Qre37NwqJncarEifX4pMLL7obAo/D RzskxCV+8MiIqVHIBkJe0ZInNG02kAi/zgYbZ7o= X-Received: by 2002:aca:31d5:: with SMTP id x204mr2253713oix.153.1611133894341; Wed, 20 Jan 2021 01:11:34 -0800 (PST) MIME-Version: 1.0 References: <20201218031703.3053753-1-saravanak@google.com> <20201218031703.3053753-6-saravanak@google.com> <86db7747ea6d48eebbf40a5855240d14@kernel.org> In-Reply-To: From: Geert Uytterhoeven Date: Wed, 20 Jan 2021 10:11:22 +0100 Message-ID: Subject: Re: [PATCH v1 5/5] driver core: Set fw_devlink=on by default To: Saravana Kannan Cc: Marc Zyngier , Greg Kroah-Hartman , "Rafael J. Wysocki" , Android Kernel Team , Linux Kernel Mailing List , Jisheng Zhang , Kevin Hilman , John Stultz , Nicolas Saenz Julienne , Yoshihiro Shimoda , Linux-Renesas Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Saravana, On Tue, Jan 19, 2021 at 7:09 PM Saravana Kannan wrote: > On Tue, Jan 19, 2021 at 1:05 AM Geert Uytterhoeven wrote: > > BTW, you are aware IOMMUs and DMA controllers are optional? > > I.e. device drivers with iommus and/or dmas DT properties where the > > targets of these properties do not have a driver should still be probed, > > eventually. But if the IOMMU or DMA drivers are present, they should be > > probed first, so the device drivers can make use of them. > > Yeah, this is going to be a problem then. How is this handled in > static kernels today? Do we just try to make sure the iommus driver > probes the iommu device before the consumers? And then the consumers > simply don't defer probe on failure to get iommu? Iommus are handled by the iommu framework, not by the driver. So the framework decides if/when it's OK to probe a device tied to an iommu. Hence the consumers' drivers don't return -EPROBE_DEFER, the framework takes care of that, before drivers' probe() functions are called. DMA is handled by consumer drivers, and driver-specific. Many consumer drivers consider DMA optional, and fall back to PIO if getting the DMA channel failed. Some drivers retry getting the DMA channel when the device is used, and thus may start using DMA when the DMAC driver appears and probes. > I can make this work if modules are not enabled (needs some code > changes), but it's not going to work when there are modules. There's > no way to tell if an iommu module won't be loaded soon. Also, device > links doing this behavior only for iommu/dma is probably not a good > idea. So, whatever we do will have to be common behavior. :( The iommu driver definitely needs to be built-in. Modular DMAC drivers currently work with consumer drivers that either consider DMA mandatory, or retry obtaining DMA channels. > Also, can you try deleting "iommu" and "dma" parsing in > of_supplier_bindings[] in driver/of/property.c and see if it helps? > Then we'd know this is the reason for things not working in your case. It also fails on another system without "iommus" properties: 182 supplier e6180000.system-controller not ready 18 supplier e6055400.gpio not ready 15 supplier e6055800.gpio not ready 15 supplier e6052000.gpio not ready 6 supplier e6055000.gpio not ready The system controller is the culprit, and is a dependency for all devices due to power-domains. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds