All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
	Vinod Koul <vkoul@kernel.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Eugeniy Paltsev <eugeniy.paltsev@synopsys.com>,
	Russell King <rmk+kernel@armlinux.org.uk>,
	Niklas Cassel <niklas.cassel@linaro.org>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Joao Pinto <joao.pinto@synopsys.com>,
	Jose Abreu <jose.abreu@synopsys.com>,
	Luis Oliveira <luis.oliveira@synopsys.com>,
	Vitor Soares <vitor.soares@synopsys.com>,
	Nelson Costa <nelson.costa@synopsys.com>,
	Pedro Sousa <pedrom.sousa@synopsys.com>
Subject: [RFC,v3,5/7] dmaengine: Add Synopsys eDMA IP PCIe glue-logic
Date: Sat, 19 Jan 2019 17:45:22 +0200	[thread overview]
Message-ID: <20190119154522.GD9170@smile.fi.intel.com> (raw)

On Tue, Jan 15, 2019 at 12:48:34PM +0000, Gustavo Pimentel wrote:
> On 15/01/2019 05:43, Andy Shevchenko wrote:
> > On Mon, Jan 14, 2019 at 11:38:02AM +0000, Gustavo Pimentel wrote:
> >> On 11/01/2019 19:47, Andy Shevchenko wrote:
> >>> On Fri, Jan 11, 2019 at 07:33:41PM +0100, Gustavo Pimentel wrote:

> >>>> +static bool disable_msix;
> >>>> +module_param(disable_msix, bool, 0644);
> >>>> +MODULE_PARM_DESC(disable_msix, "Disable MSI-X interrupts");
> >>>
> >>> Why?!
> >>> We are no allow new module parameters without very strong arguments.
> >>
> >> Since this is a reference driver and might be used to test customized HW
> >> solutions, I added this parameter to allow the possibility to test the solution
> >> forcing the MSI feature binding. This is required specially if who will test
> >> this solution has a Root Complex with both features available (MSI and MSI-X),
> >> because the Kernel will give always preference to MSI-X binding (assuming that
> >> the EP has also both features available).
> > 
> > Yes, you may do it for testing purposes, but it doesn't fit the kernel standards.
> 
> Ok, but how should I proceed? May I leave it or substitute by another way to do
> it? If so, how?
> As I said, the intended is to be only used for this test case, on normal
> operation the parameter it should be always false.

Keep out-of-tree patch for your needs.

> >>>> +	if (!pdata) {
> >>>> +		dev_err(dev, "%s missing data structure\n", pci_name(pdev));
> >>>> +		return -EFAULT;
> >>>> +	}
> >>>
> >>> Useless check.
> >>
> >> Why? It's just a precaution, isn't it a good practice always to think of the
> >> worst case?
> > 
> > You just can put an implicit requirement of pdata rather than doing this
> 
> Ok, how can I do it? What I should add to the code to force that?

Not adding, removing. That's what I put before.

> 
> > useless check. I don't believe it would make sense to have NULL pdata for the
> > driver since it wouldn't be functional anyhow.
> 
> Yes, you're right without pdata the driver can't do anything.

WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
	Vinod Koul <vkoul@kernel.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Eugeniy Paltsev <eugeniy.paltsev@synopsys.com>,
	Russell King <rmk+kernel@armlinux.org.uk>,
	Niklas Cassel <niklas.cassel@linaro.org>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Joao Pinto <joao.pinto@synopsys.com>,
	Jose Abreu <jose.abreu@synopsys.com>,
	Luis Oliveira <luis.oliveira@synopsys.com>,
	Vitor Soares <vitor.soares@synopsys.com>,
	Nelson Costa <nelson.costa@synopsys.com>,
	Pedro Sousa <pedrom.sousa@synopsys.com>
Subject: Re: [RFC v3 5/7] dmaengine: Add Synopsys eDMA IP PCIe glue-logic
Date: Sat, 19 Jan 2019 17:45:22 +0200	[thread overview]
Message-ID: <20190119154522.GD9170@smile.fi.intel.com> (raw)
In-Reply-To: <9b887e39-9de3-2285-f3b4-174a72e6c4d3@synopsys.com>

On Tue, Jan 15, 2019 at 12:48:34PM +0000, Gustavo Pimentel wrote:
> On 15/01/2019 05:43, Andy Shevchenko wrote:
> > On Mon, Jan 14, 2019 at 11:38:02AM +0000, Gustavo Pimentel wrote:
> >> On 11/01/2019 19:47, Andy Shevchenko wrote:
> >>> On Fri, Jan 11, 2019 at 07:33:41PM +0100, Gustavo Pimentel wrote:

> >>>> +static bool disable_msix;
> >>>> +module_param(disable_msix, bool, 0644);
> >>>> +MODULE_PARM_DESC(disable_msix, "Disable MSI-X interrupts");
> >>>
> >>> Why?!
> >>> We are no allow new module parameters without very strong arguments.
> >>
> >> Since this is a reference driver and might be used to test customized HW
> >> solutions, I added this parameter to allow the possibility to test the solution
> >> forcing the MSI feature binding. This is required specially if who will test
> >> this solution has a Root Complex with both features available (MSI and MSI-X),
> >> because the Kernel will give always preference to MSI-X binding (assuming that
> >> the EP has also both features available).
> > 
> > Yes, you may do it for testing purposes, but it doesn't fit the kernel standards.
> 
> Ok, but how should I proceed? May I leave it or substitute by another way to do
> it? If so, how?
> As I said, the intended is to be only used for this test case, on normal
> operation the parameter it should be always false.

Keep out-of-tree patch for your needs.

> >>>> +	if (!pdata) {
> >>>> +		dev_err(dev, "%s missing data structure\n", pci_name(pdev));
> >>>> +		return -EFAULT;
> >>>> +	}
> >>>
> >>> Useless check.
> >>
> >> Why? It's just a precaution, isn't it a good practice always to think of the
> >> worst case?
> > 
> > You just can put an implicit requirement of pdata rather than doing this
> 
> Ok, how can I do it? What I should add to the code to force that?

Not adding, removing. That's what I put before.

> 
> > useless check. I don't believe it would make sense to have NULL pdata for the
> > driver since it wouldn't be functional anyhow.
> 
> Yes, you're right without pdata the driver can't do anything.

-- 
With Best Regards,
Andy Shevchenko



             reply	other threads:[~2019-01-19 15:45 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-19 15:45 Andy Shevchenko [this message]
2019-01-19 15:45 ` [RFC v3 5/7] dmaengine: Add Synopsys eDMA IP PCIe glue-logic Andy Shevchenko
  -- strict thread matches above, loose matches on Subject: below --
2019-02-06 18:06 [RFC,v3,1/7] dmaengine: Add Synopsys eDMA IP core driver Gustavo Pimentel
2019-02-06 18:06 ` [RFC v3 1/7] " Gustavo Pimentel
2019-02-02 10:07 [RFC,v3,1/7] " Vinod Koul
2019-02-02 10:07 ` [RFC v3 1/7] " Vinod Koul
2019-02-01 11:23 [RFC,v3,1/7] " Gustavo Pimentel
2019-02-01 11:23 ` [RFC v3 1/7] " Gustavo Pimentel
2019-02-01  4:14 [RFC,v3,1/7] " Vinod Koul
2019-02-01  4:14 ` [RFC v3 1/7] " Vinod Koul
2019-01-31 11:33 [RFC,v3,1/7] " Gustavo Pimentel
2019-01-31 11:33 ` [RFC v3 1/7] " Gustavo Pimentel
2019-01-23 13:08 [RFC,v3,1/7] " Vinod Koul
2019-01-23 13:08 ` [RFC v3 1/7] " Vinod Koul
2019-01-21 15:59 [RFC,v3,7/7] dmaengine: Add Synopsys eDMA IP test and sample driver Gustavo Pimentel
2019-01-21 15:59 ` [RFC v3 7/7] " Gustavo Pimentel
2019-01-21 15:49 [RFC,v3,1/7] dmaengine: Add Synopsys eDMA IP core driver Gustavo Pimentel
2019-01-21 15:49 ` [RFC v3 1/7] " Gustavo Pimentel
2019-01-21 15:48 [RFC,v3,1/7] " Gustavo Pimentel
2019-01-21 15:48 ` [RFC v3 1/7] " Gustavo Pimentel
2019-01-21  9:21 [RFC,v3,5/7] dmaengine: Add Synopsys eDMA IP PCIe glue-logic Gustavo Pimentel
2019-01-21  9:21 ` [RFC v3 5/7] " Gustavo Pimentel
2019-01-21  9:14 [RFC,v3,1/7] dmaengine: Add Synopsys eDMA IP core driver Gustavo Pimentel
2019-01-21  9:14 ` [RFC v3 1/7] " Gustavo Pimentel
2019-01-20 11:47 [RFC,v3,1/7] " Vinod Koul
2019-01-20 11:47 ` [RFC v3 1/7] " Vinod Koul
2019-01-20 11:44 [RFC,v3,1/7] " Vinod Koul
2019-01-20 11:44 ` [RFC v3 1/7] " Vinod Koul
2019-01-19 16:21 [RFC,v3,1/7] " Andy Shevchenko
2019-01-19 16:21 ` [RFC v3 1/7] " Andy Shevchenko
2019-01-17  5:03 [RFC,v3,7/7] dmaengine: Add Synopsys eDMA IP test and sample driver Vinod Koul
2019-01-17  5:03 ` [RFC v3 7/7] " Vinod Koul
2019-01-16 14:02 [RFC,v3,2/7] dmaengine: Add Synopsys eDMA IP version 0 support Gustavo Pimentel
2019-01-16 14:02 ` [RFC v3 2/7] " Gustavo Pimentel
2019-01-16 11:56 [RFC,v3,7/7] dmaengine: Add Synopsys eDMA IP test and sample driver Gustavo Pimentel
2019-01-16 11:56 ` [RFC v3 7/7] " Gustavo Pimentel
2019-01-16 11:53 [RFC,v3,1/7] dmaengine: Add Synopsys eDMA IP core driver Gustavo Pimentel
2019-01-16 11:53 ` [RFC v3 1/7] " Gustavo Pimentel
2019-01-16 10:45 [RFC,v3,7/7] dmaengine: Add Synopsys eDMA IP test and sample driver Jose Abreu
2019-01-16 10:45 ` [RFC v3 7/7] " Jose Abreu
2019-01-16 10:33 [RFC,v3,2/7] dmaengine: Add Synopsys eDMA IP version 0 support Jose Abreu
2019-01-16 10:33 ` [RFC v3 2/7] " Jose Abreu
2019-01-16 10:21 [RFC,v3,1/7] dmaengine: Add Synopsys eDMA IP core driver Jose Abreu
2019-01-16 10:21 ` [RFC v3 1/7] " Jose Abreu
2019-01-15 13:02 [RFC,v3,7/7] dmaengine: Add Synopsys eDMA IP test and sample driver Gustavo Pimentel
2019-01-15 13:02 ` [RFC v3 7/7] " Gustavo Pimentel
2019-01-15 12:48 [RFC,v3,5/7] dmaengine: Add Synopsys eDMA IP PCIe glue-logic Gustavo Pimentel
2019-01-15 12:48 ` [RFC v3 5/7] " Gustavo Pimentel
2019-01-15  5:45 [RFC,v3,7/7] dmaengine: Add Synopsys eDMA IP test and sample driver Andy Shevchenko
2019-01-15  5:45 ` [RFC v3 7/7] " Andy Shevchenko
2019-01-15  5:43 [RFC,v3,5/7] dmaengine: Add Synopsys eDMA IP PCIe glue-logic Andy Shevchenko
2019-01-15  5:43 ` [RFC v3 5/7] " Andy Shevchenko
2019-01-14 14:41 [RFC,v3,4/7] PCI: Add Synopsys endpoint EDDA Device id Bjorn Helgaas
2019-01-14 14:41 ` [RFC v3 4/7] " Bjorn Helgaas
2019-01-14 11:44 [RFC,v3,7/7] dmaengine: Add Synopsys eDMA IP test and sample driver Gustavo Pimentel
2019-01-14 11:44 ` [RFC v3 7/7] " Gustavo Pimentel
2019-01-14 11:38 [RFC,v3,5/7] dmaengine: Add Synopsys eDMA IP PCIe glue-logic Gustavo Pimentel
2019-01-14 11:38 ` [RFC v3 5/7] " Gustavo Pimentel
2019-01-11 19:48 [RFC,v3,7/7] dmaengine: Add Synopsys eDMA IP test and sample driver Andy Shevchenko
2019-01-11 19:48 ` [RFC v3 7/7] " Andy Shevchenko
2019-01-11 19:47 [RFC,v3,5/7] dmaengine: Add Synopsys eDMA IP PCIe glue-logic Andy Shevchenko
2019-01-11 19:47 ` [RFC v3 5/7] " Andy Shevchenko
2019-01-11 18:33 [RFC,v3,7/7] dmaengine: Add Synopsys eDMA IP test and sample driver Gustavo Pimentel
2019-01-11 18:33 ` [RFC v3 7/7] " Gustavo Pimentel
2019-01-11 18:33 [RFC,v3,6/7] MAINTAINERS: Add Synopsys eDMA IP driver maintainer Gustavo Pimentel
2019-01-11 18:33 ` [RFC v3 6/7] " Gustavo Pimentel
2019-01-11 18:33 [RFC,v3,5/7] dmaengine: Add Synopsys eDMA IP PCIe glue-logic Gustavo Pimentel
2019-01-11 18:33 ` [RFC v3 5/7] " Gustavo Pimentel
2019-01-11 18:33 [RFC,v3,4/7] PCI: Add Synopsys endpoint EDDA Device id Gustavo Pimentel
2019-01-11 18:33 ` [RFC v3 4/7] " Gustavo Pimentel
2019-01-11 18:33 [RFC,v3,3/7] dmaengine: Add Synopsys eDMA IP version 0 debugfs support Gustavo Pimentel
2019-01-11 18:33 ` [RFC v3 3/7] " Gustavo Pimentel
2019-01-11 18:33 [RFC,v3,2/7] dmaengine: Add Synopsys eDMA IP version 0 support Gustavo Pimentel
2019-01-11 18:33 ` [RFC v3 2/7] " Gustavo Pimentel
2019-01-11 18:33 [RFC,v3,1/7] dmaengine: Add Synopsys eDMA IP core driver Gustavo Pimentel
2019-01-11 18:33 ` [RFC v3 1/7] " Gustavo Pimentel
2019-01-11 18:33 [RFC v3 0/6] dmaengine: Add Synopsys eDMA IP driver (version 0) Gustavo Pimentel

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=20190119154522.GD9170@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=eugeniy.paltsev@synopsys.com \
    --cc=gustavo.pimentel@synopsys.com \
    --cc=joao.pinto@synopsys.com \
    --cc=jose.abreu@synopsys.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=luis.oliveira@synopsys.com \
    --cc=nelson.costa@synopsys.com \
    --cc=niklas.cassel@linaro.org \
    --cc=pedrom.sousa@synopsys.com \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=vitor.soares@synopsys.com \
    --cc=vkoul@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.