aboutsummaryrefslogtreecommitdiff
path: root/include/hw/pci-host/pnv_phb4.h
AgeCommit message (Collapse)Author
2022-04-04ppc/pnv: Fix number of registers in the PCIe controller on POWER9Frederic Barrat
The spec defines 3 registers, even though only index 0 and 2 are valid on POWER9. The same model is used on POWER10. Register 1 is defined there but we currently don't use it in skiboot. So we can keep reporting an error on write. Reported by Coverity (CID 1487176). Fixes: 4f9924c4d4cf ("ppc/pnv: Add models for POWER9 PHB4 PCIe Host bridge") Suggested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220401091925.770803-1-fbarrat@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-03-14ppc/pnv: Introduce a pnv-phb5 device to match root portFrederic Barrat
We already have the pnv-phb3 and pnv-phb4 devices for POWER8 and POWER9 respectively. POWER10 uses version 5 of the PHB. It is very close to the PHB4 from POWER9, at least in our model and we could almost keep using the PHB4 model. However the matching root port pnv-phb5-root-port is specific to POWER10 so to avoid confusion as well as making it easy to introduce differences later, we create a pnv-phb5 class, which is mostly an alias for pnv-phb4 for now. With this patch, the command line for a user-created PHB on powernv10 becomes: -machine powernv10 -nodefaults -device pnv-phb5 -device pnv-phb5-root-port Fixes: 623575e16cd5 ("ppc/pnv: Add model for POWER10 PHB5 PCIe Host bridge") Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220310155101.294568-2-fbarrat@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-03-02ppc/pnv: Add model for POWER10 PHB5 PCIe Host bridgeCédric Le Goater
PHB4 and PHB5 are very similar. Use the PHB4 models with some minor adjustements in a subclass for P10. Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-18ppc/pnv: Add a 'rp_model' class attribute for the PHB4 PECCédric Le Goater
PHB5 will introduce its own root port model. Prepare ground for it. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220117122753.1655504-3-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-18ppc/pnv: remove PnvPhb4PecStack objectDaniel Henrique Barboza
All the complexity that was scattered between PnvPhb4PecStack and PnvPHB4 are now centered in the PnvPHB4 device. PnvPhb4PecStack does not serve any purpose in the current code base. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220114180719.52117-8-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-18ppc/pnv: make PECs create and realize PHB4sDaniel Henrique Barboza
This patch changes the design of the PEC device to create and realize PHB4s instead of PecStacks. After all the recent changes, PHB4s now contain all the information needed for their proper functioning, not relying on PecStack in any capacity. All changes are being made in a single patch to avoid renaming parts of the PecState and leaving the code in a strange way. E.g. rename PecClass->num_stacks to num_phbs, which would then read a pnv_pec_num_stacks[] array. To avoid mixing the old and new design more than necessary it's clearer to do these changes in a single step. The name changes made are: - in PnvPhb4PecState: * rename 'num_stacks' to 'num_phbs' * remove the pec->stacks[] array. Current code relies on the pec->stacks[] obj acting as a simple container, without ever accessing pec->stacks[] for any other purpose. Instead of converting this into a pec->phbs[] array, remove it - in PnvPhb4PecClass, rename *num_stacks to *num_phbs; - pnv_pec_num_stacks[] is renamed to pnv_pec_num_phbs[]. The logical changes: - pnv_pec_default_phb_realize(): * init and set the properties of the PnvPHB4 qdev * do not use stack->phb anymore; - pnv_pec_realize(): * use the new default_phb_realize() to init/realize each PHB if running with defaults; - pnv_pec_instance_init(): removed since we're creating the PHBs during pec_realize(); - pnv_phb4_get_stack(): * renamed to pnv_phb4_get_pec() and returns a PnvPhb4PecState*; - pnv_phb4_realize(): use 'phb->pec' instead of 'stack'. This design change shouldn't caused any behavioral change in the runtime of the machine. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220114180719.52117-7-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-18ppc/pnv: remove PnvPhb4PecStack::stack_noDaniel Henrique Barboza
pnv_pec_default_phb_realize() stopped using it after the previous patch and no one else is using it. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220114180719.52117-6-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-18ppc/pnv: remove stack pointer from PnvPHB4Daniel Henrique Barboza
This pointer was being used for two reasons: pnv_phb4_update_regions() was using it to access the PHB and phb4_realize() was using it as a way to determine if the PHB was user created. We can determine if the PHB is user created via phb->pec, introduced in the previous patch, and pnv_phb4_update_regions() is no longer using stack->phb. Remove the pointer from the PnvPHB4 device. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220114180719.52117-4-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-18ppc/pnv: introduce PnvPHB4 'pec' propertyDaniel Henrique Barboza
This property will track the owner PEC of this PHB. For now it's redundant since we can retrieve the PEC via phb->stack->pec but it will not be redundant when we get rid of the stack device. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220114180719.52117-2-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-18ppc/pnv: move phb_regs_mr to PnvPHB4Daniel Henrique Barboza
After recent changes, this MemoryRegion can be migrated to PnvPHB4 without too much trouble. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220113192952.911188-11-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-18ppc/pnv: move nest_regs_mr to PnvPHB4Daniel Henrique Barboza
We're now able to cleanly move nest_regs_mr to the PnvPHB4 device. One thing of notice here is the need to use a phb->stack->pec pointer because pnv_pec_stk_nest_xscom_write requires a PEC object. Another thing that can be noticed in the use of 'stack->stack_no' that still remains throughout the XSCOM code. After moving all MemoryRegions to the PnvPHB4 object, this illustrates what is the remaining role of the stack: provide a PEC pointer and the 'stack_no' information. If we can provide these in the PnvPHB4 object instead (spoiler: we can, and we will), the PnvPhb4PecStack device will be deprecated and can be removed. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220113192952.911188-10-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-18ppc/pnv: move nest_regs[] to PnvPHB4Daniel Henrique Barboza
stack->nest_regs[] is used in several XSCOM functions and it's one of the main culprits of having to deal with stack->phb pointers around the code. Sure, we're having to add 2 extra stack->phb pointers to ease nest_regs[] migration to PnvPHB4. They'll be dealt with shortly. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220113192952.911188-8-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-18ppc/pnv: move mmbar0/mmbar1 and friends to PnvPHB4Daniel Henrique Barboza
These 2 MemoryRegions, together with mmio(0|1)_base and mmio(0|1)_size variables, are used together in the same functions. We're better of moving them all in a single step. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220113192952.911188-7-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-18ppc/pnv: move intbar to PnvPHB4Daniel Henrique Barboza
This MemoryRegion can also be moved in a single step. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220113192952.911188-5-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-18ppc/pnv: move phbbar to PnvPHB4Daniel Henrique Barboza
This MemoryRegion is simple enough to be moved in a single step. A 'stack->phb' pointer had to be introduced in pnv_pec_stk_update_map() because this function isn't ready to be fully converted to use a PnvPHB4 pointer instead. This will be dealt with in the following patches. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220113192952.911188-4-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-18ppc/pnv: move PCI registers to PnvPHB4Daniel Henrique Barboza
Previous patch changed pnv_pec_stk_pci_xscom_read() and pnv_pec_stk_pci_xscom_write() to use a PnvPHB4 opaque, making it easier to move both pci_regs[] and the pci_regs_mr MemoryRegion to the PnvHB4 object. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220113192952.911188-3-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: turn pnv_phb4_update_regions() into staticDaniel Henrique Barboza
Its only callers are inside pnv_phb4.c. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220111131027.599784-6-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: turn 'phb' into a pointer in struct PnvPhb4PecStackDaniel Henrique Barboza
At this moment, stack->phb is the plain PnvPHB4 device itself instead of a pointer to the device. This will present a problem when adding user creatable devices because we can't deal with this struct and the realize() callback from the user creatable device. We can't get rid of this attribute, similar to what we did when enabling pnv-phb3 user creatable devices, because pnv_phb4_update_regions() needs to access stack->phb to do its job. This function is called twice in pnv_pec_stk_update_map(), which is one of the nested xscom write callbacks (via pnv_pec_stk_nest_xscom_write()). In fact, pnv_pec_stk_update_map() code comment is explicit about how the order of the unmap/map operations relates with the PHB subregions. All of this indicates that this code is tied together in a way that we either go on a crusade, featuring lots of refactories and redesign and considerable pain, to decouple stack and phb mapping, or we allow stack update_map operations to access the associated PHB as it is today even after introducing pnv-phb4 user devices. This patch chooses the latter. Instead of getting rid of stack->phb, turn it into a PHB pointer. This will allow us to assign an user created PHB to an existing stack later. In this process, pnv_pec_stk_instance_init() is removed because stack->phb is being initialized in stk_realize() instead. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220111131027.599784-4-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12pnv_phb4_pec.c: move pnv_pec_phb_offset() to pnv_phb4.cDaniel Henrique Barboza
The logic inside pnv_pec_phb_offset() will be useful in the next patch to determine the stack that should contain a PHB4 device. Move the function to pnv_phb4.c and make it public since there's no pnv_phb4_pec.h header. While we're at it, add 'stack_index' as a parameter and make the function return 'phb-id' directly. And rename it to pnv_phb4_pec_get_phb_id() to be even clearer about the function intent. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220110143346.455901-3-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12pnv_phb4.c: change TYPE_PNV_PHB4_ROOT_BUS nameDaniel Henrique Barboza
Similar to what was happening with pnv-phb3 buses, TYPE_PNV_PHB4_ROOT_BUS set to "pnv-phb4-root-bus" is a bit too long for a default root bus name. The usual default name for theses buses in QEMU are 'pcie', but we want to make a distinction between pnv-phb4 buses and other PCIE buses, at least as far as default name goes, because not all PCIE devices are attachable to a pnv-phb4 root-bus type. Changing the default to 'pnv-phb4-root' allow us to have a shorter name while making this bus distinct, and the user can always set its own bus naming via the "id" attribute anyway. This is the 'info qtree' output after this change, using a powernv9 domain with 2 sockets and default settings enabled: qemu-system-ppc64 -m 4G -machine powernv9,accel=tcg \ -smp 2,sockets=2,cores=1,threads=1 dev: pnv-phb4, id "" index = 5 (0x5) chip-id = 1 (0x1) version = 704374636546 (0xa400000002) device-id = 1217 (0x4c1) x-config-reg-migration-enabled = true bypass-iommu = false bus: pnv-phb4-root.11 type pnv-phb4-root dev: pnv-phb4-root-port, id "" (...) dev: pnv-phb4, id "" index = 0 (0x0) chip-id = 1 (0x1) version = 704374636546 (0xa400000002) device-id = 1217 (0x4c1) x-config-reg-migration-enabled = true bypass-iommu = false bus: pnv-phb4-root.6 type pnv-phb4-root dev: pnv-phb4-root-port, id "" (..) dev: pnv-phb4, id "" index = 5 (0x5) chip-id = 0 (0x0) version = 704374636546 (0xa400000002) device-id = 1217 (0x4c1) x-config-reg-migration-enabled = true bypass-iommu = false bus: pnv-phb4-root.5 type pnv-phb4-root dev: pnv-phb4-root-port, id "" (...) dev: pnv-phb4, id "" index = 0 (0x0) chip-id = 0 (0x0) version = 704374636546 (0xa400000002) device-id = 1217 (0x4c1) x-config-reg-migration-enabled = true bypass-iommu = false bus: pnv-phb4-root.0 type pnv-phb4-root dev: pnv-phb4-root-port, id "" Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220110143346.455901-11-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12pnv_phb4.c: make pnv-phb4-root-port user creatableDaniel Henrique Barboza
We want to create only the absolutely minimal amount of devices when running with -nodefaults. The root port is something that the machine can boot up without. But, to do that, we need to provide a way for the user to add them by hand. This patch makes pnv-phb4-root-port user creatable and then uses the pnv_phb_attach_root_port() helper to add a pnv_phb4_root_port only when running with default settings. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220105212338.49899-5-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-04ppc/pnv: Remove the PHB4 "device-id" propertyCédric Le Goater
It's unused. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20211222063817.1541058-4-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/pnv: Introduce a num_stack class attributeCédric Le Goater
Each PEC device of the POWER9 chip has a predefined number of stacks, equivalent of a root port complex: PEC0 -> 1 stack PEC1 -> 2 stacks PEC2 -> 3 stacks Introduce a class attribute to hold these values and remove the "num-stacks" property. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211213132830.108372-11-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/pnv: Introduce a "chip" property under the PHB4 modelCédric Le Goater
And check the PEC index using the chip class. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211213132830.108372-10-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/pnv: Introduce version and device_id class atributes for PHB4 devicesCédric Le Goater
It prepares ground for PHB5 which has different values. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211213132830.108372-9-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2020-09-18Use OBJECT_DECLARE_SIMPLE_TYPE when possibleEduardo Habkost
This converts existing DECLARE_INSTANCE_CHECKER usage to OBJECT_DECLARE_SIMPLE_TYPE when possible. $ ./scripts/codeconverter/converter.py -i \ --pattern=AddObjectDeclareSimpleType $(git grep -l '' -- '*.[ch]') Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Paul Durrant <paul@xen.org> Message-Id: <20200916182519.415636-6-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-09-18Use OBJECT_DECLARE_TYPE when possibleEduardo Habkost
This converts existing DECLARE_OBJ_CHECKERS usage to OBJECT_DECLARE_TYPE when possible. $ ./scripts/codeconverter/converter.py -i \ --pattern=AddObjectDeclareType $(git grep -l '' -- '*.[ch]') Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Acked-by: Paul Durrant <paul@xen.org> Message-Id: <20200916182519.415636-5-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-09-09Use DECLARE_*CHECKER* macrosEduardo Habkost
Generated using: $ ./scripts/codeconverter/converter.py -i \ --pattern=TypeCheckMacro $(git grep -l '' -- '*.[ch]') Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20200831210740.126168-12-ehabkost@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20200831210740.126168-13-ehabkost@redhat.com> Message-Id: <20200831210740.126168-14-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-09-09Move QOM typedefs and add missing includesEduardo Habkost
Some typedefs and macros are defined after the type check macros. This makes it difficult to automatically replace their definitions with OBJECT_DECLARE_TYPE. Patch generated using: $ ./scripts/codeconverter/converter.py -i \ --pattern=QOMStructTypedefSplit $(git grep -l '' -- '*.[ch]') which will split "typdef struct { ... } TypedefName" declarations. Followed by: $ ./scripts/codeconverter/converter.py -i --pattern=MoveSymbols \ $(git grep -l '' -- '*.[ch]') which will: - move the typedefs and #defines above the type check macros - add missing #include "qom/object.h" lines if necessary Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20200831210740.126168-9-ehabkost@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20200831210740.126168-10-ehabkost@redhat.com> Message-Id: <20200831210740.126168-11-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-02-02ppc/pnv: Add models for POWER9 PHB4 PCIe Host bridgeBenjamin Herrenschmidt
These changes introduces models for the PCIe Host Bridge (PHB4) of the POWER9 processor. It includes the PowerBus logic interface (PBCQ), IOMMU support, a single PCIe Gen.4 Root Complex, and support for MSI and LSI interrupt sources as found on a POWER9 system using the XIVE interrupt controller. POWER9 processor comes with 3 PHB4 PEC (PCI Express Controller) and each PEC can have several PHBs. By default, * PEC0 provides 1 PHB (PHB0) * PEC1 provides 2 PHBs (PHB1 and PHB2) * PEC2 provides 3 PHBs (PHB3, PHB4 and PHB5) Each PEC has a set "global" registers and some "per-stack" (per-PHB) registers. Those are organized in two XSCOM ranges, the "Nest" range and the "PCI" range, each range contains both some "PEC" registers and some "per-stack" registers. No default device layout is provided and PCI devices can be added on any of the available PCIe Root Port (pcie.0 .. 2 of a Power9 chip) with address 0x0 as the firwware (skiboot) only accepts a single device per root port. To run a simple system with a network and a storage adapters, use a command line options such as : -device e1000e,netdev=net0,mac=C0:FF:EE:00:00:02,bus=pcie.0,addr=0x0 -netdev bridge,id=net0,helper=/usr/libexec/qemu-bridge-helper,br=virbr0,id=hostnet0 -device megasas,id=scsi0,bus=pcie.1,addr=0x0 -drive file=$disk,if=none,id=drive-scsi0-0-0-0,format=qcow2,cache=none -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2 If more are needed, include a bridge. Multi chip is supported, each chip adding its set of PHB4 controllers and its PCI busses. The model doesn't emulate the EEH error handling. This model is not ready for hotplug yet. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> [ clg: - numerous cleanups - commit log - fix for broken LSI support - PHB pic printinfo - large QOM rework ] Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200127144506.11132-2-clg@kaod.org> [dwg: Use device_class_set_props()] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>