[Bug 2065838] Re: System crash on resume from sleep

[Mario Limonciello]

Yes since you didn't clone using git you can't use git revert.

Once you can successfully build and test that kernel I'll post you a
revert patch' with explanation how to use it.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2065838

Title:
  System crash on resume from sleep

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2065838/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2065838] Re: System crash on resume from sleep

[Mario Limonciello]

Yeah I know they're different symptoms but the reason for that revert might 
have a similar root cause.
I'm saying this because I've got a different system that fails to boot up that 
reverting that helps.

In terms of specific instructions, I'd start with this:

https://itsfoss.com/compile-linux-kernel/

Once you can get that compiling on your own I can help you with a
applying a revert patch to see if it helps.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2065838

Title:
  System crash on resume from sleep

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2065838/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[PATCH 2/2] tests/amdgpu/amd_abm: Add support for panel_power_saving property

[Mario Limonciello]

From: Mario Limonciello 

When the "panel power saving" property is set to forbidden the
compositor has indicated that userspace prefers to have color
accuracy and fidelity instead of power saving.

Verify that the sysfs file behaves as expected in this situation.

Signed-off-by: Mario Limonciello 
---
 tests/amdgpu/amd_abm.c | 65 ++
 1 file changed, 65 insertions(+)

diff --git a/tests/amdgpu/amd_abm.c b/tests/amdgpu/amd_abm.c
index f74c3012c..971cda153 100644
--- a/tests/amdgpu/amd_abm.c
+++ b/tests/amdgpu/amd_abm.c
@@ -104,6 +104,32 @@ static int backlight_write_brightness(int value)
return 0;
 }
 
+static int toggle_panel_power_saving_prop(data_t *data, igt_output_t *output, 
bool forbid)
+{
+   uint32_t type = DRM_MODE_OBJECT_CONNECTOR;
+   bool prop_exists;
+   uint32_t prop_id;
+
+   prop_exists = kmstest_get_property(
+   data->drm_fd, output->id, type, "panel power saving",
+   _id, NULL, NULL);
+
+   if (!prop_exists)
+   return -ENODEV;
+
+   return drmModeObjectSetProperty(data->drm_fd, output->id, type, 
prop_id, forbid);
+}
+
+static int allow_panel_power_saving(data_t *data, igt_output_t *output)
+{
+   return toggle_panel_power_saving_prop(data, output, false);
+}
+
+static int forbid_panel_power_saving(data_t *data, igt_output_t *output)
+{
+   return toggle_panel_power_saving_prop(data, output, true);
+}
+
 static int set_abm_level(data_t *data, igt_output_t *output, int level)
 {
char buf[PATH_MAX];
@@ -365,6 +391,43 @@ static void abm_gradual(data_t *data)
}
 }
 
+
+static void abm_forbidden(data_t *data)
+{
+   igt_output_t *output;
+   enum pipe pipe;
+   int target, r;
+
+   for_each_pipe_with_valid_output(>display, pipe, output) {
+   if (output->config.connector->connector_type != 
DRM_MODE_CONNECTOR_eDP)
+   continue;
+
+   r = allow_panel_power_saving(data, output);
+   if (r == -ENODEV) {
+   igt_skip("No panel power saving prop\n");
+   return;
+   }
+   igt_assert_eq(r, 0);
+
+   target = 3;
+   r = set_abm_level(data, output, target);
+   igt_assert_eq(r, 0);
+
+   r = forbid_panel_power_saving(data, output);
+   igt_assert_eq(r, 0);
+
+   target = 0;
+   r = set_abm_level(data, output, target);
+   igt_assert_eq(r, -1);
+
+   r = allow_panel_power_saving(data, output);
+   igt_assert_eq(r, 0);
+
+   r = set_abm_level(data, output, target);
+   igt_assert_eq(r, 0);
+   }
+}
+
 igt_main
 {
data_t data = {};
@@ -393,6 +456,8 @@ igt_main
abm_enabled();
igt_subtest("abm_gradual")
abm_gradual();
+   igt_subtest("abm_forbidden")
+   abm_forbidden();
 
igt_fixture {
igt_display_fini();
-- 
2.45.0

[PATCH 2/2] tests/amdgpu/amd_abm: Add support for panel_power_saving property

[Mario Limonciello]

From: Mario Limonciello 

When the "panel power saving" property is set to forbidden the
compositor has indicated that userspace prefers to have color
accuracy and fidelity instead of power saving.

Verify that the sysfs file behaves as expected in this situation.

Signed-off-by: Mario Limonciello 
---
 tests/amdgpu/amd_abm.c | 65 ++
 1 file changed, 65 insertions(+)

diff --git a/tests/amdgpu/amd_abm.c b/tests/amdgpu/amd_abm.c
index f74c3012c..971cda153 100644
--- a/tests/amdgpu/amd_abm.c
+++ b/tests/amdgpu/amd_abm.c
@@ -104,6 +104,32 @@ static int backlight_write_brightness(int value)
return 0;
 }
 
+static int toggle_panel_power_saving_prop(data_t *data, igt_output_t *output, 
bool forbid)
+{
+   uint32_t type = DRM_MODE_OBJECT_CONNECTOR;
+   bool prop_exists;
+   uint32_t prop_id;
+
+   prop_exists = kmstest_get_property(
+   data->drm_fd, output->id, type, "panel power saving",
+   _id, NULL, NULL);
+
+   if (!prop_exists)
+   return -ENODEV;
+
+   return drmModeObjectSetProperty(data->drm_fd, output->id, type, 
prop_id, forbid);
+}
+
+static int allow_panel_power_saving(data_t *data, igt_output_t *output)
+{
+   return toggle_panel_power_saving_prop(data, output, false);
+}
+
+static int forbid_panel_power_saving(data_t *data, igt_output_t *output)
+{
+   return toggle_panel_power_saving_prop(data, output, true);
+}
+
 static int set_abm_level(data_t *data, igt_output_t *output, int level)
 {
char buf[PATH_MAX];
@@ -365,6 +391,43 @@ static void abm_gradual(data_t *data)
}
 }
 
+
+static void abm_forbidden(data_t *data)
+{
+   igt_output_t *output;
+   enum pipe pipe;
+   int target, r;
+
+   for_each_pipe_with_valid_output(>display, pipe, output) {
+   if (output->config.connector->connector_type != 
DRM_MODE_CONNECTOR_eDP)
+   continue;
+
+   r = allow_panel_power_saving(data, output);
+   if (r == -ENODEV) {
+   igt_skip("No panel power saving prop\n");
+   return;
+   }
+   igt_assert_eq(r, 0);
+
+   target = 3;
+   r = set_abm_level(data, output, target);
+   igt_assert_eq(r, 0);
+
+   r = forbid_panel_power_saving(data, output);
+   igt_assert_eq(r, 0);
+
+   target = 0;
+   r = set_abm_level(data, output, target);
+   igt_assert_eq(r, -1);
+
+   r = allow_panel_power_saving(data, output);
+   igt_assert_eq(r, 0);
+
+   r = set_abm_level(data, output, target);
+   igt_assert_eq(r, 0);
+   }
+}
+
 igt_main
 {
data_t data = {};
@@ -393,6 +456,8 @@ igt_main
abm_enabled();
igt_subtest("abm_gradual")
abm_gradual();
+   igt_subtest("abm_forbidden")
+   abm_forbidden();
 
igt_fixture {
igt_display_fini();
-- 
2.45.0

[PATCH 0/2] Add support for testing panel power saving DRM property

[Mario Limonciello]

During the Display Next hackfest 2024 one of the topics discussed
was the need for compositor to be able to relay intention to drivers
that color fidelity is preferred over power savings.

To accomplish this a new optional DRM property is being introduced called
"panel power saving".  This property is an enum that can be configured
by the compositor to "Allowed" or "Forbidden".

When a driver advertises support for this property and the compositor
sets it to "Forbidden" then the driver will disable any power saving
features that can compromise color fidelity.

This set of IGT changes introduces a new subtest that will cover the
expected kernel behavior when switching between Allowed and Forbidden.

Mario Limonciello (2):
  tests/amdgpu/amd_abm: Make set_abm_level return type int
  tests/amdgpu/amd_abm: Add support for panel_power_saving property

 tests/amdgpu/amd_abm.c | 98 +-
 1 file changed, 88 insertions(+), 10 deletions(-)

-- 
2.45.0

[PATCH 0/2] Add support for testing panel power saving DRM property

[Mario Limonciello]

During the Display Next hackfest 2024 one of the topics discussed
was the need for compositor to be able to relay intention to drivers
that color fidelity is preferred over power savings.

To accomplish this a new optional DRM property is being introduced called
"panel power saving".  This property is an enum that can be configured
by the compositor to "Allowed" or "Forbidden".

When a driver advertises support for this property and the compositor
sets it to "Forbidden" then the driver will disable any power saving
features that can compromise color fidelity.

This set of IGT changes introduces a new subtest that will cover the
expected kernel behavior when switching between Allowed and Forbidden.

Mario Limonciello (2):
  tests/amdgpu/amd_abm: Make set_abm_level return type int
  tests/amdgpu/amd_abm: Add support for panel_power_saving property

 tests/amdgpu/amd_abm.c | 98 +-
 1 file changed, 88 insertions(+), 10 deletions(-)

-- 
2.45.0

[PATCH 1/2] tests/amdgpu/amd_abm: Make set_abm_level return type int

[Mario Limonciello]

From: Mario Limonciello 

In order to bubble of cases of expeted errors on set_abm_level()
change the return type to int.

Signed-off-by: Mario Limonciello 
---
 tests/amdgpu/amd_abm.c | 33 +++--
 1 file changed, 23 insertions(+), 10 deletions(-)

diff --git a/tests/amdgpu/amd_abm.c b/tests/amdgpu/amd_abm.c
index 2882c2c18..f74c3012c 100644
--- a/tests/amdgpu/amd_abm.c
+++ b/tests/amdgpu/amd_abm.c
@@ -104,10 +104,11 @@ static int backlight_write_brightness(int value)
return 0;
 }
 
-static void set_abm_level(data_t *data, igt_output_t *output, int level)
+static int set_abm_level(data_t *data, igt_output_t *output, int level)
 {
char buf[PATH_MAX];
int fd;
+   int ret;
 
igt_assert(snprintf(buf, PATH_MAX, PANEL_POWER_SAVINGS_PATH,
output->name) < PATH_MAX);
@@ -116,8 +117,12 @@ static void set_abm_level(data_t *data, igt_output_t 
*output, int level)
 
igt_assert(fd != -1);
 
-   igt_assert_eq(snprintf(buf, sizeof(buf), "%d", level),
- write(fd, buf, 1));
+   snprintf(buf, sizeof(buf), "%d", level);
+   ret = write(fd, buf, 1);
+   if (ret < 0) {
+   close(fd);
+   return ret;
+   }
 
igt_assert_eq(close(fd), 0);
 
@@ -129,6 +134,7 @@ static void set_abm_level(data_t *data, igt_output_t 
*output, int level)
 DRM_MODE_DPMS_OFF);
kmstest_set_connector_dpms(data->drm_fd, output->config.connector,
 DRM_MODE_DPMS_ON);
+   return 0;
 }
 
 static int backlight_read_max_brightness(int *result)
@@ -192,7 +198,8 @@ static void backlight_dpms_cycle(data_t *data)
ret = backlight_read_max_brightness(_brightness);
igt_assert_eq(ret, 0);
 
-   set_abm_level(data, output, 0);
+   ret = set_abm_level(data, output, 0);
+   igt_assert_eq(ret, 0);
backlight_write_brightness(max_brightness / 2);
usleep(10);
pwm_1 = read_target_backlight_pwm(data->drm_fd, output->name);
@@ -223,7 +230,8 @@ static void backlight_monotonic_basic(data_t *data)
 
brightness_step = max_brightness / 10;
 
-   set_abm_level(data, output, 0);
+   ret = set_abm_level(data, output, 0);
+   igt_assert_eq(ret, 0);
backlight_write_brightness(max_brightness);
usleep(10);
prev_pwm = read_target_backlight_pwm(data->drm_fd, 
output->name);
@@ -257,7 +265,8 @@ static void backlight_monotonic_abm(data_t *data)
 
brightness_step = max_brightness / 10;
for (i = 1; i < 5; i++) {
-   set_abm_level(data, output, 0);
+   ret = set_abm_level(data, output, 0);
+   igt_assert_eq(ret, 0);
backlight_write_brightness(max_brightness);
usleep(10);
prev_pwm = read_target_backlight_pwm(data->drm_fd, 
output->name);
@@ -289,14 +298,16 @@ static void abm_enabled(data_t *data)
ret = backlight_read_max_brightness(_brightness);
igt_assert_eq(ret, 0);
 
-   set_abm_level(data, output, 0);
+   ret = set_abm_level(data, output, 0);
+   igt_assert_eq(ret, 0);
backlight_write_brightness(max_brightness);
usleep(10);
prev_pwm = read_target_backlight_pwm(data->drm_fd, 
output->name);
pwm_without_abm = prev_pwm;
 
for (i = 1; i < 5; i++) {
-   set_abm_level(data, output, i);
+   ret = set_abm_level(data, output, i);
+   igt_assert_eq(ret, 0);
usleep(10);
pwm = read_target_backlight_pwm(data->drm_fd, 
output->name);
igt_assert(pwm <= prev_pwm);
@@ -323,7 +334,8 @@ static void abm_gradual(data_t *data)
 
igt_assert_eq(ret, 0);
 
-   set_abm_level(data, output, 0);
+   ret = set_abm_level(data, output, 0);
+   igt_assert_eq(ret, 0);
backlight_write_brightness(max_brightness);
 
sleep(convergence_delay);
@@ -331,7 +343,8 @@ static void abm_gradual(data_t *data)
curr = read_current_backlight_pwm(data->drm_fd, output->name);
 
igt_assert_eq(prev_pwm, curr);
-   set_abm_level(data, output, 4);
+   ret = set_abm_level(data, output, 4);
+   igt_assert_eq(ret, 0);
for (i = 0; i < 10; i++) {
usleep(10);
pwm = read_current_backlight_pwm(data->drm_fd, 
output->name);
-- 
2.45.0

[PATCH 1/2] tests/amdgpu/amd_abm: Make set_abm_level return type int

[Mario Limonciello]

From: Mario Limonciello 

In order to bubble of cases of expeted errors on set_abm_level()
change the return type to int.

Signed-off-by: Mario Limonciello 
---
 tests/amdgpu/amd_abm.c | 33 +++--
 1 file changed, 23 insertions(+), 10 deletions(-)

diff --git a/tests/amdgpu/amd_abm.c b/tests/amdgpu/amd_abm.c
index 2882c2c18..f74c3012c 100644
--- a/tests/amdgpu/amd_abm.c
+++ b/tests/amdgpu/amd_abm.c
@@ -104,10 +104,11 @@ static int backlight_write_brightness(int value)
return 0;
 }
 
-static void set_abm_level(data_t *data, igt_output_t *output, int level)
+static int set_abm_level(data_t *data, igt_output_t *output, int level)
 {
char buf[PATH_MAX];
int fd;
+   int ret;
 
igt_assert(snprintf(buf, PATH_MAX, PANEL_POWER_SAVINGS_PATH,
output->name) < PATH_MAX);
@@ -116,8 +117,12 @@ static void set_abm_level(data_t *data, igt_output_t 
*output, int level)
 
igt_assert(fd != -1);
 
-   igt_assert_eq(snprintf(buf, sizeof(buf), "%d", level),
- write(fd, buf, 1));
+   snprintf(buf, sizeof(buf), "%d", level);
+   ret = write(fd, buf, 1);
+   if (ret < 0) {
+   close(fd);
+   return ret;
+   }
 
igt_assert_eq(close(fd), 0);
 
@@ -129,6 +134,7 @@ static void set_abm_level(data_t *data, igt_output_t 
*output, int level)
 DRM_MODE_DPMS_OFF);
kmstest_set_connector_dpms(data->drm_fd, output->config.connector,
 DRM_MODE_DPMS_ON);
+   return 0;
 }
 
 static int backlight_read_max_brightness(int *result)
@@ -192,7 +198,8 @@ static void backlight_dpms_cycle(data_t *data)
ret = backlight_read_max_brightness(_brightness);
igt_assert_eq(ret, 0);
 
-   set_abm_level(data, output, 0);
+   ret = set_abm_level(data, output, 0);
+   igt_assert_eq(ret, 0);
backlight_write_brightness(max_brightness / 2);
usleep(10);
pwm_1 = read_target_backlight_pwm(data->drm_fd, output->name);
@@ -223,7 +230,8 @@ static void backlight_monotonic_basic(data_t *data)
 
brightness_step = max_brightness / 10;
 
-   set_abm_level(data, output, 0);
+   ret = set_abm_level(data, output, 0);
+   igt_assert_eq(ret, 0);
backlight_write_brightness(max_brightness);
usleep(10);
prev_pwm = read_target_backlight_pwm(data->drm_fd, 
output->name);
@@ -257,7 +265,8 @@ static void backlight_monotonic_abm(data_t *data)
 
brightness_step = max_brightness / 10;
for (i = 1; i < 5; i++) {
-   set_abm_level(data, output, 0);
+   ret = set_abm_level(data, output, 0);
+   igt_assert_eq(ret, 0);
backlight_write_brightness(max_brightness);
usleep(10);
prev_pwm = read_target_backlight_pwm(data->drm_fd, 
output->name);
@@ -289,14 +298,16 @@ static void abm_enabled(data_t *data)
ret = backlight_read_max_brightness(_brightness);
igt_assert_eq(ret, 0);
 
-   set_abm_level(data, output, 0);
+   ret = set_abm_level(data, output, 0);
+   igt_assert_eq(ret, 0);
backlight_write_brightness(max_brightness);
usleep(10);
prev_pwm = read_target_backlight_pwm(data->drm_fd, 
output->name);
pwm_without_abm = prev_pwm;
 
for (i = 1; i < 5; i++) {
-   set_abm_level(data, output, i);
+   ret = set_abm_level(data, output, i);
+   igt_assert_eq(ret, 0);
usleep(10);
pwm = read_target_backlight_pwm(data->drm_fd, 
output->name);
igt_assert(pwm <= prev_pwm);
@@ -323,7 +334,8 @@ static void abm_gradual(data_t *data)
 
igt_assert_eq(ret, 0);
 
-   set_abm_level(data, output, 0);
+   ret = set_abm_level(data, output, 0);
+   igt_assert_eq(ret, 0);
backlight_write_brightness(max_brightness);
 
sleep(convergence_delay);
@@ -331,7 +343,8 @@ static void abm_gradual(data_t *data)
curr = read_current_backlight_pwm(data->drm_fd, output->name);
 
igt_assert_eq(prev_pwm, curr);
-   set_abm_level(data, output, 4);
+   ret = set_abm_level(data, output, 4);
+   igt_assert_eq(ret, 0);
for (i = 0; i < 10; i++) {
usleep(10);
pwm = read_current_backlight_pwm(data->drm_fd, 
output->name);
-- 
2.45.0

[PATCH 0/2] Add support for Panel Power Savings property

[Mario Limonciello]

During the Display Next hackfest 2024 one of the topics discussed
was the need for compositor to be able to relay intention to drivers
that color fidelity is preferred over power savings.

To accomplish this a new optional DRM property is being introduced called
"panel power saving".  This property is an enum that can be configured
by the compositor to "Allowed" or "Forbidden".

When a driver advertises support for this property and the compositor
sets it to "Forbidden" then the driver will disable any power saving
features that can compromise color fidelity.

In practice the main feature this currently applies to is the
"Adaptive Backlight Modulation" feature within AMD DCN on eDP panels.

When the compositor has marked the property  "Forbidden" then this
feature will be disabled and any userspace that tries to turn it on
will get an -EBUSY return code.

When the compositor has restored the value back to "Allowed" then the
previous value that would have been programmed will be restored.

Mario Limonciello (2):
  drm: Introduce panel_power_saving drm property
  drm/amd: Add panel_power_saving drm property to eDP connectors

 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  3 ++
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 34 ++---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  1 +
 drivers/gpu/drm/drm_connector.c   | 37 +++
 include/drm/drm_connector.h   |  1 +
 include/drm/drm_mode_config.h |  6 +++
 include/uapi/drm/drm_mode.h   |  4 ++
 7 files changed, 81 insertions(+), 5 deletions(-)

-- 
2.45.0

[PATCH 2/2] drm/amd: Add panel_power_saving drm property to eDP connectors

[Mario Limonciello]

When the `panel_power_saving` property is set to "Forbidden" ABM
should be disabled immediately and any requests by sysfs to update
will return an -EBUSY error.

When the property is restored to "Allowed" the previous value of
ABM will be restored.

Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  3 ++
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 36 ---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  1 +
 3 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 3ecc7ef95172..6e6531c93d81 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -1350,6 +1350,9 @@ int amdgpu_display_modeset_create_props(struct 
amdgpu_device *adev)
 "dither",
 amdgpu_dither_enum_list, sz);
 
+   if (adev->dc_enabled)
+   drm_mode_create_panel_power_saving_property(adev_to_drm(adev));
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 01b0a331e4a6..f6b80018b136 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6421,6 +6421,12 @@ int amdgpu_dm_connector_atomic_set_property(struct 
drm_connector *connector,
} else if (property == adev->mode_info.underscan_property) {
dm_new_state->underscan_enable = val;
ret = 0;
+   } else if (property == dev->mode_config.panel_power_saving) {
+   dm_new_state->abm_forbidden = val;
+   dm_new_state->abm_level = (val || !amdgpu_dm_abm_level) ?
+   ABM_LEVEL_IMMEDIATE_DISABLE :
+   amdgpu_dm_abm_level;
+   ret = 0;
}
 
return ret;
@@ -6463,6 +6469,9 @@ int amdgpu_dm_connector_atomic_get_property(struct 
drm_connector *connector,
} else if (property == adev->mode_info.underscan_property) {
*val = dm_state->underscan_enable;
ret = 0;
+   } else if (property == dev->mode_config.panel_power_saving) {
+   *val = dm_state->abm_forbidden;
+   ret = 0;
}
 
return ret;
@@ -6489,9 +6498,12 @@ static ssize_t panel_power_savings_show(struct device 
*device,
u8 val;
 
drm_modeset_lock(>mode_config.connection_mutex, NULL);
-   val = to_dm_connector_state(connector->state)->abm_level ==
-   ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
-   to_dm_connector_state(connector->state)->abm_level;
+   if (to_dm_connector_state(connector->state)->abm_forbidden)
+   val = 0;
+   else
+   val = to_dm_connector_state(connector->state)->abm_level ==
+   ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
+   to_dm_connector_state(connector->state)->abm_level;
drm_modeset_unlock(>mode_config.connection_mutex);
 
return sysfs_emit(buf, "%u\n", val);
@@ -6515,10 +6527,16 @@ static ssize_t panel_power_savings_store(struct device 
*device,
return -EINVAL;
 
drm_modeset_lock(>mode_config.connection_mutex, NULL);
-   to_dm_connector_state(connector->state)->abm_level = val ?:
-   ABM_LEVEL_IMMEDIATE_DISABLE;
+   if (to_dm_connector_state(connector->state)->abm_forbidden)
+   ret = -EBUSY;
+   else
+   to_dm_connector_state(connector->state)->abm_level = val ?:
+   ABM_LEVEL_IMMEDIATE_DISABLE;
drm_modeset_unlock(>mode_config.connection_mutex);
 
+   if (ret)
+   return ret;
+
drm_kms_helper_hotplug_event(dev);
 
return count;
@@ -7689,6 +7707,14 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
aconnector->base.state->max_bpc = 16;
aconnector->base.state->max_requested_bpc = 
aconnector->base.state->max_bpc;
 
+   if (connector_type == DRM_MODE_CONNECTOR_eDP &&
+   (dc_is_dmcu_initialized(adev->dm.dc) ||
+adev->dm.dc->ctx->dmub_srv) && amdgpu_dm_abm_level < 0) {
+   drm_object_attach_property(>base.base,
+   dm->ddev->mode_config.panel_power_saving,
+   DRM_MODE_PANEL_POWER_SAVING_ALLOWED);
+   }
+
if (connector_type == DRM_MODE_CONNECTOR_HDMIA) {
/* Content Type is currently only implemented for HDMI. */
drm_connector_attach_content_type_property(>base);
diff --git a/drivers/gpu/drm/amd/display/amdgp

[PATCH 1/2] drm: Introduce panel_power_saving drm property

[Mario Limonciello]

The `panel_power_saving` DRM property is an optional property that
can be added to a connector by a driver.

This property is for compositors to indicate intent of allowing
policy for the driver to use power saving features that may
compromise color fidelity.

Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/drm_connector.c | 36 +
 include/drm/drm_connector.h |  1 +
 include/drm/drm_mode_config.h   |  6 ++
 include/uapi/drm/drm_mode.h |  4 
 4 files changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 4d2df7f64dc5..ccf672c55e0c 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -961,6 +961,11 @@ static const struct drm_prop_enum_list 
drm_scaling_mode_enum_list[] = {
{ DRM_MODE_SCALE_ASPECT, "Full aspect" },
 };
 
+static const struct drm_prop_enum_list drm_panel_power_saving_enum_list[] = {
+   { DRM_MODE_PANEL_POWER_SAVING_ALLOWED, "Allowed" },
+   { DRM_MODE_PANEL_POWER_SAVING_FORBIDDEN, "Forbidden" },
+};
+
 static const struct drm_prop_enum_list drm_aspect_ratio_enum_list[] = {
{ DRM_MODE_PICTURE_ASPECT_NONE, "Automatic" },
{ DRM_MODE_PICTURE_ASPECT_4_3, "4:3" },
@@ -1963,6 +1968,37 @@ int drm_mode_create_scaling_mode_property(struct 
drm_device *dev)
 }
 EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
 
+/**
+ * drm_mode_create_panel_power_saving_property - create panel power saving 
property
+ * @dev: DRM device
+ *
+ * Called by a driver the first time it's needed, must be attached to desired
+ * connectors.
+ *
+ * Atomic drivers should use drm_mode_create_panel_power_saving_property()
+ * instead to correctly assign _connector_state.panel_power_saving
+ * in the atomic state.
+ *
+ * Returns: %0
+ */
+int drm_mode_create_panel_power_saving_property(struct drm_device *dev)
+{
+   struct drm_property *panel_power_saving;
+
+   if (dev->mode_config.panel_power_saving)
+   return 0;
+
+   panel_power_saving =
+   drm_property_create_enum(dev, 0, "panel power saving",
+   drm_panel_power_saving_enum_list,
+   
ARRAY_SIZE(drm_panel_power_saving_enum_list));
+
+   dev->mode_config.panel_power_saving = panel_power_saving;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_mode_create_panel_power_saving_property);
+
 /**
  * DOC: Variable refresh properties
  *
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index fe88d7fc6b8f..4ea3f912c641 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -2025,6 +2025,7 @@ int drm_mode_create_dp_colorspace_property(struct 
drm_connector *connector,
   u32 supported_colorspaces);
 int drm_mode_create_content_type_property(struct drm_device *dev);
 int drm_mode_create_suggested_offset_properties(struct drm_device *dev);
+int drm_mode_create_panel_power_saving_property(struct drm_device *dev);
 
 int drm_connector_set_path_property(struct drm_connector *connector,
const char *path);
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 973119a9176b..099ad2d8c5c1 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -954,6 +954,12 @@ struct drm_mode_config {
 */
struct drm_atomic_state *suspend_state;
 
+   /**
+* @panel_power_saving: DRM ENUM property for type of
+* Panel Power Saving.
+*/
+   struct drm_property *panel_power_saving;
+
const struct drm_mode_config_helper_funcs *helper_private;
 };
 
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 7040e7ea80c7..82e565cc76fb 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -152,6 +152,10 @@ extern "C" {
 #define DRM_MODE_SCALE_CENTER  2 /* Centered, no scaling */
 #define DRM_MODE_SCALE_ASPECT  3 /* Full screen, preserve aspect */
 
+/* Panel power saving options */
+#define DRM_MODE_PANEL_POWER_SAVING_ALLOWED0 /* Panel power savings 
features allowed */
+#define DRM_MODE_PANEL_POWER_SAVING_FORBIDDEN  1 /* Panel power savings 
features not allowed */
+
 /* Dithering mode options */
 #define DRM_MODE_DITHERING_OFF 0
 #define DRM_MODE_DITHERING_ON  1
-- 
2.45.0

[PATCH 1/2] drm: Introduce panel_power_saving drm property

[Mario Limonciello]

The `panel_power_saving` DRM property is an optional property that
can be added to a connector by a driver.

This property is for compositors to indicate intent of allowing
policy for the driver to use power saving features that may
compromise color fidelity.

Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/drm_connector.c | 36 +
 include/drm/drm_connector.h |  1 +
 include/drm/drm_mode_config.h   |  6 ++
 include/uapi/drm/drm_mode.h |  4 
 4 files changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 4d2df7f64dc5..ccf672c55e0c 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -961,6 +961,11 @@ static const struct drm_prop_enum_list 
drm_scaling_mode_enum_list[] = {
{ DRM_MODE_SCALE_ASPECT, "Full aspect" },
 };
 
+static const struct drm_prop_enum_list drm_panel_power_saving_enum_list[] = {
+   { DRM_MODE_PANEL_POWER_SAVING_ALLOWED, "Allowed" },
+   { DRM_MODE_PANEL_POWER_SAVING_FORBIDDEN, "Forbidden" },
+};
+
 static const struct drm_prop_enum_list drm_aspect_ratio_enum_list[] = {
{ DRM_MODE_PICTURE_ASPECT_NONE, "Automatic" },
{ DRM_MODE_PICTURE_ASPECT_4_3, "4:3" },
@@ -1963,6 +1968,37 @@ int drm_mode_create_scaling_mode_property(struct 
drm_device *dev)
 }
 EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
 
+/**
+ * drm_mode_create_panel_power_saving_property - create panel power saving 
property
+ * @dev: DRM device
+ *
+ * Called by a driver the first time it's needed, must be attached to desired
+ * connectors.
+ *
+ * Atomic drivers should use drm_mode_create_panel_power_saving_property()
+ * instead to correctly assign _connector_state.panel_power_saving
+ * in the atomic state.
+ *
+ * Returns: %0
+ */
+int drm_mode_create_panel_power_saving_property(struct drm_device *dev)
+{
+   struct drm_property *panel_power_saving;
+
+   if (dev->mode_config.panel_power_saving)
+   return 0;
+
+   panel_power_saving =
+   drm_property_create_enum(dev, 0, "panel power saving",
+   drm_panel_power_saving_enum_list,
+   
ARRAY_SIZE(drm_panel_power_saving_enum_list));
+
+   dev->mode_config.panel_power_saving = panel_power_saving;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_mode_create_panel_power_saving_property);
+
 /**
  * DOC: Variable refresh properties
  *
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index fe88d7fc6b8f..4ea3f912c641 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -2025,6 +2025,7 @@ int drm_mode_create_dp_colorspace_property(struct 
drm_connector *connector,
   u32 supported_colorspaces);
 int drm_mode_create_content_type_property(struct drm_device *dev);
 int drm_mode_create_suggested_offset_properties(struct drm_device *dev);
+int drm_mode_create_panel_power_saving_property(struct drm_device *dev);
 
 int drm_connector_set_path_property(struct drm_connector *connector,
const char *path);
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 973119a9176b..099ad2d8c5c1 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -954,6 +954,12 @@ struct drm_mode_config {
 */
struct drm_atomic_state *suspend_state;
 
+   /**
+* @panel_power_saving: DRM ENUM property for type of
+* Panel Power Saving.
+*/
+   struct drm_property *panel_power_saving;
+
const struct drm_mode_config_helper_funcs *helper_private;
 };
 
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 7040e7ea80c7..82e565cc76fb 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -152,6 +152,10 @@ extern "C" {
 #define DRM_MODE_SCALE_CENTER  2 /* Centered, no scaling */
 #define DRM_MODE_SCALE_ASPECT  3 /* Full screen, preserve aspect */
 
+/* Panel power saving options */
+#define DRM_MODE_PANEL_POWER_SAVING_ALLOWED0 /* Panel power savings 
features allowed */
+#define DRM_MODE_PANEL_POWER_SAVING_FORBIDDEN  1 /* Panel power savings 
features not allowed */
+
 /* Dithering mode options */
 #define DRM_MODE_DITHERING_OFF 0
 #define DRM_MODE_DITHERING_ON  1
-- 
2.45.0

[PATCH 2/2] drm/amd: Add panel_power_saving drm property to eDP connectors

[Mario Limonciello]

When the `panel_power_saving` property is set to "Forbidden" ABM
should be disabled immediately and any requests by sysfs to update
will return an -EBUSY error.

When the property is restored to "Allowed" the previous value of
ABM will be restored.

Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  3 ++
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 36 ---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  1 +
 3 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 3ecc7ef95172..6e6531c93d81 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -1350,6 +1350,9 @@ int amdgpu_display_modeset_create_props(struct 
amdgpu_device *adev)
 "dither",
 amdgpu_dither_enum_list, sz);
 
+   if (adev->dc_enabled)
+   drm_mode_create_panel_power_saving_property(adev_to_drm(adev));
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 01b0a331e4a6..f6b80018b136 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6421,6 +6421,12 @@ int amdgpu_dm_connector_atomic_set_property(struct 
drm_connector *connector,
} else if (property == adev->mode_info.underscan_property) {
dm_new_state->underscan_enable = val;
ret = 0;
+   } else if (property == dev->mode_config.panel_power_saving) {
+   dm_new_state->abm_forbidden = val;
+   dm_new_state->abm_level = (val || !amdgpu_dm_abm_level) ?
+   ABM_LEVEL_IMMEDIATE_DISABLE :
+   amdgpu_dm_abm_level;
+   ret = 0;
}
 
return ret;
@@ -6463,6 +6469,9 @@ int amdgpu_dm_connector_atomic_get_property(struct 
drm_connector *connector,
} else if (property == adev->mode_info.underscan_property) {
*val = dm_state->underscan_enable;
ret = 0;
+   } else if (property == dev->mode_config.panel_power_saving) {
+   *val = dm_state->abm_forbidden;
+   ret = 0;
}
 
return ret;
@@ -6489,9 +6498,12 @@ static ssize_t panel_power_savings_show(struct device 
*device,
u8 val;
 
drm_modeset_lock(>mode_config.connection_mutex, NULL);
-   val = to_dm_connector_state(connector->state)->abm_level ==
-   ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
-   to_dm_connector_state(connector->state)->abm_level;
+   if (to_dm_connector_state(connector->state)->abm_forbidden)
+   val = 0;
+   else
+   val = to_dm_connector_state(connector->state)->abm_level ==
+   ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
+   to_dm_connector_state(connector->state)->abm_level;
drm_modeset_unlock(>mode_config.connection_mutex);
 
return sysfs_emit(buf, "%u\n", val);
@@ -6515,10 +6527,16 @@ static ssize_t panel_power_savings_store(struct device 
*device,
return -EINVAL;
 
drm_modeset_lock(>mode_config.connection_mutex, NULL);
-   to_dm_connector_state(connector->state)->abm_level = val ?:
-   ABM_LEVEL_IMMEDIATE_DISABLE;
+   if (to_dm_connector_state(connector->state)->abm_forbidden)
+   ret = -EBUSY;
+   else
+   to_dm_connector_state(connector->state)->abm_level = val ?:
+   ABM_LEVEL_IMMEDIATE_DISABLE;
drm_modeset_unlock(>mode_config.connection_mutex);
 
+   if (ret)
+   return ret;
+
drm_kms_helper_hotplug_event(dev);
 
return count;
@@ -7689,6 +7707,14 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
aconnector->base.state->max_bpc = 16;
aconnector->base.state->max_requested_bpc = 
aconnector->base.state->max_bpc;
 
+   if (connector_type == DRM_MODE_CONNECTOR_eDP &&
+   (dc_is_dmcu_initialized(adev->dm.dc) ||
+adev->dm.dc->ctx->dmub_srv) && amdgpu_dm_abm_level < 0) {
+   drm_object_attach_property(>base.base,
+   dm->ddev->mode_config.panel_power_saving,
+   DRM_MODE_PANEL_POWER_SAVING_ALLOWED);
+   }
+
if (connector_type == DRM_MODE_CONNECTOR_HDMIA) {
/* Content Type is currently only implemented for HDMI. */
drm_connector_attach_content_type_property(>base);
diff --git a/drivers/gpu/drm/amd/display/amdgp

[PATCH 0/2] Add support for Panel Power Savings property

[Mario Limonciello]

During the Display Next hackfest 2024 one of the topics discussed
was the need for compositor to be able to relay intention to drivers
that color fidelity is preferred over power savings.

To accomplish this a new optional DRM property is being introduced called
"panel power saving".  This property is an enum that can be configured
by the compositor to "Allowed" or "Forbidden".

When a driver advertises support for this property and the compositor
sets it to "Forbidden" then the driver will disable any power saving
features that can compromise color fidelity.

In practice the main feature this currently applies to is the
"Adaptive Backlight Modulation" feature within AMD DCN on eDP panels.

When the compositor has marked the property  "Forbidden" then this
feature will be disabled and any userspace that tries to turn it on
will get an -EBUSY return code.

When the compositor has restored the value back to "Allowed" then the
previous value that would have been programmed will be restored.

Mario Limonciello (2):
  drm: Introduce panel_power_saving drm property
  drm/amd: Add panel_power_saving drm property to eDP connectors

 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  3 ++
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 34 ++---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  1 +
 drivers/gpu/drm/drm_connector.c   | 37 +++
 include/drm/drm_connector.h   |  1 +
 include/drm/drm_mode_config.h |  6 +++
 include/uapi/drm/drm_mode.h   |  4 ++
 7 files changed, 81 insertions(+), 5 deletions(-)

-- 
2.45.0

[PATCH] drm/amd/display: Pass errors from amdgpu_dm_init() up

[Mario Limonciello]

Errors in amdgpu_dm_init() are silently ignored and dm_hw_init()
will succeed. However often these are fatal errors and it would
be better to pass them up.

Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index d6e71aa808d8..01b0a331e4a6 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2556,8 +2556,12 @@ static int amdgpu_dm_smu_write_watermarks_table(struct 
amdgpu_device *adev)
 static int dm_hw_init(void *handle)
 {
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+   int r;
+
/* Create DAL display manager */
-   amdgpu_dm_init(adev);
+   r = amdgpu_dm_init(adev);
+   if (r)
+   return r;
amdgpu_dm_hpd_init(adev);
 
return 0;
-- 
2.43.0

[Bug 2065838] Re: System crash on resume from sleep

[Mario Limonciello]

As a random guess; could this be the same as
https://bugzilla.kernel.org/show_bug.cgi?id=218849?

Try reverting d410ee5109a1 ("ACPICA: avoid "Info: mapping multiple BARs.
Your kernel is fine."")


** Bug watch added: Linux Kernel Bug Tracker #218849
   https://bugzilla.kernel.org/show_bug.cgi?id=218849

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2065838

Title:
  System crash on resume from sleep

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2065838/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2065948] Re: fwupdmgr enable/disable-remote auto-complete is buggy

[Mario Limonciello]

Fixed upstream.
https://github.com/fwupd/fwupd/pull/7264

** Changed in: fwupd (Ubuntu)
   Status: New => Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2065948

Title:
  fwupdmgr enable/disable-remote auto-complete is buggy

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/2065948/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [PATCH] drm/amdgpu: fix Kconfig for ISP v2

[Limonciello, Mario]

On 5/14/2024 4:28 PM, Alex Deucher wrote:

Add new config option and set proper dependencies for ISP.

v2: add missed guards, drop separate Kconfig

Signed-off-by: Alex Deucher 


I have one optional remark regarding headers, but otherwise it looks 
fine by me.  Feel free to ignore it or squash it in while committing.


Reviewed-by: Mario Limonciello 


Cc: Pratap Nirujogi 



---
  drivers/gpu/drm/amd/amdgpu/Kconfig| 11 +++
  drivers/gpu/drm/amd/amdgpu/Makefile   |  2 ++
  drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  4 
  drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c |  6 ++
  4 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig 
b/drivers/gpu/drm/amd/amdgpu/Kconfig
index 22d88f8ef5279..0cd9d29394072 100644
--- a/drivers/gpu/drm/amd/amdgpu/Kconfig
+++ b/drivers/gpu/drm/amd/amdgpu/Kconfig
@@ -70,6 +70,17 @@ config DRM_AMDGPU_USERPTR
  This option selects CONFIG_HMM and CONFIG_HMM_MIRROR if it
  isn't already selected to enabled full userptr support.
  
+config DRM_AMD_ISP

+   bool "Enable AMD Image Signal Processor IP support"
+   depends on DRM_AMDGPU
+   select MFD_CORE
+   select PM_GENERIC_DOMAINS if PM
+   help
+   Choose this option to enable ISP IP support for AMD SOCs.
+   This adds the ISP (Image Signal Processor) IP driver and wires
+   it up into the amdgpu driver.  It is required for cameras
+   on APUs which utilize mipi cameras.
+
  config DRM_AMDGPU_WERROR
bool "Force the compiler to throw an error instead of a warning when 
compiling"
depends on DRM_AMDGPU
diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile 
b/drivers/gpu/drm/amd/amdgpu/Makefile
index 12ba76025cb7c..c95ec19a38264 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -325,6 +325,8 @@ amdgpu-y += $(AMD_DISPLAY_FILES)
  endif
  
  # add isp block

+ifneq ($(CONFIG_DRM_AMD_ISP),)
  amdgpu-y += amdgpu_isp.o
+endif
  
  obj-$(CONFIG_DRM_AMDGPU)+= amdgpu.o

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 846c3550fbda8..936ed3c10c884 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -113,7 +113,9 @@
  #include "amdgpu_seq64.h"
  #include "amdgpu_reg_state.h"
  #include "amdgpu_umsch_mm.h"
+#if defined(CONFIG_DRM_AMD_ISP)
  #include "amdgpu_isp.h"
+#endif
  
  #define MAX_GPU_INSTANCE		64
  
@@ -1049,8 +1051,10 @@ struct amdgpu_device {

/* display related functionality */
struct amdgpu_display_manager dm;
  
+#if defined(CONFIG_DRM_AMD_ISP)

/* isp */
struct amdgpu_isp   isp;
+#endif
  
  	/* mes */

boolenable_mes;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
index 378d5a5cda917..1bab8dd37d621 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
@@ -107,7 +107,9 @@
  #include "jpeg_v5_0_0.h"
  
  #include "amdgpu_vpe.h"

+#if defined(CONFIG_DRM_AMD_ISP)
  #include "amdgpu_isp.h"
+#endif


IMO including this header is probably relatively safe no matter if you 
have ISP enabled or not, no?


  
  #define FIRMWARE_IP_DISCOVERY "amdgpu/ip_discovery.bin"

  MODULE_FIRMWARE(FIRMWARE_IP_DISCOVERY);
@@ -712,10 +714,12 @@ static void 
amdgpu_discovery_read_from_harvest_table(struct amdgpu_device *adev,
adev->sdma.sdma_mask &=
~(1U << harvest_info->list[i].number_instance);
break;
+#if defined(CONFIG_DRM_AMD_ISP)
case ISP_HWID:
adev->isp.harvest_config |=
~(1U << harvest_info->list[i].number_instance);
break;
+#endif
default:
break;
}
@@ -2402,6 +2406,7 @@ static int amdgpu_discovery_set_umsch_mm_ip_blocks(struct 
amdgpu_device *adev)
  
  static int amdgpu_discovery_set_isp_ip_blocks(struct amdgpu_device *adev)

  {
+#if defined(CONFIG_DRM_AMD_ISP)
switch (amdgpu_ip_version(adev, ISP_HWIP, 0)) {
case IP_VERSION(4, 1, 0):
case IP_VERSION(4, 1, 1):
@@ -2410,6 +2415,7 @@ static int amdgpu_discovery_set_isp_ip_blocks(struct 
amdgpu_device *adev)
default:
break;
}
+#endif
  
  	return 0;

  }

[regext] Fwd: New Version Notification for draft-ietf-regext-rdap-jscontact-18.txt

[Mario Loffredo]

Hi,

in this new version some feedback by Andy has been addressed, some 
sections have been slightly revised and I-Ds have been replaced with 
RFCs in references.


Have also added to the jscontact-tools library a wrapper to demonstrate 
how easy is to handle the JSContact format in an EPP-like manner (see 
see at 
https://github.com/consiglionazionaledellericerche/jscontact-tools?tab=readme-ov-file#using-jscontact-in-rdap).


Keeping aside for the moment the method used by clients to request for 
JSContact in RDAP responses, which depends on the outcomes of the 
discussion about how to handle RDAP extensions, think that next thing to 
address is how the tansition process should take place.


The draft presents a solution that aims to minimize the response payload 
during the transition and enable servers to realize when their clients 
have deprecated the jCard format.


In addition, the proposed solution is not finalized to forcefully 
deprecate the jCard format (obviously, that would be hopeful)  as the 
JSContact format would be handled as any other optional extension.


Of course, the authors would welcome any alternative leading to consensus.


Any feedback is very appreciated.

Best,

Mario






 Messaggio Inoltrato 
Oggetto: 	New Version Notification for 
draft-ietf-regext-rdap-jscontact-18.txt

Data:   Thu, 16 May 2024 00:41:09 -0700
Mittente:   internet-dra...@ietf.org
A: 	Gavin Brown , Mario Loffredo 





A new version of Internet-Draft draft-ietf-regext-rdap-jscontact-18.txt has
been successfully submitted by Mario Loffredo and posted to the
IETF repository.

Name: draft-ietf-regext-rdap-jscontact
Revision: 18
Title: Using JSContact in Registration Data Access Protocol (RDAP) JSON 
Responses

Date: 2024-05-16
Group: regext
Pages: 26
URL: https://www.ietf.org/archive/id/draft-ietf-regext-rdap-jscontact-18.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-jscontact
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-jscontact-18


Abstract:

This document describes an RDAP extension which represents entity
contact information in JSON responses using JSContact.



The IETF Secretariat

___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[Bug 2065874] Re: Can't update firmware on TPM-backed FDE systems

[Mario Limonciello]

This is the original bug for deb fwupd: 
https://github.com/canonical/ubuntu-desktop-installer/issues/2371
This is the original bug for snap fwupd: 
https://github.com/fwupd/fwupd/issues/6264

The problem is that fwupd (both deb and snap) don't understand the
layout that TPM FDE uses.

As mentioned in https://github.com/canonical/ubuntu-desktop-
installer/issues/2371#issue-1940392263 about the deb problem:

> fwupd is not aware of this layout.
In order for a firmware update to work, fwupd expects to be able to create a 
new NVRAM boot entry using shim to chainload fwupdx64.efi.

As mentioned in
https://github.com/fwupd/fwupd/issues/6264#issuecomment-1764898120 about
the snap problem:

> My take on this issue is that it's because the Ubuntu 23.10 FDE mounts
stuff in a weird location. The ESP is at /run/mnt which isn't something
that the fwupd snap interface understands. It fully expects it to be in
/boot/efi.


** Also affects: ubuntu-desktop-provision
   Importance: Undecided
   Status: New

** Changed in: fwupd (Ubuntu)
   Status: New => Triaged

** Bug watch added: github.com/canonical/ubuntu-desktop-installer/issues #2371
   https://github.com/canonical/ubuntu-desktop-installer/issues/2371

** Bug watch added: github.com/fwupd/fwupd/issues #6264
   https://github.com/fwupd/fwupd/issues/6264

** Also affects: snapd
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2065874

Title:
  Can't update firmware on TPM-backed FDE systems

To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/2065874/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [Flying-squirrel-members] Fashion Show donation

[Mario Savastano]

Works for me.

On Wed, May 15, 2024 at 10:23 PM Al Brundage  wrote:

> No objection here
> On 5/15/24 7:09 PM, Christopher Snyder wrote:
>
> Good evening all,
>
> We have a request from Gabrielle to waive the donation for the fashion
> show this past weekend. The event had a lower turnout than expected and
> they need to recoup some costs. On balance the FAC events have been an
> asset for the Squirrel so I'm not opposed to waiving for this event.
>
> Let me know if there are any questions or objections.
>
> Thank you
>
> Christopher
>
> --
> Christopher Snyder
> he/him
> 585-815-3749
>
>
>
> ___
> Flying-squirrel-members mailing 
> listFlying-squirrel-members@lists.rocus.orghttps://lists.mayfirst.org/mailman/listinfo/flying-squirrel-members
>
> To unsubscribe, send an email 
> to:flying-squirrel-members-unsubscr...@lists.rocus.org
> (The subject and body of the email don't matter)
>
> ___
> Flying-squirrel-members mailing list
> Flying-squirrel-members@lists.rocus.org
> https://lists.mayfirst.org/mailman/listinfo/flying-squirrel-members
>
> To unsubscribe, send an email to:
> flying-squirrel-members-unsubscr...@lists.rocus.org
> (The subject and body of the email don't matter)
>
___
Flying-squirrel-members mailing list
Flying-squirrel-members@lists.rocus.org
https://lists.mayfirst.org/mailman/listinfo/flying-squirrel-members

To unsubscribe, send an email to:
flying-squirrel-members-unsubscr...@lists.rocus.org
(The subject and body of the email don't matter)

[MLO] Translation of blog.kurganskyi.in.ua/2021/03/30/priority-of-task/

[Mario Seixas Sales]

Planning System Based on MyLifeOrganized

Publication Date: 18.06.2021
Author: Oleksandr Krayovyi
http://blog.kurganskyi.in.ua/2021/03/30/priority-of-task/

A well-tuned mechanism, where all weak links are addressed, and everything 
is clear as day. It's time to share my planning system, which I've been 
using for many years. In some ways, it resembles the American 
Constitution—new additions appear over time, but the foundation remains 
unshakable. All elements are time-tested, refined, and reliable. Nothing 
superfluous. Nothing without explanation or rationale.

Reading forums, I often encounter users' "reinvented wheels." I have 
nothing against it. If it works for someone, that's the beauty of 
MyLifeOrganized. Everyone customizes it to their needs. However, my 
personal belief is that such "handmade" systems can be daunting for 
beginners:
* They scare them off
* They seem overly complicated

This became another reason for writing this article: to show new 
MyLifeOrganized users that the system and product can be understandable and 
convenient, to share my insights and approach with experienced users, and 
to demonstrate the unique capabilities of MyLifeOrganized to those still 
deciding on a planner.

"Let's go!" as cosmonaut Yuri Gagarin once said...

Contents
1. Settings: There are many, but you set them once and that's it!
2. Basic Concepts: What is what?
3. One-time Task
4. Recurring Task
5. Project
6. What I Record in Project Notes
7. Project Statuses - The Basis of My Weekly System Review
8. Goals
9. Review - A Tool for Displaying "Someday" Tasks
10. Reference Information
11. Task Tree: A Complete Life Display
12. Contexts, Flags, Text Tags: Why So Many?
13. Active Actions: Main Working Lists
14. Principles of Working in My System
15. How to Form the Right List for the Current Situation
16. Are You Satisfied with Your Planning System?

Settings: There are many, but you set them once and that's it!
MyLifeOrganized has a lot of properties. Often, I see people using them 
without understanding their purpose or benefits. They just use whatever 
comes to hand. Hence my rule: Assign specific properties to certain types 
of tasks to quickly create a simple list of tasks, projects, and 
information with the necessary sorting. It's essential to understand the 
purpose of each property:
1. Which tasks to assign them to?
2. What does it provide?
3. How will it be applied or used?

In my courses, I always draw an analogy: Assigning properties to tasks is 
like the amount of sugar in tea:
1. The optimal amount is individual for everyone.
2. If there's too little sugar, it feels like something is missing.
3. If there's too much sugar, it feels cloying and uncomfortable.

By the way, there are properties I don't use at all. But this is not due to 
ignorance of their purpose, but my conscious choice. I understand that for 
you, these might be some of the most important properties. To make it 
clearer, I'll give an example of how I analyze properties. It's enough to 
give each value a definition that leaves no room for ambiguous 
interpretation. For example, a deadline. What is it? A deadline is a point 
after which it either makes no sense to complete the task, or certain 
consequences occur after the given date or time (financial loss, letting 
someone down, damaging relationships, etc.). A deadline is assigned only to 
tasks that have one. To determine whether to assign a deadline to a task, 
ask: What will happen if I don't complete this task by the assigned 
deadline? If nothing significant (in my understanding) happens, no deadline 
is assigned. These tasks can be important, urgent, "for yesterday," "for 
the day before yesterday," which will also affect their weight in the list 
of active actions. But they don't have a real deadline. This approach helps 
avoid a large number of overdue tasks, especially those with low priority, 
which undoubtedly affects internal calm and trust in the system.

Assignment: Try to define with unambiguous interpretation what urgency, 
importance, start date, and other properties mean to you.

Basic Concepts: What is what?
One-time Task
In reality, there are very few one-time tasks, especially those that fit my 
definition. For me, a one-time task is one that has the following 
characteristics:
1. Can be completed in one go at one location.
2. All necessary resources are available.
3. Completing the task does not require further development.

Each of these actions is self-sufficient. Done and forgotten! It's 
important to distinguish one-time actions from project sub-tasks. For 
example: scheduling a meeting with a client. It can be done in one go at 
one location. All resources might be available. But the process doesn't end 
there!

Recurring Task
Such tasks can be called areas of responsibility. Their main purpose is: 
What and how often should be done to keep life under control and prevent 
crises? This can also be called crisis prevention. Given that recurring 
tasks 

Re: How to run automatically a script as soon root login

[Mario Marietto]

I've installed the Cloudflare gateway on Debian as a vm because I can't do
it directly in FreeBSD. But I want to be covered even when I use FreeBSD.
The script that I wrote forward the Cloudflare "VPN" from Debian to
FreeBSD,so from outside my IP will be cloudFlared.

On Tue, May 14, 2024 at 1:16 PM Greg Wooledge  wrote:

> On Tue, May 14, 2024 at 01:10:05PM +0200, Mario Marietto wrote:
> > Your answer does not help me to understand how to use a "structured
> > programming / if , while, for, functions" for the specific task that I
> want
> > to achieve.
>
> What task is that?
>
>

-- 
Mario.

Re: How to run automatically a script as soon root login

[Mario Marietto]

Your answer does not help me to understand how to use a "structured
programming / if , while, for, functions" for the specific task that I want
to achieve. I failed using "your" lovely structured programming and that's
the reason why I'm asking for some hint to understand why and how I can use
it. Your answer puts the finger on the spot and isn't helpful, also because
it says things that I already knew.


On Tue, May 14, 2024 at 1:03 PM Greg Wooledge  wrote:

> On Tue, May 14, 2024 at 08:09:18AM +0200, Mario Marietto wrote:
> > Nobody can show a different way,a modern way, for creating my script ?
> Why
> > did I feel so comfortable by recreating the 1960s GOTO statement in Bash
> ?
>
> I have absolutely no clue what you're trying to do or why you're trying
> to do it, but I *promise* you, whatever you think you're doing, you
> have NOT recreated a GOTO statement in bash.
>
> You showed a function.  Functions can be called.  This is NOT the same
> as issuing a GOTO command, because once the function returns, control
> flow resumes from the point where it was called.
>
> Bash (and sh, on which bash is based) explicitly chose not to have a GOTO
> statement in its language.  The authors chose instead to use the control
> primitives that are collectively known as "structured programming"
> (if, while, for, functions).
>
>

-- 
Mario.

Re: How to run automatically a script as soon root login

[Mario Marietto]

Nobody can show a different way,a modern way, for creating my script ? Why
did I feel so comfortable by recreating the 1960s GOTO statement in Bash ?

On Mon, May 13, 2024 at 6:30 PM Will Mengarini  wrote:

> Nobody has yet applauded this glorious implementation
> of the 1960s GOTO statement in *Bash*?!
>
> * Mario Marietto  [24-05/13=Mo 13:37 +0200]:
> > function jumpto
> > {
> > label=$1
> > cmd=$(sed -n "/$label:/{:a;n;p;ba};" $0 | grep -v ':$')
> > eval "$cmd"
> > exit
> > }
>
> Anyway, Marietto, you've got two typi:
>
> > mid :
> That should be "mid:".
>
> > jump foo
> That should be "jumpto foo".
>
> Once you've got your root-login script working, I hope you
> move on to implementing a complete open-source PL/I compiler.
>


-- 
Mario.

Re: How to run automatically a script as soon root login

[Mario Marietto]

yeah at the beginning i used xorg + xfce but then i realized that i did not
need them,so the context became the textual mode.

Il lun 13 mag 2024, 21:52 David Wright  ha
scritto:

> On Mon 13 May 2024 at 21:18:30 (+0200), Mario Marietto wrote:
> > On Mon, May 13, 2024 at 9:05 PM Greg Wooledge  wrote:
> > > On Mon, May 13, 2024 at 06:06:37PM +0200, Hans wrote:
> > > > Am Montag, 13. Mai 2024, 13:24:17 CEST schrieb Greg Wooledge:
> > > > > On Mon, May 13, 2024 at 07:36:07AM +0200, Richard wrote:
> > > > > > .profile
> > > >
> > > > Sorry, dumb question: Depending of the shell, the user is using
> (let's
> > > say, he
> > > > will use bash), can the script not be added into ~/.bashrc?
> > >
> > > The context has been snipped out.  The context for this was "OP is
> trying
> > > to run a command when root logs in".  The method of login was not
> stated.
> > > First responder said ".profile works for every method of login".  I
> said
> > > that this is incorrect: it doesn't work for many GUI login setups.
> > >
> > > In those same GUI login setups, .bashrc is *also* not read when the
> > > user logs in.  None of the shell startup files are read at all.
> > >
> > > All of this is a tangent to the actual problem, though.
> > >
> > > > If yes, second dumb question: Coiuld it be ANY script or command?
> > > > (also running as non-rootuser, like adding "runuser -u myuser
> > > > command_whatever").
> > >
> > > We're several layers deep into an X-Y problem here.  The *actual*
> problem
> > > is that the system's networking configuration is not correct/complete.
> > >
> > > The *workaround* is that the OP is logging in and running commands to
> > > change the networking configuration temporarily.
> > >
> > > The question resulting from the workaround (the Y in the X-Y) was "How
> > > can I automate these commands that I keep having to type?"
> > >
> > > The proper question should have been "How can I fix my system's
> networking
> > > configuration permanently?"
> > >
> > ---> The context has been snipped out
> >
> > nope. Read well what I said on my first post :
> >
> >
> > *[Forgot to say that I switched boot target to text with this command :*
> >
> > *sudo systemctl set-default multi-user.target]*
> >
> > What does this mean for you ?
>
> To me, it means just one more change while trying to get your
> networking to work. Your OP finished with "It does not work and anyway
> it does not seem to be what I want..." and "I suspect that the
> solution is easier than what I'm trying to do...". Again, to me,
> that suggests that after settling on a better, permanent solution
> to your problem, you would roll back the other changes that you
> made along the way.
>
> > The context is that I was not using any
> > desktop manager.
>
> My understanding of this statement is that "the context" is what
> is described in your OP. As you said you "switched boot target to
> text", I would assume you originally had a different target, likely
> a DM, and that you might revert back to it after solving the problem.
>
> Cheers,
> David.
>
>

Re: How to run automatically a script as soon root login

[Mario Marietto]

---> The context has been snipped out

nope. Read well what I said on my first post :


*[Forgot to say that I switched boot target to text with this command :*

*sudo systemctl set-default multi-user.target]*

What does this mean for you ? The context is that I was not using any
desktop manager.


On Mon, May 13, 2024 at 9:05 PM Greg Wooledge  wrote:

> On Mon, May 13, 2024 at 06:06:37PM +0200, Hans wrote:
> > Am Montag, 13. Mai 2024, 13:24:17 CEST schrieb Greg Wooledge:
> > > On Mon, May 13, 2024 at 07:36:07AM +0200, Richard wrote:
> > > > .profile
> >
> > Sorry, dumb question: Depending of the shell, the user is using (let's
> say, he
> > will use bash), can the script not be added into ~/.bashrc?
>
> The context has been snipped out.  The context for this was "OP is trying
> to run a command when root logs in".  The method of login was not stated.
> First responder said ".profile works for every method of login".  I said
> that this is incorrect: it doesn't work for many GUI login setups.
>
> In those same GUI login setups, .bashrc is *also* not read when the
> user logs in.  None of the shell startup files are read at all.
>
> All of this is a tangent to the actual problem, though.
>
> > If yes, second dumb question: Coiuld it be ANY script or command?
> > (also running as non-rootuser, like adding "runuser -u myuser
> > command_whatever").
>
> We're several layers deep into an X-Y problem here.  The *actual* problem
> is that the system's networking configuration is not correct/complete.
>
> The *workaround* is that the OP is logging in and running commands to
> change the networking configuration temporarily.
>
> The question resulting from the workaround (the Y in the X-Y) was "How
> can I automate these commands that I keep having to type?"
>
> The proper question should have been "How can I fix my system's networking
> configuration permanently?"
>
>

-- 
Mario.

Re: Cluster Linux con Debian.

[Mario vittorio Guenzi]

Il 13/05/24 18:53, Gollum1 ha scritto:

Ciao Lista,

Mi date qualche suggerimento su come metterli in cluster?


il nostro ambiente di produzione e' in cluster con DRBD+heartbeat (si lo 
so e' deprecato ma funziona e per fare quello che dobbiamo ce n'e' da 
vendere), ogni nodo ha una primario quindi in DRBD c'e' la direttiva 
allow two primary e heartbeat governa il tutto, gestendo lvm xen e 
quant'altro in caso di caduta di un nodo  per una ragione qualsiasi.


Fondamentalmente DRDB occupa una eth su ciascun nodo e heartbeat lavora 
sulla subnet della LAN drbd e' punto punto cioe' non c'e uno switch in 
mezzo.


Per sommi capi questo usiamo.

--
Mario Vittorio Guenzi

http://clark.tipistrani.it

Si vis pacem para bellum

Re: How to run automatically a script as soon root login

[Mario Marietto]

I think I have found my way,adding this line to /etc/sudoers :

marietto ALL=(ALL) NOPASSWD: /usr/bin/iptables

and on the warp script :

sudo /usr/bin/iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE

On Mon, May 13, 2024 at 3:20 PM  wrote:

> On Mon, May 13, 2024 at 09:17:31AM -0400, Greg Wooledge wrote:
> > On Mon, May 13, 2024 at 02:03:59PM +0100, Richmond wrote:
> > > >> sudo xterm -e "echo 1 > hello"
> >
> > > Yes, but why did it allow me to delete the file? I was not root
> > > then. Try it.
> >
> > Because you have write permission on the *directory* that the file is in.
> >
> > Removing (unlinking) a file is an operation that modifies a directory,
> > not the file itself.  You don't need write permission on the file.  Just
> > the directory.
>
> Unless the directory has the sticky bit set (e.g. /tmp).
>
> (For completeness: I know you know that).
>
> Cheers
> --
> t
>


-- 
Mario.

Re: How to run automatically a script as soon root login

[Mario Marietto]

I don't have those typos in the code. The typo has been to copy the content
of the script by hand on the email message.

On Mon, May 13, 2024 at 6:30 PM Will Mengarini  wrote:

> Nobody has yet applauded this glorious implementation
> of the 1960s GOTO statement in *Bash*?!
>
> * Mario Marietto  [24-05/13=Mo 13:37 +0200]:
> > function jumpto
> > {
> > label=$1
> > cmd=$(sed -n "/$label:/{:a;n;p;ba};" $0 | grep -v ':$')
> > eval "$cmd"
> > exit
> > }
>
> Anyway, Marietto, you've got two typi:
>
> > mid :
> That should be "mid:".
>
> > jump foo
> That should be "jumpto foo".
>
> Once you've got your root-login script working, I hope you
> move on to implementing a complete open-source PL/I compiler.
>


-- 
Mario.

Re: How to run automatically a script as soon root login

[Mario Marietto]

[image: Istantanea_2024-05-13_17-37-39.png]

Can someone explain to me why user "marietto" can't execute the command
iptables as root,without password ? thanks.

[image: Istantanea_2024-05-13_17-40-21.png]

On Mon, May 13, 2024 at 5:19 PM Mario Marietto 
wrote:

> There is still a problem. If I login automatically as user and inside the
> script I do this :
>
> sudo iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE
>
> it asks me for the password (don't know why it didn't before) but I can't
> issue a password,because the script inside the vm should work automatically
> and should be hidden between the FreeBSD processes.
>
> On Mon, May 13, 2024 at 4:11 PM Stefan Monnier 
> wrote:
>
>> > You don't need to, but I definitely think he does. 
>> ^^
>>
>> [ Oh, bias, when will you leave me alone?  ]
>>
>>
>> Stefan
>>
>>
>
> --
> Mario.
>


-- 
Mario.

Re: How to run automatically a script as soon root login

[Mario Marietto]

There is still a problem. If I login automatically as user and inside the
script I do this :

sudo iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE

it asks me for the password (don't know why it didn't before) but I can't
issue a password,because the script inside the vm should work automatically
and should be hidden between the FreeBSD processes.

On Mon, May 13, 2024 at 4:11 PM Stefan Monnier 
wrote:

> > You don't need to, but I definitely think he does. 
> ^^
>
> [ Oh, bias, when will you leave me alone?  ]
>
>
>     Stefan
>
>

-- 
Mario.

Re: KIP-1040: Improve handling of nullable values in InsertField/ExtractField transformations

[Mario Fiore Vitale]

Hi all,

Any other suggestions/objections/dubs?

On Fri, May 10, 2024 at 5:10 PM Chris Egerton 
wrote:

>  Done
>
> On Fri, May 10, 2024, 10:55 Mario Fiore Vitale  wrote:
>
> > Thanks a lot! I have just a minor comment, should we also update the
> title
> > to be more generic since now it's also related to other SMTs?
> >
> > On Fri, May 10, 2024 at 4:44 PM Chris Egerton 
> > wrote:
> >
> > > I've finished updating the KIP; @Mario, please let me know what you
> > think.
> > >
> > > On Fri, May 10, 2024 at 10:26 AM Chris Egerton 
> wrote:
> > >
> > > > I can do it :)
> > > >
> > > > On Fri, May 10, 2024 at 10:02 AM Mario Fiore Vitale <
> > mvit...@redhat.com>
> > > > wrote:
> > > >
> > > >> Yes, I agree. Unfortunately due to the issue of the creation of a
> new
> > > >> account for the WIKI, I asked Mickael Maison to create the KIP for
> me.
> > > >>
> > > >> I'll ask him to update the KIP. Do you have other alternatives?
> > > >>
> > > >> Thanks,
> > > >> Mario.
> > > >>
> > > >> On Fri, May 10, 2024 at 3:40 PM Chris Egerton
>  > >
> > > >> wrote:
> > > >>
> > > >> > Yes, I think we should just do one KIP for all the SMTs. You don't
> > > have
> > > >> to
> > > >> > implement everything all at once or by yourself, but I don't see
> why
> > > we
> > > >> > should require one or more follow-up KIPs to apply the exact same
> > > >> changes
> > > >> > to the SMTs we missed the first time.
> > > >> >
> > > >> > On Fri, May 10, 2024 at 5:20 AM Mario Fiore Vitale <
> > > mvit...@redhat.com>
> > > >> > wrote:
> > > >> >
> > > >> > > Hi Chris,
> > > >> > >
> > > >> > > Thanks for the survey. Do you think I need to update the KIP to
> > put
> > > >> all
> > > >> > of
> > > >> > > these?
> > > >> > >
> > > >> > > On Thu, May 9, 2024 at 4:14 PM Chris Egerton
> > >  > > >> >
> > > >> > > wrote:
> > > >> > >
> > > >> > > > After doing a brief survey of the SMTs that ship with Connect,
> > it
> > > >> seems
> > > >> > > > like these would also benefit:
> > > >> > > >
> > > >> > > > - HeaderFrom, which populates record headers with subfields of
> > > >> > > keys/values
> > > >> > > > [1]
> > > >> > > > - Cast, which performs type transformation on subfields of
> > > >> keys/values
> > > >> > > [2]
> > > >> > > > - SetSchemaMetadata, which (when the record key/value is a
> > struct)
> > > >> > copies
> > > >> > > > fields from the input struct to the output struct (which uses
> a
> > > >> > different
> > > >> > > > schema) [3]
> > > >> > > > - TimestampConverter, which does similar input/output field
> > > copying
> > > >> to
> > > >> > > > SetSchemaMetadata [4]
> > > >> > > > - ReplaceField, which does similar input/output field copying
> to
> > > >> > > > SetSchemaMetadata and TimestampConverter
> > > >> > > >
> > > >> > > > [1] -
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://github.com/apache/kafka/blob/f4fdaa702a2e718bdb44b9c5fec254f32a33f0d8/connect/transforms/src/main/java/org/apache/kafka/connect/transforms/HeaderFrom.java#L143
> > > >> > > > [2] -
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://github.com/apache/kafka/blob/f4fdaa702a2e718bdb44b9c5fec254f32a33f0d8/connect/transforms/src/main/java/org/apache/kafka/connect/transforms/Cast.java#L178
> > > >> > > > [3] -
> > > >> > > >
> > > >> > > >
> >

Re: How to run automatically a script as soon root login

[Mario Marietto]

I've found that solution on the Internet. It wasn't the only solution that
I found,but that form won the challenge because it has found my mind ready
to detect that it could have worked. Maybe I could have used while,but
after 1 hour of thinking I didn't understand how and I resigned. The same
for until and for. Sorry for that,but I'm not an experienced coder. I try
to do my best with what I find on the Internet. I can adapt an already good
enough solution to fit my needs,but I'm not able to write a script from
scratch. It is also true that I found it good because it reminded me of my
old good times when I was a good basic and turbo pascal programmer.

On Mon, May 13, 2024 at 3:24 PM Nicolas George  wrote:

> Mario Marietto (12024-05-13):
> > The command iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE
> > doesn't work if invoked as a user,it says "you must be root". So,as
> > user,the script seems to be working fine like this :
> >
> > function jumpto
> > {
> > label=$1
> > cmd=$(sed -n "/$label:/{:a;n;p;ba};" $0 | grep -v ':$')
> > eval "$cmd"
> > exit
> > }
>
> You seem to be investing a lot of effort into a fragile solution to
> emulate a deprecated execution control primitive.
>
> Regards,
>
> --
>   Nicolas George
>
>

-- 
Mario.

Re: How to run automatically a script as soon root login

[Mario Marietto]

The command iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE
doesn't work if invoked as a user,it says "you must be root". So,as
user,the script seems to be working fine like this :

function jumpto
{
label=$1
cmd=$(sed -n "/$label:/{:a;n;p;ba};" $0 | grep -v ':$')
eval "$cmd"
exit
}

start=${1:-"start"}

jumpto $start

start:
warp-cli disconnect
OLD_IP="$(curl -s api.ipify.org)"
#echo 1 > /proc/sys/net/ipv4/ip_forward (because I've uncommented this
command inside the file /etc/sysctl.conf)
sudo iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE
warp-cli connect
NEW_IP="$(curl -s api.ipify.org)"
echo Connected to Cloudflare Warp...
echo OLD IP is $OLD_IP , NEW IP is $NEW_IP

mid :
if [ "$OLD_IP = $NEW_IP ]
then
echo OLD IP is $OLD_IP , NEW IP is $NEW_IP : it does not work
anymore,reconnecting...
sleep 10
jump foo
else
echo OLD IP is $OLD_IP , NEW IP is $NEW_IP : it still works.
sleep 10
fi
jumpto mid

foo:
warp-cli disconnect
OLD_IP="$(curl -s api.ipify.org)"
warp-cli connect
NEW_IP="$(curl -s api.ipify.org)"
echo OLD IP is $OLD_IP , NEW IP is $NEW_IP : it works again.
jumpto mid

On Mon, May 13, 2024 at 2:59 PM  wrote:

> On Mon, May 13, 2024 at 02:53:18PM +0200, Nicolas George wrote:
> > to...@tuxteam.de (12024-05-13):
> > > That's like slicing your morning baguette with the chainsaw.
> >
> > Worse than that, it will only work from an X11 environment. Certainly
> > not at boot.
>
> The analogy to that would be that not many kitchens are equipped with
> a chainsaw. Mine isn't ;-)
>
> Cheers
> --
> t
>


-- 
Mario.

Re: How to run automatically a script as soon root login

[Mario Marietto]

--> If they only want this thing to happen when root logs in directly on a
console or ssh, then .profile may indeed be the correct answer.

Yes,I don't need to run xorg and a desktop environment,since warp-cli
disconnect and warp-cli connect do not require them.
I wouldn't to login as root automatically,but I've realized that this
command :

echo 1 > /proc/sys/net/ipv4/ip_forward

work only if I'm root. It does not work using sudo. So,in the end I've
chosen to be root instead of a normal user that can use sudo.

On Mon, May 13, 2024 at 1:24 PM Greg Wooledge  wrote:

> On Mon, May 13, 2024 at 07:36:07AM +0200, Richard wrote:
> > .profile
> > will always be read as soon as the user logs in, no matter how. Through a
> > terminal, a GUI, doesn't matter.
>
> That's not correct.  There are many different GUI login setups where
> the .profile is never read.
>
> That said, since this thread is specifically about *root* logins, GUI
> logins may not be possible.  It depends on which Display Manager and
> Desktop Environment are in use.  Many of them explicitly disallow direct
> root logins.
>
> So, ultimately it comes down to what the OP actually requires, and
> what type of setup they use.  If they only want this thing to happen
> when root logs in directly on a console or ssh, then .profile may
> indeed be the correct answer.
>
>

-- 
Mario.

Re: How to run automatically a script as soon root login

[Mario Marietto]

Hello to everyone,

Richard,thanks. I've launched the script inside the .profile file that's
inside the root folder and it worked. Thank you.

Plan B : From time to time the cloudflare connection stops working,so there
is the needing to repeat these commands :

warp-cli disconnect
warp-cli connect

At this point,I've modified the script like this one : (yes,I've been a
happy coder of BASIC and I feel the nostalgia of GOTO).


function jumpto
{
label=$1
cmd=$(sed -n "/$label:/{:a;n;p;ba};" $0 | grep -v ':$')
eval "$cmd"
exit
}

start=${1:-"start"}

jumpto $start

start:
warp-cli disconnect
OLD_IP="$(curl -s api.ipify.org)"
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE
warp-cli connect
NEW_IP="$(curl -s api.ipify.org)"
echo Connected to Cloudflare Warp...
echo OLD IP is $OLD_IP , NEW IP is $NEW_IP

mid :
if [ "$OLD_IP = $NEW_IP ]
then
echo OLD IP is $OLD_IP , NEW IP is $NEW_IP : it does not work
anymore,reconnecting...
sleep 10
jump foo
else
echo OLD IP is $OLD_IP , NEW IP is $NEW_IP : it still works.
sleep 10
fi
jumpto mid

foo:
warp-cli disconnect
OLD_IP="$(curl -s api.ipify.org)"
warp-cli connect
NEW_IP="$(curl -s api.ipify.org)"
echo OLD IP is $OLD_IP , NEW IP is $NEW_IP : it works again.
jumpto mid

On Mon, May 13, 2024 at 7:36 AM Richard  wrote:

> Should be as easy as executing the script from the .profile of root - that
> means if "log in as root" actually means root, not just sudo'ing. .profile
> will always be read as soon as the user logs in, no matter how. Through a
> terminal, a GUI, doesn't matter. No idea if doing this through systemd is
> even possible.
>
> Best
> Richard
>
> On Mon, May 13, 2024, 04:10 Mario Marietto  wrote:
>
>> Hello to everyone.
>>
>> I'm using Debian 12. I'm configuring a little Debian 12 vm with qemu that
>> I will use to forward the cloudflare connection to FreeBD.
>> What I want to do is to run the script below as soon as root has logged
>> in.
>>
>> I've configured the automatic login of root adding to this service file :
>>
>> nano /etc/systemd/system/getty.target.wants/getty@tty1.service
>>
>> this line :
>>
>> ExecStart=/sbin/agetty -o '-p -f -- \\u" --noclear --autologin root %I
>> $TERM
>>
>> Now,what I want to do is that the script below is ran as soon root is
>> able to logged in automatically :
>>
>> /usr/bin/warp
>>
>> warp-cli disconnect
>> echo 1 > /proc/sys/net/ipv4/ip_forward
>> iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE
>> OLD_IP="$(curl -s api.ipify.org)"
>> warp-cli connect
>> NEW_IP="$(curl -s api.ipify.org)"
>> echo Connected to Cloudflare Warp...
>> echo OLD IP is : $OLD_IP,NEW IP is : $NEW_IP
>>
>> [Forgot to say that I switched boot target to text with this command :
>>
>> sudo systemctl set-default multi-user.target]
>>
>> What I tried right now has been to create a respawn service with systemd.
>> I created a file in /etc/systemd/system/ i.e. warp.service
>>
>> [Unit]
>> Desription=warp with systemd, respawn
>> After=pre-network.target
>>
>> [Service]
>> ExecStart=/usr/bin/warp
>> Restart=always
>>
>> [Install]
>> WantedBy=multi-user.target
>>
>>
>> and I've activated it :
>>
>> systemctl enable warp.service
>>
>>
>> rebooted and started it manually :
>>
>> systemctl daemon-reload
>> systemctl start warp.service
>>
>> It does not work and anyway it does not seem to be what I want...
>>
>> [image: Istantanea_2024-05-12_23-46-37.png]
>>
>> I want that the warp script is run everytime root is logged in,not
>> more,not less.
>> I suspect that the solution is easier than what I'm trying to do...
>>
>> --
>> Mario.
>>
>

-- 
Mario.

Re: [OT] Scelta della distro in ambiente lavorativo

[Mario vittorio Guenzi]

Scusami se rispondo solo ora, sono giornate "interessanti"

Presto detto, systemd e' la causa della nostra scelta.

Il 10/05/24 08:45, Alessandro Baggi ha scritto:



Buongiorno a tutti,

credo dipenda da diversi fattori, il principale e' la dimensione 
dell'azienda,  noi siamo piccoli e io decido che distro usare.
L'assistenza (quando serve) ce la fornisce una piccola azienda di 
Milano con la quale collaboriamo da 25 anni o giu' di li.
Tutto cio' molto difficilmente puo' succedere in azienda di 
dimensioni maggiori o che comunque ha una politica di tipo tutto deve 
essere certificato.


Abbiamo scelto Devuan diversi anni fa per n+1 motivi che sono 
importanti per noi, chi ci supporta non ci ha mai lasciato a piedi, 
quindi son sempre stati soldi investiti intelligentemente.


La mia esperienza se puo' esserti utile

Un cordiale saluto a tutti.




Ciao Mario,
grazie per il tuo feedback.

Volevo chiederti, se non è un problema, come mai la scelta è caduta su 
Devuan e non direttamente su Debian?


Un saluto,
Alessandro.


--
Mario Vittorio Guenzi

http://clark.tipistrani.it

Si vis pacem para bellum

How to run automatically a script as soon root login

[Mario Marietto]

Hello to everyone.

I'm using Debian 12. I'm configuring a little Debian 12 vm with qemu that I
will use to forward the cloudflare connection to FreeBD.
What I want to do is to run the script below as soon as root has logged in.

I've configured the automatic login of root adding to this service file :

nano /etc/systemd/system/getty.target.wants/getty@tty1.service

this line :

ExecStart=/sbin/agetty -o '-p -f -- \\u" --noclear --autologin root %I $TERM

Now,what I want to do is that the script below is ran as soon root is able
to logged in automatically :

/usr/bin/warp

warp-cli disconnect
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE
OLD_IP="$(curl -s api.ipify.org)"
warp-cli connect
NEW_IP="$(curl -s api.ipify.org)"
echo Connected to Cloudflare Warp...
echo OLD IP is : $OLD_IP,NEW IP is : $NEW_IP

[Forgot to say that I switched boot target to text with this command :

sudo systemctl set-default multi-user.target]

What I tried right now has been to create a respawn service with systemd.
I created a file in /etc/systemd/system/ i.e. warp.service

[Unit]
Desription=warp with systemd, respawn
After=pre-network.target

[Service]
ExecStart=/usr/bin/warp
Restart=always

[Install]
WantedBy=multi-user.target


and I've activated it :

systemctl enable warp.service


rebooted and started it manually :

systemctl daemon-reload
systemctl start warp.service

It does not work and anyway it does not seem to be what I want...

[image: Istantanea_2024-05-12_23-46-37.png]

I want that the warp script is run everytime root is logged in,not more,not
less.
I suspect that the solution is easier than what I'm trying to do...

-- 
Mario.

[Bug 1942616] Re: Settings Power says high hardware temperature

[Mario Limonciello]

It's saying the same thing the GUI does.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1942616

Title:
  Settings Power says high hardware temperature

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/power-profiles-daemon/+bug/1942616/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Members] Re: Proposals - programmatic and organizational business

[Mario Sabatino]

Dear Nicola, thank you for your replay. You have correctly indicated the 
real starting point of our discussion on this topic.



- what the XSF program will be for next year;
I believe the organisation's mission statement outlines the XSF 
programme for the future.


https://xmpp.org/about/xsf/mission/

So, in my opinion, should be useful to debate whether lobbying the EU 
during the DMA discussion could have been a good point for the XFS to 
achieve its goals. The same goes for the implementation of DMA in the 
real world e.g. as part of the protocol (interoperability XEP). These 
are only two examples of what could have been done and what XSF could do 
in the future.


Maintaining and developing an open standard requires hard work from the 
people involved. Applying for funding to pursue this goal could be 
helpful and may also be of interest to an EU institution or public body 
in another EU member state.


Ciao

Mario

Il 12/05/24 17:27, Nicola Fabiano ha scr
itto:

Dear All,

the discussion should cover two main points:

1) the possibility of lobbying into the EU institutions and how to start doing 
so;

 From my point of view, this is not the first point to be addressed.
It is certainly an important topic but secondary to the organization of XSF. It 
can be discussed later, but only after it has been decided
- what the XSF program will be for next year;




publickey - mario@sabatino.pro - 0x56617369.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: [PATCH] drm/mst: Fix NULL pointer dereference at drm_dp_add_payload_part2

[Limonciello, Mario]

On 5/10/2024 4:24 AM, Jani Nikula wrote:

On Fri, 10 May 2024, "Lin, Wayne"  wrote:

[Public]


-Original Message-
From: Limonciello, Mario 
Sent: Friday, May 10, 2024 3:18 AM
To: Linux regressions mailing list ; Wentland, 
Harry
; Lin, Wayne 
Cc: ly...@redhat.com; imre.d...@intel.com; Leon Weiß ; sta...@vger.kernel.org; dri-de...@lists.freedesktop.org; amd-
g...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/mst: Fix NULL pointer dereference at
drm_dp_add_payload_part2

On 5/9/2024 07:43, Linux regression tracking (Thorsten Leemhuis) wrote:

On 18.04.24 21:43, Harry Wentland wrote:

On 2024-03-07 01:29, Wayne Lin wrote:

[Why]
Commit:
- commit 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
allocation/removement") accidently overwrite the commit
- commit 54d217406afe ("drm: use mgr->dev in drm_dbg_kms in
drm_dp_add_payload_part2") which cause regression.

[How]
Recover the original NULL fix and remove the unnecessary input
parameter 'state' for drm_dp_add_payload_part2().

Fixes: 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
allocation/removement")
Reported-by: Leon Weiß 
Link:
https://lore.kernel.org/r/38c253ea42072cc825dc969ac4e6b9b600371cc8.c
a...@ruhr-uni-bochum.de/
Cc: ly...@redhat.com
Cc: imre.d...@intel.com
Cc: sta...@vger.kernel.org
Cc: regressi...@lists.linux.dev
Signed-off-by: Wayne Lin 


I haven't been deep in MST code in a while but this all looks pretty
straightforward and good.

Reviewed-by: Harry Wentland 


Hmmm, that was three weeks ago, but it seems since then nothing
happened to fix the linked regression through this or some other
patch. Is there a reason? The build failure report from the CI maybe?


It touches files outside of amd but only has an ack from AMD.  I think we
/probably/ want an ack from i915 and nouveau to take it through.


Thanks, Mario!

Hi Thorsten,
Yeah, like what Mario said. Would also like to have ack from i915 and nouveau.


It usually works better if you Cc the folks you want an ack from! ;)

Acked-by: Jani Nikula 



Thanks! Can someone with commit permissions take this to drm-misc?

Re: [PATCH] drm/mst: Fix NULL pointer dereference at drm_dp_add_payload_part2

[Limonciello, Mario]

On 5/10/2024 4:24 AM, Jani Nikula wrote:

On Fri, 10 May 2024, "Lin, Wayne"  wrote:

[Public]


-Original Message-
From: Limonciello, Mario 
Sent: Friday, May 10, 2024 3:18 AM
To: Linux regressions mailing list ; Wentland, 
Harry
; Lin, Wayne 
Cc: ly...@redhat.com; imre.d...@intel.com; Leon Weiß ; sta...@vger.kernel.org; dri-de...@lists.freedesktop.org; amd-
g...@lists.freedesktop.org; intel-...@lists.freedesktop.org
Subject: Re: [PATCH] drm/mst: Fix NULL pointer dereference at
drm_dp_add_payload_part2

On 5/9/2024 07:43, Linux regression tracking (Thorsten Leemhuis) wrote:

On 18.04.24 21:43, Harry Wentland wrote:

On 2024-03-07 01:29, Wayne Lin wrote:

[Why]
Commit:
- commit 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
allocation/removement") accidently overwrite the commit
- commit 54d217406afe ("drm: use mgr->dev in drm_dbg_kms in
drm_dp_add_payload_part2") which cause regression.

[How]
Recover the original NULL fix and remove the unnecessary input
parameter 'state' for drm_dp_add_payload_part2().

Fixes: 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
allocation/removement")
Reported-by: Leon Weiß 
Link:
https://lore.kernel.org/r/38c253ea42072cc825dc969ac4e6b9b600371cc8.c
a...@ruhr-uni-bochum.de/
Cc: ly...@redhat.com
Cc: imre.d...@intel.com
Cc: sta...@vger.kernel.org
Cc: regressi...@lists.linux.dev
Signed-off-by: Wayne Lin 


I haven't been deep in MST code in a while but this all looks pretty
straightforward and good.

Reviewed-by: Harry Wentland 


Hmmm, that was three weeks ago, but it seems since then nothing
happened to fix the linked regression through this or some other
patch. Is there a reason? The build failure report from the CI maybe?


It touches files outside of amd but only has an ack from AMD.  I think we
/probably/ want an ack from i915 and nouveau to take it through.


Thanks, Mario!

Hi Thorsten,
Yeah, like what Mario said. Would also like to have ack from i915 and nouveau.


It usually works better if you Cc the folks you want an ack from! ;)

Acked-by: Jani Nikula 



Thanks! Can someone with commit permissions take this to drm-misc?

Re: [PATCH] drm/mst: Fix NULL pointer dereference at drm_dp_add_payload_part2

[Limonciello, Mario]

On 5/10/2024 4:24 AM, Jani Nikula wrote:

On Fri, 10 May 2024, "Lin, Wayne"  wrote:

[Public]


-Original Message-
From: Limonciello, Mario 
Sent: Friday, May 10, 2024 3:18 AM
To: Linux regressions mailing list ; Wentland, 
Harry
; Lin, Wayne 
Cc: ly...@redhat.com; imre.d...@intel.com; Leon Weiß ; sta...@vger.kernel.org; dri-devel@lists.freedesktop.org; amd-
g...@lists.freedesktop.org; intel-...@lists.freedesktop.org
Subject: Re: [PATCH] drm/mst: Fix NULL pointer dereference at
drm_dp_add_payload_part2

On 5/9/2024 07:43, Linux regression tracking (Thorsten Leemhuis) wrote:

On 18.04.24 21:43, Harry Wentland wrote:

On 2024-03-07 01:29, Wayne Lin wrote:

[Why]
Commit:
- commit 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
allocation/removement") accidently overwrite the commit
- commit 54d217406afe ("drm: use mgr->dev in drm_dbg_kms in
drm_dp_add_payload_part2") which cause regression.

[How]
Recover the original NULL fix and remove the unnecessary input
parameter 'state' for drm_dp_add_payload_part2().

Fixes: 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
allocation/removement")
Reported-by: Leon Weiß 
Link:
https://lore.kernel.org/r/38c253ea42072cc825dc969ac4e6b9b600371cc8.c
a...@ruhr-uni-bochum.de/
Cc: ly...@redhat.com
Cc: imre.d...@intel.com
Cc: sta...@vger.kernel.org
Cc: regressi...@lists.linux.dev
Signed-off-by: Wayne Lin 


I haven't been deep in MST code in a while but this all looks pretty
straightforward and good.

Reviewed-by: Harry Wentland 


Hmmm, that was three weeks ago, but it seems since then nothing
happened to fix the linked regression through this or some other
patch. Is there a reason? The build failure report from the CI maybe?


It touches files outside of amd but only has an ack from AMD.  I think we
/probably/ want an ack from i915 and nouveau to take it through.


Thanks, Mario!

Hi Thorsten,
Yeah, like what Mario said. Would also like to have ack from i915 and nouveau.


It usually works better if you Cc the folks you want an ack from! ;)

Acked-by: Jani Nikula 



Thanks! Can someone with commit permissions take this to drm-misc?

[Bug 1942616] Re: Settings Power says high hardware temperature

[Mario Limonciello]

How about the command line tool (powerprofilesctl)?  Can you switch
using that?  If it really is a pure GCC bug then you can file it here:
https://launchpad.net/ubuntu/+source/gnome-control-center for Ubuntu and
here: https://gitlab.gnome.org/GNOME/gnome-control-center for upstream.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1942616

Title:
  Settings Power says high hardware temperature

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/power-profiles-daemon/+bug/1942616/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Porting HAXM to FreeBSD ?

[Mario Marietto]

Hello.

What about porting HAXM to FreeBSD ?

"HAXM was created to bring Intel Virtualization Technology to Windows and
macOS users"

keeping in consideration that MacOS has some code of FreeBSD inside :

Is the source code of HAXM freely available ? Are you able to port it to
FreeBSD ? The idea is to accelerate qemu with HAXM on FreeBSD. Someone that
can and wants to do this ?

Here :

http://mail-index.netbsd.org/netbsd-users/2019/02/13/msg022207.html

I can read that HAXM has been imported
into pkgsrc/emulators/haxm --->

Wow. So,it exists for NetBSD but not for FreeBSD ?

-- 
Mario.

[Bug 1942616] Re: Settings Power says high hardware temperature

[Mario Limonciello]

You can file it here:

https://bugzilla.kernel.org/

Mention your reproduction using a mainline kernel and add your logs.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1942616

Title:
  Settings Power says high hardware temperature

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/power-profiles-daemon/+bug/1942616/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1942616] Re: Settings Power says high hardware temperature

[Mario Limonciello]

This sure sounds like an intel-pstate bug.  If you can reproduce it with
the latest mainline kernel you should file a bug with the intel-pstate
maintainers.

You can find some kernel binaries for mainline kernel here:
https://kernel.ubuntu.com/mainline/

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1942616

Title:
  Settings Power says high hardware temperature

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/power-profiles-daemon/+bug/1942616/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Members] Re: Proposals - programmatic and organizational business

[Mario Sabatino]

Dear All,

the discussion should cover two main points:

1) the possibility of lobbying into the EU institutions and how to start 
doing so;
2) the need to have an EU legal entity in order to receive funding from 
the EU institutions.


For number 1) I don't think we need a legal entity based in the EU, but 
we do need just a lobbyist.
For number 2), we could start by exploring how to get funding from the 
EU institutions and then evaluate the possibility of creating a legal 
entity.


In the meantime, I think we could start with a simple representative 
office (a business address) of the XSF Foundation in Bruxelles.


Ciao

Mario Sabatino

Il 10/05/24 18:32, Winfried Tilanus ha scritto:

Hi,

I'm in favour, it would make several types of cooperation easier. But, I can't
judge what this would mean for taxes and so on.

Winfried


On 9 May 2024 12:09:32 CEST, Nicola Fabiano  wrote:

 ;TLTR

 Dear all,

 Regarding what is in the subject, I reproduced below the entire thread of
 emails exchanged with the Board members related to my proposal regarding 
the
 presence of XSF in Europe.
 Each email is a block with a line separating one from the others.

 All the best,

 Nicola

 


 Dear all,

 Following our last Board meeting, I propose to discuss the organization of
 XSF's activities further to promote the XMPP protocol at every level,
 including at European institutions, possibly by participating in projects 
to
 obtain contributions and funding (I have some ideas, but I will explain 
later).

 Each Board member's input is crucial.
 I encourage everyone to outline a few items as our agenda for the next 6/12
 months.
 These points should be related to programmatic and organizational business
 only (non-technical), reflecting your unique perspectives and expertise.

 In that way, everyone can be in the running for one or more items to deal
 with and what goal we (XSF) want to achieve following our program.

 Hence, feel free to share your thoughts about the programmatic and
 organizational business, and then we can discuss them.

 Apart from programmatic and organizational business, the first step is the
 proposal concerns amending the statutes of the registered office. That
 modification is necessary to access the European institutions. Other
 modification proposals are welcome, and we can evaluate all of them.

 Otherwise, an amended version (in bold italic) of Article 1 follows.


   ARTICLE I: Offices

 *Section 1.1 Registered Office and Registered Agent.* The address of the
 initial registered office of The XMPP Standards Foundation (the
 “Corporation”) in the State of Delaware and the name of the initial
 registered agent of the Corporation at such address are set forth in the
 Certificate of Incorporation (the “Certificate”). The Corporation may, from
 time to time, designate a different address as its registered office or a
 different person as its registered agent, or both; provided, however, that
 such designation shall become effective upon the filing of a statement of
 such change with the Secretary of State of the State of Delaware as is
 required by law.

 /*Section 1.2 Principal Offices.*/ The principal offices of the Corporation
 shall be at 1899 Wynkoop Street, Denver, Colorado 80202, /*and at , 
xxx,
 Europe,*/ or at such other place as the Board of Directors shall designate
 from time to time. The business of the Corporation shall be transacted from
 the principal /*offices*/, and the records of the Corporation shall be kept
 there. /*Both principal offices have legal effect, irrespective of where 
the
 activities are carried out and where they are intended*/.

 *Section 1.3 Other Offices.* The Corporation shall have such offices either
 within or outside the State of Delaware and within or outside the United
 States, as the Board of Directors may from time to time determine or as the
 business of the Corporation may require. In the event the Corporation
 desires to qualify to do business in one or more states other than 
Delaware,
 the Corporation shall designate the location of the registered office in
 each such state and designate the registered agent for service of process 
at
 such address in the manner provided by the law of the state in which the
 corporation elects to be qualified.

 


 Dear Eddie,

 Thank you for your email.

 I highlight that my email follows what I said during the Summit in 
Bruxelles.
 My intervention represents a proposal submitted to the Board, which must be
 discussed and voted on.

 On 27 Apr 2024, at 15:14, E.M. wrote:

 Dear Nicola

Re: KIP-1040: Improve handling of nullable values in InsertField/ExtractField transformations

[Mario Fiore Vitale]

Thanks a lot! I have just a minor comment, should we also update the title
to be more generic since now it's also related to other SMTs?

On Fri, May 10, 2024 at 4:44 PM Chris Egerton 
wrote:

> I've finished updating the KIP; @Mario, please let me know what you think.
>
> On Fri, May 10, 2024 at 10:26 AM Chris Egerton  wrote:
>
> > I can do it :)
> >
> > On Fri, May 10, 2024 at 10:02 AM Mario Fiore Vitale 
> > wrote:
> >
> >> Yes, I agree. Unfortunately due to the issue of the creation of a new
> >> account for the WIKI, I asked Mickael Maison to create the KIP for me.
> >>
> >> I'll ask him to update the KIP. Do you have other alternatives?
> >>
> >> Thanks,
> >> Mario.
> >>
> >> On Fri, May 10, 2024 at 3:40 PM Chris Egerton 
> >> wrote:
> >>
> >> > Yes, I think we should just do one KIP for all the SMTs. You don't
> have
> >> to
> >> > implement everything all at once or by yourself, but I don't see why
> we
> >> > should require one or more follow-up KIPs to apply the exact same
> >> changes
> >> > to the SMTs we missed the first time.
> >> >
> >> > On Fri, May 10, 2024 at 5:20 AM Mario Fiore Vitale <
> mvit...@redhat.com>
> >> > wrote:
> >> >
> >> > > Hi Chris,
> >> > >
> >> > > Thanks for the survey. Do you think I need to update the KIP to put
> >> all
> >> > of
> >> > > these?
> >> > >
> >> > > On Thu, May 9, 2024 at 4:14 PM Chris Egerton
>  >> >
> >> > > wrote:
> >> > >
> >> > > > After doing a brief survey of the SMTs that ship with Connect, it
> >> seems
> >> > > > like these would also benefit:
> >> > > >
> >> > > > - HeaderFrom, which populates record headers with subfields of
> >> > > keys/values
> >> > > > [1]
> >> > > > - Cast, which performs type transformation on subfields of
> >> keys/values
> >> > > [2]
> >> > > > - SetSchemaMetadata, which (when the record key/value is a struct)
> >> > copies
> >> > > > fields from the input struct to the output struct (which uses a
> >> > different
> >> > > > schema) [3]
> >> > > > - TimestampConverter, which does similar input/output field
> copying
> >> to
> >> > > > SetSchemaMetadata [4]
> >> > > > - ReplaceField, which does similar input/output field copying to
> >> > > > SetSchemaMetadata and TimestampConverter
> >> > > >
> >> > > > [1] -
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/apache/kafka/blob/f4fdaa702a2e718bdb44b9c5fec254f32a33f0d8/connect/transforms/src/main/java/org/apache/kafka/connect/transforms/HeaderFrom.java#L143
> >> > > > [2] -
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/apache/kafka/blob/f4fdaa702a2e718bdb44b9c5fec254f32a33f0d8/connect/transforms/src/main/java/org/apache/kafka/connect/transforms/Cast.java#L178
> >> > > > [3] -
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/apache/kafka/blob/f4fdaa702a2e718bdb44b9c5fec254f32a33f0d8/connect/transforms/src/main/java/org/apache/kafka/connect/transforms/SetSchemaMetadata.java#L174
> >> > > > [4] -
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/apache/kafka/blob/2a5efe4a334611fc7c15f76b322482bad0942db0/connect/transforms/src/main/java/org/apache/kafka/connect/transforms/TimestampConverter.java#L420
> >> > > > [5] -
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/apache/kafka/blob/f4fdaa702a2e718bdb44b9c5fec254f32a33f0d8/connect/transforms/src/main/java/org/apache/kafka/connect/transforms/ReplaceField.java#L183
> >> > > >
> >> > > > On Thu, May 9, 2024 at 3:28 AM Mario Fiore Vitale <
> >> mvit...@redhat.com>
> >> > > > wrote:
> >> > > >
> >> > > > > Hi Chris,
> >> > > > >
> >> > > > > > Wouldn't ValueToKey [1] be app

Re: KIP-1040: Improve handling of nullable values in InsertField/ExtractField transformations

[Mario Fiore Vitale]

Yes, I agree. Unfortunately due to the issue of the creation of a new
account for the WIKI, I asked Mickael Maison to create the KIP for me.

I'll ask him to update the KIP. Do you have other alternatives?

Thanks,
Mario.

On Fri, May 10, 2024 at 3:40 PM Chris Egerton 
wrote:

> Yes, I think we should just do one KIP for all the SMTs. You don't have to
> implement everything all at once or by yourself, but I don't see why we
> should require one or more follow-up KIPs to apply the exact same changes
> to the SMTs we missed the first time.
>
> On Fri, May 10, 2024 at 5:20 AM Mario Fiore Vitale 
> wrote:
>
> > Hi Chris,
> >
> > Thanks for the survey. Do you think I need to update the KIP to put all
> of
> > these?
> >
> > On Thu, May 9, 2024 at 4:14 PM Chris Egerton 
> > wrote:
> >
> > > After doing a brief survey of the SMTs that ship with Connect, it seems
> > > like these would also benefit:
> > >
> > > - HeaderFrom, which populates record headers with subfields of
> > keys/values
> > > [1]
> > > - Cast, which performs type transformation on subfields of keys/values
> > [2]
> > > - SetSchemaMetadata, which (when the record key/value is a struct)
> copies
> > > fields from the input struct to the output struct (which uses a
> different
> > > schema) [3]
> > > - TimestampConverter, which does similar input/output field copying to
> > > SetSchemaMetadata [4]
> > > - ReplaceField, which does similar input/output field copying to
> > > SetSchemaMetadata and TimestampConverter
> > >
> > > [1] -
> > >
> > >
> >
> https://github.com/apache/kafka/blob/f4fdaa702a2e718bdb44b9c5fec254f32a33f0d8/connect/transforms/src/main/java/org/apache/kafka/connect/transforms/HeaderFrom.java#L143
> > > [2] -
> > >
> > >
> >
> https://github.com/apache/kafka/blob/f4fdaa702a2e718bdb44b9c5fec254f32a33f0d8/connect/transforms/src/main/java/org/apache/kafka/connect/transforms/Cast.java#L178
> > > [3] -
> > >
> > >
> >
> https://github.com/apache/kafka/blob/f4fdaa702a2e718bdb44b9c5fec254f32a33f0d8/connect/transforms/src/main/java/org/apache/kafka/connect/transforms/SetSchemaMetadata.java#L174
> > > [4] -
> > >
> > >
> >
> https://github.com/apache/kafka/blob/2a5efe4a334611fc7c15f76b322482bad0942db0/connect/transforms/src/main/java/org/apache/kafka/connect/transforms/TimestampConverter.java#L420
> > > [5] -
> > >
> > >
> >
> https://github.com/apache/kafka/blob/f4fdaa702a2e718bdb44b9c5fec254f32a33f0d8/connect/transforms/src/main/java/org/apache/kafka/connect/transforms/ReplaceField.java#L183
> > >
> > > On Thu, May 9, 2024 at 3:28 AM Mario Fiore Vitale 
> > > wrote:
> > >
> > > > Hi Chris,
> > > >
> > > > > Wouldn't ValueToKey [1] be applicable as well, for example?
> > > > Yes, also that one can be affected.
> > > >
> > > > On Wed, May 8, 2024 at 5:59 PM Chris Egerton  >
> > > > wrote:
> > > >
> > > > > Wait, just one more thing--are there any other SMTs that could
> > benefit
> > > > from
> > > > > this? Wouldn't ValueToKey [1] be applicable as well, for example?
> > > > >
> > > > > [1] -
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/kafka/blob/2a5efe4a334611fc7c15f76b322482bad0942db0/connect/transforms/src/main/java/org/apache/kafka/connect/transforms/ValueToKey.java#L106
> > > > >
> > > > > On Wed, May 8, 2024 at 11:46 AM Chris Egerton 
> > wrote:
> > > > >
> > > > > > Hi Mario,
> > > > > >
> > > > > > I think we could have something like `copy` and
> > `copyWithoutDefaults`
> > > > to
> > > > > > get around that, but now that you bring up compatibility, I think
> > > it's
> > > > > best
> > > > > > to hold off on this. I'm forced to recall that anything we add to
> > the
> > > > > > Connect API may be used by plugin developers who write for the
> > > bleeding
> > > > > > edge of the Connect runtime, but deployed by users who are
> running
> > on
> > > > > > (possibly much) older versions. In that scenario, any use of new
> > > Struct
> > > > > > methods would cause issues at runtime caused by compatibility
> > clashes
> > > > > > between the

Re: KIP-1040: Improve handling of nullable values in InsertField/ExtractField transformations

[Mario Fiore Vitale]

Hi Chris,

Thanks for the survey. Do you think I need to update the KIP to put all of
these?

On Thu, May 9, 2024 at 4:14 PM Chris Egerton 
wrote:

> After doing a brief survey of the SMTs that ship with Connect, it seems
> like these would also benefit:
>
> - HeaderFrom, which populates record headers with subfields of keys/values
> [1]
> - Cast, which performs type transformation on subfields of keys/values [2]
> - SetSchemaMetadata, which (when the record key/value is a struct) copies
> fields from the input struct to the output struct (which uses a different
> schema) [3]
> - TimestampConverter, which does similar input/output field copying to
> SetSchemaMetadata [4]
> - ReplaceField, which does similar input/output field copying to
> SetSchemaMetadata and TimestampConverter
>
> [1] -
>
> https://github.com/apache/kafka/blob/f4fdaa702a2e718bdb44b9c5fec254f32a33f0d8/connect/transforms/src/main/java/org/apache/kafka/connect/transforms/HeaderFrom.java#L143
> [2] -
>
> https://github.com/apache/kafka/blob/f4fdaa702a2e718bdb44b9c5fec254f32a33f0d8/connect/transforms/src/main/java/org/apache/kafka/connect/transforms/Cast.java#L178
> [3] -
>
> https://github.com/apache/kafka/blob/f4fdaa702a2e718bdb44b9c5fec254f32a33f0d8/connect/transforms/src/main/java/org/apache/kafka/connect/transforms/SetSchemaMetadata.java#L174
> [4] -
>
> https://github.com/apache/kafka/blob/2a5efe4a334611fc7c15f76b322482bad0942db0/connect/transforms/src/main/java/org/apache/kafka/connect/transforms/TimestampConverter.java#L420
> [5] -
>
> https://github.com/apache/kafka/blob/f4fdaa702a2e718bdb44b9c5fec254f32a33f0d8/connect/transforms/src/main/java/org/apache/kafka/connect/transforms/ReplaceField.java#L183
>
> On Thu, May 9, 2024 at 3:28 AM Mario Fiore Vitale 
> wrote:
>
> > Hi Chris,
> >
> > > Wouldn't ValueToKey [1] be applicable as well, for example?
> > Yes, also that one can be affected.
> >
> > On Wed, May 8, 2024 at 5:59 PM Chris Egerton 
> > wrote:
> >
> > > Wait, just one more thing--are there any other SMTs that could benefit
> > from
> > > this? Wouldn't ValueToKey [1] be applicable as well, for example?
> > >
> > > [1] -
> > >
> > >
> >
> https://github.com/apache/kafka/blob/2a5efe4a334611fc7c15f76b322482bad0942db0/connect/transforms/src/main/java/org/apache/kafka/connect/transforms/ValueToKey.java#L106
> > >
> > > On Wed, May 8, 2024 at 11:46 AM Chris Egerton  wrote:
> > >
> > > > Hi Mario,
> > > >
> > > > I think we could have something like `copy` and `copyWithoutDefaults`
> > to
> > > > get around that, but now that you bring up compatibility, I think
> it's
> > > best
> > > > to hold off on this. I'm forced to recall that anything we add to the
> > > > Connect API may be used by plugin developers who write for the
> bleeding
> > > > edge of the Connect runtime, but deployed by users who are running on
> > > > (possibly much) older versions. In that scenario, any use of new
> Struct
> > > > methods would cause issues at runtime caused by compatibility clashes
> > > > between the newer API that the plugin was written for, and the older
> > API
> > > > that's provided by the runtime it's running on.
> > > >
> > > > Anyway, thanks for humoring me. The KIP looks good to me 
> > > >
> > > > Cheers,
> > > >
> > > > Chris
> > > >
> > > > On Wed, May 8, 2024 at 10:50 AM Mario Fiore Vitale <
> mvit...@redhat.com
> > >
> > > > wrote:
> > > >
> > > >> Hi Chris,
> > > >>
> > > >> Thanks for reviewing this.
> > > >>
> > > >> > It seems like the pattern of "copy the contents of this Struct
> into
> > > >> another
> > > >> one for the purpose of mutation" could be fairly common in user code
> > > bases
> > > >> in addition to the core Connect SMTs. Do you think there's a way to
> > > >> simplify this with, e.g., a Struct.putAll(Struct destination) or
> > > >> Struct.copy(Schema destinationSchema) method?
> > > >>
> > > >> The only concern that I see is backward compatibility. Suppose that
> > you
> > > >> are
> > > >> not using the JsonConvert but another convert that does't support
> the
> > > >> 'replace.null.with.default', when you use the current 'InsertField'
> > smt
> > > >> the null values will be replace by default va

Re: [PATCH v3 2/3] drm/amd/amdgpu: Add ISP driver support

[Mario Limonciello]

On 5/9/2024 16:50, Pratap Nirujogi wrote:

Add the isp driver in amdgpu to support ISP device on the APUs that
supports ISP IP block. ISP hw block is used for camera front-end, pre
and post processing operations.

Signed-off-by: Pratap Nirujogi 

Reviewed-by: Mario Limonciello 

---
Changes made in v3:

   - Remove unwanted header files
   - Remove suprious lines, duplicate error prints
   - Fix multi-line comment style

  drivers/gpu/drm/amd/amdgpu/Makefile   |   3 +
  drivers/gpu/drm/amd/amdgpu/amdgpu.h   |   4 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c   | 278 ++
  drivers/gpu/drm/amd/amdgpu/amdgpu_isp.h   |  51 
  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c   |   3 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c |   5 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h |   1 +
  7 files changed, 345 insertions(+)
  create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c
  create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_isp.h

diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile 
b/drivers/gpu/drm/amd/amdgpu/Makefile
index de7b76327f5b..12ba76025cb7 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -324,4 +324,7 @@ amdgpu-y += $(AMD_DISPLAY_FILES)
  
  endif
  
+# add isp block

+amdgpu-y += amdgpu_isp.o
+
  obj-$(CONFIG_DRM_AMDGPU)+= amdgpu.o
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index eb60d28a3a13..6d7f9ef53269 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -112,6 +112,7 @@
  #include "amdgpu_xcp.h"
  #include "amdgpu_seq64.h"
  #include "amdgpu_reg_state.h"
+#include "amdgpu_isp.h"
  
  #define MAX_GPU_INSTANCE		64
  
@@ -1045,6 +1046,9 @@ struct amdgpu_device {

/* display related functionality */
struct amdgpu_display_manager dm;
  
+	/* isp */

+   struct amdgpu_isp   isp;
+
/* mes */
boolenable_mes;
boolenable_mes_kiq;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c
new file mode 100644
index ..25e88661ac60
--- /dev/null
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c
@@ -0,0 +1,278 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright (C) 2024 Advanced Micro Devices, Inc. All rights reserved.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ */
+
+#include 
+#include 
+
+#include "amdgpu.h"
+#include "amdgpu_isp.h"
+
+#define mmDAGB0_WRCLI5_V4_10x6811C
+#define mmDAGB0_WRCLI9_V4_10x6812C
+#define mmDAGB0_WRCLI10_V4_1   0x68130
+#define mmDAGB0_WRCLI14_V4_1   0x68140
+#define mmDAGB0_WRCLI19_V4_1   0x68154
+#define mmDAGB0_WRCLI20_V4_1   0x68158
+
+static int isp_sw_init(void *handle)
+{
+   struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+
+   adev->isp.parent = adev->dev;
+
+   adev->isp.cgs_device = amdgpu_cgs_create_device(adev);
+   if (!adev->isp.cgs_device)
+   return -EINVAL;
+
+   return 0;
+}
+
+static int isp_sw_fini(void *handle)
+{
+   struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+
+   if (adev->isp.cgs_device)
+   amdgpu_cgs_destroy_device(adev->isp.cgs_device);
+
+   return 0;
+}
+
+/**
+ * isp_hw_init - start and test isp block
+ *
+ * @handle: handle for amdgpu_device pointer
+ *
+ */
+static int isp_hw_init(void *handle)
+{
+   int r;
+   u64 isp_base;
+   struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+   const struct amdgpu_ip_block *ip_block =
+   amdgpu_device_ip_get_ip_block(adev, AMD_IP_BLOCK_TYPE_ISP);
+
+   if (!ip_block)
+   return -EINVAL;
+
+   if (adev->rmmio_size == 

Re: [PATCH v2 3/3] drm/amd/amdgpu: Enable ISP in amdgpu_discovery

[Mario Limonciello]

On 5/9/2024 14:35, Pratap Nirujogi wrote:

Enable ISP for ISP V4.1.0 and V4.1.1 in amdgpu_discovery.

Signed-off-by: Pratap Nirujogi 

Reviewed-by: Mario Limonciello 

---
  drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 22 +++
  1 file changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
index 6586feab8c2c..82d064adaa49 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
@@ -107,6 +107,7 @@
  #include "jpeg_v5_0_0.h"
  
  #include "amdgpu_vpe.h"

+#include "amdgpu_isp.h"
  
  #define FIRMWARE_IP_DISCOVERY "amdgpu/ip_discovery.bin"

  MODULE_FIRMWARE(FIRMWARE_IP_DISCOVERY);
@@ -682,6 +683,10 @@ static void 
amdgpu_discovery_read_from_harvest_table(struct amdgpu_device *adev,
adev->sdma.sdma_mask &=
~(1U << harvest_info->list[i].number_instance);
break;
+   case ISP_HWID:
+   adev->isp.harvest_config |=
+   ~(1U << harvest_info->list[i].number_instance);
+   break;
default:
break;
}
@@ -2303,6 +2308,20 @@ static int 
amdgpu_discovery_set_umsch_mm_ip_blocks(struct amdgpu_device *adev)
return 0;
  }
  
+static int amdgpu_discovery_set_isp_ip_blocks(struct amdgpu_device *adev)

+{
+   switch (amdgpu_ip_version(adev, ISP_HWIP, 0)) {
+   case IP_VERSION(4, 1, 0):
+   case IP_VERSION(4, 1, 1):
+   amdgpu_device_ip_block_add(adev, _ip_block);
+   break;
+   default:
+   break;
+   }
+
+   return 0;
+}
+
  int amdgpu_discovery_set_ip_blocks(struct amdgpu_device *adev)
  {
int r;
@@ -2829,6 +2848,9 @@ int amdgpu_discovery_set_ip_blocks(struct amdgpu_device 
*adev)
if (r)
return r;
  
+	r = amdgpu_discovery_set_isp_ip_blocks(adev);

+   if (r)
+   return r;
return 0;
  }
  

Re: [PATCH v2 1/3] drm/amd/amdgpu: Add ISP support to amdgpu_discovery

[Mario Limonciello]

On 5/9/2024 14:35, Pratap Nirujogi wrote:

ISP hw block is supported in some of the AMD GPU versions, add support
to discover ISP IP in amdgpu_discovery.

Signed-off-by: Pratap Nirujogi 

Reviewed-by: Mario Limonciello 

---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h   | 1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 1 +
  drivers/gpu/drm/amd/include/amd_shared.h  | 1 +
  3 files changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 8bb8b414d511..eb60d28a3a13 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -718,6 +718,7 @@ enum amd_hw_ip_block_type {
XGMI_HWIP,
DCI_HWIP,
PCIE_HWIP,
+   ISP_HWIP,
MAX_HWIP
  };
  
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c

index ece462f8a324..6586feab8c2c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
@@ -226,6 +226,7 @@ static int hw_id_map[MAX_HWIP] = {
[DCI_HWIP]  = DCI_HWID,
[PCIE_HWIP] = PCIE_HWID,
[VPE_HWIP]  = VPE_HWID,
+   [ISP_HWIP]  = ISP_HWID,
  };
  
  static int amdgpu_discovery_read_binary_from_sysmem(struct amdgpu_device *adev, uint8_t *binary)

diff --git a/drivers/gpu/drm/amd/include/amd_shared.h 
b/drivers/gpu/drm/amd/include/amd_shared.h
index 36ee9d3d6d9c..8bc2134cdd6b 100644
--- a/drivers/gpu/drm/amd/include/amd_shared.h
+++ b/drivers/gpu/drm/amd/include/amd_shared.h
@@ -105,6 +105,7 @@ enum amd_ip_block_type {
AMD_IP_BLOCK_TYPE_JPEG,
AMD_IP_BLOCK_TYPE_VPE,
AMD_IP_BLOCK_TYPE_UMSCH_MM,
+   AMD_IP_BLOCK_TYPE_ISP,
AMD_IP_BLOCK_TYPE_NUM,
  };
  

Re: [PATCH v2 2/3] drm/amd/amdgpu: Add ISP driver support

[Mario Limonciello]

On 5/9/2024 14:35, Pratap Nirujogi wrote:

Add the isp driver in amdgpu to support ISP device on the APUs that
supports ISP IP block. ISP hw block is used for camera front-end, pre
and post processing operations.

Signed-off-by: Pratap Nirujogi 
Change-Id: I67ef206e5eca1fe74e495c3262746be495e17d09


Ttypically we strip the Change-Id for things that were in Gerrit originally.


---
Changes in v2:
  - Remove adding IORESOURCE_IRQ
  - Remove noisy info prints
  - Avoid isp version numbers while naming
  - Fix incorrect argument description
  - Replace // with /* */ for comemnts

  drivers/gpu/drm/amd/amdgpu/Makefile   |   3 +
  drivers/gpu/drm/amd/amdgpu/amdgpu.h   |   4 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c   | 287 ++
  drivers/gpu/drm/amd/amdgpu/amdgpu_isp.h   |  54 
  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c   |   3 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c |   5 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h |   1 +
  7 files changed, 357 insertions(+)
  create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c
  create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_isp.h

diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile 
b/drivers/gpu/drm/amd/amdgpu/Makefile
index de7b76327f5b..12ba76025cb7 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -324,4 +324,7 @@ amdgpu-y += $(AMD_DISPLAY_FILES)
  
  endif
  
+# add isp block

+amdgpu-y += amdgpu_isp.o
+
  obj-$(CONFIG_DRM_AMDGPU)+= amdgpu.o
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index eb60d28a3a13..6d7f9ef53269 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -112,6 +112,7 @@
  #include "amdgpu_xcp.h"
  #include "amdgpu_seq64.h"
  #include "amdgpu_reg_state.h"
+#include "amdgpu_isp.h"
  
  #define MAX_GPU_INSTANCE		64
  
@@ -1045,6 +1046,9 @@ struct amdgpu_device {

/* display related functionality */
struct amdgpu_display_manager dm;
  
+	/* isp */

+   struct amdgpu_isp   isp;
+
/* mes */
boolenable_mes;
boolenable_mes_kiq;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c
new file mode 100644
index ..c28d90c25b10
--- /dev/null
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c
@@ -0,0 +1,287 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright (C) 2024 Advanced Micro Devices, Inc. All rights reserved.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 


This list of headers should be sorted alphabetically.


+
+#include "amdgpu_smu.h"
+#include "atom.h"
+#include "amdgpu_isp.h"
+#include "smu_internal.h"
+#include "smu_v11_5_ppsmc.h"
+#include "smu_v11_5_pmfw.h"
+
+#define mmDAGB0_WRCLI5_V4_10x6811C
+#define mmDAGB0_WRCLI9_V4_10x6812C
+#define mmDAGB0_WRCLI10_V4_1   0x68130
+#define mmDAGB0_WRCLI14_V4_1   0x68140
+#define mmDAGB0_WRCLI19_V4_1   0x68154
+#define mmDAGB0_WRCLI20_V4_1   0x68158
+
+static int isp_sw_init(void *handle)
+{
+   struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+
+   adev->isp.parent = adev->dev;
+
+   adev->isp.cgs_device = amdgpu_cgs_create_device(adev);
+   if (!adev->isp.cgs_device)
+   return -EINVAL;
+
+   return 0;
+}
+
+static int isp_sw_fini(void *handle)
+{
+   struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+
+   if (adev->isp.cgs_device)
+   amdgpu_cgs_destroy_device(adev->isp.cgs_device);
+
+   return 0;
+}
+
+/**
+ * isp_hw_init - start and test isp block
+ *
+ * @handle: handle for amdgpu_device pointer
+ *
+ */
+static int isp_hw_init(void *handle)
+{
+   int r;
+   u64 isp_base;
+   

Re: [PATCH] drm/mst: Fix NULL pointer dereference at drm_dp_add_payload_part2

[Mario Limonciello]

On 5/9/2024 07:43, Linux regression tracking (Thorsten Leemhuis) wrote:

On 18.04.24 21:43, Harry Wentland wrote:

On 2024-03-07 01:29, Wayne Lin wrote:

[Why]
Commit:
- commit 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload 
allocation/removement")
accidently overwrite the commit
- commit 54d217406afe ("drm: use mgr->dev in drm_dbg_kms in 
drm_dp_add_payload_part2")
which cause regression.

[How]
Recover the original NULL fix and remove the unnecessary input parameter 
'state' for
drm_dp_add_payload_part2().

Fixes: 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload 
allocation/removement")
Reported-by: Leon Weiß 
Link: 
https://lore.kernel.org/r/38c253ea42072cc825dc969ac4e6b9b600371cc8.ca...@ruhr-uni-bochum.de/
Cc: ly...@redhat.com
Cc: imre.d...@intel.com
Cc: sta...@vger.kernel.org
Cc: regressi...@lists.linux.dev
Signed-off-by: Wayne Lin 


I haven't been deep in MST code in a while but this all looks
pretty straightforward and good.

Reviewed-by: Harry Wentland 


Hmmm, that was three weeks ago, but it seems since then nothing happened
to fix the linked regression through this or some other patch. Is there
a reason? The build failure report from the CI maybe?


It touches files outside of amd but only has an ack from AMD.  I think 
we /probably/ want an ack from i915 and nouveau to take it through.




Wayne Lin, do you know what's up?

Ciao, Thorsten


---
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
  drivers/gpu/drm/display/drm_dp_mst_topology.c | 4 +---
  drivers/gpu/drm/i915/display/intel_dp_mst.c   | 2 +-
  drivers/gpu/drm/nouveau/dispnv50/disp.c   | 2 +-
  include/drm/display/drm_dp_mst_helper.h   | 1 -
  5 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index c27063305a13..2c36f3d00ca2 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -363,7 +363,7 @@ void dm_helpers_dp_mst_send_payload_allocation(
mst_state = to_drm_dp_mst_topology_state(mst_mgr->base.state);
new_payload = drm_atomic_get_mst_payload_state(mst_state, 
aconnector->mst_output_port);
  
-	ret = drm_dp_add_payload_part2(mst_mgr, mst_state->base.state, new_payload);

+   ret = drm_dp_add_payload_part2(mst_mgr, new_payload);
  
  	if (ret) {

amdgpu_dm_set_mst_status(>mst_status,
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 03d528209426..95fd18f24e94 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3421,7 +3421,6 @@ EXPORT_SYMBOL(drm_dp_remove_payload_part2);
  /**
   * drm_dp_add_payload_part2() - Execute payload update part 2
   * @mgr: Manager to use.
- * @state: The global atomic state
   * @payload: The payload to update
   *
   * If @payload was successfully assigned a starting time slot by 
drm_dp_add_payload_part1(), this
@@ -3430,14 +3429,13 @@ EXPORT_SYMBOL(drm_dp_remove_payload_part2);
   * Returns: 0 on success, negative error code on failure.
   */
  int drm_dp_add_payload_part2(struct drm_dp_mst_topology_mgr *mgr,
-struct drm_atomic_state *state,
 struct drm_dp_mst_atomic_payload *payload)
  {
int ret = 0;
  
  	/* Skip failed payloads */

if (payload->payload_allocation_status != 
DRM_DP_MST_PAYLOAD_ALLOCATION_DFP) {
-   drm_dbg_kms(state->dev, "Part 1 of payload creation for %s failed, 
skipping part 2\n",
+   drm_dbg_kms(mgr->dev, "Part 1 of payload creation for %s failed, 
skipping part 2\n",
payload->port->connector->name);
return -EIO;
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 53aec023ce92..2fba66aec038 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -1160,7 +1160,7 @@ static void intel_mst_enable_dp(struct intel_atomic_state 
*state,
if (first_mst_stream)
intel_ddi_wait_for_fec_status(encoder, pipe_config, true);
  
-	drm_dp_add_payload_part2(_dp->mst_mgr, >base,

+   drm_dp_add_payload_part2(_dp->mst_mgr,
 drm_atomic_get_mst_payload_state(mst_state, 
connector->port));
  
  	if (DISPLAY_VER(dev_priv) >= 12)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 0c3d88ad0b0e..88728a0b2c25 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -915,7 +915,7 @@ nv50_msto_cleanup(struct drm_atomic_state *state,
msto->disabled = false;
drm_dp_remove_payload_part2(mgr, new_mst_state, 

Re: [PATCH] drm/mst: Fix NULL pointer dereference at drm_dp_add_payload_part2

[Mario Limonciello]

On 5/9/2024 07:43, Linux regression tracking (Thorsten Leemhuis) wrote:

On 18.04.24 21:43, Harry Wentland wrote:

On 2024-03-07 01:29, Wayne Lin wrote:

[Why]
Commit:
- commit 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload 
allocation/removement")
accidently overwrite the commit
- commit 54d217406afe ("drm: use mgr->dev in drm_dbg_kms in 
drm_dp_add_payload_part2")
which cause regression.

[How]
Recover the original NULL fix and remove the unnecessary input parameter 
'state' for
drm_dp_add_payload_part2().

Fixes: 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload 
allocation/removement")
Reported-by: Leon Weiß 
Link: 
https://lore.kernel.org/r/38c253ea42072cc825dc969ac4e6b9b600371cc8.ca...@ruhr-uni-bochum.de/
Cc: ly...@redhat.com
Cc: imre.d...@intel.com
Cc: sta...@vger.kernel.org
Cc: regressi...@lists.linux.dev
Signed-off-by: Wayne Lin 


I haven't been deep in MST code in a while but this all looks
pretty straightforward and good.

Reviewed-by: Harry Wentland 


Hmmm, that was three weeks ago, but it seems since then nothing happened
to fix the linked regression through this or some other patch. Is there
a reason? The build failure report from the CI maybe?


It touches files outside of amd but only has an ack from AMD.  I think 
we /probably/ want an ack from i915 and nouveau to take it through.




Wayne Lin, do you know what's up?

Ciao, Thorsten


---
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
  drivers/gpu/drm/display/drm_dp_mst_topology.c | 4 +---
  drivers/gpu/drm/i915/display/intel_dp_mst.c   | 2 +-
  drivers/gpu/drm/nouveau/dispnv50/disp.c   | 2 +-
  include/drm/display/drm_dp_mst_helper.h   | 1 -
  5 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index c27063305a13..2c36f3d00ca2 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -363,7 +363,7 @@ void dm_helpers_dp_mst_send_payload_allocation(
mst_state = to_drm_dp_mst_topology_state(mst_mgr->base.state);
new_payload = drm_atomic_get_mst_payload_state(mst_state, 
aconnector->mst_output_port);
  
-	ret = drm_dp_add_payload_part2(mst_mgr, mst_state->base.state, new_payload);

+   ret = drm_dp_add_payload_part2(mst_mgr, new_payload);
  
  	if (ret) {

amdgpu_dm_set_mst_status(>mst_status,
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 03d528209426..95fd18f24e94 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3421,7 +3421,6 @@ EXPORT_SYMBOL(drm_dp_remove_payload_part2);
  /**
   * drm_dp_add_payload_part2() - Execute payload update part 2
   * @mgr: Manager to use.
- * @state: The global atomic state
   * @payload: The payload to update
   *
   * If @payload was successfully assigned a starting time slot by 
drm_dp_add_payload_part1(), this
@@ -3430,14 +3429,13 @@ EXPORT_SYMBOL(drm_dp_remove_payload_part2);
   * Returns: 0 on success, negative error code on failure.
   */
  int drm_dp_add_payload_part2(struct drm_dp_mst_topology_mgr *mgr,
-struct drm_atomic_state *state,
 struct drm_dp_mst_atomic_payload *payload)
  {
int ret = 0;
  
  	/* Skip failed payloads */

if (payload->payload_allocation_status != 
DRM_DP_MST_PAYLOAD_ALLOCATION_DFP) {
-   drm_dbg_kms(state->dev, "Part 1 of payload creation for %s failed, 
skipping part 2\n",
+   drm_dbg_kms(mgr->dev, "Part 1 of payload creation for %s failed, 
skipping part 2\n",
payload->port->connector->name);
return -EIO;
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 53aec023ce92..2fba66aec038 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -1160,7 +1160,7 @@ static void intel_mst_enable_dp(struct intel_atomic_state 
*state,
if (first_mst_stream)
intel_ddi_wait_for_fec_status(encoder, pipe_config, true);
  
-	drm_dp_add_payload_part2(_dp->mst_mgr, >base,

+   drm_dp_add_payload_part2(_dp->mst_mgr,
 drm_atomic_get_mst_payload_state(mst_state, 
connector->port));
  
  	if (DISPLAY_VER(dev_priv) >= 12)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 0c3d88ad0b0e..88728a0b2c25 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -915,7 +915,7 @@ nv50_msto_cleanup(struct drm_atomic_state *state,
msto->disabled = false;
drm_dp_remove_payload_part2(mgr, new_mst_state, 

Re: [PATCH] drm/mst: Fix NULL pointer dereference at drm_dp_add_payload_part2

[Mario Limonciello]

On 5/9/2024 07:43, Linux regression tracking (Thorsten Leemhuis) wrote:

On 18.04.24 21:43, Harry Wentland wrote:

On 2024-03-07 01:29, Wayne Lin wrote:

[Why]
Commit:
- commit 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload 
allocation/removement")
accidently overwrite the commit
- commit 54d217406afe ("drm: use mgr->dev in drm_dbg_kms in 
drm_dp_add_payload_part2")
which cause regression.

[How]
Recover the original NULL fix and remove the unnecessary input parameter 
'state' for
drm_dp_add_payload_part2().

Fixes: 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload 
allocation/removement")
Reported-by: Leon Weiß 
Link: 
https://lore.kernel.org/r/38c253ea42072cc825dc969ac4e6b9b600371cc8.ca...@ruhr-uni-bochum.de/
Cc: ly...@redhat.com
Cc: imre.d...@intel.com
Cc: sta...@vger.kernel.org
Cc: regressi...@lists.linux.dev
Signed-off-by: Wayne Lin 


I haven't been deep in MST code in a while but this all looks
pretty straightforward and good.

Reviewed-by: Harry Wentland 


Hmmm, that was three weeks ago, but it seems since then nothing happened
to fix the linked regression through this or some other patch. Is there
a reason? The build failure report from the CI maybe?


It touches files outside of amd but only has an ack from AMD.  I think 
we /probably/ want an ack from i915 and nouveau to take it through.




Wayne Lin, do you know what's up?

Ciao, Thorsten


---
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
  drivers/gpu/drm/display/drm_dp_mst_topology.c | 4 +---
  drivers/gpu/drm/i915/display/intel_dp_mst.c   | 2 +-
  drivers/gpu/drm/nouveau/dispnv50/disp.c   | 2 +-
  include/drm/display/drm_dp_mst_helper.h   | 1 -
  5 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index c27063305a13..2c36f3d00ca2 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -363,7 +363,7 @@ void dm_helpers_dp_mst_send_payload_allocation(
mst_state = to_drm_dp_mst_topology_state(mst_mgr->base.state);
new_payload = drm_atomic_get_mst_payload_state(mst_state, 
aconnector->mst_output_port);
  
-	ret = drm_dp_add_payload_part2(mst_mgr, mst_state->base.state, new_payload);

+   ret = drm_dp_add_payload_part2(mst_mgr, new_payload);
  
  	if (ret) {

amdgpu_dm_set_mst_status(>mst_status,
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 03d528209426..95fd18f24e94 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3421,7 +3421,6 @@ EXPORT_SYMBOL(drm_dp_remove_payload_part2);
  /**
   * drm_dp_add_payload_part2() - Execute payload update part 2
   * @mgr: Manager to use.
- * @state: The global atomic state
   * @payload: The payload to update
   *
   * If @payload was successfully assigned a starting time slot by 
drm_dp_add_payload_part1(), this
@@ -3430,14 +3429,13 @@ EXPORT_SYMBOL(drm_dp_remove_payload_part2);
   * Returns: 0 on success, negative error code on failure.
   */
  int drm_dp_add_payload_part2(struct drm_dp_mst_topology_mgr *mgr,
-struct drm_atomic_state *state,
 struct drm_dp_mst_atomic_payload *payload)
  {
int ret = 0;
  
  	/* Skip failed payloads */

if (payload->payload_allocation_status != 
DRM_DP_MST_PAYLOAD_ALLOCATION_DFP) {
-   drm_dbg_kms(state->dev, "Part 1 of payload creation for %s failed, 
skipping part 2\n",
+   drm_dbg_kms(mgr->dev, "Part 1 of payload creation for %s failed, 
skipping part 2\n",
payload->port->connector->name);
return -EIO;
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 53aec023ce92..2fba66aec038 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -1160,7 +1160,7 @@ static void intel_mst_enable_dp(struct intel_atomic_state 
*state,
if (first_mst_stream)
intel_ddi_wait_for_fec_status(encoder, pipe_config, true);
  
-	drm_dp_add_payload_part2(_dp->mst_mgr, >base,

+   drm_dp_add_payload_part2(_dp->mst_mgr,
 drm_atomic_get_mst_payload_state(mst_state, 
connector->port));
  
  	if (DISPLAY_VER(dev_priv) >= 12)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 0c3d88ad0b0e..88728a0b2c25 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -915,7 +915,7 @@ nv50_msto_cleanup(struct drm_atomic_state *state,
msto->disabled = false;
drm_dp_remove_payload_part2(mgr, new_mst_state, 

RE: [PATCH 2/3] drm/amd/amdgpu: Add ISP driver support

[Limonciello, Mario]

[AMD Official Use Only - General]

Thanks, I'll take a look.

In general make sure that you prefix new versions with "PATCH v2", "PATCH v3" 
etc
and include a changelog below the cutlist or in the cover letter.

There is a --subject-prefix argument for git send-email you can use.

It's okay this time, but if you end up spinning again for a v3 do that.

> -Original Message-
> From: Nirujogi, Pratap 
> Sent: Thursday, May 9, 2024 12:19
> To: Limonciello, Mario ; amd-
> g...@lists.freedesktop.org
> Cc: Deucher, Alexander ; Chan, Benjamin
> (Koon Pan) ; Li, King ; Du,
> Bin 
> Subject: RE: [PATCH 2/3] drm/amd/amdgpu: Add ISP driver support
>
> [AMD Official Use Only - General]
>
> Hi Mario,
>
> I addressed the comments, submitted the updated patchset, please review
> and let us know your comments.
>
> Thanks,
> Pratap
>
> -Original Message-
> From: Limonciello, Mario 
> Sent: Thursday, May 9, 2024 10:15 AM
> To: Nirujogi, Pratap ; amd-
> g...@lists.freedesktop.org
> Cc: Deucher, Alexander ; Chan, Benjamin
> (Koon Pan) ; Li, King ; Du,
> Bin 
> Subject: Re: [PATCH 2/3] drm/amd/amdgpu: Add ISP driver support
>
> On 5/8/2024 09:50, Pratap Nirujogi wrote:
> > Add the isp driver in amdgpu to support ISP device on the APUs that
> > supports ISP IP block. ISP hw block is used for camera front-end, pre
> > and post processing operations.
> >
> > Signed-off-by: Pratap Nirujogi 
> > ---
> >   drivers/gpu/drm/amd/amdgpu/Makefile   |   3 +
> >   drivers/gpu/drm/amd/amdgpu/amdgpu.h   |   4 +
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c   | 298
> ++
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_isp.h   |  54 
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c   |   3 +
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c |   5 +
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h |   1 +
> >   7 files changed, 368 insertions(+)
> >   create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c
> >   create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_isp.h
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
> > b/drivers/gpu/drm/amd/amdgpu/Makefile
> > index de7b76327f5b..12ba76025cb7 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/Makefile
> > +++ b/drivers/gpu/drm/amd/amdgpu/Makefile
> > @@ -324,4 +324,7 @@ amdgpu-y += $(AMD_DISPLAY_FILES)
> >
> >   endif
> >
> > +# add isp block
> > +amdgpu-y += amdgpu_isp.o
> > +
> >   obj-$(CONFIG_DRM_AMDGPU)+= amdgpu.o
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > index eb60d28a3a13..6d7f9ef53269 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > @@ -112,6 +112,7 @@
> >   #include "amdgpu_xcp.h"
> >   #include "amdgpu_seq64.h"
> >   #include "amdgpu_reg_state.h"
> > +#include "amdgpu_isp.h"
> >
> >   #define MAX_GPU_INSTANCE64
> >
> > @@ -1045,6 +1046,9 @@ struct amdgpu_device {
> >   /* display related functionality */
> >   struct amdgpu_display_manager dm;
> >
> > + /* isp */
> > + struct amdgpu_isp   isp;
> > +
> >   /* mes */
> >   boolenable_mes;
> >   boolenable_mes_kiq;
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c
> > new file mode 100644
> > index ..dcc01a339a43
> > --- /dev/null
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c
> > @@ -0,0 +1,298 @@
> > +/* SPDX-License-Identifier: MIT */
> > +/*
> > + * Copyright (C) 2024 Advanced Micro Devices, Inc. All rights reserved.
> > + * All Rights Reserved.
> > + *
> > + * Permission is hereby granted, free of charge, to any person
> > +obtaining a
> > + * copy of this software and associated documentation files (the
> > + * "Software"), to deal in the Software without restriction,
> > +including
> > + * without limitation the rights to use, copy, modify, merge,
> > +publish,
> > + * distribute, sub license, and/or sell copies of the Software, and
> > +to
> > + * permit persons to whom the Software is furnished to do so, subject
> > +to
> > + * the following conditions:
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
> KIND,
> > +EXPRESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> > +MERCHANTABILITY,
> > +

[PATCH] drm/amd/display: Don't register panel_power_savings on OLED panels

[Mario Limonciello]

OLED panels don't support the ABM, they shouldn't offer the
panel_power_savings attribute to the user. Check whether aux BL
control support was enabled to decide whether to offer it.

Reported-by: Gergo Koteles 
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3359
Signed-off-by: Mario Limonciello 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 ---
 1 file changed, 25 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 3054bf79fc99..ce2ec857b8a6 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6532,12 +6532,34 @@ static const struct attribute_group amdgpu_group = {
.attrs = amdgpu_attrs
 };
 
+static bool
+amdgpu_dm_should_create_sysfs(struct amdgpu_dm_connector *amdgpu_dm_connector)
+{
+   if (amdgpu_dm_abm_level >= 0)
+   return false;
+
+   if (amdgpu_dm_connector->base.connector_type != DRM_MODE_CONNECTOR_eDP)
+   return false;
+
+   /* check for OLED panels */
+   if (amdgpu_dm_connector->bl_idx >= 0) {
+   struct drm_device *drm = amdgpu_dm_connector->base.dev;
+   struct amdgpu_display_manager *dm = _to_adev(drm)->dm;
+   struct amdgpu_dm_backlight_caps *caps;
+
+   caps = >backlight_caps[amdgpu_dm_connector->bl_idx];
+   if (caps->aux_support)
+   return false;
+   }
+
+   return true;
+}
+
 static void amdgpu_dm_connector_unregister(struct drm_connector *connector)
 {
struct amdgpu_dm_connector *amdgpu_dm_connector = 
to_amdgpu_dm_connector(connector);
 
-   if (connector->connector_type == DRM_MODE_CONNECTOR_eDP &&
-   amdgpu_dm_abm_level < 0)
+   if (amdgpu_dm_should_create_sysfs(amdgpu_dm_connector))
sysfs_remove_group(>kdev->kobj, _group);
 
drm_dp_aux_unregister(_dm_connector->dm_dp_aux.aux);
@@ -6644,8 +,7 @@ amdgpu_dm_connector_late_register(struct drm_connector 
*connector)
to_amdgpu_dm_connector(connector);
int r;
 
-   if (connector->connector_type == DRM_MODE_CONNECTOR_eDP &&
-   amdgpu_dm_abm_level < 0) {
+   if (amdgpu_dm_should_create_sysfs(amdgpu_dm_connector)) {
r = sysfs_create_group(>kdev->kobj,
   _group);
if (r)
-- 
2.43.0

Re: [PATCH 2/3] drm/amd/amdgpu: Add ISP driver support

[Mario Limonciello]

On 5/8/2024 09:50, Pratap Nirujogi wrote:

Add the isp driver in amdgpu to support ISP device on the APUs that
supports ISP IP block. ISP hw block is used for camera front-end, pre
and post processing operations.

Signed-off-by: Pratap Nirujogi 
---
  drivers/gpu/drm/amd/amdgpu/Makefile   |   3 +
  drivers/gpu/drm/amd/amdgpu/amdgpu.h   |   4 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c   | 298 ++
  drivers/gpu/drm/amd/amdgpu/amdgpu_isp.h   |  54 
  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c   |   3 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c |   5 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h |   1 +
  7 files changed, 368 insertions(+)
  create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c
  create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_isp.h

diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile 
b/drivers/gpu/drm/amd/amdgpu/Makefile
index de7b76327f5b..12ba76025cb7 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -324,4 +324,7 @@ amdgpu-y += $(AMD_DISPLAY_FILES)
  
  endif
  
+# add isp block

+amdgpu-y += amdgpu_isp.o
+
  obj-$(CONFIG_DRM_AMDGPU)+= amdgpu.o
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index eb60d28a3a13..6d7f9ef53269 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -112,6 +112,7 @@
  #include "amdgpu_xcp.h"
  #include "amdgpu_seq64.h"
  #include "amdgpu_reg_state.h"
+#include "amdgpu_isp.h"
  
  #define MAX_GPU_INSTANCE		64
  
@@ -1045,6 +1046,9 @@ struct amdgpu_device {

/* display related functionality */
struct amdgpu_display_manager dm;
  
+	/* isp */

+   struct amdgpu_isp   isp;
+
/* mes */
boolenable_mes;
boolenable_mes_kiq;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c
new file mode 100644
index ..dcc01a339a43
--- /dev/null
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c
@@ -0,0 +1,298 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright (C) 2024 Advanced Micro Devices, Inc. All rights reserved.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "amdgpu_smu.h"
+#include "atom.h"
+#include "amdgpu_isp.h"
+#include "smu_internal.h"
+#include "smu_v11_5_ppsmc.h"
+#include "smu_v11_5_pmfw.h"
+
+#define mmDAGB0_WRCLI5_V4_10x6811C
+#define mmDAGB0_WRCLI9_V4_10x6812C
+#define mmDAGB0_WRCLI10_V4_1   0x68130
+#define mmDAGB0_WRCLI14_V4_1   0x68140
+#define mmDAGB0_WRCLI19_V4_1   0x68154
+#define mmDAGB0_WRCLI20_V4_1   0x68158
+
+static int isp_sw_init(void *handle)
+{
+   struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+
+   pr_info("%s called adev %p\n", __func__, adev);


This and other pr_info() statements are too noisy.  I guess they were 
bringup code that should be torn out now.



+
+   adev->isp.parent = adev->dev;
+
+   adev->isp.cgs_device = amdgpu_cgs_create_device(adev);
+   if (!adev->isp.cgs_device)
+   return -EINVAL;
+
+   return 0;
+}
+
+static int isp_sw_fini(void *handle)
+{
+   struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+
+   pr_info("%s called adev %p\n", __func__, adev);
+
+   if (adev->isp.cgs_device)
+   amdgpu_cgs_destroy_device(adev->isp.cgs_device);
+
+   return 0;
+}
+
+/**
+ * isp_hw_init - start and test isp block
+ *
+ * @adev: amdgpu_device pointer


Wrong argument for the function.


+ *
+ */
+static int isp_hw_init(void *handle)
+{
+   int r;
+   u64 isp_base;
+   struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+
+   const struct amdgpu_ip_block *ip_block =
+   

Re: [OT] Scelta della distro in ambiente lavorativo

[Mario Vittorio Guenzi]

Il 08/05/24 11:53, Alessandro Baggi ha scritto:



Come viene visto l'utilizzo di una distribuzione senza supporto 
tecnico nel vostro ambiente lavorativo?


Buongiorno a tutti,

credo dipenda da diversi fattori, il principale e' la dimensione 
dell'azienda,  noi siamo piccoli e io decido che distro usare.
L'assistenza (quando serve) ce la fornisce una piccola azienda di Milano 
con la quale collaboriamo da 25 anni o giu' di li.
Tutto cio' molto difficilmente puo' succedere in azienda di dimensioni 
maggiori o che comunque ha una politica di tipo tutto deve essere 
certificato.


Abbiamo scelto Devuan diversi anni fa per n+1 motivi che sono importanti 
per noi, chi ci supporta non ci ha mai lasciato a piedi, quindi son 
sempre stati soldi investiti intelligentemente.


La mia esperienza se puo' esserti utile

Un cordiale saluto a tutti.


--
 
Mario Vittorio Guenzi

E-mail jcl...@tiscali.it
Si vis pacem, para bellum

Re: KIP-1040: Improve handling of nullable values in InsertField/ExtractField transformations

[Mario Fiore Vitale]

Hi Chris,

> Wouldn't ValueToKey [1] be applicable as well, for example?
Yes, also that one can be affected.

On Wed, May 8, 2024 at 5:59 PM Chris Egerton 
wrote:

> Wait, just one more thing--are there any other SMTs that could benefit from
> this? Wouldn't ValueToKey [1] be applicable as well, for example?
>
> [1] -
>
> https://github.com/apache/kafka/blob/2a5efe4a334611fc7c15f76b322482bad0942db0/connect/transforms/src/main/java/org/apache/kafka/connect/transforms/ValueToKey.java#L106
>
> On Wed, May 8, 2024 at 11:46 AM Chris Egerton  wrote:
>
> > Hi Mario,
> >
> > I think we could have something like `copy` and `copyWithoutDefaults` to
> > get around that, but now that you bring up compatibility, I think it's
> best
> > to hold off on this. I'm forced to recall that anything we add to the
> > Connect API may be used by plugin developers who write for the bleeding
> > edge of the Connect runtime, but deployed by users who are running on
> > (possibly much) older versions. In that scenario, any use of new Struct
> > methods would cause issues at runtime caused by compatibility clashes
> > between the newer API that the plugin was written for, and the older API
> > that's provided by the runtime it's running on.
> >
> > Anyway, thanks for humoring me. The KIP looks good to me 
> >
> > Cheers,
> >
> > Chris
> >
> > On Wed, May 8, 2024 at 10:50 AM Mario Fiore Vitale 
> > wrote:
> >
> >> Hi Chris,
> >>
> >> Thanks for reviewing this.
> >>
> >> > It seems like the pattern of "copy the contents of this Struct into
> >> another
> >> one for the purpose of mutation" could be fairly common in user code
> bases
> >> in addition to the core Connect SMTs. Do you think there's a way to
> >> simplify this with, e.g., a Struct.putAll(Struct destination) or
> >> Struct.copy(Schema destinationSchema) method?
> >>
> >> The only concern that I see is backward compatibility. Suppose that you
> >> are
> >> not using the JsonConvert but another convert that does't support the
> >> 'replace.null.with.default', when you use the current 'InsertField' smt
> >> the null values will be replace by default values. If we replace the
> >> "copy"
> >> logic with a method in the Struct we remove this behavior.
> >>
> >> Isn't it?
> >>
> >> Mario.
> >>
> >> On Wed, May 8, 2024 at 2:14 PM Chris Egerton 
> >> wrote:
> >>
> >> > Hi Mario,
> >> >
> >> > Thanks for the KIP! Looks good overall. One quick thought--it wasn't
> >> > immediately obvious to me why we had to touch on InsertField for this.
> >> It
> >> > looks like the reason is that we use Struct::get [1] to create a clone
> >> of
> >> > the input value [2], instead of Struct::getWithoutDefault [3].
> >> >
> >> > It seems like the pattern of "copy the contents of this Struct into
> >> another
> >> > one for the purpose of mutation" could be fairly common in user code
> >> bases
> >> > in addition to the core Connect SMTs. Do you think there's a way to
> >> > simplify this with, e.g., a Struct.putAll(Struct destination) or
> >> > Struct.copy(Schema destinationSchema) method?
> >> >
> >> > [1] -
> >> >
> >> >
> >>
> https://github.com/apache/kafka/blob/f74f596bc7d35fcea97edcd83244e5d6aee308d2/connect/api/src/main/java/org/apache/kafka/connect/data/Struct.java#L78-L91
> >> > [2] -
> >> >
> >> >
> >>
> https://github.com/apache/kafka/blob/f74f596bc7d35fcea97edcd83244e5d6aee308d2/connect/transforms/src/main/java/org/apache/kafka/connect/transforms/InsertField.java#L179-L183
> >> > [3] -
> >> >
> >> >
> >>
> https://github.com/apache/kafka/blob/f74f596bc7d35fcea97edcd83244e5d6aee308d2/connect/api/src/main/java/org/apache/kafka/connect/data/Struct.java#L93-L101
> >> >
> >> > Cheers,
> >> >
> >> > Chris
> >> >
> >> > On Wed, May 8, 2024 at 3:40 AM Mario Fiore Vitale  >
> >> > wrote:
> >> >
> >> > > Hi All,
> >> > >
> >> > > I have created (through Mickael Maison's account since there was an
> >> issue
> >> > > creating a new one for me) KIP-1040[1] to improve handling of
> nullable
> >> > > values in InsertField/ExtractField transformations, this is requir

[PATCH] drm/amd/display: Drop pixel_clock_mhz

[Mario Limonciello]

The pixel_clock_mhz property is populated in amdgpu_dm when Freesync is setup,
but it is not used anywhere in amdgpu_dm. Remove the dead code.

Cc: chiahsuan.ch...@amd.com
Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 1 -
 2 files changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index f80213b7e9f7..3054bf79fc99 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -11274,7 +11274,6 @@ void amdgpu_dm_update_freesync_caps(struct 
drm_connector *connector,
 
amdgpu_dm_connector->min_vfreq = 0;
amdgpu_dm_connector->max_vfreq = 0;
-   amdgpu_dm_connector->pixel_clock_mhz = 0;
connector->display_info.monitor_range.min_vfreq = 0;
connector->display_info.monitor_range.max_vfreq = 0;
freesync_capable = false;
@@ -11338,8 +11337,6 @@ void amdgpu_dm_update_freesync_caps(struct 
drm_connector *connector,

connector->display_info.monitor_range.min_vfreq;
amdgpu_dm_connector->max_vfreq =

connector->display_info.monitor_range.max_vfreq;
-   amdgpu_dm_connector->pixel_clock_mhz =
-   range->pixel_clock_mhz * 10;
 
break;
}
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index 09519b7abf67..67647bb5999b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -678,7 +678,6 @@ struct amdgpu_dm_connector {
 * value is set to zero when there is no FreeSync support.
 */
int max_vfreq ;
-   int pixel_clock_mhz;
 
/* Audio instance - protected by audio_lock. */
int audio_inst;
-- 
2.43.0

[PATCH v2] drm/amd/display: Enable colorspace property for MST connectors

[Mario Limonciello]

MST colorspace property support was disabled due to a series of warnings
that came up when the device was plugged in since the properties weren't
made at device creation. Create the properties in advance instead.

Suggested-by: Ville Syrjälä 
Fixes: 69a959610229 ("drm/amd/display: Temporary Disable MST DP Colorspace 
Property").
Reported-and-tested-by: Tyler Schneider 
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3353
Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 941e96f100f4..12b036d511d0 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -613,6 +613,9 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr *mgr,
>base,
dev->mode_config.tile_property,
0);
+   connector->colorspace_property = master->base.colorspace_property;
+   if (connector->colorspace_property)
+   drm_connector_attach_colorspace_property(connector);
 
drm_connector_set_path_property(connector, pathprop);
 
-- 
2.43.0

[PATCH v2] drm/amd/display: Enable colorspace property for MST connectors

[Mario Limonciello]

MST colorspace property support was disabled due to a series of warnings
that came up when the device was plugged in since the properties weren't
made at device creation. Create the properties in advance instead.

Suggested-by: Ville Syrjälä 
Fixes: 69a959610229 ("drm/amd/display: Temporary Disable MST DP Colorspace 
Property").
Reported-and-tested-by: Tyler Schneider 
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3353
Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 941e96f100f4..12b036d511d0 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -613,6 +613,9 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr *mgr,
>base,
dev->mode_config.tile_property,
0);
+   connector->colorspace_property = master->base.colorspace_property;
+   if (connector->colorspace_property)
+   drm_connector_attach_colorspace_property(connector);
 
drm_connector_set_path_property(connector, pathprop);
 
-- 
2.43.0

[PATCH 2/2] Revert "drm/amd/display: Temporary Disable MST DP Colorspace Property"

[Mario Limonciello]

MST colorspace property support was disabled due to a series of warnings
that came up when the device was plugged in.  As those warnings are fixed,
revert commit 69a959610229 ("drm/amd/display: Temporary Disable MST DP
Colorspace Property").

Reported-and-tested-by: Tyler Schneider 
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3353
Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 3054bf79fc99..93e2030f4c17 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7695,7 +7695,7 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
if (connector_type == DRM_MODE_CONNECTOR_HDMIA) {
if 
(!drm_mode_create_hdmi_colorspace_property(>base, 
supported_colorspaces))

drm_connector_attach_colorspace_property(>base);
-   } else if ((connector_type == DRM_MODE_CONNECTOR_DisplayPort && 
!aconnector->mst_root) ||
+   } else if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
   connector_type == DRM_MODE_CONNECTOR_eDP) {
if (!drm_mode_create_dp_colorspace_property(>base, 
supported_colorspaces))

drm_connector_attach_colorspace_property(>base);
-- 
2.43.0

[PATCH 2/2] Revert "drm/amd/display: Temporary Disable MST DP Colorspace Property"

[Mario Limonciello]

MST colorspace property support was disabled due to a series of warnings
that came up when the device was plugged in.  As those warnings are fixed,
revert commit 69a959610229 ("drm/amd/display: Temporary Disable MST DP
Colorspace Property").

Reported-and-tested-by: Tyler Schneider 
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3353
Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 3054bf79fc99..93e2030f4c17 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7695,7 +7695,7 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
if (connector_type == DRM_MODE_CONNECTOR_HDMIA) {
if 
(!drm_mode_create_hdmi_colorspace_property(>base, 
supported_colorspaces))

drm_connector_attach_colorspace_property(>base);
-   } else if ((connector_type == DRM_MODE_CONNECTOR_DisplayPort && 
!aconnector->mst_root) ||
+   } else if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
   connector_type == DRM_MODE_CONNECTOR_eDP) {
if (!drm_mode_create_dp_colorspace_property(>base, 
supported_colorspaces))

drm_connector_attach_colorspace_property(>base);
-- 
2.43.0

[PATCH 1/2] drm: Allow mode object properties to be added after a device is registered

[Mario Limonciello]

When the colorspace property is registered on MST devices there is
no `obj_free_cb` callback for it in drm_mode_object_add().

Don't show a warning trace for __drm_mode_object_add() calls for
DRM_MODE_OBJECT_PROPERTY.

Reported-and-tested-by: Tyler Schneider 
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3353
Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/drm_mode_object.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_mode_object.c 
b/drivers/gpu/drm/drm_mode_object.c
index 0e8355063eee..b077547a2db4 100644
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -42,7 +42,7 @@ int __drm_mode_object_add(struct drm_device *dev, struct 
drm_mode_object *obj,
 {
int ret;
 
-   WARN_ON(!dev->driver->load && dev->registered && !obj_free_cb);
+   WARN_ON(!dev->driver->load && dev->registered && !obj_free_cb && 
obj_type != DRM_MODE_OBJECT_PROPERTY);
 
mutex_lock(>mode_config.idr_mutex);
ret = idr_alloc(>mode_config.object_idr, register_obj ? obj : NULL,
-- 
2.43.0

[PATCH 1/2] drm: Allow mode object properties to be added after a device is registered

[Mario Limonciello]

When the colorspace property is registered on MST devices there is
no `obj_free_cb` callback for it in drm_mode_object_add().

Don't show a warning trace for __drm_mode_object_add() calls for
DRM_MODE_OBJECT_PROPERTY.

Reported-and-tested-by: Tyler Schneider 
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3353
Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/drm_mode_object.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_mode_object.c 
b/drivers/gpu/drm/drm_mode_object.c
index 0e8355063eee..b077547a2db4 100644
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -42,7 +42,7 @@ int __drm_mode_object_add(struct drm_device *dev, struct 
drm_mode_object *obj,
 {
int ret;
 
-   WARN_ON(!dev->driver->load && dev->registered && !obj_free_cb);
+   WARN_ON(!dev->driver->load && dev->registered && !obj_free_cb && 
obj_type != DRM_MODE_OBJECT_PROPERTY);
 
mutex_lock(>mode_config.idr_mutex);
ret = idr_alloc(>mode_config.object_idr, register_obj ? obj : NULL,
-- 
2.43.0

Re: KIP-1040: Improve handling of nullable values in InsertField/ExtractField transformations

[Mario Fiore Vitale]

Hi Chris,

Thanks for reviewing this.

> It seems like the pattern of "copy the contents of this Struct into
another
one for the purpose of mutation" could be fairly common in user code bases
in addition to the core Connect SMTs. Do you think there's a way to
simplify this with, e.g., a Struct.putAll(Struct destination) or
Struct.copy(Schema destinationSchema) method?

The only concern that I see is backward compatibility. Suppose that you are
not using the JsonConvert but another convert that does't support the
'replace.null.with.default', when you use the current 'InsertField' smt
the null values will be replace by default values. If we replace the "copy"
logic with a method in the Struct we remove this behavior.

Isn't it?

Mario.

On Wed, May 8, 2024 at 2:14 PM Chris Egerton 
wrote:

> Hi Mario,
>
> Thanks for the KIP! Looks good overall. One quick thought--it wasn't
> immediately obvious to me why we had to touch on InsertField for this. It
> looks like the reason is that we use Struct::get [1] to create a clone of
> the input value [2], instead of Struct::getWithoutDefault [3].
>
> It seems like the pattern of "copy the contents of this Struct into another
> one for the purpose of mutation" could be fairly common in user code bases
> in addition to the core Connect SMTs. Do you think there's a way to
> simplify this with, e.g., a Struct.putAll(Struct destination) or
> Struct.copy(Schema destinationSchema) method?
>
> [1] -
>
> https://github.com/apache/kafka/blob/f74f596bc7d35fcea97edcd83244e5d6aee308d2/connect/api/src/main/java/org/apache/kafka/connect/data/Struct.java#L78-L91
> [2] -
>
> https://github.com/apache/kafka/blob/f74f596bc7d35fcea97edcd83244e5d6aee308d2/connect/transforms/src/main/java/org/apache/kafka/connect/transforms/InsertField.java#L179-L183
> [3] -
>
> https://github.com/apache/kafka/blob/f74f596bc7d35fcea97edcd83244e5d6aee308d2/connect/api/src/main/java/org/apache/kafka/connect/data/Struct.java#L93-L101
>
> Cheers,
>
> Chris
>
> On Wed, May 8, 2024 at 3:40 AM Mario Fiore Vitale 
> wrote:
>
> > Hi All,
> >
> > I have created (through Mickael Maison's account since there was an issue
> > creating a new one for me) KIP-1040[1] to improve handling of nullable
> > values in InsertField/ExtractField transformations, this is required
> after
> > the introduction of KIP-581[2] that introduced the configuration property
> > *replace.null.with.default* to *JsonConverter* to choose whether to
> replace
> > fields that have a default value and that are null to the default value.
> >
> > [1]
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=303794677
> > [2]
> >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-581%3A+Value+of+optional+null+field+which+has+default+value
> >
> > Feedback and suggestions are welcome.
> >
> > Regards,
> > Mario.
> > --
> >
> > Mario Fiore Vitale
> >
> > Senior Software Engineer
> >
> > Red Hat <https://www.redhat.com/>
> > <https://www.redhat.com/>
> >
>


-- 

Mario Fiore Vitale

Senior Software Engineer

Red Hat <https://www.redhat.com/>
<https://www.redhat.com/>

KIP-1040: Improve handling of nullable values in InsertField/ExtractField transformations

[Mario Fiore Vitale]

Hi All,

I have created (through Mickael Maison's account since there was an issue
creating a new one for me) KIP-1040[1] to improve handling of nullable
values in InsertField/ExtractField transformations, this is required after
the introduction of KIP-581[2] that introduced the configuration property
*replace.null.with.default* to *JsonConverter* to choose whether to replace
fields that have a default value and that are null to the default value.

[1]
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=303794677
[2]
https://cwiki.apache.org/confluence/display/KAFKA/KIP-581%3A+Value+of+optional+null+field+which+has+default+value

Feedback and suggestions are welcome.

Regards,
Mario.
-- 

Mario Fiore Vitale

Senior Software Engineer

Red Hat <https://www.redhat.com/>
<https://www.redhat.com/>

Re: [BRLTTY] Braille display unable to type or navigate screen in Ubuntu 22.04

[Mario Lang]

Harry Bell  writes:


[...]

> How can I get my newly set up Ubuntu 24.04 laptop to accept my focus Blue 14
> 5th Gen Braille display as an input device for typing and giving commands to
> navigate the screen? 
> I have installed Ubuntu 24.4 along with Orca and the MATE desktop. I have
> run BRLTTY and now my focus Blue 14 5th Gen Braille display shows in Braille
> what is on the laptop screen. But when I try typing, nothing happens.

Maybe these key bindings help?

* set braille keyboard enabled: Space+Dots138
* set braille keyboard disabled: Space+Dots137
  
> And i have no idea how to navigate the laptop screen.,

Maybe reading the help page for the Focus 14 will help?
http://brltty.app/doc/KeyBindings/brl-fs-focus14.html

-- 
CYa,
  ⡍⠁⠗⠊⠕
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.app
For general information, go to: http://brltty.app/mailman/listinfo/brltty

Re: Favorite configuration and system replication tools?

[Mario Theodoridis]

On 07.05.2024 16:08, Martin Kjær Jørgensen wrote:

Hello,

I was wondering which programs you use for replicating/copying/syncing 
environments/configs on your openbsd systems with between your desktops (home 
or work) and laptops?

Example programs for this could be syncthing, stow, chezmoi, etc.

Do you also maintain installeded/removed packages in some standard way across 
systems so that you have reasonable consistent systems to work on?

All thoughts are welcome.

I've been using etch for the last decade.

https://github.com/etch/etch/wiki

The server has run on Linux, but now on OpenBSD for the last few years.
I've managed up to ~50 *nix systems with it with no problems.


Mit freundlichen Grüßen/Best regards

Mario Theodoridis

[dragonplayer] [Bug 486753] New: Dragon Player segfaults upon opening

[Mario Borna Mjertan]

https://bugs.kde.org/show_bug.cgi?id=486753

Bug ID: 486753
   Summary: Dragon Player segfaults upon opening
Classification: Applications
   Product: dragonplayer
   Version: 24.02.0
  Platform: Fedora RPMs
OS: Linux
Status: REPORTED
  Keywords: drkonqi
  Severity: crash
  Priority: NOR
 Component: general
  Assignee: unassigned-b...@kde.org
  Reporter: mariobo...@outlook.com
CC: myr...@kde.org, sit...@kde.org
  Target Milestone: ---

Application: dragon (24.02.0)

Qt Version: 6.6.2
Frameworks Version: 6.0.0
Operating System: Linux 6.8.0-0.rc6.49.fc40.x86_64 x86_64
Windowing System: Wayland
Distribution: "Fedora Linux 40 (KDE Plasma Prerelease)"
DrKonqi: 6.0.0 [CoredumpBackend]

-- Information about the crash:
Dragon segfaults upon opening with various files. Happens consistently.

The crash can be reproduced every time.

-- Backtrace:
Application: Dragon Player (dragon), signal: Segmentation fault


This GDB supports auto-downloading debuginfo from the following URLs:
  
Enable debuginfod for this session? (y or [n]) [answered N; input not from
terminal]
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
[New LWP 158992]
[New LWP 158958]
[New LWP 158959]
[New LWP 158964]
[New LWP 158999]
[New LWP 158998]
[New LWP 158961]
[New LWP 158960]
[New LWP 158954]
[New LWP 158981]
[New LWP 159002]
[New LWP 159010]
[New LWP 158963]
[New LWP 158982]
[New LWP 159009]
[New LWP 159005]
[New LWP 158980]
[New LWP 159007]
[New LWP 159006]
[New LWP 159004]
[New LWP 158985]
[New LWP 158991]
[New LWP 158993]
[New LWP 158983]
[New LWP 158994]
[New LWP 158962]
[New LWP 159000]
[New LWP 159003]
[New LWP 159001]
[New LWP 158965]
[New LWP 158979]
[New LWP 159008]
[New LWP 158966]
[New LWP 158984]
[New LWP 158986]
[New LWP 159011]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/bin/dragon
/home/mbm/Downloads/Ben.Fogle.New.Lives.in.the.Wild.S18E08.1080'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7fb0680ab184 in __pthread_kill_implementation () from
/lib64/libc.so.6
[Current thread is 1 (Thread 0x7fb0198006c0 (LWP 158992))]
Cannot QML trace cores :(
[Current thread is 1 (Thread 0x7fb0198006c0 (LWP 158992))]

Thread 36 (Thread 0x7fafd3e006c0 (LWP 159011)):
#0  0x7fb06812919d in syscall () at /lib64/libc.so.6
#1  0x7fb067bd9540 in g_cond_wait_until () at /lib64/libglib-2.0.so.0
#2  0x7fb067b464f3 in g_async_queue_pop_intern_unlocked () at
/lib64/libglib-2.0.so.0
#3  0x7fb067bad1ca in g_thread_pool_thread_proxy.lto_priv () at
/lib64/libglib-2.0.so.0
#4  0x7fb067bab453 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x7fb0680a91f7 in start_thread () at /lib64/libc.so.6
#6  0x7fb06812b3ac in clone3 () at /lib64/libc.so.6

Thread 35 (Thread 0x7fb0457ff6c0 (LWP 158986)):
#0  0x7fb0680a5959 in __futex_abstimed_wait_common () at /lib64/libc.so.6
#1  0x7fb0680a8692 in pthread_cond_timedwait@@GLIBC_2.3.2 () at
/lib64/libc.so.6
#2  0x7fb047fad677 in vlc_cond_timedwait () at /lib64/libvlccore.so.9
#3  0x7fb047f75b07 in MainLoop () at /lib64/libvlccore.so.9
#4  0x7fb047f7685a in Run () at /lib64/libvlccore.so.9
#5  0x7fb0680a91f7 in start_thread () at /lib64/libc.so.6
#6  0x7fb06812b3ac in clone3 () at /lib64/libc.so.6

Thread 34 (Thread 0x7fb0316006c0 (LWP 158984)):
#0  0x7fb06812b7b2 in epoll_wait () at /lib64/libc.so.6
#1  0x7fb04eb3b3e6 in impl_pollfd_wait () at
/usr/lib64/spa-0.2/support/libspa-support.so
#2  0x7fb04eb2d0c1 in loop_iterate () at
/usr/lib64/spa-0.2/support/libspa-support.so
#3  0x7fb047e990c7 in do_loop () at /lib64/libpipewire-0.3.so.0
#4  0x7fb0680a91f7 in start_thread () at /lib64/libc.so.6
#5  0x7fb06812b3ac in clone3 () at /lib64/libc.so.6

Thread 33 (Thread 0x7fb044c006c0 (LWP 158966)):
#0  0x7fb0680a5959 in __futex_abstimed_wait_common () at /lib64/libc.so.6
#1  0x7fb0680a8329 in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libc.so.6
#2  0x7fb04c69 in cnd_wait () at /usr/lib64/dri/radeonsi_dri.so
#3  0x7fb04c67b9ab in util_queue_thread_func () at
/usr/lib64/dri/radeonsi_dri.so
#4  0x7fb04c69dd0c in impl_thrd_routine () at
/usr/lib64/dri/radeonsi_dri.so
#5  0x7fb0680a91f7 in start_thread () at /lib64/libc.so.6
#6  0x7fb06812b3ac in clone3 () at /lib64/libc.so.6

Thread 32 (Thread 0x7fafe8c006c0 (LWP 159008)):
#0  0x7fb0680a5959 in __futex_abstimed_wait_common () at /lib64/libc.so.6
#1  0x7fb0680a8329 in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libc.so.6
#2  0x7fb00f0b9545 in frame_worker_thread.lto_priv () at
/lib64/libavcodec.so.60
#3  0x7fb0680a91f7 in start_thread () at /lib64/libc.so.6
#4  0x7fb06812b3ac in clone3 () at /lib64/libc.so.6

[Bug 2063002] Re: Add support for DCN 3.5

[Mario Limonciello]

This is certainly a false negative.  This firmware only affects DCN 3.5
which isn't available for arm64 or armhf.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2063002

Title:
  Add support for DCN 3.5

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/2063002/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2058830] Re: vp9 hw decode broken on modern AMD apus, needs amdgpu update

[Mario Limonciello]

I just tested on a Phoenix based laptop and tested video playback on
OEM-6.5 (1022) with VP9 content in mpv and things look good to me.

** Tags added: verification-done-jammy

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2058830

Title:
  vp9 hw decode broken on modern AMD apus, needs amdgpu update

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux-firmware/+bug/2058830/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [Flying-squirrel-members] One time Rehearsal Request

[Mario Savastano]

I’m actually not using the space for DVC rehearsal the 11th due to the last
minute rescheduling we had to do when we switched shows. We’ll be using all
our dates starting May 13, but 11 is open as far as DVC is concerned.

Mario

On Mon, May 6, 2024 at 7:28 PM Christopher Snyder 
wrote:

> Good evening all,
>
> We have a one time request for a rehearsal on May 11th. They are setting
> it for 11-1 to avoid conflict with the other rehearsal happening that day.
> Let me know if there are any questions otherwise I will go ahead and put
> them on the calendar.
>
> Thank you
>
> Christopher
>
> --
> Christopher Snyder
> he/him
> 585-815-3749
>
>
> ___
> Flying-squirrel-members mailing list
> Flying-squirrel-members@lists.rocus.org
> https://lists.mayfirst.org/mailman/listinfo/flying-squirrel-members
>
> To unsubscribe, send an email to:
> flying-squirrel-members-unsubscr...@lists.rocus.org
> (The subject and body of the email don't matter)
>
___
Flying-squirrel-members mailing list
Flying-squirrel-members@lists.rocus.org
https://lists.mayfirst.org/mailman/listinfo/flying-squirrel-members

To unsubscribe, send an email to:
flying-squirrel-members-unsubscr...@lists.rocus.org
(The subject and body of the email don't matter)

Re: Enabling HTTPS and Configuring SSL in Apache 2.4 on Windows 10.

[Mario Brandt]

Maybe this can be added to the wiki?

Frank Gingras  schrieb am Mo., 6. Mai 2024, 15:46:

>
>
> On Mon, May 6, 2024 at 2:55 AM General Email <
> general.email.12341...@gmail.com> wrote:
>
>> Hi,
>>
>> I have configured SSL and enabled HTTPS on Apache 2.4. It is working fine.
>>
>> If the docs team is interested, then they can put my instructions on
>> the above topic in the documentation.
>>
>> The instructions are below:
>>
>>
>> --
>> Enabling HTTPS and Configuring SSL in Apache 2.4 on Windows 10
>> Date: April, 2024
>> --
>>
>>
>> 
>> VERY IMPORTANT:
>>
>> You should not follow this process for a production environment because
>> self-signed SSL certificate (that is being generated here) is a security
>> risk.
>> You should follow this process only for the local development environment.
>>
>> 
>>
>> -
>> Please follow the steps listed below:
>> -
>>
>> Step 1: Stop Apache web server if it is already running.
>>
>> Step 2: Add "absolute_path_to_apache24_dir\bin" to the system environment
>> variable "Path". openssl.exe is in this folder.
>>
>> Step 3: Open the Windows command prompt and change directory to
>> "absolute_path_to_apache24_dir\conf".
>>
>> Step 4: On the command prompt, execute the following command:
>>
>> set
>> OPENSSL_CONF=absolute_path_to_apache24_dir\conf\openssl.cnf
>>
>> If "absolute_path_to_apache24_dir" contains spaces then enclose
>> the
>> path in quotes.
>>
>> Step 5: Check that the OPENSSL_CONF variable is set to correct directory
>> by
>> executing the following command on the command prompt:
>>
>> echo %OPENSSL_CONF%
>>
>> Step 6: On the command prompt, execute the following command
>> (openssl.exe is in "absolute_path_to_apache24_dir\bin" folder):
>>
>> openssl genrsa -out cert.key 2048
>>
>> Step 7: On the command prompt, execute the following command:
>>
>> openssl req -new -key cert.key -out cert.csr
>>
>> When you execute this command, you will be asked to give input for
>> some fields. I had given input for only one field (and for other
>> fields,
>> I just hit "Enter" key):
>>
>> Common Name (e.g. server FQDN or YOUR name) []:localhost
>>
>> Step 8: On the command prompt, execute the following command:
>>
>> openssl x509 -req -days 3650 -in cert.csr -signkey cert.key -out
>> cert.crt
>>
>> Step 9: Change a few lines in the
>> "absolute_path_to_apache24_dir\conf\httpd.conf"
>> file. I am listing the lines after the changes. I am not listing
>> the
>> original lines. You can search and change/replace the original
>> lines.
>>
>> The changed lines are:
>>
>> Define SRVROOT "absolute_path_to_apache24_dir"
>> LoadModule socache_shmcb_module modules/mod_socache_shmcb.so
>> LoadModule ssl_module modules/mod_ssl.so
>> ServerName localhost:80
>> Include conf/extra/httpd-ssl.conf
>>
>> Step 10: Change a few lines in the
>>  "absolute_path_to_apache24_dir\conf\extra\httpd-ssl.conf" file.
>>  I am listing the lines after the changes. I am not listing the
>>  original lines. You can search and change/replace the original
>>  lines.
>>
>>  The changed lines are:
>>
>>  ServerName localhost:443
>>  ServerAdmin ad...@localhost.localdomain.com
>>  SSLCertificateFile "${SRVROOT}/conf/cert.crt"
>>  SSLCertificateKeyFile "${SRVROOT}/conf/cert.key"
>>
>> Step 11 (Last Step): Now, you can start Apache web server and test.
>>
>>  Since the security certificate that was generated here is
>> self-signed,
>>  the browser may show you a warning that the
>> connection/certificate,
>>  etc. is not trusted. But since this is your local development
>>  environment, you can ignore this warning and accept the risk and
>>  go ahead with the testing/development, etc.
>>
>>  I do the same (ignore the warning and accept the risk).
>>
>>  End 
>>
>> -
>> To unsubscribe, e-mail: docs-unsubscr...@httpd.apache.org
>> For additional commands, e-mail: docs-h...@httpd.apache.org
>>
>>
> I don't think those belong in the official httpd documentation, but I
> wouldn't be opposed to adding the recipe in the httpd wiki.
>

Re: [Gvsig_usuarios] Usar Bing Maps en la versión 2.6

[Mario Carrera]

La autenticidad de este mensaje no ha podido ser verificada, por lo que podría 
ser malicioso. Recomendamos que no abra ningún enlace ni adjunto incluido en 
él, y ante la duda se verifique la autenticidad contactando con el emisor por 
medios alternativos (p.e. por teléfono).

L'autenticitat d'aquest missatge no ha pogut ser verificada, per la qual cosa 
podria ser maliciós. Recomanem que no òbriga cap enllaç ni adjunt inclòs en 
ell, i davant el dubte es verifique l'autenticitat contactant amb l'emissor per 
mitjans alternatius (p.e. per telèfon).

Hola Fidel,

han hecho varios cambios desde ambas aplicaciones, que habían hecho que 
dejasen de funcionar. De momento para la 2.6 no se han podido actualizar 
los plugins, por lo que se han quitado del administrador de complementos.


Un saludo,
 Mario


El 6/5/24 a las 16:00, Fidel Padilla escribió:
Hola, no encuentro la manera de usar los mapas del Bing Maps o del 
Google Maps en la versión 2.6, yo uso mucho esas plataformas en la 
versión 2.5.1, pueden indicarme cómo hacerlo en la 2.6?


___
gvSIG_usuarios mailing list
gvSIG_usuarios@listserv.gva.es

Para ver histórico de mensajes, editar sus preferencias de usuario o darse de 
baja en esta lista, acuda a la siguiente dirección:

https://listserv.gva.es/mailman/listinfo/gvsig_usuarios


--

*Mario Carrera*

gvSIG Association / Asociación gvSIG

http://www.gvsig.com <http://www.gvsig.com/>


Antes de imprimir este e-mail piense bien si es necesario hacerlo.

AVISO LEGAL: Este mensaje y sus archivos adjuntos van dirigidos 
exclusivamente a su destinatario, pudiendo contener información 
confidencial sometida a secreto profesional. No está permitida su 
comunicación, reproducción o distribución sin la autorización expresa de 
la Asociación gvSIG. Si usted no es el destinatario final, por favor 
elimínelo e infórmenos por esta vía.


PROTECCIÓN DE DATOS: De conformidad con lo dispuesto en las normativas 
vigentes en protección de datos personales, el Reglamento (UE) 2016/679 
de 27 de abril de 2016 (GDPR) y la Ley Orgánica (ES) 15/1999 de 13 de 
diciembre (LOPD), le informamos que los datos personales y dirección de 
correo electrónico, recabados del propio interesado o de fuentes 
públicas, serán tratados bajo la responsabilidad de la /Asociación gvSIG 
/para el envío de comunicaciones sobre nuestros productos y servicios y 
se conservarán mientras exista un interés mutuo para ello. Los datos no 
serán comunicados a terceros, salvo obligación legal. Le informamos que 
puede ejercer los derechos de acceso, rectificación, portabilidad y 
supresión de sus datos y los de limitación y oposición a su tratamiento 
dirigiéndose enviando un mensaje al correo electrónico a i...@gvsig.com. 
Si considera que el tratamiento no se ajusta a la normativa vigente, 
podrá presentar una reclamación ante la autoridad de control en 
www.agpd.es <http://www.agpd.es/>.


___
gvSIG_usuarios mailing list
gvSIG_usuarios@listserv.gva.es

Para ver histórico de mensajes, editar sus preferencias de usuario o darse de 
baja en esta lista, acuda a la siguiente dirección:

https://listserv.gva.es/mailman/listinfo/gvsig_usuarios

Re: [regext] WGLC: draft-ietf-regext-epp-ttl-08

[Mario Loffredo]

+1

Mario

Il 29/04/2024 16:27, James Galvin ha scritto:

The document editors have indicated that the following document is ready for 
submission to the IESG to be considered for publication as a Proposed Standard:

Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live (TTL) values
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/08/

Please indicate your support or no objection for the publication of this 
document by replying to this message on list (a simple “+1” is sufficient).

If any working group member has questions regarding the publication of this 
document please respond on the list with your concerns by close of business 
everywhere, Monday, 13 May 2024.

If there are no objections the document will be submitted to the IESG.

The Document Shepherd for this document is Andy Newton.

Thanks,

Antoin and Jim
REGEXT WG Co-Chairs

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[Bug 2064815] Re: Always black screen on first reboot after fresh install 24.04, Intel and AMD GPU

[Mario Limonciello]

*** This bug is a duplicate of bug 2063143 ***
https://bugs.launchpad.net/bugs/2063143

** This bug has been marked a duplicate of bug 2063143
   Frequent boot to black display

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2064815

Title:
  Always black screen on first reboot after fresh install 24.04, Intel
  and AMD GPU

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2064815/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2063877] Re: Only black screen on boot with AMD Barcelo and Intel Iris Xe GPU with "quiet splash" (Grub)

[Mario Limonciello]

*** This bug is a duplicate of bug 2063143 ***
https://bugs.launchpad.net/bugs/2063143

** This bug is no longer a duplicate of bug 2064815
   Always black screen on first reboot after fresh install 24.04, Intel and AMD 
GPU
** This bug has been marked a duplicate of bug 2063143
   Frequent boot to black display

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2063877

Title:
  Only black screen on boot with AMD Barcelo and Intel Iris Xe GPU with
  "quiet splash" (Grub)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+bug/2063877/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2063143] Re: Frequent boot to black display

[Mario Limonciello]

The issue here is the same one that happened in gdm last year where the
startup would race with the load of DRM graphics drivers.

GDM fixed it by essentially running the equivalent of 'udevadm settle'.
The same kind of fix needs to be ported to sddm or systemd needs to be
modified to not emit CanGraphical until DRM graphics drivers are fully
loaded.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2063143

Title:
  Frequent boot to black display

To manage notifications about this bug go to:
https://bugs.launchpad.net/plymouth/+bug/2063143/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2063143] Re: Frequent boot to black display

[Mario Limonciello]

The issue here is the same one that happened in gdm last year where the
startup would race with the load of DRM graphics drivers.

GDM fixed it by essentially running the equivalent of 'udevadm settle'.
The same kind of fix needs to be ported to sddm or systemd needs to be
modified to not emit CanGraphical until DRM graphics drivers are fully
loaded.

-- 
You received this bug notification because you are a member of Kubuntu
Bugs, which is subscribed to sddm in Ubuntu.
https://bugs.launchpad.net/bugs/2063143

Title:
  Frequent boot to black display

To manage notifications about this bug go to:
https://bugs.launchpad.net/plymouth/+bug/2063143/+subscriptions


-- 
kubuntu-bugs mailing list
kubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kubuntu-bugs

Re: How to configure the networking on FreeBSD to assign the same IP between host and guest in order to make work CloudFlare Warp on FreeBSD

[Mario Marietto]

 This is what I did :

on FreeBSD :

/etc/rc.conf :

ifconfig_em0="inet 192.168.1.5 netmask 255.255.255.0"
defaultrouter="192.168.1.10"

On Ubuntu :

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -A PREROUTING -t nat -p tcp -d 192.168.1.10 -j DNAT
--to-destination 192.168.1.5
iptables -A POSTROUTING -t nat -o enp0s13 -j MASQUERADE
warp-cli connect

What's the problem ? I'm able to connect to Ubuntu,but on FreeBSD I can't
surf.

On Sat, May 4, 2024 at 9:29 PM Mario Marietto 
wrote:

> So. Please help me further...
>
> Let's say that the IP number assigned to Ubuntu is 192.168.1.9,on FreeBSD
> I do :
>
> /etc/rc.conf :
>
> defaultrouter="192.168.1.9"
>
> ? even if the VM starts after the booting of FreeBSD ?
>
> About configuring the DNAT iptables rule I have no idea. Please help me to
> understand how to do it.
>
> On Sat, May 4, 2024 at 9:22 PM Apoorv Sachan 
> wrote:
>
>> Hi Mario
>>
>> You can set the ip if the Ubuntu machine as the default route on the
>> freeBSD host.
>> This will take all the traffic oroginating in freeBSD host through the
>> warp-tunnel.
>>
>> And configure a DNAT iptables rule in the Ubuntu machine to return the
>> traffic back to freeBSD machine.
>>
>> This way you could utilise the warp-cloud flare tunnel from the freeBSD
>> host even though it runs on the Ubuntu guest. And both have different IPs.
>>
>> On Sun, 5 May 2024 at 12:23 AM, Mario Marietto 
>> wrote:
>>
>>> Hello.
>>>
>>> I've just installed the CloudFlare client + GUI on Ubuntu,that I have
>>> virtualized with bhyve. Cloudflare does not work on FreeBSD. The
>>> instructions that I have followed are located here :
>>>
>>> https://youtu.be/4JuOUjCSj44
>>>
>>> Installing it in this way,it will run only on the IP assigned to Ubuntu
>>> inside the VM. For me the IP of FreeBSD is different from the IP assigned
>>> to Ubuntu. Configured in this way it's not useful.
>>>
>>> I want Cloudflare to take the IP address of FreeBSD.
>>>
>>> To achieve this goal,I should change my network configuration,in a way
>>> that I use the same IP for FreeBSD and Ubuntu.
>>>
>>> That's what I want to do,but I don't know how to do it. But I'm sure
>>> that I will be able to do it if someone can give me some advice.
>>>
>>> I can explain how I have configured my network,so you can explain what I
>>> should change to have the same IP.
>>>
>>> For example,to boot Ubuntu with bhyve,I use the following parameter :
>>>
>>> -s 13,virtio-net,tap19 \
>>>
>>>
>>> /etc/rc.conf :
>>>
>>> ifconfig_em0="DHCP"
>>> local_unbound_enable="YES"
>>> cloned_interfaces="bridge0 tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7 tap8 
>>> tap9 tap10 tap11 tap12 tap13 tap14 tap15 tap16 tap17 tap18 tap19 tap20 em0"
>>> ifconfig_bridge0="addm em0 addm tap0 addm tap1 addm tap2 addm tap3 addm 
>>> tap4 addm tap5 addm tap6 addm tap7 addm tap8 addm tap9 addm tap10 addm 
>>> tap11 addm tap12 addm tap13 addm tap14 addm tap15 addm tap16 addm tap17 
>>> addm tap18 addm tap19 addm tap20"
>>>
>>>
>>> /boot/loader.conf
>>>
>>> if_tap_load="YES"
>>> if_bridge_load="YES"
>>> bridgestp_load="YES"
>>>
>>>
>>> /etc/sysctl.conf
>>>
>>> net.link.tap.up_on_open=1
>>> net.inet.ip.forwarding=1
>>> net.inet.ip.random_id=1
>>>
>>>
>>> So,ok. I think you have understood what I want to do. Please help me.
>>> Thanks.
>>>
>>> --
>>> Mario
>>>
>>
>
> --
> Mario.
>


-- 
Mario.

RE: Caller ID Help Please.

[Mario Eiland]

This is an anomaly  with Verizon. I would suggest to give them a call. I myself 
use AT and I'm able to access this feature in the phone settings.


-Original Message-
From: viphone@googlegroups.com  On Behalf Of Carolyn 
Arnold
Sent: Saturday, May 4, 2024 7:57 AM
To: viphone@googlegroups.com
Subject: RE: Caller ID Help Please.

Verizon is my carrier. Who is yours? 

-Original Message-
From: viphone@googlegroups.com [mailto:viphone@googlegroups.com] On Behalf Of 
janet gross
Sent: Friday, May 3, 2024 7:54 PM
To: viphone@googlegroups.com
Subject: RE: Caller ID Help Please.

Carolyn,
Can I ask you who is your phone carrier?
I'm wondering why this problem with the caller ID is all about.
My phone carrier is T-Mobile.
Janet

-Original Message-
From: viphone@googlegroups.com  On Behalf Of Carolyn 
Arnold
Sent: Friday, May 3, 2024 6:04 PM
To: viphone@googlegroups.com
Subject: RE: Caller ID Help Please.

I found no Caller ID. I did go through the prompts and tried making it take my 
name, but when I called here, it said Wireless Caller.

-Original Message-
From: viphone@googlegroups.com [mailto:viphone@googlegroups.com] On Behalf Of 
Donna Casteen
Sent: Friday, May 3, 2024 11:48 AM
To: viphone@googlegroups.com
Subject: Re: Caller ID Help Please.

Carolyn,

Open the Settings app, swipe down to Phone & tap to open, swipe to Caller ID & 
tap to open. Confirm that Caller ID is toggled On.

Donna

>
> I did not find Caller ID in my phone app.
>
> -Original Message-
> From: viphone@googlegroups.com [mailto:viphone@googlegroups.com] On Behalf Of 
> janet gross
> Sent: Thursday, May 2, 2024 11:55 PM
> To: viphone@googlegroups.com
> Subject: RE: Caller ID Help Please.
>
> Hi,
>
>
>
> I don’t get the option to show my caller ID.
>
> I go to settings, phone, caller ID, I tap on that, and I then get a message 
> saying in progress but nothing changes. ,
>
>
>
> Janet
>
> From: viphone@googlegroups.com  On Behalf Of 
> Jonathan Cohn
> Sent: Thursday, May 2, 2024 9:35 PM
> To: Viphone 
> Subject: Re: Caller ID Help Please.
>
>
>
>
>
> 1. Go to Settings, Tap Phone
>
> 2. Press Show My Caller ID
>
> 3. Use the toggle switch to show or hide your number
>
>
>
>Apparently this does not work with Verizon
>
>
>
>
>
>
>On May 2, 2024, at 6:51 PM, janet gross   > wrote:
>
>
>
>Hi Carolyn,
>
>What do you mean when you say your card?
>I am talking about the caller ID on an iPhone.
>I've had caller ID turned on my iPhone for over 5 years.
>I accidentally   turned it off, now that I think of it.
>So, are you saying you don't have caller ID on your phone?
>What kind of a phone do you have?
>
>Janet
>
>-Original Message-
>From: viphone@googlegroups.com   
> mailto:viphone@googlegroups.com> > On Behalf Of 
> Carolyn Arnold
>Sent: Thursday, May 2, 2024 5:12 PM
>To: viphone@googlegroups.com 
>Subject: RE: Caller ID Help Please.
>
>On My Card, you can put your picture and name, but mine did not take just 
> my name, and I'm not about to fool with dealing with a picture.
>
>-Original Message-
>From: viphone@googlegroups.com   
> [mailto:viphone@googlegroups.com] On Behalf Of Robert Doc Wright
>Sent: Thursday, May 2, 2024 5:18 PM
>To: viphone@googlegroups.com 
>Subject: Re: Caller ID Help Please.
>
>I looked and saw what you mentioned on my 10R and it said what yours said 
> but mine doesn't have cellular.  My 13 doesn't offer Caller ID.
>
>   - Original Message -
>   From: janet gross 
>   To: viphone@googlegroups.com   
> 
>   Sent: Thursday, May 2, 2024 2:49 PM
>   Subject: Caller ID Help Please.
>
>
>   Hi Everyone,
>
>
>
>   Some way some how my caller ID has been turned off.
>
>   When I call someone, they always ask why do I have my caller ID not 
> shown.
>
>   I went in to  settings, phone, caller ID, tap on show my caller ID, 
> but all I get when I do that is a message says in progress.
>
>   I can't seem to turn on my caller ID.
>
>   Is there some way I can turn on my caller ID so when I call someone 
> they will know the call is coming from me?
>
>   I have a XR with 17.4.1.
>
>
>
>
>
>   Thank you all.
>
>
>
>   Janet
>
>
>
>   --
>   The following information is important for all members of the V 
> iPhone list.
>
>   If you have any questions or concerns about the running of this 
> list, or if you feel that a member's post is inappropriate, please contact 
> the owners or moderators directly rather than posting on the list itself.
>
>   Your V iPhone list moderator is Mark 

RE: Caller ID Help Please.

[Mario Eiland]

Who is your carrier?


-Original Message-
From: viphone@googlegroups.com  On Behalf Of Carolyn 
Arnold
Sent: Friday, May 3, 2024 4:20 PM
To: viphone@googlegroups.com
Subject: RE: Caller ID Help Please.

That is where I have gone - Settings and Phone. I get:

Phone heading
Allow phone to access
Siri and search
Notifications, sounds , badges
Incoming calls, full screen
Announce calls, always
My number, and it gives it
Share Name and photo, Contacts only
Calls heading
Wi-Fi calling off (I have tried numerous times to turn it on, but it does not 
turn on, go figure.
Respond with text
Life Voice Mail off
Silence unknown callers off
Call blocking and identification
Block Contacts
SMS/call call reporting
Change Voicemail password
Dial Assist switch button on
Dial assist automatically determines the correct international or local prefix 
when dialing

-Original Message-
From: viphone@googlegroups.com [mailto:viphone@googlegroups.com] On Behalf Of 
Sieghard Weitzel
Sent: Friday, May 3, 2024 4:39 PM
To: viphone@googlegroups.com
Subject: RE: Caller ID Help Please.

It is not in the Phone app, it is in Settings > Phone and it is towards the 
bottom and the exact name is "Show my caller Id, button". It is after Call 
Forwarding and Call Waiting.

-Original Message-
From: viphone@googlegroups.com  On Behalf Of Carolyn 
Arnold
Sent: Friday, May 3, 2024 5:28 AM
To: viphone@googlegroups.com
Subject: RE: Caller ID Help Please.

I did not find Caller ID in my phone app. 

-Original Message-
From: viphone@googlegroups.com [mailto:viphone@googlegroups.com] On Behalf Of 
janet gross
Sent: Thursday, May 2, 2024 11:55 PM
To: viphone@googlegroups.com
Subject: RE: Caller ID Help Please.

Hi, 

 

I don’t get the option to show my caller ID.  

I go to settings, phone, caller ID, I tap on that, and I then get a message 
saying in progress but nothing changes. ,

 

Janet 

From: viphone@googlegroups.com  On Behalf Of Jonathan 
Cohn
Sent: Thursday, May 2, 2024 9:35 PM
To: Viphone 
Subject: Re: Caller ID Help Please.

 

 

1. Go to Settings, Tap Phone

2. Press Show My Caller ID

3. Use the toggle switch to show or hide your number

 

Apparently this does not work with Verizon 






On May 2, 2024, at 6:51 PM, janet gross mailto:janet.harv...@outlook.com> > wrote:

 

Hi Carolyn,

What do you mean when you say your card?
I am talking about the caller ID on an iPhone.
I've had caller ID turned on my iPhone for over 5 years.
I accidentally   turned it off, now that I think of it.
So, are you saying you don't have caller ID on your phone?
What kind of a phone do you have?

Janet

-Original Message-
From: viphone@googlegroups.com   
mailto:viphone@googlegroups.com> > On Behalf Of 
Carolyn Arnold
Sent: Thursday, May 2, 2024 5:12 PM
To: viphone@googlegroups.com  
Subject: RE: Caller ID Help Please.

On My Card, you can put your picture and name, but mine did not take 
just my name, and I'm not about to fool with dealing with a picture.

-Original Message-
From: viphone@googlegroups.com   
[mailto:viphone@googlegroups.com] On Behalf Of Robert Doc Wright
Sent: Thursday, May 2, 2024 5:18 PM
To: viphone@googlegroups.com  
Subject: Re: Caller ID Help Please.

I looked and saw what you mentioned on my 10R and it said what yours 
said but mine doesn't have cellular.  My 13 doesn't offer Caller ID.

   - Original Message -
   From: janet gross 
   To: viphone@googlegroups.com   

   Sent: Thursday, May 2, 2024 2:49 PM
   Subject: Caller ID Help Please.


   Hi Everyone,



   Some way some how my caller ID has been turned off.

   When I call someone, they always ask why do I have my caller ID 
not shown.

   I went in to  settings, phone, caller ID, tap on show my caller 
ID, but all I get when I do that is a message says in progress.

   I can't seem to turn on my caller ID.

   Is there some way I can turn on my caller ID so when I call 
someone they will know the call is coming from me?

   I have a XR with 17.4.1.





   Thank you all.



   Janet



   --
   The following information is important for all members of the V 
iPhone list.

   

RE: Caller ID Help Please.

[Mario Eiland]

That has to do with your carrier.


-Original Message-
From: viphone@googlegroups.com  On Behalf Of Carolyn 
Arnold
Sent: Thursday, May 2, 2024 3:11 PM
To: viphone@googlegroups.com
Subject: RE: Caller ID Help Please.

I went into My Card and put my name in, yet, still mine will show Wireless 
Caller, when I call our landline. I'd like to know what to do about that too, 
Janet. 

-Original Message-
From: viphone@googlegroups.com [mailto:viphone@googlegroups.com] On Behalf Of 
janet gross
Sent: Thursday, May 2, 2024 4:50 PM
To: viphone@googlegroups.com
Subject: Caller ID Help Please.

Hi Everyone, 

 

Some way some how my caller ID has been turned off.  

When I call someone, they always ask why do I have my caller ID not shown.  

I went in to  settings, phone, caller ID, tap on show my caller ID, but all I 
get when I do that is a message says in progress.  

I can’t seem to turn on my caller ID.  

Is there some way I can turn on my caller ID so when I call someone they will 
know the call is coming from me? 

I have a XR with 17.4.1. 

 

 

Thank you all.  

 

Janet 

-- 
The following information is important for all members of the V iPhone list.
 
If you have any questions or concerns about the running of this list, or if you 
feel that a member's post is inappropriate, please contact the owners or 
moderators directly rather than posting on the list itself.
 
Your V iPhone list moderator is Mark Taylor. Mark can be reached at: 
mk...@ucla.edu. Your list owner is Cara Quinn - you can reach Cara at 
caraqu...@caraquinn.com
 
The archives for this list can be searched at:
http://www.mail-archive.com/viphone@googlegroups.com/
--- 
You received this message because you are subscribed to the Google Groups 
"VIPhone" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to viphone+unsubscr...@googlegroups.com 
 .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/viphone/BL3P221MB0273A499BFB4BB7D8033B133FC182%40BL3P221MB0273.NAMP221.PROD.OUTLOOK.COM
 

 .


-- 
The following information is important for all members of the V iPhone list.

If you have any questions or concerns about the running of this list, or if you 
feel that a member's post is inappropriate, please contact the owners or 
moderators directly rather than posting on the list itself.

Your V iPhone list moderator is Mark Taylor.  Mark can be reached at:  
mk...@ucla.edu.  Your list owner is Cara Quinn - you can reach Cara at 
caraqu...@caraquinn.com

The archives for this list can be searched at:
http://www.mail-archive.com/viphone@googlegroups.com/
--- 
You received this message because you are subscribed to the Google Groups 
"VIPhone" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to viphone+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/viphone/00c401da9cdd%24912e7f60%24b38b7e20%24%40gmail.com.

-- 
The following information is important for all members of the V iPhone list.

If you have any questions or concerns about the running of this list, or if you 
feel that a member's post is inappropriate, please contact the owners or 
moderators directly rather than posting on the list itself.

Your V iPhone list moderator is Mark Taylor.  Mark can be reached at:  
mk...@ucla.edu.  Your list owner is Cara Quinn - you can reach Cara at 
caraqu...@caraquinn.com

The archives for this list can be searched at:
http://www.mail-archive.com/viphone@googlegroups.com/
--- 
You received this message because you are subscribed to the Google Groups 
"VIPhone" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to viphone+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/viphone/016e01da9ce1%244cf8a830%24e6e9f890%24%40gmail.com.

Re: How to configure the networking on FreeBSD to assign the same IP between host and guest in order to make work CloudFlare Warp on FreeBSD

[Mario Marietto]

So. Please help me further...

Let's say that the IP number assigned to Ubuntu is 192.168.1.9,on FreeBSD I
do :

/etc/rc.conf :

defaultrouter="192.168.1.9"

? even if the VM starts after the booting of FreeBSD ?

About configuring the DNAT iptables rule I have no idea. Please help me to
understand how to do it.

On Sat, May 4, 2024 at 9:22 PM Apoorv Sachan 
wrote:

> Hi Mario
>
> You can set the ip if the Ubuntu machine as the default route on the
> freeBSD host.
> This will take all the traffic oroginating in freeBSD host through the
> warp-tunnel.
>
> And configure a DNAT iptables rule in the Ubuntu machine to return the
> traffic back to freeBSD machine.
>
> This way you could utilise the warp-cloud flare tunnel from the freeBSD
> host even though it runs on the Ubuntu guest. And both have different IPs.
>
> On Sun, 5 May 2024 at 12:23 AM, Mario Marietto 
> wrote:
>
>> Hello.
>>
>> I've just installed the CloudFlare client + GUI on Ubuntu,that I have
>> virtualized with bhyve. Cloudflare does not work on FreeBSD. The
>> instructions that I have followed are located here :
>>
>> https://youtu.be/4JuOUjCSj44
>>
>> Installing it in this way,it will run only on the IP assigned to Ubuntu
>> inside the VM. For me the IP of FreeBSD is different from the IP assigned
>> to Ubuntu. Configured in this way it's not useful.
>>
>> I want Cloudflare to take the IP address of FreeBSD.
>>
>> To achieve this goal,I should change my network configuration,in a way
>> that I use the same IP for FreeBSD and Ubuntu.
>>
>> That's what I want to do,but I don't know how to do it. But I'm sure that
>> I will be able to do it if someone can give me some advice.
>>
>> I can explain how I have configured my network,so you can explain what I
>> should change to have the same IP.
>>
>> For example,to boot Ubuntu with bhyve,I use the following parameter :
>>
>> -s 13,virtio-net,tap19 \
>>
>>
>> /etc/rc.conf :
>>
>> ifconfig_em0="DHCP"
>> local_unbound_enable="YES"
>> cloned_interfaces="bridge0 tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7 tap8 tap9 
>> tap10 tap11 tap12 tap13 tap14 tap15 tap16 tap17 tap18 tap19 tap20 em0"
>> ifconfig_bridge0="addm em0 addm tap0 addm tap1 addm tap2 addm tap3 addm tap4 
>> addm tap5 addm tap6 addm tap7 addm tap8 addm tap9 addm tap10 addm tap11 addm 
>> tap12 addm tap13 addm tap14 addm tap15 addm tap16 addm tap17 addm tap18 addm 
>> tap19 addm tap20"
>>
>>
>> /boot/loader.conf
>>
>> if_tap_load="YES"
>> if_bridge_load="YES"
>> bridgestp_load="YES"
>>
>>
>> /etc/sysctl.conf
>>
>> net.link.tap.up_on_open=1
>> net.inet.ip.forwarding=1
>> net.inet.ip.random_id=1
>>
>>
>> So,ok. I think you have understood what I want to do. Please help me.
>> Thanks.
>>
>> --
>> Mario
>>
>

-- 
Mario.

How to configure the networking on FreeBSD to assign the same IP between host and guest in order to make work CloudFlare Warp on FreeBSD

[Mario Marietto]

Hello.

I've just installed the CloudFlare client + GUI on Ubuntu,that I have
virtualized with bhyve. Cloudflare does not work on FreeBSD. The
instructions that I have followed are located here :

https://youtu.be/4JuOUjCSj44

Installing it in this way,it will run only on the IP assigned to Ubuntu
inside the VM. For me the IP of FreeBSD is different from the IP assigned
to Ubuntu. Configured in this way it's not useful.

I want Cloudflare to take the IP address of FreeBSD.

To achieve this goal,I should change my network configuration,in a way that
I use the same IP for FreeBSD and Ubuntu.

That's what I want to do,but I don't know how to do it. But I'm sure that I
will be able to do it if someone can give me some advice.

I can explain how I have configured my network,so you can explain what I
should change to have the same IP.

For example,to boot Ubuntu with bhyve,I use the following parameter :

-s 13,virtio-net,tap19 \


/etc/rc.conf :

ifconfig_em0="DHCP"
local_unbound_enable="YES"
cloned_interfaces="bridge0 tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7
tap8 tap9 tap10 tap11 tap12 tap13 tap14 tap15 tap16 tap17 tap18 tap19
tap20 em0"
ifconfig_bridge0="addm em0 addm tap0 addm tap1 addm tap2 addm tap3
addm tap4 addm tap5 addm tap6 addm tap7 addm tap8 addm tap9 addm tap10
addm tap11 addm tap12 addm tap13 addm tap14 addm tap15 addm tap16 addm
tap17 addm tap18 addm tap19 addm tap20"


/boot/loader.conf

if_tap_load="YES"
if_bridge_load="YES"
bridgestp_load="YES"


/etc/sysctl.conf

net.link.tap.up_on_open=1
net.inet.ip.forwarding=1
net.inet.ip.random_id=1


So,ok. I think you have understood what I want to do. Please help me.
Thanks.

-- 
Mario.

[Bug 2008958] Re: please backport 0.21 to jammy

[Mario Limonciello]

Thanks!

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2008958

Title:
  please backport 0.21 to jammy

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/power-profiles-daemon/+bug/2008958/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2008958] Re: please backport 0.21 to jammy

[Mario Limonciello]

Thanks for testing!  By chance do either of those have batteries?  Could
you test with AC unplugged too?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2008958

Title:
  please backport 0.21 to jammy

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/power-profiles-daemon/+bug/2008958/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: Allow setting a power cap that's lower than recommended

[Mario Limonciello]

On 5/3/2024 07:05, fililip wrote:

This patch allows setting a low power cap if |ignore_min_pcap|​ is set to 1.

Signed-off-by: fililip 


Rather than an attachment you should send the patch inline.  That would 
mean that your commit message and SoB should be at the top of the patch 
itself.


If you're not aware of it, you should read through:

https://www.kernel.org/doc/html/latest/process/submitting-patches.html

Basically a maintainer should be able to run:

'b4 shazam $URL'

And it would download the patch and apply it.

That being said my comments on the patch content:

As Alex mentioned a concern about the the maintenance of more 
parameters, maybe it's worth making the sysfs file of the limit 
"writable" instead.


Then when it's written the kernel driver can add_taint() for 
TAINT_FIRMWARE_WORKAROUND when in use so we can see it clearly in logs.

Re: [Metamath] Question abouot indistopon

[Mario Carneiro]

It's not my invention, although I'm not sure it's been used in this exact
situation before. Negative and positive position is a notion in proof
theory relating to whether a certain construct is covariant or
contravariant with respect to increasing in the ordering of propositions
(i.e. "more true"). So for example in the expression "P -> Q", P is in
negative position and Q is in positive position, because implication is
covariant on the right, i.e. if Q -> Q' then (P -> Q) -> (P -> Q'), but
contravariant on the left, because if P -> P' then (P' -> Q) -> (P -> Q).
In general the polarity flips every time you nest in another "negative
position", so in (P -> Q) -> R, P and R are in positive position and Q is
in negative position.

On Thu, May 2, 2024 at 2:04 AM 'B. Wilson' via Metamath <
metamath@googlegroups.com> wrote:

> Thank you for the pointer, Mario. Is this negative vs. positive position
> terminology something you neologized on the fly? Or does it have
> precedent? If
> I'm grokking you correctly, the positive positions plug into the negative
> positions, which jibes with your explanation and the Is-a-set convention
> you
> reference.
>
> Thanks for the clarity.
>
>
> Mario Carneiro  wrote:
> > There is a convention, which is to use "( A e. V -> ..." in antecedents
> to
> > theorems and deduction-form statements and |- A e. _V in inference-form
> > theorems. In "positive position", you often need to use A e. _V, i.e. in
> > fvex there is no other reasonable option for what set to say that
> function
> > value is a member of without any assumptions. In "negative position",
> it's
> > a question of whether to spend one extra elex step in some cases (e.g. 2
> e.
> > RR therefore 2 e. _V therefore I can apply this lemma about sets to 2),
> or
> > one extra syntax step to instantiate the V argument (which also takes
> some
> > space in proofs). I believe the above convention is derived from some
> > analysis along these lines, but it's also somewhat historical (it's more
> > important to have a consistent convention). See the "Is-a-set." section
> of
> > https://us.metamath.org/mpeuni/conventions.html for more information.
> >
> > On Wed, Apr 24, 2024 at 3:52 AM heiphohmia via Metamath <
> > metamath@googlegroups.com> wrote:
> >
> > > > It functions much like A e. _V would. A proof using this theorem can
> > > always
> > > > plug in _V for V but it also could plug in On, RR, or whatever is
> > > convenient.
> > > > Perhaps looking at <https://us.metamath.org/mpeuni/elex.html> makes
> it
> > > clear.
> > >
> > > Okay, elements of ZF classes are always sets, so A e. V restricts A
> from
> > > being
> > > proper classes. That begs the question why one would ever use A e. _V
> > > though.
> > > Is this just a case where there's no particular convention?
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> Groups
> > > "Metamath" group.
> > > To unsubscribe from this group and stop receiving emails from it, send
> an
> > > email to metamath+unsubscr...@googlegroups.com.
> > > To view this discussion on the web visit
> > >
> https://groups.google.com/d/msgid/metamath/272R9VKF3UZLE.34NMDVUCB3A1P%40wilsonb.com
> > > .
> > >
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/2VC9HKX4Q39T0.1ZIJO4RNZ5BIT%40wilsonb.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJStzbKu4QCWU984ynXRBOQdNVRmRCQd7Udp6CM3cZAJ02g%40mail.gmail.com.

[PATCH] dm/amd/pm: Fix problems with reboot/shutdown for some SMU 13.0.4/13.0.11 users

[Mario Limonciello]

Limit the workaround introduced by commit 31729e8c21ec ("drm/amd/pm: fixes
a random hang in S4 for SMU v13.0.4/11") to only run in the s4 path.

Cc: Tim Huang 
Fixes: 31729e8c21ec ("drm/amd/pm: fixes a random hang in S4 for SMU v13.0.4/11")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3351
Signed-off-by: Mario Limonciello 
---
I tested this on SMU 13.0.4 for ~85 cycles with this script, BIOS 1.1.0.2a and
didn't observe any hangs.

```
#!/bin/sh
echo test_resume > /sys/power/disk
i=1
while [ : ]; do

  echo "Starting cycle $i"
  echo disk > /sys/power/state
  echo "Ending cycle $i"
  i=$((i+1))
  sleep 5
done
```

 drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c
index 949131bd1ecb..4abfcd32747d 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c
@@ -226,7 +226,7 @@ static int smu_v13_0_4_system_features_control(struct 
smu_context *smu, bool en)
struct amdgpu_device *adev = smu->adev;
int ret = 0;
 
-   if (!en && !adev->in_s0ix) {
+   if (!en && adev->in_s4) {
/* Adds a GFX reset as workaround just before sending the
 * MP1_UNLOAD message to prevent GC/RLC/PMFW from entering
 * an invalid state.
-- 
2.43.0

Re: How to use Virtio GPU on FreeBSD as guest OS.

[Mario Marietto]

 What I find strange is that this configuration works on Windows 11 to
virtualize FreeBSD using -device vmware-svga :

I:\OS\vms\qemu\qemu-system-x86_64w.exe -accel whpx -machine q35 -cpu
kvm64,hv_relaxed,hv_time,hv_synic -m 8G -device
vmware-svga,id=video0,vgamem_mb=16,bus=pcie.0,addr=0x1 -audiodev
dsound,id=snd0 -device ich9-intel-hda -device hda-duplex,audiodev=snd0 -hda
"I:\Backup\FreeBSD\FreeBSD-140-zfs.img" -device hda-duplex,audiodev=snd0
-drive file=\\.\PhysicalDrive4 -drive file=\\.\PhysicalDrive5 -drive
file=\\.\PhysicalDrive6 -drive file=\\.\PhysicalDrive8 -drive
file=\\.\PhysicalDrive12 -rtc base=localtime -device
usb-ehci,id=usb,bus=pcie.0,addr=0x3 -device usb-tablet -device usb-kbd
-smbios type=2 -nodefaults -netdev
tap,id=mynet0,ifname="OpenVPN-TAP-Windows",script=no,downscript=no -device
e1000,netdev=mynet0,mac=52:55:00:d1:55:01 -device ich9-ahci,id=sata -bios
"I:\OS\vms\qemu\OVMF_combined.fd"

One can think that it will work even on Linux for the same setup (qemu +
hyper-V on Windows 11),but it does not. I'm experiencing a lot of problems
when I add -accel whpx on a Debian VM. These problems go away if I remove
it.

Adding " -device vmware-svga,id=video0,vgamem_mb=16,bus=pcie.0,addr=0x1" to
the qemu / Debian parameters will cause it won't boot. So,this :


I:\OS\vms>I:\OS\vms\qemu\qemu-system-x86_64.exe -machine q35 -cpu
kvm64,hv_relaxed,hv_time,hv_synic -m 8G -device
vmware-svga,id=video0,vgamem_mb=16,bus=pcie.0,addr=0x1 -audiodev
dsound,id=snd0 -device ich9-intel-hda -device hda-duplex,audiodev=snd0 -hda
"I:\Backup\Linux\Debian.img" -drive file=\\.\PhysicalDrive5 -drive
file=\\.\PhysicalDrive6 -drive file=\\.\PhysicalDrive8 -rtc base=localtime
-device usb-ehci,id=usb,bus=pcie.0,addr=0x3 -device usb-tablet -device
usb-kbd -smbios type=2 -nodefaults -netdev user,id=net0 -device
e1000,netdev=net0,id=net0,mac=52:54:00:11:22:33 -device ich9-ahci,id=sata
-bios "I:\OS\vms\qemu\OVMF_combined.fd"


will cause the Debian VM to freeze before reaching the login prompt. I
don't know if Linux has the proper vmware-svga driver,I didn't find it.

Regarding virtualizing Windows 7 on Windows 11 using the same setup,I can't
add -accel whpx and most importantly,what I care more, the -device
vmware-svga does not work. So,in this kind of setup,
*FreeBSD is the winner because it supports everything (hyper-V and the
vmware-svga 3D accelerated device.*


On Sat, Apr 27, 2024 at 9:41 PM Yusuf Khan  wrote:

> So your issue is that the performance is worse than Linux?
>
> There is no 3d graphics driver for virtio in mainline drm-kmod but
> https://github.com/freebsd/drm-kmod/pull/119 has
> experimental support, although that PR exists it seems to be
> non-functional with a crash.
>


-- 
Mario.

Re: Refine the firmware-updates exception

[Mario Limonciello]

Robie,

My apologies; my email didn't get a response a while and I was on leave 
a while when your response came back and I totally missed it.


Your comment on bug 1979963 prompted me to find it though!

On 3/7/24 08:00, Robie Basak wrote:

Hi Mario,

Thank you for caring for the fwupd package in Ubuntu!



Sure.


One adminsitrative question: fwupd is in main and the Foundations team
are committed to looking after it. Is your proposal made on behalf of or
in coordination with the Foundations team? If not, what's the Foundation
team's view on your proposal?


I am part of ~ubuntu-foundations-team, but admittedly I have not 
conferred closely with other members.


I would invite discussion on any opposing views from other members.



On Sun, Feb 18, 2024 at 12:11:48AM -0600, Mario Limonciello wrote:

Considering all of that, I wanted to discuss with the release team to
modify the exception used for the firmware updating stack to allow
migrations from one stable branch to another; especially considering EOL
dates.
I've drafted an updated proposal in this wiki page and aligned it
directionally upstream:
https://wiki.ubuntu.com/firmware-updates-2.0

Can the release team please review and consider this?  If approved we can
just copy the text from the new page to the old page and delete the new
page.


In general we only grant general permission to make arbitrary feature
changes to packages in stable releases under specific circumstances[1].
Probably the relevant reasons in the case of this package would be for
hardware enablement purposes, or in the case of "Internet protocol"
changes (eg. for fwupd, perhaps the mechanism to fetch updates is
changing and will no longer work).

Notably, upstream advertising "EOL dates" is *not* a valid
justification. Consider this: Ubuntu already commits to supporting an
LTS release for 10 years. How many upstreams that "publish EOL dates"
would still be supporting their releases that we shipped by the end of
that period? I'd guess virtually zero. Clearly, we are committing to
"LTS-ness" for our entire stable release cycle *despite* "upstream EOL
dates" - in effect *extending* those dates for our users. Or, consider
what would happen if "upstream EOL dates" *were* justification for us to
make major version bumps to our packages. Near the end of our stable
release cycle, this would mean that we'd effectively become a rolling
release as every package for which upstream had published an "EOL date"
would need to be updated. Clearly this is not the intention, so clearly
"upstream EOL" cannot be a justification in itself for us to bump a
major version in a stable release.


I think there's a big difference between "not touching" and "supporting".

Due to the LVFS server changes that I've alluded to and Richard 
mentioned fwupd from 18.04 LTS and 16.04 are essentially dead software 
right now.


In a sense due to the upstream EOL dates the difficulty of "maintaining" 
very old versions becomes exponentially greater as the software progresses.


It's not my day job to maintain fwupd but it's something I like to work 
on upstream, and I do my best to keep it healthy where and when I can in 
Ubuntu.





I've drafted an updated proposal in this wiki page and aligned it
directionally upstream:
https://wiki.ubuntu.com/firmware-updates-2.0


One further note from your draft:


tarball releases only. No backported individual patches.


I understand the benefit of aligning with upstream. However this is only
possible if upstream policies completely align with distribution policy
and expectations. There is no guarantee of this in the future, so from a
policy point of view, distribution-specific patches must never be ruled
out by a general policy like this. Instead, I expect uploaders and the
SRU team to continue considering such patches on a case-by-case basis.
It is normal and a common occurrence for the SRU team to push back on a
large set of updates and ask for a minimal cherry-pick to minimise risk
to users, and I don't see any reason that the fwupd should diverge from
this position. Therefore, IMHO this stipulation cannot form part for a
policy that the SRU team can accept.


I understand the position; but I have been privy to patches that are 
backported "look" like they're complete but actually introducing a bug 
because they're missing non-obvious patches already on the stable branch.


This is a strong reason that we keep the CI infrastructure that relies 
upon device emulation working even on the stable upstream branches to 
catch even our cases of missing dependencies in cherry picks.  We're 
constantly improving this upstream and will be instituting a policy in 
the future that new (USB) plugins can't go in without emulation data for 
a real device.


Is there a happy medium?  Aim for updated tarballs but maybe a 
discussion with upstream before bringing SR

Re: [Metamath] Mnemonic of Fr

[Mario Carneiro]

My understanding is that it stands for "founded relation", as in
well-founded but without the "well", I think because it doesn't have any
other ordering properties like being a partial order attached to it.

On Wed, May 1, 2024 at 5:21 AM 'B. Wilson' via Metamath <
metamath@googlegroups.com> wrote:

> This has been bugging me midly for a while, but I couldn't figure out what
> the
> Fr symbol in df-fr stood for:
>
> 19201 df-fr $a |- ( R Fr A <-> A. x ( ( x C_ A /\ x =/= (/) ) -> E. y
> e. x A. z e. x -. z R y ) ) $.
>
> I finally bothered to look up the Takeuti and Zaring reference, which also
> uses
> "Fr" and calls R a "foundational relation". It's not super important, but
> would
> it be worth mentioning this in df-fr's comment?
>
> Cheers,
> B. Wilson
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/2F5KIFFJJY2KH.28Z6N87TP90O2%40wilsonb.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSsXfJqj3nGxjuDEFGCMAw8Zvq6AFF0wZ53qib3d8u%3DD3A%40mail.gmail.com.