On Mon, Oct 25, 2021 at 03:58:25PM +0300, Andy Shevchenko wrote:

On Mon, Oct 25, 2021 at 06:44:26AM -0500, Patrick Williams wrote:

quoted

On Mon, Oct 25, 2021 at 08:15:41AM +0200, Greg Kroah-Hartman wrote:

quoted

On Mon, Oct 25, 2021 at 12:38:08AM -0500, Frank Rowand wrote:

quoted

On 10/23/21 3:56 AM, Greg Kroah-Hartman wrote:

quoted

We have the bind/unbind ability today, from userspace, that can control
this.  Why not just have Linux grab the device when it boots, and then
when userspace wants to "give the device up", it writes to "unbind" in
sysfs, and then when all is done, it writes to the "bind" file and then
Linux takes back over.

Unless for some reason Linux should _not_ grab the device when booting,
then things get messier, as we have seen in this thread.

This is probably more typical on a BMC than atypical.  The systems often require
the BMC (running Linux) to be able to reboot independently from the managed host
(running anything).  In the example Zev gave, the BMC rebooting would rip away
the BIOS chip from the running host.

The BMC almost always needs to come up in a "I don't know what could possibly be
going on in the system" state and re-discover where the system was left off.

Isn't it an architectural issue then?

I'm not sure what "it" you are referring to here.

I was trying to explain why starting in "bind" state is not a good idea for a
BMC in most of these cases where we want to be able to dynamically add a device.


-- 
Patrick Williams