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

[PATCH 7/8] mtd: nand: pxa3xx: Fix READOOB implementation

by Chris Packham

From: Boris Brezillon <boris.brezillon(a)free-electrons.com> In the current driver, OOB bytes are accessed in raw mode, and when a page access is done with NDCR_SPARE_EN set and NDCR_ECC_EN cleared, the driver must read the whole spare area (64 bytes in case of a 2k page, 16 bytes for a 512 page). The driver was only reading the free OOB bytes, which was leaving some unread data in the FIFO and was somehow leading to a timeout. We could patch the driver to read ->spare_size + ->ecc_size instead of just ->spare_size when READOOB is requested, but we'd better make in-band and OOB accesses consistent. Since the driver is always accessing in-band data in non-raw mode (with the ECC engine enabled), we should also access OOB data in this mode. That's particularly useful when using the BCH engine because in this mode the free OOB bytes are also ECC protected. Fixes: 43bcfd2bb24a ("mtd: nand: pxa3xx: Add driver-specific ECC BCH support") Cc: stable(a)vger.kernel.org Reported-by: Sean Nyekjær <sean.nyekjaer(a)prevas.dk> Tested-by: Willy Tarreau <w(a)1wt.eu> Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com> Acked-by: Ezequiel Garcia <ezequiel(a)vanguardiasur.com.ar> Tested-by: Sean Nyekjaer <sean.nyekjaer(a)prevas.dk> Acked-by: Robert Jarzmik <robert.jarzmik(a)free.fr> Signed-off-by: Richard Weinberger <richard(a)nod.at> [upstream commit fee4380f368e84ed216b62ccd2fbc4126f2bf40b] Change-Id: Ib3c8a40c72db79336bd2ddfc9463b82ead283036 Reviewed-by: Kalyan Kinthada <kalyan.kinthada(a)alliedtelesis.co.nz> Reviewed-by: Luuk Paulussen <luuk.paulussen(a)alliedtelesis.co.nz> Signed-off-by: Luuk Paulussen <luuk.paulussen(a)alliedtelesis.co.nz> --- drivers/mtd/nand/pxa3xx_nand.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c index 51fe6a5f4e..bd71d536a5 100644 --- a/drivers/mtd/nand/pxa3xx_nand.c +++ b/drivers/mtd/nand/pxa3xx_nand.c @@ -1063,6 +1063,7 @@ static void prepare_start_command(struct pxa3xx_nand_info *info, int command) switch (command) { case NAND_CMD_READ0: + case NAND_CMD_READOOB: case NAND_CMD_PAGEPROG: info->use_ecc = 1; break; -- 2.17.0

7 years, 6 months

1
0
0 0

[PATCH] PCI: pciehp: Add quirk for QDF2400 Command Completed erratum

by Sinan Kaya

The QDF2400 controller does not set the Command Completed bit unless writes to the Slot Command register change "Control" bits. Command Completed is never set for writes that only change software notification "Enable" bits. This results in timeouts like this: pciehp 0000:00:00.0:pcie004: Timeout on hotplug command 0x1038 Cc: stable(a)vger.kernel.org Signed-off-by: Sinan Kaya <okaya(a)codeaurora.org> --- drivers/pci/hotplug/pciehp_hpc.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c index e70eba5..974a8f1 100644 --- a/drivers/pci/hotplug/pciehp_hpc.c +++ b/drivers/pci/hotplug/pciehp_hpc.c @@ -914,3 +914,9 @@ static void quirk_cmd_compl(struct pci_dev *pdev) } DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, PCI_ANY_ID, PCI_CLASS_BRIDGE_PCI, 8, quirk_cmd_compl); + +DECLARE_PCI_FIXUP_CLASS_EARLY(0x17cb, 0x400, + PCI_CLASS_BRIDGE_PCI, 8, quirk_cmd_compl); + +DECLARE_PCI_FIXUP_CLASS_EARLY(0x17cb, 0x401, + PCI_CLASS_BRIDGE_PCI, 8, quirk_cmd_compl); -- 2.7.4

7 years, 6 months

4
3
0 0

Re: [PATCH 1/1] x86/xen: Reset VCPU0 info pointer after shared_info remap

by Boris Ostrovsky

On 05/07/2018 02:00 PM, van der Linden, Frank wrote: > Hi Boris, > > Thanks for the feedback. > > On 5/7/18, 8:13 AM, "Boris Ostrovsky" <boris.ostrovsky(a)oracle.com> wrote: > > > diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c > > index 6b424da1ce75..c78b3e8fb2e5 100644 > > --- a/arch/x86/xen/enlighten_hvm.c > > +++ b/arch/x86/xen/enlighten_hvm.c > > @@ -71,6 +71,19 @@ static void __init xen_hvm_init_mem_mapping(void) > > { > > early_memunmap(HYPERVISOR_shared_info, PAGE_SIZE); > > HYPERVISOR_shared_info = __va(PFN_PHYS(shared_info_pfn)); > > + > > + /* > > + * The virtual address of the shared_info page has changed, so > > + * the vcpu_info pointer for VCPU 0 is now stale. > > Is it "has changed" or "has changed if kaslr is on"? > > It's "has changed". See commit 4ca83dcf4e3bc0c98836dbb97553792ca7ea5429 . It's a way to make kaslr work, but it's done regardless of whether it's enabled or not. I completely forgot about this one. > > > + * > > + * The prepare_boot_cpu callback will re-initialize it via > > + * xen_vcpu_setup, but we can't rely on that to be called for > > + * old Xen versions (xen_have_vector_callback == 0). > > + * > > + * It is, in any case, bad to have a stale vcpu_info pointer > > + * so reset it now. > > + */ > > + xen_vcpu_info_reset(0); > > > Why not xen_vcpu_setup(0)? > > Basically, I wanted to be minimally invasive. xen_vcpu_setup does a little more work (tries to do the VCPU placement hypercall), and will be called later in any case. So doing just the basic xen_vcpu_info_reset for VCPU 0 seems like the best way to do it; it just re-iterates what is done for VCPU 0 earlier in boot, which is also a vcpu_info_reset. OK, fair enough. This should go to stable as well I think (4.12+), copying them. Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>

7 years, 6 months

2
1
0 0

[PATCH] tracing: Fix bad use of igrab in trace_uprobe.c

by Song Liu

commit 0c92c7a3c5d416f47b32c5f20a611dfeca5d5f2e upstream. As Miklos reported and suggested: This pattern repeats two times in trace_uprobe.c and in kernel/events/core.c as well: ret = kern_path(filename, LOOKUP_FOLLOW, &path); if (ret) goto fail_address_parse; inode = igrab(d_inode(path.dentry)); path_put(&path); And it's wrong. You can only hold a reference to the inode if you have an active ref to the superblock as well (which is normally through path.mnt) or holding s_umount. This way unmounting the containing filesystem while the tracepoint is active will give you the "VFS: Busy inodes after unmount..." message and a crash when the inode is finally put. Solution: store path instead of inode. This patch fixes two instances in trace_uprobe.c. struct path is added to struct trace_uprobe to keep the inode and containing mount point referenced. Link: http://lkml.kernel.org/r/20180423172135.4050588-1-songliubraving@fb.com Fixes: f3f096cfedf8 ("tracing: Provide trace events interface for uprobes") Fixes: 33ea4b24277b ("perf/core: Implement the 'perf_uprobe' PMU") Cc: stable(a)vger.kernel.org #4.14+ Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Howard McLauchlan <hmclauchlan(a)fb.com> Cc: Josef Bacik <jbacik(a)fb.com> Cc: Srikar Dronamraju <srikar(a)linux.vnet.ibm.com> Cc: Steven Rostedt (VMware) <rostedt(a)goodmis.org> Acked-by: Miklos Szeredi <mszeredi(a)redhat.com> Reported-by: Miklos Szeredi <miklos(a)szeredi.hu> Signed-off-by: Song Liu <songliubraving(a)fb.com> Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> --- kernel/trace/trace_uprobe.c | 24 ++++++++++-------------- 1 file changed, 10 insertions(+), 14 deletions(-) diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c index 4525e02..14d3af6 100644 --- a/kernel/trace/trace_uprobe.c +++ b/kernel/trace/trace_uprobe.c @@ -55,6 +55,7 @@ struct trace_uprobe { struct list_head list; struct trace_uprobe_filter filter; struct uprobe_consumer consumer; + struct path path; struct inode *inode; char *filename; unsigned long offset; @@ -287,7 +288,7 @@ static void free_trace_uprobe(struct trace_uprobe *tu) for (i = 0; i < tu->tp.nr_args; i++) traceprobe_free_probe_arg(&tu->tp.args[i]); - iput(tu->inode); + path_put(&tu->path); kfree(tu->tp.call.class->system); kfree(tu->tp.call.name); kfree(tu->filename); @@ -361,7 +362,6 @@ static int register_trace_uprobe(struct trace_uprobe *tu) static int create_trace_uprobe(int argc, char **argv) { struct trace_uprobe *tu; - struct inode *inode; char *arg, *event, *group, *filename; char buf[MAX_EVENT_NAME_LEN]; struct path path; @@ -369,7 +369,6 @@ static int create_trace_uprobe(int argc, char **argv) bool is_delete, is_return; int i, ret; - inode = NULL; ret = 0; is_delete = false; is_return = false; @@ -435,21 +434,16 @@ static int create_trace_uprobe(int argc, char **argv) } /* Find the last occurrence, in case the path contains ':' too. */ arg = strrchr(argv[1], ':'); - if (!arg) { - ret = -EINVAL; - goto fail_address_parse; - } + if (!arg) + return -EINVAL; *arg++ = '\0'; filename = argv[1]; ret = kern_path(filename, LOOKUP_FOLLOW, &path); if (ret) - goto fail_address_parse; - - inode = igrab(d_inode(path.dentry)); - path_put(&path); + return ret; - if (!inode || !S_ISREG(inode->i_mode)) { + if (!d_is_reg(path.dentry)) { ret = -EINVAL; goto fail_address_parse; } @@ -488,7 +482,7 @@ static int create_trace_uprobe(int argc, char **argv) goto fail_address_parse; } tu->offset = offset; - tu->inode = inode; + tu->path = path; tu->filename = kstrdup(filename, GFP_KERNEL); if (!tu->filename) { @@ -556,7 +550,7 @@ static int create_trace_uprobe(int argc, char **argv) return ret; fail_address_parse: - iput(inode); + path_put(&path); pr_info("Failed to parse address or file.\n"); @@ -935,6 +929,7 @@ probe_event_enable(struct trace_uprobe *tu, struct trace_event_file *file, goto err_flags; tu->consumer.filter = filter; + tu->inode = d_real_inode(tu->path.dentry); ret = uprobe_register(tu->inode, tu->offset, &tu->consumer); if (ret) goto err_buffer; @@ -980,6 +975,7 @@ probe_event_disable(struct trace_uprobe *tu, struct trace_event_file *file) WARN_ON(!uprobe_filter_is_empty(&tu->filter)); uprobe_unregister(tu->inode, tu->offset, &tu->consumer); + tu->inode = NULL; tu->tp.flags &= file ? ~TP_FLAG_TRACE : ~TP_FLAG_PROFILE; uprobe_buffer_disable(); -- 2.9.5

7 years, 6 months

1
0
0 0

[PATCH v2] KVM: vmx: update sec exec controls for UMIP iff emulating UMIP

by Sean Christopherson

Update SECONDARY_EXEC_DESC for UMIP emulation if and only UMIP is actually being emulated. Skipping the VMCS update eliminates unnecessary VMREAD/VMWRITE when UMIP is supported in hardware, and on platforms that don't have SECONDARY_VM_EXEC_CONTROL. The latter case resolves a bug where KVM would fill the kernel log with warnings due to failed VMWRITEs on older platforms. Fixes: 0367f205a3b7 ("KVM: vmx: add support for emulating UMIP") Cc: stable(a)vger.kernel.org #4.16 Reported-by: Paolo Zeppegno <pzeppegno(a)gmail.com> Suggested-by: Paolo Bonzini <pbonzini(a)redhat.com> Suggested-by: Radim Krčmář <rkrcmar(a)redhat.com> Signed-off-by: Sean Christopherson <sean.j.christopherson(a)intel.com> --- v2: Fix the bug simply by skipping VMCS updates when UMIP is not being emulated, as suggested by Paolo and again by Radim. The approach of updating the VMCS only when CR4.UMIP changed was not guaranteed to work in all cases. Optimizing away VMREAD/VMWRITE will be tackled in a separate series. arch/x86/kvm/vmx.c | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index aafcc9881e88..53d85439e5e5 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -1494,6 +1494,12 @@ static inline bool cpu_has_vmx_vmfunc(void) SECONDARY_EXEC_ENABLE_VMFUNC; } +static bool vmx_umip_emulated(void) +{ + return vmcs_config.cpu_based_2nd_exec_ctrl & + SECONDARY_EXEC_DESC; +} + static inline bool report_flexpriority(void) { return flexpriority_enabled; @@ -4776,14 +4782,16 @@ static int vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4) else hw_cr4 |= KVM_PMODE_VM_CR4_ALWAYS_ON; - if ((cr4 & X86_CR4_UMIP) && !boot_cpu_has(X86_FEATURE_UMIP)) { - vmcs_set_bits(SECONDARY_VM_EXEC_CONTROL, - SECONDARY_EXEC_DESC); - hw_cr4 &= ~X86_CR4_UMIP; - } else if (!is_guest_mode(vcpu) || - !nested_cpu_has2(get_vmcs12(vcpu), SECONDARY_EXEC_DESC)) - vmcs_clear_bits(SECONDARY_VM_EXEC_CONTROL, + if (!boot_cpu_has(X86_FEATURE_UMIP) && vmx_umip_emulated()) { + if (cr4 & X86_CR4_UMIP) { + vmcs_set_bits(SECONDARY_VM_EXEC_CONTROL, SECONDARY_EXEC_DESC); + hw_cr4 &= ~X86_CR4_UMIP; + } else if (!is_guest_mode(vcpu) || + !nested_cpu_has2(get_vmcs12(vcpu), SECONDARY_EXEC_DESC)) + vmcs_clear_bits(SECONDARY_VM_EXEC_CONTROL, + SECONDARY_EXEC_DESC); + } if (cr4 & X86_CR4_VMXE) { /* @@ -9512,12 +9520,6 @@ static bool vmx_xsaves_supported(void) SECONDARY_EXEC_XSAVES; } -static bool vmx_umip_emulated(void) -{ - return vmcs_config.cpu_based_2nd_exec_ctrl & - SECONDARY_EXEC_DESC; -} - static void vmx_recover_nmi_blocking(struct vcpu_vmx *vmx) { u32 exit_intr_info; -- 2.17.0

7 years, 6 months

2
1
0 0

[PATCH] mtd: rawnand: marvell: pass ms delay to wait_op

by Chris Packham

marvell_nfc_wait_op() expects the delay to be expressed in milliseconds but nand_sdr_timings uses picoseconds. Use PSEC_TO_MSEC when passing tPROG_max to marvell_nfc_wait_op(). Fixes: 02f26ecf8c772 ("mtd: nand: add reworked Marvell NAND controller driver") Cc: stable(a)vger.kernel.org Signed-off-by: Chris Packham <chris.packham(a)alliedtelesis.co.nz> --- drivers/mtd/nand/raw/marvell_nand.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/nand/raw/marvell_nand.c b/drivers/mtd/nand/raw/marvell_nand.c index 1d779a35ac8e..e4b964fd40d8 100644 --- a/drivers/mtd/nand/raw/marvell_nand.c +++ b/drivers/mtd/nand/raw/marvell_nand.c @@ -1074,7 +1074,7 @@ static int marvell_nfc_hw_ecc_hmg_do_write_page(struct nand_chip *chip, return ret; ret = marvell_nfc_wait_op(chip, - chip->data_interface.timings.sdr.tPROG_max); + PSEC_TO_MSEC(chip->data_interface.timings.sdr.tPROG_max)); return ret; } @@ -1494,7 +1494,7 @@ static int marvell_nfc_hw_ecc_bch_write_page(struct mtd_info *mtd, } ret = marvell_nfc_wait_op(chip, - chip->data_interface.timings.sdr.tPROG_max); + PSEC_TO_MSEC(chip->data_interface.timings.sdr.tPROG_max)); marvell_nfc_disable_hw_ecc(chip); -- 2.17.0

7 years, 6 months

4
5
0 0

[v4.14.y PATCH] errseq: Always report a writeback error once

by Jeff Layton

From: Matthew Wilcox <willy(a)infradead.org> The errseq_t infrastructure assumes that errors which occurred before the file descriptor was opened are of no interest to the application. This turns out to be a regression for some applications, notably Postgres. Before errseq_t, a writeback error would be reported exactly once (as long as the inode remained in memory), so Postgres could open a file, call fsync() and find out whether there had been a writeback error on that file from another process. This patch changes the errseq infrastructure to report errors to all file descriptors which are opened after the error occurred, but before it was reported to any file descriptor. This restores the user-visible behaviour. [ jlayton: fix up conflicts in comments ] Cc: stable(a)vger.kernel.org Fixes: 5660e13d2fd6 ("fs: new infrastructure for writeback error handling and reporting") Signed-off-by: Matthew Wilcox <mawilcox(a)microsoft.com> Reviewed-by: Jeff Layton <jlayton(a)kernel.org> Signed-off-by: Jeff Layton <jlayton(a)redhat.com> (cherry picked from commit b4678df184b314a2bd47d2329feca2c2534aa12b) --- lib/errseq.c | 25 +++++++++++-------------- 1 file changed, 11 insertions(+), 14 deletions(-) This is a backport to the v4.14 stable series. The only merge conflict was due to an earlier patch by Willy to flesh out the comments. There were no code changes necessary. diff --git a/lib/errseq.c b/lib/errseq.c index 79cc66897db4..b6ed81ec788d 100644 --- a/lib/errseq.c +++ b/lib/errseq.c @@ -111,25 +111,22 @@ EXPORT_SYMBOL(errseq_set); * errseq_sample - grab current errseq_t value * @eseq: pointer to errseq_t to be sampled * - * This function allows callers to sample an errseq_t value, marking it as - * "seen" if required. + * This function allows callers to initialise their errseq_t variable. + * If the error has been "seen", new callers will not see an old error. + * If there is an unseen error in @eseq, the caller of this function will + * see it the next time it checks for an error. + * + * Context: Any context. + * Return: The current errseq value. */ errseq_t errseq_sample(errseq_t *eseq) { errseq_t old = READ_ONCE(*eseq); - errseq_t new = old; - /* - * For the common case of no errors ever having been set, we can skip - * marking the SEEN bit. Once an error has been set, the value will - * never go back to zero. - */ - if (old != 0) { - new |= ERRSEQ_SEEN; - if (old != new) - cmpxchg(eseq, old, new); - } - return new; + /* If nobody has seen this error yet, then we can be the first. */ + if (!(old & ERRSEQ_SEEN)) + old = 0; + return old; } EXPORT_SYMBOL(errseq_sample); -- 2.17.0

7 years, 6 months

3
2
0 0

[PATCH 0/6] virtio-console: spec compliance fixes

by Michael S. Tsirkin

Turns out virtio console tries to take a buffer out of an active vq. Works by sheer luck, and is explicitly forbidden by spec. And while going over it I saw that error handling is also broken - failure is easy to trigger if I force allocations to fail. Lightly tested. Michael S. Tsirkin (6): virtio_console: don't tie bufs to a vq virtio: add ability to iterate over vqs virtio_console: free buffers after reset virtio_console: drop custom control queue cleanup virtio_console: move removal code virtio_console: reset on out of memory drivers/char/virtio_console.c | 155 ++++++++++++++++++++---------------------- include/linux/virtio.h | 3 + 2 files changed, 75 insertions(+), 83 deletions(-) -- MST

7 years, 6 months

5
18
0 0

[PATCH 2/4] iio: imu: inv_mpu6050: fix possible deadlock between mutex and iio

by Jean-Baptiste Maneyrol

Detected by kernel circular locking dependency checker. We are locking iio mutex (iio_device_claim_direct_mode) after locking our internal mutex. But when the buffer starts, iio first locks its mutex and then we lock our internal one. To avoid possible deadlock, we need to use the same order everwhere. So we change the ordering by locking first iio mutex, then our internal mutex. Fixes: 68cd6e5b206b ("iio: imu: inv_mpu6050: fix lock issues by using our own mutex") Cc: stable(a)vger.kernel.org Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol(a)invensense.com> --- drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 34 ++++++++++++++---------------- 1 file changed, 16 insertions(+), 18 deletions(-) diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c index aafa777..7358935 100644 --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c @@ -340,12 +340,9 @@ static int inv_mpu6050_read_channel_data(struct iio_dev *indio_dev, int result; int ret; - result = iio_device_claim_direct_mode(indio_dev); - if (result) - return result; result = inv_mpu6050_set_power_itg(st, true); if (result) - goto error_release; + return result; switch (chan->type) { case IIO_ANGL_VEL: @@ -386,14 +383,11 @@ static int inv_mpu6050_read_channel_data(struct iio_dev *indio_dev, result = inv_mpu6050_set_power_itg(st, false); if (result) goto error_power_off; - iio_device_release_direct_mode(indio_dev); return ret; error_power_off: inv_mpu6050_set_power_itg(st, false); -error_release: - iio_device_release_direct_mode(indio_dev); return result; } @@ -407,9 +401,13 @@ inv_mpu6050_read_raw(struct iio_dev *indio_dev, switch (mask) { case IIO_CHAN_INFO_RAW: + ret = iio_device_claim_direct_mode(indio_dev); + if (ret) + return ret; mutex_lock(&st->lock); ret = inv_mpu6050_read_channel_data(indio_dev, chan, val); mutex_unlock(&st->lock); + iio_device_release_direct_mode(indio_dev); return ret; case IIO_CHAN_INFO_SCALE: switch (chan->type) { @@ -532,17 +530,18 @@ static int inv_mpu6050_write_raw(struct iio_dev *indio_dev, struct inv_mpu6050_state *st = iio_priv(indio_dev); int result; - mutex_lock(&st->lock); /* * we should only update scale when the chip is disabled, i.e. * not running */ result = iio_device_claim_direct_mode(indio_dev); if (result) - goto error_write_raw_unlock; + return result; + + mutex_lock(&st->lock); result = inv_mpu6050_set_power_itg(st, true); if (result) - goto error_write_raw_release; + goto error_write_raw_unlock; switch (mask) { case IIO_CHAN_INFO_SCALE: @@ -581,10 +580,9 @@ static int inv_mpu6050_write_raw(struct iio_dev *indio_dev, } result |= inv_mpu6050_set_power_itg(st, false); -error_write_raw_release: - iio_device_release_direct_mode(indio_dev); error_write_raw_unlock: mutex_unlock(&st->lock); + iio_device_release_direct_mode(indio_dev); return result; } @@ -643,17 +641,18 @@ inv_mpu6050_fifo_rate_store(struct device *dev, struct device_attribute *attr, fifo_rate > INV_MPU6050_MAX_FIFO_RATE) return -EINVAL; + result = iio_device_claim_direct_mode(indio_dev); + if (result) + return result; + mutex_lock(&st->lock); if (fifo_rate == st->chip_config.fifo_rate) { result = 0; goto fifo_rate_fail_unlock; } - result = iio_device_claim_direct_mode(indio_dev); - if (result) - goto fifo_rate_fail_unlock; result = inv_mpu6050_set_power_itg(st, true); if (result) - goto fifo_rate_fail_release; + goto fifo_rate_fail_unlock; d = INV_MPU6050_ONE_K_HZ / fifo_rate - 1; result = regmap_write(st->map, st->reg->sample_rate_div, d); @@ -667,10 +666,9 @@ inv_mpu6050_fifo_rate_store(struct device *dev, struct device_attribute *attr, fifo_rate_fail_power_off: result |= inv_mpu6050_set_power_itg(st, false); -fifo_rate_fail_release: - iio_device_release_direct_mode(indio_dev); fifo_rate_fail_unlock: mutex_unlock(&st->lock); + iio_device_release_direct_mode(indio_dev); if (result) return result; -- 2.7.4

7 years, 6 months

2
1
0 0

FAILED: patch "[PATCH] cpufreq / CPPC: Set platform specific transition_delay_us" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From d4f3388afd488ed15368fa7413b8bd6d1f98bb1d Mon Sep 17 00:00:00 2001 From: Prashanth Prakash <pprakash(a)codeaurora.org> Date: Fri, 27 Apr 2018 11:35:27 -0600 Subject: [PATCH] cpufreq / CPPC: Set platform specific transition_delay_us Add support to specify platform specific transition_delay_us instead of using the transition delay derived from PCC. With commit 3d41386d556d (cpufreq: CPPC: Use transition_delay_us depending transition_latency) we are setting transition_delay_us directly and not applying the LATENCY_MULTIPLIER. Because of that, on Qualcomm Centriq we can end up with a very high rate of frequency change requests when using the schedutil governor (default rate_limit_us=10 compared to an earlier value of 10000). The PCC subspace describes the rate at which the platform can accept commands on the CPPC's PCC channel. This includes read and write command on the PCC channel that can be used for reasons other than frequency transitions. Moreover the same PCC subspace can be used by multiple freq domains and deriving transition_delay_us from it as we do now can be sub-optimal. Moreover if a platform does not use PCC for desired_perf register then there is no way to compute the transition latency or the delay_us. CPPC does not have a standard defined mechanism to get the transition rate or the latency at the moment. Given the above limitations, it is simpler to have a platform specific transition_delay_us and rely on PCC derived value only if a platform specific value is not available. Signed-off-by: Prashanth Prakash <pprakash(a)codeaurora.org> Cc: 4.14+ <stable(a)vger.kernel.org> # 4.14+ Fixes: 3d41386d556d (cpufreq: CPPC: Use transition_delay_us depending transition_latency) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c index bc5fc1630876..b15115a48775 100644 --- a/drivers/cpufreq/cppc_cpufreq.c +++ b/drivers/cpufreq/cppc_cpufreq.c @@ -126,6 +126,49 @@ static void cppc_cpufreq_stop_cpu(struct cpufreq_policy *policy) cpu->perf_caps.lowest_perf, cpu_num, ret); } +/* + * The PCC subspace describes the rate at which platform can accept commands + * on the shared PCC channel (including READs which do not count towards freq + * trasition requests), so ideally we need to use the PCC values as a fallback + * if we don't have a platform specific transition_delay_us + */ +#ifdef CONFIG_ARM64 +#include <asm/cputype.h> + +static unsigned int cppc_cpufreq_get_transition_delay_us(int cpu) +{ + unsigned long implementor = read_cpuid_implementor(); + unsigned long part_num = read_cpuid_part_number(); + unsigned int delay_us = 0; + + switch (implementor) { + case ARM_CPU_IMP_QCOM: + switch (part_num) { + case QCOM_CPU_PART_FALKOR_V1: + case QCOM_CPU_PART_FALKOR: + delay_us = 10000; + break; + default: + delay_us = cppc_get_transition_latency(cpu) / NSEC_PER_USEC; + break; + } + break; + default: + delay_us = cppc_get_transition_latency(cpu) / NSEC_PER_USEC; + break; + } + + return delay_us; +} + +#else + +static unsigned int cppc_cpufreq_get_transition_delay_us(int cpu) +{ + return cppc_get_transition_latency(cpu) / NSEC_PER_USEC; +} +#endif + static int cppc_cpufreq_cpu_init(struct cpufreq_policy *policy) { struct cppc_cpudata *cpu; @@ -162,8 +205,7 @@ static int cppc_cpufreq_cpu_init(struct cpufreq_policy *policy) cpu->perf_caps.highest_perf; policy->cpuinfo.max_freq = cppc_dmi_max_khz; - policy->transition_delay_us = cppc_get_transition_latency(cpu_num) / - NSEC_PER_USEC; + policy->transition_delay_us = cppc_cpufreq_get_transition_delay_us(cpu_num); policy->shared_type = cpu->shared_type; if (policy->shared_type == CPUFREQ_SHARED_TYPE_ANY) {

7 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror