aboutsummaryrefslogtreecommitdiff
path: root/hw/gpio/aspeed_gpio.c
AgeCommit message (Collapse)AuthorFilesLines
2024-10-24hw/gpio/aspeed: Add AST2700 supportJamin Lin1-0/+380
AST2700 integrates two set of Parallel GPIO Controller with maximum 212 control pins, which are 27 groups. (H, exclude pin: H7 H6 H5 H4) In the previous design of ASPEED SOCs, one register is used for setting one function for one set which are 32 pins and 4 groups. ex: GPIO000 is used for setting data value for GPIO A, B, C and D in AST2600. ex: GPIO004 is used for setting direction for GPIO A, B, C and D in AST2600. However, the register set have a significant change since AST2700. Each GPIO pin has their own individual control register. In other words, users are able to set one GPIO pin’s direction, interrupt enable, input mask and so on in the same one register. Currently, aspeed_gpio_read and aspeed_gpio_write callback functions are not compatible AST2700. Introduce new aspeed_gpio_2700_read and aspeed_gpio_2700_write callback functions and aspeed_gpio_2700_ops memory region operation for AST2700. Introduce a new ast2700 class to support AST2700. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2024-10-24hw/gpio/aspeed: Fix clear incorrect interrupt status for GPIO index modeJamin Lin1-10/+17
The interrupt status field is W1C, where a set bit on read indicates an interrupt is pending. If the bit extracted from data is set it should clear the corresponding bit in reg_value. However, if the extracted bit is clear then the value of the corresponding bit in reg_value should be unchanged. SHARED_FIELD_EX32() extracts the interrupt status bit from the write (data). reg_value is set to the set's interrupt status, which means that for any pin with an interrupt pending, the corresponding bit is set. The deposit32() call updates the bit at pin_idx in the reg_value, using the value extracted from the write (data). The result is that if multiple interrupt status bits were pending and the write was acknowledging specific one bit, then the all interrupt status bits will be cleared. However, it is index mode and should only clear the corresponding bit. For example, say we have an interrupt pending for GPIOA0, where the following statements are true: set->int_status == 0b01 s->pending == 1 Before it is acknowledged, an interrupt becomes pending for GPIOA1: set->int_status == 0b11 s->pending == 2 A write is issued to acknowledge the interrupt for GPIOA0. This causes the following sequence: reg_value == 0b11 pending == 2 s->pending == 0 set->int_status == 0b00 It should only clear bit 0 in index mode and the correct result should be as following. set->int_status == 0b11 s->pending == 2 pending == 1 s->pending == 1 set->int_status == 0b10 Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Suggested-by: Andrew Jeffery <andrew@codeconstruct.com.au> Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2024-10-24hw/gpio/aspeed: Support different memory region opsJamin Lin1-1/+6
It set "aspeed_gpio_ops" struct which containing read and write callbacks to be used when I/O is performed on the GPIO region. Besides, in the previous design of ASPEED SOCs, one register is used for setting one function for 32 GPIO pins. ex: GPIO000 is used for setting data value for GPIO A, B, C and D in AST2600. ex: GPIO004 is used for setting direction for GPIO A, B, C and D in AST2600. However, the register set have a significant change in AST2700. Each GPIO pin has their own control register. In other words, users are able to set one GPIO pin’s direction, interrupt enable, input mask and so on in one register. The aspeed_gpio_read/aspeed_gpio_write callback functions are not compatible AST2700. Introduce a new "const MemoryRegionOps *" attribute in AspeedGPIOClass and use it in aspeed_gpio_realize function. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com>
2024-10-24hw/gpio/aspeed: Support to set the different memory sizeJamin Lin1-1/+6
According to the datasheet of ASPEED SOCs, a GPIO controller owns 4KB of register space for AST2700, AST2500, AST2400 and AST1030; owns 2KB of register space for AST2600 1.8v and owns 2KB of register space for AST2600 3.3v. It set the memory region size 2KB by default and it does not compatible register space for AST2700. Introduce a new class attribute to set the GPIO controller memory size for different ASPEED SOCs. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com>
2024-10-24hw/gpio/aspeed: Fix coding styleJamin Lin1-3/+3
Fix coding style issues from checkpatch.pl Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com>
2024-09-16hw/gpio/aspeed_gpio: Avoid shift into sign bitPeter Maydell1-1/+1
In aspeed_gpio_update() we calculate "mask = 1 << gpio", where gpio can be between 0 and 31. Coverity complains about this because 1 << 31 won't fit in a signed integer. For QEMU this isn't an error because we enable -fwrapv, but we can keep Coverity happy by doing the shift on unsigned numbers. Resolves: Coverity CID 1547742 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Cédric Le Goater <clg@redhat.com>
2024-09-13hw: Use device_class_set_legacy_reset() instead of opencodingPeter Maydell1-1/+1
Use device_class_set_legacy_reset() instead of opencoding an assignment to DeviceClass::reset. This change was produced with: spatch --macro-file scripts/cocci-macro-file.h \ --sp-file scripts/coccinelle/device-reset.cocci \ --keep-comments --smpl-spacing --in-place --dir hw Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20240830145812.1967042-8-peter.maydell@linaro.org
2024-07-02hw/gpio/aspeed: Add reg_table_count to AspeedGPIOClassZheyu Ma1-0/+17
ASan detected a global-buffer-overflow error in the aspeed_gpio_read() function. This issue occurred when reading beyond the bounds of the reg_table. To enhance the safety and maintainability of the Aspeed GPIO code, this commit introduces a reg_table_count member to the AspeedGPIOClass structure. This change ensures that the size of the GPIO register table is explicitly tracked and initialized, reducing the risk of errors if new register tables are introduced in the future. Reproducer: cat << EOF | qemu-system-aarch64 -display none \ -machine accel=qtest, -m 512M -machine ast1030-evb -qtest stdio readq 0x7e780272 EOF ASAN log indicating the issue: ==2602930==ERROR: AddressSanitizer: global-buffer-overflow on address 0x55a5da29e128 at pc 0x55a5d700dc62 bp 0x7fff096c4e90 sp 0x7fff096c4e88 READ of size 2 at 0x55a5da29e128 thread T0 #0 0x55a5d700dc61 in aspeed_gpio_read hw/gpio/aspeed_gpio.c:564:14 #1 0x55a5d933f3ab in memory_region_read_accessor system/memory.c:445:11 #2 0x55a5d92fba40 in access_with_adjusted_size system/memory.c:573:18 #3 0x55a5d92f842c in memory_region_dispatch_read1 system/memory.c:1426:16 #4 0x55a5d92f7b68 in memory_region_dispatch_read system/memory.c:1459:9 #5 0x55a5d9376ad1 in flatview_read_continue_step system/physmem.c:2836:18 #6 0x55a5d9376399 in flatview_read_continue system/physmem.c:2877:19 #7 0x55a5d93775b8 in flatview_read system/physmem.c:2907:12 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2355 Signed-off-by: Zheyu Ma <zheyuma97@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2023-12-29hw/gpio: Constify VMStateRichard Henderson1-2/+2
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20231221031652.119827-29-richard.henderson@linaro.org>
2022-07-14hw/gpio/aspeed: Don't let guests modify input pinsPeter Delevoryas1-7/+8
Up until now, guests could modify input pins by overwriting the data value register. The guest OS should only be allowed to modify output pin values, and the QOM property setter should only be permitted to modify input pins. This change also updates the gpio input pin test to match this expectation. Andrew suggested this particularly refactoring here: https://lore.kernel.org/qemu-devel/23523aa1-ba81-412b-92cc-8174faba3612@www.fastmail.com/ Suggested-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Peter Delevoryas <peter@pjd.dev> Fixes: 4b7f956862dc ("hw/gpio: Add basic Aspeed GPIO model for AST2400 and AST2500") Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220712023219.41065-3-peter@pjd.dev> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-05-25hw/gpio: replace HWADDR_PRIx with PRIx64Jamin Lin1-4/+4
1. replace HWADDR_PRIx with PRIx64 2. fix indent issue Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220525053444.27228-5-jamin_lin@aspeedtech.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-05-25hw/gpio support GPIO index mode for write operation.Jamin Lin1-0/+168
It did not support GPIO index mode for read operation. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220525053444.27228-4-jamin_lin@aspeedtech.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-05-25hw/gpio: Add ASPEED GPIO model for AST1030Jamin Lin1-0/+27
AST1030 integrates one set of Parallel GPIO Controller with maximum 151 control pins, which are 21 groups (A~U, exclude pin: M6 M7 Q5 Q6 Q7 R0 R1 R4 R5 R6 R7 S0 S3 S4 S5 S6 S7 ) and the group T and U are input only. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220525053444.27228-3-jamin_lin@aspeedtech.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-05-25hw/gpio Add GPIO read/write trace event.Jamin Lin1-15/+39
Add GPIO read/write trace event for aspeed model. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220525053444.27228-2-jamin_lin@aspeedtech.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-05-02hw/gpio/aspeed_gpio: Fix QOM pin propertyPeter Delevoryas1-1/+1
I was setting gpioV4-7 to "1110" using the QOM pin property handler and noticed that lowering gpioV7 was inadvertently lowering gpioV4-6 too. (qemu) qom-set /machine/soc/gpio gpioV4 true (qemu) qom-set /machine/soc/gpio gpioV5 true (qemu) qom-set /machine/soc/gpio gpioV6 true (qemu) qom-get /machine/soc/gpio gpioV4 true (qemu) qom-set /machine/soc/gpio gpioV7 false (qemu) qom-get /machine/soc/gpio gpioV4 false An expression in aspeed_gpio_set_pin_level was using a logical NOT operator instead of a bitwise NOT operator: value &= !pin_mask; The original author probably intended to make a bitwise NOT expression "~", but mistakenly used a logical NOT operator "!" instead. Some programming languages like Rust use "!" for both purposes. Fixes: 4b7f956862dc ("hw/gpio: Add basic Aspeed GPIO model for AST2400 and AST2500") Signed-off-by: Peter Delevoryas <pdel@fb.com> Message-Id: <20220502080827.244815-1-pdel@fb.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-03-08hw: aspeed_gpio: Cleanup stray semicolon after switchAndrew Jeffery1-1/+1
Not sure how that got there. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Message-Id: <20220207150409.358888-2-andrew@aj.id.au> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-10-12hw: aspeed_gpio: Fix GPIO array indexingPeter Delevoryas1-47/+33
The gpio array is declared as a dense array: qemu_irq gpios[ASPEED_GPIO_NR_PINS]; (AST2500 has 228, AST2400 has 216, AST2600 has 208) However, this array is used like a matrix of GPIO sets (e.g. gpio[NR_SETS][NR_PINS_PER_SET] = gpio[8][32]) size_t offset = set * GPIOS_PER_SET + gpio; qemu_set_irq(s->gpios[offset], !!(new & mask)); This can result in an out-of-bounds access to "s->gpios" because the gpio sets do _not_ have the same length. Some of the groups (e.g. GPIOAB) only have 4 pins. 228 != 8 * 32 == 256. To fix this, I converted the gpio array from dense to sparse, to that match both the hardware layout and this existing indexing code. Fixes: 4b7f956862dc2db4c5c ("hw/gpio: Add basic Aspeed GPIO model for AST2400 and AST2500") Signed-off-by: Peter Delevoryas <pdel@fb.com> Message-Id: <20211008033501.934729-2-pdel@fb.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-10-12hw: aspeed_gpio: Fix pin I/O type declarationsPeter Delevoryas1-4/+4
Some of the pin declarations in the Aspeed GPIO module were incorrect, probably because of confusion over which bits in the input and output uint32_t's correspond to which groups in the label array. Since the uint32_t literals are in big endian, it's sort of the opposite of what would be intuitive. The least significant bit in ast2500_set_props[6] corresponds to GPIOY0, not GPIOAB7. GPIOxx indicates input and output capabilities, GPIxx indicates only input, GPOxx indicates only output. AST2500: - Previously had GPIW0..GPIW7 and GPIX0..GPIX7, that's correct. - Previously had GPIOY0..GPIOY3, should have been GPIOY0..GPIOY7. - Previously had GPIOAB0..GPIOAB3 and GPIAB4..GPIAB7, should only have been GPIOAB0..GPIOAB3. AST2600: - GPIOT0..GPIOT7 should have been GPIT0..GPIT7. - GPIOU0..GPIOU7 should have been GPIU0..GPIU7. - GPIW0..GPIW7 should have been GPIOW0..GPIOW7. - GPIOY0..GPIOY7 and GPIOZ0...GPIOZ7 were disabled. Fixes: 4b7f956862dc2db4c5c ("hw/gpio: Add basic Aspeed GPIO model for AST2400 and AST2500") Fixes: 36d737ee82b2972167e ("hw/gpio: Add in AST2600 specific implementation") Signed-off-by: Peter Delevoryas <pdel@fb.com> Reviewed-by: Damien Hedde <damien.hedde@greensocs.com> Reviewed-by: Rashmica Gupta <rashmica.g@gmail.com> Message-Id: <20210928032456.3192603-2-pdel@fb.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-09-20hw: aspeed_gpio: Clarify GPIO controller nameJoel Stanley1-13/+13
There are two GPIO controllers in the ast2600; one is 3.3V and the other is 1.8V. Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Rashmica Gupta <rashmica.g@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20210713065854.134634-4-joel@jms.id.au> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-09-20hw: aspeed_gpio: Simplify 1.8V definesJoel Stanley1-37/+36
There's no need to define the registers relative to the 0x800 offset where the controller is mapped, as the device is instantiated as it's own model at the correct memory address. Simplify the defines and remove the offset to save future confusion. Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Rashmica Gupta <rashmica.g@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210713065854.134634-3-joel@jms.id.au> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-07-27hw: aspeed_gpio: Fix memory sizeJoel Stanley1-2/+1
The macro used to calculate the maximum memory size of the MMIO region had a mistake, causing all GPIO models to create a mapping of 0x9D8. The intent was to have it be 0x9D8 - 0x800. This extra size doesn't matter on ast2400 and ast2500, which have a 4KB region set aside for the GPIO controller. On the ast2600 the 3.3V and 1.8V GPIO controllers are 2KB apart, so the regions would overlap. Worse was the 1.8V controller would map over the top of the following peripheral, which happens to be the RTC. The mmio region used by each device is a maximum of 2KB, so avoid the calculations and hard code this as the maximum. Fixes: 36d737ee82b2 ("hw/gpio: Add in AST2600 specific implementation") Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Rashmica Gupta <rashmica.g@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-id: 20210713065854.134634-2-joel@jms.id.au [PMM: fix autocorrect error in commit message] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-06-05misc: Correct relative include pathPhilippe Mathieu-Daudé1-1/+1
Headers should be included from the 'include/' directory, not from the root directory. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-Id: <20210516205034.694788-1-f4bug@amsat.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-05-13hw/gpio/aspeed: spelling fix (addtional)Michael Tokarev1-1/+1
Fixes: 36d737ee82b2972167e97901c5271ba3f904ba71 Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210508093615.411920-1-mjt@msgid.tls.msk.ru> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-07-10error: Eliminate error_propagate() with Coccinelle, part 1Markus Armbruster1-3/+1
When all we do with an Error we receive into a local variable is propagating to somewhere else, we can just as well receive it there right away. Convert if (!foo(..., &err)) { ... error_propagate(errp, err); ... return ... } to if (!foo(..., errp)) { ... ... return ... } where nothing else needs @err. Coccinelle script: @rule1 forall@ identifier fun, err, errp, lbl; expression list args, args2; binary operator op; constant c1, c2; symbol false; @@ if ( ( - fun(args, &err, args2) + fun(args, errp, args2) | - !fun(args, &err, args2) + !fun(args, errp, args2) | - fun(args, &err, args2) op c1 + fun(args, errp, args2) op c1 ) ) { ... when != err when != lbl: when strict - error_propagate(errp, err); ... when != err ( return; | return c2; | return false; ) } @rule2 forall@ identifier fun, err, errp, lbl; expression list args, args2; expression var; binary operator op; constant c1, c2; symbol false; @@ - var = fun(args, &err, args2); + var = fun(args, errp, args2); ... when != err if ( ( var | !var | var op c1 ) ) { ... when != err when != lbl: when strict - error_propagate(errp, err); ... when != err ( return; | return c2; | return false; | return var; ) } @depends on rule1 || rule2@ identifier err; @@ - Error *err = NULL; ... when != err Not exactly elegant, I'm afraid. The "when != lbl:" is necessary to avoid transforming if (fun(args, &err)) { goto out } ... out: error_propagate(errp, err); even though other paths to label out still need the error_propagate(). For an actual example, see sclp_realize(). Without the "when strict", Coccinelle transforms vfio_msix_setup(), incorrectly. I don't know what exactly "when strict" does, only that it helps here. The match of return is narrower than what I want, but I can't figure out how to express "return where the operand doesn't use @err". For an example where it's too narrow, see vfio_intx_enable(). Silently fails to convert hw/arm/armsse.c, because Coccinelle gets confused by ARMSSE being used both as typedef and function-like macro there. Converted manually. Line breaks tidied up manually. One nested declaration of @local_err deleted manually. Preexisting unwanted blank line dropped in hw/riscv/sifive_e.c. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20200707160613.848843-35-armbru@redhat.com>
2020-07-10qapi: Use returned bool to check for failure, Coccinelle partMarkus Armbruster1-2/+1
The previous commit enables conversion of visit_foo(..., &err); if (err) { ... } to if (!visit_foo(..., errp)) { ... } for visitor functions that now return true / false on success / error. Coccinelle script: @@ identifier fun =~ "check_list|input_type_enum|lv_start_struct|lv_type_bool|lv_type_int64|lv_type_str|lv_type_uint64|output_type_enum|parse_type_bool|parse_type_int64|parse_type_null|parse_type_number|parse_type_size|parse_type_str|parse_type_uint64|print_type_bool|print_type_int64|print_type_null|print_type_number|print_type_size|print_type_str|print_type_uint64|qapi_clone_start_alternate|qapi_clone_start_list|qapi_clone_start_struct|qapi_clone_type_bool|qapi_clone_type_int64|qapi_clone_type_null|qapi_clone_type_number|qapi_clone_type_str|qapi_clone_type_uint64|qapi_dealloc_start_list|qapi_dealloc_start_struct|qapi_dealloc_type_anything|qapi_dealloc_type_bool|qapi_dealloc_type_int64|qapi_dealloc_type_null|qapi_dealloc_type_number|qapi_dealloc_type_str|qapi_dealloc_type_uint64|qobject_input_check_list|qobject_input_check_struct|qobject_input_start_alternate|qobject_input_start_list|qobject_input_start_struct|qobject_input_type_any|qobject_input_type_bool|qobject_input_type_bool_keyval|qobject_input_type_int64|qobject_input_type_int64_keyval|qobject_input_type_null|qobject_input_type_number|qobject_input_type_number_keyval|qobject_input_type_size_keyval|qobject_input_type_str|qobject_input_type_str_keyval|qobject_input_type_uint64|qobject_input_type_uint64_keyval|qobject_output_start_list|qobject_output_start_struct|qobject_output_type_any|qobject_output_type_bool|qobject_output_type_int64|qobject_output_type_null|qobject_output_type_number|qobject_output_type_str|qobject_output_type_uint64|start_list|visit_check_list|visit_check_struct|visit_start_alternate|visit_start_list|visit_start_struct|visit_type_.*"; expression list args; typedef Error; Error *err; @@ - fun(args, &err); - if (err) + if (!fun(args, &err)) { ... } A few line breaks tidied up manually. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20200707160613.848843-19-armbru@redhat.com>
2020-05-15qom: Drop parameter @errp of object_property_add() & friendsMarkus Armbruster1-1/+1
The only way object_property_add() can fail is when a property with the same name already exists. Since our property names are all hardcoded, failure is a programming error, and the appropriate way to handle it is passing &error_abort. Same for its variants, except for object_property_add_child(), which additionally fails when the child already has a parent. Parentage is also under program control, so this is a programming error, too. We have a bit over 500 callers. Almost half of them pass &error_abort, slightly fewer ignore errors, one test case handles errors, and the remaining few callers pass them to their own callers. The previous few commits demonstrated once again that ignoring programming errors is a bad idea. Of the few ones that pass on errors, several violate the Error API. The Error ** argument must be NULL, &error_abort, &error_fatal, or a pointer to a variable containing NULL. Passing an argument of the latter kind twice without clearing it in between is wrong: if the first call sets an error, it no longer points to NULL for the second call. ich9_pm_add_properties(), sparc32_ledma_realize(), sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize() are wrong that way. When the one appropriate choice of argument is &error_abort, letting users pick the argument is a bad idea. Drop parameter @errp and assert the preconditions instead. There's one exception to "duplicate property name is a programming error": the way object_property_add() implements the magic (and undocumented) "automatic arrayification". Don't drop @errp there. Instead, rename object_property_add() to object_property_try_add(), and add the obvious wrapper object_property_add(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-15-armbru@redhat.com> [Two semantic rebase conflicts resolved]
2020-05-04hw/gpio/aspeed_gpio: Remove dead assignmentPhilippe Mathieu-Daudé1-1/+1
Fix warning reported by Clang static code analyzer: hw/gpio/aspeed_gpio.c:717:18: warning: Value stored to 'g_idx' during its initialization is never read int set_idx, g_idx = *group_idx; ^~~~~ ~~~~~~~~~~ Reported-by: Clang Static Analyzer Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200422133152.16770-8-philmd@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-04-03hw/gpio/aspeed_gpio.c: Don't directly include assert.hPeter Maydell1-2/+0
Remove a direct include of assert.h -- this is already provided by qemu/osdep.h, and it breaks our rule that the first include must always be osdep.h. In particular we must get the assert() macro via osdep.h to avoid compile failures on mingw (see the comment in osdep.h where we redefine assert() for that platform). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-id: 20200403124712.24826-1-peter.maydell@linaro.org
2019-12-16gpio: fix memory leak in aspeed_gpio_init()PanNengyuan1-0/+1
Address Sanitizer shows memory leak in hw/gpio/aspeed_gpio.c:875 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: PanNengyuan <pannengyuan@huawei.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-id: 20191119141211.25716-16-clg@kaod.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-24hw/gpio: Fix property accessors of the AST2600 GPIO 1.8V modelCédric Le Goater1-4/+4
The property names of AST2600 GPIO 1.8V model are one character bigger than the names of the other ASPEED GPIO model. Increase the string buffer size by one and be more strict on the expected pattern of the property name. This fixes the QOM test of the ast2600-evb machine under : Apple LLVM version 10.0.0 (clang-1000.10.44.4) Target: x86_64-apple-darwin17.7.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin Cc: Rashmica Gupta <rashmica.g@gmail.com> Fixes: 36d737ee82b2 ("hw/gpio: Add in AST2600 specific implementation") Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-id: 20191023130455.1347-2-clg@kaod.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-15hw/gpio: Add in AST2600 specific implementationRashmica Gupta1-5/+137
The AST2600 has the same sets of 3.6v gpios as the AST2400 plus an addtional two sets of 1.8V gpios. Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Acked-by: Joel Stanley <joel@jms.id.au> Message-id: 20190925143248.10000-15-clg@kaod.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-09-13hw/gpio: Add basic Aspeed GPIO model for AST2400 and AST2500Rashmica Gupta1-0/+884
GPIO pins are arranged in groups of 8 pins labeled A,B,..,Y,Z,AA,AB,AC. (Note that the ast2400 controller only goes up to group AB). A set has four groups (except set AC which only has one) and is referred to by the groups it is composed of (eg ABCD,EFGH,...,YZAAAB). Each set is accessed and controlled by a bank of 14 registers. These registers operate on a per pin level where each bit in the register corresponds to a pin, except for the command source registers. The command source registers operate on a per group level where bits 24, 16, 8 and 0 correspond to each group in the set. eg. registers for set ABCD: |D7...D0|C7...C0|B7...B0|A7...A0| <- GPIOs |31...24|23...16|15....8|7.....0| <- bit position Note that there are a couple of groups that only have 4 pins. There are two ways that this model deviates from the behaviour of the actual controller: (1) The only control source driving the GPIO pins in the model is the ARM model (as there currently aren't models for the LPC or Coprocessor). (2) None of the registers in the model are reset tolerant (needs integration with the watchdog). Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com> Tested-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-id: 20190904070506.1052-2-clg@kaod.org [clg: fixed missing header files made use of HWADDR_PRIx to fix compilation on windows ] Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
generated by cgit v1.1 at 2025-04-15 05:47:20 +0000