Re: linux-next: rebase of the jdelvare-hwmon quilt series
Hi Stephen, On Thu, 11 Jul 2013 10:27:24 +1000, Stephen Rothwell wrote: > Why have you just rebased the jdelvare-hwmon series > (http://khali.linux-fr.org/devel/linux-3/jdelvare-hwmon/)? You have > just invalidated your testing and made it likely that Linus will blast > you if you ask him to pull your patches. Your whole series was already > based after v3.10 (i.e. released or rebased after the merge window > opened), so why move it again? I'm quite confused by this complaint of yours. I do not have the feeling that I rebased anything or invalidated any testing. And I don't think I did anything different this time from the way I have been proceeding for years. I had only 2 hwmon patches for Linus for this merge window: hwmon-lm63-drop-redundant-safety.patch hwmon-lm90-drop-redundant-safety.patch They have been in http://khali.linux-fr.org/devel/linux-3/jdelvare-hwmon/ (and thus in linux-next) continuously since May 19th so I'd say they received pretty good testing. I did not touch them, I did not even have to refresh them. 3 days ago I added these 2 patches to the hwmon-for-linus branch of my staging tree: http://git.kernel.org/cgit/linux/kernel/git/jdelvare/staging.git/log/?h=hwmon-for-linus and asked Linux to pull from it. Yesterday I reviewed a new (trivial) hwmon patch, and I accepted it, so it was added to http://khali.linux-fr.org/devel/linux-3/jdelvare-hwmon/ as hwmon-w83792d-update-module-author.patch (and thus went to linux-next.) Last night Linus pulled from http://git.kernel.org/cgit/linux/kernel/git/jdelvare/staging.git/log/?h=hwmon-for-linus so the 2 "old" patches are now merged upstream. The one "new" patch is not, it will get upstream next time I ask Linus to pull from my staging tree. This is how things have happened, and I just can't see anything wrong. If you do, please explain what you thing shouldn't have happened, and let me know what I should have done instead. Thanks, -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] pci: exynos: split into two parts such as Synopsys part and Exynos part
Exynos PCIe IP consists of Synopsys specific part and Exynos
specific part. Only core block is a Synopsys designware part;
other parts are Exynos specific.
Also, the Synopsys designware part can be shared with other
platforms; thus, it can be split two parts such as Synopsys
designware part and Exynos specific part.
Signed-off-by: Jingoo Han
Cc: Pratyush Anand
Cc: Mohit KUMAR
---
Changes since v1:
- moved the configuration, I/O, memory space handling to dw_pcie_host_init()
- removed exynos_pcie_abort()
- replaced 'purple_base' with 'block_base'
- replaced 'dbi_base' with 'dbi_addr'
drivers/pci/host/Makefile |1 +
drivers/pci/host/pcie-designware.c | 963 +---
drivers/pci/host/pcie-designware.h | 71 +++
drivers/pci/host/pcie-exynos.c | 523
4 files changed, 822 insertions(+), 736 deletions(-)
create mode 100644 drivers/pci/host/pcie-designware.h
create mode 100644 drivers/pci/host/pcie-exynos.c
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 086d850..7e59864 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
obj-$(CONFIG_PCIE_DW) += pcie-designware.o
+obj-$(CONFIG_PCI_EXYNOS) += pcie-exynos.o
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index 26bdbda..b372ead 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -1,5 +1,5 @@
/*
- * PCIe host controller driver for Samsung EXYNOS SoCs
+ * Synopsys Designware PCIe host controller driver
*
* Copyright (C) 2013 Samsung Electronics Co., Ltd.
* http://www.samsung.com
@@ -11,64 +11,14 @@
* published by the Free Software Foundation.
*/
-#include
-#include
-#include
-#include
#include
-#include
#include
-#include
#include
-#include
-#include
#include
#include
-#include
-#include
-#include
-#include
#include
-struct pcie_port_info {
- u32 cfg0_size;
- u32 cfg1_size;
- u32 io_size;
- u32 mem_size;
- phys_addr_t io_bus_addr;
- phys_addr_t mem_bus_addr;
-};
-
-struct pcie_port {
- struct device *dev;
- u8 controller;
- u8 root_bus_nr;
- void __iomem*dbi_base;
- void __iomem*elbi_base;
- void __iomem*phy_base;
- void __iomem*purple_base;
- u64 cfg0_base;
- void __iomem*va_cfg0_base;
- u64 cfg1_base;
- void __iomem*va_cfg1_base;
- u64 io_base;
- u64 mem_base;
- spinlock_t conf_lock;
- struct resource cfg;
- struct resource io;
- struct resource mem;
- struct pcie_port_info config;
- struct clk *clk;
- struct clk *bus_clk;
- int irq;
- int reset_gpio;
-};
-
-/*
- * Exynos PCIe IP consists of Synopsys specific part and Exynos
- * specific part. Only core block is a Synopsys designware part;
- * other parts are Exynos specific.
- */
+#include "pcie-designware.h"
/* Synopsis specific PCIE configuration registers */
#define PCIE_PORT_LINK_CONTROL 0x710
@@ -108,69 +58,14 @@ struct pcie_port {
#define PCIE_ATU_FUNC(x) (((x) & 0x7) << 16)
#define PCIE_ATU_UPPER_TARGET 0x91C
-/* Exynos specific PCIE configuration registers */
-
-/* PCIe ELBI registers */
-#define PCIE_IRQ_PULSE 0x000
-#define IRQ_INTA_ASSERT(0x1 << 0)
-#define IRQ_INTB_ASSERT(0x1 << 2)
-#define IRQ_INTC_ASSERT(0x1 << 4)
-#define IRQ_INTD_ASSERT(0x1 << 6)
-#define PCIE_IRQ_LEVEL 0x004
-#define PCIE_IRQ_SPECIAL 0x008
-#define PCIE_IRQ_EN_PULSE 0x00c
-#define PCIE_IRQ_EN_LEVEL 0x010
-#define PCIE_IRQ_EN_SPECIAL0x014
-#define PCIE_PWR_RESET 0x018
-#define PCIE_CORE_RESET0x01c
-#define PCIE_CORE_RESET_ENABLE (0x1 << 0)
-#define PCIE_STICKY_RESET 0x020
-#define PCIE_NONSTICKY_RESET 0x024
-#define PCIE_APP_INIT_RESET0x028
-#define PCIE_APP_LTSSM_ENABLE 0x02c
-#define PCIE_ELBI_RDLH_LINKUP 0x064
-#define PCIE_ELBI_LTSSM_ENABLE 0x1
-#define PCIE_ELBI_SLV_AWMISC 0x11c
-#define PCIE_ELBI_SLV_ARMISC 0x120
-#define PCIE_ELBI_SLV_DBI_ENABLE (0x1 << 21)
-
-/* PCIe Purple registers */
-#define PCIE_PHY_GLOBAL_RESET 0x000
-#define PCIE_PHY_COMMON_RESET 0x004
-#define PCIE_PHY_CMN_REG 0x008
-#define PCIE_PHY_MAC_RESET
Re: [PATCH] cpufreq: Fix cpufreq regression after suspend/resume
2013/7/11 Srivatsa S. Bhat :
> Hi Toralf,
>
> On 07/11/2013 02:20 AM, Toralf Förster wrote:
>> I tested the patch several times on top of a66b2e5 - the origin issue is
>> fixed but - erratically another issue now appears : all 4 cores are runs
>> after wakeup at 2.6 GHz.
>> The temporary hot fix is to switch between governor performance and
>> ondemand for all 4 cores.
>>
>>
>
> Thanks for all your testing efforts. The commit a66b2e5 took a shortcut to
> achieve its goals but failed subtly in many aspects. Below is a patch (only
> compile-tested) which tries to achieve the goal (preserve sysfs files) in
> the proper way, by separating out the cpufreq-core bits from the sysfs bits.
> You might want to give it a try on current mainline and see if it improves
> anything.
>
> Regards,
> Srivatsa S. Bhat
>
>
> (Applies on current mainline)
> ---
>
> drivers/cpufreq/cpufreq.c | 144
> ++---
> 1 file changed, 82 insertions(+), 62 deletions(-)
>
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 6a015ad..28c690f 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -834,11 +834,8 @@ static int cpufreq_add_dev_interface(unsigned int cpu,
> struct cpufreq_policy *policy,
> struct device *dev)
> {
> - struct cpufreq_policy new_policy;
> struct freq_attr **drv_attr;
> - unsigned long flags;
> int ret = 0;
> - unsigned int j;
>
> /* prepare interface data */
> ret = kobject_init_and_add(>kobj, _cpufreq,
> @@ -870,31 +867,10 @@ static int cpufreq_add_dev_interface(unsigned int cpu,
> goto err_out_kobj_put;
> }
>
> - write_lock_irqsave(_driver_lock, flags);
> - for_each_cpu(j, policy->cpus) {
> - per_cpu(cpufreq_cpu_data, j) = policy;
> - per_cpu(cpufreq_policy_cpu, j) = policy->cpu;
> - }
> - write_unlock_irqrestore(_driver_lock, flags);
> -
> ret = cpufreq_add_dev_symlink(cpu, policy);
> if (ret)
> goto err_out_kobj_put;
>
> - memcpy(_policy, policy, sizeof(struct cpufreq_policy));
> - /* assure that the starting sequence is run in __cpufreq_set_policy */
> - policy->governor = NULL;
> -
> - /* set default policy */
> - ret = __cpufreq_set_policy(policy, _policy);
> - policy->user_policy.policy = policy->policy;
> - policy->user_policy.governor = policy->governor;
> -
> - if (ret) {
> - pr_debug("setting policy failed\n");
> - if (cpufreq_driver->exit)
> - cpufreq_driver->exit(policy);
> - }
> return ret;
>
> err_out_kobj_put:
> @@ -905,7 +881,7 @@ err_out_kobj_put:
>
> #ifdef CONFIG_HOTPLUG_CPU
> static int cpufreq_add_policy_cpu(unsigned int cpu, unsigned int sibling,
> - struct device *dev)
> + struct device *dev, bool init_sysfs)
> {
> struct cpufreq_policy *policy;
> int ret = 0, has_target = !!cpufreq_driver->target;
> @@ -933,30 +909,25 @@ static int cpufreq_add_policy_cpu(unsigned int cpu,
> unsigned int sibling,
> __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
> }
>
> - ret = sysfs_create_link(>kobj, >kobj, "cpufreq");
> - if (ret) {
> - cpufreq_cpu_put(policy);
> - return ret;
> + if (init_sysfs) {
> + ret = sysfs_create_link(>kobj, >kobj, "cpufreq");
> + if (ret) {
> + cpufreq_cpu_put(policy);
> + return ret;
> + }
> }
>
> return 0;
> }
> #endif
>
> -/**
> - * cpufreq_add_dev - add a CPU device
> - *
> - * Adds the cpufreq interface for a CPU device.
> - *
> - * The Oracle says: try running cpufreq registration/unregistration
> concurrently
> - * with with cpu hotplugging and all hell will break loose. Tried to clean
> this
> - * mess up, but more thorough testing is needed. - Mathieu
> - */
> -static int cpufreq_add_dev(struct device *dev, struct subsys_interface *sif)
> +static int __cpufreq_add_dev(struct device *dev, struct subsys_interface
> *sif,
> +bool init_sysfs)
> {
> unsigned int j, cpu = dev->id;
> int ret = -ENOMEM;
> struct cpufreq_policy *policy;
> + struct cpufreq_policy new_policy;
> unsigned long flags;
> #ifdef CONFIG_HOTPLUG_CPU
> struct cpufreq_governor *gov;
> @@ -984,7 +955,8 @@ static int cpufreq_add_dev(struct device *dev, struct
> subsys_interface *sif)
> struct cpufreq_policy *cp = per_cpu(cpufreq_cpu_data,
> sibling);
> if (cp && cpumask_test_cpu(cpu, cp->related_cpus)) {
> read_unlock_irqrestore(_driver_lock, flags);
> -
Re: [RFC PATCH 1/5] mm, page_alloc: support multiple pages allocation
On 07/10/2013 06:02 PM, Joonsoo Kim wrote:
> On Wed, Jul 10, 2013 at 03:52:42PM -0700, Dave Hansen wrote:
>> On 07/03/2013 01:34 AM, Joonsoo Kim wrote:
>>> - if (page)
>>> + do {
>>> + page = buffered_rmqueue(preferred_zone, zone, order,
>>> + gfp_mask, migratetype);
>>> + if (!page)
>>> + break;
>>> +
>>> + if (!nr_pages) {
>>> + count++;
>>> + break;
>>> + }
>>> +
>>> + pages[count++] = page;
>>> + if (count >= *nr_pages)
>>> + break;
>>> +
>>> + mark = zone->watermark[alloc_flags & ALLOC_WMARK_MASK];
>>> + if (!zone_watermark_ok(zone, order, mark,
>>> + classzone_idx, alloc_flags))
>>> + break;
>>> + } while (1);
>>
>> I'm really surprised this works as well as it does. Calling
>> buffered_rmqueue() a bunch of times enables/disables interrupts a bunch
>> of times, and mucks with the percpu pages lists a whole bunch.
>> buffered_rmqueue() is really meant for _single_ pages, not to be called
>> a bunch of times in a row.
>>
>> Why not just do a single rmqueue_bulk() call?
>
> rmqueue_bulk() needs a zone lock. If we allocate not so many pages,
> for example, 2 or 3 pages, it can have much more overhead rather than
> allocationg 1 page multiple times. So, IMHO, it is better that
> multiple pages allocation is supported on top of percpu pages list.
It makes _zero_ sense to be doing a number of buffered_rmqueue() calls
that are approaching the size of the percpu pages batches. If you end
up doing that, you pay both the overhead in manipulating both the percpu
page data _and_ the buddy lists.
You're probably right for small numbers of pages. But, if we're talking
about things that are more than, say, 100 pages (isn't the pcp batch
size clamped to 128 4k pages?) you surely don't want to be doing
buffered_rmqueue().
I'd also like to see some scalability numbers on this. How do your
tests look when all the CPUs on the system are hammering away?
> And I think that enables/disables interrupts a bunch of times help
> to avoid a latency problem. If we disable interrupts until the whole works
> is finished, interrupts can be handled too lately.
> free_hot_cold_page_list() already do enables/disalbed interrupts a bunch of
> times.
I don't think interrupt latency is going to be a problem on the scale
we're talking about here. There are much, much, much worse offenders in
the kernel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/7] Driver core and sysfs changes for attribute groups
On Wed, Jul 10, 2013 at 05:35:58PM -0700, Greg Kroah-Hartman wrote: > Hi all, > > Here's the second iteration of the patchset to add better attribute > group support to the driver core and sysfs. > > I've tested these (shocker!) and everything works fine with them (I'm > sending this from Linus's latest kernel with these 7 on top of it.) > > I'd like to send these to Linus for 3.11 unless someone objects. > > Oliver, please use this series instead of the last one, it has fixes > that Guenter pointed out that would have crashed your box at boot. > > changes from v2: > - actually boots > - 7th patch added properly > - added BUS_ATTR, CLASS_ATTR, and DRIVER_ATTR RW and RO macros > to help with converting code to use attributes properly. > Looks good this time. And, yes, it does boot and work, including patch #7. Feel free to add Reviewed-by: Guenter Roeck and if you like Tested-by: Guenter Roeck to the series. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/8] KVM: PPC: Add support for multiple-TCE hcalls
On 07/10/2013 08:05 PM, Alexander Graf wrote: > > On 10.07.2013, at 07:00, Alexey Kardashevskiy wrote: > >> On 07/10/2013 03:02 AM, Alexander Graf wrote: >>> On 07/06/2013 05:07 PM, Alexey Kardashevskiy wrote: This adds real mode handlers for the H_PUT_TCE_INDIRECT and H_STUFF_TCE hypercalls for QEMU emulated devices such as IBMVIO devices or emulated PCI. These calls allow adding multiple entries (up to 512) into the TCE table in one call which saves time on transition to/from real mode. >>> >>> We don't mention QEMU explicitly in KVM code usually. >>> This adds a tce_tmp cache to kvm_vcpu_arch to save valid TCEs (copied from user and verified) before writing the whole list into the TCE table. This cache will be utilized more in the upcoming VFIO/IOMMU support to continue TCE list processing in the virtual mode in the case if the real mode handler failed for some reason. This adds a guest physical to host real address converter and calls the existing H_PUT_TCE handler. The converting function is going to be fully utilized by upcoming VFIO supporting patches. This also implements the KVM_CAP_PPC_MULTITCE capability, so in order to support the functionality of this patch, QEMU needs to query for this capability and set the "hcall-multi-tce" hypertas property only if the capability is present, otherwise there will be serious performance degradation. >>> >>> Same as above. But really you're only giving recommendations here. What's >>> the point? Please describe what the benefit of this patch is, not what some >>> other random subsystem might do with the benefits it brings. >>> Signed-off-by: Paul Mackerras Signed-off-by: Alexey Kardashevskiy --- Changelog: 2013/07/06: * fixed number of wrong get_page()/put_page() calls 2013/06/27: * fixed clear of BUSY bit in kvmppc_lookup_pte() * H_PUT_TCE_INDIRECT does realmode_get_page() now * KVM_CAP_SPAPR_MULTITCE now depends on CONFIG_PPC_BOOK3S_64 * updated doc 2013/06/05: * fixed mistype about IBMVIO in the commit message * updated doc and moved it to another section * changed capability number 2013/05/21: * added kvm_vcpu_arch::tce_tmp * removed cleanup if put_indirect failed, instead we do not even start writing to TCE table if we cannot get TCEs from the user and they are invalid * kvmppc_emulated_h_put_tce is split to kvmppc_emulated_put_tce and kvmppc_emulated_validate_tce (for the previous item) * fixed bug with failthrough for H_IPI * removed all get_user() from real mode handlers * kvmppc_lookup_pte() added (instead of making lookup_linux_pte public) Signed-off-by: Alexey Kardashevskiy --- Documentation/virtual/kvm/api.txt | 25 +++ arch/powerpc/include/asm/kvm_host.h | 9 ++ arch/powerpc/include/asm/kvm_ppc.h | 16 +- arch/powerpc/kvm/book3s_64_vio.c| 154 ++- arch/powerpc/kvm/book3s_64_vio_hv.c | 260 arch/powerpc/kvm/book3s_hv.c| 41 - arch/powerpc/kvm/book3s_hv_rmhandlers.S | 6 + arch/powerpc/kvm/book3s_pr_papr.c | 37 - arch/powerpc/kvm/powerpc.c | 3 + 9 files changed, 517 insertions(+), 34 deletions(-) diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 6365fef..762c703 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -2362,6 +2362,31 @@ calls by the guest for that service will be passed to userspace to be handled. +4.86 KVM_CAP_PPC_MULTITCE + +Capability: KVM_CAP_PPC_MULTITCE +Architectures: ppc +Type: vm + +This capability means the kernel is capable of handling hypercalls +H_PUT_TCE_INDIRECT and H_STUFF_TCE without passing those into the user +space. This significanly accelerates DMA operations for PPC KVM guests. >>> >>> significanly? Please run this through a spell checker. >>> +The user space should expect that its handlers for these hypercalls >>> >>> s/The// >>> +are not going to be called. >>> >>> Is user space guaranteed they will not be called? Or can it still happen? >> >> ... if user space previously registered LIOBN in KVM (via >> KVM_CREATE_SPAPR_TCE or similar calls). >> >> ok? > > How about this? > > The hypercalls mentioned above may or may not be processed successfully in > the kernel based fast path. If they can not be handled by the kernel, they > will get passed on to user space. So user space still has to have an > implementation for these despite the in kernel acceleration. > > --- > > The target audience for this documentation is user space KVM API users. > Someone developing kvm tool for
[PATCH] power: Fix comment typo in pm_wakeup.h
This patch fix typo (sorce -> source) Signed-off-by: Chanwoo Choi --- include/linux/pm_wakeup.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/pm_wakeup.h b/include/linux/pm_wakeup.h index 569781f..a0f7080 100644 --- a/include/linux/pm_wakeup.h +++ b/include/linux/pm_wakeup.h @@ -36,8 +36,8 @@ * @last_time: Monotonic clock when the wakeup source's was touched last time. * @prevent_sleep_time: Total time this source has been preventing autosleep. * @event_count: Number of signaled wakeup events. - * @active_count: Number of times the wakeup sorce was activated. - * @relax_count: Number of times the wakeup sorce was deactivated. + * @active_count: Number of times the wakeup source was activated. + * @relax_count: Number of times the wakeup source was deactivated. * @expire_count: Number of times the wakeup source's timeout has expired. * @wakeup_count: Number of times the wakeup source might abort suspend. * @active: Status of the wakeup source. -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] perf tools: Make Power7 events available for perf
On Wed, 10 Jul 2013, Ingo Molnar wrote: > Exactly - PMUs enumerated in /sys should be self-identifying, it's a > hardware topology after all ... > > Anytime userspace is forced to look into /proc, or into weird places in > /sys it's a FAIL really. well on x86 you have to look at /proc/cpuinfo to get the vendor/family/model number. Should we add some specifier under sys? It's probably too late though as all userspace event libs will have to look at /proc/cpuinfo anyway to be backwards compatible. Vince -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 -next 2/2] kbuild: fix for updated LZ4 tool with the new streaming format
> > BTW speaking of introductory-level patches, what about the following > one: > > Now that lz4 kernel compression is available, add *.lz4 to .gitignore > > diff --git a/.gitignore b/.gitignore > index 3b8b9b3..7e9932e 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -29,6 +29,7 @@ modules.builtin > *.bz2 > *.lzma > *.xz > +*.lz4 > *.lzo > *.patch > *.gcno > Acked-by: Kyungsik Lee Thanks, Kyungsik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf annotate: Fix SEGV with assembly labels
I'm getting a SEGV when running perf annotate on a ppc64 box. The objdump -S output causing the SEGV looks like: b .ret_from_except_lite c000a508: b c000a4d4 <.ret_from_except_lite> 1: bl .save_nvgprs c000a50c: bl c000a110 <.save_nvgprs> symbol__parse_objdump_line makes an effort to distinguish between instruction addresses and assembly labels but the check is insufficent. In the above case we get line_ip = 1, and (line_ip - start) is positive so our offset < 0 check does not catch it. Fix this by adding an unsigned comparison against start. Signed-off-by: Anton Blanchard Cc: --- diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c index d102716..a791d23 100644 --- a/tools/perf/util/annotate.c +++ b/tools/perf/util/annotate.c @@ -809,7 +809,7 @@ static int symbol__parse_objdump_line(struct symbol *sym, struct map *map, end = map__rip_2objdump(map, sym->end); offset = line_ip - start; - if (offset < 0 || (u64)line_ip > end) + if (offset < 0 || (u64)line_ip < start || (u64)line_ip > end) offset = -1; else parsed_line = tmp2 + 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 V3] extcon: palmas: Option to disable ID/VBUS detection based on platform
On 07/11/2013 12:08 PM, Laxman Dewangan wrote:
> On Thursday 11 July 2013 08:12 AM, Chanwoo Choi wrote:
>> Hi Laxman,
>>
>>> static int palmas_usb_probe(struct platform_device *pdev)
>>> @@ -137,20 +140,26 @@ static int palmas_usb_probe(struct platform_device
>>> *pdev)
>>> struct palmas_usb *palmas_usb;
>>> int status;
>>> -if (node && !pdata) {
>>> -pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
>>> -
>>> -if (!pdata)
>>> -return -ENOMEM;
>>> +palmas_usb = devm_kzalloc(>dev, sizeof(*palmas_usb), GFP_KERNEL);
>>> +if (!palmas_usb)
>>> +return -ENOMEM;
>>> -pdata->wakeup = of_property_read_bool(node, "ti,wakeup");
>>> +if (node && !pdata) {
>>> +palmas_usb->wakeup = of_property_read_bool(node, "ti,wakeup");
>>> +palmas_usb->enable_id_detection = of_property_read_bool(node,
>>> +"ti,enable-id-detection");
>>> +palmas_usb->enable_vbus_detection = of_property_read_bool(node,
>>> +"ti,enable-vbus-detection");
>>> +} else if (pdata) {
>>> +palmas_usb->wakeup = pdata->wakeup;
>>> +palmas_usb->enable_id_detection = true;
>>> +palmas_usb->enable_vbus_detection = true;
>>> } else if (!pdata) {
>>> -return -EINVAL;
>>> +palmas_usb->wakeup = true;
>>> +palmas_usb->enable_id_detection = true;
>>> +palmas_usb->enable_vbus_detection = true;
>>> }
>> I think we could modify it as following patch to remove duplicate line.
>> If you agree about below modification, I will apply your patch with
>> following patch.
>>
> I am fine with this and this looks simple and straight.
>
> I have seen some patches/discussion from TI to remove the platform data
> support at all and hence removing from here in future will be very simple.
>
This patch is applied on extcon-linus branch.
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [GIT] kbuild changes for v3.11-rc1
On Wed, Jul 10, 2013 at 07:11:53PM -0700, Linus Torvalds wrote: > Commit d2aae8477cd00325bb7c7c7e95be488088900c48 is broken. It causes > root to re-write "include/config/kernel.release". > > There is no excuse for this. That commit is shit. There's no way in > hell that "make modules_install" should ever rebuild anything, so > adding that kind of dependency is fundamentally wrong and broken. > > And that totally crap commit is even marked for stable. It's now dropped from my stable to-apply queue. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/4] Radio device framework
On Thu, Jul 11, 2013 at 09:29:49AM +0530, Akhil Goyal wrote: > On 7/8/2013 3:19 PM, akhil.go...@freescale.com wrote: > >From: Akhil Goyal > > > >RF signal path is integral part of any system that transmits/receives RF > >(radio frequency) signals. In these systems Data is processed/converted > >to IQ samples (digital representation a RF signal) and passed to a RFIC > >(RF PHY) which converts the digital RF signal (IQ samples) to analog and > >transmits over antenna. > > > >Typically The signal path consists of multiple components: > > > >Antenna controller<-> vector signal processors<-> RFIC<-> Antenna > > > >Each of these components have specific functionalities: > > > >1. Antenna controller: Framing of digital IQ data into protocol specific > >frames. > >2. vector signal processors: For conditioning of signal. > >3. RFIC : converts digital IQ data to analog signal which is > >transmitted/received on/from Air. > > > >Also it is desirable to control the complete signal path, for example: > >bringing the complete signal path up/down etc. > > > >The radio device framework introduces a way to accommodate the RF signal > >paths. One signal path is represented as a RF device (rf0, rf1 etc), and > >it can contain multiple components which have their individual vendor > >specific drivers. The framework provides mechanism by which individual > >components can register with RF framework, and the framework will handle the > >binding > >of individual component devices to a RF device. RF device exports the control > >interfaces to user space, and this user space interface is independent of > >component (vendor specific) drivers. > > > >This patch set include > >1. RF Interface: Independent of phy or antenna controller. > >2. AIC driver: Antenna interface Controller(AIC) of Hetrogenous SOC's > >like BSC9131, BSC9132 > >4. Device tree bindings for AIC. > >5. Device tree changes for BSC9131-AIC > > > >changes in v2: > >1. incorporated comments for handling pointers in user space API structures. > >2. Removed patches for AD9361 phy driver. It shall be sent once a proper > >driver is in place for AD9361 chip > >3. Removed Device tree nodes/bindings for AD9361 > >4. Incorporated comments for proper handling of wait_events > >5. Added Documentation for IOCTL APIs and the structures used. > >6. Inserted paddings in user space structures. > >7. Reorganized code for rfdev.c to remove forward declaration and broke the > >rf_ioctl() function to handle local structures correctly. > >8. Corrected the error handling for mutex used. > > > > Hi Arnd/Greg, > > It has been 3-4 days for this patch set and there are no review > comments on these patches. Please suggest a way forward for the > patch set. I have incorporated all the review comments for v1. We are thick in the middle of the merge window for 3.11-rc1 and have _no_ time for reviewing anything new, please give us a chance to catch up with our existing work before asking about new stuff that is not going to happen until 3.12 at the earliest. In sort, patience please. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Jul 11
Hi all, Changes since 20130710: The slab tree lost its build failure. The akpm tree lost a patch that turned up elsewhere. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 230 trees (counting Linus' and 33 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (ae92494 Merge branch 'misc' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild) Merging fixes/master (8177a9d lseek(fd, n, SEEK_END) does *not* go to eof - n) Merging kbuild-current/rc-fixes (42a0940 Merge branch 'yem-kconfig-rc-fixes' of git://gitorious.org/linux-kconfig/linux-kconfig into kbuild/rc-fixes) Merging arc-current/for-curr (baadb8f ARC: warn on improper stack unwind FDE entries) Merging arm-current/fixes (3e0a07f ARM: 7773/1: PJ4B: Add support for errata 4742) Merging m68k-current/for-linus (767bcb4 Merge branch 'exotic-arch-fixes' into for-next) Merging metag-fixes/fixes (d903bca metag: checksum.h: fix carry in csum_tcpudp_nofold) Merging powerpc-merge/merge (ea461ab powerpc/eeh: Fix fetching bus for single-dev-PE) Merging sparc/master (961246b [PATCH] sparc32: vm_area_struct access for old Sun SPARCs.) Merging net/master (bfffbea Merge tag 'mmc-updates-for-3.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc) Merging ipsec/master (01cb71d net_sched: restore "overhead xxx" handling) Merging sound-current/for-linus (42d4ab8 ALSA: usb-audio: fix regression for fixed stream quirk) Merging pci-current/for-linus (65694c5 x86/PCI: Map PCI setup data with ioremap() so it can be in highmem) Merging wireless/master (57bf744 Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth) Merging driver-core.current/driver-core-linus (fc76a25 Merge tag 'driver-core-3.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core) Merging tty.current/tty-linus (9e895ac Linux 3.10-rc7) Merging usb.current/usb-linus (fc76a25 Merge tag 'driver-core-3.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core) Merging staging.current/staging-linus (fc76a25 Merge tag 'driver-core-3.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core) Merging char-misc.current/char-misc-linus (fc76a25 Merge tag 'driver-core-3.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core) Merging input-current/for-linus (62f548d Input: cyttsp4 - use 16bit address for I2C/SPI communication) Merging md-current/for-linus (1376512 md/raid10: fix bug which causes all RAID10 reshapes to move no data.) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (9c23b7d crypto: caam - Fixed the memory out of bound overwrite issue) Merging ide/master (1581208 ide: Fix IDE PIO size calculation) Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (d94ea3f irqchip: Return -EPERM for reserved IRQs) Merging devicetree-current/devicetree/merge (706b78f dtc: ensure #line directives don't consume data f
[PATCH v2] kernel/params.c: add/modify failure processing code when sysfs_create_file() fails.
When sysfs_create_file() fails, need consider about it. And process it
with BUG_ON(), because sysfs_create_file() can fail due to OOM (not at
boot) or name duplication (not here).
Also correct the error printing information when failure occurs.
Signed-off-by: Chen Gang
---
kernel/params.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/kernel/params.c b/kernel/params.c
index 440e65d..3d70f90 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -745,12 +745,14 @@ static struct module_kobject * __init
locate_module_kobject(const char *name)
err = kobject_init_and_add(>kobj, _ktype, NULL,
"%s", name);
#ifdef CONFIG_MODULES
- if (!err)
+ if (!err) {
err = sysfs_create_file(>kobj, _uevent.attr);
+ BUG_ON(err);
+ }
#endif
if (err) {
kobject_put(>kobj);
- pr_crit("Adding module '%s' to sysfs failed (%d), the
system may be unstable.\n",
+ pr_crit("Initializing and adding module '%s' failed
(%d), the system may be unstable.\n",
name, err);
return NULL;
}
@@ -845,6 +847,7 @@ static void __init version_sysfs_builtin(void)
mk = locate_module_kobject(vattr->module_name);
if (mk) {
err = sysfs_create_file(>kobj, >mattr.attr);
+ BUG_ON(err);
kobject_uevent(>kobj, KOBJ_ADD);
kobject_put(>kobj);
}
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/4] Radio device framework
On 7/8/2013 3:19 PM, akhil.go...@freescale.com wrote: From: Akhil Goyal RF signal path is integral part of any system that transmits/receives RF (radio frequency) signals. In these systems Data is processed/converted to IQ samples (digital representation a RF signal) and passed to a RFIC (RF PHY) which converts the digital RF signal (IQ samples) to analog and transmits over antenna. Typically The signal path consists of multiple components: Antenna controller<-> vector signal processors<-> RFIC<-> Antenna Each of these components have specific functionalities: 1. Antenna controller: Framing of digital IQ data into protocol specific frames. 2. vector signal processors: For conditioning of signal. 3. RFIC : converts digital IQ data to analog signal which is transmitted/received on/from Air. Also it is desirable to control the complete signal path, for example: bringing the complete signal path up/down etc. The radio device framework introduces a way to accommodate the RF signal paths. One signal path is represented as a RF device (rf0, rf1 etc), and it can contain multiple components which have their individual vendor specific drivers. The framework provides mechanism by which individual components can register with RF framework, and the framework will handle the binding of individual component devices to a RF device. RF device exports the control interfaces to user space, and this user space interface is independent of component (vendor specific) drivers. This patch set include 1. RF Interface: Independent of phy or antenna controller. 2. AIC driver: Antenna interface Controller(AIC) of Hetrogenous SOC's like BSC9131, BSC9132 4. Device tree bindings for AIC. 5. Device tree changes for BSC9131-AIC changes in v2: 1. incorporated comments for handling pointers in user space API structures. 2. Removed patches for AD9361 phy driver. It shall be sent once a proper driver is in place for AD9361 chip 3. Removed Device tree nodes/bindings for AD9361 4. Incorporated comments for proper handling of wait_events 5. Added Documentation for IOCTL APIs and the structures used. 6. Inserted paddings in user space structures. 7. Reorganized code for rfdev.c to remove forward declaration and broke the rf_ioctl() function to handle local structures correctly. 8. Corrected the error handling for mutex used. Hi Arnd/Greg, It has been 3-4 days for this patch set and there are no review comments on these patches. Please suggest a way forward for the patch set. I have incorporated all the review comments for v1. -Akhil -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] PCI,pciehp: avoid add a device already exist during pciehp_resume
>> We should do nothing in pciehp_resume, but we call >> pciehp_enable_slot(), so some uncomfortable messages show like above. >> In this case, we can improve it a little by add a guard >> if (!list_empty(bus->devices)). > > Great! > > I'm currently trying to bisect another problem, but hope to test this > patch (and the preceding patch it apparently needs) in a few days. > Please feel free to prod me if you think testing is needed but I'm > taking to long to report back. Hi Paul, Can you provide the lspci -vvv and lspci - info messages ? I want to confirm your hardware information which cause your resume error. You can get these messages in any kernel version, that's ok. When you suspend and resume the system, the wireless card is always present in pcie slot, right? Thanks! Yijing. > > > . > -- 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/
Re: [PATCH v2] pinctrl: msm: Add support for MSM TLMM pinmux
On 7/10/2013 3:05 PM, Linus Walleij wrote:
On Thu, Jun 27, 2013 at 11:08 PM, Hanumant Singh
wrote:
Add a new device tree enabled pinctrl driver for
Qualcomm MSM SoC's. This driver provides an extensible
framework to interface all MSM's that use a TLMM pinmux,
with the pinctrl subsytem.
This driver is split into two parts: the pinctrl interface
and the TLMM version specific implementation. The pinctrl
interface parses the device tree and registers with the pinctrl
subsytem. The TLMM version specific implementation supports
pin configuration/register programming for the different
pin types present on a given TLMM pinmux version.
Add support only for TLMM version 3 pinmux right now,
as well as, only two of the different pin types present on the
TLMM v3 pinmux.
Pintype 1: General purpose pins.
Pintype 2: SDC pins.
Signed-off-by: Hanumant Singh
This is looking better. (Sorry for late feedback...)
+Required Properties
+ - qcom,pin-type: identifies the pin type.
Define the possible types. If these are enumerable, don't pass a
generic string, use an hard identifier, e.g:
qcom,pin-type-gp;
qcom,pin-type-sdc;
will do
(...)
+Example 1: A pin-controller node with pin types
+
+ pinctrl@fd511 {
+ compatible = "qcom,msm-tlmm-v3";
+ reg = <0x1140 0x4000>;
+
+ /* General purpose pin type */
+ gp: gp {
+ qcom,pin-type = "gp";
Can we use qcom,pin-type-gp; ?
(...)
+Example 2: Spi pin entries within the pincontroller node
+ pinctrl@fd511000 {
+
+ ..
+ spi-bus {
+ /*
+* MOSI, MISO and CLK lines
+* all sharing same function and config
+* settings for each configuration node.
+*/
+ qcom,pins = < 0>, < 1>, < 3>;
+ qcom,pin-func = <1>;
+
+ /* Active configuration of bus pins */
+ spi-bus-active: spi-bus-active {
+ drive-strength = <3>; /* 8 MA */
No that shall be <8>.
If you need a translation table to translate this into your
magic constants, put a cross-reference table in your driver.
Will do
+ bias-disable; /* No PULL */
+ };
+ /* Sleep configuration of bus pins */
+ spi-bus-sleep: spi-bus-sleep {
+ drive-strength = <0>; /* 2 MA */
This shall be <2>;
(...)
+static int msm_tlmm_v3_sdc_cfg(uint pin_no, unsigned long *config,
+ void __iomem *reg_base,
+ bool write)
+{
+ unsigned int val, id, data;
+ u32 mask, shft;
+ void __iomem *cfg_reg;
+
+ cfg_reg = reg_base + sdc_regs[pin_no].offset;
+ id = pinconf_to_config_param(*config);
+ /* Get mask and shft values for this config type */
+ switch (id) {
+ case PIN_CONFIG_BIAS_DISABLE:
+ case PIN_CONFIG_BIAS_PULL_DOWN:
+ case PIN_CONFIG_BIAS_PULL_UP:
+ mask = sdc_regs[pin_no].pull_mask;
+ shft = sdc_regs[pin_no].pull_shft;
+ break;
+ case PIN_CONFIG_DRIVE_STRENGTH:
+ mask = sdc_regs[pin_no].drv_mask;
+ shft = sdc_regs[pin_no].drv_shft;
+ break;
+ default:
+ return -EINVAL;
+ };
+
+ val = readl_relaxed(cfg_reg);
+ if (write) {
+ data = pinconf_to_config_argument(*config);
This data needs to be treated per-config option and be more
optional. This makes it look like you want to supply a <1>
with any pull up or pull down configuration to nail it in when in
fact they do not take any argument, and if they do it should
be the number of Ohms in the resistor, not <1>.
OK I will supply the register magic values for each of the
pull config options.
Resistor value is not configurable, so I don't need that.
For drive strength you need a mA -> selector translation table
as mentioned.
I will implement the translation table.
+ val &= ~(mask << shft);
+ val |= (data << shft);
+ writel_relaxed(val, cfg_reg);
+ } else {
+ val >>= shft;
+ val &= mask;
+ *config = pinconf_to_config_packed(id, val);
Same thing applies in reverse here.
In that case, for get_config
1) For pull configs: I suppose I can return the default config value
instead of the register magic value?
2) For drive-strength I can return the reverse translation.
+static void msm_tlmm_v3_sdc_set_reg_base(void __iomem **ptype_base,
+ void __iomem *tlmm_base)
+{
+ *ptype_base = tlmm_base + 0x2044;
+}
0x2044 looks a bit magic, use a #define for this or
[PATCH v2 2/3] arm: atmel: at91sam9n12: add qt1070 support
add qt1070 support on at91sam9n12ek board
Signed-off-by: Bo Shen
---
Changes in v2:
- using micro for interrupt trigger mode
arch/arm/boot/dts/at91sam9n12ek.dts | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9n12ek.dts
b/arch/arm/boot/dts/at91sam9n12ek.dts
index d59b70c..7a95a28 100644
--- a/arch/arm/boot/dts/at91sam9n12ek.dts
+++ b/arch/arm/boot/dts/at91sam9n12ek.dts
@@ -40,6 +40,15 @@
i2c0: i2c@f801 {
status = "okay";
+
+ qt1070: keyboard@1b {
+ compatible = "qt1070";
+ reg = <0x1b>;
+ interrupt-parent = <>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_qt1070_irq>;
+ };
};
i2c1: i2c@f8014000 {
@@ -66,6 +75,13 @@
; /* PA7 gpio CD pin pull up
and deglitch */
};
};
+
+ qt1070 {
+ pinctrl_qt1070_irq: qt1070_irq {
+ atmel,pins =
+ ;
+ };
+ };
};
spi0: spi@f000 {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/3] arm: atmel: at91sam9n12: add pinctrl of TWI
add pinctrl of TWI for at91sam9n12 SoC
Signed-off-by: Bo Shen
---
Changes in v2:
- remove comments as use micro
arch/arm/boot/dts/at91sam9n12.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi
b/arch/arm/boot/dts/at91sam9n12.dtsi
index bb7f564..9fb7ffd 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91sam9n12.dtsi
@@ -291,6 +291,22 @@
};
};
+ i2c0 {
+ pinctrl_i2c0: i2c0-0 {
+ atmel,pins =
+ ;
+ };
+ };
+
+ i2c1 {
+ pinctrl_i2c1: i2c1-0 {
+ atmel,pins =
+ ;
+ };
+ };
+
tcb0 {
pinctrl_tcb0_tclk0: tcb0_tclk0-0 {
atmel,pins = ;
@@ -471,6 +487,8 @@
dma-names = "tx", "rx";
#address-cells = <1>;
#size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_i2c0>;
status = "disabled";
};
@@ -483,6 +501,8 @@
dma-names = "tx", "rx";
#address-cells = <1>;
#size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_i2c1>;
status = "disabled";
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/3] arm: atmel: at91sam9n12: correct pin number of gpio-key
correct pin number of gpio-key for at91sam9n12ek board
the pioB4 is connect to LED, the pioB3 use as gpio-key
Signed-off-by: Bo Shen
---
Changes in v2: None
arch/arm/boot/dts/at91sam9n12ek.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/at91sam9n12ek.dts
b/arch/arm/boot/dts/at91sam9n12ek.dts
index 7a95a28..3e86b05 100644
--- a/arch/arm/boot/dts/at91sam9n12ek.dts
+++ b/arch/arm/boot/dts/at91sam9n12ek.dts
@@ -137,7 +137,7 @@
enter {
label = "Enter";
- gpios = < 4 GPIO_ACTIVE_LOW>;
+ gpios = < 3 GPIO_ACTIVE_LOW>;
linux,code = <28>;
gpio-key,wakeup;
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/3] arm: atmel: at91sam9n12: add i2c pinctrl and qt1070 support
this patch is based on linux master branch, implementation as following: - add the i2c pinctrl which needed for using at91sam9n12 TWI - enable qt1070 - trival fix for the gpio-key pin number Changes in v2: - remove comments as use micro - using micro for interrupt trigger mode Bo Shen (3): arm: atmel: at91sam9n12: add pinctrl of TWI arm: atmel: at91sam9n12: add qt1070 support arm: atmel: at91sam9n12: correct pin number of gpio-key arch/arm/boot/dts/at91sam9n12.dtsi | 20 arch/arm/boot/dts/at91sam9n12ek.dts | 18 +- 2 files changed, 37 insertions(+), 1 deletion(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [RFC] [PATCH 1/2 v2] x86: introduce int3-based instruction patching
(2013/07/11 6:36), H. Peter Anvin wrote: > On 07/10/2013 02:31 PM, Jiri Kosina wrote: >> >> If any CPU instruction execution would collide with the patching, >> it'd be trapped by the int3 breakpoint and redirected to the provided >> "handler" (which would typically mean just skipping over the patched >> region, acting as "nop" has been there, in case we are doing nop -> jump >> and jump -> nop transitions). >> > > I'm wondering if it would be easier/more general to just return to the > instruction. The "more general" bit would allow this to be used for > other things, like alternatives, and perhaps eventually dynamic call > patching. > > Returning to the instruction will, in effect, be a busy-wait for the > faulted CPU until the patch is complete; more or less what stop_machine > would do, but only for a CPU which actually strays into the affected region. Sounds a good idea :) It may minimize the interface and the implementation will be self-contained. Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virtio tools: add .gitignore
"Michael S. Tsirkin" writes: > On Wed, Jul 10, 2013 at 04:27:00PM +0530, Ramkumar Ramachandra wrote: >> Signed-off-by: Ramkumar Ramachandra >> --- > > Why not. > > Acked-by: Michael S. Tsirkin Applied. Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: rebase of lblnet tree
On Thursday, July 11, 2013 10:01:17 AM Stephen Rothwell wrote: > Hi Paul, Hi Stephen, I know you already emailed me privately about my @hp.com email address, but for the sake of everyone else on the list, my @hp.com address no longer works, it hasn't for some time now. Please check my entry in the MAINTAINERS file for my correct contact information (this email address). That said, I established this current email address to avoid problems when changing employers so hopefully this confusion won't happen again in the future. > Why have you just rebased the lblnet tree > (git://git.infradead.org/users/pcmoore/lblnet-2.6_next#master)? You have > just invalidated your testing and made it likely that Linus will blast > you if you ask him to pull your tree. Your whole tree was already based > after v3.10 (i.e. released or rebased after the merge window opened), so > why move it again? [NOTE: I get the impression that the above is a "form letter" email, but just in case ...] When I added two additional patches to the labeled networking tree today, I rebased the tree to verify that there were no merge conflicts and that everything worked as expected on a booted system. I also occasionally rebase the tree when there are pending patches and I'm not adding anything new for the same reason: I believe that testing changes against the latest upstream code is a Good Thing. If there is a patch with my sign-off in a tree I am responsible for, I do my best to make sure it builds, boots, and passes some basic sanity tests. I can't say I'm perfect, but I do try to not push crap upwards. Also, just to be clear, the labeled networking tree usually goes into Linus' tree via the netdev or security tree (and then it hits the security tree usually via the SELinux tree). I can't ever think of a time when I asked Linus' to pull a tree of mine directly. If this approach doesn't work for you, please let me know and preferably suggest an alternative. -Paul -- paul moore www.paul-moore.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92
On Thu, 11 Jul 2013 12:26:34 +1000 Dave Chinner wrote: > > Just for reference. wait_on_page_writeback is issued only for memcg > > reclaim because there is no other throttling mechanism to prevent from > > too many dirty pages on the list, thus pre-mature OOM killer. See > > e62e384e9d (memcg: prevent OOM with too many dirty pages) for more > > details. The original patch relied on may_enter_fs but that check > > disappeared by later changes by c3b94f44fc (memcg: further prevent OOM > > with too many dirty pages). > > Aye. That's the exact code I was looking at yesterday and wondering > "how the hell is waiting on page writeback valid in GFP_NOFS > context?". It seems that memcg reclaim is intentionally ignoring > GFP_NOFS to avoid OOM issues. That's a memcg implementation problem, > not a filesystem or LRU infrastructure problem Yup, c3b94f44fc shouldn't have done that. Throttling by waiting on a specific page is indeed prone to deadlocks and has a number of efficiency problems as well: if 1,000,000 pages came clean while you're waiting for *this* page to come clean, you're left looking pretty stupid. Hence congestion_wait(), which perhaps can save us here. I'm not sure how the wait_on_page_writeback() got back in there - I must have been asleep at the time. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] extcon: palmas: Option to disable ID/VBUS detection based on platform
On Thursday 11 July 2013 08:12 AM, Chanwoo Choi wrote:
Hi Laxman,
static int palmas_usb_probe(struct platform_device *pdev)
@@ -137,20 +140,26 @@ static int palmas_usb_probe(struct platform_device *pdev)
struct palmas_usb *palmas_usb;
int status;
- if (node && !pdata) {
- pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
-
- if (!pdata)
- return -ENOMEM;
+ palmas_usb = devm_kzalloc(>dev, sizeof(*palmas_usb), GFP_KERNEL);
+ if (!palmas_usb)
+ return -ENOMEM;
- pdata->wakeup = of_property_read_bool(node, "ti,wakeup");
+ if (node && !pdata) {
+ palmas_usb->wakeup = of_property_read_bool(node, "ti,wakeup");
+ palmas_usb->enable_id_detection = of_property_read_bool(node,
+ "ti,enable-id-detection");
+ palmas_usb->enable_vbus_detection = of_property_read_bool(node,
+ "ti,enable-vbus-detection");
+ } else if (pdata) {
+ palmas_usb->wakeup = pdata->wakeup;
+ palmas_usb->enable_id_detection = true;
+ palmas_usb->enable_vbus_detection = true;
} else if (!pdata) {
- return -EINVAL;
+ palmas_usb->wakeup = true;
+ palmas_usb->enable_id_detection = true;
+ palmas_usb->enable_vbus_detection = true;
}
I think we could modify it as following patch to remove duplicate line.
If you agree about below modification, I will apply your patch with following
patch.
I am fine with this and this looks simple and straight.
I have seen some patches/discussion from TI to remove the platform data
support at all and hence removing from here in future will be very simple.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kernel/params.c: print failure information instead of 'KOBJ_ADD' to user space, when sysfs_create_file() fails.
On 07/11/2013 09:53 AM, Rusty Russell wrote: > Chen Gang F T writes: >> > On 07/09/2013 04:07 PM, Rusty Russell wrote: >>> >> Chen Gang writes: >>> When sysfs_create_file() fails, recommend to print the related failure >>> information. And it is useless to still 'KOBJ_ADD' to user space. >>> >>> Signed-off-by: Chen Gang >>> >> >>> >> sysfs_create_file() should not fail during boot, should it? >>> >> >> > >> > Hmm..., please reference locate_module_kobject() in "kernel/params.c", >> > which is an '__init' function, and also call sysfs_create_file(), it >> > processes the related error. >> > >> > So I recommend to get the check too in version_sysfs_builtin(). > It still can't fail. sysfs_create_file() can fail due to OOM (not at > boot) or name duplication (not here). > > You can BUG_ON() if you want. > OK, thanks, I will send patch v2 for it. > And feel free to fix locate_module_kobject() in a separate patch. OK, thanks, I will send related patch for it. :-) Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] dma: mmp_pdma: support for getting residual bytes
2013/7/5 Vinod Koul :
> On Tue, Jun 18, 2013 at 04:41:20PM +0800, Xiang Wang wrote:
>> From: Xiang Wang
>>
>> In some of our drivers (e.g. UART) we may stop a running DMA
>> before it finishes. So we need APIs to know how many bytes
>> have been transferred.
>>
>> Signed-off-by: Xiang Wang
>> ---
>> drivers/dma/mmp_pdma.c | 88
>> +++
>> 1 files changed, 80 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/dma/mmp_pdma.c b/drivers/dma/mmp_pdma.c
>> index c26699f..57cd047 100644
>> --- a/drivers/dma/mmp_pdma.c
>> +++ b/drivers/dma/mmp_pdma.c
>> @@ -104,7 +104,8 @@ struct mmp_pdma_chan {
>> spinlock_t desc_lock; /* Descriptor list lock */
>> struct list_head chain_pending; /* Link descriptors queue for pending
>> */
>> struct list_head chain_running; /* Link descriptors queue for running
>> */
>> - bool idle; /* channel statue machine */
>> + enum dma_status status; /* channel status machine */
>> + u32 bytes_residue;
>>
>> struct dma_pool *desc_pool; /* Descriptors pool */
>> };
>> @@ -270,7 +271,7 @@ static void start_pending_queue(struct mmp_pdma_chan
>> *chan)
>> struct mmp_pdma_desc_sw *desc;
>>
>> /* still in running, irq will start the pending list */
>> - if (!chan->idle) {
>> + if (chan->status == DMA_IN_PROGRESS) {
>> dev_dbg(chan->dev, "DMA controller still busy\n");
>> return;
>> }
>> @@ -307,7 +308,64 @@ static void start_pending_queue(struct mmp_pdma_chan
>> *chan)
>>*/
>> set_desc(chan->phy, desc->async_tx.phys);
>> enable_chan(chan->phy);
>> - chan->idle = false;
>> + chan->status = DMA_IN_PROGRESS;
>> + chan->bytes_residue = 0;
>> +}
>> +
>> +/*
>> + * Get the number of pending bytes. Should be called with desc_lock held
>> + * because we are accessing desc list.
>> + */
>> +static u32 mmp_pdma_get_bytes_residue(struct mmp_pdma_chan *chan)
>> +{
>> + u32 reg, orig_pos, cur_pos, ddadr, residue = 0;
>> + bool running_desc_found = false;
>> + struct mmp_pdma_desc_sw *desc_sw;
>> +
>> + /*
>> + * When a phy channel is unavailable, maybe it has been freed, return
>> + * last stored value for safe.
>> + */
>> + if (!chan->phy)
>> + return chan->bytes_residue;
>> +
>> + reg = (chan->phy->idx << 4) + DDADR;
>> + ddadr = readl_relaxed(chan->phy->base + reg);
>> +
>> + /* iterate over all descriptors to sum up the number of pending bytes
>> */
> and why?
>
> Residue does not mean sum of all pending bytes across all descriptors
> submitted
> You need to find the residue of current descriptor only and return
>
Here are my thoughts:
We tell dma engine to transmit x bytes for us and it creates n
descriptors to transmit which is transparent to us.
So when we want to find out how many bytes are left, dma engine should
sum up all pending bytes across all descriptors.
What's your opinion?
>> + list_for_each_entry(desc_sw, >chain_running, node) {
>> + /* for the case of a running descriptor */
>> + if (desc_sw->desc.ddadr == ddadr && !running_desc_found) {
>> + switch (chan->dir) {
>> + case DMA_DEV_TO_MEM:
>> + case DMA_MEM_TO_MEM:
>> + reg = (chan->phy->idx << 4) + DTADR;
>> + cur_pos = readl_relaxed(chan->phy->base + reg);
>> + orig_pos = desc_sw->desc.dtadr;
>> + break;
>> +
>> + case DMA_MEM_TO_DEV:
>> + reg = (chan->phy->idx << 4) + DSADR;
>> + cur_pos = readl_relaxed(chan->phy->base + reg);
>> + orig_pos = desc_sw->desc.dsadr;
>> + break;
>> +
>> + default:
>> + cur_pos = 0;
>> + orig_pos = 0;
> This makes no sense...
What do you recommend for the default case? Just return 0?
>
>> + }
>> + residue = (u32)(desc_sw->desc.dcmd & DCMD_LENGTH)
>> + + orig_pos - cur_pos;
>> + running_desc_found = true;
>> + continue;
>> + }
>> +
>> + /* for the case of following un-started descriptors*/
>> + if (running_desc_found)
>> + residue += (u32)(desc_sw->desc.dcmd & DCMD_LENGTH);
>> + }
>> +
>> + return residue;
>> }
>>
>>
>> @@ -381,7 +439,7 @@ static int mmp_pdma_alloc_chan_resources(struct dma_chan
>> *dchan)
>> chan->phy->vchan = NULL;
>> chan->phy = NULL;
>> }
>> - chan->idle = true;
>> + chan->status = DMA_SUCCESS;
>> chan->dev_addr = 0;
>> return 1;
>> }
>> @@ -409,7 +467,7 @@ static void
Re: [PATCH 1/3] sh_eth: SH_ETH should depend on HAS_DMA
From: Geert Uytterhoeven Date: Wed, 10 Jul 2013 23:03:34 +0200 > If NO_DMA=y: > > drivers/built-in.o: In function `sh_eth_free_dma_buffer': > drivers/net/ethernet/renesas/sh_eth.c:1103: undefined reference to > `dma_free_coherent' > drivers/net/ethernet/renesas/sh_eth.c:1110: undefined reference to > `dma_free_coherent' > drivers/built-in.o: In function `sh_eth_ring_init': > drivers/net/ethernet/renesas/sh_eth.c:1065: undefined reference to > `dma_alloc_coherent' > drivers/net/ethernet/renesas/sh_eth.c:1086: undefined reference to > `dma_free_coherent' > drivers/built-in.o: In function `sh_eth_ring_format': > drivers/net/ethernet/renesas/sh_eth.c:988: undefined reference to > `dma_map_single' > drivers/built-in.o: In function `sh_eth_txfree': > drivers/net/ethernet/renesas/sh_eth.c:1220: undefined reference to > `dma_unmap_single' > drivers/built-in.o: In function `sh_eth_rx': > drivers/net/ethernet/renesas/sh_eth.c:1323: undefined reference to > `dma_map_single' > drivers/built-in.o: In function `sh_eth_start_xmit': > drivers/net/ethernet/renesas/sh_eth.c:1954: undefined reference to > `dma_map_single' > > Signed-off-by: Geert Uytterhoeven Applied, thanks Geert. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LOCKDEP] cpufreq: possible circular locking dependency detected
Hi, Sergey
On 07/11/2013 07:13 AM, Sergey Senozhatsky wrote:
[snip]
>
>
> Please kindly review the following patch.
>
>
>
> Remove cpu device only upon succesful cpu down on CPU_POST_DEAD event,
> so we can kill off CPU_DOWN_FAILED case and eliminate potential extra
> remove/add path:
>
> hotplug lock
> CPU_DOWN_PREPARE: __cpufreq_remove_dev
> CPU_DOWN_FAILED: cpufreq_add_dev
> hotplug unlock
>
> Since cpu still present on CPU_DEAD event, cpu stats table should be
> kept longer and removed later on CPU_POST_DEAD as well.
>
> Because CPU_POST_DEAD action performed with hotplug lock released, CPU_DOWN
> might block existing gov_queue_work() user (blocked on get_online_cpus())
> and unblock it with one of policy->cpus offlined, thus cpu_is_offline()
> check is performed in __gov_queue_work().
>
> Besides, existing gov_queue_work() hotplug guard extended to protect all
> __gov_queue_work() calls: for both all_cpus and !all_cpus cases.
>
> CPUFREQ_GOV_START performs direct __gov_queue_work() call because hotplug
> lock already held there, opposing to previous gov_queue_work() and nested
> get/put_online_cpus().
Nice to know you have some idea on solving the issue ;-)
I'm not sure whether I catch the idea, but seems like you are trying
to re-organize the timing of add/remove device.
I'm sure that we have more than one way to solve the issues, but what
we need is the cure of root...
As Srivatsa discovered, the root issue may be:
gov_cancel_work() failed to stop all the work after it's return.
And Viresh also confirmed that this is not by-designed.
Which means gov_queue_work() invoked by od_dbs_timer() is supposed to
never happen after CPUFREQ_GOV_STOP notify, the whole policy should
stop working at that time.
But it failed to, and the work concurrent with cpu dying caused the
first problem.
Thus I think we should focus on this and suggested below fix, I'd like
to know your opinions :)
Regards,
Michael Wang
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index dc9b72e..a64b544 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -178,13 +178,14 @@ void gov_queue_work(struct dbs_data *dbs_data, struct
cpufreq_policy *policy,
{
int i;
+ if (dbs_data->queue_stop)
+ return;
+
if (!all_cpus) {
__gov_queue_work(smp_processor_id(), dbs_data, delay);
} else {
- get_online_cpus();
for_each_cpu(i, policy->cpus)
__gov_queue_work(i, dbs_data, delay);
- put_online_cpus();
}
}
EXPORT_SYMBOL_GPL(gov_queue_work);
@@ -193,12 +194,27 @@ static inline void gov_cancel_work(struct dbs_data
*dbs_data,
struct cpufreq_policy *policy)
{
struct cpu_dbs_common_info *cdbs;
- int i;
+ int i, round = 2;
+ dbs_data->queue_stop = 1;
+redo:
+ round--;
for_each_cpu(i, policy->cpus) {
cdbs = dbs_data->cdata->get_cpu_cdbs(i);
cancel_delayed_work_sync(>work);
}
+
+ /*
+* Since there is no lock to prvent re-queue the
+* cancelled work, some early cancelled work might
+* have been queued again by later cancelled work.
+*
+* Flush the work again with dbs_data->queue_stop
+* enabled, this time there will be no survivors.
+*/
+ if (round)
+ goto redo;
+ dbs_data->queue_stop = 0;
}
/* Will return if we need to evaluate cpu load again or not */
diff --git a/drivers/cpufreq/cpufreq_governor.h
b/drivers/cpufreq/cpufreq_governor.h
index e16a961..9116135 100644
--- a/drivers/cpufreq/cpufreq_governor.h
+++ b/drivers/cpufreq/cpufreq_governor.h
@@ -213,6 +213,7 @@ struct dbs_data {
unsigned int min_sampling_rate;
int usage_count;
void *tuners;
+ int queue_stop;
/* dbs_mutex protects dbs_enable in governor start/stop */
struct mutex mutex;
>
> Signed-off-by: Sergey Senozhatsky
>
> ---
>
> drivers/cpufreq/cpufreq.c | 5 +
> drivers/cpufreq/cpufreq_governor.c | 17 +++--
> drivers/cpufreq/cpufreq_stats.c| 2 +-
> 3 files changed, 13 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 6a015ad..f8aacf1 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1943,13 +1943,10 @@ static int __cpuinit cpufreq_cpu_callback(struct
> notifier_block *nfb,
> case CPU_ONLINE:
> cpufreq_add_dev(dev, NULL);
> break;
> - case CPU_DOWN_PREPARE:
> + case CPU_POST_DEAD:
> case CPU_UP_CANCELED_FROZEN:
> __cpufreq_remove_dev(dev, NULL);
> break;
> - case CPU_DOWN_FAILED:
> -
Re: [PATCH V3] extcon: palmas: Option to disable ID/VBUS detection based on platform
Hi Laxman,
> static int palmas_usb_probe(struct platform_device *pdev)
> @@ -137,20 +140,26 @@ static int palmas_usb_probe(struct platform_device
> *pdev)
> struct palmas_usb *palmas_usb;
> int status;
>
> - if (node && !pdata) {
> - pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
> -
> - if (!pdata)
> - return -ENOMEM;
> + palmas_usb = devm_kzalloc(>dev, sizeof(*palmas_usb), GFP_KERNEL);
> + if (!palmas_usb)
> + return -ENOMEM;
>
> - pdata->wakeup = of_property_read_bool(node, "ti,wakeup");
> + if (node && !pdata) {
> + palmas_usb->wakeup = of_property_read_bool(node, "ti,wakeup");
> + palmas_usb->enable_id_detection = of_property_read_bool(node,
> + "ti,enable-id-detection");
> + palmas_usb->enable_vbus_detection = of_property_read_bool(node,
> + "ti,enable-vbus-detection");
> + } else if (pdata) {
> + palmas_usb->wakeup = pdata->wakeup;
> + palmas_usb->enable_id_detection = true;
> + palmas_usb->enable_vbus_detection = true;
> } else if (!pdata) {
> - return -EINVAL;
> + palmas_usb->wakeup = true;
> + palmas_usb->enable_id_detection = true;
> + palmas_usb->enable_vbus_detection = true;
> }
I think we could modify it as following patch to remove duplicate line.
If you agree about below modification, I will apply your patch with following
patch.
index 5c218d2..56909cc 100644
--- a/drivers/extcon/extcon-palmas.c
+++ b/drivers/extcon/extcon-palmas.c
@@ -150,16 +150,14 @@ static int palmas_usb_probe(struct platform_device *pdev)
"ti,enable-id-detection");
palmas_usb->enable_vbus_detection = of_property_read_bool(node,
"ti,enable-vbus-detection");
- } else if (pdata) {
- palmas_usb->wakeup = pdata->wakeup;
- palmas_usb->enable_id_detection = true;
- palmas_usb->enable_vbus_detection = true;
- } else if (!pdata) {
+ } else {
palmas_usb->wakeup = true;
palmas_usb->enable_id_detection = true;
palmas_usb->enable_vbus_detection = true;
- }
+ if (pdata)
+ palmas_usb->wakeup = pdata->wakeup;
+ }
palmas->usb = palmas_usb;
palmas_usb->palmas = palmas;
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kernel/params.c: print failure information instead of 'KOBJ_ADD' to user space, when sysfs_create_file() fails.
Chen Gang F T writes: > On 07/09/2013 04:07 PM, Rusty Russell wrote: >> Chen Gang writes: >>> When sysfs_create_file() fails, recommend to print the related failure >>> information. And it is useless to still 'KOBJ_ADD' to user space. >>> >>> Signed-off-by: Chen Gang >> >> sysfs_create_file() should not fail during boot, should it? >> > > Hmm..., please reference locate_module_kobject() in "kernel/params.c", > which is an '__init' function, and also call sysfs_create_file(), it > processes the related error. > > So I recommend to get the check too in version_sysfs_builtin(). It still can't fail. sysfs_create_file() can fail due to OOM (not at boot) or name duplication (not here). You can BUG_ON() if you want. And feel free to fix locate_module_kobject() in a separate patch. Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/2] PCI: introduce PCIe Device Serial NUmber Capability support
>> + */ >> +void pci_get_dsn(struct pci_dev *dev, u64 *sn) > > How about: > > u64 pci_device_serial_number(struct pci_dev *dev) > > "get" suggests reference counting, which isn't happening here. And > why pass a pointer to a return value when we can just as easily return > it directly? Yes, u64 pci_device_serial_number(struct pci_dev *dev) is better, thanks! > id pci_init_capabilities(struct pci_dev *dev) >> /* Power Management */ >> pci_pm_init(dev); >> >> + /* Device Serial Number */ >> + pci_dsn_init(dev); > > dev->sn = pci_serial_number(dev); > > Obvious, no comment or wrapper function needed. OK, will remove the unnecessary comment. > >> + >> /* Vital Product Data */ >> pci_vpd_pci22_init(dev); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: 32 Bit Kernel kexec hangs on P2020
On 07/10/2013 06:00 PM, Stefani Seibold wrote: Am Mittwoch, den 10.07.2013, 16:48 +0800 schrieb tiejun.chen: On 07/10/2013 04:39 PM, Stefani Seibold wrote: Hi, i have tried to kexec a 32 bit kernel on a Freescale P2020 dual core CPU (e500v2, revison 5.1 - pvr 8021 1051), but Kexec will hang after the "Bye!". The host and the kexec kernel are the same, based on the current kernel version 3.10. I have tried it with kexec-tools 2.0.4.git released 30 June 2013. Invoking kexec with kexec --command-line "1 maxcpus=1 noirqdistrib reset_devices $(cat /proc/cmdline)" -t elf-ppc --dtb=rs2020.dtb \ --reuse-node="/cpus/PowerPC,P2020@0/timebase-frequency" \ --reuse-node="/cpus/PowerPC,P2020@0/bus-frequency" \ --reuse-node="/cpus/PowerPC,P2020@0/clock-frequency" \ --reuse-node="/cpus/PowerPC,P2020@0/next-level-cache" \ --reuse-node="/cpus/PowerPC,P2020@1/timebase-frequency" \ --reuse-node="/cpus/PowerPC,P2020@1/bus-frequency" \ --reuse-node="/cpus/PowerPC,P2020@1/clock-frequency" \ --reuse-node="/cpus/PowerPC,P2020@1/next-level-cache" \ --reuse-node="/cpus/PowerPC,P2020@1/cpu-release-addr" \ --reuse-node="/cpus/PowerPC,P2020@1/enable-method" \ --reuse-node="/soc@ffe0/bus-frequency" \ --reuse-node="/soc@ffe0/serial@4500/clock-frequency" \ --reuse-node="/soc@ffe0/ethernet@24000/local-mac-address" \ -d -l -x vmlinux kexec -e Could you try again with one simple command like, kexec -l vmlinux --append="`cat /proc/cmdline`";kexec -e Great, this works. I did more test and the issue for the fail is the passing of the device tree. But the device tree is exact the same as the previous used one. Is passing a new device tree not allowed? No, I think this is not interdicted. I suspect you probably don't pass a proper dtb, so you can take a further test to figure out this problem. For example, in the u-boot prompt, you can use the fdt command to get last dtb after that board setup from u-boot, then pass that directly to try. Tiejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] PCI,pciehp: avoid add a device already exist during pciehp_resume
>> If the slot support surprise hot remove, this action maybe safe. right? > > If there's no device, config space accesses performed by .remove() > will fail (reads will return -1 data or error; writes will be > dropped). MMIO or I/O port accesses may fail with machine checks or > similar bad things. But I don't see a way around that except by > fixing drivers as we encounter issues like that. > > Since you're not changing anything here, I don't think we should worry > about it for now. OK. > remove the old card firstly, then add the new card. >>> >>> With your patch, I think we'll call the old driver's .remove() method >>> on the new device. This seems bad; see below. >> >> Ah, this is issue. >> What about power off slot first, then call the old driver's remove() method >> will not touch the new physical device. After the old driver's remove() >> cleanup, >> we call pciehp_enable_slot() to power on and enable the new device. > > Turning off power to the slot seems like a reasonable approach. Then > we can run the old .remove() method in basically the same way we would > in case 2. Hmmm, I will follow this method to rework this patch in next version. > >>> With your patch, if we remove and reinsert the same device while >>> suspended, we do nothing because the DSN didn't change. Previously we >>> called pciehp_enable_slot(). I don't know if we need to do anything >>> here or not. >> >> Mainly to avoid the redundant device add, the same like the changes for case >> 4 > > I don't know whether it's redundant or not. Obviously if we remove > and reinsert a device, we lose *all* state that was in the device. If > we lose everything even if the card stayed inserted the whole time we > were suspended, we must already deal with that and the "add" would be > redundant. But if the state of the card is different if it got pulled > and reinserted, the "add" would be necessary. This is a key issue, sorry, I'm not familiar with PM :( In my opinion, the device driver .suspend() method will be called regardless of system enter in suspend to RAM(S3) or suspend to Disk(S4). Driver will save the pci/pcie/pci-x state in .suspend() method. So once device driver .resume() method be called, the pci/pcie/pci-x state willl be restored. Because suspend to disk will power off whole system, so I thought if the device was removed and inserted same device(DSN) again, maybe .resume will enable this device ok regardless of the pci config space state has been changed. If I have any thing above understanding wrong, please correct me, thanks! > 4. slot is non empty before suspend, no action during suspend. We should do nothing in pciehp_resume, but we call pciehp_enable_slot(), so some uncomfortable messages show like above. In this case, we can improve it a little by add a guard if (!list_empty(bus->devices)). >>> >>> This is the common case. Previously we called pciehp_enable_slot(), >>> and with your patch we do nothing. I think that seems sensible, but >>> this part should be split into a separate patch. That way we can keep >>> the benefit of this change even if we trip over something with the >>> other changes. >> >> OK, I will split this changes into a new patch. > > Actually, without your DSN changes, I don't think we can distinguish > this from case 3. So I doubt it really could be split out. I will try, but I think this is not a big deal :) > > . > -- 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/
Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92
On Wed, Jul 10, 2013 at 10:06:05AM +0200, Michal Hocko wrote: > On Wed 10-07-13 12:31:39, Dave Chinner wrote: > [...] > > > 20761 [] xlog_grant_head_wait+0xdd/0x1a0 [xfs] > > > [] xlog_grant_head_check+0xc6/0xe0 [xfs] > > > [] xfs_log_reserve+0xff/0x240 [xfs] > > > [] xfs_trans_reserve+0x234/0x240 [xfs] > > > [] xfs_create+0x1a9/0x5c0 [xfs] > > > [] xfs_vn_mknod+0x8a/0x1a0 [xfs] > > > [] xfs_vn_create+0xe/0x10 [xfs] > > > [] vfs_create+0xad/0xd0 > > > [] lookup_open+0x1b8/0x1d0 > > > [] do_last+0x2de/0x780 > > > [] path_openat+0xda/0x400 > > > [] do_filp_open+0x43/0xa0 > > > [] do_sys_open+0x160/0x1e0 > > > [] sys_open+0x1c/0x20 > > > [] system_call_fastpath+0x16/0x1b > > > [] 0x > > > > That's an XFS log space issue, indicating that it has run out of > > space in IO the log and it is waiting for more to come free. That > > requires IO completion to occur. > > > > > [276962.652076] INFO: task xfs-data/sda9:930 blocked for more than 480 > > > seconds. > > > [276962.652087] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > > > disables this message. > > > [276962.652093] xfs-data/sda9 D 88001ffb9cc8 0 930 2 > > > 0x > > > > Oh, that's why. This is the IO completion worker... > > But that task doesn't seem to be stuck anymore (at least lockup watchdog > doesn't report it anymore and I have already rebooted to test with ext3 > :/). I am sorry if the these lockups logs were more confusing than > helpful, but they happened _long_ time ago and the system obviously > recovered from them. I am pasting only the traces for processes in D > state here again for reference. Right, there are various triggers that can get XFS out of the situation - it takes something to kick the log or metadata writeback and that can make space in the log free up and hence things get moving again. The problem will be that once in this low memory state everything in the filesystem will back up on slow memory allocation and it might take minutes to clear the backlog of IO completions > 20757 [] xlog_grant_head_wait+0xdd/0x1a0 [xfs] > [] xlog_grant_head_check+0xc6/0xe0 [xfs] > [] xfs_log_reserve+0xff/0x240 [xfs] > [] xfs_trans_reserve+0x234/0x240 [xfs] That is the stack of a process waiting for log space to come available. > We are wating for page under writeback but neither of the 2 paths starts > in xfs code. So I do not think waiting for PageWriteback causes a > deadlock here. The problem is this: the page that we are waiting for IO on is in the IO completion queue, but the IO compeltion requires memory allocation to complete the transaction. That memory allocation is causing memcg reclaim, which then waits for IO completion on another page, which may or may not end up in the same IO completion queue. The CMWQ can continue to process new Io completions - up to a point - so slow progress will be made. In the worst case, it can deadlock. GFP_NOFS allocation is the mechanism by which filesystems are supposed to be able to avoid this recursive deadlock... > [...] > > ... is running IO completion work and trying to commit a transaction > > that is blocked in memory allocation which is waiting for IO > > completion. It's disappeared up it's own fundamental orifice. > > > > Ok, this has absolutely nothing to do with the LRU changes - this is > > a pre-existing XFS/mm interaction problem from around 3.2. The > > question is now this: how the hell do I get memory allocation to not > > block waiting on IO completion here? This is already being done in > > GFP_NOFS allocation context here > > Just for reference. wait_on_page_writeback is issued only for memcg > reclaim because there is no other throttling mechanism to prevent from > too many dirty pages on the list, thus pre-mature OOM killer. See > e62e384e9d (memcg: prevent OOM with too many dirty pages) for more > details. The original patch relied on may_enter_fs but that check > disappeared by later changes by c3b94f44fc (memcg: further prevent OOM > with too many dirty pages). Aye. That's the exact code I was looking at yesterday and wondering "how the hell is waiting on page writeback valid in GFP_NOFS context?". It seems that memcg reclaim is intentionally ignoring GFP_NOFS to avoid OOM issues. That's a memcg implementation problem, not a filesystem or LRU infrastructure problem Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH 0/2] x86: make jump labels use int3-based breakpoint instead of stop_machine()
(2013/07/11 5:25), Jiri Kosina wrote:
> Hi,
>
> this is a resurrection of a few years old idea to have jump labels use
> synchronization based on int3 breakpoint rather than relying on
> stop_machine() with all the consequences.
>
> ftrace has been doing exactly this kind of patching for year since
> 08d636b6 ("ftrace/x86: Have arch x86_64 use breakpoints instead of stop
> machine").
>
> This patchset first introduces generic text_poke_bp() that provides means
> to perform this method of patching in parallel to text_poke_smp(), and
> then converts x86 jump label code to use it.
>
> If this is merged, I'll do a followup patch converting ftrace to use this
> infrastructure as well, as it's doing the same thing in principle already.
Hi Jiri,
Thank you for taking over it! :)
If yours is merged, I can move optprobe on that too ;)
Thank you again!!
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/12] drivers/mtd/nand/gpmi-nand: don't use devm_pinctrl_get_select_default() in probe
于 2013年07月11日 10:14, Huang Shijie 写道: > 于 2013年07月10日 23:57, Wolfram Sang 写道: >> Since commit ab78029 (drivers/pinctrl: grab default handles from device >> core), >> we can rely on device core for setting the default pins. Compile tested only. >> >> Acked-by: Linus Walleij (personally at LCE13) >> Signed-off-by: Wolfram Sang >> --- > i remember Fabio had already sent a similar patch about this issue. > sorry. Fabio just fix it in the gpmi driver, maybe he did not fix the atmel-nand. thanks Huang Shijie -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.10.0-rc7: rtc_cmos.o: No linking because of missing CONFIG_HPET [PATCH]
On Tue, Jul 02, 2013 at 07:49:47PM +, Bjarni Ingi Gislason wrote:
> On Mon, Jul 01, 2013 at 11:40:08AM +0200, Clemens Ladisch wrote:
> > > On 29.6.2013 22:42, Bjarni Ingi Gislason wrote:
> > >> The file "drivers/rtc/rtc_cmos.c" needs CONFIG_HPET to get linked.
> > >>
> > >> rtc-cmos.c:(.text+0x16f214): undefined reference to `hpet_rtc_interrupt'
> >
> > CONFIG_HPET enables drivers/char/hpet.c and nothing else; it does not
> > affect the HPET RTC emulation.
> >
> > You are probably searching for CONFIG_HPET_EMULATE_RTC.
> >
>
> Sorry. I selected (configured) "HPET_TIMER" to fix the compilation
> and linking (which automatically includes HPET_EMULATE_RTC).
>
This patch fixes the linking error and comments out one unused
fuction.
--- rtc-cmos.c-original 2013-06-22 19:47:31.0 +
+++ rtc-cmos.c 2013-07-10 20:42:32.0 +
@@ -121,11 +121,12 @@ static inline int hpet_set_periodic_freq
return 0;
}
-static inline int hpet_rtc_dropped_irq(void)
-{
- return 0;
-}
-
+/* Not used in this file, but mentioned in include-file
+ * static inline int hpet_rtc_dropped_irq(void)
+ * {
+ * return 0;
+ * }
+ */
static inline int hpet_rtc_timer_init(void)
{
return 0;
@@ -700,6 +701,11 @@ cmos_do_probe(struct device *dev, struct
if (is_valid_irq(rtc_irq)) {
irq_handler_t rtc_cmos_int_handler;
+/* if CONFIG_HPET_EMULATE_RTC is false, "is_hpet_enabled()" is defined to
+ * return zero (false).
+ */
+
+#ifdef CONFIG_HPET_EMULATE_RTC
if (is_hpet_enabled()) {
int err;
@@ -711,6 +717,7 @@ cmos_do_probe(struct device *dev, struct
goto cleanup1;
}
} else
+#endif /* CONFIG_HPET_EMULATE_RTC */
rtc_cmos_int_handler = cmos_interrupt;
retval = request_irq(rtc_irq, rtc_cmos_int_handler,
--
Bjarni I. Gislason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [GIT] kbuild changes for v3.11-rc1
On Wed, Jul 10, 2013 at 6:37 AM, Michal Marek wrote: > > please pull the kbuild bits for v3.11-rc1: THIS IS SOME HORRIBLY BROKEN CRAP. "make install" and "make modules_install" ABSOLUTELY MUST NOT MODIFY THE SOURCE TREE. Dammit, this has happened before, and it was broken then, and it is broken now. If they do, they are *F*CKING*BROKEN*. They are really really badly broken, since we do *not* want root to write to the source tree. You should build the tree as a normal user, and install as root, and dammit, if there are any root-owned files in the source tree after that "make install", then the build system is broken. You need to start being more careful. And I would seriously suggest you start doing some explicit testing for this. You can do things like "find . -user root", and if that shows a single file in the kernel tree after a "make [modules_]install", then there's a problem. Commit d2aae8477cd00325bb7c7c7e95be488088900c48 is broken. It causes root to re-write "include/config/kernel.release". There is no excuse for this. That commit is shit. There's no way in hell that "make modules_install" should ever rebuild anything, so adding that kind of dependency is fundamentally wrong and broken. And that totally crap commit is even marked for stable. I hate hate hate when this kind of crap happens. In this case I noticed it because the git commit abbreviation rules are different for root and for a normal user on my machine, and so running that version-generation script as root actually GIVES THE WRONG ANSWER - it gives a different version than the one the kernel was actually built with. So no. We do *not* start adding random dependencies to the install targets. Because they damn well should not be building anything. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/12] drivers/mtd/nand/gpmi-nand: don't use devm_pinctrl_get_select_default() in probe
于 2013年07月10日 23:57, Wolfram Sang 写道: > Since commit ab78029 (drivers/pinctrl: grab default handles from device core), > we can rely on device core for setting the default pins. Compile tested only. > > Acked-by: Linus Walleij (personally at LCE13) > Signed-off-by: Wolfram Sang > --- i remember Fabio had already sent a similar patch about this issue. thanks Huang Shijie -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: rebase of the device-mapper quilt series
On Thu, Jul 11, 2013 at 10:31:16AM +1000, Stephen Rothwell wrote: > You have > just invalidated your testing On the contrary, it is part of my testing. > Your whole series was already > based after v3.10 (i.e. released or rebased after the merge window > opened), so why move it again? I usually base it either on the actual final release, v3.10 in this case, or, if there are non-trivial conflicts, a suitable commit from a point after the inclusion of the tree (normally block) leading to the conflict. Alasdair -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] fs: sync: fixed performance regression
On Wed, Jul 10, 2013 at 04:12:36PM -0700, Paul Taysom wrote: > The following commit introduced a 10x regression for > syncing inodes in ext4 with relatime enabled where just > the atime had been modified. > > commit 4ea425b63a3dfeb7707fc7cc7161c11a51e871ed > Author: Jan Kara > Date: Tue Jul 3 16:45:34 2012 +0200 > vfs: Avoid unnecessary WB_SYNC_NONE writeback during sys_sync and reorder > sync passes > > See also: http://www.kernelhub.org/?msg=93100=2 > > Fixed by putting back in the call to writeback_inodes_sb. > > I'll attach the test in a reply to this e-mail. > > The test starts by creating 512 files, syncing, reading one byte > from each of those files, syncing, and then deleting each file > and syncing. The time to do each sync is printed. The process > is then repeated for 1024 files and then the next power of > two up to 262144 files. > > Note, when running the test, the slow down doesn't always happen > but most of the tests will show a slow down. Can you please check if the patch attached to this mail: http://marc.info/?l=linux-kernel=137276874025813=2 Fixes your problem? Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: uefi boot hang (bisected)
On 07/10/2013 08:36 PM, Matt Fleming wrote: > On 10/07/13 07:36, Dave Young wrote: >> Another problem is: With this patch applied I tried noefi boot, but >> kernel paniced, looks like efivar_init depends on efi runtime. Below >> patches works for me about noefi boot though I'm not sure if it's a >> right fix, please review. > > It makes more sense to check in efivars.c, since none of that file can > function without runtime serivces. > > Could you try the following patch? It works, thanks for the patch. Tested-by: Dave Young > > --- > > diff --git a/drivers/firmware/efi/efivars.c b/drivers/firmware/efi/efivars.c > index 8bd1bb6..8a7432a 100644 > --- a/drivers/firmware/efi/efivars.c > +++ b/drivers/firmware/efi/efivars.c > @@ -583,6 +583,9 @@ int efivars_sysfs_init(void) > struct kobject *parent_kobj = efivars_kobject(); > int error = 0; > > + if (!efi_enabled(EFI_RUNTIME_SERVICES)) > + return -ENODEV; > + > /* No efivars has been registered yet */ > if (!parent_kobj) > return 0; > -- Thanks Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: rebase of the device-mapper quilt series
On Thu, Jul 11, 2013 at 10:31:16AM +1000, Stephen Rothwell wrote: > Why have you just rebased the device-mapper series I was confirming there weren't any unexpected conflicts or other issues to deal with from a point after the block tree went in before generating the pull request. Alasdair -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pci: exynos: split into two parts such as Synopsys part and Exynos part
On Wednesday, July 10, 2013 11:02 PM, Kishon Vijay Abraham I: > On Friday 05 July 2013 01:59 PM, Jingoo Han wrote: > > Exynos PCIe IP consists of Synopsys specific part and Exynos > > specific part. Only core block is a Synopsys designware part; > > other parts are Exynos specific. > > Also, the Synopsys designware part can be shared with other > > platforms; thus, it can be split two parts such as Synopsys > > designware part and Exynos specific part. > > Thanks for doing that :-) > > I'll be using the synopsys specific part as Jacinto6 also uses the same pcie > core. Once I start implementing, I'll have some queries and comments ;-) Hi Kishon, OK, I see. I will send v2 patch. Also, I will be CC'ing you. :) Best regards, Jingoo Han -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] device-mapper changes for 3.11
Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm tags/dm-3.11-changes to get the following device-mapper changes for 3.11. Thanks, Alasdair Add a device-mapper target called dm-switch to provide a multipath framework for storage arrays that dynamically reconfigure their preferred paths for different device regions. Fix a bug in the verity target that prevented its use with some specific sizes of devices. Improve some locking mechanisms in the device-mapper core and bufio. Add Mike Snitzer as a device-mapper maintainer. A few more clean-ups and fixes. Alasdair G Kergon (2): dm flakey: correct ctr alloc failure mesg dm: update maintainers Hannes Reinecke (1): dm mpath: fix ioctl deadlock when no paths Jim Ramsay (1): dm: add switch target Mikulas Patocka (9): dm ioctl: set noio flag to avoid __vmalloc deadlock dm verity: fix inability to use a few specific devices sizes dm: use __GFP_HIGHMEM in __vmalloc dm verity: remove pointless comparison dm verity: use __ffs and __fls dm cache: fix arm link errors with inline dm bufio: submit writes outside lock dm: optimize use SRCU and RCU dm: optimize reorder structure Documentation/device-mapper/switch.txt | 126 MAINTAINERS|2 + drivers/md/Kconfig | 14 + drivers/md/Makefile|1 + drivers/md/dm-bufio.c | 75 - drivers/md/dm-cache-target.c |4 + drivers/md/dm-flakey.c |2 +- drivers/md/dm-ioctl.c | 127 +--- drivers/md/dm-mpath.c |8 +- drivers/md/dm-switch.c | 538 drivers/md/dm-table.c | 35 --- drivers/md/dm-verity.c | 17 +- drivers/md/dm.c| 177 ++- include/linux/device-mapper.h |6 +- include/uapi/linux/dm-ioctl.h |4 +- 15 files changed, 951 insertions(+), 185 deletions(-) create mode 100644 Documentation/device-mapper/switch.txt create mode 100644 drivers/md/dm-switch.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tpmdd-devel] [PATCH 3/4] tpm: Convert tpm_tis driver to use dev_pm_ops from legacy pm_ops
Hi Peter, On 07/10/2013 05:30 PM, Peter Hüwe wrote: >> >> tpm_tis_resume() is defined originally in CONFIG_PM_SLEEP scope. I can >> make the change to have tpm_tis_resume() not be in CONFIG_PM_SLEEP scope >> and remove this CONFIG_PM_SLEEP when defining .pm. >> That does make sense looking at tpm_pm_suspend() and tpm_pm_resume() which >> are defined ithout CONFIG_PM_SLEEP scope. Sounds like the right approach? >> I will redo the patch and send v2. > > Hmm, > at first I thought that would be a good idea, however scrolling to the git > history I found: > > commit 07368d32f1a67e797def08cf2ee3ea1647b204b6 > Author: Rafael J. Wysocki > Date: Thu Aug 9 23:00:35 2012 +0200 > > tpm_tis / PM: Fix unused function warning for CONFIG_PM_SLEEP > > According to a compiler warning, the tpm_tis_resume() function is not > used for CONFIG_PM_SLEEP unset, so add a #ifdef to prevent it from > being built in that case. > > Signed-off-by: Rafael J. Wysocki > > So removing it there would effectively revert the patch and re-enable the > warning. > > > >> I find that the use of CONFIG_PM, CONFIG_PM_SLEEP, and CONFIG_PM_RUNTIME >> are not very consistent. :) > Yes. > > Maybe the better idea is to add the correct CONFIG_PM ifdefs for all code > paths related to PM. > Or leave the CONFIG_PM for tpm_tis_resume as it is. > > For now, leaving tpm_tis_resume() is better to keep this change simpler. I am seeing this type of inconsistency in several drivers as I am going around making changes to convert from legacy pm_ops to dev_pm_ops. At some point, it might be worth while looking at the usage of these defines and set some clear guidelines. -- Shuah Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research America (Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] remove sched notifier for cross-cpu migrations
Linux as a guest on KVM hypervisor, the only user of the pvclock
vsyscall interface, does not require notification on task migration
because:
1. cpu ID number maps 1:1 to per-CPU pvclock time info.
2. per-CPU pvclock time info is updated if the
underlying CPU changes.
3. that version is increased whenever underlying CPU
changes.
Which is sufficient to guarantee nanoseconds counter
is calculated properly.
Signed-off-by: Marcelo Tosatti
diff --git a/arch/x86/include/asm/pvclock.h b/arch/x86/include/asm/pvclock.h
index 109a9dd..be8269b 100644
--- a/arch/x86/include/asm/pvclock.h
+++ b/arch/x86/include/asm/pvclock.h
@@ -93,7 +93,6 @@ unsigned __pvclock_read_cycles(const struct
pvclock_vcpu_time_info *src,
struct pvclock_vsyscall_time_info {
struct pvclock_vcpu_time_info pvti;
- u32 migrate_count;
} __attribute__((__aligned__(SMP_CACHE_BYTES)));
#define PVTI_SIZE sizeof(struct pvclock_vsyscall_time_info)
diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c
index 2cb9470..a16bae3 100644
--- a/arch/x86/kernel/pvclock.c
+++ b/arch/x86/kernel/pvclock.c
@@ -128,46 +128,7 @@ void pvclock_read_wallclock(struct pvclock_wall_clock
*wall_clock,
set_normalized_timespec(ts, now.tv_sec, now.tv_nsec);
}
-static struct pvclock_vsyscall_time_info *pvclock_vdso_info;
-
-static struct pvclock_vsyscall_time_info *
-pvclock_get_vsyscall_user_time_info(int cpu)
-{
- if (!pvclock_vdso_info) {
- BUG();
- return NULL;
- }
-
- return _vdso_info[cpu];
-}
-
-struct pvclock_vcpu_time_info *pvclock_get_vsyscall_time_info(int cpu)
-{
- return _get_vsyscall_user_time_info(cpu)->pvti;
-}
-
#ifdef CONFIG_X86_64
-static int pvclock_task_migrate(struct notifier_block *nb, unsigned long l,
- void *v)
-{
- struct task_migration_notifier *mn = v;
- struct pvclock_vsyscall_time_info *pvti;
-
- pvti = pvclock_get_vsyscall_user_time_info(mn->from_cpu);
-
- /* this is NULL when pvclock vsyscall is not initialized */
- if (unlikely(pvti == NULL))
- return NOTIFY_DONE;
-
- pvti->migrate_count++;
-
- return NOTIFY_DONE;
-}
-
-static struct notifier_block pvclock_migrate = {
- .notifier_call = pvclock_task_migrate,
-};
-
/*
* Initialize the generic pvclock vsyscall state. This will allocate
* a/some page(s) for the per-vcpu pvclock information, set up a
@@ -181,17 +142,12 @@ int __init pvclock_init_vsyscall(struct
pvclock_vsyscall_time_info *i,
WARN_ON (size != PVCLOCK_VSYSCALL_NR_PAGES*PAGE_SIZE);
- pvclock_vdso_info = i;
-
for (idx = 0; idx <= (PVCLOCK_FIXMAP_END-PVCLOCK_FIXMAP_BEGIN); idx++) {
__set_fixmap(PVCLOCK_FIXMAP_BEGIN + idx,
__pa(i) + (idx*PAGE_SIZE),
PAGE_KERNEL_VVAR);
}
-
- register_task_migration_notifier(_migrate);
-
return 0;
}
#endif
diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
index c74436e..72074d5 100644
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -85,15 +85,18 @@ static notrace cycle_t vread_pvclock(int *mode)
cycle_t ret;
u64 last;
u32 version;
- u32 migrate_count;
u8 flags;
unsigned cpu, cpu1;
/*
-* When looping to get a consistent (time-info, tsc) pair, we
-* also need to deal with the possibility we can switch vcpus,
-* so make sure we always re-fetch time-info for the current vcpu.
+* Note: hypervisor must guarantee that:
+* 1. cpu ID number maps 1:1 to per-CPU pvclock time info.
+* 2. that per-CPU pvclock time info is updated if the
+*underlying CPU changes.
+* 3. that version is increased whenever underlying CPU
+*changes.
+*
*/
do {
cpu = __getcpu() & VGETCPU_CPU_MASK;
@@ -104,8 +107,6 @@ static notrace cycle_t vread_pvclock(int *mode)
pvti = get_pvti(cpu);
- migrate_count = pvti->migrate_count;
-
version = __pvclock_read_cycles(>pvti, , );
/*
@@ -117,8 +118,7 @@ static notrace cycle_t vread_pvclock(int *mode)
cpu1 = __getcpu() & VGETCPU_CPU_MASK;
} while (unlikely(cpu != cpu1 ||
(pvti->pvti.version & 1) ||
- pvti->pvti.version != version ||
- pvti->migrate_count != migrate_count));
+ pvti->pvti.version != version));
if (unlikely(!(flags & PVCLOCK_TSC_STABLE_BIT)))
*mode = VCLOCK_NONE;
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 178a8d9..217ce4b 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -107,14 +107,6 @@ extern unsigned long this_cpu_load(void);
extern void calc_global_load(unsigned long
Re: [PATCH 2/3] arm: atmel: at91sam9n12: add qt1070 support
Hi J,
On 7/10/2013 22:38, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 17:51 Wed 10 Jul , Bo Shen wrote:
add qt1070 support on at91sam9n12ek board
Signed-off-by: Bo Shen
---
arch/arm/boot/dts/at91sam9n12ek.dts | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9n12ek.dts
b/arch/arm/boot/dts/at91sam9n12ek.dts
index d59b70c..3acac62 100644
--- a/arch/arm/boot/dts/at91sam9n12ek.dts
+++ b/arch/arm/boot/dts/at91sam9n12ek.dts
@@ -40,6 +40,15 @@
i2c0: i2c@f801 {
status = "okay";
+
+ qt1070: keyboard@1b {
+ compatible = "qt1070";
+ reg = <0x1b>;
+ interrupt-parent = <>;
+ interrupts = <2 0x0>;
use the macro
Thanks, I will use macro here.
+ pinctrl-names = "default";
+ pinctrl-0 = <_qt1070_irq>;
+ };
};
i2c1: i2c@f8014000 {
@@ -66,6 +75,13 @@
; /* PA7 gpio CD pin pull up
and deglitch */
};
};
+
+ qt1070 {
+ pinctrl_qt1070_irq: qt1070_irq {
+ atmel,pins =
+ ; /* PA2 GPIO with pull up deglith
*/
drop the comment as we use macro
OK, I will drop the comment
+ };
+ };
};
spi0: spi@f000 {
--
Best Regards,
J.
Best Regards,
Bo Shen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arm: atmel: at91sam9n12: add pinctrl of TWI
Hi J,
On 7/10/2013 22:39, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 17:51 Wed 10 Jul , Bo Shen wrote:
add pinctrl of TWI for at91sam9n12 SoC
Signed-off-by: Bo Shen
---
arch/arm/boot/dts/at91sam9n12.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi
b/arch/arm/boot/dts/at91sam9n12.dtsi
index bb7f564..3db62f6 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91sam9n12.dtsi
@@ -291,6 +291,22 @@
};
};
+ i2c0 {
+ pinctrl_i2c0: i2c0-0 {
+ atmel,pins =
+ ; /* PA31 periph A I2C0 clock */
+ };
+ };
+
+ i2c1 {
+ pinctrl_i2c1: i2c1-0 {
+ atmel,pins =
+ ; /* PC1 periph C I2C1 clock */
drop the comment as we use macro
Thanks, I will drop the comment.
+ };
+ };
+
tcb0 {
pinctrl_tcb0_tclk0: tcb0_tclk0-0 {
atmel,pins = ;
@@ -471,6 +487,8 @@
dma-names = "tx", "rx";
#address-cells = <1>;
#size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_i2c0>;
status = "disabled";
};
@@ -483,6 +501,8 @@
dma-names = "tx", "rx";
#address-cells = <1>;
#size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_i2c1>;
status = "disabled";
};
--
1.7.9.5
Best Regards,
Bo Shen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Support multiple pages allocation
On Wed, Jul 10, 2013 at 01:27:37PM +0200, Michal Hocko wrote: > On Wed 10-07-13 18:55:33, Joonsoo Kim wrote: > > On Wed, Jul 10, 2013 at 11:17:03AM +0200, Michal Hocko wrote: > > > On Wed 10-07-13 09:31:42, Joonsoo Kim wrote: > > > > On Thu, Jul 04, 2013 at 12:00:44PM +0200, Michal Hocko wrote: > [...] > > > > > Which benchmark you are using for this testing? > > > > > > > > I use my own module which do allocation repeatedly. > > > > > > I am not sure this microbenchmark will tell us much. Allocations are > > > usually not short lived so the longer time might get amortized. > > > If you want to use the multi page allocation for read ahead then try to > > > model your numbers on read-ahead workloads. > > > > Of couse. In later, I will get the result on read-ahead workloads or > > vmalloc workload which is recommended by Zhang. > > > > I think, without this microbenchmark, we cannot know this modification's > > performance effect to single page allocation accurately. Because the impact > > to single page allocation is relatively small and it is easily hidden by > > other factors. > > The main thing is whether the numbers you get from an artificial > microbenchmark matter at all. You might see a regression which cannot be > hit in practice because other effects are of magnitude more significant. Okay. I will keep this in mind. Thanks for your comment. > -- > Michal Hocko > SUSE Labs > > -- > 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: [RFC PATCH 1/5] mm, page_alloc: support multiple pages allocation
On Wed, Jul 10, 2013 at 03:52:42PM -0700, Dave Hansen wrote:
> On 07/03/2013 01:34 AM, Joonsoo Kim wrote:
> > - if (page)
> > + do {
> > + page = buffered_rmqueue(preferred_zone, zone, order,
> > + gfp_mask, migratetype);
> > + if (!page)
> > + break;
> > +
> > + if (!nr_pages) {
> > + count++;
> > + break;
> > + }
> > +
> > + pages[count++] = page;
> > + if (count >= *nr_pages)
> > + break;
> > +
> > + mark = zone->watermark[alloc_flags & ALLOC_WMARK_MASK];
> > + if (!zone_watermark_ok(zone, order, mark,
> > + classzone_idx, alloc_flags))
> > + break;
> > + } while (1);
>
> I'm really surprised this works as well as it does. Calling
> buffered_rmqueue() a bunch of times enables/disables interrupts a bunch
> of times, and mucks with the percpu pages lists a whole bunch.
> buffered_rmqueue() is really meant for _single_ pages, not to be called
> a bunch of times in a row.
>
> Why not just do a single rmqueue_bulk() call?
Hello, Dave.
There are some reasons why I implement the feature in this way.
rmqueue_bulk() needs a zone lock. If we allocate not so many pages,
for example, 2 or 3 pages, it can have much more overhead rather than
allocationg 1 page multiple times. So, IMHO, it is better that
multiple pages allocation is supported on top of percpu pages list.
And I think that enables/disables interrupts a bunch of times help
to avoid a latency problem. If we disable interrupts until the whole works
is finished, interrupts can be handled too lately.
free_hot_cold_page_list() already do enables/disalbed interrupts a bunch of
times.
Thanks for helpful comment!
>
> --
> 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: [PATCH 1/1 V2] linux-firmware: Add AMD microcode patch firmware files
I've applied this, but: On Wed, 2013-07-10 at 19:42 -0500, suravee.suthikulpa...@amd.com wrote: > From: Suravee Suthikulpanit > > For AMD Families 10h ~ 14h Processors > file: amd-ucode/microcode_amd.bin > md5sum: 55ae79b82cbfddcf7142058be3c9ec2d > > For AMD Family 15h Processors > file: amd-ucode/microcode_amd_fam15h.bin > md5sum: 122ac7e56442c2b7c28eb26978b2d57c > > Version: 07_10_2013 This is not a suitable version format, as e.g. 01_01_2014 would be a later version but will sort earlier. When dates are used as versions, they should be written in ISO 8601 order, -mm-dd. Old releases from amd64.org were labelled that way. Also, the version belongs in WHENCE, so I added this to WHENCE: Version: 2013-07-10 > Signed-off-by: Sherry Hurwitz > Signed-off-by: Suravee Suthikulpanit > > --- > > Key Name= AMD Microcode Signing Key (for signing microcode container > files only) > Key ID = 8C0108B4 > Key Fingerprint = 916A 7708 23A7 B27A ADE0 1565 A5E8 DBC9 8C01 08B4 > > GnuPG Signature for file : microcode_amd.bin.asc > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > > iQEcBAABAgAGBQJR3dkLAAoJEKXo28mMAQi0/9cIAKraXlbchZkkIPzyMrZBZZJe > zapMterpLdDYL6zukfqgF7Frg94+ilGPK9yKAFsvC+EJyHrF5lbRQ/JthANdRv+Y > 8sBKz5/knVI72WdjSjg+473I1rFdIUK+YN7Ygp6eAwP3fg/IQ9UD9iQfWKbbUnx0 > WSEMCZm/izsyU2LQMJvtizJ2gz9ktFoALUtTvj0bv34CKr++qqngEVFy/WKQdR6x > R3l5MjFAhvzO0O9gV59s1tXbPU56HRhMbvSBn3NIVZu17pwAFySHwQLAeW10GH0j > UfgpKQppbz90iLLaSh8vseTOoTBn5SegDtK0JEJNMOuK1VoZ+kgv0cqGCs17HBQ= > =FnHv > -END PGP SIGNATURE- > > GnuPG Signature for file : microcode_amd_fam15h.bin.asc > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > > iQEcBAABAgAGBQJR3dkfAAoJEKXo28mMAQi0iTsIAJ5nCgz/+jFYag2W/OH+kOQe > BDXYSC5diXQR5wF/HUkXWh0sl+jNK/OrRVxT7sFaEgAUhEXhK6Df/h7qnJAYQGFr > 5+CKhfSr/0Qbk1ziWYAXVKMOXbuLWSSIov1SCcwLsps7A7puITK6xDemLby7KDGC > xCUfKIM/BO6DyFpNhKQ+xJdDi+yVxUKQhbdk/8gY94VdUnVZq3CTK9UStpBuaXu0 > qJNfhbaU+OzgZmnmLq5+xGsCML1xfbgF6sexVRx7oT/Jv30tm97YQJWR0h4DU7jU > zjID8kGtYRVV7+i8jC+jVpFo21yDVUkHUcqtNXXRB/lbOYFAm+UJviAEc4NEdSw= > =JaWY > -END PGP SIGNATURE- [...] I added the detached signatures to the commit as separate files, so that distributions and other downstream users can verify the signatures. linux-firmware.git itself is not currently being tagged, with or without signatures. Please include detached signatures in future. Ben. -- Ben Hutchings Reality is just a crutch for people who can't handle science fiction. signature.asc Description: This is a digitally signed message part
Re: [PATCH] usb: USB host support should depend on HAS_DMA
On Thu, 11 Jul 2013, Arnd Bergmann wrote:
> On Wednesday 10 July 2013, Alan Stern wrote:
> > This isn't right. There are USB host controllers that use PIO, not
> > DMA. The HAS_DMA dependency should go with the controller driver, not
> > the USB core.
> >
> > On the other hand, the USB core does call various routines like
> > dma_unmap_single. It ought to be possible to compile these calls even
> > when DMA isn't enabled. That is, they should be defined as do-nothing
> > stubs.
>
> The asm-generic/dma-mapping-broken.h file intentionally causes link
> errors, but that could be changed.
>
> The better approach in my mind would be to replace code like
>
>
> if (hcd->self.uses_dma)
>
> with
>
> if (IS_ENABLED(CONFIG_HAS_DMA) && hcd->self.uses_dma) {
>
> which will reliably cause that reference to be omitted from object code,
> but not stop giving link errors for drivers that actually require
> DMA.
How will it give link errors for drivers that require DMA?
Besides, wouldn't it be better to get an error at config time rather
than at link time? Or even better still, not to be allowed to
configure drivers that depend on DMA if DMA isn't available?
If we add an explicit dependency for HAS_DMA to the Kconfig entries for
these drivers, then your suggestion would be a good way to allow
usbcore to be built independently of DMA support.
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/1 V2] linux-firmware: Add AMD microcode patch firmware files
From: Suravee Suthikulpanit
For AMD Families 10h ~ 14h Processors
file: amd-ucode/microcode_amd.bin
md5sum: 55ae79b82cbfddcf7142058be3c9ec2d
For AMD Family 15h Processors
file: amd-ucode/microcode_amd_fam15h.bin
md5sum: 122ac7e56442c2b7c28eb26978b2d57c
Version: 07_10_2013
Signed-off-by: Sherry Hurwitz
Signed-off-by: Suravee Suthikulpanit
---
Key Name= AMD Microcode Signing Key (for signing microcode container
files only)
Key ID = 8C0108B4
Key Fingerprint = 916A 7708 23A7 B27A ADE0 1565 A5E8 DBC9 8C01 08B4
GnuPG Signature for file : microcode_amd.bin.asc
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAABAgAGBQJR3dkLAAoJEKXo28mMAQi0/9cIAKraXlbchZkkIPzyMrZBZZJe
zapMterpLdDYL6zukfqgF7Frg94+ilGPK9yKAFsvC+EJyHrF5lbRQ/JthANdRv+Y
8sBKz5/knVI72WdjSjg+473I1rFdIUK+YN7Ygp6eAwP3fg/IQ9UD9iQfWKbbUnx0
WSEMCZm/izsyU2LQMJvtizJ2gz9ktFoALUtTvj0bv34CKr++qqngEVFy/WKQdR6x
R3l5MjFAhvzO0O9gV59s1tXbPU56HRhMbvSBn3NIVZu17pwAFySHwQLAeW10GH0j
UfgpKQppbz90iLLaSh8vseTOoTBn5SegDtK0JEJNMOuK1VoZ+kgv0cqGCs17HBQ=
=FnHv
-END PGP SIGNATURE-
GnuPG Signature for file : microcode_amd_fam15h.bin.asc
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAABAgAGBQJR3dkfAAoJEKXo28mMAQi0iTsIAJ5nCgz/+jFYag2W/OH+kOQe
BDXYSC5diXQR5wF/HUkXWh0sl+jNK/OrRVxT7sFaEgAUhEXhK6Df/h7qnJAYQGFr
5+CKhfSr/0Qbk1ziWYAXVKMOXbuLWSSIov1SCcwLsps7A7puITK6xDemLby7KDGC
xCUfKIM/BO6DyFpNhKQ+xJdDi+yVxUKQhbdk/8gY94VdUnVZq3CTK9UStpBuaXu0
qJNfhbaU+OzgZmnmLq5+xGsCML1xfbgF6sexVRx7oT/Jv30tm97YQJWR0h4DU7jU
zjID8kGtYRVV7+i8jC+jVpFo21yDVUkHUcqtNXXRB/lbOYFAm+UJviAEc4NEdSw=
=JaWY
-END PGP SIGNATURE-
LICENSE.amd-ucode | 64
WHENCE |9 +
amd-ucode/microcode_amd.bin| Bin 0 -> 12684 bytes
amd-ucode/microcode_amd_fam15h.bin | Bin 0 -> 7876 bytes
4 files changed, 73 insertions(+)
create mode 100644 LICENSE.amd-ucode
create mode 100644 amd-ucode/microcode_amd.bin
create mode 100644 amd-ucode/microcode_amd_fam15h.bin
diff --git a/LICENSE.amd-ucode b/LICENSE.amd-ucode
new file mode 100644
index 000..9d4c425
--- /dev/null
+++ b/LICENSE.amd-ucode
@@ -0,0 +1,64 @@
+Copyright (C) 2010-2013 Advanced Micro Devices, Inc., All rights reserved.
+
+Permission is hereby granted by Advanced Micro Devices, Inc. ("AMD"),
+free of any license fees, to any person obtaining a copy of this
+microcode in binary form (the "Software") ("You"), to install,
+reproduce, copy and distribute copies of the Software and to permit
+persons to whom the Software is provided to do the same, subject to
+the following terms and conditions. Your use of any portion of the
+Software shall constitute Your acceptance of the following terms and
+conditions. If You do not agree to the following terms and conditions,
+do not use, retain or redistribute any portion of the Software.
+
+If You redistribute this Software, You must reproduce the above
+copyright notice and this license with the Software.
+Without specific, prior, written permission from AMD, You may not
+reference AMD or AMD products in the promotion of any product derived
+from or incorporating this Software in any manner that implies that
+AMD endorses or has certified such product derived from or
+incorporating this Software.
+
+You may not reverse engineer, decompile, or disassemble this Software
+or any portion thereof.
+
+THE SOFTWARE IS PROVIDED "AS IS" WITHOUT ANY EXPRESS OR IMPLIED
+WARRANTY OF ANY KIND, INCLUDING BUT NOT LIMITED TO WARRANTIES OF
+MERCHANTABILITY, NONINFRINGEMENT, TITLE, FITNESS FOR ANY PARTICULAR
+PURPOSE, OR WARRANTIES ARISING FROM CONDUCT, COURSE OF DEALING, OR
+USAGE OF TRADE. IN NO EVENT SHALL AMD OR ITS LICENSORS BE LIABLE FOR
+ANY DAMAGES WHATSOEVER (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR
+LOSS OF PROFITS, BUSINESS INTERRUPTION, OR LOSS OF DATA OR
+INFORMATION) ARISING OUT OF AMD'S NEGLIGENCE, GROSS NEGLIGENCE, THE
+USE OF OR INABILITY TO USE THE SOFTWARE, EVEN IF AMD HAS BEEN ADVISED
+OF THE POSSIBILITY OF SUCH DAMAGES. BECAUSE SOME JURISDICTIONS
+PROHIBIT THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR
+INCIDENTAL DAMAGES OR THE EXCLUSION OF IMPLIED WARRANTIES, THE ABOVE
+LIMITATION MAY NOT APPLY TO YOU.
+
+Without limiting the foregoing, the Software may implement third party
+technologies for which You must obtain licenses from parties other
+than AMD. You agree that AMD has not obtained or conveyed to You, and
+that You shall be responsible for obtaining the rights to use and/or
+distribute the applicable underlying intellectual property rights
+related to the third party technologies. These third party
+technologies are not licensed hereunder.
+
+If You use the Software (in whole or in part), You shall adhere to all
+applicable U.S., European, and other export laws, including but not
+limited to the U.S. Export Administration Regulations ("EAR"), (15
+C.F.R. Sections 730 through 774), and E.U. Council Regulation (EC) No
Re: [PATCH firmware] rtl_nic: add firmware rtl8411-2
On Mon, 2013-07-08 at 17:11 +0800, Hayes Wang wrote: > File: rtl_nic/rtl8411-2.fw > Version: 0.0.1 > > Signed-off-by: Hayes Wang > --- > WHENCE | 3 +++ > rtl_nic/rtl8411-2.fw | Bin 0 -> 1040 bytes > 2 files changed, 3 insertions(+) > create mode 100644 rtl_nic/rtl8411-2.fw [...] Applied, thanks. Ben. -- Ben Hutchings Reality is just a crutch for people who can't handle science fiction. signature.asc Description: This is a digitally signed message part
Re: [PATCH] perf: Update event buffer tail when overwriting old events
On 07/10/2013 07:44 PM, Peter Zijlstra wrote: > On Wed, Jul 10, 2013 at 07:37:43PM +0800, Yan, Zheng wrote: >> On 07/08/2013 08:15 PM, Peter Zijlstra wrote: >>> On Thu, Jun 06, 2013 at 01:58:06PM +0800, Yan, Zheng wrote: From: "Yan, Zheng" > before overwrite mode after overwrite mode AVG 1000999 10461044 STDEV19.419.517.117.9 >>> >>> OK, so I was sure I replied to this email; but apparently I didn't :/ >>> >>> So its still adding about 5% overhead to the regular case; this is sad. >>> >>> What does something like the below do? >>> >> >> I re-test the patch on a different 32 core sandybridge-ep machine. the >> result is quite good. >> >>origin origin overwrite modifiedmodified overwrite >> AVG1000 1044 9601006 >> STDEV 39.0 26.0 28.1 14.4 > > Nice! -- you did fix the snafu for the overwrite more before testing right? > yes, of course. Regards Yan, Zheng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] fs: sync: fixed performance regression
Third time is the charm crbug.com/240411 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] mmc: dw_mmc: Add exynos resume callback to clear WAKEUP_INT
On Tue, Jul 9, 2013 at 12:09 PM, Doug Anderson wrote: > Hi, > > On Tue, Jul 9, 2013 at 10:31 AM, Doug Anderson wrote: >> If the WAKEUP_INT is asserted at wakeup and not cleared, we'll end up >> looping around forever. >> >> Signed-off-by: Doug Anderson >> --- >> drivers/mmc/host/dw_mmc-exynos.c | 23 +++ >> 1 file changed, 23 insertions(+) > > Grant just pointed out that the WAKEUP_INT is supposed to only be > enabled if bits 8, 9, or 10 are 1. Our driver never sets those so we > _should_ never get a WAKEUP_INT. Bits 8-10 are marked as RESERVED on > the exynos5420 manual, so the current guess is that they're broken on > that silicon but that sometimes the interrupt fires anyway. > > In any case, it is still a reasonable thing to clear this interrupt at > wakeup if it has fired, even if we're on an exynos device without any > problems. I agree. Can add: Reviewed-by: Grant Grundler thanks, grant > > -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next] r8169: add a new chip for RTL8411
From: Francois Romieu Date: Wed, 10 Jul 2013 01:00:16 +0200 > David Miller : > [...] >> Francois, please review. > > The style is consistent with the driver. > > The commit message may state that this 8411 chipset does not require > any special action in rtl_link_chg_patch (whence differing from the > previous "F" 8411). > > Most of the code shared by rtl_hw_start_8168g_2 and rtl_hw_start_8411_2 > is already factored out. There is not much to win here. > > The new RTL_GIGA_MAC_VER_XY id is added in the required places. > > It builds. > > It's fine. Thanks for reviewing, applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] tracing: Fix error handling to ensure instances can always be removed
Remove debugfs directories for tracing instances during creation if an error
occurs causing the trace_array for that instance to not be added to
ftrace_trace_arrays. If the directory continues to exist after the error, it
cannot be removed because the respective trace_array is not in
ftrace_trace_arrays.
Cc: Vaibhav Nagarnaik
Cc: David Sharp
Cc: Alexander Z Lam
Signed-off-by: Alexander Z Lam
---
kernel/trace/trace.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index ca2743b..4ea9967 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -5985,8 +5985,10 @@ static int new_instance_create(const char *name)
goto out_free_tr;
ret = event_trace_add_tracer(tr->dir, tr);
- if (ret)
+ if (ret) {
+ debugfs_remove_recursive(tr->dir);
goto out_free_tr;
+ }
init_tracer_debugfs(tr, tr->dir);
--
1.8.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] fs: sync: fixed performance regression
On Wed, Jul 10, 2013 at 4:56 PM, Dave Jones wrote: > On Wed, Jul 10, 2013 at 04:12:36PM -0700, Paul Taysom wrote: > > > Note, when running the test, the slow down doesn't always happen > > but most of the tests will show a slow down. > > > > In response to crbug.com/240422 > > Just in case this ends up as the actual commit msg, that url > seems to be the wrong bug. > > Dave. Copied the wrong number crbug.con/218910 Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 3/7] sysfs.h: add BIN_ATTR macro
This makes it easier to create static binary attributes, which is needed
in a number of drivers, instead of "open coding" them.
Signed-off-by: Greg Kroah-Hartman
---
include/linux/sysfs.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index f62ff01..d50a96b 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -132,6 +132,15 @@ struct bin_attribute {
*/
#define sysfs_bin_attr_init(bin_attr) sysfs_attr_init(&(bin_attr)->attr)
+/* macro to create static binary attributes easier */
+#define BIN_ATTR(_name, _mode, _read, _write, _size) \
+struct bin_attribute bin_attr_##_name = { \
+ .attr = {.name = __stringify(_name), .mode = _mode }, \
+ .read = _read,\
+ .write = _write, \
+ .size = _size,\
+}
+
struct sysfs_ops {
ssize_t (*show)(struct kobject *, struct attribute *,char *);
ssize_t (*store)(struct kobject *,struct attribute *,const char *,
size_t);
--
1.8.3.rc0.20.gb99dd2e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/7] Driver core and sysfs changes for attribute groups
Hi all, Here's the second iteration of the patchset to add better attribute group support to the driver core and sysfs. I've tested these (shocker!) and everything works fine with them (I'm sending this from Linus's latest kernel with these 7 on top of it.) I'd like to send these to Linus for 3.11 unless someone objects. Oliver, please use this series instead of the last one, it has fixes that Guenter pointed out that would have crashed your box at boot. changes from v2: - actually boots - 7th patch added properly - added BUS_ATTR, CLASS_ATTR, and DRIVER_ATTR RW and RO macros to help with converting code to use attributes properly. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: rebase/rewrite of the renesas tree
Hi Simon, On Thu, 11 Jul 2013 09:31:33 +0900 Simon Horman wrote: > > I am not planning to send any pull requests for v3.11, > at least not for the branches that I rebased. Then none of that stuff should be in -next at the moment (not until after v3.11-rc1 is released). It just mucks up possible tesing for stuff that is still to be merged. > I can rewind the next branch if you like. If so, would rewinding > it to the point it was at for next-20130709 make sense? See above. > Also, on this topic, could you clarify when it would be appropriate > to do any rebasing. Obviously I am not clear on this. I notice that you seem to use topic branches that you then merge for inclusion in -next (and presumably arm-soc). You should endeavour to not rebase those topic branches once they have been published. Sometimes it may be very necessary, but generally it should not (as you would have done review and testing on them before publishing them, right? ;-)). You should definitely *not* rebase those branches after you have asked the arm-soc guys to merge them (unless that rebase is just to pick a new starting point (though you should generally be able to get that by fast forwarding into the arm soc tree after the spot where your stuff was merged). You should also not rebase them if others are using them as a base for development. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpUmOsJ9BXHX.pgp Description: PGP signature
[PATCH v2 2/7] sysfs.h: add ATTRIBUTE_GROUPS() macro
To make it easier for driver subsystems to work with attribute groups,
create the ATTRIBUTE_GROUPS macro to remove some of the repetitive
typing for the most common use for attribute groups.
Signed-off-by: Greg Kroah-Hartman
---
include/linux/sysfs.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index 9cd20c8..f62ff01 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -94,6 +94,15 @@ struct attribute_group {
#define __ATTR_IGNORE_LOCKDEP __ATTR
#endif
+#define ATTRIBUTE_GROUPS(name) \
+static const struct attribute_group name##_group = { \
+ .attrs = name##_attrs, \
+}; \
+static const struct attribute_group *name##_groups[] = { \
+ ##_group, \
+ NULL, \
+}
+
#define attr_name(_attr) (_attr).attr.name
struct file;
--
1.8.3.rc0.20.gb99dd2e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/7] driver core: device.h: add RW and RO attribute macros
Make it easier to create attributes without having to always audit the
mode settings.
Signed-off-by: Greg Kroah-Hartman
---
include/linux/device.h | 28 +---
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/include/linux/device.h b/include/linux/device.h
index bcf8c0d..f207a8f 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -47,7 +47,11 @@ struct bus_attribute {
};
#define BUS_ATTR(_name, _mode, _show, _store) \
-struct bus_attribute bus_attr_##_name = __ATTR(_name, _mode, _show, _store)
+ struct bus_attribute bus_attr_##_name = __ATTR(_name, _mode, _show,
_store)
+#define BUS_ATTR_RW(_name) \
+ struct bus_attribute bus_attr_##_name = __ATTR_RW(_name)
+#define BUS_ATTR_RO(_name) \
+ struct bus_attribute bus_attr_##_name = __ATTR_RO(_name)
extern int __must_check bus_create_file(struct bus_type *,
struct bus_attribute *);
@@ -261,9 +265,12 @@ struct driver_attribute {
size_t count);
};
-#define DRIVER_ATTR(_name, _mode, _show, _store) \
-struct driver_attribute driver_attr_##_name = \
- __ATTR(_name, _mode, _show, _store)
+#define DRIVER_ATTR(_name, _mode, _show, _store) \
+ struct driver_attribute driver_attr_##_name = __ATTR(_name, _mode,
_show, _store)
+#define DRIVER_ATTR_RW(_name) \
+ struct driver_attribute driver_attr_##_name = __ATTR_RW(_name)
+#define DRIVER_ATTR_RO(_name) \
+ struct driver_attribute driver_attr_##_name = __ATTR_RO(_name)
extern int __must_check driver_create_file(struct device_driver *driver,
const struct driver_attribute *attr);
@@ -414,8 +421,12 @@ struct class_attribute {
const struct class_attribute *attr);
};
-#define CLASS_ATTR(_name, _mode, _show, _store)\
-struct class_attribute class_attr_##_name = __ATTR(_name, _mode, _show, _store)
+#define CLASS_ATTR(_name, _mode, _show, _store) \
+ struct class_attribute class_attr_##_name = __ATTR(_name, _mode, _show,
_store)
+#define CLASS_ATTR_RW(_name) \
+ struct class_attribute class_attr_##_name = __ATTR_RW(_name)
+#define CLASS_ATTR_RO(_name) \
+ struct class_attribute class_attr_##_name = __ATTR_RO(_name)
extern int __must_check class_create_file(struct class *class,
const struct class_attribute *attr);
@@ -423,7 +434,6 @@ extern void class_remove_file(struct class *class,
const struct class_attribute *attr);
/* Simple class attribute that is just a static string */
-
struct class_attribute_string {
struct class_attribute attr;
char *str;
@@ -512,6 +522,10 @@ ssize_t device_store_bool(struct device *dev, struct
device_attribute *attr,
#define DEVICE_ATTR(_name, _mode, _show, _store) \
struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show,
_store)
+#define DEVICE_ATTR_RW(_name) \
+ struct device_attribute dev_attr_##_name = __ATTR_RW(_name)
+#define DEVICE_ATTR_RO(_name) \
+ struct device_attribute dev_attr_##_name = __ATTR_RO(_name)
#define DEVICE_ULONG_ATTR(_name, _mode, _var) \
struct dev_ext_attribute dev_attr_##_name = \
{ __ATTR(_name, _mode, device_show_ulong, device_store_ulong),
&(_var) }
--
1.8.3.rc0.20.gb99dd2e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 7/7] driver core: add default groups to struct class
We should be using groups, not attribute lists, for classes to allow
subdirectories, and soon, binary files. Groups are just more flexible
overall, so add them.
The dev_attrs list will go away after all in-kernel users are converted
to use dev_groups.
Signed-off-by: Greg Kroah-Hartman
---
drivers/base/core.c| 9 -
include/linux/device.h | 4 +++-
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index a8aae18..8856d74 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -528,9 +528,12 @@ static int device_add_attrs(struct device *dev)
int error;
if (class) {
- error = device_add_attributes(dev, class->dev_attrs);
+ error = device_add_groups(dev, class->dev_groups);
if (error)
return error;
+ error = device_add_attributes(dev, class->dev_attrs);
+ if (error)
+ goto err_remove_class_groups;
error = device_add_bin_attributes(dev, class->dev_bin_attrs);
if (error)
goto err_remove_class_attrs;
@@ -563,6 +566,9 @@ static int device_add_attrs(struct device *dev)
err_remove_class_attrs:
if (class)
device_remove_attributes(dev, class->dev_attrs);
+ err_remove_class_groups:
+ if (class)
+ device_remove_groups(dev, class->dev_groups);
return error;
}
@@ -581,6 +587,7 @@ static void device_remove_attrs(struct device *dev)
if (class) {
device_remove_attributes(dev, class->dev_attrs);
device_remove_bin_attributes(dev, class->dev_bin_attrs);
+ device_remove_groups(dev, class->dev_groups);
}
}
diff --git a/include/linux/device.h b/include/linux/device.h
index bd5931e..22b546a 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -320,6 +320,7 @@ int subsys_virtual_register(struct bus_type *subsys,
* @name: Name of the class.
* @owner: The module owner.
* @class_attrs: Default attributes of this class.
+ * @dev_groups:Default attributes of the devices that belong to the
class.
* @dev_attrs: Default attributes of the devices belong to the class.
* @dev_bin_attrs: Default binary attributes of the devices belong to the
class.
* @dev_kobj: The kobject that represents this class and links it into the
hierarchy.
@@ -349,7 +350,8 @@ struct class {
struct module *owner;
struct class_attribute *class_attrs;
- struct device_attribute *dev_attrs;
+ struct device_attribute *dev_attrs; /* use dev_groups
instead */
+ const struct attribute_group**dev_groups;
struct bin_attribute*dev_bin_attrs;
struct kobject *dev_kobj;
--
1.8.3.rc0.20.gb99dd2e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/7] sysfs: add support for binary attributes in groups
groups should be able to support binary attributes, just like it
supports "normal" attributes. This lets us only handle one type of
structure, groups, throughout the driver core and subsystems, making
binary attributes a "full fledged" part of the driver model, and not
something just "tacked on".
Reported-by: Oliver Schinagl
Signed-off-by: Greg Kroah-Hartman
---
fs/sysfs/group.c | 66 +++
include/linux/sysfs.h | 4 ++--
2 files changed, 48 insertions(+), 22 deletions(-)
diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
index aec3d5c..e5719c6 100644
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@ -20,38 +20,64 @@ static void remove_files(struct sysfs_dirent *dir_sd,
struct kobject *kobj,
const struct attribute_group *grp)
{
struct attribute *const* attr;
- int i;
+ struct bin_attribute *const* bin_attr;
- for (i = 0, attr = grp->attrs; *attr; i++, attr++)
- sysfs_hash_and_remove(dir_sd, NULL, (*attr)->name);
+ if (grp->attrs)
+ for (attr = grp->attrs; *attr; attr++)
+ sysfs_hash_and_remove(dir_sd, NULL, (*attr)->name);
+ if (grp->bin_attrs)
+ for (bin_attr = grp->bin_attrs; *bin_attr; bin_attr++)
+ sysfs_remove_bin_file(kobj, *bin_attr);
}
static int create_files(struct sysfs_dirent *dir_sd, struct kobject *kobj,
const struct attribute_group *grp, int update)
{
struct attribute *const* attr;
+ struct bin_attribute *const* bin_attr;
int error = 0, i;
- for (i = 0, attr = grp->attrs; *attr && !error; i++, attr++) {
- umode_t mode = 0;
+ if (grp->attrs) {
+ for (i = 0, attr = grp->attrs; *attr && !error; i++, attr++) {
+ umode_t mode = 0;
+
+ /*
+* In update mode, we're changing the permissions or
+* visibility. Do this by first removing then
+* re-adding (if required) the file.
+*/
+ if (update)
+ sysfs_hash_and_remove(dir_sd, NULL,
+ (*attr)->name);
+ if (grp->is_visible) {
+ mode = grp->is_visible(kobj, *attr, i);
+ if (!mode)
+ continue;
+ }
+ error = sysfs_add_file_mode(dir_sd, *attr,
+ SYSFS_KOBJ_ATTR,
+ (*attr)->mode | mode);
+ if (unlikely(error))
+ break;
+ }
+ if (error) {
+ remove_files(dir_sd, kobj, grp);
+ goto exit;
+ }
+ }
- /* in update mode, we're changing the permissions or
-* visibility. Do this by first removing then
-* re-adding (if required) the file */
- if (update)
- sysfs_hash_and_remove(dir_sd, NULL, (*attr)->name);
- if (grp->is_visible) {
- mode = grp->is_visible(kobj, *attr, i);
- if (!mode)
- continue;
+ if (grp->bin_attrs) {
+ for (bin_attr = grp->bin_attrs; *bin_attr; bin_attr++) {
+ if (update)
+ sysfs_remove_bin_file(kobj, *bin_attr);
+ error = sysfs_create_bin_file(kobj, *bin_attr);
+ if (error)
+ break;
}
- error = sysfs_add_file_mode(dir_sd, *attr, SYSFS_KOBJ_ATTR,
- (*attr)->mode | mode);
- if (unlikely(error))
- break;
+ if (error)
+ remove_files(dir_sd, kobj, grp);
}
- if (error)
- remove_files(dir_sd, kobj, grp);
+exit:
return error;
}
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index d50a96b..2c3b6a3 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -21,6 +21,7 @@
struct kobject;
struct module;
+struct bin_attribute;
enum kobj_ns_type;
struct attribute {
@@ -59,10 +60,9 @@ struct attribute_group {
umode_t (*is_visible)(struct kobject *,
struct attribute *, int);
struct attribute**attrs;
+ struct bin_attribute**bin_attrs;
};
-
-
/**
* Use these macros to make defining attributes easier. See
include/linux/device.h
* for examples..
--
1.8.3.rc0.20.gb99dd2e
--
To unsubscribe from this list: send
[PATCH v2 6/7] driver core: Introduce device_create_groups
From: Guenter Roeck
device_create_groups lets callers create devices as well as associated
sysfs attributes with a single call. This avoids race conditions seen
if sysfs attributes on new devices are created later.
[fixed up comment block placement and add checks for printk buffer
formats - gregkh]
Signed-off-by: Guenter Roeck
Cc: Jean Delvare
Signed-off-by: Greg Kroah-Hartman
---
drivers/base/core.c| 111 -
include/linux/device.h | 5 +++
2 files changed, 88 insertions(+), 28 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index dc3ea23..a8aae18 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1667,34 +1667,11 @@ static void device_create_release(struct device *dev)
kfree(dev);
}
-/**
- * device_create_vargs - creates a device and registers it with sysfs
- * @class: pointer to the struct class that this device should be registered to
- * @parent: pointer to the parent struct device of this new device, if any
- * @devt: the dev_t for the char device to be added
- * @drvdata: the data to be added to the device for callbacks
- * @fmt: string for the device's name
- * @args: va_list for the device's name
- *
- * This function can be used by char device classes. A struct device
- * will be created in sysfs, registered to the specified class.
- *
- * A "dev" file will be created, showing the dev_t for the device, if
- * the dev_t is not 0,0.
- * If a pointer to a parent struct device is passed in, the newly created
- * struct device will be a child of that device in sysfs.
- * The pointer to the struct device will be returned from the call.
- * Any further sysfs files that might be required can be created using this
- * pointer.
- *
- * Returns device pointer on success, or ERR_PTR() on error.
- *
- * Note: the struct class passed to this function must have previously
- * been created with a call to class_create().
- */
-struct device *device_create_vargs(struct class *class, struct device *parent,
- dev_t devt, void *drvdata, const char *fmt,
- va_list args)
+static struct device *
+device_create_groups_vargs(struct class *class, struct device *parent,
+ dev_t devt, void *drvdata,
+ const struct attribute_group **groups,
+ const char *fmt, va_list args)
{
struct device *dev = NULL;
int retval = -ENODEV;
@@ -1711,6 +1688,7 @@ struct device *device_create_vargs(struct class *class,
struct device *parent,
dev->devt = devt;
dev->class = class;
dev->parent = parent;
+ dev->groups = groups;
dev->release = device_create_release;
dev_set_drvdata(dev, drvdata);
@@ -1728,6 +1706,39 @@ error:
put_device(dev);
return ERR_PTR(retval);
}
+
+/**
+ * device_create_vargs - creates a device and registers it with sysfs
+ * @class: pointer to the struct class that this device should be registered to
+ * @parent: pointer to the parent struct device of this new device, if any
+ * @devt: the dev_t for the char device to be added
+ * @drvdata: the data to be added to the device for callbacks
+ * @fmt: string for the device's name
+ * @args: va_list for the device's name
+ *
+ * This function can be used by char device classes. A struct device
+ * will be created in sysfs, registered to the specified class.
+ *
+ * A "dev" file will be created, showing the dev_t for the device, if
+ * the dev_t is not 0,0.
+ * If a pointer to a parent struct device is passed in, the newly created
+ * struct device will be a child of that device in sysfs.
+ * The pointer to the struct device will be returned from the call.
+ * Any further sysfs files that might be required can be created using this
+ * pointer.
+ *
+ * Returns device pointer on success, or ERR_PTR() on error.
+ *
+ * Note: the struct class passed to this function must have previously
+ * been created with a call to class_create().
+ */
+struct device *device_create_vargs(struct class *class, struct device *parent,
+ dev_t devt, void *drvdata, const char *fmt,
+ va_list args)
+{
+ return device_create_groups_vargs(class, parent, devt, drvdata, NULL,
+ fmt, args);
+}
EXPORT_SYMBOL_GPL(device_create_vargs);
/**
@@ -1767,6 +1778,50 @@ struct device *device_create(struct class *class, struct
device *parent,
}
EXPORT_SYMBOL_GPL(device_create);
+/**
+ * device_create_with_groups - creates a device and registers it with sysfs
+ * @class: pointer to the struct class that this device should be registered to
+ * @parent: pointer to the parent struct device of this new device, if any
+ * @devt: the dev_t for the char device to be added
+ * @drvdata: the data to be added to the device for callbacks
+ * @groups: NULL-terminated list of attribute
[PATCH v2 1/7] sysfs.h: add __ATTR_RW() macro
A number of parts of the kernel created their own version of this, might
as well have the sysfs core provide it instead.
Signed-off-by: Greg Kroah-Hartman
---
include/linux/sysfs.h | 2 ++
kernel/events/core.c | 2 --
mm/backing-dev.c | 2 --
3 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index e2cee22..9cd20c8 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -79,6 +79,8 @@ struct attribute_group {
.show = _name##_show, \
}
+#define __ATTR_RW(_name) __ATTR(_name, 0644, _name##_show, _name##_store)
+
#define __ATTR_NULL { .attr = { .name = NULL } }
#ifdef CONFIG_DEBUG_LOCK_ALLOC
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 1833bc5..95191bf 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6212,8 +6212,6 @@ perf_event_mux_interval_ms_store(struct device *dev,
return count;
}
-#define __ATTR_RW(attr) __ATTR(attr, 0644, attr##_show, attr##_store)
-
static struct device_attribute pmu_dev_attrs[] = {
__ATTR_RO(type),
__ATTR_RW(perf_event_mux_interval_ms),
diff --git a/mm/backing-dev.c b/mm/backing-dev.c
index d014ee5..e04454c 100644
--- a/mm/backing-dev.c
+++ b/mm/backing-dev.c
@@ -232,8 +232,6 @@ static ssize_t stable_pages_required_show(struct device
*dev,
bdi_cap_stable_pages_required(bdi) ? 1 : 0);
}
-#define __ATTR_RW(attr) __ATTR(attr, 0644, attr##_show, attr##_store)
-
static struct device_attribute bdi_dev_attrs[] = {
__ATTR_RW(read_ahead_kb),
__ATTR_RW(min_ratio),
--
1.8.3.rc0.20.gb99dd2e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/13] xfs: use get_unused_fd_flags(0) instead of get_unused_fd()
On Wed, Jul 10, 2013 at 12:00:57PM +0200, Yann Droneaud wrote: > Hi, > > Le 09.07.2013 22:53, Ben Myers a écrit : > >On Mon, Jul 08, 2013 at 05:41:33PM -0500, Ben Myers wrote: > >>On Tue, Jul 02, 2013 at 06:39:34PM +0200, Yann Droneaud wrote: > > >>> diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c > >>> index 5e99968..dc5b659 100644 > >>> --- a/fs/xfs/xfs_ioctl.c > >>> +++ b/fs/xfs/xfs_ioctl.c > >>> @@ -248,7 +248,7 @@ xfs_open_by_handle( > >>> goto out_dput; > >>> } > >>> > >>> - fd = get_unused_fd(); > >>> + fd = get_unused_fd_flags(0); > >> > >>O_CLOEXEC should be fine in this case. > >> > >>Reviewed-by: Ben Myers > > > >Applied at git://oss.sgi.com/xfs/xfs.git. Looks like I was wrong about > >O_CLOEXEC being ok here. There may be applications which > >open_by_handle then > >fork/exec and expect to still be able to use that file descriptor. > > > > OK, it's very important to not cause regression here. > > For the record, xfs_open_by_handle() is not related to > open_by_handle_at() syscall. > > It's an ioctl (XFS_IOC_OPEN_BY_HANDLE) which is used by xfsprogs's > libhandle > in functions open_by_fshandle() and open_by_handle(). > > http://sources.debian.net/src/xfsprogs/3.1.9/libhandle/handle.c?hl=284#L284 > http://sources.debian.net/src/xfsprogs/3.1.9/libhandle/handle.c?hl=308#L308 > > According to codesearch.debian.org, libhandle's open_by_handle() is > only used > by xfsdump > > http://sources.debian.net/src/xfsdump/3.1.1/restore/tree.c?hl=2534#L2534 > > So there's no many *known* users of this features ... but it's more > important > not to break *unknown* users of it. There are commercial products (i.e. proprietary, closed source) that use it. SGI has one (DMF) and there are a couple of other backup programs that have used it in the past, too. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/23] tools lib lk: Fix for cross build
On Wed, Jul 10, 2013 at 04:19:06PM -0300, Arnaldo Carvalho de Melo wrote: > From: Joonsoo Kim > > Currently, lib lk doesn't use CROSS_COMPILE environment variable, so > cross build always fails. Hello, Arnaldo. Fix for lib lk cross build is already merged into mainline. It may be from your tree :) See following commit. commit 3c4797d46c14fa0c7cf733a77bd4b28875078b53 Author: Rabin Vincent Date: Fri May 17 22:27:44 2013 +0200 tools lib lk: Respect CROSS_COMPILE Make lk use CROSS_COMPILE, in order to be able to cross compile perf again. Signed-off-by: Rabin Vincent Cc: Ingo Molnar Cc: Borislav Petkov Link: http://lkml.kernel.org/r/1368822464-4887-1-git-send-email-ra...@rab.in Signed-off-by: Arnaldo Carvalho de Melo Thanks. > > This is a quick fix for this problem. > > Signed-off-by: Joonsoo Kim > Cc: Ingo Molnar > Cc: Namhyung Kim > Cc: Paul Mackerras > Cc: Peter Zijlstra > Link: > http://lkml.kernel.org/r/1371603750-15053-2-git-send-email-iamjoonsoo@lge.com > Signed-off-by: Arnaldo Carvalho de Melo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] tracing: Miscellaneous fixes for trace_array ref counting
Some error paths did not handle ref counting properly, and some trace files need
ref counting.
Cc: Vaibhav Nagarnaik
Cc: David Sharp
Cc: Alexander Z Lam
Signed-off-by: Alexander Z Lam
---
kernel/trace/trace.c| 34 +++---
kernel/trace/trace_events.c | 21 +++--
2 files changed, 42 insertions(+), 13 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 0cd500b..ca2743b 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -3008,7 +3008,6 @@ static int tracing_release(struct inode *inode, struct
file *file)
iter = m->private;
tr = iter->tr;
- trace_array_put(tr);
mutex_lock(_types_lock);
@@ -3023,6 +3022,9 @@ static int tracing_release(struct inode *inode, struct
file *file)
if (!iter->snapshot)
/* reenable tracing if it was previously enabled */
tracing_start_tr(tr);
+
+ __trace_array_put(tr);
+
mutex_unlock(_types_lock);
mutex_destroy(>mutex);
@@ -3447,6 +3449,7 @@ tracing_trace_options_write(struct file *filp, const char
__user *ubuf,
static int tracing_trace_options_open(struct inode *inode, struct file *file)
{
struct trace_array *tr = inode->i_private;
+ int ret;
if (tracing_disabled)
return -ENODEV;
@@ -3454,7 +3457,11 @@ static int tracing_trace_options_open(struct inode
*inode, struct file *file)
if (trace_array_get(tr) < 0)
return -ENODEV;
- return single_open(file, tracing_trace_options_show, inode->i_private);
+ ret = single_open(file, tracing_trace_options_show, inode->i_private);
+ if (ret < 0)
+ trace_array_put(tr);
+
+ return ret;
}
static const struct file_operations tracing_iter_fops = {
@@ -3958,7 +3965,7 @@ static int tracing_open_pipe(struct inode *inode, struct
file *filp)
iter = kzalloc(sizeof(*iter), GFP_KERNEL);
if (!iter) {
ret = -ENOMEM;
- goto out;
+ goto fail_iter;
}
/*
@@ -3968,13 +3975,13 @@ static int tracing_open_pipe(struct inode *inode,
struct file *filp)
iter->trace = kmalloc(sizeof(*iter->trace), GFP_KERNEL);
if (!iter->trace) {
ret = -ENOMEM;
- goto fail;
+ goto fail_trace;
}
*iter->trace = *tr->current_trace;
if (!alloc_cpumask_var(>started, GFP_KERNEL)) {
ret = -ENOMEM;
- goto fail;
+ goto fail_trace;
}
/* trace pipe does not show start of buffer */
@@ -4001,9 +4008,10 @@ out:
mutex_unlock(_types_lock);
return ret;
-fail:
+fail_trace:
kfree(iter->trace);
kfree(iter);
+fail_iter:
__trace_array_put(tr);
mutex_unlock(_types_lock);
return ret;
@@ -4705,12 +4713,15 @@ static int tracing_snapshot_open(struct inode *inode,
struct file *file)
} else {
/* Writes still need the seq_file to hold the private data */
m = kzalloc(sizeof(*m), GFP_KERNEL);
- if (!m)
- return -ENOMEM;
+ if (!m) {
+ ret = -ENOMEM;
+ goto out;
+ }
iter = kzalloc(sizeof(*iter), GFP_KERNEL);
if (!iter) {
kfree(m);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto out;
}
iter->tr = tr;
iter->trace_buffer = >tr->max_buffer;
@@ -4718,7 +4729,7 @@ static int tracing_snapshot_open(struct inode *inode,
struct file *file)
m->private = iter;
file->private_data = m;
}
-
+out:
if (ret < 0)
trace_array_put(tr);
@@ -5328,9 +5339,10 @@ tracing_stats_read(struct file *filp, char __user *ubuf,
}
static const struct file_operations tracing_stats_fops = {
- .open = tracing_open_generic,
+ .open = tracing_open_generic_tc,
.read = tracing_stats_read,
.llseek = generic_file_llseek,
+ .release= tracing_release_generic_tc,
};
#ifdef CONFIG_DYNAMIC_FTRACE
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 7d85429..7a75cb2 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -1218,6 +1218,7 @@ show_header(struct file *filp, char __user *ubuf, size_t
cnt, loff_t *ppos)
static int ftrace_event_avail_open(struct inode *inode, struct file *file);
static int ftrace_event_set_open(struct inode *inode, struct file *file);
+static int ftrace_event_release(struct inode *inode, struct file *file);
static const struct seq_operations show_event_seq_ops = {
.start = t_start,
@@ -1245,7 +1246,7 @@ static const struct file_operations
[PATCH] kernel: trace: remove __init from race_selftest_startup_function() and trace_selftest_startup_function_graph()
Like other trace_selftest_startup_*, trace_selftest_startup_function()
and trace_selftest_startup_function_graph() need in normal section, or
may cause section mismatch.
The related warnings:
LD kernel/trace/built-in.o
WARNING: kernel/trace/built-in.o(.data+0x154c): Section mismatch in reference
from the variable function_trace to the function
.init.text:trace_selftest_startup_function()
The variable function_trace references
the function __init trace_selftest_startup_function()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
Signed-off-by: Chen Gang
---
kernel/trace/trace_selftest.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace_selftest.c b/kernel/trace/trace_selftest.c
index a7329b7..e341b9d 100644
--- a/kernel/trace/trace_selftest.c
+++ b/kernel/trace/trace_selftest.c
@@ -640,7 +640,7 @@ out:
* Enable ftrace, sleep 1/10 second, and then read the trace
* buffer to see if all is in order.
*/
-__init int
+int
trace_selftest_startup_function(struct tracer *trace, struct trace_array *tr)
{
int save_ftrace_enabled = ftrace_enabled;
@@ -734,7 +734,7 @@ static int trace_graph_entry_watchdog(struct
ftrace_graph_ent *trace)
* Pretty much the same than for the function tracer from which the selftest
* has been borrowed.
*/
-__init int
+int
trace_selftest_startup_function_graph(struct tracer *trace,
struct trace_array *tr)
{
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: rebase/rewrite of the renesas tree
On Thu, Jul 11, 2013 at 10:08:51AM +1000, Stephen Rothwell wrote: > Hi Simon, > > Why have you just rebased the renesas tree > (git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#next)? > You have just invalidated your testing and made it likely that your > upstream maintainers will blast you if you ask them to pull your tree > (though it is probably too late for v3.11 now anyway). Hi Stephen, I am not planning to send any pull requests for v3.11, at least not for the branches that I rebased. I can rewind the next branch if you like. If so, would rewinding it to the point it was at for next-20130709 make sense? Also, on this topic, could you clarify when it would be appropriate to do any rebasing. Obviously I am not clear on this. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: rebase of the device-mapper quilt series
Hi Alasdair, Why have you just rebased the device-mapper series (http://people.redhat.com/agk/patches/linux/editing/)? You have just invalidated your testing and made it likely that Linus will blast you if you ask him to pull your patches. Your whole series was already based after v3.10 (i.e. released or rebased after the merge window opened), so why move it again? -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpZU4xOA7SzK.pgp Description: PGP signature
Re: [PATCH] ACPI / scan: Always call acpi_bus_scan() for bus check notifications
On Wednesday, July 10, 2013 05:48:26 PM Toshi Kani wrote: > On Thu, 2013-07-11 at 00:45 +0200, Rafael J. Wysocki wrote: > > On Wednesday, July 10, 2013 02:11:05 AM Rafael J. Wysocki wrote: > > > On Tuesday, July 09, 2013 01:32:42 PM Toshi Kani wrote: > > > > On Mon, 2013-07-08 at 02:10 +0200, Rafael J. Wysocki wrote: > > > > > From: Rafael J. Wysocki > > > > > > > > > > An ACPI_NOTIFY_BUS_CHECK notification means that we should scan the > > > > > entire namespace starting from the given handle even if the device > > > > > represented by that handle is present (other devices below it may > > > > > just have been added). > > > > > > > > > > For this reason, modify acpi_scan_bus_device_check() to always run > > > > > acpi_bus_scan() if the notification being handled is of type > > > > > ACPI_NOTIFY_BUS_CHECK. > > > > > > > > > > Signed-off-by: Rafael J. Wysocki > > > > > Cc: 3.10+ > > > > > > > > Acked-by: Toshi Kani > > > > > > > > But, I think we need the additional patch below. > > > > > > Yes, I think you're right. > > > > That said I'd prefer to put the check into acpi_bus_device_attach() like in > > the appended patch. > > That's fine by me. > > Acked-by: Toshi Kani > > Just a minor point, though. Isn't it a bit inconsistent with > device_attach(), which checks dev->driver inside the function? Well, device_attach() may be called from different places while this is the only place where acpi_scan_attach_handler() is called. The check in acpi_bus_device_attach() is easier to follow to me, because it clearly means "we don't need to do anything more if there's a handler", while the check in acpi_scan_attach_handler() makes you wonder "why do we need to return 1 in that case?" and then you need to go to the caller and look at the check of the return value to see "ah, because we don't want that device_attach() to be called then!". > That said, I am OK with either way. Cool. :-) Thanks, Rafael > > --- > > From: Rafael J. Wysocki > > Subject: ACPI / scan: Do not try to attach scan handlers to devices having > > them > > > > In acpi_bus_device_attach(), if there is an ACPI device object > > for the given handle and that device object has a scan handler > > attached to it already, there's nothing more to do for that handle > > and the function should just return success immediately. Make > > that happen. > > > > Reported-by: Toshi Kani > > Signed-off-by: Rafael J. Wysocki > > --- > > drivers/acpi/scan.c |3 +++ > > 1 file changed, 3 insertions(+) > > > > Index: linux-pm/drivers/acpi/scan.c > > === > > --- linux-pm.orig/drivers/acpi/scan.c > > +++ linux-pm/drivers/acpi/scan.c > > @@ -1984,6 +1984,9 @@ static acpi_status acpi_bus_device_attac > > if (acpi_bus_get_device(handle, )) > > return AE_CTRL_DEPTH; > > > > + if (device->handler) > > + return AE_OK; > > + > > ret = acpi_scan_attach_handler(device); > > if (ret) > > return ret > 0 ? AE_OK : AE_CTRL_DEPTH; > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: rebase of the jdelvare-hwmon quilt series
Hi Jean, Why have you just rebased the jdelvare-hwmon series (http://khali.linux-fr.org/devel/linux-3/jdelvare-hwmon/)? You have just invalidated your testing and made it likely that Linus will blast you if you ask him to pull your patches. Your whole series was already based after v3.10 (i.e. released or rebased after the merge window opened), so why move it again? -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpBAR9uNGOG_.pgp Description: PGP signature
Re: [PATCH 1/1] linux-firmware: Add AMD microcode patch firmware files
On 07/03/2013 09:56 PM, Ben Hutchings wrote: On Fri, 2013-06-28 at 14:27 -0500, Sherry Hurwitz wrote: For AMD Families 10h ~ 14h Processors file: amd-ucode/microcode_amd.bin md5sum: 55ae79b82cbfddcf7142058be3c9ec2d For AMD Family 15h Processors file: amd-ucode/microcode_amd_fam15h.bin md5sum: 122ac7e56442c2b7c28eb26978b2d57c Signed-off-by: Sherry Hurwitz --- LICENSE.amd-ucode | 64 WHENCE |9 + amd-ucode/microcode_amd.bin| Bin 0 -> 12684 bytes amd-ucode/microcode_amd_fam15h.bin | Bin 0 -> 7876 bytes 4 files changed, 73 insertions(+) create mode 100644 LICENSE.amd-ucode create mode 100644 amd-ucode/microcode_amd.bin create mode 100644 amd-ucode/microcode_amd_fam15h.bin [...] --- a/WHENCE +++ b/WHENCE @@ -2169,3 +2169,12 @@ File: go7007/wis-startrek.fw Licence: Redistributable. See LICENCE.go7007_firmware for details -- + +Driver: microcode_amd - AMD CPU Microcode Update Driver for Linux + +File: amd-ucode/microcode_amd.bin +File: amd-ucode/microcode_amd_fam15h.bin + +License: Redistributable. See LICENSE.amd-ucode for details [...] Please include the version number. I notice that the download page on amd64.org also has GPG signatures. Perhaps those should be included too? (Actually, I would like to see verifiable signatures on all binary firmware, but I don't think that can be made a requirement any time soon. Key 9F94BC90 isn't signed by another published key, so I still have no reason to trust its identity.) Ben. The amd64.org site is down and will no longer be used for distributing AMD microcode patches. Therefore, the Key ID 9F94BC90 will no longer be used to sign the future microcode container files. A new key will be created and signed by me and another AMD co-worker. We will resend the patch with the Key ID 8C0108B4. You can pull this key from the gnuPG key server to verify and see it is signed by two other keys, one belonging to me and the other by Suravee Suthikulpanit, with AMD email addresses. Sherry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sysfs: add support for binary attributes in groups
On Wed, Jul 10, 2013 at 04:59:28PM -0700, Greg Kroah-Hartman wrote:
> On Wed, Jul 10, 2013 at 04:00:57PM -0700, Guenter Roeck wrote:
> > > + for (bin_attr = grp->bin_attrs; *bin_attr; bin_attr++) {
> >
> > What happens here if grp->bin_attrs is NULL ? Doesn't that cause a NULL
> > reference when accessing *bin_attr ?
> >
> > [ The problem didn't exist before since attr was supposed to be non-NULL.
> > It may now be a problem if only bin_attr is provided, ie if there are
> > only binary attribute files.
> > Or maybe I am just tired and there is no problem... ]
>
> I thought I tested this patch out, but I think you are right, let me go
> do a rebuild and test it again...
You were right, good catch, as-is, the kernel dies at boot, I've fixed
this and will resend the series, thanks so much for the review.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC V9 0/19] Paravirtualized ticket spinlocks
Gleb Natapov wrote: >On Wed, Jul 10, 2013 at 11:03:15AM -0400, Konrad Rzeszutek Wilk wrote: >> On Wed, Jul 10, 2013 at 01:47:17PM +0300, Gleb Natapov wrote: >> > On Wed, Jul 10, 2013 at 12:40:47PM +0200, Peter Zijlstra wrote: >> > > On Wed, Jul 10, 2013 at 01:33:25PM +0300, Gleb Natapov wrote: >> > > >> > > Here's an idea, trim the damn email ;-) -- not only directed at >gleb. >> > > >> > Good idea. >> > >> > > > > Ingo, Gleb, >> > > > > >> > > > > From the results perspective, Andrew Theurer, Vinod's test >results are >> > > > > pro-pvspinlock. >> > > > > Could you please help me to know what will make it a >mergeable >> > > > > candidate?. >> > > > > >> > > > I need to spend more time reviewing it :) The problem with PV >interfaces >> > > > is that they are easy to add but hard to get rid of if better >solution >> > > > (HW or otherwise) appears. >> > > >> > > How so? Just make sure the registration for the PV interface is >optional; that >> > > is, allow it to fail. A guest that fails the PV setup will either >have to try >> > > another PV interface or fall back to 'native'. >> > > >> > We have to carry PV around for live migration purposes. PV >interface >> > cannot disappear under a running guest. >> >> Why can't it? This is the same as handling say XSAVE operations. Some >hosts >> might have it - some might not. It is the job of the toolstack to >make sure >> to not migrate to the hosts which don't have it. Or bound the guest >to the >> lowest interface (so don't enable the PV interface if the other hosts >in the >> cluster can't support this flag)? >XSAVE is HW feature and it is not going disappear under you after >software >upgrade. Upgrading kernel on part of your hosts and no longer been >able to migrate to them is not something people who use live migration >expect. In practise it means that updating all hosts in a datacenter to >newer kernel is no longer possible without rebooting VMs. > >-- > Gleb. I see. Perhaps then if the hardware becomes much better at this then another PV interface can be provided which will use the static_key to turn off the PV spin lock and use the bare metal version (or perhaps some forms of super ellision locks). That does mean the host has to do something when this PV interface is invoked for the older guests. Anyhow that said I think the benefits are pretty neat right now and benefit much and worrying about whether the hardware vendors will provide something new is not benefiting users. What perhaps then needs to be addressed is how to have an obsolete mechanism in this if the hardware becomes superb? -- Sent from my Android phone. Please excuse my brevity. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next v3 0/3] net: finish renaming lls to busy poll
From: Eliezer Tamir
Date: Wed, 10 Jul 2013 17:13:07 +0300
> Here are three patches that complete the rename of lls to busy-poll
>
> 1. rename include/net/ll_poll.h to include/net/busy_poll.h
> 2. Rename ndo_ll_poll to ndo_busy_poll.
>Rename sk_mark_ll to sk_mark_napi_id.
>Rename skb_mark_ll to skb_mark_napi_id.
>Correct all useres of these functions.
>Update comments and defines in include/net/busy_poll.h
> 3. Rename LL_SO to BUSY_POLL_SO
>Rename sysctl_net_ll_{read,poll} to sysctl_busy_{read,poll}
>Fix up users of these variables.
>Fix documentation for sysctl.
>
> v2 fixed forgetting the ndo changes in v1
> v3 is a resend with -M
Series applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: rebase/rewrite of the renesas tree
Hi Simon, Why have you just rebased the renesas tree (git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#next)? You have just invalidated your testing and made it likely that your upstream maintainers will blast you if you ask them to pull your tree (though it is probably too late for v3.11 now anyway). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp1dJmZzxtkw.pgp Description: PGP signature
Re: [RFC] [PATCH 0/2] x86: make jump labels use int3-based breakpoint instead of stop_machine()
On Wed, 10 Jul 2013, Jason Baron wrote:
> > this is a resurrection of a few years old idea to have jump labels use
> > synchronization based on int3 breakpoint rather than relying on
> > stop_machine() with all the consequences.
> >
> > ftrace has been doing exactly this kind of patching for year since
> > 08d636b6 ("ftrace/x86: Have arch x86_64 use breakpoints instead of stop
> > machine").
> >
> > This patchset first introduces generic text_poke_bp() that provides means
> > to perform this method of patching in parallel to text_poke_smp(), and
> > then converts x86 jump label code to use it.
> >
> > If this is merged, I'll do a followup patch converting ftrace to use this
> > infrastructure as well, as it's doing the same thing in principle already.
> >
> > Comments welcome.
> >
>
> Cool. This definitely an area I've wanted to improve with jump labels.
>
> Perhaps, ftrace should be considered at this point to make sure the
> interface is suitable for both callers?
Yeah, Steven is CCed. From my understanding of the code, ftrace is
actually doing exactly what I have done for jump labels in 2/2, i.e. in
case the breakpoint is triggered, ftrace implicitly behaves like if "nop"
was the instruction that has been executed.
I even have preliminary (completely untested) patch, but would like to
have this merged/acked in the first round before proceeding with porting
ftrace to the new interface.
> Also, I wonder if its worth batching up updates. For example, right now
> we simply update each call-site one at a time even if its associated
> with the same control variable.
That does seem to make sense indeed, but it's not really closely tied to
this patchset, is it?
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: rebase of the drivers-x86 tree
Hi Matthew, Why have you just rebased the drivers-x86 tree (git://cavan.codon.org.uk/platform-drivers-x86.git#linux-next)? You have just invalidated your testing and made it likely that Linus will blast you if you ask him to pull your tree. Your whole tree was already based after v3.10 (i.e. released or rebased after the merge window opened), so why move it again? -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpxPeeznXyk_.pgp Description: PGP signature
[GIT PULL] target updates for v3.11-rc1
Hello Linus! Here are the target pending patches for the v3.11-rc1 merge window. Please go ahead and pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next Lots of activity this round on performance improvements in target-core while benchmarking the prototype scsi-mq initiator code with vhost-scsi fabric ports, along with a number of iscsi/iser-target improvements and hardening fixes for exception path cases post v3.10 merge. The highlights include: - Make persistent reservations APTPL buffer allocated on-demand, and drop per t10_reservation buffer. (grover) - Make virtual LUN=0 a NULLIO device, and skip allocation of NULLIO device pages (grover) - Add transport_cmd_check_stop write_pending bit to avoid extra access of ->t_state_lock is WRITE I/O submission fast-path. (nab) - Drop unnecessary CMD_T_DEV_ACTIVE check from transport_lun_remove_cmd to avoid extra access of ->t_state_lock in release fast-path. (nab) - Avoid extra t_state_lock access in __target_execute_cmd fast-path (nab) - Drop unnecessary vhost-scsi wait_for_tasks=true usage + ->t_state_lock access in release fast-path. (nab) - Convert vhost-scsi to use modern se_cmd->cmd_kref TARGET_SCF_ACK_KREF usage (nab) - Add tracepoints for SCSI commands being processed (roland) - Refactoring of iscsi-target handling of ISCSI_OP_NOOP + ISCSI_OP_TEXT to be transport independent (nab) - Add iscsi-target SendTargets=$IQN support for in-band discovery (nab) - Add iser-target support for in-band discovery (nab + Or) - Add iscsi-target demo-mode TPG authentication context support (nab) - Fix isert_put_reject payload buffer post (nab) - Fix iscsit_add_reject* usage for iser (nab) - Fix iscsit_sequence_cmd reject handling for iser (nab) - Fix ISCSI_OP_SCSI_TMFUNC handling for iser (nab) - Fix session reset bug with RDMA_CM_EVENT_DISCONNECTED (nab) The last five iscsi/iser-target items are CC'ed to stable, as they do address issues present in v3.10 code. They are certainly larger than I'd like for stable patch set, but are important to ensure proper REJECT exception handling in iser-target for 3.10.y. Also just a heads up to expect a minor conflict in drivers/vhost/scsi.c when pulling vhost-next (MST CC'ed) that has come up recently in linux-next testing here: http://marc.info/?l=linux-next=137331470429528=2 Thank you, --nab Andy Grover (13): target: Add register_type and preempt_type enums to clarify code target: Alter core_pr_dump_initiator_port for ease of use target: Fix two debugprints that appear to be wrong target: Simplify metadata handling when clearing aptpl metadata target: Unify __core_scsi3_update_aptpl_buf and core_scsi3_update_aptpl_buf target: Remove t10_reservation.pr_aptpl_buf_len target: Remove unneeded param pr_aptpl_buf_len to write_aptpl_to_file() target: Delete incorrect comment target: Allocate aptpl_buf inside update_and_write_aptpl() target: Use if/else for sa_res_key conditional in emulate_pro_register() target: Further refactoring of core_scsi3_emulate_pro_register() target: Make virtual_lun0 a nullio device target: Don't allocate pages for NULLIO devices Dan Carpenter (1): iscsi-target: missing kfree() on error path Joern Engel (2): target: remove unused codes from enum tcm_tmrsp_table target: make queue_tm_rsp() return void Jörn Engel (3): qla_target: remove qlt_check_fcport_exist iscsi-target: Fix tfc_tpg_nacl_auth_cit configfs length overflow iscsi-target: kstrtou* configfs attribute parameter cleanups Nicholas Bellinger (29): target: Add transport_cmd_check_stop write_pending bit target: Drop unnecessary CMD_T_DEV_ACTIVE check from transport_lun_remove_cmd target: Remove legacy t_fe_count + avoid t_state_lock access in transport_put_cmd target: Avoid extra t_state_lock access in __target_execute_cmd target: Drop unnecessary t_state_lock access for SCF_SUPPORTED_SAM_OPCODE assignment iscsi-target: Avoid unnecessary t_state_lock during unsolicited data-out check target: Drop legacy se_cmd->check_release bit vhost/scsi: Drop unnecessary wait_for_tasks=true usage with transport_generic_free_cmd vhost/scsi: Convert to se_cmd->cmd_kref TARGET_SCF_ACK_KREF usage iscsi/isert-target: Refactor ISCSI_OP_NOOP RX handling iscsi-target: Refactor ISCSI_OP_TEXT RX handling iscsi-target: Refactor ISCSI_OP_TEXT_RSP TX handling iscsi-target: Allow ->MaxXmitDataSegmentLength assignment for iser discovery iscsi-target: Move sendtargets parsing into iscsit_process_text_cmd iscsi-target: Add IFC_SENDTARGETS_SINGLE support target: Add se_portal_group->tpg_auth_group iscsi-target: Add demo-mode TPG authentication context support target: Make core_scsi3_update_and_write_aptpl return sense_reason_t iscsi-target: Drop left-over iscsi_conn->bad_hdr iser-target: Fix isert_put_reject payload buffer post iscsi-target: Fix
Re: [PATCH] usb: phy: samsung-usb2: Toggle HSIC GPIO from device tree
Hi Julius, On Wed, Jul 10, 2013 at 2:42 PM, Julius Werner wrote: > Hi Felipe, > > This is intended to pull down a reset signal line, not to switch power > to the device. I could implement that with the regulator framework > too, but I think that would just be confusing and harder to understand > without providing any benefit. It's really just a plain old GPIO. It seems that the reset gpio driver from Phillip Zabel would help in this case: http://permalink.gmane.org/gmane.linux.drivers.devicetree/36830 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: rebase of lblnet tree
Hi Paul, Why have you just rebased the lblnet tree (git://git.infradead.org/users/pcmoore/lblnet-2.6_next#master)? You have just invalidated your testing and made it likely that Linus will blast you if you ask him to pull your tree. Your whole tree was already based after v3.10 (i.e. released or rebased after the merge window opened), so why move it again? -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpMbk87TFLip.pgp Description: PGP signature
Re: [PATCH 5/6] sysfs: add support for binary attributes in groups
On Wed, Jul 10, 2013 at 04:00:57PM -0700, Guenter Roeck wrote:
> On Wed, Jul 10, 2013 at 01:05:13PM -0700, Greg Kroah-Hartman wrote:
> > @@ -52,6 +55,17 @@ static int create_files(struct sysfs_dirent *dir_sd,
> > struct kobject *kobj,
> > }
> > if (error)
> > remove_files(dir_sd, kobj, grp);
>
> You might want to abort here if there was an error.
Good point, I'll update it.
> > +
> > + for (bin_attr = grp->bin_attrs; *bin_attr; bin_attr++) {
>
> What happens here if grp->bin_attrs is NULL ? Doesn't that cause a NULL
> reference when accessing *bin_attr ?
>
> [ The problem didn't exist before since attr was supposed to be non-NULL.
> It may now be a problem if only bin_attr is provided, ie if there are
> only binary attribute files.
> Or maybe I am just tired and there is no problem... ]
I thought I tested this patch out, but I think you are right, let me go
do a rebuild and test it again...
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Bisected] 3.7-rc1 can't resume (still present in 3.9)
On 07/10/2013 01:52 PM, Christian Sünkenberg wrote: > Hello, > > On 05/01/2013 07:33 PM, H. Peter Anvin wrote: >> On 05/01/2013 10:01 AM, Jonas Heinrich wrote: >>> Hello, I tried the newest kernel, 3.9 today but the bug is still >>> present. Applying the attached patch solves the bug for me. >>> >>> Best regards, Jonas Heinrich >> >> Okay... WTF is going on here? Does pmode_behavior just not get set up >> correctly? Since it seems you can get it to wake up with your patch, >> perhaps we can get read out the value of pmode_behavior and print it... > > indeed, arch/x86/kernel/acpi/sleep.c tries an rdmsr_safe(MSR_EFER, ...) > and sets WAKEUP_BEHAVIOR_RESTORE_EFER bit on success, however, > on 90 nm Pentium M (Family 6, Model 13), reading an invalid MSR > is not guaranteed to trap, see Erratum X4 in "Intel® Pentium® M > Processor on 90 nm Process with 2-MB L2 Cache and Intel® Processor A100 > and A110 on 90 nm process with 512-KB L2 Cache Specification Update". > On Jonas' T43, which has an affected Pentium M without EFER, > rdmsr_safe(MSR_EFER, ...) succeeds and WAKEUP_BEHAVIOR_RESTORE_EFER > gets set, while on resume the corresponding wrmsr traps and thus resume > fails. > > The pre-3.7 code snippet incidentally catched this by not restoring > EFER when it would be restored to all 0s. > That does seem like a reasonable explanation. Does this patch fix the problem? (Comment blatantly ripped off from your email message.) -hpa diff --git a/arch/x86/kernel/acpi/sleep.c b/arch/x86/kernel/acpi/sleep.c index b44577b..927c5ce 100644 --- a/arch/x86/kernel/acpi/sleep.c +++ b/arch/x86/kernel/acpi/sleep.c @@ -48,9 +48,20 @@ int acpi_suspend_lowlevel(void) #ifndef CONFIG_64BIT native_store_gdt((struct desc_ptr *)>pmode_gdt); + /* +* We have to check that we can write back the value, and not +* just read it. At least on 90 nm Pentium M (Family 6, Model +* 13), reading an invalid MSR is not guaranteed to trap, see +* Erratum X4 in "Intel Pentium M Processor on 90 nm Process +* with 2-MB L2 Cache and Intel® Processor A100 and A110 on 90 +* nm process with 512-KB L2 Cache Specification Update". +*/ if (!rdmsr_safe(MSR_EFER, >pmode_efer_low, - >pmode_efer_high)) + >pmode_efer_high) && + !wrmsr_safe(MSR_EFER, + header->pmode_efer_low, + header->pmode_efer_high)) header->pmode_behavior |= (1 << WAKEUP_BEHAVIOR_RESTORE_EFER); #endif /* !CONFIG_64BIT */
Re: [PATCH] fs: sync: fixed performance regression
On Wed, Jul 10, 2013 at 04:12:36PM -0700, Paul Taysom wrote: > Note, when running the test, the slow down doesn't always happen > but most of the tests will show a slow down. > > In response to crbug.com/240422 Just in case this ends up as the actual commit msg, that url seems to be the wrong bug. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] kexec: return error of machine_kexec() fails
On Wed, Jul 10, 2013 at 01:42:17PM -0700, Eric W. Biederman wrote: > I meant code not hardware architecture. We keep having code thrown in > the the shutdown paths because ARM only supports cpu shutdown via cpu > hotunplug and cpu hotunplug is not universally available. > > That is a software architecture BUG with the ARM kernels. There are many problems here: 1) if you can't place a CPU individually into reset, what do you do with it over a kexec? Once woken it executes code. It will never stop executing code. If you place it inside an infinite loop in the existing kernel, and then overwrite it, it will then start executing the instructions there when the new kernel broadcasts the cache flushes, and it will start executing whatever code is there. 2) if the CPU itself needs to execute code to shut itself down, how do you get it to do that on a crash-based kexec when IPI broadcasts may not work? 3) what about situations where you need the requestor to also do something to shut down the secondary CPU? Taking CPUs offline is not an easy thing to do when every platform plays their own games with doing that, and then you have security crap that gets in the way too, with the security crap having platform specific interfaces. CPU hotplug is by far the best solution we have to this mess. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: phy: samsung-usb2: Toggle HSIC GPIO from device tree
On Wednesday, July 10, 2013 9:34 AM, Julius Werner wrote:
>
> This patch adds support for a new 'samsung,hsic-reset-gpio' in the
> device tree, which will be interpreted as an active-low reset pin during
> PHY initialization when it exists. Useful for intergrated HSIC devices
> like an SMSC 3503 hub. It is necessary to add this directly to the PHY
> initialization to get the timing right, since resetting a HSIC device
> after it has already been enumerated can confuse the USB stack.
>
> Also fixes PHY semaphore code to make sure we always go through the
> setup at least once, even if it was already turned on (e.g. by
> firmware), and changes a spinlock to a mutex to allow sleeping in the
> critical section.
CC'ed Thomas Abraham,
This reset signal pin seems 'HUB_RESET' pin to reset SMSC 3503 hub
on Arndale board. This reset pin is described that 'This active low signal
is used by the system to reset the chip' in SMSC 3503 hub datasheet.
One more thing,
'phy-samsung-usb*.c' files are used and designed to control USB PHY controller
in Exynos SoCs; thus, these files should control only internal USB PHY
controller
in Exynos SoCs.
However, the reset pin is used for reset external SMSC 3503 hub chip
that is not placed in Exynos SoC.
Thus, there should not be HUB reset code
in ./drivers/usb/phy/phy-samsung-usb*.c
This topic was already discussed one month ago.
As Olof Johansson mentioned, 'drivers/platform/arm/' would be
a good alternative; thus, USB hub reset code should be moved
to 'drivers/platform/arm/'. Please refer to the discussion.
(http://patches.linaro.org/16856/)
Best regards,
Jingoo Han
>
> Change-Id: Ieecac52c27daa7a17a7ed3b2863ddba3aeb8d16f
> Signed-off-by: Julius Werner
> ---
> .../devicetree/bindings/usb/samsung-usbphy.txt | 10 ++
> drivers/usb/phy/phy-samsung-usb.c | 17 ++
> drivers/usb/phy/phy-samsung-usb.h | 7 ++--
> drivers/usb/phy/phy-samsung-usb2.c | 38
> ++
> drivers/usb/phy/phy-samsung-usb3.c | 12 +++
> 5 files changed, 55 insertions(+), 29 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
> b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
> index 33fd354..82e2e16 100644
> --- a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
> +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
> @@ -31,6 +31,12 @@ Optional properties:
> - ranges: allows valid translation between child's address space and parent's
> address space.
>
> +- samsung,hsic-reset-gpio: an active low GPIO pin that resets a device
> + connected to the HSIC port. Useful for things like
> + an on-board SMSC3503 hub.
> +- pinctrl-0: Pin control group containing the HSIC reset GPIO pin.
> +- pinctrl-names: Should contain only one value - "default".
> +
> - The child node 'usbphy-sys' to the node 'usbphy' is for the system
> controller
>interface for usb-phy. It should provide the following information
> required by
>usb-phy controller to control phy.
> @@ -56,6 +62,10 @@ Example:
> clocks = < 2>, < 305>;
> clock-names = "xusbxti", "otg";
>
> + samsung,hsic-reset-gpio = < 4 1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_reset>;
> +
> usbphy-sys {
> /* USB device and host PHY_CONTROL registers */
> reg = <0x10020704 0x8>;
> diff --git a/drivers/usb/phy/phy-samsung-usb.c
> b/drivers/usb/phy/phy-samsung-usb.c
> index ac025ca..23f1d70 100644
> --- a/drivers/usb/phy/phy-samsung-usb.c
> +++ b/drivers/usb/phy/phy-samsung-usb.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "phy-samsung-usb.h"
> @@ -58,6 +59,22 @@ int samsung_usbphy_parse_dt(struct samsung_usbphy *sphy)
> if (sphy->sysreg == NULL)
> dev_warn(sphy->dev, "Can't get usb-phy sysreg cfg register\n");
>
> + /*
> + * Some boards have a separate active-low reset GPIO for their HSIC USB
> + * devices. If they don't, this will just stay at an invalid value and
> + * the init code will ignore it.
> + */
> + sphy->hsic_reset_gpio = of_get_named_gpio(sphy->dev->of_node,
> + "samsung,hsic-reset-gpio", 0);
> + if (gpio_is_valid(sphy->hsic_reset_gpio)) {
> + if (devm_gpio_request_one(sphy->dev, sphy->hsic_reset_gpio,
> + GPIOF_OUT_INIT_LOW, "samsung_hsic_reset")) {
> + dev_err(sphy->dev, "can't request hsic reset gpio %d\n",
> + sphy->hsic_reset_gpio);
> + sphy->hsic_reset_gpio = -EINVAL;
> + }
> + }
> +
> of_node_put(usbphy_sys);
>
> return 0;
> diff --git a/drivers/usb/phy/phy-samsung-usb.h
>
Re: [PATCH] ACPI / scan: Always call acpi_bus_scan() for bus check notifications
On Thu, 2013-07-11 at 00:45 +0200, Rafael J. Wysocki wrote: > On Wednesday, July 10, 2013 02:11:05 AM Rafael J. Wysocki wrote: > > On Tuesday, July 09, 2013 01:32:42 PM Toshi Kani wrote: > > > On Mon, 2013-07-08 at 02:10 +0200, Rafael J. Wysocki wrote: > > > > From: Rafael J. Wysocki > > > > > > > > An ACPI_NOTIFY_BUS_CHECK notification means that we should scan the > > > > entire namespace starting from the given handle even if the device > > > > represented by that handle is present (other devices below it may > > > > just have been added). > > > > > > > > For this reason, modify acpi_scan_bus_device_check() to always run > > > > acpi_bus_scan() if the notification being handled is of type > > > > ACPI_NOTIFY_BUS_CHECK. > > > > > > > > Signed-off-by: Rafael J. Wysocki > > > > Cc: 3.10+ > > > > > > Acked-by: Toshi Kani > > > > > > But, I think we need the additional patch below. > > > > Yes, I think you're right. > > That said I'd prefer to put the check into acpi_bus_device_attach() like in > the appended patch. That's fine by me. Acked-by: Toshi Kani Just a minor point, though. Isn't it a bit inconsistent with device_attach(), which checks dev->driver inside the function? That said, I am OK with either way. Thanks, -Toshi > > Thanks, > Rafael > > > --- > From: Rafael J. Wysocki > Subject: ACPI / scan: Do not try to attach scan handlers to devices having > them > > In acpi_bus_device_attach(), if there is an ACPI device object > for the given handle and that device object has a scan handler > attached to it already, there's nothing more to do for that handle > and the function should just return success immediately. Make > that happen. > > Reported-by: Toshi Kani > Signed-off-by: Rafael J. Wysocki > --- > drivers/acpi/scan.c |3 +++ > 1 file changed, 3 insertions(+) > > Index: linux-pm/drivers/acpi/scan.c > === > --- linux-pm.orig/drivers/acpi/scan.c > +++ linux-pm/drivers/acpi/scan.c > @@ -1984,6 +1984,9 @@ static acpi_status acpi_bus_device_attac > if (acpi_bus_get_device(handle, )) > return AE_CTRL_DEPTH; > > + if (device->handler) > + return AE_OK; > + > ret = acpi_scan_attach_handler(device); > if (ret) > return ret > 0 ? AE_OK : AE_CTRL_DEPTH; > > -- > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] DRM: use anon_inode instead of delayed inode init
Instead of delaying inode initialization until first ->open(), we can use
an anonymous inode. This avoids modifying FS internal inode fields and
provides us a private address_space right during initialization.
Delayed TTM dev_mapping initialization is currently left untouched to keep
this simple. But we could now safely provide the address_space during
ttm_bo_device_init() instead of delaying until first buffer ->mmap().
Note that this also fixes several bugs:
- We currently call iput(container_of(..dev_mapping..)) before
drm_lastclose(), but we reset dev_mapping to zero at the end of
drm_lastclose(). This fails if dev_mapping points to an address_space
other than the current inode and the char-dev got already removed.
- We also drop dev_mapping during any drm_lastclose() call. So if
user-space still has VMAs to our buffers, we will be unable to unmap
them if the next ->firstopen() is on another inode. dev_mapping will
then point to a new address_space and we leak mappings that we no
longer control.
- We ignore inode->i_mapping completely. It is unlikely that a FS uses it
to overwrite inode->i_data for char-devs, but it definitely doesn't
look very nice to ignore it silently.
Regarding legacy drivers: We no longer reset the address_space during
drm_lastclose() to avoid re-allocating inodes all the time. However,
legacy UMS drivers are weird and it is not clear to me whether some of the
old drivers might depend on this (for what reason?), but I remember Daniel
told me that i810 might.
Tested with nouveau on x86_64.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_drv.c | 1 -
drivers/gpu/drm/drm_fops.c | 24 +++-
drivers/gpu/drm/drm_stub.c | 12 +++-
drivers/gpu/drm/i915/i915_gem.c| 4 ++--
drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
drivers/gpu/drm/omapdrm/omap_gem.c | 7 ---
drivers/gpu/drm/qxl/qxl_object.c | 2 +-
drivers/gpu/drm/qxl/qxl_ttm.c | 2 +-
drivers/gpu/drm/radeon/radeon_object.c | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 2 +-
include/drm/drmP.h | 2 +-
12 files changed, 27 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 99fcd7c..9797613 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -232,7 +232,6 @@ int drm_lastclose(struct drm_device * dev)
!drm_core_check_feature(dev, DRIVER_MODESET))
drm_dma_takedown(dev);
- dev->dev_mapping = NULL;
mutex_unlock(>struct_mutex);
DRM_DEBUG("lastclose completed\n");
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 3a24385..6752f59 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -122,8 +122,6 @@ int drm_open(struct inode *inode, struct file *filp)
struct drm_minor *minor;
int retcode = 0;
int need_setup = 0;
- struct address_space *old_mapping;
- struct address_space *old_imapping;
minor = idr_find(_minors_idr, minor_id);
if (!minor)
@@ -137,16 +135,9 @@ int drm_open(struct inode *inode, struct file *filp)
if (!dev->open_count++)
need_setup = 1;
- mutex_lock(>struct_mutex);
- old_imapping = inode->i_mapping;
- old_mapping = dev->dev_mapping;
- if (old_mapping == NULL)
- dev->dev_mapping = >i_data;
- /* ihold ensures nobody can remove inode with our i_data */
- ihold(container_of(dev->dev_mapping, struct inode, i_data));
- inode->i_mapping = dev->dev_mapping;
- filp->f_mapping = dev->dev_mapping;
- mutex_unlock(>struct_mutex);
+
+ /* set address_space for shared mappings */
+ filp->f_mapping = dev->anon_inode->i_mapping;
retcode = drm_open_helper(inode, filp, dev);
if (retcode)
@@ -160,12 +151,6 @@ int drm_open(struct inode *inode, struct file *filp)
return 0;
err_undo:
- mutex_lock(>struct_mutex);
- filp->f_mapping = old_imapping;
- inode->i_mapping = old_imapping;
- iput(container_of(dev->dev_mapping, struct inode, i_data));
- dev->dev_mapping = old_mapping;
- mutex_unlock(>struct_mutex);
dev->open_count--;
return retcode;
}
@@ -543,9 +528,6 @@ int drm_release(struct inode *inode, struct file *filp)
}
}
- BUG_ON(dev->dev_mapping == NULL);
- iput(container_of(dev->dev_mapping, struct inode, i_data));
-
/* drop the reference held my the file priv */
drm_master_put(_priv->master);
file_priv->is_master = 0;
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 327ca19..45804f1 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -31,6 +31,7 @@
* DEALINGS IN THE SOFTWARE.
*/
+#include
#include
#include
[PATCH 1/2] anon_inodes: allow external inode allocations
DRM core shares a single address_space across all inodes that belong to
the same DRM device. This allows efficient unmapping of user-space
mappings during buffer destruction. However, there is no easy way to get a
shared address_space for DRM devices during initialization. Therefore, we
currently delay this step until the first ->open() and save the given
inode for future use.
This causes ugly delayed initialization throughout the DRM core. TTM
devices end up without a dev_mapping pointer and we have to carefully
respect any underlying filesystem implementation so we don't corrupt the
inode->i_mapping and inode->i_data fields.
We can avoid this if we were allowed to allocate an anonymous inode for
each DRM device. We only have to set file->f_mapping during ->open()
and no longer need to adjust inode mappings. As fs/anon_inodes.c already
provides a minimal internal FS mount, we extend it to also provide
anonymous inodes for use in drivers like DRM.
Signed-off-by: David Herrmann
---
fs/anon_inodes.c| 36 +---
include/linux/anon_inodes.h | 1 +
2 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c
index 47a65df..7d8a80a 100644
--- a/fs/anon_inodes.c
+++ b/fs/anon_inodes.c
@@ -25,6 +25,7 @@
static struct vfsmount *anon_inode_mnt __read_mostly;
static struct inode *anon_inode_inode;
static const struct file_operations anon_inode_fops;
+static struct dentry *anon_inode_root;
/*
* anon_inodefs_dname() is called from d_path().
@@ -87,19 +88,18 @@ static struct inode *anon_inode_mkinode(struct super_block
*s)
static struct dentry *anon_inodefs_mount(struct file_system_type *fs_type,
int flags, const char *dev_name, void *data)
{
- struct dentry *root;
- root = mount_pseudo(fs_type, "anon_inode:", NULL,
+ anon_inode_root = mount_pseudo(fs_type, "anon_inode:", NULL,
_inodefs_dentry_operations, ANON_INODE_FS_MAGIC);
- if (!IS_ERR(root)) {
- struct super_block *s = root->d_sb;
+ if (!IS_ERR(anon_inode_root)) {
+ struct super_block *s = anon_inode_root->d_sb;
anon_inode_inode = anon_inode_mkinode(s);
if (IS_ERR(anon_inode_inode)) {
- dput(root);
+ dput(anon_inode_root);
deactivate_locked_super(s);
- root = ERR_CAST(anon_inode_inode);
+ anon_inode_root = ERR_CAST(anon_inode_inode);
}
}
- return root;
+ return anon_inode_root;
}
static struct file_system_type anon_inode_fs_type = {
@@ -219,6 +219,28 @@ err_put_unused_fd:
}
EXPORT_SYMBOL_GPL(anon_inode_getfd);
+/**
+ * anon_inode_new - create private anonymous inode
+ *
+ * Creates a new inode on the anonymous inode FS for driver's use. The inode
has
+ * it's own address_space compared to the shared anon_inode_inode. It can be
+ * used in situations where user-space mappings have to be shared across
+ * different files but no backing inode is available.
+ *
+ * Call iput(inode) to release the inode.
+ *
+ * RETURNS:
+ * New inode on success, error pointer on failure.
+ */
+struct inode *anon_inode_new(void)
+{
+ if (IS_ERR(anon_inode_root))
+ return ERR_CAST(anon_inode_root);
+
+ return anon_inode_mkinode(anon_inode_root->d_sb);
+}
+EXPORT_SYMBOL_GPL(anon_inode_new);
+
static int __init anon_inode_init(void)
{
int error;
diff --git a/include/linux/anon_inodes.h b/include/linux/anon_inodes.h
index 8013a45..ddbd67f 100644
--- a/include/linux/anon_inodes.h
+++ b/include/linux/anon_inodes.h
@@ -15,6 +15,7 @@ struct file *anon_inode_getfile(const char *name,
void *priv, int flags);
int anon_inode_getfd(const char *name, const struct file_operations *fops,
void *priv, int flags);
+struct inode *anon_inode_new(void);
#endif /* _LINUX_ANON_INODES_H */
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [uclinux-dist-devel] [GIT PULL] Blackfin updates for 3.11
Hi Steven, On Wed, 10 Jul 2013 14:05:45 +0800 Steven Miao wrote: > > Pls use for-linus branch on > http://git.kernel.org/pub/scm/linux/kernel/git/realmz6/blackfin-linux.git Done. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpa2k9AByyhk.pgp Description: PGP signature
