On Wed, Jul 26, 2017 at 01:02:38PM -0700, David Daney wrote: > On 07/26/2017 10:33 AM, Greg KH wrote: > > On Wed, Jul 26, 2017 at 06:30:49PM +0200, Borislav Petkov wrote: > > > On Wed, Jul 26, 2017 at 09:19:49AM -0700, Greg KH wrote: > > > > On Wed, Jul 26, 2017 at 05:55:48PM +0200, Borislav Petkov wrote: > > > > > On Wed, Jul 26, 2017 at 05:45:15PM +0200, Jan Glauber wrote: > > > > > > The PMU/EDAC devices are all PCI devices do I need the 'struct pci_dev *'. > > > > > > I'm not aware of other ways to access these devices. Please enlighten > > > > > > me if I'm missing something. > > > > > > > > > > Me enlighten you on Cavium hardware?! You're funny. > > > > > > > > > > So I don't know whether the PCI hotplug code can run more than one > > > > > function upon PCI ID detection. Probably Greg will say, write a > > > > > multiplexer wrapper. :-) > > > > > > > > -ENOCONTEXT.... > > > > > > > > Anyway, pci questions are best asked on the linux-pci@vger list. And > > > > yes, all PCI devices end up with a 'struct pci_dev *' automatically. > > > > > > Simple: so they have a PCI ID of a memory contoller and want to hotplug > > > two drivers for it. And those two drivers should remain independent from > > > each other. > > > > Hahahahaha, no. That's crazy, you were right in guessing what my answer > > was going to be :) > > > > > Just to be clear about the situation, the device is a memory controller. It > has two main behaviors we are interested in: > > A) Error Detection And Correction (EDAC). This should be connected to the > kernel's EDAC subsystem. An existing driver (drivers/edac/thunderx_edac.c) > does exactly this. > > B) Performance Counters for actions taken in the corresponding memory. This > should be connected to the kernel's perf framework as an uncore-PMU (the > subject of this patch set). > > It is a single PCI device. What should the driver architecture look like to > connect it to two different kernel subsystems? Modify the drivers/edac/thunderx_edac.c code to add support for performance counters.
