Cited commit introduced the following warnings:
drivers/net/wireless/ath/ath10k/mac.c: In function 'chan_to_phymode':
drivers/net/wireless/ath/ath10k/mac.c:558:3: warning: enumeration value
'NL80211_CHAN_WIDTH_1' not handled in switch [-Wswitch]
558 | switch (chandef->width) {
|
Hello,
Apply for a loan, at a 3% interest rate.
Do you need a personal loan?
Do you need a business loan?
Do you need a consolidation loan?
Do you need a secure loan?
Do you need an unsecured loan?
Do you need a mortgage loan?
Do you need a pay off debt loan?
Hi,
Sorry ... long delay.
> > The reason I'm asking is that it's starting to sound like we really
> > ought to be implementing devlink, but we've got a bunch of
> > infrastructure that uses the devcoredump, and it'll take time
> > (significantly so) to change all that...
>
> In devlink world
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
This reverts commit 2dc016599cfa9672a147528ca26d70c3654a5423.
Per Atheros documentation to manufacturers, the EEPROM regulatory domain
code 0x0 must always map to "US". In particular, it should not map to a
custom world regulatory domain. For references, see [1] and [2] below.
Furthermore,
On Sun, 2020-07-26 at 21:49 +0530, Rakesh Pillai wrote:
> We do have the usage of napi_gro_receive and netif_receive_skb in mac80211.
> /* deliver to local stack */
> if (rx->napi)
> napi_gro_receive(rx->napi, skb);
> else
>
