linux-kernel - Re: [RFC PATCH 0/2] DT match helpers for initcalls and platform 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:	Wed, 30 Oct 2013 15:02:40 -0500
From:	Rob Herring <robherring2@...il.com>
To:	Thierry Reding <thierry.reding@...il.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Grant Likely <grant.likely@...aro.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Rob Herring <rob.herring@...xeda.com>
Subject: Re: [RFC PATCH 0/2] DT match helpers for initcalls and platform devices

On Wed, Oct 30, 2013 at 3:26 AM, Thierry Reding
<thierry.reding@...il.com> wrote:
> On Wed, Oct 30, 2013 at 01:12:49AM -0500, Rob Herring wrote:
>> From: Rob Herring <rob.herring@...xeda.com>
>>
>> This series adds a couple of boilerplate helpers to match with DT for
>> initcalls and platform device creation and probe. The goal here is to
>> remove more platform code out of arch/arm and eventually the machine
>> descriptors.
>
> I fear that this is a step backwards because it makes it easier for
> people to do the wrong thing. We've been doing the same with interrupt
> controllers and clocks. With those there's at least the argument that
> they need to be available really early and therefore cannot use the
> regular driver model. But for everything else, shouldn't we enforce
> proper drivers to be written?

You think both are a step backwards or just the initcall one? For
initcalls, there are things which are not drivers, but just one time
init.  The example on highbank is highbank_pm_init. In some cases like
cpuidle, they have been converted to platform drivers, but then we
have platform code to create devices if we are on the relevant
platform. There is not really a real device node that exists for some
of these drivers and we need to create the device rather than the
device getting created by scanning the buses in the DT.

I think this is less error prone because we've had cases of
unconditional initcalls which break multi-platform kernels.

> Perhaps if you can point me to some examples I could get more context
> why and where this would be useful.

I'll push out a WIP branch later which has the above examples and
removes the machine_desc struct for highbank. This all is more for
arm64 which doesn't have or want to have a machine_desc.

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