Johannes Berg writes:
> On Fri, 2020-07-24 at 12:26 +0300, Kalle Valo wrote:
>
>> > > So to me it feels like the best solution forward is to go with the
>> > > vendor API, do you agree? We can, of course, later switch to the common
>> > > API if we manage to create one which is usable for
On Thu, Jul 30, 2020 at 6:24 AM Johannes Berg wrote:
> > Good, I was just checking that we all are on the same page.
>
> But are we? ;-)
I think you were deferring to, "how would user space use it?" And,
"would a common API really help anyone?" (And then you implied
"anyone" = "Chrome OS.")
I
On Fri, 2020-07-24 at 12:26 +0300, Kalle Valo wrote:
> > > So to me it feels like the best solution forward is to go with the
> > > vendor API, do you agree? We can, of course, later switch to the common
> > > API if we manage to create one which is usable for everyone.
But why wouldn't we try
On Mon, 2020-06-01 at 18:32 -0700, Brian Norris wrote:
> I haven't quite reached the 3 month lag on the prior replies here :)
But I did, almost ;-)
> I do want to see this question resolved somehow, or else we'll be
> dragging along out-of-tree patches for...(counts on fingers)...4
> different
Brian Norris writes:
> On Thu, Jul 16, 2020 at 2:35 AM Kalle Valo wrote:
>> Brian Norris writes:
>> > Really, I could live with per-vendor APIs. My primary goal is to get
>> > these upstream in some form, so vendors can stop using things like
>> > this as a reason for shipping us non-upstream
On Thu, Jul 16, 2020 at 2:35 AM Kalle Valo wrote:
> Brian Norris writes:
> > Really, I could live with per-vendor APIs. My primary goal is to get
> > these upstream in some form, so vendors can stop using things like
> > this as a reason for shipping us non-upstream code, and so we can
> >
Brian Norris writes:
> Really, I could live with per-vendor APIs. My primary goal is to get
> these upstream in some form, so vendors can stop using things like
> this as a reason for shipping us non-upstream code, and so we can
> reduce the delta between upstream and Chrome OS kernels.
>
> I
I haven't quite reached the 3 month lag on the prior replies here :)
I do want to see this question resolved somehow, or else we'll be
dragging along out-of-tree patches for...(counts on fingers)...4
different nl80211 APIs for the same feature, and a driver-detecting
user space for it. I think I
On Tue, 2020-03-17 at 18:54 +0200, Kalle Valo wrote:
> For me either solutions are good enough, I'm not familiar enough with
> all the different SAR user space interfaces to make a good decision.
Brian probably has most insight into this :-)
I really didn't want to have to be the referee here,
Brian Norris writes:
>> > > This was discussed during the 2019 wireless workshop. The conclusion
>> > > from that discussion was that while there is clear need for SAR power
>> > > limits for various devices and multiple vendors/drivers, it did not look
>> > > clear that a single common
On Thu, Dec 19, 2019 at 10:55 AM Jouni Malinen wrote:
>
> On Thu, Dec 19, 2019 at 10:32:06AM -0800, Brian Norris wrote:
> > On Thu, Dec 19, 2019 at 7:48 AM Jouni Malinen wrote:
> > > On Thu, Dec 19, 2019 at 09:44:52AM +, Pkshih wrote:
> > > > On Wed, 2019-12-18 at 17:48 +0200, Kalle Valo
On Thu, Dec 19, 2019 at 10:32:06AM -0800, Brian Norris wrote:
> On Thu, Dec 19, 2019 at 7:48 AM Jouni Malinen wrote:
> > On Thu, Dec 19, 2019 at 09:44:52AM +, Pkshih wrote:
> > > On Wed, 2019-12-18 at 17:48 +0200, Kalle Valo wrote:
> > > > diff --git a/include/uapi/nl80211-vnd-qca.h
> > > >
On Thu, Dec 19, 2019 at 7:48 AM Jouni Malinen wrote:
> On Thu, Dec 19, 2019 at 09:44:52AM +, Pkshih wrote:
> > On Wed, 2019-12-18 at 17:48 +0200, Kalle Valo wrote:
> > > diff --git a/include/uapi/nl80211-vnd-qca.h
> > > b/include/uapi/nl80211-vnd-qca.h
> > > + * NOTE: The authoritative place
On Thu, Dec 19, 2019 at 09:44:52AM +, Pkshih wrote:
> On Wed, 2019-12-18 at 17:48 +0200, Kalle Valo wrote:
> > diff --git a/include/uapi/nl80211-vnd-qca.h b/include/uapi/nl80211-vnd-qca.h
> > + * NOTE: The authoritative place for definition of QCA_NL80211_VENDOR_ID,
> > + * vendor subcmd
On Wed, 2019-12-18 at 17:48 +0200, Kalle Valo wrote:
> From: Wen Gong
>
> The vendor commands is to add API for user to configure dynamic SAR
> power limits, it will not replace the existing power control
> functionality, it is to make more convenient to configure power.
>
> An example of
From: Wen Gong
The vendor commands is to add API for user to configure dynamic SAR
power limits, it will not replace the existing power control
functionality, it is to make more convenient to configure power.
An example of usage(wlan0 is the wireless interface dev name):
iw dev wlan0 vendor
16 matches
Mail list logo
