Hi,
Instead of letting uhidev drivers get the report sizes, do it once in
uhidev and pass the same sizes as part of the attach arguments. Makes
the uhidev drivers a bit less repetitive. Note that each call to
uhidev_get_report_size() requires one malloc() and a full traversal of
the HID report.
On Wed, Sep 08, 2021 at 06:08:53PM +0200, Claudio Jeker wrote:
> On Wed, Sep 08, 2021 at 05:40:31PM +0200, Theo Buehler wrote:
> > On Wed, Sep 08, 2021 at 03:05:41PM +0200, Claudio Jeker wrote:
> > > Looking at profiling information and the code made me realize that these
> > > recallocarray calls
On Wed, Sep 08, 2021 at 05:40:31PM +0200, Theo Buehler wrote:
> On Wed, Sep 08, 2021 at 03:05:41PM +0200, Claudio Jeker wrote:
> > Looking at profiling information and the code made me realize that these
> > recallocarray calls growing the array by one every time are unnecessary.
> > The size of
On Wed, Sep 08, 2021 at 03:05:41PM +0200, Claudio Jeker wrote:
> Looking at profiling information and the code made me realize that these
> recallocarray calls growing the array by one every time are unnecessary.
> The size of the array is known in advance so use that information and
> build it up
On Tue, 07 Sep 2021 21:38:27 +0200, Mark Kettenis wrote:
> I'm not convinced the original diff is right:
>
> * We have several places in the kernel where we store numbers of pages
> in a (32-bit) int. Changing just one of these places is dangerous.
>
> * Changing the type of just vm_dsize
On Wed, Sep 08, 2021 at 02:19:00PM +0200, Stefan Sperling wrote:
> This patch applies on top of all the other iwx(4) diffs I've sent today.
> It makes iwx(4) initialize the device completely in the acpi thread.
>
> We now prepare the device for loading firmware during DVACT_RESUME,
> and load
Looking at profiling information and the code made me realize that these
recallocarray calls growing the array by one every time are unnecessary.
The size of the array is known in advance so use that information and
build it up ahead of time.
In the roa case the IP list is double nested and so
This patch applies on top of all the other iwx(4) diffs I've sent today.
It makes iwx(4) initialize the device completely in the acpi thread.
We now prepare the device for loading firmware during DVACT_RESUME,
and load firmware from host memory into the device during DVACT_WAKEUP.
Previously,
Add a missing call to iwx_ctxt_info_free_fw_img() in an error path
of iwx_ctxt_info_init() which should always free on error.
Also, free firmware paging DMA memory in case loading firmware has failed.
If we don't free paging on error we hit KASSERT(dram->paging == NULL)
in iwx_init_fw_sec() once
On Wed, Sep 08, 2021 at 11:45:25AM +0200, Stefan Sperling wrote:
> I will fix the splnet() issue separately later.
And here is the patch for missing splnet() while loading firmware.
ok?
diff 5ebc9004f07f27c14bbae5eb2e8cab3d8cf3446d
a34aaba3c6977adc3012688a6d24ef6d0499df07
blob -
With 'ifconfig debug' and 11n block ack sessions we see messages such as:
iwm0: sending action to xx:xx:xx:xx:xx:xx
Which is not very informative.
It would be more useful to show the type of action frame being sent.
The patch below implements this for the types we currently care about.
On Tue, Sep 07, 2021 at 07:29:37PM +0200, Martin Pieuchot wrote:
> On 07/09/21(Tue) 18:03, Stefan Sperling wrote:
> > On Tue, Sep 07, 2021 at 05:16:52PM +0200, Martin Pieuchot wrote:
> > > On 07/09/21(Tue) 15:48, Stefan Sperling wrote:
> > > > This patch makes iwx(4) resume reliably for me.
> > >
On 07/09/21(Tue) 14:19, Patrick Wildt wrote:
> Hi,
>
> I was playing around a little with the mutex code and found that on
> arm64 there some uninitialized mutexes out there.
>
> I think the arm64 specific one is comparatively easy to solve. We
> either initialize the mtx when we initialize the
13 matches
Mail list logo
