[PATCH] input: ab8500-ponkey: Allocate resources using managed interfaces
This patch moves most data allocated in the probe function from
unmanaged interfaces to managed interfaces. The kfrees and error
handling code is done away with. Also, the unnecesary labels are
removed and the function ab8500_ponkey_remove is removed as it becomes
empty after removing the no longer required function calls. Also,
linux/device.h is added to make sure the devm_*() routine declarations
are unambiguously available.
The following Coccinelle semantic patch was used for making a part of
the change:
@platform@
identifier p, probefn, removefn;
@@
struct platform_driver p = {
.probe = probefn,
.remove = removefn,
};
@prb@
identifier platform.probefn, pdev;
expression e, e1, e2;
@@
probefn(struct platform_device *pdev, ...) {
+...
- e = kzalloc(e1, e2)
+ e = devm_kzalloc(pdev-dev, e1, e2)
...
?-kfree(e);
...+
}
@rem depends on prb@
identifier platform.removefn;
expression e;
@@
removefn(...) {
...
- kfree(e);
...
}
Signed-off-by: Himangi Saraogi himangi...@gmail.com
Acked-by: Julia Lawall julia.law...@lip6.fr
---
To send to: Dmitry Torokhov
dmitry.torok...@gmail.com,linux-in...@vger.kernel.org,linux-kernel@vger.kernel.org
drivers/input/misc/ab8500-ponkey.c | 51 +++---
1 file changed, 15 insertions(+), 36 deletions(-)
diff --git a/drivers/input/misc/ab8500-ponkey.c
b/drivers/input/misc/ab8500-ponkey.c
index f2fbdd8..89fb1c6 100644
--- a/drivers/input/misc/ab8500-ponkey.c
+++ b/drivers/input/misc/ab8500-ponkey.c
@@ -7,6 +7,7 @@
* AB8500 Power-On Key handler
*/
+#include linux/device.h
#include linux/kernel.h
#include linux/module.h
#include linux/platform_device.h
@@ -65,12 +66,11 @@ static int ab8500_ponkey_probe(struct platform_device *pdev)
return irq_dbr;
}
- ponkey = kzalloc(sizeof(struct ab8500_ponkey), GFP_KERNEL);
- input = input_allocate_device();
- if (!ponkey || !input) {
- error = -ENOMEM;
- goto err_free_mem;
- }
+ ponkey = devm_kzalloc(pdev-dev, sizeof(struct ab8500_ponkey),
+ GFP_KERNEL);
+ input = devm_input_allocate_device(pdev-dev);
+ if (!ponkey || !input)
+ return -ENOMEM;
ponkey-idev = input;
ponkey-ab8500 = ab8500;
@@ -82,52 +82,32 @@ static int ab8500_ponkey_probe(struct platform_device *pdev)
input_set_capability(input, EV_KEY, KEY_POWER);
- error = request_any_context_irq(ponkey-irq_dbf, ab8500_ponkey_handler,
- 0, ab8500-ponkey-dbf, ponkey);
+ error = devm_request_any_context_irq(pdev-dev, ponkey-irq_dbf,
+ab8500_ponkey_handler, 0,
+ab8500-ponkey-dbf, ponkey);
if (error 0) {
dev_err(ab8500-dev, Failed to request dbf IRQ#%d: %d\n,
ponkey-irq_dbf, error);
- goto err_free_mem;
+ return error;
}
- error = request_any_context_irq(ponkey-irq_dbr, ab8500_ponkey_handler,
- 0, ab8500-ponkey-dbr, ponkey);
+ error = devm_request_any_context_irq(pdev-dev, ponkey-irq_dbr,
+ab8500_ponkey_handler, 0,
+ab8500-ponkey-dbr, ponkey);
if (error 0) {
dev_err(ab8500-dev, Failed to request dbr IRQ#%d: %d\n,
ponkey-irq_dbr, error);
- goto err_free_dbf_irq;
+ return error;
}
error = input_register_device(ponkey-idev);
if (error) {
dev_err(ab8500-dev, Can't register input device: %d\n,
error);
- goto err_free_dbr_irq;
+ return error;
}
platform_set_drvdata(pdev, ponkey);
return 0;
-
-err_free_dbr_irq:
- free_irq(ponkey-irq_dbr, ponkey);
-err_free_dbf_irq:
- free_irq(ponkey-irq_dbf, ponkey);
-err_free_mem:
- input_free_device(input);
- kfree(ponkey);
-
- return error;
-}
-
-static int ab8500_ponkey_remove(struct platform_device *pdev)
-{
- struct ab8500_ponkey *ponkey = platform_get_drvdata(pdev);
-
- free_irq(ponkey-irq_dbf, ponkey);
- free_irq(ponkey-irq_dbr, ponkey);
- input_unregister_device(ponkey-idev);
- kfree(ponkey);
-
- return 0;
}
#ifdef CONFIG_OF
@@ -144,7 +124,6 @@ static struct platform_driver ab8500_ponkey_driver = {
.of_match_table = of_match_ptr(ab8500_ponkey_match),
},
.probe = ab8500_ponkey_probe,
- .remove = ab8500_ponkey_remove,
};
module_platform_driver(ab8500_ponkey_driver);
--
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
Re: [PATCH 01/27] mtd: nand: introduce function to fix a common bug in most nand-drivers not showing a device in sysfs
On Wed, May 28, 2014 at 08:52:06PM +0200, Alexander Holler wrote:
Am 28.05.2014 10:43, schrieb Brian Norris:
On Tue, May 27, 2014 at 12:12:26AM +0200, Alexander Holler wrote:
+{
+ mtd-priv = priv;
I don't think you should hide this one here. It will be quite obvious if
a driver didn't stash its private data but tries to access it later. Are
there any drivers that missed this?
No, it just saves a line of source in all drivers and I think it
fits there. I don't understand why do you think it is hidden.
The function name doesn't make it obvious what it's doing. So all code
readers will have to follow the definition to see what it's doing. But
this point is not that important, so I won't argue.
+ mtd-owner = pdev-dev.driver-owner;
+ mtd-dev.parent = pdev-dev;
+ mtd-name = pdev-dev.driver-name;
I think this is a little dangerous. You're potentially clobbering the
name that a driver already chose here. And why did you pick to use the
driver name? This gives non-unique names if there is more than one
device instantiated for a driver. That's why some drivers already use
the device name, not the driver name:
mtd-name = dev_name(pev-dev);
And in fact, if any drivers are missing mtd-name, perhaps it's best to
just modify the MTD registration to give them a default:
if (!mtd-name)
mtd-name = dev_name(pdev-dev);
+}
I don't clobber any name. The name is set as default before drivers
might do this.
At the moment this is true, but the ordering is somewhat subtle if you
don't examine the details of mtd_setup_common_members() to see that it
is assigning a name. I can easily imagine some new driver in which
someone does:
mtd-name = ...;
[...]
mtd_setup_common_members(mtd, priv, pdev);
And doesn't notice that the ordering matters.
You could make this simpler by either
(1) making mtd_setup_common_members() check for mtd-name==NULL first
(2) just move the (default) name assignment to the common MTD
registration, like I suggested
+
extern int mtd_device_parse_register(struct mtd_info *mtd,
const char * const *part_probe_types,
struct mtd_part_parser_data *parser_data,
How about we rethink the helper approach, and instead just do
validation in the core code? This would cover most of the important
parts of your helper, I think:
Feel free to change all drivers. I like my approach with fixing 21
bugs by reducing code by 44 lines.
I appreciate the bug fixes. I am just questioning the approach. Reduced
(source) code doesn't help anyone if it makes the code less
maintainable. My suggestions can probably make this more maintainable,
fix the same bugs, and reduce the source by a similar (albeit smaller)
number of lines.
And it offers a common function where future similiarities can be
put into too. Of course you can just add 21 lines, but that is not
how I do such stuff.
I don't see how your common location helps much more than putting it in
mtdcore.c like I suggested, without the extra function.
And I did the patches. If you don't like them, feel free to ignore
them. I'm not playing remote keyboard but I do patches like I would
do them, not like some arbitrary maintainer would do them. Sorry for
the harsh words.
Arbitrary maintainer, eh? I'm simply suggesting that this could be
accomplished in a better way. If you don't want to take part in the
review process, then I have no obligation to engage either.
Regards,
Brian
--
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] ARM: dts: qcom: Update msm8960 device trees
On Wed, May 28, 2014 at 01:27:23PM -0500, Kumar Gala wrote:
* Move SoC peripherals into an SoC container node
* Move serial enabling into board file (qcom-msm8960-cdp.dts)
* Cleanup cpu node to match binding spec, enable-method and compatible
should be per cpu, not part of the container
* Drop interrupts property from l2-cache node as its not part of the
binding spec
Signed-off-by: Kumar Gala ga...@codeaurora.org
---
arch/arm/boot/dts/qcom-msm8960-cdp.dts | 6 ++
arch/arm/boot/dts/qcom-msm8960.dtsi| 165
+
2 files changed, 93 insertions(+), 78 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-msm8960-cdp.dts
b/arch/arm/boot/dts/qcom-msm8960-cdp.dts
index a58fb88..8e77ed7 100644
--- a/arch/arm/boot/dts/qcom-msm8960-cdp.dts
+++ b/arch/arm/boot/dts/qcom-msm8960-cdp.dts
@@ -3,4 +3,10 @@
/ {
model = Qualcomm MSM8960 CDP;
compatible = qcom,msm8960-cdp, qcom,msm8960;
+
+ soc {
+ serial@1644 {
+ status = ok;
+ };
+ };
};
Is now the time put these serial nodes under a GSBI parent node?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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] pci: Save and restore VFs as a part of a reset
On Wed, May 28, 2014 at 10:39 AM, Alexander Duyck alexander.h.du...@intel.com wrote: On 05/27/2014 09:12 PM, Alex Williamson wrote: On Tue, 2014-05-27 at 19:19 -0600, Bjorn Helgaas wrote: Maybe resetting the PF should just fail if there's an active VF. If you need to reset the PF, you'd have to unbind the VFs first. The use case is certainly questionable, personally I'm not going to expect VFs to continue working after the PF is reset. Driver binding gets complicated, especially when KVM doesn't actually bind devices to use them. Hopefully we'll get that out of the tree some day though. I suppose we could -EBUSY the PF reset as long as VFs are enabled. What I could do is go through and notify the VFs that they are about to get hit by a reset. What they do with that information would be up to them. So if the VFs are loaded on the host I could then at least allow them to recover by saving and restoring the config space within the driver themselves. I really like the idea of punting by failing the PF reset if there are any active VFs. That's a really easy way of making sure we aren't going to blow up any guests. What problems would it cause if we went this route? This reminds me about an open problem: VFs can be on virtual buses, which aren't really connected in the hierarchy, and I don't think we have a nice way to iterate over them. So probably pci_get_device() is the best we can do now. Yeah, those virtual buses don't have a bus-self, we just have to skip to bus-parent-self. pci_walk_bus() goes in the opposite direction, but without an actual device hosting the bus, I don't see how it finds it. Thanks, It seems like we should be able to come up with something like pci_walk_vbus() though or something similar. All we would need to do is search the VFs on the bus of the PF and all child busses to that bus if I am not mistaken. I don't think that's going to work because the virtual buses don't appear as the child bus of anything. Bjorn -- 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: fs/dcache.c - BUG: soft lockup - CPU#5 stuck for 22s! [systemd-udevd:1667]
On Wed, May 28, 2014 at 12:43:24PM -0700, Linus Torvalds wrote: It does require that the dentry shrinking code always hold the RCU lock for reading, because others may actually be doing the final dput() while the thing is on the shrinking list (and holding the RCU lock is what protects the entry from actually being free'd). NOTE! I don't claim that this fixes anything, but I do think that it makes that whole cross-thread complexity of that DCACHE_MAY_FREE go away. I think it's easier to understand, and it removes code in the process. Comments? Unless I'm badly misreading your patch, you are calling dentry_kill() with rcu_read_lock() held. And that can trigger all sorts of interesting things, starting with iput() and tons of disk IO... What am I missing here? -- 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] fence: Use smp_mb__before_atomic()
On 28-05-14 16:26, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
Commit febdbfe8a91c (arch: Prepare for smp_mb__{before,after}_atomic())
deprecated the smp_mb__{before,after}_{atomic,clear}_{dec,inc,bit}*()
functions in favour of the unified smp_mb__{before,after}_atomic().
Signed-off-by: Thierry Reding tred...@nvidia.com
Acked-by: Maarten Lankhorst maarten.lankho...@canonical.com
I saw the patches, but hard to clean up if it's not in the fences tree
yet. :-)
~maarten
--
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] ARM: dts: qcom: Update msm8960 device trees
On May 28, 2014, at 3:09 PM, Josh Cartwright jo...@codeaurora.org wrote:
On Wed, May 28, 2014 at 01:27:23PM -0500, Kumar Gala wrote:
* Move SoC peripherals into an SoC container node
* Move serial enabling into board file (qcom-msm8960-cdp.dts)
* Cleanup cpu node to match binding spec, enable-method and compatible
should be per cpu, not part of the container
* Drop interrupts property from l2-cache node as its not part of the
binding spec
Signed-off-by: Kumar Gala ga...@codeaurora.org
---
arch/arm/boot/dts/qcom-msm8960-cdp.dts | 6 ++
arch/arm/boot/dts/qcom-msm8960.dtsi| 165
+
2 files changed, 93 insertions(+), 78 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-msm8960-cdp.dts
b/arch/arm/boot/dts/qcom-msm8960-cdp.dts
index a58fb88..8e77ed7 100644
--- a/arch/arm/boot/dts/qcom-msm8960-cdp.dts
+++ b/arch/arm/boot/dts/qcom-msm8960-cdp.dts
@@ -3,4 +3,10 @@
/ {
model = Qualcomm MSM8960 CDP;
compatible = qcom,msm8960-cdp, qcom,msm8960;
+
+soc {
+serial@1644 {
+status = ok;
+};
+};
};
Is now the time put these serial nodes under a GSBI parent node?
Yeah, I’ll make the change to the 8960 8660 dts
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
--
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 v8 5/8] arm64: Add ftrace support
On Wed, Apr 30, 2014 at 06:54:33PM +0900, AKASHI Takahiro wrote: +/* + * arch/arm64/kernel/entry-ftrace.S + * + * Copyright (C) 2013 Linaro Limited + * Author: AKASHI Takahiro takahiro.aka...@linaro.org + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/linkage.h +#include asm/ftrace.h +#include asm/insn.h asm/insn.h contains a bunch of C stuff which won't build without __ASSEMBLY__ guards unless I'm missing something (I'm working with a non-mainline tree so I might be). signature.asc Description: Digital signature
Re: [RFC] perf/x86: PMU IRQ handler issues
On 05/28/2014 12:48 PM, Stephane Eranian wrote: Some days ago, I was alerted that under important network load, something is going wrong with perf_event sampling in frequency mode (such as perf top). The number of samples was way too low given the cycle count (via perf stat). Looking at the syslog, I noticed that the perf irq latency throttler had kicked in several times. There may have been several reasons for this. Maybe the workload had changing phases and the frequency adjustments was not working properly and dropping to very small period and then generated flood of interrupts. The problem description here is pretty fuzzy. Could you give some actual numbers describing the issues that you're seeing, including the ftrace that Andi was asking for? There are also some handy tracepoints for NMI lengths that I stuck in. The reason that the throttling code is there is that the CPU can get in to a state where it is doing *NOTHING* other than processing NMIs (the biggest of which are the perf-driven ones). It doesn't start throttling until 128 samples end up averaging more than the limit. How large of a system is this, btw? I had the worst issues on a 160-logical-cpu system. It was much harder to get it to trouble on smaller systems. -- 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: linux-next: build failure after merge of the final tree
Greg, On Wed, 2014-05-28 at 12:14 +0200, Paul Bolle wrote: I must have compile tested this with CONFIG_LIB80211_CRYPT_TKIP=m while the code checks for CONFIG_LIB80211_CRYPT_TKIP only (ie, builtin only). I'll have to have a better look at this. Greg, can the cleaning up of this mess involve an entirely new patch? An incremental patch would leave this build error in a certain range of commits. The pieces of the latest linux-next build were handed to me by Stephen as my patch managed to break it. I'm assuming you'd like to include rtl8192u in linux-next's builds again. Currently I got nothing to offer to you but a request to either drop staging: rtl8192u: rename CONFIG_IEEE80211_CRYPT_TKIP from staging-next or, if that's not how staging-next works, a request to revert it. What do you prefer? Either way I'll see whether I can come up with a fix that allows me to take off that brown paper bag. Paul Bolle -- 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: ks8851: Don't use regulator_get_optional()
On Wed, May 28, 2014 at 01:11:12PM -0700, Stephen Boyd wrote: We shouldn't be using regulator_get_optional() here. These regulators are always present as part of the physical design and there isn't any way to use an internal regulator or change the source of the reference voltage via software. Given that the only users of this driver in the kernel are DT based, this change should be transparent to them even if they don't specify any supplies because the regulator framework will insert dummy supplies as needed. Reviewed-by: Mark Brown broo...@linaro.org signature.asc Description: Digital signature
Re: fs/dcache.c - BUG: soft lockup - CPU#5 stuck for 22s! [systemd-udevd:1667]
On Wed, May 28, 2014 at 01:02:23PM -0700, Linus Torvalds wrote: Anyway, one reason I looked at this is that most of the threads in Mika's NMI watchdog traces were stuck on _raw_spin_lock() in the whole d_walk() thing, and I had a *really* hard time convincing myself that this was all safe without the RCU lock. I'm wondering if Mika perhaps has CONFIG_PREEMPT_RCU set, which means that spinlocks (or the rename_lock sequence lock) do not end up being RCU-safe points. d_walk() covers its arse with -d_lock (and it wants the starting point to be pinned, obviously). So AFAICS RCU is not a problem. -- 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] regulator: Fix regulator_get_{optional,exclusive}() documentation
On Wed, May 28, 2014 at 12:41:28PM -0700, Stephen Boyd wrote: regulator_get_optional() doesn't hold an exclusive reference to the regulator. Fix the documentation and reword the exclusive documentation to fix the grammatical error this reference is held. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 0/6] DT early console initialization
On Wed, May 28, 2014 at 11:30:04AM -0500, Rob Herring wrote: On Wed, May 14, 2014 at 9:26 AM, Grant Likely grant.lik...@linaro.org wrote: On Thu, 8 May 2014 17:23:37 -0500, Rob Herring robherri...@gmail.com wrote: From: Rob Herring r...@kernel.org This series adds support for early serial console initialization using DT. This enables determining the serial port type and address using the FDT and allows enabling the console before platform specific initialization runs. I've tested this on arm64. ARM support is dependent on adding fixmap support. Currently, the earlycon is only enabled if earlycon is present on the kernel command line. The FDT needs to have /chosen/stdout-path set to the path of the serial port. This series is dependent on generic earlycon[1], libfdt support[2], and vmlinux.lds.h clean-ups[3]. The first 2 are in linux-next already. A git branch is available here: git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git earlycon-dt Nice. For the whole series: Acked-by: Grant Likely grant.lik...@linaro.org I haven't tested it though. Rob [1] https://lkml.org/lkml/2014/4/18/573 [2] https://lkml.org/lkml/2014/4/22/1202 [3] https://lkml.org/lkml/2014/3/27/285 Rob Herring (6): of: align RESERVEDMEM_OF_DECLARE function callbacks to other callbacks of: consolidate linker section OF match table declarations serial: earlycon: add DT support of/fdt: add FDT address translation support of/fdt: add FDT serial scanning for earlycon tty/serial: pl011: add DT based earlycon support Greg, I plan to take this series thru the DT tree for 3.16 unless you have any objections. It has dependencies on both the tty-next and the DT trees. No objection from me at all, feel free to do so. greg k-h -- 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] rtmutex: Do not boost fair tasks each other
On Mon, 5 May 2014, Kirill Tkhai wrote: В Сб, 03/05/2014 в 20:54 +0200, Thomas Gleixner пишет: Though exercising that code path as much as we can is not a bad thing either. So I'd like to see that made compile time conditional on one of the lock testing CONFIG items. +#ifndef CONFIG_RT_MUTEX_BOOST_ALL No, not another pointless config option. Read what I said. What's wrong with using an existing config item, e.g DEBUG_RT_MUTEXES? +#define heritable_prio(prio) (rt_prio(prio) || dl_prio(prio)) inheritable please. It's not priority heritance and never will be. Thanks, tglx
Re: [patch 4/6] rtmutex: Confine deadlock logic to futex
On Thu, 22 May 2014, Peter Zijlstra wrote: On Thu, May 22, 2014 at 03:25:50AM -, Thomas Gleixner wrote: The builtin tester is gone,, so the deadlock logic is now only required for futexes. Remove the extra arguments for the public functions and also for the futex specific ones which get always called with deadlock detection enabled. This reminds me, the raw rt_mutex primitives have no lockdep support, and we've grown a few users in-tree. We should fix that. It shouldn't be that hard. We just need to exclude the futex mess ... Thanks, tglx -- 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 v4 00/16] PCI/iommu: Fix DMA alias problems
On Thu, May 22, 2014 at 05:07:23PM -0600, Alex Williamson wrote: For testing, this version can be found in my git tree: git://github.com/awilliam/linux-vfio.git dma-alias-v4 Please report any issues. v4: - Change dma_func_alias to dma_alias_devfn, holding a single devfn to alias, thereby supporting aliases to the wrong slot. The DMA alias iterator is easily changed, but IOMMU grouping requires significant rework. This is now done in IOMMU code rather than PCI code. - AMD-Vi - try to incorporate IVRS aliases dynamically into PCI alias quirks to make sure that our grouping remains the same. Potentially this could end up reporting BIOS aliases that we can add to our list of quirks. v3: - Found several instances where I had PCI_SLOT when I meant PCI_FUNC. Thanks to Andrew for spotting this. This should fix the problem he was having with Ricoh quirks. We also pruned down the func0 quirks to only those that we know are needed. We can always add them back later. - Found a case in intel-iommu of using dev_is_pci() where I really wanted !dev_is_pci(). Fixed. v2: - Several new Marvell controllers added to quirks. There's been a lot of success reported with this series in https://bugzilla.kernel.org/show_bug.cgi?id=42679 - Add quirk for ASMedia and Tundra PCIe-to-PCI bridges that do not expose a PCIe capability. These have been shown to use the standard PCIe-to-PCI bridge requester ID. - Fix copy/paste duplicate Ricoh quirk ID - Fixed AMD IOMMU for the ghost function case where the DMA alias is for an absent device. The iommu rlookup table and data fields need to be initializes. - Fixed Intel interrupt remapping, I wasn't passing the target bus number, only the alias bus number. These patches are split across PCI and IOMMU, but I've front-loaded all of the PCI infrastructure so that the first 7 patches can be applied to PCI-core, the IOMMU maintainers can pickup their patches, then we can finish with dead code removal. Bjorn might also be willing to carry the IOMMU changes if the maintainers want to ack them. I put 1-7 on a pci/iommu branch for v3.16. I'm happy to include the rest, too, given acks from Joerg and David. Or if they prefer to take them all, which might be easier than coordinating two trees, especially since there's PCI stuff at the beginning and end, here's my ack for the PCI bits (patches 1-7 and 15-16): Acked-by: Bjorn Helgaas bhelg...@google.com If you want to send me updated changelogs for patches 5 6, I'll drop those in. Didn't you have more testing reports? I see George's, but I thought there were some others, too. Original description: This series attempts to fix a couple issues we've had outstanding in the PCI/IOMMU code for a while. The first issue is with devices that use the wrong requester ID for DMA transactions. We already have a sort of half-baked attempt to fix this for several Ricoh devices, but the fix only helps them be useful through IOMMU groups, not the general DMA case. There are also several Marvell devices which use use a different wrong requester ID and don't even fit into the DMA source idea. This series creates a DMA alias iterator that will step through each possible alias of a device, allowing IOMMUs to insert mappings for both the device and its aliases. Hand-in-hand with this is our broken pci_find_upstream_pcie_bridge() function, which is known to blowup when it finds itself suddenly at a PCIe device without crossing a PCIe-to-PCI bridge (as identified by the PCIe capability). It also likes to make the invalid assumption that a PCIe device never has its requester ID masked by any usptream bus. We can fix this using the above new DMA alias iterator, since that's effectively what this function was meant to do. Finally, with all these helpers, it makes sense to consolidate code for determining IOMMU groups. The first step in finding the root of a group is finding the final upstream DMA alias for the device, then applying additional ACS rules and incorporating device specific aliases. As this is all common to PCI, create a single implementation and remove piles of code from the individual IOMMU drivers. This series allows devices like the Marvell 88SE9123 to finally work on Linux with either AMD-Vi or VT-d enabled on the box. I've collected device IDs from various bugs to support as many SKUs of these devices as possible, but I'm sure there are others that I've missed. This should also enable motherboards with an onboard ASmedia ASM1083/1085 PCIe-to-PCI bridge to work with VT-d enabled. I've acquired an adapter board with this chip, but it actually exposes a PCIe capability, unlike most of the onboard controllers. Therefore I expect this series will fix the WARN_ON currently hit during boot, but there's a 50/50 chance whether the device behaves like a PCI bridge or a
Re: [PATCH] tty/hvc/hvc_console: Fix wakeup of HVC thread on hvc_kick()
On Wed, May 28, 2014 at 10:01:30AM +1000, Benjamin Herrenschmidt wrote: On Fri, 2014-05-23 at 19:41 +1000, Benjamin Herrenschmidt wrote: Some backends call hvc_kick() to wakeup the HVC thread from its slumber upon incoming characters. This however doesn't work properly because it uses msleep_interruptible() which is mostly immune to wake_up_process(). It will basically go back to sleep until the timeout is expired (only signals can really wake it). Replace it with a simple shedule_timeout_interruptible() instead, which may wakeup earlier every now and then but we really don't care in this case. Nobody commented ? :-) Greg, do you want to take this in the tty tree or can I stick it in powerpc ? I'll take it, thanks. greg k-h -- 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: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
Serge E. Hallyn se...@hallyn.com writes: I was aware of FUSE but hadn't ever looked at it much. Looking at it now, this isn't going to satisfy any of the use cases I know about, which are wanting to use filesystems supported in-kernel (isofs, ext*). I don't see that any of these have a FUSE implementation, and I think we gain more from figuring out how to use in-kernel filesystems in containers than trying to find a way to shoehorn selected filesystems into FUSE. That's why I was wondering how much work it would be to auto-generate fuse fs support from the in-kernel source. So at a quick look I have found fuseext2, fuseiso and mountlo-0.5 (which claims to have supported all the in-kernel filesystems with the help of user mode linux). Give that the first two are just an apt-get install away fuse really looks like the shortest path to being able to mount an iso, do other interesting things. We probably want something more but only when performance becomes a bottle-neck. Eric -- 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] pci: Save and restore VFs as a part of a reset
On 05/28/2014 04:14 PM, Bjorn Helgaas wrote: On Wed, May 28, 2014 at 10:39 AM, Alexander Duyck alexander.h.du...@intel.com wrote: On 05/27/2014 09:12 PM, Alex Williamson wrote: On Tue, 2014-05-27 at 19:19 -0600, Bjorn Helgaas wrote: Maybe resetting the PF should just fail if there's an active VF. If you need to reset the PF, you'd have to unbind the VFs first. The use case is certainly questionable, personally I'm not going to expect VFs to continue working after the PF is reset. Driver binding gets complicated, especially when KVM doesn't actually bind devices to use them. Hopefully we'll get that out of the tree some day though. I suppose we could -EBUSY the PF reset as long as VFs are enabled. What I could do is go through and notify the VFs that they are about to get hit by a reset. What they do with that information would be up to them. So if the VFs are loaded on the host I could then at least allow them to recover by saving and restoring the config space within the driver themselves. I really like the idea of punting by failing the PF reset if there are any active VFs. That's a really easy way of making sure we aren't going to blow up any guests. What problems would it cause if we went this route? I think this is the safest route. PF-VF interaction isn't architected, and resetting the PF with active VFs will probably hang a number of SRIOV implementations, requiring a system-level reset to correct the compounded problem. This reminds me about an open problem: VFs can be on virtual buses, which aren't really connected in the hierarchy, and I don't think we have a nice way to iterate over them. So probably pci_get_device() is the best we can do now. Yeah, those virtual buses don't have a bus-self, we just have to skip to bus-parent-self. pci_walk_bus() goes in the opposite direction, but without an actual device hosting the bus, I don't see how it finds it. Thanks, It seems like we should be able to come up with something like pci_walk_vbus() though or something similar. All we would need to do is search the VFs on the bus of the PF and all child busses to that bus if I am not mistaken. I don't think that's going to work because the virtual buses don't appear as the child bus of anything. +1. Bjorn -- 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: linux-next: build failure after merge of the final tree
On Wed, May 28, 2014 at 10:21:28PM +0200, Paul Bolle wrote: Greg, On Wed, 2014-05-28 at 12:14 +0200, Paul Bolle wrote: I must have compile tested this with CONFIG_LIB80211_CRYPT_TKIP=m while the code checks for CONFIG_LIB80211_CRYPT_TKIP only (ie, builtin only). I'll have to have a better look at this. Greg, can the cleaning up of this mess involve an entirely new patch? An incremental patch would leave this build error in a certain range of commits. As I already have the patch in my tree, I can't do that, we can live with the build issue. The pieces of the latest linux-next build were handed to me by Stephen as my patch managed to break it. I'm assuming you'd like to include rtl8192u in linux-next's builds again. Currently I got nothing to offer to you but a request to either drop staging: rtl8192u: rename CONFIG_IEEE80211_CRYPT_TKIP from staging-next or, if that's not how staging-next works, a request to revert it. What do you prefer? Either is fine with me, I can revert it, or apply a fix, which ever you want, just let me know. thanks, greg k-h -- 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] perf/x86/uncore: Remove unnecessary assignment to box in uncore_pci_remove(...)
On Wed, 28 May 2014, walter harms wrote:
Am 28.05.2014 11:11, schrieb Giedrius Rekasius:
Local variable box gets assigned correct value when it is initialized.
There is no need to assign the same value again.
Signed-off-by: Giedrius Rekasius giedrius.rekas...@gmail.com
---
arch/x86/kernel/cpu/perf_event_intel_uncore.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
index 65bbbea..8cbbb1b 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
@@ -3817,7 +3817,6 @@ static void uncore_pci_remove(struct pci_dev *pdev)
struct intel_uncore_pmu *pmu;
int i, cpu, phys_id = pcibus_to_physid[pdev-bus-number];
- box = pci_get_drvdata(pdev);
if (!box) {
for (i = 0; i UNCORE_EXTRA_PCI_DEV_MAX; i++) {
if (extra_pci_dev[phys_id][i] == pdev) {
Just a remark,
for readability it is better to remove the other one.
I rather have stuff reshuffled a bit more:
static void uncore_pci_remove(struct pci_dev *pdev)
{
int i, cpu, phys_id = pcibus_to_physid[pdev-bus-number];
struct intel_uncore_box *box = pci_get_drvdata(pdev);
struct intel_uncore_pmu *pmu;
if (!box) {
That's less lines and entirely readable.
Thanks,
tglx
--
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 v4 00/16] PCI/iommu: Fix DMA alias problems
On Wed, 2014-05-28 at 14:29 -0600, Bjorn Helgaas wrote: On Thu, May 22, 2014 at 05:07:23PM -0600, Alex Williamson wrote: For testing, this version can be found in my git tree: git://github.com/awilliam/linux-vfio.git dma-alias-v4 Please report any issues. v4: - Change dma_func_alias to dma_alias_devfn, holding a single devfn to alias, thereby supporting aliases to the wrong slot. The DMA alias iterator is easily changed, but IOMMU grouping requires significant rework. This is now done in IOMMU code rather than PCI code. - AMD-Vi - try to incorporate IVRS aliases dynamically into PCI alias quirks to make sure that our grouping remains the same. Potentially this could end up reporting BIOS aliases that we can add to our list of quirks. v3: - Found several instances where I had PCI_SLOT when I meant PCI_FUNC. Thanks to Andrew for spotting this. This should fix the problem he was having with Ricoh quirks. We also pruned down the func0 quirks to only those that we know are needed. We can always add them back later. - Found a case in intel-iommu of using dev_is_pci() where I really wanted !dev_is_pci(). Fixed. v2: - Several new Marvell controllers added to quirks. There's been a lot of success reported with this series in https://bugzilla.kernel.org/show_bug.cgi?id=42679 - Add quirk for ASMedia and Tundra PCIe-to-PCI bridges that do not expose a PCIe capability. These have been shown to use the standard PCIe-to-PCI bridge requester ID. - Fix copy/paste duplicate Ricoh quirk ID - Fixed AMD IOMMU for the ghost function case where the DMA alias is for an absent device. The iommu rlookup table and data fields need to be initializes. - Fixed Intel interrupt remapping, I wasn't passing the target bus number, only the alias bus number. These patches are split across PCI and IOMMU, but I've front-loaded all of the PCI infrastructure so that the first 7 patches can be applied to PCI-core, the IOMMU maintainers can pickup their patches, then we can finish with dead code removal. Bjorn might also be willing to carry the IOMMU changes if the maintainers want to ack them. I put 1-7 on a pci/iommu branch for v3.16. I'm happy to include the rest, too, given acks from Joerg and David. Or if they prefer to take them all, which might be easier than coordinating two trees, especially since there's PCI stuff at the beginning and end, here's my ack for the PCI bits (patches 1-7 and 15-16): Acked-by: Bjorn Helgaas bhelg...@google.com Awesome, thanks! If you want to send me updated changelogs for patches 5 6, I'll drop those in. Yep, I'll send changelog updates for 5 6 in a few minutes. Didn't you have more testing reports? I see George's, but I thought there were some others, too. I also see: https://lkml.org/lkml/2014/5/28/24 Tested-by: Pat Erley pat-l...@erley.org There are several reports of success in the bzs, but I don't see any official tested-by tags there. Thanks, Alex Original description: This series attempts to fix a couple issues we've had outstanding in the PCI/IOMMU code for a while. The first issue is with devices that use the wrong requester ID for DMA transactions. We already have a sort of half-baked attempt to fix this for several Ricoh devices, but the fix only helps them be useful through IOMMU groups, not the general DMA case. There are also several Marvell devices which use use a different wrong requester ID and don't even fit into the DMA source idea. This series creates a DMA alias iterator that will step through each possible alias of a device, allowing IOMMUs to insert mappings for both the device and its aliases. Hand-in-hand with this is our broken pci_find_upstream_pcie_bridge() function, which is known to blowup when it finds itself suddenly at a PCIe device without crossing a PCIe-to-PCI bridge (as identified by the PCIe capability). It also likes to make the invalid assumption that a PCIe device never has its requester ID masked by any usptream bus. We can fix this using the above new DMA alias iterator, since that's effectively what this function was meant to do. Finally, with all these helpers, it makes sense to consolidate code for determining IOMMU groups. The first step in finding the root of a group is finding the final upstream DMA alias for the device, then applying additional ACS rules and incorporating device specific aliases. As this is all common to PCI, create a single implementation and remove piles of code from the individual IOMMU drivers. This series allows devices like the Marvell 88SE9123 to finally work on Linux with either AMD-Vi or VT-d enabled on the box. I've collected device IDs from various bugs to support as many SKUs of these devices as possible, but I'm sure there are
Re: [RFC PATCH] crypto: crc32c-pclmul - Use pmovzxdq to shrink K_table
George Spelvin li...@horizon.com 05/28/14 4:40 PM Jan: Is support for SLE10's pre-2.18 binutils still required? Your PEXTRD fix was only a year ago, so I expect, but I wanted to ask. I'd much appreciate if I would be able to build the kernel that way for another while. Two other minor additional changes: 1. The current code unnecessarily puts the table in the read-write .data section. Moved to .text. Putting data into .text seems wrong - it should go into .rodata. Jan -- 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 char-misc-next 2/8] misc: mic: add a bus driver for virtual MIC devices
On Tue, May 27, 2014 at 07:36:11PM -0700, Sudeep Dutt wrote:
+int register_mbus_driver(struct mbus_driver *driver)
+{
+ driver-driver.bus = mic_bus;
+ return driver_register(driver-driver);
+}
+EXPORT_SYMBOL_GPL(register_mbus_driver);
mbus_register_driver()?
+void unregister_mbus_driver(struct mbus_driver *driver)
+{
+ driver_unregister(driver-driver);
+}
+EXPORT_SYMBOL_GPL(unregister_mbus_driver);
mbus_unregister_driver()?
+int register_mbus_device(struct mbus_device *dev)
mbus_register_device()?
Trying to keep the kernel namespace sane.
Why doesn't this function create the device structure?
+{
+ int err;
+
+ dev-dev.bus = mic_bus;
+
+ /* Assign a unique device index and hence name. */
+ err = ida_simple_get(mbus_index_ida, 0, 0, GFP_KERNEL);
+ if (err 0)
+ return err;
+
+ dev-index = err;
+ dev_set_name(dev-dev, mbus-dev%u, dev-index);
+ /*
+ * device_register() causes the bus infrastructure to look for a
+ * matching driver.
+ */
+ err = device_register(dev-dev);
+ return err;
+}
+EXPORT_SYMBOL_GPL(register_mbus_device);
+
+void unregister_mbus_device(struct mbus_device *dev)
+{
+ int index = dev-index; /* save for after device release */
+
+ device_unregister(dev-dev);
+ ida_simple_remove(mbus_index_ida, index);
+}
+EXPORT_SYMBOL_GPL(unregister_mbus_device);
+
+static int __init mbus_init(void)
+{
+ return bus_register(mic_bus);
+}
+
+static void __exit mbus_exit(void)
+{
+ bus_unregister(mic_bus);
+}
+
+core_initcall(mbus_init);
+module_exit(mbus_exit);
+
+MODULE_AUTHOR(Intel Corporation);
+MODULE_DESCRIPTION(Intel(R) MIC Bus driver);
+MODULE_LICENSE(GPL v2);
diff --git a/include/linux/mic_bus.h b/include/linux/mic_bus.h
new file mode 100644
index 000..8297573
--- /dev/null
+++ b/include/linux/mic_bus.h
@@ -0,0 +1,148 @@
+/*
+ * Intel MIC Platform Software Stack (MPSS)
+ *
+ * Copyright(c) 2014 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * The full GNU General Public License is included in this distribution in
+ * the file called COPYING.
+ *
+ * Intel MIC Bus driver.
+ *
+ * This implementation is very similar to the the virtio bus driver
+ * implementation @ include/linux/virtio.h.
+ */
+#ifndef _MIC_BUS_H_
+#define _MIC_BUS_H_
+/*
+ * Everything a mbus driver needs to work with any particular mbus
+ * implementation.
+ */
+#include linux/types.h
+#include linux/device.h
+#include linux/mod_devicetable.h
+#include linux/interrupt.h
+#include linux/dma-mapping.h
+
+struct mbus_device_id {
+ __u32 device;
+ __u32 vendor;
+};
+
+#define MBUS_DEV_DMA_HOST 2
+#define MBUS_DEV_DMA_MIC 3
+#define MBUS_DEV_ANY_ID 0x
+
+/**
+ * mbus_device - representation of a device using mbus
+ * @priv: private pointer for the driver's use.
+ * @mmio_va: virtual address of mmio space
+ * @hw_ops: the hardware ops supported by this device.
+ * @id: the device type identification (used to match it with a driver).
+ * @dev: underlying device.
+ * be used to communicate with.
+ * @index: unique position on the mbus bus
+ */
+struct mbus_device {
+ void *priv;
+ void __iomem *mmio_va;
+ struct mbus_hw_ops *hw_ops;
+ struct mbus_device_id id;
+ struct device dev;
+ int index;
+};
+
+/**
+ * mbus_driver - operations for a mbus I/O driver
+ * @driver: underlying device driver (populate name and owner).
+ * @id_table: the ids serviced by this driver.
+ * @probe: the function to call when a device is found. Returns 0 or -errno.
+ * @remove: the function to call when a device is removed.
+ */
+struct mbus_driver {
+ struct device_driver driver;
+ const struct mbus_device_id *id_table;
+ int (*probe)(struct mbus_device *dev);
+ void (*scan)(struct mbus_device *dev);
+ void (*remove)(struct mbus_device *dev);
+};
+
+/**
+ * struct mic_irq - opaque pointer used as cookie
+ */
+struct mic_irq;
+
+/**
+ * mbus_hw_ops - Hardware operations for accessing a MIC device on the MIC
bus.
+ */
+struct mbus_hw_ops {
+ struct mic_irq* (*request_threaded_irq)(struct mbus_device *mbdev,
+ irq_handler_t handler, irq_handler_t thread_fn,
+ const char *name, void *data, int intr_src);
+ void (*free_irq)(struct mbus_device *mbdev,
+ struct mic_irq *cookie, void *data);
+ void (*ack_interrupt)(struct mbus_device *mbdev, int num);
+};
Re: [PATCH] x32: Mask away the x32 syscall bit in the ptrace codepath
On 05/28/2014 05:19 AM, Philipp Kern wrote: audit_filter_syscall uses the syscall number to reference into a bitmask (e-rule.mask[word]). Not removing the x32 bit before passing the number to this architecture independent codepath will fail to lookup the proper audit bit. Furthermore it will cause an invalid memory access in the kernel if the out of bound location is not mapped: BUG: unable to handle kernel paging request at 8800e5446630 IP: [810fcdd0] audit_filter_syscall+0x90/0xf0 Together with the entrypoint in entry_64.S this change causes x32 programs to pass in both AUDIT_ARCH_X86_64 and AUDIT_ARCH_I386 depending on the syscall path. Cc: linux-kernel@vger.kernel.org Cc: H. J. Lu hjl.to...@gmail.com Cc: Eric Paris epa...@redhat.com Signed-off-by: Philipp Kern pk...@google.com --- arch/x86/kernel/ptrace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c index 678c0ad..166a3c7 100644 --- a/arch/x86/kernel/ptrace.c +++ b/arch/x86/kernel/ptrace.c @@ -1489,7 +1489,7 @@ long syscall_trace_enter(struct pt_regs *regs) if (IS_IA32) audit_syscall_entry(AUDIT_ARCH_I386, - regs-orig_ax, + regs-orig_ax __SYSCALL_MASK, This is weird. Three questions: 1. How can this happen? I thought that x32 syscalls always came in through the syscall path, which doesn't set is_compat_task. (Can someone rename is_compat_task to in_compat_syscall? Pretty please?) 2. Now audit can't tell whether a syscall is x32 or i386. And audit is inconsistent with seccomp. This seems wrong. 3. The OOPS you're fixing doesn't seem like it's fixed. What if some other random high bits are set? --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/
Re: linux-next: build failure after merge of the final tree
On Wed, 2014-05-28 at 13:42 -0700, Greg KH wrote: Either is fine with me, I can revert it, or apply a fix, which ever you want, just let me know. Well, a proper fix would make this whole episode worthwhile. But if I can't come up with anything that actually builds in a day or two it'll have to be a revert. If that exceeds your patience you're free to hand me a shorter deadline. Paul Bolle -- 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] fence: Use smp_mb__before_atomic()
On Wed, May 28, 2014 at 04:26:32PM +0200, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
Commit febdbfe8a91c (arch: Prepare for smp_mb__{before,after}_atomic())
deprecated the smp_mb__{before,after}_{atomic,clear}_{dec,inc,bit}*()
functions in favour of the unified smp_mb__{before,after}_atomic().
Signed-off-by: Thierry Reding tred...@nvidia.com
---
drivers/base/fence.c | 4 ++--
Where does this file come from? I've not seen it before, and it's not
in my tree.
confused,
greg k-h
--
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] drivercore: refine commit 58b116b drivercore: deferral race condition fix
On Wed, May 21, 2014 at 11:21:43AM +0800, Wei Yang wrote: Hi~ Is this fix reasonable? I'll leave this up to Grant... -- 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 v3] x86/mce: Improve mcheck_init_device() error handling
Thanks too, you helped me a lot. I can do more work, if it's not too difficult for me. Mathieu Le 28/05/2014 11:52, Borislav Petkov a écrit : On Wed, May 28, 2014 at 09:12:37AM +0200, Mathieu Souchaud wrote: Check return code of every function called by mcheck_init_device(). Signed-off-by: Mathieu Souchaud mattieu.souch...@free.fr Applied, thanks! I'll queue it for 3.17 though since we're very close to the 3.16 merge window and this patch hasn't had any linux-next time. Thanks for your good work, let me know if you want to do more around mce. :-) -- 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 1/4] x86, irq: refine mp_register_ioapic() to prepare for IOAPIC hotplug
On Tue, 27 May 2014, Jiang Liu wrote: -static void ioapic_create_irqdomains(void) +static int ioapic_create_irqdomain(int idx) ... -static int __init io_apic_get_redir_entries(int ioapic) +static int io_apic_get_redir_entries(int ioapic) Can you please split the functional changes from the trivial __init removal ones? Thanks, tglx -- 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 v4.1 05/16] PCI: quirk dma_alias_devfn for Marvell devices
Several Marvell devices and a JMicron device have a similar DMA
requester ID problem to Ricoh, except they use function 1 as the
PCIe requester ID. Add a quirk for these to populate the DMA
alias with the correct devfn.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
v4.1: minor commitlog tweak, no code chage
drivers/pci/quirks.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index bc8ebd9..923689f 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3349,6 +3349,42 @@ static void quirk_dma_func0_alias(struct pci_dev *dev)
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_RICOH, 0xe832, quirk_dma_func0_alias);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_RICOH, 0xe476, quirk_dma_func0_alias);
+static void quirk_dma_func1_alias(struct pci_dev *dev)
+{
+ if (PCI_FUNC(dev-devfn) != 1) {
+ dev-dma_alias_devfn = PCI_DEVFN(PCI_SLOT(dev-devfn), 1);
+ dev-dev_flags |= PCI_DEV_FLAGS_DMA_ALIAS_DEVFN;
+ }
+}
+
+/*
+ * Marvell 88SE9123 uses function 1 as the requester ID for DMA. In some
+ * SKUs function 1 is present and is a legacy IDE controller, in other
+ * SKUs this function is not present, making this a ghost requester.
+ * https://bugzilla.kernel.org/show_bug.cgi?id=42679
+ */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9123,
+quirk_dma_func1_alias);
+/* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c14 */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9130,
+quirk_dma_func1_alias);
+/* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c47 + c57 */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9172,
+quirk_dma_func1_alias);
+/* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c59 */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x917a,
+quirk_dma_func1_alias);
+/* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c46 */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x91a0,
+quirk_dma_func1_alias);
+/* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c49 */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9230,
+quirk_dma_func1_alias);
+/* https://bugs.gentoo.org/show_bug.cgi?id=497630 */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_JMICRON,
+PCI_DEVICE_ID_JMICRON_JMB388_ESD,
+quirk_dma_func1_alias);
+
static struct pci_dev *pci_func_0_dma_source(struct pci_dev *dev)
{
if (!PCI_FUNC(dev-devfn))
--
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] base: platform: name the device already during allocation
On Mon, Apr 28, 2014 at 03:09:27PM +0300, Heikki Krogerus wrote:
This allows resources such as GPIOs and clocks, which can be
matched based on the device name when requested, to be
assigned even when PLATFORM_DEVID_AUTO is used.
Why would anyone want to do that?
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
drivers/base/platform.c | 77
++---
1 file changed, 47 insertions(+), 30 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 5b47210..697896d 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -174,11 +174,45 @@ struct platform_object {
*/
void platform_device_put(struct platform_device *pdev)
{
- if (pdev)
- put_device(pdev-dev);
+ if (!pdev)
+ return;
+
+ if (pdev-id_auto) {
+ ida_simple_remove(platform_devid_ida, pdev-id);
+ pdev-id = PLATFORM_DEVID_AUTO;
+ }
+
+ put_device(pdev-dev);
}
EXPORT_SYMBOL_GPL(platform_device_put);
+static int pdev_set_name(struct platform_device *pdev)
+{
+ int ret;
+
+ switch (pdev-id) {
+ default:
+ return dev_set_name(pdev-dev, %s.%d, pdev-name, pdev-id);
+ case PLATFORM_DEVID_NONE:
+ return dev_set_name(pdev-dev, %s, pdev-name);
+ case PLATFORM_DEVID_AUTO:
+ /*
+ * Automatically allocated device ID. We mark it as such so
+ * that we remember it must be freed, and we append a suffix
+ * to avoid namespace collision with explicit IDs.
+ */
+ ret = ida_simple_get(platform_devid_ida, 0, 0, GFP_KERNEL);
+ if (ret 0)
+ return ret;
+ pdev-id = ret;
+ pdev-id_auto = true;
+ return dev_set_name(pdev-dev, %s.%d.auto, pdev-name,
+ pdev-id);
+ }
+
+ return 0;
+}
+
static void platform_device_release(struct device *dev)
{
struct platform_object *pa = container_of(dev, struct platform_object,
@@ -211,6 +245,10 @@ struct platform_device *platform_device_alloc(const char
*name, int id)
device_initialize(pa-pdev.dev);
pa-pdev.dev.release = platform_device_release;
arch_setup_pdev_archdata(pa-pdev);
+ if (pdev_set_name(pa-pdev)) {
+ kfree(pa);
+ return NULL;
+ }
}
return pa ? pa-pdev : NULL;
@@ -291,28 +329,6 @@ int platform_device_add(struct platform_device *pdev)
pdev-dev.bus = platform_bus_type;
- switch (pdev-id) {
- default:
- dev_set_name(pdev-dev, %s.%d, pdev-name, pdev-id);
- break;
- case PLATFORM_DEVID_NONE:
- dev_set_name(pdev-dev, %s, pdev-name);
- break;
- case PLATFORM_DEVID_AUTO:
- /*
- * Automatically allocated device ID. We mark it as such so
- * that we remember it must be freed, and we append a suffix
- * to avoid namespace collision with explicit IDs.
- */
- ret = ida_simple_get(platform_devid_ida, 0, 0, GFP_KERNEL);
- if (ret 0)
- goto err_out;
- pdev-id = ret;
- pdev-id_auto = true;
- dev_set_name(pdev-dev, %s.%d.auto, pdev-name, pdev-id);
- break;
- }
-
for (i = 0; i pdev-num_resources; i++) {
struct resource *p, *r = pdev-resource[i];
@@ -355,7 +371,6 @@ int platform_device_add(struct platform_device *pdev)
release_resource(r);
}
- err_out:
return ret;
}
EXPORT_SYMBOL_GPL(platform_device_add);
@@ -375,11 +390,6 @@ void platform_device_del(struct platform_device *pdev)
if (pdev) {
device_del(pdev-dev);
- if (pdev-id_auto) {
- ida_simple_remove(platform_devid_ida, pdev-id);
- pdev-id = PLATFORM_DEVID_AUTO;
- }
-
for (i = 0; i pdev-num_resources; i++) {
struct resource *r = pdev-resource[i];
unsigned long type = resource_type(r);
@@ -397,8 +407,15 @@ EXPORT_SYMBOL_GPL(platform_device_del);
*/
int platform_device_register(struct platform_device *pdev)
{
+ int ret;
+
device_initialize(pdev-dev);
arch_setup_pdev_archdata(pdev);
+
+ ret = pdev_set_name(pdev);
+ if (ret)
+ return ret;
+
return platform_device_add(pdev);
}
EXPORT_SYMBOL_GPL(platform_device_register);
--
2.0.0.rc0
I don't understand the usage of this, what drivers want/need this
change?
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo
[PATCH v4.1 06/16] PCI: Quirk pci_for_each_dma_alias() for bridges
Several PCIe-to-PCI bridges fail to provide a PCIe capability, causing
us to handle them as conventional PCI devices when they really use the
requester ID of the secondary bus. We need to differentiate these
from PCIe-to-PCI bridges that actually use the conventional PCI ID
when a PCIe capability is not present, such as those found on the root
complex of may Intel chipsets. Add a dev_flag bit to identify devices
to be handled as standard PCIe-to-PCI bridges.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
v4.1: expand commitlog, no code change
drivers/pci/search.c | 10 --
include/linux/pci.h |2 ++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/search.c b/drivers/pci/search.c
index 2c19f3f..df38f73 100644
--- a/drivers/pci/search.c
+++ b/drivers/pci/search.c
@@ -88,8 +88,14 @@ int pci_for_each_dma_alias(struct pci_dev *pdev,
continue;
}
} else {
- ret = fn(tmp, PCI_DEVID(tmp-bus-number, tmp-devfn),
-data);
+ if (tmp-dev_flags PCI_DEV_FLAG_PCIE_BRIDGE_ALIAS)
+ ret = fn(tmp,
+PCI_DEVID(tmp-subordinate-number,
+ PCI_DEVFN(0, 0)), data);
+ else
+ ret = fn(tmp,
+PCI_DEVID(tmp-bus-number,
+ tmp-devfn), data);
if (ret)
return ret;
}
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 9d4035c..85ab35e 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -173,6 +173,8 @@ enum pci_dev_flags {
PCI_DEV_FLAGS_ACS_ENABLED_QUIRK = (__force pci_dev_flags_t) (1 3),
/* Flag to indicate the device uses dma_alias_devfn */
PCI_DEV_FLAGS_DMA_ALIAS_DEVFN = (__force pci_dev_flags_t) (1 4),
+ /* Use a PCIe-to-PCI bridge alias even if !pci_is_pcie */
+ PCI_DEV_FLAG_PCIE_BRIDGE_ALIAS = (__force pci_dev_flags_t) (1 5),
};
enum pci_irq_reroute_variant {
--
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] x32: Mask away the x32 syscall bit in the ptrace codepath
On Wed, May 28, 2014 at 10:47 PM, Andy Lutomirski l...@amacapital.net wrote: On 05/28/2014 05:19 AM, Philipp Kern wrote: audit_filter_syscall uses the syscall number to reference into a bitmask (e-rule.mask[word]). Not removing the x32 bit before passing the number to this architecture independent codepath will fail to lookup the proper audit bit. Furthermore it will cause an invalid memory access in the kernel if the out of bound location is not mapped: BUG: unable to handle kernel paging request at 8800e5446630 IP: [810fcdd0] audit_filter_syscall+0x90/0xf0 Together with the entrypoint in entry_64.S this change causes x32 programs to pass in both AUDIT_ARCH_X86_64 and AUDIT_ARCH_I386 depending on the syscall path. Cc: linux-kernel@vger.kernel.org Cc: H. J. Lu hjl.to...@gmail.com Cc: Eric Paris epa...@redhat.com Signed-off-by: Philipp Kern pk...@google.com --- arch/x86/kernel/ptrace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c index 678c0ad..166a3c7 100644 --- a/arch/x86/kernel/ptrace.c +++ b/arch/x86/kernel/ptrace.c @@ -1489,7 +1489,7 @@ long syscall_trace_enter(struct pt_regs *regs) if (IS_IA32) audit_syscall_entry(AUDIT_ARCH_I386, - regs-orig_ax, + regs-orig_ax __SYSCALL_MASK, This is weird. Three questions: 1. How can this happen? I thought that x32 syscalls always came in through the syscall path, which doesn't set is_compat_task. (Can someone rename is_compat_task to in_compat_syscall? Pretty please?) The other patch is this one: https://lkml.org/lkml/2014/5/26/209 But I agree: IS_IA32 is confusing but it does trigger on x32 tasks. I put that into a bug report but apparently not into the patch description, I'm sorry. is_compat_task is defined as is_ia32_task() || is_x32_task(). 2. Now audit can't tell whether a syscall is x32 or i386. And audit is inconsistent with seccomp. This seems wrong. I'm not sure where seccomp is hooked in. Can you point me to the entry points here? ptrace still requires that userspace sees the x32 bit so it cannot be masked beforehand. The path the other patch fixes masks the bit away directly after the audit call. 3. The OOPS you're fixing doesn't seem like it's fixed. What if some other random high bits are set? Fair point. I guess we should check against AUDIT_BITMASK_SIZE as that is the size of the array we are referencing into. But what would we do in case it's larger? Those are not ENOSYS'ed yet in the entry_64.S path. That's after tracing and auditing. Kind regards and thanks Philipp Kern -- 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] x32: Mask away the x32 syscall bit in the ptrace codepath
On 05/28/2014 01:47 PM, Andy Lutomirski wrote: On 05/28/2014 05:19 AM, Philipp Kern wrote: audit_filter_syscall uses the syscall number to reference into a bitmask (e-rule.mask[word]). Not removing the x32 bit before passing the number to this architecture independent codepath will fail to lookup the proper audit bit. Furthermore it will cause an invalid memory access in the kernel if the out of bound location is not mapped: BUG: unable to handle kernel paging request at 8800e5446630 IP: [810fcdd0] audit_filter_syscall+0x90/0xf0 Together with the entrypoint in entry_64.S this change causes x32 programs to pass in both AUDIT_ARCH_X86_64 and AUDIT_ARCH_I386 depending on the syscall path. Cc: linux-kernel@vger.kernel.org Cc: H. J. Lu hjl.to...@gmail.com Cc: Eric Paris epa...@redhat.com Signed-off-by: Philipp Kern pk...@google.com --- arch/x86/kernel/ptrace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c index 678c0ad..166a3c7 100644 --- a/arch/x86/kernel/ptrace.c +++ b/arch/x86/kernel/ptrace.c @@ -1489,7 +1489,7 @@ long syscall_trace_enter(struct pt_regs *regs) if (IS_IA32) audit_syscall_entry(AUDIT_ARCH_I386, -regs-orig_ax, +regs-orig_ax __SYSCALL_MASK, This is weird. Three questions: 1. How can this happen? I thought that x32 syscalls always came in through the syscall path, which doesn't set is_compat_task. (Can someone rename is_compat_task to in_compat_syscall? Pretty please?) The SYSCALL path doesn't set TS_COMPAT, but is_compat_task() looks both as TS_COMPAT and bit 30 of orig_ax. I think what is really needed here is IS_IA32 should use is_ia32_task() instead, and *that* is the context we can mask off the x32 bit in at all. However, does audit not need that information? (And why the frakk does audit receive the first four syscall arguments? Audit seems like the worst turd ever...) 2. Now audit can't tell whether a syscall is x32 or i386. And audit is inconsistent with seccomp. This seems wrong. This is completely and totally bogus, indeed. 3. The OOPS you're fixing doesn't seem like it's fixed. What if some other random high bits are set? There is a range check in entry_*.S for the system call. -hpa -- 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] IIO: Add iio magn_north ABI documentation
Update documentation for HID compass true/magnetic north sensor. Signed-off-by: Reyad Attiyat reyad.atti...@gmail.com --- Documentation/ABI/testing/sysfs-bus-iio | 76 + 1 file changed, 76 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 6e02c50..0341b2f 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -165,6 +165,10 @@ Description: What: /sys/bus/iio/devices/iio:deviceX/in_magn_x_raw What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_raw What: /sys/bus/iio/devices/iio:deviceX/in_magn_z_raw +What: /sys/bus/iio/devices/iio:deviceX/in_magn_north_raw +What: /sys/bus/iio/devices/iio:deviceX/in_magn_north_true_raw +What: /sys/bus/iio/devices/iio:deviceX/in_magn_north_tilt_comp_raw +What: /sys/bus/iio/devices/iio:deviceX/in_magn_north_true_tilt_comp_raw KernelVersion: 2.6.35 Contact: linux-...@vger.kernel.org Description: @@ -249,6 +253,10 @@ What: /sys/bus/iio/devices/iio:deviceX/in_magn_scale What: /sys/bus/iio/devices/iio:deviceX/in_magn_x_scale What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_scale What: /sys/bus/iio/devices/iio:deviceX/in_magn_z_scale +What: /sys/bus/iio/devices/iio:deviceX/in_magn_north_scale +What: /sys/bus/iio/devices/iio:deviceX/in_magn_north_true_scale +What: /sys/bus/iio/devices/iio:deviceX/in_magn_north_tilt_comp_scale +What: /sys/bus/iio/devices/iio:deviceX/in_magn_north_true_tilt_comp_scale What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_scale What: /sys/bus/iio/devices/iio:deviceX/in_pressure_scale KernelVersion: 2.6.35 @@ -436,6 +444,14 @@ What: /sys/.../iio:deviceX/events/in_magn_y_thresh_rising_en What: /sys/.../iio:deviceX/events/in_magn_y_thresh_falling_en What: /sys/.../iio:deviceX/events/in_magn_z_thresh_rising_en What: /sys/.../iio:deviceX/events/in_magn_z_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_magn_north_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_magn_north_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_magn_north_true_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_magn_north_true_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_magn_north_tilt_comp_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_magn_north_tilt_comp_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_magn_north_true_tilt_comp_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_magn_north_true_tilt_comp_thresh_falling_en What: /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_rising_en What: /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_falling_en What: /sys/.../iio:deviceX/events/in_voltageY_thresh_rising_en @@ -481,6 +497,14 @@ What: /sys/.../iio:deviceX/events/in_magn_y_roc_rising_en What: /sys/.../iio:deviceX/events/in_magn_y_roc_falling_en What: /sys/.../iio:deviceX/events/in_magn_z_roc_rising_en What: /sys/.../iio:deviceX/events/in_magn_z_roc_falling_en +What: /sys/.../iio:deviceX/events/in_magn_north_roc_rising_en +What: /sys/.../iio:deviceX/events/in_magn_north_roc_falling_en +What: /sys/.../iio:deviceX/events/in_magn_north_true_roc_rising_en +What: /sys/.../iio:deviceX/events/in_magn_north_true_roc_falling_en +What: /sys/.../iio:deviceX/events/in_magn_north_tilt_comp_roc_rising_en +What: /sys/.../iio:deviceX/events/in_magn_north_tilt_comp_roc_falling_en +What: /sys/.../iio:deviceX/events/in_magn_north_true_tilt_comp_roc_rising_en +What: /sys/.../iio:deviceX/events/in_magn_north_true_tilt_comp_roc_falling_en What: /sys/.../iio:deviceX/events/in_voltageY_supply_roc_rising_en What: /sys/.../iio:deviceX/events/in_voltageY_supply_roc_falling_en What: /sys/.../iio:deviceX/events/in_voltageY_roc_rising_en @@ -527,6 +551,14 @@ What: /sys/.../events/in_magn_y_raw_thresh_rising_value What: /sys/.../events/in_magn_y_raw_thresh_falling_value What: /sys/.../events/in_magn_z_raw_thresh_rising_value What: /sys/.../events/in_magn_z_raw_thresh_falling_value +What: /sys/.../events/in_magn_north_raw_thresh_rising_value +What: /sys/.../events/in_magn_north_raw_thresh_falling_value +What: /sys/.../events/in_magn_north_true_raw_thresh_rising_value +What: /sys/.../events/in_magn_north_true_raw_thresh_falling_value +What: /sys/.../events/in_magn_north_tilt_comp_raw_thresh_rising_value +What: /sys/.../events/in_magn_north_tilt_comp_raw_thresh_falling_value +What:
[PATCH 2/3] IIO: Add iio_chan modifier for True/Magnetic North HID usages
Updated iio_chan_info_enum for compass north sensor usages,
including magnetic/true north and tilt compensation.
Signed-off-by: Reyad Attiyat reyad.atti...@gmail.com
---
drivers/iio/industrialio-core.c | 4
include/linux/iio/types.h | 4
2 files changed, 8 insertions(+)
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index ede16aec..41bd377 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -84,6 +84,10 @@ static const char * const iio_modifier_names[] = {
[IIO_MOD_LIGHT_RED] = red,
[IIO_MOD_LIGHT_GREEN] = green,
[IIO_MOD_LIGHT_BLUE] = blue,
+ [IIO_MOD_MAGN_NORTH] = north,
+ [IIO_MOD_MAGN_NORTH_TRUE] = north_true,
+ [IIO_MOD_MAGN_NORTH_TILT_COMP] = north_tilt_comp,
+ [IIO_MOD_MAGN_NORTH_TRUE_TILT_COMP] = north_true_tilt_comp,
};
/* relies on pairs of these shared then separate */
diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
index 084d882..f1e8be6 100644
--- a/include/linux/iio/types.h
+++ b/include/linux/iio/types.h
@@ -53,6 +53,10 @@ enum iio_modifier {
IIO_MOD_LIGHT_RED,
IIO_MOD_LIGHT_GREEN,
IIO_MOD_LIGHT_BLUE,
+ IIO_MOD_MAGN_NORTH,
+ IIO_MOD_MAGN_NORTH_TRUE,
+ IIO_MOD_MAGN_NORTH_TILT_COMP,
+ IIO_MOD_MAGN_NORTH_TRUE_TILT_COMP
};
enum iio_event_type {
--
1.9.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/
[PATCH 3/3] IO: hid-sensor-magn-3d: Add in support for True/Magnetic North HID usages
Updated magn_3d_channel enum for all possible north channels
Added functions to setup iio_chan_spec array depending on
a hid usage report
Renamed magn_val to iio_val to differentiate the index being used
Updated magn_3d_state struct to hold pointer array (magn_val_addr[]) to
iio_val and a count of the iio channels found
Updated magn_3d_parse_report to scan for all compass usages
and create channels for each
Signed-off-by: Reyad Attiyat reyad.atti...@gmail.com
---
drivers/iio/magnetometer/hid-sensor-magn-3d.c | 278 +-
1 file changed, 183 insertions(+), 95 deletions(-)
diff --git a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
index 6d162b7..7ffac17 100644
--- a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
+++ b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
@@ -34,63 +34,54 @@ enum magn_3d_channel {
CHANNEL_SCAN_INDEX_X,
CHANNEL_SCAN_INDEX_Y,
CHANNEL_SCAN_INDEX_Z,
+ CHANNEL_SCAN_INDEX_NORTH,
+ CHANNEL_SCAN_INDEX_NORTH_TRUE,
+ CHANNEL_SCAN_INDEX_NORTH_TILT_COMP,
+ CHANNEL_SCAN_INDEX_NORTH_TRUE_TILT_COMP,
MAGN_3D_CHANNEL_MAX,
};
+#define IIO_CHANNEL_MAX MAGN_3D_CHANNEL_MAX
+
struct magn_3d_state {
struct hid_sensor_hub_callbacks callbacks;
struct hid_sensor_common common_attributes;
struct hid_sensor_hub_attribute_info magn[MAGN_3D_CHANNEL_MAX];
- u32 magn_val[MAGN_3D_CHANNEL_MAX];
-};
+ u32 *magn_val_addr[MAGN_3D_CHANNEL_MAX];
-static const u32 magn_3d_addresses[MAGN_3D_CHANNEL_MAX] = {
- HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_X_AXIS,
- HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Y_AXIS,
- HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Z_AXIS
+ u32 iio_val[IIO_CHANNEL_MAX];
+ int num_iio_channels;
};
-/* Channel definitions */
-static const struct iio_chan_spec magn_3d_channels[] = {
- {
- .type = IIO_MAGN,
- .modified = 1,
- .channel2 = IIO_MOD_X,
- .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OFFSET) |
- BIT(IIO_CHAN_INFO_SCALE) |
- BIT(IIO_CHAN_INFO_SAMP_FREQ) |
- BIT(IIO_CHAN_INFO_HYSTERESIS),
- .scan_index = CHANNEL_SCAN_INDEX_X,
- }, {
- .type = IIO_MAGN,
- .modified = 1,
- .channel2 = IIO_MOD_Y,
- .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OFFSET) |
- BIT(IIO_CHAN_INFO_SCALE) |
- BIT(IIO_CHAN_INFO_SAMP_FREQ) |
- BIT(IIO_CHAN_INFO_HYSTERESIS),
- .scan_index = CHANNEL_SCAN_INDEX_Y,
- }, {
- .type = IIO_MAGN,
- .modified = 1,
- .channel2 = IIO_MOD_Z,
- .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OFFSET) |
- BIT(IIO_CHAN_INFO_SCALE) |
- BIT(IIO_CHAN_INFO_SAMP_FREQ) |
- BIT(IIO_CHAN_INFO_HYSTERESIS),
- .scan_index = CHANNEL_SCAN_INDEX_Z,
+/* Find index into magn_3d_state magn[] and magn_val_addr[] from HID Usage */
+static int magn_3d_usage_id_to_chan_index(unsigned usage_id){
+ int offset = -1;
+
+ switch (usage_id) {
+ case HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_X_AXIS:
+ offset = CHANNEL_SCAN_INDEX_X;
+ break;
+ case HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Y_AXIS:
+ offset = CHANNEL_SCAN_INDEX_Y;
+ break;
+ case HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Z_AXIS:
+ offset = CHANNEL_SCAN_INDEX_Z;
+ break;
+ case HID_USAGE_SENSOR_ORIENT_COMP_MAGN_NORTH:
+ offset = CHANNEL_SCAN_INDEX_NORTH_TILT_COMP;
+ break;
+ case HID_USAGE_SENSOR_ORIENT_COMP_TRUE_NORTH:
+ offset = CHANNEL_SCAN_INDEX_NORTH_TRUE_TILT_COMP;
+ break;
+ case HID_USAGE_SENSOR_ORIENT_MAGN_NORTH:
+ offset = CHANNEL_SCAN_INDEX_NORTH;
+ break;
+ case HID_USAGE_SENSOR_ORIENT_TRUE_NORTH:
+ offset = CHANNEL_SCAN_INDEX_NORTH_TRUE;
+ break;
}
-};
-/* Adjust channel real bits based on report descriptor */
-static void magn_3d_adjust_channel_bit_mask(struct iio_chan_spec *channels,
- int channel, int size)
-{
- channels[channel].scan_type.sign = 's';
- /* Real storage bits will change based on the report desc. */
- channels[channel].scan_type.realbits = size * 8;
- /* Maximum size of a sample to capture is u32 */
- channels[channel].scan_type.storagebits = sizeof(u32) * 8;
+ return offset;
}
/* Channel read_raw handler */
@@ -101,21 +92,31 @@ static int magn_3d_read_raw(struct iio_dev *indio_dev,
{
struct magn_3d_state *magn_state = iio_priv(indio_dev);
int report_id = -1;
- u32 address;
+ unsigned usage_id;
+ int chan_index = -1;
int ret;
int
[PATCH 0/3] IIO: hid-sensor-magn-3d: Add support for compass north usage attribute
Update hid-sensor-magn-3d to dynamically create IIO channels Update IIO to include modifiers for true/magnetic north and tilt compensation compass usages Signed-off-by: Reyad Attiyat reyad.atti...@gmail.com Reyad Attiyat (3): IIO: Added iio magn_north ABI documentation IIO: Add iio_chan modifier for True/Magnetic North HID usages IO: hid-sensor-magn-3d: Add in support for True/Magnetic North HID usages Documentation/ABI/testing/sysfs-bus-iio | 76 +++ drivers/iio/industrialio-core.c | 4 + drivers/iio/magnetometer/hid-sensor-magn-3d.c | 278 +- include/linux/iio/types.h | 4 + 4 files changed, 267 insertions(+), 95 deletions(-) -- 1.9.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/
Re: [Patch V3 19/37] x86, irq: introduce mechanisms to support dynamically allocate IRQ for IOAPIC
On Wed, 28 May 2014, Jiang Liu wrote: On 2014/5/28 3:58, Thomas Gleixner wrote: So you have these cases covered here: 1) The ACPI case of secondary ioapics. You only have the strict 1:1 mapping for the first ioapic 2) The gsi NR_IRQS_LEGACY case where you have two options: a) Let the core create a random virq number if ioapic_identity_map is 0 ioapic_identity_map is only set by SFI and devicetree So in all other cases we fall into that code path for all legacy interrupts. So how is that supposed to work lets say for i8042 which has hardcoded irq 1 and 12? irq_create_mapping(1) hint = 1 % nr_irqs; -- 1 virq = irq_alloc_desc_from(hint, of_node_to_nid(domain-of_node)); This returns something = 16, because the irq descriptors for 0-15 (LEGACY) are allocated already. The pin association works, but how is the i8042 driver supposed to figure out that it should request the virq =16 which was created instead of the hardcoded 1 ? This is used to work around special non-ISA interrupts with GSI below NR_IRQS_LEGACY. The original code for the special case is: /* * Provide an identity mapping of gsi == irq except on truly * weird platforms that have non isa irqs in the first 16 gsis. */ return gsi = NR_IRQS_LEGACY ? gsi : gsi_top + gsi; That looks really, really wrong. What's wrong with assigning that irq irq number on those platforms? The weird stuff is SFI and devicetree, if I understand your code correctly. So if those platforms do not have actual legacy irqs, what's wrong with giving out the legacy numbers? We have one path to handle ISA IRQs before calling alloc_irq_from_domain() as below: if (idx = 0 test_bit(mp_irqs[idx].srcbus, mp_bus_not_pci)) return mp_irqs[idx].srcbusirq; Ok. /* We can't set this earlier, because we need to calibrate the timer */ legacy_pic = null_legacy_pic; I haven't figured out the story behind the comment yet:( Sebastian gave some insight. Why do we need strict mappings in the non ACPI case for all ioapic pins? What's so different about ACPI? Or is this just to avoid breaking the existing SFI/devicetree stuff. If that's the reason I'm fine with it, but ... It's to avoid breaking SFI/intel_mid stuff. intel_mid assumes IRQ number equals to pin number and use pci_dev-irq to save both IRQ number and pin number. Fair enough. Thanks, tglx -- 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 01/27] mtd: nand: introduce function to fix a common bug in most nand-drivers not showing a device in sysfs
Am 28.05.2014 22:10, schrieb Brian Norris:
On Wed, May 28, 2014 at 08:52:06PM +0200, Alexander Holler wrote:
Am 28.05.2014 10:43, schrieb Brian Norris:
On Tue, May 27, 2014 at 12:12:26AM +0200, Alexander Holler wrote:
+{
+ mtd-priv = priv;
I don't think you should hide this one here. It will be quite obvious if
a driver didn't stash its private data but tries to access it later. Are
there any drivers that missed this?
No, it just saves a line of source in all drivers and I think it
fits there. I don't understand why do you think it is hidden.
The function name doesn't make it obvious what it's doing. So all code
readers will have to follow the definition to see what it's doing. But
this point is not that important, so I won't argue.
So you think every function does hide important things? How's about C?
It hides which registers are used. Maybe we should go back to assembler.
But I prefer to just press ctrl-} in vim.
+ mtd-owner = pdev-dev.driver-owner;
+ mtd-dev.parent = pdev-dev;
+ mtd-name = pdev-dev.driver-name;
I think this is a little dangerous. You're potentially clobbering the
name that a driver already chose here. And why did you pick to use the
It's a dangerous world. And ordering sometimes matters. Feel free to
post another patch where you add an if() or an if (). I don't care which
style you prefer, but checkpatch would want the second one.
And as I currently don't see your argument to use the driver instead of
the platform device, here's an argument why I prefer to use pdev:
someone might want to use the upper layer (here the platform device) in
that silly function in the future. A very personal decision I did., but...
driver name? This gives non-unique names if there is more than one
device instantiated for a driver. That's why some drivers already use
the device name, not the driver name:
mtd-name = dev_name(pev-dev);
And in fact, if any drivers are missing mtd-name, perhaps it's best to
just modify the MTD registration to give them a default:
if (!mtd-name)
mtd-name = dev_name(pdev-dev);
+}
I don't clobber any name. The name is set as default before drivers
might do this.
BTW. I don't like what dev_name produces. E.g. on one box I use here
devname would produce f400.nand instead orion_nand. So I would have
to name partitons with f400.nand. I don't understand why someone
would prefer f400.nand instead of orion_nand, but I accept that
other people do so. I don't have to understand everything.
At the moment this is true, but the ordering is somewhat subtle if you
don't examine the details of mtd_setup_common_members() to see that it
is assigning a name. I can easily imagine some new driver in which
someone does:
mtd-name = ...;
[...]
mtd_setup_common_members(mtd, priv, pdev);
And doesn't notice that the ordering matters.
You could make this simpler by either
(1) making mtd_setup_common_members() check for mtd-name==NULL first
(2) just move the (default) name assignment to the common MTD
registration, like I suggested
+
extern int mtd_device_parse_register(struct mtd_info *mtd,
const char * const *part_probe_types,
struct mtd_part_parser_data *parser_data,
How about we rethink the helper approach, and instead just do
validation in the core code? This would cover most of the important
parts of your helper, I think:
Feel free to change all drivers. I like my approach with fixing 21
bugs by reducing code by 44 lines.
I appreciate the bug fixes. I am just questioning the approach. Reduced
(source) code doesn't help anyone if it makes the code less
maintainable. My suggestions can probably make this more maintainable,
fix the same bugs, and reduce the source by a similar (albeit smaller)
number of lines.
And it offers a common function where future similiarities can be
put into too. Of course you can just add 21 lines, but that is not
how I do such stuff.
I don't see how your common location helps much more than putting it in
mtdcore.c like I suggested, without the extra function.
And I did the patches. If you don't like them, feel free to ignore
them. I'm not playing remote keyboard but I do patches like I would
do them, not like some arbitrary maintainer would do them. Sorry for
the harsh words.
Arbitrary maintainer, eh? I'm simply suggesting that this could be
accomplished in a better way. If you don't want to take part in the
review process, then I have no obligation to engage either.
TIMTOWTDI. Humans are different, they think different, they write
different code, they see code different and they prefer different
styles. And what you think is a better way, isn't one in my point of
view. And I prefer to not discuss such silly things like this simple 4
line function.
I'm very sorry, but I find such discussions extremly tiresome.
If you just would have suggested
Re: fs/dcache.c - BUG: soft lockup - CPU#5 stuck for 22s! [systemd-udevd:1667]
On Wed, May 28, 2014 at 1:14 PM, Al Viro v...@zeniv.linux.org.uk wrote: Unless I'm badly misreading your patch, you are calling dentry_kill() with rcu_read_lock() held. And that can trigger all sorts of interesting things, starting with iput() and tons of disk IO... Yes, right you are. As to my worry: d_walk() covers its arse with -d_lock (and it wants the starting point to be pinned, obviously). So AFAICS RCU is not a problem. It's not RCU itself, it's that DCACHE_MAY_FREE bit. Yes, d_walk() gets -d_lock, but dentry_kill() drops d_lock in the middle, and the whole dentry_kill() can get called multiple times for the same dentry just makes me go Hmm. It is *not* obvious what happens the second vs third time that gets called. If it can get called two times, why not three times? And if it can get called three times, why can't _two_ of them set can_free to true? That is absolutely *not* obvious to me. The aim of my patch (and I agree that sadly holding the rcu lock is not viable) was to make that if it gets called twice case _much_ more obvious. Because any but the first time will be very obviously a no-op (apart from taking and releasing the lock, which is ok for a rcu-delayed data structure). That's very much not the case with DCACHE_MAY_FREE. The behavior of that things os very much non-obvious, because different callers into dentry_kill() all do different things. 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: linux-next: build failure after merge of the final tree
On Wed, May 28, 2014 at 10:48:02PM +0200, Paul Bolle wrote: On Wed, 2014-05-28 at 13:42 -0700, Greg KH wrote: Either is fine with me, I can revert it, or apply a fix, which ever you want, just let me know. Well, a proper fix would make this whole episode worthwhile. But if I can't come up with anything that actually builds in a day or two it'll have to be a revert. If that exceeds your patience you're free to hand me a shorter deadline. How about I revert it now, that way you can provide a proper fix whenever you get the chance. thanks, greg k-h -- 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] x32: Mask away the x32 syscall bit in the ptrace codepath
On Wed, May 28, 2014 at 2:01 PM, H. Peter Anvin h...@linux.intel.com wrote: On 05/28/2014 01:47 PM, Andy Lutomirski wrote: On 05/28/2014 05:19 AM, Philipp Kern wrote: audit_filter_syscall uses the syscall number to reference into a bitmask (e-rule.mask[word]). Not removing the x32 bit before passing the number to this architecture independent codepath will fail to lookup the proper audit bit. Furthermore it will cause an invalid memory access in the kernel if the out of bound location is not mapped: BUG: unable to handle kernel paging request at 8800e5446630 IP: [810fcdd0] audit_filter_syscall+0x90/0xf0 Together with the entrypoint in entry_64.S this change causes x32 programs to pass in both AUDIT_ARCH_X86_64 and AUDIT_ARCH_I386 depending on the syscall path. Cc: linux-kernel@vger.kernel.org Cc: H. J. Lu hjl.to...@gmail.com Cc: Eric Paris epa...@redhat.com Signed-off-by: Philipp Kern pk...@google.com --- arch/x86/kernel/ptrace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c index 678c0ad..166a3c7 100644 --- a/arch/x86/kernel/ptrace.c +++ b/arch/x86/kernel/ptrace.c @@ -1489,7 +1489,7 @@ long syscall_trace_enter(struct pt_regs *regs) if (IS_IA32) audit_syscall_entry(AUDIT_ARCH_I386, -regs-orig_ax, +regs-orig_ax __SYSCALL_MASK, This is weird. Three questions: 1. How can this happen? I thought that x32 syscalls always came in through the syscall path, which doesn't set is_compat_task. (Can someone rename is_compat_task to in_compat_syscall? Pretty please?) The SYSCALL path doesn't set TS_COMPAT, but is_compat_task() looks both as TS_COMPAT and bit 30 of orig_ax. I think what is really needed here is IS_IA32 should use is_ia32_task() instead, and *that* is the context we can mask off the x32 bit in at all. However, does audit not need that information? This is thoroughly fscked up. What *should* have happened is that there should have been an AUDIT_ARCH_X32. Unfortunately no one caught that in time, so the current enshrined ABI is that, as far as seccomp is concerned, x32 is AUDIT_ARCH_X86_64 (see syscall_get_arch) but nr has the x32 bit set. But the audit code is different: x32 is AUDIT_ARCH_I386 and the x32 bit is set. This may be changeable, since fixes to the audit ABI may not break anything. Can we just use syscall_get_arch to determine the token to pass to the audit code? If it makes everyone feel better, I think that every single architecture has screwed this up. We actually had to prevent seccomp and audit from being configured in on any OABI-supporting ARM kernel, and MIPS almost did the same thing that x32 did. We caught that one on time, and it's now fixed in Linus' tree. (And why the frakk does audit receive the first four syscall arguments? Audit seems like the worst turd ever...) If you ever benchmark the performance impact of merely running auditd, you might have to upgrade that insult :-/ 2. Now audit can't tell whether a syscall is x32 or i386. And audit is inconsistent with seccomp. This seems wrong. This is completely and totally bogus, indeed. I'd suggest just fixing the bug in auditsc.c. 3. The OOPS you're fixing doesn't seem like it's fixed. What if some other random high bits are set? There is a range check in entry_*.S for the system call. I can imagine that causing a certain amount of confusion to fancy seccomp users. Oh, well. No one that I know of has complained yet. --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/
Re: [PATCH 3/3] IO: hid-sensor-magn-3d: Add in support for True/Magnetic North HID usages
+static void sensor_hub_fill_attr_info(
+ struct hid_sensor_hub_attribute_info *info,
+ s32 index, s32 report_id, struct hid_field *field)
+{
+ info-index = index;
+ info-report_id = report_id;
+ info-units = field-unit;
+ info-unit_expo = field-unit_exponent;
+ info-size = (field-report_size * field-report_count)/8;
+ info-logical_minimum = field-logical_minimum;
+ info-logical_maximum = field-logical_maximum;
}
I copied this function from hid/hid-sensor-hub.c as it is marked
static in that file. I use it to fill attributes as I find them.
Should I create an another patch to make it non-static?
+ list_for_each_entry(report, report_enum-report_list, list) {
+ for (i = 0; i report-maxfield; ++i) {
+ field = report-field[i];
+
+ for (j = 0; j field-maxusage; j++) {
+ usage = (field-usage[j]);
+
This is how I mange to find all possible hid reports in the parse
reports function. I noticed that in the other function that was used,
sensor_hub_input_get_attribute_info(), it only uses field-usage[0].
Is there a reason for this and should I change my current
implementation?
--
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/
kredīta piedāvājums
Laba diena, Mēs esam DIAMOND ŠVEICES aizdevumu uzņēmumam sniedzot aizdevumus ar pasta reklāma. Mēs piedāvājam dažāda veida aizdevumu (īstermiņa un ilgtermiņa aizdevumi, individuālie aizņēmumi, aizdevumi uzņēmumiem uc), par 3% procentu likmi. Mēs izsniegt aizdevumus cilvēkiem, kam nepieciešama ne neatkarīgi no to atrašanās vietas, dzimuma, ģimenes stāvokļa, izglītības, nodarbinātības statusu, bet ir jābūt ar tiesiskiem līdzekļiem atmaksu. Mūsu aizdevumu svārstās no 5,000.00 līdz 10,000,000.00 ASV dolāru vai eiro, vai mārciņa ar maksimālo ilgumu 20 gadi. Ja jūs interesē vairāk informācijas, lūdzu, aizpildiet zemāk esošo formu un nosūtiet to uz mūsu e-pasta adresi: diamond_swisslo...@outlook.com Lūdzu, aizpildiet: vārds: adrese: vecums: dzimums: Kontaktu Tālrunis: Nodarbošanās: Ikmēneša ienākumi: Nepieciešama aizdevuma summa: Ilgums aizdevums: Aizdevuma mērķis: Valsts: ZIP kods: Mēs parādīsim jums labāku veidu, lai jūsu finansiālo brīvību Ar cieņu, Mr Diamond Peters (Managing Director). Mr Bill Anthony (mārketinga vadītājs) -- 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] x32: Mask away the x32 syscall bit in the ptrace codepath
On 05/28/2014 02:15 PM, Andy Lutomirski wrote: 3. The OOPS you're fixing doesn't seem like it's fixed. What if some other random high bits are set? There is a range check in entry_*.S for the system call. I can imagine that causing a certain amount of confusion to fancy seccomp users. Oh, well. No one that I know of has complained yet. I don't know how seccomp or audit deal with out-of-range syscall numbers, so that might be worth taking a look at. -hpa -- 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 3/3] IO: hid-sensor-magn-3d: Add in support for True/Magnetic North HID usages
On 05/28/2014 02:15 PM, Reyad Attiyat wrote:
+static void sensor_hub_fill_attr_info(
+ struct hid_sensor_hub_attribute_info *info,
+ s32 index, s32 report_id, struct hid_field *field)
+{
+ info-index = index;
+ info-report_id = report_id;
+ info-units = field-unit;
+ info-unit_expo = field-unit_exponent;
+ info-size = (field-report_size * field-report_count)/8;
+ info-logical_minimum = field-logical_minimum;
+ info-logical_maximum = field-logical_maximum;
}
I copied this function from hid/hid-sensor-hub.c as it is marked
static in that file. I use it to fill attributes as I find them.
Should I create an another patch to make it non-static?
I didn't check your implementation. But
sensor_hub_input_get_attribute_info()
function is not enough? We are already using to get other attributes for
x, y and Z.
Thanks,
Srinivas
+ list_for_each_entry(report, report_enum-report_list, list) {
+ for (i = 0; i report-maxfield; ++i) {
+ field = report-field[i];
+
+ for (j = 0; j field-maxusage; j++) {
+ usage = (field-usage[j]);
+
This is how I mange to find all possible hid reports in the parse
reports function. I noticed that in the other function that was used,
sensor_hub_input_get_attribute_info(), it only uses field-usage[0].
Is there a reason for this and should I change my current
implementation?
--
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 V3 19/37] x86, irq: introduce mechanisms to support dynamically allocate IRQ for IOAPIC
On Wed, 28 May 2014, Thomas Gleixner wrote: On Wed, 28 May 2014, Jiang Liu wrote: This is used to work around special non-ISA interrupts with GSI below NR_IRQS_LEGACY. The original code for the special case is: /* * Provide an identity mapping of gsi == irq except on truly * weird platforms that have non isa irqs in the first 16 gsis. */ return gsi = NR_IRQS_LEGACY ? gsi : gsi_top + gsi; That looks really, really wrong. What's wrong with assigning that irq irq number on those platforms? The weird stuff is SFI and devicetree, if I understand your code correctly. So if those platforms do not have actual legacy irqs, what's wrong with giving out the legacy numbers? Though if it's a real issue, we can simply mark the ioapic on those devices as DYNAMIC and avoid that whole magic. Thanks, tglx -- 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/
[tip:x86/platform] x86, iosf: Make IOSF driver modular and usable by more drivers
Commit-ID: 6b8f0c8780c71d78624f736d7849645b64cc88b7
Gitweb: http://git.kernel.org/tip/6b8f0c8780c71d78624f736d7849645b64cc88b7
Author: David E. Box david.e@linux.intel.com
AuthorDate: Fri, 9 May 2014 13:44:05 -0700
Committer: H. Peter Anvin h...@linux.intel.com
CommitDate: Fri, 9 May 2014 14:56:15 -0700
x86, iosf: Make IOSF driver modular and usable by more drivers
Currently drivers that run on non-IOSF systems (Core/Xeon) can't use the IOSF
driver on SOC's without selecting it which forces an unnecessary and limiting
dependency. Provides dummy functions to allow these modules to conditionally
use the driver on IOSF equipped platforms without impacting their ability to
compile and load on non-IOSF platforms. Build default m to ensure availability
on x86 SOC's.
Signed-off-by: David E. Box david.e@linux.intel.com
Link:
http://lkml.kernel.org/r/1399668248-24199-2-git-send-email-david.e@linux.intel.com
Signed-off-by: H. Peter Anvin h...@linux.intel.com
---
arch/x86/Kconfig| 7 ++-
arch/x86/include/asm/iosf_mbi.h | 33 +
arch/x86/kernel/iosf_mbi.c | 7 +++
3 files changed, 42 insertions(+), 5 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 25d2c6f..f1304d3 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2375,12 +2375,9 @@ config X86_DMA_REMAP
depends on STA2X11
config IOSF_MBI
- bool
+ tristate
+ default m
depends on PCI
- ---help---
- To be selected by modules requiring access to the Intel OnChip System
- Fabric (IOSF) Sideband MailBox Interface (MBI). For MBI platforms
- enumerable by PCI.
source net/Kconfig
diff --git a/arch/x86/include/asm/iosf_mbi.h b/arch/x86/include/asm/iosf_mbi.h
index 8e71c79..1a91a36 100644
--- a/arch/x86/include/asm/iosf_mbi.h
+++ b/arch/x86/include/asm/iosf_mbi.h
@@ -50,6 +50,10 @@
#define BT_MBI_PCIE_READ 0x00
#define BT_MBI_PCIE_WRITE 0x01
+#if IS_ENABLED(CONFIG_IOSF_MBI)
+
+bool iosf_mbi_available(void);
+
/**
* iosf_mbi_read() - MailBox Interface read command
* @port: port indicating subunit being accessed
@@ -87,4 +91,33 @@ int iosf_mbi_write(u8 port, u8 opcode, u32 offset, u32 mdr);
*/
int iosf_mbi_modify(u8 port, u8 opcode, u32 offset, u32 mdr, u32 mask);
+#else /* CONFIG_IOSF_MBI is not enabled */
+static inline
+bool iosf_mbi_available(void)
+{
+ return false;
+}
+
+static inline
+int iosf_mbi_read(u8 port, u8 opcode, u32 offset, u32 *mdr)
+{
+ WARN(1, IOSF_MBI driver not available);
+ return -EPERM;
+}
+
+static inline
+int iosf_mbi_write(u8 port, u8 opcode, u32 offset, u32 mdr)
+{
+ WARN(1, IOSF_MBI driver not available);
+ return -EPERM;
+}
+
+static inline
+int iosf_mbi_modify(u8 port, u8 opcode, u32 offset, u32 mdr, u32 mask)
+{
+ WARN(1, IOSF_MBI driver not available);
+ return -EPERM;
+}
+#endif /* CONFIG_IOSF_MBI */
+
#endif /* IOSF_MBI_SYMS_H */
diff --git a/arch/x86/kernel/iosf_mbi.c b/arch/x86/kernel/iosf_mbi.c
index c3aae66..f4ff978 100644
--- a/arch/x86/kernel/iosf_mbi.c
+++ b/arch/x86/kernel/iosf_mbi.c
@@ -177,6 +177,13 @@ int iosf_mbi_modify(u8 port, u8 opcode, u32 offset, u32
mdr, u32 mask)
}
EXPORT_SYMBOL(iosf_mbi_modify);
+bool iosf_mbi_available(void)
+{
+ /* Mbi isn't hot-pluggable. No remove routine is provided */
+ return mbi_pdev;
+}
+EXPORT_SYMBOL(iosf_mbi_available);
+
static int iosf_mbi_probe(struct pci_dev *pdev,
const struct pci_device_id *unused)
{
--
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/
[tip:x86/platform] x86, iosf: Add PCI ID macros for better readability
Commit-ID: 04725ad59474d24553d526fa774179ecd2922342
Gitweb: http://git.kernel.org/tip/04725ad59474d24553d526fa774179ecd2922342
Author: Ong Boon Leong boon.leong@intel.com
AuthorDate: Fri, 9 May 2014 13:44:08 -0700
Committer: H. Peter Anvin h...@linux.intel.com
CommitDate: Fri, 9 May 2014 14:57:35 -0700
x86, iosf: Add PCI ID macros for better readability
Introduce PCI IDs macro for the list of supported product:
BayTrail Quark X1000.
Signed-off-by: Ong Boon Leong boon.leong@intel.com
Link:
http://lkml.kernel.org/r/1399668248-24199-5-git-send-email-david.e@linux.intel.com
Signed-off-by: David E. Box david.e@linux.intel.com
Signed-off-by: H. Peter Anvin h...@linux.intel.com
---
arch/x86/kernel/iosf_mbi.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/iosf_mbi.c b/arch/x86/kernel/iosf_mbi.c
index 201a7ab..d30acdc 100644
--- a/arch/x86/kernel/iosf_mbi.c
+++ b/arch/x86/kernel/iosf_mbi.c
@@ -25,6 +25,9 @@
#include asm/iosf_mbi.h
+#define PCI_DEVICE_ID_BAYTRAIL 0x0F00
+#define PCI_DEVICE_ID_QUARK_X1000 0x0958
+
static DEFINE_SPINLOCK(iosf_mbi_lock);
static inline u32 iosf_mbi_form_mcr(u8 op, u8 port, u8 offset)
@@ -200,8 +203,8 @@ static int iosf_mbi_probe(struct pci_dev *pdev,
}
static DEFINE_PCI_DEVICE_TABLE(iosf_mbi_pci_ids) = {
- { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0F00) },
- { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0958) },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_BAYTRAIL) },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_QUARK_X1000) },
{ 0, },
};
MODULE_DEVICE_TABLE(pci, iosf_mbi_pci_ids);
--
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/
[tip:x86/platform] x86, iosf: Added Quark MBI identifiers
Commit-ID: 7ef1def800e907edd28ddb1a5c64bae6b8749cdd Gitweb: http://git.kernel.org/tip/7ef1def800e907edd28ddb1a5c64bae6b8749cdd Author: Ong Boon Leong boon.leong@intel.com AuthorDate: Fri, 9 May 2014 13:44:06 -0700 Committer: H. Peter Anvin h...@linux.intel.com CommitDate: Fri, 9 May 2014 14:57:08 -0700 x86, iosf: Added Quark MBI identifiers Added all the MBI units below and their associated read/write opcodes: - Host Bridge Arbiter - Host Bridge - Remote Management Unit - Memory Manager eSRAM - SoC Unit Signed-off-by: Ong Boon Leong boon.leong@intel.com Link: http://lkml.kernel.org/r/1399668248-24199-3-git-send-email-david.e@linux.intel.com Signed-off-by: David E. Box david.e@linux.intel.com Signed-off-by: H. Peter Anvin h...@linux.intel.com --- arch/x86/include/asm/iosf_mbi.h | 22 ++ 1 file changed, 22 insertions(+) diff --git a/arch/x86/include/asm/iosf_mbi.h b/arch/x86/include/asm/iosf_mbi.h index 1a91a36..57995f0 100644 --- a/arch/x86/include/asm/iosf_mbi.h +++ b/arch/x86/include/asm/iosf_mbi.h @@ -50,6 +50,28 @@ #define BT_MBI_PCIE_READ 0x00 #define BT_MBI_PCIE_WRITE 0x01 +/* Quark available units */ +#define QRK_MBI_UNIT_HBA 0x00 +#define QRK_MBI_UNIT_HB0x03 +#define QRK_MBI_UNIT_RMU 0x04 +#define QRK_MBI_UNIT_MM0x05 +#define QRK_MBI_UNIT_MMESRAM 0x05 +#define QRK_MBI_UNIT_SOC 0x31 + +/* Quark read/write opcodes */ +#define QRK_MBI_HBA_READ 0x10 +#define QRK_MBI_HBA_WRITE 0x11 +#define QRK_MBI_HB_READ0x10 +#define QRK_MBI_HB_WRITE 0x11 +#define QRK_MBI_RMU_READ 0x10 +#define QRK_MBI_RMU_WRITE 0x11 +#define QRK_MBI_MM_READ0x10 +#define QRK_MBI_MM_WRITE 0x11 +#define QRK_MBI_MMESRAM_READ 0x12 +#define QRK_MBI_MMESRAM_WRITE 0x13 +#define QRK_MBI_SOC_READ 0x06 +#define QRK_MBI_SOC_WRITE 0x07 + #if IS_ENABLED(CONFIG_IOSF_MBI) bool iosf_mbi_available(void); -- 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/
[tip:x86/platform] x86, iosf: Add Quark X1000 PCI ID
Commit-ID: 90916e048c1e0c1d379577e43ab9b8e331490cfb
Gitweb: http://git.kernel.org/tip/90916e048c1e0c1d379577e43ab9b8e331490cfb
Author: Ong Boon Leong boon.leong@intel.com
AuthorDate: Fri, 9 May 2014 13:44:07 -0700
Committer: H. Peter Anvin h...@linux.intel.com
CommitDate: Fri, 9 May 2014 14:57:23 -0700
x86, iosf: Add Quark X1000 PCI ID
Add PCI device ID, i.e. that of the Host Bridge,
for IOSF MBI driver.
Signed-off-by: Ong Boon Leong boon.leong@intel.com
Link:
http://lkml.kernel.org/r/1399668248-24199-4-git-send-email-david.e@linux.intel.com
Signed-off-by: David E. Box david.e@linux.intel.com
Signed-off-by: H. Peter Anvin h...@linux.intel.com
---
arch/x86/kernel/iosf_mbi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/iosf_mbi.c b/arch/x86/kernel/iosf_mbi.c
index f4ff978..201a7ab 100644
--- a/arch/x86/kernel/iosf_mbi.c
+++ b/arch/x86/kernel/iosf_mbi.c
@@ -201,6 +201,7 @@ static int iosf_mbi_probe(struct pci_dev *pdev,
static DEFINE_PCI_DEVICE_TABLE(iosf_mbi_pci_ids) = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0F00) },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0958) },
{ 0, },
};
MODULE_DEVICE_TABLE(pci, iosf_mbi_pci_ids);
--
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] staging: android: fix Missing a blank line after declarations warnings
On Wed, May 28, 2014 at 06:52:51PM +1000, Scott Weir wrote: This patch corrects coding style issue: WARNING: Missing a black line after declarations Signed-off-by: Scott Weir sjw0...@gmail.com --- drivers/staging/android/sync_debug.c | 4 This file isn't in my tree. Always work against linux-next, not Linus's tree for new patches. thanks, greg k-h -- 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: fs/dcache.c - BUG: soft lockup - CPU#5 stuck for 22s! [systemd-udevd:1667]
On Wed, May 28, 2014 at 02:11:51PM -0700, Linus Torvalds wrote: d_walk() covers its arse with -d_lock (and it wants the starting point to be pinned, obviously). So AFAICS RCU is not a problem. It's not RCU itself, it's that DCACHE_MAY_FREE bit. Yes, d_walk() gets -d_lock, but dentry_kill() drops d_lock in the middle, and the whole dentry_kill() can get called multiple times for the same dentry just makes me go Hmm. It is *not* obvious what happens the second vs third time that gets called. If it can get called two times, why not three times? dentry_kill(dentry, 1) can only be called when -d_count had been positive up to the point of caller grabbing -d_lock. And it either does lockref_mark_dead() before dropping -d_lock or it fails trylock and buggers off having done nothing, including changes of -d_count. In case of dentry_kill(dentry, 0), -d_lock has been held since the moment dentry had been found on shrink list. It either does nothing and dentry gets returned to the same shrink list without ever dropping -d_lock (or changing refcount) or it does lockref_mark_dead() before dropping -d_lock. In the latter case dentry will *not* be put on any shrink lists again. So we have at most one call of the first kind getting past the trylocks and at most one call of the second kind doing the same. -- 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] Staging: rtl8192u: r8192U_wx.c Added {} braces and newlines
On Wed, May 28, 2014 at 07:32:39AM -0700, Chaitanya Hazarey wrote:
-static int r8192_wx_set_scan_type(struct net_device *dev, struct
iw_request_info *aa, union
- iwreq_data *wrqu, char *p){
+static int r8192_wx_set_scan_type(struct net_device *dev, struct
iw_request_info *aa,
+ union iwreq_data *wrqu, char *p){
The '{' still isn't in the right place, but I'll let you fix that up in
a future patch.
thanks,
greg k-h
--
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] Re: recvmmsg() timeout behavior strangeness [RESEND]
On 05/28/2014 01:50 PM, 'Arnaldo Carvalho de Melo' wrote: What is being discussed here is how to return the EFAULT that may happen _after_ datagram processing, be it interrupted by an EFAULT, signal, or plain returning all that was requested, with no errors. This EFAULT _after_ datagram processing may happen when updating the remaining timeout, because then how can userspace both receive the number of successfully copied datagrams (in any of the cases mentioned in the previous paragraph) and know that that timeout can't be used because there was a problem while trying to copy it to userspace (EFAULT)? How does select() handle this problem? It updates the timeout and also modifies other data. Could we just check whether the timeout pointer is valid before doing anything else? Of course we could still fault the page out while waiting for messages and then fail to fault it back in later, but that seems like a not-very-likely scenario. Chris -- 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 3/3] IO: hid-sensor-magn-3d: Add in support for True/Magnetic North HID usages
Hey Srinivas,
Well I could use sensor_hub_input_get_attribute_info() for each usage
attribute. I was just thinking that since each usage attribute is
found in a row, one for each field I think, it'd be easier to create
iio channels that way. This would eliminate running the for loop
search for usage id each time.
I realize that my parse_report function is quite ugly espically ending
in four closing parenthesis and copying code from
sensor_hub_input_get_attribute_info(). I will change it if you don't
think it will slow down the driver or have any negative effects.
Thanks,
Reyad
On Wed, May 28, 2014 at 4:25 PM, Srinivas Pandruvada
srinivas.pandruv...@linux.intel.com wrote:
On 05/28/2014 02:15 PM, Reyad Attiyat wrote:
+static void sensor_hub_fill_attr_info(
+ struct hid_sensor_hub_attribute_info *info,
+ s32 index, s32 report_id, struct hid_field *field)
+{
+ info-index = index;
+ info-report_id = report_id;
+ info-units = field-unit;
+ info-unit_expo = field-unit_exponent;
+ info-size = (field-report_size * field-report_count)/8;
+ info-logical_minimum = field-logical_minimum;
+ info-logical_maximum = field-logical_maximum;
}
I copied this function from hid/hid-sensor-hub.c as it is marked
static in that file. I use it to fill attributes as I find them.
Should I create an another patch to make it non-static?
I didn't check your implementation. But
sensor_hub_input_get_attribute_info()
function is not enough? We are already using to get other attributes for x,
y and Z.
Thanks,
Srinivas
+ list_for_each_entry(report, report_enum-report_list, list) {
+ for (i = 0; i report-maxfield; ++i) {
+ field = report-field[i];
+
+ for (j = 0; j field-maxusage; j++) {
+ usage = (field-usage[j]);
+
This is how I mange to find all possible hid reports in the parse
reports function. I noticed that in the other function that was used,
sensor_hub_input_get_attribute_info(), it only uses field-usage[0].
Is there a reason for this and should I change my current
implementation?
--
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] clk: flatten clk tree in debugfs
On 05/28/2014 11:52 AM, Mike Turquette wrote:
Quoting Saravana Kannan (2014-05-28 10:47:46)
On 05/26/2014 04:14 AM, Peter De Schrijver wrote:
On Sat, May 24, 2014 at 12:24:32AM +0200, Saravana Kannan wrote:
On 05/23/2014 03:59 AM, Peter De Schrijver wrote:
This patch flattens the clk tree in CCF debugfs. Instead of representing the
clocks and their hierarchy as a directory structure under
/sys/kernel/debug/clk, each clock gets a single directory directly under
/sys/kernel/debug/clk.
While this may seem strange, here's way I think this is the right thing to do:
1) a directory structure cannot be 'snapshotted' atomically, therefore it's
not in general possible to get a consistent view of the clocktree, because
clocks can be reparented at any time. This was solved by adding clk_dump
and clk_summary, which do guarantee an atomic snapshot of the tree.
Therefore I think the directory structure doesn't add any value.
2) When writing userspace programs which use the files in the clock
directories (eg. for testing purposes), it's impossible to know for sure
where a certain clock will be, because it might have been reparented by
the
time you figured out the path from clk_dump. This makes writing such
programs more difficult than it should be.
So because the directory structure doesn't give any information we don't
already provide by other means and it makes certain usecases more difficult
than the should be, I think we should move to a flat directory containing
one subdir per clock.
Completely agree and a huge ACK to this idea.
Thanks.
Signed-off-by: Peter De Schrijver pdeschrij...@nvidia.com
---
drivers/clk/clk.c | 54
+++-
1 files changed, 4 insertions(+), 50 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index dff0373..53c6b4f 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -306,7 +306,7 @@ static int clk_debug_create_subtree(struct clk *clk, struct
dentry *pdentry)
goto out;
hlist_for_each_entry(child, clk-children, child_node)
- clk_debug_create_subtree(child, clk-dentry);
+ clk_debug_create_subtree(child, pdentry);
ret = 0;
out:
@@ -326,29 +326,20 @@ out:
*/
static int clk_debug_register(struct clk *clk)
{
- struct clk *parent;
struct dentry *pdentry;
int ret = 0;
if (!inited)
goto out;
- parent = clk-parent;
-
/*
* Check to see if a clk is a root clk. Also check that it is
* safe to add this clk to debugfs
*/
- if (!parent)
- if (clk-flags CLK_IS_ROOT)
- pdentry = rootdir;
- else
- pdentry = orphandir;
+ if (clk-flags CLK_IS_ROOT)
+ pdentry = rootdir;
else
- if (parent-dentry)
- pdentry = parent-dentry;
- else
- goto out;
+ pdentry = orphandir;
I'm confused by this code. Shouldn't pdentry always be the same? Do we
need a dir for orphans? Also, I'm not sure the code is actually right?
Indeed. This code is most likely wrong... I don't have a strong opinion
if we need an orphan dir or if we can just have a file to list orphaned
clocks.
I don't have a strong opinion either. A file is probably safer in case
we add debug files that allow changes to the clock. In which case, we
don't want orphan clocks to be modifiable.
I would still like to be able to see if there are orphaned clocks.
Agree
Yes, easy orphan clock detection should not go away. How about an
orphan_summary sysfs file? That means that orphan clocks will still get
their own directory under the newly flattened hierarchy, we can remove
the orphans directory completely and it is still easy to find orphan
regressions with a quick `cat /sys/kernel/debug/clk/orphan_summary`.
You could argue that the same race exists for the orphan dir. It is possible
for the parent to be registered while you're traversing the orphan dir and
cause a clock to move around. In practice this seems rather unlikely to happen
to me?
I think you read too much into my comment. I wasn't in any way against
knowing orphaned clocks from debugfs. I was just referring to that
specific point in code, the clock might always need to pick the same
dentry. I might be wrong about the code too (I just looked at the diff).
Looks like you are putting everything but the root into orphandir?
Yes...
Now I'm confused. Does some other code path unorphan and move them into
the clock debug root dir later on?
Yes. See drivers/clk/clk.c, lines 1860-1870 in the clk-next branch.
Mike, others,
Any objections to this idea? If there's not much opposition, then maybe
Peter can actually spend time fixing and testing this patch?
Idea seems fine. I had actually considered removing the hiearchal
directory structure completely with the advent of clk_dump and
clk_summary, but if
Re: [PATCH] drivers/char/mem.c: Add /dev/ioports, supporting 16-bit and 32-bit ports
On 05/19/2014 05:36 AM, Arnd Bergmann wrote: My feeling is that all devices we can think of fall into at least one of these categories: * legacy PC stuff that needs only byte access * PCI devices that can be accessed through sysfs * devices on x86 that can be accessed using iopl I don't believe PCI I/O space devices can be accessed through sysfs, but perhaps I'm wrong? (mmapping I/O space is not portable.) -hpa -- 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] x32: Mask away the x32 syscall bit in the ptrace codepath
On Wed, May 28, 2014 at 2:19 PM, H. Peter Anvin h...@linux.intel.com wrote:
On 05/28/2014 02:15 PM, Andy Lutomirski wrote:
3. The OOPS you're fixing doesn't seem like it's fixed. What if some
other random high bits are set?
There is a range check in entry_*.S for the system call.
I can imagine that causing a certain amount of confusion to fancy
seccomp users. Oh, well. No one that I know of has complained yet.
I don't know how seccomp or audit deal with out-of-range syscall
numbers, so that might be worth taking a look at.
audit oopses, apparently. seccomp will tell BPF about it and follow
directions, barring bugs.
However: are you sure that entry_64.S handles this? It looks like
tracesys has higher priority than badsys. And strace can certainly
see out-of-range syscalls. And I can oops audit by doing:
auditctl -a exit,always -S open
./a.out
where a.out is this:
#include stdio.h
#include sys/syscall.h
int main()
{
long i;
for (i = 1000; ; i += 64 * 4096)
syscall(i, 0, 0, 0, 0, 0, 0);
return 0;
}
I would *love* to deprecate the entire syscall auditing mechanism. Or
at least I'd love to have distros stop using it.
I'll go ask for a CVE number. Sigh.
--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/
[BUG] perf probe segfaulting when asked for variable it doesn't find
Masami-san, While trying: [root@zoo ~]# perf probe 'vfs_getname=getname_flags:65 pathname=result-name:string' Failed to find the location of result at this address. Perhaps, it has been optimized out. Failed to find 'result' in this function. Error: Failed to add events. (-2) [root@zoo ~]# perf probe 'vfs_getname=getname_flags:65 pathname=result-name:string' Added new event: Segmentation fault (core dumped) I got segfaulted while in the past I would get the much nicer: [root@zoo ~]# perf probe 'vfs_getname=getname_flags:65 pathname=result-name:string' Failed to find the location of result at this address. Perhaps, it has been optimized out. Failed to find 'result' in this function. Error: Failed to add events. (-2) [root@zoo ~]# The Error: part can and should be trimmed, just the two middle ones should be enough, but I'm digressing, I bisected it down to the cset at the bottom of this message. In the past there was a 'result' variable at getname_flags, but now 'probe' isn't finding any, as it seems to have been optimized away, still haven't checked thoroughly: [root@zoo ~]# perf probe -V getname_flags Available variables at getname_flags @getname_flags+0 char* filename int flags int*empty @getname+18 (No matched variables) @user_path_create+37 (No matched variables) @user_path_parent+37 (No matched variables) @user_path_at_empty+50 (No matched variables) @user_path_mountpoint_at+37 (No matched variables) @sys_symlinkat+38 (No matched variables) @sys_symlink+34 (No matched variables) [root@zoo ~] 3d918a12a1b3088ac16ff37fa52760639d6e2403 is the first bad commit commit 3d918a12a1b3088ac16ff37fa52760639d6e2403 Author: Masami Hiramatsu masami.hiramatsu...@hitachi.com Date: Fri Oct 11 16:10:26 2013 +0900 perf probe: Find fentry mcount fuzzed parameter location At this point, --fentry (mcount function entry) option for gcc fuzzes the debuginfo variable locations by skipping the mcount instruction offset (on x86, this is a 5 byte call instruction). This makes variable searching fail at the entry of functions which are mcount'ed. e.g.) Available variables at vfs_read @vfs_read+0 (No matched variables) This patch adds additional location search at the function entry point to solve this issue, which tries to find the earliest address for the variable location. Note that this only works with function parameters (formal parameters) because any local variables should not exist on the function entry address (those are not initialized yet). With this patch, perf probe shows correct parameters if possible; # perf probe --vars vfs_read Available variables at vfs_read @vfs_read+0 char* buf loff_t* pos size_t count struct file*file Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com Cc: Ingo Molnar mi...@redhat.com Cc: Paul Mackerras pau...@samba.org Cc: Peter Zijlstra a.p.zijls...@chello.nl Link: http://lkml.kernel.org/r/20131011071025.15557.13275.st...@udc4-manage.rcp.hitachi.co.jp Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com :04 04 4c416906285aa1488ed2badbaf3b3feee86f9578 978c6b47f442845e6e93a79a24aeb36bbca0b7da M tools [acme@zoo linux]$ -- 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: Pondering per-process vsyscall disablement
On 05/23/2014 09:40 AM, Andy Lutomirski wrote: I don't think this should be something configured by the administrator, unless the administrator is the builder of a kiosky thing like Chromium OS. In that case, the administrator can use vsyscall=none. I think this should be handled by either libc or the toolchain, hence the suggestions of a syscall or an ELF header. We could mimic the NX stack stuff, but it would have a lot of false negatives, simply because very few things would actually poke at the vsyscall page. The NX stuff uses a dummy program header in the ELF image. On the other hand, you could make the argument that anything compiled with a new toolchain simply should not use the vsyscall page, and just unconditionally set the opt-out bit (header) in question. It might be better to have some kind of flags field (which a number of architectures use) than keep using dummy program headers, though. -hpa -- 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] crypto: crc32c-pclmul - Use pmovzxdq to shrink K_table
Jan Beulich jbeul...@suse.com wrote: George Spelvin li...@horizon.com 05/28/14 4:40 PM Jan: Is support for SLE10's pre-2.18 binutils still required? Your PEXTRD fix was only a year ago, so I expect, but I wanted to ask. I'd much appreciate if I would be able to build the kernel that way for another while. Does it matter that the code I'm working on is 64-bit only? It aready uses crc32q instruction (added with SSE4.2) with no assembler workarounds, so I figure pmovzxdq (part of SSE 4.1) doesn't make it any worse. The annoying thing about doing it with macros is that it would be a PITA to support a memory operand; I'd probably have to punt to .byte. Putting data into .text seems wrong - it should go into .rodata. I don't really care, but it's being accessed PC-relative the same as a jump table that's already in .text, so I just figured I'd be lazy. -- 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 2/2] power: twl4030_charger: attempt to power off in case of critical events
Attempt to power off in case of critical events such as battery removal,
over voltage events.
There is no guarentee that we'd be in a safe scenario here, but the very
least we can try to do is to power off the device to prevent damage to
the system instead of just printing a message and hoping for the best.
NOTE: twl4030 should attempt some form of recovery, but just depending
on that is never a safe alternative.
Signed-off-by: Nishanth Menon n...@ti.com
---
new patch. original attempt was: https://patchwork.kernel.org/patch/4002371/
NOTE: we dont have poweroff support yet enabled on LDP, but it just needs
relevant dts entry.
drivers/power/twl4030_charger.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index 2598c58..ed0dbd2 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -22,6 +22,7 @@
#include linux/power_supply.h
#include linux/notifier.h
#include linux/usb/otg.h
+#include linux/reboot.h
#include linux/regulator/machine.h
#define TWL4030_BCIMSTATEC 0x02
@@ -332,6 +333,7 @@ static irqreturn_t twl4030_bci_interrupt(int irq, void *arg)
struct twl4030_bci *bci = arg;
u8 irqs1, irqs2;
int ret;
+ bool power_off = false;
ret = twl_i2c_read_u8(TWL4030_MODULE_INTERRUPTS, irqs1,
TWL4030_INTERRUPTS_BCIISR1A);
@@ -352,20 +354,34 @@ static irqreturn_t twl4030_bci_interrupt(int irq, void
*arg)
}
/* various monitoring events, for now we just log them here */
- if (irqs1 (TWL4030_TBATOR2 | TWL4030_TBATOR1))
+ if (irqs1 (TWL4030_TBATOR2 | TWL4030_TBATOR1)) {
dev_warn(bci-dev, battery temperature out of range\n);
+ power_off = true;
+ }
- if (irqs1 TWL4030_BATSTS)
+ if (irqs1 TWL4030_BATSTS) {
dev_crit(bci-dev, battery disconnected\n);
+ power_off = true;
+ }
- if (irqs2 TWL4030_VBATOV)
+ if (irqs2 TWL4030_VBATOV) {
dev_crit(bci-dev, VBAT overvoltage\n);
+ power_off = true;
+ }
- if (irqs2 TWL4030_VBUSOV)
+ if (irqs2 TWL4030_VBUSOV) {
dev_crit(bci-dev, VBUS overvoltage\n);
+ power_off = true;
+ }
- if (irqs2 TWL4030_ACCHGOV)
+ if (irqs2 TWL4030_ACCHGOV) {
dev_crit(bci-dev, Ac charger overvoltage\n);
+ power_off = true;
+ }
+
+ /* Try to shutdown the system */
+ if (power_off)
+ orderly_poweroff(true);
return IRQ_HANDLED;
}
--
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/
Re: [PATCH] CLK: TI: DRA7: return error code in failure case
Quoting Tero Kristo (2014-05-19 05:23:10)
On 05/19/2014 02:25 PM, Julia Lawall wrote:
From: Julia Lawall julia.law...@lip6.fr
Add a returned error code in the MAX_APLL_WAIT_TRIES case. Remove the
updating of the return variable r to 0 if MAX_APLL_WAIT_TRIES is not yet
reached, because r is already 0 at this point.
Signed-off-by: Julia Lawall julia.law...@lip6.fr
Acked-by: Tero Kristo t-kri...@ti.com
Mike, do you want to queue this as a fix or shall I add this to be
queued for 3.16?
It's not a visible regression, so let's go with 3.16.
Regards,
Mike
-Tero
---
diff --git a/drivers/clk/ti/apll.c b/drivers/clk/ti/apll.c
index b986f61..efc71a0 100644
--- a/drivers/clk/ti/apll.c
+++ b/drivers/clk/ti/apll.c
@@ -77,13 +77,11 @@ static int dra7_apll_enable(struct clk_hw *hw)
if (i == MAX_APLL_WAIT_TRIES) {
pr_warn(clock: %s failed transition to '%s'\n,
clk_name, (state) ? locked : bypassed);
- } else {
+ r = -EBUSY;
+ } else
pr_debug(clock: %s transition to '%s' in %d loops\n,
clk_name, (state) ? locked : bypassed, i);
- r = 0;
- }
-
return r;
}
--
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] gpu/drm/ttm: Use mutex_lock_killable() for shrinker functions.
Konrad Rzeszutek Wilk wrote:
On Sat, May 24, 2014 at 11:22:09PM +0900, Tetsuo Handa wrote:
Hello.
I tried to test whether it is OK (from point of view of reentrant) to use
mutex_lock() or mutex_lock_killable() inside shrinker functions when
shrinker
functions do memory allocation, for
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c is
doing memory allocation with mutex lock held inside
ttm_dma_pool_shrink_scan().
If I compile a test module shown below which mimics extreme case of what
ttm_dma_pool_shrink_scan() will do
And ttm_pool_shrink_scan.
I don't know why but ttm_pool_shrink_scan() does not take mutex.
and load the test module and do
# echo 3 /proc/sys/vm/drop_caches
the system stalls with 0% CPU usage because of mutex deadlock
(with prior lockdep warning).
Is this because wrong gfp flags are passed to kmalloc() ? Is this because
the test module's shrinker functions return wrong values? Is this because
doing memory allocation with mutex held inside shrinker functions is
forbidden? Can anybody tell me what is wrong with my test module?
What is the sc-gfp_flags? What if you use GFP_ATOMIC?
I didn't check it but at least I'm sure that __GFP_WAIT bit is set.
Thus, GFP_ATOMIC or GFP_NOWAIT will solve this problem.
In regards to the lockdep warning below it looks like
Regards.
[ 48.077353]
[ 48.077999] =
[ 48.080023] [ INFO: inconsistent lock state ]
[ 48.080023] 3.15.0-rc6-00190-g1ee1cea #203 Tainted: G OE
[ 48.080023] -
[ 48.080023] inconsistent {RECLAIM_FS-ON-W} - {IN-RECLAIM_FS-W} usage.
[ 48.086745] kswapd0/784 [HC0[0]:SC0[0]:HE1:SE1] takes:
[ 48.086745] (lock#2){+.+.?.}, at: [e0861022]
shrink_test_count+0x12/0x60 [test]
[ 48.086745] {RECLAIM_FS-ON-W} state was registered at:
You have the scenario you described below, that is:
shrink_test_scan
mutex_lock_killable()
- kmalloc
- shrink_test_count
mutex_lock_killable()
And 'mutex_lock_killable' is the same (in at least this context)
the same as 'mutex_lock'. In other words, your second 'mutex_lock'
is going to spin - which is a deadlock.
Perhaps a way of not getting in this scenario is:
1). Try to take the mutex (ie, one that won't spin if it can't
get it).
2). Use the GFP_ATOMIC in the shrinker so that we never
end up calling ourselves in case of memory pressure
?
Yes, I think so as well.
This patch changes mutex_lock(); to if (mutex_lock_killable())
return ...;
so that any threads can promptly give up. (By the way, as far as I
tested,
changing to if (!mutex_trylock()) return ...; likely shortens the
duration
of stall. Maybe we don't need to wait for mutex if someone is already
calling
these functions.)
While discussing about XFS problem, I got a question. Is it OK (from point
of view of reentrant) to use mutex_lock() or mutex_lock_killable() inside
shrinker's entry point functions? Can senario shown below possible?
(1) kswapd is doing memory reclaim which does not need to hold mutex.
(2) Someone in GFP_KERNEL context (not kswapd) calls
ttm_dma_pool_shrink_count() and then calls ttm_dma_pool_shrink_scan()
from direct reclaim path.
(3) Inside ttm_dma_pool_shrink_scan(), GFP_KERNEL allocation is issued
while mutex is held by the someone.
(4) GFP_KERNEL allocation cannot be completed immediately due to memory
pressure.
(5) kswapd calls ttm_dma_pool_shrink_count() which need to hold mutex.
(6) Inside ttm_dma_pool_shrink_count(), kswapd is blocked waiting for
mutex held by the someone, and the someone is waiting for GFP_KERNEL
allocation to complete, but GFP_KERNEL allocation cannot be completed
until mutex held by the someone is released?
Ewww. Perhaps if we used GFP_ATOMIC for the array allocation we do in
ttm_dma_page_pool_free and ttm_page_pool_free?
That would avoid the 4) problem.
Right. Which approach (use GFP_ATOMIC or GFP_NOWAIT / use !mutex_trylock())
do you prefer? I'll create RHBZ entry for RHEL7 kernel as non count/scan
version has the same problem.
-- test.c start --
#include linux/module.h
#include linux/sched.h
#include linux/slab.h
#include linux/mm.h
static int shrink_test(struct shrinker *shrinker, struct shrink_control *sc)
{
static DEFINE_MUTEX(lock);
LIST_HEAD(list);
int i = 0;
if (mutex_lock_killable(lock)) {
printk(KERN_WARNING Process %u (%s) gave up waiting for mutex
\n, current-pid, current-comm);
return 0;
}
while (1) {
struct list_head *l = kmalloc(PAGE_SIZE, sc-gfp_mask);
if (!l)
break;
[PATCH V2 1/2] power: twl4030_charger: detect battery presence prior to enabling charger
TWL4030's Battery Charger seems to be designed for non-hotpluggable
batteries.
If battery is not present in the system, BATSTS is always set with the
expectation that software will take actions to move to a required safe
state (could be power down or disable various charger paths).
It does not seem possible even by manipulating the edge detection
of the event (using BCIEDR2 register) to have a consistent hotplug
handling. This seems to be the result of BATSTS interrupt generated
when the thermistor of the battery pack is disconnected from the
dedicated ADIN1 pin. Clearing the status just results in the status
being regenerated by the monitoring ADC(MADC) and disabling the
edges of event just makes hotplug no longer function. The only
other option is to disable the detection of the MADC by disabling
BCIMFEN4::BATSTSMCHGEN (battery presence detector) - but then, we can
never again detect battery reconnection.
So, detect battery presence based on precharge(which is hardware
automatic state) or default main charger configuration at the time of
probe and enable charger logic only if battery was present.
Reported-by: Russell King li...@arm.linux.org.uk
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Nishanth Menon n...@ti.com
---
V2: just a rebase, picked up tony's tested-by, minor formatting fix
V1: https://patchwork.kernel.org/patch/4124751/
drivers/power/twl4030_charger.c | 44 ++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index f141088..2598c58 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -28,10 +28,13 @@
#define TWL4030_BCIICHG0x08
#define TWL4030_BCIVAC 0x0a
#define TWL4030_BCIVBUS0x0c
+#define TWL4030_BCIMFSTS3 0x0F
#define TWL4030_BCIMFSTS4 0x10
#define TWL4030_BCICTL10x23
#define TWL4030_BB_CFG 0x12
+#define TWL4030_BCIMFSTS1 0x01
+
#define TWL4030_BCIAUTOWEN BIT(5)
#define TWL4030_CONFIG_DONEBIT(4)
#define TWL4030_BCIAUTOUSB BIT(1)
@@ -52,6 +55,9 @@
#define TWL4030_BBISEL_500uA 0x02
#define TWL4030_BBISEL_1000uA 0x03
+#define TWL4030_BATSTSPCHG BIT(2)
+#define TWL4030_BATSTSMCHG BIT(6)
+
/* BCI interrupts */
#define TWL4030_WOVF BIT(0) /* Watchdog overflow */
#define TWL4030_TMOVF BIT(1) /* Timer overflow */
@@ -145,6 +151,35 @@ static int twl4030bci_read_adc_val(u8 reg)
}
/*
+ * Check if Battery Pack was present
+ */
+static int twl4030_is_battery_present(struct twl4030_bci *bci)
+{
+ int ret;
+ u8 val = 0;
+
+ /* Battery presence in Main charge? */
+ ret = twl_i2c_read_u8(TWL_MODULE_MAIN_CHARGE, val, TWL4030_BCIMFSTS3);
+ if (ret)
+ return ret;
+ if (val TWL4030_BATSTSMCHG)
+ return 0;
+
+ /*
+* OK, It could be that bootloader did not enable main charger,
+* pre-charge is h/w auto. So, Battery presence in Pre-charge?
+*/
+ ret = twl_i2c_read_u8(TWL4030_MODULE_PRECHARGE, val,
+ TWL4030_BCIMFSTS1);
+ if (ret)
+ return ret;
+ if (val TWL4030_BATSTSPCHG)
+ return 0;
+
+ return -ENODEV;
+}
+
+/*
* Check if VBUS power is present
*/
static int twl4030_bci_have_vbus(struct twl4030_bci *bci)
@@ -541,8 +576,14 @@ static int __init twl4030_bci_probe(struct platform_device
*pdev)
bci-irq_chg = platform_get_irq(pdev, 0);
bci-irq_bci = platform_get_irq(pdev, 1);
- platform_set_drvdata(pdev, bci);
+ /* Only proceed further *IF* battery is physically present */
+ ret = twl4030_is_battery_present(bci);
+ if (ret) {
+ dev_crit(pdev-dev, Battery was not detected:%d\n, ret);
+ goto fail_no_battery;
+ }
+ platform_set_drvdata(pdev, bci);
bci-ac.name = twl4030_ac;
bci-ac.type = POWER_SUPPLY_TYPE_MAINS;
bci-ac.properties = twl4030_charger_props;
@@ -633,6 +674,7 @@ fail_chg_irq:
fail_register_usb:
power_supply_unregister(bci-ac);
fail_register_ac:
+fail_no_battery:
kfree(bci);
return ret;
--
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/
[PATCH V2 0/2] power: twl4030_charger: cleanup to handle various battery handling error conditions
Hi, This issue was originally reported by Russell on OMAP3-LDP platform, and original attempt to solve this by Felipe[1] did not quiet work, follow on attempt[2] seems to be effective, but in this resend, I have added an shutdown attempt in case things dont quiet look right. Based on: v3.15-rc7 Tests: ldp boot with battery: http://slexy.org/raw/s20StiV4xr ldp boot with a/c charger, no battery: http://slexy.org/raw/s2UfjIkZKG ldp boot with a/c charger+battery, remove battery: http://slexy.org/raw/s2yFTVlrWJ ^^ - this is not exactly a safe test to perform :).. Nishanth Menon (2): power: twl4030_charger: detect battery presence prior to enabling charger power: twl4030_charger: attempt to power off in case of critical events drivers/power/twl4030_charger.c | 70 +++ 1 file changed, 64 insertions(+), 6 deletions(-) [1] https://patchwork.kernel.org/patch/4002371/ [2] https://patchwork.kernel.org/patch/4124751/ -- 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/
Re: [PATCH 01/27] mtd: nand: introduce function to fix a common bug in most nand-drivers not showing a device in sysfs
On Wed, May 28, 2014 at 11:09:05PM +0200, Alexander Holler wrote: I'm very sorry, but I find such discussions extremly tiresome. If you just would have suggested that one if to prevent that someone who doesn't cp existing code would end up with a clobbered name (which he obviously can't miss if he ever would test his new or changed driver), than I maybe would have send a v2 with that if. But all the other noise just made me to want I never had send (again) a patch to LKML. It is almost impossible to avoid such answers and it turns every patch posting into a endless story where people do want to discuss every line or even character of totally silly things. It would help if you brought a more open attitude to the table. https://lkml.org/lkml/2014/5/14/574 -- 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] Re: recvmmsg() timeout behavior strangeness [RESEND]
Em Wed, May 28, 2014 at 03:33:51PM -0600, Chris Friesen escreveu: On 05/28/2014 01:50 PM, 'Arnaldo Carvalho de Melo' wrote: What is being discussed here is how to return the EFAULT that may happen _after_ datagram processing, be it interrupted by an EFAULT, signal, or plain returning all that was requested, with no errors. This EFAULT _after_ datagram processing may happen when updating the remaining timeout, because then how can userspace both receive the number of successfully copied datagrams (in any of the cases mentioned in the previous paragraph) and know that that timeout can't be used because there was a problem while trying to copy it to userspace (EFAULT)? How does select() handle this problem? It updates the timeout and also modifies other data. Could we just check whether the timeout pointer is valid before doing anything else? Of course we could still fault the page out while waiting for messages and then fail to fault it back in later, but that seems like a not-very-likely scenario. I'll check how select behaves, and yes, I think it is not-very-likely and what we're doing now is reasonable for datagram protocols, i.e. to return -EFAULT when updating the timeout fails, not reporting if packets were successfully received, i.e. they end up being dropped, as userspace can't easily figure out if some was received short of painting it with some pattern and then checking the ones that aren't with that pattern. - Arnaldo -- 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 3/3] IO: hid-sensor-magn-3d: Add in support for True/Magnetic North HID usages
Hi Reyad,
On 05/28/2014 02:35 PM, Reyad Attiyat wrote:
Hey Srinivas,
Well I could use sensor_hub_input_get_attribute_info() for each usage
attribute. I was just thinking that since each usage attribute is
found in a row, one for each field I think, it'd be easier to create
iio channels that way. This would eliminate running the for loop
search for usage id each time.
It shouldn't be an issue for few more attributes. The idea is that
we don't expose the report level parsing information to the client drivers.
The client shouldn't worry about which collection or report it belongs to.
In this way if we have to enhance the parse function for newer
FW changes or quirks, it is only done at one place. Clients are not
affected at all.
Alternatively
we can enhance API, which takes multiple usage ids and fills information
in a single call. What do you think about this?
Thanks,
Srinivas
I realize that my parse_report function is quite ugly espically ending
in four closing parenthesis and copying code from
sensor_hub_input_get_attribute_info(). I will change it if you don't
think it will slow down the driver or have any negative effects.
Thanks,
Reyad
On Wed, May 28, 2014 at 4:25 PM, Srinivas Pandruvada
srinivas.pandruv...@linux.intel.com wrote:
On 05/28/2014 02:15 PM, Reyad Attiyat wrote:
+static void sensor_hub_fill_attr_info(
+ struct hid_sensor_hub_attribute_info *info,
+ s32 index, s32 report_id, struct hid_field *field)
+{
+ info-index = index;
+ info-report_id = report_id;
+ info-units = field-unit;
+ info-unit_expo = field-unit_exponent;
+ info-size = (field-report_size * field-report_count)/8;
+ info-logical_minimum = field-logical_minimum;
+ info-logical_maximum = field-logical_maximum;
}
I copied this function from hid/hid-sensor-hub.c as it is marked
static in that file. I use it to fill attributes as I find them.
Should I create an another patch to make it non-static?
I didn't check your implementation. But
sensor_hub_input_get_attribute_info()
function is not enough? We are already using to get other attributes for x,
y and Z.
Thanks,
Srinivas
+ list_for_each_entry(report, report_enum-report_list, list) {
+ for (i = 0; i report-maxfield; ++i) {
+ field = report-field[i];
+
+ for (j = 0; j field-maxusage; j++) {
+ usage = (field-usage[j]);
+
This is how I mange to find all possible hid reports in the parse
reports function. I noticed that in the other function that was used,
sensor_hub_input_get_attribute_info(), it only uses field-usage[0].
Is there a reason for this and should I change my current
implementation?
--
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] x32: Mask away the x32 syscall bit in the ptrace codepath
On Wed, May 28, 2014 at 11:43 PM, Andy Lutomirski l...@amacapital.net wrote: However: are you sure that entry_64.S handles this? It looks like tracesys has higher priority than badsys. And strace can certainly see out-of-range syscalls. […] Not only can it see them: It must see that this bit is set as that's the only identifier it has to deduce that the binary is running in x32 mode. Out of range syscall numbers certainly do not work for auditing right now, hence my attempt to patch around it. Kind regards and thanks Philipp Kern -- 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: 3.15-rc6 build / link failed fs/built-in mb_cache_entry problems
On 05/28/2014 01:48 PM, werner wrote: Oi think im using 4.2.4 . but the kernel should be programmed clean, so that it builds with all not-too-old versions. wl Hi Werner, Please reply to the mailing list also (as I am doing). I asked Thavatchai for a patch to fix this. n Tue, 27 May 2014 15:51:26 -0700 Randy Dunlap rdun...@infradead.org wrote: On 05/27/2014 03:22 PM, Thavatchai Makphaibulchoke wrote: On 05/26/2014 11:04 PM, Randy Dunlap wrote: On 05/26/2014 11:17 AM, werner wrote: @tmac: can mbcache.c #include linux/log2.h and use ilog2(NR_BG_LOCKS) instead of using __builtin_log2(NR_BG_LOCKS) ? (ref. commit ID 1f3e55fe02d12213f87869768aa2b0bad3ba9a7d) I don't see any problem with that, unless somebody else has any concern. Please let me know if you'd like me to submit the change. I'd say yes since some gcc version(s) don't seem to support __builtin_log2(). -- ~Randy werner w.landg...@ru.ru --- Professional hosting for everyone - http://www.host.ru -- ~Randy -- 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] x32: Mask away the x32 syscall bit in the ptrace codepath
On Wed, May 28, 2014 at 2:53 PM, Philipp Kern pk...@google.com wrote: On Wed, May 28, 2014 at 11:43 PM, Andy Lutomirski l...@amacapital.net wrote: However: are you sure that entry_64.S handles this? It looks like tracesys has higher priority than badsys. And strace can certainly see out-of-range syscalls. […] Not only can it see them: It must see that this bit is set as that's the only identifier it has to deduce that the binary is running in x32 mode. Out of range syscall numbers certainly do not work for auditing right now, hence my attempt to patch around it. There appears to be a completely arbitrary limit of 32*64 syscalls. There's also an arbitrary limit of 4 arguments. Both are wrong. I have no intention of fixing either. I'll fix the OOPS, though. Kind regards and thanks Philipp Kern -- Andy Lutomirski AMA Capital Management, LLC -- 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 2/2] x86_64: expand kernel stack to 16K
On Wed, May 28, 2014 at 12:06:58PM -0400, Johannes Weiner wrote: On Wed, May 28, 2014 at 07:13:45PM +1000, Dave Chinner wrote: On Wed, May 28, 2014 at 06:37:38PM +1000, Dave Chinner wrote: [ cc XFS list ] [and now there is a complete copy on the XFs list, I'll add my 2c] On Wed, May 28, 2014 at 03:53:59PM +0900, Minchan Kim wrote: While I play inhouse patches with much memory pressure on qemu-kvm, 3.14 kernel was randomly crashed. The reason was kernel stack overflow. When I investigated the problem, the callstack was a little bit deeper by involve with reclaim functions but not direct reclaim path. I tried to diet stack size of some functions related with alloc/reclaim so did a hundred of byte but overflow was't disappeard so that I encounter overflow by another deeper callstack on reclaim/allocator path. That's a no win situation. The stack overruns through -writepage we've been seeing with XFS over the past *4 years* are much larger than a few bytes. The worst case stack usage on a virtio block device was about 10.5KB of stack usage. And, like this one, it came from the flusher thread as well. The difference was that the allocation that triggered the reclaim path you've reported occurred when 5k of the stack had already been used... Of course, we might sweep every sites we have found for reducing stack usage but I'm not sure how long it saves the world(surely, lots of developer start to add nice features which will use stack agains) and if we consider another more complex feature in I/O layer and/or reclaim path, it might be better to increase stack size( meanwhile, stack usage on 64bit machine was doubled compared to 32bit while it have sticked to 8K. Hmm, it's not a fair to me and arm64 already expaned to 16K. ) Yup, that's all been pointed out previously. 8k stacks were never large enough to fit the linux IO architecture on x86-64, but nobody outside filesystem and IO developers has been willing to accept that argument as valid, despite regular stack overruns and filesystem having to add workaround after workaround to prevent stack overruns. That's why stuff like this appears in various filesystem's -writepage: /* * Refuse to write the page out if we are called from reclaim context. * * This avoids stack overflows when called from deeply used stacks in * random callers for direct reclaim or memcg reclaim. We explicitly * allow reclaim from kswapd as the stack usage there is relatively low. * * This should never happen except in the case of a VM regression so * warn about it. */ if (WARN_ON_ONCE((current-flags (PF_MEMALLOC|PF_KSWAPD)) == PF_MEMALLOC)) goto redirty; That still doesn't guarantee us enough stack space to do writeback, though, because memory allocation can occur when reading in metadata needed to do delayed allocation, and so we could trigger GFP_NOFS memory allocation from the flusher thread with 4-5k of stack already consumed, so that would still overrun teh stack. So, a couple of years ago we started defering half the writeback stack usage to a worker thread (commit c999a22 xfs: introduce an allocation workqueue), under the assumption that the worst stack usage when we call memory allocation is around 3-3.5k of stack used. We thought that would be safe, but the stack trace you've posted shows that alloc_page(GFP_NOFS) can consume upwards of 5k of stack, which means we're still screwed despite all the workarounds we have in place. The allocation and reclaim stack itself is only 2k per the stacktrace below. What got us in this particular case is that we engaged a complicated block layer setup from within the allocation context in order to swap out a page. The report does not have a complicated block layer setup - it's just a swap device on a virtio device. There's no MD, no raid, no complex transport and protocol layer, etc. It's about as simple as it gets. In the past we disabled filesystem -writepage from within the allocation context and deferred it to kswapd for stack reasons (see the WARN_ON_ONCE and the comment in your above quote), but I think we have to go further and do the same for even swap_writepage(): I don't think that solves the problem. I've seen plenty of near stack overflows that were caused by 3k of stack being used because of memory allocation/reclaim overhead and then scheduling. usage and another 1k of stack scheduling waiting. If we have a subsystem that can put 3k on the stack at arbitrary locations, then we really only have 5k of stack available for callers. And when the generic code typically consumes 1-2k of stack before we get to filesystem specific methods, we only have 3-4k of stack left for the
Re: [PATCH v3] PCI: Introduce new device binding path using pci_dev.driver_override
On Tue, May 27, 2014 at 09:07:42PM -0600, Bjorn Helgaas wrote: On Tue, May 20, 2014 at 08:53:21AM -0600, Alex Williamson wrote: The driver_override field allows us to specify the driver for a device rather than relying on the driver to provide a positive match of the device. This shortcuts the existing process of looking up the vendor and device ID, adding them to the driver new_id, binding the device, then removing the ID, but it also provides a couple advantages. First, the above existing process allows the driver to bind to any device matching the new_id for the window where it's enabled. This is often not desired, such as the case of trying to bind a single device to a meta driver like pci-stub or vfio-pci. Using driver_override we can do this deterministically using: echo pci-stub /sys/bus/pci/devices/:03:00.0/driver_override echo :03:00.0 /sys/bus/pci/devices/:03:00.0/driver/unbind echo :03:00.0 /sys/bus/pci/drivers_probe Previously we could not invoke drivers_probe after adding a device to new_id for a driver as we get non-deterministic behavior whether the driver we intend or the standard driver will claim the device. Now it becomes a deterministic process, only the driver matching driver_override will probe the device. To return the device to the standard driver, we simply clear the driver_override and reprobe the device: echo /sys/bus/pci/devices/:03:00.0/driver_override echo :03:00.0 /sys/bus/pci/devices/:03:00.0/driver/unbind echo :03:00.0 /sys/bus/pci/drivers_probe Another advantage to this approach is that we can specify a driver override to force a specific binding or prevent any binding. For instance when an IOMMU group is exposed to userspace through VFIO we require that all devices within that group are owned by VFIO. However, devices can be hot-added into an IOMMU group, in which case we want to prevent the device from binding to any driver (override driver = none) or perhaps have it automatically bind to vfio-pci. With driver_override it's a simple matter for this field to be set internally when the device is first discovered to prevent driver matches. Signed-off-by: Alex Williamson alex.william...@redhat.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Greg, are you going to weigh in on this? It does seem to solve some real problems. ISTR you had an opinion once, but I don't know your current thoughts. This looks good to me: Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org -- 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] Implement Batched (group) ticket lock
On 05/28/2014 08:16 AM, Raghavendra K T wrote: This patch looks very promising. TODO: - we need an intelligent way to nullify the effect of batching for baremetal (because extra cmpxchg is not required). On (larger?) NUMA systems, the unfairness may be a nice performance benefit, reducing cache line bouncing through the system, and it could well outweigh the extra cmpxchg at times. - we may have to make batch size as kernel arg to solve above problem (to run same kernel for host/guest). Increasing batch size also seem to help virtualized guest more, so we will have flexibility of tuning depending on vm size. - My kernbench/ebizzy test on baremetal (32 cpu +ht sandybridge) did not seem to show the impact of extra cmpxchg. but there should be effect of extra cmpxchg. Canceled out by better NUMA locality? Or maybe cmpxchg is cheap once you already own the cache line exclusively? - virtualized guest had slight impact on 1x cases of some benchmarks but we have got impressive performance for 1x cases. So overall, patch needs exhaustive tesing. - we can further add dynamically changing batch_size implementation (inspiration and hint by Paul McKenney) as necessary. I could see a larger batch size being beneficial. Currently the maximum wait time for a spinlock on a system with N CPUs is N times the length of the largest critical section. Having the batch size set equal to the number of CPUs would only double that, and better locality (CPUs local to the current lock holder winning the spinlock operation) might speed things up enough to cancel that part of that out again... I have found that increasing batch size gives excellent improvements for overcommitted guests. I understand that we need more exhaustive testing. Please provide your suggestion and comments. I have only nitpicks so far... diff --git a/arch/x86/include/asm/spinlock_types.h b/arch/x86/include/asm/spinlock_types.h index 4f1bea1..b04c03d 100644 --- a/arch/x86/include/asm/spinlock_types.h +++ b/arch/x86/include/asm/spinlock_types.h @@ -3,15 +3,16 @@ #include linux/types.h +#define TICKET_LOCK_INC_SHIFT 1 +#define __TICKET_LOCK_TAIL_INC (1TICKET_LOCK_INC_SHIFT) + #ifdef CONFIG_PARAVIRT_SPINLOCKS -#define __TICKET_LOCK_INC2 #define TICKET_SLOWPATH_FLAG ((__ticket_t)1) #else -#define __TICKET_LOCK_INC1 #define TICKET_SLOWPATH_FLAG ((__ticket_t)0) #endif For the !CONFIG_PARAVIRT case, TICKET_LOCK_INC_SHIFT used to be 0, now you are making it one. Probably not an issue, since even people who compile with 128 CONFIG_NR_CPUS = 256 will likely have their spinlocks padded out to 32 or 64 bits anyway in most data structures. -#if (CONFIG_NR_CPUS (256 / __TICKET_LOCK_INC)) +#if (CONFIG_NR_CPUS (256 / __TICKET_LOCK_TAIL_INC)) typedef u8 __ticket_t; typedef u16 __ticketpair_t; #else @@ -19,7 +20,12 @@ typedef u16 __ticket_t; typedef u32 __ticketpair_t; #endif -#define TICKET_LOCK_INC ((__ticket_t)__TICKET_LOCK_INC) +#define TICKET_LOCK_TAIL_INC ((__ticket_t)__TICKET_LOCK_TAIL_INC) + +#define TICKET_LOCK_HEAD_INC ((__ticket_t)1) +#define TICKET_BATCH0x4 /* 4 waiters can contend simultaneously */ +#define TICKET_LOCK_BATCH_MASK (~(TICKET_BATCHTICKET_LOCK_INC_SHIFT) + \ + TICKET_LOCK_TAIL_INC - 1) I do not see the value in having TICKET_BATCH declared with a hexadecimal number, and it may be worth making sure the code does not compile if someone tried a TICKET_BATCH value that is not a power of 2. -- All rights reversed -- 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/
Fwd: [PATCH 3/3] IO: hid-sensor-magn-3d: Add in support for True/Magnetic North HID usages
Forgot to forward to list -- Forwarded message -- From: Reyad Attiyat reyad.atti...@gmail.com Date: Wed, May 28, 2014 at 4:57 PM Subject: Re: [PATCH 3/3] IO: hid-sensor-magn-3d: Add in support for True/Magnetic North HID usages To: Srinivas Pandruvada srinivas.pandruv...@linux.intel.com Hey Srinivas, It shouldn't be an issue for few more attributes. The idea is that we don't expose the report level parsing information to the client drivers. The client shouldn't worry about which collection or report it belongs to. Makes sense. In this way if we have to enhance the parse function for newer FW changes or quirks, it is only done at one place. Clients are not affected at all. Alternatively we can enhance API, which takes multiple usage ids and fills information in a single call. What do you think about this? Yes this seems like a great idea. I will try and implement this and resubmit these patches. Thank You, Reyad Attiyat -- 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] mm/memory-failure.c: support dedicated thread to handle SIGBUS(BUS_MCEERR_AO) thread
On Wed, May 28, 2014 at 11:47 AM, Naoya Horiguchi n-horigu...@ah.jp.nec.com wrote: Could you take a look? It looks good - and should be a workable API for application writers to use. @@ -84,6 +84,11 @@ PR_MCE_KILL PR_MCE_KILL_EARLY: Early kill PR_MCE_KILL_LATE: Late kill PR_MCE_KILL_DEFAULT: Use system global default + Note that if you want to have a dedicated thread which handles + the SIGBUS(BUS_MCEERR_AO) on behalf of the process, you should + call prctl() on the thread. Otherwise, the SIGBUS is sent to + the main thread. Perhaps be more explicit here that the user should call prctl(PR_MCE_KILL_EARLY) on the designated thread to get this behavior? The user could also mark more than one thread in this way - in which case the kernel will pick the first one it sees (is that oldest, or newest?) that is marked. Not sure if this would ever be useful unless you want to pass responsibility around in an application that is dynamically creating and removing threads. + if (t-flags PF_MCE_PROCESS t-flags PF_MCE_EARLY) This is correct - but made me twitch to add extra brackets: if ((t-flags PF_MCE_PROCESS) (t-flags PF_MCE_EARLY)) or if ((t-flags (PF_MCE_PROCESS|PF_MCE_EARLY)) == PF_MCE_PROCESS|PF_MCE_EARLY) [oops, no ... that's too long and no clearer] -Tony -- 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 00/11] printk: safe printing in NMI context
On Fri, 9 May 2014, Petr Mladek wrote: printk() cannot be used safely in NMI context because it uses internal locks and thus could cause a deadlock. Unfortunately there are circumstances when calling printk from NMI is very useful. For example, all WARN.*(in_nmi()) would be much more helpful if they didn't lockup the machine. Another example would be arch_trigger_all_cpu_backtrace for x86 which uses NMI to dump traces on all CPU (either triggered by sysrq+l or from RCU stall detector). I am rather surprised that this patchset hasn't received a single review comment for 3 weeks. Let me point out that the issues Petr is talking about in the cover letter are real -- we've actually seen the lockups triggered by RCU stall detector trying to dump stacks on all CPUs, and hard-locking machine up while doing so. So this really needs to be solved. -- Jiri Kosina SUSE Labs -- 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 11/16] byteorder: provide a linux/byteorder.h with {be, le}_to_cpu() and cpu_to_{be, le}() macros
On Wed, May 28, 2014 at 3:45 AM, David Laight david.lai...@aculab.com wrote: From: Cody P Schafer Rather manually specifying the size of the integer to be converted, key off of the type size. Reduces duplicate size info and the occurance of certain types of bugs (using the wrong sized conversion). ... +#define be_to_cpu(v) \ + __builtin_choose_expr(sizeof(v) == sizeof(uint8_t) , v, \ + __builtin_choose_expr(sizeof(v) == sizeof(uint16_t), be16_to_cpu(v), \ + __builtin_choose_expr(sizeof(v) == sizeof(uint32_t), be32_to_cpu(v), \ + __builtin_choose_expr(sizeof(v) == sizeof(uint64_t), be64_to_cpu(v), \ + (void)0 ... I'm not at all sure that using the 'size' of the constant will reduce the number of bugs - it just introduces a whole new category of bugs. Certainly, if you mis-size the argument (and thus have missized one of the variables containing the be value, probably a bug anyhow), there will be problems. I put this interface together because of an actual bug I wrote into the initial code of the hv_24x7 driver (resized a struct member without adjusting the be*_to_cpu() sizing). Having this auto sizing macro means I can avoid encoding the size of a struct field in multiple places. -- 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: [alsa-devel] [patch 2/2] ALSA: fireworks: small leak on error path
(May 29 2014 01:42), Dan Carpenter wrote:
There was a typo here so we return directly instead of freeing hwinfo.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
Reviewd-by: Takashi Sakamoto o-taka...@sakamocchi.jp
Tested-by: Takashi Sakamoto o-taka...@sakamocchi.jp
diff --git a/sound/firewire/fireworks/fireworks.c
b/sound/firewire/fireworks/fireworks.c
index 8e856cc..996fdc4 100644
--- a/sound/firewire/fireworks/fireworks.c
+++ b/sound/firewire/fireworks/fireworks.c
@@ -157,7 +157,7 @@ get_hardware_info(struct snd_efw *efw)
/* Hardware metering. */
if (hwinfo-phys_in_grp_count HWINFO_MAX_CAPS_GROUPS ||
hwinfo-phys_out_grp_count HWINFO_MAX_CAPS_GROUPS) {
- return -EIO;
+ err = -EIO;
goto end;
}
efw-phys_in = hwinfo-phys_in;
--
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 11/16] byteorder: provide a linux/byteorder.h with {be,le}_to_cpu() and cpu_to_{be,le}() macros
On Tue, May 27, 2014 at 7:44 PM, Joe Perches j...@perches.com wrote:
On Tue, 2014-05-27 at 17:22 -0700, Cody P Schafer wrote:
Rather manually specifying the size of the integer to be converted, key
off of the type size. Reduces duplicate size info and the occurance of
certain types of bugs (using the wrong sized conversion).
[]
diff --git a/include/linux/byteorder.h b/include/linux/byteorder.h
[]
@@ -0,0 +1,34 @@
+#ifndef LINUX_BYTEORDER_H_
+#define LINUX_BYTEORDER_H_
+
+#include asm/byteorder.h
+
+#define be_to_cpu(v) \
+ __builtin_choose_expr(sizeof(v) == sizeof(uint8_t) , v, \
+ __builtin_choose_expr(sizeof(v) == sizeof(uint16_t), be16_to_cpu(v), \
+ __builtin_choose_expr(sizeof(v) == sizeof(uint32_t), be32_to_cpu(v), \
+ __builtin_choose_expr(sizeof(v) == sizeof(uint64_t), be64_to_cpu(v), \
+ (void)0
probably better to use BUILD_BUG instead of these 0 returns
They aren't 0 returns.
$ echo int main(void) { int x = (void)0; return x; } | gcc -x c -
stdin: In function ‘main’:
stdin:1:26: error: void value not ignored as it ought to be
--
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] mtd: bf5xx_nand: use the managed version of kzalloc (Re: [PATCH] mtd: Introduce the use of the managed version of kzalloc)
On Fri, May 23, 2014 at 12:28:48AM +0530, Himangi Saraogi wrote:
This patch moves data allocated using kzalloc to managed data allocated
using devm_kzalloc and cleans now unnecessary kfrees in probe and remove
functions. Also, the now unnecessary label out_err_hw_init is done away
with and the label out_err_kzalloc is renamed to out_err.
The following Coccinelle semantic patch was used for making the change:
@platform@
identifier p, probefn, removefn;
@@
struct platform_driver p = {
.probe = probefn,
.remove = removefn,
};
@prb@
identifier platform.probefn, pdev;
expression e, e1, e2;
@@
probefn(struct platform_device *pdev, ...) {
+...
- e = kzalloc(e1, e2)
+ e = devm_kzalloc(pdev-dev, e1, e2)
...
?-kfree(e);
...+
}
@rem depends on prb@
identifier platform.removefn;
expression e;
@@
removefn(...) {
...
- kfree(e);
...
}
Signed-off-by: Himangi Saraogi himangi...@gmail.com
Improved the subject and pushed to l2-mtd.git. Thanks!
Brian
--
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 v3] PCI: Introduce new device binding path using pci_dev.driver_override
On Tue, May 20, 2014 at 08:53:21AM -0600, Alex Williamson wrote: The driver_override field allows us to specify the driver for a device rather than relying on the driver to provide a positive match of the device. This shortcuts the existing process of looking up the vendor and device ID, adding them to the driver new_id, binding the device, then removing the ID, but it also provides a couple advantages. First, the above existing process allows the driver to bind to any device matching the new_id for the window where it's enabled. This is often not desired, such as the case of trying to bind a single device to a meta driver like pci-stub or vfio-pci. Using driver_override we can do this deterministically using: echo pci-stub /sys/bus/pci/devices/:03:00.0/driver_override echo :03:00.0 /sys/bus/pci/devices/:03:00.0/driver/unbind echo :03:00.0 /sys/bus/pci/drivers_probe Previously we could not invoke drivers_probe after adding a device to new_id for a driver as we get non-deterministic behavior whether the driver we intend or the standard driver will claim the device. Now it becomes a deterministic process, only the driver matching driver_override will probe the device. To return the device to the standard driver, we simply clear the driver_override and reprobe the device: echo /sys/bus/pci/devices/:03:00.0/driver_override echo :03:00.0 /sys/bus/pci/devices/:03:00.0/driver/unbind echo :03:00.0 /sys/bus/pci/drivers_probe Another advantage to this approach is that we can specify a driver override to force a specific binding or prevent any binding. For instance when an IOMMU group is exposed to userspace through VFIO we require that all devices within that group are owned by VFIO. However, devices can be hot-added into an IOMMU group, in which case we want to prevent the device from binding to any driver (override driver = none) or perhaps have it automatically bind to vfio-pci. With driver_override it's a simple matter for this field to be set internally when the device is first discovered to prevent driver matches. Signed-off-by: Alex Williamson alex.william...@redhat.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org I applied this with Reviewed-bys/Acks from Konrad, Alexander, and Greg to pci/virtualization for v3.16, thanks! --- v3: kfree() override buffer on device release, noted by Alex Graf v2: Use strchr() as suggested by Guenter Roeck and adopted by the platform driver version of this same interface. Documentation/ABI/testing/sysfs-bus-pci | 21 drivers/pci/pci-driver.c| 25 +-- drivers/pci/pci-sysfs.c | 40 +++ drivers/pci/probe.c |1 + include/linux/pci.h |1 + 5 files changed, 85 insertions(+), 3 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci index a3c5a66..898ddc4 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci +++ b/Documentation/ABI/testing/sysfs-bus-pci @@ -250,3 +250,24 @@ Description: valid. For example, writing a 2 to this file when sriov_numvfs is not 0 and not 2 already will return an error. Writing a 10 when the value of sriov_totalvfs is 8 will return an error. + +What:/sys/bus/pci/devices/.../driver_override +Date:April 2014 +Contact: Alex Williamson alex.william...@redhat.com +Description: + This file allows the driver for a device to be specified which + will override standard static and dynamic ID matching. When + specified, only a driver with a name matching the value written + to driver_override will have an opportunity to bind to the + device. The override is specified by writing a string to the + driver_override file (echo pci-stub driver_override) and + may be cleared with an empty string (echo driver_override). + This returns the device to standard matching rules binding. + Writing to driver_override does not automatically unbind the + device from its current driver or make any attempt to + automatically load the specified driver. If no driver with a + matching name is currently loaded in the kernel, the device + will not bind to any driver. This also allows devices to + opt-out of driver binding using a driver_override name such as + none. Only a single driver may be specified in the override, + there is no support for parsing delimiters. diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c index d911e0c..4393c12 100644 --- a/drivers/pci/pci-driver.c +++ b/drivers/pci/pci-driver.c @@ -216,6 +216,13 @@ const struct pci_device_id
Re: [RFC 2/2] x86_64: expand kernel stack to 16K
On Wed, May 28, 2014 at 07:23:23AM -0700, H. Peter Anvin wrote: We tried for 4K on x86-64, too, for b quite a while as I recall. The kernel stack is a one of the main costs for a thread. I would like to decouple struct thread_info from the kernel stack (PJ Waskewicz was working on that before he left Intel) but that doesn't buy us all that much. 8K additional per thread is a huge hit. XFS has indeed always been a canary, or troublespot, I suspect because it originally came from another kernel where this was not an optimization target. sigh Always blame XFS for stack usage problems. Even when the reported problem is from IO to an ext4 filesystem. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- 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 11/16] byteorder: provide a linux/byteorder.h with {be, le}_to_cpu() and cpu_to_{be, le}() macros
On Wed, May 28, 2014 at 5:05 PM, Cody P Schafer d...@codyps.com wrote: On Wed, May 28, 2014 at 3:45 AM, David Laight david.lai...@aculab.com wrote: From: Cody P Schafer Rather manually specifying the size of the integer to be converted, key off of the type size. Reduces duplicate size info and the occurance of certain types of bugs (using the wrong sized conversion). ... +#define be_to_cpu(v) \ + __builtin_choose_expr(sizeof(v) == sizeof(uint8_t) , v, \ + __builtin_choose_expr(sizeof(v) == sizeof(uint16_t), be16_to_cpu(v), \ + __builtin_choose_expr(sizeof(v) == sizeof(uint32_t), be32_to_cpu(v), \ + __builtin_choose_expr(sizeof(v) == sizeof(uint64_t), be64_to_cpu(v), \ + (void)0 ... I'm not at all sure that using the 'size' of the constant will reduce the number of bugs - it just introduces a whole new category of bugs. Certainly, if you mis-size the argument (and thus have missized one of the variables containing the be value, probably a bug anyhow), there will be problems. I put this interface together because of an actual bug I wrote into the initial code of the hv_24x7 driver (resized a struct member without adjusting the be*_to_cpu() sizing). Having this auto sizing macro means I can avoid encoding the size of a struct field in multiple places. To clarify, the point I'm making here is that this simply cuts out 1 more place we can screw up endianness conversion sizing. -- 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] crypto: crc32c-pclmul - Shrink K_table to 32-bit words
crypto: crc32c-pclmul - Shrink K_table to 32-bit words There's no need for the K_table to be made of 64-bit words. For some reason, the original authors didn't fully reduce the values modulo the CRC32C polynomial, and so had some 33-bit number in there. They can all be reduced to 32 bits. Doing that cuts the table size in half. Since the code depends on both pclmulq and crc32, SSE 4.1 is obviously present, so we can use pmovzxdq to fetch it in the correct format. Two other related fixes: * K_table is read-only, so belongs in .text, not .data, and * There's no need for more than 8-byte alignment Signed-off-by: George Spelvin li...@horizon.com --- Fixed properly and tested with an exhaustive user-space test harness. I filled a 4K byte buffer with pseudorandom bytes and computed CRCs from i to j and from j to k for all 0 = i j k 4096, comparing both the intermediate and final results against a basic bit-at-a-time software algorithm. There's still room for improvement. Some additional areas that could use tweaking: - If the SMALL_SIZE is set right, that should also be the size where we fall out of the 3-part algorithm. As it is, a buffer of size 3096 will do a 3072-byte chunk and then do 3 8-byte CRCs and mess around a lot combining them. - Does it really warrant all the unrolling? Surely any processor new enough to have a fully pipelined crc32 insutruction can also handle some loop overhead instructions as well? - Some reassignment of the registers would put 32-bit variables (like crc_init_dw) in low registers so that they can be addressed without REX prefixes and shrink the ode. But 64-bit pointers like block_0 and block_1 are only ever used with 64-bit operands and thus REX prefixes. diff --git a/arch/x86/crypto/crc32c-pcl-intel-asm_64.S b/arch/x86/crypto/crc32c-pcl-intel-asm_64.S index dbc4339b..dcc50752 100644 --- a/arch/x86/crypto/crc32c-pcl-intel-asm_64.S +++ b/arch/x86/crypto/crc32c-pcl-intel-asm_64.S @@ -216,15 +216,11 @@ LABEL crc_ %i ## 4) Combine three results: - lea (K_table-16)(%rip), bufp# first entry is for idx 1 + lea (K_table-8)(%rip), bufp # first entry is for idx 1 shlq$3, %rax# rax *= 8 - subq%rax, tmp # tmp -= rax*8 - shlq$1, %rax - subq%rax, tmp # tmp -= rax*16 - # (total tmp -= rax*24) - addq%rax, bufp - - movdqa (bufp), %xmm0 # 2 consts: K1:K2 + pmovzxdq (bufp,%rax), %xmm0 # 2 consts: K1:K2 + leal(%eax,%eax,2), %eax # rax *= 3 (total *24) + subq%rax, tmp # tmp -= rax*24 movqcrc_init, %xmm1 # CRC for block 1 PCLMULQDQ 0x00,%xmm0,%xmm1 # Multiply by K2 @@ -238,9 +234,9 @@ LABEL crc_ %i mov crc2, crc_init crc32 %rax, crc_init - -## 5) Check for end: - + + ## 5) Check for end: + LABEL crc_ 0 mov tmp, len @@ -331,136 +327,135 @@ ENDPROC(crc_pcl) ## PCLMULQDQ tables - ## Table is 128 entries x 2 quad words each + ## Table is 128 entries x 2 words (8 bytes) each -.data -.align 64 +.align 8 K_table: -.quad 0x14cd00bd6,0x105ec76f0 -.quad 0x0ba4fc28e,0x14cd00bd6 -.quad 0x1d82c63da,0x0f20c0dfe -.quad 0x09e4addf8,0x0ba4fc28e -.quad 0x039d3b296,0x1384aa63a -.quad 0x102f9b8a2,0x1d82c63da -.quad 0x14237f5e6,0x01c291d04 -.quad 0x00d3b6092,0x09e4addf8 -.quad 0x0c96cfdc0,0x0740eef02 -.quad 0x18266e456,0x039d3b296 -.quad 0x0daece73e,0x0083a6eec -.quad 0x0ab7aff2a,0x102f9b8a2 -.quad 0x1248ea574,0x1c1733996 -.quad 0x083348832,0x14237f5e6 -.quad 0x12c743124,0x02ad91c30 -.quad 0x0b9e02b86,0x00d3b6092 -.quad 0x018b33a4e,0x06992cea2 -.quad 0x1b331e26a,0x0c96cfdc0 -.quad 0x17d35ba46,0x07e908048 -.quad 0x1bf2e8b8a,0x18266e456 -.quad 0x1a3e0968a,0x11ed1f9d8 -.quad 0x0ce7f39f4,0x0daece73e -.quad 0x061d82e56,0x0f1d0f55e -.quad 0x0d270f1a2,0x0ab7aff2a -.quad 0x1c3f5f66c,0x0a87ab8a8 -.quad 0x12ed0daac,0x1248ea574 -.quad 0x065863b64,0x08462d800 -.quad 0x11eef4f8e,0x083348832 -.quad 0x1ee54f54c,0x071d111a8 -.quad 0x0b3e32c28,0x12c743124 -
Re: [PATCH RFC RESEND 01/14] block: kconfig update and build bits for BFQ
On Tue, May 27, 2014 at 02:42:25PM +0200, paolo wrote: diff --git a/block/Makefile b/block/Makefile index 20645e8..cbd83fb 100644 --- a/block/Makefile +++ b/block/Makefile @@ -16,6 +16,7 @@ obj-$(CONFIG_BLK_DEV_THROTTLING)+= blk-throttle.o obj-$(CONFIG_IOSCHED_NOOP) += noop-iosched.o obj-$(CONFIG_IOSCHED_DEADLINE) += deadline-iosched.o obj-$(CONFIG_IOSCHED_CFQ)+= cfq-iosched.o +obj-$(CONFIG_IOSCHED_BFQ)+= bfq-iosched.o Doesn't this break builds where BFQ is enabled including all-y/m? Please make the config / makefile changes with the actual implementation. Thanks. -- tejun -- 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] Implement Batched (group) ticket lock
On Wed, May 28, 2014 at 2:55 PM, Rik van Riel r...@redhat.com wrote: Or maybe cmpxchg is cheap once you already own the cache line exclusively? A locked cmpxchg ends up being anything between ~15-50 cycles depending on microarchitecture if things are already exclusively in the cache (with the P4 being an outlier, and all locked instructions tend to take ~100+ cycles, but I can't say I can really find it in myself to even care about netburst any more). The most noticeable downside we've seen has been when we've used read-op-cmpxchg as a _replacement_ for something like lock [x]add, when that read+cmpxchg has caused two cacheline ops (cacheline first loaded shared by the read, then exclusive by the cmpxchg). That's bad. But if preceded by a write (or, in this case, an xadd), that doesn't happen. Still, those roughly 15-50 cycles can certainly be noticeable (especially at the high end), but you need to have some load that doesn't bounce the lock, and largely fit in the caches to see it. And you probably want to test one of the older CPU's, I think Haswell is the lower end (ie in the ~20 cycle range). If somebody has a P4 still, that's likely the worst case by far. 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 2/2] audit: Move CONFIG_AUDITSYSCALL into staging and update help text
Here are some issues with the code: - It thinks that syscalls have four arguments. - It's a performance disaster. - It assumes that syscall numbers are between 0 and 2048. - It's unclear whether it's supposed to be reliable. - It's broken on things like x32. - It can't support ARM OABI. - Its approach to memory allocation is terrifying. I considered marking it BROKEN, but that might be too harsh. Signed-off-by: Andy Lutomirski l...@amacapital.net --- init/Kconfig | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index 9d3585b..4584f8a 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -296,13 +296,16 @@ config HAVE_ARCH_AUDITSYSCALL bool config AUDITSYSCALL - bool Enable system-call auditing support - depends on AUDIT HAVE_ARCH_AUDITSYSCALL + bool Enable system-call auditing support (not recommended) + depends on AUDIT HAVE_ARCH_AUDITSYSCALL STAGING default y if SECURITY_SELINUX help - Enable low-overhead system-call auditing infrastructure that - can be used independently or with another kernel subsystem, - such as SELinux. + Enable system-call auditing infrastructure that can be used + independently or with another kernel subsystem, such as + SELinux. + + AUDITSYSCALL has serious performance and correctness issues. + Use it with extreme caution. config AUDIT_WATCH def_bool y -- 1.9.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/
[PATCH 0/2] Fix auditsc DoS and move it to staging
CONFIG_AUDITSYSCALL is awful. Patch 2 enumerates some reasons. Patch 1 fixes a nasty DoS and possible information leak. It should be applied and backported. Patch 2 is optional. I leave it to other peoples' judgment. Andy Lutomirski (2): auditsc: audit_krule mask accesses need bounds checking audit: Move CONFIG_AUDITSYSCALL into staging and update help text init/Kconfig | 13 - kernel/auditsc.c | 27 ++- 2 files changed, 26 insertions(+), 14 deletions(-) -- 1.9.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/
[PATCH 1/2] auditsc: audit_krule mask accesses need bounds checking
Fixes an easy DoS and possible information disclosure.
This does nothing about the broken state of x32 auditing.
Cc: sta...@vger.kernel.org
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
kernel/auditsc.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index f251a5e..7ccd9db 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -728,6 +728,22 @@ static enum audit_state audit_filter_task(struct
task_struct *tsk, char **key)
return AUDIT_BUILD_CONTEXT;
}
+static bool audit_in_mask(const struct audit_krule *rule, unsigned long val)
+{
+ int word, bit;
+
+ if (val 0x)
+ return false;
+
+ word = AUDIT_WORD(val);
+ if (word = AUDIT_BITMASK_SIZE)
+ return false;
+
+ bit = AUDIT_BIT(val);
+
+ return rule-mask[word] bit;
+}
+
/* At syscall entry and exit time, this filter is called if the
* audit_state is not low enough that auditing cannot take place, but is
* also not high enough that we already know we have to write an audit
@@ -745,11 +761,8 @@ static enum audit_state audit_filter_syscall(struct
task_struct *tsk,
rcu_read_lock();
if (!list_empty(list)) {
- int word = AUDIT_WORD(ctx-major);
- int bit = AUDIT_BIT(ctx-major);
-
list_for_each_entry_rcu(e, list, list) {
- if ((e-rule.mask[word] bit) == bit
+ if (audit_in_mask(e-rule, ctx-major)
audit_filter_rules(tsk, e-rule, ctx, NULL,
state, false)) {
rcu_read_unlock();
@@ -769,20 +782,16 @@ static enum audit_state audit_filter_syscall(struct
task_struct *tsk,
static int audit_filter_inode_name(struct task_struct *tsk,
struct audit_names *n,
struct audit_context *ctx) {
- int word, bit;
int h = audit_hash_ino((u32)n-ino);
struct list_head *list = audit_inode_hash[h];
struct audit_entry *e;
enum audit_state state;
- word = AUDIT_WORD(ctx-major);
- bit = AUDIT_BIT(ctx-major);
-
if (list_empty(list))
return 0;
list_for_each_entry_rcu(e, list, list) {
- if ((e-rule.mask[word] bit) == bit
+ if (audit_in_mask(e-rule, ctx-major)
audit_filter_rules(tsk, e-rule, ctx, n, state, false)) {
ctx-current_state = state;
return 1;
--
1.9.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/
Re: [PATCH] pci: Save and restore VFs as a part of a reset
On 05/28/2014 01:34 PM, Don Dutile wrote: On 05/28/2014 04:14 PM, Bjorn Helgaas wrote: On Wed, May 28, 2014 at 10:39 AM, Alexander Duyck alexander.h.du...@intel.com wrote: On 05/27/2014 09:12 PM, Alex Williamson wrote: On Tue, 2014-05-27 at 19:19 -0600, Bjorn Helgaas wrote: Maybe resetting the PF should just fail if there's an active VF. If you need to reset the PF, you'd have to unbind the VFs first. The use case is certainly questionable, personally I'm not going to expect VFs to continue working after the PF is reset. Driver binding gets complicated, especially when KVM doesn't actually bind devices to use them. Hopefully we'll get that out of the tree some day though. I suppose we could -EBUSY the PF reset as long as VFs are enabled. What I could do is go through and notify the VFs that they are about to get hit by a reset. What they do with that information would be up to them. So if the VFs are loaded on the host I could then at least allow them to recover by saving and restoring the config space within the driver themselves. I really like the idea of punting by failing the PF reset if there are any active VFs. That's a really easy way of making sure we aren't going to blow up any guests. What problems would it cause if we went this route? I think this is the safest route. PF-VF interaction isn't architected, and resetting the PF with active VFs will probably hang a number of SRIOV implementations, requiring a system-level reset to correct the compounded problem. Well it still might be worth while to allow a full PCIe reset in cases where the hardware has gotten into a bad state. It seems like it might be worthwhile to update the newly added reset notifier to allow for the device to indicate if it ready for a reset or not, with the default being to return -ENOTTY if the function is not implemented. This reminds me about an open problem: VFs can be on virtual buses, which aren't really connected in the hierarchy, and I don't think we have a nice way to iterate over them. So probably pci_get_device() is the best we can do now. Yeah, those virtual buses don't have a bus-self, we just have to skip to bus-parent-self. pci_walk_bus() goes in the opposite direction, but without an actual device hosting the bus, I don't see how it finds it. Thanks, It seems like we should be able to come up with something like pci_walk_vbus() though or something similar. All we would need to do is search the VFs on the bus of the PF and all child busses to that bus if I am not mistaken. I don't think that's going to work because the virtual buses don't appear as the child bus of anything. +1. Maybe I don't understand something but I have a function that I am already testing that seems to work for what I need. Is there any reason I couldn't use the bus-children list to navigate through the bus list and get all of the children of a given bus? I'll submit a couple patches for feedback on those bits. Thanks, Alex -- 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 v3 09/15] thunderbolt: Handle hotplug events
On Mon, May 26, 2014 at 05:18:06PM +0200, Andreas Noever wrote:
We reveive a plug event callback whenever a thunderbolt device is added
s/reveive/receive/
or removed. This patch fills in the tb_handle_hotplug method and starts
reacting to these events by adding/removing switches from the hierarchy.
Signed-off-by: Andreas Noever andreas.noe...@gmail.com
---
drivers/thunderbolt/switch.c | 42 +++-
drivers/thunderbolt/tb.c | 46
+++-
drivers/thunderbolt/tb.h | 3 +++
3 files changed, 89 insertions(+), 2 deletions(-)
diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
index 279b9c5..c092f7c 100644
--- a/drivers/thunderbolt/switch.c
+++ b/drivers/thunderbolt/switch.c
@@ -195,6 +195,24 @@ static void tb_dump_switch(struct tb *tb, struct
tb_regs_switch_header *sw)
sw-__unknown1, sw-__unknown4);
}
+struct tb_switch *get_switch_at_route(struct tb_switch *sw, u64 route)
+{
+ u8 next_port = route; /*
+* Routes use a stride of 8 bits,
+* eventhough a port index has 6 bits at most.
+* */
+ if (route == 0)
+ return sw;
+ if (next_port sw-config.max_port_number)
+ return 0;
+ if (tb_is_upstream_port(sw-ports[next_port]))
+ return 0;
+ if (!sw-ports[next_port].remote)
+ return 0;
+ return get_switch_at_route(sw-ports[next_port].remote-sw,
+route TB_ROUTE_SHIFT);
+}
+
/**
* tb_plug_events_active() - enable/disable plug events on a switch
*
@@ -243,7 +261,8 @@ void tb_switch_free(struct tb_switch *sw)
sw-ports[i].remote = NULL;
}
- tb_plug_events_active(sw, false);
+ if (!sw-is_unplugged)
+ tb_plug_events_active(sw, false);
kfree(sw-ports);
kfree(sw);
@@ -327,3 +346,24 @@ err:
return NULL;
}
+/**
+ * tb_sw_set_unpplugged() - set is_unplugged on switch and downstream
switches
+ */
+void tb_sw_set_unpplugged(struct tb_switch *sw)
+{
+ int i;
+ if (sw == sw-tb-root_switch) {
+ tb_sw_WARN(sw, cannot unplug root switch\n);
+ return;
+ }
+ if (sw-is_unplugged) {
+ tb_sw_WARN(sw, is_unplugged already set\n);
+ return;
+ }
+ sw-is_unplugged = true;
+ for (i = 0; i = sw-config.max_port_number; i++) {
+ if (!tb_is_upstream_port(sw-ports[i]) sw-ports[i].remote)
+ tb_sw_set_unpplugged(sw-ports[i].remote-sw);
+ }
+}
+
diff --git a/drivers/thunderbolt/tb.c b/drivers/thunderbolt/tb.c
index 3b716fd..1efcacc 100644
--- a/drivers/thunderbolt/tb.c
+++ b/drivers/thunderbolt/tb.c
@@ -71,11 +71,55 @@ static void tb_handle_hotplug(struct work_struct *work)
{
struct tb_hotplug_event *ev = container_of(work, typeof(*ev), work);
struct tb *tb = ev-tb;
+ struct tb_switch *sw;
+ struct tb_port *port;
mutex_lock(tb-lock);
if (!tb-hotplug_active)
goto out; /* during init, suspend or shutdown */
- /* do nothing for now */
+ sw = get_switch_at_route(tb-root_switch, ev-route);
+ if (!sw) {
+ tb_warn(tb,
+ hotplug event from non existent switch %llx:%x
(unplug: %d)\n,
+ ev-route, ev-port, ev-unplug);
+ goto out;
+ }
+ if (ev-port sw-config.max_port_number) {
+ tb_warn(tb,
+ hotplug event from non existent port %llx:%x (unplug:
%d)\n,
+ ev-route, ev-port, ev-unplug);
+ goto out;
+ }
+ port = sw-ports[ev-port];
+ if (tb_is_upstream_port(port)) {
+ tb_warn(tb,
+ hotplug event for upstream port %llx:%x (unplug:
%d)\n,
+ ev-route, ev-port, ev-unplug);
+ goto out;
+ }
+ if (ev-unplug) {
+ if (port-remote) {
+ tb_port_info(port, unplugged\n);
+ tb_sw_set_unpplugged(port-remote-sw);
+ tb_switch_free(port-remote-sw);
+ port-remote = NULL;
+ } else {
+ tb_port_info(port,
+ got unplug event for disconnected port,
ignoring\n);
+ }
+ } else if (port-remote) {
+ tb_port_info(port,
+ got plug event for connected port, ignoring\n);
+ } else {
+ tb_port_info(port, hotplug: scanning\n);
+ tb_scan_port(port);
+ if (!port-remote) {
+ tb_port_info(port, hotplug: no switch found\n);
+ } else if (port-remote-sw-config.depth 1) {
+ tb_sw_warn(port-remote-sw,
+
[PATCH] asm-generic: uaccess: avoid name conflicts for strncpy and str(n)len
asm-generic/uaccess.h defines 'strncpy_from_user', 'strnlen_user' and
'strlen_user' as static inline functions. It makes it impossible for an
arch to include asm-generic/uaccess.h and benefits from its content, in
addition to defining GENERIC_STRNCPY_FROM_USER and GENERIC_STRNLEN_USER.
Both configuration tokens respectively enable lib/strncpy_from_user.c
and lib/strnlen_user.c which redefine the same symbols, causing
redefinition errors at compilation.
This patch modifies asm-generic/uaccess.h so that strncpy_from_user is
not defined when GENERIC_STRNCPY_FROM_USER is, and strnlen_user and
strlen_user are not defined when GENERIC_STRNLEN_USER is, thus avoiding
any name conflict.
At the moment, numerous archs, which make use of
GENERIC_STRNCPY_FROM_USER and GENERIC_STRNLEN_USER, are forced to
rewrite an entire asm/uaccess.h header because of this issue.
To the best of my knowledge, the following list of archs could benefit
from this patch: x86, sh, openrisc, powerpc, arm64, arm, alpha, parisc,
sparc, m68k.
Signed-off-by: Joel Porquet j...@porquet.org
---
include/asm-generic/uaccess.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/asm-generic/uaccess.h b/include/asm-generic/uaccess.h
index 72d8803..4198d84 100644
--- a/include/asm-generic/uaccess.h
+++ b/include/asm-generic/uaccess.h
@@ -272,6 +272,7 @@ static inline long copy_to_user(void __user *to,
return n;
}
+#ifndef CONFIG_GENERIC_STRNCPY_FROM_USER
/*
* Copy a null terminated string from userspace.
*/
@@ -294,7 +295,9 @@ strncpy_from_user(char *dst, const char __user *src, long
count)
return -EFAULT;
return __strncpy_from_user(dst, src, count);
}
+#endif
+#ifndef CONFIG_GENERIC_STRNLEN_USER
/*
* Return the size of a string (including the ending 0)
*
@@ -320,6 +323,7 @@ static inline long strlen_user(const char __user *src)
{
return strnlen_user(src, 32767);
}
+#endif
/*
* Zero Userspace
--
1.9.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/
[PATCH 1/2] pci: Add pci_walk_vbus for walking virtual busses associated with SR-IOV
This function provides a simple means for applying a given function to all
devices on bus and all of it's children, including virtual busses. To do
this the function begins by processing all devices on the bus, then it will
proceed through bus-children and process each of the child busses.
Signed-off-by: Alexander Duyck alexander.h.du...@intel.com
---
drivers/pci/bus.c | 44
include/linux/pci.h |2 ++
2 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index fb8aed3..769bbcb 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -336,6 +336,50 @@ void pci_walk_bus(struct pci_bus *top, int (*cb)(struct
pci_dev *, void *),
}
EXPORT_SYMBOL_GPL(pci_walk_bus);
+/** pci_walk_vbus - walk devices on/under bus, calling callback.
+ * @top bus whose devices should be walked
+ * @cb callback to be called for each device found
+ * @userdata arbitrary pointer to be passed to callback.
+ *
+ * Walk the given bus, including any child buses under this bus.
+ * Call the provided callback on each device found.
+ *
+ * We check the return of @cb each time. If it returns anything
+ * other than 0, we break out.
+ *
+ */
+void pci_walk_vbus(struct pci_bus *top, int (*cb)(struct pci_dev *, void *),
+ void *userdata)
+{
+ struct list_head *bus_next;
+ struct pci_bus *bus;
+ struct pci_dev *dev;
+
+ down_read(pci_bus_sem);
+ bus_next = top-node;
+ for (;;) {
+ /* prep bus for next iteration */
+ bus = list_entry(bus_next, struct pci_bus, node);
+
+ /* process each device on this bus */
+ list_for_each_entry(dev, bus-devices, bus_list) {
+ if (cb(dev, userdata))
+ goto release_semaphore;
+ }
+
+ /* end of this bus, go to child, next bus, or finish */
+ for (bus_next = bus-children.next;
+bus_next == bus-children;
+bus_next = bus-node.next, bus = bus-parent) {
+ if (bus == top)
+ goto release_semaphore;
+ }
+ }
+release_semaphore:
+ up_read(pci_bus_sem);
+}
+EXPORT_SYMBOL_GPL(pci_walk_vbus);
+
struct pci_bus *pci_bus_get(struct pci_bus *bus)
{
if (bus)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index aab57b4..1fb18a8 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1118,6 +1118,8 @@ int pci_scan_bridge(struct pci_bus *bus, struct pci_dev
*dev, int max,
void pci_walk_bus(struct pci_bus *top, int (*cb)(struct pci_dev *, void *),
void *userdata);
+void pci_walk_vbus(struct pci_bus *top, int (*cb)(struct pci_dev *, void *),
+ void *userdata);
int pci_cfg_space_size(struct pci_dev *dev);
unsigned char pci_bus_max_busnr(struct pci_bus *bus);
void pci_setup_bridge(struct pci_bus *bus);
--
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] Implement Batched (group) ticket lock
On Wed, 28 May 2014, Linus Torvalds wrote: If somebody has a P4 still, that's likely the worst case by far. I do, but I'm only using it during winter and only if the ia64 machine does not provide sufficient heating. So you have to wait at least half a year until I'm able to test it. -- 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/
