Disable power_down by setting the parameter to
DWC2_POWER_DOWN_PARAM_NONE. This fixes a problem on various Amlogic
Meson SoCs where USB devices are only recognized when plugged in before
booting Linux. A hot-plugged USB device was not detected even though the
device got power (my USB thumb drive for example has an LED which lit
up).
A similar fix was implemented for Rockchip SoCs in commit c216765d3a1def
("usb: dwc2: disable power_down on rockchip devices"). That commit
suggests that a change in the dwc2 driver is the cause because the
default value for the "hibernate" parameter (which then got renamed to
"power_down" to support other modes) was changed in the v4.17 merge
window with:
commit 6d23ee9caa6790 ("Merge tag 'usb-for-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-testing").
Cc: <stable(a)vger.kernel.org> # 4.19
Suggested-by: Christian Hewitt <christianshewitt(a)gmail.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl(a)googlemail.com>
---
drivers/usb/dwc2/params.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index 7c1b6938f212..38c813b1d203 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -111,6 +111,7 @@ static void dwc2_set_amlogic_params(struct dwc2_hsotg *hsotg)
p->phy_type = DWC2_PHY_TYPE_PARAM_UTMI;
p->ahbcfg = GAHBCFG_HBSTLEN_INCR8 <<
GAHBCFG_HBSTLEN_SHIFT;
+ p->power_down = DWC2_POWER_DOWN_PARAM_NONE;
}
static void dwc2_set_amcc_params(struct dwc2_hsotg *hsotg)
--
2.19.2
Zebu boards were added in v4.9 and then renamed to "haps" in v4.10.
Thus backporting
commit 64234961c145 (ARC: configs: Remove CONFIG_INITRAMFS_SOURCE from defconfigs)
we missed "zebu" defconfigs in v4.9.
Note this is only applicable to "linux-4.9.y"!
Spotted by KerneCI, see [1].
[1] https://storage.kernelci.org/stable/linux-4.9.y/v4.9.144/arc/zebu_hs_smp_de…
Signed-off-by: Alexey Brodkin <abrodkin(a)synopsys.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Kevin Hilman <khilman(a)baylibre.com>
---
arch/arc/configs/zebu_hs_defconfig | 1 -
arch/arc/configs/zebu_hs_smp_defconfig | 1 -
2 files changed, 2 deletions(-)
diff --git a/arch/arc/configs/zebu_hs_defconfig b/arch/arc/configs/zebu_hs_defconfig
index 9f6166be7145..3346829b02bb 100644
--- a/arch/arc/configs/zebu_hs_defconfig
+++ b/arch/arc/configs/zebu_hs_defconfig
@@ -11,7 +11,6 @@ CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_PID_NS is not set
CONFIG_BLK_DEV_INITRD=y
-CONFIG_INITRAMFS_SOURCE="../../arc_initramfs_hs/"
CONFIG_EXPERT=y
CONFIG_PERF_EVENTS=y
# CONFIG_COMPAT_BRK is not set
diff --git a/arch/arc/configs/zebu_hs_smp_defconfig b/arch/arc/configs/zebu_hs_smp_defconfig
index 44e9693f4257..4471f9c37d7e 100644
--- a/arch/arc/configs/zebu_hs_smp_defconfig
+++ b/arch/arc/configs/zebu_hs_smp_defconfig
@@ -11,7 +11,6 @@ CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_PID_NS is not set
CONFIG_BLK_DEV_INITRD=y
-CONFIG_INITRAMFS_SOURCE="../../arc_initramfs_hs/"
CONFIG_EMBEDDED=y
CONFIG_PERF_EVENTS=y
# CONFIG_VM_EVENT_COUNTERS is not set
--
2.16.2
On Sun, Dec 09, 2018 at 11:44:19AM -0500, Theodore Y. Ts'o wrote:
> On Sun, Dec 09, 2018 at 12:30:39PM +0100, Greg KH wrote:
> > > P.P.P.S. If I were king, I'd be asking for a huge number of kunit
> > > tests for block-mq to be developed, and then running them under a
> > > Thread Sanitizer.
> >
> > Isn't that what xfs and fio is? Aren't we running this all the time and
> > reporting those issues? How did this bug not show up on those tests, is
> > it just because they didn't run long enough?
> >
> > Because of those test suites, I was thinking that the block and
> > filesystem paths were one of the more well-tested things we had at the
> > moment, is this not true?
>
> I'm pretty confident about the file system paths, and the "happy
> paths" for the block layer.
>
> But with Kernel Bugzilla #201685, despite huge amounts both before and
> after 4.19-rc1, nothing picked it up. It turned out to be very
> configuration specific, *and* only happened when you were under heavy
> memory pressure and/or I/O pressure.
>
> I'm starting to try to use blktests, but it's not as mature as
> xfstests. It has portability issues, as it assumes a much newer
> userspace. So I can't even run it under some environments at all.
> The test coverage just isn't as broad. Compare:
>
> ext4/4k: 441 tests, 1 failures, 42 skipped, 4387 seconds
> Failures: generic/388
>
> Versus:
>
> Run: block/001 block/002 block/003 block/004 block/005 block/006
> block/009 block/010 block/012 block/013 block/014 block/015
> block/016 block/017 block/018 block/020 block/021 block/023
> block/024 loop/001 loop/002 loop/003 loop/004 loop/005 loop/006
> nvme/002 nvme/003 nvme/004 nvme/006 nvme/007 nvme/008 nvme/009
> nvme/010 nvme/011 nvme/012 nvme/013 nvme/014 nvme/015 nvme/016
> nvme/017 nvme/019 nvme/020 nvme/021 nvme/022 nvme/023 nvme/024
> nvme/025 nvme/026 nvme/027 nvme/028 scsi/001 scsi/002 scsi/003
> scsi/004 scsi/005 scsi/006 srp/001 srp/002 srp/003 srp/004
> srp/005 srp/006 srp/007 srp/008 srp/009 srp/010 srp/011 srp/012 srp/013
> Failures: block/017 block/024 nvme/002 nvme/003 nvme/008 nvme/009
> nvme/010 nvme/011 nvme/012 nvme/013 nvme/014 nvme/015 nvme/016
> nvme/019 nvme/020 nvme/021 nvme/022 nvme/023 nvme/024 nvme/025
> nvme/026 nvme/027 nvme/028 scsi/006 srp/001 srp/002 srp/003 srp/004
> srp/005 srp/006 srp/007 srp/008 srp/009 srp/010 srp/011 srp/012 srp/013
> Failed 37 of 69 tests
>
> (Most of the failures are test portability issues that I still need to
> work through, not real failures. But just look at the number of
> tests....)
So you are saying quantity rules over quantity? :)
It's really hard to judge this, given that xfstests are testing a whole
range of other things (POSIX compliance and stressing the vfs api),
while blktests are there to stress the block i/o api/interface.
So both would be best to run as we know xfstests also hits the block
layer...
thanks,
greg k-h