This is probably incomplete. Is locking needed? Should we notify the
next writer (if any) that the port is writable when flushing the output?
Change-Id: I2566e2d036a61af4819894a44f57603179aa27df
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2516
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* This allows file systems to retrieve the actual error code on a
failure, and report it to the user.
* All affected file systems have been adjusted to the API change.
This is a binary incompatible change.
Change-Id: Id73392aaf9c6cb7d643ff9adcb8bf80f3037874c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2913
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
type is acpi_handle, to be used with the ACPI bus manager
Change-Id: Ibbdd81a21bdd57fc651f7a7238e3676033204857
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2456
Reviewed-by: Rene Gollent <rene@gollent.com>
ACPI_DEVICE_HID_ITEM is now optional, instead of an empty string.
Change-Id: I352ffaaad377659f650a0b8c0d56e40a68b739c3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2420
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
to find a node in the hierarchy.
Change-Id: Iee858f21ce134569bf25fccbef9fe18ea8787e9d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2419
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Not used by anything at all, and not included in the build.
Even the BeOS engineer who created it wrote in a Be Newsletter
that he was uncertain how useful it was, which is why BeOS
did not ship it as a kernel add-on...
There is no good reason to put them in a private header.
No functional change (but drivers now have access
to these constants.)
Change-Id: I7ac00a120ab44fbc110bc858dfd87d69d0061135
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2294
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: John Scipione <jscipione@gmail.com>
- Fix USB_hid_page_consumer.h: some values are skipped in the spec so
our defines were off
- Handle the horizontal wheel on my mouse which is declared as a
CON_AC_PAN, but otherwise works just like the vertical wheel
- Input server and interface kit already handle the events properly
(they were available for serial mice already).
Change-Id: Ie0080ebb27e9478bcfe9f9dc5fd2a936ae05a848
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2201
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
- Remove duplicate and otherwise unused lendian_bitfield.h
- Adjust listusb jamfile to use lendian_bitfield.h
- Fix various typos in usb_video.h and restore some fields to make
listusb happy
It now lives in OS.h. The idea is that this will now be
accessible to userland applications, so userland memory
is protected from access by other processes, just as
kernel memory is.
No functional change (the constants are still the same,
though I've changed some to use shifts to make clear
which bits are allocated are which are unused.)
The kernel version is only partially tested.
Change-Id: I9a2f6c78087154ab137eadbced99062a8a2dd688
Reviewed-on: https://review.haiku-os.org/c/918
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Since it handles physical address it should really be this.
It's not like many drivers actually used it anyway. It shouldn't harm
compatibility, drivers calling it with only 32bit would leave garbage in
the higher bits but since on x86 it's a noop anyway, it would end up in
the MSB register tha's ignored because it expects a 32bit result.
- Various cleanups to the USB-audio side, which is similar
- Add in the UVC (USB Video) specific info with parsing of some of the
descriptors (most of the "control" part).
* Added a directory argument for notify_{stat/attribute}_changed().
* This allows to watch only a directory, and get the notifications for
all of its files, not just add/remove entry notifications.
It provides a way for filesystems to cache a lookup failure and
therefore prevents repeated lookups of missing entries. This is a
common scenario for example in command lookup and compiling, where
each directory in PATH or each include directory is searched for the
given entry.
This isn't really a bus_manager yet, but just minimal support so
we can get rid of hardcoded ARM SoC support from the core kernel
code.
Needs lots of work, like proper handling of #address-cells and
the like. Also, generic attribute handling, device_manager
integration, and I could go on for hours ;)
* Added VFS helper function check_access_permissions() that combines
several partially correct versions to the one true version (tm).
* All but BFS (since recently) missed the S_IXOTH for root on directories,
and all but packagefs missed proper group handling.
* Create new interface for cpuidle modules (similar to the cpufreq
interface)
* Generic cpuidle module is no longer needed
* Fix and update Intel C-State module
* virtio_scsi can have 16384 luns, though we cap at 256 as our scsi_ccb
only uses uchar as a type for target_lun and target_id members.
* minor code cleanup in scsi_scan_bus().
* The UNMAP command is theoretically much faster, as it can get many block
ranges instead of just a single range.
* Furthermore, the ATA TRIM command resembles it much better.
* Therefore, fs_trim_data now gets an array of ranges, and we use SCSI UNMAP
to trim.
* Updated BFS code to collect array ranges to fully support the new
fs_trim_data possibilities.
