* Re: [PATCH] nfc: Ensure presence of required attributes in the deactivate_target handler
From: David Miller @ 2019-06-14 15:48 UTC (permalink / raw)
To: 92siuyang; +Cc: sameo, linux-wireless, netdev, linux-kernel
In-Reply-To: <1560496382-32532-1-git-send-email-92siuyang@gmail.com>
From: Young Xiao <92siuyang@gmail.com>
Date: Fri, 14 Jun 2019 15:13:02 +0800
> Check that the NFC_ATTR_TARGET_INDEX attributes (in addition to
> NFC_ATTR_DEVICE_INDEX) are provided by the netlink client prior to
> accessing them. This prevents potential unhandled NULL pointer dereference
> exceptions which can be triggered by malicious user-mode programs,
> if they omit one or both of these attributes.
>
> Signed-off-by: Young Xiao <92siuyang@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] mmc: core: Prevent processing SDIO IRQs when the card is suspended
From: Doug Anderson @ 2019-06-14 15:41 UTC (permalink / raw)
To: Ulf Hansson
Cc: Linux MMC List, Adrian Hunter, Brian Norris, Shawn Lin,
Guenter Roeck, Heiko Stuebner, Kalle Valo, linux-wireless, # 4.0+
In-Reply-To: <CAPDyKFpqk4ZcVTqifnbnW1WgNfx9ZNebCttUPcK_e9KWqpDMjQ@mail.gmail.com>
Hi,
On Fri, Jun 14, 2019 at 4:56 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> > I was more worried about the safety of mmc_card_set_suspended()
> > itself. That is:
> >
> > #define mmc_card_set_suspended(c) ((c)->state |= MMC_STATE_SUSPENDED)
> >
> > ...so it's doing a read-modify-write of "state". Is that safe to do
> > without any type of locking?
>
> In this case, yes I think so.
>
> The point is, it really doesn't matter if the reader (work or thread),
> reads a non-updated value, because the synchronization is managed by
> the later mmc_claim_host() and the cancel_delayed_work_sync().
If this were just an "int" then perhaps, but this is a bitfield. So
if someone else updates the bitfield at the same time then we can
fully clobber their modification or they can clobber ours, right?
task 1: load "state" from memory into CPU register on cpu0
task 2: load "state" from memory into CPU register on cpu1
task 1: OR in MMC_CARD_REMOVED
task 1: write "state" from CPU register on cpu0
task 2: OR in MMC_STATE_SUSPENDED
task 2: write "state" from CPU register on cpu1
...so now we've clobbered MMC_CARD_REMOVED. ...or am I just being
paranoid here and everything else in "state" is somehow guaranteed to
not be touched at the same time this function is running?
-Doug
^ permalink raw reply
* Re: [PATCH 12/16] staging/comedi: mark as broken
From: Christoph Hellwig @ 2019-06-14 15:34 UTC (permalink / raw)
To: Greg KH
Cc: Christoph Hellwig, Maarten Lankhorst, Maxime Ripard, Sean Paul,
David Airlie, Daniel Vetter, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Ian Abbott, H Hartley Sweeten, devel, linux-s390,
Intel Linux Wireless, linux-rdma, netdev, intel-gfx,
linux-wireless, linux-kernel, dri-devel, linux-mm, iommu,
moderated list:ARM PORT, linux-media
In-Reply-To: <20190614153032.GD18049@kroah.com>
On Fri, Jun 14, 2019 at 05:30:32PM +0200, Greg KH wrote:
> On Fri, Jun 14, 2019 at 04:48:57PM +0200, Christoph Hellwig wrote:
> > On Fri, Jun 14, 2019 at 04:02:39PM +0200, Greg KH wrote:
> > > Perhaps a hint as to how we can fix this up? This is the first time
> > > I've heard of the comedi code not handling dma properly.
> >
> > It can be fixed by:
> >
> > a) never calling virt_to_page (or vmalloc_to_page for that matter)
> > on dma allocation
> > b) never remapping dma allocation with conflicting cache modes
> > (no remapping should be doable after a) anyway).
>
> Ok, fair enough, have any pointers of drivers/core code that does this
> correctly? I can put it on my todo list, but might take a week or so...
Just about everyone else. They just need to remove the vmap and
either do one large allocation, or live with the fact that they need
helpers to access multiple array elements instead of one net vmap,
which most of the users already seem to do anyway, with just a few
using the vmap (which might explain why we didn't see blowups yet).
^ permalink raw reply
* Re: [PATCH 12/16] staging/comedi: mark as broken
From: Greg KH @ 2019-06-14 15:30 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Maarten Lankhorst, Maxime Ripard, Sean Paul, David Airlie,
Daniel Vetter, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Ian Abbott, H Hartley Sweeten, devel, linux-s390,
Intel Linux Wireless, linux-rdma, netdev, intel-gfx,
linux-wireless, linux-kernel, dri-devel, linux-mm, iommu,
moderated list:ARM PORT, linux-media
In-Reply-To: <20190614144857.GA9088@lst.de>
On Fri, Jun 14, 2019 at 04:48:57PM +0200, Christoph Hellwig wrote:
> On Fri, Jun 14, 2019 at 04:02:39PM +0200, Greg KH wrote:
> > Perhaps a hint as to how we can fix this up? This is the first time
> > I've heard of the comedi code not handling dma properly.
>
> It can be fixed by:
>
> a) never calling virt_to_page (or vmalloc_to_page for that matter)
> on dma allocation
> b) never remapping dma allocation with conflicting cache modes
> (no remapping should be doable after a) anyway).
Ok, fair enough, have any pointers of drivers/core code that does this
correctly? I can put it on my todo list, but might take a week or so...
Ian, want to look into doing this sooner?
thanks,
greg k-h
^ permalink raw reply
* RE: [PATCH 16/16] dma-mapping: use exact allocation in dma_alloc_contiguous
From: David Laight @ 2019-06-14 15:16 UTC (permalink / raw)
To: 'Robin Murphy', 'Christoph Hellwig'
Cc: Maxime Ripard, Joonas Lahtinen, dri-devel@lists.freedesktop.org,
linux-mm@kvack.org, devel@driverdev.osuosl.org,
linux-s390@vger.kernel.org, linux-rdma@vger.kernel.org,
David Airlie, linux-media@vger.kernel.org, Intel Linux Wireless,
intel-gfx@lists.freedesktop.org, Maarten Lankhorst, Jani Nikula,
Ian Abbott, Rodrigo Vivi, Sean Paul, moderated list:ARM PORT,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, H Hartley Sweeten,
iommu@lists.linux-foundation.org, Daniel Vetter
In-Reply-To: <4113cd5f-5c13-e9c7-bc5e-dcf0b60e7054@arm.com>
From: Robin Murphy
> Sent: 14 June 2019 16:06
...
> Well, apart from the bit in DMA-API-HOWTO which has said this since
> forever (well, before Git history, at least):
>
> "The CPU virtual address and the DMA address are both
> guaranteed to be aligned to the smallest PAGE_SIZE order which
> is greater than or equal to the requested size. This invariant
> exists (for example) to guarantee that if you allocate a chunk
> which is smaller than or equal to 64 kilobytes, the extent of the
> buffer you receive will not cross a 64K boundary."
I knew it was somewhere :-)
Interestingly that also implies that the address returned for a size
of (say) 128 will also be page aligned.
In that case 128 byte alignment should probably be ok - but it is still
an API change that could have horrid consequences.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH-v3 1/2] wireless: Support assoc-at-ms timer in sta-info
From: Ben Greear @ 2019-06-14 15:14 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
In-Reply-To: <e8343919c6851e6b5a7905b708661870c4c88481.camel@sipsolutions.net>
On 6/14/19 7:56 AM, Johannes Berg wrote:
> On Fri, 2019-06-14 at 07:46 -0700, Ben Greear wrote:
>>
>> The point of my patch was to allow 'iw' to return a more precise time
>> that the station has been associated, so I am not sure that BOOTIME is
>> a good thing to use for that?
>
> Depends what you want, really.
>
>> + if (sinfo[NL80211_STA_INFO_ASSOC_AT_MS])
>> + printf("\n\tassociated at:\t%llu ms",
>> + (unsigned long long)nla_get_u64(sinfo[NL80211_STA_INFO_ASSOC_AT_MS]));
>>
>> - printf("\n");
>> + printf("\n\tcurrent time:\t%llu ms\n", now_ms);
>
> Since you just print the time in milliseconds, and the current time in
> milliseconds, you don't even really have any value in the wall clock.
> Quite the opposite - this lends itself to subtracting to try to figure
> out how long it was associated, which is the completely wrong thing to
> do with wall clock - timezone adjustment could've happened inbetween,
> for example!
>
> I really see no point in trying to give the wall clock at assoc time. If
> no timezone adjustment happened, you can just as well give the boottime
> and have the userspace figure out the wall clock. If timezone adjustment
> happened, then any calculations are wrong anyway, what would the point
> be?
So, maybe I return instead the elapsed time in the netlink API instead of a
timestamp. I think that will give me the value that I am looking for,
and I can still print out the 'real' time in iw so any tools reading that
output and do some simple math and figure out the 'real' associated-at time.
If that sounds good to you, I'll code that up.
Thanks,
Ben
>
> johannes
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 16/16] dma-mapping: use exact allocation in dma_alloc_contiguous
From: 'Christoph Hellwig' @ 2019-06-14 15:08 UTC (permalink / raw)
To: Robin Murphy
Cc: 'Christoph Hellwig', David Laight, Maxime Ripard,
Joonas Lahtinen, dri-devel@lists.freedesktop.org,
linux-mm@kvack.org, devel@driverdev.osuosl.org,
linux-s390@vger.kernel.org, linux-rdma@vger.kernel.org,
David Airlie, linux-media@vger.kernel.org, Intel Linux Wireless,
intel-gfx@lists.freedesktop.org, Maarten Lankhorst, Jani Nikula,
Ian Abbott, Rodrigo Vivi, Sean Paul, moderated list:ARM PORT,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, H Hartley Sweeten,
iommu@lists.linux-foundation.org, Daniel Vetter
In-Reply-To: <4113cd5f-5c13-e9c7-bc5e-dcf0b60e7054@arm.com>
On Fri, Jun 14, 2019 at 04:05:33PM +0100, Robin Murphy wrote:
> That said, I don't believe this particular patch should make any
> appreciable difference - alloc_pages_exact() is still going to give back
> the same base address as the rounded up over-allocation would, and
> PAGE_ALIGN()ing the size passed to get_order() already seemed to be
> pointless.
True, we actually do get the right alignment just about anywhere.
Not 100% sure about the various static pool implementations, but we
can make sure if any didn't we'll do that right thing once those
get consolidated.
^ permalink raw reply
* Re: [PATCH 16/16] dma-mapping: use exact allocation in dma_alloc_contiguous
From: 'Christoph Hellwig' @ 2019-06-14 15:05 UTC (permalink / raw)
To: David Laight
Cc: 'Christoph Hellwig', Maarten Lankhorst, Maxime Ripard,
Sean Paul, David Airlie, Daniel Vetter, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Ian Abbott, H Hartley Sweeten,
Intel Linux Wireless, moderated list:ARM PORT,
dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
linux-rdma@vger.kernel.org, linux-media@vger.kernel.org,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
linux-s390@vger.kernel.org, devel@driverdev.osuosl.org,
linux-mm@kvack.org, iommu@lists.linux-foundation.org,
linux-kernel@vger.kernel.org
In-Reply-To: <d93fd4c2c1584d92a05dd641929f6d63@AcuMS.aculab.com>
On Fri, Jun 14, 2019 at 03:01:22PM +0000, David Laight wrote:
> I'm pretty sure there is a lot of code out there that makes that assumption.
> Without it many drivers will have to allocate almost double the
> amount of memory they actually need in order to get the required alignment.
> So instead of saving memory you'll actually make more be used.
That code would already be broken on a lot of Linux platforms.
^ permalink raw reply
* Re: [PATCH 16/16] dma-mapping: use exact allocation in dma_alloc_contiguous
From: Robin Murphy @ 2019-06-14 15:05 UTC (permalink / raw)
To: 'Christoph Hellwig', David Laight
Cc: Maxime Ripard, Joonas Lahtinen, dri-devel@lists.freedesktop.org,
linux-mm@kvack.org, devel@driverdev.osuosl.org,
linux-s390@vger.kernel.org, linux-rdma@vger.kernel.org,
David Airlie, linux-media@vger.kernel.org, Intel Linux Wireless,
intel-gfx@lists.freedesktop.org, Maarten Lankhorst, Jani Nikula,
Ian Abbott, Rodrigo Vivi, Sean Paul, moderated list:ARM PORT,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, H Hartley Sweeten,
iommu@lists.linux-foundation.org, Daniel Vetter
In-Reply-To: <20190614145001.GB9088@lst.de>
On 14/06/2019 15:50, 'Christoph Hellwig' wrote:
> On Fri, Jun 14, 2019 at 02:15:44PM +0000, David Laight wrote:
>> Does this still guarantee that requests for 16k will not cross a 16k boundary?
>> It looks like you are losing the alignment parameter.
>
> The DMA API never gave you alignment guarantees to start with,
> and you can get not naturally aligned memory from many of our
> current implementations.
Well, apart from the bit in DMA-API-HOWTO which has said this since
forever (well, before Git history, at least):
"The CPU virtual address and the DMA address are both
guaranteed to be aligned to the smallest PAGE_SIZE order which
is greater than or equal to the requested size. This invariant
exists (for example) to guarantee that if you allocate a chunk
which is smaller than or equal to 64 kilobytes, the extent of the
buffer you receive will not cross a 64K boundary."
That said, I don't believe this particular patch should make any
appreciable difference - alloc_pages_exact() is still going to give back
the same base address as the rounded up over-allocation would, and
PAGE_ALIGN()ing the size passed to get_order() already seemed to be
pointless.
Robin.
^ permalink raw reply
* RE: [PATCH 16/16] dma-mapping: use exact allocation in dma_alloc_contiguous
From: David Laight @ 2019-06-14 15:01 UTC (permalink / raw)
To: 'Christoph Hellwig'
Cc: Maarten Lankhorst, Maxime Ripard, Sean Paul, David Airlie,
Daniel Vetter, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Ian Abbott, H Hartley Sweeten, Intel Linux Wireless,
moderated list:ARM PORT, dri-devel@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, linux-rdma@vger.kernel.org,
linux-media@vger.kernel.org, netdev@vger.kernel.org,
linux-wireless@vger.kernel.org, linux-s390@vger.kernel.org,
devel@driverdev.osuosl.org, linux-mm@kvack.org,
iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
In-Reply-To: <20190614145001.GB9088@lst.de>
From: 'Christoph Hellwig'
> Sent: 14 June 2019 15:50
> To: David Laight
> On Fri, Jun 14, 2019 at 02:15:44PM +0000, David Laight wrote:
> > Does this still guarantee that requests for 16k will not cross a 16k boundary?
> > It looks like you are losing the alignment parameter.
>
> The DMA API never gave you alignment guarantees to start with,
> and you can get not naturally aligned memory from many of our
> current implementations.
Hmmm...
I thought that was even documented.
I'm pretty sure there is a lot of code out there that makes that assumption.
Without it many drivers will have to allocate almost double the
amount of memory they actually need in order to get the required alignment.
So instead of saving memory you'll actually make more be used.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [mac80211-next:master 17/20] drivers/net/wireless/intel/iwlwifi/dvm/rs.c:3317:3: error: 'const struct rate_control_ops' has no member named 'remove_sta_debugfs'; did you mean 'add_sta_debugfs'?
From: Johannes Berg @ 2019-06-14 14:58 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: kbuild test robot, kbuild-all, linux-wireless
In-Reply-To: <20190614143359.GA11550@kroah.com>
On Fri, 2019-06-14 at 16:33 +0200, Greg Kroah-Hartman wrote:
> Did you apply my "[PATCH 3/5] iwlwifi: dvm: no need to check return
> value of debugfs_create function" patch also to this tree? The 5th
> patch in the series depended on it :(
Yeah, my bad, sorry about that. I was not paying attention to the "5/5"
in patchwork, and the other patches got assigned to other maintainers so
I didn't see them there.
I've dropped the patch for now, until that's all sorted out. Or maybe
Kalle will just take them all together.
johannes
^ permalink raw reply
* Re: [PATCH-v3 1/2] wireless: Support assoc-at-ms timer in sta-info
From: Johannes Berg @ 2019-06-14 14:56 UTC (permalink / raw)
To: Ben Greear, linux-wireless
In-Reply-To: <3ad69c55-2b88-a96b-d21e-99f4418466ee@candelatech.com>
On Fri, 2019-06-14 at 07:46 -0700, Ben Greear wrote:
>
> The point of my patch was to allow 'iw' to return a more precise time
> that the station has been associated, so I am not sure that BOOTIME is
> a good thing to use for that?
Depends what you want, really.
> + if (sinfo[NL80211_STA_INFO_ASSOC_AT_MS])
> + printf("\n\tassociated at:\t%llu ms",
> + (unsigned long long)nla_get_u64(sinfo[NL80211_STA_INFO_ASSOC_AT_MS]));
>
> - printf("\n");
> + printf("\n\tcurrent time:\t%llu ms\n", now_ms);
Since you just print the time in milliseconds, and the current time in
milliseconds, you don't even really have any value in the wall clock.
Quite the opposite - this lends itself to subtracting to try to figure
out how long it was associated, which is the completely wrong thing to
do with wall clock - timezone adjustment could've happened inbetween,
for example!
I really see no point in trying to give the wall clock at assoc time. If
no timezone adjustment happened, you can just as well give the boottime
and have the userspace figure out the wall clock. If timezone adjustment
happened, then any calculations are wrong anyway, what would the point
be?
johannes
^ permalink raw reply
* Re: [PATCH 16/16] dma-mapping: use exact allocation in dma_alloc_contiguous
From: 'Christoph Hellwig' @ 2019-06-14 14:50 UTC (permalink / raw)
To: David Laight
Cc: 'Christoph Hellwig', Maarten Lankhorst, Maxime Ripard,
Sean Paul, David Airlie, Daniel Vetter, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Ian Abbott, H Hartley Sweeten,
Intel Linux Wireless, moderated list:ARM PORT,
dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
linux-rdma@vger.kernel.org, linux-media@vger.kernel.org,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
linux-s390@vger.kernel.org, devel@driverdev.osuosl.org,
linux-mm@kvack.org, iommu@lists.linux-foundation.org,
linux-kernel@vger.kernel.org
In-Reply-To: <a90cf7ec5f1c4166b53c40e06d4d832a@AcuMS.aculab.com>
On Fri, Jun 14, 2019 at 02:15:44PM +0000, David Laight wrote:
> Does this still guarantee that requests for 16k will not cross a 16k boundary?
> It looks like you are losing the alignment parameter.
The DMA API never gave you alignment guarantees to start with,
and you can get not naturally aligned memory from many of our
current implementations.
^ permalink raw reply
* Re: [PATCH 12/16] staging/comedi: mark as broken
From: Christoph Hellwig @ 2019-06-14 14:48 UTC (permalink / raw)
To: Greg KH
Cc: Christoph Hellwig, Maarten Lankhorst, Maxime Ripard, Sean Paul,
David Airlie, Daniel Vetter, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Ian Abbott, H Hartley Sweeten, devel, linux-s390,
Intel Linux Wireless, linux-rdma, netdev, intel-gfx,
linux-wireless, linux-kernel, dri-devel, linux-mm, iommu,
moderated list:ARM PORT, linux-media
In-Reply-To: <20190614140239.GA7234@kroah.com>
On Fri, Jun 14, 2019 at 04:02:39PM +0200, Greg KH wrote:
> Perhaps a hint as to how we can fix this up? This is the first time
> I've heard of the comedi code not handling dma properly.
It can be fixed by:
a) never calling virt_to_page (or vmalloc_to_page for that matter)
on dma allocation
b) never remapping dma allocation with conflicting cache modes
(no remapping should be doable after a) anyway).
^ permalink raw reply
* Re: [PATCH-v3 1/2] wireless: Support assoc-at-ms timer in sta-info
From: Ben Greear @ 2019-06-14 14:46 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
In-Reply-To: <21fa668485f4eb0a8056aac1797854f267d5f1e0.camel@sipsolutions.net>
On 6/14/19 6:38 AM, Johannes Berg wrote:
> On Mon, 2019-04-15 at 10:21 -0700, greearb@candelatech.com wrote:
>> From: Ben Greear <greearb@candelatech.com>
>>
>> Report time stamp of when sta became associated.
>
> I guess that makes sense.
>
>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>> ---
>> include/net/cfg80211.h | 2 ++
>> include/uapi/linux/nl80211.h | 2 ++
>> net/wireless/nl80211.c | 1 +
>> 3 files changed, 5 insertions(+)
>>
>> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
>> index f49eb1464b7a..a3ad78b9d9f4 100644
>> --- a/include/net/cfg80211.h
>> +++ b/include/net/cfg80211.h
>> @@ -1268,6 +1268,7 @@ struct cfg80211_tid_stats {
>> * indicate the relevant values in this struct for them
>> * @connected_time: time(in secs) since a station is last connected
>> * @inactive_time: time since last station activity (tx/rx) in milliseconds
>> + * @assoc_at_ms: time in ms of the last association
>
> I think the "_at_ms" doesn't really make sense. "time in ms" also
> doesn't make sense as documentation. I think you need to say what should
> be assigned here.
>
> Also, you're actually using ktime_get_real() for this, which again
> doesn't make much sense. For exposing an absolute time, I think we're
> better off with CLOCK_BOOTTIME like we use elsewhere:
The point of my patch was to allow 'iw' to return a more precise time
that the station has been associated, so I am not sure that BOOTIME is
a good thing to use for that?
Here are the pertinent parts of my iw patches:
diff --git a/station.c b/station.c
index 25cbbc3..e7738cc 100644
--- a/station.c
+++ b/station.c
@@ -314,6 +314,12 @@ static int print_sta_handler(struct nl_msg *msg, void *arg)
[NL80211_STA_INFO_ACK_SIGNAL_AVG] = { .type = NLA_U8 },
};
char *chain;
+ struct timeval now;
+ unsigned long long now_ms;
+
+ gettimeofday(&now, NULL);
+ now_ms = now.tv_sec * 1000;
+ now_ms += (now.tv_usec / 1000);
nla_parse(tb, NL80211_ATTR_MAX, genlmsg_attrdata(gnlh, 0),
genlmsg_attrlen(gnlh, 0), NULL);
@@ -557,8 +563,11 @@ static int print_sta_handler(struct nl_msg *msg, void *arg)
if (sinfo[NL80211_STA_INFO_CONNECTED_TIME])
printf("\n\tconnected time:\t%u seconds",
nla_get_u32(sinfo[NL80211_STA_INFO_CONNECTED_TIME]));
+ if (sinfo[NL80211_STA_INFO_ASSOC_AT_MS])
+ printf("\n\tassociated at:\t%llu ms",
+ (unsigned long long)nla_get_u64(sinfo[NL80211_STA_INFO_ASSOC_AT_MS]));
- printf("\n");
+ printf("\n\tcurrent time:\t%llu ms\n", now_ms);
return NL_SKIP;
}
Thanks,
Ben
>
> * @boottime_ns: CLOCK_BOOTTIME timestamp the frame was received at, this is
> * needed only for beacons and probe responses that update the scan cache.
>
>
>> + * @NL80211_STA_INFO_ASSOC_AT_MS: Timestamp of last association
>
> _ASSOC_TIMESTAMP or something would make more sense too as the attribute
> name, and clearly the documentation needs to spell out the semantics
> here too.
>
> johannes
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply related
* Re: [mac80211-next:master 17/20] drivers/net/wireless/intel/iwlwifi/dvm/rs.c:3317:3: error: 'const struct rate_control_ops' has no member named 'remove_sta_debugfs'; did you mean 'add_sta_debugfs'?
From: Greg Kroah-Hartman @ 2019-06-14 14:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: kbuild test robot, kbuild-all, linux-wireless
In-Reply-To: <201906142122.HSTAYprn%lkp@intel.com>
On Fri, Jun 14, 2019 at 09:17:28PM +0800, kbuild test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git master
> head: 499169fb3a5a27b8322cdd559a09e79e390c211b
> commit: d3f7e94bc458dd1b20bef591ee2b82e2ae631858 [17/20] mac80211: remove unused and unneeded remove_sta_debugfs callback
> config: xtensa-allyesconfig (attached as .config)
> compiler: xtensa-linux-gcc (GCC) 7.4.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout d3f7e94bc458dd1b20bef591ee2b82e2ae631858
> # save the attached .config to linux build tree
> GCC_VERSION=7.4.0 make.cross ARCH=xtensa
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot <lkp@intel.com>
>
> All errors (new ones prefixed by >>):
>
> >> drivers/net/wireless/intel/iwlwifi/dvm/rs.c:3317:3: error: 'const struct rate_control_ops' has no member named 'remove_sta_debugfs'; did you mean 'add_sta_debugfs'?
> .remove_sta_debugfs = rs_remove_debugfs,
> ^~~~~~~~~~~~~~~~~~
> add_sta_debugfs
Did you apply my "[PATCH 3/5] iwlwifi: dvm: no need to check return
value of debugfs_create function" patch also to this tree? The 5th
patch in the series depended on it :(
thanks,
greg k-h
> >> drivers/net/wireless/intel/iwlwifi/dvm/rs.c:3317:24: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
> .remove_sta_debugfs = rs_remove_debugfs,
> ^~~~~~~~~~~~~~~~~
> drivers/net/wireless/intel/iwlwifi/dvm/rs.c:3317:24: note: (near initialization for 'rs_ops.get_expected_throughput')
> cc1: some warnings being treated as errors
> --
> >> drivers/net/wireless/intel/iwlwifi/mvm/rs.c:4138:3: error: 'const struct rate_control_ops' has no member named 'remove_sta_debugfs'; did you mean 'add_sta_debugfs'?
> .remove_sta_debugfs = rs_remove_sta_debugfs,
> ^~~~~~~~~~~~~~~~~~
> add_sta_debugfs
> >> drivers/net/wireless/intel/iwlwifi/mvm/rs.c:4138:24: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
> .remove_sta_debugfs = rs_remove_sta_debugfs,
> ^~~~~~~~~~~~~~~~~~~~~
> drivers/net/wireless/intel/iwlwifi/mvm/rs.c:4138:24: note: (near initialization for 'rs_mvm_ops_drv.get_expected_throughput')
> cc1: some warnings being treated as errors
> --
> >> drivers/net//wireless/intel/iwlegacy/4965-rs.c:2815:3: error: 'const struct rate_control_ops' has no member named 'remove_sta_debugfs'; did you mean 'add_sta_debugfs'?
> .remove_sta_debugfs = il4965_rs_remove_debugfs,
> ^~~~~~~~~~~~~~~~~~
> add_sta_debugfs
> >> drivers/net//wireless/intel/iwlegacy/4965-rs.c:2815:24: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
> .remove_sta_debugfs = il4965_rs_remove_debugfs,
> ^~~~~~~~~~~~~~~~~~~~~~~~
> drivers/net//wireless/intel/iwlegacy/4965-rs.c:2815:24: note: (near initialization for 'rs_4965_ops.get_expected_throughput')
> cc1: some warnings being treated as errors
>
> vim +3317 drivers/net/wireless/intel/iwlwifi/dvm/rs.c
>
> 631ad703b drivers/net/wireless/iwlwifi/dvm/rs.c Johannes Berg 2014-01-20 3305
> 631ad703b drivers/net/wireless/iwlwifi/dvm/rs.c Johannes Berg 2014-01-20 3306 static const struct rate_control_ops rs_ops = {
> b481de9ca drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi 2007-09-25 3307 .name = RS_NAME,
> b481de9ca drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi 2007-09-25 3308 .tx_status = rs_tx_status,
> b481de9ca drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi 2007-09-25 3309 .get_rate = rs_get_rate,
> fe6b23dd3 drivers/net/wireless/iwlwifi/iwl-agn-rs.c Reinette Chatre 2010-02-22 3310 .rate_init = rs_rate_init_stub,
> b481de9ca drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi 2007-09-25 3311 .alloc = rs_alloc,
> b481de9ca drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi 2007-09-25 3312 .free = rs_free,
> b481de9ca drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi 2007-09-25 3313 .alloc_sta = rs_alloc_sta,
> b481de9ca drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi 2007-09-25 3314 .free_sta = rs_free_sta,
> 93dc646ad drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi 2007-09-27 3315 #ifdef CONFIG_MAC80211_DEBUGFS
> 93dc646ad drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi 2007-09-27 3316 .add_sta_debugfs = rs_add_debugfs,
> 93dc646ad drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi 2007-09-27 @3317 .remove_sta_debugfs = rs_remove_debugfs,
> 93dc646ad drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi 2007-09-27 3318 #endif
> b481de9ca drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi 2007-09-25 3319 };
> b481de9ca drivers/net/wireless/iwlwifi/iwl-4965-rs.c Zhu Yi 2007-09-25 3320
>
> :::::: The code at line 3317 was first introduced by commit
> :::::: 93dc646adb94127ca1c2e74275a85265ec57b9af [PATCH] iwlwifi: add debugfs framework to rate scale
>
> :::::: TO: Zhu Yi <yi.zhu@intel.com>
> :::::: CC: David S. Miller <davem@sunset.davemloft.net>
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* pull-request: mac80211-next 2019-06-14
From: Johannes Berg @ 2019-06-14 14:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
And ... here's a -next pull request. Nothing really major here,
see more details below.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit cec4f328c929f72ad634e8f385b589bd6eac80e5:
enetc: fix le32/le16 degrading to integer warnings (2019-05-27 10:12:08 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2019-06-14
for you to fetch changes up to ddb754aa31813fd17d8374eba881827e6e2c85c6:
mac80211: notify offchannel expire on mgmt_tx (2019-06-14 16:08:28 +0200)
----------------------------------------------------------------
Many changes all over:
* HE (802.11ax) work continues
* WPA3 offloads
* work on extended key ID handling continues
* fixes to honour AP supported rates with auth/assoc frames
* nl80211 netlink policy improvements to fix some issues
with strict validation on new commands with old attrs
----------------------------------------------------------------
Alexander Wetzel (1):
mac80211: AMPDU handling for Extended Key ID
Chaitanya Tata (1):
cfg80211: Handle bss expiry during connection
Chung-Hsien Hsu (3):
nl80211: add NL80211_ATTR_IFINDEX to port authorized event
nl80211: add WPA3 definition for SAE authentication
nl80211: add support for SAE authentication offload
Greg Kroah-Hartman (1):
mac80211: no need to check return value of debugfs_create functions
Ilan Peer (2):
cfg80211: Add a function to iterate all BSS entries
ieee80211: Add a missing extended capability flag definition
James Prestwood (2):
nl80211: send event when CMD_FRAME duration expires
mac80211: notify offchannel expire on mgmt_tx
Johannes Berg (6):
nl80211: fill all policy .type entries
nl80211: require and validate vendor command policy
mac80211: call rate_control_send_low() internally
mac80211: use STA info in rate_control_send_low()
mac80211: fill low rate even for HAS_RATE_CONTROL
mac80211: extend __rate_control_send_low warning
John Crispin (3):
mac80211: add ieee80211_get_he_iftype_cap() helper
mac80211: dynamically enable the TWT requester support on STA interfaces
mac80211: allow turning TWT responder support on and off via netlink
.../driver-api/80211/mac80211-advanced.rst | 3 -
drivers/net/wireless/intel/iwlegacy/3945-rs.c | 3 -
drivers/net/wireless/intel/iwlegacy/4965-rs.c | 4 -
drivers/net/wireless/intel/iwlwifi/dvm/rs.c | 4 -
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 4 -
drivers/net/wireless/mac80211_hwsim.c | 2 +
drivers/net/wireless/realtek/rtlwifi/rc.c | 3 -
include/linux/ieee80211.h | 8 ++
include/net/cfg80211.h | 82 +++++++++--
include/net/mac80211.h | 32 ++---
include/net/netlink.h | 9 ++
include/uapi/linux/nl80211.h | 24 ++++
net/mac80211/cfg.c | 8 +-
net/mac80211/debugfs.c | 1 +
net/mac80211/debugfs_key.c | 3 -
net/mac80211/debugfs_netdev.c | 10 +-
net/mac80211/debugfs_sta.c | 2 -
net/mac80211/key.c | 100 +++++++------
net/mac80211/mlme.c | 25 +++-
net/mac80211/offchannel.c | 4 +
net/mac80211/rate.c | 27 ++--
net/mac80211/rc80211_minstrel.c | 4 -
net/mac80211/rc80211_minstrel_ht.c | 3 -
net/mac80211/sta_info.c | 43 +++++-
net/wireless/core.c | 13 ++
net/wireless/core.h | 4 +
net/wireless/nl80211.c | 155 +++++++++++++++++----
net/wireless/scan.c | 33 ++++-
net/wireless/sme.c | 32 ++++-
net/wireless/trace.h | 18 +++
30 files changed, 495 insertions(+), 168 deletions(-)
^ permalink raw reply
* RE: [PATCH 16/16] dma-mapping: use exact allocation in dma_alloc_contiguous
From: David Laight @ 2019-06-14 14:15 UTC (permalink / raw)
To: 'Christoph Hellwig', Maarten Lankhorst, Maxime Ripard,
Sean Paul, David Airlie, Daniel Vetter, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Ian Abbott, H Hartley Sweeten
Cc: Intel Linux Wireless, moderated list:ARM PORT,
dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
linux-rdma@vger.kernel.org, linux-media@vger.kernel.org,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
linux-s390@vger.kernel.org, devel@driverdev.osuosl.org,
linux-mm@kvack.org, iommu@lists.linux-foundation.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190614134726.3827-17-hch@lst.de>
From: Christoph Hellwig
> Sent: 14 June 2019 14:47
>
> Many architectures (e.g. arm, m68 and sh) have always used exact
> allocation in their dma coherent allocator, which avoids a lot of
> memory waste especially for larger allocations. Lift this behavior
> into the generic allocator so that dma-direct and the generic IOMMU
> code benefit from this behavior as well.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> include/linux/dma-contiguous.h | 8 +++++---
> kernel/dma/contiguous.c | 17 +++++++++++------
> 2 files changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/include/linux/dma-contiguous.h b/include/linux/dma-contiguous.h
> index c05d4e661489..2e542e314acf 100644
> --- a/include/linux/dma-contiguous.h
> +++ b/include/linux/dma-contiguous.h
> @@ -161,15 +161,17 @@ static inline struct page *dma_alloc_contiguous(struct device *dev, size_t size,
> gfp_t gfp)
> {
> int node = dev ? dev_to_node(dev) : NUMA_NO_NODE;
> - size_t align = get_order(PAGE_ALIGN(size));
> + void *cpu_addr = alloc_pages_exact_node(node, size, gfp);
>
> - return alloc_pages_node(node, gfp, align);
> + if (!cpu_addr)
> + return NULL;
> + return virt_to_page(p);
> }
Does this still guarantee that requests for 16k will not cross a 16k boundary?
It looks like you are losing the alignment parameter.
There may be drivers and hardware that also require 12k allocates
to not cross 16k boundaries (etc).
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH v3 2/3] mac80211: implement HE support for mesh
From: Johannes Berg @ 2019-06-14 14:14 UTC (permalink / raw)
To: Sven Eckelmann; +Cc: linux-wireless, ath11k
In-Reply-To: <2194147.kqlnQF7k4C@bentobox>
On Fri, 2019-06-14 at 16:13 +0200, Sven Eckelmann wrote:
> On Friday, 14 June 2019 16:11:15 CEST Johannes Berg wrote:
> > > + ie_len = 2 + 1 +
> > > + sizeof(he_cap->he_cap_elem) + n +
> > > + ieee80211_he_ppe_size(he_cap->ppe_thres[0],
> > > + he_cap->he_cap_elem.phy_cap_info);
> > > +
> > > + return ie_len;
> >
> > There's no value in the "ie_len" variable here.
>
> Sorry, my parser just broke. Why is there no value in ie_len? Was just
> assigned a line before. Or are you talking about something else?
Heh, sorry. I mean, there's no value in having the variable, you could
just
return 2 + 1 + ...
johannes
^ permalink raw reply
* Re: [PATCH v3 2/3] mac80211: implement HE support for mesh
From: Sven Eckelmann @ 2019-06-14 14:13 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, ath11k
In-Reply-To: <8d0d11ca39b6216b24cf4e9e3a1522072db5c0d2.camel@sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 530 bytes --]
On Friday, 14 June 2019 16:11:15 CEST Johannes Berg wrote:
> > + ie_len = 2 + 1 +
> > + sizeof(he_cap->he_cap_elem) + n +
> > + ieee80211_he_ppe_size(he_cap->ppe_thres[0],
> > + he_cap->he_cap_elem.phy_cap_info);
> > +
> > + return ie_len;
>
> There's no value in the "ie_len" variable here.
Sorry, my parser just broke. Why is there no value in ie_len? Was just
assigned a line before. Or are you talking about something else?
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/3] mac80211: implement HE support for mesh
From: Johannes Berg @ 2019-06-14 14:11 UTC (permalink / raw)
To: Sven Eckelmann, linux-wireless; +Cc: ath11k, Sven Eckelmann
In-Reply-To: <20190612193510.29489-3-sven@narfation.org>
On Wed, 2019-06-12 at 21:35 +0200, Sven Eckelmann wrote:
>
> +u8 ieee80211_ie_len_he_cap(struct ieee80211_sub_if_data *sdata)
> +{
> + const struct ieee80211_sta_he_cap *he_cap;
> + struct ieee80211_supported_band *sband;
> + u8 ie_len;
> + u8 n;
> +
> + sband = ieee80211_get_sband(sdata);
> + if (!sband)
> + return 0;
> +
> + he_cap = ieee80211_get_he_mesh_cap(sband);
> + if (!he_cap)
> + return 0;
> +
> + n = ieee80211_he_mcs_nss_size(&he_cap->he_cap_elem);
> + ie_len = 2 + 1 +
> + sizeof(he_cap->he_cap_elem) + n +
> + ieee80211_he_ppe_size(he_cap->ppe_thres[0],
> + he_cap->he_cap_elem.phy_cap_info);
> +
> + return ie_len;
There's no value in the "ie_len" variable here.
johannes
^ permalink raw reply
* Re: [PATCH v3 0/3] mac80211/ath11k: HE mesh support
From: Johannes Berg @ 2019-06-14 14:10 UTC (permalink / raw)
To: Sven Eckelmann, linux-wireless; +Cc: ath11k
In-Reply-To: <20190612193510.29489-1-sven@narfation.org>
Hi Sven,
Two comments:
1) It seems to me that patches 1/2 really should be in opposite order,
since you can't really claim HE mesh support in hwsim when you don't
have it in mac80211?
Or maybe I misunderstand?
2) This series breaks the wpas_mesh_max_peering wpa_supplicant/hwsim
test, and I'm not sure why. Perhaps some length calculations are bad?
johannes
^ permalink raw reply
* Re: [PATCH v2] Revert "cfg80211: fix processing world regdomain when non modular"
From: Hodaszi, Robert @ 2019-06-14 14:06 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <6a9c7642a2fcca60658036c605438ff2ac982bd0.camel@sipsolutions.net>
*From:* Johannes Berg <johannes@sipsolutions.net>
*Sent:* Friday, June 14, 2019 4:01PM
*To:* Hodaszi, Robert <Robert.Hodaszi@digi.com>
*Cc:* Linux-wireless <linux-wireless@vger.kernel.org>
*Subject:* Re: [PATCH v2] Revert "cfg80211: fix processing world
regdomain when non modular"
> On Fri, 2019-06-14 at 13:58 +0000, Hodaszi, Robert wrote:
>> I didn't just resend that. I just realized, accidentally I forgot to fix
>> the debug message printing function, that define doesn't exist anymore.
>> Sorry for the confusion!
> Oops. I looked too superficially then and didn't even see the
> difference, sorry.
>
> I guess that's why Kalle always says you should have a patch changelog
> :-)
Shame on me, I was able to make a bug in a one-line change. :)
>
>> Under "original issue", you mean the issue, which commit
>> 96cce12ff6e0bc9d9fcb2235e08b7fc150f96fd2 (cfg80211: fix processing world
>> regdomain when non modular) supposed to fix?
> Yes.
>
>> That still won't work, but
>> that didn't work neither before I reverted the patch, because crda call
>> timeout will just drop the last packet. Also, as it re-processed the
>> last request, not just resent it, it caused undesired states. Like when
>> I used 2 WiFi modules with US regulatory domains, after enumeration, my
>> global regulator domain was set to "Country 98".
>>
>> To fix my issue, why I reverted the patch, and also fix the issue the
>> reverted commit supposed to fix, I could imagine something like this.
>> But I'm not sure, it doesn't have any side effect:
> [snip]
>
> Ok, thanks. I guess I'll have to look at this in more detail.
>
> You don't happen to have a way to reproduce either issue with a hwsim
> test case?
>
> johannes
>
To tell the truth, I never tried hwsim. But it's pretty trivial to repro
it. You just need 2 WiFi modules, and put e.g. a "sleep 1" into the udev
or mdev script, before it would call the "crda". That should trigger the
issue immediately. After that change, I just did an "rmmod ath10k_pci;
modprobe ath10k_pci", and bumm, "iw reg get" will should "Country 98".
Robert
^ permalink raw reply
* Re: [PATCH 12/16] staging/comedi: mark as broken
From: Greg KH @ 2019-06-14 14:02 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Maarten Lankhorst, Maxime Ripard, Sean Paul, David Airlie,
Daniel Vetter, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Ian Abbott, H Hartley Sweeten, devel, linux-s390,
Intel Linux Wireless, linux-rdma, netdev, intel-gfx,
linux-wireless, linux-kernel, dri-devel, linux-mm, iommu,
moderated list:ARM PORT, linux-media
In-Reply-To: <20190614134726.3827-13-hch@lst.de>
On Fri, Jun 14, 2019 at 03:47:22PM +0200, Christoph Hellwig wrote:
> comedi_buf.c abuse the DMA API in gravely broken ways, as it assumes it
> can call virt_to_page on the result, and the just remap it as uncached
> using vmap. Disable the driver until this API abuse has been fixed.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/staging/comedi/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/staging/comedi/Kconfig b/drivers/staging/comedi/Kconfig
> index 049b659fa6ad..e7c021d76cfa 100644
> --- a/drivers/staging/comedi/Kconfig
> +++ b/drivers/staging/comedi/Kconfig
> @@ -1,6 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0
> config COMEDI
> tristate "Data acquisition support (comedi)"
> + depends on BROKEN
Um, that's a huge sledgehammer.
Perhaps a hint as to how we can fix this up? This is the first time
I've heard of the comedi code not handling dma properly.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2] Revert "cfg80211: fix processing world regdomain when non modular"
From: Johannes Berg @ 2019-06-14 14:01 UTC (permalink / raw)
To: Hodaszi, Robert; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <32951d52-3f9d-aaee-fa07-75585c03edba@digi.com>
On Fri, 2019-06-14 at 13:58 +0000, Hodaszi, Robert wrote:
>
> I didn't just resend that. I just realized, accidentally I forgot to fix
> the debug message printing function, that define doesn't exist anymore.
> Sorry for the confusion!
Oops. I looked too superficially then and didn't even see the
difference, sorry.
I guess that's why Kalle always says you should have a patch changelog
:-)
> Under "original issue", you mean the issue, which commit
> 96cce12ff6e0bc9d9fcb2235e08b7fc150f96fd2 (cfg80211: fix processing world
> regdomain when non modular) supposed to fix?
Yes.
> That still won't work, but
> that didn't work neither before I reverted the patch, because crda call
> timeout will just drop the last packet. Also, as it re-processed the
> last request, not just resent it, it caused undesired states. Like when
> I used 2 WiFi modules with US regulatory domains, after enumeration, my
> global regulator domain was set to "Country 98".
>
> To fix my issue, why I reverted the patch, and also fix the issue the
> reverted commit supposed to fix, I could imagine something like this.
> But I'm not sure, it doesn't have any side effect:
[snip]
Ok, thanks. I guess I'll have to look at this in more detail.
You don't happen to have a way to reproduce either issue with a hwsim
test case?
johannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox