search for: kdoc

Hi, On Mon, 2023-08-28 at 14:34 -0700, Shannon Nelson wrote: > Finally following up to Simon's suggestion for some kdoc attention > on struct virtio_pci_modern_device. > > Link: https://lore.kernel.org/netdev/ZE%2FQS0lnUvxFacjf at corigine.com/ > Cc: Simon Horman <simon.horman at corigine.com> > Signed-off-by: Shannon Nelson <shannon.nelson at amd.com> IMHO this is net-next material and...

Finally following up to Simon's suggestion for some kdoc attention on struct virtio_pci_modern_device. Link: https://lore.kernel.org/netdev/ZE%2FQS0lnUvxFacjf at corigine.com/ Cc: Simon Horman <simon.horman at corigine.com> Signed-off-by: Shannon Nelson <shannon.nelson at amd.com> --- include/linux/virtio_pci_modern.h | 34 +++++++++++++++++...

...t; > * range. > > > * > > > * This function is permitted to sleep. > > > * > > > * @Return: false if blocking was required, but @range is > > > * non-blocking. > > > * > > > */ > > > > Is this kdoc format for function pointers? > > heh, I'm sort of winging it, I'm not sure how function pointers are supposed > to be documented in kdoc. Actually the only key take-away here is to write > > "This function can sleep" > > as a separate sentence.. Sure &gt...

...range_notifier_ops > * @invalidate: Upon return the caller must stop using any SPTEs within this > * range. > * > * This function is permitted to sleep. > * > * @Return: false if blocking was required, but @range is > * non-blocking. > * > */ Is this kdoc format for function pointers? > > > +struct mmu_range_notifier_ops { > > + bool (*invalidate)(struct mmu_range_notifier *mrn, > > + const struct mmu_notifier_range *range, > > + unsigned long cur_seq); > > +}; > > + > > +struct mmu_range_not...

On Tue, Sep 08, 2020 at 02:34:24PM -0400, Lyude Paul wrote: > With the nitpicks addressed (note there were a couple of other spots where we > wanted to use Return: in the kdocs, but I didn't bother pointing all of them > out), all but patch 07 is: > > Reviewed-by: Lyude Paul <lyude at redhat.com> Thanks for the review. I fixed up the missing/bad docs and pushed the lot to drm-intel-next-queued (with Daniel's irc ack). PS. Had to s/drm_dp_downst...

...t; @@ -338,6 +344,33 @@ enum skb_drop_reason { > * for another host. > */ > SKB_DROP_REASON_IPV6_NDISC_NS_OTHERHOST, > + /** @SKB_DROP_REASON_BRIDGE_FWD_NO_BACKUP_PORT: failed to get a backup > + * port link when the destination port is down. > + */ That's not valid kdoc. Text can be on the same line as the value only in one-line comments. Otherwise: /** * @VALUE: bla bla bla * more blas. */ > +static inline bool should_deliver(const struct net_bridge_port *p, const struct sk_buff *skb, > + enum skb_drop_reason *need_reason) > { > struct...

...r other error In some cases useful info is found in syslog - try dmesg | tail or so # mount -t 9p -o trans=virtio /mnt/SASInstaller /mnt/SASInstaller The page you referenced also mentions using -oversion=9p2000.L. There is some additional info on the versions at http://landley.net/kdocs/Documentation/filesystems/9p.txt; that page says .L is the default, while http://wiki.qemu.org/Documentation/9psetup#Starting_the_Guest_using_libvirt says it's .U. I don't know how to tell which I ended up with. Thanks for the pointer. Ross ________________________________________ From:...

...n the caller must stop using any SPTEs within this >> * range. >> * >> * This function is permitted to sleep. >> * >> * @Return: false if blocking was required, but @range is >> * non-blocking. >> * >> */ > > Is this kdoc format for function pointers? heh, I'm sort of winging it, I'm not sure how function pointers are supposed to be documented in kdoc. Actually the only key take-away here is to write "This function can sleep" as a separate sentence.. ... >> c) Rename new one. Ideas: >&...

From: xu xin <xu.xin16 at zte.com.cn> This creates six drop reasons as follows, which will help users know the specific reason why bridge drops the packets when forwarding. 1) SKB_DROP_REASON_BRIDGE_FWD_NO_BACKUP_PORT: failed to get a backup port link when the destination port is down. 2) SKB_DROP_REASON_BRIDGE_FWD_SAME_PORT: destination port is the same with originating port when

While the way we find the associated connector for an encoder is just fine for legacy modesetting, it's not correct for nv50+ since that uses atomic modesetting. For reference, see the drm_encoder kdocs. Fix this by removing nouveau_encoder_connector_get(), and replacing it with nv04_encoder_get_connector(), nv50_outp_get_old_connector(), and nv50_outp_get_new_connector(). v2: * Don't line-wrap for_each_(old|new)_connector_in_state in nv50_outp_get_(old|new)_connector() - sravn Signed-of...

On 10/28/19 1:10 PM, Jason Gunthorpe wrote: ... > include/linux/mmu_notifier.h | 98 +++++++ > mm/Kconfig | 1 + > mm/mmu_notifier.c | 533 +++++++++++++++++++++++++++++++++-- > 3 files changed, 607 insertions(+), 25 deletions(-) > > diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h > index 12bd603d318ce7..51b92ba013ddce

...t * Rename drm_dp_mst_topology_get_(port|mstb)() -> drm_dp_mst_topology_try_get_(port|mstb)() and drm_dp_mst_topology_ref_(port|mstb)() -> drm_dp_mst_topology_get_(port|mstb)() - danvet * s/should/must in docs - danvet * WARN_ON(refcount == 0) in topology_get_(mstb|port) - danvet * Move kdocs for mstb/port structs inline - danvet * Split drm_dp_get_last_connected_port_and_mstb() changes into their own commit - danvet Signed-off-by: Lyude Paul <lyude at redhat.com> Reviewed-by: Harry Wentland <harry.wentland at amd.com> Cc: Daniel Vetter <daniel at ffwll.ch> Cc: Dav...

...t * Rename drm_dp_mst_topology_get_(port|mstb)() -> drm_dp_mst_topology_try_get_(port|mstb)() and drm_dp_mst_topology_ref_(port|mstb)() -> drm_dp_mst_topology_get_(port|mstb)() - danvet * s/should/must in docs - danvet * WARN_ON(refcount == 0) in topology_get_(mstb|port) - danvet * Move kdocs for mstb/port structs inline - danvet * Split drm_dp_get_last_connected_port_and_mstb() changes into their own commit - danvet Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: Daniel Vetter <daniel at ffwll.ch> Cc: David Airlie <airlied at redhat.com> Cc: Jerry Zuo <Jerr...

To start off: this patch series is less work to review then it looks - most (but not all) of the nouveau related work has already been reviewed elsewhere. Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM

Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM related and MST related fixes, we're missing a lot of nice things that have been added to DRM since this was originally written. Additionally, the code

This is the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream implementation requires a

This is the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream implementation requires a

Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM related and MST related fixes, we're missing a lot of nice things that have been added to DRM since this was originally written. Additionally, the code

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrj?l? came up

This is the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream implementation requires a