* [Xen-devel] [linux-5.4 test] 147001: regressions - FAIL
From: osstest service owner @ 2020-02-14 19:18 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 147001 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147001/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 146121
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 146121
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 146121
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail REGR. vs. 146121
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-pvshim 12 guest-start fail never pass
test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-i386-libvirt 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass
test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt 13 migrate-support-check fail never pass
test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass
test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass
test-arm64-arm64-xl 13 migrate-support-check fail never pass
test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass
test-arm64-arm64-xl 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass
test-armhf-armhf-xl 13 migrate-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass
test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass
test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
version targeted for testing:
linux d6591ea2dd1a44b1c72c5a3e3b6555d7585acdae
baseline version:
linux 122179cb7d648a6f36b20dd6bf34f953cb384c30
Last test of basis 146121 2020-01-15 17:42:04 Z 30 days
Failing since 146178 2020-01-17 02:59:07 Z 28 days 59 attempts
Testing same since 146876 2020-02-11 13:39:51 Z 3 days 3 attempts
------------------------------------------------------------
1007 people touched revisions under test,
not listing them all
jobs:
build-amd64-xsm pass
build-arm64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-arm64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-arm64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-arm64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-arm64-arm64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass
test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-arm64-arm64-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-arm64-arm64-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvhv2-amd pass
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
test-amd64-i386-xl-qemuu-ovmf-amd64 fail
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-qemut-ws16-amd64 fail
test-amd64-i386-xl-qemut-ws16-amd64 fail
test-amd64-amd64-xl-qemuu-ws16-amd64 fail
test-amd64-i386-xl-qemuu-ws16-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit1 pass
test-arm64-arm64-xl-credit1 pass
test-armhf-armhf-xl-credit1 pass
test-amd64-amd64-xl-credit2 pass
test-arm64-arm64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass
test-amd64-amd64-examine pass
test-arm64-arm64-examine pass
test-armhf-armhf-examine pass
test-amd64-i386-examine pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-amd64-qemuu-nested-intel fail
test-amd64-amd64-xl-pvhv2-intel pass
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-xl-pvshim pass
test-amd64-i386-xl-pvshim fail
test-amd64-amd64-pygrub pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw pass
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds fail
test-armhf-armhf-xl-rtds pass
test-arm64-arm64-xl-seattle pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-amd64-xl-shadow pass
test-amd64-i386-xl-shadow pass
test-arm64-arm64-xl-thunderx pass
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
(No revision log; it would be 52571 lines long.)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [PATCH AUTOSEL 4.14 140/186] ide: remove set but not used variable 'hwif'
From: Sasha Levin @ 2020-02-14 16:16 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Wang Hai, linux-ide, Hulk Robot, linuxppc-dev,
David S . Miller
In-Reply-To: <20200214161715.18113-1-sashal@kernel.org>
From: Wang Hai <wanghai38@huawei.com>
[ Upstream commit 98949a1946d70771789def0c9dbc239497f9f138 ]
Fix the following gcc warning:
drivers/ide/pmac.c: In function pmac_ide_setup_device:
drivers/ide/pmac.c:1027:14: warning: variable hwif set but not used
[-Wunused-but-set-variable]
Fixes: d58b0c39e32f ("powerpc/macio: Rework hotplug media bay support")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/ide/pmac.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/ide/pmac.c b/drivers/ide/pmac.c
index 203ed4adc04ae..7db083ec5ee06 100644
--- a/drivers/ide/pmac.c
+++ b/drivers/ide/pmac.c
@@ -1024,7 +1024,6 @@ static int pmac_ide_setup_device(pmac_ide_hwif_t *pmif, struct ide_hw *hw)
struct device_node *np = pmif->node;
const int *bidp;
struct ide_host *host;
- ide_hwif_t *hwif;
struct ide_hw *hws[] = { hw };
struct ide_port_info d = pmac_port_info;
int rc;
@@ -1080,7 +1079,7 @@ static int pmac_ide_setup_device(pmac_ide_hwif_t *pmif, struct ide_hw *hw)
rc = -ENOMEM;
goto bail;
}
- hwif = pmif->hwif = host->ports[0];
+ pmif->hwif = host->ports[0];
if (on_media_bay(pmif)) {
/* Fixup bus ID for media bay */
--
2.20.1
^ permalink raw reply related
* [Virtio-fs] virtiofs on top of overlayfs
From: Vivek Goyal @ 2020-02-14 19:20 UTC (permalink / raw)
To: virtio-fs-list, eric.ernst; +Cc: Mrunal Patel, Miklos Szeredi
Hi Eric,
Was talking to Mrunal and he said you mentioned that virtiofs on top of
overlayfs has some issues.
I can't remember any issues and thought it should just work. Would you
remember the specific issue you faced with this configuraiton.
Have kata continaers tried using virtiofs on top overlayfs.
Thanks
Vivek
^ permalink raw reply
* Re: [PATCH 0/9] recipe updates, testing fixes
From: Alexander Kanavin @ 2020-02-14 19:21 UTC (permalink / raw)
To: Khem Raj; +Cc: OE-core
In-Reply-To: <CANNYZj-MhZhZ1QANwkQxiqCU8dtt5Mn3LzPTtqkB5-BCekDU3w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1306 bytes --]
I got to it finally. Normally /var/lib/rpm is absent when opkg is in use,
but when /usr/bin/rpm is present, python3's ptest involves distutils test
creating rpm packages (and presumably installing them too), which creates a
database in /var/lib/rpm, which then triggers rpm tests to run and fail. So
a check for /var/lib/rpm in rpm tests isn't always sufficient to determine
which packaging system is in use, and there should be a stronger one.
I'm fine with adjusting libsolv to not pull in rpm, but please use
EXCLUDE_FROM_WORLD instead of PNBLACKLIST, so that just that specific
problem is solved, rather than banning libdnf/dnf altogether from builds.
Making libdnf to not require rpm-enabled libsolv is not feasible sadly,
it's basically built around that assumption.
Alex
On Fri, 14 Feb 2020 at 13:19, Alexander Kanavin <alex.kanavin@gmail.com>
wrote:
> On Fri, 14 Feb 2020 at 08:15, Khem Raj <raj.khem@gmail.com> wrote:
>
>> local.conf I have
>>
>> DISTRO_FEATURES_append = " largefile opengl ptest multiarch wayland pam
>> polkit "
>> IMAGE_CLASSES += "testimage testsdk"
>>
>
> Right, I'm running this now, it's a bit tricky because I have to do it on
> the Yocto AB. Big company's bureaucracy is causing delays in getting me a
> build machine :(
>
> Alex
>
[-- Attachment #2: Type: text/html, Size: 2011 bytes --]
^ permalink raw reply
* [PATCH v6 0/2] Convert period and duty cycle to u64
From: Guru Das Srinagesh @ 2020-02-14 19:22 UTC (permalink / raw)
To: linux-pwm
Cc: Thierry Reding, Uwe Kleine-König, Subbaraman Narayanamurthy,
linux-kernel, Guru Das Srinagesh
Reworked the change pushed upstream earlier [1] so as to not add an extension
to an obsolete API. With this change, pwm_ops->apply() can be used to set
pwm_state parameters as usual.
[1] https://lore.kernel.org/lkml/20190916140048.GB7488@ulmo/
Changes from v1:
- Fixed compilation errors seen when compiling for different archs.
Changes from v2:
- Fixed %u -> %llu in a dev_dbg in pwm-stm32-lp.c, thanks to kbuild test robot
- Added a couple of fixes to pwm-imx-tpm.c and pwm-sifive.c
Changes from v3:
- Rebased to current tip of for-next.
Changes from v4:
- Split the patch into two: one for changes to the drivers, and the actual
switch to u64 for ease of reverting should the need arise.
- Re-examined the patch and made the following corrections:
* intel_panel.c:
DIV64_U64_ROUND_UP -> DIV_ROUND_UP_ULL (as only the numerator would be
64-bit in this case).
* pwm-sti.c:
do_div -> div_u64 (do_div is optimized only for x86 architectures, and
div_u64's comment block suggests to use this as much as possible).
Changes from v5:
- Dropped the conversion of struct pwm_capture to u64 for reasons mentioned
in https://www.spinics.net/lists/linux-pwm/msg11541.html.
Guru Das Srinagesh (2):
pwm: Convert drivers to use 64-bit period and duty cycle
pwm: core: Convert period and duty cycle to u64
drivers/clk/clk-pwm.c | 2 +-
drivers/gpu/drm/i915/display/intel_panel.c | 2 +-
drivers/hwmon/pwm-fan.c | 2 +-
drivers/media/rc/ir-rx51.c | 3 ++-
drivers/pwm/core.c | 4 ++--
drivers/pwm/pwm-clps711x.c | 2 +-
drivers/pwm/pwm-imx-tpm.c | 2 +-
drivers/pwm/pwm-imx27.c | 5 ++---
drivers/pwm/pwm-sifive.c | 2 +-
drivers/pwm/pwm-sti.c | 5 +++--
drivers/pwm/pwm-stm32-lp.c | 2 +-
drivers/pwm/pwm-sun4i.c | 2 +-
drivers/pwm/sysfs.c | 8 ++++----
drivers/video/backlight/pwm_bl.c | 3 ++-
include/linux/pwm.h | 12 ++++++------
15 files changed, 29 insertions(+), 27 deletions(-)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v6 1/2] pwm: Convert drivers to use 64-bit period and duty cycle
From: Guru Das Srinagesh @ 2020-02-14 19:22 UTC (permalink / raw)
To: linux-pwm
Cc: Thierry Reding, Uwe Kleine-König, Subbaraman Narayanamurthy,
linux-kernel, Guru Das Srinagesh
In-Reply-To: <cover.1581706694.git.gurus@codeaurora.org>
Because period and duty cycle are defined in the PWM framework structs
as ints with units of nanoseconds, the maximum time duration that can be
set is limited to ~2.147 seconds. Redefining them as u64 values will
enable larger time durations to be set.
As a first step, prepare drivers to handle the switch to u64 period and
duty_cycle by making the relevant fixes to those drivers that use the
period and duty_cycle pwm struct members in division operations, viz.
replacing the division operations with 64-bit division macros as
appropriate. The actual switch to u64 period and duty_cycle follows as a
separate patch.
Where the dividend is 64-bit but the divisor is 32-bit, use *_ULL
macros:
- DIV_ROUND_UP_ULL
- DIV_ROUND_CLOSEST_ULL
- div_u64
Where the divisor is 64-bit (dividend may be 32-bit or 64-bit), use
DIV64_* macros:
- DIV64_U64_ROUND_CLOSEST
- div64_u64
The kbuild test robot helped to improve this patch by catching a couple
of code sites that had to be adapted.
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
---
drivers/clk/clk-pwm.c | 2 +-
drivers/gpu/drm/i915/display/intel_panel.c | 2 +-
drivers/hwmon/pwm-fan.c | 2 +-
drivers/media/rc/ir-rx51.c | 3 ++-
drivers/pwm/pwm-clps711x.c | 2 +-
drivers/pwm/pwm-imx-tpm.c | 2 +-
drivers/pwm/pwm-imx27.c | 5 ++---
drivers/pwm/pwm-sifive.c | 2 +-
drivers/pwm/pwm-sti.c | 5 +++--
drivers/pwm/pwm-stm32-lp.c | 2 +-
drivers/pwm/pwm-sun4i.c | 2 +-
drivers/video/backlight/pwm_bl.c | 3 ++-
12 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/drivers/clk/clk-pwm.c b/drivers/clk/clk-pwm.c
index 87fe0b0e..7b1f7a0 100644
--- a/drivers/clk/clk-pwm.c
+++ b/drivers/clk/clk-pwm.c
@@ -89,7 +89,7 @@ static int clk_pwm_probe(struct platform_device *pdev)
}
if (of_property_read_u32(node, "clock-frequency", &clk_pwm->fixed_rate))
- clk_pwm->fixed_rate = NSEC_PER_SEC / pargs.period;
+ clk_pwm->fixed_rate = div64_u64(NSEC_PER_SEC, pargs.period);
if (pargs.period != NSEC_PER_SEC / clk_pwm->fixed_rate &&
pargs.period != DIV_ROUND_UP(NSEC_PER_SEC, clk_pwm->fixed_rate)) {
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c b/drivers/gpu/drm/i915/display/intel_panel.c
index bc14e9c..843cac1 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -1868,7 +1868,7 @@ static int pwm_setup_backlight(struct intel_connector *connector,
panel->backlight.min = 0; /* 0% */
panel->backlight.max = 100; /* 100% */
- panel->backlight.level = DIV_ROUND_UP(
+ panel->backlight.level = DIV_ROUND_UP_ULL(
pwm_get_duty_cycle(panel->backlight.pwm) * 100,
CRC_PMIC_PWM_PERIOD_NS);
panel->backlight.enabled = panel->backlight.level != 0;
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 42ffd2e..283423a 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -437,7 +437,7 @@ static int pwm_fan_resume(struct device *dev)
return 0;
pwm_get_args(ctx->pwm, &pargs);
- duty = DIV_ROUND_UP(ctx->pwm_value * (pargs.period - 1), MAX_PWM);
+ duty = DIV_ROUND_UP_ULL(ctx->pwm_value * (pargs.period - 1), MAX_PWM);
ret = pwm_config(ctx->pwm, duty, pargs.period);
if (ret)
return ret;
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 8574eda..9a5dfd7 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -241,7 +241,8 @@ static int ir_rx51_probe(struct platform_device *dev)
}
/* Use default, in case userspace does not set the carrier */
- ir_rx51.freq = DIV_ROUND_CLOSEST(pwm_get_period(pwm), NSEC_PER_SEC);
+ ir_rx51.freq = DIV_ROUND_CLOSEST_ULL(pwm_get_period(pwm),
+ NSEC_PER_SEC);
pwm_put(pwm);
hrtimer_init(&ir_rx51.timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
diff --git a/drivers/pwm/pwm-clps711x.c b/drivers/pwm/pwm-clps711x.c
index 924d39a..ba9500a 100644
--- a/drivers/pwm/pwm-clps711x.c
+++ b/drivers/pwm/pwm-clps711x.c
@@ -43,7 +43,7 @@ static void clps711x_pwm_update_val(struct clps711x_chip *priv, u32 n, u32 v)
static unsigned int clps711x_get_duty(struct pwm_device *pwm, unsigned int v)
{
/* Duty cycle 0..15 max */
- return DIV_ROUND_CLOSEST(v * 0xf, pwm->args.period);
+ return DIV64_U64_ROUND_CLOSEST(v * 0xf, pwm->args.period);
}
static int clps711x_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
diff --git a/drivers/pwm/pwm-imx-tpm.c b/drivers/pwm/pwm-imx-tpm.c
index 9145f61..53bf364 100644
--- a/drivers/pwm/pwm-imx-tpm.c
+++ b/drivers/pwm/pwm-imx-tpm.c
@@ -126,7 +126,7 @@ static int pwm_imx_tpm_round_state(struct pwm_chip *chip,
real_state->duty_cycle = state->duty_cycle;
tmp = (u64)p->mod * real_state->duty_cycle;
- p->val = DIV_ROUND_CLOSEST_ULL(tmp, real_state->period);
+ p->val = DIV64_U64_ROUND_CLOSEST(tmp, real_state->period);
real_state->polarity = state->polarity;
real_state->enabled = state->enabled;
diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
index 35a7ac42..b7d38d0 100644
--- a/drivers/pwm/pwm-imx27.c
+++ b/drivers/pwm/pwm-imx27.c
@@ -208,7 +208,7 @@ static void pwm_imx27_wait_fifo_slot(struct pwm_chip *chip,
sr = readl(imx->mmio_base + MX3_PWMSR);
fifoav = FIELD_GET(MX3_PWMSR_FIFOAV, sr);
if (fifoav == MX3_PWMSR_FIFOAV_4WORDS) {
- period_ms = DIV_ROUND_UP(pwm_get_period(pwm),
+ period_ms = DIV_ROUND_UP_ULL(pwm_get_period(pwm),
NSEC_PER_MSEC);
msleep(period_ms);
@@ -240,8 +240,7 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
period_cycles /= prescale;
c = (unsigned long long)period_cycles * state->duty_cycle;
- do_div(c, state->period);
- duty_cycles = c;
+ duty_cycles = div64_u64(c, state->period);
/*
* according to imx pwm RM, the real period value should be PERIOD
diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c
index cc63f9b..62de0bb 100644
--- a/drivers/pwm/pwm-sifive.c
+++ b/drivers/pwm/pwm-sifive.c
@@ -181,7 +181,7 @@ static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *pwm,
* consecutively
*/
num = (u64)duty_cycle * (1U << PWM_SIFIVE_CMPWIDTH);
- frac = DIV_ROUND_CLOSEST_ULL(num, state->period);
+ frac = DIV64_U64_ROUND_CLOSEST(num, state->period);
/* The hardware cannot generate a 100% duty cycle */
frac = min(frac, (1U << PWM_SIFIVE_CMPWIDTH) - 1);
diff --git a/drivers/pwm/pwm-sti.c b/drivers/pwm/pwm-sti.c
index 1508616..5a7f337 100644
--- a/drivers/pwm/pwm-sti.c
+++ b/drivers/pwm/pwm-sti.c
@@ -371,10 +371,11 @@ static int sti_pwm_capture(struct pwm_chip *chip, struct pwm_device *pwm,
effective_ticks = clk_get_rate(pc->cpt_clk);
result->period = (high + low) * NSEC_PER_SEC;
- result->period /= effective_ticks;
+ result->period = div_u64(result->period, effective_ticks);
result->duty_cycle = high * NSEC_PER_SEC;
- result->duty_cycle /= effective_ticks;
+ result->duty_cycle = div_u64(result->duty_cycle,
+ effective_ticks);
break;
diff --git a/drivers/pwm/pwm-stm32-lp.c b/drivers/pwm/pwm-stm32-lp.c
index 67fca62..134c146 100644
--- a/drivers/pwm/pwm-stm32-lp.c
+++ b/drivers/pwm/pwm-stm32-lp.c
@@ -61,7 +61,7 @@ static int stm32_pwm_lp_apply(struct pwm_chip *chip, struct pwm_device *pwm,
do_div(div, NSEC_PER_SEC);
if (!div) {
/* Clock is too slow to achieve requested period. */
- dev_dbg(priv->chip.dev, "Can't reach %u ns\n", state->period);
+ dev_dbg(priv->chip.dev, "Can't reach %llu ns\n", state->period);
return -EINVAL;
}
diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
index 3e3efa6..772fdf4 100644
--- a/drivers/pwm/pwm-sun4i.c
+++ b/drivers/pwm/pwm-sun4i.c
@@ -286,7 +286,7 @@ static int sun4i_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
val = (duty & PWM_DTY_MASK) | PWM_PRD(period);
sun4i_pwm_writel(sun4i_pwm, val, PWM_CH_PRD(pwm->hwpwm));
sun4i_pwm->next_period[pwm->hwpwm] = jiffies +
- usecs_to_jiffies(cstate.period / 1000 + 1);
+ usecs_to_jiffies(div_u64(cstate.period, 1000) + 1);
sun4i_pwm->needs_delay[pwm->hwpwm] = true;
if (state->polarity != PWM_POLARITY_NORMAL)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index efb4efc..3e5dbcf 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -625,7 +625,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
pb->scale = data->max_brightness;
}
- pb->lth_brightness = data->lth_brightness * (state.period / pb->scale);
+ pb->lth_brightness = data->lth_brightness * (div_u64(state.period,
+ pb->scale));
props.type = BACKLIGHT_RAW;
props.max_brightness = data->max_brightness;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH v6 2/2] pwm: core: Convert period and duty cycle to u64
From: Guru Das Srinagesh @ 2020-02-14 19:22 UTC (permalink / raw)
To: linux-pwm
Cc: Thierry Reding, Uwe Kleine-König, Subbaraman Narayanamurthy,
linux-kernel, Guru Das Srinagesh
In-Reply-To: <cover.1581706694.git.gurus@codeaurora.org>
Because period and duty cycle are defined as ints with units of
nanoseconds, the maximum time duration that can be set is limited to
~2.147 seconds. Change their definitions to u64 in the structs of the
PWM framework so that higher durations may be set.
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
---
drivers/pwm/core.c | 4 ++--
drivers/pwm/sysfs.c | 8 ++++----
include/linux/pwm.h | 12 ++++++------
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 5a7f659..81aa3c2 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -1163,8 +1163,8 @@ static void pwm_dbg_show(struct pwm_chip *chip, struct seq_file *s)
if (state.enabled)
seq_puts(s, " enabled");
- seq_printf(s, " period: %u ns", state.period);
- seq_printf(s, " duty: %u ns", state.duty_cycle);
+ seq_printf(s, " period: %llu ns", state.period);
+ seq_printf(s, " duty: %llu ns", state.duty_cycle);
seq_printf(s, " polarity: %s",
state.polarity ? "inverse" : "normal");
diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
index 2389b86..449dbc0 100644
--- a/drivers/pwm/sysfs.c
+++ b/drivers/pwm/sysfs.c
@@ -42,7 +42,7 @@ static ssize_t period_show(struct device *child,
pwm_get_state(pwm, &state);
- return sprintf(buf, "%u\n", state.period);
+ return sprintf(buf, "%llu\n", state.period);
}
static ssize_t period_store(struct device *child,
@@ -52,10 +52,10 @@ static ssize_t period_store(struct device *child,
struct pwm_export *export = child_to_pwm_export(child);
struct pwm_device *pwm = export->pwm;
struct pwm_state state;
- unsigned int val;
+ u64 val;
int ret;
- ret = kstrtouint(buf, 0, &val);
+ ret = kstrtou64(buf, 0, &val);
if (ret)
return ret;
@@ -77,7 +77,7 @@ static ssize_t duty_cycle_show(struct device *child,
pwm_get_state(pwm, &state);
- return sprintf(buf, "%u\n", state.duty_cycle);
+ return sprintf(buf, "%llu\n", state.duty_cycle);
}
static ssize_t duty_cycle_store(struct device *child,
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 0ef808d..b53f13d 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -39,7 +39,7 @@ enum pwm_polarity {
* current PWM hardware state.
*/
struct pwm_args {
- unsigned int period;
+ u64 period;
enum pwm_polarity polarity;
};
@@ -56,8 +56,8 @@ enum {
* @enabled: PWM enabled status
*/
struct pwm_state {
- unsigned int period;
- unsigned int duty_cycle;
+ u64 period;
+ u64 duty_cycle;
enum pwm_polarity polarity;
bool enabled;
};
@@ -105,13 +105,13 @@ static inline bool pwm_is_enabled(const struct pwm_device *pwm)
return state.enabled;
}
-static inline void pwm_set_period(struct pwm_device *pwm, unsigned int period)
+static inline void pwm_set_period(struct pwm_device *pwm, u64 period)
{
if (pwm)
pwm->state.period = period;
}
-static inline unsigned int pwm_get_period(const struct pwm_device *pwm)
+static inline u64 pwm_get_period(const struct pwm_device *pwm)
{
struct pwm_state state;
@@ -126,7 +126,7 @@ static inline void pwm_set_duty_cycle(struct pwm_device *pwm, unsigned int duty)
pwm->state.duty_cycle = duty;
}
-static inline unsigned int pwm_get_duty_cycle(const struct pwm_device *pwm)
+static inline u64 pwm_get_duty_cycle(const struct pwm_device *pwm)
{
struct pwm_state state;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 155/186] powerpc/sriov: Remove VF eeh_dev state when disabling SR-IOV
From: Sasha Levin @ 2020-02-14 16:16 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sam Bobroff, Oliver O'Halloran, linuxppc-dev, Sasha Levin
In-Reply-To: <20200214161715.18113-1-sashal@kernel.org>
From: Oliver O'Halloran <oohall@gmail.com>
[ Upstream commit 1fb4124ca9d456656a324f1ee29b7bf942f59ac8 ]
When disabling virtual functions on an SR-IOV adapter we currently do not
correctly remove the EEH state for the now-dead virtual functions. When
removing the pci_dn that was created for the VF when SR-IOV was enabled
we free the corresponding eeh_dev without removing it from the child device
list of the eeh_pe that contained it. This can result in crashes due to the
use-after-free.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Reviewed-by: Sam Bobroff <sbobroff@linux.ibm.com>
Tested-by: Sam Bobroff <sbobroff@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20190821062655.19735-1-oohall@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/kernel/pci_dn.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/pci_dn.c b/arch/powerpc/kernel/pci_dn.c
index 0e395afbf0f49..0e45a446a8c78 100644
--- a/arch/powerpc/kernel/pci_dn.c
+++ b/arch/powerpc/kernel/pci_dn.c
@@ -261,9 +261,22 @@ void remove_dev_pci_data(struct pci_dev *pdev)
continue;
#ifdef CONFIG_EEH
- /* Release EEH device for the VF */
+ /*
+ * Release EEH state for this VF. The PCI core
+ * has already torn down the pci_dev for this VF, but
+ * we're responsible to removing the eeh_dev since it
+ * has the same lifetime as the pci_dn that spawned it.
+ */
edev = pdn_to_eeh_dev(pdn);
if (edev) {
+ /*
+ * We allocate pci_dn's for the totalvfs count,
+ * but only only the vfs that were activated
+ * have a configured PE.
+ */
+ if (edev->pe)
+ eeh_rmv_from_parent_pe(edev);
+
pdn->edev = NULL;
kfree(edev);
}
--
2.20.1
^ permalink raw reply related
* [igt-dev] [PATCH i-g-t] i915/gem_ctx_engines: Exercise 0 engines[]
From: Chris Wilson @ 2020-02-14 19:23 UTC (permalink / raw)
To: intel-gfx; +Cc: igt-dev
Setup a context with no engines, and make sure we reject all execution
attempts.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
tests/i915/gem_ctx_engines.c | 45 ++++++++++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/tests/i915/gem_ctx_engines.c b/tests/i915/gem_ctx_engines.c
index cb82f08ef..063140e0f 100644
--- a/tests/i915/gem_ctx_engines.c
+++ b/tests/i915/gem_ctx_engines.c
@@ -242,6 +242,48 @@ static void idempotent(int i915)
gem_context_destroy(i915, p.ctx_id);
}
+static uint32_t batch_create(int i915)
+{
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ uint32_t handle = gem_create(i915, 4096);
+
+ gem_write(i915, handle, 0, &bbe, sizeof(bbe));
+ return handle;
+}
+
+static void none(int i915)
+{
+ struct i915_context_param_engines engines = {};
+ struct drm_i915_gem_context_param p = {
+ .ctx_id = gem_context_create(i915),
+ .param = I915_CONTEXT_PARAM_ENGINES,
+ .value = to_user_pointer(&engines),
+ .size = sizeof(engines),
+ };
+
+ gem_context_set_param(i915, &p);
+
+ {
+ struct drm_i915_gem_exec_object2 obj = {
+ .handle = batch_create(i915),
+ };
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(&obj),
+ .buffer_count = 1,
+ .rsvd1 = p.ctx_id,
+ };
+
+ for (execbuf.flags = 0;
+ execbuf.flags <= I915_EXEC_RING_MASK;
+ execbuf.flags++)
+ igt_assert_eq(__gem_execbuf(i915, &execbuf), -EINVAL);
+
+ gem_close(i915, obj.handle);
+ }
+
+ gem_context_destroy(i915, p.ctx_id);
+}
+
static void execute_one(int i915)
{
I915_DEFINE_CONTEXT_PARAM_ENGINES(engines , I915_EXEC_RING_MASK + 1);
@@ -527,6 +569,9 @@ igt_main
igt_subtest("idempotent")
idempotent(i915);
+ igt_subtest("none")
+ none(i915);
+
igt_subtest("execute-one")
execute_one(i915);
--
2.25.0
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply related
* Re: [PATCH rdma] IB/mlx5: Fix linkage failure on 32-bit arches
From: Jason Gunthorpe @ 2020-02-14 19:24 UTC (permalink / raw)
To: Alexander Lobakin
Cc: Leon Romanovsky, Doug Ledford, Yishai Hadas, Maxim Mikityanskiy,
linux-rdma, linux-kernel
In-Reply-To: <20200214191309.155654-1-alobakin@dlink.ru>
On Fri, Feb 14, 2020 at 10:13:09PM +0300, Alexander Lobakin wrote:
> Commit f164be8c0366 ("IB/mlx5: Extend caps stage to handle VAR
> capabilities") introduced a straight "/" division of the u64
> variable "bar_size", which emits an __udivdi3() libgcc call on
> 32-bit arches and certain GCC versions:
>
> error: "__udivdi3" [drivers/infiniband/hw/mlx5/mlx5_ib.ko] undefined! [1]
>
> Replace it with the corresponding div_u64() call.
> Compile-tested on ARCH=mips 32r2el_defconfig BOARDS=ocelot.
>
> [1] https://lore.kernel.org/linux-mips/CAMuHMdXM9S1VkFMZ8eDAyZR6EE4WkJY215Lcn2qdOaPeadF+EQ@mail.gmail.com/
>
> Fixes: f164be8c0366 ("IB/mlx5: Extend caps stage to handle VAR
> capabilities")
> Signed-off-by: Alexander Lobakin <alobakin@dlink.ru>
> ---
> drivers/infiniband/hw/mlx5/main.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Randy beat you too it..
https://lore.kernel.org/linux-rdma/20200206143201.GF25297@ziepe.ca/
But it seems patchwork missed this somehow.
Applied now at least
Jason
^ permalink raw reply
* Re: [RFC PATCH 1/2] Input: add `SW_MACHINE_COVER`
From: Ladislav Michl @ 2020-02-14 19:16 UTC (permalink / raw)
To: Merlijn Wajer
Cc: Benoît Cousson, Tony Lindgren, Rob Herring, Mark Rutland,
Dmitry Torokhov, Mattias Jacobsson, Darren Hart (VMware),
linux-omap, devicetree, linux-kernel, linux-input
In-Reply-To: <20200214130249.6845-2-merlijn@wizzup.org>
Hi Merlijn,
On Fri, Feb 14, 2020 at 02:02:47PM +0100, Merlijn Wajer wrote:
> This event code represents the state of a removable cover of a device.
> Value 1 means that the cover is open or removed, value 0 means that the
> cover is closed.
>
> This can be used to preempt users removing a removable mmc card or even
> the battery, allowing userspace to attempt to safely unmount a card.
> ---
> include/linux/mod_devicetable.h | 2 +-
> include/uapi/linux/input-event-codes.h | 3 ++-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> index 448621c32e4d..4c692cb3cc1d 100644
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -299,7 +299,7 @@ struct pcmcia_device_id {
> #define INPUT_DEVICE_ID_LED_MAX 0x0f
> #define INPUT_DEVICE_ID_SND_MAX 0x07
> #define INPUT_DEVICE_ID_FF_MAX 0x7f
> -#define INPUT_DEVICE_ID_SW_MAX 0x0f
> +#define INPUT_DEVICE_ID_SW_MAX 0x10
> #define INPUT_DEVICE_ID_PROP_MAX 0x1f
>
> #define INPUT_DEVICE_ID_MATCH_BUS 1
> diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
> index 64cee116928e..318a6387cdfb 100644
> --- a/include/uapi/linux/input-event-codes.h
> +++ b/include/uapi/linux/input-event-codes.h
> @@ -807,7 +807,8 @@
> #define SW_LINEIN_INSERT 0x0d /* set = inserted */
> #define SW_MUTE_DEVICE 0x0e /* set = device disabled */
> #define SW_PEN_INSERTED 0x0f /* set = pen inserted */
> -#define SW_MAX 0x0f
> +#define SW_MACHINE_COVER 0x10 /* set = cover closed */
There is an extra space above ^
> +#define SW_MAX 0x10
> #define SW_CNT (SW_MAX+1)
>
> /*
> --
> 2.23.0
^ permalink raw reply
* [Intel-gfx] [PATCH i-g-t] i915/gem_ctx_engines: Exercise 0 engines[]
From: Chris Wilson @ 2020-02-14 19:23 UTC (permalink / raw)
To: intel-gfx; +Cc: igt-dev
Setup a context with no engines, and make sure we reject all execution
attempts.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
tests/i915/gem_ctx_engines.c | 45 ++++++++++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/tests/i915/gem_ctx_engines.c b/tests/i915/gem_ctx_engines.c
index cb82f08ef..063140e0f 100644
--- a/tests/i915/gem_ctx_engines.c
+++ b/tests/i915/gem_ctx_engines.c
@@ -242,6 +242,48 @@ static void idempotent(int i915)
gem_context_destroy(i915, p.ctx_id);
}
+static uint32_t batch_create(int i915)
+{
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ uint32_t handle = gem_create(i915, 4096);
+
+ gem_write(i915, handle, 0, &bbe, sizeof(bbe));
+ return handle;
+}
+
+static void none(int i915)
+{
+ struct i915_context_param_engines engines = {};
+ struct drm_i915_gem_context_param p = {
+ .ctx_id = gem_context_create(i915),
+ .param = I915_CONTEXT_PARAM_ENGINES,
+ .value = to_user_pointer(&engines),
+ .size = sizeof(engines),
+ };
+
+ gem_context_set_param(i915, &p);
+
+ {
+ struct drm_i915_gem_exec_object2 obj = {
+ .handle = batch_create(i915),
+ };
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(&obj),
+ .buffer_count = 1,
+ .rsvd1 = p.ctx_id,
+ };
+
+ for (execbuf.flags = 0;
+ execbuf.flags <= I915_EXEC_RING_MASK;
+ execbuf.flags++)
+ igt_assert_eq(__gem_execbuf(i915, &execbuf), -EINVAL);
+
+ gem_close(i915, obj.handle);
+ }
+
+ gem_context_destroy(i915, p.ctx_id);
+}
+
static void execute_one(int i915)
{
I915_DEFINE_CONTEXT_PARAM_ENGINES(engines , I915_EXEC_RING_MASK + 1);
@@ -527,6 +569,9 @@ igt_main
igt_subtest("idempotent")
idempotent(i915);
+ igt_subtest("none")
+ none(i915);
+
igt_subtest("execute-one")
execute_one(i915);
--
2.25.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* Re: [PATCH v2] net: davicom: dm9000: allow to pass MAC address through mac_addr module parameter
From: H. Nikolaus Schaller @ 2020-02-14 19:24 UTC (permalink / raw)
To: Paul Cercueil
Cc: Andrew Lunn, David S. Miller, Petr Štetiar, Richard Fontana,
Thomas Gleixner, Heiner Kallweit, netdev, linux-kernel,
letux-kernel, kernel
In-Reply-To: <1581706048.3.3@crapouillou.net>
> Am 14.02.2020 um 19:47 schrieb Paul Cercueil <paul@crapouillou.net>:
>
> Hi Nikolaus,
>
> What I'd suggest is to write a NVMEM driver for the efuse and retrieve the MAC address cleanly with nvmem_get_mac_address().
>
> It shouldn't be hard to do (there's already code for it in the non-upstream 3.18 kernel for the CI20) and you remove the dependency on uboot.
Interesting approach. I have found this:
https://lore.kernel.org/patchwork/patch/868158/
but it looks as if it was never finished (I could not locate a V3 or anything mainline?)
and and it tries to solve other problems as well.
And it looks to be much more complex than my "solution" to the immediate problem.
I have to study it to know if I can write a nvmem_get_mac_address().
BR,
Nikolaus
>
> -Paul
>
>
> Le ven., févr. 14, 2020 at 17:07, H. Nikolaus Schaller <hns@goldelico.com> a écrit :
>> The MIPS Ingenic CI20 board is shipped with a quite old u-boot
>> (ci20-v2013.10 see https://elinux.org/CI20_Dev_Zone). This passes
>> the MAC address through dm9000.mac_addr=xx:xx:xx:xx:xx:xx
>> kernel module parameter to give the board a fixed MAC address.
>> This is not processed by the dm9000 driver which assigns a random
>> MAC address on each boot, making DHCP assign a new IP address
>> each time.
>> So we add a check for the mac_addr module parameter as a last
>> resort before assigning a random one. This mechanism can also
>> be used outside of u-boot to provide a value through modprobe
>> config.
>> To parse the MAC address in a new function get_mac_addr() we
>> use an copy adapted from the ksz884x.c driver which provides
>> the same functionality.
>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>> ---
>> drivers/net/ethernet/davicom/dm9000.c | 42 +++++++++++++++++++++++++++
>> 1 file changed, 42 insertions(+)
>> diff --git a/drivers/net/ethernet/davicom/dm9000.c b/drivers/net/ethernet/davicom/dm9000.c
>> index 1ea3372775e6..7402030b0352 100644
>> --- a/drivers/net/ethernet/davicom/dm9000.c
>> +++ b/drivers/net/ethernet/davicom/dm9000.c
>> @@ -1409,6 +1409,43 @@ static struct dm9000_plat_data *dm9000_parse_dt(struct device *dev)
>> return pdata;
>> }
>> +static char *mac_addr = ":";
>> +module_param(mac_addr, charp, 0);
>> +MODULE_PARM_DESC(mac_addr, "MAC address");
>> +
>> +static void get_mac_addr(struct net_device *ndev, char *macaddr)
>> +{
>> + int i = 0;
>> + int j = 0;
>> + int got_num = 0;
>> + int num = 0;
>> +
>> + while (j < ETH_ALEN) {
>> + if (macaddr[i]) {
>> + int digit;
>> +
>> + got_num = 1;
>> + digit = hex_to_bin(macaddr[i]);
>> + if (digit >= 0)
>> + num = num * 16 + digit;
>> + else if (':' == macaddr[i])
>> + got_num = 2;
>> + else
>> + break;
>> + } else if (got_num) {
>> + got_num = 2;
>> + } else {
>> + break;
>> + }
>> + if (got_num == 2) {
>> + ndev->dev_addr[j++] = (u8)num;
>> + num = 0;
>> + got_num = 0;
>> + }
>> + i++;
>> + }
>> +}
>> +
>> /*
>> * Search DM9000 board, allocate space and register it
>> */
>> @@ -1679,6 +1716,11 @@ dm9000_probe(struct platform_device *pdev)
>> ndev->dev_addr[i] = ior(db, i+DM9000_PAR);
>> }
>> + if (!is_valid_ether_addr(ndev->dev_addr)) {
>> + mac_src = "param";
>> + get_mac_addr(ndev, mac_addr);
>> + }
>> +
>> if (!is_valid_ether_addr(ndev->dev_addr)) {
>> inv_mac_addr = true;
>> eth_hw_addr_random(ndev);
>> --
>> 2.23.0
>
>
^ permalink raw reply
* Re: [PATCH v2] x86/resctrl: Preserve CDP enable over cpuhp
From: Reinette Chatre @ 2020-02-14 19:24 UTC (permalink / raw)
To: James Morse, x86, linux-kernel
Cc: Fenghua Yu, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
H . Peter Anvin
In-Reply-To: <20200214181600.38779-1-james.morse@arm.com>
Hi James,
On 2/14/2020 10:16 AM, James Morse wrote:
> Resctrl assumes that all CPUs are online when the filesystem is
> mounted, and that CPUs remember their CDP-enabled state over CPU
> hotplug.
>
> This goes wrong when resctrl's CDP-enabled state changes while all
> the CPUs in a domain are offline.
>
> When a domain comes online, enable (or disable!) CDP to match resctrl's
> current setting.
>
> Fixes: 5ff193fbde20 ("x86/intel_rdt: Add basic resctrl filesystem support")
> Suggested-by: Reinette Chatre <reinette.chatre@intel.com>
> Signed-off-by: James Morse <james.morse@arm.com>
>
> ---
> Changes since v1:
> * Explicitly test for L2/L3 resources to ignore duplicate calls.
> * Poke the LxDATA resources to avoid confusing CDP-off with CDP-unsupported.
> * Moved code to rdtgroup.c for fewer exported functions.
>
> v1: lore.kernel.org/r/20200212185359.163111-1-james.morse@arm.com
> ---
> arch/x86/kernel/cpu/resctrl/core.c | 2 ++
> arch/x86/kernel/cpu/resctrl/internal.h | 1 +
> arch/x86/kernel/cpu/resctrl/rdtgroup.c | 18 ++++++++++++++++++
> 3 files changed, 21 insertions(+)
>
> diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c
> index 89049b343c7a..d8cc5223b7ce 100644
> --- a/arch/x86/kernel/cpu/resctrl/core.c
> +++ b/arch/x86/kernel/cpu/resctrl/core.c
> @@ -578,6 +578,8 @@ static void domain_add_cpu(int cpu, struct rdt_resource *r)
> d->id = id;
> cpumask_set_cpu(cpu, &d->cpu_mask);
>
> + rdt_domain_reconfigure_cdp(r);
> +
> if (r->alloc_capable && domain_setup_ctrlval(r, d)) {
> kfree(d);
> return;
> diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/resctrl/internal.h
> index 181c992f448c..3dd13f3a8b23 100644
> --- a/arch/x86/kernel/cpu/resctrl/internal.h
> +++ b/arch/x86/kernel/cpu/resctrl/internal.h
> @@ -601,5 +601,6 @@ bool has_busy_rmid(struct rdt_resource *r, struct rdt_domain *d);
> void __check_limbo(struct rdt_domain *d, bool force_free);
> bool cbm_validate_intel(char *buf, u32 *data, struct rdt_resource *r);
> bool cbm_validate_amd(char *buf, u32 *data, struct rdt_resource *r);
> +void rdt_domain_reconfigure_cdp(struct rdt_resource *r);
>
> #endif /* _ASM_X86_RESCTRL_INTERNAL_H */
> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> index 064e9ef44cd6..5967320a1951 100644
> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> @@ -1831,6 +1831,9 @@ static int set_cache_qos_cfg(int level, bool enable)
> struct rdt_domain *d;
> int cpu;
>
> + /* CDP state is restored during cpuhp, which takes this lock */
> + lockdep_assert_held(&rdtgroup_mutex);
> +
I think this hunk can be dropped. (1) The code path where this
annotation is added is not part of this fix. (2) The comment implies
that the taking of the mutex is something new/unique added in the CPU
hotplug path but that is not accurate since this mutex is also taken in
the only other existing call path of this snippet that is handling the
mounting of the filesystem.
You do mention that these annotations is helpful for the MPAM work.
Could the annotations instead be added as a separate patch forming part
of that work?
> if (level == RDT_RESOURCE_L3)
> update = l3_qos_cfg_update;
> else if (level == RDT_RESOURCE_L2)
> @@ -1859,6 +1862,21 @@ static int set_cache_qos_cfg(int level, bool enable)
> return 0;
> }
>
> +/* Restore the qos cfg state when a package comes online */
s/package/domain/? When, for example, considering L2 then "package" is
not the right term to use.
> +void rdt_domain_reconfigure_cdp(struct rdt_resource *r)
> +{
> + lockdep_assert_held(&rdtgroup_mutex);
> +
> + if (!r->alloc_capable)
> + return;
> +
> + if (r == &rdt_resources_all[RDT_RESOURCE_L2DATA])
> + l2_qos_cfg_update(&r->alloc_enabled);
> +
> + if (r == &rdt_resources_all[RDT_RESOURCE_L3DATA])
> + l3_qos_cfg_update(&r->alloc_enabled);
> +}
> +
> /*
> * Enable or disable the MBA software controller
> * which helps user specify bandwidth in MBps.
>
Thank you very much.
Reinette
^ permalink raw reply
* Re: [PATCH v2 01/12] drm: ingenic-drm: add MODULE_DEVICE_TABLE
From: H. Nikolaus Schaller @ 2020-02-14 19:24 UTC (permalink / raw)
To: Paul Cercueil
Cc: Paul Boddie, Rob Herring, Mark Rutland, Ralf Baechle, Paul Burton,
David Airlie, Daniel Vetter, Andi Kleen, Miquel Raynal, Kees Cook,
devicetree, linux-mips, linux-kernel, dri-devel, letux-kernel,
kernel
In-Reply-To: <1581707177.3.6@crapouillou.net>
> Am 14.02.2020 um 20:06 schrieb Paul Cercueil <paul@crapouillou.net>:
>
> Hi Nikolaus,
>
> Please rebase this patch on top of drm-misc-next and send it apart - it should go through the DRM tree.
>
>
> Le ven., févr. 14, 2020 at 17:10, H. Nikolaus Schaller <hns@goldelico.com> a écrit :
>> Add MODULE_DEVICE_TABLE so that the driver can load by
>> matching the device tree if compiled as module.
>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>> ---
>> drivers/gpu/drm/ingenic/ingenic-drm.c | 2 ++
>> 1 file changed, 2 insertions(+)
>> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c b/drivers/gpu/drm/ingenic/ingenic-drm.c
>> index 6d47ef7b148c..d8617096dd8e 100644
>> --- a/drivers/gpu/drm/ingenic/ingenic-drm.c
>> +++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
>> @@ -844,6 +844,8 @@ static const struct of_device_id ingenic_drm_of_match[] = {
>> { /* sentinel */ },
>> };
>> +MODULE_DEVICE_TABLE(of, ingenic_drm_of_match);
>
> Also please remove the blank line above MODULE_DEVICE_TABLE.
>
> Cheers,
> -Paul
Ok.
BR and thanks,
Nikolaus
>
>> +
>> static struct platform_driver ingenic_drm_driver = {
>> .driver = {
>> .name = "ingenic-drm",
>> --
>> 2.23.0
>
>
^ permalink raw reply
* Re: [PATCH v2 2/2] md: enable io polling
From: Keith Busch @ 2020-02-14 19:25 UTC (permalink / raw)
To: Andrzej Jakowski; +Cc: axboe, song, linux-block, linux-raid, Artur Paszkiewicz
In-Reply-To: <f516e2b2-1988-03ca-f966-5f26771717ff@linux.intel.com>
On Thu, Feb 13, 2020 at 01:19:42PM -0700, Andrzej Jakowski wrote:
> On 2/12/20 2:42 PM, Keith Busch wrote:
> > Okay, that's a nice subtlety. But it means the original caller gets the
> > cookie from the last submission in the chain. If md recieves a single
> > request that has to be split among more than one member disk, the cookie
> > you're using to control the polling is valid only for one of the
> > request_queue's and may break others.
>
> Correct, I agree that it is an issue. I can see at least two ways how to solve it:
> 1. Provide a mechanism in md accounting for outstanding IOs, storing cookie information
> for them. md_poll() will then use valid cookie's
> 2. Provide similar mechanism abstracted for stackable block devices and block layer could
> handle completions for subordinate bios in an abstracted way in blk_poll() routine.
> How do you Guys see this going?
Honestly, I don't see how this is can be successful without a more
significant change than you may be anticipating. I'd be happy to hear if
there's a better solution, but here's what I'm thinking:
You'd need each stacking layer to return a cookie that its poll function
can turn into a list of { request_queue, blk_qc_t } tuples for each bio
the stacking layer created so that it can chain the poll request to the
next layers.
The problems are that the stacking layers don't get a cookie for the
bio's it submits from within the same md_make_request() context. Even if
you could get the cookie associated with those bios, you either allocate
more memory to track these things, or need polling bio list link fields
added 'struct bio', neither of which seem very appealing.
Do you have a better way in mind?
^ permalink raw reply
* [PATCH AUTOSEL 4.9 003/141] soc: fsl: qe: change return type of cpm_muram_alloc() to s32
From: Sasha Levin @ 2020-02-14 16:19 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Timur Tabi, Rasmus Villemoes, Li Yang, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20200214162122.19794-1-sashal@kernel.org>
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
[ Upstream commit 800cd6fb76f0ec7711deb72a86c924db1ae42648 ]
There are a number of problems with cpm_muram_alloc() and its
callers. Most callers assign the return value to some variable and
then use IS_ERR_VALUE to check for allocation failure. However, when
that variable is not sizeof(long), this leads to warnings - and it is
indeed broken to do e.g.
u32 foo = cpm_muram_alloc();
if (IS_ERR_VALUE(foo))
on a 64-bit platform, since the condition
foo >= (unsigned long)-ENOMEM
is tautologically false. There are also callers that ignore the
possibility of error, and then there are those that check for error by
comparing the return value to 0...
One could fix that by changing all callers to store the return value
temporarily in an "unsigned long" and test that. However, use of
IS_ERR_VALUE() is error-prone and should be restricted to things which
are inherently long-sized (stuff in pt_regs etc.). Instead, let's aim
for changing to the standard kernel style
int foo = cpm_muram_alloc();
if (foo < 0)
deal_with_it()
some->where = foo;
Changing the return type from unsigned long to s32 (aka signed int)
doesn't change the value that gets stored into any of the callers'
variables except if the caller was storing the result in a u64 _and_
the allocation failed, so in itself this patch should be a no-op.
Another problem with cpm_muram_alloc() is that it can certainly
validly return 0 - and except if some cpm_muram_alloc_fixed() call
interferes, the very first cpm_muram_alloc() call will return just
that. But that shows that both ucc_slow_free() and ucc_fast_free() are
buggy, since they assume that a value of 0 means "that field was never
allocated". We'll later change cpm_muram_free() to accept (and ignore)
a negative offset, so callers can use a sentinel of -1 instead of 0
and just unconditionally call cpm_muram_free().
Reviewed-by: Timur Tabi <timur@kernel.org>
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Li Yang <leoyang.li@nxp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/soc/fsl/qe/qe_common.c | 29 ++++++++++++++++-------------
include/soc/fsl/qe/qe.h | 16 ++++++++--------
2 files changed, 24 insertions(+), 21 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe_common.c b/drivers/soc/fsl/qe/qe_common.c
index 104e68d9b84f2..4f60724b06b7c 100644
--- a/drivers/soc/fsl/qe/qe_common.c
+++ b/drivers/soc/fsl/qe/qe_common.c
@@ -35,7 +35,7 @@ static phys_addr_t muram_pbase;
struct muram_block {
struct list_head head;
- unsigned long start;
+ s32 start;
int size;
};
@@ -113,13 +113,14 @@ int cpm_muram_init(void)
* @algo: algorithm for alloc.
* @data: data for genalloc's algorithm.
*
- * This function returns an offset into the muram area.
+ * This function returns a non-negative offset into the muram area, or
+ * a negative errno on failure.
*/
-static unsigned long cpm_muram_alloc_common(unsigned long size,
- genpool_algo_t algo, void *data)
+static s32 cpm_muram_alloc_common(unsigned long size,
+ genpool_algo_t algo, void *data)
{
struct muram_block *entry;
- unsigned long start;
+ s32 start;
if (!muram_pool && cpm_muram_init())
goto out2;
@@ -140,7 +141,7 @@ static unsigned long cpm_muram_alloc_common(unsigned long size,
out1:
gen_pool_free(muram_pool, start, size);
out2:
- return (unsigned long)-ENOMEM;
+ return -ENOMEM;
}
/*
@@ -148,13 +149,14 @@ static unsigned long cpm_muram_alloc_common(unsigned long size,
* @size: number of bytes to allocate
* @align: requested alignment, in bytes
*
- * This function returns an offset into the muram area.
+ * This function returns a non-negative offset into the muram area, or
+ * a negative errno on failure.
* Use cpm_dpram_addr() to get the virtual address of the area.
* Use cpm_muram_free() to free the allocation.
*/
-unsigned long cpm_muram_alloc(unsigned long size, unsigned long align)
+s32 cpm_muram_alloc(unsigned long size, unsigned long align)
{
- unsigned long start;
+ s32 start;
unsigned long flags;
struct genpool_data_align muram_pool_data;
@@ -171,7 +173,7 @@ EXPORT_SYMBOL(cpm_muram_alloc);
* cpm_muram_free - free a chunk of multi-user ram
* @offset: The beginning of the chunk as returned by cpm_muram_alloc().
*/
-int cpm_muram_free(unsigned long offset)
+int cpm_muram_free(s32 offset)
{
unsigned long flags;
int size;
@@ -197,13 +199,14 @@ EXPORT_SYMBOL(cpm_muram_free);
* cpm_muram_alloc_fixed - reserve a specific region of multi-user ram
* @offset: offset of allocation start address
* @size: number of bytes to allocate
- * This function returns an offset into the muram area
+ * This function returns @offset if the area was available, a negative
+ * errno otherwise.
* Use cpm_dpram_addr() to get the virtual address of the area.
* Use cpm_muram_free() to free the allocation.
*/
-unsigned long cpm_muram_alloc_fixed(unsigned long offset, unsigned long size)
+s32 cpm_muram_alloc_fixed(unsigned long offset, unsigned long size)
{
- unsigned long start;
+ s32 start;
unsigned long flags;
struct genpool_data_fixed muram_pool_data_fixed;
diff --git a/include/soc/fsl/qe/qe.h b/include/soc/fsl/qe/qe.h
index 226f915a68c28..55907f7ace82e 100644
--- a/include/soc/fsl/qe/qe.h
+++ b/include/soc/fsl/qe/qe.h
@@ -102,26 +102,26 @@ static inline void qe_reset(void) {}
int cpm_muram_init(void);
#if defined(CONFIG_CPM) || defined(CONFIG_QUICC_ENGINE)
-unsigned long cpm_muram_alloc(unsigned long size, unsigned long align);
-int cpm_muram_free(unsigned long offset);
-unsigned long cpm_muram_alloc_fixed(unsigned long offset, unsigned long size);
+s32 cpm_muram_alloc(unsigned long size, unsigned long align);
+int cpm_muram_free(s32 offset);
+s32 cpm_muram_alloc_fixed(unsigned long offset, unsigned long size);
void __iomem *cpm_muram_addr(unsigned long offset);
unsigned long cpm_muram_offset(void __iomem *addr);
dma_addr_t cpm_muram_dma(void __iomem *addr);
#else
-static inline unsigned long cpm_muram_alloc(unsigned long size,
- unsigned long align)
+static inline s32 cpm_muram_alloc(unsigned long size,
+ unsigned long align)
{
return -ENOSYS;
}
-static inline int cpm_muram_free(unsigned long offset)
+static inline int cpm_muram_free(s32 offset)
{
return -ENOSYS;
}
-static inline unsigned long cpm_muram_alloc_fixed(unsigned long offset,
- unsigned long size)
+static inline s32 cpm_muram_alloc_fixed(unsigned long offset,
+ unsigned long size)
{
return -ENOSYS;
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v1] usb:gadget: Fix issue with config_ep_by_speed function.
From: Thinh Nguyen @ 2020-02-14 19:26 UTC (permalink / raw)
To: Pawel Laszczak, Thinh Nguyen, Jayshri Dajiram Pawar,
linux-usb@vger.kernel.org
Cc: gregkh@linuxfoundation.org, balbi@kernel.org,
heikki.krogerus@linux.intel.com, rogerq@ti.com,
linux-kernel@vger.kernel.org, jbergsagel@ti.com, nsekhar@ti.com,
nm@ti.com, peter.chen@nxp.com, Rahul Kumar, Sanket Parmar
In-Reply-To: <BYAPR07MB47098648C28E5E4BB9B78DCADD150@BYAPR07MB4709.namprd07.prod.outlook.com>
Pawel Laszczak wrote:
> Hi,
>
>> Hi,
>>
>> Jayshri Pawar wrote:
>>> This patch adds additional parameter alt to config_ep_by_speed function.
>>> This additional parameter allows to improve this function and
>>> find proper usb_ss_ep_comp_descriptor.
>>>
>>> Problem has appeared during testing f_tcm (BOT/UAS) driver function.
>>>
>>> f_tcm function for SS use array of headers for both BOT/UAS alternate
>>> setting:
>>>
>>> static struct usb_descriptor_header *uasp_ss_function_desc[] = {
>>> (struct usb_descriptor_header *) &bot_intf_desc,
>>> (struct usb_descriptor_header *) &bot_uasp_ss_bi_desc,
>>> (struct usb_descriptor_header *) &bot_bi_ep_comp_desc,
>>> (struct usb_descriptor_header *) &bot_uasp_ss_bo_desc,
>>> (struct usb_descriptor_header *) &bot_bo_ep_comp_desc,
>>>
>>> (struct usb_descriptor_header *) &uasp_intf_desc,
>>> (struct usb_descriptor_header *) &bot_uasp_ss_bi_desc,
>>> (struct usb_descriptor_header *) &uasp_bi_ep_comp_desc,
>>> (struct usb_descriptor_header *) &uasp_bi_pipe_desc,
>>> (struct usb_descriptor_header *) &bot_uasp_ss_bo_desc,
>>> (struct usb_descriptor_header *) &uasp_bo_ep_comp_desc,
>>> (struct usb_descriptor_header *) &uasp_bo_pipe_desc,
>>> (struct usb_descriptor_header *) &uasp_ss_status_desc,
>>> (struct usb_descriptor_header *) &uasp_status_in_ep_comp_desc,
>>> (struct usb_descriptor_header *) &uasp_status_pipe_desc,
>>> (struct usb_descriptor_header *) &uasp_ss_cmd_desc,
>>> (struct usb_descriptor_header *) &uasp_cmd_comp_desc,
>>> (struct usb_descriptor_header *) &uasp_cmd_pipe_desc,
>>> NULL,
>>> };
>>>
>>> The first 5 descriptors are associated with BOT alternate setting,
>>> and others are associated with UAS.
>>>
>>> During handling UAS alternate setting f_tcm drivr invokes
>>> config_ep_by_speed and this function sets incorrect companion endpoint
>>> descriptor in usb_ep object.
>>>
>>> Instead setting ep->comp_desc to uasp_bi_ep_comp_desc function in this
>>> case set ep->comp_desc to bot_uasp_ss_bi_desc.
>>>
>>> This is due to the fact that it search endpoint based on endpoint
>>> address:
>>>
>>> for_each_ep_desc(speed_desc, d_spd) {
>>> chosen_desc = (struct usb_endpoint_descriptor *)*d_spd;
>>> if (chosen_desc->bEndpoitAddress == _ep->address)
>>> goto ep_found;
>>> }
>>>
>>> And in result it uses the descriptor from BOT alternate setting
>>> instead UAS.
>>>
>>> Finally, it causes that controller driver during enabling endpoints
>>> detect that just enabled endpoint for bot.
>>>
>>> Signed-off-by: Jayshri Pawar <jpawar@cadence.com>
>>> Signed-off-by: Pawel Laszczak <pawell@cadence.com>
>>> ---
>>> drivers/usb/gadget/composite.c | 46 ++++++++++++++------
>>> drivers/usb/gadget/function/f_acm.c | 7 +--
>>> drivers/usb/gadget/function/f_ecm.c | 7 +--
>>> drivers/usb/gadget/function/f_eem.c | 4 +-
>>> drivers/usb/gadget/function/f_fs.c | 3 +-
>>> drivers/usb/gadget/function/f_hid.c | 4 +-
>>> drivers/usb/gadget/function/f_loopback.c | 2 +-
>>> drivers/usb/gadget/function/f_mass_storage.c | 5 ++-
>>> drivers/usb/gadget/function/f_midi.c | 2 +-
>>> drivers/usb/gadget/function/f_ncm.c | 7 +--
>>> drivers/usb/gadget/function/f_obex.c | 4 +-
>>> drivers/usb/gadget/function/f_phonet.c | 4 +-
>>> drivers/usb/gadget/function/f_rndis.c | 7 +--
>>> drivers/usb/gadget/function/f_serial.c | 4 +-
>>> drivers/usb/gadget/function/f_sourcesink.c | 11 +++--
>>> drivers/usb/gadget/function/f_subset.c | 4 +-
>>> drivers/usb/gadget/function/f_tcm.c | 36 +++++++--------
>>> drivers/usb/gadget/function/f_uac1_legacy.c | 2 +-
>>> drivers/usb/gadget/function/f_uvc.c | 5 ++-
>>> drivers/usb/gadget/function/u_audio.c | 4 +-
>>> include/linux/usb/composite.h | 2 +-
>>> 21 files changed, 99 insertions(+), 71 deletions(-)
>>>
>> I think we should create a new function and keep the old
>> config_ep_by_speed() for default alt-setting (e.i. have
>> config_ep_by_speed calls the new function with default alt-setting 0).
>> This way, we can keep compatibility with old function drivers and
>> minimize changes. At least that's what we did.
>>
> I don't think we need the separate function.
> If we set last parameter alt=0 then this function will work in the same way as old one.
>
I wasn't talking about that. This patch modifies the
config_ep_by_speed() parameters, which requires to make a change to
every function driver of the kernel, and all in a single patch. This
makes it difficult to backport this fix. The only function driver that
you really need this fix for is f_tcm because of the stream eps right?
You could just add a function like
int config_ep_by_speed_and_alt(struct usb_gadget *g, struct
usb_function *f, unsigned int alt, struct usb_ep *_ep);
Then redefine config_ep_by_speed() to use it
int config_ep_by_speed(struct usb_gadget *g,
struct usb_function *f,
struct usb_ep *_ep)
{
return config_ep_by_speed_and_alt(g, f, 0, _ep);
}
This way, 1) you can split this patch, 2) you only need to make a fix to
f_tcm, 3) this fix can be backported much easier.
Anyways, this is just a suggestion. It's up to the maintainers to decide.
BR,
Thinh
^ permalink raw reply
* [Virtio-fs] One virtiofs daemon per exported dir requirement
From: Vivek Goyal @ 2020-02-14 19:27 UTC (permalink / raw)
To: virtio-fs-list; +Cc: Mrunal Patel, Miklos Szeredi
Hi,
Dan Walsh and Mrunal mentioned that one virtiofsd daemon per exported
directory requirement sounds excessive. For container use case, they have
atleast 2-3 more directories they need to export (secrets and /etc/host). And
that means 3-4 virtiofsd running for each kata container.
One option seems that bind mount all exports in one directory and export
that directory using one virtiofsd. I am aware of atleast one problem
with that configuraiton and that is possibility of inode number collision
if bind mounts are coming from different devices. Not sure how many
applications care though. Sergio is looking into solving this issue. It
might take a while though.
Any other thoughts?
Thanks
Vivek
^ permalink raw reply
* digital microphone on google chromebook code name banon
From: Chris Gorman @ 2020-02-14 19:26 UTC (permalink / raw)
To: linux-kernel
Hello All,
I have a problem with my laptop recording via the digital microphone.
I did try to explain the problem on
https://bugzilla.kernel.org/show_bug.cgi?id=95681, but I have heard no
response on the issue, so I am bugging the mailing list in hopes that
someone will have a magic fix for me. ;)
My laptop is a google chromebook, braswell, banon. It is of the intel
strago family. When I try to record all I get is white noise. I can
reduce the level of noise via alsamixer, but I have to reduce all the
capture levels to 5 or lower.
I reached out to Sam McNally (thank you sam) from chromium regarding
his patch to cht_bsw_rt5645.c
adebb11139029ddf1fba6f796c4a476f17eacddc. He was quite nice and
helpful. According to Sam, the banon chromebooks dmic works with
their chromeos 4.9 and chromeos 5.4 kernels. Unfortunately the dmic
still failed on my system when I tried the chromeos 5.4 kernel.
Perhaps the problem is my new coreboot 4.11 bios, whereas chrome uses
an older bios? I don't know.
Sam also pointed me to checking /sys/kernel/debug/clk/clk_summary.
While recording I get..
pmc_plt_clk_0 0 0 0 19200000
0 0 50000
and while playing everything's fine and I get...
pmc_plt_clk_0 1 1 0 19200000
0 0 50000
This is clearly the problem. I don't know how to get the clock
working with the capture function though.
My kernel configs are ...
SOUND = y
SND = y
SND_SOC = y
SND_SOC_INTEL_MACH = y
SND_SST_ATOM_HIFI2_PLATFORM = y
SND_SST_ATOM_HIFI2_PLATFORM_ACPI = y
I2C = y
ACPI = y
X86_INTEL_LPSS = y
SND_SOC_ACPI = y
SND_SOC_INTEL_CHT_BSW_RT5645_MACH = y
SND_SOC_RT5645 = y
SND_SOC_DMIC = y
and I am running linux 5.5.0. I welcome patches and suggestions, but
have not subscribed to the mailing list because of the volume of
emails, so please cc me with any response.
Thanks in advance.
Chris Gorman
^ permalink raw reply
* [PATCH 1/2] arm64: dts: imx8mm-evk: add phy-reset-gpios for fec1
From: Alifer Moraes @ 2020-02-14 19:27 UTC (permalink / raw)
To: robh+dt
Cc: mark.rutland, shawnguo, s.hauer, kernel, festevam, linux-imx,
peng.fan, leonard.crestez, devicetree, linux-kernel,
Alifer Moraes
imx8mm-evk has a GPIO connected to AR8031 Ethernet PHY's reset pin.
Describe it in the device tree, following phy's datasheet reset duration of 10ms.
Tested booting via NFS.
Signed-off-by: Alifer Moraes <alifer.wsdm@gmail.com>
---
Originally sent by Peng Fan <peng.fan@nxp.com>
Back then CONFIG_AT803X_PHY was set as "m" in defconfig so the boot process hung
at nfs boot, now that CONFIG_AT803X_PHY is set as "y" by default, the patch works
correctly.
Peng's original patch missed to pass the phy-reset-duration, according to the AR8031
datasheet the reset GPIO needs to stay low for 10ms.
Original thread: https://lkml.org/lkml/2019/10/21/347
arch/arm64/boot/dts/freescale/imx8mm-evk.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
index 28ab17a277bb..11903ca86f0e 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
@@ -82,6 +82,8 @@
pinctrl-0 = <&pinctrl_fec1>;
phy-mode = "rgmii-id";
phy-handle = <ðphy0>;
+ phy-reset-gpios = <&gpio4 22 GPIO_ACTIVE_LOW>;
+ phy-reset-duration = <10>;
fsl,magic-packet;
status = "okay";
--
2.17.1
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: imx8mq-evk: add phy-reset-gpios for fec1
From: Alifer Moraes @ 2020-02-14 19:27 UTC (permalink / raw)
To: robh+dt
Cc: mark.rutland, shawnguo, s.hauer, kernel, festevam, linux-imx,
peng.fan, leonard.crestez, devicetree, linux-kernel,
Alifer Moraes
In-Reply-To: <20200214192750.20845-1-alifer.wsdm@gmail.com>
imx8mq-evk has a GPIO connected to AR8031 Ethernet PHY's reset pin.
Describe it in the device tree, following phy's datasheet reset duration of 10ms.
Tested booting via NFS.
Signed-off-by: Alifer Moraes <alifer.wsdm@gmail.com>
---
arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
index c36685916683..a49e2bf8afe5 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
@@ -110,6 +110,8 @@
pinctrl-0 = <&pinctrl_fec1>;
phy-mode = "rgmii-id";
phy-handle = <ðphy0>;
+ phy-reset-gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
+ phy-reset-duration = <10>;
fsl,magic-packet;
status = "okay";
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 3/5] drm/virtio: track whether or not a context has been initiated
From: Chia-I Wu @ 2020-02-14 19:27 UTC (permalink / raw)
To: Gurchetan Singh; +Cc: Gerd Hoffmann, ML dri-devel, jbates
In-Reply-To: <20200213231805.622-4-gurchetansingh@chromium.org>
On Thu, Feb 13, 2020 at 3:18 PM Gurchetan Singh
<gurchetansingh@chromium.org> wrote:
>
> Use an atomic variable to track whether a context has been
> initiated.
>
> v2: Fix possible race (@olv)
>
> Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
> drivers/gpu/drm/virtio/virtgpu_ioctl.c | 3 +++
> drivers/gpu/drm/virtio/virtgpu_kms.c | 1 +
> 3 files changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index 72c1d9b59dfe..ca505984f8ab 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -209,6 +209,7 @@ struct virtio_gpu_device {
>
> struct virtio_gpu_fpriv {
> uint32_t ctx_id;
> + atomic_t context_initiated;
> };
>
> /* virtio_ioctl.c */
> diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> index 896c3f419a6d..a98884462944 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> @@ -44,6 +44,9 @@ void virtio_gpu_create_context(struct drm_device *dev,
> if (!vgdev->has_virgl_3d)
> return;
>
> + if (!atomic_add_unless(&vfpriv->context_initiated, 1, 1))
> + return;
> +
How does this work? When thread A and B enter this function at the
same time, and thread B returns early, it is possible that thread B
queues other commands before thread A has the chance to queue
virtio_gpu_cmd_context_create.
> get_task_comm(dbgname, current);
> virtio_gpu_cmd_context_create(vgdev, vfpriv->ctx_id,
> strlen(dbgname), dbgname);
> diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c
> index 282558576527..25248bad3fc4 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_kms.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
> @@ -263,6 +263,7 @@ int virtio_gpu_driver_open(struct drm_device *dev, struct drm_file *file)
> }
>
> vfpriv->ctx_id = handle + 1;
> + atomic_set(&vfpriv->context_initiated, 0);
> file->driver_priv = vfpriv;
> virtio_gpu_create_context(dev, file);
> return 0;
> --
> 2.25.0.265.gbab2e86ba0-goog
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 1/7] e2fsck: Clarify overflow link count error message
From: Andreas Dilger @ 2020-02-14 19:27 UTC (permalink / raw)
To: Jan Kara; +Cc: Ted Tso, linux-ext4
In-Reply-To: <20200213101602.29096-2-jack@suse.cz>
[-- Attachment #1: Type: text/plain, Size: 3580 bytes --]
On Feb 13, 2020, at 3:15 AM, Jan Kara <jack@suse.cz> wrote:
>
> When directory link count is set to overflow value (1) but during pass 4
> we find out the exact link count would fit, we either silently fix this
> (which is not great because e2fsck then reports the fs was modified but
> output doesn't indicate why in any way), or we report that link count is
> wrong and ask whether we should fix it (in case -n option was
> specified). The second case is even more misleading because it suggests
> non-trivial fs corruption which then gets silently fixed on the next
> run. Similarly to how we fix up other non-problems, just create a new
> error message for the case directory link count is not overflown anymore
> and always report it to clarify what is going on.
>
> Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
> ---
> e2fsck/pass4.c | 20 ++++++++++++++++----
> e2fsck/problem.c | 5 +++++
> e2fsck/problem.h | 3 +++
> 3 files changed, 24 insertions(+), 4 deletions(-)
>
> diff --git a/e2fsck/pass4.c b/e2fsck/pass4.c
> index 10be7f87180d..8c2d2f1fca12 100644
> --- a/e2fsck/pass4.c
> +++ b/e2fsck/pass4.c
> @@ -237,6 +237,8 @@ void e2fsck_pass4(e2fsck_t ctx)
> link_counted = 1;
> }
> if (link_counted != link_count) {
> + int fix_nlink = 0;
> +
> e2fsck_read_inode_full(ctx, i, EXT2_INODE(inode),
> inode_size, "pass4");
> pctx.ino = i;
> @@ -250,10 +252,20 @@ void e2fsck_pass4(e2fsck_t ctx)
> pctx.num = link_counted;
> /* i_link_count was previously exceeded, but no longer
> * is, fix this but don't consider it an error */
> - if ((isdir && link_counted > 1 &&
> - (inode->i_flags & EXT2_INDEX_FL) &&
> - link_count == 1 && !(ctx->options & E2F_OPT_NO)) ||
> - fix_problem(ctx, PR_4_BAD_REF_COUNT, &pctx)) {
> + if (isdir && link_counted > 1 &&
> + (inode->i_flags & EXT2_INDEX_FL) &&
> + link_count == 1) {
> + if ((ctx->options & E2F_OPT_READONLY) == 0) {
> + fix_nlink =
> + fix_problem(ctx,
> + PR_4_DIR_OVERFLOW_REF_COUNT,
> + &pctx);
> + }
> + } else {
> + fix_nlink = fix_problem(ctx, PR_4_BAD_REF_COUNT,
> + &pctx);
> + }
> + if (fix_nlink) {
> inode->i_links_count = link_counted;
> e2fsck_write_inode_full(ctx, i,
> EXT2_INODE(inode),
> diff --git a/e2fsck/problem.c b/e2fsck/problem.c
> index c7c0ba986006..e79c853b2096 100644
> --- a/e2fsck/problem.c
> +++ b/e2fsck/problem.c
> @@ -2035,6 +2035,11 @@ static struct e2fsck_problem problem_table[] = {
> N_("@d exceeds max links, but no DIR_NLINK feature in @S.\n"),
> PROMPT_FIX, 0, 0, 0, 0 },
>
> + /* Directory inode ref count set to overflow but could be exact value */
> + { PR_4_DIR_OVERFLOW_REF_COUNT,
> + N_("@d @i %i ref count set to overflow but could be exact value %N. "),
> + PROMPT_FIX, PR_PREEN_OK, 0, 0, 0 },
> +
> /* Pass 5 errors */
>
> /* Pass 5: Checking group summary information */
> diff --git a/e2fsck/problem.h b/e2fsck/problem.h
> index c7f65f6dee0f..4185e5175cab 100644
> --- a/e2fsck/problem.h
> +++ b/e2fsck/problem.h
> @@ -1164,6 +1164,9 @@ struct problem_context {
> /* directory exceeds max links, but no DIR_NLINK feature in superblock */
> #define PR_4_DIR_NLINK_FEATURE 0x040006
>
> +/* Directory ref count set to overflow but it doesn't have to be */
> +#define PR_4_DIR_OVERFLOW_REF_COUNT 0x040007
> +
> /*
> * Pass 5 errors
> */
> --
> 2.16.4
>
Cheers, Andreas
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 873 bytes --]
^ permalink raw reply
* Re: [PATCH 2/7] e2fsck: Fix indexed dir rehash failure with metadata_csum enabled
From: Andreas Dilger @ 2020-02-14 19:28 UTC (permalink / raw)
To: Jan Kara; +Cc: Ted Tso, linux-ext4
In-Reply-To: <20200213101602.29096-3-jack@suse.cz>
[-- Attachment #1: Type: text/plain, Size: 1951 bytes --]
On Feb 13, 2020, at 3:15 AM, Jan Kara <jack@suse.cz> wrote:
>
> E2fsck directory rehashing code can fail with ENOSPC due to a bug in
> ext2fs_htree_intnode_maxrecs() which fails to take metadata checksum
> into account and thus e.g. e2fsck can decide to create 1 indirect level
> of index tree when two are actually needed. Fix the logic to account for
> metadata checksum.
>
> Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
> ---
> lib/ext2fs/ext2fs.h | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/lib/ext2fs/ext2fs.h b/lib/ext2fs/ext2fs.h
> index 93ecf29c568d..5fde3343b1f1 100644
> --- a/lib/ext2fs/ext2fs.h
> +++ b/lib/ext2fs/ext2fs.h
> @@ -1783,7 +1783,6 @@ extern blk_t ext2fs_group_first_block(ext2_filsys fs, dgrp_t group);
> extern blk_t ext2fs_group_last_block(ext2_filsys fs, dgrp_t group);
> extern blk_t ext2fs_inode_data_blocks(ext2_filsys fs,
> struct ext2_inode *inode);
> -extern int ext2fs_htree_intnode_maxrecs(ext2_filsys fs, int blocks);
> extern unsigned int ext2fs_div_ceil(unsigned int a, unsigned int b);
> extern __u64 ext2fs_div64_ceil(__u64 a, __u64 b);
> extern int ext2fs_dirent_name_len(const struct ext2_dir_entry *entry);
> @@ -2015,9 +2014,14 @@ _INLINE_ blk_t ext2fs_inode_data_blocks(ext2_filsys fs,
> return (blk_t) ext2fs_inode_data_blocks2(fs, inode);
> }
>
> -_INLINE_ int ext2fs_htree_intnode_maxrecs(ext2_filsys fs, int blocks)
> +static inline int ext2fs_htree_intnode_maxrecs(ext2_filsys fs, int blocks)
> {
> - return blocks * ((fs->blocksize - 8) / sizeof(struct ext2_dx_entry));
> + int csum_size = 0;
> +
> + if (ext2fs_has_feature_metadata_csum(fs->super))
> + csum_size = sizeof(struct ext2_dx_tail);
> + return blocks * ((fs->blocksize - (8 + csum_size)) /
> + sizeof(struct ext2_dx_entry));
> }
>
> /*
> --
> 2.16.4
>
Cheers, Andreas
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 873 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.