Re: [PATCH v3 00/13] Add CMU/RMU/DMA/MMC/I2C support for Actions Semi
On Tue, Dec 29, 2020 at 11:17:15PM +0200, Cristian Ciocaltea wrote: > Hi, > > This patchset brings a series of improvements for the Actions Semi S500 > SoCs family, by adding support for Clock & Reset Management Units, DMA, > MMC, I2C & SIRQ controllers. > > Please note the patches consist mostly of DTS and bindings/compatibles > changes, since all the work they depend on has been already merged, > i.e. clock fixes/additions, pinctrl driver, sirq driver. > > For the moment, I have only enabled the features I could test on > RoseapplePi SBC. > Applied all patches except the 2 dmaengine patches for v5.12. Andreas, please let me know if you want to do the PR this time. Else I'll proceed. Thanks, Mani > Thanks, > Cristi > > Changes in v3: > - Squashed 'arm: dts: owl-s500-roseapplepi: Use UART clock from CMU' with > 'arm: dts: owl-s500: Set CMU clocks for UARTs', according to Mani's review > - Rebased series on v5.11-rc1 and dropped the already merged patches: > * dt-bindings: mmc: owl: Add compatible string for Actions Semi S500 SoC > * dt-bindings: i2c: owl: Convert Actions Semi Owl binding to a schema > * MAINTAINERS: Update entry for Actions Semi Owl I2C binding > * i2c: owl: Add compatible for the Actions Semi S500 I2C controller > > Changes in v2: > - Added new bindings/compatibles for S500 DMA, MMC & I2C controllers > - Added support for the SIRQ controller > - Added new entries in MAINTAINERS > - Updated naming of some patches in v1 > > Cristian Ciocaltea (13): > arm: dts: owl-s500: Add Clock Management Unit > arm: dts: owl-s500: Set CMU clocks for UARTs > arm: dts: owl-s500: Add Reset controller > dt-bindings: dma: owl: Add compatible string for Actions Semi S500 SoC > dmaengine: owl: Add compatible for the Actions Semi S500 DMA > controller > arm: dts: owl-s500: Add DMA controller > arm: dts: owl-s500: Add pinctrl & GPIO support > arm: dts: owl-s500: Add MMC support > arm: dts: owl-s500: Add I2C support > arm: dts: owl-s500: Add SIRQ controller > arm: dts: owl-s500-roseapplepi: Add uSD support > arm: dts: owl-s500-roseapplepi: Add I2C pinctrl configuration > MAINTAINERS: Add linux-actions ML for Actions Semi Arch > > .../devicetree/bindings/dma/owl-dma.yaml | 7 +- > MAINTAINERS | 1 + > arch/arm/boot/dts/owl-s500-cubieboard6.dts| 7 - > .../arm/boot/dts/owl-s500-guitar-bb-rev-b.dts | 7 - > .../arm/boot/dts/owl-s500-labrador-base-m.dts | 7 - > arch/arm/boot/dts/owl-s500-roseapplepi.dts| 97 +++- > arch/arm/boot/dts/owl-s500-sparky.dts | 7 - > arch/arm/boot/dts/owl-s500.dtsi | 140 ++ > drivers/dma/owl-dma.c | 3 +- > 9 files changed, 239 insertions(+), 37 deletions(-) > > -- > 2.30.0 >
C/C++ Code Reviewer Available
"Linux kernel's Kroah-Hartman: We're not struggling to get new coders, it's code review that's the bottleneck", says article at The Register. Ok, I've used C++ for 20 years, taught C/C++ at two universities, and developed real-time safety-critical systems. Need me? Contact me off-list. Rob -- Robin Rowe CinePaint Project Manager Beverly Hills, California
Re: [PATCH v3 11/13] arm: dts: owl-s500-roseapplepi: Add uSD support
On Tue, Dec 29, 2020 at 11:17:26PM +0200, Cristian Ciocaltea wrote:
> Add uSD support for RoseapplePi SBC using a fixed regulator as a
> temporary solution until PMIC support becomes available.
>
> Signed-off-by: Cristian Ciocaltea
Reviewed-by: Manivannan Sadhasivam
Thanks,
Mani
> ---
> Changes in v3:
> - None
>
> arch/arm/boot/dts/owl-s500-roseapplepi.dts | 50 ++
> 1 file changed, 50 insertions(+)
>
> diff --git a/arch/arm/boot/dts/owl-s500-roseapplepi.dts
> b/arch/arm/boot/dts/owl-s500-roseapplepi.dts
> index 800edf5d2d12..fe9ae3619422 100644
> --- a/arch/arm/boot/dts/owl-s500-roseapplepi.dts
> +++ b/arch/arm/boot/dts/owl-s500-roseapplepi.dts
> @@ -14,6 +14,7 @@ / {
> model = "Roseapple Pi";
>
> aliases {
> + mmc0 =
> serial2 =
> };
>
> @@ -25,6 +26,55 @@ memory@0 {
> device_type = "memory";
> reg = <0x0 0x8000>; /* 2GB */
> };
> +
> + /* Fixed regulator used in the absence of PMIC */
> + sd_vcc: sd-vcc {
> + compatible = "regulator-fixed";
> + regulator-name = "fixed-3.1V";
> + regulator-min-microvolt = <310>;
> + regulator-max-microvolt = <310>;
> + regulator-always-on;
> + };
> +};
> +
> + {
> + mmc0_pins: mmc0-pins {
> + pinmux {
> + groups = "sd0_d0_mfp", "sd0_d1_mfp", "sd0_d2_d3_mfp",
> + "sd0_cmd_mfp", "sd0_clk_mfp";
> + function = "sd0";
> + };
> +
> + drv-pinconf {
> + groups = "sd0_d0_d3_drv", "sd0_cmd_drv", "sd0_clk_drv";
> + drive-strength = <8>;
> + };
> +
> + bias0-pinconf {
> + pins = "sd0_d0", "sd0_d1", "sd0_d2",
> +"sd0_d3", "sd0_cmd";
> + bias-pull-up;
> + };
> +
> + bias1-pinconf {
> + pins = "sd0_clk";
> + bias-pull-down;
> + };
> + };
> +};
> +
> +/* uSD */
> + {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + no-sdio;
> + no-mmc;
> + no-1-8-v;
> + cd-gpios = < 117 GPIO_ACTIVE_LOW>;
> + bus-width = <4>;
> + vmmc-supply = <_vcc>;
> + vqmmc-supply = <_vcc>;
> };
>
> _timer {
> --
> 2.30.0
>
Re: [PATCH v2] mhi: use irq_flags if client driver configures it
On Tue, Dec 29, 2020 at 02:05:51AM -0500, Carl Huang wrote:
> If client driver has specified the irq_flags, mhi uses this specified
> irq_flags. Otherwise, mhi uses default irq_flags.
>
> The purpose of this change is to support one MSI vector for QCA6390.
> MHI will use one same MSI vector too in this scenario.
>
> In case of one MSI vector, IRQ_NO_BALANCING is needed when irq handler
> is requested. The reason is if irq migration happens, the msi_data may
> change too. However, the msi_data is already programmed to QCA6390
> hardware during initialization phase. This msi_data inconsistence will
> result in crash in kernel.
>
> Another issue is in case of one MSI vector, IRQF_NO_SUSPEND will trigger
> WARNINGS because QCA6390 wants to disable the IRQ during the suspend.
>
> To avoid above two issues, QCA6390 driver specifies the irq_flags in case
> of one MSI vector when mhi_register_controller is called.
>
> Signed-off-by: Carl Huang
Small nitpick below, with that addressed,
Reviewed-by: Manivannan Sadhasivam
> ---
> v2:
> - document irq_flags added to mhi_controller
>
> drivers/bus/mhi/core/init.c | 9 +++--
> include/linux/mhi.h | 2 ++
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
> index 0ffdebd..5f74e1e 100644
> --- a/drivers/bus/mhi/core/init.c
> +++ b/drivers/bus/mhi/core/init.c
> @@ -148,12 +148,17 @@ int mhi_init_irq_setup(struct mhi_controller *mhi_cntrl)
> {
> struct mhi_event *mhi_event = mhi_cntrl->mhi_event;
> struct device *dev = _cntrl->mhi_dev->dev;
> + unsigned long irq_flags = IRQF_SHARED | IRQF_NO_SUSPEND;
> int i, ret;
>
> + /* if client driver has set irq_flags, use it */
s/client driver/controller driver
Thanks,
Mani
> + if (mhi_cntrl->irq_flags)
> + irq_flags = mhi_cntrl->irq_flags;
> +
> /* Setup BHI_INTVEC IRQ */
> ret = request_threaded_irq(mhi_cntrl->irq[0], mhi_intvec_handler,
> mhi_intvec_threaded_handler,
> -IRQF_SHARED | IRQF_NO_SUSPEND,
> +irq_flags,
> "bhi", mhi_cntrl);
> if (ret)
> return ret;
> @@ -171,7 +176,7 @@ int mhi_init_irq_setup(struct mhi_controller *mhi_cntrl)
>
> ret = request_irq(mhi_cntrl->irq[mhi_event->irq],
> mhi_irq_handler,
> - IRQF_SHARED | IRQF_NO_SUSPEND,
> + irq_flags,
> "mhi", mhi_event);
> if (ret) {
> dev_err(dev, "Error requesting irq:%d for ev:%d\n",
> diff --git a/include/linux/mhi.h b/include/linux/mhi.h
> index d4841e5..918cf6a 100644
> --- a/include/linux/mhi.h
> +++ b/include/linux/mhi.h
> @@ -353,6 +353,7 @@ struct mhi_controller_config {
> * @fbc_download: MHI host needs to do complete image transfer (optional)
> * @pre_init: MHI host needs to do pre-initialization before power up
> * @wake_set: Device wakeup set flag
> + * @irq_flags: irq flags passed to request_irq (optional)
> *
> * Fields marked as (required) need to be populated by the controller driver
> * before calling mhi_register_controller(). For the fields marked as
> (optional)
> @@ -442,6 +443,7 @@ struct mhi_controller {
> bool fbc_download;
> bool pre_init;
> bool wake_set;
> + unsigned long irq_flags;
> };
>
> /**
> --
> 2.7.4
>
Re: [PATCH v6 3/8] power: supply: max8997_charger: Set CHARGER current limit
On Thu, 31 Dec 2020 07:22:22 +0800, kernel test robot wrote: > Hi Timon, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on regulator/for-next] > [also build test ERROR on pinctrl-samsung/for-next krzk/for-next v5.11-rc1 > next-20201223] > [cannot apply to robh/for-next] > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch] > > url: > https://github.com/0day-ci/linux/commits/Timon-Baetz/extcon-max8997-Add-CHGINS-and-CHGRM-interrupt-handling/20201231-045812 > base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git > for-next > config: arm-randconfig-r004-20201230 (attached as .config) > compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project > 3c0d36f977d9e012b245c796ddc8596ac3af659b) > reproduce (this is a W=1 build): > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # install arm cross compiling tool for clang build > # apt-get install binutils-arm-linux-gnueabi > # > https://github.com/0day-ci/linux/commit/3a597219bbfc1f9a0b65b9662b7b95bbb7cf728f > git remote add linux-review https://github.com/0day-ci/linux > git fetch --no-tags linux-review > Timon-Baetz/extcon-max8997-Add-CHGINS-and-CHGRM-interrupt-handling/20201231-045812 > git checkout 3a597219bbfc1f9a0b65b9662b7b95bbb7cf728f > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All errors (new ones prefixed by >>): > > >> drivers/power/supply/max8997_charger.c:261:9: error: implicit declaration > >> of function 'devm_extcon_register_notifier_all' > >> [-Werror,-Wimplicit-function-declaration] >ret = devm_extcon_register_notifier_all(>dev, > charger->edev, > ^ >drivers/power/supply/max8997_charger.c:261:9: note: did you mean > 'devm_extcon_register_notifier'? >include/linux/extcon.h:263:19: note: 'devm_extcon_register_notifier' > declared here >static inline int devm_extcon_register_notifier(struct device *dev, > ^ >1 error generated. This is failing because CONFIG_EXTCON is not set and *_all() don't have stub implementations in extcon.h. Should I add a fix for it in this series?
drivers/thunderbolt/test.c:1529:1: warning: the frame size of 1216 bytes is larger than 1024 bytes
Hi Mika,
First bad commit (maybe != root cause):
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f6e1ea19649216156576aeafa784e3b4cee45549
commit: 2c6ea4e2cefe2e86af782a5b8e1070f4d434f2f2 thunderbolt: Allow KUnit tests
to be built also when CONFIG_USB4=m
date: 4 months ago
config: arm-randconfig-r034-20201231 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2c6ea4e2cefe2e86af782a5b8e1070f4d434f2f2
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 2c6ea4e2cefe2e86af782a5b8e1070f4d434f2f2
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/thunderbolt/test.c: In function 'tb_test_tunnel_usb3':
>> drivers/thunderbolt/test.c:1529:1: warning: the frame size of 1216 bytes is
>> larger than 1024 bytes [-Wframe-larger-than=]
1529 | }
| ^
drivers/thunderbolt/test.c: In function 'tb_test_tunnel_dp_max_length':
drivers/thunderbolt/test.c:1474:1: warning: the frame size of 1080 bytes is
larger than 1024 bytes [-Wframe-larger-than=]
1474 | }
| ^
drivers/thunderbolt/test.c: In function 'tb_test_tunnel_pcie':
drivers/thunderbolt/test.c:1260:1: warning: the frame size of 1216 bytes is
larger than 1024 bytes [-Wframe-larger-than=]
1260 | }
| ^
Kconfig warnings: (for reference only)
WARNING: unmet direct dependencies detected for UIO
Depends on MMU
Selected by
- CNIC && NETDEVICES && ETHERNET && NET_VENDOR_BROADCOM && PCI && (IPV6 ||
IPV6
vim +1529 drivers/thunderbolt/test.c
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1475
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1476 static void
tb_test_tunnel_usb3(struct kunit *test)
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1477 {
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1478struct tb_switch *host,
*dev1, *dev2;
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1479struct tb_tunnel
*tunnel1, *tunnel2;
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1480struct tb_port *down,
*up;
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1481
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1482/*
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1483 * Create USB3 tunnel
between host and two devices.
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1484 *
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1485 * [Host]
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1486 *1 |
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1487 *1 |
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1488 * [Device #1]
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1489 * \ 7
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1490 * \ 1
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1491 * [Device #2]
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1492 */
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1493host = alloc_host(test);
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1494dev1 =
alloc_dev_default(test, host, 0x1, true);
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1495dev2 =
alloc_dev_default(test, dev1, 0x701, true);
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1496
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1497down = >ports[12];
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1498up = >ports[16];
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1499tunnel1 =
tb_tunnel_alloc_usb3(NULL, up, down, 0, 0);
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1500KUNIT_ASSERT_TRUE(test,
tunnel1 != NULL);
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1501KUNIT_EXPECT_EQ(test,
tunnel1->type, (enum tb_tunnel_type)TB_TUNNEL_USB3);
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1502
KUNIT_EXPECT_PTR_EQ(test, tunnel1->src_port, down);
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1503
KUNIT_EXPECT_PTR_EQ(test, tunnel1->dst_port, up);
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1504KUNIT_ASSERT_EQ(test,
tunnel1->npaths, (size_t)2);
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1505KUNIT_ASSERT_EQ(test,
tunnel1->paths[0]->path_length, 2);
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1506
KUNIT_EXPECT_PTR_EQ(test, tunnel1->paths[0]->hops[0].in_port, down);
40c14d9f4f6d348 Mika Westerberg 2020-05-04 1507
KUNIT_EXPECT_PTR_EQ(test, tunnel1->paths[0]->hops[1].out_port, up);
40c14d9f4f6d348 Mika Westerberg
Re: [PATCH] genirq: Export irq_check_status_bit
Am 30.12.20 um 16:45 schrieb Arnd Bergmann: > From: Arnd Bergmann > > Changing some inline functions to use the new irq_check_status_bit > function out of line breaks calling them from loadable modules: > > ERROR: modpost: "irq_check_status_bit" [drivers/perf/arm_spe_pmu.ko] > undefined! Just FYI: Levi Yun sent a similar patch a on Dec, 26 already: https://lore.kernel.org/lkml/20201226123818.GA693525@ubuntu/ But nothing happened afaics, the festival season is taking its toll. ;-) I'd like to see this fixed, too, as it broke my Kernel Vanilla builds for Fedora (https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories) just a day after I finally started building packages for aarch64, too. Bad timing. :-D Ciao, Thorsten
Re: [PATCH] mmc: sdhci-msm: Fix possible NULL pointer exception
On 12/22/2020 2:18 PM, Md Sadre Alam wrote: of_device_get_match_data returns NULL when no match. So add the NULL pointer check to avoid dereference. Signed-off-by: Md Sadre Alam --- Reviewed-by: Veerabhadrarao Badiganti drivers/mmc/host/sdhci-msm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c index 9c7927b..f20e424 100644 --- a/drivers/mmc/host/sdhci-msm.c +++ b/drivers/mmc/host/sdhci-msm.c @@ -2235,6 +2235,8 @@ static int sdhci_msm_probe(struct platform_device *pdev) * the data associated with the version info. */ var_info = of_device_get_match_data(>dev); + if (!var_info) + goto pltfm_free; msm_host->mci_removed = var_info->mci_removed; msm_host->restore_dll_config = var_info->restore_dll_config;
[rcu:dev.2020.12.26a] BUILD SUCCESS 99f7c53b43866761e4df3460ace228e7520898f3
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev.2020.12.26a branch HEAD: 99f7c53b43866761e4df3460ace228e7520898f3 squash! clocksource: Retry clock read if long delays detected elapsed time: 724m configs tested: 133 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig nios2alldefconfig powerpc pcm030_defconfig x86_64 defconfig sh sh7785lcr_32bit_defconfig mipsbcm63xx_defconfig armzeus_defconfig arm64alldefconfig h8300 defconfig shmigor_defconfig powerpc akebono_defconfig powerpc obs600_defconfig powerpcklondike_defconfig armmvebu_v5_defconfig s390 alldefconfig sh rts7751r2dplus_defconfig arm colibri_pxa300_defconfig mips fuloong2e_defconfig powerpc ppc6xx_defconfig powerpc mpc83xx_defconfig mips lemote2f_defconfig arm imote2_defconfig powerpc tqm8xx_defconfig arm u8500_defconfig powerpc skiroot_defconfig armoxnas_v6_defconfig mips loongson1b_defconfig mips loongson1c_defconfig x86_64 alldefconfig m68k sun3_defconfig mips ip22_defconfig powerpc ppc44x_defconfig arm sama5_defconfig pariscgeneric-64bit_defconfig powerpc pmac32_defconfig arm pxa910_defconfig openriscor1ksim_defconfig sh se7721_defconfig powerpcsam440ep_defconfig arc haps_hs_smp_defconfig riscvnommu_virt_defconfig ia64 alldefconfig sh sh7710voipgw_defconfig arm pcm027_defconfig mips capcella_defconfig arm footbridge_defconfig arm milbeaut_m10v_defconfig sparc sparc32_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a005-20201230 x86_64 randconfig-a001-20201230 x86_64 randconfig-a006-20201230 x86_64 randconfig-a002-20201230 x86_64 randconfig-a004-20201230 x86_64 randconfig-a003-20201230 i386 randconfig-a005-20201230 i386 randconfig-a006-20201230 i386 randconfig-a004-20201230 i386 randconfig-a003-20201230 i386 randconfig-a002-20201230 i386 randconfig-a001-20201230 x86_64 randconfig-a015-20201231 x86_64 randconfig-a014-20201231 x86_64 randconfig-a011
[PATCH RFC] KVM: arm64: vgic: Decouple the check of the EnableLPIs bit from the ITS LPI translation
When the EnableLPIs bit is set to 0, any ITS LPI requests in the
Redistributor would be ignored. And this check is independent from
the ITS LPI translation. So it might be better to move the check
of the EnableLPIs bit out of the LPI resolving, and also add it
to the path that uses the translation cache. Besides it seems that
by this the invalidating of the translation cache caused by the LPI
disabling is unnecessary.
Not sure if I have missed something... Thanks.
Signed-off-by: Shenming Lu
---
arch/arm64/kvm/vgic/vgic-its.c | 9 +
arch/arm64/kvm/vgic/vgic-mmio-v3.c | 4 +---
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c
index 40cbaca81333..f53446bc154e 100644
--- a/arch/arm64/kvm/vgic/vgic-its.c
+++ b/arch/arm64/kvm/vgic/vgic-its.c
@@ -683,9 +683,6 @@ int vgic_its_resolve_lpi(struct kvm *kvm, struct vgic_its
*its,
if (!vcpu)
return E_ITS_INT_UNMAPPED_INTERRUPT;
- if (!vcpu->arch.vgic_cpu.lpis_enabled)
- return -EBUSY;
-
vgic_its_cache_translation(kvm, its, devid, eventid, ite->irq);
*irq = ite->irq;
@@ -738,6 +735,9 @@ static int vgic_its_trigger_msi(struct kvm *kvm, struct
vgic_its *its,
if (err)
return err;
+ if (!irq->target_vcpu->arch.vgic_cpu.lpis_enabled)
+ return -EBUSY;
+
if (irq->hw)
return irq_set_irqchip_state(irq->host_irq,
IRQCHIP_STATE_PENDING, true);
@@ -757,7 +757,8 @@ int vgic_its_inject_cached_translation(struct kvm *kvm,
struct kvm_msi *msi)
db = (u64)msi->address_hi << 32 | msi->address_lo;
irq = vgic_its_check_cache(kvm, db, msi->devid, msi->data);
- if (!irq)
+
+ if (!irq || !irq->target_vcpu->arch.vgic_cpu.lpis_enabled)
return -EWOULDBLOCK;
raw_spin_lock_irqsave(>irq_lock, flags);
diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
index 15a6c98ee92f..7b0749f7660d 100644
--- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
+++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
@@ -242,10 +242,8 @@ static void vgic_mmio_write_v3r_ctlr(struct kvm_vcpu *vcpu,
vgic_cpu->lpis_enabled = val & GICR_CTLR_ENABLE_LPIS;
- if (was_enabled && !vgic_cpu->lpis_enabled) {
+ if (was_enabled && !vgic_cpu->lpis_enabled)
vgic_flush_pending_lpis(vcpu);
- vgic_its_invalidate_cache(vcpu->kvm);
- }
if (!was_enabled && vgic_cpu->lpis_enabled)
vgic_enable_lpis(vcpu);
--
2.19.1
[PATCH] arm64: add pmem module for kernel update
Category: feature
Bugzilla: NA
CVE: NA
Use reserved memory to create a pmem device to store the
processes information that dumped before kernel update.
When you want to use this feature you need to declare by
"pmemmem=pmem_size:pmem_phystart" in cmdline.
(exp: pmemmem=100M:0x2020)
Signed-off-by: Zhuling
---
arch/arm64/kernel/setup.c | 5 +++
arch/arm64/mm/init.c | 90 +++
drivers/nvdimm/Kconfig| 11 +
drivers/nvdimm/Makefile | 3 ++
drivers/nvdimm/kup_pmem.c | 106 ++
include/linux/ioport.h| 1 +
include/linux/mm.h| 4 ++
lib/Kconfig | 6 +++
8 files changed, 226 insertions(+)
create mode 100644 drivers/nvdimm/kup_pmem.c
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 133257f..0bd9429 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -237,6 +237,11 @@ static void __init request_standard_resources(void)
if (kernel_data.start >= res->start &&
kernel_data.end <= res->end)
request_resource(res, _data);
+#ifdef CONFIG_KUP_PMEM_MEMORY
+ if (pmem_res.end)
+ insert_resource(_resource, _res);
+#endif
+
#ifdef CONFIG_KEXEC_CORE
/* Userspace will find "Crash kernel" region in /proc/iomem. */
if (crashk_res.end && crashk_res.start >= res->start &&
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 0955406..9d1395e 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -62,6 +62,18 @@ EXPORT_SYMBOL(memstart_addr);
phys_addr_t arm64_dma_phys_limit __ro_after_init;
static phys_addr_t arm64_dma32_phys_limit __ro_after_init;
+#ifdef CONFIG_KUP_PMEM_MEMORY
+static unsigned long long pmem_size, pmem_phystart;
+
+struct resource pmem_res = {
+ .name = "Kpmem Dev",
+ .start = 0,
+ .end = 0,
+ .flags = IORESOURCE_MEM,
+ .desc = IORES_DESC_KPMEM_DEV
+};
+#endif
+
#ifdef CONFIG_KEXEC_CORE
/*
* reserve_crashkernel() - reserves memory for crash kernel
@@ -123,6 +135,80 @@ static void __init reserve_crashkernel(void)
}
#endif /* CONFIG_KEXEC_CORE */
+#ifdef CONFIG_KUP_PMEM_MEMORY
+/*
+ * reserve_pmem() - reserves memory for pmem
+ *
+ * This function reserves memory area given in "pmemmem=" kernel command
+ * line parameter. The memory reserved is used by pmem restore progress
+ * when kernel update.
+ */
+static int __init parse_pmem(char *par)
+{
+ char *cur = par;
+
+ if (!par)
+ return 0;
+
+ pmem_size = 0;
+ pmem_phystart = 0;
+
+ pmem_size = memparse(par, );
+ if (par == cur) {
+ pr_warn("pmem: memory value expected\n");
+ return -EINVAL;
+ }
+
+ if (*cur == ':')
+ pmem_phystart = memparse(cur+1, );
+ else if (*cur != ' ' && *cur != '\0') {
+ pr_warn("pmem: unrecognized char %c\n", *cur);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+early_param("pmemmem", parse_pmem);
+
+static void __init reserve_pmem(void)
+{
+ if (!pmem_size || !pmem_phystart) {
+ return;
+ }
+
+ pmem_size = PAGE_ALIGN(pmem_size);
+
+ if (!memblock_is_region_memory(pmem_phystart, pmem_size)) {
+ pr_warn("cannot reserve pmem: region is not memory!\n");
+ return;
+ }
+
+ if (memblock_is_region_reserved(pmem_phystart, pmem_size)) {
+ pr_warn("cannot reserve pmem: region overlaps reserved
memory!\n");
+ return;
+ }
+
+ if (!IS_ALIGNED(pmem_phystart, SZ_2M)) {
+ pr_warn("cannot reserve pmem: base address is not 2MB
aligned\n");
+ return;
+ }
+ memblock_reserve(pmem_phystart, pmem_size);
+ memblock_remove(pmem_phystart, pmem_size);
+ pr_info("pmem reserved: 0x%016llx - 0x%016llx (%lld MB)\n",
+ pmem_phystart, pmem_phystart + pmem_size, pmem_size >> 20);
+
+ pmem_res.start = pmem_phystart;
+ pmem_res.end = pmem_phystart + pmem_size - 1;
+}
+#else
+static void __init reserve_pmem(void)
+{
+}
+static void __init reserve_pmem_pages(void)
+{
+}
+#endif /*CONFIG_KUP_PMEM_MEMORY*/
+
#ifdef CONFIG_CRASH_DUMP
static int __init early_init_dt_scan_elfcorehdr(unsigned long node,
const char *uname, int depth, void *data)
@@ -390,6 +476,10 @@ void __init arm64_memblock_init(void)
reserve_elfcorehdr();
+#ifdef CONFIG_KUP_PMEM_MEMORY
+ reserve_pmem();
+#endif
+
high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
dma_contiguous_reserve(arm64_dma32_phys_limit);
diff --git a/drivers/nvdimm/Kconfig b/drivers/nvdimm/Kconfig
index b7d1eb3..7f5fa22 100644
--- a/drivers/nvdimm/Kconfig
+++ b/drivers/nvdimm/Kconfig
@@ -119,6 +119,17 @@ config NVDIMM_KEYS
depends on ENCRYPTED_KEYS
depends on (LIBNVDIMM=ENCRYPTED_KEYS)
[PATCH] PM: sleep: core: Resume suspended device if direct-complete is disabled
HDA controller can't be runtime-suspended after commit 215a22ed31a1
("ALSA: hda: Refactor codjc PM to use direct-complete optimization"),
which enables direct-complete for HDA codec.
The HDA codec driver doesn't expect direct-complete will be disabled
after it returns a positive value from prepare() callback. So freeze()
is called directly when it's runtime-suspended, breaks the balance of
its internal codec_powered counting.
So if a device is prepared for direct-complete but PM core breaks the
assumption, resume the device to keep PM operations balanced.
Fixes: 215a22ed31a1 ("ALSA: hda: Refactor codec PM to use direct-complete
optimization")
Signed-off-by: Kai-Heng Feng
---
drivers/base/power/main.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 46793276598d..9c0e25a92ad0 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -1849,6 +1849,10 @@ static int device_prepare(struct device *dev,
pm_message_t state)
(ret > 0 || dev->power.no_pm_callbacks) &&
!dev_pm_test_driver_flags(dev, DPM_FLAG_NO_DIRECT_COMPLETE);
spin_unlock_irq(>power.lock);
+
+ if (ret > 0 && !dev->power.direct_complete)
+ pm_runtime_resume(dev);
+
return 0;
}
--
2.29.2
ERROR: modpost: ".mutex_unlock" undefined!
Hi Zhu, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: f6e1ea19649216156576aeafa784e3b4cee45549 commit: 2cf1ba9a4d15cb78b96ea97f727b93382c3f9a60 vhost_vdpa: implement IRQ offloading in vhost_vdpa date: 5 months ago config: powerpc-randconfig-r034-20201225 (attached as .config) compiler: powerpc64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2cf1ba9a4d15cb78b96ea97f727b93382c3f9a60 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 2cf1ba9a4d15cb78b96ea97f727b93382c3f9a60 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>, old ones prefixed by <<): >> ERROR: modpost: ".module_put" [virt/lib/irqbypass.ko] undefined! >> ERROR: modpost: ".mutex_unlock" [virt/lib/irqbypass.ko] undefined! >> ERROR: modpost: ".mutex_lock" [virt/lib/irqbypass.ko] undefined! >> ERROR: modpost: ".try_module_get" [virt/lib/irqbypass.ko] undefined! >> ERROR: modpost: ".__might_sleep" [virt/lib/irqbypass.ko] undefined! ERROR: modpost: ".dev_remove_offload" [net/nsh/nsh.ko] undefined! ERROR: modpost: ".dev_add_offload" [net/nsh/nsh.ko] undefined! ERROR: modpost: ".skb_pull_rcsum" [net/nsh/nsh.ko] undefined! ERROR: modpost: ".__csum_partial" [net/nsh/nsh.ko] undefined! ERROR: modpost: ".pskb_expand_head" [net/nsh/nsh.ko] undefined! ERROR: modpost: ".memcpy" [net/nsh/nsh.ko] undefined! ERROR: modpost: ".skb_push" [net/nsh/nsh.ko] undefined! ERROR: modpost: ".skb_mac_gso_segment" [net/nsh/nsh.ko] undefined! ERROR: modpost: ".__pskb_pull_tail" [net/nsh/nsh.ko] undefined! ERROR: modpost: ".flush_work" [net/vmw_vsock/vsock_loopback.ko] undefined! ERROR: modpost: ".vsock_core_unregister" [net/vmw_vsock/vsock_loopback.ko] undefined! ERROR: modpost: ".destroy_workqueue" [net/vmw_vsock/vsock_loopback.ko] undefined! ERROR: modpost: ".vsock_core_register" [net/vmw_vsock/vsock_loopback.ko] undefined! ERROR: modpost: ".__raw_spin_lock_init" [net/vmw_vsock/vsock_loopback.ko] undefined! ERROR: modpost: ".alloc_workqueue" [net/vmw_vsock/vsock_loopback.ko] undefined! ERROR: modpost: ".virtio_transport_recv_pkt" [net/vmw_vsock/vsock_loopback.ko] undefined! ERROR: modpost: ".virtio_transport_deliver_tap_pkt" [net/vmw_vsock/vsock_loopback.ko] undefined! ERROR: modpost: ".virtio_transport_free_pkt" [net/vmw_vsock/vsock_loopback.ko] undefined! ERROR: modpost: ".queue_work_on" [net/vmw_vsock/vsock_loopback.ko] undefined! ERROR: modpost: "._raw_spin_unlock_bh" [net/vmw_vsock/vsock_loopback.ko] undefined! ERROR: modpost: "._raw_spin_lock_bh" [net/vmw_vsock/vsock_loopback.ko] undefined! ERROR: modpost: ".vsock_addr_init" [net/vmw_vsock/vmw_vsock_virtio_transport_common.ko] undefined! ERROR: modpost: ".vsock_deliver_tap" [net/vmw_vsock/vmw_vsock_virtio_transport_common.ko] undefined! ERROR: modpost: ".cancel_delayed_work" [net/vmw_vsock/vmw_vsock_virtio_transport_common.ko] undefined! ERROR: modpost: ".release_sock" [net/vmw_vsock/vmw_vsock_virtio_transport_common.ko] undefined! ERROR: modpost: "._copy_to_iter" [net/vmw_vsock/vmw_vsock_virtio_transport_common.ko] undefined! ERROR: modpost: ".init_timer_key" [net/vmw_vsock/vmw_vsock_virtio_transport_common.ko] undefined! ERROR: modpost: ".vsock_find_bound_socket" [net/vmw_vsock/vmw_vsock_virtio_transport_common.ko] undefined! ERROR: modpost: ".vsock_assign_transport" [net/vmw_vsock/vmw_vsock_virtio_transport_common.ko] undefined! ERROR: modpost: ".refcount_warn_saturate" [net/vmw_vsock/vmw_vsock_virtio_transport_common.ko] undefined! ERROR: modpost: ".lock_sock_nested" [net/vmw_vsock/vmw_vsock_virtio_transport_common.ko] undefined! ERROR: modpost: ".vsock_stream_has_data" [net/vmw_vsock/vmw_vsock_virtio_transport_common.ko] undefined! ERROR: modpost: ".vsock_create_connected" [net/vmw_vsock/vmw_vsock_virtio_transport_common.ko] undefined! ERROR: modpost: "._raw_spin_lock_bh" [net/vmw_vsock/vmw_vsock_virtio_transport_common.ko] undefined! ERROR: modpost: ".queue_delayed_work_on" [net/vmw_vsock/vmw_vsock_virtio_transport_common.ko] undefined! ERROR: modpost: ".skb_put" [net/vmw_vsock/vmw_vsock_virtio_transport_common.ko] undefined! ERROR: modpost: ".__kmalloc" [net/vmw_vsock/vmw_vsock_virtio_transport_common.ko] undefined! ERROR: modpost: ".wait_woken" [net/vmw_vsock/vmw_vsock_virtio_transport_common.ko] undefined! ERROR: modpost: ".vsock_stream_has_space" [net/vmw_vsock/vmw_vsock_virtio_transport_common.ko] undefined! ERROR: modpost:
[tip:x86/misc] BUILD SUCCESS 4b2d8ca9208be636b30e924b1cbcb267b0740c93
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/misc branch HEAD: 4b2d8ca9208be636b30e924b1cbcb267b0740c93 x86/reboot: Add Zotac ZBOX CI327 nano PCI reboot quirk elapsed time: 721m configs tested: 48 configs skipped: 62 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig i386 allyesconfig i386 tinyconfig i386defconfig i386 randconfig-a005-20201230 i386 randconfig-a006-20201230 i386 randconfig-a004-20201230 i386 randconfig-a003-20201230 i386 randconfig-a002-20201230 i386 randconfig-a001-20201230 x86_64 randconfig-a005-20201230 x86_64 randconfig-a001-20201230 x86_64 randconfig-a006-20201230 x86_64 randconfig-a002-20201230 x86_64 randconfig-a004-20201230 x86_64 randconfig-a003-20201230 i386 randconfig-a016-20201230 i386 randconfig-a014-20201230 i386 randconfig-a012-20201230 i386 randconfig-a015-20201230 i386 randconfig-a011-20201230 i386 randconfig-a013-20201230 x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec clang tested configs: x86_64 randconfig-a015-20201230 x86_64 randconfig-a014-20201230 x86_64 randconfig-a016-20201230 x86_64 randconfig-a011-20201230 x86_64 randconfig-a013-20201230 x86_64 randconfig-a012-20201230 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: wg-crypt-wg0 process
Hi Jason,
Thanks for the detailed research and explanation.That's ok for me.
Regards.
Fatih USTA
On 30.12.2020 15:39, Jason A. Donenfeld wrote:
Hi Fatih,
Thanks for the report and the detailed test case. From what I can see,
this behavior presents itself both with the explicit ip link del and
without. When running with debugging enabled, I can see this in dmesg:
[558758.361056] wireguard: wg0: Keypair 244 destroyed for peer 21
[558758.546649] wireguard: wg0: Peer 21 (10.150.150.2:51820) destroyed
[558758.563317] wireguard: wg0: Interface destroyed
[558758.567803] wireguard: wg0: Keypair 243 destroyed for peer 22
[558758.733287] wireguard: wg0: Peer 22 (10.150.150.1:51820) destroyed
[558758.749991] wireguard: wg0: Interface destroyed
The fact that I see "Interface destroyed" for both interfaces means
that wg_destruct() is being called, which includes these calls:
destroy_workqueue(wg->handshake_receive_wq);
destroy_workqueue(wg->handshake_send_wq);
destroy_workqueue(wg->packet_crypt_wq);
In doing so, the output of ps changes from:
$ ps aux|grep wg0
root 200479 0.0 0.0 0 0 ?I13:06 0:00
[kworker/0:2-wg-crypt-wg0]
root 201226 0.0 0.0 0 0 ?I13:08 0:00
[kworker/1:4-wg-crypt-wg0]
root 201476 0.0 0.0 0 0 ?I< 13:11 0:00
[wg-crypt-wg0]
root 201484 0.0 0.0 0 0 ?I< 13:11 0:00
[wg-crypt-wg0]
to:
$ ps aux|grep wg0
root 200479 0.0 0.0 0 0 ?I13:06 0:00
[kworker/0:2-wg-crypt-wg0]
root 201226 0.0 0.0 0 0 ?I13:08 0:00
[kworker/1:4-wg-crypt-wg0]
What I suspect is happening is that destroying the workqueue does not
actually destroy the kthreads that they were using, so that they can
be reused (and eventually relabeled) by other drivers. Looking at the
stack of those indicates this is probably the case:
$ cat /proc/200479/stack
[<0>] worker_thread+0xba/0x3c0
[<0>] kthread+0x114/0x130
[<0>] ret_from_fork+0x1f/0x30
So it's just hanging out there idle waiting to be scheduled by
something new. In fact, while I was writing this email, that worker
already seems to have been reclaimed by another driver:
$ cat /proc/200479/comm
kworker/0:2-events
Now it's called "events".
This is happening because the kthread isn't actually destroyed, and
task->comm is being hijacked. In proc_task_name we have:
if (p->flags & PF_WQ_WORKER)
wq_worker_comm(tcomm, sizeof(tcomm), p);
else
__get_task_comm(tcomm, sizeof(tcomm), p);
That top condition holds for workqueue workers, and wq_worker_comm
winds up scnprintf'ing the current worker description in there:
/*
* ->desc tracks information (wq name or
* set_worker_desc()) for the latest execution. If
* current, prepend '+', otherwise '-'.
*/
if (worker->desc[0] != '\0') {
if (worker->current_work)
scnprintf(buf + off, size - off, "+%s",
worker->desc);
else
scnprintf(buf + off, size - off, "-%s",
worker->desc);
But worker->desc isn't set until process_one_work is called:
/*
* Record wq name for cmdline and debug reporting, may get
* overridden through set_worker_desc().
*/
strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN);
And it's never unset after the work is done and it's waiting idle in
worker_thread for the scheduler to reschedule it and eventually call
process_one_work on a new work unit.
It would be easy to just null out that string after the work is done
with something like:
worker->current_func(work);
worker->desc[0] = '\0';
But I guess this has never sufficiently bothered anyone before. I
suppose I could submit a patch and see how it's received. But it also
looks like the scnprintf above in wq_worker_comm distinguishes these
cases anyway. If there's a + it means that the work is active and if
there's a - it means that it's an old leftover thread. So maybe this
is fine as-is?
Jason
Re: [PATCH net-next] nfc: Add a virtual nci device driver
On Tue, Dec 29, 2020 at 6:16 AM Jakub Kicinski wrote: > > On Mon, 28 Dec 2020 18:45:07 +0900 Bongsu Jeon wrote: > > From: Bongsu Jeon > > > > A NCI virtual device can be made to simulate a NCI device in user space. > > Using the virtual NCI device, The NCI module and application can be > > validated. This driver supports to communicate between the virtual NCI > > device and NCI module. > > > > Signed-off-by: Bongsu Jeon > > net-next is still closed: > > http://vger.kernel.org/~davem/net-next.html > > Please repost in a few days. > > As far as the patch goes - please include some tests for the NCI/NFC > subsystem based on this virtual device, best if they live in tree under > tools/testing/selftest. thank you for your answer. I think that neard(NFC deamon) is necessary to test the NCI subsystem meaningfully. The NCI virtual device in user space can communicate with neard through this driver. Is it enough to make NCI virtual device at tools/nfc for some test?
Re: [PATCH v8 1/3] scsi: ufs: Protect some contexts from unexpected clock scaling
Hi Stanley,
I slightly updated this change, because I found that in
ufshcd_devfreq_scale(),
in order to call ufshcd_wb_ctrl(), clk_scale_lock write sem is released
once,
which breaks the assumption that clk_scale_lock wraps the entire func.
So,
in ufshcd_devfreq_scale(), I changed the up_write() to downgrade_write()
so that
the clk_scale_lock does not have to be released.
Thus, I removed your reviewed-by tag. It would be very helpful if you
can review
it one more time. Thanks.
Happy new year!!!
Regards,
Can Guo.
On 2020-12-30 19:29, Can Guo wrote:
In contexts like suspend, shutdown and error handling, we need to
suspend
devfreq to make sure these contexts won't be disturbed by clock
scaling.
However, suspending devfreq is not enough since users can still trigger
a
clock scaling by manipulating the devfreq sysfs nodes like min/max_freq
and
governor even after devfreq is suspended. Moreover, mere suspending
devfreq
cannot synchroinze a clock scaling which has already been invoked
through
these sysfs nodes. Add one more flag in struct clk_scaling and wrap the
entire func ufshcd_devfreq_scale() with the clk_scaling_lock, so that
we
can use this flag and clk_scaling_lock to control and synchronize clock
scaling invoked through devfreq sysfs nodes.
Signed-off-by: Can Guo
---
drivers/scsi/ufs/ufshcd.c | 87
++-
drivers/scsi/ufs/ufshcd.h | 6 +++-
2 files changed, 60 insertions(+), 33 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 0c148fc..44cbee1 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1147,19 +1147,33 @@ static int ufshcd_clock_scaling_prepare(struct
ufs_hba *hba)
*/
ufshcd_scsi_block_requests(hba);
down_write(>clk_scaling_lock);
- if (ufshcd_wait_for_doorbell_clr(hba, DOORBELL_CLR_TOUT_US)) {
+
+ if (!hba->clk_scaling.is_allowed)
+ ret = -EAGAIN;
+ else if (ufshcd_wait_for_doorbell_clr(hba, DOORBELL_CLR_TOUT_US))
ret = -EBUSY;
+
+ if (ret) {
up_write(>clk_scaling_lock);
ufshcd_scsi_unblock_requests(hba);
+ goto out;
}
+ /* let's not get into low power until clock scaling is completed */
+ ufshcd_hold(hba, false);
+
+out:
return ret;
}
-static void ufshcd_clock_scaling_unprepare(struct ufs_hba *hba)
+static void ufshcd_clock_scaling_unprepare(struct ufs_hba *hba, bool
writelock)
{
- up_write(>clk_scaling_lock);
+ if (writelock)
+ up_write(>clk_scaling_lock);
+ else
+ up_read(>clk_scaling_lock);
ufshcd_scsi_unblock_requests(hba);
+ ufshcd_release(hba);
}
/**
@@ -1174,13 +1188,11 @@ static void
ufshcd_clock_scaling_unprepare(struct ufs_hba *hba)
static int ufshcd_devfreq_scale(struct ufs_hba *hba, bool scale_up)
{
int ret = 0;
-
- /* let's not get into low power until clock scaling is completed */
- ufshcd_hold(hba, false);
+ bool is_writelock = true;
ret = ufshcd_clock_scaling_prepare(hba);
if (ret)
- goto out;
+ return ret;
/* scale down the gear before scaling down clocks */
if (!scale_up) {
@@ -1206,14 +1218,12 @@ static int ufshcd_devfreq_scale(struct ufs_hba
*hba, bool scale_up)
}
/* Enable Write Booster if we have scaled up else disable it */
- up_write(>clk_scaling_lock);
+ downgrade_write(>clk_scaling_lock);
+ is_writelock = false;
ufshcd_wb_ctrl(hba, scale_up);
- down_write(>clk_scaling_lock);
out_unprepare:
- ufshcd_clock_scaling_unprepare(hba);
-out:
- ufshcd_release(hba);
+ ufshcd_clock_scaling_unprepare(hba, is_writelock);
return ret;
}
@@ -1487,7 +1497,7 @@ static ssize_t
ufshcd_clkscale_enable_show(struct device *dev,
{
struct ufs_hba *hba = dev_get_drvdata(dev);
- return snprintf(buf, PAGE_SIZE, "%d\n", hba->clk_scaling.is_allowed);
+ return snprintf(buf, PAGE_SIZE, "%d\n", hba->clk_scaling.is_enabled);
}
static ssize_t ufshcd_clkscale_enable_store(struct device *dev,
@@ -1501,7 +1511,7 @@ static ssize_t
ufshcd_clkscale_enable_store(struct device *dev,
return -EINVAL;
value = !!value;
- if (value == hba->clk_scaling.is_allowed)
+ if (value == hba->clk_scaling.is_enabled)
goto out;
pm_runtime_get_sync(hba->dev);
@@ -1510,7 +1520,7 @@ static ssize_t
ufshcd_clkscale_enable_store(struct device *dev,
cancel_work_sync(>clk_scaling.suspend_work);
cancel_work_sync(>clk_scaling.resume_work);
- hba->clk_scaling.is_allowed = value;
+ hba->clk_scaling.is_enabled = value;
if (value) {
ufshcd_resume_clkscaling(hba);
@@ -1845,8 +1855,6 @@ static void ufshcd_init_clk_scaling(struct
ufs_hba *hba)
snprintf(wq_name, sizeof(wq_name),
Re: [PATCH] ocfs2: Remove redundant conditional before iput
On 12/31/20 12:05 PM, Yi Li wrote: > iput handles NULL pointers gracefully, so there's no need to > check the pointer before the call. > > Signed-off-by: Yi Li Acked-by: Joseph Qi > --- > fs/ocfs2/super.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/fs/ocfs2/super.c b/fs/ocfs2/super.c > index 2febc76e9de7..079f8826993e 100644 > --- a/fs/ocfs2/super.c > +++ b/fs/ocfs2/super.c > @@ -973,8 +973,6 @@ static void ocfs2_disable_quotas(struct ocfs2_super *osb) >* quota files */ > dquot_disable(sb, type, DQUOT_USAGE_ENABLED | > DQUOT_LIMITS_ENABLED); > - if (!inode) > - continue; > iput(inode); > } > } >
[PATCH 2/2] scsi: ufs: Protect PM ops and err_handler from user access through sysfs
User layer may access sysfs nodes when system PM ops or error handling
is running, which can cause various problems. Rename eh_sem to host_sem
and use it to protect PM ops and error handling from user layer intervene.
Signed-off-by: Can Guo
diff --git a/drivers/scsi/ufs/ufs-sysfs.c b/drivers/scsi/ufs/ufs-sysfs.c
index 08e72b7..1828b34 100644
--- a/drivers/scsi/ufs/ufs-sysfs.c
+++ b/drivers/scsi/ufs/ufs-sysfs.c
@@ -154,18 +154,29 @@ static ssize_t auto_hibern8_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
u32 ahit;
+ int ret;
struct ufs_hba *hba = dev_get_drvdata(dev);
if (!ufshcd_is_auto_hibern8_supported(hba))
return -EOPNOTSUPP;
+ down(>host_sem);
+ if (hba->shutting_down) {
+ ret = -EBUSY;
+ goto out;
+ }
+
pm_runtime_get_sync(hba->dev);
ufshcd_hold(hba, false);
ahit = ufshcd_readl(hba, REG_AUTO_HIBERNATE_IDLE_TIMER);
ufshcd_release(hba);
pm_runtime_put_sync(hba->dev);
- return scnprintf(buf, PAGE_SIZE, "%d\n", ufshcd_ahit_to_us(ahit));
+ ret = scnprintf(buf, PAGE_SIZE, "%d\n", ufshcd_ahit_to_us(ahit));
+
+out:
+ up(>host_sem);
+ return ret;
}
static ssize_t auto_hibern8_store(struct device *dev,
@@ -174,6 +185,7 @@ static ssize_t auto_hibern8_store(struct device *dev,
{
struct ufs_hba *hba = dev_get_drvdata(dev);
unsigned int timer;
+ int ret = 0;
if (!ufshcd_is_auto_hibern8_supported(hba))
return -EOPNOTSUPP;
@@ -184,9 +196,17 @@ static ssize_t auto_hibern8_store(struct device *dev,
if (timer > UFSHCI_AHIBERN8_MAX)
return -EINVAL;
+ down(>host_sem);
+ if (hba->shutting_down) {
+ ret = -EBUSY;
+ goto out;
+ }
+
ufshcd_auto_hibern8_update(hba, ufshcd_us_to_ahit(timer));
- return count;
+out:
+ up(>host_sem);
+ return ret ? ret : count;
}
static DEVICE_ATTR_RW(rpm_lvl);
@@ -225,12 +245,21 @@ static ssize_t ufs_sysfs_read_desc_param(struct ufs_hba
*hba,
if (param_size > 8)
return -EINVAL;
+ down(>host_sem);
+ if (hba->shutting_down) {
+ ret = -EBUSY;
+ goto out;
+ }
+
pm_runtime_get_sync(hba->dev);
ret = ufshcd_read_desc_param(hba, desc_id, desc_index,
param_offset, desc_buf, param_size);
pm_runtime_put_sync(hba->dev);
- if (ret)
- return -EINVAL;
+ if (ret) {
+ ret = -EINVAL;
+ goto out;
+ }
+
switch (param_size) {
case 1:
ret = sprintf(sysfs_buf, "0x%02X\n", *desc_buf);
@@ -249,6 +278,8 @@ static ssize_t ufs_sysfs_read_desc_param(struct ufs_hba
*hba,
break;
}
+out:
+ up(>host_sem);
return ret;
}
@@ -591,9 +622,16 @@ static ssize_t _name##_show(struct device *dev,
\
int desc_len = QUERY_DESC_MAX_SIZE; \
u8 *desc_buf; \
\
+ down(>host_sem); \
+ if (hba->shutting_down) { \
+ up(>host_sem); \
+ return -EBUSY; \
+ } \
desc_buf = kzalloc(QUERY_DESC_MAX_SIZE, GFP_ATOMIC);\
- if (!desc_buf) \
- return -ENOMEM; \
+ if (!desc_buf) {\
+ up(>host_sem); \
+ return -ENOMEM; \
+ } \
pm_runtime_get_sync(hba->dev); \
ret = ufshcd_query_descriptor_retry(hba,\
UPIU_QUERY_OPCODE_READ_DESC, QUERY_DESC_IDN_DEVICE, \
@@ -613,6 +651,7 @@ static ssize_t _name##_show(struct device *dev,
\
out: \
pm_runtime_put_sync(hba->dev); \
kfree(desc_buf);\
+ up(>host_sem); \
return ret; \
} \
static DEVICE_ATTR_RO(_name)
@@ -651,15 +690,26 @@ static
[PATCH 1/2] scsi: ufs: Fix a possible NULL pointer issue
During system resume/suspend, hba could be NULL. In this case, do not touch
eh_sem.
Fixes: 88a92d6ae4fe ("scsi: ufs: Serialize eh_work with system PM events and
async scan")
Signed-off-by: Can Guo
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index e221add..34e2541 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -8896,8 +8896,11 @@ int ufshcd_system_suspend(struct ufs_hba *hba)
int ret = 0;
ktime_t start = ktime_get();
+ if (!hba)
+ return 0;
+
down(>eh_sem);
- if (!hba || !hba->is_powered)
+ if (!hba->is_powered)
return 0;
if ((ufs_get_pm_lvl_to_dev_pwr_mode(hba->spm_lvl) ==
@@ -8945,10 +8948,8 @@ int ufshcd_system_resume(struct ufs_hba *hba)
int ret = 0;
ktime_t start = ktime_get();
- if (!hba) {
- up(>eh_sem);
+ if (!hba)
return -EINVAL;
- }
if (!hba->is_powered || pm_runtime_suspended(hba->dev))
/*
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project.
Re: Time to re-enable Runtime PM per default for PCI devcies?
On Wed, Dec 30, 2020 at 11:56:04PM +0100, Heiner Kallweit wrote: > --- a/drivers/pci/pci.c > +++ b/drivers/pci/pci.c > @@ -3024,7 +3024,9 @@ void pci_pm_init(struct pci_dev *dev) > u16 status; > u16 pmc; > > - pm_runtime_forbid(>dev); > + if (pci_acpi_forbid_runtime_pm()) > + pm_runtime_forbid(>dev); > + Generic PCI code usually does not call ACPI-specific functions directly, but rather through a pci_platform_pm_ops callback. FWIW, if platform_pci_power_manageable() returns true, it can probably be assumed that allowing runtime PM by default is okay. So as a first step, you may want to call that instead of adding a new callback. Thanks, Lukas
[PATCH] ocfs2: Remove redundant conditional before iput
iput handles NULL pointers gracefully, so there's no need to check the pointer before the call. Signed-off-by: Yi Li --- fs/ocfs2/super.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/fs/ocfs2/super.c b/fs/ocfs2/super.c index 2febc76e9de7..079f8826993e 100644 --- a/fs/ocfs2/super.c +++ b/fs/ocfs2/super.c @@ -973,8 +973,6 @@ static void ocfs2_disable_quotas(struct ocfs2_super *osb) * quota files */ dquot_disable(sb, type, DQUOT_USAGE_ENABLED | DQUOT_LIMITS_ENABLED); - if (!inode) - continue; iput(inode); } } -- 2.25.3
include/linux/compiler_types.h:338:38: error: call to '__compiletime_assert_513' declared with attribute error: BUILD_BUG_ON failed: sizeof(cmd_a64_entry_t) != 64
Hi Will, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: f6e1ea19649216156576aeafa784e3b4cee45549 commit: eb5c2d4b45e3d2d5d052ea6b8f1463976b1020d5 compiler.h: Move compiletime_assert() macros into compiler_types.h date: 5 months ago config: arm-randconfig-r006-20201231 (attached as .config) compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eb5c2d4b45e3d2d5d052ea6b8f1463976b1020d5 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout eb5c2d4b45e3d2d5d052ea6b8f1463976b1020d5 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): In file included from : drivers/scsi/qla2xxx/qla_os.c: In function 'qla2x00_module_init': >> include/linux/compiler_types.h:338:38: error: call to >> '__compiletime_assert_513' declared with attribute error: BUILD_BUG_ON >> failed: sizeof(cmd_a64_entry_t) != 64 338 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | ^ include/linux/compiler_types.h:319:4: note: in definition of macro '__compiletime_assert' 319 |prefix ## suffix();\ |^~ include/linux/compiler_types.h:338:2: note: in expansion of macro '_compiletime_assert' 338 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | ^~~ include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) | ^~ include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' 50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) | ^~~~ drivers/scsi/qla2xxx/qla_os.c:7825:2: note: in expansion of macro 'BUILD_BUG_ON' 7825 | BUILD_BUG_ON(sizeof(cmd_a64_entry_t) != 64); | ^~~~ >> include/linux/compiler_types.h:338:38: error: call to >> '__compiletime_assert_514' declared with attribute error: BUILD_BUG_ON >> failed: sizeof(cmd_entry_t) != 64 338 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | ^ include/linux/compiler_types.h:319:4: note: in definition of macro '__compiletime_assert' 319 |prefix ## suffix();\ |^~ include/linux/compiler_types.h:338:2: note: in expansion of macro '_compiletime_assert' 338 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | ^~~ include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) | ^~ include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' 50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) | ^~~~ drivers/scsi/qla2xxx/qla_os.c:7826:2: note: in expansion of macro 'BUILD_BUG_ON' 7826 | BUILD_BUG_ON(sizeof(cmd_entry_t) != 64); | ^~~~ >> include/linux/compiler_types.h:338:38: error: call to >> '__compiletime_assert_518' declared with attribute error: BUILD_BUG_ON >> failed: sizeof(mrk_entry_t) != 64 338 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | ^ include/linux/compiler_types.h:319:4: note: in definition of macro '__compiletime_assert' 319 |prefix ## suffix();\ |^~ include/linux/compiler_types.h:338:2: note: in expansion of macro '_compiletime_assert' 338 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | ^~~ include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) | ^~ include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' 50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) | ^~~~ drivers/scsi/qla2xxx/qla_os.c:7830:2: note: in expansion of macro 'BUILD_BUG_ON' 7830 |
Re: [PATCH V2 00/19] vDPA driver for virtio-pci device
On 2020/12/4 下午12:03, Jason Wang wrote: Hi all: This series tries to implement a vDPA driver for virtio-pci device which will bridge between vDPA bus and virtio-pci device. This could be used for future feature prototyping and testing. Please review Changes from V2: - don't try to use devres for virtio-pci core - tweak the commit log - split the patches furtherly to ease the reviewing Changes from V1: - Split common codes from virito-pci and share it with vDPA driver - Use dynamic id in order to be less confusing with virtio-pci driver - No feature whitelist, supporting any features (mq, config etc) Thanks Michael, any comment for this series? It's needed for testing doorbell mapping and config interrupt support. Thanks
Re: [PATCH 2/2] spi: fix the divide by 0 error when calculating xfer waiting time
On Wed, Dec 30, 2020 at 01:46:44PM +, Mark Brown wrote: > On Wed, Dec 30, 2020 at 10:24:20AM +0800, Xu Yilun wrote: > > On Tue, Dec 29, 2020 at 01:13:08PM +, Mark Brown wrote: > > > > Does this still apply with current code? There have been some fixes in > > > this area which I think should ensure that we don't turn the speed down > > > to 0 if the controller doesn't supply a limit IIRC. > > > Yes, there is chance the speed is set to 0, some related code from 5.11-rc1 > > Please check the code in the SPI tree and -next. I see the fix patches in maillist, thanks. > > > BTW, Could we keep the spi->max_speed_hz if no controller->max_speed_hz? > > Always clamp the spi->max_speed_hz to 0 makes no sense. > > Right, that's the fix. Seems it still doesn't fix the case that neither controller nor client dev provides the non-zero max_speed_hz. Do you think the patch is still necessary? Thanks, Yilun
[PATCH] PCI:tegra:Correct typo for PCIe endpoint mode in Tegra194
In config PCIE_TEGRA194_EP the mode incorrectly referred to host mode. Signed-off-by: Wesley Sheng --- drivers/pci/controller/dwc/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig index 044a3761c44f..6960babe6161 100644 --- a/drivers/pci/controller/dwc/Kconfig +++ b/drivers/pci/controller/dwc/Kconfig @@ -273,7 +273,7 @@ config PCIE_TEGRA194_EP select PCIE_TEGRA194 help Enables support for the PCIe controller in the NVIDIA Tegra194 SoC to - work in host mode. There are two instances of PCIe controllers in + work in endpoint mode. There are two instances of PCIe controllers in Tegra194. This controller can work either as EP or RC. In order to enable host-specific features PCIE_TEGRA194_HOST must be selected and in order to enable device-specific features PCIE_TEGRA194_EP must be -- 2.16.2
Re: [PATCH] ASoC: mediatek: add MTK_PMIC_WRAP dependency
On Wed, Dec 30, 2020 at 11:43 PM Arnd Bergmann wrote: > > From: Arnd Bergmann > > Randconfig builds often show harmless warnings like > > WARNING: unmet direct dependencies detected for SND_SOC_MT6359 > Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && > MTK_PMIC_WRAP [=n] > Selected by [y]: > - SND_SOC_MT8192_MT6359_RT1015_RT5682 [=y] && SOUND [=y] && !UML && SND > [=y] && SND_SOC [=y] && I2C [=y] && SND_SOC_MT8192 [=y] > > Add a dependency to avoid that. > > Signed-off-by: Arnd Bergmann Acked-by: Tzung-Bi Shih
[PATCH net-next v2] net: nfc: nci: Change the NCI close sequence
From: Bongsu Jeon If there is a NCI command in work queue after closing the NCI device at nci_unregister_device, The NCI command timer starts at flush_workqueue function and then NCI command timeout handler would be called 5 second after flushing the NCI command work queue and destroying the queue. At that time, the timeout handler would try to use NCI command work queue that is destroyed already. it will causes the problem. To avoid this abnormal situation, change the sequence to prevent the NCI command timeout handler from being called after destroying the NCI command work queue. Signed-off-by: Bongsu Jeon --- Changes in v2: - Change the commit message. net/nfc/nci/core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c index e64727e1a72f..79bebf4b0796 100644 --- a/net/nfc/nci/core.c +++ b/net/nfc/nci/core.c @@ -579,11 +579,11 @@ static int nci_close_device(struct nci_dev *ndev) clear_bit(NCI_INIT, >flags); - del_timer_sync(>cmd_timer); - /* Flush cmd wq */ flush_workqueue(ndev->cmd_wq); + del_timer_sync(>cmd_timer); + /* Clear flags */ ndev->flags = 0; -- 2.17.1
Re: [PATCH v2 2/2] arm64: dts: meson: add initial Beelink GS-King-X device-tree
> On 31 Dec 2020, at 4:23 am, Martin Blumenstingl > wrote: > > On Wed, Dec 30, 2020 at 11:38 AM Christian Hewitt > wrote: >> >> The Shenzen AZW (Beelink) GS-King-X is based on the Amlogic W400 reference >> board with an S922X-H chip. >> >> - 4GB LPDDR4 RAM >> - 64GB eMMC storage >> - 10/100/1000 Base-T Ethernet >> - AP6356S Wireless (802.11 a/b/g/n/ac, BT 4.1) >> - HDMI 2.1 video >> - S/PDIF optical output > are you planning to enable this also? I plan to add this later (after v1 comments). >> - 2x ESS9018 audio DACs >> - 4x Ricor RT6862 audio amps >> - Analogue headphone output > there's no driver for that DAC so I think that's why you are not enabling them ESS9018 is used with some Raspberry Pi DAC boards so there may be some prior art to build upon. However it’s not clear (even with schematics) how the DAC and AMP are controlled (they look like dumb input/output devices) so this is still to be explored. >> - 1x USB 2.0 OTG port >> - 3x USB 3.0 ports >> - IR receiver >> - 1x micro SD card slot (internal) >> - USB SATA controller with 2x 3.5" drive bays >> - 1x Power on/off button >> >> Signed-off-by: Christian Hewitt > I don't know/have this board but also I don't see anything problematic so: > Acked-by: Martin Blumenstingl Thx!
Re: [PATCH v4 0/3] add custom hinge sensor support
On Wed, Dec 30, 2020 at 12:05:17PM +, Jonathan Cameron wrote: > On Tue, 15 Dec 2020 13:44:41 +0800 > Ye Xiang wrote: > > > Here we register one iio device with three channels which present angle for > > hinge, keyboard and screen. > > > > This driver works on devices with Intel integrated sensor hub, where > > hinge sensor is presented using a custom sensor usage id. > > > > Here the angle is presented in degrees, which is converted to radians. > > Other than those minor bits I'm happy to fix up in patch 2, this looks > good to me. However, I'll need a Jiri Ack for the hid parts before > I apply it. We are are early in this cycle, so no great rush given > the usual xmas slow down! Ok, let's wait Jiri to review the hid parts. Thanks for the help. Thanks Ye Xiang > > > > > Changes since v3: > > - hid-sensor-custom: remove sensor_inst::custom_pdev_exposed. > > - hid-sensor-custom: use static buf, w_buf to avoid using goto in > > get_known_custom_sensor_index. > > - hid-sensor-custom-intel-hinge: use devm_ prefix function instead. > > - sysfs-bus-iio: put in_anglY_raw together with in_angl_raw. > > > > Changes since v2: > > - use 1 iio device instead of 3 for hinge sensor. > > - use indexed channel instead of modified channel and added channel > > labels. > > - remove 2,3 patch in last version, add a document patch to describe the > > hinge channels. > > - hid-sensor-custom: use meaningful return value in > > get_known_custom_sensor_index and checked in call side. > > - hid-sensor-ids.h: use HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE(x) to > > define custom sensor value. > > > > Changes since v1: > > - fixed errors reported by lkp > > > > Ye Xiang (3): > > HID: hid-sensor-custom: Add custom sensor iio support > > iio: hid-sensors: Add hinge sensor driver > > iio:Documentation: Add documentation for hinge sensor channels > > > > Documentation/ABI/testing/sysfs-bus-iio | 11 + > > drivers/hid/hid-sensor-custom.c | 143 +++ > > .../hid-sensors/hid-sensor-attributes.c | 2 + > > drivers/iio/position/Kconfig | 16 + > > drivers/iio/position/Makefile | 1 + > > .../position/hid-sensor-custom-intel-hinge.c | 391 ++ > > include/linux/hid-sensor-ids.h| 14 + > > 7 files changed, 578 insertions(+) > > create mode 100644 drivers/iio/position/hid-sensor-custom-intel-hinge.c > > >
Re: fs/f2fs/gc.c:622:12: warning: stack frame size of 3056 bytes in function 'get_victim_by_default'
Hello,
I tried -Wframe-larger-than=512 in x86_64, and only below two functions
exceed the frame size threshold, will check powerpc64 later.
namei.c: In function ‘f2fs_update_extension_list’:
namei.c:276:1: warning: the frame size of 560 bytes is larger than 512 bytes
[-Wframe-larger-than=]
node.c: In function ‘f2fs_destroy_node_manager’:
node.c:3271:1: warning: the frame size of 792 bytes is larger than 512 bytes
[-Wframe-larger-than=]
Does this issue only occur in powerpc64? do you have results in other archs?
On 2020/12/30 2:45, kernel test robot wrote:
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: dea8dcf2a9fa8cc540136a6cd885c3beece16ec3
commit: 093749e296e29a4b0162eb925a6701a01e8c9a98 f2fs: support age threshold
based garbage collection
date: 4 months ago
config: powerpc64-randconfig-r023-20201221 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
cee1e7d14f4628d6174b33640d502bff3b54ae45)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc64 cross compiling tool for clang build
# apt-get install binutils-powerpc64-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=093749e296e29a4b0162eb925a6701a01e8c9a98
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 093749e296e29a4b0162eb925a6701a01e8c9a98
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross
ARCH=powerpc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
fs/f2fs/gc.c:622:12: warning: stack frame size of 3056 bytes in function
'get_victim_by_default' [-Wframe-larger-than=]
static int get_victim_by_default(struct f2fs_sb_info *sbi,
^
1 warning generated.
vim +/get_victim_by_default +622 fs/f2fs/gc.c
093749e296e29a4 Chao Yu 2020-08-04 613
0a8165d7c2cf139 Jaegeuk Kim 2012-11-29 614 /*
111d2495a8a8fbd Masanari Iida 2013-03-19 615 * This function is called from
two paths.
7bc0900347e069a Jaegeuk Kim 2012-11-02 616 * One is garbage collection and
the other is SSR segment selection.
7bc0900347e069a Jaegeuk Kim 2012-11-02 617 * When it is called during GC,
it just gets a victim segment
7bc0900347e069a Jaegeuk Kim 2012-11-02 618 * and it does not remove it
from dirty seglist.
7bc0900347e069a Jaegeuk Kim 2012-11-02 619 * When it is called from SSR
segment selection, it finds a segment
7bc0900347e069a Jaegeuk Kim 2012-11-02 620 * which has minimum valid
blocks and removes it from dirty seglist.
7bc0900347e069a Jaegeuk Kim 2012-11-02 621 */
7bc0900347e069a Jaegeuk Kim 2012-11-02 @622 static int
get_victim_by_default(struct f2fs_sb_info *sbi,
093749e296e29a4 Chao Yu 2020-08-04 623 unsigned int
*result, int gc_type, int type,
093749e296e29a4 Chao Yu 2020-08-04 624 char
alloc_mode, unsigned long long age)
7bc0900347e069a Jaegeuk Kim 2012-11-02 625 {
7bc0900347e069a Jaegeuk Kim 2012-11-02 626 struct dirty_seglist_info
*dirty_i = DIRTY_I(sbi);
e066b83c9b40f3a Jaegeuk Kim 2017-04-13 627 struct sit_info *sm =
SIT_I(sbi);
7bc0900347e069a Jaegeuk Kim 2012-11-02 628 struct victim_sel_policy p;
3fa565039e3338f Sheng Yong2016-09-29 629 unsigned int secno, last_victim;
04f0b2eaa3b3ee2 Qiuyang Sun 2019-06-05 630 unsigned int last_segment;
093749e296e29a4 Chao Yu 2020-08-04 631 unsigned int nsearched;
093749e296e29a4 Chao Yu 2020-08-04 632 bool is_atgc;
97767500781fae9 Qilong Zhang 2020-06-28 633 int ret = 0;
7bc0900347e069a Jaegeuk Kim 2012-11-02 634
210f41bc048263d Chao Yu 2014-09-15 635
mutex_lock(_i->seglist_lock);
04f0b2eaa3b3ee2 Qiuyang Sun 2019-06-05 636 last_segment = MAIN_SECS(sbi) *
sbi->segs_per_sec;
210f41bc048263d Chao Yu 2014-09-15 637
7bc0900347e069a Jaegeuk Kim 2012-11-02 638 p.alloc_mode = alloc_mode;
093749e296e29a4 Chao Yu 2020-08-04 639 p.age = age;
093749e296e29a4 Chao Yu 2020-08-04 640 p.age_threshold =
sbi->am.age_threshold;
7bc0900347e069a Jaegeuk Kim 2012-11-02 641
093749e296e29a4 Chao Yu 2020-08-04 642 retry:
093749e296e29a4 Chao Yu 2020-08-04 643 select_policy(sbi, gc_type, type,
);
7bc0900347e069a Jaegeuk Kim 2012-11-02 644 p.min_segno = NULL_SEGNO;
093749e296e29a4 Chao Yu 2020-08-04 645 p.oldest_age = 0;
3fa565039e3338f Sheng Yong2016-09-29 646 p.min_cost = get_max_cost(sbi,
);
7bc0900347e069a Jaegeuk Kim 2012-11-02 647
093749e296e29a4 Chao Yu 2020-08-04 648 is_atgc = (p.gc_mode == GC_AT
Re: [PATCH 12/21] vhost-vdpa: introduce uAPI to get the number of virtqueue groups
On 2020/12/30 下午6:05, Eli Cohen wrote: On Wed, Dec 16, 2020 at 02:48:09PM +0800, Jason Wang wrote: Follows the vDPA support for multiple address spaces, this patch introduce uAPI for the userspace to know the number of virtqueue groups supported by the vDPA device. Signed-off-by: Jason Wang --- drivers/vhost/vdpa.c | 4 include/uapi/linux/vhost.h | 3 +++ 2 files changed, 7 insertions(+) diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c index 060d5b5b7e64..1ba5901b28e7 100644 --- a/drivers/vhost/vdpa.c +++ b/drivers/vhost/vdpa.c @@ -536,6 +536,10 @@ static long vhost_vdpa_unlocked_ioctl(struct file *filep, case VHOST_VDPA_GET_VRING_NUM: r = vhost_vdpa_get_vring_num(v, argp); break; + case VHOST_VDPA_GET_GROUP_NUM: + r = copy_to_user(argp, >vdpa->ngroups, +sizeof(v->vdpa->ngroups)); + break; Is this and other ioctls already supported in qemu? Not yet, the prototype is under development. I test the series with a small and dedicated userspace program. Thanks
[PATCH v2 2/2] drm/bridge: anx7625: add MIPI DPI input feature support
Add MIPI rx DPI input support
Signed-off-by: Xin Ji
Reported-by: kernel test robot
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 344 --
drivers/gpu/drm/bridge/analogix/anx7625.h | 24 ++-
2 files changed, 348 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 65cc059..372b356 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -164,6 +164,20 @@ static int anx7625_write_and_or(struct anx7625_data *ctx,
offset, (val & and_mask) | (or_mask));
}
+static int anx7625_config_bit_matrix(struct anx7625_data *ctx)
+{
+ int i, ret;
+
+ ret = anx7625_reg_write(ctx, ctx->i2c.tx_p2_client,
+ AUDIO_CONTROL_REGISTER, 0x80);
+ for (i = 0; i < 13; i++)
+ ret |= anx7625_reg_write(ctx, ctx->i2c.tx_p2_client,
+VIDEO_BIT_MATRIX_12 + i,
+0x18 + i);
+
+ return ret;
+}
+
static int anx7625_read_ctrl_status_p0(struct anx7625_data *ctx)
{
return anx7625_reg_read(ctx, ctx->i2c.rx_p0_client, AP_AUX_CTRL_STATUS);
@@ -189,10 +203,64 @@ static int wait_aux_op_finish(struct anx7625_data *ctx)
AP_AUX_CTRL_STATUS);
if (val < 0 || (val & 0x0F)) {
DRM_DEV_ERROR(dev, "aux status %02x\n", val);
- val = -EIO;
+ return -EIO;
}
- return val;
+ return 0;
+}
+
+static int anx7625_aux_dpcd_read(struct anx7625_data *ctx,
+u8 addrh, u8 addrm, u8 addrl,
+u8 len, u8 *buf)
+{
+ struct device *dev = >client->dev;
+ int ret;
+ u8 cmd;
+
+ if (len > MAX_DPCD_BUFFER_SIZE) {
+ DRM_DEV_ERROR(dev, "exceed aux buffer len.\n");
+ return -E2BIG;
+ }
+
+ cmd = ((len - 1) << 4) | 0x09;
+
+ /* Set command and length */
+ ret = anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
+ AP_AUX_COMMAND, cmd);
+
+ /* Set aux access address */
+ ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
+AP_AUX_ADDR_7_0, addrl);
+ ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
+AP_AUX_ADDR_15_8, addrm);
+ ret |= anx7625_write_and(ctx, ctx->i2c.rx_p0_client,
+AP_AUX_ADDR_19_16, addrh);
+
+ /* Enable aux access */
+ ret |= anx7625_write_or(ctx, ctx->i2c.rx_p0_client,
+ AP_AUX_CTRL_STATUS, AP_AUX_CTRL_OP_EN);
+
+ if (ret < 0) {
+ DRM_DEV_ERROR(dev, "cannot access aux related register.\n");
+ return -EIO;
+ }
+
+ usleep_range(2000, 2100);
+
+ ret = wait_aux_op_finish(ctx);
+ if (ret) {
+ DRM_DEV_ERROR(dev, "aux IO error: wait aux op finish.\n");
+ return ret;
+ }
+
+ ret = anx7625_reg_block_read(ctx, ctx->i2c.rx_p0_client,
+AP_AUX_BUFF_START, len, buf);
+ if (ret < 0) {
+ DRM_DEV_ERROR(dev, "read dpcd register failed\n");
+ return -EIO;
+ }
+
+ return 0;
}
static int anx7625_video_mute_control(struct anx7625_data *ctx,
@@ -595,6 +663,101 @@ static int anx7625_dsi_config(struct anx7625_data *ctx)
return ret;
}
+static int anx7625_api_dpi_config(struct anx7625_data *ctx)
+{
+ struct device *dev = >client->dev;
+ u16 freq = ctx->dt.pixelclock.min / 1000;
+ int ret;
+
+ /* configure pixel clock */
+ ret = anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
+ PIXEL_CLOCK_L, freq & 0xFF);
+ ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
+PIXEL_CLOCK_H, (freq >> 8));
+
+ /* set DPI mode */
+ /* set to DPI PLL module sel */
+ ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p1_client,
+MIPI_DIGITAL_PLL_9, 0x20);
+ /* power down MIPI */
+ ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p1_client,
+MIPI_LANE_CTRL_10, 0x08);
+ /* enable DPI mode */
+ ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p1_client,
+MIPI_DIGITAL_PLL_18, 0x1C);
+ /* set first edge */
+ ret |= anx7625_reg_write(ctx, ctx->i2c.tx_p2_client,
+VIDEO_CONTROL_0, 0x06);
+ if (ret < 0)
+ DRM_DEV_ERROR(dev, "IO error : dpi phy set failed.\n");
+
+ return ret;
+}
+
+static int anx7625_dpi_config(struct anx7625_data *ctx)
+{
+ struct device *dev = >client->dev;
+ int ret;
+
+ DRM_DEV_DEBUG_DRIVER(dev, "config dpi\n");
+
+ /* DSC disable */
+
[PATCH v2 1/2] dt-bindings: drm/bridge: anx7625: add DPI flag and swing setting
Add DPI flag for distinguish MIPI input signal type, DSI or DPI. Add
swing setting for adjusting DP tx PHY swing
Signed-off-by: Xin Ji
---
.../bindings/display/bridge/analogix,anx7625.yaml | 25 --
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
index 60585a4..4eb0ea3 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
@@ -34,6 +34,16 @@ properties:
description: used for reset chip control, RESET_N pin B7.
maxItems: 1
+ analogix,swing-setting:
+type: uint8-array
+$ref: /schemas/types.yaml#/definitions/uint32-array
+description: an array of swing register setting for DP tx PHY
+
+ analogix,mipi-dpi-in:
+type: int
+$ref: /schemas/types.yaml#/definitions/uint32
+description: indicate the MIPI rx signal type is DPI or DSI
+
ports:
type: object
@@ -49,8 +59,8 @@ properties:
Video port for panel or connector.
required:
-- port@0
-- port@1
+ - port@0
+ - port@1
required:
- compatible
@@ -72,6 +82,17 @@ examples:
reg = <0x58>;
enable-gpios = < 45 GPIO_ACTIVE_HIGH>;
reset-gpios = < 73 GPIO_ACTIVE_HIGH>;
+analogix,swing-setting = <0x00 0x14>, <0x01 0x54>,
+<0x02 0x64>, <0x03 0x74>, <0x04 0x29>,
+<0x05 0x7b>, <0x06 0x77>, <0x07 0x5b>,
+<0x08 0x7f>, <0x0c 0x20>, <0x0d 0x60>,
+<0x10 0x60>, <0x12 0x40>, <0x13 0x60>,
+<0x14 0x14>, <0x15 0x54>, <0x16 0x64>,
+<0x17 0x74>, <0x18 0x29>, <0x19 0x7b>,
+<0x1a 0x77>, <0x1b 0x5b>, <0x1c 0x7f>,
+<0x20 0x20>, <0x21 0x60>, <0x24 0x60>,
+<0x26 0x40>, <0x27 0x60>;
+analogix,mipi-dpi-in = <0>;
ports {
#address-cells = <1>;
--
2.7.4
drivers/pci/controller/dwc/pci-keystone.c:1127:34: warning: unused variable 'ks_pcie_of_match'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f6e1ea19649216156576aeafa784e3b4cee45549
commit: 476b70b4d1adff4465e9ff68021c52858555ac28 PCI: keystone: Enable
compile-testing on !ARM
date: 6 weeks ago
config: x86_64-randconfig-a001-20201231 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
3c0d36f977d9e012b245c796ddc8596ac3af659b)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=476b70b4d1adff4465e9ff68021c52858555ac28
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 476b70b4d1adff4465e9ff68021c52858555ac28
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/pci/controller/dwc/pci-keystone.c:1127:34: warning: unused variable
>> 'ks_pcie_of_match' [-Wunused-const-variable]
static const struct of_device_id ks_pcie_of_match[] = {
^
1 warning generated.
vim +/ks_pcie_of_match +1127 drivers/pci/controller/dwc/pci-keystone.c
18b0415bc802a8b Kishon Vijay Abraham I 2019-03-25 1126
18b0415bc802a8b Kishon Vijay Abraham I 2019-03-25 @1127 static const struct
of_device_id ks_pcie_of_match[] = {
18b0415bc802a8b Kishon Vijay Abraham I 2019-03-25 1128 {
18b0415bc802a8b Kishon Vijay Abraham I 2019-03-25 1129 .type =
"pci",
18b0415bc802a8b Kishon Vijay Abraham I 2019-03-25 1130 .data =
_pcie_rc_of_data,
18b0415bc802a8b Kishon Vijay Abraham I 2019-03-25 1131
.compatible = "ti,keystone-pcie",
18b0415bc802a8b Kishon Vijay Abraham I 2019-03-25 1132 },
18b0415bc802a8b Kishon Vijay Abraham I 2019-03-25 1133 {
18b0415bc802a8b Kishon Vijay Abraham I 2019-03-25 1134 .data =
_pcie_am654_rc_of_data,
18b0415bc802a8b Kishon Vijay Abraham I 2019-03-25 1135
.compatible = "ti,am654-pcie-rc",
18b0415bc802a8b Kishon Vijay Abraham I 2019-03-25 1136 },
23284ad677a94f2 Kishon Vijay Abraham I 2019-03-25 1137 {
23284ad677a94f2 Kishon Vijay Abraham I 2019-03-25 1138 .data =
_pcie_am654_ep_of_data,
23284ad677a94f2 Kishon Vijay Abraham I 2019-03-25 1139
.compatible = "ti,am654-pcie-ep",
23284ad677a94f2 Kishon Vijay Abraham I 2019-03-25 1140 },
18b0415bc802a8b Kishon Vijay Abraham I 2019-03-25 1141 { },
18b0415bc802a8b Kishon Vijay Abraham I 2019-03-25 1142 };
18b0415bc802a8b Kishon Vijay Abraham I 2019-03-25 1143
:: The code at line 1127 was first introduced by commit
:: 18b0415bc802a8bab5dedba5ae2757e83259e6ee PCI: keystone: Add support for
PCIe RC in AM654x Platforms
:: TO: Kishon Vijay Abraham I
:: CC: Lorenzo Pieralisi
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH v2 0/2] Add MIPI rx DPI support
Hi all, this patch series implement MIPI rx DPI feature. Please help to review. This is the v2 version, any mistakes, please let me know, I'll fix it in the next series. Change history: v2: Fix Rob Herring comment - Fix yamllint warnings/errors in analogix,anx7625.yaml - Fix kernel robot compiling warning v1: initial MIPI rx DPI feature support Xin Ji (2): dt-bindings: drm/bridge: anx7625: add DPI flag and swing setting drm/bridge: anx7625: add MIPI DPI input feature support .../bindings/display/bridge/analogix,anx7625.yaml | 25 +- drivers/gpu/drm/bridge/analogix/anx7625.c | 344 +++-- drivers/gpu/drm/bridge/analogix/anx7625.h | 24 +- 3 files changed, 371 insertions(+), 22 deletions(-) -- 2.7.4
Re: [PATCH v10 3/7] [v10, 3/7]: soc: mediatek: SVS: introduce MTK SVS engine
On Sun, Dec 27, 2020 at 6:55 PM Roger Lu wrote:
>
> The Smart Voltage Scaling(SVS) engine is a piece of hardware
> which calculats suitable SVS bank voltages to OPP voltage table.
calculates
> Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
> when receiving OPP_EVENT_ADJUST_VOLTAGE.
>
> Signed-off-by: Roger Lu
> ---
> drivers/soc/mediatek/Kconfig | 10 +
> drivers/soc/mediatek/Makefile |1 +
> drivers/soc/mediatek/mtk-svs.c | 1748
> 3 files changed, 1759 insertions(+)
> create mode 100644 drivers/soc/mediatek/mtk-svs.c
>
> diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
> index 59a56cd790ec..f33da25f8336 100644
> --- a/drivers/soc/mediatek/Kconfig
> +++ b/drivers/soc/mediatek/Kconfig
> @@ -51,4 +51,14 @@ config MTK_MMSYS
> Say yes here to add support for the MediaTek Multimedia
> Subsystem (MMSYS).
>
> +config MTK_SVS
> + tristate "MediaTek Smart Voltage Scaling(SVS)"
> + depends on MTK_EFUSE && NVMEM
> + help
> + The Smart Voltage Scaling(SVS) engine is a piece of hardware
> + which has several controllers(banks) for calculating suitable
> + voltage to different power domains(CPU/GPU/CCI) according to
> + chip process corner, temperatures and other factors. Then DVFS
> + driver could apply SVS bank voltage to PMIC/Buck.
> +
> endmenu
> diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
> index 01f9f873634a..e10f2cd87514 100644
> --- a/drivers/soc/mediatek/Makefile
> +++ b/drivers/soc/mediatek/Makefile
> @@ -4,3 +4,4 @@ obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
> obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
> obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
> obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o
> +obj-$(CONFIG_MTK_SVS) += mtk-svs.o
> diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
> new file mode 100644
> index ..0efefb48839d
> --- /dev/null
> +++ b/drivers/soc/mediatek/mtk-svs.c
> @@ -0,0 +1,1748 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2020 MediaTek Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* svs bank 1-line sw id */
> +#define SVSB_CPU_LITTLEBIT(0)
> +#define SVSB_CPU_BIG BIT(1)
> +#define SVSB_CCI BIT(2)
> +#define SVSB_GPU BIT(3)
> +
> +/* svs bank mode support */
> +#define SVSB_MODE_ALL_DISABLE 0
> +#define SVSB_MODE_INIT01 BIT(1)
> +#define SVSB_MODE_INIT02 BIT(2)
> +#define SVSB_MODE_MON BIT(3)
> +
> +/* svs bank init01 condition */
> +#define SVSB_INIT01_VOLT_IGNOREBIT(1)
> +#define SVSB_INIT01_VOLT_INC_ONLY BIT(2)
> +#define SVSB_INIT01_CLK_EN BIT(31)
> +
> +/* svs bank common setting */
> +#define SVSB_TZONE_HIGH_TEMP_MAX U32_MAX
> +#define SVSB_RUNCONFIG_DEFAULT 0x8000
> +#define SVSB_DC_SIGNED_BIT 0x8000
> +#define SVSB_INTEN_INIT0x 0x5f01
> +#define SVSB_INTEN_MONVOPEN0x00ff
> +#define SVSB_EN_OFF0x0
> +#define SVSB_EN_MASK 0x7
> +#define SVSB_EN_INIT01 0x1
> +#define SVSB_EN_INIT02 0x5
> +#define SVSB_EN_MON0x2
> +#define SVSB_INTSTS_MONVOP 0x00ff
> +#define SVSB_INTSTS_COMPLETE 0x1
> +#define SVSB_INTSTS_CLEAN 0x00ff
> +
> +static DEFINE_SPINLOCK(mtk_svs_lock);
> +
> +/*
> + * enum svsb_phase - svs bank phase enumeration
> + * @SVSB_PHASE_INIT01: basic init for svs bank
> + * @SVSB_PHASE_INIT02: svs bank can provide voltages
> + * @SVSB_PHASE_MON: svs bank can provide voltages with thermal effect
> + * @SVSB_PHASE_ERROR: svs bank encouters unexpected condition
encounters
> + *
> + * Each svs bank has its own independent phase. We enable each svs bank by
> + * running their phase orderly. However, When svs bank ecnounters unexpected
encounters
> + * condition, it will fire an irq (PHASE_ERROR) to inform svs software.
> + *
> + * svs bank general phase-enabled order:
> + * SVSB_PHASE_INIT01 -> SVSB_PHASE_INIT02 -> SVSB_PHASE_MON
> + */
> +enum svsb_phase {
> + SVSB_PHASE_INIT01 = 0,
> + SVSB_PHASE_INIT02,
> + SVSB_PHASE_MON,
> + SVSB_PHASE_ERROR,
> +};
> +
> +enum svs_reg_index {
> + DESCHAR = 0,
> + TEMPCHAR,
> + DETCHAR,
> + AGECHAR,
> + DCCONFIG,
> + AGECONFIG,
> + FREQPCT30,
> + FREQPCT74,
> + LIMITVALS,
> + VBOOT,
> + DETWINDOW,
> + CONFIG,
> + TSCALCS,
> +
Re: [PATCH] pinctrl: nomadik: remove an unused variable
On Wed, Dec 30, 2020 at 04:46:17PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> A recent patch added a local variable twice:
>
> drivers/pinctrl/nomadik/pinctrl-nomadik.c:953:8: error: unused variable
> 'wake' [-Werror,-Wunused-variable]
>
> Remove the unused outer declaration
>
> Fixes: f3925032d7fd ("pinctrl: nomadik: Use irq_has_action()")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/pinctrl/nomadik/pinctrl-nomadik.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/pinctrl/nomadik/pinctrl-nomadik.c
> b/drivers/pinctrl/nomadik/pinctrl-nomadik.c
> index d4ea10803fd9..abfe11c7b49f 100644
> --- a/drivers/pinctrl/nomadik/pinctrl-nomadik.c
> +++ b/drivers/pinctrl/nomadik/pinctrl-nomadik.c
> @@ -949,7 +949,6 @@ static void nmk_gpio_dbg_show_one(struct seq_file *s,
> } else {
> int irq = chip->to_irq(chip, offset);
> const int pullidx = pull ? 1 : 0;
> - bool wake;
> int val;
> static const char * const pulls[] = {
> "none",
> --
> 2.29.2
>
Got rid of the warning for me, I don't have hardware to test on but I
don't think that's necessary for this.
Tested-by: Andrew Halaney
Reviewed-by: Andrew Halaney
Thanks,
Andrew
[PATCH] ext4: Change list_for_each to list_for_each_entry
list_for_each + list_entry can be changed to list_for_each_entry
It reduces number of variables and lines.
Signed-off-by: Daejun Park
---
fs/ext4/fast_commit.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/fs/ext4/fast_commit.c b/fs/ext4/fast_commit.c
index 5b6bb3ef0f33..dc58471971db 100644
--- a/fs/ext4/fast_commit.c
+++ b/fs/ext4/fast_commit.c
@@ -915,13 +915,11 @@ static int ext4_fc_submit_inode_data_all(journal_t
*journal)
struct super_block *sb = (struct super_block *)(journal->j_private);
struct ext4_sb_info *sbi = EXT4_SB(sb);
struct ext4_inode_info *ei;
- struct list_head *pos;
int ret = 0;
spin_lock(>s_fc_lock);
ext4_set_mount_flag(sb, EXT4_MF_FC_COMMITTING);
- list_for_each(pos, >s_fc_q[FC_Q_MAIN]) {
- ei = list_entry(pos, struct ext4_inode_info, i_fc_list);
+ list_for_each_entry(ei, >s_fc_q[FC_Q_MAIN], i_fc_list) {
ext4_set_inode_state(>vfs_inode, EXT4_STATE_FC_COMMITTING);
while (atomic_read(>i_fc_updates)) {
DEFINE_WAIT(wait);
@@ -1099,8 +1097,7 @@ static int ext4_fc_perform_commit(journal_t *journal)
goto out;
}
- list_for_each(pos, >s_fc_q[FC_Q_MAIN]) {
- iter = list_entry(pos, struct ext4_inode_info, i_fc_list);
+ list_for_each_entry(iter, >s_fc_q[FC_Q_MAIN], i_fc_list) {
inode = >vfs_inode;
if (!ext4_test_inode_state(inode, EXT4_STATE_FC_COMMITTING))
continue;
--
2.25.1
Re: [PATCH v3, 1/8] soc: mediatek: mmsys: create mmsys folder
On Mon, Dec 28, 2020 at 4:38 PM Yongqiang Niu wrote: > > the mmsys will more and more complicated after support > more and more SoCs, add an independent folder will be > more clear > > Signed-off-by: Yongqiang Niu > --- > drivers/soc/mediatek/Makefile | 2 +- > drivers/soc/mediatek/mmsys/Makefile| 2 + > drivers/soc/mediatek/mmsys/mtk-mmsys.c | 380 > + > drivers/soc/mediatek/mtk-mmsys.c | 380 > - I wonder why this doesn't get detected as a rename? > 4 files changed, 383 insertions(+), 381 deletions(-) > create mode 100644 drivers/soc/mediatek/mmsys/Makefile > create mode 100644 drivers/soc/mediatek/mmsys/mtk-mmsys.c > delete mode 100644 drivers/soc/mediatek/mtk-mmsys.c > > diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile > index 01f9f87..b5987ca 100644 > --- a/drivers/soc/mediatek/Makefile > +++ b/drivers/soc/mediatek/Makefile > @@ -3,4 +3,4 @@ obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o > obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o > obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o > obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o > -obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o > +obj-$(CONFIG_MTK_MMSYS) += mmsys/ > diff --git a/drivers/soc/mediatek/mmsys/Makefile > b/drivers/soc/mediatek/mmsys/Makefile > new file mode 100644 > index 000..5d976d7 > --- /dev/null > +++ b/drivers/soc/mediatek/mmsys/Makefile > @@ -0,0 +1,2 @@ > +# SPDX-License-Identifier: GPL-2.0-only > +obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o > \ No newline at end of file Nit: newline at end of file please.
[PATCH 4/5] Revert "iommu: Add quirk for Intel graphic devices in map_sg"
This reverts commit 65f746e8285f0a67d43517d86fedb9e29ead49f2.
As commit 8a473dbadccfc ("drm/i915: Fix DMA mapped scatterlist walks") and
commit 934941ed5a307 ("drm/i915: Fix DMA mapped scatterlist lookup") fixed
the DMA scatterlist limitations in the i915 driver, remove this temporary
workaround.
Cc: Tvrtko Ursulin
Cc: Tom Murphy
Cc: Logan Gunthorpe
Signed-off-by: Lu Baolu
---
drivers/iommu/dma-iommu.c | 27 ---
1 file changed, 27 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index f0305e6aac1b..4078358ed66e 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -863,33 +863,6 @@ static int __finalise_sg(struct device *dev, struct
scatterlist *sg, int nents,
unsigned int cur_len = 0, max_len = dma_get_max_seg_size(dev);
int i, count = 0;
- /*
-* The Intel graphic driver is used to assume that the returned
-* sg list is not combound. This blocks the efforts of converting
-* Intel IOMMU driver to dma-iommu api's. Add this quirk to make the
-* device driver work and should be removed once it's fixed in i915
-* driver.
-*/
- if (IS_ENABLED(CONFIG_DRM_I915) && dev_is_pci(dev) &&
- to_pci_dev(dev)->vendor == PCI_VENDOR_ID_INTEL &&
- (to_pci_dev(dev)->class >> 16) == PCI_BASE_CLASS_DISPLAY) {
- for_each_sg(sg, s, nents, i) {
- unsigned int s_iova_off = sg_dma_address(s);
- unsigned int s_length = sg_dma_len(s);
- unsigned int s_iova_len = s->length;
-
- s->offset += s_iova_off;
- s->length = s_length;
- sg_dma_address(s) = dma_addr + s_iova_off;
- sg_dma_len(s) = s_length;
- dma_addr += s_iova_len;
-
- pr_info_once("sg combining disabled due to i915
driver\n");
- }
-
- return nents;
- }
-
for_each_sg(sg, s, nents, i) {
/* Restore this segment's original unaligned fields first */
unsigned int s_iova_off = sg_dma_address(s);
--
2.25.1
[PATCH 5/5] iommu/vt-d: Fix lockdep splat in sva bind()/unbind()
Lock(>lock) without disabling irq causes lockdep warnings.
WARNING: possible irq lock inversion dependency detected
5.11.0-rc1+ #828 Not tainted
kworker/0:1H/120 just changed the state of lock:
ad9ea1b8 (device_domain_lock){..-.}-{2:2}, at:
iommu_flush_dev_iotlb.part.0+0x32/0x120
but this lock took another, SOFTIRQ-unsafe lock in the past:
(>lock){+.+.}-{2:2}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
Possible interrupt unsafe locking scenario:
CPU0CPU1
lock(>lock);
local_irq_disable();
lock(device_domain_lock);
lock(>lock);
lock(device_domain_lock);
*** DEADLOCK ***
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/svm.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index b16a4791acfb..18a9f05df407 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -299,6 +299,7 @@ int intel_svm_bind_gpasid(struct iommu_domain *domain,
struct device *dev,
struct dmar_domain *dmar_domain;
struct device_domain_info *info;
struct intel_svm *svm = NULL;
+ unsigned long iflags;
int ret = 0;
if (WARN_ON(!iommu) || !data)
@@ -400,12 +401,12 @@ int intel_svm_bind_gpasid(struct iommu_domain *domain,
struct device *dev,
* each bind of a new device even with an existing PASID, we need to
* call the nested mode setup function here.
*/
- spin_lock(>lock);
+ spin_lock_irqsave(>lock, iflags);
ret = intel_pasid_setup_nested(iommu, dev,
(pgd_t *)(uintptr_t)data->gpgd,
data->hpasid, >vendor.vtd,
dmar_domain,
data->addr_width);
- spin_unlock(>lock);
+ spin_unlock_irqrestore(>lock, iflags);
if (ret) {
dev_err_ratelimited(dev, "Failed to set up PASID %llu in nested
mode, Err %d\n",
data->hpasid, ret);
@@ -505,6 +506,7 @@ intel_svm_bind_mm(struct device *dev, unsigned int flags,
struct device_domain_info *info;
struct intel_svm_dev *sdev;
struct intel_svm *svm = NULL;
+ unsigned long iflags;
int pasid_max;
int ret;
@@ -624,14 +626,14 @@ intel_svm_bind_mm(struct device *dev, unsigned int flags,
}
}
- spin_lock(>lock);
+ spin_lock_irqsave(>lock, iflags);
ret = intel_pasid_setup_first_level(iommu, dev,
mm ? mm->pgd : init_mm.pgd,
svm->pasid, FLPT_DEFAULT_DID,
(mm ? 0 : PASID_FLAG_SUPERVISOR_MODE) |
(cpu_feature_enabled(X86_FEATURE_LA57) ?
PASID_FLAG_FL5LP : 0));
- spin_unlock(>lock);
+ spin_unlock_irqrestore(>lock, iflags);
if (ret) {
if (mm)
mmu_notifier_unregister(>notifier, mm);
@@ -651,14 +653,14 @@ intel_svm_bind_mm(struct device *dev, unsigned int flags,
* Binding a new device with existing PASID, need to setup
* the PASID entry.
*/
- spin_lock(>lock);
+ spin_lock_irqsave(>lock, iflags);
ret = intel_pasid_setup_first_level(iommu, dev,
mm ? mm->pgd : init_mm.pgd,
svm->pasid, FLPT_DEFAULT_DID,
(mm ? 0 :
PASID_FLAG_SUPERVISOR_MODE) |
(cpu_feature_enabled(X86_FEATURE_LA57) ?
PASID_FLAG_FL5LP : 0));
- spin_unlock(>lock);
+ spin_unlock_irqrestore(>lock, iflags);
if (ret) {
kfree(sdev);
goto out;
--
2.25.1
[PATCH 2/5] iommu/vt-d: Fix unaligned addresses for intel_flush_svm_range_dev()
The VT-d hardware will ignore those Addr bits which have been masked by
the AM field in the PASID-based-IOTLB invalidation descriptor. As the
result, if the starting address in the descriptor is not aligned with
the address mask, some IOTLB caches might not invalidate. Hence people
will see below errors.
[ 1093.704661] dmar_fault: 29 callbacks suppressed
[ 1093.704664] DMAR: DRHD: handling fault status reg 3
[ 1093.712738] DMAR: [DMA Read] Request device [7a:02.0] PASID 2
fault addr 7f81c968d000 [fault reason 113]
SM: Present bit in first-level paging entry is clear
Fix this by using aligned address for PASID-based-IOTLB invalidation.
Fixes: 1c4f88b7f1f92 ("iommu/vt-d: Shared virtual address in scalable mode")
Reported-and-tested-by: Guo Kaijie
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/svm.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index 69566695d032..b16a4791acfb 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -118,8 +118,10 @@ void intel_svm_check(struct intel_iommu *iommu)
iommu->flags |= VTD_FLAG_SVM_CAPABLE;
}
-static void intel_flush_svm_range_dev (struct intel_svm *svm, struct
intel_svm_dev *sdev,
- unsigned long address, unsigned long pages, int
ih)
+static void __flush_svm_range_dev(struct intel_svm *svm,
+ struct intel_svm_dev *sdev,
+ unsigned long address,
+ unsigned long pages, int ih)
{
struct qi_desc desc;
@@ -170,6 +172,22 @@ static void intel_flush_svm_range_dev (struct intel_svm
*svm, struct intel_svm_d
}
}
+static void intel_flush_svm_range_dev(struct intel_svm *svm,
+ struct intel_svm_dev *sdev,
+ unsigned long address,
+ unsigned long pages, int ih)
+{
+ unsigned long shift = ilog2(__roundup_pow_of_two(pages));
+ unsigned long align = (1ULL << (VTD_PAGE_SHIFT + shift));
+ unsigned long start = ALIGN_DOWN(address, align);
+ unsigned long end = ALIGN(address + (pages << VTD_PAGE_SHIFT), align);
+
+ while (start < end) {
+ __flush_svm_range_dev(svm, sdev, start, align >>
VTD_PAGE_SHIFT, ih);
+ start += align;
+ }
+}
+
static void intel_flush_svm_range(struct intel_svm *svm, unsigned long address,
unsigned long pages, int ih)
{
--
2.25.1
[PATCH 1/5] iommu/vt-d: Fix misuse of ALIGN in qi_flush_piotlb()
Use IS_ALIGNED() instead. Otherwise, an unaligned address will be ignored.
Fixes: 33cd6e642d6a7 ("iommu/vt-d: Flush PASID-based iotlb for iova over first
level")
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/dmar.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c
index b46dbfa6d0ed..004feaed3c72 100644
--- a/drivers/iommu/intel/dmar.c
+++ b/drivers/iommu/intel/dmar.c
@@ -1461,8 +1461,8 @@ void qi_flush_piotlb(struct intel_iommu *iommu, u16 did,
u32 pasid, u64 addr,
int mask = ilog2(__roundup_pow_of_two(npages));
unsigned long align = (1ULL << (VTD_PAGE_SHIFT + mask));
- if (WARN_ON_ONCE(!ALIGN(addr, align)))
- addr &= ~(align - 1);
+ if (WARN_ON_ONCE(!IS_ALIGNED(addr, align)))
+ addr = ALIGN_DOWN(addr, align);
desc.qw0 = QI_EIOTLB_PASID(pasid) |
QI_EIOTLB_DID(did) |
--
2.25.1
[PATCH 3/5] iommu/vt-d: Remove unused dma map/unmap trace events
With commit c588072bba6b5 ("iommu/vt-d: Convert intel iommu driver to
the iommu ops"), the trace events for dma map/unmap have no users any
more. Remove them so that they don't show up under
/sys/kernel/debug/tracing/events/intel_iommu. The users should use the
map/unmap traces defined in the iommu core from now on.
Fixes: c588072bba6b5 ("iommu/vt-d: Convert intel iommu driver to the iommu ops")
Signed-off-by: Lu Baolu
---
include/trace/events/intel_iommu.h | 119 -
1 file changed, 119 deletions(-)
diff --git a/include/trace/events/intel_iommu.h
b/include/trace/events/intel_iommu.h
index 112bd06487bf..31c74202d8c3 100644
--- a/include/trace/events/intel_iommu.h
+++ b/include/trace/events/intel_iommu.h
@@ -16,125 +16,6 @@
#include
#include
-DECLARE_EVENT_CLASS(dma_map,
- TP_PROTO(struct device *dev, dma_addr_t dev_addr, phys_addr_t phys_addr,
-size_t size),
-
- TP_ARGS(dev, dev_addr, phys_addr, size),
-
- TP_STRUCT__entry(
- __string(dev_name, dev_name(dev))
- __field(dma_addr_t, dev_addr)
- __field(phys_addr_t, phys_addr)
- __field(size_t, size)
- ),
-
- TP_fast_assign(
- __assign_str(dev_name, dev_name(dev));
- __entry->dev_addr = dev_addr;
- __entry->phys_addr = phys_addr;
- __entry->size = size;
- ),
-
- TP_printk("dev=%s dev_addr=0x%llx phys_addr=0x%llx size=%zu",
- __get_str(dev_name),
- (unsigned long long)__entry->dev_addr,
- (unsigned long long)__entry->phys_addr,
- __entry->size)
-);
-
-DEFINE_EVENT(dma_map, map_single,
- TP_PROTO(struct device *dev, dma_addr_t dev_addr, phys_addr_t phys_addr,
-size_t size),
- TP_ARGS(dev, dev_addr, phys_addr, size)
-);
-
-DEFINE_EVENT(dma_map, bounce_map_single,
- TP_PROTO(struct device *dev, dma_addr_t dev_addr, phys_addr_t phys_addr,
-size_t size),
- TP_ARGS(dev, dev_addr, phys_addr, size)
-);
-
-DECLARE_EVENT_CLASS(dma_unmap,
- TP_PROTO(struct device *dev, dma_addr_t dev_addr, size_t size),
-
- TP_ARGS(dev, dev_addr, size),
-
- TP_STRUCT__entry(
- __string(dev_name, dev_name(dev))
- __field(dma_addr_t, dev_addr)
- __field(size_t, size)
- ),
-
- TP_fast_assign(
- __assign_str(dev_name, dev_name(dev));
- __entry->dev_addr = dev_addr;
- __entry->size = size;
- ),
-
- TP_printk("dev=%s dev_addr=0x%llx size=%zu",
- __get_str(dev_name),
- (unsigned long long)__entry->dev_addr,
- __entry->size)
-);
-
-DEFINE_EVENT(dma_unmap, unmap_single,
- TP_PROTO(struct device *dev, dma_addr_t dev_addr, size_t size),
- TP_ARGS(dev, dev_addr, size)
-);
-
-DEFINE_EVENT(dma_unmap, unmap_sg,
- TP_PROTO(struct device *dev, dma_addr_t dev_addr, size_t size),
- TP_ARGS(dev, dev_addr, size)
-);
-
-DEFINE_EVENT(dma_unmap, bounce_unmap_single,
- TP_PROTO(struct device *dev, dma_addr_t dev_addr, size_t size),
- TP_ARGS(dev, dev_addr, size)
-);
-
-DECLARE_EVENT_CLASS(dma_map_sg,
- TP_PROTO(struct device *dev, int index, int total,
-struct scatterlist *sg),
-
- TP_ARGS(dev, index, total, sg),
-
- TP_STRUCT__entry(
- __string(dev_name, dev_name(dev))
- __field(dma_addr_t, dev_addr)
- __field(phys_addr_t, phys_addr)
- __field(size_t, size)
- __field(int, index)
- __field(int, total)
- ),
-
- TP_fast_assign(
- __assign_str(dev_name, dev_name(dev));
- __entry->dev_addr = sg->dma_address;
- __entry->phys_addr = sg_phys(sg);
- __entry->size = sg->dma_length;
- __entry->index = index;
- __entry->total = total;
- ),
-
- TP_printk("dev=%s [%d/%d] dev_addr=0x%llx phys_addr=0x%llx size=%zu",
- __get_str(dev_name), __entry->index, __entry->total,
- (unsigned long long)__entry->dev_addr,
- (unsigned long long)__entry->phys_addr,
- __entry->size)
-);
-
-DEFINE_EVENT(dma_map_sg, map_sg,
- TP_PROTO(struct device *dev, int index, int total,
-struct scatterlist *sg),
- TP_ARGS(dev, index, total, sg)
-);
-
-DEFINE_EVENT(dma_map_sg, bounce_map_sg,
- TP_PROTO(struct device *dev, int index, int total,
-struct scatterlist *sg),
- TP_ARGS(dev, index, total, sg)
-);
#endif /* _TRACE_INTEL_IOMMU_H */
/* This part must be outside protection */
--
2.25.1
回复: [PATCH] ipc/sem.c: Convert kfree_rcu() to call_rcu() in freeary function
发件人: Paul E. McKenney
发送时间: 2020年12月31日 0:19
收件人: Zhang, Qiang
抄送: a...@linux-foundation.org; manf...@colorfullife.com; gustavo...@kernel.org;
linux-kernel@vger.kernel.org
主题: Re: [PATCH] ipc/sem.c: Convert kfree_rcu() to call_rcu() in freeary function
On Wed, Dec 30, 2020 at 08:00:38PM +0800, qiang.zh...@windriver.com wrote:
> From: Zqiang
>
> Due to freeary function is called with spinlock be held,
> the synchronize_rcu function may be called in kfree_rcu
> function, the schedule may be happen in spinlock critical
> region, need to replace kfree_rcu() with call_rcu().
>
>Except that the call to kfree_rcu() below has two arguments, and >thus
>provides a link for queuing the callback. It will never directly invoke
>synchronize_rcu(). It is only the single-argument variant of >kfree_rcu()
>that might invoke synchronize_rcu().
Sorry. It was my mistake, please ignore this patch.
Thanks
Qiang
>Or are you seeing lockdep or might-sleep failures with the current >code?
>If so, please post the relevant portions of the console output.
>
> Thanx, Paul
>
> Fixes: 693a8b6eecce ("ipc,rcu: Convert call_rcu(free_un) to kfree_rcu()")
> Signed-off-by: Zqiang
> ---
> ipc/sem.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/ipc/sem.c b/ipc/sem.c
> index f6c30a85dadf..12c3184347d9 100644
> --- a/ipc/sem.c
> +++ b/ipc/sem.c
> @@ -1132,6 +1132,13 @@ static int count_semcnt(struct sem_array *sma, ushort
> semnum,
> return semcnt;
> }
>
> +static void free_un(struct rcu_head *head)
> +{
> + struct sem_undo *un = container_of(head, struct sem_undo, rcu);
> +
> + kfree(un);
> +}
> +
> /* Free a semaphore set. freeary() is called with sem_ids.rwsem locked
> * as a writer and the spinlock for this semaphore set hold. sem_ids.rwsem
> * remains locked on exit.
> @@ -1152,7 +1159,7 @@ static void freeary(struct ipc_namespace *ns, struct
> kern_ipc_perm *ipcp)
> un->semid = -1;
> list_del_rcu(>list_proc);
> spin_unlock(>ulp->lock);
> - kfree_rcu(un, rcu);
> + call_rcu(>rcu, free_un);
> }
>
> /* Wake up all pending processes and let them fail with EIDRM. */
> --
> 2.17.1
>
Re: [bug] Radeon 3900XT not switch to graphic mode on kernel 5.10
On Tue, 29 Dec 2020 at 20:15, Deucher, Alexander wrote: > > It looks like the driver is not able to access the firmware for some reason. > Please make sure it is available in your initrd or compiled into the kernel > depending on your config. Exactly! Thanks! # lsinitrd /boot/initramfs-5.10.0-0.rc6.20201204git34816d20f173.92.fc34.x86_64.img | grep sienna_cichlid # ls /usr/lib/firmware/amdgpu | grep sienna_cichlid sienna_cichlid_ce.bin sienna_cichlid_dmcub.bin sienna_cichlid_me.bin sienna_cichlid_mec2.bin sienna_cichlid_mec.bin sienna_cichlid_pfp.bin sienna_cichlid_rlc.bin sienna_cichlid_sdma.bin sienna_cichlid_smc.bin sienna_cichlid_sos.bin sienna_cichlid_ta.bin sienna_cichlid_vcn.bin # dracut -f --regenerate-all # lsinitrd /boot/initramfs-5.10.0-0.rc6.20201204git34816d20f173.92.fc34.x86_64.img | grep sienna_cichlid -rw-r--r-- 1 root root 263296 Dec 15 14:00 usr/lib/firmware/amdgpu/sienna_cichlid_ce.bin -rw-r--r-- 1 root root80244 Dec 15 14:00 usr/lib/firmware/amdgpu/sienna_cichlid_dmcub.bin -rw-r--r-- 1 root root 263424 Dec 15 14:00 usr/lib/firmware/amdgpu/sienna_cichlid_me.bin -rw-r--r-- 2 root root 268592 Dec 15 14:00 usr/lib/firmware/amdgpu/sienna_cichlid_mec2.bin -rw-r--r-- 2 root root0 Dec 15 14:00 usr/lib/firmware/amdgpu/sienna_cichlid_mec.bin -rw-r--r-- 1 root root 263424 Dec 15 14:00 usr/lib/firmware/amdgpu/sienna_cichlid_pfp.bin -rw-r--r-- 1 root root 128592 Dec 15 14:00 usr/lib/firmware/amdgpu/sienna_cichlid_rlc.bin -rw-r--r-- 1 root root34048 Dec 15 14:00 usr/lib/firmware/amdgpu/sienna_cichlid_sdma.bin -rw-r--r-- 1 root root 247396 Dec 15 14:00 usr/lib/firmware/amdgpu/sienna_cichlid_smc.bin -rw-r--r-- 1 root root 215152 Dec 15 14:00 usr/lib/firmware/amdgpu/sienna_cichlid_sos.bin -rw-r--r-- 1 root root 333568 Dec 15 14:00 usr/lib/firmware/amdgpu/sienna_cichlid_ta.bin -rw-r--r-- 1 root root 504224 Dec 15 14:00 usr/lib/firmware/amdgpu/sienna_cichlid_vcn.bin # grep '20201204git34816d20f173\|linux-firmware-20201218-116' /var/log/dnf.rpm.log 2020-12-06T12:40:44+0500 SUBDEBUG Installed: kernel-core-5.10.0-0.rc6.20201204git34816d20f173.92.fc34.x86_64 2020-12-06T12:40:46+0500 SUBDEBUG Installed: kernel-modules-5.10.0-0.rc6.20201204git34816d20f173.92.fc34.x86_64 2020-12-06T12:41:03+0500 SUBDEBUG Installed: kernel-5.10.0-0.rc6.20201204git34816d20f173.92.fc34.x86_64 2020-12-06T12:41:03+0500 SUBDEBUG Installed: kernel-modules-extra-5.10.0-0.rc6.20201204git34816d20f173.92.fc34.x86_64 2020-12-21T10:52:43+0500 SUBDEBUG Upgrade: linux-firmware-20201218-116.fc34.noarch I think every update of linux-firmware should regenerate initramfs. But my downstream report was closed: https://bugzilla.redhat.com/show_bug.cgi?id=1911745 -- Best Regards, Mike Gavrilov.
Re: [LKP] Re: [kasan] 97593cad00: RIP:kasan_record_aux_stack
On 12/31/20 4:49 AM, Linus Torvalds wrote:
On Tue, Dec 29, 2020 at 6:59 PM kernel test robot wrote:
[ 235.553325] BUG: sleeping function called from invalid context at
arch/x86/mm/fault.c:1351
[ 235.554684] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 7515,
name: trinity-c1
[ 235.555890] 2 locks held by trinity-c1/7515:
[ 235.556506] #0: 8323dd38 (>rwsem){}-{3:3}, at:
semctl_down+0x6d/0x686
[ 235.557684] #1: 888128ccc868 (>mmap_lock#2){}-{3:3}, at:
do_user_addr_fault+0x196/0x59e
[ 235.559020] CPU: 1 PID: 7515 Comm: trinity-c1 Not tainted
5.10.0-g97593cad003c #2
[ 235.560317] Call Trace:
[ 235.560767] dump_stack+0x7d/0xa3
[ 235.561371] ___might_sleep+0x2c4/0x2df
[ 235.562063] ? do_user_addr_fault+0x196/0x59e
[ 235.562834] do_user_addr_fault+0x234/0x59e
[ 235.563519] exc_page_fault+0x70/0x8b
[ 235.564112] asm_exc_page_fault+0x1b/0x20
Btw, I wonder if the kernel test robot dumps could be please run through the
scripts/decode_stacktrace.sh
script to give line numbers and inlining information?
That does require CONFIG_DEBUG_INFO to work, but it would help things
like this when you don't have to try to guess where the exact access
happens.
Now, in this case, it seems to be a recursive issue with the original
fault happening in:
[ 235.564754] RIP: 0010:kasan_record_aux_stack+0x64/0x74
And yeah, that explains why it then bisects to 97593cad003c ("kasan:
sanitize objects when metadata doesn't fit")
The faulting instruction sequence decodes to
10: 48 39 f3cmp%rsi,%rbx
13: 48 0f 46 f3 cmovbe %rbx,%rsi
17: e8 6f e5 ff ff callq .. something ..
1c: bf 00 08 00 00 mov$0x800,%edi
21: 48 89 c3mov%rax,%rbx
24:* 8b 40 08mov0x8(%rax),%eax <--
trapping instruction
27: 89 43 0cmov%eax,0xc(%rbx)
and I *think* that "call something" is the call to
kasan_get_alloc_meta. And there is no check for a NULL return.
So I think this was already fixed by commit 13384f6125ad ("kasan: fix
null pointer dereference in kasan_record_aux_stack").
But see about that "decode_stacktrace,sh" script request. I thought I
had already asked for this, but I now realize that I think that was
just for syzbot.
Can we do that for these kernel test robot reports too? Please?
Linus
Hi Linus,
Sorry for the inconvenience and we're working on it right now.
Happy New Year!
Best Regards,
Rong Chen
Re: [PATCH 3/3] MIPS: cpu-probe: Vulnerabilities for Loongson cores
Hi, Jiaxun,
On Wed, Dec 30, 2020 at 11:26 AM Jiaxun Yang wrote:
>
> Loongson64C is known to be vulnerable to meltdown according to
> PoC from Rui Wang .
How about Loongson-3A1000/3B1500, and Loongson-2E/2F?
Huacai
>
> Loongson64G defended these side-channel attack by silicon.
>
> Signed-off-by: Jiaxun Yang
> ---
> arch/mips/kernel/cpu-probe.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
> index 2460783dbdb1..24b21f51353c 100644
> --- a/arch/mips/kernel/cpu-probe.c
> +++ b/arch/mips/kernel/cpu-probe.c
> @@ -2092,6 +2092,8 @@ static inline void cpu_probe_loongson(struct
> cpuinfo_mips *c, unsigned int cpu)
> c->ases |= (MIPS_ASE_LOONGSON_MMI | MIPS_ASE_LOONGSON_CAM |
> MIPS_ASE_LOONGSON_EXT | MIPS_ASE_LOONGSON_EXT2);
> c->ases &= ~MIPS_ASE_VZ; /* VZ of Loongson-3A2000/3000 is
> incomplete */
> + c->vulnerabilities |= MIPS_VULNBL_MELTDOWN;
> + c->vulnerable |= MIPS_VULNBL_MELTDOWN;
> break;
> case PRID_IMP_LOONGSON_64G:
> c->cputype = CPU_LOONGSON64;
> @@ -2100,6 +2102,8 @@ static inline void cpu_probe_loongson(struct
> cpuinfo_mips *c, unsigned int cpu)
> set_isa(c, MIPS_CPU_ISA_M64R2);
> decode_cpucfg(c);
> c->writecombine = _CACHE_UNCACHED_ACCELERATED;
> + c->vulnerabilities |= MIPS_VULNBL_MELTDOWN |
> + MIPS_VULNBL_SPECTRE_V1 | MIPS_VULNBL_SPECTRE_V2;
> break;
> default:
> panic("Unknown Loongson Processor ID!");
> --
> 2.30.0
>
Re: [PATCH 2/3] MIPS: cpu-probe: Vulnerabilities for MIPS cores
Reviewed-by: Huacai Chen
On Wed, Dec 30, 2020 at 11:25 AM Jiaxun Yang wrote:
>
> Accorading to MIPS's announcement[1], only P5600 and P6600 is
> affected by spectre v1 and v2, other cores are not affected.
>
> So we mark vulnerabilities states for MIPS cores as known and
> set P5600 and P6600 as vulnerable.
>
> [1]:
> https://www.mips.com/blog/mips-response-on-speculative-execution-and-side-channel-vulnerabilities/
>
> Signed-off-by: Jiaxun Yang
> ---
> arch/mips/kernel/cpu-probe.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
> index 03adeed58efb..2460783dbdb1 100644
> --- a/arch/mips/kernel/cpu-probe.c
> +++ b/arch/mips/kernel/cpu-probe.c
> @@ -1688,6 +1688,9 @@ static inline void cpu_probe_legacy(struct cpuinfo_mips
> *c, unsigned int cpu)
> static inline void cpu_probe_mips(struct cpuinfo_mips *c, unsigned int cpu)
> {
> c->writecombine = _CACHE_UNCACHED_ACCELERATED;
> + c->vulnerabilities |= MIPS_VULNBL_MELTDOWN |
> + MIPS_VULNBL_SPECTRE_V1 | MIPS_VULNBL_SPECTRE_V2;
> +
> switch (c->processor_id & PRID_IMP_MASK) {
> case PRID_IMP_QEMU_GENERIC:
> c->writecombine = _CACHE_UNCACHED;
> @@ -1794,10 +1797,12 @@ static inline void cpu_probe_mips(struct cpuinfo_mips
> *c, unsigned int cpu)
> case PRID_IMP_P5600:
> c->cputype = CPU_P5600;
> __cpu_name[cpu] = "MIPS P5600";
> + c->vulnerable |= MIPS_VULNBL_SPECTRE_V1 |
> MIPS_VULNBL_SPECTRE_V2;
> break;
> case PRID_IMP_P6600:
> c->cputype = CPU_P6600;
> __cpu_name[cpu] = "MIPS P6600";
> + c->vulnerable |= MIPS_VULNBL_SPECTRE_V1 |
> MIPS_VULNBL_SPECTRE_V2;
> break;
> case PRID_IMP_I6400:
> c->cputype = CPU_I6400;
> --
> 2.30.0
>
Re: [PATCH 1/3] MIPS: Add vulnerabilities infrastructure
Hi, Jiaxun,
On Wed, Dec 30, 2020 at 11:25 AM Jiaxun Yang wrote:
>
> Add infrastructure to display CPU vulnerabilities.
> As most MIPS CPU vendors are dead today and we can't confirm
> vulnerabilities states with them, we'll display vulnerabilities
> as "Unknown" by default and override them in cpu-probe.c
>
> Signed-off-by: Jiaxun Yang
> ---
> arch/mips/Kconfig| 1 +
> arch/mips/include/asm/cpu-info.h | 5
> arch/mips/include/asm/cpu.h | 7 +
> arch/mips/kernel/Makefile| 2 +-
> arch/mips/kernel/vulnbl.c| 46
> 5 files changed, 60 insertions(+), 1 deletion(-)
> create mode 100644 arch/mips/kernel/vulnbl.c
>
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index ef5b2a177b1b..524053b8f769 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -24,6 +24,7 @@ config MIPS
> select GENERIC_CLOCKEVENTS
> select GENERIC_CMOS_UPDATE
> select GENERIC_CPU_AUTOPROBE
> + select GENERIC_CPU_VULNERABILITIES
> select GENERIC_GETTIMEOFDAY
> select GENERIC_IOMAP
> select GENERIC_IRQ_PROBE
> diff --git a/arch/mips/include/asm/cpu-info.h
> b/arch/mips/include/asm/cpu-info.h
> index a600670d00e9..1a964dbfc0a8 100644
> --- a/arch/mips/include/asm/cpu-info.h
> +++ b/arch/mips/include/asm/cpu-info.h
> @@ -106,6 +106,11 @@ struct cpuinfo_mips {
> unsigned intguestid_mask;
> unsigned intguestid_cache;
>
> + /* Vulnerabilities */
> + unsigned intvulnerabilities; /* Vulnerabilities states
> that we known */
> + unsigned intvulnerable; /* Vulnerabilities affated */
What is "affated"? maybe "affected"?
Huacai
> + unsigned intmitigations; /* Mitigations */
> +
> #ifdef CONFIG_CPU_LOONGSON3_CPUCFG_EMULATION
> /* CPUCFG data for this CPU, synthesized at probe time.
> *
> diff --git a/arch/mips/include/asm/cpu.h b/arch/mips/include/asm/cpu.h
> index f5b04e8f6061..3414c9f5464e 100644
> --- a/arch/mips/include/asm/cpu.h
> +++ b/arch/mips/include/asm/cpu.h
> @@ -447,4 +447,11 @@ enum cpu_type_enum {
> #define MIPS_ASE_LOONGSON_EXT 0x2000 /* Loongson EXTensions */
> #define MIPS_ASE_LOONGSON_EXT2 0x4000 /* Loongson EXTensions R2 */
>
> +/*
> + * CPU security vulnerabilities
> + */
> +#define MIPS_VULNBL_MELTDOWN BIT(0)
> +#define MIPS_VULNBL_SPECTRE_V1 BIT(1)
> +#define MIPS_VULNBL_SPECTRE_V2 BIT(2)
> +
> #endif /* _ASM_CPU_H */
> diff --git a/arch/mips/kernel/Makefile b/arch/mips/kernel/Makefile
> index 13a26d254829..39abc8ead5e0 100644
> --- a/arch/mips/kernel/Makefile
> +++ b/arch/mips/kernel/Makefile
> @@ -8,7 +8,7 @@ extra-y := head.o vmlinux.lds
> obj-y += cmpxchg.o cpu-probe.o branch.o elf.o entry.o genex.o
> idle.o irq.o \
>process.o prom.o ptrace.o reset.o setup.o signal.o \
>syscall.o time.o topology.o traps.o unaligned.o watch.o \
> - vdso.o cacheinfo.o
> + vdso.o cacheinfo.o vulnbl.o
>
> ifdef CONFIG_FUNCTION_TRACER
> CFLAGS_REMOVE_ftrace.o = -pg
> diff --git a/arch/mips/kernel/vulnbl.c b/arch/mips/kernel/vulnbl.c
> new file mode 100644
> index ..fc73da6214fe
> --- /dev/null
> +++ b/arch/mips/kernel/vulnbl.c
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2020, Jiaxun Yang
> + * MIPS CPU vulnerabilities
> + */
> +
> +#include
> +
> +#include
> +#include
> +
> +ssize_t cpu_show_meltdown(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + if (!(boot_cpu_data.vulnerabilities & MIPS_VULNBL_MELTDOWN))
> + return sprintf(buf, "Unknown\n");
> +
> + if (!(boot_cpu_data.vulnerable & MIPS_VULNBL_MELTDOWN))
> + return sprintf(buf, "Not affected\n");
> +
> + return sprintf(buf, "Affected\n");
> +}
> +
> +ssize_t cpu_show_spectre_v1(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + if (!(boot_cpu_data.vulnerabilities & MIPS_VULNBL_SPECTRE_V1))
> + return sprintf(buf, "Unknown\n");
> +
> + if (!(boot_cpu_data.vulnerable & MIPS_VULNBL_SPECTRE_V1))
> + return sprintf(buf, "Not affected\n");
> +
> + return sprintf(buf, "Affected\n");
> +}
> +
> +ssize_t cpu_show_spectre_v2(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + if (!(boot_cpu_data.vulnerabilities & MIPS_VULNBL_SPECTRE_V2))
> + return sprintf(buf, "Unknown\n");
> +
> + if (!(boot_cpu_data.vulnerable & MIPS_VULNBL_SPECTRE_V2))
> + return sprintf(buf, "Not affected\n");
> +
> + return sprintf(buf, "Affected\n");
> +}
> --
> 2.30.0
>
[PATCH 8/9] KVM: x86: Kill off __ex() and __kvm_handle_fault_on_reboot()
Remove the __kvm_handle_fault_on_reboot() and __ex() macros now that all
VMX and SVM instructions use asm goto to handle the fault (or in the
case of VMREAD, completely custom logic). Drop kvm_spurious_fault()'s
asmlinkage annotation as __kvm_handle_fault_on_reboot() was the only
flow that invoked it from assembly code.
Cc: Uros Bizjak
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/kvm_host.h | 25 +
arch/x86/kvm/svm/sev.c | 2 --
arch/x86/kvm/svm/svm.c | 2 --
arch/x86/kvm/vmx/vmx_ops.h | 2 --
arch/x86/kvm/x86.c | 9 -
5 files changed, 9 insertions(+), 31 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 3ab7b46087b7..51ba20ffaedb 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1634,30 +1634,7 @@ enum {
#define kvm_arch_vcpu_memslots_id(vcpu) ((vcpu)->arch.hflags & HF_SMM_MASK ? 1
: 0)
#define kvm_memslots_for_spte_role(kvm, role) __kvm_memslots(kvm, (role).smm)
-asmlinkage void kvm_spurious_fault(void);
-
-/*
- * Hardware virtualization extension instructions may fault if a
- * reboot turns off virtualization while processes are running.
- * Usually after catching the fault we just panic; during reboot
- * instead the instruction is ignored.
- */
-#define __kvm_handle_fault_on_reboot(insn) \
- "666: \n\t" \
- insn "\n\t" \
- "jmp668f \n\t" \
- "667: \n\t" \
- "1: \n\t" \
- ".pushsection .discard.instr_begin \n\t"\
- ".long 1b - . \n\t" \
- ".popsection \n\t" \
- "call kvm_spurious_fault \n\t"\
- "1: \n\t" \
- ".pushsection .discard.instr_end \n\t" \
- ".long 1b - . \n\t" \
- ".popsection \n\t" \
- "668: \n\t" \
- _ASM_EXTABLE(666b, 667b)
+void kvm_spurious_fault(void);
#define KVM_ARCH_WANT_MMU_NOTIFIER
int kvm_unmap_hva_range(struct kvm *kvm, unsigned long start, unsigned long
end,
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 4511d7ccdb19..e7080e5056a4 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -26,8 +26,6 @@
#include "cpuid.h"
#include "trace.h"
-#define __ex(x) __kvm_handle_fault_on_reboot(x)
-
static u8 sev_enc_bit;
static int sev_flush_asids(void);
static DECLARE_RWSEM(sev_deactivate_lock);
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 4308ab5ca27e..e4907e490c24 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -43,8 +43,6 @@
#include "svm.h"
#include "svm_ops.h"
-#define __ex(x) __kvm_handle_fault_on_reboot(x)
-
MODULE_AUTHOR("Qumranet");
MODULE_LICENSE("GPL");
diff --git a/arch/x86/kvm/vmx/vmx_ops.h b/arch/x86/kvm/vmx/vmx_ops.h
index 692b0c31c9c8..7b6fbe103c61 100644
--- a/arch/x86/kvm/vmx/vmx_ops.h
+++ b/arch/x86/kvm/vmx/vmx_ops.h
@@ -10,8 +10,6 @@
#include "evmcs.h"
#include "vmcs.h"
-#define __ex(x) __kvm_handle_fault_on_reboot(x)
-
asmlinkage void vmread_error(unsigned long field, bool fault);
__attribute__((regparm(0))) void vmread_error_trampoline(unsigned long field,
bool fault);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 3f7c1fc7a3ce..836912b42030 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -412,7 +412,14 @@ int kvm_set_apic_base(struct kvm_vcpu *vcpu, struct
msr_data *msr_info)
}
EXPORT_SYMBOL_GPL(kvm_set_apic_base);
-asmlinkage __visible noinstr void kvm_spurious_fault(void)
+/*
+ * Handle a fault on a hardware virtualization (VMX or SVM) instruction.
+ *
+ * Hardware virtualization extension instructions may fault if a reboot turns
+ * off virtualization while processes are running. Usually after catching the
+ * fault we just panic; during reboot instead the instruction is ignored.
+ */
+noinstr void kvm_spurious_fault(void)
{
/* Fault while not rebooting. We want the trace. */
BUG_ON(!kvm_rebooting);
--
2.29.2.729.g45daf8777d-goog
[PATCH 9/9] KVM: x86: Move declaration of kvm_spurious_fault() to x86.h
From: Uros Bizjak
Move the declaration of kvm_spurious_fault() to KVM's "private" x86.h,
it should never be called by anything other than low level KVM code.
Cc: Paolo Bonzini
Cc: Sean Christopherson
Signed-off-by: Uros Bizjak
[sean: rebased to a series without __ex()/__kvm_handle_fault_on_reboot()]
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/kvm_host.h | 2 --
arch/x86/kvm/svm/svm_ops.h | 2 +-
arch/x86/kvm/vmx/vmx_ops.h | 2 +-
arch/x86/kvm/x86.h | 2 ++
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 51ba20ffaedb..feba0ec5474b 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1634,8 +1634,6 @@ enum {
#define kvm_arch_vcpu_memslots_id(vcpu) ((vcpu)->arch.hflags & HF_SMM_MASK ? 1
: 0)
#define kvm_memslots_for_spte_role(kvm, role) __kvm_memslots(kvm, (role).smm)
-void kvm_spurious_fault(void);
-
#define KVM_ARCH_WANT_MMU_NOTIFIER
int kvm_unmap_hva_range(struct kvm *kvm, unsigned long start, unsigned long
end,
unsigned flags);
diff --git a/arch/x86/kvm/svm/svm_ops.h b/arch/x86/kvm/svm/svm_ops.h
index 0c8377aee52c..aa028ef5b1e9 100644
--- a/arch/x86/kvm/svm/svm_ops.h
+++ b/arch/x86/kvm/svm/svm_ops.h
@@ -4,7 +4,7 @@
#include
-#include
+#include "x86.h"
#define svm_asm(insn, clobber...) \
do { \
diff --git a/arch/x86/kvm/vmx/vmx_ops.h b/arch/x86/kvm/vmx/vmx_ops.h
index 7b6fbe103c61..7e3cb53c413f 100644
--- a/arch/x86/kvm/vmx/vmx_ops.h
+++ b/arch/x86/kvm/vmx/vmx_ops.h
@@ -4,11 +4,11 @@
#include
-#include
#include
#include "evmcs.h"
#include "vmcs.h"
+#include "x86.h"
asmlinkage void vmread_error(unsigned long field, bool fault);
__attribute__((regparm(0))) void vmread_error_trampoline(unsigned long field,
diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
index c5ee0f5ce0f1..0d830945ae38 100644
--- a/arch/x86/kvm/x86.h
+++ b/arch/x86/kvm/x86.h
@@ -8,6 +8,8 @@
#include "kvm_cache_regs.h"
#include "kvm_emulate.h"
+void kvm_spurious_fault(void);
+
#define KVM_DEFAULT_PLE_GAP128
#define KVM_VMX_DEFAULT_PLE_WINDOW 4096
#define KVM_DEFAULT_PLE_WINDOW_GROW2
--
2.29.2.729.g45daf8777d-goog
[PATCH 7/9] KVM: SVM: Use asm goto to handle unexpected #UD on SVM instructions
Add svm_asm*() macros, a la the existing vmx_asm*() macros, to handle
faults on SVM instructions instead of using the generic __ex(), a.k.a.
__kvm_handle_fault_on_reboot(). Using asm goto generates slightly
better code as it eliminates the in-line JMP+CALL sequences that are
needed by __kvm_handle_fault_on_reboot() to avoid triggering BUG()
from fixup (which generates bad stack traces).
Using SVM specific macros also drops the last user of __ex() and the
the last asm linkage to kvm_spurious_fault(), and adds a helper for
VMSAVE, which may gain an addition call site in the future (as part
of optimizing the SVM context switching).
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/svm/sev.c | 3 +-
arch/x86/kvm/svm/svm.c | 16 +--
arch/x86/kvm/svm/svm_ops.h | 59 ++
3 files changed, 62 insertions(+), 16 deletions(-)
create mode 100644 arch/x86/kvm/svm/svm_ops.h
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 9858d5ae9ddd..4511d7ccdb19 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -22,6 +22,7 @@
#include "x86.h"
#include "svm.h"
+#include "svm_ops.h"
#include "cpuid.h"
#include "trace.h"
@@ -2001,7 +2002,7 @@ void sev_es_vcpu_load(struct vcpu_svm *svm, int cpu)
* of which one step is to perform a VMLOAD. Since hardware does not
* perform a VMSAVE on VMRUN, the host savearea must be updated.
*/
- asm volatile(__ex("vmsave") : : "a" (__sme_page_pa(sd->save_area)) :
"memory");
+ vmsave(__sme_page_pa(sd->save_area));
/*
* Certain MSRs are restored on VMEXIT, only save ones that aren't
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index cce0143a6f80..4308ab5ca27e 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -41,6 +41,7 @@
#include "trace.h"
#include "svm.h"
+#include "svm_ops.h"
#define __ex(x) __kvm_handle_fault_on_reboot(x)
@@ -246,21 +247,6 @@ u32 svm_msrpm_offset(u32 msr)
#define MAX_INST_SIZE 15
-static inline void clgi(void)
-{
- asm volatile (__ex("clgi"));
-}
-
-static inline void stgi(void)
-{
- asm volatile (__ex("stgi"));
-}
-
-static inline void invlpga(unsigned long addr, u32 asid)
-{
- asm volatile (__ex("invlpga %1, %0") : : "c"(asid), "a"(addr));
-}
-
static int get_max_npt_level(void)
{
#ifdef CONFIG_X86_64
diff --git a/arch/x86/kvm/svm/svm_ops.h b/arch/x86/kvm/svm/svm_ops.h
new file mode 100644
index ..0c8377aee52c
--- /dev/null
+++ b/arch/x86/kvm/svm/svm_ops.h
@@ -0,0 +1,59 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __KVM_X86_SVM_OPS_H
+#define __KVM_X86_SVM_OPS_H
+
+#include
+
+#include
+
+#define svm_asm(insn, clobber...) \
+do { \
+ asm_volatile_goto("1: " __stringify(insn) "\n\t"\
+ _ASM_EXTABLE(1b, %l[fault]) \
+ ::: clobber : fault); \
+ return; \
+fault: \
+ kvm_spurious_fault(); \
+} while (0)
+
+#define svm_asm1(insn, op1, clobber...)\
+do { \
+ asm_volatile_goto("1: " __stringify(insn) " %0\n\t"\
+ _ASM_EXTABLE(1b, %l[fault]) \
+ :: op1 : clobber : fault);\
+ return; \
+fault: \
+ kvm_spurious_fault(); \
+} while (0)
+
+#define svm_asm2(insn, op1, op2, clobber...) \
+do { \
+ asm_volatile_goto("1: " __stringify(insn) " %1, %0\n\t"\
+ _ASM_EXTABLE(1b, %l[fault]) \
+ :: op1, op2 : clobber : fault); \
+ return; \
+fault: \
+ kvm_spurious_fault(); \
+} while (0)
+
+static inline void clgi(void)
+{
+ svm_asm(clgi);
+}
+
+static inline void stgi(void)
+{
+ svm_asm(stgi);
+}
+
+static inline void invlpga(unsigned long addr, u32 asid)
+{
+ svm_asm2(invlpga, "c"(asid), "a"(addr));
+}
+
+static inline void vmsave(hpa_t pa)
+{
+ svm_asm1(vmsave, "a" (pa), "memory");
+}
+
+#endif /* __KVM_X86_SVM_OPS_H */
--
2.29.2.729.g45daf8777d-goog
Re: [PATCH v3] MIPS: zboot: head.S clean up
Reviewed-by: Huacai Chen On Wed, Dec 30, 2020 at 11:49 AM Jiaxun Yang wrote: > > .cprestore is removed as we don't expect Position Independent > zboot ELF. > > .noreorder is also removed and rest instructions are massaged > to improve readability. > > t9 register is used for indirect jump as MIPS ABI requirement. > > start label is removed as it already defined in LEAF. > > Reported-by: Paul Cercueil > Signed-off-by: Jiaxun Yang > > -- > v2: Remove start label (paul) > --- > arch/mips/boot/compressed/head.S | 18 +++--- > 1 file changed, 7 insertions(+), 11 deletions(-) > > diff --git a/arch/mips/boot/compressed/head.S > b/arch/mips/boot/compressed/head.S > index 409cb483a9ff..070b2fbabae4 100644 > --- a/arch/mips/boot/compressed/head.S > +++ b/arch/mips/boot/compressed/head.S > @@ -15,10 +15,7 @@ > #include > #include > > - .set noreorder > - .cprestore > LEAF(start) > -start: > /* Save boot rom start args */ > moves0, a0 > moves1, a1 > @@ -35,21 +32,20 @@ start: > PTR_LA a0, (.heap) /* heap address */ > PTR_LA sp, (.stack + 8192) /* stack address */ > > - PTR_LA ra, 2f > - PTR_LA k0, decompress_kernel > - jr k0 > -nop > + PTR_LA t9, decompress_kernel > + jalrt9 > + > 2: > movea0, s0 > movea1, s1 > movea2, s2 > movea3, s3 > - PTR_LI k0, KERNEL_ENTRY > - jr k0 > -nop > + PTR_LI t9, KERNEL_ENTRY > + jalrt9 > + > 3: > b 3b > -nop > + > END(start) > > .comm .heap,BOOT_HEAP_SIZE,4 > -- > 2.30.0 >
[PATCH 5/9] KVM: VMX: Move Intel PT shenanigans out of VMXON/VMXOFF flows
Move the Intel PT tracking outside of the VMXON/VMXOFF helpers so that
a future patch can drop KVM's kvm_cpu_vmxoff() in favor of the kernel's
cpu_vmxoff() without an associated PT functional change, and without
losing symmetry between the VMXON and VMXOFF flows.
Barring undocumented behavior, this should have no meaningful effects
as Intel PT behavior does not interact with CR4.VMXE.
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/vmx/vmx.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 65b5f02b199f..131f390ade24 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -2265,7 +2265,6 @@ static int kvm_cpu_vmxon(u64 vmxon_pointer)
u64 msr;
cr4_set_bits(X86_CR4_VMXE);
- intel_pt_handle_vmx(1);
asm_volatile_goto("1: vmxon %[vmxon_pointer]\n\t"
_ASM_EXTABLE(1b, %l[fault])
@@ -2276,7 +2275,6 @@ static int kvm_cpu_vmxon(u64 vmxon_pointer)
fault:
WARN_ONCE(1, "VMXON faulted, MSR_IA32_FEAT_CTL (0x3a) = 0x%llx\n",
rdmsrl_safe(MSR_IA32_FEAT_CTL, ) ? 0xdeadbeef : msr);
- intel_pt_handle_vmx(0);
cr4_clear_bits(X86_CR4_VMXE);
return -EFAULT;
@@ -2299,9 +2297,13 @@ static int hardware_enable(void)
!hv_get_vp_assist_page(cpu))
return -EFAULT;
+ intel_pt_handle_vmx(1);
+
r = kvm_cpu_vmxon(phys_addr);
- if (r)
+ if (r) {
+ intel_pt_handle_vmx(0);
return r;
+ }
if (enable_ept)
ept_sync_global();
@@ -2327,7 +2329,6 @@ static void kvm_cpu_vmxoff(void)
{
asm volatile (__ex("vmxoff"));
- intel_pt_handle_vmx(0);
cr4_clear_bits(X86_CR4_VMXE);
}
@@ -2335,6 +2336,8 @@ static void hardware_disable(void)
{
vmclear_local_loaded_vmcss();
kvm_cpu_vmxoff();
+
+ intel_pt_handle_vmx(0);
}
/*
--
2.29.2.729.g45daf8777d-goog
[PATCH 6/9] KVM: VMX: Use the kernel's version of VMXOFF
Drop kvm_cpu_vmxoff() in favor of the kernel's cpu_vmxoff(). Modify the
latter to return -EIO on fault so that KVM can invoke
kvm_spurious_fault() when appropriate. In addition to the obvious code
reuse, dropping kvm_cpu_vmxoff() also eliminates VMX's last usage of the
__ex()/__kvm_handle_fault_on_reboot() macros, thus helping pave the way
toward dropping them entirely.
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/virtext.h | 7 ++-
arch/x86/kvm/vmx/vmx.c | 15 +++
2 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/arch/x86/include/asm/virtext.h b/arch/x86/include/asm/virtext.h
index 2cc585467667..8757078d4442 100644
--- a/arch/x86/include/asm/virtext.h
+++ b/arch/x86/include/asm/virtext.h
@@ -41,13 +41,18 @@ static inline int cpu_has_vmx(void)
* faults are guaranteed to be due to the !post-VMXON check unless the CPU is
* magically in RM, VM86, compat mode, or at CPL>0.
*/
-static inline void cpu_vmxoff(void)
+static inline int cpu_vmxoff(void)
{
asm_volatile_goto("1: vmxoff\n\t"
_ASM_EXTABLE(1b, %l[fault])
::: "cc", "memory" : fault);
+
+ cr4_clear_bits(X86_CR4_VMXE);
+ return 0;
+
fault:
cr4_clear_bits(X86_CR4_VMXE);
+ return -EIO;
}
static inline int cpu_vmx_enabled(void)
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 131f390ade24..1a3b508ba8c1 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -2321,21 +2321,12 @@ static void vmclear_local_loaded_vmcss(void)
__loaded_vmcs_clear(v);
}
-
-/* Just like cpu_vmxoff(), but with the __kvm_handle_fault_on_reboot()
- * tricks.
- */
-static void kvm_cpu_vmxoff(void)
-{
- asm volatile (__ex("vmxoff"));
-
- cr4_clear_bits(X86_CR4_VMXE);
-}
-
static void hardware_disable(void)
{
vmclear_local_loaded_vmcss();
- kvm_cpu_vmxoff();
+
+ if (cpu_vmxoff())
+ kvm_spurious_fault();
intel_pt_handle_vmx(0);
}
--
2.29.2.729.g45daf8777d-goog
[PATCH 4/9] KVM/nVMX: Use __vmx_vcpu_run in nested_vmx_check_vmentry_hw
From: Uros Bizjak
Replace inline assembly in nested_vmx_check_vmentry_hw
with a call to __vmx_vcpu_run. The function is not
performance critical, so (double) GPR save/restore
in __vmx_vcpu_run can be tolerated, as far as performance
effects are concerned.
Cc: Paolo Bonzini
Cc: Sean Christopherson
Reviewed-and-tested-by: Sean Christopherson
Signed-off-by: Uros Bizjak
[sean: dropped versioning info from changelog]
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/vmx/nested.c | 32 +++-
arch/x86/kvm/vmx/vmenter.S | 2 +-
arch/x86/kvm/vmx/vmx.c | 2 --
arch/x86/kvm/vmx/vmx.h | 1 +
4 files changed, 5 insertions(+), 32 deletions(-)
diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index e2f26564a12d..5bbb4d667370 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -12,6 +12,7 @@
#include "nested.h"
#include "pmu.h"
#include "trace.h"
+#include "vmx.h"
#include "x86.h"
static bool __read_mostly enable_shadow_vmcs = 1;
@@ -3057,35 +3058,8 @@ static int nested_vmx_check_vmentry_hw(struct kvm_vcpu
*vcpu)
vmx->loaded_vmcs->host_state.cr4 = cr4;
}
- asm(
- "sub $%c[wordsize], %%" _ASM_SP "\n\t" /* temporarily adjust
RSP for CALL */
- "cmp %%" _ASM_SP ", %c[host_state_rsp](%[loaded_vmcs]) \n\t"
- "je 1f \n\t"
- __ex("vmwrite %%" _ASM_SP ", %[HOST_RSP]") "\n\t"
- "mov %%" _ASM_SP ", %c[host_state_rsp](%[loaded_vmcs]) \n\t"
- "1: \n\t"
- "add $%c[wordsize], %%" _ASM_SP "\n\t" /* un-adjust RSP */
-
- /* Check if vmlaunch or vmresume is needed */
- "cmpb $0, %c[launched](%[loaded_vmcs])\n\t"
-
- /*
-* VMLAUNCH and VMRESUME clear RFLAGS.{CF,ZF} on VM-Exit, set
-* RFLAGS.CF on VM-Fail Invalid and set RFLAGS.ZF on VM-Fail
-* Valid. vmx_vmenter() directly "returns" RFLAGS, and so the
-* results of VM-Enter is captured via CC_{SET,OUT} to vm_fail.
-*/
- "call vmx_vmenter\n\t"
-
- CC_SET(be)
- : ASM_CALL_CONSTRAINT, CC_OUT(be) (vm_fail)
- : [HOST_RSP]"r"((unsigned long)HOST_RSP),
- [loaded_vmcs]"r"(vmx->loaded_vmcs),
- [launched]"i"(offsetof(struct loaded_vmcs, launched)),
- [host_state_rsp]"i"(offsetof(struct loaded_vmcs,
host_state.rsp)),
- [wordsize]"i"(sizeof(ulong))
- : "memory"
- );
+ vm_fail = __vmx_vcpu_run(vmx, (unsigned long *)>arch.regs,
+vmx->loaded_vmcs->launched);
if (vmx->msr_autoload.host.nr)
vmcs_write32(VM_EXIT_MSR_LOAD_COUNT, vmx->msr_autoload.host.nr);
diff --git a/arch/x86/kvm/vmx/vmenter.S b/arch/x86/kvm/vmx/vmenter.S
index e85aa5faa22d..3a6461694fc2 100644
--- a/arch/x86/kvm/vmx/vmenter.S
+++ b/arch/x86/kvm/vmx/vmenter.S
@@ -44,7 +44,7 @@
* they VM-Fail, whereas a successful VM-Enter + VM-Exit will jump
* to vmx_vmexit.
*/
-SYM_FUNC_START(vmx_vmenter)
+SYM_FUNC_START_LOCAL(vmx_vmenter)
/* EFLAGS.ZF is set if VMCS.LAUNCHED == 0 */
je 2f
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 75c9c6a0a3a4..65b5f02b199f 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -6577,8 +6577,6 @@ static fastpath_t vmx_exit_handlers_fastpath(struct
kvm_vcpu *vcpu)
}
}
-bool __vmx_vcpu_run(struct vcpu_vmx *vmx, unsigned long *regs, bool launched);
-
static noinstr void vmx_vcpu_enter_exit(struct kvm_vcpu *vcpu,
struct vcpu_vmx *vmx)
{
diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h
index 9d3a557949ac..03fc90569ae1 100644
--- a/arch/x86/kvm/vmx/vmx.h
+++ b/arch/x86/kvm/vmx/vmx.h
@@ -339,6 +339,7 @@ void vmx_set_virtual_apic_mode(struct kvm_vcpu *vcpu);
struct vmx_uret_msr *vmx_find_uret_msr(struct vcpu_vmx *vmx, u32 msr);
void pt_update_intercept_for_msr(struct kvm_vcpu *vcpu);
void vmx_update_host_rsp(struct vcpu_vmx *vmx, unsigned long host_rsp);
+bool __vmx_vcpu_run(struct vcpu_vmx *vmx, unsigned long *regs, bool launched);
int vmx_find_loadstore_msr_slot(struct vmx_msrs *m, u32 msr);
void vmx_ept_load_pdptrs(struct kvm_vcpu *vcpu);
--
2.29.2.729.g45daf8777d-goog
[PATCH 3/9] x86/virt: Mark flags and memory as clobbered by VMXOFF
From: David P. Reed
Explicitly tell the compiler that VMXOFF modifies flags (like all VMX
instructions), and mark memory as clobbered since VMXOFF must not be
reordered and also may have memory side effects (though the kernel
really shouldn't be accessing the root VMCS anyways).
Practically speaking, adding the clobbers is most likely a nop; the
primary motivation is to properly document VMXOFF's behavior.
For the flags clobber, both Clang and GCC automatically mark flags as
clobbered; this is noted in commit 4b1e54786e48 ("KVM/x86: Use assembly
instruction mnemonics instead of .byte streams"), which intentionally
removed the previous clobber. But, neither Clang nor GCC documents
this behavior, and there's no downside to including the clobber.
For the memory clobber, the RFLAGS.IF and CR4.VMXE manipulations that
immediately follow VMXOFF have compiler barriers of their own, i.e.
VMXOFF can't get reordered after clearing CR4.VMXE, which is really
what's of interest.
Cc: Randy Dunlap
Signed-off-by: David P. Reed
[sean: rewrote changelog, dropped comment adjustments]
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/virtext.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/virtext.h b/arch/x86/include/asm/virtext.h
index fda3e7747c22..2cc585467667 100644
--- a/arch/x86/include/asm/virtext.h
+++ b/arch/x86/include/asm/virtext.h
@@ -44,7 +44,8 @@ static inline int cpu_has_vmx(void)
static inline void cpu_vmxoff(void)
{
asm_volatile_goto("1: vmxoff\n\t"
- _ASM_EXTABLE(1b, %l[fault]) fault);
+ _ASM_EXTABLE(1b, %l[fault])
+ ::: "cc", "memory" : fault);
fault:
cr4_clear_bits(X86_CR4_VMXE);
}
--
2.29.2.729.g45daf8777d-goog
[PATCH 2/9] x86/reboot: Force all cpus to exit VMX root if VMX is supported
Force all CPUs to do VMXOFF (via NMI shootdown) during an emergency
reboot if VMX is _supported_, as VMX being off on the current CPU does
not prevent other CPUs from being in VMX root (post-VMXON). This fixes
a bug where a crash/panic reboot could leave other CPUs in VMX root and
prevent them from being woken via INIT-SIPI-SIPI in the new kernel.
Fixes: d176720d34c7 ("x86: disable VMX on all CPUs on reboot")
Cc: sta...@vger.kernel.org
Suggested-by: Sean Christopherson
Signed-off-by: David P. Reed
[sean: reworked changelog and further tweaked comment]
Signed-off-by: Sean Christopherson
---
arch/x86/kernel/reboot.c | 30 ++
1 file changed, 10 insertions(+), 20 deletions(-)
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index db115943e8bd..efbaef8b4de9 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -538,31 +538,21 @@ static void emergency_vmx_disable_all(void)
local_irq_disable();
/*
-* We need to disable VMX on all CPUs before rebooting, otherwise
-* we risk hanging up the machine, because the CPU ignores INIT
-* signals when VMX is enabled.
+* Disable VMX on all CPUs before rebooting, otherwise we risk hanging
+* the machine, because the CPU blocks INIT when it's in VMX root.
*
-* We can't take any locks and we may be on an inconsistent
-* state, so we use NMIs as IPIs to tell the other CPUs to disable
-* VMX and halt.
+* We can't take any locks and we may be on an inconsistent state, so
+* use NMIs as IPIs to tell the other CPUs to exit VMX root and halt.
*
-* For safety, we will avoid running the nmi_shootdown_cpus()
-* stuff unnecessarily, but we don't have a way to check
-* if other CPUs have VMX enabled. So we will call it only if the
-* CPU we are running on has VMX enabled.
-*
-* We will miss cases where VMX is not enabled on all CPUs. This
-* shouldn't do much harm because KVM always enable VMX on all
-* CPUs anyway. But we can miss it on the small window where KVM
-* is still enabling VMX.
+* Do the NMI shootdown even if VMX if off on _this_ CPU, as that
+* doesn't prevent a different CPU from being in VMX root operation.
*/
- if (cpu_has_vmx() && cpu_vmx_enabled()) {
- /* Disable VMX on this CPU. */
- cpu_vmxoff();
+ if (cpu_has_vmx()) {
+ /* Safely force _this_ CPU out of VMX root operation. */
+ __cpu_emergency_vmxoff();
- /* Halt and disable VMX on the other CPUs */
+ /* Halt and exit VMX root operation on the other CPUs. */
nmi_shootdown_cpus(vmxoff_nmi);
-
}
}
--
2.29.2.729.g45daf8777d-goog
[PATCH 1/9] x86/virt: Eat faults on VMXOFF in reboot flows
Silently ignore all faults on VMXOFF in the reboot flows as such faults
are all but guaranteed to be due to the CPU not being in VMX root.
Because (a) VMXOFF may be executed in NMI context, e.g. after VMXOFF but
before CR4.VMXE is cleared, (b) there's no way to query the CPU's VMX
state without faulting, and (c) the whole point is to get out of VMX
root, eating faults is the simplest way to achieve the desired behaior.
Technically, VMXOFF can fault (or fail) for other reasons, but all other
fault and failure scenarios are mode related, i.e. the kernel would have
to magically end up in RM, V86, compat mode, at CPL>0, or running with
the SMI Transfer Monitor active. The kernel is beyond hosed if any of
those scenarios are encountered; trying to do something fancy in the
error path to handle them cleanly is pointless.
Fixes: 1e9931146c74 ("x86: asm/virtext.h: add cpu_vmxoff() inline function")
Reported-by: David P. Reed
Cc: sta...@vger.kernel.org
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/virtext.h | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/arch/x86/include/asm/virtext.h b/arch/x86/include/asm/virtext.h
index 9aad0e0876fb..fda3e7747c22 100644
--- a/arch/x86/include/asm/virtext.h
+++ b/arch/x86/include/asm/virtext.h
@@ -30,15 +30,22 @@ static inline int cpu_has_vmx(void)
}
-/** Disable VMX on the current CPU
+/**
+ * cpu_vmxoff() - Disable VMX on the current CPU
*
- * vmxoff causes a undefined-opcode exception if vmxon was not run
- * on the CPU previously. Only call this function if you know VMX
- * is enabled.
+ * Disable VMX and clear CR4.VMXE (even if VMXOFF faults)
+ *
+ * Note, VMXOFF causes a #UD if the CPU is !post-VMXON, but it's impossible to
+ * atomically track post-VMXON state, e.g. this may be called in NMI context.
+ * Eat all faults as all other faults on VMXOFF faults are mode related, i.e.
+ * faults are guaranteed to be due to the !post-VMXON check unless the CPU is
+ * magically in RM, VM86, compat mode, or at CPL>0.
*/
static inline void cpu_vmxoff(void)
{
- asm volatile ("vmxoff");
+ asm_volatile_goto("1: vmxoff\n\t"
+ _ASM_EXTABLE(1b, %l[fault]) fault);
+fault:
cr4_clear_bits(X86_CR4_VMXE);
}
--
2.29.2.729.g45daf8777d-goog
[PATCH 0/9] x86/virt: KVM: x86: Exception handling fixes/cleanups
This series is a conglomeration of three previous series/patches and a bit
of new code. None of the previous series are directly related, but they
are all needed to achieve the overarching goal of nuking
__kvm_handle_fault_on_reboot(), which is a rather ugly inline asm macro
that has the unfortunate side effect of inserting in-line JMP+CALL
sequences.
Patches 1-3 are resurrected from a series by David Reed[1] to fix VMXOFF
bugs in the reboot flows.
Patch 4 is a patch from Uros Bizjak to get rid of custom inline asm in
nested VMX. This already received Paolo's "Queued, thanks." blessing,
but has not been pushed to kvm.git. It's included here as there is an
indirect dependency in patch 8.
Patches 5-6 are minor tweaks to KVM's VMX{ON/OFF} paths to use the
kernel's now-fault-tolerant VMXOFF instead of KVM's custom asm.
Patch 7 replaces SVM's __ex()/__kvm_handle_fault_on_reboot() with more
tailored asm goto macros, similar to the existing VMX asm_vmx*() macros.
This is largely an excuse to get rid of __kvm_handle_fault_on_reboot();
the actual benefits of removing JMP+CALL are likely negligible as SVM only
has a few uses of the macro (versus VMX's bajillion VMREADs/VMWRITEs).
Patch 8 removes __ex()/__kvm_handle_fault_on_reboot().
Patch 9 is a very trimmed down version of a different patch from Uros[3],
which cleaned up the __ex()/__kvm_handle_fault_on_reboot() code, as
opposed to zapping them entirely.
[1] https://lkml.kernel.org/r/20200704203809.76391-1-dpr...@deepplum.com
[2] https://lkml.kernel.org/r/20201029134145.107560-1-ubiz...@gmail.com
[3] https://lkml.kernel.org/r/20201221194800.46962-1-ubiz...@gmail.com
David P. Reed (1):
x86/virt: Mark flags and memory as clobbered by VMXOFF
Sean Christopherson (6):
x86/virt: Eat faults on VMXOFF in reboot flows
x86/reboot: Force all cpus to exit VMX root if VMX is supported
KVM: VMX: Move Intel PT shenanigans out of VMXON/VMXOFF flows
KVM: VMX: Use the kernel's version of VMXOFF
KVM: SVM: Use asm goto to handle unexpected #UD on SVM instructions
KVM: x86: Kill off __ex() and __kvm_handle_fault_on_reboot()
Uros Bizjak (2):
KVM/nVMX: Use __vmx_vcpu_run in nested_vmx_check_vmentry_hw
KVM: x86: Move declaration of kvm_spurious_fault() to x86.h
arch/x86/include/asm/kvm_host.h | 25 --
arch/x86/include/asm/virtext.h | 25 ++
arch/x86/kernel/reboot.c| 30 ++---
arch/x86/kvm/svm/sev.c | 5 ++-
arch/x86/kvm/svm/svm.c | 18 +-
arch/x86/kvm/svm/svm_ops.h | 59 +
arch/x86/kvm/vmx/nested.c | 32 ++
arch/x86/kvm/vmx/vmenter.S | 2 +-
arch/x86/kvm/vmx/vmx.c | 28 ++--
arch/x86/kvm/vmx/vmx.h | 1 +
arch/x86/kvm/vmx/vmx_ops.h | 4 +--
arch/x86/kvm/x86.c | 9 -
arch/x86/kvm/x86.h | 2 ++
13 files changed, 117 insertions(+), 123 deletions(-)
create mode 100644 arch/x86/kvm/svm/svm_ops.h
--
2.29.2.729.g45daf8777d-goog
Re: [PATCH 2/2] MIPS: Loongson64: Set cluster for cores
Reviewed-by: Huacai Chen On Wed, Dec 30, 2020 at 11:43 AM Jiaxun Yang wrote: > > cluster is required for cacheinfo to set shared_cpu_map correctly. > > Signed-off-by: Jiaxun Yang > Reviewed-by: Tiezhu Yang > Tested-by: Tiezhu Yang > --- > arch/mips/loongson64/smp.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/mips/loongson64/smp.c b/arch/mips/loongson64/smp.c > index e744e1bee49e..fae3a97d853c 100644 > --- a/arch/mips/loongson64/smp.c > +++ b/arch/mips/loongson64/smp.c > @@ -403,6 +403,8 @@ static void __init loongson3_smp_setup(void) > __cpu_number_map[i] = num; > __cpu_logical_map[num] = i; > set_cpu_possible(num, true); > + /* Loongson processors are always grouped by 4 */ > + cpu_set_cluster(_data[num], i / 4); > num++; > } > i++; > -- > 2.30.0 >
Re: [PATCH RESEND 1/2] MIPS: cacheinfo: Add missing VCache
Hi, Jiaxun,
On Wed, Dec 30, 2020 at 11:41 AM Jiaxun Yang wrote:
>
> Victim Cache is defined by Loongson as per-core unified
> private Cache.
> Add this into cacheinfo and make cache levels selfincrement
> instead of hardcode levels.
>
> Signed-off-by: Jiaxun Yang
> Reviewed-by: Tiezhu Yang
> Tested-by: Tiezhu Yang
> ---
> arch/mips/kernel/cacheinfo.c | 34 ++
> 1 file changed, 26 insertions(+), 8 deletions(-)
>
> diff --git a/arch/mips/kernel/cacheinfo.c b/arch/mips/kernel/cacheinfo.c
> index 47312c529410..83548331ee94 100644
> --- a/arch/mips/kernel/cacheinfo.c
> +++ b/arch/mips/kernel/cacheinfo.c
> @@ -35,6 +35,11 @@ static int __init_cache_level(unsigned int cpu)
>
> leaves += (c->icache.waysize) ? 2 : 1;
>
> + if (c->vcache.waysize) {
> + levels++;
> + leaves++;
> + }
> +
> if (c->scache.waysize) {
> levels++;
> leaves++;
> @@ -74,25 +79,38 @@ static int __populate_cache_leaves(unsigned int cpu)
> struct cpuinfo_mips *c = _cpu_data;
> struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
> struct cacheinfo *this_leaf = this_cpu_ci->info_list;
> + int level = 1;
>
> if (c->icache.waysize) {
> - /* L1 caches are per core */
> + /* D/I caches are per core */
It seems "I/D caches" is better than "D/I caches", see
arch/mips/include/asm/cpu-info.h and search cache_desc.
Huacai
> fill_cpumask_siblings(cpu, _leaf->shared_cpu_map);
> - populate_cache(dcache, this_leaf, 1, CACHE_TYPE_DATA);
> + populate_cache(dcache, this_leaf, level, CACHE_TYPE_DATA);
> fill_cpumask_siblings(cpu, _leaf->shared_cpu_map);
> - populate_cache(icache, this_leaf, 1, CACHE_TYPE_INST);
> + populate_cache(icache, this_leaf, level, CACHE_TYPE_INST);
> + level++;
> } else {
> - populate_cache(dcache, this_leaf, 1, CACHE_TYPE_UNIFIED);
> + populate_cache(dcache, this_leaf, level, CACHE_TYPE_UNIFIED);
> + level++;
> + }
> +
> + if (c->vcache.waysize) {
> + /* Vcache is per core as well */
> + fill_cpumask_siblings(cpu, _leaf->shared_cpu_map);
> + populate_cache(vcache, this_leaf, level, CACHE_TYPE_UNIFIED);
> + level++;
> }
>
> if (c->scache.waysize) {
> - /* L2 cache is per cluster */
> + /* Scache is per cluster */
> fill_cpumask_cluster(cpu, _leaf->shared_cpu_map);
> - populate_cache(scache, this_leaf, 2, CACHE_TYPE_UNIFIED);
> + populate_cache(scache, this_leaf, level, CACHE_TYPE_UNIFIED);
> + level++;
> }
>
> - if (c->tcache.waysize)
> - populate_cache(tcache, this_leaf, 3, CACHE_TYPE_UNIFIED);
> + if (c->tcache.waysize) {
> + populate_cache(tcache, this_leaf, level, CACHE_TYPE_UNIFIED);
> + level++;
> + }
>
> this_cpu_ci->cpu_map_populated = true;
>
> --
> 2.30.0
>
Re: [PATCH v2 2/2] arm64: dts: meson: add initial Beelink GS-King-X device-tree
On Wed, Dec 30, 2020 at 11:38 AM Christian Hewitt wrote: > > The Shenzen AZW (Beelink) GS-King-X is based on the Amlogic W400 reference > board with an S922X-H chip. > > - 4GB LPDDR4 RAM > - 64GB eMMC storage > - 10/100/1000 Base-T Ethernet > - AP6356S Wireless (802.11 a/b/g/n/ac, BT 4.1) > - HDMI 2.1 video > - S/PDIF optical output are you planning to enable this also? > - 2x ESS9018 audio DACs > - 4x Ricor RT6862 audio amps > - Analogue headphone output there's no driver for that DAC so I think that's why you are not enabling them > - 1x USB 2.0 OTG port > - 3x USB 3.0 ports > - IR receiver > - 1x micro SD card slot (internal) > - USB SATA controller with 2x 3.5" drive bays > - 1x Power on/off button > > Signed-off-by: Christian Hewitt I don't know/have this board but also I don't see anything problematic so: Acked-by: Martin Blumenstingl
Re: [PATCH v2 1/2] dt-bindings: arm: amlogic: add support for the Beelink GS-King-X
On Wed, Dec 30, 2020 at 11:38 AM Christian Hewitt wrote: > > The Shenzen AZW (Beelink) GS-King-X is based on the Amlogic W400 reference > board with an S922X-H chip. > > Signed-off-by: Christian Hewitt > Acked-by: Rob Herring Reviewed-by: Martin Blumenstingl
Re: [PATCH 2/3] scsi: megaraid_sas: check user-provided offsets
On Tue, Sep 08, 2020 at 11:36:22PM +0200, Arnd Bergmann wrote: > It sounds unwise to let user space pass an unchecked 32-bit > offset into a kernel structure in an ioctl. This is an unsigned > variable, so checking the upper bound for the size of the structure > it points into is sufficient to avoid data corruption, but as > the pointer might also be unaligned, it has to be written carefully > as well. > > While I stumbled over this problem by reading the code, I did not > continue checking the function for further problems like it. Sorry for replying to an ancient thread, but this patch just recently made it into 5.10.3 and has caused unintended consequences. On Dell servers with PERC RAID controllers, booting 5.10.3+ with this patch causes a PCI parity error. Specifically: Event Message: A PCI parity error was detected on a component at bus 0 device 5 function 0. Severity: Critical Message ID: PCI1308 I reverted this single patch and the errors went away. Thoughts? Phil Oester
Re: [RFC PATCH 3/3] gpio: ej1x8: Add GPIO driver for Etron Tech Inc. EJ168/EJ188/EJ198
Hi Linus, On Mon, Dec 21, 2020 at 4:28 PM Martin Blumenstingl wrote: > > Hi Linus, > > On Wed, Oct 7, 2020 at 9:44 PM Martin Blumenstingl > wrote: > [...] > > > As noted on the earlier patches I think this should be folded into the > > > existing XHCI USB driver in drivers/usb/host/xhci-pci.c or, if that > > > gets messy, as a separate bolt-on, something like > > > xhci-pci-gpio.[c|h] in the drivers/usb/host/* directory. > > > You can use a Kconfig symbol for the GPIO portions or not. > > OK, I will do that if there are no objections from other developers > > I am intending to place the relevant code in xhci-pci-etron.c, similar > > to what we already have with xhci-pci-renesas.c > I tried this and unfortunately there's a catch. > the nice thing about having a separate GPIO driver means that the > xhci-pci driver doesn't need to know about it. > > I implemented xhci-pci-etron.c and gave it a Kconfig option. > xhci-pci is then calling into xhci-pci-etron (through some > etron_xhci_pci_probe function). > unfortunately this means that xhci-pci now depends on xhci-pci-etron. > for xhci-pci-renesas this is fine (I think) because that part of the > code is needed to get the xHCI controller going > but for xhci-pci-etron this is a different story: the GPIO controller > is entirely optional and only used on few devices > > my goal is (at some point in the future) to have the GPIO driver in OpenWrt. > I am not sure if they would accept a patch where xhci-pci would then > pull in the dependencies for that Etron controller, even though most > boards don't need it. > > Please let me know if you have any idea on how to solve this. next week I have some free time to work on this I am still interested in any ideas that you have about this Best regards, Martin
Re: [PATCH v7 0/5] Introduce the Counter character device interface
On 12/25/20 6:15 PM, William Breathitt Gray wrote: Changes in v7: - Implemented u32 enums; enum types can now be used directly for callbacks and values - Fixed refcount underflow bug - Refactored all err check to check for err < 0; this should help prevent future oversights on valid positive return valids - Use mutex instead of raw_spin_lock in counter_chrdev_read(); kifo_to_user() can now safely sleep - Renamed COUNTER_COMPONENT_DUMMY to COUNTER_COMPONENT_NONE to make purpose more obvious - Introduced a watch_validate() callback - Consolidated the functionality to clear the watches to the counter_clear_watches() function - Reimplemented counter_push_event() as a void function; on error, errno is returned via struct counter_event so that it can be handled by userspace (because interrupt handlers can't do much for this) - Renamed the events_config() callback to events_configure(); "events_config" could be confused as a read callback when this is actually intended to configure the device for the requested events - Reimplemented 104-QUAD-8 driver to use events_configure() and watch_validate() callbacks; irq_trigger_enable sysfs attribute removed because events_configure() now serves this purpose The changes for this revision were much simpler compared to the previous revisions. I don't have any further questions for this patchset, so it's really just a search for possible bugs or regressions now. Please test and verify this patchset on your systems, and ACK appropriately. I'll wait for the next round to give my Reviewed-By, Tested-By but I've rebased my WIP TI eQEP changes[1] on this and I haven't ran into any problems yet. [1]: https://github.com/dlech/linux/commits/bone-counter
Re: [PATCH v7 1/5] counter: Internalize sysfs interface code
On 12/25/20 6:15 PM, William Breathitt Gray wrote:
diff --git a/drivers/counter/ti-eqep.c b/drivers/counter/ti-eqep.c
index a60aee1a1a29..6c058b93dc98 100644
--- a/drivers/counter/ti-eqep.c
+++ b/drivers/counter/ti-eqep.c
-static ssize_t ti_eqep_position_floor_write(struct counter_device *counter,
- struct counter_count *count,
- void *ext_priv, const char *buf,
- size_t len)
+static int ti_eqep_position_floor_write(struct counter_device *counter,
+ struct counter_count *count, u64 floor)
{
struct ti_eqep_cnt *priv = counter->priv;
- int err;
- u32 res;
- err = kstrtouint(buf, 0, );
- if (err < 0)
- return err;
+ if (floor != (u32)floor)
+ return -ERANGE;
- regmap_write(priv->regmap32, QPOSINIT, res);
+ regmap_write(priv->regmap32, QPOSINIT, floor);
- return len;
+ return 0;
}
This will conflict with 2ba7b50893de "counter:ti-eqep: remove floor"
(in Jonathan's fixes-togreg branch) which removes these functions.
discussion: re-structuring of the Amlogic Meson VPU DRM driver
Hi Neil and all interested people, in the past there were concerns about how some of the components are coupled in our Meson DRM driver(s). With this discussion I would like to achieve four things: 1. understand the current issues that we have 2. come up with a TODO list of things that need to be tackled as well as recommendations how to solve it (for example: "driver ABC function ABC uses the recommended way - take that as reference") 3. one by one work on the items on the TODO list 4. add support for the 32-bit SoCs to the Meson VPU DRM driver (without adding more "not recommended" code) Disclaimer: I am not familiar with the DRM subsystem - so apologies if the terminology is not correct. drivers/gpu/drm/meson/meson_dw_hdmi.c currently serves four purposes: 1. manage the TOP (glue) registers for the dw-hdmi IP This is Amlogic specific and consists of things like HPD filtering, some internal resets, etc. In my opinion this part is supposed to stay in this driver 2. load the driver for the dw-hdmi IP by calling dw_hdmi_probe() I read somewhere that this is not recommended anymore and should be replaced. Is my understanding correct and what is the recommended replacement? 3. it manages the HDMI PHY registers in the HHI register area For the 32-bit SoCs I will not follow this pattern and will create a separate PHY instead. As a long-term goal I think we should also move this into a dedicated PHY driver. 4. call back into VPU/VENC functions to set up these registers This is a blocker for 32-bit SoC support as I would have to duplicate this code if we don't make any changes. This includes things like calculating (and setting) clock frequencies, calling meson_venc_hdmi_mode_set for setting up the DVI pixel encoder, etc. My understanding is that this part should not be part of the meson_dw_hdmi driver, but "some other" driver. I don't understand which driver that's supposed to be though and how things would be wired up in the end. In addition to HDMI my understanding is that for adding MIPI DSI support you would a) either have to follow the pattern from the meson_dw_hdmi driver or b) also require some better way to achieve this The biggest question marks for me are #2 and #4 from the list above. Also is there anything I have missed? Any input, feedback and questions are welcome! PS: an additional topic on the TODO list will be "use the common clock framework" for clock setup. it's currently not clear to me if that's possible on the 64-bit SoCs in all cases. I will start a separate discussion for that topic after this one. Best regards, Martin
Re: [PATCH v6 3/8] power: supply: max8997_charger: Set CHARGER current limit
Hi Timon,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on regulator/for-next]
[also build test ERROR on pinctrl-samsung/for-next krzk/for-next v5.11-rc1
next-20201223]
[cannot apply to robh/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Timon-Baetz/extcon-max8997-Add-CHGINS-and-CHGRM-interrupt-handling/20201231-045812
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
for-next
config: arm-randconfig-r004-20201230 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
3c0d36f977d9e012b245c796ddc8596ac3af659b)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm cross compiling tool for clang build
# apt-get install binutils-arm-linux-gnueabi
#
https://github.com/0day-ci/linux/commit/3a597219bbfc1f9a0b65b9662b7b95bbb7cf728f
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Timon-Baetz/extcon-max8997-Add-CHGINS-and-CHGRM-interrupt-handling/20201231-045812
git checkout 3a597219bbfc1f9a0b65b9662b7b95bbb7cf728f
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/power/supply/max8997_charger.c:261:9: error: implicit declaration of
>> function 'devm_extcon_register_notifier_all'
>> [-Werror,-Wimplicit-function-declaration]
ret = devm_extcon_register_notifier_all(>dev,
charger->edev,
^
drivers/power/supply/max8997_charger.c:261:9: note: did you mean
'devm_extcon_register_notifier'?
include/linux/extcon.h:263:19: note: 'devm_extcon_register_notifier'
declared here
static inline int devm_extcon_register_notifier(struct device *dev,
^
1 error generated.
vim +/devm_extcon_register_notifier_all +261
drivers/power/supply/max8997_charger.c
165
166 static int max8997_battery_probe(struct platform_device *pdev)
167 {
168 int ret = 0;
169 struct charger_data *charger;
170 struct max8997_dev *iodev = dev_get_drvdata(pdev->dev.parent);
171 struct i2c_client *i2c = iodev->i2c;
172 struct max8997_platform_data *pdata = iodev->pdata;
173 struct power_supply_config psy_cfg = {};
174
175 if (!pdata) {
176 dev_err(>dev, "No platform data supplied.\n");
177 return -EINVAL;
178 }
179
180 if (pdata->eoc_mA) {
181 int val = (pdata->eoc_mA - 50) / 10;
182 if (val < 0)
183 val = 0;
184 if (val > 0xf)
185 val = 0xf;
186
187 ret = max8997_update_reg(i2c, MAX8997_REG_MBCCTRL5,
188 val << ITOPOFF_SHIFT, ITOPOFF_MASK);
189 if (ret < 0) {
190 dev_err(>dev, "Cannot use i2c bus.\n");
191 return ret;
192 }
193 }
194 switch (pdata->timeout) {
195 case 5:
196 ret = max8997_update_reg(i2c, MAX8997_REG_MBCCTRL1,
197 0x2 << TFCH_SHIFT, TFCH_MASK);
198 break;
199 case 6:
200 ret = max8997_update_reg(i2c, MAX8997_REG_MBCCTRL1,
201 0x3 << TFCH_SHIFT, TFCH_MASK);
202 break;
203 case 7:
204 ret = max8997_update_reg(i2c, MAX8997_REG_MBCCTRL1,
205 0x4 << TFCH_SHIFT, TFCH_MASK);
206 break;
207 case 0:
208 ret = max8997_update_reg(i2c, MAX8997_REG_MBCCTRL1,
209 0x7 << TFCH_SHIFT, TFCH_MASK);
210 break;
211 default:
212 dev_err(>dev, "incorrect timeout value (%d)\n",
213 pdata->timeout);
214 return -EINVAL;
215 }
216 if (ret < 0) {
217 dev_err(>dev, "Cannot use i2c bus.\n");
218 return ret;
219 }
220
221 c
[tip:master] BUILD SUCCESS ae0e95a3f49d2fe64920d6af3a85f409bb44e47b
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master branch HEAD: ae0e95a3f49d2fe64920d6af3a85f409bb44e47b Merge branch 'x86/cleanups' elapsed time: 725m configs tested: 127 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig m68k hp300_defconfig nios2alldefconfig pariscgeneric-32bit_defconfig powerpc wii_defconfig mips rbtx49xx_defconfig armspear3xx_defconfig arm imx_v4_v5_defconfig arm omap2plus_defconfig powerpc walnut_defconfig c6x alldefconfig arm colibri_pxa300_defconfig mips fuloong2e_defconfig powerpc ppc6xx_defconfig powerpc mpc83xx_defconfig mips lemote2f_defconfig arm imote2_defconfig sh se7722_defconfig x86_64 alldefconfig powerpc ksi8560_defconfig armtrizeps4_defconfig s390 zfcpdump_defconfig xtensaxip_kc705_defconfig powerpc mpc832x_rdb_defconfig shedosk7760_defconfig parisc allyesconfig powerpc iss476-smp_defconfig arm moxart_defconfig m68k atari_defconfig arm zx_defconfig sh ul2_defconfig umkunit_defconfig shsh7757lcr_defconfig powerpcmvme5100_defconfig mips malta_defconfig armu300_defconfig mips loongson1b_defconfig mips loongson1c_defconfig m68k sun3_defconfig mips ip22_defconfig powerpc ppc44x_defconfig powerpc akebono_defconfig h8300 h8s-sim_defconfig mips cu1830-neo_defconfig m68k amiga_defconfig powerpc mpc8560_ads_defconfig powerpc ppc40x_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a005-20201230 i386 randconfig-a006-20201230 i386 randconfig-a004-20201230 i386 randconfig-a003-20201230 i386 randconfig-a002-20201230 i386 randconfig-a001-20201230 x86_64 randconfig-a005-20201230 x86_64 randconfig-a001-20201230 x86_64 randconfig-a006-20201230 x86_64 randconfig-a002-20201230 x86_64 randconfig-a004-20201230 x86_64 randconfig-a003-20201230 i386 randconfig-a016-20201230 i386 randconfig-a014-20201230 i386 randconfig-a012-20201230 i386 randconfig-a015-20201230 i386 randconfig-a011-20201230 i386 randconfig-a013-20201230 riscv
Re: [PATCH 1/2] spi: rpc-if: Avoid use of C++ style comments
Hi Sergei, On Wed, Dec 30, 2020 at 4:27 PM Sergei Shtylyov wrote: > > On 12/30/20 5:57 PM, Lad Prabhakar wrote: > > > Replace C++ style comment with C style. > >Note that the switch to // was made following the SPI maintainer's > request... > Thanks for letting me know, let's drop this patch. Cheers, Prabhakar > > Signed-off-by: Lad Prabhakar > [...] > > MBR, Sergei
Re: [PATCH] ARM: avoid cpuidle link warning
On Wed, Dec 30, 2020 at 4:55 PM Arnd Bergmann wrote: > > Change the definition of CPUIDLE_METHOD_OF_DECLARE() to silently > drop the table and all code referenced from it when CONFIG_CPU_IDLE > is disabled. Re-Cc'ing Nick (Arnd's email had a wrong address). Cheers, Miguel
[PATCH v7 1/2] dt-bindings: power: Add the bq256xx dt bindings
Add the bindings for the bq256xx series of battery charging ICs.
Datasheets:
- https://www.ti.com/lit/ds/symlink/bq25600.pdf
- https://www.ti.com/lit/ds/symlink/bq25601.pdf
- https://www.ti.com/lit/ds/symlink/bq25600d.pdf
- https://www.ti.com/lit/ds/symlink/bq25601d.pdf
- https://www.ti.com/lit/ds/symlink/bq25611d.pdf
- https://www.ti.com/lit/ds/symlink/bq25618.pdf
- https://www.ti.com/lit/ds/symlink/bq25619.pdf
Reviewed-by: Rob Herring
Signed-off-by: Ricardo Rivera-Matos
v4 - documents monitored-battery and interrupts, fixes example for
ti,watchdog-timeout-ms
---
.../bindings/power/supply/bq256xx.yaml| 110 ++
1 file changed, 110 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/supply/bq256xx.yaml
diff --git a/Documentation/devicetree/bindings/power/supply/bq256xx.yaml
b/Documentation/devicetree/bindings/power/supply/bq256xx.yaml
new file mode 100644
index ..18b54783e11a
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/bq256xx.yaml
@@ -0,0 +1,110 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# Copyright (C) 2020 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/power/supply/bq256xx.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: TI bq256xx Switch Mode Buck Charger
+
+maintainers:
+ - Ricardo Rivera-Matos
+
+description: |
+ The bq256xx devices are a family of highly-integrated battery charge
+ management and system power management ICs for single cell Li-ion and Li-
+ polymer batteries.
+
+ Datasheets:
+- https://www.ti.com/lit/ds/symlink/bq25600.pdf
+- https://www.ti.com/lit/ds/symlink/bq25601.pdf
+- https://www.ti.com/lit/ds/symlink/bq25600d.pdf
+- https://www.ti.com/lit/ds/symlink/bq25601d.pdf
+- https://www.ti.com/lit/ds/symlink/bq25611d.pdf
+- https://www.ti.com/lit/ds/symlink/bq25618.pdf
+- https://www.ti.com/lit/ds/symlink/bq25619.pdf
+
+properties:
+ compatible:
+enum:
+ - ti,bq25600
+ - ti,bq25601
+ - ti,bq25600d
+ - ti,bq25601d
+ - ti,bq25611d
+ - ti,bq25618
+ - ti,bq25619
+
+ reg:
+maxItems: 1
+
+ ti,watchdog-timeout-ms:
+$ref: /schemas/types.yaml#/definitions/uint32
+default: 0
+description: |
+ Watchdog timer in ms. 0 (default) disables the watchdog
+minimum: 0
+maximum: 16
+enum: [ 0, 4, 8, 16]
+
+ input-voltage-limit-microvolt:
+description: |
+ Minimum input voltage limit in µV with a 10 µV step
+minimum: 390
+maximum: 540
+
+ input-current-limit-microamp:
+description: |
+ Maximum input current limit in µA with a 10 µA step
+minimum: 10
+maximum: 320
+
+ monitored-battery:
+$ref: /schemas/types.yaml#/definitions/phandle
+description: phandle to the battery node being monitored
+
+ interrupts:
+maxItems: 1
+description: |
+ Interrupt sends an active low, 256 μs pulse to host to report the charger
+ device status and faults.
+
+required:
+ - compatible
+ - reg
+ - monitored-battery
+
+additionalProperties: false
+
+examples:
+ - |
+bat: battery {
+ compatible = "simple-battery";
+ constant-charge-current-max-microamp = <204>;
+ constant-charge-voltage-max-microvolt = <4352000>;
+ precharge-current-microamp = <18>;
+ charge-term-current-microamp = <18>;
+};
+#include
+#include
+i2c {
+
+ clock-frequency = <40>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ charger@6b {
+compatible = "ti,bq25601";
+reg = <0x6b>;
+monitored-battery = <>;
+
+interrupt-parent = <>;
+interrupts = <16 IRQ_TYPE_EDGE_FALLING>;
+ti,watchdog-timeout-ms = <4>;
+
+input-voltage-limit-microvolt = <450>;
+input-current-limit-microamp = <240>;
+ };
+};
+...
--
2.28.0
[PATCH v7 0/2] Introduce the BQ256XX family of chargers
Hello, This patchset introduces the bq256xx family of charging ICs. The bq256xx ICs are highly integrated, buck, switching chargers intended for use in smartphones, tablets, and portable electronics. Ricardo Rivera-Matos (2): dt-bindings: power: Add the bq256xx dt bindings power: supply: bq256xx: Introduce the BQ256XX charger driver .../bindings/power/supply/bq256xx.yaml| 110 ++ drivers/power/supply/Kconfig | 11 + drivers/power/supply/Makefile |1 + drivers/power/supply/bq256xx_charger.c| 1747 + 4 files changed, 1869 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/supply/bq256xx.yaml create mode 100644 drivers/power/supply/bq256xx_charger.c -- 2.28.0
[PATCH v7 2/2] power: supply: bq256xx: Introduce the BQ256XX charger driver
The BQ256XX family of devices are highly integrated buck chargers for single cell batteries. Signed-off-by: Ricardo Rivera-Matos v5 - adds power_supply_put_battery_info() and devm_add_action_or_rest() calls v6 - implements bq256xx_remove function v7 - applies various fixes - implements clamp() API - implements memcmp() API - changes cache_type to REGACHE_FLAT - changes bq256xx_probe to properly unregister device Signed-off-by: Ricardo Rivera-Matos --- drivers/power/supply/Kconfig | 11 + drivers/power/supply/Makefile |1 + drivers/power/supply/bq256xx_charger.c | 1747 3 files changed, 1759 insertions(+) create mode 100644 drivers/power/supply/bq256xx_charger.c diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig index 44d3c8512fb8..87d852914bc2 100644 --- a/drivers/power/supply/Kconfig +++ b/drivers/power/supply/Kconfig @@ -618,6 +618,17 @@ config CHARGER_BQ25890 help Say Y to enable support for the TI BQ25890 battery charger. +config CHARGER_BQ256XX + tristate "TI BQ256XX battery charger driver" + depends on I2C + depends on GPIOLIB || COMPILE_TEST + select REGMAP_I2C + help + Say Y to enable support for the TI BQ256XX battery chargers. The + BQ256XX family of devices are highly-integrated, switch-mode battery + charge management and system power path management devices for single + cell Li-ion and Li-polymer batteries. + config CHARGER_SMB347 tristate "Summit Microelectronics SMB347 Battery Charger" depends on I2C diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile index b9644663e435..e762442c7cc6 100644 --- a/drivers/power/supply/Makefile +++ b/drivers/power/supply/Makefile @@ -83,6 +83,7 @@ obj-$(CONFIG_CHARGER_BQ24190) += bq24190_charger.o obj-$(CONFIG_CHARGER_BQ24257) += bq24257_charger.o obj-$(CONFIG_CHARGER_BQ24735) += bq24735-charger.o obj-$(CONFIG_CHARGER_BQ25890) += bq25890_charger.o +obj-$(CONFIG_CHARGER_BQ256XX) += bq256xx_charger.o obj-$(CONFIG_CHARGER_SMB347) += smb347-charger.o obj-$(CONFIG_CHARGER_TPS65090) += tps65090-charger.o obj-$(CONFIG_CHARGER_TPS65217) += tps65217_charger.o diff --git a/drivers/power/supply/bq256xx_charger.c b/drivers/power/supply/bq256xx_charger.c new file mode 100644 index ..4a5973524a70 --- /dev/null +++ b/drivers/power/supply/bq256xx_charger.c @@ -0,0 +1,1747 @@ +// SPDX-License-Identifier: GPL-2.0 +// BQ256XX Battery Charger Driver +// Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define BQ256XX_MANUFACTURER "Texas Instruments" + +#define BQ256XX_INPUT_CURRENT_LIMIT0x00 +#define BQ256XX_CHARGER_CONTROL_0 0x01 +#define BQ256XX_CHARGE_CURRENT_LIMIT 0x02 +#define BQ256XX_PRECHG_AND_TERM_CURR_LIM 0x03 +#define BQ256XX_BATTERY_VOLTAGE_LIMIT 0x04 +#define BQ256XX_CHARGER_CONTROL_1 0x05 +#define BQ256XX_CHARGER_CONTROL_2 0x06 +#define BQ256XX_CHARGER_CONTROL_3 0x07 +#define BQ256XX_CHARGER_STATUS_0 0x08 +#define BQ256XX_CHARGER_STATUS_1 0x09 +#define BQ256XX_CHARGER_STATUS_2 0x0a +#define BQ256XX_PART_INFORMATION 0x0b +#define BQ256XX_CHARGER_CONTROL_4 0x0c + +#define BQ256XX_IINDPM_MASKGENMASK(4, 0) +#define BQ256XX_IINDPM_STEP_uA 10 +#define BQ256XX_IINDPM_OFFSET_uA 10 +#define BQ256XX_IINDPM_MIN_uA 10 +#define BQ256XX_IINDPM_MAX_uA 320 +#define BQ256XX_IINDPM_DEF_uA 240 + +#define BQ256XX_VINDPM_MASKGENMASK(3, 0) +#define BQ256XX_VINDPM_STEP_uV 10 +#define BQ256XX_VINDPM_OFFSET_uV 390 +#define BQ256XX_VINDPM_MIN_uV 390 +#define BQ256XX_VINDPM_MAX_uV 540 +#define BQ256XX_VINDPM_DEF_uV 450 + +#define BQ256XX_VBATREG_MASK GENMASK(7, 3) +#define BQ2560X_VBATREG_STEP_uV32000 +#define BQ2560X_VBATREG_OFFSET_uV 3856000 +#define BQ2560X_VBATREG_MIN_uV 3856000 +#define BQ2560X_VBATREG_MAX_uV 4624000 +#define BQ2560X_VBATREG_DEF_uV 4208000 +#define BQ25601D_VBATREG_OFFSET_uV 3847000 +#define BQ25601D_VBATREG_MIN_uV3847000 +#define BQ25601D_VBATREG_MAX_uV4615000 +#define BQ25601D_VBATREG_DEF_uV4199000 +#define BQ2561X_VBATREG_STEP_uV1 +#define BQ25611D_VBATREG_MIN_uV3494000 +#define BQ25611D_VBATREG_MAX_uV451 +#define BQ25611D_VBATREG_DEF_uV419 +#define BQ25618_VBATREG_MIN_uV 3504000 +#define BQ25618_VBATREG_MAX_uV 450 +#define
Re: [PATCH] ARM: avoid cpuidle link warning
On Wed, Dec 30, 2020 at 4:55 PM Arnd Bergmann wrote: > > Change the definition of CPUIDLE_METHOD_OF_DECLARE() to silently > drop the table and all code referenced from it when CONFIG_CPU_IDLE > is disabled. Looks good, Reviewed-by: Miguel Ojeda Cheers, Miguel
Re: Time to re-enable Runtime PM per default for PCI devcies?
On 17.11.2020 17:57, Rafael J. Wysocki wrote:
> On Tue, Nov 17, 2020 at 5:38 PM Bjorn Helgaas wrote:
>>
>> [+to Rafael, author of the commit you mentioned,
>> +cc Mika, Kai Heng, Lukas, linux-pm, linux-kernel]
>>
>> On Tue, Nov 17, 2020 at 04:56:09PM +0100, Heiner Kallweit wrote:
>>> More than 10 yrs ago Runtime PM was disabled per default by bb910a7040
>>> ("PCI/PM Runtime: Make runtime PM of PCI devices inactive by default").
>>>
>>> Reason given: "avoid breakage on systems where ACPI-based wake-up is
>>> known to fail for some devices"
>>> Unfortunately the commit message doesn't mention any affected devices
>>> or systems.
>
> Even if it did that, it wouldn't have been a full list almost for sure.
>
> We had received multiple problem reports related to that, most likely
> because the ACPI PM in BIOSes at that time was tailored for
> system-wide PM transitions only.
>
>>> With Runtime PM disabled e.g. the PHY on network devices may remain
>>> powered up even with no cable plugged in, affecting battery lifetime
>>> on mobile devices. Currently we have to rely on the respective distro
>>> or user to enable Runtime PM via sysfs (echo auto > power/control).
>>> Some devices work around this restriction by calling pm_runtime_allow
>>> in their probe routine, even though that's not recommended by
>>> https://www.kernel.org/doc/Documentation/power/pci.txt
>>>
>>> Disabling Runtime PM per default seems to be a big hammer, a quirk
>>> for affected devices / systems may had been better. And we still
>>> have the option to disable Runtime PM for selected devices via sysfs.
>>>
>>> So, to cut a long story short: Wouldn't it be time to remove this
>>> restriction?
>>
>> I don't know the history of this, but maybe Rafael or the others can
>> shed some light on it.
>
> The systems that had those problems 10 years ago would still have
> them, but I expect there to be more systems where runtime PM can be
> enabled by default for PCI devices without issues.
>
As a proposal, maybe we can use the ACPI revision as an indicator for
whether ACPI implementation is new enough to not be affected by the old
problems. With the following simple patch runtime pm won't be disabled
per default for ACPI versions >= 6.0. AFAIK ACPI 6.0 was published in 2015.
On a side note:
It seems the sole motivation to disable runtime pm per default is ACPI
problems. So why do we disable runtime pm also on non-ACPI systems?
With the proposed patch runtime pm is enabled per default if
CONFIG_ACPI isn't defined.
---
drivers/pci/pci-acpi.c | 5 +
drivers/pci/pci.c | 4 +++-
drivers/pci/pci.h | 5 +
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
index 53502a751..265f5d2c4 100644
--- a/drivers/pci/pci-acpi.c
+++ b/drivers/pci/pci-acpi.c
@@ -27,6 +27,11 @@ const guid_t pci_acpi_dsm_guid =
GUID_INIT(0xe5c937d0, 0x3553, 0x4d7a,
0x91, 0x17, 0xea, 0x4d, 0x19, 0xc3, 0x43, 0x4d);
+bool pci_acpi_forbid_runtime_pm(void)
+{
+ return acpi_gbl_FADT.header.revision < 6;
+}
+
#if defined(CONFIG_PCI_QUIRKS) && defined(CONFIG_ARM64)
static int acpi_get_rc_addr(struct acpi_device *adev, struct resource *res)
{
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index b9fecc25d..83b5a7e63 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3024,7 +3024,9 @@ void pci_pm_init(struct pci_dev *dev)
u16 status;
u16 pmc;
- pm_runtime_forbid(>dev);
+ if (pci_acpi_forbid_runtime_pm())
+ pm_runtime_forbid(>dev);
+
pm_runtime_set_active(>dev);
pm_runtime_enable(>dev);
device_enable_async_suspend(>dev);
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 5c5936509..c1d521fb2 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -701,11 +701,16 @@ static inline int pci_aer_raw_clear_status(struct pci_dev
*dev) { return -EINVAL
#ifdef CONFIG_ACPI
int pci_acpi_program_hp_params(struct pci_dev *dev);
+bool pci_acpi_forbid_runtime_pm(void);
#else
static inline int pci_acpi_program_hp_params(struct pci_dev *dev)
{
return -ENODEV;
}
+static inline bool pci_acpi_forbid_runtime_pm(void)
+{
+ return false;
+}
#endif
#ifdef CONFIG_PCIEASPM
--
2.29.2
Re: [EXTERNAL] Re: [PATCH v6 2/2] power: supply: bq256xx: Introduce the BQ256XX charger driver
Sebastian, On 10/19/20 4:53 PM, Sebastian Reichel wrote: Hi Ricardo, On Mon, Oct 05, 2020 at 04:47:09PM -0500, Ricardo Rivera-Matos wrote: The BQ256XX family of devices are highly integrated buck chargers for single cell batteries. Signed-off-by: Ricardo Rivera-Matos v5 - adds power_supply_put_battery_info() and devm_add_action_or_rest() calls v6 - implements bq256xx_remove function v6 unfortunately makes things worse. You might want to read some background information about managed resources: https://lwn.net/Articles/222860/ https://www.kernel.org/doc/html/latest/driver-api/driver-model/devres.html ACK --- drivers/power/supply/Kconfig | 11 + drivers/power/supply/Makefile |1 + drivers/power/supply/bq256xx_charger.c | 1803 3 files changed, 1815 insertions(+) create mode 100644 drivers/power/supply/bq256xx_charger.c diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig index 44d3c8512fb8..87d852914bc2 100644 --- a/drivers/power/supply/Kconfig +++ b/drivers/power/supply/Kconfig @@ -618,6 +618,17 @@ config CHARGER_BQ25890 help Say Y to enable support for the TI BQ25890 battery charger. +config CHARGER_BQ256XX + tristate "TI BQ256XX battery charger driver" + depends on I2C + depends on GPIOLIB || COMPILE_TEST + select REGMAP_I2C + help + Say Y to enable support for the TI BQ256XX battery chargers. The + BQ256XX family of devices are highly-integrated, switch-mode battery + charge management and system power path management devices for single + cell Li-ion and Li-polymer batteries. + config CHARGER_SMB347 tristate "Summit Microelectronics SMB347 Battery Charger" depends on I2C diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile index b9644663e435..e762442c7cc6 100644 --- a/drivers/power/supply/Makefile +++ b/drivers/power/supply/Makefile @@ -83,6 +83,7 @@ obj-$(CONFIG_CHARGER_BQ24190) += bq24190_charger.o obj-$(CONFIG_CHARGER_BQ24257) += bq24257_charger.o obj-$(CONFIG_CHARGER_BQ24735) += bq24735-charger.o obj-$(CONFIG_CHARGER_BQ25890) += bq25890_charger.o +obj-$(CONFIG_CHARGER_BQ256XX) += bq256xx_charger.o obj-$(CONFIG_CHARGER_SMB347) += smb347-charger.o obj-$(CONFIG_CHARGER_TPS65090)+= tps65090-charger.o obj-$(CONFIG_CHARGER_TPS65217)+= tps65217_charger.o diff --git a/drivers/power/supply/bq256xx_charger.c b/drivers/power/supply/bq256xx_charger.c new file mode 100644 index ..b9caec10c456 --- /dev/null +++ b/drivers/power/supply/bq256xx_charger.c @@ -0,0 +1,1803 @@ +// SPDX-License-Identifier: GPL-2.0 +// BQ256XX Battery Charger Driver +// Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define BQ256XX_MANUFACTURER "Texas Instruments" + +#define BQ256XX_INPUT_CURRENT_LIMIT0x00 +#define BQ256XX_CHARGER_CONTROL_0 0x01 +#define BQ256XX_CHARGE_CURRENT_LIMIT 0x02 +#define BQ256XX_PRECHG_AND_TERM_CURR_LIM 0x03 +#define BQ256XX_BATTERY_VOLTAGE_LIMIT 0x04 +#define BQ256XX_CHARGER_CONTROL_1 0x05 +#define BQ256XX_CHARGER_CONTROL_2 0x06 +#define BQ256XX_CHARGER_CONTROL_3 0x07 +#define BQ256XX_CHARGER_STATUS_0 0x08 +#define BQ256XX_CHARGER_STATUS_1 0x09 +#define BQ256XX_CHARGER_STATUS_2 0x0a +#define BQ256XX_PART_INFORMATION 0x0b +#define BQ256XX_CHARGER_CONTROL_4 0x0c + +#define BQ256XX_IINDPM_MASKGENMASK(4, 0) +#define BQ256XX_IINDPM_STEP_uA 10 +#define BQ256XX_IINDPM_OFFSET_uA 10 +#define BQ256XX_IINDPM_MIN_uA 10 +#define BQ256XX_IINDPM_MAX_uA 320 +#define BQ256XX_IINDPM_DEF_uA 240 + +#define BQ256XX_VINDPM_MASKGENMASK(3, 0) +#define BQ256XX_VINDPM_STEP_uV 10 +#define BQ256XX_VINDPM_OFFSET_uV 390 +#define BQ256XX_VINDPM_MIN_uV 390 +#define BQ256XX_VINDPM_MAX_uV 540 +#define BQ256XX_VINDPM_DEF_uV 450 + +#define BQ256XX_VBATREG_MASK GENMASK(7, 3) +#define BQ2560X_VBATREG_STEP_uV32000 +#define BQ2560X_VBATREG_OFFSET_uV 3856000 +#define BQ2560X_VBATREG_MIN_uV 3856000 +#define BQ2560X_VBATREG_MAX_uV 4624000 +#define BQ2560X_VBATREG_DEF_uV 4208000 +#define BQ25601D_VBATREG_OFFSET_uV 3847000 +#define BQ25601D_VBATREG_MIN_uV3847000 +#define BQ25601D_VBATREG_MAX_uV4615000 +#define BQ25601D_VBATREG_DEF_uV4199000 +#define BQ2561X_VBATREG_STEP_uV1 +#define BQ25611D_VBATREG_MIN_uV3494000 +#define BQ25611D_VBATREG_MAX_uV451
[PATCH] neighbour: Disregard DEAD dst in neigh_update
In 4.x kernel a dst in DST_OBSOLETE_DEAD state is associated
with loopback net_device and leads to loopback neighbour. It
leads to an ethernet header with all zero addresses.
A very troubling case is working with mac80211 and ath9k.
A packet with all zero source MAC address to mac80211 will
eventually fail ieee80211_find_sta_by_ifaddr in ath9k (xmit.c).
As result, ath9k flushes tx queue (ath_tx_complete_aggr) without
updating baw (block ack window), damages baw logic and disables
transmission.
Signed-off-by: Tong Zhu
---
net/core/neighbour.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 6e890f51b7d8..e471c32e448f 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -1271,7 +1271,7 @@ int neigh_update(struct neighbour *neigh, const u8
*lladdr, u8 new,
* we can reinject the packet there.
*/
n2 = NULL;
- if (dst) {
+ if (dst && dst->obsolete != DST_OBSOLETE_DEAD) {
n2 = dst_neigh_lookup_skb(dst, skb);
if (n2)
n1 = n2;
--
2.17.1
Re: [PATCH 1/4] ARM: dts: qcom: msm8974: add gpu support
On Wed, Dec 30, 2020 at 05:51:29PM +0200, Iskren Chernev wrote: > From: Brian Masney > > Add support for the a3xx GPU > > Signed-off-by: Brian Masney Reviewed-by: Brian Masney
Re: [PATCH 1/2] drm/msm: Call msm_init_vram before binding the gpu
On Wed, Dec 30, 2020 at 05:29:42PM +0200, Iskren Chernev wrote: > From: Craig Tatlor > > vram.size is needed when binding a gpu without an iommu and is defined > in msm_init_vram(), so run that before binding it. > > Signed-off-by: Craig Tatlor For the series: Reviewed-by: Brian Masney Next time, please include a cover letter so that tags added to the cover letter can be applied to all patches in the series via patchwork. Brian
Re: [PATCH] xfs: Wake CIL push waiters more reliably
On Wed, Dec 30, 2020 at 12:56:27AM +0100, Donald Buczek wrote: > Threads, which committed items to the CIL, wait in the xc_push_wait > waitqueue when used_space in the push context goes over a limit. These > threads need to be woken when the CIL is pushed. > > The CIL push worker tries to avoid the overhead of calling wake_all() > when there are no waiters waiting. It does so by checking the same > condition which caused the waits to happen. This, however, is > unreliable, because ctx->space_used can actually decrease when items are > recommitted. When does this happen? Do you have tracing showing the operation where the relogged item has actually gotten smaller? By definition, relogging in the CIL should only grow the size of the object in the CIL because it must relog all the existing changes on top of the new changed being made to the object. Hence the CIL reservation should only ever grow. IOWs, returning negative lengths from the formatting code is unexpected and probably a bug and requires further investigation, not papering over the occurrence with broadcast wakeups... > If the value goes below the limit while some threads are > already waiting but before the push worker gets to it, these threads are > not woken. > > Always wake all CIL push waiters. Test with waitqueue_active() as an > optimization. This is possible, because we hold the xc_push_lock > spinlock, which prevents additions to the waitqueue. > > Signed-off-by: Donald Buczek > --- > fs/xfs/xfs_log_cil.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/xfs/xfs_log_cil.c b/fs/xfs/xfs_log_cil.c > index b0ef071b3cb5..d620de8e217c 100644 > --- a/fs/xfs/xfs_log_cil.c > +++ b/fs/xfs/xfs_log_cil.c > @@ -670,7 +670,7 @@ xlog_cil_push_work( > /* >* Wake up any background push waiters now this context is being pushed. >*/ > - if (ctx->space_used >= XLOG_CIL_BLOCKING_SPACE_LIMIT(log)) > + if (waitqueue_active(>xc_push_wait)) > wake_up_all(>xc_push_wait); That just smells wrong to me. It *might* be correct, but this condition should pair with the sleep condition, as space used by a CIL context should never actually decrease Cheers, Dave. -- Dave Chinner da...@fromorbit.com
Re: [PATCH] ibmvnic: fix: NULL pointer dereference.
On Wed, Dec 30, 2020 at 1:25 AM YANG LI wrote:
>
> The error is due to dereference a null pointer in function
> reset_one_sub_crq_queue():
>
> if (!scrq) {
> netdev_dbg(adapter->netdev,
>"Invalid scrq reset. irq (%d) or msgs(%p).\n",
> scrq->irq, scrq->msgs);
> return -EINVAL;
> }
>
> If the expression is true, scrq must be a null pointer and cannot
> dereference.
>
> Signed-off-by: YANG LI
> Reported-by: Abaci
> ---
Acked-by: Lijun Pan
Re: [PATCH] i3c/master/mipi-i3c-hci: re-fix __maybe_unused attribute
On 30/12/2020 14:43:21-0700, Nathan Chancellor wrote:
> On Wed, Dec 30, 2020 at 10:40:53PM +0100, Alexandre Belloni wrote:
> > On 30/12/2020 16:23:56-0500, Nicolas Pitre wrote:
> > > On Wed, 30 Dec 2020, Arnd Bergmann wrote:
> > >
> > > > From: Arnd Bergmann
> > > >
> > > > clang warns because the added __maybe_unused attribute is in
> > > > the wrong place:
> > > >
> > > > drivers/i3c/master/mipi-i3c-hci/core.c:780:21: error: attribute
> > > > declaration must precede definition [-Werror,-Wignored-attributes]
> > > > static const struct __maybe_unused of_device_id i3c_hci_of_match[] = {
> > > > ^
> > > > include/linux/compiler_attributes.h:267:56: note: expanded
> > > >
> > > > Fixes: 95393f3e07ab ("i3c/master/mipi-i3c-hci: quiet maybe-unused
> > > > variable warning")
> > > > Signed-off-by: Arnd Bergmann
> > >
> > > Acked-by: Nicolas Pitre
> > >
> > > This might be the 3rd patch from 3 different people fixing the same
> > > thing. Looks like I3C maintainer is on vacation. Please feel free to
> > > send this trivial fix upstream some other way.
> > >
> >
> > Isn't it already upstream?
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=95393f3e07ab53855b91881692a4a5b52dcdc03c
>
> This patch is fixing that one, the attribute was added between the
> struct type, causing a new warning for clang.
>
Ah yes, even after reading that 3 times, I got it wrong.
> I sent a fix for this earlier too, I do not care which one goes in as
> long as one does so:
>
> Reviewed-by: Nathan Chancellor
>
I was going to review and apply yours now that I have access to the i3c
repo. I must admit I didn't have a look at i3c patches until now and the
holiday season is not helping.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH 1/2] dm crypt: use GFP_ATOMIC when allocating crypto requests from softirq
Yes, good call! Reposted with allocation failure handling. Thanks, Ignat On Wed, Dec 30, 2020 at 6:11 PM Mikulas Patocka wrote: > > Hi > > This patch doesn't handle allocation failure gracefully. > > Mikulas > > > > On Tue, 29 Dec 2020, Ignat Korchagin wrote: > > > Commit 39d42fa96ba1b7d2544db3f8ed5da8fb0d5cb877 made it possible for some > > code > > paths in dm-crypt to be executed in softirq context, when the underlying > > driver > > processes IO requests in interrupt/softirq context. > > > > In this case sometimes when allocating a new crypto request we may get a > > stacktrace like below: > > > > [ 210.103008][C0] BUG: sleeping function called from invalid context > > at mm/mempool.c:381 > > [ 210.104746][C0] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, > > pid: 2602, name: fio > > [ 210.106599][C0] CPU: 0 PID: 2602 Comm: fio Tainted: GW > > 5.10.0+ #50 > > [ 210.108331][C0] Hardware name: QEMU Standard PC (i440FX + PIIX, > > 1996), BIOS 0.0.0 02/06/2015 > > [ 210.110212][C0] Call Trace: > > [ 210.110921][C0] > > [ 210.111527][C0] dump_stack+0x7d/0xa3 > > [ 210.112411][C0] ___might_sleep.cold+0x122/0x151 > > [ 210.113527][C0] mempool_alloc+0x16b/0x2f0 > > [ 210.114524][C0] ? __queue_work+0x515/0xde0 > > [ 210.115553][C0] ? mempool_resize+0x700/0x700 > > [ 210.116586][C0] ? crypt_endio+0x91/0x180 > > [ 210.117479][C0] ? blk_update_request+0x757/0x1150 > > [ 210.118513][C0] ? blk_mq_end_request+0x4b/0x480 > > [ 210.119572][C0] ? blk_done_softirq+0x21d/0x340 > > [ 210.120628][C0] ? __do_softirq+0x190/0x611 > > [ 210.121626][C0] crypt_convert+0x29f9/0x4c00 > > [ 210.122668][C0] ? _raw_spin_lock_irqsave+0x87/0xe0 > > [ 210.123824][C0] ? kasan_set_track+0x1c/0x30 > > [ 210.124858][C0] ? crypt_iv_tcw_ctr+0x4a0/0x4a0 > > [ 210.125930][C0] ? kmem_cache_free+0x104/0x470 > > [ 210.126973][C0] ? crypt_endio+0x91/0x180 > > [ 210.127947][C0] kcryptd_crypt_read_convert+0x30e/0x420 > > [ 210.129165][C0] blk_update_request+0x757/0x1150 > > [ 210.130231][C0] blk_mq_end_request+0x4b/0x480 > > [ 210.131294][C0] blk_done_softirq+0x21d/0x340 > > [ 210.132332][C0] ? _raw_spin_lock+0x81/0xd0 > > [ 210.133289][C0] ? blk_mq_stop_hw_queue+0x30/0x30 > > [ 210.134399][C0] ? _raw_read_lock_irq+0x40/0x40 > > [ 210.135458][C0] __do_softirq+0x190/0x611 > > [ 210.136409][C0] ? handle_edge_irq+0x221/0xb60 > > [ 210.137447][C0] asm_call_irq_on_stack+0x12/0x20 > > [ 210.138507][C0] > > [ 210.139118][C0] do_softirq_own_stack+0x37/0x40 > > [ 210.140191][C0] irq_exit_rcu+0x110/0x1b0 > > [ 210.141151][C0] common_interrupt+0x74/0x120 > > [ 210.142171][C0] asm_common_interrupt+0x1e/0x40 > > [ 210.143206][C0] RIP: 0010:_aesni_enc1+0x65/0xb0 > > [ 210.144313][C0] Code: 38 dc c2 41 0f 28 52 d0 66 0f 38 dc c2 41 0f > > 28 52 e0 66 0f 38 dc c2 41 0f 28 52 f0 66 0f 38 dc c2 41 0f 28 12 66 0f 38 > > dc c2 <41> 0f 28 52 10 66 0f 38 dc c2 41 0f 28 52 20 66 0f 38 dc c2 41 0f > > [ 210.148542][C0] RSP: 0018:88810dbe6db0 EFLAGS: 0286 > > [ 210.149842][C0] RAX: 9a90cdc0 RBX: RCX: > > 0200 > > [ 210.151576][C0] RDX: 888101e5f240 RSI: 888101e5f240 RDI: > > 888b5020 > > [ 210.153339][C0] RBP: 88810dbe6e20 R08: R09: > > 0020 > > [ 210.155063][C0] R10: 888b5090 R11: 111021b7cdcc R12: > > 9e87cd40 > > [ 210.156791][C0] R13: 888b5210 R14: 888101e5f0d8 R15: > > > > [ 210.158497][C0] ? aesni_set_key+0x1e0/0x1e0 > > [ 210.159523][C0] ? aesni_enc+0xf/0x20 > > [ 210.160408][C0] ? glue_xts_req_128bit+0x181/0x6f0 > > [ 210.161571][C0] ? aesni_set_key+0x1e0/0x1e0 > > [ 210.162560][C0] ? glue_ctr_req_128bit+0x630/0x630 > > [ 210.163706][C0] ? kasan_save_stack+0x37/0x50 > > [ 210.164761][C0] ? kasan_save_stack+0x20/0x50 > > [ 210.165786][C0] ? get_page_from_freelist+0x2052/0x36a0 > > [ 210.167024][C0] ? __blkdev_direct_IO_simple+0x43b/0x7e0 > > [ 210.168288][C0] ? blkdev_direct_IO+0xd16/0x1020 > > [ 210.169396][C0] ? generic_file_direct_write+0x1a3/0x480 > > [ 210.170648][C0] ? __generic_file_write_iter+0x1d9/0x530 > > [ 210.171882][C0] ? blkdev_write_iter+0x20d/0x3e0 > > [ 210.172954][C0] ? vfs_write+0x524/0x770 > > [ 210.173889][C0] ? do_syscall_64+0x33/0x40 > > [ 210.174859][C0] ? __zone_watermark_ok+0x340/0x340 > > [ 210.175977][C0] ? crypt_convert+0x28b6/0x4c00 > > [ 210.177079][C0] ? mempool_alloc+0x107/0x2f0 > > [ 210.178096][C0] ? crypt_iv_tcw_ctr+0x4a0/0x4a0 > > [ 210.179193][C0] ? bio_add_page+0x111/0x170 > > [ 210.180251][C0] ? __bio_try_merge_page+0x480/0x480 > > [ 210.181446][C0] ?
[PATCH v2 2/2] dm crypt: do not wait for backlogged crypto request completion in softirq
Commit 39d42fa96ba1b7d2544db3f8ed5da8fb0d5cb877 made it possible for some code
paths in dm-crypt to be executed in softirq context, when the underlying driver
processes IO requests in interrupt/softirq context.
When Crypto API backlogs a crypto request, dm-crypt uses wait_for_completion to
avoid sending further requests to an already overloaded crypto driver. However,
if the code is executing in softirq context, we might get the following
stacktrace:
[ 210.235213][C0] BUG: scheduling while atomic: fio/2602/0x0102
[ 210.236701][C0] Modules linked in:
[ 210.237566][C0] CPU: 0 PID: 2602 Comm: fio Tainted: GW
5.10.0+ #50
[ 210.239292][C0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 0.0.0 02/06/2015
[ 210.241233][C0] Call Trace:
[ 210.241946][C0]
[ 210.242561][C0] dump_stack+0x7d/0xa3
[ 210.243466][C0] __schedule_bug.cold+0xb3/0xc2
[ 210.244539][C0] __schedule+0x156f/0x20d0
[ 210.245518][C0] ? io_schedule_timeout+0x140/0x140
[ 210.246660][C0] schedule+0xd0/0x270
[ 210.247541][C0] schedule_timeout+0x1fb/0x280
[ 210.248586][C0] ? usleep_range+0x150/0x150
[ 210.249624][C0] ? unpoison_range+0x3a/0x60
[ 210.250632][C0] ? kasan_kmalloc.constprop.0+0x82/0xa0
[ 210.251949][C0] ? unpoison_range+0x3a/0x60
[ 210.252958][C0] ? __prepare_to_swait+0xa7/0x190
[ 210.254067][C0] do_wait_for_common+0x2ab/0x370
[ 210.255158][C0] ? usleep_range+0x150/0x150
[ 210.256192][C0] ? bit_wait_io_timeout+0x160/0x160
[ 210.257358][C0] ? blk_update_request+0x757/0x1150
[ 210.258582][C0] ? _raw_spin_lock_irq+0x82/0xd0
[ 210.259674][C0] ? _raw_read_unlock_irqrestore+0x30/0x30
[ 210.260917][C0] wait_for_completion+0x4c/0x90
[ 210.261971][C0] crypt_convert+0x19a6/0x4c00
[ 210.263033][C0] ? _raw_spin_lock_irqsave+0x87/0xe0
[ 210.264193][C0] ? kasan_set_track+0x1c/0x30
[ 210.265191][C0] ? crypt_iv_tcw_ctr+0x4a0/0x4a0
[ 210.266283][C0] ? kmem_cache_free+0x104/0x470
[ 210.267363][C0] ? crypt_endio+0x91/0x180
[ 210.268327][C0] kcryptd_crypt_read_convert+0x30e/0x420
[ 210.269565][C0] blk_update_request+0x757/0x1150
[ 210.270563][C0] blk_mq_end_request+0x4b/0x480
[ 210.271680][C0] blk_done_softirq+0x21d/0x340
[ 210.272775][C0] ? _raw_spin_lock+0x81/0xd0
[ 210.273847][C0] ? blk_mq_stop_hw_queue+0x30/0x30
[ 210.275031][C0] ? _raw_read_lock_irq+0x40/0x40
[ 210.276182][C0] __do_softirq+0x190/0x611
[ 210.277203][C0] ? handle_edge_irq+0x221/0xb60
[ 210.278340][C0] asm_call_irq_on_stack+0x12/0x20
[ 210.279514][C0]
[ 210.280164][C0] do_softirq_own_stack+0x37/0x40
[ 210.281281][C0] irq_exit_rcu+0x110/0x1b0
[ 210.282286][C0] common_interrupt+0x74/0x120
[ 210.283376][C0] asm_common_interrupt+0x1e/0x40
[ 210.284496][C0] RIP: 0010:_aesni_enc1+0x65/0xb0
Fix this by making crypt_convert function reentrant from the point of a single
bio and make dm-crypt defer further bio processing to a workqueue, if Crypto API
backlogs a request in interrupt context.
Fixes: 39d42fa96ba1 ("dm crypt: add flags to optionally bypass kcryptd workq
ueues")
Cc: # v5.9+
Signed-off-by: Ignat Korchagin
---
drivers/md/dm-crypt.c | 102 +++---
1 file changed, 97 insertions(+), 5 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index e4fd690c70e1..0d939fbe51af 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -1539,13 +1539,19 @@ static void crypt_free_req(struct crypt_config *cc,
void *req, struct bio *base_
* Encrypt / decrypt data from one bio to another one (can be the same one)
*/
static blk_status_t crypt_convert(struct crypt_config *cc,
-struct convert_context *ctx, bool atomic)
+struct convert_context *ctx, bool atomic, bool
reset_pending)
{
unsigned int tag_offset = 0;
unsigned int sector_step = cc->sector_size >> SECTOR_SHIFT;
int r;
- atomic_set(>cc_pending, 1);
+ /*
+* if reset_pending is set we are dealing with the bio for the first
time,
+* else we're continuing to work on the previous bio, so don't mess with
+* the cc_pending counter
+*/
+ if (reset_pending)
+ atomic_set(>cc_pending, 1);
while (ctx->iter_in.bi_size && ctx->iter_out.bi_size) {
@@ -1566,7 +1572,24 @@ static blk_status_t crypt_convert(struct crypt_config
*cc,
* but the driver request queue is full, let's wait.
*/
case -EBUSY:
- wait_for_completion(>restart);
+ if (in_interrupt()) {
+ if (try_wait_for_completion(>restart)) {
+ /*
+* we don't have to block to wait for
[PATCH v2 0/2] dm crypt: some fixes to support dm-crypt running in softirq context
Changes from v1: 0001: Handle memory allocation failure for GFP_ATOMIC Ignat Korchagin (2): dm crypt: use GFP_ATOMIC when allocating crypto requests from softirq dm crypt: do not wait for backlogged crypto request completion in softirq drivers/md/dm-crypt.c | 135 +- 1 file changed, 120 insertions(+), 15 deletions(-) -- 2.20.1
[PATCH v2 1/2] dm crypt: use GFP_ATOMIC when allocating crypto requests from softirq
Commit 39d42fa96ba1b7d2544db3f8ed5da8fb0d5cb877 made it possible for some code paths in dm-crypt to be executed in softirq context, when the underlying driver processes IO requests in interrupt/softirq context. In this case sometimes when allocating a new crypto request we may get a stacktrace like below: [ 210.103008][C0] BUG: sleeping function called from invalid context at mm/mempool.c:381 [ 210.104746][C0] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2602, name: fio [ 210.106599][C0] CPU: 0 PID: 2602 Comm: fio Tainted: GW 5.10.0+ #50 [ 210.108331][C0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 [ 210.110212][C0] Call Trace: [ 210.110921][C0] [ 210.111527][C0] dump_stack+0x7d/0xa3 [ 210.112411][C0] ___might_sleep.cold+0x122/0x151 [ 210.113527][C0] mempool_alloc+0x16b/0x2f0 [ 210.114524][C0] ? __queue_work+0x515/0xde0 [ 210.115553][C0] ? mempool_resize+0x700/0x700 [ 210.116586][C0] ? crypt_endio+0x91/0x180 [ 210.117479][C0] ? blk_update_request+0x757/0x1150 [ 210.118513][C0] ? blk_mq_end_request+0x4b/0x480 [ 210.119572][C0] ? blk_done_softirq+0x21d/0x340 [ 210.120628][C0] ? __do_softirq+0x190/0x611 [ 210.121626][C0] crypt_convert+0x29f9/0x4c00 [ 210.122668][C0] ? _raw_spin_lock_irqsave+0x87/0xe0 [ 210.123824][C0] ? kasan_set_track+0x1c/0x30 [ 210.124858][C0] ? crypt_iv_tcw_ctr+0x4a0/0x4a0 [ 210.125930][C0] ? kmem_cache_free+0x104/0x470 [ 210.126973][C0] ? crypt_endio+0x91/0x180 [ 210.127947][C0] kcryptd_crypt_read_convert+0x30e/0x420 [ 210.129165][C0] blk_update_request+0x757/0x1150 [ 210.130231][C0] blk_mq_end_request+0x4b/0x480 [ 210.131294][C0] blk_done_softirq+0x21d/0x340 [ 210.132332][C0] ? _raw_spin_lock+0x81/0xd0 [ 210.133289][C0] ? blk_mq_stop_hw_queue+0x30/0x30 [ 210.134399][C0] ? _raw_read_lock_irq+0x40/0x40 [ 210.135458][C0] __do_softirq+0x190/0x611 [ 210.136409][C0] ? handle_edge_irq+0x221/0xb60 [ 210.137447][C0] asm_call_irq_on_stack+0x12/0x20 [ 210.138507][C0] [ 210.139118][C0] do_softirq_own_stack+0x37/0x40 [ 210.140191][C0] irq_exit_rcu+0x110/0x1b0 [ 210.141151][C0] common_interrupt+0x74/0x120 [ 210.142171][C0] asm_common_interrupt+0x1e/0x40 [ 210.143206][C0] RIP: 0010:_aesni_enc1+0x65/0xb0 [ 210.144313][C0] Code: 38 dc c2 41 0f 28 52 d0 66 0f 38 dc c2 41 0f 28 52 e0 66 0f 38 dc c2 41 0f 28 52 f0 66 0f 38 dc c2 41 0f 28 12 66 0f 38 dc c2 <41> 0f 28 52 10 66 0f 38 dc c2 41 0f 28 52 20 66 0f 38 dc c2 41 0f [ 210.148542][C0] RSP: 0018:88810dbe6db0 EFLAGS: 0286 [ 210.149842][C0] RAX: 9a90cdc0 RBX: RCX: 0200 [ 210.151576][C0] RDX: 888101e5f240 RSI: 888101e5f240 RDI: 888b5020 [ 210.153339][C0] RBP: 88810dbe6e20 R08: R09: 0020 [ 210.155063][C0] R10: 888b5090 R11: 111021b7cdcc R12: 9e87cd40 [ 210.156791][C0] R13: 888b5210 R14: 888101e5f0d8 R15: [ 210.158497][C0] ? aesni_set_key+0x1e0/0x1e0 [ 210.159523][C0] ? aesni_enc+0xf/0x20 [ 210.160408][C0] ? glue_xts_req_128bit+0x181/0x6f0 [ 210.161571][C0] ? aesni_set_key+0x1e0/0x1e0 [ 210.162560][C0] ? glue_ctr_req_128bit+0x630/0x630 [ 210.163706][C0] ? kasan_save_stack+0x37/0x50 [ 210.164761][C0] ? kasan_save_stack+0x20/0x50 [ 210.165786][C0] ? get_page_from_freelist+0x2052/0x36a0 [ 210.167024][C0] ? __blkdev_direct_IO_simple+0x43b/0x7e0 [ 210.168288][C0] ? blkdev_direct_IO+0xd16/0x1020 [ 210.169396][C0] ? generic_file_direct_write+0x1a3/0x480 [ 210.170648][C0] ? __generic_file_write_iter+0x1d9/0x530 [ 210.171882][C0] ? blkdev_write_iter+0x20d/0x3e0 [ 210.172954][C0] ? vfs_write+0x524/0x770 [ 210.173889][C0] ? do_syscall_64+0x33/0x40 [ 210.174859][C0] ? __zone_watermark_ok+0x340/0x340 [ 210.175977][C0] ? crypt_convert+0x28b6/0x4c00 [ 210.177079][C0] ? mempool_alloc+0x107/0x2f0 [ 210.178096][C0] ? crypt_iv_tcw_ctr+0x4a0/0x4a0 [ 210.179193][C0] ? bio_add_page+0x111/0x170 [ 210.180251][C0] ? __bio_try_merge_page+0x480/0x480 [ 210.181446][C0] ? bio_associate_blkg+0x6d/0x100 [ 210.182558][C0] ? kcryptd_crypt_write_convert+0x5ea/0x980 [ 210.183852][C0] ? crypt_map+0x5bf/0xc80 [ 210.184838][C0] ? bio_clone_blkg_association+0x10e/0x2c0 [ 210.186125][C0] ? __map_bio.isra.0+0x109/0x3f0 [ 210.187204][C0] ? __split_and_process_non_flush+0x7f9/0xc50 [ 210.188560][C0] ? __send_empty_flush+0x2d0/0x2d0 [ 210.189697][C0] ? __part_start_io_acct+0x70/0x2d0 [ 210.190842][C0] ? dm_submit_bio+0x4d8/0xe40 [ 210.191845][C0] ? __split_and_process_non_flush+0xc50/0xc50 [ 210.193201][C0] ? submit_bio_noacct+0x2b9/0xe50 [
Re: [PATCH] i3c/master/mipi-i3c-hci: re-fix __maybe_unused attribute
On Wed, Dec 30, 2020 at 10:40:53PM +0100, Alexandre Belloni wrote:
> On 30/12/2020 16:23:56-0500, Nicolas Pitre wrote:
> > On Wed, 30 Dec 2020, Arnd Bergmann wrote:
> >
> > > From: Arnd Bergmann
> > >
> > > clang warns because the added __maybe_unused attribute is in
> > > the wrong place:
> > >
> > > drivers/i3c/master/mipi-i3c-hci/core.c:780:21: error: attribute
> > > declaration must precede definition [-Werror,-Wignored-attributes]
> > > static const struct __maybe_unused of_device_id i3c_hci_of_match[] = {
> > > ^
> > > include/linux/compiler_attributes.h:267:56: note: expanded
> > >
> > > Fixes: 95393f3e07ab ("i3c/master/mipi-i3c-hci: quiet maybe-unused
> > > variable warning")
> > > Signed-off-by: Arnd Bergmann
> >
> > Acked-by: Nicolas Pitre
> >
> > This might be the 3rd patch from 3 different people fixing the same
> > thing. Looks like I3C maintainer is on vacation. Please feel free to
> > send this trivial fix upstream some other way.
> >
>
> Isn't it already upstream?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=95393f3e07ab53855b91881692a4a5b52dcdc03c
This patch is fixing that one, the attribute was added between the
struct type, causing a new warning for clang.
I sent a fix for this earlier too, I do not care which one goes in as
long as one does so:
Reviewed-by: Nathan Chancellor
Cheers,
Nathan
Re: [PATCH] i3c/master/mipi-i3c-hci: re-fix __maybe_unused attribute
On 30/12/2020 16:23:56-0500, Nicolas Pitre wrote:
> On Wed, 30 Dec 2020, Arnd Bergmann wrote:
>
> > From: Arnd Bergmann
> >
> > clang warns because the added __maybe_unused attribute is in
> > the wrong place:
> >
> > drivers/i3c/master/mipi-i3c-hci/core.c:780:21: error: attribute declaration
> > must precede definition [-Werror,-Wignored-attributes]
> > static const struct __maybe_unused of_device_id i3c_hci_of_match[] = {
> > ^
> > include/linux/compiler_attributes.h:267:56: note: expanded
> >
> > Fixes: 95393f3e07ab ("i3c/master/mipi-i3c-hci: quiet maybe-unused variable
> > warning")
> > Signed-off-by: Arnd Bergmann
>
> Acked-by: Nicolas Pitre
>
> This might be the 3rd patch from 3 different people fixing the same
> thing. Looks like I3C maintainer is on vacation. Please feel free to
> send this trivial fix upstream some other way.
>
Isn't it already upstream?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=95393f3e07ab53855b91881692a4a5b52dcdc03c
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[PATCH] getcpu.2: Document glibc wrapper instead of kernel syscall
The glibc wrapper doesn't provide the third argument.
Simplify the info about the (unused) kernel parameter
to the minimum that is useful.
kernels <=2.6.23 are EOL since a long time ago.
The old info is commented out instead of removed.
..
$ syscall='getcpu';
$ ret='int';
$ find glibc/ -type f -name '*.h' \
|xargs pcregrep -Mn "(?s)^[\w\s]*${ret}\s*${syscall}\s*\(.*?;";
glibc/sysdeps/unix/sysv/linux/bits/sched.h:92:
extern int getcpu (unsigned int *, unsigned int *) __THROW;
Signed-off-by: Alejandro Colomar
---
man2/getcpu.2 | 55 ---
1 file changed, 30 insertions(+), 25 deletions(-)
diff --git a/man2/getcpu.2 b/man2/getcpu.2
index 46e4d53ff..a9588119b 100644
--- a/man2/getcpu.2
+++ b/man2/getcpu.2
@@ -16,8 +16,7 @@ getcpu \- determine CPU and NUMA node on which the calling
thread is running
.nf
.B #include
.PP
-.BI "int getcpu(unsigned int *" cpu ", unsigned int *" node ,
-.BI " struct getcpu_cache *" tcache );
+.BI "int getcpu(unsigned int *" cpu ", unsigned int *" node );
.fi
.SH DESCRIPTION
The
@@ -36,10 +35,10 @@ When either
or
.I node
is NULL nothing is written to the respective pointer.
-.PP
-The third argument to this system call is nowadays unused,
-and should be specified as NULL
-unless portability to Linux 2.6.23 or earlier is required (see NOTES).
+.\" .PP
+.\" The third argument to this system call is nowadays unused,
+.\" and should be specified as NULL
+.\" unless portability to Linux 2.6.23 or earlier is required (see NOTES).
.PP
The information placed in
.I cpu
@@ -71,6 +70,12 @@ Library support was added in glibc 2.29
(Earlier glibc versions did not provide a wrapper for this system call,
necessitating the use of
.BR syscall (2).)
+.PP
+The Linux system call has a third argument
+.IR tcache ,
+which since kernel 2.6.24 is ignored.
+It should be specified as NULL.
+The glibc wrapper hides that parameter.
.SH CONFORMING TO
.BR getcpu ()
is Linux-specific.
@@ -82,25 +87,25 @@ The intention of
.BR getcpu ()
is to allow programs to make optimizations with per-CPU data
or for NUMA optimization.
-.PP
-The
-.I tcache
-argument is unused since Linux 2.6.24.
-.\" commit 4307d1e5ada595c87f9a4d16db16ba5edb70dcb1
-.\" Author: Ingo Molnar
-.\" Date: Wed Nov 7 18:37:48 2007 +0100
-.\" x86: ignore the sys_getcpu() tcache parameter
-In earlier kernels,
-if this argument was non-NULL,
-then it specified a pointer to a caller-allocated buffer in thread-local
-storage that was used to provide a caching mechanism for
-.BR getcpu ().
-Use of the cache could speed
-.BR getcpu ()
-calls, at the cost that there was a very small chance that
-the returned information would be out of date.
-The caching mechanism was considered to cause problems when
-migrating threads between CPUs, and so the argument is now ignored.
+.\" .PP
+.\" The
+.\" .I tcache
+.\" argument is unused since Linux 2.6.24.
+.\" .\" commit 4307d1e5ada595c87f9a4d16db16ba5edb70dcb1
+.\" .\" Author: Ingo Molnar
+.\" .\" Date: Wed Nov 7 18:37:48 2007 +0100
+.\" .\" x86: ignore the sys_getcpu() tcache parameter
+.\" In earlier kernels,
+.\" if this argument was non-NULL,
+.\" then it specified a pointer to a caller-allocated buffer in thread-local
+.\" storage that was used to provide a caching mechanism for
+.\" .BR getcpu ().
+.\" Use of the cache could speed
+.\" .BR getcpu ()
+.\" calls, at the cost that there was a very small chance that
+.\" the returned information would be out of date.
+.\" The caching mechanism was considered to cause problems when
+.\" migrating threads between CPUs, and so the argument is now ignored.
.\"
.\" = Before kernel 2.6.24: =
.\" .I tcache
--
2.29.2
Re: [PATCH] fs: fix: second lock in function d_prune_aliases().
On Wed, Dec 30, 2020 at 08:04:49PM +, Al Viro wrote: > On Wed, Dec 30, 2020 at 03:01:25PM +0800, YANG LI wrote: > > Goto statement jumping will cause lock to be executed again without > > executing unlock, placing the lock statement in front of goto > > label to fix this problem. > > > > Signed-off-by: YANG LI > > Reported-by: Abaci > > I am sorry, but have you even attempted to trigger that codepath? > Just to test your patch... > > FWIW, the patch is completely broken. Obviously so, since you > have dput() done just before goto restart and dput() in very > much capable of blocking. It should never be called with spinlocks > held. And if you look at __dentry_kill() (well, dentry_unlink_inode() > called by __dentry_kill()), you will see that it bloody well *DOES* > drop inode->i_lock. Not only that, but the function is even _annotated_ to that effect. So this 'abaci' tool you have isn't even capable of the bare minimum.
Re: [PATCH v7 3/5] counter: Add character device interface
On 12/25/20 6:15 PM, William Breathitt Gray wrote:
diff --git a/include/uapi/linux/counter.h b/include/uapi/linux/counter.h
new file mode 100644
index ..7585dc9db19d
--- /dev/null
+++ b/include/uapi/linux/counter.h
@@ -0,0 +1,123 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/*
+ * Userspace ABI for Counter character devices
+ * Copyright (C) 2020 William Breathitt Gray
+ */
+#ifndef _UAPI_COUNTER_H_
+#define _UAPI_COUNTER_H_
+
+#include
+#include
+
+/* Component type definitions */
+enum counter_component_type {
+ COUNTER_COMPONENT_NONE,
+ COUNTER_COMPONENT_SIGNAL,
+ COUNTER_COMPONENT_COUNT,
+ COUNTER_COMPONENT_FUNCTION,
+ COUNTER_COMPONENT_SYNAPSE_ACTION,
+ COUNTER_COMPONENT_EXTENSION,
+};
+
+/* Component scope definitions */
+enum counter_scope {
Do we need COUNTER_SCOPE_NONE to go with COUNTER_COMPONENT_NONE?
+ COUNTER_SCOPE_DEVICE,
+ COUNTER_SCOPE_SIGNAL,
+ COUNTER_SCOPE_COUNT,
+};
+
+/**
+ * struct counter_component - Counter component identification
+ * @type: component type (Count, extension, etc.)
Instead of "Count, extension, etc.", it could be more helpful
to say one of enum counter_component_type.
+ * @scope: component scope (Device, Count, or Signal)
Same here. @scope must be one of enum counter_scope.
+ * @parent: parent component identification number
+ * @id: component identification number
It could be helpful to say that these id numbers match
the X/Y/Z in the sysfs paths as described in the sysfs
ABI.
+ */
+struct counter_component {
+ __u8 type;
+ __u8 scope;
+ __u8 parent;
+ __u8 id;
+};
+
+/* Event type definitions */
+enum counter_event_type {
+ COUNTER_EVENT_OVERFLOW,
+ COUNTER_EVENT_UNDERFLOW,
+ COUNTER_EVENT_OVERFLOW_UNDERFLOW,
+ COUNTER_EVENT_THRESHOLD,
+ COUNTER_EVENT_INDEX,
+};
+
+/**
+ * struct counter_watch - Counter component watch configuration
+ * @component: component to watch when event triggers
+ * @event: event that triggers
It would be helpful to say that @event must be one of
enum counter_event_type.
+ * @channel: event channel
It would be useful to say that @channel should be 0 unless
a component has more than one event of the same type.
+ */
+struct counter_watch {
+ struct counter_component component;
+ __u8 event;
+ __u8 channel;
+};
+
+/* ioctl commands */
+#define COUNTER_CLEAR_WATCHES_IOCTL _IO(0x3E, 0x00)
+#define COUNTER_ADD_WATCH_IOCTL _IOW(0x3E, 0x01, struct counter_watch)
+#define COUNTER_LOAD_WATCHES_IOCTL _IO(0x3E, 0x02)
+
+/**
+ * struct counter_event - Counter event data
+ * @timestamp: best estimate of time of event occurrence, in nanoseconds
+ * @value: component value
+ * @watch: component watch configuration
+ * @errno: system error number
+ */
+struct counter_event {
+ __aligned_u64 timestamp;
+ __aligned_u64 value;
+ struct counter_watch watch;
+ __u8 errno;
There are error codes larger than 255. Probably better
make this __u32.
+};
+
+/* Count direction values */
+enum counter_count_direction {
+ COUNTER_COUNT_DIRECTION_FORWARD,
+ COUNTER_COUNT_DIRECTION_BACKWARD,
+};
+
+/* Count mode values */
+enum counter_count_mode {
+ COUNTER_COUNT_MODE_NORMAL,
+ COUNTER_COUNT_MODE_RANGE_LIMIT,
+ COUNTER_COUNT_MODE_NON_RECYCLE,
+ COUNTER_COUNT_MODE_MODULO_N,
+};
+
+/* Count function values */
+enum counter_function {
+ COUNTER_FUNCTION_INCREASE,
+ COUNTER_FUNCTION_DECREASE,
+ COUNTER_FUNCTION_PULSE_DIRECTION,
+ COUNTER_FUNCTION_QUADRATURE_X1_A,
+ COUNTER_FUNCTION_QUADRATURE_X1_B,
+ COUNTER_FUNCTION_QUADRATURE_X2_A,
+ COUNTER_FUNCTION_QUADRATURE_X2_B,
+ COUNTER_FUNCTION_QUADRATURE_X4,
+};
+
+/* Signal values */
+enum counter_signal_level {
+ COUNTER_SIGNAL_LEVEL_LOW,
+ COUNTER_SIGNAL_LEVEL_HIGH,
+};
+
+/* Action mode values */
+enum counter_synapse_action {
+ COUNTER_SYNAPSE_ACTION_NONE,
+ COUNTER_SYNAPSE_ACTION_RISING_EDGE,
+ COUNTER_SYNAPSE_ACTION_FALLING_EDGE,
+ COUNTER_SYNAPSE_ACTION_BOTH_EDGES,
+};
+
+#endif /* _UAPI_COUNTER_H_ */
Re: [PATCH] net: ethernet: Fix memleak in ethoc_probe
On Mon, 28 Dec 2020 16:14:17 -0500 Konstantin Ryabitsev wrote: > On Mon, Dec 28, 2020 at 01:05:26PM -0800, Florian Fainelli wrote: > > On 12/28/2020 12:23 PM, Konstantin Ryabitsev wrote: > > > On Thu, Dec 24, 2020 at 01:57:40PM -0800, Florian Fainelli wrote: > > Konstantin, would you be willing to mod the kernel.org instance of > > patchwork to populate Fixes tags in the generated mboxes? > > >>> > > >>> I'd really rather not -- we try not to diverge from project upstream if > > >>> at all > > >>> possible, as this dramatically complicates upgrades. > > >> > > >> Well that is really unfortunate then because the Linux developer > > >> community settled on using the Fixes: tag for years now and having > > >> patchwork automatically append those tags would greatly help > > >> maintainers. > > > > > > I agree -- but this is something that needs to be implemented upstream. > > > Picking up a one-off patch just for patchwork.kernel.org is not the right > > > way > > > to go about this. > > > > You should be able to tune this from the patchwork administrative > > interface and add new tags there, would not that be acceptable? > > Oh, oops, I got confused by the mention of a rejected upstream patch -- I > didn't realize that this is already possible with a configuration setting. > > Sure, I added a match for ^Fixes: -- let me know if it's not doing the right > thing. I used this one for a test: https://patchwork.kernel.org/project/netdevbpf/patch/1609312994-121032-1-git-send-email-abaci-bug...@linux.alibaba.com/ I'm not getting the Fixes tag when I download the mbox.
[ANNOUNCE] 4.14.213-rt103
Hello RT-list! I'm pleased to announce the 4.14.213-rt103 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.14-rt Head SHA1: af29de213eb180fe8a0db0d4aadde83f1a74be13 Or to build 4.14.213-rt103 directly, the following patches should be applied: https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.14.tar.xz https://www.kernel.org/pub/linux/kernel/v4.x/patch-4.14.213.xz https://www.kernel.org/pub/linux/kernel/projects/rt/4.14/patch-4.14.213-rt103.patch.xz You can also build from 4.14.212-rt102 by applying the incremental patch: https://www.kernel.org/pub/linux/kernel/projects/rt/4.14/incr/patch-4.14.212-rt102-rt103.patch.xz Enjoy! Clark
[PATCH v2] crypto: Fix divide error in do_xor_speed()
crypto: Fix divide error in do_xor_speed()
From: Kirill Tkhai
Latest (but not only latest) linux-next panics with divide
error on my QEMU setup.
The patch at the bottom of this message fixes the problem.
xor: measuring software checksum speed
divide error: [#1] PREEMPT SMP KASAN
PREEMPT SMP KASAN
CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.10.0-next-20201223+ #2177
RIP: 0010:do_xor_speed+0xbb/0xf3
Code: 41 ff cc 75 b5 bf 01 00 00 00 e8 3d 23 8b fe 65 8b 05 f6 49 83 7d 85 c0
75 05 e8
84 70 81 fe b8 00 00 50 c3 31 d2 48 8d 7b 10 f5 41 89 c4 e8 58 07 a2 fe
44 89 63 10 48 8d 7b 08
e8 cb 07 a2
RSP: :888100137dc8 EFLAGS: 00010246
RAX: c350 RBX: 823f0160 RCX:
RDX: RSI: 0808 RDI: 823f0170
RBP: R08: 8109c50f R09: 824bb6f7
R10: fbfff04976de R11: 0001 R12:
R13: 888101997000 R14: 888101994000 R15: 823f0178
FS: () GS:8881f778() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: CR3: 0220e000 CR4: 06a0
Call Trace:
calibrate_xor_blocks+0x13c/0x1c4
? do_xor_speed+0xf3/0xf3
do_one_initcall+0xc1/0x1b7
? start_kernel+0x373/0x373
? unpoison_range+0x3a/0x60
kernel_init_freeable+0x1dd/0x238
? rest_init+0xc6/0xc6
kernel_init+0x8/0x10a
ret_from_fork+0x1f/0x30
---[ end trace 5bd3c1d0b2da ]---
Fixes: c055e3eae0f1 ("crypto: xor - use ktime for template benchmarking")
Signed-off-by: Kirill Tkhai
Acked-by: Ard Biesheuvel
---
v2: New Year resend :) Added fixes tag.
crypto/xor.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/crypto/xor.c b/crypto/xor.c
index eacbf4f93990..8f899f898ec9 100644
--- a/crypto/xor.c
+++ b/crypto/xor.c
@@ -107,6 +107,8 @@ do_xor_speed(struct xor_block_template *tmpl, void *b1,
void *b2)
preempt_enable();
// bytes/ns == GB/s, multiply by 1000 to get MB/s [not MiB/s]
+ if (!min)
+ min = 1;
speed = (1000 * REPS * BENCH_SIZE) / (unsigned int)ktime_to_ns(min);
tmpl->speed = speed;
Re: [PATCH v3 1/4] Add support for Realtek RTL838x/RTL839x switch SoCs
On 12/30/20 10:22 PM, Bert Vermeulen wrote: The RTL838x/839x family of SoCs are Realtek switches with an embedded MIPS core. Oops, forgot patch version note: v3: - all code removed, the base system is now only device tree files and docs and some build config. - ioremap.h restored to the v1 version, with hardcoded I/O ranges, since I got flak on changing that as suggested. This brings it in line with other systems in arch/mips/generic. -- Bert Vermeulen b...@biot.com
