On Mon, Jun 26, 2017 at 07:28:12PM -0700, Vikram Mulukutla wrote:
> On 6/26/2017 10:33 AM, Luis R. Rodriguez wrote:
> > On Sat, Jun 24, 2017 at 02:39:51PM +0200, Greg KH wrote:
> > > Was it used because your version has taken so long to be
> > > submitted/reviwed?
> >
> > Vikram would have a bette
On 6/26/2017 10:33 AM, Luis R. Rodriguez wrote:
On Sat, Jun 24, 2017 at 02:39:51PM +0200, Greg KH wrote:
On Sat, Jun 24, 2017 at 02:48:28AM +0200, Luis R. Rodriguez wrote:
On Fri, Jun 23, 2017 at 04:09:29PM -0700, Linus Torvalds wrote:
On Fri, Jun 23, 2017 at 3:43 PM, Luis R. Rodriguez
wrote:
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 t
On 2017-06-26 19:33, Luis R. Rodriguez wrote:
On Sat, Jun 24, 2017 at 02:39:51PM +0200, Greg KH wrote:
On Sat, Jun 24, 2017 at 02:48:28AM +0200, Luis R. Rodriguez wrote:
> On Fri, Jun 23, 2017 at 04:09:29PM -0700, Linus Torvalds wrote:
> > On Fri, Jun 23, 2017 at 3:43 PM, Luis R. Rodriguez
wro
On Sat, Jun 24, 2017 at 02:39:51PM +0200, Greg KH wrote:
> On Sat, Jun 24, 2017 at 02:48:28AM +0200, Luis R. Rodriguez wrote:
> > On Fri, Jun 23, 2017 at 04:09:29PM -0700, Linus Torvalds wrote:
> > > On Fri, Jun 23, 2017 at 3:43 PM, Luis R. Rodriguez
> > > wrote:
> > > >
> > > > Ah, yes! Here is
On Sat, Jun 24, 2017 at 02:40:57PM +0200, Greg KH wrote:
> On Sat, Jun 24, 2017 at 12:43:38AM +0200, Luis R. Rodriguez wrote:
> > > It's also blocking real bug fixes and features that people want
> > > addressed, which isn't acceptable.
> >
> > What? What bugs ? I have addressed *every single* sta
On Sat, Jun 24, 2017 at 12:43:38AM +0200, Luis R. Rodriguez wrote:
> > It's also blocking real bug fixes and features that people want
> > addressed, which isn't acceptable.
>
> What? What bugs ? I have addressed *every single* stable issue in queue and
> have sent patches for them and they do not
On Sat, Jun 24, 2017 at 02:48:28AM +0200, Luis R. Rodriguez wrote:
> On Fri, Jun 23, 2017 at 04:09:29PM -0700, Linus Torvalds wrote:
> > On Fri, Jun 23, 2017 at 3:43 PM, Luis R. Rodriguez
> > wrote:
> > >
> > > Ah, yes! Here is what I believe seems to be the *crux* issue of these
> > > patch
> >
On Fri, Jun 23, 2017 at 04:09:29PM -0700, Linus Torvalds wrote:
> On Fri, Jun 23, 2017 at 3:43 PM, Luis R. Rodriguez wrote:
> >
> > Ah, yes! Here is what I believe seems to be the *crux* issue of these patch
> > series and I'm happy we have finally landed on it. Yes, indeed the new API
> > propose
On Fri, Jun 23, 2017 at 3:43 PM, Luis R. Rodriguez wrote:
>
> Ah, yes! Here is what I believe seems to be the *crux* issue of these patch
> series and I'm happy we have finally landed on it. Yes, indeed the new API
> proposed here provides more flexibility, and it does so by embracing a
> "data dr
On Fri, Jun 23, 2017 at 11:59:36PM +0800, Greg KH wrote:
> On Mon, Jun 19, 2017 at 09:35:22PM +0200, Luis R. Rodriguez wrote:
> > You may argue that *one* upstream users is not sufficient to introduce a new
> > feature for, but I disagree given we have had new full *API* added for a new
> > feature
On Fri, Jun 23, 2017 at 11:51:23PM +0800, Greg KH wrote:
> On Mon, Jun 19, 2017 at 09:35:22PM +0200, Luis R. Rodriguez wrote:
> > > I agree, that's what I'm saying here. I just do not see that happening
> > > with your patch set at all. It's adding more code, a more complex way
> > > to interact
On Mon, Jun 19, 2017 at 09:35:22PM +0200, Luis R. Rodriguez wrote:
> > I agree, that's what I'm saying here. I just do not see that happening
> > with your patch set at all. It's adding more code, a more complex way
> > to interact with the subsystem, and not making driver writer lives any
> > ea
To respond to one issue in your wall-of-text response:
On Mon, Jun 19, 2017 at 09:35:22PM +0200, Luis R. Rodriguez wrote:
> You may argue that *one* upstream users is not sufficient to introduce a new
> feature for, but I disagree given we have had new full *API* added for a new
> feature on the f
On Wed, Jun 21, 2017 at 09:49:35AM +0900, AKASHI Takahiro wrote:
> On Tue, Jun 20, 2017 at 07:22:19PM +0200, Luis R. Rodriguez wrote:
> > On Tue, Jun 20, 2017 at 09:27:45AM -0700, Vikram Mulukutla wrote:
> > >
> > > perhaps a light
> > > internal rework inside firmware_class might be more suitable
On Tue, Jun 20, 2017 at 07:22:19PM +0200, Luis R. Rodriguez wrote:
> On Tue, Jun 20, 2017 at 09:27:45AM -0700, Vikram Mulukutla wrote:
> >
> > perhaps a light
> > internal rework inside firmware_class might be more suitable towards the
> > extensibility goal while keeping driver API usage as simpl
On Tue, Jun 20, 2017 at 09:27:45AM -0700, Vikram Mulukutla wrote:
>
> Hi Greg, Luis,
>
> On 2017-06-17 12:38, Greg KH wrote:
> > On Tue, Jun 13, 2017 at 09:40:11PM +0200, Luis R. Rodriguez wrote:
> > > On Tue, Jun 13, 2017 at 11:05:48AM +0200, Greg KH wrote:
> > > > On Mon, Jun 05, 2017 at 02:39:
Hi Greg, Luis,
On 2017-06-17 12:38, Greg KH wrote:
On Tue, Jun 13, 2017 at 09:40:11PM +0200, Luis R. Rodriguez wrote:
On Tue, Jun 13, 2017 at 11:05:48AM +0200, Greg KH wrote:
> On Mon, Jun 05, 2017 at 02:39:33PM -0700, Luis R. Rodriguez wrote:
> > As the firmware API evolves we keep extending
On 6/19/2017 8:48 PM, AKASHI Takahiro wrote:
On Mon, Jun 19, 2017 at 05:51:08PM -0500, Li, Yi wrote:
Hi Greg,
On 6/17/2017 2:38 PM, Greg KH wrote:
On Tue, Jun 13, 2017 at 09:40:11PM +0200, Luis R. Rodriguez wrote:
On Tue, Jun 13, 2017 at 11:05:48AM +0200, Greg KH wrote:
On Mon, Jun 05, 201
On Mon, Jun 19, 2017 at 05:51:08PM -0500, Li, Yi wrote:
> Hi Greg,
>
> On 6/17/2017 2:38 PM, Greg KH wrote:
> >On Tue, Jun 13, 2017 at 09:40:11PM +0200, Luis R. Rodriguez wrote:
> >>On Tue, Jun 13, 2017 at 11:05:48AM +0200, Greg KH wrote:
> >>>On Mon, Jun 05, 2017 at 02:39:33PM -0700, Luis R. Rodr
On Mon, Jun 19, 2017 at 09:41:07PM +0200, Luis R. Rodriguez wrote:
> On Mon, Jun 19, 2017 at 09:33:16AM +0200, Johannes Berg wrote:
> > On Sat, 2017-06-17 at 21:38 +0200, Greg KH wrote:
> >
> > > But we don't accept kernel patches for some mythical future option
> > > that might be happening some
Hi Greg,
On 6/17/2017 2:38 PM, Greg KH wrote:
On Tue, Jun 13, 2017 at 09:40:11PM +0200, Luis R. Rodriguez wrote:
On Tue, Jun 13, 2017 at 11:05:48AM +0200, Greg KH wrote:
On Mon, Jun 05, 2017 at 02:39:33PM -0700, Luis R. Rodriguez wrote:
As the firmware API evolves we keep extending functions
On Mon, Jun 19, 2017 at 09:33:16AM +0200, Johannes Berg wrote:
> On Sat, 2017-06-17 at 21:38 +0200, Greg KH wrote:
>
> > But we don't accept kernel patches for some mythical future option
> > that might be happening some time in the future. Heck, I'm still not
> > convinced that firmware signing
On Sat, Jun 17, 2017 at 09:38:15PM +0200, Greg KH wrote:
> On Tue, Jun 13, 2017 at 09:40:11PM +0200, Luis R. Rodriguez wrote:
> > On Tue, Jun 13, 2017 at 11:05:48AM +0200, Greg KH wrote:
> > > On Mon, Jun 05, 2017 at 02:39:33PM -0700, Luis R. Rodriguez wrote:
> > > > As the firmware API evolves we
On Sat, 2017-06-17 at 21:38 +0200, Greg KH wrote:
> But we don't accept kernel patches for some mythical future option
> that might be happening some time in the future. Heck, I'm still not
> convinced that firmware signing isn't anything more than just some
> snakeoil in the first place!
I for
On Tue, Jun 13, 2017 at 09:40:11PM +0200, Luis R. Rodriguez wrote:
> On Tue, Jun 13, 2017 at 11:05:48AM +0200, Greg KH wrote:
> > On Mon, Jun 05, 2017 at 02:39:33PM -0700, Luis R. Rodriguez wrote:
> > > As the firmware API evolves we keep extending functions with more
> > > arguments.
> > > Stop t
On 6/13/2017 2:40 PM, Luis R. Rodriguez wrote:
On Tue, Jun 13, 2017 at 11:05:48AM +0200, Greg KH wrote:
On Mon, Jun 05, 2017 at 02:39:33PM -0700, Luis R. Rodriguez wrote:
As the firmware API evolves we keep extending functions with more arguments.
Stop this nonsense by proving an extensible d
On Tue, Jun 13, 2017 at 11:05:48AM +0200, Greg KH wrote:
> On Mon, Jun 05, 2017 at 02:39:33PM -0700, Luis R. Rodriguez wrote:
> > As the firmware API evolves we keep extending functions with more arguments.
> > Stop this nonsense by proving an extensible data structure which can be used
> > to repr
On Tue, Jun 13, 2017 at 05:32:49PM +0200, Luis R. Rodriguez wrote:
> On Tue, Jun 13, 2017 at 03:17:43PM +0200, Greg KH wrote:
> > On Tue, Jun 13, 2017 at 12:31:04PM +0200, Rafał Miłecki wrote:
> > > On 2017-06-13 11:05, Greg KH wrote:
> > > > On Mon, Jun 05, 2017 at 02:39:33PM -0700, Luis R. Rodrig
On Tue, Jun 13, 2017 at 03:17:43PM +0200, Greg KH wrote:
> On Tue, Jun 13, 2017 at 12:31:04PM +0200, Rafał Miłecki wrote:
> > On 2017-06-13 11:05, Greg KH wrote:
> > > On Mon, Jun 05, 2017 at 02:39:33PM -0700, Luis R. Rodriguez wrote:
> > > > As the firmware API evolves we keep extending functions
On 06/13/2017 03:17 PM, Greg KH wrote:
On Tue, Jun 13, 2017 at 12:31:04PM +0200, Rafał Miłecki wrote:
On 2017-06-13 11:05, Greg KH wrote:
On Mon, Jun 05, 2017 at 02:39:33PM -0700, Luis R. Rodriguez wrote:
As the firmware API evolves we keep extending functions with more
arguments.
Stop this no
On Tue, Jun 13, 2017 at 12:31:04PM +0200, Rafał Miłecki wrote:
> On 2017-06-13 11:05, Greg KH wrote:
> > On Mon, Jun 05, 2017 at 02:39:33PM -0700, Luis R. Rodriguez wrote:
> > > As the firmware API evolves we keep extending functions with more
> > > arguments.
> > > Stop this nonsense by proving an
On 2017-06-13 11:05, Greg KH wrote:
On Mon, Jun 05, 2017 at 02:39:33PM -0700, Luis R. Rodriguez wrote:
As the firmware API evolves we keep extending functions with more
arguments.
Stop this nonsense by proving an extensible data structure which can
be used
to represent both user parameters and
On Mon, Jun 05, 2017 at 02:39:33PM -0700, Luis R. Rodriguez wrote:
> As the firmware API evolves we keep extending functions with more arguments.
> Stop this nonsense by proving an extensible data structure which can be used
> to represent both user parameters and private internal parameters.
Let'
As the firmware API evolves we keep extending functions with more arguments.
Stop this nonsense by proving an extensible data structure which can be used
to represent both user parameters and private internal parameters.
We introduce 3 data structures:
o struct driver_data_req_params - used fo
35 matches
Mail list logo
