From: Oliver O'Halloran <oohall@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Rajat Jain <rajatja@google.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
David Woodhouse <dwmw2@infradead.org>,
Lu Baolu <baolu.lu@linux.intel.com>,
Joerg Roedel <joro@8bytes.org>,
Bjorn Helgaas <bhelgaas@google.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Len Brown <lenb@kernel.org>,
"open list:AMD IOMMU (AMD-VI)" <iommu@lists.linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux PCI <linux-pci@vger.kernel.org>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
Raj Ashok <ashok.raj@intel.com>,
"Krishnakumar,
Lalithambika" <lalithambika.krishnakumar@intel.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Jean-Philippe Brucker <jean-philippe@linaro.org>,
Prashant Malani <pmalani@google.com>,
Benson Leung <bleung@google.com>, Todd Broch <tbroch@google.com>,
Alex Levin <levinale@google.com>,
Mattias Nissler <mnissler@google.com>,
Rajat Jain <rajatxjain@gmail.com>,
Bernie Keany <bernie.keany@intel.com>,
Aaron Durbin <adurbin@google.com>,
Diego Rivas <diegorivas@google.com>,
Duncan Laurie <dlaurie@google.com>,
Furquan Shaikh <furquan@google.com>,
Jesse Barnes <jsbarnes@google.com>,
Christian Kellner <christian@kellner.me>,
Alex Williamson <alex.williamson@redhat.com>,
Saravana Kannan <saravanak@google.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH v2 5/7] driver core: Add device location to "struct device" and expose it in sysfs
Date: Thu, 02 Jul 2020 18:40:09 +1000 [thread overview]
Message-ID: <24f56c0ed6d10ef565cf83d47d0538d37ac0d8ef.camel@gmail.com> (raw)
In-Reply-To: <20200702073226.GB1073011@kroah.com>
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.
Oliver
next prev parent reply other threads:[~2020-07-02 8:40 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-30 4:49 [PATCH v2 0/7] Tighten PCI security, expose dev location in sysfs Rajat Jain
2020-06-30 4:49 ` [PATCH v2 1/7] PCI: Keep the ACS capability offset in device Rajat Jain
2020-07-06 15:58 ` Bjorn Helgaas
2020-07-06 22:16 ` Rajat Jain
2020-07-06 23:18 ` Bjorn Helgaas
2020-06-30 4:49 ` [PATCH v2 2/7] PCI: Set "untrusted" flag for truly external devices only Rajat Jain
2020-06-30 7:38 ` Lu Baolu
2020-06-30 7:55 ` Greg Kroah-Hartman
2020-07-06 16:41 ` Bjorn Helgaas
2020-07-06 18:48 ` Greg Kroah-Hartman
2020-07-06 16:38 ` Bjorn Helgaas
2020-07-06 22:31 ` Rajat Jain
2020-07-06 23:30 ` Bjorn Helgaas
2020-07-06 23:40 ` Rajat Jain
2020-06-30 4:49 ` [PATCH v2 3/7] PCI/ACS: Enable PCI_ACS_TB for untrusted/external-facing devices Rajat Jain
2020-07-06 16:45 ` Bjorn Helgaas
2020-07-06 23:12 ` Rajat Jain
2020-07-06 17:07 ` Bjorn Helgaas
2020-07-06 23:19 ` Rajat Jain
2020-06-30 4:49 ` [PATCH v2 4/7] PCI: Add device even if driver attach failed Rajat Jain
2020-06-30 8:02 ` Greg Kroah-Hartman
2020-07-06 23:35 ` Rajat Jain
2020-06-30 4:49 ` [PATCH v2 5/7] driver core: Add device location to "struct device" and expose it in sysfs Rajat Jain
2020-06-30 8:01 ` Greg Kroah-Hartman
2020-06-30 10:49 ` Heikki Krogerus
2020-06-30 12:52 ` Greg Kroah-Hartman
2020-06-30 13:00 ` Rafael J. Wysocki
2020-06-30 15:38 ` Greg Kroah-Hartman
2020-06-30 16:08 ` Rafael J. Wysocki
2020-06-30 17:00 ` Greg Kroah-Hartman
2020-07-01 18:06 ` Rajat Jain
2020-07-02 5:23 ` Oliver O'Halloran
2020-07-02 7:32 ` Greg Kroah-Hartman
2020-07-02 8:40 ` Oliver O'Halloran [this message]
2020-07-02 8:52 ` Greg Kroah-Hartman
2020-07-02 8:53 ` Greg Kroah-Hartman
2020-07-07 6:03 ` Rajat Jain
2020-06-30 17:43 ` Saravana Kannan
2020-06-30 4:49 ` [PATCH v2 6/7] PCI: Move pci_dev->untrusted logic to use device location instead Rajat Jain
2020-06-30 7:39 ` Lu Baolu
2020-06-30 4:49 ` [PATCH v2 7/7] PCI: Add parameter to disable attaching external devices Rajat Jain
2020-07-04 11:44 ` [PATCH v2 0/7] Tighten PCI security, expose dev location in sysfs Pavel Machek
2020-07-06 22:18 ` Rajat Jain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=24f56c0ed6d10ef565cf83d47d0538d37ac0d8ef.camel@gmail.com \
--to=oohall@gmail.com \
--cc=adurbin@google.com \
--cc=alex.williamson@redhat.com \
--cc=arnd@arndb.de \
--cc=ashok.raj@intel.com \
--cc=baolu.lu@linux.intel.com \
--cc=bernie.keany@intel.com \
--cc=bhelgaas@google.com \
--cc=bleung@google.com \
--cc=christian@kellner.me \
--cc=diegorivas@google.com \
--cc=dlaurie@google.com \
--cc=dwmw2@infradead.org \
--cc=furquan@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jean-philippe@linaro.org \
--cc=joro@8bytes.org \
--cc=jsbarnes@google.com \
--cc=lalithambika.krishnakumar@intel.com \
--cc=lenb@kernel.org \
--cc=levinale@google.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=mnissler@google.com \
--cc=pmalani@google.com \
--cc=rafael@kernel.org \
--cc=rajatja@google.com \
--cc=rajatxjain@gmail.com \
--cc=rjw@rjwysocki.net \
--cc=saravanak@google.com \
--cc=suzuki.poulose@arm.com \
--cc=tbroch@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).