Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 13 4月, 2020 3 次提交
    • A
      ARM: Prepare Realtek RTD1195 · 86aeee4d
      由 Andreas Färber 提交于 
      Introduce ARCH_REALTEK Kconfig option also for 32-bit Arm.

Override the text offset to cope with boot ROM occupying first 0xa800
bytes and further reservations up to 0xf4000 (compare Device Tree).

Add a custom machine_desc to enforce memory carveout for I/O registers.
Signed-off-by: NAndreas Färber <afaerber@suse.de>
      86aeee4d
    • L
      MAINTAINERS: sort field names for all entries · 3b50142d
      由 Linus Torvalds 提交于 
      This sorts the actual field names too, potentially causing even more
chaos and confusion at merge time if you have edited the MAINTAINERS
file.  But the end result is a more consistent layout, and hopefully
it's a one-time pain minimized by doing this just before the -rc1
release.

This was entirely scripted:

  ./scripts/parse-maintainers.pl --input=MAINTAINERS --output=MAINTAINERS --order
Requested-by: NJoe Perches <joe@perches.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3b50142d
    • L
      MAINTAINERS: sort entries by entry name · 4400b7d6
      由 Linus Torvalds 提交于 
      They are all supposed to be sorted, but people who add new entries don't
always know the alphabet.  Plus sometimes the entry names get edited,
and people don't then re-order the entry.

Let's see how painful this will be for merging purposes (the MAINTAINERS
file is often edited in various different trees), but Joe claims there's
relatively few patches in -next that touch this, and doing it just
before -rc1 is likely the best time.  Fingers crossed.

This was scripted with

  /scripts/parse-maintainers.pl --input=MAINTAINERS --output=MAINTAINERS

but then I also ended up manually upper-casing a few entry names that
stood out when looking at the end result.
Requested-by: NJoe Perches <joe@perches.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4400b7d6
  3. 11 4月, 2020 2 次提交
  5. 08 4月, 2020 1 次提交
  7. 02 4月, 2020 5 次提交
    • M
      vdpa: move to drivers/vdpa · c9b9f5f8
      由 Michael S. Tsirkin 提交于 
      We have both vhost and virtio drivers that depend on vdpa.
It's easier to locate it at a top level directory otherwise
we run into issues e.g. if vhost is built-in but virtio
is modular.  Let's just move it up a level.
Reported-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      c9b9f5f8
    • M
      MAINTAINERS: drop an old reference to stm32 pwm timers doc · 8967918e
      由 Mauro Carvalho Chehab 提交于 
      The DT files for pwm were merged and converted to json.
The new reference is already at the maintainers file, so
just drop the obsoleted one.

Fixes: 56fb34d8 ("dt-bindings: mfd: Convert stm32 timers bindings to json-schema")
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: NRob Herring <robh@kernel.org>
      8967918e
    • M
      MAINTAINERS: dt: update etnaviv file reference · a3cc3345
      由 Mauro Carvalho Chehab 提交于 
      The etnaviv file was converted to json and renamed.

Update its reference accordingly.

Fixes: 90aeca87 ("dt-bindings: display: Convert etnaviv to json-schema")
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: NRob Herring <robh@kernel.org>
      a3cc3345
    • J
      vDPA: introduce vDPA bus · 961e9c84
      由 Jason Wang 提交于 
      vDPA device is a device that uses a datapath which complies with the
virtio specifications with vendor specific control path. vDPA devices
can be both physically located on the hardware or emulated by
software. vDPA hardware devices are usually implemented through PCIE
with the following types:

- PF (Physical Function) - A single Physical Function
- VF (Virtual Function) - Device that supports single root I/O
  virtualization (SR-IOV). Its Virtual Function (VF) represents a
  virtualized instance of the device that can be assigned to different
  partitions
- ADI (Assignable Device Interface) and its equivalents - With
  technologies such as Intel Scalable IOV, a virtual device (VDEV)
  composed by host OS utilizing one or more ADIs. Or its equivalent
  like SF (Sub function) from Mellanox.

>From a driver's perspective, depends on how and where the DMA
translation is done, vDPA devices are split into two types:

- Platform specific DMA translation - From the driver's perspective,
  the device can be used on a platform where device access to data in
  memory is limited and/or translated. An example is a PCIE vDPA whose
  DMA request was tagged via a bus (e.g PCIE) specific way. DMA
  translation and protection are done at PCIE bus IOMMU level.
- Device specific DMA translation - The device implements DMA
  isolation and protection through its own logic. An example is a vDPA
  device which uses on-chip IOMMU.

To hide the differences and complexity of the above types for a vDPA
device/IOMMU options and in order to present a generic virtio device
to the upper layer, a device agnostic framework is required.

This patch introduces a software vDPA bus which abstracts the
common attributes of vDPA device, vDPA bus driver and the
communication method (vdpa_config_ops) between the vDPA device
abstraction and the vDPA bus driver. This allows multiple types of
drivers to be used for vDPA device like the virtio_vdpa and vhost_vdpa
driver to operate on the bus and allow vDPA device could be used by
either kernel virtio driver or userspace vhost drivers as:

   virtio drivers  vhost drivers
          |             |
    [virtio bus]   [vhost uAPI]
          |             |
   virtio device   vhost device
   virtio_vdpa drv vhost_vdpa drv
             \       /
            [vDPA bus]
                 |
            vDPA device
            hardware drv
                 |
            [hardware bus]
                 |
            vDPA hardware

With the abstraction of vDPA bus and vDPA bus operations, the
difference and complexity of the under layer hardware is hidden from
upper layer. The vDPA bus drivers on top can use a unified
vdpa_config_ops to control different types of vDPA device.
Signed-off-by: NJason Wang <jasowang@redhat.com>
Link: https://lore.kernel.org/r/20200326140125.19794-6-jasowang@redhat.comSigned-off-by: NMichael S. Tsirkin <mst@redhat.com>
      961e9c84
    • J
      vhost: factor out IOTLB · 0bbe3066
      由 Jason Wang 提交于 
      This patch factors out IOTLB into a dedicated module in order to be
reused by other modules like vringh. User may choose to enable the
automatic retiring by specifying VHOST_IOTLB_FLAG_RETIRE flag to fit
for the case of vhost device IOTLB implementation.
Signed-off-by: NJason Wang <jasowang@redhat.com>
Link: https://lore.kernel.org/r/20200326140125.19794-4-jasowang@redhat.comSigned-off-by: NMichael S. Tsirkin <mst@redhat.com>
      0bbe3066
  9. 31 3月, 2020 2 次提交
  11. 30 3月, 2020 2 次提交
  13. 28 3月, 2020 1 次提交
  15. 27 3月, 2020 3 次提交
  17. 26 3月, 2020 11 次提交
  19. 25 3月, 2020 6 次提交
  21. 24 3月, 2020 3 次提交
  23. 23 3月, 2020 1 次提交