Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1573476 > unrolled thread

Re: [PATCH v4 1/3] firmware: add new extensible firmware API - drvdata

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v4 1/3] firmware: add new extensible firmware API -  drvdata "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-02-03 23:00 +0100

#1573476 — 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

[toc] | [standalone]

Back to top | Article view | linux.kernel

csiph-web