ac2c4d3a | 08-May-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: pl011: Really use RX FIFO depth
While we model a 16-elements RX FIFO since the PL011 model was introduced in commit cdbdb648b7c ("ARM Versatile Platform Baseboard emulation"), we only read 1 c
rust: pl011: Really use RX FIFO depth
While we model a 16-elements RX FIFO since the PL011 model was introduced in commit cdbdb648b7c ("ARM Versatile Platform Baseboard emulation"), we only read 1 char at a time!
Have can_receive() return how many elements are available, and use that in receive().
This is the Rust version of commit 3e0f118f825 ("hw/char/pl011: Really use RX FIFO depth"); but it also adds back a comment that is present in commit f576e0733cc ("hw/char/pl011: Add support for loopback") and absent in the Rust code.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
6d8c6dee | 07-Apr-2025 |
Rakesh Jeyasingh <rakeshjb010@gmail.com> |
rust/hw/char/pl011: Extract DR write logic into separate function
- Split `write()` DR case into `write_data_register()`
Signed-off-by: Rakesh Jeyasingh <rakeshjb010@gmail.com> Link: https://lore.k
rust/hw/char/pl011: Extract DR write logic into separate function
- Split `write()` DR case into `write_data_register()`
Signed-off-by: Rakesh Jeyasingh <rakeshjb010@gmail.com> Link: https://lore.kernel.org/r/20250407181327.171563-3-rakeshjb010@gmail.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
81694536 | 07-Mar-2025 |
Peter Maydell <peter.maydell@linaro.org> |
rust: pl011: Allow NULL chardev argument to pl011_create()
It's valid for the caller to pass a NULL chardev to pl011_create(); this means "don't set the chardev property on the device", which in tur
rust: pl011: Allow NULL chardev argument to pl011_create()
It's valid for the caller to pass a NULL chardev to pl011_create(); this means "don't set the chardev property on the device", which in turn means "act like there's no chardev". All the chardev frontend APIs (in C, at least) accept a NULL pointer to mean "do nothing".
This fixes some failures in 'make check-functional' when Rust support is enabled.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Link: https://lore.kernel.org/r/20250307190051.3274226-1-peter.maydell@linaro.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
519088b7 | 27-Feb-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: hpet: decode HPET registers into enums
Generalize timer_and_addr() to decode all registers into a single enum HPETRegister, and use the TryInto derive to separate valid and invalid values.
Th
rust: hpet: decode HPET registers into enums
Generalize timer_and_addr() to decode all registers into a single enum HPETRegister, and use the TryInto derive to separate valid and invalid values.
The main advantage lies in checking that all registers are enumerated in the "match" statements.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
aa50bc4f | 18-Dec-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: pl011: pass around registers::Data
The values stored in the Fifo are instances of the bitfield-struct registers::Data. Convert as soon as possible the value written into DR, and always refer
rust: pl011: pass around registers::Data
The values stored in the Fifo are instances of the bitfield-struct registers::Data. Convert as soon as possible the value written into DR, and always refer to the bitfield struct; it's generally cleaner other than PL011State::receive having to do a double conversion u8=>u32=>registers::Data.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
9b642097 | 11-Feb-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: pl011: switch to safe chardev operation
Switch bindings::CharBackend with chardev::CharBackend. This removes occurrences of "unsafe" due to FFI and switches the wrappers for receive, can_rece
rust: pl011: switch to safe chardev operation
Switch bindings::CharBackend with chardev::CharBackend. This removes occurrences of "unsafe" due to FFI and switches the wrappers for receive, can_receive and event callbacks to the common ones implemented by chardev::CharBackend.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
567c0c41 | 13-Feb-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: pl011, qemu_api tests: do not use ClassInitImpl
Outside the qemu_api crate, orphan rules make the usage of ClassInitImpl unwieldy. Now that it is optional, do not use it.
For PL011Class, thi
rust: pl011, qemu_api tests: do not use ClassInitImpl
Outside the qemu_api crate, orphan rules make the usage of ClassInitImpl unwieldy. Now that it is optional, do not use it.
For PL011Class, this makes it easier to provide a PL011Impl trait similar to the ones in the qemu_api crate. The device id consts are moved there.
Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
4551f342 | 12-Feb-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
rust: qom: add ObjectImpl::CLASS_INIT
As shown in the PL011 device, the orphan rules required a manual implementation of ClassInitImpl for anything not in the qemu_api crate; this gets in the way of
rust: qom: add ObjectImpl::CLASS_INIT
As shown in the PL011 device, the orphan rules required a manual implementation of ClassInitImpl for anything not in the qemu_api crate; this gets in the way of moving system emulation-specific code (including DeviceClass, which as a blanket ClassInitImpl<DeviceClass> implementation) into its own crate.
Make ClassInitImpl optional, at the cost of having to specify the CLASS_INIT member by hand in every implementation of ObjectImpl. The next commits will get rid of it, replacing all the "impl<T> ClassInitImpl<Class> for T" blocks with a generic class_init<T> method on Class.
Right now the definition is always the same, but do not provide a default as that will not be true once ClassInitImpl goes away.
Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|