linux-kernel - Re: [RFC 2/4] driver core: Allow early registration of devices

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:	Mon, 19 Aug 2013 13:49:18 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Tomasz Figa <tomasz.figa@...il.com>
CC:	Grant Likely <grant.likely@...aro.org>,
	Thierry Reding <thierry.reding@...il.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Rob Herring <rob.herring@...xeda.com>,
	Hiroshi Doyu <hdoyu@...dia.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC 2/4] driver core: Allow early registration of devices

On 08/17/2013 04:26 AM, Tomasz Figa wrote:
...
> Please correct me if I'm wrong, but to get to initcalls you need a timer. 
> However a timer driver might need interrupts (to tick) and clocks (to get 
> the frequency).
> 
> At least this is what happens on the platforms I work with. They don't 
> need any special early registration method, though. We just special case 
> those drivers, as Thierry pointed, so they don't use device based APIs.
> 
> However if we consider a more complex setup, let's say that the timer 
> driver needs to access some special registers, which are shared with other 
> drivers as well (again not a completely exotic case, as I already met this 
> when working with timer and PWM drivers for older Samsung platforms and 
> had to hack things a bit). One would suggest using regmap here, but it is 
> a device based API.

To take this even further, I'm not sure there's a particular reason why
the timer has to have an internal clock source driven from the same chip
clock input as the CPU itself. What if there's a separate clock input,
whose source chip has an enable input, which is connected to a GPIO,
which is driven by an I2C-based GPIO expander? Admittedly that's a
pretty crazy HW design, but I doubt it's much other than an accident
that it doesn't exist in practice, given the probable lack of feedback
cycle from Linux SW internals to all board designers.

It seems like the best solution here is to make the generic case fully
capable. Perhaps initcalls shouldn't depend on a timer at all, or should
be split into sets that require certain services, and those services can
appear dynamically, and when they do, the relevant initcalls that were
held off by lack of a certain feature all get triggered.
--
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/