[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b27cda60-8bf8-47a1-15b5-bf8b3a83fc45@gmail.com>
Date: Wed, 26 Jul 2017 14:02:42 -0700
From: David Daney <ddaney.cavm@...il.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Borislav Petkov <bp@...en8.de>,
Mark Rutland <mark.rutland@....com>,
Suzuki K Poulose <Suzuki.Poulose@....com>,
linux-pci@...r.kernel.org, Will Deacon <will.deacon@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Jan Glauber <jan.glauber@...iumnetworks.com>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v8 1/3] perf: cavium: Support memory controller PMU
counters
On 07/26/2017 01:08 PM, Greg KH wrote:
> 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@...r 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.
>
Thanks Greg. This adds some clarity to the situation.
This technique does slightly complicate the mapping of files and
directories in the kernel source tree to maintainers.
Also, if a given configuration disables CONFIG_EDAC there is some
hackery needed to get the perf portion of the driver included.
David Daney
Powered by blists - more mailing lists