On Fri, Oct 22, 2021 at 02:00:57AM -0700, Zev Weiss wrote: > On Thu, Oct 21, 2021 at 11:50:07PM PDT, Greg Kroah-Hartman wrote: > > On Thu, Oct 21, 2021 at 07:00:27PM -0700, Zev Weiss wrote: > > > Hello all, > > > > > > This series is another incarnation of a couple other patchsets I've > > > posted recently [0, 1], but again different enough in overall > > > structure that I'm not sure it's exactly a v2 (or v3). > > > > > > As compared to [1], it abandons the writable binary sysfs files and at > > > Frank's suggestion returns to an approach more akin to [0], though > > > without any driver-specific (aspeed-smc) changes, which I figure might > > > as well be done later in a separate series once appropriate > > > infrastructure is in place. > > > > > > The basic idea is to implement support for a status property value > > > that's documented in the DT spec [2], but thus far not used at all in > > > the kernel (or anywhere else I'm aware of): "reserved". According to > > > the spec (section 2.3.4, Table 2.4), this status: > > > > > > Indicates that the device is operational, but should not be used. > > > Typically this is used for devices that are controlled by another > > > software component, such as platform firmware. > > > > > > With these changes, devices marked as reserved are (at least in some > > > cases, more on this later) instantiated, but will not have drivers > > > bound to them unless and until userspace explicitly requests it by > > > writing the device's name to the driver's sysfs 'bind' file. This > > > enables appropriate handling of hardware arrangements that can arise > > > in contexts like OpenBMC, where a device may be shared with another > > > external controller not under the kernel's control (for example, the > > > flash chip storing the host CPU's firmware, shared by the BMC and the > > > host CPU and exclusively under the control of the latter by default). > > > Such a device can be marked as reserved so that the kernel refrains > > > from touching it until appropriate preparatory steps have been taken > > > (e.g. BMC userspace coordinating with the host CPU to arbitrate which > > > processor has control of the firmware flash). > > > > > > Patches 1-3 provide some basic plumbing for checking the "reserved" > > > status of a device, patch 4 is the main driver-core change, and patch > > > 5 tweaks the OF platform code to not skip reserved devices so that > > > they can actually be instantiated. > > > > Again, the driver core should not care about this, that is up to the bus > > that wants to read these "reserved" values and do something with them or > > not (remember the bus is the thing that does the binding, not the driver > > core). > > > > But are you sure you are using the "reserved" field properly? > > Well, thus far both Rob Herring and Oliver O'Halloran (originator of the > "reserved" status in the DT spec, whom I probably should have CCed earlier, > sorry) have seemed receptive to this interpretation of it, which I'd hope > would lend it some credence. Ok, that's up to the DT people, I'll let you all fight it out with the platform creators :) Good luck! greg k-h
