Messages in this thread | | | Date | Fri, 3 Feb 2017 22:56:36 +0100 | From | "Luis R. Rodriguez" <> | Subject | Re: [PATCH v4 1/3] firmware: add new extensible firmware API - drvdata |
| |
On Thu, Jan 19, 2017 at 10:58:56AM -0800, Bjorn Andersson wrote: > On Thu 12 Jan 07:02 PST 2017, Luis R. Rodriguez wrote: > [..] > > +Fallback mechanisms on the driver data API > > +========================================== > > + > > +The old firmware API provided support for a series of fallback mechanisms. The > > +new driver data API abandons all current notions of the fallback mechanisms, > > +it may soon add support for one though. > > + > > What will this fallback mechanism look like? Will it be fully compatible > with the current userspace interfaces
I think its important to strive towards this as we get to fix up the old stuff as much as possible that way. As you could tell from the surge of fixes on the fallback mechanism it is rather fragile and has not had much love. With time some of us have been giving it some love, just recently we added test interfaces for it. We need to address some few more cobwebs before being 100% certain the precise old interface is the ideal solution for a fallback mechanism. I haven't personally found any roadblocks from keeping it compatible on the newer API.
> or will we forever have two > duplicate systems for loading "firmware" in the kernel?
We need flexibility, that's where the new API comes from, the old API will remain but new features should go in through the new API.
> Will the "driver_data" API replace the firmware_class at any point in the future?
The idea is to keep the old API as-is, users requiring new features would use the newer API. That's all.
Luis
| |