As of now, in tce_freemulti_pSeriesLP(), there is no limit on how many TCEs
are passed to H_STUFF_TCE hcall. This was not an issue until now. Newer
firmware releases have started enforcing this requirement.
The interface has been in it's current form since the beginning.
Cc: stable(a)vger.kernel.org
Signed-off-by: Gaurav Batra <gbatra(a)linux.vnet.ibm.com>
Reviewed-by: Brian King <brking(a)linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/iommu.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
index c74b71d4733d..f159a195101d 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -306,13 +306,22 @@ static void tce_free_pSeriesLP(unsigned long liobn, long tcenum, long tceshift,
static void tce_freemulti_pSeriesLP(struct iommu_table *tbl, long tcenum, long npages)
{
u64 rc;
+ long rpages = npages;
+ unsigned long limit;
if (!firmware_has_feature(FW_FEATURE_STUFF_TCE))
return tce_free_pSeriesLP(tbl->it_index, tcenum,
tbl->it_page_shift, npages);
- rc = plpar_tce_stuff((u64)tbl->it_index,
- (u64)tcenum << tbl->it_page_shift, 0, npages);
+ do {
+ limit = min_t(unsigned long, rpages, 512);
+
+ rc = plpar_tce_stuff((u64)tbl->it_index,
+ (u64)tcenum << tbl->it_page_shift, 0, limit);
+
+ rpages -= limit;
+ tcenum += limit;
+ } while (rpages > 0 && !rc);
if (rc && printk_ratelimit()) {
printk("tce_freemulti_pSeriesLP: plpar_tce_stuff failed\n");
--
2.39.2 (Apple Git-143)
This is an automatic generated email to let you know that the following patch were queued:
Subject: media: uapi: Fix [GS]_ROUTING ACTIVE flag value
Author: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Date: Mon Apr 24 15:22:37 2023 +0300
The value of the V4L2_SUBDEV_ROUTE_FL_ACTIVE is 1, not 0. Use hexadecimal
numbers as is done elsewhere in the documentation.
Cc: stable(a)vger.kernel.org # for >= v6.3
Fixes: ea73eda50813 ("media: Documentation: Add GS_ROUTING documentation")
Signed-off-by: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi(a)ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl>
Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
diff --git a/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst b/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst
index 68ca343c3b44..2d6e3bbdd040 100644
--- a/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst
+++ b/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst
@@ -122,7 +122,7 @@ for all the route entries and call ``VIDIOC_SUBDEV_G_ROUTING`` again.
:widths: 3 1 4
* - V4L2_SUBDEV_ROUTE_FL_ACTIVE
- - 0
+ - 0x0001
- The route is enabled. Set by applications.
Return Value
Hi,
I notice a regression report on Bugzilla [1]. Quoting from it:
> Original Summary:
> absent both plymouth, and video= on linu lines, vtty[1-6] framebuffers produce vast raster right and bottom borders on the larger resolution of two displays
>
> To reproduce:
> 1-connect two unequal native resolution displays to a Tesla or Firmi GPU
> 2-don't have plymouth in use (I don't ever have it installed, so don't know whether it impacts)
> 3-don't include e.g. video=1440x900@60 directive on Grub's linu lines
> 4-boot Tumbleweed or Fedora 38
> 5-switch to a vtty, e.g. Ctrl-Alt-F3
>
> Actual behavior:
> 1-Both displays utilize the resolution (same pixel grid) of the lower resolution display
> 2-Lower resolution display behaves as expected (light text on black background)
> 3-Higher resolution display uses same pixels as lower resolution display, with light text on black background, leaving right side and bottom raster instead of black
>
> Expected behavior:
> 1-Both displays utilize the resolution (same pixel grid) of the lower resolution display
> 2-Lower resolution display behaves as expected
> 3-Entire higher resolution display's background is black instead of portions in raster
>
> Workaround: add e.g. video=1440x900@60 to Grub's linu lines, which causes both displays to use the same nominal mode on the full display space.
>
> Typical other linu line options:
> noresume consoleblank=0 net.ifnames=0 ipv6.disable=1 preempt=full mitigations=none
>
> My Tesla has HDMI and DVI outputs, tested with 1920x1200 and 1680x1050 displays.
> My Fermi has dual DisplayPort, tested with 2560x1440 and 1680x1050 displays.
> Occurs Tumbleweed with 6.3.2 and 6.2.12 kernel-default, and with 6.2.15 on Fedora 38, and (partially with Tesla, right side only) with 6.2.12 and 6.3.3 on Mageia 9.
> Does not occur with 6.1.12 kernel-default on NVidia, or with AMD Caicos (Terascale2) GPU, or with Intel Eaglelake GPU.
> Tested only on legacy booting (no UEFI support).
> Others might describe what I call "raster" as multicolored snow.
See bugzilla for the full thread and attached dmesg.
Anyway, I'm adding it to regzbot:
#regzbot introduced: v6.1.12..v6.2.12
#regzbot title: vast raster right and bottom borders on larger display (two displays with inequal resolution) unless forcing resolution with video= parameter
Thanks.
--
An old man doll... just what I always wanted! - Clara
Hi,
I notice a regression report on Bugzilla [1]. Quoting from it:
> Linux kernel >= v6.2 no longer boots on Apple's Virtualization.framework (x86_64).
>
> It is reported that the issue is not reproducible on ARM64: https://github.com/lima-vm/lima/issues/1577#issuecomment-1561577694
>
>
> ## Reproduction
> - Checkout the kernel repo, and run `make defconfig bzImage`.
>
> - Create an initrd (see the attached `initrd-example.txt`)
>
> - Transfer the bzImage and initrd to an Intel Mac.
>
> - On Mac, download `RunningLinuxInAVirtualMachine.zip` from https://developer.apple.com/documentation/virtualization/running_linux_in_a… , and build the `LinuxVirtualMachine` binary with Xcode.
> Building this binary with Xcode requires logging in to Apple.
> If you do not like logging in, a third party equivalent such as https://github.com/Code-Hex/vz/blob/v3.0.6/example/linux/main.go can be used.
>
> - Run `LinuxVirtualMachine /tmp/bzImage /tmp/initrd.img`.
> v6.1 successfully boots into the busybox shell.
> v6.2 just hangs before printing something in the console.
>
>
> ## Tested versions
> ```
> v6.1: OK
> ...
> v6.1.0-rc2-00002-g60f2096b59bc (included in v6.2-rc1): OK
> v6.1.0-rc2-00003-g5c62d5aab875 (included in v6.2-rc1): NG <-- This commit caused a regression
> ...
> v6.2-rc1: NG
> ...
> v6.2: NG
> ...
> v6.3.0-rc7-00181-g8e41e0a57566 (included in v6.3): NG <-- Reverts 5c62d5aab875 but still NG
> ...
> v6.3: NG
> v6.4-rc3: NG
> ```
>
> Tested on MacBookPro 2020 (Intel(R) Core(TM) i7-1068NG7 CPU @ 2.30GHz) running macOS 13.4.
>
>
> The issue seems a regression in [5c62d5aab8752e5ee7bfbe75ed6060db1c787f98](https://git.kernel.org/pub/scm/li… "ACPICA: Events: Support fixed PCIe wake event".
>
> This commit was introduced in v6.2-rc1, and apparently reverted in v6.3 ([8e41e0a575664d26bb87e012c39435c4c3914ed9](https://git.kernel.org/pub/scm/li…).
> However, v6.3 and the latest v6.4-rc3 still don't boot.
See bugzilla for the full thread.
Interestingly, this regression still occurs despite the culprit is
reverted in 8e41e0a575664d ("Revert "ACPICA: Events: Support fixed
PCIe wake event""), so this (obviously) isn't wake-on-lan regression,
but rather early boot one.
Also, the reporter can't provide dmesg log (forget to attach serial
console?).
Anyway, I'm adding it to regzbot:
#regzbot introduced: 5c62d5aab8752e https://bugzilla.kernel.org/show_bug.cgi?id=217485
#regzbot title: Linux v6.2+ (x86_64) no longer boots on Apple's Virtualization framework (ACPICA issue)
Thanks.
[1]: https://bugzilla.kernel.org/show_bug.cgi?id=217485
--
An old man doll... just what I always wanted! - Clara
This is an automatic generated email to let you know that the following patch were queued:
Subject: media: uapi: Fix [GS]_ROUTING ACTIVE flag value
Author: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Date: Mon Apr 24 15:22:37 2023 +0300
The value of the V4L2_SUBDEV_ROUTE_FL_ACTIVE is 1, not 0. Use hexadecimal
numbers as is done elsewhere in the documentation.
Cc: stable(a)vger.kernel.org # for >= v6.3
Fixes: ea73eda50813 ("media: Documentation: Add GS_ROUTING documentation")
Signed-off-by: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi(a)ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl>
Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
diff --git a/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst b/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst
index 68ca343c3b44..2d6e3bbdd040 100644
--- a/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst
+++ b/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst
@@ -122,7 +122,7 @@ for all the route entries and call ``VIDIOC_SUBDEV_G_ROUTING`` again.
:widths: 3 1 4
* - V4L2_SUBDEV_ROUTE_FL_ACTIVE
- - 0
+ - 0x0001
- The route is enabled. Set by applications.
Return Value