- Linux-stable-mirror - lists.linaro.org

[PATCH] [RESEND] drm/i915/dp: Send DPCD ON for MST before phy_up

by Lyude Paul

As it turns out, the aux block being off was not the real problem here, as transition from D3 to D0 is mandated by the DP spec to take a maximum of 1ms, whereas we're allowed a 100ms timeframe to respond to ESI irqs. The real problem here is a bit more subtle. When doing a modeset where the problem of the sink timing out to our sideband requests when transitioning from D3 to D0 occurs, the timeout is from the aux block not coming on. However, nothing else times out other than the initial phy_up message because the DPCD on call in intel_ddi_enable_dp() ends up waking up the AUX block on the hub, not the phy_up sideband message. This means that the real fix we need is to use the DPMS on before sending a phy_up to ensure that the hub is ready to accept sideband messages. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan(a)intel.com> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: Laura Abbott <labbott(a)redhat.com> Cc: stable(a)vger.kernel.org Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.") --- Sorry for all the spam guys! This is my last attempt at getting this patch to actually come up on intel-gfx's patchwork page instead of dri-devel. I have no idea what is going on with patchwork right now :|, but maybe removing dri-devel from the CC entirely will help. drivers/gpu/drm/i915/intel_ddi.c | 6 +++++- drivers/gpu/drm/i915/intel_dp_mst.c | 1 + 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index a6672a9abd85..9bd675f73f7b 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -2324,7 +2324,11 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder, intel_prepare_dp_ddi_buffers(encoder, crtc_state); intel_ddi_init_dp_buf_reg(encoder); - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); + /* for MST, we do DPMS_ON outside of here so that DPMS_ON can happen + * before drm_dp_send_power_updown_phy() + */ + if (!intel_dp->is_mst) + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); intel_dp_start_link_train(intel_dp); if (port != PORT_A || INTEL_GEN(dev_priv) >= 9) intel_dp_stop_link_train(intel_dp); diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c index c3de0918ee13..eff9a4eae1f0 100644 --- a/drivers/gpu/drm/i915/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/intel_dp_mst.c @@ -223,6 +223,7 @@ static void intel_mst_pre_enable_dp(struct intel_encoder *encoder, DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links); + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); drm_dp_send_power_updown_phy(&intel_dp->mst_mgr, connector->port, true); if (intel_dp->active_mst_links == 0) intel_dig_port->base.pre_enable(&intel_dig_port->base, -- 2.14.3

7 years, 8 months

1
0
0 0

[PATCH] [RESEND] drm/i915/dp: Send DPCD ON for MST before phy_up

by Lyude Paul

As it turns out, the aux block being off was not the real problem here, as transition from D3 to D0 is mandated by the DP spec to take a maximum of 1ms, whereas we're allowed a 100ms timeframe to respond to ESI irqs. The real problem here is a bit more subtle. When doing a modeset where the problem of the sink timing out to our sideband requests when transitioning from D3 to D0 occurs, the timeout is from the aux block not coming on. However, nothing else times out other than the initial phy_up message because the DPCD on call in intel_ddi_enable_dp() ends up waking up the AUX block on the hub, not the phy_up sideband message. This means that the real fix we need is to use the DPMS on before sending a phy_up to ensure that the hub is ready to accept sideband messages. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan(a)intel.com> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: Laura Abbott <labbott(a)redhat.com> Cc: stable(a)vger.kernel.org Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.") --- drivers/gpu/drm/i915/intel_ddi.c | 6 +++++- drivers/gpu/drm/i915/intel_dp_mst.c | 1 + 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index a6672a9abd85..9bd675f73f7b 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -2324,7 +2324,11 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder, intel_prepare_dp_ddi_buffers(encoder, crtc_state); intel_ddi_init_dp_buf_reg(encoder); - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); + /* for MST, we do DPMS_ON outside of here so that DPMS_ON can happen + * before drm_dp_send_power_updown_phy() + */ + if (!intel_dp->is_mst) + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); intel_dp_start_link_train(intel_dp); if (port != PORT_A || INTEL_GEN(dev_priv) >= 9) intel_dp_stop_link_train(intel_dp); diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c index c3de0918ee13..eff9a4eae1f0 100644 --- a/drivers/gpu/drm/i915/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/intel_dp_mst.c @@ -223,6 +223,7 @@ static void intel_mst_pre_enable_dp(struct intel_encoder *encoder, DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links); + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); drm_dp_send_power_updown_phy(&intel_dp->mst_mgr, connector->port, true); if (intel_dp->active_mst_links == 0) intel_dig_port->base.pre_enable(&intel_dig_port->base, -- 2.14.3

7 years, 8 months

1
0
0 0

[nacked] mm-memblock-fix-potential-issue-in-memblock_search_pfn_nid.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/memblock: fix potential issue in memblock_search_pfn_nid() has been removed from the -mm tree. Its filename was mm-memblock-fix-potential-issue-in-memblock_search_pfn_nid.patch This patch was dropped because it was nacked ------------------------------------------------------ From: Wei Yang <richard.weiyang(a)gmail.com> Subject: mm/memblock: fix potential issue in memblock_search_pfn_nid() memblock_search_pfn_nid() returns the nid and the [start|end]_pfn of the memory region where pfn sits in. While the calculation of start_pfn has potential issue when the regions base is not page aligned. For example, we assume PAGE_SHIFT is 12 and base is 0x1234. Current implementation would return 1 while this is not correct. This patch fixes this by using PFN_UP(). The original commit is commit e76b63f80d93 ("memblock, numa: binary search node id") and merged in v3.12. Link: http://lkml.kernel.org/r/20180330033055.22340-1-richard.weiyang@gmail.com Fixes: e76b63f80d93 ("memblock, numa: binary search node id") Signed-off-by: Wei Yang <richard.weiyang(a)gmail.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Yinghai Lu <yinghai(a)kernel.org> Cc: Jia He <hejianet(a)gmail.com> Cc: <stable(a)vger.kernel.org> [3.12+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memblock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN mm/memblock.c~mm-memblock-fix-potential-issue-in-memblock_search_pfn_nid mm/memblock.c --- a/mm/memblock.c~mm-memblock-fix-potential-issue-in-memblock_search_pfn_nid +++ a/mm/memblock.c @@ -1646,7 +1646,7 @@ int __init_memblock memblock_search_pfn_ if (mid == -1) return -1; - *start_pfn = PFN_DOWN(type->regions[mid].base); + *start_pfn = PFN_UP(type->regions[mid].base); *end_pfn = PFN_DOWN(type->regions[mid].base + type->regions[mid].size); return type->regions[mid].nid; _ Patches currently in -mm which might be from richard.weiyang(a)gmail.com are mm-check-__highest_present_sectioin_nr-directly-in-memory_dev_init.patch

7 years, 8 months

1
0
0 0

+ lib-fix-stall-in-__bitmap_parselist.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: lib: fix stall in __bitmap_parselist() has been added to the -mm tree. Its filename is lib-fix-stall-in-__bitmap_parselist.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/lib-fix-stall-in-__bitmap_parselis… and later at http://ozlabs.org/~akpm/mmotm/broken-out/lib-fix-stall-in-__bitmap_parselis… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Yury Norov <ynorov(a)caviumnetworks.com> Subject: lib: fix stall in __bitmap_parselist() syzbot is catching stalls at __bitmap_parselist() (https://syzkaller.appspot.com/bug?id=ad7e0351fbc90535558514a71cd3edc1168199…). The trigger is unsigned long v = 0; bitmap_parselist("7:,", &v, BITS_PER_LONG); which results in hitting infinite loop at while (a <= b) { off = min(b - a + 1, used_size); bitmap_set(maskp, a, off); a += group_size; } due to used_size == group_size == 0. Link: http://lkml.kernel.org/r/20180404162647.15763-1-ynorov@caviumnetworks.com Fixes: 0a5ce0831d04382a ("lib/bitmap.c: make bitmap_parselist() thread-safe and much faster") Signed-off-by: Yury Norov <ynorov(a)caviumnetworks.com> Reported-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Reported-by: syzbot <syzbot+6887cbb011c8054e8a3d(a)syzkaller.appspotmail.com> Cc: Noam Camus <noamca(a)mellanox.com> Cc: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> Cc: Matthew Wilcox <mawilcox(a)microsoft.com> Cc: Mauro Carvalho Chehab <mchehab(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/bitmap.c | 2 +- lib/test_bitmap.c | 4 ++++ 2 files changed, 5 insertions(+), 1 deletion(-) diff -puN lib/bitmap.c~lib-fix-stall-in-__bitmap_parselist lib/bitmap.c --- a/lib/bitmap.c~lib-fix-stall-in-__bitmap_parselist +++ a/lib/bitmap.c @@ -607,7 +607,7 @@ static int __bitmap_parselist(const char /* if no digit is after '-', it's wrong*/ if (at_start && in_range) return -EINVAL; - if (!(a <= b) || !(used_size <= group_size)) + if (!(a <= b) || group_size == 0 || !(used_size <= group_size)) return -EINVAL; if (b >= nmaskbits) return -ERANGE; diff -puN lib/test_bitmap.c~lib-fix-stall-in-__bitmap_parselist lib/test_bitmap.c --- a/lib/test_bitmap.c~lib-fix-stall-in-__bitmap_parselist +++ a/lib/test_bitmap.c @@ -255,6 +255,10 @@ static const struct test_bitmap_parselis {-EINVAL, "-1", NULL, 8, 0}, {-EINVAL, "-0", NULL, 8, 0}, {-EINVAL, "10-1", NULL, 8, 0}, + {-EINVAL, "0-31:", NULL, 8, 0}, + {-EINVAL, "0-31:0", NULL, 8, 0}, + {-EINVAL, "0-31:0/0", NULL, 8, 0}, + {-EINVAL, "0-31:1/0", NULL, 8, 0}, {-EINVAL, "0-31:10/1", NULL, 8, 0}, }; _ Patches currently in -mm which might be from ynorov(a)caviumnetworks.com are lib-fix-stall-in-__bitmap_parselist.patch

7 years, 8 months

1
0
0 0

[PATCH] blk-mq: order getting budget and driver tag

by Ming Lei

This patch orders getting budget and driver tag by making sure to acquire driver tag after budget is got, this way can help to avoid the following race: 1) before dispatch request from scheduler queue, get one budget first, then dequeue a request, call it request A. 2) in another IO path for dispatching request B which is from hctx->dispatch, driver tag is got, then try to get budget in blk_mq_dispatch_rq_list(), unfortunately the budget is held by request A. 3) meantime blk_mq_dispatch_rq_list() is called for dispatching request A, and try to get driver tag first, unfortunately no driver tag is available because the driver tag is held by request B 4) both two IO pathes can't move on, and IO stall is caused. This issue can be observed when running dbench on USB storage. This patch fixes this issue by always getting budget before getting driver tag. Cc: stable(a)vger.kernel.org Fixes: de1482974080ec9e ("blk-mq: introduce .get_budget and .put_budget in blk_mq_ops") Cc: Christoph Hellwig <hch(a)lst.de> Cc: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Omar Sandoval <osandov(a)fb.com> Signed-off-by: Ming Lei <ming.lei(a)redhat.com> --- block/blk-mq.c | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/block/blk-mq.c b/block/blk-mq.c index 16e83e6df404..90838e998f66 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -1188,7 +1188,12 @@ bool blk_mq_dispatch_rq_list(struct request_queue *q, struct list_head *list, struct blk_mq_queue_data bd; rq = list_first_entry(list, struct request, queuelist); - if (!blk_mq_get_driver_tag(rq, &hctx, false)) { + + hctx = blk_mq_map_queue(rq->q, rq->mq_ctx->cpu); + if (!got_budget && !blk_mq_get_dispatch_budget(hctx)) + break; + + if (!blk_mq_get_driver_tag(rq, NULL, false)) { /* * The initial allocation attempt failed, so we need to * rerun the hardware queue when a tag is freed. The @@ -1197,8 +1202,7 @@ bool blk_mq_dispatch_rq_list(struct request_queue *q, struct list_head *list, * we'll re-run it below. */ if (!blk_mq_mark_tag_wait(&hctx, rq)) { - if (got_budget) - blk_mq_put_dispatch_budget(hctx); + blk_mq_put_dispatch_budget(hctx); /* * For non-shared tags, the RESTART check * will suffice. @@ -1209,11 +1213,6 @@ bool blk_mq_dispatch_rq_list(struct request_queue *q, struct list_head *list, } } - if (!got_budget && !blk_mq_get_dispatch_budget(hctx)) { - blk_mq_put_driver_tag(rq); - break; - } - list_del_init(&rq->queuelist); bd.rq = rq; @@ -1812,11 +1811,11 @@ static blk_status_t __blk_mq_try_issue_directly(struct blk_mq_hw_ctx *hctx, if (q->elevator && !bypass_insert) goto insert; - if (!blk_mq_get_driver_tag(rq, NULL, false)) + if (!blk_mq_get_dispatch_budget(hctx)) goto insert; - if (!blk_mq_get_dispatch_budget(hctx)) { - blk_mq_put_driver_tag(rq); + if (!blk_mq_get_driver_tag(rq, NULL, false)) { + blk_mq_put_dispatch_budget(hctx); goto insert; } -- 2.9.5

7 years, 8 months

2
1
0 0

[PATCH 1/1] drm/i915: Keep AUX block running when disabling DPMS for MST

by Lyude Paul

While enabling/disabling DPMS before link training with MST hubs is perfectly valid; unfortunately disabling DPMS results in some devices disabling their AUX CH block as well. For SST this isn't as much of a problem, but for MST we need to be able to continue handling aux transactions even when none of the sinks are turned on since it's possible for us to have a single atomic commit which results in disabling each downstream sink, followed by subsequently re-enabling each sink. If we don't do this, we'll end up stalling any pending ESI interrupts from the sink for up to 1ms. Unfortunately, dropping ESIs during this timespan makes it so that link fallback retraining for MST (which I will be submitting to the ML shortly) fails due to the channel EQ failure interrupts potentially getting dropped. Additionally, when performing a modeset that brings the hub status's link status from bad -> good having ESIs disabled for that long causes us to miss the hub's response to us trying to start link training as well. Since any sink with MST is going to support DisplayPort 1.2 anyway, save us the hassle of trying to wait until the sink comes back up and just never shut the aux block down. Changes since v2: - Fix patch name, no functional changes Changes since v3: - acks, t-b's Signed-off-by: Lyude Paul <lyude(a)redhat.com> Acked-by: Dhinakaran Pandiyan <dhinakaran.pandiyan(a)intel.com> Tested-by: Laura Abbott <labbott(a)redhat.com> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: stable(a)vger.kernel.org Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.") --- drivers/gpu/drm/i915/intel_dp.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 62f82c4298ac..0479c377981b 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode) return; if (mode != DRM_MODE_DPMS_ON) { + unsigned char data = intel_dp->is_mst ? + DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3; + if (downstream_hpd_needs_d0(intel_dp)) return; - ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER, - DP_SET_POWER_D3); + ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER, data); } else { struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp); -- 2.14.3

7 years, 8 months

1
0
0 0

[PATCH v2][RESEND] drm/i915: Keep AUX block running when disabling DPMS for MST

by Lyude Paul

While enabling/disabling DPMS before link training with MST hubs is perfectly valid; unfortunately disabling DPMS results in some devices disabling their AUX CH block as well. For SST this isn't as much of a problem, but for MST we need to be able to continue handling aux transactions even when none of the sinks are turned on since it's possible for us to have a single atomic commit which results in disabling each downstream sink, followed by subsequently re-enabling each sink. If we don't do this, we'll end up stalling any pending ESI interrupts from the sink for up to 1ms. Unfortunately, dropping ESIs during this timespan makes it so that link fallback retraining for MST (which I will be submitting to the ML shortly) fails due to the channel EQ failure interrupts potentially getting dropped. Additionally, when performing a modeset that brings the hub status's link status from bad -> good having ESIs disabled for that long causes us to miss the hub's response to us trying to start link training as well. Since any sink with MST is going to support DisplayPort 1.2 anyway, save us the hassle of trying to wait until the sink comes back up and just never shut the aux block down. Changes since v2: - Fix patch name, no functional changes Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: Laura Abbott <labbott(a)redhat.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan(a)intel.com> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: stable(a)vger.kernel.org Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.") --- drivers/gpu/drm/i915/intel_dp.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 62f82c4298ac..0479c377981b 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode) return; if (mode != DRM_MODE_DPMS_ON) { + unsigned char data = intel_dp->is_mst ? + DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3; + if (downstream_hpd_needs_d0(intel_dp)) return; - ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER, - DP_SET_POWER_D3); + ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER, data); } else { struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp); -- 2.14.3

7 years, 8 months

1
0
0 0

[PATCH] Revert "scsi: core: return BLK_STS_OK for DID_OK in __scsi_error_from_host_byte()"

by Bart Van Assche

The description of commit e39a97353e53 is wrong: it mentions that commit 2a842acab109 introduced a bug in __scsi_error_from_host_byte() although that commit did not change the behavior of that function. Additionally, that commit introduced a severe bug: it causes commands that fail with hostbyte=DID_OK and driverbyte=DRIVER_SENSE to be completed with BLK_STS_OK. Although that commit claims to fix a bug it does not mention which bug it fixes. Hence revert that commit. Fixes: e39a97353e53 ("scsi: core: return BLK_STS_OK for DID_OK in __scsi_error_from_host_byte()") Reported-by: Damien Le Moal <damien.lemoal(a)wdc.com> Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Hannes Reinecke <hare(a)suse.com> Cc: Douglas Gilbert <dgilbert(a)interlog.com> Cc: Damien Le Moal <damien.lemoal(a)wdc.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: stable(a)vger.kernel.org --- drivers/scsi/scsi_lib.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index 74a39db57d49..71f5b010684c 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -735,8 +735,6 @@ static blk_status_t __scsi_error_from_host_byte(struct scsi_cmnd *cmd, int result) { switch (host_byte(result)) { - case DID_OK: - return BLK_STS_OK; case DID_TRANSPORT_FAILFAST: return BLK_STS_TRANSPORT; case DID_TARGET_FAILURE: -- 2.16.2

7 years, 8 months

2
1
0 0

[PATCH] w1: gpio: fix problem with platfom data in w1-gpio

by Pawel Dembicki

In devices, where fdt is used, is impossible to apply platform data without proper fdt node. This patch allow to use platform data in devices with fdt. Signed-off-by: Pawel Dembicki <paweldembicki(a)gmail.com> --- drivers/w1/masters/w1-gpio.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/w1/masters/w1-gpio.c b/drivers/w1/masters/w1-gpio.c index a90728ceec5a..7b80762941af 100644 --- a/drivers/w1/masters/w1-gpio.c +++ b/drivers/w1/masters/w1-gpio.c @@ -112,17 +112,16 @@ static int w1_gpio_probe_dt(struct platform_device *pdev) static int w1_gpio_probe(struct platform_device *pdev) { struct w1_bus_master *master; - struct w1_gpio_platform_data *pdata; + struct w1_gpio_platform_data *pdata = dev_get_platdata(&pdev->dev); int err; - if (of_have_populated_dt()) { + if (of_have_populated_dt() && !pdata) { err = w1_gpio_probe_dt(pdev); if (err < 0) return err; + pdata = dev_get_platdata(&pdev->dev); } - pdata = dev_get_platdata(&pdev->dev); - if (!pdata) { dev_err(&pdev->dev, "No configuration data\n"); return -ENXIO; -- 2.14.1

7 years, 8 months

4
7
0 0

[PATCHv2] scsi: Fix failed request error code

by Hannes Reinecke

With the introduction of commit e39a97353e53 ("scsi: core: return BLK_STS_OK for DID_OK in __scsi_error_from_host_byte()"), a command that failed with hostbyte=DID_OK and driverbyte=DRIVER_SENSE but lacking additional sense information will have a return code set to BLK_STS_OK. This results in the request issuer to see successful request execution despite the failure. An example of such case is an unaligned write on a host managed ZAC disk connected to a SAS HBA with a malfunctioning SAT. The unaligned write command gets aborted but has no additional sense information. sd 10:0:0:0: [sde] tag#3905 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE sd 10:0:0:0: [sde] tag#3905 Sense Key : Aborted Command [current] sd 10:0:0:0: [sde] tag#3905 Add. Sense: No additional sense information sd 10:0:0:0: [sde] tag#3905 CDB: Write(16) 8a 00 00 00 00 00 02 0c 00 01 00 00 00 01 00 00 print_req_error: I/O error, dev sde, sector 274726920 In scsi_io_completion(), sense key handling to not change the request error code and success being reported to the issuer. Fix this by making sure that the error code always indicates an error if scsi_io_completion() decide that the action to be taken for a failed command is to not retry it and terminate it immediately (ACTION_FAIL) . Signed-off-by: Damien Le Moal <damien.lemoal(a)wdc.com> Signed-off-by: Hannes Reinecke <hare(a)suse.com> Fixes: e39a97353e53 ("scsi: core: return BLK_STS_OK for DID_OK in __scsi_error_from_host_byte()") Cc: <stable(a)vger.kernel.org> --- drivers/scsi/scsi_lib.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index 393f9db8f41b..9389c41e2829 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -905,6 +905,12 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned int good_bytes) goto requeue; error = __scsi_error_from_host_byte(cmd, result); + /* + * If the hostbyte was DID_OK, but the sense code is valid + * we always should set BLK_STS_IOERR. + */ + if (error == BLK_STS_OK && sense_valid) + error = BLK_STS_IOERR; if (host_byte(result) == DID_RESET) { /* Third party bus reset or reset for error recovery -- 2.12.3

7 years, 8 months

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror