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=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 83D78C433E1 for ; Thu, 2 Jul 2020 08:52:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 628AD208D5 for ; Thu, 2 Jul 2020 08:52:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593679934; bh=64soL0tpbUuYgXGJqe7C5+8BD4CFUcTKY7CsglwFpHA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=njiJNHexUETikC+oPRU777xHNwG0+LdgrbrmGgRXwPiwhiiilNxvPBDJcPoEe4KKu MOt8f5sfpNfE8RkX94Dent+xETiTLJbehehg+IKQizU6UOgoMBF/SIgrMTxzMadCye DJ1bG37FM3qt9R71iPlMr/uO4yAphUZIes3ywvH4= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726795AbgGBIwK (ORCPT ); Thu, 2 Jul 2020 04:52:10 -0400 Received: from mail.kernel.org ([198.145.29.99]:35136 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726089AbgGBIwK (ORCPT ); Thu, 2 Jul 2020 04:52:10 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8F8EC2088E; Thu, 2 Jul 2020 08:52:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593679929; bh=64soL0tpbUuYgXGJqe7C5+8BD4CFUcTKY7CsglwFpHA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bV71bDmCWLpYhjJuusNikY/jpLjKUstYQQSuTe+EzDvYkEsEVjHagEuzrCMiXRLSe Xy23RtBHyDSEkDtkx8ct96dxIocLXlrDZA1kczoAmy5YtvAR5XXnfGzwD3F1cL8JB+ DnMfMwIC8yJTQEzUiOyQEoU7mF3gN5VLnBuJfCRo= Date: Thu, 2 Jul 2020 10:52:12 +0200 From: Greg Kroah-Hartman To: Oliver O'Halloran Cc: Rajat Jain , "Rafael J. Wysocki" , Heikki Krogerus , David Woodhouse , Lu Baolu , Joerg Roedel , Bjorn Helgaas , "Rafael J. Wysocki" , Len Brown , "open list:AMD IOMMU (AMD-VI)" , Linux Kernel Mailing List , Linux PCI , ACPI Devel Maling List , Raj Ashok , "Krishnakumar, Lalithambika" , Mika Westerberg , Jean-Philippe Brucker , Prashant Malani , Benson Leung , Todd Broch , Alex Levin , Mattias Nissler , Rajat Jain , Bernie Keany , Aaron Durbin , Diego Rivas , Duncan Laurie , Furquan Shaikh , Jesse Barnes , Christian Kellner , Alex Williamson , Saravana Kannan , Suzuki K Poulose , Arnd Bergmann Subject: Re: [PATCH v2 5/7] driver core: Add device location to "struct device" and expose it in sysfs Message-ID: <20200702085212.GA1089671@kroah.com> References: <20200630104948.GC856968@kuha.fi.intel.com> <20200630125216.GA1109228@kroah.com> <20200630153816.GD1785141@kroah.com> <20200630170012.GB1894898@kroah.com> <20200702073226.GB1073011@kroah.com> <24f56c0ed6d10ef565cf83d47d0538d37ac0d8ef.camel@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24f56c0ed6d10ef565cf83d47d0538d37ac0d8ef.camel@gmail.com> Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Thu, Jul 02, 2020 at 06:40:09PM +1000, Oliver O'Halloran wrote: > On Thu, 2020-07-02 at 09:32 +0200, Greg Kroah-Hartman wrote: > > On Thu, Jul 02, 2020 at 03:23:23PM +1000, Oliver O'Halloran wrote: > > > Yep, that's a problem. If we want to provide a useful mechanism to > > > userspace then the default behaviour of the kernel can't undermine > > > that mechanism. If that means we need another kernel command line > > > parameter then I guess we just have to live with it. > > > > I really do not want yet-another-kernel-command-line-option if we can > > help it at all. Sane defaults are the best thing to do here. Userspace > > comes up really early, put your policy in there, not in blobs passed > > from your bootloader. > > Userspace comes up early, but builtin drivers will bind before init is > started. e.g. > > # dmesg | egrep '0002:01:00.0|/init' > [ 0.976800][ T1] pci 0002:01:00.0: [8086:1589] type 00 class 0x020000 > [ 0.976923][ T1] pci 0002:01:00.0: reg 0x10: [mem 0x220000000000-0x2200007fffff 64bit pref] > [ 0.977004][ T1] pci 0002:01:00.0: reg 0x1c: [mem 0x220002000000-0x220002007fff 64bit pref] > [ 0.977068][ T1] pci 0002:01:00.0: reg 0x30: [mem 0x00000000-0x0007ffff pref] > [ 0.977122][ T1] pci 0002:01:00.0: BAR3 [mem size 0x00008000 64bit pref]: requesting alignment to 0x10000 > [ 0.977401][ T1] pci 0002:01:00.0: PME# supported from D0 D3hot > [ 1.011929][ T1] pci 0002:01:00.0: BAR 0: assigned [mem 0x220000000000-0x2200007fffff 64bit pref] > [ 1.012085][ T1] pci 0002:01:00.0: BAR 6: assigned [mem 0x3fe100000000-0x3fe10007ffff pref] > [ 1.012127][ T1] pci 0002:01:00.0: BAR 3: assigned [mem 0x220002000000-0x220002007fff 64bit pref] > [ 4.399588][ T12] i40e 0002:01:00.0: enabling device (0140 -> 0142) > [ 4.410891][ T12] i40e 0002:01:00.0: fw 5.1.40981 api 1.5 nvm 5.03 0x80002469 1.1313.0 [8086:1589] [15d9:0000] > [ 4.647524][ T12] i40e 0002:01:00.0: MAC address: 0c:c4:7a:b7:fc:74 > [ 4.647685][ T12] i40e 0002:01:00.0: FW LLDP is enabled > [ 4.653918][ T12] i40e 0002:01:00.0 eth0: NIC Link is Up, 1000 Mbps Full Duplex, Flow Control: None > [ 4.655552][ T12] i40e 0002:01:00.0: PCI-Express: Speed 8.0GT/s Width x8 > [ 4.656071][ T12] i40e 0002:01:00.0: Features: PF-id[0] VSIs: 34 QP: 80 RSS FD_ATR FD_SB NTUPLE VxLAN Geneve PTP VEPA > [ 13.803709][ T1] Run /init as init process > [ 13.963242][ T711] i40e 0002:01:00.0 enP2p1s0f0: renamed from eth0 > > Building everything into the kernel is admittedly pretty niche. I only > do it to avoid re-building the initramfs for my test kernels. It does > seem relatively common on embedded systems, but I'm not sure how many > of those care about PCIe. It would be nice to provide *something* to > cover that case for the people who care. Those people who care should not build those drivers into their kernel :)