If device is not found, 'list' is allocated to size 0.
So, modify function to return 0 as FreeBSD's subr_bus.c
when 'count' is 0.
Pointed out by Clang Static Analyzer.
Change-Id: Ice24ae939bfcdb6e1276a86dba40d0b689030fbb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3753
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Fix value stored to 'newPowerManagementStatus' is never read.
Pointed out by Clang Static Analyzer.
It seems FreeBSD's pci_set_powerstate_method() writes 'status'
(newPowerManagementStatus in Haiku) with PCI_WRITE_CONFIG
(pci_write_config in Haiku).
Change-Id: I9b11f746ed8e772a3f839e1bd5a6b432c9e8ff6b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3513
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This is a version of the qsort function allowing you to pass a "cookie" to the function.
Change-Id: I60c645213b9c9590e38b112634fcac1d7969b6d9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2449
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This adds the upper 32 bits for address and size.
Change-Id: I2f776c7b8b72ecefca9f3b93d9c42912666a41e2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3026
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Factor out the conversion to BAR index and hand the pci_info to both
memory and IO port allocation functions. Then apply the same checks
in the IO port case as are done for memory.
This aligns with what is done on FreeBSD.
Change-Id: Ib4bd28fd861959a467ba676de22efb1f97e5a27c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3025
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The check as to whether or not the buf should be freed was wrong,
leading to incorrect frees.
Fixes double-free KDLs under the idualwifi driver that occur
on boot extremely frequently.
Change-Id: Ia411a6f5c31dd30764705cd87840797f862b4020
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2862
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The parser was based on an old example from agg. NanoSVG is originally
based on the same code, but has lots of bugfixes. So it makes sense
to use it.
Nanosvg revision 25241c5a8f8451d41ab1b02ab2d865b01600d949
Fixes #5955, #8586, #13021.
Change-Id: I38ff9aa4e1d403c41979ebe42f7b45d4500a870c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2661
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
- Use gcc builtin
- Define as a static inline function in the .h so no function call overhead is needed
- Keep the function in libroot for backwards compatibility
- Remove a duplicate implementation in the freebsd compatibility layer
gcc2 does not document the builtin, but it is in fact already available
there as well.
Fixes #3281.
Change-Id: I94f8a2548637aa70e85febbfab06f07c1a427005
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2605
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
wpa_supplicant needs to be rebuilt
against it and then this needs to be tested.
Added some FIXMEs to keep track of places I'm not sure if we need to
change anything.
Fixes #14805
Change-Id: I6379dc32b772289960afbfb362365a542a986983
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2225
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Somehow, I missed this when implementing MTX_SPIN in the first place,
and it went largely unnoticed because MTX_SPIN is rarely used and
apparently even more rarely destroyed.
Should fix #15749.
This header was not included when Haiku is built with KDEBUG_LEVEL=0,
causing build failures.
Change-Id: I690064f7c1a9818056a394e2655811775c4cc554
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2360
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
libprint had a very conservative size limitation (4MB) for the bitmap it
allocates. This leads to splitting a page to print in several "bands"
(about 5 in my testing). However, these may still be too large for the
printer driver to handle, which means the driver may be further slicing
things up, or other drivers may need the full page anyway and recompose
it in some way.
Instead of an hardcoded limit, now try to allocate a bitmap for the
whole page, and if that doesn't work, progressively increase the number
of bands until we manage to allocate a bitmap. Stop when we have split
the page in 256 bands, as it seems rather pointless to be that far. Call
debugger when this happens, as there doesn't seem to be a way to do
better error handling here (the code used to raise std::bad_alloc if
BBitmap allocation failed, or just return an invalid bitmap and view).
Change-Id: Iba690f68c748d20828709244a23e82a08185390e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1922
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
- Factor in types changes (introduction of intptr_t)
- Align JamFiles syntax with in progress architectures (arm/sparc)
- Xorriso doesn't support much of the mkisofs options (anymore ?)
- (After a correct bootstrap) one should be able to build @minimum-raw and haiku-boot-cd again
Change-Id: I4f779ad8f2210389fa9b7f7c0a98c3652a64c257
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1983
Reviewed-by: François Revol <revol@free.fr>
It seems some drivers do not create dmamaps for all their bustags,
so we can't allocate the segments there. And of course, some also
do not go through dmamem_alloc, so the only option then is to revert
to where FreeBSD allocates them, inside dmamap_load.
It seems that some drivers (e.g. broadcom43xx) create a parent DMA tag
with nsegments set to BUS_SPACE_UNRESTRICTED, i.e. MAX_INT, which of
course fails allocation, expecting to never allocate memory for this
tag, only for child tags. So in order to handle this, we have to
delay allocating the segment array until we are certain that the nsegments
value is the "real deal".
Doing it in dmamap_load would be fine, but as there is more than one
entry point to that, we would have to allocate this in multiple places.
dmamap_create() must be called and there is only one way through it,
so put the allocation there.
Fixes #15500 (i.e. both the KDL and the underlying problem that
led to it; it only crashed because the wrong pointer was passed
to kernel_free, whoops.)
The old implementation was based on an ancient copy of the FreeBSD
busdma code for x86, and did not make a bunch of assumptions that
we make basically everywhere else (for instance, that we can request
arbitrarily-aligned contiguous physical memory from the VM.)
As a consequence, it had a significant amount of code devoted to
bounce pages, which are just a waste of resources on x86, and
for that matter, probably any other architecture Haiku will ever
be ported to. (Even if we do need to run on some system where
only a small portion of system memory can be accessed by devices,
likely we would reserve that memory for just this occasion anyway.)
I was initially under the impression that the bounce-pages code
never turned on, but apparently due to the "alignment" check
(and also the "Maxmem" check, which was to defined to 32KB...?!)
it does indeed activate on a variety of systems, and maybe
(in the case of drivers that do not call sync() properly) even
is the cause of some of our ported driver breakage.
The new implementation is pretty much optimized for Haiku,
and shares almost no code or structure with the old one (save
for a few functions that really only have one proper implementation.)
Tested with ipro1000 and rtl81xx. Regressions are more than possible,
so please don't hesitate to file bugs if your network driver now
fails to come up (or you get KDLs.)
* Rename device.c to device_hooks.c, as this is what it really contains.
* Rename compat.c to device.c, as it implements the generic "device"
related functions, both for compat layer internals and FreeBSD
public ones.
* Move malloc and related operations out of the now-device.c,
and place them in a new "malloc.cpp", which also incorporates
compat_cpp.cpp.
No functional change intended.
The HAIKU_FIRMWARE_NAME_MAP macro takes a size parameter to define the
firmware map array type, and then a multi-dimensional array literal is
assigned to the array defined by that macro.
This is error-prone. The idualwifi7260 driver, before this patch, had
the size incorrectly set to 6 when the number of entries was 7, which
sliced the last entry off of the map, making it unavailable to the
driver. After fixing this size, the driver properly loads the
iwm-8265-22.ucode firmware on my computer.
This patch changes that macro to take a const char[][2] literal as its
only parameter, making it less likely for this sort of bug to be
re-introduced.
Fixes #15413.
Change-Id: I78a75e692a8637af0f13d1eb16180ce8d95d0852
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1917
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Call the superclass implementation of MessageReceived() to process messages not
handled by GlutWindow itself.
This restores mouse and keyboard functionality in OpenGL apps, including
Celestia, affected by commit 75e5739772.
Change-Id: Ic3af56ab2f78e8b2b8be576d2edc30bb7357f359
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1862
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This makes ARM64 target compile more files. This patch is one of
series of patches to support new architecture, as fixes in many
places are required just to compile the code.
Signed-off-by: Jaroslaw Pelczar <jarek@jpelczar.com>
Change-Id: Ia060612733cd3a0fcb781fec449da164ed635b8e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1807
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Unless __STRICT_ANSI__ is defined (as it is when running the compiler in
--std=c89 or --std=c99, but not when running it without any specific
args), we can enable these by default and behave like most other
systems. I don't know why no one has done this yet despite suggesting it
multiple times and people prefer to #define _BSD_SOURCE manually
everywhere.
Remove all places in our Jamfiles and sources where it had been defined.
_DEFAULT_SOURCE is now enabled by default for all sources of Haiku, since we
let the compiler use GNU extensions (no strict C standard specified on
command line)
Use _DEFAULT_SOURCE as the define name to match current versions of
glibc. Enable it if _BSD_SOURCE is #defined in compiler flags, for
backward compatibility.
Change-Id: I6db04da5f6db437723cdfba3478f5094a69d7727
Reviewed-on: https://review.haiku-os.org/c/1633
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Their copy constructors are exactly what GCC would generate,
but we can't remove them because doing so would make them
trivially copyable, and so they would be passed in registers
on x86_64, an ABI breakage.
So instead we have to add explicit casts to void* here.
A lot of these classes are not *technically* "trivially copyable"
for one reason or another, but in all of these cases it seems
OK to me to use memcpy/memset on them. Adding a cast to void*
tells GCC that "I know what I'm doing here" and shuts up the
warning.
This also means that when attach fails, we destroy the root device.
This should fix stale root devices getting left around when attach
fails.
Probably helps with or even outright fixes #15016.
- Did not see his comments before pushing my previous change.
- clear owning flag when passed value is NULL.
Change-Id: I493973aff2b107785c3734847c85a52f0f9da360
Reviewed-on: https://review.haiku-os.org/c/1443
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
- Keep track if the softc was allocated externally or not.
- Only try to deallocate it if it was allocated internally.
Do not try to free the softc if we were not the ones allocating it.
- Avoid a double free on consecutive calls to device_set_softc.
Change-Id: Ibb38e54e9dfd2a80dbb53920970bead626da8ba1
Reviewed-on: https://review.haiku-os.org/c/1441
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
