| 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
| ||
|
Message-ID: <alpine.LNX.2.00.1507051141370.15162@localhost.localdomain>
Date: Sun, 5 Jul 2015 11:45:56 +0200 (CEST)
From: Paul Osmialowski <pawelo@...g.net.pl>
To: Vinod Koul <vinod.koul@...el.com>
cc: Paul Osmialowski <pawelo@...g.net.pl>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Jiri Slaby <jslaby@...e.cz>, Kumar Gala <galak@...eaurora.org>,
Linus Walleij <linus.walleij@...aro.org>,
Mark Rutland <mark.rutland@....com>,
Michael Turquette <mturquette@...libre.com>,
Pawel Moll <pawel.moll@....com>,
Rob Herring <robh+dt@...nel.org>,
Russell King <linux@....linux.org.uk>,
Stephen Boyd <sboyd@...eaurora.org>,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-clk@...r.kernel.org, linux-gpio@...r.kernel.org,
linux-serial@...r.kernel.org, devicetree@...r.kernel.org,
dmaengine@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Nicolas Pitre <nicolas.pitre@...aro.org>,
Paul Bolle <pebolle@...cali.nl>,
Thomas Gleixner <tglx@...utronix.de>,
Uwe Kleine-Koenig <u.kleine-koenig@...gutronix.de>,
Anson Huang <b20788@...escale.com>,
Frank Li <Frank.Li@...escale.com>,
Jingchang Lu <jingchang.lu@...escale.com>,
Rob Herring <r.herring@...escale.com>,
Yuri Tikhonov <yur@...raft.com>,
Sergei Poselenov <sposelenov@...raft.com>,
Alexander Potashev <aspotashev@...raft.com>
Subject: Re: [PATCH v2 6/9] arm: twr-k70f120m: extend Freescale eDMA driver
with the ability to support Kinetis SoC
Hi Vinod,
You're right, this should be separate patchset. Having patchset too big
leads to huge list of maintainers and lack of focusing on details
(on-error return values are total mess now!).
I plan to split it into three: 1) initial support (so the proof that
platform is living could be read only on JTAG), 2) DMA support and 3) UART
support.
Also in my view extending this DMA driver requires acceptance of initial
platform support first - there's no point in extending this driver without
having support for a platform for which we are extending it.
Thanks,
Paul
On Sun, 5 Jul 2015, Vinod Koul wrote:
> On Tue, Jun 30, 2015 at 02:27:27PM +0200, Paul Osmialowski wrote:
> The patch title is not per subsystem semantics, pls fix that
>
>> Surprisingly small amount of work was required in order to extend already
>> existing eDMA driver with the support for Kinetis SoC architecture.
> And this doesn't tell me the stuff you added/removed/fixed in current driver
> to extend to Kinetis. Our changelog should tell what changed and why
>
> Btw is this patch dependent upon the rest of the series?
>
>>
>> static int
>> -fsl_edma_irq_init(struct platform_device *pdev, struct fsl_edma_engine *fsl_edma)
>> +fsl_edma_irq_init(struct platform_device *pdev,
>> + struct fsl_edma_engine *fsl_edma)
> please keep style changes in a separate patch
>
>> {
>> + struct device_node *np = pdev->dev.of_node;
>> + int irq, errirq;
>> int ret;
>>
>> - fsl_edma->txirq = platform_get_irq_byname(pdev, "edma-tx");
>> - if (fsl_edma->txirq < 0) {
>> - dev_err(&pdev->dev, "Can't get edma-tx irq.\n");
>> - return fsl_edma->txirq;
>> - }
>> -
>> - fsl_edma->errirq = platform_get_irq_byname(pdev, "edma-err");
>> - if (fsl_edma->errirq < 0) {
>> + errirq = platform_get_irq_byname(pdev, "edma-err");
>> + if (errirq < 0) {
>> dev_err(&pdev->dev, "Can't get edma-err irq.\n");
>> - return fsl_edma->errirq;
>> + return irq;
> shouldn't this be errirq
>
>> }
>>
>> - if (fsl_edma->txirq == fsl_edma->errirq) {
>> - ret = devm_request_irq(&pdev->dev, fsl_edma->txirq,
>> - fsl_edma_irq_handler, 0, "eDMA", fsl_edma);
>> - if (ret) {
>> - dev_err(&pdev->dev, "Can't register eDMA IRQ.\n");
>> - return ret;
>> + if (fsl_edma->kinetis) {
>> + int i;
>> + int irqs = of_irq_count(np);
>> +
>> + if (irqs <= 1) {
>> + dev_err(&pdev->dev, "Wrong eDMA irq count %d\n", irqs);
>> + return -EINVAL;
> why not return irqs?
>
>> }
>> - } else {
>> - ret = devm_request_irq(&pdev->dev, fsl_edma->txirq,
>> +
>> + for (i = 0; i < (irqs - 1); i++) {
>> + char irq_name[32];
>> +
>> + sprintf(irq_name, "edma-tx-%d,%d", i, 16 + i);
>> + irq = platform_get_irq_byname(pdev, irq_name);
>> + if (irq < 0) {
>> + dev_err(&pdev->dev, "Can't get %s irq.\n",
>> + irq_name);
>> + return irq;
>> + }
>> +
>> + ret = devm_request_irq(&pdev->dev, irq,
>> fsl_edma_tx_handler, 0, "eDMA tx", fsl_edma);
>> - if (ret) {
>> - dev_err(&pdev->dev, "Can't register eDMA tx IRQ.\n");
>> - return ret;
>> + if (ret) {
>> + dev_err(&pdev->dev, "Can't register %s IRQ.\n",
>> + irq_name);
>> + return ret;
>> + }
>> }
>>
>> - ret = devm_request_irq(&pdev->dev, fsl_edma->errirq,
>> - fsl_edma_err_handler, 0, "eDMA err", fsl_edma);
>> + ret = devm_request_irq(&pdev->dev, errirq,
>> + fsl_edma_err_handler, 0, "eDMA err", fsl_edma);
>> if (ret) {
>> dev_err(&pdev->dev, "Can't register eDMA err IRQ.\n");
>> - return ret;
>> + return ret;
>> + }
>> + } else {
>> + irq = platform_get_irq_byname(pdev, "edma-tx");
>> + if (irq < 0) {
>> + dev_err(&pdev->dev, "Can't get edma-tx irq.\n");
>> + return irq;
>> + }
>> +
>> + if (irq == errirq) {
>> + ret = devm_request_irq(&pdev->dev, irq,
>> + fsl_edma_irq_handler, 0, "eDMA", fsl_edma);
>> + if (ret) {
>> + dev_err(&pdev->dev,
>> + "Can't register eDMA IRQ.\n");
>> + return ret;
>> + }
>> + } else {
>> + ret = devm_request_irq(&pdev->dev, irq,
>> + fsl_edma_tx_handler, 0, "eDMA tx", fsl_edma);
>> + if (ret) {
>> + dev_err(&pdev->dev,
>> + "Can't register eDMA tx IRQ.\n");
>> + return ret;
>> + }
>> +
>> + ret = devm_request_irq(&pdev->dev, errirq,
>> + fsl_edma_err_handler, 0, "eDMA err", fsl_edma);
>> + if (ret) {
>> + dev_err(&pdev->dev,
>> + "Can't register eDMA err IRQ.\n");
>> + return ret;
>> + }
>> }
>> }
> Okay here we have a bunch of changes without explanation on why these are
> required and what are they supposed to do. So it is kind of very difficult to
> review!
>
> So please split these up in sequence of patches where each patch does only
> ONE thing with right changelog messages
>
> Thanks
>
> --
> ~Vinod
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists