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]
Date:   Tue, 20 Jul 2021 17:13:53 +0530
From:   Vinod Koul <vkoul@...nel.org>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Kelvin Cheung <keguang.zhang@...il.com>, dmaengine@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH V5] dmaengine: Loongson1: Add Loongson1 dmaengine driver

On 17-07-21, 19:39, Greg KH wrote:
> On Sat, Jul 17, 2021 at 08:09:45PM +0530, Vinod Koul wrote:
> > On 17-07-21, 18:57, Kelvin Cheung wrote:
> > > Vinod Koul <vkoul@...nel.org> 于2021年7月14日周三 下午1:14写道:
> > > >
> > > > On 04-07-21, 23:33, Keguang Zhang wrote:
> > > >
> > > > > +static struct platform_driver ls1x_dma_driver = {
> > > > > +     .probe  = ls1x_dma_probe,
> > > > > +     .remove = ls1x_dma_remove,
> > > > > +     .driver = {
> > > > > +             .name   = "ls1x-dma",
> > > > > +     },
> > > > > +};
> > > > > +
> > > > > +module_platform_driver(ls1x_dma_driver);
> > > >
> > > > so my comment was left unanswered, who creates this device!
> > > 
> > > Sorry!
> > > This patch will create the device: https://patchwork.kernel.org/patch/12281691
> > 
> > Greg, looks like the above patch creates platform devices in mips, is
> > that the right way..?
> 
> I do not understand, what exactly is the question?

So this patch was adding Loongson1 dmaengine driver which is a platform
device. I asked about the platform device and was told that [1] creates
the platform device. I am not sure if that is the recommended way given
that you have been asking people to not use platform devices.

[1]: https://patchwork.kernel.org/patch/12281691

So is [1] the correct approach or should this be fixed?

-- 
~Vinod

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ