Add support for on-chip I2C controller used on newer UniPhier SoCs
such as PH1-Pro4, PH1-Pro5, etc. This adapter is equipped with
8-depth TX/RX FIFOs.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Add support for on-chip I2C controller used on old UniPhier SoCs
such as PH1-LD4, PH1-sLD8, etc. This adapter is so simple that
it has no FIFO in it.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The patch reverts commit a445900c90 (i2c: designware: Add support for
AMD I2C controller). It never worked anyhow because it did not register
a proper clkdev.
Since kernel 4.1 starts to support APD, there is no need to get freq
from id->driver_data for AMD0010. clkdev is supposed to be already
registered in APD.
So, revert old design and make AMD0010 looks like other ones.
Signed-off-by: Ken Xue <Ken.Xue@amd.com>
Signed-off-by: Xiangliang Yu <Xiangliang.Yu@amd.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
When the DISP1 power domain is powered off, there's two clocks that need
to be temporarily reparented to OSC, and back to their original parents
when the domain is powered on again.
We expose these two clocks in the DT bindings so that the DT node of the
power domain can reference them.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Kukjin Kim <kgene@kernel.org>
Add the Altera PCIe host controller driver.
[bhelgaas: whitespace, fold in DT and maintainer updates, OF_PCI
dependency from Arnd]
Signed-off-by: Ley Foon Tan <lftan@altera.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Rob Herring <robh@kernel.org> (DT binding)
If the CLEAN_SHUTDOWN flag is not set when a cache is loaded then all cache
blocks are marked as dirty and a full writeback occurs.
__commit_transaction() is responsible for setting/clearing
CLEAN_SHUTDOWN (based the flags_mutator that is passed in).
Fix this issue, of the cache's on-disk flags being wrong, by making sure
__commit_transaction() does not reset the flags after the mutator has
altered the flags in preparation for them being serialized to disk.
before:
sb_flags = mutator(le32_to_cpu(disk_super->flags));
disk_super->flags = cpu_to_le32(sb_flags);
disk_super->flags = cpu_to_le32(cmd->flags);
after:
disk_super->flags = cpu_to_le32(cmd->flags);
sb_flags = mutator(le32_to_cpu(disk_super->flags));
disk_super->flags = cpu_to_le32(sb_flags);
Reported-by: Bogdan Vasiliev <bogdan.vasiliev@gmail.com>
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
btree_split_beneath()'s error path had an outstanding FIXME that speaks
directly to the potential for _not_ cleaning up a previously allocated
bufio-backed block.
Fix this by releasing the previously allocated bufio block using
unlock_block().
Reported-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Acked-by: Joe Thornber <thornber@redhat.com>
Cc: stable@vger.kernel.org
Commit 4c7e309340 ("dm btree remove: fix bug in redistribute3") wasn't
a complete fix for redistribute3().
The redistribute3 function takes 3 btree nodes and shares out the entries
evenly between them. If the three nodes in total contained
(MAX_ENTRIES * 3) - 1 entries between them then this was erroneously getting
rebalanced as (MAX_ENTRIES - 1) on the left and right, and (MAX_ENTRIES + 1) in
the center.
Fix this issue by being more careful about calculating the target number
of entries for the left and right nodes.
Unit tested in userspace using this program:
https://github.com/jthornber/redistribute3-test/blob/master/redistribute3_t.c
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
- Add IOMUXC LPSR (Low Power State Retention) device for i.MX7D.
- Add a few low power mode related devices and touch controller for
i.MX6UL.
- Add a number of devices for i.MX7D SDB board support, USB, Dual FEC,
and eMMC5.0.
- i.MX6 Boundary Devices updates: relicense under GPLv2/X11, add Okaya
LCD, touch and wifi support, add new boards Nitrogen6_Lite and
Nitrogen6_Max.
- Enable touch screen and NAND Flash controller for a few Vybrid
devices.
- Some random and small updates on LS1021A and MXS support.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJWJQUPAAoJEFBXWFqHsHzOo+cH/irx+abVdFV97q6M0VwFsQ3/
Tf4/CsdiTjM5ZDrKZEtXzP8BZl+ZO4tQXLspP+wVceQ+PVUiVvdAHu0l68iuJRrA
+Bj9VrLIzMDf7FVpzbZHZD3kd1NALGh/5i0TerkuZMNl1KH57HyGjLnjKH43n7uz
mFPeZFAQMwSjEnRJj/6217Itqi+LurARJsnXQs6uhQ7feSsA88HU3EQ8QsiZqiAu
MULAJBYaE09shlokuXIKx67t8outdb8C0Uue64nt42y8NR0m5eVVG7NJoF+23T6C
CRX5zveYa7D2QXTkihvjdRpazhLiPnwV3RCVejLOZMk0G14hD9U39jkTp+9ws1w=
=kPBq
-----END PGP SIGNATURE-----
Merge tag 'imx-dt-4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into next/dt
The i.MX device tree changes for 4.4:
- Add IOMUXC LPSR (Low Power State Retention) device for i.MX7D.
- Add a few low power mode related devices and touch controller for
i.MX6UL.
- Add a number of devices for i.MX7D SDB board support, USB, Dual FEC,
and eMMC5.0.
- i.MX6 Boundary Devices updates: relicense under GPLv2/X11, add Okaya
LCD, touch and wifi support, add new boards Nitrogen6_Lite and
Nitrogen6_Max.
- Enable touch screen and NAND Flash controller for a few Vybrid
devices.
- Some random and small updates on LS1021A and MXS support.
* tag 'imx-dt-4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: (53 commits)
ARM: dts: ls1021a: Add quirk for Erratum A009116
ARM: imx6sx-sdb: Fix typo in regulator enable GPIO property
ARM: dts: imx6: phyFLEX: fix typo in "pinctrl-names"
ARM: dts: imx6: change the core clock of spdif
ARM: dts: vf-colibri: enable NAND flash controller
ARM: dts: vf610twr: add NAND flash controller peripherial
ARM: dts: imx: add Boundary Devices Nitrogen6_Lite board
ARM: dts: imx: add Boundary Devices Nitrogen6_Max board
ARM: dts: imx6dl-nitrogen6x: change manufacturer to Boundary Devices
ARM: dts: imx6q-nitrogen6x: change manufacturer to Boundary Devices
of: Add Boundary Devices Inc. vendor prefix
ARM: dts: imx6qdl-sabrelite: relicense under GPLv2/X11
ARM: dts: imx6qdl-nitrogen6x: relicense under GPLv2/X11
ARM: dts: imx6qdl-nitrogen6x: add wifi wl1271 support
ARM: dts: imx6dql-nitrogen6x: add touchscreen support
ARM: dts: imx6qdl-sabrelite: add Okaya LCD panel
ARM: dts: imx6qdl-nitrogen6x: add Okaya LCD panel
ARM: dts: vf500-colibri: Add device tree node for touchscreen support
ARM: dts: i.MX35: fix cpu compatible value
ARM: dts: i.MX31: fix cpu compatible value
...
Signed-off-by: Olof Johansson <olof@lixom.net>
This fixes the corner-case where the pmic is initialized by the bootloader, but
not the pmic watchdog.
Add support for active wakeup to the scpsys. This allows to keep the power of
a scpsys domain during suspend state.
With version v4.3 new subsystem clocks are added to the clock dirver. In late
init the kernel turns off all unused clocks. This can provoke a hang if
the kernel tries to access the venc and venc_lt power domain registers.
Add the necessary parent clocks for this power domains to
the scpsys so that no random hang happens.
The bootloader of mt6589, mt8135 and mt1827 does not turn on the arm-arch-timer.
As there is no opensource bootloader in the near future for this architectures
we enable the arch timer at kernel boot. We need the arch timer for SMP boot.
Add support for SMP on mt6589, mt8127 and mt8135.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWI4fcAAoJELQ5Ylss8dNDANYP/1hhCHTT3ssT0eURn+gGJX/e
f5J0dgX9KfJK7Ds0fznD6iMMHgp+EgK7WXI6vsO0VcbvokfS2KowS3NbeRKTnbTS
gmPOWvbFooHVIhzTom3serxyc9AgpnAG7WaRNxVD0CgaufeOlgbFtmOIdxze2cdE
S1ucq3JWJcpiCUaI3S9zRc3kkY9W/wpTEKNY98S4K3blKnWWT0sHSQxSGjoKy3wk
f1qhVjX82FeFizVSf5Ca6iqyXSFiO9gXQWvfVnS2kZE+gO/sh4df8tg8psxVqfqK
//3INxXhqkgkN4O3W+y3nUfSAQ5fElknnhiHaxAsl0PXFGMHROT3xtNR21syVkDh
dge/Eu34KyROPj68UbE2MnqnQbbSl2KbHsapT4ls8LiDWJPisjhhOmWL459eIS5X
+ycQniAxOpTgSIjYJnBwCBesru8OdfGNWRqm+SpGHyrClNtJt66/pK4AWEN2fgX4
eI8CeZ13uiuiQNmROOKRmTzSoG7ZBQMFK4g5Cy1Dl5bkGiJaednv6HnZoWqPZ4PG
isiOdsmiPsGB5GgvTpue996Nfc2kfHx2emr8+kxM8wejRWQJqmwLwTkX9bZ3dpFQ
7RGK46qN34tbJH/bgrck99Zgfg7OxChTQqVL0oTEjCCABK41clDFbguJiCV8SENw
uxtnI++cVFcUwxv7Qz0t
=iuHl
-----END PGP SIGNATURE-----
Merge tag 'v4.3-next-soc' of https://github.com/mbgg/linux-mediatek into next/soc
Do the initial setting of the pmic wrap interrupt before requesting the interrupt.
This fixes the corner-case where the pmic is initialized by the bootloader, but
not the pmic watchdog.
Add support for active wakeup to the scpsys. This allows to keep the power of
a scpsys domain during suspend state.
With version v4.3 new subsystem clocks are added to the clock dirver. In late
init the kernel turns off all unused clocks. This can provoke a hang if
the kernel tries to access the venc and venc_lt power domain registers.
Add the necessary parent clocks for this power domains to
the scpsys so that no random hang happens.
The bootloader of mt6589, mt8135 and mt1827 does not turn on the arm-arch-timer.
As there is no opensource bootloader in the near future for this architectures
we enable the arch timer at kernel boot. We need the arch timer for SMP boot.
Add support for SMP on mt6589, mt8127 and mt8135.
* tag 'v4.3-next-soc' of https://github.com/mbgg/linux-mediatek:
ARM: mediatek: add smp bringup code
ARM: mediatek: enable gpt6 on boot up to make arch timer working
soc: mediatek: Fix random hang up issue while kernel init
soc: mediatek: add scpsys support active_wakeup
soc: mediatek: Move the initial setting of pmic wrap interrupt before requesting irq.
Signed-off-by: Olof Johansson <olof@lixom.net>
Add support for the Allwinner R8 SoC used in the CHIP.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWInwoAAoJEBx+YmzsjxAgrsAQAIS7IN6NqaQRMv/H8pOGMqWH
tn2jCqQBavzIRJ8WK/ny+umkM1t7WC9kNVvU/hMO3LoFhjXRXDWZSBaIQv4dnGFM
o7Iw09A9pci4VDvUqnyUiLcYq2azhdKbjMSwVsWx92zWx3j2L+iG6d3FJrDDyNBT
eXDjsvuhQVxE653a9hon1aFFH28wbJhPvpzf31m0J96o4fmizvmyZvIB2cc8BBmy
qLnbhxCkG2FxDkM8vAXfpDF7ypDEzn/rG3/mHXX+tjDY3Fk+53WzAfIqBhnSPJzN
Zrv2ffn2K/n28rjUMSfSkThKGMTWriyKgNy+OosDrEUpX/FsU55BX5oNSDlDS9N5
0cK4dmHUwf1YIes5dum5XoeJd9Tq3vyJUsD7/+OhuMLTSyGxmjAZD6tu3ldmZ9pC
7Fwa8ZTr2YagmNwXdvxq6DbcLTEuNZH+7ztr/prhBn5DQfvPWTX+r4cKYjG9SApX
XVJ5UZb+zkTVPAUSVKJOdiiKmuiibkNAL4isMPj3KKqYIXdsMysgVmsDyr3b00B1
0K5zrDU0mjZHohfNJ3ppjilcLtq/iimH3UAgGa77vGYF3BPosf8kq96BbqL+s5Hx
CMbnA4FRpFdSvWXi1qiPwnN9BzU82OPVRti4o6OdY8BJlSg0dTp7ngnuIrz7HT5/
UWtveTP1w/ePlnlaY4NE
=o6P8
-----END PGP SIGNATURE-----
Merge tag 'sunxi-core-for-4.4' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into next/soc
Allwinner core changes for 4.4
Add support for the Allwinner R8 SoC used in the CHIP.
* tag 'sunxi-core-for-4.4' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux:
ARM: sunxi: Add R8 support
Signed-off-by: Olof Johansson <olof@lixom.net>
Rockchip Kconfig options, fixing a possible null-pointer and a
typo in the dt-bindings.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABCAAGBQJWIlknAAoJEPOmecmc0R2BrTkH/3w+1ZZuvtfQmzBkPwJGJ9vJ
zZFZLZqD0NADib8sOhFnJxTfxrhoE/Bfijqk4wPfjdKta2GABfljGbLDanQB8Yr9
Ip+fyflQ6cd925dEuPccHMbumZep+QuSIGYjOGFIuRbbjCdOY5MB+I2Yhvognwus
Xh4FtjS7CL6ruotmyOcMtnpNDCAvc8NSwO7xBqxYRPcgd+DY8+86cD/dUpvmD4Kr
pGtUXkfQpAjBhV9P6RuP63gO42JD1VMb7c6idd+B/tzbJxI08CTDolwqvyujVkHf
KeRvu7g8qKKUwL5ffOImR4tR/T2o1wDLwfxuUJXW+mIVJa72qA+h90aNOhM2iC8=
=Qk94
-----END PGP SIGNATURE-----
Merge tag 'v4.4-rockchip-drivers2' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into next/drivers
Some fixes for the new power-domain driver, including restricting
Rockchip Kconfig options, fixing a possible null-pointer and a
typo in the dt-bindings.
* tag 'v4.4-rockchip-drivers2' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
dt-bindings: Correct paths in Rockchip power domains binding document
soc: rockchip: power-domain: don't try to print the clock name in error case
soc: rockchip: Restrict to ARCH_ROCKCHIP
Signed-off-by: Olof Johansson <olof@lixom.net>
The PSCI specifications [1] and the SMC calling convention mandate
that unimplemented functions ids must return NOT_SUPPORTED (0xffffffff)
if a function id is called but it is not implemented.
Consequently, PSCI 1.0 function ids that require the 1.0 PSCI_FEATURES
call to be initialized:
CPU_SUSPEND (psci_init_cpu_suspend())
SYSTEM_SUSPEND (psci_init_system_suspend())
call the PSCI_FEATURES function id independently of the detected
PSCI firmware version, since, if the PSCI_FEATURES function id is not
implemented, it must return NOT_SUPPORTED according to the PSCI
specifications, causing the initialization functions to fail as expected.
Some existing PSCI implementations (ie Qemu PSCI emulation), do not
comply with the SMC calling convention and fail if function ids that are
not implemented are called from the OS, causing boot failures.
To solve this issue, this patch adds code that checks the PSCI firmware
version before calling PSCI 1.0 initialization functions so that the
OS makes sure that it is calling 1.0 functions only if the firmware
version detected is 1.0 or greater, therefore avoiding PSCI calls
that are bound to fail and might cause system boot failures owing
to non-compliant PSCI firmware implementations.
[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Rutland <mark.rutland@arm.com>
Tested-by: Kevin Hilman <khilman@kernel.org>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Taking the grph update lock is only necessary when
updating the the secondary address (for single pipe stereo).
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Taking the grph update lock is only necessary when
updating the the secondary address (for single pipe stereo).
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Taking the grph update lock is only necessary when
updating the the secondary address (for single pipe stereo).
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Mapping an image with a long parent chain (e.g. image foo, whose parent
is bar, whose parent is baz, etc) currently leads to a kernel stack
overflow, due to the following recursion in the reply path:
rbd_osd_req_callback()
rbd_obj_request_complete()
rbd_img_obj_callback()
rbd_img_parent_read_callback()
rbd_obj_request_complete()
...
Limit the parent chain to 16 images, which is ~5K worth of stack. When
the above recursion is eliminated, this limit can be lifted.
Fixes: http://tracker.ceph.com/issues/12538
Cc: stable@vger.kernel.org # 3.10+, needs backporting for < 4.2
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: Josh Durgin <jdurgin@redhat.com>
Currently we leak parent_spec and trigger a "parent reference
underflow" warning if rbd_dev_create() in rbd_dev_probe_parent() fails.
The problem is we take the !parent out_err branch and that only drops
refcounts; parent_spec that would've been freed had we called
rbd_dev_unparent() remains and triggers rbd_warn() in
rbd_dev_parent_put() - at that point we have parent_spec != NULL and
parent_ref == 0, so counter ends up being -1 after the decrement.
Redo rbd_dev_probe_parent() to fix this.
Cc: stable@vger.kernel.org # 3.10+, needs backporting for < 4.2
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: Alex Elder <elder@linaro.org>
When building docs with make htmldocs, warnings about not having
a description for the return value are reported, i.e:
warning: No description found for return value of 'spi_register_driver'
Fix these by following the kernel-doc conventions explained in
Documentation/kernel-doc-nano-HOWTO.txt.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Jeff Kirsher says:
====================
Intel Wired LAN Driver Updates 2015-10-23
This series contains updates to i40e, i40evf, if_link, ixgbe and ixgbevf.
Anjali adds a workaround to drop any flow control frames from being
transmitted from any VSI, so that a malicious VF cannot send flow control
or PFC packets out on the wire. Also fixed a bug in debugfs by grabbing
the filter list lock before adding or deleting a filter.
Akeem fixes an issue where we were unconditionally returning VEB bridge
mode before allowing LB in the add VSI routine, resolve by checking if
the bridge is actually in VEB mode first.
Mitch fixed an issue where the incorrect structure was being used for
VLAN filter list, which meant the VLAN filter list did not get
processed correctly and VLAN filters would not be re-enabled after any
kind of reset.
Helin fixed a problem of possibly getting inconsistent flow control
status after a PF reset. The issue was requested_mode was being set
with a default value during probe, but the hardware state could be a
different value from this mode.
Carolyn fixed a problem where the driver output of the OEM version
string varied from the other tools.
Jean Sacren fixes up kernel documentation by fixing function header
comments to match actual variables used in the functions. Also
cleaned up variable initialization, when the variable would be
over-written immediately.
Hiroshi Shimanoto provides three patches to add "trusted" VF by adding
netlink directives and an NDO entry. Then implement these new controls
in ixgbe and ixgbevf. This series has gone through several iterations
to address all the suggested community changes and concerns.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
When offlining a cpu, instead of cpu_down, call device_offline, which
also takes care of updating the cpu.dev.offline field. This keeps the
sysfs file /sys/devices/system/cpu/cpuN/online, up to date. Also move
the call to disable_hotplug_cpu, because it makes more sense to have it
there.
We don't call device_online at cpu-hotplug time, because that would
immediately take the cpu online, while we want to retain the current
behaviour: the user needs to explicitly enable the cpu after it has
been hotplugged.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
CC: konrad.wilk@oracle.com
CC: boris.ostrovsky@oracle.com
CC: david.vrabel@citrix.com
Build cpu_hotplug for ARM and ARM64 guests.
Rename arch_(un)register_cpu to xen_(un)register_cpu and provide an
empty implementation on ARM and ARM64. On x86 just call
arch_(un)register_cpu as we are already doing.
Initialize cpu_hotplug on ARM.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
The PV ring may use multiple grants and expect them to be mapped
contiguously in the virtual memory.
Although, the current code is relying on a Linux page will be mapped to
a single grant. On build where Linux is using a different page size than
the grant (i.e other than 4KB), the grant will always be mapped on the
first 4KB of each Linux page which make the final ring not contiguous in
the memory.
This can be fixed by mapping multiple grant in a same Linux page.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
With the 64KB page granularity support on ARM64, a Linux page may be
split accross multiple grant.
Currently we have the helper gnttab_foreach_grant_in_grant to break a
Linux page based on an offset and a len, but it doesn't fit when we only
have a number of grants in hand.
Introduce a new helper which take an array of Linux page and a number of
grant and will figure out the address of each grant.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Linux may use a different page size than the size of grant. So make
clear that the order is actually in number of grant.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
The type of the item in frame_list is xen_pfn_t which is not an unsigned
long on ARM but an uint64_t.
With the current computation, the size of frame_list will be 2 *
PAGE_SIZE rather than PAGE_SIZE.
I bet it's just mistake when the type has been switched from "unsigned
long" to "xen_pfn_t" in commit 965c0aaafe
"xen: balloon: use correct type for frame_list".
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Swiotlb is used on ARM64 to support DMA on platform where devices are
not protected by an SMMU. Furthermore it's only enabled for DOM0.
While Xen is always using 4KB page granularity in the stage-2 page table,
Linux ARM64 may either use 4KB or 64KB. This means that a Linux page
can be spanned accross multiple Xen page.
The Swiotlb code has to validate that the buffer used for DMA is
physically contiguous in the memory. As a Linux page can't be shared
between local memory and foreign page by design (the balloon code always
removing entirely a Linux page), the changes in the code are very
minimal because we only need to check the first Xen PFN.
Note that it may be possible to optimize the function
check_page_physically_contiguous to avoid looping over every Xen PFN
for local memory. Although I will let this optimization for a follow-up.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
With 64KB page granularity support, the frame number will be different.
It will be easier to modify the behavior in a single place rather than
in each caller.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
The hypercall interface (as well as the toolstack) is always using 4KB
page granularity. When the toolstack is asking for mapping a series of
guest PFN in a batch, it expects to have the page map contiguously in
its virtual memory.
When Linux is using 64KB page granularity, the privcmd driver will have
to map multiple Xen PFN in a single Linux page.
Note that this solution works on page granularity which is a multiple of
4KB.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
The PV network protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity working as a
network backend on a non-modified Xen.
It's only necessary to adapt the ring size and break skb data in small
chunk of 4KB. The rest of the code is relying on the grant table code.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
The PV network protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity using network
device on a non-modified Xen.
It's only necessary to adapt the ring size and break skb data in small
chunk of 4KB. The rest of the code is relying on the grant table code.
Note that we allocate a Linux page for each rx skb but only the first
4KB is used. We may improve the memory usage by extending the size of
the rx skb.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
The PV block protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity behaving as a
block backend on a non-modified Xen.
It's only necessary to adapt the ring size and the number of request per
indirect frames. The rest of the code is relying on the grant table
code.
Note that the grant table code is allocating a Linux page per grant
which will result to waste 6OKB for every grant when Linux is using 64KB
page granularity. This could be improved by sharing the page between
multiple grants.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: "Roger Pau Monné" <roger.pau@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
The PV block protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity using block
device on a non-modified Xen.
The block API is using segment which should at least be the size of a
Linux page. Therefore, the driver will have to break the page in chunk
of 4K before giving the page to the backend.
When breaking a 64KB segment in 4KB chunks, it is possible that some
chunks are empty. As the PV protocol always require to have data in the
chunk, we have to count the number of Xen page which will be in use and
avoid sending empty chunks.
Note that, a pre-defined number of grants are reserved before preparing
the request. This pre-defined number is based on the number and the
maximum size of the segments. If each segment contains a very small
amount of data, the driver may reserve too many grants (16 grants is
reserved per segment with 64KB page granularity).
Furthermore, in the case of persistent grants we allocate one Linux page
per grant although only the first 4KB of the page will be effectively
in use. This could be improved by sharing the page with multiple grants.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
The Xen interface is using 4KB page granularity. This means that each
grant is 4KB.
The current implementation allocates a Linux page per grant. On Linux
using 64KB page granularity, only the first 4KB of the page will be
used.
We could decrease the memory wasted by sharing the page with multiple
grant. It will require some care with the {Set,Clear}ForeignPage macro.
Note that no changes has been made in the x86 code because both Linux
and Xen will only use 4KB page granularity.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Only use the first 4KB of the page to store the events channel info. It
means that we will waste 60KB every time we allocate page for:
* control block: a page is allocating per CPU
* event array: a page is allocating everytime we need to expand it
I think we can reduce the memory waste for the 2 areas by:
* control block: sharing between multiple vCPUs. Although it will
require some bookkeeping in order to not free the page when the CPU
goes offline and the other CPUs sharing the page still there
* event array: always extend the array event by 64K (i.e 16 4K
chunk). That would require more care when we fail to expand the
event channel.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
For ARM64 guests, Linux is able to support either 64K or 4K page
granularity. Although, the hypercall interface is always based on 4K
page granularity.
With 64K page granularity, a single page will be spread over multiple
Xen frame.
To avoid splitting the page into 4K frame, take advantage of the
extent_order field to directly allocate/free chunk of the Linux page
size.
Note that PVMMU is only used for PV guest (which is x86) and the page
granularity is always 4KB. Some BUILD_BUG_ON has been added to ensure
that because the code has not been modified.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
The console ring is always based on the page granularity of Xen.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
All the ring (xenstore, and PV rings) are always based on the page
granularity of Xen.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
On ARM all dma-capable devices on a same platform may not be protected
by an IOMMU. The DMA requests have to use the BFN (i.e MFN on ARM) in
order to use correctly the device.
While the DOM0 memory is allocated in a 1:1 fashion (PFN == MFN), grant
mapping will screw this contiguous mapping.
When Linux is using 64KB page granularitary, the page may be split
accross multiple non-contiguous MFN (Xen is using 4KB page
granularity). Therefore a DMA request will likely fail.
Checking that a 64KB page is using contiguous MFN is tedious. For
now, always says that biovec are not mergeable.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Prepare the code to support 64KB page granularity. The first
implementation will use a full Linux page per indirect and persistent
grant. When non-persistent grant is used, each page of a bio request
may be split in multiple grant.
Furthermore, the field page of the grant structure is only used to copy
data from persistent grant or indirect grant. Avoid to set it for other
use case as it will have no meaning given the page will be split in
multiple grant.
Provide 2 functions, to setup indirect grant, the other for bio page.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
All the usage of the field pfn are done using the same idiom:
pfn_to_page(grant->pfn)
This will return always the same page. Store directly the page in the
grant to clean up the code.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Currently, blkif_queue_request has 2 distinct execution path:
- Send a discard request
- Send a read/write request
The function is also allocating grants to use for generating the
request. Although, this is only used for read/write request.
Rather than having a function with 2 distinct execution path, separate
the function in 2. This will also remove one level of tabulation.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Currently, a grant is always based on the Xen page granularity (i.e
4KB). When Linux is using a different page granularity, a single page
will be split between multiple grants.
The new helpers will be in charge of splitting the Linux page into grants
and call a function given by the caller on each grant.
Also provide an helper to count the number of grants within a given
contiguous region.
Note that the x86/include/asm/xen/page.h is now including
xen/interface/grant_table.h rather than xen/grant_table.h. It's
necessary because xen/grant_table.h depends on asm/xen/page.h and will
break the compilation. Furthermore, only definition in
interface/grant_table.h is required.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
The skb doesn't change within the function. Therefore it's only
necessary to check if we need GSO once at the beginning.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
