Re: stec skd block driver needs updating for immutable biovec
On Fri, Nov 01 2013 at 12:34pm -0400, Jens Axboe wrote: > On 11/01/2013 10:28 AM, Mike Snitzer wrote: > > On Fri, Nov 01 2013 at 12:02pm -0400, > > Jens Axboe wrote: > > > >> On 11/01/2013 09:50 AM, Christoph Hellwig wrote: > >>> On Fri, Nov 01, 2013 at 11:43:39AM -0400, Mike Snitzer wrote: > All the bi_sector ones are low hanging fruit, but the conversion for > skd_preop_sg_list_bio()'s bio_vec code is more involved. > > Kent, any chance you could crank through it? > > If not I can come back to trying to fix this later.. but I'm working > through a test merge of linux-dm.git's 'for-next' with linux-block.git's > 'for-next'. > >>> > >>> The right thing for 3.13 is to rip out the bio base code path, and > >>> for 3.14 to convert it to blk-mq. > >> > >> It is. I will kill it. > > > > I just cranked through it.. hope this helps (think I got everything but > > may have missed something): > > You lost out, I committed it 20 min ago :-0 Cool, it's OK, I was still able to get the fulfilling experience of killing a bunch of code... made my day. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Run checksumming in parallel accross multiple alu's
On Fri, Nov 01, 2013 at 04:18:50PM -, David Laight wrote: > > How would you suggest replacing the jumps in this case? I agree it would be > > faster here, but I'm not sure how I would implement an increment using a > > single > > conditional move. > > I think you need 3 instructions, move a 0, conditionally move a 1 > then add. I suspect it won't be a win! > > If you do 'win' it is probably very dependent on how the instructions > get scheduled onto the execution units - which will probably make > it very cpu type dependant. > > David > I agree, that sounds interesting, but very cpu dependent. Thanks for the suggestion, Ben, but I think it would be better if we just did the prefetch here and re-addressed this area when AVX (or addcx/addox) instructions were available for testing on hardware. Neil -- 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: Disabling in-memory write cache for x86-64 in Linux II
// Sorry for the late response! I'm in marriage leave these days. :) On Tue, Oct 29, 2013 at 03:42:08PM -0700, Linus Torvalds wrote: > On Tue, Oct 29, 2013 at 3:13 PM, Jan Kara wrote: > > > > So I think we both realize this is only about what the default should be. > > Yes. Most people will use the defaults, but there will always be > people who tune things for particular loads. > > In fact, I think we have gone much too far in saying "all policy in > user space", because the fact is, user space isn't very good at > policy. Especially not at reacting to complex situations with > different devices. From what I've seen, "policy in user space" has > resulted in exactly two modes: > > - user space does something stupid and wrong (example: "nice -19 X" > to work around some scheduler oddities) > > - user space does nothing at all, and the kernel people say "hey, > user space _could_ set this value Xyz, so it's not our problem, and > it's policy, so we shouldn't touch it". > > I think we in the kernel should say "our defaults should be what > everybody sane can use, and they should work fine on average". With > "policy in user space" being for crazy people that do really odd > things and can really spare the time to tune for their particular > issue. > > So the "policy in user space" should be about *overriding* kernel > policy choices, not about the kernel never having them. Agreed totally. The kernel defaults should better be geared to the typical use case by the majority users, unless it will lead to insane behaviors in some less frequent but still relevant use cases. > And this kind of "you can have many different devices and they act > quite differently" is a good example of something complicated that > user space really doesn't have a great model for. And we actually have > much better possible information in the kernel than user space ever is > likely to have. > > > Also I'm not sure capping dirty limits at 200MB is the best spot. It may be > > but I think we should experiment with numbers a bit to check whether we > > didn't miss something. > > Sure. That said, the patch I suggested basically makes the numbers be > at least roughly comparable across different architectures. So it's > been at least somewhat tested, even if 16GB x86-32 machines are > hopefully pretty rare (but I hear about people installing 32-bit on > modern machines much too often). Yeah, it's interesting the new policy rule actually makes x86_64 behave more consistent with i386, and hence have been reasonably tested. > >> - temp-files may not be written out at all. > >> > >>Quite frankly, if you have multi-hundred-megabyte temptiles, you've > >> got issues > > Actually people do stuff like this e.g. when generating ISO images before > > burning them. > > Yes, but then the temp-file is long-lived enough that it *will* hit > the disk anyway. So it's only the "create temporary file and pretty > much immediately delete it" case that changes behavior (ie compiler > assembly files etc). > > If the temp-file is for something like burning an ISO image, the > burning part is slow enough that the temp-file will hit the disk > regardless of when we start writing it. The temp-file IO avoidance is an optimization not a guarantee. If a user want to avoid IO seriously, he will probably use tmpfs and disable swap. So if we have to do some trade-offs in the optimization, I agree that we should optimize more towards the "large copies to USB stick" use case. The alternative solution, per-bdi dirty thresholds, could eliminate the need to do such trade-offs. So it's worth looking at the two solutions side by side. > > There is one more aspect: > > - transforming random writes into mostly sequential writes > > Sure. And I think that if you have a big database, that's when you do > end up tweaking the dirty limits. Sure. In general, whenever we have to make some tradeoffs, it's probably better to "sacrifice" the embedded and super computing worlds much more than the desktop. Because in the former areas, people tend to have the skill and mind set to do customizations and optimizations. I wonder if some hand-held devices will set dirty_background_bytes to 0 for better data safety. > That said, I'd certainly like it even *more* if the limits really were > per-BDI, and the global limit was in addition to the per-bdi ones. > Because when you have a USB device that gets maybe 10MB/s on > contiguous writes, and 100kB/s on random 4k writes, I think it would > make more sense to make the "start writeout" limits be 1MB/2MB, not > 100MB/200MB. So my patch doesn't even take it far enough, it's just a > "let's not be ridiculous". The per-BDI limits don't seem quite ready > for prime time yet, though. Even the new "strict" limits seems to be > more about "trusted filesystems" than about really sane writeback > limits. > > Fengguang, comments? Basically A) lowering the global dirty limit is a reasonable tradeoff, and B) the time based
rcu: Throttle rcu_try_advance_all_cbs() execution causes visible slowdown in ftrace switching
Hi, I am doing some clean up in x86 ftrace code. I check the performance by switching between different tracers and by enabling and disabling them. The operation has started to be much slower after rebasing on the kernel tip tree. Bisecting has shown that the difference was caused by the commit c229828ca6bc62d6c654 (rcu: Throttle rcu_try_advance_all_cbs() execution) The following times are from Intel 2xCore i7-3770 CPU @ 3.40GHz when calling the attached test script (time ./test-ftrace). It 100x switches between "function" and "nop" tracer. It also enables and disables the tracer each time. Results with the commit c229828ca6bc62d6c654: real0m49.393s 0m49.632s 0m49.359s user0m0.004s 0m0.000s 0m0.004s sys 0m0.996s 0m0.880s 0m0.892s Results after reverting the commit c229828ca6bc62d6c654: real0m35.320s 0m35.687s 0m35.920s user0m0.004s 0m0.004s 0m0.000s sys 0m1.140s 0m1.208s 0m1.152s I might do some more debugging on Monday. I wonder if you have any hints or ideas. Best Regards, Petr test-ftrace Description: application/shellscript
Re: [PATCH driver-core-next] sysfs: use generic_file_llseek() for sysfs_file_operations
On Fri, Nov 01, 2013 at 01:16:53PM -0400, Tejun Heo wrote: > Hey, Greg. > > Here's proper patch with description and SOB. I'll be traveling from > tomorrow so I might not be responsive for some days. Can you please > apply it once Heiko confirms it fixes the issue? Will do. Heiko, let me know if this fixes your problem or not, 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] phy: Add MOXA RTL8201CP PHY support
Hi Jonas,
On Friday 01 November 2013 08:24 PM, Jonas Jensen wrote:
The MOXA UC-711X hardware(s) has an ethernet controller that seem
to be developed internally. The IC used is "RTL8201CP".
This patch adds an MDIO driver and also patches realtek to include
RTL8201CP PHY driver.
Signed-off-by: Jonas Jensen
Added netdev mailing list and David Miller as I don't maintain ethernet
PHYs.
Thanks
Kishon
---
Notes:
The hardware does not use a separate IRQ for PHY.
The link state change interrupt can instead be caught by MAC but the
current drivers/of/of_mdio.c does not allow it to be handled in MAC.
Applies to next-20131031
.../devicetree/bindings/net/moxa,moxart-mdio.txt | 19 ++
drivers/net/phy/Kconfig| 7 +
drivers/net/phy/Makefile | 1 +
drivers/net/phy/mdio-moxart.c | 201 +
drivers/net/phy/realtek.c | 15 ++
5 files changed, 243 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/moxa,moxart-mdio.txt
create mode 100644 drivers/net/phy/mdio-moxart.c
diff --git a/Documentation/devicetree/bindings/net/moxa,moxart-mdio.txt
b/Documentation/devicetree/bindings/net/moxa,moxart-mdio.txt
new file mode 100644
index 000..de0b90c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/moxa,moxart-mdio.txt
@@ -0,0 +1,19 @@
+* MOXA ART MDIO Ethernet Controller interface
+
+Required properties:
+- compatible: should be "moxa,moxart-mdio".
+- reg: address and length of the register set for the device.
+
+Example:
+mdio1: mdio@9290 {
+ compatible = "moxa,moxart-mdio";
+ reg = <0x9290 0x8>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy1: ethernet-phy@1 {
+ device_type = "ethernet-phy";
+ compatible = "moxa,moxart-rtl8201cp";
+ reg = <1>;
+ };
+};
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 342561a..9b5d46c 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -154,6 +154,13 @@ config MDIO_SUN4I
interface units of the Allwinner SoC that have an EMAC (A10,
A12, A10s, etc.)
+config MDIO_MOXART
+tristate "MOXA ART MDIO interface support"
+depends on ARCH_MOXART
+help
+ This driver supports the MDIO interface found in the network
+ interface units of the MOXA ART SoC
+
config MDIO_BUS_MUX
tristate
depends on OF_MDIO
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 23a2ab2..9013dfa 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -31,3 +31,4 @@ obj-$(CONFIG_MDIO_BUS_MUX)+= mdio-mux.o
obj-$(CONFIG_MDIO_BUS_MUX_GPIO) += mdio-mux-gpio.o
obj-$(CONFIG_MDIO_BUS_MUX_MMIOREG) += mdio-mux-mmioreg.o
obj-$(CONFIG_MDIO_SUN4I) += mdio-sun4i.o
+obj-$(CONFIG_MDIO_MOXART) += mdio-moxart.o
diff --git a/drivers/net/phy/mdio-moxart.c b/drivers/net/phy/mdio-moxart.c
new file mode 100644
index 000..ad5d0f8
--- /dev/null
+++ b/drivers/net/phy/mdio-moxart.c
@@ -0,0 +1,201 @@
+/* MOXA ART Ethernet (RTL8201CP) MDIO interface driver
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define REG_PHY_CTRL0
+#define REG_PHY_WRITE_DATA 4
+
+/* REG_PHY_CTRL */
+#define MIIWR BIT(27) /* init write sequence (auto cleared)*/
+#define MIIRD BIT(26)
+#define REGAD_MASK 0x3e0
+#define PHYAD_MASK 0x1f
+#define MIIRDATA_MASK 0x
+
+/* REG_PHY_WRITE_DATA */
+#define MIIWDATA_MASK 0x
+
+struct moxart_mdio_data {
+ void __iomem*base;
+};
+
+static int moxart_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
+{
+ struct moxart_mdio_data *data = bus->priv;
+ u32 ctrl = 0;
+ unsigned int count = 5;
+
+ dev_dbg(>dev, "%s\n", __func__);
+
+ ctrl |= MIIRD | ((mii_id << 16) & PHYAD_MASK) |
+ ((regnum << 21) & REGAD_MASK);
+
+ writel(ctrl, data->base + REG_PHY_CTRL);
+
+ do {
+ ctrl = readl(data->base + REG_PHY_CTRL);
+
+ if (!(ctrl & MIIRD))
+ return ctrl & MIIRDATA_MASK;
+
+ mdelay(10);
+ count--;
+ } while (count > 0);
+
+ dev_err(>dev, "%s timed out\n", __func__);
+
+ return -ETIMEDOUT;
+}
+
+static int moxart_mdio_write(struct mii_bus *bus, int mii_id,
+int regnum, u16 value)
+{
+ struct moxart_mdio_data *data = bus->priv;
+ u32 ctrl = 0;
+ unsigned int count =
[PATCH driver-core-next] sysfs: use generic_file_llseek() for sysfs_file_operations
Hey, Greg.
Here's proper patch with description and SOB. I'll be traveling from
tomorrow so I might not be responsive for some days. Can you please
apply it once Heiko confirms it fixes the issue?
Thanks!
--- 8< ---
13c589d5b0ac6 ("sysfs: use seq_file when reading regular files")
converted regular sysfs files to use seq_file. The commit substituted
generic_file_llseek() with seq_lseek() for llseek implementation.
Before the change, all regular sysfs files were allowed to seek to any
position in [0, PAGE_SIZE] as the file size is always PAGE_SIZE and
generic_file_llseek() allows any seeking inside the range under file
size; however, seq_lseek()'s behavior is different. It traverses the
output by repeatedly invoking ->show() until it reaches the target
offset or traversal indicates EOF. As seq_files are fully dynamic and
may not end at all, it doesn't support seeking from the end
(SEEK_END).
Apparently, there are userland tools which uses SEEK_END to discover
the buffer size to use and the switch to seq_lseek() disturbs them as
SEEK_END fails with -EINVAL.
The only benefits of using seq_lseek() instead of
generic_file_llseek() are
* Early failure. If traversing to certain file position should fail,
seq_lseek() will report such failures on lseek(2) instead of the
following read/write operations.
* EOF detection. While SEEK_END is not supported, SEEK_SET/CUR +
large offset can be used to detect eof - eof at the time of the seek
anyway as the file size may change dynamically.
Both aren't necessary for sysfs or prospect kernfs users. Revert to
genefic_file_llseek() and preserve the original behavior.
Signed-off-by: Tejun Heo
Reported-by: Heiko Carstens
Link: https://lkml.kernel.org/r/20131031114358.GA5551@osiris
---
fs/sysfs/file.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -800,7 +800,7 @@ EXPORT_SYMBOL_GPL(sysfs_notify);
const struct file_operations sysfs_file_operations = {
.read = seq_read,
.write = sysfs_write_file,
- .llseek = seq_lseek,
+ .llseek = generic_file_llseek,
.open = sysfs_open_file,
.release= sysfs_release,
.poll = sysfs_poll,
--
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: Re: Re: Re: Re: Re: [PATCH 1/3] switch_creds: Syscall to switch creds for file server ops
On Saturday, November 02, 2013 01:07:59 Tetsuo Handa wrote:
> Jim Lieb wrote:
> > On Friday, November 01, 2013 22:24:12 Tetsuo Handa wrote:
> > > Jim Lieb wrote:
> > > > Subsequent uses look like:
> > > > use_creds(cached fd);
> > > >
> > > > followed by
> > > >
> > > > open/creat/mknod/write
> > > >
> > > > followed by
> > > >
> > > > use_creds(-1);
> > >
> > > Are you aware that calling commit_creds() is prohibitted between
> > > override_creds() and revert_creds() ?
> > >
> > > If the caller does some operation that calls commit_creds() (like
> > > example below), the kernel triggers BUG().
> >
> > Yes, I do. I caught this in an early pass. I only use override_creds()
> > and revert_creds().
>
> Excuse me, but even below example will trigger BUG(). You pack
> override_creds() + open() + revert_creds() into one system call so that the
> caller of this system call shall not do something that calls commit_creds()
> ?
Ok, I see your point here. If I do a switch_creds and the userland does
something like seteuid before I do the revert, we are toast. Correct?
This is an issue. Thanks for pointing this out. It is certainly not in my
use case but that doesn't mean someone else won't try it. I have some more
work to do.
>
> -- example module start --
> #include
> #include
> #include
> #include
>
> static int __init test_init(void)
> {
> const struct cred *orig;
> { /* switch_cred() syscall */
> struct fd f = fdget(0);
> if (!f.file)
> return -EBADF;
> orig = override_creds(f.file->f_cred);
> fdput(f);
> }
> { /* something that calls commit_creds() */
> struct cred *cred = prepare_creds();
> if (cred)
> commit_creds(cred);
> }
> { /* restore */
> revert_creds(orig);
> }
> return 0;
> }
>
> static void test_exit(void)
> {
> }
>
> module_init(test_init);
> module_exit(test_exit);
> MODULE_LICENSE("GPL");
> -- example module end --
--
Jim Lieb
Linux Systems Engineer
Panasas Inc.
"If ease of use was the only requirement, we would all be riding tricycles"
- Douglas Engelbart 1925–2013
--
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] extcon-gpio: add devicetree support.
Hi Neil, While I'm not fundamentally opposed to this binding, I have some issues with its current form and would not want to see this version hit mainline. On Fri, Nov 01, 2013 at 09:50:05AM +, NeilBrown wrote: > > As this device is not vendor specific, I haven't included any "vendor," > prefixes. For my model I used "regulator-gpio" which takes a similar > approach. > > Signed-off-by: NeilBrown > > diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt > b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt > new file mode 100644 > index ..2346b61cc620 > --- /dev/null > +++ b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt > @@ -0,0 +1,26 @@ > +* EXTCON detector using GPIO EXTCON is _extremely_ Linux-specific. The binding document needs a description of the class of device it's inteded to describe that does not just refer to Linux internals. I would prefer if we could have a better name for this that was not tied to the Linux driver name. Perhaps "gpio-presence-detector"? > + > +Required Properties: > + - compatible: "extcon-gpio" > + - gpios: gpio line that detects connector > + - interrupts: interrupt generated by that gpio We don't need this. If we need the interrupt a gpio generates, we should ask the gpio controller driver to map the gpio to an interrupt. We have gpiod_to_irq for this in Linux. > + - debounce-delay-ms: debouncing delay > + > +Optional Properties: > + - label: name for connector. If not given, device name is used. > + - state-on: string to report when GPIO is high (else '0') > + - state-off: string to report when GPIO is low (else '1') I do not like these properties, they are very much a Linux implementation detail. Are extcon devices ever used standalone? If so, why? If not I see _no_ reason at all for the label property. If a userspace application needs to detect the presence of a particular external connector, it will need to know this in relation to the device the external connectors are attached to. In that case the application should find that device and traverse its set of extcon devices. The names for the external connections will be a property of the device, not the extcon devices themselves (along hte same lines as clocks), and need not be a property of the extcon device. As for state-on and state-off, we are exposing a binary property to userspace, the meaning of which is already dependent on the particular device the extcon devices are connected to. Given userspace already has to understand that, I see no value in embedding arbitrary strings in the device tree which attempt to replicate this knowledge. They provide no additional value and in my mind make the interface to userspace harder to use because you have ot handle an arbitrary set of values depending on how the dt author felt one morning rather than just the binary value you actually care about. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/4] ARM: dts: Add initial device tree support for EXYNOS5410
On Monday 14 of October 2013 19:08:25 Vyacheslav Tyrtov wrote: > From: Tarek Dakhran > > Add initial device tree nodes for EXYNOS5410 SoC and SMDK5410 board. > > Signed-off-by: Tarek Dakhran > Signed-off-by: Vyacheslav Tyrtov > --- > arch/arm/boot/dts/Makefile| 1 + > arch/arm/boot/dts/exynos5410-smdk5410.dts | 65 ++ > arch/arm/boot/dts/exynos5410.dtsi | 209 > ++ 3 files changed, 275 insertions(+) > create mode 100644 arch/arm/boot/dts/exynos5410-smdk5410.dts > create mode 100644 arch/arm/boot/dts/exynos5410.dtsi Reviewed-by: Tomasz Figa Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] ARM: EXYNOS: Add support for EXYNOS5410 SoC
On Monday 14 of October 2013 19:08:22 Vyacheslav Tyrtov wrote: > From: Tarek Dakhran > > EXYNOS5410 is SoC in Samsung's Exynos5 SoC series. > Add initial support for this SoC. > > Signed-off-by: Tarek Dakhran > Signed-off-by: Vyacheslav Tyrtov > --- > arch/arm/mach-exynos/Kconfig | 12 > arch/arm/mach-exynos/common.c| 18 ++ > arch/arm/mach-exynos/include/mach/map.h | 1 + > arch/arm/mach-exynos/mach-exynos5-dt.c | 1 + > arch/arm/plat-samsung/include/plat/cpu.h | 8 > 5 files changed, 40 insertions(+) Reviewed-by: Tomasz Figa Best regards, Tomasz -- 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] phy: Add MOXA RTL8201CP PHY support
Hello Jonas,
2013/11/1 Jonas Jensen :
> The MOXA UC-711X hardware(s) has an ethernet controller that seem
> to be developed internally. The IC used is "RTL8201CP".
>
> This patch adds an MDIO driver and also patches realtek to include
> RTL8201CP PHY driver.
>
> Signed-off-by: Jonas Jensen
> ---
>
> Notes:
> The hardware does not use a separate IRQ for PHY.
>
> The link state change interrupt can instead be caught by MAC but the
> current drivers/of/of_mdio.c does not allow it to be handled in MAC.
>
> Applies to next-20131031
>
> .../devicetree/bindings/net/moxa,moxart-mdio.txt | 19 ++
> drivers/net/phy/Kconfig| 7 +
> drivers/net/phy/Makefile | 1 +
> drivers/net/phy/mdio-moxart.c | 201
> +
> drivers/net/phy/realtek.c | 15 ++
> 5 files changed, 243 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/moxa,moxart-mdio.txt
> create mode 100644 drivers/net/phy/mdio-moxart.c
>
> diff --git a/Documentation/devicetree/bindings/net/moxa,moxart-mdio.txt
> b/Documentation/devicetree/bindings/net/moxa,moxart-mdio.txt
> new file mode 100644
> index 000..de0b90c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/moxa,moxart-mdio.txt
> @@ -0,0 +1,19 @@
> +* MOXA ART MDIO Ethernet Controller interface
> +
> +Required properties:
> +- compatible: should be "moxa,moxart-mdio".
> +- reg: address and length of the register set for the device.
> +
> +Example:
> +mdio1: mdio@9290 {
> + compatible = "moxa,moxart-mdio";
> + reg = <0x9290 0x8>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethphy1: ethernet-phy@1 {
> + device_type = "ethernet-phy";
> + compatible = "moxa,moxart-rtl8201cp";
> + reg = <1>;
> + };
> +};
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index 342561a..9b5d46c 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -154,6 +154,13 @@ config MDIO_SUN4I
> interface units of the Allwinner SoC that have an EMAC (A10,
> A12, A10s, etc.)
>
> +config MDIO_MOXART
> +tristate "MOXA ART MDIO interface support"
> +depends on ARCH_MOXART
> +help
> + This driver supports the MDIO interface found in the network
> + interface units of the MOXA ART SoC
> +
> config MDIO_BUS_MUX
> tristate
> depends on OF_MDIO
> diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
> index 23a2ab2..9013dfa 100644
> --- a/drivers/net/phy/Makefile
> +++ b/drivers/net/phy/Makefile
> @@ -31,3 +31,4 @@ obj-$(CONFIG_MDIO_BUS_MUX)+= mdio-mux.o
> obj-$(CONFIG_MDIO_BUS_MUX_GPIO)+= mdio-mux-gpio.o
> obj-$(CONFIG_MDIO_BUS_MUX_MMIOREG) += mdio-mux-mmioreg.o
> obj-$(CONFIG_MDIO_SUN4I) += mdio-sun4i.o
> +obj-$(CONFIG_MDIO_MOXART) += mdio-moxart.o
> diff --git a/drivers/net/phy/mdio-moxart.c b/drivers/net/phy/mdio-moxart.c
> new file mode 100644
> index 000..ad5d0f8
> --- /dev/null
> +++ b/drivers/net/phy/mdio-moxart.c
> @@ -0,0 +1,201 @@
> +/* MOXA ART Ethernet (RTL8201CP) MDIO interface driver
> + *
> + * Copyright (C) 2013 Jonas Jensen
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define REG_PHY_CTRL0
> +#define REG_PHY_WRITE_DATA 4
> +
> +/* REG_PHY_CTRL */
> +#define MIIWR BIT(27) /* init write sequence (auto
> cleared)*/
> +#define MIIRD BIT(26)
> +#define REGAD_MASK 0x3e0
> +#define PHYAD_MASK 0x1f
> +#define MIIRDATA_MASK 0x
> +
> +/* REG_PHY_WRITE_DATA */
> +#define MIIWDATA_MASK 0x
> +
> +struct moxart_mdio_data {
> + void __iomem*base;
> +};
> +
> +static int moxart_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
> +{
> + struct moxart_mdio_data *data = bus->priv;
> + u32 ctrl = 0;
> + unsigned int count = 5;
> +
> + dev_dbg(>dev, "%s\n", __func__);
> +
> + ctrl |= MIIRD | ((mii_id << 16) & PHYAD_MASK) |
> + ((regnum << 21) & REGAD_MASK);
> +
> + writel(ctrl, data->base + REG_PHY_CTRL);
> +
> + do {
> + ctrl = readl(data->base + REG_PHY_CTRL);
> +
> + if (!(ctrl & MIIRD))
> + return ctrl & MIIRDATA_MASK;
> +
> + mdelay(10);
> + count--;
> + } while (count > 0);
> +
> + dev_err(>dev, "%s timed out\n", __func__);
I would keep these as a debugging aid and not spawn error messages on
the console by default.
> +
> +
Re: [PATCH 2/2] virtio_blk: blk-mq support
On 11/01/2013 10:45 AM, Christoph Hellwig wrote: > Updated version to address Asias' comments and rebased ontop of > block/for-next with the immutable bio changes: Thanks, I updated the blk-mq/drivers branch to have the for-3.13/core immutable changes and replaced the existing virtio-blk patch. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PATCH] USB fixes for 3.12-final
The following changes since commit 959f58544b7f20c92d5eb43d1232c96c15c01bfb: Linux 3.12-rc7 (2013-10-27 16:12:03 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-3.12-rc8 for you to fetch changes up to e1466ad5b1aeda303f9282463d55798d2eda218c: USB: serial: ftdi_sio: add id for Z3X Box device (2013-11-01 09:33:56 -0700) USB fixes for 3.12-final Here is a set of patches that revert all of the changes done to the pl2303 USB serial driver in the 3.12-rc timeframe, as it turns out they break some devices that work just fine on 3.11. As it's not a good idea to break working systems, drop them all and they will be reworked for future kernel versions such that there is no breakage. I've also included a MAINTAINERS update for the USB serial subsystem and a new device id for the ftdi_sio driver as well. Signed-off-by: Greg Kroah-Hartman Greg KH (1): USB: Maintainers change for usb serial drivers Greg Kroah-Hartman (12): Revert "USB: pl2303: distinguish between original and cloned HX chips" Revert "pl2303: improve the chip type detection/distinction" Revert "pl2303: improve the chip type information output on startup" Revert "pl2303: simplify the else-if contruct for type_1 chips in pl2303_startup()" Revert "usb: pl2303: add two comments concerning the supported baud rates with HX chips" Revert "usb: pl2303: also use the divisor based baud rate encoding method for baud rates < 115200 with HX chips" Revert "usb: pl2303: increase the allowed baud rate range for the divisor based encoding method" Revert "usb: pl2303: move the two baud rate encoding methods to separate functions" Revert "usb: pl2303: remove 50 baud from the list of standard baud rates" Revert "usb: pl2303: do not round to the next nearest standard baud rate for the divisor based baud rate encoding method" Revert "usb: pl2303: fix+improve the divsor based baud rate encoding method" Revert "USB: pl2303: restrict the divisor based baud rate encoding method to the "HX" chip type" Алексей Крамаренко (1): USB: serial: ftdi_sio: add id for Z3X Box device MAINTAINERS | 53 +--- drivers/usb/serial/ftdi_sio.c | 1 + drivers/usb/serial/ftdi_sio_ids.h | 6 + drivers/usb/serial/pl2303.c | 274 -- 4 files changed, 66 insertions(+), 268 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] clk: exynos5410: register clocks using common clock framework
Hi,
On Monday 14 of October 2013 19:08:23 Vyacheslav Tyrtov wrote:
> From: Tarek Dakhran
>
> The EXYNOS5410 clocks are statically listed and registered
> using the Samsung specific common clock helper functions.
>
> Signed-off-by: Tarek Dakhran
> Signed-off-by: Vyacheslav Tyrtov
> ---
> .../devicetree/bindings/clock/exynos5410-clock.txt | 37 +++
> drivers/clk/samsung/Makefile | 1 +
> drivers/clk/samsung/clk-exynos5410.c | 251
> + include/dt-bindings/clock/exynos5410.h
> | 175 ++ 4 files changed, 464 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/clock/exynos5410-clock.txt create
> mode 100644 drivers/clk/samsung/clk-exynos5410.c
> create mode 100644 include/dt-bindings/clock/exynos5410.h
The driver looks pretty good now, thanks for addressing my comments to
previous version. There are still few issues remaining, though. Please see
my comments inline.
[snip]
> diff --git a/drivers/clk/samsung/clk-exynos5410.c
> b/drivers/clk/samsung/clk-exynos5410.c new file mode 100644
> index 000..c5eba08
> --- /dev/null
> +++ b/drivers/clk/samsung/clk-exynos5410.c
[snip]
> +static struct of_device_id ext_clk_match[] __initdata = {
> + { .compatible = "samsung,clock-oscclk", .data = (void *)0, },
> + { },
> +};
I don't see anything in binding documentation mentioning this compatible
value. Anyway, since there is already a generic binding for fixed rate
clocks, this shouldn't be needed at all.
> +
> +/* register exynos5410 clocks */
> +static void __init exynos5410_clk_init(struct device_node *np)
> +{
> + void __iomem *reg_base;
> +
> + reg_base = of_iomap(np, 0);
> + if (!reg_base)
> + panic("%s: failed to map registers\n", __func__);
> +
> + samsung_clk_init(np, reg_base, CLK_NR_CLKS,
> + exynos5410_clk_regs,
ARRAY_SIZE(exynos5410_clk_regs),
> + NULL, 0);
> + samsung_clk_of_register_fixed_ext(exynos5410_frt_ext_clks,
> + ARRAY_SIZE(exynos5410_frt_ext_clks),
> + ext_clk_match);
This call could be dropped after moving to generic fixed rate clock
bindings.
Best regards,
Tomasz
--
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] ceph: Write through cache support based on fscache
Li,
I think it would be fantastic to see a write cache. In many workloads
you ended up writing out a file and then turning around and reading it
right back in on the same node.
There's a few things that I would like to see. First, an mount option
to turn on/off write through caching. There are some workloads / user
hardware configurations that will not benefit from this (it might be a
net negative). Also, I think it's nice to have a fallback to disable
it it's miss behaving.
Second, for correctness I think you should only do write-through
caching if you have an exclusive cap on the file. Currently as the
code is written it only reads from fscache if the file is open in read
only mode and has the cache cap. This would also have to change.
Thanks,
- Milosz
P.S: Sorry for the second message Li, I fail at email and forgot to reply-all.
On Fri, Nov 1, 2013 at 9:49 AM, Li Wang wrote:
> Currently, fscache only plays as read cache for ceph, this patch
> enables it plays as the write through cache as well.
>
> A small trick to be discussed: if the writing to OSD finishes before
> the writing to fscache, the fscache writing is cancelled to avoid
> slow down the writepages() process.
>
> Signed-off-by: Min Chen
> Signed-off-by: Li Wang
> Signed-off-by: Yunchuan Wen
> ---
> fs/ceph/addr.c | 10 +++---
> fs/ceph/cache.c | 29 +
> fs/ceph/cache.h | 13 +
> 3 files changed, 49 insertions(+), 3 deletions(-)
>
> diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c
> index 6df8bd4..2465c49 100644
> --- a/fs/ceph/addr.c
> +++ b/fs/ceph/addr.c
> @@ -506,7 +506,7 @@ static int writepage_nounlock(struct page *page, struct
> writeback_control *wbc)
> CONGESTION_ON_THRESH(fsc->mount_options->congestion_kb))
> set_bdi_congested(>backing_dev_info, BLK_RW_ASYNC);
>
> - ceph_readpage_to_fscache(inode, page);
> + ceph_writepage_to_fscache(inode, page);
>
> set_page_writeback(page);
> err = ceph_osdc_writepages(osdc, ceph_vino(inode),
> @@ -634,6 +634,7 @@ static void writepages_finish(struct ceph_osd_request
> *req,
> if ((issued & (CEPH_CAP_FILE_CACHE|CEPH_CAP_FILE_LAZYIO)) ==
> 0)
> generic_error_remove_page(inode->i_mapping, page);
>
> + ceph_maybe_release_fscache_page(inode, page);
> unlock_page(page);
> }
> dout("%p wrote+cleaned %d pages\n", inode, wrote);
> @@ -746,7 +747,7 @@ retry:
>
> while (!done && index <= end) {
> int num_ops = do_sync ? 2 : 1;
> - unsigned i;
> + unsigned i, j;
> int first;
> pgoff_t next;
> int pvec_pages, locked_pages;
> @@ -894,7 +895,6 @@ get_more_pages:
> if (!locked_pages)
> goto release_pvec_pages;
> if (i) {
> - int j;
> BUG_ON(!locked_pages || first < 0);
>
> if (pvec_pages && i == pvec_pages &&
> @@ -924,6 +924,10 @@ get_more_pages:
>
> osd_req_op_extent_osd_data_pages(req, 0, pages, len, 0,
> !!pool, false);
> + for (j = 0; j < locked_pages; j++) {
> + struct page *page = pages[j];
> + ceph_writepage_to_fscache(inode, page);
> + }
>
> pages = NULL; /* request message now owns the pages array */
> pool = NULL;
> diff --git a/fs/ceph/cache.c b/fs/ceph/cache.c
> index 6bfe65e..6f928c4 100644
> --- a/fs/ceph/cache.c
> +++ b/fs/ceph/cache.c
> @@ -320,6 +320,24 @@ void ceph_readpage_to_fscache(struct inode *inode,
> struct page *page)
> fscache_uncache_page(ci->fscache, page);
> }
>
> +void ceph_writepage_to_fscache(struct inode *inode, struct page *page)
> +{
> + struct ceph_inode_info *ci = ceph_inode(inode);
> + int ret;
> +
> + if (!cache_valid(ci))
> + return;
> +
> + if (!PageFsCache(page)) {
> + if (fscache_alloc_page(ci->fscache, page, GFP_KERNEL))
> + return;
> + }
> +
> + if (fscache_write_page(ci->fscache, page, GFP_KERNEL))
> + fscache_uncache_page(ci->fscache, page);
> +}
> +
> +
> void ceph_invalidate_fscache_page(struct inode* inode, struct page *page)
> {
> struct ceph_inode_info *ci = ceph_inode(inode);
> @@ -328,6 +346,17 @@ void ceph_invalidate_fscache_page(struct inode* inode,
> struct page *page)
> fscache_uncache_page(ci->fscache, page);
> }
>
> +void ceph_maybe_release_fscache_page(struct inode *inode, struct page *page)
> +{
> + struct ceph_inode_info *ci = ceph_inode(inode);
> +
> + if (PageFsCache(page)) {
> + if (!fscache_check_page_write(ci->fscache, page))
> +
Re: [PATCH 2/2] virtio_blk: blk-mq support
Updated version to address Asias' comments and rebased ontop of
block/for-next with the immutable bio changes:
---
From: Jens Axboe
Subject: virtio_blk: blk-mq support
Switch virtio-blk from the dual support for old-style requests and bios
to use the block-multiqueue.
Acked-by: Asias He
Signed-off-by: Jens Axboe
Signed-off-by: Christoph Hellwig
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 93fde08..7455fe2 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -11,12 +11,11 @@
#include
#include
#include
+#include
+#include
#define PART_BITS 4
-static bool use_bio;
-module_param(use_bio, bool, S_IRUGO);
-
static int major;
static DEFINE_IDA(vd_index_ida);
@@ -26,13 +25,11 @@ struct virtio_blk
{
struct virtio_device *vdev;
struct virtqueue *vq;
- wait_queue_head_t queue_wait;
+ spinlock_t vq_lock;
/* The disk structure for the kernel. */
struct gendisk *disk;
- mempool_t *pool;
-
/* Process context for config space updates */
struct work_struct config_work;
@@ -47,31 +44,17 @@ struct virtio_blk
/* Ida index - used to track minor number allocations. */
int index;
-
- /* Scatterlist: can be too big for stack. */
- struct scatterlist sg[/*sg_elems*/];
};
struct virtblk_req
{
struct request *req;
- struct bio *bio;
struct virtio_blk_outhdr out_hdr;
struct virtio_scsi_inhdr in_hdr;
- struct work_struct work;
- struct virtio_blk *vblk;
- int flags;
u8 status;
struct scatterlist sg[];
};
-enum {
- VBLK_IS_FLUSH = 1,
- VBLK_REQ_FLUSH = 2,
- VBLK_REQ_DATA = 4,
- VBLK_REQ_FUA= 8,
-};
-
static inline int virtblk_result(struct virtblk_req *vbr)
{
switch (vbr->status) {
@@ -84,22 +67,6 @@ static inline int virtblk_result(struct virtblk_req *vbr)
}
}
-static inline struct virtblk_req *virtblk_alloc_req(struct virtio_blk *vblk,
- gfp_t gfp_mask)
-{
- struct virtblk_req *vbr;
-
- vbr = mempool_alloc(vblk->pool, gfp_mask);
- if (!vbr)
- return NULL;
-
- vbr->vblk = vblk;
- if (use_bio)
- sg_init_table(vbr->sg, vblk->sg_elems);
-
- return vbr;
-}
-
static int __virtblk_add_req(struct virtqueue *vq,
struct virtblk_req *vbr,
struct scatterlist *data_sg,
@@ -143,83 +110,8 @@ static int __virtblk_add_req(struct virtqueue *vq,
return virtqueue_add_sgs(vq, sgs, num_out, num_in, vbr, GFP_ATOMIC);
}
-static void virtblk_add_req(struct virtblk_req *vbr, bool have_data)
-{
- struct virtio_blk *vblk = vbr->vblk;
- DEFINE_WAIT(wait);
- int ret;
-
- spin_lock_irq(vblk->disk->queue->queue_lock);
- while (unlikely((ret = __virtblk_add_req(vblk->vq, vbr, vbr->sg,
-have_data)) < 0)) {
- prepare_to_wait_exclusive(>queue_wait, ,
- TASK_UNINTERRUPTIBLE);
-
- spin_unlock_irq(vblk->disk->queue->queue_lock);
- io_schedule();
- spin_lock_irq(vblk->disk->queue->queue_lock);
-
- finish_wait(>queue_wait, );
- }
-
- virtqueue_kick(vblk->vq);
- spin_unlock_irq(vblk->disk->queue->queue_lock);
-}
-
-static void virtblk_bio_send_flush(struct virtblk_req *vbr)
-{
- vbr->flags |= VBLK_IS_FLUSH;
- vbr->out_hdr.type = VIRTIO_BLK_T_FLUSH;
- vbr->out_hdr.sector = 0;
- vbr->out_hdr.ioprio = 0;
-
- virtblk_add_req(vbr, false);
-}
-
-static void virtblk_bio_send_data(struct virtblk_req *vbr)
-{
- struct virtio_blk *vblk = vbr->vblk;
- struct bio *bio = vbr->bio;
- bool have_data;
-
- vbr->flags &= ~VBLK_IS_FLUSH;
- vbr->out_hdr.type = 0;
- vbr->out_hdr.sector = bio->bi_iter.bi_sector;
- vbr->out_hdr.ioprio = bio_prio(bio);
-
- if (blk_bio_map_sg(vblk->disk->queue, bio, vbr->sg)) {
- have_data = true;
- if (bio->bi_rw & REQ_WRITE)
- vbr->out_hdr.type |= VIRTIO_BLK_T_OUT;
- else
- vbr->out_hdr.type |= VIRTIO_BLK_T_IN;
- } else
- have_data = false;
-
- virtblk_add_req(vbr, have_data);
-}
-
-static void virtblk_bio_send_data_work(struct work_struct *work)
-{
- struct virtblk_req *vbr;
-
- vbr = container_of(work, struct virtblk_req, work);
-
- virtblk_bio_send_data(vbr);
-}
-
-static void virtblk_bio_send_flush_work(struct work_struct *work)
-{
- struct virtblk_req *vbr;
-
- vbr = container_of(work, struct virtblk_req, work);
-
- virtblk_bio_send_flush(vbr);
-}
-
static inline void virtblk_request_done(struct virtblk_req
Re: [PATCH v7 0/5] clk: clock deregistration support
Hi Jonas, On 11/01/2013 02:56 PM, Jonas Jensen wrote: Hi, Just letting you know, the following warning from __clk_get is now printed, and not printed after revert (git revert 0b35b92fb3600a2f9ca114a6142db95f760d55f5). It is recommended to quote also human readable patch summary line, so it's more immediately clear which patch you refer to. Is the driver doing something it shouldn't be doing? I don't think so. That is a known issue, it shouldn't be happening when you apply $subject patch series onto todays -next. If it does please let me know. Is the warning still triggered when you apply this patch: http://www.spinics.net/lists/arm-kernel/msg283550.html onto next-20131031 instead of reverting ? moxart_of_pll_clk_init() source can be found here: http://www.spinics.net/lists/arm-kernel/msg278572.html The driver seems OK from a brief look. Thanks for the feedback. boot log: Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.12.0-rc7-next-20131031+ (i@Ildjarn) [0.00] [ cut here ] [0.00] WARNING: CPU: 0 PID: 0 at include/linux/kref.h:47 __clk_get+0x54/0x68() [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 3.12.0-rc7-next-20131031+ #1043 [0.00] [] (unwind_backtrace+0x0/0xf4) from [] (show_stack+0x18/0x1c) [0.00] [] (show_stack+0x18/0x1c) from [] (dump_stack+0x20/0x28) [0.00] [] (dump_stack+0x20/0x28) from [] (warn_slowpath_common+0x64/0x84) [0.00] [] (warn_slowpath_common+0x64/0x84) from [] (warn_slowpath_null+0x24/0x2c) [0.00] [] (warn_slowpath_null+0x24/0x2c) from [] (__clk_get+0x54/0x68) [0.00] [] (__clk_get+0x54/0x68) from [] (of_clk_get+0x64/0x7c) [0.00] [] (of_clk_get+0x64/0x7c) from [] (moxart_of_pll_clk_init+0xd8/0x15c) [0.00] [] (moxart_of_pll_clk_init+0xd8/0x15c) from [] (of_clk_init+0x48/0x70) [0.00] [] (of_clk_init+0x48/0x70) from [] (moxart_init_time+0x14/0x1c) [0.00] [] (moxart_init_time+0x14/0x1c) from [] (time_init+0x28/0x3c) [0.00] [] (time_init+0x28/0x3c) from [] (start_kernel+0x1d0/0x2dc) [0.00] [] (start_kernel+0x1d0/0x2dc) from [<8040>] (0x8040) [0.00] ---[ end trace 3406ff24bd97382e ]--- Regards, Sylwester -- 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/7] perf timechart: add option to limit number of tasks
Add -n option to specify min. number of tasks to print.
Signed-off-by: Stanislav Fomichev
---
tools/perf/Documentation/perf-timechart.txt | 4
tools/perf/builtin-timechart.c | 5 -
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Documentation/perf-timechart.txt
b/tools/perf/Documentation/perf-timechart.txt
index 1632b0efc757..919cbe9ce428 100644
--- a/tools/perf/Documentation/perf-timechart.txt
+++ b/tools/perf/Documentation/perf-timechart.txt
@@ -41,6 +41,10 @@ OPTIONS
--symfs=::
Look for files with symbols relative to this directory.
+-n::
+--proc-num::
+Print task info for at least given number of tasks.
+
SEE ALSO
linkperf:perf-record[1]
diff --git a/tools/perf/builtin-timechart.c b/tools/perf/builtin-timechart.c
index c68ed44c2319..51a5532b3382 100644
--- a/tools/perf/builtin-timechart.c
+++ b/tools/perf/builtin-timechart.c
@@ -40,6 +40,7 @@
#define SUPPORT_OLD_POWER_EVENTS 1
#define PWR_EVENT_EXIT -1
+static int proc_num = 15;
static unsigned intnumcpus;
static u64 min_freq; /* Lowest CPU frequency seen */
@@ -954,7 +955,7 @@ static void write_svg_file(const char *filename)
do {
count = determine_display_tasks(thresh);
thresh /= 10;
- } while (!process_filter && thresh && count < 15);
+ } while (!process_filter && thresh && count < proc_num);
open_svg(filename, numcpus, count, first_time, last_time);
@@ -1096,6 +1097,8 @@ int cmd_timechart(int argc, const char **argv,
parse_process),
OPT_STRING(0, "symfs", _conf.symfs, "directory",
"Look for files with symbols relative to this directory"),
+ OPT_INTEGER('n', "proc-num", _num,
+ "min. number of tasks to print"),
OPT_END()
};
const char * const timechart_usage[] = {
--
1.8.3.2
--
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 5/7] perf timechart: group figures and add title with details
Add titles to figures so we can run SVG interactively in Firefox
and check event details in the tooltips.
This also aids exploring SVG with Inkscape because when user clicks on
one part of logical figure, all parts are selected.
It's also possible to read titles with Inkscape in the object details.
Signed-off-by: Stanislav Fomichev
---
tools/perf/builtin-timechart.c | 6 ++---
tools/perf/util/svghelper.c| 56 --
tools/perf/util/svghelper.h| 5 ++--
3 files changed, 60 insertions(+), 7 deletions(-)
diff --git a/tools/perf/builtin-timechart.c b/tools/perf/builtin-timechart.c
index 7819006387f0..cab1d0fd3fc0 100644
--- a/tools/perf/builtin-timechart.c
+++ b/tools/perf/builtin-timechart.c
@@ -797,11 +797,11 @@ static void draw_process_bars(void)
sample = c->samples;
while (sample) {
if (sample->type == TYPE_RUNNING)
- svg_sample(Y, sample->cpu,
sample->start_time, sample->end_time);
+ svg_running(Y, sample->cpu,
sample->start_time, sample->end_time);
if (sample->type == TYPE_BLOCKED)
- svg_box(Y, sample->start_time,
sample->end_time, "blocked");
+ svg_blocked(Y, sample->cpu,
sample->start_time, sample->end_time);
if (sample->type == TYPE_WAITING)
- svg_waiting(Y, sample->start_time,
sample->end_time);
+ svg_waiting(Y, sample->cpu,
sample->start_time, sample->end_time);
sample = sample->next;
}
diff --git a/tools/perf/util/svghelper.c b/tools/perf/util/svghelper.c
index 96c866045d60..9a5b41392e01 100644
--- a/tools/perf/util/svghelper.c
+++ b/tools/perf/util/svghelper.c
@@ -95,6 +95,7 @@ void open_svg(const char *filename, int cpus, int rows, u64
start, u64 end)
total_height = (1 + rows + cpu2slot(cpus)) * SLOT_MULT;
fprintf(svgfile, " \n");
+ fprintf(svgfile, "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd\;>\n");
fprintf(svgfile, "http://www.w3.org/2000/svg\;>\n", svg_page_width,
total_height);
fprintf(svgfile, "\n
[PATCH 1/7] perf timechart: always try to print at least 15 tasks
Always try to print at least 15 tasks no matter how long they run.
Signed-off-by: Stanislav Fomichev
---
tools/perf/builtin-timechart.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/tools/perf/builtin-timechart.c b/tools/perf/builtin-timechart.c
index c2e02319347a..c68ed44c2319 100644
--- a/tools/perf/builtin-timechart.c
+++ b/tools/perf/builtin-timechart.c
@@ -944,15 +944,17 @@ static void write_svg_file(const char *filename)
{
u64 i;
int count;
+ int thresh = TIME_THRESH;
numcpus++;
- count = determine_display_tasks(TIME_THRESH);
-
- /* We'd like to show at least 15 tasks; be less picky if we have fewer
*/
- if (count < 15)
- count = determine_display_tasks(TIME_THRESH / 10);
+ /* We'd like to show at least proc_num tasks;
+* be less picky if we have fewer */
+ do {
+ count = determine_display_tasks(thresh);
+ thresh /= 10;
+ } while (!process_filter && thresh && count < 15);
open_svg(filename, numcpus, count, first_time, last_time);
--
1.8.3.2
--
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 4/7] perf timechart: add support for displaying only tasks related data
In order to make SVG smaller and faster to browse add possibility to
switch off power related information with -T switch.
Signed-off-by: Stanislav Fomichev
---
tools/perf/Documentation/perf-timechart.txt | 3 +++
tools/perf/builtin-timechart.c | 11 ++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Documentation/perf-timechart.txt
b/tools/perf/Documentation/perf-timechart.txt
index 919cbe9ce428..a79d473394f6 100644
--- a/tools/perf/Documentation/perf-timechart.txt
+++ b/tools/perf/Documentation/perf-timechart.txt
@@ -34,6 +34,9 @@ OPTIONS
-P::
--power-only::
Only output the CPU power section of the diagram
+-T::
+--tasks-only::
+Don't output processor state transitions
-p::
--process::
Select the processes to display, by name or PID
diff --git a/tools/perf/builtin-timechart.c b/tools/perf/builtin-timechart.c
index 74c040abb3af..7819006387f0 100644
--- a/tools/perf/builtin-timechart.c
+++ b/tools/perf/builtin-timechart.c
@@ -50,6 +50,7 @@ static u64turbo_frequency;
static u64 first_time, last_time;
static boolpower_only;
+static booltasks_only;
struct per_pid;
@@ -970,7 +971,8 @@ static void write_svg_file(const char *filename)
draw_cpu_usage();
if (proc_num)
draw_process_bars();
- draw_c_p_states();
+ if (!tasks_only)
+ draw_c_p_states();
if (proc_num)
draw_wakeups();
@@ -1096,6 +1098,8 @@ int cmd_timechart(int argc, const char **argv,
OPT_STRING('o', "output", _name, "file", "output file name"),
OPT_INTEGER('w', "width", _page_width, "page width"),
OPT_BOOLEAN('P', "power-only", _only, "output power data only"),
+ OPT_BOOLEAN('T', "tasks-only", _only,
+ "output processes data only"),
OPT_CALLBACK('p', "process", NULL, "process",
"process selector. Pass a pid or process name.",
parse_process),
@@ -1113,6 +1117,11 @@ int cmd_timechart(int argc, const char **argv,
argc = parse_options(argc, argv, options, timechart_usage,
PARSE_OPT_STOP_AT_NON_OPTION);
+ if (power_only && tasks_only) {
+ pr_err("-P and -T options cannot be used at the same time.\n");
+ return -1;
+ }
+
symbol__init();
if (argc && !strncmp(argv[0], "rec", 3))
--
1.8.3.2
--
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: stec skd block driver needs updating for immutable biovec
On 11/01/2013 10:28 AM, Mike Snitzer wrote: > On Fri, Nov 01 2013 at 12:02pm -0400, > Jens Axboe wrote: > >> On 11/01/2013 09:50 AM, Christoph Hellwig wrote: >>> On Fri, Nov 01, 2013 at 11:43:39AM -0400, Mike Snitzer wrote: All the bi_sector ones are low hanging fruit, but the conversion for skd_preop_sg_list_bio()'s bio_vec code is more involved. Kent, any chance you could crank through it? If not I can come back to trying to fix this later.. but I'm working through a test merge of linux-dm.git's 'for-next' with linux-block.git's 'for-next'. >>> >>> The right thing for 3.13 is to rip out the bio base code path, and >>> for 3.14 to convert it to blk-mq. >> >> It is. I will kill it. > > I just cranked through it.. hope this helps (think I got everything but > may have missed something): You lost out, I committed it 20 min ago :-0 http://git.kernel.dk/?p=linux-block.git;a=commit;h=1d36f7a5fb577afaaead6c5e2fc8e01e0c95235d Looks like you missed some of the skd_device removal, while I neglected killing bio/start_time in the skd_request_context. -- Jens Axboe -- 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 7/7] perf timechart: add backtrace support
Add -g flag to `perf timechart record` which saves callchain info in
the perf.data.
When generating SVG, add backtrace information to the figure details,
so now it's possible to see which code path woke up the task and why some
task went to sleep.
Signed-off-by: Stanislav Fomichev
---
tools/perf/Documentation/perf-timechart.txt | 3 +
tools/perf/builtin-timechart.c | 170
tools/perf/util/svghelper.c | 27 -
tools/perf/util/svghelper.h | 12 +-
4 files changed, 176 insertions(+), 36 deletions(-)
diff --git a/tools/perf/Documentation/perf-timechart.txt
b/tools/perf/Documentation/perf-timechart.txt
index abfaff2707da..bd566cb9f426 100644
--- a/tools/perf/Documentation/perf-timechart.txt
+++ b/tools/perf/Documentation/perf-timechart.txt
@@ -56,6 +56,9 @@ RECORD OPTIONS
-T::
--tasks-only::
Record only tasks-related events
+-g::
+--callchain::
+Do call-graph (stack chain/backtrace) recording
SEE ALSO
diff --git a/tools/perf/builtin-timechart.c b/tools/perf/builtin-timechart.c
index b5b2726d6e32..4836c6e1b560 100644
--- a/tools/perf/builtin-timechart.c
+++ b/tools/perf/builtin-timechart.c
@@ -51,6 +51,7 @@ static u64first_time, last_time;
static boolpower_only;
static booltasks_only;
+static boolwith_backtrace;
struct per_pid;
@@ -125,6 +126,7 @@ struct cpu_sample {
u64 end_time;
int type;
int cpu;
+ const char *backtrace;
};
static struct per_pid *all_data;
@@ -146,6 +148,7 @@ struct wake_event {
int waker;
int wakee;
u64 time;
+ const char *backtrace;
};
static struct power_event*power_events;
@@ -230,7 +233,8 @@ static void pid_exit(int pid, u64 timestamp)
}
static void
-pid_put_sample(int pid, int type, unsigned int cpu, u64 start, u64 end)
+pid_put_sample(int pid, int type, unsigned int cpu, u64 start, u64 end,
+ const char *backtrace)
{
struct per_pid *p;
struct per_pidcomm *c;
@@ -253,6 +257,7 @@ pid_put_sample(int pid, int type, unsigned int cpu, u64
start, u64 end)
sample->type = type;
sample->next = c->samples;
sample->cpu = cpu;
+ sample->backtrace = backtrace;
c->samples = sample;
if (sample->type == TYPE_RUNNING && end > start && start > 0) {
@@ -404,7 +409,8 @@ static void p_state_change(int cpu, u64 timestamp, u64
new_freq)
}
static void
-sched_wakeup(int cpu, u64 timestamp, int pid, struct trace_entry *te)
+sched_wakeup(int cpu, u64 timestamp, int pid, struct trace_entry *te,
+const char *backtrace)
{
struct per_pid *p;
struct wakeup_entry *wake = (void *)te;
@@ -415,6 +421,7 @@ sched_wakeup(int cpu, u64 timestamp, int pid, struct
trace_entry *te)
we->time = timestamp;
we->waker = pid;
+ we->backtrace = backtrace;
if ((te->flags & TRACE_FLAG_HARDIRQ) || (te->flags &
TRACE_FLAG_SOFTIRQ))
we->waker = -1;
@@ -429,13 +436,15 @@ sched_wakeup(int cpu, u64 timestamp, int pid, struct
trace_entry *te)
p->current->state = TYPE_WAITING;
}
if (p && p->current && p->current->state == TYPE_BLOCKED) {
- pid_put_sample(p->pid, p->current->state, cpu,
p->current->state_since, timestamp);
+ pid_put_sample(p->pid, p->current->state, cpu,
+ p->current->state_since, timestamp, NULL);
p->current->state_since = timestamp;
p->current->state = TYPE_WAITING;
}
}
-static void sched_switch(int cpu, u64 timestamp, struct trace_entry *te)
+static void sched_switch(int cpu, u64 timestamp, struct trace_entry *te,
+const char *backtrace)
{
struct per_pid *p = NULL, *prev_p;
struct sched_switch *sw = (void *)te;
@@ -446,10 +455,14 @@ static void sched_switch(int cpu, u64 timestamp, struct
trace_entry *te)
p = find_create_pid(sw->next_pid);
if (prev_p->current && prev_p->current->state != TYPE_NONE)
- pid_put_sample(sw->prev_pid, TYPE_RUNNING, cpu,
prev_p->current->state_since, timestamp);
+ pid_put_sample(sw->prev_pid, TYPE_RUNNING, cpu,
+ prev_p->current->state_since, timestamp,
+ backtrace);
if (p && p->current) {
if (p->current->state != TYPE_NONE)
- pid_put_sample(sw->next_pid, p->current->state, cpu,
p->current->state_since, timestamp);
+ pid_put_sample(sw->next_pid, p->current->state, cpu,
+ p->current->state_since, timestamp,
+ backtrace);
p->current->state_since = timestamp;
p->current->state = TYPE_RUNNING;
@@ -465,8 +478,87 @@ static void sched_switch(int cpu,
[PATCH v3 4/6] edac: Document Krait L1/L2 EDAC driver binding
The Krait L1/L2 error reporting device is made up of two
interrupts, one per-CPU interrupt for the L1 caches and one
interrupt for the L2 cache.
Cc: Mark Rutland
Acked-by: Kumar Gala
Cc:
Signed-off-by: Stephen Boyd
---
Documentation/devicetree/bindings/arm/cpus.txt | 49 ++
1 file changed, 49 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
b/Documentation/devicetree/bindings/arm/cpus.txt
index f32494d..c30d547 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -44,6 +44,8 @@ For the ARM architecture every CPU node must contain the
following properties:
"marvell,mohawk"
"marvell,xsc3"
"marvell,xscale"
+ "qcom,scorpion"
+ "qcom,krait"
Example:
@@ -75,3 +77,50 @@ Example:
reg = <0x101>;
};
};
+
+If the compatible string contains "qcom,krait" there shall be an interrupts
+property containing the L1/CPU error interrupt number. There shall also be a
+l2-cache node containing the following properties:
+
+ - compatible: Shall contain at least "cache"
+ - cache-level: Must be 2
+ - interrupts: Shall contain the L2 error interrupt
+
+Example:
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <1 9 0xf04>;
+ compatible = "qcom,krait";
+
+ cpu@0 {
+ device_type = "cpu";
+ reg = <0>;
+ next-level-cache = <>;
+ };
+
+ cpu@1 {
+ device_type = "cpu";
+ reg = <1>;
+ next-level-cache = <>;
+ };
+
+ cpu@2 {
+ device_type = "cpu";
+ reg = <2>;
+ next-level-cache = <>;
+ };
+
+ cpu@3 {
+ device_type = "cpu";
+ reg = <3>;
+ next-level-cache = <>;
+ };
+
+ L2: l2-cache {
+ compatible = "cache";
+ cache-level = <2>;
+ interrupts = <0 2 0x4>;
+ };
+ };
--
The Qualcomm Innovation Center, Inc. is a member of the 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/
[PATCH v3 5/6] edac: Add support for Krait CPU cache error detection
Add support for the Krait CPU cache error detection. This is a
simplified version of the code originally written by Stepan
Moskovchenko[1] ported to the EDAC device framework.
[1]
https://www.codeaurora.org/cgit/quic/la/kernel/msm/tree/arch/arm/mach-msm/cache_erp.c?h=msm-3.4
Cc: Stepan Moskovchenko
Signed-off-by: Stephen Boyd
---
drivers/edac/Kconfig | 8 ++
drivers/edac/Makefile | 2 +
drivers/edac/krait_edac.c | 346 ++
3 files changed, 356 insertions(+)
create mode 100644 drivers/edac/krait_edac.c
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 878f090..68f612d 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -368,4 +368,12 @@ config EDAC_OCTEON_PCI
Support for error detection and correction on the
Cavium Octeon family of SOCs.
+config EDAC_KRAIT_CACHE
+ tristate "Krait L1/L2 Cache"
+ depends on EDAC_MM_EDAC && ARCH_MSM
+ select KRAIT_L2_ACCESSORS
+ help
+ Support for error detection and correction on the
+ Krait L1/L2 cache controller.
+
endif # EDAC
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index 4154ed6..b6ea505 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -64,3 +64,5 @@ obj-$(CONFIG_EDAC_OCTEON_PC) += octeon_edac-pc.o
obj-$(CONFIG_EDAC_OCTEON_L2C) += octeon_edac-l2c.o
obj-$(CONFIG_EDAC_OCTEON_LMC) += octeon_edac-lmc.o
obj-$(CONFIG_EDAC_OCTEON_PCI) += octeon_edac-pci.o
+
+obj-$(CONFIG_EDAC_KRAIT_CACHE) += krait_edac.o
diff --git a/drivers/edac/krait_edac.c b/drivers/edac/krait_edac.c
new file mode 100644
index 000..b1d9f52
--- /dev/null
+++ b/drivers/edac/krait_edac.c
@@ -0,0 +1,346 @@
+/* Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "edac_core.h"
+
+#define CESR_DCTPE BIT(0)
+#define CESR_DCDPE BIT(1)
+#define CESR_ICTPE BIT(2)
+#define CESR_ICDPE BIT(3)
+#define CESR_DCTE (BIT(4) | BIT(5))
+#define CESR_ICTE (BIT(6) | BIT(7))
+#define CESR_TLBMH BIT(16)
+#define CESR_I_MASK0x00cc
+/* Print a message for everything but TLB MH events */
+#define CESR_PRINT_MASK0x00ff
+
+#define L2ESR 0x204
+#define L2ESR_MPDCDBIT(0)
+#define L2ESR_MPSLVBIT(1)
+#define L2ESR_TSESBBIT(2)
+#define L2ESR_TSEDBBIT(3)
+#define L2ESR_DSESBBIT(4)
+#define L2ESR_DSEDBBIT(5)
+#define L2ESR_MSE BIT(6)
+#define L2ESR_MPLDREXNOK BIT(8)
+#define L2ESR_CPU_MASK 0xf
+#define L2ESR_CPU_SHIFT16
+#define L2ESR_SP BIT(20)
+
+#define L2ESYNR0 0x208
+#define L2ESYNR1 0x209
+#define L2EAR0 0x20c
+#define L2EAR1 0x20d
+
+struct krait_edac {
+ int l1_irq;
+ struct edac_device_ctl_info * __percpu *edev;
+ struct notifier_block notifier;
+};
+
+struct krait_edac_error {
+ const char * const msg;
+ void (*func)(struct edac_device_ctl_info *edac_dev,
+ int inst_nr, int block_nr, const char *msg);
+};
+
+static unsigned int read_cesr(void)
+{
+ unsigned int cesr;
+
+ asm volatile ("mrc p15, 7, %0, c15, c0, 1 @ cesr" : "=r" (cesr));
+ return cesr;
+}
+
+static void write_cesr(unsigned int cesr)
+{
+ asm volatile ("mcr p15, 7, %0, c15, c0, 1 @ cesr" : : "r" (cesr));
+}
+
+static unsigned int read_cesynr(void)
+{
+ unsigned int cesynr;
+
+ asm volatile ("mrc p15, 7, %0, c15, c0, 3 @ cesynr" : "=r" (cesynr));
+ return cesynr;
+}
+
+static irqreturn_t krait_l1_irq(int irq, void *dev_id)
+{
+ struct edac_device_ctl_info *edac = dev_id;
+ unsigned int cesr = read_cesr();
+ unsigned int i_cesynr, d_cesynr;
+ unsigned int cpu = smp_processor_id();
+ int print_regs = cesr & CESR_PRINT_MASK;
+ int i;
+ static const struct krait_edac_error errors[] = {
+ { "D-cache tag parity error", edac_device_handle_ue },
+ { "D-cache data parity error", edac_device_handle_ue },
+ { "I-cache tag parity error", edac_device_handle_ce },
+ { "I-cache data parity error", edac_device_handle_ce },
+ {
[PATCH v3 6/6] ARM: dts: msm: Add Krait CPU/L2 nodes
This allows us to probe the krait-edac driver.
Acked-by: David Brown
Signed-off-by: Stephen Boyd
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 37 +
1 file changed, 37 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 152879d..bfe8b9c 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -9,6 +9,43 @@
compatible = "qcom,msm8974";
interrupt-parent = <>;
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <1 9 0xf04>;
+ compatible = "qcom,krait";
+
+ cpu@0 {
+ device_type = "cpu";
+ reg = <0>;
+ next-level-cache = <>;
+ };
+
+ cpu@1 {
+ device_type = "cpu";
+ reg = <1>;
+ next-level-cache = <>;
+ };
+
+ cpu@2 {
+ device_type = "cpu";
+ reg = <2>;
+ next-level-cache = <>;
+ };
+
+ cpu@3 {
+ device_type = "cpu";
+ reg = <3>;
+ next-level-cache = <>;
+ };
+
+ L2: l2-cache {
+ compatible = "cache";
+ cache-level = <2>;
+ interrupts = <0 2 0x4>;
+ };
+ };
+
soc: soc {
#address-cells = <1>;
#size-cells = <1>;
--
The Qualcomm Innovation Center, Inc. is a member of the 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/
[PATCH v3 0/6] Krait L1/L2 EDAC driver
This patchset adds support for the Krait L1/L2 cache error detection hardware. The first patch fixes a generic framework bug. The next two patches lay the groundwork for this driver to be added by exporting percpu irq functions as well as adding the Krait l2 indirection register code. The next two patches add the driver and the binding and the final patch hooks it all up by adding the device tree node. I'm not sure which tree this is supposed to go through. Ideally we could send the first 3 plus the 5th one through an edac tree. The final dts changes could go through arm-soc via davidb's tree and the Documentation patch could go through the devicetree tree. Changes since v2: * Picked up acks * s/an/a/ in DT binding Changes since v1: * Moved binding into cpus node * Picked up acks on first two patches * Commented krait l2 accessor functions Stephen Boyd (6): edac: Don't try to cancel workqueue when it's never setup genirq: export percpu irq functions for module usage ARM: Add Krait L2 accessor functions edac: Document Krait L1/L2 EDAC driver binding edac: Add support for Krait CPU cache error detection ARM: dts: msm: Add Krait CPU/L2 nodes Documentation/devicetree/bindings/arm/cpus.txt | 49 arch/arm/boot/dts/qcom-msm8974.dtsi| 37 +++ arch/arm/common/Kconfig| 3 + arch/arm/common/Makefile | 1 + arch/arm/common/krait-l2-accessors.c | 58 + arch/arm/include/asm/krait-l2-accessors.h | 20 ++ drivers/edac/Kconfig | 8 + drivers/edac/Makefile | 2 + drivers/edac/edac_device.c | 3 + drivers/edac/krait_edac.c | 346 + kernel/irq/manage.c| 2 + 11 files changed, 529 insertions(+) create mode 100644 arch/arm/common/krait-l2-accessors.c create mode 100644 arch/arm/include/asm/krait-l2-accessors.h create mode 100644 drivers/edac/krait_edac.c -- The Qualcomm Innovation Center, Inc. is a member of the 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/
[PATCH v3 1/6] edac: Don't try to cancel workqueue when it's never setup
We only setup a workqueue for edac devices that use the polling
method. We still try to cancel the workqueue if an edac_device
uses the irq method though. This causes a warning from debug
objects when we remove an edac device:
WARNING: CPU: 0 PID: 56 at lib/debugobjects.c:260 debug_print_object+0x98/0xc0()
ODEBUG: assert_init not available (active state 0) object type: timer_list
hint: stub_timer+0x0/0x28
Modules linked in: krait_edac(-)
CPU: 0 PID: 56 Comm: rmmod Not tainted 3.12.0-rc2-00035-g15292a0 #69
(unwind_backtrace+0x0/0x144)
(show_stack+0x20/0x24)
(dump_stack+0x74/0xb4)
(warn_slowpath_common+0x78/0x9c)
(warn_slowpath_fmt+0x40/0x48)
(debug_print_object+0x98/0xc0)
(debug_object_assert_init+0xdc/0xec)
(del_timer+0x24/0x7c)
(try_to_grab_pending+0xc0/0x1b0)
(cancel_delayed_work+0x2c/0xa0)
(edac_device_workq_teardown+0x1c/0x38)
(edac_device_del_device+0xb8/0xe4)
(krait_edac_remove+0x50/0x70 [krait_edac])
(platform_drv_remove+0x24/0x28)
(__device_release_driver+0x68/0xc0)
(driver_detach+0xc4/0xc8)
(bus_remove_driver+0xac/0x114)
(driver_unregister+0x38/0x58)
(platform_driver_unregister+0x1c/0x20)
(krait_edac_driver_exit+0x14/0x1c [krait_edac])
(SyS_delete_module+0x178/0x2b4)
Fix it by skipping the workqueue teardown for such devices.
Acked-by: Borislav Petkov
Signed-off-by: Stephen Boyd
---
drivers/edac/edac_device.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/edac/edac_device.c b/drivers/edac/edac_device.c
index 211021d..203561b 100644
--- a/drivers/edac/edac_device.c
+++ b/drivers/edac/edac_device.c
@@ -437,6 +437,9 @@ void edac_device_workq_teardown(struct edac_device_ctl_info
*edac_dev)
{
int status;
+ if (!edac_dev->edac_check)
+ return;
+
status = cancel_delayed_work(_dev->work);
if (status == 0) {
/* workq instance might be running, wait for it */
--
The Qualcomm Innovation Center, Inc. is a member of the 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: perf events ring buffer memory barrier on powerpc
"David Laight" wrote on 11/01/2013 06:25:29 PM: > gcc will do unexpected memory accesses for bit fields that are > adjacent to volatile data. > In particular it may generate 64bit sized (and aligned) RMW cycles > when accessing bit fields. > And yes, this has caused real problems. Thanks, I am aware about this bug/feature in gcc. -- Victor -- 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 v3 2/6] genirq: export percpu irq functions for module usage
In the near future we're going to use these percpu irq functions in the Krait CPU EDAC driver. Export them so that the EDAC driver can be compiled as a module. Acked-by: Thomas Gleixner Signed-off-by: Stephen Boyd --- kernel/irq/manage.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c index 514bcfd..c6009d1 100644 --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c @@ -1623,6 +1623,7 @@ void free_percpu_irq(unsigned int irq, void __percpu *dev_id) kfree(__free_percpu_irq(irq, dev_id)); chip_bus_sync_unlock(desc); } +EXPORT_SYMBOL_GPL(free_percpu_irq); /** * setup_percpu_irq - setup a per-cpu interrupt @@ -1693,3 +1694,4 @@ int request_percpu_irq(unsigned int irq, irq_handler_t handler, return retval; } +EXPORT_SYMBOL_GPL(request_percpu_irq); -- The Qualcomm Innovation Center, Inc. is a member of the 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/
[PATCH v3 3/6] ARM: Add Krait L2 accessor functions
Qualcomm's Krait CPUs have a handful of L2 cache controller
registers that live behind a cp15 based indirection register.
First you program the indirection register (l2cpselr) to point
the L2 'window' register (l2cpdr) at what you want to read/write.
Then you read/write the 'window' register to do what you want.
The l2cpselr register is not banked per-cpu so we must lock
around accesses to it to prevent other CPUs from re-pointing
l2cpdr underneath us.
Cc: Mark Rutland
Cc: Russell King
Signed-off-by: Stephen Boyd
---
arch/arm/common/Kconfig | 3 ++
arch/arm/common/Makefile | 1 +
arch/arm/common/krait-l2-accessors.c | 58 +++
arch/arm/include/asm/krait-l2-accessors.h | 20 +++
4 files changed, 82 insertions(+)
create mode 100644 arch/arm/common/krait-l2-accessors.c
create mode 100644 arch/arm/include/asm/krait-l2-accessors.h
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index c3a4e9c..9da52dc 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -9,6 +9,9 @@ config DMABOUNCE
bool
select ZONE_DMA
+config KRAIT_L2_ACCESSORS
+ bool
+
config SHARP_LOCOMO
bool
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index 8c60f47..606131a 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_ICST) += icst.o
obj-$(CONFIG_SA) += sa.o
obj-$(CONFIG_PCI_HOST_VIA82C505) += via82c505.o
obj-$(CONFIG_DMABOUNCE)+= dmabounce.o
+obj-$(CONFIG_KRAIT_L2_ACCESSORS) += krait-l2-accessors.o
obj-$(CONFIG_SHARP_LOCOMO) += locomo.o
obj-$(CONFIG_SHARP_PARAM) += sharpsl_param.o
obj-$(CONFIG_SHARP_SCOOP) += scoop.o
diff --git a/arch/arm/common/krait-l2-accessors.c
b/arch/arm/common/krait-l2-accessors.c
new file mode 100644
index 000..f17c361
--- /dev/null
+++ b/arch/arm/common/krait-l2-accessors.c
@@ -0,0 +1,58 @@
+/*
+ * Copyright (c) 2011-2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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.
+ */
+
+#include
+#include
+
+#include
+#include
+
+static DEFINE_RAW_SPINLOCK(krait_l2_lock);
+
+void set_l2_indirect_reg(u32 addr, u32 val)
+{
+ unsigned long flags;
+
+ raw_spin_lock_irqsave(_l2_lock, flags);
+ /*
+* Select the L2 window by poking l2cpselr, then write to the window
+* via l2cpdr.
+*/
+ asm volatile ("mcr p15, 3, %0, c15, c0, 6 @ l2cpselr" : : "r" (addr));
+ isb();
+ asm volatile ("mcr p15, 3, %0, c15, c0, 7 @ l2cpdr" : : "r" (val));
+ isb();
+
+ raw_spin_unlock_irqrestore(_l2_lock, flags);
+}
+EXPORT_SYMBOL(set_l2_indirect_reg);
+
+u32 get_l2_indirect_reg(u32 addr)
+{
+ u32 val;
+ unsigned long flags;
+
+ raw_spin_lock_irqsave(_l2_lock, flags);
+ /*
+* Select the L2 window by poking l2cpselr, then read from the window
+* via l2cpdr.
+*/
+ asm volatile ("mcr p15, 3, %0, c15, c0, 6 @ l2cpselr" : : "r" (addr));
+ isb();
+ asm volatile ("mrc p15, 3, %0, c15, c0, 7 @ l2cpdr" : "=r" (val));
+
+ raw_spin_unlock_irqrestore(_l2_lock, flags);
+
+ return val;
+}
+EXPORT_SYMBOL(get_l2_indirect_reg);
diff --git a/arch/arm/include/asm/krait-l2-accessors.h
b/arch/arm/include/asm/krait-l2-accessors.h
new file mode 100644
index 000..d5305c4
--- /dev/null
+++ b/arch/arm/include/asm/krait-l2-accessors.h
@@ -0,0 +1,20 @@
+/*
+ * Copyright (c) 2011-2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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.
+ */
+
+#ifndef __ASMARM_KRAIT_L2_ACCESSORS_H
+#define __ASMARM_KRAIT_L2_ACCESSORS_H
+
+extern void set_l2_indirect_reg(u32 addr, u32 val);
+extern u32 get_l2_indirect_reg(u32 addr);
+
+#endif
--
The Qualcomm Innovation Center, Inc. is a member of the 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
Re: [PATCH net] net: flow_dissector: fail on evil iph->ihl
On Fri, 2013-11-01 at 15:01 +0800, Jason Wang wrote: > We don't validate iph->ihl which may lead a dead loop if we meet a IPIP > skb whose iph->ihl is zero. Fix this by failing immediately when iph->ihl > is evil (less than 5). > > This issue were introduced by commit ec5efe7946280d1e84603389a1030ccec0a767ae > (rps: support IPIP encapsulation). It would be helpful to include the CVE ID here: CVE-2013-4348 Ben. > Cc: Eric Dumazet > Cc: Petr Matousek > Cc: Michael S. Tsirkin > Cc: Daniel Borkmann > Signed-off-by: Jason Wang > --- > This patch is needed for stable. > --- > net/core/flow_dissector.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c > index 8d7d0dd..143b6fd 100644 > --- a/net/core/flow_dissector.c > +++ b/net/core/flow_dissector.c > @@ -40,7 +40,7 @@ again: > struct iphdr _iph; > ip: > iph = skb_header_pointer(skb, nhoff, sizeof(_iph), &_iph); > - if (!iph) > + if (!iph || iph->ihl < 5) > return false; > > if (ip_is_fragment(iph)) -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. -- 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] Make efi-pstore return a unique id
On Fri, Nov 1, 2013 at 5:14 PM, Madper Xie wrote:
>
> Pstore fs expects that backends provide a uniqued id which could avoid
> pstore making entries as duplication or denominating entries the same
> name. So I combine the timestamp, part and count into id.
>
> Signed-off-by: Madper Xie
> ---
> drivers/firmware/efi/efi-pstore.c | 22 ++
> 1 file changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/firmware/efi/efi-pstore.c
> b/drivers/firmware/efi/efi-pstore.c
> index 5002d50..0de9179 100644
> --- a/drivers/firmware/efi/efi-pstore.c
> +++ b/drivers/firmware/efi/efi-pstore.c
> @@ -39,6 +39,17 @@ struct pstore_read_data {
> char **buf;
> };
>
> +static u64 efi_generate_id(unsigned long timestamp, unsigned int part, int
> count)
> +{
> + char id_str[64];
> + u64 id = 0;
> +
> + sprintf(id_str, "%lu%u%d", timestamp, part, count);
> + if (kstrtoull(id_str, 10, ))
> + pr_warn("efi-pstore: failed to generate id\n");
> + return id;
> +}
This is just odd. You make a string from three ints and then a parse
it to a int again.
> static int efi_pstore_read_func(struct efivar_entry *entry, void *data)
> {
> efi_guid_t vendor = LINUX_EFI_CRASH_GUID;
> @@ -57,17 +68,18 @@ static int efi_pstore_read_func(struct efivar_entry
> *entry, void *data)
>
> if (sscanf(name, "dump-type%u-%u-%d-%lu-%c",
>cb_data->type, , , , _type) == 5) {
> - *cb_data->id = part;
> + *cb_data->id = efi_generate_id(time, part, cnt);
> *cb_data->count = cnt;
> cb_data->timespec->tv_sec = time;
> cb_data->timespec->tv_nsec = 0;
> +
> if (data_type == 'C')
> *cb_data->compressed = true;
> else
> *cb_data->compressed = false;
> } else if (sscanf(name, "dump-type%u-%u-%d-%lu",
>cb_data->type, , , ) == 4) {
> - *cb_data->id = part;
> + *cb_data->id = efi_generate_id(time, part, cnt);
> *cb_data->count = cnt;
> cb_data->timespec->tv_sec = time;
> cb_data->timespec->tv_nsec = 0;
> @@ -79,7 +91,7 @@ static int efi_pstore_read_func(struct efivar_entry *entry,
> void *data)
> * which doesn't support holding
> * multiple logs, remains.
> */
> - *cb_data->id = part;
> + *cb_data->id = efi_generate_id(time, part, 0);
> *cb_data->count = 0;
> cb_data->timespec->tv_sec = time;
> cb_data->timespec->tv_nsec = 0;
> @@ -125,9 +137,11 @@ static int efi_pstore_write(enum pstore_type_id type,
> efi_char16_t efi_name[DUMP_NAME_LEN];
> efi_guid_t vendor = LINUX_EFI_CRASH_GUID;
> int i, ret = 0;
> + unsigned long timestamp;
>
> + timestamp = get_seconds();
> sprintf(name, "dump-type%u-%u-%d-%lu-%c", type, part, count,
> - get_seconds(), compressed ? 'C' : 'D');
> + timestamp, compressed ? 'C' : 'D');
>
> for (i = 0; i < DUMP_NAME_LEN; i++)
> efi_name[i] = name[i];
> --
> 1.8.4.2
>
> --
> 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/
--
Thanks,
//richard
--
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] cciss: return 0 from driver probe function on success, not 1
On 11/01/2013 03:08 PM, scame...@beardog.cce.hp.com wrote:
> On Fri, Nov 01, 2013 at 06:31:10AM -0700, Andrew Morton wrote:
>> On Fri, 01 Nov 2013 14:06:45 +0100 Tomas Henzl wrote:
>>
>>> The problem in kernel is that the error handling in local_pci_probe
>>> and in __pci_device_probe is different for ret values > 0,
>>> so we should fix it somewhere so it is in sync.
>>> The documentation states that the probe function should return zero on
>>> success
>>> so what about this -
>>>
>>> This would bring the handling to sync
>>> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
>>> index 98f7b9b..200a071 100644
>>> --- a/drivers/pci/pci-driver.c
>>> +++ b/drivers/pci/pci-driver.c
>>> @@ -317,8 +317,6 @@ __pci_device_probe(struct pci_driver *drv, struct
>>> pci_dev *pci_dev)
>>> id = pci_match_device(drv, pci_dev);
>>> if (id)
>>> error = pci_call_probe(drv, pci_dev, id);
>>> - if (error >= 0)
>>> - error = 0;
>>> }
>>> return error;
>>> }
>> ah, there it is.
>>
>> This change would turn semi-kaput drivers into kaput-kaput drivers. It
>> would be better to add a runtime warning here so those drivers get
>> fixed. Such a warning would need to reliably identify the offending
>> probe function so a simple WARN_ON() wouldn't be sufficient.
>>
> FWIW, I just booted up with the following change:
>
> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> index 98f7b9b..ef71bb5 100644
> --- a/drivers/pci/pci-driver.c
> +++ b/drivers/pci/pci-driver.c
> @@ -264,9 +264,16 @@ static long local_pci_probe(void *_ddi)
> pm_runtime_get_sync(dev);
> pci_dev->driver = pci_drv;
> rc = pci_drv->probe(pci_dev, ddi->id);
> - if (rc) {
> + if (rc < 0) {
> pci_dev->driver = NULL;
> pm_runtime_put_sync(dev);
> + } else {
> + if (rc > 0) {
> + dev_warn(dev,
> + "Driver probe function returned %d, greater
> than 0\n", rc);
> + rc = 0;
> +
> + }
> }
> return rc;
> }
>
>
> And,
>
> [scameron@localhost linux-3.12-rc6]$ dmesg | grep 'Driver probe'
> [scameron@localhost linux-3.12-rc6]$
>
> Not that it means all that much since I don't have hardware for
> the majority of drivers, obviously.
>
> I think the above should make drivers with probe functions
> returning > 0 "work" again, but with a warning.
>
> The question would be, are there drivers which return > 0 and
> by this value intend to convey that the probe function has failed?
I think that this is unlikely and the patch is fine, but I can't speak for the
drivers..
Please repost your patch so it gets more attention than in this thread.
>
> -- steve
>
> --
> 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/
--
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: stec skd block driver needs updating for immutable biovec
On Fri, Nov 01 2013 at 12:02pm -0400,
Jens Axboe wrote:
> On 11/01/2013 09:50 AM, Christoph Hellwig wrote:
> > On Fri, Nov 01, 2013 at 11:43:39AM -0400, Mike Snitzer wrote:
> >> All the bi_sector ones are low hanging fruit, but the conversion for
> >> skd_preop_sg_list_bio()'s bio_vec code is more involved.
> >>
> >> Kent, any chance you could crank through it?
> >>
> >> If not I can come back to trying to fix this later.. but I'm working
> >> through a test merge of linux-dm.git's 'for-next' with linux-block.git's
> >> 'for-next'.
> >
> > The right thing for 3.13 is to rip out the bio base code path, and
> > for 3.14 to convert it to blk-mq.
>
> It is. I will kill it.
I just cranked through it.. hope this helps (think I got everything but
may have missed something):
From: Mike Snitzer
Subject: [PATCH] skd: remove all the bio-based code
We'll want to convert this driver to blk-mq in the near-term.
Suggested-by: Christoph Hellwig
Signed-off-by: Mike Snitzer
---
drivers/block/skd_main.c | 515 ++
1 files changed, 62 insertions(+), 453 deletions(-)
diff --git a/drivers/block/skd_main.c b/drivers/block/skd_main.c
index 1a8717f..d259b1a 100644
--- a/drivers/block/skd_main.c
+++ b/drivers/block/skd_main.c
@@ -214,8 +214,6 @@ struct skd_request_context {
u32 fitmsg_id;
struct request *req;
- struct bio *bio;
- unsigned long start_time;
u8 flush_cmd;
u8 discard_page;
@@ -357,9 +355,6 @@ struct skd_device {
struct work_struct completion_worker;
- struct bio_list bio_queue;
- int queue_stopped;
-
struct list_head flush_list;
};
@@ -470,11 +465,6 @@ MODULE_PARM_DESC(skd_dbg_level, "s1120 debug level
(0,1,2)");
module_param(skd_isr_comp_limit, int, 0444);
MODULE_PARM_DESC(skd_isr_comp_limit, "s1120 isr comp limit (0=none)
default=4");
-static int skd_bio;
-module_param(skd_bio, int, 0444);
-MODULE_PARM_DESC(skd_bio,
-"Register as a bio device instead of block (0, 1) default=0");
-
/* Major device number dynamically assigned. */
static u32 skd_major;
@@ -512,11 +502,6 @@ static void skd_log_skmsg(struct skd_device *skdev,
static void skd_log_skreq(struct skd_device *skdev,
struct skd_request_context *skreq, const char *event);
-/* FLUSH FUA flag handling. */
-static int skd_flush_cmd_enqueue(struct skd_device *, void *);
-static void *skd_flush_cmd_dequeue(struct skd_device *);
-
-
/*
*
* READ/WRITE REQUESTS
@@ -524,37 +509,22 @@ static void *skd_flush_cmd_dequeue(struct skd_device *);
*/
static void skd_stop_queue(struct skd_device *skdev)
{
- if (!skd_bio)
- blk_stop_queue(skdev->queue);
- else
- skdev->queue_stopped = 1;
+ blk_stop_queue(skdev->queue);
}
static void skd_unstop_queue(struct skd_device *skdev)
{
- if (!skd_bio)
- queue_flag_clear(QUEUE_FLAG_STOPPED, skdev->queue);
- else
- skdev->queue_stopped = 0;
+ queue_flag_clear(QUEUE_FLAG_STOPPED, skdev->queue);
}
static void skd_start_queue(struct skd_device *skdev)
{
- if (!skd_bio) {
- blk_start_queue(skdev->queue);
- } else {
- pr_err("(%s): Starting queue\n", skd_name(skdev));
- skdev->queue_stopped = 0;
- skd_request_fn(skdev->queue);
- }
+ blk_start_queue(skdev->queue);
}
static int skd_queue_stopped(struct skd_device *skdev)
{
- if (!skd_bio)
- return blk_queue_stopped(skdev->queue);
- else
- return skdev->queue_stopped;
+ return blk_queue_stopped(skdev->queue);
}
static void skd_fail_all_pending_blk(struct skd_device *skdev)
@@ -571,40 +541,9 @@ static void skd_fail_all_pending_blk(struct skd_device
*skdev)
}
}
-static void skd_fail_all_pending_bio(struct skd_device *skdev)
-{
- struct bio *bio;
- int error = -EIO;
-
- for (;; ) {
- bio = bio_list_pop(>bio_queue);
-
- if (bio == NULL)
- break;
-
- bio_endio(bio, error);
- }
-}
-
static void skd_fail_all_pending(struct skd_device *skdev)
{
- if (!skd_bio)
- skd_fail_all_pending_blk(skdev);
- else
- skd_fail_all_pending_bio(skdev);
-}
-
-static void skd_make_request(struct request_queue *q, struct bio *bio)
-{
- struct skd_device *skdev = q->queuedata;
- unsigned long flags;
-
- spin_lock_irqsave(>lock, flags);
-
- bio_list_add(>bio_queue, bio);
- skd_request_fn(skdev->queue);
-
- spin_unlock_irqrestore(>lock, flags);
+ skd_fail_all_pending_blk(skdev);
}
static void
@@ -667,18 +606,9 @@ skd_prep_discard_cdb(struct skd_scsi_request *scsi_req,
put_unaligned_be64(lba, [8]);
[PATCH 3/7] perf timechart: use proc_num to implement --power-only
Don't use special flag to indicate power-only mode,
just set proc_num to 0.
Signed-off-by: Stanislav Fomichev
---
tools/perf/builtin-timechart.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/tools/perf/builtin-timechart.c b/tools/perf/builtin-timechart.c
index 51a5532b3382..74c040abb3af 100644
--- a/tools/perf/builtin-timechart.c
+++ b/tools/perf/builtin-timechart.c
@@ -911,7 +911,7 @@ static int determine_display_tasks(u64 threshold)
/* no exit marker, task kept running to the end */
if (p->end_time == 0)
p->end_time = last_time;
- if (p->total_time >= threshold && !power_only)
+ if (p->total_time >= threshold)
p->display = 1;
c = p->all;
@@ -922,7 +922,7 @@ static int determine_display_tasks(u64 threshold)
if (c->start_time == 1)
c->start_time = first_time;
- if (c->total_time >= threshold && !power_only) {
+ if (c->total_time >= threshold) {
c->display = 1;
count++;
}
@@ -949,6 +949,8 @@ static void write_svg_file(const char *filename)
numcpus++;
+ if (power_only)
+ proc_num = 0;
/* We'd like to show at least proc_num tasks;
* be less picky if we have fewer */
@@ -966,9 +968,11 @@ static void write_svg_file(const char *filename)
svg_cpu_box(i, max_freq, turbo_frequency);
draw_cpu_usage();
- draw_process_bars();
+ if (proc_num)
+ draw_process_bars();
draw_c_p_states();
- draw_wakeups();
+ if (proc_num)
+ draw_wakeups();
svg_close();
}
--
1.8.3.2
--
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/7] perf timechart improvements
This patch series adds more features to the perf timechart command: * -n option that adds possibility to limit number of tasks on SVG * -T option that adds possibility to show only tasks related info * -T and -P options now work with `perf timechart record` command to keep perf.data small * -g option that adds possibility to record and add callchain to the SVG so it's now possible to understand why some task went to sleep or what code path woke it up * add titles to the SVG blocks so it's possible to see how long task is running/sleeping/blocked v2: * fix errors pointed out by Namhyung Kim Stanislav Fomichev (7): perf timechart: always try to print at least 15 tasks perf timechart: add option to limit number of tasks perf timechart: use proc_num to implement --power-only perf timechart: add support for displaying only tasks related data perf timechart: group figures and add title with details perf timechart: add support for -P and -T in timechart recording perf timechart: add backtrace support tools/perf/Documentation/perf-timechart.txt | 25 ++- tools/perf/builtin-timechart.c | 307 ++-- tools/perf/util/svghelper.c | 77 ++- tools/perf/util/svghelper.h | 11 +- 4 files changed, 348 insertions(+), 72 deletions(-) -- 1.8.3.2 -- 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 6/7] perf timechart: add support for -P and -T in timechart recording
If we don't want either power or task events we may use -T or -P
with the `perf timechart record` command to filter out events while
recording to keep perf.data small.
Signed-off-by: Stanislav Fomichev
---
tools/perf/Documentation/perf-timechart.txt | 15 -
tools/perf/builtin-timechart.c | 101 +---
2 files changed, 87 insertions(+), 29 deletions(-)
diff --git a/tools/perf/Documentation/perf-timechart.txt
b/tools/perf/Documentation/perf-timechart.txt
index a79d473394f6..abfaff2707da 100644
--- a/tools/perf/Documentation/perf-timechart.txt
+++ b/tools/perf/Documentation/perf-timechart.txt
@@ -8,7 +8,7 @@ perf-timechart - Tool to visualize total system behavior during
a workload
SYNOPSIS
[verse]
-'perf timechart' {record}
+'perf timechart' [] {record} []
DESCRIPTION
---
@@ -20,8 +20,8 @@ There are two variants of perf timechart:
'perf timechart' to turn a trace into a Scalable Vector Graphics file,
that can be viewed with popular SVG viewers such as 'Inkscape'.
-OPTIONS
+TIMECHART OPTIONS
+-
-o::
--output=::
Select the output file (default: output.svg)
@@ -48,6 +48,15 @@ OPTIONS
--proc-num::
Print task info for at least given number of tasks.
+RECORD OPTIONS
+--
+-P::
+--power-only::
+Record only power-related events
+-T::
+--tasks-only::
+Record only tasks-related events
+
SEE ALSO
linkperf:perf-record[1]
diff --git a/tools/perf/builtin-timechart.c b/tools/perf/builtin-timechart.c
index cab1d0fd3fc0..b5b2726d6e32 100644
--- a/tools/perf/builtin-timechart.c
+++ b/tools/perf/builtin-timechart.c
@@ -1034,50 +1034,81 @@ out_delete:
static int __cmd_record(int argc, const char **argv)
{
-#ifdef SUPPORT_OLD_POWER_EVENTS
- const char * const record_old_args[] = {
+ unsigned int rec_argc, i, j;
+ const char **rec_argv;
+ const char **p;
+ unsigned int record_elems;
+
+ const char * const common_args[] = {
"record", "-a", "-R", "-c", "1",
+ };
+ unsigned int common_args_nr = ARRAY_SIZE(common_args);
+
+ const char * const power_args[] = {
+ "-e", "power:cpu_frequency",
+ "-e", "power:cpu_idle",
+ };
+ unsigned int power_args_nr = ARRAY_SIZE(power_args);
+
+ const char * const old_power_args[] = {
+#ifdef SUPPORT_OLD_POWER_EVENTS
"-e", "power:power_start",
"-e", "power:power_end",
"-e", "power:power_frequency",
- "-e", "sched:sched_wakeup",
- "-e", "sched:sched_switch",
- };
#endif
- const char * const record_new_args[] = {
- "record", "-a", "-R", "-c", "1",
- "-e", "power:cpu_frequency",
- "-e", "power:cpu_idle",
+ };
+ unsigned int old_power_args_nr = ARRAY_SIZE(old_power_args);
+
+ const char * const tasks_args[] = {
"-e", "sched:sched_wakeup",
"-e", "sched:sched_switch",
};
- unsigned int rec_argc, i, j;
- const char **rec_argv;
- const char * const *record_args = record_new_args;
- unsigned int record_elems = ARRAY_SIZE(record_new_args);
+ unsigned int tasks_args_nr = ARRAY_SIZE(tasks_args);
#ifdef SUPPORT_OLD_POWER_EVENTS
if (!is_valid_tracepoint("power:cpu_idle") &&
is_valid_tracepoint("power:power_start")) {
use_old_power_events = 1;
- record_args = record_old_args;
- record_elems = ARRAY_SIZE(record_old_args);
+ power_args_nr = 0;
+ } else {
+ old_power_args_nr = 0;
}
#endif
- rec_argc = record_elems + argc - 1;
+ if (power_only)
+ tasks_args_nr = 0;
+
+ if (tasks_only) {
+ power_args_nr = 0;
+ old_power_args_nr = 0;
+ }
+
+ record_elems = common_args_nr + tasks_args_nr +
+ power_args_nr + old_power_args_nr;
+
+ rec_argc = record_elems + argc;
rec_argv = calloc(rec_argc + 1, sizeof(char *));
if (rec_argv == NULL)
return -ENOMEM;
- for (i = 0; i < record_elems; i++)
- rec_argv[i] = strdup(record_args[i]);
+ p = rec_argv;
+ for (i = 0; i < common_args_nr; i++)
+ *p++ = strdup(common_args[i]);
+
+ for (i = 0; i < tasks_args_nr; i++)
+ *p++ = strdup(tasks_args[i]);
+
+ for (i = 0; i < power_args_nr; i++)
+ *p++ = strdup(power_args[i]);
- for (j = 1; j < (unsigned int)argc; j++, i++)
- rec_argv[i] = argv[j];
+ for (i = 0; i < old_power_args_nr; i++)
+ *p++ = strdup(old_power_args[i]);
- return cmd_record(i, rec_argv, NULL);
+ for (j = 1; j < (unsigned int)argc; j++)
+ *p++ = argv[j];
+
+ return cmd_record(rec_argc,
RE: perf events ring buffer memory barrier on powerpc
> But "broken" compiler is much wider issue to be deeply discussed in this > thread. I'm pretty sure that kernel have tons of very subtle > code that actually creates locks and memory ordering. Such code > usually just use the "barrier()" approach to tell gcc not to combine > or move memory accesses around it. gcc will do unexpected memory accesses for bit fields that are adjacent to volatile data. In particular it may generate 64bit sized (and aligned) RMW cycles when accessing bit fields. And yes, this has caused real problems. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] clk: exynos5410: register clocks using common clock framework
Nevermind, didn't read the clk-pll.c properly..
pll_35xx and pl_2550 will default to the same code.
Best Regards,
Mauro
On Fri, Nov 1, 2013 at 1:53 PM, Mauro Ribeiro wrote:
> Is the PLL35xx driver compatible with the ones used on 5410?
>
> +static struct samsung_pll_clock exynos5410_plls[nr_plls] __initdata = {
> + [apll] = PLL(pll_35xx, CLK_FOUT_APLL, "fout_apll", "fin_pll",
> APLL_LOCK,
> + APLL_CON0, NULL),
> + [cpll] = PLL(pll_35xx, CLK_FOUT_CPLL, "fout_cpll", "fin_pll",
> CPLL_LOCK,
> + CPLL_CON0, NULL),
> + [mpll] = PLL(pll_35xx, CLK_FOUT_MPLL, "fout_mpll", "fin_pll",
> MPLL_LOCK,
> + MPLL_CON0, NULL),
> + [bpll] = PLL(pll_35xx, CLK_FOUT_BPLL, "fout_bpll", "fin_pll",
> BPLL_LOCK,
> + BPLL_CON0, NULL),
> + [kpll] = PLL(pll_35xx, CLK_FOUT_KPLL, "fout_kpll", "fin_pll",
> KPLL_LOCK,
> + KPLL_CON0, NULL),
>
> It registers all the PLL's with the same PLL. While the manual says
> others PLL names.
>
> Regards,
> Mauro
>
> On Tue, Oct 22, 2013 at 7:44 AM, Mike Turquette wrote:
>> Quoting Vyacheslav Tyrtov (2013-10-14 08:08:23)
>>> From: Tarek Dakhran
>>>
>>> The EXYNOS5410 clocks are statically listed and registered
>>> using the Samsung specific common clock helper functions.
>>>
>>> Signed-off-by: Tarek Dakhran
>>> Signed-off-by: Vyacheslav Tyrtov
>>
>> Looks good to me. Any objections for me to take this through the clk
>> tree?
>>
>> Regards,
>> Mike
>>
>>> ---
>>> .../devicetree/bindings/clock/exynos5410-clock.txt | 37 +++
>>> drivers/clk/samsung/Makefile | 1 +
>>> drivers/clk/samsung/clk-exynos5410.c | 251
>>> +
>>> include/dt-bindings/clock/exynos5410.h | 175 ++
>>> 4 files changed, 464 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/clock/exynos5410-clock.txt
>>> create mode 100644 drivers/clk/samsung/clk-exynos5410.c
>>> create mode 100644 include/dt-bindings/clock/exynos5410.h
>>>
>>> diff --git a/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
>>> b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
>>> new file mode 100644
>>> index 000..a462da231
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
>>> @@ -0,0 +1,37 @@
>>> +* Samsung Exynos5410 Clock Controller
>>> +
>>> +The Exynos5410 clock controller generates and supplies clock to various
>>> +controllers within the Exynos5410 SoC.
>>> +
>>> +Required Properties:
>>> +
>>> +- compatible: should be "samsung,exynos5410-clock"
>>> +
>>> +- reg: physical base address of the controller and length of memory mapped
>>> + region.
>>> +
>>> +- #clock-cells: should be 1.
>>> +
>>> +All available clocks are defined as preprocessor macros in
>>> +dt-bindings/clock/exynos5410.h header and can be used in device
>>> +tree sources.
>>> +
>>> +Example 1: An example of a clock controller node is listed below.
>>> +
>>> + clock: clock-controller@0x1001 {
>>> + compatible = "samsung,exynos5410-clock";
>>> + reg = <0x1001 0x3>;
>>> + #clock-cells = <1>;
>>> + };
>>> +
>>> +Example 2: UART controller node that consumes the clock generated by the
>>> clock
>>> + controller. Refer to the standard clock bindings for information
>>> + about 'clocks' and 'clock-names' property.
>>> +
>>> + serial@12C2 {
>>> + compatible = "samsung,exynos4210-uart";
>>> + reg = <0x12C0 0x100>;
>>> + interrupts = <0 51 0>;
>>> + clocks = < CLK_UART0>, < CLK_SCLK_UART0>;
>>> + clock-names = "uart", "clk_uart_baud0";
>>> + };
>>> diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
>>> index 3413380..5a446ca 100644
>>> --- a/drivers/clk/samsung/Makefile
>>> +++ b/drivers/clk/samsung/Makefile
>>> @@ -5,6 +5,7 @@
>>> obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o
>>> obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
>>> obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
>>> +obj-$(CONFIG_SOC_EXYNOS5410) += clk-exynos5410.o
>>> obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o
>>> obj-$(CONFIG_SOC_EXYNOS5440) += clk-exynos5440.o
>>> obj-$(CONFIG_ARCH_EXYNOS) += clk-exynos-audss.o
>>> diff --git a/drivers/clk/samsung/clk-exynos5410.c
>>> b/drivers/clk/samsung/clk-exynos5410.c
>>> new file mode 100644
>>> index 000..c5eba08
>>> --- /dev/null
>>> +++ b/drivers/clk/samsung/clk-exynos5410.c
>>> @@ -0,0 +1,251 @@
>>> +/*
>>> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
>>> + * Author: Tarek Dakhran
>>> + *
>>> + * 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.
>>> + *
>>> + * Common Clock Framework support for Exynos5410 SoC.
>>> +*/
>>>
Re: FTDI custom VID/PID patch
On Fri, Nov 01, 2013 at 05:26:38PM +0400, Алексей Крамаренко wrote: > Hello Greg. > > It's my first patch, sorry if something wrong. > > Custom VID/PID for Z3X Box device, popular tool for cellphone flashing. A few meta-comments. Your patch had the tabs turned into spaces, the lines were line-wrapped, and you put the Signed-off-by: at the bottom of the patch, not up here in the changelog area. I've fixed it up by hand, but in the future, please work to fix your email client to not mutilate 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: [PATCH] x86: Run checksumming in parallel accross multiple alu's
> How would you suggest replacing the jumps in this case? I agree it would be > faster here, but I'm not sure how I would implement an increment using a > single > conditional move. I think you need 3 instructions, move a 0, conditionally move a 1 then add. I suspect it won't be a win! If you do 'win' it is probably very dependent on how the instructions get scheduled onto the execution units - which will probably make it very cpu type dependant. David -- 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] cciss: return 0 from driver probe function on success, not 1
On 11/01/2013 10:06 AM, Stephen M. Cameron wrote: > From: Stephen M. Cameron > > A return value of 1 is interpreted as an error. See pci_driver. > in local_pci_probe(). If you're wondering how this ever could > have worked, it's because it used to be the case that only return > values less than zero were interpreted as failure. But even in > the current kernel if the driver registers its various entry > points with the kernel, and then returns a value which is > interpreted as failure, those registrations aren't undone, so > the driver still mostly works. However, the driver's remove > function wouldn't be called on rmmod, and pci power management > functions wouldn't work. In the case of Smart Array, since it > has a battery backed cache (or else no cache) even if the driver > is not shut down properly as long as there is no outstanding > i/o, nothing too bad happens, which is why it took so long to > notice. > > Requesting backport to stable because the change to pci-driver.c > which requires driver probe functions to return 0 occurred between > 2.6.35 and 2.6.36 (the pci power management breakage) and again > between 3.7 and 3.8 (pci_dev->driver getting set to NULL in > local_pci_probe() preventing driver remove function from being > called on rmmod.) The original patch went in two days ago, so it's a little difficult for me to update it unfortunately. But you can include lots of this in the pci-driver.c warning print patch instead. -- Jens Axboe -- 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: perf events ring buffer memory barrier on powerpc
On Wed, Oct 30, 2013 at 11:40:15PM -0700, Paul E. McKenney wrote: > The dependency you are talking about is via the "if" statement? > Even C/C++11 is not required to respect control dependencies. > > This one is a bit annoying. The x86 TSO means that you really only > need barrier(), ARM (recent ARM, anyway) and Power could use a weaker > barrier, and so on -- but smp_mb() emits a full barrier. > > Perhaps a new smp_tmb() for TSO semantics, where reads are ordered > before reads, writes before writes, and reads before writes, but not > writes before reads? Another approach would be to define a per-arch > barrier for this particular case. Supposing a sane language where we can rely on control flow; would that change the story? I'm afraid I'm now terminally confused between actual proper memory model issues and fucked compilers. -- 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] arm64: add PAGE_ALIGNED_DATA to linker script
On Fri, Nov 01, 2013 at 03:01:30PM +, Mark Salter wrote: > On Fri, 2013-10-11 at 08:18 -0400, Mark Salter wrote: > > On Wed, 2013-10-09 at 11:14 +0100, Will Deacon wrote: > > > > @@ -110,6 +110,7 @@ SECTIONS > > > >*/ > > > > INIT_TASK_DATA(THREAD_SIZE) > > > > NOSAVE_DATA > > > > + PAGE_ALIGNED_DATA(PAGE_SIZE) > > > > CACHELINE_ALIGNED_DATA(64) > > > > READ_MOSTLY_DATA(64) > > > > > > Can we just replace this chunk with RW_DATA_SECTION(64, PAGE_SIZE, > > > THREAD_SIZE) instead? > > > > > > > I took a look at this. It can be done, but the RW_DATA_SECTION aligns > > data to PAGE_SIZE where the existing alignment is THREAD_SIZE. So using > > RW_DATA_SECTION would waste some space if using 64K pagesize. > > > > --Mark > > So where do we stand with this one? I'd probably go for using the generic macro, but I don't have strong preferences either way. Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Run checksumming in parallel accross multiple alu's
On Fri, 2013-11-01 at 12:08 -0400, Neil Horman wrote: > On Fri, Nov 01, 2013 at 03:42:46PM +, Ben Hutchings wrote: > > On Thu, 2013-10-31 at 14:30 -0400, Neil Horman wrote: > > [...] > > > It > > > functions, but unfortunately the performance lost to the completely broken > > > branch prediction that this inflicts makes it a non starter: > > [...] > > > > Conditional branches are no good but conditional moves might be worth a > > shot. > > > > Ben. > > > How would you suggest replacing the jumps in this case? I agree it would be > faster here, but I'm not sure how I would implement an increment using a > single > conditional move. You can't, but it lets you use additional registers as carry flags. Whether there are enough registers and enough parallelism to cancel out the extra additions required, I don't know. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. -- 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] Make efi-pstore return a unique id
Pstore fs expects that backends provide a uniqued id which could avoid
pstore making entries as duplication or denominating entries the same
name. So I combine the timestamp, part and count into id.
Signed-off-by: Madper Xie
---
drivers/firmware/efi/efi-pstore.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/firmware/efi/efi-pstore.c
b/drivers/firmware/efi/efi-pstore.c
index 5002d50..0de9179 100644
--- a/drivers/firmware/efi/efi-pstore.c
+++ b/drivers/firmware/efi/efi-pstore.c
@@ -39,6 +39,17 @@ struct pstore_read_data {
char **buf;
};
+static u64 efi_generate_id(unsigned long timestamp, unsigned int part, int
count)
+{
+ char id_str[64];
+ u64 id = 0;
+
+ sprintf(id_str, "%lu%u%d", timestamp, part, count);
+ if (kstrtoull(id_str, 10, ))
+ pr_warn("efi-pstore: failed to generate id\n");
+ return id;
+}
+
static int efi_pstore_read_func(struct efivar_entry *entry, void *data)
{
efi_guid_t vendor = LINUX_EFI_CRASH_GUID;
@@ -57,17 +68,18 @@ static int efi_pstore_read_func(struct efivar_entry *entry,
void *data)
if (sscanf(name, "dump-type%u-%u-%d-%lu-%c",
cb_data->type, , , , _type) == 5) {
- *cb_data->id = part;
+ *cb_data->id = efi_generate_id(time, part, cnt);
*cb_data->count = cnt;
cb_data->timespec->tv_sec = time;
cb_data->timespec->tv_nsec = 0;
+
if (data_type == 'C')
*cb_data->compressed = true;
else
*cb_data->compressed = false;
} else if (sscanf(name, "dump-type%u-%u-%d-%lu",
cb_data->type, , , ) == 4) {
- *cb_data->id = part;
+ *cb_data->id = efi_generate_id(time, part, cnt);
*cb_data->count = cnt;
cb_data->timespec->tv_sec = time;
cb_data->timespec->tv_nsec = 0;
@@ -79,7 +91,7 @@ static int efi_pstore_read_func(struct efivar_entry *entry,
void *data)
* which doesn't support holding
* multiple logs, remains.
*/
- *cb_data->id = part;
+ *cb_data->id = efi_generate_id(time, part, 0);
*cb_data->count = 0;
cb_data->timespec->tv_sec = time;
cb_data->timespec->tv_nsec = 0;
@@ -125,9 +137,11 @@ static int efi_pstore_write(enum pstore_type_id type,
efi_char16_t efi_name[DUMP_NAME_LEN];
efi_guid_t vendor = LINUX_EFI_CRASH_GUID;
int i, ret = 0;
+ unsigned long timestamp;
+ timestamp = get_seconds();
sprintf(name, "dump-type%u-%u-%d-%lu-%c", type, part, count,
- get_seconds(), compressed ? 'C' : 'D');
+ timestamp, compressed ? 'C' : 'D');
for (i = 0; i < DUMP_NAME_LEN; i++)
efi_name[i] = name[i];
--
1.8.4.2
--
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] KVM: IOMMU: hva align mapping page size
When determining the page size we could use to map with the IOMMU, the page size should be aligned with the hva, not the gfn. The gfn may not reflect the real alignment within the hugetlbfs file. Most of the time, this works fine. However, if the hugetlbfs file is backed by non-contiguous huge pages, a multi-huge page memslot starts at an unaligned offset within the hugetlbfs file, and the gfn is aligned with respect to the huge page size, kvm_host_page_size() will return the huge page size and we will use that to map with the IOMMU. When we later unpin that same memslot, the IOMMU returns the unmap size as the huge page size, and we happily unpin that many pfns in monotonically increasing order, not realizing we are spanning non-contiguous huge pages and partially unpin the wrong huge page. Instead, ensure the IOMMU mapping page size is aligned with the hva corresponding to the gfn, which does reflect the alignment within the hugetlbfs file. Signed-off-by: Greg Edwards Cc: sta...@vger.kernel.org --- This resolves the bug previously reported (and misdiagnosed) here: http://www.spinics.net/lists/kvm/msg97599.html virt/kvm/iommu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/virt/kvm/iommu.c b/virt/kvm/iommu.c index 72a130b..0e2ff32 100644 --- a/virt/kvm/iommu.c +++ b/virt/kvm/iommu.c @@ -99,8 +99,8 @@ int kvm_iommu_map_pages(struct kvm *kvm, struct kvm_memory_slot *slot) while ((gfn + (page_size >> PAGE_SHIFT)) > end_gfn) page_size >>= 1; - /* Make sure gfn is aligned to the page size we want to map */ - while ((gfn << PAGE_SHIFT) & (page_size - 1)) + /* Make sure hva is aligned to the page size we want to map */ + while (__gfn_to_hva_memslot(slot, gfn) & (page_size - 1)) page_size >>= 1; /* -- 1.8.3.2 -- 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: perf events ring buffer memory barrier on powerpc
On Wed, Oct 30, 2013 at 11:40:15PM -0700, Paul E. McKenney wrote:
> > void kbuf_write(int sz, void *buf)
> > {
> > u64 tail = ACCESS_ONCE(ubuf->tail); /* last location userspace read */
> > u64 offset = kbuf->head; /* we already know where we last wrote */
> > u64 head = offset + sz;
> >
> > if (!space(tail, offset, head)) {
> > /* discard @buf */
> > return;
> > }
> >
> > /*
> > * Ensure that if we see the userspace tail (ubuf->tail) such
> > * that there is space to write @buf without overwriting data
> > * userspace hasn't seen yet, we won't in fact store data before
> > * that read completes.
> > */
> >
> > smp_mb(); /* A, matches with D */
> >
> > write(kbuf->data + offset, buf, sz);
> > kbuf->head = head % kbuf->size;
> >
> > /*
> > * Ensure that we write all the @buf data before we update the
> > * userspace visible ubuf->head pointer.
> > */
> > smp_wmb(); /* B, matches with C */
> >
> > ubuf->head = kbuf->head;
> > }
> > Now the whole crux of the question is if we need barrier A at all, since
> > the STORES issued by the @buf writes are dependent on the ubuf->tail
> > read.
>
> The dependency you are talking about is via the "if" statement?
> Even C/C++11 is not required to respect control dependencies.
But surely we must be able to make it so; otherwise you'd never be able
to write:
void *ptr = obj1;
void foo(void)
{
/* create obj2, obj3 */
smp_wmb(); /* ensure the objs are complete */
/* expose either obj2 or obj3 */
if (x)
ptr = obj2;
else
ptr = obj3;
/* free the unused one */
if (x)
free(obj3);
else
free(obj2);
}
Earlier you said that 'volatile' or '__atomic' avoids speculative
writes; so would:
volatile void *ptr = obj1;
Make the compiler respect control dependencies again? If so, could we
somehow mark that !space() condition volatile?
Currently the above would be considered a valid pattern. But you're
saying its not because the compiler is free to expose both obj2 and obj3
(for however short a time) and thus the free of the 'unused' object is
incorrect and can cause use-after-free.
In fact; how can we be sure that:
void *ptr = NULL;
void bar(void)
{
void *obj = malloc(...);
/* fill obj */
if (!err)
rcu_assign_pointer(ptr, obj);
else
free(obj);
}
Does not get 'optimized' into:
void bar(void)
{
void *obj = malloc(...);
void *old_ptr = ptr;
/* fill obj */
rcu_assign_pointer(ptr, obj);
if (err) { /* because runtime profile data says this is unlikely */
ptr = old_ptr;
free(obj);
}
}
We _MUST_ be able to rely on control flow, otherwise me might as well
all go back to writing kernels in asm.
--
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: [Xen-devel] [PATCH net-next RFC 2/5] xen-netback: Change TX path from grant copy to mapping
On 30/10/13 21:10, Zoltan Kiss wrote:
On 30/10/13 09:11, Paul Durrant wrote:
+err = alloc_xenballooned_pages(MAX_PENDING_REQS,
+vif->mmap_pages,
+false);
Since this is a per-vif allocation, is this going to scale?
Good question, I'll look after this.
I've talked to David Vrabel about this: if ballooning is disabled, this
will reserve real memory, therefore for every VIF you allocate usually
1MB memory. But if you enable ballooning, it will use pages which are
not actually reserved, and that's fine, because we never gonna really
use them. The only issue is that you need to set the maximum at boot
time, and it will consume memory also because of the page table
reservations.
The long term solution would be to just use a bunch of struct pages,
David said the ballooning driver has something like that, but it's
broken at the moment.
if (data_len < txp->size) {
/* Append the packet payload as a fragment. */
txp->offset += data_len;
txp->size -= data_len;
-} else {
+skb_shinfo(skb)->destructor_arg =
+
pending_tx_info[pending_idx].callback_struct;
+} else if (!skb_shinfo(skb)->nr_frags) {
/* Schedule a response immediately. */
+skb_shinfo(skb)->destructor_arg = NULL;
+xenvif_idx_unmap(vif, pending_idx);
xenvif_idx_release(vif, pending_idx,
XEN_NETIF_RSP_OKAY);
+} else {
+/* FIXME: first request fits linear space, I don't know
+ * if any guest would do that, but I think it's possible
+ */
The Windows frontend, because it has to parse the packet headers, will
coalesce everything up to the payload in a single frag and it would be
a good idea to copy this directly into the linear area.
I forgot to clarify this comment: the problem I wanted to handle here if
the first request's size is PKT_PROT_LEN and there is more fragments.
Then skb->len will be PKT_PROT_LEN as well, and the if statement falls
through to the else branch. That might be problematic if we release the
slot of the first request separately from the others. Or am I
overlooking something? Does that matter to netfront anyway?
And this problem, if it's true, applies to the previous, grant copy
method as well.
However, as I think, it might be better to change the condition to
(data_len <= txp->size), rather than putting an if-else statement into
the else branch.
I've talked to Wei, we think this is a broken guest behaviour, and
therefore we shouldn't care if someone does such a stupid thing.
Zoli
--
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: Re: Re: Re: Re: [PATCH 1/3] switch_creds: Syscall to switch creds for file server ops
Jim Lieb wrote:
> On Friday, November 01, 2013 22:24:12 Tetsuo Handa wrote:
> > Jim Lieb wrote:
> > > Subsequent uses look like:
> > > use_creds(cached fd);
> > >
> > > followed by
> > >
> > > open/creat/mknod/write
> > >
> > > followed by
> > >
> > > use_creds(-1);
> >
> > Are you aware that calling commit_creds() is prohibitted between
> > override_creds() and revert_creds() ?
> >
> > If the caller does some operation that calls commit_creds() (like
> > example below), the kernel triggers BUG().
>
> Yes, I do. I caught this in an early pass. I only use override_creds() and
> revert_creds().
Excuse me, but even below example will trigger BUG(). You pack
override_creds() + open() + revert_creds() into one system call so that the
caller of this system call shall not do something that calls commit_creds() ?
-- example module start --
#include
#include
#include
#include
static int __init test_init(void)
{
const struct cred *orig;
{ /* switch_cred() syscall */
struct fd f = fdget(0);
if (!f.file)
return -EBADF;
orig = override_creds(f.file->f_cred);
fdput(f);
}
{ /* something that calls commit_creds() */
struct cred *cred = prepare_creds();
if (cred)
commit_creds(cred);
}
{ /* restore */
revert_creds(orig);
}
return 0;
}
static void test_exit(void)
{
}
module_init(test_init);
module_exit(test_exit);
MODULE_LICENSE("GPL");
-- example module end --
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Run checksumming in parallel accross multiple alu's
On Fri, Nov 01, 2013 at 03:42:46PM +, Ben Hutchings wrote: > On Thu, 2013-10-31 at 14:30 -0400, Neil Horman wrote: > [...] > > It > > functions, but unfortunately the performance lost to the completely broken > > branch prediction that this inflicts makes it a non starter: > [...] > > Conditional branches are no good but conditional moves might be worth a shot. > > Ben. > How would you suggest replacing the jumps in this case? I agree it would be faster here, but I'm not sure how I would implement an increment using a single conditional move. Neil > -- > Ben Hutchings, Staff Engineer, Solarflare > Not speaking for my employer; that's the marketing department's job. > They asked us to note that Solarflare product names are trademarked. > > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- 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 4/5] input: tc3589x-keypad: support probing from device tree
On Thu, Oct 31, 2013 at 5:58 PM, Mark Rutland wrote: >> + plat = devm_kzalloc(dev, sizeof(*plat), GFP_KERNEL); >> + if (!plat) >> + return ERR_PTR(-ENOMEM); >> + >> + of_property_read_u8(np, "keypad,num-columns", >kcol); >> + of_property_read_u8(np, "keypad,num-rows", >krow); > > These look wrong to me, as almost every single use of of_property_read_u8 (or > of_property_read_u16) do. They read _packed_ values out of the dt, and do not > read (u32) cells as u8s or u16s. Yes... > The matrix-keymap binding doesn't define these as 8-bit, and the example > binding they are u32 cells. Either the binding document or this code is wrong. The biding is in patch titled: "mfd: tc3589x: Add device tree bindings" and yes, you are right, this seems wrong. (The example in that patch is wrong too.) > I'm confused as to how this can work. Are you using /bits/ 8 in your dts? Yes indeed I do. So it was working fine... I'll adjust this to use u32:s, even if it seems odd supporting keypads with 255+ columns and rows... well it's in there. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers: w1: make w1_slave::flags long to avoid casts
Hi everyone 31.10.2013, 13:12, "Michal Nazarewicz" : >>> int ttl; >> ... w1_slave.ttl? For noisy lines this was a 'timeout' after which system considered attached device as failed, the noisier line is the longer is timeout I experimented with meters-long w1 wires and it required several search fails to correctly determine that device disappeared > Now that I look at documentation, I think you are correct, but the > problem is on big-endian 64-bit architectures. The fix is still > valid, but the commit message not so much. Something along the > lines of the following would be better: Guys, you so much overcomplicate things - this field is basically a set of in-memory flags for attached device, there is no need to even think about how it is present in different endianess Or do I miss something fundamental there? I wrote it gazillions years ago and probably already forgot something -- 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: perf events ring buffer memory barrier on powerpc
"Paul E. McKenney" wrote on 10/31/2013 05:25:43 PM: > I really don't care about "fair" -- I care instead about the kernel > working reliably. Though I don't see how putting a memory barrier without deep understanding why it is needed helps kernel reliability, I do agree that reliability is more important than performance. > And it should also be easy for proponents of removing memory barriers to > clearly articulate what orderings their code does and does not need. I intentionally took a simplified example of circle buffer from Documentation/circular-buffers.txt. I think both sides agree about memory ordering requirements in the example. At least I didn't see anyone argued about them. > You are assuming control dependencies that the C language does not > provide. Now, for all I know right now, there might well be some other > reason why a full barrier is not required, but the "if" statement cannot > be that reason. > > Please review section 1.10 of the C++11 standard (or the corresponding > section of the C11 standard, if you prefer). The point is that the > C/C++11 covers only data dependencies, not control dependencies. I feel you made a wrong assumption about my expertise in compilers. I don't need to reread section 1.10 of the C++11 standard, because I do agree that potentially compiler can break the code in our case. And I do agree that a compiler barrier() or some other means (including a change of the standard) can be required in future to prevent a compiler from moving memory accesses around. But "broken" compiler is much wider issue to be deeply discussed in this thread. I'm pretty sure that kernel have tons of very subtle code that actually creates locks and memory ordering. Such code usually just use the "barrier()" approach to tell gcc not to combine or move memory accesses around it. Let's just agree for the sake of this memory barrier discussion that we *do* need compiler barrier to tell gcc not to combine or move memory accesses around it. > Glad we agree on something! I'm glad too! > Did you miss the following passage in the paragraph you quoted? > >"... likewise, your consumer must issue a memory barrier >instruction after removing an item from the queue and before >reading from its memory." > > That is why DEC Alpha readers need a read-side memory barrier -- it says > so right there. And as either you or Peter noted earlier in this thread, > this barrier can be supplied by smp_read_barrier_depends(). I did not miss that passage. That passage explains why consumer on Alpha processor after reading @head is required to execute an additional smp_read_barrier_depends() before it can *read* from memory pointed by @tail. And I think that I understand why - because the reader have to wait till local caches are fully updated and only then it can read data from the data buffer. But on the producer side, after we read @tail, we don't need to wait for update of local caches before we start *write* data to the buffer, since the producer is the only one who write data there! > > I can sympathize if you are having trouble believing this. After all, > it took the DEC Alpha architects a full hour to convince me, and that was > in a face-to-face meeting instead of over email. (Just for the record, > it took me even longer to convince them that their earlier documentation > did not clearly indicate the need for these read-side barriers.) But > regardless of whether or not I sympathize, DEC Alpha is what it is. Again, I do understand quirkiness of the DEC Alpha, and I still think that there is no need in *full* memory barrier on producer side - the one before writing data to the buffer and which you've put in kfifo implementation. Regard, -- Victor -- 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] cciss: return 0 from driver probe function on success, not 1
Just resending the patch with a better change log message (as requested by Andrew Morton) and cc'ing sta...@vger.kernel.org, (as I originally had intended.) --- Stephen M. Cameron (1): cciss: return 0 from driver probe function on success, not 1 drivers/block/cciss.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- -- steve -- 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] cciss: return 0 from driver probe function on success, not 1
From: Stephen M. Cameron A return value of 1 is interpreted as an error. See pci_driver. in local_pci_probe(). If you're wondering how this ever could have worked, it's because it used to be the case that only return values less than zero were interpreted as failure. But even in the current kernel if the driver registers its various entry points with the kernel, and then returns a value which is interpreted as failure, those registrations aren't undone, so the driver still mostly works. However, the driver's remove function wouldn't be called on rmmod, and pci power management functions wouldn't work. In the case of Smart Array, since it has a battery backed cache (or else no cache) even if the driver is not shut down properly as long as there is no outstanding i/o, nothing too bad happens, which is why it took so long to notice. Requesting backport to stable because the change to pci-driver.c which requires driver probe functions to return 0 occurred between 2.6.35 and 2.6.36 (the pci power management breakage) and again between 3.7 and 3.8 (pci_dev->driver getting set to NULL in local_pci_probe() preventing driver remove function from being called on rmmod.) Signed-off-by: Stephen M. Cameron Cc: sta...@vger.kernel.org --- drivers/block/cciss.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c index edfa251..0c004ac 100644 --- a/drivers/block/cciss.c +++ b/drivers/block/cciss.c @@ -5183,7 +5183,7 @@ reinit_after_soft_reset: rebuild_lun_table(h, 1, 0); cciss_engage_scsi(h); h->busy_initializing = 0; - return 1; + return 0; clean4: cciss_free_cmd_pool(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: stec skd block driver needs updating for immutable biovec
On 11/01/2013 09:50 AM, Christoph Hellwig wrote: > On Fri, Nov 01, 2013 at 11:43:39AM -0400, Mike Snitzer wrote: >> All the bi_sector ones are low hanging fruit, but the conversion for >> skd_preop_sg_list_bio()'s bio_vec code is more involved. >> >> Kent, any chance you could crank through it? >> >> If not I can come back to trying to fix this later.. but I'm working >> through a test merge of linux-dm.git's 'for-next' with linux-block.git's >> 'for-next'. > > The right thing for 3.13 is to rip out the bio base code path, and > for 3.14 to convert it to blk-mq. It is. I will kill it. -- Jens Axboe -- 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: VT-d and x2apic: broken resume after suspend to ram
On Fri, Nov 01, 2013 at 04:47:47PM +0100, Peter Senna Tschudin wrote: > Only serial ports over USB: > usb 2-1.3.2: pl2303 converter now attached to ttyUSB0 > > The issue with no_console_suspend is that the monitor is powered off > on suspend and never resume after that. The external monitor enters in > power save mode during suspend and also never resume. Do you know if > replacing my wifi/bt card by this: > > http://www.startech.com/Cards-Adapters/Serial-Cards-Adapters/2-Port-RS232-Mini-PCI-Express-Serial-Card-16950-UART~MPEX2S952 > > would enable to use the serial console for seeing kernel debug messages? Who knows, depends on the BIOS in your machine, I guess. But I would say there is a at least a better chance with this than with a USB-Serial adapter. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] clk: exynos5410: register clocks using common clock framework
Is the PLL35xx driver compatible with the ones used on 5410?
+static struct samsung_pll_clock exynos5410_plls[nr_plls] __initdata = {
+ [apll] = PLL(pll_35xx, CLK_FOUT_APLL, "fout_apll", "fin_pll", APLL_LOCK,
+ APLL_CON0, NULL),
+ [cpll] = PLL(pll_35xx, CLK_FOUT_CPLL, "fout_cpll", "fin_pll", CPLL_LOCK,
+ CPLL_CON0, NULL),
+ [mpll] = PLL(pll_35xx, CLK_FOUT_MPLL, "fout_mpll", "fin_pll", MPLL_LOCK,
+ MPLL_CON0, NULL),
+ [bpll] = PLL(pll_35xx, CLK_FOUT_BPLL, "fout_bpll", "fin_pll", BPLL_LOCK,
+ BPLL_CON0, NULL),
+ [kpll] = PLL(pll_35xx, CLK_FOUT_KPLL, "fout_kpll", "fin_pll", KPLL_LOCK,
+ KPLL_CON0, NULL),
It registers all the PLL's with the same PLL. While the manual says
others PLL names.
Regards,
Mauro
On Tue, Oct 22, 2013 at 7:44 AM, Mike Turquette wrote:
> Quoting Vyacheslav Tyrtov (2013-10-14 08:08:23)
>> From: Tarek Dakhran
>>
>> The EXYNOS5410 clocks are statically listed and registered
>> using the Samsung specific common clock helper functions.
>>
>> Signed-off-by: Tarek Dakhran
>> Signed-off-by: Vyacheslav Tyrtov
>
> Looks good to me. Any objections for me to take this through the clk
> tree?
>
> Regards,
> Mike
>
>> ---
>> .../devicetree/bindings/clock/exynos5410-clock.txt | 37 +++
>> drivers/clk/samsung/Makefile | 1 +
>> drivers/clk/samsung/clk-exynos5410.c | 251
>> +
>> include/dt-bindings/clock/exynos5410.h | 175 ++
>> 4 files changed, 464 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/clock/exynos5410-clock.txt
>> create mode 100644 drivers/clk/samsung/clk-exynos5410.c
>> create mode 100644 include/dt-bindings/clock/exynos5410.h
>>
>> diff --git a/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
>> b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
>> new file mode 100644
>> index 000..a462da231
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
>> @@ -0,0 +1,37 @@
>> +* Samsung Exynos5410 Clock Controller
>> +
>> +The Exynos5410 clock controller generates and supplies clock to various
>> +controllers within the Exynos5410 SoC.
>> +
>> +Required Properties:
>> +
>> +- compatible: should be "samsung,exynos5410-clock"
>> +
>> +- reg: physical base address of the controller and length of memory mapped
>> + region.
>> +
>> +- #clock-cells: should be 1.
>> +
>> +All available clocks are defined as preprocessor macros in
>> +dt-bindings/clock/exynos5410.h header and can be used in device
>> +tree sources.
>> +
>> +Example 1: An example of a clock controller node is listed below.
>> +
>> + clock: clock-controller@0x1001 {
>> + compatible = "samsung,exynos5410-clock";
>> + reg = <0x1001 0x3>;
>> + #clock-cells = <1>;
>> + };
>> +
>> +Example 2: UART controller node that consumes the clock generated by the
>> clock
>> + controller. Refer to the standard clock bindings for information
>> + about 'clocks' and 'clock-names' property.
>> +
>> + serial@12C2 {
>> + compatible = "samsung,exynos4210-uart";
>> + reg = <0x12C0 0x100>;
>> + interrupts = <0 51 0>;
>> + clocks = < CLK_UART0>, < CLK_SCLK_UART0>;
>> + clock-names = "uart", "clk_uart_baud0";
>> + };
>> diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
>> index 3413380..5a446ca 100644
>> --- a/drivers/clk/samsung/Makefile
>> +++ b/drivers/clk/samsung/Makefile
>> @@ -5,6 +5,7 @@
>> obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o
>> obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
>> obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
>> +obj-$(CONFIG_SOC_EXYNOS5410) += clk-exynos5410.o
>> obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o
>> obj-$(CONFIG_SOC_EXYNOS5440) += clk-exynos5440.o
>> obj-$(CONFIG_ARCH_EXYNOS) += clk-exynos-audss.o
>> diff --git a/drivers/clk/samsung/clk-exynos5410.c
>> b/drivers/clk/samsung/clk-exynos5410.c
>> new file mode 100644
>> index 000..c5eba08
>> --- /dev/null
>> +++ b/drivers/clk/samsung/clk-exynos5410.c
>> @@ -0,0 +1,251 @@
>> +/*
>> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
>> + * Author: Tarek Dakhran
>> + *
>> + * 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.
>> + *
>> + * Common Clock Framework support for Exynos5410 SoC.
>> +*/
>> +
>> +#include
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "clk.h"
>> +
>> +#define APLL_LOCK 0x0
>> +#define APLL_CON0 0x100
>> +#define CPLL_LOCK 0x10020
>> +#define CPLL_CON0 0x10120
>> +#define MPLL_LOCK
Re: [PATCH 3/3] perf tools: Add -L as short option for call-graph for record/top commands
On Fri, Nov 01, 2013 at 04:23:14PM +0100, Jiri Olsa wrote: > Adding -L as short option for call-graph for record/top > commands. Plus documentation update. Seems overkill. I guess the long option is enough, and in perf short options already need to be considered a precious resource, as they may soon run out. -Andi -- 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] perf tools: Allow multiple cpus record for -p option
Currently we don't create default CPU map for task related target, like: $ perf record -p This makes record command to disable inherited events. which is not desired behaviour (we have special option for that (-i) anyway). Fixing this by creating default CPU map for task related processes. Signed-off-by: Jiri Olsa Cc: Adrian Hunter Cc: Corey Ashford Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Arnaldo Carvalho de Melo --- tools/perf/util/evlist.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c index 0582f67..52bb127 100644 --- a/tools/perf/util/evlist.c +++ b/tools/perf/util/evlist.c @@ -804,7 +804,7 @@ int perf_evlist__create_maps(struct perf_evlist *evlist, return -1; if (perf_target__has_task(target)) - evlist->cpus = cpu_map__dummy_new(); + evlist->cpus = cpu_map__new(target->cpu_list); else if (!perf_target__has_cpu(target) && !target->uses_mmap) evlist->cpus = cpu_map__dummy_new(); else -- 1.7.11.7 -- 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: stec skd block driver needs updating for immutable biovec
On Fri, Nov 01, 2013 at 11:43:39AM -0400, Mike Snitzer wrote: > All the bi_sector ones are low hanging fruit, but the conversion for > skd_preop_sg_list_bio()'s bio_vec code is more involved. > > Kent, any chance you could crank through it? > > If not I can come back to trying to fix this later.. but I'm working > through a test merge of linux-dm.git's 'for-next' with linux-block.git's > 'for-next'. The right thing for 3.13 is to rip out the bio base code path, and for 3.14 to convert it to blk-mq. -- 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: Re: Re: Re: Re: [PATCH 1/3] switch_creds: Syscall to switch creds for file server ops
On Friday, November 01, 2013 22:24:12 Tetsuo Handa wrote:
> Jim Lieb wrote:
> > Subsequent uses look like:
> > use_creds(cached fd);
> >
> > followed by
> >
> > open/creat/mknod/write
> >
> > followed by
> >
> > use_creds(-1);
>
> Are you aware that calling commit_creds() is prohibitted between
> override_creds() and revert_creds() ?
>
> If the caller does some operation that calls commit_creds() (like
> example below), the kernel triggers BUG().
Yes, I do. I caught this in an early pass. I only use override_creds() and
revert_creds().
>
> -- example module start --
> #include
> #include
> #include
> #include
>
> static int __init test_init(void)
> {
> { /* switch_creds() syscall */
> struct fd f = fdget(0);
> if (!f.file)
> return -EBADF;
> put_cred(override_creds(f.file->f_cred));
> fdput(f);
> }
> { /* something that calls commit_creds() */
> struct cred *cred = prepare_creds();
> if (cred)
> commit_creds(cred);
> }
> return 0;
> }
>
> static void test_exit(void)
> {
> }
>
> module_init(test_init);
> module_exit(test_exit);
> MODULE_LICENSE("GPL");
> -- example module end --
>
> Since nobody can guarantee that the caller of switch_creds() never does
> some operation that calls commit_creds(), I don't think switch_creds()
> based on override_creds() will work.
--
Jim Lieb
Linux Systems Engineer
Panasas Inc.
"If ease of use was the only requirement, we would all be riding tricycles"
- Douglas Engelbart 1925–2013
--
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: VT-d and x2apic: broken resume after suspend to ram
On Fri, Nov 1, 2013 at 3:21 PM, Joerg Roedel wrote: > On Fri, Nov 01, 2013 at 02:21:07PM +0100, Peter Senna Tschudin wrote: >> On Fri, Nov 1, 2013 at 2:07 PM, Joerg Roedel wrote: >> > Which kernels have you tried? Does it happen with all of them or is >> > there a kernel-version where this started? >> >> I'm using 3.11.6-200.fc19.x86_64. I always had VT-d enabled, and >> suspend / resume never worked on Linux. I did not know that disabling >> VT-d could be a workaround to the resume issue until yesterday. >> >> Does this have anything in common to: >> https://bugzilla.redhat.com/show_bug.cgi?id=752613 > > This is probably not related. As far as I can see this issue was about > boot problem with discrete graphics while your problem is related to > suspend/resume. > > The next thing I would try on your machine is to get some kernel debug > messages from resume. This might be hard to get, since your notebook > has probably no serial port. But you can try to boot with > no_console_suspend on the kernel cmdline and see if it gives you any > output on resume. Only serial ports over USB: usb 2-1.3.2: pl2303 converter now attached to ttyUSB0 The issue with no_console_suspend is that the monitor is powered off on suspend and never resume after that. The external monitor enters in power save mode during suspend and also never resume. Do you know if replacing my wifi/bt card by this: http://www.startech.com/Cards-Adapters/Serial-Cards-Adapters/2-Port-RS232-Mini-PCI-Express-Serial-Card-16950-UART~MPEX2S952 would enable to use the serial console for seeing kernel debug messages? > > Maybe some of the VT-d guys can take a look too? > > > Joerg > -- Peter -- 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/
stec skd block driver needs updating for immutable biovec
Hey Jens and Kent, You're likely already aware of this but building the latest linux-block.git 'for-next' I get: CC [M] drivers/block/skd_main.o drivers/block/skd_main.c: In function ‘skd_request_fn’: drivers/block/skd_main.c:773: error: ‘struct bio’ has no member named ‘bi_sector’ drivers/block/skd_main.c: In function ‘skd_end_request_bio’: drivers/block/skd_main.c:1142: error: ‘struct bio’ has no member named ‘bi_sector’ drivers/block/skd_main.c: In function ‘skd_preop_sg_list_bio’: drivers/block/skd_main.c:1198: error: implicit declaration of function ‘bio_iovec_idx’ drivers/block/skd_main.c:1198: warning: assignment makes pointer from integer without a cast drivers/block/skd_main.c: In function ‘skd_log_skreq’: drivers/block/skd_main.c:5814: error: ‘struct bio’ has no member named ‘bi_sector’ make[2]: *** [drivers/block/skd_main.o] Error 1 make[1]: *** [drivers/block] Error 2 make: *** [drivers] Error 2 All the bi_sector ones are low hanging fruit, but the conversion for skd_preop_sg_list_bio()'s bio_vec code is more involved. Kent, any chance you could crank through it? If not I can come back to trying to fix this later.. but I'm working through a test merge of linux-dm.git's 'for-next' with linux-block.git's 'for-next'. (I happen to have one of these stec cards so I'll be able to test) Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] of: Add vendor prefix for Cadence
Drivers like clocksource/cadence_ttc and net/macb already use the 'cdns' prefix for Cadence IP. Signed-off-by: Soren Brinkmann --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 2956800f0240..1ce180ce610d 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -16,6 +16,7 @@ avago Avago Technologies bosch Bosch Sensortec GmbH brcm Broadcom Corporation cavium Cavium, Inc. +cdns Cadence Design Systems Inc. chrp Common Hardware Reference Platform cirrus Cirrus Logic, Inc. cortinaCortina Systems, Inc. -- 1.8.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Run checksumming in parallel accross multiple alu's
On Thu, 2013-10-31 at 14:30 -0400, Neil Horman wrote: [...] > It > functions, but unfortunately the performance lost to the completely broken > branch prediction that this inflicts makes it a non starter: [...] Conditional branches are no good but conditional moves might be worth a shot. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. -- 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: perf version not set when building out of tree
* David Ahern wrote: > On 11/1/13, 1:02 AM, Ingo Molnar wrote: > > > >* David Ahern wrote: > > > >>When building out of tree: > >> > >>make perf-tar-src-pkg > > > >What's the canonical way to build a perf tarball? I didn't find any > >makefile target for that. > > Perhaps I misunderstand your question. From the top-level of a kernel tree: > $ make help | grep perf > > perf-tar-src-pkg- Build perf-3.12.0-rc5.tar source tarball > perf-targz-src-pkg - Build perf-3.12.0-rc5.tar.gz source tarball > perf-tarbz2-src-pkg - Build perf-3.12.0-rc5.tar.bz2 source tarball > perf-tarxz-src-pkg - Build perf-3.12.0-rc5.tar.xz source tarball Thx - I was trying to find that within the tools/perf/ Makefiles ;-) Thanks, Ingo -- 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/
[3.8.y.z extended stable] Linux 3.8.13.12
I am announcing the release of the Linux 3.8.13.12 kernel. The updated 3.8.y tree can be found at: git://kernel.ubuntu.com/ubuntu/linux.git linux-3.8.y and can be browsed at: http://kernel.ubuntu.com/git?p=ubuntu/linux.git;h=refs/heads/linux-3.8.y;a=shortlog The diff from v3.8.13.11 is posted as a follow-up to this email. The 3.8.y extended stable tree is maintained by the Ubuntu Kernel Team. For more info, see https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable -Kamal -- Documentation/networking/ipvs-sysctl.txt| 7 + Makefile| 2 +- arch/arm/include/asm/jump_label.h | 2 +- arch/arm/include/asm/syscall.h | 6 + arch/mips/include/asm/jump_label.h | 2 +- arch/parisc/kernel/traps.c | 6 +- arch/powerpc/include/asm/jump_label.h | 2 +- arch/powerpc/kvm/book3s_hv_rmhandlers.S | 2 +- arch/s390/include/asm/jump_label.h | 2 +- arch/sparc/include/asm/jump_label.h | 2 +- arch/sparc/kernel/entry.S | 2 +- arch/sparc/kernel/ktlb.S| 3 +- arch/sparc/kernel/syscalls.S| 8 +- arch/sparc/kernel/trampoline_64.S | 2 - arch/sparc/lib/ksyms.c | 9 -- arch/tile/include/asm/percpu.h | 34 - arch/x86/include/asm/cpufeature.h | 2 +- arch/x86/include/asm/jump_label.h | 2 +- drivers/block/xen-blkfront.c| 36 +++-- drivers/char/random.c | 11 +- drivers/gpu/drm/i915/i915_reg.h | 6 + drivers/gpu/drm/i915/intel_display.c| 8 +- drivers/gpu/drm/i915/intel_pm.c | 5 + drivers/gpu/drm/radeon/evergreen.c | 2 +- drivers/gpu/drm/radeon/evergreend.h | 4 +- drivers/gpu/drm/radeon/r600d.h | 2 +- drivers/gpu/drm/radeon/radeon_test.c| 4 +- drivers/gpu/drm/radeon/sid.h| 4 +- drivers/hwmon/applesmc.c| 13 ++ drivers/i2c/busses/i2c-omap.c | 3 + drivers/md/dm-snap-persistent.c | 18 ++- drivers/net/bonding/bond_main.c | 13 +- drivers/net/can/flexcan.c | 20 +-- drivers/net/ethernet/realtek/r8169.c| 1 + drivers/net/ethernet/via/via-rhine.c| 9 +- drivers/net/ethernet/xilinx/ll_temac_main.c | 6 + drivers/net/ppp/pptp.c | 2 +- drivers/net/tun.c | 11 +- drivers/net/usb/dm9601.c| 2 +- drivers/net/xen-netback/netback.c | 94 drivers/scsi/esp_scsi.c | 14 +- drivers/scsi/esp_scsi.h | 1 + drivers/tty/serial/vt8500_serial.c | 9 +- drivers/usb/core/quirks.c | 6 + drivers/usb/host/xhci-pci.c | 24 +++ drivers/usb/host/xhci.c | 14 +- drivers/usb/host/xhci.h | 2 + drivers/usb/serial/option.c | 225 +++- drivers/usb/serial/ti_usb_3410_5052.c | 1 + drivers/usb/storage/scsiglue.c | 5 +- drivers/usb/storage/unusual_devs.h | 7 + fs/btrfs/inode.c| 2 +- fs/cifs/cifsfs.c| 6 +- fs/ext4/xattr.c | 2 + fs/statfs.c | 2 +- include/linux/compiler-gcc.h| 3 + include/linux/compiler-gcc4.h | 33 +++- include/linux/random.h | 1 + include/linux/timex.h | 14 ++ include/linux/usb_usual.h | 4 +- include/net/ip.h| 12 +- include/net/ip_vs.h | 12 ++ include/net/ipip.h | 3 +- init/main.c | 2 + mm/huge_memory.c| 10 +- mm/page-writeback.c | 10 +- net/bridge/br_netlink.c | 2 +- net/bridge/br_private.h | 8 +- net/bridge/br_stp.c | 23 ++- net/bridge/br_stp_if.c | 12 +- net/caif/cfctrl.c | 3 +- net/core/flow_dissector.c | 4 +- net/core/netpoll.c | 9 +- net/dccp/ipv6.c | 1 + net/ipv4/igmp.c | 8 +- net/ipv4/inetpeer.c | 4 +- net/ipv4/ip_output.c| 8 +- net/ipv4/ipmr.c | 2 +- net/ipv4/raw.c | 2 +- net/ipv4/tcp.c | 3 +- net/ipv4/xfrm4_mode_tunnel.c| 2 +- net/ipv6/exthdrs.c | 6 - net/ipv6/ip6_fib.c | 2 +-
Re: [PATCH v2] WAN: Adding support for Infineon PEF2256 E1 chipset (FALC56)
On Fri, 1 Nov 2013, Christophe Leroy wrote:
diff -urN a/drivers/net/wan/pef2256.c b/drivers/net/wan/pef2256.c
[..]
+static int pef2256_remove(struct platform_device *pdev)
+{
+ struct net_device *ndev = dev_get_drvdata(>dev);
+ struct pef2256_dev_priv *priv = dev_to_hdlc(ndev)->priv;
+
+
+ device_remove_file(priv->dev, _attr_regs);
+ device_remove_file(priv->dev, _attr_Tx_TS);
+ device_remove_file(priv->dev, _attr_Rx_TS);
+ device_remove_file(priv->dev, _attr_mode);
+
+ unregister_hdlc_device(priv->netdev);
+
+ free_netdev(priv->netdev);
+
+ iounmap(priv->base_addr);
+
+ kfree(priv);
+
+ dev_set_drvdata(>dev, NULL);
dev_set_drvdata is not necessary. driver core clears the driver data to NULL
after device_release or on probe failure.
//govind
--
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] perf tools: Add -L as short option for call-graph for record/top commands
Adding -L as short option for call-graph for record/top
commands. Plus documentation update.
Signed-off-by: Jiri Olsa
Cc: Corey Ashford
Cc: David Ahern
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Arnaldo Carvalho de Melo
Cc: Andi Kleen
Cc: Adrian Hunter
---
tools/perf/Documentation/perf-record.txt | 1 +
tools/perf/Documentation/perf-top.txt| 1 +
tools/perf/builtin-record.c | 2 +-
tools/perf/builtin-top.c | 2 +-
4 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index 22ccd63..fb4956e 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -92,6 +92,7 @@ OPTIONS
-g::
Enables call-graph (stack chain/backtrace) recording.
+-L::
--call-graph::
Setup and enable call-graph (stack chain/backtrace) recording,
implies -g.
diff --git a/tools/perf/Documentation/perf-top.txt
b/tools/perf/Documentation/perf-top.txt
index 456fd65..f92d477 100644
--- a/tools/perf/Documentation/perf-top.txt
+++ b/tools/perf/Documentation/perf-top.txt
@@ -143,6 +143,7 @@ Default is to monitor all CPUS.
-G::
Enables call-graph (stack chain/backtrace) recording.
+-L::
--call-graph::
Setup and enable call-graph (stack chain/backtrace) recording,
implies -G.
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 04c5cf9..a20098d 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -903,7 +903,7 @@ const struct option record_options[] = {
OPT_CALLBACK_NOOPT('g', NULL, ,
NULL, "enables call-graph recording" ,
_callchain_opt),
- OPT_CALLBACK(0, "call-graph", ,
+ OPT_CALLBACK('L', "call-graph", ,
"mode[,dump_size]", record_callchain_help,
_parse_callchain_opt),
OPT_INCR('v', "verbose", ,
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index e1671b1..938e025 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1121,7 +1121,7 @@ int cmd_top(int argc, const char **argv, const char
*prefix __maybe_unused)
OPT_CALLBACK_NOOPT('G', NULL, _opts,
NULL, "enables call-graph recording",
_opt),
- OPT_CALLBACK(0, "call-graph", _opts,
+ OPT_CALLBACK('L', "call-graph", _opts,
"mode[,dump_size]", record_callchain_help,
_callchain_opt),
OPT_CALLBACK(0, "ignore-callees", NULL, "regex",
--
1.7.11.7
--
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] perf tools: Add call-graph option support into .perfconfig
Adding call-graph option support into .perfconfig file,
so it's now possible use call-graph option like:
[top]
call-graph = fp
[record]
call-graph = dwarf,8192
Above options ONLY setup the unwind method. To enable
perf record/top to actually use it the command line
option -g/-G must be specified.
The --call-graph option overloads .perfconfig setup.
Assuming above configuration:
$ perf record -g ls
- enables dwarf unwind with user stack size dump 8192 bytes
$ perf top -G
- enables frame pointer unwind
$ perf record --call-graph=fp ls
- enables frame pointer unwind
$ perf top --call-graph=dwarf,4096 ls
- enables dwarf unwind with user stack size dump 4096 bytes
v2 changes:
- Documentation updated
Signed-off-by: Jiri Olsa
Cc: Corey Ashford
Cc: David Ahern
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Arnaldo Carvalho de Melo
Cc: Andi Kleen
Cc: Adrian Hunter
---
tools/perf/Documentation/perf-record.txt | 5 +
tools/perf/Documentation/perf-top.txt| 8
tools/perf/builtin-record.c | 16
tools/perf/builtin-top.c | 12
tools/perf/perf.h| 1 +
tools/perf/util/evsel.c | 2 +-
6 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index ca0d3d9..22ccd63 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -105,6 +105,11 @@ OPTIONS
call graphs, using "dwarf", if available (perf tools linked to
the libunwind library) should be used instead.
+ It's possible to use 'call-grap' option as .perfconfig
+ entry, like:
+ [record]
+ call-graph = dwarf,8192
+
-q::
--quiet::
Don't print any message, useful for scripting.
diff --git a/tools/perf/Documentation/perf-top.txt
b/tools/perf/Documentation/perf-top.txt
index 6a118e7..456fd65 100644
--- a/tools/perf/Documentation/perf-top.txt
+++ b/tools/perf/Documentation/perf-top.txt
@@ -147,6 +147,14 @@ Default is to monitor all CPUS.
Setup and enable call-graph (stack chain/backtrace) recording,
implies -G.
+ Please check other 'call-graph' option DWARF details in
+ perf-record man page.
+
+ It's possible to use 'call-grap' option as .perfconfig
+ entry, like:
+ [top]
+ call-graph = dwarf,8192
+
--ignore-callees=::
Ignore callees of the function(s) matching the given regex.
This has the effect of collecting the callers of each such
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index d046514..2d00a19 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -784,6 +784,8 @@ int record_parse_callchain_opt(const struct option *opt,
struct perf_record_opts *opts = opt->value;
int ret;
+ opts->call_graph_enabled = !unset;
+
/* --no-call-graph */
if (unset) {
opts->call_graph = CALLCHAIN_NONE;
@@ -804,6 +806,8 @@ int record_callchain_opt(const struct option *opt,
{
struct perf_record_opts *opts = opt->value;
+ opts->call_graph_enabled = !unset;
+
if (opts->call_graph == CALLCHAIN_NONE)
opts->call_graph = CALLCHAIN_FP;
@@ -811,6 +815,16 @@ int record_callchain_opt(const struct option *opt,
return 0;
}
+static int perf_record_config(const char *var, const char *value, void *cb)
+{
+ struct perf_record *rec = cb;
+
+ if (!strcmp(var, "record.call-graph"))
+ return record_parse_callchain(value, >opts);
+
+ return perf_default_config(var, value, cb);
+}
+
static const char * const record_usage[] = {
"perf record [] []",
"perf record [] -- []",
@@ -936,6 +950,8 @@ int cmd_record(int argc, const char **argv, const char
*prefix __maybe_unused)
rec->evlist = evsel_list;
+ perf_config(perf_record_config, rec);
+
argc = parse_options(argc, argv, record_options, record_usage,
PARSE_OPT_STOP_AT_NON_OPTION);
if (!argc && perf_target__none(>opts.target))
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 5a11f13..e1671b1 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1031,6 +1031,16 @@ parse_callchain_opt(const struct option *opt, const char
*arg, int unset)
return record_parse_callchain_opt(opt, arg, unset);
}
+static int perf_top_config(const char *var, const char *value, void *cb)
+{
+ struct perf_top *top = cb;
+
+ if (!strcmp(var, "top.call-graph"))
+ return record_parse_callchain(value, >record_opts);
+
+ return perf_default_config(var, value, cb);
+}
+
static int
parse_percent_limit(const struct option *opt, const char *arg,
int unset
[PATCH 2/3] perf tools: Add readable output for callchain debug
Adding people readable output for callchain debug,
to get following '-v' output:
$ perf record -v -g ls
callchain: type DWARF
callchain: stack dump size 4096
...
Tested-Reviewed-by: David Ahern
Signed-off-by: Jiri Olsa
Cc: Corey Ashford
Cc: David Ahern
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Arnaldo Carvalho de Melo
Cc: Andi Kleen
Cc: Adrian Hunter
---
tools/perf/builtin-record.c | 4 +++-
tools/perf/perf.h | 3 ++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 2d00a19..04c5cf9 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -770,7 +770,9 @@ int record_parse_callchain(const char *arg, struct
perf_record_opts *opts)
static void callchain_debug(struct perf_record_opts *opts)
{
- pr_debug("callchain: type %d\n", opts->call_graph);
+ static const char *str[CALLCHAIN_MAX] = { "NONE", "FP", "DWARF" };
+
+ pr_debug("callchain: type %s\n", str[opts->call_graph]);
if (opts->call_graph == CALLCHAIN_DWARF)
pr_debug("callchain: stack dump size %d\n",
diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index 27223fb..313a5df 100644
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -207,7 +207,8 @@ void pthread__unblock_sigwinch(void);
enum perf_call_graph_mode {
CALLCHAIN_NONE,
CALLCHAIN_FP,
- CALLCHAIN_DWARF
+ CALLCHAIN_DWARF,
+ CALLCHAIN_MAX
};
struct perf_record_opts {
--
1.7.11.7
--
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/
[PATCHv2 0/3] perf tools: Fix -g option handling
hi, changing the '-g/-G' options for record/top commands to take NO argument and enable unwind method based on .perfconfig setup (using FP by default). The current -g option parsing moves into the '--call-graph' option. Examples: $ cat ~/.perfconfig: [top] call-graph = fp [record] call-graph = dwarf,8192 $ perf record -g ls - enables dwarf unwind with user stack size dump 8192 bytes $ perf top -G - enables frame pointer unwind $ perf record --call-graph=fp ls - enables frame pointer unwind $ perf top --call-graph=dwarf,4096 ls - enables dwarf unwind with user stack size dump 4096 bytes v2 changes: - added -L as short option for call-graph for record/top commands - updated documentation - based on latest acme's perf/urgent thanks, jirka Cc: Corey Ashford Cc: David Ahern Cc: Ingo Molnar Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: Andi Kleen Cc: Adrian Hunter --- Jiri Olsa (3): perf tools: Add call-graph option support into .perfconfig perf tools: Add readable output for callchain debug perf tools: Add -L as short option for call-graph for record/top commands tools/perf/Documentation/perf-record.txt | 6 ++ tools/perf/Documentation/perf-top.txt| 9 + tools/perf/builtin-record.c | 22 -- tools/perf/builtin-top.c | 14 +- tools/perf/perf.h| 4 +++- tools/perf/util/evsel.c | 2 +- 6 files changed, 52 insertions(+), 5 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/13] tracing/uprobes: Fetch args before reserving a ring buffer
On 11/01, Oleg Nesterov wrote: > > Hi Namhyung, > > Sorry if this was already discussed. But I can't really understand > the idea of this per-cpu buffer... > > On 10/29, Namhyung Kim wrote: > > > > Fetching from user space should be done in a non-atomic context. So > > use a per-cpu buffer and copy its content to the ring buffer > > atomically. Note that we can migrate during accessing user memory > > thus use a per-cpu mutex to protect concurrent accesses. > > And if the task migrates or just sleeps in page fault, another task > which hits another uprobe on the same CPU should wait. > > Why we can't simply add trace_uprobe->buffer instead? Only to save > some memory? But every uprobe is very expensive in this sense anyway. Ah, please ignore... handler_chain() is not self-serialized, so tu->buffer needs locking/waiting too. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] perf tools: Add call-graph option support into .perfconfig
On Tue, Oct 29, 2013 at 11:18:21AM +0100, Jiri Olsa wrote: > On Mon, Oct 28, 2013 at 05:10:54PM +0900, Namhyung Kim wrote: > > On Sat, 26 Oct 2013 16:25:35 +0200, Jiri Olsa wrote: > > > Adding call-graph option support into .perfconfig file, > > > so it's now possible use call-graph option like: > > > > > > [top] > > > call-graph = fp > > > > > > [record] > > > call-graph = dwarf,8192 > > > > > > Above options ONLY setup the unwind method. To enable > > > perf record/top to actually use it the command line > > > option -g/-G must be specified. > > > > > > The --call-graph option overloads .perfconfig setup. > > > > > > Assuming above configuration: > > > > > > $ perf record -g ls > > > - enables dwarf unwind with user stack size dump 8192 bytes > > > > > > $ perf top -G > > > - enables frame pointer unwind > > > > > > $ perf record --call-graph=fp ls > > > - enables frame pointer unwind > > > > > > $ perf top --call-graph=dwarf,4096 ls > > > - enables dwarf unwind with user stack size dump 4096 bytes > > > > > [SNIP] > > > --- a/tools/perf/builtin-record.c > > > +++ b/tools/perf/builtin-record.c > > > @@ -750,6 +750,8 @@ int record_parse_callchain_opt(const struct option > > > *opt, > > > struct perf_record_opts *opts = opt->value; > > > int ret; > > > > > > + opts->call_graph_enabled = !unset; > > > + > > > > Why not just using symbol_conf.use_callchain? > > > > right, this way we'd be in sync with top hum, on the other hand using symbol_conf.use_callchain within utils/evsel.c adds symbol object dependency to python code which I'm not sure is something we want ;-) I'll keep it as it is in v2 jirka -- 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] block: Document immutable biovecs
On 10/31/2013 03:27 PM, Kent Overstreet wrote: > Signed-off-by: Kent Overstreet > Cc: Jens Axboe > Cc: NeilBrown > Cc: Christoph Hellwig Added, and incorporated the changes suggested by Randy. -- Jens Axboe -- 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: Tree for Oct 31 (crypto, rsa, mpi)
Randy Dunlap wrote: > crypto/built-in.o: In function `RSA_verify_signature': > rsa.c:(.text+0x1d347): undefined reference to `mpi_get_nbits' > rsa.c:(.text+0x1d354): undefined reference to `mpi_get_nbits' > ... Does the attached patch fix it for you? David --- KEYS: The RSA public key algorithm needs to select MPILIB The RSA public key algorithm needs to select MPILIB directly in Kconfig as the 'select' directive is not recursive and is thus MPILIB is not enabled by selecting MPILIB_EXTRA. Without this, the following errors can occur: crypto/built-in.o: In function `RSA_verify_signature': rsa.c:(.text+0x1d347): undefined reference to `mpi_get_nbits' rsa.c:(.text+0x1d354): undefined reference to `mpi_get_nbits' rsa.c:(.text+0x1d36e): undefined reference to `mpi_cmp_ui' rsa.c:(.text+0x1d382): undefined reference to `mpi_cmp' rsa.c:(.text+0x1d391): undefined reference to `mpi_alloc' rsa.c:(.text+0x1d3b0): undefined reference to `mpi_powm' rsa.c:(.text+0x1d3c3): undefined reference to `mpi_free' rsa.c:(.text+0x1d3d8): undefined reference to `mpi_get_buffer' rsa.c:(.text+0x1d4d4): undefined reference to `mpi_free' rsa.c:(.text+0x1d503): undefined reference to `mpi_get_nbits' Reported-by: Randy Dunlap Signed-off-by: David Howells --- diff --git a/crypto/asymmetric_keys/Kconfig b/crypto/asymmetric_keys/Kconfig index 82e7d6b0c276..03a6eb95ab50 100644 --- a/crypto/asymmetric_keys/Kconfig +++ b/crypto/asymmetric_keys/Kconfig @@ -23,6 +23,7 @@ config ASYMMETRIC_PUBLIC_KEY_SUBTYPE config PUBLIC_KEY_ALGO_RSA tristate "RSA public-key algorithm" select MPILIB_EXTRA + select MPILIB help This option enables support for the RSA algorithm (PKCS#1, RFC3447). -- 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] USB: storage: use sg_miter_* APIs to access scsi buffer
On Fri, Nov 1, 2013 at 10:54 PM, Alan Stern wrote:
> On Wed, 30 Oct 2013, Ming Lei wrote:
>
>> We have sg_miter_* APIs for accessing scsi sg buffer, so
>> use them to make code clean and bug free.
>
> Hmmm. You could simply call sg_copy_buffer, if you didn't mind the
> quadratic penalty for the sg_miter_skip operations.
I don't want to change all current callers now.
>
>> --- a/drivers/usb/storage/protocol.c
>> +++ b/drivers/usb/storage/protocol.c
>> @@ -135,69 +135,43 @@ unsigned int usb_stor_access_xfer_buf(unsigned char
>> *buffer,
>> unsigned int buflen, struct scsi_cmnd *srb, struct scatterlist **sgptr,
>> unsigned int *offset, enum xfer_buf_dir dir)
>> {
>> - unsigned int cnt;
>> + unsigned int cnt = 0;
>> struct scatterlist *sg = *sgptr;
>> + struct sg_mapping_iter miter;
>> + unsigned int nents = scsi_sg_count(srb);
>>
>> - /* We have to go through the list one entry
>> - * at a time. Each s-g entry contains some number of pages, and
>> - * each page has to be kmap()'ed separately. If the page is already
>> - * in kernel-addressable memory then kmap() will return its address.
>> - * If the page is not directly accessible -- such as a user buffer
>> - * located in high memory -- then kmap() will map it to a temporary
>> - * position in the kernel's virtual address space.
>> - */
>> -
>> - if (!sg)
>> + if (sg)
>> + nents -= sg - scsi_sglist(srb);
>
> This is definitely wrong. Scatterlist entries are not always stored in
> a linear array. To do this properly, you would have to make the caller
> keep track of the current value of nents.
>
> Or better yet, have the caller store and pass the sg_mapping_iter
> structure rather than sgptr and offset.
You are right, but looks we can use sg_nents(), which is easier, :-)
>
>> + else
>> sg = scsi_sglist(srb);
>>
>> - /* This loop handles a single s-g list entry, which may
>> - * include multiple pages. Find the initial page structure
>> - * and the starting offset within the page, and update
>> - * the *offset and **sgptr values for the next loop.
>> - */
>> - cnt = 0;
>> - while (cnt < buflen && sg) {
>> - struct page *page = sg_page(sg) +
>> - ((sg->offset + *offset) >> PAGE_SHIFT);
>> - unsigned int poff = (sg->offset + *offset) & (PAGE_SIZE-1);
>> - unsigned int sglen = sg->length - *offset;
>> -
>> - if (sglen > buflen - cnt) {
>> -
>> - /* Transfer ends within this s-g entry */
>> - sglen = buflen - cnt;
>> - *offset += sglen;
>> - } else {
>> + if (dir == FROM_XFER_BUF)
>> + sg_miter_start(, sg, nents, SG_MITER_FROM_SG);
>> + else
>> + sg_miter_start(, sg, nents, SG_MITER_TO_SG);
>
> I find this style somewhat annoying. Maybe the compiler is smart
> enough to optimize it, maybe not. In any case, I would prefer to see
>
> if (dir == FROM_XFER_BUF)
> sgdir = SG_MITER_FROM_SG;
> else
> sgdir = SG_MITER_TO_SG;
> sg_miter_start(, nents, sgdir);
>
> Or even:
>
> sg_miter_start(, nents, (dir == FROM_XFER_BUF ?
> SG_MITER_FROM_SG : SG_MITER_TO_SG));
Looks the above is fine.
>
>> - /* Transfer continues to next s-g entry */
>> - *offset = 0;
>> - sg = sg_next(sg);
>> - }
>> + if (!sg_miter_skip(, *offset))
>> + return cnt;
>> +
>> + while (sg_miter_next() && cnt < buflen) {
>> + unsigned int len = min(miter.length, buflen - cnt);
>> +
>> + if (dir == FROM_XFER_BUF)
>> + memcpy(buffer + cnt, miter.addr, len);
>> + else
>> + memcpy(miter.addr, buffer + cnt, len);
>>
>> - /* Transfer the data for all the pages in this
>> - * s-g entry. For each page: call kmap(), do the
>> - * transfer, and call kunmap() immediately after. */
>> - while (sglen > 0) {
>> - unsigned int plen = min(sglen, (unsigned int)
>> - PAGE_SIZE - poff);
>> - unsigned char *ptr = kmap(page);
>> -
>> - if (dir == TO_XFER_BUF)
>> - memcpy(ptr + poff, buffer + cnt, plen);
>> - else
>> - memcpy(buffer + cnt, ptr + poff, plen);
>> - kunmap(page);
>> -
>> - /* Start at the beginning of the next page */
>> - poff = 0;
>> - ++page;
>> - cnt += plen;
>> - sglen -= plen;
>> + if (*offset + len < miter.piter.sg->length) {
>> + *offset +=
Re: [PATCH 08/14] perf report: Cache cumulative callchains
On Fri, Nov 01, 2013 at 04:07:22PM +0900, Namhyung Kim wrote: > Hi Rodrigo, > > On Thu, 31 Oct 2013 11:13:34 +, Rodrigo Campos wrote: > > On Thu, Oct 31, 2013 at 03:56:10PM +0900, Namhyung Kim wrote: > > I think the right fix is assigning "iter->priv = NULL" as you said. But > I changed this patch a bit for v3 so need to check it again. Btw, that would have a race condition if this is run on multiple threads (I mean, if different threads can free the same "iter->prev" pointer), at least if we do it just assigning NULL after the free(). But maybe that's not an issue ? Thanks a lot, Rodrigo -- 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: manual merge of the block tree with the tree
On 10/31/2013 09:20 PM, Stephen Rothwell wrote:
> Hi Jens,
>
> Today's linux-next merge of the block tree got a conflict in
> drivers/block/loop.c between commit 2486740b52fd ("loop: use aio to
> perform io on the underlying file") from the aio-direct tree and commit
> ed2d2f9a8265 ("block: Abstract out bvec iterator") from the block tree.
>
> I fixed it up (I think - see below - I have also attached the final
> resulting file) and can carry the fix as necessary (no action is
> required).
>
What tree is this from? It'd be a lot more convenient to fold that loop
patch into my tree, especially since the block tree in linux-next failed
after this merge.
--
Jens Axboe
--
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 10/13] tracing/uprobes: Fetch args before reserving a ring buffer
Hi Namhyung, Sorry if this was already discussed. But I can't really understand the idea of this per-cpu buffer... On 10/29, Namhyung Kim wrote: > > Fetching from user space should be done in a non-atomic context. So > use a per-cpu buffer and copy its content to the ring buffer > atomically. Note that we can migrate during accessing user memory > thus use a per-cpu mutex to protect concurrent accesses. And if the task migrates or just sleeps in page fault, another task which hits another uprobe on the same CPU should wait. Why we can't simply add trace_uprobe->buffer instead? Only to save some memory? But every uprobe is very expensive in this sense anyway. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] power: Add legacy pm ops usage warning
Add legacy pm_ops usage checks to device_pm_add() when a device gets added
to PM core's list of active devices. If legacy pm_ops usage is found at its
class, bus, driver level, print warning message to indicate the driver code
needs updating to use dev pm ops interfaces. This will help serve as a way
to track drivers that still use legacy pm ops and fix them.
Signed-off-by: Shuah Khan
---
drivers/base/power/main.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 9f098a8..4dc26dc 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -112,6 +112,23 @@ void device_pm_unlock(void)
}
/**
+ * check for lgeacy pm_ops usage and warn
+ */
+static void device_legacy_pm_ops_check(struct device *dev)
+{
+ char *info = "Please update driver to use dev pm_ops";
+
+ if (dev->class && (dev->class->suspend || dev->class->resume))
+ dev_warn(dev, "Driver uses legacy class pm ops - %s\n", info);
+
+ if (dev->bus && (dev->bus->suspend || dev->bus->resume))
+ dev_warn(dev, "Driver uses legacy bus pm ops - %s\n", info);
+
+ if (dev->driver && (dev->driver->suspend || dev->driver->resume))
+ dev_warn(dev, "Driver uses legacy pm ops - %s\n", info);
+}
+
+/**
* device_pm_add - Add a device to the PM core's list of active devices.
* @dev: Device to add to the list.
*/
@@ -123,6 +140,7 @@ void device_pm_add(struct device *dev)
if (dev->parent && dev->parent->power.is_prepared)
dev_warn(dev, "parent %s should not be sleeping\n",
dev_name(dev->parent));
+ device_legacy_pm_ops_check(dev);
list_add_tail(>power.entry, _list);
mutex_unlock(_list_mtx);
}
--
1.8.1.2
--
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 for-next] dm: fix missing bi_remaining accounting
On 11/01/2013 07:59 AM, Mike Snitzer wrote: > Add the missing bi_remaining increment, required by the block layer's > new bio-chaining code, to both the verity and old snapshot DM targets. > > Otherwise users will hit the bi_remaining <= 0 BUG_ON in bio_endio(). Thanks Mike, added to the mix. -- Jens Axboe -- 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] WAN: Adding support for Infineon PEF2256 E1 chipset (FALC56)
The patch adds WAN support for Infineon FALC56 - PEF2256 E1 Chipset.
Signed-off-by: Jerome Chantelauze
Acked-by: Christophe Leroy
diff -urN a/drivers/net/wan/pef2256.c b/drivers/net/wan/pef2256.c
--- a/drivers/net/wan/pef2256.c 1970-01-01 01:00:00.0 +0100
+++ b/drivers/net/wan/pef2256.c 2013-10-13 13:05:01.0 +0200
@@ -0,0 +1,1197 @@
+/* drivers/net/wan/pef2256.c : a PEF2256 HDLC driver for Linux
+ *
+ * This software may be used and distributed according to the terms of the
+ * GNU General Public License.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "pef2256.h"
+
+static irqreturn_t pef2256_irq(int irq, void *dev_priv);
+static int Config_HDLC(struct pef2256_dev_priv *priv);
+static int init_FALC(struct pef2256_dev_priv *priv);
+static int pef2256_open(struct net_device *netdev);
+static int pef2256_close(struct net_device *netdev);
+
+void print_regs(struct device *dev)
+{
+ struct net_device *ndev = dev_get_drvdata(dev);
+ struct pef2256_dev_priv *priv = dev_to_hdlc(ndev)->priv;
+ unsigned char *base_addr = priv->base_addr;
+
+ netdev_info(ndev, " MODE = 0x%02x\n", readb(base_addr + MODE));
+ netdev_info(ndev, " RAH1 = 0x%02x\n", readb(base_addr + RAH1));
+ netdev_info(ndev, " RAH2 = 0x%02x\n", readb(base_addr + RAH2));
+ netdev_info(ndev, " RAL1 = 0x%02x\n", readb(base_addr + RAL1));
+ netdev_info(ndev, " RAL2 = 0x%02x\n", readb(base_addr + RAL2));
+ netdev_info(ndev, " IPC = 0x%02x\n", readb(base_addr + IPC));
+ netdev_info(ndev, " CCR1 = 0x%02x\n", readb(base_addr + CCR1));
+ netdev_info(ndev, " CCR2 = 0x%02x\n", readb(base_addr + CCR2));
+ netdev_info(ndev, " RTR1 = 0x%02x\n", readb(base_addr + RTR1));
+ netdev_info(ndev, " RTR2 = 0x%02x\n", readb(base_addr + RTR2));
+ netdev_info(ndev, " RTR3 = 0x%02x\n", readb(base_addr + RTR3));
+ netdev_info(ndev, " RTR4 = 0x%02x\n", readb(base_addr + RTR4));
+ netdev_info(ndev, " TTR1 = 0x%02x\n", readb(base_addr + TTR1));
+ netdev_info(ndev, " TTR2 = 0x%02x\n", readb(base_addr + TTR2));
+ netdev_info(ndev, " TTR3 = 0x%02x\n", readb(base_addr + TTR3));
+ netdev_info(ndev, " TTR4 = 0x%02x\n", readb(base_addr + TTR4));
+ netdev_info(ndev, " IMR0 = 0x%02x\n", readb(base_addr + IMR0));
+ netdev_info(ndev, " IMR1 = 0x%02x\n", readb(base_addr + IMR1));
+ netdev_info(ndev, " IMR2 = 0x%02x\n", readb(base_addr + IMR2));
+ netdev_info(ndev, " IMR3 = 0x%02x\n", readb(base_addr + IMR3));
+ netdev_info(ndev, " IMR4 = 0x%02x\n", readb(base_addr + IMR4));
+ netdev_info(ndev, " IMR5 = 0x%02x\n", readb(base_addr + IMR5));
+ netdev_info(ndev, " IERR = 0x%02x\n", readb(base_addr + IERR));
+ netdev_info(ndev, " FMR0 = 0x%02x\n", readb(base_addr + FMR0));
+ netdev_info(ndev, " FMR1 = 0x%02x\n", readb(base_addr + FMR1));
+ netdev_info(ndev, " FMR2 = 0x%02x\n", readb(base_addr + FMR2));
+ netdev_info(ndev, " LOOP = 0x%02x\n", readb(base_addr + LOOP));
+ netdev_info(ndev, " XSW = 0x%02x\n", readb(base_addr + XSW));
+ netdev_info(ndev, " XSP = 0x%02x\n", readb(base_addr + XSP));
+ netdev_info(ndev, " XC0 = 0x%02x\n", readb(base_addr + XC0));
+ netdev_info(ndev, " XC1 = 0x%02x\n", readb(base_addr + XC1));
+ netdev_info(ndev, " RC0 = 0x%02x\n", readb(base_addr + RC0));
+ netdev_info(ndev, " RC1 = 0x%02x\n", readb(base_addr + RC1));
+ netdev_info(ndev, " XPM0 = 0x%02x\n", readb(base_addr + XPM0));
+ netdev_info(ndev, " XPM1 = 0x%02x\n", readb(base_addr + XPM1));
+ netdev_info(ndev, " XPM2 = 0x%02x\n", readb(base_addr + XPM2));
+ netdev_info(ndev, " TSWM = 0x%02x\n", readb(base_addr + TSWM));
+ netdev_info(ndev, " IDLE = 0x%02x\n", readb(base_addr + IDLE));
+ netdev_info(ndev, " XSA4 = 0x%02x\n", readb(base_addr + XSA4));
+ netdev_info(ndev, " XSA5 = 0x%02x\n", readb(base_addr + XSA5));
+ netdev_info(ndev, " XSA6 = 0x%02x\n", readb(base_addr + XSA6));
+ netdev_info(ndev, " XSA7 = 0x%02x\n", readb(base_addr + XSA7));
+ netdev_info(ndev, " XSA8 = 0x%02x\n", readb(base_addr + XSA8));
+ netdev_info(ndev, " FMR3 = 0x%02x\n", readb(base_addr + FMR3));
+ netdev_info(ndev, " ICB1 = 0x%02x\n", readb(base_addr + ICB1));
+ netdev_info(ndev, " ICB2 = 0x%02x\n", readb(base_addr + ICB2));
+ netdev_info(ndev, " ICB3 = 0x%02x\n", readb(base_addr + ICB3));
+ netdev_info(ndev, " ICB4 = 0x%02x\n", readb(base_addr + ICB4));
+ netdev_info(ndev, "
Re: [PATCH] arm64: add PAGE_ALIGNED_DATA to linker script
On Fri, 2013-10-11 at 08:18 -0400, Mark Salter wrote: > On Wed, 2013-10-09 at 11:14 +0100, Will Deacon wrote: > > > @@ -110,6 +110,7 @@ SECTIONS > > >*/ > > > INIT_TASK_DATA(THREAD_SIZE) > > > NOSAVE_DATA > > > + PAGE_ALIGNED_DATA(PAGE_SIZE) > > > CACHELINE_ALIGNED_DATA(64) > > > READ_MOSTLY_DATA(64) > > > > Can we just replace this chunk with RW_DATA_SECTION(64, PAGE_SIZE, > > THREAD_SIZE) instead? > > > > I took a look at this. It can be done, but the RW_DATA_SECTION aligns > data to PAGE_SIZE where the existing alignment is THREAD_SIZE. So using > RW_DATA_SECTION would waste some space if using 64K pagesize. > > --Mark So where do we stand with this one? -- 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: perf events ring buffer memory barrier on powerpc
On Wed, Oct 30, 2013 at 11:40:15PM -0700, Paul E. McKenney wrote: > > Now the whole crux of the question is if we need barrier A at all, since > > the STORES issued by the @buf writes are dependent on the ubuf->tail > > read. > > The dependency you are talking about is via the "if" statement? > Even C/C++11 is not required to respect control dependencies. > > This one is a bit annoying. The x86 TSO means that you really only > need barrier(), ARM (recent ARM, anyway) and Power could use a weaker > barrier, and so on -- but smp_mb() emits a full barrier. > > Perhaps a new smp_tmb() for TSO semantics, where reads are ordered > before reads, writes before writes, and reads before writes, but not > writes before reads? Another approach would be to define a per-arch > barrier for this particular case. I suppose we can only introduce new barrier primitives if there's more than 1 use-case. > > If the read shows no available space, we simply will not issue those > > writes -- therefore we could argue we can avoid the memory barrier. > > Proving that means iterating through the permitted combinations of > compilers and architectures... There is always hand-coded assembly > language, I suppose. I'm starting to think that while the C/C++ language spec says they can wreck the world by doing these silly optimization, real world users will push back for breaking their existing code. I'm fairly sure the GCC people _will_ get shouted at _loudly_ when they break the kernel by doing crazy shit like that. Given its near impossible to write a correct program in C/C++ and tagging the entire kernel with __atomic is equally not going to happen, I think we must find a practical solution. Either that, or we really need to consider forking the language and compiler :-( -- 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] perf test: Update command line callchain attribute tests
From: Arnaldo Carvalho de Melo
The "struct perf_event_attr setup" entry in 'perf test' is in fact a
series of tests that will exec the tools, passing different sets of
command line arguments to then intercept the sys_perf_event_open
syscall, in user space, to check that the perf_event_attr->sample_type
and other feature request bits are setup as expected.
We recently restored the callchain requesting command line argument, -g,
to not require a parameter ("dwarf" or "fp"), instead using a default
("fp" for now) and making the long option variant, --call-chain, be the
one to be used when a different callchain collection method is
preferred.
The "struct perf_event_attr setup" test failed because we forgot to
update the tests involving callchains, not switching from, '-g dwarf' to
'--call-chain dwarf', making 'perf test' detect it:
[root@sandy ~]# perf test -v 13
13: struct perf_event_attr setup :
--- start ---
running '/home/acme/libexec/perf-core/tests/attr/test-record-basic'
running '/home/acme/libexec/perf-core/tests/attr/test-record-branch-any'
running '/home/acme/libexec/perf-core/tests/attr/test-record-graph-default'
running '/home/acme/libexec/perf-core/tests/attr/test-record-graph-dwarf'
expected sample_type=12583, got 295
expected exclude_callchain_user=1, got 0
expected sample_stack_user=8192, got 0
FAILED '/home/acme/libexec/perf-core/tests/attr/test-record-graph-dwarf' -
match failure
end
struct perf_event_attr setup: FAILED!
[root@sandy ~]#
Fix all of them now to use --call-chain when explicitely specifying a
method.
There is still work to do, as '-g fp', for instance, passed without
problems.
In that case 'perf test' saw no problems as the intercepted syscall got
the bits as expected, i.e. the default is 'fp', but the fact that 'fp'
may be an existing program and the specified workload would then be
passed as a parameter to it is an usability problem that needs fixing.
Next merge window tho.
Acked-by: Jiri Olsa
Cc: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/n/tip-jr3oq1k5iywnp7vvqlslz...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/tests/attr/README| 6 +++---
tools/perf/tests/attr/test-record-graph-default | 2 +-
tools/perf/tests/attr/test-record-graph-dwarf | 2 +-
tools/perf/tests/attr/test-record-graph-fp | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/perf/tests/attr/README b/tools/perf/tests/attr/README
index d102957cd59a..430024f618f1 100644
--- a/tools/perf/tests/attr/README
+++ b/tools/perf/tests/attr/README
@@ -44,9 +44,9 @@ Following tests are defined (with perf commands):
perf record -c 123 kill (test-record-count)
perf record -d kill (test-record-data)
perf record -F 100 kill (test-record-freq)
- perf record -g -- kill(test-record-graph-default)
- perf record -g dwarf -- kill (test-record-graph-dwarf)
- perf record -g fp kill(test-record-graph-fp)
+ perf record -g kill (test-record-graph-default)
+ perf record --call-graph dwarf kill (test-record-graph-dwarf)
+ perf record --call-graph fp kill (test-record-graph-fp)
perf record --group -e cycles,instructions kill (test-record-group)
perf record -e '{cycles,instructions}' kill (test-record-group1)
perf record -D kill (test-record-no-delay)
diff --git a/tools/perf/tests/attr/test-record-graph-default
b/tools/perf/tests/attr/test-record-graph-default
index 833d1849d767..853597a9a8f6 100644
--- a/tools/perf/tests/attr/test-record-graph-default
+++ b/tools/perf/tests/attr/test-record-graph-default
@@ -1,6 +1,6 @@
[config]
command = record
-args= -g -- kill >/dev/null 2>&1
+args= -g kill >/dev/null 2>&1
[event:base-record]
sample_type=295
diff --git a/tools/perf/tests/attr/test-record-graph-dwarf
b/tools/perf/tests/attr/test-record-graph-dwarf
index e93e082f5208..d6f324ea578c 100644
--- a/tools/perf/tests/attr/test-record-graph-dwarf
+++ b/tools/perf/tests/attr/test-record-graph-dwarf
@@ -1,6 +1,6 @@
[config]
command = record
-args= -g dwarf -- kill >/dev/null 2>&1
+args= --call-graph dwarf -- kill >/dev/null 2>&1
[event:base-record]
sample_type=12583
diff --git a/tools/perf/tests/attr/test-record-graph-fp
b/tools/perf/tests/attr/test-record-graph-fp
index 7cef3743f03f..055e3bee7993 100644
--- a/tools/perf/tests/attr/test-record-graph-fp
+++ b/tools/perf/tests/attr/test-record-graph-fp
@@ -1,6 +1,6 @@
[config]
command = record
-args= -g fp kill >/dev/null 2>&1
+args= --call-graph fp kill >/dev/null 2>&1
[event:base-record]
sample_type=295
--
1.8.1.4
--
To
[GIT PULL 0/3] perf/urgent fixes
From: Arnaldo Carvalho de Melo Hi Ingo, Please consider pulling, - Arnaldo The following changes since commit e8a923cc1fff6e627f906655ad52ee694ef2f6d7: perf/x86: Fix NMI measurements (2013-10-29 12:01:20 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux tags/perf-urgent-for-mingo for you to fetch changes up to 46d525eae2a076adfde92dca1db12d9a3b8ad8bb: perf test: Update command line callchain attribute tests (2013-11-01 10:42:57 -0300) perf/urgent fixes: . Fix command line callchain attribute tests to handle the new -g/--call-chain semantics. . Remove cast of non-variadic function to variadic, fixing perf output on armhf arch. Fix from Michael Hudson-Doyle. . Fix 32-bit building of 'perf bench', from Wei Yang. Signed-off-by: Arnaldo Carvalho de Melo Arnaldo Carvalho de Melo (1): perf test: Update command line callchain attribute tests Michael Hudson-Doyle (1): perf tools: Remove cast of non-variadic function to variadic Wei Yang (1): perf bench: Fix two warnings tools/perf/bench/numa.c | 4 ++-- tools/perf/tests/attr/README| 6 +++--- tools/perf/tests/attr/test-record-graph-default | 2 +- tools/perf/tests/attr/test-record-graph-dwarf | 2 +- tools/perf/tests/attr/test-record-graph-fp | 2 +- tools/perf/ui/hist.c| 2 +- tools/perf/util/color.c | 11 +-- tools/perf/util/color.h | 2 +- 8 files changed, 19 insertions(+), 12 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] perf bench: Fix two warnings
From: Wei Yang
There are two warnings in bench/numa, when building this on 32-bit
machine.
The warning output is attached:
bench/numa.c:1113:20: error: comparison between signed and unsigned integer
expressions [-Werror=sign-compare]
bench/numa.c:1161:6: error: format ‘%lx’ expects argument of t'long unsigned
int’, but argument 5 has type ‘u64’ [-Werror=format]
This patch fixes these two warnings.
Signed-off-by: Wei Yang
Acked-by: Ingo Molnar
Cc: Ingo Molnar
Link:
http://lkml.kernel.org/r/1379839764-9245-1-git-send-email-weiy...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/bench/numa.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/bench/numa.c b/tools/perf/bench/numa.c
index 30d1c3225b46..a73c4ed8af17 100644
--- a/tools/perf/bench/numa.c
+++ b/tools/perf/bench/numa.c
@@ -1110,7 +1110,7 @@ static void *worker_thread(void *__tdata)
/* Check whether our max runtime timed out: */
if (g->p.nr_secs) {
timersub(, , );
- if (diff.tv_sec >= g->p.nr_secs) {
+ if (diff.tv_sec >= (time_t)g->p.nr_secs) {
g->stop_work = true;
break;
}
@@ -1157,7 +1157,7 @@ static void *worker_thread(void *__tdata)
runtime_ns_max += diff.tv_usec * 1000;
if (details >= 0) {
- printf(" #%2d / %2d: %14.2lf nsecs/op [val:
%016lx]\n",
+ printf(" #%2d / %2d: %14.2lf nsecs/op [val:
%016"PRIu64"]\n",
process_nr, thread_nr, runtime_ns_max /
bytes_done, val);
}
fflush(stdout);
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] perf tools: Remove cast of non-variadic function to variadic
From: Michael Hudson-Doyle
The 4fb71074a570 (perf ui/hist: Consolidate hpp helpers) cset introduced
a cast of percent_color_snprintf to a function pointer type with
varargs. Change percent_color_snprintf to be variadic and remove the
cast.
The symptom of this was all percentages being reported as 0.00% in perf
report --stdio output on the armhf arch.
Signed-off-by: Michael Hudson-Doyle
Acked-by: Namhyung Kim
Acked-by: Will Deacon
Cc: Jean Pihet
Cc: Jiri Olsa
Cc: Will Deacon
Cc: sta...@vger.kernel.org
Link: http://lkml.kernel.org/r/87zjppvw7y@canonical.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/ui/hist.c| 2 +-
tools/perf/util/color.c | 11 +--
tools/perf/util/color.h | 2 +-
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
index 0a193281eba8..78f4c92e9b73 100644
--- a/tools/perf/ui/hist.c
+++ b/tools/perf/ui/hist.c
@@ -117,7 +117,7 @@ static int hpp__color_##_type(struct perf_hpp_fmt *fmt
__maybe_unused, \
struct perf_hpp *hpp, struct hist_entry *he)
\
{
\
return __hpp__fmt(hpp, he, he_get_##_field, " %6.2f%%",
\
- (hpp_snprint_fn)percent_color_snprintf, true);
\
+ percent_color_snprintf, true);
\
}
#define __HPP_ENTRY_PERCENT_FN(_type, _field)
\
diff --git a/tools/perf/util/color.c b/tools/perf/util/color.c
index 11e46da17bbb..66e44a5019d5 100644
--- a/tools/perf/util/color.c
+++ b/tools/perf/util/color.c
@@ -318,8 +318,15 @@ int percent_color_fprintf(FILE *fp, const char *fmt,
double percent)
return r;
}
-int percent_color_snprintf(char *bf, size_t size, const char *fmt, double
percent)
+int percent_color_snprintf(char *bf, size_t size, const char *fmt, ...)
{
- const char *color = get_percent_color(percent);
+ va_list args;
+ double percent;
+ const char *color;
+
+ va_start(args, fmt);
+ percent = va_arg(args, double);
+ va_end(args);
+ color = get_percent_color(percent);
return color_snprintf(bf, size, color, fmt, percent);
}
diff --git a/tools/perf/util/color.h b/tools/perf/util/color.h
index dea082b79602..fced3840e99c 100644
--- a/tools/perf/util/color.h
+++ b/tools/perf/util/color.h
@@ -39,7 +39,7 @@ int color_fprintf(FILE *fp, const char *color, const char
*fmt, ...);
int color_snprintf(char *bf, size_t size, const char *color, const char *fmt,
...);
int color_fprintf_ln(FILE *fp, const char *color, const char *fmt, ...);
int color_fwrite_lines(FILE *fp, const char *color, size_t count, const char
*buf);
-int percent_color_snprintf(char *bf, size_t size, const char *fmt, double
percent);
+int percent_color_snprintf(char *bf, size_t size, const char *fmt, ...);
int percent_color_fprintf(FILE *fp, const char *fmt, double percent);
const char *get_percent_color(double percent);
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] phy: Add MOXA RTL8201CP PHY support
The MOXA UC-711X hardware(s) has an ethernet controller that seem
to be developed internally. The IC used is "RTL8201CP".
This patch adds an MDIO driver and also patches realtek to include
RTL8201CP PHY driver.
Signed-off-by: Jonas Jensen
---
Notes:
The hardware does not use a separate IRQ for PHY.
The link state change interrupt can instead be caught by MAC but the
current drivers/of/of_mdio.c does not allow it to be handled in MAC.
Applies to next-20131031
.../devicetree/bindings/net/moxa,moxart-mdio.txt | 19 ++
drivers/net/phy/Kconfig| 7 +
drivers/net/phy/Makefile | 1 +
drivers/net/phy/mdio-moxart.c | 201 +
drivers/net/phy/realtek.c | 15 ++
5 files changed, 243 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/moxa,moxart-mdio.txt
create mode 100644 drivers/net/phy/mdio-moxart.c
diff --git a/Documentation/devicetree/bindings/net/moxa,moxart-mdio.txt
b/Documentation/devicetree/bindings/net/moxa,moxart-mdio.txt
new file mode 100644
index 000..de0b90c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/moxa,moxart-mdio.txt
@@ -0,0 +1,19 @@
+* MOXA ART MDIO Ethernet Controller interface
+
+Required properties:
+- compatible: should be "moxa,moxart-mdio".
+- reg: address and length of the register set for the device.
+
+Example:
+mdio1: mdio@9290 {
+ compatible = "moxa,moxart-mdio";
+ reg = <0x9290 0x8>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy1: ethernet-phy@1 {
+ device_type = "ethernet-phy";
+ compatible = "moxa,moxart-rtl8201cp";
+ reg = <1>;
+ };
+};
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 342561a..9b5d46c 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -154,6 +154,13 @@ config MDIO_SUN4I
interface units of the Allwinner SoC that have an EMAC (A10,
A12, A10s, etc.)
+config MDIO_MOXART
+tristate "MOXA ART MDIO interface support"
+depends on ARCH_MOXART
+help
+ This driver supports the MDIO interface found in the network
+ interface units of the MOXA ART SoC
+
config MDIO_BUS_MUX
tristate
depends on OF_MDIO
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 23a2ab2..9013dfa 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -31,3 +31,4 @@ obj-$(CONFIG_MDIO_BUS_MUX)+= mdio-mux.o
obj-$(CONFIG_MDIO_BUS_MUX_GPIO)+= mdio-mux-gpio.o
obj-$(CONFIG_MDIO_BUS_MUX_MMIOREG) += mdio-mux-mmioreg.o
obj-$(CONFIG_MDIO_SUN4I) += mdio-sun4i.o
+obj-$(CONFIG_MDIO_MOXART) += mdio-moxart.o
diff --git a/drivers/net/phy/mdio-moxart.c b/drivers/net/phy/mdio-moxart.c
new file mode 100644
index 000..ad5d0f8
--- /dev/null
+++ b/drivers/net/phy/mdio-moxart.c
@@ -0,0 +1,201 @@
+/* MOXA ART Ethernet (RTL8201CP) MDIO interface driver
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define REG_PHY_CTRL0
+#define REG_PHY_WRITE_DATA 4
+
+/* REG_PHY_CTRL */
+#define MIIWR BIT(27) /* init write sequence (auto cleared)*/
+#define MIIRD BIT(26)
+#define REGAD_MASK 0x3e0
+#define PHYAD_MASK 0x1f
+#define MIIRDATA_MASK 0x
+
+/* REG_PHY_WRITE_DATA */
+#define MIIWDATA_MASK 0x
+
+struct moxart_mdio_data {
+ void __iomem*base;
+};
+
+static int moxart_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
+{
+ struct moxart_mdio_data *data = bus->priv;
+ u32 ctrl = 0;
+ unsigned int count = 5;
+
+ dev_dbg(>dev, "%s\n", __func__);
+
+ ctrl |= MIIRD | ((mii_id << 16) & PHYAD_MASK) |
+ ((regnum << 21) & REGAD_MASK);
+
+ writel(ctrl, data->base + REG_PHY_CTRL);
+
+ do {
+ ctrl = readl(data->base + REG_PHY_CTRL);
+
+ if (!(ctrl & MIIRD))
+ return ctrl & MIIRDATA_MASK;
+
+ mdelay(10);
+ count--;
+ } while (count > 0);
+
+ dev_err(>dev, "%s timed out\n", __func__);
+
+ return -ETIMEDOUT;
+}
+
+static int moxart_mdio_write(struct mii_bus *bus, int mii_id,
+int regnum, u16 value)
+{
+ struct moxart_mdio_data *data = bus->priv;
+ u32 ctrl = 0;
+ unsigned int count = 5;
+
+ dev_dbg(>dev, "%s\n", __func__);
+
+ ctrl |= MIIWR | ((mii_id << 16) & PHYAD_MASK) |
+ ((regnum << 21) & REGAD_MASK);
+
+ value &=
Re: scsi-mq + open-iscsi support patches..?
On 10/28/13 5:03 PM, Nicholas A. Bellinger wrote: Hi Mike, Just curious as to the status of the scsi-mq conversion patches for open-iscsi that you where working on a while back..? I'm asking because recently I've been spending alot of time with scsi-mq + virtio-scsi, and would really to start banging on iser-target ports using an scsi-mq enabled iser-initiator as well.. So that said, are there any blockers holding things up towards getting a working prototype..? Just time. Just finished a release at work and just got back from vacation so hoping to work on this some more in the next weeks. On a related note, some iscsi vendor has been hitting a crash with your tree. Have you rebased it it to take in Christoph's changes and fixes that are in Jens's tree? The code here https://git.kernel.org/cgit/linux/kernel/git/nab/target-pending.git/log/?h=scsi-mq looks ok. That is the current code right? -- 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] USB: storage: use sg_miter_* APIs to access scsi buffer
On Wed, 30 Oct 2013, Ming Lei wrote:
> We have sg_miter_* APIs for accessing scsi sg buffer, so
> use them to make code clean and bug free.
Hmmm. You could simply call sg_copy_buffer, if you didn't mind the
quadratic penalty for the sg_miter_skip operations.
> --- a/drivers/usb/storage/protocol.c
> +++ b/drivers/usb/storage/protocol.c
> @@ -135,69 +135,43 @@ unsigned int usb_stor_access_xfer_buf(unsigned char
> *buffer,
> unsigned int buflen, struct scsi_cmnd *srb, struct scatterlist **sgptr,
> unsigned int *offset, enum xfer_buf_dir dir)
> {
> - unsigned int cnt;
> + unsigned int cnt = 0;
> struct scatterlist *sg = *sgptr;
> + struct sg_mapping_iter miter;
> + unsigned int nents = scsi_sg_count(srb);
>
> - /* We have to go through the list one entry
> - * at a time. Each s-g entry contains some number of pages, and
> - * each page has to be kmap()'ed separately. If the page is already
> - * in kernel-addressable memory then kmap() will return its address.
> - * If the page is not directly accessible -- such as a user buffer
> - * located in high memory -- then kmap() will map it to a temporary
> - * position in the kernel's virtual address space.
> - */
> -
> - if (!sg)
> + if (sg)
> + nents -= sg - scsi_sglist(srb);
This is definitely wrong. Scatterlist entries are not always stored in
a linear array. To do this properly, you would have to make the caller
keep track of the current value of nents.
Or better yet, have the caller store and pass the sg_mapping_iter
structure rather than sgptr and offset.
> + else
> sg = scsi_sglist(srb);
>
> - /* This loop handles a single s-g list entry, which may
> - * include multiple pages. Find the initial page structure
> - * and the starting offset within the page, and update
> - * the *offset and **sgptr values for the next loop.
> - */
> - cnt = 0;
> - while (cnt < buflen && sg) {
> - struct page *page = sg_page(sg) +
> - ((sg->offset + *offset) >> PAGE_SHIFT);
> - unsigned int poff = (sg->offset + *offset) & (PAGE_SIZE-1);
> - unsigned int sglen = sg->length - *offset;
> -
> - if (sglen > buflen - cnt) {
> -
> - /* Transfer ends within this s-g entry */
> - sglen = buflen - cnt;
> - *offset += sglen;
> - } else {
> + if (dir == FROM_XFER_BUF)
> + sg_miter_start(, sg, nents, SG_MITER_FROM_SG);
> + else
> + sg_miter_start(, sg, nents, SG_MITER_TO_SG);
I find this style somewhat annoying. Maybe the compiler is smart
enough to optimize it, maybe not. In any case, I would prefer to see
if (dir == FROM_XFER_BUF)
sgdir = SG_MITER_FROM_SG;
else
sgdir = SG_MITER_TO_SG;
sg_miter_start(, nents, sgdir);
Or even:
sg_miter_start(, nents, (dir == FROM_XFER_BUF ?
SG_MITER_FROM_SG : SG_MITER_TO_SG));
> - /* Transfer continues to next s-g entry */
> - *offset = 0;
> - sg = sg_next(sg);
> - }
> + if (!sg_miter_skip(, *offset))
> + return cnt;
> +
> + while (sg_miter_next() && cnt < buflen) {
> + unsigned int len = min(miter.length, buflen - cnt);
> +
> + if (dir == FROM_XFER_BUF)
> + memcpy(buffer + cnt, miter.addr, len);
> + else
> + memcpy(miter.addr, buffer + cnt, len);
>
> - /* Transfer the data for all the pages in this
> - * s-g entry. For each page: call kmap(), do the
> - * transfer, and call kunmap() immediately after. */
> - while (sglen > 0) {
> - unsigned int plen = min(sglen, (unsigned int)
> - PAGE_SIZE - poff);
> - unsigned char *ptr = kmap(page);
> -
> - if (dir == TO_XFER_BUF)
> - memcpy(ptr + poff, buffer + cnt, plen);
> - else
> - memcpy(buffer + cnt, ptr + poff, plen);
> - kunmap(page);
> -
> - /* Start at the beginning of the next page */
> - poff = 0;
> - ++page;
> - cnt += plen;
> - sglen -= plen;
> + if (*offset + len < miter.piter.sg->length) {
> + *offset += len;
> + *sgptr = miter.piter.sg;
> + } else {
> + *offset = 0;
> + *sgptr = sg_next(miter.piter.sg);
> }
> + cnt += len;
> }
> - *sgptr = sg;
> + sg_miter_stop();
>
> - /* Return the amount actually
Re: [PATCH -v2 -tip] fix race between stop_two_cpus and stop_cpus
On 11/01/2013 10:47 AM, Mel Gorman wrote: > On Fri, Nov 01, 2013 at 10:41:46AM -0400, Rik van Riel wrote: >> Subject: fix race between stop_two_cpus and stop_cpus >> >> There is a race between stop_two_cpus, and the global stop_cpus. >> >> It is possible for two CPUs to get their stopper functions queued >> "backwards" from one another, resulting in the stopper threads >> getting stuck, and the system hanging. This can happen because >> queuing up stoppers is not synchronized. >> >> This patch adds synchronization between stop_cpus (a rare operation), >> and stop_two_cpus. >> >> Signed-off-by: Rik van Riel >> --- >> v2: use lglock, as suggested by Peter & Mel, thanks to both of you >> for insisting on nicer code :) >> > > This is a tad more comprehensible :). Thanks! > > Acked-by: Mel Gorman I'll test for a few hours and get back to everyone by the end of the day. P. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -v2 -tip] fix race between stop_two_cpus and stop_cpus
On Fri, Nov 01, 2013 at 10:41:46AM -0400, Rik van Riel wrote: > Subject: fix race between stop_two_cpus and stop_cpus > > There is a race between stop_two_cpus, and the global stop_cpus. > > It is possible for two CPUs to get their stopper functions queued > "backwards" from one another, resulting in the stopper threads > getting stuck, and the system hanging. This can happen because > queuing up stoppers is not synchronized. > > This patch adds synchronization between stop_cpus (a rare operation), > and stop_two_cpus. > > Signed-off-by: Rik van Riel > --- > v2: use lglock, as suggested by Peter & Mel, thanks to both of you > for insisting on nicer code :) > This is a tad more comprehensible :). Thanks! Acked-by: Mel Gorman -- Mel Gorman 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/
[PATCH -v2 -tip] fix race between stop_two_cpus and stop_cpus
Subject: fix race between stop_two_cpus and stop_cpus
There is a race between stop_two_cpus, and the global stop_cpus.
It is possible for two CPUs to get their stopper functions queued
"backwards" from one another, resulting in the stopper threads
getting stuck, and the system hanging. This can happen because
queuing up stoppers is not synchronized.
This patch adds synchronization between stop_cpus (a rare operation),
and stop_two_cpus.
Signed-off-by: Rik van Riel
---
v2: use lglock, as suggested by Peter & Mel, thanks to both of you
for insisting on nicer code :)
kernel/stop_machine.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index 32a6c44..c5c1af1 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
/*
* Structure to determine completion condition and record errors. May
@@ -43,6 +44,14 @@ static DEFINE_PER_CPU(struct cpu_stopper, cpu_stopper);
static DEFINE_PER_CPU(struct task_struct *, cpu_stopper_task);
static bool stop_machine_initialized = false;
+/*
+ * Avoids a race between stop_two_cpus and global stop_cpus, where
+ * the stoppers could get queued up in reverse order, leading to
+ * system deadlock. Using an lglock means stop_two_cpus remains
+ * relatively cheap.
+ */
+DEFINE_STATIC_LGLOCK(stop_cpus_lock);
+
static void cpu_stop_init_done(struct cpu_stop_done *done, unsigned int
nr_todo)
{
memset(done, 0, sizeof(*done));
@@ -268,8 +277,10 @@ int stop_two_cpus(unsigned int cpu1, unsigned int cpu2,
cpu_stop_fn_t fn, void *
*/
call_cpu = min(cpu1, cpu2);
+ lg_local_lock(_cpus_lock);
smp_call_function_single(call_cpu, _cpu_stop_queue_work,
_args, 0);
+ lg_local_unlock(_cpus_lock);
wait_for_completion();
return done.executed ? done.ret : -ENOENT;
@@ -319,10 +330,10 @@ static void queue_stop_cpus_work(const struct cpumask
*cpumask,
* preempted by a stopper which might wait for other stoppers
* to enter @fn which can lead to deadlock.
*/
- preempt_disable();
+ lg_global_lock(_cpus_lock);
for_each_cpu(cpu, cpumask)
cpu_stop_queue_work(cpu, _cpu(stop_cpus_work, cpu));
- preempt_enable();
+ lg_global_unlock(_cpus_lock);
}
static int __stop_cpus(const struct cpumask *cpumask,
--
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] mm: add strictlimit knob
"strictlimit" feature was introduced to enforce per-bdi dirty limits for
FUSE which sets bdi max_ratio to 1% by default:
http://www.http.com//article.gmane.org/gmane.linux.kernel.mm/105809
However the feature can be useful for other relatively slow or untrusted
BDIs like USB flash drives and DVD+RW. The patch adds a knob to enable the
feature:
echo 1 > /sys/class/bdi/X:Y/strictlimit
Being enabled, the feature enforces bdi max_ratio limit even if global (10%)
dirty limit is not reached. Of course, the effect is not visible until
max_ratio is decreased to some reasonable value.
Signed-off-by: Maxim Patlasov
---
mm/backing-dev.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/mm/backing-dev.c b/mm/backing-dev.c
index ce682f7..4ee1d64 100644
--- a/mm/backing-dev.c
+++ b/mm/backing-dev.c
@@ -234,11 +234,46 @@ static ssize_t stable_pages_required_show(struct device
*dev,
}
static DEVICE_ATTR_RO(stable_pages_required);
+static ssize_t strictlimit_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct backing_dev_info *bdi = dev_get_drvdata(dev);
+ unsigned int val;
+ ssize_t ret;
+
+ ret = kstrtouint(buf, 10, );
+ if (ret < 0)
+ return ret;
+
+ switch (val) {
+ case 0:
+ bdi->capabilities &= ~BDI_CAP_STRICTLIMIT;
+ break;
+ case 1:
+ bdi->capabilities |= BDI_CAP_STRICTLIMIT;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return count;
+}
+static ssize_t strictlimit_show(struct device *dev,
+ struct device_attribute *attr, char *page)
+{
+ struct backing_dev_info *bdi = dev_get_drvdata(dev);
+
+ return snprintf(page, PAGE_SIZE-1, "%d\n",
+ !!(bdi->capabilities & BDI_CAP_STRICTLIMIT));
+}
+static DEVICE_ATTR_RW(strictlimit);
+
static struct attribute *bdi_dev_attrs[] = {
_attr_read_ahead_kb.attr,
_attr_min_ratio.attr,
_attr_max_ratio.attr,
_attr_stable_pages_required.attr,
+ _attr_strictlimit.attr,
NULL,
};
ATTRIBUTE_GROUPS(bdi_dev);
--
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/
