linux-kernel - Re: [PATCHv5] dmaengine: Add support for BCM2835

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131116114134.GU16735@n2100.arm.linux.org.uk>
Date:	Sat, 16 Nov 2013 11:41:34 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Mark Brown <broonie@...nel.org>
Cc:	Andy Shevchenko <andy.shevchenko@...il.com>,
	"Shevchenko, Andriy" <andriy.shevchenko@...el.com>,
	Florian Meier <florian.meier@...lo.de>,
	"Koul, Vinod" <vinod.koul@...el.com>,
	"Williams, Dan J" <dan.j.williams@...el.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	dmaengine <dmaengine@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCHv5] dmaengine: Add support for BCM2835

On Sat, Nov 16, 2013 at 11:27:54AM +0000, Mark Brown wrote:
> On Sat, Nov 16, 2013 at 11:37:54AM +0200, Andy Shevchenko wrote:
> 
> > The reason why I was asking about I'm just wondering what we have to do
> > with existing drivers. Shall we convert them to be initialized as normal
> > platform drivers instead of subsys_initcall?
> 
> We should in general be moving in that direction however it does need a
> bit of care to make sure that there aren't any dependencies which do
> things like discard error codes, fail to check errors or treat errors as
> hard failures.

I don't agree: on platforms which have done this, it's very difficult to
tell from reading the kernel message log whether things came up correctly
because there's soo much spew from deferred probing it's virtually
impossible to tell whether component X initialised or whether that error
about resource Y missing was ever resolved.

The only way that can be checked is when things work (or don't) from
userspace.

It's soo bad on some platforms that reading the kernel boot log is a
total waste of time; you don't get any useful information from it.

If we want kernel boot logs to be useful, we really need to shut up *all*
the drivers and subsystems whinging about being deferred probing, and only
have the driver model core reporting this status - maybe only allow
output about why at debug level or similar.
--
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/