lkml.org 
[lkml]   [2013]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v3 3/3] DT: proc: Add runtime overlay interface in /proc
From
Date
Hi Grant,

On Nov 11, 2013, at 7:47 PM, Grant Likely wrote:

> On Fri, 8 Nov 2013 17:06:10 +0200, Pantelis Antoniou <panto@antoniou-consulting.com> wrote:
>> Add a runtime interface to /proc to enable generic device tree overlay
>> usage.
>>
>> Two new /proc files are added:
>>
>> /proc/device-tree-overlay & /proc/device-tree-overlay-status
>>
>> /proc/device-tree-overlay accepts a stream of a device tree objects and
>> applies it to the running kernel's device tree.
>>
>> $ cat ~/BB-UART2-00A0.dtbo >device-tree-overlay
>> overlay_proc_release: Applied #2 overlay segments @0
>>
>> /proc/device-tree-overlay-status displays the the overlays added using
>> the /proc interface
>>
>> $ cat device-tree-overlay-status
>> 0: 861 bytes BB-UART2:00A0
>>
>> The format of the status line is
>> <ID>: <SIZE> bytes <part-number>:<version>
>>
>> <ID> is the id of the overlay
>> <SIZE> is the size of the overlay in bytes
>> <part-number>, <version> are (optional) root level properties of the DTBO
>>
>> You can remove an overlay by echoing the <ID> number of the overlay
>> precedded with a '-'
>>
>> So
>> $ echo "-0" >device-tree-overlay-status
>>
>> Removes the overlay.
>>
>> Note that this seldom works on most platforms since platform_device
>> removal is something that almost never works without extra patches.
>>
>> Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
>
> Why /proc? Did you consider using the firmware loading mechanism? While
> I expressed concerned about the capebus approach, the loading of
> overlays needs to remain under the control of either a driver or the
> platform. By default it should not be possible to drop an arbitrary
> overlay into /proc/device-tree-overlay and have things change in the
> base tree. Along the same lines, I would expect for the device driver or
> platform to be able to filter or limit the parts of the tree that are
> allowed to be modified.
>

The firmware loading mechanism is the preferred way to handle it, and is
in fact what is used in practice by the whole cape manager mechanism.
But that's part of specific board support, and this is more like a general
way to use overlays, in any kind of DT enabled system.

I agree this is a) completely dangerous and b) /proc is a bad place to put
it. I put it here in order to get the ball rolling, about the proper place
to put device tree related interfaces.

The good thing about this interface is that it's always available, and
it is good for debugging (especially loading/unloading debugging).


> A side benefit of the firmware loader is that the kernel can obtain the
> overlay on its own if needed at boot time without userspace involvement.
>

Yes, that is correct, and it is the way we use it on the beaglebone.
The root fs device is present on a overlay, which is built into the kernel's
firmware.


> g.
>

Regards

-- Pantelis



\
 
 \ /
  Last update: 2013-11-12 10:01    [W:0.127 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site