Re: [PATCH 4/8] hw/gpio/pca9554: New abstract base "pca9554-base"

[Markus Armbruster <armbru@redhat.com>]

BALATON Zoltan <balaton@eik.bme.hu> writes:

> On Mon, 9 Nov 2026, Markus Armbruster wrote:
>> Mark Cave-Ayland <mark.caveayland@nutanix.com> writes:
>>
>>> On 06/11/2026 11:04, Markus Armbruster wrote:
>>>
>>>> Commit 5eceb48bbe86 (hw/gpio: pca9554: add PCA9536 support) made type
>>>> "pca9535" a child of concrete type "pca9555".  This is inconvenient
>>>> for the next commit.  Make them both children of new abstract type
>>>> "pca9554-base".
>>>>
>>>> Signed-off-by: Markus Armbruster <armbru@redhat.com>

[...]

>>> The basic change looks good to me, however I found it tricky to follow
>>> given that PCA9554Class is now related to PCA9554_BASE_CLASS() and
>>> PCA9554State is now related to PCA9554_BASE().
>>>
>>> Would it make sense to rename PCA9554Class to PCA9554BaseClass and
>>> PCA9554State to PCA9554BaseState here? I think it would help make the
>>> hierarchy easier to follow.
>>
>> I considered it when I wrote this patch, then decided not to, to
>> minimize churn and keep the identifiers short.  I'm fine either way.
>
> How about calling the base class PCA95xx or similar to keep it both short and show it belongs to both child classes?

Existing types in this area:

* Abstract "pca955x" with concrete subtypes "pca9552", "pca9535",
  "pca9555".

* Abstract type whose name we're debating with concrete subtypes
  "pca9554" and "pca9536".

I fear naming it "pca95xx" would be confusing.