The AVR32 architecture support has been removed from the Linux kernel,
hence remove all references to it from Documentation.
Signed-off-by: NHans-Christian Noren Egtvedt <egtvedt@samfundet.no>
Signed-off-by: NHåvard Skinnemoen <hskinnemoen@gmail.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@microchip.com>
Acked-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

This commit gets rid of some minor errors in Documentation/:
* cputopology.txt: drawes -> drawers
* debugging-via-ohci1394.txt: remove an unnecessary line break
* static-keys: statemnts -> statements
* zorro.txt: busses -> buses
Signed-off-by: NStan Drozd <drozdziak1@gmail.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

This commit fixes a repeated "the" in vfio-mediated-device.txt and reflows the
paragraph.
Signed-off-by: NStan Drozd <drozdziak1@gmail.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

This commit fixes a misspelled header name in the ioctl numbers list
Signed-off-by: NStan Drozd <drozdziak1@gmail.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Documentation/DocBook/Makefile hard codes the prefixed path to which you
can install the built man pages (/usr/local prefix). That's unfortunate
since the user may want to install to another prefix or location (for
example, a distribution packaging the man pages may want to install to a
random temporary location in the build process).

Be flexible and allow the prefixed path to which we install man pages to be
changed with the INSTALL_MAN_PATH environment variable (and use the same
default as other similar variables like INSTALL_HDR_PATH).
Signed-off-by: NHerton R. Krzesinski <herton@redhat.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Commit feb6cd6a ("thermal/intel_powerclamp: stop sched tick in forced
idle") changed how idle injection accouting, so we need to update
the documentation accordingly.

This patch also expands more details on the behavior of cur_state.
Signed-off-by: NJacob Pan <jacob.jun.pan@linux.intel.com>
Reported-by: NWang, Xiaolong <xiaolong.wang@intel.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

The /proc/bus/usb/devices got moved to sysfs. It is now
sitting at:
	/sys/kernel/debug/usb/devices
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

The contents of proc_usb_info.txt complements what's there at
driver-api usb book. Yet, it is outdated, as it still refers
to the USB character devices as usbfs.

So, move the contents to usb.rst, adjusting it to point to
the right places.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

The philips.txt file were at the wrong place: it should be,
instead, at Documentation/media.

Move and convert it.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

There's no usbfs anymore. The old features are now either
exported to /dev/bus/usb or via debugfs.

Update documentation accordingly, pointing to the new
places where the character devices and usb/devices are
now placed.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

the path in the example cmd is out of date, and the path for now
is also mentioned in the same file
Signed-off-by: NPerr Zhang <strongbox8@zoho.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

In Documentation/process/4.Coding.rst there were a couple of paragraphs
that spilled over the 80 character line length. This was likely caused
when the document was converted to reStructuredText. Re-flow the
paragraphs and make the document references proper reStructuredText
:ref: links.

This also adds the appropriate reStructuredText file heading to
kernel-parameters.rst as referenced by the kernel-parameters link in
this patch.
Signed-off-by: NAndrew Clayton <andrew@digital-domain.net>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Document the fact that the autosuspend delay and enable helpers may
change the power.usage_count and resume or suspend a device depending on
the values of power.autosuspend_delay and power.use_autosuspend.

Note that this means that a driver must disable autosuspend before
disabling runtime pm on probe errors and on driver unbind if the device
is to be suspended upon return (as a negative delay may otherwise keep
the device resumed).
Signed-off-by: NJohan Hovold <johan@kernel.org>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Update the autosuspend documentation which claimed that the autosuspend
delay is not taken into account when using the non-autosuspend helper
functions, something which is no longer true since commit d66e6db2
("PM / Runtime: Respect autosuspend when idle triggers suspend").

This specifically means that drivers must now disable autosuspend before
disabling runtime pm in probe error paths and remove callbacks if
pm_runtime_put_sync was being used to suspend the device before
returning. (If an idle callback can prevent suspend,
pm_runtime_put_sync_suspend must be used instead of pm_runtime_put_sync
as before.)

Also remove the claim that the autosuspend helpers behave "just like
the non-autosuspend counterparts", something which have never really
been true as some of the latter use idle notifications.
Signed-off-by: NJohan Hovold <johan@kernel.org>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch extends the device tree support for the pca9532 by adding
the leds 'default-state' property.
Signed-off-by: NFelix Brack <fb@ltec.ch>
Signed-off-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>

This patch introduces a simple heuristic to load applications quickly,
and to perform the I/O requested by interactive applications just as
quickly. To this purpose, both a newly-created queue and a queue
associated with an interactive application (we explain in a moment how
BFQ decides whether the associated application is interactive),
receive the following two special treatments:

1) The weight of the queue is raised.

2) The queue unconditionally enjoys device idling when it empties; in
fact, if the requests of a queue are sync, then performing device
idling for the queue is a necessary condition to guarantee that the
queue receives a fraction of the throughput proportional to its weight
(see [1] for details).

For brevity, we call just weight-raising the combination of these
two preferential treatments. For a newly-created queue,
weight-raising starts immediately and lasts for a time interval that:
1) depends on the device speed and type (rotational or
non-rotational), and 2) is equal to the time needed to load (start up)
a large-size application on that device, with cold caches and with no
additional workload.

Finally, as for guaranteeing a fast execution to interactive,
I/O-related tasks (such as opening a file), consider that any
interactive application blocks and waits for user input both after
starting up and after executing some task. After a while, the user may
trigger new operations, after which the application stops again, and
so on. Accordingly, the low-latency heuristic weight-raises again a
queue in case it becomes backlogged after being idle for a
sufficiently long (configurable) time. The weight-raising then lasts
for the same time as for a just-created queue.

According to our experiments, the combination of this low-latency
heuristic and of the improvements described in the previous patch
allows BFQ to guarantee a high application responsiveness.

[1] P. Valente, A. Avanzini, "Evolution of the BFQ Storage I/O
    Scheduler", Proceedings of the First Workshop on Mobile System
    Technologies (MST-2015), May 2015.
    http://algogroup.unimore.it/people/paolo/disk_sched/mst-2015.pdfSigned-off-by: NPaolo Valente <paolo.valente@linaro.org>
Signed-off-by: NArianna Avanzini <avanzini.arianna@gmail.com>
Signed-off-by: NJens Axboe <axboe@fb.com>

Add complete support for full hierarchical scheduling, with a cgroups
interface. Full hierarchical scheduling is implemented through the
'entity' abstraction: both bfq_queues, i.e., the internal BFQ queues
associated with processes, and groups are represented in general by
entities. Given the bfq_queues associated with the processes belonging
to a given group, the entities representing these queues are sons of
the entity representing the group. At higher levels, if a group, say
G, contains other groups, then the entity representing G is the parent
entity of the entities representing the groups in G.

Hierarchical scheduling is performed as follows: if the timestamps of
a leaf entity (i.e., of a bfq_queue) change, and such a change lets
the entity become the next-to-serve entity for its parent entity, then
the timestamps of the parent entity are recomputed as a function of
the budget of its new next-to-serve leaf entity. If the parent entity
belongs, in its turn, to a group, and its new timestamps let it become
the next-to-serve for its parent entity, then the timestamps of the
latter parent entity are recomputed as well, and so on. When a new
bfq_queue must be set in service, the reverse path is followed: the
next-to-serve highest-level entity is chosen, then its next-to-serve
child entity, and so on, until the next-to-serve leaf entity is
reached, and the bfq_queue that this entity represents is set in
service.

Writeback is accounted for on a per-group basis, i.e., for each group,
the async I/O requests of the processes of the group are enqueued in a
distinct bfq_queue, and the entity associated with this queue is a
child of the entity associated with the group.

Weights can be assigned explicitly to groups and processes through the
cgroups interface, differently from what happens, for single
processes, if the cgroups interface is not used (as explained in the
description of the previous patch). In particular, since each node has
a full scheduler, each group can be assigned its own weight.
Signed-off-by: NFabio Checconi <fchecconi@gmail.com>
Signed-off-by: NPaolo Valente <paolo.valente@linaro.org>
Signed-off-by: NArianna Avanzini <avanzini.arianna@gmail.com>
Signed-off-by: NJens Axboe <axboe@fb.com>

We tag as v0 the version of BFQ containing only BFQ's engine plus
hierarchical support. BFQ's engine is introduced by this commit, while
hierarchical support is added by next commit. We use the v0 tag to
distinguish this minimal version of BFQ from the versions containing
also the features and the improvements added by next commits. BFQ-v0
coincides with the version of BFQ submitted a few years ago [1], apart
from the introduction of preemption, described below.

BFQ is a proportional-share I/O scheduler, whose general structure,
plus a lot of code, are borrowed from CFQ.

- Each process doing I/O on a device is associated with a weight and a
  (bfq_)queue.

- BFQ grants exclusive access to the device, for a while, to one queue
  (process) at a time, and implements this service model by
  associating every queue with a budget, measured in number of
  sectors.

  - After a queue is granted access to the device, the budget of the
    queue is decremented, on each request dispatch, by the size of the
    request.

  - The in-service queue is expired, i.e., its service is suspended,
    only if one of the following events occurs: 1) the queue finishes
    its budget, 2) the queue empties, 3) a "budget timeout" fires.

    - The budget timeout prevents processes doing random I/O from
      holding the device for too long and dramatically reducing
      throughput.

    - Actually, as in CFQ, a queue associated with a process issuing
      sync requests may not be expired immediately when it empties. In
      contrast, BFQ may idle the device for a short time interval,
      giving the process the chance to go on being served if it issues
      a new request in time. Device idling typically boosts the
      throughput on rotational devices, if processes do synchronous
      and sequential I/O. In addition, under BFQ, device idling is
      also instrumental in guaranteeing the desired throughput
      fraction to processes issuing sync requests (see [2] for
      details).

      - With respect to idling for service guarantees, if several
        processes are competing for the device at the same time, but
        all processes (and groups, after the following commit) have
        the same weight, then BFQ guarantees the expected throughput
        distribution without ever idling the device. Throughput is
        thus as high as possible in this common scenario.

  - Queues are scheduled according to a variant of WF2Q+, named
    B-WF2Q+, and implemented using an augmented rb-tree to preserve an
    O(log N) overall complexity.  See [2] for more details. B-WF2Q+ is
    also ready for hierarchical scheduling. However, for a cleaner
    logical breakdown, the code that enables and completes
    hierarchical support is provided in the next commit, which focuses
    exactly on this feature.

  - B-WF2Q+ guarantees a tight deviation with respect to an ideal,
    perfectly fair, and smooth service. In particular, B-WF2Q+
    guarantees that each queue receives a fraction of the device
    throughput proportional to its weight, even if the throughput
    fluctuates, and regardless of: the device parameters, the current
    workload and the budgets assigned to the queue.

  - The last, budget-independence, property (although probably
    counterintuitive in the first place) is definitely beneficial, for
    the following reasons:

    - First, with any proportional-share scheduler, the maximum
      deviation with respect to an ideal service is proportional to
      the maximum budget (slice) assigned to queues. As a consequence,
      BFQ can keep this deviation tight not only because of the
      accurate service of B-WF2Q+, but also because BFQ *does not*
      need to assign a larger budget to a queue to let the queue
      receive a higher fraction of the device throughput.

    - Second, BFQ is free to choose, for every process (queue), the
      budget that best fits the needs of the process, or best
      leverages the I/O pattern of the process. In particular, BFQ
      updates queue budgets with a simple feedback-loop algorithm that
      allows a high throughput to be achieved, while still providing
      tight latency guarantees to time-sensitive applications. When
      the in-service queue expires, this algorithm computes the next
      budget of the queue so as to:

      - Let large budgets be eventually assigned to the queues
        associated with I/O-bound applications performing sequential
        I/O: in fact, the longer these applications are served once
        got access to the device, the higher the throughput is.

      - Let small budgets be eventually assigned to the queues
        associated with time-sensitive applications (which typically
        perform sporadic and short I/O), because, the smaller the
        budget assigned to a queue waiting for service is, the sooner
        B-WF2Q+ will serve that queue (Subsec 3.3 in [2]).

- Weights can be assigned to processes only indirectly, through I/O
  priorities, and according to the relation:
  weight = 10 * (IOPRIO_BE_NR - ioprio).
  The next patch provides, instead, a cgroups interface through which
  weights can be assigned explicitly.

- If several processes are competing for the device at the same time,
  but all processes and groups have the same weight, then BFQ
  guarantees the expected throughput distribution without ever idling
  the device. It uses preemption instead. Throughput is then much
  higher in this common scenario.

- ioprio classes are served in strict priority order, i.e.,
  lower-priority queues are not served as long as there are
  higher-priority queues.  Among queues in the same class, the
  bandwidth is distributed in proportion to the weight of each
  queue. A very thin extra bandwidth is however guaranteed to the Idle
  class, to prevent it from starving.

- If the strict_guarantees parameter is set (default: unset), then BFQ
     - always performs idling when the in-service queue becomes empty;
     - forces the device to serve one I/O request at a time, by
       dispatching a new request only if there is no outstanding
       request.
  In the presence of differentiated weights or I/O-request sizes,
  both the above conditions are needed to guarantee that every
  queue receives its allotted share of the bandwidth (see
  Documentation/block/bfq-iosched.txt for more details). Setting
  strict_guarantees may evidently affect throughput.

[1] https://lkml.org/lkml/2008/4/1/234
    https://lkml.org/lkml/2008/11/11/148

[2] P. Valente and M. Andreolini, "Improving Application
    Responsiveness with the BFQ Disk I/O Scheduler", Proceedings of
    the 5th Annual International Systems and Storage Conference
    (SYSTOR '12), June 2012.
    Slightly extended version:
    http://algogroup.unimore.it/people/paolo/disk_sched/bfq-v1-suite-
							results.pdf
Signed-off-by: NFabio Checconi <fchecconi@gmail.com>
Signed-off-by: NPaolo Valente <paolo.valente@linaro.org>
Signed-off-by: NArianna Avanzini <avanzini.arianna@gmail.com>
Signed-off-by: NJens Axboe <axboe@fb.com>

Fix some typos in the linuxized-acpica.txt document.
Signed-off-by: NCao jin <caoj.fnst@cn.fujitsu.com>
[ rjw: Subject / changelog ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch introduces pblk, a host-side translation layer for
Open-Channel SSDs to expose them like block devices. The translation
layer allows data placement decisions, and I/O scheduling to be
managed by the host, enabling users to optimize the SSD for their
specific workloads.

An open-channel SSD has a set of LUNs (parallel units) and a
collection of blocks. Each block can be read in any order, but
writes must be sequential. Writes may also fail, and if a block
requires it, must also be reset before new writes can be
applied.

To manage the constraints, pblk maintains a logical to
physical address (L2P) table,  write cache, garbage
collection logic, recovery scheme, and logic to rate-limit
user I/Os versus garbage collection I/Os.

The L2P table is fully-associative and manages sectors at a
4KB granularity. Pblk stores the L2P table in two places, in
the out-of-band area of the media and on the last page of a
line. In the cause of a power failure, pblk will perform a
scan to recover the L2P table.

The user data is organized into lines. A line is data
striped across blocks and LUNs. The lines enable the host to
reduce the amount of metadata to maintain besides the user
data and makes it easier to implement RAID or erasure coding
in the future.

pblk implements multi-tenant support and can be instantiated
multiple times on the same drive. Each instance owns a
portion of the SSD - both regarding I/O bandwidth and
capacity - providing I/O isolation for each case.

Finally, pblk also exposes a sysfs interface that allows
user-space to peek into the internals of pblk. The interface
is available at /dev/block/*/pblk/ where * is the block
device name exposed.

This work also contains contributions from:
  Matias Bjørling <matias@cnexlabs.com>
  Simon A. F. Lund <slund@cnexlabs.com>
  Young Tack Jin <youngtack.jin@gmail.com>
  Huaicheng Li <huaicheng@cs.uchicago.edu>
Signed-off-by: NJavier González <javier@cnexlabs.com>
Signed-off-by: NMatias Bjørling <matias@cnexlabs.com>
Signed-off-by: NJens Axboe <axboe@fb.com>

The Kyber I/O scheduler is an I/O scheduler for fast devices designed to
scale to multiple queues. Users configure only two knobs, the target
read and synchronous write latencies, and the scheduler tunes itself to
achieve that latency goal.

The implementation is based on "tokens", built on top of the scalable
bitmap library. Tokens serve as a mechanism for limiting requests. There
are two tiers of tokens: queueing tokens and dispatch tokens.

A queueing token is required to allocate a request. In fact, these
tokens are actually the blk-mq internal scheduler tags, but the
scheduler manages the allocation directly in order to implement its
policy.

Dispatch tokens are device-wide and split up into two scheduling
domains: reads vs. writes. Each hardware queue dispatches batches
round-robin between the scheduling domains as long as tokens are
available for that domain.

These tokens can be used as the mechanism to enable various policies.
The policy Kyber uses is inspired by active queue management techniques
for network routing, similar to blk-wbt. The scheduler monitors
latencies and scales the number of dispatch tokens accordingly. Queueing
tokens are used to prevent starvation of synchronous requests by
asynchronous requests.

Various extensions are possible, including better heuristics and ionice
support. The new scheduler isn't set as the default yet.
Signed-off-by: NOmar Sandoval <osandov@fb.com>
Signed-off-by: NJens Axboe <axboe@fb.com>

This drivers was added in 2008, but as far as a I can tell we never had a
single platform that actually registered resources for the platform driver.

It's also been unmaintained for a long time and apparently has a ATA mode
that can be driven using the IDE/libata subsystem.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NHannes Reinecke <hare@suse.com>
Signed-off-by: NJens Axboe <axboe@fb.com>

Update the 'intel_rdt_ui' documentation to have Memory bandwidth(b/w)
allocation interface usage.
Signed-off-by: NVikas Shivappa <vikas.shivappa@linux.intel.com>
Cc: ravi.v.shankar@intel.com
Cc: tony.luck@intel.com
Cc: fenghua.yu@intel.com
Cc: vikas.shivappa@intel.com
Link: http://lkml.kernel.org/r/1491611637-20417-2-git-send-email-vikas.shivappa@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Add a user-space program to compute/generate the PELT constants.

The kernel/sched/sched-pelt.h header will contain the output of
this program.
Signed-off-by: NYuyang Du <yuyang.du@intel.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: matt@codeblueprint.co.uk
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: umgwanakikbuti@gmail.com
Cc: vincent.guittot@linaro.org
Link: http://lkml.kernel.org/r/1486935863-25251-2-git-send-email-yuyang.du@intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

This add a new device tree binding for LEGO MINDSTORMS EV3 battery. The EV3
has some built-in capability for monitoring the attached battery.
Signed-off-by: NDavid Lechner <david@lechnology.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

The DT binding document for LTC2941 and LTC2943 battery gauges did not use
a vendor prefix in the listed compatible strings. The driver says that the
manufacturer is Linear Technology which is "lltc" in vendor-prefixes.txt.

There isn't an upstream Device Tree source file that has nodes defined for
these devices, so there's no need to keep the old compatible strings.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

The custom CPCAP PMIC used on Motorola phones such as Droid 4 has a
USB battery charger. It can optionally also have a companion chip that
is used for wireless charging.

The charger on CPCAP also can feed VBUS for the USB host mode. This
can be handled by the existing kernel phy_companion interface.

Cc: devicetree@vger.kernel.org
Cc: Marcel Partap <mpartap@gmx.net>
Cc: Michael Scott <michael.scott@linaro.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

Fix the max8925_batter typo in the file name.
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

This adds device tree bindings to the power management controller
in the Gemini SoC.

Cc: devicetree@vger.kernel.org
Cc: Janos Laube <janos.dev@gmail.com>
Cc: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Cc: Hans Ulli Kroll <ulli.kroll@googlemail.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

Make the syscon-poweroff driver accept value and mask instead of
just value.

Prior to this patch, the property name for the value was 'mask'. If
only the mask property is defined on a node, maintain compatibility
by using it as the value.
Signed-off-by: NGuy Shapiro <guy.shapiro@mobi-wize.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NSebastian Reichel <sre@kernel.org>

/sys/firmware/acpi/hotplug/force_remove was presumably added to support
auto offlining in the past. This is, however, inherently dangerous for
some hotplugable resources like memory. The memory offlining fails when
the memory is still in use and cannot be dropped or migrated. If we
ignore the failure we are basically allowing for subtle memory
corruption or a crash.

We have actually noticed the later while hitting BUG() during the memory
hotremove (remove_memory):
	ret = walk_memory_range(PFN_DOWN(start), PFN_UP(start + size - 1), NULL,
			check_memblock_offlined_cb);
	if (ret)
		BUG();

it took us quite non-trivial time realize that the customer had
force_remove enabled. Even if the BUG was removed here and we could
propagate the error up the call chain it wouldn't help at all because
then we would hit a crash or a memory corruption later and harder to
debug. So force_remove is unfixable for the memory hotremove. We haven't
checked other hotplugable resources to be prone to a similar problems.

Remove the force_remove functionality because it is not fixable currently.
Keep the sysfs file and report an error if somebody tries to enable it.
Encourage users to report about the missing functionality and work with
them with an alternative solution.
Reviewed-by: NLee, Chun-Yi <jlee@suse.com>
Signed-off-by: NMichal Hocko <mhocko@suse.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The "hisilicon,pcie-almost-ecam" binding goes against the usual DT
conventions, and is non-sensical in that it describes the IP based on
what it isn't.  Fix the DT binding with "hisilicon,hip06-pcie-ecam"
and "hisilicon,hip07-pcie-ecam".
Signed-off-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NDongdong Liu <liudongdong3@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

As some USB documentation files got moved, adjust their
cross-references to their new place.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Get rid of those warnings:

    Documentation/driver-api/usb/usb.rst:615: ERROR: Unknown target name: "usb_type".
    Documentation/driver-api/usb/usb.rst:615: ERROR: Unknown target name: "usb_dir".
    Documentation/driver-api/usb/usb.rst:615: ERROR: Unknown target name: "usb_recip".
    Documentation/driver-api/usb/usb.rst:679: ERROR: Unknown target name: "usbdevfs_urb_type".
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

The URB doc describes the Kernel mechanism that do USB transfers.
While the functions are already described at urb.h, there are a
number of concepts and theory that are important for USB driver
developers.

Convert it to ReST and use C ref links to point to the places
at usb.h where each function and struct is located.

A few of those descriptions were incomplete. While here, update
to reflect the current API status.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

This document describe some USB core features. Add it to the
driver-api book.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

This document describe some USB core features. Add it to the
driver-api book.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

This document describe some USB core features. Add it to the
driver-api book.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

This document describe some USB core features. Add it to the
driver-api book.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

This document describe some USB core functions. Add it to the
driver-api book.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>