linux-kernel - Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180501115417.GD19391@e107981-ln.cambridge.arm.com>
Date:   Tue, 1 May 2018 12:54:17 +0100
From:   Lorenzo Pieralisi <lorenzo.pieralisi@....com>
To:     Kishon Vijay Abraham I <kishon@...com>
Cc:     Gustavo Pimentel <gustavo.pimentel@...opsys.com>,
        bhelgaas@...gle.com, Joao.Pinto@...opsys.com, jingoohan1@...il.com,
        robh+dt@...nel.org, mark.rutland@....com,
        linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second
 entry

On Tue, May 01, 2018 at 03:37:47PM +0530, Kishon Vijay Abraham I wrote:
> Hi Lorenzo,
> 
> On Thursday 26 April 2018 10:26 PM, Lorenzo Pieralisi wrote:
> > On Tue, Apr 24, 2018 at 02:44:40PM +0100, Gustavo Pimentel wrote:
> >> Adds a seconds entry on the pci_epf_test_ids structure that disables the
> > 
> > "Add a second entry to..."
> > 
> >> linkup_notifier parameter on driver for the designware EP.
> >>
> >> This allows designware EPs that doesn't have linkup notification signal
> >> to work with pcitest.
> >>
> >> Updates the binding documentation accordingly.
> > 
> > Valid for all the series: use imperative sentences.
> > 
> > eg:
> > 
> > "Update the binding documentation accordingly".
> > 
> > not
> > 
> > "Updates the binding documentation accordingly".
> > 
> >> Signed-off-by: Gustavo Pimentel <gustavo.pimentel@...opsys.com>
> >> Acked-by: Kishon Vijay Abraham I <kishon@...com>
> >> ---
> >> Change v2->v3:
> >>  - Added second entry in pci_epf_test_ids structure.
> >>  - Remove test_reg_bar field assignment on second entry.
> >> Changes v3->v4:
> >>  - Nothing changed, just to follow the patch set version.
> >> Changes v4->v5:
> >>  - Changed pci_epf_test_cfg2 to pci_epf_test_designware.
> >> Changes v5->v6:
> >>  - Changed name field from pci_epf_test_designware to pci_epf_test_dw.
> >> Changes v6->v7:
> >>  - Changed variable name from data_cfg2 to data_linkup_notifier_disabled.
> >>
> >>  Documentation/PCI/endpoint/function/binding/pci-test.txt | 2 ++
> >>  drivers/pci/endpoint/functions/pci-epf-test.c            | 8 ++++++++
> >>  2 files changed, 10 insertions(+)
> >>
> >> diff --git a/Documentation/PCI/endpoint/function/binding/pci-test.txt b/Documentation/PCI/endpoint/function/binding/pci-test.txt
> >> index 3b68b95..dc39f47 100644
> >> --- a/Documentation/PCI/endpoint/function/binding/pci-test.txt
> >> +++ b/Documentation/PCI/endpoint/function/binding/pci-test.txt
> >> @@ -1,6 +1,8 @@
> >>  PCI TEST ENDPOINT FUNCTION
> >>  
> >>  name: Should be "pci_epf_test" to bind to the pci_epf_test driver.
> >> +name: Should be "pci_epf_test_dw" to bind to the pci_epf_test driver
> >> +      with a custom configuration for the designware EP.
> > 
> > The link between the "name" and the device created is quite obscure and
> > reading pci-test-howto.txt certainly does not clarify it.
> > 
> > In pci-test-howto.txt an explanation should be added to the configs
> > device creation paragraph to clarify it.
> > 
> >>  Configurable Fields:
> >>  vendorid	 : should be 0x104c
> >> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
> >> index 7cef851..4ab463b 100644
> >> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> >> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> >> @@ -459,10 +459,18 @@ static int pci_epf_test_bind(struct pci_epf *epf)
> >>  	return 0;
> >>  }
> >>  
> >> +static const struct pci_epf_test_data data_linkup_notifier_disabled = {
> >> +	.linkup_notifier = false
> >> +};
> >> +
> >>  static const struct pci_epf_device_id pci_epf_test_ids[] = {
> >>  	{
> >>  		.name = "pci_epf_test",
> >>  	},
> >> +	{
> >> +		.name = "pci_epf_test_dw",
> >> +		.driver_data = (kernel_ulong_t)&data_linkup_notifier_disabled,
> >> +	},
> >>  	{},
> > 
> > Should not this be a property derived from the controller compatible
> > property instead of the test device name written in configfs ?
> 
> pci_epf_test is an independent driver on its own that operates in a layer above
> the controller driver. So it does not get the controller compatible (which is
> used in controller drivers like pcie-designware-plat.c). pci_epf_test uses
> "pci_epf_device_id" which is _similar_ to "of_device_id" used by platform drivers.

I understand that, the problem is that the independent driver depends on
features of the related controller driver as this patch shows. This
patch basically says that if you use a specific path in configfs (that
includes pci_epf_test_dw) your device has specific HW features (eg
linkup notifier above), that obviously depends on the platform HW not on
the string you use in configfs.

What I am questioning is a) if I understand this right and b) whether
this is the right approach.

Lorenzo