| Message ID | 20200806234933.16448-1-sstabellini@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [01/14] kernel-doc: public/arch-arm.h | expand |
Stefano Stabellini writes ("[PATCH 01/14] kernel-doc: public/arch-arm.h"):
> From: Stefano Stabellini <stefano.stabellini@xilinx.com>
>
> Convert in-code comments to kernel-doc format wherever possible.
Thanks. But, err, I think there is not yet any in-tree machinery for
actually building and publishing these kernel-doc comments ?
As I said I think replacing our ad-hoc in-tree system with kernel-doc
is a good idea, but...
> -/*
> - * `incontents 50 arm_abi Hypercall Calling Convention
> +/**
> + * DOC: Hypercall Calling Convention
... let us not replace the in-tree markup for that system until we
have its replacement.
Ian.
On Tue, 18 Aug 2020, Ian Jackson wrote: > Stefano Stabellini writes ("[PATCH 01/14] kernel-doc: public/arch-arm.h"): > > From: Stefano Stabellini <stefano.stabellini@xilinx.com> > > > > Convert in-code comments to kernel-doc format wherever possible. > > Thanks. But, err, I think there is not yet any in-tree machinery for > actually building and publishing these kernel-doc comments ? No, there isn't. But you can call kernel-doc on the headers manually and it will produce fully readable docs in RST format. (Then you can covert RST docs to HTML with Sphinx.) Like: kernel-doc xen/include/public/features.h > readme-features.rst I also gave a few more details on the plan I had in my other email reply. > As I said I think replacing our ad-hoc in-tree system with kernel-doc > is a good idea, but... > > > -/* > > - * `incontents 50 arm_abi Hypercall Calling Convention > > +/** > > + * DOC: Hypercall Calling Convention > > ... let us not replace the in-tree markup for that system until we > have its replacement. Ah! I didn't know what `incontents 50 arm_abi was for. I assumed it was a relic of another era and removed it. Is it actually used (and the other markups like that)? Is there a script somewhere that parses it in xen.git or on xenbits already? If they are in-use, then I can try to retain them for now until we have the kernel-doc infrastructure on xenbits -- they should be compatible with the kernel-doc syntax.
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h index c365b1b39e..409697dede 100644 --- a/xen/include/public/arch-arm.h +++ b/xen/include/public/arch-arm.h @@ -27,8 +27,8 @@ #ifndef __XEN_PUBLIC_ARCH_ARM_H__ #define __XEN_PUBLIC_ARCH_ARM_H__ -/* - * `incontents 50 arm_abi Hypercall Calling Convention +/** + * DOC: Hypercall Calling Convention * * A hypercall is issued using the ARM HVC instruction. * @@ -72,8 +72,8 @@ * Any cache allocation hints are acceptable. */ -/* - * `incontents 55 arm_hcall Supported Hypercalls +/** + * DOC: Supported Hypercalls * * Xen on ARM makes extensive use of hardware facilities and therefore * only a subset of the potential hypercalls are required. @@ -175,10 +175,17 @@ typedef union { type *p; uint64_aligned_t q; } \ __guest_handle_64_ ## name -/* +/** + * DOC: XEN_GUEST_HANDLE - a guest pointer in a struct + * * XEN_GUEST_HANDLE represents a guest pointer, when passed as a field * in a struct in memory. On ARM is always 8 bytes sizes and 8 bytes * aligned. + */ + +/** + * DOC: XEN_GUEST_HANDLE_PARAM - a guest pointer as a hypercall arg + * * XEN_GUEST_HANDLE_PARAM represents a guest pointer, when passed as an * hypercall argument. It is 4 bytes on aarch32 and 8 bytes on aarch64. */ @@ -201,7 +208,9 @@ typedef uint64_t xen_pfn_t; #define PRI_xen_pfn PRIx64 #define PRIu_xen_pfn PRIu64 -/* +/** + * DOC: XEN_LEGACY_MAX_VCPUS + * * Maximum number of virtual CPUs in legacy multi-processor guests. * Only one. All other VCPUS must use VCPUOP_register_vcpu_info. */ @@ -299,26 +308,28 @@ struct vcpu_guest_context { typedef struct vcpu_guest_context vcpu_guest_context_t; DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t); -/* + +/** + * struct xen_arch_domainconfig - arch-specific domain creation params + * * struct xen_arch_domainconfig's ABI is covered by * XEN_DOMCTL_INTERFACE_VERSION. */ +struct xen_arch_domainconfig { + /** @gic_version: IN/OUT parameter */ #define XEN_DOMCTL_CONFIG_GIC_NATIVE 0 #define XEN_DOMCTL_CONFIG_GIC_V2 1 #define XEN_DOMCTL_CONFIG_GIC_V3 2 - + uint8_t gic_version; + /** @tee_type: IN parameter */ #define XEN_DOMCTL_CONFIG_TEE_NONE 0 #define XEN_DOMCTL_CONFIG_TEE_OPTEE 1 - -struct xen_arch_domainconfig { - /* IN/OUT */ - uint8_t gic_version; - /* IN */ uint16_t tee_type; - /* IN */ + /** @nr_spis: IN parameter */ uint32_t nr_spis; - /* - * OUT + /** + * @clock_frequency: OUT parameter + * * Based on the property clock-frequency in the DT timer node. * The property may be present when the bootloader/firmware doesn't * set correctly CNTFRQ which hold the timer frequency.