On Mon, Jun 26, 2017 at 08:19:07PM +0200, Rafał Miłecki wrote: > On 2017-06-26 19:33, Luis R. Rodriguez wrote: > > On Sat, Jun 24, 2017 at 02:39:51PM +0200, Greg KH wrote: > > > > There are still other requirements and features in the pipeline for > > > > which we > > > > can consider parameters to parse for, rather than adding new API. Case > > > > in > > > > point, do we want *one* API just to disable the firmware cache? > > > > Specially > > > > knowing that another feature in the pipeline later would make use of > > > > this as a > > > > requirement? > > > > > > Again, I do not care! You can not justify patches today with some > > > mythical thing in the future that might never even happen. > > > > Granting the option to make async firmware optional was discussed since > > December 2016 by RafaÅ [1]. It was only later during my driver data API > > changes that Hans noted the nvram part was actually *not* optional [2] so > > this requirement dropped. *However* as the maintainer I believ ethis > > requirement *is sensible* and would not be surprised if alternative > > firmware already exists where this is what is intended. > > I believe there was a misunderstanding of my patch by Hans. The point of my > patch was to don't display warning *IF* we can use alternative soruce and > get the NVRAM (firmware) from platform data (special partition used by the > bootloader and accessible by the operating system).
Oh, are you saying the optional async firmware loading is still a requirement for this driver? Are you, Hans, and Arend Van Spriel in agreement on this? If so then that definitely makes 3 effective changes in my radar for extensions to the firmware API. Luis
