[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YLosn8r6pg4AUC14@kroah.com>
Date: Fri, 4 Jun 2021 15:37:35 +0200
From: Greg KH <greg@...ah.com>
To: Rajat Jain <rajatja@...gle.com>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: build warning after merge of the usb tree
On Tue, Jun 01, 2021 at 10:39:42AM -0700, Rajat Jain wrote:
> Hello,
>
>
> On Tue, Jun 1, 2021 at 1:30 AM Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> >
> > Hi all,
> >
> > After merging the usb tree, today's linux-next build (htmldocs) produced
> > this warning:
> >
> > Documentation/ABI/testing/sysfs-devices-removable:2: WARNING: Unexpected indentation.
> > Documentation/ABI/testing/sysfs-devices-removable:2: WARNING: Block quote ends without a blank line; unexpected unindent.
>
> I'd be happy to send a patch to fix this, but I didn't really
> understand what needs to be done.
>
> Here is the relevant documentation update in the patch:
>
> +What: /sys/devices/.../removable
> +Date: May 2021
> +Contact: Rajat Jain <rajatxjain@...il.com>
> +Description:
> + Information about whether a given device can be removed from the
> + platform by the user. This is determined by its subsystem in a
> + bus / platform-specific way. This attribute is only present for
> + devices that can support determining such information:
> +
> + "removable": device can be removed from the platform by the user
> + "fixed": device is fixed to the platform / cannot be removed
> + by the user.
> + "unknown": The information is unavailable / cannot be deduced.
> +
> + Currently this is only supported by USB (which infers the
> + information from a combination of hub descriptor bits and
> + platform-specific data such as ACPI).
>
> I'd be happy to send a patch if you can point me what needs to be done
> (or let Stephen / Greg / some one else do it if it is easier to just
> do it instead of guiding me).
I do not know what the "right" thing to do here is, sorry. Maybe one of
the kerneldoc people know?
greg k-h
Powered by blists - more mailing lists