[PATCH] arm64: defconfig: Add Ceva ahci to the defconfig
From: Suneel Garapati The Ceva ahci controller is available on the Xilinx Zynq UltraScale+ MPSoC. Signed-off-by: Suneel Garapati Signed-off-by: Michal Simek --- arch/arm64/configs/defconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index f38c94f1d898..ef5b5d27a226 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -35,10 +35,10 @@ CONFIG_ARCH_EXYNOS7=y CONFIG_ARCH_FSL_LS2085A=y CONFIG_ARCH_HISI=y CONFIG_ARCH_MEDIATEK=y +CONFIG_ARCH_QCOM=y CONFIG_ARCH_SEATTLE=y CONFIG_ARCH_TEGRA=y CONFIG_ARCH_TEGRA_132_SOC=y -CONFIG_ARCH_QCOM=y CONFIG_ARCH_SPRD=y CONFIG_ARCH_THUNDER=y CONFIG_ARCH_VEXPRESS=y @@ -82,7 +82,7 @@ CONFIG_BLK_DEV_SD=y # CONFIG_SCSI_LOWLEVEL is not set CONFIG_ATA=y CONFIG_SATA_AHCI=y -CONFIG_SATA_AHCI_PLATFORM=y +CONFIG_AHCI_CEVA=y CONFIG_AHCI_XGENE=y CONFIG_PATA_PLATFORM=y CONFIG_PATA_OF_PLATFORM=y -- 2.3.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] tun, macvtap: higher order allocations for skbs
On 06/18/2015 06:20 PM, Michael S. Tsirkin wrote: > Needs more testing. Anyone see anything wrong with this? > > Signed-off-by: Michael S. Tsirkin > --- > drivers/net/macvtap.c | 2 +- > drivers/net/tun.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c > index 928f3f4..80e87e4 100644 > --- a/drivers/net/macvtap.c > +++ b/drivers/net/macvtap.c > @@ -610,7 +610,7 @@ static inline struct sk_buff *macvtap_alloc_skb(struct > sock *sk, size_t prepad, > linear = len; > > skb = sock_alloc_send_pskb(sk, prepad + linear, len - linear, noblock, > -err, 0); > +err, 1); > if (!skb) > return NULL; > > diff --git a/drivers/net/tun.c b/drivers/net/tun.c > index cb376b2d..8f2f1e5 100644 > --- a/drivers/net/tun.c > +++ b/drivers/net/tun.c > @@ -1069,7 +1069,7 @@ static struct sk_buff *tun_alloc_skb(struct tun_file > *tfile, > linear = len; > > skb = sock_alloc_send_pskb(sk, prepad + linear, len - linear, noblock, > -, 0); > +, 1); > if (!skb) > return ERR_PTR(err); > Have a round of netperf testing in tun and ixgbe, can see improvement on packet size 512 and 2048. TX: size/session/+thu%/+normalize% 64/ 1/0%/0% 64/ 4/0%/0% 512/ 1/ +6%/ +7% 512/ 4/ +2%/ +2% 2048/ 1/ +24%/ +50% 2048/ 4/0%/ +6% 16384/ 1/0%/ -6% 16384/ 4/0%/ -5% 65535/ 1/0%/ -4% 65535/ 4/0%/ -1% RX: size/session/+thu%/+normalize% 64/ 1/ -5%/ -4% 64/ 4/ -2%/ -1% 512/ 1/ -7%/ -8% 512/ 4/0%/0% 2048/ 1/ +4%/ +7% 2048/ 4/0%/ +2% 16384/ 1/0%/ +2% 16384/ 4/0%/ +13% 65535/ 1/0%/0% 65535/ 4/0%/ -1% TCP_RR: size/session/+thu%/+normalize% 1/25/0%/0% 1/50/0%/0% 64/25/0%/ -1% 64/50/0%/0% 256/25/0%/0% 256/50/0%/0% -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 1/1] drm/amdkfd: Remove redundant pdd validation
pdd is already dereferenced before this check. So it is redundtant to validate pdd here. Signed-off-by: Maninder Singh --- drivers/gpu/drm/amd/amdkfd/kfd_process.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c b/drivers/gpu/drm/amd/amdkfd/kfd_process.c index 8a1f999..4dbc4e5 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c @@ -431,8 +431,7 @@ void kfd_unbind_process_from_device(struct kfd_dev *dev, unsigned int pasid) * We don't call amd_iommu_unbind_pasid() here * because the IOMMU called us. */ - if (pdd) - pdd->bound = false; + pdd->bound = false; mutex_unlock(>mutex); } -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Jun 29
Hi all, Changes since 20150626: Undropped tree: edac-amd The modules tree lost its build failure. Non-merge commits (relative to Linus' tree): 1821 1683 files changed, 111393 insertions(+), 26077 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 221 trees (counting Linus' and 31 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (4a10a91756ef Merge branch 'upstream' of git://git.infradead.org/users/pcmoore/audit) Merging fixes/master (e0dd880a545c Merge branch 'for-4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq) Merging kbuild-current/rc-fixes (c517d838eb7d Linux 4.0-rc1) Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify) Merging arm-current/fixes (0bbe6b5a73c0 ARM: 8388/1: tcm: Don't crash when TCM banks are protected by TrustZone) Merging m68k-current/for-linus (1214c525484c m68k: Use for_each_sg()) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge-mpe/fixes (b953c0d234bc Linux 4.1) Merging powerpc-merge/merge (c517d838eb7d Linux 4.0-rc1) Merging sparc/master (f01cae4e1a9b Merge branch 'sparc-perf-stack') Merging net/master (011cb197a84e Merge branch 'bnx2x') Merging ipsec/master (31a418986a58 xen: netback: read hotplug script once at start of day.) Merging sound-current/for-linus (831bfdf9520e ALSA: hda - restore the MIC FIXUP for some Dell machines) Merging pci-current/for-linus (552bc94ebeeb PCI: Preserve resource size during alignment reordering) Merging wireless-drivers/master (38fe44e61a89 Merge tag 'iwlwifi-for-kalle-2015-05-28' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging driver-core.current/driver-core-linus (d4a4f75cd8f2 Linux 4.1-rc7) Merging tty.current/tty-linus (d4a4f75cd8f2 Linux 4.1-rc7) Merging usb.current/usb-linus (d4a4f75cd8f2 Linux 4.1-rc7) Merging usb-gadget-fixes/fixes (c94e289f195e usb: gadget: remove incorrect __init/__exit annotations) Merging usb-serial-fixes/usb-linus (0f57d86787d8 Linux 4.1-rc8) Merging staging.current/staging-linus (2a298679b411 Merge tag 'usb-4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb) Merging char-misc.current/char-misc-linus (2a298679b411 Merge tag 'usb-4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb) Merging input-current/for-linus (f7ebc4dcdeb1 Merge branch 'next' into for-linus) Merging crypto-current/master (44a17ef872fa crypto: rsa - add .gitignore for crypto/*.-asn1.[ch] files) Merging ide/master (d681f1166919 ide: remove deprecated use of pci api) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES) Merging rr-fixes/fixes (f36963c9d3f6 cpumask_set_cpu_local_first => cpumask_local_spread, lament) Merging vfio-fixes/for-linus (db7d4d7f4021 vfio: Fix runaway interruptible timeout) Merging kselftest-fixes/fixes (ba155e2d21f6 Linux 4.1-rc5) Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: Handle EPROBE_DEFER while requesting the PWM) Merging drm-intel-fixes/for-linux-next-fixes (b953c0d234bc Linux 4.1) Merging asm-generic/master (643165c8bbc8 Merge tag 'uaccess_for_upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost into asm-generic) Merging arc/for-next (40b8ad8f762c ARC: Fix build failures for ARCompact in linux-next after ARCv2 support) CONFLICT (content): Merge conflict
Re: [RFC PATCH 0/6] stop_machine: kill stop_cpus_mutex and stop_cpus_lock
On 06/26, Oleg Nesterov wrote:
>
> 2 cmpxchg()'s vs 2 spin_lock()'s. Plus wake_up(), but we can check
> waitqueue_active().
>
> Do you think thi will be noticeably slower?
>
> Of course, if it races with another stop_two_cpus/stop_cpus it will
> sleep, but in this case we need to wait anyway.
>
>
> And I don't think that percpu-rwsem instead of stop_cpu_mutex makes
> sense. at least I don't understand how can it help. OK, stop_two_cpus()
> can use percpu_down_read() to avoid the deadlock with stop_cpus(), but
> you still need double-lock... So I don't think this will make it faster,
> this will just penalize stop_cpus(). Or I misunderstood.
>
> So I am still not convinced... But probably I am too biased ;)
Yes... I'll probably try to make v2, this version is overcomplicated
and buggy.
> Btw. I can't understand the cpu_active() checks in stop_two_cpus().
> Do we really need them?
Ah, please ignore.
Yes, we can't rely on stopper->enabled check in cpu_stop_queue_work(),
cpu_stop_signal_done() does not update multi_stop_data->num_threads /
->thread_ack. So we need to ensure that cpu_online() == T for both CPUS
or multi_cpu_stop() can hang.
But we can't use cpu_online() instead, take_cpu_down() can be already
queued.
So this relies on the fact that CPU_DOWN_PREPARE (which removes CPU
from cpu_active_mask) is called before stop_machine(take_cpu_down) and
we do not care that cpu_active() is not stable; if we see cpu_active()
cpu_online() can't change unders us because take_cpu_down() was not
queued.
If we change stop_two_cpus() to use stop_work_alloc_one() it can use
cpu_online(),
int stop_two_cpus(unsigned int cpu1, unsigned int cpu2, cpu_stop_fn_t
fn, void *arg)
{
struct cpu_stop_work *work1, *work2;
struct cpu_stop_done done;
struct multi_stop_data msdata = {
.fn = fn,
.data = arg,
.num_threads = 2,
.active_cpus = cpumask_of(cpu1),
};
set_state(, MULTI_STOP_PREPARE);
cpu_stop_init_done(, 2);
if (cpu1 > cpu2)
swap(cpu1, cpu2);
work1 = stop_work_alloc_one(cpu1, true);
work2 = stop_work_alloc_one(cpu2, true);
/* stop_machine() is blocked, cpu can't go away */
if (cpu_online(cpu1) && cpu_online(cpu2)) {
work1->fn = work2->fn = multi_cpu_stop;
work1->arg = work2->arg =
work1->done = work2->done =
preempt_disable();
cpu_stop_queue_work(cpu1, work1);
cpu_stop_queue_work(cpu2, work2);
preempt_enable();
wait_for_completion();
}
stop_work_free_one(cpu1);
stop_work_free_one(cpu2);
stop_work_wake_up();
return done.executed ? done.ret : -ENOENT;
}
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] MAINTAINERS: Update Zynq git tree location
On 06/26/2015 06:04 PM, Soren Brinkmann wrote: > The git tree for Zynq moved to Github. Update the MAINTAINERS record to > reflect the change. > > Signed-off-by: Soren Brinkmann > --- > MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index a01df3088b01..f6b16941ae08 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1639,7 +1639,7 @@ M: Michal Simek > R: Sören Brinkmann > L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) > W: http://wiki.xilinx.com > -T: git git://git.xilinx.com/linux-xlnx.git > +T: git https://github.com/Xilinx/linux-xlnx.git > S: Supported > F: arch/arm/mach-zynq/ > F: drivers/cpuidle/cpuidle-zynq.c > Acked-by: Michal Simek I will add it to my branch if someone else doesn't want it. Thanks, Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kernel/ptrace.c: 2 blank lines, 2 sizeof parentheses
Fixed 4 checkpatch.pl warnings:
kernel/ptrace.c:270: WARNING: Missing a blank line after declarations
kernel/ptrace.c:413: WARNING: Missing a blank line after declarations
kernel/ptrace.c:841: WARNING: sizeof siginfo should be sizeof(siginfo)
kernel/ptrace.c:1140: WARNING: sizeof siginfo should be sizeof(siginfo)
Signed-off-by: Ruben Carlo Benante
---
kernel/ptrace.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index c8e0e05..0759a65 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -264,6 +264,7 @@ ok:
bool ptrace_may_access(struct task_struct *task, unsigned int mode)
{
int err;
+
task_lock(task);
err = __ptrace_may_access(task, mode);
task_unlock(task);
@@ -407,6 +408,7 @@ static int ptrace_traceme(void)
static int ignoring_children(struct sighand_struct *sigh)
{
int ret;
+
spin_lock(>siglock);
ret = (sigh->action[SIGCHLD-1].sa.sa_handler == SIG_IGN) ||
(sigh->action[SIGCHLD-1].sa.sa_flags & SA_NOCLDWAIT);
@@ -835,7 +837,7 @@ int ptrace_request(struct task_struct *child, long request,
break;
case PTRACE_SETSIGINFO:
- if (copy_from_user(, datavp, sizeof siginfo))
+ if (copy_from_user(, datavp, sizeof(siginfo)))
ret = -EFAULT;
else
ret = ptrace_setsiginfo(child, );
@@ -1134,7 +1136,7 @@ int compat_ptrace_request(struct task_struct *child,
compat_long_t request,
break;
case PTRACE_SETSIGINFO:
- memset(, 0, sizeof siginfo);
+ memset(, 0, sizeof(siginfo));
if (copy_siginfo_from_user32(
, (struct compat_siginfo __user *) datap))
ret = -EFAULT;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: via: VIA_RHINE and VIA_VELOCITY should depend on HAS_DMA
From: Geert Uytterhoeven
Date: Fri, 26 Jun 2015 14:08:22 +0200
> If NO_DMA=y:
...
> Before, the symbols depended implicitly on HAS_DMA through PCI or
> USE_OF. Add explicit dependencies on HAS_DMA to fix this.
>
> Fixes: commit b7d3282a245f4428 ("net: via/Kconfig: replace USE_OF with
> OF_???")
> Signed-off-by: Geert Uytterhoeven
Applied, thanks Geert.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]drivers:staging:visorbus:Fix checkpatch warnings
On Sun, Jun 28, 2015 at 10:24:49PM +0530, Ravi Teja wrote: > > This patch fixes checkpatch warnings What warnings? Be specific please. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH 1/6] Document: bindings: DT: Add SMP enable method for MT6580 SoC platform
On Fri, 2015-06-19 at 02:01 +0800, Scott Shu wrote: > For MT6580 SoC platform, the secondary cores are in powered off state > as default, so compared with MT65xx series SoC, one new enable method > is needed. This method using the SPM (System Power Manager) inside > the SCYSYS to control the CPU power. > --- > Documentation/devicetree/bindings/arm/cpus.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/arm/cpus.txt > b/Documentation/devicetree/bindings/arm/cpus.txt > index ac2903d..fb80b2e 100644 > --- a/Documentation/devicetree/bindings/arm/cpus.txt > +++ b/Documentation/devicetree/bindings/arm/cpus.txt > @@ -194,6 +194,7 @@ nodes to be present and contain the properties described > below. > "marvell,armada-380-smp" > "marvell,armada-390-smp" > "marvell,armada-xp-smp" > + "mediatek,mt6580-smp" > "mediatek,mt65xx-smp" > "mediatek,mt81xx-tz-smp" > "qcom,gcc-msm8660" Hi It seems we have 3 different kinds of cpu enable method now, and mt65xx-smp doesn't cover all mt65xx series. So maybe it make sense to change naming before it got merged. Short summary for these methods: mt65xx-smp: For mt65xx socs which wakeup all cores at boot. Tested on mt6589 by Matthias. mt6580-smp: Only first core is alive at boot, so need to wakeup other cores using SPM. AFAIK only for mt6580 now. mt81xx-tz-smp: For soc which wakeup all cores at boot, and have trustzone firmware. Suitable for mt8127, mt8135. I'm not sure about smp for mt6592, maybe Howard or Scott can comment on it. Any suggestion on how we should organize these methods? Joe.C -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC Patch V1] ioatdma: Ignore IOAT devices under hotplug-capable PCI host bridge
> On Jun 28, 2015, at 7:14 PM, Jiang Liu wrote:
>
> Hi Dave,
>Gentle Ping:) Any suggestion about this patch?
> Thanks!
> Gerry
I'm fine with it if Dan has no objections.
>> On 2015/6/2 14:36, Jiang Liu wrote:
>> The dmaengine core assumes that async DMA devices will only be removed
>> when they not used anymore, or it assumes dma_async_device_unregister()
>> will only be called by dma driver exit routines. But this assumption is
>> not true for the IOAT driver, which calls dma_async_device_unregister()
>> from ioat_remove(). So current IOAT driver doesn't support device
>> hot-removal because it may cause system crash to hot-remove an inuse
>> IOAT device.
>>
>> To support CPU socket hot-removal, all PCI devices, including IOAT
>> devices embedded in the socket, will be hot-removed. The idea solution
>> is to enhance the dmaengine core and IOAT driver to support hot-removal,
>> but that's too hard.
>>
>> This patch implements a hack to disable IOAT devices under hotplug-capable
>> CPU socket so it won't break socket hot-removal.
>>
>> Signed-off-by: Jiang Liu
>> ---
>> drivers/dma/ioat/pci.c | 34 ++
>> 1 file changed, 34 insertions(+)
>>
>> diff --git a/drivers/dma/ioat/pci.c b/drivers/dma/ioat/pci.c
>> index 76f0dc688a19..3b8c9b03f4b3 100644
>> --- a/drivers/dma/ioat/pci.c
>> +++ b/drivers/dma/ioat/pci.c
>> @@ -27,6 +27,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include "dma.h"
>> #include "dma_v2.h"
>> #include "registers.h"
>> @@ -148,6 +149,34 @@ alloc_ioatdma(struct pci_dev *pdev, void __iomem
>> *iobase)
>>return d;
>> }
>>
>> +/*
>> + * The dmaengine core assumes that async DMA devices will only be removed
>> + * when they not used anymore, or it assumes dma_async_device_unregister()
>> + * will only be called by dma driver exit routines. But this assumption is
>> + * not true for the IOAT driver, which calls dma_async_device_unregister()
>> + * from ioat_remove(). So current IOAT driver doesn't support device
>> + * hot-removal because it may cause system crash to hot-remove inuse IOAT
>> + * devices.
>> + *
>> + * This is a hack to disable IOAT devices under ejectable PCI host bridge
>> + * so it won't break PCI host bridge hot-removal.
>> + */
>> +static bool ioat_pci_has_ejectable_acpi_ancestor(struct pci_dev *pdev)
>> +{
>> +#ifdef CONFIG_ACPI
>> +struct pci_bus *bus = pdev->bus;
>> +struct acpi_device *adev;
>> +
>> +while (bus->parent)
>> +bus = bus->parent;
>> +for (adev = ACPI_COMPANION(bus->bridge); adev; adev = adev->parent)
>> +if (adev->flags.ejectable)
>> +return true;
>> +#endif
>> +
>> +return false;
>> +}
>> +
>> static int ioat_pci_probe(struct pci_dev *pdev, const struct pci_device_id
>> *id)
>> {
>>void __iomem * const *iomap;
>> @@ -155,6 +184,11 @@ static int ioat_pci_probe(struct pci_dev *pdev, const
>> struct pci_device_id *id)
>>struct ioatdma_device *device;
>>int err;
>>
>> +if (ioat_pci_has_ejectable_acpi_ancestor(pdev)) {
>> +dev_dbg(>dev, "ignore ejectable IOAT device.\n");
>> +return -ENODEV;
>> +}
>> +
>>err = pcim_enable_device(pdev);
>>if (err)
>>return err;
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC Patch V1] ioatdma: Ignore IOAT devices under hotplug-capable PCI host bridge
Hi Dave,
Gentle Ping:) Any suggestion about this patch?
Thanks!
Gerry
On 2015/6/2 14:36, Jiang Liu wrote:
> The dmaengine core assumes that async DMA devices will only be removed
> when they not used anymore, or it assumes dma_async_device_unregister()
> will only be called by dma driver exit routines. But this assumption is
> not true for the IOAT driver, which calls dma_async_device_unregister()
> from ioat_remove(). So current IOAT driver doesn't support device
> hot-removal because it may cause system crash to hot-remove an inuse
> IOAT device.
>
> To support CPU socket hot-removal, all PCI devices, including IOAT
> devices embedded in the socket, will be hot-removed. The idea solution
> is to enhance the dmaengine core and IOAT driver to support hot-removal,
> but that's too hard.
>
> This patch implements a hack to disable IOAT devices under hotplug-capable
> CPU socket so it won't break socket hot-removal.
>
> Signed-off-by: Jiang Liu
> ---
> drivers/dma/ioat/pci.c | 34 ++
> 1 file changed, 34 insertions(+)
>
> diff --git a/drivers/dma/ioat/pci.c b/drivers/dma/ioat/pci.c
> index 76f0dc688a19..3b8c9b03f4b3 100644
> --- a/drivers/dma/ioat/pci.c
> +++ b/drivers/dma/ioat/pci.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
> #include "dma.h"
> #include "dma_v2.h"
> #include "registers.h"
> @@ -148,6 +149,34 @@ alloc_ioatdma(struct pci_dev *pdev, void __iomem *iobase)
> return d;
> }
>
> +/*
> + * The dmaengine core assumes that async DMA devices will only be removed
> + * when they not used anymore, or it assumes dma_async_device_unregister()
> + * will only be called by dma driver exit routines. But this assumption is
> + * not true for the IOAT driver, which calls dma_async_device_unregister()
> + * from ioat_remove(). So current IOAT driver doesn't support device
> + * hot-removal because it may cause system crash to hot-remove inuse IOAT
> + * devices.
> + *
> + * This is a hack to disable IOAT devices under ejectable PCI host bridge
> + * so it won't break PCI host bridge hot-removal.
> + */
> +static bool ioat_pci_has_ejectable_acpi_ancestor(struct pci_dev *pdev)
> +{
> +#ifdef CONFIG_ACPI
> + struct pci_bus *bus = pdev->bus;
> + struct acpi_device *adev;
> +
> + while (bus->parent)
> + bus = bus->parent;
> + for (adev = ACPI_COMPANION(bus->bridge); adev; adev = adev->parent)
> + if (adev->flags.ejectable)
> + return true;
> +#endif
> +
> + return false;
> +}
> +
> static int ioat_pci_probe(struct pci_dev *pdev, const struct pci_device_id
> *id)
> {
> void __iomem * const *iomap;
> @@ -155,6 +184,11 @@ static int ioat_pci_probe(struct pci_dev *pdev, const
> struct pci_device_id *id)
> struct ioatdma_device *device;
> int err;
>
> + if (ioat_pci_has_ejectable_acpi_ancestor(pdev)) {
> + dev_dbg(>dev, "ignore ejectable IOAT device.\n");
> + return -ENODEV;
> + }
> +
> err = pcim_enable_device(pdev);
> if (err)
> return err;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] power: axp288_charger: Fix broken extcon API calls
Hi Guenter,
The similar patch[1] was already merged.
[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4b703b1d4c46ca4a00109ca1a391943ec21991b3
Thanks,
Chanwoo Choi
On 06/27/2015 10:12 AM, Guenter Roeck wrote:
> The extcon API calls have been changed to add an additional argument.
> This causes build errors such as
>
> drivers/power/axp288_charger.c:851:2: error:
> too few arguments to function 'extcon_register_notifier'
>
> Fixes: 73b6ecdb93e8 ("extcon: Redefine the unique id of supported
> external connectors without 'enum extcon' type")
> Fixes: 046050f6e623 ("extcon: Update the prototype of
> extcon_register_notifier() with enum extcon")
> Cc: Chanwoo Choi
> Cc: Ramakrishna Pallala
> Signed-off-by: Guenter Roeck
> ---
> drivers/power/axp288_charger.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/power/axp288_charger.c b/drivers/power/axp288_charger.c
> index 5680317f4823..0aa6e7fd25d4 100644
> --- a/drivers/power/axp288_charger.c
> +++ b/drivers/power/axp288_charger.c
> @@ -848,7 +848,8 @@ static int axp288_charger_probe(struct platform_device
> *pdev)
> /* Register for extcon notification */
> INIT_WORK(>cable.work, axp288_charger_extcon_evt_worker);
> info->cable.nb.notifier_call = axp288_charger_handle_cable_evt;
> - ret = extcon_register_notifier(info->cable.edev, >cable.nb);
> + ret = extcon_register_notifier(info->cable.edev, EXTCON_NONE,
> +>cable.nb);
> if (ret) {
> dev_err(>pdev->dev,
> "failed to register extcon notifier %d\n", ret);
> @@ -909,7 +910,8 @@ intr_reg_failed:
> extcon_unregister_interest(>otg.cable);
> power_supply_unregister(info->psy_usb);
> psy_reg_failed:
> - extcon_unregister_notifier(info->cable.edev, >cable.nb);
> + extcon_unregister_notifier(info->cable.edev, EXTCON_NONE,
> +>cable.nb);
> return ret;
> }
>
> @@ -920,7 +922,8 @@ static int axp288_charger_remove(struct platform_device
> *pdev)
> if (info->otg.cable.edev)
> extcon_unregister_interest(>otg.cable);
>
> - extcon_unregister_notifier(info->cable.edev, >cable.nb);
> + extcon_unregister_notifier(info->cable.edev, EXTCON_NONE,
> +>cable.nb);
> power_supply_unregister(info->psy_usb);
>
> return 0;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] tty: check tcsetpgrp p is a process group
On Sun, Jun 28, 2015 at 12:07 PM, Peter Hurley wrote: > On 06/27/2015 08:51 PM, Patrick Donnelly wrote: >> This fixes a bug where a process can set the foreground process group to its >> pid even if its pid is not a valid pgrp. >> >> Signed-off-by: Patrick Donnelly >> --- >> drivers/tty/tty_io.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c >> index fbb55db..01b4769 100644 >> --- a/drivers/tty/tty_io.c >> +++ b/drivers/tty/tty_io.c >> @@ -2579,6 +2579,9 @@ static int tiocspgrp(struct tty_struct *tty, struct >> tty_struct *real_tty, pid_t >> retval = -ESRCH; >> if (!pgrp) >> goto out_unlock; >> + retval = -EINVAL; >> + if (!pid_task(pgrp, PIDTYPE_PGID)) >> + goto out_unlock; > > This change implies that the sequence in session_of_pgrp() that specifically > checks for pid_task(pgrp, PIDTYPE_PGID) == NULL is not doing anything > useful. However, that hypothesis is directly contradicted by the > comment above session_of_pgrp() > > "* This checks not only the pgrp, but falls back on the pid if no > * satisfactory pgrp is found. I dunno - gdb doesn't work correctly > * without this..." > > Regards, > Peter Hurley > >> retval = -EPERM; >> if (session_of_pgrp(pgrp) != task_session(current)) >> goto out_unlock; >> Ah, missed that. Good catch! I guess this patch is no good since it was already accounted for and it breaks gdb. -- Patrick Donnelly -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL REQUEST] md updates for 4.2
The following changes since commit 0f57d86787d8b1076ea8f9cba2a46d534a27: Linux 4.1-rc8 (2015-06-14 15:51:10 -1000) are available in the git repository at: git://neil.brown.name/md/ tags/md/4.2 for you to fetch changes up to ab16bfc732c436658d13455f28b0b4a2608a7476: md: clear Blocked flag on failed devices when array is read-only. (2015-06-25 17:16:49 +1000) md updates for 4.2 A mixed bag - a few bug fixes - some performance improvement that decrease lock contention - some clean-up Nothing major. Alexey Dobriyan (1): md: convert to kstrto*() Firo Yang (1): md: fix a build warning Kent Overstreet (1): md/raid10: make sync_request_write() call bio_copy_data() Neil Brown (1): md: clear Blocked flag on failed devices when array is read-only. NeilBrown (2): md: clear mddev->private when it has been freed. md: unlock mddev_lock on an error path. Shaohua Li (1): md/raid5: ignore released_stripes check Yuanhan Liu (3): wait: introduce wait_event_exclusive_cmd md/raid5: split wait_for_stripe and introduce wait_for_quiescent md/raid5: per hash value and exclusive wait_for_stripe drivers/md/md.c | 167 ++- drivers/md/raid10.c | 18 ++ drivers/md/raid5.c | 46 +- drivers/md/raid5.h | 3 +- include/linux/wait.h | 13 5 files changed, 146 insertions(+), 101 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND] mfd: rtsx: add support for rts522A
From: Micky Ching
rts522a(rts5227s) is derived from rts5227, and mainly same with rts5227.
Add it to file mfd/rts5227.c to support this chip.
Signed-off-by: Micky Ching
---
drivers/mfd/Kconfig | 7 ++--
drivers/mfd/rts5227.c| 77 ++--
drivers/mfd/rtsx_pcr.c | 5 +++
drivers/mfd/rtsx_pcr.h | 3 ++
include/linux/mfd/rtsx_pci.h | 6
5 files changed, 93 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 6538159..614c146 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -686,9 +686,10 @@ config MFD_RTSX_PCI
select MFD_CORE
help
This supports for Realtek PCI-Express card reader including rts5209,
- rts5229, rtl8411, etc. Realtek card reader supports access to many
- types of memory cards, such as Memory Stick, Memory Stick Pro,
- Secure Digital and MultiMediaCard.
+ rts5227, rts522A, rts5229, rts5249, rts524A, rts525A, rtl8411, etc.
+ Realtek card reader supports access to many types of memory cards,
+ such as Memory Stick, Memory Stick Pro, Secure Digital and
+ MultiMediaCard.
config MFD_RT5033
tristate "Richtek RT5033 Power Management IC"
diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
index ce012d7..cf13e66 100644
--- a/drivers/mfd/rts5227.c
+++ b/drivers/mfd/rts5227.c
@@ -26,6 +26,14 @@
#include "rtsx_pcr.h"
+static u8 rts5227_get_ic_version(struct rtsx_pcr *pcr)
+{
+ u8 val;
+
+ rtsx_pci_read_register(pcr, DUMMY_REG_RESET_0, );
+ return val & 0x0F;
+}
+
static void rts5227_fill_driving(struct rtsx_pcr *pcr, u8 voltage)
{
u8 driving_3v3[4][3] = {
@@ -88,7 +96,7 @@ static void rts5227_force_power_down(struct rtsx_pcr *pcr, u8
pm_state)
rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 3, 0x01, 0);
if (pm_state == HOST_ENTER_S3)
- rtsx_pci_write_register(pcr, PM_CTRL3, 0x10, 0x10);
+ rtsx_pci_write_register(pcr, pcr->reg_pm_ctrl3, 0x10, 0x10);
rtsx_pci_write_register(pcr, FPDCTL, 0x03, 0x03);
}
@@ -121,7 +129,7 @@ static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB8, 0xB8);
else
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB8, 0x88);
- rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PM_CTRL3, 0x10, 0x00);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, pcr->reg_pm_ctrl3, 0x10, 0x00);
return rtsx_pci_send_cmd(pcr, 100);
}
@@ -298,8 +306,73 @@ void rts5227_init_params(struct rtsx_pcr *pcr)
pcr->tx_initial_phase = SET_CLOCK_PHASE(27, 27, 15);
pcr->rx_initial_phase = SET_CLOCK_PHASE(30, 7, 7);
+ pcr->ic_version = rts5227_get_ic_version(pcr);
pcr->sd_pull_ctl_enable_tbl = rts5227_sd_pull_ctl_enable_tbl;
pcr->sd_pull_ctl_disable_tbl = rts5227_sd_pull_ctl_disable_tbl;
pcr->ms_pull_ctl_enable_tbl = rts5227_ms_pull_ctl_enable_tbl;
pcr->ms_pull_ctl_disable_tbl = rts5227_ms_pull_ctl_disable_tbl;
+
+ pcr->reg_pm_ctrl3 = PM_CTRL3;
+}
+
+static int rts522a_optimize_phy(struct rtsx_pcr *pcr)
+{
+ int err;
+
+ err = rtsx_pci_write_register(pcr, RTS522A_PM_CTRL3, D3_DELINK_MODE_EN,
+ 0x00);
+ if (err < 0)
+ return err;
+
+ if (is_version(pcr, 0x522A, IC_VER_A)) {
+ err = rtsx_pci_write_phy_register(pcr, PHY_RCR2,
+ PHY_RCR2_INIT_27S);
+ if (err)
+ return err;
+
+ rtsx_pci_write_phy_register(pcr, PHY_RCR1, PHY_RCR1_INIT_27S);
+ rtsx_pci_write_phy_register(pcr, PHY_FLD0, PHY_FLD0_INIT_27S);
+ rtsx_pci_write_phy_register(pcr, PHY_FLD3, PHY_FLD3_INIT_27S);
+ rtsx_pci_write_phy_register(pcr, PHY_FLD4, PHY_FLD4_INIT_27S);
+ }
+
+ return 0;
+}
+
+static int rts522a_extra_init_hw(struct rtsx_pcr *pcr)
+{
+ rts5227_extra_init_hw(pcr);
+
+ rtsx_pci_write_register(pcr, FUNC_FORCE_CTL, FUNC_FORCE_UPME_XMT_DBG,
+ FUNC_FORCE_UPME_XMT_DBG);
+ rtsx_pci_write_register(pcr, PCLK_CTL, 0x04, 0x04);
+ rtsx_pci_write_register(pcr, PM_EVENT_DEBUG, PME_DEBUG_0, PME_DEBUG_0);
+ rtsx_pci_write_register(pcr, PM_CLK_FORCE_CTL, 0xFF, 0x11);
+
+ return 0;
+}
+
+/* rts522a operations mainly derived from rts5227, except phy/hw init setting.
+ */
+static const struct pcr_ops rts522a_pcr_ops = {
+ .fetch_vendor_settings = rts5227_fetch_vendor_settings,
+ .extra_init_hw = rts522a_extra_init_hw,
+ .optimize_phy = rts522a_optimize_phy,
+ .turn_on_led = rts5227_turn_on_led,
+ .turn_off_led = rts5227_turn_off_led,
+ .enable_auto_blink = rts5227_enable_auto_blink,
+ .disable_auto_blink = rts5227_disable_auto_blink,
+ .card_power_on = rts5227_card_power_on,
+ .card_power_off =
[PATCH] Input: elan_i2c - Add hover event for ST format
Signed-off by: Duson Lin --- drivers/input/mouse/elan_i2c_core.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/input/mouse/elan_i2c_core.c b/drivers/input/mouse/elan_i2c_core.c index 62641f2..ce97e28 100644 --- a/drivers/input/mouse/elan_i2c_core.c +++ b/drivers/input/mouse/elan_i2c_core.c @@ -847,6 +847,7 @@ static void elan_report_absolute(struct elan_tp_data *data, u8 *packet) } input_report_key(input, BTN_LEFT, tp_info & 0x01); + input_report_abs(input, ABS_DISTANCE, hover_event != 0); input_mt_report_pointer_emulation(input, true); input_sync(input); } @@ -922,6 +923,7 @@ static int elan_setup_input_device(struct elan_tp_data *data) input_abs_set_res(input, ABS_Y, data->y_res); input_set_abs_params(input, ABS_PRESSURE, 0, ETP_MAX_PRESSURE, 0, 0); input_set_abs_params(input, ABS_TOOL_WIDTH, 0, ETP_FINGER_WIDTH, 0, 0); + input_set_abs_params(input, ABS_DISTANCE, 0, 1, 0, 0); /* And MT parameters */ input_set_abs_params(input, ABS_MT_POSITION_X, 0, data->max_x, 0, 0); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [all better] Re: regression: massive trouble with fpu rework
On Sun, 28 Jun 2015, Mike Galbraith wrote: > On Sun, 2015-06-28 at 12:06 -0300, Henrique de Moraes Holschuh wrote: > > It is just that this kind of breakage should not be subtle if we can help > > it, because people will use a crippled system for years without noticing... > > If you can use it without noticing for years, it ain't crippled, or? My > point being that severity seems more akin to the box having a zit behind > its left ear, in which case lobotomizing it seems a tad extreme. Noted. However if it does boot with cpuid limited (and we don't "unlimit" it somehow) on a recent processor, at *best* the user paid good money for a lot of stuff that is going to not be used to enhance system performance and system security. It is not nice to the user to just limp along silently about this. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mwifiex: usb: Fix double add error when submitting rx urb
There is an error that can occur where the driver adds the same URB to USB
submission list twice.
This happens since mwifiex_usb_submit_rem_rx can submit packets at same time as
an rx urb complete callback.
This causes list corruption and is fixed by not setting the skb to NULL when
submitting an rx packet.
[ 84.461242] WARNING: CPU: 1 PID: 748 at lib/list_debug.c:36
__list_add+0xcb/0xd0()
[ 84.461245] list_add double add: new=8800c92b0c50,
prev=8800c92b0c50, next=8800ced6c430.
[ 84.461247] Modules linked in: rfcomm fuse cmac nf_conntrack_netbios_ns
nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack
ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat
nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security
ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack bnep iptable_mangle
iptable_security iptable_raw btusb btintel bluetooth mwifiex_usb mwifiex
x86_pkg_temp_thermal cfg80211 coretemp r8712u(C) kvm_intel kvm hid_sensor_als
hid_sensor_incl_3d hid_sensor_rotation hid_sensor_magn_3d hid_sensor_accel_3d
hid_sensor_gyro_3d hid_sensor_trigger hid_sensor_iio_common
industrialio_triggered_buffer kfifo_buf rfkill iTCO_wdt industrialio
iTCO_vendor_support
[ 84.461316] crc32_pclmul crc32c_intel ghash_clmulni_intel microcode
snd_hda_codec_realtek vfat snd_hda_codec_generic fat snd_hda_codec_hdmi
snd_hda_intel snd_hda_controller uvcvideo snd_hda_codec videobuf2_vmalloc
videobuf2_memops snd_hwdep videobuf2_core snd_hda_core joydev v4l2_common
videodev hid_sensor_hub snd_seq hid_multitouch media snd_seq_device snd_pcm
snd_timer mei_me snd i2c_i801 lpc_ich mei soundcore tpm_infineon tpm_tis tpm
i2c_hid i2c_designware_platform i2c_designware_core nfsd auth_rpcgss nfs_acl
lockd grace sunrpc sch_fq_codel i915 i2c_algo_bit drm_kms_helper drm xhci_pci
xhci_hcd ehci_pci sd_mod ehci_hcd video
[ 84.461383] CPU: 1 PID: 748 Comm: kworker/u9:0 Tainted: G C
4.1.0-rc5+ #163
[ 84.461386] Hardware name: Microsoft Corporation Surface Pro 2/Surface Pro
2, BIOS 2.05.0250 04/10/2015
[ 84.461396] Workqueue: MWIFIEX_RX_WORK_QUEUE mwifiex_rx_work_queue [mwifiex]
[ 84.461399] 81a8150e 8801174cf8e8 817df830
[ 84.461405] 8801174cf938 8801174cf928 810a54ba
8800c86bd750
[ 84.461410] 8800c92b0c50 8800c92b0c50 8800ced6c430
88010c057178
[ 84.461416] Call Trace:
[ 84.461421] [] dump_stack+0x4f/0x7b
[ 84.461428] [] warn_slowpath_common+0x8a/0xc0
[ 84.461432] [] warn_slowpath_fmt+0x46/0x50
[ 84.461436] [] __list_add+0xcb/0xd0
[ 84.461442] [] ? usb_hcd_link_urb_to_ep+0x2a/0xa0
[ 84.461446] [] usb_hcd_link_urb_to_ep+0x80/0xa0
[ 84.461459] [] prepare_transfer+0xaa/0x130 [xhci_hcd]
[ 84.461470] [] xhci_queue_bulk_tx+0xb7/0x7a0 [xhci_hcd]
[ 84.461480] [] ? xhci_urb_enqueue+0x50f/0x660 [xhci_hcd]
[ 84.461489] [] ? xhci_urb_enqueue+0x50f/0x660 [xhci_hcd]
[ 84.461498] [] xhci_urb_enqueue+0x5c5/0x660 [xhci_hcd]
[ 84.461503] [] usb_hcd_submit_urb+0x93/0xa70
[ 84.461507] [] ? __alloc_skb+0x78/0x1f0
[ 84.461511] [] ? __kmalloc_reserve.isra.26+0x31/0x90
[ 84.461515] [] ? __alloc_skb+0x4c/0x1f0
[ 84.461519] [] ? __alloc_skb+0x8c/0x1f0
[ 84.461523] [] ? skb_dequeue+0x5d/0x80
[ 84.461527] [] usb_submit_urb+0x42e/0x5f0
[ 84.461531] [] ? __alloc_rx_skb+0x39/0x100
[ 84.461536] [] mwifiex_usb_submit_rx_urb+0xb2/0x170
[mwifiex_usb]
[ 84.461542] [] mwifiex_usb_submit_rem_rx_urbs+0x45/0x50
[mwifiex_usb]
[ 84.461550] [] mwifiex_rx_work_queue+0x10e/0x140 [mwifiex]
[ 84.461556] [] process_one_work+0x229/0x890
[ 84.461559] [] ? process_one_work+0x18c/0x890
[ 84.461565] [] worker_thread+0x53/0x470
[ 84.461569] [] ? process_one_work+0x890/0x890
[ 84.461572] [] kthread+0xf2/0x110
[ 84.461577] [] ? trace_hardirqs_on+0xd/0x10
[ 84.461581] [] ? kthread_create_on_node+0x230/0x230
[ 84.461586] [] ret_from_fork+0x42/0x70
[ 84.461590] [] ? kthread_create_on_node+0x230/0x230
[ 84.461593] ---[ end trace 65103af5e6fb3444 ]---
Signed-off-by: Reyad Attiyat
---
drivers/net/wireless/mwifiex/usb.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/usb.c
b/drivers/net/wireless/mwifiex/usb.c
index fd8027f..cd3ba76 100644
--- a/drivers/net/wireless/mwifiex/usb.c
+++ b/drivers/net/wireless/mwifiex/usb.c
@@ -235,9 +235,11 @@ setup_for_next:
if (card->rx_cmd_ep == context->ep) {
mwifiex_usb_submit_rx_urb(context, size);
} else {
- context->skb = NULL;
- if (atomic_read(>rx_pending) <= HIGH_RX_PENDING)
+ if (atomic_read(>rx_pending) <= HIGH_RX_PENDING){
mwifiex_usb_submit_rx_urb(context, size);
+ }else{
+ context->skb = NULL;
+
[PATCH RFC 1/1] perf,tool: partial callgrap and time support
From: Kan Liang
When multiple events are sampled it may not be needed to collect
callgraphs for all of them. The sample sites are usually nearby, and
it's enough to collect the callgraphs on a reference event (such as
precise cycles or precise instructions). Similarly we also don't need
fine grained time stamps on all events, as it's enough to have time
stamps on the regular reference events.
This patchkit adds the ability to turn off callgraphs and time stamps
per event. This in term can reduce sampling overhead and the size of the
perf.data. Furthermore, it makes collecting back traces and timestamps
possible when PEBS threshold > 1, which significantly reducing the
sampling overhead especially for frequently occurring events
(https://lkml.org/lkml/2015/5/10/196). For example, A slower event with
a larger period collects back traces/timestamps. Other more events run
fast with multi-pebs. The time stamps from the slower events can be used
to order the faster events. Their backtraces can give the user enough
hint to find the right spot.
Here are some examples and test results.
1. Comparing the elapsed time and perf.data size from "kernbench -M -H".
The test command for FULL callgrap and time support.
"perf record -e
'{cpu/cpu-cycles,period=10/,cpu/instructions,period=2/p}'
--call-graph fp --time"
The test command for PARTIAL callgrap and time support.
"perf record -e
'{cpu/cpu-cycles,callgraph=1,time=1,period=10/,
cpu/instructions,callgraph=0,time=0,period=2/p}'"
The elapsed time for FULL is 24.3 Sec, while for PARTIAL is 16.9 Sec.
The perf.data size for FULL is 22.1 Gb, while for PARTIAL is 12.4 Gb.
2. Comparing the perf.data size and callgraph results.
The test command for FULL callgrap and time support.
"perf record -e
'{cpu/cpu-cycles,period=10/pp,cpu/instructions,period=2/p}'
--call-graph fp -- ./tchain_edit"
The test command for PARTIAL callgrap and time support.
"perf record -e
'{cpu/cpu-cycles,callgraph=1,time=1,period=10/pp,
cpu/instructions,callgraph=0,time=0,period=2/p}'
-- ./tchain_edit"
The perf.data size for FULL is 43.2 MB, while for PARTIAL is 21.1 MB.
The callgraph is roughly the same.
The callgraph from FULL
# Samples: 87K of event
'cpu/cpu-cycles,callgraph=1,time=1,period=10/pp'
# Event count (approx.): 876000
#
# Children Self Command Shared Object Symbol
# ... ..
..
#
99.98% 0.00% tchain_edit libc-2.15.so[.]
__libc_start_main
|
---__libc_start_main
99.97% 0.00% tchain_edit tchain_edit [.] main
|
---main
__libc_start_main
99.97% 0.00% tchain_edit tchain_edit [.] f1
|
---f1
main
__libc_start_main
99.85%87.01% tchain_edit tchain_edit [.] f3
|
---f3
|
|--99.74%-- f2
| f1
| main
| __libc_start_main
--0.26%-- [...]
99.71% 0.12% tchain_edit tchain_edit [.] f2
|
---f2
f1
main
__libc_start_main
The callgraph from PARTIAL
# Samples: 417K of event
'cpu/instructions,callgraph=0,time=0,period=2/p'
# Event count (approx.): 834698
#
# Children Self Command Shared Object Symbol
# ...
..
#
98.82% 0.00% tchain_edit libc-2.15.so [.]
__libc_start_main
|
---__libc_start_main
98.82% 0.00% tchain_edit tchain_edit [.] main
|
---main
__libc_start_main
98.82% 0.00% tchain_edit tchain_edit [.] f1
|
---f1
main
__libc_start_main
98.82%98.28% tchain_edit tchain_edit [.] f3
|
---f3
|
|--0.53%-- f2
| f1
| main
| __libc_start_main
|
|--0.01%-- f1
| main
| __libc_start_main
--99.46%-- [...]
97.63% 0.03% tchain_edit tchain_edit [.] f2
|
---f2
f1
main
__libc_start_main
7.13% 0.03% tchain_edit [kernel.vmlinux] [k] do_nmi
|
---do_nmi
end_repeat_nmi
f3
f2
f1
main
__libc_start_main
Signed-off-by: Kan Liang
---
tools/perf/Documentation/perf-record.txt | 13
[PATCH v2] usb: xhci: Add support for URB_ZERO_PACKET to bulk/sg transfers
This commmit checks for the URB_ZERO_PACKET flag and creates an extra
zero-length td if the urb transfer length is a multiple of the endpoint's
max packet length.
Signed-off-by: Reyad Attiyat
---
drivers/usb/host/xhci-ring.c | 43 +--
1 file changed, 33 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 7d34cbf..3d57a7a 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -3040,7 +3040,9 @@ static int queue_bulk_sg_tx(struct xhci_hcd *xhci, gfp_t
mem_flags,
int num_sgs;
int trb_buff_len, this_sg_len, running_total;
unsigned int total_packet_count;
+ bool zero_length_needed;
bool first_trb;
+ int last_trb;
u64 addr;
bool more_trbs_coming;
@@ -3056,6 +3058,14 @@ static int queue_bulk_sg_tx(struct xhci_hcd *xhci, gfp_t
mem_flags,
total_packet_count = DIV_ROUND_UP(urb->transfer_buffer_length,
usb_endpoint_maxp(>ep->desc));
+ /* Deal with URB_ZERO_PACKET - need one more td/trb */
+ zero_length_needed = (urb->transfer_flags & URB_ZERO_PACKET)
+&& !(urb->transfer_buffer_length % usb_endpoint_maxp(>ep->desc));
+ if(zero_length_needed){
+ num_trbs++;
+ xhci_dbg(xhci, "Creating zero length td.\n");
+ }
+
trb_buff_len = prepare_transfer(xhci, xhci->devs[slot_id],
ep_index, urb->stream_id,
num_trbs, urb, 0, mem_flags);
@@ -3092,6 +3102,7 @@ static int queue_bulk_sg_tx(struct xhci_hcd *xhci, gfp_t
mem_flags,
trb_buff_len = urb->transfer_buffer_length;
first_trb = true;
+ last_trb = zero_length_needed ? 2 : 1;
/* Queue the first TRB, even if it's zero-length */
do {
u32 field = 0;
@@ -3109,12 +3120,13 @@ static int queue_bulk_sg_tx(struct xhci_hcd *xhci,
gfp_t mem_flags,
/* Chain all the TRBs together; clear the chain bit in the last
* TRB to indicate it's the last TRB in the chain.
*/
- if (num_trbs > 1) {
+ if (num_trbs > last_trb) {
field |= TRB_CHAIN;
- } else {
- /* FIXME - add check for ZERO_PACKET flag before this */
+ } else if (num_trbs == last_trb) {
td->last_trb = ep_ring->enqueue;
field |= TRB_IOC;
+ } else if (zero_length_needed && num_trbs == 1) {
+ trb_buff_len = 0;
}
/* Only set interrupt on short packet for IN endpoints */
@@ -3176,7 +3188,7 @@ static int queue_bulk_sg_tx(struct xhci_hcd *xhci, gfp_t
mem_flags,
if (running_total + trb_buff_len > urb->transfer_buffer_length)
trb_buff_len =
urb->transfer_buffer_length - running_total;
- } while (running_total < urb->transfer_buffer_length);
+ } while (num_trbs > 0);
check_trb_math(urb, num_trbs, running_total);
giveback_first_trb(xhci, slot_id, ep_index, urb->stream_id,
@@ -3194,7 +3206,9 @@ int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t
mem_flags,
int num_trbs;
struct xhci_generic_trb *start_trb;
bool first_trb;
+ int last_trb;
bool more_trbs_coming;
+ bool zero_length_needed;
int start_cycle;
u32 field, length_field;
@@ -3225,7 +3239,14 @@ int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t
mem_flags,
num_trbs++;
running_total += TRB_MAX_BUFF_SIZE;
}
- /* FIXME: this doesn't deal with URB_ZERO_PACKET - need one more */
+
+ /* Deal with URB_ZERO_PACKET - need one more td/trb */
+ zero_length_needed = (urb->transfer_flags & URB_ZERO_PACKET)
+&& !(urb->transfer_buffer_length % usb_endpoint_maxp(>ep->desc));
+ if(zero_length_needed){
+ num_trbs++;
+ xhci_dbg(xhci, "Creating zero length td.\n");
+ }
ret = prepare_transfer(xhci, xhci->devs[slot_id],
ep_index, urb->stream_id,
@@ -3255,7 +3276,7 @@ int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t
mem_flags,
trb_buff_len = urb->transfer_buffer_length;
first_trb = true;
-
+ last_trb = zero_length_needed ? 2 : 1;
/* Queue the first TRB, even if it's zero-length */
do {
u32 remainder = 0;
@@ -3272,12 +3293,14 @@ int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t
mem_flags,
/* Chain all the TRBs together; clear the chain bit in the last
* TRB to indicate it's the last TRB in the chain.
*/
- if (num_trbs > 1) {
+
+ if (num_trbs > last_trb) {
field |= TRB_CHAIN;
-
Re: [alsa-devel] [V2 PATCH] ALSA: hda - Enable mute/mic-mute LEDs for more Thinkpads with Conexant codec
On 06/27/2015 11:03 AM, Raymond Yau wrote:
Most Thinkpad Edge series laptops use conexant codec, so far
although
Is there anything I can debug or any information I can collect
from my
box to examine this?
What is the linux distribution on your machine? And use showkey to
catch
the keycode of that button.
I'm running OpenSUSE 13.1. The reported keycode of the power
button is
116.
It seems the keycode is correct, it is power keycode rather the mute
keycode.
Could you please do some debug, let us find which line of code is
the
root cause for this problem. for example:
after running the line, the problem shows up:
1. if (ACPI_SUCCESS(acpi_get_devices("LEN0068", acpi_check_cb,
, NULL)) && found) // in the sound/pci/hda/thinkpad_helper.c,
is_thinkpad()
This evaluates to true
2. return ACPI_SUCCESS(acpi_get_devices("IBM0068",
acpi_check_cb,
, NULL)) && found; // same as above
3. if (led_set_func(TPACPI_LED_MUTE, false) >= 0) { //in the
sound/pci/hda/thinkpad_helper.c, hda_fixup_thinkpad_acpi()
...and this
4. if (led_set_func(TPACPI_LED_MICMUTE, false) >= 0) { // same as
above
...and this as well. spec->num_adc_nids is 1.
If we change the code like below, does the power button can work well?
in the thinkpad_helper.c, hda_fixup_thinkpad_acpi()
if (led_set_func(TPACPI_LED_MUTE, false) >= 0) {
/*
old_vmaster_hook = spec->vmaster_mute.hook;
spec->vmaster_mute.hook = update_tpacpi_mute_led;
removefunc = false;
*/
Disabling only this block resolves the issue.
So Below two lines make the power button change to the reset button.
drivers/platform/x86/thinkpad_acpi.c mute_led_on_off():
acpi_get_handle(hkey_handle, "SSMS", );
acpi_evalf(hkey_handle, , "SSMS", "dd", 1);
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/platform/x86/thinkpad_acpi.c?id=9a417ec0c9d1f7af5394333411fc4d98adb8761b
It seem that software mute also depend on HAUM and SAUM ACPI interface
Seem regression of the above patch is SSMS is not supported
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1450947
Which models of thinkpad are tested by the author ?
A lot, we tested this patch on all Lenovo machines with mute led we
have. I need to check the models name and provide them at a later time.
___
Alsa-devel mailing list
alsa-de...@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: xhci: Add support for URB_ZERO_PACKET to bulk/sg transfers
Sorry I have forgotten to change the dp loop check line in the bulk_sg
function. Will resubmit.
On Sun, Jun 28, 2015 at 7:36 PM, Reyad Attiyat wrote:
> This commit checks for the URB_ZERO_PACKET flag and creates an extra
> zero-length td if the urb transfer length is a multiple of the endpoint
> max packet length.
>
> Signed-off-by: Reyad Attiyat
> ---
> drivers/usb/host/xhci-ring.c | 41 -
> 1 file changed, 32 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index 7d34cbf..fb24099 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -3040,7 +3040,9 @@ static int queue_bulk_sg_tx(struct xhci_hcd *xhci,
> gfp_t mem_flags,
> int num_sgs;
> int trb_buff_len, this_sg_len, running_total;
> unsigned int total_packet_count;
> + bool zero_length_needed;
> bool first_trb;
> + int last_trb;
> u64 addr;
> bool more_trbs_coming;
>
> @@ -3056,6 +3058,14 @@ static int queue_bulk_sg_tx(struct xhci_hcd *xhci,
> gfp_t mem_flags,
> total_packet_count = DIV_ROUND_UP(urb->transfer_buffer_length,
> usb_endpoint_maxp(>ep->desc));
>
> + /* Deal with URB_ZERO_PACKET - need one more td/trb */
> + zero_length_needed = (urb->transfer_flags & URB_ZERO_PACKET)
> +&& !(urb->transfer_buffer_length %
> usb_endpoint_maxp(>ep->desc));
> + if(zero_length_needed){
> + num_trbs++;
> + xhci_dbg(xhci, "Creating zero length td.\n");
> + }
> +
> trb_buff_len = prepare_transfer(xhci, xhci->devs[slot_id],
> ep_index, urb->stream_id,
> num_trbs, urb, 0, mem_flags);
> @@ -3092,6 +3102,7 @@ static int queue_bulk_sg_tx(struct xhci_hcd *xhci,
> gfp_t mem_flags,
> trb_buff_len = urb->transfer_buffer_length;
>
> first_trb = true;
> + last_trb = zero_length_needed ? 2 : 1;
> /* Queue the first TRB, even if it's zero-length */
> do {
> u32 field = 0;
> @@ -3109,12 +3120,13 @@ static int queue_bulk_sg_tx(struct xhci_hcd *xhci,
> gfp_t mem_flags,
> /* Chain all the TRBs together; clear the chain bit in the
> last
> * TRB to indicate it's the last TRB in the chain.
> */
> - if (num_trbs > 1) {
> + if (num_trbs > last_trb) {
> field |= TRB_CHAIN;
> - } else {
> - /* FIXME - add check for ZERO_PACKET flag before this
> */
> + } else if (num_trbs == last_trb) {
> td->last_trb = ep_ring->enqueue;
> field |= TRB_IOC;
> + } else if (zero_length_needed && num_trbs == 1) {
> + trb_buff_len = 0;
> }
>
> /* Only set interrupt on short packet for IN endpoints */
> @@ -3194,7 +3206,9 @@ int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t
> mem_flags,
> int num_trbs;
> struct xhci_generic_trb *start_trb;
> bool first_trb;
> + int last_trb;
> bool more_trbs_coming;
> + bool zero_length_needed;
> int start_cycle;
> u32 field, length_field;
>
> @@ -3225,7 +3239,14 @@ int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t
> mem_flags,
> num_trbs++;
> running_total += TRB_MAX_BUFF_SIZE;
> }
> - /* FIXME: this doesn't deal with URB_ZERO_PACKET - need one more */
> +
> + /* Deal with URB_ZERO_PACKET - need one more td/trb */
> + zero_length_needed = (urb->transfer_flags & URB_ZERO_PACKET)
> +&& !(urb->transfer_buffer_length %
> usb_endpoint_maxp(>ep->desc));
> + if(zero_length_needed){
> + num_trbs++;
> + xhci_dbg(xhci, "Creating zero length td.\n");
> + }
>
> ret = prepare_transfer(xhci, xhci->devs[slot_id],
> ep_index, urb->stream_id,
> @@ -3255,7 +3276,7 @@ int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t
> mem_flags,
> trb_buff_len = urb->transfer_buffer_length;
>
> first_trb = true;
> -
> + last_trb = zero_length_needed ? 2 : 1;
> /* Queue the first TRB, even if it's zero-length */
> do {
> u32 remainder = 0;
> @@ -3272,12 +3293,14 @@ int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t
> mem_flags,
> /* Chain all the TRBs together; clear the chain bit in the
> last
> * TRB to indicate it's the last TRB in the chain.
> */
> - if (num_trbs > 1) {
> +
> + if (num_trbs > last_trb) {
> field |= TRB_CHAIN;
> - } else {
> - /* FIXME - add check for ZERO_PACKET flag before this
> */
> + } else if
[PATCH] usb: xhci: Add support for URB_ZERO_PACKET to bulk/sg transfers
This commit checks for the URB_ZERO_PACKET flag and creates an extra
zero-length td if the urb transfer length is a multiple of the endpoint
max packet length.
Signed-off-by: Reyad Attiyat
---
drivers/usb/host/xhci-ring.c | 41 -
1 file changed, 32 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 7d34cbf..fb24099 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -3040,7 +3040,9 @@ static int queue_bulk_sg_tx(struct xhci_hcd *xhci, gfp_t
mem_flags,
int num_sgs;
int trb_buff_len, this_sg_len, running_total;
unsigned int total_packet_count;
+ bool zero_length_needed;
bool first_trb;
+ int last_trb;
u64 addr;
bool more_trbs_coming;
@@ -3056,6 +3058,14 @@ static int queue_bulk_sg_tx(struct xhci_hcd *xhci, gfp_t
mem_flags,
total_packet_count = DIV_ROUND_UP(urb->transfer_buffer_length,
usb_endpoint_maxp(>ep->desc));
+ /* Deal with URB_ZERO_PACKET - need one more td/trb */
+ zero_length_needed = (urb->transfer_flags & URB_ZERO_PACKET)
+&& !(urb->transfer_buffer_length % usb_endpoint_maxp(>ep->desc));
+ if(zero_length_needed){
+ num_trbs++;
+ xhci_dbg(xhci, "Creating zero length td.\n");
+ }
+
trb_buff_len = prepare_transfer(xhci, xhci->devs[slot_id],
ep_index, urb->stream_id,
num_trbs, urb, 0, mem_flags);
@@ -3092,6 +3102,7 @@ static int queue_bulk_sg_tx(struct xhci_hcd *xhci, gfp_t
mem_flags,
trb_buff_len = urb->transfer_buffer_length;
first_trb = true;
+ last_trb = zero_length_needed ? 2 : 1;
/* Queue the first TRB, even if it's zero-length */
do {
u32 field = 0;
@@ -3109,12 +3120,13 @@ static int queue_bulk_sg_tx(struct xhci_hcd *xhci,
gfp_t mem_flags,
/* Chain all the TRBs together; clear the chain bit in the last
* TRB to indicate it's the last TRB in the chain.
*/
- if (num_trbs > 1) {
+ if (num_trbs > last_trb) {
field |= TRB_CHAIN;
- } else {
- /* FIXME - add check for ZERO_PACKET flag before this */
+ } else if (num_trbs == last_trb) {
td->last_trb = ep_ring->enqueue;
field |= TRB_IOC;
+ } else if (zero_length_needed && num_trbs == 1) {
+ trb_buff_len = 0;
}
/* Only set interrupt on short packet for IN endpoints */
@@ -3194,7 +3206,9 @@ int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t
mem_flags,
int num_trbs;
struct xhci_generic_trb *start_trb;
bool first_trb;
+ int last_trb;
bool more_trbs_coming;
+ bool zero_length_needed;
int start_cycle;
u32 field, length_field;
@@ -3225,7 +3239,14 @@ int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t
mem_flags,
num_trbs++;
running_total += TRB_MAX_BUFF_SIZE;
}
- /* FIXME: this doesn't deal with URB_ZERO_PACKET - need one more */
+
+ /* Deal with URB_ZERO_PACKET - need one more td/trb */
+ zero_length_needed = (urb->transfer_flags & URB_ZERO_PACKET)
+&& !(urb->transfer_buffer_length % usb_endpoint_maxp(>ep->desc));
+ if(zero_length_needed){
+ num_trbs++;
+ xhci_dbg(xhci, "Creating zero length td.\n");
+ }
ret = prepare_transfer(xhci, xhci->devs[slot_id],
ep_index, urb->stream_id,
@@ -3255,7 +3276,7 @@ int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t
mem_flags,
trb_buff_len = urb->transfer_buffer_length;
first_trb = true;
-
+ last_trb = zero_length_needed ? 2 : 1;
/* Queue the first TRB, even if it's zero-length */
do {
u32 remainder = 0;
@@ -3272,12 +3293,14 @@ int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t
mem_flags,
/* Chain all the TRBs together; clear the chain bit in the last
* TRB to indicate it's the last TRB in the chain.
*/
- if (num_trbs > 1) {
+
+ if (num_trbs > last_trb) {
field |= TRB_CHAIN;
- } else {
- /* FIXME - add check for ZERO_PACKET flag before this */
+ } else if (num_trbs == last_trb) {
td->last_trb = ep_ring->enqueue;
field |= TRB_IOC;
+ } else if (zero_length_needed && num_trbs == 1) {
+ trb_buff_len = 0;
}
/* Only set interrupt on short packet for IN endpoints */
@@ -3315,7 +3338,7 @@ int xhci_queue_bulk_tx(struct xhci_hcd
Re: [lkp] [usb] 56aa45adcc5: Fixed: WARNING: at kernel/mutex.c:199 mutex_lock_nested+0x121/0x349()
On Fri, 2015-06-26 at 11:01 -0500, Felipe Balbi wrote:
> Hi,
>
> On Fri, Jun 26, 2015 at 10:32:30AM +0800, Huang Ying wrote:
> > FYI, we noticed the below changes on
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > master
> > commit 56aa45adcc5b793369e535a4b7177f1c7314b577 ("usb: gadget: make
> > usb functions to load before gadget driver")
> >
> > This commit fixed an warning as below:
> >
> > [8.571726] [ cut here ]
> > [8.572786] WARNING: at kernel/mutex.c:199
> > mutex_lock_nested+0x121/0x349()
> > [8.572786] Hardware name: Standard PC (i440FX + PIIX, 1996)
> > [8.572786] Pid: 1, comm: swapper/0 Not tainted 3.9.0-rc1-6
> > -gfe2a429 #884
> > [8.572786] Call Trace:
> > [8.572786] [] warn_slowpath_common+0x77/0x91
> > [8.572786] [] warn_slowpath_null+0x15/0x17
> > [8.572786] [] mutex_lock_nested+0x121/0x349
> > [8.572786] [] ? sched_clock+0x9/0xd
> > [8.572786] [] ? sched_clock_local+0x11/0x78
> > [8.572786] [] ?
> > gserial_alloc_line+0x2a/0x1c0
> > [8.572786] [] gserial_alloc_line+0x2a/0x1c0
> > [8.572786] [] ?
> > gserial_alloc_line+0x2a/0x1c0
> > [8.572786] [] acm_ms_bind+0x2d/0x7ab
> > [8.572786] [] ? mutex_unlock+0x9/0xb
> > [8.572786] [] ? sysfs_addrm_finish+0x16/0x52
> > [8.572786] [] ?
> > sysfs_add_file_mode+0xa8/0xdc
> > [8.572786] [] ? sysfs_add_file+0xd/0xf
> > [8.572786] [] ? sysfs_create_file+0x23/0x25
> > [8.572786] [] ? device_create_file+0x14/0x16
> > [8.572786] [] ?
> > composite_dev_prepare+0xb0/0xe9
> > [8.572786] [] composite_bind+0x9c/0x166
> > [8.572786] [] ? m66592_probe+0x418/0x418
> > [8.572786] [] udc_bind_to_driver+0x25/0xa6
> > [8.572786] [] ? m66592_probe+0x418/0x418
> > [8.572786] []
> > usb_gadget_probe_driver+0x75/0x88
> > [8.572786] [] usb_composite_probe+0x8d/0x8f
> > [8.572786] [] init+0x10/0x12
> > [8.572786] [] do_one_initcall+0x7a/0x13d
> > [8.572786] []
> > kernel_init_freeable+0x178/0x1fb
> > [8.572786] [] ? rest_init+0xb7/0xb7
> > [8.572786] [] kernel_init+0x9/0xd1
> > [8.572786] [] ret_from_fork+0x7c/0xb0
> > [8.572786] [] ? rest_init+0xb7/0xb7
> > [8.572786] ---[ end trace 220a440ac161c663 ]---
>
> This warning is not available on your dmesg.xz
As I said above, the commit FIXED the warning as abvoe in
prev_dmesg.xz.
Best Regards,
Huang, Ying
> > #
> > # Automatically generated file; DO NOT EDIT.
> > # Linux/x86_64 3.9.0-rc1 Kernel Configuration
>
> 3.9 ??
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] HID: microsoft: Add quirk for MS Surface Type/Touch cover
The newer firmware on MS Surface 2 tablets causes the type and touch cover
keyboards to timeout when waiting for reports.
The quirk HID_QUIRK_NO_INIT_REPORTS allows them to function normally.
Signed-off-by: Reyad Attiyat
---
drivers/hid/usbhid/hid-quirks.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 4696895e..b0e0a8c 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -87,6 +87,9 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_MOUSE_C05A,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_MOUSE_C06A,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_MGE, USB_DEVICE_ID_MGE_UPS, HID_QUIRK_NOGET },
+ { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_SURFACE_PRO_2,
HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_2,
HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TOUCH_COVER_2,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_3,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_3_JP,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL,
HID_QUIRK_NO_INIT_REPORTS },
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH] regulator: Add lockdep asserts to help detecting locking misuse
Add lockdep_assert_held_once() to functions explicitly mentioning that
rdev or regulator_list mutex must be held. Using WARN_ONCE shouldn't
pollute the dmesg to much.
The patch (if CONFIG_LOCKDEP enabled) will show warnings in certain
regulators calling regulator_notifier_call_chain() without rdev->mutex
held.
Signed-off-by: Krzysztof Kozlowski
---
Resending because apparently the patch got lost. It was marked for
applying in June:
http://lkml.iu.edu/hypermail/linux/kernel/1506.1/02032.html
---
drivers/regulator/core.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index c9f72019bd68..68b616580533 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -640,6 +640,8 @@ static int drms_uA_update(struct regulator_dev *rdev)
int current_uA = 0, output_uV, input_uV, err;
unsigned int mode;
+ lockdep_assert_held_once(>mutex);
+
/*
* first check to see if we can set modes at all, otherwise just
* tell the consumer everything is OK.
@@ -760,6 +762,8 @@ static int suspend_set_state(struct regulator_dev *rdev,
/* locks held by caller */
static int suspend_prepare(struct regulator_dev *rdev, suspend_state_t state)
{
+ lockdep_assert_held_once(>mutex);
+
if (!rdev->constraints)
return -EINVAL;
@@ -1587,6 +1591,8 @@ static void _regulator_put(struct regulator *regulator)
if (regulator == NULL || IS_ERR(regulator))
return;
+ lockdep_assert_held_once(_list_mutex);
+
rdev = regulator->rdev;
debugfs_remove_recursive(regulator->debugfs);
@@ -1965,6 +1971,8 @@ static int _regulator_enable(struct regulator_dev *rdev)
{
int ret;
+ lockdep_assert_held_once(>mutex);
+
/* check voltage and requested load before enabling */
if (rdev->constraints &&
(rdev->constraints->valid_ops_mask & REGULATOR_CHANGE_DRMS))
@@ -2065,6 +2073,8 @@ static int _regulator_disable(struct regulator_dev *rdev)
{
int ret = 0;
+ lockdep_assert_held_once(>mutex);
+
if (WARN(rdev->use_count <= 0,
"unbalanced disables for %s\n", rdev_get_name(rdev)))
return -EIO;
@@ -2143,6 +2153,8 @@ static int _regulator_force_disable(struct regulator_dev
*rdev)
{
int ret = 0;
+ lockdep_assert_held_once(>mutex);
+
ret = _notifier_call_chain(rdev, REGULATOR_EVENT_FORCE_DISABLE |
REGULATOR_EVENT_PRE_DISABLE, NULL);
if (ret & NOTIFY_STOP_MASK)
@@ -3439,6 +3451,8 @@ EXPORT_SYMBOL_GPL(regulator_bulk_free);
int regulator_notifier_call_chain(struct regulator_dev *rdev,
unsigned long event, void *data)
{
+ lockdep_assert_held_once(>mutex);
+
_notifier_call_chain(rdev, event, data);
return NOTIFY_DONE;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] percpu-rwsem: don't use percpu_rw_semaphore->rw_sem to exclude writers
percpu_down_write() does down_write() to exclude both the readers and
other writers. We can rely on rcu_sync_enter() in exclusive mode and
take ->rw_sem right before wait_event().
Signed-off-by: Oleg Nesterov
---
kernel/locking/percpu-rwsem.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/kernel/locking/percpu-rwsem.c b/kernel/locking/percpu-rwsem.c
index 014d2f4..609c13b 100644
--- a/kernel/locking/percpu-rwsem.c
+++ b/kernel/locking/percpu-rwsem.c
@@ -139,8 +139,6 @@ static bool readers_active_check(struct percpu_rw_semaphore
*sem)
void percpu_down_write(struct percpu_rw_semaphore *sem)
{
- down_write(>rw_sem);
-
/* Notify readers to take the slow path. */
rcu_sync_enter(>rss);
@@ -158,6 +156,7 @@ void percpu_down_write(struct percpu_rw_semaphore *sem)
* therefore will wait for them.
*/
+ down_write(>rw_sem);
/* Wait for all now active readers to complete. */
wait_event(sem->writer, readers_active_check(sem));
}
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] percpu-rwsem: introduce percpu_rw_semaphore->recursive mode
Add percpu_rw_semaphore->recursive boolean. If it is true then the
recursive percpu_down_read() is safe, percpu_down_write() doesn't
exclude the new readers, like cpu_hotplug_begin().
Signed-off-by: Oleg Nesterov
---
include/linux/percpu-rwsem.h | 15 ++-
kernel/events/uprobes.c |2 +-
kernel/locking/percpu-rwsem.c | 15 +++
3 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/include/linux/percpu-rwsem.h b/include/linux/percpu-rwsem.h
index 9202e73..9441abd 100644
--- a/include/linux/percpu-rwsem.h
+++ b/include/linux/percpu-rwsem.h
@@ -13,16 +13,18 @@ struct percpu_rw_semaphore {
int state;
struct rcu_sync_struct rss;
wait_queue_head_t writer;
+ boolrecursive;
struct rw_semaphore rw_sem;
};
-#define DEFINE_STATIC_PERCPU_RWSEM(name) \
+#define DEFINE_STATIC_PERCPU_RWSEM(name, rec) \
static DEFINE_PER_CPU(unsigned int, __percpu_rwsem_refcount_##name); \
static struct percpu_rw_semaphore name = { \
.refcount = &__percpu_rwsem_refcount_##name,\
.state = 0, \
.rss = __RCU_SYNC_INITIALIZER(name.rss, RCU_SCHED_SYNC, 1), \
.writer = __WAIT_QUEUE_HEAD_INITIALIZER(name.writer), \
+ .recursive = rec, \
.rw_sem = __RWSEM_INITIALIZER(name.rw_sem), \
}
@@ -37,7 +39,10 @@ static inline void percpu_down_read(struct
percpu_rw_semaphore *sem)
{
might_sleep();
- rwsem_acquire_read(>rw_sem.dep_map, 0, 0, _RET_IP_);
+ if (sem->recursive)
+ rwlock_acquire_read(>rw_sem.dep_map, 0, 0, _RET_IP_);
+ else
+ rwsem_acquire_read(>rw_sem.dep_map, 0, 0, _RET_IP_);
preempt_disable();
/*
@@ -97,14 +102,14 @@ static inline void percpu_up_read(struct
percpu_rw_semaphore *sem)
extern void percpu_down_write(struct percpu_rw_semaphore *);
extern void percpu_up_write(struct percpu_rw_semaphore *);
-extern int __percpu_init_rwsem(struct percpu_rw_semaphore *,
+extern int __percpu_init_rwsem(struct percpu_rw_semaphore *, bool,
const char *, struct lock_class_key *);
extern void percpu_free_rwsem(struct percpu_rw_semaphore *);
-#define percpu_init_rwsem(sem) \
+#define percpu_init_rwsem(sem, recursive) \
({ \
static struct lock_class_key rwsem_key; \
- __percpu_init_rwsem(sem, #sem, _key); \
+ __percpu_init_rwsem(sem, recursive, #sem, _key); \
})
#endif
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index cb346f2..a4813a1 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1985,7 +1985,7 @@ static int __init init_uprobes(void)
for (i = 0; i < UPROBES_HASH_SZ; i++)
mutex_init(_mmap_mutex[i]);
- if (percpu_init_rwsem(_mmap_sem))
+ if (percpu_init_rwsem(_mmap_sem, false))
return -ENOMEM;
return register_die_notifier(_exception_nb);
diff --git a/kernel/locking/percpu-rwsem.c b/kernel/locking/percpu-rwsem.c
index 609c13b..3db7c45 100644
--- a/kernel/locking/percpu-rwsem.c
+++ b/kernel/locking/percpu-rwsem.c
@@ -10,7 +10,7 @@
enum { readers_slow, readers_block };
-int __percpu_init_rwsem(struct percpu_rw_semaphore *sem,
+int __percpu_init_rwsem(struct percpu_rw_semaphore *sem, bool recursive,
const char *name, struct lock_class_key *rwsem_key)
{
sem->refcount = alloc_percpu(unsigned int);
@@ -20,6 +20,7 @@ int __percpu_init_rwsem(struct percpu_rw_semaphore *sem,
sem->state = readers_slow;
rcu_sync_init(>rss, RCU_SCHED_SYNC, true);
init_waitqueue_head(>writer);
+ sem->recursive = recursive;
__init_rwsem(>rw_sem, name, rwsem_key);
return 0;
@@ -124,9 +125,15 @@ void __percpu_up_read(struct percpu_rw_semaphore *sem)
*/
static bool readers_active_check(struct percpu_rw_semaphore *sem)
{
- if (per_cpu_sum(*sem->refcount) != 0)
+ if (sem->recursive && !down_write_trylock(>rw_sem))
return false;
+ if (per_cpu_sum(*sem->refcount) != 0) {
+ if (sem->recursive)
+ up_write(>rw_sem);
+ return false;
+ }
+
/*
* If we observed the decrement; ensure we see the entire critical
* section.
@@ -155,8 +162,8 @@ void percpu_down_write(struct percpu_rw_semaphore *sem)
* then we are guaranteed to see their sem->refcount increment, and
* therefore will wait for them.
*/
-
- down_write(>rw_sem);
+ if (!sem->recursive)
+
[PATCH 0/3] percpu-rwsem: introduce percpu_rw_semaphore->recursive mode
On 06/24, Oleg Nesterov wrote: > > So we need percpu_down_write_dont_block_readers(). I already thought > about this before, I'll try to make the patch tomorrow on top of your > changes. Never say tomorrow... > This means that we do not need task_struct->cpuhp_ref, but we can't > avoid livelock we currently have: cpu_hotplug_begin() can never succeed > if the new readers come fast enough. Like with any other "recursive" lock. Peter, I know you don't like the 1st patch. And yes, we could add another mutex into percpu_rw_semaphore instead. But I think it would be better to rely on rcu_sync_enter(). As for completion, we can remove it later. Nevermind, the actual change is 3/3 and it looks simple. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] rcusync: introduce rcu_sync_struct->exclusive mode
Add rcu_sync_struct->exclusive boolean set by rcu_sync_init(), it
obviously controls the exclusiveness of rcu_sync_enter(). This is
what percpu_down_write() actually wants.
We turn ->gp_wait into "struct completion gp_comp", it is used as
a resource counter in "exclusive" mode. Otherwise we only use its
completion->wait member for wait_event/wake_up_all. We never mix
the completion/wait_queue_head_t operations.
TODO: we can cleanup this logic and avoid "struct completion", but
this needs a bit more changes.
Signed-off-by: Oleg Nesterov
---
include/linux/percpu-rwsem.h |2 +-
include/linux/rcusync.h | 29 -
kernel/locking/percpu-rwsem.c |2 +-
kernel/rcu/sync.c | 25 -
4 files changed, 38 insertions(+), 20 deletions(-)
diff --git a/include/linux/percpu-rwsem.h b/include/linux/percpu-rwsem.h
index e12ce86..9202e73 100644
--- a/include/linux/percpu-rwsem.h
+++ b/include/linux/percpu-rwsem.h
@@ -21,7 +21,7 @@ static DEFINE_PER_CPU(unsigned int,
__percpu_rwsem_refcount_##name); \
static struct percpu_rw_semaphore name = { \
.refcount = &__percpu_rwsem_refcount_##name,\
.state = 0, \
- .rss = __RCU_SYNC_INITIALIZER(name.rss, RCU_SCHED_SYNC),\
+ .rss = __RCU_SYNC_INITIALIZER(name.rss, RCU_SCHED_SYNC, 1), \
.writer = __WAIT_QUEUE_HEAD_INITIALIZER(name.writer), \
.rw_sem = __RWSEM_INITIALIZER(name.rw_sem), \
}
diff --git a/include/linux/rcusync.h b/include/linux/rcusync.h
index 0135838..aaea86a 100644
--- a/include/linux/rcusync.h
+++ b/include/linux/rcusync.h
@@ -1,7 +1,7 @@
#ifndef _LINUX_RCUSYNC_H_
#define _LINUX_RCUSYNC_H_
-#include
+#include
#include
enum rcu_sync_type { RCU_SYNC, RCU_SCHED_SYNC, RCU_BH_SYNC };
@@ -9,11 +9,12 @@ enum rcu_sync_type { RCU_SYNC, RCU_SCHED_SYNC, RCU_BH_SYNC };
struct rcu_sync_struct {
int gp_state;
int gp_count;
- wait_queue_head_t gp_wait;
+ struct completion gp_comp;
int cb_state;
struct rcu_head cb_head;
+ boolexclusive;
enum rcu_sync_type gp_type;
};
@@ -28,30 +29,32 @@ static inline bool rcu_sync_is_idle(struct rcu_sync_struct
*rss)
#endif
}
-extern void rcu_sync_init(struct rcu_sync_struct *, enum rcu_sync_type);
+extern void rcu_sync_init(struct rcu_sync_struct *,
+ enum rcu_sync_type, bool excl);
extern void rcu_sync_enter(struct rcu_sync_struct *);
extern void rcu_sync_exit(struct rcu_sync_struct *);
extern void rcu_sync_dtor(struct rcu_sync_struct *);
-#define __RCU_SYNC_INITIALIZER(name, type) { \
+#define __RCU_SYNC_INITIALIZER(name, type, excl) { \
.gp_state = 0, \
.gp_count = 0, \
- .gp_wait = __WAIT_QUEUE_HEAD_INITIALIZER(name.gp_wait), \
+ .gp_comp = COMPLETION_INITIALIZER(name.gp_comp),\
.cb_state = 0, \
+ .exclusive = excl, \
.gp_type = type,\
}
-#define__DEFINE_RCU_SYNC(name, type) \
- struct rcu_sync_struct name = __RCU_SYNC_INITIALIZER(name, type)
+#define__DEFINE_RCU_SYNC(name, type, excl) \
+ struct rcu_sync_struct name = __RCU_SYNC_INITIALIZER(name, type, excl)
-#define DEFINE_RCU_SYNC(name) \
- __DEFINE_RCU_SYNC(name, RCU_SYNC)
+#define DEFINE_RCU_SYNC(name, excl)\
+ __DEFINE_RCU_SYNC(name, RCU_SYNC, excl)
-#define DEFINE_RCU_SCHED_SYNC(name)\
- __DEFINE_RCU_SYNC(name, RCU_SCHED_SYNC)
+#define DEFINE_RCU_SCHED_SYNC(name, excl) \
+ __DEFINE_RCU_SYNC(name, RCU_SCHED_SYNC, excl)
-#define DEFINE_RCU_BH_SYNC(name) \
- __DEFINE_RCU_SYNC(name, RCU_BH_SYNC)
+#define DEFINE_RCU_BH_SYNC(name, excl) \
+ __DEFINE_RCU_SYNC(name, RCU_BH_SYNC, excl)
#endif /* _LINUX_RCUSYNC_H_ */
diff --git a/kernel/locking/percpu-rwsem.c b/kernel/locking/percpu-rwsem.c
index 915646c..014d2f4 100644
--- a/kernel/locking/percpu-rwsem.c
+++ b/kernel/locking/percpu-rwsem.c
@@ -18,7 +18,7 @@ int __percpu_init_rwsem(struct percpu_rw_semaphore *sem,
return -ENOMEM;
sem->state = readers_slow;
- rcu_sync_init(>rss, RCU_SCHED_SYNC);
+ rcu_sync_init(>rss, RCU_SCHED_SYNC, true);
init_waitqueue_head(>writer);
__init_rwsem(>rw_sem, name, rwsem_key);
diff --git a/kernel/rcu/sync.c b/kernel/rcu/sync.c
index 8835ad1..03ddc61 100644
--- a/kernel/rcu/sync.c
+++ b/kernel/rcu/sync.c
Re: [PATCH] drivers: net: xgene: Pre-initialize ret in xgene_enet_get_resources()
From: Geert Uytterhoeven
Date: Thu, 25 Jun 2015 15:13:29 +0200
> If CONFIG_ACPI=n:
>
> drivers/net/ethernet/apm/xgene/xgene_enet_main.c: In function
> ‘xgene_enet_get_resources’:
> drivers/net/ethernet/apm/xgene/xgene_enet_main.c:951: warning: ‘ret’ may
> be used uninitialized in this function
>
> If the driver is bound to a legacy platform device, ret will contain
> arbitrary data. If it is non-zero, it will be returned to the caller as
> an error code.
>
> Signed-off-by: Geert Uytterhoeven
Applied.
N§²ζμrΈyϊθΨb²X¬ΆΗ§vΨ^)ήΊ{.nΗ+·₯{±κηzX§Ά‘ά¨}©²Ζ
zΪ:+v¨Ύ«κηzZ+Κ+zf£’·h§~Ϋi�ϋΰzΉ �w₯’Έ?¨θΪ&’)ί’fω^jΗ«y§m
α@A«aΆΪ�
0Άμh�εi
Re: [PATCH] flow_dissector: Pre-initialize ip_proto in __skb_flow_dissect()
From: Geert Uytterhoeven Date: Thu, 25 Jun 2015 15:10:32 +0200 > net/core/flow_dissector.c: In function ‘__skb_flow_dissect’: > net/core/flow_dissector.c:132: warning: ‘ip_proto’ may be used uninitialized > in this function > > Signed-off-by: Geert Uytterhoeven Applied, thanks.
Re: [PATCH] xen-netfront: Remove the meaningless code
From: David Vrabel Date: Fri, 26 Jun 2015 16:15:18 +0100 > On 27/06/15 00:17, Liang Li wrote: >> The function netif_set_real_num_tx_queues() will return -EINVAL if >> the second parameter < 1, so call this function with the second >> parameter set to 0 is meaningless. > > Reviewed-by: David Vrabel Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] vfio: powerpc/spapr: One function call less in tce_iommu_attach_group() after kzalloc() failure
On 06/29/2015 02:24 AM, SF Markus Elfring wrote:
From: Markus Elfring
Date: Sun, 28 Jun 2015 17:58:42 +0200
The kfree() function was called even if a previous memory allocation
try failed.
tcegrp will be NULL and kfree() can handle this just fine (is not it the
whole point of this patchset - remove the check and just call kfree() even
if the pointer is NULL?). And if you wanted another label, than the
existing one should have been renamed to "free_exit" or "free_unlock_exit"
and new one would be "unlock_exit".
This implementation detail could be improved by the introduction
of another jump label.
Signed-off-by: Markus Elfring
---
drivers/vfio/vfio_iommu_spapr_tce.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c
b/drivers/vfio/vfio_iommu_spapr_tce.c
index 50ddfac..2523075 100644
--- a/drivers/vfio/vfio_iommu_spapr_tce.c
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -1200,7 +1200,7 @@ static int tce_iommu_attach_group(void *iommu_data,
tcegrp = kzalloc(sizeof(*tcegrp), GFP_KERNEL);
if (!tcegrp) {
ret = -ENOMEM;
- goto unlock_exit;
+ goto unlock_container;
}
if (!table_group->ops || !table_group->ops->take_ownership ||
@@ -1217,7 +1217,7 @@ static int tce_iommu_attach_group(void *iommu_data,
unlock_exit:
if (ret)
kfree(tcegrp);
-
+unlock_container:
mutex_unlock(>lock);
return ret;
--
Alexey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] HID: microsoft: Add quirk for MS Surface Type/Touch cover
This is missing a device ID I will need to resubmit
Sorry,
Reyad Attiyat
On Fri, Jun 26, 2015 at 1:00 AM, Reyad Attiyat wrote:
> The newer frimware on MS Surface 2 tablets causes the type and touch cover
> keyboards to timeout when waiting for reports.
>
> Signed-off-by: Reyad Attiyat
> ---
> drivers/hid/usbhid/hid-quirks.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
> index 4696895e..19c6f74 100644
> --- a/drivers/hid/usbhid/hid-quirks.c
> +++ b/drivers/hid/usbhid/hid-quirks.c
> @@ -87,6 +87,8 @@ static const struct hid_blacklist {
> { USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_MOUSE_C05A,
> HID_QUIRK_ALWAYS_POLL },
> { USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_MOUSE_C06A,
> HID_QUIRK_ALWAYS_POLL },
> { USB_VENDOR_ID_MGE, USB_DEVICE_ID_MGE_UPS, HID_QUIRK_NOGET },
> + { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_2,
> HID_QUIRK_NO_INIT_REPORTS },
> + { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TOUCH_COVER_2,
> HID_QUIRK_NO_INIT_REPORTS },
> { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_3,
> HID_QUIRK_NO_INIT_REPORTS },
> { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_3_JP,
> HID_QUIRK_NO_INIT_REPORTS },
> { USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL,
> HID_QUIRK_NO_INIT_REPORTS },
> --
> 2.4.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[no subject]
You have been pick for a donation contact: ( gloriamackenzi...@gmail.com ) for more details... Privacy and Confidentiality Notice: The information contained in this e-mail is intended for the named recipient(s) only. It may contain privileged and confidential information. If you are not an intended recipient, you must not copy, distribute or take any action in reliance on it. If you have received this e-mail in error, we would be grateful if you would notify us immediately. Thank you for your assistance. Please note that e-mails sent or received by our staff may be disclosed under the Freedom of Information Act (unless exempt). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] iio: magnetometer: Add support for MEMSIC MMC35240 sensor
Daniel Baluta schrieb am 24.04.2015 um 17:58:
> Minimal implementation for MMC35240 3-axis magnetometer
> sensor. It provides processed readings and possiblity to change
> the sampling frequency.
>
Hi Daniel,
please find a few issues inline, which you could address in a next
rework patch set. I would have sent a patch for the critical stuff,
but was obviously too stupid to find a data sheet :-(
> Signed-off-by: Daniel Baluta
> ---
> drivers/iio/magnetometer/Kconfig| 11 +
> drivers/iio/magnetometer/Makefile | 1 +
> drivers/iio/magnetometer/mmc35240.c | 468
>
> 3 files changed, 480 insertions(+)
> create mode 100644 drivers/iio/magnetometer/mmc35240.c
>
> diff --git a/drivers/iio/magnetometer/Kconfig
> b/drivers/iio/magnetometer/Kconfig
> index a5d6de7..7aba685 100644
> --- a/drivers/iio/magnetometer/Kconfig
> +++ b/drivers/iio/magnetometer/Kconfig
> @@ -47,6 +47,17 @@ config HID_SENSOR_MAGNETOMETER_3D
> Say yes here to build support for the HID SENSOR
> Magnetometer 3D.
>
> +config MMC35240
> + tristate "MEMSIC MMC35240 3-axis magnetic sensor"
> + select REGMAP_I2C
> + depends on I2C
> + help
> + Say yes here to build support for the MEMSIC MMC35240 3-axis
> + magnetic sensor.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called mmc35240.
> +
> config IIO_ST_MAGN_3AXIS
> tristate "STMicroelectronics magnetometers 3-Axis Driver"
> depends on (I2C || SPI_MASTER) && SYSFS
> diff --git a/drivers/iio/magnetometer/Makefile
> b/drivers/iio/magnetometer/Makefile
> index 0f5d3c9..696a429 100644
> --- a/drivers/iio/magnetometer/Makefile
> +++ b/drivers/iio/magnetometer/Makefile
> @@ -6,6 +6,7 @@
> obj-$(CONFIG_AK8975) += ak8975.o
> obj-$(CONFIG_MAG3110)+= mag3110.o
> obj-$(CONFIG_HID_SENSOR_MAGNETOMETER_3D) += hid-sensor-magn-3d.o
> +obj-$(CONFIG_MMC35240) += mmc35240.o
>
> obj-$(CONFIG_IIO_ST_MAGN_3AXIS) += st_magn.o
> st_magn-y := st_magn_core.o
> diff --git a/drivers/iio/magnetometer/mmc35240.c
> b/drivers/iio/magnetometer/mmc35240.c
> new file mode 100644
> index 000..beefebc
> --- /dev/null
> +++ b/drivers/iio/magnetometer/mmc35240.c
> @@ -0,0 +1,468 @@
> +/*
> + * MMC35240 - MEMSIC 3-axis Magnetic Sensor
> + *
> + * Copyright (c) 2015, Intel Corporation.
> + *
> + * This file is subject to the terms and conditions of version 2 of
> + * the GNU General Public License. See the file COPYING in the main
> + * directory of this archive for more details.
> + *
> + * IIO driver for MMC35240 (7-bit I2C slave address 0x30).
> + *
> + * TODO: offset, ACPI, continuous measurement mode, PM
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#define MMC35240_DRV_NAME "mmc35240"
> +#define MMC35240_REGMAP_NAME "mmc35240_regmap"
> +
> +#define MMC35240_REG_XOUT_L 0x00
> +#define MMC35240_REG_XOUT_H 0x01
> +#define MMC35240_REG_YOUT_L 0x02
> +#define MMC35240_REG_YOUT_H 0x03
> +#define MMC35240_REG_ZOUT_L 0x04
> +#define MMC35240_REG_ZOUT_H 0x05
> +
> +#define MMC35240_REG_STATUS 0x06
> +#define MMC35240_REG_CTRL0 0x07
> +#define MMC35240_REG_CTRL1 0x08
> +
> +#define MMC35240_REG_ID 0x20
> +
> +#define MMC35240_STATUS_MEAS_DONE_BITBIT(0)
> +
> +#define MMC35240_CTRL0_REFILL_BITBIT(7)
> +#define MMC35240_CTRL0_RESET_BIT BIT(6)
> +#define MMC35240_CTRL0_SET_BIT BIT(5)
> +#define MMC35240_CTRL0_CMM_BIT BIT(1)
> +#define MMC35240_CTRL0_TM_BITBIT(0)
It took me quite some time to figure out TM would stand for take measurement.
Still no clue about CMM (it's still not used from what I could see). Would be
great if you could comment them.
> +
> +/* output resolution bits */
> +#define MMC35240_CTRL1_BW0_BIT BIT(0)
> +#define MMC35240_CTRL1_BW1_BIT BIT(1)
> +
> +#define MMC35240_CTRL1_BW_MASK(MMC35240_CTRL1_BW0_BIT | \
> + MMC35240_CTRL1_BW1_BIT)
> +#define MMC35240_CTRL1_BW_SHIFT 0
> +
> +#define MMC35240_WAIT_CHARGE_PUMP5 /* us */
> +#define MMC53240_WAIT_SET_RESET 1000/* us */
> +
> +enum mmc35240_resolution {
> + MMC35240_16_BITS_SLOW = 0, /* 100 Hz */
> + MMC35240_16_BITS_FAST, /* 200 Hz */
> + MMC35240_14_BITS, /* 333 Hz */
> + MMC35240_12_BITS, /* 666 Hz */
> +};
> +
> +enum mmc35240_axis {
> + AXIS_X = 0,
> + AXIS_Y,
> + AXIS_Z,
> +};
> +
> +static const struct {
> + int sens[3]; /* sensitivity per X, Y, Z axis */
> + int nfo; /* null field output */
> +} mmc35240_props_table[] = {
> + /* 16 bits, 100Hz ODR */
> + {
> + {1024, 1024, 770},
> + 32768,
> + },
> + /* 16 bits, 200Hz ODR */
> + {
> + {1024, 1024, 770},
> + 32768,
> + },
> + /* 14 bits, 333Hz ODR */
> + {
> +
[git pull] m68knommu arch fixes for 4.2
Hi Linus, Can you please pull the m68knommu git tree, for-next branch. Only a couple of small changes. Improved the m68knommu MAINTAINERS entry to make it clearer which m68k parts this applies to, and a print format clean up. Regards Greg The following changes since commit 0f57d86787d8b1076ea8f9cba2a46d534a27: Linux 4.1-rc8 (2015-06-14 15:51:10 -1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-next for you to fetch changes up to e1632fa2471281c69bb3b6414d2c0fb01c56cc70: m68k: improve m68knommu MAINTAINERS entry (2015-06-19 17:22:17 +1000) Greg Ungerer (1): m68k: improve m68knommu MAINTAINERS entry Joe Perches (1): m68k: Use vsprintf %pM extension MAINTAINERS| 6 +- arch/m68k/68000/m68EZ328.c | 3 +-- arch/m68k/68000/m68VZ328.c | 3 +-- arch/m68k/68360/config.c | 3 +-- 4 files changed, 8 insertions(+), 7 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND] Bluetooth: btusb: Modify entry to support misc devices with BT interface
On 06/28/2015 04:49 PM, Xi Ruoyao wrote:
In the USB device table in btusb driver, the code specify a generic Bluetooth
device by matching Device Descriptor. However, some devices with BT interface
are classified as "Miscellaneous Device" and have different Device Descriptor,
such as Realtek RTL8723AU. Then btusb wouldn't probe them.
To resolve this, specify generic Bluetooth device in the USB device table by
matching Interface Descriptor, to probe all devices with Bluetooth interface
including these "Miscellaneous" ones.
Signed-off-by: Xi Ruoyao
---
The Bluetooth USB driver changed a lot since 4.1 released. However this problem
still exists now, so I think I should resend this patch.
I have now been able to get this patch tested through the repo at GitHub.com. My
testers concur that this allows the BT part of the RTL8723AU to load.
Acked-by: Larry Finger
Thanks,
Larry
After apply this patch, my RTL8723AU works well. This is the info of the
RTL8723AU
USB device:
T: Bus=03 Lev=02 Prnt=02 Port=03 Cnt=03 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0bda ProdID=1724 Rev= 2.00
S: Manufacturer=Realtek
S: Product=802.11n WLAN Adapter
S: SerialNumber=00e04c01
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=500mA
A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
drivers/bluetooth/btusb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index b4cf8d9..950afda 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -63,7 +63,7 @@ static struct usb_driver btusb_driver;
static const struct usb_device_id btusb_table[] = {
/* Generic Bluetooth USB device */
- { USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
+ { USB_INTERFACE_INFO(0xe0, 0x01, 0x01) },
/* Generic Bluetooth AMP device */
{ USB_DEVICE_INFO(0xe0, 0x01, 0x04), .driver_info = BTUSB_AMP },
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] [v3 0/7] Crystalcove (CRC) PMIC based panel and pwm control
[Re: [Intel-gfx] [v3 0/7] Crystalcove (CRC) PMIC based panel and pwm control] On 26/06/2015 (Fri 20:47) Ville Syrjälä wrote: > On Fri, Jun 26, 2015 at 06:31:37PM +0200, Daniel Vetter wrote: > > On Fri, Jun 26, 2015 at 02:32:03PM +0530, Shobhit Kumar wrote: > > > Hi, > > > Next update of the series reviewed at > > > https://lkml.org/lkml/2015/6/22/155 > > > > > > Major changes are few review comments from Varka and Ville being > > > addressed. Also except > > > for intel-gfx patches, all patches reviesion history is moved out of > > > commit message. > > > > > > Hope this series finally finds its mark. > > > > > > Regards > > > Shobhit > > > > > > Shobhit Kumar (7): > > > gpiolib: Add support for removing registered consumer lookup table > > > mfd: intel_soc_pmic_core: Add lookup table for Panel Control as GPIO > > > signal > > > mfd: intel_soc_pmic_crc: Add PWM cell device for Crystalcove PMIC > > > mfd: intel_soc_pmic_core: ADD PWM lookup table for CRC PMIC based PWM > > > pwm: crc: Add Crystalcove (CRC) PWM driver > > > drm/i915: Use the CRC gpio for panel enable/disable > > > drm/i915: Backlight control using CRC PMIC based PWM driver > > > > I think we have r-b/acks on all the patches now. Ok if I pull this in > > through drm-intel.git for 4.3? Or should I make a topic branch with tag > > and then send out pull requests to everyone? Or will each maintainer merge > > on their own since it's all only coupled at runtime anyway? Any of these > > would suit me. > > I forgot to mention that I had a build failure due to > builtin_platform_driver() when I tried this (just changed it to > module_platform_driver() to get past it). So I'm not sure if this > now depends on some tree which isn't included in -nightly... builtin_platform_register does not yet exist in mainline; as Paul (the other one) said earlier. So you can either open-code what it does for now, or use module_platform_register. If you do the latter, then ensure you (temorarily) also include module.h or you risk additional breakage in the future. Paul. -- > > -- > Ville Syrjälä > Intel OTC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LIBCFS_ALLOC
Yeah. You're right. Doing a vmalloc() when kmalloc() doesn't have even a tiny sliver of RAM isn't going to work. It's easier to use libcfs_kvzalloc() everywhere, but it's probably the wrong thing. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v2 2/3] tty: serial_core: Add hooks for uart slave drivers
Hi,
Some minor comments below.
On Sun, Jun 28, 2015 at 09:46:25PM +0200, Marek Belisko wrote:
> From: "H. Nikolaus Schaller"
>
> 1. allow drivers to get notified in mctrl changes
> 2. allow drivers to get notified on rx data (indicating to the driver that
>the connected chip is active)
>
> Signed-off-by: H. Nikolaus Schaller
> Signed-off-by: Marek Belisko
> ---
> drivers/tty/serial/serial_core.c | 102
> +--
> include/linux/serial_core.h | 11 -
> 2 files changed, 107 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/tty/serial/serial_core.c
> b/drivers/tty/serial/serial_core.c
> index ad61441..c8910c4 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -163,6 +163,84 @@ err0:
> }
> EXPORT_SYMBOL_GPL(devm_serial_get_uart_by_phandle);
>
> +void uart_register_slave(struct uart_port *uport, void *slave)
> +{
> + if (!slave) {
> + uart_register_mctrl_notification(uport, NULL);
> + uart_register_rx_notification(uport, NULL, NULL);
> + }
> + uport->slave = slave;
> +}
> +
> +void uart_register_mctrl_notification(struct uart_port *uport, int
> (*function)(void *slave, int state))
> +{
> + uport->mctrl_notification = function;
> +}
> +
> +static int uart_port_startup(struct tty_struct *tty, struct uart_state
> *state,
> + int init_hw);
> +
> +static void uart_port_shutdown(struct tty_port *port);
> +
> +void uart_register_rx_notification(struct uart_port *uport, int
> (*function)(void *slave, unsigned int *c), struct ktermios *termios)
> +{
> + struct uart_state *state = uport->state;
> + struct tty_port *tty_port = >port;
> +
> + if (!uport->slave)
> + return; /* slave must be registered first */
> +
> + uport->rx_notification = function;
> +
> + if (tty_port->count == 0) {
if (tty_port->count)
return;
> + if (function) {
> + int retval = 0;
Useless initialization.
> +
> + uart_change_pm(state, UART_PM_STATE_ON);
> + retval = uport->ops->startup(uport);
> + if (retval == 0 && termios) {
Indentation is evil in this rather simple function :)
> + int hw_stopped;
> + /*
> + * Initialise the hardware port settings.
> + */
> + uport->ops->set_termios(uport, termios, NULL);
> +
> + /*
> + * Set modem status enables based on termios
> cflag
> + */
> + spin_lock_irq(>lock);
> + if (termios->c_cflag & CRTSCTS)
> + uport->status |= UPSTAT_CTS_ENABLE;
> + else
> + uport->status &= ~UPSTAT_CTS_ENABLE;
> +
> + if (termios->c_cflag & CLOCAL)
> + uport->status &= ~UPSTAT_DCD_ENABLE;
> + else
> + uport->status |= UPSTAT_DCD_ENABLE;
> +
> + /* reset sw-assisted CTS flow control based on
> (possibly) new mode */
checkpatch.pl will complain about long line :)
> + hw_stopped = uport->hw_stopped;
> + uport->hw_stopped = uart_softcts_mode(uport) &&
> + !(uport->ops->get_mctrl(uport) &
> TIOCM_CTS);
> + if (uport->hw_stopped) {
> + if (!hw_stopped)
> + uport->ops->stop_tx(uport);
> + } else {
> + if (hw_stopped)
> + uport->ops->start_tx(uport);
> + }
> + spin_unlock_irq(>lock);
> + }
> + } else
Usage of braces is against CodingStyle.
> + uart_port_shutdown(tty_port);
> + }
> +}
> +
> +EXPORT_SYMBOL_GPL(uart_register_slave);
> +EXPORT_SYMBOL_GPL(uart_register_mctrl_notification);
> +EXPORT_SYMBOL_GPL(uart_register_rx_notification);
> +
> /*
> * This routine is used by the interrupt handler to schedule processing in
> * the software interrupt portion of the driver.
> @@ -220,6 +298,10 @@ uart_update_mctrl(struct uart_port *port, unsigned int
> set, unsigned int clear)
> port->mctrl = (old & ~clear) | set;
> if (old != port->mctrl)
> port->ops->set_mctrl(port, port->mctrl);
> +
> + if (port->mctrl_notification)
> + (*port->mctrl_notification)(port->slave, port->mctrl);
> +
> spin_unlock_irqrestore(>lock, flags);
> }
>
> @@ -259,7
[PATCH RESEND] Bluetooth: btusb: Modify entry to support misc devices with BT interface
In the USB device table in btusb driver, the code specify a generic Bluetooth
device by matching Device Descriptor. However, some devices with BT interface
are classified as "Miscellaneous Device" and have different Device Descriptor,
such as Realtek RTL8723AU. Then btusb wouldn't probe them.
To resolve this, specify generic Bluetooth device in the USB device table by
matching Interface Descriptor, to probe all devices with Bluetooth interface
including these "Miscellaneous" ones.
Signed-off-by: Xi Ruoyao
---
The Bluetooth USB driver changed a lot since 4.1 released. However this problem
still exists now, so I think I should resend this patch.
After apply this patch, my RTL8723AU works well. This is the info of the
RTL8723AU
USB device:
T: Bus=03 Lev=02 Prnt=02 Port=03 Cnt=03 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0bda ProdID=1724 Rev= 2.00
S: Manufacturer=Realtek
S: Product=802.11n WLAN Adapter
S: SerialNumber=00e04c01
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=500mA
A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
drivers/bluetooth/btusb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index b4cf8d9..950afda 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -63,7 +63,7 @@ static struct usb_driver btusb_driver;
static const struct usb_device_id btusb_table[] = {
/* Generic Bluetooth USB device */
- { USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
+ { USB_INTERFACE_INFO(0xe0, 0x01, 0x01) },
/* Generic Bluetooth AMP device */
{ USB_DEVICE_INFO(0xe0, 0x01, 0x04), .driver_info = BTUSB_AMP },
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hpfs: add fstrim support
On Sun, Jun 28, 2015 at 1:59 PM, Al Viro wrote: > > More to the point, why bother with ->ioctl() at all? Why not make > ->fitrim() a super_block method and let do_vfs_ioctl() handle all > marshalling? As in > (int *)fitrim(struct super_block *, struct fstrim_range *); > guaranteed to be called only on a filesystem kept active by caller... I'd be ok with that, but that's a bigger issue and I think would be a separate second step from removing the whole compat mess anyway. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v2 1/3] tty: serial core: provide method to search uart by phandle
Hi,
Some comments below.
On Sun, Jun 28, 2015 at 09:46:24PM +0200, Marek Belisko wrote:
> From: "H. Nikolaus Schaller"
>
> 1. add registered uart_ports to a search list
> 2. provide a function to search an uart_port by phandle. This copies the
>mechanism how devm_usb_get_phy_by_phandle() works
>
> Signed-off-by: H. Nikolaus Schaller
> Signed-off-by: Marek Belisko
> ---
> Documentation/serial/slaves.txt | 36 ++
> drivers/tty/serial/serial_core.c | 103
> +++
> include/linux/serial_core.h | 10
> 3 files changed, 149 insertions(+)
> create mode 100644 Documentation/serial/slaves.txt
>
> diff --git a/Documentation/serial/slaves.txt b/Documentation/serial/slaves.txt
> new file mode 100644
> index 000..6f8d44d
> --- /dev/null
> +++ b/Documentation/serial/slaves.txt
> @@ -0,0 +1,36 @@
> +UART slave device support
> +
> +A remote device connected to a RS232 interface is usually power controlled
> by the DTR line.
> +The DTR line is managed automatically by the UART driver for open() and
> close() syscalls
> +and on demand by tcsetattr().
> +
> +With embedded devices, the serial peripheral might be directly and always
> connected to the UART
> +and there might be no physical DTR line involved. Power control (on/off) has
> to be done by some
> +chip specific device driver (which we call "UART slave") through some
> mechanisms (I2C, GPIOs etc.)
> +not related to the serial interface. Some devices do not explicitly tell
> their power state except
> +by sending or not sending data to the UART. In such a case the device driver
> must be able to monitor
> +data activity. The role of the device driver is to encapsulate such power
> control in a single place.
> +
> +This patch series allows to support such drivers by providing:
> +* a mechanism that a slave driver can identify the UART instance it is
> connected to
> +* a mechanism that UART slave drivers can register to be notified
> +* notfications for DTR (and other modem control) state changes
> +* notifications that the UART has received some data from the UART
> +
> +A slave device simply adds a phandle reference to the UART it is connected
> to, e.g.
> +
> + gps {
> + compatible = "wi2wi,w2sg0004";
> + uart = <>;
> + };
> +
> +The slave driver calls devm_serial_get_uart_by_phandle() to identify the
> uart driver.
> +This API follows the concept of devm_usb_get_phy_by_phandle().
> +
> +A slave device driver registers itself with serial_register_slave() to
> receive notifications.
> +Notification handler callbacks can be registered by
> serial_register_mctrl_notification() and
> +serial_register_rx_notification(). If an UART has registered a NULL slave or
> a NULL handler,
> +no notifications are sent.
> +
> +RX notification handlers can define a ktermios during setup and the handler
> function can modify
> +or decide to throw away each character that is passed upwards.
> diff --git a/drivers/tty/serial/serial_core.c
> b/drivers/tty/serial/serial_core.c
> index eec067d..ad61441 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -38,6 +38,33 @@
> #include
> #include
>
> +static LIST_HEAD(uart_list);
> +static DEFINE_SPINLOCK(uart_lock);
> +
> +/* same concept as __of_usb_find_phy */
> +static struct uart_port *__of_serial_find_uart(struct device_node *node)
> +{
> + struct uart_port *uart;
> +
> + if (!of_device_is_available(node))
> + return ERR_PTR(-ENODEV);
> +
> + list_for_each_entry(uart, _list, head) {
> + if (node != uart->dev->of_node)
> + continue;
> +
> + return uart;
We can easily save three lines here :)
> + }
> +
> + return ERR_PTR(-EPROBE_DEFER);
> +}
> +
> +static void devm_serial_uart_release(struct device *dev, void *res)
> +{
> + struct uart_port *uart = *(struct uart_port **)res;
> + /* FIXME: serial_put_uart(uart); */
> +}
Looks unfinished...
> +
> /*
> * This is used to lock changes in serial line configuration.
> */
> @@ -64,6 +91,78 @@ static int uart_dcd_enabled(struct uart_port *uport)
> return !!(uport->status & UPSTAT_DCD_ENABLE);
> }
>
> +/**
> + * devm_serial_get_uart_by_phandle - find the uart by phandle
> + * @dev - device that requests this uart
> + * @phandle - name of the property holding the uart phandle value
> + * @index - the index of the uart
> + *
> + * Returns the uart_port associated with the given phandle value,
> + * after getting a refcount to it, -ENODEV if there is no such uart or
> + * -EPROBE_DEFER if there is a phandle to the uart, but the device is
> + * not yet loaded. While at that, it also associates the device with
> + * the uart using devres. On driver detach, release function is invoked
> + * on the devres data, then, devres data is freed.
Add -ENOMEM and -EINVAL, remove -EPROBE_DEFER?
> + *
> + * For use by tty host and
[PATCH] um: Fix out-of-tree build
Commit 30b11ee9a (um: Remove copy code from init.h) uncovered an issue wrt. out-of-tree builds. For out-of-tree builds, we must not rely on relative paths. Before 30b11ee9a it worked by chance as no host code included generated header files. Signed-off-by: Richard Weinberger --- arch/um/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/um/Makefile b/arch/um/Makefile index 098ab33..e3abe6f 100644 --- a/arch/um/Makefile +++ b/arch/um/Makefile @@ -70,8 +70,8 @@ KBUILD_AFLAGS += $(ARCH_INCLUDE) USER_CFLAGS = $(patsubst $(KERNEL_DEFINES),,$(patsubst -I%,,$(KBUILD_CFLAGS))) \ $(ARCH_INCLUDE) $(MODE_INCLUDE) $(filter -I%,$(CFLAGS)) \ - -D_FILE_OFFSET_BITS=64 -idirafter include \ - -D__KERNEL__ -D__UM_HOST__ + -D_FILE_OFFSET_BITS=64 -idirafter $(srctree)/include \ + -idirafter $(obj)/include -D__KERNEL__ -D__UM_HOST__ #This will adjust *FLAGS accordingly to the platform. include $(ARCH_DIR)/Makefile-os-$(OS) -- 1.8.4.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hpfs: add fstrim support
On Sun, Jun 28, 2015 at 12:52:11PM -0700, Linus Torvalds wrote:
> On Sun, Jun 28, 2015 at 6:16 AM, Mikulas Patocka
> wrote:
> > This patch adds support for fstrim to the HPFS filesystem.
> ...
> > +#ifdef CONFIG_COMPAT
> > + .compat_ioctl = hpfs_compat_ioctl,
> > +#endif
> ...
> > +#ifdef CONFIG_COMPAT
> > + .compat_ioctl = hpfs_compat_ioctl,
> > +#endif
> ...
> > +#ifdef CONFIG_COMPAT
> > +long hpfs_compat_ioctl(struct file *file, unsigned cmd, unsigned long arg)
> > +{
> > + return hpfs_ioctl(file, cmd, (unsigned long)compat_ptr(arg));
> > +}
> > +#endif
>
> Hmm. You've clearly copied this pattern from other filesystems, and so
> I can't really blame you, but this thing annoys me a lot.
>
> Why isn't FITRIM just marked as a COMPATIBLE_IOCTL(), at which point
> the generic ioctl layer will do exactly the above translation for us?
>
> Am I missing something?
More to the point, why bother with ->ioctl() at all? Why not make
->fitrim() a super_block method and let do_vfs_ioctl() handle all
marshalling? As in
(int *)fitrim(struct super_block *, struct fstrim_range *);
guaranteed to be called only on a filesystem kept active by caller...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug 100491] New: Oops under bitmap_start_sync [md_mod] at boot
On Thu, Jun 25, 2015 at 09:02:45PM +, bugzilla-dae...@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=100491 > > Bug ID: 100491 >Summary: Oops under bitmap_start_sync [md_mod] at boot [...] > Reading all physical valumes. This may take a while... > Found volume group "rootvg" using metadata type lvm2 > device-mapper: raid: Device 0 specified for rebuild: Clearing superblock > md/raid1:mdX: active with 1 out of 2 mirrors > mdX: invalid bitmap file superblock: bad magic > md-cluster module not found. > mdX: Could not setup cluster service (256) > BUG: unable to handle kernel NULL pointer dereference at 0100 > IP: [] _raw_spin_lock_irq+0x29/0x70 > PGD 0 > Oops: 0002 [#1] PREEMPT SMP [...] I'm marking this as a regression in bugzilla, since this seems to prevent booting on 4.1.0 at least in certain circumstances (namely those which I have; I wonder if any raid1 recovery works?) while 4.0.6 boots correctly. I bisected this down to one of four commits. Well, assuming that the problem was caused by changes in drivers/md; a fair assumption, I think. The commits are: $ git bisect view --oneline f9209a3 bitmap_create returns bitmap pointer 96ae923 Gather on-going resync information of other nodes 54519c5 Lock bitmap while joining the cluster b97e9257 Use separate bitmaps for each nodes in the cluster The crash happens whether or not CONFIG_MD_CLUSTER is enabled. Here's the versions I tested: git bisect start '--' 'drivers/md' # bad: [b953c0d234bc72e8489d3bf51a276c5c4ec85345] Linux 4.1 # good: [39a8804455fb23f09157341d3ba7db6d7ae6ee76] Linux 4.0 # bad: [9ffc8f7cb9647b13dfe4d1ad0d5e1427bb8b46d6] md/raid5: don't do chunk aligned read on degraded array. # bad: [6dc69c9c460b0cf05b5b3f323a8b944a2e52e76d] md: recover_bitmaps() can be static # bad: [4b26a08af92c0d9c0bce07612b56ff326112321a] Perform resync for cluster node failure # good: [cf921cc19cf7c1e99f730a2faa02d80817d684a2] Add node recovery callbacks # skip: [96ae923ab659e37dd5fc1e05ecbf654e2f94bcbe] Gather on-going resync information of other nodes # bad: [f9209a323547f054c7439a3bf67c45e64a054bdd] bitmap_create returns bitmap pointer # skip: [54519c5f4b398bcfe599f652b4ef4004d5fa63ff] Lock bitmap while joining the cluster Sami -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 1/2] serial_core: add pci uart early console support
On 06/08/2015 02:17 PM, Bin Gao wrote: > On some Intel Atom SoCs, the legacy IO port UART(0x3F8) is not available. > Instead, a 8250 compatible PCI uart can be used as early console. > This patch adds pci support to the 8250 early console driver uart8250. > For example, to enable pci uart(00:21.3) as early console on these > platforms, append the following line to the kernel command line > (assume baud rate is 115200): > earlyprintk=uart8250,pci32,0:24.2,115200n8 Reviewed-by: Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tty/vt: Fix the memory leak in visual_init
On 06/10/2015 03:21 AM, Dongxing Zhang wrote: > If vc->vc_uni_pagedir_loc is not NULL, its refcount needs to be > decreased before vc_uni_pagedir_loc is re-assigned. Reviewed-by: Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCv4 PATCH 00/34] sched: Energy cost model for energy-aware scheduling
Hi,
So I tried to play around a little bit with this patchset. I did a
checkout from:
git://linux-arm.org/linux-power.git energy_model_rfc_v4
and then, when I tried to enable the ENERGY_AWARE from sysfs inside
qemu (x86_64) and I got this:
[69452.750245] BUG: unable to handle kernel paging request at 88009d3fb958
[69452.750245] IP: [] try_to_wake_up+0x125/0x310
[69452.750245] PGD 2155067 PUD 0
[69452.750245] Oops: [#1] SMP
[69452.750245] Modules linked in:
[69452.750245] CPU: 0 PID: 1007 Comm: sh Not tainted 4.1.0-rc2+ #8
[69452.750245] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.8.1-20150318_183358- 04/01/2014
[69452.750245] task: 88007c9e5aa0 ti: 88007be0c000 task.ti:
88007be0c000
[69452.750245] RIP: 0010:[] []
try_to_wake_up+0x125/0x310
[69452.750245] RSP: :88007fc03d78 EFLAGS: 0092
[69452.750245] RAX: RBX: RCX: 00015a40
[69452.750245] RDX: 0001 RSI: RDI: 88007d005000
[69452.750245] RBP: 88007fc03dc8 R08: 0400 R09:
[69452.750245] R10: R11: R12: 00015a40
[69452.750245] R13: 88007d3fbdaa R14: R15: 88007d3fb660
[69452.750245] FS: 7f8a3c9f0700() GS:88007fc0()
knlGS:
[69452.750245] CS: 0010 DS: ES: CR0: 80050033
[69452.750245] CR2: 88009d3fb958 CR3: 7c32c000 CR4: 06f0
[69452.750245] DR0: DR1: DR2:
[69452.750245] DR3: DR6: DR7:
[69452.750245] Stack:
[69452.750245] 88007fc15aa8 88007c9e5b08 88007fc15aa8
0046
[69452.750245] 88007fc03e08 88007c83fe60 81e3c8a8
81e3c890
[69452.750245] 0003 88007fc03dd8
8107bb8d
[69452.750245] Call Trace:
[69452.750245]
[69452.750245] [] default_wake_function+0xd/0x10
[69452.750245] [] autoremove_wake_function+0x11/0x40
[69452.750245] [] __wake_up_common+0x55/0x90
[69452.750245] [] __wake_up+0x38/0x60
[69452.750245] [] rcu_gp_kthread_wake+0x42/0x50
[69452.750245] [] rcu_process_callbacks+0x2ef/0x5e0
[69452.750245] [] __do_softirq+0x9f/0x280
[69452.750245] [] irq_exit+0xa5/0xb0
[69452.750245] [] smp_apic_timer_interrupt+0x41/0x50
[69452.750245] [] apic_timer_interrupt+0x6b/0x70
[69452.750245]
[69452.750245] Code: 4c 89 ff ff d0 41 83 bf f8 02 00 00 01 41 8b 5f
48 7e 16 49 8b 47 60 89 de 44 89 f1 ba 10 00 00 00 4c 89 ff ff 50 40
89 c3 89 d8 <49> 0f a3 87 00 03 00 00 19 d2 85 d2 0f 84 59 01 00 00 48
8b 15
[69452.750245] RIP [] try_to_wake_up+0x125/0x310
[69452.750245] RSP
[69452.750245] CR2: 88009d3fb958
[69452.750245] ---[ end trace 9b4570a93c243e98 ]---
[69452.750245] Kernel panic - not syncing: Fatal exception in interrupt
[69452.750245] Kernel Offset: disabled
[69452.750245] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
and then I did a disassable from kgdb and I got this:
0x8107b8ae <+286>: callq *0x40(%rax)
0x8107b8b1 <+289>: mov%eax,%ebx
0x8107b8b3 <+291>: mov%ebx,%eax
0x8107b8b5 <+293>: bt %rax,0x300(%r15)
0x8107b8bd <+301>: sbb%edx,%edx
and then I did a objdump and got this:
static inline
int select_task_rq(struct task_struct *p, int cpu, int sd_flags, int wake_flags)
{
if (p->nr_cpus_allowed > 1)
7dcb: 7e 16 jle7de3
cpu = p->sched_class->select_task_rq(p, cpu, sd_flags,
wake_flags);
7dcd: 49 8b 47 60 mov0x60(%r15),%rax
7dd1: 89 de mov%ebx,%esi
7dd3: 44 89 f1mov%r14d,%ecx
7dd6: ba 10 00 00 00 mov$0x10,%edx
7ddb: 4c 89 ffmov%r15,%rdi
7dde: ff 50 40callq *0x40(%rax)
7de1: 89 c3 mov%eax,%ebx
7de3: 89 d8 mov%ebx,%eax
7de5: 49 0f a3 87 00 03 00bt %rax,0x300(%r15)
7dec: 00
7ded: 19 d2 sbb%edx,%edx
* Since this is common to all placement strategies, this lives here.
*
* [ this allows ->select_task() to simply return task_cpu(p) and
* not worry about this generic constraint ]
*/
if (unlikely(!cpumask_test_cpu(cpu, tsk_cpus_allowed(p)) ||
7def: 85 d2 test %edx,%edx
I wasn't able to determine the cause from the line:
7de5: 49 0f a3 87 00 03 00bt %rax,0x300(%r15)
Finally, the question I have is: Could this happen because I'm running
it from qemu?
I hope all this info helps.
Thanks,
Abel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info
Re: [RFC PATCH v3] arm DMA: Fix allocation from CMA for coherent DMA
On Fri, Jun 26, 2015 at 6:25 PM, Catalin Marinas
wrote:
> On Thu, Jun 18, 2015 at 11:44:22PM +0200, Lorenzo Nava wrote:
>> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
>> index 7e7583d..8e7f402 100644
>> --- a/arch/arm/mm/dma-mapping.c
>> +++ b/arch/arm/mm/dma-mapping.c
>> @@ -645,15 +645,29 @@ static void *__dma_alloc(struct device *dev, size_t
>> size, dma_addr_t *handle,
>> size = PAGE_ALIGN(size);
>> want_vaddr = !dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, attrs);
>>
>> - if (is_coherent || nommu())
>> + if (nommu()) {
>> addr = __alloc_simple_buffer(dev, size, gfp, );
>> - else if (!(gfp & __GFP_WAIT))
>> + goto dma_alloc_done;
>> + }
>> +
>> + if (dev_get_cma_area(dev) && (gfp & __GFP_WAIT)) {
>> + addr = __alloc_from_contiguous(dev, size, prot, ,
>> +caller, want_vaddr);
>> + goto dma_alloc_done;
>> + }
>> +
>> + if (is_coherent) {
>> + addr = __alloc_simple_buffer(dev, size, gfp, );
>> + goto dma_alloc_done;
>> + }
>> +
>> + if (!(gfp & __GFP_WAIT))
>> addr = __alloc_from_pool(size, );
>> - else if (!dev_get_cma_area(dev))
>> - addr = __alloc_remap_buffer(dev, size, gfp, prot, ,
>> caller, want_vaddr);
>> else
>> - addr = __alloc_from_contiguous(dev, size, prot, , caller,
>> want_vaddr);
>> + addr = __alloc_remap_buffer(dev, size, gfp, prot, ,
>> + caller, want_vaddr);
>>
>> +dma_alloc_done:
>> if (page)
>> *handle = pfn_to_dma(dev, page_to_pfn(page));
>
> The logic here looks alright but I would have preferred the original
> more concise "if ... else if" constructs than the gotos (just personal
> preference).
>
Ok, I can switch back to "if..else": I thought it was becoming too
difficult to read, but in the end the code looks good also with the
original style.
>> @@ -680,9 +694,14 @@ void *arm_dma_alloc(struct device *dev, size_t size,
>> dma_addr_t *handle,
>> static void *arm_coherent_dma_alloc(struct device *dev, size_t size,
>> dma_addr_t *handle, gfp_t gfp, struct dma_attrs *attrs)
>> {
>> - pgprot_t prot = __get_dma_pgprot(attrs, PAGE_KERNEL);
>> + pgprot_t prot;
>> void *memory;
>>
>> + if (attrs == NULL)
>> + prot = PAGE_KERNEL;
>> + else
>> + prot = __get_dma_pgprot(attrs, PAGE_KERNEL);
>> +
>> if (dma_alloc_from_coherent(dev, size, handle, ))
>> return memory;
>
> I still think this is the wrong way to fix. It doesn't address the
> coherent dma mmap operation. I already replied on the previous version
> that we should rather have an extra argument "coherent" to
> __get_dma_pgprot().
>
I avoided touching the __get_dma_pgprot() function because it affects
a lot of different functions.
If you think that the implementation you suggested in previous reply
was ok and doesn't introduce problems on the other functions using the
__get_dma_pgprot(), for me it's of course ok as well. Do you see any
code that maybe need a double check: I'm thinking, for example, at the
function arm_iommu_alloc_attrs() and arm_iommu_mmap_attrs()? I agree
with you that the extra argument in the __get_dma_pgprot() function is
definitely the best solution, but I have to be sure that this doesn't
affect any other functions with unexpected behaviour.
For the dma mmap there is still the patch "[PATCH v3]
arm/mm/dma-mapping.c: Add arm_coherent_dma_mmap" which corrects the
behaviour of mapped attributes and makes this version of patch ok.
>> @@ -735,12 +754,12 @@ static void __arm_dma_free(struct device *dev, size_t
>> size, void *cpu_addr,
>>
>> size = PAGE_ALIGN(size);
>>
>> - if (is_coherent || nommu()) {
>> + if (nommu()) {
>> __dma_free_buffer(page, size);
>> } else if (__free_from_pool(cpu_addr, size)) {
>> return;
>
> You have an unnecessary __free_from_pool() call here in the is_coherent
> case.
Ok, I'll fix it. Do you think that short-circuit evaluation can be
used here or it is better to use another solution?
>
>> } else if (!dev_get_cma_area(dev)) {
>> - if (want_vaddr)
>> + if (want_vaddr && !is_coherent)
>> __dma_free_remap(cpu_addr, size);
>> __dma_free_buffer(page, size);
>> } else {
>
> --
> Catalin
Thanks.
Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hpfs: add fstrim support
On Sun, Jun 28, 2015 at 6:16 AM, Mikulas Patocka wrote:
> This patch adds support for fstrim to the HPFS filesystem.
...
> +#ifdef CONFIG_COMPAT
> + .compat_ioctl = hpfs_compat_ioctl,
> +#endif
...
> +#ifdef CONFIG_COMPAT
> + .compat_ioctl = hpfs_compat_ioctl,
> +#endif
...
> +#ifdef CONFIG_COMPAT
> +long hpfs_compat_ioctl(struct file *file, unsigned cmd, unsigned long arg)
> +{
> + return hpfs_ioctl(file, cmd, (unsigned long)compat_ptr(arg));
> +}
> +#endif
Hmm. You've clearly copied this pattern from other filesystems, and so
I can't really blame you, but this thing annoys me a lot.
Why isn't FITRIM just marked as a COMPATIBLE_IOCTL(), at which point
the generic ioctl layer will do exactly the above translation for us?
Am I missing something?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC v2 2/3] tty: serial_core: Add hooks for uart slave drivers
From: "H. Nikolaus Schaller"
1. allow drivers to get notified in mctrl changes
2. allow drivers to get notified on rx data (indicating to the driver that
the connected chip is active)
Signed-off-by: H. Nikolaus Schaller
Signed-off-by: Marek Belisko
---
drivers/tty/serial/serial_core.c | 102 +--
include/linux/serial_core.h | 11 -
2 files changed, 107 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index ad61441..c8910c4 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -163,6 +163,84 @@ err0:
}
EXPORT_SYMBOL_GPL(devm_serial_get_uart_by_phandle);
+void uart_register_slave(struct uart_port *uport, void *slave)
+{
+ if (!slave) {
+ uart_register_mctrl_notification(uport, NULL);
+ uart_register_rx_notification(uport, NULL, NULL);
+ }
+ uport->slave = slave;
+}
+
+void uart_register_mctrl_notification(struct uart_port *uport, int
(*function)(void *slave, int state))
+{
+ uport->mctrl_notification = function;
+}
+
+static int uart_port_startup(struct tty_struct *tty, struct uart_state *state,
+ int init_hw);
+
+static void uart_port_shutdown(struct tty_port *port);
+
+void uart_register_rx_notification(struct uart_port *uport, int
(*function)(void *slave, unsigned int *c), struct ktermios *termios)
+{
+ struct uart_state *state = uport->state;
+ struct tty_port *tty_port = >port;
+
+ if (!uport->slave)
+ return; /* slave must be registered first */
+
+ uport->rx_notification = function;
+
+ if (tty_port->count == 0) {
+ if (function) {
+ int retval = 0;
+
+ uart_change_pm(state, UART_PM_STATE_ON);
+ retval = uport->ops->startup(uport);
+ if (retval == 0 && termios) {
+ int hw_stopped;
+ /*
+* Initialise the hardware port settings.
+*/
+ uport->ops->set_termios(uport, termios, NULL);
+
+ /*
+* Set modem status enables based on termios
cflag
+*/
+ spin_lock_irq(>lock);
+ if (termios->c_cflag & CRTSCTS)
+ uport->status |= UPSTAT_CTS_ENABLE;
+ else
+ uport->status &= ~UPSTAT_CTS_ENABLE;
+
+ if (termios->c_cflag & CLOCAL)
+ uport->status &= ~UPSTAT_DCD_ENABLE;
+ else
+ uport->status |= UPSTAT_DCD_ENABLE;
+
+ /* reset sw-assisted CTS flow control based on
(possibly) new mode */
+ hw_stopped = uport->hw_stopped;
+ uport->hw_stopped = uart_softcts_mode(uport) &&
+ !(uport->ops->get_mctrl(uport) &
TIOCM_CTS);
+ if (uport->hw_stopped) {
+ if (!hw_stopped)
+ uport->ops->stop_tx(uport);
+ } else {
+ if (hw_stopped)
+ uport->ops->start_tx(uport);
+ }
+ spin_unlock_irq(>lock);
+ }
+ } else
+ uart_port_shutdown(tty_port);
+ }
+}
+
+EXPORT_SYMBOL_GPL(uart_register_slave);
+EXPORT_SYMBOL_GPL(uart_register_mctrl_notification);
+EXPORT_SYMBOL_GPL(uart_register_rx_notification);
+
/*
* This routine is used by the interrupt handler to schedule processing in
* the software interrupt portion of the driver.
@@ -220,6 +298,10 @@ uart_update_mctrl(struct uart_port *port, unsigned int
set, unsigned int clear)
port->mctrl = (old & ~clear) | set;
if (old != port->mctrl)
port->ops->set_mctrl(port, port->mctrl);
+
+ if (port->mctrl_notification)
+ (*port->mctrl_notification)(port->slave, port->mctrl);
+
spin_unlock_irqrestore(>lock, flags);
}
@@ -259,7 +341,8 @@ static int uart_port_startup(struct tty_struct *tty, struct
uart_state *state,
uart_circ_clear(>xmit);
}
- retval = uport->ops->startup(uport);
+ if (!state->uart_port->rx_notification)
+ retval = uport->ops->startup(uport);
if (retval == 0) {
if (uart_console(uport) && uport->cons->cflag) {
tty->termios.c_cflag = uport->cons->cflag;
[PATCH RFC v2 3/3] misc: Add w2g0004 gps receiver driver
From: "H. Nikolaus Schaller"
Add driver for Wi2Wi w2g004 GPS module connected through uart. Use uart
slave + notification hooks to glue with tty.
Signed-off-by: H. Nikolaus Schaller
Signed-off-by: Marek Belisko
---
.../devicetree/bindings/misc/wi2wi,w2sg0004.txt| 18 +
drivers/misc/Kconfig | 18 +
drivers/misc/Makefile | 1 +
drivers/misc/w2sg0004.c| 436 +
include/linux/w2sg0004.h | 28 ++
5 files changed, 501 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
create mode 100644 drivers/misc/w2sg0004.c
create mode 100644 include/linux/w2sg0004.h
diff --git a/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
b/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
new file mode 100644
index 000..ef0d6d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
@@ -0,0 +1,18 @@
+Wi2Wi GPS module connected through UART
+
+Required properties:
+- compatible: wi2wi,w2sg0004 or wi2wi,w2sg0084
+- on-off-gpio: the GPIO that controls the module's on-off toggle input
+- uart: the uart we are connected to (provides DTR for power control)
+
+Optional properties:
+- lna-suppy: an (optional) LNA regulator that is enabled together with the GPS
receiver
+
+example:
+
+gps_receiver: w2sg0004 {
+compatible = "wi2wi,w2sg0004";
+lna-supply = <>; /* LNA regulator */
+on-off-gpio = < 17 0>; /* GPIO_145: trigger for
turning on/off w2sg0004 */
+uart = <>; /* we are a slave of uart1 */
+}
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 42c3852..952add4 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -527,4 +527,22 @@ source "drivers/misc/mic/Kconfig"
source "drivers/misc/genwqe/Kconfig"
source "drivers/misc/echo/Kconfig"
source "drivers/misc/cxl/Kconfig"
+
+menu "GTA04 misc hardware support"
+
+config W2SG0004
+ tristate "W2SG0004 on/off control"
+ depends on GPIOLIB
+ help
+ Enable on/off control of W2SG0004 GPS using a tty slave to
+ to allow powering up if the /dev/tty$n is opened.
+ It also provides a rfkill gps node to control the LNA power.
+
+config W2SG0004_DEBUG
+ bool "W2SG0004 on/off debugging"
+ depends on W2SG0004
+ help
+ Enable driver debugging mode of W2SG0004 GPS.
+
+endmenu
endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index d056fb7..3bc67c7 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -53,5 +53,6 @@ obj-$(CONFIG_SRAM)+= sram.o
obj-y += mic/
obj-$(CONFIG_GENWQE) += genwqe/
obj-$(CONFIG_ECHO) += echo/
+obj-$(CONFIG_W2SG0004) += w2sg0004.o
obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
obj-$(CONFIG_CXL_BASE) += cxl/
diff --git a/drivers/misc/w2sg0004.c b/drivers/misc/w2sg0004.c
new file mode 100644
index 000..c5f0f7b
--- /dev/null
+++ b/drivers/misc/w2sg0004.c
@@ -0,0 +1,436 @@
+/*
+ * w2sg0004.c
+ * Driver for power controlling the w2sg0004/w2sg0084 GPS receiver.
+ *
+ * This receiver has an ON/OFF pin which must be toggled to
+ * turn the device 'on' of 'off'. A high->low->high toggle
+ * will switch the device on if it is off, and off if it is on.
+ *
+ * To enable receiving on/off requests we register with the
+ * UART power management notifications.
+ *
+ * It is not possible to directly detect the state of the device.
+ * However when it is on it will send characters on a UART line
+ * regularly.
+ *
+ * To detect that the power state is out of sync (e.g. if GPS
+ * was enabled before a reboot), we register for UART data received
+ * notifications.
+ *
+ * In addition we register as a rfkill client so that we can
+ * control the LNA power.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifdef CONFIG_W2SG0004_DEBUG
+#undef pr_debug
+#define pr_debug printk
+#endif
+
+/*
+ * There seems to be restrictions on how quickly we can toggle the
+ * on/off line. data sheets says "two rtc ticks", whatever that means.
+ * If we do it too soon it doesn't work.
+ * So we have a state machine which uses the common work queue to ensure
+ * clean transitions.
+ * When a change is requested we record that request and only act on it
+ * once the previous change has completed.
+ * A change involves a 10ms low pulse, and a 990ms raised level, so only
+ * one change per second.
+ */
+
+enum w2sg_state {
+ W2SG_IDLE, /* is not changing state */
+ W2SG_PULSE, /* activate on/off impulse */
+ W2SG_NOPULSE/* deactivate on/off impulse */
+};
+
+struct w2sg_data {
+ struct rfkill *rf_kill;
+ struct
[PATCH RFC v2 1/3] tty: serial core: provide method to search uart by phandle
From: "H. Nikolaus Schaller"
1. add registered uart_ports to a search list
2. provide a function to search an uart_port by phandle. This copies the
mechanism how devm_usb_get_phy_by_phandle() works
Signed-off-by: H. Nikolaus Schaller
Signed-off-by: Marek Belisko
---
Documentation/serial/slaves.txt | 36 ++
drivers/tty/serial/serial_core.c | 103 +++
include/linux/serial_core.h | 10
3 files changed, 149 insertions(+)
create mode 100644 Documentation/serial/slaves.txt
diff --git a/Documentation/serial/slaves.txt b/Documentation/serial/slaves.txt
new file mode 100644
index 000..6f8d44d
--- /dev/null
+++ b/Documentation/serial/slaves.txt
@@ -0,0 +1,36 @@
+UART slave device support
+
+A remote device connected to a RS232 interface is usually power controlled by
the DTR line.
+The DTR line is managed automatically by the UART driver for open() and
close() syscalls
+and on demand by tcsetattr().
+
+With embedded devices, the serial peripheral might be directly and always
connected to the UART
+and there might be no physical DTR line involved. Power control (on/off) has
to be done by some
+chip specific device driver (which we call "UART slave") through some
mechanisms (I2C, GPIOs etc.)
+not related to the serial interface. Some devices do not explicitly tell their
power state except
+by sending or not sending data to the UART. In such a case the device driver
must be able to monitor
+data activity. The role of the device driver is to encapsulate such power
control in a single place.
+
+This patch series allows to support such drivers by providing:
+* a mechanism that a slave driver can identify the UART instance it is
connected to
+* a mechanism that UART slave drivers can register to be notified
+* notfications for DTR (and other modem control) state changes
+* notifications that the UART has received some data from the UART
+
+A slave device simply adds a phandle reference to the UART it is connected to,
e.g.
+
+ gps {
+ compatible = "wi2wi,w2sg0004";
+ uart = <>;
+ };
+
+The slave driver calls devm_serial_get_uart_by_phandle() to identify the uart
driver.
+This API follows the concept of devm_usb_get_phy_by_phandle().
+
+A slave device driver registers itself with serial_register_slave() to receive
notifications.
+Notification handler callbacks can be registered by
serial_register_mctrl_notification() and
+serial_register_rx_notification(). If an UART has registered a NULL slave or a
NULL handler,
+no notifications are sent.
+
+RX notification handlers can define a ktermios during setup and the handler
function can modify
+or decide to throw away each character that is passed upwards.
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index eec067d..ad61441 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -38,6 +38,33 @@
#include
#include
+static LIST_HEAD(uart_list);
+static DEFINE_SPINLOCK(uart_lock);
+
+/* same concept as __of_usb_find_phy */
+static struct uart_port *__of_serial_find_uart(struct device_node *node)
+{
+ struct uart_port *uart;
+
+ if (!of_device_is_available(node))
+ return ERR_PTR(-ENODEV);
+
+ list_for_each_entry(uart, _list, head) {
+ if (node != uart->dev->of_node)
+ continue;
+
+ return uart;
+ }
+
+ return ERR_PTR(-EPROBE_DEFER);
+}
+
+static void devm_serial_uart_release(struct device *dev, void *res)
+{
+ struct uart_port *uart = *(struct uart_port **)res;
+ /* FIXME: serial_put_uart(uart); */
+}
+
/*
* This is used to lock changes in serial line configuration.
*/
@@ -64,6 +91,78 @@ static int uart_dcd_enabled(struct uart_port *uport)
return !!(uport->status & UPSTAT_DCD_ENABLE);
}
+/**
+ * devm_serial_get_uart_by_phandle - find the uart by phandle
+ * @dev - device that requests this uart
+ * @phandle - name of the property holding the uart phandle value
+ * @index - the index of the uart
+ *
+ * Returns the uart_port associated with the given phandle value,
+ * after getting a refcount to it, -ENODEV if there is no such uart or
+ * -EPROBE_DEFER if there is a phandle to the uart, but the device is
+ * not yet loaded. While at that, it also associates the device with
+ * the uart using devres. On driver detach, release function is invoked
+ * on the devres data, then, devres data is freed.
+ *
+ * For use by tty host and peripheral drivers.
+ */
+
+/* same concept as devm_usb_get_phy_by_phandle() */
+
+struct uart_port *devm_serial_get_uart_by_phandle(struct device *dev,
+ const char *phandle, u8 index)
+{
+ struct uart_port *uart = ERR_PTR(-ENOMEM), **ptr;
+ unsigned long flags;
+ struct device_node *node;
+
+ if (!dev->of_node) {
+ dev_err(dev, "device does not have a device node entry\n");
+
[PATCH RFC v2 0/3] UART slave device support
Post RFC V2 (test on 4.1) as it seems that V1 wasn't sent properly.
Hi all,
this patch series is our proposal to add hooks so that the driver for a device
connected to an UART can
monitor modem control lines and data activity of the connected chip.
It contains an example for such a device driver which needs such sophisticated
power control: wi2wi,w2sg0004
A remote device connected to a RS232 interface is usually power controlled by
the DTR line.
The DTR line is managed automatically by the UART driver for open() and close()
syscalls
and on demand by tcsetattr().
With embedded devices, the serial peripheral might be directly and always
connected to the UART
and there might be no physical DTR line involved. Power control (on/off) has to
be done by some
chip specific device driver (which we call "UART slave") through some
mechanisms (I2C, GPIOs etc.)
not related to the serial interface. Some devices do not tell their power state
except by sending
or not sending data to the UART. In such a case the device driver must be able
to monitor data
activity. The role of the device driver is to encapsulate such power control in
a single place.
This patch series allows to support such UART slave drivers by providing:
* a mechanism that a slave driver can identify the UART instance it is
connected to
* a mechanism that UART slave drivers can register to be notified
* notfications for DTR (and other modem control) state changes
* notifications that the device has sent some data to the UART
A slave device tree entry simply adds a phandle reference to the UART it is
connected to, e.g.
gps {
compatible = "wi2wi,w2sg0004";
uart = <>;
};
The slave driver calls devm_serial_get_uart_by_phandle() to identify the uart
driver.
devm_serial_get_uart_by_phandle() follows the concept of
devm_usb_get_phy_by_phandle().
A slave device driver registers itself with serial_register_slave() to receive
notifications.
Notification handlers can be registered by serial_register_mctrl_notification()
and
serial_register_rx_notification(). If an UART has a NULL slave or a NULL
handler registered,
no notifications are sent.
RX notification handlers can define a ktermios setup and modify or decide to
throw away the
character that is passed upwards.
This all is a follow-up to the w2sg0004 driver submitted in 2014 that did want
to add an optional
GPIO to DTR in omap-serial.c and required the w2sg0004 driver to present itself
as a "virtual
GPIO". The idea of a "virtual GPIO" is not compatible with the concept that DT
must
describe hardware (and not virtual hardware). So in this new solution DT only
describes that
the w2sg0004 is connected to some UART and how the power state signalling works
is left
to the driver implementations.
The rx data notification also removes the concept of having two different
pinmux states
and make the w2sg0004 driver intercept rx activities by switching the rx line
to a GPIO
interrupt. This was very OMAP3 specific. The new solution is generic and might
even be
extensible that the chip driver could filter or consume the rx data before it
is passed
to the tty layer.
This patch works on linux-next as intended except one major weakness: we have
to call
uart_change_speed() each time we open the tty. This is the opposite of what we
would like
to have: that the slave initializes the uart speed through some termios and the
tty level just uses
this setting. We have not yet completely understood how to make this work and
are happy
about help in this area.
And of course we would like to see general comments about the whole
implementation
approach.
H. Nikolaus Schaller (3):
tty: serial core: provide method to search uart by phandle
tty: serial_core: Add hooks for uart slave drivers
misc: Add w2g0004 gps receiver driver
.../devicetree/bindings/misc/wi2wi,w2sg0004.txt| 18 +
Documentation/serial/slaves.txt| 36 ++
drivers/misc/Kconfig | 18 +
drivers/misc/Makefile | 1 +
drivers/misc/w2sg0004.c| 436 +
drivers/tty/serial/serial_core.c | 205 +-
include/linux/serial_core.h| 21 +-
include/linux/w2sg0004.h | 28 ++
8 files changed, 757 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
create mode 100644 Documentation/serial/slaves.txt
create mode 100644 drivers/misc/w2sg0004.c
create mode 100644 include/linux/w2sg0004.h
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] un-improve strrchr()
Joe Perches wrote:
> On Sun, 2015-06-28 at 19:44 +0300, Alexey Dobriyan wrote:
> > Commit 8da53d4595a53fb9a3380dd4d1c9bc24c7c9aab8
> > ("lib/string.c: improve strrchr()") changed strrchr() implementation
> > from "rewind to the end and search backwards" to "search forward"
> > optimizing for characher not found case. However, common case is exactly
> > the opposite: string is absolute pathname, c is '/' always to be found.
> >
> > Previous code did 1 branch per character + 1 branch for every character
> > in the last path component. Current code does 2 branches per characher
> > regardless.
>
> Are you comparing total cycles of all of the branches
> in the called functions too?
I'm comparing branches to branches. For strrchr() you don't need 2xN branches
even in theory. strlen() might even be optimized (gcc does have the impudence
to inline it's own CMPB version though).
> As written the current version removes the strlen call.
It does.
> > --- a/lib/string.c
> > +++ b/lib/string.c
> > @@ -313,12 +313,13 @@ EXPORT_SYMBOL(strchrnul);
> > */
> > char *strrchr(const char *s, int c)
> > {
> > - const char *last = NULL;
> > + const char *p = s + strlen(s);
> > +
> > do {
> > - if (*s == (char)c)
> > - last = s;
> > - } while (*s++);
> > - return (char *)last;
> > + if (*p == (char)c)
> > + return (char *)p;
> > + } while (--p >= s);
> > + return NULL;
> > }
> > EXPORT_SYMBOL(strrchr);
> > #endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: tegra: paz00: set gpiod_lookup table conn_id's
Commit 72daceb9a10a ("net: rfkill: gpio: Add default GPIO driver mappings
for ACPI") removed possibility to request GPIO by table index for non-ACPI
platforms without changing it users. As result "shutdown" GPIO request
will fail if request for "reset" GPIO succeeded or "reset" will be
requested instead of "shutdown" if "reset" wasn't defined. Fix it by
setting conn_id's in gpiod_lookup_table.
Signed-off-by: Dmitry Osipenko
Fixes: 72daceb (net: rfkill: gpio: Add default GPIO driver mappings for ACPI)
Cc: # v3.19+
---
arch/arm/mach-tegra/board-paz00.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-tegra/board-paz00.c
b/arch/arm/mach-tegra/board-paz00.c
index fbe74c6..67024f3 100644
--- a/arch/arm/mach-tegra/board-paz00.c
+++ b/arch/arm/mach-tegra/board-paz00.c
@@ -39,8 +39,8 @@ static struct platform_device wifi_rfkill_device = {
static struct gpiod_lookup_table wifi_gpio_lookup = {
.dev_id = "rfkill_gpio",
.table = {
- GPIO_LOOKUP_IDX("tegra-gpio", 25, NULL, 0, 0),
- GPIO_LOOKUP_IDX("tegra-gpio", 85, NULL, 1, 0),
+ GPIO_LOOKUP_IDX("tegra-gpio", 25, "reset", 0, 0),
+ GPIO_LOOKUP_IDX("tegra-gpio", 85, "shutdown", 1, 0),
{ },
},
};
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] gpu: host1x: Fix MLOCK's debug info
MLOCK's debug info, spewed on CDMA timeout, contains meaningless MLOCK
owner channel ID because HOST1X_SYNC_MLOCK_OWNER_CHID_F() returns shifted
value, while unshifted should be used. Fix it by changing '_F' to '_V'.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/host1x/hw/debug_hw.c | 2 +-
drivers/gpu/host1x/hw/hw_host1x01_sync.h | 8
drivers/gpu/host1x/hw/hw_host1x02_sync.h | 8
drivers/gpu/host1x/hw/hw_host1x04_sync.h | 8
4 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/host1x/hw/debug_hw.c b/drivers/gpu/host1x/hw/debug_hw.c
index 791de93..cc3f182 100644
--- a/drivers/gpu/host1x/hw/debug_hw.c
+++ b/drivers/gpu/host1x/hw/debug_hw.c
@@ -298,7 +298,7 @@ static void host1x_debug_show_mlocks(struct host1x *host,
struct output *o)
host1x_sync_readl(host, HOST1X_SYNC_MLOCK_OWNER(i));
if (HOST1X_SYNC_MLOCK_OWNER_CH_OWNS_V(owner))
host1x_debug_output(o, "%d: locked by channel %d\n",
- i, HOST1X_SYNC_MLOCK_OWNER_CHID_F(owner));
+ i, HOST1X_SYNC_MLOCK_OWNER_CHID_V(owner));
else if (HOST1X_SYNC_MLOCK_OWNER_CPU_OWNS_V(owner))
host1x_debug_output(o, "%d: locked by cpu\n", i);
else
diff --git a/drivers/gpu/host1x/hw/hw_host1x01_sync.h
b/drivers/gpu/host1x/hw/hw_host1x01_sync.h
index ac704e5..31238c2 100644
--- a/drivers/gpu/host1x/hw/hw_host1x01_sync.h
+++ b/drivers/gpu/host1x/hw/hw_host1x01_sync.h
@@ -131,12 +131,12 @@ static inline u32 host1x_sync_mlock_owner_r(unsigned int
id)
}
#define HOST1X_SYNC_MLOCK_OWNER(id) \
host1x_sync_mlock_owner_r(id)
-static inline u32 host1x_sync_mlock_owner_chid_f(u32 v)
+static inline u32 host1x_sync_mlock_owner_chid_v(u32 v)
{
- return (v & 0xf) << 8;
+ return (v >> 8) & 0xf;
}
-#define HOST1X_SYNC_MLOCK_OWNER_CHID_F(v) \
- host1x_sync_mlock_owner_chid_f(v)
+#define HOST1X_SYNC_MLOCK_OWNER_CHID_V(v) \
+ host1x_sync_mlock_owner_chid_v(v)
static inline u32 host1x_sync_mlock_owner_cpu_owns_v(u32 r)
{
return (r >> 1) & 0x1;
diff --git a/drivers/gpu/host1x/hw/hw_host1x02_sync.h
b/drivers/gpu/host1x/hw/hw_host1x02_sync.h
index 4495401..540c7b6 100644
--- a/drivers/gpu/host1x/hw/hw_host1x02_sync.h
+++ b/drivers/gpu/host1x/hw/hw_host1x02_sync.h
@@ -131,12 +131,12 @@ static inline u32 host1x_sync_mlock_owner_r(unsigned int
id)
}
#define HOST1X_SYNC_MLOCK_OWNER(id) \
host1x_sync_mlock_owner_r(id)
-static inline u32 host1x_sync_mlock_owner_chid_f(u32 v)
+static inline u32 host1x_sync_mlock_owner_chid_v(u32 v)
{
- return (v & 0xf) << 8;
+ return (v >> 8) & 0xf;
}
-#define HOST1X_SYNC_MLOCK_OWNER_CHID_F(v) \
- host1x_sync_mlock_owner_chid_f(v)
+#define HOST1X_SYNC_MLOCK_OWNER_CHID_V(v) \
+ host1x_sync_mlock_owner_chid_v(v)
static inline u32 host1x_sync_mlock_owner_cpu_owns_v(u32 r)
{
return (r >> 1) & 0x1;
diff --git a/drivers/gpu/host1x/hw/hw_host1x04_sync.h
b/drivers/gpu/host1x/hw/hw_host1x04_sync.h
index ef2275b..3d6c8ec 100644
--- a/drivers/gpu/host1x/hw/hw_host1x04_sync.h
+++ b/drivers/gpu/host1x/hw/hw_host1x04_sync.h
@@ -131,12 +131,12 @@ static inline u32 host1x_sync_mlock_owner_r(unsigned int
id)
}
#define HOST1X_SYNC_MLOCK_OWNER(id) \
host1x_sync_mlock_owner_r(id)
-static inline u32 host1x_sync_mlock_owner_chid_f(u32 v)
+static inline u32 host1x_sync_mlock_owner_chid_v(u32 v)
{
- return (v & 0xf) << 8;
+ return (v >> 8) & 0xf;
}
-#define HOST1X_SYNC_MLOCK_OWNER_CHID_F(v) \
- host1x_sync_mlock_owner_chid_f(v)
+#define HOST1X_SYNC_MLOCK_OWNER_CHID_V(v) \
+ host1x_sync_mlock_owner_chid_v(v)
static inline u32 host1x_sync_mlock_owner_cpu_owns_v(u32 r)
{
return (r >> 1) & 0x1;
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] tty: add missing rcu_read_lock for task_pgrp
Hi Patrick,
On 06/27/2015 08:51 PM, Patrick Donnelly wrote:
> task_pgrp requires an rcu or tasklist lock to be obtained if the returned pid
> is to be dereferenced, which kill_pgrp does. Obtain an RCU lock for the
> duration of use.
>
> Signed-off-by: Patrick Donnelly
> ---
> drivers/tty/tty_io.c | 24 +++-
> 1 file changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> index 57fc6ee..fbb55db 100644
> --- a/drivers/tty/tty_io.c
> +++ b/drivers/tty/tty_io.c
> @@ -388,33 +388,39 @@ EXPORT_SYMBOL_GPL(tty_find_polling_driver);
> int tty_check_change(struct tty_struct *tty)
> {
> unsigned long flags;
> + struct pid *pgrp;
> int ret = 0;
>
> if (current->signal->tty != tty)
> return 0;
>
> - spin_lock_irqsave(>ctrl_lock, flags);
> + rcu_read_lock();
> + pgrp = task_pgrp(current);
>
> + spin_lock_irqsave(>ctrl_lock, flags);
> if (!tty->pgrp) {
> printk(KERN_WARNING "tty_check_change: tty->pgrp == NULL!\n");
> - goto out_unlock;
> + goto out_irqunlock;
The label name changing is not really necessary and would reduce diff count.
It would be nice to get the printk() out from the locks as well (in a follow-on
patch?)
Regards,
Peter Hurley
> }
> - if (task_pgrp(current) == tty->pgrp)
> - goto out_unlock;
> + if (pgrp == tty->pgrp)
> + goto out_irqunlock;
> spin_unlock_irqrestore(>ctrl_lock, flags);
> +
> if (is_ignored(SIGTTOU))
> - goto out;
> + goto out_rcuunlock;
> if (is_current_pgrp_orphaned()) {
> ret = -EIO;
> - goto out;
> + goto out_rcuunlock;
> }
> - kill_pgrp(task_pgrp(current), SIGTTOU, 1);
> + kill_pgrp(pgrp, SIGTTOU, 1);
> + rcu_read_unlock();
> set_thread_flag(TIF_SIGPENDING);
> ret = -ERESTARTSYS;
> -out:
> return ret;
> -out_unlock:
> +out_irqunlock:
> spin_unlock_irqrestore(>ctrl_lock, flags);
> +out_rcuunlock:
> + rcu_read_unlock();
> return ret;
> }
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] tty: add missing rcu_read_lock for task_pgrp
On 06/28/2015 01:20 PM, Patrick Donnelly wrote: > On Sun, Jun 28, 2015 at 11:23 AM, Peter Hurley > wrote: >> On 06/27/2015 08:51 PM, Patrick Donnelly wrote: >>> task_pgrp requires an rcu or tasklist lock to be obtained if the returned >>> pid >>> is to be dereferenced, which kill_pgrp does. Obtain an RCU lock for the >>> duration of use. >> >> kill_pgrp() obtains tasklist_lock, so I don't see an unsafe deref. > > I see a race between looking up the pgrp via task_pgrp and passing it > to kill_pgrp. The pgrp struct pid may be freed via setpgid/setsid, as > mentioned in the comment for task_pgrp: > > * Without tasklist or rcu lock it is not safe to dereference > * the result of task_pgrp/task_session even if task == current, > * we can race with another thread doing sys_setsid/sys_setpgid. > > Getting the lock after the lookup is getting the lock too late. I > could be wrong though as I'm no expert on locking in Linux. I suppose it can't hurt; please add similar logic to job_control() in drivers/tty/n_tty.c which handles the corresponding SIGTTIN signal conditions. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 4/6] slim: qcom: Add Qualcomm Slimbus controller driver
On 6/17/2015 7:53 AM, Mark Brown wrote:
On Tue, Jun 16, 2015 at 07:46:02PM -0600, Sagar Dharia wrote:
+ - dmaengine, and pipes used to communicate between controller and memory if
+ sps-BAM HW is used
This needs more detail.
+*/
+ mb();
+ if (notify_rx)
+ complete(>rx_msgq_notify);
+ }
+ return IRQ_HANDLED;
This interrupt handler unconditionally returns IRQ_HANDLED regardless of
if that's true or not.
Some interrupt handling is done in ISR itself. RX-msgq thread
notifier/workQ is only used for items that can sleep/operations that can
take longer. (e.g. assignment of logical address based on report_present
message)
That's the reason IRQ_HANDLED is always true here.
+static void msm_slim_wait_retry(struct msm_slim_ctrl *dev)
+{
+ int msec_per_frm = 0;
+ int sfr_per_sec;
+
+ /* Wait for 1 superframe, or default time and then retry */
+ sfr_per_sec = dev->framer.superfreq /
+ (1 << (SLIM_MAX_CLK_GEAR - dev->ctrl.clkgear));
+ if (sfr_per_sec)
+ msec_per_frm = MSEC_PER_SEC / sfr_per_sec;
+ if (msec_per_frm < DEF_RETRY_MS)
+ msec_per_frm = DEF_RETRY_MS;
+ msleep(msec_per_frm);
+}
Is this device specific?
This is seen on most of the Qualcomm-controllers I've worked with, where
retries in early initialization were needed to avoid issues due to noise.
+static void msm_slim_cb(void *ctx, int err)
+{
+ if (err)
+ pr_err("MSM-slim completion reported err:%d\n", err);
dev_err()?
+ else if (ctx)
+ complete(ctx);
+}
That's weird, if we get an error we don't signal whatever's waiting -
won't it just time out at best then? Also, what happens if we get
neither an error nor context?
+ if (txn->msg->wbuf)
+ memcpy(puc, txn->msg->wbuf, txn->msg->num_bytes);
+ msm_slim_queue_tx(dev, pbuf, txn->rl, MGR_TX_MSG);
+ timeout = wait_for_completion_timeout(,
+ msecs_to_jiffies(txn->rl + 100));
+
+ if (!timeout)
+ dev_err(dev->dev, "TX timed out:MC:0x%x,mt:0x%x\n", txn->mc,
+ txn->mt);
+
+ mutex_unlock(>txn_lock);
+ return timeout ? 0 : -ETIMEDOUT;
+}
Shouldn't we provide a route for error reports here (and might some of
this timeout stuff go into the core)?
Sure, good point. If I move it to core, all controllers will be expected
to have 'write-done' notification. If that's a fair assumption, I will
move it to core.
That will also mean the above callback/completion will move to framework.
+
+ if ((msm_slim_put_rx(dev, (u8 *)buf)) != -ENODATA) {
+ len = buf[0] & 0x1F;
+ mt = (buf[0] >> 5) & 0x7;
+ mc = buf[1];
+ if (mt == SLIM_MSG_MT_CORE &&
+ mc == SLIM_MSG_MC_REPORT_PRESENT) {
Looks like a switch statement.
+static int msm_slim_rx_msgq_thread(void *data)
+{
+ struct msm_slim_ctrl *dev = (struct msm_slim_ctrl *)data;
+ struct completion *notify = >rx_msgq_notify;
+ int ret;
+
+ while (!kthread_should_stop()) {
+ set_current_state(TASK_INTERRUPTIBLE);
+ ret = wait_for_completion_interruptible(notify);
+
+ if (ret)
+ dev_err(dev->dev, "rx thread wait error:%d\n", ret);
+ else
+ msm_slim_rxwq(dev);
+ }
+
+ return 0;
+}
It's not entirely clear to me why this is a kthread rather than a
workqueue or something. I'm also unclear what happens if more than one
piece of work is queued prior to msm_slim_rxwq() running, it looks like
it only handles a single operation.
Sure, I will change this to workqueue. That should not be a problem.
+ /* SLEW RATE register for this slimbus */
+ dev->slew_mem = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+ "slimbus_slew_reg");
+ if (!dev->slew_mem) {
+ dev_err(>dev, "no slimbus slew resource\n");
+ return;
+ }
Warning not an error isn't it?
+ hclk = clk_get(>dev, "iface_clk");
+ if (IS_ERR(hclk))
+ return PTR_ERR(hclk);
devm_clk_get()
+ ret = clk_set_rate(rclk, SLIM_ROOT_FREQ);
You're ignoring this error in spite of assigning to ret.
+ slim_mem = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+ "slimbus_physical");
+ if (!slim_mem) {
+ dev_err(>dev, "no slimbus physical memory resource\n");
+ ret = ENODEV;
+ goto err_get_mem_failed;
+ }
+ slim_io = request_mem_region(slim_mem->start, resource_size(slim_mem),
+ pdev->name);
+ if (!slim_io) {
+ dev_err(>dev, "slimbus memory already claimed\n");
+
Re: [PATCH 3/6] ASoC: fsl_ssi: enable AC'97 asymmetric rates
W dniu 28.06.2015 16:01, Timur Tabi pisze:
> Maciej S. Szmigiero wrote:
>> /* Are the RX and the TX clocks locked? */
>> if (!of_find_property(np, "fsl,ssi-asynchronous", NULL)) {
>> -ssi_private->cpu_dai_drv.symmetric_rates = 1;
>> +if (!fsl_ssi_is_ac97(ssi_private))
>> +ssi_private->cpu_dai_drv.symmetric_rates = 1;
>> +
>
> Is this necessary? Why not just add fsl,ssi-asynchronous to the AC97 device
> tree node?
Because in the AC'97 mode the driver supports only one channel config and one
sample format
anyway the remaining settings controlled by this property don't do anything.
Since it should be safe to enable asymmetric rates with any AC'97 CODEC I think
it is good
to do it in driver than to add "fsl,ssi-asynchronous" to every AC'97 DT node.
Also the description of this property in fsl,ssi.txt looks like that it only
makes sense in
non-AC'97 mode.
Best regards,
Maciej Szmigiero
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] SCSI: DTC: Removed 0 initialization for statics
Removed unneccessary initialization of zero to a static variable
Signed-off-by: Rudhresh Kumar J
---
drivers/scsi/dtc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/dtc.c b/drivers/scsi/dtc.c
index 4c74c7b..99164d6 100644
--- a/drivers/scsi/dtc.c
+++ b/drivers/scsi/dtc.c
@@ -150,7 +150,7 @@ static const struct signature {
static int __init dtc_setup(char *str)
{
- static int commandline_current = 0;
+ static int commandline_current;
int i;
int ints[10];
@@ -188,7 +188,7 @@ __setup("dtc=", dtc_setup);
static int __init dtc_detect(struct scsi_host_template * tpnt)
{
- static int current_override = 0, current_base = 0;
+ static int current_override, current_base;
struct Scsi_Host *instance;
unsigned int addr;
void __iomem *base;
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:irq/urgent] avr32/at32ap: Fix race in installing chained IRQ handler
Around Fri 26 Jun 2015 12:47:18 -0700 or thereabout, tip-bot for Thomas
Gleixner wrote:
> avr32/at32ap: Fix race in installing chained IRQ handler
>
> Reported-by: Russell King
> Signed-off-by: Thomas Gleixner
> Cc: Julia Lawall
> Cc: Haavard Skinnemoen
> Cc: Hans-Christian Egtvedt
> ---
> arch/avr32/mach-at32ap/extint.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/avr32/mach-at32ap/extint.c b/arch/avr32/mach-at32ap/extint.c
> index cfb298d..2d48b6a 100644
> --- a/arch/avr32/mach-at32ap/extint.c
> +++ b/arch/avr32/mach-at32ap/extint.c
> @@ -231,8 +231,7 @@ static int __init eic_probe(struct platform_device *pdev)
> irq_set_chip_data(eic->first_irq + i, eic);
> }
>
> - irq_set_chained_handler(int_irq, demux_eic_irq);
> - irq_set_handler_data(int_irq, eic);
> + irq_set_chained_handler_and_data(int_irq, demux_eic_irq, eic);
>
> if (pdev->id == 0) {
> nmi_eic = eic;
Good fix, wil you pass it through your git tree, or would you prefer I add it
to the AVR32 tree? I have nothing in the pipe, hence feel free to add it to a
series if you are preparing fixes.
Acked-by: Hans-Christian Egtvedt
--
mvh
Hans-Christian Egtvedt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] un-improve strrchr()
On Sun, 2015-06-28 at 19:44 +0300, Alexey Dobriyan wrote:
> Commit 8da53d4595a53fb9a3380dd4d1c9bc24c7c9aab8
> ("lib/string.c: improve strrchr()") changed strrchr() implementation
> from "rewind to the end and search backwards" to "search forward"
> optimizing for characher not found case. However, common case is exactly
> the opposite: string is absolute pathname, c is '/' always to be found.
>
> Previous code did 1 branch per character + 1 branch for every character
> in the last path component. Current code does 2 branches per characher
> regardless.
Are you comparing total cycles of all of the branches
in the called functions too?
As written the current version removes the strlen call.
> --- a/lib/string.c
> +++ b/lib/string.c
> @@ -313,12 +313,13 @@ EXPORT_SYMBOL(strchrnul);
> */
> char *strrchr(const char *s, int c)
> {
> - const char *last = NULL;
> + const char *p = s + strlen(s);
> +
> do {
> - if (*s == (char)c)
> - last = s;
> - } while (*s++);
> - return (char *)last;
> + if (*p == (char)c)
> + return (char *)p;
> + } while (--p >= s);
> + return NULL;
> }
> EXPORT_SYMBOL(strrchr);
> #endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH REESEND 06/10] Drivers: hv: vmbus: prefer 'die' notification chain to 'panic'
From: Vitaly Kuznetsov
current_pt_regs() sometimes returns regs of the userspace process and in
case of a kernel crash this is not what we need to report. E.g. when we
trigger crash with sysrq we see the following:
...
RIP: 0010:[] []
sysrq_handle_crash+0x16/0x20
RSP: 0018:8800db0a7d88 EFLAGS: 00010246
RAX: 000f RBX: 820a0660 RCX:
...
at the same time current_pt_regs() give us:
ip=7f899ea7e9e0, ax=ffda, bx=26c81a0, cx=7f899ea7e9e0, ...
These registers come from the userspace process triggered the crash. As we
don't even know which process it was this information is rather useless.
When kernel crash happens through 'die' proper regs are being passed to
all receivers on the die_chain (and panic_notifier_list is being notified
with the string passed to panic() only). If panic() is called manually
(e.g. on BUG()) we won't get 'die' notification so keep the 'panic'
notification reporter as well but guard against double reporting.
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/vmbus_drv.c | 40
1 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 1ed9b32..b6114cc 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include "hyperv_vmbus.h"
static struct acpi_device *hv_acpi_dev;
@@ -48,12 +49,18 @@ static struct completion probe_event;
static int irq;
-static int hyperv_panic_event(struct notifier_block *nb,
- unsigned long event, void *ptr)
+static void hyperv_report_panic(struct pt_regs *regs)
{
- struct pt_regs *regs;
+ static bool panic_reported;
- regs = current_pt_regs();
+ /*
+* We prefer to report panic on 'die' chain as we have proper
+* registers to report, but if we miss it (e.g. on BUG()) we need
+* to report it on 'panic'.
+*/
+ if (panic_reported)
+ return;
+ panic_reported = true;
wrmsrl(HV_X64_MSR_CRASH_P0, regs->ip);
wrmsrl(HV_X64_MSR_CRASH_P1, regs->ax);
@@ -65,9 +72,32 @@ static int hyperv_panic_event(struct notifier_block *nb,
* Let Hyper-V know there is crash data available
*/
wrmsrl(HV_X64_MSR_CRASH_CTL, HV_CRASH_CTL_CRASH_NOTIFY);
+}
+
+static int hyperv_panic_event(struct notifier_block *nb, unsigned long val,
+ void *args)
+{
+ struct pt_regs *regs;
+
+ regs = current_pt_regs();
+
+ hyperv_report_panic(regs);
return NOTIFY_DONE;
}
+static int hyperv_die_event(struct notifier_block *nb, unsigned long val,
+ void *args)
+{
+ struct die_args *die = (struct die_args *)args;
+ struct pt_regs *regs = die->regs;
+
+ hyperv_report_panic(regs);
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block hyperv_die_block = {
+ .notifier_call = hyperv_die_event,
+};
static struct notifier_block hyperv_panic_block = {
.notifier_call = hyperv_panic_event,
};
@@ -842,6 +872,7 @@ static int vmbus_bus_init(int irq)
* Only register if the crash MSRs are available
*/
if (ms_hyperv.features & HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) {
+ register_die_notifier(_die_block);
atomic_notifier_chain_register(_notifier_list,
_panic_block);
}
@@ -1139,6 +1170,7 @@ static void __exit vmbus_exit(void)
tasklet_kill(_dpc);
vmbus_free_channels();
if (ms_hyperv.features & HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) {
+ unregister_die_notifier(_die_block);
atomic_notifier_chain_unregister(_notifier_list,
_panic_block);
}
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 08/10] Drivers: hv: fcopy: dynamically allocate smsg_out in fcopy_send_data()
From: Vitaly Kuznetsov
struct hv_start_fcopy is too big to be on stack on i386, the following
warning is reported:
>> drivers/hv/hv_fcopy.c:159:1: warning: the frame size of 1088 bytes is larger
>> than 1024 bytes [-Wframe-larger-than=]
Reported-by: kbuild test robot
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/hv_fcopy.c | 21 +
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/hv/hv_fcopy.c b/drivers/hv/hv_fcopy.c
index b50dd33..db4b887 100644
--- a/drivers/hv/hv_fcopy.c
+++ b/drivers/hv/hv_fcopy.c
@@ -116,7 +116,7 @@ static int fcopy_handle_handshake(u32 version)
static void fcopy_send_data(struct work_struct *dummy)
{
- struct hv_start_fcopy smsg_out;
+ struct hv_start_fcopy *smsg_out = NULL;
int operation = fcopy_transaction.fcopy_msg->operation;
struct hv_start_fcopy *smsg_in;
void *out_src;
@@ -136,21 +136,24 @@ static void fcopy_send_data(struct work_struct *dummy)
switch (operation) {
case START_FILE_COPY:
out_len = sizeof(struct hv_start_fcopy);
- memset(_out, 0, out_len);
- smsg_out.hdr.operation = operation;
+ smsg_out = kzalloc(sizeof(*smsg_out), GFP_KERNEL);
+ if (!smsg_out)
+ return;
+
+ smsg_out->hdr.operation = operation;
smsg_in = (struct hv_start_fcopy *)fcopy_transaction.fcopy_msg;
utf16s_to_utf8s((wchar_t *)smsg_in->file_name, W_MAX_PATH,
UTF16_LITTLE_ENDIAN,
- (__u8 *)_out.file_name, W_MAX_PATH - 1);
+ (__u8 *)_out->file_name, W_MAX_PATH - 1);
utf16s_to_utf8s((wchar_t *)smsg_in->path_name, W_MAX_PATH,
UTF16_LITTLE_ENDIAN,
- (__u8 *)_out.path_name, W_MAX_PATH - 1);
+ (__u8 *)_out->path_name, W_MAX_PATH - 1);
- smsg_out.copy_flags = smsg_in->copy_flags;
- smsg_out.file_size = smsg_in->file_size;
- out_src = _out;
+ smsg_out->copy_flags = smsg_in->copy_flags;
+ smsg_out->file_size = smsg_in->file_size;
+ out_src = smsg_out;
break;
default:
@@ -168,6 +171,8 @@ static void fcopy_send_data(struct work_struct *dummy)
fcopy_transaction.state = HVUTIL_READY;
}
}
+ kfree(smsg_out);
+
return;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 03/10] Drivers: hv: vmbus: add special kexec handler
From: Vitaly Kuznetsov
When general-purpose kexec (not kdump) is being performed in Hyper-V guest
the newly booted kernel fails with an MCE error coming from the host. It
is the same error which was fixed in the "Drivers: hv: vmbus: Implement
the protocol for tearing down vmbus state" commit - monitor pages remain
special and when they're being written to (as the new kernel doesn't know
these pages are special) bad things happen. We need to perform some
minimalistic cleanup before booting a new kernel on kexec. To do so we
need to register a special machine_ops.shutdown handler to be executed
before the native_machine_shutdown(). Registering a shutdown notification
handler via the register_reboot_notifier() call is not sufficient as it
happens to early for our purposes. machine_ops is not being exported to
modules (and I don't think we want to export it) so let's do this in
mshyperv.c
The minimalistic cleanup consists of cleaning up clockevents, synic MSRs,
guest os id MSR, and hypercall MSR.
Kdump doesn't require all this stuff as it lives in a separate memory
space.
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
---
arch/x86/include/asm/mshyperv.h |2 ++
arch/x86/kernel/cpu/mshyperv.c | 24
drivers/hv/vmbus_drv.c | 14 ++
3 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index c163215..d3db910 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -20,4 +20,6 @@ void hyperv_vector_handler(struct pt_regs *regs);
void hv_setup_vmbus_irq(void (*handler)(void));
void hv_remove_vmbus_irq(void);
+void hv_setup_kexec_handler(void (*handler)(void));
+void hv_remove_kexec_handler(void);
#endif
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 939155f..09911aa 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -28,10 +29,13 @@
#include
#include
#include
+#include
struct ms_hyperv_info ms_hyperv;
EXPORT_SYMBOL_GPL(ms_hyperv);
+static void (*hv_kexec_handler)(void);
+
#if IS_ENABLED(CONFIG_HYPERV)
static void (*vmbus_handler)(void);
@@ -69,8 +73,27 @@ void hv_remove_vmbus_irq(void)
}
EXPORT_SYMBOL_GPL(hv_setup_vmbus_irq);
EXPORT_SYMBOL_GPL(hv_remove_vmbus_irq);
+
+void hv_setup_kexec_handler(void (*handler)(void))
+{
+ hv_kexec_handler = handler;
+}
+EXPORT_SYMBOL_GPL(hv_setup_kexec_handler);
+
+void hv_remove_kexec_handler(void)
+{
+ hv_kexec_handler = NULL;
+}
+EXPORT_SYMBOL_GPL(hv_remove_kexec_handler);
#endif
+static void hv_machine_shutdown(void)
+{
+ if (kexec_in_progress && hv_kexec_handler)
+ hv_kexec_handler();
+ native_machine_shutdown();
+}
+
static uint32_t __init ms_hyperv_platform(void)
{
u32 eax;
@@ -143,6 +166,7 @@ static void __init ms_hyperv_init_platform(void)
no_timer_check = 1;
#endif
+ machine_ops.shutdown = hv_machine_shutdown;
}
const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 00d5158..31748a2 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1060,6 +1060,17 @@ static struct acpi_driver vmbus_acpi_driver = {
},
};
+static void hv_kexec_handler(void)
+{
+ int cpu;
+
+ hv_synic_clockevents_cleanup();
+ vmbus_initiate_unload();
+ for_each_online_cpu(cpu)
+ smp_call_function_single(cpu, hv_synic_cleanup, NULL, 1);
+ hv_cleanup();
+};
+
static int __init hv_acpi_init(void)
{
int ret, t;
@@ -1092,6 +1103,8 @@ static int __init hv_acpi_init(void)
if (ret)
goto cleanup;
+ hv_setup_kexec_handler(hv_kexec_handler);
+
return 0;
cleanup:
@@ -1104,6 +1117,7 @@ static void __exit vmbus_exit(void)
{
int cpu;
+ hv_remove_kexec_handler();
vmbus_connection.conn_state = DISCONNECTED;
hv_synic_clockevents_cleanup();
vmbus_disconnect();
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 02/10] kexec: define kexec_in_progress in !CONFIG_KEXEC case
From: Vitaly Kuznetsov
If some piece of code wants to check kexec_in_progress it has to be put
in #ifdef CONFIG_KEXEC block to not break the build in !CONFIG_KEXEC
case. Overcome this limitation by defining kexec_in_progress to false.
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
---
include/linux/kexec.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index e804306..b63218f 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -323,6 +323,7 @@ struct pt_regs;
struct task_struct;
static inline void crash_kexec(struct pt_regs *regs) { }
static inline int kexec_should_crash(struct task_struct *p) { return 0; }
+#define kexec_in_progress false
#endif /* CONFIG_KEXEC */
#endif /* !defined(__ASSEBMLY__) */
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 07/10] Drivers: hv: kvp: check kzalloc return value
From: Vitaly Kuznetsov kzalloc() return value check was accidentally lost in 11bc3a5fa91f: "Drivers: hv: kvp: convert to hv_utils_transport" commit. We don't need to reset kvp_transaction.state here as we have the kvp_timeout_func() timeout function and in case we're in OOM situation it is preferable to wait. Reported-by: Dan Carpenter Signed-off-by: Vitaly Kuznetsov Signed-off-by: K. Y. Srinivasan --- drivers/hv/hv_kvp.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c index d85798d..74c38a9 100644 --- a/drivers/hv/hv_kvp.c +++ b/drivers/hv/hv_kvp.c @@ -353,6 +353,9 @@ kvp_send_key(struct work_struct *dummy) return; message = kzalloc(sizeof(*message), GFP_KERNEL); + if (!message) + return; + message->kvp_hdr.operation = operation; message->kvp_hdr.pool = pool; in_msg = kvp_transaction.kvp_msg; -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 01/10] Drivers: hv: vmbus: remove hv_synic_free_cpu() call from hv_synic_cleanup()
From: Vitaly Kuznetsov We already have hv_synic_free() which frees all per-cpu pages for all CPUs, let's remove the hv_synic_free_cpu() call from hv_synic_cleanup() so it will be possible to do separate cleanup (writing to MSRs) and final freeing. This is going to be used to assist kexec. Signed-off-by: Vitaly Kuznetsov Signed-off-by: K. Y. Srinivasan --- drivers/hv/hv.c|2 -- drivers/hv/vmbus_drv.c |1 + 2 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c index d3943bc..5b87042 100644 --- a/drivers/hv/hv.c +++ b/drivers/hv/hv.c @@ -530,6 +530,4 @@ void hv_synic_cleanup(void *arg) rdmsrl(HV_X64_MSR_SCONTROL, sctrl.as_uint64); sctrl.enable = 0; wrmsrl(HV_X64_MSR_SCONTROL, sctrl.as_uint64); - - hv_synic_free_cpu(cpu); } diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c index cf20400..00d5158 100644 --- a/drivers/hv/vmbus_drv.c +++ b/drivers/hv/vmbus_drv.c @@ -1120,6 +1120,7 @@ static void __exit vmbus_exit(void) tasklet_kill(hv_context.event_dpc[cpu]); smp_call_function_single(cpu, hv_synic_cleanup, NULL, 1); } + hv_synic_free(); acpi_bus_unregister_driver(_acpi_driver); hv_cpu_hotplug_quirk(false); } -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 04/10] Drivers: hv: don't do hypercalls when hypercall_page is NULL
From: Vitaly Kuznetsov
At the very late stage of kexec a driver (which are not being unloaded) can
try to post a message or signal an event. This will crash the kernel as we
already did hv_cleanup() and the hypercall page is NULL.
Move all common (between 32 and 64 bit code) declarations to the beginning
of the do_hypercall() function. Unfortunately we have to write the
!hypercall_page check twice to not mix declarations and code.
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/hv.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index 5b87042..41d8072 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -93,11 +93,14 @@ static int query_hypervisor_info(void)
*/
static u64 do_hypercall(u64 control, void *input, void *output)
{
-#ifdef CONFIG_X86_64
- u64 hv_status = 0;
u64 input_address = (input) ? virt_to_phys(input) : 0;
u64 output_address = (output) ? virt_to_phys(output) : 0;
void *hypercall_page = hv_context.hypercall_page;
+#ifdef CONFIG_X86_64
+ u64 hv_status = 0;
+
+ if (!hypercall_page)
+ return (u64)ULLONG_MAX;
__asm__ __volatile__("mov %0, %%r8" : : "r" (output_address) : "r8");
__asm__ __volatile__("call *%3" : "=a" (hv_status) :
@@ -112,13 +115,13 @@ static u64 do_hypercall(u64 control, void *input, void
*output)
u32 control_lo = control & 0x;
u32 hv_status_hi = 1;
u32 hv_status_lo = 1;
- u64 input_address = (input) ? virt_to_phys(input) : 0;
u32 input_address_hi = input_address >> 32;
u32 input_address_lo = input_address & 0x;
- u64 output_address = (output) ? virt_to_phys(output) : 0;
u32 output_address_hi = output_address >> 32;
u32 output_address_lo = output_address & 0x;
- void *hypercall_page = hv_context.hypercall_page;
+
+ if (!hypercall_page)
+ return (u64)ULLONG_MAX;
__asm__ __volatile__ ("call *%8" : "=d"(hv_status_hi),
"=a"(hv_status_lo) : "d" (control_hi),
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 10/10] Drivers: hv: vmbus: Permit sending of packets without payload
The guest may have to send a completion packet back to the host. To support this usage, permit sending a packet without a payload - we would be only sending the descriptor in this case. Signed-off-by: K. Y. Srinivasan --- drivers/hv/channel.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c index 603ce97..c4dcab0 100644 --- a/drivers/hv/channel.c +++ b/drivers/hv/channel.c @@ -601,6 +601,7 @@ int vmbus_sendpacket_ctl(struct vmbus_channel *channel, void *buffer, u64 aligned_data = 0; int ret; bool signal = false; + int num_vecs = ((bufferlen != 0) ? 3 : 1); /* Setup the descriptor */ @@ -618,7 +619,8 @@ int vmbus_sendpacket_ctl(struct vmbus_channel *channel, void *buffer, bufferlist[2].iov_base = _data; bufferlist[2].iov_len = (packetlen_aligned - packetlen); - ret = hv_ringbuffer_write(>outbound, bufferlist, 3, ); + ret = hv_ringbuffer_write(>outbound, bufferlist, num_vecs, + ); /* * Signalling the host is conditional on many factors: -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 05/10] Drivers: hv: vmbus: add special crash handler
From: Vitaly Kuznetsov
Full kernel hang is observed when kdump kernel starts after a crash. This
hang happens in vmbus_negotiate_version() function on
wait_for_completion() as Hyper-V host (Win2012R2 in my testing) never
responds to CHANNELMSG_INITIATE_CONTACT as it thinks the connection is
already established. We need to perform some mandatory minimalistic
cleanup before we start new kernel.
Reported-by: K. Y. Srinivasan
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
---
arch/x86/include/asm/mshyperv.h |2 ++
arch/x86/kernel/cpu/mshyperv.c | 22 ++
drivers/hv/vmbus_drv.c | 14 ++
3 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index d3db910..d02f9c9 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -22,4 +22,6 @@ void hv_remove_vmbus_irq(void);
void hv_setup_kexec_handler(void (*handler)(void));
void hv_remove_kexec_handler(void);
+void hv_setup_crash_handler(void (*handler)(struct pt_regs *regs));
+void hv_remove_crash_handler(void);
#endif
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 09911aa..1a6e742 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -35,6 +35,7 @@ struct ms_hyperv_info ms_hyperv;
EXPORT_SYMBOL_GPL(ms_hyperv);
static void (*hv_kexec_handler)(void);
+static void (*hv_crash_handler)(struct pt_regs *regs);
#if IS_ENABLED(CONFIG_HYPERV)
static void (*vmbus_handler)(void);
@@ -85,6 +86,18 @@ void hv_remove_kexec_handler(void)
hv_kexec_handler = NULL;
}
EXPORT_SYMBOL_GPL(hv_remove_kexec_handler);
+
+void hv_setup_crash_handler(void (*handler)(struct pt_regs *regs))
+{
+ hv_crash_handler = handler;
+}
+EXPORT_SYMBOL_GPL(hv_setup_crash_handler);
+
+void hv_remove_crash_handler(void)
+{
+ hv_crash_handler = NULL;
+}
+EXPORT_SYMBOL_GPL(hv_remove_crash_handler);
#endif
static void hv_machine_shutdown(void)
@@ -94,6 +107,14 @@ static void hv_machine_shutdown(void)
native_machine_shutdown();
}
+static void hv_machine_crash_shutdown(struct pt_regs *regs)
+{
+ if (hv_crash_handler)
+ hv_crash_handler(regs);
+ native_machine_crash_shutdown(regs);
+}
+
+
static uint32_t __init ms_hyperv_platform(void)
{
u32 eax;
@@ -167,6 +188,7 @@ static void __init ms_hyperv_init_platform(void)
#endif
machine_ops.shutdown = hv_machine_shutdown;
+ machine_ops.crash_shutdown = hv_machine_crash_shutdown;
}
const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 31748a2..1ed9b32 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1071,6 +1071,18 @@ static void hv_kexec_handler(void)
hv_cleanup();
};
+static void hv_crash_handler(struct pt_regs *regs)
+{
+ vmbus_initiate_unload();
+ /*
+* In crash handler we can't schedule synic cleanup for all CPUs,
+* doing the cleanup for current CPU only. This should be sufficient
+* for kdump.
+*/
+ hv_synic_cleanup(NULL);
+ hv_cleanup();
+};
+
static int __init hv_acpi_init(void)
{
int ret, t;
@@ -1104,6 +1116,7 @@ static int __init hv_acpi_init(void)
goto cleanup;
hv_setup_kexec_handler(hv_kexec_handler);
+ hv_setup_crash_handler(hv_crash_handler);
return 0;
@@ -1118,6 +1131,7 @@ static void __exit vmbus_exit(void)
int cpu;
hv_remove_kexec_handler();
+ hv_remove_crash_handler();
vmbus_connection.conn_state = DISCONNECTED;
hv_synic_clockevents_cleanup();
vmbus_disconnect();
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 09/10] Drivers: hv: balloon: Enable dynamic memory protocol negotiation with Windows 10 hosts
From: Alex Ng
Support Win10 protocol for Dynamic Memory. Thia patch allows guests on Win10
hosts
to hot-add memory even when dynamic memory is not enabled on the guest.
Signed-off-by: Alex Ng
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/hv_balloon.c | 26 --
1 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 8a725cd..b853b4b 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -62,11 +62,13 @@
enum {
DYNMEM_PROTOCOL_VERSION_1 = DYNMEM_MAKE_VERSION(0, 3),
DYNMEM_PROTOCOL_VERSION_2 = DYNMEM_MAKE_VERSION(1, 0),
+ DYNMEM_PROTOCOL_VERSION_3 = DYNMEM_MAKE_VERSION(2, 0),
DYNMEM_PROTOCOL_VERSION_WIN7 = DYNMEM_PROTOCOL_VERSION_1,
DYNMEM_PROTOCOL_VERSION_WIN8 = DYNMEM_PROTOCOL_VERSION_2,
+ DYNMEM_PROTOCOL_VERSION_WIN10 = DYNMEM_PROTOCOL_VERSION_3,
- DYNMEM_PROTOCOL_VERSION_CURRENT = DYNMEM_PROTOCOL_VERSION_WIN8
+ DYNMEM_PROTOCOL_VERSION_CURRENT = DYNMEM_PROTOCOL_VERSION_WIN10
};
@@ -1296,13 +1298,25 @@ static void version_resp(struct hv_dynmem_device *dm,
if (dm->next_version == 0)
goto version_error;
- dm->next_version = 0;
memset(_req, 0, sizeof(struct dm_version_request));
version_req.hdr.type = DM_VERSION_REQUEST;
version_req.hdr.size = sizeof(struct dm_version_request);
version_req.hdr.trans_id = atomic_inc_return(_id);
- version_req.version.version = DYNMEM_PROTOCOL_VERSION_WIN7;
- version_req.is_last_attempt = 1;
+ version_req.version.version = dm->next_version;
+
+ /*
+* Set the next version to try in case current version fails.
+* Win7 protocol ought to be the last one to try.
+*/
+ switch (version_req.version.version) {
+ case DYNMEM_PROTOCOL_VERSION_WIN8:
+ dm->next_version = DYNMEM_PROTOCOL_VERSION_WIN7;
+ version_req.is_last_attempt = 0;
+ break;
+ default:
+ dm->next_version = 0;
+ version_req.is_last_attempt = 1;
+ }
ret = vmbus_sendpacket(dm->dev->channel, _req,
sizeof(struct dm_version_request),
@@ -1442,7 +1456,7 @@ static int balloon_probe(struct hv_device *dev,
dm_device.dev = dev;
dm_device.state = DM_INITIALIZING;
- dm_device.next_version = DYNMEM_PROTOCOL_VERSION_WIN7;
+ dm_device.next_version = DYNMEM_PROTOCOL_VERSION_WIN8;
init_completion(_device.host_event);
init_completion(_device.config_event);
INIT_LIST_HEAD(_device.ha_region_list);
@@ -1474,7 +1488,7 @@ static int balloon_probe(struct hv_device *dev,
version_req.hdr.type = DM_VERSION_REQUEST;
version_req.hdr.size = sizeof(struct dm_version_request);
version_req.hdr.trans_id = atomic_inc_return(_id);
- version_req.version.version = DYNMEM_PROTOCOL_VERSION_WIN8;
+ version_req.version.version = DYNMEM_PROTOCOL_VERSION_WIN10;
version_req.is_last_attempt = 0;
ret = vmbus_sendpacket(dev->channel, _req,
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 00/10] Drivers: hv: vmbus: Enable kexec and other misc cleanup
In addition to enabling kexec, this patch-set has a bunch of miscellaneous fixes. I have been having mail issues and hence resending the series. Alex Ng (1): Drivers: hv: balloon: Enable dynamic memory protocol negotiation with Windows 10 hosts K. Y. Srinivasan (1): Drivers: hv: vmbus: Permit sending of packets without payload Vitaly Kuznetsov (8): Drivers: hv: vmbus: remove hv_synic_free_cpu() call from hv_synic_cleanup() kexec: define kexec_in_progress in !CONFIG_KEXEC case Drivers: hv: vmbus: add special kexec handler Drivers: hv: don't do hypercalls when hypercall_page is NULL Drivers: hv: vmbus: add special crash handler Drivers: hv: vmbus: prefer 'die' notification chain to 'panic' Drivers: hv: kvp: check kzalloc return value Drivers: hv: fcopy: dynamically allocate smsg_out in fcopy_send_data() arch/x86/include/asm/mshyperv.h |4 ++ arch/x86/kernel/cpu/mshyperv.c | 46 ++ drivers/hv/channel.c|4 ++- drivers/hv/hv.c | 15 drivers/hv/hv_balloon.c | 26 +++--- drivers/hv/hv_fcopy.c | 21 +++ drivers/hv/hv_kvp.c |3 ++ drivers/hv/vmbus_drv.c | 69 -- include/linux/kexec.h |1 + 9 files changed, 163 insertions(+), 26 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE
-- I am Mrs. Gloria C. Mackenzie, the power-ball lottery winner and I have donated $2,000,000.00 USD to you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] tty: add missing rcu_read_lock for task_pgrp
On Sun, Jun 28, 2015 at 11:23 AM, Peter Hurley wrote: > On 06/27/2015 08:51 PM, Patrick Donnelly wrote: >> task_pgrp requires an rcu or tasklist lock to be obtained if the returned pid >> is to be dereferenced, which kill_pgrp does. Obtain an RCU lock for the >> duration of use. > > kill_pgrp() obtains tasklist_lock, so I don't see an unsafe deref. I see a race between looking up the pgrp via task_pgrp and passing it to kill_pgrp. The pgrp struct pid may be freed via setpgid/setsid, as mentioned in the comment for task_pgrp: * Without tasklist or rcu lock it is not safe to dereference * the result of task_pgrp/task_session even if task == current, * we can race with another thread doing sys_setsid/sys_setpgid. Getting the lock after the lookup is getting the lock too late. I could be wrong though as I'm no expert on locking in Linux. -- Patrick Donnelly -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH]drivers:staging:visorbus:Fix checkpatch warnings
This patch fixes checkpatch warnings
Signed-off-by: Ravi Teja Darbha
---
drivers/staging/unisys/visorbus/visorchipset.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/unisys/visorbus/visorchipset.c
b/drivers/staging/unisys/visorbus/visorchipset.c
index bb8087e..62f7f68 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -1410,8 +1410,8 @@ visorchipset_chipset_ready(void)
static int
visorchipset_chipset_selftest(void)
{
-char env_selftest[20];
-char *envp[] = { env_selftest, NULL };
+static char env_selftest[20];
+static const char * const envp[] = { env_selftest, NULL };
sprintf(env_selftest, "SPARSP_SELFTEST=%d", 1);
kobject_uevent_env(_platform_device.dev.kobj, KOBJ_CHANGE,
@@ -1559,9 +1559,9 @@ static void
parahotplug_request_kickoff(struct parahotplug_request *req)
{
struct controlvm_message_packet *cmd = >msg.cmd;
-char env_cmd[40], env_id[40], env_state[40], env_bus[40], env_dev[40],
-env_func[40];
-char *envp[] = {
+static char env_cmd[40], env_id[40], env_state[40], env_bus[40],
+env_dev[40], env_func[40];
+static const char * const envp[] = {
env_cmd, env_id, env_state, env_bus, env_dev, env_func, NULL
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] un-improve strrchr()
Commit 8da53d4595a53fb9a3380dd4d1c9bc24c7c9aab8
("lib/string.c: improve strrchr()") changed strrchr() implementation
from "rewind to the end and search backwards" to "search forward"
optimizing for characher not found case. However, common case is exactly
the opposite: string is absolute pathname, c is '/' always to be found.
Previous code did 1 branch per character + 1 branch for every character
in the last path component. Current code does 2 branches per characher
regardless.
Patch reverts to previous implementation (sans fixed coding style).
Signed-off-by: Alexey Dobriyan
---
Cc linux-kernel
lib/string.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
--- a/lib/string.c
+++ b/lib/string.c
@@ -313,12 +313,13 @@ EXPORT_SYMBOL(strchrnul);
*/
char *strrchr(const char *s, int c)
{
- const char *last = NULL;
+ const char *p = s + strlen(s);
+
do {
- if (*s == (char)c)
- last = s;
- } while (*s++);
- return (char *)last;
+ if (*p == (char)c)
+ return (char *)p;
+ } while (--p >= s);
+ return NULL;
}
EXPORT_SYMBOL(strrchr);
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] vfio: powerpc/spapr: One function call less in tce_iommu_attach_group() after kzalloc() failure
From: Markus Elfring
Date: Sun, 28 Jun 2015 17:58:42 +0200
The kfree() function was called even if a previous memory allocation
try failed.
This implementation detail could be improved by the introduction
of another jump label.
Signed-off-by: Markus Elfring
---
drivers/vfio/vfio_iommu_spapr_tce.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c
b/drivers/vfio/vfio_iommu_spapr_tce.c
index 50ddfac..2523075 100644
--- a/drivers/vfio/vfio_iommu_spapr_tce.c
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -1200,7 +1200,7 @@ static int tce_iommu_attach_group(void *iommu_data,
tcegrp = kzalloc(sizeof(*tcegrp), GFP_KERNEL);
if (!tcegrp) {
ret = -ENOMEM;
- goto unlock_exit;
+ goto unlock_container;
}
if (!table_group->ops || !table_group->ops->take_ownership ||
@@ -1217,7 +1217,7 @@ static int tce_iommu_attach_group(void *iommu_data,
unlock_exit:
if (ret)
kfree(tcegrp);
-
+unlock_container:
mutex_unlock(>lock);
return ret;
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] vfio: powerpc/spapr: Delete an unnecessary check before the function call "kfree"
From: Markus Elfring Date: Sun, 28 Jun 2015 17:43:48 +0200 The kfree() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/vfio/vfio_iommu_spapr_tce.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c b/drivers/vfio/vfio_iommu_spapr_tce.c index 0582b72..50ddfac 100644 --- a/drivers/vfio/vfio_iommu_spapr_tce.c +++ b/drivers/vfio/vfio_iommu_spapr_tce.c @@ -1215,7 +1215,7 @@ static int tce_iommu_attach_group(void *iommu_data, } unlock_exit: - if (ret && tcegrp) + if (ret) kfree(tcegrp); mutex_unlock(>lock); -- 2.4.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] vfio: powerpc/spapr: Deletion of an unnecessary check
From: Markus Elfring Another update suggestion was taken into account after a patch was applied from static source code analysis. Markus Elfring (2): Delete an unnecessary check before the function call "kfree" One function call less in tce_iommu_attach_group() after kzalloc() failure drivers/vfio/vfio_iommu_spapr_tce.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.4.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/3] restartable sequences: fast user-space percpu critical sections
- On Jun 27, 2015, at 12:25 PM, Andy Lutomirski l...@amacapital.net wrote: > Let me try to summarize some of the approaches with their pros and cons: > I can try summarizing a desiderata that I gather from this thread so far: - *very fast* accesses for per-cpu push/pop, per-cpu lock acquisition, and per-cpu counters, - guaranteed progress (don't loop forever when single-stepped), - critical section implementation flexibility: - can be written only in assembly or also in C, - provide a single building-block (e.g. cmpxchg) or allow applications/libraries to do arbitrary critical sections, - portability to non-x86 architectures, - low-intrusiveness for injection into applications (no signal handler, no segment selector used by pre-existing applications). - can be used by either a single or many shared objects per process, - don't disturb real-time scheduling, - minimal slowdown of kernel scheduling execution. More comments on each approach below: > --- percpu segment --- > > This is probably the simplest and might make sense regardless. > cmpxchg can be used to do an atomic push onto a linked list. I think > that unlocked cmpxchg16b can be used to get an atomic pop. (You'd > have the list head pointer next to an auxiliary pointer to the second > element in the list, perhaps.) Based on http://www.agner.org/optimize/instruction_tables.pdf On Intel Haswell: instruction latency (cycles) cmpxchg: 8 lock cmpxchg: 19 cmpxchg16b: 15 cmpxchg16b does not appear to be particularly fast (twice the latency of cmpxchg). > > You can also use this for limited forms of speculative locking. > Aborting cleanly if your lock is stolen might require the kernel's > help, though (you're now on the wrong cpu, so you can't atomically > poke the lock variable any more). > > The ABI is straightforward, and the only limitation on multiple users > in the same process is that they need to coordinate their offsets into > the percpu segment. One more downside about this approach: some applications already use the gs segment (AFAIK the wine emulator uses it), so can be prohibitive to use it from tracing code injected into pre-existing applications. Another downside is that it is x86-specific. > > --- vdso-provided atomic ops --- > > This could be quite flexible. The upside is that the ABI would be > straightforward (call a function with clearly-specified behavior). Following same ref as above, the call/ret pair alone would cost about 5 cycles. > The downside is that implementing it well might require percpu > segments and a certain amount of coordination, and it requires a > function call. Same downside as above about gs segment being already used by some applications. > > One nice thing about doing it in the vdso is that we can change the > implementation down the road. Yes, this is clearly an advantage over letting applications inline their cmpxchg on gs:. Same downside as above about being x86-specific. > > --- kernel preemption hooks --- > > I'm defining a preemption hook as an action taken by the kernel when a > user task is preempted during a critical section. > > As an upside, we get extremely efficient, almost arbitrary percpu > operations. We don't need to worry about memory ordering at all, > because the whole sequence aborts if anything else might run on the > same cpu. Push and pop are both easy. > > One con is that actually defining where the critical section is might > be nasty. If there's a single IP range, then two libraries could > fight over it. We could have a variable somewhere that you write to > arm the critical section, but that's a bit slower. My current understanding is that we have two means to tell the kernel "we are in a critical section": either through register content or through a per-thread memory area. Paul's implementation uses the instruction pointer, but it could perhaps use another reserved register state, which might help us do the critical functions in C code rather than assembly. It might be tricky to find a register that is guaranteed not to be used though, hence the per-thread memory area. The per-thread memory area has the advantage of allowing the critical sections to be implemented in C code rather than assembly, but, as you say, its downside is that we need at the very least to set/clear a TLS flag (or have a nesting counter) surrounding the critical section. This approach is quite similar to preempt_disable()/preempt_enable() in the Linux kernel. Another advantage of preempt migration hooks over migration hooks is that the critical section can assume it has mutually exclusive access, which is not the case for migration hooks, because it can be preempted and continue execution afterward. This means what can be achieved with e.g. "load+test+store" with preempt hook needs to be performed with "cmpxchg" with migration hooks. This might not be a huge issue for x86, but can become more expensive on other architectures. >
Re: [4.1.0-07254-gc13c810] Regression: Bluetooth not working.
On Sun, Jun 28, 2015 at 05:36:04PM +0200, Jörg Otte wrote: > 2015-06-26 16:28 GMT+02:00 Jörg Otte : > > 2015-06-26 12:03 GMT+02:00 Jörg Otte : > >> 2015-06-26 11:37 GMT+02:00 Marcel Holtmann : > >>> Hi Joerg, > >>> > Bluetooth is inoperable in current Linus tree and the > first bad commit is: > > 835a6a2f8603237a3e6cded5a6765090ecb06ea5 is the first bad commit > commit 835a6a2f8603237a3e6cded5a6765090ecb06ea5 > Author: Alexey Dobriyan > Date: Wed Jun 10 20:28:33 2015 +0300 > > Bluetooth: Stop sabotaging list poisoning > > list_del() poisons pointers with special values, no need to overwrite > them. > > Signed-off-by: Alexey Dobriyan > Signed-off-by: Marcel Holtmann > > My BT adapter is an intel 8087:07da > I reverted that commit and this fixed the problem for me. > >>> > >>> today we had a patch from Tedd fixing the list initialization in the HIDP > >>> code. > >>> > >>> diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c > >>> index 9070dfd6b4ad..f1a117f8cad2 100644 > >>> --- a/net/bluetooth/hidp/core.c > >>> +++ b/net/bluetooth/hidp/core.c > >>> @@ -915,6 +915,7 @@ static int hidp_session_new(struct hidp_session > >>> **out, const bdaddr_t *bdaddr, > >>> session->conn = l2cap_conn_get(conn); > >>> session->user.probe = hidp_session_probe; > >>> session->user.remove = hidp_session_remove; > >>> + INIT_LIST_HEAD(>user.list); > >>> session->ctrl_sock = ctrl_sock; > >>> session->intr_sock = intr_sock; > >>> skb_queue_head_init(>ctrl_transmit); > >>> > >>> Could this be fixing it for you as well? > >>> > >> I will check this when I am at home in the > >> afternoon. > >> > > > > The patch works for me too. > > > Ok, this was a little bit hasty! > I now see the following additional problems: > > - System freeze on resume (occures always). > - System freeze on shutdown (occures sometimes) > - System freeze when BT-mouse is connecting (occures sometimes). > > Then I can't do anything except power off. > > This happens only if Bluetooth AND BT-mouse is activated. OK, what happens if you just revert only list_del patch? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] tty: check tcsetpgrp p is a process group
On 06/27/2015 08:51 PM, Patrick Donnelly wrote: > This fixes a bug where a process can set the foreground process group to its > pid even if its pid is not a valid pgrp. > > Signed-off-by: Patrick Donnelly > --- > drivers/tty/tty_io.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c > index fbb55db..01b4769 100644 > --- a/drivers/tty/tty_io.c > +++ b/drivers/tty/tty_io.c > @@ -2579,6 +2579,9 @@ static int tiocspgrp(struct tty_struct *tty, struct > tty_struct *real_tty, pid_t > retval = -ESRCH; > if (!pgrp) > goto out_unlock; > + retval = -EINVAL; > + if (!pid_task(pgrp, PIDTYPE_PGID)) > + goto out_unlock; This change implies that the sequence in session_of_pgrp() that specifically checks for pid_task(pgrp, PIDTYPE_PGID) == NULL is not doing anything useful. However, that hypothesis is directly contradicted by the comment above session_of_pgrp() "* This checks not only the pgrp, but falls back on the pid if no * satisfactory pgrp is found. I dunno - gdb doesn't work correctly * without this..." Regards, Peter Hurley > retval = -EPERM; > if (session_of_pgrp(pgrp) != task_session(current)) > goto out_unlock; > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [all better] Re: regression: massive trouble with fpu rework
On Sun, 2015-06-28 at 12:06 -0300, Henrique de Moraes Holschuh wrote: > On Sun, 28 Jun 2015, Mike Galbraith wrote: > > > > > > BIOS setting "Limit CPUID Maximum" upsets new fpu code mightily. > > > > > > Well, it is supposed to disable CPUID levels >= 0x04. This thing should > > > *NEVER* be enabled, the last operating system that required it to be > > > enabled > > > was Windows 98. > > > > > > Can/do we override that crap during cpu init? If we cannot/don't, maybe > > > instead of limping along with CPUID crippled, it would be better to either > > > output a very nasty warning, or outright stop booting [with an appropriate > > > error message] ? > > > > Why get all upset? We didn't even notice before, nor did/does that > > other OS. A casual "BTW, your BIOS sucks.." should suffice, no? > > Oh, I am not upset, although I suppose my reply did look like it. Sorry > about that. I didn't mean you personally of course, I meant the kernel ;-) > It is just that this kind of breakage should not be subtle if we can help > it, because people will use a crippled system for years without noticing... If you can use it without noticing for years, it ain't crippled, or? My point being that severity seems more akin to the box having a zit behind its left ear, in which case lobotomizing it seems a tad extreme. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4.1.0-07254-gc13c810] Regression: Bluetooth not working.
2015-06-26 16:28 GMT+02:00 Jörg Otte : > 2015-06-26 12:03 GMT+02:00 Jörg Otte : >> 2015-06-26 11:37 GMT+02:00 Marcel Holtmann : >>> Hi Joerg, >>> Bluetooth is inoperable in current Linus tree and the first bad commit is: 835a6a2f8603237a3e6cded5a6765090ecb06ea5 is the first bad commit commit 835a6a2f8603237a3e6cded5a6765090ecb06ea5 Author: Alexey Dobriyan Date: Wed Jun 10 20:28:33 2015 +0300 Bluetooth: Stop sabotaging list poisoning list_del() poisons pointers with special values, no need to overwrite them. Signed-off-by: Alexey Dobriyan Signed-off-by: Marcel Holtmann My BT adapter is an intel 8087:07da I reverted that commit and this fixed the problem for me. >>> >>> today we had a patch from Tedd fixing the list initialization in the HIDP >>> code. >>> >>> diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c >>> index 9070dfd6b4ad..f1a117f8cad2 100644 >>> --- a/net/bluetooth/hidp/core.c >>> +++ b/net/bluetooth/hidp/core.c >>> @@ -915,6 +915,7 @@ static int hidp_session_new(struct hidp_session **out, >>> const bdaddr_t *bdaddr, >>> session->conn = l2cap_conn_get(conn); >>> session->user.probe = hidp_session_probe; >>> session->user.remove = hidp_session_remove; >>> + INIT_LIST_HEAD(>user.list); >>> session->ctrl_sock = ctrl_sock; >>> session->intr_sock = intr_sock; >>> skb_queue_head_init(>ctrl_transmit); >>> >>> Could this be fixing it for you as well? >>> >> I will check this when I am at home in the >> afternoon. >> > > The patch works for me too. > Ok, this was a little bit hasty! I now see the following additional problems: - System freeze on resume (occures always). - System freeze on shutdown (occures sometimes) - System freeze when BT-mouse is connecting (occures sometimes). Then I can't do anything except power off. This happens only if Bluetooth AND BT-mouse is activated. Thanks, Jörg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] tty: add missing rcu_read_lock for task_pgrp
On 06/27/2015 08:51 PM, Patrick Donnelly wrote:
> task_pgrp requires an rcu or tasklist lock to be obtained if the returned pid
> is to be dereferenced, which kill_pgrp does. Obtain an RCU lock for the
> duration of use.
kill_pgrp() obtains tasklist_lock, so I don't see an unsafe deref.
> Signed-off-by: Patrick Donnelly
> ---
> drivers/tty/tty_io.c | 24 +++-
> 1 file changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> index 57fc6ee..fbb55db 100644
> --- a/drivers/tty/tty_io.c
> +++ b/drivers/tty/tty_io.c
> @@ -388,33 +388,39 @@ EXPORT_SYMBOL_GPL(tty_find_polling_driver);
> int tty_check_change(struct tty_struct *tty)
> {
> unsigned long flags;
> + struct pid *pgrp;
> int ret = 0;
>
> if (current->signal->tty != tty)
> return 0;
>
> - spin_lock_irqsave(>ctrl_lock, flags);
> + rcu_read_lock();
> + pgrp = task_pgrp(current);
>
> + spin_lock_irqsave(>ctrl_lock, flags);
> if (!tty->pgrp) {
> printk(KERN_WARNING "tty_check_change: tty->pgrp == NULL!\n");
> - goto out_unlock;
> + goto out_irqunlock;
> }
> - if (task_pgrp(current) == tty->pgrp)
> - goto out_unlock;
> + if (pgrp == tty->pgrp)
> + goto out_irqunlock;
> spin_unlock_irqrestore(>ctrl_lock, flags);
> +
> if (is_ignored(SIGTTOU))
> - goto out;
> + goto out_rcuunlock;
> if (is_current_pgrp_orphaned()) {
> ret = -EIO;
> - goto out;
> + goto out_rcuunlock;
> }
> - kill_pgrp(task_pgrp(current), SIGTTOU, 1);
> + kill_pgrp(pgrp, SIGTTOU, 1);
> + rcu_read_unlock();
> set_thread_flag(TIF_SIGPENDING);
> ret = -ERESTARTSYS;
> -out:
> return ret;
> -out_unlock:
> +out_irqunlock:
> spin_unlock_irqrestore(>ctrl_lock, flags);
> +out_rcuunlock:
> + rcu_read_unlock();
> return ret;
> }
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, msr: Allow read access to /dev/cpu/X/msr
On Fri, 26 Jun 2015, Prarit Bhargava wrote: > > The proper way to do this is to write a driver to only expose the MSRs > > that the user tools need, and nothing else. > > Will do -- At least I got everyone's attention with this :). IMHO we need both a new driver that exposes semanthic functionality instead of raw MSRs, and also to lock down the current MSR driver using processor vendor, family and model-aware whitelists. We have absolutely no idea of the real security impact of the CONFIG_X86_MSR /dev/cpu/cpu#/msr driver, as that driver allows CAP_SYS_RAWIO userspace to have complete access to all documented *and undocumented* MSRs. Maybe we could build on the ideas and data already colleced by the msr-safe LLNS code? https://github.com/scalability-llnl/msr-safe http://www.vi-hps.org/upload/program/espt-sc14/vi-hps-ESPT14-Shoga.pdf At the very least, their work on building a list of safe MSRs should help... Their code seems to be licensed under the GPLv3, which is a rather strange choice of license for a kernel module. A quick look using Debian's codesearch found these users of /dev/cpu/cpu#/msr: * cpufrequtils * flashrom * i7z * intel-gpu-tools * inteltool * mcelog * msrtool, msr-tools * PAPI (can use msr_safe) * powertop * qemu * slurm-llnl (maybe this can also use msr_safe?) * stressapptest * turbostat * wmlongrun, longrun * x86info * xserver-xorg-video-geode As well as the other stuff that ships from the Linux kernel tree. Looking at what they need the MSR access for (well, except for msrtools, which is just a way for shell scripts to easily talk to the MSR driver) might help define the problem space better. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, msr: Allow read access to /dev/cpu/X/msr
On Sun, 28 Jun 2015, Prarit Bhargava wrote: > Is it easier to blacklist MSRs we don't want generally exposed, or only expose > the ones that we think are safe? That's sort of a devil's advocate sort of > question ;) and I'm wondering what the shorter list is. The only way to make MSR access safe is to allow it only by whitelisting. The x86 platform restricts all MSR access to ring 0 for a damn good reason. Also, such a whitelist would most likely need to be vendor and model-aware, and to differentiate "allow reads" from "allow writes"... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7] dma: Add Xilinx AXI Direct Memory Access Engine driver support
HI, On Sun, Jun 28, 2015 at 5:45 PM, Vinod Koul wrote: [...] >> > I asked how the device address in configured. For both MM2S S2MM you are >> > using sg for memory address, where are you getting device adress, are you >> > assuming/hardcoding or getting somehow, if so how? >> As the name says, one end is memory (MM) and the other end is an AXI4 >> Stream Bus (S) which has no concept of memory address. >> So yes, it is hardcoded at design time. > So where does the data go at the end of stream bus, who configures that? > Shouldnt all this be at least documented... You make the connection at design time. In Zynq7000 case, there's a dual core Cortex A9 coupled with an FPGA. While designing the FPGA part, you instantiate an Xilinx AXI DMA, on one side you connect it to an AXI4 Lite bus (which is memory mapped) and on the other side you connect your custom peripheral using an AXI4 Stream bus which has no concept of addresses. Here's a picture which depicts all of this [0]. Does this clear things up? [0] http://www.fpgadeveloper.com/wp-content/uploads/2014/08/fpga_developer_20140806_130447.png -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [all better] Re: regression: massive trouble with fpu rework
On Sun, 28 Jun 2015, Mike Galbraith wrote: > > > > > BIOS setting "Limit CPUID Maximum" upsets new fpu code mightily. > > > > Well, it is supposed to disable CPUID levels >= 0x04. This thing should > > *NEVER* be enabled, the last operating system that required it to be enabled > > was Windows 98. > > > > Can/do we override that crap during cpu init? If we cannot/don't, maybe > > instead of limping along with CPUID crippled, it would be better to either > > output a very nasty warning, or outright stop booting [with an appropriate > > error message] ? > > Why get all upset? We didn't even notice before, nor did/does that > other OS. A casual "BTW, your BIOS sucks.." should suffice, no? Oh, I am not upset, although I suppose my reply did look like it. Sorry about that. It is just that this kind of breakage should not be subtle if we can help it, because people will use a crippled system for years without noticing... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PCI-iproc: Delete unnecessary checks before two function calls
From: Markus Elfring Date: Sun, 28 Jun 2015 16:42:04 +0200 The functions phy_exit() and phy_power_off() test whether their argument is NULL and then return immediately. Thus the test around the calls is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/pci/host/pcie-iproc.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c index d77481e..f875821 100644 --- a/drivers/pci/host/pcie-iproc.c +++ b/drivers/pci/host/pcie-iproc.c @@ -239,12 +239,9 @@ err_rm_root_bus: pci_remove_root_bus(bus); err_power_off_phy: - if (pcie->phy) - phy_power_off(pcie->phy); + phy_power_off(pcie->phy); err_exit_phy: - if (pcie->phy) - phy_exit(pcie->phy); - + phy_exit(pcie->phy); return ret; } EXPORT_SYMBOL(iproc_pcie_setup); -- 2.4.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7] dma: Add Xilinx AXI Direct Memory Access Engine driver support
On Sat, Jun 27, 2015 at 05:44:38PM +0300, Nicolae Rosia wrote: > On Sat, Jun 27, 2015 at 5:40 PM, Vinod Koul wrote: > [...] > >> Please let me know if you are not clear. > > No sorry am not... > > > > I asked how the device address in configured. For both MM2S S2MM you are > > using sg for memory address, where are you getting device adress, are you > > assuming/hardcoding or getting somehow, if so how? > As the name says, one end is memory (MM) and the other end is an AXI4 > Stream Bus (S) which has no concept of memory address. > So yes, it is hardcoded at design time. So where does the data go at the end of stream bus, who configures that? Shouldnt all this be at least documented... -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, msr: Allow read access to /dev/cpu/X/msr
On 06/27/2015 11:52 AM, Andy Lutomirski wrote:
> On Sat, Jun 27, 2015 at 1:39 AM, Ingo Molnar wrote:
>>
>> * Ingo Molnar wrote:
>>
>>> So what's wrong with exposing them as a simplified PMU driver?
>>>
>>> That way we only expose the ones we want to - plus tooling can use all the
>>> rich
>>> perf features that can be used around this. (sampling, counting, call
>>> chains,
>>> etc.)
>>
>> See below code from Andy that exposes a single MSR via perf. At the core of
>> the
>> PMU driver is a single rdmsrl():
>>
>> +static void aperfmperf_event_start(struct perf_event *event, int flags)
>> +{
>> + u64 now;
>> +
>> + rdmsrl(event->hw.event_base, now);
>> + local64_set(>hw.prev_count, now);
>> +}
>>
I just sat down to do something similar to what Andy had proposed here :).
>> Now I think what we really want is to expose not a single MSR but multiple
>> MSRs in
>> a single driver, i.e. don't have one PMU driver per MSR, but have a driver
>> that
>> allows the exposure of select MSRs as counters.
>
> I'm way ahead of you: this driver can expose *two* MSRs as counters :)
>
> Seriously, though, it would be straightforward to make it handle a
> more general list, complete with non-architectural stuff (such as the
> upcoming PPERF in Skylake).
Is it easier to blacklist MSRs we don't want generally exposed, or only expose
the ones that we think are safe? That's sort of a devil's advocate sort of
question ;) and I'm wondering what the shorter list is.
>
> This driver only knows how to handle counters, though. I'm not sure
> whether all of the MSRs that turbostat needs are counters.
I knew that turbostat only did MSR reads and that's why turbostat's code was
changed in this patch. TBH I'm more concerned for software that monitors system
power consumption, performance, and load.
I'll take what Andy has proposed and expand on it.
P.
>
> --Andy
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] iommu/arm-smmu: Delete an unnecessary check before the function call "free_io_pgtable_ops"
From: Markus Elfring
Date: Sun, 28 Jun 2015 15:55:11 +0200
The free_io_pgtable_ops() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/iommu/arm-smmu-v3.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index f141301..8e9ec81 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -1389,8 +1389,7 @@ static void arm_smmu_domain_free(struct iommu_domain
*domain)
struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
struct arm_smmu_device *smmu = smmu_domain->smmu;
- if (smmu_domain->pgtbl_ops)
- free_io_pgtable_ops(smmu_domain->pgtbl_ops);
+ free_io_pgtable_ops(smmu_domain->pgtbl_ops);
/* Free the CD and ASID, if we allocated them */
if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1) {
--
2.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
