On Wed, 03 Aug 2016, Daniel Vetter wrote:
> On Wed, Aug 03, 2016 at 06:00:14AM +, Vivi, Rodrigo wrote:
>> So, what should we do in cases like this missed 1.23?
>> Close the bug as wontfix?
>>
>> We are blocking users from upgrade the component, or worst, like in this
>> case where 1.23 was c
On Wed, Aug 03, 2016 at 06:00:14AM +, Vivi, Rodrigo wrote:
> So, what should we do in cases like this missed 1.23?
> Close the bug as wontfix?
>
> We are blocking users from upgrade the component, or worst, like in this
> case where 1.23 was causing bugs we are removing at all and preventing
So, what should we do in cases like this missed 1.23?
Close the bug as wontfix?
We are blocking users from upgrade the component, or worst, like in this case
where 1.23 was causing bugs we are removing at all and preventing the user to
have the extra power savings with another stable version of
On Wed, 20 Jul 2016, "Vivi, Rodrigo" wrote:
> We don't hardcode all userspace libraries in the userspace side for
> the graphics stack and we do not validate all possible combinations of
> libdrm, mesa, ddx, libva, etc... Why should we need this with
> firmware?
Because the firmware blob is more
If you look back we did have both no-black listing (only required a
proper major version) and black listing before we ended up deciding
that we'll use white listing. The reasons for this were too many
obscure firmware issues, undocumented interoperability details between
firmware and the driver and
Marc kicked me to the other side of the fence. I'm now cheering for the
symbolic links back again.
We cannot block users to use some new firmware version if they
like/want/need.
Also, also as Chris highlighted the hardcoded version doesn't help the
bisect but make it unlikely. I don't believe a
Versioning dependencies isn't exactly a new problem outside the kernel,
so please allow me to share my experience below. Thanks to Rodrigo for
glancing over this email and preventing me from writing anything too
stupid or that was said already.
>> The firmware should be side-ways compatible for
On ma, 2016-07-11 at 14:50 +0100, ch...@chris-wilson.co.uk wrote:
> On Mon, Jul 11, 2016 at 04:24:50PM +0300, Imre Deak wrote:
> > On ma, 2016-07-11 at 13:55 +0100, ch...@chris-wilson.co.uk wrote:
> > > And then you get random changes in the firmare whilst bisecting
> > > the
> > > kernel.
> >
> >
On Mon, Jul 11, 2016 at 04:24:50PM +0300, Imre Deak wrote:
> On ma, 2016-07-11 at 13:55 +0100, ch...@chris-wilson.co.uk wrote:
> > And then you get random changes in the firmare whilst bisecting the
> > kernel.
>
> What do you mean random? During bisecting we want to load the firmware
> version th
On ma, 2016-07-11 at 13:55 +0100, ch...@chris-wilson.co.uk wrote:
> On Mon, Jul 11, 2016 at 03:45:21PM +0300, Imre Deak wrote:
> > On ma, 2016-07-11 at 13:39 +0100, ch...@chris-wilson.co.uk wrote:
> > > On Mon, Jul 11, 2016 at 02:23:48PM +0300, Imre Deak wrote:
> > > > On to, 2016-07-07 at 17:57 +0
On Mon, Jul 11, 2016 at 03:45:21PM +0300, Imre Deak wrote:
> On ma, 2016-07-11 at 13:39 +0100, ch...@chris-wilson.co.uk wrote:
> > On Mon, Jul 11, 2016 at 02:23:48PM +0300, Imre Deak wrote:
> > > On to, 2016-07-07 at 17:57 +0300, Mika Kuoppala wrote:
> > > > "Vivi, Rodrigo" writes:
> > > >
> > >
On ma, 2016-07-11 at 13:39 +0100, ch...@chris-wilson.co.uk wrote:
> On Mon, Jul 11, 2016 at 02:23:48PM +0300, Imre Deak wrote:
> > On to, 2016-07-07 at 17:57 +0300, Mika Kuoppala wrote:
> > > "Vivi, Rodrigo" writes:
> > >
> > > > Nak.
> > > >
> > > > I don't intend to update the symbolic links o
On Mon, Jul 11, 2016 at 02:23:48PM +0300, Imre Deak wrote:
> On to, 2016-07-07 at 17:57 +0300, Mika Kuoppala wrote:
> > "Vivi, Rodrigo" writes:
> >
> > > Nak.
> > >
> > > I don't intend to update the symbolic links on linux-firmware.git
> > > repository anymore so if we receive a new minor versi
On to, 2016-07-07 at 17:57 +0300, Mika Kuoppala wrote:
> "Vivi, Rodrigo" writes:
>
> > Nak.
> >
> > I don't intend to update the symbolic links on linux-firmware.git
> > repository anymore so if we receive a new minor version update we
> > are
> > not going to load.
> >
> > I was the one advoca
On Thu, 2016-07-07 at 17:57 +0300, Mika Kuoppala wrote:
> "Vivi, Rodrigo" writes:
>
> >
> > Nak.
> >
> > I don't intend to update the symbolic links on linux-firmware.git
> > repository anymore so if we receive a new minor version update we
> > are
> > not going to load.
> >
> > I was the one
"Vivi, Rodrigo" writes:
> Nak.
>
> I don't intend to update the symbolic links on linux-firmware.git
> repository anymore so if we receive a new minor version update we are
> not going to load.
>
> I was the one advocating in the favor for the symbolic link flexibility
> but I lost the discussion
Nak.
I don't intend to update the symbolic links on linux-firmware.git
repository anymore so if we receive a new minor version update we are
not going to load.
I was the one advocating in the favor for the symbolic link flexibility
but I lost the discussions for the stability and validation etc.
We need the ability to explicitly load only a specified firmware
version. As the firmware blob contains the version, we use
that to filter out the ones we don't want. The version encoded
into the firmware name is superfluous and we should allow user
to point into specific firmware through a symlink
18 matches
Mail list logo
