linux-kernel - Re: [resend][PATCH 01/16] dw_dmac: call .probe after we have a device in place

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: <20130109153848.GT19691@intel.com>
Date:	Wed, 9 Jan 2013 07:38:48 -0800
From:	Vinod Koul <vinod.koul@...el.com>
To:	Andy Shevchenko <andy.shevchenko@...il.com>,
	Linus Walleij <linus.walleij@...aro.org>
Cc:	Andy Shevchenko <andriy.shevchenko@...ux.jf.intel.com>,
	linux-kernel@...r.kernel.org,
	Viresh Kumar <viresh.kumar@...aro.org>,
	spear-devel <spear-devel@...t.st.com>
Subject: Re: [resend][PATCH 01/16] dw_dmac: call .probe after we have a
 device in place

On Wed, Jan 09, 2013 at 04:56:45PM +0200, Andy Shevchenko wrote:
> On Wed, Jan 9, 2013 at 3:47 PM, Vinod Koul <vinod.koul@...el.com> wrote:
> > On Wed, Jan 09, 2013 at 10:17:00AM +0200, Andy Shevchenko wrote:
> >> If we don't yet have the platform device for the driver when it is being loaded
> >> we fail to probe the driver. So instead of calling probe() directly we call
> >> platform_driver_register(). It will call the probe() immediately if we have the
> >> device but also makes the driver to work on platforms where the platform device
> >> is created later.
> > Why wont you have the platform device?
> 
> It's still the same device as before. The only difference is in
> boot/initialization sequence.
> 
> > Is this only due to your approach of
> > creating the device in PCI probe?
> 
> No. We had an issue when driver was initialized (and with old version
> immediately probed)
> just before it happened in the platform devices. In such case .probe() fails.
> Above patch makes sure that platform devices are already in the
> internal structures and we could match them safely.
hmmm, but that its still not clear why that would happen. Driver init is called
later when all device creation should already be done.

> >>  }
> >>  subsys_initcall(dw_init);
Viresh, Linus

We had this discussion sometime back. pl022 use dma and we need DMA before SPI.
So if we have pl022 as late_init and dma as device_init. If we have one  more
dependency then moving dw_dmac to fs_init should help too. But arch/subsys seems
overkill here?

--
~Vinod


why is dw_dmac a subsys init. One reason could be ensure these are before before
the client devices, but 
--
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/