On Wed, Apr 25, 2018 at 10:55 AM, Luis R. Rodriguez <mcgrof@xxxxxxxxxx> wrote: > Android became the primary user of CONFIG_FW_LOADER_USER_HELPER_FALLBACK. > > It would be good for us to hear from Android folks if their current use of > request_firmware_into_buf() is designed in practice to *never* use the direct > filesystem firmware loading interface, and always rely instead on the > fallback mechanism. It's hard to answer this question for Android in general. As far as I can tell the reasons we use CONFIG_FW_LOADER_USER_HELPER(_FALLBACK) are: 1) We have multiple different paths on our devices where firmware can be located, and the direct loader only supports one custom path 2) Most of those paths are not mounted by the time the corresponding drivers are loaded, because pretty much all Android kernels today are built without module support, and therefore drivers are loaded well before the firmware partition is mounted 3) I think we use _FALLBACK because doing this with uevents is just the easiest thing to do; our init code has a firmware helper that deals with this and searches the paths that we care about 2) will change at some point, because Android is moving towards a model where device-specific peripheral drivers will be loaded as modules, and since those modules would likely come from the same partition as the firmware, it's possible that the direct load would succeed (depending on whether the custom path is configured there or not). But I don't think we can rely on the direct loader even in those cases, unless we could configure it with multiple custom paths. I have no reason to believe request_firmware_into_buf() is special in this regard; drivers that depend on it may have their corresponding firmware in different locations, so just depending on the direct loader would not be good enough. > > Is ptr below > > ret = request_firmware_into_buf(&seg_fw, fw_name, dev, > ptr, phdr->p_filesz); > > Also part of the DMA buffer allocated earlier via: > > ret = qcom_scm_pas_init_image(pas_id, fw->data, fw->size); > > Android folks? I think the Qualcomm folks owning this (Andy, David, Bjorn, already cc'd here) are better suited to answer that question. Thanks, Martijn
