linux-kernel - Re: [PATCHv2 2/4] dmaengine: dw_dmac: Add PCI part of the driver

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: <201209261941.11944.arnd@arndb.de>
Date:	Wed, 26 Sep 2012 19:41:11 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Andy Shevchenko <andy.shevchenko@...il.com>
Cc:	viresh kumar <viresh.kumar@...aro.org>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Vinod Koul <vinod.koul@...el.com>,
	linux-kernel@...r.kernel.org,
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
	"spear-devel" <spear-devel@...t.st.com>
Subject: Re: [PATCHv2 2/4] dmaengine: dw_dmac: Add PCI part of the driver

On Wednesday 26 September 2012, Andy Shevchenko wrote:
> On Wed, Sep 26, 2012 at 5:33 PM, viresh kumar <viresh.kumar@...aro.org> wrote:
> > On Wed, Sep 26, 2012 at 6:10 PM, Andy Shevchenko
> > <andriy.shevchenko@...ux.intel.com> wrote:
> >> diff --git a/drivers/dma/dw_dmac_pci.c b/drivers/dma/dw_dmac_pci.c
> >> +#include <linux/module.h>
> >> +#include <linux/pci.h>
> >> +#include <linux/platform_device.h>
> >> +#include <linux/dw_dmac.h>
> >> +
> >> +#define DRIVER(_is_private, _chan_order, _chan_pri)            \
> >> +       ((kernel_ulong_t)&(struct dw_dma_platform_data) {       \
> >> +               .is_private = (_is_private),                    \
> >> +               .chan_allocation_order = (_chan_order),         \
> >> +               .chan_priority = (_chan_pri),                   \
> >
> > I believe you don't need these braces around input variables on right side
> > of "=". Even if there is something complex passed.
> Hmm... Have no idea if anyone will use robust stuff as a parameter to
> that macro. I could remove them.

IMHO It's better to leave them in as general practice in case of a macro.

However, I would prefer not having this macro at all and just open-code
the contents. If you use traditional struct initializers, the amount of
code is almost exactly the same.

> 
> >> +       pd = platform_device_alloc("dw_dmac", instance);
> >> +       if (!pd) {
> >> +               dev_err(&pdev->dev, "can't allocate dw_dmac platform device\n");
> >> +               ret = -ENOMEM;
> >> +               goto err0;
> >> +       }
> >
> > Is this the correct approach? I doubt... We are creating a platform
> > device from a
> > pci driver... Don't know if it can lead to some issues within kernel.
> >
> > Lets call the specialist for his comments  :)
> > @Arnd: Can you please help us here?
> This approach is used among different drivers in kernel. As first
> example that comes to my mind you could consider chipidea USB driver
> (drivers/usb/chipidea).

Yes, this is fine for a PCI device with multiple logical devices. You could
also use the MFD framework if that results in smaller code. For a driver
that can be either a platform device or a pci device with no other sub-devices,
I would however recommend having a common initialization function for stuff
that can be called from either bus_type but with no extra level of indirection.

	Arnd
--
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/