In all honesty, there really should be no hotplug anyhow. At not for this
sort of thing. The device should be powered down when wiring new circuitry
to it anyhow right ?


On Mon, Dec 2, 2013 at 5:15 PM, Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> On 12/2/2013 5:48 PM, William Hermans wrote:
> > Charles, where do you get your information from ? Not trying to be rude
> or
> > condescending, or anything of that nature. I only ask because I have
> actual
> > hands experience with this "feature" and have often wondered if  there
> > could be a potential work around( through code ).
>
> My experience is mostly from beating my head against the wall trying to
> get this working, along with crawling through some of the device tree
> "back-story", technical details, and kernel code.
>
> Basically, device tree is intended to be a *STATIC* definition of the
> machine hardware available to the kernel at boot.  Pretty much *ALL*
> device tree does is store a bunch of values that can be retrieved via an
> identifier (think INI file and you're not too far off).  The overlay
> stuff is all pretty much BeagleBone specific.
>
> Loading an overlay works fairly well because it is very similar in
> concept and process to the kernel initialization...various kernel module
> code gets run and other kernel modules may or may not already be present
> or fully loaded.  If your driver code can't deal with this, it's going
> to be buggy in general use, regardless of whether or not you're trying
> to load overlays.  In a sense, loading a device tree overlay is very
> much like simply extending system initialization for what could be a
> _long_ time while a bunch of other code runs.  :)
>
> Unloading an overlay, however, is a minefield of potential problems,
> particularly since most of the ARM drivers weren't written with hot-plug
> in mind.  I'm not even sure most of the drivers can be unloaded at the
> kernel level (hmm...I should go off and try to rmmod some of them).
>
> Anyway, true hotplug is a big-fat-hairy-can-of-worms, and pretty much
> _none_ of the ARM ecosystem has been written with hot-plug in mind
> (except for the bits that carry over from other systems, like USB and
> PCI).  It's not really surprising it crashes, it's just kind of
> annoying.  :)
>
> As for a work-around, I believe the saying goes:
>
> "There is no problem in computer science which cannot be solved by one
> more level of indirection."
>
> --
> Charles Steinkuehler
> char...@steinkuehler.net
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to