On Fri, Jan 27, 2017 at 03:39:36PM +0100, Rafał Miłecki wrote: > On 27 January 2017 at 15:30, Greg KH <gre...@linuxfoundation.org> wrote: > > On Fri, Jan 27, 2017 at 03:14:14PM +0100, Rafał Miłecki wrote: > >> > Does that patch really "simplify" anything? Anyway, resend it if the > >> > maintainer of the subsystem ignores it (you did cc: the correct people, > >> > right?) > >> > >> According to the MAINTAINERS there isn't firmware API tree / > >> maintainer. Also this is just a cleanup so I don't know if I should > >> expect some random maintainer (e.g. wireless tree) to pick it. > > > > I don't think you looked very hard: > > > > $ ./scripts/get_maintainer.pl --file drivers/base/firmware_class.c > > Ming Lei <ming....@canonical.com> (maintainer:FIRMWARE LOADER > > (request_firmware)) > > "Luis R. Rodriguez" <mcg...@kernel.org> (maintainer:FIRMWARE LOADER > > (request_firmware)) > > Greg Kroah-Hartman <gre...@linuxfoundation.org> (supporter:DRIVER CORE, > > KOBJECTS, DEBUGFS, KERNFS AND SYSFS) > > linux-kernel@vger.kernel.org (open list:FIRMWARE LOADER (request_firmware)) > > > > Please try again... > > My memory totally failed me :( Sorry
I was eventually copied on the patch but there was also a side discussion on you wanting FW_OPT_NO_WARN. Can you review if the proposed driver_data API does what I think you wanted. Although request_firmware_direct() only avoids warning on a sync all the diver_data API also supports this for async calls. If its something else I'd prefer we evaluate extending the driver_data API before loosely adding yet another API call using the old API. Luis
