Re: [PATCH v2 5/7] driver core: Add device location to "struct device" and expose it in sysfs

Greg Kroah-Hartman
2020-07-02T08:53:23Z

On Thu, Jul 02, 2020 at 10:52:12AM +0200, Greg Kroah-Hartman wrote:
> 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 :)

That being said, that is the _last_ thing to worry about in this type of
patchset, lots of work needs to be done before we can care about this.
In fact, that should just be a totally separate patch after all of the
real work is done here first.

thanks,

greg k-h