Re: [PATCH] Repeated fork() causes SLAB to grow without bound
On Wed, Nov 19, 2014 at 7:09 PM, Vlastimil Babka wrote: > On 11/19/2014 03:36 PM, Konstantin Khlebnikov wrote: >> On Wed, Nov 19, 2014 at 2:50 AM, Vlastimil Babka wrote: >>> On 11/19/2014 12:02 AM, Konstantin Khlebnikov wrote: On Wed, Nov 19, 2014 at 1:15 AM, Konstantin Khlebnikov wrote: > On Tue, Nov 18, 2014 at 11:19 PM, Andrew Morton > wrote: >> On Mon, 17 Nov 2014 21:41:57 -0500 Rik van Riel wrote: >> >>> > Because of the serial forking there does indeed end up being an >>> > infinite number of vmas. The initial vma can never be deleted >>> > (even though the initial parent process has long since terminated) >>> > because the initial vma is referenced by the children. >>> >>> There is a finite number of VMAs, but an infite number of >>> anon_vmas. >>> >>> Subtle, yet deadly... >> >> Well, we clearly have the data structures screwed up. I've forgotten >> enough about this code for me to be unable to work out what the fixed >> up data structures would look like :( But surely there is some proper >> solution here. Help? > > Not sure if it's right but probably we could reuse on fork an old anon_vma > from the chain if it's already lost all vmas which points to it. > For endlessly forking exploit this should work mostly like proposed patch > which stops branching after some depth but without magic constant. Something like this. I leave proper comment for tomorrow. >>> >>> Hmm I'm not sure that will work as it is. If I understand it correctly, your >>> patch can detect if the parent's anon_vma has no own references at the >>> fork() >>> time. But at the fork time, the parent is still alive, it only exits after >>> the >>> fork, right? So I guess it still has own references and the child will still >>> allocate its new anon_vma, and the problem is not solved. >> >> But it could reuse anon_vma from grandparent or older. >> Count of anon_vmas in chain will be limited with count of alive processes. > > Ah I missed that it can reuse older anon_vma, sorry. > >> I think it's better to describe this in terms of sets of anon_vma >> instead hierarchy: >> at clone vma inherits pages from parent together with set of anon_vma >> which they belong. >> For new pages it might allocate new anon_vma or reuse existing. After >> my patch vma >> will try to reuse anon_vma from that set which has no vmas which points to >> it. >> As a result there will be no parent-child relation between anon_vma and >> multiple pages might have equal (anon_vma, index) pair but I see no >> problems here. > > Hmm I wonder if root anon_vma should be excluded from this reusal. For > performance reasons, exclusive pages go to non-root anon_vma (see > __page_set_anon_rmap()) and reusing root anon_vma would change this. This is simple, in my patch this can be reached by bumping its nr_vmas by one and it'll never be reused. > Also from reading http://lwn.net/Articles/383162/ I understand that > correctness > also depends on the hierarchy and I wonder if there's a danger of > reintroducing > a bug like the one described there. If I remember right that was fixed by linking non-exclusively mapped pages to root anon_vma instead of anon_vma from vma where fault has happened. After my patch this still works. Topology hierarchy actually isn't used. Here just one selected "root' anon_vma which dies last. That's all. > > Vlastimil > >>> >>> So maybe we could detect that the own references dropped to zero when the >>> parent >>> does exit, and then change mapping of all relevant pages to the root >>> anon_vma, >>> destroy avc's of children and the anon_vma itself. But that sounds quite >>> heavyweight :/ >>> >>> Vlastimil >>> > >> >>> >> >> -- >> To unsubscribe, send a message with 'unsubscribe linux-mm' in >> the body to majord...@kvack.org. For more info on Linux MM, >> see: http://www.linux-mm.org/ . >> Don't email: mailto:"d...@kvack.org;> em...@kvack.org >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Looking for good references for ARM driver development
On 11/19/2014 06:20 PM, Mason wrote: > Hello everyone, > > I've been using several Linux distributions, and writing user-space programs, > for 15 years. > I recently seized an opportunity to move into kernel development, mainly > writing drivers > for an ARM SoC, and I'm finding the transition harder than I expected. > > I'm having a hard time finding good reference material to bring me up to > speed on the ins > and outs of driver development. Sure, I found Documentation/driver-model > (eventually) but > I'm still missing the high-level overview that ties everything together, and > makes my > brain click and "get it". > > Many years ago, I read LDD2 and it was an eye-opener. We do have LDD3 at > work, but it is > now almost 10 years old, and it doesn't document things like the platform > bus, or the "new" > driver model, or hwmon, or cpufreq, or device tree, to name a few things on > my plate. > (I'm writing drivers for the 3.14 kernel.) > > http://www.xml.com/ldd/chapter/book/ > http://www.makelinux.net/ldd3/ > > Are there more recent technical references, as good as LDD3, that cover > "modern" aspects > of kernel development? The LDD3 is one of the best there is. A fourth edition is suppose to come out sometime next year. http://www.amazon.com/Linux-Device-Drivers-Jessica-McKellar/dp/1449371612 > > I've read good things about: > > "Writing Linux Device Drivers: a guide with exercises" > by Jerry Cooperstein (2009) > originally written for 2.6.31, updated for 3.3 > http://www.coopj.com/ > > What do kernel devs recommend as the worthy successor to LDD3? > > > To wrap up this (long) message, I'd like to post some of my questions, to > highlight some > of my confusion. I'm writing a driver for a temperature sensor, which is > supposed to work > within the hwmon/lm-sensors framework. > > The sensor's API consists of 3 memory-mapped registers, which are accessible > over the > SoC's memory bus. I first wrote a user-space proof-of-concept to interact > with the > sensors, accessing them through /dev/mem O_SYNC + mmap. That works as > expected, and > I now have the code to read the temperature when needed. > > Next, I looked at the driver glue required to use these sensors from > lm-sensors. > That's where my troubles started. > > 1) Which bus should I be using for this driver? Is the platform bus > appropriate? > > 2) platform.txt states > >> Some drivers are not fully converted to the driver model, because they take >> on a non-driver role: the driver registers its platform device, rather than >> leaving that for system infrastructure. Such drivers can't be hotplugged >> or coldplugged, since those mechanisms require device creation to be in a >> different system component than the driver. > > How do I "leave device registration for the system infrastructure"? > Where should I put that code? > Is it a good idea to separate device registration and driver registration > in the case of a SoC, where the device is embedded in the SoC and is not > "hot-plugged" (or anything-plugged for that matter, it's just "there"). For understanding this you need to understand how the platform infrastructure works and why is it used. http://lwn.net/Articles/448499/ http://lwn.net/Articles/448502/ and go through some of the relevant drivers. > > 3) Why is the function used to "destroy a platform device" named > platform_device_put? Why put? > Put on a list of things to destroy at a later time? This should be more clear once you go through LDD3. > > 4) Can I use platform_driver_probe, instead of platform_driver_register? > The comments in platform.c state: >> /** >> * platform_driver_probe - register driver for non-hotpluggable device >> * @drv: platform driver structure >> * @probe: the driver probe routine, probably from an __init section >> * >> * Use this instead of platform_driver_register() when you know the device >> * is not hotpluggable and has already been registered, and you want to >> * remove its run-once probe() infrastructure from memory after the driver >> * has bound to the device. >> * >> * One typical use for this would be with drivers for controllers integrated >> * into system-on-chip processors, where the controller devices have been >> * configured as part of board setup. >> * >> * Note that this is incompatible with deferred probing. >> * >> * Returns zero if the driver registered and bound to a device, else returns >> * a negative error code and with the driver not registered. >> */ > > AFAICT, I need to answer question 2 before I can answer this one. > How do I get "devices have been configured as part of board setup."? This actually depends on the kernel you are using. Do you have relatively new kernel or an old one? Depending on that, either you will get that information in a board file or else in the device tree in arch/arm/boot/dts. > > 5) Very hwmon-specific, how often are temperature sensors probed? > Does the frequency vary? (Through
Re: [PATCH 1/2] tracing: Clean up tracing_fill_pipe_page()
On Wed 2014-11-19 11:17:18, Steven Rostedt wrote:
> On Tue, 18 Nov 2014 17:15:46 +0100
> Petr Mladek wrote:
>
> > On Mon 2014-11-17 14:11:08, Steven Rostedt wrote:
> > > >
> > > > I don't like the fact that I did a code structure change with this
> > > > patch. This patch should be just a simple conversion of len to
> > > > seq_buf_used(). I'm going to strip this change out and put it before
> > > > this patch.
> > >
> > >
> > > The function tracing_fill_pipe_page() logic is a little confusing with the
> > > use of count saving the seq.len and reusing it.
> > >
> > > Instead of subtracting a number that is calculated from the saved
> > > value of the seq.len from seq.len, just save the seq.len at the start
> > > and if we need to reset it, just assign it again.
> > >
> > > When the seq_buf overflow is len == size + 1, the current logic will
> > > break. Changing it to use a saved length for resetting back to the
> > > original value is more robust and will work when we change the way
> > > seq_buf sets the overflow.
> > >
> > > Signed-off-by: Steven Rostedt
> > > ---
> > > kernel/trace/trace.c | 26 --
> > > 1 file changed, 20 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> > > index 7d7a07e9b9e9..2dbc18e5f929 100644
> > > --- a/kernel/trace/trace.c
> > > +++ b/kernel/trace/trace.c
> > > @@ -4575,23 +4575,37 @@ static size_t
> > > tracing_fill_pipe_page(size_t rem, struct trace_iterator *iter)
> > > {
> > > size_t count;
> > > + int save_len;
> > > int ret;
> > >
> > > /* Seq buffer is page-sized, exactly what we need. */
> > > for (;;) {
> > > - count = iter->seq.seq.len;
> > > + save_len = iter->seq.seq.len;
> > > ret = print_trace_line(iter);
> > > - count = iter->seq.seq.len - count;
> > > - if (rem < count) {
> > > - rem = 0;
> > > - iter->seq.seq.len -= count;
> > > +
> > > + if (trace_seq_has_overflowed(>seq)) {
> > > + iter->seq.seq.len = save_len;
> > > break;
> > > }
> > > +
> > > + /*
> > > + * This should not be hit, because it should only
> > > + * be set if the iter->seq overflowed. But check it
> > > + * anyway to be safe.
> > > + */
> > > if (ret == TRACE_TYPE_PARTIAL_LINE) {
> > > - iter->seq.seq.len -= count;
> > > + iter->seq.seq.len = save_len;
> > > break;
> > > }
> >
> > The two ifs has the same body. Small optimization would be to do:
> >
> > /*
> > * The two checks should be equivalent but rather be
> > * on the safe side.
> > */
> > if (trace_seq_has_overflowed(>seq) ||
> > ret == TRACE_TYPE_PARTIAL_LINE) {
> > iter->seq.seq.len = save_len;
> > break;
> > }
>
> Yeah, I originally had something like that, but I wanted to remove that
> second check. I left it separate to make it stand out as something that
> might be removed in the future. Just a preference I guess.
Fair enough.
> > To be honest, the code seems to be a bit twisted. This function
> > is called from tracing_splice_read_pipe(). It copies the
> > trace_seq buffer into spd.page and call trace_seq_init()
> > in a for cycle.
>
> Yeah, that splice code confused me too. I'll start looking at it some
> more and see if it can be fixed up.
>
> >
> > Therefore if the overflow happens, trace_find_next_entry_inc()
> > is not called in tracing_fill_pipe_page() and we work with the same
> > iterator instance next time. It means that the overflow happens most
> > likely again and we fill all remaining spd.pages with no data and
> > are stacked on the same iterator instance.
>
> Luckily, overflows never happen. But if they do, things might break.
I thought so. :-)
> >
> > BTW: The trace_seq_to_buffer() in tracing_splice_read_pipe()
> > is suspicious as well. It passes trace_seq_used(>seq)
> > as the "cnt" parameter. I guess that it should pass the
> > size of the "spd.page" instead.
>
> Wow, I should have looked harder at that code when I accepted it. It
> just "worked" and I was happy. Oh well, another thing to fix up.
>
> >
> > Also we should somehow handle the situation when some data are not
> > copied. Well, it seems the spd.page has the page size, so it is
> > the same size as the trace_seq buffer.
> >
> >
> > Well, this patch does not change the behavior. We could solve the
> > above problem later if it is there. Maybe I got it wrong.
>
> No, that code doesn't look too good. That's some old stuff that got in
> when we were still learning, and if it worked, we added it ;-)
>
> That needs to be cleaned up. I'll put it on my ever growing todo
> list.
I believe. I am a bit scared to put it on my todo list because these
kind of working things tend to
Re: [PATCH RFC] ARM: option for loading modules into vmalloc area
On Wed, 19 Nov 2014, Russell King - ARM Linux wrote: > On Wed, Nov 19, 2014 at 11:37:47AM -0500, Nicolas Pitre wrote: > > On Wed, 19 Nov 2014, Russell King - ARM Linux wrote: > > > Which is not a good idea either, because the compiler needs to know how > > > far away its own manually generated literal pool is from the instructions > > > which reference it. The .ltorg statement can end up emitting any number > > > of literals at that point, which makes it indeterminant how many words > > > are contained within the asm() statement. > > > > > > Yes, it isn't desirable to waste an entire data cache line per indirect > > > call like the original quote above, but I don't see a practical > > > alternative. > > > > Modules could be built without far calls by default, and then the module > > linker would only have to redirect those calls whose destination is too > > far away to a dynamically created trampoline table. > > > > If I remember correctly you even posted some patches to that effect a > > couple years ago. Maybe those could be salvaged? > > I don't think I ever did, because its pretty much impossible to do as I > explained in a follow up to this thread. > > We _used_ to do this with the userspace insmod methods, but since we got > this kernel-side linker, it's been pretty much impossible to do without > rewriting the module code. That's not going to happen on account of one > quirky architecture which Linus doesn't particularly like. Still... We could try adding a hook in the generic module linker code for a pre-relocation pass. Maybe only ARM would use it, but if the need to load big modules is real then I imagine Linus could be amenable to a compromise. Nicolas -- 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/1] DRM-vmwgfx: Deletion of an unnecessary check before the function call "vfree"
From: Markus Elfring
Date: Wed, 19 Nov 2014 17:50:19 +0100
The vfree() function performes also input parameter validation. Thus the test
around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 14b2f50..f9a67b8 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -889,8 +889,7 @@ static int vmw_driver_unload(struct drm_device *dev)
if (dev_priv->ctx.res_ht_initialized)
drm_ht_remove(_priv->ctx.res_ht);
- if (dev_priv->ctx.cmd_bounce)
- vfree(dev_priv->ctx.cmd_bounce);
+ vfree(dev_priv->ctx.cmd_bounce);
if (dev_priv->enable_fb) {
vmw_fb_close(dev_priv);
vmw_kms_restore_vga(dev_priv);
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] ARM: option for loading modules into vmalloc area
On Wed, Nov 19, 2014 at 05:38:57PM +0100, Ard Biesheuvel wrote: > Numbers are disambiguated by the f and b suffixes, so they can be > reused in the same .s file. So as long as you use a strictly numerical > prefix, you can deal correctly with the case where, for instance, > do_div() is called twice in the same compilation unit, and still not > clash with other inline asm What's not particularly nice though is to hide these in a macro, which itself may be part of a larger macro or code fragment also using small numbers. We probably ought to be a bit more inteligent about how we choose these numbers inside macros, rather than just randomly picking some and hoping that they don't clash. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] at91: dt for 3.19 #2
Arnd, Olof, Kevin, Another DT pull-request for 3.19. For this one, I had to pull one Vinod's topic branch to be able to include the XDMA DT properties. This branch is stable and based on 3.18-rc3 (Cf. http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/304041.html). Note that my previous DT pull-request for 3.19 was based on 3.18-rc2. So, this is what I did: - took a v3.18-rc3 tag - merged the at91-3.19-dt branch that you already have in at91/dt (you'd taken the at91-dt tag) - merged the topic/at_xdmac from Vinod - stacked the new material described above on top of this. Tell me if it's okay for you or if I have to arrange things differently. The content itself is pretty straightforward. Thanks, best regards, The following changes since commit 51f46e5bc326972f623cad7ac9dadc3cf8159203: Merge branch 'topic/at_xdmac' of git://git.infradead.org/users/vkoul/slave-dma into at91-3.19-dt2 (2014-11-19 12:11:30 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git tags/at91-dt2 for you to fetch changes up to accda2736fcab10fc3eb35da935e0e049188f6d5: ARM: at91/dt: at91sam9g45: add ISI node (2014-11-19 15:55:17 +0100) Second DT batch for 3.19: - some trivial fixes: macro for IRQ, license wording - DMA description for sama5d4 - RTT as RTC driver definition plus associated GPBR for several SoCs - addition of missing nodes: rtc for at91sam9rl, isi for at91sam9g45 Alexandre Belloni (1): ARM: at91/dt: at91sam9rl: add rtc Boris Brezillon (5): ARM: at91/dt: add RTT nodes to at91 dtsis ARM: at91/dt: add GPBR nodes ARM: at91/dt: enable the RTT block on the sam9g20ek board ARM: at91/dt: enable the RTT block on the at91sam9m10g45ek board ARM: at91/dt: at91sam9g45: add ISI node Ludovic Desroches (2): ARM: at91/dt: sama5d4: use macro instead of numeric value ARM: at91/dt: sama5d4: add DMA support Nicolas Ferre (1): ARM: at91: fix GPLv2 wording arch/arm/boot/dts/at91-sama5d4ek.dts| 4 +- arch/arm/boot/dts/at91sam9260.dtsi | 14 ++ arch/arm/boot/dts/at91sam9261.dtsi | 14 ++ arch/arm/boot/dts/at91sam9263.dtsi | 21 arch/arm/boot/dts/at91sam9g20ek_common.dtsi | 14 ++ arch/arm/boot/dts/at91sam9g45.dtsi | 46 ++ arch/arm/boot/dts/at91sam9m10g45ek.dts | 9 arch/arm/boot/dts/at91sam9rl.dtsi | 21 arch/arm/boot/dts/sama5d4.dtsi | 75 +++-- 9 files changed, 213 insertions(+), 5 deletions(-) -- Nicolas Ferre -- 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 1/3] mfd: arizona: Add support for CS47L24
On Tue, 11 Nov 2014, Richard Fitzgerald wrote:
> Signed-off-by: Richard Fitzgerald
> ---
> drivers/mfd/Kconfig |6 +
> drivers/mfd/Makefile |3 +
> drivers/mfd/arizona-core.c | 91 ++-
> drivers/mfd/arizona-irq.c| 42 +-
> drivers/mfd/arizona-spi.c|9 +
> drivers/mfd/arizona.h|5 +
> drivers/mfd/cs47l24-tables.c | 1632
> ++
> include/linux/mfd/arizona/core.h |4 +
> 8 files changed, 1765 insertions(+), 27 deletions(-)
> create mode 100644 drivers/mfd/cs47l24-tables.c
This patch looks okay.
Acked-by: Lee Jones
I guess you need a re-spin though.
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index abef204..f9bf242 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1247,6 +1247,12 @@ config MFD_WM8997
> help
> Support for Wolfson Microelectronics WM8997 low power audio SoC
>
> +config MFD_CS47L24
> + bool "Cirrus Logic CS47L24"
> + depends on MFD_ARIZONA
> + help
> + Support for Cirrus Logic CS47L24 low power audio SoC
> +
> config MFD_WM8400
> bool "Wolfson Microelectronics WM8400"
> select MFD_CORE
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 24e7d68..dd5f656 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -50,6 +50,9 @@ endif
> ifneq ($(CONFIG_MFD_WM8997),n)
> obj-$(CONFIG_MFD_ARIZONA)+= wm8997-tables.o
> endif
> +ifneq ($(CONFIG_MFD_CS47L24),n)
> +obj-$(CONFIG_MFD_ARIZONA)+= cs47l24-tables.o
> +endif
> obj-$(CONFIG_MFD_WM8400) += wm8400-core.o
> wm831x-objs := wm831x-core.o wm831x-irq.o wm831x-otp.o
> wm831x-objs += wm831x-auxadc.o
> diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
> index bce7c07..9cc40f0 100644
> --- a/drivers/mfd/arizona-core.c
> +++ b/drivers/mfd/arizona-core.c
> @@ -1,6 +1,7 @@
> /*
> * Arizona core driver
> *
> + * Copyright 2014 CirrusLogic, Inc.
> * Copyright 2012 Wolfson Microelectronics plc
> *
> * Author: Mark Brown
> @@ -347,6 +348,9 @@ static int arizona_runtime_resume(struct device *dev)
> regcache_cache_only(arizona->regmap, false);
>
> switch (arizona->type) {
> + case WM1831:
> + case CS47L24:
> + break;
> case WM5102:
> if (arizona->external_dcvdd) {
> ret = regmap_update_bits(arizona->regmap,
> @@ -415,14 +419,20 @@ static int arizona_runtime_suspend(struct device *dev)
> dev_dbg(arizona->dev, "Entering AoD mode\n");
>
> if (arizona->external_dcvdd) {
> - ret = regmap_update_bits(arizona->regmap,
> - ARIZONA_ISOLATION_CONTROL,
> - ARIZONA_ISOLATE_DCVDD1,
> - ARIZONA_ISOLATE_DCVDD1);
> - if (ret != 0) {
> - dev_err(arizona->dev, "Failed to isolate DCVDD: %d\n",
> - ret);
> - return ret;
> + switch (arizona->type) {
> + case WM1831:
> + case CS47L24:
> + break;
> + default:
> + ret = regmap_update_bits(arizona->regmap,
> + ARIZONA_ISOLATION_CONTROL,
> + ARIZONA_ISOLATE_DCVDD1,
> + ARIZONA_ISOLATE_DCVDD1);
> + if (ret != 0) {
> + dev_err(arizona->dev,
> + "Failed to isolate DCVDD: %d\n", ret);
> + return ret;
> + }
> }
> }
>
> @@ -568,6 +578,8 @@ const struct of_device_id arizona_of_match[] = {
> { .compatible = "wlf,wm5102", .data = (void *)WM5102 },
> { .compatible = "wlf,wm5110", .data = (void *)WM5110 },
> { .compatible = "wlf,wm8997", .data = (void *)WM8997 },
> + { .compatible = "wlf,wm1831", .data = (void *)WM1831 },
> + { .compatible = "cirrus,cs47l24", .data = (void *)CS47L24 },
> {},
> };
> EXPORT_SYMBOL_GPL(arizona_of_match);
> @@ -649,6 +661,23 @@ static const struct mfd_cell wm8997_devs[] = {
> },
> };
>
> +static const char *cs47l24_supplies[] = {
> + "MICVDD",
> + "CPVDD",
> + "SPKVDD",
> +};
> +
> +static const struct mfd_cell cs47l24_devs[] = {
> + { .name = "arizona-gpio" },
> + { .name = "arizona-haptics" },
> + { .name = "arizona-pwm" },
> + {
> + .name = "cs47l24-codec",
> + .parent_supplies = cs47l24_supplies,
> + .num_parent_supplies = ARRAY_SIZE(cs47l24_supplies),
> + },
> +};
> +
> int arizona_dev_init(struct arizona *arizona)
> {
> struct device *dev = arizona->dev;
> @@ -672,6 +701,8 @@ int arizona_dev_init(struct arizona *arizona)
>
Re: [PATCH 1/3] tun: move internal flag defines out of uapi
On Wed, Nov 19, 2014 at 10:47:14AM -0600, Dan Williams wrote:
> On Wed, 2014-11-19 at 18:18 +0200, Michael S. Tsirkin wrote:
> > TUN_ flags are internal and never exposed
> > to userspace. Any application using it is almost
> > certainly buggy.
>
> Except for TUN_TUN_DEV and TUN_TAP_DEV and TUN_TYPE_MASK... which we're
> using (for some reason) in NetworkManager, though I'll happily convert
> those to IFF_* instead. It might be worth #defining those to their
> IFF_* equivalents since their usage is not technically broken.
>
> Dan
Hmm you are right, they happen to have the same value.
I'll send v2 leaving these in place.
> > Move them out to tun.c, we'll remove them in follow-up patches.
> > Signed-off-by: Michael S. Tsirkin
> > ---
> > include/uapi/linux/if_tun.h | 14 --
> > drivers/net/tun.c | 14 ++
> > 2 files changed, 14 insertions(+), 14 deletions(-)
> >
> > diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
> > index e9502dd..b82c276 100644
> > --- a/include/uapi/linux/if_tun.h
> > +++ b/include/uapi/linux/if_tun.h
> > @@ -23,20 +23,6 @@
> > /* Read queue size */
> > #define TUN_READQ_SIZE 500
> >
> > -/* TUN device flags */
> > -#define TUN_TUN_DEV0x0001
> > -#define TUN_TAP_DEV0x0002
> > -#define TUN_TYPE_MASK 0x000f
> > -
> > -#define TUN_FASYNC 0x0010
> > -#define TUN_NOCHECKSUM 0x0020
> > -#define TUN_NO_PI 0x0040
> > -/* This flag has no real effect */
> > -#define TUN_ONE_QUEUE 0x0080
> > -#define TUN_PERSIST0x0100
> > -#define TUN_VNET_HDR 0x0200
> > -#define TUN_TAP_MQ 0x0400
> > -
> > /* Ioctl defines */
> > #define TUNSETNOCSUM _IOW('T', 200, int)
> > #define TUNSETDEBUG _IOW('T', 201, int)
> > diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> > index 2e18ddd..81735f5 100644
> > --- a/drivers/net/tun.c
> > +++ b/drivers/net/tun.c
> > @@ -103,6 +103,20 @@ do {
> > \
> > } while (0)
> > #endif
> >
> > +/* TUN device flags */
> > +#define TUN_TUN_DEV0x0001
> > +#define TUN_TAP_DEV0x0002
> > +#define TUN_TYPE_MASK 0x000f
> > +
> > +#define TUN_FASYNC 0x0010
> > +#define TUN_NOCHECKSUM 0x0020
> > +#define TUN_NO_PI 0x0040
> > +/* This flag has no real effect */
> > +#define TUN_ONE_QUEUE 0x0080
> > +#define TUN_PERSIST0x0100
> > +#define TUN_VNET_HDR 0x0200
> > +#define TUN_TAP_MQ 0x0400
> > +
> > #define GOODCOPY_LEN 128
> >
> > #define FLT_EXACT_COUNT 8
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] ARM: option for loading modules into vmalloc area
On Wed, Nov 19, 2014 at 11:37:47AM -0500, Nicolas Pitre wrote: > On Wed, 19 Nov 2014, Russell King - ARM Linux wrote: > > Which is not a good idea either, because the compiler needs to know how > > far away its own manually generated literal pool is from the instructions > > which reference it. The .ltorg statement can end up emitting any number > > of literals at that point, which makes it indeterminant how many words > > are contained within the asm() statement. > > > > Yes, it isn't desirable to waste an entire data cache line per indirect > > call like the original quote above, but I don't see a practical > > alternative. > > Modules could be built without far calls by default, and then the module > linker would only have to redirect those calls whose destination is too > far away to a dynamically created trampoline table. > > If I remember correctly you even posted some patches to that effect a > couple years ago. Maybe those could be salvaged? I don't think I ever did, because its pretty much impossible to do as I explained in a follow up to this thread. We _used_ to do this with the userspace insmod methods, but since we got this kernel-side linker, it's been pretty much impossible to do without rewriting the module code. That's not going to happen on account of one quirky architecture which Linus doesn't particularly like. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- 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 1/1] net: sched: Deletion of an unnecessary check before the function call "kfree"
On 11/18/2014 12:26 PM, SF Markus Elfring wrote: From: Markus Elfring Date: Tue, 18 Nov 2014 21:21:16 +0100 The kfree() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- net/sched/cls_bpf.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/net/sched/cls_bpf.c b/net/sched/cls_bpf.c index 0e30d58..f323944 100644 --- a/net/sched/cls_bpf.c +++ b/net/sched/cls_bpf.c @@ -212,8 +212,7 @@ static int cls_bpf_modify_existing(struct net *net, struct tcf_proto *tp, if (fp_old) bpf_prog_destroy(fp_old); - if (bpf_old) - kfree(bpf_old); + kfree(bpf_old); return 0; Maybe I need some coffee but I can't figure out what this patch is against... # grep bpf_old ./net/sched/cls_bpf.c # Marcus, what tree are you looking at? -- John Fastabend Intel Corporation -- 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 1/3] tun: move internal flag defines out of uapi
On Wed, 2014-11-19 at 18:18 +0200, Michael S. Tsirkin wrote:
> TUN_ flags are internal and never exposed
> to userspace. Any application using it is almost
> certainly buggy.
Except for TUN_TUN_DEV and TUN_TAP_DEV and TUN_TYPE_MASK... which we're
using (for some reason) in NetworkManager, though I'll happily convert
those to IFF_* instead. It might be worth #defining those to their
IFF_* equivalents since their usage is not technically broken.
Dan
> Move them out to tun.c, we'll remove them in follow-up patches.
> Signed-off-by: Michael S. Tsirkin
> ---
> include/uapi/linux/if_tun.h | 14 --
> drivers/net/tun.c | 14 ++
> 2 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
> index e9502dd..b82c276 100644
> --- a/include/uapi/linux/if_tun.h
> +++ b/include/uapi/linux/if_tun.h
> @@ -23,20 +23,6 @@
> /* Read queue size */
> #define TUN_READQ_SIZE 500
>
> -/* TUN device flags */
> -#define TUN_TUN_DEV 0x0001
> -#define TUN_TAP_DEV 0x0002
> -#define TUN_TYPE_MASK 0x000f
> -
> -#define TUN_FASYNC 0x0010
> -#define TUN_NOCHECKSUM 0x0020
> -#define TUN_NO_PI0x0040
> -/* This flag has no real effect */
> -#define TUN_ONE_QUEUE0x0080
> -#define TUN_PERSIST 0x0100
> -#define TUN_VNET_HDR 0x0200
> -#define TUN_TAP_MQ 0x0400
> -
> /* Ioctl defines */
> #define TUNSETNOCSUM _IOW('T', 200, int)
> #define TUNSETDEBUG _IOW('T', 201, int)
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 2e18ddd..81735f5 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -103,6 +103,20 @@ do {
> \
> } while (0)
> #endif
>
> +/* TUN device flags */
> +#define TUN_TUN_DEV 0x0001
> +#define TUN_TAP_DEV 0x0002
> +#define TUN_TYPE_MASK 0x000f
> +
> +#define TUN_FASYNC 0x0010
> +#define TUN_NOCHECKSUM 0x0020
> +#define TUN_NO_PI0x0040
> +/* This flag has no real effect */
> +#define TUN_ONE_QUEUE0x0080
> +#define TUN_PERSIST 0x0100
> +#define TUN_VNET_HDR 0x0200
> +#define TUN_TAP_MQ 0x0400
> +
> #define GOODCOPY_LEN 128
>
> #define FLT_EXACT_COUNT 8
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2] HID: i2c-hid: fix race condition reading reports
From: Jean-Baptiste Maneyrol
Current driver uses a common buffer for reading reports either
synchronously in i2c_hid_get_raw_report() and asynchronously in
the interrupt handler.
There is race condition if an interrupt arrives immediately after
the report is received in i2c_hid_get_raw_report(); the common
buffer is modified by the interrupt handler with the new report
and then i2c_hid_get_raw_report() proceed using wrong data.
Fix it by using a separate buffers for synchronous reports.
Signed-off-by: Jean-Baptiste Maneyrol
[Antonio Borneo: cleanup, rebase to v3.17, submit mainline]
Signed-off-by: Antonio Borneo
Cc: sta...@vger.kernel.org
---
V1 -> V2
rename the synchronous buffer as rawbuf (instead of the
asynchronous one)
drivers/hid/i2c-hid/i2c-hid.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
index 933bf10..c66e6ac 100644
--- a/drivers/hid/i2c-hid/i2c-hid.c
+++ b/drivers/hid/i2c-hid/i2c-hid.c
@@ -137,6 +137,7 @@ struct i2c_hid {
* descriptor. */
unsigned intbufsize;/* i2c buffer size */
char*inbuf; /* Input buffer */
+ char*rawbuf;/* Raw Input buffer */
char*cmdbuf;/* Command buffer */
char*argsbuf; /* Command arguments buffer */
@@ -504,9 +505,11 @@ static void i2c_hid_find_max_report(struct hid_device
*hid, unsigned int type,
static void i2c_hid_free_buffers(struct i2c_hid *ihid)
{
kfree(ihid->inbuf);
+ kfree(ihid->rawbuf);
kfree(ihid->argsbuf);
kfree(ihid->cmdbuf);
ihid->inbuf = NULL;
+ ihid->rawbuf = NULL;
ihid->cmdbuf = NULL;
ihid->argsbuf = NULL;
ihid->bufsize = 0;
@@ -522,10 +525,11 @@ static int i2c_hid_alloc_buffers(struct i2c_hid *ihid,
size_t report_size)
report_size; /* report */
ihid->inbuf = kzalloc(report_size, GFP_KERNEL);
+ ihid->rawbuf = kzalloc(report_size, GFP_KERNEL);
ihid->argsbuf = kzalloc(args_len, GFP_KERNEL);
ihid->cmdbuf = kzalloc(sizeof(union command) + args_len, GFP_KERNEL);
- if (!ihid->inbuf || !ihid->argsbuf || !ihid->cmdbuf) {
+ if (!ihid->inbuf || !ihid->rawbuf || !ihid->argsbuf || !ihid->cmdbuf) {
i2c_hid_free_buffers(ihid);
return -ENOMEM;
}
@@ -552,12 +556,12 @@ static int i2c_hid_get_raw_report(struct hid_device *hid,
ret = i2c_hid_get_report(client,
report_type == HID_FEATURE_REPORT ? 0x03 : 0x01,
- report_number, ihid->inbuf, ask_count);
+ report_number, ihid->rawbuf, ask_count);
if (ret < 0)
return ret;
- ret_count = ihid->inbuf[0] | (ihid->inbuf[1] << 8);
+ ret_count = ihid->rawbuf[0] | (ihid->rawbuf[1] << 8);
if (ret_count <= 2)
return 0;
@@ -566,7 +570,7 @@ static int i2c_hid_get_raw_report(struct hid_device *hid,
/* The query buffer contains the size, dropping it in the reply */
count = min(count, ret_count - 2);
- memcpy(buf, ihid->inbuf + 2, count);
+ memcpy(buf, ihid->rawbuf + 2, count);
return count;
}
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] tracing: Use trace_seq_used() and seq_buf_used() instead of len
On Wed 2014-11-19 11:00:37, Steven Rostedt wrote: > On Wed, 19 Nov 2014 15:40:05 +0100 > Petr Mladek wrote: > > > > Regardless of overflow or not (or even if trace_seq is full), that if > > > statement will prevent this from doing any buffer overflows. > > > > > > s->seq.len will never be more than s->seq.size after the test against > > > TRACE_MAX_PRINT. So I see no harm here. > > > > Ah, I see. Well, I would feel more comfortable if it uses > > trace_seq_used() or if there is some explanation in a comment. > > But you are right, it is safe as it is. Feel free to leave it. > > > > OK, I added this just for you: > > BTW, using trace_seq_used() would not be good enough because it could > return s->seq.size. Which would overflow the buffer on the > > s->buffer[s->seq.len] = 0; Great catch! > -- Steve > > From 1922acc9987d23d0b9c1ad28dc3eaafc1cf2d6b7 Mon Sep 17 00:00:00 2001 > From: "Steven Rostedt (Red Hat)" > Date: Wed, 19 Nov 2014 10:56:41 -0500 > Subject: [PATCH] tracing: Add paranoid size check in trace_printk_seq() > > To be really paranoid about writing out of bound data in > trace_printk_seq(), add another check of len compared to size. > > Link: http://lkml.kernel.org/r/20141119144004.gb2...@dhcp128.suse.cz > > Suggested-by: Petr Mladek > Signed-off-by: Steven Rostedt Reviewed-by: Petr Mladek Thanks a lot for the addition. Best Regards, Petr > --- > kernel/trace/trace.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c > index 9023446b2c2b..26facec4625e 100644 > --- a/kernel/trace/trace.c > +++ b/kernel/trace/trace.c > @@ -6656,6 +6656,14 @@ trace_printk_seq(struct trace_seq *s) > if (s->seq.len >= TRACE_MAX_PRINT) > s->seq.len = TRACE_MAX_PRINT; > > + /* > + * More paranoid code. Although the buffer size is set to > + * PAGE_SIZE, and TRACE_MAX_PRINT is 1000, this is just > + * an extra layer of protection. > + */ > + if (WARN_ON_ONCE(s->seq.len >= s->seq.size)) > + s->seq.len = s->seq.size - 1; > + > /* should be zero ended, but we are paranoid. */ > s->buffer[s->seq.len] = 0; > > -- > 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/
Re: [PATCH] driver: input: touchscreen: add Raydium i2c touchscreen driver
On 11/19/2014 04:30 PM, jeffrey.lin wrote: > From: "jeffrey.lin" > > this patch is porting Raydium I2C touch driver. Developer can enable > raydium touch driver by modifying define "CONFIG_TOUCHSCREEN_RM_TS". > > BUG: None > TEST: built and test with peppy > > Signed-off-by: jeffrey@rad-ic.com > Change-Id: I05d54e5ef29249d2a6eae97222c90bed11e839f9 > --- Just some general remarks that IMO need to be addressed before a more thorough review can happen: * Please remove all dead code, such as code in comments and in #if 0 blocks. * Use the regmap framework to abstract the hardware access on the I2C layer (see drivers/input/keyboard/cap1106.c and many other drivers as an example, and check include/linux/regmap.h). That makes the code a lot shorter and more comprehensible to read. * By using request_threaded_irq(), you don't have to manually control your worker and can simplify your code quite a bit. * See if you can claim all the resources the driver needs by using devm_* variants. * Don't use uppercase names for filenames, structs, functions and IDs * Why do you need a miscdevice for this? Isn't the input event layer enough? * Also, run scripts/checkpatch.pl on the new patch, which will help you find some more typical pitfalls. Thanks, Daniel > drivers/input/touchscreen/Kconfig | 12 + > drivers/input/touchscreen/Makefile | 1 + > drivers/input/touchscreen/RM31100.c | 972 > > include/linux/input/RM31100.h | 60 +++ > 4 files changed, 1045 insertions(+) > create mode 100644 drivers/input/touchscreen/RM31100.c > create mode 100644 include/linux/input/RM31100.h > > diff --git a/drivers/input/touchscreen/Kconfig > b/drivers/input/touchscreen/Kconfig > index 3ce9181..b692036 100644 > --- a/drivers/input/touchscreen/Kconfig > +++ b/drivers/input/touchscreen/Kconfig > @@ -98,6 +98,18 @@ config TOUCHSCREEN_ATMEL_MXT > To compile this driver as a module, choose M here: the > module will be called atmel_mxt_ts. > > +config TOUCHSCREEN_RM_TS > + tristate "Raydium I2C Touchscreen" > + depends on I2C > + help > + Say Y here if you have Raydium series I2C touchscreen, > + such as RM31100 , connected to your system. > + > + If unsure, say N. > + > + To compile this driver as a module, choose M here: the > + module will be called RM31100. > + > config TOUCHSCREEN_AUO_PIXCIR > tristate "AUO in-cell touchscreen using Pixcir ICs" > depends on I2C > diff --git a/drivers/input/touchscreen/Makefile > b/drivers/input/touchscreen/Makefile > index 687d5a7..d991815 100644 > --- a/drivers/input/touchscreen/Makefile > +++ b/drivers/input/touchscreen/Makefile > @@ -73,6 +73,7 @@ wm97xx-ts-$(CONFIG_TOUCHSCREEN_WM9705) += wm9705.o > wm97xx-ts-$(CONFIG_TOUCHSCREEN_WM9712) += wm9712.o > wm97xx-ts-$(CONFIG_TOUCHSCREEN_WM9713) += wm9713.o > obj-$(CONFIG_TOUCHSCREEN_WM97XX_ATMEL) += atmel-wm97xx.o > +obj-$(CONFIG_TOUCHSCREEN_RM_TS) += RM31100.o > obj-$(CONFIG_TOUCHSCREEN_WM97XX_MAINSTONE) += mainstone-wm97xx.o > obj-$(CONFIG_TOUCHSCREEN_WM97XX_ZYLONITE)+= zylonite-wm97xx.o > obj-$(CONFIG_TOUCHSCREEN_W90X900)+= w90p910_ts.o > diff --git a/drivers/input/touchscreen/RM31100.c > b/drivers/input/touchscreen/RM31100.c > new file mode 100644 > index 000..78cc80d > --- /dev/null > +++ b/drivers/input/touchscreen/RM31100.c > @@ -0,0 +1,972 @@ > +/* Source for: > + * Raydium RM31100 Prototype touchscreen driver. > + * drivers/input/touchscreen/RM31100.c > + * > + * Copyright (C) 2012, > + * > + * 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. > + * > + * Raydium reserves the right to make changes without further notice > + * to the materials described herein. Raydium does not assume any > + * liability arising out of the application described herein. > + * > + * Contact Raydium Semiconductor Corporation at www.rad-ic.com > + * > + * History: > + * (C) 2012 Raydium - Update for GPL distribution > + * (C) 2009 Enea - Original prototype > + * > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +/*#include */ > +#include > +/*#include copy_to_user() */ > +#include > + > + > +#if 0/*defined(CONFIG_HAS_EARLYSUSPEND)*/ > +#include > + > +/* Early-suspend level */ > +#define RM31100_TS_SUSPEND_LEVEL 1 > +#endif > + > +#define RM31100
Re: [PATCHv2 3/5] clk: s2mps11: Add the support for S2MPS13 PMIC clock
On Tue, 18 Nov 2014, Mike Turquette wrote:
> Quoting Chanwoo Choi (2014-11-18 00:59:41)
> > This patch adds the support for S2MPS13 PMIC clock which is same with
> > existing
> > S2MPS14 RTC IP. But, S2MPS13 uses all of clocks (32khz_{ap|bt|cp}).
> >
> > Cc: Mike Turquette
> > Signed-off-by: Chanwoo Choi
> > Reviewed-by: Krzysztof Kozlowski
>
> Applied to clk-next.
I'm pretty sure you can't do that. You have a dependency on
linux/mfd/samsung/s2mps13.h, which is satisfied in one of the earlier
patches in the set. If you'd care to just provide an Ack for this
patch, I can send you a pull-request with the decencies met.
> > ---
> > drivers/clk/clk-s2mps11.c | 24
> > 1 file changed, 24 insertions(+)
> >
> > diff --git a/drivers/clk/clk-s2mps11.c b/drivers/clk/clk-s2mps11.c
> > index b7797fb..7bb13af 100644
> > --- a/drivers/clk/clk-s2mps11.c
> > +++ b/drivers/clk/clk-s2mps11.c
> > @@ -23,6 +23,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -120,6 +121,24 @@ static struct clk_init_data
> > s2mps11_clks_init[S2MPS11_CLKS_NUM] = {
> > },
> > };
> >
> > +static struct clk_init_data s2mps13_clks_init[S2MPS11_CLKS_NUM] = {
> > + [S2MPS11_CLK_AP] = {
> > + .name = "s2mps13_ap",
> > + .ops = _clk_ops,
> > + .flags = CLK_IS_ROOT,
> > + },
> > + [S2MPS11_CLK_CP] = {
> > + .name = "s2mps13_cp",
> > + .ops = _clk_ops,
> > + .flags = CLK_IS_ROOT,
> > + },
> > + [S2MPS11_CLK_BT] = {
> > + .name = "s2mps13_bt",
> > + .ops = _clk_ops,
> > + .flags = CLK_IS_ROOT,
> > + },
> > +};
> > +
> > static struct clk_init_data s2mps14_clks_init[S2MPS11_CLKS_NUM] = {
> > [S2MPS11_CLK_AP] = {
> > .name = "s2mps14_ap",
> > @@ -184,6 +203,10 @@ static int s2mps11_clk_probe(struct platform_device
> > *pdev)
> > s2mps11_reg = S2MPS11_REG_RTC_CTRL;
> > clks_init = s2mps11_clks_init;
> > break;
> > + case S2MPS13X:
> > + s2mps11_reg = S2MPS13_REG_RTCCTRL;
> > + clks_init = s2mps13_clks_init;
> > + break;
> > case S2MPS14X:
> > s2mps11_reg = S2MPS14_REG_RTCCTRL;
> > clks_init = s2mps14_clks_init;
> > @@ -279,6 +302,7 @@ static int s2mps11_clk_remove(struct platform_device
> > *pdev)
> >
> > static const struct platform_device_id s2mps11_clk_id[] = {
> > { "s2mps11-clk", S2MPS11X},
> > + { "s2mps13-clk", S2MPS13X},
> > { "s2mps14-clk", S2MPS14X},
> > { "s5m8767-clk", S5M8767X},
> > { },
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] ARM: option for loading modules into vmalloc area
On Wed, Nov 19, 2014 at 05:25:41PM +0100, Ard Biesheuvel wrote: > On 19 November 2014 17:07, Russell King - ARM Linux > wrote: > > On Wed, Nov 19, 2014 at 05:02:40PM +0100, Ard Biesheuvel wrote: > > Which is not a good idea either, because the compiler needs to know how > > far away its own manually generated literal pool is from the instructions > > which reference it. The .ltorg statement can end up emitting any number > > of literals at that point, which makes it indeterminant how many words > > are contained within the asm() statement. > > > > That applies to any inline asm statement in general: the compiler > assumes that the expanded size will not interfere with its ability to > emit literals after the function's return instruction. > Sometimes it will put a literal pool in the middle of the function if > it is very large, and I am not sure if an inline asm by itself would > ever trigger that heuristic to kick in. The compiler works it out by counting the number of assembler delimiters (iow, semicolons or newlines) in the asm() statement, and using that to track how many instructions are present. > > Yes, it isn't desirable to waste an entire data cache line per indirect > > call like the original quote above, but I don't see a practical > > alternative. > > We could at least add some labels instead of doing explicit pc arithmetic, > i.e., > > adr lr, 1f > ldr pc, 0f > 0: .long symbol > 1: Yes, but this doesn't get away from the performance impact of having one word used in a D-cache line scattered throughout the code. This is the reason why I never looked at this as a serious option for kernel modules, and decided to put the kernel modules below the kernel itself instead. In older kernels, when we had the linking done by userspace insmod, I was able to be much more clever in this regard - I was able to detect which relocations were out of range, and I generated trampolines for each such symbol. What this relied upon was being able to parse the relocations before allocating module space, so we knew what the maximum size of trampolines needed for a particular module would be. We don't have that luxury with the current approach - the earliest we get to see the module is after the module space has been allocated, and the module has been copied to that module. That leaves no room to extend the allocation for the trampolines. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- 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 08/16] PCI: Introduce pci_scan_host_bridge() and pci_host_info
On Wed, Nov 19, 2014 at 02:09:12AM +, Yijing Wang wrote:
> >> struct pci_host_bridge *pci_create_host_bridge(
> >> - struct device *parent, u32 db,
> >> - struct pci_ops *ops, void *sysdata,
> >> - struct list_head *resources)
> >> + struct device *parent, u32 db, struct pci_ops *ops,
> >> + struct pci_host_info *info)
> >> {
> >>int error;
> >>struct pci_bus *b;
> >>struct pci_host_bridge *host, *h;
> >> - struct pci_host_bridge_window *window, *n;
> >>
> >>down_read(_host_bridge_sem);
> >>list_for_each_entry(h, _host_bridge_list, list) {
> >> @@ -53,7 +51,7 @@ struct pci_host_bridge *pci_create_host_bridge(
> >>if (!host)
> >>return NULL;
> >>
> >> - host->sysdata = sysdata;
> >> + host->sysdata = info->arg;
> >>host->busnum = PCI_BUSNUM(db);
> >>host->domain = PCI_DOMAIN(db);
> >>host->ops = ops;
> >> @@ -63,18 +61,23 @@ struct pci_host_bridge *pci_create_host_bridge(
> >>
> >>/* this is hack, just for build, will be removed later*/
> >
> > Why do you need this hack? Just for calling pci_domain_nr() ?
>
> Yes, it's temporary code, we need domain number here for pci host bridge
> register.
>
> >
> >>b = kzalloc(sizeof(*b), GFP_KERNEL);
> >> - b->sysdata = sysdata;
> >> + b->sysdata = host->sysdata;
> >>pci_bus_assign_domain_nr(b, parent);
> >>host->domain = pci_domain_nr(b);
> >> + kfree(b);
> >>
> ...
> >> +static int pci_default_init_res(struct pci_host_bridge *host,
> >> + struct pci_host_info *info)
> >> +{
> >> + struct pci_host_bridge_window *window, *n;
> >> +
> >> + if (info->res_type != PCI_HOST_RES_DEFAULT)
> >> + list_for_each_entry_safe(window, n, info->resources,
> >> + list)
> >> + list_move_tail(>list, >windows);
> >> + else
> >> + info->res_type = PCI_HOST_RES_DEFAULT;
> >
> > I'm confused about this assignment. Isn't this a nop as the else part
> > means info->res_type *is* PCI_HOST_RES_DEFAULT?
>
> No, in this patch, host drivers pass a pci host bridge resources init hook
> in pci_host_info *info, and we call this info->init_res() in
> pci_create_host_bridge().
>
> +struct pci_host_info {
> + u8 res_type;
> + void *arg;
> + struct list_head *resources; /*just for build, will clean up later */
> + int (*init_res)(struct pci_host_bridge *host,
> + struct pci_host_info *info);
> +};
> +
That's not what I've asked! Your code does:
if (info->res_type != PCI_HOST_RES_DEFAULT)
else /* info->res_type == PCI_HOST_RES_DEFAULT)
info->res_type = PCI_HOST_RES_DEFAULT;
info->res_type is already == PCI_HOST_RES_DEFAULT in the else side, assignment
is a NOP?
>
> >
> >> +
> >> + return 0;
> >> +}
> ...
> >> @@ -2038,8 +2057,13 @@ struct pci_bus *pci_scan_root_bus(struct device
> >> *parent, u32 db,
> >>bool found = false;
> >>struct pci_host_bridge *host;
> >>int max;
> >> + struct pci_host_info info;
> >> +
> >> + info.arg = sysdata;
> >> + info.resources = resources;
> >> + info.init_res = pci_default_init_res;
> >
> > I have mixed feelings about this patch. While it is heading in the right
> > direction
> > of moving pci_host_bridge relevant information towards the right user, I
> > don't think
> > you picked up the right set to move. The resource list is going to be
> > copied into
> > internal pci_host_bridge list anyway, keeping another copy is not helpful
> > *and*
> > you have increased the code size.
> >
> > I think for now we should aim to get the *missing* data into
> > pci_host_bridge: MSI
> > controllers and PCI domain/segment. Then we can do more cleanup.
>
> Hi Liviu, I agree with you here, the changes to resources stuff seems not a
> perfect
> solution. In my patch 6, we could pass pci domain nr by u32
> PCI_DOMBUS(domain, bus) argument,
> and store it in pci_host_bridge. For msi controller, we couldn't save the
> msi_controller
> in pci_host_bridge. Before we assume one pci host bridge only had one
> msi_controller,
> but now something changes, Jiang introduce hierarchy irq domain in x86, and
> now
> one pci host bridge may has more than one msi_controller. So I prefer to add a
> function to pci_host_bridge something like
>
> struct msi_controller *pci_get_msi_controller(struct pci_dev *dev)
Yes, good idea.
>
> >
> >>
> >> - host = pci_create_host_bridge(parent, db, ops, sysdata, resources);
> >> + host = pci_create_host_bridge(parent, db, ops, );
> >>if (!host)
> >>return NULL;
> >>
> >> @@ -2070,6 +2094,47 @@ struct pci_bus *pci_scan_root_bus(struct device
> >> *parent, u32 db,
> >> }
> >> EXPORT_SYMBOL(pci_scan_root_bus);
> >>
> >> +struct pci_host_bridge *pci_scan_host_bridge(
> >> + struct device *parent, u32 db, struct pci_ops *ops,
> >> + struct pci_host_info *info)
> >> +{
> >> + struct
Re: [PATCH RFC] ARM: option for loading modules into vmalloc area
On 19 November 2014 17:37, Nicolas Pitre wrote: > On Wed, 19 Nov 2014, Russell King - ARM Linux wrote: > >> On Wed, Nov 19, 2014 at 05:02:40PM +0100, Ard Biesheuvel wrote: >> > On 19 November 2014 16:52, Konstantin Khlebnikov wrote: >> > > Do you mean ldr pc, =symbol ? >> > > >> > > In this case I get this error: >> > > >> > > /tmp/ccAHtONU.s: Assembler messages: >> > > /tmp/ccAHtONU.s:220: Error: invalid literal constant: pool needs to be >> > > closer >> > > >> > > Probably constant pool doesn't work well in inline assembly. >> > > >> > > >> > > Something like this seems work: >> > > >> > > add lr, pc, #4 >> > > ldr pc, [pc, #-4] >> > > .long symbol >> > > >> > >> > You can add a '.ltorg' instruction which tells the assembler to dump >> > the literal pool, but you still need to jump over it, i.e., >> > >> > adr lr, 0f >> > ldr pc, =symbol >> > .ltorg >> > 0: >> >> Which is not a good idea either, because the compiler needs to know how >> far away its own manually generated literal pool is from the instructions >> which reference it. The .ltorg statement can end up emitting any number >> of literals at that point, which makes it indeterminant how many words >> are contained within the asm() statement. >> >> Yes, it isn't desirable to waste an entire data cache line per indirect >> call like the original quote above, but I don't see a practical >> alternative. > > Modules could be built without far calls by default, and then the module > linker would only have to redirect those calls whose destination is too > far away to a dynamically created trampoline table. > > If I remember correctly you even posted some patches to that effect a > couple years ago. Maybe those could be salvaged? > > I would largely recommend a solution where the link process could deal > with it automatically and as needed rather than sprinkling yet more > manually maintained macros into assembly code. > Yes, that would be preferable. I played around with 'bl symbol@PLT' instead of plain 'bl symbol' but unfortunately, our .ko's are not proper ELF shared libraries, so that doesn't work. But essentially, we just need a (eager) PLT. -- Ard. -- 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 1/1] EDAC: Deletion of unnecessary checks before the function call "pci_dev_put"
On Wed, Nov 19, 2014 at 04:06:53PM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Wed, 19 Nov 2014 16:00:13 +0100 > > The pci_dev_put() function tests whether its argument is NULL and then > returns immediately. Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring Applied, thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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] thermal: sti: Ignore suspend/resume functions when !PM
On Wed, 19 Nov 2014, Fabio Estevam wrote: > On Wed, Nov 19, 2014 at 1:50 PM, Lee Jones wrote: > > Prevents build warning: > > > > st_thermal.c:278:12: > > warning: ‘st_thermal_suspend’ defined but not used [-Wunused-function] > > st_thermal.c:286:12: > > warning: ‘st_thermal_resume’ defined but not used [-Wunused-function] > > > > Signed-off-by: Lee Jones > > --- > > > > v1 => v2: > > - CONFIG_PM => CONFIG_PM_SLEEP suggested by David Paris. > > You should also update the Subject to 'when !PM_SLEEP' I guess we should, yes. Zhang, Eduardo, Are you happy to do that, or would you like me to re-spin again? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] ARM: option for loading modules into vmalloc area
On 19 November 2014 17:32, Konstantin Khlebnikov wrote: > On Wed, Nov 19, 2014 at 7:25 PM, Ard Biesheuvel > wrote: >> On 19 November 2014 17:07, Russell King - ARM Linux >> wrote: >>> On Wed, Nov 19, 2014 at 05:02:40PM +0100, Ard Biesheuvel wrote: On 19 November 2014 16:52, Konstantin Khlebnikov wrote: > Do you mean ldr pc, =symbol ? > > In this case I get this error: > > /tmp/ccAHtONU.s: Assembler messages: > /tmp/ccAHtONU.s:220: Error: invalid literal constant: pool needs to be > closer > > Probably constant pool doesn't work well in inline assembly. > > > Something like this seems work: > > add lr, pc, #4 > ldr pc, [pc, #-4] > .long symbol > You can add a '.ltorg' instruction which tells the assembler to dump the literal pool, but you still need to jump over it, i.e., adr lr, 0f ldr pc, =symbol .ltorg 0: >>> >>> Which is not a good idea either, because the compiler needs to know how >>> far away its own manually generated literal pool is from the instructions >>> which reference it. The .ltorg statement can end up emitting any number >>> of literals at that point, which makes it indeterminant how many words >>> are contained within the asm() statement. >>> >> >> That applies to any inline asm statement in general: the compiler >> assumes that the expanded size will not interfere with its ability to >> emit literals after the function's return instruction. >> Sometimes it will put a literal pool in the middle of the function if >> it is very large, and I am not sure if an inline asm by itself would >> ever trigger that heuristic to kick in. >> >> But by the same logic, i.e., due to the fact that GCC manages its own >> literals, the literal pool at the assembly level is unlikely to be so >> large that you will actually hit this condition. >> >>> Yes, it isn't desirable to waste an entire data cache line per indirect >>> call like the original quote above, but I don't see a practical >>> alternative. >>> >> >> We could at least add some labels instead of doing explicit pc arithmetic, >> i.e., >> >> adr lr, 1f >> ldr pc, 0f >> 0: .long symbol >> 1: > > I think we need some unique prefix here, this macro is used inside > bigger inline assembly constructions and probably another macro. Numbers are disambiguated by the f and b suffixes, so they can be reused in the same .s file. So as long as you use a strictly numerical prefix, you can deal correctly with the case where, for instance, do_div() is called twice in the same compilation unit, and still not clash with other inline asm -- Ard. -- 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/1] DRM-UDL: Deletion of an unnecessary check before the function call "vunmap"
From: Markus Elfring Date: Wed, 19 Nov 2014 17:33:32 +0100 The vunmap() function performes also input parameter validation. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/gpu/drm/udl/udl_gem.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c index 8044f5f..2979625 100644 --- a/drivers/gpu/drm/udl/udl_gem.c +++ b/drivers/gpu/drm/udl/udl_gem.c @@ -164,8 +164,7 @@ void udl_gem_vunmap(struct udl_gem_object *obj) return; } - if (obj->vmapping) - vunmap(obj->vmapping); + vunmap(obj->vmapping); udl_gem_put_pages(obj); } -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] ARM: option for loading modules into vmalloc area
On Wed, 19 Nov 2014, Russell King - ARM Linux wrote: > On Wed, Nov 19, 2014 at 05:02:40PM +0100, Ard Biesheuvel wrote: > > On 19 November 2014 16:52, Konstantin Khlebnikov wrote: > > > Do you mean ldr pc, =symbol ? > > > > > > In this case I get this error: > > > > > > /tmp/ccAHtONU.s: Assembler messages: > > > /tmp/ccAHtONU.s:220: Error: invalid literal constant: pool needs to be > > > closer > > > > > > Probably constant pool doesn't work well in inline assembly. > > > > > > > > > Something like this seems work: > > > > > > add lr, pc, #4 > > > ldr pc, [pc, #-4] > > > .long symbol > > > > > > > You can add a '.ltorg' instruction which tells the assembler to dump > > the literal pool, but you still need to jump over it, i.e., > > > > adr lr, 0f > > ldr pc, =symbol > > .ltorg > > 0: > > Which is not a good idea either, because the compiler needs to know how > far away its own manually generated literal pool is from the instructions > which reference it. The .ltorg statement can end up emitting any number > of literals at that point, which makes it indeterminant how many words > are contained within the asm() statement. > > Yes, it isn't desirable to waste an entire data cache line per indirect > call like the original quote above, but I don't see a practical > alternative. Modules could be built without far calls by default, and then the module linker would only have to redirect those calls whose destination is too far away to a dynamically created trampoline table. If I remember correctly you even posted some patches to that effect a couple years ago. Maybe those could be salvaged? I would largely recommend a solution where the link process could deal with it automatically and as needed rather than sprinkling yet more manually maintained macros into assembly code. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] HID: i2c-hid: fix race condition reading reports
Hi Benjamin, On Tue, Nov 18, 2014 at 5:43 AM, Benjamin Tissoires wrote: > Hey Antonio, > > On Nov 16 2014 or thereabouts, Antonio Borneo wrote: >> From: Jean-Baptiste Maneyrol >> >> From: Jean-Baptiste Maneyrol >> >> Current driver uses a common buffer for reading reports either >> synchronously in i2c_hid_get_raw_report() and asynchronously in >> the interrupt handler. >> There is race condition if an interrupt arrives immediately after >> the report is received in i2c_hid_get_raw_report(); the common >> buffer is modified by the interrupt handler with the new report >> and then i2c_hid_get_raw_report() proceed using wrong data. >> >> Fix it by using a separate buffers for asynchronous reports. >> >> Signed-off-by: Jean-Baptiste Maneyrol >> [Antonio Borneo: cleanup and rebase to v3.17] >> Signed-off-by: Antonio Borneo >> Cc: sta...@vger.kernel.org > > For your next submission, when you want a patch to go in stable, put CC > here, but please do not CC the actual mail to stable@. Stable should receive > either mails which are already in Linus' tree, or which refer a commit > in Linus' tree in case it does not applies smoothly. > > [keeping stable@ here to show them that this one should not get picked > right now] I agree with you to lower the noise in -stable, even if Greg does not feel annoyed. I'll take care in the future. > >> --- >> >> Hi Jiri, Benjamin, >> >> I think this patch should also go through linux-stable. >> Confirmation from our side is welcome. > > I think the patch is definitively valuable. However, my personal taste > would go for having a new .rawbuf buffer and use it in > i2c_hid_get_raw_report(). The rationale would be that it's actually > i2c_hid_get_raw_report() which is problematic, not the generic irq > handling. Also I prefer rawbuf to irqinbuf. > > I am perfectly aware that this is just bikeshedding, so if changing the > patch is too cumbersome (looks like Jean-Baptiste is involved), and if > Jiri agree, this can go into the hid tree with my reviewed-by. > > I am fine having this version or the rawbuf one in stable BTW. No major issue changing the patch in line with your suggestion; just some offline work to get also Jean-Baptiste check and approve it. I'll send shortly a V2 that adds rawbuf instead of irqinbuf. I will not add your "reviewed-by" since the code in V2 is quite different than V1. Thanks! Antonio -- 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 07/16] PCI: Separate pci_host_bridge creation out of pci_create_root_bus()
On Wed, Nov 19, 2014 at 10:24:52AM +0800, Yijing Wang wrote:
> >> We need, some platforms pass NULL pointer as host bridge parent.
> >
> > Yijing,
> >
> > May I suggest a different approach here? Rather than having to pass an
> > opaque
> > pointer that gets converted by the host bridge driver back to the private
> > structure, what about promoting a new style of usage, that is similar to the
> > way device drivers work? Lets try to promote the embedding of the generic
> > pci_host_bridge structure in the host bridge specific structure! Then we can
> > access the private data doing container_of().
> >
> > Something like this:
> >
> > struct pci_controller {
> > struct pci_host_bridge bridge;
> > /* private host bridge data here */
> > .
> > };
> >
> > #define PCI_CONTROLLER(bus) ({
> > struct pci_host_bridge *hb = to_pci_host_bridge(bus->bridge); \
> > container_of(hb, struct pci_controller, bridge); })
> >
> >
> > Then we can retrieve the host bridge structure from everywhere we have a
> > device.
>
> Hi Liviu, it looks good to me, because this change will involve lots
> platforms,
> I would think more about it. Thanks for your suggestion very much! :)
Given that I also look at this area maybe we should join forces and divide the
problem?
Best regards,
Liviu
>
>
> Thanks!
> Yijing.
>
> >
> > Best regards,
> > Liviu
> >
> >>
> >>>
> +host = kzalloc(sizeof(*host), GFP_KERNEL);
> +if (!host)
> +return NULL;
> >>>
> >>> devm_kzalloc maybe?
> >>
> >> I don't know much detail about devm_kzalloc(), but we have no pci host
> >> driver
> >> here, and I found no devm_kzalloc() uses in core PCI code before.
> >>
> >>>
> +if (!resources) {
> +/* Use default IO/MEM/BUS resources*/
> +pci_add_resource(>windows, _resource);
> +pci_add_resource(>windows, _resource);
> +pci_add_resource(>windows, _resource);
> +} else {
> +list_for_each_entry_safe(window, n, resources, list)
> +list_move_tail(>list, >windows);
> +}
> >>>
> >>> I think we should assume that the correct resources are passed. You
> >>> could add a wrapper around this function to convert old platforms
> >>> though.
> >>
> >> OK, I will move these code out of pci_create_host_bridge, and add a wrapper
> >> to setup the default resources.
> >>
> >>>
> +EXPORT_SYMBOL(pci_create_host_bridge);
> >>>
> >>> EXPORT_SYMBOL_GPL() maybe?
> >>
> >> OK, will update it.
> >>
> >>>
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 8b11b38..daa7f40 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -402,7 +402,12 @@ struct pci_host_bridge_window {
> struct pci_host_bridge {
> struct device dev;
> struct pci_bus *bus;/* root bus */
> +struct list_head list;
> struct list_head windows; /* pci_host_bridge_windows */
> +int busnum;
> >>>
> >>> The busnum should already be implied through the bus resource.
> >>
> >> Yes, I will consider remove it and introduce a helper function to get the
> >> root bus number, thanks!
> >>
> >> Thanks!
> >> Yijing.
> >>
> >>>
> >>> Arnd
> >>>
> >>> .
> >>>
> >>
> >>
> >> --
> >> Thanks!
> >> Yijing
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> >> the body of a message to majord...@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>
> >
>
>
> --
> Thanks!
> Yijing
>
> --
> 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/
>
--
---
.oooO
( )
\ ( Oooo.
\_) ( )
) /
(_/
One small step
for me ...
--
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 07/16] PCI: Separate pci_host_bridge creation out of pci_create_root_bus()
On Wed, Nov 19, 2014 at 01:42:52AM +, Yijing Wang wrote:
> On 2014/11/18 23:30, Liviu Dudau wrote:
> > On Mon, Nov 17, 2014 at 10:21:41AM +, Yijing Wang wrote:
> >> There are some common PCI infos like domain, msi_controller, these
> >> infos are saved in arch PCI sysdata, and lots arch specific functions
> >> like pci_domain_nr() and pcibios_msi_controller() required.
> >> We could separate pci_host_bridge creation out of pci_create_root_bus(),
> >> then we could put the common infos in, then we could eliminate
> >> the arch specifc functions.
> >>
> >
> > Please Cc: Yinghai Lu and Jiang Liu on future versions.
> >
> > More comments on the conversion of pci_create_root_bus():
>
> That's my mistake, will add CC Yinghai and Jiang in next version.
>
> >
> >> Signed-off-by: Yijing Wang
> >> ---
> ...
> >> +
> >> +static void pci_release_host_bridge_dev(struct device *dev)
> >> +{
> >> + struct pci_host_bridge *bridge = to_pci_host_bridge(dev);
> >> +
> >> + if (bridge->release_fn)
> >> + bridge->release_fn(bridge);
> >> + pci_free_resource_list(>windows);
> >> + kfree(bridge);
> >> +}
> >> +
> >> +struct pci_host_bridge *pci_create_host_bridge(
> >> + struct device *parent, u32 db,
> >> + struct pci_ops *ops, void *sysdata,
> >
> > I don't thinks it is worth moving the buses' pci_ops into pci_host_bridge.
> > It
> > might be more useful to have pci_host_bridge specific ops here.
>
> Because we want to create pci_host_bridge before pci root bus creation,
> so when we scan the root bus and child buses, we use pci_host_bridge as
> the only argument, and another pci_host_info will be addes in later patch,
> which one support carry the pci_host_bridge ops.
But pci_create_root_bus() already has a pci_ops argument, I don't see the reason
to drop that.
pci_create_host_bridge() can get pci_host_bridge ops while
pci_create_root_bus() gets
the bus ops. For find out the MSI controller, the domain number and any other HB
specific stuff, you use the HB ops. For config R/W acceses you use bus ops.
>
> >
> >> + struct list_head *resources)
> >> +{
> >> + int error;
> >> + struct pci_bus *b;
> >> + struct pci_host_bridge *host, *h;
> ...
> >> -struct pci_bus *pci_create_root_bus(struct device *parent, u32 db,
> >> - struct pci_ops *ops, void *sysdata, struct list_head
> >> *resources)
> >> +struct pci_bus *__pci_create_root_bus(struct pci_host_bridge *bridge)
> >> {
> >> int error;
> >> - struct pci_host_bridge *bridge;
> >> struct pci_bus *b, *b2;
> >> - struct pci_host_bridge_window *window, *n;
> >> + struct pci_host_bridge_window *window;
> >> struct resource *res;
> >> resource_size_t offset;
> >> char bus_addr[64];
> >> char *fmt;
> >> - u8 bus = PCI_BUSNUM(db);
> >> + struct device *parent = bridge->dev.parent;
> >>
> >> b = pci_alloc_bus(NULL);
> >> if (!b)
> >> return NULL;
> >>
> >> - b->sysdata = sysdata;
> >> - b->ops = ops;
> >> - b->number = b->busn_res.start = bus;
> >> + b->sysdata = bridge->sysdata;
> >
> > I think bridge should be the b->sysdata here.
>
> ? what's the meaning?
Currently, bus->sysdata holds a pointer to the arch/driver host bridge
structure, as passed
in pci_create_root_bus(). If you agree with my idea of wrapping the host bridge
driver
structure around the pci_host_bridge, then we will always have a way of
retrieving that
information; but for backwards compatibility we could set bus->sysdata to be
the bridge.
Then existing macros that convert sysdata to pci_controller can be reused after
being
updated.
Best regards,
Liviu
>
> >
> >> + b->ops = bridge->ops;
> >
> > See comment above why I don't think this is necessary.
> >
> >> + b->number = b->busn_res.start = bridge->busnum;
> >> pci_bus_assign_domain_nr(b, parent);
> >> - b2 = pci_find_bus(pci_domain_nr(b), bus);
> >> + bridge->domain = pci_domain_nr(b);
> >
> > Do you really want to overwrite the bridge's domain with the one from a bus
> > that
> > could possibly be rejected a couple of lines further down?
> >
> > As an asside: if we are doing the split of pci_host_bridge from root bus
> > creation
> > it is worth in my opinion to move the domain setup in
> > pci_create_host_bridge()
> > and stop fiddling with it here.
>
>
> Hi Liviu, these lines just temporary, I will remove it after all host drivers
> save its domain in pci_host_bridge.
>
>
> >
> > Otherwise it looks to me like you are heading in the right direction.
>
> Thanks!
> Yijing.
>
> >
> > Best regards,
> > Liviu
> >
> >> + b2 = pci_find_bus(pci_domain_nr(b), bridge->busnum);
> >> if (b2) {
> >> /* If we already got to this bus through a different
> >> bridge, ignore it */
> >> dev_dbg(>dev, "bus already known\n");
Re: [PATCH v5 1/4] mfd: rt5033: Add Richtek RT5033 driver core.
On Wed, 19 Nov 2014, Beomho Seo wrote:
> This patch adds a new driver for Richtek RT5033 driver.
> RT5033 is a Multifunction device which includes battery charger, fuel gauge,
> flash LED current source, LDO and synchronous Buck converter. It is interfaced
> to host controller using I2C interface.
>
> Cc: Samuel Ortiz
> Cc: Lee Jones
> Signed-off-by: Beomho Seo
> Acked-by: Chanwoo Choi
> ---
> Changes in v5
> - Change possible built as a module.
> - Revise rt5033_dev mfd cell entry.
> - Fix incorrect typo.
> - Add module alias.
>
> Changes in v4
> - none.
>
> Changes in v3
> - Correct sentence errors.
> - Add author information the top of each drivers.
> - Remove unnecessary pre-initialise, struct member(rt5033->i2c) and blink.
> - Change some return check.
> - Use bool and of_match_ptr().
>
> Changes in v2
> - Remove volatile_reg callback. Because this driver not in use regmap cache.
> - Revmoe unnecessary subnode of_compatible.
> - Add define for set_high impedance mode of charger.
> ---
> drivers/mfd/Kconfig| 12 ++
> drivers/mfd/Makefile |1 +
> drivers/mfd/rt5033.c | 136 +++
> include/linux/mfd/rt5033-private.h | 260
>
> include/linux/mfd/rt5033.h | 62 +
> 5 files changed, 471 insertions(+)
> create mode 100644 drivers/mfd/rt5033.c
> create mode 100644 include/linux/mfd/rt5033-private.h
> create mode 100644 include/linux/mfd/rt5033.h
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 72d3808..9c13170 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -618,6 +618,18 @@ config MFD_RTSX_PCI
> types of memory cards, such as Memory Stick, Memory Stick Pro,
> Secure Digital and MultiMediaCard.
>
> +config MFD_RT5033
> + tristate "Richtek RT5033 Power Management IC"
> + depends on I2C=y
> + select MFD_CORE
> + select REGMAP_I2C
> + help
> + This driver provides for the Richtek RT5033 Power Management IC,
> + which includes the I2C driver and the Core APIs. This driver provides
> + common support for accessing the device. The device supports multiple
> + sub-devices like charger, fuel gauge, flash LED, current source,
> + LDO and Buck.
> +
> config MFD_RTSX_USB
> tristate "Realtek USB card reader"
> depends on USB
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 53467e2..4059c24 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -176,6 +176,7 @@ obj-$(CONFIG_MFD_IPAQ_MICRO) += ipaq-micro.o
> obj-$(CONFIG_MFD_MENF21BMC) += menf21bmc.o
> obj-$(CONFIG_MFD_HI6421_PMIC)+= hi6421-pmic-core.o
> obj-$(CONFIG_MFD_DLN2) += dln2.o
> +obj-$(CONFIG_MFD_RT5033) += rt5033.o
>
> intel-soc-pmic-objs := intel_soc_pmic_core.o intel_soc_pmic_crc.o
> obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> diff --git a/drivers/mfd/rt5033.c b/drivers/mfd/rt5033.c
> new file mode 100644
> index 000..4d289b9
> --- /dev/null
> +++ b/drivers/mfd/rt5033.c
> @@ -0,0 +1,136 @@
> +/*
> + * MFD core driver for the Richtek RT5033.
> + *
> + * Copyright (C) 2014 Samsung Electronics, Co., Ltd.
> + * Author: Beomho Seo
> + *
> + * 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 bythe Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static const struct regmap_irq rt5033_irqs[] = {
> + { .mask = RT5033_PMIC_IRQ_BUCKOCP, },
> + { .mask = RT5033_PMIC_IRQ_BUCKLV, },
> + { .mask = RT5033_PMIC_IRQ_SAFELDOLV, },
> + { .mask = RT5033_PMIC_IRQ_LDOLV, },
> + { .mask = RT5033_PMIC_IRQ_OT, },
> + { .mask = RT5033_PMIC_IRQ_VDDA_UV, },
> +};
> +
> +static const struct regmap_irq_chip rt5033_irq_chip = {
> + .name = "rt5033",
> + .status_base= RT5033_REG_PMIC_IRQ_STAT,
> + .mask_base = RT5033_REG_PMIC_IRQ_CTRL,
> + .mask_invert= true,
> + .num_regs = 1,
> + .irqs = rt5033_irqs,
> + .num_irqs = ARRAY_SIZE(rt5033_irqs),
> +};
> +
> +static const struct mfd_cell rt5033_devs[] = {
> + { .name = "rt5033-regulator", },
> + { .name = "rt5033-charger", .of_compatible = "richtek,rt5033-charger",},
> + { .name = "rt5033-battery", .of_compatible = "richtek,rt5033-battery",},
> +};
Perhaps I wasn't clear enough in my previous review -- sorry for
that. I only want to see the single entry on one line i.e. one with
.name, but no .of_compatible. I probably wouldn't have requested a
re-spin, but you have white space issues at the end of those two lines
too.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send
Re: [PATCH 1/3] usb: phy: introduce usb_phy_set_event interface
On Wed, Nov 19, 2014 at 2:43 AM, Kiran Kumar Raparthy wrote: > From: Todd Poynor > > usb: phy: introduce usb_phy_set_event interface Hi Kiran, this is new stuff that is all your own work and you deserve the credit. Thanks for working to get this feature in shape for mainline! Todd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] ARM: option for loading modules into vmalloc area
On Wed, Nov 19, 2014 at 7:25 PM, Ard Biesheuvel wrote: > On 19 November 2014 17:07, Russell King - ARM Linux > wrote: >> On Wed, Nov 19, 2014 at 05:02:40PM +0100, Ard Biesheuvel wrote: >>> On 19 November 2014 16:52, Konstantin Khlebnikov wrote: >>> > Do you mean ldr pc, =symbol ? >>> > >>> > In this case I get this error: >>> > >>> > /tmp/ccAHtONU.s: Assembler messages: >>> > /tmp/ccAHtONU.s:220: Error: invalid literal constant: pool needs to be >>> > closer >>> > >>> > Probably constant pool doesn't work well in inline assembly. >>> > >>> > >>> > Something like this seems work: >>> > >>> > add lr, pc, #4 >>> > ldr pc, [pc, #-4] >>> > .long symbol >>> > >>> >>> You can add a '.ltorg' instruction which tells the assembler to dump >>> the literal pool, but you still need to jump over it, i.e., >>> >>> adr lr, 0f >>> ldr pc, =symbol >>> .ltorg >>> 0: >> >> Which is not a good idea either, because the compiler needs to know how >> far away its own manually generated literal pool is from the instructions >> which reference it. The .ltorg statement can end up emitting any number >> of literals at that point, which makes it indeterminant how many words >> are contained within the asm() statement. >> > > That applies to any inline asm statement in general: the compiler > assumes that the expanded size will not interfere with its ability to > emit literals after the function's return instruction. > Sometimes it will put a literal pool in the middle of the function if > it is very large, and I am not sure if an inline asm by itself would > ever trigger that heuristic to kick in. > > But by the same logic, i.e., due to the fact that GCC manages its own > literals, the literal pool at the assembly level is unlikely to be so > large that you will actually hit this condition. > >> Yes, it isn't desirable to waste an entire data cache line per indirect >> call like the original quote above, but I don't see a practical >> alternative. >> > > We could at least add some labels instead of doing explicit pc arithmetic, > i.e., > > adr lr, 1f > ldr pc, 0f > 0: .long symbol > 1: I think we need some unique prefix here, this macro is used inside bigger inline assembly constructions and probably another macro. -- 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 18/26 v5] seq_buf: Create seq_buf_used() to find out how much was written
On Wed 2014-11-19 10:49:56, Steven Rostedt wrote:
> On Tue, 18 Nov 2014 16:02:04 +0100
> Petr Mladek wrote:
>
> > On Fri 2014-11-14 23:59:05, Steven Rostedt wrote:
> > > From: "Steven Rostedt (Red Hat)"
> > >
> > > Add a helper function seq_buf_used() that replaces the SEQ_BUF_USED()
> > > private macro to let callers have a method to know how much of the
> > > seq_buf was written to.
> > >
> > > Link: http://lkml.kernel.org/r/20141114011412.170377...@goodmis.org
> > > Link: http://lkml.kernel.org/r/20141114011413.321654...@goodmis.org
> > >
> > > Signed-off-by: Steven Rostedt
> > > ---
> > > include/linux/seq_buf.h | 6 ++
> > > kernel/trace/seq_buf.c | 5 +
> > > 2 files changed, 7 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/include/linux/seq_buf.h b/include/linux/seq_buf.h
> > > index 5d91262433e2..93718e570d4c 100644
> > > --- a/include/linux/seq_buf.h
> > > +++ b/include/linux/seq_buf.h
> > > @@ -64,6 +64,12 @@ seq_buf_buffer_left(struct seq_buf *s)
> > > return (s->size - 1) - s->len;
> > > }
> > >
> > > +/* How much buffer was written? */
> > > +static inline unsigned int seq_buf_used(struct seq_buf *s)
> > > +{
> > > + return min(s->len, s->size);
> >
> > To be precise, it should do
> >
> > return min(s->len, s->size - 1);
> >
> > at this stage and switch to the above code in ("[PATCH 21/26 v5] tracing:
> > Have
> > seq_buf use full buffer"). Well, it does not cause any big harm. Feel
> > free to add:
>
> I actually thought about it, but realized that this only replaces the
> original use of s->len, and we are only doing this to avoid buffer
> overflows. If you get garbage, then so be it, as the original code
> would give garbage too. Remember, some of the functions did have real
> content in that last byte, even though it was considered "overflowed".
I thought that it was based on ftrace_seq code that had
#define TRACE_SEQ_BUF_USED(s) min((s)->len, (unsigned int)(PAGE_SIZE -
1))
But you are right that the callers used s->len because the macro was
local in trace_seq.c.
Well, I think that it does not matter much. As you said, there might be
a garbage a the end of the buffer. Callers used "len" directly.
Also it will be min(s->len, s->size); after the commit "Have seq_buf
use full buffer".
Let's leave it as is.
Best Regards,
Petr
--
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] sched/deadline: change cpudl_find() to return bool instead of best_cpu
On Wed, 19 Nov 2014 23:46:22 +0800
"pang.xunlei" wrote:
> cpudl_find() is not a good place to select the best cpu, so leave
> this role to its call site, currently it is find_later_rq() where
> we can do the election of the best cpu according to sd topology.
>
> Signed-off-by: pang.xunlei
> ---
> kernel/sched/cpudeadline.c | 15 +--
> kernel/sched/deadline.c| 17 ++---
> 2 files changed, 11 insertions(+), 21 deletions(-)
>
> diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c
> index 3047846..41d3578 100644
> --- a/kernel/sched/cpudeadline.c
> +++ b/kernel/sched/cpudeadline.c
> @@ -100,29 +100,24 @@ static inline int cpudl_maximum(struct cpudl *cp)
> * @later_mask: a mask to fill in with the selected CPUs (not NULL)
> * @set_flag: indicate if later_mask should be set
> *
> - * Returns: int - best CPU (heap maximum if suitable)
> + * Return: (int)bool - CPUs were found
> */
> int cpudl_find(struct cpudl *cp, struct task_struct *p,
> struct cpumask *later_mask, int set_flag)
> {
> - int best_cpu = -1;
> const struct sched_dl_entity *dl_se = >dl;
>
> cpumask_and(later_mask, cpu_active_mask, >cpus_allowed);
> if (cpumask_and(later_mask, later_mask, cp->free_cpus)) {
> - best_cpu = cpumask_any(later_mask);
> - goto out;
> + return 1;
> } else if (cpumask_test_cpu(cpudl_maximum(cp), >cpus_allowed) &&
> dl_time_before(dl_se->deadline, cp->elements[0].dl)) {
> - best_cpu = cpudl_maximum(cp);
> if (set_flag)
> - cpumask_set_cpu(best_cpu, later_mask);
> + cpumask_set_cpu(cpudl_maximum(cp), later_mask);
> + return 1;
> }
>
> -out:
> - WARN_ON(best_cpu != -1 && !cpu_present(best_cpu));
You lost this warning. It should be moved too.
> -
> - return best_cpu;
> + return 0;
> }
>
> /*
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index e8208d0..3e82cf3 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -976,7 +976,7 @@ static void check_preempt_equal_dl(struct rq *rq, struct
> task_struct *p)
>* let's hope p can move out.
>*/
> if (rq->curr->nr_cpus_allowed == 1 ||
> - cpudl_find(>rd->cpudl, rq->curr, later_mask, 0) == -1)
> + !cpudl_find(>rd->cpudl, rq->curr, later_mask, 0))
> return;
>
> /*
> @@ -984,7 +984,7 @@ static void check_preempt_equal_dl(struct rq *rq, struct
> task_struct *p)
>* see if it is pushed or pulled somewhere else.
>*/
> if (p->nr_cpus_allowed != 1 &&
> - cpudl_find(>rd->cpudl, p, later_mask, 0) != -1)
> + cpudl_find(>rd->cpudl, p, later_mask, 0))
> return;
>
> resched_curr(rq);
> @@ -1189,9 +1189,7 @@ static int find_later_rq(struct task_struct *task)
>* We have to consider system topology and task affinity
>* first, then we can look for a suitable cpu.
>*/
> - best_cpu = cpudl_find(_rq(task)->rd->cpudl,
> - task, later_mask, 1);
> - if (best_cpu == -1)
> + if (!cpudl_find(_rq(task)->rd->cpudl, task, later_mask, 1))
> return -1;
>
> /*
> @@ -1230,12 +1228,9 @@ static int find_later_rq(struct task_struct *task)
> return this_cpu;
> }
>
> - /*
> - * Last chance: if best_cpu is valid and is
> - * in the mask, that becomes our choice.
> - */
> - if (best_cpu < nr_cpu_ids &&
> - cpumask_test_cpu(best_cpu, sched_domain_span(sd))) {
> + best_cpu = cpumask_first_and(lowest_mask,
> + sched_domain_span(sd));
Sometimes that 80 character rule isn't the best for readability. But
that is Peter's or Juri's call.
> + if (best_cpu < nr_cpu_ids) {
The warning should probably go here.
-- Steve
> rcu_read_unlock();
> return best_cpu;
> }
--
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/core/of: Add symlink to device-tree from devices with an OF node
On Wed, Nov 19, 2014 at 3:39 PM, Rob Herring wrote:
> On Wed, Nov 19, 2014 at 8:49 AM, Arnd Bergmann wrote:
>> On Wednesday 19 November 2014 08:45:58 Rob Herring wrote:
>>> > static inline struct device_node *dev_of_node(struct device *of_node)
>>> > {
>>> > if (!IS_ENABLED(CONFIG_OF))
>>> > return NULL;
>>> >
>>> > return dev->of_node;
>>> > }
>>> >
>>> > Adding the IS_ENABLED() in a lot of drivers isn't horrible, but we seem
>>> > to be doing it a lot.
>>>
>>> I think you misread things. of_node is always present now, so it
>>> should always be NULL for !CONFIG_OF.
>>>
>>
>> No, I didn't misread it but I should have been clearer with the intention:
>> The idea is to tell the compiler that we know it will be NULL when CONFIG_OF
>> is unset, so it can optimize out all code that does
>>
>> struct device_node *dn = dev_of_node(dev);
>>
>> if (dn) {
>> ...
>> /* complex code */
>> ...
>> }
>>
>> and we can avoid using an #ifdef or if(IS_ENABLED()) in the source to
>> compile out the DT-only sections of a driver.
>
> Oh, right. That would definitely be worthwhile to do.
Agreed.
g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] mfd: dln2: add support for USB-SPI module
On Tue, 18 Nov 2014, Laurentiu Palcu wrote:
> Signed-off-by: Laurentiu Palcu
> ---
> drivers/mfd/dln2.c | 12
> 1 file changed, 12 insertions(+)
For my own reference:
Acked-by: Lee Jones
So what's the plan for this set?
> diff --git a/drivers/mfd/dln2.c b/drivers/mfd/dln2.c
> index 9765a17..0cdad2d 100644
> --- a/drivers/mfd/dln2.c
> +++ b/drivers/mfd/dln2.c
> @@ -52,6 +52,7 @@ enum dln2_handle {
> DLN2_HANDLE_CTRL,
> DLN2_HANDLE_GPIO,
> DLN2_HANDLE_I2C,
> + DLN2_HANDLE_SPI,
> DLN2_HANDLES
> };
>
> @@ -634,6 +635,12 @@ static struct dln2_platform_data dln2_pdata_i2c = {
> .port = 0,
> };
>
> +/* Only one SPI port supported */
> +static struct dln2_platform_data dln2_pdata_spi = {
> + .handle = DLN2_HANDLE_SPI,
> + .port = 0,
> +};
> +
> static const struct mfd_cell dln2_devs[] = {
> {
> .name = "dln2-gpio",
> @@ -645,6 +652,11 @@ static const struct mfd_cell dln2_devs[] = {
> .platform_data = _pdata_i2c,
> .pdata_size = sizeof(struct dln2_platform_data),
> },
> + {
> + .name = "dln2-spi",
> + .platform_data = _pdata_spi,
> + .pdata_size = sizeof(struct dln2_platform_data),
> + },
> };
>
> static void dln2_disconnect(struct usb_interface *interface)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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: frequent lockups in 3.18rc4
On Wed, Nov 19, 2014 at 10:38:52AM -0500, Dave Jones wrote:
> On Wed, Nov 19, 2014 at 10:03:33AM -0500, Vivek Goyal wrote:
>
> > Not being able to capture the dump I can understand but having wedged
> > the machine so that it does not reboot after dump failure sounds bad.
> > So you could not get machine to boot even after a power cycle? Would
> > you remember what was failing. I am curious to know what did kdump do
> > to make machine unbootable.
>
> Power cycling was fine, because then it booted into the non-kdump kernel.
> The issue was when I caused that kernel to panic, it would just sit there
> wedged, with no indication it even tried to switch to the kdump kernel.
I have seen the cases where we fail to boot in second kernel and often
failure can happen very early without any information on graphic console.
I have to always hook up a serial console to get an idea what went wrong
that early. It is not an idea situation but at the same time don't know
how to improve it.
I am wondering may be in some cases we panic in second kernel and sit
there. Probably we should append a kernel command line automatically
say "panic=1" so that it reboots itself if second kernel panics.
By any chance, have you enabled "CONFIG_RANDOMIZE_BASE"? If yes, please
disable that as currently kexec/kdump stuff does not work with it. And
it hangs very early in the boot process and I had to hook serial console
to get following message on console.
arch/x86/boot/compressed/misc.c
error("32-bit relocation outside of kernel!\n");
I noticed that error() halts in a while loop after error message. May be
there can be some way for it to try to reboot instead of halting in
while loop.
>
> > > > Unless there's some magic step missing from the documentation at
> > > > http://fedoraproject.org/wiki/How_to_use_kdump_to_debug_kernel_crashes
> > > > then I'm not optimistic it'll be useful.
> >
> > I had a quick look at it and it basically looks fine. In fedora ideally
> > it is just two steps process.
> >
> > - Reserve memory using crashkernel. Say crashkernel=160M
> > - systemctl start kdump
> > - Crash the system or wait for it to crash.
> >
> > So despite your bad experience in the past, I would encourage you to
> > give it a try.
>
> 'the past' here, is two weeks ago, on Fedora 21.
>
> But, since then, I've reinstalled that box with Fedora 20 because I didn't
> trust gcc 4.9, and on f20 things are actually even worse.
>
> Right now it doesn't even create the image correctly:
>
> dracut: *** Stripping files done ***
> dracut: *** Store current command line parameters ***
> dracut: *** Creating image file ***
> dracut: *** Creating image file done ***
> kdumpctl: cat: write error: Broken pipe
> kdumpctl: kexec: failed to load kdump kernel
> kdumpctl: Starting kdump: [FAILED]
Hmmm..., can you please enable debugging in kdumpctl using "set -x" and
do "touch /etc/kdump.conf; kdumpctl restart" and give debug output to me.
>
> It works if I run a Fedora kernel, but not with a self-built one.
> And there's zero information as to what I'm doing wrong.
I just tested F20 kdump on my box and it worked fine for me.
So for you second kernel hangs and there is no info on console? Is there
any possibility to hook up serial console, enable early printk and see
if soemthing shows up there.
Apart from this, if you run into kdump issues in fedora, please cc
kexec fedora mailing list too so that we are aware of it.
https://lists.fedoraproject.org/mailman/listinfo/kexec
Thanks
Vivek
--
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] ACPI: Add _DEP(Operation Region Dependencies) support to fix battery issue on the Asus T100TA
On Wed, Nov 19, 2014 at 11:20:41PM +0800, Lan Tianyu wrote:
> ACPI 5.0 introduces _DEP to designate device objects that OSPM should
> assign a higher priority in start ordering due to future operation region
> accesses.
>
> On Asus T100TA, ACPI battery info are read from a I2C slave device via
> I2C operation region. Before I2C operation region handler is installed,
> battery _STA always returns 0. There is a _DEP method of designating
> start order under battery device node.
>
> This patch is to implement _DEP feature to fix battery issue on the Asus
> T100TA.
> Introducing acpi_dep_list and adding dep_unmet count in the struct
> acpi_device. During ACPI namespace scan, create struct acpi_dep_data for a
> valid pair of master (device pointed to by _DEP)/slave(device with _DEP),
> record
> master's and slave's ACPI handle in it and put it into acpi_dep_list. The
> dep_unmet
> count will increase by one if there is a device under its _DEP. Driver's
> probe() should
> return EPROBE_DEFER when find dep_unmet larger than 0. When I2C operation
> region handler is installed, remove all struct acpi_dep_data on the
> acpi_dep_list
> whose master is pointed to I2C host controller and decrease slave's dep_unmet.
> When dep_unmet decreases to 0, all _DEP conditions are met and then do
> acpi_bus_attach()
> for the device in order to resolve battery _STA issue on the Asus T100TA.
>
> Reference: https://bugzilla.kernel.org/show_bug.cgi?id=69011
> Tested-by: Jan-Michael Brummer
> Tested-by: Adam Williamson
> Tested-by: Michael Shigorin
> Signed-off-by: Lan Tianyu
> ---
> drivers/acpi/battery.c | 4 +++
> drivers/acpi/scan.c | 89
> +
> drivers/i2c/i2c-core.c | 1 +
> include/acpi/acpi_bus.h | 1 +
> include/linux/acpi.h| 3 ++
> 5 files changed, 98 insertions(+)
>
> diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
> index 8ec8a89..d98ba43 100644
> --- a/drivers/acpi/battery.c
> +++ b/drivers/acpi/battery.c
> @@ -1180,6 +1180,10 @@ static int acpi_battery_add(struct acpi_device *device)
>
> if (!device)
> return -EINVAL;
> +
> + if (device->dep_unmet)
> + return -EPROBE_DEFER;
> +
> battery = kzalloc(sizeof(struct acpi_battery), GFP_KERNEL);
> if (!battery)
> return -ENOMEM;
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 9cb5cca..0e58666 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -36,6 +36,8 @@ bool acpi_force_hot_remove;
>
> static const char *dummy_hid = "device";
>
> +static LIST_HEAD(acpi_dep_list);
> +static DEFINE_MUTEX(acpi_dep_list_lock);
> static LIST_HEAD(acpi_bus_id_list);
> static DEFINE_MUTEX(acpi_scan_lock);
> static LIST_HEAD(acpi_scan_handlers_list);
> @@ -43,6 +45,12 @@ DEFINE_MUTEX(acpi_device_lock);
> LIST_HEAD(acpi_wakeup_device_list);
> static DEFINE_MUTEX(acpi_hp_context_lock);
>
> +struct acpi_dep_data {
> + struct list_head node;
> + acpi_handle master;
> + acpi_handle slave;
> +};
> +
> struct acpi_device_bus_id{
> char bus_id[15];
> unsigned int instance_no;
> @@ -2193,6 +2201,61 @@ static void acpi_scan_init_hotplug(struct acpi_device
> *adev)
> }
> }
>
> +static void acpi_device_dep_initialize(struct acpi_device *adev)
> +{
> + struct acpi_dep_data *dep;
> + struct acpi_handle_list dep_devices;
> + struct acpi_device_info *info;
> + acpi_status status;
> + int i, skip;
> +
> + if (!acpi_has_method(adev->handle, "_DEP"))
> + return;
> +
> + status = acpi_evaluate_reference(adev->handle, "_DEP", NULL,
> + _devices);
> + if (ACPI_FAILURE(status)) {
> + dev_err(>dev, "Failed to evaluate _DEP.\n");
> + return;
> + }
> +
> + for (i = 0; i < dep_devices.count; i++) {
> +
Delete the black line.
> + status = acpi_get_object_info(dep_devices.handles[i], );
> + if (ACPI_FAILURE(status)) {
> + dev_err(>dev, "Error reading device info\n");
> + continue;
> + }
> +
> + /*
> + * Skip the dependency of Windows System Power
> + * Management Controller
> + */
> + if (info->valid & ACPI_VALID_HID
> + && !strcmp(info->hardware_id.string, "INT3396"))
> + skip = 1;
> + else
> + skip = 0;
> +
> + kfree(info);
> +
> + if (skip)
> + continue;
> +
> + dep = kzalloc(sizeof(struct acpi_dep_data), GFP_KERNEL);
> + if (!dep)
> + return;
> +
> + dep->master = dep_devices.handles[i];
> + dep->slave = adev->handle;
> + adev->dep_unmet++;
> +
> + mutex_lock(_dep_list_lock);
> + list_add_tail(>node , _dep_list);
> +
Re: [PATCH v3] x86, kaslr: Prevent .bss from overlaping initrd
On 11/17/2014 06:23 PM, Greg Thelen wrote: > > On Mon, Nov 17 2014, Greg Thelen wrote: > [...] >> Given that bss and brk are nobits (i.e. only ALLOC) sections, does >> file_offset make sense as a load address. This fails with gold: >> It really doesn't. We have that information elsewhere. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] ARM: option for loading modules into vmalloc area
On 19 November 2014 17:07, Russell King - ARM Linux wrote: > On Wed, Nov 19, 2014 at 05:02:40PM +0100, Ard Biesheuvel wrote: >> On 19 November 2014 16:52, Konstantin Khlebnikov wrote: >> > Do you mean ldr pc, =symbol ? >> > >> > In this case I get this error: >> > >> > /tmp/ccAHtONU.s: Assembler messages: >> > /tmp/ccAHtONU.s:220: Error: invalid literal constant: pool needs to be >> > closer >> > >> > Probably constant pool doesn't work well in inline assembly. >> > >> > >> > Something like this seems work: >> > >> > add lr, pc, #4 >> > ldr pc, [pc, #-4] >> > .long symbol >> > >> >> You can add a '.ltorg' instruction which tells the assembler to dump >> the literal pool, but you still need to jump over it, i.e., >> >> adr lr, 0f >> ldr pc, =symbol >> .ltorg >> 0: > > Which is not a good idea either, because the compiler needs to know how > far away its own manually generated literal pool is from the instructions > which reference it. The .ltorg statement can end up emitting any number > of literals at that point, which makes it indeterminant how many words > are contained within the asm() statement. > That applies to any inline asm statement in general: the compiler assumes that the expanded size will not interfere with its ability to emit literals after the function's return instruction. Sometimes it will put a literal pool in the middle of the function if it is very large, and I am not sure if an inline asm by itself would ever trigger that heuristic to kick in. But by the same logic, i.e., due to the fact that GCC manages its own literals, the literal pool at the assembly level is unlikely to be so large that you will actually hit this condition. > Yes, it isn't desirable to waste an entire data cache line per indirect > call like the original quote above, but I don't see a practical > alternative. > We could at least add some labels instead of doing explicit pc arithmetic, i.e., adr lr, 1f ldr pc, 0f 0: .long symbol 1: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] tun: flag cleanup
this patchset cleans up flag handling in tun. It logically belongs to net tree, but I'm basing support for new virtio header on top of it. Similar situation will take place with vhost patches. Rusty, Dave, what's your take? Merge this patch through virtio tree? Merge both this patch and virtio 1.0 patches through vhost tree? I'm fine with any option. Please review/ack patches in any case. Michael S. Tsirkin (3): tun: move internal flag defines out of uapi tun: reuse IFF_ flags internally tun: drop most type defines include/uapi/linux/if_tun.h | 14 - drivers/net/tun.c | 125 2 files changed, 46 insertions(+), 93 deletions(-) -- MST -- 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 3/4] sched/deadline: add the "set_flag" argument to cpudl_find()
On Wed, 19 Nov 2014 23:46:21 +0800
"pang.xunlei" wrote:
> The call site of cpudl_find() in check_preempt_equal_dl() doesn't
> use later_mask, so add this extra argument to distinquish the case.
>
> Signed-off-by: pang.xunlei
> ---
> kernel/sched/cpudeadline.c |6 --
> kernel/sched/cpudeadline.h |2 +-
> kernel/sched/deadline.c|6 +++---
> 3 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c
> index c01b3aa..3047846 100644
> --- a/kernel/sched/cpudeadline.c
> +++ b/kernel/sched/cpudeadline.c
> @@ -98,11 +98,12 @@ static inline int cpudl_maximum(struct cpudl *cp)
> * @cp: the cpudl max-heap context
> * @p: the task
> * @later_mask: a mask to fill in with the selected CPUs (not NULL)
> + * @set_flag: indicate if later_mask should be set
> *
> * Returns: int - best CPU (heap maximum if suitable)
> */
> int cpudl_find(struct cpudl *cp, struct task_struct *p,
> -struct cpumask *later_mask)
> +struct cpumask *later_mask, int set_flag)
set_flag should be a bool type.
> {
> int best_cpu = -1;
> const struct sched_dl_entity *dl_se = >dl;
> @@ -114,7 +115,8 @@ int cpudl_find(struct cpudl *cp, struct task_struct *p,
> } else if (cpumask_test_cpu(cpudl_maximum(cp), >cpus_allowed) &&
> dl_time_before(dl_se->deadline, cp->elements[0].dl)) {
> best_cpu = cpudl_maximum(cp);
> - cpumask_set_cpu(best_cpu, later_mask);
> + if (set_flag)
> + cpumask_set_cpu(best_cpu, later_mask);
I'm not sure this is worth it. cpumask_set_cpu() is rather efficient.
> }
>
> out:
--
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/
Payment
Dear Recipient, You have been awarded the sum of 8,000,000.00 (Eight Million Pounds sterling) with reference number 77100146 by office of the ministry of finance UK.Send us your personal details to deliver your funds. Gloria 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/
Re: [PATCH 6/6] pci, acpi: Share ACPI PCI config space accessors.
On 19.11.2014 17:19, Arnd Bergmann wrote:
On Wednesday 19 November 2014 17:04:51 Tomasz Nowicki wrote:
+/*
+ * raw_pci_read/write - ACPI PCI config space accessors.
+ *
+ * ACPI spec defines MMCFG as the way we can access PCI config space,
+ * so let MMCFG be default (__weak).
+ *
+ * If platform needs more fancy stuff, should provides its own implementation.
+ */
+int __weak raw_pci_read(unsigned int domain, unsigned int bus,
+ unsigned int devfn, int reg, int len, u32 *val)
+{
+ return pci_mmcfg_read(domain, bus, devfn, reg, len, val);
+}
+
+int __weak raw_pci_write(unsigned int domain, unsigned int bus,
+unsigned int devfn, int reg, int len, u32 val)
+{
+ return pci_mmcfg_write(domain, bus, devfn, reg, len, val);
+}
+
I think it would be better to avoid __weak functions here, as they tend
to be hard to follow when trying to understand the code.
How about using a Kconfig symbol like this:
#ifdef CONFIG_ARCH_RAW_PCI_READWRITE
int raw_pci_read(unsigned int domain, unsigned int bus, unsigned int devfn,
int reg, int len, u32 *val);
int raw_pci_write(unsigned int domain, unsigned int bus, unsigned int devfn,
int reg, int len, u32 val);
#else
static inline int raw_pci_read(unsigned int domain, unsigned int bus,
unsigned int devfn, int reg, int len, u32 *val)
{
return pci_mmcfg_read(domain, bus, devfn, reg, len, val);
}
static inline int raw_pci_write(unsigned int domain, unsigned int bus,
unsigned int devfn, int reg, int len,
u32 val)
{
return pci_mmcfg_write(domain, bus, devfn, reg, len, val);
}
#endif
Same thing for the weak symbols in patch 5.
It makes sense to me, thanks!
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 6/6] pci, acpi: Share ACPI PCI config space accessors.
On Wednesday 19 November 2014 17:04:51 Tomasz Nowicki wrote:
> +/*
> + * raw_pci_read/write - ACPI PCI config space accessors.
> + *
> + * ACPI spec defines MMCFG as the way we can access PCI config space,
> + * so let MMCFG be default (__weak).
> + *
> + * If platform needs more fancy stuff, should provides its own
> implementation.
> + */
> +int __weak raw_pci_read(unsigned int domain, unsigned int bus,
> + unsigned int devfn, int reg, int len, u32 *val)
> +{
> + return pci_mmcfg_read(domain, bus, devfn, reg, len, val);
> +}
> +
> +int __weak raw_pci_write(unsigned int domain, unsigned int bus,
> +unsigned int devfn, int reg, int len, u32 val)
> +{
> + return pci_mmcfg_write(domain, bus, devfn, reg, len, val);
> +}
> +
>
I think it would be better to avoid __weak functions here, as they tend
to be hard to follow when trying to understand the code.
How about using a Kconfig symbol like this:
#ifdef CONFIG_ARCH_RAW_PCI_READWRITE
int raw_pci_read(unsigned int domain, unsigned int bus, unsigned int devfn,
int reg, int len, u32 *val);
int raw_pci_write(unsigned int domain, unsigned int bus, unsigned int devfn,
int reg, int len, u32 val);
#else
static inline int raw_pci_read(unsigned int domain, unsigned int bus,
unsigned int devfn, int reg, int len, u32 *val)
{
return pci_mmcfg_read(domain, bus, devfn, reg, len, val);
}
static inline int raw_pci_write(unsigned int domain, unsigned int bus,
unsigned int devfn, int reg, int len,
u32 val)
{
return pci_mmcfg_write(domain, bus, devfn, reg, len, val);
}
#endif
Same thing for the weak symbols in patch 5.
Arnd
--
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] tun: move internal flag defines out of uapi
TUN_ flags are internal and never exposed
to userspace. Any application using it is almost
certainly buggy.
Move them out to tun.c, we'll remove them in follow-up patches.
Signed-off-by: Michael S. Tsirkin
---
include/uapi/linux/if_tun.h | 14 --
drivers/net/tun.c | 14 ++
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
index e9502dd..b82c276 100644
--- a/include/uapi/linux/if_tun.h
+++ b/include/uapi/linux/if_tun.h
@@ -23,20 +23,6 @@
/* Read queue size */
#define TUN_READQ_SIZE 500
-/* TUN device flags */
-#define TUN_TUN_DEV0x0001
-#define TUN_TAP_DEV0x0002
-#define TUN_TYPE_MASK 0x000f
-
-#define TUN_FASYNC 0x0010
-#define TUN_NOCHECKSUM 0x0020
-#define TUN_NO_PI 0x0040
-/* This flag has no real effect */
-#define TUN_ONE_QUEUE 0x0080
-#define TUN_PERSIST0x0100
-#define TUN_VNET_HDR 0x0200
-#define TUN_TAP_MQ 0x0400
-
/* Ioctl defines */
#define TUNSETNOCSUM _IOW('T', 200, int)
#define TUNSETDEBUG _IOW('T', 201, int)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 2e18ddd..81735f5 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -103,6 +103,20 @@ do {
\
} while (0)
#endif
+/* TUN device flags */
+#define TUN_TUN_DEV0x0001
+#define TUN_TAP_DEV0x0002
+#define TUN_TYPE_MASK 0x000f
+
+#define TUN_FASYNC 0x0010
+#define TUN_NOCHECKSUM 0x0020
+#define TUN_NO_PI 0x0040
+/* This flag has no real effect */
+#define TUN_ONE_QUEUE 0x0080
+#define TUN_PERSIST0x0100
+#define TUN_VNET_HDR 0x0200
+#define TUN_TAP_MQ 0x0400
+
#define GOODCOPY_LEN 128
#define FLT_EXACT_COUNT 8
--
MST
--
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] tun: drop most type defines
It's just as easy to use IFF_ flags directly,
there's no point in adding our own defines.
Signed-off-by: Michael S. Tsirkin
---
drivers/net/tun.c | 64 ---
1 file changed, 28 insertions(+), 36 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index e4bd542..06683af 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -104,20 +104,12 @@ do {
\
#endif
/* TUN device flags */
-#define TUN_TUN_DEVIFF_TUN
-#define TUN_TAP_DEVIFF_TAP
#define TUN_TYPE_MASK (IFF_TUN | IFF_TAP)
/* IFF_ATTACH_QUEUE is never stored in device flags,
* overload it to mean fasync when stored there.
*/
#define TUN_FASYNC IFF_ATTACH_QUEUE
-#define TUN_NO_PI IFF_NO_PI
-/* This flag has no real effect */
-#define TUN_ONE_QUEUE IFF_ONE_QUEUE
-#define TUN_PERSISTIFF_PERSIST
-#define TUN_VNET_HDR IFF_VNET_HDR
-#define TUN_TAP_MQ IFF_MULTI_QUEUE
#define TUN_FEATURES (IFF_NO_PI | IFF_ONE_QUEUE | IFF_VNET_HDR | \
IFF_MULTI_QUEUE)
@@ -490,7 +482,7 @@ static void __tun_detach(struct tun_file *tfile, bool clean)
if (tun && tun->numqueues == 0 && tun->numdisabled == 0) {
netif_carrier_off(tun->dev);
- if (!(tun->flags & TUN_PERSIST) &&
+ if (!(tun->flags & IFF_PERSIST) &&
tun->dev->reg_state == NETREG_REGISTERED)
unregister_netdevice(tun->dev);
}
@@ -541,7 +533,7 @@ static void tun_detach_all(struct net_device *dev)
}
BUG_ON(tun->numdisabled != 0);
- if (tun->flags & TUN_PERSIST)
+ if (tun->flags & IFF_PERSIST)
module_put(THIS_MODULE);
}
@@ -559,7 +551,7 @@ static int tun_attach(struct tun_struct *tun, struct file
*file, bool skip_filte
goto out;
err = -EBUSY;
- if (!(tun->flags & TUN_TAP_MQ) && tun->numqueues == 1)
+ if (!(tun->flags & IFF_MULTI_QUEUE) && tun->numqueues == 1)
goto out;
err = -E2BIG;
@@ -938,7 +930,7 @@ static void tun_net_init(struct net_device *dev)
struct tun_struct *tun = netdev_priv(dev);
switch (tun->flags & TUN_TYPE_MASK) {
- case TUN_TUN_DEV:
+ case IFF_TUN:
dev->netdev_ops = _netdev_ops;
/* Point-to-Point TUN Device */
@@ -952,7 +944,7 @@ static void tun_net_init(struct net_device *dev)
dev->tx_queue_len = TUN_READQ_SIZE; /* We prefer our own queue
length */
break;
- case TUN_TAP_DEV:
+ case IFF_TAP:
dev->netdev_ops = _netdev_ops;
/* Ethernet TAP Device */
ether_setup(dev);
@@ -1043,7 +1035,7 @@ static ssize_t tun_get_user(struct tun_struct *tun,
struct tun_file *tfile,
int err;
u32 rxhash;
- if (!(tun->flags & TUN_NO_PI)) {
+ if (!(tun->flags & IFF_NO_PI)) {
if (len < sizeof(pi))
return -EINVAL;
len -= sizeof(pi);
@@ -1053,7 +1045,7 @@ static ssize_t tun_get_user(struct tun_struct *tun,
struct tun_file *tfile,
offset += sizeof(pi);
}
- if (tun->flags & TUN_VNET_HDR) {
+ if (tun->flags & IFF_VNET_HDR) {
if (len < tun->vnet_hdr_sz)
return -EINVAL;
len -= tun->vnet_hdr_sz;
@@ -1070,7 +1062,7 @@ static ssize_t tun_get_user(struct tun_struct *tun,
struct tun_file *tfile,
offset += tun->vnet_hdr_sz;
}
- if ((tun->flags & TUN_TYPE_MASK) == TUN_TAP_DEV) {
+ if ((tun->flags & TUN_TYPE_MASK) == IFF_TAP) {
align += NET_IP_ALIGN;
if (unlikely(len < ETH_HLEN ||
(gso.hdr_len && __virtio16_to_cpu(false,
gso.hdr_len) < ETH_HLEN)))
@@ -1133,8 +1125,8 @@ static ssize_t tun_get_user(struct tun_struct *tun,
struct tun_file *tfile,
}
switch (tun->flags & TUN_TYPE_MASK) {
- case TUN_TUN_DEV:
- if (tun->flags & TUN_NO_PI) {
+ case IFF_TUN:
+ if (tun->flags & IFF_NO_PI) {
switch (skb->data[0] & 0xf0) {
case 0x40:
pi.proto = htons(ETH_P_IP);
@@ -1153,7 +1145,7 @@ static ssize_t tun_get_user(struct tun_struct *tun,
struct tun_file *tfile,
skb->protocol = pi.proto;
skb->dev = tun->dev;
break;
- case TUN_TAP_DEV:
+ case IFF_TAP:
skb->protocol = eth_type_trans(skb, tun->dev);
break;
}
@@ -1254,7 +1246,7 @@ static ssize_t tun_put_user(struct tun_struct *tun,
ssize_t total = 0;
int vlan_offset = 0, copied;
- if (!(tun->flags & TUN_NO_PI)) {
+ if (!(tun->flags & IFF_NO_PI)) {
[PATCH 2/3] tun: reuse IFF_ flags internally
By reusing IFF_ flags for internal tun device flags,
we can get rid of a bunch of code translating back
and forth.
This cleanup exposes a bug: TUNGETFEATURES reports IFF_TUN and IFF_TAP
which aren't legal for TUNSETFEATURES (but, correctly, doesn't report
IFF_PERSIST which also isn't legal there).
I'm not fixing this bug at the moment, just in case some weird
userspace depends on it, using TUNGETFEATURES to check device type.
Follow-up patches will get rid of some of TUN_ macros,
using IFF_ directly instead.
Signed-off-by: Michael S. Tsirkin
---
drivers/net/tun.c | 83 +++
1 file changed, 22 insertions(+), 61 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 81735f5..e4bd542 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -104,19 +104,23 @@ do {
\
#endif
/* TUN device flags */
-#define TUN_TUN_DEV0x0001
-#define TUN_TAP_DEV0x0002
-#define TUN_TYPE_MASK 0x000f
+#define TUN_TUN_DEVIFF_TUN
+#define TUN_TAP_DEVIFF_TAP
+#define TUN_TYPE_MASK (IFF_TUN | IFF_TAP)
-#define TUN_FASYNC 0x0010
-#define TUN_NOCHECKSUM 0x0020
-#define TUN_NO_PI 0x0040
+/* IFF_ATTACH_QUEUE is never stored in device flags,
+ * overload it to mean fasync when stored there.
+ */
+#define TUN_FASYNC IFF_ATTACH_QUEUE
+#define TUN_NO_PI IFF_NO_PI
/* This flag has no real effect */
-#define TUN_ONE_QUEUE 0x0080
-#define TUN_PERSIST0x0100
-#define TUN_VNET_HDR 0x0200
-#define TUN_TAP_MQ 0x0400
+#define TUN_ONE_QUEUE IFF_ONE_QUEUE
+#define TUN_PERSISTIFF_PERSIST
+#define TUN_VNET_HDR IFF_VNET_HDR
+#define TUN_TAP_MQ IFF_MULTI_QUEUE
+#define TUN_FEATURES (IFF_NO_PI | IFF_ONE_QUEUE | IFF_VNET_HDR | \
+ IFF_MULTI_QUEUE)
#define GOODCOPY_LEN 128
#define FLT_EXACT_COUNT 8
@@ -1529,32 +1533,7 @@ static struct proto tun_proto = {
static int tun_flags(struct tun_struct *tun)
{
- int flags = 0;
-
- if (tun->flags & TUN_TUN_DEV)
- flags |= IFF_TUN;
- else
- flags |= IFF_TAP;
-
- if (tun->flags & TUN_NO_PI)
- flags |= IFF_NO_PI;
-
- /* This flag has no real effect. We track the value for backwards
-* compatibility.
-*/
- if (tun->flags & TUN_ONE_QUEUE)
- flags |= IFF_ONE_QUEUE;
-
- if (tun->flags & TUN_VNET_HDR)
- flags |= IFF_VNET_HDR;
-
- if (tun->flags & TUN_TAP_MQ)
- flags |= IFF_MULTI_QUEUE;
-
- if (tun->flags & TUN_PERSIST)
- flags |= IFF_PERSIST;
-
- return flags;
+ return tun->flags & (TUN_FEATURES | IFF_PERSIST | IFF_TUN | IFF_TAP);
}
static ssize_t tun_show_flags(struct device *dev, struct device_attribute
*attr,
@@ -1714,28 +1693,8 @@ static int tun_set_iff(struct net *net, struct file
*file, struct ifreq *ifr)
tun_debug(KERN_INFO, tun, "tun_set_iff\n");
- if (ifr->ifr_flags & IFF_NO_PI)
- tun->flags |= TUN_NO_PI;
- else
- tun->flags &= ~TUN_NO_PI;
-
- /* This flag has no real effect. We track the value for backwards
-* compatibility.
-*/
- if (ifr->ifr_flags & IFF_ONE_QUEUE)
- tun->flags |= TUN_ONE_QUEUE;
- else
- tun->flags &= ~TUN_ONE_QUEUE;
-
- if (ifr->ifr_flags & IFF_VNET_HDR)
- tun->flags |= TUN_VNET_HDR;
- else
- tun->flags &= ~TUN_VNET_HDR;
-
- if (ifr->ifr_flags & IFF_MULTI_QUEUE)
- tun->flags |= TUN_TAP_MQ;
- else
- tun->flags &= ~TUN_TAP_MQ;
+ tun->flags = (tun->flags & ~TUN_FEATURES) |
+ (ifr->ifr_flags & TUN_FEATURES);
/* Make sure persistent devices do not get stuck in
* xoff state.
@@ -1898,9 +1857,11 @@ static long __tun_chr_ioctl(struct file *file, unsigned
int cmd,
if (cmd == TUNGETFEATURES) {
/* Currently this just means: "what IFF flags are valid?".
* This is needed because we never checked for invalid flags on
-* TUNSETIFF. */
- return put_user(IFF_TUN | IFF_TAP | IFF_NO_PI | IFF_ONE_QUEUE |
- IFF_VNET_HDR | IFF_MULTI_QUEUE,
+* TUNSETIFF. Why do we report IFF_TUN and IFF_TAP which are
+* not legal for TUNSETIFF here? It's probably a bug, but it
+* doesn't seem to be worth fixing.
+*/
+ return put_user(IFF_TUN | IFF_TAP | TUN_FEATURES,
(unsigned int __user*)argp);
} else if (cmd == TUNSETQUEUE)
return tun_set_queue(file, );
--
MST
--
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
Re: [PATCH 1/2] tracing: Clean up tracing_fill_pipe_page()
On Tue, 18 Nov 2014 17:15:46 +0100
Petr Mladek wrote:
> On Mon 2014-11-17 14:11:08, Steven Rostedt wrote:
> > >
> > > I don't like the fact that I did a code structure change with this
> > > patch. This patch should be just a simple conversion of len to
> > > seq_buf_used(). I'm going to strip this change out and put it before
> > > this patch.
> >
> >
> > The function tracing_fill_pipe_page() logic is a little confusing with the
> > use of count saving the seq.len and reusing it.
> >
> > Instead of subtracting a number that is calculated from the saved
> > value of the seq.len from seq.len, just save the seq.len at the start
> > and if we need to reset it, just assign it again.
> >
> > When the seq_buf overflow is len == size + 1, the current logic will
> > break. Changing it to use a saved length for resetting back to the
> > original value is more robust and will work when we change the way
> > seq_buf sets the overflow.
> >
> > Signed-off-by: Steven Rostedt
> > ---
> > kernel/trace/trace.c | 26 --
> > 1 file changed, 20 insertions(+), 6 deletions(-)
> >
> > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> > index 7d7a07e9b9e9..2dbc18e5f929 100644
> > --- a/kernel/trace/trace.c
> > +++ b/kernel/trace/trace.c
> > @@ -4575,23 +4575,37 @@ static size_t
> > tracing_fill_pipe_page(size_t rem, struct trace_iterator *iter)
> > {
> > size_t count;
> > + int save_len;
> > int ret;
> >
> > /* Seq buffer is page-sized, exactly what we need. */
> > for (;;) {
> > - count = iter->seq.seq.len;
> > + save_len = iter->seq.seq.len;
> > ret = print_trace_line(iter);
> > - count = iter->seq.seq.len - count;
> > - if (rem < count) {
> > - rem = 0;
> > - iter->seq.seq.len -= count;
> > +
> > + if (trace_seq_has_overflowed(>seq)) {
> > + iter->seq.seq.len = save_len;
> > break;
> > }
> > +
> > + /*
> > +* This should not be hit, because it should only
> > +* be set if the iter->seq overflowed. But check it
> > +* anyway to be safe.
> > +*/
> > if (ret == TRACE_TYPE_PARTIAL_LINE) {
> > - iter->seq.seq.len -= count;
> > + iter->seq.seq.len = save_len;
> > break;
> > }
>
> The two ifs has the same body. Small optimization would be to do:
>
> /*
>* The two checks should be equivalent but rather be
>* on the safe side.
>*/
> if (trace_seq_has_overflowed(>seq) ||
> ret == TRACE_TYPE_PARTIAL_LINE) {
> iter->seq.seq.len = save_len;
> break;
> }
Yeah, I originally had something like that, but I wanted to remove that
second check. I left it separate to make it stand out as something that
might be removed in the future. Just a preference I guess.
>
> To be honest, the code seems to be a bit twisted. This function
> is called from tracing_splice_read_pipe(). It copies the
> trace_seq buffer into spd.page and call trace_seq_init()
> in a for cycle.
Yeah, that splice code confused me too. I'll start looking at it some
more and see if it can be fixed up.
>
> Therefore if the overflow happens, trace_find_next_entry_inc()
> is not called in tracing_fill_pipe_page() and we work with the same
> iterator instance next time. It means that the overflow happens most
> likely again and we fill all remaining spd.pages with no data and
> are stacked on the same iterator instance.
Luckily, overflows never happen. But if they do, things might break.
>
> BTW: The trace_seq_to_buffer() in tracing_splice_read_pipe()
> is suspicious as well. It passes trace_seq_used(>seq)
> as the "cnt" parameter. I guess that it should pass the
> size of the "spd.page" instead.
Wow, I should have looked harder at that code when I accepted it. It
just "worked" and I was happy. Oh well, another thing to fix up.
>
> Also we should somehow handle the situation when some data are not
> copied. Well, it seems the spd.page has the page size, so it is
> the same size as the trace_seq buffer.
>
>
> Well, this patch does not change the behavior. We could solve the
> above problem later if it is there. Maybe I got it wrong.
No, that code doesn't look too good. That's some old stuff that got in
when we were still learning, and if it worked, we added it ;-)
That needs to be cleaned up. I'll put it on my ever growing todo list.
Of course if you want to clean it up, feel free to send some patches on
top of this. That is, if we get the OK from Linus or Andrew.
>
> Reviewed-by: Petr Mladek
>
Thanks,
-- 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
Re: [PATCH 11/16] perf hists: Fix up srcline histogram key formatting
On Wed, Nov 19, 2014 at 01:03:31PM -0300, Arnaldo Carvalho de Melo wrote: > From: Arnaldo Carvalho de Melo > > Problem introduced in: > > commit 5b5916696051 "perf report: Honor column width setting" Thanks! I'll also check what happens with --gtk. -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 1/1] DRM-tilcdc: Deletion of an unnecessary check before the function call "drm_fbdev_cma_hotplug_event"
From: Markus Elfring
Date: Wed, 19 Nov 2014 17:05:20 +0100
The drm_fbdev_cma_hotplug_event() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 000428e..335b1dc 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -58,8 +58,7 @@ static struct drm_framebuffer *tilcdc_fb_create(struct
drm_device *dev,
static void tilcdc_fb_output_poll_changed(struct drm_device *dev)
{
struct tilcdc_drm_private *priv = dev->dev_private;
- if (priv->fbdev)
- drm_fbdev_cma_hotplug_event(priv->fbdev);
+ drm_fbdev_cma_hotplug_event(priv->fbdev);
}
static const struct drm_mode_config_funcs mode_config_funcs = {
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 07/19] selftests/firmware: add install target to enable installing test
On 11/11/2014 06:06 PM, Shuah Khan wrote: > On 11/11/2014 02:29 PM, Kees Cook wrote: >> Hi, >> >> Sorry, I still really don't like this approach. While it is all in one >> place (thank you for that), I think it isn't a form that is very >> workable for the people maintaining the self tests. How about this, >> instead of per-Makefile customization, why not define an execution >> framework for these tests instead. > > If I understand correctly, sounds like you don't like the way > install target is implemented in the individual test Makefiles > and the changes I made to run_tests targets to address the code > duplication concern. > > At the moment there is no duplicate code in this patch series > between install and run_tests targets. This is a first step > towards standardizing the framework and a definite improvement > over what we have currently. As I mentioned earlier, my goal > is to make it easier for developers to install and run the > existing tests and evolve the framework as we go. > > Assuming my understanding is correct that: > > -- install and run_tests targets in individual tests can be >refined and automated with a common Makefile approach you >proposed. > -- the rest of the user-interface kselftest_install and kselftest >are good. > > I would like to propose that we get started with the current > implementation and refine it based on the following ideas you > suggested. The refinements you are recommending are confined > to selftests and can be made after the kselftest_install > gets added. Adding kselftest_install makes it easier to make > the refinements as it defines overall UI. > Hi Kees, Are you ok with the above proposal? I understand this approach might not be perfect, however it is a step in the right direction to enable and make it easier to run them. I would like to get some initial work in for 3.19 if at all possible. I plan to evolve the back-end to make it easier to write and maintain for developers writing tests going forward. thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- 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] ACPI: Add _DEP(Operation Region Dependencies) support to fix battery issue on the Asus T100TA
On Wed, Nov 19, 2014 at 11:20:41PM +0800, Lan Tianyu wrote: > ACPI 5.0 introduces _DEP to designate device objects that OSPM should > assign a higher priority in start ordering due to future operation region > accesses. > > On Asus T100TA, ACPI battery info are read from a I2C slave device via > I2C operation region. Before I2C operation region handler is installed, > battery _STA always returns 0. There is a _DEP method of designating > start order under battery device node. > > This patch is to implement _DEP feature to fix battery issue on the Asus > T100TA. > Introducing acpi_dep_list and adding dep_unmet count in the struct > acpi_device. During ACPI namespace scan, create struct acpi_dep_data for a > valid pair of master (device pointed to by _DEP)/slave(device with _DEP), > record > master's and slave's ACPI handle in it and put it into acpi_dep_list. The > dep_unmet > count will increase by one if there is a device under its _DEP. Driver's > probe() should > return EPROBE_DEFER when find dep_unmet larger than 0. When I2C operation > region handler is installed, remove all struct acpi_dep_data on the > acpi_dep_list > whose master is pointed to I2C host controller and decrease slave's dep_unmet. > When dep_unmet decreases to 0, all _DEP conditions are met and then do > acpi_bus_attach() > for the device in order to resolve battery _STA issue on the Asus T100TA. > > Reference: https://bugzilla.kernel.org/show_bug.cgi?id=69011 > Tested-by: Jan-Michael Brummer > Tested-by: Adam Williamson > Tested-by: Michael Shigorin > Signed-off-by: Lan Tianyu As long as the I2C related changes are that minimal: Acked-by: Wolfram Sang for the I2C part signature.asc Description: Digital signature
[PATCH 11/16] perf hists: Fix up srcline histogram key formatting
From: Arnaldo Carvalho de Melo
Problem introduced in:
commit 5b5916696051 "perf report: Honor column width setting"
Where the left justification signal was after the width, which ended up,
when the width was, say, 11, always printing:
%11.11-s
Instead of src:line left justified and limited to 11 chars.
Resulting in a like:
70.93% %11.11-s [.] f2 tcall
When it should instead be:
70.93% tcall.c:5[.] f2 tcall
Cc: Adrian Hunter
Cc: Andi Kleen
Cc: Borislav Petkov
Cc: David Ahern
Cc: Don Zickus
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/n/tip-2xnt0vqkoox52etq2qhye...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/sort.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 9402885a77f3..82a5596241a7 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -309,7 +309,7 @@ sort__srcline_cmp(struct hist_entry *left, struct
hist_entry *right)
static int hist_entry__srcline_snprintf(struct hist_entry *he, char *bf,
size_t size, unsigned int width)
{
- return repsep_snprintf(bf, size, "%*.*-s", width, width, he->srcline);
+ return repsep_snprintf(bf, size, "%-*.*s", width, width, he->srcline);
}
struct sort_entry sort_srcline = {
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/16] perf test: fix typo in python test
From: WANG Chao
Library loading in python syntax should be 'import perf', not 'use perf'.
Signed-off-by: WANG Chao
Cc: Adrian Hunter
Cc: Ingo Molnar
Cc: Jean Pihet
Cc: Jiri Olsa
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1415780826-13250-1-git-send-email-chaow...@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/tests/builtin-test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
index 162c978f1491..4b7d9ab0f049 100644
--- a/tools/perf/tests/builtin-test.c
+++ b/tools/perf/tests/builtin-test.c
@@ -85,7 +85,7 @@ static struct test {
.func = test__hists_link,
},
{
- .desc = "Try 'use perf' in python, checking link problems",
+ .desc = "Try 'import perf' in python, checking link problems",
.func = test__python_use,
},
{
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/16] perf tools: Fix annotation with kcore
From: Adrian Hunter
Patch "perf tools: Fix build-id matching on vmlinux" breaks annotation
with kcore. The problem is that symbol__annotate() first gets the
filename based on the build-id which was previously not set.
This patch provides a quick fix, however there should probably be only
one way to determine the filename. e.g. symbol__annotate() should use
the same way as dso__data_fd().
Signed-off-by: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1415700294-30816-1-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/annotate.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 7dabde14ea54..873c8778db20 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -915,6 +915,8 @@ int symbol__annotate(struct symbol *sym, struct map *map,
size_t privsize)
return -ENOMEM;
}
goto fallback;
+ } else if (dso__is_kcore(dso)) {
+ goto fallback;
} else if (readlink(symfs_filename, command, sizeof(command)) < 0 ||
strstr(command, "[kernel.kallsyms]") ||
access(symfs_filename, R_OK)) {
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/16] perf annotate: Support source line numbers in annotate
From: Andi Kleen
With srcline key/sort'ing it's useful to have line numbers in the
annotate window. This patch implements this.
Use objdump -l to request the line numbers and save them in the line
structure. Then the browser displays them for source lines.
The line numbers are not displayed by default, but can be toggled on
with 'k'
There is one unfortunate problem with this setup. For lines not
containing source and which are outside functions objdump -l reports
line numbers off by a few: it always reports the first line number in
the next function even for lines that are outside the function.
I haven't found a nice way to detect/correct this. Probably objdump has
to be fixed.
See https://sourceware.org/bugzilla/show_bug.cgi?id=16433
The line numbers are still useful even with these problems, as most are
correct and the ones which are not are nearby.
v2: Fix help text. Handle (discriminator...) output in objdump.
Left align the line numbers.
Signed-off-by: Andi Kleen
Cc: Jiri Olsa
Cc: Namhyung Kim
Link:
http://lkml.kernel.org/r/1415844328-4884-9-git-send-email-a...@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/ui/browsers/annotate.c | 13 -
tools/perf/util/annotate.c| 30 +-
tools/perf/util/annotate.h| 1 +
3 files changed, 38 insertions(+), 6 deletions(-)
diff --git a/tools/perf/ui/browsers/annotate.c
b/tools/perf/ui/browsers/annotate.c
index f0697a3aede0..1e0a2fd80115 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -27,6 +27,7 @@ static struct annotate_browser_opt {
bool hide_src_code,
use_offset,
jump_arrows,
+show_linenr,
show_nr_jumps;
} annotate_browser__opts = {
.use_offset = true,
@@ -128,7 +129,11 @@ static void annotate_browser__write(struct ui_browser
*browser, void *entry, int
if (!*dl->line)
slsmg_write_nstring(" ", width - pcnt_width);
else if (dl->offset == -1) {
- printed = scnprintf(bf, sizeof(bf), "%*s ",
+ if (dl->line_nr && annotate_browser__opts.show_linenr)
+ printed = scnprintf(bf, sizeof(bf), "%-*d ",
+ ab->addr_width + 1, dl->line_nr);
+ else
+ printed = scnprintf(bf, sizeof(bf), "%*s ",
ab->addr_width, " ");
slsmg_write_nstring(bf, printed);
slsmg_write_nstring(dl->line, width - printed - pcnt_width + 1);
@@ -733,6 +738,7 @@ static int annotate_browser__run(struct annotate_browser
*browser,
"o Toggle disassembler output/simplified view\n"
"s Toggle source code view\n"
"/ Search string\n"
+ "k Toggle line numbers\n"
"r Run available scripts\n"
"? Search string backwards\n");
continue;
@@ -741,6 +747,10 @@ static int annotate_browser__run(struct annotate_browser
*browser,
script_browse(NULL);
continue;
}
+ case 'k':
+ annotate_browser__opts.show_linenr =
+ !annotate_browser__opts.show_linenr;
+ break;
case 'H':
nd = browser->curr_hot;
break;
@@ -984,6 +994,7 @@ static struct annotate_config {
} annotate__configs[] = {
ANNOTATE_CFG(hide_src_code),
ANNOTATE_CFG(jump_arrows),
+ ANNOTATE_CFG(show_linenr),
ANNOTATE_CFG(show_nr_jumps),
ANNOTATE_CFG(use_offset),
};
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 873c8778db20..e5670f1af737 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -17,11 +17,13 @@
#include "debug.h"
#include "annotate.h"
#include "evsel.h"
+#include
#include
#include
const char *disassembler_style;
const char *objdump_path;
+static regex_t file_lineno;
static struct ins *ins__find(const char *name);
static int disasm_line__parse(char *line, char **namep, char **rawp);
@@ -570,13 +572,15 @@ out_free_name:
return -1;
}
-static struct disasm_line *disasm_line__new(s64 offset, char *line, size_t
privsize)
+static struct disasm_line *disasm_line__new(s64 offset, char *line,
+ size_t privsize, int line_nr)
{
struct disasm_line *dl = zalloc(sizeof(*dl) + privsize);
if (dl != NULL) {
dl->offset = offset;
dl->line = strdup(line);
+ dl->line_nr = line_nr;
if (dl->line == NULL)
goto out_delete;
@@ -788,13 +792,15 @@ static int
[PATCH 08/16] perf callchain: Use a common function to resolve symbol or name
From: Andi Kleen
Refactor the duplicated code to resolve the symbol name or
the address of a symbol into a single function.
Used in next patch to add common functionality.
Signed-off-by: Andi Kleen
Cc: Jiri Olsa
Cc: Namhyung Kim
Link:
http://lkml.kernel.org/r/1415844328-4884-6-git-send-email-a...@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/ui/browsers/hists.c | 17 -
tools/perf/ui/gtk/hists.c | 11 +--
tools/perf/ui/stdio/hist.c | 23 +--
tools/perf/util/callchain.c| 19 +++
tools/perf/util/callchain.h| 3 +++
5 files changed, 32 insertions(+), 41 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index cfb976b3de3a..12c17c5a3d68 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -463,23 +463,6 @@ out:
return key;
}
-static char *callchain_list__sym_name(struct callchain_list *cl,
- char *bf, size_t bfsize, bool show_dso)
-{
- int printed;
-
- if (cl->ms.sym)
- printed = scnprintf(bf, bfsize, "%s", cl->ms.sym->name);
- else
- printed = scnprintf(bf, bfsize, "%#" PRIx64, cl->ip);
-
- if (show_dso)
- scnprintf(bf + printed, bfsize - printed, " %s",
- cl->ms.map ? cl->ms.map->dso->short_name : "unknown");
-
- return bf;
-}
-
struct callchain_print_arg {
/* for hists browser */
off_t row_offset;
diff --git a/tools/perf/ui/gtk/hists.c b/tools/perf/ui/gtk/hists.c
index fc654fb77ace..4b3585eed1e8 100644
--- a/tools/perf/ui/gtk/hists.c
+++ b/tools/perf/ui/gtk/hists.c
@@ -89,15 +89,6 @@ void perf_gtk__init_hpp(void)
perf_gtk__hpp_color_overhead_acc;
}
-static void callchain_list__sym_name(struct callchain_list *cl,
-char *bf, size_t bfsize)
-{
- if (cl->ms.sym)
- scnprintf(bf, bfsize, "%s", cl->ms.sym->name);
- else
- scnprintf(bf, bfsize, "%#" PRIx64, cl->ip);
-}
-
static void perf_gtk__add_callchain(struct rb_root *root, GtkTreeStore *store,
GtkTreeIter *parent, int col, u64 total)
{
@@ -128,7 +119,7 @@ static void perf_gtk__add_callchain(struct rb_root *root,
GtkTreeStore *store,
scnprintf(buf, sizeof(buf), "%5.2f%%", percent);
gtk_tree_store_set(store, , 0, buf, -1);
- callchain_list__sym_name(chain, buf, sizeof(buf));
+ callchain_list__sym_name(chain, buf, sizeof(buf),
false);
gtk_tree_store_set(store, , col, buf, -1);
if (need_new_parent) {
diff --git a/tools/perf/ui/stdio/hist.c b/tools/perf/ui/stdio/hist.c
index 15b451acbde6..dfcbc90146ef 100644
--- a/tools/perf/ui/stdio/hist.c
+++ b/tools/perf/ui/stdio/hist.c
@@ -41,6 +41,7 @@ static size_t ipchain__fprintf_graph(FILE *fp, struct
callchain_list *chain,
{
int i;
size_t ret = 0;
+ char bf[1024];
ret += callchain__fprintf_left_margin(fp, left_margin);
for (i = 0; i < depth; i++) {
@@ -56,11 +57,8 @@ static size_t ipchain__fprintf_graph(FILE *fp, struct
callchain_list *chain,
} else
ret += fprintf(fp, "%s", " ");
}
- if (chain->ms.sym)
- ret += fprintf(fp, "%s\n", chain->ms.sym->name);
- else
- ret += fprintf(fp, "0x%0" PRIx64 "\n", chain->ip);
-
+ fputs(callchain_list__sym_name(chain, bf, sizeof(bf), false), fp);
+ fputc('\n', fp);
return ret;
}
@@ -168,6 +166,7 @@ static size_t callchain__fprintf_graph(FILE *fp, struct
rb_root *root,
struct rb_node *node;
int i = 0;
int ret = 0;
+ char bf[1024];
/*
* If have one single callchain root, don't bother printing
@@ -196,10 +195,8 @@ static size_t callchain__fprintf_graph(FILE *fp, struct
rb_root *root,
} else
ret += callchain__fprintf_left_margin(fp,
left_margin);
- if (chain->ms.sym)
- ret += fprintf(fp, " %s\n",
chain->ms.sym->name);
- else
- ret += fprintf(fp, " %p\n", (void
*)(long)chain->ip);
+ ret += fprintf(fp, "%s\n",
callchain_list__sym_name(chain, bf, sizeof(bf),
+ false));
if (++entries_printed == callchain_param.print_limit)
break;
@@ -219,6 +216,7 @@ static size_t __callchain__fprintf_flat(FILE *fp, struct
callchain_node *node,
{
struct callchain_list *chain;
size_t ret = 0;
+ char bf[1024];
if (!node)
return 0;
@@
Re: [PATCH] thermal: sti: Ignore suspend/resume functions when !PM
On Wed, Nov 19, 2014 at 1:50 PM, Lee Jones wrote: > Prevents build warning: > > st_thermal.c:278:12: > warning: ‘st_thermal_suspend’ defined but not used [-Wunused-function] > st_thermal.c:286:12: > warning: ‘st_thermal_resume’ defined but not used [-Wunused-function] > > Signed-off-by: Lee Jones > --- > > v1 => v2: > - CONFIG_PM => CONFIG_PM_SLEEP suggested by David Paris. You should also update the Subject to 'when !PM_SLEEP' -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] ARM: option for loading modules into vmalloc area
On Wed, Nov 19, 2014 at 05:02:40PM +0100, Ard Biesheuvel wrote: > On 19 November 2014 16:52, Konstantin Khlebnikov wrote: > > Do you mean ldr pc, =symbol ? > > > > In this case I get this error: > > > > /tmp/ccAHtONU.s: Assembler messages: > > /tmp/ccAHtONU.s:220: Error: invalid literal constant: pool needs to be > > closer > > > > Probably constant pool doesn't work well in inline assembly. > > > > > > Something like this seems work: > > > > add lr, pc, #4 > > ldr pc, [pc, #-4] > > .long symbol > > > > You can add a '.ltorg' instruction which tells the assembler to dump > the literal pool, but you still need to jump over it, i.e., > > adr lr, 0f > ldr pc, =symbol > .ltorg > 0: Which is not a good idea either, because the compiler needs to know how far away its own manually generated literal pool is from the instructions which reference it. The .ltorg statement can end up emitting any number of literals at that point, which makes it indeterminant how many words are contained within the asm() statement. Yes, it isn't desirable to waste an entire data cache line per indirect call like the original quote above, but I don't see a practical alternative. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- 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/6] x86, acpi, pci: Reorder logic of pci_mmconfig_insert() function
This patch is the first step of MMCONFIG refactoring process.
Code that uses pci_mmcfg_lock will be moved to common file and become
accessible for all architectures. pci_mmconfig_insert() cannot be moved
so easily since it is mixing generic mmcfg code with x86 specific logic
inside of mutual exclusive block guarded by pci_mmcfg_lock.
To get rid of that constraint we reorder actions as fallow:
1. mmconfig entry allocation can be done at first, does not need lock
2. insertion to iomem_resource has its own lock, no need to wrap it into mutex
3. insertion to mmconfig list can be done as the final stage in separate
function (candidate for further factoring)
Signed-off-by: Tomasz Nowicki
Tested-by: Hanjun Guo
---
arch/x86/pci/mmconfig-shared.c | 100 ++---
1 file changed, 54 insertions(+), 46 deletions(-)
diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index 326198a..ac24e1c 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -692,6 +692,39 @@ static int __init pci_mmcfg_late_insert_resources(void)
*/
late_initcall(pci_mmcfg_late_insert_resources);
+static int __init pci_mmconfig_inject(struct pci_mmcfg_region *cfg)
+{
+ struct pci_mmcfg_region *cfg_conflict;
+ int err = 0;
+
+ mutex_lock(_mmcfg_lock);
+ cfg_conflict = pci_mmconfig_lookup(cfg->segment, cfg->start_bus);
+ if (cfg_conflict) {
+ if (cfg_conflict->end_bus < cfg->end_bus)
+ pr_info(FW_INFO "MMCONFIG for "
+ "domain %04x [bus %02x-%02x] "
+ "only partially covers this bridge\n",
+ cfg_conflict->segment, cfg_conflict->start_bus,
+ cfg_conflict->end_bus);
+ err = -EEXIST;
+ goto out;
+ }
+
+ if (pci_mmcfg_arch_map(cfg)) {
+ pr_warn("fail to map MMCONFIG %pR.\n", >res);
+ err = -ENOMEM;
+ goto out;
+ } else {
+ list_add_sorted(cfg);
+ pr_info("MMCONFIG at %pR (base %#lx)\n",
+ >res, (unsigned long)cfg->address);
+
+ }
+out:
+ mutex_unlock(_mmcfg_lock);
+ return err;
+}
+
/* Add MMCFG information for host bridges */
int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
phys_addr_t addr)
@@ -703,66 +736,41 @@ int pci_mmconfig_insert(struct device *dev, u16 seg, u8
start, u8 end,
if (!(pci_probe & PCI_PROBE_MMCONF) || pci_mmcfg_arch_init_failed)
return -ENODEV;
- if (start > end)
+ if (start > end || !addr)
return -EINVAL;
- mutex_lock(_mmcfg_lock);
- cfg = pci_mmconfig_lookup(seg, start);
- if (cfg) {
- if (cfg->end_bus < end)
- dev_info(dev, FW_INFO
-"MMCONFIG for "
-"domain %04x [bus %02x-%02x] "
-"only partially covers this bridge\n",
- cfg->segment, cfg->start_bus, cfg->end_bus);
- mutex_unlock(_mmcfg_lock);
- return -EEXIST;
- }
-
- if (!addr) {
- mutex_unlock(_mmcfg_lock);
- return -EINVAL;
- }
-
rc = -EBUSY;
cfg = pci_mmconfig_alloc(seg, start, end, addr);
if (cfg == NULL) {
dev_warn(dev, "fail to add MMCONFIG (out of memory)\n");
- rc = -ENOMEM;
+ return -ENOMEM;
} else if (!pci_mmcfg_check_reserved(dev, cfg, 0)) {
dev_warn(dev, FW_BUG "MMCONFIG %pR isn't reserved\n",
>res);
- } else {
- /* Insert resource if it's not in boot stage */
- if (pci_mmcfg_running_state)
- tmp = insert_resource_conflict(_resource,
- >res);
-
- if (tmp) {
- dev_warn(dev,
-"MMCONFIG %pR conflicts with "
-"%s %pR\n",
->res, tmp->name, tmp);
- } else if (pci_mmcfg_arch_map(cfg)) {
- dev_warn(dev, "fail to map MMCONFIG %pR.\n",
->res);
- } else {
- list_add_sorted(cfg);
- dev_info(dev, "MMCONFIG at %pR (base %#lx)\n",
->res, (unsigned long)addr);
- cfg = NULL;
- rc = 0;
- }
+ goto error;
}
- if (cfg) {
- if (cfg->res.parent)
- release_resource(>res);
- kfree(cfg);
+ /* Insert resource if it's not in boot stage */
+ if
Re: Looking for good references for ARM driver development
Hello Andreas, On 19/11/2014 16:02, Andreas Färber wrote: Am 19.11.2014 um 13:50 schrieb Mason: [...] I'm writing a driver for a temperature sensor, which is supposed to work within the hwmon/lm-sensors framework. The sensor's API consists of 3 memory-mapped registers, which are accessible over the SoC's memory bus. [...] 1) Which bus should I be using for this driver? Is the platform bus appropriate? Probably. Is there an exhaustive list of available buses (on the ARM platform) and an overview of when/where each one is appropriate? 2) platform.txt states Some drivers are not fully converted to the driver model, because they take on a non-driver role: the driver registers its platform device, rather than leaving that for system infrastructure. Such drivers can't be hotplugged or coldplugged, since those mechanisms require device creation to be in a different system component than the driver. How do I "leave device registration for the system infrastructure"? Where should I put that code? Is it a good idea to separate device registration and driver registration in the case of a SoC, where the device is embedded in the SoC and is not "hot-plugged" (or anything-plugged for that matter, it's just "there"). Since this appears to be about an ARM SoC according to your To list, in general, you create a device tree binding, that binding is registered within your platform/... driver code and referenced in the device tree for SoC or board, and then your driver will automatically be probed. I know nothing about DT (aside from the Wikipedia entry). I'll take a closer look at Documentation/devicetree. Will that explain what platform/... is? I see a drivers/platform folder, but nothing ARM-specific there? 4) Can I use platform_driver_probe, instead of platform_driver_register? Most likely you do not need to call either yourself. Hmmm, color me even more confused. I had really come to believe that driver registration was a mandatory part of the driver, something that wasn't left to "infrastructure code". Just compare other platform drivers on the one hand, and temperature sensor drivers on the other (such as I2C based gmt,g781 / LM90). Did you already check whether there is a driver that is both? Please excuse my naive question: what are platform drivers, and where are they stored in the kernel source tree? Regards. -- 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] Repeated fork() causes SLAB to grow without bound
On 11/19/2014 03:36 PM, Konstantin Khlebnikov wrote: > On Wed, Nov 19, 2014 at 2:50 AM, Vlastimil Babka wrote: >> On 11/19/2014 12:02 AM, Konstantin Khlebnikov wrote: >>> On Wed, Nov 19, 2014 at 1:15 AM, Konstantin Khlebnikov >>> wrote: On Tue, Nov 18, 2014 at 11:19 PM, Andrew Morton wrote: > On Mon, 17 Nov 2014 21:41:57 -0500 Rik van Riel wrote: > >> > Because of the serial forking there does indeed end up being an >> > infinite number of vmas. The initial vma can never be deleted >> > (even though the initial parent process has long since terminated) >> > because the initial vma is referenced by the children. >> >> There is a finite number of VMAs, but an infite number of >> anon_vmas. >> >> Subtle, yet deadly... > > Well, we clearly have the data structures screwed up. I've forgotten > enough about this code for me to be unable to work out what the fixed > up data structures would look like :( But surely there is some proper > solution here. Help? Not sure if it's right but probably we could reuse on fork an old anon_vma from the chain if it's already lost all vmas which points to it. For endlessly forking exploit this should work mostly like proposed patch which stops branching after some depth but without magic constant. >>> >>> Something like this. I leave proper comment for tomorrow. >> >> Hmm I'm not sure that will work as it is. If I understand it correctly, your >> patch can detect if the parent's anon_vma has no own references at the fork() >> time. But at the fork time, the parent is still alive, it only exits after >> the >> fork, right? So I guess it still has own references and the child will still >> allocate its new anon_vma, and the problem is not solved. > > But it could reuse anon_vma from grandparent or older. > Count of anon_vmas in chain will be limited with count of alive processes. Ah I missed that it can reuse older anon_vma, sorry. > I think it's better to describe this in terms of sets of anon_vma > instead hierarchy: > at clone vma inherits pages from parent together with set of anon_vma > which they belong. > For new pages it might allocate new anon_vma or reuse existing. After > my patch vma > will try to reuse anon_vma from that set which has no vmas which points to it. > As a result there will be no parent-child relation between anon_vma and > multiple pages might have equal (anon_vma, index) pair but I see no > problems here. Hmm I wonder if root anon_vma should be excluded from this reusal. For performance reasons, exclusive pages go to non-root anon_vma (see __page_set_anon_rmap()) and reusing root anon_vma would change this. Also from reading http://lwn.net/Articles/383162/ I understand that correctness also depends on the hierarchy and I wonder if there's a danger of reintroducing a bug like the one described there. Vlastimil >> >> So maybe we could detect that the own references dropped to zero when the >> parent >> does exit, and then change mapping of all relevant pages to the root >> anon_vma, >> destroy avc's of children and the anon_vma itself. But that sounds quite >> heavyweight :/ >> >> Vlastimil >> > >> > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 16/16] perf tools: Only override the default :tid comm entry
From: Adrian Hunter
Events may still be ordered even if there are no timestamps e.g. if the
data is recorded per-thread.
Also synthesized COMM events have a timestamp of zero.
Consequently it is better to keep comm entries even if they have a
timestamp of zero.
However, when a struct thread is created the command string is not known
and a comm entry with a string of the form ":" is used.
In that case thread->comm_set is false and the comm entry should be
overridden.
Signed-off-by: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1415715423-15563-4-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/thread.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c
index a2157f0ef1df..9ebc8b1f9be5 100644
--- a/tools/perf/util/thread.c
+++ b/tools/perf/util/thread.c
@@ -103,15 +103,14 @@ struct comm *thread__exec_comm(const struct thread
*thread)
return last;
}
-/* CHECKME: time should always be 0 if event aren't ordered */
int __thread__set_comm(struct thread *thread, const char *str, u64 timestamp,
bool exec)
{
struct comm *new, *curr = thread__comm(thread);
int err;
- /* Override latest entry if it had no specific time coverage */
- if (!curr->start && !curr->exec) {
+ /* Override the default :tid entry */
+ if (!thread->comm_set) {
err = comm__override(curr, str, timestamp, exec);
if (err)
return err;
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] x86, acpi, pci: mmconfig_{32,64}.c code refactoring - remove code duplication.
mmconfig_64.c version is going to be default implementation for arch
agnostic low-level direct PCI config space accessors via MMCONFIG.
However, now it initialize raw_pci_ext_ops pointer which is used in
x86 specific code only. Moreover, mmconfig_32.c is doing the same thing
at the same time.
Move it to mmconfig_shared.c so it becomes common for both and
mmconfig_64.c turns out to be purely arch agnostic.
Signed-off-by: Tomasz Nowicki
Tested-by: Hanjun Guo
---
arch/x86/pci/mmconfig-shared.c | 10 --
arch/x86/pci/mmconfig_32.c | 10 ++
arch/x86/pci/mmconfig_64.c | 6 ++
include/linux/mmconfig.h | 4
4 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index b397544..e42004c 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -29,6 +29,11 @@
static bool pci_mmcfg_running_state;
static bool pci_mmcfg_arch_init_failed;
+const struct pci_raw_ops pci_mmcfg = {
+ .read = pci_mmcfg_read,
+ .write =pci_mmcfg_write,
+};
+
static const char *__init pci_mmcfg_e7520(void)
{
u32 win;
@@ -486,9 +491,10 @@ static void __init __pci_mmcfg_init(int early)
}
}
- if (pci_mmcfg_arch_init())
+ if (pci_mmcfg_arch_init()) {
+ raw_pci_ext_ops = _mmcfg;
pci_probe = (pci_probe & ~PCI_PROBE_MASK) | PCI_PROBE_MMCONF;
- else {
+ } else {
free_all_mmcfg();
pci_mmcfg_arch_init_failed = true;
}
diff --git a/arch/x86/pci/mmconfig_32.c b/arch/x86/pci/mmconfig_32.c
index d774672..c0106a6 100644
--- a/arch/x86/pci/mmconfig_32.c
+++ b/arch/x86/pci/mmconfig_32.c
@@ -50,7 +50,7 @@ static void pci_exp_set_dev_base(unsigned int base, int bus,
int devfn)
}
}
-static int pci_mmcfg_read(unsigned int seg, unsigned int bus,
+int pci_mmcfg_read(unsigned int seg, unsigned int bus,
unsigned int devfn, int reg, int len, u32 *value)
{
unsigned long flags;
@@ -89,7 +89,7 @@ err: *value = -1;
return 0;
}
-static int pci_mmcfg_write(unsigned int seg, unsigned int bus,
+int pci_mmcfg_write(unsigned int seg, unsigned int bus,
unsigned int devfn, int reg, int len, u32 value)
{
unsigned long flags;
@@ -126,15 +126,9 @@ static int pci_mmcfg_write(unsigned int seg, unsigned int
bus,
return 0;
}
-const struct pci_raw_ops pci_mmcfg = {
- .read = pci_mmcfg_read,
- .write =pci_mmcfg_write,
-};
-
int __init pci_mmcfg_arch_init(void)
{
printk(KERN_INFO "PCI: Using MMCONFIG for extended config space\n");
- raw_pci_ext_ops = _mmcfg;
return 1;
}
diff --git a/arch/x86/pci/mmconfig_64.c b/arch/x86/pci/mmconfig_64.c
index 1209596..ff2c50c 100644
--- a/arch/x86/pci/mmconfig_64.c
+++ b/arch/x86/pci/mmconfig_64.c
@@ -25,7 +25,7 @@ static char __iomem *pci_dev_base(unsigned int seg, unsigned
int bus, unsigned i
return NULL;
}
-static int pci_mmcfg_read(unsigned int seg, unsigned int bus,
+int pci_mmcfg_read(unsigned int seg, unsigned int bus,
unsigned int devfn, int reg, int len, u32 *value)
{
char __iomem *addr;
@@ -59,7 +59,7 @@ err: *value = -1;
return 0;
}
-static int pci_mmcfg_write(unsigned int seg, unsigned int bus,
+int pci_mmcfg_write(unsigned int seg, unsigned int bus,
unsigned int devfn, int reg, int len, u32 value)
{
char __iomem *addr;
@@ -121,8 +121,6 @@ int __init pci_mmcfg_arch_init(void)
return 0;
}
- raw_pci_ext_ops = _mmcfg;
-
return 1;
}
diff --git a/include/linux/mmconfig.h b/include/linux/mmconfig.h
index 6ccd1ee..ae8ec83 100644
--- a/include/linux/mmconfig.h
+++ b/include/linux/mmconfig.h
@@ -43,6 +43,10 @@ int pci_mmcfg_arch_init(void);
void pci_mmcfg_arch_free(void);
int pci_mmcfg_arch_map(struct pci_mmcfg_region *cfg);
void pci_mmcfg_arch_unmap(struct pci_mmcfg_region *cfg);
+int pci_mmcfg_read(unsigned int seg, unsigned int bus,
+ unsigned int devfn, int reg, int len, u32 *value);
+int pci_mmcfg_write(unsigned int seg, unsigned int bus,
+ unsigned int devfn, int reg, int len, u32 value);
extern struct list_head pci_mmcfg_list;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] usb: dwc2: resume root hub when device detect with suspend state
On 18.11.2014 18:41, Felipe Balbi wrote:
> On Tue, Nov 18, 2014 at 11:07:34AM -0500, Alan Stern wrote:
>> On Tue, 18 Nov 2014, Kever Yang wrote:
>>
>>> After we implement the bus_suspend/resume, auto suspend id enabled.
>>> The root hub will be auto suspend if there is no device connected,
>>> we need to resume the root hub when a device connect detect.
>>>
>>> This patch tested on rk3288.
>>>
>>> Signed-off-by: Roy Li
>>> Signed-off-by: Kever Yang
>>> ---
>>>
>>> Changes in v2:
>>> - add definition for hcd structure
>>> - remove check for bus->root_hub
>>>
>>> drivers/usb/dwc2/hcd_intr.c | 5 +
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c
>>> index 551ba87..680206f 100644
>>> --- a/drivers/usb/dwc2/hcd_intr.c
>>> +++ b/drivers/usb/dwc2/hcd_intr.c
>>> @@ -329,6 +329,7 @@ static void dwc2_port_intr(struct dwc2_hsotg *hsotg)
>>> {
>>> u32 hprt0;
>>> u32 hprt0_modify;
>>> + struct usb_hcd *hcd = (struct usb_hcd *)hsotg->priv;
>>>
>>> dev_vdbg(hsotg->dev, "--Port Interrupt--\n");
>>>
>>> @@ -354,6 +355,10 @@ static void dwc2_port_intr(struct dwc2_hsotg *hsotg)
>>> hsotg->flags.b.port_connect_status = 1;
>>> hprt0_modify |= HPRT0_CONNDET;
>>>
>>> + /* resume root hub? */
>>> + if (hcd->state == HC_STATE_SUSPENDED)
>>> + usb_hcd_resume_root_hub(hcd);
>>
>> You should be aware that it's not safe to use hcd->state for anything
>> in a host controller driver. That field is owned by usbcore, not by
>> the HCD, and it is not protected by any locks.
>>
>> Thus, for example, hcd->state does not get set to HC_STATE_SUSPENDED
>> until some time after the bus_suspend routine has returned. A
>> port-change interrupt might occur during that time interval.
>
> In that case, XHCI has a bug :-) Mathias, care to add it to your TODO
> list ?
>
I guess I'll need to check it out, thanks for pointing it out.
-Mathias
--
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/6] pci, acpi: Share ACPI PCI config space accessors.
MMCFG can be used perfectly for all architectures which support ACPI.
ACPI mandates MMCFG to describe PCI config space ranges which means
we should use MMCONFIG accessors by default.
Signed-off-by: Tomasz Nowicki
Tested-by: Hanjun Guo
---
drivers/acpi/mmconfig.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/acpi/mmconfig.c b/drivers/acpi/mmconfig.c
index c0ad05f..c9c6e05 100644
--- a/drivers/acpi/mmconfig.c
+++ b/drivers/acpi/mmconfig.c
@@ -23,6 +23,26 @@ static DEFINE_MUTEX(pci_mmcfg_lock);
LIST_HEAD(pci_mmcfg_list);
+/*
+ * raw_pci_read/write - ACPI PCI config space accessors.
+ *
+ * ACPI spec defines MMCFG as the way we can access PCI config space,
+ * so let MMCFG be default (__weak).
+ *
+ * If platform needs more fancy stuff, should provides its own implementation.
+ */
+int __weak raw_pci_read(unsigned int domain, unsigned int bus,
+ unsigned int devfn, int reg, int len, u32 *val)
+{
+ return pci_mmcfg_read(domain, bus, devfn, reg, len, val);
+}
+
+int __weak raw_pci_write(unsigned int domain, unsigned int bus,
+unsigned int devfn, int reg, int len, u32 val)
+{
+ return pci_mmcfg_write(domain, bus, devfn, reg, len, val);
+}
+
static char __iomem *pci_dev_base(unsigned int seg, unsigned int bus,
unsigned int devfn)
{
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] x86, acpi, pci: Move PCI config space accessors.
We are going to use mmio_config_{} name convention across all architectures.
Currently it belongs to asm/pci_x86.h header which should be included
only for x86 specific files. From now on, those accessors are in asm/pci.h
header which can be included in non-architecture code much easier.
Signed-off-by: Tomasz Nowicki
Tested-by: Hanjun Guo
---
arch/x86/include/asm/pci.h | 42 +
arch/x86/include/asm/pci_x86.h | 43 --
2 files changed, 42 insertions(+), 43 deletions(-)
diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index 0892ea0..5ba3720 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -71,6 +71,48 @@ void pcibios_set_master(struct pci_dev *dev);
struct irq_routing_table *pcibios_get_irq_routing_table(void);
int pcibios_set_irq_routing(struct pci_dev *dev, int pin, int irq);
+/*
+ * AMD Fam10h CPUs are buggy, and cannot access MMIO config space
+ * on their northbrige except through the * %eax register. As such, you MUST
+ * NOT use normal IOMEM accesses, you need to only use the magic mmio-config
+ * accessor functions.
+ * In fact just use pci_config_*, nothing else please.
+ */
+static inline unsigned char mmio_config_readb(void __iomem *pos)
+{
+ u8 val;
+ asm volatile("movb (%1),%%al" : "=a" (val) : "r" (pos));
+ return val;
+}
+
+static inline unsigned short mmio_config_readw(void __iomem *pos)
+{
+ u16 val;
+ asm volatile("movw (%1),%%ax" : "=a" (val) : "r" (pos));
+ return val;
+}
+
+static inline unsigned int mmio_config_readl(void __iomem *pos)
+{
+ u32 val;
+ asm volatile("movl (%1),%%eax" : "=a" (val) : "r" (pos));
+ return val;
+}
+
+static inline void mmio_config_writeb(void __iomem *pos, u8 val)
+{
+ asm volatile("movb %%al,(%1)" : : "a" (val), "r" (pos) : "memory");
+}
+
+static inline void mmio_config_writew(void __iomem *pos, u16 val)
+{
+ asm volatile("movw %%ax,(%1)" : : "a" (val), "r" (pos) : "memory");
+}
+
+static inline void mmio_config_writel(void __iomem *pos, u32 val)
+{
+ asm volatile("movl %%eax,(%1)" : : "a" (val), "r" (pos) : "memory");
+}
#define HAVE_PCI_MMAP
extern int pci_mmap_page_range(struct pci_dev *dev, struct vm_area_struct *vma,
diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index caba141..42e7332 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -121,49 +121,6 @@ extern int __init pcibios_init(void);
extern int pci_legacy_init(void);
extern void pcibios_fixup_irqs(void);
-/*
- * AMD Fam10h CPUs are buggy, and cannot access MMIO config space
- * on their northbrige except through the * %eax register. As such, you MUST
- * NOT use normal IOMEM accesses, you need to only use the magic mmio-config
- * accessor functions.
- * In fact just use pci_config_*, nothing else please.
- */
-static inline unsigned char mmio_config_readb(void __iomem *pos)
-{
- u8 val;
- asm volatile("movb (%1),%%al" : "=a" (val) : "r" (pos));
- return val;
-}
-
-static inline unsigned short mmio_config_readw(void __iomem *pos)
-{
- u16 val;
- asm volatile("movw (%1),%%ax" : "=a" (val) : "r" (pos));
- return val;
-}
-
-static inline unsigned int mmio_config_readl(void __iomem *pos)
-{
- u32 val;
- asm volatile("movl (%1),%%eax" : "=a" (val) : "r" (pos));
- return val;
-}
-
-static inline void mmio_config_writeb(void __iomem *pos, u8 val)
-{
- asm volatile("movb %%al,(%1)" : : "a" (val), "r" (pos) : "memory");
-}
-
-static inline void mmio_config_writew(void __iomem *pos, u16 val)
-{
- asm volatile("movw %%ax,(%1)" : : "a" (val), "r" (pos) : "memory");
-}
-
-static inline void mmio_config_writel(void __iomem *pos, u32 val)
-{
- asm volatile("movl %%eax,(%1)" : : "a" (val), "r" (pos) : "memory");
-}
-
#ifdef CONFIG_PCI
# ifdef CONFIG_ACPI
# define x86_default_pci_init pci_acpi_init
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 2/3] kernel: add support for live patching
On Wed, Nov 19, 2014 at 04:27:39PM +0100, Miroslav Benes wrote:
>
> Hi,
>
> during rewriting our code I came across few more things. See below.
>
> On Sun, 16 Nov 2014, Seth Jennings wrote:
>
> [...]
>
> > +/**
> > + * module notifier
> > + */
> > +
> > +static void lpc_module_notify_coming(struct module *pmod,
> > +struct lpc_object *obj)
> > +{
> > + struct module *mod = obj->mod;
> > + int ret;
> > +
> > + pr_notice("applying patch '%s' to loading module '%s'\n",
> > + mod->name, pmod->name);
>
> This looks strange. I guess the arguments should be swapped.
Indeed, you are correct :)
>
> > + obj->mod = mod;
>
> And this is redundant.
True again!
>
> > + ret = lpc_enable_object(pmod, obj);
> > + if (ret)
> > + pr_warn("failed to apply patch '%s' to module '%s' (%d)\n",
> > + pmod->name, mod->name, ret);
> > +}
> > +
> > +static void lpc_module_notify_going(struct module *pmod,
> > + struct lpc_object *obj)
> > +{
> > + struct module *mod = obj->mod;
> > + int ret;
> > +
> > + pr_notice("reverting patch '%s' on unloading module '%s'\n",
> > + pmod->name, mod->name);
> > + ret = lpc_disable_object(obj);
> > + if (ret)
> > + pr_warn("failed to revert patch '%s' on module '%s' (%d)\n",
> > + pmod->name, mod->name, ret);
> > + obj->mod = NULL;
> > +}
> > +
> > +static int lpc_module_notify(struct notifier_block *nb, unsigned long
> > action,
> > + void *data)
> > +{
> > + struct module *mod = data;
> > + struct lpc_patch *patch;
> > + struct lpc_object *obj;
> > +
> > + mutex_lock(_mutex);
> > +
> > + if (action != MODULE_STATE_COMING && action != MODULE_STATE_GOING)
> > + goto out;
> > +
> > + list_for_each_entry(patch, _patches, list) {
> > + if (patch->state == LPC_DISABLED)
> > + continue;
> > + list_for_each_entry(obj, >objs, list) {
> > + if (strcmp(obj->name, mod->name))
> > + continue;
> > + if (action == MODULE_STATE_COMING) {
> > + obj->mod = mod;
> > + lpc_module_notify_coming(patch->mod, obj);
> > + } else /* MODULE_STATE_GOING */
> > + lpc_module_notify_going(patch->mod, obj);
> > + break;
> > + }
> > + }
> > +out:
> > + mutex_unlock(_mutex);
> > + return 0;
> > +}
>
> [...]
>
> > +static struct lpc_object *lpc_create_object(struct kobject *root,
> > + struct lp_object *userobj)
> > +{
> > + struct lpc_object *obj;
> > + int ret;
> > +
> > + /* alloc */
> > + obj = kzalloc(sizeof(*obj), GFP_KERNEL);
> > + if (!obj)
> > + return NULL;
> > +
> > + /* init */
> > + INIT_LIST_HEAD(>list);
> > + obj->name = userobj->name;
> > + obj->relocs = userobj->relocs;
> > + obj->state = LPC_DISABLED;
> > + /* obj->mod set by lpc_object_module_get() */
> > + INIT_LIST_HEAD(>funcs);
>
> There is nothing like lpc_object_module_get() in the code. Did you mean
> lpc_find_object_module()?
Yes, this comment should be removed or updated.
Thanks,
Seth
>
> Thank you,
> --
> Miroslav Benes
> 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 09/16] perf tools: Only print base source file for srcline
From: Andi Kleen
For perf report with --sort srcline only print the base source file
name. This makes the results generally fit much better to the screen.
The path is usually not that useful anyways because it is often from
different systems.
Signed-off-by: Andi Kleen
Cc: Jiri Olsa
Cc: Namhyung Kim
Link:
http://lkml.kernel.org/r/1415844328-4884-8-git-send-email-a...@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/srcline.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
index f3e4bc5fe5d2..77c180637138 100644
--- a/tools/perf/util/srcline.c
+++ b/tools/perf/util/srcline.c
@@ -274,7 +274,7 @@ char *get_srcline(struct dso *dso, unsigned long addr)
if (!addr2line(dso_name, addr, , , dso))
goto out;
- if (asprintf(, "%s:%u", file, line) < 0) {
+ if (asprintf(, "%s:%u", basename(file), line) < 0) {
free(file);
goto out;
}
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/16] perf tools: Clean up libelf feature support code
From: Namhyung Kim Current EXTLIBS contains -lelf by default and removes it when libelf is not detected. This is little bit confusing since we can now build perf without libelf so there's no need to handle it differently than other libraries. Signed-off-by: Namhyung Kim Cc: Adrian Hunter Cc: David Ahern Cc: Ingo Molnar Cc: Jiri Olsa Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1415337606-2186-3-git-send-email-namhy...@kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/Makefile.perf | 2 -- tools/perf/config/Makefile | 5 +++-- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf index aecf61dcd754..478efa9b2364 100644 --- a/tools/perf/Makefile.perf +++ b/tools/perf/Makefile.perf @@ -497,8 +497,6 @@ ifneq ($(OUTPUT),) endif ifdef NO_LIBELF -EXTLIBS := $(filter-out -lelf,$(EXTLIBS)) - # Remove ELF/DWARF dependent codes LIB_OBJS := $(filter-out $(OUTPUT)util/symbol-elf.o,$(LIB_OBJS)) LIB_OBJS := $(filter-out $(OUTPUT)util/dwarf-aux.o,$(LIB_OBJS)) diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index 79f906c7124e..5d4b039fe1ed 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile @@ -150,7 +150,7 @@ CFLAGS += -std=gnu99 # adding assembler files missing the .GNU-stack linker note. LDFLAGS += -Wl,-z,noexecstack -EXTLIBS = -lelf -lpthread -lrt -lm -ldl +EXTLIBS = -lpthread -lrt -lm -ldl ifneq ($(OUTPUT),) OUTPUT_FEATURES = $(OUTPUT)config/feature-checks/ @@ -354,6 +354,7 @@ endif # NO_LIBELF ifndef NO_LIBELF CFLAGS += -DHAVE_LIBELF_SUPPORT + EXTLIBS += -lelf ifeq ($(feature-libelf-mmap), 1) CFLAGS += -DHAVE_LIBELF_MMAP_SUPPORT @@ -373,7 +374,7 @@ ifndef NO_LIBELF else CFLAGS += -DHAVE_DWARF_SUPPORT $(LIBDW_CFLAGS) LDFLAGS += $(LIBDW_LDFLAGS) - EXTLIBS += -lelf -ldw + EXTLIBS += -ldw endif # PERF_HAVE_DWARF_REGS endif # NO_DWARF endif # NO_LIBELF -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL 00/16] perf/core improvements and fixes
Hi Ingo, Please consider pulling, - Arnaldo The following changes since commit 2565711fb7d7c28e0cd93c8971b520d1b10b857c: perf: Improve the perf_sample_data struct layout (2014-11-16 11:42:04 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo for you to fetch changes up to a84808083688d82d7f1e5786ccf5df0ff7d448cb: perf tools: Only override the default :tid comm entry (2014-11-19 12:37:26 -0300) perf/core improvements and fixes: User visible fixes: - Fallback to kallsyms when using the minimal 'ELF' loader (Arnaldo Carvalho de Melo) - Fix annotation with kcore (Adrian Hunter) - Fix up srcline histogram key formatting (Arnaldo Carvalho de Melo) - Add missing handler for PERF_RECORD_MMAP2 events in 'perf diff' (Kan Liang) User visible changes/new features: - Only print base source file for srcline histogram sort key (Andi Kleen) - Support source line numbers in annotate using a hotkey (Andi Kleen) Infrastructure: - Do not poll events that use the system_wide flag (Adrian Hunter) - Add perf-read-vdso32 and perf-read-vdsox32 to .gitignore (Adrian Hunter) perf tools: Only override the default :tid comm entry (Adrian Hunter) - Factor out adding new call chain entries (Andi Kleen) - Use al.addr to set up call chain (Andi Kleen) - Use a common function to resolve symbol or name (Andi Kleen) - Fix ftrace:function event recording (Jiri Olsa) - Move disable_buildid_cache() to util/build-id.c (Namhyung Kim) - Clean up libelf feature support code (Namhyung Kim) - fix typo in python 'perf test' (WANG Chao) Signed-off-by: Arnaldo Carvalho de Melo Adrian Hunter (4): perf tools: Fix annotation with kcore perf evlist: Do not poll events that use the system_wide flag perf tools: Add perf-read-vdso32 and perf-read-vdsox32 to .gitignore perf tools: Only override the default :tid comm entry Andi Kleen (5): perf callchain: Factor out adding new call chain entries perf callchain: Use al.addr to set up call chain perf callchain: Use a common function to resolve symbol or name perf tools: Only print base source file for srcline perf annotate: Support source line numbers in annotate Arnaldo Carvalho de Melo (2): perf symbols: Fallback to kallsyms when using the minimal 'ELF' loader perf hists: Fix up srcline histogram key formatting Jiri Olsa (1): perf evsel: Fix ftrace:function event recording Kan Liang (1): perf diff: Add missing handler for PERF_RECORD_MMAP2 events Namhyung Kim (2): perf build-id: Move disable_buildid_cache() to util/build-id.c perf tools: Clean up libelf feature support code WANG Chao (1): perf test: fix typo in python test tools/perf/.gitignore | 2 ++ tools/perf/Makefile.perf | 2 -- tools/perf/builtin-diff.c | 1 + tools/perf/config/Makefile| 5 ++-- tools/perf/tests/builtin-test.c | 2 +- tools/perf/ui/browsers/annotate.c | 13 +- tools/perf/ui/browsers/hists.c| 17 - tools/perf/ui/gtk/hists.c | 11 + tools/perf/ui/stdio/hist.c| 23 +++--- tools/perf/util/annotate.c| 32 tools/perf/util/annotate.h| 1 + tools/perf/util/build-id.c| 11 + tools/perf/util/build-id.h| 1 + tools/perf/util/callchain.c | 19 +++ tools/perf/util/callchain.h | 3 +++ tools/perf/util/evlist.c | 10 +++- tools/perf/util/evsel.c | 8 ++ tools/perf/util/header.c | 10 +--- tools/perf/util/machine.c | 51 --- tools/perf/util/sort.c| 2 +- tools/perf/util/srcline.c | 2 +- tools/perf/util/symbol-minimal.c | 1 - tools/perf/util/thread.c | 5 ++-- tools/perf/util/util.h| 1 - 24 files changed, 145 insertions(+), 88 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 13/16] perf evsel: Fix ftrace:function event recording
From: Jiri Olsa Following patch fails (-EINVAL) ftrace:function with enabled user space callchains: cfa77bc4af2c perf: Disallow user-space callchains for function trace events We need to follow in perf tool itself and explicitly set the perf_event_attr::exclude_callchain_user flag for ftrace:function event. Reported-by: Steven Rostedt Signed-off-by: Jiri Olsa Cc: Corey Ashford Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Steven Rostedt Link: http://lkml.kernel.org/r/1415899263-24820-1-git-send-email-jo...@kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/evsel.c | 8 1 file changed, 8 insertions(+) diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c index 34344ffa79ca..f2dc91fb87fa 100644 --- a/tools/perf/util/evsel.c +++ b/tools/perf/util/evsel.c @@ -658,6 +658,14 @@ void perf_evsel__config(struct perf_evsel *evsel, struct record_opts *opts) attr->mmap_data = track; } + /* +* We don't allow user space callchains for function trace +* event, due to issues with page faults while tracing page +* fault handler and its overall trickiness nature. +*/ + if (perf_evsel__is_function_event(evsel)) + evsel->attr.exclude_callchain_user = 1; + if (callchain_param.enabled && !evsel->no_aux_samples) perf_evsel__config_callgraph(evsel); -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 15/16] perf tools: Add perf-read-vdso32 and perf-read-vdsox32 to .gitignore
From: Adrian Hunter Recently added executables Add perf-read-vdso32 and perf-read-vdsox32 need to be added to .gitignore. Signed-off-by: Adrian Hunter Cc: David Ahern Cc: Frederic Weisbecker Cc: Jiri Olsa Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lkml.kernel.org/r/1415715423-15563-3-git-send-email-adrian.hun...@intel.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/.gitignore | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/perf/.gitignore b/tools/perf/.gitignore index 717221e98450..40399c3d97d6 100644 --- a/tools/perf/.gitignore +++ b/tools/perf/.gitignore @@ -2,6 +2,8 @@ PERF-CFLAGS PERF-GUI-VARS PERF-VERSION-FILE perf +perf-read-vdso32 +perf-read-vdsox32 perf-help perf-record perf-report -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/16] perf callchain: Factor out adding new call chain entries
From: Andi Kleen
Move the code to resolve and add a new callchain entry into a new
add_callchain_ip function. This will be used in the next patches to add
LBRs too.
No change in behavior.
Signed-off-by: Andi Kleen
Cc: Jiri Olsa
Cc: Namhyung Kim
Link:
http://lkml.kernel.org/r/1415844328-4884-2-git-send-email-a...@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/machine.c | 51 +--
1 file changed, 32 insertions(+), 19 deletions(-)
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 52e94902afb1..84390eecab06 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1381,6 +1381,34 @@ struct mem_info *sample__resolve_mem(struct perf_sample
*sample,
return mi;
}
+static int add_callchain_ip(struct thread *thread,
+ struct symbol **parent,
+ struct addr_location *root_al,
+ int cpumode,
+ u64 ip)
+{
+ struct addr_location al;
+
+ al.filtered = 0;
+ al.sym = NULL;
+ thread__find_addr_location(thread, cpumode, MAP__FUNCTION,
+ ip, );
+ if (al.sym != NULL) {
+ if (sort__has_parent && !*parent &&
+ symbol__match_regex(al.sym, _regex))
+ *parent = al.sym;
+ else if (have_ignore_callees && root_al &&
+ symbol__match_regex(al.sym, _callees_regex)) {
+ /* Treat this symbol as the root,
+ forgetting its callees. */
+ *root_al = al;
+ callchain_cursor_reset(_cursor);
+ }
+ }
+
+ return callchain_cursor_append(_cursor, ip, al.map, al.sym);
+}
+
struct branch_info *sample__resolve_bstack(struct perf_sample *sample,
struct addr_location *al)
{
@@ -1427,7 +1455,6 @@ static int thread__resolve_callchain_sample(struct thread
*thread,
for (i = 0; i < chain_nr; i++) {
u64 ip;
- struct addr_location al;
if (callchain_param.order == ORDER_CALLEE)
j = i;
@@ -1464,24 +1491,10 @@ static int thread__resolve_callchain_sample(struct
thread *thread,
continue;
}
- al.filtered = 0;
- thread__find_addr_location(thread, cpumode,
- MAP__FUNCTION, ip, );
- if (al.sym != NULL) {
- if (sort__has_parent && !*parent &&
- symbol__match_regex(al.sym, _regex))
- *parent = al.sym;
- else if (have_ignore_callees && root_al &&
- symbol__match_regex(al.sym, _callees_regex)) {
- /* Treat this symbol as the root,
- forgetting its callees. */
- *root_al = al;
- callchain_cursor_reset(_cursor);
- }
- }
-
- err = callchain_cursor_append(_cursor,
- ip, al.map, al.sym);
+ err = add_callchain_ip(thread, parent, root_al,
+ cpumode, ip);
+ if (err == -EINVAL)
+ break;
if (err)
return err;
}
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/16] perf build-id: Move disable_buildid_cache() to util/build-id.c
From: Namhyung Kim
Also move static variable no_buildid_cache and check it in the
perf_session_cache_build_ids().
Signed-off-by: Namhyung Kim
Cc: Aravinda Prasad
Cc: Brendan Gregg
Cc: Hemant Kumar
Cc: Ingo Molnar
Cc: Masami Hiramatsu
Cc: Oleg Nesterov
Cc: Pekka Enberg
Cc: Peter Zijlstra
Cc: Srikar Dronamraju
Cc: Vasant Hegde
Cc: system...@sourceware.org
Link:
http://lkml.kernel.org/r/1415368677-3794-1-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/build-id.c | 11 +++
tools/perf/util/build-id.h | 1 +
tools/perf/util/header.c | 10 +-
tools/perf/util/util.h | 1 -
4 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/tools/perf/util/build-id.c b/tools/perf/util/build-id.c
index dd2a3e52ada1..e8d79e5bfaf7 100644
--- a/tools/perf/util/build-id.c
+++ b/tools/perf/util/build-id.c
@@ -18,6 +18,9 @@
#include "header.h"
#include "vdso.h"
+
+static bool no_buildid_cache;
+
int build_id__mark_dso_hit(struct perf_tool *tool __maybe_unused,
union perf_event *event,
struct perf_sample *sample,
@@ -251,6 +254,11 @@ int dsos__hit_all(struct perf_session *session)
return 0;
}
+void disable_buildid_cache(void)
+{
+ no_buildid_cache = true;
+}
+
int build_id_cache__add_s(const char *sbuild_id, const char *debugdir,
const char *name, bool is_kallsyms, bool is_vdso)
{
@@ -404,6 +412,9 @@ int perf_session__cache_build_ids(struct perf_session
*session)
int ret;
char debugdir[PATH_MAX];
+ if (no_buildid_cache)
+ return 0;
+
snprintf(debugdir, sizeof(debugdir), "%s", buildid_dir);
if (mkdir(debugdir, 0755) != 0 && errno != EEXIST)
diff --git a/tools/perf/util/build-id.h b/tools/perf/util/build-id.h
index 666a3bd4f64e..8236319514d5 100644
--- a/tools/perf/util/build-id.h
+++ b/tools/perf/util/build-id.h
@@ -25,5 +25,6 @@ int perf_session__cache_build_ids(struct perf_session
*session);
int build_id_cache__add_s(const char *sbuild_id, const char *debugdir,
const char *name, bool is_kallsyms, bool is_vdso);
int build_id_cache__remove_s(const char *sbuild_id, const char *debugdir);
+void disable_buildid_cache(void);
#endif
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 05fab7a188dc..b20e40c74468 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -24,8 +24,6 @@
#include "build-id.h"
#include "data.h"
-static bool no_buildid_cache = false;
-
static u32 header_argc;
static const char **header_argv;
@@ -191,8 +189,7 @@ static int write_build_id(int fd, struct perf_header *h,
pr_debug("failed to write buildid table\n");
return err;
}
- if (!no_buildid_cache)
- perf_session__cache_build_ids(session);
+ perf_session__cache_build_ids(session);
return 0;
}
@@ -2791,8 +2788,3 @@ int perf_event__process_build_id(struct perf_tool *tool
__maybe_unused,
session);
return 0;
}
-
-void disable_buildid_cache(void)
-{
- no_buildid_cache = true;
-}
diff --git a/tools/perf/util/util.h b/tools/perf/util/util.h
index 7dc44cfe25b3..76d23d83eae5 100644
--- a/tools/perf/util/util.h
+++ b/tools/perf/util/util.h
@@ -154,7 +154,6 @@ extern void set_die_routine(void (*routine)(const char
*err, va_list params) NOR
extern int prefixcmp(const char *str, const char *prefix);
extern void set_buildid_dir(void);
-extern void disable_buildid_cache(void);
static inline const char *skip_prefix(const char *str, const char *prefix)
{
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/16] perf diff: Add missing handler for PERF_RECORD_MMAP2 events
From: Kan Liang
Without mmap2, perf diff fails to find the symbol name. The default
symbol sort key doesn't work well.
Signed-off-by: Kan Liang
Acked-by: Namhyung Kim
Cc: Andi Kleen
Cc: Jiri Olsa
Cc: Namhyung Kim
Link:
http://lkml.kernel.org/r/1416328700-1836-2-git-send-email-kan.li...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-diff.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 25114c9a6801..1ce425d101a9 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -357,6 +357,7 @@ static int diff__process_sample_event(struct perf_tool
*tool __maybe_unused,
static struct perf_tool tool = {
.sample = diff__process_sample_event,
.mmap = perf_event__process_mmap,
+ .mmap2 = perf_event__process_mmap2,
.comm = perf_event__process_comm,
.exit = perf_event__process_exit,
.fork = perf_event__process_fork,
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 14/16] perf evlist: Do not poll events that use the system_wide flag
From: Adrian Hunter
The system_wide flag causes a selected event to be opened always without
a pid.
Consequently it will never get a POLLHUP, but it is used for tracking in
combination with other events, so it should not need to be polled
anyway.
Therefore don't add it for polling.
Signed-off-by: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1415715423-15563-2-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/evlist.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 7e23dae54f1d..cfbe2b99b9aa 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -816,7 +816,15 @@ static int perf_evlist__mmap_per_evsel(struct perf_evlist
*evlist, int idx,
perf_evlist__mmap_get(evlist, idx);
}
- if (__perf_evlist__add_pollfd(evlist, fd, idx) < 0) {
+ /*
+* The system_wide flag causes a selected event to be opened
+* always without a pid. Consequently it will never get a
+* POLLHUP, but it is used for tracking in combination with
+* other events, so it should not need to be polled anyway.
+* Therefore don't add it for polling.
+*/
+ if (!evsel->system_wide &&
+ __perf_evlist__add_pollfd(evlist, fd, idx) < 0) {
perf_evlist__mmap_put(evlist, idx);
return -1;
}
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] x86, acpi, pci: Move arch-agnostic MMCFG code out of arch/x86/ directory
MMCFG table seems to be architecture independent and it makes sense
to share common code across all architectures. The ones that may need
architectural specific actions have default prototype (__weak).
Signed-off-by: Tomasz Nowicki
Tested-by: Hanjun Guo
---
arch/x86/include/asm/pci_x86.h | 29 -
arch/x86/pci/acpi.c| 1 +
arch/x86/pci/init.c| 1 +
arch/x86/pci/mmconfig-shared.c | 200 +-
arch/x86/pci/mmconfig_32.c | 1 +
arch/x86/pci/mmconfig_64.c | 1 +
drivers/acpi/Makefile | 1 +
drivers/acpi/bus.c | 1 +
drivers/acpi/mmconfig.c| 242 +
include/linux/mmconfig.h | 58 ++
include/linux/pci.h| 8 --
11 files changed, 308 insertions(+), 235 deletions(-)
create mode 100644 drivers/acpi/mmconfig.c
create mode 100644 include/linux/mmconfig.h
diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index fa1195d..caba141 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -121,35 +121,6 @@ extern int __init pcibios_init(void);
extern int pci_legacy_init(void);
extern void pcibios_fixup_irqs(void);
-/* pci-mmconfig.c */
-
-/* "PCI MMCONFIG %04x [bus %02x-%02x]" */
-#define PCI_MMCFG_RESOURCE_NAME_LEN (22 + 4 + 2 + 2)
-
-struct pci_mmcfg_region {
- struct list_head list;
- struct resource res;
- u64 address;
- char __iomem *virt;
- u16 segment;
- u8 start_bus;
- u8 end_bus;
- char name[PCI_MMCFG_RESOURCE_NAME_LEN];
-};
-
-extern int __init pci_mmcfg_arch_init(void);
-extern void __init pci_mmcfg_arch_free(void);
-extern int pci_mmcfg_arch_map(struct pci_mmcfg_region *cfg);
-extern void pci_mmcfg_arch_unmap(struct pci_mmcfg_region *cfg);
-extern int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
- phys_addr_t addr);
-extern int pci_mmconfig_delete(u16 seg, u8 start, u8 end);
-extern struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus);
-
-extern struct list_head pci_mmcfg_list;
-
-#define PCI_MMCFG_BUS_OFFSET(bus) ((bus) << 20)
-
/*
* AMD Fam10h CPUs are buggy, and cannot access MMIO config space
* on their northbrige except through the * %eax register. As such, you MUST
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index cfd1b13..6d11131 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include
#include
diff --git a/arch/x86/pci/init.c b/arch/x86/pci/init.c
index adb62aa..b4a55df 100644
--- a/arch/x86/pci/init.c
+++ b/arch/x86/pci/init.c
@@ -1,5 +1,6 @@
#include
#include
+#include
#include
#include
diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index ac24e1c..b397544 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -27,103 +28,6 @@
/* Indicate if the mmcfg resources have been placed into the resource table. */
static bool pci_mmcfg_running_state;
static bool pci_mmcfg_arch_init_failed;
-static DEFINE_MUTEX(pci_mmcfg_lock);
-
-LIST_HEAD(pci_mmcfg_list);
-
-static void __init pci_mmconfig_remove(struct pci_mmcfg_region *cfg)
-{
- if (cfg->res.parent)
- release_resource(>res);
- list_del(>list);
- kfree(cfg);
-}
-
-static void __init free_all_mmcfg(void)
-{
- struct pci_mmcfg_region *cfg, *tmp;
-
- pci_mmcfg_arch_free();
- list_for_each_entry_safe(cfg, tmp, _mmcfg_list, list)
- pci_mmconfig_remove(cfg);
-}
-
-static void list_add_sorted(struct pci_mmcfg_region *new)
-{
- struct pci_mmcfg_region *cfg;
-
- /* keep list sorted by segment and starting bus number */
- list_for_each_entry_rcu(cfg, _mmcfg_list, list) {
- if (cfg->segment > new->segment ||
- (cfg->segment == new->segment &&
-cfg->start_bus >= new->start_bus)) {
- list_add_tail_rcu(>list, >list);
- return;
- }
- }
- list_add_tail_rcu(>list, _mmcfg_list);
-}
-
-static struct pci_mmcfg_region *pci_mmconfig_alloc(int segment, int start,
- int end, u64 addr)
-{
- struct pci_mmcfg_region *new;
- struct resource *res;
-
- if (addr == 0)
- return NULL;
-
- new = kzalloc(sizeof(*new), GFP_KERNEL);
- if (!new)
- return NULL;
-
- new->address = addr;
- new->segment = segment;
- new->start_bus = start;
- new->end_bus = end;
-
- res = >res;
- res->start = addr + PCI_MMCFG_BUS_OFFSET(start);
- res->end = addr + PCI_MMCFG_BUS_OFFSET(end + 1) - 1;
- res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
-
Re: Implement lbr-as-callgraph v10
Em Wed, Nov 19, 2014 at 11:10:27AM -0300, Arnaldo Carvalho de Melo escreveu: > Em Wed, Nov 19, 2014 at 11:54:50AM +0100, Jiri Olsa escreveu: > > > > BUILD_BUG_ON then? > > > > > > sounds gut > > > > hum, acme/perf/core changed and so has the compile error ;-) > > we dont overload the , so the kernel one got > > included, which is wrong.. attached patch fixes that > > I had fixed this but not force pushed out, sorry. > > Now I mistakenly tried running: > > perf report --stdio --no-children --branch-history > > on a file that has no BRANCH_STACK, i.e. a perf.data file on a wrong > directory since I'm comparing the output of --stdio, --tui and --gtk, > since it looks --gtk is wrong, still unsure about what the problem is in > that case, but stumbled on: > I need to investigate this further, so I created a perf/branch-history branch that has the patches I need to test more rebased on top of my perf/core branch I just pushed out to Ingo. - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/6] PCI: MMCONFIG clean up
MMCFG ACPI table has no arch dependencies so it can be used across all
architectures. Currently MMCONFIG related code resides in arch/x86 directories.
This patch set is goint to isolate non-architecure specific code and make
it accessible from drivers/pci/ directory.
Tomasz Nowicki (6):
x86, acpi, pci: Reorder logic of pci_mmconfig_insert() function
x86, acpi, pci: Move arch-agnostic MMCFG code out of arch/x86/
directory
x86, acpi, pci: Move PCI config space accessors.
x86, acpi, pci: mmconfig_{32,64}.c code refactoring - remove code
duplication.
x86, acpi, pci: mmconfig_64.c becomes default implementation for arch
agnostic low-level direct PCI config space accessors via MMCONFIG.
pci, acpi: Share ACPI PCI config space accessors.
arch/x86/include/asm/pci.h | 42 +
arch/x86/include/asm/pci_x86.h | 72
arch/x86/pci/Makefile | 5 +-
arch/x86/pci/acpi.c| 1 +
arch/x86/pci/init.c| 1 +
arch/x86/pci/mmconfig-shared.c | 242 -
arch/x86/pci/mmconfig_32.c | 11 +-
arch/x86/pci/mmconfig_64.c | 153
drivers/acpi/Makefile | 1 +
drivers/acpi/bus.c | 1 +
drivers/acpi/mmconfig.c| 396 +
include/linux/mmconfig.h | 62 +++
include/linux/pci.h| 8 -
13 files changed, 541 insertions(+), 454 deletions(-)
delete mode 100644 arch/x86/pci/mmconfig_64.c
create mode 100644 drivers/acpi/mmconfig.c
create mode 100644 include/linux/mmconfig.h
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] x86, acpi, pci: mmconfig_64.c becomes default implementation for arch agnostic low-level direct PCI config space accessors via MMCONFIG.
Note that x86 32bits machines still have its own low-level direct
PCI config space accessors.
Signed-off-by: Tomasz Nowicki
---
arch/x86/pci/Makefile | 5 +-
arch/x86/pci/mmconfig_64.c | 152 -
drivers/acpi/mmconfig.c| 134 +++
3 files changed, 138 insertions(+), 153 deletions(-)
delete mode 100644 arch/x86/pci/mmconfig_64.c
diff --git a/arch/x86/pci/Makefile b/arch/x86/pci/Makefile
index 5c6fc35..35c765b 100644
--- a/arch/x86/pci/Makefile
+++ b/arch/x86/pci/Makefile
@@ -1,7 +1,10 @@
obj-y := i386.o init.o
obj-$(CONFIG_PCI_BIOS) += pcbios.o
-obj-$(CONFIG_PCI_MMCONFIG) += mmconfig_$(BITS).o direct.o mmconfig-shared.o
+obj-$(CONFIG_PCI_MMCONFIG) += direct.o mmconfig-shared.o
+ifeq ($(BITS),32)
+obj-$(CONFIG_PCI_MMCONFIG) += mmconfig_32.o
+endif
obj-$(CONFIG_PCI_DIRECT) += direct.o
obj-$(CONFIG_PCI_OLPC) += olpc.o
obj-$(CONFIG_PCI_XEN) += xen.o
diff --git a/arch/x86/pci/mmconfig_64.c b/arch/x86/pci/mmconfig_64.c
deleted file mode 100644
index ff2c50c..000
--- a/arch/x86/pci/mmconfig_64.c
+++ /dev/null
@@ -1,152 +0,0 @@
-/*
- * mmconfig.c - Low-level direct PCI config space access via MMCONFIG
- *
- * This is an 64bit optimized version that always keeps the full mmconfig
- * space mapped. This allows lockless config space operation.
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#define PREFIX "PCI: "
-
-static char __iomem *pci_dev_base(unsigned int seg, unsigned int bus, unsigned
int devfn)
-{
- struct pci_mmcfg_region *cfg = pci_mmconfig_lookup(seg, bus);
-
- if (cfg && cfg->virt)
- return cfg->virt + (PCI_MMCFG_BUS_OFFSET(bus) | (devfn << 12));
- return NULL;
-}
-
-int pci_mmcfg_read(unsigned int seg, unsigned int bus,
- unsigned int devfn, int reg, int len, u32 *value)
-{
- char __iomem *addr;
-
- /* Why do we have this when nobody checks it. How about a BUG()!? -AK */
- if (unlikely((bus > 255) || (devfn > 255) || (reg > 4095))) {
-err: *value = -1;
- return -EINVAL;
- }
-
- rcu_read_lock();
- addr = pci_dev_base(seg, bus, devfn);
- if (!addr) {
- rcu_read_unlock();
- goto err;
- }
-
- switch (len) {
- case 1:
- *value = mmio_config_readb(addr + reg);
- break;
- case 2:
- *value = mmio_config_readw(addr + reg);
- break;
- case 4:
- *value = mmio_config_readl(addr + reg);
- break;
- }
- rcu_read_unlock();
-
- return 0;
-}
-
-int pci_mmcfg_write(unsigned int seg, unsigned int bus,
- unsigned int devfn, int reg, int len, u32 value)
-{
- char __iomem *addr;
-
- /* Why do we have this when nobody checks it. How about a BUG()!? -AK */
- if (unlikely((bus > 255) || (devfn > 255) || (reg > 4095)))
- return -EINVAL;
-
- rcu_read_lock();
- addr = pci_dev_base(seg, bus, devfn);
- if (!addr) {
- rcu_read_unlock();
- return -EINVAL;
- }
-
- switch (len) {
- case 1:
- mmio_config_writeb(addr + reg, value);
- break;
- case 2:
- mmio_config_writew(addr + reg, value);
- break;
- case 4:
- mmio_config_writel(addr + reg, value);
- break;
- }
- rcu_read_unlock();
-
- return 0;
-}
-
-const struct pci_raw_ops pci_mmcfg = {
- .read = pci_mmcfg_read,
- .write =pci_mmcfg_write,
-};
-
-static void __iomem *mcfg_ioremap(struct pci_mmcfg_region *cfg)
-{
- void __iomem *addr;
- u64 start, size;
- int num_buses;
-
- start = cfg->address + PCI_MMCFG_BUS_OFFSET(cfg->start_bus);
- num_buses = cfg->end_bus - cfg->start_bus + 1;
- size = PCI_MMCFG_BUS_OFFSET(num_buses);
- addr = ioremap_nocache(start, size);
- if (addr)
- addr -= PCI_MMCFG_BUS_OFFSET(cfg->start_bus);
- return addr;
-}
-
-int __init pci_mmcfg_arch_init(void)
-{
- struct pci_mmcfg_region *cfg;
-
- list_for_each_entry(cfg, _mmcfg_list, list)
- if (pci_mmcfg_arch_map(cfg)) {
- pci_mmcfg_arch_free();
- return 0;
- }
-
- return 1;
-}
-
-void __init pci_mmcfg_arch_free(void)
-{
- struct pci_mmcfg_region *cfg;
-
- list_for_each_entry(cfg, _mmcfg_list, list)
- pci_mmcfg_arch_unmap(cfg);
-}
-
-int pci_mmcfg_arch_map(struct pci_mmcfg_region *cfg)
-{
- cfg->virt = mcfg_ioremap(cfg);
- if (!cfg->virt) {
- pr_err(PREFIX "can't map MMCONFIG at %pR\n", >res);
- return -ENOMEM;
- }
-
- return 0;
-}
[PATCH 07/16] perf callchain: Use al.addr to set up call chain
From: Andi Kleen Use the relative address, this makes get_srcline work correctly in the end. Signed-off-by: Andi Kleen Cc: Jiri Olsa Cc: Namhyung Kim Link: http://lkml.kernel.org/r/1415844328-4884-4-git-send-email-a...@firstfloor.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/machine.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c index 84390eecab06..d97309c87bd6 100644 --- a/tools/perf/util/machine.c +++ b/tools/perf/util/machine.c @@ -1406,7 +1406,7 @@ static int add_callchain_ip(struct thread *thread, } } - return callchain_cursor_append(_cursor, ip, al.map, al.sym); + return callchain_cursor_append(_cursor, al.addr, al.map, al.sym); } struct branch_info *sample__resolve_bstack(struct perf_sample *sample, -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/16] perf symbols: Fallback to kallsyms when using the minimal 'ELF' loader
From: Arnaldo Carvalho de Melo
The minimal ELF loader should not return 1 when it manages to read the
vmlinux build-id, it should instead return 0, meaning that it hasn't
loaded any symbols, since it doesn't parses ELF at all.
That way, the main symbol.c routines will understand that it is
necessary to continue looking for a file with symbols, and when no
libelf is linked, that means it will eventually try kallsyms.
Reported-by: Peter Zijlstra
Tested-by: Peter Zijlstra
Cc: Adrian Hunter
Cc: Borislav Petkov
Cc: David Ahern
Cc: Don Zickus
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/r/2014130326.gt18...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/symbol-minimal.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/perf/util/symbol-minimal.c b/tools/perf/util/symbol-minimal.c
index c9541fea9514..fa585c63f56a 100644
--- a/tools/perf/util/symbol-minimal.c
+++ b/tools/perf/util/symbol-minimal.c
@@ -341,7 +341,6 @@ int dso__load_sym(struct dso *dso, struct map *map
__maybe_unused,
if (filename__read_build_id(ss->name, build_id, BUILD_ID_SIZE) > 0) {
dso__set_build_id(dso, build_id);
- return 1;
}
return 0;
}
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] x86: allow dma_get_required_mask() to be overridden
Use dma_ops->get_required_mask() if provided, defaulting to
dma_get_requried_mask_from_max_pfn().
This is needed on systems (such as Xen PV guests) where the DMA
address and the physical address are not equal.
ARCH_HAS_DMA_GET_REQUIRED_MASK is defined in asm/device.h instead of
asm/dma-mapping.h because linux/dma-mapping.h uses the define before
including asm/dma-mapping.h
Signed-off-by: David Vrabel
Reviewed-by: Stefano Stabellini
---
arch/x86/include/asm/device.h |2 ++
arch/x86/kernel/pci-dma.c |8
2 files changed, 10 insertions(+)
diff --git a/arch/x86/include/asm/device.h b/arch/x86/include/asm/device.h
index 03dd729..10bc628 100644
--- a/arch/x86/include/asm/device.h
+++ b/arch/x86/include/asm/device.h
@@ -13,4 +13,6 @@ struct dev_archdata {
struct pdev_archdata {
};
+#define ARCH_HAS_DMA_GET_REQUIRED_MASK
+
#endif /* _ASM_X86_DEVICE_H */
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index a25e202..5154400 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -140,6 +140,14 @@ void dma_generic_free_coherent(struct device *dev, size_t
size, void *vaddr,
free_pages((unsigned long)vaddr, get_order(size));
}
+u64 dma_get_required_mask(struct device *dev)
+{
+ if (dma_ops->get_required_mask)
+ return dma_ops->get_required_mask(dev);
+ return dma_get_required_mask_from_max_pfn(dev);
+}
+EXPORT_SYMBOL_GPL(dma_get_required_mask);
+
/*
* See for the iommu kernel
* parameter documentation.
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] ARM: option for loading modules into vmalloc area
On 19 November 2014 16:52, Konstantin Khlebnikov wrote: > On Wed, Nov 19, 2014 at 5:54 PM, Ard Biesheuvel > wrote: >> On 19 November 2014 14:40, Arnd Bergmann wrote: >>> On Tuesday 18 November 2014 21:13:56 Konstantin Khlebnikov wrote: On 2014-11-18 20:34, Russell King - ARM Linux wrote: > On Tue, Nov 18, 2014 at 08:21:46PM +0400, Konstantin Khlebnikov wrote: >> Usually modules are loaded into small area prior to the kernel >> text because they are linked with the kernel using short calls. >> Compile-time instrumentation like GCOV or KASAN bloats code a lot, >> and as a result huge modules no longer fit into reserved area. >> >> This patch adds option CONFIG_MODULES_USE_VMALLOC which lifts >> limitation on amount of loaded modules. It links modules using >> long-calls (option -mlong-calls) and loads them into vmalloc area. >> >> In few places exported symbols are called from inline assembly. >> This patch adds macro for such call sites: __asmbl and __asmbl_clobber. >> Call turns into single 'bl' or sequence 'movw; movt; blx' depending on >> context and state of config option. >> >> Unfortunately this option isn't compatible with CONFIG_FUNCTION_TRACER. >> Compiler emits short calls to profiling function despite of >> -mlong-calls. >> This is a bug in GCC, but ftrace anyway needs an update to handle this. > It also isn't compatible with the older architectures which don't have > "blx". Ok, I'll add "depends on CPU_V6 || CPU_V7" I don't think that it is necessary for older cpus. >>> >>> Why not just use a different branch instruction for the older CPUs? >>> >> >> ARMv6 doesn't support movw/movt so this will only work on v7. >> >> What about doing 'mov lr, pc; ldr pc,=symbol' instead? You clearly >> don't care about performance in this case, so the performance hit (due >> to the dcache access and interfering with the return stack predictors) >> should be tolerable. The only thing to be careful about is thumb2 >> kernels: you would need to set the thumb bit in lr manually but only >> if the call is made /from/ thumb. You would probably be better off >> just depending on !THUMB2_KERNEL. > > Do you mean ldr pc, =symbol ? > > In this case I get this error: > > /tmp/ccAHtONU.s: Assembler messages: > /tmp/ccAHtONU.s:220: Error: invalid literal constant: pool needs to be closer > > Probably constant pool doesn't work well in inline assembly. > > > Something like this seems work: > > add lr, pc, #4 > ldr pc, [pc, #-4] > .long symbol > You can add a '.ltorg' instruction which tells the assembler to dump the literal pool, but you still need to jump over it, i.e., adr lr, 0f ldr pc, =symbol .ltorg 0: -- Ard. -- 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/4] ia64: use common dma_get_required_mask_from_pfn()
Signed-off-by: David Vrabel
Cc: Tony Luck
Cc: Fenghua Yu
Cc: linux-i...@vger.kernel.org
---
arch/ia64/include/asm/machvec.h |2 +-
arch/ia64/include/asm/machvec_init.h |1 -
arch/ia64/pci/pci.c | 20
3 files changed, 1 insertion(+), 22 deletions(-)
diff --git a/arch/ia64/include/asm/machvec.h b/arch/ia64/include/asm/machvec.h
index 9c39bdf..beaa47d 100644
--- a/arch/ia64/include/asm/machvec.h
+++ b/arch/ia64/include/asm/machvec.h
@@ -287,7 +287,7 @@ extern struct dma_map_ops *dma_get_ops(struct device *);
# define platform_dma_get_ops dma_get_ops
#endif
#ifndef platform_dma_get_required_mask
-# define platform_dma_get_required_mask ia64_dma_get_required_mask
+# define platform_dma_get_required_mask
dma_get_required_mask_from_max_pfn
#endif
#ifndef platform_irq_to_vector
# define platform_irq_to_vector__ia64_irq_to_vector
diff --git a/arch/ia64/include/asm/machvec_init.h
b/arch/ia64/include/asm/machvec_init.h
index 37a4698..ef964b2 100644
--- a/arch/ia64/include/asm/machvec_init.h
+++ b/arch/ia64/include/asm/machvec_init.h
@@ -3,7 +3,6 @@
extern ia64_mv_send_ipi_t ia64_send_ipi;
extern ia64_mv_global_tlb_purge_t ia64_global_tlb_purge;
-extern ia64_mv_dma_get_required_mask ia64_dma_get_required_mask;
extern ia64_mv_irq_to_vector __ia64_irq_to_vector;
extern ia64_mv_local_vector_to_irq __ia64_local_vector_to_irq;
extern ia64_mv_pci_get_legacy_mem_t ia64_pci_get_legacy_mem;
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 291a582..79da21b 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -791,26 +791,6 @@ static void __init set_pci_dfl_cacheline_size(void)
pci_dfl_cache_line_size = (1 << cci.pcci_line_size) / 4;
}
-u64 ia64_dma_get_required_mask(struct device *dev)
-{
- u32 low_totalram = ((max_pfn - 1) << PAGE_SHIFT);
- u32 high_totalram = ((max_pfn - 1) >> (32 - PAGE_SHIFT));
- u64 mask;
-
- if (!high_totalram) {
- /* convert to mask just covering totalram */
- low_totalram = (1 << (fls(low_totalram) - 1));
- low_totalram += low_totalram - 1;
- mask = low_totalram;
- } else {
- high_totalram = (1 << (fls(high_totalram) - 1));
- high_totalram += high_totalram - 1;
- mask = (((u64)high_totalram) << 32) + 0x;
- }
- return mask;
-}
-EXPORT_SYMBOL_GPL(ia64_dma_get_required_mask);
-
u64 dma_get_required_mask(struct device *dev)
{
return platform_dma_get_required_mask(dev);
--
1.7.10.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/
[PATCHv3 0/4]: dma, x86, xen: reduce SWIOTLB usage in Xen guests
On systems where DMA addresses and physical addresses are not 1:1 (such as Xen PV guests), the generic dma_get_required_mask() will not return the correct mask (since it uses max_pfn). Some device drivers (such as mptsas, mpt2sas) use dma_get_required_mask() to set the device's DMA mask to allow them to use only 32-bit DMA addresses in hardware structures. This results in unnecessary use of the SWIOTLB if DMA addresses are more than 32-bits, impacting performance significantly. This series allows Xen PV guests to override the default dma_get_required_mask() with one that calculates the DMA mask from the maximum MFN (and not the PFN). Changes in v3: - fix off-by-one in xen_dma_get_required_mask() - split ia64 changes into separate patch. Changes in v2: - split x86 and xen changes into separate patches 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/
[PATCH 4/4] x86/xen: use the maximum MFN to calculate the required DMA mask
On a Xen PV guest the DMA addresses and physical addresses are not 1:1
(such as Xen PV guests) and the generic dma_get_required_mask() does
not return the correct mask (since it uses max_pfn).
Some device drivers (such as mptsas, mpt2sas) use
dma_get_required_mask() to set the device's DMA mask to allow them to
use only 32-bit DMA addresses in hardware structures. This results in
unnecessary use of the SWIOTLB if DMA addresses are more than 32-bits,
impacting performance significantly.
Provide a get_required_mask op that uses the maximum MFN to calculate
the DMA mask.
Signed-off-by: David Vrabel
---
arch/x86/xen/pci-swiotlb-xen.c |1 +
drivers/xen/swiotlb-xen.c | 13 +
include/xen/swiotlb-xen.h |4
3 files changed, 18 insertions(+)
diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
index 0e98e5d..a5d180a 100644
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci-swiotlb-xen.c
@@ -31,6 +31,7 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
.map_page = xen_swiotlb_map_page,
.unmap_page = xen_swiotlb_unmap_page,
.dma_supported = xen_swiotlb_dma_supported,
+ .get_required_mask = xen_swiotlb_get_required_mask,
};
/*
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index ebd8f21..654587d 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -42,9 +42,11 @@
#include
#include
#include
+#include
#include
#include
+#include
#include
/*
@@ -683,3 +685,14 @@ xen_swiotlb_set_dma_mask(struct device *dev, u64 dma_mask)
return 0;
}
EXPORT_SYMBOL_GPL(xen_swiotlb_set_dma_mask);
+
+u64
+xen_swiotlb_get_required_mask(struct device *dev)
+{
+ unsigned long max_mfn;
+
+ max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
+
+ return DMA_BIT_MASK(fls_long(max_mfn - 1) + PAGE_SHIFT);
+}
+EXPORT_SYMBOL_GPL(xen_swiotlb_get_required_mask);
diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
index 8b2eb93..640 100644
--- a/include/xen/swiotlb-xen.h
+++ b/include/xen/swiotlb-xen.h
@@ -58,4 +58,8 @@ xen_swiotlb_dma_supported(struct device *hwdev, u64 mask);
extern int
xen_swiotlb_set_dma_mask(struct device *dev, u64 dma_mask);
+
+extern u64
+xen_swiotlb_get_required_mask(struct device *dev);
+
#endif /* __LINUX_SWIOTLB_XEN_H */
--
1.7.10.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/4] dma: add dma_get_required_mask_from_max_pfn()
A generic dma_get_required_mask() is useful even for architectures (such
as ia64) that define ARCH_HAS_GET_REQUIRED_MASK.
Signed-off-by: David Vrabel
Reviewed-by: Stefano Stabellini
---
drivers/base/platform.c | 10 --
include/linux/dma-mapping.h |1 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index b2afc29..f9f3930 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1009,8 +1009,7 @@ int __init platform_bus_init(void)
return error;
}
-#ifndef ARCH_HAS_DMA_GET_REQUIRED_MASK
-u64 dma_get_required_mask(struct device *dev)
+u64 dma_get_required_mask_from_max_pfn(struct device *dev)
{
u32 low_totalram = ((max_pfn - 1) << PAGE_SHIFT);
u32 high_totalram = ((max_pfn - 1) >> (32 - PAGE_SHIFT));
@@ -1028,6 +1027,13 @@ u64 dma_get_required_mask(struct device *dev)
}
return mask;
}
+EXPORT_SYMBOL_GPL(dma_get_required_mask_from_max_pfn);
+
+#ifndef ARCH_HAS_DMA_GET_REQUIRED_MASK
+u64 dma_get_required_mask(struct device *dev)
+{
+ return dma_get_required_mask_from_max_pfn(dev);
+}
EXPORT_SYMBOL_GPL(dma_get_required_mask);
#endif
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index d5d3881..6e2fdfc 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -127,6 +127,7 @@ static inline int dma_coerce_mask_and_coherent(struct
device *dev, u64 mask)
return dma_set_mask_and_coherent(dev, mask);
}
+extern u64 dma_get_required_mask_from_max_pfn(struct device *dev);
extern u64 dma_get_required_mask(struct device *dev);
#ifndef set_arch_dma_coherent_ops
--
1.7.10.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 5/7] [RFC] ARM: shmobile: sh73a0 dtsi: Add PM domain support
Add a device node for the System Controller, with subnodes that
represent the hardware power area hierarchy.
Hook up all devices to their respective PM domains.
Add memory-controller nodes for the SDRAM Bus State Controllers (SBSC1
and SBSC2), which lie in the A4BC0 resp. A4BC1 PM domains, to prevent
them from being powered down.
There are no documented bindings for the SBSC yet (so far there's still
no need for a driver), but all properties follow the standard
conventions.
Note that unlike on R-Mobile A1 (r8a7740), PM domain D4 can be powered
down without ill effects on s2ram behavior, just like on SH-Mobile AP4
(sh7372). Hence we can postpone adding a (minimal) device node for the
Coresight-ETM hardware block.
Signed-off-by: Geert Uytterhoeven
---
Question: Should I make sbsc1 and sbsc2 minimal nodes for now, i.e. only
retain their "compatible" and "power-domains" properties?
---
arch/arm/boot/dts/sh73a0.dtsi | 159 +-
1 file changed, 157 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi
index c7ab55e55e23f8cb..0ba0892d21a7affd 100644
--- a/arch/arm/boot/dts/sh73a0.dtsi
+++ b/arch/arm/boot/dts/sh73a0.dtsi
@@ -26,12 +26,14 @@
compatible = "arm,cortex-a9";
reg = <0>;
clock-frequency = <119600>;
+ power-domains = <_a2sl>;
};
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
clock-frequency = <119600>;
+ power-domains = <_a2sl>;
};
};
@@ -43,6 +45,24 @@
<0xf100 0x100>;
};
+ sbsc2: memory-controller@fb40 {
+ compatible = "renesas,sbsc-sh73a0";
+ reg = <0xfb40 0x400>;
+ interrupts = <0 37 IRQ_TYPE_LEVEL_HIGH>,
+<0 38 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "sec", "temp";
+ power-domains = <_a4bc1>;
+ };
+
+ sbsc1: memory-controller@fe40 {
+ compatible = "renesas,sbsc-sh73a0";
+ reg = <0xfe40 0x400>;
+ interrupts = <0 35 IRQ_TYPE_LEVEL_HIGH>,
+<0 36 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "sec", "temp";
+ power-domains = <_a4bc0>;
+ };
+
pmu {
compatible = "arm,cortex-a9-pmu";
interrupts = <0 55 IRQ_TYPE_LEVEL_HIGH>,
@@ -53,11 +73,12 @@
compatible = "renesas,cmt-48-sh73a0", "renesas,cmt-48";
reg = <0xe6138000 0x200>;
interrupts = <0 65 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <_clks SH73A0_CLK_CMT1>;
+ clock-names = "fck";
+ power-domains = <_c5>;
renesas,channels-mask = <0x3f>;
- clocks = <_clks SH73A0_CLK_CMT1>;
- clock-names = "fck";
status = "disabled";
};
@@ -79,6 +100,7 @@
0 7 IRQ_TYPE_LEVEL_HIGH
0 8 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks SH73A0_CLK_INTCA0>;
+ power-domains = <_a4s>;
};
irqpin1: irqpin@e694 {
@@ -99,6 +121,7 @@
0 15 IRQ_TYPE_LEVEL_HIGH
0 16 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks SH73A0_CLK_INTCA0>;
+ power-domains = <_a4s>;
control-parent;
};
@@ -120,6 +143,7 @@
0 23 IRQ_TYPE_LEVEL_HIGH
0 24 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks SH73A0_CLK_INTCA0>;
+ power-domains = <_a4s>;
};
irqpin3: irqpin@e69c {
@@ -140,6 +164,7 @@
0 31 IRQ_TYPE_LEVEL_HIGH
0 32 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks SH73A0_CLK_INTCA0>;
+ power-domains = <_a4s>;
};
i2c0: i2c@e682 {
@@ -152,6 +177,7 @@
0 169 IRQ_TYPE_LEVEL_HIGH
0 170 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks SH73A0_CLK_IIC0>;
+ power-domains = <_a3sp>;
status = "disabled";
};
@@ -165,6 +191,7 @@
0 53 IRQ_TYPE_LEVEL_HIGH
0 54 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks SH73A0_CLK_IIC1>;
+ power-domains = <_a3sp>;
status = "disabled";
};
@@ -178,6 +205,7 @@
0 173 IRQ_TYPE_LEVEL_HIGH
0 174 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks SH73A0_CLK_IIC2>;
+
Re: [PATCH 2/2] tracing: Use trace_seq_used() and seq_buf_used() instead of len
On Wed, 19 Nov 2014 15:40:05 +0100 Petr Mladek wrote: > > Regardless of overflow or not (or even if trace_seq is full), that if > > statement will prevent this from doing any buffer overflows. > > > > s->seq.len will never be more than s->seq.size after the test against > > TRACE_MAX_PRINT. So I see no harm here. > > Ah, I see. Well, I would feel more comfortable if it uses > trace_seq_used() or if there is some explanation in a comment. > But you are right, it is safe as it is. Feel free to leave it. > OK, I added this just for you: BTW, using trace_seq_used() would not be good enough because it could return s->seq.size. Which would overflow the buffer on the s->buffer[s->seq.len] = 0; -- Steve >From 1922acc9987d23d0b9c1ad28dc3eaafc1cf2d6b7 Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (Red Hat)" Date: Wed, 19 Nov 2014 10:56:41 -0500 Subject: [PATCH] tracing: Add paranoid size check in trace_printk_seq() To be really paranoid about writing out of bound data in trace_printk_seq(), add another check of len compared to size. Link: http://lkml.kernel.org/r/20141119144004.gb2...@dhcp128.suse.cz Suggested-by: Petr Mladek Signed-off-by: Steven Rostedt --- kernel/trace/trace.c | 8 1 file changed, 8 insertions(+) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 9023446b2c2b..26facec4625e 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -6656,6 +6656,14 @@ trace_printk_seq(struct trace_seq *s) if (s->seq.len >= TRACE_MAX_PRINT) s->seq.len = TRACE_MAX_PRINT; + /* +* More paranoid code. Although the buffer size is set to +* PAGE_SIZE, and TRACE_MAX_PRINT is 1000, this is just +* an extra layer of protection. +*/ + if (WARN_ON_ONCE(s->seq.len >= s->seq.size)) + s->seq.len = s->seq.size - 1; + /* should be zero ended, but we are paranoid. */ s->buffer[s->seq.len] = 0; -- 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/
Re: [PATCH v2] usb: dwc2: resume root hub when device detect with suspend state
On Tue, 18 Nov 2014, Julius Werner wrote: > >> You should be aware that it's not safe to use hcd->state for anything > >> in a host controller driver. That field is owned by usbcore, not by > >> the HCD, and it is not protected by any locks. > >> > >> Thus, for example, hcd->state does not get set to HC_STATE_SUSPENDED > >> until some time after the bus_suspend routine has returned. A > >> port-change interrupt might occur during that time interval. > > Looks like there is explicit code in hcd_bus_suspend() to check for > that race condition right after setting hcd->state, or do I > misinterpret that (the "Did we race with a root-hub wakeup event?" > part)? That code doesn't quite do what you think. For example: CPU 1 CPU 2 - - hcd_bus_suspend(): call hcd->bus_suspend(): root hub gets suspended Wakeup IRQ arrives and is ignored because hcd->state is still HC_STATE_QUIESCING set hcd->state to HC_STATE_SUSPENDED Did we race with a wakeup event? No because usb_hcd_resume_root_hub() wasn't called. Result: the wakeup event is lost. > Also, it seems xhci_bus_suspend() explicitly sets 'hcd->state = > HC_STATE_SUSPENDED' before giving up the spinlock for some > undocumented reason, maybe to avoid exactly this problem. We could > just copy that trick if the hcd.c solution isn't enough (although the > DWC2 bus_suspend/bus_resume in the other patch don't grab that > spinlock right now, where I'm also not so sure if that's a good > idea...). It's better for HCDs to avoid testing hcd->state at all. They should set it to appropriate values at the right times, because usbcore checks it, but they should not test it. This is why ehci-hcd, ohci-hcd, and uhci-hcd all have a private rh_state variable, and they use it while holding their respective private spinlocks. Alan Stern -- 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/7] PM / Domains: Document SH-Mobile AG5 (sh73a0) binding
SH-Mobile AG5 (sh73a0) can be handled by the existing bindings. Signed-off-by: Geert Uytterhoeven --- Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt b/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt index 89ca3f35aec69750..061971bb387f7b27 100644 --- a/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt +++ b/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt @@ -12,6 +12,7 @@ Required properties: fallback. Examples with soctypes are: - "renesas,sysc-r8a7740" (R-Mobile A1) + - "renesas,sysc-sh73a0" (SH-Mobile AG5) - reg: Two address start and address range blocks for the device: - The first block refers to the normally accessible registers, - the second block refers to the registers protected by the HPB -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 02/19] kbuild: kselftest_install - add a new make target to install selftests
On 11/11/2014 01:27 PM, Shuah Khan wrote: > Add a new make target to install to install kernel selftests. > This new target will build and install selftests. kselftest > target now depends on kselftest_install and runs the generated > kselftest script to reduce duplicate work and for common look > and feel when running tests. > > Approach: > > make kselftest_target: > -- exports kselftest INSTALL_KSFT_PATH >default $(INSTALL_MOD_PATH)/lib/kselftest/$(KERNELRELEASE) > -- exports path for ksefltest.sh > -- runs selftests make install target: > > selftests make install target > -- creates kselftest.sh script in install install dir > -- runs install targets for all INSTALL_TARGETS >(Note: ftrace and powerpc aren't included in INSTALL_TARGETS, > to not add more content to patch v1 series. This work > will happen soon. In this series these two targets are > run after running the generated kselftest script, without > any regression in the way these tests are run with > "make kselftest" prior to this work.) > -- install target can be run only from top level source dir. > > Individual test make install targets: > -- install test programs and/or scripts in install dir > -- append to the ksefltest.sh file to add commands to run test > -- install target can be run only from top level source dir. > > Adds the following new ways to initiate selftests: > -- Installing and running kselftest from install directory >by running "make kselftest" > -- Running kselftest script from install directory > > Maintains the following ways to run tests: > -- make -C tools/testing/selftests run_tests > -- make -C tools/testing/selftests TARGETS=target run_tests >Ability specify targets: e.g TARGETS=net > -- make run_tests from tools/testing/selftests > -- make run_tests from individual test directories: >e.g: make run_tests in tools/testing/selftests/breakpoints > > Signed-off-by: Shuah Khan > --- > Makefile | 21 +++-- > 1 file changed, 19 insertions(+), 2 deletions(-) Hi Marek, Did you get a chance to take a look at this patch? -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- 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] ARM: shmobile: R-Mobile: Consolidate rmobile_pd_suspend_*()
Consolidate the identical rmobile_pd_suspend_*() routines that just
return -EBUSY to prevent a PM domain from being powered down into a
single rmobile_pd_suspend_busy().
Signed-off-by: Geert Uytterhoeven
---
arch/arm/mach-shmobile/pm-rmobile.c | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-shmobile/pm-rmobile.c
b/arch/arm/mach-shmobile/pm-rmobile.c
index 5e01a28110e24034..3d383d3dcd4ec640 100644
--- a/arch/arm/mach-shmobile/pm-rmobile.c
+++ b/arch/arm/mach-shmobile/pm-rmobile.c
@@ -209,11 +209,10 @@ void rmobile_add_devices_to_domains(struct
pm_domain_device data[],
#else /* !CONFIG_ARCH_SHMOBILE_LEGACY */
-static int rmobile_pd_suspend_cpu(void)
+static int rmobile_pd_suspend_busy(void)
{
/*
-* This domain contains the CPU core and therefore it should
-* only be turned off if the CPU is not in use.
+* This domain should not be turned off.
*/
return -EBUSY;
}
@@ -227,16 +226,6 @@ static int rmobile_pd_suspend_console(void)
return console_suspend_enabled ? 0 : -EBUSY;
}
-static int rmobile_pd_suspend_debug(void)
-{
- /*
-* This domain contains the Coresight-ETM hardware block and
-* therefore it should only be turned off if the debug module is
-* not in use.
-*/
- return -EBUSY;
-}
-
#define MAX_NUM_CPU_PDS8
static unsigned int num_cpu_pds __initdata;
@@ -310,17 +299,26 @@ static void __init rmobile_setup_pm_domain(struct
device_node *np,
const char *name = pd->genpd.name;
if (pd_contains_cpu(np)) {
+ /*
+* This domain contains the CPU core and therefore it should
+* only be turned off if the CPU is not in use.
+*/
pr_debug("PM domain %s contains CPU\n", name);
pd->gov = _domain_always_on_gov;
- pd->suspend = rmobile_pd_suspend_cpu;
+ pd->suspend = rmobile_pd_suspend_busy;
} else if (np == console_pd) {
pr_debug("PM domain %s contains serial console\n", name);
pd->gov = _domain_always_on_gov;
pd->suspend = rmobile_pd_suspend_console;
} else if (np == debug_pd) {
+ /*
+* This domain contains the Coresight-ETM hardware block and
+* therefore it should only be turned off if the debug module is
+* not in use.
+*/
pr_debug("PM domain %s contains Coresight-ETM\n", name);
pd->gov = _domain_always_on_gov;
- pd->suspend = rmobile_pd_suspend_debug;
+ pd->suspend = rmobile_pd_suspend_busy;
}
rmobile_init_pm_domain(pd);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/7] drivers: sh: Disable PM runtime for multi-platform sh73a0 with genpd
If the default PM domain using PM_CLK is used for PM runtime, the real PM
domain(s) cannot be registered from DT later.
Hence do not enable it when running a multi-platform kernel with genpd
support on an sh73a0. The R-Mobile PM domain driver will take care of
PM runtime management of the module clocks.
The default PM domain is still needed for:
- platforms without genpd support,
- the legacy (non-DT) case, where genpd may take over later, except
for the C5 "always on" PM domain.
Signed-off-by: Geert Uytterhoeven
---
drivers/sh/pm_runtime.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/sh/pm_runtime.c b/drivers/sh/pm_runtime.c
index 85cc89fd3e7d7cb7..2e6f1efadedca1b0 100644
--- a/drivers/sh/pm_runtime.c
+++ b/drivers/sh/pm_runtime.c
@@ -83,6 +83,7 @@ static int __init sh_pm_runtime_init(void)
!of_machine_is_compatible("renesas,r8a73a4") &&
#ifndef CONFIG_PM_GENERIC_DOMAINS_OF
!of_machine_is_compatible("renesas,r8a7740") &&
+ !of_machine_is_compatible("renesas,sh73a0") &&
#endif
!of_machine_is_compatible("renesas,r8a7778") &&
!of_machine_is_compatible("renesas,r8a7779") &&
@@ -91,8 +92,7 @@ static int __init sh_pm_runtime_init(void)
!of_machine_is_compatible("renesas,r8a7792") &&
!of_machine_is_compatible("renesas,r8a7793") &&
!of_machine_is_compatible("renesas,r8a7794") &&
- !of_machine_is_compatible("renesas,sh7372") &&
- !of_machine_is_compatible("renesas,sh73a0"))
+ !of_machine_is_compatible("renesas,sh7372"))
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/7] ARM: shmobile: R-Mobile: Generalize adding/looking up special PM domains
Make adding special PM domains to an array, and looking them up
later, more generic, so it can be used for all special hardware blocks.
The type of PM domain is also stored, so rmobile_setup_pm_domain() can
use a switch() statement instead of a chain of if/else statements.
Signed-off-by: Geert Uytterhoeven
---
arch/arm/mach-shmobile/pm-rmobile.c | 107 ++--
1 file changed, 67 insertions(+), 40 deletions(-)
diff --git a/arch/arm/mach-shmobile/pm-rmobile.c
b/arch/arm/mach-shmobile/pm-rmobile.c
index 3d383d3dcd4ec640..774a8e276049a202 100644
--- a/arch/arm/mach-shmobile/pm-rmobile.c
+++ b/arch/arm/mach-shmobile/pm-rmobile.c
@@ -226,71 +226,89 @@ static int rmobile_pd_suspend_console(void)
return console_suspend_enabled ? 0 : -EBUSY;
}
-#define MAX_NUM_CPU_PDS8
+enum pd_types {
+ PD_NORMAL,
+ PD_CPU,
+ PD_CONSOLE,
+ PD_DEBUG,
+};
-static unsigned int num_cpu_pds __initdata;
-static struct device_node *cpu_pds[MAX_NUM_CPU_PDS] __initdata;
-static struct device_node *console_pd __initdata;
-static struct device_node *debug_pd __initdata;
+#define MAX_NUM_SPECIAL_PDS16
-static void __init get_special_pds(void)
+static struct special_pd {
+ struct device_node *pd;
+ enum pd_types type;
+} special_pds[MAX_NUM_SPECIAL_PDS] __initdata;
+
+static unsigned int num_special_pds __initdata;
+
+static void __init add_special_pd(struct device_node *np, enum pd_types type)
{
- struct device_node *np, *pd;
unsigned int i;
+ struct device_node *pd;
- /* PM domains containing CPUs */
- for_each_node_by_type(np, "cpu") {
- pd = of_parse_phandle(np, "power-domains", 0);
- if (!pd)
- continue;
+ pd = of_parse_phandle(np, "power-domains", 0);
+ if (!pd)
+ return;
- for (i = 0; i < num_cpu_pds; i++)
- if (pd == cpu_pds[i])
- break;
-
- if (i < num_cpu_pds) {
- of_node_put(pd);
- continue;
- }
+ for (i = 0; i < num_special_pds; i++)
+ if (pd == special_pds[i].pd && type == special_pds[i].type)
+ break;
- if (num_cpu_pds == MAX_NUM_CPU_PDS) {
- pr_warn("Too many CPU PM domains\n");
- of_node_put(pd);
- continue;
- }
+ if (i < num_special_pds) {
+ of_node_put(pd);
+ return;
+ }
- cpu_pds[num_cpu_pds++] = pd;
+ if (num_special_pds == ARRAY_SIZE(special_pds)) {
+ pr_warn("Too many special PM domains\n");
+ of_node_put(pd);
+ return;
}
+ pr_debug("Special PM domain %s type %d for %s\n", pd->name, type,
+np->full_name);
+
+ special_pds[num_special_pds].pd = pd;
+ special_pds[num_special_pds].type = type;
+ num_special_pds++;
+}
+
+static void __init get_special_pds(void)
+{
+ struct device_node *np;
+
+ /* PM domains containing CPUs */
+ for_each_node_by_type(np, "cpu")
+ add_special_pd(np, PD_CPU);
+
/* PM domain containing console */
if (of_stdout)
- console_pd = of_parse_phandle(of_stdout, "power-domains", 0);
+ add_special_pd(of_stdout, PD_CONSOLE);
/* PM domain containing Coresight-ETM */
np = of_find_compatible_node(NULL, NULL, "arm,coresight-etm3x");
if (np)
- debug_pd = of_parse_phandle(np, "power-domains", 0);
+ add_special_pd(np, PD_DEBUG);
}
static void __init put_special_pds(void)
{
unsigned int i;
- for (i = 0; i < num_cpu_pds; i++)
- of_node_put(cpu_pds[i]);
- of_node_put(console_pd);
- of_node_put(debug_pd);
+ for (i = 0; i < num_special_pds; i++)
+ of_node_put(special_pds[i].pd);
}
-static bool __init pd_contains_cpu(const struct device_node *pd)
+static enum pd_types __init pd_type(const struct device_node *pd)
{
unsigned int i;
- for (i = 0; i < num_cpu_pds; i++)
- if (pd == cpu_pds[i])
- return true;
+ for (i = 0; i < num_special_pds; i++)
+ if (pd == special_pds[i].pd)
+ return special_pds[i].type;
- return false;
+ return PD_NORMAL;
}
static void __init rmobile_setup_pm_domain(struct device_node *np,
@@ -298,7 +316,8 @@ static void __init rmobile_setup_pm_domain(struct
device_node *np,
{
const char *name = pd->genpd.name;
- if (pd_contains_cpu(np)) {
+ switch (pd_type(np)) {
+ case PD_CPU:
/*
* This domain contains the CPU core and therefore it should
* only be turned off if the CPU is not in
[PATCH 4/7] ARM: shmobile: R-Mobile: Special-case PM domains containing SBSCs
Add a special case for PM domains containing a memory controller like
the SDRAM Bus State Controller (SBSC). Such a PM domain must not be
turned off if SDRAM is in use.
On sh73a0 PM domains A4BC0 and A4BC1 each contain an SDRAM Bus State
Controller (SBSC1 resp. SBSC2). On r8a73a4 PM domain A3BC contains a DDR
Bus Controller (DBSC). In both cases, there are no other devices in
these PM domains, so they were eligible for power down, crashing the
system.
On r8a7740 the DDR3 Bus State Controller (DBSC3) is located in A4S,
whose child domain A3SM contains the CPU core. Hence A4S is never turned
off, and no crash happened.
Signed-off-by: Geert Uytterhoeven
---
arch/arm/mach-shmobile/pm-rmobile.c | 28
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-shmobile/pm-rmobile.c
b/arch/arm/mach-shmobile/pm-rmobile.c
index 774a8e276049a202..4bae656a83b4fca3 100644
--- a/arch/arm/mach-shmobile/pm-rmobile.c
+++ b/arch/arm/mach-shmobile/pm-rmobile.c
@@ -231,6 +231,7 @@ enum pd_types {
PD_CPU,
PD_CONSOLE,
PD_DEBUG,
+ PD_SBSC,
};
#define MAX_NUM_SPECIAL_PDS16
@@ -242,6 +243,14 @@ static struct special_pd {
static unsigned int num_special_pds __initdata;
+static const struct of_device_id special_ids[] __initconst = {
+ { .compatible = "arm,coresight-etm3x", .data = (void *)PD_DEBUG },
+ { .compatible = "renesas,dbsc-r8a73a4", .data = (void *)PD_SBSC, },
+ { .compatible = "renesas,dbsc3-r8a7740", .data = (void *)PD_SBSC, },
+ { .compatible = "renesas,sbsc-sh73a0", .data = (void *)PD_SBSC, },
+ { /* sentinel */ },
+};
+
static void __init add_special_pd(struct device_node *np, enum pd_types type)
{
unsigned int i;
@@ -277,6 +286,7 @@ static void __init add_special_pd(struct device_node *np,
enum pd_types type)
static void __init get_special_pds(void)
{
struct device_node *np;
+ const struct of_device_id *id;
/* PM domains containing CPUs */
for_each_node_by_type(np, "cpu")
@@ -286,10 +296,9 @@ static void __init get_special_pds(void)
if (of_stdout)
add_special_pd(of_stdout, PD_CONSOLE);
- /* PM domain containing Coresight-ETM */
- np = of_find_compatible_node(NULL, NULL, "arm,coresight-etm3x");
- if (np)
- add_special_pd(np, PD_DEBUG);
+ /* PM domains containing other special devices */
+ for_each_matching_node_and_match(np, special_ids, )
+ add_special_pd(np, (enum pd_types)id->data);
}
static void __init put_special_pds(void)
@@ -344,6 +353,17 @@ static void __init rmobile_setup_pm_domain(struct
device_node *np,
pd->suspend = rmobile_pd_suspend_busy;
break;
+ case PD_SBSC:
+ /*
+* This domain contains the SDRAM Bus State Controller and
+* therefore it should only be turned off if SDRAM is not in
+* use.
+*/
+ pr_debug("PM domain %s contains SBSC\n", name);
+ pd->gov = _domain_always_on_gov;
+ pd->suspend = rmobile_pd_suspend_busy;
+ break;
+
case PD_NORMAL:
break;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] ARM: at91/dt: add trng node
On 30/09/2014 18:19, Boris Brezillon :
> Add a DT node for the TRNG (True Random Number Generator) block.
>
> Keep this block enabled as it does not depend on any external connection,
> and thus should be available on all boards.
>
> Signed-off-by: Boris Brezillon
For patches 2 to 5, you can add my:
Acked-by: Nicolas Ferre
while re-sending a series. Maybe add linux-crypto and the "HARDWARE
RANDOM NUMBER GENERATOR CORE" guys to the CC list.
Bye,
> ---
> arch/arm/boot/dts/at91sam9g45.dtsi | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi
> b/arch/arm/boot/dts/at91sam9g45.dtsi
> index 932a669..790c890 100644
> --- a/arch/arm/boot/dts/at91sam9g45.dtsi
> +++ b/arch/arm/boot/dts/at91sam9g45.dtsi
> @@ -934,6 +934,13 @@
> status = "disabled";
> };
>
> + trng@fffcc000 {
> + compatible = "atmel,at91sam9g45-trng";
> + reg = <0xfffcc000 0x4000>;
> + interrupts = <6 IRQ_TYPE_LEVEL_HIGH 0>;
> + clocks = <_clk>;
> + };
> +
> i2c0: i2c@fff84000 {
> compatible = "atmel,at91sam9g10-i2c";
> reg = <0xfff84000 0x100>;
>
--
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC 0/7] ARM: shmobile: sh73a0: DT PM domain support
Hi Simon, Magnus,
This patch series enables DT support for PM domains on the Renesas SH-Mobile
AG5 (sh73a0) SoC. It is marked "RFC" due to the addition of memory-controllers
nodes without bindings in patch [5/7] and [7/7].
This series builds further on the series "[PATCH v5 0/8] ARM: shmobile:
R-Mobile: DT PM domain support", which added similar support for R-Mobile A1
(r8a7740). Due to the similarity of the SYSC System-Controller on the various
SH-Mobile/R-Mobile SoCs, and the abstraction of PM domains in DT, the same
driver can handle sh73a0 after some small modifications, without changing the
DT bindings.
Compared to r8a7740, the only significant change is the move of the
memory-controller(s) to separate PM domains on sh73a0 (and also on R-Mobile
APE6 (r8a73a4)). Hence a provision must be made to not turn off these PM
domains inadvertently. Please see patch [5/7] ("[RFC] ARM: shmobile: sh73a0
dtsi: Add PM domain support"), and the follow-up patch for r8a7740 [7/7]
("[RFC] ARM: shmobile: r8a7740 dtsi: Add missing memory-controller node") for
more details.
This was tested on kzm9g-multiplatform.
Functionality-wise, it behaves the same as the legacy (non-DT) version (modulo
missing DT support in some device drivers).
Thanks for your comments!
Dependencies:
- [PATCH v5 0/8] ARM: shmobile: R-Mobile: DT PM domain support,
- [[PATCH v5 0/6] sh73a0 common clock framework implementation,
- [PATCH 2/2] ARM: shmobile: sh73a0 dtsi: Add missing INTCA0 clock for
irqpin module.
Geert Uytterhoeven (7):
PM / Domains: Document SH-Mobile AG5 (sh73a0) binding
ARM: shmobile: R-Mobile: Consolidate rmobile_pd_suspend_*()
ARM: shmobile: R-Mobile: Generalize adding/looking up special PM
domains
ARM: shmobile: R-Mobile: Special-case PM domains containing SBSCs
[RFC] ARM: shmobile: sh73a0 dtsi: Add PM domain support
drivers: sh: Disable PM runtime for multi-platform sh73a0 with genpd
[RFC] ARM: shmobile: r8a7740 dtsi: Add missing memory-controller node
.../bindings/power/renesas,sysc-rmobile.txt| 1 +
arch/arm/boot/dts/r8a7740.dtsi | 6 +
arch/arm/boot/dts/sh73a0.dtsi | 159 -
arch/arm/mach-shmobile/pm-rmobile.c| 159 +
drivers/sh/pm_runtime.c| 4 +-
5 files changed, 268 insertions(+), 61 deletions(-)
--
1.9.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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] [RFC] ARM: shmobile: r8a7740 dtsi: Add missing memory-controller node
Add a memory-controller node for the DDR3 Bus State Controller (DBSC3),
which lies in the A4S PM domain.
There are no documented bindings for the DBSC3 yet (so far there's still
no need for a driver), but all of its properties follow the standard
conventions.
This has no visible effect for now, as A4S is never turned off because
its child domain A3SM contains the CPU core.
Signed-off-by: Geert Uytterhoeven
---
Question: Should I make dbsc3 a minimal node for now, i.e. retain only
its "compatible" and "power-domains" properties?
---
arch/arm/boot/dts/r8a7740.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
index 95723764431a3e5d..173d4340bba1c4fa 100644
--- a/arch/arm/boot/dts/r8a7740.dtsi
+++ b/arch/arm/boot/dts/r8a7740.dtsi
@@ -37,6 +37,12 @@
<0xc200 0x1000>;
};
+ dbsc3: memory-controller@fe40 {
+ compatible = "renesas,dbsc3-r8a7740";
+ reg = <0xfe40 0x400>;
+ power-domains = <_a4s>;
+ };
+
pmu {
compatible = "arm,cortex-a9-pmu";
interrupts = <0 83 IRQ_TYPE_LEVEL_HIGH>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
