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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 92405C433F5 for ; Wed, 22 Dec 2021 16:42:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; 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=wMIe5qTP3a8BDI6rPdnsW3+531HGYdJA05Oq5ozIDsY=; b=cgtNkJe4Sa5w5d aKFq5wYYWQkqOuSORGdllM/yI9GX+R1b6GTTnBmxeATNeK4kFXyROI1euzNi+otJMO2j4LrDorEtn fAbqBp8OhrmPAJXyXlK0B5tPW6wKcuvxdmyFIOfNrvMLHKPrJKqS8UZiIJgkV87obmg4/BSa7NXMW WD/ZRIBf8znnoFJS5YLfDPqTad1HE+TGYj2MndKNP8xA5wmGkvj0Wzgh6F4g5CrsjKBAU4Nc9Gg0B HQUNxZRAGI+z+JHQ6R/lgMb+nbJEmsUX60h3sx+vdmqT9KOogmBsyjuGcb/+5P0g7RdLuEqsl8loG Jd5NXVGEpf80L2DKs1vA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n04fs-00AuSD-PD; Wed, 22 Dec 2021 16:41:08 +0000 Received: from mail-qt1-x830.google.com ([2607:f8b0:4864:20::830]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n04fm-00AuRV-AB for linux-arm-kernel@lists.infradead.org; Wed, 22 Dec 2021 16:41:06 +0000 Received: by mail-qt1-x830.google.com with SMTP id m18so1980534qtk.3 for ; Wed, 22 Dec 2021 08:41:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=zdnOtqH49FH1fYSxifA1900Fs7Gze7wTJmeR7vfENR8=; b=nPyWZp9kN4YMVBYp2L51x8LeEuE5RmMKfdr9ToP4mwLI5eWu4HcHT/duQVXnKzNKZ7 AXiQ+FTmo+w6iMgwAQkimWPa6MBafVDQU+X1eu/13sLNcp9AixdFjFSrG3mRpxhudzdw L370rgVD867T1JWTjsg02nBiwx0Tsnv/gym0E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=zdnOtqH49FH1fYSxifA1900Fs7Gze7wTJmeR7vfENR8=; b=rg8Sap/5DaltFPxHKKBnjVChoYUvwQgb5JHia0++7/2DXIis4DQJknDCnluHr0xo3O SM69+JE2M6KknN1i/ukRhAnBisCamFyYQ35Oc5rZ0qzIb+jlwHojoCw+lHl+nStNyDvd RVFFBdbBrmT0huQzn4tBQO1cG4G3Nki7gm9YrA0y314KF3uEcCDlw9j3zmF7jm2iaWgJ VCevxbGDJENsRPGGo+1fRHg/vQheWLKU62y59wR0sa11gvri4pYbyuNHEgKefTnP6UAz QJF49/JKQLpmp31Gh/94dWBaq60p7h3XdFAghJH1ynWzm+IlPOd3u+DuXDzfoBYVsfbP cbvg== X-Gm-Message-State: AOAM532VbZF7TUhwwWjDbdD2I62lzV7GKOB8rhegolGx9RMUzKYfqmdA 3uK0L23nDZjyZTrmqRszN6eWUQ== X-Google-Smtp-Source: ABdhPJyXqqeFwTthMvo3+JnH55PTWd1DXt2aOuMGGTCA2lQhyF8hEjLaiuai/kcU7kuEQ6sx29auuQ== X-Received: by 2002:ac8:5d89:: with SMTP id d9mr2748336qtx.49.1640191259808; Wed, 22 Dec 2021 08:40:59 -0800 (PST) Received: from bill-the-cat (2603-6081-7b01-cbda-d9c0-d76f-ebfe-a14d.res6.spectrum.com. [2603:6081:7b01:cbda:d9c0:d76f:ebfe:a14d]) by smtp.gmail.com with ESMTPSA id l15sm2177207qtx.77.2021.12.22.08.40.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Dec 2021 08:40:59 -0800 (PST) Date: Wed, 22 Dec 2021 11:40:57 -0500 From: Tom Rini To: Vignesh Raghavendra Cc: Arnd Bergmann , Nishanth Menon , Olof Johansson , SoC , arm-soc , Tero Kristo , Linux ARM , Linux Kernel Mailing List , KISHON VIJAY ABRAHAM Subject: Re: [GIT PULL 1/2] arm64: TI K3 SoC configs changes for v5.17 Message-ID: <20211222164057.GN2773246@bill-the-cat> References: <20211217172806.10023-1-vigneshr@ti.com> <06e60038-1365-fc35-801e-448c9025fb2a@ti.com> <20211221153250.GA2081238@bill-the-cat> <20211221160933.GM2773246@bill-the-cat> <9a5d6b32-7e2a-0eae-aed4-97291e4c3f97@ti.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <9a5d6b32-7e2a-0eae-aed4-97291e4c3f97@ti.com> X-Clacks-Overhead: GNU Terry Pratchett X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211222_084102_406587_36E01D39 X-CRM114-Status: GOOD ( 32.28 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Dec 22, 2021 at 12:56:06PM +0530, Vignesh Raghavendra wrote: > > > On 21/12/21 9:39 pm, Tom Rini wrote: > > On Tue, Dec 21, 2021 at 04:55:48PM +0100, Arnd Bergmann wrote: > >> On Tue, Dec 21, 2021 at 4:32 PM Tom Rini wrote: > >>> On Mon, Dec 20, 2021 at 11:10:25PM +0530, Vignesh Raghavendra wrote: > >>>> > >>>> Currently its not possible to build PCIE_CADENCE_PLAT_HOST/EP drivers as > >>>> modules (symbols are bool only). > >>>> PCIe is not necessary for basic boot either. So, I can drop these > >>>> configs until these drivers are build able as modules, if you prefer. > >>> > >>> Is PCIe required for basic boot for the other platforms in the defconfig > >>> which do enable it in the defconfig today? It is required for non-basic > >>> boot (whatever storage one puts in a PCIe slot). If someone is going to > >>> be fixing the PCIe driver to be able to be modular, that's fine too but > >>> I ran in to this trying to see what works out of the box in the > >>> defconfig, on this platform and hit both of these rather large > >>> omissions. > >> > >> If PCI is often used for storage, then that's ok. There are a number of > >> other platforms where PCIe is only used for wireless networking or > >> other secondary devices, but they are still built-in because they got > >> added before it became possible for PCIe host drivers to be loadable > >> modules. I would like to eventually go through and turn those into > >> loadable modules, but for the moment it would be good to only add > >> built-in drivers where this is actually useful. > > > > That's good to know. My question tho is, what's actually useful? The > > EVM is 2 PCIe x8 type slots. I honestly don't know if that means "super > > useful, arbitrary devices are expected to work" or "not useful, > > arbitrary devices are not expected to work". Is the functional > > definition of what's in the defconfig vs left up to users, > > distributions, etc, to find and enabled defined, or at least well known > > / explained somewhere? Where I'm coming from on this is that these > > platforms practically are, and can be SystemReady IR certified. So > > what's needed here to ensure there's a good experience distros to enable > > what needs enabling for full functionality? What we hit was "lets throw > > some stuff at this board to test it out and.. wait, PCIe isn't enabled > > at all? USB host isn't enabled at all?" > > > > And all that said, if someone is going to be fixing the PCIe drivers to > > be enabled as modules soon, and just getting it handled that way in the > > next appropriately timed merge window, OK, fine, good enough. > > > > Looks like its not a big effort to convert J7 PCIe driver to build as > module and can be done for v5.18 Merge Window. So how about we enable > only USB controller drivers now and then enable PCIe after its > build-able as module? Works for me, thanks! -- Tom _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel