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
next 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: linkBe 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.