May 2021 - Linux-stable-mirror

FAILED: patch "[PATCH] drm/i915/ilk-glk: Fix link training on links with LTTPRs" failed to apply to 5.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 984982f3ef7b240cd24c2feb2762d81d9d8da3c2 Mon Sep 17 00:00:00 2001 From: Imre Deak <imre.deak(a)intel.com> Date: Wed, 17 Mar 2021 20:48:59 +0200 Subject: [PATCH] drm/i915/ilk-glk: Fix link training on links with LTTPRs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The spec requires to use at least 3.2ms for the AUX timeout period if there are LT-tunable PHY Repeaters on the link (2.11.2). An upcoming spec update makes this more specific, by requiring a 3.2ms minimum timeout period for the LTTPR detection reading the 0xF0000-0xF0007 range (3.6.5.1). Accordingly disable LTTPR detection until GLK, where the maximum timeout we can set is only 1.6ms. Link training in the non-transparent mode is known to fail at least on some SKL systems with a WD19 dock on the link, which exposes an LTTPR (see the References below). While this could have different reasons besides the too short AUX timeout used, not detecting LTTPRs (and so not using the non-transparent LT mode) fixes link training on these systems. While at it add a code comment about the platform specific maximum timeout values. v2: Add a comment about the g4x maximum timeout as well. (Ville) Reported-by: Takashi Iwai <tiwai(a)suse.de> Reported-and-tested-by: Santiago Zarate <santiago.zarate(a)suse.com> Reported-and-tested-by: Bodo Graumann <mail(a)bodograumann.de> References: https://gitlab.freedesktop.org/drm/intel/-/issues/3166 Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link training") Cc: <stable(a)vger.kernel.org> # v5.11 Cc: Takashi Iwai <tiwai(a)suse.de> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Signed-off-by: Imre Deak <imre.deak(a)intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210317184901.4029798-2-imre… diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c b/drivers/gpu/drm/i915/display/intel_dp_aux.c index eaebf123310a..10fe17b7280d 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c @@ -133,6 +133,7 @@ static u32 g4x_get_aux_send_ctl(struct intel_dp *intel_dp, else precharge = 5; + /* Max timeout value on G4x-BDW: 1.6ms */ if (IS_BROADWELL(dev_priv)) timeout = DP_AUX_CH_CTL_TIME_OUT_600us; else @@ -159,6 +160,12 @@ static u32 skl_get_aux_send_ctl(struct intel_dp *intel_dp, enum phy phy = intel_port_to_phy(i915, dig_port->base.port); u32 ret; + /* + * Max timeout values: + * SKL-GLK: 1.6ms + * CNL: 3.2ms + * ICL+: 4ms + */ ret = DP_AUX_CH_CTL_SEND_BUSY | DP_AUX_CH_CTL_DONE | DP_AUX_CH_CTL_INTERRUPT | diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c b/drivers/gpu/drm/i915/display/intel_dp_link_training.c index 19ba7c7cbaab..c0e25c75c105 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c @@ -82,6 +82,18 @@ static void intel_dp_read_lttpr_phy_caps(struct intel_dp *intel_dp, static bool intel_dp_read_lttpr_common_caps(struct intel_dp *intel_dp) { + struct drm_i915_private *i915 = dp_to_i915(intel_dp); + + if (intel_dp_is_edp(intel_dp)) + return false; + + /* + * Detecting LTTPRs must be avoided on platforms with an AUX timeout + * period < 3.2ms. (see DP Standard v2.0, 2.11.2, 3.6.6.1). + */ + if (INTEL_GEN(i915) < 10) + return false; + if (drm_dp_read_lttpr_common_caps(&intel_dp->aux, intel_dp->lttpr_common_caps) < 0) { memset(intel_dp->lttpr_common_caps, 0, @@ -127,9 +139,6 @@ int intel_dp_lttpr_init(struct intel_dp *intel_dp) bool ret; int i; - if (intel_dp_is_edp(intel_dp)) - return 0; - ret = intel_dp_read_lttpr_common_caps(intel_dp); if (!ret) return 0;

3 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] drm: bridge/panel: Cleanup connector on bridge detach" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 4d906839d321c2efbf3fed4bc31ffd9ff55b75c0 Mon Sep 17 00:00:00 2001 From: Paul Cercueil <paul(a)crapouillou.net> Date: Sat, 27 Mar 2021 11:57:40 +0000 Subject: [PATCH] drm: bridge/panel: Cleanup connector on bridge detach If we don't call drm_connector_cleanup() manually in panel_bridge_detach(), the connector will be cleaned up with the other DRM objects in the call to drm_mode_config_cleanup(). However, since our drm_connector is devm-allocated, by the time drm_mode_config_cleanup() will be called, our connector will be long gone. Therefore, the connector must be cleaned up when the bridge is detached to avoid use-after-free conditions. v2: Cleanup connector only if it was created v3: Add FIXME v4: (Use connector->dev) directly in if() block Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.") Cc: <stable(a)vger.kernel.org> # 4.12+ Cc: Andrzej Hajda <a.hajda(a)samsung.com> Cc: Neil Armstrong <narmstrong(a)baylibre.com> Cc: Laurent Pinchart <Laurent.pinchart(a)ideasonboard.com> Cc: Jonas Karlman <jonas(a)kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec(a)siol.net> Signed-off-by: Paul Cercueil <paul(a)crapouillou.net> Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210327115742.18986-2-paul@c… diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c index 0ddc37551194..c916f4b8907e 100644 --- a/drivers/gpu/drm/bridge/panel.c +++ b/drivers/gpu/drm/bridge/panel.c @@ -87,6 +87,18 @@ static int panel_bridge_attach(struct drm_bridge *bridge, static void panel_bridge_detach(struct drm_bridge *bridge) { + struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge); + struct drm_connector *connector = &panel_bridge->connector; + + /* + * Cleanup the connector if we know it was initialized. + * + * FIXME: This wouldn't be needed if the panel_bridge structure was + * allocated with drmm_kzalloc(). This might be tricky since the + * drm_device pointer can only be retrieved when the bridge is attached. + */ + if (connector->dev) + drm_connector_cleanup(connector); } static void panel_bridge_pre_enable(struct drm_bridge *bridge)

3 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] drm: bridge/panel: Cleanup connector on bridge detach" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 4d906839d321c2efbf3fed4bc31ffd9ff55b75c0 Mon Sep 17 00:00:00 2001 From: Paul Cercueil <paul(a)crapouillou.net> Date: Sat, 27 Mar 2021 11:57:40 +0000 Subject: [PATCH] drm: bridge/panel: Cleanup connector on bridge detach If we don't call drm_connector_cleanup() manually in panel_bridge_detach(), the connector will be cleaned up with the other DRM objects in the call to drm_mode_config_cleanup(). However, since our drm_connector is devm-allocated, by the time drm_mode_config_cleanup() will be called, our connector will be long gone. Therefore, the connector must be cleaned up when the bridge is detached to avoid use-after-free conditions. v2: Cleanup connector only if it was created v3: Add FIXME v4: (Use connector->dev) directly in if() block Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.") Cc: <stable(a)vger.kernel.org> # 4.12+ Cc: Andrzej Hajda <a.hajda(a)samsung.com> Cc: Neil Armstrong <narmstrong(a)baylibre.com> Cc: Laurent Pinchart <Laurent.pinchart(a)ideasonboard.com> Cc: Jonas Karlman <jonas(a)kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec(a)siol.net> Signed-off-by: Paul Cercueil <paul(a)crapouillou.net> Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210327115742.18986-2-paul@c… diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c index 0ddc37551194..c916f4b8907e 100644 --- a/drivers/gpu/drm/bridge/panel.c +++ b/drivers/gpu/drm/bridge/panel.c @@ -87,6 +87,18 @@ static int panel_bridge_attach(struct drm_bridge *bridge, static void panel_bridge_detach(struct drm_bridge *bridge) { + struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge); + struct drm_connector *connector = &panel_bridge->connector; + + /* + * Cleanup the connector if we know it was initialized. + * + * FIXME: This wouldn't be needed if the panel_bridge structure was + * allocated with drmm_kzalloc(). This might be tricky since the + * drm_device pointer can only be retrieved when the bridge is attached. + */ + if (connector->dev) + drm_connector_cleanup(connector); } static void panel_bridge_pre_enable(struct drm_bridge *bridge)

3 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] drm: bridge/panel: Cleanup connector on bridge detach" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 4d906839d321c2efbf3fed4bc31ffd9ff55b75c0 Mon Sep 17 00:00:00 2001 From: Paul Cercueil <paul(a)crapouillou.net> Date: Sat, 27 Mar 2021 11:57:40 +0000 Subject: [PATCH] drm: bridge/panel: Cleanup connector on bridge detach If we don't call drm_connector_cleanup() manually in panel_bridge_detach(), the connector will be cleaned up with the other DRM objects in the call to drm_mode_config_cleanup(). However, since our drm_connector is devm-allocated, by the time drm_mode_config_cleanup() will be called, our connector will be long gone. Therefore, the connector must be cleaned up when the bridge is detached to avoid use-after-free conditions. v2: Cleanup connector only if it was created v3: Add FIXME v4: (Use connector->dev) directly in if() block Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.") Cc: <stable(a)vger.kernel.org> # 4.12+ Cc: Andrzej Hajda <a.hajda(a)samsung.com> Cc: Neil Armstrong <narmstrong(a)baylibre.com> Cc: Laurent Pinchart <Laurent.pinchart(a)ideasonboard.com> Cc: Jonas Karlman <jonas(a)kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec(a)siol.net> Signed-off-by: Paul Cercueil <paul(a)crapouillou.net> Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210327115742.18986-2-paul@c… diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c index 0ddc37551194..c916f4b8907e 100644 --- a/drivers/gpu/drm/bridge/panel.c +++ b/drivers/gpu/drm/bridge/panel.c @@ -87,6 +87,18 @@ static int panel_bridge_attach(struct drm_bridge *bridge, static void panel_bridge_detach(struct drm_bridge *bridge) { + struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge); + struct drm_connector *connector = &panel_bridge->connector; + + /* + * Cleanup the connector if we know it was initialized. + * + * FIXME: This wouldn't be needed if the panel_bridge structure was + * allocated with drmm_kzalloc(). This might be tricky since the + * drm_device pointer can only be retrieved when the bridge is attached. + */ + if (connector->dev) + drm_connector_cleanup(connector); } static void panel_bridge_pre_enable(struct drm_bridge *bridge)

3 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] drm/ingenic: Fix non-OSD mode" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 7b4957684e5d813fcbdc98144e3cc5c4467b3e2e Mon Sep 17 00:00:00 2001 From: Paul Cercueil <paul(a)crapouillou.net> Date: Sun, 24 Jan 2021 08:55:52 +0000 Subject: [PATCH] drm/ingenic: Fix non-OSD mode Even though the JZ4740 did not have the OSD mode, it had (according to the documentation) two DMA channels, but there is absolutely no information about how to select the second DMA channel. Make the ingenic-drm driver work in non-OSD mode by using the foreground0 plane (which is bound to the DMA0 channel) as the primary plane, instead of the foreground1 plane, which is the primary plane when in OSD mode. Fixes: 3c9bea4ef32b ("drm/ingenic: Add support for OSD mode") Cc: <stable(a)vger.kernel.org> # v5.8+ Signed-off-by: Paul Cercueil <paul(a)crapouillou.net> Acked-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Tested-by: H. Nikolaus Schaller <hns(a)goldelico.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210124085552.29146-5-paul@c… diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c index 54ee2cb61f3c..d60e1eefc9d1 100644 --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c @@ -561,7 +561,7 @@ static void ingenic_drm_plane_atomic_update(struct drm_plane *plane, height = newstate->src_h >> 16; cpp = newstate->fb->format->cpp[0]; - if (priv->soc_info->has_osd && plane->type == DRM_PLANE_TYPE_OVERLAY) + if (!priv->soc_info->has_osd || plane->type == DRM_PLANE_TYPE_OVERLAY) hwdesc = &priv->dma_hwdescs->hwdesc_f0; else hwdesc = &priv->dma_hwdescs->hwdesc_f1; @@ -833,6 +833,7 @@ static int ingenic_drm_bind(struct device *dev, bool has_components) const struct jz_soc_info *soc_info; struct ingenic_drm *priv; struct clk *parent_clk; + struct drm_plane *primary; struct drm_bridge *bridge; struct drm_panel *panel; struct drm_encoder *encoder; @@ -947,9 +948,11 @@ static int ingenic_drm_bind(struct device *dev, bool has_components) if (soc_info->has_osd) priv->ipu_plane = drm_plane_from_index(drm, 0); - drm_plane_helper_add(&priv->f1, &ingenic_drm_plane_helper_funcs); + primary = priv->soc_info->has_osd ? &priv->f1 : &priv->f0; - ret = drm_universal_plane_init(drm, &priv->f1, 1, + drm_plane_helper_add(primary, &ingenic_drm_plane_helper_funcs); + + ret = drm_universal_plane_init(drm, primary, 1, &ingenic_drm_primary_plane_funcs, priv->soc_info->formats_f1, priv->soc_info->num_formats_f1, @@ -961,7 +964,7 @@ static int ingenic_drm_bind(struct device *dev, bool has_components) drm_crtc_helper_add(&priv->crtc, &ingenic_drm_crtc_helper_funcs); - ret = drm_crtc_init_with_planes(drm, &priv->crtc, &priv->f1, + ret = drm_crtc_init_with_planes(drm, &priv->crtc, primary, NULL, &ingenic_drm_crtc_funcs, NULL); if (ret) { dev_err(dev, "Failed to init CRTC: %i\n", ret);

3 years, 8 months

1
0
0 0

[PATCH 0/2] drm/i915/gvt: Backport GVT BXT/APL fix to 5.10.y

by Colin Xu

commit a5a8ef937cfa79167f4b2a5602092b8d14fd6b9a upstream commit 4ceb06e7c336f4a8d3f3b6ac9a4fea2e9c97dc07 upstream Upstream intel-gvt fixed some breaking and GPU hang issues on BXT/APL platform but 5.10.y doesn't have so backport them. These patch have been rebased to linux-5.10.y. Colin Xu (2): drm/i915/gvt: Fix virtual display setup for BXT/APL drm/i915/gvt: Fix vfio_edid issue for BXT/APL drivers/gpu/drm/i915/gvt/display.c | 212 +++++++++++++++++++++++++++++ drivers/gpu/drm/i915/gvt/mmio.c | 5 + drivers/gpu/drm/i915/gvt/vgpu.c | 5 +- 3 files changed, 219 insertions(+), 3 deletions(-) -- 2.31.1

3 years, 8 months

2
3
0 0

FAILED: patch "[PATCH] thermal/core/fair share: Lock the thermal zone while looping" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From fef05776eb02238dcad8d5514e666a42572c3f32 Mon Sep 17 00:00:00 2001 From: Lukasz Luba <lukasz.luba(a)arm.com> Date: Thu, 22 Apr 2021 16:36:22 +0100 Subject: [PATCH] thermal/core/fair share: Lock the thermal zone while looping over instances The tz->lock must be hold during the looping over the instances in that thermal zone. This lock was missing in the governor code since the beginning, so it's hard to point into a particular commit. CC: stable(a)vger.kernel.org # 4.4+ Signed-off-by: Lukasz Luba <lukasz.luba(a)arm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> Link: https://lore.kernel.org/r/20210422153624.6074-2-lukasz.luba@arm.com diff --git a/drivers/thermal/gov_fair_share.c b/drivers/thermal/gov_fair_share.c index aaa07180ab48..645432ce6365 100644 --- a/drivers/thermal/gov_fair_share.c +++ b/drivers/thermal/gov_fair_share.c @@ -82,6 +82,8 @@ static int fair_share_throttle(struct thermal_zone_device *tz, int trip) int total_instance = 0; int cur_trip_level = get_trip_level(tz); + mutex_lock(&tz->lock); + list_for_each_entry(instance, &tz->thermal_instances, tz_node) { if (instance->trip != trip) continue; @@ -110,6 +112,8 @@ static int fair_share_throttle(struct thermal_zone_device *tz, int trip) mutex_unlock(&instance->cdev->lock); thermal_cdev_update(cdev); } + + mutex_unlock(&tz->lock); return 0; }

3 years, 8 months

2
1
0 0

FAILED: patch "[PATCH] FDDI: defxx: Make MMIO the configuration default except for" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 193ced4a79599352d63cb8c9e2f0c6043106eb6a Mon Sep 17 00:00:00 2001 From: "Maciej W. Rozycki" <macro(a)orcam.me.uk> Date: Wed, 10 Mar 2021 13:03:14 +0100 Subject: [PATCH] FDDI: defxx: Make MMIO the configuration default except for EISA Recent versions of the PCI Express specification have deprecated support for I/O transactions and actually some PCIe host bridges, such as Power Systems Host Bridge 4 (PHB4), do not implement them. The default kernel configuration choice for the defxx driver is the use of I/O ports rather than MMIO for PCI and EISA systems. It may have made sense as a conservative backwards compatible choice back when MMIO operation support was added to the driver as a part of TURBOchannel bus support. However nowadays this configuration choice makes the driver unusable with systems that do not implement I/O transactions for PCIe. Make DEFXX_MMIO the configuration default then, except where configured for EISA. This exception is because an EISA adapter can have its MMIO decoding disabled with ECU (EISA Configuration Utility) and therefore not available with the resource allocation infrastructure we implement, while port I/O is always readily available as it uses slot-specific addressing, directly mapped to the slot an option card has been placed in and handled with our EISA bus support core. Conversely a kernel that supports modern systems which may not have I/O transactions implemented for PCIe will usually not be expected to handle legacy EISA systems. The change of the default will make it easier for people, including but not limited to distribution packagers, to make a working choice for the driver. Update the option description accordingly and while at it replace the potentially ambiguous PIO acronym with IOP for "port I/O" vs "I/O ports" according to our nomenclature used elsewhere. Signed-off-by: Maciej W. Rozycki <macro(a)orcam.me.uk> Fixes: e89a2cfb7d7b ("[TC] defxx: TURBOchannel support") Cc: stable(a)vger.kernel.org # v2.6.21+ Signed-off-by: David S. Miller <davem(a)davemloft.net> diff --git a/drivers/net/fddi/Kconfig b/drivers/net/fddi/Kconfig index f722079dfb6a..f99c1048c97e 100644 --- a/drivers/net/fddi/Kconfig +++ b/drivers/net/fddi/Kconfig @@ -40,17 +40,20 @@ config DEFXX config DEFXX_MMIO bool - prompt "Use MMIO instead of PIO" if PCI || EISA + prompt "Use MMIO instead of IOP" if PCI || EISA depends on DEFXX - default n if PCI || EISA + default n if EISA default y help This instructs the driver to use EISA or PCI memory-mapped I/O - (MMIO) as appropriate instead of programmed I/O ports (PIO). + (MMIO) as appropriate instead of programmed I/O ports (IOP). Enabling this gives an improvement in processing time in parts - of the driver, but it may cause problems with EISA (DEFEA) - adapters. TURBOchannel does not have the concept of I/O ports, - so MMIO is always used for these (DEFTA) adapters. + of the driver, but it requires a memory window to be configured + for EISA (DEFEA) adapters that may not always be available. + Conversely some PCIe host bridges do not support IOP, so MMIO + may be required to access PCI (DEFPA) adapters on downstream PCI + buses with some systems. TURBOchannel does not have the concept + of I/O ports, so MMIO is always used for these (DEFTA) adapters. If unsure, say N.

3 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] FDDI: defxx: Make MMIO the configuration default except for" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 193ced4a79599352d63cb8c9e2f0c6043106eb6a Mon Sep 17 00:00:00 2001 From: "Maciej W. Rozycki" <macro(a)orcam.me.uk> Date: Wed, 10 Mar 2021 13:03:14 +0100 Subject: [PATCH] FDDI: defxx: Make MMIO the configuration default except for EISA Recent versions of the PCI Express specification have deprecated support for I/O transactions and actually some PCIe host bridges, such as Power Systems Host Bridge 4 (PHB4), do not implement them. The default kernel configuration choice for the defxx driver is the use of I/O ports rather than MMIO for PCI and EISA systems. It may have made sense as a conservative backwards compatible choice back when MMIO operation support was added to the driver as a part of TURBOchannel bus support. However nowadays this configuration choice makes the driver unusable with systems that do not implement I/O transactions for PCIe. Make DEFXX_MMIO the configuration default then, except where configured for EISA. This exception is because an EISA adapter can have its MMIO decoding disabled with ECU (EISA Configuration Utility) and therefore not available with the resource allocation infrastructure we implement, while port I/O is always readily available as it uses slot-specific addressing, directly mapped to the slot an option card has been placed in and handled with our EISA bus support core. Conversely a kernel that supports modern systems which may not have I/O transactions implemented for PCIe will usually not be expected to handle legacy EISA systems. The change of the default will make it easier for people, including but not limited to distribution packagers, to make a working choice for the driver. Update the option description accordingly and while at it replace the potentially ambiguous PIO acronym with IOP for "port I/O" vs "I/O ports" according to our nomenclature used elsewhere. Signed-off-by: Maciej W. Rozycki <macro(a)orcam.me.uk> Fixes: e89a2cfb7d7b ("[TC] defxx: TURBOchannel support") Cc: stable(a)vger.kernel.org # v2.6.21+ Signed-off-by: David S. Miller <davem(a)davemloft.net> diff --git a/drivers/net/fddi/Kconfig b/drivers/net/fddi/Kconfig index f722079dfb6a..f99c1048c97e 100644 --- a/drivers/net/fddi/Kconfig +++ b/drivers/net/fddi/Kconfig @@ -40,17 +40,20 @@ config DEFXX config DEFXX_MMIO bool - prompt "Use MMIO instead of PIO" if PCI || EISA + prompt "Use MMIO instead of IOP" if PCI || EISA depends on DEFXX - default n if PCI || EISA + default n if EISA default y help This instructs the driver to use EISA or PCI memory-mapped I/O - (MMIO) as appropriate instead of programmed I/O ports (PIO). + (MMIO) as appropriate instead of programmed I/O ports (IOP). Enabling this gives an improvement in processing time in parts - of the driver, but it may cause problems with EISA (DEFEA) - adapters. TURBOchannel does not have the concept of I/O ports, - so MMIO is always used for these (DEFTA) adapters. + of the driver, but it requires a memory window to be configured + for EISA (DEFEA) adapters that may not always be available. + Conversely some PCIe host bridges do not support IOP, so MMIO + may be required to access PCI (DEFPA) adapters on downstream PCI + buses with some systems. TURBOchannel does not have the concept + of I/O ports, so MMIO is always used for these (DEFTA) adapters. If unsure, say N.

3 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] FDDI: defxx: Make MMIO the configuration default except for" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 193ced4a79599352d63cb8c9e2f0c6043106eb6a Mon Sep 17 00:00:00 2001 From: "Maciej W. Rozycki" <macro(a)orcam.me.uk> Date: Wed, 10 Mar 2021 13:03:14 +0100 Subject: [PATCH] FDDI: defxx: Make MMIO the configuration default except for EISA Recent versions of the PCI Express specification have deprecated support for I/O transactions and actually some PCIe host bridges, such as Power Systems Host Bridge 4 (PHB4), do not implement them. The default kernel configuration choice for the defxx driver is the use of I/O ports rather than MMIO for PCI and EISA systems. It may have made sense as a conservative backwards compatible choice back when MMIO operation support was added to the driver as a part of TURBOchannel bus support. However nowadays this configuration choice makes the driver unusable with systems that do not implement I/O transactions for PCIe. Make DEFXX_MMIO the configuration default then, except where configured for EISA. This exception is because an EISA adapter can have its MMIO decoding disabled with ECU (EISA Configuration Utility) and therefore not available with the resource allocation infrastructure we implement, while port I/O is always readily available as it uses slot-specific addressing, directly mapped to the slot an option card has been placed in and handled with our EISA bus support core. Conversely a kernel that supports modern systems which may not have I/O transactions implemented for PCIe will usually not be expected to handle legacy EISA systems. The change of the default will make it easier for people, including but not limited to distribution packagers, to make a working choice for the driver. Update the option description accordingly and while at it replace the potentially ambiguous PIO acronym with IOP for "port I/O" vs "I/O ports" according to our nomenclature used elsewhere. Signed-off-by: Maciej W. Rozycki <macro(a)orcam.me.uk> Fixes: e89a2cfb7d7b ("[TC] defxx: TURBOchannel support") Cc: stable(a)vger.kernel.org # v2.6.21+ Signed-off-by: David S. Miller <davem(a)davemloft.net> diff --git a/drivers/net/fddi/Kconfig b/drivers/net/fddi/Kconfig index f722079dfb6a..f99c1048c97e 100644 --- a/drivers/net/fddi/Kconfig +++ b/drivers/net/fddi/Kconfig @@ -40,17 +40,20 @@ config DEFXX config DEFXX_MMIO bool - prompt "Use MMIO instead of PIO" if PCI || EISA + prompt "Use MMIO instead of IOP" if PCI || EISA depends on DEFXX - default n if PCI || EISA + default n if EISA default y help This instructs the driver to use EISA or PCI memory-mapped I/O - (MMIO) as appropriate instead of programmed I/O ports (PIO). + (MMIO) as appropriate instead of programmed I/O ports (IOP). Enabling this gives an improvement in processing time in parts - of the driver, but it may cause problems with EISA (DEFEA) - adapters. TURBOchannel does not have the concept of I/O ports, - so MMIO is always used for these (DEFTA) adapters. + of the driver, but it requires a memory window to be configured + for EISA (DEFEA) adapters that may not always be available. + Conversely some PCIe host bridges do not support IOP, so MMIO + may be required to access PCI (DEFPA) adapters on downstream PCI + buses with some systems. TURBOchannel does not have the concept + of I/O ports, so MMIO is always used for these (DEFTA) adapters. If unsure, say N.

3 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2021