Re: [PATCH] perf/core: fix multiplexing event scheduling issue
> On Oct 17, 2019, at 11:19 PM, Stephane Eranian wrote: > > On Thu, Oct 17, 2019 at 11:13 PM Song Liu wrote: >> >> >> >>> On Oct 17, 2019, at 5:27 PM, Stephane Eranian wrote: >>> >>> This patch complements the following commit: >>> 7fa343b7fdc4 ("perf/core: Fix corner case in perf_rotate_context()") >>> >>> The fix from Song addresses the consequences of the problem but >>> not the cause. This patch fixes the causes and can sit on top of >>> Song's patch. >>> >>> This patch fixes a scheduling problem in the core functions of >>> perf_events. Under certain conditions, some events would not be >>> scheduled even though many counters would be available. This >>> is related to multiplexing and is architecture agnostic and >>> PMU agnostic (i.e., core or uncore). >>> >>> This problem can easily be reproduced when you have two perf >>> stat sessions. The first session does not cause multiplexing, >>> let's say it is measuring 1 event, E1. While it is measuring, >>> a second session starts and causes multiplexing. Let's say it >>> adds 6 events, B1-B6. Now, 7 events compete and are multiplexed. >>> When the second session terminates, all 6 (B1-B6) events are >>> removed. Normally, you'd expect the E1 event to continue to run >>> with no multiplexing. However, the problem is that depending on >>> the state Of E1 when B1-B6 are removed, it may never be scheduled >>> again. If E1 was inactive at the time of removal, despite the >>> multiplexing hrtimer still firing, it will not find any active >>> events and will not try to reschedule. This is what Song's patch >>> fixes. It forces the multiplexing code to consider non-active events. >> >> Good analysis! I kinda knew the example I had (with pinned event) >> was not the only way to trigger this issue. But I didn't think >> about event remove path. >> > I was pursuing this bug without knowledged of your patch. Your patch > makes it harder to see. Clearly in my test case, it disappears, but it is > just because of the multiplexing interval. If we get to the rotate code > and we have no active events yet some inactive, there is something > wrong because we are wasting counters. When I tracked the bug, > I started from the remove_context code, then realized there was also > the disable case. I fixed both and they I discovered your patch which > is fixing it at the receiving end. Hopefully, there aren't any code path > that can lead to this situation. Thanks for the explanation. Agreed that blind spot has bigger impact with longer rotation interval. [...] >>> Signed-off-by: Stephane Eranian >> >> Maybe add: >> Fixes: 8d5bce0c37fa ("perf/core: Optimize perf_rotate_context() event >> scheduling") >> > It does not really fix your patch, I think we can keep it as a double > precaution. It fixes > the causes. I think it is useful to check beyond the active in the > rotate code as well. Also agreed, this is not really fixing that specific commit. Acked-by: Song Liu Thanks, Song
[PATCH net-next] net: axienet: In kconfig add ARM64 as supported platform
xilinx axi_emac driver is supported on ZynqMP UltraScale platform(ARM64). So enable it in kconfig. Basic sanity testing is done on zu+ mpsoc zcu102 evaluation board. Signed-off-by: Radhey Shyam Pandey --- drivers/net/ethernet/xilinx/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/xilinx/Kconfig b/drivers/net/ethernet/xilinx/Kconfig index 8d994ce..a616bdc 100644 --- a/drivers/net/ethernet/xilinx/Kconfig +++ b/drivers/net/ethernet/xilinx/Kconfig @@ -6,7 +6,7 @@ config NET_VENDOR_XILINX bool "Xilinx devices" default y - depends on PPC || PPC32 || MICROBLAZE || ARCH_ZYNQ || MIPS || X86 || ARM || COMPILE_TEST + depends on PPC || PPC32 || MICROBLAZE || ARCH_ZYNQ || MIPS || X86 || ARM || ARM64 || COMPILE_TEST ---help--- If you have a network (Ethernet) card belonging to this class, say Y. @@ -26,11 +26,11 @@ config XILINX_EMACLITE config XILINX_AXI_EMAC tristate "Xilinx 10/100/1000 AXI Ethernet support" - depends on MICROBLAZE || X86 || ARM || COMPILE_TEST + depends on MICROBLAZE || X86 || ARM || ARM64 || COMPILE_TEST select PHYLINK ---help--- This driver supports the 10/100/1000 Ethernet from Xilinx for the - AXI bus interface used in Xilinx Virtex FPGAs. + AXI bus interface used in Xilinx Virtex FPGAs and Soc's. config XILINX_LL_TEMAC tristate "Xilinx LL TEMAC (LocalLink Tri-mode Ethernet MAC) driver" -- 2.7.4
IWL AC 8260, suspect GRP implementation, broken connectivity
Dear all, (please cc) linux 5.3.N (currently .7), but also older kernels Debian/sid Thinkpad X260 iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208 iwlwifi :04:00.0: loaded firmware version 36.8fd77bb3.0 op_mode iwlmvm In one particular location I see completely broken connection: dns does not work (resolve does not work), ping, ssh breaks down, http breaks down, it really sounds like a really weak connection. The problem is that: - the *same* laptop booted into Windows works at high speed connections - other computers (2 Mac) around here work without problems - mobile also connects without any problem There are no RX/TX errors whatsoever. I tried reducing MTU, to no effect. The only warning I see is TCP: wlp4s0: Driver has suspect GRO implementation, TCP performance may be compromised. wlp4s0: flags=4163 mtu 1400 inet 172.17.1.166 netmask 255.255.0.0 broadcast 172.17.255.255 inet6 fe80::fddc:f32e:f9cb:fded prefixlen 64 scopeid 0x20 ether e4:a7:a0:66:6d:f4 txqueuelen 1000 (Ethernet) RX packets 11164 bytes 7459009 (7.1 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 13204 bytes 3062515 (2.9 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 I am a bit at loss how to debug this, or better, whether it is possible to get back normal connectivity? Thanks a lot for any pointer Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: [PATCH v3 06/15] powerpc/32: prepare for CONFIG_VMAP_STACK
Le 17/10/2019 à 09:36, Andrew Donnellan a écrit : On 10/9/19 7:16 pm, Christophe Leroy wrote: +#if defined(CONFIG_VMAP_STACK) && CONFIG_THREAD_SHIFT < PAGE_SHIFT +#define THREAD_SHIFT PAGE_SHIFT +#else #define THREAD_SHIFT CONFIG_THREAD_SHIFT +#endif #define THREAD_SIZE (1 << THREAD_SHIFT) Looking at 64-bit book3s: with 64K pages, this results in a THREAD_SIZE that's too large for immediate mode arithmetic operations, which is annoying. Hmm. Which operation are you thinking about ? For instance, 'addi' can't be used anymore, but 'addis' can. Christophe
Re: [PATCH 1/2] x86, mce, therm_throt: Optimize logging of thermal throttle messages
On Thu, Oct 17, 2019 at 11:53:18PM +, Luck, Tony wrote: > > * we throttle the machine from within the kernel - whatever that may mean > > * if that doesn't help, we stop scheduling !root tasks > > * if that doesn't help, we halt > > The silicon will do that "halt" step all by itself if the temperature > continues to rise and hits the highest of the temperature thresholds. Oh, I know that. But that is not of our concern - I believe we're discussing right now what to do when the lower, softer limits are reached and the thermal interrupt fires. When the hw forces HLT, it means we didn't do a very good job earlier, before it got so hot. :-) -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH v3 3/6] dt-bindings: regulator: max77650: convert the binding document to yaml
czw., 17 paź 2019 o 20:35 Rob Herring napisał(a): > > On Thu, Oct 17, 2019 at 09:12:31AM +0200, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski > > > > Convert the binding document for MAX77650 regulator module to YAML. > > > > Signed-off-by: Bartosz Golaszewski > > --- > > .../bindings/regulator/max77650-regulator.txt | 41 --- > > .../regulator/max77650-regulator.yaml | 31 ++ > > 2 files changed, 31 insertions(+), 41 deletions(-) > > delete mode 100644 > > Documentation/devicetree/bindings/regulator/max77650-regulator.txt > > create mode 100644 > > Documentation/devicetree/bindings/regulator/max77650-regulator.yaml > > > > diff --git > > a/Documentation/devicetree/bindings/regulator/max77650-regulator.txt > > b/Documentation/devicetree/bindings/regulator/max77650-regulator.txt > > deleted file mode 100644 > > index f1cbe813c30f.. > > --- a/Documentation/devicetree/bindings/regulator/max77650-regulator.txt > > +++ /dev/null > > @@ -1,41 +0,0 @@ > > -Regulator driver for MAX77650 PMIC from Maxim Integrated. > > - > > -This module is part of the MAX77650 MFD device. For more details > > -see Documentation/devicetree/bindings/mfd/max77650.txt. > > - > > -The regulator controller is represented as a sub-node of the PMIC node > > -on the device tree. > > - > > -The device has a single LDO regulator and a SIMO buck-boost regulator with > > -three independent power rails. > > - > > -Required properties: > > - > > -- compatible:Must be "maxim,max77650-regulator" > > - > > -Each rail must be instantiated under the regulators subnode of the top PMIC > > -node. Up to four regulators can be defined. For standard regulator > > properties > > -refer to Documentation/devicetree/bindings/regulator/regulator.txt. > > - > > -Available regulator compatible strings are: "ldo", "sbb0", "sbb1", "sbb2". > > - > > -Example: > > - > > - > > - regulators { > > - compatible = "maxim,max77650-regulator"; > > - > > - max77650_ldo: regulator@0 { > > - regulator-compatible = "ldo"; > > - regulator-name = "max77650-ldo"; > > - regulator-min-microvolt = <135>; > > - regulator-max-microvolt = <2937500>; > > - }; > > - > > - max77650_sbb0: regulator@1 { > > - regulator-compatible = "sbb0"; > > - regulator-name = "max77650-sbb0"; > > - regulator-min-microvolt = <80>; > > - regulator-max-microvolt = <1587500>; > > - }; > > - }; > > diff --git > > a/Documentation/devicetree/bindings/regulator/max77650-regulator.yaml > > b/Documentation/devicetree/bindings/regulator/max77650-regulator.yaml > > new file mode 100644 > > index ..a8770742836d > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/regulator/max77650-regulator.yaml > > @@ -0,0 +1,31 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/regulator/max77650-regulator.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Regulator driver for MAX77650 PMIC from Maxim Integrated. > > + > > +maintainers: > > + - Bartosz Golaszewski > > + > > +description: | > > + This module is part of the MAX77650 MFD device. For more details > > + see Documentation/devicetree/bindings/mfd/max77650.txt. > > .yaml? > Is there any better way of referencing the main document than mentioning it in the description? Bart > > + > > + The regulator controller is represented as a sub-node of the PMIC node > > + on the device tree. > > + > > + The device has a single LDO regulator and a SIMO buck-boost regulator > > with > > + three independent power rails. > > + > > +properties: > > + compatible: > > +const: maxim,max77650-regulator > > + > > +patternProperties: > > + "^regulator@[0-3]$": > > +$ref: "regulator.yaml#" > > + > > +required: > > + - compatible > > -- > > 2.23.0 > >
Re: [PATCH v3 1/6] dt-bindings: mfd: max77650: convert the binding document to yaml
czw., 17 paź 2019 o 20:31 Rob Herring napisał(a): > > On Thu, Oct 17, 2019 at 09:12:29AM +0200, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski > > > > Convert the binding document for MAX77650 core MFD module to YAML. > > > > Signed-off-by: Bartosz Golaszewski > > --- > > .../devicetree/bindings/mfd/max77650.txt | 46 -- > > .../devicetree/bindings/mfd/max77650.yaml | 151 ++ > > 2 files changed, 151 insertions(+), 46 deletions(-) > > delete mode 100644 Documentation/devicetree/bindings/mfd/max77650.txt > > create mode 100644 Documentation/devicetree/bindings/mfd/max77650.yaml > > > > diff --git a/Documentation/devicetree/bindings/mfd/max77650.txt > > b/Documentation/devicetree/bindings/mfd/max77650.txt > > deleted file mode 100644 > > index b529d8d19335.. > > --- a/Documentation/devicetree/bindings/mfd/max77650.txt > > +++ /dev/null > > @@ -1,46 +0,0 @@ > > -MAX77650 ultra low-power PMIC from Maxim Integrated. > > - > > -Required properties: > > > > -- compatible:Must be "maxim,max77650" > > -- reg: I2C device address. > > -- interrupts:The interrupt on the parent the controller is > > - connected to. > > -- interrupt-controller: Marks the device node as an interrupt controller. > > -- #interrupt-cells: Must be <2>. > > - > > -- gpio-controller: Marks the device node as a gpio controller. > > -- #gpio-cells: Must be <2>. The first cell is the pin number > > and > > - the second cell is used to specify the gpio active > > - state. > > - > > -Optional properties: > > - > > -gpio-line-names: Single string containing the name of the GPIO line. > > - > > -The GPIO-controller module is represented as part of the top-level PMIC > > -node. The device exposes a single GPIO line. > > - > > -For device-tree bindings of other sub-modules (regulator, power supply, > > -LEDs and onkey) refer to the binding documents under the respective > > -sub-system directories. > > - > > -For more details on GPIO bindings, please refer to the generic GPIO DT > > -binding document . > > - > > -Example: > > - > > - > > - pmic@48 { > > - compatible = "maxim,max77650"; > > - reg = <0x48>; > > - > > - interrupt-controller; > > - interrupt-parent = <&gpio2>; > > - #interrupt-cells = <2>; > > - interrupts = <3 IRQ_TYPE_LEVEL_LOW>; > > - > > - gpio-controller; > > - #gpio-cells = <2>; > > - gpio-line-names = "max77650-charger"; > > - }; > > diff --git a/Documentation/devicetree/bindings/mfd/max77650.yaml > > b/Documentation/devicetree/bindings/mfd/max77650.yaml > > new file mode 100644 > > index ..66a447e1cf56 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mfd/max77650.yaml > > @@ -0,0 +1,151 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/mfd/max77650.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: MAX77650 ultra low-power PMIC from Maxim Integrated. > > + > > +maintainers: > > + - Bartosz Golaszewski > > + > > +description: | > > + This document describes the DT properties of the core MFD controller. > > So does every file in this directory. > > Describe what this chip is. > > > + > > + The GPIO-controller module is represented as part of the top-level PMIC > > + node. The device exposes a single GPIO line. > > + > > + For device-tree bindings of other sub-modules (regulator, power supply, > > + LEDs and onkey) refer to the binding documents under the respective > > + sub-system directories. > > + > > + For more details on GPIO bindings, please refer to the generic GPIO DT > > + binding document . > > Also fairly useless and another reference to maintain... > > > + > > +properties: > > + compatible: > > +const: maxim,max77650 > > + > > + reg: > > +description: > > + I2C device address. > > +maxItems: 1 > > + > > + interrupts: > > +maxItems: 1 > > + > > + interrupt-controller: true > > + > > + "#interrupt-cells": > > +const: 2 > > +description: > > + The first cell is the IRQ number, the second cell is the trigger > > type. > > + > > + gpio-controller: true > > + > > + "#gpio-cells": > > +const: 2 > > +description: > > + The first cell is the pin number and the second cell is used to > > specify > > + the gpio active state. > > + > > + gpio-line-names: > > +maxItems: 1 > > +description: > > + Single string containing the name of the GPIO line. > > + > > + regulators: > > +$ref: ../regulator/max77650-regulator.yaml > > Not bisectable... This patch needs to come last. > > > + > > + charger: > > +$ref: ../power/supply/max77650-charger.yaml > > + > > + leds: > > +$ref: .
Re: [PATCH] vfio/type1: remove hugepage checks in is_invalid_reserved_pfn()
A friendly reminder :) Thanks, Ben 在 2019/10/4 上午12:41, Andrea Arcangeli 写道: On Thu, Oct 03, 2019 at 11:49:42AM +0800, Ben Luo wrote: Currently, no hugepage split code can transfer the reserved bit from head to tail during the split, so checking the head can't make a difference in a racing condition with hugepage spliting. The buddy wouldn't allow a driver to allocate an hugepage if any subpage is reserved in the e820 map at boot, if any driver sets the reserved bit of head page before mapping the hugepage in userland, it needs to set the reserved bit in all subpages to be safe. Signed-off-by: Ben Luo Reviewed-by: Andrea Arcangeli --- drivers/vfio/vfio_iommu_type1.c | 26 -- 1 file changed, 4 insertions(+), 22 deletions(-) diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c index 054391f..e2019ba 100644 --- a/drivers/vfio/vfio_iommu_type1.c +++ b/drivers/vfio/vfio_iommu_type1.c @@ -287,31 +287,13 @@ static int vfio_lock_acct(struct vfio_dma *dma, long npage, bool async) * Some mappings aren't backed by a struct page, for example an mmap'd * MMIO range for our own or another device. These use a different * pfn conversion and shouldn't be tracked as locked pages. + * For compound pages, any driver that sets the reserved bit in head + * page needs to set the reserved bit in all subpages to be safe. */ static bool is_invalid_reserved_pfn(unsigned long pfn) { - if (pfn_valid(pfn)) { - bool reserved; - struct page *tail = pfn_to_page(pfn); - struct page *head = compound_head(tail); - reserved = !!(PageReserved(head)); - if (head != tail) { - /* -* "head" is not a dangling pointer -* (compound_head takes care of that) -* but the hugepage may have been split -* from under us (and we may not hold a -* reference count on the head page so it can -* be reused before we run PageReferenced), so -* we've to check PageTail before returning -* what we just read. -*/ - smp_rmb(); - if (PageTail(tail)) - return reserved; - } - return PageReserved(tail); - } + if (pfn_valid(pfn)) + return PageReserved(pfn_to_page(pfn)); return true; } -- 1.8.3.1
Re: [RFC 2/2] vhost: IFC VF vdpa layer
Hello Jason, Thanks for your comments, I am on a conference travel, I will reply next Monday. Thanks, BR Zhu Lingshan On 10/16/2019 6:19 PM, Jason Wang wrote: On 2019/10/16 上午9:30, Zhu Lingshan wrote: This commit introduced IFC VF operations for vdpa, which complys to vhost_mdev interfaces, handles IFC VF initialization, configuration and removal. Signed-off-by: Zhu Lingshan --- drivers/vhost/ifcvf/ifcvf_main.c | 541 +++ 1 file changed, 541 insertions(+) create mode 100644 drivers/vhost/ifcvf/ifcvf_main.c diff --git a/drivers/vhost/ifcvf/ifcvf_main.c b/drivers/vhost/ifcvf/ifcvf_main.c new file mode 100644 index ..c48a29969a85 --- /dev/null +++ b/drivers/vhost/ifcvf/ifcvf_main.c @@ -0,0 +1,541 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright (C) 2019 Intel Corporation. + */ + +#include +#include +#include +#include +#include + +#include "ifcvf_base.h" + +#define VERSION_STRING "0.1" +#define DRIVER_AUTHOR "Intel Corporation" +#define IFCVF_DRIVER_NAME "ifcvf" + +static irqreturn_t ifcvf_intr_handler(int irq, void *arg) +{ + struct vring_info *vring = arg; + + if (vring->cb.callback) + return vring->cb.callback(vring->cb.private); + + return IRQ_HANDLED; +} + +static u64 ifcvf_mdev_get_features(struct mdev_device *mdev) +{ + return IFC_SUPPORTED_FEATURES; I would expect this should be done by querying the hw. Or IFC VF can't get any update through its firmware? +} + +static int ifcvf_mdev_set_features(struct mdev_device *mdev, u64 features) +{ + struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev); + struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter); + + vf->req_features = features; + + return 0; +} + +static u64 ifcvf_mdev_get_vq_state(struct mdev_device *mdev, u16 qid) +{ + struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev); + struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter); + + return vf->vring[qid].last_avail_idx; Does this really work? I'd expect it should be fetched from hw since it's an internal state. +} + +static int ifcvf_mdev_set_vq_state(struct mdev_device *mdev, u16 qid, u64 num) +{ + struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev); + struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter); + + vf->vring[qid].last_used_idx = num; I fail to understand why last_used_idx is needed. It looks to me the used idx in the used ring is sufficient. + vf->vring[qid].last_avail_idx = num; Do we need a synchronization with hw immediately here? + + return 0; +} + +static int ifcvf_mdev_set_vq_address(struct mdev_device *mdev, u16 idx, + u64 desc_area, u64 driver_area, + u64 device_area) +{ + struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev); + struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter); + + vf->vring[idx].desc = desc_area; + vf->vring[idx].avail = driver_area; + vf->vring[idx].used = device_area; + + return 0; +} + +static void ifcvf_mdev_set_vq_num(struct mdev_device *mdev, u16 qid, u32 num) +{ + struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev); + struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter); + + vf->vring[qid].size = num; +} + +static void ifcvf_mdev_set_vq_ready(struct mdev_device *mdev, + u16 qid, bool ready) +{ + + struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev); + struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter); + + vf->vring[qid].ready = ready; +} + +static bool ifcvf_mdev_get_vq_ready(struct mdev_device *mdev, u16 qid) +{ + + struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev); + struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter); + + return vf->vring[qid].ready; +} + +static void ifcvf_mdev_set_vq_cb(struct mdev_device *mdev, u16 idx, + struct virtio_mdev_callback *cb) +{ + struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev); + struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter); + + vf->vring[idx].cb = *cb; +} + +static void ifcvf_mdev_kick_vq(struct mdev_device *mdev, u16 idx) +{ + struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev); + struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter); + + ifcvf_notify_queue(vf, idx); +} + +static u8 ifcvf_mdev_get_status(struct mdev_device *mdev) +{ + struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev); + struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter); + + return vf->status; +} + +static u32 ifcvf_mdev_get_generation(struct mdev_device *mdev) +{ + struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev); + struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter); + + return vf->generation; +} + +static int ifcvf_mdev_get_version(struct mdev_device *mdev) +{ + return VIRTIO_MDEV_VERSION; +} + +static u32 ifcvf_mdev_get_device_id(struct mdev_device *mdev) +{ + return IFCVF_DEVICE_ID; +} + +static u32 ifcvf_mdev_get_vendor_id(struct mdev_device *mdev) +{ + return IFCVF_VENDOR_ID; +} + +static
[PATCH v2] KVM: SVM: Fix potential wrong physical id in avic_handle_ldr_update
Guest physical APIC ID may not equal to vcpu->vcpu_id in some case. We may set the wrong physical id in avic_handle_ldr_update as we always use vcpu->vcpu_id. Get physical APIC ID from vAPIC page instead. Export and use kvm_xapic_id here and in avic_handle_apic_id_update as suggested by Vitaly. Signed-off-by: Miaohe Lin --- arch/x86/kvm/lapic.c | 5 - arch/x86/kvm/lapic.h | 5 + arch/x86/kvm/svm.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 87b0fcc23ef8..b29d00b661ff 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -111,11 +111,6 @@ static inline int apic_enabled(struct kvm_lapic *apic) (LVT_MASK | APIC_MODE_MASK | APIC_INPUT_POLARITY | \ APIC_LVT_REMOTE_IRR | APIC_LVT_LEVEL_TRIGGER) -static inline u8 kvm_xapic_id(struct kvm_lapic *apic) -{ - return kvm_lapic_get_reg(apic, APIC_ID) >> 24; -} - static inline u32 kvm_x2apic_id(struct kvm_lapic *apic) { return apic->vcpu->vcpu_id; diff --git a/arch/x86/kvm/lapic.h b/arch/x86/kvm/lapic.h index 2aad7e226fc0..1f5014852e20 100644 --- a/arch/x86/kvm/lapic.h +++ b/arch/x86/kvm/lapic.h @@ -242,4 +242,9 @@ static inline enum lapic_mode kvm_apic_mode(u64 apic_base) return apic_base & (MSR_IA32_APICBASE_ENABLE | X2APIC_ENABLE); } +static inline u8 kvm_xapic_id(struct kvm_lapic *apic) +{ + return kvm_lapic_get_reg(apic, APIC_ID) >> 24; +} + #endif diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c index f8ecb6df5106..ca200b50cde4 100644 --- a/arch/x86/kvm/svm.c +++ b/arch/x86/kvm/svm.c @@ -4591,6 +4591,7 @@ static int avic_handle_ldr_update(struct kvm_vcpu *vcpu) int ret = 0; struct vcpu_svm *svm = to_svm(vcpu); u32 ldr = kvm_lapic_get_reg(vcpu->arch.apic, APIC_LDR); + u32 id = kvm_xapic_id(vcpu->arch.apic); if (ldr == svm->ldr_reg) return 0; @@ -4598,7 +4599,7 @@ static int avic_handle_ldr_update(struct kvm_vcpu *vcpu) avic_invalidate_logical_id_entry(vcpu); if (ldr) - ret = avic_ldr_write(vcpu, vcpu->vcpu_id, ldr); + ret = avic_ldr_write(vcpu, id, ldr); if (!ret) svm->ldr_reg = ldr; @@ -4610,8 +4611,7 @@ static int avic_handle_apic_id_update(struct kvm_vcpu *vcpu) { u64 *old, *new; struct vcpu_svm *svm = to_svm(vcpu); - u32 apic_id_reg = kvm_lapic_get_reg(vcpu->arch.apic, APIC_ID); - u32 id = (apic_id_reg >> 24) & 0xff; + u32 id = kvm_xapic_id(vcpu->arch.apic); if (vcpu->vcpu_id == id) return 0; -- 2.19.1
Re: memory offline infinite loop after soft offline
On Fri, Oct 18, 2019 at 08:06:35AM +0200, Michal Hocko wrote: > On Fri 18-10-19 02:19:06, Naoya Horiguchi wrote: > > On Thu, Oct 17, 2019 at 08:27:59PM +0200, Michal Hocko wrote: > > > On Thu 17-10-19 14:07:13, Qian Cai wrote: > > > > On Thu, 2019-10-17 at 12:01 +0200, Michal Hocko wrote: > > > > > On Thu 17-10-19 09:34:10, Naoya Horiguchi wrote: > > > > > > On Mon, Oct 14, 2019 at 10:39:14AM +0200, Michal Hocko wrote: > > > > > > > > > > [...] > > > > > > > diff --git a/mm/page_isolation.c b/mm/page_isolation.c > > > > > > > index 89c19c0feadb..5fb3fee16fde 100644 > > > > > > > --- a/mm/page_isolation.c > > > > > > > +++ b/mm/page_isolation.c > > > > > > > @@ -274,7 +274,7 @@ __test_page_isolated_in_pageblock(unsigned > > > > > > > long pfn, unsigned long end_pfn, > > > > > > >* simple way to verify that as VM_BUG_ON(), > > > > > > > though. > > > > > > >*/ > > > > > > > pfn += 1 << page_order(page); > > > > > > > - else if (skip_hwpoisoned_pages && PageHWPoison(page)) > > > > > > > + else if (skip_hwpoisoned_pages && > > > > > > > PageHWPoison(compound_head(page))) > > > > > > > /* A HWPoisoned page cannot be also PageBuddy */ > > > > > > > pfn++; > > > > > > > else > > > > > > > > > > > > This fix looks good to me. The original code only addresses > > > > > > hwpoisoned 4kB-page, > > > > > > we seem to have this issue since the following commit, > > > > > > > > > > Thanks a lot for double checking Naoya! > > > > > > > > > > > commit b023f46813cde6e3b8a8c24f432ff9c1fd8e9a64 > > > > > > Author: Wen Congyang > > > > > > Date: Tue Dec 11 16:00:45 2012 -0800 > > > > > > > > > > > > memory-hotplug: skip HWPoisoned page when offlining pages > > > > > > > > > > > > and extension of LTP coverage finally discovered this. > > > > > > > > > > Qian, could you give the patch some testing? > > > > > > > > Unfortunately, this does not solve the problem. It looks to me that in > > > > soft_offline_huge_page(), set_hwpoison_free_buddy_page() will only set > > > > PG_hwpoison for buddy pages, so the even the compound_head() has no > > > > PG_hwpoison > > > > set. > > > > > > > > if (PageBuddy(page_head) && page_order(page_head) >= > > > > order) { > > > > if (!TestSetPageHWPoison(page)) > > > > hwpoisoned = true; > > > > > > This is more than unexpected. How are we supposed to find out that the > > > page is poisoned? Any idea Naoya? > > > > # sorry for my poor review... > > > > We set PG_hwpoison bit only on the head page for hugetlb, that's because > > we handle multiple pages as a single one for hugetlb. So it's enough > > to check isolation only on the head page. Simply skipping pfn cursor to > > the page after the hugepage should avoid the infinite loop: > > But the page dump Qian provided shows that the head page doesn't have > HWPoison bit either. If it had then going pfn at a time should just work > because all tail pages would be skipped. Or do I miss something? You're right, then I don't see how this happens. If the error hugepage was isolated without having PG_hwpoison set, it's unexpected and problematic. I'm testing myself with v5.4-rc2 (simply ran move_pages12 and did hotremove/hotadd) but don't reproduce the issue yet. Do we need specific kernel version/config to trigger this? Thanks, Naoya Horiguchi > > > @@ -274,9 +274,13 @@ __test_page_isolated_in_pageblock(unsigned long pfn, > > unsigned long end_pfn, > > * simple way to verify that as VM_BUG_ON(), though. > > */ > > pfn += 1 << page_order(page); > > - else if (skip_hwpoisoned_pages && PageHWPoison(page)) > > - /* A HWPoisoned page cannot be also PageBuddy */ > > - pfn++; > > + else if (skip_hwpoisoned_pages && > > PageHWPoison(compound_head(page))) > > + /* > > + * A HWPoisoned page cannot be also PageBuddy. > > + * PG_hwpoison could be set only on the head page in > > + * hugetlb case, so no need to check tail pages. > > + */ > > + pfn += 1 << compound_order(page); > > else > > break; > > } > > > > Qian, could you please try this? > > > > Thanks, > > Naoya Horiguchi > > -- > Michal Hocko > SUSE Labs >
Re: [PATCH V2 3/3] bnxt_en: Add support to collect crash dump via ethtool
On Fri, Oct 18, 2019 at 12:52 AM Jakub Kicinski wrote: > > On Thu, 17 Oct 2019 17:31:22 +0530, Sheetal Tigadoli wrote: > > From: Vasundhara Volam > > > > Driver supports 2 types of core dumps. > > > > 1. Live dump - Firmware dump when system is up and running. > > 2. Crash dump - Dump which is collected during firmware crash > > that can be retrieved after recovery. > > Crash dump is currently supported only on specific 58800 chips > > which can be retrieved using OP-TEE API only, as firmware cannot > > access this region directly. > > > > User needs to set the dump flag using following command before > > initiating the dump collection: > > > > $ ethtool -W|--set-dump eth0 N > > > > Where N is "0" for live dump and "1" for crash dump > > > > Command to collect the dump after setting the flag: > > > > $ ethtool -w eth0 data Filename > > > > Cc: Michael Chan > > Signed-off-by: Vasundhara Volam > > Signed-off-by: Sheetal Tigadoli > > --- > > drivers/net/ethernet/broadcom/bnxt/bnxt.h | 3 ++ > > drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 36 > > +-- > > drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.h | 2 ++ > > 3 files changed, 39 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.h > > b/drivers/net/ethernet/broadcom/bnxt/bnxt.h > > index 0943715..3e7d1fb 100644 > > --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.h > > +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.h > > @@ -1807,6 +1807,9 @@ struct bnxt { > > > > u8 num_leds; > > struct bnxt_led_infoleds[BNXT_MAX_LED]; > > + u16 dump_flag; > > +#define BNXT_DUMP_LIVE 0 > > +#define BNXT_DUMP_CRASH 1 > > > > struct bpf_prog *xdp_prog; > > > > diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c > > b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c > > index 51c1404..1596221 100644 > > --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c > > +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c > > @@ -3311,6 +3311,23 @@ static int bnxt_get_coredump(struct bnxt *bp, void > > *buf, u32 *dump_len) > > return rc; > > } > > > > +static int bnxt_set_dump(struct net_device *dev, struct ethtool_dump *dump) > > +{ > > + struct bnxt *bp = netdev_priv(dev); > > + > > +#ifndef CONFIG_TEE_BNXT_FW > > + return -EOPNOTSUPP; > > +#endif > > if (!IS_ENABLED(...)) > return x; > > reads better IMHO Okay. > > But also you seem to be breaking live dump for systems with > CONFIG_TEE_BNXT_FW=n Yes, we are supporting set_dump only if crash dump is supported. > > > + if (dump->flag > BNXT_DUMP_CRASH) { > > + netdev_err(dev, "Supports only Live(0) and Crash(1) > > dumps.\n"); > > more of an _info than _err, if at all I made this err, as we are returning error on invalid flag value. I can modify the log to something like "Invalid dump flag. Supports only Live(0) and Crash(1) dumps.\n" to make it more like error log. > > > + return -EINVAL; > > + } > > + > > + bp->dump_flag = dump->flag; > > + return 0; > > +} > > + > > static int bnxt_get_dump_flag(struct net_device *dev, struct ethtool_dump > > *dump) > > { > > struct bnxt *bp = netdev_priv(dev); > > @@ -3323,7 +3340,12 @@ static int bnxt_get_dump_flag(struct net_device > > *dev, struct ethtool_dump *dump) > > bp->ver_resp.hwrm_fw_bld_8b << 8 | > > bp->ver_resp.hwrm_fw_rsvd_8b; > > > > - return bnxt_get_coredump(bp, NULL, &dump->len); > > + dump->flag = bp->dump_flag; > > + if (bp->dump_flag == BNXT_DUMP_CRASH) > > + dump->len = BNXT_CRASH_DUMP_LEN; > > + else > > + bnxt_get_coredump(bp, NULL, &dump->len); > > + return 0; > > } > > > > static int bnxt_get_dump_data(struct net_device *dev, struct ethtool_dump > > *dump, > > @@ -3336,7 +3358,16 @@ static int bnxt_get_dump_data(struct net_device > > *dev, struct ethtool_dump *dump, > > > > memset(buf, 0, dump->len); > > > > - return bnxt_get_coredump(bp, buf, &dump->len); > > + dump->flag = bp->dump_flag; > > + if (dump->flag == BNXT_DUMP_CRASH) { > > +#ifdef CONFIG_TEE_BNXT_FW > > + return tee_bnxt_copy_coredump(buf, 0, dump->len); > > +#endif > > + } else { > > + return bnxt_get_coredump(bp, buf, &dump->len); > > + } > > + > > + return 0; > > } > > > > void bnxt_ethtool_init(struct bnxt *bp) > > @@ -3446,6 +3477,7 @@ void bnxt_ethtool_free(struct bnxt *bp) > > .set_phys_id= bnxt_set_phys_id, > > .self_test = bnxt_self_test, > > .reset = bnxt_reset, > > + .set_dump = bnxt_set_dump, > > .get_dump_flag = bnxt_get_dump_flag, > > .get_dump_data = bnxt_get_dump_data, > > }; > > diff --git a/drivers/net/ethernet/broadcom/
Re: BUG: bad usercopy in ld_usb_read (3)
On Wed, Oct 16, 2019 at 06:42:11PM -0700, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:22be26f7 usb-fuzzer: main usb gadget fuzzer driver > git tree: https://github.com/google/kasan.git usb-fuzzer > console output: https://syzkaller.appspot.com/x/log.txt?x=1756ff7760 > kernel config: https://syzkaller.appspot.com/x/.config?x=387eccb7ac68ec5 > dashboard link: https://syzkaller.appspot.com/bug?extid=acee996f6938b9ded381 > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+acee996f6938b9ded...@syzkaller.appspotmail.com > > ldusb 5-1:0.28: Read buffer overflow, 177886378725897 bytes dropped > usercopy: Kernel memory exposure attempt detected from process stack > (offset 0, size 2147479552)! > [ cut here ] > kernel BUG at mm/usercopy.c:99! > invalid opcode: [#1] SMP KASAN > CPU: 1 PID: 6543 Comm: syz-executor.5 Not tainted 5.4.0-rc3+ #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > RIP: 0010:usercopy_abort+0xb9/0xbb mm/usercopy.c:99 > Code: e8 32 51 d6 ff 49 89 d9 4d 89 e8 4c 89 e1 41 56 48 89 ee 48 c7 c7 40 > d9 cd 85 ff 74 24 08 41 57 48 8b 54 24 20 e8 46 e3 c0 ff <0f> 0b e8 06 51 > d6 ff e8 31 8b fd ff 8b 54 24 04 49 89 d8 4c 89 e1 > RSP: 0018:8881d35f7c58 EFLAGS: 00010282 > RAX: 0061 RBX: 85cdd660 RCX: > RDX: RSI: 8128bcbd RDI: ed103a6bef7d > RBP: 85cdd820 R08: 0061 R09: fbfff11b23be > R10: fbfff11b23bd R11: 88d91def R12: 85cdda40 > R13: 85cdd660 R14: 7000 R15: 85cdd660 > FS: 7fb330338700() GS:8881db30() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 7f07cea47000 CR3: 0001cc11e000 CR4: 001406e0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Call Trace: > __check_object_size mm/usercopy.c:282 [inline] > __check_object_size.cold+0x91/0xbb mm/usercopy.c:256 > check_object_size include/linux/thread_info.h:119 [inline] > check_copy_size include/linux/thread_info.h:150 [inline] > copy_to_user include/linux/uaccess.h:151 [inline] > ld_usb_read+0x31a/0x760 drivers/usb/misc/ldusb.c:492 > __vfs_read+0x76/0x100 fs/read_write.c:425 > vfs_read+0x1ea/0x430 fs/read_write.c:461 > ksys_read+0x1e8/0x250 fs/read_write.c:587 > do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > RIP: 0033:0x459a59 > Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff > ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > RSP: 002b:7fb330337c78 EFLAGS: 0246 ORIG_RAX: > RAX: ffda RBX: 0003 RCX: 00459a59 > RDX: ffad RSI: 20003200 RDI: 0004 > RBP: 0075bfc8 R08: R09: > R10: R11: 0246 R12: 7fb3303386d4 > R13: 004c7120 R14: 004dcae8 R15: > Modules linked in: > ---[ end trace 0fa22c64036b6ebe ]--- > RIP: 0010:usercopy_abort+0xb9/0xbb mm/usercopy.c:99 > Code: e8 32 51 d6 ff 49 89 d9 4d 89 e8 4c 89 e1 41 56 48 89 ee 48 c7 c7 40 > d9 cd 85 ff 74 24 08 41 57 48 8b 54 24 20 e8 46 e3 c0 ff <0f> 0b e8 06 51 > d6 ff e8 31 8b fd ff 8b 54 24 04 49 89 d8 4c 89 e1 > RSP: 0018:8881d35f7c58 EFLAGS: 00010282 > RAX: 0061 RBX: 85cdd660 RCX: > RDX: RSI: 8128bcbd RDI: ed103a6bef7d > RBP: 85cdd820 R08: 0061 R09: fbfff11b23be > R10: fbfff11b23bd R11: 88d91def R12: 85cdda40 > R13: 85cdd660 R14: 7000 R15: 85cdd660 > FS: 7fb330338700() GS:8881db30() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 7f07cea47000 CR3: 0001cc11e000 CR4: 001406e0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 #syz dup: KASAN: slab-out-of-bounds Read in ld_usb_read (3) Fix under way. Johan
Re: memory offline infinite loop after soft offline
On Thu, Oct 17, 2019 at 08:27:59PM +0200, Michal Hocko wrote: > On Thu 17-10-19 14:07:13, Qian Cai wrote: > > On Thu, 2019-10-17 at 12:01 +0200, Michal Hocko wrote: > > > On Thu 17-10-19 09:34:10, Naoya Horiguchi wrote: > > > > On Mon, Oct 14, 2019 at 10:39:14AM +0200, Michal Hocko wrote: > > > > > > [...] > > > > > diff --git a/mm/page_isolation.c b/mm/page_isolation.c > > > > > index 89c19c0feadb..5fb3fee16fde 100644 > > > > > --- a/mm/page_isolation.c > > > > > +++ b/mm/page_isolation.c > > > > > @@ -274,7 +274,7 @@ __test_page_isolated_in_pageblock(unsigned long > > > > > pfn, unsigned long end_pfn, > > > > >* simple way to verify that as VM_BUG_ON(), > > > > > though. > > > > >*/ > > > > > pfn += 1 << page_order(page); > > > > > - else if (skip_hwpoisoned_pages && PageHWPoison(page)) > > > > > + else if (skip_hwpoisoned_pages && > > > > > PageHWPoison(compound_head(page))) > > > > > /* A HWPoisoned page cannot be also PageBuddy */ > > > > > pfn++; > > > > > else > > > > > > > > This fix looks good to me. The original code only addresses hwpoisoned > > > > 4kB-page, > > > > we seem to have this issue since the following commit, > > > > > > Thanks a lot for double checking Naoya! > > > > > > > commit b023f46813cde6e3b8a8c24f432ff9c1fd8e9a64 > > > > Author: Wen Congyang > > > > Date: Tue Dec 11 16:00:45 2012 -0800 > > > > > > > > memory-hotplug: skip HWPoisoned page when offlining pages > > > > > > > > and extension of LTP coverage finally discovered this. > > > > > > Qian, could you give the patch some testing? > > > > Unfortunately, this does not solve the problem. It looks to me that in > > soft_offline_huge_page(), set_hwpoison_free_buddy_page() will only set > > PG_hwpoison for buddy pages, so the even the compound_head() has no > > PG_hwpoison > > set. > > > > if (PageBuddy(page_head) && page_order(page_head) >= order) { > > if (!TestSetPageHWPoison(page)) > > hwpoisoned = true; > > This is more than unexpected. How are we supposed to find out that the > page is poisoned? Any idea Naoya? # sorry for my poor review... We set PG_hwpoison bit only on the head page for hugetlb, that's because we handle multiple pages as a single one for hugetlb. So it's enough to check isolation only on the head page. Simply skipping pfn cursor to the page after the hugepage should avoid the infinite loop: @@ -274,9 +274,13 @@ __test_page_isolated_in_pageblock(unsigned long pfn, unsigned long end_pfn, * simple way to verify that as VM_BUG_ON(), though. */ pfn += 1 << page_order(page); - else if (skip_hwpoisoned_pages && PageHWPoison(page)) - /* A HWPoisoned page cannot be also PageBuddy */ - pfn++; + else if (skip_hwpoisoned_pages && PageHWPoison(compound_head(page))) + /* + * A HWPoisoned page cannot be also PageBuddy. + * PG_hwpoison could be set only on the head page in + * hugetlb case, so no need to check tail pages. + */ + pfn += 1 << compound_order(page); else break; } Qian, could you please try this? Thanks, Naoya Horiguchi
Re: PCI/MSI: Remove the PCI_MSI_IRQ_DOMAIN architecture whitelist
Hi, On 17. 10. 19 20:19, Palmer Dabbelt wrote: > This came up in the context of the microblaze port, where a patch was > recently posted to extend the whitelist. I hoped you were aware about this discussion we have with Christoph. https://lkml.org/lkml/2019/10/8/682 It means 1/3 and 2/3 should be replaced by mandatory-y and I expect msi.h can be removed from architecture Kbuild too. Thanks, Michal
Re: [PATCH] perf/core: fix multiplexing event scheduling issue
On Thu, Oct 17, 2019 at 11:13 PM Song Liu wrote: > > > > > On Oct 17, 2019, at 5:27 PM, Stephane Eranian wrote: > > > > This patch complements the following commit: > > 7fa343b7fdc4 ("perf/core: Fix corner case in perf_rotate_context()") > > > > The fix from Song addresses the consequences of the problem but > > not the cause. This patch fixes the causes and can sit on top of > > Song's patch. > > > > This patch fixes a scheduling problem in the core functions of > > perf_events. Under certain conditions, some events would not be > > scheduled even though many counters would be available. This > > is related to multiplexing and is architecture agnostic and > > PMU agnostic (i.e., core or uncore). > > > > This problem can easily be reproduced when you have two perf > > stat sessions. The first session does not cause multiplexing, > > let's say it is measuring 1 event, E1. While it is measuring, > > a second session starts and causes multiplexing. Let's say it > > adds 6 events, B1-B6. Now, 7 events compete and are multiplexed. > > When the second session terminates, all 6 (B1-B6) events are > > removed. Normally, you'd expect the E1 event to continue to run > > with no multiplexing. However, the problem is that depending on > > the state Of E1 when B1-B6 are removed, it may never be scheduled > > again. If E1 was inactive at the time of removal, despite the > > multiplexing hrtimer still firing, it will not find any active > > events and will not try to reschedule. This is what Song's patch > > fixes. It forces the multiplexing code to consider non-active events. > > Good analysis! I kinda knew the example I had (with pinned event) > was not the only way to trigger this issue. But I didn't think > about event remove path. > I was pursuing this bug without knowledged of your patch. Your patch makes it harder to see. Clearly in my test case, it disappears, but it is just because of the multiplexing interval. If we get to the rotate code and we have no active events yet some inactive, there is something wrong because we are wasting counters. When I tracked the bug, I started from the remove_context code, then realized there was also the disable case. I fixed both and they I discovered your patch which is fixing it at the receiving end. Hopefully, there aren't any code path that can lead to this situation. > > However, the cause is not addressed. The kernel should not rely on > > the multiplexing hrtimer to unblock inactive events. That timer > > can have abitrary duration in the milliseconds. Until the timer > > fires, counters are available, but no measurable events are using > > them. We do not want to introduce blind spots of arbitrary durations. > > > > This patch addresses the cause of the problem, by checking that, > > when an event is disabled or removed and the context was multiplexing > > events, inactive events gets immediately a chance to be scheduled by > > calling ctx_resched(). The rescheduling is done on event of equal > > or lower priority types. With that in place, as soon as a counter > > is freed, schedulable inactive events may run, thereby eliminating > > a blind spot. > > > > This can be illustrated as follows using Skylake uncore CHA here: > > > > $ perf stat --no-merge -a -I 1000 -C 28 -e uncore_cha_0/event=0x0/ > >42.007856531 2,000,291,322 uncore_cha_0/event=0x0/ > >43.008062166 2,000,399,526 uncore_cha_0/event=0x0/ > >44.008293244 2,000,473,720 uncore_cha_0/event=0x0/ > >45.008501847 2,000,423,420 uncore_cha_0/event=0x0/ > >46.008706558 2,000,411,132 uncore_cha_0/event=0x0/ > >47.008928543 2,000,441,660 uncore_cha_0/event=0x0/ > > > > Adding second sessiont with 4 events for 4s > > > > $ perf stat -a -I 1000 -C 28 --no-merge -e > > uncore_cha_0/event=0x0/,uncore_cha_0/event=0x0/,uncore_cha_0/event=0x0/,uncore_cha_0/event=0x0/ > > sleep 4 > >48.009114643 1,983,129,830 uncore_cha_0/event=0x0/ > > (99.71%) > >49.009279616 1,976,067,751 uncore_cha_0/event=0x0/ > > (99.30%) > >50.009428660 1,974,448,006 uncore_cha_0/event=0x0/ > > (98.92%) > >51.009524309 1,973,083,237 uncore_cha_0/event=0x0/ > > (98.55%) > >52.009673467 1,972,097,678 uncore_cha_0/event=0x0/ > > (97.11%) > > > > End of 4s, second session is removed. But the first event does not schedule > > and never will > > unless new events force multiplexing again. > > > >53.009815999uncore_cha_0/event=0x0/ > > (95.28%) > >54.009961809uncore_cha_0/event=0x0/ > > (93.52%) > >55.010110972uncore_cha_0/event=0x0/ > > (91.82%)
Re: [PATCH] perf/core: fix multiplexing event scheduling issue
> On Oct 17, 2019, at 5:27 PM, Stephane Eranian wrote: > > This patch complements the following commit: > 7fa343b7fdc4 ("perf/core: Fix corner case in perf_rotate_context()") > > The fix from Song addresses the consequences of the problem but > not the cause. This patch fixes the causes and can sit on top of > Song's patch. > > This patch fixes a scheduling problem in the core functions of > perf_events. Under certain conditions, some events would not be > scheduled even though many counters would be available. This > is related to multiplexing and is architecture agnostic and > PMU agnostic (i.e., core or uncore). > > This problem can easily be reproduced when you have two perf > stat sessions. The first session does not cause multiplexing, > let's say it is measuring 1 event, E1. While it is measuring, > a second session starts and causes multiplexing. Let's say it > adds 6 events, B1-B6. Now, 7 events compete and are multiplexed. > When the second session terminates, all 6 (B1-B6) events are > removed. Normally, you'd expect the E1 event to continue to run > with no multiplexing. However, the problem is that depending on > the state Of E1 when B1-B6 are removed, it may never be scheduled > again. If E1 was inactive at the time of removal, despite the > multiplexing hrtimer still firing, it will not find any active > events and will not try to reschedule. This is what Song's patch > fixes. It forces the multiplexing code to consider non-active events. Good analysis! I kinda knew the example I had (with pinned event) was not the only way to trigger this issue. But I didn't think about event remove path. > However, the cause is not addressed. The kernel should not rely on > the multiplexing hrtimer to unblock inactive events. That timer > can have abitrary duration in the milliseconds. Until the timer > fires, counters are available, but no measurable events are using > them. We do not want to introduce blind spots of arbitrary durations. > > This patch addresses the cause of the problem, by checking that, > when an event is disabled or removed and the context was multiplexing > events, inactive events gets immediately a chance to be scheduled by > calling ctx_resched(). The rescheduling is done on event of equal > or lower priority types. With that in place, as soon as a counter > is freed, schedulable inactive events may run, thereby eliminating > a blind spot. > > This can be illustrated as follows using Skylake uncore CHA here: > > $ perf stat --no-merge -a -I 1000 -C 28 -e uncore_cha_0/event=0x0/ >42.007856531 2,000,291,322 uncore_cha_0/event=0x0/ >43.008062166 2,000,399,526 uncore_cha_0/event=0x0/ >44.008293244 2,000,473,720 uncore_cha_0/event=0x0/ >45.008501847 2,000,423,420 uncore_cha_0/event=0x0/ >46.008706558 2,000,411,132 uncore_cha_0/event=0x0/ >47.008928543 2,000,441,660 uncore_cha_0/event=0x0/ > > Adding second sessiont with 4 events for 4s > > $ perf stat -a -I 1000 -C 28 --no-merge -e > uncore_cha_0/event=0x0/,uncore_cha_0/event=0x0/,uncore_cha_0/event=0x0/,uncore_cha_0/event=0x0/ > sleep 4 >48.009114643 1,983,129,830 uncore_cha_0/event=0x0/ > (99.71%) >49.009279616 1,976,067,751 uncore_cha_0/event=0x0/ > (99.30%) >50.009428660 1,974,448,006 uncore_cha_0/event=0x0/ > (98.92%) >51.009524309 1,973,083,237 uncore_cha_0/event=0x0/ > (98.55%) >52.009673467 1,972,097,678 uncore_cha_0/event=0x0/ > (97.11%) > > End of 4s, second session is removed. But the first event does not schedule > and never will > unless new events force multiplexing again. > >53.009815999uncore_cha_0/event=0x0/ > (95.28%) >54.009961809uncore_cha_0/event=0x0/ > (93.52%) >55.010110972uncore_cha_0/event=0x0/ > (91.82%) >56.010217579uncore_cha_0/event=0x0/ > (90.18%) Does this still happen after my patch? I was not able to repro this. > Signed-off-by: Stephane Eranian Maybe add: Fixes: 8d5bce0c37fa ("perf/core: Optimize perf_rotate_context() event scheduling") Thanks, Song
Re: [PATCH] MAINTAINERS: mtd/ubi/ubifs: Remove inactive maintainers
On 17/10/19 5:22 PM, Miquel Raynal wrote: > Despite their substantial personal investment in the MTD/UBI/UBIFS a > few years back, David, Brian, Artem and Adrian are not actively > maintaining the subsystem anymore. We warmly salute them for all the > work they have achieved and will of course still welcome their > participation and reviews. > > That said, Marek retired himself a few weeks ago quoting Harald [1]: > > It matters who has which title and when. Should somebody not > be an active maintainer, make sure he's not listed as such. > > For this same reason, let’s trim the maintainers list with the > actually active ones over the past two years. > > [1] http://laforge.gnumonks.org/blog/20180307-mchardy-gpl/ > > Cc: David Woodhouse > Cc: Brian Norris > Cc: Artem Bityutskiy > Cc: Adrian Hunter > Cc: Marek Vasut > Cc: Miquel Raynal > Cc: Richard Weinberger > Cc: Vignesh Raghavendra > Cc: Tudor Ambarus > Signed-off-by: Miquel Raynal Acked-by: Adrian Hunter > --- > MAINTAINERS | 5 - > 1 file changed, 5 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 0632422ce9d4..0e5e0736ee55 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -10528,8 +10528,6 @@ F:include/linux/vmalloc.h > F: mm/ > > MEMORY TECHNOLOGY DEVICES (MTD) > -M: David Woodhouse > -M: Brian Norris > M: Miquel Raynal > M: Richard Weinberger > M: Vignesh Raghavendra > @@ -16579,8 +16577,6 @@ F:drivers/media/pci/tw686x/ > > UBI FILE SYSTEM (UBIFS) > M: Richard Weinberger > -M: Artem Bityutskiy > -M: Adrian Hunter > L: linux-...@lists.infradead.org > T: git git://git.infradead.org/ubifs-2.6.git > W: http://www.linux-mtd.infradead.org/doc/ubifs.html > @@ -16697,7 +16693,6 @@ S:Maintained > F: drivers/scsi/ufs/ufs-mediatek* > > UNSORTED BLOCK IMAGES (UBI) > -M: Artem Bityutskiy > M: Richard Weinberger > W: http://www.linux-mtd.infradead.org/ > L: linux-...@lists.infradead.org >
Re: [PATCH] ubifs: ubifs_tnc_start_commit: Fix OOB in layout_in_gaps
Can the current modification method be confirmed? 在 2019/9/16 6:00, Richard Weinberger 写道: > I need to give this another thought
Re: [PATCH] MAINTAINERS: mtd/ubi/ubifs: Remove inactive maintainers
On Thu, 2019-10-17 at 16:22 +0200, Miquel Raynal wrote: > Despite their substantial personal investment in the MTD/UBI/UBIFS a > few years back, David, Brian, Artem and Adrian are not actively > maintaining the subsystem anymore. We warmly salute them for all the > work they have achieved and will of course still welcome their > participation and reviews. > > That said, Marek retired himself a few weeks ago quoting Harald [1]: > > It matters who has which title and when. Should somebody not > be an active maintainer, make sure he's not listed as such. > > For this same reason, let’s trim the maintainers list with the > actually active ones over the past two years. I am fine with being removed from maintainers, thanks!
Re: [PATCH 3/8] riscv: init: merge split string literals in preprocessor directive
On Fri, 18 Oct 2019, Luc Van Oostenryck wrote: > I quickly checked and gcc also complain about the second line: > $ cat y.c > #ifndef __riscv_cmodel_medany > #error "setup_vm() is called from head.S before relocate so it should " >"not use absolute addressing." > #endif > > $ gcc -c y.c > y.c:2:2: error: #error "setup_vm() is called from head.S before relocate so > it should " > #error "setup_vm() is called from head.S before relocate so it should " > ^ > y.c:3:8: error: expected identifier or '(' before string constant > "not use absolute addressing." > ^~ > > So it seems that gcc doesn't join these lines. I guess that's what I get for assuming that the original code was tested. Thanks for doing that, and sorry for the noise. > Fell free to add my: > Reviewed-by: Luc Van Oostenryck Done. - Paul
Re: memory offline infinite loop after soft offline
On Fri 18-10-19 02:19:06, Naoya Horiguchi wrote: > On Thu, Oct 17, 2019 at 08:27:59PM +0200, Michal Hocko wrote: > > On Thu 17-10-19 14:07:13, Qian Cai wrote: > > > On Thu, 2019-10-17 at 12:01 +0200, Michal Hocko wrote: > > > > On Thu 17-10-19 09:34:10, Naoya Horiguchi wrote: > > > > > On Mon, Oct 14, 2019 at 10:39:14AM +0200, Michal Hocko wrote: > > > > > > > > [...] > > > > > > diff --git a/mm/page_isolation.c b/mm/page_isolation.c > > > > > > index 89c19c0feadb..5fb3fee16fde 100644 > > > > > > --- a/mm/page_isolation.c > > > > > > +++ b/mm/page_isolation.c > > > > > > @@ -274,7 +274,7 @@ __test_page_isolated_in_pageblock(unsigned long > > > > > > pfn, unsigned long end_pfn, > > > > > > * simple way to verify that as VM_BUG_ON(), > > > > > > though. > > > > > > */ > > > > > > pfn += 1 << page_order(page); > > > > > > - else if (skip_hwpoisoned_pages && PageHWPoison(page)) > > > > > > + else if (skip_hwpoisoned_pages && > > > > > > PageHWPoison(compound_head(page))) > > > > > > /* A HWPoisoned page cannot be also PageBuddy */ > > > > > > pfn++; > > > > > > else > > > > > > > > > > This fix looks good to me. The original code only addresses > > > > > hwpoisoned 4kB-page, > > > > > we seem to have this issue since the following commit, > > > > > > > > Thanks a lot for double checking Naoya! > > > > > > > > > commit b023f46813cde6e3b8a8c24f432ff9c1fd8e9a64 > > > > > Author: Wen Congyang > > > > > Date: Tue Dec 11 16:00:45 2012 -0800 > > > > > > > > > > memory-hotplug: skip HWPoisoned page when offlining pages > > > > > > > > > > and extension of LTP coverage finally discovered this. > > > > > > > > Qian, could you give the patch some testing? > > > > > > Unfortunately, this does not solve the problem. It looks to me that in > > > soft_offline_huge_page(), set_hwpoison_free_buddy_page() will only set > > > PG_hwpoison for buddy pages, so the even the compound_head() has no > > > PG_hwpoison > > > set. > > > > > > if (PageBuddy(page_head) && page_order(page_head) >= order) { > > > if (!TestSetPageHWPoison(page)) > > > hwpoisoned = true; > > > > This is more than unexpected. How are we supposed to find out that the > > page is poisoned? Any idea Naoya? > > # sorry for my poor review... > > We set PG_hwpoison bit only on the head page for hugetlb, that's because > we handle multiple pages as a single one for hugetlb. So it's enough > to check isolation only on the head page. Simply skipping pfn cursor to > the page after the hugepage should avoid the infinite loop: But the page dump Qian provided shows that the head page doesn't have HWPoison bit either. If it had then going pfn at a time should just work because all tail pages would be skipped. Or do I miss something? > @@ -274,9 +274,13 @@ __test_page_isolated_in_pageblock(unsigned long pfn, > unsigned long end_pfn, >* simple way to verify that as VM_BUG_ON(), though. >*/ > pfn += 1 << page_order(page); > - else if (skip_hwpoisoned_pages && PageHWPoison(page)) > - /* A HWPoisoned page cannot be also PageBuddy */ > - pfn++; > + else if (skip_hwpoisoned_pages && > PageHWPoison(compound_head(page))) > + /* > +* A HWPoisoned page cannot be also PageBuddy. > +* PG_hwpoison could be set only on the head page in > +* hugetlb case, so no need to check tail pages. > +*/ > + pfn += 1 << compound_order(page); > else > break; > } > > Qian, could you please try this? > > Thanks, > Naoya Horiguchi -- Michal Hocko SUSE Labs
Re: [PATCH 5/8] riscv: add missing prototypes
On Fri, 18 Oct 2019, Luc Van Oostenryck wrote: > On Thu, Oct 17, 2019 at 05:49:26PM -0700, Paul Walmsley wrote: > > sparse identifies these missing prototypes when building arch/riscv: > > > > arch/riscv/kernel/cpu.c:149:29: warning: symbol 'cpuinfo_op' was not > > declared. Should it be static? > > arch/riscv/kernel/irq.c:27:29: warning: symbol 'do_IRQ' was not declared. > > Should it be static? > > arch/riscv/kernel/irq.c:57:13: warning: symbol 'init_IRQ' was not declared. > > Should it be static? > > arch/riscv/kernel/syscall_table.c:15:6: warning: symbol 'sys_call_table' > > was not declared. Should it be static? > > arch/riscv/kernel/time.c:15:13: warning: symbol 'time_init' was not > > declared. Should it be static? > > arch/riscv/kernel/smpboot.c:135:24: warning: symbol 'smp_callin' was not > > declared. Should it be static? > > arch/riscv/kernel/smp.c:72:5: warning: symbol 'setup_profiling_timer' was > > not declared. Should it be static? > > arch/riscv/mm/init.c:151:7: warning: symbol 'trampoline_pg_dir' was not > > declared. Should it be static? > > arch/riscv/mm/init.c:157:7: warning: symbol 'early_pg_dir' was not > > declared. Should it be static? > > arch/riscv/kernel/process.c:32:6: warning: symbol 'show_regs' was not > > declared. Should it be static? > > arch/riscv/kernel/ptrace.c:151:6: warning: symbol 'do_syscall_trace_enter' > > was not declared. Should it be static? > > arch/riscv/kernel/ptrace.c:165:6: warning: symbol 'do_syscall_trace_exit' > > was not declared. Should it be static? > > > > Fix by adding the missing prototypes to the appropriate header files. > > For functions defined in C but used ony in assembly, you can also simply mark > them as '__visible' (aka __attribute__((exrernally_visible)) ). Thanks, I'll take this suggestion. - Paul
Re: [PATCH v3 2/6] thermal: Initialize thermal subsystem earlier
On 17-10-19, 17:57, Amit Kucheria wrote: > Now that the thermal framework is built-in, in order to facilitate > thermal mitigation as early as possible in the boot cycle, move the > thermal framework initialization to core_initcall. > > Signed-off-by: Amit Kucheria > --- > drivers/thermal/thermal_core.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c > index d21b754baee2..d8251d723459 100644 > --- a/drivers/thermal/thermal_core.c > +++ b/drivers/thermal/thermal_core.c > @@ -1537,4 +1537,5 @@ static int __init thermal_init(void) > mutex_destroy(&poweroff_lock); > return result; > } > -fs_initcall(thermal_init); > + remove the blank line please. > +core_initcall(thermal_init); Acked-by: Viresh Kumar -- viresh
Re: [PATCH v3 5/6] clk: qcom: Initialise clock drivers earlier
On 17-10-19, 10:47, Stephen Boyd wrote: > Quoting Amit Kucheria (2019-10-17 05:27:37) > > Initialise the clock drivers on sdm845 and qcs404 in core_initcall so we > > can have earlier access to cpufreq during booting. > > > > Signed-off-by: Amit Kucheria > > --- > > Acked-by: Stephen Boyd > > Makes me sad again. I am wondering why it makes you sad ? :) -- viresh
Re: [PATCH] cpufreq: flush any pending policy update work scheduled before freeing
On 18-10-19, 06:55, Sudeep Holla wrote: > On Thu, Oct 17, 2019 at 11:26:54PM +0200, Rafael J. Wysocki wrote: > > On Thu, Oct 17, 2019 at 9:36 PM Rafael J. Wysocki wrote: > > > > > > On Thu, Oct 17, 2019 at 6:35 PM Sudeep Holla wrote: > > > > > > > > dev_pm_qos_remove_request ends calling {max,min}_freq_req QoS notifiers > > > > which schedule policy update work. It may end up racing with the freeing > > > > the policy and unregistering the driver. > > > > > > > > One possible race is as below where the cpufreq_driver is unregistered > > > > but the scheduled work gets executed at later stage when cpufreq_driver > > > > is NULL(i.e. after freeing the policy and driver) > > > > > > > > Unable to handle kernel NULL pointer dereference at virtual address > > > > 001c > > > > pgd = (ptrval) > > > > [001c] *pgd=8080204003, *pmd= > > > > Internal error: Oops: 206 [#1] SMP THUMB2 > > > > Modules linked in: > > > > CPU: 0 PID: 34 Comm: kworker/0:1 Not tainted > > > > 5.4.0-rc3-6-g67f5a8081a4b #86 > > > > Hardware name: ARM-Versatile Express > > > > Workqueue: events handle_update > > > > PC is at cpufreq_set_policy+0x58/0x228 > > > > LR is at dev_pm_qos_read_value+0x77/0xac > > > > Control: 70c5387d Table: 80203000 DAC: fffd > > > > Process kworker/0:1 (pid: 34, stack limit = 0x(ptrval)) > > > > (cpufreq_set_policy) from > > > > (refresh_frequency_limits.part.24+0x37/0x48) > > > > (refresh_frequency_limits.part.24) from > > > > (handle_update+0x2f/0x38) > > > > (handle_update) from (process_one_work+0x16d/0x3cc) > > > > (process_one_work) from (worker_thread+0xff/0x414) > > > > (worker_thread) from (kthread+0xff/0x100) > > > > (kthread) from (ret_from_fork+0x11/0x28) > > > > > > > > Cc: "Rafael J. Wysocki" > > > > Cc: Viresh Kumar > > > > Signed-off-by: Sudeep Holla > > > > --- > > > > drivers/cpufreq/cpufreq.c | 3 +++ > > > > 1 file changed, 3 insertions(+) > > > > > > > > Hi Rafael, Viresh, > > > > > > > > This fixed the boot issue I reported[1] on TC2 with bL switcher enabled. > > > > I have based this patch on -rc3 and not on top of your patches. This > > > > only fixes the boot issue but I hit the other crashes while continuously > > > > switching on and off the bL switcher that register/unregister the driver > > > > Your patch series fixes them. I can based this on top of those if you > > > > prefer. > > > > > > > > Regards, > > > > Sudeep > > > > > > > > [1] https://lore.kernel.org/linux-pm/20191015155735.GA29105@bogus/ > > > > > > > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > > > > index c52d6fa32aac..b703c29a84be 100644 > > > > --- a/drivers/cpufreq/cpufreq.c > > > > +++ b/drivers/cpufreq/cpufreq.c > > > > @@ -1278,6 +1278,9 @@ static void cpufreq_policy_free(struct > > > > cpufreq_policy *policy) > > > > } > > > > > > > > dev_pm_qos_remove_request(policy->min_freq_req); > > > > + /* flush the pending policy->update work before freeing the > > > > policy */ > > > > + if (work_pending(&policy->update)) > > > > > > Isn't this racy? > > > > > > It still may be running if the pending bit is clear and we still need > > > to wait for it then, don't we? > > > > > > Why don't you do an unconditional flush_work() here? > > > > You may as well do a cancel_work_sync() here, because whether or not > > the last update of the policy happens before it goes away is a matter > > of timing in any case > > In fact that's the first thing I tried to fix the issue I was seeing. > But I then thought it would be better to complete the update as the PM > QoS were getting updated back to DEFAULT values for the device. Even > this works. > > What is your preference ? flush_work or cancel_work_sync ? I will > update accordingly. I may need to do some more testing with > cancel_work_sync as I just checked that quickly to confirm the race. As I said in the other email, this work didn't come as a result of removal of the qos request from cpufreq core and so must have come from other thermal or similar events. In that case maybe doing flush_work() is better before we remove the cpufreq driver. Though Rafael's timing related comment makes sense as well, but now that we have received the work before policy is removed, I will rather complete the work and quit. -- viresh
Re: RISC-V nommu support v5
Hi Paul/Palmer, On Thu, Oct 17, 2019 at 11:07 PM Christoph Hellwig wrote: > > Hi all, > > below is a series to support nommu mode on RISC-V. For now this series > just works under qemu with the qemu-virt platform, but Damien has also > been able to get kernel based on this tree with additional driver hacks > to work on the Kendryte KD210, but that will take a while to cleanup > an upstream. > > A git tree is available here: > > git://git.infradead.org/users/hch/riscv.git riscv-nommu.5 > > Gitweb: > > > http://git.infradead.org/users/hch/riscv.git/shortlog/refs/heads/riscv-nommu.5 > > I've also pushed out a builtroot branch that can build a RISC-V nommu > root filesystem here: > >git://git.infradead.org/users/hch/buildroot.git riscv-nommu.2 > > Gitweb: > > > http://git.infradead.org/users/hch/buildroot.git/shortlog/refs/heads/riscv-nommu.2 It will be really cool to have this series for Linux-5.4-rcX. Best Regards, Anup > > > Changes since v4: > - rebased to 5.4-rc + latest riscv fixes > - clean up do_trap_break > - fix an SR_XPIE issue (Paul Walmsley) > - use the symbolic PAGE_OFFSET value in the flat loader >(Aurabindo Jayamohanan) > > Changes since v3: > - improve a few commit message > - cleanup riscv_cpuid_to_hartid_mask > - cleanup the timer handling > - cleanup the IPI handling a little more > - renamed CONFIG_M_MODE to CONFIG_RISCV_M_MODE > - split out CONFIG_RISCV_SBI to make some of the ifdefs more obbious > - use IS_ENABLED wherever possible instead of if ifdefs to make the >code more readable > > Changes since v2: > - rebased to 5.3-rc > - remove the EFI image header for nommu builds > - set ARCH_SLAB_MINALIGN to ensure stack alignment in the flat binary >loader > - minor comment improvement > - use #defines for more CSRs > > Changes since v1: > - fixes so that a kernel with this series still work on builds with an >IOMMU > - small clint cleanups > - the binfmt_flat base and buildroot now don't put arguments on the stack > > ___ > linux-riscv mailing list > linux-ri...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
Re: [PATCH v2 4/5] cpufreq: vexpress-spc: remove lots of debug messages
On Fri, Oct 18, 2019 at 11:27:20AM +0530, Viresh Kumar wrote: > On 17-10-19, 13:35, Sudeep Holla wrote: > > This driver have been used and tested for year now and the extensive > > debug/log messages in the driver are not really required anymore. > > Get rid of those unnecessary log messages. > > > > Signed-off-by: Sudeep Holla > > --- > > drivers/cpufreq/vexpress-spc-cpufreq.c | 72 +- > > 1 file changed, 13 insertions(+), 59 deletions(-) > > > > diff --git a/drivers/cpufreq/vexpress-spc-cpufreq.c > > b/drivers/cpufreq/vexpress-spc-cpufreq.c > > static void put_cluster_clk_and_freq_table(struct device *cpu_dev, > > @@ -324,11 +296,9 @@ static void put_cluster_clk_and_freq_table(struct > > device *cpu_dev, > > > > for_each_present_cpu(i) { > > struct device *cdev = get_cpu_device(i); > > - if (!cdev) { > > - pr_err("%s: failed to get cpu%d device\n", __func__, i); > > - return; > > - } > > > > + if (!cdev) > > + return; > > We had a blank line after this, which isn't there in your version > anymore. Please keep that here and few more places below. > Ah, this one is spurious change when doing in bulk not intended. I will add back the blank line. -- Regards, Sudeep
Re: possible audio regression for usb-audio with 5.3 kernel (5.3.1), sounds like variants of 8-bit audio
On Wed, 02 Oct 2019 17:01:29 +0200, Matt wrote: > > Hi Takashi, > > there appears to be a sound regression for plug-n-play usb-audio DACs > with 5.3 kernel. > > I'm using the following one: > > https://www.aliexpress.com/item/33012416525.html?spm=a2g0s.9042311.0.0.4f314c4dv3EF0p > > which includes SA9023A + ES9018K2M on the chip. > > When listening to parts of the Unreal Tournament 3 soundtrack the > output resembles a bit like: > > https://www.youtube.com/watch?v=9gq4R6acnBQ Rush - Tom Sawyer (8-bit > NES audio render) > > it immediately made me think of 8-bit audio and the NES. > > First thought of misconfiguration in the kernel config but then went > back to 5.2.17-rt9 (copying the config and only enabling full > preemption) and there the output is correct and crystal clear. > > For each kernel build I need to jump through a few hoops (nvidia > driver, zfsonlinux modules, luks, genkernel, etc.) so it'll take a > while to build and get it up and running. I don't know of a similar regression, and have currently no idea of possible cause. The git bisection would be the best option to spot out the cause, I suppose. For that, it'd be maybe helpful to reduce the reproducible condition, e.g. try to boot with the stock Linus kernel without Nvidia graphics and reduced configuration. Basically you don't need the graphics environment for reproducing the audio problem. This will make the git bisection much easier. thanks, Takashi > > System is: > cat /etc/lsb-release > DISTRIB_ID="Gentoo" > > ~amd64 > > gcc version 9.2.0 (Gentoo Hardened 9.2.0-r1 p2) > GNU ld (Gentoo 2.32 p2) 2.32.0 > > PCIe related sound doesn't seem to be affected (Xonar DX), it works > fine both on 5.3.1 and 5.2.17-rt9 > > Kind Regards > > Matthew >
linux-next: manual merge of the akpm-current tree with the printk tree
Hi all, Today's linux-next merge of the akpm-current tree got a conflict in: lib/Kconfig.debug between commit: 57f5677e535b ("printf: add support for printing symbolic error names") from the printk tree and patch: "kernel-hacking: move DEBUG_BUGVERBOSE to 'printk and dmesg options'" from the akpm-current tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell diff --cc lib/Kconfig.debug index 045ef7caeb49,83bb867fcb6f.. --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@@ -164,15 -164,15 +164,24 @@@ config DYNAMIC_DEBU See Documentation/admin-guide/dynamic-debug-howto.rst for additional information. +config SYMBOLIC_ERRNAME + bool "Support symbolic error names in printf" + default y if PRINTK + help +If you say Y here, the kernel's printf implementation will +be able to print symbolic error names such as ENOSPC instead +of the number 28. It makes the kernel image slightly larger +(about 3KB), but can make the kernel logs easier to read. + + config DEBUG_BUGVERBOSE + bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT + depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE) + default y + help + Say Y here to make BUG() panics output the file name and line number + of the BUG call as well as the EIP and oops trace. This aids + debugging but costs about 70-100K of memory. + endmenu # "printk and dmesg options" menu "Compile-time checks and compiler options" pgpey2veWfVIC.pgp Description: OpenPGP digital signature
Re: [PATCH v2 5/5] cpufreq: vexpress-spc: fix some coding style issues
On Fri, Oct 18, 2019 at 11:25:17AM +0530, Viresh Kumar wrote: > On 17-10-19, 13:35, Sudeep Holla wrote: > > Fix the following checkpatch checks/warnings: > > > > CHECK: Unnecessary parentheses around the code > > CHECK: Alignment should match open parenthesis > > CHECK: Prefer kernel type 'u32' over 'uint32_t' > > WARNING: Missing a blank line after declarations > > > > Signed-off-by: Sudeep Holla > > --- > > drivers/cpufreq/vexpress-spc-cpufreq.c | 43 -- > > 1 file changed, 20 insertions(+), 23 deletions(-) > > > > diff --git a/drivers/cpufreq/vexpress-spc-cpufreq.c > > b/drivers/cpufreq/vexpress-spc-cpufreq.c > > index 81064430317f..8ecb2961be86 100644 > > --- a/drivers/cpufreq/vexpress-spc-cpufreq.c > > +++ b/drivers/cpufreq/vexpress-spc-cpufreq.c > > @@ -79,8 +79,8 @@ static unsigned int find_cluster_maxfreq(int cluster) > > for_each_online_cpu(j) { > > cpu_freq = per_cpu(cpu_last_req_freq, j); > > > > - if ((cluster == per_cpu(physical_cluster, j)) && > > - (max_freq < cpu_freq)) > > + if (cluster == per_cpu(physical_cluster, j) && > > + max_freq < cpu_freq) > > max_freq = cpu_freq; > > } > > > > @@ -188,22 +188,19 @@ static int ve_spc_cpufreq_set_target(struct > > cpufreq_policy *policy, > > freqs_new = freq_table[cur_cluster][index].frequency; > > > > if (is_bL_switching_enabled()) { > > - if ((actual_cluster == A15_CLUSTER) && > > - (freqs_new < clk_big_min)) { > > + if (actual_cluster == A15_CLUSTER && freqs_new < clk_big_min) > > new_cluster = A7_CLUSTER; > > - } else if ((actual_cluster == A7_CLUSTER) && > > - (freqs_new > clk_little_max)) { > > + else if (actual_cluster == A7_CLUSTER && > > +freqs_new > clk_little_max) > > new_cluster = A15_CLUSTER; > > - } > > } > > > > ret = ve_spc_cpufreq_set_rate(cpu, actual_cluster, new_cluster, > > freqs_new); > > > > - if (!ret) { > > + if (!ret) > > That's not the standard way in Linux I believe. We do use {} even when > the body is single line but broken into two, like below. > OK, wasn't aware of that. I will update. Generally I ignore checkpatch warnings, but the list was big and fixed a bunch of them :) -- Regards, Sudeep
Re: [PATCH v2 1/2] dt-bindings: gpio: brcm: Add bindings for xgs-iproc
czw., 17 paź 2019 o 21:24 Rob Herring napisał(a): > > On Thu, Oct 17, 2019 at 04:10:50PM +1300, Chris Packham wrote: > > This GPIO controller is present on a number of Broadcom switch ASICs > > with integrated SoCs. It is similar to the nsp-gpio and iproc-gpio > > blocks but different enough to require a separate driver. > > > > Signed-off-by: Chris Packham > > --- > > > > Notes: > > Changes in v2: > > - Document as DT schema > > - Include ngpios, #gpio-cells and gpio-controller properties > > > > .../bindings/gpio/brcm,xgs-iproc.yaml | 83 +++ > > 1 file changed, 83 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/gpio/brcm,xgs-iproc.yaml > > > > diff --git a/Documentation/devicetree/bindings/gpio/brcm,xgs-iproc.yaml > > b/Documentation/devicetree/bindings/gpio/brcm,xgs-iproc.yaml > > new file mode 100644 > > index ..71998551209e > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/gpio/brcm,xgs-iproc.yaml > > @@ -0,0 +1,83 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/gpio/brcm,xgs-iproc.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Broadcom XGS iProc GPIO controller > > + > > +maintainers: > > + - Chris Packham > > + > > +description: | > > + This controller is the Chip Common A GPIO present on a number of Broadcom > > + switch ASICs with integrated SoCs. > > + > > +properties: > > + compatible: > > +enum: > > + - brcm,iproc-gpio-cca > > enum vs. const usage depends on whether you think you'll add more > compatibles. > What if you don't know yet? For instance we use a const compatible and then a new chip is released for which we can reuse the driver? Is this something that is expected to remain stable in the binding document? The question is unrelated to this patch, I'm just unsure about my own approach to writing yaml bindings. Bart > > + > > + reg: > > +minItems: 2 > > +maxItems: 2 > > +description: > > + The first region defines the base I/O address containing > > + the GPIO controller registers. The second region defines > > + the I/O address containing the Chip Common A interrupt > > + registers. > > items: > - description: the I/O address containing the GPIO controller > registers > - description: the I/O address containing the Chip Common A interrupt > registers > > And minItems/maxItems can be implicit. > > > + > > + gpio-controller: true > > + > > + '#gpio-cells': > > + const: 2 > > + > > + ngpios: > > +$ref: /schemas/types.yaml#/definitions/uint32 > > Common property, doesn't need a type definition. Also, it would have to > be under an 'allOf' to actually work. > > > +minimum: 0 > > +maximum: 32 > > + > > + interrupt-controller: > > +type: boolean > > Just 'interrupt-controller: true' > > > + > > + '#interrupt-cells': > > +const: 2 > > + > > + interrupts: > > +maxItems: 1 > > + > > +required: > > + - compatible > > + - reg > > + - "#gpio-cells" > > + - gpio-controller > > + > > +allOf: > > + - if: > > + properties: > > + interrupt-controller: > > + contains: > > + const: true > > + then: > > + required: > > + - interrupts > > + - '#interrupt-cells' > > This is mostly handled in the core schema already and 'dependencies' > works better for this anyways. All you need here is: > > dependencies: > interrupt-controller: [ interrupts ] > > > + > > +examples: > > + - | > > +#include > > +#include > > +gpio@1860 { > > +compatible = "brcm,iproc-gpio-cca"; > > +#gpio-cells = <2>; > > +reg = <0x1860 0x50>, > > + <0x1800 0x50>; > > +ngpios = <12>; > > +gpio-controller; > > +interrupt-controller; > > +#interrupt-cells = <2>; > > +interrupts = ; > > +}; > > + > > + > > +... > > -- > > 2.23.0 > >
[PATCH] arm64: dts: qcom: c630: Add WiFi node
Specify regulators and enable the &wifi node. The firmware uses the 8 bit version of the host capability message, so specify this quirk. Signed-off-by: Bjorn Andersson --- arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts index 01709951fdb6..53d4d40dfe43 100644 --- a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts +++ b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts @@ -461,3 +461,14 @@ vdda-phy-supply = <&vdda_usb2_ss_1p2>; vdda-pll-supply = <&vdda_usb2_ss_core>; }; + +&wifi { + status = "okay"; + + vdd-0.8-cx-mx-supply = <&vreg_l5a_0p8>; + vdd-1.8-xo-supply = <&vreg_l7a_1p8>; + vdd-1.3-rfa-supply = <&vreg_l17a_1p3>; + vdd-3.3-ch0-supply = <&vreg_l25a_3p3>; + + qcom,snoc-host-cap-8bit-quirk; +}; -- 2.23.0
[PATCH] arm64: dts: qcom: c630: Enable UFS device reset
Setup the TLMM UFS_RESET to make the UFS core reset the UFS memory device during initialization. Signed-off-by: Bjorn Andersson --- arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts index 13dc619687f3..01709951fdb6 100644 --- a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts +++ b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts @@ -7,6 +7,7 @@ /dts-v1/; +#include #include #include "sdm845.dtsi" #include "pm8998.dtsi" @@ -394,6 +395,8 @@ &ufs_mem_hc { status = "okay"; + reset-gpios = <&tlmm 150 GPIO_ACTIVE_LOW>; + vcc-supply = <&vreg_l20a_2p95>; vcc-max-microamp = <60>; }; -- 2.23.0
Re: [PATCH] Bluetooth: hci_qca: fix in-band sleep enablement
Hi Balakrishna, Sorry for the late reply. I was on vacation for the past few days. The chipset we use is QCA6174A-3 and rjliao has already confirmed that IBS won't work without RAM fw downloaded. Please ignore this change. Thanks, Claire On Fri, Oct 11, 2019 at 3:21 PM Balakrishna Godavarthi wrote: > > Hi Claire, > > This change will not work as we need fw files to be loaded tofor IBS to > active. > may i know on which chipset you have this issue of IBS active even with > out fw download. > > On 2019-10-11 12:31, Harish Bandi wrote: > > ++ Balakrishna > > > > On 2019-10-09 14:21, Claire Chang wrote: > >> Enabling in-band sleep when there is no patch/nvm-config found and > >> bluetooth is running with the original fw/config. > >> > >> Fixes: ba8f35979002 ("Bluetooth: hci_qca: Avoid setup failure on > >> missing rampatch") > >> Fixes: 7dc5fe0814c3 ("Bluetooth: hci_qca: Avoid missing rampatch > >> failure with userspace fw loader") > >> Signed-off-by: Claire Chang > >> --- > >> drivers/bluetooth/hci_qca.c | 11 +++ > >> 1 file changed, 7 insertions(+), 4 deletions(-) > >> > >> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c > >> index e3164c200eac..367eef893a11 100644 > >> --- a/drivers/bluetooth/hci_qca.c > >> +++ b/drivers/bluetooth/hci_qca.c > >> @@ -1291,10 +1291,8 @@ static int qca_setup(struct hci_uart *hu) > >> /* Setup patch / NVM configurations */ > >> ret = qca_uart_setup(hdev, qca_baudrate, soc_type, soc_ver, > >> firmware_name); > >> -if (!ret) { > >> -set_bit(QCA_IBS_ENABLED, &qca->flags); > >> -qca_debugfs_init(hdev); > >> -} else if (ret == -ENOENT) { > >> + > >> +if (ret == -ENOENT) { > >> /* No patch/nvm-config found, run with original fw/config */ > >> ret = 0; > >> } else if (ret == -EAGAIN) { > >> @@ -1305,6 +1303,11 @@ static int qca_setup(struct hci_uart *hu) > >> ret = 0; > >> } > >> > >> +if (!ret) { > >> +set_bit(QCA_IBS_ENABLED, &qca->flags); > >> +qca_debugfs_init(hdev); > >> +} > >> + > >> /* Setup bdaddr */ > >> if (qca_is_wcn399x(soc_type)) > >> hu->hdev->set_bdaddr = qca_set_bdaddr; > > -- > Regards > Balakrishna.
Re: [PATCH v2 4/5] cpufreq: vexpress-spc: remove lots of debug messages
On 17-10-19, 13:35, Sudeep Holla wrote: > This driver have been used and tested for year now and the extensive > debug/log messages in the driver are not really required anymore. > Get rid of those unnecessary log messages. > > Signed-off-by: Sudeep Holla > --- > drivers/cpufreq/vexpress-spc-cpufreq.c | 72 +- > 1 file changed, 13 insertions(+), 59 deletions(-) > > diff --git a/drivers/cpufreq/vexpress-spc-cpufreq.c > b/drivers/cpufreq/vexpress-spc-cpufreq.c > static void put_cluster_clk_and_freq_table(struct device *cpu_dev, > @@ -324,11 +296,9 @@ static void put_cluster_clk_and_freq_table(struct device > *cpu_dev, > > for_each_present_cpu(i) { > struct device *cdev = get_cpu_device(i); > - if (!cdev) { > - pr_err("%s: failed to get cpu%d device\n", __func__, i); > - return; > - } > > + if (!cdev) > + return; We had a blank line after this, which isn't there in your version anymore. Please keep that here and few more places below. > _put_cluster_clk_and_freq_table(cdev, cpumask); > } > > @@ -354,19 +324,12 @@ static int _get_cluster_clk_and_freq_table(struct > device *cpu_dev, > goto out; > > ret = dev_pm_opp_init_cpufreq_table(cpu_dev, &freq_table[cluster]); > - if (ret) { > - dev_err(cpu_dev, "%s: failed to init cpufreq table, cpu: %d, > err: %d\n", > - __func__, cpu_dev->id, ret); > + if (ret) > goto out; > - } > > clk[cluster] = clk_get(cpu_dev, NULL); > - if (!IS_ERR(clk[cluster])) { > - dev_dbg(cpu_dev, "%s: clk: %p & freq table: %p, cluster: %d\n", > - __func__, clk[cluster], freq_table[cluster], > - cluster); > + if (!IS_ERR(clk[cluster])) > return 0; > - } > > dev_err(cpu_dev, "%s: Failed to get clk for cpu: %d, cluster: %d\n", > __func__, cpu_dev->id, cluster); > @@ -401,11 +364,9 @@ static int get_cluster_clk_and_freq_table(struct device > *cpu_dev, >*/ > for_each_present_cpu(i) { > struct device *cdev = get_cpu_device(i); > - if (!cdev) { > - pr_err("%s: failed to get cpu%d device\n", __func__, i); > - return -ENODEV; > - } > > + if (!cdev) > + return -ENODEV; > ret = _get_cluster_clk_and_freq_table(cdev, cpumask); > if (ret) > goto put_clusters; > @@ -419,19 +380,14 @@ static int get_cluster_clk_and_freq_table(struct device > *cpu_dev, > clk_big_min = get_table_min(freq_table[0]); > clk_little_max = VIRT_FREQ(1, get_table_max(freq_table[1])); > > - pr_debug("%s: cluster: %d, clk_big_min: %d, clk_little_max: %d\n", > - __func__, cluster, clk_big_min, clk_little_max); > - > return 0; > > put_clusters: > for_each_present_cpu(i) { > struct device *cdev = get_cpu_device(i); > - if (!cdev) { > - pr_err("%s: failed to get cpu%d device\n", __func__, i); > - return -ENODEV; > - } > > + if (!cdev) > + return -ENODEV; > _put_cluster_clk_and_freq_table(cdev, cpumask); > } > > @@ -500,8 +456,6 @@ static int ve_spc_cpufreq_exit(struct cpufreq_policy > *policy) > } > > put_cluster_clk_and_freq_table(cpu_dev, policy->related_cpus); > - dev_dbg(cpu_dev, "%s: Exited, cpu: %d\n", __func__, policy->cpu); > - > return 0; > } > > -- > 2.17.1 -- viresh
[PATCH v2] arm64: dts: qcom: c630: Enable adsp, cdsp and mpss
Specify the firmware-name for the adsp, cdsp and mpss and enable the nodes. Signed-off-by: Bjorn Andersson --- .../boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 14 ++ 1 file changed, 14 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts index ded120d3aef5..13dc619687f3 100644 --- a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts +++ b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts @@ -20,6 +20,11 @@ }; }; +&adsp_pas { + firmware-name = "qcom/LENOVO/81JL/qcadsp850.mbn"; + status = "okay"; +}; + &apps_rsc { pm8998-rpmh-regulators { compatible = "qcom,pm8998-rpmh-regulators"; @@ -229,6 +234,11 @@ status = "disabled"; }; +&cdsp_pas { + firmware-name = "qcom/LENOVO/81JL/qccdsp850.mbn"; + status = "okay"; +}; + &gcc { protected-clocks = , , @@ -296,6 +306,10 @@ }; }; +&mss_pil { + firmware-name = "qcom/LENOVO/81JL/qcdsp1v2850.mbn", "qcom/LENOVO/81JL/qcdsp2850.mbn"; +}; + &qup_i2c12_default { drive-strength = <2>; bias-disable; -- 2.23.0
Re: [PATCH] cpufreq: flush any pending policy update work scheduled before freeing
On Thu, Oct 17, 2019 at 11:26:54PM +0200, Rafael J. Wysocki wrote: > On Thu, Oct 17, 2019 at 9:36 PM Rafael J. Wysocki wrote: > > > > On Thu, Oct 17, 2019 at 6:35 PM Sudeep Holla wrote: > > > > > > dev_pm_qos_remove_request ends calling {max,min}_freq_req QoS notifiers > > > which schedule policy update work. It may end up racing with the freeing > > > the policy and unregistering the driver. > > > > > > One possible race is as below where the cpufreq_driver is unregistered > > > but the scheduled work gets executed at later stage when cpufreq_driver > > > is NULL(i.e. after freeing the policy and driver) > > > > > > Unable to handle kernel NULL pointer dereference at virtual address > > > 001c > > > pgd = (ptrval) > > > [001c] *pgd=8080204003, *pmd= > > > Internal error: Oops: 206 [#1] SMP THUMB2 > > > Modules linked in: > > > CPU: 0 PID: 34 Comm: kworker/0:1 Not tainted > > > 5.4.0-rc3-6-g67f5a8081a4b #86 > > > Hardware name: ARM-Versatile Express > > > Workqueue: events handle_update > > > PC is at cpufreq_set_policy+0x58/0x228 > > > LR is at dev_pm_qos_read_value+0x77/0xac > > > Control: 70c5387d Table: 80203000 DAC: fffd > > > Process kworker/0:1 (pid: 34, stack limit = 0x(ptrval)) > > > (cpufreq_set_policy) from > > > (refresh_frequency_limits.part.24+0x37/0x48) > > > (refresh_frequency_limits.part.24) from (handle_update+0x2f/0x38) > > > (handle_update) from (process_one_work+0x16d/0x3cc) > > > (process_one_work) from (worker_thread+0xff/0x414) > > > (worker_thread) from (kthread+0xff/0x100) > > > (kthread) from (ret_from_fork+0x11/0x28) > > > > > > Cc: "Rafael J. Wysocki" > > > Cc: Viresh Kumar > > > Signed-off-by: Sudeep Holla > > > --- > > > drivers/cpufreq/cpufreq.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > Hi Rafael, Viresh, > > > > > > This fixed the boot issue I reported[1] on TC2 with bL switcher enabled. > > > I have based this patch on -rc3 and not on top of your patches. This > > > only fixes the boot issue but I hit the other crashes while continuously > > > switching on and off the bL switcher that register/unregister the driver > > > Your patch series fixes them. I can based this on top of those if you > > > prefer. > > > > > > Regards, > > > Sudeep > > > > > > [1] https://lore.kernel.org/linux-pm/20191015155735.GA29105@bogus/ > > > > > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > > > index c52d6fa32aac..b703c29a84be 100644 > > > --- a/drivers/cpufreq/cpufreq.c > > > +++ b/drivers/cpufreq/cpufreq.c > > > @@ -1278,6 +1278,9 @@ static void cpufreq_policy_free(struct > > > cpufreq_policy *policy) > > > } > > > > > > dev_pm_qos_remove_request(policy->min_freq_req); > > > + /* flush the pending policy->update work before freeing the > > > policy */ > > > + if (work_pending(&policy->update)) > > > > Isn't this racy? > > > > It still may be running if the pending bit is clear and we still need > > to wait for it then, don't we? > > > > Why don't you do an unconditional flush_work() here? > > You may as well do a cancel_work_sync() here, because whether or not > the last update of the policy happens before it goes away is a matter > of timing in any case In fact that's the first thing I tried to fix the issue I was seeing. But I then thought it would be better to complete the update as the PM QoS were getting updated back to DEFAULT values for the device. Even this works. What is your preference ? flush_work or cancel_work_sync ? I will update accordingly. I may need to do some more testing with cancel_work_sync as I just checked that quickly to confirm the race. -- Regards, Sudeep
Re: [RFC][PATCH 2/3] usb: roles: Add usb role switch notifier.
On Wed, Oct 16, 2019 at 12:27 AM Hans de Goede wrote: > On 10/15/19 7:39 AM, John Stultz wrote: > > On Thu, Oct 3, 2019 at 1:51 PM Hans de Goede wrote: > >> On 03-10-2019 22:37, John Stultz wrote: > >>> Fair point. I'm sort of taking a larger patchset and trying to break > >>> it up into more easily reviewable chunks, but I guess here I mis-cut. > >>> > >>> The user is the hikey960 gpio hub driver here: > >>> > >>> https://git.linaro.org/people/john.stultz/android-dev.git/commit/?id=b06158a2d3eb00c914f12c76c93695e92d9af00f > >> > >> Hmm, that seems to tie the TypeC data-role to the power-role, which > >> is not going to work with role swapping. > > > > Thanks again for the feedback here. Sorry for the slow response. Been > > reworking some of the easier changes but am starting to look at how to > > address your feedback here. > > > >> What is controlling the usb-role-switch, and thus ultimately > >> causing the notifier you are suggesting to get called ? > > > > The tcpm_mux_set() call via tcpm_state_machine_work() > > > >> Things like TYPEC_VBUS_POWER_OFF and TYPEC_VBUS_POWER_ON > >> really beg to be modeled as a regulator and then the > >> Type-C controller (using e.g. the drivers/usb/typec/tcpm/tcpm.c > >> framework) can use that regulator to control things. > >> in case of the tcpm.c framework it can then use that > >> regulator to implement the set_vbus callback. > > > > So I'm looking at the bindings and I'm not sure exactly how to tie a > > regulator style driver into the tcpm for this? > > Looking at the driver I just see this commented out bit: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/typec/tcpm/tcpm.c#n3075 > > > > Do you happen to have a pointer to something closer to what you are > > describing? > > Look at the tcpm_set_vbus implementation in drivers/usb/typec/tcpm/fusb302.c > you need to do something similar in your Type-C controller driver and > export the GPIO as as a gpio-controlled regulator and tie the regulator to > the connector. Thanks for the suggestion, I really appreciate it! One more question though, since I'm using the tcpci_rt1711h driver, which re-uses the somewhat sparse tcpci.c implementation, would you recommend trying to add generic regulator support to the tcpci code or trying to extend the implementation somehow allow the tcpci_rt1711h driver replace just the set_vbus function? thanks -john
Re: [PATCH V3] mm/page_alloc: Add alloc_contig_pages()
On 10/18/2019 02:44 AM, John Hubbard wrote: > On 10/17/19 1:24 AM, Anshuman Khandual wrote: >> HugeTLB helper alloc_gigantic_page() implements fairly generic allocation >> method where it scans over various zones looking for a large contiguous pfn >> range before trying to allocate it with alloc_contig_range(). Other than >> deriving the requested order from 'struct hstate', there is nothing HugeTLB >> specific in there. This can be made available for general use to allocate >> contiguous memory which could not have been allocated through the buddy >> allocator. >> >> alloc_gigantic_page() has been split carving out actual allocation method >> which is then made available via new alloc_contig_pages() helper wrapped >> under CONFIG_CONTIG_ALLOC. All references to 'gigantic' have been replaced >> with more generic term 'contig'. Allocated pages here should be freed with >> free_contig_range() or by calling __free_page() on each allocated page. >> >> Cc: Mike Kravetz >> Cc: Andrew Morton >> Cc: Vlastimil Babka >> Cc: Michal Hocko >> Cc: David Rientjes >> Cc: Andrea Arcangeli >> Cc: Oscar Salvador >> Cc: Mel Gorman >> Cc: Mike Rapoport >> Cc: Dan Williams >> Cc: Pavel Tatashin >> Cc: Matthew Wilcox >> Cc: David Hildenbrand >> Cc: linux-kernel@vger.kernel.org >> Acked-by: David Hildenbrand >> Acked-by: Michal Hocko >> Signed-off-by: Anshuman Khandual >> --- >> This is based on https://patchwork.kernel.org/patch/11190213/ > > Hi Anshuman, > > I'm having trouble finding a tree that this applies cleanly too, > which one did you use? (latest linux-next, or linux.git would be > nice). Hello John, Yeah, it is bit non-trivial because v5 of the pgtable tests are still on the latest linux-next (20191015 or 20191017). You will need to revert the following patches. 1. mm/hugetlb: make alloc_gigantic_page() available for general use 2. mm/debug: add tests validating architecture page table helpers 3. mm-debug-add-tests-validating-architecture-page-table-helpers-fix and apply the following patch (https://patchwork.kernel.org/patch/11190213/) 1. hugetlbfs: don't access uninitialized memmaps in pfn_range_valid_gigantic() After which this particular patch here will apply cleanly. Hope this helps. - Anshuman > > > thanks, > > John Hubbard > NVIDIA > > >> >> Changes in V3: >> >> - Added an in-code comment per Michal and David >> >> Changes in V2: >> >> - Rephrased patch subject per David >> - Fixed all typos per David >> - s/order/contiguous >> >> Changes from [V5,1/2] mm/hugetlb: Make alloc_gigantic_page()... >> >> - alloc_contig_page() takes nr_pages instead of order per Michal >> - s/gigantic/contig on all related functions >> >> include/linux/gfp.h | 2 + >> mm/hugetlb.c| 77 + >> mm/page_alloc.c | 101 >> 3 files changed, 105 insertions(+), 75 deletions(-) >> >> diff --git a/include/linux/gfp.h b/include/linux/gfp.h >> index fb07b503dc45..1a11d4857027 100644 >> --- a/include/linux/gfp.h >> +++ b/include/linux/gfp.h >> @@ -589,6 +589,8 @@ static inline bool pm_suspended_storage(void) >> /* The below functions must be run on a range from a single zone. */ >> extern int alloc_contig_range(unsigned long start, unsigned long end, >>unsigned migratetype, gfp_t gfp_mask); >> +extern struct page *alloc_contig_pages(unsigned long nr_pages, gfp_t >> gfp_mask, >> + int nid, nodemask_t *nodemask); >> #endif >> void free_contig_range(unsigned long pfn, unsigned int nr_pages); >> >> diff --git a/mm/hugetlb.c b/mm/hugetlb.c >> index 985ee15eb04b..a5c2c880af27 100644 >> --- a/mm/hugetlb.c >> +++ b/mm/hugetlb.c >> @@ -1023,85 +1023,12 @@ static void free_gigantic_page(struct page *page, >> unsigned int order) >> } >> >> #ifdef CONFIG_CONTIG_ALLOC >> -static int __alloc_gigantic_page(unsigned long start_pfn, >> -unsigned long nr_pages, gfp_t gfp_mask) >> -{ >> -unsigned long end_pfn = start_pfn + nr_pages; >> -return alloc_contig_range(start_pfn, end_pfn, MIGRATE_MOVABLE, >> - gfp_mask); >> -} >> - >> -static bool pfn_range_valid_gigantic(struct zone *z, >> -unsigned long start_pfn, unsigned long nr_pages) >> -{ >> -unsigned long i
linux-next: manual merge of the char-misc tree with the char-misc.current tree
Hi all, Today's linux-next merge of the char-misc tree got a conflict in: drivers/android/binder.c between commit: 45d02f79b539 ("binder: Don't modify VMA bounds in ->mmap handler") from the char-misc.current tree and commit: 990be7476485 ("binder: Use common definition of SZ_1K") from the char-misc tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell diff --cc drivers/android/binder.c index 265d9dd46a5e,bef788058bc3.. --- a/drivers/android/binder.c +++ b/drivers/android/binder.c @@@ -92,11 -93,10 +93,6 @@@ static atomic_t binder_last_id static int proc_show(struct seq_file *m, void *unused); DEFINE_SHOW_ATTRIBUTE(proc); - /* This is only defined in include/asm-arm/sizes.h */ - #ifndef SZ_1K - #define SZ_1K 0x400 -#ifndef SZ_4M -#define SZ_4M 0x40 --#endif -- #define FORBIDDEN_MMAP_FLAGS(VM_WRITE) enum { pgpYHOFt_RnJr.pgp Description: OpenPGP digital signature
[PATCH] x86: Don't use MWAIT if explicitly requested
If 'idle=nomwait' is specified or process matching what's in processor_idle_dmi_table, we should't use MWAIT at bootup stage before cpuidle driver loaded, even if it's preferred by default on Intel. Add a check so that HALT instruction is used in those cases. Signed-off-by: Zhenzhong Duan Cc: Thomas Gleixner Cc: Borislav Petkov Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Boris Ostrovsky --- arch/x86/kernel/process.c | 4 1 file changed, 4 insertions(+) diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c index 5e94c43..37fc577 100644 --- a/arch/x86/kernel/process.c +++ b/arch/x86/kernel/process.c @@ -667,6 +667,10 @@ static void amd_e400_idle(void) */ static int prefer_mwait_c1_over_halt(const struct cpuinfo_x86 *c) { + /* Don't use MWAIT-C1 if explicitly requested */ + if (boot_option_idle_override == IDLE_NOMWAIT) + return 0; + if (c->x86_vendor != X86_VENDOR_INTEL) return 0; -- 1.8.3.1
Re: [PATCH v2 5/5] cpufreq: vexpress-spc: fix some coding style issues
On 17-10-19, 13:35, Sudeep Holla wrote: > Fix the following checkpatch checks/warnings: > > CHECK: Unnecessary parentheses around the code > CHECK: Alignment should match open parenthesis > CHECK: Prefer kernel type 'u32' over 'uint32_t' > WARNING: Missing a blank line after declarations > > Signed-off-by: Sudeep Holla > --- > drivers/cpufreq/vexpress-spc-cpufreq.c | 43 -- > 1 file changed, 20 insertions(+), 23 deletions(-) > > diff --git a/drivers/cpufreq/vexpress-spc-cpufreq.c > b/drivers/cpufreq/vexpress-spc-cpufreq.c > index 81064430317f..8ecb2961be86 100644 > --- a/drivers/cpufreq/vexpress-spc-cpufreq.c > +++ b/drivers/cpufreq/vexpress-spc-cpufreq.c > @@ -79,8 +79,8 @@ static unsigned int find_cluster_maxfreq(int cluster) > for_each_online_cpu(j) { > cpu_freq = per_cpu(cpu_last_req_freq, j); > > - if ((cluster == per_cpu(physical_cluster, j)) && > - (max_freq < cpu_freq)) > + if (cluster == per_cpu(physical_cluster, j) && > + max_freq < cpu_freq) > max_freq = cpu_freq; > } > > @@ -188,22 +188,19 @@ static int ve_spc_cpufreq_set_target(struct > cpufreq_policy *policy, > freqs_new = freq_table[cur_cluster][index].frequency; > > if (is_bL_switching_enabled()) { > - if ((actual_cluster == A15_CLUSTER) && > - (freqs_new < clk_big_min)) { > + if (actual_cluster == A15_CLUSTER && freqs_new < clk_big_min) > new_cluster = A7_CLUSTER; > - } else if ((actual_cluster == A7_CLUSTER) && > - (freqs_new > clk_little_max)) { > + else if (actual_cluster == A7_CLUSTER && > + freqs_new > clk_little_max) > new_cluster = A15_CLUSTER; > - } > } > > ret = ve_spc_cpufreq_set_rate(cpu, actual_cluster, new_cluster, > freqs_new); > > - if (!ret) { > + if (!ret) That's not the standard way in Linux I believe. We do use {} even when the body is single line but broken into two, like below. > arch_set_freq_scale(policy->related_cpus, freqs_new, > policy->cpuinfo.max_freq); > - } > > return ret; > } > @@ -222,7 +219,8 @@ static inline u32 get_table_count(struct > cpufreq_frequency_table *table) > static inline u32 get_table_min(struct cpufreq_frequency_table *table) > { > struct cpufreq_frequency_table *pos; > - uint32_t min_freq = ~0; > + u32 min_freq = ~0; > + > cpufreq_for_each_entry(pos, table) > if (pos->frequency < min_freq) > min_freq = pos->frequency; > @@ -233,7 +231,8 @@ static inline u32 get_table_min(struct > cpufreq_frequency_table *table) > static inline u32 get_table_max(struct cpufreq_frequency_table *table) > { > struct cpufreq_frequency_table *pos; > - uint32_t max_freq = 0; > + u32 max_freq = 0; > + > cpufreq_for_each_entry(pos, table) > if (pos->frequency > max_freq) > max_freq = pos->frequency; > @@ -255,14 +254,11 @@ static int merge_cluster_tables(void) > freq_table[MAX_CLUSTERS] = table; > > /* Add in reverse order to get freqs in increasing order */ > - for (i = MAX_CLUSTERS - 1; i >= 0; i--) { > + for (i = MAX_CLUSTERS - 1; i >= 0; i--) > for (j = 0; freq_table[i][j].frequency != CPUFREQ_TABLE_END; > - j++) { > - table[k].frequency = VIRT_FREQ(i, > - freq_table[i][j].frequency); > - k++; > - } > - } > + j++, k++) same here, please keep {}. > + table[k].frequency = > + VIRT_FREQ(i, freq_table[i][j].frequency); > > table[k].driver_data = k; > table[k].frequency = CPUFREQ_TABLE_END; > @@ -332,13 +328,13 @@ static int _get_cluster_clk_and_freq_table(struct > device *cpu_dev, > return 0; > > dev_err(cpu_dev, "%s: Failed to get clk for cpu: %d, cluster: %d\n", > - __func__, cpu_dev->id, cluster); > + __func__, cpu_dev->id, cluster); > ret = PTR_ERR(clk[cluster]); > dev_pm_opp_free_cpufreq_table(cpu_dev, &freq_table[cluster]); > > out: > dev_err(cpu_dev, "%s: Failed to get data for cluster: %d\n", __func__, > - cluster); > + cluster); > return ret; > } > > @@ -406,7 +402,7 @@ static int ve_spc_cpufreq_init(struct cpufreq_policy > *policy) > cpu_dev = get_cpu_device(policy->cpu); > if (!cpu_dev) { > pr_err("%s: failed to get cpu%d device\n", __func__, > - policy->cpu); > +policy->cpu); > return -ENODEV; >
Re: [PATCH 07/15] riscv: implement remote sfence.i using IPIs
On Thu, Oct 17, 2019 at 11:08 PM Christoph Hellwig wrote: > > The RISC-V ISA only supports flushing the instruction cache for the > local CPU core. Currently we always offload the remote TLB flushing to > the SBI, which then issues an IPI under the hoods. But with M-mode > we do not have an SBI so we have to do it ourselves. IPI to the > other nodes using the existing kernel helpers instead if we have > native clint support and thus can IPI directly from the kernel. > > Signed-off-by: Christoph Hellwig > --- > arch/riscv/include/asm/sbi.h | 3 +++ > arch/riscv/mm/cacheflush.c | 24 ++-- > 2 files changed, 21 insertions(+), 6 deletions(-) > > diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h > index b167af3e7470..0cb74eccc73f 100644 > --- a/arch/riscv/include/asm/sbi.h > +++ b/arch/riscv/include/asm/sbi.h > @@ -94,5 +94,8 @@ static inline void sbi_remote_sfence_vma_asid(const > unsigned long *hart_mask, > { > SBI_CALL_4(SBI_REMOTE_SFENCE_VMA_ASID, hart_mask, start, size, asid); > } > +#else /* CONFIG_RISCV_SBI */ > +/* stub to for code is only reachable under IS_ENABLED(CONFIG_RISCV_SBI): */ > +void sbi_remote_fence_i(const unsigned long *hart_mask); > #endif /* CONFIG_RISCV_SBI */ > #endif /* _ASM_RISCV_SBI_H */ > diff --git a/arch/riscv/mm/cacheflush.c b/arch/riscv/mm/cacheflush.c > index 3f15938dec89..794c9ab256eb 100644 > --- a/arch/riscv/mm/cacheflush.c > +++ b/arch/riscv/mm/cacheflush.c > @@ -10,9 +10,17 @@ > > #include > > +static void ipi_remote_fence_i(void *info) > +{ > + return local_flush_icache_all(); > +} > + > void flush_icache_all(void) > { > - sbi_remote_fence_i(NULL); > + if (IS_ENABLED(CONFIG_RISCV_SBI)) > + sbi_remote_fence_i(NULL); > + else > + on_each_cpu(ipi_remote_fence_i, NULL, 1); > } > > /* > @@ -28,7 +36,7 @@ void flush_icache_all(void) > void flush_icache_mm(struct mm_struct *mm, bool local) > { > unsigned int cpu; > - cpumask_t others, hmask, *mask; > + cpumask_t others, *mask; > > preempt_disable(); > > @@ -46,10 +54,7 @@ void flush_icache_mm(struct mm_struct *mm, bool local) > */ > cpumask_andnot(&others, mm_cpumask(mm), cpumask_of(cpu)); > local |= cpumask_empty(&others); > - if (mm != current->active_mm || !local) { > - riscv_cpuid_to_hartid_mask(&others, &hmask); > - sbi_remote_fence_i(hmask.bits); > - } else { > + if (mm == current->active_mm && local) { > /* > * It's assumed that at least one strongly ordered operation > is > * performed on this hart between setting a hart's cpumask bit > @@ -59,6 +64,13 @@ void flush_icache_mm(struct mm_struct *mm, bool local) > * with flush_icache_deferred(). > */ > smp_mb(); > + } else if (IS_ENABLED(CONFIG_RISCV_SBI)) { > + cpumask_t hartid_mask; > + > + riscv_cpuid_to_hartid_mask(&others, &hartid_mask); > + sbi_remote_fence_i(cpumask_bits(&hartid_mask)); > + } else { > + on_each_cpu_mask(&others, ipi_remote_fence_i, NULL, 1); > } > > preempt_enable(); > -- > 2.20.1 > > > ___ > linux-riscv mailing list > linux-ri...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv LGTM. Reviewed-by: Anup Patel Regards, Anup
Re: [PATCH v2 2/5] cpufreq: merge arm_big_little and vexpress-spc
On Fri, Oct 18, 2019 at 11:17:40AM +0530, Viresh Kumar wrote: > On 17-10-19, 13:35, Sudeep Holla wrote: > > diff --git a/drivers/cpufreq/arm_big_little.c > > b/drivers/cpufreq/vexpress-spc-cpufreq.c > > similarity index 90% > > rename from drivers/cpufreq/arm_big_little.c > > rename to drivers/cpufreq/vexpress-spc-cpufreq.c > > index 7fe52fcddcf1..b7e1aa000c80 100644 > > --- a/drivers/cpufreq/arm_big_little.c > > +++ b/drivers/cpufreq/vexpress-spc-cpufreq.c > > @@ -1,20 +1,12 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > /* > > - * ARM big.LITTLE Platforms CPUFreq support > > + * Versatile Express SPC CPUFreq Interface driver > > * > > - * Copyright (C) 2013 ARM Ltd. > > - * Sudeep KarkadaNagesha > > + * Copyright (C) 2019 ARM Ltd. > > Should this be 2013-2019 instead ? > Sure. -- Regards, Sudeep
Re: [PATCH 08/15] riscv: add support for MMIO access to the timer registers
On Thu, Oct 17, 2019 at 11:08 PM Christoph Hellwig wrote: > > When running in M-mode we can't use the SBI to set the timer, and > don't have access to the time CSR as that usually is emulated by > M-mode. Instead provide code that directly accesses the MMIO for > the timer. > > Signed-off-by: Christoph Hellwig > --- > arch/riscv/include/asm/sbi.h | 3 ++- > arch/riscv/include/asm/timex.h| 19 +-- > drivers/clocksource/timer-riscv.c | 21 + > 3 files changed, 36 insertions(+), 7 deletions(-) > > diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h > index 0cb74eccc73f..a4774bafe033 100644 > --- a/arch/riscv/include/asm/sbi.h > +++ b/arch/riscv/include/asm/sbi.h > @@ -95,7 +95,8 @@ static inline void sbi_remote_sfence_vma_asid(const > unsigned long *hart_mask, > SBI_CALL_4(SBI_REMOTE_SFENCE_VMA_ASID, hart_mask, start, size, asid); > } > #else /* CONFIG_RISCV_SBI */ > -/* stub to for code is only reachable under IS_ENABLED(CONFIG_RISCV_SBI): */ > +/* stubs to for code is only reachable under IS_ENABLED(CONFIG_RISCV_SBI): */ > +void sbi_set_timer(uint64_t stime_value); > void sbi_remote_fence_i(const unsigned long *hart_mask); > #endif /* CONFIG_RISCV_SBI */ > #endif /* _ASM_RISCV_SBI_H */ > diff --git a/arch/riscv/include/asm/timex.h b/arch/riscv/include/asm/timex.h > index c7ef131b9e4c..e17837d61667 100644 > --- a/arch/riscv/include/asm/timex.h > +++ b/arch/riscv/include/asm/timex.h > @@ -7,12 +7,25 @@ > #define _ASM_RISCV_TIMEX_H > > #include > +#include > > typedef unsigned long cycles_t; > > +extern u64 __iomem *riscv_time_val; > +extern u64 __iomem *riscv_time_cmp; > + > +#ifdef CONFIG_64BIT > +#define mmio_get_cycles() readq_relaxed(riscv_time_val) > +#else > +#define mmio_get_cycles() readl_relaxed(riscv_time_val) > +#define mmio_get_cycles_hi() readl_relaxed(((u32 *)riscv_time_val) + 1) > +#endif > + > static inline cycles_t get_cycles(void) > { > - return csr_read(CSR_TIME); > + if (IS_ENABLED(CONFIG_RISCV_SBI)) > + return csr_read(CSR_TIME); > + return mmio_get_cycles(); > } > #define get_cycles get_cycles > > @@ -24,7 +37,9 @@ static inline u64 get_cycles64(void) > #else /* CONFIG_64BIT */ > static inline u32 get_cycles_hi(void) > { > - return csr_read(CSR_TIMEH); > + if (IS_ENABLED(CONFIG_RISCV_SBI)) > + return csr_read(CSR_TIMEH); > + return mmio_get_cycles_hi(); > } > > static inline u64 get_cycles64(void) > diff --git a/drivers/clocksource/timer-riscv.c > b/drivers/clocksource/timer-riscv.c > index 5d2fdc3e28a9..2b9fbc4ebe49 100644 > --- a/drivers/clocksource/timer-riscv.c > +++ b/drivers/clocksource/timer-riscv.c > @@ -3,9 +3,9 @@ > * Copyright (C) 2012 Regents of the University of California > * Copyright (C) 2017 SiFive > * > - * All RISC-V systems have a timer attached to every hart. These timers can > be > - * read from the "time" and "timeh" CSRs, and can use the SBI to setup > - * events. > + * All RISC-V systems have a timer attached to every hart. These timers can > + * either be read from the "time" and "timeh" CSRs, and can use the SBI to > + * setup events, or directly accessed using MMIO registers. > */ > #include > #include > @@ -13,14 +13,27 @@ > #include > #include > #include > +#include > #include > #include > > +u64 __iomem *riscv_time_cmp; > +u64 __iomem *riscv_time_val; > + > +static inline void mmio_set_timer(u64 val) > +{ > + writeq_relaxed(val, > + riscv_time_cmp + cpuid_to_hartid_map(smp_processor_id())); > +} > + > static int riscv_clock_next_event(unsigned long delta, > struct clock_event_device *ce) > { > csr_set(CSR_XIE, XIE_XTIE); > - sbi_set_timer(get_cycles64() + delta); > + if (IS_ENABLED(CONFIG_RISCV_SBI)) > + sbi_set_timer(get_cycles64() + delta); > + else > + mmio_set_timer(get_cycles64() + delta); > return 0; > } > > -- > 2.20.1 > > > ___ > linux-riscv mailing list > linux-ri...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv LGTM. Reviewed-by: Anup Patel Regards, Anup
Re: [PATCH] cpufreq: flush any pending policy update work scheduled before freeing
On Thu, Oct 17, 2019 at 09:36:30PM +0200, Rafael J. Wysocki wrote: > On Thu, Oct 17, 2019 at 6:35 PM Sudeep Holla wrote: > > > > dev_pm_qos_remove_request ends calling {max,min}_freq_req QoS notifiers > > which schedule policy update work. It may end up racing with the freeing > > the policy and unregistering the driver. > > > > One possible race is as below where the cpufreq_driver is unregistered > > but the scheduled work gets executed at later stage when cpufreq_driver > > is NULL(i.e. after freeing the policy and driver) > > > > Unable to handle kernel NULL pointer dereference at virtual address 001c > > pgd = (ptrval) > > [001c] *pgd=8080204003, *pmd= > > Internal error: Oops: 206 [#1] SMP THUMB2 > > Modules linked in: > > CPU: 0 PID: 34 Comm: kworker/0:1 Not tainted 5.4.0-rc3-6-g67f5a8081a4b > > #86 > > Hardware name: ARM-Versatile Express > > Workqueue: events handle_update > > PC is at cpufreq_set_policy+0x58/0x228 > > LR is at dev_pm_qos_read_value+0x77/0xac > > Control: 70c5387d Table: 80203000 DAC: fffd > > Process kworker/0:1 (pid: 34, stack limit = 0x(ptrval)) > > (cpufreq_set_policy) from > > (refresh_frequency_limits.part.24+0x37/0x48) > > (refresh_frequency_limits.part.24) from (handle_update+0x2f/0x38) > > (handle_update) from (process_one_work+0x16d/0x3cc) > > (process_one_work) from (worker_thread+0xff/0x414) > > (worker_thread) from (kthread+0xff/0x100) > > (kthread) from (ret_from_fork+0x11/0x28) > > > > Cc: "Rafael J. Wysocki" > > Cc: Viresh Kumar > > Signed-off-by: Sudeep Holla > > --- > > drivers/cpufreq/cpufreq.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > Hi Rafael, Viresh, > > > > This fixed the boot issue I reported[1] on TC2 with bL switcher enabled. > > I have based this patch on -rc3 and not on top of your patches. This > > only fixes the boot issue but I hit the other crashes while continuously > > switching on and off the bL switcher that register/unregister the driver > > Your patch series fixes them. I can based this on top of those if you > > prefer. > > > > Regards, > > Sudeep > > > > [1] https://lore.kernel.org/linux-pm/20191015155735.GA29105@bogus/ > > > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > > index c52d6fa32aac..b703c29a84be 100644 > > --- a/drivers/cpufreq/cpufreq.c > > +++ b/drivers/cpufreq/cpufreq.c > > @@ -1278,6 +1278,9 @@ static void cpufreq_policy_free(struct cpufreq_policy > > *policy) > > } > > > > dev_pm_qos_remove_request(policy->min_freq_req); > > + /* flush the pending policy->update work before freeing the policy > > */ > > + if (work_pending(&policy->update)) > > Isn't this racy? > > It still may be running if the pending bit is clear and we still need > to wait for it then, don't we? > Yes, we could end up in such situation. > Why don't you do an unconditional flush_work() here? > Yes that should be fine. -- Regards, Sudeep
Re: [PATCH 3/8] riscv: init: merge split string literals in preprocessor directive
On Thu, Oct 17, 2019 at 09:38:18PM -0700, Paul Walmsley wrote: > On Fri, 18 Oct 2019, Luc Van Oostenryck wrote: > > > On Thu, Oct 17, 2019 at 05:49:24PM -0700, Paul Walmsley wrote: > > > sparse complains loudly when string literals associated with > > > preprocessor directives are split into multiple, separately quoted > > > strings across different lines: > > > > ... > > > > > #ifndef __riscv_cmodel_medany > > > -#error "setup_vm() is called from head.S before relocate so it should " > > > - "not use absolute addressing." > > > +#error "setup_vm() is called from head.S before relocate so it should > > > not use absolute addressing." > > > #endif ... > On the other hand, gcc seems to support the non-backslashed syntax. So if > the intention is for sparse to follow the gcc practice, and to be used > beyond the kernel, maybe it's worth aligning sparse to gcc? Only if > you're bored, I suppose... I quickly checked and gcc also complain about the second line: $ cat y.c #ifndef __riscv_cmodel_medany #error "setup_vm() is called from head.S before relocate so it should " "not use absolute addressing." #endif $ gcc -c y.c y.c:2:2: error: #error "setup_vm() is called from head.S before relocate so it should " #error "setup_vm() is called from head.S before relocate so it should " ^ y.c:3:8: error: expected identifier or '(' before string constant "not use absolute addressing." ^~ So it seems that gcc doesn't join these lines. Fell free to add my: Reviewed-by: Luc Van Oostenryck -- Luc
Re: [PATCH v2 2/5] cpufreq: merge arm_big_little and vexpress-spc
On 17-10-19, 13:35, Sudeep Holla wrote: > diff --git a/drivers/cpufreq/arm_big_little.c > b/drivers/cpufreq/vexpress-spc-cpufreq.c > similarity index 90% > rename from drivers/cpufreq/arm_big_little.c > rename to drivers/cpufreq/vexpress-spc-cpufreq.c > index 7fe52fcddcf1..b7e1aa000c80 100644 > --- a/drivers/cpufreq/arm_big_little.c > +++ b/drivers/cpufreq/vexpress-spc-cpufreq.c > @@ -1,20 +1,12 @@ > +// SPDX-License-Identifier: GPL-2.0 > /* > - * ARM big.LITTLE Platforms CPUFreq support > + * Versatile Express SPC CPUFreq Interface driver > * > - * Copyright (C) 2013 ARM Ltd. > - * Sudeep KarkadaNagesha > + * Copyright (C) 2019 ARM Ltd. Should this be 2013-2019 instead ? > + * Sudeep Holla > * > * Copyright (C) 2013 Linaro. > * Viresh Kumar > - * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License version 2 as > - * published by the Free Software Foundation. > - * > - * This program is distributed "as is" WITHOUT ANY WARRANTY of any > - * kind, whether express or implied; without even the implied warranty > - * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > - * GNU General Public License for more details. > */ -- viresh
Re: [PATCH] lib/vdso: Use __arch_use_vsyscall() to indicate fallback
On Thu, Oct 17, 2019 at 7:57 PM Huacai Chen wrote: > > In do_hres(), we currently use whether the return value of __arch_get_ > hw_counter() is negtive to indicate fallback, but this is not a good > idea. Because: > > 1, ARM64 returns ULL_MAX but MIPS returns 0 when clock_mode is invalid; > 2, For a 64bit counter, a "negtive" value of counter is actually valid. s/negtive/negative What's the actual bug? Is it that MIPS is returning 0 but the check is < 0? Sounds like MIPS should get fixed. > > To solve this problem, we use U64_MAX as the only "invalid" return > value -- this is still not fully correct, but has no problem in most > cases. I'm sort of okay with that, but... > Moreover, all vdso time-related functions should rely on the > return value of __arch_use_vsyscall(), because update_vdso_data() and > update_vsyscall_tz() also rely on it. So, in the core functions of > __cvdso_gettimeofday(), __cvdso_clock_gettime() and __cvdso_clock_ > getres(), if __arch_use_vsyscall() returns false, we use the fallback > functions directly. __arch_use_vsyscall() is not currently intended for use in the vDSO at all. > > Fixes: 00b26474c2f1613d7ab894c5 ("lib/vdso: Provide generic VDSO > implementation") > Cc: sta...@vger.kernel.org > Cc: Arnd Bergmann > Cc: Paul Burton > Cc: linux-m...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > Signed-off-by: Huacai Chen > --- > arch/arm64/include/asm/vdso/vsyscall.h | 2 +- > arch/mips/include/asm/vdso/vsyscall.h | 2 +- > include/asm-generic/vdso/vsyscall.h| 2 +- > lib/vdso/gettimeofday.c| 12 +++- > 4 files changed, 14 insertions(+), 4 deletions(-) > > diff --git a/arch/arm64/include/asm/vdso/vsyscall.h > b/arch/arm64/include/asm/vdso/vsyscall.h > index 0c731bf..406e6de 100644 > --- a/arch/arm64/include/asm/vdso/vsyscall.h > +++ b/arch/arm64/include/asm/vdso/vsyscall.h > @@ -31,7 +31,7 @@ int __arm64_get_clock_mode(struct timekeeper *tk) > #define __arch_get_clock_mode __arm64_get_clock_mode > > static __always_inline > -int __arm64_use_vsyscall(struct vdso_data *vdata) > +int __arm64_use_vsyscall(const struct vdso_data *vdata) > { > return !vdata[CS_HRES_COARSE].clock_mode; > } > diff --git a/arch/mips/include/asm/vdso/vsyscall.h > b/arch/mips/include/asm/vdso/vsyscall.h > index 1953147..8b10dd7 100644 > --- a/arch/mips/include/asm/vdso/vsyscall.h > +++ b/arch/mips/include/asm/vdso/vsyscall.h > @@ -29,7 +29,7 @@ int __mips_get_clock_mode(struct timekeeper *tk) > #define __arch_get_clock_mode __mips_get_clock_mode > > static __always_inline > -int __mips_use_vsyscall(struct vdso_data *vdata) > +int __mips_use_vsyscall(const struct vdso_data *vdata) > { > return (vdata[CS_HRES_COARSE].clock_mode != VDSO_CLOCK_NONE); > } > diff --git a/include/asm-generic/vdso/vsyscall.h > b/include/asm-generic/vdso/vsyscall.h > index e94b1978..ac05a625 100644 > --- a/include/asm-generic/vdso/vsyscall.h > +++ b/include/asm-generic/vdso/vsyscall.h > @@ -26,7 +26,7 @@ static __always_inline int __arch_get_clock_mode(struct > timekeeper *tk) > #endif /* __arch_get_clock_mode */ > > #ifndef __arch_use_vsyscall > -static __always_inline int __arch_use_vsyscall(struct vdso_data *vdata) > +static __always_inline int __arch_use_vsyscall(const struct vdso_data *vdata) > { > return 1; > } > diff --git a/lib/vdso/gettimeofday.c b/lib/vdso/gettimeofday.c > index e630e7f..4ad062e 100644 > --- a/lib/vdso/gettimeofday.c > +++ b/lib/vdso/gettimeofday.c > @@ -9,6 +9,7 @@ > #include > #include > #include > +#include > > /* > * The generic vDSO implementation requires that gettimeofday.h > @@ -50,7 +51,7 @@ static int do_hres(const struct vdso_data *vd, clockid_t > clk, > cycles = __arch_get_hw_counter(vd->clock_mode); > ns = vdso_ts->nsec; > last = vd->cycle_last; > - if (unlikely((s64)cycles < 0)) > + if (unlikely(cycles == U64_MAX)) > return -1; I would actually prefer: if (unlikely(cycles < last)) or perhaps: if (unlikely((s64)(cycles-last) < 0)) which would have the nice side effect of getting rid of the annoying x86 special case in vdso_calc_delta(). The former version is compatible with U64_MAX, whereas the latter version would need the error case to return last-1 or similar. The benefit of the latter version is that it can survive wrap-around. > > ns += vdso_calc_delta(cycles, last, vd->mask, vd->mult); > @@ -91,6 +92,9 @@ __cvdso_clock_gettime_common(clockid_t clock, struct > __kernel_timespec *ts) > if (unlikely((u32) clock >= MAX_CLOCKS)) > return -1; > > + if (!__arch_use_vsyscall(vd)) > + return -1; > + NAK. I don't think this is helpful or correct. It doesn't appear to do anything valid, and it's racy. > /* > * Convert the clockid to a bitmask and use it to check which > * clocks are handled in
BUG: unable to handle kernel paging request in is_bpf_text_address
Hello, syzbot found the following crash on: HEAD commit:283ea345 coccinelle: api/devm_platform_ioremap_resource: r.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=122f199b60 kernel config: https://syzkaller.appspot.com/x/.config?x=f0a8b0a0736a2ac1 dashboard link: https://syzkaller.appspot.com/bug?extid=710043c5d1d5b5013bc7 compiler: clang version 9.0.0 (/home/glider/llvm/clang 80fee25776c2fb61e74c1ecb1a523375c2500b69) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=142676bb60 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11a2cebb60 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+710043c5d1d5b5013...@syzkaller.appspotmail.com BUG: unable to handle page fault for address: c90001923030 #PF: supervisor read access in kernel mode #PF: error_code(0x) - not-present page PGD aa551067 P4D aa551067 PUD aa552067 PMD a572b067 PTE 8000a1173163 Oops: [#1] PREEMPT SMP KASAN CPU: 0 PID: 7982 Comm: syz-executor912 Not tainted 5.4.0-rc3+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:bpf_jit_binary_hdr include/linux/filter.h:787 [inline] RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:531 [inline] RIP: 0010:bpf_tree_comp kernel/bpf/core.c:600 [inline] RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline] RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline] RIP: 0010:bpf_prog_kallsyms_find kernel/bpf/core.c:674 [inline] RIP: 0010:is_bpf_text_address+0x184/0x3b0 kernel/bpf/core.c:709 Code: 89 df e8 ff dd 2e 00 48 8b 1b 48 8d 7b 30 48 89 f8 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df 80 3c 08 00 74 05 e8 dc dd 2e 00 <4c> 8b 63 30 48 c7 c0 00 f0 ff ff 49 21 c4 48 83 c3 02 48 89 d8 48 RSP: 0018:88809569f9c8 EFLAGS: 00010246 RAX: 192000324606 RBX: c90001923000 RCX: dc00 RDX: 88809d900500 RSI: 8880a8227838 RDI: c90001923030 RBP: 88809569fa00 R08: 817d9d5a R09: ed1015d46b05 R10: ed1015d46b05 R11: R12: 88809d900500 R13: R14: R15: 8880a8227838 FS: 00728880() GS:8880aea0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: c90001923030 CR3: 96dc4000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: kernel_text_address kernel/extable.c:147 [inline] __kernel_text_address+0x9a/0x110 kernel/extable.c:102 unwind_get_return_address+0x4c/0x90 arch/x86/kernel/unwind_frame.c:19 arch_stack_walk+0x98/0xe0 arch/x86/kernel/stacktrace.c:26 stack_trace_save+0xb6/0x150 kernel/stacktrace.c:123 save_stack mm/kasan/common.c:69 [inline] set_track mm/kasan/common.c:77 [inline] __kasan_kmalloc+0x11c/0x1b0 mm/kasan/common.c:510 kasan_slab_alloc+0xf/0x20 mm/kasan/common.c:518 slab_post_alloc_hook mm/slab.h:584 [inline] slab_alloc mm/slab.c:3319 [inline] kmem_cache_alloc+0x1f5/0x2e0 mm/slab.c:3483 getname_flags+0xba/0x640 fs/namei.c:138 getname+0x19/0x20 fs/namei.c:209 do_sys_open+0x261/0x560 fs/open.c:1091 __do_sys_open fs/open.c:1115 [inline] __se_sys_open fs/open.c:1110 [inline] __x64_sys_open+0x87/0x90 fs/open.c:1110 do_syscall_64+0xf7/0x1c0 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4011a0 Code: 01 f0 ff ff 0f 83 c0 0b 00 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 83 3d 2d 15 2d 00 00 75 14 b8 02 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 94 0b 00 00 c3 48 83 ec 08 e8 fa 00 00 00 RSP: 002b:7ffd6d953f58 EFLAGS: 0246 ORIG_RAX: 0002 RAX: ffda RBX: 7ffd6d953f84 RCX: 004011a0 RDX: 7ffd6d953f8a RSI: 00080001 RDI: 004a2422 RBP: 7ffd6d953f80 R08: R09: 0004 R10: R11: 0246 R12: 004021c0 R13: R14: R15: Modules linked in: CR2: c90001923030 ---[ end trace a62c6ddd9792af6a ]--- RIP: 0010:bpf_jit_binary_hdr include/linux/filter.h:787 [inline] RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:531 [inline] RIP: 0010:bpf_tree_comp kernel/bpf/core.c:600 [inline] RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline] RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline] RIP: 0010:bpf_prog_kallsyms_find kernel/bpf/core.c:674 [inline] RIP: 0010:is_bpf_text_address+0x184/0x3b0 kernel/bpf/core.c:709 Code: 89 df e8 ff dd 2e 00 48 8b 1b 48 8d 7b 30 48 89 f8 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df 80 3c 08 00 74 05 e8 dc dd 2e 00 <4c> 8b 63 30 48 c7 c0 00 f0 ff ff 49 21 c4 48 83 c3 02 48 89 d8 48 RSP: 0018:88809569f9c8 EFLAGS: 00010246 RAX: 192000324606 RBX: c90001923000 RCX: dc00 RDX: 88809d900500 RSI: 8880a8227838 RDI: c900019230
Re: [PATCH 12/15] riscv: clear the instruction cache and all registers when booting
On Thu, Oct 17, 2019 at 11:08 PM Christoph Hellwig wrote: > > When we get booted we want a clear slate without any leaks from previous > supervisors or the firmware. Flush the instruction cache and then clear > all registers to known good values. This is really important for the > upcoming nommu support that runs on M-mode, but can't really harm when > running in S-mode either. Vaguely based on the concepts from opensbi. > > Signed-off-by: Christoph Hellwig > --- > arch/riscv/include/asm/csr.h | 1 + > arch/riscv/kernel/head.S | 88 +++- > 2 files changed, 88 insertions(+), 1 deletion(-) > > diff --git a/arch/riscv/include/asm/csr.h b/arch/riscv/include/asm/csr.h > index d0b5113e1a54..ee0101278608 100644 > --- a/arch/riscv/include/asm/csr.h > +++ b/arch/riscv/include/asm/csr.h > @@ -83,6 +83,7 @@ > /* symbolic CSR names: */ > #define CSR_MHARTID0xf14 > #define CSR_MSTATUS0x300 > +#define CSR_MISA 0x301 > #define CSR_MIE0x304 > #define CSR_MTVEC 0x305 > #define CSR_MSCRATCH 0x340 > diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S > index 583784cb3a32..25867b99cc95 100644 > --- a/arch/riscv/kernel/head.S > +++ b/arch/riscv/kernel/head.S > @@ -11,6 +11,7 @@ > #include > #include > #include > +#include > #include > > __INIT > @@ -51,12 +52,18 @@ _start_kernel: > csrw CSR_XIP, zero > > #ifdef CONFIG_RISCV_M_MODE > + /* flush the instruction cache */ > + fence.i > + > + /* Reset all registers except ra, a0, a1 */ > + call reset_regs > + > /* > * The hartid in a0 is expected later on, and we have no firmware > * to hand it to us. > */ > csrr a0, CSR_MHARTID > -#endif > +#endif /* CONFIG_RISCV_M_MODE */ > > /* Load the global pointer */ > .option push > @@ -203,6 +210,85 @@ relocate: > j .Lsecondary_park > END(_start) > > +#ifdef CONFIG_RISCV_M_MODE > +ENTRY(reset_regs) > + li sp, 0 > + li gp, 0 > + li tp, 0 > + li t0, 0 > + li t1, 0 > + li t2, 0 > + li s0, 0 > + li s1, 0 > + li a2, 0 > + li a3, 0 > + li a4, 0 > + li a5, 0 > + li a6, 0 > + li a7, 0 > + li s2, 0 > + li s3, 0 > + li s4, 0 > + li s5, 0 > + li s6, 0 > + li s7, 0 > + li s8, 0 > + li s9, 0 > + li s10, 0 > + li s11, 0 > + li t3, 0 > + li t4, 0 > + li t5, 0 > + li t6, 0 > + csrwsscratch, 0 > + > +#ifdef CONFIG_FPU > + csrrt0, CSR_MISA > + andit0, t0, (COMPAT_HWCAP_ISA_F | COMPAT_HWCAP_ISA_D) > + bnezt0, .Lreset_regs_done > + > + li t1, SR_FS > + csrsCSR_XSTATUS, t1 > + fmv.s.x f0, zero > + fmv.s.x f1, zero > + fmv.s.x f2, zero > + fmv.s.x f3, zero > + fmv.s.x f4, zero > + fmv.s.x f5, zero > + fmv.s.x f6, zero > + fmv.s.x f7, zero > + fmv.s.x f8, zero > + fmv.s.x f9, zero > + fmv.s.x f10, zero > + fmv.s.x f11, zero > + fmv.s.x f12, zero > + fmv.s.x f13, zero > + fmv.s.x f14, zero > + fmv.s.x f15, zero > + fmv.s.x f16, zero > + fmv.s.x f17, zero > + fmv.s.x f18, zero > + fmv.s.x f19, zero > + fmv.s.x f20, zero > + fmv.s.x f21, zero > + fmv.s.x f22, zero > + fmv.s.x f23, zero > + fmv.s.x f24, zero > + fmv.s.x f25, zero > + fmv.s.x f26, zero > + fmv.s.x f27, zero > + fmv.s.x f28, zero > + fmv.s.x f29, zero > + fmv.s.x f30, zero > + fmv.s.x f31, zero > + csrwfcsr, 0 > + /* note that the caller must clear SR_FS */ > +#endif /* CONFIG_FPU */ > +.Lreset_regs_done: > + ret > +END(reset_regs) > +#endif /* CONFIG_RISCV_M_MODE */ > + > __PAGE_ALIGNED_BSS > /* Empty zero page */ > .balign PAGE_SIZE > -- > 2.20.1 > > > ___ > linux-riscv mailing list > linux-ri...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv LGTM. Reviewed-by: Anup Patel Regards, Anup
Re: [PATCH 13/15] riscv: add nommu support
On Thu, Oct 17, 2019 at 11:08 PM Christoph Hellwig wrote: > > The kernel runs in M-mode without using page tables, and thus can't run > bare metal without help from additional firmware. > > Most of the patch is just stubbing out code not needed without page > tables, but there is an interesting detail in the signals implementation: > > - The normal RISC-V syscall ABI only implements rt_sigreturn as VDSO >entry point, but the ELF VDSO is not supported for nommu Linux. >We instead copy the code to call the syscall onto the stack. > > In addition to enabling the nommu code a new defconfig for a small > kernel image that can run in nommu mode on qemu is also provided, to run > a kernel in qemu you can use the following command line: > > qemu-system-riscv64 -smp 2 -m 64 -machine virt -nographic \ > -kernel arch/riscv/boot/loader \ > -drive file=rootfs.ext2,format=raw,id=hd0 \ > -device virtio-blk-device,drive=hd0 > > Contains contributions from Damien Le Moal . > > Signed-off-by: Christoph Hellwig > --- > arch/riscv/Kconfig | 26 ++--- > arch/riscv/configs/nommu_virt_defconfig | 78 + > arch/riscv/include/asm/cache.h | 8 +++ > arch/riscv/include/asm/elf.h| 4 +- > arch/riscv/include/asm/fixmap.h | 2 + > arch/riscv/include/asm/futex.h | 6 ++ > arch/riscv/include/asm/io.h | 4 ++ > arch/riscv/include/asm/mmu.h| 3 + > arch/riscv/include/asm/page.h | 10 +++- > arch/riscv/include/asm/pgalloc.h| 2 + > arch/riscv/include/asm/pgtable.h| 64 +++- > arch/riscv/include/asm/tlbflush.h | 12 +++- > arch/riscv/include/asm/uaccess.h| 4 ++ > arch/riscv/kernel/Makefile | 3 +- > arch/riscv/kernel/entry.S | 11 > arch/riscv/kernel/head.S| 6 ++ > arch/riscv/kernel/signal.c | 17 +- > arch/riscv/lib/Makefile | 11 ++-- > arch/riscv/mm/Makefile | 3 +- > arch/riscv/mm/cacheflush.c | 2 + > arch/riscv/mm/context.c | 2 + > arch/riscv/mm/init.c| 13 - > 22 files changed, 236 insertions(+), 55 deletions(-) > create mode 100644 arch/riscv/configs/nommu_virt_defconfig > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > index b85492c42ccb..babc8a0d3d2e 100644 > --- a/arch/riscv/Kconfig > +++ b/arch/riscv/Kconfig > @@ -26,14 +26,14 @@ config RISCV > select GENERIC_IRQ_SHOW > select GENERIC_PCI_IOMAP > select GENERIC_SCHED_CLOCK > - select GENERIC_STRNCPY_FROM_USER > - select GENERIC_STRNLEN_USER > + select GENERIC_STRNCPY_FROM_USER if MMU > + select GENERIC_STRNLEN_USER if MMU > select GENERIC_SMP_IDLE_THREAD > select GENERIC_ATOMIC64 if !64BIT > select HAVE_ARCH_AUDITSYSCALL > select HAVE_ASM_MODVERSIONS > select HAVE_MEMBLOCK_NODE_MAP > - select HAVE_DMA_CONTIGUOUS > + select HAVE_DMA_CONTIGUOUS if MMU > select HAVE_FUTEX_CMPXCHG if FUTEX > select HAVE_PERF_EVENTS > select HAVE_PERF_REGS > @@ -50,6 +50,7 @@ config RISCV > select PCI_DOMAINS_GENERIC if PCI > select PCI_MSI if PCI > select RISCV_TIMER > + select UACCESS_MEMCPY if !MMU > select GENERIC_IRQ_MULTI_HANDLER > select GENERIC_ARCH_TOPOLOGY if SMP > select ARCH_HAS_PTE_SPECIAL > @@ -60,7 +61,7 @@ config RISCV > select ARCH_WANT_HUGE_PMD_SHARE if 64BIT > select SPARSEMEM_STATIC if 32BIT > select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU > - select HAVE_ARCH_MMAP_RND_BITS > + select HAVE_ARCH_MMAP_RND_BITS if MMU > > config ARCH_MMAP_RND_BITS_MIN > default 18 if 64BIT > @@ -75,6 +76,7 @@ config ARCH_MMAP_RND_BITS_MAX > # set if we run in machine mode, cleared if we run in supervisor mode > config RISCV_M_MODE > bool > + default !MMU > > # set if we are running in S-mode and can use SBI calls > config RISCV_SBI > @@ -83,7 +85,11 @@ config RISCV_SBI > default y > > config MMU > - def_bool y > + bool "MMU-based Paged Memory Management Support" > + default y > + help > + Select if you want MMU-based virtualised addressing space > + support by paged memory management. If unsure, say 'Y'. > > config ZONE_DMA32 > bool > @@ -102,6 +108,7 @@ config PA_BITS > config PAGE_OFFSET > hex > default 0xC000 if 32BIT && MAXPHYSMEM_2GB > + default 0x8000 if 64BIT && !MMU > default 0x8000 if 64BIT && MAXPHYSMEM_2GB > default 0xffe0 if 64BIT && MAXPHYSMEM_128GB > > @@ -145,7 +152,7 @@ config GENERIC_HWEIGHT > def_bool y > > config FIX_EARLYCON_MEM > - def_bool y > + def_bool CONFIG_MMU > > config PGTABLE_LEVELS > int > @@ -170,6 +1
Re: [RFT][PATCH 0/3] cpufreq / PM: QoS: Introduce frequency QoS and use it in cpufreq
On 17-10-19, 18:34, Rafael J. Wysocki wrote: > [BTW, Viresh, it looks like cpufreq_set_policy() should still ensure > that the new min is less than the new max, because the QoS doesn't do > that.] The ->verify() callback does that for us I believe. -- viresh
Re: [RFT][PATCH 1/3] PM: QoS: Introduce frequency QoS
On 17-10-19, 16:16, Rafael J. Wysocki wrote: > [Also note that the current code in device PM QoS uses MIN and MAX > here in the same way. :-)] Stupid me, enough embarrassment for the day :( -- viresh
Re: [PATCH] cpufreq: flush any pending policy update work scheduled before freeing
On 17-10-19, 17:35, Sudeep Holla wrote: > dev_pm_qos_remove_request ends calling {max,min}_freq_req QoS notifiers > which schedule policy update work. I don't think that's correct. We remove the notifiers first and then only remove the requests. Though it is possible due to the other bug we are discussing where the notifier doesn't really get removed from the right CPU, but even that patch didn't fix your issue. Looks like we are still missing something ? > It may end up racing with the freeing > the policy and unregistering the driver. > > One possible race is as below where the cpufreq_driver is unregistered > but the scheduled work gets executed at later stage when cpufreq_driver > is NULL(i.e. after freeing the policy and driver) > > Unable to handle kernel NULL pointer dereference at virtual address 001c > pgd = (ptrval) > [001c] *pgd=8080204003, *pmd= > Internal error: Oops: 206 [#1] SMP THUMB2 > Modules linked in: > CPU: 0 PID: 34 Comm: kworker/0:1 Not tainted 5.4.0-rc3-6-g67f5a8081a4b #86 > Hardware name: ARM-Versatile Express > Workqueue: events handle_update > PC is at cpufreq_set_policy+0x58/0x228 > LR is at dev_pm_qos_read_value+0x77/0xac > Control: 70c5387d Table: 80203000 DAC: fffd > Process kworker/0:1 (pid: 34, stack limit = 0x(ptrval)) > (cpufreq_set_policy) from (refresh_frequency_limits.part.24+0x37/0x48) > (refresh_frequency_limits.part.24) from (handle_update+0x2f/0x38) > (handle_update) from (process_one_work+0x16d/0x3cc) > (process_one_work) from (worker_thread+0xff/0x414) > (worker_thread) from (kthread+0xff/0x100) > (kthread) from (ret_from_fork+0x11/0x28) > > Cc: "Rafael J. Wysocki" > Cc: Viresh Kumar > Signed-off-by: Sudeep Holla > --- > drivers/cpufreq/cpufreq.c | 3 +++ > 1 file changed, 3 insertions(+) > > Hi Rafael, Viresh, > > This fixed the boot issue I reported[1] on TC2 with bL switcher enabled. > I have based this patch on -rc3 and not on top of your patches. This > only fixes the boot issue but I hit the other crashes while continuously > switching on and off the bL switcher that register/unregister the driver > Your patch series fixes them. I can based this on top of those if you > prefer. > > Regards, > Sudeep > > [1] https://lore.kernel.org/linux-pm/20191015155735.GA29105@bogus/ > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > index c52d6fa32aac..b703c29a84be 100644 > --- a/drivers/cpufreq/cpufreq.c > +++ b/drivers/cpufreq/cpufreq.c > @@ -1278,6 +1278,9 @@ static void cpufreq_policy_free(struct cpufreq_policy > *policy) > } > > dev_pm_qos_remove_request(policy->min_freq_req); > + /* flush the pending policy->update work before freeing the policy */ > + if (work_pending(&policy->update)) > + flush_work(&policy->update); This diff surely makes sense even without the QoS stuff, this race can still happen, very unlikely though. And yes, you must use the other variant that Rafael suggested, we are already doing similar thing in a bunch of cpufreq governors :) And I will probably add this after calling dev_pm_qos_remove_notifier() for the MAX policy as this doesn't and shouldn't depend on removing the qos request. > kfree(policy->min_freq_req); > > cpufreq_policy_put_kobj(policy); > -- > 2.17.1 -- viresh
Re: [PATCH 02/15] riscv: cleanup do_trap_break
On Thu, Oct 17, 2019 at 11:07 PM Christoph Hellwig wrote: > > If we always compile the get_break_insn_length inline function we can > remove the ifdefs and let dead code elimination take care of the warn > branch that is now unreadable because the report_bug stub always > returns BUG_TRAP_TYPE_BUG. > > Signed-off-by: Christoph Hellwig > --- > arch/riscv/kernel/traps.c | 26 ++ > 1 file changed, 6 insertions(+), 20 deletions(-) > > diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c > index 1ac75f7d0bff..10a17e545f43 100644 > --- a/arch/riscv/kernel/traps.c > +++ b/arch/riscv/kernel/traps.c > @@ -111,7 +111,6 @@ DO_ERROR_INFO(do_trap_ecall_s, > DO_ERROR_INFO(do_trap_ecall_m, > SIGILL, ILL_ILLTRP, "environment call from M-mode"); > > -#ifdef CONFIG_GENERIC_BUG > static inline unsigned long get_break_insn_length(unsigned long pc) > { > bug_insn_t insn; > @@ -120,28 +119,15 @@ static inline unsigned long > get_break_insn_length(unsigned long pc) > return 0; > return (((insn & __INSN_LENGTH_MASK) == __INSN_LENGTH_32) ? 4UL : > 2UL); > } > -#endif /* CONFIG_GENERIC_BUG */ > > asmlinkage void do_trap_break(struct pt_regs *regs) > { > - if (user_mode(regs)) { > - force_sig_fault(SIGTRAP, TRAP_BRKPT, > - (void __user *)(regs->sepc)); > - return; > - } > -#ifdef CONFIG_GENERIC_BUG > - { > - enum bug_trap_type type; > - > - type = report_bug(regs->sepc, regs); > - if (type == BUG_TRAP_TYPE_WARN) { > - regs->sepc += get_break_insn_length(regs->sepc); > - return; > - } > - } > -#endif /* CONFIG_GENERIC_BUG */ > - > - die(regs, "Kernel BUG"); > + if (user_mode(regs)) > + force_sig_fault(SIGTRAP, TRAP_BRKPT, (void __user > *)regs->sepc); > + else if (report_bug(regs->sepc, regs) == BUG_TRAP_TYPE_WARN) > + regs->sepc += get_break_insn_length(regs->sepc); > + else > + die(regs, "Kernel BUG"); > } > > #ifdef CONFIG_GENERIC_BUG > -- > 2.20.1 > > > ___ > linux-riscv mailing list > linux-ri...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv LGTM. Reviewed-by: Anup Patel Regards, Anup
Re: [PATCH v3 04/10] sched/fair: rework load_balance
On 10/16/19 5:26 PM, Vincent Guittot wrote: > On Wed, 16 Oct 2019 at 09:21, Parth Shah wrote: >> >> >> >> On 9/19/19 1:03 PM, Vincent Guittot wrote: >> >> [...] >> >>> Signed-off-by: Vincent Guittot >>> --- >>> kernel/sched/fair.c | 585 >>> ++-- >>> 1 file changed, 380 insertions(+), 205 deletions(-) >>> >>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >>> index 017aad0..d33379c 100644 >>> --- a/kernel/sched/fair.c >>> +++ b/kernel/sched/fair.c >>> @@ -7078,11 +7078,26 @@ static unsigned long __read_mostly >>> max_load_balance_interval = HZ/10; >>> >>> enum fbq_type { regular, remote, all }; >>> >>> +/* >>> + * group_type describes the group of CPUs at the moment of the load >>> balance. >>> + * The enum is ordered by pulling priority, with the group with lowest >>> priority >>> + * first so the groupe_type can be simply compared when selecting the >>> busiest >>> + * group. see update_sd_pick_busiest(). >>> + */ >>> enum group_type { >>> - group_other = 0, >>> + group_has_spare = 0, >>> + group_fully_busy, >>> group_misfit_task, >>> + group_asym_packing, >>> group_imbalanced, >>> - group_overloaded, >>> + group_overloaded >>> +}; >>> + >>> +enum migration_type { >>> + migrate_load = 0, >>> + migrate_util, >>> + migrate_task, >>> + migrate_misfit >>> }; >>> >>> #define LBF_ALL_PINNED 0x01 >>> @@ -7115,7 +7130,7 @@ struct lb_env { >>> unsigned intloop_max; >>> >>> enum fbq_type fbq_type; >>> - enum group_type src_grp_type; >>> + enum migration_type balance_type; >>> struct list_headtasks; >>> }; >>> >>> @@ -7347,7 +7362,7 @@ static int detach_tasks(struct lb_env *env) >>> { >>> struct list_head *tasks = &env->src_rq->cfs_tasks; >>> struct task_struct *p; >>> - unsigned long load; >>> + unsigned long util, load; >>> int detached = 0; >>> >>> lockdep_assert_held(&env->src_rq->lock); >>> @@ -7380,19 +7395,53 @@ static int detach_tasks(struct lb_env *env) >>> if (!can_migrate_task(p, env)) >>> goto next; >>> >>> - load = task_h_load(p); >>> + switch (env->balance_type) { >>> + case migrate_load: >>> + load = task_h_load(p); >>> >>> - if (sched_feat(LB_MIN) && load < 16 && >>> !env->sd->nr_balance_failed) >>> - goto next; >>> + if (sched_feat(LB_MIN) && >>> + load < 16 && !env->sd->nr_balance_failed) >>> + goto next; >>> >>> - if ((load / 2) > env->imbalance) >>> - goto next; >>> + if ((load / 2) > env->imbalance) >>> + goto next; >>> + >>> + env->imbalance -= load; >>> + break; >>> + >>> + case migrate_util: >>> + util = task_util_est(p); >>> + >>> + if (util > env->imbalance) >> >> Can you please explain what would happen for >> `if (util/2 > env->imbalance)` ? >> just like when migrating load, even util shouldn't be migrated if >> env->imbalance is just near the utilization of the task being moved, isn't >> it? > > I have chosen uti and not util/2 to be conservative because > migrate_util is used to fill spare capacity. > With `if (util/2 > env->imbalance)`, we can more easily overload the > local group or pick too much utilization from the overloaded group. > fair enough. I missed the point that unlike migrate_load, with migrate_util, env->imbalance is just spare capacity of the local group. Thanks, Parth >> >>> + goto next; >>> + >>> + env->imbalance -= util; >>> + break; >>> +[ ... ] >> >> Thanks, >> Parth >>
Re: [PATCH 09/15] riscv: provide native clint access for M-mode
On Thu, Oct 17, 2019 at 11:08 PM Christoph Hellwig wrote: > > RISC-V has the concept of a cpu level interrupt controller. The > interface for it is split between a standardized part that is exposed > as bits in the mstatus/sstatus register and the mie/mip/sie/sip > CRS. But the bit to actually trigger IPIs is not standardized and > just mentioned as implementable using MMIO. > > Add support for IPIs using MMIO using the SiFive clint layout (which is > also shared by Ariane, Kendrye and the Qemu virt platform). Additional > the MMIO block also support the time value and timer compare registers, > so they are also set up using the same OF node. Support for other > layouts should also be relatively easy to add in the future. > > Signed-off-by: Christoph Hellwig > --- > arch/riscv/include/asm/clint.h | 39 ++ > arch/riscv/include/asm/sbi.h | 2 ++ > arch/riscv/kernel/Makefile | 1 + > arch/riscv/kernel/clint.c | 44 ++ > arch/riscv/kernel/setup.c | 2 ++ > arch/riscv/kernel/smp.c| 16 ++--- > arch/riscv/kernel/smpboot.c| 4 > 7 files changed, 105 insertions(+), 3 deletions(-) > create mode 100644 arch/riscv/include/asm/clint.h > create mode 100644 arch/riscv/kernel/clint.c > > diff --git a/arch/riscv/include/asm/clint.h b/arch/riscv/include/asm/clint.h > new file mode 100644 > index ..02a26b68f21d > --- /dev/null > +++ b/arch/riscv/include/asm/clint.h > @@ -0,0 +1,39 @@ > +// SPDX-License-Identifier: GPL-2.0 > +#ifndef _ASM_CLINT_H > +#define _ASM_CLINT_H 1 > + > +#include > +#include > + > +#ifdef CONFIG_RISCV_M_MODE > +extern u32 __iomem *clint_ipi_base; > + > +void clint_init_boot_cpu(void); > + > +static inline void clint_send_ipi_single(unsigned long hartid) > +{ > + writel(1, clint_ipi_base + hartid); > +} > + > +static inline void clint_send_ipi_mask(const struct cpumask *hartid_mask) > +{ > + int hartid; > + > + for_each_cpu(hartid, hartid_mask) > + clint_send_ipi_single(hartid); > +} > + > +static inline void clint_clear_ipi(unsigned long hartid) > +{ > + writel(0, clint_ipi_base + hartid); > +} > +#else /* CONFIG_RISCV_M_MODE */ > +#define clint_init_boot_cpu() do { } while (0) > + > +/* stubs to for code is only reachable under > IS_ENABLED(CONFIG_RISCV_M_MODE): */ > +void clint_send_ipi_single(unsigned long hartid); > +void clint_send_ipi_mask(const struct cpumask *hartid_mask); > +void clint_clear_ipi(unsigned long hartid); > +#endif /* CONFIG_RISCV_M_MODE */ > + > +#endif /* _ASM_CLINT_H */ > diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h > index a4774bafe033..407d1024f9eb 100644 > --- a/arch/riscv/include/asm/sbi.h > +++ b/arch/riscv/include/asm/sbi.h > @@ -97,6 +97,8 @@ static inline void sbi_remote_sfence_vma_asid(const > unsigned long *hart_mask, > #else /* CONFIG_RISCV_SBI */ > /* stubs to for code is only reachable under IS_ENABLED(CONFIG_RISCV_SBI): */ > void sbi_set_timer(uint64_t stime_value); > +void sbi_clear_ipi(void); > +void sbi_send_ipi(const unsigned long *hart_mask); > void sbi_remote_fence_i(const unsigned long *hart_mask); > #endif /* CONFIG_RISCV_SBI */ > #endif /* _ASM_RISCV_SBI_H */ > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile > index d8c35fa93cc6..2dca51046899 100644 > --- a/arch/riscv/kernel/Makefile > +++ b/arch/riscv/kernel/Makefile > @@ -29,6 +29,7 @@ obj-y += vdso.o > obj-y += cacheinfo.o > obj-y += vdso/ > > +obj-$(CONFIG_RISCV_M_MODE) += clint.o > obj-$(CONFIG_FPU) += fpu.o > obj-$(CONFIG_SMP) += smpboot.o > obj-$(CONFIG_SMP) += smp.o > diff --git a/arch/riscv/kernel/clint.c b/arch/riscv/kernel/clint.c > new file mode 100644 > index ..3647980d14c3 > --- /dev/null > +++ b/arch/riscv/kernel/clint.c > @@ -0,0 +1,44 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (c) 2019 Christoph Hellwig. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* > + * This is the layout used by the SiFive clint, which is also shared by the > qemu > + * virt platform, and the Kendryte KD210 at least. > + */ > +#define CLINT_IPI_OFF 0 > +#define CLINT_TIME_CMP_OFF 0x4000 > +#define CLINT_TIME_VAL_OFF 0xbff8 > + > +u32 __iomem *clint_ipi_base; > + > +void clint_init_boot_cpu(void) > +{ > + struct device_node *np; > + void __iomem *base; > + > + np = of_find_compatible_node(NULL, NULL, "riscv,clint0"); > + if (!np) { > + panic("clint not found"); > + return; > + } > + > + base = of_iomap(np, 0); > + if (!base) > + panic("could not map CLINT"); > + > + clint_ipi_base = base + CLINT_IPI_OFF; > + riscv_time_cmp = base + CLINT_TIME_CMP_OFF; > + riscv_time_val = base + CLINT_TIME_VAL_OFF; > + > + clint_clear_ipi(boot_c
[PATCH net] net: hns3: fix mis-counting IRQ vector numbers issue
From: Yonglong Liu Currently, the num_msi_left means the vector numbers of NIC, but if the PF supported RoCE, it contains the vector numbers of NIC and RoCE(Not expected). This may cause interrupts lost in some case, because of the NIC module used the vector resources which belongs to RoCE. This patch adds a new variable num_nic_msi to store the vector numbers of NIC, and adjust the default TQP numbers and rss_size according to the value of num_nic_msi. Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Signed-off-by: Yonglong Liu Signed-off-by: Huazhong Tan --- drivers/net/ethernet/hisilicon/hns3/hnae3.h| 2 ++ .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 21 +++- .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h| 1 + .../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c | 11 +++-- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 28 +++--- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h | 1 + 6 files changed, 58 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h b/drivers/net/ethernet/hisilicon/hns3/hnae3.h index c4b7bf8..75ccc1e 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h +++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h @@ -32,6 +32,8 @@ #define HNAE3_MOD_VERSION "1.0" +#define HNAE3_MIN_VECTOR_NUM 2 /* first one for misc, another for IO */ + /* Device IDs */ #define HNAE3_DEV_ID_GE0xA220 #define HNAE3_DEV_ID_25GE 0xA221 diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c index fd7f943..e02e01b 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c @@ -906,6 +906,9 @@ static int hclge_query_pf_resource(struct hclge_dev *hdev) hnae3_get_field(__le16_to_cpu(req->pf_intr_vector_number), HCLGE_PF_VEC_NUM_M, HCLGE_PF_VEC_NUM_S); + /* nic's msix numbers is always equals to the roce's. */ + hdev->num_nic_msi = hdev->num_roce_msi; + /* PF should have NIC vectors and Roce vectors, * NIC vectors are queued before Roce vectors. */ @@ -915,6 +918,15 @@ static int hclge_query_pf_resource(struct hclge_dev *hdev) hdev->num_msi = hnae3_get_field(__le16_to_cpu(req->pf_intr_vector_number), HCLGE_PF_VEC_NUM_M, HCLGE_PF_VEC_NUM_S); + + hdev->num_nic_msi = hdev->num_msi; + } + + if (hdev->num_nic_msi < HNAE3_MIN_VECTOR_NUM) { + dev_err(&hdev->pdev->dev, + "Just %u msi resources, not enough for pf(min:2).\n", + hdev->num_nic_msi); + return -EINVAL; } return 0; @@ -1507,6 +1519,10 @@ static int hclge_assign_tqp(struct hclge_vport *vport, u16 num_tqps) kinfo->rss_size = min_t(u16, hdev->rss_size_max, vport->alloc_tqps / hdev->tm_info.num_tc); + /* ensure one to one mapping between irq and queue at default */ + kinfo->rss_size = min_t(u16, kinfo->rss_size, + (hdev->num_nic_msi - 1) / hdev->tm_info.num_tc); + return 0; } @@ -2285,7 +2301,8 @@ static int hclge_init_msi(struct hclge_dev *hdev) int vectors; int i; - vectors = pci_alloc_irq_vectors(pdev, 1, hdev->num_msi, + vectors = pci_alloc_irq_vectors(pdev, HNAE3_MIN_VECTOR_NUM, + hdev->num_msi, PCI_IRQ_MSI | PCI_IRQ_MSIX); if (vectors < 0) { dev_err(&pdev->dev, @@ -2300,6 +2317,7 @@ static int hclge_init_msi(struct hclge_dev *hdev) hdev->num_msi = vectors; hdev->num_msi_left = vectors; + hdev->base_msi_vector = pdev->irq; hdev->roce_base_vector = hdev->base_msi_vector + hdev->roce_base_msix_offset; @@ -3903,6 +3921,7 @@ static int hclge_get_vector(struct hnae3_handle *handle, u16 vector_num, int alloc = 0; int i, j; + vector_num = min_t(u16, hdev->num_nic_msi - 1, vector_num); vector_num = min(hdev->num_msi_left, vector_num); for (j = 0; j < vector_num; j++) { diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h index 3e9574a..c3d56b8 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h @@ -763,6 +763,7 @@ struct hclge_dev { u32 base_msi_vector; u16 *vector_status; int *vector_irq; + u16 num_nic_msi;/* Num of nic vectors for this PF */ u16 num_roce_msi; /* Num of roce vec
Re: [PATCH 11/15] riscv: use the correct interrupt levels for M-mode
On Thu, Oct 17, 2019 at 11:08 PM Christoph Hellwig wrote: > > The numerical levels for External/Timer/Software interrupts differ > between S-mode and M-mode. > > Signed-off-by: Christoph Hellwig > --- > arch/riscv/kernel/irq.c | 12 +--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/arch/riscv/kernel/irq.c b/arch/riscv/kernel/irq.c > index 804ff70bb853..dbd1fd7c22e4 100644 > --- a/arch/riscv/kernel/irq.c > +++ b/arch/riscv/kernel/irq.c > @@ -14,9 +14,15 @@ > /* > * Possible interrupt causes: > */ > -#define INTERRUPT_CAUSE_SOFTWARE IRQ_S_SOFT > -#define INTERRUPT_CAUSE_TIMER IRQ_S_TIMER > -#define INTERRUPT_CAUSE_EXTERNAL IRQ_S_EXT > +#ifdef CONFIG_RISCV_M_MODE > +# define INTERRUPT_CAUSE_SOFTWARE IRQ_M_SOFT > +# define INTERRUPT_CAUSE_TIMER IRQ_M_TIMER > +# define INTERRUPT_CAUSE_EXTERNAL IRQ_M_EXT > +#else > +# define INTERRUPT_CAUSE_SOFTWARE IRQ_S_SOFT > +# define INTERRUPT_CAUSE_TIMER IRQ_S_TIMER > +# define INTERRUPT_CAUSE_EXTERNAL IRQ_S_EXT > +#endif /* CONFIG_RISCV_M_MODE */ > > int arch_show_interrupts(struct seq_file *p, int prec) > { > -- > 2.20.1 > LGTM. Reviewed-by: Anup Patel Regards, Anup
Re: [PATCH v4 1/2] clk: qcom: Add MSM8998 GPU Clock Controller (GPUCC) driver
Hi Jeffrey, On 10/2/2019 6:46 AM, Jeffrey Hugo wrote: The GPUCC manages the clocks for the Adreno GPU found on MSM8998. Signed-off-by: Jeffrey Hugo --- drivers/clk/qcom/Kconfig | 9 + drivers/clk/qcom/Makefile| 1 + drivers/clk/qcom/gpucc-msm8998.c | 346 +++ 3 files changed, 356 insertions(+) create mode 100644 drivers/clk/qcom/gpucc-msm8998.c diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig index 96efee18fa6c..31a70168327c 100644 --- a/drivers/clk/qcom/Kconfig +++ b/drivers/clk/qcom/Kconfig @@ -230,6 +230,15 @@ config MSM_MMCC_8998 Say Y if you want to support multimedia devices such as display, graphics, video encode/decode, camera, etc. +config MSM_GPUCC_8998 + tristate "MSM8998 Graphics Clock Controller" + select MSM_GCC_8998 + select QCOM_GDSC + help + Support for the graphics clock controller on MSM8998 devices. + Say Y if you want to support graphics controller devices and + functionality such as 3D graphics. + config QCS_GCC_404 tristate "QCS404 Global Clock Controller" help diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile index 0ac3c1459313..616b68f91db6 100644 --- a/drivers/clk/qcom/Makefile +++ b/drivers/clk/qcom/Makefile @@ -33,6 +33,7 @@ obj-$(CONFIG_MSM_GCC_8994) += gcc-msm8994.o obj-$(CONFIG_MSM_GCC_8996) += gcc-msm8996.o obj-$(CONFIG_MSM_LCC_8960) += lcc-msm8960.o obj-$(CONFIG_MSM_GCC_8998) += gcc-msm8998.o +obj-$(CONFIG_MSM_GPUCC_8998) += gpucc-msm8998.o obj-$(CONFIG_MSM_MMCC_8960) += mmcc-msm8960.o obj-$(CONFIG_MSM_MMCC_8974) += mmcc-msm8974.o obj-$(CONFIG_MSM_MMCC_8996) += mmcc-msm8996.o diff --git a/drivers/clk/qcom/gpucc-msm8998.c b/drivers/clk/qcom/gpucc-msm8998.c new file mode 100644 index ..f0ccb4963885 --- /dev/null +++ b/drivers/clk/qcom/gpucc-msm8998.c @@ -0,0 +1,346 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2019, Jeffrey Hugo + */ + Copyright (c) 2019, The Linux Foundation. All rights reserved. +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "common.h" +#include "clk-regmap.h" +#include "clk-regmap-divider.h" +#include "clk-alpha-pll.h" +#include "clk-rcg.h" +#include "clk-branch.h" +#include "reset.h" +#include "gdsc.h" + +enum { + P_XO, + P_GPLL0, + P_GPUPLL0_OUT_EVEN, +}; + +/* Instead of going directly to the block, XO is routed through this branch */ +static struct clk_branch gpucc_cxo_clk = { + .halt_reg = 0x1020, + .clkr = { + .enable_reg = 0x1020, + .enable_mask = BIT(0), + .hw.init = &(struct clk_init_data){ + .name = "gpucc_cxo_clk", + .parent_data = &(const struct clk_parent_data){ + .fw_name = "xo", + .name = "xo" + }, + .num_parents = 1, + .ops = &clk_branch2_ops, + .flags = CLK_IS_CRITICAL, + }, + }, +}; + +static const struct clk_div_table post_div_table_fabia_even[] = { + { 0x0, 1 }, + { 0x1, 2 }, + { 0x3, 4 }, + { 0x7, 8 }, + { } +}; + +static struct clk_alpha_pll gpupll0 = { + .offset = 0x0, + .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_FABIA], + .clkr.hw.init = &(struct clk_init_data){ + .name = "gpupll0", + .parent_hws = (const struct clk_hw *[]){ &gpucc_cxo_clk.clkr.hw }, + .num_parents = 1, + .ops = &clk_alpha_pll_fixed_fabia_ops, + }, +}; + +static struct clk_alpha_pll_postdiv gpupll0_out_even = { + .offset = 0x0, + .post_div_shift = 8, + .post_div_table = post_div_table_fabia_even, + .num_post_div = ARRAY_SIZE(post_div_table_fabia_even), + .width = 4, + .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_FABIA], + .clkr.hw.init = &(struct clk_init_data){ + .name = "gpupll0_out_even", + .parent_hws = (const struct clk_hw *[]){ &gpupll0.clkr.hw }, + .num_parents = 1, + .ops = &clk_alpha_pll_postdiv_fabia_ops, + }, +}; + +static const struct parent_map gpu_xo_gpll0_map[] = { + { P_XO, 0 }, + { P_GPLL0, 5 }, +}; + +static const struct clk_parent_data gpu_xo_gpll0[] = { + { .hw = &gpucc_cxo_clk.clkr.hw }, + { .fw_name = "gpll0", .name = "gpll0" }, +}; + +static const struct parent_map gpu_xo_gpupll0_map[] = { + { P_XO, 0 }, + { P_GPUPLL0_OUT_EVEN, 1 }, +}; + +static const struct clk_parent_data gpu_xo_gpupll0[] = { + { .hw = &gpucc_cxo_clk.clkr.hw }, + { .hw = &gpupll0_out_even.clkr.hw }, +}; + +static const struct freq_tbl ftbl_rbcpr_clk_src[] = { + F(1920, P_XO, 1, 0, 0), + F(5000
Re: [PATCH] cpufreq: powernv: fix stack bloat and NR_CPUS limitation
On 17-10-19, 17:04, John Hubbard wrote: > The following build warning occurred on powerpc 64-bit builds: > > drivers/cpufreq/powernv-cpufreq.c: In function 'init_chip_info': > drivers/cpufreq/powernv-cpufreq.c:1070:1: warning: the frame size of 1040 > bytes is larger than 1024 bytes [-Wframe-larger-than=] How come we are catching this warning after 4 years ? > > This is due to putting 1024 bytes on the stack: > > unsigned int chip[256]; > > ...and while looking at this, it also has a bug: it fails with a stack > overrun, if CONFIG_NR_CPUS > 256. > > Fix both problems by dynamically allocating based on CONFIG_NR_CPUS. > > Fixes: 053819e0bf840 ("cpufreq: powernv: Handle throttling due to Pmax > capping at chip level") > Cc: Shilpasri G Bhat > Cc: Preeti U Murthy > Cc: Viresh Kumar > Cc: Rafael J. Wysocki > Cc: linux...@vger.kernel.org > Cc: linuxppc-...@lists.ozlabs.org > Signed-off-by: John Hubbard > --- > > Hi, > > I have only compile-tested this, so I would appreciate if anyone > could do a basic runtime test on it. But (famous last words) it > seems simple enough that I'm confident it's correct. oh boy. :) > > thanks, > John Hubbard > NVIDIA > > drivers/cpufreq/powernv-cpufreq.c | 17 + > 1 file changed, 13 insertions(+), 4 deletions(-) > > diff --git a/drivers/cpufreq/powernv-cpufreq.c > b/drivers/cpufreq/powernv-cpufreq.c > index 6061850e59c9..78e04402125f 100644 > --- a/drivers/cpufreq/powernv-cpufreq.c > +++ b/drivers/cpufreq/powernv-cpufreq.c > @@ -1041,9 +1041,14 @@ static struct cpufreq_driver powernv_cpufreq_driver = { > > static int init_chip_info(void) > { > - unsigned int chip[256]; > + unsigned int *chip; > unsigned int cpu, i; > unsigned int prev_chip_id = UINT_MAX; > + int ret = 0; > + > + chip = kcalloc(CONFIG_NR_CPUS, sizeof(int), GFP_KERNEL); sizeof(*chip) > + if (!chips) (!chip) > + return -ENOMEM; > > for_each_possible_cpu(cpu) { > unsigned int id = cpu_to_chip_id(cpu); > @@ -1055,8 +1060,10 @@ static int init_chip_info(void) > } > > chips = kcalloc(nr_chips, sizeof(struct chip), GFP_KERNEL); > - if (!chips) > - return -ENOMEM; > + if (!chips) { > + ret = -ENOMEM; > + goto free_and_return; > + } > > for (i = 0; i < nr_chips; i++) { > chips[i].id = chip[i]; > @@ -1066,7 +1073,9 @@ static int init_chip_info(void) > per_cpu(chip_info, cpu) = &chips[i]; > } > > - return 0; > +free_and_return: > + kfree(chip); > + return ret; > } > > static inline void clean_chip_info(void) > -- > 2.23.0 -- viresh
[PATCH v4 1/2] dt-bindings: iio: accel: bma400: add bindings
Add devicetree binding for the Bosch BMA400 3-axes ultra-low power accelerometer sensor. Signed-off-by: Dan Robertson --- .../devicetree/bindings/iio/accel/bma400.yaml | 39 +++ 1 file changed, 39 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/accel/bma400.yaml diff --git a/Documentation/devicetree/bindings/iio/accel/bma400.yaml b/Documentation/devicetree/bindings/iio/accel/bma400.yaml new file mode 100644 index ..e0a85dc7bf34 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/accel/bma400.yaml @@ -0,0 +1,39 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/accel/bma400.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bosch BMA400 triaxial acceleration sensor + +maintainers: + - Dan Robertson + +description: | + Acceleration and temerature iio sensors with an i2c interface + + Specifications about the sensor can be found at: + https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BMA400-DS000.pdf + +properties: + compatible: +enum: + - bosch,bma400 + + reg: +maxItems: 1 + +required: + - compatible + - reg + +examples: + - | +i2c0 { + #address-cells = <1>; + #size-cells = <0>; + bma400@14 { +compatible = "bosch,bma400"; +reg = <0x14>; + }; +};
[PATCH v4 2/2] iio: (bma400) add driver for the BMA400
Add a IIO driver for the Bosch BMA400 3-axes ultra-low power accelerometer. The driver supports reading from the acceleration and temperature registers. The driver also supports reading and configuring the output data rate, oversampling ratio, and scale. Signed-off-by: Dan Robertson --- drivers/iio/accel/Kconfig | 18 + drivers/iio/accel/Makefile | 2 + drivers/iio/accel/bma400.h | 85 drivers/iio/accel/bma400_core.c | 796 drivers/iio/accel/bma400_i2c.c | 60 +++ 5 files changed, 961 insertions(+) create mode 100644 drivers/iio/accel/bma400.h create mode 100644 drivers/iio/accel/bma400_core.c create mode 100644 drivers/iio/accel/bma400_i2c.c diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig index 9b9656ce37e6..a1081b902d16 100644 --- a/drivers/iio/accel/Kconfig +++ b/drivers/iio/accel/Kconfig @@ -112,6 +112,24 @@ config BMA220 To compile this driver as a module, choose M here: the module will be called bma220_spi. +config BMA400 + tristate "Bosch BMA400 3-Axis Accelerometer Driver" + depends on I2C + select REGMAP + select BMA400_I2C if (I2C) + help + Say Y here if you want to build a driver for the Bosch BMA400 + triaxial acceleration sensor. + + To compile this driver as a module, choose M here: the + module will be called bma400_core and you will also get + bma400_i2c for I2C. + +config BMA400_I2C + tristate + depends on BMA400 + select REGMAP_I2C + config BMC150_ACCEL tristate "Bosch BMC150 Accelerometer Driver" select IIO_BUFFER diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile index 56bd0215e0d4..3a051cf37f40 100644 --- a/drivers/iio/accel/Makefile +++ b/drivers/iio/accel/Makefile @@ -14,6 +14,8 @@ obj-$(CONFIG_ADXL372_I2C) += adxl372_i2c.o obj-$(CONFIG_ADXL372_SPI) += adxl372_spi.o obj-$(CONFIG_BMA180) += bma180.o obj-$(CONFIG_BMA220) += bma220_spi.o +obj-$(CONFIG_BMA400) += bma400_core.o +obj-$(CONFIG_BMA400_I2C) += bma400_i2c.o obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel-core.o obj-$(CONFIG_BMC150_ACCEL_I2C) += bmc150-accel-i2c.o obj-$(CONFIG_BMC150_ACCEL_SPI) += bmc150-accel-spi.o diff --git a/drivers/iio/accel/bma400.h b/drivers/iio/accel/bma400.h new file mode 100644 index ..3a3860220a68 --- /dev/null +++ b/drivers/iio/accel/bma400.h @@ -0,0 +1,85 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * bma400.h - Register constants and other forward declarations + *needed by the bma400 sources. + * + * Copyright 2019 Dan Robertson + */ + +#ifndef _BMA400_H_ +#define _BMA400_H_ + +#include + +/* + * Read-Only Registers + */ + +/* Status and ID registers */ +#define BMA400_CHIP_ID_REG 0x00 +#define BMA400_ERR_REG 0x02 +#define BMA400_STATUS_REG 0x03 + +/* Acceleration registers */ +#define BMA400_X_AXIS_LSB_REG 0x04 +#define BMA400_X_AXIS_MSB_REG 0x05 +#define BMA400_Y_AXIS_LSB_REG 0x06 +#define BMA400_Y_AXIS_MSB_REG 0x07 +#define BMA400_Z_AXIS_LSB_REG 0x08 +#define BMA400_Z_AXIS_MSB_REG 0x09 + +/* Sensor time registers */ +#define BMA400_SENSOR_TIME0 0x0a +#define BMA400_SENSOR_TIME1 0x0b +#define BMA400_SENSOR_TIME2 0x0c + +/* Event and interrupt registers */ +#define BMA400_EVENT_REG0x0d +#define BMA400_INT_STAT0_REG0x0e +#define BMA400_INT_STAT1_REG0x0f +#define BMA400_INT_STAT2_REG0x10 + +/* Temperature register */ +#define BMA400_TEMP_DATA_REG0x11 + +/* FIFO length and data registers */ +#define BMA400_FIFO_LENGTH0_REG 0x12 +#define BMA400_FIFO_LENGTH1_REG 0x13 +#define BMA400_FIFO_DATA_REG0x14 + +/* Step count registers */ +#define BMA400_STEP_CNT0_REG0x15 +#define BMA400_STEP_CNT1_REG0x16 +#define BMA400_STEP_CNT3_REG0x17 +#define BMA400_STEP_STAT_REG0x18 + +/* + * Read-write configuration registers + */ +#define BMA400_ACC_CONFIG0_REG 0x19 +#define BMA400_ACC_CONFIG1_REG 0x1a +#define BMA400_ACC_CONFIG2_REG 0x1b +#define BMA400_CMD_REG 0x7e + +/* Chip ID of BMA 400 devices found in the chip ID register. */ +#define BMA400_ID_REG_VAL 0x90 + +#define BMA400_TWO_BITS_MASK0x03 +#define BMA400_LP_OSR_MASK 0x60 +#define BMA400_NP_OSR_MASK 0x30 +#define BMA400_ACC_ODR_MASK 0x0f +#define BMA400_ACC_SCALE_MASK 0xc0 + +#define BMA400_LP_OSR_SHIFT 0x05 +#define BMA400_NP_OSR_SHIFT 0x04 +#define BMA400_SCALE_SHIFT 0x06 + +#define BMA400_ACC_ODR_MIN 0x05 + +extern const struct regmap_config bma400_regmap_config; + +int bma400_probe(struct device *dev, struct regmap *regmap, const char *name); + +int bma400_remove(struct device *dev); + +#endif diff --git a/drivers/iio/accel/bma400_core.c b/drivers/iio/accel/bma400_core.c new file mode 100644 index ..80f1ee6713fa --- /dev/null +++ b/drivers/iio/accel/bma400_core.c @@ -0,0 +1,796 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * bma400_cor
Re: [PATCH 10/15] riscv: read the hart ID from mhartid on boot
On Thu, Oct 17, 2019 at 11:08 PM Christoph Hellwig wrote: > > From: Damien Le Moal > > When in M-Mode, we can use the mhartid CSR to get the ID of the running > HART. Doing so, direct M-Mode boot without firmware is possible. > > Signed-off-by: Damien Le Moal > Signed-off-by: Christoph Hellwig > Reviewed-by: Atish Patra > --- > arch/riscv/include/asm/csr.h | 1 + > arch/riscv/kernel/head.S | 8 > 2 files changed, 9 insertions(+) > > diff --git a/arch/riscv/include/asm/csr.h b/arch/riscv/include/asm/csr.h > index 0dae5c361f29..d0b5113e1a54 100644 > --- a/arch/riscv/include/asm/csr.h > +++ b/arch/riscv/include/asm/csr.h > @@ -81,6 +81,7 @@ > #define SIE_SEIE (_AC(0x1, UL) << IRQ_S_EXT) > > /* symbolic CSR names: */ > +#define CSR_MHARTID0xf14 > #define CSR_MSTATUS0x300 > #define CSR_MIE0x304 > #define CSR_MTVEC 0x305 > diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S > index 679e63d29edb..583784cb3a32 100644 > --- a/arch/riscv/kernel/head.S > +++ b/arch/riscv/kernel/head.S > @@ -50,6 +50,14 @@ _start_kernel: > csrw CSR_XIE, zero > csrw CSR_XIP, zero > > +#ifdef CONFIG_RISCV_M_MODE > + /* > +* The hartid in a0 is expected later on, and we have no firmware > +* to hand it to us. > +*/ > + csrr a0, CSR_MHARTID > +#endif > + > /* Load the global pointer */ > .option push > .option norelax > -- > 2.20.1 > > > ___ > linux-riscv mailing list > linux-ri...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv LGTM. Reviewed-by: Anup Patel Regards, Anup
[PATCH v3 0/2] iio: add driver for Bosch BMA400 accelerometer
This patchset adds a IIO driver for the Bosch BMA400 3-axes ultra low-power accelerometer. The initial implementation of the driver adds read support for the acceleration and temperature data registers. The driver also has support for reading and writing to the output data rate, oversampling ratio, and scale configuration registers. I've ran some basic tests with libiio and I've run the device tree checks. Are there other tests that are recommended to be run for a new device? Thanks again for the reviews! Cheers, - Dan Changes in v4: * Fix error in DT bindings * Fix typo when setting the OSR * Simplified the cached sample frequency * Fix the MODULE_LICENSE Changes in v3: * Use yaml format for DT bindings * Remove strict dependency on OF * Tidy Kconfig dependencies * Stylistic changes * Do not soft-reset device on remove Changes in v2: * Implemented iio_info -> read_avail * Stylistic changes * Implemented devicetree bindings Dan Robertson (2): dt-bindings: iio: accel: bma400: add bindings iio: (bma400) add driver for the BMA400 .../devicetree/bindings/iio/accel/bma400.yaml | 39 + drivers/iio/accel/Kconfig | 18 + drivers/iio/accel/Makefile| 2 + drivers/iio/accel/bma400.h| 85 ++ drivers/iio/accel/bma400_core.c | 796 ++ drivers/iio/accel/bma400_i2c.c| 60 ++ 6 files changed, 1000 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/accel/bma400.yaml create mode 100644 drivers/iio/accel/bma400.h create mode 100644 drivers/iio/accel/bma400_core.c create mode 100644 drivers/iio/accel/bma400_i2c.c
Re: [PATCH 3/8] riscv: init: merge split string literals in preprocessor directive
On Thu, Oct 17, 2019 at 09:38:18PM -0700, Paul Walmsley wrote: > On Fri, 18 Oct 2019, Luc Van Oostenryck wrote: > > > On Thu, Oct 17, 2019 at 05:49:24PM -0700, Paul Walmsley wrote: > > > sparse complains loudly when string literals associated with > > > preprocessor directives are split into multiple, separately quoted > > > strings across different lines: > > > > ... > > > > > #ifndef __riscv_cmodel_medany > > > -#error "setup_vm() is called from head.S before relocate so it should " > > > - "not use absolute addressing." > > > +#error "setup_vm() is called from head.S before relocate so it should > > > not use absolute addressing." > > > #endif > > > > Using a blacslash should do the trick : > > #error "blablablablablablablablablablablabla" \ > > "and blablabla again" > > Or if need I cn fix Sparse if needed and desiable. > > Thanks for the kind offer! > > The backslashless syntax is pretty horrible to my eyes. As far as I can > tell from a brief glance, the instance fixed by this patch was the only > instance of its kind in the kernel. The existing kernel precedents appear > to be to simply use a single long line. Example: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/compiler-gcc.h#n3 > > So, from a kernel point of view, we should just fix this specific > instance. It doesn't seem worth changing sparse for such a rare case. > > On the other hand, gcc seems to support the non-backslashed syntax. So if > the intention is for sparse to follow the gcc practice, and to be used > beyond the kernel, maybe it's worth aligning sparse to gcc? Only if > you're bored, I suppose... I'll first see what is acceptable for the point of view of the standard (and maybe some justifications from GCC). -- Luc
Re: [PATCH 04/15] riscv: don't allow selecting SBI based drivers for M-mode
On Thu, Oct 17, 2019 at 11:07 PM Christoph Hellwig wrote: > > From: Damien Le Moal > > When running in M-mode we can't use SBI based drivers. Add a new > CONFIG_RISCV_SBI that drivers that do SBI calls can depend on > instead. > > Signed-off-by: Damien Le Moal > Signed-off-by: Christoph Hellwig > --- > arch/riscv/Kconfig | 6 ++ > drivers/tty/hvc/Kconfig| 2 +- > drivers/tty/serial/Kconfig | 2 +- > 3 files changed, 8 insertions(+), 2 deletions(-) > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > index 86b7e8b0471c..b85492c42ccb 100644 > --- a/arch/riscv/Kconfig > +++ b/arch/riscv/Kconfig > @@ -76,6 +76,12 @@ config ARCH_MMAP_RND_BITS_MAX > config RISCV_M_MODE > bool > > +# set if we are running in S-mode and can use SBI calls > +config RISCV_SBI > + bool > + depends on !RISCV_M_MODE > + default y > + > config MMU > def_bool y > > diff --git a/drivers/tty/hvc/Kconfig b/drivers/tty/hvc/Kconfig > index 4d22b91f..4487a6b9acc8 100644 > --- a/drivers/tty/hvc/Kconfig > +++ b/drivers/tty/hvc/Kconfig > @@ -89,7 +89,7 @@ config HVC_DCC > > config HVC_RISCV_SBI > bool "RISC-V SBI console support" > - depends on RISCV > + depends on RISCV_SBI > select HVC_DRIVER > help > This enables support for console output via RISC-V SBI calls, which > diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig > index 67a9eb3f94ce..540142c5b7b3 100644 > --- a/drivers/tty/serial/Kconfig > +++ b/drivers/tty/serial/Kconfig > @@ -88,7 +88,7 @@ config SERIAL_EARLYCON_ARM_SEMIHOST > > config SERIAL_EARLYCON_RISCV_SBI > bool "Early console using RISC-V SBI" > - depends on RISCV > + depends on RISCV_SBI > select SERIAL_CORE > select SERIAL_CORE_CONSOLE > select SERIAL_EARLYCON > -- > 2.20.1 > > > ___ > linux-riscv mailing list > linux-ri...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv LGTM. Reviewed-by: Anup Patel Regards, Anup
Re: [PATCH 06/15] riscv: cleanup the default power off implementation
On Thu, Oct 17, 2019 at 11:08 PM Christoph Hellwig wrote: > > Move the sbi poweroff to a separate function and file that is only > compiled if CONFIG_SBI is set. Provide a new default fallback > power off that just sits in a wfi loop to save some power. > > Signed-off-by: Christoph Hellwig > Reviewed-by: Atish Patra > --- > arch/riscv/kernel/Makefile | 1 + > arch/riscv/kernel/reset.c | 5 ++--- > arch/riscv/kernel/sbi.c| 17 + > 3 files changed, 20 insertions(+), 3 deletions(-) > create mode 100644 arch/riscv/kernel/sbi.c > > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile > index 696020ff72db..d8c35fa93cc6 100644 > --- a/arch/riscv/kernel/Makefile > +++ b/arch/riscv/kernel/Makefile > @@ -41,5 +41,6 @@ obj-$(CONFIG_DYNAMIC_FTRACE) += mcount-dyn.o > obj-$(CONFIG_PERF_EVENTS) += perf_event.o > obj-$(CONFIG_PERF_EVENTS) += perf_callchain.o > obj-$(CONFIG_HAVE_PERF_REGS) += perf_regs.o > +obj-$(CONFIG_RISCV_SBI)+= sbi.o > > clean: > diff --git a/arch/riscv/kernel/reset.c b/arch/riscv/kernel/reset.c > index d0fe623bfb8f..5e4e69859af1 100644 > --- a/arch/riscv/kernel/reset.c > +++ b/arch/riscv/kernel/reset.c > @@ -4,12 +4,11 @@ > */ > > #include > -#include > > static void default_power_off(void) > { > - sbi_shutdown(); > - while (1); > + while (1) > + wait_for_interrupt(); > } > > void (*pm_power_off)(void) = default_power_off; > diff --git a/arch/riscv/kernel/sbi.c b/arch/riscv/kernel/sbi.c > new file mode 100644 > index ..f6c7c3e82d28 > --- /dev/null > +++ b/arch/riscv/kernel/sbi.c > @@ -0,0 +1,17 @@ > +// SPDX-License-Identifier: GPL-2.0-only > + > +#include > +#include > +#include > + > +static void sbi_power_off(void) > +{ > + sbi_shutdown(); > +} > + > +static int __init sbi_init(void) > +{ > + pm_power_off = sbi_power_off; > + return 0; > +} > +early_initcall(sbi_init); > -- > 2.20.1 > > > ___ > linux-riscv mailing list > linux-ri...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv LGTM. Reviewed-by: Anup Patel Regards, Anup
Re: [PATCH 4/8] riscv: ensure RISC-V C model definitions are passed to static analyzers
On Thu, Oct 17, 2019 at 09:39:29PM -0700, Paul Walmsley wrote: > On Fri, 18 Oct 2019, Luc Van Oostenryck wrote: > > On Thu, Oct 17, 2019 at 05:49:25PM -0700, Paul Walmsley wrote: > > > ifeq ($(CONFIG_CMODEL_MEDANY),y) > > > KBUILD_CFLAGS += -mcmodel=medany > > > + CHECKFLAGS += -D__riscv_cmodel_medany > > > > I can teach sparse about this in the following days. > > That would be great. Would you be willing to follow up with me via E-mail > or mailing list post when it's fixed? If so, then in the meantime, I'll > just drop this patch. For sure. -- Luc
[PATCH v12 0/5] DMA-BUF Heaps (destaging ION)
Andrew brought up a reasonable concern with the CMA heap enumeration in the previous patch set, and I had a few other minor cleanups to add, so here is yet another pass at the dma-buf heaps patchset Andrew and I have been working on which tries to destage a fair chunk of ION functionality. The patchset implements per-heap devices which can be opened directly and then an ioctl is used to allocate a dmabuf from the heap. The interface is similar, but much simpler then IONs, only providing an ALLOC ioctl. Also, I've provided relatively simple system and cma heaps. I've booted and tested these patches with AOSP on the HiKey960 using the kernel tree here: https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap And the userspace changes here: https://android-review.googlesource.com/c/device/linaro/hikey/+/909436 Compared to ION, this patchset is missing the system-contig, carveout and chunk heaps, as I don't have a device that uses those, so I'm unable to do much useful validation there. Additionally we have no upstream users of chunk or carveout, and the system-contig has been deprecated in the common/andoid-* kernels, so this should be ok. I've also removed the stats accounting, since any such accounting should be implemented by dma-buf core or the heaps themselves. New in v12: * To address Andrew's concern about adding all CMA areas, the CMA heap only adds the default CMA region for now. * Minor cleanups and prep for loading heaps from modules * I have patches to add other specified CMA regions, as well as loading heaps from modules in my WIP tree, which I will submit once this set is queued, here: https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap-WIP thanks -john Cc: Laura Abbott Cc: Benjamin Gaignard Cc: Sumit Semwal Cc: Liam Mark Cc: Pratik Patel Cc: Brian Starkey Cc: Vincent Donnefort Cc: Sudipto Paul Cc: Andrew F. Davis Cc: Christoph Hellwig Cc: Chenbo Feng Cc: Alistair Strachan Cc: Hridya Valsaraju Cc: Hillf Danton Cc: dri-de...@lists.freedesktop.org Andrew F. Davis (1): dma-buf: Add dma-buf heaps framework John Stultz (4): dma-buf: heaps: Add heap helpers dma-buf: heaps: Add system heap to dmabuf heaps dma-buf: heaps: Add CMA heap to dmabuf heaps kselftests: Add dma-heap test MAINTAINERS | 18 ++ drivers/dma-buf/Kconfig | 11 + drivers/dma-buf/Makefile | 2 + drivers/dma-buf/dma-heap.c| 271 ++ drivers/dma-buf/heaps/Kconfig | 14 + drivers/dma-buf/heaps/Makefile| 4 + drivers/dma-buf/heaps/cma_heap.c | 178 drivers/dma-buf/heaps/heap-helpers.c | 270 + drivers/dma-buf/heaps/heap-helpers.h | 55 drivers/dma-buf/heaps/system_heap.c | 124 include/linux/dma-heap.h | 59 include/uapi/linux/dma-heap.h | 55 tools/testing/selftests/dmabuf-heaps/Makefile | 9 + .../selftests/dmabuf-heaps/dmabuf-heap.c | 238 +++ 14 files changed, 1308 insertions(+) create mode 100644 drivers/dma-buf/dma-heap.c create mode 100644 drivers/dma-buf/heaps/Kconfig create mode 100644 drivers/dma-buf/heaps/Makefile create mode 100644 drivers/dma-buf/heaps/cma_heap.c create mode 100644 drivers/dma-buf/heaps/heap-helpers.c create mode 100644 drivers/dma-buf/heaps/heap-helpers.h create mode 100644 drivers/dma-buf/heaps/system_heap.c create mode 100644 include/linux/dma-heap.h create mode 100644 include/uapi/linux/dma-heap.h create mode 100644 tools/testing/selftests/dmabuf-heaps/Makefile create mode 100644 tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c -- 2.17.1
[PATCH v12 2/5] dma-buf: heaps: Add heap helpers
Add generic helper dmabuf ops for dma heaps, so we can reduce the amount of duplicative code for the exported dmabufs. This code is an evolution of the Android ION implementation, so thanks to its original authors and maintainters: Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others! Cc: Laura Abbott Cc: Benjamin Gaignard Cc: Sumit Semwal Cc: Liam Mark Cc: Pratik Patel Cc: Brian Starkey Cc: Vincent Donnefort Cc: Sudipto Paul Cc: Andrew F. Davis Cc: Christoph Hellwig Cc: Chenbo Feng Cc: Alistair Strachan Cc: Hridya Valsaraju Cc: Hillf Danton Cc: dri-de...@lists.freedesktop.org Reviewed-by: Benjamin Gaignard Reviewed-by: Brian Starkey Acked-by: Laura Abbott Tested-by: Ayan Kumar Halder Signed-off-by: John Stultz --- v2: * Removed cache management performance hack that I had accidentally folded in. * Removed stats code that was in helpers * Lots of checkpatch cleanups v3: * Uninline INIT_HEAP_HELPER_BUFFER (suggested by Christoph) * Switch to WARN on buffer destroy failure (suggested by Brian) * buffer->kmap_cnt decrementing cleanup (suggested by Christoph) * Extra buffer->vaddr checking in dma_heap_dma_buf_kmap (suggested by Brian) * Switch to_helper_buffer from macro to inline function (suggested by Benjamin) * Rename kmap->vmap (folded in from Andrew) * Use vmap for vmapping - not begin_cpu_access (folded in from Andrew) * Drop kmap for now, as its optional (folded in from Andrew) * Fold dma_heap_map_user into the single caller (foled in from Andrew) * Folded in patch from Andrew to track page list per heap not sglist, which simplifies the tracking logic v4: * Moved dma-heap.h change out to previous patch v6: * Minor cleanups and typo fixes suggested by Brian v7: * Removed stray ; * Make init_heap_helper_buffer lowercase, as suggested by Christoph * Add dmabuf export helper to reduce boilerplate code v8: * Remove unused private_flags value * Condense dma_heap_buffer and heap_helper_buffer (suggested by Christoph) * Fix indentation by using shorter argument names (suggested by Christoph) * Add flush_kernel_vmap_range/invalidate_kernel_vmap_range calls (suggested by Christoph) * Checkpatch whitespace fixups v9: * Minor cleanups suggested by Brian Starkey v10: * Fix missing vmalloc.h inclusion in heap helpers (found by kbuild test robot ) v12: * Add symbol exports for heaps as modules --- drivers/dma-buf/Makefile | 1 + drivers/dma-buf/heaps/Makefile | 2 + drivers/dma-buf/heaps/heap-helpers.c | 270 +++ drivers/dma-buf/heaps/heap-helpers.h | 55 ++ 4 files changed, 328 insertions(+) create mode 100644 drivers/dma-buf/heaps/Makefile create mode 100644 drivers/dma-buf/heaps/heap-helpers.c create mode 100644 drivers/dma-buf/heaps/heap-helpers.h diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile index caee5eb3d351..9c190026bfab 100644 --- a/drivers/dma-buf/Makefile +++ b/drivers/dma-buf/Makefile @@ -2,6 +2,7 @@ obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \ dma-resv.o seqno-fence.o obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o +obj-$(CONFIG_DMABUF_HEAPS) += heaps/ obj-$(CONFIG_SYNC_FILE)+= sync_file.o obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o obj-$(CONFIG_UDMABUF) += udmabuf.o diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile new file mode 100644 index ..de49898112db --- /dev/null +++ b/drivers/dma-buf/heaps/Makefile @@ -0,0 +1,2 @@ +# SPDX-License-Identifier: GPL-2.0 +obj-y += heap-helpers.o diff --git a/drivers/dma-buf/heaps/heap-helpers.c b/drivers/dma-buf/heaps/heap-helpers.c new file mode 100644 index ..fb9835126893 --- /dev/null +++ b/drivers/dma-buf/heaps/heap-helpers.c @@ -0,0 +1,270 @@ +// SPDX-License-Identifier: GPL-2.0 +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "heap-helpers.h" + +void init_heap_helper_buffer(struct heap_helper_buffer *buffer, +void (*free)(struct heap_helper_buffer *)) +{ + buffer->priv_virt = NULL; + mutex_init(&buffer->lock); + buffer->vmap_cnt = 0; + buffer->vaddr = NULL; + buffer->pagecount = 0; + buffer->pages = NULL; + INIT_LIST_HEAD(&buffer->attachments); + buffer->free = free; +} +EXPORT_SYMBOL_GPL(init_heap_helper_buffer); + +struct dma_buf *heap_helper_export_dmabuf(struct heap_helper_buffer *buffer, + int fd_flags) +{ + DEFINE_DMA_BUF_EXPORT_INFO(exp_info); + + exp_info.ops = &heap_helper_ops; + exp_info.size = buffer->size; + exp_info.flags = fd_flags; + exp_info.priv = buffer; + + return dma_buf_export(&exp_info); +} +EXPORT_SYMBOL_GPL(heap_helper_export_dmabuf); + +static void *dma_heap_map_kernel(struct heap_helper_buffer *buffer) +{ + void *vaddr; + +
[PATCH 1/4] Bluetooth: hci_qca: Update regulator_set_load() usage
Since the introduction of '5451781dadf8 ("regulator: core: Only count load for enabled consumers")' in v5.0, the requested load of a regulator consumer is only accounted for when said consumer is voted enabled. So there's no need to vote for load ever time the regulator is enabled or disabled. Signed-off-by: Bjorn Andersson --- drivers/bluetooth/hci_qca.c | 33 ++--- 1 file changed, 18 insertions(+), 15 deletions(-) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index e3164c200eac..c07c529b0d81 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -1393,13 +1393,6 @@ static int qca_enable_regulator(struct qca_vreg vregs, if (ret) return ret; - if (vregs.load_uA) - ret = regulator_set_load(regulator, -vregs.load_uA); - - if (ret) - return ret; - return regulator_enable(regulator); } @@ -1409,8 +1402,6 @@ static void qca_disable_regulator(struct qca_vreg vregs, { regulator_disable(regulator); regulator_set_voltage(regulator, 0, vregs.max_uV); - if (vregs.load_uA) - regulator_set_load(regulator, 0); } @@ -1462,18 +1453,30 @@ static int qca_power_setup(struct hci_uart *hu, bool on) static int qca_init_regulators(struct qca_power *qca, const struct qca_vreg *vregs, size_t num_vregs) { + struct regulator_bulk_data *bulk; + int ret; int i; - qca->vreg_bulk = devm_kcalloc(qca->dev, num_vregs, - sizeof(struct regulator_bulk_data), - GFP_KERNEL); - if (!qca->vreg_bulk) + bulk = devm_kcalloc(qca->dev, num_vregs, sizeof(*bulk), GFP_KERNEL); + if (!bulk) return -ENOMEM; for (i = 0; i < num_vregs; i++) - qca->vreg_bulk[i].supply = vregs[i].name; + bulk[i].supply = vregs[i].name; + + ret = devm_regulator_bulk_get(qca->dev, num_vregs, bulk); + if (ret < 0) + return ret; - return devm_regulator_bulk_get(qca->dev, num_vregs, qca->vreg_bulk); + for (i = 0; i < num_vregs; i++) { + ret = regulator_set_load(bulk[i].consumer, vregs[i].load_uA); + if (ret) + return ret; + } + + qca->vreg_bulk = bulk; + + return 0; } static int qca_serdev_probe(struct serdev_device *serdev) -- 2.23.0
[PATCH 4/4] Bluetooth: hci_qca: Split qca_power_setup()
Split and rename qca_power_setup() in order to simplify each code path and to clarify that it is unrelated to qca_power_off() and qca_power_setup(). Signed-off-by: Bjorn Andersson --- drivers/bluetooth/hci_qca.c | 61 ++--- 1 file changed, 36 insertions(+), 25 deletions(-) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index 01f941e9adf3..c591a8ba9d93 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -160,7 +160,8 @@ struct qca_serdev { const char *firmware_name; }; -static int qca_power_setup(struct hci_uart *hu, bool on); +static int qca_regulator_enable(struct qca_serdev *qcadev); +static void qca_regulator_disable(struct qca_serdev *qcadev); static void qca_power_shutdown(struct hci_uart *hu); static int qca_power_off(struct hci_dev *hdev); @@ -516,7 +517,7 @@ static int qca_open(struct hci_uart *hu) } else { hu->init_speed = qcadev->init_speed; hu->oper_speed = qcadev->oper_speed; - ret = qca_power_setup(hu, true); + ret = qca_regulator_enable(qcadev); if (ret) { destroy_workqueue(qca->workqueue); kfree_skb(qca->rx_skb); @@ -1186,7 +1187,7 @@ static int qca_wcn3990_init(struct hci_uart *hu) qcadev = serdev_device_get_drvdata(hu->serdev); if (!qcadev->bt_power->vregs_on) { serdev_device_close(hu->serdev); - ret = qca_power_setup(hu, true); + ret = qca_regulator_enable(qcadev); if (ret) return ret; @@ -1351,9 +1352,12 @@ static const struct qca_vreg_data qca_soc_data_wcn3998 = { static void qca_power_shutdown(struct hci_uart *hu) { + struct qca_serdev *qcadev; struct qca_data *qca = hu->priv; unsigned long flags; + qcadev = serdev_device_get_drvdata(hu->serdev); + /* From this point we go into power off state. But serial port is * still open, stop queueing the IBS data and flush all the buffered * data in skb's. @@ -1365,7 +1369,7 @@ static void qca_power_shutdown(struct hci_uart *hu) host_set_baudrate(hu, 2400); qca_send_power_pulse(hu, false); - qca_power_setup(hu, false); + qca_regulator_disable(qcadev); } static int qca_power_off(struct hci_dev *hdev) @@ -1381,36 +1385,43 @@ static int qca_power_off(struct hci_dev *hdev) return 0; } -static int qca_power_setup(struct hci_uart *hu, bool on) +static int qca_regulator_enable(struct qca_serdev *qcadev) { - struct regulator_bulk_data *vreg_bulk; - struct qca_serdev *qcadev; - int num_vregs; - int ret = 0; + struct qca_power *power = qcadev->bt_power; + int ret; - qcadev = serdev_device_get_drvdata(hu->serdev); - if (!qcadev || !qcadev->bt_power || !qcadev->bt_power->vreg_bulk) - return -EINVAL; + /* Already enabled */ + if (power->vregs_on) + return 0; - vreg_bulk = qcadev->bt_power->vreg_bulk; - num_vregs = qcadev->bt_power->num_vregs; - BT_DBG("on: %d (%d regulators)", on, num_vregs); - if (on && !qcadev->bt_power->vregs_on) { - ret = regulator_bulk_enable(num_vregs, vreg_bulk); - if (ret) - return ret; + BT_DBG("enabling %d regulators)", power->num_vregs); - qcadev->bt_power->vregs_on = true; - } else if (!on && qcadev->bt_power->vregs_on) { - /* turn off regulator in reverse order */ - regulator_bulk_disable(num_vregs, vreg_bulk); + ret = regulator_bulk_enable(power->num_vregs, power->vreg_bulk); + if (ret) + return ret; - qcadev->bt_power->vregs_on = false; - } + power->vregs_on = true; return 0; } +static void qca_regulator_disable(struct qca_serdev *qcadev) +{ + struct qca_power *power; + + if (!qcadev) + return; + + power = qcadev->bt_power; + + /* Already disabled? */ + if (!power->vregs_on) + return; + + regulator_bulk_disable(power->num_vregs, power->vreg_bulk); + power->vregs_on = false; +} + static int qca_init_regulators(struct qca_power *qca, const struct qca_vreg *vregs, size_t num_vregs) { -- 2.23.0
[PATCH v12 4/5] dma-buf: heaps: Add CMA heap to dmabuf heaps
This adds a CMA heap, which allows userspace to allocate a dma-buf of contiguous memory out of a CMA region. This code is an evolution of the Android ION implementation, so thanks to its original author and maintainters: Benjamin Gaignard, Laura Abbott, and others! NOTE: This patch only adds the default CMA heap. We will enable selectively adding other CMA memory regions to the dmabuf heaps interface with a later patch (which requires a dt binding) Cc: Laura Abbott Cc: Benjamin Gaignard Cc: Sumit Semwal Cc: Liam Mark Cc: Pratik Patel Cc: Brian Starkey Cc: Vincent Donnefort Cc: Sudipto Paul Cc: Andrew F. Davis Cc: Christoph Hellwig Cc: Chenbo Feng Cc: Alistair Strachan Cc: Hridya Valsaraju Cc: Hillf Danton Cc: dri-de...@lists.freedesktop.org Reviewed-by: Benjamin Gaignard Reviewed-by: Brian Starkey Acked-by: Laura Abbott Tested-by: Ayan Kumar Halder Signed-off-by: John Stultz --- v2: * Switch allocate to return dmabuf fd * Simplify init code * Checkpatch fixups v3: * Switch to inline function for to_cma_heap() * Minor cleanups suggested by Brian * Fold in new registration style from Andrew * Folded in changes from Andrew to use simplified page list from the heap helpers v4: * Use the fd_flags when creating dmabuf fd (Suggested by Benjamin) * Use precalculated pagecount (Suggested by Andrew) v6: * Changed variable names to improve clarity, as suggested by Brian v7: * Use newly lower-cased init_heap_helper_buffer helper * Use new dmabuf export helper v8: * Make struct dma_heap_ops const (Suggested by Christoph) * Condense dma_heap_buffer and heap_helper_buffer (suggested by Christoph) * Checkpatch whitespace fixups v9: * Removing needless check noted by Brian Starkey * Rename dma_heap_get_data->dma_heap_get_drvdata suggested by Hilf Danton * Check signals after clearing memory pages to avoid doing needless work if the task is killed as suggested by Hilf v12: * Rework to only add the default CMA heap --- drivers/dma-buf/heaps/Kconfig| 8 ++ drivers/dma-buf/heaps/Makefile | 1 + drivers/dma-buf/heaps/cma_heap.c | 178 +++ 3 files changed, 187 insertions(+) create mode 100644 drivers/dma-buf/heaps/cma_heap.c diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig index 205052744169..a5eef06c4226 100644 --- a/drivers/dma-buf/heaps/Kconfig +++ b/drivers/dma-buf/heaps/Kconfig @@ -4,3 +4,11 @@ config DMABUF_HEAPS_SYSTEM help Choose this option to enable the system dmabuf heap. The system heap is backed by pages from the buddy allocator. If in doubt, say Y. + +config DMABUF_HEAPS_CMA + bool "DMA-BUF CMA Heap" + depends on DMABUF_HEAPS && DMA_CMA + help + Choose this option to enable dma-buf CMA heap. This heap is backed + by the Contiguous Memory Allocator (CMA). If your system has these + regions, you should say Y here. diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile index d1808eca2581..6e54cdec3da0 100644 --- a/drivers/dma-buf/heaps/Makefile +++ b/drivers/dma-buf/heaps/Makefile @@ -1,3 +1,4 @@ # SPDX-License-Identifier: GPL-2.0 obj-y += heap-helpers.o obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o +obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c new file mode 100644 index ..064926b5d735 --- /dev/null +++ b/drivers/dma-buf/heaps/cma_heap.c @@ -0,0 +1,178 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * DMABUF CMA heap exporter + * + * Copyright (C) 2012, 2019 Linaro Ltd. + * Author: for ST-Ericsson. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "heap-helpers.h" + +struct cma_heap { + struct dma_heap *heap; + struct cma *cma; +}; + +static void cma_heap_free(struct heap_helper_buffer *buffer) +{ + struct cma_heap *cma_heap = dma_heap_get_drvdata(buffer->heap); + unsigned long nr_pages = buffer->pagecount; + struct page *cma_pages = buffer->priv_virt; + + /* free page list */ + kfree(buffer->pages); + /* release memory */ + cma_release(cma_heap->cma, cma_pages, nr_pages); + kfree(buffer); +} + +/* dmabuf heap CMA operations functions */ +static int cma_heap_allocate(struct dma_heap *heap, +unsigned long len, +unsigned long fd_flags, +unsigned long heap_flags) +{ + struct cma_heap *cma_heap = dma_heap_get_drvdata(heap); + struct heap_helper_buffer *helper_buffer; + struct page *cma_pages; + size_t size = PAGE_ALIGN(len); + unsigned long nr_pages = size >> PAGE_SHIFT; + unsigned long align = get_order(size); + struct dma_buf *dmabuf; + int ret = -ENOMEM; + pgoff_t pg; + + if (align > C
[PATCH 0/4] Bluetooth: hci_qca: Regulator usage cleanup
Clean up the regulator usage in hci_qca and in particular don't regulator_set_voltage() for fixed voltages. It cleans up the driver, but more important it makes bluetooth work on my Lenovo Yoga C630, where the regulator for vddch0 is defined with a voltage range that doesn't overlap the values in the driver. Bjorn Andersson (4): Bluetooth: hci_qca: Update regulator_set_load() usage Bluetooth: hci_qca: Don't vote for specific voltage Bluetooth: hci_qca: Use regulator bulk enable/disable Bluetooth: hci_qca: Split qca_power_setup() drivers/bluetooth/hci_qca.c | 135 +++- 1 file changed, 55 insertions(+), 80 deletions(-) -- 2.23.0
[PATCH 3/4] Bluetooth: hci_qca: Use regulator bulk enable/disable
With the regulator_set_load() and regulator_set_voltage() out of the enable/disable code paths the code can now use the standard regulator bulk enable/disable API. By cloning num_vregs into struct qca_power there's no need to lug around a reference to the struct qca_vreg_data, which further simplifies qca_power_setup(). Signed-off-by: Bjorn Andersson --- drivers/bluetooth/hci_qca.c | 55 + 1 file changed, 13 insertions(+), 42 deletions(-) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index 54aafcc69d06..01f941e9adf3 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -144,8 +144,8 @@ struct qca_vreg_data { */ struct qca_power { struct device *dev; - const struct qca_vreg_data *vreg_data; struct regulator_bulk_data *vreg_bulk; + int num_vregs; bool vregs_on; }; @@ -1381,63 +1381,34 @@ static int qca_power_off(struct hci_dev *hdev) return 0; } -static int qca_enable_regulator(struct qca_vreg vregs, - struct regulator *regulator) -{ - return regulator_enable(regulator); - -} - -static void qca_disable_regulator(struct qca_vreg vregs, - struct regulator *regulator) -{ - regulator_disable(regulator); - -} - static int qca_power_setup(struct hci_uart *hu, bool on) { - struct qca_vreg *vregs; struct regulator_bulk_data *vreg_bulk; struct qca_serdev *qcadev; - int i, num_vregs, ret = 0; + int num_vregs; + int ret = 0; qcadev = serdev_device_get_drvdata(hu->serdev); - if (!qcadev || !qcadev->bt_power || !qcadev->bt_power->vreg_data || - !qcadev->bt_power->vreg_bulk) + if (!qcadev || !qcadev->bt_power || !qcadev->bt_power->vreg_bulk) return -EINVAL; - vregs = qcadev->bt_power->vreg_data->vregs; vreg_bulk = qcadev->bt_power->vreg_bulk; - num_vregs = qcadev->bt_power->vreg_data->num_vregs; - BT_DBG("on: %d", on); + num_vregs = qcadev->bt_power->num_vregs; + BT_DBG("on: %d (%d regulators)", on, num_vregs); if (on && !qcadev->bt_power->vregs_on) { - for (i = 0; i < num_vregs; i++) { - ret = qca_enable_regulator(vregs[i], - vreg_bulk[i].consumer); - if (ret) - break; - } + ret = regulator_bulk_enable(num_vregs, vreg_bulk); + if (ret) + return ret; - if (ret) { - BT_ERR("failed to enable regulator:%s", vregs[i].name); - /* turn off regulators which are enabled */ - for (i = i - 1; i >= 0; i--) - qca_disable_regulator(vregs[i], - vreg_bulk[i].consumer); - } else { - qcadev->bt_power->vregs_on = true; - } + qcadev->bt_power->vregs_on = true; } else if (!on && qcadev->bt_power->vregs_on) { /* turn off regulator in reverse order */ - i = qcadev->bt_power->vreg_data->num_vregs - 1; - for ( ; i >= 0; i--) - qca_disable_regulator(vregs[i], vreg_bulk[i].consumer); + regulator_bulk_disable(num_vregs, vreg_bulk); qcadev->bt_power->vregs_on = false; } - return ret; + return 0; } static int qca_init_regulators(struct qca_power *qca, @@ -1465,6 +1436,7 @@ static int qca_init_regulators(struct qca_power *qca, } qca->vreg_bulk = bulk; + qca->num_vregs = num_vregs; return 0; } @@ -1493,7 +1465,6 @@ static int qca_serdev_probe(struct serdev_device *serdev) return -ENOMEM; qcadev->bt_power->dev = &serdev->dev; - qcadev->bt_power->vreg_data = data; err = qca_init_regulators(qcadev->bt_power, data->vregs, data->num_vregs); if (err) { -- 2.23.0
[PATCH v12 3/5] dma-buf: heaps: Add system heap to dmabuf heaps
This patch adds system heap to the dma-buf heaps framework. This allows applications to get a page-allocator backed dma-buf for non-contiguous memory. This code is an evolution of the Android ION implementation, so thanks to its original authors and maintainters: Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others! Cc: Laura Abbott Cc: Benjamin Gaignard Cc: Sumit Semwal Cc: Liam Mark Cc: Pratik Patel Cc: Brian Starkey Cc: Vincent Donnefort Cc: Sudipto Paul Cc: Andrew F. Davis Cc: Christoph Hellwig Cc: Chenbo Feng Cc: Alistair Strachan Cc: Hridya Valsaraju Cc: Hillf Danton Cc: dri-de...@lists.freedesktop.org Reviewed-by: Benjamin Gaignard Reviewed-by: Brian Starkey Acked-by: Laura Abbott Tested-by: Ayan Kumar Halder Signed-off-by: John Stultz --- v2: * Switch allocate to return dmabuf fd * Simplify init code * Checkpatch fixups * Droped dead system-contig code v3: * Whitespace fixups from Benjamin * Make sure we're zeroing the allocated pages (from Liam) * Use PAGE_ALIGN() consistently (suggested by Brian) * Fold in new registration style from Andrew * Avoid needless dynamic allocation of sys_heap (suggested by Christoph) * Minor cleanups * Folded in changes from Andrew to use simplified page list from the heap helpers v4: * Optimization to allocate pages in chunks, similar to old pagepool code * Use fd_flags when creating dmabuf fd (Suggested by Benjamin) v5: * Back out large order page allocations (was leaking memory, as the page array didn't properly track order size) v6: * Minor whitespace change suggested by Brian * Remove unused variable v7: * Use newly lower-cased init_heap_helper_buffer helper * Add system heap DOS avoidance suggested by Laura from ION code * Use new dmabuf export helper v8: * Make struct dma_heap_ops consts (suggested by Christoph) * Get rid of needless struct system_heap (suggested by Christoph) * Condense dma_heap_buffer and heap_helper_buffer (suggested by Christoph) * Add forgotten include file to fix build issue on x86 v12: * Minor tweaks to prep loading heap from module --- drivers/dma-buf/Kconfig | 2 + drivers/dma-buf/heaps/Kconfig | 6 ++ drivers/dma-buf/heaps/Makefile | 1 + drivers/dma-buf/heaps/system_heap.c | 124 4 files changed, 133 insertions(+) create mode 100644 drivers/dma-buf/heaps/Kconfig create mode 100644 drivers/dma-buf/heaps/system_heap.c diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig index bffa58fc3e6e..0613bb7770f5 100644 --- a/drivers/dma-buf/Kconfig +++ b/drivers/dma-buf/Kconfig @@ -53,4 +53,6 @@ menuconfig DMABUF_HEAPS allows userspace to allocate dma-bufs that can be shared between drivers. +source "drivers/dma-buf/heaps/Kconfig" + endmenu diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig new file mode 100644 index ..205052744169 --- /dev/null +++ b/drivers/dma-buf/heaps/Kconfig @@ -0,0 +1,6 @@ +config DMABUF_HEAPS_SYSTEM + bool "DMA-BUF System Heap" + depends on DMABUF_HEAPS + help + Choose this option to enable the system dmabuf heap. The system heap + is backed by pages from the buddy allocator. If in doubt, say Y. diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile index de49898112db..d1808eca2581 100644 --- a/drivers/dma-buf/heaps/Makefile +++ b/drivers/dma-buf/heaps/Makefile @@ -1,2 +1,3 @@ # SPDX-License-Identifier: GPL-2.0 obj-y += heap-helpers.o +obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c new file mode 100644 index ..455782efbb32 --- /dev/null +++ b/drivers/dma-buf/heaps/system_heap.c @@ -0,0 +1,124 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * DMABUF System heap exporter + * + * Copyright (C) 2011 Google, Inc. + * Copyright (C) 2019 Linaro Ltd. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "heap-helpers.h" + +struct dma_heap *sys_heap; + +static void system_heap_free(struct heap_helper_buffer *buffer) +{ + pgoff_t pg; + + for (pg = 0; pg < buffer->pagecount; pg++) + __free_page(buffer->pages[pg]); + kfree(buffer->pages); + kfree(buffer); +} + +static int system_heap_allocate(struct dma_heap *heap, + unsigned long len, + unsigned long fd_flags, + unsigned long heap_flags) +{ + struct heap_helper_buffer *helper_buffer; + struct dma_buf *dmabuf; + int ret = -ENOMEM; + pgoff_t pg; + + helper_buffer = kzalloc(sizeof(*helper_buffer), GFP_KERNEL); + if (!helper_buffer) + return -ENOMEM; + + init_heap_helper_buffer(helper_buffer, system_heap_free); + helper_buffer->flags = heap_flags; +
[PATCH v12 5/5] kselftests: Add dma-heap test
Add very trivial allocation and import test for dma-heaps, utilizing the vgem driver as a test importer. A good chunk of this code taken from: tools/testing/selftests/android/ion/ionmap_test.c Originally by Laura Abbott Cc: Benjamin Gaignard Cc: Sumit Semwal Cc: Liam Mark Cc: Pratik Patel Cc: Brian Starkey Cc: Vincent Donnefort Cc: Sudipto Paul Cc: Andrew F. Davis Cc: Christoph Hellwig Cc: Chenbo Feng Cc: Alistair Strachan Cc: Hridya Valsaraju Cc: Hillf Danton Cc: dri-de...@lists.freedesktop.org Reviewed-by: Benjamin Gaignard Reviewed-by: Brian Starkey Acked-by: Laura Abbott Tested-by: Ayan Kumar Halder Signed-off-by: John Stultz --- v2: * Switched to use reworked dma-heap apis v3: * Add simple mmap * Utilize dma-buf testdev to test importing v4: * Rework to use vgem * Pass in fd_flags to match interface changes * Skip . and .. dirs v6: * Number of style/cleanups suggested by Brian v7: * Whitespace fixup for checkpatch v8: * More checkpatch whitespace fixups v9: * Better handling error returns out to main, suggested by Brian Starkey * Switch to using snprintf, suggested by Brian --- tools/testing/selftests/dmabuf-heaps/Makefile | 9 + .../selftests/dmabuf-heaps/dmabuf-heap.c | 238 ++ 2 files changed, 247 insertions(+) create mode 100644 tools/testing/selftests/dmabuf-heaps/Makefile create mode 100644 tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c diff --git a/tools/testing/selftests/dmabuf-heaps/Makefile b/tools/testing/selftests/dmabuf-heaps/Makefile new file mode 100644 index ..8c4c36e2972d --- /dev/null +++ b/tools/testing/selftests/dmabuf-heaps/Makefile @@ -0,0 +1,9 @@ +# SPDX-License-Identifier: GPL-2.0 +CFLAGS += -static -O3 -Wl,-no-as-needed -Wall +#LDLIBS += -lrt -lpthread -lm + +# these are all "safe" tests that don't modify +# system time or require escalated privileges +TEST_GEN_PROGS = dmabuf-heap + +include ../lib.mk diff --git a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c new file mode 100644 index ..b36dd9f35c19 --- /dev/null +++ b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c @@ -0,0 +1,238 @@ +// SPDX-License-Identifier: GPL-2.0 + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#include "../../../../include/uapi/linux/dma-heap.h" + +#define DEVPATH "/dev/dma_heap" + +static int check_vgem(int fd) +{ + drm_version_t version = { 0 }; + char name[5]; + int ret; + + version.name_len = 4; + version.name = name; + + ret = ioctl(fd, DRM_IOCTL_VERSION, &version); + if (ret) + return 0; + + return !strcmp(name, "vgem"); +} + +static int open_vgem(void) +{ + int i, fd; + const char *drmstr = "/dev/dri/card"; + + fd = -1; + for (i = 0; i < 16; i++) { + char name[80]; + + snprintf(name, 80, "%s%u", drmstr, i); + + fd = open(name, O_RDWR); + if (fd < 0) + continue; + + if (!check_vgem(fd)) { + close(fd); + fd = -1; + continue; + } else { + break; + } + } + return fd; +} + +static int import_vgem_fd(int vgem_fd, int dma_buf_fd, uint32_t *handle) +{ + struct drm_prime_handle import_handle = { + .fd = dma_buf_fd, + .flags = 0, + .handle = 0, +}; + int ret; + + ret = ioctl(vgem_fd, DRM_IOCTL_PRIME_FD_TO_HANDLE, &import_handle); + if (ret == 0) + *handle = import_handle.handle; + return ret; +} + +static void close_handle(int vgem_fd, uint32_t handle) +{ + struct drm_gem_close close = { + .handle = handle, + }; + + ioctl(vgem_fd, DRM_IOCTL_GEM_CLOSE, &close); +} + +static int dmabuf_heap_open(char *name) +{ + int ret, fd; + char buf[256]; + + ret = snprintf(buf, 256, "%s/%s", DEVPATH, name); + if (ret < 0) { + printf("snprintf failed!\n"); + return ret; + } + + fd = open(buf, O_RDWR); + if (fd < 0) + printf("open %s failed!\n", buf); + return fd; +} + +static int dmabuf_heap_alloc(int fd, size_t len, unsigned int flags, +int *dmabuf_fd) +{ + struct dma_heap_allocation_data data = { + .len = len, + .fd_flags = O_RDWR | O_CLOEXEC, + .heap_flags = flags, + }; + int ret; + + if (!dmabuf_fd) + return -EINVAL; + + ret = ioctl(fd, DMA_HEAP_IOC_ALLOC, &data); + if (ret < 0) + return ret; + *dmabuf_fd = (int)data.fd; + return ret; +} + +static void dmabuf_sync(int fd, int start_stop) +{ + struct dma_buf_sync s
[PATCH 2/4] Bluetooth: hci_qca: Don't vote for specific voltage
Devices with specific voltage requirements should not request voltage from the driver, but instead rely on the system configuration to define appropriate voltages for each rail. This ensures that PMIC and board variations are accounted for, something that the 0.1V range in the hci_qca driver currently tries to address. But on the Lenovo Yoga C630 (with wcn3990) vddch0 is 3.1V, which means the driver will fail to set the voltage. Signed-off-by: Bjorn Andersson --- drivers/bluetooth/hci_qca.c | 26 -- 1 file changed, 8 insertions(+), 18 deletions(-) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index c07c529b0d81..54aafcc69d06 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -130,8 +130,6 @@ enum qca_speed_type { */ struct qca_vreg { const char *name; - unsigned int min_uV; - unsigned int max_uV; unsigned int load_uA; }; @@ -1332,10 +1330,10 @@ static const struct hci_uart_proto qca_proto = { static const struct qca_vreg_data qca_soc_data_wcn3990 = { .soc_type = QCA_WCN3990, .vregs = (struct qca_vreg []) { - { "vddio", 180, 190, 15000 }, - { "vddxo", 180, 190, 8 }, - { "vddrf", 130, 135, 30 }, - { "vddch0", 330, 340, 45 }, + { "vddio", 15000 }, + { "vddxo", 8 }, + { "vddrf", 30 }, + { "vddch0", 45 }, }, .num_vregs = 4, }; @@ -1343,10 +1341,10 @@ static const struct qca_vreg_data qca_soc_data_wcn3990 = { static const struct qca_vreg_data qca_soc_data_wcn3998 = { .soc_type = QCA_WCN3998, .vregs = (struct qca_vreg []) { - { "vddio", 180, 190, 1 }, - { "vddxo", 180, 190, 8 }, - { "vddrf", 130, 1352000, 30 }, - { "vddch0", 330, 330, 45 }, + { "vddio", 1 }, + { "vddxo", 8 }, + { "vddrf", 30 }, + { "vddch0", 45 }, }, .num_vregs = 4, }; @@ -1386,13 +1384,6 @@ static int qca_power_off(struct hci_dev *hdev) static int qca_enable_regulator(struct qca_vreg vregs, struct regulator *regulator) { - int ret; - - ret = regulator_set_voltage(regulator, vregs.min_uV, - vregs.max_uV); - if (ret) - return ret; - return regulator_enable(regulator); } @@ -1401,7 +1392,6 @@ static void qca_disable_regulator(struct qca_vreg vregs, struct regulator *regulator) { regulator_disable(regulator); - regulator_set_voltage(regulator, 0, vregs.max_uV); } -- 2.23.0
Re: [PATCH 01/15] riscv: cleanup
On Thu, Oct 17, 2019 at 11:07 PM Christoph Hellwig wrote: > > Remove various not required ifdefs and externs. > > Signed-off-by: Christoph Hellwig > --- > arch/riscv/include/asm/bug.h | 16 +++- > 1 file changed, 3 insertions(+), 13 deletions(-) > > diff --git a/arch/riscv/include/asm/bug.h b/arch/riscv/include/asm/bug.h > index 07ceee8b1747..75604fec1b1b 100644 > --- a/arch/riscv/include/asm/bug.h > +++ b/arch/riscv/include/asm/bug.h > @@ -12,7 +12,6 @@ > > #include > > -#ifdef CONFIG_GENERIC_BUG > #define __INSN_LENGTH_MASK _UL(0x3) > #define __INSN_LENGTH_32_UL(0x3) > #define __COMPRESSED_INSN_MASK _UL(0x) > @@ -20,7 +19,6 @@ > #define __BUG_INSN_32 _UL(0x00100073) /* ebreak */ > #define __BUG_INSN_16 _UL(0x9002) /* c.ebreak */ > > -#ifndef __ASSEMBLY__ > typedef u32 bug_insn_t; > > #ifdef CONFIG_GENERIC_BUG_RELATIVE_POINTERS > @@ -43,6 +41,7 @@ typedef u32 bug_insn_t; > RISCV_SHORT " %2" > #endif > > +#ifdef CONFIG_GENERIC_BUG > #define __BUG_FLAGS(flags) \ > do { \ > __asm__ __volatile__ ( \ > @@ -58,14 +57,10 @@ do { > \ > "i" (flags), \ > "i" (sizeof(struct bug_entry))); \ > } while (0) > - > -#endif /* !__ASSEMBLY__ */ > #else /* CONFIG_GENERIC_BUG */ > -#ifndef __ASSEMBLY__ > #define __BUG_FLAGS(flags) do {\ > __asm__ __volatile__ ("ebreak\n"); \ > } while (0) > -#endif /* !__ASSEMBLY__ */ > #endif /* CONFIG_GENERIC_BUG */ > > #define BUG() do { \ > @@ -79,15 +74,10 @@ do { > \ > > #include > > -#ifndef __ASSEMBLY__ > - > struct pt_regs; > struct task_struct; > > -extern void die(struct pt_regs *regs, const char *str); > -extern void do_trap(struct pt_regs *regs, int signo, int code, > - unsigned long addr); > - > -#endif /* !__ASSEMBLY__ */ > +void die(struct pt_regs *regs, const char *str); > +void do_trap(struct pt_regs *regs, int signo, int code, unsigned long addr); > > #endif /* _ASM_RISCV_BUG_H */ > -- > 2.20.1 > > > ___ > linux-riscv mailing list > linux-ri...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv LGTM. Reviewed-by: Anup Patel Regards, Anup
Re: [PATCH 05/15] riscv: poison SBI calls for M-mode
On Thu, Oct 17, 2019 at 11:08 PM Christoph Hellwig wrote: > > There is no SBI when we run in M-mode, so fail the compile for any code > trying to use SBI calls. > > Signed-off-by: Christoph Hellwig > --- > arch/riscv/include/asm/sbi.h | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h > index 21134b3ef404..b167af3e7470 100644 > --- a/arch/riscv/include/asm/sbi.h > +++ b/arch/riscv/include/asm/sbi.h > @@ -8,6 +8,7 @@ > > #include > > +#ifdef CONFIG_RISCV_SBI > #define SBI_SET_TIMER 0 > #define SBI_CONSOLE_PUTCHAR 1 > #define SBI_CONSOLE_GETCHAR 2 > @@ -93,5 +94,5 @@ static inline void sbi_remote_sfence_vma_asid(const > unsigned long *hart_mask, > { > SBI_CALL_4(SBI_REMOTE_SFENCE_VMA_ASID, hart_mask, start, size, asid); > } > - > -#endif > +#endif /* CONFIG_RISCV_SBI */ > +#endif /* _ASM_RISCV_SBI_H */ > -- > 2.20.1 > > > ___ > linux-riscv mailing list > linux-ri...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv LGTM. Reviewed-by: Anup Patel Regards, Anup
Re: RISC-V nommu support v5
On Fri, 18 Oct 2019, Anup Patel wrote: > It will be really cool to have this series for Linux-5.4-rcX. It's way too big to go in via the -rc series. I'm hoping to have it ready to go for v5.5-rc1. - Paul
Re: [PATCH 5/8] riscv: add missing prototypes
On Thu, Oct 17, 2019 at 05:49:26PM -0700, Paul Walmsley wrote: > sparse identifies these missing prototypes when building arch/riscv: > > arch/riscv/kernel/cpu.c:149:29: warning: symbol 'cpuinfo_op' was not > declared. Should it be static? > arch/riscv/kernel/irq.c:27:29: warning: symbol 'do_IRQ' was not declared. > Should it be static? > arch/riscv/kernel/irq.c:57:13: warning: symbol 'init_IRQ' was not declared. > Should it be static? > arch/riscv/kernel/syscall_table.c:15:6: warning: symbol 'sys_call_table' was > not declared. Should it be static? > arch/riscv/kernel/time.c:15:13: warning: symbol 'time_init' was not declared. > Should it be static? > arch/riscv/kernel/smpboot.c:135:24: warning: symbol 'smp_callin' was not > declared. Should it be static? > arch/riscv/kernel/smp.c:72:5: warning: symbol 'setup_profiling_timer' was not > declared. Should it be static? > arch/riscv/mm/init.c:151:7: warning: symbol 'trampoline_pg_dir' was not > declared. Should it be static? > arch/riscv/mm/init.c:157:7: warning: symbol 'early_pg_dir' was not declared. > Should it be static? > arch/riscv/kernel/process.c:32:6: warning: symbol 'show_regs' was not > declared. Should it be static? > arch/riscv/kernel/ptrace.c:151:6: warning: symbol 'do_syscall_trace_enter' > was not declared. Should it be static? > arch/riscv/kernel/ptrace.c:165:6: warning: symbol 'do_syscall_trace_exit' was > not declared. Should it be static? > > Fix by adding the missing prototypes to the appropriate header files. For functions defined in C but used ony in assembly, you can also simply mark them as '__visible' (aka __attribute__((exrernally_visible)) ). Best regards, -- Luc
[PATCH v3 0/3] Logitech G920 fixes
Everyone: This series contains patches to fix a couple of regressions in G920 wheel support by hid-logitech-hidpp driver. Without the patches the wheel remains stuck in autocentering mode ("resisting" any attempt to trun) as well as missing support for any FF action. Thanks, Andrey Smirnov Changes since [v2]: - Fixes a buggy validity check "HID: logitech-hidpp: rework device validation" as pointed out by Benjamin Tissoires - Marked "HID: logitech-hidpp: do all FF cleanup in hidpp_ff_destroy()" as 5.2+ for stable Changes since [v1]: - "HID: logitech-hidpp: split g920_get_config()" is changed to not rely on devres and be a self contained patch - Quirk driven behaviour of "HID: logitech-hidpp: add G920 device validation quirk" is replaced with generic validation algorithm of "HID: logitech-hidpp: rework device validation" - Fix for a poteintial race condition is added in "HID: logitech-hidpp: do all FF cleanup in hidpp_ff_destroy()" as per suggestion by Benjamin Tissoires - Collected Tested-by from Sam Bazely for "HID: logitech-hidpp: split g920_get_config()" since that patch didn't change significantly since [v1] - Specified stable kernel versions I think the patches should apply to (hopefully I got that right) [v2] lore.kernel.org/lkml/20191016182935.5616-1-andrew.smir...@gmail.com [v1] lore.kernel.org/lkml/20191007051240.4410-1-andrew.smir...@gmail.com Andrey Smirnov (3): HID: logitech-hidpp: split g920_get_config() HID: logitech-hidpp: rework device validation HID: logitech-hidpp: do all FF cleanup in hidpp_ff_destroy() drivers/hid/hid-logitech-hidpp.c | 237 +-- 1 file changed, 131 insertions(+), 106 deletions(-) -- 2.21.0
Re: [PATCH v2 31/33] tools lib bpf: Renaming pr_warning to pr_warn
On Fri, Oct 18, 2019 at 11:18:48AM +0800, Kefeng Wang wrote: > For kernel logging macro, pr_warning is completely removed and > replaced by pr_warn, using pr_warn in tools lib bpf for symmetry > to kernel logging macro, then we could drop pr_warning in the > whole linux code. > > Cc: Alexei Starovoitov > Cc: Daniel Borkmann > Cc: Martin KaFai Lau > Cc: Song Liu > Cc: Yonghong Song > Cc: b...@vger.kernel.org > Acked-by: Andrii Nakryiko > Reviewed-by: Sergey Senozhatsky > Signed-off-by: Kefeng Wang > --- > tools/lib/bpf/btf.c | 56 +-- > tools/lib/bpf/btf_dump.c| 18 +- > tools/lib/bpf/libbpf.c | 679 > tools/lib/bpf/libbpf_internal.h | 8 +- > tools/lib/bpf/xsk.c | 4 +- > 5 files changed, 379 insertions(+), 386 deletions(-) Nack. I prefer this type of renaming to go via bpf tree. It's not a kernel patch. It's touching user space library which is under heavy development. Doing any other way will cause a ton of conflicts.
Re: linux-next: build warning after merge of the block tree
Hi Jens, On Thu, 17 Oct 2019 18:56:39 -0600 Jens Axboe wrote: > > I'll fix these warnings up, guessing it's 32-bit? Thanks. Yeah 32 bit. -- Cheers, Stephen Rothwell pgpAAZTHyaXeP.pgp Description: OpenPGP digital signature
[PATCH v3 2/3] HID: logitech-hidpp: rework device validation
G920 device only advertises REPORT_ID_HIDPP_LONG and REPORT_ID_HIDPP_VERY_LONG in its HID report descriptor, so querying for REPORT_ID_HIDPP_SHORT with optional=false will always fail and prevent G920 to be recognized as a valid HID++ device. To fix this and improve some other aspects, modify hidpp_validate_device() as follows: - Inline the code of hidpp_validate_report() to simplify distingushing between non-present and invalid report descriptors - Drop the check for id >= HID_MAX_IDS || id < 0 since all of our IDs are static and known to satisfy that at compile time - Change the algorithms to check all possible report types (including very long report) and deem the device as a valid HID++ device if it supports at least one - Treat invalid report length as a hard stop for the validation algorithm, meaning that if any of the supported reports has invalid length we assume the worst and treat the device as a generic HID device. - Fold initialization of hidpp->very_long_report_length into hidpp_validate_device() since it already fetches very long report length and validates its value Fixes: fe3ee1ec007b ("HID: logitech-hidpp: allow non HID++ devices to be handled by this module") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204191 Reported-by: Sam Bazely Signed-off-by: Andrey Smirnov Cc: Jiri Kosina Cc: Benjamin Tissoires Cc: Henrik Rydberg Cc: Pierre-Loup A. Griffais Cc: Austin Palmer Cc: linux-in...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: sta...@vger.kernel.org # 5.2+ --- drivers/hid/hid-logitech-hidpp.c | 54 ++-- 1 file changed, 30 insertions(+), 24 deletions(-) diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c index 85911586b3b6..6e669eb7dc69 100644 --- a/drivers/hid/hid-logitech-hidpp.c +++ b/drivers/hid/hid-logitech-hidpp.c @@ -3498,34 +3498,45 @@ static int hidpp_get_report_length(struct hid_device *hdev, int id) return report->field[0]->report_count + 1; } -static bool hidpp_validate_report(struct hid_device *hdev, int id, - int expected_length, bool optional) +static bool hidpp_validate_device(struct hid_device *hdev) { - int report_length; + struct hidpp_device *hidpp = hid_get_drvdata(hdev); + int id, report_length, supported_reports = 0; + + id = REPORT_ID_HIDPP_SHORT; + report_length = hidpp_get_report_length(hdev, id); + if (report_length) { + if (report_length < HIDPP_REPORT_SHORT_LENGTH) + goto bad_device; - if (id >= HID_MAX_IDS || id < 0) { - hid_err(hdev, "invalid HID report id %u\n", id); - return false; + supported_reports++; } + id = REPORT_ID_HIDPP_LONG; report_length = hidpp_get_report_length(hdev, id); - if (!report_length) - return optional; + if (report_length) { + if (report_length < HIDPP_REPORT_LONG_LENGTH) + goto bad_device; - if (report_length < expected_length) { - hid_warn(hdev, "not enough values in hidpp report %d\n", id); - return false; + supported_reports++; } - return true; -} + id = REPORT_ID_HIDPP_VERY_LONG; + report_length = hidpp_get_report_length(hdev, id); + if (report_length) { + if (report_length < HIDPP_REPORT_LONG_LENGTH || + report_length > HIDPP_REPORT_VERY_LONG_MAX_LENGTH) + goto bad_device; -static bool hidpp_validate_device(struct hid_device *hdev) -{ - return hidpp_validate_report(hdev, REPORT_ID_HIDPP_SHORT, -HIDPP_REPORT_SHORT_LENGTH, false) && - hidpp_validate_report(hdev, REPORT_ID_HIDPP_LONG, -HIDPP_REPORT_LONG_LENGTH, true); + supported_reports++; + hidpp->very_long_report_length = report_length; + } + + return supported_reports; + +bad_device: + hid_warn(hdev, "not enough values in hidpp report %d\n", id); + return false; } static bool hidpp_application_equals(struct hid_device *hdev, @@ -3572,11 +3583,6 @@ static int hidpp_probe(struct hid_device *hdev, const struct hid_device_id *id) return hid_hw_start(hdev, HID_CONNECT_DEFAULT); } - hidpp->very_long_report_length = - hidpp_get_report_length(hdev, REPORT_ID_HIDPP_VERY_LONG); - if (hidpp->very_long_report_length > HIDPP_REPORT_VERY_LONG_MAX_LENGTH) - hidpp->very_long_report_length = HIDPP_REPORT_VERY_LONG_MAX_LENGTH; - if (id->group == HID_GROUP_LOGITECH_DJ_DEVICE) hidpp->quirks |= HIDPP_QUIRK_UNIFYING; -- 2.21.0
[PATCH v3 1/3] HID: logitech-hidpp: split g920_get_config()
Original version of g920_get_config() contained two kind of actions: 1. Device specific communication to query/set some parameters which requires active communication channel with the device, or, put in other way, for the call to be sandwiched between hid_device_io_start() and hid_device_io_stop(). 2. Input subsystem specific FF controller initialization which, in order to access a valid 'struct hid_input' via 'hid->inputs.next', requires claimed hidinput which means be executed after the call to hid_hw_start() with connect_mask containing HID_CONNECT_HIDINPUT. Location of g920_get_config() can only fulfill requirements for #1 and not #2, which might result in following backtrace: [ 88.312258] logitech-hidpp-device 0003:046D:C262.0005: HID++ 4.2 device connected. [ 88.320298] BUG: kernel NULL pointer dereference, address: 0018 [ 88.320304] #PF: supervisor read access in kernel mode [ 88.320307] #PF: error_code(0x) - not-present page [ 88.320309] PGD 0 P4D 0 [ 88.320315] Oops: [#1] SMP PTI [ 88.320320] CPU: 1 PID: 3080 Comm: systemd-udevd Not tainted 5.4.0-rc1+ #31 [ 88.320322] Hardware name: Apple Inc. MacBookPro11,1/Mac-189A3D4F975D5FFC, BIOS 149.0.0.0.0 09/17/2018 [ 88.320334] RIP: 0010:hidpp_probe+0x61f/0x948 [hid_logitech_hidpp] [ 88.320338] Code: 81 00 00 48 89 ef e8 f0 d6 ff ff 41 89 c6 85 c0 75 b5 0f b6 44 24 28 48 8b 5d 00 88 44 24 1e 89 44 24 0c 48 8b 83 18 1c 00 00 <48> 8b 48 18 48 8b 83 10 19 00 00 48 8b 40 40 48 89 0c 24 0f b7 80 [ 88.320341] RSP: 0018:b0a6824aba68 EFLAGS: 00010246 [ 88.320345] RAX: RBX: 93a50756e000 RCX: 00010408 [ 88.320347] RDX: RSI: 93a51f0ad0a0 RDI: 0002d0a0 [ 88.320350] RBP: 93a50416da28 R08: 93a50416da70 R09: 93a50416da70 [ 88.320352] R10: 00148ae9e60c R11: 000f1525 R12: 93a50756e000 [ 88.320354] R13: 93a50756f8d0 R14: R15: 93a50756fc38 [ 88.320358] FS: 7f8d8c1e0940() GS:93a51f08() knlGS: [ 88.320361] CS: 0010 DS: ES: CR0: 80050033 [ 88.320363] CR2: 0018 CR3: 0003996d8003 CR4: 001606e0 [ 88.320366] Call Trace: [ 88.320377] ? _cond_resched+0x15/0x30 [ 88.320387] ? create_pinctrl+0x2f/0x3c0 [ 88.320393] ? kernfs_link_sibling+0x94/0xe0 [ 88.320398] ? _cond_resched+0x15/0x30 [ 88.320402] ? kernfs_activate+0x5f/0x80 [ 88.320406] ? kernfs_add_one+0xe2/0x130 [ 88.320411] hid_device_probe+0x106/0x170 [ 88.320419] really_probe+0x147/0x3c0 [ 88.320424] driver_probe_device+0xb6/0x100 [ 88.320428] device_driver_attach+0x53/0x60 [ 88.320433] __driver_attach+0x8a/0x150 [ 88.320437] ? device_driver_attach+0x60/0x60 [ 88.320440] bus_for_each_dev+0x78/0xc0 [ 88.320445] bus_add_driver+0x14d/0x1f0 [ 88.320450] driver_register+0x6c/0xc0 [ 88.320453] ? 0xc0d67000 [ 88.320457] __hid_register_driver+0x4c/0x80 [ 88.320464] do_one_initcall+0x46/0x1f4 [ 88.320469] ? _cond_resched+0x15/0x30 [ 88.320474] ? kmem_cache_alloc_trace+0x162/0x220 [ 88.320481] ? do_init_module+0x23/0x230 [ 88.320486] do_init_module+0x5c/0x230 [ 88.320491] load_module+0x26e1/0x2990 [ 88.320502] ? ima_post_read_file+0xf0/0x100 [ 88.320508] ? __do_sys_finit_module+0xaa/0x110 [ 88.320512] __do_sys_finit_module+0xaa/0x110 [ 88.320520] do_syscall_64+0x5b/0x180 [ 88.320525] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 88.320528] RIP: 0033:0x7f8d8d1f01fd [ 88.320532] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 5b 8c 0c 00 f7 d8 64 89 01 48 [ 88.320535] RSP: 002b:7ffefa3bb068 EFLAGS: 0246 ORIG_RAX: 0139 [ 88.320539] RAX: ffda RBX: 55922040cb40 RCX: 7f8d8d1f01fd [ 88.320541] RDX: RSI: 7f8d8ce4984d RDI: 0006 [ 88.320543] RBP: 0002 R08: R09: 0007 [ 88.320545] R10: 0006 R11: 0246 R12: 7f8d8ce4984d [ 88.320547] R13: R14: 55922040efc0 R15: 55922040cb40 [ 88.320551] Modules linked in: hid_logitech_hidpp(+) fuse rfcomm ccm xt_CHECKSUM xt_MASQUERADE bridge stp llc nf_nat_tftp nf_conntrack_tftp nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat tun iptable_mangle iptable_raw iptable_security nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ip_set nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables cmac bnep sunrpc dm_crypt nls_utf8 hfsplus intel_rapl_msr intel_rapl_common ath9k_htc ath9k_common x86_pkg_temp_thermal intel_powerclamp b43 ath9k_hw coretemp snd_hda_c
[PATCH] mm,thp: recheck each page before collapsing file THP
In collapse_file(), after locking the page, it is necessary to recheck that the page is up-to-date, clean, and pointing to the proper mapping. If any check fails, abort the collapse. Fixes: 99cb0dbd47a1 ("mm,thp: add read-only THP support for (non-shmem) FS") Cc: Kirill A. Shutemov Cc: Johannes Weiner Cc: Hugh Dickins Cc: William Kucharski Cc: Andrew Morton Signed-off-by: Song Liu --- mm/khugepaged.c | 8 1 file changed, 8 insertions(+) diff --git a/mm/khugepaged.c b/mm/khugepaged.c index 0a1b4b484ac5..7da49b643c4d 100644 --- a/mm/khugepaged.c +++ b/mm/khugepaged.c @@ -1619,6 +1619,14 @@ static void collapse_file(struct mm_struct *mm, result = SCAN_PAGE_LOCK; goto xa_locked; } + + /* double check the page is correct and clean */ + if (unlikely(!PageUptodate(page)) || + unlikely(PageDirty(page)) || + unlikely(page->mapping != mapping)) { + result = SCAN_FAIL; + goto out_unlock; + } } /* -- 2.17.1
Re: [PATCH v1 4/4] net: dsa: add support for Atheros AR9331 build-in switch
On Thu, Oct 17, 2019 at 11:35:48AM -0700, Florian Fainelli wrote: > > > On 10/13/2019 11:15 PM, Oleksij Rempel wrote: > > Provide basic support for Atheros AR9331 build-in switch. So far it > > works as port multiplexer without any hardware offloading support. > > I glanced through the functional parts of the code, and it looks pretty > straight forward, since there is no offloading done so far, do you plan > on adding bridge offload eventually if nothing more? Currently not. There are following reasons: - I do it for the Freifunk project. It is currently not clear, what functionality has higher priority. - there are not many ar9331 based devices with enough RAM to run any thing modern. There is even less devices using more then one switch port. - IPv6 support is important for this project, but old Atheros switches have some known issues with IPv6 packages in hardware bridge mode. So, this functionality will need more testing. > When you submit v2, I would suggest splitting the tagger code from the > switch driver code, just to make them easier to review. ok. Regards, Oleksij -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH 4/8] riscv: ensure RISC-V C model definitions are passed to static analyzers
On Fri, 18 Oct 2019, Luc Van Oostenryck wrote: > On Thu, Oct 17, 2019 at 05:49:25PM -0700, Paul Walmsley wrote: > > Static analysis tools such as sparse don't set the RISC-V C model > > preprocessor directives such as "__riscv_cmodel_medany", set by the C > > compilers. This causes the static analyzers to evaluate different > > preprocessor paths than C compilers would. Fix this by defining the > > appropriate C model macros in the static analyzer command lines. > > > > Signed-off-by: Paul Walmsley > > --- > > arch/riscv/Makefile | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile > > index f5e914210245..0247a90bd4d8 100644 > > --- a/arch/riscv/Makefile > > +++ b/arch/riscv/Makefile > > @@ -47,9 +47,11 @@ KBUILD_CFLAGS += > > -DCONFIG_PAGE_OFFSET=$(CONFIG_PAGE_OFFSET) > > > > ifeq ($(CONFIG_CMODEL_MEDLOW),y) > > KBUILD_CFLAGS += -mcmodel=medlow > > + CHECKFLAGS += -D__riscv_cmodel_medlow > > endif > > ifeq ($(CONFIG_CMODEL_MEDANY),y) > > KBUILD_CFLAGS += -mcmodel=medany > > + CHECKFLAGS += -D__riscv_cmodel_medany > > I can teach sparse about this in the following days. That would be great. Would you be willing to follow up with me via E-mail or mailing list post when it's fixed? If so, then in the meantime, I'll just drop this patch. - Paul
Re: [PATCH 2/3] HID: google: Add of_match table to Whiskers switch device.
A gentle ping on adding DT binding for Hammer (2/2). On Sat, Oct 5, 2019 at 6:14 PM Ikjoon Jang wrote: > > Add a device tree match table. > > Change-Id: Iaee68311073cefa4b99cde182bd37d1a67c94ea6 > Signed-off-by: Ikjoon Jang > --- > drivers/hid/hid-google-hammer.c | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/drivers/hid/hid-google-hammer.c b/drivers/hid/hid-google-hammer.c > index 31e4a39946f5..bf2b6c6c9787 100644 > --- a/drivers/hid/hid-google-hammer.c > +++ b/drivers/hid/hid-google-hammer.c > @@ -17,6 +17,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -272,12 +273,21 @@ static const struct acpi_device_id cbas_ec_acpi_ids[] = > { > }; > MODULE_DEVICE_TABLE(acpi, cbas_ec_acpi_ids); > > +#ifdef CONFIG_OF > +static const struct of_device_id cbas_ec_of_match[] = { > + { .compatible = "google,cros-cbas" }, > + { }, > +}; > +MODULE_DEVICE_TABLE(of, cbas_ec_of_match); > +#endif > + > static struct platform_driver cbas_ec_driver = { > .probe = cbas_ec_probe, > .remove = cbas_ec_remove, > .driver = { > .name = "cbas_ec", > .acpi_match_table = ACPI_PTR(cbas_ec_acpi_ids), > + .of_match_table = of_match_ptr(cbas_ec_of_match), > .pm = &cbas_ec_pm_ops, > }, > }; > -- > 2.23.0.581.g78d2f28ef7-goog >
Re: [PATCH v2] cpufreq: powernv: fix stack bloat and NR_CPUS limitation
On 17-10-19, 21:55, John Hubbard wrote: > The following build warning occurred on powerpc 64-bit builds: > > drivers/cpufreq/powernv-cpufreq.c: In function 'init_chip_info': > drivers/cpufreq/powernv-cpufreq.c:1070:1: warning: the frame size of 1040 > bytes is larger than 1024 bytes [-Wframe-larger-than=] > > This is due to putting 1024 bytes on the stack: > > unsigned int chip[256]; > > ...and while looking at this, it also has a bug: it fails with a stack > overrun, if CONFIG_NR_CPUS > 256. > > Fix both problems by dynamically allocating based on CONFIG_NR_CPUS. > > Fixes: 053819e0bf840 ("cpufreq: powernv: Handle throttling due to Pmax > capping at chip level") > Cc: Shilpasri G Bhat > Cc: Preeti U Murthy > Cc: Viresh Kumar > Cc: Rafael J. Wysocki > Cc: linux...@vger.kernel.org > Cc: linuxppc-...@lists.ozlabs.org > Signed-off-by: John Hubbard > --- > > Changes since v1: includes Viresh's review commit fixes. > > drivers/cpufreq/powernv-cpufreq.c | 17 + > 1 file changed, 13 insertions(+), 4 deletions(-) Acked-by: Viresh Kumar -- viresh
[PATCH v2 22/33] sh/intc: Use pr_warn instead of pr_warning
As said in commit f2c2cbcc35d4 ("powerpc: Use pr_warn instead of pr_warning"), removing pr_warning so all logging messages use a consistent _warn style. Let's do it. Cc: Yoshinori Sato Cc: Rich Felker Reviewed-by: Sergey Senozhatsky Signed-off-by: Kefeng Wang --- drivers/sh/intc/core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/sh/intc/core.c b/drivers/sh/intc/core.c index 46f0f322d4d8..8485e812d9b2 100644 --- a/drivers/sh/intc/core.c +++ b/drivers/sh/intc/core.c @@ -100,8 +100,8 @@ static void __init intc_register_irq(struct intc_desc *desc, primary = 1; if (!data[0] && !data[1]) - pr_warning("missing unique irq mask for irq %d (vect 0x%04x)\n", - irq, irq2evt(irq)); + pr_warn("missing unique irq mask for irq %d (vect 0x%04x)\n", + irq, irq2evt(irq)); data[0] = data[0] ? data[0] : intc_get_mask_handle(desc, d, enum_id, 1); data[1] = data[1] ? data[1] : intc_get_prio_handle(desc, d, enum_id, 1); -- 2.20.1
Re: [PATCH 2/2] Fix a NULL-ptr-deref bug in ath10k_usb_alloc_urb_from_pipe
On Sun, Sep 01, 2019 at 11:06:05AM +0300, Kalle Valo wrote: > Guenter Roeck writes: > > > Hi, > > > > On Sat, Aug 03, 2019 at 08:31:01PM -0400, Hui Peng wrote: > >> The `ar_usb` field of `ath10k_usb_pipe_usb_pipe` objects > >> are initialized to point to the containing `ath10k_usb` object > >> according to endpoint descriptors read from the device side, as shown > >> below in `ath10k_usb_setup_pipe_resources`: > >> > >> for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) { > >> endpoint = &iface_desc->endpoint[i].desc; > >> > >> // get the address from endpoint descriptor > >> pipe_num = ath10k_usb_get_logical_pipe_num(ar_usb, > >> endpoint->bEndpointAddress, > >> &urbcount); > >> .. > >> // select the pipe object > >> pipe = &ar_usb->pipes[pipe_num]; > >> > >> // initialize the ar_usb field > >> pipe->ar_usb = ar_usb; > >> } > >> > >> The driver assumes that the addresses reported in endpoint > >> descriptors from device side to be complete. If a device is > >> malicious and does not report complete addresses, it may trigger > >> NULL-ptr-deref `ath10k_usb_alloc_urb_from_pipe` and > >> `ath10k_usb_free_urb_to_pipe`. > >> > >> This patch fixes the bug by preventing potential NULL-ptr-deref. > >> > >> Signed-off-by: Hui Peng > >> Reported-by: Hui Peng > >> Reported-by: Mathias Payer > > > > This patch fixes CVE-2019-15099, which has CVSS scores of 7.5 (CVSS 3.0) > > and 7.8 (CVSS 2.0). Yet, I don't find it in the upstream kernel or in Linux > > next. > > > > Is the patch going to be applied to the upstream kernel anytime soon ? > > Same answer as in patch 1: > > https://patchwork.kernel.org/patch/11074655/ > Sorry to bring this up again. The ath6k patch made it into the upstream kernel, but the ath10k patch didn't. Did it get lost, or was there a reason not to apply this patch ? Thanks, Guenter
[PATCH v2 11/33] clocksource: samsung_pwm_timer: Use pr_warn instead of pr_warning
As said in commit f2c2cbcc35d4 ("powerpc: Use pr_warn instead of pr_warning"), removing pr_warning so all logging messages use a consistent _warn style. Let's do it. Cc: Daniel Lezcano Acked-by: Daniel Lezcano Reviewed-by: Sergey Senozhatsky Signed-off-by: Kefeng Wang --- drivers/clocksource/samsung_pwm_timer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clocksource/samsung_pwm_timer.c b/drivers/clocksource/samsung_pwm_timer.c index 895f53eb5771..0274219e1720 100644 --- a/drivers/clocksource/samsung_pwm_timer.c +++ b/drivers/clocksource/samsung_pwm_timer.c @@ -430,7 +430,7 @@ static int __init samsung_pwm_alloc(struct device_node *np, of_property_for_each_u32(np, "samsung,pwm-outputs", prop, cur, val) { if (val >= SAMSUNG_PWM_NUM) { - pr_warning("%s: invalid channel index in samsung,pwm-outputs property\n", + pr_warn("%s: invalid channel index in samsung,pwm-outputs property\n", __func__); continue; } -- 2.20.1
[PATCH v2 17/33] oprofile: Use pr_warn instead of pr_warning
As said in commit f2c2cbcc35d4 ("powerpc: Use pr_warn instead of pr_warning"), removing pr_warning so all logging messages use a consistent _warn style. Let's do it. Cc: Robert Richter Acked-by: Robert Richter Reviewed-by: Sergey Senozhatsky Signed-off-by: Kefeng Wang --- drivers/oprofile/oprofile_perf.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/oprofile/oprofile_perf.c b/drivers/oprofile/oprofile_perf.c index 4b150a754890..98a63a5f8763 100644 --- a/drivers/oprofile/oprofile_perf.c +++ b/drivers/oprofile/oprofile_perf.c @@ -46,8 +46,8 @@ static void op_overflow_handler(struct perf_event *event, if (id != num_counters) oprofile_add_sample(regs, id); else - pr_warning("oprofile: ignoring spurious overflow " - "on cpu %u\n", cpu); + pr_warn("oprofile: ignoring spurious overflow on cpu %u\n", + cpu); } /* @@ -88,8 +88,8 @@ static int op_create_counter(int cpu, int event) if (pevent->state != PERF_EVENT_STATE_ACTIVE) { perf_event_release_kernel(pevent); - pr_warning("oprofile: failed to enable event %d " - "on CPU %d\n", event, cpu); + pr_warn("oprofile: failed to enable event %d on CPU %d\n", + event, cpu); return -EBUSY; } -- 2.20.1
[PATCH v2 21/33] scsi: Use pr_warn instead of pr_warning
As said in commit f2c2cbcc35d4 ("powerpc: Use pr_warn instead of pr_warning"), removing pr_warning so all logging messages use a consistent _warn style. Let's do it. Cc: "James E.J. Bottomley" Cc: "Martin K. Petersen" Reviewed-by: Sergey Senozhatsky Signed-off-by: Kefeng Wang --- drivers/scsi/a3000.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/a3000.c b/drivers/scsi/a3000.c index 222c77c9621f..b6a0432f305a 100644 --- a/drivers/scsi/a3000.c +++ b/drivers/scsi/a3000.c @@ -39,7 +39,7 @@ static irqreturn_t a3000_intr(int irq, void *data) spin_unlock_irqrestore(instance->host_lock, flags); return IRQ_HANDLED; } - pr_warning("Non-serviced A3000 SCSI-interrupt? ISTR = %02x\n", status); + pr_warn("Non-serviced A3000 SCSI-interrupt? ISTR = %02x\n", status); return IRQ_NONE; } -- 2.20.1